Skip to content
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

Feature: "Monitor/Preview Node" Group for Base Address #163

Open
dreamsyntax opened this issue Jun 23, 2024 · 0 comments
Open

Feature: "Monitor/Preview Node" Group for Base Address #163

dreamsyntax opened this issue Jun 23, 2024 · 0 comments

Comments

@dreamsyntax
Copy link
Collaborator

Not really sure how to describe/title this, but the idea is this:

Given a base address: "80500000", in r3
Lets say we know the pointer 0x0 -> results in a string "MyObject"
We know the game takes this base address, and adds offsets to it BEFORE de-referencing a pointer.

For example,
lwz r15, 0x000C (r3)

Currently in DME, we have no way of keeping the base address as our "watch" address and adding a pre-pointer de-reference value.

We would NOT want:

base address: 80500000
level 0: 0xC

This is not the same as:

base address: 8050000C
level 0: 0x0

--

Additionally, many games sometimes can have fairly large range of pre-pointer adds ex:

805002C0 may be a valid reference to the base object, if the struct/class has many members such as a player struct.


Proposals:

  1. Implement a way to add to a base address, while keeping the base address as the watchlist value before a pointer derefence.
  2. Implement a new node "Preview" (name up to debate) similar to "Group" that allows previewing many values from the base address.

Example of the new node:
The "Preview" mode would have a base address of 80500000, with a value (range) of "0x200", and a depth value of "5"
This would then show the next 0x200 items within the "Preview's Group". We wouldn't be able to differentiate the types, but the iterator would be every "Word" (0x4).

The preview would look something like this:
image

Ideally we would be able to specify how many levels deep the items would attempt to resolve.
For example, each node would attempt to resolve 5 levels deep if possible, stopping wherever a pointer cannot be resolved.

image

In the above image, it would stop at the top level, not resolving as a pointer at all.

@dreamsyntax dreamsyntax changed the title Feature: "Monitor" Group for Base Address Feature: "Monitor/Preview Node" Group for Base Address Jul 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant