Lock nodes offset

[Stridemann]

Hi,
Thanks again for a program.

I just wanted to ask if it's possible to add LOCK node feature. When you lock node it's offset can't be broken after deleting/inserting bytes before/under it.
Sometimes we don't need to define types in whole structure, just some nodes at start, middle and end of structure.

Also this feature gives us other new awesome feature - we can delete some byte range we don't need (like "hide" in old reclass).

I know, this can be not easy task, just wanted to ask if this is possible.
Thanks you.

[Stridemann]

Also adding options for inserting 1 and 2 bytes will be awesome too.

[KN4CK3R]

ye, locking something would be amazing, like the checkbox when u add a value in cheat engine, u press it, and it forces the value to it every 50 milisecond

That's not what he is talking about.

[KN4CK3R]

@Stridemann Currently that's not possible. There is a rewrite of the internal class representation planned. The new system may have support for that.

[Stridemann]

@KN4CK3R Thanks a lot for your work on this project. That will be really great.
I also working on free program for reversing (searching offsets) https://github.com/Stridemann/StructureSpiderAdvanced

I got one stable bug that throws crash error (can continue working, no data lost). Don't want to create a new issue due to low priority: When you double click on node to edit name (enable text input field) and then right click on any other place or node you will got error.

[KN4CK3R]

I got one stable bug that throws crash error (can continue working, no data lost). Don't want to create a new issue due to low priority: When you double click on node to edit name (enable text input field) and then right click on any other place or node you will got error.

But a crash is a real issue so you should have created another one.

[KN4CK3R]

The original request isn't implemented...

[dot-visual]

Still no fix for this? @KN4CK3R

[Timboy67678]

Nothing to fix, this is a feature request.

…

On Wed, 21 Aug. 2019, 9:00 pm .visual, ***@***.***> wrote: Still no fix for this? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#48?email_source=notifications&email_token=AAHSZZVDGU2243YKHXI5UQ3QFUN3JA5CNFSM4ESX2SAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ZJCBQ#issuecomment-523407622>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHSZZSBKHHFSY4WXGRIBPTQFUN3JANCNFSM4ESX2SAA> .

[LoneDev6]

Hello!
I think this feature request is a must have to avoid doing using a top-down approach when reversing a structure.
Let us know what you think @KN4CK3R

[oculus472]

Does anyone know of a good way to handle this? At the moment redefining fields is a nightmare.

[LoneDev6]

No idea sincerely, all the tools I tried have the same problem.
I always have to redefine all my structures from the ground up and use a top down approach

[ross-weir]

@KN4CK3R Is this still something you'd be interested having added?

If so I'd like to have a go at implementing this. Do you have any preferences/suggestions on how to go about it?

From a quick look I was thinking something like:

• Before adding nodes in InsertBytes save all defined node offsets - defined nodes being those with a non empty Name value.
• After adding nodes restore saved nodes to original offsets

[LoneDev6]

@KN4CK3R Is this still something you'd be interested having added?

If so I'd like to have a go at implementing this. Do you have any preferences/suggestions on how to go about it?

From a quick look I was thinking something like:

* Before adding nodes in `InsertBytes` save all defined node offsets - defined nodes being those with a non empty `Name` value.

* After adding nodes restore saved nodes to original offsets

Why not implementing it anyway, opening a pull request and in the meantime publish your fork?

[KN4CK3R]

You have to keep in mind that BaseNode.Offset is not intended to be frozen. Every action which changes the class layout recalculates the offset for all nodes.

[LoneDev6]

@KN4CK3R So basically this means that the program is structured in a way that this feature is very hard to implement without a lot of modifications?

[KN4CK3R]

Yes, you would have to insert HexNodes infront to increase a nodes offset or remove them. Removing will be a problem if there are no unused hex nodes to remove.
Something like this is already there:

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

Lines 191 to 204 in 0ee8a4c

	if (ShouldCompensateSizeChanges)
	{
	var oldSize = oldNode.MemorySize;
	var newSize = newNode.MemorySize;
	if (newSize < oldSize)
	{
	InsertBytes(index + 1, oldSize - newSize, ref additionalCreatedNodes);
	}
	/*else if (newSize > oldSize)
	{
	RemoveNodes(index + 1, newSize - oldSize);
	}*/
	}

Commented out 5 years ago because I decided it's not worth it.