Changing types to bigger sized types move defined offsets

[Veykril]

I am not sure if this is intended or not(and i really hope it isn't) but when you change the type of an address to something bigger than what it was before, for example hex32 -> Vector3 it pushes all the already defined/named offset positions by the size leftover effectively making them all point to the wrong offsets which makes using this kind of cumbersome at times because i have to fix all my offsets over and over again.

[KN4CK3R]

It's intended and it's not intended 😁

Mode 1: Changed offsets
If you use a bigger sized type all following node offsets are wrong and you need to remove the now added space.

Mode 2: Deleted following nodes
If you use a bigger sized type all following nodes are removed until the used space is balanced. This could remove important nodes unintentionally (Example: You have a class instance node and change the referenced class. You accidently choose the wrong class which is really big. Now ReClass would try to keep the parent class size and remove all following nodes.).

I have decided that currently mode 1 is used because it is less destructive and therefore the user has less pain while using it.

ReClass.NET/ReClass.NET/Nodes/BaseContainerNode.cs

Lines 148 to 151 in 065aec1

	/*else if (newSize > oldSize)
	{
	RemoveNodes(index + 1, newSize - oldSize);
	}*/

Here you can see mode 2 commented out.

[Veykril]

Ah I see, thanks for the explanation. Your decision there makes a lot of sense then I guess. I didn't really grasp the "node system" before, but I got it now. So in mode 1 i basically have to delete the new extra nodes manually while mode 2 would do it automatically?

[KN4CK3R]

In mode 1 there are no new nodes. You just have to delete the existing nodes until the layout is fixed again. In mode 2 this deletion would be automatically but destructive.

Sure, mode 2 is the correct one but I think it is not worth it. It may become the standard mode if an undo system is added. But undo-redo is a lot of work and so far I failed to develop an architecture for this feature.

Here is an other discussion about that topic: ajkhoury/ReClassEx#31
And there you can see an other problem with mode 2. You change a class and ReClass needs to adjust all other classes where this class is used. Imagine you want to see what is in the memory after the class so you add 2048 bytes. Now you have successfully erased all/most nodes from other classes where this class was a reference.

[Veykril]

Ah yes got it, thanks for the thorough explanation!