Non compatible change support

[neomonkeus]

@ttl269 @throttlekitty @jonwd7 @Ghostwalker71 @deedes @skyfox69
Just getting the ball rolling.

As per the discussion in #24 EE2 AoS breaks general nif format by not incrementing the user version, such that the version differences can't be detected through normal condition checking.

I mod EE2 models ok, but i cant do with the expansion (Art of Supremacy) models, when i open AoS models appears this error: ""array Properties much too large. 16777216 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:/Documents and Settings/GONGALO/Configuración local/Temp/Rar$DI97.584/civ10_cuirassier_French.nifcache'"

[hexabits]

I've only looked at a handful of files, but looking at Empire Earth II Gold edition, NIFCache files in the EE2X zips folder are 10.2.0.0 and NIFCache files in the EE2 zips folder are 10.1.0.0.

Is this not generally the case? If all the EE2X files were 10.2.0.0 then clearly there is something just not being correctly accounted for in the change between 10.1.0.0 and 10.2.0.0 ... Or are you saying that the 10.2.0.0 in EE2X is different from other 10.2.0.0 NIFs from other games?

[hexabits]

@neomonkeus @ttl269 ...In which case ticket #34 would be where this discussion lies.

---

OK, I just searched all 170 files in zips_ee2x\EE2X_graphics.zip\cache\nifcache\ and they are all version 10.2.0.0.

In all 1638 files in zips\graphics.zip\cache\nifcache\ there are no 10.2.0.0 files.

So... is there still an issue here separate from a version difference?

[neomonkeus]

Perhaps there are other games which use the 10.2.0.0 version.
@ttl269 any ideas?

[ttl269]

@jonwd7 @neomonkeus I think we have two separate problems. But both are related to fact that we have nif files with same Version and User Version but with different structure:

1. NIFs with Version = 10.2.0.0, User Version = 0
   • 170 NIF files from zips_ee2x\EE2X_graphics.zip (Empire Earth expansion nifcache). They can't be opened with recent nif.xml. They have modified structure of nif file - strange unknown int at start of any NiObject and also other modifications. Here is modified nif for opening them (only for this purpose).
   • I have also some files from game Making History (small amount of files has Version 10.1.0.0). They can be opened with recent nif.xml (with no modifications needed for files above,i .e. Empire Earth expansion nifcache).
2. NIFs with Version = 10.2.0.0, User Version = 1
   • There are sample files from issue Support 10.2.0.0, User Version 1 #34 (Skink.7z). I don't know which game they are from. They can't be opened with recent nif.xml. They need to enable those strange additions mentioned in NiSkinPartition unknowns removed #24. They have no vertexes and UVs in NiTriShapeData block but Triangles yes, so Nifskope reports errors with invalid indexes. As somebody at sf.net mentioned in Support 10.2.0.0, User Version 1 #34 - the vertexes and UVs are probably stored in arrays at ends of NiSkinPartition blocks.
   • I have also some files from Blood Bowl game. They can be opened with recent nif.xml. They must not have those strange additions mentioned in NiSkinPartition unknowns removed #24.

So it would be good to find more games using nifs with Version 10.2.0.0 and User Version = 0 or 1 and find out which structure they use. And then prefer that variant of nif.xml which is suitable for more games and take them as standard for that Version and User Version.

[hexabits]

I came back around to this issue while increasing the versions my 010 templates support and found the real issue. Simply put, the 10.2.0.0 NIFs in ee2x are actually 10.1.0.0 in practice.

NiObject is actually like so (in 010 template format):

typedef struct {
    if ( version >= V10_0_0_0 && version < V10_1_0_114 )
        uint groupID;
} NiObject;

So any NIF that is 10.0 or 10.1 will get the Group ID at the front of every single block, since every single block inherits NiObject. However, the ee2x 10.2 NIFs will only load if you treat them as if they are 10.1. As established there is no way to compensate for this in nif.xml since there is no differentiating factor.

Given this, I believe this should just be closed. Issue 2 in the above comment is another issue entirely, and the only way to resolve this issue is external to nif.xml. Some kind of compatibility mode in the parsers for 10.2 NIFs where it attempts to also load them as 10.1 if 10.2 fails.