AGS 4: Watch Variables feature potential improvements

[ivan-mogilko]

This is a list of potential fixes and improvements copied from #2430 discussion.

• [ ] 1. Script TOC data is saved as an (optional) compiled script extension. It is saved only in Debug configuration, but I think that regardless it might be better to have it as a separate optional asset inside a game package. This is technically doable, but would require to change the game compilation workflow.
• [ ] 2. Somewhat related, I have to save declared imports along the "table of contents", although they are not part of script's memory. I must do that because memory inspector has to be aware of the imports type and kind (array, etc). But this is annoying, as this results in a large amount of duplicated entries across game scripts. I think that this could be resolved by saving this data in temporary files, and then merging them together in a single "toc" that mentions only imports. Again, this would require changes to compilation workflow.
• [ ] 3. Multidimensional arrays, I suspect they won't work at the moment, at least not dynamic multidimensional arrays (aka jagged arrays). This is not only this inspector's fault, but also an oversight in RTTI (I think I programmed RTTI before jagged arrays were implemented). I will have to address this separately, and begin with fixing RTTI, which should have means to describe array which has another array as its elements.
• [ ] 4. Memory inspector in the engine currently cannot deduce the size of the dynamic object, resolved from a handle (it cannot tell its type_id at that point... but this is related to how the memory resolving function is written). In practice this means that user may request any element of a dynamic array without boundary checks, and see memory contents past array's end. Possibly this may also lead to a program crash if offset is high enough. (added FIXME note in code)
• [ ] 5. Support nested expressions, such is - arrayname[ integervarname ]. I did not do that yet, being busy with fixing mistakes. May be addressed separately; but I think that would require simply a recursive call to "resolve memory" for each nested item.
• [ ] 6. Make "context" depend on a selected level of callstack. This means that if user switches to another item in a callstack window, the "watch variables" should react and update as if we looked from within a previous function. I think that this is doable, but would require extra work on both engine and editor side. The idea is to save the current callstack level and pass it as a part of the request. Engine should backtrack to the correct instance in the saved callstack. Backtracking script's stack position is what bothers me most though; this should be technically doable, would require saving previous stack pos in the "callstack" array, and maybe something else.
• [ ] 7. Save variables list on exit and restore on launch. May be done as a part of https://github.com/adventuregamestudio/ags/issues/2384.
• [ ] 8. If a variable that is a struct (not a managed struct), it's value will be displayed as "unknown data", instead of something like "(struct)".

[ericoporto]

I've been playing with Autocomplete (of AGS Editor) and recently with the Watch Variable panel in VBA (in Excel) and had an idea of offering the autocomplete that we can get in the line of the script that is on break (is this line known anywhere?) on the typing box we get in the watch variable. The idea came to me because the watch pane in VBA also doesn't have autocomplete and after using it for a bit for an issue at work I reminded that the one in ags also didn't have.

[ivan-mogilko]

that we can get in the line of the script that is on break (is this line known anywhere?)

Sort of, this line is known from the message that comes to Editor each time after a break or step. This message contains a callstack, with script/line pairs. I don't think if it's currently saved anywhere except for the Callstack panel.

[ericoporto]

Uhm, ok, so the issue here is if we want to have that specific line in autocomplete, so we can have all the local variables, the way to do requires we have access to the ScriptEditor, which both the script and the line will be get in the ZoomToFile call here

https://github.com/adventuregamestudio/ags/blob/e3a35543d5427232cbffb8f3d9f6389f337f0e5e/Editor/AGS.Editor/AGSEditor.cs#L370-L376

So what I can do is at some point here pass the script name and line to the watch panel (or somewhere else?), and then I can get this from there. I thought to do it even in that NotifyWatchVariables but I am unsure how to pass arguments and how that works - all these calls use those "invoke" which I know are needed for Winforms stuff but I don't understand how they work (are they async?).

And then having such info I can then know when someone is typing in watch variable which script and line should the autocomplete show relative to, and then I can pickup this from the corresponding scintilla wrapper instance. I need to play more with this before I have anything...

[ivan-mogilko]

I suppose, there could be a event named, as an example, OnScriptDebugPosition. This event could be located somewhere in GUIController, Debugger or other global manager. This event would be fire when: a) break point happens; b) step in script happens; c) script position is selected in Callstack window. (question is how to make callstack window trigger this event)

Any panel, such as WatchVariables window, would be able to subscribe to this event, and update itself upon receiving it.

WatchVariables would likely need to save "current debug position" for any future value updates.

[ericoporto]

I think C is not needed as the local variables shown there won't be in scope (for the engine internally I think), so we won't be able to read from there.

Regarding B, I thought that when a step is done the engine throws a break itself.

[ivan-mogilko]

I think C is not needed as the local variables shown there won't be in scope (for the engine internally I think), so we won't be able to read from there.

True, this is for the future, when engine supports backtracing callstack (task number 6 in this list).