Skip to content

vec3 shift other variables #196

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
holmirr opened this issue May 23, 2021 · 3 comments
Open

vec3 shift other variables #196

holmirr opened this issue May 23, 2021 · 3 comments

Comments

@holmirr
Copy link

holmirr commented May 23, 2021

When I convert the value into a vector3, all other offsets of variables which defined below the vec3 get shifted by 8 bytes below.

@GH-Rake
Copy link
Contributor

GH-Rake commented May 23, 2021

Are you compiling from the source using all the latest commits? That should fix your issue

@ghost
Copy link

ghost commented Jul 29, 2021

After you defined the vector3 you just have to select the two nodes under the vector you just defined then right click and select remove nodes. Or you can select them individually and click on the red 'x' at the end right side. Dont worry this will not actually remove the offset from the the structure. However if you want to do so, there is also a feature called 'hide Selected Node(s) that does that. Now all the values under defined vector should be at the right offset again.

You will also notice that sometimes the values get shifted up. For example when you define an int64 in the x86 version (not sure why you would to hat) but it also sometimes happens when you change a node to hex 8 or 16 and then back to hex32. To fix this select the node under the changed one and choose insert bytes until the offsets underneath are in the right place again.

Im not sure but I think this is also the issue that some people are in #48 are complaining about. Anyways I hope this was helpful to you.

@KulaGGin
Copy link

KulaGGin commented May 2, 2022

For example when you define an int64 in the x86 version (not sure why you would to hat)

You'd do that when you have a 64-bit signed integer in a program.

You will also notice that sometimes the values get shifted up. For example when you define an int64 in the x86 version (not sure why you would to hat) but it also sometimes happens when you change a node to hex 8 or 16 and then back to hex32. To fix this select the node under the changed one and choose insert bytes until the offsets underneath are in the right place again.

Im not sure but I think this is also the issue that some people are in #48 are complaining about. Anyways I hope this was helpful to you.

Yes, this is a real problem of Reclass. One of the biggest ones. The way it works is obviously not what we want when we have a Player class with health field at offset 0xE8, so we mark it, and then we go back to offset 0x10 and define a transform field of type 4x4matrix. This shifts all the fields below the matrix and now we have to manually remove 36 bytes of fields below the matrix manually.

Sometimes we forget to do it and continue working. So we define new fields at offsets that are correct. But the fields we defined before we defined the matrix are at the wrong offsets. Then some time later we notice that old fields are at wrong offsets(because of defining the matrix). Now we have to manually fix offsets of all the fields we defined before(in time) the matrix but not the fields that we defined after(in time) the matrix. But the thing is that removing nodes shifts all the new fields we defined after(after in time, not offsets) the matrix, too. And so when we remove nodes to make older fields move to correct offsets, we break newer fields that we defined after(in time) the matrix. Basically, a nightmare operation. Once you have defined like 50 fields in a class and you have to do this nightmare operation, you'll know how annoying it is to fight a tool.

A much better way of doing this is how IDA does it: you define fields at offsets and they stay there. If you want a field at a different offset, you'll have to create it there and undefine the current one. And if a previous field starts to overlap onto the next one after you change its type to a bigger one, it just eats it. So let's say you first defined a float at offset 0x1C. And then you figured out that it's actually a 4x4 matrix at offset 0x10. So you define a matrix at offset 0x10. The matrix swallows the float at offset 0x1C. Much more intuitive to work with and you won't constantly break your class by shifting offsets of all fields every time you define a new field in a class that's bigger than the size of the node at which you define it at.

And that's exactly how it works in IDA behind the scenes: every defined structure has an array field called members and every member of this array is the field of the structure: it has an offset, type, name, size in bytes. Here's how IDA does if you're interested to learn more: https://www.hex-rays.com/products/ida/support/idapython_docs/ida_struct.html

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants