Print

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

[tryrar]

worked thanx!

[Kogut]

God bless you (cleanmap!)!

But there is problem with flows - in windows version it claims that I have 999515 tiles of water and 0 of magma what is untrue.

[Cave Man]

Is there a tool for cleaning equipment from mud, blood and vomit?

[peterix]

Is there a tool for cleaning equipment from mud, blood and vomit?

There will be. Quietust wrote one, but it needs a few tweaks. I'm slowly working on a new release.

Also, the 'experimental IPC after this weekend' is a fail. Not enough time >_<

[gsvslto]

I've written a new plugin for DFHack, called seedwatch, which is for fortress mode.

It can watch the quantities of seeds, and change whether the seeds and the plant grown from those seeds are allowed to be cooked.  In that way, you can cook seeds and plants without worrying that you will run out of seeds for planting (except when your dwarves eat the seeds raw - can't help with that!).

Thanks to Quietust for the information http://www.bay12forums.com/smf/index.php?topic=91166.msg2605147#msg2605147

I've got a GitHub for it https://github.com/gsvslto/dfhack/blob/master/plugins/seedwatch.cpp

Unfortunately, there are problems:

• It doesn't work for Linux Dwarf Fortress.  This is due to ...
  
• The access to the cookery exclusions structures in DF memory is a hardcoded memory hack, rather than through a DFHack module, as currently there is no such feature.  The kludge is at line 276 of seedwatch.cpp (in the t_kitchenExclusions::start method), and also at lines 107-144 (in the t_kitchenExclusions constructor).  I don't really know how to add the memory locations to memory.xml and use them in a module (either a currently existing one, or a new one).

However, as a general point, the cookery exclusions list in DF does allow DFHack (main program, modules, and plugins) to store information in the save game files for a particular fortress.  This is because, apart from the kinds of entries which do mean that an item is excluded from cookery, the entries in the cookery exclusions list (that is, the five co-ordinated vectors, listed in Quietust's post) have no effect upon DF, and yet are nevertheless saved in the save game files.  Therefore, by ensuring that the format of the information does not clash with legitimate cookery exclusion entries, such information can be stored in the save game via the cookery exclusions list.  This feature may be useful for other plugins and DFHack itself, as long the information does not clash with that stored by other plugins, modules, etc.

This storage facility is used by seedwatch to store which seed types the user wants to have watched and the limits for them, so that this information is automatically loaded by seedwatch when the game is loaded, and stored there when it is saved.  Therefore the user does not have to issue commands to seedwatch for a particular fortress each time that fortress is loaded.

Hopefully seedwatch will be useful for some people, or at least the basis for something useful.  I've tried to helpfully comment the code, and to make the help information clear, which can be viewed using #seedwatch info, in the DFHack console.  Of course, if there are any questions or suggestions, I'll try my best.  I don't think it's quite ready to be pulled into the main DFHack code at the moment, mostly due to the failure with Linux.

[Quietust]

Very neat.

Once peterix adds the entire PLANT definition structure (I've mapped it out on Windows, but it hasn't yet been verified on Linux), you'll be able to query the BASIC_MAT and SEED_MAT of every plant in existence (rather than only the ones you actually have at the moment) and find the appropriate offset within the plant's material list.

The current method of getting the plant/seed materials is a bit hackish (in fact, the entire Items module is extremely hackish), but right now it's the only way - the ideal way would be to call the item's virtual methods (vtable[0] = item type, vtable[1] = item subtype, vtable[2] = material type, vtable[3] = material subtype), but some Trickery would be involved in getting them to use the proper calling convention.

[Gizogin]

Is there any news on a mac version of this?  It's really frustrating not having access to it.

[peterix]

Is there any news on a mac version of this?  It's really frustrating not having access to it.

I don't have a mac.

[peterix]

I've written a new plugin for DFHack, called seedwatch, which is for fortress mode.

It can watch the quantities of seeds, and change whether the seeds and the plant grown from those seeds are allowed to be cooked.  In that way, you can cook seeds and plants without worrying that you will run out of seeds for planting (except when your dwarves eat the seeds raw - can't help with that!).

Thanks to Quietust for the information http://www.bay12forums.com/smf/index.php?topic=91166.msg2605147#msg2605147

I've got a GitHub for it https://github.com/gsvslto/dfhack/blob/master/plugins/seedwatch.cpp

Awesome

Unfortunately, there are problems:

• It doesn't work for Linux Dwarf Fortress.  This is due to ...
  
• The access to the cookery exclusions structures in DF memory is a hardcoded memory hack, rather than through a DFHack module, as currently there is no such feature.  The kludge is at line 276 of seedwatch.cpp (in the t_kitchenExclusions::start method), and also at lines 107-144 (in the t_kitchenExclusions constructor).  I don't really know how to add the memory locations to memory.xml and use them in a module (either a currently existing one, or a new one).

Yes. That can be fixed. I'll look at it today.

However, as a general point, the cookery exclusions list in DF does allow DFHack (main program, modules, and plugins) to store information in the save game files for a particular fortress.  This is because, apart from the kinds of entries which do mean that an item is excluded from cookery, the entries in the cookery exclusions list (that is, the five co-ordinated vectors, listed in Quietust's post) have no effect upon DF, and yet are nevertheless saved in the save game files.  Therefore, by ensuring that the format of the information does not clash with legitimate cookery exclusion entries, such information can be stored in the save game via the cookery exclusions list.  This feature may be useful for other plugins and DFHack itself, as long the information does not clash with that stored by other plugins, modules, etc.

This storage facility is used by seedwatch to store which seed types the user wants to have watched and the limits for them, so that this information is automatically loaded by seedwatch when the game is loaded, and stored there when it is saved.  Therefore the user does not have to issue commands to seedwatch for a particular fortress each time that fortress is loaded.

Good idea, IMHO bad implementation. It could break for newer versions of DF, leading to a kind of cat and mouse game with dfhack hiding data in other places in the game saves. A better way to do it is adding a way to store data next to the save files in the world folder. I'll leave it in until I have a generic system for storing plugin data in place.

Hopefully seedwatch will be useful for some people, or at least the basis for something useful.  I've tried to helpfully comment the code, and to make the help information clear, which can be viewed using #seedwatch info, in the DFHack console.  Of course, if there are any questions or suggestions, I'll try my best.  I don't think it's quite ready to be pulled into the main DFHack code at the moment, mostly due to the failure with Linux.

Haven't read it in full, but it seems that it does quite a lot of stuff in plugin_onupdate. Only thing plugin_onupdate guarantees is that it will never run at the same time as the game simulation - it can run more multiple times between ticks, leading to wasted CPU time. That's fine for something like reveal disabling the pause key by forcing pause state, but not for something that scans all the existing items.  The idea here would be to check if the game time has changed since the last run and only update when it did. Not the most obvious thing... I guess I should document this somewhere

[blake77]

1. Is it possible to make a tool that clears occupancy flags, or at least checks them. In my current fort there is one tile that I can't build a wall in because according to DF it is being blocked by an   object. I've already channeled out that tile but to effect.


2. I've noticed that using revflood tool, the walls of frozen lakes/oceans are not shown.

[rampaging-poet]

I played with the occupancy flags a bit.  It hasn't been merged into DFHack proper yet, but there's a plugin called buildprobe in the developer plugins section of my fork.  If you can build it yourself, my fork is here.  Use the setflag command to set the building flag to 0.

[Rumrusher]

I played with the occupancy flags a bit.  It hasn't been merged into DFHack proper yet, but there's a plugin called buildprobe in the developer plugins section of my fork.  If you can build it yourself, my fork is here.  Use the setflag command to set the building flag to 0.

oh man if you can set the occupancy flags to 14 you can recreate "DFlair" though I kinda want to test out setting indoor lighting for forts in adventure mode.

[Sutremaine]

Is it possible to make a spot clean tool? I want to keep my filth-encrusted entrance hall but clean off some odd pools in the middle of complicated stockpiles.

(except when your dwarves eat the seeds raw - can't help with that!)

Not a problem, dwarves don't eat raw seeds.

[peterix]

Is it possible to make a spot clean tool? I want to keep my filth-encrusted entrance hall but clean off some odd pools in the middle of complicated stockpiles.

Done.

[peterix]

And done.

New release is here with some pretty awesome stuff. Definitely check the first post for news.

Enjoy