What is the best method for someone who is not a developer (my coding abilities extend to semi-complex python scripting and some basic Java coding) to find out the progress towards having DFHack up to date with DF? I don't want to bother the devs or spam threads every time there's a new DF version. Instead, is there a way for me to find this out directly, on my own? If so, could some kind soul point me in that direction?
In the past, we have pointed people to "v0.xx.yy.lst" in
https://github.com/dfhack/df-structures. There isn't one yet for 0.44.x, though, because the Linux build was only just released.
Here is 0.43.05's; "UNCHECKED" is (potentially) bad, "ALIGNED" is good, "VERIFIED" is human-checked, so hopefully entirely right.
There are usually other things to be done too. You can look for the "r1" milestone under
https://github.com/dfhack/dfhack/issues, although it doesn't currently have anything assigned.
I meant the: "Various additional data in the XML export" from the release notes, is there not anything relevant to getting dfhack working added this time?
Toady added global addresses in 0.44.01, which are in a global table in the DF executable, nothing to do with the XML export.
I would have thought you already had a set of basic sanity checking tools for the structures that are mapped?
Yeah, we have some tools (cl-linux-debug, although it wasn't as useful without a Linux build). Mifki is actually working on another one right now, a Lua script.
I'm thinking of something that crawls through df.global depth first and verifies that fields with known bounds are within those,
Not sure what exactly this part means - it's nearly impossible to check primitive field sizes (integers)
and probably crashing (with a log indication of where) when assumed pointers don't point to legal locations as it attempts to follow the pointers.
We can check pointer validity, but it's a little slow. Checking vector validity isn't too hard either, but other things (like strings) can be more complicated.
- The most trivial sanity check would probably be to verify that enum values either have a legal value or -1.
Mifki's script does this, I think. (-1 is only legal for some.)
- Another check would be to verify that a value that's a reference into a vector is within that vector's range, or that an identifier (such as a hist fig id) lies within the range of the value of the first entry and the last one. That would require meta info on the field to specify what it refers to, though.
The problem there is that "ref-target" attributes from the XML files aren't available to Lua, so Lua scripts can't tell which vector a field like "unit.histfig_id" is for. cl-linux-debug can do this, I think.
- A third check would be to verify that arrays that should be the same length are (such as the coordinate vectors where X and Y are stored in separate arrays). Again, meta info would be required.
- A fourth check would be to check that arrays have the correct length, such as arrays that should be the size of the world width/height. Meta info required, of course.
Assuming you mean vectors; there's no way to check this reliably for C arrays. There are relatively few cases where we could use this metadata, and fewer still where we'd run into
valid vectors that should have the same dimensions but don't, so it's probably easier to just check things like that manually.
Edit: Some rather brief poking around using some of my scripts as probes only found a single issue: the DFHack Lua scriptery that displays which key a command is bound to always prints a question mark for me (as seen in gui/gm-editor's help screen, where all the commands are presented as "?: ...". The bound keys seem to work when pressed, however. I guess this is really not a structure issue, though, but a script one, for the next stage of the update.
That's because the "keydisplay" offset is missing on Win64 (I'm assuming you're using that, since that's the only platform that has any sort of 0.44.02 support but not that offset, but specifying is helpful). That points to a map of interface_key's to strings, which DF uses to display keys, and DFHack relies on as well (in Screen::getKeyDisplay()). You'll see the same issue in things like the manipulator plugin, so it's not Lua- or script-specific.
From devel/dt-export-ini.lua:
--WARNING below value should be: "general_ref::vtable","1","0x8","0x4","vmethod","getType","general_ref_type",""
value('ref_type',0x8)
I think this one should be 0x10 on 64 bits platforms (getType is the third method in general_ref vtable). Does the comment mean there is a proper way to get the value or should I add a test based on the architecture?
Sounds like you want 2*sizeof(void*), aka 2*dfhack.getArchitecture()/8.
The comment is referring to a line from CSV files exported by some df-structures-related tool that I've never really used much. I believe the old Perl script to generate DT layouts uses those CSV files, so maybe that's why the comment is there.
Minor result from poking around:
Found a dorf with a misc_unit_trait.id = 63 (nil)
.value =45
I suspect this means new misc_trait_type values have been added, since I can't find any value out of bounds on half a dozen 0.43.05 dorfs.
Yeah, that's probably the case, thanks. That's a "new" dwarf, right? (One generated in 0.44)
Author
Topic: DFHack 50.13-r1 (Read 811419 times)