Vectors are offsetting all other entries

[ShadyXVX]

Hi,

I'm pretty new to ReClass but I couldn't find an answer to my question anywhere. I just reversed a class with it and midway I noticed that almost all of my named entries in the list were 2 offsets down in the list which made them are incorrect. A little bit later I noticed that when I mark 3 coordinates for example as a Vec3 it pushes all entries below it down, so they are all wrong. Some entries also just disappeared like a health value that had nothing to do with any of the vectors.

I solved it by doing it all over again, marking all vectors first and then doing all other values which would be pretty annoying if I wouldn't have done the class already and knew how many vectors I will mark. Is there any solution to this or is this just normal behavior?

Thanks in Advance ;)

[KN4CK3R]

See the discussion in #48 and #196

[ShadyXVX]

From what I see in #196 removing the next vectorsize-1 nodes would fix the shifted offsets, is that right? Or is the top-down approach the only viable way?

[KN4CK3R]

Yes, it would fix it partly. But keep the problem in mind: If you accidently change the type to something big, it will erase all nodes in the new range. Then there are edge cases when you need to remove the first 4 bytes of a vec3 node. What do you do with this node? Convert it into three hex4 nodes and just keep the last two? How do you handle class nodes. You can change the "inner class" of that node. If the inner class has a different size, what do you do? Remove everything underneath? At some point I decided that a human can fix misaligned classes faster.

[ShadyXVX]

Okay, big thanks for the blazing fast support. Gonna try to keep a top-down workflow then.

[KN4CK3R]

If you have some finished areas you could use the node comment of some nodes to note the offset. If something breaks, you can compare the comment to the offset to find the problem.

[KulaGGin]

Then there are edge cases when you need to remove the first 4 bytes of a vec3 node. What do you do with this node? Convert it into three hex4 nodes and just keep the last two? How do you handle class nodes. You can change the "inner class" of that node. If the inner class has a different size, what do you do? Remove everything underneath? At some point I decided that a human can fix misaligned classes faster.

As I've mentioned in the #196, just do what IDA does. In all the questions you asked, IDA works just fine in all of these cases.

So if we will go with your vec3 example in IDA.
So suppose we have unknown class Player:

class Player {
public:
...
...
}
static_assert(sizeof(Player) == 0x40, "Size of Player should be 0x40");

And so we define a vector at offset 0x1C:

Then we decide that we don't want Vector at offset 0x1C, because it was a mistake, and instead we want 2 floats at offset 0x20 and 0x24. What do we do in IDA? We just press RMB and choose the undefine option in the context menu:

What does IDA do in this case? It replaces the whole vector with undefined bytes:

Now we define 2 floats as we wanted:

Now let's say we add health at offset 0x30:

And then we decide we still want that vector at offset 0x1C, so we just define it at offset 0x1C again:

It will just convert the field to the respective type at the specified offset and preserve all the other fields and the offsets that you specified after it: health in this case.

Under no circumstances IDA will shift offsets of other fields. It only does what we tell it: we want a field at offset, we define it there. We want to undefine the field, we undefine it. We want a field of a bigger size? IDA creates a field of that size, without shifting other fields.

And, of course, if we create something big, it will eat the fields that go after it. But it's not a problem, because there's always a Ctrl+Z undo command if you made a mistake and need to go to the previous state.

Yes, it would fix it partly. But keep the problem in mind: If you accidently change the type to something big, it will erase all nodes in the new range.

This can be fixed with the undo feature.

Convert it into three hex4 nodes and just keep the last two?

You undefine the field and it converts it into however many hex nodes as needed. Three hex4 nodes for Vector3, yes. When needed it can be three hex4 nodes and then one hex2 node, etc.

You can change the "inner class" of that node. If the inner class has a different size, what do you do? Remove everything underneath?

Yes, you start eating consecutive fields. Because rn if I have a class field and I change its size, all of the fields inside classes where this class is used are shifted, and now everything is broken and I have to fix offsets manually in every place where this class is used, and there is no way around it at all.

IDA also shows a message prompt about the fact that if you increase the field's size, it will overwrite consecutive fields, and you have to confirm that you do want to increase the size of the field and eat consecutive fields:

So you can always show a message prompt and ask the user if they really want to increase the size of the class, because if they increase the size of the class, it will start to destroy fields in other classes. Show which classes and which fields, at what offsets.