Print

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

[khearn]

Ahh, I think I figured it out. I was following old instructions and cloning quietust's develop branch. Yeah, when I build from the regular develop branch it looks like dfhack. I do get some error/warning messages at startup:

Loading bindings from data/init/interface.txt
Resetting textures
Plugin weather: missing symbol: plugin_name
Can't load plugin misery
Plugin drybuckets: missing symbol: plugin_name
Plugin remotefortressreader: missing symbol: plugin_name
Plugin feature: missing symbol: plugin_name
Plugin initflags: missing symbol: plugin_name
DFHack is ready. Have a nice day!
DFHack version 0.42.06-alpha0 (development build 0.42.05-alpha1-40-g8eb39cc)

But it starts up, gives the usual prerelease warnings, workflow seems to be working. Enhanced stock screen looks good. I've definitely got dfhack running this time.

[sv-esk]

Something is wrong. All 0.42.06 symbols are known. missing symbol error shoul not be a thing

[lethosor]

For a couple of dfhack scripts/plugins (i.e autolabor, workflow) there is some data stored separately for each save file. Where is it stored? Is it possible to copy it from one save to another?

For example I have some dwarf labor rules set up in autolabor in game A. I did set it up once and then every time I load that save it's there. Is it possible to copy it to my next games without manually typing everything in dfhack console?

Thanks in advance!

Cheers,
Matt

Those two store their data as fake historical figures, which means it gets written to world.sav when DF saves (or unit#.sav, or something else). There's not a really easy way to extract that, although those plugins could implement their own export functionality.

One thing you can do is save the commands you use to a file, say "autolabor-setup.txt", then use DFHack's "script" command to execute all of the commands in that file (specifying the filename, e.g. "script autolabor-setup.txt"). Some plugins actually have a way to export the commands you would need to use for this technique, although I don't remember exactly which ones (the zone plugin might).

Ahh, I think I figured it out. I was following old instructions and cloning quietust's develop branch. Yeah, when I build from the regular develop branch it looks like dfhack. I do get some error/warning messages at startup:

Loading bindings from data/init/interface.txt
Resetting textures
Plugin weather: missing symbol: plugin_name
Can't load plugin misery
Plugin drybuckets: missing symbol: plugin_name
Plugin remotefortressreader: missing symbol: plugin_name
Plugin feature: missing symbol: plugin_name
Plugin initflags: missing symbol: plugin_name
DFHack is ready. Have a nice day!
DFHack version 0.42.06-alpha0 (development build 0.42.05-alpha1-40-g8eb39cc)

But it starts up, gives the usual prerelease warnings, workflow seems to be working. Enhanced stock screen looks good. I've definitely got dfhack running this time.

I'm going to guess that those plugins in red are left over from the older version of DFHack. You can safely remove those. (If you're on Linux, remotefortressreader was renamed to RemoteFortressReader, so I expect you have both in the folder and can get rid of the lowercase one.)

Something is wrong. All 0.42.06 symbols are known. missing symbol error shoul not be a thing

"symbol" in this case is a symbol defined in a plugin (or shared object, returned by dlopen()/dlsym()), not a DF global.

[Manzeenan]

was there ever a working plugin to give medical care to animals?

[khearn]

Ahh, I think I figured it out. I was following old instructions and cloning quietust's develop branch. Yeah, when I build from the regular develop branch it looks like dfhack. I do get some error/warning messages at startup:

Loading bindings from data/init/interface.txt
Resetting textures
Plugin weather: missing symbol: plugin_name
Can't load plugin misery
Plugin drybuckets: missing symbol: plugin_name
Plugin remotefortressreader: missing symbol: plugin_name
Plugin feature: missing symbol: plugin_name
Plugin initflags: missing symbol: plugin_name
DFHack is ready. Have a nice day!
DFHack version 0.42.06-alpha0 (development build 0.42.05-alpha1-40-g8eb39cc)

