NiSkinPartition unknowns removed

[ttl269]

@neomonkeus @skyfox69 @jonwd7 @Ghostwalker71 @throttlekitty @nexustheru @amorilia I have found a strange additions at the end of NiSkinPartition block definition. There is notice:

<!-- related to the file posted in tracker item #3117836:
            http://sourceforge.net/tracker/?func=detail&aid=3117836&group_id=149157&atid=776343 -->

followed by 7 lines of added unknowns conditioned only for nifs Version = 10.2.0.0 and UserVersion = 1. There is also added a compound SkinPartitionUnknownItem1. Yesterday I have got sample nifs from Blood Bowl game which are precisely of that Version and UserVersion and these unknowns causes error on nif load - these unknowns should not be there. Without these lines, nifs from Blood Bowl game are loading ok.

• Does anybody know anything about that mentioned tracker item #3117836 on sourceforge? That link don't works for me - it requires login into SourceForge account.
• Is it possible to get nif file(s) on which these unknowns was added to nif.xml?

For now I have uncommented them out as it is possible that these unknowns are valid for some nif versions - maybe there are only bad version/user version numbers in conditions.

[Ghostwalker71]

Would this be related to the recent thread on the forums... http://niftools.sourceforge.net/forum/viewtopic.php?f=10&t=5870&p=30085#p30085

[neomonkeus]

Link to original support request as migrated to allura platform - https://sourceforge.net/p/niftools/bugs/93/. Will copy over the information from there as part of migration process from sf.net to github. Should hold off on merge until all information is present.

[neomonkeus]

Original issue

Since the last version, NifSkope handles Empire Earth 2 nifcache files brilliantly. Unfortunately, the files from its expansion pack can't be opened; an error pops up, going like this:
""array Children much too large. 1868717941 bytes requested"" 
"failed to load block number 0 (NiNode) previous block was NiHeader" 
""infinite recursive link construct detected 0 -> 0"" 
"failed to load nif from 'C:/path to nifcache/any.nifcache'"
or this:
"failed to load block number 0 (NiNode) previous block was NiHeader" 
""infinite recursive link construct detected 0 -> 0"" 
"failed to load nif from 'C:/path to nifcache/any.nifcache'"
for all the nifcache files in the expansion pack. This applies to texcache files as well. I'm attaching several of these as examples,

@amorilia - Well, it appears that these nifs have an extra zero integer in front of every name (and perhaps in front of every string outside the header). As far as I can see, there's nothing earlier in the header to indicate this... Alphax, any clues as to how we might deal with this elegantly? It looks as if they customized the nif format without setting the user version field...

Ok, so from my understanding of the problem. The changes were introduced because of EE2 expansion as they never updated the use version. The changes introduced into the nif.xml break compatability with 10.2.0.0 and UserVersion = 1 "versioned" nifs as seen in BB.

I would propose that we introduce this change to support as many nif versions as possible. @jonwd7 - what are your thought on an "external" nif.xml or specific versions. Not sure if it applicable to the conversion we are having regarding #3.

[ttl269]

@neomonkeus @skyfox69 @jonwd7 @Ghostwalker71 @throttlekitty @nexustheru @amorilia I have also found same "zero integer before any NiObject" in some 10.2.0.0 nifs. The authors modificated the nif structure without changing user versions, so it is not possible for us to handle those nifs with one nif.xml.

[neomonkeus]

@ttl269 : Yes, @Ghostwalker71 linked to the forum topic in the comment previous to mine, I just collected all the information together based on the original sf.net bug report and your findings.

Personally I think that this fixes more than it breaks and the the change introduced by EEC2 mod version breaks too much compatiablilty. The pull request as is can be merged to "fix" the issue but how we handle support of EEC2 modified version or incompatible versions is something that is wider than this specific issue.