What is the version of xEdit you are using?
FO4Edit 4.1.2p EXTREMELY EXPERIMENTAL (3854AB12)
FO4Edit 4.0.3 (1CDF3AC7)
FO4Edit 3.3.10 BETA (C9BB14F9)
FO4Edit 3.2.72 EXPERIMENTAL (42567E08)
All displayed identical behavior.
Describe the bug
Test mod for demonstration
Script properties with complex structures, i.e. where structs are within structs, and especially arrays (potentially of structs) within structs, still often do not parse correctly. Presumably as a result of this, manipulation of records that do not parse correctly may corrupt the record.
Using the data structure from hell I made for the test mod:
As parsed by xEdit
property testStructA =
[
level = 1,
recursion =
[
level = 2,
recursion =
[
level = 3,
recursion =
[
level = 4,
recursion =
[
level = 5,
moreRecursion =
[
* Note that this part appears to parse correctly,
but if manipulated, resaved, and then opened in the CK,
the value of moreRecursion here shows up as <<Unknown>>
[
level = 6
]
],
recursion =
[
level = 6,
recursion =
[
level = 7
]
]
]
]
]
]
]
To reproduce
Steps to reproduce the behavior:
- Load SillyScript.esp
- Compare parsed properties in __TestQuest in xEdit to CK property dialog
An example of weirdness when manipulating one of these records:
- Load SillyScript.esp
- Copy as override into... -> any other plugin
- Notice how the override differs from the original record
Expected behavior
Parsed by the game, this is how the data structure looks
This is as printed by the game to the Papyrus log, then prettified by hand.
Note that game fills in data about the script that xEdit wouldn't know (unassigned values).
property testStructA =
[
level = 1,
recursion =
[
level = 2,
recursion =
[
level = 3,
recursion =
[
level = 4,
recursion =
[
level = 5,
recursion =
[
level = 6,
recursion =
[
level = 7,
recursion = None,
moreRecursion = []
],
moreRecursion = []
],
moreRecursion =
[
[
level = 6,
recursion = None,
moreRecursion = []
]
]
],
moreRecursion = []
],
moreRecursion = []
],
moreRecursion = []
],
moreRecursion = [
[
level = 2,
recursion = None,
moreRecursion = []
],
[
level = 2,
recursion = None,
moreRecursion = []
],
[
level = 2,
recursion =
[
level = 3,
recursion = None,
moreRecursion = []
],
moreRecursion = []
]
]
]
How xEdit should parse it, probably
Same as above, but with the unassigned values that xEdit couldn't know about removed.
property testStructA =
[
level = 1,
recursion =
[
level = 2,
recursion =
[
level = 3,
recursion =
[
level = 4,
recursion =
[
level = 5,
recursion =
[
level = 6,
recursion =
[
level = 7
]
],
moreRecursion =
[
[
level = 6
]
]
]
]
]
],
moreRecursion = [
[
level = 2
],
[
level = 2
],
[
level = 2,
recursion =
[
level = 3
]
]
]
]
Additional context
I thought #544 fully addressed this, but I never looked closely enough at it to notice the remaining bugs.
What is the version of xEdit you are using?
FO4Edit 4.1.2p EXTREMELY EXPERIMENTAL (3854AB12)
FO4Edit 4.0.3 (1CDF3AC7)
FO4Edit 3.3.10 BETA (C9BB14F9)
FO4Edit 3.2.72 EXPERIMENTAL (42567E08)
All displayed identical behavior.
Describe the bug
Test mod for demonstration
Script properties with complex structures, i.e. where structs are within structs, and especially arrays (potentially of structs) within structs, still often do not parse correctly. Presumably as a result of this, manipulation of records that do not parse correctly may corrupt the record.
Using the data structure from hell I made for the test mod:
As parsed by xEdit
To reproduce
Steps to reproduce the behavior:
An example of weirdness when manipulating one of these records:
Expected behavior
Parsed by the game, this is how the data structure looks
This is as printed by the game to the Papyrus log, then prettified by hand.
Note that game fills in data about the script that xEdit wouldn't know (unassigned values).
How xEdit should parse it, probably
Same as above, but with the unassigned values that xEdit couldn't know about removed.
Additional context
I thought #544 fully addressed this, but I never looked closely enough at it to notice the remaining bugs.