But it starts up, gives the usual prerelease warnings, workflow seems to be working. Enhanced stock screen looks good. I've definitely got dfhack running this time.

I'm going to guess that those plugins in red are left over from the older version of DFHack. You can safely remove those. (If you're on Linux, remotefortressreader was renamed to RemoteFortressReader, so I expect you have both in the folder and can get rid of the lowercase one.)

Yup, sorting hack/plugins by timestamp shows that those plugins (and only those plugins) are older than my latest make install. After removing them the warnings went away.

Thanks!

[Uzu Bash]

This may be a poor time to request a core feature, but could someone consider it on the back burner?

Aliases for commonly used command strings, pre-configurable in .init, usable in command window and interactive lua. This would be especially helpful for referencing the df.* heirarchy; ie aliasing 'df.global.world.world_data.sites' to 'SITES' and 'SITES[ # ]'. Could also include the command in the alias.

[lethosor]

Not sure what command window you're referring to, but I just added support for things like that to the interactive "lua" interpreter 5 minutes ago. Making it configurable would take some more time, but it's doable.

[Uzu Bash]

Not sure what command window you're referring to,

The only command-line window that opens in conjunction with DF+dfhack. And by configurable I'm talking about letting people assign their own sets aliases in an .init file, so they can use abbreviations convenient to them to refer to longer strings on command line as well as in the interpreter.

So I could enter something like this on command line:  ED UNITS[id#]
and it would be translated to: gui/gm-editor df.global.world.units.active[id#]
then for a lua search loop: for x,y in pairs(UNITS) do
and UNITS could be expanded to "df.global.world.units.active".

[lethosor]

Oh, you want aliases for normal commands too. That's also possible, although there isn't an easy way to do that yet. For Lua scripts, it's possible to set up redirects (see scripts/gui/hack-wish for an example - only the first line is necessary), but those are cumbersome. I think there's a suggestion for easier-to-use aliases on the issue tracker, e.g. an "alias alias-name command-name" command.

[lethosor]

0.42.06-alpha1 is up: https://github.com/DFHack/dfhack/releases/tag/0.42.06-alpha1
It contains some more fixes than the builds from yesterday, but the new stuff could also introduce problems that people didn't find earlier, so back things up, report problems, etc.

[PeridexisErrant]

This may be a poor time to request a core feature, but could someone consider it on the back burner?

Aliases for commonly used command strings, pre-configurable in .init, usable in command window and interactive lua. This would be especially helpful for referencing the df.* heirarchy; ie aliasing 'df.global.world.world_data.sites' to 'SITES' and 'SITES[ # ]'. Could also include the command in the alias.

https://github.com/DFHack/dfhack/issues/701

Considered, and indeed on the back burner

[Max™]

0.42.06-alpha1 is up: https://github.com/DFHack/dfhack/releases/tag/0.42.06-alpha1
It contains some more fixes than the builds from yesterday, but the new stuff could also introduce problems that people didn't find earlier, so back things up, report problems, etc.

Someone posted about it not being updated on /dfg/ literally seconds before I posted the link to it.

[Nimrod]

Thanks to you all! You are exalted among dwarves (and men).

[soul4hdwn]

sorry for referring to 0.40.26 still but tele-dwarves kinda cause babies to be abandoned, random babies lying around most of the time.  either they don't hunger/thirst or my absolute laziness waiting for the right phase of game to "be normal" on one of my worlds keeping teledwarf on is having dwarves provide... but they're perfectly fine and even grow up.

[Putnam]

Considering the way teledwarf works (by checking every unit on every tick to see if they're pathing, then teleporting them to the path destination should there be one), that doesn't surprise me in the slightest. "Teleporting" here refers to a process where all occupancy flags at the beginning and ending locations are set up properly for the new positions, the teleporting unit's laying-down flag is set as appropriate for if there's a standing creature at the destination, and the teleporting creature's position is set to the destination. Note that none of that accounts for babies, which I have no idea how the game keeps track of babies being held (some sort of general ref?)