-
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
[DIRTY DRAFT] AGS 4: Watch game variables from the Editor #2390
Closed
ivan-mogilko
wants to merge
19
commits into
adventuregamestudio:ags4
from
ivan-mogilko:ags4--draft-memwatch
Closed
[DIRTY DRAFT] AGS 4: Watch game variables from the Editor #2390
ivan-mogilko
wants to merge
19
commits into
adventuregamestudio:ags4
from
ivan-mogilko:ags4--draft-memwatch
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This only counts regular variables in this script's data. Imported variables from other scripts are not resolved yet. Local variables on stack are not supported yet.
Currently NOT supported: - accessing array elements (parsing `[i]) - local variables on stack - imported variables - structs cannot be "viewed", querying regular structs return nothing, managed structs return handle value
WARNING: very ugly code (for now)
ivan-mogilko
force-pushed
the
ags4--draft-memwatch
branch
from
May 13, 2024 21:54
a20dc1f
to
bbd7a53
Compare
For the reference, I started working on a cleaner branch: will open a new PR when it will be at least usable. |
Closed in favor of a cleaner variant #2430 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WARNING: a dirty draft, contains ugly code and non-final data serialization, NOT FOR MERGING.
UPDATE: started a cleaner branch here: https://github.com/ivan-mogilko/ags-refactoring/tree/ags4--memwatch
This implements an mechanism for retrieving contents of engine 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.
A tall screenshot under the spoiler: **CLICK HERE**
What works:
[n]
notation.What does not work:
How is it done
x[N]:offset[,type[:offset,type[:...]]
, wherex
is a script's memory designation (e.g.g
for global script,r
for current room script,m2
for script module under index 2, and so on),offset
tells relative memory address in bytes, and type explains how to resolve this address (e.g.i1
for int8,i2
for int16,i4
for int32,h
for managed handle, etc).I implemented this command first, because it allows to get memory without even knowing variable names. But of course it's quite inconvenient for common users.
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 similar to "GETMEM" command, for itself, and then carries on with its processing.Other notes...
Remaining questions
Besides the code written in a dirty way, and quickly mashed serialization format for "table of contents" (I will be rewriting this as soon as I get more spare time), the big question I have is whether we want to have this "toc" persistent in the game scripts.
With RTTI the situation was simpler, because RTTI was required to make nested pointers work.
This TOC is so far only for debugging.
An alternate use that I might think of is for improving the save system, because knowing a list of variables may let us actually know what we are saving or reading. But this is only an idea.
I see two options here, if we don't want this to be always present in compiled scripts:
There's also a question of separating tasks. I wrote this so that engine does most of the work, but that's because it was faster for me to do. I thought that Editor, or another debugger (whoever sends commands), could be resolving variable names to memory instruction as well. But I'm not entirely certain about that now, because there are imported variables which address cannot be known without linking, and local variables with their tricky processing.
Finally, the "watch" GUI may be better, but that's a completely separate problem that may be dealt with on its own.
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.