ReClassNET / ReClass.NET

More than a ReClass port to the .NET platform.
MIT License
1.81k stars 368 forks source link

vec3 shift other variables #196

Open holmirr opened 3 years ago

holmirr commented 3 years ago

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 commented 3 years ago

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

ghost commented 3 years ago

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 commented 2 years ago

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