Closed deonix37 closed 3 years ago
Indeed, it fails on cycling references, so serialization shouldn't be used. But still, this PR aims for user friendliness so we don't have to write multiple debug statements or experience crashes when passing tables. So is it good without serialization?
Alright, sorry for not taking action for a while, had some stuff to take care of with real life.
Now, I still think this feature isn't really "needed", since there's an easy way to do what you're trying to do, and the feature you're implementing here has a lot of limitations, as we've seen before.
I just think it's better to keep the old system, even if it requires a little more work on the modder's end. Although, I like the idea of being able to send several parameters to DEBUG, so maybe there's something to look into with that?
All in all, unless you have something else to add, I'm ready to close this PR.
The addition you made is welcome, but it's also lacking, I'm afraid.
Here's an example I tried, which I think is missing some important data:
Plus I'm afraid having a table debugger inside of the C# debugger object doesn't give much freedom as to what you want to print: what if the user wants to print the tables inside said table, and if that's the case, how does one handle cycling references? (one table that contains another that itself contains the first table)
We already have a Lua function that displays tables correctly and which takes care of some of these problems (I'm adding it at the end of the comment, although it doesn't take care of cycling references), so it's up to you whether you want to tackle the problems I talked about or if you want to all simply drop the merge.