-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AGS 4: Watch script variables at runtime #2430
base: ags4
Are you sure you want to change the base?
AGS 4: Watch script variables at runtime #2430
Conversation
01d2597
to
974a2f3
Compare
I believe that this feature now works for the most part. What remains are looking for nuances and edge cases, and usability improvements. The biggest next change which I have in todo here is to move return value formatting to the Editor side, and make engine return plain array of bytes, accompanied by a type hint. Possibly encoded in base64? EDIT: Another thing that could be supported here is having "nested expression" (variable reference) as an array index in |
e8e5bd9
to
16151ea
Compare
I can't figure it out how to test this, do I have to do something to make the watch variable panel not be empty? Edit: uhm... I tried to manually add a variable in my project but got and error...
OK, trying to attach a read in different places always gives me this error... Trying in a much simpler project in my String Split test I get a crash with exception but it's a different one
OK, figured if I comment any GUI stuff I don't get crashes |
What about making the local variables dynamically watcheable and having global variables require explicitly being watched? Plus some right click watch selection in the script editor. And perhaps an array could show the first three or five elements and a ellipsis to signal it goes longer. |
Please elaborate, what do you mean by "manually add a variable in project"?
I am not going to do any of these in the first stage. Any automation may be added later if there's a wish for that, and showing all variables should be optional, as I imagine not everyone will like that. There's a number of things to be figured out for this. For instance, at the moment Editor does not know which variables are there, because it does not read this gathered data. So either this data should be available for the Editor too, or it should receive their list from the engine first, using another command.
Whole array contents are not sent at the moment. This may be done though, but I need to figure out how to limit the size of tranferred memory (and also for strings). |
I tried testing the code you posted above, not commenting anything, and I do not get any exceptions. If you are still getting these crashes, could you send me your full test project? |
16151ea
to
e5584ba
Compare
In the ags4distfx.zip project, you can add a breakpoint in the After your changes I don't get crashes anymore in my String Split program (which is simpler), but I still do get crashes in the Sandwalker. In the title room (1) try to throw a breakpoint in I noticed my Ags4VideoHD.zip project can't hit breakpoints, but I don't know if this was a change here or breakpoints were broken during video playback... |
Could you also test the latest ags4 branch? I noticed that breakpoints do not work in room scripts with the new compiler, but they work with old compiler, but I don't know since when. |
I tested and it doesn't work in the latest ags4 branch too. The compiler doesn't make a difference. Edit: I also think I caught a new issue that the new video api is ignoring the |
Alright, should look into these separately... |
So, I fixed couple of more mistakes. Because of these variables did not show up correctly when one script called another. There's something else that I forgot; I probably should make it so that if you switch to another level of a call stack (in the Editor), the context of memory inspection also change. I will try implementing this tomorrow. |
@ericoporto I fixed a mistake in the old compiler that caused breakpoints to not work in room scripts. But from my tests, there's no problem with the new compiler. I think there could be a confusion if you don't order "Rebuild all files" then the room scripts are not rebuilt when you switch compilers, so it looks like the problem repeats with another compiler. Switching compiler property must force Editor to rebuild all scripts... |
Only compile with SCOPT_SCRIPT_TOC if game is built in Debug mode
This is a temporary solution for scanning imported variables, as import/export table alone does not let know the imported symbol's type. This may be disabled later if a more optimal way found.
49b3942
to
529b701
Compare
Hey, I tried this and now all my test games are running correctly and both the breakpoints are being hit as trying to read a variable do not crash AGS anymore. I tried a few of my games and it appears they are all working correctly as is now. If you want to merge as is and fix further issues later the way it is looks alright - I think one fix I will do after this is merged is to make the right click context menu of the watch panel to not have the "Remove" enabled if nothing is selected or you right click on blank space . Like logging with the Log Panel the first time I used, this feature is also one thing that I will miss now everytime I try to test something in AGS after having used it, when using a version that doesn't have it. xD |
This is just a cheap way of marking extensions as "optional", which may be skipped without loosing actual game feature.
* F2 starts editing selected item. * Ensure there's always 1 empty item in the end, which user may click to edit or use F2 on. * Automatically remove multiple trailing empty items.
This implements an mechanism for retrieving contents of a script memory via a debugger communication interface. Adds the "Watch variables" panel in the Editor, which lets user type in variable names, and receive current values.
The list of variables currently is worked with using a context menu that has Add/Remove/Clear commands. You may also edit variable's name by single clicking on a existing item in the list.
A tall screenshot under the spoiler: **CLICK HERE**
What works:
[n]
notation.What does not work:
How this is achieved
mystruct.member_field.internal_field
etc. In order to process this command and correctly resolve all memory addresses engine requires "table of contents" from the current script and RTTI. If these are not available, then it will fail. If they are present then engine builds a memory access instruction, and then processes this instruction as a separate operation. This is when it gets to the final memory address, reads a value of certain size, and thenformats it into a string, depending on its type.encodes value's bytes into a base64 string, except when value is already a string, and sends back to debugger.Other notes...
Design issues
But the problem is that they make a lot of duplicate entries in script TOCs. And also ScriptTOC is intended to serve an index of things found inside script, so presence of imported declarations there looks like a logical flaw. I suppose that their type info could be added to existing list of imports in the script data instead.
Backporting to AGS 3
If there's a wish to backport this watch feature to ags3, the RTTI generation must also be backported. Any RTTI-based features (in scripting) may be omitted, but RTTI table itself has to be present to be able to access nested fields and recognize types.
Known problems and TODOs
Parsing array access is done inconveniently in "query variable" code, and should be rewritten.TOCs compiled by an old compiler report regular array of managed pointers as a "managed pointer" itself, which results in unexpected values when typing only such array's name (without element index).With TOCs compiled by a new compiler there's a small mistake in local variable scope, which results in wrong local variable results at the first line inside a nested scope and the first line right after a nested scope.[]
; this means that multiple variables have to be resolved in a sequence (or recursively).Null pointers return no value instead of "0".String values should perhaps be reported in double quotes, in order to distinguish them from any special results, like "0" for a null string, or some service messages ("invalid variable" etc).Char
variables should perhaps have both numeric value and char value shown in a result string.Return errors from the engine, instead of empty value string on failure.In the Editor, "Output" panel is always sent to front whenever a compilation is started. Possibly it should bring "Watch variables" in front as soon as a test run is launched.Minor GUI improvements may be wanted, but these may addressed separately afterwards.