df-structures
df-structures copied to clipboard
df.creature-raw.xml:caste_raw.misc mismatches oddly between 0.44.12 and 0.47.03
Comparing the same save between versions, this structure looks the same superficially, i.e. the same fields in the same order. However, some of the fields have completely different values, only for field values to synchronize again, repeated several times. In addition to that, the "replaced" values in the older version does not reappear elsewhere, so it doesn't seem to be a simple rearrangement of fields.
Thus, I believer there's a need for an investigation into the actual layout of this structure.
@PatrikLundell is this still an issue as of 0.47.04?
Yes. Looking at the female TOAD (as it's the first one) for the same save between versions (originally the save comes from an LNP with the Phoebus tileset, but the 0.47.4 copy was copied from 0.44.12 no vanilla plus the DFHack at the time): itemcorpse_itemtype: 80 vs 1023 itemcorpse_materialtype: 0 vs 32760 caste_glowcolor: 0/0/0 vs -274/0/0 speed: 0 vs 32760 baby_age: 4 vs 7628903 child_age: 0 vs 375 (the previous value plus this one looks like a pointer) swim_speed: 1403 vs 11 grazer: 0 vs 375 unk_6: 1/1/2/0/1408/ 0/4/0/1409/ 0/4/0/1410/ 0/56/0/1411/ 0/112/0/1412/ 0/2/0/1413/ 0/4/0/1414 vs: 1/1/-2093337320/32760/8705/ 0/-1866901856/375/-1866901872/ 375/-1866762576/375/1024/ 0/-2093407849/32760/106/ 0/-1289657591/47/1297043015/ 1094999877/1090538322/20041/ 10/0/15/0/139264
Here is a comparison of 32-bit and 64-bit 0.47.04, and even that has some weird differences. I'm not sure what to make of this. It doesn't appear to be a padding issue, because some fields are totally different on 32-bit and 64-bit Linux, but others are the same (including some between different fields, e.g. remains_color
). Even stranger, the data I'm getting for unk6 on linux64 is:
[DFHack]# memview world.raws.creatures.all[0].caste[0].misc.unk6 116
0x7FFFEDA5E870 *01*00*00*00*01*00*00*00*66*6F*75*6E*64*20*3D*20 | ........found =
0x7FFFEDA5E880 *74*72*75*65*0A*20*20*20*20*20*20*20*20*20*20*20 | true.
0x7FFFEDA5E890 *20*74*69*74*6C*65*5F*73*63*72*65*65*6E*2E*73*65 | title_screen.se
0x7FFFEDA5E8A0 *6C*5F*6D*65*6E*75*5F*6C*69*6E*65*20*3D*20*69*64 | l_menu_line = id
0x7FFFEDA5E8B0 *78*0A*20*20*20*20*20*20*20*20*20*20*20*20*62*72 | x. br
0x7FFFEDA5E8C0 *65*61*6B*0A*20*20*20*20*20*20*20*20*65*6E*64*0A | eak. end.
0x7FFFEDA5E8D0 *20*20*20*20*65*6E*64*0A*20*20*20*20*69*66*20*6E | end. if n
0x7FFFEDA5E8E0 *6F*74*20*66 | ot f
which is from https://github.com/DFHack/scripts/blob/73f89fe3d48e52d9d860462df02d488b73de0953/load-save.lua#L33-L38. My initial guess would be that the size of misc is wrong, but that would throw off everything else in caste_raw, and fields at least as far down as body_size_1
appear to be valid.