Feature Request: Inspect variable while debugging

[Crimson Wizard]

I am more trying to think from the perspective that the import is in the header, so it gets into all scripts. So I think it would show everywhere. Which could crowd the variable watcher.

I suppose you imply the list that mentions all known variables?
If that's a list that has all variables from all the game, then it will have to include each unique variable only once. This may be achieved by creating a unique key, something like module.variable. If local variables are also included there, then the key would be more complex, including a function and likely a range of lines (i've been speculating on this in one of the previous comments).
If that's a list that only shows variables visible from the current place (a break point), then the variables may be filtered according to their visibility scope. I suppose that may work similar to how autocomplete works, although I haven't thought this through. In my opinion this is a secondary problem, and may be done as an extra task after the general mechanism is implemented.

My primary goal right now is to make possible for user to manually type variable's name into the list, and let Editor & engine resolve that into a value.

[eri0o]

2. Editor resolves the context-dependent name of a variable using a local->global var name table, and passes a globally unique variable name to Engine. Engine will still have to resolve its address using table of variables generated for the given script AND table of imports for the given script.

Uhm, just thinking back at this, I know that the Editor loads a GUID for each module pair when editing the script. Is that GUID present in the script object? Could this be used as a prefix somehow to help identify? I don't remember if we can have a case where a variable in a local context can match the name of a variable in a global context or if this blocked by the compiler.

Btw, about the three options I would suggest going for whatever you feel is the easiest to implement.

[Crimson Wizard]

Uhm, just thinking back at this, I know that the Editor loads a GUID for each module pair when editing the script. Is that GUID present in the script object?

No, GUID is purely editor thing and is not a part of the compiled script. The scripts may be identified with their "sectionname" which contains either name of header or script file. This is used when resolving types for RTTI.

[Crimson Wizard]

Some interesting progress. Now it understands variable names, including member names:



Branch is still here:
https://github.com/ivan-mogilko/ags-refactoring/tree/ags4--draft-memwatch

This requires script compiler to generate a table of contents of script memory.
And naturally, we need RTTI to be built as well, because RTTI tells us about struct fields.

For the time being I put resolving request inside Engine, it is just faster to write dirty code there.

Currently not supported:
- Accessing array elements (but it's a matter of parsing `[ i ]`);
- Imported variables (from other scripts). These need a mechanism that resolves local declaration to their actual memory location.
- Local variables (those that are allocated on stack). These require a somewhat different approach, because they do not exist in a single instance, but are generated as functions are called (and same local variable may be generated multiple times in case of recursive call), so there's no "fixed" address.


UPDATE: arrays work now (both regular and managed).

UPDATE2: imported variables from other scripts work now.
Imports from the engine don't work yet.

[eri0o]

Hey @Crimson Wizard , I just thought about it now, I imagine it's not possible to look into things that are from plugins, but how would it show, like say an object that is from a plugin. Or even perhaps like a "character*" to an engine character? Was just thinking about this.

[Crimson Wizard]

Hey @Crimson Wizard , I just thought about it now, I imagine it's not possible to look into things that are from plugins, but how would it show, like say an object that is from a plugin. Or even perhaps like a "character*" to an engine character? Was just thinking about this.

I am planning to make this work at the moment, need to revert and redo some recent changes for this. But only pointer value itself and plain fields will work, not properties.

For properties to be read, the corresponding "get_" function has to be called, which may lead to unwanted side effects. Also, properties which are handled in script cannot be run without having a dedicated script instance allocated exclusively for "watching". I'd rather not touch that until the general watch feature is completed.

[eri0o]

Oh, yeah, didn't expect those to be accessible, I was more thinking if there is a place in the list where the typename could appear maybe these could have like "(native)" or something to indicate they aren't script objects. But it's cool you have thought about this too. A lot of my System.Log usage will disappear with this new functionality (edit: the variable inspection things).

[Crimson Wizard]

Oh right, having a "type" column would be a nice addition too.

[Crimson Wizard]

Alright, new update:

1. Now supports local variables (from stack memory), including function parameters.
Supposedly, engine correctly calculates their lifescope, and overriding names in the nested sections should also work (but I cannot remember if old and new compilers allowed to do that yet). But it works correctly if you have multiple variables with the same name inside multiple functions.
The code for local variables turned to be uglier than the rest of the draft, so some things may still be not completely reliable.

2. Added "Type" column.

Branch is still here:
https://github.com/ivan-mogilko/ags-refactoring/tree/ags4--draft-memwatch

I might open a Draft PR to let this build on CI for easier testing.

[Crimson Wizard]

Opened draft PR: https://github.com/adventuregamestudio/ags/pull/2390

The test build may be downloaded here:
https://cirrus-ci.com/task/6250684968861696

This is based on AGS 4 (alpha) version.

[eri0o]

Very interesting stuff, haven't managed to try it out yet but will probably be playing with it tomorrow.

Save TOC in separate files, packed along with the scripts, sort of "debug symbols" for the game.

My view is this is best. It's not useful for actually running the thing and it will make the size of things bigger. I guess it will work like pdb files or dwarf or any of the many debug parts that are as separate files.