Notifying @fesh0r because he created xnb_parse and knows xnb_parse the best. Maybe you can help.
XmlHelper sometimes fails to find / apply special data simply because the naming of XML attributes / nodes is not the same as the naming of the fields / properties / types of FEZ. Such an example is maptree.xml, which required this commit to make XmlHelper import the xnb_parse output.
I understand that xnb_parse's goal is to make the FEZ data human-readable, which means changes in xnb_parse should be omitted. Instead, my goal is to find most, if not all, differences between the naming conventions in the xnb_parse XMLs and FEZ's internals and patch them into XmlHelper.FindSpecialType and XmlHelper.HandleSpecialDataDeserialize.
HandleSpecialData{Pre,Post}Serialize are not important as backwards compatibility is not a goal.
Only important incompatibilities will be listed. For example, the orientation of trile instances in levels being stored as bytes is not such an incompatibility, but rather an inconvenience. On the other hand, the naming of the type attribute varies of some nodes varies between the XML files (Level XML file: Entity.Type: entityType; MapTree XML file: MapNode.NodeType: type).
Known incompatibilities:
MapTree
[x] Node "Node" of type "MapNode"
[x] Node "Connection" of type "MapNode+Connection" (although this can be counted as FindType simply not finding nested types)
[x] Node "Scripts" being assigned to "ScriptIds", making finding the type of the node "Scripts" harder
[x] Node "Scripts" being assigned to "ScriptIds", makingXmlHelper think the "Script" children nodes are real scripts, not ints
[x] Attribute "name" of node "Node" being assigned to "LevelName"
[x] Attribute "type" of node "Node" being assigned to "NodeType"
[x] Attribute "chests" of node "WinConditions" being assigned to "ChestCount"
[x] Attribute "lockedDoors" of node "WinConditions" being assigned to "LockedDoorCount"
[x] Attribute "unlockedDoors" of node "WinConditions" being assigned to "UnlockedDoorCount"
[x] Attribute "cubeShards" of node "WinConditions" being assigned to "CubeShardCount"
[x] Attribute "splitUp" of node "WinConditions" being assigned to "SplitUpCount"
[x] Attribute "secrets" of node "WinConditions" being assigned to "SecretCount"
[x] Attribute "others" of node "WinConditions" being assigned to "OtherCollectibleCount"
Level
[x] Attribute "entityType" of node "Entity" being assigned to "Type"
[x] Node "Action" of type "NpcAction" with content being in attribute "key" (xnb_parse or XmlHelper?)
As I seem to forget to update this issue, it will be closed for now. I may re-open it at a future point if someone wants to list all the incompatibilities.
Notifying @fesh0r because he created xnb_parse and knows xnb_parse the best. Maybe you can help.
XmlHelper sometimes fails to find / apply special data simply because the naming of XML attributes / nodes is not the same as the naming of the fields / properties / types of FEZ. Such an example is maptree.xml, which required this commit to make XmlHelper import the xnb_parse output.
I understand that xnb_parse's goal is to make the FEZ data human-readable, which means changes in xnb_parse should be omitted. Instead, my goal is to find most, if not all, differences between the naming conventions in the xnb_parse XMLs and FEZ's internals and patch them into XmlHelper.FindSpecialType and XmlHelper.HandleSpecialDataDeserialize.
HandleSpecialData{Pre,Post}Serialize are not important as backwards compatibility is not a goal.
Only important incompatibilities will be listed. For example, the orientation of trile instances in levels being stored as bytes is not such an incompatibility, but rather an inconvenience. On the other hand, the naming of the type attribute varies of some nodes varies between the XML files (Level XML file: Entity.Type: entityType; MapTree XML file: MapNode.NodeType: type).
Known incompatibilities: