Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[myk]

This doesn't apply to items with more complex keys, like constructions sorted by coordinate, and I'm not even sure if insert_sorted() works for those.

I simulate building of constructions in the new build-now script, and insert_sorted() works with a custom comparator that handles "pos" as the sort key: https://github.com/DFHack/scripts/pull/310/files#diff-9091d1d17bc89f1a68bcba7da240ef463721738a3db24f21d0713efb8d092f42R352-R360

[myk]

I use this revealdesignated script a lot while playing:
...
If this is useful, could you incorporate it into the DFHack release? Maybe it would be useful for other people as well. And then I wouldn't have to keep installing it by hand.

You can submit it as a pull request to the scripts repo. That way it can get reviewed and improved before committing. For example, you could rewrite the script as a tiletypes command and it would probably execute much faster.

As a side note, you can keep your own personal scripts in any directory so they won't get overwritten by updates to DF and DFHack. You can add that directory to the DFHack script search path in dfhack-config/script-paths.txt. For example, my script-paths.txt adds my script dev directory and looks like this:

Code: [Select]

# Add additional script search paths here
# Blank lines and lines that start with "#" will be ignored
# Paths preceded by "+" will be searched first
# Paths preceded by "-" will be searched after the default paths
+/home/myk/src/dfhack-scripts


[Bumber]

What's the proper way to free a struct from memory in dfhack?

For example, a plant struct, which can have tree_info, etc., that needs to be deleted.

[myk]

Unless there's a library function that's handles it for you, you have to walk the struct and manually delete all the owned pointers. The trick is knowing which pointers are owned by the structure you're deleting :-)

[lethosor]

As a general rule of thumb, non-owned references tend to be IDs instead of pointers. This is not a guarantee, however. DF likely handles this in its own destructors, but the only time DFHack code can call those easily is when they are virtual (in which case "delete" from C++ or "obj:delete()" / "df.delete(obj)" should call them automatically).

[Bumber]

Is there a way to test if everything has been deleted?

[myk]

On Linux I believe we have valgrind integration, which will report any unfreed memory.

[Bumber]

I'm using Windows. Looks like DF reliably crashes when attempting to delete something that's already been deleted, so I can check using lua.

Looks like everything needs to be deleted manually for plants.

[lethosor]

I'm using Windows. Looks like DF reliably crashes when attempting to delete something that's already been deleted, so I can check using lua.

While a crash can indicate that DF has already deleted something, the inverse is not necessarily true: the lack of a crash does not mean that DF has not already deleted something, nor does it mean that the crash won't occur in the future or in different environments (other systems, DF versions, DFHack versions, etc.).

My suggestion (which unfortunately also doesn't work on Windows) is to use the MALLOC_PERTURB_ environment variable (Linux) or MallocScribble (macOS), which will overwrite freed memory with a specific bit pattern. This would allow you to use "memview" or something similar before and after deleted an object to see what else was freed.

Looks like deleting tree_info deletes extent_east, etc., (didn't check tree_tiles) but deleting a plant doesn't delete its tree_info. Guess I can't rely on it.

I verified on Linux that this is not the case:

Code: [Select]

t = df.plant_tree_info:new()
t.extent_east = df.new('int16_t', 120)
~t  -- in lua interpreter
t:delete()
~t
delete() frees the parent plant_tree_info struct, and causes it to be overwritten with garbage, but extent_east is left intact (all 0s), meaning that it was not deleted.

In general, delete() can't call "delete" or free() on sub-fields because it doesn't know whether it's safe (or which one is correct) any more than you do. DF's destructor does this, but we cannot call it directly unless it is virtual (which it is not in most cases, including for plant_tree_info).

[Bumber]

@lethosor

Does calling delete() on the plant struct delete extent_east?


In which module should I put a function that deletes a plant (given a df::plant) and removes it from the plant vectors?

[lethosor]

@lethosor

Does calling delete() on the plant struct delete extent_east?

That's exactly what my previous post was intended to answer "no" to. I realize now that it's confusing because you had also mentioned plant.tree_info in addition to plant_tree_info.extents_east. delete() does not delete any subfields of plant or plant_tree_info or most other structs, because their destructors are not virtual.

In which module should I put a function that deletes a plant (given a df::plant) and removes it from the plant vectors?

Good question. Maybe Maps?

[Bumber]

How do I check if the plant->contaminants vector is not NULL, and then delete it (without deleting the spatters the pointers aim at?)

Will this work?

Code: [Select]

...
if (plant->contaminants.capacity != 0)
std::vector<df::spatter_common *>().swap(plant->contaminants);
delete plant;
return;
Or should I use clear() or resize(0) and then shrink_to_fit()?

[lethosor]

How do I check if the plant->contaminants vector is not NULL, and then delete it (without deleting the spatters the pointers aim at?)

Will this work?

Code: [Select]

...
if (plant->contaminants.capacity != 0)
std::vector<df::spatter_common *>().swap(plant->contaminants);
delete plant;
return;
Or should I use clear() or resize(0) and then shrink_to_fit()?

This is different because plant.contaminants is not a pointer. Any memory internal to the vector gets freed along with the plant object - you don't need to delete it manually (and in fact, doing so will likely crash). It essentially follows the same rules as an integer field in this case.

If the vector contains pointers, it's worth pointing out that what I said does not apply to the objects that the vector is pointing to. You might still need to free them manually, although it sounds like you've determined that you don't in this case, because spatters are owned by something else.

Edit: another way of thinking of this: if you don't create the object yourself with new(), you should not destroy it with delete(). These are the same rules as C++. Since you don't need to create the contaminants vector manually when constructing a plant object, you don't need to (and should not) delete it manually.

[PatrikLundell]

Spatters on a plant should be removed together with the plant it's tied to. If the spatter resides in a different place and the vector just refers to them, you should locate that place and remove them from there (it could be the spatter vector owned by one of the blocks, but I have a feeling that's only for spatter directly on the tiles: regardless, you'll have to trace the info down and deal with it: if you don't you're probably creating orphaned data that won't be used [somewhat like the invisible puddles of evil rain from the air biome at the boundary between the air biome and the "real" biome beneath]).

[Erendir]

what is the nicest way to check from Lua if a structure has a field?

I want the following loop.

Code: [Select]

for j, gref in ipairs(posting.job.general_refs) do
if gref.unit_id == some_unit_id then
do_stuff
end
end
but I don't know what gref is going to be. If it's general_ref_unit_slaughtereest or general_ref_unit_workerst, it has unit_id, but general_ref_building_holderst doesn't.

In current form, the loop throws

Cannot read field general_ref_building_holderst.unit_id: not found.
stack traceback:
        [C]: in metamethod '__index'

Ideally, it would just return nil in this case, but this may be too much to ask