Header : Num Blocks resetting. about nifskope HOT 2 CLOSED

I'm a bit confused. What is the purpose of manually updating the header data? As far as I know the header data should never be touched directly.

If you're adding more blocks via "num blocks" it defaults to the 0th block type for the block type index. So if 0 = NiNode it creates N many NiNodes in the index, where N = Old # blocks - New # blocks. At the same time, it is not meant to handle the insertion of these blocks into the actual model data because the 0th block type (e.g. NiNode) defaults to having 0 block size and it doesn't carry out any of the function of Block > Insert > NiNode.

So I believe as far as the NIF data is concerned, it's correct that the header gets updated to reflect what is in the list/tree models upon saving. If it didn't refresh the header to match you could corrupt the entire NIF by messing with the header data.

In fact, I'm not sure if poking directly through the header is a good idea for end users. Maybe there should be some level of abstraction, a separate model / widget / etc. that lets you deal with the header data in a more user-friendly format. For one, making the string modal window (i.e. clicking 'TXT') more accessible, like its own draggable widget, and for the rest of the relevant header data, a widget like the Inspect widget. I'll create a ticket for that idea.

from nifskope.

Yeah I am closing this. The num blocks and block types and RTTI strings must come from what is present in the Block List. You can't do it the other way around. Incrementing Num Blocks is nothing like incrementing Num Children on an NiNode. If you need to add a block, you add a child to whichever node it belongs to, or if it's a property/extradata you add it to those arrays instead. Then you use the new Add Ref button on None refs to fill out the block.

from nifskope.