DFHack / dfhack

Memory hacking library for Dwarf Fortress and a set of tools that use it
Other
1.84k stars 461 forks source link

Exportlegends remove empty claims for Entities #1552

Closed ralpha closed 4 years ago

ralpha commented 4 years ago

There should be a check on if it is (going to be) empty in the exportlegends.lau file.

If the tag is empty it should be removed.

Example of current output:

<entity>
        <id>1</id>
        <race>ant_man</race>
        <type>civilization</type>
        <child>1</child>
        <claims>                </claims>
</entity>

Desired output:

<entity>
        <id>1</id>
        <race>ant_man</race>
        <type>civilization</type>
        <child>1</child>
</entity>

( The unwanted extra spacing inside the tag is already addressed in: https://github.com/DFHack/scripts/pull/148 )

So there should be an if-test before this line. https://github.com/DFHack/scripts/blob/068ae13427c7bad0c084c21a1ac83eec91395efa/exportlegends.lua#L420

        if ...<test here>... then
            file:write("\t\t<claims>")
            for xK, xVal in ipairs(entityV.claims.border.x) do
                file:write(xVal..","..entityV.claims.border.y[xK].."|")
            end
            file:write("</claims>\n")
        end
lethosor commented 4 years ago

Just from looking at the code, I'm guessing entityV.claims.border.x is a vector, so you'd want to check if it's non-empty, e.g. #entityV.claims.border.x > 0

ralpha commented 4 years ago

I'm not really familiar with the dfhack codebase. So don't know how the objects are structured. Or where I can even find the structure. So I did not know what to change. If you could point me in the right direction I could check it out.

As I'm working on a program that parses the xml. So I'll probably change this file more in the future. When I have some time I'll figure out how to fix it. :P

lethosor commented 4 years ago

Up to you - I can fix it if you like, or I can let you handle it.

gui/gm-editor is a nice way to visualize structures, or you can use the lua interpreter (specifically the ~ command within it to dump a structure is what I often use to explore things). I'm guessing entityV is an instance of df.historical_entity, so in the Lua interpreter you could start with df.historical_entity.find(some_Id) or df.historical_entity.get_vector(). https://dfhack.readthedocs.io/en/stable/docs/Lua%20API.html goes into some more detail about how the Lua API works and might help.

I'm not sure if that answers your questions, so let me know if there's something else we can clarify/help with.

ralpha commented 4 years ago

I'll check it out tomorrow. This looks like a good beginners bug :) I'll let you know if I have questions. Already found some other bugs/improvements so rather than writing a bug report I'll try to fix them. (Will make separate benches/pull requests for the bugs as noted here) Thanks for the info!

ralpha commented 4 years ago

Thanks for letting me handle this. I fixed and tested the issue in the pull request above. A simple solution but I have also set up a testing environment here so I can use it in the future. If you have feedback, let me know.

One small question, what did you mean with

or you can use the lua interpreter (specifically the ~ command within it to dump a structure is what I often use to explore things).

I got the gui/gm-editor working and it is quite nice. But dumping this to file might be nice too, if that is what you mean.

lethosor commented 4 years ago

By "dump" I just meant it'll list all of the fields, basically in the same format you see in gui/gm-editor. It has a couple advantages over gui/gm-editor for some use-cases (e.g. it's easier to copy text and develop snippets of scripts on the fly).