Bay 12 Games Forum

Dwarf Fortress => DF Modding => Utilities and 3rd Party Applications => Topic started by: lethosor on May 13, 2017, 10:35:51 pm

Title: DFHack 50.13-r1
Post by: lethosor on May 13, 2017, 10:35:51 pm
DFHack is a cross-platform framework allowing for easier development of tools that access DF memory (and of course, making the game more enjoyable for players). It comes with some useful tools that can fix your fort and make it easier to manage. DFHack integrates with Dwarf Fortress and extends it with plugins, scripts, a console, a way to bind hotkeys to commands, support for external tools to connect over the network, and more.

Continued development of DFHack would be impossible without its contributors and definitely isn't a one man show. Check this out! (https://dfhack.readthedocs.org/en/stable/docs/Authors.html)

DFHack 50.13-r1: Download (https://github.com/DFHack/dfhack/releases/tag/50.13-r1) (Current stable, for 50.13, Windows and Linux, all builds)
Nightly builds: Download (https://dfhack.org/builds/) (May be unstable)

Note: all releases can be found on GitHub (https://github.com/DFHack/dfhack/releases).

Please report bugs in the GitHub issue tracker (http://github.com/DFHack/dfhack/issues). This includes documentation issues and gaps. Feature requests are also welcome there, or you can discuss features beforehand here if you prefer.
If bugs are only reported in this thread, they may be forgotten. You can create a GitHub account here (https://github.com/join) in order to open issues in the issue tracker.

Documentation for the current stable version of DFHack can be found here: http://dfhack.readthedocs.io/en/stable/
Documentation for the latest development builds, including DFHack pre-releases, can be found here: http://dfhack.readthedocs.io/en/latest/

Some quick documentation links:

We have a couple chat options, listed here in order of age. Note that many people in these channels are idle and will only check them periodically. Please don't ask a question and leave seconds later without waiting for an answer.
(Note: our previous Freenode channel has been effectively deleted - many people have moved to Libera and/or Discord)
For even more support channels, see https://docs.dfhack.org/en/latest/docs/Support.html

The source code is available from GitHub (https://github.com/DFHack/dfhack). Please read the Compile (https://dfhack.readthedocs.org/en/latest/docs/Compile.html) document before building.

DFHack has many developers so we don't take donations. Donate generously to Toady instead! (http://www.bay12games.com/support.html) You can say it's in honor of DFHack if you want.

Some older versions of DFHack that aren't on GitHub can be found here: http://dethware.org/dfhack/download/ (http://dethware.org/dfhack/download/)

Previous threads: Peterix (through 0.34.11-r4) (http://www.bay12forums.com/smf/index.php?topic=91166.0) - Expwnent (through 0.43.03-r1) (http://www.bay12forums.com/smf/index.php?topic=139553.0)
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on May 13, 2017, 10:37:02 pm
Reserved (for no real reason other than that the previous threads did this too)
Title: Re: DFHack 0.43.05-r1
Post by: Amostubal on May 13, 2017, 11:42:53 pm
PTW. Congrats on the new release.
Title: Re: DFHack 0.43.05-r1
Post by: Rose on May 14, 2017, 12:52:40 am
Yay, new thread.
Title: Re: DFHack 0.43.05-r1
Post by: knedl on May 14, 2017, 02:46:24 am
Party time!  :P Congrats on the new release!  :D

Auto-unsuspend is set to 100 ticks, but for the sake of FPS death I think it could easily be set to 600. Once every half in-game day should work, tho I always play with 200 dwarfs and even big construction designations (over 100 blocks used at once) makes them swarm like flies. Not sure how 600 ticks would work on a smaller number of dwarfs.

And some food for the brain. While I was trading huge quantities yesterday and was watching my dwarfs swarming the trade depot bringing goods + close too 1000 stone blocks I was thinking about how to speed up this process. What I wonder is if it is possible that wheelbarrows could be assigned to trade depot. Now lets say that you could assign 100 wheelbarrows to the trade depot (like you can to stockpile), by each adding +1% speed to the dwarfs that caries the goods to and off the depo. So the dwarfs would not be running around with wheelbarrows to bring goods to the depot but they would just be faster when doing the bring goods to trade depot job. Not sure where the wheelbarrows would be stored tho. In case of trade depot which entity creates a job - a storage where goods are stored or the trade depot? I know it's the storage that actually creates jobs for hauling but in case of trade depot it could be different. Any ideas on this one?
Title: Re: DFHack 0.43.05-r1
Post by: Warmist on May 14, 2017, 02:53:15 am
Just want to be part of the party :]
Title: Re: DFHack 0.43.05-r1
Post by: PeridexisErrant on May 14, 2017, 04:52:33 am
New thread!  Congrats and thanks to everyone who has contributed to this release :D
Title: Re: DFHack 0.43.05-r1
Post by: Amostubal on May 14, 2017, 07:30:20 am
Party time!  :P Congrats on the new release!  :D

Auto-unsuspend is set to 100 ticks, but for the sake of FPS death I think it could easily be set to 600. Once every half in-game day should work, tho I always play with 200 dwarfs and even big construction designations (over 100 blocks used at once) makes them swarm like flies. Not sure how 600 ticks would work on a smaller number of dwarfs.

And some food for the brain. While I was trading huge quantities yesterday and was watching my dwarfs swarming the trade depot bringing goods + close too 1000 stone blocks I was thinking about how to speed up this process. What I wonder is if it is possible that wheelbarrows could be assigned to trade depot. Now lets say that you could assign 100 wheelbarrows to the trade depot (like you can to stockpile), by each adding +1% speed to the dwarfs that caries the goods to and off the depo. So the dwarfs would not be running around with wheelbarrows to bring goods to the depot but they would just be faster when doing the bring goods to trade depot job. Not sure where the wheelbarrows would be stored tho. In case of trade depot which entity creates a job - a storage where goods are stored or the trade depot? I know it's the storage that actually creates jobs for hauling but in case of trade depot it could be different. Any ideas on this one?
Easier methods exist...
1. fastdwarf 1 1 they just teleport to good to depot to meeting area repeat. sorry I was on a phone, damn autocorrects.
2. Trade stockpile, setup a stockpile by depot that auto trades it's goods to the depot. Add wheelbarrows, setup the stockpile settings to what you want traded...

But really, unless your selling boulders to the depot, wheelbarrows aren't going to help much.  I prefer method 1, but method 2 is very effective if your trying to 'not cheat'.  I use it for custom merchant shops in MW to sell unwanted stones and other things.

Additionally without a stockpile, dwarves will try to send wheelbarrows back to a furniture stockpile, or other stockpiles with wheelbarrows enabled.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on May 14, 2017, 04:35:44 pm
Auto-unsuspend is set to 100 ticks, but for the sake of FPS death I think it could easily be set to 600. Once every half in-game day should work, tho I always play with 200 dwarfs and even big construction designations (over 100 blocks used at once) makes them swarm like flies. Not sure how 600 ticks would work on a smaller number of dwarfs.
I was worried that 600 would be too slow with low FPS, although I could increase it or try to make it configurable, although I'm not exactly sure how persistent settings would work with Ruby scripts. Alternatively, we could add an automatic mode to the "resume" plugin to replace autounsuspend entirely.

Eastward 1 1
I think this should be "fastdwarf 1 1" (in case anyone's confused).
Edit: fastdwarf, not teledwarf
Title: Re: DFHack 0.43.05-r1
Post by: Amostubal on May 14, 2017, 05:20:26 pm
Auto-unsuspend is set to 100 ticks, but for the sake of FPS death I think it could easily be set to 600. Once every half in-game day should work, tho I always play with 200 dwarfs and even big construction designations (over 100 blocks used at once) makes them swarm like flies. Not sure how 600 ticks would work on a smaller number of dwarfs.
I was worried that 600 would be too slow with low FPS, although I could increase it or try to make it configurable, although I'm not exactly sure how persistent settings would work with Ruby scripts. Alternatively, we could add an automatic mode to the "resume" plugin to replace autounsuspend entirely.

Eastward 1 1
I think this should be "teledwarf 1 1" (in case anyone's confused).
lol damn phones... wasn't it fastdwarf? or did we name change and I've got an old script roaming around , lol.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on May 14, 2017, 05:23:09 pm
Yeah, it's fastdwarf. I realized just before I posted that that I was about to use the wrong name, but apparently I still managed to get it wrong. Fixed.
Title: Re: DFHack 0.43.05-r1
Post by: eddievxx on May 15, 2017, 08:06:33 pm
I have just been browsing the dfhack docs, and the steam-engine plugin has caught my eye (and imagination). But I am not sure if it is still current... at least, it doesn't appear to be running automatically, nor when I try 'enable steam-engine'. it says:
steam-engine is not a recognized command.                                                                               
steam-engine is a plugin but does not implement any commands

I googled around a bit but couldn't really find anything on it at all.

I am currently running the latest LNP with DF 43.05 & DFHack 43.05-beta on windows (and also on Linux but I haven't tried steam-engine on linux yet).

Any ideas how I should go about getting a steam engine running?

Title: Re: DFHack 0.43.05-r1
Post by: lethosor on May 15, 2017, 08:24:11 pm
I have just been browsing the dfhack docs, and the steam-engine plugin has caught my eye (and imagination). But I am not sure if it is still current... at least, it doesn't appear to be running automatically, nor when I try 'enable steam-engine'. it says:
steam-engine is not a recognized command.                                                                               
steam-engine is a plugin but does not implement any commands

I googled around a bit but couldn't really find anything on it at all.

I am currently running the latest LNP with DF 43.05 & DFHack 43.05-beta on windows (and also on Linux but I haven't tried steam-engine on linux yet).

Any ideas how I should go about getting a steam engine running?
It's a plugin, but it's not a plugin that provides commands you can run (so none of the commands you ran will work). The steam-engine documentation (http://dfhack.readthedocs.io/en/stable/docs/Plugins.html#steam-engine) should explain it. The key part:
Quote from: http://dfhack.readthedocs.io/en/stable/docs/Plugins.html#steam-engine
The steam-engine plugin detects custom workshops with STEAM_ENGINE in their token, and turns them into real steam engines.
You need to create custom workshops in the raws, with "STEAM_ENGINE" in their token, and then the plugin should detect them and enable itself. There should be an example of this in the hack/raw folder.
Title: Re: DFHack 0.43.05-r1
Post by: eddievxx on May 15, 2017, 09:15:10 pm
I see. Excellent. Cheers.
I did see those examples in the raws... I will give it a go...

Edit: I copied the 3 example raw files as is into the DF raws folder, and updated the entity_default.txt file with the relevant lines; and now I see the steam engine in the workshop list, and piston in the forge list. So it appears to be working although I have not actually build a steam engine yet...
Title: Re: DFHack 0.43.05-r1
Post by: Rumrusher on May 16, 2017, 09:15:34 am
so it seems like on the prepare for journey screen, you can change the job for the pets you can get.
which means you can spend points on a cat doctor, or a Dog tavern keeper.
I wonder if with a tad bit of modding you can set up additional special migrants.
Title: Re: DFHack 0.43.05-r1
Post by: Droggarth on May 16, 2017, 02:05:03 pm
Lethosor... *draws his own most precious Drolth sword from the collection that has many slain monster and creature names engraved into its memory-* Thank you so much! *-and gives that Drolth sword as a gift to Lethsor*
(http://i.imgur.com/I1ieYD3.png)
Title: Re: DFHack 0.43.05-r1
Post by: Droggarth on May 16, 2017, 02:07:58 pm
(delete: accidental double post upon editing the original post)
Title: Re: DFHack 0.43.05-r1
Post by: Hesperid on May 17, 2017, 11:29:42 am
If we got an actual release of Dfhack for v 0.43.05, then that must mean the new Dwarf Fortress release is only days away.
Title: Re: DFHack 0.43.05-r1
Post by: Amostubal on May 19, 2017, 12:00:44 pm
okay I found this in a script in MW repository that is causing a slight issue.

df.global.gps.screen.value

in this:
Code: [Select]
  -- Reset count if a new fort or reclaim, i.e. onload.init runs prior to load of embark screen.
  if df.global.gps.screen.value == 0 then

and apparently this does not spot an embark screen. I'm not even sure what it is spotting.  But the reality is I want it moved to the onMapload.init anyway, so the question is at onMapload.init.  Is there a way to detect If a map is new?   Basically I want this counter to reset every time a new embark has occurred on the map, not every time the map is loaded.  And for it to occur when onMapload.init is loaded.

any ideas on a direction to head in?
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on May 19, 2017, 12:52:09 pm
okay I found this in a script in MW repository that is causing a slight issue.

df.global.gps.screen.value

in this:
Code: [Select]
  -- Reset count if a new fort or reclaim, i.e. onload.init runs prior to load of embark screen.
  if df.global.gps.screen.value == 0 then

and apparently this does not spot an embark screen. I'm not even sure what it is spotting.  But the reality is I want it moved to the onMapload.init anyway, so the question is at onMapload.init.  Is there a way to detect If a map is new?   Basically I want this counter to reset every time a new embark has occurred on the map, not every time the map is loaded.  And for it to occur when onMapload.init is loaded.

any ideas on a direction to head in?
Yeah, that has nothing at all to do with the embark screen. That detects whether the tile in the upper left corner of the screen is blank, has a black background color, has a black foreground color, or doesn't have a bold/bright foreground color (it's exactly one of those four; I'm not sure which). I definitely would not rely on that. It looks to me like someone just found something that seemed to correspond to the embark screen sometimes and decided to use it.

This is one way to check for the embark screen:
Code: [Select]
df.viewscreen_choose_start_sitest:is_instance(dfhack.gui.getCurViewscreen())
I would be more inclined to use an onStateChange handler in your situation (see http://dfhack.readthedocs.io/en/stable/docs/Lua%20API.html). Maybe something like this:

Code: [Select]
was_embarking = false
dfhack.onStateChange.your_script_name = function(event)
    if event == SC_VIEWSCREEN_CHANGED then
        if df.viewscreen_choose_start_sitest:is_instance(dfhack.gui.getCurViewscreen()) then
            was_embarking = true
        end
    elseif event == SC_MAP_LOADED then
        if was_embarking then
            print('do stuff')
        end
        -- make sure this doesn't fire again the next time a map loads, unless the user embarks again
        was_embarking = false
    end
end

Title: Re: DFHack 0.43.05-r1
Post by: Amostubal on May 19, 2017, 01:53:16 pm
awesome lethosor... new unbroken territory of dfhack for me.  I'll try that and see what I can get it to do.



I've also found some other scripts I thought were from DFHack but apparently not?  Some of them I'm not even sure why they even exist or what they were there to fix.   I didn't notice these until I was switching to this version (previously I just copied back in all the scripts that were removed, then deleted/fixed as they produced errors, this time I grouped them into one folder separate from DFHack).  I've identified several of their sources... most were old scripts that apparently were just left in, even though their usage had stopped.

But a couple I find are rather useful, and one I thought was odd for not being a DFHack script, it needs some reformatting to fit the motif of DFHack, but its a fix for handedness of gloves produced by reactions... As far as I can tell its just checking every X ticks for unhanded gloves then just switching them left, right, left, right.  Its in ruby, so I'm not fully on board with the language, but I think I can read other rb scripts in DFHack, and update the format to fit. and post it to the github if your interested in a such a fix... I couldn't find a similar fix inside of DFHack, other than the one in create-item.
Title: Re: DFHack 0.43.05-r1
Post by: Amostubal on May 19, 2017, 03:11:21 pm
new information... apparently dfhack persistent created tables are deleted when a map site is abandoned, at least my test map was doing that... I just removed the line of code and the whole thing returned to normal operation all together, as the saved counter disappeared when I abandoned the fortress.  is that as intended?  I'm going with it at the moment, and stick to this fix, unless someone has some other
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on May 19, 2017, 07:34:49 pm
But a couple I find are rather useful, and one I thought was odd for not being a DFHack script, it needs some reformatting to fit the motif of DFHack, but its a fix for handedness of gloves produced by reactions... As far as I can tell its just checking every X ticks for unhanded gloves then just switching them left, right, left, right.  Its in ruby, so I'm not fully on board with the language, but I think I can read other rb scripts in DFHack, and update the format to fit. and post it to the github if your interested in a such a fix... I couldn't find a similar fix inside of DFHack, other than the one in create-item.
Is that autofixhandedness? It sounds familiar, but I couldn't find it in any Git history, and I'm not entirely sure what it was used for. Maybe I just heard about it from MDF.

new information... apparently dfhack persistent created tables are deleted when a map site is abandoned, at least my test map was doing that... I just removed the line of code and the whole thing returned to normal operation all together, as the saved counter disappeared when I abandoned the fortress.  is that as intended?  I'm going with it at the moment, and stick to this fix, unless someone has some other
I don't think that's intentional. Had you saved before abandoning? Persistent tables are still saved as histfigs, I believe, and those shouldn't normally be deleted when you abandon a fortress, as long as the world stays around.
Title: Re: DFHack 0.43.05-r1
Post by: Gorobay on May 19, 2017, 07:37:13 pm
How can I determine site-specific position assignments, like captain of the guard? I can get entity-wide position assignments using historical_entity.positions.assignments, but I can’t find the site equivalent.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on May 19, 2017, 07:51:11 pm
How can I determine site-specific position assignments, like captain of the guard? I can get entity-wide position assignments using historical_entity.positions.assignments, but I can’t find the site equivalent.
This (https://github.com/DFHack/scripts/blob/f6862e8c4351bc2e319df3e2b925c9b65eb7f1bb/gui/extended-status.lua#L51) is what gui/extended-status uses to find managers. I couldn't find anything in my fort's world_site instance ("df.world_site.find(ui.site_id)"), but it has two entries in "df.world_site.find(ui.site_id).entity_links", with one's entity_id equal to ui.civ_id and the other's entity_id equal to ui.group_id, and the assignments for the latter (what gui/extended-status uses) change when I assign a manager.

I'm not sure if that's useful or not, since I couldn't figure out a way to detect a militia commander just now. I'm assuming captain of the guard wouldn't be much different.
Title: Re: DFHack 0.43.05-r1
Post by: Gorobay on May 19, 2017, 08:00:12 pm
That was indeed helpful. Given a site site, its assignments are df.historical_entity.find(site.cur_owner_id).positions.assignments, which is exactly what I was looking for.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on May 19, 2017, 08:02:51 pm
Cool. Player fortresses seem to have a cur_owner_id of -1, so I would have missed that. Out of curiosity, how are you finding militia commanders? Are you searching through assignments yourself? I couldn't find something in assignments_by_type that looked like it was changing when I assigned one.
Title: Re: DFHack 0.43.05-r1
Post by: Gorobay on May 19, 2017, 08:20:28 pm
I am not looking for militia commanders, or any other position in particular: I had some numbers which I was pretty sure corresponded to site positions, and in fact they are indexes into the site’s group’s positions.assignments. A pull request is forthcoming. I am not sure how to find the assignment for a given position, but probably I would iterate through that vector, checking each position_id in positions.own until I found the one that matched the position I wanted.
Title: Re: DFHack 0.43.05-r1
Post by: Max™ on May 20, 2017, 05:45:08 am
Hmmm, I just checked one of my active reclaimed forts, df.global.world.world_data.active_site.entity_links and looked at the bottom of the list, numbers list the site id and relevant entity, usually player created/claimed site groups are near or at the end, went to that entity and grabbed this shot:
Spoiler (click to show/hide)
Isn't that it?

Oh yeah! Is there a simple way to recenter a screen on a unit or whatnot that I'm just a moron and overlooked? I couldn't figure out dfhack.screen.zoom() syntax at all though I tried feeding it my unit position, cursor position, unit id, and a couple other things.

Hmmm, there's an update screen check too isn't there? Was annoying trying out a "teleport to the cursor" hotkeyable script because if you have the cursor out of view you have to move before it will refresh your screen fully. Even tried having it just straight up list that tile as revealed through the dfhack.maps.getTileBlock(blah).designations[xmath][ymath] stuff with no luck.
Title: Re: DFHack 0.43.05-r1
Post by: Amostubal on May 20, 2017, 08:37:44 am
But a couple I find are rather useful, and one I thought was odd for not being a DFHack script, it needs some reformatting to fit the motif of DFHack, but its a fix for handedness of gloves produced by reactions... As far as I can tell its just checking every X ticks for unhanded gloves then just switching them left, right, left, right.  Its in ruby, so I'm not fully on board with the language, but I think I can read other rb scripts in DFHack, and update the format to fit. and post it to the github if your interested in a such a fix... I couldn't find a similar fix inside of DFHack, other than the one in create-item.
Is that autofixhandedness? It sounds familiar, but I couldn't find it in any Git history, and I'm not entirely sure what it was used for. Maybe I just heard about it from MDF.

Yes it was... I couldn't find it anywhere online... but its just a basic repeating script... It works, its set to 2000 ticks if I understand it correctly, and in fortress mode that's just about perfect timing, I couldn't tell you how "optimized" it is.  Here you go:

Code: [Select]
class AutoFixHandedness

def initialize
end

def process
return false unless @running

# the colection of GLOVES
gloves=df.world.items.other[:GLOVES]
hand=0 # which hand  0=right, 1=left
count=0
gloves.each do |glove|
# if glove is unhanded (right and left = false, fix it
unless glove.handedness[0] or glove.handedness[1]
#puts glove.id
glove.handedness[hand] = true
hand ^= 1 # switch hand for next glove
count += 1
end
end

puts "Found #{count} unhanded glove(s)." unless count == 0

end

def start
@onupdate = df.onupdate_register('autofixhandedness', 2000) { process }
@running = true
@item_next_id = 0
end

def stop
df.onupdate_unregister(@onupdate)
@running = false
end

def status
@running ? 'Running.' : 'Stopped.'
end

end

case $script_args[0]
when 'start'
    $AutoFixHandedness = AutoFixHandedness.new unless $AutoFixHandedness
    $AutoFixHandedness.start

when 'end', 'stop'
    $AutoFixHandedness.stop

else
    if $AutoFixHandedness
        puts $AutoFixHandedness.status
    else
        puts 'Not loaded.'
    end
end

Quote
new information... apparently dfhack persistent created tables are deleted when a map site is abandoned, at least my test map was doing that... I just removed the line of code and the whole thing returned to normal operation all together, as the saved counter disappeared when I abandoned the fortress.  is that as intended?  I'm going with it at the moment, and stick to this fix, unless someone has some other
I don't think that's intentional. Had you saved before abandoning? Persistent tables are still saved as histfigs, I believe, and those shouldn't normally be deleted when you abandon a fortress, as long as the world stays around.

yeah I had, and on abandon, it reset the counter when I claimed a new site on the same map.  I can try and do some more testing but It may be next week and I'll get back to you.  I've got a load of things I'm trying to accomplish between today and monday, so when I can, its back on my list.  I don't want to have to fix that set of scripts anymore...

Title: Re: DFHack 0.43.05-r1
Post by: lethosor on May 20, 2017, 09:07:58 am
Hmmm, I just checked one of my active reclaimed forts, df.global.world.world_data.active_site.entity_links and looked at the bottom of the list, numbers list the site id and relevant entity, usually player created/claimed site groups are near or at the end, went to that entity and grabbed this shot:
Spoiler (click to show/hide)
Isn't that it?
Yeah. Is that in assignments? I couldn't find it in assignments_by_type.

Quote
Oh yeah! Is there a simple way to recenter a screen on a unit or whatnot that I'm just a moron and overlooked? I couldn't figure out dfhack.screen.zoom() syntax at all though I tried feeding it my unit position, cursor position, unit id, and a couple other things.
dfhack.gui.revealInDwarfmodeMap() (it takes a df.coord, I believe). dfhack.screen.zoom() zooms the screen in and out.

Quote
Hmmm, there's an update screen check too isn't there? Was annoying trying out a "teleport to the cursor" hotkeyable script because if you have the cursor out of view you have to move before it will refresh your screen fully. Even tried having it just straight up list that tile as revealed through the dfhack.maps.getTileBlock(blah).designations[xmath][ymath] stuff with no luck.
Some tools that need that just feed CURSOR_DOWN_Z and CURSOR_UP_Z to the dwarfmode screen, although that doesn't work at the lowest z-level. I've been meaning to add something to the Gui module to handle that appropriately.

Yes it was... I couldn't find it anywhere online... but its just a basic repeating script... It works, its set to 2000 ticks if I understand it correctly, and in fortress mode that's just about perfect timing, I couldn't tell you how "optimized" it is.  Here you go:
Is there a reason why MDF needs it? I'm fine with including it, but I don't want to enable it by default unless it fixes something that comes up in vanilla often.

Edit: also, I don't see anything particularly wrong with the formatting...

Quote
yeah I had, and on abandon, it reset the counter when I claimed a new site on the same map.  I can try and do some more testing but It may be next week and I'll get back to you.  I've got a load of things I'm trying to accomplish between today and monday, so when I can, its back on my list.  I don't want to have to fix that set of scripts anymore...
Weird. I don't see an obvious reason why it would be doing that. I'll look into it, though.
Title: Re: DFHack 0.43.05-r1
Post by: Amostubal on May 20, 2017, 09:15:34 pm
Quote
Yes it was... I couldn't find it anywhere online... but its just a basic repeating script... It works, its set to 2000 ticks if I understand it correctly, and in fortress mode that's just about perfect timing, I couldn't tell you how "optimized" it is.  Here you go:

Is there a reason why MDF needs it? I'm fine with including it, but I don't want to enable it by default unless it fixes something that comes up in vanilla often.

Edit: also, I don't see anything particularly wrong with the formatting...

simply put its not a vanilla issue as much as its a modder issue.  Basically any time you produce gloves from reactions they are unhanded.  so if you mod a lot of reactions in as MDF has, multiple times (craft full armor sets, mass productions, custom shops, specialty glove sets, etc.), this fixes that without having to add a reaction-trigger for every reaction that has gloves to run a correction.  I was just surprised, it wasn't a part of the repo, and I yeah I wouldn't have it enabled by default.

really it just needs some documentation added to it on the second part... thats what I meant for about not being DFHack-esque.
Title: Re: DFHack 0.43.05-r1
Post by: Max™ on May 20, 2017, 11:39:43 pm
Hmmm, I just checked one of my active reclaimed forts, df.global.world.world_data.active_site.entity_links and looked at the bottom of the list, numbers list the site id and relevant entity, usually player created/claimed site groups are near or at the end, went to that entity and grabbed this shot:
Spoiler (click to show/hide)
Isn't that it?
Yeah. Is that in assignments? I couldn't find it in assignments_by_type.
entities[k].positions.own had that, .assignments just lists the histfig that it's linked to, never even thought to check assignments_by_type actually.
Quote
Quote
Oh yeah! Is there a simple way to recenter a screen on a unit or whatnot that I'm just a moron and overlooked? I couldn't figure out dfhack.screen.zoom() syntax at all though I tried feeding it my unit position, cursor position, unit id, and a couple other things.
dfhack.gui.revealInDwarfmodeMap() (it takes a df.coord, I believe). dfhack.screen.zoom() zooms the screen in and out.
That'll work even if not in dwarf mode?

Quote
Quote
Hmmm, there's an update screen check too isn't there? Was annoying trying out a "teleport to the cursor" hotkeyable script because if you have the cursor out of view you have to move before it will refresh your screen fully. Even tried having it just straight up list that tile as revealed through the dfhack.maps.getTileBlock(blah).designations[xmath][ymath] stuff with no luck.
Some tools that need that just feed CURSOR_DOWN_Z and CURSOR_UP_Z to the dwarfmode screen, although that doesn't work at the lowest z-level. I've been meaning to add something to the Gui module to handle that appropriately.
Yeah, I was trying to work out if I was just missing something or what, but then the lua api didn't mention anything remotely like what I was after.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on May 21, 2017, 04:37:40 pm
Quote
dfhack.gui.revealInDwarfmodeMap() (it takes a df.coord, I believe). dfhack.screen.zoom() zooms the screen in and out.
That'll work even if not in dwarf mode?
I wouldn't expect it to work in adventure mode, but I haven't checked.

I got the CURSOR_UP_Z / CURSOR_DOWN_Z idea from gui/liquids.lua. There are a couple plugins that use it too (mousequery?).
Title: Re: DFHack 0.43.05-r1
Post by: expwnent on May 21, 2017, 09:27:51 pm
Old thread locked to avoid confusion.
Title: Re: DFHack 0.43.05-r1
Post by: necros on May 23, 2017, 01:55:13 pm
Hello, wasn't sure where to put this and I haven't see anyone talk about this, but can someone explain why doors, tables and I guess other furniture are built with coke when they are put down in planning mode?
By coke, I mean they haul bars of coke to the location and then create a door or table from scratch!  I can deconstruct it and I get bars of coke back...  I've never seen this behaviour before.

Planning mode was working normally a while ago where it would wait until I'd build the funiture item and then a dwarf would go haul the constructed item to the spot and install it.  But suddenly (and I'm not sure exactly when as 'coke bar' furniture looks like gabbro) any planned furniture immediately gets made out of coke bars...  and it's always coke bars.  Any ideas?
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on May 23, 2017, 02:23:34 pm
I haven't seen that happen before. What DFHack version are you using?
Edit: I can't reproduce it in DFHack 0.43.05-r1, even if there aren't any tables available (and coke bars are available).
Title: Re: DFHack 0.43.05-r1
Post by: necros on May 23, 2017, 03:51:27 pm
Right, sorry I should have said all the technical stuff :)

I'm using the LNP (PeridexisErrant's Starter Pack 0.43.05-r03) which has DF 43.05 along with DFHack 0.43.05-r1 (thread: http://www.bay12forums.com/smf/index.php?topic=126076.0)

To be clear, I have the min quality set to ordinary and filter set to *any.  I have say 4 beds prebuilt.  I place 1 bed down in planning mode and a dwarf hauls a bar of coke over.

I don't think this happens on a new game.  I feel like I did something at some point that triggered this behaviour because it reliably does this as soon as I load up the save (even if I already have the furniture constructed).  But when I load an earlier save, it doesn't happen and dwarfs will wait until I construct a bed even if there is coke bars available.

I tried forbidding all my coke bars from the stocks screen.  When they are forbidden, dwarfs properly use normal constructed beds.   After unforbidding, it seems this has fixed the behaviour...  Very strange!!!  I'll post again if anything interesting happens...

Title: Re: DFHack 0.43.05-r1
Post by: lethosor on May 23, 2017, 06:58:17 pm
Right, sorry I should have said all the technical stuff :)

I'm using the LNP (PeridexisErrant's Starter Pack 0.43.05-r03) which has DF 43.05 along with DFHack 0.43.05-r1 (thread: http://www.bay12forums.com/smf/index.php?topic=126076.0)
Thanks :)
I asked because DFHack 0.43.05-alpha3 had several bugs related to planning mode (and other things) - planned buildings disappearing instantly or being unbuildable, for example.
Quote
To be clear, I have the min quality set to ordinary and filter set to *any.  I have say 4 beds prebuilt.  I place 1 bed down in planning mode and a dwarf hauls a bar of coke over.

I don't think this happens on a new game.  I feel like I did something at some point that triggered this behaviour because it reliably does this as soon as I load up the save (even if I already have the furniture constructed).  But when I load an earlier save, it doesn't happen and dwarfs will wait until I construct a bed even if there is coke bars available.

I tried forbidding all my coke bars from the stocks screen.  When they are forbidden, dwarfs properly use normal constructed beds.   After unforbidding, it seems this has fixed the behaviour...  Very strange!!!  I'll post again if anything interesting happens...
Yeah, that is weird. Let us know if you can reproduce it again, and upload the save if you can.
Title: Re: DFHack 0.43.05-r1
Post by: MLP Pandemic on May 26, 2017, 01:23:19 am
Absolutely fantastic. Please accept a gift of hundreds of sacrificed elf buttocks encircled with a useless mineral.
Title: Re: DFHack 0.43.05-r1
Post by: krisslanza on June 01, 2017, 02:18:32 pm
If you use the autoassign DFHack thing from LNP, how does it actually decide when to let things Fish? If I try to manually assign labors, it naturally unassigns them, and I'm not sure how to make it turn someone to fishing.

Or should I just turn that hack off and do it the old fashion, manual way?
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 01, 2017, 02:37:15 pm
If you use the autoassign DFHack thing from LNP, how does it actually decide when to let things Fish? If I try to manually assign labors, it naturally unassigns them, and I'm not sure how to make it turn someone to fishing.

Or should I just turn that hack off and do it the old fashion, manual way?
"The autoassign DFHack thing" is vague, although since you mentioned labors, I assume you mean labormanager (which is similar to autolabor, but different). I think if you mouse over that option in PyLNP, you'll get a tooltip with a more descriptive name, but I haven't tried.

From the labormanager docs (http://dfhack.readthedocs.io/en/stable/docs/Plugins.html?highlight=labormanager#labormanager), it sounds like there are a couple things you need to do:
- Have a fishery
- Run "labormanager allow-fishing" in the DFHack console (and pay attention to the warning: "This tends to result in most of the fort going fishing")
Title: Re: DFHack 0.43.05-r1
Post by: krisslanza on June 01, 2017, 04:36:34 pm
If you use the autoassign DFHack thing from LNP, how does it actually decide when to let things Fish? If I try to manually assign labors, it naturally unassigns them, and I'm not sure how to make it turn someone to fishing.

Or should I just turn that hack off and do it the old fashion, manual way?
"The autoassign DFHack thing" is vague, although since you mentioned labors, I assume you mean labormanager (which is similar to autolabor, but different). I think if you mouse over that option in PyLNP, you'll get a tooltip with a more descriptive name, but I haven't tried.

From the labormanager docs (http://dfhack.readthedocs.io/en/stable/docs/Plugins.html?highlight=labormanager#labormanager), it sounds like there are a couple things you need to do:
- Have a fishery
- Run "labormanager allow-fishing" in the DFHack console (and pay attention to the warning: "This tends to result in most of the fort going fishing")

On LNP it specifically calls it "Automatic Job Assignments", which seems to just automate labor assignments.
Thanks though. Guess I'll just need to stop being lazy and actually manually assign things instead of just having it on automatic...
Title: Re: DFHack 0.43.05-r1
Post by: Snafu on June 01, 2017, 07:59:53 pm
If you don't have a fishery no dwarves will autofish..
Title: Re: DFHack 0.43.05-r1
Post by: Moonshine Fox on June 03, 2017, 01:06:15 pm
I can't find anything about this in any bug tracker or thread about DFHack, but planning mode seem to be utterly broken.

Steps to reproduce:

Start a new fort.
Dig in/down to be inside.
b-b to build a bed.
P to switch to planning mode.
Place bed, instant segfault.

Code: [Select]
dfhack: line 66: 16014 Segmentation fault      (core dumped) setarch i386 -R env LD_PRELOAD="$PRELOAD_LIB" ./libs/Dwarf_Fortress "$@"
Any ideas? Is it something I'm missing to install, or is this a DFHack bug? I'm running 64 bit Arch Linux with multilib libraries installed.
DFHack version 0.43.05-alpha4 (release) on x86_64
DF is version 0.43.05-4 on x86_64
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 03, 2017, 03:02:06 pm
There was an issue almost like that reported in alpha3. I'd be surprised if it was happening in alpha4, but I would try upgrading to r1 and see what happens.
Title: Re: DFHack 0.43.05-r1
Post by: Moonshine Fox on June 03, 2017, 03:10:56 pm
There was an issue almost like that reported in alpha3. I'd be surprised if it was happening in alpha4, but I would try upgrading to r1 and see what happens.

I downloaded the latest (r1) from git, ran it and it works now. Apparently alpha4 was the latest in the AUR (Arch User Repository), and r1 wasn't uploaded and packaged yet. But yes, r1 fixed the problem. Thanks for the headsup!
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 03, 2017, 03:21:58 pm
Oh, there was a different issue fixed in beta1 (https://github.com/DFHack/dfhack/releases/tag/0.43.05-beta1) that was just occurring on Linux (the changelog mentions automaterial, but the bug probably affected buildingplan too).
Title: Re: DFHack 0.43.05-r1
Post by: Max™ on June 03, 2017, 04:31:30 pm
I didn't even know the aur had a dfhack build, I just use the arch df install as a base for the graphics fixes and slap the rest of my stuff on top when it's available.
Title: A bug with "source"?
Post by: Tournesol on June 03, 2017, 05:19:54 pm
TL;DR: Blood appeared where water created by "source" fell through a grate.

I wanted to cheat myself to a mist generator using source, this is the setup:
The idea is to have mist on level z.
In a closed chamber on level z+1, "source add water" on a tile. The water then falls through grates to level z, and then down (through grates on level z) to another closed chamber on level z-1, where there is a tile with "source add water 0".
On some of the grates on level z, blood stains (spatterings) appear.
This blood is stated as coming from a certain giant who was killed (game-)years ago.
It seems to me that this blood ought not to appear.

Using the current PeridexisErrant Starter Pack on Windows 7. Ask for a copy of the save and you shall have it.

Apolgies for not reporting on Github, but they require account creation.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 03, 2017, 08:01:51 pm
I'm not entirely sure how spatters work, but I think I've seen things like that happen in vanilla before. Whatever it is, I doubt it has much to do with "source". You could try diverting a river or creating more water using "gui/liquids" (or "liquids") and see if more blood shows up. Maybe the grate has blood on it, although I'm not sure if that's possible.
Title: Re: DFHack 0.43.05-r1
Post by: Amostubal on June 03, 2017, 08:28:35 pm
blood spatter is insidious... remaining on objects for years waiting to be rehydrated and passed around again... I've seen such things many times... a dwarf will clean the floors and walls... he may clean himself, but not very well without soap.  a dwarf never cleans the spatters off of stuff in storage, which might have got the spatter when a dwarf stored it in the stockpile... later someone picked it up walked past the mist generator and boom splatter everywhere.  I'd use clean in dfhack and use it to get rid of splatters on items and the maps.  and then see if it comes back.
Title: Re: DFHack 0.43.05-r1
Post by: Tournesol on June 04, 2017, 02:26:15 am
... I doubt it has much to do with "source". You could try diverting a river or creating more water using "gui/liquids" (or "liquids") and see if more blood shows up. Maybe the grate has blood on it, although I'm not sure if that's possible.
OK, I'll do some !!SCIENCE!!. May be a while until I report back, though.

blood spatter is insidious... remaining on objects for years waiting to be rehydrated and passed around again...

I'd use clean in dfhack and use it to get rid of splatters on items and the maps.  and then see if it comes back.
So, even if the grates were made a long time after the Giant fight, and with lots of soap available, what Amostubal says is likely how it is. Especially as I have not yet used "clean" in this fortress, apart from a few "spotcleans" (inclkuding removing the spatter on the grates only to see it return, perhaps washed off another dwarf).
Title: Re: DFHack 0.43.05-r1
Post by: Amostubal on June 04, 2017, 10:58:37 am
yeah I've seen a dwarf go to a pond wash himself and still have the splatter on his clothes, just not himself.  I've seen them use soap and get  it off of everything they had in inventory and themselves.... and then walk through the splatter he just cleaned off and track it through an entire base.  I've seen a dwarf go to a shallow basin I made clean himself, then walk through that basin and track it down every hallway... eventually the game stops displaying it as it slowly reduces (I'm not so sure about the internals, but I'm guessing a counter is ticking off for it to dry).  but it never seems to self delete without actually cleaning with soap everything, or utilizing the clean command in dfhack...  at least you didn't have a raining blood embark. *que slayer music now*
Title: Re: DFHack 0.43.05-r1
Post by: Moonshine Fox on June 05, 2017, 12:26:53 am
I didn't even know the aur had a dfhack build, I just use the arch df install as a base for the graphics fixes and slap the rest of my stuff on top when it's available.
This is what I do as well now. But I used the AUR just for the fun of it. But it seems slow to update, and I'm usually very bleeding edge on DF.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 06, 2017, 08:25:54 pm
Last week I was working on getting TwbT to work with other DFHack tools better, without having to replace some DFHack-provided plugins. As a bonus, it works with some GUI scripts now too!

Spoiler: gui/siege-engine (click to show/hide)

Spoiler: gui/guide-path (click to show/hide)

Spoiler: devel/unit-path (click to show/hide)

Mifki also fixed some issues with overlays (e.g. Lua sidebars) hiding the map in fortress mode completely, so things like gui/liquids should be usable now.

Spoiler: gui/liquids (click to show/hide)


Spoiler: gui/room-list (click to show/hide)

Spoiler: gui/mechanisms (click to show/hide)

Spoiler: gui/power-meter (click to show/hide)

Spoiler: gui/workshop-job (click to show/hide)
Title: Re: DFHack 0.43.05-r1
Post by: Amostubal on June 06, 2017, 08:33:13 pm
well those are pretty lethosor.  I can't wait for r2 now. lol
Title: Re: DFHack 0.43.05-r1
Post by: scamtank on June 06, 2017, 09:02:30 pm
Oh hell yeah. You can't... well actually I think you can imagine exactly how much that blind mode has been grinding my gears.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 08, 2017, 11:23:17 pm
In the process of getting sidebars to work with TwbT, I figured out how sidebars work, so here's a front-end for the "teleport" script ("gui/teleport"):

Spoiler: Selecting a unit (click to show/hide)
Spoiler: Use with caution (click to show/hide)
Title: Re: DFHack 0.43.05-r1
Post by: PatrikLundell on June 09, 2017, 02:56:23 am
That sidebar integration looks rather handy. I hope you can share the knowledge of how it works (a couple of working examples may very be all that's needed for that, unless there are caveats you have to take into consideration).
Title: Re: DFHack 0.43.05-r1
Post by: Max™ on June 10, 2017, 06:55:22 am
Oh shit I found something I have looked for periodically with no luck, while trying to get a script together to let you pick some more stuff while setting up an adventurer, like your starting site/deity/etc right?

One of the unks back in the adventurer subscreen happened to catch my eye because, man... those values look really familiar... but surely it couldn't be THE FUCKING APPEARANCE AND SIZE MODIFIERS!
Spoiler (click to show/hide)
So naturally I'll get around to poking at them some more and see about getting a pull request in, but damn, that is NOT what I expected to find and I have no idea how I missed it because I'm sure I've been over that unk_324 entry.
Title: Re: DFHack 0.43.05-r1
Post by: Gorobay on June 10, 2017, 08:23:02 am
unk_324 is indeed the appearance modifiers. It was identified in pull request #190 (https://github.com/DFHack/df-structures/pull/190), but there are still some unknown fields.
Title: Re: DFHack 0.43.05-r1
Post by: Droggarth on June 10, 2017, 08:21:01 pm
...but surely it couldn't be THE FUCKING APPEARANCE AND SIZE MODIFIERS!

We'll finally have a chance one day to customize our adventurers after the initial creation of them? O_O

If so then so much yes from me. I still get OCD about getting my character's facial descriptions right and even when RNG does get it right somewhat I've already wasted either an hour or two of my time so I avoid the entire damn thing by just blunt-forcing my Ischrotaur god-race to look the same each time due to set-in-stone lines in the raw files, I'm the only one anyway in the game who exists as that particular sentient-super-being.

But still, I'd love to change appearance and body sizes mid-game when I start not liking something or find something off-putting. I tend to alter my character looks multiple times in other games until I find/alter something I eventually end up using always.
Title: Re: DFHack 0.43.05-r1
Post by: Max™ on June 10, 2017, 08:37:09 pm
Yeah, once I get rested I'll poke around more at trying to get a general advedit.lua script set up with options for manipulating your site/deity/entity/appearance during creation, and add in the values/skills/attributes editing on top of that for general use later.
unk_324 is indeed the appearance modifiers. It was identified in pull request #190 (https://github.com/DFHack/df-structures/pull/190), but there are still some unknown fields.
Well naturally I just started getting back into a scripty mood so I missed that one, and several of them depend on the creature raw so we won't be able to have like nose_length and ear_height due to the ones populated from the creature, but unk_7[0] is height, unk_7[1] is broadness, unk_11 is the creature_mat number for the following tissues, in this case hair (24) for my modded dwarves (440), unk_12 is the hair/hair/sideburn/sideburn/beard/moustache styles, unk_13 is the hair/hair/sideburn/sideburn/beard/moustache style types, unk_14 is tissue length but weirdly spaced so [4] and [6] were hair length, [5] was 0, same for the other tissues, unk_16 is hair/skin/eye colors.

Incidentally, I've been driving myself nuts trying to get names.lua working again, the way mifki showed me:
local blah = df.new(df.viewscreen_setupadventurest) ; blah.subscreen = 3
...doesn't work anymore.

I tried all sorts of different ways of trying to point it at the name selection screen like blah.child=df.viewscreen_layer_choose_language_namest:new() all the way to shit like trying to have the names screen declared first and then create a .parent as the viewscreen_setupadventurest which was pretty good at crashing df, but I've had shit for luck getting it to work outside of a weird case where it put a screen up properly which wanted the right inputs but it was blank and just prevented me from doing shit besides devel/pop-screen-ing it away.
Title: Re: DFHack 0.43.05-r1
Post by: Eric Blank on June 10, 2017, 09:39:33 pm
Hey, I'm having some trouble with DFhack in conjunction with my Spellcrafts mod. Specifically, the alchemy labor shows up red in the in-game menu with dfhack installed and cannot be activated for dwarves. I was wondering why this is, as in why is that particular job not available? I can obviously change the reactions to use some other labor if need be.
Title: Re: DFHack 0.43.05-r1
Post by: Max™ on June 10, 2017, 09:43:51 pm
Man, I've seen where that is blocked by something but I can't think of what.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 10, 2017, 10:50:14 pm
It's "tweak block-labors". Manipulator also does that, and other tools may use the same check.

The issue is that your civ isn't allowed to perform that labor. It may have something to do with the PERMITTED_JOB (http://dwarffortresswiki.org/index.php/DF2014:Entity_token#PERMITTED_JOB) token, although DFHack appears to be checking for allowed labors specifically, not professions (maybe allowed labors are computed in-game).
Title: Re: DFHack 0.43.05-r1
Post by: Eric Blank on June 10, 2017, 11:33:20 pm
Alright. Im not even sure theres an alchemist profession, but if there is then adding it to the list of valid professions in the entity file should fix it?
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 11, 2017, 07:22:33 am
I found a reference to [PERMITTED_JOB:ALCHEMIST] in another thread, so that might be it. Alternatively, maybe permitting a reaction that increases the alchemy skill would work too. Or you could just disable the tweak, which should allow you to at least assign the labor.

Sorry I'm not able to be more helpful. If you do find something that works, we could add it to the documentation.

Edit: another thread: http://www.bay12forums.com/smf/index.php?topic=110704.msg7053207;topicseen#msg7053207
Title: Re: DFHack 0.43.05-r1
Post by: Gorobay on June 11, 2017, 01:23:09 pm
Well naturally I just started getting back into a scripty mood so I missed that one, and several of them depend on the creature raw so we won't be able to have like nose_length and ear_height due to the ones populated from the creature, but unk_7[0] is height, unk_7[1] is broadness, unk_11 is the creature_mat number for the following tissues, in this case hair (24) for my modded dwarves (440), unk_12 is the hair/hair/sideburn/sideburn/beard/moustache styles, unk_13 is the hair/hair/sideburn/sideburn/beard/moustache style types, unk_14 is tissue length but weirdly spaced so [4] and [6] were hair length, [5] was 0, same for the other tissues, unk_16 is hair/skin/eye colors.
unk_7[0] and unk_7[1] are not height and broadness: they are the first and second body modifiers. As it turns out, those are commonly height and broadness, but you have to look up the caste’s body_appearance_modifier to know for sure. Similarly, to determine nose length and ear height, consult unk_8 with reference to the caste’s bp_appearance.modifiers.
Title: Re: DFHack 0.43.05-r1
Post by: Eric Blank on June 12, 2017, 12:18:30 am
I found a reference to [PERMITTED_JOB:ALCHEMIST] in another thread, so that might be it. Alternatively, maybe permitting a reaction that increases the alchemy skill would work too. Or you could just disable the tweak, which should allow you to at least assign the labor.

Sorry I'm not able to be more helpful. If you do find something that works, we could add it to the documentation.

Edit: another thread: http://www.bay12forums.com/smf/index.php?topic=110704.msg7053207;topicseen#msg7053207

Adding that to the entity did work. Thanks!
Title: Re: DFHack 0.43.05-r1
Post by: Roses on June 13, 2017, 10:37:02 am
So I am trying to work on the robustness of modtools/create-unit (still occasionally getting crashes when using it) and was wondering if anyone else that uses it has documented any crashes? I think I know what causes a couple of them, but I'm hoping to eliminate all crashes (as I would like to use it extensively). So if you ever use it and get a crash could you please tell me what command you used, if your game was paused or running when you used it, game mode, and anything else you can think of.
Title: Re: DFHack 0.43.05-r1
Post by: Amostubal on June 13, 2017, 11:14:57 am
So I am trying to work on the robustness of modtools/create-unit (still occasionally getting crashes when using it) and was wondering if anyone else that uses it has documented any crashes? I think I know what causes a couple of them, but I'm hoping to eliminate all crashes (as I would like to use it extensively). So if you ever use it and get a crash could you please tell me what command you used, if your game was paused or running when you used it, game mode, and anything else you can think of.

I did a lot of work on it,  I found that a lot of the older errors, where it would fail half way through came through teleport, so I just moved the cursor instead.  As for crashes... well I've mainly seen crashes when a script tries to push more than 1 unit at a time into the game, It seems like your chance of crash increases along by the number of units being created at once.  Where 1 at a time really doesn't crash often (1 in 50 or better), but if your tossing 10 out, your going to crash around 25% of the time.  I've had 20 successful once, after 3 attempts, so I call that a 50% fail rate.  I avoid making more than 10 at a time, although if it ever got to the point of not crashing I'd do more.... I use them in active play mode through reaction-triggers so its more of an actual modded in game mechanic, than just playing with it.  I've even considered maybe seeing if a delay script that could queue up create-unit calls with wait times could be used to reduce the crashes... the issues is what exactly is causing the crash.  When I did paused testing I couldn't really get it to crash to often, even when using a script that creates multiple units.  It seems to be when I let time run or step through that it fails in the first tick.

additionally since this script can be paired with "create-item", the unit can be given another civ, and invader tags, I did a little work creating mini 1 man invaders out of this for a proof of concept script created force invasion, made it about half way through it, but abandoned it when I realized I could effectively call for a 50 man army in waves of 10 and effectively guarantee a crash.  So I shelved it until someone with a little better idea of whats going on could fix the crash issues.
Title: Re: DFHack 0.43.05-r1
Post by: Roses on June 13, 2017, 11:48:45 am
Yes, one of the more common crashes is creating a unit outside of the game dimensions while unpaused, this is helped by setting the cursor to a valid position so that the unit is spawned within the game boundaries. I am also experimenting with pausing the game, creating the unit, and then unpausing, it seems to help ease the crashes. I'm thinking about putting in a 3 tick delay (maybe longer) between creating multiple units at once. So that the game isn't trying to assign pathing (and other calculations) to 20 new units at once.
Title: Re: DFHack 0.43.05-r1
Post by: danamlund on June 13, 2017, 12:27:13 pm
Another small bug with create-unit I found.
When invoking create-unit while a modal dialog is visible, dwarf fortress is left in a pseudo arena-mode.
This is most visible with the dwarf unit lists only showing names and not professions.

I also noticed slightly fewer crashes by invoking create-unit a bunch of times inside a dfhack.with_suspend(..). But this is no big surprise.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 13, 2017, 12:31:09 pm
Another small bug with create-unit I found.
When invoking create-unit while a modal dialog is visible, dwarf fortress is left in a pseudo arena-mode.
This is most visible with the dwarf unit lists only showing names and not professions.

I also noticed slightly fewer crashes by invoking create-unit a bunch of times inside a dfhack.with_suspend(..). But this is no big surprise.

Please report bugs in the GitHub issue tracker (http://github.com/DFHack/dfhack/issues). (Bugs reported in this thread can be buried sometimes.)
(Really. I wasn't aware this was an issue at all.)

Also, I've never had create-unit crash, although I haven't used it a lot, or without a cursor. What types of units are you creating, and what options are you using? (Roses: I realize you asked that yourself, but it would be helpful to know what you're using too.)

It should go without saying, but please make a pull request if you figure out how to fix the issue(s) you're having, or at least let us know about the fixed version so it doesn't get left out.

Edit: thanks - that bug report was helpful. (Also, thanks to whoever posted about the masspit.rb bug as well.)

I also noticed slightly fewer crashes by invoking create-unit a bunch of times inside a dfhack.with_suspend(..). But this is no big surprise.
I missed this the first time - with_suspend shouldn't be necessary. Where are you running the script from?
Title: Re: DFHack 0.43.05-r1
Post by: danamlund on June 13, 2017, 03:38:32 pm
I missed this the first time - with_suspend shouldn't be necessary. Where are you running the script from?
It is a lua script started manually through the dfhack console (link later in post). It forces a pause before calling create-unit.

additionally since this script can be paired with "create-item", the unit can be given another civ, and invader tags, I did a little work creating mini 1 man invaders out of this for a proof of concept script created force invasion, made it about half way through it, but abandoned it when I realized I could effectively call for a 50 man army in waves of 10 and effectively guarantee a crash.  So I shelved it until someone with a little better idea of whats going on could fix the crash issues.

I made a similar script that spawns invaders. My scripts fails about half the time when spawning ~60 units with a few pieces of equipment and a few skills. (see http://www.bay12forums.com/smf/index.php?topic=164458.0 )

I ran some experiments to see how often it fails and which errors I got.
Two of the errors I saw are dfhack related. But the majority are dwarf fortress segfaulting.

Can we get interesting data from a segfault or does the code obfuscation prevent this? Are these errors helpful?

Anyway, here are my experiment results:
* Experiment 1
save: df6/r1
experiment: unpause and spawn (strength=1000, ~60 goblins)
Worked: 6, segfault: 4

* Experiment 2
save: df6/r2
experiment: unpause and spawn (strength=1000, ~60 goblins)
Worked: 8, segfault: 1, free: 1

* Experiment 3
save: df6/r2
experiment: keep paused and spawn (strength=1000, ~60 goblins)
Worked: 6, segfault: 3, gui-loop#1: 1

Errors:
* segfault:
Code: [Select]
Segmentation fault (core dumped)

* free:
Code: [Select]
[DFHack]# *** Error in `./libs/Dwarf_Fortress': free(): invalid next size (normal): 0x00007fffc4031b30 ***
                    Aborted (core dumped)

* gui-loop #1
Code: [Select]
./hack/lua/gui.lua:177: attempt to compare nil with number
stack traceback:
        ./hack/lua/gui.lua:177: in method 'inClipGlobalXY'
        ./hack/lua/gui.lua:408: in method 'getMousePos'
        ./hack/lua/gui/widgets.lua:384: in method 'onRenderBody'
        ./hack/lua/gui.lua:460: in method 'render'
        ./hack/lua/gui.lua:447: in method 'renderSubviews'
        ./hack/lua/gui.lua:462: in method 'render'
        ./hack/lua/gui.lua:563: in function <./hack/lua/gui.lua:562>
        [C]: in ?
... repeating for ever

Other errors I saw before writing down experimental results:

* linked list
Code: [Select]
*** Error in `./libs/Dwarf_Fortress': malloc(): smallbin double linked list corrupted: 0x00007fffc4072070 ***
Aborted (core dumped)

* gui loop #2
Code: [Select]
./hack/lua/gui.lua:158: attempt to perform arithmetic on a nil value (field '?')
stack traceback:
        ./hack/lua/gui.lua:158: in local 'fun'
        ./hack/lua/class.lua:98: in upvalue 'invoke_after_rec'
        ./hack/lua/class.lua:94: in upvalue 'invoke_after_rec'
        ./hack/lua/class.lua:127: in function <./hack/lua/class.lua:112>
        (...tail calls...)
        ./hack/lua/gui.lua:563: in function <./hack/lua/gui.lua:562>
        [C]: in ?
... repeating for ever

Conclusions:
We get many different errors even though the experiments were pretty similarly executed.

I might have seen fewer more errors when spawning units after waiting for 2 seconds after loading a game, but that might just be wishful thinking.

These are very limited experiments. I cannot say if the crash rate is higher or lower with other saves and in other situations.

Do anyone have any ideas for ways to reduce the crash rate?
Title: Re: DFHack 0.43.05-r1
Post by: Hesperid on June 13, 2017, 09:34:27 pm
So, now that the unit.relations structure has been dispersed so that pregnancy variables are directly under the unit, and references to other unit (or histfig?) IDs are in a new structure called "relationship_ids", I happened to notice that the names of the fields of that structure begin with capital letters. I.e. we've now got

unit.relationship_ids.Lover

unit.relationship_ids.Spouse

...

Off-hand I'm not aware of anything else in the DFhack API that has capital letters in any field names. It might be a good idea to nip this in the bud, because if we start on the road that only some of them get capital letters in them, nobody is going to remember which.
Title: Re: DFHack 0.43.05-r1
Post by: Quietust on June 13, 2017, 10:35:47 pm
unit.relationship_ids.Lover
unit.relationship_ids.Spouse
Off-hand I'm not aware of anything else in the DFhack API that has capital letters in any field names.

Those aren't field names - those are array indices (i.e. they're actually "unit.relationship_ids[unit_relationship_type.Lover]" and "unit.relationship_ids[unit_relationship_type.Spouse]", and most of those are capitalized (and some are even all caps).
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 14, 2017, 08:23:00 am
To add to that, unit_relationship_type is an enum, and nearly all enum items are capitalized. In C++, your only option is "unit->relationship_ids[df::unit_relationship_type::Spouse]", which translates directly to "unit.relationship_ids[df.unit_relationship_type.Spouse]" in Lua - "unit.relationship_ids.Spouse" is equivalent and is just supported to make Lua scripts more readable. (It's also equivalent to "unit.relationship_ids[1]", which is much less readable.) Changing the array indices to lowercase wouldn't make sense because it wouldn't match the case of the enum items.

Also, I'd like to point out that we didn't have much of a choice when it came to removing unit.relations - it's likely that the "relations" compound had never existed at all in DF (or at least not in the way we had it set up). We had to change it to get unit fields to line up with 64-bit DF properly.

Edit: more examples of similar things:

world.buildings.other
world.items.other
world.units.other
world.stockpile.num_jobs
world.stockpile.num_haulers
world.status.slot_id_used (this is a good example of an enum with gaps - those fields can only be accessed by numerical indices in Lua)
world.status.slot_id_idx1 (same)
world.status.slot_id_idx2 (same)
world.profession_skills.primary
world.profession_skills.secondary

Usually, the ones in all caps are names from the raws, and the rest are only capitalized.
Title: Re: DFHack 0.43.05-r1
Post by: Hesperid on June 14, 2017, 05:10:18 pm
The instance I was thinking of when referring to previous convention was that the physical attributes have been fully capitalized as STRENGTH etc.

In C++, your only option is "unit->relationship_ids[df::unit_relationship_type::Spouse]", which translates directly to "unit.relationship_ids[df.unit_relationship_type.Spouse]" in Lua - "unit.relationship_ids.Spouse" is equivalent and is just supported to make Lua scripts more readable. (It's also equivalent to "unit.relationship_ids[1]", which is much less readable.) Changing the array indices to lowercase wouldn't make sense because it wouldn't match the case of the enum items.

Usually, the ones in all caps are names from the raws, and the rest are only capitalized.

Thanks for this very detailed explanation for both the reasoning behind different caps styles used, and why what looks incongruent is only shorthand that appears in Lua (exclusively by the sound of it?).

I'm not complaining about the loss of relations, it only requires search-and-replace level maintenance in scripts.
Title: Re: DFHack 0.43.05-r1
Post by: Uzu Bash on June 18, 2017, 04:53:47 pm
As of this version using advfort to craft with items owned by a dwarven civ crashes the game. I found that this is fixed by removing general_ref_building_civzone_assignedst from general_refs. I don't know where that could be added into advfort.lua, but is this included in any other scripts? How would I write a quick function to find and remove this ref from my inventory items?


EDIT: nm the quick fix; moving the items out of warehouse and depot areas then offloading/reloading the map clears the ref.
Title: Re: DFHack 0.43.05-r1
Post by: PatrikLundell on June 19, 2017, 10:22:25 am
Does DFHack export any operation to change the display mode? I've found dfhack.screen.inGraphicsMode, but not any operation to change it. mifki must know how to do it to get TwbT to work, but is it an internal function to TwbT?
The usage I see for such an operation (outside of TwbT) is to change the mode to text when bringing up a DFHack display (such as e.g. gui/gm-editor) so the contents is legible, and then restore the mode to what it was on exit.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 19, 2017, 11:00:21 am
Does DFHack export any operation to change the display mode? I've found dfhack.screen.inGraphicsMode, but not any operation to change it. mifki must know how to do it to get TwbT to work, but is it an internal function to TwbT?
The usage I see for such an operation (outside of TwbT) is to change the mode to text when bringing up a DFHack display (such as e.g. gui/gm-editor) so the contents is legible, and then restore the mode to what it was on exit.
I'm not really sure what you're talking about. The concepts of a separate text and graphics font are entirely specific to TWBT, unless you're talking about truetype, which DFHack doesn't support. There's no "text mode" that DFHack could switch to. TWBT is far more complicated than that and handles graphics on its own.
Title: Re: DFHack 0.43.05-r1
Post by: scourge728 on June 19, 2017, 11:21:10 am
Did retiring my tavern and temple cause the dwarves that were using them to break? because most of them are just sitting there with "No Job" even though many of them have jobs, such as my animal trainers that are refusing to tame some of my baby animals for seemingly no reason

EDIT: I forgot to mention, I tried using things such as workNow, but they caused absolutely nothing to change
Title: Re: DFHack 0.43.05-r1
Post by: Hesperid on June 19, 2017, 12:05:02 pm
Did retiring my tavern and temple cause the dwarves that were using them to break?

Previously in your thread here (http://www.bay12forums.com/smf/index.php?topic=164565.msg7489330#msg7489330) you said using DFhack to retire your tavern and temple is what fixed this issue for you:

Quote
It appears what I needed to do was use DFhack to retire both my temple and tavern as that seems to have made them function now

So... which is it?
Title: Re: DFHack 0.43.05-r1
Post by: scourge728 on June 19, 2017, 12:09:06 pm
I THOUGHT it fixed the issue, because they tamed the giraffe's, the problem being they STOPPED taming things or doing ANYTHING else again, (for some reason they will imedietly jump to war/hunting training things and then go back to doing nothing even though they have hauling enabled and there are many things to haul and many bins to put them in) similar is true for all of the workers, they will do what I put in the workshops, but then go back to doing nothing, not even hauling and I don't know why
Title: Re: DFHack 0.43.05-r1
Post by: Hesperid on June 19, 2017, 12:13:26 pm
So if the problem surfaced before you used DFhack to try to fix it, why do you now think it was your attempt to fix it by DFhack that caused the problem?
Title: Re: DFHack 0.43.05-r1
Post by: scourge728 on June 19, 2017, 12:16:31 pm
Because other than the tamers, the broken dwarves were in the temple/tavern
Title: Re: DFHack 0.43.05-r1
Post by: PatrikLundell on June 19, 2017, 01:01:48 pm
Does DFHack export any operation to change the display mode? I've found dfhack.screen.inGraphicsMode, but not any operation to change it. mifki must know how to do it to get TwbT to work, but is it an internal function to TwbT?
The usage I see for such an operation (outside of TwbT) is to change the mode to text when bringing up a DFHack display (such as e.g. gui/gm-editor) so the contents is legible, and then restore the mode to what it was on exit.
I'm not really sure what you're talking about. The concepts of a separate text and graphics font are entirely specific to TWBT, unless you're talking about truetype, which DFHack doesn't support. There's no "text mode" that DFHack could switch to. TWBT is far more complicated than that and handles graphics on its own.
Well, given that a boolean function is defined, it ought to have some function, but I may very well be barking up the wrong tree regarding what that function is. (It's also use to set 'USE_GRAPHICS = dscreen.inGraphicsMode()' in the beginning of gui.lua).
Title: Re: DFHack 0.43.05-r1
Post by: Hesperid on June 19, 2017, 01:19:13 pm
Because other than the tamers, the broken dwarves were in the temple/tavern

Do they take jobs like "Drink" etc?  Do you have burrows?
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 19, 2017, 01:57:23 pm
Well, given that a boolean function is defined, it ought to have some function, but I may very well be barking up the wrong tree regarding what that function is. (It's also use to set 'USE_GRAPHICS = dscreen.inGraphicsMode()' in the beginning of gui.lua).
It does have a purpose - it returns what the GRAPHICS setting is in init.txt. See the Lua API documentation (https://dfhack.readthedocs.io/en/latest/docs/Lua%20API.html).
Quote from: https://dfhack.readthedocs.io/en/latest/docs/Lua%20API.html#screen-api
dfhack.screen.inGraphicsMode()

Checks if [GRAPHICS:YES] was specified in init.
Quote from: https://dfhack.readthedocs.io/en/latest/docs/Lua%20API.html#misc
USE_GRAPHICS

Contains the value of dfhack.screen.inGraphicsMode(), which cannot be changed without restarting the game and thus is constant during the session.
It's impossible to change without restarting DF because DF simply does not support changing that setting in-game. TWBT essentially reimplements a lot of pieces of libgraphics itself in order to accomplish something similar.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 19, 2017, 01:59:54 pm
Did retiring my tavern and temple cause the dwarves that were using them to break? because most of them are just sitting there with "No Job" even though many of them have jobs, such as my animal trainers that are refusing to tame some of my baby animals for seemingly no reason

EDIT: I forgot to mention, I tried using things such as workNow, but they caused absolutely nothing to change
This sounds like something that isn't DFHack-related. As far as I know, you can't use DFHack to retire a fortress. That's a vanilla feature.

If there's a reason why you posted about your issue in this thread, you'll need to be more specific about how exactly DFHack is affecting it.
Title: Re: DFHack 0.43.05-r1
Post by: scourge728 on June 19, 2017, 02:12:36 pm
Because other than the tamers, the broken dwarves were in the temple/tavern

Do they take jobs like "Drink" etc?  Do you have burrows?

They DO appear to be doing that, but despite that they mostly just sit in the area doing nothing at all, several of them are just sitting on top of each other and the animal tamers won't tame most of the baby cave crocodiles or 3 of the 4 baby dralthlas but they WILL train the newly caught cave crocodile and then go back to sitting still, slowly building up unmet needs, I HAD a burrow but that was for the trolls I modded to be trainable and I had to kill them and remove the burrow when I realized any animal trainer who tried to train them just stopped moving entirely to the point of slowly dehydrating to death if I let them, now they don't even do THAT or haul, although I know we have stockpile room because two dwarves are hauling things... I can't even tell if this is a glitch or if I'm just really unlucky (for reference about 50 dwarves are currently idlers out of my 120 dwarves total (and of ones that ARE working, most are either military or just repasturing the strays that keep immediately leaving the pasture (although I DO have a few that ARE doing things))
Title: Re: DFHack 0.43.05-r1
Post by: scourge728 on June 19, 2017, 02:13:31 pm
I didn't retire a fortress I retired a temple and a tavern IN the fortress, and I think that's DFhack because the pop-up I get when I hit the button has DFhack on it

EDIT: So, oddest thing, I was testing a theory(turned out to be incorrect) so I had saved and then reloaded but when I reloaded it.. the dwarves decided to start hauling and storing things again, but sadly the animal trainers still refuse to actually do their jobs, even the ones who as a test, I turned off all other labors just sit there I don't understand what happened since I had saved and reloaded before without this result....
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 19, 2017, 03:09:02 pm
I didn't retire a fortress I retired a temple and a tavern IN the fortress, and I think that's DFhack because the pop-up I get when I hit the button has DFhack on it
Oh. The only DFHack feature there is the confirmation. Vanilla DF allows you to delete locations, but does so instantly. DFHack's "confirm" plugin simply intercepts the key you pressed, and only passes it to DF if you confirm that you want to delete the location.
Title: Re: DFHack 0.43.05-r1
Post by: scourge728 on June 19, 2017, 03:15:28 pm
I see... So I'm going to assume my dwarves were just being dumb and my animal trainers just all hate baby animals or something
Title: Re: DFHack 0.43.05-r1
Post by: PatrikLundell on June 19, 2017, 04:30:34 pm
Well, given that a boolean function is defined, it ought to have some function, but I may very well be barking up the wrong tree regarding what that function is. (It's also use to set 'USE_GRAPHICS = dscreen.inGraphicsMode()' in the beginning of gui.lua).
It does have a purpose - it returns what the GRAPHICS setting is in init.txt. See the Lua API documentation (https://dfhack.readthedocs.io/en/latest/docs/Lua%20API.html).
Quote from: https://dfhack.readthedocs.io/en/latest/docs/Lua%20API.html#screen-api
dfhack.screen.inGraphicsMode()

Checks if [GRAPHICS:YES] was specified in init.
Quote from: https://dfhack.readthedocs.io/en/latest/docs/Lua%20API.html#misc
USE_GRAPHICS

Contains the value of dfhack.screen.inGraphicsMode(), which cannot be changed without restarting the game and thus is constant during the session.
It's impossible to change without restarting DF because DF simply does not support changing that setting in-game. TWBT essentially reimplements a lot of pieces of libgraphics itself in order to accomplish something similar.
Thanks lethosor! I suspected it was too easy to be true, and it was...
Title: Re: DFHack 0.43.05-r1
Post by: Max™ on June 19, 2017, 11:37:14 pm
Incidentally, I've been driving myself nuts trying to get names.lua working again, the way mifki showed me:
local blah = df.new(df.viewscreen_setupadventurest) ; blah.subscreen = 3
...doesn't work anymore.

I tried all sorts of different ways of trying to point it at the name selection screen like blah.child=df.viewscreen_layer_choose_language_namest:new() all the way to shit like trying to have the names screen declared first and then create a .parent as the viewscreen_setupadventurest which was pretty good at crashing df, but I've had shit for luck getting it to work outside of a weird case where it put a screen up properly which wanted the right inputs but it was blank and just prevented me from doing shit besides devel/pop-screen-ing it away.
Update: I didn't understand what that line mifki suggested was doing, so after pondering it I figured out I was a moron and what mifki did was show me how to make dfhack pull up the setup_adventurest screen and then fake input the key to bring up the custom name screen. Needed to use page = 7 instead of subscreen = 3 to get it working as it was, but since I was already getting a feel for shit I decided that, since I know shit about dialogs, I should obviously drive myself nuts trying to figure them out.

...then I checked the hack/lua/gui folder and came to learn it's just an editfield widget in a bitesize wrapper, and so:
Spoiler (click to show/hide)
No more -unit, -item, or -first flags necessary, it'll pick up the target from the relevant screens, and no need to run the script again to apply it, it'll apply it if the first name is changed, and it'll apply the full name on exit properly, so, yay!

Did a pull request (forgot how, fuck, did it backwards first try) with the updated names.lua and other scripts in there.
Title: Re: DFHack 0.43.05-r1
Post by: DaSwayza on June 20, 2017, 10:44:15 am
Not sure if this has come up recently, but I made a world with custom parameters, and was attempting to use CREATEITEM, and each time, no matter what I made, it would disappear upon unpausing, no matter what I attempt. Any thoughts/advice? Looks like this fort is by the books! lol
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 20, 2017, 10:46:44 am
Not sure if this has come up recently, but I made a world with custom parameters, and was attempting to use CREATEITEM, and each time, no matter what I made, it would disappear upon unpausing, no matter what I attempt. Any thoughts/advice? Looks like this fort is by the books! lol
That's strange, it's working fine for me. What DFHack build and platform are you using? What items did you try to create? Do you have a unit selected? Does it work if you run "createitem floor" first? Does it work in another location? What about another save?

There's also gui/create-item, which you could try, although I don't know if it would fix your issue. Createitem should definitely work.
Title: Re: DFHack 0.43.05-r1
Post by: Hesperid on June 20, 2017, 11:04:48 am
Not sure if this has come up recently, but I made a world with custom parameters, and was attempting to use CREATEITEM, and each time, no matter what I made, it would disappear upon unpausing, no matter what I attempt. Any thoughts/advice? Looks like this fort is by the books! lol

Since the item exists until you unpause the game, can you open it up in gm-editor and show us the flags? Particularly the garbage_collect flag, which specifically destroys any item as soon as the game is unpaused.
Title: Re: DFHack 0.43.05-r1
Post by: Rumrusher on June 21, 2017, 06:16:59 am
pondering about creating new worldgen events in adventure mode, like is it possible to just get an retired adventurer to be kidnapped by a night troll?
Title: Re: DFHack 0.43.05-r1
Post by: Amostubal on June 21, 2017, 01:54:30 pm
Not sure if this has come up recently, but I made a world with custom parameters, and was attempting to use CREATEITEM, and each time, no matter what I made, it would disappear upon unpausing, no matter what I attempt. Any thoughts/advice? Looks like this fort is by the books! lol

Since the item exists until you unpause the game, can you open it up in gm-editor and show us the flags? Particularly the garbage_collect flag, which specifically destroys any item as soon as the game is unpaused.

did you read the help file? If I remember right it says "createitem" must be run with a creature/unit selected and will place items at their feet.  If you don't the item instantly disappears when the game is unpaused...
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 21, 2017, 03:02:58 pm
That's incorrect. createitem was changed to allow creating items anywhere, and before that, creating items without a unit selected wasn't allowed at all (unless you were in the mode that allows you to create items in a building).
Title: Re: DFHack 0.43.05-r1
Post by: Max™ on June 21, 2017, 03:10:52 pm
Gonna look over those style/shortcut suggestions again now that I'm free, lethosor, btw.
Edit: think I got them all and pushed to the dfhack/scripts properly, I missed the change from the name-scripts style to the current fork>dfhack/scripts version completely.
pondering about creating new worldgen events in adventure mode, like is it possible to just get an retired adventurer to be kidnapped by a night troll?
Code: [Select]
df.global.world.history.events:new()
 df.global.world.history.events:insert('#',{new=df.history_event_hist_figure_abductedst,
year = *desired year*,
seconds = *desired tick in the year*,
id = df.global.hist_event_next_id,
target = *you*.id,
snatcher = *night troll*.id,
site = *your retired site*,
region = *uh, df.world_region.find(*a link to your df.global.world.world_data.region_map[k].sites[v].id=*your site*)*
*maybe? not sure what a viable shortcut for that is*
layer = *however the fuck you get the layer from the region link?*
}
)
df.global.hist_event_next_id = df.global.hist_event_next_id+1
Then you'd toss in the links to the relevant corrupting events I suppose?
Title: Re: DFHack 0.43.05-r1
Post by: Rumrusher on June 22, 2017, 04:39:34 pm
sweet probably adapt this into some kind of script that adds world changing events.
now to see if setting a dwarf to abduct someone causes their victims to turn into a dwarf?
hmm looks like this doesn't work, or well messing with the history logs doesn't convert a person.
so it something else.
also doesn't seem to pop up in legends either
Title: Re: DFHack 0.43.05-r1
Post by: Max™ on June 22, 2017, 04:54:55 pm
Hmmm, there are a few more links you'll need to add I guess, but that's the format I used to have artifakes show up properly in legends.
Title: Re: DFHack 0.43.05-r1
Post by: scourge728 on June 22, 2017, 11:38:45 pm
Didn't there used to be a command that would clear the dead unit list? what happened to that
Title: Re: DFHack 0.43.05-r1
Post by: Max™ on June 23, 2017, 03:29:02 am
Isn't it fix/dead-units?
Title: Re: DFHack 0.43.05-r1
Post by: assasin on June 23, 2017, 08:11:52 am
I downloaded dfhack source to play around with and damn the build process has been a mission. Current problem. It keeps trying to download a files for stonesense that don't seem to exist anymore. I'm trying a win32 build. I think I've traced where the problem is. I believe the problem is gna.org has shut down and so the files have disappeared into the aether.


dfhack\plugins\stonesense\CMakeLists.txt
Code: [Select]
# windows
ELSE(UNIX)
    SET(ALLEGRO_DOWNLOAD_DIR ${stonesense_SOURCE_DIR}/win${DFHACK_BUILD_ARCH})
    IF(DFHACK_BUILD_64)
        download_file("http://download.gna.org/allegro/allegro-unstable-bin/5.1.12/allegro-msvc2015-x64-5.1.12.zip"
                      ${ALLEGRO_DOWNLOAD_DIR}/allegro-msvc2015-x64-5.1.12.zip
                      "3abb0bd88251efde001a8b65fdf17683")
        execute_process(COMMAND ${CMAKE_COMMAND} -E tar xzf ${ALLEGRO_DOWNLOAD_DIR}/allegro-msvc2015-x64-5.1.12.zip
                        WORKING_DIRECTORY ${ALLEGRO_DOWNLOAD_DIR})
        download_file("http://download.gna.org/allegro/allegro-deps/1.2.0/allegro_deps-msvc2015-x64-1.2.0.zip"
                      ${ALLEGRO_DOWNLOAD_DIR}/allegro_deps-msvc2015-x64-1.2.0.zip
                      "eb8d0f4569b84c36bef3733b40b00c72")
        execute_process(COMMAND ${CMAKE_COMMAND} -E tar xzf ${ALLEGRO_DOWNLOAD_DIR}/allegro_deps-msvc2015-x64-1.2.0.zip
                        WORKING_DIRECTORY ${ALLEGRO_DOWNLOAD_DIR})
    ELSE()
        download_file("http://download.gna.org/allegro/allegro-unstable-bin/5.1.12/allegro-msvc2015-x86-5.1.12.zip"
                      ${ALLEGRO_DOWNLOAD_DIR}/allegro-msvc2015-x86-5.1.12.zip
                      "86e6aeea828743107dc1f3a3d562e53d")
        execute_process(COMMAND ${CMAKE_COMMAND} -E tar xzf ${ALLEGRO_DOWNLOAD_DIR}/allegro-msvc2015-x86-5.1.12.zip
                        WORKING_DIRECTORY ${ALLEGRO_DOWNLOAD_DIR})
        download_file("http://download.gna.org/allegro/allegro-deps/1.2.0/allegro_deps-msvc2015-x86-1.2.0.zip"
                      ${ALLEGRO_DOWNLOAD_DIR}/allegro_deps-msvc2015-x86-1.2.0.zip
                      "be096bfef256cb113e25dbb2eb7fd410")
        execute_process(COMMAND ${CMAKE_COMMAND} -E tar xzf ${ALLEGRO_DOWNLOAD_DIR}/allegro_deps-msvc2015-x86-1.2.0.zip
                        WORKING_DIRECTORY ${ALLEGRO_DOWNLOAD_DIR})


I have no experience in large projects or tools like git/automated builds/etc. I don't quite know the etiquette. I apologise if I've screwed u[ anywhere.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 23, 2017, 08:43:53 am
Yeah, it looks like that site is down. I'm not entirely sure where to get Allegro for Windows, then. Maybe https://github.com/liballeg/allegro5/releases would work, but those builds all contain "mingw" in their names, which worries me a bit. You might be better off disabling Stonesense for now unless you specifically want to work with it.
Title: Re: DFHack 0.43.05-r1
Post by: assasin on June 23, 2017, 09:31:54 am
Yeah, it looks like that site is down. I'm not entirely sure where to get Allegro for Windows, then. Maybe https://github.com/liballeg/allegro5/releases would work, but those builds all contain "mingw" in their names, which worries me a bit. You might be better off disabling Stonesense for now unless you specifically want to work with it.

Disabled stonesense and everything seems to work fine. Good enough for now I guess. Thanks.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 23, 2017, 09:41:53 am
islandofcalmness pointed me to here: https://web.archive.org/web/20170306031002/http://download.gna.org/allegro/

I won't be able to update Stonesense right away, but you should be able to find the files you need there. (You can download them and place them in CMake/downloads to have CMake recognize them, using the process for offline builds outlined in Compile.rst.)
Title: Re: DFHack 0.43.05-r1
Post by: scourge728 on June 23, 2017, 11:19:41 am
Isn't it fix/dead-units?
thank you
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 27, 2017, 10:54:27 pm
Had some fun working on an autogems UI yesterday. Next up is a similar one for autochop.

Spoiler: main view (click to show/hide)
Spoiler: diamonds (click to show/hide)
Spoiler: dark red gems (click to show/hide)
Spoiler: rough gems on the map (click to show/hide)
Title: Re: DFHack 0.43.05-r1
Post by: Atkana on June 28, 2017, 11:59:43 am
Can anybody work out a reason why this code continues after being cancelled, or is it a bug with repeat-util?
Code: [Select]
local blah = 1
local id = "foo"
local repeatUtil = require 'repeat-util'

local function doStuff()
print("Blah: " .. blah)
blah = blah +1
print("Blah is now " .. blah)
if blah > 10 then
print("Blah is more than 10. Stopping.")
print("Has supposedly cancelled = " .. tostring(repeatUtil.cancel(id)))
end
end

repeatUtil.scheduleEvery(id,50,"frames",doStuff)
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 28, 2017, 04:49:00 pm
Can anybody work out a reason why this code continues after being cancelled, or is it a bug with repeat-util?
Code: [Select]
local blah = 1
local id = "foo"
local repeatUtil = require 'repeat-util'

local function doStuff()
print("Blah: " .. blah)
blah = blah +1
print("Blah is now " .. blah)
if blah > 10 then
print("Blah is more than 10. Stopping.")
print("Has supposedly cancelled = " .. tostring(repeatUtil.cancel(id)))
end
end

repeatUtil.scheduleEvery(id,50,"frames",doStuff)

Thanks for the example!

It looks like the issue is that repeat-util's scheduleEvery() calls your callback, then sets a timeout for the next one after your callback returns, regardless of what your callback did. Here's the relevant part of repeat-utils.lua:

Code: [Select]
function scheduleEvery(name,time,timeUnits,func)
 cancel(name)
 local function helper()
  func()
  repeating[name] = dfhack.timeout(time,timeUnits,helper)
 end
 helper()
end

helper() gets called repeatedly, which calls func() (your callback), then sets up a new timeout. This has the advantage that if func() raises an error, it won't get rescheduled indefinitely (i.e. swapping "func()" with the line below would be a bad idea). However, it also means a repeating function can't cancel itself. I think it could track calls to cancel() and make sure that func() didn't cancel itself before rescheduling it, though, if you'd find that useful.

Edit: added this as an issue: https://github.com/DFHack/dfhack/issues/1122
Title: Re: DFHack 0.43.05-r1
Post by: Hesperid on June 29, 2017, 11:14:14 am
I thought repeating functions not being able to cancel their own scheduling was a deliberate design decision.

The workaround that suggests itself is to have an infrequently running auxiliary function handle canceling of other functions. While the repeaters are waiting to be canceled, they are prevented from running by a guard variable. In my implementation, the guard variable and cancel signal are the same variable.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on June 29, 2017, 12:06:00 pm
I thought repeating functions not being able to cancel their own scheduling was a deliberate design decision.
Why would it be? Expwnent seems to agree that it's unintentional. I can't see much of an advantage from preventing repeating functions from cancelling themselves (particularly since they can cancel other ones already).

Atkana: you might also find the "gui.script" module useful, by the way. Something like this could work:

Code: [Select]
local script = require 'gui.script'

script.start(function()
    for blah = 1, 10 do
        print("Blah: " .. blah)
        script.sleep(50, "frames")
    end
end)
Title: Re: DFHack 0.43.05-r1
Post by: expwnent on June 30, 2017, 07:19:22 am
I thought repeating functions not being able to cancel their own scheduling was a deliberate design decision.
Why would it be? Expwnent seems to agree that it's unintentional. I can't see much of an advantage from preventing repeating functions from cancelling themselves (particularly since they can cancel other ones already).

Definitely unintentional. We didn't notice until you pointed it out because it's actually pretty uncommon that you need to unregister a repeating event.
Title: Re: DFHack 0.43.05-r1
Post by: Atkana on June 30, 2017, 10:30:19 am
-snip-
Thanks. For my actual script I ended up cutting out the middlescript and just used dfhack.timeout() itself, as well as redesigning it so it didn't have to cancel itself :P I'll keep that method in mind if I have to do something like that in the future, it just goes to show that I really need to make learning how GUI-related stuff works as my next priority...
Title: Re: DFHack 0.43.05-r1
Post by: Max™ on June 30, 2017, 03:34:11 pm
Agreed, and having just started down this path let me point out that while the gui and screen portions of the lua api: https://github.com/DFHack/dfhack/blob/develop/docs/Lua%20API.rst#screen-api are handy, there are things involved which aren't really covered in there because a lot of them are actually contained in some of the dfhack scripts.

Open up the hack/lua/gui folder and look through the scripts in there to see how our lovely dfhack folks put together the widgets and dialogs and such, it makes it a lot easier to figure out how to get them working yourself.
Title: Re: DFHack 0.43.05-r1
Post by: Hesperid on June 30, 2017, 05:27:58 pm
I thought repeating functions not being able to cancel their own scheduling was a deliberate design decision.
Why would it be? Expwnent seems to agree that it's unintentional.

I'm not claiming it's intentional. What I'm saying is that when I originally encountered this behavior, I assumed it was deliberate. That seemed like a reasonable assumption given the circumstances.
Title: Re: DFHack 0.43.05-r1
Post by: Moonshine Fox on July 02, 2017, 04:01:15 am
I can't seem to figure this out. I keep getting segfaults literally all the time on my save in Linux now, and I've had it happen on earlier saves as well.

Code: [Select]
[DFHack]# .dwarffortress/dfhack: line 66: 22352 Segmentation fault      (core dumped) setarch i386 -R env LD_PRELOAD="$PRELOAD_LIB" ./libs/Dwarf_Fortress "$@"
Is what it most often ends with.

I'm using r1 DFHack and TWBT Next 6.18. Any ideas? It seems completely random as to when it happens, but usually within minutes of loading the save.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on July 02, 2017, 07:11:47 am
Do you have any weapon traps?
Title: Re: DFHack 0.43.05-r1
Post by: Moonshine Fox on July 02, 2017, 08:57:47 am
Do you have any weapon traps?

Yes, I do. I just recently set a couple up outside my fort. Is this problem connected to Weapon Traps somehow?
Title: Re: DFHack 0.43.05-r1
Post by: Rose on July 02, 2017, 08:59:53 am
Yup, there's a bug with weapon traps in vanilla df
Title: Re: DFHack 0.43.05-r1
Post by: PatrikLundell on July 02, 2017, 09:42:06 am
Stuff in weapon tracks breaking due to wear (when the trap operates) causes DF to break as well...
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on July 02, 2017, 12:39:42 pm
Specifically, it's http://www.bay12games.com/dwarves/mantisbt/view.php?id=9888, which is fixed in the next version.
Title: Re: DFHack 0.43.05-r1
Post by: Moonshine Fox on July 03, 2017, 01:15:31 am
Specifically, it's http://www.bay12games.com/dwarves/mantisbt/view.php?id=9888, which is fixed in the next version.

Thank you! I for some reason didn't expect something that has been working fine for years to suddenly break. But I see a new wear code was put in, so welp. Thanks for pointing me in the right direction!
Title: Re: DFHack 0.43.05-r1
Post by: scourge728 on July 03, 2017, 07:32:57 am
I'm incredibly excited for the new update...
Title: Re: DFHack 0.43.05-r1
Post by: Max™ on July 04, 2017, 02:36:24 am
Ok so, Atkana is fucking awesome apparently. I saw the script they set up to manipulate appearance and such during adventurer creation and thought "wow, I bet that could be gotten into gm-unit" and tried but failed at getting it fully working so I showed them right?

http://www.bay12forums.com/smf/index.php?topic=164709.msg7501676#msg7501676
Code: (gui/gm-unit.lua) [Select]
-- Interface powered, user friendly, unit editor

--[====[

gui/gm-unit
===========
An editor for various unit attributes.

]====]
local gui = require 'gui'
local dialog = require 'gui.dialogs'
local widgets =require 'gui.widgets'
local guiScript = require 'gui.script'
local utils = require 'utils'
local args={...}


local target
--TODO: add more ways to guess what unit you want to edit
if args[1]~= nil then
    target=df.units.find(args[1])
else
    target=dfhack.gui.getSelectedUnit(true)
end

if target==nil then
    qerror("No unit to edit") --TODO: better error message
end
local editors={}
function add_editor(editor_class)
    table.insert(editors,{text=editor_class.ATTRS.frame_title,on_submit=function ( unit )
        editor_class{target_unit=unit}:show()
    end})
end
-------------------------------various subeditors---------
--TODO set local sould or better yet skills vector to reduce long skill list access typing
editor_skills=defclass(editor_skills,gui.FramedScreen)
editor_skills.ATTRS={
    frame_style = gui.GREY_LINE_FRAME,
    frame_title = "Skill editor",
    target_unit = DEFAULT_NIL,
    learned_only= false,
}
function list_skills(unit,learned_only)
    local s_=df.job_skill
    local u_skills=unit.status.current_soul.skills
    local ret={}
    for i,v in ipairs(s_) do
        if i>=0 then
            local u_skill=utils.binsearch(u_skills,i,"id")
            if u_skill or not learned_only then
                if not u_skill then
                    u_skill={rating=-1,experience=0}
                end

                local rating
                if u_skill.rating >=0 then
                    rating=df.skill_rating.attrs[u_skill.rating]
                else
                    rating={caption="<unlearned>",xp_threshold=0}
                end

                local text=string.format("%s: %s %d %d/%d",df.job_skill.attrs[i].caption,rating.caption,u_skill.rating,u_skill.experience,rating.xp_threshold)
                table.insert(ret,{text=text,id=i})
            end
        end
    end
    return ret
end
function editor_skills:update_list(no_save_place)
    local skill_list=list_skills(self.target_unit,self.learned_only)
    if no_save_place then
        self.subviews.skills:setChoices(skill_list)
    else
        self.subviews.skills:setChoices(skill_list,self.subviews.skills:getSelected())
    end
end
function editor_skills:init( args )
    if self.target_unit.status.current_soul==nil then
        qerror("Unit does not have soul, can't edit skills")
    end

    local skill_list=list_skills(self.target_unit,self.learned_only)

    self:addviews{
    widgets.FilteredList{
        choices=skill_list,
        frame = {t=0, b=1,l=1},
        view_id="skills",
    },
    widgets.Label{
                frame = { b=0,l=1},
                text ={{text= ": exit editor ",
                    key  = "LEAVESCREEN",
                    on_activate= self:callback("dismiss")
                    },
                    {text=": remove level ",
                    key = "SECONDSCROLL_UP",
                    on_activate=self:callback("level_skill",-1)},
                    {text=": add level ",
                    key = "SECONDSCROLL_DOWN",
                    on_activate=self:callback("level_skill",1)}
                    ,
                    {text=": show learned only ",
                    key = "CHANGETAB",
                    on_activate=function ()
                        self.learned_only=not self.learned_only
                        self:update_list(true)
                    end}
                    }
            },
        }
end
function editor_skills:get_cur_skill()
    local list_wid=self.subviews.skills
    local _,choice=list_wid:getSelected()
    if choice==nil then
        qerror("Nothing selected")
    end
    local u_skill=utils.binsearch(self.target_unit.status.current_soul.skills,choice.id,"id")
    return choice,u_skill
end
function editor_skills:level_skill(lvl)
    local sk_en,sk=self:get_cur_skill()
    if lvl >0 then
        local rating

        if sk then
            rating=sk.rating+lvl
        else
            rating=lvl-1
        end

        utils.insert_or_update(self.target_unit.status.current_soul.skills, {new=true, id=sk_en.id, rating=rating}, 'id') --TODO set exp?
    elseif sk and sk.rating==0 and lvl<0 then
        utils.erase_sorted_key(self.target_unit.status.current_soul.skills,sk_en.id,"id")
    elseif sk and lvl<0 then
        utils.insert_or_update(self.target_unit.status.current_soul.skills, {new=true, id=sk_en.id, rating=sk.rating+lvl}, 'id') --TODO set exp?
    end
    self:update_list()
end
function editor_skills:remove_rust(skill)
    --TODO
end
add_editor(editor_skills)
------- civ editor
RaceBox = defclass(RaceBox, dialog.ListBox)
RaceBox.focus_path = 'RaceBox'

RaceBox.ATTRS{
    format_name="$NAME ($TOKEN)",
    with_filter=true,
    allow_none=false,
}
function RaceBox:format_creature(creature_raw)
    local t = {NAME=creature_raw.name[0],TOKEN=creature_raw.creature_id}
    return string.gsub(self.format_name, "%$(%w+)", t)
end
function RaceBox:preinit(info)
    self.format_name=RaceBox.ATTRS.format_name or info.format_name -- preinit does not have ATTRS set yet
    local choices={}
    if RaceBox.ATTRS.allow_none or info.allow_none then
        table.insert(choices,{text="<none>",num=-1})
    end
    for i,v in ipairs(df.global.world.raws.creatures.all) do
        local text=self:format_creature(v)
        table.insert(choices,{text=text,raw=v,num=i,search_key=text:lower()})
    end
    info.choices=choices
end
function showRacePrompt(title, text, tcolor, on_select, on_cancel, min_width,allow_none)
    RaceBox{
        frame_title = title,
        text = text,
        text_pen = tcolor,
        on_select = on_select,
        on_cancel = on_cancel,
        frame_width = min_width,
        allow_none = allow_none,
    }:show()
end
CivBox = defclass(CivBox,dialog.ListBox)
CivBox.focus_path = "CivBox"

CivBox.ATTRS={
    format_name="$NAME ($ENGLISH):$ID",
    format_no_name="<unnamed>:$ID",
    name_other="<other(-1)>",
    with_filter=true,
    allow_other=false,
}

function civ_name(id,format_name,format_no_name,name_other,name_invalid)
    if id==-1 then
        return name_other or "<other (-1)>"
    end
    local civ
    if type(id)=='userdata' then
        civ=id
    else
        civ=df.historical_entity.find(id)
        if civ==nil then
            return name_invalid or "<invalid>"
        end
    end
    local t={NAME=dfhack.TranslateName(civ.name),ENGLISH=dfhack.TranslateName(civ.name,true),ID=civ.id} --TODO race?, maybe something from raws?
    if t.NAME=="" then
        return string.gsub(format_no_name or "<unnamed>:$ID", "%$(%w+)", t)
    end
    return string.gsub(format_name or "$NAME ($ENGLISH):$ID", "%$(%w+)", t)
end
function CivBox:update_choices()
    local choices={}
    if self.allow_other then
        table.insert(choices,{text=self.name_other,num=-1})
    end

    for i,v in ipairs(df.global.world.entities.all) do
        if not self.race_filter or (v.race==self.race_filter) then --TODO filter type
            local text=civ_name(v,self.format_name,self.format_no_name,self.name_other,self.name_invalid)
            table.insert(choices,{text=text,raw=v,num=i})
        end
    end
    self.choices=choices
    if self.subviews.list then
        self.subviews.list:setChoices(self.choices)
    end
end
function CivBox:update_race_filter(id)
    local raw=df.creature_raw.find(id)
    if raw then
        self.subviews.race_label:setText(": "..raw.name[0])
        self.race_filter=id
    else
        self.subviews.race_label:setText(": <none>")
        self.race_filter=nil
    end

    self:update_choices()
end
function CivBox:choose_race()
    showRacePrompt("Choose race","Select new race:",nil,function (id,choice)
        self:update_race_filter(choice.num)
    end,nil,nil,true)
end
function CivBox:init(info)
    self.subviews.list.frame={t=3,r=0,l=0}
    self:addviews{
        widgets.Label{frame={t=1,l=0},text={
        {text="Filter race ",key="CUSTOM_CTRL_A",key_sep="()",on_activate=self:callback("choose_race")},
        }},
        widgets.Label{frame={t=1,l=21},view_id="race_label",
        text=": <none>",
        }
    }
    self:update_choices()
end
function showCivPrompt(title, text, tcolor, on_select, on_cancel, min_width,allow_other)
    CivBox{
        frame_title = title,
        text = text,
        text_pen = tcolor,
        on_select = on_select,
        on_cancel = on_cancel,
        frame_width = min_width,
        allow_other = allow_other,
    }:show()
end

editor_civ=defclass(editor_civ,gui.FramedScreen)
editor_civ.ATTRS={
    frame_style = gui.GREY_LINE_FRAME,
    frame_title = "Civilization editor",
    target_unit = DEFAULT_NIL,
    }

function editor_civ:update_curren_civ()
    self.subviews.civ_name:setText("Currently: "..civ_name(self.target_unit.civ_id))
end
function editor_civ:init( args )
    if self.target_unit==nil then
        qerror("invalid unit")
    end

    self:addviews{
    widgets.Label{view_id="civ_name",frame = { t=1,l=1}, text="Currently: "..civ_name(self.target_unit.civ_id)},
    widgets.Label{frame = { t=2,l=1}, text={{text=": set to other (-1, usually enemy)",key="CUSTOM_N",
        on_activate= function() self.target_unit.civ_id=-1;self:update_curren_civ() end}}},
    widgets.Label{frame = { t=3,l=1}, text={{text=": set to current civ("..df.global.ui.civ_id..")",key="CUSTOM_C",
        on_activate= function() self.target_unit.civ_id=df.global.ui.civ_id;self:update_curren_civ() end}}},
    widgets.Label{frame = { t=4,l=1}, text={{text=": manually enter",key="CUSTOM_E",
        on_activate=function ()
         dialog.showInputPrompt("Civ id","Enter new civ id:",COLOR_WHITE,
            tostring(self.target_unit.civ_id),function(new_value)
                self.target_unit.civ_id=new_value
                self:update_curren_civ()
            end)
        end}}
        },
    widgets.Label{frame= {t=5,l=1}, text={{text=": select from list",key="CUSTOM_L",
        on_activate=function (  )
            showCivPrompt("Choose civilization", "Select units civilization",nil,function ( id,choice )
                self.target_unit.civ_id=choice.num
                self:update_curren_civ()
            end,nil,nil,true)
        end
        }}},
    widgets.Label{
                frame = { b=0,l=1},
                text ={{text= ": exit editor ",
                    key  = "LEAVESCREEN",
                    on_activate= self:callback("dismiss")
                    },
                    }
            },
        }
end
add_editor(editor_civ)
------- counters editor
editor_counters=defclass(editor_counters,gui.FramedScreen)
editor_counters.ATTRS={
    frame_style = gui.GREY_LINE_FRAME,
    frame_title = "Counters editor",
    target_unit = DEFAULT_NIL,
    counters1={
    "think_counter",
    "job_counter",
    "swap_counter",
    "winded",
    "stunned",
    "unconscious",
    "suffocation",
    "webbed",
    "soldier_mood_countdown",
    "soldier_mood", --todo enum,
    "pain",
    "nausea",
    "dizziness",
    },
    counters2={
    "paralysis",
    "numbness",
    "fever",
    "exhaustion",
    "hunger_timer",
    "thirst_timer",
    "sleepiness_timer",
    "stomach_content",
    "stomach_food",
    "vomit_timeout",
    "stored_fat" --TODO what to reset to?
    }
}
function editor_counters:fill_counters()
    local ret={}
    local u=self.target_unit
    for i,v in ipairs(self.counters1) do
        table.insert(ret,{f=u.counters:_field(v),name=v})
    end
    for i,v in ipairs(self.counters2) do
        table.insert(ret,{f=u.counters2:_field(v),name=v})
    end
    return ret
end
function editor_counters:update_counters()
    for i,v in ipairs(self.counter_list) do
        v.text=string.format("%s:%d",v.name,v.f.value)
    end
    self.subviews.counters:setChoices(self.counter_list)
end
function editor_counters:set_cur_counter(value,index,choice)
    choice.f.value=value
    self:update_counters()
end
function editor_counters:choose_cur_counter(index,choice)
    dialog.showInputPrompt(choice.name,"Enter new value:",COLOR_WHITE,
            tostring(choice.f.value),function(new_value)
                self:set_cur_counter(new_value,index,choice)
            end)
end
function editor_counters:init( args )
    if self.target_unit==nil then
        qerror("invalid unit")
    end

    self.counter_list=self:fill_counters()


    self:addviews{
    widgets.FilteredList{
        choices=self.counter_list,
        frame = {t=0, b=1,l=1},
        view_id="counters",
        on_submit=self:callback("choose_cur_counter"),
        on_submit2=self:callback("set_cur_counter",0),--TODO some things need to be set to different defaults
    },
    widgets.Label{
                frame = { b=0,l=1},
                text ={{text= ": exit editor ",
                    key  = "LEAVESCREEN",
                    on_activate= self:callback("dismiss")
                    },
                    {text=": reset counter ",
                    key = "SEC_SELECT",
                    },
                    {text=": set counter ",
                    key = "SELECT",
                    }
                   
                    }
            },
        }
    self:update_counters()
end
add_editor(editor_counters)

wound_creator=defclass(wound_creator,gui.FramedScreen)
wound_creator.ATTRS={
    frame_style = gui.GREY_LINE_FRAME,
    frame_title = "Wound creator",
    target_wound = DEFAULT_NIL,
    --filter
}
function wound_creator:init( args )
    if self.target_wound==nil then
        qerror("invalid wound")
    end
   

    self:addviews{
    widgets.List{
       
        frame = {t=0, b=1,l=1},
        view_id="fields",
        on_submit=self:callback("edit_cur_wound"),
        on_submit2=self:callback("delete_current_wound")
    },
    widgets.Label{
                frame = { b=0,l=1},
                text ={{text= ": exit editor ",
                    key  = "LEAVESCREEN",
                    on_activate= self:callback("dismiss")},

                    {text=": edit wound ",
                    key = "SELECT"},

                    {text=": delete wound ",
                    key = "SEC_SELECT"},
                    {text=": create wound ",
                    key = "CUSTOM_CTRL_I",
                    on_activate= self:callback("create_new_wound")},

                    }
            },
        }
    self:update_wounds()
end
-------------------
editor_wounds=defclass(editor_wounds,gui.FramedScreen)
editor_wounds.ATTRS={
    frame_style = gui.GREY_LINE_FRAME,
    frame_title = "Wound editor",
    target_unit = DEFAULT_NIL,
    --filter
}
function is_scar( wound_part )
    return wound_part.flags1.scar_cut or wound_part.flags1.scar_smashed or
        wound_part.flags1.scar_edged_shake1 or wound_part.flags1.scar_blunt_shake1
end
function format_flag_name( fname )
    return fname:sub(1,1):upper()..fname:sub(2):gsub("_"," ")
end
function name_from_flags( wp )
    for i,v in ipairs(wp.flags1) do
        if v then
            return format_flag_name(df.wound_damage_flags1[i])
        end
    end
    for i,v in ipairs(wp.flags2) do
        if v then
            return format_flag_name(df.wound_damage_flags2[i])
        end
    end
    return "<unnamed wound>"
end
function format_wound( list_id,wound, unit)

    local name="<unnamed wound>"
    if #wound.parts>0 and #wound.parts[0].effect_type>0 then --try to make wound name by effect...
        name=tostring(df.wound_effect_type[wound.parts[0].effect_type[0]])
        if #wound.parts>1 then --cheap and probably incorrect...
            name=name.."s"
        end
    elseif #wound.parts>0 and is_scar(wound.parts[0]) then
        name="Scar"
    elseif #wound.parts>0 then
        local wp=wound.parts[0]
        name=name_from_flags(wp)
    end

    return string.format("%d. %s id=%d",list_id,name,wound.id)
end
function editor_wounds:update_wounds()
    local ret={}
    for i,v in ipairs(self.trg_wounds) do
        table.insert(ret,{text=format_wound(i,v,self.target_unit),wound=v})
    end
    self.subviews.wounds:setChoices(ret)
    self.wound_list=ret
end
function editor_wounds:dirty_unit()
    print("todo: implement unit status recalculation")
end
function editor_wounds:get_cur_wound()
    local list_wid=self.subviews.wounds
    local _,choice=list_wid:getSelected()
    if choice==nil then
        qerror("Nothing selected")
    end
    local ret_wound=utils.binsearch(self.trg_wounds,choice.id,"id")
    return choice,ret_wound
end
function editor_wounds:delete_current_wound(index,choice)
   
    utils.erase_sorted(self.trg_wounds,choice.wound,"id")
    choice.wound:delete()
    self:dirty_unit()
    self:update_wounds()
end
function editor_wounds:create_new_wound()
    print("Creating")
end
function editor_wounds:edit_cur_wound(index,choice)
   
end
function editor_wounds:init( args )
    if self.target_unit==nil then
        qerror("invalid unit")
    end
    self.trg_wounds=self.target_unit.body.wounds

    self:addviews{
    widgets.List{
       
        frame = {t=0, b=1,l=1},
        view_id="wounds",
        on_submit=self:callback("edit_cur_wound"),
        on_submit2=self:callback("delete_current_wound")
    },
    widgets.Label{
                frame = { b=0,l=1},
                text ={{text= ": exit editor ",
                    key  = "LEAVESCREEN",
                    on_activate= self:callback("dismiss")},

                    {text=": edit wound ",
                    key = "SELECT"},

                    {text=": delete wound ",
                    key = "SEC_SELECT"},
                    {text=": create wound ",
                    key = "CUSTOM_CTRL_I",
                    on_activate= self:callback("create_new_wound")},

                    }
            },
        }
    self:update_wounds()
end
add_editor(editor_wounds)

------ Body editor

modifier_selector = defclass(modifier_selector, gui.FramedScreen)

function modifierString(mod)
local out = df.appearance_modifier_type[mod.type]
out = out:lower() --Make lowercase
out = out:gsub("_", " ") --Replace underscores with spaces
out = out:gsub("^%l", string.upper) --capitalises first letter

return out
end

function showModifierScreen(data)
modifier_selector{
    frame_style = gui.GREY_LINE_FRAME,
    frame_title = "Select a modifier",
    target_unit = DEFAULT_NIL,
data = data
    }:show()
end

function modifier_selector:set_value(value,index,choice)
for i,v in ipairs(choice.changes) do
self.changeType[v] = value
end
self:update_features()
end

function modifier_selector:on_select(index, choice)
dialog.showInputPrompt(modifierString(choice.mod),"Enter new value:",COLOR_WHITE,
            tostring(self.changeType[choice.changes[1]]),function(new_value)
                self:set_value(new_value,index,choice)
            end)
end

function modifier_selector:update_features()
local out = {}
for i, v in ipairs(self.partPicked.modList) do
table.insert(out, {text = (modifierString(v.modifier) .. ": " .. self.changeType[v.changes[1]]), mod = v.modifier, changes = v.changes})
end
self.subviews.modifiers:setChoices(out)
end

function modifier_selector:init( info )
self.partPicked = info.data.choice --The part that was picked in editor_body

if info.data.choice.isPart then
self.changeType = target.appearance.bp_modifiers
else
self.changeType = target.appearance.body_modifiers
end

    self:addviews{
    widgets.FilteredList{
        frame = {t=0, b=1,l=1},
        view_id="modifiers",
on_submit=self:callback("on_select")
    },
    widgets.Label{
                frame = { b=0,l=1},
                text ={{text= ": back to part selector ",
                    key  = "LEAVESCREEN",
                    on_activate= self:callback("dismiss")
                    },
                    {text=": select modifier ",
                    key = "SELECT",
                    }
                   
                    }
            },
        }

    self:update_features()
end


editor_body=defclass(editor_body,gui.FramedScreen)
editor_body.ATTRS={
    frame_style = gui.GREY_LINE_FRAME,
    frame_title = "Body modifier editor",
    target_unit = DEFAULT_NIL,
}

function editor_body:bp_links()
local out = {}
local uc = self.ucaste
for i,v in ipairs(uc.bp_appearance.part_idx) do
out[i] = {["modId"] = uc.bp_appearance.modifier_idx[i], ["partId"] = uc.bp_appearance.part_idx[i]}
end

return out
end

--Following is a relic from my original change-appearance script. There's probably a more efficient way of doing this, but I'm not in the mood to be redesigning ;P
function editor_body:make_bplist()
local ret = {}
local bpm = self.ucaste.bp_appearance.modifiers
local links = self:bp_links()
local point = {}

for i, v in ipairs(bpm) do
local mod = v

local bpmname
if #mod.noun > 0 then
bpmname = mod.noun
else
bpmname = self.ucaste.body_info.body_parts[mod.body_parts[0]].name_singular[0].value
end

local changes = {}
for i2, v2 in ipairs(mod.body_parts) do
local partId = v2
for i3, v3 in ipairs(links) do
if v3.modId == i and v3.partId == partId then
table.insert(changes, i3) --?
end
end
end

if point[bpmname] then
table.insert(ret[point[bpmname]].modList, {["modifier"] = mod, ["changes"] = changes})
else
table.insert(ret, {["name"] = bpmname, ["modList"] = {[1] = {["modifier"] = mod, ["changes"] = changes}}})
point[bpmname] = #ret --Stores the index of the name for future additions
end
end
return ret
end

function editor_body:make_bodmodlist() --Version of make_bplist() to make a spoof version for body so it can be treated the same. Only makes modList
local ret = {}
local bm = self.ucaste.body_appearance_modifiers

for i, v in ipairs(bm) do
table.insert(ret, {["modifier"] = v, ["changes"] = {[1] = i}})
end

return ret
end

function editor_body:update_features()
self.bplist = self:make_bplist()
local out = {}
local uc = self.ucaste
self.bodmodlist = self:make_bodmodlist()
--Special case of body
--First check to discover if there are any body mods
if #uc.body_appearance_modifiers > 0 then
table.insert(out, {text = "Body", modList = self.bodmodlist})
end

for i,v in ipairs(self.bplist) do
table.insert(out, {text = v.name:gsub("^%l", string.upper), modList = v.modList, isPart = true})
end

self.subviews.body:setChoices(out)
end

function editor_body:choose_cur_bp(index, choice)
local data = {["choice"] = choice}

showModifierScreen(data)
end


function editor_body:init( args )
    if self.target_unit==nil then
        qerror("invalid unit")
    end

self.urace = self.target_unit.race
self.ucritter = df.creature_raw.find(self.urace)
self.ucaste = self.ucritter.caste[self.target_unit.caste]

    self:addviews{
    widgets.FilteredList{
        choices=self.features_list,
        frame = {t=0, b=1,l=1},
        view_id="body",
on_submit=self:callback("choose_cur_bp")
    },
    widgets.Label{
                frame = { b=0,l=1},
                text ={{text= ": exit editor ",
                    key  = "LEAVESCREEN",
                    on_activate= self:callback("dismiss")
                    },
                    {text=": select feature ",
                    key = "SELECT",
                    }
                   
                    }
            },
        }

    self:update_features()
end
add_editor(editor_body)

------ Colors editor
ColorBox = defclass(ColorBox, dialog.ListBox)
ColorBox.focus_path = 'ColorBox'

ColorBox.ATTRS{
with_filter = true,
allow_none = false,
}

function showColorPrompt(title, text, tcolor, on_select, on_cancel, min_width,allow_other, data)
    ColorBox{
        frame_title = title,
        text = text,
        text_pen = tcolor,
        on_select = on_select,
        on_cancel = on_cancel,
        frame_width = min_width,
        allow_other = allow_other,
data = data
    }:show()
end

function ColorBox:update_choices()
local choices = {}
for i,v in ipairs(self.mod.pattern_index) do
table.insert(choices, {text=patternString(self.mod.pattern_index[i]), index = i})
end

self.choices = choices
if self.subviews.list then
        self.subviews.list:setChoices(self.choices)
    end
end

function ColorBox:init(info)
self.mod = info.data.mod

self.target_unit = target
self:update_choices()
end

editor_colors=defclass(editor_colors,gui.FramedScreen)
editor_colors.ATTRS={
    frame_style = gui.GREY_LINE_FRAME,
    frame_title = "Colors editor",
    target_unit = DEFAULT_NIL,
}

function getColor(id)
return df.descriptor_color.find(id)
end

function getPattern(id)
return df.descriptor_pattern.find(id)
end

function patternString(id)
local pattern = getPattern(id)
local prefix
if pattern.pattern == 0 then --Monochrome
return getColor(pattern.colors[0]).name
elseif pattern.pattern == 1 then --Stripes
prefix = "striped"
elseif pattern.pattern == 2 then --Iris_eye
return getColor(pattern.colors[2]).name .. " eyes"
elseif pattern.pattern == 3 then --Spots
prefix = "spotted" --that's a guess
elseif pattern.pattern == 4 then --Pupil_eye
return getColor(pattern.colors[2]).name .. " eyes"
elseif pattern.pattern == 5 then --mottled
prefix = "mottled"
end
local out = prefix .. " "
for i=0, #pattern.colors-1 do
if i == #pattern.colors-1 then
out = out .. "and " .. getColor(pattern.colors[i]).name
elseif i == #pattern.colors-2 then
out = out .. getColor(pattern.colors[i]).name .. " "
else
out = out .. getColor(pattern.colors[i]).name .. ", "
end
end
return out
end

function editor_colors:change_color(index,patternId)
self.target_unit.appearance.colors[index] = patternId
end

function editor_colors:update_features()
local uc = self.ucaste
local out = {}
for i,v in ipairs(uc.color_modifiers) do
table.insert(out, {text=uc.color_modifiers[i].part:gsub("^%l", string.upper), mod = uc.color_modifiers[i], index = i})
end
self.subviews.colors:setChoices(out)
end

function editor_colors:choose_cur_feature(index,choice)
self.chosenFeature = choice
local data = {ucaste = self.ucaste, mod = choice.mod} --data to pass to color prompt
showColorPrompt("Choose color", "Select features color",nil,function ( id,choice )
self:change_color(self.chosenFeature.index, choice.index)
            end,nil,nil,true, data)
end


function editor_colors:init( args )
    if self.target_unit==nil then
        qerror("invalid unit")
    end

self.urace = self.target_unit.race
self.ucritter = df.creature_raw.find(self.urace)
self.ucaste = self.ucritter.caste[self.target_unit.caste]

    self:addviews{
    widgets.FilteredList{
        choices=self.features_list,
        frame = {t=0, b=1,l=1},
        view_id="colors",
on_submit=self:callback("choose_cur_feature")
    },
    widgets.Label{
                frame = { b=0,l=1},
                text ={{text= ": exit editor ",
                    key  = "LEAVESCREEN",
                    on_activate= self:callback("dismiss")
                    },
                    {text=": select feature ",
                    key = "SELECT",
                    }
                   
                    }
            },
        }

    self:update_features()
end
add_editor(editor_colors)

-------------------------------main window----------------
unit_editor = defclass(unit_editor, gui.FramedScreen)
unit_editor.ATTRS={
    frame_style = gui.GREY_LINE_FRAME,
    frame_title = "GameMaster's unit editor",
    target_unit = DEFAULT_NIL,
    }


function unit_editor:init(args)

    self:addviews{
    widgets.FilteredList{
        choices=editors,
        on_submit=function (idx,choice)
            if choice.on_submit then
                choice.on_submit(self.target_unit)
            end
        end
    },
    widgets.Label{
                frame = { b=0,l=1},
                text ={{text= ": exit editor",
                    key  = "LEAVESCREEN",
                    on_activate= self:callback("dismiss")
                    },
                    }
            },
        }
end


unit_editor{target_unit=target}:show()
That adds Body Modifier and Color entries, which frankly I think look good enough from a first pass to be in the main version.
Title: Re: DFHack 0.43.05-r1
Post by: Moonshine Fox on July 04, 2017, 08:27:29 am
Hmm, problem still persists even though I've removed the Weapon Traps. Mind you, the traps were not completed, they were only planned, so no one could've stepped in them.
Title: Re: DFHack 0.43.05-r1
Post by: mifki on July 04, 2017, 04:52:18 pm
Hmm, problem still persists even though I've removed the Weapon Traps. Mind you, the traps were not completed, they were only planned, so no one could've stepped in them.

Try TWBT 5.xx (not Next). There's a bug in Next that may cause crashes.
Title: Re: DFHack 0.43.05-r1
Post by: Moonshine Fox on July 05, 2017, 01:09:11 am
Hmm, problem still persists even though I've removed the Weapon Traps. Mind you, the traps were not completed, they were only planned, so no one could've stepped in them.

Try TWBT 5.xx (not Next). There's a bug in Next that may cause crashes.
After about half an hour of testing, this seems to have done the trick.
Title: Re: DFHack 0.43.05-r1
Post by: Atkana on July 05, 2017, 11:48:36 am
Hey, I made a few of modtools for some features I encountered that didn't have any, and since I don't yet know how to github I figured I should share them here and maybe someone'll be kind enough to github magic them if they're acceptable (may need testing) :P + I have a question relating to them, anyways.
The first is modtools/set-need. Mainly inspired by how Masterwork has recreational workshops to give workers good thoughts, I made this with the intention of mostly being used in conjunction with reaction-trigger to have reactions that can fulfill a worker's needs:
Code: (modtools/set-need.lua) [Select]
-- Change focus level of needs for units

local usage = [====[

modtools/set-need
=====================
This allows for modifying the focus levels for needs on units.

Arguments:

-need id
the id/type of the need to change. Alternatively "all" to apply the value to all.
examples:
1
DrinkAlcohol
all
-value
the value to set focus to. Defaults to 400 if not included (the value focus resets to when normally fulfilled in game).
Negative values need to have a \ before the negative symbol
examples:
250
\-5000
-target id
        the unit id of the target unit. If unspecified, will check for a selected unit.
        examples:
            0
            28
-needlist
displays a list of need ids.

]====]

local utils = require 'utils'

validArgs = validArgs or utils.invert({
'help',
'needlist',
'need',
'value',
'target'
})

local args = utils.processArgs({...}, validArgs)

if args.help then
print(usage)
return
end

if args.needlist then
for i,v in ipairs(df.need_type)do
print(i .. " (" .. v .. ")")
end
return
end

--Find the target
local targ
if not args.target then
if dfhack.gui.getSelectedUnit(true) then
targ =  dfhack.gui.getSelectedUnit(true)
else
error 'Specify a target'
end
else
if df.unit.find(tonumber(args.target)) then
targ = df.unit.find(tonumber(args.target))
else
error ('Could not find target: '.. args.target)
end
end
args.target = targ

--Work out the need
local doAll
if not args.need then
error 'Specify a need'
end

if (args.need):lower() == "all" then
doAll = true
elseif  tonumber(args.need) then
args.need = tonumber(args.need)
elseif df.need_type[args.need] then
args.need = df.need_type[args.need]
else
error 'Invalid need'
end

--Set the value
args.value = tonumber(args.value) or 400

--Doing the thing
local currentNeedTableId
for i, v in ipairs(args.target.status.current_soul.personality.needs) do
if doAll or v.id == args.need then
v.focus_level = args.value
if not doAll then
return
end
end
end

The second and third are similar scripts I made as part of setting up a groundwork for when I eventually get around to making a values/personality GUI editor: modtools/set-belief and modtools/set-personality.
Code: (modtools/set-belief) [Select]
-- Change beliefs value of a unit
--[[ Issues/Potential changes
- Doesn't cause needs to change
- Changes don't respect creature's cultural weights (not sure how you'd model that, anyway)
- Step sets to a particular value rather than a random range
]]

local usage = [====[

modtools/set-belief
=====================
This allows for altering the beliefs of units.

Arguments:

-belief #
the id/token of the belief to change. Alternatively "all" to apply the value to all... if you want to do that for some reason.
examples:
1
LOYALTY
all
-value #
the value to set the belief strength to. Defaults to 0
examples:
-15
45
-step #
alternative to value. Increase/decrease along description levels by #.
Negative values need to have a \ before the negative symbol.
examples:
2
\-1
-add #
alternative to value. Adds to current value.
Negative values need to have a \ before the negative symbol.
examples:
15
\-20
Without valid value/step/add, defaults to value style at 0.
-target #
        the unit id of the target unit. If unspecified, will check for a selected unit.
        examples:
            0
            28
-belieflist
displays a list of need ids.

]====]

local utils = require 'utils'

validArgs = validArgs or utils.invert({
'help',
'belieflist',
'belief',
'value',
'target',
'step',
'add'
})

local args = utils.processArgs({...}, validArgs)

if args.help then
print(usage)
return
end

if args.belieflist then
for i,v in ipairs(df.value_type)do
print(i .. " (" .. v .. ")")
end
return
end

--Find the target
local targ
if not args.target then
if dfhack.gui.getSelectedUnit(true) then
targ =  dfhack.gui.getSelectedUnit(true)
else
error 'Specify a target'
end
else
if df.unit.find(tonumber(args.target)) then
targ = df.unit.find(tonumber(args.target))
else
error ('Could not find target: '.. args.target)
end
end
args.target = targ

--Checks has a soul, probably
if not targ.status.current_soul then
error 'Unit has no soul'
end

--Store shorthand for use later
local beliefs = args.target.status.current_soul.personality.values

--Work out the trait
local doAll
if not args.belief then
error 'Specify a belief'
end

if (args.belief):lower() == "all" then
doAll = true
elseif  tonumber(args.belief) then
args.belief = tonumber(args.belief)
elseif df.value_type[args.belief] then
args.belief = df.value_type[args.belief]
else
error 'Invalid belief'
end

local ranges = {
[1] = {["low"] = -50, ["high"] = -41, ["mid"] = -45},
[2] = {["low"] = -40, ["high"] = -26, ["mid"] = -33},
[3] = {["low"] = -25, ["high"] = -11, ["mid"] = -18},
[4] = {["low"] = -10, ["high"] = 10, ["mid"] = 0},
[5] = {["low"] = 11, ["high"] = 25, ["mid"] = 18},
[6] = {["low"] = 26, ["high"] = 40, ["mid"] = 33},
[7] = {["low"] = 41, ["high"] = 50, ["mid"] = 45}
}

local function clamp(val, low, high)
if val < low then
return low
elseif val > high then
return high
end
return val
end

local function getStep(value)
for i,v in ipairs(ranges) do
if (value >= v.low) and (value <= v.high) then
return i
end
end
end

local pointers = {}
--[[ Structure: pointers[#1] = #2
#1 is the value's type
#2 is the index entry for unit.status.current_soul.personality.values
]]
local function buildPointers()
for i, v in ipairs(beliefs) do
pointers[v.type] = i
end
end

--Returns unit's current value for given belief
local function getCurBeliefValue(unit, beliefId)
local upers = unit.status.current_soul.personality
if pointers[beliefId] then
return upers.values[pointers[beliefId]].strength
elseif upers.cultural_identity ~= -1 then
return df.cultural_identity.find(upers.cultural_identity).values[beliefId]
else
return 0 --outsiders have no culture
end
end

--Ultimately changes value strength. Changes an existing entry if possible, otherwise creates a new one. Uses pointers.
local function changeBelief(beliefId, value)
local upers = args.target.status.current_soul.personality
local value = clamp(value, -50, 50)
if pointers[beliefId] then --belief already exists on unit
upers.values[pointers[beliefId]].strength = value
--Done!
else --Makes new belief (assumes it's fine to have a personal value entry that's technically the same step as their culture's)
upers.values:insert("#", {new = df.unit_personality.T_values, type = beliefId, strength = value})
--Add this new info to pointers, in case of doAll
pointers[beliefId] = #upers.values-1
--Done!
end
end

local function stepUp(beliefId)
local curStep = getStep(getCurBeliefValue(args.target, beliefId))
local changed = clamp(curStep + args.step, 1, 7)
changeBelief(beliefId, ranges[changed].mid)
end

--Setup for add changes
local function doAdd(beliefId)
changeBelief(beliefId, getCurBeliefValue(args.target, beliefId) + args.add) --No need to check if new value would be beyond range, value is clamped during changeBelief()
end

--Before making changes, make a table that records the unit's individual beliefs
buildPointers()

--Both check for a valid value/alternative and do the thing
if tonumber(args.step) then --Do steps
if doAll then
for i,v in ipairs(df.value_type) do
stepUp(i)
end
else
stepUp(args.belief)
end
return
elseif tonumber(args.add) then --Do adds
if doAll then
for i,v in ipairs(df.value_type) do
doAdd(i)
end
else
doAdd(args.belief)
end
return
else --Doing value or defaulting to value
if not tonumber(args.value) then --If value is missing or invalid, set to 0
args.value = 0
end
--Do values
if doAll then
for i,v in ipairs(df.value_type) do
changeBelief(i, args.value)
end
else
changeBelief(args.belief, args.value)
end
return
end
Code: (modtools/set-personality) [Select]
-- Change personality trait value of a unit
--[[ Issues/Potential changes
- Doesn't cause needs to change
- Changes don't respect target creature's natural limits
- Step sets to a particular value rather than a random range
]]


local usage = [====[

modtools/set-personality
=====================
This allows for altering the personality of units.

Arguments:

-trait #
the id/token of the trait to change. Alternatively "all" to apply the value to all... if you want to do that for some reason.
examples:
1
HATE_PROPENSITY
all
-value #
the value to set the personality to. Defaults to 50
examples:
0
75
-step #
alternative to value. Increase/decrease along description levels by #.
Negative values need to have a \ before the negative symbol
examples:
2
\-1
-add #
alternative to value. Adds to current value.
Negative values need to have a \ before the negative symbol.
examples:
15
\-20
Without valid value/step/add, defaults to value style at 50.
-target #
        the unit id of the target unit. If unspecified, will check for a selected unit.
        examples:
            0
            28
-traitlist
displays a list of need ids.

]====]

local utils = require 'utils'

validArgs = validArgs or utils.invert({
'help',
'traitlist',
'trait',
'value',
'target',
'step',
'add'
})

local args = utils.processArgs({...}, validArgs)

if args.help then
print(usage)
return
end

if args.traitlist then
for i,v in ipairs(df.personality_facet_type)do
print(i .. " (" .. v .. ")")
end
return
end

--Find the target
local targ
if not args.target then
if dfhack.gui.getSelectedUnit(true) then
targ =  dfhack.gui.getSelectedUnit(true)
else
error 'Specify a target'
end
else
if df.unit.find(tonumber(args.target)) then
targ = df.unit.find(tonumber(args.target))
else
error ('Could not find target: '.. args.target)
end
end
args.target = targ

--Checks has a soul, probably
if not targ.status.current_soul then
error 'Unit has no soul'
end

--Store shorthand for use later
local traits = args.target.status.current_soul.personality.traits

--Work out the trait
local doAll
if not args.trait then
error 'Specify a trait'
end

if (args.trait):lower() == "all" then
doAll = true
elseif  tonumber(args.trait) then
args.trait = tonumber(args.trait)
elseif df.personality_facet_type[args.trait] then
args.trait = df.personality_facet_type[args.trait]
else
error 'Invalid trait'
end

local ranges = {
[1] = {["low"] = 0, ["high"] = 9, ["mid"] = 5},
[2] = {["low"] = 10, ["high"] = 24, ["mid"] = 17},
[3] = {["low"] = 25, ["high"] = 39, ["mid"] = 32},
[4] = {["low"] = 40, ["high"] = 60, ["mid"] = 50},
[5] = {["low"] = 61, ["high"] = 75, ["mid"] = 68},
[6] = {["low"] = 76, ["high"] = 90, ["mid"] = 83},
[7] = {["low"] = 91, ["high"] = 100, ["mid"] = 95}
}

local function clamp(val, low, high)
if val < low then
return low
elseif val > high then
return high
end
return val
end

local function getStep(value)
for i,v in ipairs(ranges) do
if (value >= v.low) and (value <= v.high) then
return i
end
end
end

--Ultimately change the trait
local function setValue(traitId, value)
traits[traitId] = clamp(value, 0, 100)
end

--Changes the trait value using step style
local function stepUp(traitId)
local curStep = getStep(traits[traitId])
local changed = clamp(curStep + args.step, 1, 7)
setValue(traitId, ranges[changed].mid) --In theory could instead have a random number between low and high
end

local function doAdd(traitId)
setValue(traitId, traits[traitId] + args.add)
end

--Both check for a valid value/alternative and do the thing
if tonumber(args.step) then
--Do step
if doAll then
for i,v in ipairs(traits) do
stepUp(i)
end
else
stepUp(args.trait)
end
return
elseif tonumber(args.add) then
--Do add
if doAll then
for i,v in ipairs(traits) do
doAdd(i)
end
else
doAdd(args.trait)
end
return
else --Doing value or defaulting to value
if not tonumber(args.value) then
args.value = 50
end
if doAll then
for i,v in ipairs(traits) do
setValue(i, args.value)
end
else
setValue(args.trait, args.value)
end
return
end

These two have a problem, however - while they successfully change the unit's values/personality, the unit's needs don't update to reflect the changes. Does anyone know how to make DF recalculate a unit's needs, or am I going to have to make a script to do it?
Title: Re: DFHack 0.43.05-r1
Post by: Max™ on July 06, 2017, 12:11:05 am
I could swear there was something that did a recalculation of unit status somewhere, and that beliefs script is handy, can't believe I didn't think about the lack of one before, I've just done it manually with gm-editor when I wanted to change them.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on July 06, 2017, 12:13:55 pm
Some Python experiments (with Python 3.6):

Spoiler (click to show/hide)

It doesn't support much yet, and there are some stability issues. It doesn't support accessing DF memory or running scripts directly from the console (it uses a "pyscript" command for that right now, but I'm working on a better way to allow plugins to register their own script types). I've come up with some ways that could make most of the Lua API available to Python, though, so that should be an improvement over the Ruby plugin.
Title: Re: DFHack 0.43.05-r1
Post by: Atkana on July 07, 2017, 01:24:05 pm
Quick update on a couple of the modtools I posted earlier: a fix to a problem that came up when I was trying to use it via script, as well as adding the ability to set beliefs to the culture's default + the ability to set personality traits to the caste's average. Still have no idea regarding the updating needs, though :(
Spoiler (click to show/hide)
Title: Re: DFHack 0.43.05-r1
Post by: PeridexisErrant on July 07, 2017, 06:19:05 pm
Some Python experiments (with Python 3.6):

Spoiler (click to show/hide)

It doesn't support much yet, and there are some stability issues. It doesn't support accessing DF memory or running scripts directly from the console (it uses a "pyscript" command for that right now, but I'm working on a better way to allow plugins to register their own script types). I've come up with some ways that could make most of the Lua API available to Python, though, so that should be an improvement over the Ruby plugin.

I just want to say that this is super exciting and I hope it continues  :D
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on July 07, 2017, 09:56:23 pm
I managed to fix the crash that was happening when reloading the plugin, with help from Quietust (it was an issue with PyImport_AppendInittab appending to a global table that didn't get cleared when the plugin was unloaded/reloaded). That seems to be the only major stability issue so far, although there are likely some memory leaks and threading issues due to me not figuring out entirely how the Python API works.

Anyway, I can call everything from Lua's dfhack.world module in Python now (since those all take primitive types - it only supports transferring None/nil, floats, integers, strings, and bools between Lua and Python for now).
Code: (test.py) [Select]
print(f"""\
save path: {dfhack.world.ReadWorldFolder()}
weather: {dfhack.world.ReadCurrentWeather()}
date: {dfhack.world.ReadCurrentDay()}-{dfhack.world.ReadCurrentMonth()}-{dfhack.world.ReadCurrentYear()}
""")
Code: (console output) [Select]
save path: arena1
weather: 0
date: 2-0-1
About the only useful things it can do are pausing and unpausing the game (dfhack.world.SetPauseState()) and setting the current weather (dfhack.world.SetCurrentWeather()). There are also some functions in the dfhack.internal module that work, but not all of them (some take pointers, some return tables, etc.).

I did manage to use the struct identities used by the Lua API to make isinstance() and issubclass() work properly. Note that creating instances of any DF classes doesn't do anything yet, but things like isinstance(df.viewscreen_titlest(), df.viewscreen) work as you'd expect.
Title: Re: DFHack 0.43.05-r1
Post by: Roses on July 07, 2017, 11:48:16 pm
So here's a question for an idea I had a little while ago. Currently DF has structures for accessing data, would it be possible to create our own structures that would be accessible through DFHack? For example, currently if I want to get the strength and willpower of a unit I need to type in (away from my DF right now so the exact location might be wrong);
Code: [Select]
strength = df.global.world.units.active[x].body.physical_attributes.STRENGTH.value
willpower = df.global.world.units.active[x].status.current_soul.mental_attributes.WILLPOWER.value
But what if I could just have all of my scripts reference a single location
Code: [Select]
strength = unit[x].attribute.STRENGTH.value
willpower = unit[x].attribute.WILLPOWER.value
And then have a different script that links the two. This way if Toady ever changes how the data are structured I only need to change a single location (the link between the two) instead of changing every single script. It would also allow linking of things that are separate in DF (like unit and histfig) and putting them together so that you can reference them both with a single unit.x declaration.

I was thinking it would just be simpler to code scripts if we had a constant scheme that didn't depend on how Toady structures his data.
Title: Re: DFHack 0.43.05-r1
Post by: lethosor on July 08, 2017, 07:51:55 am
It's possible to add structures/enums/bitfields/etc. that aren't actually in DF - there are a few things like that in df-structures already. You're describing making some fields of structures available through other structures, though, which is more complicated and harder to maintain.

If you really want to access unit traits like that, you could make your own wrapper tables and use metatables (with __index and __newindex) to implement something similar to that. Here's (https://github.com/lethosor/dwarf-manipulator/blob/90d9e344f9313ee9a6869b5ad12326d012d76033/manipulator/utils.lua#L505) an example of something similar I did to attach extra data to units. (It won't do exactly what you want, since adding a "skills" table with the data you want won't update the unit's skills when you change the table, unless you set up a metatable on it too.)
Title: Re: DFHack 0.43.05-r1
Post by: Mrandom on July 09, 2017, 12:46:00 am
Hello, I've been playing adventure mode recently and wrote a couple of scripts I feel is needed. I do have questions however:

1) Is there a way to trigger some specific interaction between a character and an object? In my case, the "read" interaction to read slabs. I wrote a script that copies all the secret slabs to player's location. This allows quick access to all secrets and is super fun with mods like Masterwork. It is slow, however, because the player needs to manually pick up and read every slab. Is there a way I can just let the player learn the secrets (represented as "topic" fields of the slabs)?

2) Another script is long-distance teleport. It teleports the player by cells on the big map. e.g. "teleport-long [delta-x] [delta-y] [delta-z]". However, when teleporting near places that fast travel is prohibited, usually next to rivers or camps, it sometimes loses the reference to the player's unit and change it to another random unit. Is there any way that we can throw an exception if the player is in a position that may cause errors?

3) Also for the long-distance teleport, is there a way to check the new player position so I can loop thru z positions to make sure the player is positioned on the surface, not in the air or under the surface? i.e. check if the new position is open space or a wall.
Title: Re: DFHack 0.43.05-r1
Post by: Max™ on July 09, 2017, 02:03:17 pm
When you say long distance teleport, you mean from the adventurer screen right? Cause https://github.com/maxthyme/maxthyme-scripts/blob/master/questport.lua works even if you're not on the travel map (by kicking you into it briefly) but it puts you at the top left corner of a given block. If you wanted you could use a similar trick to bump you into travel mode, then grab the army with flags[0] set and alter the x/y pos directly, it'll handle moving the z pos for you.

If you wrote a script to grab the relevant secrets you could dfhack a book up and add the secrets as improvements. Under the improvement link there's a field for the written content, under written content you can set them to be secrets and such.
Title: Re: DFHack 0.43.05-r1
Post by: Clément on July 09, 2017, 02:49:54 pm
Hi, while studying Dwarf Therapist source code, I got few problems with the devel/export-dt-ini script.

It does not seems to give the value that DT is expecting: DT add the value from the ini file to the base address, but the script print the difference between the actual address and "rebase delta" that is, if understand correctly, the difference between DEFAULT_BASE_ADDR and the actual base address. I though of a quick and dirty fix by replacing "addr = addr - rdelta" by "addr = addr - 0x140000000 - rdelta" (0x140000000 being DEFAULT_BASE_ADDR on win64), but I actually needed to use 0x13fc00000 instead. Are DT and DFHack disagreeing on the base address? I am not sure I understand everything right about either DFHack or DT.

Note: I am also discussing this problem on the DT thread (http://www.bay12forums.com/smf/index.php?topic=122968.msg7506330#msg7506330).
Title: Re: DFHack 0.43.05-r1
Post by: Quietust on July 09, 2017, 03:34:33 pm
32-bit versions of Dwarf Therapist all expected "default absolute offsets" (i.e. the absolute addresses you get when DF loads at its default base address, with ASLR disabled) in its layout INI files, and that's what export-dt-ini.lua generates for 32-bit and 64-bit. For example, the proper offset for "cur_year_tick" in 0.43.05 Win64 should be 0x141904240.
Title: Re: DFHack 0.43.05-r1
Post by: Roses on July 09, 2017, 04:12:44 pm
It's possible to add structures/enums/bitfields/etc. that aren't actually in DF - there are a few things like that in df-structures already. You're describing making some fields of structures available through other structures, though, which is more complicated and harder to maintain.

If you really want to access unit traits like that, you could make your own wrapper tables and use metatables (with __index and __newindex) to implement something similar to that. Here's (https://github.com/lethosor/dwarf-manipulator/blob/90d9e344f9313ee9a6869b5ad12326d012d76033/manipulator/utils.lua#L505) an example of something similar I did to attach extra data to units. (It won't do exactly what you want, since adding a "skills" table with the data you want won't update the unit's skills when you change the table, unless you set up a metatable on it too.)

Hmm, well the reason I thought about it in the first place was to attach extra data to units, the rest was just an afterthought really.
Title: Re: DFHack 0.43.05-r1
Post by: Clément on July 09, 2017, 05:44:29 pm
32-bit versions of Dwarf Therapist all expected "default absolute offsets" (i.e. the absolute addresses you get when DF loads at its default base address, with ASLR disabled) in its layout INI files, and that's what export-dt-ini.lua generates for 32-bit and 64-bit. For example, the proper offset for "cur_year_tick" in 0.43.05 Win64 should be 0x141904240.

I think I understand now. What DT calls "base_addr" is actually the base address difference (same as rebase_delta from dfhack). I found that DT has hard-coded the default base address for win32 (https://github.com/splintermind/Dwarf-Therapist/blob/x64/src/dfinstancewindows.cpp#L209), that explains the value 0x13fc00000: it is actually the difference between the default base addresses for win32 and win64. If I change this value, it should work with layout from the script.
Title: Re: DFHack 0.43.05-r1
Post by: Quietust on July 09, 2017, 06:56:26 pm
I found that DT has hard-coded the default base address for win32 (https://github.com/splintermind/Dwarf-Therapist/blob/x64/src/dfinstancewindows.cpp#L209), that explains the value 0x13fc00000: it is actually the difference between the default base addresses for win32 and win64. If I change this value, it should work with layout from the script.

Code: [Select]
m_base_addr = base_addr - 0x00400000;
That's technically correct for 32-bit processes (and is the same thing DFHack uses - see "include/Memory.h"), but for 64-bit ones it should subtract 0x140000000 instead.
Title: Re: DFHack 0.43.05-r1
Post by: Algorithman on July 12, 2017, 03:17:21 pm
I wonder if it is possible to get all sitemaps of a world through dfhack (Heightmap, vegetation and such) exported. Maybe in adventurer mode? I wouldn't care about performance and no need (yet) for below ground information.

If someone has an idea how to accomplish that, pls tell me :)
Title: Re: DFHack 0.43.05-r1
Post by: PatrikLundell on July 12, 2017, 05:42:32 pm
On the world tile level it's easy and has basically been done (as PSV data), but I take it you want to go down to the detailed level? If so you'd have to somehow get DF to load each site one at a time and then dump the data in the detailed structure that's populated only when in that region (or one of the 8 surrounding ones). If you were to manually move to each place in adventurer mode the dumping itself would be fairly straightforward (you could do it in fortress mode as well, but I assume it's easier to move around in adventurer mode). If you're satisfied with less detailed info Legends Mode can provide site maps.
Title: Re: DFHack 0.43.05-r1
Post by: mifki on July 12, 2017, 06:11:05 pm
Don't know about "heightmap, vegetation and such", but I've done tile-level world exports before http://mifki.com/df/bigmap/
Title: Re: DFHack 0.43.05-r1
Post by: Algorithman on July 12, 2017, 11:16:42 pm
mifki, that's kinda the thing i need. you did it via twbt, right? i want to get a step further and save the data of each tile. like if there is a fortress wall, which kind of rock it's made of and of course its z coordinate. Would this be doable via a script plugin?
Title: Re: DFHack 0.43.05-r1
Post by: mifki on July 12, 2017, 11:43:09 pm
mifki, that's kinda the thing i need. you did it via twbt, right? i want to get a step further and save the data of each tile. like if there is a fortress wall, which kind of rock it's made of and of course its z coordinate. Would this be doable via a script plugin?

It was a custom code based on twbt. It's in worldmapexport branch, but it's a terrible mess, so I probably need to try running it again first and tell you how to use/modify it.
Title: Re: DFHack 0.43.05-r1
Post by: Algorithman on July 13, 2017, 12:03:57 am
To be more clear about my goal:

I want to create a 1st person walkable worldmap with UE4. it's mostly a learning project for me, to get a hold of the coding traps for a open world game (map chunking/LOD stuff etc). To show different tree types and ground vegetation, maybe even fauna out of the map data would be so awesome :)
Title: Re: DFHack 0.43.05-r1
Post by: Rose on July 13, 2017, 12:05:53 am
To be more clear about my goal:

I want to create a 1st person walkable worldmap with UE4. it's mostly a learning project for me, to get a hold of the coding traps for a open world game (map chunking/LOD stuff etc). To show different tree types and ground vegetation, maybe even fauna out of the map data would be so awesome :)

Have you looked at Armok Vision?
Title: Re: DFHack 0.43.05-r1
Post by: mifki on July 13, 2017, 12:06:07 am
To be more clear about my goal:

I want to create a 1st person walkable worldmap with UE4. it's mostly a learning project for me, to get a hold of the coding traps for a open world game (map chunking/LOD stuff etc). To show different tree types and ground vegetation, maybe even fauna out of the map data would be so awesome :)

Yeah, that was my ultimate goal too, so I'm happy to assist.
Title: Re: DFHack 0.43.05-r1
Post by: Max™ on July 13, 2017, 12:11:32 am
Ok so, Atkana is fucking awesome apparently. I saw the script they set up to manipulate appearance and such during adventurer creation and thought "wow, I bet that could be gotten into gm-unit" and tried but failed at getting it fully working so I showed them right?

http://www.bay12forums.com/smf/index.php?topic=164709.msg7501676#msg7501676
Got attribute editor folded into the mix, it's really damn convenient having all these accessible from a single interface, btw.
https://github.com/maxthyme/scripts/blob/master/gui/gm-unit.lua
Note that most of the work adding those was Atkana, not me, I just got the attributes hacked into place earlier.
Spoiler (click to show/hide)
For simplicity I just had the max set to 2x the entered/raised/lowered attribute value.
Title: Re: DFHack 0.43.05-r1
Post by: Algorithman on July 13, 2017, 12:38:26 am
To be more clear about my goal:

I want to create a 1st person walkable worldmap with UE4. it's mostly a learning project for me, to get a hold of the coding traps for a open world game (map chunking/LOD stuff etc). To show different tree types and ground vegetation, maybe even fauna out of the map data would be so awesome :)

Have you looked at Armok Vision?

Yes, i Know Armok Vision. But I want the whole world and not necessarily in-game (probably wouldn't work anyway with the amount of data given). And I don't want it to look like mine craft, not blocky, more sloping landscapes.
Title: Re: DFHack 0.43.05-r1
Post by: Rose on July 13, 2017, 12:58:28 am
Hm... There's ways to go about this, but I think this may not be the right thread. Anybody feel like starting a thread for the project, or should I?
Title: Re: DFHack 0.43.05-r1
Post by: Algorithman on July 13, 2017, 01:16:24 am
@mifki: that would be great

@japa: We need to think of a name first?
Title: Re: DFHack 0.43.05-r1
Post by: Rose on July 13, 2017, 01:21:02 am
http://www.bay12forums.com/smf/index.php?topic=164837.new#new

Done.
Title: Re: DFHack 0.43.05-r1
Post by: Bulwersator on July 13, 2017, 03:00:37 am
Is there existing tool that shows relationships ("Friendly terms", "Passing Acquaintance", "Pet", "Deity" etc?) or dumps this data for further processing? As many other things in DF there is a nice and interesting complexity there hidden by unwanted complexity of horrible interface and I thought that relationship viewer would be interesting and relatively simple to write.

I found https://github.com/DFHack/scripts/blob/master/gui/family-affairs.lua that would be easily adapted for listing marriages but no evidence that listing other relationships is possible (hopefully I am mistaken, I also found no open issue for that on https://github.com/DFHack/dfhack/issues).
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on July 13, 2017, 08:45:47 am
r2 is up! (https://github.com/DFHack/dfhack/releases/tag/0.43.05-r2)
Title: Re: DFHack 0.43.05-r2
Post by: Warmist on July 14, 2017, 02:24:45 pm
r2 is up! (https://github.com/DFHack/dfhack/releases/tag/0.43.05-r2)
Thanks to everyone involved for their hard work!
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on July 20, 2017, 03:11:50 pm
It looks like the change to allow Ruby scripts from separate paths can break Ruby scripts if the folder they're in has an apostrophe in its name. This is due to some highly "unusual" (read: dumb) code that loads Ruby scripts, which I was working on fixing anyway. It's not a trivial fix by any means, though, so here (https://github.com/lethosor/dfhack-scripts/blob/master/r2-ruby-patch.lua) is a script that patches DFHack to allow single quotes in path names (but will break with double quotes). It must be run once, and once only, to work, and should ideally be run before anything is loaded to avoid error messages (and so nothing is lost in case it crashes).
Title: Re: DFHack 0.43.05-r2
Post by: Altaree on July 21, 2017, 08:26:17 am
It looks like the change to allow Ruby scripts from separate paths can break Ruby scripts if the folder they're in has an apostrophe in its name.

I would call this a feature. Folder names with spaces or other odd characters need to be submerged in magma.
Title: Re: DFHack 0.43.05-r2
Post by: hertggf on July 21, 2017, 01:07:17 pm
In the dfusion lua console, is there some context where dfhack.gui.getSelectedItem() works in adventure mode?  The only way I've figured out to get a pointer to an item is to pick something up and use
Code: [Select]
item=u.inventory[#u.inventory-1].itemBut of course that only works if you can pick it up.

Any suggestions or, failing that, better workarounds?
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on July 21, 2017, 01:16:12 pm
DFusion has been removed for over a year now. Are you talking about the built-in Lua console you open with "lua"?

If you select an item (with 'a' through 'e'), it opens another screen, which really ought to support getSelectedItem() but doesn't, so I'll add support for that. It doesn't look like it's possible to add support for the main adventure mode screen, though, since it can list up to 5 items at once and there isn't a cursor you can use to distinguish between them.

(Also, you can use "item" as a read-only alias for "dfhack.gui.getSelectedItem()" in the Lua interpreter.)

Edit: okay, the reason getSelectedItem() doesn't work in viewscreen_itemst (the one you can get to with a/b/c/d/e) is because it returns the highlighted contained item there (i.e. the one selected in the list for bins/barrels/bags). I'm going to add support for the text viewer screen you can get to by pressing "v" instead.
Title: Re: DFHack 0.43.05-r2
Post by: hertggf on July 21, 2017, 02:36:22 pm
Excellent, thank you.  While we're on the topic it would be great if some of the ease of use features from fort mode could be adapted to adventure mode, especially filtering for item lists and maybe putting what's in your hands at the top of the inventory screen instead of the bottom.

Is there a discussion forum for dfhack or you guys just use irc?   Maybe I could contribute.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on July 21, 2017, 04:03:55 pm
The search plugin is fairly easy to extend, although it would require a bit more effort to support in adventure mode because most things there are shoved into one screen (searches are tied to specific screens, so you couldn't unconditionally enable a search option like you can in fortress mode).

Most discussion happens on IRC and in this thread. There was talk of making a DFHack subforum here a couple years ago, but it never happened.
Title: Re: DFHack 0.43.05-r2
Post by: hertggf on July 21, 2017, 05:07:15 pm
Some possibilities might be to add a hotkey when (l)ooking that opens a screen with an item list of whatever was under the cursor.  Then you could search, look, pick up, maybe even throw and interact with them directly from there (being able to read books without picking them up first would be a godsend)
And in the (i)nventory screen add hotkeys to drop, interact, throw, eat, remove, wear, etc rather than opening a new screen for every type of interaction.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on July 21, 2017, 05:18:50 pm
The issue tracker is also a good place to put suggestions (at least specific ones like that) so they don't get buried as easily.
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on July 21, 2017, 08:58:39 pm
Yeah, enabling search in adventure mode is a pain, I toyed with it for a bit, also travis is maddening but I guess I gotta poke at it since I got firefox updated and shit now.
Title: Re: DFHack 0.43.05-r2
Post by: Bumber on July 22, 2017, 05:39:49 pm
It looks like the change to allow Ruby scripts from separate paths can break Ruby scripts if the folder they're in has an apostrophe in its name.

I would call this a feature. Folder names with spaces or other odd characters need to be submerged in magma.
Apostrophes aren't that odd, given their use in possessives. I'd say non-English characters are more an issue, and they aren't going away anytime soon.

The following characters are forbidden for Windows folder names:
\ / : * ? " < > |

Linux only forbids / and \0.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on July 22, 2017, 06:16:34 pm
It looks like the change to allow Ruby scripts from separate paths can break Ruby scripts if the folder they're in has an apostrophe in its name.

I would call this a feature. Folder names with spaces or other odd characters need to be submerged in magma.
Apostrophes aren't that odd, given their use in possessives. I'd say non-English characters are more an issue, and they aren't going away anytime soon.

The following characters are forbidden for Windows folder names:
\ / : * ? " < > |

Linux only forbids / and \0.
Well, if double quotes are forbidden anyway, I suppose my script is more useful than I thought.

Also, another possible solution would be to add hack/scripts to script-paths.txt. However, I don't want to encourage that, because I don't know if it'll interfere with other paths in hard-to-predict ways, so I don't want people leaving it in there indefinitely.
Title: Re: DFHack 0.43.05-r2
Post by: Uzu Bash on July 26, 2017, 06:52:26 am
How do you terminate a hung script? Or any script for that matter; that would be useful to know even if it's working as designed.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on July 26, 2017, 06:58:01 am
You can stop Lua scripts by running kill-lua. Use dfhack-run to run it if you can't use the DFHack console.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on July 27, 2017, 05:31:59 am
Can someone explain how to interpret the entity_claims1 and 2 fields in df.global.world.world_data? Or is it still unknown?

Obviously it's two sets of bit map masks of bit mapped civs (as explained), but what do these masks represent (I find my goblin civ in both of them, for instance), and what are these masks intended to mask? There's an indication of a height/width of 3*3 (haven't seen anything else so far), but again, height/width of what? Trying to apply it to the geography doesn't make sense, at least not on the world tile scale, as my humans on the NE continent of a 33*33 4 square continent would claim almost everything immediately on creation (including the other continents), for instance.
Title: Re: DFHack 0.43.05-r2
Post by: Atkana on July 27, 2017, 02:06:45 pm
Bluh, it'd be nice if it was mentioned somewhere that eventful.registerReaction will only trigger on reactions with a product - I spent way longer than I should have before I worked that out. On the topic of the docs, I noticed the entry for the units module is missing at least:
Spoiler (click to show/hide)
and I didn't know the World module even existed until I stumbled across it in a script (okay, that applies to pretty much everything I know about dfhack, but what I'm saying is it doesn't appear in the docs :P)
/documentation rant

So back to my original point/problem: Anyone got a preferred goto dummy product they use for their reactions-that-actually-trigger-eventful?
Title: Re: DFHack 0.43.05-r2
Post by: Warmist on July 27, 2017, 05:00:47 pm
So back to my original point/problem: Anyone got a preferred goto dummy product they use for their reactions-that-actually-trigger-eventful?

I use
Code: [Select]
[PRODUCT:0:1:LIQUID_MISC:NONE:WATER][PRODUCT_DIMENSION:2000]
with code that cancels the creation with "call_native.value=false"
Title: Re: DFHack 0.43.05-r2
Post by: Atkana on July 28, 2017, 03:10:25 am
So back to my original point/problem: Anyone got a preferred goto dummy product they use for their reactions-that-actually-trigger-eventful?

I use
Code: [Select]
[PRODUCT:0:1:LIQUID_MISC:NONE:WATER][PRODUCT_DIMENSION:2000]
with code that cancels the creation with "call_native.value=false"
Huh, so it'll still trigger even if the reaction's only product has a 0% chance of being made? If so, is it actually necessary to cancel the creation with code?
Title: Re: DFHack 0.43.05-r2
Post by: Warmist on July 29, 2017, 02:20:56 am
So back to my original point/problem: Anyone got a preferred goto dummy product they use for their reactions-that-actually-trigger-eventful?

I use
Code: [Select]
[PRODUCT:0:1:LIQUID_MISC:NONE:WATER][PRODUCT_DIMENSION:2000]
with code that cancels the creation with "call_native.value=false"
Huh, so it'll still trigger even if the reaction's only product has a 0% chance of being made? If so, is it actually necessary to cancel the creation with code?
Probably not :P
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on July 30, 2017, 08:50:16 am
Where is "dfhack.screen" located?
It's referenced by gui.lua, and the referenced operation is similar to one defined in Screen.cpp, but the profile differs, so there's a translation layer somewhere. However, my searches have failed to find any matching file (or contents in files I've looked at).
What I'm trying to do is to create "transparent" screens that can be used as overlays on top of DF's native UI (the current attempt is to provide an overlay that shows where non displayed sites are located pre embark [e.g. lairs and refugee camps]).
So far I've managed to get a "transparent" DFHack window where I can paint things only at selected tiles, which is sufficient for my purposes technically. The problem I have is that I can't "unpaint" what's painted: skipping rendering of no longer desired tiles doesn't do anything, although I suspect it would if I let DF advance a frame (which may be where I end up anyway, since it would be nice to allow movement while the overlay is present, but callback based operation is a bit messy).
Another alternative (which is the source if the question) is to read what's on the tile and before I put the overlay there and cache the info to paint the original info on the overlay to emulate it being cleared on that tile (or just paint all of it with the original data to start with).

Edit: Corrected the above by replacing "tick" with "frame".
Title: Re: DFHack 0.43.05-r2
Post by: Warmist on July 30, 2017, 11:21:03 am
Where is "dfhack.screen" located?
It's referenced by gui.lua, and the referenced operation is similar to one defined in Screen.cpp, but the profile differs, so there's a translation layer somewhere. However, my searches have failed to find any matching file (or contents in files I've looked at).
What I'm trying to do is to create "transparent" screens that can be used as overlays on top of DF's native UI (the current attempt is to provide an overlay that shows where non displayed sites are located pre embark [e.g. lairs and refugee camps]).
So far I've managed to get a "transparent" DFHack window where I can paint things only at selected tiles, which is sufficient for my purposes technically. The problem I have is that I can't "unpaint" what's painted: skipping rendering of no longer desired tiles doesn't do anything, although I suspect it would if I let DF advance a frame (which may be where I end up anyway, since it would be nice to allow movement while the overlay is present, but callback based operation is a bit messy).
Another alternative (which is the source if the question) is to read what's on the tile and before I put the overlay there and cache the info to paint the original info on the overlay to emulate it being cleared on that tile (or just paint all of it with the original data to start with).

Edit: Corrected the above by replacing "tick" with "frame".
To do transparent display in c++ is quite easy. Either subclass the screen you want and then call parent->render (not sure the exact naming) or use vmethod interposing to replace the render and then call  INTERPOSE_NEXT(render) (which calls the next inserted function - usually the original)
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on July 30, 2017, 11:30:41 am
You probably wouldn't want to subclass DF screens.

Anyway, as long as you're calling render() on the parent screen every time your screen is rendered, it should work. If it doesn't, can you post your code?
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on July 30, 2017, 11:52:22 am
I'm using Lua, as I am under the impression that GCC isn't compatible with small soft compilers.

I've been using the pre embark screen as my test bed.
I've been messing around with various approaches, and my code is doing anything as it's purely experimenting to see what might work. I'm currently calling Screen:renderParent() every time the 'm' key is pressed and nothing else, after a starting state of putting up a DFHack "transparent" frame (the clearing of the innards removed from an overriding onRenderFrame(), a label, and a Grid widget that doesn't actually render anything at all at the moment).
renderParent() gives odd results, as random parts of the screen gets blanked out at random calls. When I did sent an 'm' on to the parent DF correctly moved the embark frame, but did not clear out the old one and parts get overwritten but with the old contents still displayed (flickering between two results when F1/F2 becomes available, for instance).

The mess looks like this:
Spoiler (click to show/hide)
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on July 30, 2017, 12:59:45 pm
You can only call renderParent from render (or onRender, etc.). Calling it from onInput is likely the cause of the issues you're having.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on July 30, 2017, 01:41:02 pm
Thanks lethosor!

A few small changes results in both DF's embark rectangle moving and my "application" marker moving at the same time without leving trails behind.
I still wouldn't mind knowing how to read the DF screen for future use, but this will certainly bring me on to my next stumbling block on this "project".
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on July 30, 2017, 10:03:02 pm
dfhack.screen.readTile(), I think. (Although it's not as easy for your purposes here, of course.)
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on July 31, 2017, 02:50:58 am
Thanks again, lethosor. It looks like readTile (x, y) returns the tile info just fine, based on my simple experiment.
Title: Re: DFHack 0.43.05-r2
Post by: SalmonGod on July 31, 2017, 11:29:19 pm
PTW
Title: Re: DFHack 0.43.05-r2
Post by: gnome on August 02, 2017, 05:24:10 am
Someone told me this mod adds a little bit of mouse functionality for some menus - any chance that extends to the conversation menus in Adventure Mode? Those things are infuriating to scroll through after awhile.
Title: Re: DFHack 0.43.05-r2
Post by: Atkana on August 03, 2017, 03:07:20 am
So back to my original point/problem: Anyone got a preferred goto dummy product they use for their reactions-that-actually-trigger-eventful?

I use
Code: [Select]
[PRODUCT:0:1:LIQUID_MISC:NONE:WATER][PRODUCT_DIMENSION:2000]
with code that cancels the creation with "call_native.value=false"
Huh, so it'll still trigger even if the reaction's only product has a 0% chance of being made? If so, is it actually necessary to cancel the creation with code?
Probably not :P
Okay, so I finally got around to trying this out and it seems (at least based on my tests using DFhack 0.43.05-r2):
:(
Though I guess if I have the product be a minor amount of water, and it doesn't have a container it'll just splash on the ground when it's produced?
Fake edit: Nope, it gets stored in the workshop

I hate Fortress Mode modding  :'(
Title: Re: DFHack 0.43.05-r2
Post by: Warmist on August 03, 2017, 05:40:31 am
I hate Fortress Mode modding  :'(
Me too. The raws modding too :P.

Can you print all the args to lua? I.e.
Code: [Select]
function reaction() local args={...}; printall(args); end
Title: Re: DFHack 0.43.05-r2
Post by: Atkana on August 03, 2017, 06:10:23 am
I hate Fortress Mode modding  :'(
Me too. The raws modding too :P.

Can you print all the args to lua? I.e.
Code: [Select]
function reaction() local args={...}; printall(args); end
Oh derp I didn't think to do that when trying to work stuff out.
It only receives 6 args, where the 7th should be the call_native: 1 is a reaction, 2 is a reaction product item table, 3 is a unit, 4 is a table of items, 5 is a table of reaction reagents, 6 is a table of items.

Maybe it's something related to the reaction using a custom building? That's the only thing I could think of that deviates slightly from the norm.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 03, 2017, 08:23:03 am
Someone told me this mod adds a little bit of mouse functionality for some menus - any chance that extends to the conversation menus in Adventure Mode? Those things are infuriating to scroll through after awhile.
mousequery only deals with the fortress mode map. Don't the adventure mode menus have search functionality built-in in vanilla DF?
Title: Re: DFHack 0.43.05-r2
Post by: argh226 on August 03, 2017, 08:33:46 am
Hi all,

I don't know if it has been mentioned but I might have found something odd with planning tool.

I use labormanager and planning tool and once in a while, for some reason it don’t place item anymore, even if I have it.  I think the trigger is when I use the alert and burrow to get all dwarves inside and once the gate close, I release the alert and it stops working.  Not 100% sure tho...

I would also add something else, labormanager doesn't work very well with hauler... it’s a low priority that I have to switch to autolabor once in a while to get everything laying around.

Btw dfhack does make this game far much enjoyable! :)
Title: Re: DFHack 0.43.05-r2
Post by: Wiking on August 03, 2017, 08:50:55 am
I'm having some problems getting the autofarm plugin to work properly for me, so I was wonder what am I doing wrong?
Using latest dfhack 0.43.05-r2

Using this command:
autofarm threshold 200 helmet_plump tail_pig pod_sweet rye vine_whip grass_wheat_cave
autofarm start
(https://i.gyazo.com/5db5b7f7e9415b02ac663453e699937d.png)

For some reason autofarm doesnt see my Pig Tails, Cave wheat and Whip Vines, even though I have 300+ of each.
(it shows current:0 for those three)
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on August 03, 2017, 08:55:14 am
I have no actual idea for that pluging, but a lot of scripts and plugins are case sensitive, i.e. you need to type RYE etc.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 03, 2017, 09:06:19 am
autofarm is a script. Also, given that the console output contains "RYE", while the command contains "rye", I don't think case-sensitivity is the issue.

Hi all,

I don't know if it has been mentioned but I might have found something odd with planning tool.

I use labormanager and planning tool and once in a while, for some reason it don’t place item anymore, even if I have it.  I think the trigger is when I use the alert and burrow to get all dwarves inside and once the gate close, I release the alert and it stops working.  Not 100% sure tho...

I would also add something else, labormanager doesn't work very well with hauler... it’s a low priority that I have to switch to autolabor once in a while to get everything laying around.

Btw dfhack does make this game far much enjoyable! :)


Is labormanager relevant to the issue here? ab9rf (the person who wrote labormanager) says she hasn't had issues with it interfering with buildingplan, but you can check it by running "unload labormanager" and see if the issue persists.

Also, providing a save would be really helpful. So far nobody with this issue has provided a save, which makes it hard to figure out what the issue is.
Title: Re: DFHack 0.43.05-r2
Post by: argh226 on August 03, 2017, 12:01:39 pm
Will do that and provide a save for the next time.
Title: Re: DFHack 0.43.05-r2
Post by: Warmist on August 03, 2017, 02:50:27 pm
I hate Fortress Mode modding  :'(
Me too. The raws modding too :P.

Can you print all the args to lua? I.e.
Code: [Select]
function reaction() local args={...}; printall(args); end
Oh derp I didn't think to do that when trying to work stuff out.
It only receives 6 args, where the 7th should be the call_native: 1 is a reaction, 2 is a reaction product item table, 3 is a unit, 4 is a table of items, 5 is a table of reaction reagents, 6 is a table of items.

Maybe it's something related to the reaction using a custom building? That's the only thing I could think of that deviates slightly from the norm.
It shouldn't matter. In fact ALL my reactions use custom buildings. Hmm maybe something broke and nobody noticed?
Title: Re: DFHack 0.43.05-r2
Post by: gnome on August 04, 2017, 04:59:23 am
Someone told me this mod adds a little bit of mouse functionality for some menus - any chance that extends to the conversation menus in Adventure Mode? Those things are infuriating to scroll through after awhile.
mousequery only deals with the fortress mode map. Don't the adventure mode menus have search functionality built-in in vanilla DF?
Search functionality is only in the deeper conversation menus like if you're picking from a list of incidents to summarize - but it isn't available nor would it be useful at the base menu where you select the main options. What bothers me is like when I want to ask a lot of people the same thing, and so every time I have to type the + or - key x amount of times to get to the option I want, and I have to do this a thousand times until I find someone who has the information I need. Thanks for the response, though, just checking.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 04, 2017, 08:22:25 am
Search functionality is only in the deeper conversation menus like if you're picking from a list of incidents to summarize - but it isn't available nor would it be useful at the base menu where you select the main options. What bothers me is like when I want to ask a lot of people the same thing, and so every time I have to type the + or - key x amount of times to get to the option I want, and I have to do this a thousand times until I find someone who has the information I need. Thanks for the response, though, just checking.
Which ones aren't "deeper"? I'm getting this after I choose a person to talk to, which has a filter:
Spoiler (click to show/hide)
Are you just referring to the first menu where you can choose who to talk to?
Title: Re: DFHack 0.43.05-r2
Post by: gnome on August 04, 2017, 11:05:59 am
Search functionality is only in the deeper conversation menus like if you're picking from a list of incidents to summarize - but it isn't available nor would it be useful at the base menu where you select the main options. What bothers me is like when I want to ask a lot of people the same thing, and so every time I have to type the + or - key x amount of times to get to the option I want, and I have to do this a thousand times until I find someone who has the information I need. Thanks for the response, though, just checking.
Which ones aren't "deeper"? I'm getting this after I choose a person to talk to, which has a filter:
Spoiler (click to show/hide)
Are you just referring to the first menu where you can choose who to talk to?
Yes the first menu is what I'm referring to. What I'm really talking about with the mouse is really probably only for the sake of shaving off a few seconds per encounter (which does add up, mind you), but when applied to the aforementioned "deeper" menus I'm sure there'd be a lot of benefit in that area as well. Or hotkeys to each option like in the combat menu would be great, that way doing simple things where you often remember the hotkey for it would go by so much quicker. Like asking people permission to stay the night. It just gets a little tedious and it makes my eyes sore.
Title: Re: DFHack 0.43.05-r2
Post by: Nilsou on August 04, 2017, 06:22:31 pm
Hi ! Just to know. Is diggingInvaders included in Dfhack currently ? Documentation say yes, some folks on forum say yes when i asked here :
http://www.bay12forums.com/smf/index.php?topic=165077.0

But the dedicated thread say no (no response since 2014) : http://www.bay12forums.com/smf/index.php?topic=127116.msg7527593#new
The files from dfhack does not include a plugin of this name and the command is not recognised in game ...


Did i miss something ?
Title: Re: DFHack 0.43.05-r2
Post by: Clément on August 05, 2017, 02:37:17 am
The source is here (https://github.com/DFHack/dfhack/tree/master/plugins/diggingInvaders). But it is not compiled because this line is commented (https://github.com/DFHack/dfhack/blob/master/plugins/CMakeLists.txt#L111). The change was made by this commit (https://github.com/DFHack/dfhack/commit/8916aba3bf29f81a426485a779a623edd4b1be61).
Title: Re: DFHack 0.43.05-r2
Post by: Nilsou on August 05, 2017, 09:10:14 am
Hum seems to have some trouble with digging invaders in 64 i think as the commit is "Win64 fix" If they had corrected the plugin instead of deleting it would have been better ...

As far as i can see in the digginginvader code there is no special code that are not 64bit compatible... and as no comment explain why ... may be someone with the code should try compiling and see ...

Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 05, 2017, 11:01:25 am
Hum seems to have some trouble with digging invaders in 64 i think as the commit is "Win64 fix" If they had corrected the plugin instead of deleting it would have been better ...

As far as i can see in the digginginvader code there is no special code that are not 64bit compatible... and as no comment explain why ... may be someone with the code should try compiling and see ...
The plugin was not deleted. It was excluded from being built. Clément just linked you to the code too.

I don't know why mifki excluded it. Perhaps it didn't compile on 64-bit Windows, but I don't have a 64-bit Windows build machine to test on. I tried asking mifki why he made that change, but didn't get an answer.
Title: Re: DFHack 0.43.05-r2
Post by: Nilsou on August 05, 2017, 12:49:48 pm
I understood that the code was not deleted ^^
I have a 64bit machine, but well, i'm not common nor with Cmake nor with dfhack.

Well, i guess we have to wait for an answer ...
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on August 05, 2017, 07:42:12 pm
Someone told me this mod adds a little bit of mouse functionality for some menus - any chance that extends to the conversation menus in Adventure Mode? Those things are infuriating to scroll through after awhile.
mousequery only deals with the fortress mode map. Don't the adventure mode menus have search functionality built-in in vanilla DF?
Search functionality is only in the deeper conversation menus like if you're picking from a list of incidents to summarize - but it isn't available nor would it be useful at the base menu where you select the main options. What bothers me is like when I want to ask a lot of people the same thing, and so every time I have to type the + or - key x amount of times to get to the option I want, and I have to do this a thousand times until I find someone who has the information I need. Thanks for the response, though, just checking.
Don't adv-rumors and gather-quests cover most of these cases? I might have the names wrong btw, but I think those are the current ones.
Title: Re: DFHack 0.43.05-r2
Post by: Uzu Bash on August 05, 2017, 08:37:56 pm
I've noticed very consistent crashes at the corners of region tiles, after entering then leaving them (playing advmode.) Fast traveling away often but not always counters this. Is there a particular plugin that could be causing this?
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 05, 2017, 08:42:35 pm
I've noticed very consistent crashes at the corners of region tiles, after entering then leaving them (playing advmode.) Fast traveling away often but not always counters this. Is there a particular plugin that could be causing this?

Run "unload -all" and see if it persists.
(If you're using TWBT, you'll have to disable it in init.txt or a launcher and restart DF. Actually, you might try that first, just to see if it helps.)
Title: Re: DFHack 0.43.05-r2
Post by: Uzu Bash on August 05, 2017, 09:28:18 pm
Actually turning off multilevel and reloading the map has stabilized the region corners. So I must be "some users" who experience crashes from it.
Title: Re: DFHack 0.43.05-r2
Post by: OluapPlayer on August 09, 2017, 08:44:53 am
Hello,

I've been experiencing problems with the dwarfvet plugin. Trying to use it causes the game to close itself without warning. i.e. an injured cat goes to the hospital to rest, a dwarf goes to the hospital to take care of it, and then suddenly the game shuts down completely. The time it takes for the game to shut down seems completely random; sometimes it happens right after the animal starts resting, sometimes it waits until the animal is taken care of, but it always happens eventually.

I've taken a look through the thread and the issue tracker and didn't notice any mention of this, so I'm wondering if I'm the only one with the problem. I've experienced it since the alpha releases.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 09, 2017, 10:54:26 am
I've experienced it since the alpha releases.

The entire purpose of the alpha releases was for people to report issues like that. If you don't, they won't magically be fixed. Also, that is a crash.

That said, have you narrowed it down to dwarfvet? That is, if dwarfvet is completely disabled (run "unload dwarfvet" to be sure), does it still crash?
Title: Re: DFHack 0.43.05-r2
Post by: OluapPlayer on August 09, 2017, 12:16:29 pm
The entire purpose of the alpha releases was for people to report issues like that. If you don't, they won't magically be fixed. Also, that is a crash.

That said, have you narrowed it down to dwarfvet? That is, if dwarfvet is completely disabled (run "unload dwarfvet" to be sure), does it still crash?

Well I'm sorry for being unaware an issue tracker existed at the time, since it was an alpha release I expected bugs to exist and assumed other people would notice the problem, given how easy it is to reproduce.

And yes, dwarfvet is definitely the issue. The game runs flawlessly until I enable it. Unloaded and loaded it, same problem.
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on August 11, 2017, 04:44:46 pm
Hmmm, anybody got any better ideas for the current civ populations during worldgen?

I was going in to df.global.world.entity_populations and doing a check with df.historical_entity.find(epops[k].civ_id).entity_raw.code=='BLAH' before summing the .counts there and displaying them on screen with a total value gotten by just summing those, but for some reason whether I try for k=0,#epops-1,1 or for i,k in ipairs(epops) it doesn't want to count all of them and I end up getting from about half to all but a couple hundred counted when compared against the numbers from the world_sites_and_pops export. Naturally I tried to locate that block of data but have no clue where the hell it is.
Never mind, just went in and grabbed the world_data.sites so I could use the inhabitants[k].race with a find and check for dwarf/gob/etc and just sum those.

It's still a little short of the values in the pops and exports but I think it's just skipping the outcast populations? Not that either, weird that it is off by such a small amount.

Also anybody got a clean/handy/favorite way to go through and do a "grab these numbers from this table and sum them" with lua?
Title: Re: DFHack 0.43.05-r2
Post by: oldmansutton on August 12, 2017, 05:29:19 pm
I've been playing with visitors in dfhack lately, and made a discovery today.  If you flip the flags3.unk31 flag to false on a visiting guest (dancer, merc, scholar, etc), they show up in the "Other" tab of the View Units list as just "Visitor" instead of "Guest / Activity".  If you "v"iew the unit, they will be missing the Guest information in general.   If you flip it back to true, they show up as a guest again.

I'm continuing to look into other visitor information and unknown flags, if this information is useful, I'll keep you posted.  If there's a better place to report this information, please let me know.

Thanks!
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on August 12, 2017, 06:24:05 pm
On that note, unit.flags3.unk29 is "marked for gelding". I guess historical_unit.info.wounds.anon_3 0 is dead and 1 is gelded, but not certain.

@lethosor: While at it might be worth noting that, reading dwarvet at line 655 (https://github.com/DFHack/dfhack/blob/master/plugins/dwarfvet.cpp), a naturalized human member of fort will be an Untamed Member of Own Civ who is not a Dwarf - which seems like it'd pass the checks for a reverted previously-tamed animal to unset civ_id, I guess breaking in the same way makeown does.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 13, 2017, 10:36:14 am
I'm continuing to look into other visitor information and unknown flags, if this information is useful, I'll keep you posted.  If there's a better place to report this information, please let me know.
Maybe https://github.com/dfhack/df-structures?

@lethosor: While at it might be worth noting that, reading dwarvet at line 655 (https://github.com/DFHack/dfhack/blob/master/plugins/dwarfvet.cpp), a naturalized human member of fort will be an Untamed Member of Own Civ who is not a Dwarf - which seems like it'd pass the checks for a reverted previously-tamed animal to unset civ_id, I guess breaking in the same way makeown does.
I've never worked with dwarfvet, sorry. If there's an issue with makeown, is it documented and/or is there a fix?
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on August 13, 2017, 01:10:47 pm
Damn damn damn, how the hell do you get a showListPrompt dialog to pass the chosen value to a showInputPrompt dialog?

Got a "find type" function working with gm-editor and goddammit does it look tantalizing:
Spoiler (click to show/hide)
The idea being you can just pop that up to track down/filter to a specific type and then input the value and do like df.creature_raw.find(440) or whatever without having to pull up a gui/gm-editor df page to find all the various ones.

I was trying various things like so:
Code: [Select]
function GmEditorUi:find_type()
    local list={}
    for i in pairs(df) do
        table.insert(list,{text=('%s'):format(tostring(df[i]), i)})
    end
    guiScript.start(function(choice)
        dialog.showListPrompt("Select type to find:",nil,COLOR_WHITE,list,
             dialog.showInputPrompt(tostring(trg_key),"Value to find:",COLOR_WHITE,
                "",function()
                        local tp = ""
                        self:pushTarget(df.choice.find(tp))
                    end))
        end)
end
With lots of fucking around trying different local declarations, having the input spawned from outside the list, having the list return the choice local, and so forth, it feels like there's a "well Max, you've got the dumb because all you do is ________" method here but fuck if I can find it.

Oh and the gui.script bit in there was from an earlier attempt and I just left it in place though I switched to the regular gui.dialog versions as the only error is: /home/thefunk/.df/hack/scripts/gui/gm-editor.lua:334: attempt to index a nil value (field 'choice') when the input box shows up and I try to confirm the value.
Title: Re: DFHack 0.43.05-r2
Post by: Prester on August 13, 2017, 01:36:10 pm
i have a question:

when i try to use tiletypes it pretty much works as advertised.

but my problem is: i wanna add some clay and sand to my map and all i manage to do is adding different stone types, but whenever i try to "paint soil sand_red" or "paint m sand" or whatever it wont work. all it does is paint soil or stone.

what i was searching for the last 2 hours is some kind of LIST of available materials but i couldnt find anything. so my question: how do i select any kind of sand or clay as painted material?

thanks for making dfhack, its amazing <3
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on August 14, 2017, 04:28:13 am
@lethosor: it's documented in the comments right after that, yeah, though not in DFHack Plugins — DFHack 0.43.05-r2 documentation (https://dfhack.readthedocs.io/en/stable/docs/Plugins.html).
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on August 18, 2017, 01:54:08 pm
Man, still can't figure out what is breaking this, it's slapped into gm-editor and it loads up the df.types properly, but I've lost track of the ways I've tried to make it pass the type from the list prompt to the input prompt so you could scroll down and find the history_event entry and get prompted to enter 334 resulting in gm-editor opening df.history_event.find(334) for you, right?
Code: (gm-editor tinkering) [Select]
function GmEditorUi:find_type()
    local list={}
    for i in pairs(df) do
        table.insert(list,{text=('%s'):format(tostring(df[i]), i)})
    end
    guiScript.start(function()
        local choice=guiScript.showListPrompt("Select type to find:",nil,3,list,nil,true)
        if choice then
            dialog.showInputPrompt(tostring(choice),"Value to find:",COLOR_WHITE,
            "",function()
                local tp = ""
                self:pushTarget(df.choice.find(tp))
            end)
        end
    end)
end

Tried having the input setup in another GmEditorUi:blah function and calling it, tried making it a local function blah inside the find_type one, tried using getSelectedValue/Key/EnumType or currentTarget but I'm clearly missing something where either you can't just pass those values from list prompts to input prompts like that or I'm overcomplicating it/overlooking an obvious method.
Title: Re: DFHack 0.43.05-r2
Post by: Uzu Bash on August 22, 2017, 03:28:43 pm
In the armies structure, army_T_members, unk_4 to unk_c are counters for hunger, thirst and stored_fat. The unit data is located in counters2.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 22, 2017, 10:15:12 pm
Man, still can't figure out what is breaking this, it's slapped into gm-editor and it loads up the df.types properly, but I've lost track of the ways I've tried to make it pass the type from the list prompt to the input prompt so you could scroll down and find the history_event entry and get prompted to enter 334 resulting in gm-editor opening df.history_event.find(334) for you, right?

How exactly is this different from the existing feature where you can press "i" with a numeric field highlighted (GmEditorUi:find_id())? Am I missing something?

Quote
Code: (gm-editor tinkering) [Select]
function GmEditorUi:find_type()
    local list={}
    for i in pairs(df) do
        table.insert(list,{text=('%s'):format(tostring(df[i]), i)})
    end
    guiScript.start(function()
        local choice=guiScript.showListPrompt("Select type to find:",nil,3,list,nil,true)
        if choice then
            dialog.showInputPrompt(tostring(choice),"Value to find:",COLOR_WHITE,
            "",function()
                local tp = ""
                self:pushTarget(df.choice.find(tp))
            end)
        end
    end)
end
Several things wrong that I noticed:

- guiScript.showListPrompt() returns three values, and the third one is the one you want (I think): local ret, idx, choice=guiScript.showListPrompt(...)
- "df.choice" definitely isn't what you want, since that's the same as df["choice"]. You probably want df[choice], or df[choice.something]. It's been a while since I've dealt with that.
- The "tp" argument you're passing to find() (as in df.choice.find(tp)) is always an empty string.

In the armies structure, army_T_members, unk_4 to unk_c are counters for hunger, thirst and stored_fat. The unit data is located in counters2.
A pull request would be nice. I opened https://github.com/DFHack/df-structures/issues/211 so it doesn't get buried here.
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on August 23, 2017, 09:36:56 pm
What I was trying to do was let you pull up something like that find id (which I never actually got working because it never did anything when I tried it since I didn't aim it at a nuimber) except have it work like opening "gui/gm-editor df" and then let you search for an entry from the df.type list.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 24, 2017, 10:23:30 am
Ah, that makes more sense. Essentially the equivalent of "gui/gm-editor df.type.find(id)", right? (I don't think it supports expressions like that, so your thing would be useful.) Are you thinking of having it be an in-editor option like the existing "i" key, or a flag to pass to gui/gm-editor (like "gui/gm-editor -i" to open that menu)?
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on August 25, 2017, 06:05:52 am
I was working on it as an in-editor keybind to make use of the gui power baked in, just got stumped on making it grab the chosen entry from the listprompt and pass it to an inputprompt so it pulls up that df.type.find(id) page.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on August 25, 2017, 06:58:29 am
DFHack plugin writing question (win32 currently, if it makes a difference):
I'm trying to write a plugin, but I'm puzzled by some random DF crashes, and I'm unsure whether I am to blame or whether my plugin is merely a canary exposing existing DF bugs.
DF occasionally crashes at game cleanup or game exit and the cause every time I've looked at it has been pointer access violation in ntdll.dll, and I've seen similar DF behavior (without knowledge of where it crashed) in the past, in particular with the 0.40.X versions (LNP, so DFHack was present). My plugin allocates memory but does not write to any DF structure (but reads a lot), although simulated key input is used to order the cursor on the pre embark map to move (and the underlying data structures to be loaded by DF).
However, the crashes happen when DF cleans up its data, not when my plugin tries to clean up its own stuff (of course, I've screwed up that as well, numerous times), which has already happened at that point. If I understand it correctly, failure on my part to clean up plugin memory allocation will merely result in a memory leak, not a crash, as DF itself has no knowledge of that memory and thus shouldn't do anything at all with it.
Writing data outside of the bounds of my own structures could potentially corrupt DF data, but most of the time it results in a crash at the time the plugin writes it, and it seems unlikely that kind of error would occasionally screw up DF's data but never cause the plugin to crash despite quite a few plugin test/fix/retest cycles for various errors/added code.
Title: Re: DFHack 0.43.05-r2
Post by: ab9rf on August 25, 2017, 11:29:37 am
DFHack plugin writing question (win32 currently, if it makes a difference):
I'm trying to write a plugin, but I'm puzzled by some random DF crashes, and I'm unsure whether I am to blame or whether my plugin is merely a canary exposing existing DF bugs.
DF occasionally crashes at game cleanup or game exit and the cause every time I've looked at it has been pointer access violation in ntdll.dll, and I've seen similar DF behavior (without knowledge of where it crashed) in the past, in particular with the 0.40.X versions (LNP, so DFHack was present). My plugin allocates memory but does not write to any DF structure (but reads a lot), although simulated key input is used to order the cursor on the pre embark map to move (and the underlying data structures to be loaded by DF).
However, the crashes happen when DF cleans up its data, not when my plugin tries to clean up its own stuff (of course, I've screwed up that as well, numerous times), which has already happened at that point. If I understand it correctly, failure on my part to clean up plugin memory allocation will merely result in a memory leak, not a crash, as DF itself has no knowledge of that memory and thus shouldn't do anything at all with it.
Writing data outside of the bounds of my own structures could potentially corrupt DF data, but most of the time it results in a crash at the time the plugin writes it, and it seems unlikely that kind of error would occasionally screw up DF's data but never cause the plugin to crash despite quite a few plugin test/fix/retest cycles for various errors/added code.
Crashes at exit in the runtime library are almost always caused by memory arena corruption, which means that you're writing to a freed pointer or overrunning an allocated buffer, which usually means a fencepost error somewhere.
Title: Re: DFHack 0.43.05-r2
Post by: Roses on August 25, 2017, 12:18:23 pm
So I am finally digging myself out from a large pile of work and getting back to DF modding/script writing. Something I had thought about while I was away was an ability to link my journal entries (for reference the post about my journal can be foundhere (http://www.bay12forums.com/smf/index.php?topic=152762.msg7404330#msg7404330)). Ideally you could look up a creature, see its butcher components, select one and see the material information, then if there are reactions that use it for a reagent you could select that to see the reaction, then look at the buildings that have that reaction, etc... With simply pressing escape taking you to the previous screen.

Now I think I can do this by redoing the way I create the journal entries and creating a tree structure and simply creating new viewscreens each time you select something, but I was wondering if there was a more efficient way to "link" two or more separate viewscreens instead of having to construct a complex tree.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on August 25, 2017, 01:44:12 pm
Thanks ab9rf, that's the info I needed (although not the one I wanted, of course, but rather an unpleasant correct one than a pleasing lie).
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on August 25, 2017, 08:44:18 pm
Hm. Toying with gui.FramedScreen for an indicator. Noticed that when fps/gfps < 1+numbers of screen I'm dismissing, screen:dismiss() can briefly blink game screen black.

Given that, is there a reason beyond onDismiss() to not just set the screen object to nil and have it poof without blinking? Graphical glitches, or..?
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 26, 2017, 09:21:17 am
Hm. Toying with gui.FramedScreen for an indicator. Noticed that when fps/gfps < 1+numbers of screen I'm dismissing, screen:dismiss() can briefly blink game screen black.
All screens will do that, sometimes. If you decrease your FPS setting to 10 (you can use [Alt][-] by default) and enter and exit the options (esc) menu, you'll notice a black screen when exiting but not when entering (probably).

Quote
Given that, is there a reason beyond onDismiss() to not just set the screen object to nil and have it poof without blinking? Graphical glitches, or..?
No! First, that won't work without modifying the list of screens in df.global.gview.view (although maybe that's what you meant). Also, it will leak memory, because the screen won't be deleted properly, and might result in feed()/render()/logic() getting called on the wrong screen for a frame (or worse, crashing).

Besides calling DFHack's onDismiss(), screen.dismiss() pretty much only sets the screen's breakdown_level, which results in DF cleaning up the screen safely at an appropriate time (not instantly). You should generally always use that (except maybe in weird cases, e.g. where the screen has never been displayed).
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on August 26, 2017, 10:50:55 am
Yeah, I noticed the behaviour for vanilla screens too. In fact, setfps 10 is my litmus test, since I know at least some players run with at least gfps at 10 (not that it'd matter if actual fps is higher).

I initially went by modifying screen._native.parent.child or df.global.gview.view, but then I realized that screen._native.parent.child is screen._native, and tested that both poof it without blinking.

Shame it leaks memory, then - I'd have assumed that lua garbage collection would clean up the table that I don't know is being used anywhere, but I guess it is not so. (And yes, badly toying with this does indeed result in errors or even DF crashes. i.e. setting the parent.child to nil and then calling screen:dismiss() without waiting two frames in-between, amongst many, many, many other variants.)

For reference, code that seemed to work fine:

Code: [Select]
local myscreen = dfhack.gui.getCurViewscreen()-- df.global.gview.view.child.child

dfhack.timeout(100, "frames", function()
myscreen.parent.child = nil
dfhack.timeout(2, "frames", function()
newscreen:dismiss()
dfhack.println("screen is dismissed " .. tostring(newscreen:isDismissed()))
end)

end)

Tested it while running firefox in background (with slightly complicated screen object) by pasting 101 lines of screen-making into console and DF went from 383,3 MB to up to highest point 663 MB while using 1 CPU at full blow, then down to 628,2 MB after all were gone and game had returned to dwarfmode/Default - which averages to a 2,42 MB of RAM per screen.

However,  doing that same test with just :dismiss() after 100 frames resulted in 384,0 MB → high of 900+ before even being done *killed at this point and reran with quit firefox RAM* - high of 508→ remained there after all were gone, an average of 1,23 MB. Unlike before threw a bunch of errors.

Then reran initial to be fair with also less demand on ram and got 381,3 → high of 431,1 → remained there, for average of 0,49 MB per screen.

It seems this has less of a memory leak, in both cases? Couldn't even run 101 screens with firefox eating vast majority of RAM with the default :dismiss().

*befuddled*

Anyway, it seems that one can improve on DF's cleanup. No crashes with that, but just few tests in dwarfmode. Though I do have the question of what is still left hanging with the above method?
(It'd be also nice if you could know if this was fine, but ain't nobody who knows that for sure.)

Hmm...Maybe screen object itself. *Tests with newscreen= nil after the line and fox restarted* 380,2 →429,5. 0,49 still.
Title: Re: DFHack 0.43.05-r2
Post by: Rose on August 26, 2017, 10:59:43 am
C++ doesn't have garbage collection.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 26, 2017, 01:39:55 pm
C++ doesn't have garbage collection.
Exactly. Lua screens also contain a pointer to an underlying C++ object (that's what "_native" is), and that is what won't get garbage-collected (possibly other things as well).

I'm not entirely sure what you're saying with your benchmarking results. dismiss() shouldn't be leaking memory. It might use a bit more memory to actually run, and because Lua garbage collection happens at unpredictable times, it's hard to know when that will get cleaned up. Also, the script you posted won't work, because you're referring to "myscreen" and "newscreen".
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on August 26, 2017, 04:04:55 pm
Ah well. Read that lua did have garbage collection(Programming in Lua : 11.6 (http://www.lua.org/pil/11.6.html)), and assumed it'd apply to the lua things I create. Ultimately, in the tests above I just displayed 9 lines of text.

And well, sure the code snippet won't work on it's own; myscreen is defined, but newscreen is a modified gui.Framedscreen obtained by a screen constructor function.

---

What/why am I benchmarking?
Well, you said that the main concerns would be  memory leaking and flickering in a different way, provided it doesn't crash. I'm testing how much memory does leak, and whether setting viewscreen to nil before dismissing  the gui.Framedscreen results in a bigger memory leak.

Hm, to further test that dismiss doesn't leak memory with something simpler...Using a simpler gui/hello-world with 100 frames to dismiss results in 381,4 MB → 385,7 MB and stays there, or 0,04 MB per screen. (Fair enough, the modified screen is more than a magnitude larger all right.)

Since that was kind of small difference, ran it 101 times again without closing down DF this time and it went from 385,7 to 387,2. 4,3 MB vs 1,5. A third 101 goes to 378,8.

Decreasing each time...going back to the more complex screen used in initial benchmarking last page, two x 101 dismiss-only runs bring it from 380,7 MB → 1,3 GB→2,6 GB→didn't run a third time (Also wtf.). Three runs that use the code snippet setting to nil before dismiss go 380,1 MB → 648,3→814,1 →813,6 MB.

----

Note that all the tests are performed on linux lubuntu distro with setfps 10 - the RAM drain is magnitudes smaller on higher fpses, which, combined with the stabilizing memory usage for 101 made-and-dismissed screen makes me thing that DF requests RAM space, resizes lazily unless total RAM is a concern, but keeps using same space if it is free.

This pretty much puts to rest my concerns about memory leaking with the code snippet, as long as I don't generate hundreds of screens at the same time.

Though, while they're not complete, wildly different RAM usages suggests something more is going on with my custom screens (that also interact with dfhack's keybinding, gui and probably onStateChange in the tests).

Given that, if you have enough free time handy, I'd ask you to check my code for mem leaks: tests used 101x `testenvtester (https://pastebin.com/TWmYYKiZ) aleph beta ral` that calls on `gui/construct-screen.lua (https://pastebin.com/SXJx97eH)` (whose .nonblinky_dismiss ends up being doing, like most of the code, ultimately zilch here) that calls on keybinding that can - though did not, for I pressed no keys into DF window - call on `gui/construct_screen_execute_hook (https://pastebin.com/vGeFwCLL)`.

At commented 800ish lines for three files to save what will be, at worst in tests, around dozen MB of RAM for a single screen, it's kind of lot of effort for small benefit. Currently, I'll probably be end up using the simple :dismiss() with perhaps nilling the C++ viewscreen in onDestroy(). (doing it the other way around, like in tests above, doesn't have the nicest interaction with menus, as nilling the base of stack also poofs all above it without error or warning.)

The point of the code is to help simulate plugin indicator screens, such as x: additional options (DFHack) in z-status overlay. (Though, hm, not quite there yet seamlessly; only single color at one moment for one line atm, albeit you may wrap second half of line in color().)

(PS: For readers from the spacefuture of mid-september+, the links only worked for 2 weeks as to not burden pastebin.)
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 26, 2017, 04:41:58 pm
I'll take a closer look at that later, but the "x: additional options (DFHack)" is a script (gui/extended-status). Also, your way of getting rid of screens will leak memory. Maybe not a lot, but it will leak some, and that can accumulate over time.
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on August 26, 2017, 05:12:09 pm
...Well. Failed to get script starting from gui/hello-world to work without interfering with parent focus and hotkeys or with simple replacement of gui.FramedScreen → gui.Screen as I desired and assumed all command transparency can only be done by plugin, based on the likes of workflow and search and simply repeating dfhack.screen.paintString failing outside rendering contexts...

Perhaps having FramedScreen(s) that are apply properly both keybinding and native keys of ancestor(s) is not useless, but at glance at gui/extended-status it seems I could have accomplished all this a loooot simpler :<.

About half the code being a workaround to, say, allow one to move cursor around and hit Ctrl-C for spotclean, Ctrl-Shift-I for gui/dfstatus or z in unitlist to zoom while screen is up.

>_>

Though, before I rewrite it, got to ask: For things like clickable label (https://gist.github.com/Putnam3145/e5d4aab2228b44b51b830021da4631c2), this is not possible with the indicator style used by gui/extended-status?
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 26, 2017, 05:48:48 pm
gui/extended-status doesn't use widgets, but it could. (Also, the DFHack-provided Label widget supports mouse input too now - you probably don't need to use ClickableLabel.)
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on August 26, 2017, 07:29:58 pm
Hm, cool....Though, upon relook, seems I cursed/cheered too soon. gui/extended_status still changes path, so something like keybinding add Shift-Alt-G@overallstatus "gaydar -citizens" in dfhack.init will fail to work with it activated...So, yeah. Seems I just unknowingly duplicated small part of it's code. Not sure now if I made any entirely superfluous functions, given that it'd need pretty much the same code to inherit keybindings and such.
Title: Re: DFHack 0.43.05-r2
Post by: Jerry The Hellbound on August 26, 2017, 07:50:32 pm
Is there a way to remove a tag from a unit by commands?
Or must it be removed by an interaction or syndrome? if so, how do i input those?
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 26, 2017, 08:44:31 pm
Hm, cool....Though, upon relook, seems I cursed/cheered too soon. gui/extended_status still changes path, so something like keybinding add Shift-Alt-G@overallstatus "gaydar -citizens" in dfhack.init will fail to work with it activated...So, yeah. Seems I just unknowingly duplicated small part of it's code. Not sure now if I made any entirely superfluous functions, given that it'd need pretty much the same code to inherit keybindings and such.
Yeah, that's a downside. There's been talk of adding ways for Lua scripts to modify screens like that, but it'd be a lot of effort.

It's worth noting that "keybinding" supports multiple contexts (although this isn't a great solution, since you'd potentially have to add contexts for multiple overlays):
Code: [Select]
keybinding add Shift-Alt-G@overallstatus|dfhack/lua/status_overlay "gaydar -citizens"

Is there a way to remove a tag from a unit by commands?
Or must it be removed by an interaction or syndrome? if so, how do i input those?
It depends on what tag you're referring to. There's no way to "remove a tag" in a text-based way for a specific unit, as you would in a text editor. However, some tags cause certain flags/fields/etc. to be set on units, which you can change in-game on a per-unit basis. What tag(s) are you interested in?
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on August 26, 2017, 09:23:02 pm
@lethosor: Well, I guess that part of what my above scripts is still useful then.

For, say, a small temperature indicator in loo(k) at -28, -1 that one wants to work with spotclean, it queries keybinding for all bindings and tells it to activate those in current context as long as screen is up with the gui/construct_screen_execute_hook that basically removes the screen and runs spotclean and adds screen back 1 frame later.
Title: Re: DFHack 0.43.05-r2
Post by: Jerry The Hellbound on August 27, 2017, 12:08:52 pm
I'm interested in the NOSTUN tag in particular.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 28, 2017, 01:23:43 pm
I'm interested in the NOSTUN tag in particular.
That looks like something that can only be done by modifying the creature raws (which would affect every creature of that race) or through a syndrome.
Title: Re: DFHack 0.43.05-r2
Post by: Jerry The Hellbound on August 28, 2017, 06:08:19 pm
I'm interested in the NOSTUN tag in particular.
That looks like something that can only be done by modifying the creature raws (which would affect every creature of that race) or through a syndrome.
Just like that?
I probably should say it first, that its without generating a new world.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on August 29, 2017, 02:27:24 am
It's possible to modify the creature raws inside a save, However, when I did that it only affected new creatures, not existing ones (I changed cats and dogs to into tomcats/cats and dogs/bitches respectively, i.e. gave separate names to the genders, This was using 0.40.X).
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 29, 2017, 09:12:38 am
I was talking about modifying the in-game representation of the creature raws, actually, not the raw files, although that would probably have the same limitations as editing the raw files if certain changes only apply to new creatures.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on August 29, 2017, 11:28:19 am
Given my experience, I'd say some raw changes only affect new creatures, but I'd suspect others affect all of them. The difference ought to be whether the info is copied into the unit on creation (in which case it ought to be possible to modify individually) or not. Note that this is speculation only: I haven't tried it out.
I wouldn't be surprised if changing the adult size of a creature would cause maturing (but already existing) creatures to take on the new size while those already mature would remain unchanged, i.e. raw changes affect only creatures that refer to the changed data for some processing.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on August 29, 2017, 02:20:01 pm
Issues with DFHack documentation on Github (They're stored separately where I can't find any way to raise Issues):
I've tried to create a DFHack plugin and have encountered a number of issues with the documentation on how to do this (the documentation is rather helpful, so this is a set of smaller issues). I'd also need help actually understanding how the process works.

- The Compile document https://dfhack.readthedocs.io/en/stable/docs/Compile.html (https://dfhack.readthedocs.io/en/stable/docs/Compile.html) claims Python is needed only for documentation. This isn't quite correct as the How to Contribute document https://dfhack.readthedocs.io/en/stable/Contributing.html#contributing-code (https://dfhack.readthedocs.io/en/stable/Contributing.html#contributing-code) says you have to pass a Python script test before submitting code (which not all the DFHack copied from Github passed did, by the way).
- The latter document above assumes the reader has far too much knowledge of both Github and DFHack's use of Github for me to make sense of the process (which might be due to my lack of understanding, and it doesn't help that I have no prior experience of Github). It seems Github repos can be set up in several ways, and it isn't clear how DFHack is set up.
A guess:
- Create a fork of the development branch (based on the second point plus some of the first one).
- Do work in branches of your fork, pull request (weird terminology for pushing something back without anyone actually being involved in accepting it?) the work back to your development branch and then pull request that back to your master branch and then pull request that back to the DFHack development branch. Look like overkill for a simple plugin, though.
- Presumably, the last step should be done only after some sanity checking and actual acceptance by a trusted DFHack maintainer, but it seems this is based only on trust?
Title: Re: DFHack 0.43.05-r2
Post by: Roses on August 29, 2017, 05:17:46 pm
Given my experience, I'd say some raw changes only affect new creatures, but I'd suspect others affect all of them. The difference ought to be whether the info is copied into the unit on creation (in which case it ought to be possible to modify individually) or not. Note that this is speculation only: I haven't tried it out.
I wouldn't be surprised if changing the adult size of a creature would cause maturing (but already existing) creatures to take on the new size while those already mature would remain unchanged, i.e. raw changes affect only creatures that refer to the changed data for some processing.

As far as I know modifying the creature information in global.world.raws.creatures.all (or something like that) will effect all existing and new creatures, since the information found in the unit (seen through something like gm-editor) is more or less a link to the creature raws, not stored per unit. There are exceptions to this since, like you said, some of the information in the creatures raws is just used as a basis for the unit (attribute information for instance, changing the range of a certain attribute wouldn't effect an existing unit, except for it's description), however most of the good stuff is linked to (like materials and tissues, and most of the tokens) and can not be changed on a per unit basis.
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on August 29, 2017, 09:31:41 pm
Having done my own embarrassing trying to poke around with the current dfhack github on the scripts side; you don't need to make a travis account, shouldn't link your github to it because it will spam build notifications in the dfhack irc, and the easy way to pass which I haven't actually seen the full list written together directly is as follows:

*--Put a short description for the ls/help/etc up here.
*--[====[
*
*scriptname
*======== <- same length as scriptname or longer I think
*some info
*about your script use
*also help/args and such
*
*]====]
*find and replace all tabs in your code with 4 spaces each
*kill trailing whitespace
*put a return at the end of lua scripts, I assume ruby is the same
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on August 30, 2017, 02:00:41 am
Thanks Max. I haven't done anything with any travis linking: I've just run the script (once I managed to find it). Since it's a matter of code in my case the description etc. script stuff doesn't apply to me. Finding how to get the small soft compiler environment to stop using tabs took a few search passes to find the setting, but I've finally gotten rid of the tabs. The script pointed out where trailing spaces were, so it was a matter of going through that list to eliminate them.
If I get the hang of how Github is supposed to be used I'll consider placing my scripts there, in which case your script summary will come in handy (although I'll have to find out how to get Notepad++ to stop using tabs). Come to think of it, no, I won't put my script there, because of the stupid demand for 4 character indentation, which wastes far too much space (I use 2 in my scripts, but have resigned myself to suffering lines being pushed off the page with the code).
Title: Re: DFHack 0.43.05-r2
Post by: Uzu Bash on August 30, 2017, 10:41:56 am
I think twbt bears too much investigation into its stability to be so intractably integrated with dfhack that it can't be unloaded or disabled. It seems to me there's a level of denial about its responsibility for dfhack's crashprone reputation.
Title: Re: DFHack 0.43.05-r2
Post by: Roses on August 30, 2017, 11:58:05 am
I think twbt bears too much investigation into its stability to be so intractably integrated with dfhack that it can't be unloaded or disabled. It seems to me there's a level of denial about its responsibility for dfhack's crashprone reputation.

TWBT doesn't come with DFHack, it's a separate thing. And as far as I know, even if you have it installed it can be disabled by changing the print mode.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 30, 2017, 12:54:12 pm
I've been fairly busy (and will be more busy shortly), and haven't had much time to respond to posts here, so sorry for the delayed responses.

Regarding documentation: it's not great, I know. There's an open issue for improving the docs about the build process and Travis tests, I think.

Issues with DFHack documentation on Github (They're stored separately where I can't find any way to raise Issues):
Not sure where you were looking, but it's definitely on Github in the docs folder of https://github.com/dfhack/dfhack/

Quote
I've tried to create a DFHack plugin and have encountered a number of issues with the documentation on how to do this (the documentation is rather helpful, so this is a set of smaller issues). I'd also need help actually understanding how the process works.

- The Compile document https://dfhack.readthedocs.io/en/stable/docs/Compile.html (https://dfhack.readthedocs.io/en/stable/docs/Compile.html) claims Python is needed only for documentation. This isn't quite correct as the How to Contribute document https://dfhack.readthedocs.io/en/stable/Contributing.html#contributing-code (https://dfhack.readthedocs.io/en/stable/Contributing.html#contributing-code) says you have to pass a Python script test before submitting code (which not all the DFHack copied from Github passed did, by the way).
I suppose that's a fair point, although you don't need it to build DFHack - it just enforces a few checks. All of the code in the DFHack repo passes it currently: https://travis-ci.org/DFHack/dfhack

Quote
- The latter document above assumes the reader has far too much knowledge of both Github and DFHack's use of Github for me to make sense of the process (which might be due to my lack of understanding, and it doesn't help that I have no prior experience of Github). It seems Github repos can be set up in several ways, and it isn't clear how DFHack is set up.
A guess:
- Create a fork of the development branch (based on the second point plus some of the first one).
- Do work in branches of your fork, pull request (weird terminology for pushing something back without anyone actually being involved in accepting it?) the work back to your development branch and then pull request that back to your master branch and then pull request that back to the DFHack development branch. Look like overkill for a simple plugin, though.
- Presumably, the last step should be done only after some sanity checking and actual acceptance by a trusted DFHack maintainer, but it seems this is based only on trust?
Basic process:
- create a fork of dfhack/dfhack (e.g. your-username/dfhack)
- make a new branch based on the develop branch
- work on your stuff there
- make a pull request
- someone on the DFHack team comments on / accepts the pull request (that's what the "request" part means - you'd be requesting that someone takes a look at your changes and merges them in)


Thanks Max. I haven't done anything with any travis linking: I've just run the script (once I managed to find it). Since it's a matter of code in my case the description etc. script stuff doesn't apply to me. Finding how to get the small soft compiler environment to stop using tabs took a few search passes to find the setting, but I've finally gotten rid of the tabs. The script pointed out where trailing spaces were, so it was a matter of going through that list to eliminate them.
If I get the hang of how Github is supposed to be used I'll consider placing my scripts there, in which case your script summary will come in handy (although I'll have to find out how to get Notepad++ to stop using tabs). Come to think of it, no, I won't put my script there, because of the stupid demand for 4 character indentation, which wastes far too much space (I use 2 in my scripts, but have resigned myself to suffering lines being pushed off the page with the code).
There's no demand for 4-space indentation for scripts:
Quote from: https://dfhack.readthedocs.io/en/latest/Contributing.html
Four space indents for C++. Never use tabs for indentation in any language.
(Now, I do have objections to 1-space indentation, because it's hard to read, but 2-space indentation is fine if you really want to do that. If you're running into issues with lines being too long, either you have things nested too far or you should break lines up at some point.)

I think twbt bears too much investigation into its stability to be so intractably integrated with dfhack that it can't be unloaded or disabled. It seems to me there's a level of denial about its responsibility for dfhack's crashprone reputation.
To add on what Roses said, these are some reasons why it's not included in DFHack. Plugins that refuse to be disabled/unloaded are hard to deal with. I'm not up-to-date with how stable recent TWBT builds are, but having seen several crashes linked to it in the past, I'm a bit wary of using it much myself.

TWBT doesn't come with DFHack, it's a separate thing. And as far as I know, even if you have it installed it can be disabled by changing the print mode.
I'm pretty sure Uzu Bash was talking about disabling it in-game with "disable twbt" or "unload twbt", both of which are impossible (it enables itself if it detects PRINT_MODE:TWBT in init.txt, and cannot be unloaded, ever).
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on August 30, 2017, 02:09:33 pm
Thanks lethosor, good answers as always.

I'm not exactly complaining about the documentation, as what's there is way more than we have reason to demand (which, I think, is nothing, by the way).  My comments were mostly meant as feedback to improve it, should someone wish to do so. However, I'll write an Issue for it.

The documentation links I've found are at https://dfhack.readthedocs.io/en/stable/ (https://dfhack.readthedocs.io/en/stable/), which is where I ended up searching for documentation.

Thanks for the description of the process. It's also good to hear that the Github documentation I've tried to read has failed to point out that there's actually a request/accept stage involved (or maybe the DFHack structure of it uses an organization way down the list after my brained had shut down).

Good to hear I was wrong about script indentation. I have more trouble with breaking lines in C where the development environment decides that the broken line should be placed so it ends up in a hard to read mess. With scripts I'm in control, but if half the page is lost to indentation there isn't much left for the actual script/code without it being broken over a silly number of lines.

Edit:
Trying to understand the pull request logic, my impression is that a pull request contains all the differences between the base and the head (terms used by web pages describing it). If that's the case, don't you need a separate branch for each item = (future) pull request? If you create plugin 1 and plugin 2 (or bug fix 1 and 2) they ought to be accepted/rejected separately?
Title: Re: DFHack 0.43.05-r2
Post by: Rose on August 31, 2017, 09:47:54 am
Generally, yeah, each separate thing you're working on would be a separate branch, unless they're supposed to be together, in which case a single branch and PR would be fine.
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on August 31, 2017, 10:07:04 am
Ah, yeah the 4 spaces was indeed from the C++ part, just remembered seeing that while checking for style info in dfhack, and once I did one script I just went around spamming find/replace with the same tab > 4space cache and didn't catch that travis only cared about tabs.
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on August 31, 2017, 11:46:50 am
Why no tabs requirement, anyway? Problems on *guessing* Mac systems?
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on August 31, 2017, 12:33:45 pm
Might just be a style preference, they can end up being excessive too.

Code: [Select]
I feel like this
    helps keep a groove
    when I'm scripting
        because it reminds me
            which blocks to check for closure
            by visually
        delineating
            the relevant
        nesting
    and lack thereof
    in my
subsections.

Code: [Select]
While this
        causes the lines to skew
                way over to the side
                        after just a couple of
                chunks
                which ends up
                        losing the vertical
                                component
                                        of the visual
                                relationships
                                        and can
                                make it harder
                        to catch errors
                or even just
        clean up
                sloppy
        and cluttered
bits of code.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on August 31, 2017, 03:01:29 pm
Thanks for the answer, Japa.

One problem with tabs is that the horizontal space they take up varies, so you can create a file and format it using 4 space long tabs and then load it elsewhere where e.g. 8 or 3 spaces are using as the visual translation.
Title: Re: DFHack 0.43.05-r2
Post by: Roses on August 31, 2017, 04:01:41 pm
Edit:
Trying to understand the pull request logic, my impression is that a pull request contains all the differences between the base and the head (terms used by web pages describing it). If that's the case, don't you need a separate branch for each item = (future) pull request? If you create plugin 1 and plugin 2 (or bug fix 1 and 2) they ought to be accepted/rejected separately?

I'm not sure about in GitHub, but just using git you are able to commit specific file changes and do pull requests on those specific changes, so if you are working on two separate things you can keep their commits and pulls separate. I don't think GitHub allows you to merge specific commits with the web interface, but if you use a terminal you can.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on August 31, 2017, 04:31:18 pm
Why no tabs requirement, anyway? Problems on *guessing* Mac systems?
No, it's not platform specific at all. Mostly consistency and issues with tabs displaying differently in different environments.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 02, 2017, 11:13:57 am
Further DFHack contribution questions:
Would it be a good idea to make pull requests for updated DFHack structures when fields have been identified rather than generating issues? I'm particularly thinking about some rather lengthy description (in acomment) to describe how rivers work (there's an issued for the raw info).
If that is a good idea, does Travis (or something else) theck the XML syntax to verify it's legal? I currently have no tool for XML editing to it would be raw text editing. None of the things I've seen are complicated, but it's easy to make mistakes.
Obviously, any field identification should be verified by at least one additional person to make reasonably sure it was actually a correct identification.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on September 02, 2017, 04:13:10 pm
Yeah, make pull requests if you can. We haven't set up any Travis stuff in df-structures yet. Are you able to build DFHack? If so, you can build just the "generate_headers" target to make sure the XML is valid, or "dfhack" to make sure the generated headers actually compile. (Usually people will double-check stuff and make sure it compiles, though, but it's nice to check before making PRs if you can, and if it's not trivial.)
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 03, 2017, 02:16:29 am
Thanks lethosor. Yes, I can build DF. I didn't know the headers were generated "locally" (but was puzzled about where they came from, as I haven't been able to find them on github), but that makes the syntactic check a lot easier.
Should I "convert" the other issues I've raised that are complete enough into pull requests as well?

Edit: I think the "generate_headers" you refer to is actually the Perl script "codegen.pl"? Running it generated a codegen directory containing a whole lot of .h files, and the one generated from my changes looks well formed (and Visual Studio doesn't complain about it).
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on September 03, 2017, 11:13:05 am
"generate_headers" is the name of the CMake target, which should show up in Visual Studio somehow if you're using that. Yes, it does run codegen.pl, but it gives it certain arguments that cause it to put headers in the right places (so you can actually compile DFHack with them), which I don't think you did. "make generate_headers" would run the same thing on Linux/macOS, but I haven't tried this in Visual Studio, so I'm not sure exactly how it would work there.

Anyway, pull requests generally tend to get looked at faster than issues, so yeah, feel free to make more.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 03, 2017, 01:46:15 pm
With a marginal amount of additional experience, I conclude it's probably not possible to just magically get the header generation script to run from Visual Studio without the addition of some glue. The reason for this is that DFHack and df-structures are separate repos and separate entities, and separate directories (on my machine), so something would have to tell Visual Studio in my DFHack fork->branch->clone where to look for the df-structures fork->branch->clone. Adding this glue is probably trivial when you know how...

Also, I'm not too keen on pushing the new headers into my current DFHack fork->branch->repo, as that will break the plugin I have there, so it would have to be a separate clone (which shouldn't be too hard to create). It can also be mentioned that df-structures
is ahead of the development branch of DFHack, as of my last check (a small bug Quietust fixed within 15 minutes of it being reported wasn't present in DFHack develop a few days later when I cloned my stuff, and I don't know what other things are ahead).

My current plan is to transform my issues into  pull requests once I've gotten somewhere with the current one, so I won't have to repeat all process corrections in parallel.
Title: Re: DFHack 0.43.05-r2
Post by: Nahere on September 03, 2017, 03:50:29 pm
Is it possible to get modtools like projectile-trigger and spawn-flow to work in the arena? If so how?
Title: Re: DFHack 0.43.05-r2
Post by: Rose on September 03, 2017, 10:22:44 pm
PatrikLundell, it's probably easiest just to keep different copies of the dfhack repo for different things. That's what I do anyway.

Just have one just for DF-structures research. Then you can change the DF-structures branch for separating pull requests.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on September 04, 2017, 08:48:56 am
With a marginal amount of additional experience, I conclude it's probably not possible to just magically get the header generation script to run from Visual Studio without the addition of some glue. The reason for this is that DFHack and df-structures are separate repos and separate entities, and separate directories (on my machine), so something would have to tell Visual Studio in my DFHack fork->branch->clone where to look for the df-structures fork->branch->clone. Adding this glue is probably trivial when you know how..
df-structures should be a submodule and cloned in your DFHack/library/xml folder. You can make changes there and push them to your fork as with any other repo, although you may need to run "git checkout master" first.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 04, 2017, 12:26:17 pm
Ah, so that's where the XML files are hiding (and evading my eyes while looking for missing stuff). Sub modules haven't been my friends so far, as my attempt to push things back to my master (with DFHack scripts) failed, probably because the sub module did not respect my mastery, but somehow retained the one I forked from. I ended up with a "naked " scripts repo, and it's a lot less work to use the web interface to just drop my files there (from the folder inside DF), so I don't even need a local git copy of the repo.

Edit:
I've now managed to get the modified .XML file to generate h. files that have been used to build the Win 32 DFHack solution.
Title: Re: DFHack 0.43.05-r2
Post by: Uzu Bash on September 04, 2017, 09:28:51 pm
Documentation isn't clear on  what df.units.flags2 cleanup vars do. What do the kill function and forget function do exactly?

From testing I found that cleanup_1 will remove a unit from active, but not units.all, but I don't see any other effect it has on the unit, nor the unit's nemesis or figure records if they have one. Reloading the map doesn't return unit to active, not even leaving the region and returning.

cleanup_2 will clear the unit from active and all, and the associated nemesis record, if it exists. This corrupts the save because every nemesis# now refers to different histfigs. If non-notable units are cleared, they never return to the region tile.

I haven't seen any effects from cleanup_3, cleanup_4, or killed. cleanup_3 set to true will revert to false on next tick, the others will remain true.
Title: Re: DFHack 0.43.05-r2
Post by: Quietust on September 05, 2017, 08:53:30 am
The identities of those "cleanup" vars were provided by Toady himself - we don't know exactly what they do, and we'd have to study a disassembly to figure out.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 07, 2017, 06:41:27 am
I'm trying to use the EventManager plugin's onJobCompleted callback from a Lua script. However, it doesn't seem to trigger on either StoreItemInStockpile or StoreItemInVehicle.
I've set the callback up both with a frequency of 0 and 1 (on different runs) with no apparent difference in the results. It's not that the callback isn't triggered: I've added a printout that prints df.job_type[job.job_type], and other stuff appears, such as drink2, eat, sleep, gather plants, and construct tool. Hauling a mine cart to a route stop did not register, however, so it might filter out all kinds of hauling jobs, which is unfortunate in my case, as I'm trying to make it possible to both transport booze using mine carts, and store it in (mine cart) quantum stockpiles. The intention was to strip any stockpile designation from booze barrels hauled to (food) stockpiles, but I haven't come further than trying to get a trigger when it would be time to look for booze barrels to strip for stockpile allocation...

Edit:
Well, the oddity above still remains, but my attempt to make it possible to transport booze failed as removing the references from barrels and stockpiles are immediately undone by DF restoring them. Otherwise it turned out INVENTORY_CHANGE can be used as a hauling trigger.
Title: Re: DFHack 0.43.05-r2
Post by: Roses on September 10, 2017, 03:13:59 pm
Did something change with table.unpack in the latest DFHack release? A script of mine that used to work no longer does, returning nil whenever I try to unpack a table. Not a big deal since I changed the way the script works, just wondering for curiosity.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on September 10, 2017, 03:38:03 pm
What table are you trying to unpack (and what are its contents)? These seem to be working for me:

Code: [Select]
[lua]# ~table.unpack{1,2,3}
1 2 3
[lua]# ~table.unpack{nil,1,2,3}
nil 1 2 3

We had to switch to Lua 5.3 (from 5.2) for 0.43.05, but that was several releases ago. That could've changed some behavior of built-in Lua functions.
Title: Re: DFHack 0.43.05-r2
Post by: Roses on September 11, 2017, 03:33:17 pm
It looks like I had just created the table wrong, it's working fine for me now. One change that is real though is that tonumber('2') now returns 2.0 instead of 2.
Title: Re: DFHack 0.43.05-r2
Post by: Bob69Joe on September 11, 2017, 07:52:53 pm
So how does 'O' work in adventure mode? I have a lady elf companion and I would like her to wear the sawgrass trousers I made for her. Mostly so she chaffs.
_____
Hello again! I've got an adventurer dwarf who has been ambushing gobbos going back and forth between two dark pits. They decided to plant their dark pits right on top of a road between two hamlets, in the midst of a considerably sized human population, I am not sure how they avoided many troubles, the dark pits are quite large. Well, a human guy named Akar joined up early on who was a great hammerer wielding a silver maul though he had troubles with his hip. I could count four times he twisted his hip and pulled some tendons and ligaments though he always fought off his foes and recovered a day later. Eventually I lost him in a hamlet north of the pits. We were sleeping among some friendly villagers and gobbos ambushed us outside the house we were in. Ended up killing them all, but poor Akar got a nasty leg scrape and was forced to crawl. I lost track of him during the fight as I went 'T' and hunted down the ambush party. I spent several in-game hours looking around and found he bled out in an alley way. I brought his body and all his belongings out into a snowed field. The farmers will find a stiff corpse when Spring thaws out the fields.

Well, that was a rather poorly worded summation of Akar's end. I would like to bury him or put his body and belongings onto a pyre and turn it all to ash. Does DFHack have any commands or reactions for that?

I found that elf chick while ambushing gobbos several days later. Strange things you'll see when gobbos plant a huge dark pit onto a major highway. She said she was going back to the elves, and she even killed several dwarfs. I'm keping an eye on her, and lead her dangerous goblin caves. Still want to know how the party 'O' thing works. All I can do is highlight her name, but the commands don't change anything.
_____
Okey dokey. I just noticed she's been naked for a while in 10 degree weather. So, she has to be standing on top of what I want her to equip.

Is there a command to make someone, or something, join your party?
Title: Re: DFHack 0.43.05-r2
Post by: Roses on September 13, 2017, 06:28:04 pm
Is there a way to execute a dfhack.script_environment call silently? For running scripts there is dfhack.run_command_silent, just wondering if there is something similar for the script_environment
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on September 13, 2017, 07:34:18 pm
If calling script_environment sends output to the console, you shouldn't be using it on that script (or you should change that script).
Title: Re: DFHack 0.43.05-r2
Post by: Bob69Joe on September 13, 2017, 10:30:24 pm
Are there commands to cast magic or at least spawn a pillar of dragonbreath on a square?
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 14, 2017, 07:59:55 am
Mods may or may not have implemented some kind of magic. Ask in that sub forum. DF itself doesn't have magic yet (it's about 2 years off). The DFHack "liquids" tool allows you to dump magma on a tile, though.
Title: Re: DFHack 0.43.05-r2
Post by: Bob69Joe on September 14, 2017, 01:30:32 pm
Is there any quick way to clear a room of eighty beak dogs in gobbo towers?
_____
That's why I asked about the dragonfire, I should have been more specific as to the use.
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on September 14, 2017, 02:39:08 pm
exterminate script does let you kill anything or any species on map.
Title: Re: DFHack 0.43.05-r2
Post by: Bob69Joe on September 14, 2017, 04:49:24 pm
It doesn't show in the 'ls' menu and it isn't finding it with 'help exterminate'. Would it kill creatures on the screen or entire world?
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on September 14, 2017, 04:50:52 pm
Roses did something with flows that would let you spawn a line of dragonfire or whatnot but I can't remember where it was.
Title: Re: DFHack 0.43.05-r2
Post by: Bob69Joe on September 14, 2017, 05:06:58 pm
Is there any quick way to clear a room of eighty beak dogs in gobbo towers?
_____
That's why I asked about the dragonfire, I should have been more specific as to the use.

Is it possible to make all creatures unable to move, I don't care if they attack, but gobbo towers are so populated I lag considerably which is probably due to pathing like most lag issues.
Title: Re: DFHack 0.43.05-r2
Post by: Bumber on September 14, 2017, 07:41:25 pm
It doesn't show in the 'ls' menu and it isn't finding it with 'help exterminate'. Would it kill creatures on the screen or entire world?
Loaded revealed tiles, I think. Just type 'exterminate' and it should give you a list of target races. Then use exterminate <race name> to kill them.
Title: Re: DFHack 0.43.05-r2
Post by: Bob69Joe on September 14, 2017, 09:21:33 pm
Loaded revealed tiles

So, that would be all the things encountered in the past day's travel, pretty much?

Or everywhere I have been since day one?
_____
'exterminate is not a recognized command' error.
Title: Re: DFHack 0.43.05-r2
Post by: Bob69Joe on September 14, 2017, 09:54:17 pm
http://dfhack.readthedocs.io/en/stable/docs/_auto/base.html#exterminate

This helps a lot. I wished that would be more noticeable on the first page, but that's my fault.
_____
Something is really wrong. I typed 'exterminate gob' and it says exterminate is not a recognized command.
Huh, I began using DFHack on a dffiledepot search of the utility, so I guess it wasn't the updated one on the first page. Stuff works. :D
Title: Re: DFHack 0.43.05-r2
Post by: Bumber on September 14, 2017, 10:13:59 pm
Loaded revealed tiles

So, that would be all the things encountered in the past day's travel, pretty much?

Or everywhere I have been since day one?
'Loaded' as in 'currently loaded'. Just the things in the site you're visiting, or a certain radius around you in the wilderness.
Title: Re: DFHack 0.43.05-r2
Post by: Bob69Joe on September 14, 2017, 11:29:18 pm
Jeebus, that's devastating. Just standing outside the towers among the trenches nets more than 200 kills.

Welp, I think my dwarf has had a fulfilling life, killing more than 400 goblins not counting the generated kills that number hundreds more. Three towers have had demonic masters slain. His hairs are graying. I've swam him north into the sea far away to a lone island. It's covered in black sand and it snows here. Found a shrine with an amethyst colored giant dove that's eyeless and breathes fire, plus a single cave that seems uninhabited. Please say their is a way to retire my dwarf as a hermit in the cave.
Title: Re: DFHack 0.43.05-r2
Post by: FortunaDraken on September 16, 2017, 06:38:52 am
Small question for the smarter people: what's the difference between region-pops list and region-pops list-all? I'm trying to work out why the numbers are different between the two (list showing 0 and list-all showing 18) and I think I'm just confusing myself trying to work it out.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on September 16, 2017, 10:40:00 am
From http://dfhack.readthedocs.io/en/latest/docs/_auto/base.html#region-pops:

Quote from: http://dfhack.readthedocs.io/en/latest/docs/_auto/base.html#region-pops
region-pops list [pattern]:
    Lists encountered populations of the region, possibly restricted by pattern.
region-pops list-all [pattern]:
    Lists all populations of the region.
Title: Re: DFHack 0.43.05-r2
Post by: FortunaDraken on September 16, 2017, 08:13:02 pm
From http://dfhack.readthedocs.io/en/latest/docs/_auto/base.html#region-pops:

Quote from: http://dfhack.readthedocs.io/en/latest/docs/_auto/base.html#region-pops
region-pops list [pattern]:
    Lists encountered populations of the region, possibly restricted by pattern.
region-pops list-all [pattern]:
    Lists all populations of the region.
I've seen that, and it's kind of why I'm confused, hence my asking. If the encountered only shows the population of things that've shown up, why would the numbers be different between the list and list-all?
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on September 17, 2017, 12:44:38 am
Because there are certain ones you haven't encountered, I'm assuming? I'm not familiar with the exact terminology here, but "region" may include more than your local map.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 17, 2017, 03:05:14 am
If I recall correctly, region-pops looks at a DF structure of flora/fauna spanning a 7*7 world tile area with your fortress in the middle. This also explains why you can get stuff like ocean creatures reported even though you're not embarked particularly close to the ocean.
Determining what the technical difference is between the reports requires a study of the script, though.
Title: Re: DFHack 0.43.05-r2
Post by: FortunaDraken on September 18, 2017, 01:15:10 am
Because there are certain ones you haven't encountered, I'm assuming? I'm not familiar with the exact terminology here, but "region" may include more than your local map.
My wording on that was bad, sorry. I was wondering more why like, my region-pops list shows Giant Tigers at 1, while region-pops list-all had about...18, I think it was?

If I recall correctly, region-pops looks at a DF structure of flora/fauna spanning a 7*7 world tile area with your fortress in the middle. This also explains why you can get stuff like ocean creatures reported even though you're not embarked particularly close to the ocean.
Determining what the technical difference is between the reports requires a study of the script, though.
This though would make sense...it'd be everything in the surrounding area, which miiiight end up showing up sometime? Hm. That helps make me less confused, thanks.


EDIT: Not sure if this is place to make a suggestion or not, but would it be possible to add a confirmation of the script being on or off to warn-stuck-trees and warn-starving? I assume it's on to begin with, but it'd make it easier to tell.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on September 18, 2017, 09:52:21 pm
EDIT: Not sure if this is place to make a suggestion or not, but would it be possible to add a confirmation of the script being on or off to warn-stuck-trees and warn-starving? I assume it's on to begin with, but it'd make it easier to tell.
Are you talking about a way to tell whether those scripts are enabled? The default configuration uses the "repeat" command to run those scripts periodically, and I don't know if that has a way to tell whether a certain timeout is enabled or not.
Title: Re: DFHack 0.43.05-r2
Post by: FortunaDraken on September 18, 2017, 10:42:22 pm
EDIT: Not sure if this is place to make a suggestion or not, but would it be possible to add a confirmation of the script being on or off to warn-stuck-trees and warn-starving? I assume it's on to begin with, but it'd make it easier to tell.
Are you talking about a way to tell whether those scripts are enabled? The default configuration uses the "repeat" command to run those scripts periodically, and I don't know if that has a way to tell whether a certain timeout is enabled or not.
Yeah, I wasn't sure how to actually tell if those scripts were on or not. I am very newbish to learning how to DFhack, I wasn't aware there was a repeat going on. But that makes sense.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 19, 2017, 05:40:00 am
Is there a way to get access to df structure enum value attributes from Lua? C translates it into macros, but that's of little help from a script. The things I'm currently after are the "color" attribute of df.unit-thoughts.xml:emotion_type and "caption" of unit_thought_type in the same file. As a bonus, it wouldn't hurt to know how to interpret the "divider" attribute of emotion_type.
Title: Re: DFHack 0.43.05-r2
Post by: Clément on September 19, 2017, 06:26:13 am
I have a problem with the devel/export-dt-ini script. I get the wrong size for the structure "squad_schedule_entry" ("sched_size" in DT's world) using 0.43.05-r2 win32.

The line is:
Code: [Select]
value('sched_size',df.squad_schedule_entry:sizeof())
I get 0x40 instead of 0x34. I assume df-structures is good since it is what I used to get the correct size. I am not sure where the error comes from (C++ code generation or the script itself?).
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on September 19, 2017, 12:43:37 pm
Is there a way to get access to df structure enum value attributes from Lua? C translates it into macros, but that's of little help from a script. The things I'm currently after are the "color" attribute of df.unit-thoughts.xml:emotion_type and "caption" of unit_thought_type in the same file. As a bonus, it wouldn't hurt to know how to interpret the "divider" attribute of emotion_type.
df.enum_type.attrs[value] (or df.enum_type.attrs.name).

I have a problem with the devel/export-dt-ini script. I get the wrong size for the structure "squad_schedule_entry" ("sched_size" in DT's world) using 0.43.05-r2 win32.

The line is:
Code: [Select]
value('sched_size',df.squad_schedule_entry:sizeof())
I get 0x40 instead of 0x34. I assume df-structures is good since it is what I used to get the correct size. I am not sure where the error comes from (C++ code generation or the script itself?).

What does "df.squad_schedule_entry:new():_field('name'):sizeof()" give you? Also, are you saying 0x34 should be the correct size? I don't think there's a way the size could be wrong unless df-structures' layout is wrong, because it should use C++'s sizeof() under the hood (and squad_schedule_entry doesn't inherit from anything, although that shouldn't matter either). Are you taking padding into account?
Title: Re: DFHack 0.43.05-r2
Post by: Clément on September 19, 2017, 01:21:56 pm
Sorry, all is right (for DFHack). DFhack gives the correct value (0x34). The ini I generated the first time was sneakily replaced by DT's auto-updater with a faulty one from the splintermind repo.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 19, 2017, 01:29:31 pm
Thanks lethosor!
Title: Re: DFHack 0.43.05-r2
Post by: ab9rf on September 21, 2017, 07:05:22 am
With a marginal amount of additional experience, I conclude it's probably not possible to just magically get the header generation script to run from Visual Studio without the addition of some glue. The reason for this is that DFHack and df-structures are separate repos and separate entities, and separate directories (on my machine), so something would have to tell Visual Studio in my DFHack fork->branch->clone where to look for the df-structures fork->branch->clone. Adding this glue is probably trivial when you know how...

Also, I'm not too keen on pushing the new headers into my current DFHack fork->branch->repo, as that will break the plugin I have there, so it would have to be a separate clone (which shouldn't be too hard to create). It can also be mentioned that df-structures
is ahead of the development branch of DFHack, as of my last check (a small bug Quietust fixed within 15 minutes of it being reported wasn't present in DFHack develop a few days later when I cloned my stuff, and I don't know what other things are ahead).
I have three or four working directories for DFHack on my system (including one that I keep "clean" because I only use it for release builds: the only thing I ever do with it is bring it to a specific commit, followed by running the 32-bit and 64-bit build scripts). It's also very easy to switch between branches within a given repo. It's easy enough to have a DFHack repo in which the subrepo for df-structures is tracking a working branch of df-structures, although getting here does require using the git command line; you'll have to do a git submodule update --checkout whenever you switch a working directory between branches that are tracking different branches of the df-structures of the submodule.

As far as I recall. df-structures doesn't include prebuilt Visual Studio solutions, so the easiest way to work with df-structures within VS is to have a working DFHack local repo, with its df-structures subrepo pinned to a branch of df-structures that you're working on. It's actually possible to directly add the subrepo as a repo in the Windows Github client: a subrepo is a full repo in its own right.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 21, 2017, 07:55:04 am
Thanks ab9rf.
Given that the github structure has one structure for DFHack and another for DF structures, I never considered that the off site organization might somehow pull the apparent separate DF structures entity into the DFHack one, although I was aware that there are a lot of things I could never find in the online DFHack file structure.
Given your comments, I managed to get git to tell me there's a "git submodule status" command, and that command shows there is indeed a "library/xml" submodule, which looks to be very similar to the df structures one (i.e. it should be the one). This means it should be reasonably easy to have a "complete" dfhack structure whose purpose is to support df structures work as you said.
Title: Re: DFHack 0.43.05-r2
Post by: Roses on September 22, 2017, 03:38:06 pm
Is it possible to print in different colors in the DFHack screen? I currently have an output like;
PASSED: unit/action-change
PASSED: unit/attack
FAILED: unit/body-change
NOCHECK: unit/create
PASSED: unit/move

and it would be awesome if I could color code it
PASSED: unit/action-change
PASSED: unit/attack
FAILED: unit/body-change
NOCHECK: unit/create
PASSED: unit/move
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on September 22, 2017, 05:01:55 pm
Yep. Here's what I use:

Code: [Select]
    function printlnc(text, color)
        dfhack.color(color)
            dfhack.println(text)
        dfhack.color(COLOR_RESET)
    end

Example screenshot (https://i.imgur.com/l0DV4X7.png) from relations-indicator.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 22, 2017, 05:12:38 pm
You can use the 15 colors supported by DF for display in both the DFHack console window and on windows you create on top of/integrated into DF. The syntax differs slightly depending on whether you use C(++) or Lua (and I assume things like Ruby supports it as well, although I've never looked at that) but the essential functionality is the same.
You can also change the background color to any of the 15 supported colors, although that requires slightly more work, and there's a Bold parameter I've never used as well.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 24, 2017, 02:27:12 am
This script kills DF 64 bit but does nothing on DF 32 bit on Windows 10.1:
Code: [Select]
function bellyup ()
  local geo_biome = df.world_geo_biome:new ()
  geo_biome.layers:delete()
end

bellyup ()
As far as I understand, :delete() should not do anything when there is no applicable delete operation ("Destroys the object with the C++ delete operator. If destructor is not available, returns false." from the DFHack Lua API documentation). Is that a bug in the DFHack 64 bit Windows implementation?

Ignore the fact that the code isn't doing anything useful: I've already realized that...
Title: Re: DFHack 0.43.05-r2
Post by: Warmist on September 24, 2017, 02:30:53 am
This script kills DF 64 bit but does nothing on DF 32 bit on Windows 10.1:
Code: [Select]
function bellyup ()
  local geo_biome = df.world_geo_biome:new ()
  geo_biome.layers:delete()
end

bellyup ()
As far as I understand, :delete() should not do anything when there is no applicable delete operation ("Destroys the object with the C++ delete operator. If destructor is not available, returns false." from the DFHack Lua API documentation). Is that a bug in the DFHack 64 bit Windows implementation?

Ignore the fact that the code isn't doing anything useful: I've already realized that...
Usually crashes like this is when stuff is misaligned (IIRC) i.e. when the underlying structures are not correct.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 24, 2017, 03:39:29 am
I doubt it's a structure mismatch issue, as I changed the script to:
Code: [Select]
function bellyup ()
  local unit = df.unit:new()
  unit.social_activities:delete()
 
  --local geo_biome = df.world_geo_biome:new ()
  --geo_biome.layers:delete()
end

bellyup ()
after reading Warmist's comment, and the behavior is the same, despite a completely different structure is attacked. The common denominator (that I can identify) is that both structures attempted to be deleted are <stl-vector> ones, and I don't think it matters if they contain data or not.
Title: Re: DFHack 0.43.05-r2
Post by: Warmist on September 24, 2017, 04:27:25 am
I doubt it's a structure mismatch issue, as I changed the script to:
Code: [Select]
function bellyup ()
  local unit = df.unit:new()
  unit.social_activities:delete()
 
  --local geo_biome = df.world_geo_biome:new ()
  --geo_biome.layers:delete()
end

bellyup ()
after reading Warmist's comment, and the behavior is the same, despite a completely different structure is attacked. The common denominator (that I can identify) is that both structures attempted to be deleted are <stl-vector> ones, and I don't think it matters if they contain data or not.
Oh you are doing something very strange... See the std::vector is not a pointer, so you are deleting a part of struct which is very invalid in all version, and you should not do it

Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 24, 2017, 07:15:31 am
Yes, as I said initially, I've realized the pointer isn't actually a naked pointer but embedded in an object, so I'm in no way claiming it's sensible to do it. The thing is that the DFHack Lua API documentation seems to indicate the operation should do nothing when not valid (as well as return 'false' which I haven't checked to see if the 32 bit version does), rather than just run off the cliff.
Title: Re: DFHack 0.43.05-r2
Post by: Warmist on September 24, 2017, 08:37:56 am
Yes, as I said initially, I've realized the pointer isn't actually a naked pointer but embedded in an object, so I'm in no way claiming it's sensible to do it. The thing is that the DFHack Lua API documentation seems to indicate the operation should do nothing when not valid (as well as return 'false' which I haven't checked to see if the 32 bit version does), rather than just run off the cliff.

Yup you are right, something is wrong :). I've posted an issue here (https://github.com/DFHack/dfhack/issues/1170)
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 24, 2017, 09:44:57 am
Thanks Warmist.
That would have been my next step, but I generally want to be reasonably sure it is a bug before I post bug reports (which does not mean I screw up and post bug reports incorrectly anyway), so asking here first was my first step.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on September 24, 2017, 11:04:00 am
There's a difference between a destructor being "not available" and "not valid". Only the former is easy to detect. https://github.com/DFHack/dfhack/issues/1170#issuecomment-331719462
Title: Re: DFHack 0.43.05-r2
Post by: ab9rf on September 26, 2017, 12:49:12 am
Thanks ab9rf.
Given that the github structure has one structure for DFHack and another for DF structures, I never considered that the off site organization might somehow pull the apparent separate DF structures entity into the DFHack one, although I was aware that there are a lot of things I could never find in the online DFHack file structure.
Given your comments, I managed to get git to tell me there's a "git submodule status" command, and that command shows there is indeed a "library/xml" submodule, which looks to be very similar to the df structures one (i.e. it should be the one). This means it should be reasonably easy to have a "complete" dfhack structure whose purpose is to support df structures work as you said.
library/xml is df-structures. It's a subrepo, and if you go into it's a full repository that you can manipulate in the same manner as any other repository. If you change the commit to which that repo points, the parent repository will track that as a change as to which commit the parent repository will track. This is, in fact, what you basically have to do if you make a change to dfhack code that relies on a newer df-structures release.

There are a lot of gotchas, caveats, and non-obvious best-practice advice for dealing with subrepos. DFHack has five or six subrepos now (and some of them have subrepos of their own, as I recall), so if you're going to be a serious DFHack developer, you kinda have to have at least some understanding of this.
Title: Re: DFHack 0.43.05-r2
Post by: Burneddi on September 26, 2017, 10:42:52 am
I'm having some adventure mode woes with TWBT. The site building screen works incredibly poorly, with tiles not properly refreshing when you pan the view around. Advfort (gui/advfort) also doesn't work, the view goes blank when using it so you can't actually see what's going on. Am I using an outdated version or something?
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 26, 2017, 11:42:26 am
How would we know if you're using an outdated version?

What versions of what are you using, and on what platform? Note that I don't know any answers to adventure mode questions, but those who do most likely need the basic info.
- Platform? (Windows (version, 32/64 bit), Linux (version), Mac)
- DF/Pack version? LNP? If you've compiled it yourself, from which parts? Which DFHack version?
- Which tile set are you using?
- Does it work if you disable TwbT?
- Any other potentially useful pieces of information you can come up with.
Title: Re: DFHack 0.43.05-r2
Post by: Burneddi on September 26, 2017, 12:30:20 pm
How would we know if you're using an outdated version?
Possibly by being familiar with the bug and knowing that it has been recently fixed, for instance. Site building being glitched sounds like the kind of bug people would notice fairly easily if it affected them. Here's a video of the site creation bug: https://gfycat.com/SpanishVigorousInexpectatumpleco

Either way, I'm using DFHack 0.43.05-r2 with TWBT 5.86 (although I just tried updating to 6.21 and it still had the bug) with the Spacefox tileset (although it seems to occur with any other tileset all the same). This is all launched through PE's LNP.
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on September 26, 2017, 12:31:48 pm
Sadly twbt doesn't play nicely with adventure mode.
Title: Re: DFHack 0.43.05-r2
Post by: Burneddi on September 26, 2017, 12:54:53 pm
Sadly twbt doesn't play nicely with adventure mode.
I've used it in adventure mode for a good bit, and this is the only major issue I've encountered. The other problem is that the yellow descriptive text in the bottom left corner (when looking at things) flows off screen with TWBT, but it's usually not too important.
Title: Re: DFHack 0.43.05-r2
Post by: KittyTac on September 27, 2017, 04:30:04 am
Any way to raise the temperature of a loaded region to, say, 60000U?
Title: Re: DFHack 0.43.05-r2
Post by: Rumrusher on September 27, 2017, 03:29:11 pm
diving into adv mode building and wonder if it possible to say shrink the build timer to 1 hour for projects that ask for say 3000 hours to complete?
I know it possible to cut the time down with companions but kinda figure there's a more dfhacky solution.

edit: hmm it seems messing with the display timer does cut the timer down, but it doesn't speed up the building process so I guess I need to see if Companion number inflation can shorten the time needed to build large advmode constructions
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on September 28, 2017, 03:29:24 am
Never got that one working, btw, what was the flag you found to toggle the "can build here" state?
Sadly twbt doesn't play nicely with adventure mode.
I've used it in adventure mode for a good bit, and this is the only major issue I've encountered. The other problem is that the yellow descriptive text in the bottom left corner (when looking at things) flows off screen with TWBT, but it's usually not too important.
Go into travel mode and approach a site until the map zooms in a bit, particularly the first thing you do after loading a save, if it doesn't crash when the map zoom happens, it'll usually do it if you leave travel mode there, or upon re-entering it.
Title: Re: DFHack 0.43.05-r2
Post by: Roses on September 29, 2017, 10:51:05 am
So I know that it is possible to add a skill to a unit using a skill_id that doesn't exist (e.g. BOOKBINDING is skill_id 134, 135 doesn't have a skill associated with it, but I can use utils.insert_or_update() to add an entry in unit.status.current_soul.skills with a skill_id of 135). My questions are, if I have a couple dozen custom skills that I want to track, will adding them in this way cause any issues further down the line that I am not seeing? (currently I use persistent tables to store these custom skills, but having them all in the same place would be very nice). And is there any way to add a visual representation of these skills? (i.e. when 'V'isualizing a unit you can see Novice Wood Cutter, could I set it up to display my custom skills somehow?

As a bonus question, can this same method (utils.insert_or_update) be used to store custom attributes and traits? And will information stored like this be lost in save/reload?
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on September 29, 2017, 08:31:27 pm
My questions are, if I have a couple dozen custom skills that I want to track, will adding them in this way cause any issues further down the line that I am not seeing?
Yes. When (not if) Toady adds more skills, you won't be able to distinguish yours from the new ones. Maybe negative numbers would work, but I'm not sure.

Quote
And is there any way to add a visual representation of these skills? (i.e. when 'V'isualizing a unit you can see Novice Wood Cutter, could I set it up to display my custom skills somehow?
I'm not sure how DF displays skill names. If it uses a function, we probably wouldn't be able to patch that, and depending on how it works, using invalid (to DF) skill IDs could crash.

Quote
As a bonus question, can this same method (utils.insert_or_update) be used to store custom attributes and traits? And will information stored like this be lost in save/reload?
insert_or_update isn't that special - if the way in which attributes and traits are stored is similar to skills, you could probably use it. I'm guessing it would be saved, but maybe not.
Title: Re: DFHack 0.43.05-r2
Post by: KittyTac on September 30, 2017, 06:52:31 am
Is there a way to do a bodyswap?
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on September 30, 2017, 08:04:01 am
Is there a way to do a bodyswap?
If by "bodyswap" you mean to change a creature into something else, I think there's a script to do that (and it may have some issues, so I'd make sure to have a backup before trying). If you mean swapping the bodies between two creatures I assume you could convert them one at a time, but if you wanted it done completely you'd probably have to record all the features of them and apply adjustment of them to the other one afterwards (things like the shape of the nose, hair color, weight, etc).
Title: Re: DFHack 0.43.05-r2
Post by: KittyTac on September 30, 2017, 09:47:04 am
Is there a way to do a bodyswap?
If by "bodyswap" you mean to change a creature into something else, I think there's a script to do that (and it may have some issues, so I'd make sure to have a backup before trying). If you mean swapping the bodies between two creatures I assume you could convert them one at a time, but if you wanted it done completely you'd probably have to record all the features of them and apply adjustment of them to the other one afterwards (things like the shape of the nose, hair color, weight, etc).

I meant swapping the bodies of a decoy adventurer and a megabeast, as a hacky way of playing an actual worldgen megabeast.
Title: Re: DFHack 0.43.05-r2
Post by: Rumrusher on October 01, 2017, 01:40:48 am
Is there a way to do a bodyswap?
If by "bodyswap" you mean to change a creature into something else, I think there's a script to do that (and it may have some issues, so I'd make sure to have a backup before trying). If you mean swapping the bodies between two creatures I assume you could convert them one at a time, but if you wanted it done completely you'd probably have to record all the features of them and apply adjustment of them to the other one afterwards (things like the shape of the nose, hair color, weight, etc).

I meant swapping the bodies of a decoy adventurer and a megabeast, as a hacky way of playing an actual worldgen megabeast.
there should be an Adv-bodyswap script left over from uhh one of the dfhack folks remaking warmist scripts but if that got lost in the recent updates of dfhack then uhh uh oh shoot I don't know which one to port, my copy is a tad rigged for my tastes and I know there's a bodyswap script that allows for switching back to your original body that's some where in dfhack's old versions... or in dfusion.

edit : uhh oh wow there is no adv-bodyswap lua file or plugin at all in the files, there is an adv-fort but no adv-bodyswap.
Title: Re: DFHack 0.43.05-r2
Post by: Roses on October 01, 2017, 02:03:07 pm
My questions are, if I have a couple dozen custom skills that I want to track, will adding them in this way cause any issues further down the line that I am not seeing?
Yes. When (not if) Toady adds more skills, you won't be able to distinguish yours from the new ones. Maybe negative numbers would work, but I'm not sure.

I would write a small script that would always assign custom skills above whichever is the highest game skill. That way SPELL_CASTING could be 135 or 146, it would just always be tracked as #skills+1.

As for the other stuff, I guess I will just have to play around with it a little bit and see what's possible, and, more importantly, what causes crashes.

EDIT: It looks like I can use df.job_skill._last_item + X to reference a custom skill X, and that the skill will be stored nicely and remain active between save/reload. There isn't anything written in the 'V'iew screen, but I am working on a custom gui anyway so that isn't a big issue. It's really nice to be able to use the same code to handle custom skills as basic skills. You can even add entries onto df.job_skill so that code will properly understand what you are looking for (that gets rewritten every time, but that's easy enough to add to a on-load.init).

I can't figure out how to add custom attributes and traits and such (if it's even possible). Whenever I attempt to insert a new attribute into unit.body.physical_attrs or unit.status.current_soul.mental_attrs I get an error, so adding them there may not be a possibility.
Title: Re: DFHack 0.43.05-r2
Post by: Bumber on October 01, 2017, 05:03:46 pm
I would write a small script that would always assign custom skills above whichever is the highest game skill. That way SPELL_CASTING could be 135 or 146, it would just always be tracked as #skills+1.
Wouldn't that break save compatibility each time the number of skills changes? You'd be better off using arbitrarily large numbers, or moving backwards from the highest possible value.
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on October 02, 2017, 02:26:51 am
Is there a way to do a bodyswap?
If by "bodyswap" you mean to change a creature into something else, I think there's a script to do that (and it may have some issues, so I'd make sure to have a backup before trying). If you mean swapping the bodies between two creatures I assume you could convert them one at a time, but if you wanted it done completely you'd probably have to record all the features of them and apply adjustment of them to the other one afterwards (things like the shape of the nose, hair color, weight, etc).

I meant swapping the bodies of a decoy adventurer and a megabeast, as a hacky way of playing an actual worldgen megabeast.
there should be an Adv-bodyswap script left over from uhh one of the dfhack folks remaking warmist scripts but if that got lost in the recent updates of dfhack then uhh uh oh shoot I don't know which one to port, my copy is a tad rigged for my tastes and I know there's a bodyswap script that allows for switching back to your original body that's some where in dfhack's old versions... or in dfusion.

edit : uhh oh wow there is no adv-bodyswap lua file or plugin at all in the files, there is an adv-fort but no adv-bodyswap.
I was toying around trying to get this fixed so it shows a list of retired adventurer flag=true units to swap back to if targeted on yourself:
Code: (assumecontrol.lua) [Select]
--Assume Direct Control of the unit you're viewing. This Can Hurt You.
--[====[
assumecontrol
=============
Allows you to temporarily or permanently swap bodies with another unit.
Animals and other non-historical figures can be glitchy if you travel as one, be careful!
]====]
local utils = require 'gui'
local dialog = require 'gui.dialogs'

function assumeControl(new,old)
local actold
for i,j in ipairs(df.global.world.units.all) do
    if j.id==df.global.world.units.active[0].id then
        actold=j.id
        break
    end
end
local active=df.global.world.units.active
local old
old=df.unit.find(actold)
local new
new=dfhack.gui.getSelectedUnit(true)
if new==nil then
    qerror("Unable to Assume Control!")
end
local actnew
for k,v in pairs(active) do
    if v==new then
        actnew=k
        break
    end
end
if actnew==nil then
    qerror("Attempt to Assume Control has failed?")
end
if dfhack.gui.getSelectedUnit(true)==active[0] then
    local choices={}
    for k,v in pairs(active) do
        if dfhack.units.getNemesis(active[k]).flags.RETIRED_ADVENTURER==true then
            local nems=active[k]
            table.insert(choices,{text=nems.name.first_name,nems=k})
        end
        dialog.showListPrompt("Unit choice", "Choose unit to return to:", COLOR_WHITE,choices,
            function (idx,choice)
              dfhack.units.getNemesis(choice).flags.ACTIVE_ADVENTURER=true
              dfhack.units.getNemesis(choice).flags.ADVENTURER=true
              dfhack.units.getNemesis(choice).flags.RETIRED_ADVENTURER=false
              choice.status.current_soul.personality.flags[1]=true
              dfhack.units.getNemesis(old).flags.ACTIVE_ADVENTURER=false
              dfhack.units.getNemesis(old).flags.RETIRED_ADVENTURER=true
              old.status.current_soul.personality.flags[1]=false
              return
            end)
    end
end
active[actnew]=active[0]
active[0]=new
local target = dfhack.units.getNemesis(new)
    if target then
    local nwnem=dfhack.units.getNemesis(new)
    local olnem=dfhack.units.getNemesis(old)
    if olnem then
        olnem.flags.ACTIVE_ADVENTURER=false
        olnem.flags.RETIRED_ADVENTURER=true
        olnem.unit.status.current_soul.personality.flags[1]=false
        olnem.unit.idle_area.x=olnem.unit.pos.x
        olnem.unit.idle_area.y=olnem.unit.pos.y
        olnem.unit.idle_area.z=olnem.unit.pos.z
    end
    if nwnem then
        nwnem.flags.ACTIVE_ADVENTURER=true
        nwnem.flags.RETIRED_ADVENTURER=false
        nwnem.flags.ADVENTURER=true
        nwnem.unit.status.current_soul.personality.flags[1]=true
        for k,v in pairs(df.global.world.nemesis.all) do
            if v.id==nwnem.id then
                df.global.ui_advmode.player_id=k
                end
            end
        end
    else
        qerror("Assuming Direct Control! Current target may not last long!")
    end
end
assumeControl(new,old)

Commenting out those lines makes it work just fine, though it just spits an error when you dismiss the box atm, my lua mojo ran out.
Title: Re: DFHack 0.43.05-r2
Post by: KittyTac on October 02, 2017, 09:36:50 pm
OOOOOOHHHHHH YEEEEESSSSS. I can fulfill my dragon rampage dreams!  :D Oh, and can you make a script for eating things from the ground?
Title: Re: DFHack 0.43.05-r2
Post by: Thundercraft on October 03, 2017, 04:43:34 am
Thank you! 8) I'm so glad that interest in bodyswap hasn't completely disappeared and that someone worked on updating it. I was sad to see DFusion and, particularly, Rumrusher's "Adventure Tools" (aka, "adv_tools") get abandoned (http://www.bay12forums.com/smf/index.php?topic=139553.msg7034131#msg7034131), but I miss bodyswap most of all.

BTW: Which lines are the ones that need to be commented out?


Ok, either someone please tell me about a replacement to Dfusion's freaky Friday-like change adventurer script or just tell me how to re-add Dfusion.

Well, the easy part is set a target grab (dfhackgetselectedunit or whatnot) and grab hist_id, pass it to the find command (what was the dfhack one? not the df.global.find(k) one or whatnot) and it'll pull up the df.global.world.history.hist_figs[k] for you, then have it set flags[0] to true, which should add that unit to the Specific Person part of the adventurer selection screen, I've gm-editor'D a bodyswitch but it was all sorts of slapdash, it should just be a matter of unlinking your unit from df.global.world.units.active[0] and setting your new adventurer target in there, plus tracking down any hanging links left in the hist_fig part I think?

I meant swapping the bodies of a decoy adventurer and a megabeast, as a hacky way of playing an actual worldgen megabeast.
there should be an Adv-bodyswap script left over from uhh one of the dfhack folks remaking warmist scripts but if that got lost in the recent updates of dfhack then uhh uh oh shoot I don't know which one to port, my copy is a tad rigged for my tastes and I know there's a bodyswap script that allows for switching back to your original body that's some where in dfhack's old versions... or in dfusion.

edit : uhh oh wow there is no adv-bodyswap lua file or plugin at all in the files, there is an adv-fort but no adv-bodyswap.
I was toying around trying to get this fixed so it shows a list of retired adventurer flag=true units to swap back to if targeted on yourself:
Code: (assumecontrol.lua) [Select]
--Assume Direct Control of the unit you're viewing. This Can Hurt You.
--[====[
assumecontrol
=============
Allows you to temporarily or permanently swap bodies with another unit.
Animals and other non-historical figures can be glitchy if you travel as one, be careful!
]====]
local utils = require 'gui'
local dialog = require 'gui.dialogs'

function assumeControl(new,old)
local actold
for i,j in ipairs(df.global.world.units.all) do
    if j.id==df.global.world.units.active[0].id then
        actold=j.id
        break
    end
end
local active=df.global.world.units.active
local old
old=df.unit.find(actold)
local new
new=dfhack.gui.getSelectedUnit(true)
if new==nil then
    qerror("Unable to Assume Control!")
end
local actnew
for k,v in pairs(active) do
    if v==new then
        actnew=k
        break
    end
end
if actnew==nil then
    qerror("Attempt to Assume Control has failed?")
end
if dfhack.gui.getSelectedUnit(true)==active[0] then
    local choices={}
    for k,v in pairs(active) do
        if dfhack.units.getNemesis(active[k]).flags.RETIRED_ADVENTURER==true then
            local nems=active[k]
            table.insert(choices,{text=nems.name.first_name,nems=k})
        end
        dialog.showListPrompt("Unit choice", "Choose unit to return to:", COLOR_WHITE,choices,
            function (idx,choice)
              dfhack.units.getNemesis(choice).flags.ACTIVE_ADVENTURER=true
              dfhack.units.getNemesis(choice).flags.ADVENTURER=true
              dfhack.units.getNemesis(choice).flags.RETIRED_ADVENTURER=false
              choice.status.current_soul.personality.flags[1]=true
              dfhack.units.getNemesis(old).flags.ACTIVE_ADVENTURER=false
              dfhack.units.getNemesis(old).flags.RETIRED_ADVENTURER=true
              old.status.current_soul.personality.flags[1]=false
              return
            end)
    end
end
active[actnew]=active[0]
active[0]=new
local target = dfhack.units.getNemesis(new)
    if target then
    local nwnem=dfhack.units.getNemesis(new)
    local olnem=dfhack.units.getNemesis(old)
    if olnem then
        olnem.flags.ACTIVE_ADVENTURER=false
        olnem.flags.RETIRED_ADVENTURER=true
        olnem.unit.status.current_soul.personality.flags[1]=false
        olnem.unit.idle_area.x=olnem.unit.pos.x
        olnem.unit.idle_area.y=olnem.unit.pos.y
        olnem.unit.idle_area.z=olnem.unit.pos.z
    end
    if nwnem then
        nwnem.flags.ACTIVE_ADVENTURER=true
        nwnem.flags.RETIRED_ADVENTURER=false
        nwnem.flags.ADVENTURER=true
        nwnem.unit.status.current_soul.personality.flags[1]=true
        for k,v in pairs(df.global.world.nemesis.all) do
            if v.id==nwnem.id then
                df.global.ui_advmode.player_id=k
                end
            end
        end
    else
        qerror("Assuming Direct Control! Current target may not last long!")
    end
end
assumeControl(new,old)

Commenting out those lines makes it work just fine, though it just spits an error when you dismiss the box atm, my lua mojo ran out.
Title: Re: DFHack 0.43.05-r2
Post by: Rumrusher on October 03, 2017, 04:08:15 pm
don on me that I still haven't fix the invoke script to add a new dialog option than just changing or converting some options.
this probably would fix and lead to some more dialog options in adventure mode or setting up Scripts that trigger on conversation.
being able to mandatory force folks to accepting hearthperson roles, or taking folks positions away seems ok.
probably call it the dialog-unlocker.
Title: Re: DFHack 0.43.05-r2
Post by: Rose on October 03, 2017, 11:37:41 pm
So, I've been working on a little change to the RPC stuff in DFHack, and due to its nature, I think it needs a bit of discussion.

PR Here: https://github.com/DFHack/dfhack/pull/1173

Basically, it allows the user to turn on being able to use the DFHack RPC stuff from outside their computer. This is dangerous, obviously, which is why not all RPC functions are available. Biggest two that are disabled are the run command and the lua command, both of which can potentially wreck your everything due to being able to run arbitrary code.

So, opinions?
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on October 04, 2017, 04:07:37 am
Thank you! 8) I'm so glad that interest in bodyswap hasn't completely disappeared and that someone worked on updating it. I was sad to see DFusion and, particularly, Rumrusher's "Adventure Tools" (aka, "adv_tools") get abandoned (http://www.bay12forums.com/smf/index.php?topic=139553.msg7034131#msg7034131), but I miss bodyswap most of all.

BTW: Which lines are the ones that need to be commented out?
These:
Code: (attempt at getting "select past adventurers via list" to work) [Select]
if dfhack.gui.getSelectedUnit(true)==active[0] then
    local choices={}
    for k,v in pairs(active) do
        if dfhack.units.getNemesis(active[k]).flags.RETIRED_ADVENTURER==true then
            local nems=active[k]
            table.insert(choices,{text=nems.name.first_name,nems=k})
        end
        dialog.showListPrompt("Unit choice", "Choose unit to return to:", COLOR_WHITE,choices,
            function (idx,choice)
              dfhack.units.getNemesis(choice).flags.ACTIVE_ADVENTURER=true
              dfhack.units.getNemesis(choice).flags.ADVENTURER=true
              dfhack.units.getNemesis(choice).flags.RETIRED_ADVENTURER=false
              choice.status.current_soul.personality.flags[1]=true
              dfhack.units.getNemesis(old).flags.ACTIVE_ADVENTURER=false
              dfhack.units.getNemesis(old).flags.RETIRED_ADVENTURER=true
              old.status.current_soul.personality.flags[1]=false
              return
            end)
    end
end

don on me that I still haven't fix the invoke script to add a new dialog option than just changing or converting some options.
this probably would fix and lead to some more dialog options in adventure mode or setting up Scripts that trigger on conversation.
being able to mandatory force folks to accepting hearthperson roles, or taking folks positions away seems ok.
probably call it the dialog-unlocker.
Now I wanna get out of "woodcarving mode" and back into "hackery mode" and try to figure out how to make a list prompt version of that, though I'd have gone with allconvo.lua or convocontrol.lua myself.
Title: Re: DFHack 0.43.05-r2
Post by: Warmist on October 04, 2017, 04:14:09 am
So, I've been working on a little change to the RPC stuff in DFHack, and due to its nature, I think it needs a bit of discussion.

PR Here: https://github.com/DFHack/dfhack/pull/1173

Basically, it allows the user to turn on being able to use the DFHack RPC stuff from outside their computer. This is dangerous, obviously, which is why not all RPC functions are available. Biggest two that are disabled are the run command and the lua command, both of which can potentially wreck your everything due to being able to run arbitrary code.

So, opinions?

My view is reverse: allow everything, but be disabled by default.
Title: Re: DFHack 0.43.05-r2
Post by: Rose on October 04, 2017, 04:38:13 am
It's currently setup to be disabled by default, actually.
Title: Re: DFHack 0.43.05-r2
Post by: KittyTac on October 04, 2017, 06:29:37 am
Again, any way to eat things from the ground?
Title: Re: DFHack 0.43.05-r2
Post by: Warmist on October 04, 2017, 07:39:08 am
Again, any way to eat things from the ground?
Nope, but you can e.g. haul the item before trying to eat.
Title: Re: DFHack 0.43.05-r2
Post by: KittyTac on October 04, 2017, 08:33:48 am
Again, any way to eat things from the ground?
Nope, but you can e.g. haul the item before trying to eat.

I meant a script. Dragons don't have hands, you know.
Title: Re: DFHack 0.43.05-r2
Post by: Nagidal on October 06, 2017, 01:33:27 pm
I'm experiencing a weird bug when refreshing Dwarf Therapist when a migrant wave is currently incoming. Last time I did thins when migrants were incoming and a caravan leaving. It looks like migrant dwarves are stuck outside of the map. In a previous fortress I had a caravan stuck outside of the map and a new one never arrived again.  :'(

http://dffd.bay12games.com/file.php?id=13121 (http://dffd.bay12games.com/file.php?id=13121)

I don't know whether this is a Dwarf Therapist or a DFHack issue, I think it could be either one, because DT only uses when DFHack gives it, but I also read that they DT may be connecting and disconnecting to DF memory every time it refreshes... so I don't know. I also reported this bug in DT GitHub, hoping that either you or the DT guys will find the cause for this.

Thank you for your involvement.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on October 06, 2017, 02:03:55 pm
I don't know whether this is a Dwarf Therapist or a DFHack issue, I think it could be either one, because DT only uses when DFHack gives it, but I also read that they DT may be connecting and disconnecting to DF memory every time it refreshes... so I don't know. I also reported this bug in DT GitHub, hoping that either you or the DT guys will find the cause for this.
DFHack currently doesn't provide any data to DT. (Well, you can generate layout files for DT using DFHack, but DT is independent from DFHack otherwise, and you should run into the same issues regardless of whether you're actually using DFHack.)
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on October 06, 2017, 03:22:01 pm
However, there are quite a few issues on the forum regarding merchants/migrants/sieges stuck more or less off the map, and in the cases explored it does seem to be a vanilla DF bug (or set of bugs), unrelated to either DFHack or DT. It's quite natural that you'd see the bug as you refresh DT, as you'd refresh DT as migrants arrive, so if it happens "naturally" you'd also have refreshed DT to look at the new arrivals.
When a caravan gets stuck it tends to block other caravans from appearing.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on October 06, 2017, 09:07:39 pm
I was wondering for a bit there if DT saving changes in the middle of a migrant wave could be a cause, e.g. if it broke yet-to-arrive migrants. However, I can't think of a good reason for people to be consistently committing changes with DT during a siege or caravan arrival, so that might not be it.

DFHack does have a couple of recently-added scripts to address that issue, anyway. Check the changelog for details - maybe fix/stuck-merchants is one of them.
Title: Re: DFHack 0.43.05-r2
Post by: feelotraveller on October 07, 2017, 12:00:54 am
This is off topic for dfhack, I believe.

But just to chip in because the comments are here - Dwarf Therapist can cause this issue.  :( I'm not sure of the how but I have experienced it myself (infrequently).  Best practice is not to refresh DT (nor to save DF for that matter...) whilst migrants are arriving - that is until you are certain that all new arrivals are on the map.  DT was changed (34.0, I think) to show the entire migration wave once they have started to arrive (and if memory serves you can actually see the migrant wave shortly before they are announced and start to arrive on the map) but did not address this problem. 

I also advise against refreshing DT whilst the caravan is departing as this can cause oddness, at least as far as DT information display is concerned.  Although once it caused me serious 'game-ending' problems. In this case making a save as a backup should be fine (I think) if you want to try your luck with DT, since it is often ok.

If the unit-id of the missing dwarf can be ascertained then I would suggest using 'teleport' to bring them onto the map and all should be good.  Getting the unit-id could be tricky though?  Patrik, I seem to remember you dealing with this problem for the missing merchants, am I wrong?  Or is there a shortcut where the dwarf will have unit-id one higher than the other dwarf of the migrant wave...?
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on October 07, 2017, 03:24:11 am
The cause of Nagidal's (and other sufferers') problem is not a DFHack issue, but a possible fix could be...
I don't understand how reading the DF memory could screw up the data structure (while not saying it's impossible just because of my limited imagination), but making use of it (as in changing character data, such as nick names, job allocations, etc.) might. Also, I would advice against doing DT changes while DF isn't paused.
If DT can cause the issue, it would probably be good to have a save where you an provoke it with some degree of reliability to investigate what's happening.
I would be careful with saving in the middle of a migrant/caravan/siege arrival, though, as I believe that has been thought to trigger the issues.

With the merchants I looked for units that were merchants and some other criteria. With migrants I'd start to look at the end of the unit list and also the unit ids following the next visible ones. However, poking around in a bugged save is probably the only way to figure out how to identify the bugged ones (except, of course, understanding what causing the problem and address that, but we seem to be far away from that, struggling with trying to address the symptoms). In fact, I had intended to look at Nagidal's problem about now if a save had been provided.
Title: Re: DFHack 0.43.05-r2
Post by: Nagidal on October 07, 2017, 05:03:58 am
Thank you for your input. I had provided the link (http://dffd.bay12games.com/file.php?id=13121) to the save in the initial post about this.

Because this problem has cost me one fort already where both migrants and caravans simply stopped arriving, and may cost me this one too, I had figured I should take the same precautions PatrikLundell and feelotraveller have suggested:


It looks like you guys don't need to take any further action now. When my liason finally left the map, the missing/stuck migrant dwarf either sneakily came. I can see him in the unit list now. I don't want to distract you anymore with this off-topic issue. Thanks for your assistance. I'll be using the tool carefully now.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on October 07, 2017, 08:16:49 am
Sorry for missing the first link.
I've started to look into the issue (before Nagial updated the previous post). As far as I can see Bomrek Mirrorbridges is marked as dead and incoming. He appears as the last migration wave according to DT, but is actually above the second last wave dwarf in the internal DF unit list (by a few units). Toggling the <unit>.flags1.dead flag causes him to move into the fortress, but NOT appear on the any of the DF unit tabs. I've seen a similar issue with "revived" merchants before, i.e. they are there, but not "detected".

Edit:
And yes, allowing DF to do its own thing without hacking causes the migrant to arrive without the "dead" flag set, so apparently we should be careful with interpreting the "dead" flag as meaning "not alive", as well as resetting it without doing whatever unknown things DF does in addition to that to get the unit into play.
Title: Re: DFHack 0.43.05-r2
Post by: Bumber on October 07, 2017, 09:57:10 pm
Again, any way to eat things from the ground?
Nope, but you can e.g. haul the item before trying to eat.
I meant a script. Dragons don't have hands, you know.
I don't think you need hands to haul. See if you can get the item there through hackery.
Title: Re: DFHack 0.43.05-r2
Post by: KittyTac on October 07, 2017, 10:10:51 pm
Again, any way to eat things from the ground?
Nope, but you can e.g. haul the item before trying to eat.
I meant a script. Dragons don't have hands, you know.
I don't think you need hands to haul. See if you can get the item there through hackery.

Uh, I'm a Dabbling Coder. I will probably royally mess something up.
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on October 07, 2017, 10:13:11 pm
Well, you can make a backup, and have a learning experience.
Title: Re: DFHack 0.43.05-r2
Post by: KittyTac on October 07, 2017, 10:29:05 pm
Well, you can make a backup, and have a learning experience.

By that I mean, I can't code for crap and I probably won't be able to do this even if I wouldn't mess something up.
Title: Re: DFHack 0.43.05-r2
Post by: feelotraveller on October 08, 2017, 01:29:31 am
I don't understand how reading the DF memory could screw up the data structure (while not saying it's impossible just because of my limited imagination), but making use of it (as in changing character data, such as nick names, job allocations, etc.) might.

You are quite correct.  My mistake.

Quote
If DT can cause the issue, it would probably be good to have a save where you an provoke it with some degree of reliability to investigate what's happening.
I would be careful with saving in the middle of a migrant/caravan/siege arrival, though, as I believe that has been thought to trigger the issues.

Unfortunately the issue arises in middle of a migrant wave arrival.  These are somewhat randomised making it difficult to get a save just before a migrant wave starts, and even then, in my limited experience, you get a different makeup of the migrant wave.  And once it has started saving can cause problems without DT playing a part. 

If I get another one I'll definitely post it (but I prefer touching wood, casting salt over my shoulder, not stepping on cracks...).  In my experience the likelihood of a problem is in the region of 10% so if you are determined you can probably generate your own example.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on October 08, 2017, 02:32:26 am
I think stuck migrant investigations need to start with looking at cases where migrants are definitely stuck to figure out what they look like. From there I'd try to provoke it with DT while using a stuck detection script (resulting from the first step of the investigation) before and after invoking DT to verify DT is actually responsible.
Personally I delay processing of migrants until all of them are on the map. At that time I assign the animals to pastures and assign jobs to new arrivals. There isn't any benefit in hurrying the job assignment, since migrants will first head to a meeting area and be marked as "new arrival" for quite some time. This is not saying DT shouldn't be made safe if possible, only that a safer usage won't hurt your fortress' efficiency.
Title: Re: DFHack 0.43.05-r2
Post by: feelotraveller on October 08, 2017, 04:12:33 am
Yep, all good. 

Just to note that the issue has arisen for me when changing the labours of dwarfs who are already fortess inhabitants when migrants are incoming.  (Tempts me to speculate that DT overwrites all labours... but that's pure speculation...)  And for some of us ('micromanagers') not changing labours for that long can be excruciating.  ;D

(Btw I think you need to search and replace your last post "I'd" -> "I'll"  :P)

Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on October 08, 2017, 06:15:55 am
I'm fairly micro managery as well, but I've been able to temper it with the realization that delaying the management a bit doesn't change the outcome at all. Interesting data point that changing something unrelated might still cause issues. Would -> will would depend on whether I get my hands on a suitable "seed" save that's bugged and whether someone else does it before me.
Title: Re: DFHack 0.43.05-r2
Post by: Thundercraft on October 12, 2017, 11:15:31 am
Does there already exist a DFhack script to allow the remains of tame or trained animals to be butchered? I searched the DFhack documentation, but I couldn't find anything.

If not, how would I go about flipping the dead_dwarf flag on a specific corpse back to false? I don't want to bring it back to life. But I do want to stop the usual pet-burial behavior in order to butcher it, instead. (See this post (http://www.bay12forums.com/smf/index.php?topic=161408.msg7341491#msg7341491) in relation to issue 1275 (http://www.bay12games.com/dwarves/mantisbt/view.php?id=1275).)
Title: Re: DFHack 0.43.05-r2
Post by: FantasticDorf on October 12, 2017, 11:36:41 am
Does there already exist a DFhack script to allow the remains of tame or trained animals to be butchered? I searched the DFhack documentation, but I couldn't find anything.

If not, how would I go about flipping the dead_dwarf flag on a specific corpse back to false? I don't want to bring it back to life. But I do want to stop the usual pet-burial behavior in order to butcher it, instead. (See this post (http://www.bay12forums.com/smf/index.php?topic=161408.msg7341491#msg7341491) in relation to issue 1275 (http://www.bay12games.com/dwarves/mantisbt/view.php?id=1275).)

Read a little bit further into the thread and there's a script that automatically turns items to false (http://www.bay12forums.com/smf/index.php?topic=161408.msg7455623#msg7455623)  by Altree.

I recommend that you persist reading the thread in entirety.
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on October 12, 2017, 12:15:50 pm
There is also DFHack Script: Unbutcherable Sentient Workaround for fortress mode (http://www.bay12forums.com/smf/index.php?topic=165414.0) to persistently do it whenever something dies.
Title: Re: DFHack 0.43.05-r2
Post by: Rumrusher on October 13, 2017, 04:17:18 pm
well been working on a revised invoke script for adding a new dialog option
and got up to the game adding a new dialog choice
Spoiler (click to show/hide)
the issue is I ended up copying the first choice over the new one and the changes effect both... so now I need to figure out how to make a blank choice option to insert any dialog choice... also write a change the only bottom number in a vector for the page bottom choices.

Title: Re: DFHack 0.43.05-r2
Post by: Burneddi on October 14, 2017, 08:53:56 am
3dveins is giving me a "Discontinuous layer 1 at (73,86,120)" error. I'm guessing this might be because I have an ocean embark, but am not sure.

Is there any way to rectify this? Already tried fixveins but it didn't seem to do anything. I like using 3dveins.
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on October 15, 2017, 10:47:30 am
When speaking about fixing things, how hard would it be to fix falconne's automaterial/automelt to work like his search/buildingplan/dwarfmonitor/resume/pasture assignment in regards to lua viewscreens (in that the first wouldn't disappear while one is up, like the latter don't)?
(mousequery falls somewhere in-between, where it displays data, but doesn't place floors)

((Though at least it looks like one might be able to replicate automelt's gui frontend entirely, I don't see how to do it for automaterial.))

(((For constructmultiz, I worked around this by making the viewscreen poof while building constructions, but that's not exactly ideal.)))
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on October 15, 2017, 10:27:20 pm
BLARGH, frustratingly close but I've been trying to resist the urge to start rebuilding all of the hack/gui/widgets.lua chunks I need, recently I got the pieces to show up and act like they might want to work when I tried reversing the order they are displayed but it's still not wanting to pass the input-or-choice from one dialog to the other, which I feel like there is an obvious trick I'm missing for but even trying to steal an example of it from other scripts I've had no luck:
Code: (attempted gui/gm-editor "find_type" function) [Select]
function GmEditorUi:find_type()
    local list={}
    for i in pairs(df) do
        table.insert(list,{text=('%s'):format(tostring(df[i]), i), type=i})
    end
    guiScript.start(function()
        dialog.showInputPrompt("Testing","Value to find:",COLOR_WHITE,"",
        function()
            dialog.showListPrompt("Select type to find:",nil,COLOR_WHITE,list,
            function()
                local key = self:currentTarget()
                self:pushTarget(df.key.find("..input.."))
            end)
        end)
    end)
end
Gone through a bunch of iterations incidentally, tried stripping it down to just the dialogs, tried having it call a "just select_type" function from a find_type one, tried copying bits of the various similar scripts in gm-editor itself, but I still can't get it to pass the values on properly, just gives the "attempt to index a nil value" for something I just assigned a value for in the prior steps.
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on October 15, 2017, 11:02:51 pm
This no good?

I've got the feeling that it is not what you want, but I used the "call function defined elsewhere" quite nicely to have a popup dialog to change a number in the constructmultiz indicator framedscreen.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on October 16, 2017, 07:51:14 am
When speaking about fixing things, how hard would it be to fix falconne's automaterial/automelt to work like his search/buildingplan/dwarfmonitor/resume/pasture assignment in regards to lua viewscreens (in that the first wouldn't disappear while one is up, like the latter don't)?
(mousequery falls somewhere in-between, where it displays data, but doesn't place floors)

((Though at least it looks like one might be able to replicate automelt's gui frontend entirely, I don't see how to do it for automaterial.))

(((For constructmultiz, I worked around this by making the viewscreen poof while building constructions, but that's not exactly ideal.)))
Are you working with a Lua overlay/dialog or something? I've seen a couple plugins that don't display under overlays, and I imagine the two you mentioned are similar and not too hard to change. Getting mouse input passed through to mousequery could be hard, though.
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on October 16, 2017, 10:36:01 am
Yes, exactly.

Just tested whether mousequery respects gui.simulateInput/screen:sendInputToParent (with and without flickering on-off). [It doesn't]. OTOH, in build mode replicating placing cursor at mouse position and then placing selected building at mouse position isn't difficult.
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on October 16, 2017, 12:54:03 pm

Just tested whether mousequery respects gui.simulateInput/screen:sendInputToParent (with and without flickering on-off). [It doesn't].
I'm not sure what you're saying here. Mousequery isn't a screen, so you can't send keys to it (and it really only looks at the mouse status in the enabler global anyway, from what I remember).
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on October 16, 2017, 01:12:30 pm
I dunno (haven't read up on) how the mousequery detects mouse clicks, but I know it does it somehow, so I thought it worth testing for methods that work with cascading keys down with other options.

E: Oh yeah, forgot to mention but after reading your post tested that toggling enabler works to trigger mousequery, thanks.
Title: Re: DFHack 0.43.05-r2
Post by: Vi Et Armis on October 17, 2017, 05:25:47 pm
Hey guys, I just wanted to poke my head in and offer my thanks for such an awesome project/ecosystem!

I am planning to make some exploratory changes to help out a bit (hopefully... I'm dtimm on github) and learn the code base, so I will see you around!
Title: Re: DFHack 0.43.05-r2
Post by: KittyTac on October 17, 2017, 10:10:47 pm
Is there a way to make an adventurer retire in the wild?
Title: Re: DFHack 0.43.05-r2
Post by: Amostubal on October 19, 2017, 07:34:10 am
Okay I was doing some work on fixing a modtool script that is, I'm guessing, out dated or just incomplete.  The particular one was skill-change.lua

So after a few changes to fix things such as actually forcing rating increase (otherwise you could just add 100,000 exp and it wont change the rating) and stopping it from jumping the L+5 mark(rating 20) on skills.  the issue now is that I know certain skills have a higher max than rating 20. considering this quote from the wiki under skills:

Quote
Combat skills can scale upwards to a functionally impossible to reach degree, meaning that simply reaching Legendary in a combat skill only means they've just started climbing the ranks of the legendary warriors of Dwarf Fortress. A Legendary +100 warrior will more regularly hit and deal more damage than a "mere" Legendary +10, although it takes nearly three-quarters of a million more experience points to get there.

My issue is that it doesn't clearly define which skills these are.  I'm fairly certain the weapon skills are considered in this, such as AXE and CROSSBOW.... I need a full list so that I'm not making this script cap a skill that doesn't have a cap.  Anyone have that info?
Title: Re: DFHack 0.43.05-r2
Post by: Roses on October 19, 2017, 01:50:15 pm
Okay I was doing some work on fixing a modtool script that is, I'm guessing, out dated or just incomplete.  The particular one was skill-change.lua

So after a few changes to fix things such as actually forcing rating increase (otherwise you could just add 100,000 exp and it wont change the rating) and stopping it from jumping the L+5 mark(rating 20) on skills.  the issue now is that I know certain skills have a higher max than rating 20. considering this quote from the wiki under skills:

Quote
Combat skills can scale upwards to a functionally impossible to reach degree, meaning that simply reaching Legendary in a combat skill only means they've just started climbing the ranks of the legendary warriors of Dwarf Fortress. A Legendary +100 warrior will more regularly hit and deal more damage than a "mere" Legendary +10, although it takes nearly three-quarters of a million more experience points to get there.

My issue is that it doesn't clearly define which skills these are.  I'm fairly certain the weapon skills are considered in this, such as AXE and CROSSBOW.... I need a full list so that I'm not making this script cap a skill that doesn't have a cap.  Anyone have that info?

I'm pretty sure you can set any skill to higher than 20 with DFHack without any problems (at least that's what I remember from the last time I tested this). It's just that only certain skills actually benefit from having higher than 20. So the first order fix would just be to allow the number to go as high as you want.
Title: Re: DFHack 0.43.05-r2
Post by: Amostubal on October 19, 2017, 02:40:22 pm
Okay I was doing some work on fixing a modtool script that is, I'm guessing, out dated or just incomplete.  The particular one was skill-change.lua

So after a few changes to fix things such as actually forcing rating increase (otherwise you could just add 100,000 exp and it wont change the rating) and stopping it from jumping the L+5 mark(rating 20) on skills.  the issue now is that I know certain skills have a higher max than rating 20. considering this quote from the wiki under skills:

Quote
Combat skills can scale upwards to a functionally impossible to reach degree, meaning that simply reaching Legendary in a combat skill only means they've just started climbing the ranks of the legendary warriors of Dwarf Fortress. A Legendary +100 warrior will more regularly hit and deal more damage than a "mere" Legendary +10, although it takes nearly three-quarters of a million more experience points to get there.

My issue is that it doesn't clearly define which skills these are.  I'm fairly certain the weapon skills are considered in this, such as AXE and CROSSBOW.... I need a full list so that I'm not making this script cap a skill that doesn't have a cap.  Anyone have that info?

I'm pretty sure you can set any skill to higher than 20 with DFHack without any problems (at least that's what I remember from the last time I tested this). It's just that only certain skills actually benefit from having higher than 20. So the first order fix would just be to allow the number to go as high as you want.

Ahhh I did not think about this... well then a slight tweak and I'll post it to github like that unless anyone else have a differing opinion... Its only a few minor fixes but it was giving me such a headache when I realized what it was doing.
Title: Re: DFHack 0.43.05-r2
Post by: MCreeper on October 21, 2017, 05:29:27 am
It seems my dfhack don't see plugins. When i tryed to use tiletypes to partially delete aquifer, it said "tiletypes is not recognised command". When i try "plug tiletypes" it gives me "plugin does not exist"  - everything. What to do? I don't want to remove all aquifer, i still need it it to test one thing.
Also, what dfhack-run.exe does? DFhack launches just fine, but when i try to open exe it gives me "it's not win32 exe", i.e. it's not windows XP exe, which is pretty ridiculous.  ::)
Title: Re: DFHack 0.43.05-r2
Post by: lethosor on October 21, 2017, 02:43:41 pm
Can you run "plug" and paste the output?
Title: Re: DFHack 0.43.05-r2
Post by: Rumrusher on October 22, 2017, 04:05:19 am
slowly working on this "add new dialog to adventure mode" project and learn how to insert a new choice option.
the problem I'm having now is that I can't fill out the Talk_choice section of the choices. and I can't just copy and paste some other choice on to this as it seems to end up sharing the same value leading to having 2 talk choice being the same but taking up 2 slots on the dialog list.
so kinda stumped and spent most my time poking around old scripts to get a better idea on how to fill out this
Code: [Select]
df.global.ui_advmode.conversation[insert number here].choices.choice option.

on the side of things you could chain performances and possibly have 2 performers perform at the same time, if someone wanted to make a script that commands bard companions to tell a speech in a middle of a musical number they aren't in.
Title: Re: DFHack 0.43.05-r2
Post by: feelotraveller on October 22, 2017, 05:15:05 pm
Is there a way/script in DFHack to "clone" a dwarf (fortress mode)?  I'm looking to do some testing and would like perfect copies, including for example sleep and hunger counters.  Don't mind overwriting another existing dwarf to get it done.  If not, how close can I get?
Title: Re: DFHack 0.43.05-r2
Post by: Amostubal on October 23, 2017, 08:45:08 pm
Is the vanilla hard coded workshops, their tile data, possible to be edited directly through dfhack?

I had an idea but I really wanted to change a few shop images completely...
and it sounds like its possible.  But I can't find the right direction to get there... I'm not talking TWBT...as TWBT only goes sooo far.  I'm talking actually changing every single location to exactly what I want it to be...

Besides directly editting these through DFHack I've also considered what it would take to copy building menus to new buildings...  like pulling the menu/reactions for the still to a new custom building.  anyways if anyone has an idea of how this could be done.. I'd appreciate it.
Title: Re: DFHack 0.43.05-r2
Post by: Warmist on October 23, 2017, 10:05:27 pm
Is the vanilla hard coded workshops, their tile data, possible to be edited directly through dfhack?

I had an idea but I really wanted to change a few shop images completely...
and it sounds like its possible.  But I can't find the right direction to get there... I'm not talking TWBT...as TWBT only goes sooo far.  I'm talking actually changing every single location to exactly what I want it to be...

Besides directly editting these through DFHack I've also considered what it would take to copy building menus to new buildings...  like pulling the menu/reactions for the still to a new custom building.  anyways if anyone has an idea of how this could be done.. I'd appreciate it.
First one is possible, but hard-ish. You need to vmethod-interpose a building vmethod (i think it's called "render"). This can only be done by writing a plugin.
Second one could be faked i think. There is eventful plugin (https://dfhack.readthedocs.io/en/stable/docs/Lua%20API.html#functions) that allows displaying any sidebar you want on a building.
Title: Re: DFHack 0.43.05-r2
Post by: Amostubal on October 24, 2017, 10:03:44 am
Is the vanilla hard coded workshops, their tile data, possible to be edited directly through dfhack?

I had an idea but I really wanted to change a few shop images completely...
and it sounds like its possible.  But I can't find the right direction to get there... I'm not talking TWBT...as TWBT only goes sooo far.  I'm talking actually changing every single location to exactly what I want it to be...

Besides directly editting these through DFHack I've also considered what it would take to copy building menus to new buildings...  like pulling the menu/reactions for the still to a new custom building.  anyways if anyone has an idea of how this could be done.. I'd appreciate it.
First one is possible, but hard-ish. You need to vmethod-interpose a building vmethod (i think it's called "render"). This can only be done by writing a plugin.
Second one could be faked i think. There is eventful plugin (https://dfhack.readthedocs.io/en/stable/docs/Lua%20API.html#functions) that allows displaying any sidebar you want on a building.

I've seen those eventful functions and how you can say turn the menu into a custom workshop_overlay... I'm reading through a lot of code at the moment... to see if I see something that could say tag what the menu is for a vanilla hard coded shop so I could pass that to a custom shop.  I think it could really be helpful.  Which reminds me I need to send some stuff up to the repo.

anyways so i was going through the eventful.lua and I saw that there was some stuff that seemed to have stopped mid development, for whatever reason.  I'm considering how some of this works and what could be accomplished without going as far as say a cpp.  Maybe either giving a workshop a different workshop def at best or at worst pulling the menu from a different workshop def over a custom workshops menu... thanks for the direction on this Warmist...  oh and I like some of the work of yours that I've seen in the past.
Title: Re: DFHack 0.43.05-r2
Post by: MoonyTheHuman on October 24, 2017, 01:36:28 pm
Has anyone ever toyed with the concept of a offscreen viewport? You know, rendering parts of the map that are offscreen without moving the viewport.
If it requires writing custom rendering, fine by me. I just want a bit of guidance so i know (roughly) where to aim at this whale.
Title: Re: DFHack 0.43.05-r2
Post by: Warmist on October 24, 2017, 02:15:58 pm
Has anyone ever toyed with the concept of a offscreen viewport? You know, rendering parts of the map that are offscreen without moving the viewport.
If it requires writing custom rendering, fine by me. I just want a bit of guidance so i know (roughly) where to aim at this whale.
It's DONE!*

* by done i mean it's in pull-req. Basically mifki found "render_map" function that df uses to render the map. You can use it (with before setting viewscreen pos and later restoring) to render any part of map. Look here:  my repo (https://github.com/warmist/dfhack/blob/twbt_experiments/plugins/twbt-utils.cpp#L66). Basically i've been using it for multiplayer thing. This link has code that exposes the function to lua. All it's missing is offsets from mifki repo  here  (https://github.com/mifki/df-twbt/blob/master/patches.hpp#L779)
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on October 24, 2017, 02:54:26 pm
Has anyone ever toyed with the concept of a offscreen viewport? You know, rendering parts of the map that are offscreen without moving the viewport.
If it requires writing custom rendering, fine by me. I just want a bit of guidance so i know (roughly) where to aim at this whale.
I guess it depends on what you mean by that question. Warmist has provided an answer that, if I understand it correctly, allows you to render a different part of an embark(?). I suspect that's the info you're after.

If you're trying to render things outside of the embark it gets trickier, as much of the details do not exist outside of the embark. However, if you're aiming at higher levels (such as the world map level), that info is largely available, while mid level tile info is available only for the world tile in focus pre embark, and the embark world tile plus the 8 surrounding ones in a fortress. Still, if you can get at the info you should be able to render it using a grid based view (a pen array is a good foundation, and I've made a widget based on that for my own scripts) once you've decided on an encoding of the info.
Title: Re: DFHack 0.43.05-r2
Post by: Rumrusher on October 26, 2017, 12:10:25 pm
well finally with help from irc on the insert data got a script that inserts a new adventure mode talk option,
and used this to pull one of the demon binding talk options
which works well on Everyone, though using this will cause them to say your their master, and probably backstab your companions/bound beings
Spoiler (click to show/hide)
(http://www.truimagz.com/host/rumrusher/folder4/invoke-revise-showcase.gif)

edit: this script is an older version that didn't all the way work.
use this one if you want a single dialog option that grants you access to demon binding on everyone... through talking.
Spoiler (click to show/hide)
Title: Re: DFHack 0.43.05-r2
Post by: FantasticDorf on October 26, 2017, 12:59:25 pm
Time to do this with random wild animals as a elf i guess.
Title: Re: DFHack 0.43.05-r2
Post by: Rumrusher on October 27, 2017, 05:54:05 am
Time to do this with random wild animals as a elf i guess.
man I remember doing this with a mod.
giving elves the ability to grant folks the gift of speech and intelligence opens up to bear companions and animals holding your gear, then making so this gift also pumps their adventure seeking trait to max allows them to agree to join you.
the script just make it so you can avoid going through the mod hassle.
with a small amount of extra work, I could see if I can stick in the Banishment option from my old invoke script.
so you can ... uhh kill... well vaporize folks with words.

edit: crud on a stick this script still busted

edit2: okay got this fixed and now allows the player to banish and bind anyone one, as a dialog option.
Spoiler: "invoke revise script" (click to show/hide)
I probably should change the script I linked in the old post so folks don't get the buggy version...
Title: Re: DFHack 0.43.05-r2
Post by: Dunmeris on October 28, 2017, 11:16:25 pm
So, what sort of DFHackery would I have to do to make monotheism? Is there even a way?
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on October 29, 2017, 04:04:40 am
So, what sort of DFHackery would I have to do to make monotheism? Is there even a way?
This is really stuff expected to be covered in the Myth & Magic arcs (and not necessarily the first one).
In the nearer time frame, it depends on what you mean with monotheism.
- If you mean there's only a single god in the world, you could presumably remove all but one and then search all units to replace their deity references with only that one or none (I'd check if the same can be done with hist figs).
- If you mean there's only a single god in each pantheon you could do the same but for each civ.
In both of the cases you'll probably end up with a somewhat inappropriate single aspect type of god, though.

However, neither method would stop development of worship of e.g. megabeasts, and the somewhat broken worship inheritance system where children inherit the mother's gods plus a random one (or none) with duplicates possible remains.
Title: Re: DFHack 0.43.05-r2
Post by: Dunmeris on October 29, 2017, 05:23:35 pm
So, what sort of DFHackery would I have to do to make monotheism? Is there even a way?
This is really stuff expected to be covered in the Myth & Magic arcs (and not necessarily the first one).
In the nearer time frame, it depends on what you mean with monotheism.
- If you mean there's only a single god in the world, you could presumably remove all but one and then search all units to replace their deity references with only that one or none (I'd check if the same can be done with hist figs).
- If you mean there's only a single god in each pantheon you could do the same but for each civ.
In both of the cases you'll probably end up with a somewhat inappropriate single aspect type of god, though.

However, neither method would stop development of worship of e.g. megabeasts, and the somewhat broken worship inheritance system where children inherit the mother's gods plus a random one (or none) with duplicates possible remains.

Thanks. I'm fine with megabeast worship being a thing, and even with the majority of civs being polytheistic. The thing is, I basically just want there to be a couple of strictly monotheistic religions followed by certain civs for whom A) polytheism doesn't make sense, and B) I've got a religion and narrative thought out.
Title: Re: DFHack 0.43.05-r2
Post by: Grimm Spector on October 29, 2017, 06:25:42 pm
Using the DFHack advfort stuff, and I was able to make a masons workshop, and a couple gabbro blocks out of a piece of gabbro stone...but after making one set of blocks, and having more stone, I can't see to make anymore blocks.

Additionally I'm trying to make a metalsmiths forge, but it doesn't seem to want to accept my fireproof block as a material...

I also can't make any stone items at the masons now that I've used it once, with any stone at the workshop...

I am very confused, some help would be super awesome!
Title: Re: DFHack 0.43.05-r2
Post by: Grimm Spector on October 29, 2017, 08:23:04 pm
Using the DFHack advfort stuff, and I was able to make a masons workshop, and a couple gabbro blocks out of a piece of gabbro stone...but after making one set of blocks, and having more stone, I can't see to make anymore blocks.

Additionally I'm trying to make a metalsmiths forge, but it doesn't seem to want to accept my fireproof block as a material...

I also can't make any stone items at the masons now that I've used it once, with any stone at the workshop...

I am very confused, some help would be super awesome!

Found picking up and dropping items repeatedly fixed some of this nonesense...

but now the built smelter and wood furnace don't have the "TAB" option as a workshop, only the masons shop seems to be a workshop...so I can't do anything anywhere but there...any ideas?
Title: Re: DFHack 0.43.05-r2
Post by: Grimm Spector on October 30, 2017, 09:06:44 am
Using the DFHack advfort stuff, and I was able to make a masons workshop, and a couple gabbro blocks out of a piece of gabbro stone...but after making one set of blocks, and having more stone, I can't see to make anymore blocks.

Additionally I'm trying to make a metalsmiths forge, but it doesn't seem to want to accept my fireproof block as a material...

I also can't make any stone items at the masons now that I've used it once, with any stone at the workshop...

I am very confused, some help would be super awesome!

More information, I've found that what's happening is that the build process isn't finishing. I am not sure why..I can leave it forever ticking away as my adventurer gets hungry and thirsty and tired while it never builds, saying (1) for the ticks, or in a few cases (-1). When I watch these fail to build, they start decreasing as usual, but when they hit 0 they either jump back to 1, or drop down to -1, and then fail. If they stay on 0 for a couple of steps they finish and I can use them...

Workarounds would be super helpful!

Found picking up and dropping items repeatedly fixed some of this nonesense...

but now the built smelter and wood furnace don't have the "TAB" option as a workshop, only the masons shop seems to be a workshop...so I can't do anything anywhere but there...any ideas?
Title: Re: DFHack 0.43.05-r2
Post by: FantasticDorf on October 30, 2017, 09:28:10 am
Would it be possible to move the structures of dwarven conversation topics from adventure mode interactions into fortress mode options forcefully via a script? Dwarves in fortress mode tend to repeat troubles constantly (when you snoop in on conversations) and it doesn't garner any effect unless you go to extreme lengths like Loci did in this experiment (http://www.bay12games.com/dwarves/mantisbt/view.php?id=10315#c36817).

Right now adventure mode options are (-1) (https://github.com/DFHack/df-structures/blob/a8e80088b9cc934da993dc244ece2d0ae14143da/df.advmode.xml#L357) while regular conversations dont appear to have a value (https://github.com/DFHack/df-structures/blob/57e53a575c866903c990db0c4181851fc1a8e20a/df.meeting.xml#L642) but that's just me probably being a complete novice reading community created DF-structure &/or misinterpreting any connection between the two.

Maybe i have poorly understood what is presented infront of me, but if there was any pre-emptive way to fudge dwarves into particular/correct field conversation behaviours so they can resume socialising normally like pre-tavern update that'd be great.
Title: Re: DFHack 0.43.05-r2
Post by: milo christiansen on October 31, 2017, 02:19:37 pm
I just realized I never posted in this thread, so, PTW I guess...
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on November 02, 2017, 01:27:12 pm
Is there a DFHack or script implementation of a naming UI? I'm considering a script that would involve (re)naming of at least regions and rivers, and would rather use something already available than slog through that mess myself.
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on November 02, 2017, 01:54:37 pm
There's obviously Ctrl-Shift-N, but I take you must mean using 'natural' DF multi-part names translatable to the various tongues?

Perhaps one could adopt one of the df native naming viewscreens?
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on November 02, 2017, 05:01:44 pm
I'm talking about changing the entities' names as displayed on the world map pre embark, which means changing the multi part language based names (and I suspect these entities do not have any simple string "name" field to modify anyway). The fallback would indeed be to re-implement some version of the native naming screens, but it's not my favorite wheel to reinvent.
Title: Re: DFHack 0.43.05-r2
Post by: Amostubal on November 02, 2017, 07:46:56 pm
Is there a DFHack or script implementation of a naming UI? I'm considering a script that would involve (re)naming of at least regions and rivers, and would rather use something already available than slog through that mess myself.

I'm talking about changing the entities' names as displayed on the world map pre embark, which means changing the multi part language based names (and I suspect these entities do not have any simple string "name" field to modify anyway). The fallback would indeed be to re-implement some version of the native naming screens, but it's not my favorite wheel to reinvent.

So basically you want to rename map regions that say you have on embark selection map screen?   That would be interesting, not sure if its possible.  i'm sure there has to be some sort of DF structure that is holding the map regions data so you could iterate through it.  Then after that it would only simply be a question of where is the cursor at on the map and locating that DF structure to pass on the new data...  personally I wonder if it would have to be done square by square... or if the region data is some how maintained in a larger structure.  I also am wondering if that structure is even mapped currently in DFHack or if its a bit of the unknown variables that still persist to be to this day.
Title: Re: DFHack 0.43.05-r2
Post by: Fleeting Frames on November 02, 2017, 07:56:20 pm
@PatrikLundall: Not re-implement, but reuse df.viewscreen_layer_choose_language_namest perhaps?
Title: Re: DFHack 0.43.05-r2
Post by: Rose on November 02, 2017, 09:41:11 pm
Amostubal, the region data is almost entirely mapped. There is a global list of regions with all of their data, including names, population, etc.

The biggest question is if it gets saved when you save the game, but that's easy to test, and quite likely, considering that even procedural creature raws can be modified and changes saved.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on November 03, 2017, 03:04:15 am
What I intend to try is to make it possible to edit the world map, and if that is done during world gen (the intended usage), the changes would be saved when the game is saved unless there is a parallel structure somewhere, which doesn't seem likely (even "features" added through DFHacking are saved when the game is saved, even though they have to be images of something stored elsewhere (possibly save game files), as the structure isn't populated until required). As Japa said, the structures are mapped, so that part isn't a problem.

Thanks Fleeting Frames, now I understand what you mean.
Title: Re: DFHack 0.43.05-r2
Post by: Rumrusher on November 04, 2017, 08:46:47 am
Dive into dialog options once more to discover how the top and bottom page listing work and probably be able to make a separate page for custom added dialog.
Took me awhile to realize the game top page choices was asking for the first choice to be selected on the page, while the bottom one ask for the last one to be selected.

also that my open dialog script only inserts the new choice options at pages 0 or 1 so if there say page 6 in the menu scrolling down page 1 would take a while as the page now has all the dialog choice options.
so do go trying to banish someone in the rumor menu unless you like searching for the choice.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on November 04, 2017, 10:20:47 am
Further name related questions:
The raws contain word tables, and I suspect each table is used for the naming of a specific category of things (I didn't find a single region in my world with either a Front or Rear Compound, for instance, while rivers used a wider range of names). Has anyone figured out which table is used for what (The tables I had at indices 35 and 37 seem to match the one used to name a fortress or a group on embark (both seem to use the same set), for instance)?

It also seems the parts sub structure is a reordering of the items found in the fortress naming UI:
0: Front Compound
1: Rear Compound
2: The X
3: First Adjective AND Second Adjective (both seem to use the same table, which makes sense)
4: Hyphen Compound
5: Of Y

Edit: Ignore the question above as the assumption was incorrect. Annoyingly, the only two tables that contain composition of the names of all regions are the same as the ones matching rivers and fortress/group name generation, i.e. tables 35 and 37. Thus, the rules for how to create region and river names are somewhere else. This, of course, assumes my my matching attempt isn't flawed.

Edit 2: Maybe the initial assumption wasn't flawed, after all. I get more matches with the tables at index 1 (rather than 0).
Edit 3: No, the matching tables are far too large to be useful for restricting name generation to what DF produces, most of the seem to be the same as the fortress/group one.
Title: Re: DFHack 0.43.05-r2
Post by: Quietust on November 04, 2017, 03:32:56 pm
I've identified the meanings of most of the language_word_table entries - see my df-structures fork (https://github.com/quietust/df-structures/blob/master/df.language.xml#L273) for a full list.

The first 36 were conclusively identified in version 0.23 (based on where each type of name was generated), and their selection criteria (effectively a set of SELECT_SYMBOL, SUBSELECT_SYMBOL, and CULL_SYMBOL directives) were confirmed to match the current version; the rest were identified just by said criteria, which is why some of them are "unknown".
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on November 04, 2017, 06:50:40 pm
Thanks Quietust, I'll take a closer look at this.

Edit: It's not what I wanted to find, but it's definitely useful to know I'm barking up the wrong tree.
Title: Re: DFHack 0.43.05-r2
Post by: Rose on November 05, 2017, 10:02:13 am
Has anybody reverse engineered what happens in adventure mode when you press a movement key?

Is it possible to cause the adventurer to move only by modifying the structures?
Title: Re: DFHack 0.43.05-r2
Post by: milo christiansen on November 05, 2017, 04:04:06 pm
Well, it may not fit your needs, but I'm pretty sure it is possible to fake input events in-game via Lua.
Title: Re: DFHack 0.43.05-r2
Post by: Rose on November 05, 2017, 07:49:19 pm
That much I know, and that's fine for simple movement, but climbing, for example, has multiple menus to sort through, which means I can't just tell my adventurer to climb north-east in one go.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on November 06, 2017, 06:08:45 am
A DF Structure question: Is it known what the df.world-data.xml:world_region.tree_tile_* fields are used for and the logic for how they're populated?
As far as I can see each biome type present in the region gets one index, but all biomes of the same type in all regions seem to get the same selection of trees in _1 and _2 (with _good, _evil, and _savage have that tree present or not depending on the region's evilness/if that biome within the region has any savage tiles. In both cases the trees actually have to be valid for the region, excluding e.g. mountains and oceans), regardless of whether they're actually present in the selection of plants available in the region or not.
For instance, temperate freshwater marsh gets willow trees in both the _1 and _2 tile despite there being quite a few different trees that grow in such biomes.

I'm both looking for the logic behind how the trees for these fields are selected (to be able to replicate it without simple hard coding, which doesn't fare well in the face of modding or updates), as well as what the fields are used for (if anything: I wouldn't be surprised if they're not actually used).
Title: Re: DFHack 0.43.05-r2
Post by: Rumrusher on November 06, 2017, 06:53:16 am
That much I know, and that's fine for simple movement, but climbing, for example, has multiple menus to sort through, which means I can't just tell my adventurer to climb north-east in one go.
from my dabble into this mess it seems like the whole thing is tied to careful movement options and that seems to have no data in gm-editor.
the my best bet is to see what happens if you could copy and paste different adventure movement options to a table and save them for inputing them back into the ui_advmode's actions list.
Title: Re: DFHack 0.43.05-r2
Post by: Aranador on November 07, 2017, 06:39:40 pm
Is there a DFHack tool that will allow you to 'reroll' your starting seven?

IE - you are looking to make a generational fort, and want an even mix of male/female, but you get to the skill select screen and notice that the game has coughed up 7 females.  Instead of exiting out, and re-entering and selecting your site and doing all the busy work, you could just hit a key and reroll the seven initial dwarves.

Is there such a thing?
Title: Re: DFHack 0.43.05-r2
Post by: mifki on November 07, 2017, 06:49:41 pm
Is there a DFHack tool that will allow you to 'reroll' your starting seven?

IE - you are looking to make a generational fort, and want an even mix of male/female, but you get to the skill select screen and notice that the game has coughed up 7 females.  Instead of exiting out, and re-entering and selecting your site and doing all the busy work, you could just hit a key and reroll the seven initial dwarves.

Is there such a thing?

In DFHack console:

Code: [Select]
lua "dfhack.gui.getCurViewscreen().parent.breakdown_level=df.interface_breakdown_types.NONE  dfhack.gui.getCurViewscreen().breakdown_level=df.interface_breakdown_types.STOPSCREEN"
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on November 14, 2017, 01:44:41 pm
I'm talking about changing the entities' names as displayed on the world map pre embark, which means changing the multi part language based names (and I suspect these entities do not have any simple string "name" field to modify anyway). The fallback would indeed be to re-implement some version of the native naming screens, but it's not my favorite wheel to reinvent.
Feel free to grab anything useful from here: https://github.com/maxthyme/scripts/blob/master/names.lua though I don't see any reason why it wouldn't be possible to make it check for the embark screen > currently displayed region/etc name and use that for the target. I'd try to do it myself but I'm in a woodcrafty mode, not a luahackery mode.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on November 14, 2017, 03:01:06 pm
I'm talking about changing the entities' names as displayed on the world map pre embark, which means changing the multi part language based names (and I suspect these entities do not have any simple string "name" field to modify anyway). The fallback would indeed be to re-implement some version of the native naming screens, but it's not my favorite wheel to reinvent.
Feel free to grab anything useful from here: https://github.com/maxthyme/scripts/blob/master/names.lua though I don't see any reason why it wouldn't be possible to make it check for the embark screen > currently displayed region/etc name and use that for the target. I'd try to do it myself but I'm in a woodcrafty mode, not a luahackery mode.

Thanks for the answer. It looks like the script is your version of a names.lua provided with DFHack, and a further guess is that both of them are intended for adventure mode, as they fail in fortress mode. I'll look at it to see what I can get out of it, although I've worked around my immediate issue by generating random names based on fixed templates without allowing the user to change the name.
And keep on with the wood crafting: it's probably healthier than lua hacking anyway.
Title: Re: DFHack 0.43.05-r2
Post by: Max™ on November 14, 2017, 03:05:48 pm
Hmmm, that one there I thought was fixed from the problems it was having in fort mode.
Title: Re: DFHack 0.43.05-r2
Post by: PatrikLundell on November 15, 2017, 05:57:24 am
@MaxTM: The problem lies at line 59, where the script checks for a screen I assume is an adventure mode one. Replacing the line with "else" brought up the naming UI for a unit in fortress mode. To get it to work properly I assume there should be a check whether the screen is the original one or the one used in fortress mode. I assume fortress mode usage could also make use of units/items selected (i.e.'v' for units) rather than just looked at, but that's just icing.

Anyway, thanks for pointing me in this direction.
Title: Re: DFHack 0.43.05-r2
Post by: Amostubal on November 21, 2017, 11:06:09 am
Okay I have a script that forces the addition of buildings found in a file to an entity using change-build-menu. 

The issue is these buildings have reactions they need to operate and I need to be able to add these reactions also, in other words.

I want this script when enabled to add the buildings and the reactions for these buildings.

Any ideas which commands to do that with in DFHack through Lua?
Title: Re: DFHack 0.43.05-r2
Post by: milo christiansen on November 21, 2017, 02:09:14 pm
You can just add the reactions directly in the entity file... Unless you need go do it later to avoid worldgen issues.

If that is the case, then you will need to edit the correct entity in df.global.world.entities. If the historical entity doesn't have a proper fields (I didn't check, so it may not), then the lists in (*entity_raw).workshops will probably do the trick (found in df.global.world.raws.entities or (*historical_entity).entity_raw)

Be careful! The historical entities (but not the raw entities) are saved! Either way you need to make sure not to add duplicate entries.
Title: Re: DFHack 0.43.05-r2
Post by: Amostubal on November 21, 2017, 03:41:25 pm
You can just add the reactions directly in the entity file... Unless you need go do it later to avoid worldgen issues.

If that is the case, then you will need to edit the correct entity in df.global.world.entities. If the historical entity doesn't have a proper fields (I didn't check, so it may not), then the lists in (*entity_raw).workshops will probably do the trick (found in df.global.world.raws.entities or (*historical_entity).entity_raw)

Be careful! The historical entities (but not the raw entities) are saved! Either way you need to make sure not to add duplicate entries.

yeah I found this in eventful documentation:
Code: [Select]
b=require "plugins.eventful"
b.addReactionToShop("TAN_A_HIDE","LEATHERWORKS")

going to try that when I get to the point of attempting... right now I'm still writting the main body of the script up to adding that in...  and if it all works I'll sennd it over to you Milo, as you may find it an interesting usage of your change-build-menu.
Title: Re: DFHack 0.43.05-r2
Post by: milo christiansen on November 21, 2017, 04:47:26 pm
IIRC, addReactionToShop either didn't work at all, or worked very poorly last time I tried to use it.

Some completely useless info on it not working here. (http://www.bay12forums.com/smf/index.php?topic=150775.msg6389451#msg6389451) Damn, I wish I could remember how and why it didn't work.

Edit: it may have been fixed at some point though, so if it works let me know. Can't have outdated info clogging the mind...
Title: Re: DFHack 0.43.05-r2
Post by: Warmist on November 22, 2017, 01:47:58 am
IIRC, addReactionToShop either didn't work at all, or worked very poorly last time I tried to use it.

Some completely useless info on it not working here. (http://www.bay12forums.com/smf/index.php?topic=150775.msg6389451#msg6389451) Damn, I wish I could remember how and why it didn't work.

Edit: it may have been fixed at some point though, so if it works let me know. Can't have outdated info clogging the mind...
I think addReactionToShop has some limit on shops...
It's only for workshop and furnace. Workshop here is most workshops (?). Easiest way to see is probably add event on onPostSidebar to print a message and just see.

P.S.: looking over the code there is a way to change add other type jobs. Did not try though, because it's setting the default df button to add different job type.  Lua Code here  (https://github.com/warmist/dfhack/blob/develop/plugins/lua/eventful.lua#L68)
Title: Re: DFHack 0.43.05-r2
Post by: milo christiansen on November 22, 2017, 03:31:43 am
Ahh, that jogged some memories loose. I have added hardcoded jobs to workshops a bunch, just not reactions.

The reason I never modified the sidebar button lists to add reactions to workshops where that is possible is simple: It does not play nice with the manager. Not working with the manager is ok for a small number of otherwise critical hardcoded jobs, but it is terrible UX for reactions when you could just add them properly.

In any case, the procedure for adding a reaction to a workshop is simple: Use eventful.postWorkshopFillSidebarMenu, create new button objects, and insert them into df.global.ui_sidebar_menus.workshop_job.choices_all and .choices_visible

Creating buttons is a matter of creating and populating (IIRC) df.interface_button_building_new_jobst objects. Which is what eventful does I think, so...
Title: Re: DFHack 0.43.05-r2
Post by: Amostubal on November 22, 2017, 12:33:52 pm
hmmm Okay I'm half way there.... here's the issue so far... I have the shop added into the entity menus just fine from the change-build-menu thanks Milo.  The AddReactiontoShop  also seems to work... except they are unaccessible, in red, as if they don't have the right reagents, the reactions have 0 reagents so it can't be that.

so... I guess the issue is I need to add the reactions to the entity too? somehow? that was the part I was trying to avoid.  As I want them to appear only when I want them to become available.

But the way I have it working right now is avoiding the AddReactiontoShop all together.
Added the permitted reactions to the entity and the building only through script when I want it to be add it.  I'm going to stick to that, because at least I can restrict the building being available to begin with... I just wont have tiered abilities at the shop that way...  but that's okay,  the current script doesn't need that, and I can think of other ways to do that, that I've done before.
Title: Re: DFHack 0.43.05-r2
Post by: milo christiansen on November 22, 2017, 01:04:18 pm
except they are unaccessible, in red, as if they don't have the right reagents, the reactions have 0 reagents so it can't be that.

Now I remember! That was the problem! I'm pretty sure I never figured out why it did that, so I gave up and worked something else out.

By the way: If you want, it would be fairly easy to write a script that removed reactions from the sidebar list just before it is shown, but after the game populates it. You just use the same method as in my last post, but instead of adding new buttons, you iterate the list and remove the ones you don't want. (The procedure should be similar to what change-build-menu does to remove workshops, just with different lists and greatly simplified due to being able to use eventful to trigger the code).

The only issue is that, last I knew, eventful.postWorkshopFillSidebarMenu did not work for furnaces.
Title: Re: DFHack 0.43.05-r2
Post by: Roses on November 22, 2017, 03:28:27 pm
I think you could have the reaction (and building) present in the entity from the beginning but delete it from the menu everytime the menu is opened up, unless a certain flag is set. That way it would be like "adding" the reaction when a specific criterion is meant, but in actually it would be just not removing it. I planed to do something similar for creating tech trees
Title: Re: DFHack 0.43.05-r2
Post by: Amostubal on November 23, 2017, 05:08:18 am
except they are unaccessible, in red, as if they don't have the right reagents, the reactions have 0 reagents so it can't be that.

Now I remember! That was the problem! I'm pretty sure I never figured out why it did that, so I gave up and worked something else out.

By the way: If you want, it would be fairly easy to write a script that removed reactions from the sidebar list just before it is shown, but after the game populates it. You just use the same method as in my last post, but instead of adding new buttons, you iterate the list and remove the ones you don't want. (The procedure should be similar to what change-build-menu does to remove workshops, just with different lists and greatly simplified due to being able to use eventful to trigger the code).

The only issue is that, last I knew, eventful.postWorkshopFillSidebarMenu did not work for furnaces.
I think you could have the reaction (and building) present in the entity from the beginning but delete it from the menu everytime the menu is opened up, unless a certain flag is set. That way it would be like "adding" the reaction when a specific criterion is meant, but in actually it would be just not removing it. I planed to do something similar for creating tech trees

Basically that's what I did... actually since its a complex script setup; the buildings are added to a abnormal location (MACHINES not WORKSHOP or FURNACES) I just built a quick reader that reads the opening of the raw file for the building list and a few other interesting bits of info.  It also reads the opening to the reaction list which stores a section of info for reaction-triggers and could contain other bits of info later for restrictions.... all of this is done prior to the object token so DF itself ignores it all completely as if its a comment section.  What it allows is the dynamic construction of the reaction triggers and putting the buildings wherever the player wants.  even added in a section for entity control so the first part of the info for each building is the entity allowed the item ie "- MOUNTAIN BUILDING INFO....." means the building will only be added to Dwarfs.  Lastly which I'm not going to bother, I can work out restrictions in similar ways and stop reactions from being accessible, although I totally ignored it this project... since I'm already restricting via not entering the buildings into the entity build menu until the script is turned on.

The smaller project which I'm working on that the whole of the code is based off is named "pipe-dreams" which will be an integrated part of LDF, but will also be standalone launched when I get it completed... probably in a week... even though it wont be ready for the new DF version until the next DFHack is ready.  Its based on some of your scripts Roses, I hope you don't mind.
Title: Re: DFHack 0.43.05-r2
Post by: Roses on November 23, 2017, 03:38:14 pm
except they are unaccessible, in red, as if they don't have the right reagents, the reactions have 0 reagents so it can't be that.

Now I remember! That was the problem! I'm pretty sure I never figured out why it did that, so I gave up and worked something else out.

By the way: If you want, it would be fairly easy to write a script that removed reactions from the sidebar list just before it is shown, but after the game populates it. You just use the same method as in my last post, but instead of adding new buttons, you iterate the list and remove the ones you don't want. (The procedure should be similar to what change-build-menu does to remove workshops, just with different lists and greatly simplified due to being able to use eventful to trigger the code).

The only issue is that, last I knew, eventful.postWorkshopFillSidebarMenu did not work for furnaces.
I think you could have the reaction (and building) present in the entity from the beginning but delete it from the menu everytime the menu is opened up, unless a certain flag is set. That way it would be like "adding" the reaction when a specific criterion is meant, but in actually it would be just not removing it. I planed to do something similar for creating tech trees

Basically that's what I did... actually since its a complex script setup; the buildings are added to a abnormal location (MACHINES not WORKSHOP or FURNACES) I just built a quick reader that reads the opening of the raw file for the building list and a few other interesting bits of info.  It also reads the opening to the reaction list which stores a section of info for reaction-triggers and could contain other bits of info later for restrictions.... all of this is done prior to the object token so DF itself ignores it all completely as if its a comment section.  What it allows is the dynamic construction of the reaction triggers and putting the buildings wherever the player wants.  even added in a section for entity control so the first part of the info for each building is the entity allowed the item ie "- MOUNTAIN BUILDING INFO....." means the building will only be added to Dwarfs.  Lastly which I'm not going to bother, I can work out restrictions in similar ways and stop reactions from being accessible, although I totally ignored it this project... since I'm already restricting via not entering the buildings into the entity build menu until the script is turned on.

The smaller project which I'm working on that the whole of the code is based off is named "pipe-dreams" which will be an integrated part of LDF, but will also be standalone launched when I get it completed... probably in a week... even though it wont be ready for the new DF version until the next DFHack is ready.  Its based on some of your scripts Roses, I hope you don't mind.

Not at all, that's what they are there for
Title: Re: DFHack 0.43.05-r3.1
Post by: lethosor on November 24, 2017, 11:38:28 pm
DFHack 0.43.05-r3 was released yesterday. Unfortunately, all of the packages still contained scripts from r2, so I fixed and repackaged them today and renamed them as "r3.1". DFHack will still report its version as "r3" to make things easier for projects like TWBT, DF-AI, etc., so apologies for any confusion there. Other than that change, the builds are identical.

If you downloaded r3 yesterday, you can just download "new-scripts.zip" or "new-scripts.tar.bz2" from GitHub, extract the "scripts" folder from it, and replace your "hack/scripts" folder with the new scripts folder (that's what I did to make the "r3.1" packages).

Download: https://github.com/DFHack/dfhack/releases/tag/0.43.05-r3
Title: Re: DFHack 0.43.05-r3.1
Post by: Clément on November 26, 2017, 04:10:51 pm
Is there a way to check the current architecture from a lua script? I need that for a fix in devel/export-dt-ini. There is dfhack.getOSType() for the OS, but I need to know if it is win32 or win64.
Title: Re: DFHack 0.43.05-r3.1
Post by: lethosor on November 26, 2017, 05:51:50 pm
dfhack.internal.getArchitecture()
Title: Re: DFHack 0.43.05-r3.1
Post by: Fatace on November 26, 2017, 06:48:42 pm
Any rough estimates on time when DFhack will be available for .44.02+ release soon?
Title: Re: DFHack 0.43.05-r3.1
Post by: lethosor on November 26, 2017, 07:22:40 pm
Probably multiple weeks. I don't actually have a good estimate yet.
Title: Re: DFHack 0.43.05-r3.1
Post by: PatrikLundell on November 27, 2017, 04:55:07 am
Consider a first DFHack release for a new arc in less than a month to be a quick one, so I'd hope for Christmas.
Title: Re: DFHack 0.43.05-r3.1
Post by: Amostubal on November 27, 2017, 07:38:45 am
Probably multiple weeks. I don't actually have a good estimate yet.

Where do you need hands at?  I'm not the greatest at things (more brute force than anything), but I don't mind trying.  I also have a couple of programmer friends on call.  I guess what I'm asking is what needs to be done to get a test DFHack version up and going?
Title: Re: DFHack 0.43.05-r3.1
Post by: Max™ on November 27, 2017, 12:51:54 pm
I'd be looking at it myself but naturally can't, but what is the new stuff in the xml export exactly?
Title: Re: DFHack 0.43.05-r3.1
Post by: lethosor on November 27, 2017, 05:00:22 pm
Where do you need hands at?  I'm not the greatest at things (more brute force than anything), but I don't mind trying.  I also have a couple of programmer friends on call.  I guess what I'm asking is what needs to be done to get a test DFHack version up and going?
We mostly need to verify that structure layouts are right, and fix ones that have changed. It's hard for me to explain exactly what to do there, but if you can compile a bleeding-edge version of DFHack (with up-to-date structures, which might require an extra "git pull" in library/xml), you could poke around at things in the Lua interpreter and point out anything that looks wrong or crashes.

I'd be looking at it myself but naturally can't, but what is the new stuff in the xml export exactly?

Assuming you mean the DF XML export, I'm not that familiar with it, but here's the output of "strings dwarfort.exe | grep '^<.*>'", which grabs all strings starting with a <:
Spoiler (click to show/hide)
Besides things like <SWAP> and <no colors>, those all seem to be XML export-related, and some look new.
Title: Re: DFHack 0.43.05-r3.1
Post by: Moonshine Fox on November 28, 2017, 02:14:51 am
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?
Title: Re: DFHack 0.43.05-r3.1
Post by: Max™ on November 28, 2017, 03:27:58 am
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?
Title: Re: DFHack 0.43.05-r3.1
Post by: PatrikLundell on November 28, 2017, 04:48:29 am
I would have thought you already had a set of basic sanity checking tools for the structures that are mapped?
I'm thinking of something that crawls through df.global depth first and verifies that fields with known bounds are within those, 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.
- The most trivial sanity check would probably be to verify that enum values either have a legal value or -1.
- 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.
- 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.

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.
Title: Re: DFHack 0.43.05-r3.1
Post by: Clément on November 28, 2017, 09:48:53 am
From devel/dt-export-ini.lua:
Code: [Select]
--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?
Title: Re: DFHack 0.43.05-r3.1
Post by: PatrikLundell on November 28, 2017, 09:59:48 am
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.
Title: Re: DFHack 0.43.05-r3.1
Post by: lethosor on November 28, 2017, 11:22:14 am
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 (https://github.com/DFHack/df-structures/blob/master/v0.43.05.lst) 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.
Quote
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)
Quote
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.
Quote
- 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.)
Quote
- 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.
Quote
- 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.

Quote
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:
Code: [Select]
--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)
Title: Re: DFHack 0.43.05-r3.1
Post by: PatrikLundell on November 28, 2017, 11:41:21 am
:
I'm thinking of something that crawls through df.global depth first and verifies that fields with known bounds are within those,
:
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)
The bounds comment intended to refer to the contents of the field, such as an X coordinate being 0 - X_Dim - 1 or -30000. The intended purpose of that kind of checks (as well as those of vectors) would be to flag that the field might no longer be at that location.
 
My poking is done on a Win64 installation (the LNP is the base), correct, and I didn't find it useful to poke in a ported save, so it's a 0.44.02 world, but it's a relevant question, of course. (Note to self: remember to provide all the relevant info).
Title: Re: DFHack 0.43.05-r3.1
Post by: Clément on November 28, 2017, 11:55:11 am
Sounds like you want 2*sizeof(void*), aka 2*dfhack.getArchitecture().
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.
"2*(dfhack.getArchitecture()/8)" more exactly. So, there is no way in the current script API to know where "getType" is in the vtable.
Title: Re: DFHack 0.43.05-r3.1
Post by: Moonshine Fox on November 28, 2017, 12:51:53 pm
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 (https://github.com/DFHack/df-structures/blob/master/v0.43.05.lst) 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.


Thanks! That's exactly what I was looking for.
Title: Re: DFHack 0.43.05-r3.1
Post by: lethosor on November 28, 2017, 01:23:40 pm
"2*(dfhack.getArchitecture()/8)" more exactly. So, there is no way in the current script API to know where "getType" is in the vtable.
Whoops, fixed. You could also use something like df.reinterpret_cast('pointer',1):sizeof(). Apparently df.sizeof('pointer') isn't supported, though.

It doesn't look like it, sorry. I poked around in debug.getmetatable(df.general_ref) and debug.getmetatable(df.general_ref:new()), although the closest thing I could find, "_index_table" in the latter, just has data fields, not methods (and is empty in this case).

Thanks! That's exactly what I was looking for.
If you're talking about the .lst file, it's not always kept up-to-date, unfortunately, but we'll try.

Someone (Japa?) made an SVG chart back in the early 0.40 days that updated periodically - I could perhaps look into doing that again.
Title: Re: DFHack 0.43.05-r3.1
Post by: Max™ on November 28, 2017, 05:26:51 pm
Ohhhh, so the global addresses may be easier to get translated into a symbols table then, it sounded like he was going to do one of the "pass -a flag or some shit and it spits out a table of addresses" suggestions a while ago but I never saw where he went with it.
Title: Re: DFHack 0.43.05-r3.1
Post by: PatrikLundell on November 29, 2017, 07:12:19 am
Another DF structure issue:
There's something off with unit.status.current_soul.performance_skills.

The same save sometimes have the field containing nil, sometimes a value that looks like a legal pointer (and points to data that seems reasonable, with empty vectors), and sometimes contains a suspect pointer value that crashes DF when you try to follow it.
Note that the same dorf can have a pointer in one load of the save, but not the next one (with the save not being updated in the mean time).
Current example: unit personality pointer: 000001B715BA8638 and performance_skills pointer being 00D2090000170612, and, as expected DF went belly up as I tried to follow the pointer.

My save is a win64 0.44.02 generated world (from PSV data) with the raw changes being lowered ATTACK_TRIGGER values for (semi)megabeasts as well as changed siege triggers for the civs. Goblins set to start on glaciers only.

Edit: Concerning the misc_unit_trait mentioned earlier:
- Immediately after embark all 7 had WantsDrink, except for the expedition leader who also had a RoomComplaint.
- Releasing the pause for a few second addeded 3 values to all of them: ClaimClothingCooldown, CleanSelfCooldown, and the reported 63. The expedition leader also added id=21, value=545, so it seems one of the previously unused values has been used (and my guess would be that they probably all have been used, as 63 is a fair bit higher than the previous last value, indicating a need for a fair number of new values).

Edit2: Probably a binding issue of some kind rather than a layout issue: a unit.meeting.state value of 0 is considered to be nil by Lua (gm-editor as well as a home brew script). As far as I see from the XML that should be "SelectNoble". It can be noted that the enum is defined inside the struct element rather than as its own type.

I also remembered that I still failed to describe the world gen conditions, as I'd forgotten that I'd tried to force goblins to start on glaciers (corrected above).

Edit3:
- df.global.world.units.all[].job.mood_skill: Enum out of whack with 4-5 digit values.
- df.global.world.units.all[].body.body_plan.interaction [].interaction.material_breath: Several values of 20, with current max = 19. The one I looked at was a cat and other data indicates it's a licking interaction, and also a head-bump interaction with the same value for the same cat.
- df.global.world.entities.all[].armies[].controller: Following this pointer crashed both gui/gm-editor and my script. The pointer address looked reasonable.
Title: Re: DFHack 0.43.05-r3.1
Post by: Clément on December 02, 2017, 05:01:41 am
Is there any blocker for updating df-structures' symbols.xml with linux versions? Is help needed?
Title: Re: DFHack 0.43.05-r3.1
Post by: lethosor on December 02, 2017, 12:26:03 pm
There weren't Linux builds of DF for a while, so that's behind. You could run devel/dump-offsets and provide the output of that, but I'm not sure what else needs to be done.

Edit: looks like that was done already.
Title: Re: DFHack 0.43.05-r3.1
Post by: Quietust on December 02, 2017, 11:14:18 pm
There's something off with unit.status.current_soul.performance_skills.
The historical_figure_info structure claimed to contain a pointer to unit_personality, when it actually pointed to a structure containing a unit_personality plus an integer, so when that one reported a size mismatch, I updated the original and thus misaligned unit_soul. That should be fixed now.

- df.global.world.units.all[].job.mood_skill: Enum out of whack with 4-5 digit values.
Uninitialized memory - you can ignore that.

- df.global.world.units.all[].body.body_plan.interaction [].interaction.material_breath: Several values of 20, with current max = 19. The one I looked at was a cat and other data indicates it's a licking interaction, and also a head-bump interaction with the same value for the same cat.
The constructor for that class fills in a bogus value.

- df.global.world.entities.all[].armies[].controller: Following this pointer crashed both gui/gm-editor and my script. The pointer address looked reasonable.
Try again with the latest structures - army_controller was badly misaligned before.
Title: Re: DFHack 0.43.05-r3.1
Post by: Clément on December 03, 2017, 05:13:53 am
There weren't Linux builds of DF for a while, so that's behind. You could run devel/dump-offsets and provide the output of that, but I'm not sure what else needs to be done.

Edit: looks like that was done already.

Thanks for the update.

I tried to compile DFHack before I saw it was already updated, and there was a compilation error. I am not sure if it is expected in the current state. I am posting it just in case.

Code: [Select]
/home/clement/projects/DFHack/dfhack/library/modules/Maps.cpp: In function 'const char* DFHack::sa_feature(df::enums::feature_type::feature_type)':
/home/clement/projects/DFHack/dfhack/library/modules/Maps.cpp:94:24: error: 'underworld_from_layer' is not a member of 'df::enums::feature_type'
     case feature_type::underworld_from_layer:
                        ^~~~~~~~~~~~~~~~~~~~~
/home/clement/projects/DFHack/dfhack/library/modules/Maps.cpp:94:24: note: suggested alternative: 'feature_underworld_from_layer'
     case feature_type::underworld_from_layer:
                        ^~~~~~~~~~~~~~~~~~~~~
                        feature_underworld_from_layer
make[2]: *** [library/CMakeFiles/dfhack.dir/build.make:1479: library/CMakeFiles/dfhack.dir/modules/Maps.cpp.o] Error 1
Title: Re: DFHack 0.43.05-r3.1
Post by: PatrikLundell on December 03, 2017, 08:12:52 am
feature_underworld_from_layer was recently changed into underworld_from_layer. This suggests that your df structures sub repo may not be up to date.

However, the changes today to dfhack/develop and df structures/master do not compile for me (I compiled with a freshly pulled df structures/master yesterday without issues). It should be noted that I do not try to compile plugins. I wouldn't be surprised if my poor compatibility with git is the cause, though.
Title: Re: DFHack 0.43.05-r3.1
Post by: Quietust on December 03, 2017, 08:56:57 am
However, the changes today to dfhack/develop and df structures/master do not compile for me (I compiled with a freshly pulled df structures/master yesterday without issues).
From what commit did you try to build? I made a fix last night for unit_personality, and I've confirmed that it builds correctly on both Windows (32-bit and 64-bit) and Linux (via Travis CI). If you're compiling on Windows, be sure to do a clean build, because there's a strange script bug that's preventing partial rebuilds from working correctly.
Title: Re: DFHack 0.43.05-r3.1
Post by: surazal on December 03, 2017, 09:36:56 am
feature_underworld_from_layer was recently changed into underworld_from_layer. This suggests that your df structures sub repo may not be up to date.

However, the changes today to dfhack/develop and df structures/master do not compile for me (I compiled with a freshly pulled df structures/master yesterday without issues). It should be noted that I do not try to compile plugins. I wouldn't be surprised if my poor compatibility with git is the cause, though.

I think running "git submodule update" after doing a pull should resolve this issue (make sure to run a fresh cmake afterwards, just to be on the safe side). I was able to compile my version from the "develop" branch this morning without issues as well. If that doesn't work, you may need to clone a whole new copy of the repository as a last resort.
Title: Re: DFHack 0.43.05-r3.1
Post by: PatrikLundell on December 03, 2017, 10:19:55 am
Thanks Quietust. The "clean" seems to do the trick ("Seems to" as I'm doing a 3 hour world gen, so I think the final error from the install-release script comes from the DLL being in use when trying to copy it. Compilation within VS itself didn't generate any errors, just the usual slew of warnings).

"git submodule update" may very well be what's needed for Clément, but I haven't done it since my df structures sub repo has been detached from the release the download originally pointed to and instead refers to df-structures/master (or none of the df structure changes between DFHack releases can be accessed), so I update that with "git pull".
Title: Re: DFHack 0.43.05-r3.1
Post by: lethosor on December 03, 2017, 10:28:31 am
(or none of the df structure changes between DFHack releases can be accessed), so I update that with "git pull".
The DFHack develop branch should usually point to something more recent in df-structures, although not necessarily the master branch.
Title: Re: DFHack 0.43.05-r3.1
Post by: PatrikLundell on December 03, 2017, 10:35:22 am
(or none of the df structure changes between DFHack releases can be accessed), so I update that with "git pull".
The DFHack develop branch should usually point to something more recent in df-structures, although not necessarily the master branch.
True, of course, but when I started it was still on a 0.43.05 release, and I want to look at the latest changes. It those aren't compatible with the DFHack develop branch I have to wait for it to catch up anyway.

Edit:
Removing performance_skills and controller from the blacklist of my script do not cause any crashes now, i.e. following the pointers works as expected.
Title: Re: DFHack 0.43.05-r3.1
Post by: surazal on December 03, 2017, 01:15:02 pm
From what commit did you try to build? I made a fix last night for unit_personality, and I've confirmed that it builds correctly on both Windows (32-bit and 64-bit) and Linux (via Travis CI). If you're compiling on Windows, be sure to do a clean build, because there's a strange script bug that's preventing partial rebuilds from working correctly.

commit 1489e7db824cc6323de14772fbf0f121ecd0860b

Yes, I did perform a "make clean". When I did "make -j8 install" it rebuilt everything from source again so I know it appeared to have worked.
Title: Re: DFHack 0.43.05-r3.1
Post by: Quietust on December 03, 2017, 02:56:34 pm
From what commit did you try to build? I made a fix last night for unit_personality, and I've confirmed that it builds correctly on both Windows (32-bit and 64-bit) and Linux (via Travis CI). If you're compiling on Windows, be sure to do a clean build, because there's a strange script bug that's preventing partial rebuilds from working correctly.

commit 1489e7db824cc6323de14772fbf0f121ecd0860b

Yes, I did perform a "make clean". When I did "make -j8 install" it rebuilt everything from source again so I know it appeared to have worked.
Good to know that it works for you, but that question was directed specifically at PatrikLundell (who was complaining about build errors with my most recent commits).
Title: Re: DFHack 0.43.05-r3.1
Post by: PatrikLundell on December 03, 2017, 04:21:01 pm
I didn't answer the question as I thought it would no longer be relevant since "clean" worked, so no further trouble shooting was needed (and I still haven't looked up the answer, although I think it was listing of some *.inc files or something like that).
Title: Re: DFHack 0.43.05-r3.1
Post by: Rusty_knight on December 06, 2017, 01:13:19 am
Is it possible to create mineral veins out of layer rock or thin air using DFHack? If so, how?
Title: Re: DFHack 0.43.05-r3.1
Post by: PatrikLundell on December 06, 2017, 04:00:13 am
Yes, manipulation of the geo biome can be performed using the Biome Manipulator http://www.bay12forums.com/smf/index.php?topic=164658.0 (http://www.bay12forums.com/smf/index.php?topic=164658.0) contains geo biome manipulation functionality. Note that this tools has to be used before embarking as it manipulates the data DF uses to generate the embark details.

Creating rock out of thin air should be possible as well, and I think there are tools for that kind of manipulation, as well as morphing single tiles. There's a tool for water/magma manipulation that can also create obsidian.
Title: Re: DFHack 0.43.05-r3.1
Post by: Rusty_knight on December 06, 2017, 04:44:23 am
Note that this tools has to be used before embarking as it manipulates the data DF uses to generate the embark details.
Thanks, but I want to do it post-embark.
Creating rock out of thin air should be possible as well, and I think there are tools for that kind of manipulation, as well as morphing single tiles. There's a tool for water/magma manipulation that can also create obsidian.
Yeah, I know that tiles can be manipulated into rock/obsidian/open space/water/magma. But I'm interested in another kind of manipulation: abundant, dumb layer rock -> mineable ore. I've seen a post somewhere where it was stated that new mineral veins can be injected via DFHack, but it had no details how to do that exactly.
Title: Re: DFHack 0.43.05-r3.1
Post by: Warmist on December 06, 2017, 05:11:43 am
Note that this tools has to be used before embarking as it manipulates the data DF uses to generate the embark details.
Thanks, but I want to do it post-embark.
Creating rock out of thin air should be possible as well, and I think there are tools for that kind of manipulation, as well as morphing single tiles. There's a tool for water/magma manipulation that can also create obsidian.
Yeah, I know that tiles can be manipulated into rock/obsidian/open space/water/magma. But I'm interested in another kind of manipulation: abundant, dumb layer rock -> mineable ore. I've seen a post somewhere where it was stated that new mineral veins can be injected via DFHack, but it had no details how to do that exactly.

Ancient code warning: https://gist.github.com/warmist/11218191 but it should work on any version (?)
Title: Re: DFHack 0.43.05-r3.1
Post by: Rusty_knight on December 06, 2017, 09:56:03 am
Ancient code warning: https://gist.github.com/warmist/11218191 but it should work on any version (?)
I'm not very familiar with understanding scripts yet. What should it do?
Title: Re: DFHack 0.43.05-r3.1
Post by: PatrikLundell on December 06, 2017, 10:33:06 am
I've happened to see a couple of DFHack commands that might be what Rusty_knight wants: changelayer and changevein. You might want to take a look at those (I haven't actually tried to use them).
Title: Re: DFHack 0.43.05-r3.1
Post by: lethosor on December 06, 2017, 10:48:57 am
I think those only work on existing layers/veins, and don't add new ones.

It's worth noting that the 3dveins plugin essentially adds new veins, but takes care to ensure that their distribution roughly matches the existing distribution, so it's probably not that helpful in this case.
Title: Re: DFHack 0.43.05-r3.1
Post by: Rusty_knight on December 06, 2017, 11:27:29 am
I've happened to see a couple of DFHack commands that might be what Rusty_knight wants: changelayer and changevein. You might want to take a look at those (I haven't actually tried to use them).
Problem is these two commands aren't scripts, but plugins. Yes, they have source code, but it's in C++.
Title: Re: DFHack 0.43.05-r3.1
Post by: PatrikLundell on December 06, 2017, 02:13:49 pm
I've happened to see a couple of DFHack commands that might be what Rusty_knight wants: changelayer and changevein. You might want to take a look at those (I haven't actually tried to use them).
Problem is these two commands aren't scripts, but plugins. Yes, they have source code, but it's in C++.
I don't quite understand why plugin/vs script is an issue. If you're using them directly from the console there isn't much of a difference (if any). C(++) isn't that far removed from Lua that it should be impossible to translate the logic if you're trying to understand what it does to make your own code or script, although there are some gotchas, but all the data references are the same (slightly different syntax, but the same paths).
Title: Re: DFHack 0.43.05-r3.1
Post by: Rusty_knight on December 06, 2017, 04:00:25 pm
Got this very crude script working (in the sense that it isnt crashing or throwing errors):
Spoiler (click to show/hide)

It has an unfortunate side effect of regenerating layer stone tiles (with a wrong tile type) alongside with ore, possibly leading to bugs.
Any ideas on how to limit it to regenerating only vein tiles?

I don't quite understand why plugin/vs script is an issue. If you're using them directly from the console there isn't much of a difference (if any). C(++) isn't that far removed from Lua that it should be impossible to translate the logic if you're trying to understand what it does to make your own code or script, although there are some gotchas, but all the data references are the same (slightly different syntax, but the same paths).
Me knowing syntax of neither C++ nor LUA is an issue. And not knowing inner workings of dfhack & the game too.
Title: Re: DFHack 0.43.05-r3.1
Post by: PatrikLundell on December 06, 2017, 04:49:33 pm
Not having dealt much with tile properties, I can't be sure, but it looks to me that the script checks if the tile is any mineral, rather than the mineral you're after. Thus, the innermost loop of refill_tile should probably check if the mineral that was in that tile is the one you want to restore and do nothing otherwise.
And yes, I guess two unfamiliar syntaxes confuses things more than one does.
Title: Re: DFHack 0.43.05-r3.1
Post by: Kruniac on December 06, 2017, 08:39:19 pm
Update this for the latest version.
Title: Re: DFHack 0.43.05-r3.1
Post by: lethosor on December 06, 2017, 10:59:42 pm
Update this for the latest version.
Are you talking about 0.44.02? If so, that's not the way to go about asking that. We've been working on it fairly regularly since 0.44 came out. It's not an instantaneous process.
Title: Re: DFHack 0.43.05-r3.1
Post by: PatrikLundell on December 07, 2017, 03:47:42 am
Update this for the latest version.
As lethosor said, they're working their butts off to update DFHack, but it's quite a lot of work (the pay is lousy, and abuse is poor sustenance). If you meant creation of a new thread I would expect that to happen when a somewhat stable DFHack becomes available.
Title: Re: DFHack 0.43.05-r3.1
Post by: Rusty_knight on December 07, 2017, 05:06:59 am
Regenvein v0.1c - added rudimentary check for tile types applicable to conversion.
!May cause pathfinding problems!
Spoiler (click to show/hide)
Title: Re: DFHack 0.43.05-r3.1
Post by: Kruniac on December 07, 2017, 07:14:09 am
Update this for the latest version.
As lethosor said, they're working their butts off to update DFHack, but it's quite a lot of work (the pay is lousy, and abuse is poor sustenance). If you meant creation of a new thread I would expect that to happen when a somewhat stable DFHack becomes available.

Yeah, I couldn't maintain this kind of software, I know that. Far too complex and far too little gained.

I just want my soundsense plugin working again.
Title: Re: DFHack 0.43.05-r3.1
Post by: zakarum on December 07, 2017, 10:25:42 am
Then wait Kruniac. It's already a free job, what they are doing. Have some patience. Go play something else in the meantime.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 07, 2017, 05:56:46 pm
Here's a prerelease for 0.44.02: https://github.com/DFHack/dfhack/releases/tag/0.44.02-alpha1

I haven't gotten it to crash, but I also haven't tested very many tools either, so please report any issues you find.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Montieth on December 07, 2017, 07:21:05 pm
I've been doing other things for the past week, occasionally looking at the Bay12 forums to see if it's good.

Thank you terribly for the work you do on DF-Hack.

Downloading now and if I see anything that I think may be useful for you I'll report back.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Rekov on December 07, 2017, 09:54:28 pm
Well it's not a default script, but biome manipulator threw me an error.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 07, 2017, 11:45:58 pm
What exactly is the error? Text would be preferable if you can copy it (right click the title bar on Windows). I don't know if it's due to something we changed or not, but either way, posting that in the biome manipulator thread might be better.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Rekov on December 08, 2017, 12:09:54 am
Here's what I got. I'll post it in the other thread too.

Code: [Select]
...Dwarf Fortress 0.44.02/hack/scripts/biomemanipulator.lua:250: decompose fails to match 'r' in 0.44.02-alpha1
stack traceback:
        [C]: in function 'error'
        ...Dwarf Fortress 0.44.02/hack/scripts/biomemanipulator.lua:250: in global 'decomposeDFHackReleaseNumber'
        ...Dwarf Fortress 0.44.02/hack/scripts/biomemanipulator.lua:270: in global 'isDFHackOlderThan'
        ...Dwarf Fortress 0.44.02/hack/scripts/biomemanipulator.lua:3238: in global 'Make_Profile'
        ...Dwarf Fortress 0.44.02/hack/scripts/biomemanipulator.lua:4862: in local 'fun'
        ...sktop\DFSTUF~1\Dwarf Fortress 0.44.02\hack\lua\class.lua:98: in upvalue 'invoke_after_rec'
        ...sktop\DFSTUF~1\Dwarf Fortress 0.44.02\hack\lua\class.lua:127: in global 'BiomeManipulatorUi'
        ...Dwarf Fortress 0.44.02/hack/scripts/biomemanipulator.lua:9303: in global 'Show_Viewer'
        ...Dwarf Fortress 0.44.02/hack/scripts/biomemanipulator.lua:9310: in global 'biomemanipulator'
        ...Dwarf Fortress 0.44.02/hack/scripts/biomemanipulator.lua:9313: in local 'script_code'
        ...ktop\DFSTUF~1\Dwarf Fortress 0.44.02\hack\lua\dfhack.lua:562: in function 'dfhack.run_script_with_env'
        (...tail calls...)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 08, 2017, 01:09:12 am
Oh, it looks like the "alpha" in the version name is confusing it. That (part of the) script might be new enough that it hasn't had to deal with prerelease versions before. Some sort of version comparison thing might be useful to have in the DFHack core eventually.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Max™ on December 08, 2017, 03:11:42 am
Well shit that was a lot faster than I was expecting, I take it the changes helped speed it up after all?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: PatrikLundell on December 08, 2017, 05:01:32 am
Biome Manipulator needs to be updated because (at least) there are name changes in used structures. The error reported is just the first one (and I hadn't anticipated the possibility of an "alpha" in the pattern), and as lethosor correctly assumes, the script hasn't existed long enough for alphas to be encountered. The script will be updated shortly (but I think issues with scripts not part of the DFHack distribution should be reported in their threads only, as lethosor said).

Anyway, yes, DFHack (although alpha) appeared a lot faster than expected.

Edit: Biome Manipulator updated.
A DFHack version comparison in the core would be nice, although I've mostly moved away from that to let the script directly detect if the structure conforms to the new pattern and use that as a basis, rather than the indirect release version measurement. I assume there are other reasons for wanting to compare versions, though.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Manzeenan on December 08, 2017, 01:08:34 pm
uhh not sure where to put this but got an indication from DFHack that a dwarf was stuck in a tree, dwarf immediately got down from tree, using alpha prerelease 1
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: PatrikLundell on December 08, 2017, 04:28:40 pm
uhh not sure where to put this but got an indication from DFHack that a dwarf was stuck in a tree, dwarf immediately got down from tree, using alpha prerelease 1
That should probably be put on the altar of fixed bugs, as the stuck-in-trees bug should be one of those fixed with 0.44.01 so the DFHack detector might be redundant (or not, since I there was a post about it still happening).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Bumber on December 08, 2017, 05:20:58 pm
Using gui/liquids, a permaflow that is flowing downwards is labeled "inv_8". It is "inv_9" if flowing off the east edge of the map. Haven't tested others.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: nicfer on December 08, 2017, 05:57:14 pm
I've installed DFHack 0.44.02-alpha1 to check the 'startdwarf' mod, and it isn't working. It throws an error about missing memory addresses or something. I tried to look for the new address with Cheat Engine, but it's very hard for values that (almost) don't change.

Any advices, other than waiting for a new version?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Rafal99 on December 08, 2017, 06:44:56 pm
I have written a small lua script that wakes up selected sleeping dwarf.
(it is mostly based on siren script but kinda simpler and more verbose)

What is the procedure to have it included in DFHack?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 08, 2017, 06:47:44 pm
uhh not sure where to put this but got an indication from DFHack that a dwarf was stuck in a tree, dwarf immediately got down from tree, using alpha prerelease 1
Sounds like Toady's fix is working, then. I'll take out that script from the default config, at least.

I've installed DFHack 0.44.02-alpha1 to check the 'startdwarf' mod, and it isn't working. It throws an error about missing memory addresses or something. I tried to look for the new address with Cheat Engine, but it's very hard for values that (almost) don't change.

Any advices, other than waiting for a new version?
That address is tricky to find because it isn't a global. It hasn't been a priority historically either, but I'll see if I can get the script to find it to work.

I have written a small lua script that wakes up selected sleeping dwarf.
(it is mostly based on siren script but kinda simpler and more verbose)

What is the procedure to have it included in DFHack?
Post it here or make a pull request in https://github.com/dfhack/scripts (if you know how) and we'll take a look. I'm wondering if it would be better as an option in "siren" instead of a separate script, but either way, having that would be useful.

Using gui/liquids, a permaflow that is flowing downwards is labeled "inv_8". It is "inv_9" if flowing off the east edge of the map. Haven't tested others.
Naturally-occurring or created with DFHack?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Putnam on December 08, 2017, 07:45:54 pm
yo, here's a script that lets you add custom artifacts (https://gist.github.com/Putnam3145/2d1609e935f91f2e50371c9787914b6b). It uses anon entries, so it's for testing only at this point, no way am I releasing anything with this until the artifact_record is mapped out better. Assumptions in writing are here (https://github.com/DFHack/df-structures/issues/226); for the most part, it works perfectly. Artifacts can be recovered from sites as expected.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Manzeenan on December 08, 2017, 07:57:10 pm
uhh not sure where to put this but got an indication from DFHack that a dwarf was stuck in a tree, dwarf immediately got down from tree, using alpha prerelease 1
Sounds like Toady's fix is working, then. I'll take out that script from the default config, at least.
Well... they keep gathering fruits that dont exactly exist, nothing harvested they just climb around the tree till theyre done and continue gathering on the ground empty handed kinda odd but no one is starving in a tree yet

Edit: ill keep an eye out and note change
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Bumber on December 09, 2017, 01:21:40 am
Using gui/liquids, a permaflow that is flowing downwards is labeled "inv_8". It is "inv_9" if flowing off the east edge of the map. Haven't tested others.
Naturally-occurring or created with DFHack?
Naturally-occurring, in a save untouched by DFHack.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Rafal99 on December 09, 2017, 08:53:51 am
I have written a small lua script that wakes up selected sleeping dwarf.
(it is mostly based on siren script but kinda simpler and more verbose)

What is the procedure to have it included in DFHack?
Post it here or make a pull request in https://github.com/dfhack/scripts (if you know how) and we'll take a look. I'm wondering if it would be better as an option in "siren" instead of a separate script, but either way, having that would be useful.

Ok. I will make a PR after I do some more extensive testing.
As for extending siren, siren already uses all its parameters for burrow names so it is not so simple, and also has extra logic for stopping breaks, parties etc. which I didn't want. Also siren has different theme and inflicted thoughts, meant to be used as a global alarm during a siege, while my script is about dwarf having "nightmares" because he sleeps at wrong place and time. :P
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Rusty_knight on December 09, 2017, 02:00:38 pm
What is the purpose of "rube-autogen-win.rb" script and how can I run it?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 09, 2017, 02:28:38 pm
What is the purpose of "rube-autogen-win.rb" script and how can I run it?
It's not something you can run directly, which is why it isn't in the scripts folder. It's auto-generated Ruby code (for Windows, in this case) that deals with DF structures somehow.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: YetAnotherLurker on December 10, 2017, 01:42:23 am
I'm getting an immediate crash when attempting to rename a region folder. Not exactly a major problem, but just so you know. Windows 64-bit 44.02a1.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Max™ on December 10, 2017, 01:54:56 am
yo, here's a script that lets you add custom artifacts (https://gist.github.com/Putnam3145/2d1609e935f91f2e50371c9787914b6b). It uses anon entries, so it's for testing only at this point, no way am I releasing anything with this until the artifact_record is mapped out better. Assumptions in writing are here (https://github.com/DFHack/df-structures/issues/226); for the most part, it works perfectly. Artifacts can be recovered from sites as expected.
Nice, I was just thinking about wondering if this could be done way back when I started fucking around with artifake.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 10, 2017, 02:00:23 am
I'm getting an immediate crash when attempting to rename a region folder. Not exactly a major problem, but just so you know. Windows 64-bit 44.02a1.
How/where exactly are you renaming it?

Edit: if you mean in the "start playing" menu, I found and fixed the issue there.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: YetAnotherLurker on December 10, 2017, 02:33:52 am
Edit: if you mean in the "start playing" menu, I found and fixed the issue there.
Yeah, that's the one.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Rusty_knight on December 10, 2017, 02:41:57 am
Is there a way to start another script from within currently running script?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Putnam on December 10, 2017, 03:04:54 am
dfhack.run_script
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Rusty_knight on December 10, 2017, 03:41:42 am
dfhack.run_script

Script to gm-edit map block under cursor, now with a cursor check!
Spoiler (click to show/hide)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Max™ on December 10, 2017, 05:57:34 am
Well hell that's kinda interesting, though now I wonder if it would be possible to add that in as a my_trg while you've got the actual tile name highlighted instead of the objects/units that might be present...
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Vitellus on December 11, 2017, 10:08:33 am
Thanks for the release! Keep up the hard work!
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: jaked122 on December 11, 2017, 06:15:09 pm
Wow already out for the new build? That's incredible.

Did Toady end up giving the project some information to make it easier?

I thought he was talking about that stuff a while back.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: martinuzz on December 11, 2017, 07:36:28 pm
Can I install (replace the DLL) DFHack while DF is running? I want to save two dwarves that got bugged into a water reservoir with a teleport, but obviously can't exit the game.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: mifki on December 11, 2017, 08:02:43 pm
Can I install (replace the DLL) DFHack while DF is running? I want to save two dwarves that got bugged into a water reservoir with a teleport, but obviously can't exit the game.

No, even if you could replace, it wouldn't work.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 11, 2017, 08:03:33 pm
Wow already out for the new build? That's incredible.

Did Toady end up giving the project some information to make it easier?

I thought he was talking about that stuff a while back.
Yeah, we have all of the global addresses now, which helps some.

Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Max™ on December 11, 2017, 09:46:40 pm
I mean, I know there is a fuckton of other work, but over the last few years I've played it's pretty much the search for the last few globals that wound up holding back a release the longest. It helps make the rest of the process much faster for sure.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: PatrikLundell on December 12, 2017, 04:59:17 am
Can I install (replace the DLL) DFHack while DF is running? I want to save two dwarves that got bugged into a water reservoir with a teleport, but obviously can't exit the game.
Why don't you simply save, exit DF, install DFHack, restore the save, and THEN teleport? You can even copy your existing save before saving anew to keep (sort of) a backup.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Findulidas on December 12, 2017, 03:49:04 pm
Windows antivirus says createitem is a trojan in the latest dfhack alpha included in per. starter pack. False positive?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 12, 2017, 04:29:11 pm
That's only the second report I've seen of that, unless you're the same person who posted about it on Reddit. I uploaded that file to VirusTotal and it reported (https://www.virustotal.com/#/file-analysis/MzYwNDAzMGM0MzUyYzIzMGNjMTIwODFjNTYzYTk0NzM6MTUxMzExMzg4MQ==) that 0 of 63 AV programs flagged it. It's most likely a false positive - some AV software randomly flags things it hasn't seen before.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Killermartian on December 13, 2017, 02:28:12 am
Haven't checked if anyone has mentioned this already, but if i get a companion in adventure mode and travel, immediate crash. It works when i disable dfhack though. Also crashes when i (Z), even without a companion.

EDIT: I'm not sure how to give a crash log
EDIT2: Seems to work better without a tile set
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: mifki on December 13, 2017, 02:28:52 pm
Haven't checked if anyone has mentioned this already, but if i get a companion in adventure mode and travel, immediate crash. It works when i disable dfhack though. Also crashes when i (Z), even without a companion.

EDIT: I'm not sure how to give a crash log
EDIT2: Seems to work better without a tile set

There was a bug in TWBT related to fast travel, I either didn't fully fix it or something has changed, anyway I see what's happening now, hopefully I'll fix it this time.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Amostubal on December 13, 2017, 08:52:53 pm
Windows antivirus says createitem is a trojan in the latest dfhack alpha included in per. starter pack. False positive?

I just confirmed Windows Defender antivirus that comes with windows 10 current registers it as a virus, instantly quarrantine and removes it.... rather annoyingly actually I had to dig around the system to see what it did with it.  tries to claim its Trojan:Win32/Azden.A!cl
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Amostubal on December 14, 2017, 10:41:51 am
So I went one step further, I contacted microsoft, uploaded the file, and got an answer back this morning.  interestingly enough they updated thier definitions around the same time I got the response. 

(https://image.prntscr.com/image/GY6lUUj_ROimoEpYwJmLfg.png)

Not that I doubted anyone... but sometimes you got to make microsoft look at it, to fix the problem.

Oh and so I reset the defender's catches this morning restarted dwarf fortress and no more virus detection.  So anyone who is still getting this error... update your virus definitions and it should stop.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Rumrusher on December 14, 2017, 04:20:22 pm
(http://www.truimagz.com/host/rumrusher/folder4/new-way-to-recruit-migrants.gif)
well send one goblin out on a raid, goblin returns with a huge party of random companions
welcome to a new dumb script for fort mode. so now you could probably go on snatcher raids now.
Code: ("Recruit.lua") [Select]
for de,oe in pairs(df.global.world.army_controllers.all) do
if oe.unk_60 == nil then else
print ( de,oe.unk_60.anon_6)
for e,o in pairs(df.global.world.armies.all) do
if oe.id == o.controller_id then
print (e)
df.global.world.armies.all[e].members:insert("#",{new=true,nemesis_id=df.global.world.nemesis.all[math.random(1,999)].id}) -- this is the part that inserts a unit to the army
end
end
end
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Putnam on December 14, 2017, 04:39:40 pm
uh, doesn't that more just kinda... randomly insert some nemesis records

also:

1. you should be using dfhack.random.new():random(#df.global.world.nemesis.all) instead of math.random(1,999), since nemesis.all is a C++ vector and therefore 0-indexed and also this will pick from every nemesis unit instead of just the first 999
2. you should probably be doing some stuff to check if the nemesis record is for a valid (i.e. not dead) hist fig anyway, probably by going through the nemesis records before you go through all the armies and putting them into a new table
3. is there not an army id in army controllers? you could just use df.army.find(id) instead of making this whole thing O(n2)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Rumrusher on December 14, 2017, 07:34:53 pm
uh, doesn't that more just kinda... randomly insert some nemesis records

also:

1. you should be using dfhack.random.new():random(#df.global.world.nemesis.all) instead of math.random(1,999), since nemesis.all is a C++ vector and therefore 0-indexed and also this will pick from every nemesis unit instead of just the first 999
2. you should probably be doing some stuff to check if the nemesis record is for a valid (i.e. not dead) hist fig anyway, probably by going through the nemesis records before you go through all the armies and putting them into a new table
3. is there not an army id in army controllers? you could just use df.army.find(id) instead of making this whole thing O(n2)

1. it was mostly a proof of concept that I didnt really find a "random number generator coding" like you posted I probably could use that
2. considering if a historical figure from a nemesis record ended up dead wouldn't really mind as this opens up to pretty much any pull. overall the script is inserting a nemesis unit to an army so they can visit your fort.
3. would had skip army controllers but had a issue trying to write a script that would find said army with no descriptors. it only took realizing army controllers have a section that writes up the mission report and that was the only way to tell one army apart from another.

so far it has room for improvement.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Acolyte on December 14, 2017, 10:26:56 pm
Errant thought - I seem to be having a lot of those these days - right now when you slaughter an animal it triggers a butchering job automatically, would DFHack be able to have contaminants trigger a Cleaning job?

Just a thought.
   - Shane
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: mifki on December 15, 2017, 05:54:18 am
Haven't checked if anyone has mentioned this already, but if i get a companion in adventure mode and travel, immediate crash. It works when i disable dfhack though. Also crashes when i (Z), even without a companion.

EDIT: I'm not sure how to give a crash log
EDIT2: Seems to work better without a tile set

There was a bug in TWBT related to fast travel, I either didn't fully fix it or something has changed, anyway I see what's happening now, hopefully I'll fix it this time.

Try version 6.25
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: strainer on December 15, 2017, 03:14:50 pm
Hi. I would like to share dfhacks manipulator.cpp extended with the following features:

An extra tab mode reveals units physical and mental attributes in a compact grid which is highlighted to improve readability. Coloring shows strong and weak attributes and also shows which particular attributes are exercised by the currently focused job & unit.

(https://i.imgur.com/n01XCwB.png)

The labor activation grid can also be color hinted to reveal best and worst performing roles for each unit. This aptitude coloring can demystify labor assignment and even for seasoned dwarf therapists could provide an intresting alternative account of the assigned labors.

(https://i.imgur.com/eSAex6s.png)

The aptitude ratings numeric scores (0~200) are also displayed along side the existing skill and experience rating fields.

There are 9 theme options in total: legacy b&w, 4 tinted monocrome modes, and 4 degrees of aptitude hinting to choose from. The theme is cycled with a hotkey and setting is saved with the game and carrys to new games in the current session.


Sorting is developed with simpler controls, subtle tweaks and highlighting of "group sorts" and with extra sorts by scores calculated of civil, performer, scholar, academic and martial skills and aptitudes.

Here is arrival groups subsorted by martial,

(https://i.imgur.com/TnC9NlS.png)


An extra tab mode calculates and reveals 'notices' which are strings of tips generated from various unit flags such as: DngrTrrn, RqRescue, RqDoctor, Trappd, Intoxcd. The notices are not exhaustive but are suprisingly informative for ongoing situations and tracking recovery.

Here they are recounting the death throws of the fallen:

(https://i.imgur.com/8ESy5qV.png)


Other tweaks include, persistent selection and focus to alleviate the impact of acidental exit, and pet nicknaming is handy for selection of sturdiest work animals.


Some of the added code is substantial and some maybe too crafty but I think it is fairly well encapsulated and serviceable. The current version has been quite thoroughly playtested on Debian df v43.

I hope the dfhack project can find time to try this and hopefully pass these features on to other players, there is an open pull request at the repo.


Here is a mode like 'matrix blue pill' (Its just the blue highlight-set applied to all).

(https://i.imgur.com/BBnOGkA.png)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Rumrusher on December 15, 2017, 05:51:45 pm
didn't know ghosts and probably undead can be assign to squads via dfhack.
and didn't realize you can then send them on raids which might end up causing them to poof from the squad list.
so one could tell a bunch of ghosts to raid someone elses site and they probably leave you alone... forever or until the mission completes itself
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Max™ on December 16, 2017, 08:58:50 am
I've noticed when I poof a mummy out of a tomb it doesn't disappear, it just ends up elsewhere on the world map, so I'm pretty sure you're on your way to starting a random ghostpocalypse or something.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Rumrusher on December 16, 2017, 10:32:15 pm
so it possible to cast interactions on a ghost, and transform a ghost which heals all their missing limbs back.
so I wonder if I could just make a bunch of archery items then make a ghost archer squad.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: scourge728 on December 17, 2017, 08:44:16 am
So how exactly does one assign a ghost to a sqaud? Do they show up, or do you have to do something special?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Rumrusher on December 17, 2017, 03:25:27 pm
So how exactly does one assign a ghost to a sqaud? Do they show up, or do you have to do something special?
how I did it was finding the military menu's squad position section then filling out one of the ten options with a historical id of the dead unit that turn into a ghost.
automating this probably going to take a while given I need to find where does gm-editor scr on the military screen would send you, so one could do a proper insert.
the ghost seems to fly about and blink out of existence often when following them.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Acolyte on December 18, 2017, 06:31:21 am
Is there a script that'll tell me how many "sutures worth" in a partially used thread? I just had to do some quick n dirty setting up of a temporary hospital (Damn Giant Keas!) and after the suturing my dwarves helpfully put the thread back in with all the other thread.

Anyway, looking for a way to separate them out to put the partials into my proper hospital.

Thanks!
   - Shane
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: CaptainArchmage on December 18, 2017, 09:45:55 am
I got two little questions about DFHack, regarding a succession world that seems to have been going for about 50 years cumulative so far since the 0.43.05. The save works for the new version.

1) Is it possible to use DFhack in the ability to build new buildings for existing civilisations, so we can for example build pedestals and display cases?

2) Is it possible to use DFhack to change the mineral composition of an existing world in the new version?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: PatrikLundell on December 18, 2017, 11:11:16 am
I got two little questions about DFHack, regarding a succession world that seems to have been going for about 50 years cumulative so far since the 0.43.05. The save works for the new version.

1) Is it possible to use DFhack in the ability to build new buildings for existing civilisations, so we can for example build pedestals and display cases?

2) Is it possible to use DFhack to change the mineral composition of an existing world in the new version?
1. I believe someone has hacked in step ladders into a succession fortress and thought about doing a similar operation for pedestals (etc.), but I would guess that kind of surgery requires raw hacking, and so would better be asked about in the mod forum (where there's a greater chance of getting answers from people who know about such things).
2. If you take about hacking an existing fortress, the answer is most probably yes (there was a similar question recently), but you'd probably have to create the script for what you want yourself (or change one tile at a time using scripts that probably exist).
If you talk about changing the world pre embark (or in between embarks) the answer is yes: http://www.bay12forums.com/smf/index.php?topic=164658.0 (http://www.bay12forums.com/smf/index.php?topic=164658.0).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Roses on December 18, 2017, 12:55:49 pm
I am wondering if anyone has done any research on the flags in action.data.attack.flags? I know there are some already marked (e.g. precise, charge, etc...), but there are other flags in there that sometimes get set as true. The real reason I am wondering is because I am trying to create a script that allows a unit to attack another unit from multiple tiles away. My current attack script creates an attack action with everything needed for a proper attack, but it will obviously miss if the target is more than a tile away. Now I have been working on a work-around that involves replicating wounds and such, but it's rather buggy and would prefer something more concrete.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: CaptainArchmage on December 18, 2017, 02:12:32 pm
I got two little questions about DFHack, regarding a succession world that seems to have been going for about 50 years cumulative so far since the 0.43.05. The save works for the new version.

1) Is it possible to use DFhack in the ability to build new buildings for existing civilisations, so we can for example build pedestals and display cases?

2) Is it possible to use DFhack to change the mineral composition of an existing world in the new version?
1. I believe someone has hacked in step ladders into a succession fortress and thought about doing a similar operation for pedestals (etc.), but I would guess that kind of surgery requires raw hacking, and so would better be asked about in the mod forum (where there's a greater chance of getting answers from people who know about such things).
2. If you take about hacking an existing fortress, the answer is most probably yes (there was a similar question recently), but you'd probably have to create the script for what you want yourself (or change one tile at a time using scripts that probably exist).
If you talk about changing the world pre embark (or in between embarks) the answer is yes: http://www.bay12forums.com/smf/index.php?topic=164658.0 (http://www.bay12forums.com/smf/index.php?topic=164658.0).

Thank you, with regards to 2. will look into changing the pre-embark or between embark world (which we currently have).

With regards to 1. I believe the fortress was standard, so I can just replace the "old raws" with the "new raws". However, the entity file is used for worldgen and that means the items available get stored in the game format, and not entities. That means I will have to hack in display cases and pedestals.

Edit: It would require me to edit the entities existing in the game so they have more items available to them, and have more animals available to them too. At least. Not sure if a script exists for that yet.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Montieth on December 21, 2017, 03:14:56 am
Been playing for nearly a week off and on (gotta burn the last of the vacation days).

Found an issue I think.

when trying to select uniforms for specific members of the squad, something in DFHack is taking the right most list of uniforms away. If you just work with the Squad leader, it lets you scroll down. But scroll down to the next member in the squad and the right most uniform selector goes away. More over, when you try to specifically assign a special weapon or armor component to a squad member, even the leader, the Special Selection screen does not appear.


MacOS 10.11.6
LazyMacPAck v.044.02- Alpha A.64 with dfhack-0.44.02-alpha1-OSX-64-gcc-4.8.5
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 21, 2017, 10:03:07 am
That's probably another case of https://github.com/DFHack/dfhack/issues/1199, which should be fixed in the next release, but thanks for the report! Make sure to double-check that it is fixed once that comes out.

Just curious, are you seeing the search option when this is happening?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Montieth on December 21, 2017, 03:23:11 pm
When the right most weapon selection menu is visible the Q: Search addition is present. But when you step down the middle menu to the next Dwarf Soldier, both the right menu and the Q:Search menu disappear.

When using the Uniform Selection Menu at right (3rd column) there is no Q:Search option.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Kat on December 21, 2017, 05:05:45 pm
Hi, I have a little question/request.

Can DFHack tell me what the names of my civilisations deities are ? or can it do that in future ?

I'm building a bunch of temples. My civ has 12 deities. I want to build a statue of each deity.

But, instead of writing it all down on paper, I'd like to be able to see my civ's deities in the DFHack window, so I can look at it while I'm specifying statue designs.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 21, 2017, 05:17:12 pm
It's probably possible to do now, although there isn't a script that does that that I know of. What exactly do you mean by a "civilization's deities"? I'm not seeing a direct link to deities from historical entities/civs, but I'll investigate.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: PatrikLundell on December 21, 2017, 05:37:37 pm
Hi, I have a little question/request.

Can DFHack tell me what the names of my civilisations deities are ? or can it do that in future ?

I'm building a bunch of temples. My civ has 12 deities. I want to build a statue of each deity.

But, instead of writing it all down on paper, I'd like to be able to see my civ's deities in the DFHack window, so I can look at it while I'm specifying statue designs.
A follow on question to lethosor's:
Do you actually want the deities associated with your civ (I haven't found any direct links either, by the way), or do you want the ones your citizens (and possibly residents) worship (or possibly both)?
The civ list is probably static for the purpose of a fortress, while the citizen/resident one would grow over time as you acquire people who originate from other civs.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Kat on December 21, 2017, 05:48:05 pm
It's probably possible to do now, although there isn't a script that does that that I know of. What exactly do you mean by a "civilization's deities"? I'm not seeing a direct link to deities from historical entities/civs, but I'll investigate.
A follow on question to lethosor's:
Do you actually want the deities associated with your civ (I haven't found any direct links either, by the way), or do you want the ones your citizens (and possibly residents) worship (or possibly both)?
The civ list is probably static for the purpose of a fortress, while the citizen/resident one would grow over time as you acquire people who originate from other civs.

I mean, when I create a temple zone, I can choose to dedicate it to any of the deities that my citizens worship.

but I'd like to be able to see that list of the deities my citizens worship, somewhere, so that I can look at it in the dfhack window, while specifying images for my craftsmen/sculptors to create.

and yeah, I'd forgotten that immigrants from other civs might have other deities.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 21, 2017, 06:35:39 pm
I mean, when I create a temple zone, I can choose to dedicate it to any of the deities that my citizens worship.

but I'd like to be able to see that list of the deities my citizens worship, somewhere, so that I can look at it in the dfhack window, while specifying images for my craftsmen/sculptors to create.
Oh, is that where that list comes from? I was trying to figure it out - in one world, it also happened to be all of the dwarven deities, but not in another world.
If you're only interested in the contents of the list, I can pretty easily provide something to print all the entries in that list when it's open (I was doing that anyway to test).

Edit: I'm seeing 12 deities listed in a fort with 7 citizens, and each citizen only worships one deity (with some overlap), so the list is coming from somewhere else.

Here are a couple one-line commands you can copy and paste into the DFHack console (you have to include the colon in ":lua").
For dwarven names:
Code: [Select]
:lua for _,d in pairs(ui_sidebar_menus.location.deities) do if d then print(dfhack.df2console(dfhack.TranslateName(d.name))) end end
English names: (note that I just added "true" as a second parameter to TranslateName)
Code: [Select]
:lua for _,d in pairs(ui_sidebar_menus.location.deities) do if d then print(dfhack.df2console(dfhack.TranslateName(d.name,true))) end end
Note that you need to have the temple deity selection menu open for these to work. The second (English) one seems to match the text displayed in that list, although I don't know if it matches the slab creation list, so I provided both.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Rumrusher on December 21, 2017, 06:38:25 pm
so slowly working on a add to military script for enlisting guests to your army so you can send them on raids.
ended up filling the entire squad with the same person, over all ironing out the recruit script so it possible that those you recruited are added to the squad so you dont end up with random folks in your fort and be able to put them to use... in defending, the lack of labors is another problem.

once this is done, now to see if I can figure out the retrieval of an item so it possible to send folks out to get supplies than an artifact.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Kat on December 21, 2017, 08:33:08 pm
I was trying to figure it out - in one world, it also happened to be all of the dwarven deities, but not in another world.
Edit: I'm seeing 12 deities listed in a fort with 7 citizens, and each citizen only worships one deity (with some overlap), so the list is coming from somewhere else.

Cool. Thanks !

About your finding 12 deities listed in a 7-population fort. I'm wondering if that might be your parent civilisation's pantheon, and you just haven't got migrants yet that worship the others in the pantheon.

I think each independent civilisation generates its own pantheon, so if there's more than one dwarf civilisation, then the list will not include all dwarven deities in the world.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: PatrikLundell on December 22, 2017, 04:31:58 am
I was trying to figure it out - in one world, it also happened to be all of the dwarven deities, but not in another world.
Edit: I'm seeing 12 deities listed in a fort with 7 citizens, and each citizen only worships one deity (with some overlap), so the list is coming from somewhere else.

Cool. Thanks !

About your finding 12 deities listed in a 7-population fort. I'm wondering if that might be your parent civilisation's pantheon, and you just haven't got migrants yet that worship the others in the pantheon.

I think each independent civilisation generates its own pantheon, so if there's more than one dwarf civilisation, then the list will not include all dwarven deities in the world.
I haven't done much with deities (I'm using omni temples since my rather failed attempt to use dedicated ones caused the visitors to cram into temples rather than petition or research, for, or do whatever else they were supposed to be at the fortress for), but if I remember correctly, the list of deities you can create temples for initially contains the ones your civ worships (and I believe Kat is correct in that this is a subset of the race set), regardless of whether anyone worships those. The list of available deities then grows as "foreign" ones are worshiped by the population.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Devast on December 22, 2017, 06:17:09 am
Is the Startdwarf script not working or am I doing something incorrect?
(https://i.imgur.com/fua46Gx.jpg)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Rumrusher on December 22, 2017, 06:39:43 am
so uhh spent some time writing up scripts that mess with the raiding system so here's the probably updated version of recruit, and the move to military script for enlisting well historical units like say guests to a military squad of their own so you can send them out to attack stuff, or go on a raid. For the fort mode player who end up with more traveling guests than they have militia. I guess this probably works on the 'hostile' units on unretire maps.
Spoiler (click to show/hide)

ps. this probably works on ghosts so a squad full of ghosts is possible
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 22, 2017, 11:18:30 am
I haven't done much with deities (I'm using omni temples since my rather failed attempt to use dedicated ones caused the visitors to cram into temples rather than petition or research, for, or do whatever else they were supposed to be at the fortress for), but if I remember correctly, the list of deities you can create temples for initially contains the ones your civ worships (and I believe Kat is correct in that this is a subset of the race set), regardless of whether anyone worships those. The list of available deities then grows as "foreign" ones are worshiped by the population.
Any idea how to get that list (without having to start creating a new temple)?

Is the Startdwarf script not working or am I doing something incorrect?
It will work in the next version, unless you're using the 64-bit Linux build.

Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: CaptainArchmage on December 22, 2017, 12:04:55 pm
Just want to do another check - is there any way to dfhack in new items, reactions, or pets to existing civilisations (entities) in a world? I have heard at least pets or mounts can be hacked in.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 22, 2017, 12:47:22 pm
http://dfhack.readthedocs.io/en/stable/docs/_auto/devel.html#devel-inject-raws might work, but I haven't used it. There should be more directions if you try running the script. Make a backup of your save first! This script can cause corruption if you use it incorrectly.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: PatrikLundell on December 22, 2017, 01:01:25 pm
Regarding deities list:
No, I've only seen the list in game when trying to build a temple. The only other way I can think of at the moment is the rather brute force action of going through all hist figs to find the deities, check if they are civ tagged (I don't know if they are or even should be) to possibly get the starting list.
I can get the deities from a single sapient's relations, so getting it for all residents would be a matter of going through the units list and look at the ones that are residents.
The second part is fairly reasonable, but I don't like the first part. There must be somewhere in the data structures where you can find a civ's deities, as I very much doubt Toady uses the stupid brute force approach above. If there's a list of deities somewhere and they're tagged with civs somehow you can probably easily scan through that list (it shouldn't be very long), but a (unmapped) list of deity hist fig Ids in the civ entity would be even easier for the base (I think you still have to scan the units to get the current set, unless it's cached/built during game play).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Kat on December 22, 2017, 02:42:04 pm
Any idea how to get that list (without having to start creating a new temple)?

Not sure how helpful this would be, but using the exportlegends thing, and looking at it with worldviewer, you can see a civilisation and see their list of native deities.

so, it would appear to be saved somewhere within the games data, right ?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: PatrikLundell on December 22, 2017, 02:58:39 pm
Any idea how to get that list (without having to start creating a new temple)?

Not sure how helpful this would be, but using the exportlegends thing, and looking at it with worldviewer, you can see a civilisation and see their list of native deities.

so, it would appear to be saved somewhere within the games data, right ?
I've seen that as well, and it's a good idea, but unfortunately I don't think it helps us to find *where* it's stored, unless that's part of the "extra" info (as that is actually extracted using DFHackery, and so that code could be studied). Since Legends Mode can export it, it can presumably also display it, but then we're probably back at pulling data from a UI screen rather than whatever the actual source is.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 22, 2017, 04:04:32 pm
Yeah, the only thing exportlegends does with deities is exporting the deities associated with certain buildings.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Devast on December 22, 2017, 05:59:49 pm

It will work in the next version, unless you're using the 64-bit Linux build.

Sweet, thanks.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: CaptainArchmage on December 22, 2017, 08:34:26 pm
http://dfhack.readthedocs.io/en/stable/docs/_auto/devel.html#devel-inject-raws might work, but I haven't used it. There should be more directions if you try running the script. Make a backup of your save first! This script can cause corruption if you use it incorrectly.

Oh this one will be very useful. Does anyone know if this will change the entities though, so they can also use pedestals and display cases for example?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Max™ on December 22, 2017, 11:08:49 pm
Regarding deities list:
No, I've only seen the list in game when trying to build a temple. The only other way I can think of at the moment is the rather brute force action of going through all hist figs to find the deities, check if they are civ tagged (I don't know if they are or even should be) to possibly get the starting list.
I can get the deities from a single sapient's relations, so getting it for all residents would be a matter of going through the units list and look at the ones that are residents.
The second part is fairly reasonable, but I don't like the first part. There must be somewhere in the data structures where you can find a civ's deities, as I very much doubt Toady uses the stupid brute force approach above. If there's a list of deities somewhere and they're tagged with civs somehow you can probably easily scan through that list (it shouldn't be very long), but a (unmapped) list of deity hist fig Ids in the civ entity would be even easier for the base (I think you still have to scan the units to get the current set, unless it's cached/built during game play).
df.global.world.entities.all[k].unknown1b.worship has various numbers that I can't find a obvious relation to anything else, and the unknown1b.unknown1a has some which kinda sorta make sense as a list of histfig id numbers.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Urlance Woolsbane on December 23, 2017, 02:27:05 am
Regarding deities list:
No, I've only seen the list in game when trying to build a temple. The only other way I can think of at the moment is the rather brute force action of going through all hist figs to find the deities, check if they are civ tagged (I don't know if they are or even should be) to possibly get the starting list.
I did a bit of poking around in a save-file with a hex-editor, and I can confirm that deities are not civ tagged. Furthermore, each entity (including subgroups) has a table of deities. I don't know exactly where it falls in relation to the other data, save that it's shortly before the randomly-generated positions (used for law-givers, priests, and the like.)

If you want, I can upload the save-file, along with a list of the relevant deities.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: PatrikLundell on December 23, 2017, 04:48:46 am
I think MaxTM found it:
Printing the names of the hist figs listed in df.global.world.entities.all [my_civ].unknown1b.unk32b resulted in a list matching that presented when trying to create a new temple with a newly embarked group of 7.

@Urlance Woolsbane: Save game hacking is a bit outside of the scope for the task, although I wouldn't be surprised if it was located at the same location there as it is in DF itself (i.e. the location MaxTM pointed at).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Urlance Woolsbane on December 23, 2017, 05:39:44 am
@Urlance Woolsbane: Save game hacking is a bit outside of the scope for the task, although I wouldn't be surprised if it was located at the same location there as it is in DF itself (i.e. the location MaxTM pointed at).
That was my working assumption. Certainly, what I've seen of DF-Structures seems to line up with my research on the save-format.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: PatrikLundell on December 23, 2017, 05:57:36 am
OK, I think I've made a script. The testing is limited to a single embark before the first migrant wave (two visitors, though), so the "acquired" part hasn't been tested at all.

Spoiler (click to show/hide)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 23, 2017, 12:03:13 pm
df.global.world.entities.all [my_civ].unknown1b.unk32b
You should use df.historical_entity.find(my_civ) instead, assuming my_civ is ui.civ_id. Your way might work for small worlds, but most of the "all" vectors in worlds can skip IDs. It's possible that this one doesn't ever skip IDs, but just to be safe, find() will always return something with the right ID (or nil).

And yes, entity.unknown1b.unk32b does appear to be deity IDs (but in reverse order). I'll have to name that.

Edit: I think someone may have named the wrong vector (https://github.com/DFHack/df-structures/blob/0.44.02-alpha1/df.entities.xml#L492) "worship" (the third instead of the second). They have the same size, so there's a good chance they're related, but the second one is deity IDs. Turns out that actually dates back to 2012 (https://github.com/DFHack/df-structures/blame/0.44.02-alpha1/df.entities.xml#L492).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: PatrikLundell on December 23, 2017, 03:08:56 pm
You're correct that I should use "find" (although I've never seen entities.all to skip anything, but better safe than sorry).

Regarding naming the wrong vector and naming the unnamed one I've actually created a pull request for it (which also scrubs the (now?) incorrect comment that the first vector is empty. However, I won't mind if you reject it and creates your own with better/wider info instead.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: Putnam on December 23, 2017, 07:39:58 pm
I usually just use the type name, e.g. df.historical_entity.unknown1b.unk32b
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 23, 2017, 09:32:22 pm
Using gui/liquids, a permaflow that is flowing downwards is labeled "inv_8". It is "inv_9" if flowing off the east edge of the map. Haven't tested others.
Naturally-occurring or created with DFHack?
Naturally-occurring, in a save untouched by DFHack.
This appears to occur in 0.43.05 as well; reported at https://github.com/DFHack/df-structures/issues/228
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: jecowa on December 24, 2017, 01:14:34 am
Does Stonesense work in 0.44.02-alpha? I've tried both "2D" and "STANDARD" print modes. I've tried it both with the vanilla libraries and with "libfreetype.6.dylib" added. I'm testing mostly in the Object Testing Arena, but I tried in a dwarf fortress once. I've tried with both the Lazy Newb Pack and a manual installation.


If stonesense isn't updated yet, that's fine; I just want to make sure it's not just me.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 24, 2017, 11:04:21 am
Stonesense hasn't been touched in a long time. Whatever that is is probably a system or packaging issue - we've never had to update it for specific versions to avoid library issues, because the libraries it uses aren't tied to specific DF versions. Can you post your stderr.log?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: jecowa on December 24, 2017, 01:18:51 pm
probably the relevant bit:
Code: [Select]
loaded plugin stocks; DFHack build 0.44.02-alpha1-0-g43b19c89
loading plugin stonesense
dlopen(~/Downloads/df/df_osx_44_02 DFHack TWBT Tergel/hack/plugins/stonesense.plug.dylib, 6): Symbol not found: ___sincos_stret
  Referenced from: ~/Downloads/df/df_osx_44_02 DFHack TWBT Tergel/hack/libs/liballegro.5.2.2.dylib
  Expected in: flat namespace
 in ~/Downloads/df/df_osx_44_02 DFHack TWBT Tergel/hack/libs/liballegro.5.2.2.dylib
Can't load plugin stonesense
loading plugin strangemood


Spoiler: full file (click to show/hide)

I'm on 10.7.5 Lion if it matters.

Edit: I tried stonesense in 43.05-64 (didn't work) and 43.03-32 (it worked), so it seems like a 64-bit specific issue.

Edit2: Works great in DFHack 44.02-alpha-32bit:
Spoiler (click to show/hide)

The error says something about a namespace and the 64-bit version is using absolute file references while the 32-bit version is using relative locations. Maybe that doesn't really matter, though.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 24, 2017, 02:17:37 pm
the 64-bit version is using absolute file references while the 32-bit version is using relative locations
I see absolute paths to liballegro in the 64-bit log, but they're pointing to things on your machine, so that's not the issue. I see nothing that could be described as relative locations in the 32-bit log, unless you mean "stonesense", but that's just the plugin's name.

Note that the 64-bit version uses a newer version of Allegro. A search for "___sinceos_stret" turned up https://github.com/mapnik/node-mapnik/issues/324 and https://github.com/pioneerspacesim/pioneer/issues/2610, so it's possible that this version of Allegro either doesn't support <10.9 at all or was built in a way that doesn't.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: scourge728 on December 24, 2017, 02:40:02 pm
Was the command to force units into your possession removed, or am I just missing it when I look at the documentation?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: lethosor on December 24, 2017, 02:46:06 pm
Are you talking about "tweak makeown"?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-alpha1 (dev)
Post by: scourge728 on December 24, 2017, 02:52:51 pm
Are you talking about "tweak makeown"?
That's the one
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: lethosor on December 24, 2017, 08:39:17 pm
New (beta) release: https://github.com/DFHack/dfhack/releases/tag/0.44.02-beta1

Hopefully this is the last one before a stable release! It was supposed to be up yesterday, but the build server died.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: shnapsx on December 25, 2017, 12:54:13 am
Hi. Came here to report a little bug, I think.
Seems like autogems using fishery instead of jewelry to cut gems.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: lethosor on December 25, 2017, 01:01:54 am
What DFHack version are you using?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: shnapsx on December 25, 2017, 03:06:28 am
What DFHack version are you using?
44 alpha1. Didn't updated to beta yet.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: lethosor on December 25, 2017, 08:07:43 am
I'm pretty sure beta1 fixes it, so try that when you get a chance.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: shnapsx on December 25, 2017, 02:46:55 pm
I'm pretty sure beta1 fixes it, so try that when you get a chance.
Yea, it works. But I'll wait for twbt for beta :D
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: lethosor on December 25, 2017, 11:13:01 pm
I've set up a release for 0.44.03. It looks like the build server is currently working on building the last development build before the release, so if it's not done with that in a couple hours, I'll publish the release anyway and hope that it uploads binaries overnight.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: CaptainArchmage on December 25, 2017, 11:16:57 pm
I've successfully gotten DFhack to inject in the raws for pedestals and display cases (Update from 0.43.05 to 0.44.02)! No save corruption and I can confirm carpenter's shops can produce pedestals.

The next problem is the reaction for producing a display case. I did not hack this in the first time around, since I'm not sure how to enter it into the command line.

Here's the line I used for hacking in the pedestals and display cases:
Code: [Select]
devel/inject-raws tool ITEM_TOOL_PEDESTAL tool ITEM_TOOL_DISPLAY_CASE
Here's the problem with the reaction:
It is listed as [REACTION:MAKE WOODEN DISPLAY CASE]

I am concerned that doing
Code: [Select]
devel/inject-raws reaction MAKE WOODEN DISPLAY CASE will inject a reaction called [REACTION:MAKE] instead of [REACTION:MAKE WOODEN DISPLAY CASE], which would be a very bad thing (though not insurmountable)

Is this going to get parsed properly into the command line?

Also I was using the DF 0.44.02 version of raws and so on for this, not that it matters yet.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: Quietust on December 25, 2017, 11:23:51 pm
Here's the problem with the reaction:
It is listed as [REACTION:MAKE WOODEN DISPLAY CASE]

I am concerned that doing
Code: [Select]
devel/inject-raws reaction MAKE WOODEN DISPLAY CASE will inject a reaction called [REACTION:MAKE] instead of [REACTION:MAKE WOODEN DISPLAY CASE], which would be a very bad thing (though not insurmountable)
Try enclosing it in quotes - that should ensure that "MAKE WOODEN DISPLAY CASE" is handled as a single argument instead of 4.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: CaptainArchmage on December 25, 2017, 11:39:38 pm
Here's the problem with the reaction:
It is listed as [REACTION:MAKE WOODEN DISPLAY CASE]

I am concerned that doing
Code: [Select]
devel/inject-raws reaction MAKE WOODEN DISPLAY CASE will inject a reaction called [REACTION:MAKE] instead of [REACTION:MAKE WOODEN DISPLAY CASE], which would be a very bad thing (though not insurmountable)
Try enclosing it in quotes - that should ensure that "MAKE WOODEN DISPLAY CASE" is handled as a single argument instead of 4.

Thanks for the reply, just tried it, I get:

Invalid option: MAKE WOODEN DISPLAY CASE
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: lethosor on December 25, 2017, 11:44:02 pm
You're including the reaction argument, correct?

Also, build server update: it requires some extra setup for new DF versions, apparently, so builds won't be up for a while.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: CaptainArchmage on December 25, 2017, 11:45:34 pm
You're including the reaction argument, correct?

Also, build server update: it requires some extra setup for new DF versions, apparently, so builds won't be up for a while.

Yes, I entered:
Code: [Select]
devel/inject-raws reaction "MAKE WOODEN DISPLAY CASE"
Edit: It doesn't seem to be possible to parse in the string with spaces using the quotation marks. The following was attempted without a save loaded (hopefully haven't wrecked the game files):

Code: [Select]
[DFHack]# devel/inject-raws reaction MAKE_WOODEN_DISPLAY_CASE
WARNING: THIS SCRIPT CAN PERMANENLY DAMAGE YOUR SAVE.

This script attempts to inject new raw objects into your
world. If the injected references do not match the actual
edited raws, your save will refuse to load, or load but crash.

Did you make a backup? (y/n): y

Injecting reaction MAKE_WOODEN_DISPLAY_CASE

Now without unpausing save and reload the game to re-read raws.
[DFHack]# devel/inject-raws reaction "MAKE WOODEN DISPLAY CASE"
WARNING: THIS SCRIPT CAN PERMANENLY DAMAGE YOUR SAVE.

This script attempts to inject new raw objects into your
world. If the injected references do not match the actual
edited raws, your save will refuse to load, or load but crash.

Did you make a backup? (y/n): y
Invalid option: MAKE WOODEN DISPLAY CASE

It seems the options are to either:
1) Edit the reaction to "MAKE_WOODEN_DISPLAY_CASE" in all places it occurs and be vigilant about further raw changes.
2) Try to find another way to input a string. Which is probably going to be important somewhere.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: lethosor on December 26, 2017, 12:29:45 am
Yeah, looks like an issue with the script. In hack/scripts/devel/inject-raws.lua, try changing this line (it's near the end):

Code: [Select]
    if mode and string.match(kv, '^[%u_]+$') then

to this:

Code: [Select]
    if mode and string.match(kv, '^[%u_ ]+$') then

The only change is adding a space before the ] character.

I'll look into a better way of fixing that. Thanks!
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: CaptainArchmage on December 26, 2017, 12:32:39 am
Yeah, looks like an issue with the script. In hack/scripts/devel/inject-raws.lua, try changing this line (it's near the end):

Code: [Select]
    if mode and string.match(kv, '^[%u_]+$') then

to this:

Code: [Select]
    if mode and string.match(kv, '^[%u_ ]+$') then

The only change is adding a space before the ] character.

I'll look into a better way of fixing that. Thanks!

Will take note of that, and do this tomorrow (will report back about success or not). Also is there any way (besides the save not spontaneously combusting on load) to tell whether my civilisation has access to the reaction (and the modding was successful)? I've pretty much confirmed the pedestals can be made since they show up in the carpenter's workshop.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: Putnam on December 26, 2017, 12:33:46 am
Yeah, looks like an issue with the script. In hack/scripts/devel/inject-raws.lua, try changing this line (it's near the end):

Code: [Select]
    if mode and string.match(kv, '^[%u_]+$') then

to this:

Code: [Select]
    if mode and string.match(kv, '^[%u_ ]+$') then

The only change is adding a space before the ] character.

I'll look into a better way of fixing that. Thanks!

That seems like a perfectly reasonable way to fix that, if I'm reading that regex right.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: lethosor on December 26, 2017, 12:57:36 am
Yeah, but if someone decides to use another character in a reaction name (or any raw identifier), it'll break again. Unless there are restrictions on the characters that can be in an identifier, it might be better to treat anything besides "reaction" or a building/item type as an identifier. (Or we could just assume other characters won't be used; that might be easier.)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: KittyTac on December 26, 2017, 02:55:55 am
So, I made a "God Of Slaughter" creature for slaughtering things and turning them into demons. Both demons and I have [OPPOSED_TO_LIFE] and infight. How to fix the infighting? I want to massacre innocents without my servants killing each other.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: Putnam on December 26, 2017, 03:34:35 am
[NOT_LIVING]
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: CaptainArchmage on December 26, 2017, 09:55:42 am
Yeah, but if someone decides to use another character in a reaction name (or any raw identifier), it'll break again. Unless there are restrictions on the characters that can be in an identifier, it might be better to treat anything besides "reaction" or a building/item type as an identifier. (Or we could just assume other characters won't be used; that might be easier.)

Could you explain this one? How would other characters be used? The [ and ] characters I get delimit the raw identifier. Until recently, we didn't have spaces used in reaction names, it seems their first use was with ASSEMBLE STONE AXE and before that spaces in names were instead delimited with _s. If I remember rightly, that specific reaction went in for adventure mode sites, which was slightly after the primary 0.43 release.

Also assuming the save doesn't spontaneously combust, there should be some lazy newb script for updating a 0.43.05 game to the latest version.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: dragdeler on December 26, 2017, 10:09:06 am
Hi, what happens if I uninstall DFhack? Will I be able to keep my old savegame, update the game, and reinstall a later version of DFhack? Or do I need to expect the savegame to not work properly? Is it adviseable to update it all at once?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: scourge728 on December 26, 2017, 11:06:28 am
From my experience, 1. Not much 2.Yes, yes,
 yes 3.No. 4. Yes
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: lethosor on December 26, 2017, 11:28:05 am
Could you explain this one? How would other characters be used? The [ and ] characters I get delimit the raw identifier. Until recently, we didn't have spaces used in reaction names, it seems their first use was with ASSEMBLE STONE AXE and before that spaces in names were instead delimited with _s. If I remember rightly, that specific reaction went in for adventure mode sites, which was slightly after the primary 0.43 release.
People could use other characters in identifiers. Like "CREATE-WOODEN-DISPLAY-CASE", or "Create wooden display case!". The square brackets in the line I asked you to patch contain the characters that script considers to be valid in identifiers - they're not representing the square brackets in the raw files (I'm not sure if that's what you meant).

Quote
Also assuming the save doesn't spontaneously combust, there should be some lazy newb script for updating a 0.43.05 game to the latest version.
It would be nice, but as far as I know, we've never done this for previous DF releases, and it would also require raw edits.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: lethosor on December 26, 2017, 12:12:46 pm
Here's a new release for 0.44.03 that may or may not work (test it and find out!): https://github.com/DFHack/dfhack/releases/tag/0.44.03-alpha1
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: dragdeler on December 26, 2017, 12:15:01 pm
thank you very much scourge728 ... and all of you for that matter

Quote
Here's a new release for 0.44.03 that may or may not work (test it and find out!): https://github.com/DFHack/dfhack/releases/tag/0.44.03-alpha1

Just in time eh  :D? Will do
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: jecowa on December 26, 2017, 12:15:53 pm
Here's a new release for 0.44.03 that may or may not work (test it and find out!): https://github.com/DFHack/dfhack/releases/tag/0.44.03-alpha1


Wow, everything's happening so quickly!
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: lethosor on December 26, 2017, 12:33:14 pm
Wow, everything's happening so quickly!
That also means few of the builds have been verified manually. I'm fairly certain all of the global and vtable addresses are right, assuming the scripts that find them are working, but I had to fill in a few things manually. If people could report back that certain builds work, that would be great.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: CaptainArchmage on December 26, 2017, 01:26:20 pm
Yeah, but if someone decides to use another character in a reaction name (or any raw identifier), it'll break again. Unless there are restrictions on the characters that can be in an identifier, it might be better to treat anything besides "reaction" or a building/item type as an identifier. (Or we could just assume other characters won't be used; that might be easier.)

Just ran the reaction using the fix and it seems nothing is broken. Of course I have not made display cases in this release cycle and they may be broken more than one way...
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: Putnam on December 26, 2017, 11:38:29 pm
Yeah, but if someone decides to use another character in a reaction name (or any raw identifier), it'll break again. Unless there are restrictions on the characters that can be in an identifier, it might be better to treat anything besides "reaction" or a building/item type as an identifier. (Or we could just assume other characters won't be used; that might be easier.)

If it's anything like reaction classes, you can probably use anything in the charset that isn't []:
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: lethosor on December 27, 2017, 10:26:08 am
So far, there have been 146 downloads of the 64-bit Windows build and 13 of the 32-bit one. I haven't heard any reports from anyone using them - can I assume they're working, or can someone confirm? (A check for the Linux builds would be nice too.)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: dragdeler on December 27, 2017, 10:43:23 am
Works for me unless this (http://www.bay12forums.com/smf/index.php?topic=154617.135) is related.

64bit windows
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: Button on December 27, 2017, 03:47:59 pm
I posted this on Reddit but I really should have come here instead. Obviously updating for 44.03 is higher priority but I have a Question.

Has anyone identified how to make the game's Resident info screens show up for creatures who were initially created as Animals rather than as Persons?

I mod animal people to be PET_EXOTIC.

Animal people that I catch and train eventually petition for citizenship and are assigned default peasant labors; they can also be assigned labors through Dwarf Therapist. However, they maintain the Animal in-game labor assignment screen and the stranger/animal-style description screen, e.g. "This is a person with the head of a peach-faced lovebird. His feathers are green. His skin is ecru."

Any pointers you could provide would be appreciated.

I've checked all the unit flags, including the unknown ones, and none of them seem to be what I'm looking for.

Alternatively, a script that forces a unit to petition for residency might also work? Trained animal people never petition for residency - they become de facto residents when you first train them, and skip straight to petitioning for citizenship. If you could force an animal person to petition for residency it might perform the description screen conversion as a matter of course.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: Kanil on December 27, 2017, 04:12:50 pm
Thank you for the update. I've had no problems using any of the commands I'm familiar with the use of.

That said, I've been unable to rename any units. I'm not sure if "names" is working correctly, or if I'm just using it wrong, or if I should be using some other command entirely.

Meanwhile "gm-editor" can update the unit's name in the unit list, but doesn't seem update the unit's translated name (IE: I can rename a unit Urist Olonreg, but it doesn't appear as "Urist Geargloves", rather it still uses it's original name.)

Edit: Forgot to mention, using 44.02beta-1 Win64.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: lethosor on December 27, 2017, 04:28:59 pm
Thank you for the update. I've had no problems using any of the commands I'm familiar with the use of.

That said, I've been unable to rename any units. I'm not sure if "names" is working correctly, or if I'm just using it wrong, or if I should be using some other command entirely.

Meanwhile "gm-editor" can update the unit's name in the unit list, but doesn't seem update the unit's translated name (IE: I can rename a unit Urist Olonreg, but it doesn't appear as "Urist Geargloves", rather it still uses it's original name.)
Are you just looking to change the nickname, or the entire name? The error I'm seeing in "names" indicates that it's been broken for a long time (maybe since 0.42). "gui/rename" can change nicknames. The reason gui/gm-editor doesn't work for what you're trying is because units can have up to 3-4 names (unit, histfig, soul? alternate identity?), and the one that's displayed can vary. You can use dfhack.units.setNickname() from Lua, but that only changes the nickname (as you can probably tell).

I'll look into fixing "names". Let me know if that helps.

Has anyone identified how to make the game's Resident info screens show up for creatures who were initially created as Animals rather than as Persons?
The screens you get with 'u'-'v'? That's viewscreen_unitst, if I remember that correctly, which is fairly easy to create in Lua:
Code: [Select]
s=df.viewscreen_unitst:new() -- note that this crashes if a world isn't loaded, as I just found out
s.unit = some_unit
dfhack.screen.show(s)
I don't know what's up with animal-men-turned-citizens not having this option. A save might help, if you have one.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: Kanil on December 27, 2017, 04:42:12 pm
I'm trying to change the unit's actual name. I probably should have specified that "rename" wasn't useful, as it only does nicknames. My apologies.

gm-editor does seem mostly beyond my limited abilities/understanding, but I figured I'd try anything I could think of before making pointless forum posts.

Basically I'm trying to conjure up a couple of units for my fort without having to go through the hassle of creating adventurers and retiring them (and the fort.) modtools/create-unit seems to have worked just fine, but I don't think it has a way to set the unit name beyond which language to use. So I'm just trying to give Mr. Islandlobster a slightly better name.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: lethosor on December 27, 2017, 04:50:32 pm
On mobile, but if you can read C++, https://github.com/DFHack/dfhack/blob/master/library/modules/Units.cpp#L183 mentions all of the possible names a unit could have. The first two or three might be all you need to change.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: Kanil on December 27, 2017, 05:39:29 pm
I can't say I really know what I'm doing, but I was able to change the unit's name in it's historical figure, which update the in-fort "translated" name. I'm not sure if the other names get used anywhere in day-to-day forting, but if they don't, then it seems to have worked fine.

Thank you.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: feelotraveller on December 27, 2017, 06:26:12 pm
So far, there have been 146 downloads of the 64-bit Windows build and 13 of the 32-bit one. I haven't heard any reports from anyone using them - can I assume they're working, or can someone confirm? (A check for the Linux builds would be nice too.)

Linux-64 build [dfhack-0.44.03-alpha1-Linux-64-gcc-5.4.0 to be precise] is working for me but I have only used a couple of basic functions so far.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: lethosor on December 27, 2017, 11:43:08 pm
Kanil: I'm having trouble figuring out the "names" script - have you used it before? Do you know what it's supposed to do in various situations? It looks like it's supposed to open the custom name screen, but I'm not seeing how that could end up changing a unit's name. Did you just find it in the documentation? I'm inclined to remove or rewrite it.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: Button on December 27, 2017, 11:54:41 pm
Has anyone identified how to make the game's Resident info screens show up for creatures who were initially created as Animals rather than as Persons?
The screens you get with 'u'-'v'? That's viewscreen_unitst, if I remember that correctly, which is fairly easy to create in Lua:
Code: [Select]
s=df.viewscreen_unitst:new() -- note that this crashes if a world isn't loaded, as I just found out
s.unit = some_unit
dfhack.screen.show(s)
I don't know what's up with animal-men-turned-citizens not having this option. A save might help, if you have one.

It turns out I haven't had animal man citizens since 43.05; now that the flood of elves is no longer an issue I may be able to play a longer-term fort in 44 and check to see if anything has changed. I hope this being a 43.05 save isn't a problem. Save is here (http://dffd.bay12games.com/file.php?id=13353).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.02-beta1 (dev)
Post by: KittyTac on December 28, 2017, 01:30:53 am
[NOT_LIVING]

They have that tag already, and still infight. I want a script or something.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: Kanil on December 28, 2017, 03:32:31 am
Kanil: I'm having trouble figuring out the "names" script - have you used it before? Do you know what it's supposed to do in various situations? It looks like it's supposed to open the custom name screen, but I'm not seeing how that could end up changing a unit's name. Did you just find it in the documentation? I'm inclined to remove or rewrite it.
I've never used it before, so I'm not sure what it's supposed to do -- this is the first time I've wanted something renamed. I found it both in the documentation and in "ls" under scripts.

I'm mostly happy with what I've been able to do, so you needn't rewrite it on my behalf.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: Urlance Woolsbane on December 28, 2017, 04:13:01 am
Does anyone know exactly what it is that prevents one from consistently embarking with fewer than 7 dwarves? Selecting "Start Now" automatically crashes, but using a custom embark occasionally works. In one instance I was able to embark with a mere three dwarves, but I haven't the foggiest what made it work.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: PatrikLundell on December 28, 2017, 04:54:00 am
:
Has anyone identified how to make the game's Resident info screens show up for creatures who were initially created as Animals rather than as Persons?
The screens you get with 'u'-'v'? That's viewscreen_unitst, if I remember that correctly, which is fairly easy to create in Lua:
Code: [Select]
s=df.viewscreen_unitst:new() -- note that this crashes if a world isn't loaded, as I just found out
s.unit = some_unit
dfhack.screen.show(s)
I don't know what's up with animal-men-turned-citizens not having this option. A save might help, if you have one.
As far as I can see from the description the modded animal people behave the same as unmodded Gremlins do (I haven't had any since 0.43.05, but I doubt this has changed). Thus, it's a low priority vanilla DF issue which Toady probably won't touch until animal people are reworked (whenever that will be).
Another problem you'll have with "animal" animal people is that once they become citizens they still need to be retrained, but retraining is an incredibly low priority activity, so the trainer just sits there waiting unless you force the trainee to show up. I've worked around that with Gremlins by setting their training level to "Tame" using gui/gm-editor as they become citizens. (And you can order the butchering of "animal" citizens... I haven't tried, so I don't know if they'll eat those sapients as well). DT works well to work around the issue with setting and changing the work profile for Gremlins, but Dwarf Manipulator considers that to be outside of its scope.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: Urlance Woolsbane on December 28, 2017, 05:02:05 am
As far as I can see from the description the modded animal people behave the same as unmodded Gremlins do (I haven't had any since 0.43.05, but I doubt this has changed). Thus, it's a low priority vanilla DF issue which Toady probably won't touch until animal people are reworked (whenever that will be).
That should be part of the Myth Arc. Toady has talked about incorporating them into creation myths, allowing for varied and sundry permutations.

EDIT:
I did a bit more testing on the starting dwarves issue, and it seems that it's possible to embark with only one, so long as you have at least six animals in your livestock. Basically, the game insists on having a minimum of 7 units in the embark party, but it doesn't care if they're citizens or livestock. Hopefully someone more knowledgeable than I am can explain what this signifies.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: FantasticDorf on December 28, 2017, 07:37:13 am
Interesting but altering the starting amount of dwarves (and as Woolsbane points out, possibly inserting sentient pets as citizens?) is also a development that may happen by the time we reach starting scenarios which may have a degree of flexibility on the settings for now that are hardcoded.

Fixing the behaviour pertaining to gremlins is a bit higher on the agenda than other modding outcomes as its intentional vanilla, but actually obtaining gremlins (because of their knack to avoid traps, deep underground and mostly invisible) for most intermediate players doesn't happen frequently enough and also in the respect of noticing the changes in the game over time gremlins now have to put up with identities & tavern behaviours.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: PatrikLundell on December 28, 2017, 09:28:05 am
The Gremlins I've had didn't seem to have any problems with (unstaffed) taverns or with libraries (I believe they read a fair bit). I'm not sure about whether they used the (omni) temple or not, and since DF doesn't provide access to their personal screen I haven't been able to see if they had any deities or preferences. And, regarding that: don't assign Gremlins or "animal" animal people as nobles, as you can't see their demands and/or mandates (I don't remember if it was one or both, as I make sure not to get any mandate spewers).

Explaining where animal people come from may not necessarily mean their behavior is changed at that time, but we'll eventually see what appears in the various Myth & Magic arcs. The Myth & Magic bag is bursting at the seams (each section of it on the dev page except one is larger than the complete contents of this arc).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: Button on December 28, 2017, 04:06:11 pm
Yeah, I know it should be coming eventually but as a low priority fix - I was just hoping there might be some memhacking we could do in the meantime to make the game go "Oh, that's a person."

Making them stop needing training with DFHack is an easy fix, just a matter of flipping a boolean flag. It's the other bits that are a problem... like giving them names so I can actually tell them apart; or choosing who to try to marry to whom so I can see what the second generation is like.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: Urlance Woolsbane on December 28, 2017, 04:20:25 pm
Interesting but altering the starting amount of dwarves (and as Woolsbane points out, possibly inserting sentient pets as citizens?) is also a development that may happen by the time we reach starting scenarios which may have a degree of flexibility on the settings for now that are hardcoded.
Quite probably, but embark scenarios are easily a few years down the road, and I'm trying to get a head start on them...

Explaining where animal people come from may not necessarily mean their behavior is changed at that time, but we'll eventually see what appears in the various Myth & Magic arcs. The Myth & Magic bag is bursting at the seams (each section of it on the dev page except one is larger than the complete contents of this arc).
It's ambitious, to be sure. Even if Toady spreads it out over several releases, I imagine we'll still be in for nearly two years between the last 00.44.xx release and the first Myth and Magic one. You're right that certain plans may go the way of gambling, recipes, and roadside inns...
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: pikachu17 on December 28, 2017, 04:23:17 pm
PTW
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: Urlance Woolsbane on December 28, 2017, 11:28:41 pm
Per my previous query, is there anything that can be done to change it, or is the address in question likely not writable? Am I better off jury-rigging a solution?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: lethosor on December 29, 2017, 01:24:31 am
My best guess is that DF assumes there are always at least 7 creatures and deals with the first 7 unconditionally. I'm a bit surprised that livestock affects it, but I guess it makes sense.

I highly doubt there's a single address that contains a single number that can affect this. I'm pretty sure start_dwarf_count is used in the loop that creates units in DF, but there are likely several places that assume there are at least 7. The fact that code isn't writable doesn't matter - start_dwarf_count is in the code section and isn't normally writeable as well, but we have a way to patch read-only memory.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: Urlance Woolsbane on December 29, 2017, 02:07:07 am
My best guess is that DF assumes there are always at least 7 creatures and deals with the first 7 unconditionally. I'm a bit surprised that livestock affects it, but I guess it makes sense.
If I had to guess, it's either vestigial or connected to creatures such as kobolds, that count as livestock but act like citizens. Regardless, it's odd.

I highly doubt there's a single address that contains a single number that can affect this. I'm pretty sure start_dwarf_count is used in the loop that creates units in DF, but there are likely several places that assume there are at least 7.
And therein lies my problem. Start_dwarf_count works fine until I press 'e', at which point the game does any number of things behind the scenes. It might be one subroutine that's to blame, it might be twenty.

The fact that code isn't writable doesn't matter - start_dwarf_count is in the code section and isn't normally writeable as well, but we have a way to patch read-only memory.

That's quite a relief. Contrived band-aid solutions drive me up the wall.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: Clément on December 29, 2017, 05:57:22 am
I wrote a script for helping to create twbt override (https://gist.github.com/cvuchener/c176e7d0bee18e5c6c75c7ac5bded6f7). When Meph tried it on a custom workshop (http://www.bay12forums.com/smf/index.php?topic=138754.msg7654933#msg7654933), it found the buildings_other_id "WEAPON_UPRIGHT". The script is not very good at choosing the best ID but it should choose at least a valid one. Do you see an issue with my script? Or does this category really contains custom workshop and is not well named?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: Meph on December 29, 2017, 07:30:19 am
I wrote a script for helping to create twbt override (https://gist.github.com/cvuchener/c176e7d0bee18e5c6c75c7ac5bded6f7). When Meph tried it on a custom workshop (http://www.bay12forums.com/smf/index.php?topic=138754.msg7654933#msg7654933), it found the buildings_other_id "WEAPON_UPRIGHT". The script is not very good at choosing the best ID but it should choose at least a valid one. Do you see an issue with my script? Or does this category really contains custom workshop and is not well named?
Weapopn_Upright is a valid building ID, it's the adamantine sword in the underground fortresses that connect to the underworld.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: Putnam on December 29, 2017, 07:57:48 am
Ah, previously existing fortresses. They were removed in... either 0.34.01 or 0.40.01, I forgot.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: FantasticDorf on December 29, 2017, 08:36:41 am
40.01 including hyenaman huts, which i remember fondly of my breif encounters fending them off from attempting to kill my sheep and carry them off-screen.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: lethosor on December 29, 2017, 10:19:53 am
I wrote a script for helping to create twbt override (https://gist.github.com/cvuchener/c176e7d0bee18e5c6c75c7ac5bded6f7). When Meph tried it on a custom workshop (http://www.bay12forums.com/smf/index.php?topic=138754.msg7654933#msg7654933), it found the buildings_other_id "WEAPON_UPRIGHT". The script is not very good at choosing the best ID but it should choose at least a valid one. Do you see an issue with my script? Or does this category really contains custom workshop and is not well named?
Just to confirm, you are not using DFHack 0.44.02-alpha1, correct? That version had an issue with buildings_other_id.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: mifki on December 29, 2017, 10:24:20 am
I wrote a script for helping to create twbt override (https://gist.github.com/cvuchener/c176e7d0bee18e5c6c75c7ac5bded6f7). When Meph tried it on a custom workshop (http://www.bay12forums.com/smf/index.php?topic=138754.msg7654933#msg7654933), it found the buildings_other_id "WEAPON_UPRIGHT". The script is not very good at choosing the best ID but it should choose at least a valid one. Do you see an issue with my script? Or does this category really contains custom workshop and is not well named?
Just to confirm, you are not using DFHack 0.44.02-alpha1, correct? That version had an issue with buildings_other_id.

I'm pretty sure it's all good in 44.03.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: Clément on December 29, 2017, 10:41:24 am
Given Meph's later answer (http://www.bay12forums.com/smf/index.php?topic=138754.msg7654983#msg7654983), I think it was 44.02.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: lethosor on December 29, 2017, 10:49:04 am
Oh, different thread. But there were two DFHack builds for 0.44.02 (alpha1 and beta1), and only the former had the issue. (Edit: yeah, sounds like alpha1.)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: iceball3 on December 29, 2017, 10:00:07 pm
How is the current build alpha? Are there some usable features, or should I wait before using it for anything besides directly development?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: lethosor on December 29, 2017, 10:45:11 pm
The only way to know for sure is to test it - that's why it was released! That said, most things should work. I haven't had any issues myself, but I don't use a lot of DFHack tools on a regular basis. If you're willing to report issues that you run into, then feel free to download it and play around.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: iceball3 on December 30, 2017, 12:40:52 am
The only way to know for sure is to test it - that's why it was released! That said, most things should work. I haven't had any issues myself, but I don't use a lot of DFHack tools on a regular basis. If you're willing to report issues that you run into, then feel free to download it and play around.
Ahh, fair enough! Best i set autosave to seasonal, then, before i get started. Perhaps with backups enabled for once!
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-alpha1 (dev)
Post by: lethosor on December 30, 2017, 02:17:41 am
I put up a new release with a few fixes, mostly to new structures that few people were likely using (but a couple bugfixes too). It's at https://github.com/DFHack/dfhack/releases/tag/0.44.03-beta1. Currently there aren't any binaries, but I need to sleep, so hopefully they'll be uploaded in the next hour or so (assuming it works this time, which it appears to be doing).

Edit: it broke again. Sorry, all. I'll see if there's a way to restart it.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Max™ on December 30, 2017, 03:28:31 am
Kanil: I'm having trouble figuring out the "names" script - have you used it before? Do you know what it's supposed to do in various situations? It looks like it's supposed to open the custom name screen, but I'm not seeing how that could end up changing a unit's name. Did you just find it in the documentation? I'm inclined to remove or rewrite it.
I've got a new version with fixes for various bugs and whatnot up with a pull for it and the various format/random missed spaces/trying to include the --[[blah]]-- documenation properly that seems fine according to travis.

You are right that it pulls up the custom name screen to access the native interface options there. Upon confirming/leaving it sets the unit/artifact name to the custom name shown.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Rumrusher on December 30, 2017, 09:54:57 am
so setting an adventurer in Fort mode(using a switch adventurer script) seems to crash the game, which is really really weird. but I guess given the whole army arc there been some changes.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: lethosor on December 30, 2017, 02:04:30 pm
Binaries for beta1 are up now.

Max - cool, I'll look at it.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: iceball3 on December 30, 2017, 09:52:20 pm
In the alpha, I'm trying to save and exit but it's stuck at the save menu.
(https://cdn.discordapp.com/attachments/209085745166680065/396857278441193473/unknown.png)
Not sure what exactly is causing it. I'm near the end of the first year. I would've expected it's just a slow save, but it's been really long now.
Is there anything I could mess around with in the dfhack console to get it moving again?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Max™ on December 30, 2017, 10:14:34 pm
devel/pop-screen
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: iceball3 on December 30, 2017, 10:18:22 pm
I just figured it out, and I will provide insight on what I think happened.
How I got it unstuck: I pressed the enter key in the DFHack menu.

What I think happened: I had earlier typed "ls" so i could see the command list. The command list was printed, and the line immediately after was blinking _, as what I would normally expect.
When i tried saving, the game got stuck in not-responding, and DF was using no processor resources. I was a bit confused, so I waited a long while with no progress.
I then pressed enter in the DFHack window. This caused the display to change as so:
(https://cdn.discordapp.com/attachments/209085745166680065/396863848503836672/unknown.png)
My deduction here is this: the "ls" script continues running until after enter is pressed again. This prevents "clearing animal hospitals" or any other number of "it's time to save" subroutines from going through. This stalls Dwarf Fortress itself from performing any saving.
Luckily, I didn't close DF before I figured this out, so my save is safe!

Question though, can I safely paste the new DFHack version over my DF Folder that has the alpha version on it? This experience has made me crave some of those new bugfixes.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: PatrikLundell on December 31, 2017, 08:11:40 am
I think I've sort of replicated iceball3's behavior using 0.44.02-alpha1 (built locally with some changes that were underway, rather than downloaded):
Pressing control-s (XOFF) while s was doing it's output during fortress loading resulted in a blinking underscore halfway through, BUT NO DFHACK PROMPT, and it seemed the fortress got stuck on loading when it should start the screen display. A return in the DFHack window caused the halted output to resume, a couple of DFHack loading commands to be performed, and the fortress to be brought up. Also, pressing control-s when ls has been typed but return isn't pressed causes up arrow to be gobbled up (probably activating an XON) with a second up arrow to go back in the command history.

It should be noted that I had to try a fair number of times before I managed to suspend the ls output halfway through, but loading of that fortress took a fair while, so there was enough time...

I've got no idea how you'd accidentally get an XOFF signal to the DFHack window without doing it manually, though.
A question for iceball3: Which OS are you using? There's one DFHack console window version for Windows and another for other OS' (I'm on Windows).

Control-s in the DFHack command window (just on an empty line) and then trying to save DF resulted in the DFHack prompt disappearing, but DF itself being stuck on the command screen. A return in the DFHack console window caused "Clearing all animal hospitals" (and the DFHack prompt) to appear, as well as the game saving to progress. I suspect any input in the command window would dislodge XOFF, but haven't tried.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Clément on December 31, 2017, 08:26:04 am
Using 0.44.03-beta1, I have a bug in the identity structure. I have a vampire pretending to be born the 24th of Opal in 118. Dwarf Therapist was showing it much too old, so I looked at DFHack:
Code: [Select]
<identity: 0x7fffa854edb0>
id                      = 7853
name                    = <language_name: 0x7fffa854edb8>
race                    = 572
caste                  = 0
histfig_id              = -1
unk_4c                  = 33318
birth_year              = 0
birth_second            = 118
anon_1                  = 363899
anon_2                  = -1
anon_3                  = -1
anon_4                  = -1
anon_5                  = -1
anon_6                  = <vector<identity_unk_94*>[0]: 0x7fffa854ee30>
anon_7                  = <vector<identity_unk_94*>[0]: 0x7fffa854ee48>
birth_year and birth_second are off by one field (histfig_id too, it is 33318).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: lethosor on December 31, 2017, 03:07:09 pm
Was that working in 0.43.05? What platform/architecture are you using? I can confirm that the size of the identity structure on 64-bit OS X is correct (176 bytes), so I'm not sure what changed.

Here are 11 identity instances from a world generated in 0.44.03. I could see "unk_4c" actually being a histfig ID for all of them, but after that, only one field is positive for some, and I don't think birth_second should be negative.
Spoiler (click to show/hide)

Edit: I got some strange values in 0.43.05 too (different world, just one identity):
Spoiler (click to show/hide)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: jecowa on December 31, 2017, 03:18:07 pm
sounds similar to bug. http://www.bay12games.com/dwarves/mantisbt/print_bug_page.php?bug_id=1178
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: lethosor on December 31, 2017, 03:32:19 pm
That may be related to identities as well, but they're almost certainly not the same issue. The issue here is (probably) DFHack's layout/names being wrong somehow. On the other hand, Toady's names for everything are right, so it's unlikely that he's mixing up a histfig ID and a year somehow. Also, it looks like at least something got added in 0.44, but the issue you linked to is from 0.31.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Clément on December 31, 2017, 03:59:17 pm
I am using both windows and linux 64 bits (linux was used for the last post values, windows may be the 0.44.03-alpha version). I don't think it is a DF bug, the date displayed in game is coherent with birth_year = 118, birth_second = 363899.

Even your strange values moved between 0.43.05 and 0.44.03. It really looks like there is a new member before histfig_id.

About the strange value for birth_year, is it possible it is actually a union whose content depends on unk_4c value (0 for birth date)?

Edit: maybe not that simple: I have a valid birth date with unk_4c=3. On Windows 64 bits (updated to beta1), a non-vampire from this save (http://www.bay12forums.com/smf/index.php?topic=168411.msg7655021#msg7655021), Rel Anoeslik is lying about his name but not about his age.
Code: [Select]
[lua]# ~df.identity.find(2541)
<identity: 000000003AC6ECD0>
id                       = 2541
name                     = <language_name: 000000003AC6ECD8>
race                     = 495
caste                    = 1
histfig_id               = -1
unk_4c                   = 38030
birth_year               = 3
birth_second             = 131
anon_1                   = 127964
anon_2                   = -1
anon_3                   = 1889
anon_4                   = 132
anon_5                   = 828
anon_6                   = <vector<identity_unk_94*>[0]: 000000003AC6ED80>
anon_7                   = <vector<identity_unk_94*>[0]: 000000003AC6ED98>
[lua]# ~df.historical_figure.find(38030)
<historical_figure: 000000006C14DA90>
profession               = 79
race                     = 495
caste                    = 1
sex                      = 1
orientation_flags        = <orientation_flags: 000000006C14DA98>
appeared_year            = 131
born_year                = 131
born_seconds             = 127964
curse_year               = -1
curse_seconds            = -1
birth_year_bias          = 0
birth_time_bias          = 0
old_year                 = -1
old_seconds              = -1
died_year                = -1
died_seconds             = -1
name                     = <language_name: 000000006C14DAC8>
civ_id                   = 894
population_id            = 844
breed_id                 = -1
cultural_identity        = -1
anon_1                   = 6597
flags                    = <BitArray<>: 000000006C14DB58>
unit_id                  = 5126
unit_id2                 = 5126
id                       = 38030
unk4                     = 0
entity_links             = <vector<histfig_entity_link*>[6]: 000000006C14DB78>
site_links               = <vector<histfig_site_link*>[0]: 000000006C14DB90>
histfig_links            = <vector<histfig_hf_link*>[6]: 000000006C14DBA8>
info                     = <historical_figure_info: 000000006C302ED0>
unk_f0                   = nil
unk_f4                   = nil
unk_f8                   = nil
unk_fc                   = nil
unk_100                  = 0
unk_v4019_1              = -1
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: martinuzz on December 31, 2017, 05:21:19 pm
I have a visitor goblin animal caretaker, part of a visiting troop of performers. He has been running from location to location with a constant 'no job' for a few years now, and I think he is both blocking his troupe from leaving, as well as blocking any visiting troops from applying for semi-resident status.

I downloaded DT in hopes of fixing him somehow, only to find out DT doesn't deal with visitors.

Is there any way I can use DFHack to get rid of this goblin? Preferably just snap him out of it, but if all else fails, how do kill?

EDIT: nvm, found out how exterminate works
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: PatrikLundell on December 31, 2017, 08:38:57 pm
@martinuzz:
I've used this script in the past:
Spoiler (click to show/hide)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Max™ on December 31, 2017, 09:51:47 pm
Looks like anon_2 and anon_3 under nemesis[k].figure.info.relationships[v] in a given unit are the same as the reputation.wanted[k].type and .level with the same values/effects on fame when edited:
(https://i.imgur.com/hWgPrFS.png)
I just figured it out, and I will provide insight on what I think happened.
How I got it unstuck: I pressed the enter key in the DFHack menu.

What I think happened: I had earlier typed "ls" so i could see the command list. The command list was printed, and the line immediately after was blinking _, as what I would normally expect.
When i tried saving, the game got stuck in not-responding, and DF was using no processor resources. I was a bit confused, so I waited a long while with no progress.
I then pressed enter in the DFHack window. This caused the display to change as so:
(https://cdn.discordapp.com/attachments/209085745166680065/396863848503836672/unknown.png)
My deduction here is this: the "ls" script continues running until after enter is pressed again. This prevents "clearing animal hospitals" or any other number of "it's time to save" subroutines from going through. This stalls Dwarf Fortress itself from performing any saving.
Luckily, I didn't close DF before I figured this out, so my save is safe!

Question though, can I safely paste the new DFHack version over my DF Folder that has the alpha version on it? This experience has made me crave some of those new bugfixes.
Dwarvet drives me nuts in adventure mode so I just delete it when I do a new dfhack version, I wonder if it wasn't the source of the hang as it runs at times when it never needs (travel mode changes?), and yeah it'll just drop into the relevant folders fine, I copy over my scripts since I've got personal projects/variations in there but other than that it's easy as that.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Rumrusher on January 01, 2018, 09:46:10 am
what does Dwarvet do anyway? was there a bug that consistently spawn animal hospitals in DF that never to this day got patched out?
other than that
 I take it if folks want fame they have to build a personal relationship? this might make solving the issue of getting folks to become your hearthperson alot eaiser or moving up in noble ranks.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Max™ on January 01, 2018, 10:52:08 am
Yeah, but the personal store of rep doesn't seem to track everything properly either, and people don't seem to care about the entity linked fame since I previously tried making myself a legendary hero/hunter/bandit slayer/artifact finder and all via the reputation fields for shit effect, but doing it to a direct relationship field worked as seen above.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Kat on January 01, 2018, 02:10:17 pm
what does Dwarvet do anyway?

allows your medics to treat injured animals, in a zone marked as hospital & animal training zone iirc.

otherwise, your animals only heal very slowly on their own.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Rumrusher on January 01, 2018, 09:32:20 pm
Yeah, but the personal store of rep doesn't seem to track everything properly either, and people don't seem to care about the entity linked fame since I previously tried making myself a legendary hero/hunter/bandit slayer/artifact finder and all via the reputation fields for shit effect, but doing it to a direct relationship field worked as seen above.
so in a odd way adventurers can get into a relationship, it kinda tied to your fame.
so the game plan isn't to do a bunch of quests for a bunch of random folks but to instead to a bunch of quest for a Really really important person to butter them up and gain favors like your wooing them with your feats.
wait doesn't that mean since it's a relationship affair you could get an adventurer to be someone's hero/hunter/bandit slayer/artifact finder in the relationship tab? like how if you trade with a player fort citizen they will add the adventurer down as "good for business" in their relationship list.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Roses on January 02, 2018, 10:14:40 pm
Question time!

1. I know that the equip-item script can be used to put pretty much any item on any unit, but does it actually have an effect? If I put a helmet on a dog will it actually help protect it's head? Will the dog even keep it equipped, or will it just unequip it right away?

2. Does the equip-script and item-trigger play well with each other?

3. With the addition of the SYN_CONCENTRATION_ADDED and SYN_IDENTIFIER and such, does the add-syndrome script correctly add concentrations and respect the dilution factors?

4. I'm not sure add-syndrome is working correctly for syndromes that add effects like bleeding, or for syndromes that have targeted body parts. It seems that a syndrome applied normally from in-game comes with a wound that actually does the targeting/bleeding/etc... Has anyone else noticed this or am I just doing something wrong?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Boltgun on January 03, 2018, 06:39:26 am
Question time!

1. I know that the equip-item script can be used to put pretty much any item on any unit, but does it actually have an effect? If I put a helmet on a dog will it actually help protect it's head? Will the dog even keep it equipped, or will it just unequip it right away?

2. Does the equip-script and item-trigger play well with each other?

3. With the addition of the SYN_CONCENTRATION_ADDED and SYN_IDENTIFIER and such, does the add-syndrome script correctly add concentrations and respect the dilution factors?

4. I'm not sure add-syndrome is working correctly for syndromes that add effects like bleeding, or for syndromes that have targeted body parts. It seems that a syndrome applied normally from in-game comes with a wound that actually does the targeting/bleeding/etc... Has anyone else noticed this or am I just doing something wrong?

I'm on the same issue with add-syndrome. Syndrome-util is setting wound_id to -1 and I guess that it prevent a lot of symptoms from working. We had the same issue in 0.34 and is was fixed by creating a fresh wound (as far as my memory goes).

Interactions are not working either when added with add-syndrome. Perhaps there is more to insert that the list of symptoms. I need to compare in gm-editor a naturally infected creature with a dfhack infected one to check this.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: buuface on January 03, 2018, 09:44:07 pm
Hi guys is there a way to force a siege to end?

I have a bug whereby I was besieged by goblins who immediately seem to have left the map (I searched everywhere for them including using the 'reveal' hack) but the *SIEGE* tag remains.

Is there a way I can use DFhack to force this status to end? Looked in the commands list but couldn't see anything.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Kat on January 03, 2018, 10:26:59 pm
Hi guys is there a way to force a siege to end?

I have a bug whereby I was besieged by goblins who immediately seem to have left the map (I searched everywhere for them including using the 'reveal' hack) but the *SIEGE* tag remains.

Is there a way I can use DFhack to force this status to end? Looked in the commands list but couldn't see anything.

Try fix/retrieve-units

this might clear the siege, or force the goblins to enter.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Roses on January 04, 2018, 06:58:26 pm
I'm on the same issue with add-syndrome. Syndrome-util is setting wound_id to -1 and I guess that it prevent a lot of symptoms from working. We had the same issue in 0.34 and is was fixed by creating a fresh wound (as far as my memory goes).

Interactions are not working either when added with add-syndrome. Perhaps there is more to insert that the list of symptoms. I need to compare in gm-editor a naturally infected creature with a dfhack infected one to check this.

Interactions aren't working either? Hmm, I hope we can get that fixed. I use interactions from syndromes a lot.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Meph on January 05, 2018, 01:53:42 am
It's one of the reasons I never updated the interaction-heavy warlocks/necromancers to the newer df.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: strainer on January 05, 2018, 08:36:35 am
Im stuck on how to get a list of units dieties to show such info in my manipulator extension. Has anyone done this in cpp or lua? Units have a little array called relationship_ids which only lists a few relationships like pet,father,mother. There is a "unit_relationship_type" enum which continues to list many more interesting relationships like friend, grudge, worship, hero.. but I cant find the keys which that could be for. Maybe its unimplemented or found in historical figure data?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: PatrikLundell on January 05, 2018, 10:41:25 am
Im stuck on how to get a list of units dieties to show such info in my manipulator extension. Has anyone done this in cpp or lua? Units have a little array called relationship_ids which only lists a few relationships like pet,father,mother. There is a "unit_relationship_type" enum which continues to list many more interesting relationships like friend, grudge, worship, hero.. but I cant find the keys which that could be for. Maybe its unimplemented or found in historical figure data?
You're referring back to something undefined ("such info") so it's hard to understand what you're after. Deities worshiped by units can be found via the relations (I believe this thread had an exercise where a fortress' deities were located, plus those of citizens "imported" from elsewhere).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: lethosor on January 05, 2018, 10:57:00 am
Yeah, it might be a histfig relationship or something. I can't check myself for a while, though. I don't think it hasn't been identified, though.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: strainer on January 05, 2018, 03:16:42 pm
Its curious the unit_relationship_type enum has loads of relations including worship, grudge, hero, aunt..  but the relationship_ids structure under unit is just an int array of the first 9 enums, which even if it were longer couldnt store multiple relations of same type.

Ive dug around quite a bit looking for a vector that includes the other relations, and ive dug around looking for code or conversation on those other relations but no luck yet.

Gods are historical figures, there is a script to make them but it cant assign them to anyone.

I read that df rejigged the relations info in v43 maybe the defs havent quite caught it all yet.

In getNemesis(unit)->figure->info->relationships->... there are 4 half-anon lists with more anon vectors inside them.

I will have a look at legends viewer source next it should have a handle on gods and things...
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: strainer on January 06, 2018, 03:32:23 am
So there is a vector under historical figure called histfig_links, with elements containing "target_hf" and "link_strength" but puzzlingly no link_type.

Then we have headers concerning these links, for various link_types including dieties. eg.

..include\df\histfig_hf_link_deityst.h

...seems there is a whole feature Ive been unaware of, I may be able to just do:

Code: [Select]
if(histfig_links[i]->getType() == df::histfig_hf_link_type::DEITY) { .... }
Fingers crossed for that. Im nearly ready to start trying to compile an unwieldy heap of modifications now.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Quietust on January 06, 2018, 07:40:34 am
So there is a vector under historical figure called histfig_links, with elements containing "target_hf" and "link_strength" but puzzlingly no link_type.

Then we have headers concerning these links, for various link_types including dieties. eg.

..include\df\histfig_hf_link_deityst.h

Ive no idea how these access the fh_link types and dont find this used anywhere in dfhack repo, but i found a lua snippet online using them
...seems there is a whole feature Ive been unaware of, I may be able to just do:

if(histfig_links->getType() == df::histfig_hf_link_type::DEITY) { .... }

Fingers crossed for that. Im nearly ready to start trying to compile an unwieldy heap of modifications now.
The histfig_hf_link class is polymorphic - its type is determined not by reading a variable but by executing code. Many other object types in DF work exactly the same way - item, building, and general_ref, just to name a few.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: strainer on January 06, 2018, 07:49:27 am
Thanks Quietust - this should relieve me of much future puzzling !
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Boltgun on January 06, 2018, 08:11:27 am
I'm on the same issue with add-syndrome. Syndrome-util is setting wound_id to -1 and I guess that it prevent a lot of symptoms from working. We had the same issue in 0.34 and is was fixed by creating a fresh wound (as far as my memory goes).

Interactions are not working either when added with add-syndrome. Perhaps there is more to insert that the list of symptoms. I need to compare in gm-editor a naturally infected creature with a dfhack infected one to check this.

Interactions aren't working either? Hmm, I hope we can get that fixed. I use interactions from syndromes a lot.

Did some more research by comparing a spawned unit in arena mode with the secret (interactions work ok) with one that received the syndrome.
The wound is properly created (in 'body') by DF when the syndrome is added. It contain a curse info with all the proper data, said curse is then applied to the unit.
The only divergence was the lack of a reinfection id and count, but after modifying syndrome-util to add it, nothing changed.

Everything in body, in curse and in syndrome is adequate. I'm still searching...
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: KittyTac on January 06, 2018, 08:21:35 am
Can you guys make me a script that makes hostilities between companions cease?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: strainer on January 06, 2018, 09:31:01 am
Id guess not without brainwashing them all to be pacifist KittyKat. Though Im trying to include enough information in the labors screen to tell what is winding them up.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: KittyTac on January 06, 2018, 10:41:24 am
Id guess not without brainwashing them all to be pacifist KittyKat. Though Im trying to include enough information in the labors screen to tell what is winding them up.

I meant adv mode. No labors screen there.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Boltgun on January 06, 2018, 04:34:26 pm
Did some more research by comparing a spawned unit in arena mode with the secret (interactions work ok) with one that received the syndrome.
The wound is properly created (in 'body') by DF when the syndrome is added. It contain a curse info with all the proper data, said curse is then applied to the unit.
The only divergence was the lack of a reinfection id and count, but after modifying syndrome-util to add it, nothing changed.

Everything in body, in curse and in syndrome is adequate. I'm still searching...

Quoting myself, but after figuring it out I believe you might be interested.
Dfhack wise, the syndrome is properly added as far as interaction goes. But Kruggsmash made a video about turning dwarves into necromancers so I knew that it had to work.
I tested with an inhaled stone that provides interactions and the units were not using it either, so taking inspiration from generated necromancy I removed usage hints and it worked.

As it seems, ATTACK is not working anymore, but no hint now has the same effect (instead of "all the time" from 0.34) and the unit will use the interaction in combat. The arena does not respect those rules, so it's probably a bug. Mystery... kinda solved, I guess?

Spoiler: The interaction (click to show/hide)

It is added with :
Code: [Select]
local synName = 'Pyromaniac (fireballs, directed ash, firejet)'
dfhack.run_script('modtools/add-syndrome', '-target', unit.id, '-syndrome', synName, '-resetPolicy', 'DoNothing')

That does not explain issues with bleeding or drowsiness. Those symptoms are a little complicated as those counters were not in body, probably in body parts. Again, it is worth testing it with inhalation before going further.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Max™ on January 06, 2018, 07:14:32 pm
Its curious the unit_relationship_type enum has loads of relations including worship, grudge, hero, aunt..  but the relationship_ids structure under unit is just an int array of the first 9 enums, which even if it were longer couldnt store multiple relations of same type.

Ive dug around quite a bit looking for a vector that includes the other relations, and ive dug around looking for code or conversation on those other relations but no luck yet.

Gods are historical figures, there is a script to make them but it cant assign them to anyone.

I read that df rejigged the relations info in v43 maybe the defs havent quite caught it all yet.

In getNemesis(unit)->figure->info->relationships->... there are 4 half-anon lists with more anon vectors inside them.

I will have a look at legends viewer source next it should have a handle on gods and things...
The stuff under info.relationships also contains duplicates of stuff under info.reputation.wanted[k] like type and level, changing those values are how I did my reputation experiment:
Looks like anon_2 and anon_3 under nemesis[k].figure.info.relationships[v] in a given unit are the same as the reputation.wanted[k].type and .level with the same values/effects on fame when edited:
Spoiler (click to show/hide)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Roses on January 06, 2018, 07:51:51 pm
Did some more research by comparing a spawned unit in arena mode with the secret (interactions work ok) with one that received the syndrome.
The wound is properly created (in 'body') by DF when the syndrome is added. It contain a curse info with all the proper data, said curse is then applied to the unit.
The only divergence was the lack of a reinfection id and count, but after modifying syndrome-util to add it, nothing changed.

Everything in body, in curse and in syndrome is adequate. I'm still searching...

Quoting myself, but after figuring it out I believe you might be interested.
Dfhack wise, the syndrome is properly added as far as interaction goes. But Kruggsmash made a video about turning dwarves into necromancers so I knew that it had to work.
I tested with an inhaled stone that provides interactions and the units were not using it either, so taking inspiration from generated necromancy I removed usage hints and it worked.

As it seems, ATTACK is not working anymore, but no hint now has the same effect (instead of "all the time" from 0.34) and the unit will use the interaction in combat. The arena does not respect those rules, so it's probably a bug. Mystery... kinda solved, I guess?

Spoiler: The interaction (click to show/hide)

It is added with :
Code: [Select]
local synName = 'Pyromaniac (fireballs, directed ash, firejet)'
dfhack.run_script('modtools/add-syndrome', '-target', unit.id, '-syndrome', synName, '-resetPolicy', 'DoNothing')

That does not explain issues with bleeding or drowsiness. Those symptoms are a little complicated as those counters were not in body, probably in body parts. Again, it is worth testing it with inhalation before going further.

Interesting results, I wonder why USAGE_HINT:ATTACK isn't working anymore. Was that information anywhere in the change logs? I think I need to start doing all my testing in fortress mode, it seems arena mode has some issues.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: lethosor on January 06, 2018, 08:36:08 pm
Thanks Quietust - this should relieve me of much future puzzling !
You can also use df.type.is_instance() instead of link:getType():
Code: [Select]
unit = dfhack.gui.getSelectedUnit()
for _, link in ipairs(df.historical_figure.find(unit.hist_figure_id).histfig_links) do
    if df.histfig_hf_link_deityst:is_instance(link) then
        deity = df.historical_figure.find(link.target_hf)
        -- do something with deity
    end
end
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: dragdeler on January 06, 2018, 10:15:09 pm
There seems to be a problem where working pumps don't pump, after you changed a tile upon which a machine part lies with "tiletypes".

god that'll teach me not to cheat instead of spending a day to do minor improvements... i'm so done
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Pvt. Pirate on January 07, 2018, 04:39:45 am
i got problems with mousequery not responding to the mouse being in the bottom or right border.
this did not occur in 43.x.x but only in 44.x.x
i'm using a 5:4 screen and running DF windowed 1280x960.
maybe there's something wrong with the calculation of the position and/or size of the areas for mouse scrolling.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: iceball3 on January 07, 2018, 05:12:33 am
Also, I'll test it again tomorrow, but I'm pretty sure that the stonesense bundled in dfhack is currently non-functional. Wouldn't even close when i tried to force it to, aside from closing DF.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: KittyTac on January 07, 2018, 08:05:39 am
Can you write me a script that teleports you in adv mode to the cursor with "l"? It would make navigating laggy areas more bearable.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Quietust on January 07, 2018, 08:50:46 am
Thanks Quietust - this should relieve me of much future puzzling !
You can also use df.type.is_instance() instead of link:getType():
Code: [Select]
unit = dfhack.gui.getSelectedUnit()
for _, link in ipairs(df.historical_figure.find(unit.hist_figure_id).histfig_links) do
    if df.histfig_hf_link_deityst:is_instance(link) then
        deity = df.historical_figure.find(link.target_hf)
        -- do something with deity
    end
end
You can, but it's generally much more efficient to use .getType() - the only time you really need to use is_instance is when you're dealing with a class that doesn't have a .getType() vmethod (e.g. a Viewscreen).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: mifki on January 07, 2018, 09:09:23 am
Thanks Quietust - this should relieve me of much future puzzling !
You can also use df.type.is_instance() instead of link:getType():
Code: [Select]
unit = dfhack.gui.getSelectedUnit()
for _, link in ipairs(df.historical_figure.find(unit.hist_figure_id).histfig_links) do
    if df.histfig_hf_link_deityst:is_instance(link) then
        deity = df.historical_figure.find(link.target_hf)
        -- do something with deity
    end
end
You can, but it's generally much more efficient to use .getType() - the only time you really need to use is_instance is when you're dealing with a class that doesn't have a .getType() vmethod (e.g. a Viewscreen).

I always use instance._type myself. It should be the most efficient as it's already populated, and doesn't depend on getType() availability.

Obviously the main difference between all this and is_instance() is that the latter can be used to check if an instance is of a subclass of a base class, but I don't think this is ever needed, so it's an overkill.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: strainer on January 07, 2018, 09:40:34 am
I think is_instance is nice and descriptive, but here Im getting the type of each hflink and switching on it to grow a digest which is part of making a condensed 2 or 3 line description of the units circumstances, likes, strongest traits and beliefs. Think im still missing a few like 'friendly terms' though, leaving this for now...

The info displays while the unit is focused in the list so they can be browsed without rifling through other screens. If the process runs fast enough ill do it for the whole list when screen is loaded so efficiency is relevant, if it causes any delay for maybe a couple of hundred units, it can run individually on the units the first time they are focused.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: strainer on January 08, 2018, 05:25:24 am
Just to note - I havent found the relationships of friends, friendly terms, aquaintances, or detailed family relations though those could be constructed from mother,father and children which appear in figure.histfig_links. Aunts, cousins, grandfather, "SonEldest5" ... etc are enumed in histfig_relationship_type.h (which is not the type of histfig_links).

Some more correctly enumed relations like enemy and squad members appear in figure->entity_links

There is a small flat array in unit named relationship_ids which only contains refs to 10 things like mother, father, pet, ridermount. These are the first 10 enums in unit_relationship_type.h. Perhaps that array is longer than currently defined, but it doesnt seem capable of containing multiple links of same type anyhow. Maybe its just a small cache of those first 10 rels.

Finally? there is a figure.info.relationships.list which looks a likely suspect, but is mostly anonymous as yet.

Seems like an area to look out for / fill out in the future.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: iceball3 on January 08, 2018, 06:51:59 am
Hmm, just had a sudden "hard close". Not exactly sure what caused it.
Has taverns or missions been tested with DFhack yet?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: strainer on January 08, 2018, 08:18:33 am
I found a bugged save after a hard close can possibly be fixed by escaping immediately after load, selecting export local image, and cycling through the levels. Then the game might save again and be playable, to observe the hard close again...
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: lethosor on January 08, 2018, 01:09:54 pm
There is a small flat array in unit named relationship_ids which only contains refs to 10 things like mother, father, pet, ridermount. These are the first 10 enums in unit_relationship_type.h. Perhaps that array is longer than currently defined, but it doesnt seem capable of containing multiple links of same type anyhow. Maybe its just a small cache of those first 10 rels.
It cannot be longer than it is currently, because if that were the case, everything following it (including unit.job, unit.body, unit.counters, unit.status, and more) would be wrong, because it's a C array ("int32_t relationship_ids[10];" in df/unit.h).

Hmm, just had a sudden "hard close". Not exactly sure what caused it.
Has taverns or missions been tested with DFhack yet?
I think the word you're looking for is "crash". There aren't any other situations I can think of where DF would suddenly close except when it crashes.
As for your question, are you asking if DFHack not being tested with taverns/missions could be the cause of the crash? If so, the answer is almost certainly no, because if DFHack research hasn't been done on those things, nothing in DFHack can possibly touch them (unless layouts of globals like "world" are wrong, but those have been fixed for 0.44). Also, taverns were new in 0.42, so they're not likely to be a cause of any new bugs/crashes related to DFHack at this point.

I found a bugged save after a hard close can possibly be fixed by escaping immediately after load, selecting export local image, and cycling through the levels. Then the game might save again and be playable, to observe the hard close again...
If DF crashes, it will not touch the actual save folder itself at all (it saves temporary files to data/save/current, but ignores them when you restart DF). In other words, a crash (except when saving the game) will not permanently affect your save. I highly doubt that exporting images has anything to do with a crash, because that feature pretty much only reads from the map and hasn't been changed in years. If you think you observed it affecting a crash in some way, then that crash is probably due to undefined behavior somewhere, which means that exporting a map could affect it somehow, sometimes, if you're lucky, due to any number of semi-random factors (that could vary depending on your system, etc.). And I know I'm being pedantic, but please don't be afraid to use the word "crash" - it's a lot easier to search for.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Max™ on January 08, 2018, 01:34:19 pm
Can you write me a script that teleports you in adv mode to the cursor with "l"? It would make navigating laggy areas more bearable.
Write one for you, personally?

Absolutely not.

Already have one?

Probably.
Code: (flashstep.lua) [Select]
--Teleports unit to cursor
--[====[

flashstep
=========
A hotkey-friendly teleport that places you where your cursor is.

]====]
function flashstep(flash,step)
    local flash = df.global.world.units.active[0]
    local step
        if df.global.ui_advmode.menu == df.ui_advmode_menu.Look then
            step = df.global.cursor
        else
            qerror("No [l] cursor located! You kinda need it for this script.")
        end
    local unitoccupancy = dfhack.maps.getTileBlock(flash.pos).occupancy[flash.pos.x%16][flash.pos.y%16]
        flash.pos.x = step.x
        flash.pos.y = step.y
        flash.pos.z = step.z
            if flash.pos.x==step.x then
            local stepvisibility = dfhack.maps.getTileBlock(flash.pos).designation[flash.pos.x%16][flash.pos.y%16]
                stepvisibility.hidden=false
            end
    if not flash.flags1.on_ground then unitoccupancy.unit = false else unitoccupancy.unit_grounded = false end
end
flashstep(flash,step)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: strainer on January 08, 2018, 02:31:43 pm
Lethosor:   "Maybe its just a small cache of those first 10 rels." - It *cannot* be longer than it is currently, ...

Ok, thats something. We all still seem to be in the situation that *no one here knows* where to find units friends, friendly terms, aquaintances... And whatever info is in figure.info.relationships.links is unkeyed.

Im just putting that info as I find it, here, for others to notice, or duckduckgo later.

Lethosor: a crash (except when saving the game) will not permanently affect your save.

I wouldnt have expected it to because I noticed task-killing a game is usually fine, but I have bugged dozens of game saves, with silly division by zero, infinite loops or null pointer crashes occuring while in manipulator (while not doing any saving). I dont know the mechanism but a hard crash while in manipulator, on linux, can kill a save, and the process I described can repair it (not necessary to actually export the levels, just scan through them - maybe even just open and close the feature).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: lethosor on January 08, 2018, 03:40:59 pm
Lethosor:   "Maybe its just a small cache of those first 10 rels." - It *cannot* be longer than it is currently, ...

Ok, thats something. We all still seem to be in the situation that *no one here knows* where to find units friends, friendly terms, aquaintances... And whatever info is in figure.info.relationships.links is unkeyed.

Im just putting that info as I find it, here, for others to notice, or duckduckgo later.

Lethosor: a crash (except when saving the game) will not permanently affect your save.

I wouldnt have expected it to because I noticed task-killing a game is usually fine, but I have bugged dozens of game saves, with silly division by zero, infinite loops or null pointer crashes occuring while in manipulator (while not doing any saving). I dont know the mechanism but a hard crash while in manipulator, on linux, can kill a save, and the process I described can repair it (not necessary to actually export the levels, just scan through them - maybe even just open and close the feature).
figure.info.relationships.links might be it, although I'm seeing garbage for year_tick (0xaaaaaaaa, which means it's uninitialized in my setup), so that structure might be off a bit.

I can guarantee that you did not corrupt your save by doing anything in manipulator. If it crashes, any modifications you made to the save are gone. Back before there was a data/save/current folder (around 23a), crashes and killing DF could corrupt saves, because everything was written to the region folder, but that's no longer the case. If you saved files yourself, though (like custom profession files), those might be corrupted somehow. Anyway, you're probably just getting lucky with the map-export feature. I can't think of a way it would affect anything else, but bugs due to undefined behavior can be affected by doing unrelated things sometimes, if you get lucky.

Just to clarify, what exactly is wrong with these "bugged saves" you have? Do they crash at some point soon after loading, or do they exhibit some other bug(s)? Particularly if it's the former, I'd like to take a look at one of these saves.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Putnam on January 08, 2018, 03:50:21 pm
Can you write me a script that teleports you in adv mode to the cursor with "l"? It would make navigating laggy areas more bearable.
Write one for you, personally?

Absolutely not.

Already have one?

Probably.
Code: (flashstep.lua) [Select]
--Teleports unit to cursor
--[====[

flashstep
=========
A hotkey-friendly teleport that places you where your cursor is.

]====]
function flashstep(flash,step)
    local flash = df.global.world.units.active[0]
    local step
        if df.global.ui_advmode.menu == df.ui_advmode_menu.Look then
            step = df.global.cursor
        else
            qerror("No [l] cursor located! You kinda need it for this script.")
        end
    local unitoccupancy = dfhack.maps.getTileBlock(flash.pos).occupancy[flash.pos.x%16][flash.pos.y%16]
        flash.pos.x = step.x
        flash.pos.y = step.y
        flash.pos.z = step.z
            if flash.pos.x==step.x then
            local stepvisibility = dfhack.maps.getTileBlock(flash.pos).designation[flash.pos.x%16][flash.pos.y%16]
                stepvisibility.hidden=false
            end
    if not flash.flags1.on_ground then unitoccupancy.unit = false else unitoccupancy.unit_grounded = false end
end
flashstep(flash,step)

you could also use dfhack's teleport script both to get your adventurer's ID and to teleport your adventurer that way
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: lethosor on January 08, 2018, 03:51:37 pm
you could also use dfhack's teleport script both to get your adventurer's ID and to teleport your adventurer that way
I think the "more bearable" part implied that the teleport script was annoying to use (which is fair - gui/teleport is nicer, in my opinion, but only works in fortress mode).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: strainer on January 08, 2018, 04:26:39 pm
Lethosor:

>Just to clarify, what exactly is wrong with these "bugged saves" you have?

I do find them strange, I can make them easily, just put a div by zero or something in manipulator, open it, df crashes, fix manipulator, next time I open the save it can crash seconds after loading, even while paused, or run for a few seconds unpaused before crashing, it wont save again. I would kick myself if it was a good game and then found through trial that 'export' proceedure can straighten it out somehow enough so it saves, and then runs again. I dont expect its very interesting, maybe just some out of sync temp file or something, but I can make one and zip it up this week if you're curious.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Max™ on January 08, 2018, 06:19:14 pm
you could also use dfhack's teleport script both to get your adventurer's ID and to teleport your adventurer that way
I think the "more bearable" part implied that the teleport script was annoying to use (which is fair - gui/teleport is nicer, in my opinion, but only works in fortress mode).
Yeah, in adventurer mode there is no reason to have a script which needs to be aimed but doesn't use the cursor. I can move myself around with gui/gm-editor easily enough too, or I can hit a keybind and poof over to where my cursor is currently.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: PatrikLundell on January 08, 2018, 06:29:07 pm
I still don't understand what strainer is looking for, but it sounds like something along the lines of this:

Spoiler (click to show/hide)

The snipped of a (unfinished) script gets reasonably close to what's shown on the relations screen, but doesn't get it correct all the time, and it also lists relations suppressed from that screen (but obviously present in df). I assume strainer is actually looking for something else, though.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: lethosor on January 08, 2018, 11:44:03 pm
Yeah, no idea what's going on there. What files are you overwriting when you reinstall DFHack? It could be some sort of configuration thing. I'd expect that to be related to data/init/init.txt, though, which DFHack doesn't include.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Rose on January 08, 2018, 11:47:37 pm
If you right click in the dfhack window to select something during bootup, that can prevent the game from starting till you right click again.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Isher on January 09, 2018, 12:05:39 am
When you build the source of DFHack, is that when the header files in  dfhack>library>include>df are created? Or do I get those from somewhere else?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: lethosor on January 09, 2018, 12:09:15 am
When you build the source of DFHack, is that when the header files in  dfhack>library>include>df are created?
Yes. Specifically, it's the "generate_headers" target, or the one that generates codegen.out.xml.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Rose on January 09, 2018, 12:11:42 am
Note that this is why dfhack relies on perl.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: strainer on January 09, 2018, 04:21:30 am
"the header files in  dfhack/library/include/df are created ..."

Heh, I spent quite a while puzzled why I couldnt grep any header info, as I was writing and compiling on different machines.

PatrikLundell wrote:
"I still don't understand what strainer is looking for"

I was looking for where units deities are stored, which I found in figure.histfig_links. Im also interested in decoding all of the other unit relationships which is what I was refering to by "such info". Ive discussed the relationship info found in unit.relationship_ids and figure.histfig_links and figure.entity_links and the anon elements in figure.info.relationships.

Your code snippet is very intresting thanks, it looks like you have decoded some of anon figure.info.relationships. Ill try to use it (in the short term to make a rough count of units friends to complete a compact unit summary)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: PatrikLundell on January 09, 2018, 07:56:47 am
@strainer: Just be aware that the snippet is by no means the truth. It gets somewhat close to replicating what DF displays, but that's about it, but it might serve as a starting point. I think Fleeting Frames did a similar type of calculation using a different formula recently, but I haven't done any comparisons. I don't quite remember the context, but it might be regarding enhancements to Dwarf Manipulator info.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: strainer on January 09, 2018, 09:51:55 am
Great! Fleeting Frames has mostly decyphered the figure.info.relationships thing in relations-indicator.lua --lots of good comments too.

Thread: relations-indicator.lua (http://"http://www.bay12forums.com/smf/index.php?topic=167496.msg7567743#msg7567743")

Thanks again Patrik.

... Im noticing that there is a manipulator.lua underway which my extension of manipulator.cpp ignores. Apologies for that Ive got too far into it before noticing to switch. Maybe they can compliment each other.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: lethosor on January 09, 2018, 09:59:02 am
I still don't understand what strainer is looking for, but it sounds like something along the lines of this:

Spoiler (click to show/hide)

The snipped of a (unfinished) script gets reasonably close to what's shown on the relations screen, but doesn't get it correct all the time, and it also lists relations suppressed from that screen (but obviously present in df). I assume strainer is actually looking for something else, though.
Can you explain what the fields you used are? anon_3 appears to be some kind of weight, and anon_1 is some sort of ID, I think, but it's hard to tell at a glance. If you can make a PR at https://github.com/dfhack/df-structures, that would be even better. anon names are unreliable and generally shouldn't be used except for experimentation.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: PatrikLundell on January 09, 2018, 12:30:05 pm
I haven't made a pull request or issue out of the anon fields because I don't know what they are, only that they seem to relate to the relation strength/level in some way, and the script largely manages to match what DF produces, so it's a fair way from a usable shape (what strainer gets is basically messy half baked research notes).
I messed with that script some time during the autumn and then lost interest for various reasons, so it hasn't been used for anything by me (the script itself is basically experimentation). You've actually seen the whole script then I provided it for some help with getting other info, and made the (correct) comment that using the find operation is better than trying to roll my own bugged one (and I haven't fixed it since I haven't used the script...), but the snippet was from the end of the fairly large script and not the focus of the issue at hand.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: strainer on January 09, 2018, 02:34:21 pm
Lethosor wrote: "Can you explain what the fields you used are?"

In the relations_indicator.lua script Fleeting Frames uses anon3 ( in figure.info.relations.list(0..n) ) as a vector of 'feeling_types' with values interpreted like this:

Code: [Select]
--[[List of options I've noticed with changing that value:
0: Hero
1: Friend
2: Grudge
3: Bonded
6: Good for Business
7: Friendly Terms? (unsure)
10: Comrade
17: Loyal Soldier
18: Considers Monster (hm, could be interesting RP-wise)
26: Protector of the Weak

Others seemed to default to Friendly terms
with just few points on 7 as second relation.
Perhaps anon_1 and anon_5 may also matter.
--]]

Those values have considerable matches with
unit_relationship_type.h starting from "friend".

Like this:

Code: [Select]
enum unit_relationship_type : int16_t {
None = -1,
Pet,
Spouse,
Mother,
Father,
LastAttacker,
GroupLeader,
Draggee,
Dragger,
RiderMount,
Lover,
unk10,
Sibling,             //
Child,               //hero  xxx
Friend,              //friend 1
Grudge,              //grudge 2
Worship,             //bonded 3
AcquaintanceLong,    //4 ?
AcquaintancePassing  //5 ?
Bonded,             
Hero,
ConsidersViolent,    //4 ?
ConsidersPsychotic,  //5 ?
GoodForBusiness,     //goodfor business 6
FriendlyTerms,       //friendly terms  8
ConsidersKiller,     //8 ?
ConsidersMurderer,   //9 ?
Comrade,             //comrade 10
MemberOfRespectedGr  //11 ?
MemberOfHatedGroup,  //12 ?
EnemyFighter,        //13 ?
FriendlyFighter,     //14 ?
ConsidersBully,      //15 ?
ConsidersBrigand,    //16 ?
LoyalSoldier,        //loyal soldier 17
ConsidersMonster,    //considers monster 18
ConsidersStorytelle  //19 ?
ConsidersPoet,       //protectorofweek 20?
ConsidersBard,
ConsidersDancer,
Master,
Apprentice,
Companion,
FormerMaster,
FormerApprentice,
ConsidersQuarreler,
ConsidersFlatterer,
Hunter,
ProtectorOfTheWeak

Ive not means to resolve these properly but will try using anon3 in mean time to get freind info to complete unit descriptions which will look something like this:

Code: [Select]
'121yr fcs-2 Datos Blibberanok Expert Thrower (lv6 ap43 xp12)
 Extremely gregarious.Very adoring,rude,leisurely. Rgds Friendship++ Peace-
 Likes Surviving,platinum,shields,bolts,opposum men... Gods:Laven,Zul
 Fam 2/6 Frn 4/6 wif lvr pet kil3 loy3 gru1 pri-1 
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: PatrikLundell on January 09, 2018, 05:11:14 pm
Continuing the guessing, an anon_3 value of 7 is more likely to be AcquaintanceLong, as even grudges have a 7 as well, in which case Friendly Terms may be the fallback if there aren't any other modifiers. anon_4 seems to have the same length as anon_3 and might be some kind of strength value, but it doesn't determine the order of the Friendly Terms entries, nor whether a unit is shown on the relations screen or not.
In my one year old fortress I've got a 23 coupled with a 7 as well, though it's listed as Friendly Terms (actually I had another one on a visitor's list, but obviously I can't compare that with what the game shows).
It can be noted that Passing Acquaintances seem to have an empty anon_3 vector (Rather than something that would match up with AcquaintancePassing).
Thus, it seems the vector contains elements from another enum type that shares a lot of the values with unit_relationship_type, but not in the same order, and probably a smaller set.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: mifki on January 09, 2018, 05:53:29 pm
1. I removed everything from figure.info.relations.list, and relationships screen still showed family relationships (and other subclasses of histfig_hf_link) but "friendly terms", "passing acquaintance", and suchlike disappeared.

2. I removed everything from figure.histfig_links and all family relationships disappeared. Only Pets left (maybe something else for other units).

3. I removed unit.relationship_ids.Pet from pets and they disappeared.

.anon_3 indeed looks like unit_relationship_type values starting with Friend.
.anon_5 controls the position on relationships screen.
.anon_4 have no idea.

Actually, I think .anon_4 is indeed some sort of relationship level or a counter, well, it has to be. If a unit is a Friend with someone, .anon_3 will have two entries - Friend and Friendly Terms. If I set .anon_4 for Friend entry to 0, the relationship stops showing as Friend and is shown as Friendly Terms. I thought maybe the game would remove Friend type eventually if I decrease its value but that didn't happen (so far).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: PatrikLundell on January 10, 2018, 05:15:43 am
I've now seen Friend, Grudge, and Bonded matching 1, 2, 3 in anon_3. I've also seen visitors that have Friend without AcquaintanceLong (7), although I've seen cases where the same visitor has both (1) and (1, 7) entries.
I've seen a number of 23 entries both as (1, 7, 23) and (7, 23), but still don't know what 23 is. In at least one case the person was the spouse.
The primary control for order seems to be Friend/Grudge/Bonded, and within that group the order was in HF Id order on the cases I examined.
Once the Friend/Grudge/Bonded cases have been dealt with the first control for order seems to be anon_5, as mifki said, with HF Id controlling the order when the anon_5 value is the same.
AcquaintanceLong (7) entries with an anon_5 value of 0 seem to be suppressed from display.
Passing Acquaintances again seem to be sorted first on anon_5 and then on HF Id.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: mifki on January 10, 2018, 05:40:04 am
I've seen a number of 23 entries both as (1, 7, 23) and (7, 23), but still don't know what 23 is. In at least one case the person was the spouse.

What's the problem with 23? Just change any of the links to have this type or remove 1 and 7 in your case. For me it gives "Considers Quarreler".
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: PatrikLundell on January 10, 2018, 05:47:13 am
Thanks mifki. So far I've just observed, not changed anything.

Anyway, this seems to sort the units in the same order as DF does (just checked on a small number of units, though).
Spoiler (click to show/hide)

It's quite possible there are additional cases not covered by this.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: strainer on January 10, 2018, 06:59:52 am
Spouse ConsideredQuarreller - hehehe

Thanks for resolving these - impressive!

A summary:

If we skip master to formerApprentice (which are in histfig_links ), looks like the 'feelingType' has a clear run with the enum from FriendlyTerms/Frienemy, to the last: ProtectorOfTheWeak.

Just values 4,5,6 are ~~left unindicated~~. Theyre considersviolent,  consdrpsychotic, goodforbiz

The anons would be:
anon3 - feeling
anon4 - counter  //~experience
anon5 - position //listing

This is like the 'social memory' of the units. To think this directs their interactions and emotions generated between them (170 of them! in emotion_type.h) The games relationship listing seems just the surface overview.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: mifki on January 10, 2018, 07:13:31 am
I missed the start of this - why did you want to be able to get this data?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: PatrikLundell on January 10, 2018, 07:54:27 am
strainer wants it for a compact description (about 10 posts up). I originally wanted it to see gremlin relationships (in the unlikely case I'll ever get two of opposite genders with less than 10 years age difference who are willing to marry the opposite gender again).
Apart from that, there is also the general reason that it hasn't been mapped properly yet (DF hackers abhor an information vacuum)...

I suspect anon_4 is some kind of counter/experience/weight thing, as strainer said. It's possible it might tick over and bump anon_5 at some time somehow, but that's a pure guess.

In the past I've seen units climb in the relations list as a result of pre nuptial treatment, and I've also seen the relation drop in the list for a deceased relation, but I didn't do any investigation beyond the vanilla DF screens in either case.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: strainer on January 10, 2018, 09:49:35 am
mifki: why did you want to be able to get this data?

Ive done a big extension of the lmanager screen 'manipulator' to include a list mode for units mental and physical attributes, and which does nice coloring of all the labors to show how good the dwarf will be at doing them (which is a bit OP actually because dorfs with right attributes for jobs do MUCH better a them) And im adding a three line description option which for the current focused unit will relate its strongest traits, its goal, its likes, gods, its 'regards' (the things that can confict with traits), focus, cavedin... and an idea of how popular it is, and how much family it has. Should look something like this:

Code: [Select]
'121yr fcs-2 Datos Blibberanok Expert Thrower (lv6 ap43 xp12)
 Extremely gregarious.Very adoring,rude,leisurely. Rgds Friendship++ Peace-- Mirth+
 Likes Surviving,Outwork+,platinum,shields,a fabric,opposum men...   Gods:Laven,Zul
 Fam 2/6 Frn 4/6 wif lvr pet kil3 loy3 gru1 pri-1 

I put some screenshots up in this post (http://"http://www.bay12forums.com/smf/index.php?topic=164123.msg7644962#msg7644962")

Its got a limited cheat mode for rearranging skill points after embark, and a deeper one for unlimited skill changing. The highlight colors are moddable with a theme file. The sorts are going to be much improved with this latest info - no sadistic medics, fanciful performers etc.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: lethosor on January 10, 2018, 11:02:28 am
i got problems with mousequery not responding to the mouse being in the bottom or right border.
this did not occur in 43.x.x but only in 44.x.x
i'm using a 5:4 screen and running DF windowed 1280x960.
maybe there's something wrong with the calculation of the position and/or size of the areas for mouse scrolling.
Mousequery hasn't changed at all. What specific mousequery feature are you referring to? "mousequery edge"? Are you using TWBT, and if so, does the issue occur with DFHack's (not TWBT's) version of mousequery?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Roses on January 10, 2018, 11:32:05 am
Does anyone know exactly when the Event Manager onBuildingCreatedDestroyed() triggers?

For creation, is it as soon as you place the building, as soon as the dwarf begins working on the building, on finishing the building, or something else?
For destruction, is it when you mark the building to be destroyed, when it starts to be destroyed, on finishing destruction, or something else?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Pvt. Pirate on January 10, 2018, 12:34:08 pm
i got problems with mousequery not responding to the mouse being in the bottom or right border.
this did not occur in 43.x.x but only in 44.x.x
i'm using a 5:4 screen and running DF windowed 1280x960.
maybe there's something wrong with the calculation of the position and/or size of the areas for mouse scrolling.
Mousequery hasn't changed at all. What specific mousequery feature are you referring to? "mousequery edge"? Are you using TWBT, and if so, does the issue occur with DFHack's (not TWBT's) version of mousequery?
i used the 44.x LNP and the 1.9 Meph and it occured in both versions.
i used twbt without multilevel view and it did scroll correctly at the top and left edge, but not on the right and lower edge.
it does work in all the 42.x and 43.x versions.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: lethosor on January 10, 2018, 07:37:20 pm
Do both of those installations include TWBT? If so, again, can you try with the mousequery plugin distributed with DFHack? I know that DFHack's version hasn't changed since 0.43.05, but I can't make any guarantees about TWBT's version of mousequery (or TWBT itself) not changing things. It doesn't look like TWBT's mousequery.cpp has changed, but it's possible that TWBT has changed something.

Also, what specific mousequery feature are you referring to? Run "mousequery" and you should see a list of features, like this:
Code: [Select]
mousequery [plugin|rbutton|track|edge|live] [enabled|disabled]
  plugin: enable/disable the entire plugin
  rbutton: enable/disable right mouse button
  track: enable/disable moving cursor in build and designation mode
  edge: enable/disable active edge scrolling (when on, will also enable tracking)
  live: enable/disable query view when unpaused
Disable one at a time, like "mousequery track disable", until whatever you're talking about doesn't work at all.

Anyway, if this doesn't occur with DFHack's mousequery plugin, downloaded from https://github.com/dfhack/dfhack/releases, there isn't anything I can do to fix it.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: jecowa on January 11, 2018, 05:04:48 pm
Is it a bug if the /raw/onLoad.init file doesn't get loaded in the testing arena? In Dwarf mode the /data/save/regionx/raw/onLoad.txt loads just fine. But the testing Arena won't load the /raw/onLoad.txt when using the default source. It also won't load the /data/save/regionx/raw/onLoad.txt when using the save file as the source.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: lethosor on January 11, 2018, 05:45:38 pm
onLoad.init or onLoad.txt? Also, does it load onLoad.init in the main DF folder?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: jecowa on January 11, 2018, 06:12:53 pm
Yes, I meant onLoad.init. It will load an onLoad.init from the root DF folder.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: iceball3 on January 11, 2018, 09:26:33 pm
For the new version, will dfhack attempt to run on it (with associated risk of bugs), or will a version-mismatch cause an error automatically?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: lethosor on January 11, 2018, 09:33:52 pm
It won't recognize newer versions than what it was built for, which is always the case. We're working on 0.44.04 support, so expect a release soon.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: iceball3 on January 11, 2018, 09:37:37 pm
It won't recognize newer versions than what it was built for, which is always the case. We're working on 0.44.04 support, so expect a release soon.
Thanks for the fine work!
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: Pvt. Pirate on January 12, 2018, 12:44:43 am
Do both of those installations include TWBT? If so, again, can you try with the mousequery plugin distributed with DFHack? I know that DFHack's version hasn't changed since 0.43.05, but I can't make any guarantees about TWBT's version of mousequery (or TWBT itself) not changing things. It doesn't look like TWBT's mousequery.cpp has changed, but it's possible that TWBT has changed something.

Also, what specific mousequery feature are you referring to? Run "mousequery" and you should see a list of features, like this:
Code: [Select]
mousequery [plugin|rbutton|track|edge|live] [enabled|disabled]
  plugin: enable/disable the entire plugin
  rbutton: enable/disable right mouse button
  track: enable/disable moving cursor in build and designation mode
  edge: enable/disable active edge scrolling (when on, will also enable tracking)
  live: enable/disable query view when unpaused
Disable one at a time, like "mousequery track disable", until whatever you're talking about doesn't work at all.

Anyway, if this doesn't occur with DFHack's mousequery plugin, downloaded from https://github.com/dfhack/dfhack/releases, there isn't anything I can do to fix it.
i always use twbt and the mousequery feature that doesnt work correctly in 44.x is "edge".
so if this is a twbt-issue, where should i adress this bugreport then?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.03-beta1 (dev)
Post by: lethosor on January 12, 2018, 12:59:51 am
Good to know that you're using TWBT, but can you also test with the mousequery plugin distributed with DFHack and see if the issue occurs with it? I linked to it above.

If the issue does not occur when you do that, I would report it in the TWBT thread.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: lethosor on January 12, 2018, 02:10:29 am
A release for 0.44.04: https://github.com/DFHack/dfhack/releases/tag/0.44.04-alpha1
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: MoonyTheHuman on January 12, 2018, 01:40:25 pm
How would i set up DFhack in a way that i can run it on a server (with no GUI) but still access both DF and DFHack's screens?

(i.e. have them be on their own terminals in tmux, maybe?)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: Rose on January 12, 2018, 06:44:07 pm
Use dfhack-run to send commands.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: buuface on January 12, 2018, 09:09:09 pm
Hello i'm getting a crash which I suspect maybe something to do with DFHack in the latest alpha build

When a human caravan and guild representative arrives (year2, playing with 'enhanced gameplay' on) the game crashes with no error message.

Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: lethosor on January 12, 2018, 09:28:35 pm
What specific DFHack version are you using? I'm guessing it's not "the latest" because you mentioned "enhanced gameplay", which is a name some packs made up, and I'm not aware of any packs that include 0.44.04 yet. Can you test with 0.44.04, and also without DFHack entirely? If it only occurs with DFHack, can you upload your save?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: iceball3 on January 13, 2018, 02:27:09 am
"Something to do with trade representative" could possibly be what caused the crash I mentioned earlier too when I asked about missions and taverns, as I crashed somewhere in the middle of year two as well.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: PatrikLundell on January 13, 2018, 03:05:33 am
A question regarding the df.emotion_type attribute "divider" (defined in df.unit_thoughts.xml):
What does this attribute describe, and how is is supposed to be applied?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: Pvt. Pirate on January 13, 2018, 04:56:42 am
A release for 0.44.04: https://github.com/DFHack/dfhack/releases/tag/0.44.04-alpha1

it works when put into an unmodded DF. it somehow doesn't work when put into the LNP.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: lethosor on January 13, 2018, 12:14:19 pm
"Something to do with trade representative" could possibly be what caused the crash I mentioned earlier too when I asked about missions and taverns, as I crashed somewhere in the middle of year two as well.
Is it reproducible? If so, test without DFHack and see if it still occurs. If it only occurs with DFHack, please upload your save and explain how to reproduce the issue.

A question regarding the df.emotion_type attribute "divider" (defined in df.unit_thoughts.xml):
What does this attribute describe, and how is is supposed to be applied?

From https://github.com/DFHack/df-structures/commit/d69705e288075c9d640cd19b42aa21884f9500b9, they are "stress divisors". Not sure on specifics, but Quietust would know more.

it works when put into an unmodded DF. it somehow doesn't work when put into the LNP.
What does "doesn't work" mean?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: Quietust on January 13, 2018, 01:16:56 pm
A question regarding the df.emotion_type attribute "divider" (defined in df.unit_thoughts.xml):
What does this attribute describe, and how is is supposed to be applied?
Every "thought" affects a dwarf's Stress based on the emotion it provoked, the dwarf's personality, and likely also how long ago it happened. The relevant "base stress" value for the thought is divided by the "divider" associated with the emotion, and the result is then added to the dwarf's Stress level. Positive versus negative decides whether stress goes up or down, and larger values result in smaller adjustments.

For example, for a "base stress" value of 100, Despair (divider=1) would increase stress by 100 (a lot), Disappointment (divider=8) would increase stress by 13 (not much), Contentment (divider=-8) would reduce stress by 13, Delight (divider=-1) would reduce stress by 100, and Apathy (divider=0) would have no effect on stress.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: Putnam on January 13, 2018, 01:45:19 pm
This is all explained on the Dwarf Fortress wiki article for emotions. (http://dwarffortresswiki.org/index.php/DF2014:Emotion)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: PatrikLundell on January 13, 2018, 02:01:03 pm
Thanks Quietust!
I would never have figured that out, in particular since division by zero is a rather poor idea...

By the way, I think I've found out what a unit's emotion.flags.unk3 is for: when True it causes the display of the corresponding emotion to be didn't/doesn't feel anything, rather than the normal display (i.e. "didn't feel anything due to inebriation" rather than "felt euphoric due to inebriation" [with the first one being possible to misinterpret to mean the inebriation dulled any sensations, rather than having no effect]). It should eventually make its way into a structure pull request.

Also thanks to Putnam: I didn't even think of looking for such low level details on the wiki.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: surazal on January 13, 2018, 03:02:38 pm
I could very well be posting in the wrong forum for this question, and if so let me know. I saw that the dev branch in the github repository was updated to 0.44.04 alpha1, and the most recent update included the TWBT mod. I installed dfhack (in Linux, 64 bit) and saw that it was indeed enabled, but the font widths are variable. Is there any way I can switch those back to being fixed with as the font renderings are bugged when they're that way? I tried modifying the data/twbt_init/init.txt file among others but nothing seems to have any effect. I am running the Pheobus tileset pack.

P.S. I wasn't certain if this was a TBWT setting or a dfhack setting, which is why I'm posting here

(https://i.imgur.com/OPVmBya.png)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: lethosor on January 13, 2018, 03:08:43 pm
I could very well be posting in the wrong forum for this question, and if so let me know. I saw that the dev branch in the github repository was updated to 0.44.04 alpha1, and the most recent update included the TWBT mod. I installed dfhack (in Linux, 64 bit) and saw that it was indeed enabled, but the font widths are variable. Is there any way I can switch those back to being fixed with as the font renderings are bugged when they're that way? I tried modifying the data/twbt_init/init.txt file among others but nothing seems to have any effect. I am running the Pheobus tileset pack.

P.S. I wasn't certain if this was a TBWT setting or a dfhack setting, which is why I'm posting here
It definitely has something to do with TWBT. TWBT isn't included in DFHack, so I don't know what you meant by "the most recent update included the TWBT mod" - you can get TWBT from https://github.com/mifki/df-twbt ("Releases"). Also, it sounds like you're dealing with a pack, because I've never heard of a "twbt_init" folder - init.txt is usually just in data/init/init.txt. I'm not sure what the twbt_init folder is for - it might be used if TWBT is enabled somehow, but I'm pretty sure TWBT doesn't deal with that folder directly.

Short version: it's not DFHack stuff, but your setup is strange enough that I'm not sure exactly how to get it working. My best advice is to install TWBT from the link above and see if that fixes anything, but you might also have to make some configuration changes.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: surazal on January 13, 2018, 03:32:50 pm
It definitely has something to do with TWBT. TWBT isn't included in DFHack, so I don't know what you meant by "the most recent update included the TWBT mod" - you can get TWBT from https://github.com/mifki/df-twbt ("Releases"). Also, it sounds like you're dealing with a pack, because I've never heard of a "twbt_init" folder - init.txt is usually just in data/init/init.txt. I'm not sure what the twbt_init folder is for - it might be used if TWBT is enabled somehow, but I'm pretty sure TWBT doesn't deal with that folder directly.

Short version: it's not DFHack stuff, but your setup is strange enough that I'm not sure exactly how to get it working. My best advice is to install TWBT from the link above and see if that fixes anything, but you might also have to make some configuration changes.

Hm, OK, your point about twbt not being in dfhack led me to double-check, and it turns out it's from the Phoebus pack, not dfhack. They must have included it with their pack when tbwt was released for DF 0.44.04 recently.

So yes, you are correct, my bad. Thanks!
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: iceball3 on January 13, 2018, 03:54:20 pm
I've been running a pocket size world with a 1 tile embark, trying to isolate when I can get the hard crash to happen. It's occurred several times, but I can't quite isolate a consistent time, and I'm not sure if the 1 tile embark is to blame either. I've gotten past the first migrant wave, and am trying to get to the second.
It's been less straining on patience than it ought to be because I'm running the game at uncapped FPS, and I'm saving frequently until an event that would crash the game consistently happens shortly after loading, and I'll upload the save.
DF Version 44.03
For your amusement: uncapped normally peaks at at around 162800 fps, but tanks to 600 whenever leaves and fruits start falling from trees.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: lethosor on January 13, 2018, 03:58:56 pm
You might be able to use "repeat" to get "quicksave" to run automatically and leave it to run on its own.

Unrelated (maybe):

If anyone is getting crashes related to the units screen, can you please follow the instructions here (https://github.com/DFHack/dfhack/issues/1057#issuecomment-354582176) (specifically disabling the search plugin) and see if that helps?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: jecowa on January 13, 2018, 03:59:54 pm
I could very well be posting in the wrong forum for this question, and if so let me know. I saw that the dev branch in the github repository was updated to 0.44.04 alpha1, and the most recent update included the TWBT mod. I installed dfhack (in Linux, 64 bit) and saw that it was indeed enabled, but the font widths are variable. Is there any way I can switch those back to being fixed with as the font renderings are bugged when they're that way? I tried modifying the data/twbt_init/init.txt file among others but nothing seems to have any effect. I am running the Pheobus tileset pack.

P.S. I wasn't certain if this was a TBWT setting or a dfhack setting, which is why I'm posting here

Spoiler (click to show/hide)

Oh sorry, those graphics packs probably should have included some instructions for the new TWBT layout to explain how to install the TWBT content.

The TWBT and vanilla versions of the graphics packs were holding each other back. This is so creatures can have transparent background for TWBT users but without changing the creature background to black for non-TWBT users. It allows the non-TWBT versions to use simplified language files without forcing the TWBT versions (that don't need it) to do them same. It allows the TWBT versions to use cool multi-layer transparency feature, without making the tiles look bad for non-TWBT users.. It also allows the non-TWBT versions to use true-black in their color palettes so TTF doesn't look ugly.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: Pvt. Pirate on January 14, 2018, 05:38:34 am
it works when put into an unmodded DF. it somehow doesn't work when put into the LNP.
What does "doesn't work" mean?
it means that even when entering "mousequery edge enable" into the dfhack console, it doesnt activate the edge scrolling.

it does work when putting dfhack into mephs latest pack (the one with the launcher) and into a vanilla DF. I got no idea why it doesnt work with the LNP or why it didnt work with the dfhack version used in those packs.
anyway i'm glad it works for me now.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: lethosor on January 14, 2018, 03:15:53 pm
it means that even when entering "mousequery edge enable" into the dfhack console, it doesnt activate the edge scrolling.
Oh, so it's not all of DFHack that doesn't work. It's possible that you have a mismatch between mousequery and DFHack versions, especially if you're using TWBT's mousequery. Or it's possible that TWBT's mousequery behaves differently.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: Isher on January 14, 2018, 06:06:53 pm
Mousequery edge enable works with TWBT's version of mousequery, you just have to make sure it's the correct mousequery plugin installed. Generally if it's the wrong verison of mousequery it'll tell you in the dfhack window.

Unrelated question: Should 44.05 work with this version since it's only like one change or do memory addresses and such get changed for even minor edits?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: iceball3 on January 14, 2018, 06:14:01 pm
Mousequery edge enable works with TWBT's version of mousequery, you just have to make sure it's the correct mousequery plugin installed. Generally if it's the wrong verison of mousequery it'll tell you in the dfhack window.

Unrelated question: Should 44.05 work with this version since it's only like one change or do memory addresses and such get changed for even minor edits?
He mentioned earlier that as long as too much doesn't change between the update, all that's needed is some fiddling with the header (and worrying about a few unforeseen bugs).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: lethosor on January 14, 2018, 07:14:18 pm
Global addresses almost always change between versions. Some didn't change in 0.44.05, but some did. No layouts changed, as far as I can tell, so DFHack for 0.44.05 should be up soon, as soon as the upload script is fixed (it's already built, and for reference, it supports 0.44.04 and 0.44.05 right now).

If you're impatient, you can get symbols.xml from https://raw.githubusercontent.com/DFHack/df-structures/0.44.05-alpha1/symbols.xml and replace the one in the hack folder with it, although that won't include any of the other fixes in 0.44.05-alpha1 (not many).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.04-alpha1 (dev)
Post by: Meph on January 14, 2018, 07:35:29 pm
Are there any known crashes related to dfhack when it comes to building placement? I am getting crashes-to-desktop when placing farm plots or custom workshops now and then. No errorlog, nothing in stderr.log, only one "Resetting textures" entry in the other dfhack log.

Happened to me multiple times in 44.03 beta while using dfhack and twbt.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 14, 2018, 07:41:27 pm
0.44.05-alpha1 is up: https://github.com/DFHack/dfhack/releases/tag/0.44.05-alpha1


First I've heard of building/farm-related crashes, although if it doesn't occur in 0.44.05, we can't really do anything about it. Maybe try without TWBT as well?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Rumrusher on January 16, 2018, 10:56:39 am
so discovered unit.enemy.unk_v40_sub3.unk_5 contains something to do with learning Demon names.
which means it possible to edit that to bind and banish folks
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Meph on January 16, 2018, 12:20:44 pm
On windows 44.03, dfhack beta, I tried running exportlegends info, got this error message:

Quote
Invoking: exportlegends info
...t Launcher\Dwarf Fortress/hack/scripts/exportlegends.lua:86: Cannot iterate field vector<world_construction*>.0: index out of bounds.
stack traceback:
   [C]: in upvalue 'cb'
   ...t Launcher\Dwarf Fortress/hack/scripts/exportlegends.lua:86: in for iterator 'for iterator'
   ...t Launcher\Dwarf Fortress/hack/scripts/exportlegends.lua:211: in global 'export_more_legends_xml'
   ...t Launcher\Dwarf Fortress/hack/scripts/exportlegends.lua:772: in global 'export_legends_info'
   ...t Launcher\Dwarf Fortress/hack/scripts/exportlegends.lua:821: in local 'script_code'
   ...op 3\Tileset Launcher\Dwarf Fortress\hack\lua\dfhack.lua:562: in function 'dfhack.run_script_with_env'
   (...tail calls...)
Invoking: die

Is that a known issue, the script not updated to the newest version? Or did I mess something up?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 16, 2018, 12:25:47 pm
It's known and fixed in DFHack 0.44.04-alpha1
https://dfhack.readthedocs.io/en/latest/docs/NEWS-dev.html#dfhack-0-44-04-alpha1
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Meph on January 16, 2018, 12:35:04 pm
It's known and fixed in DFHack 0.44.04-alpha1
https://dfhack.readthedocs.io/en/latest/docs/NEWS-dev.html#dfhack-0-44-04-alpha1
Perfect, thank you. :)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 16, 2018, 12:42:22 pm
I double-checked and it's actually a one-line change (https://github.com/DFHack/scripts/commit/bd8fbdd78b6bc1321ab00601d5b4e4f0c716b3e2), so you could patch DFHack for 0.44.03 yourself if you wanted.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Hylum on January 16, 2018, 12:52:19 pm
Not sure if anyone has brought this up here but "twbt redraw_all 1" causes the game to crash and close when building certain objects, one that happens to me a lot is farm plots. When I set "twbt redraw_all 0" the crashes stop. Any way to fix this problem?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 16, 2018, 01:11:06 pm
That should be reported in the TWBT thread (although it already has): http://www.bay12forums.com/smf/index.php?topic=138754.0
I'm not aware of any fix yet besides what you did.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Hylum on January 16, 2018, 03:10:02 pm
That should be reported in the TWBT thread (although it already has): http://www.bay12forums.com/smf/index.php?topic=138754.0
I'm not aware of any fix yet besides what you did.

Ok great, ty. Just wanted to make sure the right people knew about it.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: martinuzz on January 17, 2018, 04:05:17 pm
Request:
Would it be possible to create a command that lists which cooking ingredients are favoured in the thoughts and preferences screen of you dwarves?
Idem for drink preferences?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Roses on January 17, 2018, 04:05:57 pm
Is there a way to add a reaction to a workshop entirely through the command line? I am trying to test some of my reaction based scripts and it would be a lot easier if I could automate it. I saw there was dfhack.job.linkIntoWorld(job,new_id) but I wasn't sure if that would do what I wanted.

EDIT: Also, does the eventful onReactionComplete only work if the reaction starts with 'LUA_HOOK_TRIGGER'?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Novaris on January 17, 2018, 04:16:32 pm
I seem to have an issue with the quicksave command. Normally I quicksave every time an enemy force is coming but it seems that, as soon as i save the game, the invaders which did not spawn yet on the map vanish before spawning, leaving all their armor, cloth and weapons just outside of the map. I can see the items in the stock overview as forbidden and marked red for no unobtainable and when I jump to them the cursor is placed right on the mapedge the siege came from, all the way on the last tile of the map. This also happens for merchants so all the food and items they carry is just dumped before entering the map. If I dont quicksave everything works fine and a whole bunch of enemies spawn and attack. If I save once all are spawned, everything seems fine...

Anybody else experiencing this? 0.44.04 with dfhack.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 18, 2018, 12:38:05 am
I seem to have an issue with the quicksave command. Normally I quicksave every time an enemy force is coming but it seems that, as soon as i save the game, the invaders which did not spawn yet on the map vanish before spawning, leaving all their armor, cloth and weapons just outside of the map. I can see the items in the stock overview as forbidden and marked red for no unobtainable and when I jump to them the cursor is placed right on the mapedge the siege came from, all the way on the last tile of the map. This also happens for merchants so all the food and items they carry is just dumped before entering the map. If I dont quicksave everything works fine and a whole bunch of enemies spawn and attack. If I save once all are spawned, everything seems fine...

Anybody else experiencing this? 0.44.04 with dfhack.
I've heard of a variety of issues like this in vanilla DF. http://www.bay12games.com/dwarves/mantisbt/view.php?id=9593 is related. I think saving before a siege or caravan (or migrant wave?) has entered the map prevents them from entering. I'm surprised that quicksave broke it - I would have expected it to work better than a save/load cycle. That probably means autosaves are affected too, since that's basically identical to what quicksave does.

I couldn't find a bug report quickly that links the issue to saving, so I might have to address that, but if you have an affected save handy, it might help to upload it to DFFD and see if you can find a good report to link it to.

Is there a way to add a reaction to a workshop entirely through the command line? I am trying to test some of my reaction based scripts and it would be a lot easier if I could automate it. I saw there was dfhack.job.linkIntoWorld(job,new_id) but I wasn't sure if that would do what I wanted.

EDIT: Also, does the eventful onReactionComplete only work if the reaction starts with 'LUA_HOOK_TRIGGER'?
dfhack.job.linkIntoWorld has something to do with setting up jobs (the things in the "j" screen, not the options workshops). If I misunderstood and you're talking about queueing jobs at specific workshops that happen to involve interactions, there are probably some examples of that. I was looking at autogems recently, but it's a bit complicated. I don't know much about eventful.

Request:
Would it be possible to create a command that lists which cooking ingredients are favoured in the thoughts and preferences screen of you dwarves?
Idem for drink preferences?
Interesting idea. I'm not sure where that information is stored, but I can look into it.
Edit: "dwarfmonitor prefs" should list this already, although it's mixed in among other preferences.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: PatrikLundell on January 18, 2018, 03:41:24 am
@martinuzz: Yes, it's possible, and I think there was a discussion recently where someone wanted to do something similar.
I've got the script parts to get the preferences, so it should be a matter of just applying that to all units while filtering out visitors. I'm not sure whether it would include or exclude residents, though (I don't think I've got any in my saves). I should probably be able to put something together today.

Edit:
OK, here's an attempt:
Spoiler (click to show/hide)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Novaris on January 18, 2018, 04:00:30 am
I started a new fortress in the altest release and am now waiting for the caravan and siegers to arrive. I hope that I can reproduce the issue /or can confirm that autosave wasn't the issue. I'll keep you posted and upload the save if confirmed.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Rumrusher on January 18, 2018, 08:36:34 am
so yeah it seems like quicksave Quickens armies you send to return back home in the 44.05 version of the game.
though I kinda was wondering what was crashing the game for a bit
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Novaris on January 18, 2018, 09:07:28 am
Do you see the same with a save/load cycle?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Rumrusher on January 18, 2018, 10:18:16 am
Do you see the same with a save/load cycle?
just booted up a save where I sent a queen to a 9 day hike and yeah looks like the game just brought them back instantly.
kinda wonder if save and load skips the timer on these and or either returns everyone to their last Site which for raid parties from fort mode means they return to the fort?
seems like this could be used to speed up sieging sites. now if there was only a way to Tell your army to Murder everyone at the site and not try to steal artifacts.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 18, 2018, 10:40:15 am
Rumrusher, you're talking about something (probably) different from the issue with caravans/migrants/etc. not arriving properly. (And sounds like it's not quicksave-specific, in any case.)

Martinuzz: it turns out that you can search for preference types in the "dwarfmonitor prefs" screen - does this help?
Spoiler (click to show/hide)

Note that you can get to this screen with Alt-M from the main fortress mode screen (with the default keybindings, anyway).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: flyteofheart on January 18, 2018, 11:46:40 am
Anyone here know how to make legends export to a diff folder? I dont like that it just dumps a shitton of stuff into the main DF folder. i would love if I could 'exportlegends all" -> into a legends export folder. even better if i can make each regions export go into a different sub folder but its ok if it doesnt do that.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 18, 2018, 11:52:15 am
It's not possible right now, but it could be added.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: jecowa on January 18, 2018, 12:12:32 pm
How many items does it make when exporting legends? I wish the vanilla exports would also go into a folder. I always print an image of my world after generating a new world. Might not be as important to print those anymore now that there's an in-game map, though.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 18, 2018, 12:37:47 pm
Looks like "exportlegends info" exports 3 XML files, 2 text files, and a bitmap image (note that this is from running it some time ago, so I might be a bit off). I think "exportlegends maps" can export a lot of images, depending on the world.

Note that the exportlegends script only has control over where the "...legends_plus.xml" file is saved. DF writes the rest of them, and they all go in the DF folder. exportlegends could probably move them afterward, but it might be a little tricky because DF truncates region names in those filenames to 20 characters (except ...world_gen_param.txt).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: martinuzz on January 18, 2018, 11:07:56 pm
Rumrusher, you're talking about something (probably) different from the issue with caravans/migrants/etc. not arriving properly. (And sounds like it's not quicksave-specific, in any case.)

Martinuzz: it turns out that you can search for preference types in the "dwarfmonitor prefs" screen - does this help?
Spoiler (click to show/hide)

Note that you can get to this screen with Alt-M from the main fortress mode screen (with the default keybindings, anyway).
Oh awesome! That's basically what I asked for, I see I should have searched harder, for it's already there!
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: strainer on January 20, 2018, 12:16:55 pm
@PatrikLundell

Would you be able to push the histfig relationships.list structural info? I had a look but not sure where to alter. Im using the anon names at the moment but think its a good idea for these to be updated soon.

These names would work:
relationships.list(#).anon_3 : attitude //or standing
relationships.list(#).anon_4 : counter //(experience)
relationships.list(#).anon_5 : position //(display)

And the enum for the attitude codes:
Code: [Select]
relations_list_attitude_type : int16_t

None = -1,
Hero,
Friend,
Grudge,
Bonded,
ConsidersViolent,
ConsidersPsychotic,
GoodForBusiness,
FriendlyTerms,
ConsidersKiller,
ConsidersMurderer,
Comrade,
MemberOfRespectedGroup,
MemberOfHatedGroup, 
EnemyFighter, 
FriendlyFighter, 
ConsidersBully, 
ConsidersBrigand, 
LoyalSoldier, 
ConsidersMonster,
ConsidersStoryteller,
ConsidersPoet,
ConsidersBard,
ConsidersDancer,
ConsidersQuarreler,
ConsidersFlatterer,
Hunter,
ProtectorOfTheWeak
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: PatrikLundell on January 20, 2018, 01:44:02 pm
@strainer: The main reason I haven't generated a "pull request" is that there was an unknown hole in the anon_3 enum type (which you're filling in), and because I still don't understand the role of anon_4.
However, I guess we're not getting further for the time being, so I'll make an attempt.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: strainer on January 20, 2018, 02:23:48 pm
No pressure Patrick, i just thought id bring it up again. I dont know whats done with that counter either, but seems safe to call it counter. And I have observed the keys which are filled in. There is some mechanism involving the counter which juggles the most important 'attitude' or decides friendly terms or whatever, but it may be guessed/ resolved later.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: PatrikLundell on January 20, 2018, 03:36:21 pm
Well, I've made a "pull request", so we'll see what the judges say.
The enum type actually did exist already. Slightly different names, but the same values (plus two additional ones at the end, one of which I think was Thief). The enum was used for the reputation structure nearby, so it's a fair bet it's really the same type used in both cases.
I changed the name of "position" to "rank", and added a comment block trying to summarize the sort order determination, as well as that being based on limited data. I also mentioned that the function of "counter" was unknown.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: strainer on January 20, 2018, 06:13:58 pm
Sounds good Patrick, I didnt know about that reputations structure. I'll look at the pull request to see how these definitions are updated.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: flyteofheart on January 21, 2018, 12:54:59 pm
snip- found what i was looking for in search.

someone already made an adventure mode quick teleportation script called Flashstep

Im not sure how to get a script into DF and then set it to a hotkey but ill figure it out.

this specifically -

Can you write me a script that teleports you in adv mode to the cursor with "l"? It would make navigating laggy areas more bearable.
Write one for you, personally?

Absolutely not.

Already have one?

Probably.
Code: (flashstep.lua) [Select]
--Teleports unit to cursor
--[====[

flashstep
=========
A hotkey-friendly teleport that places you where your cursor is.

]====]
function flashstep(flash,step)
    local flash = df.global.world.units.active[0]
    local step
        if df.global.ui_advmode.menu == df.ui_advmode_menu.Look then
            step = df.global.cursor
        else
            qerror("No [l] cursor located! You kinda need it for this script.")
        end
    local unitoccupancy = dfhack.maps.getTileBlock(flash.pos).occupancy[flash.pos.x%16][flash.pos.y%16]
        flash.pos.x = step.x
        flash.pos.y = step.y
        flash.pos.z = step.z
            if flash.pos.x==step.x then
            local stepvisibility = dfhack.maps.getTileBlock(flash.pos).designation[flash.pos.x%16][flash.pos.y%16]
                stepvisibility.hidden=false
            end
    if not flash.flags1.on_ground then unitoccupancy.unit = false else unitoccupancy.unit_grounded = false end
end
flashstep(flash,step)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: dotterian on January 22, 2018, 08:25:26 am
Hi. I'm trying to determine selected or followed dwarf id from lua script. In first case it's a matter of calling one method, but I can't find anything for "follow dwarf" part.
Seems like I can get data of a dwarf in the center of sceen (some times I'll get two or more dwarves on one tile, but that's irrelevant for now).
I need to do this only when I'm in "follow dwarf" mode, and, since it's my first attempt at scripting for DFHack, I dunno how to determine if game is in this mode.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: mifki on January 22, 2018, 08:30:34 am
Hi. I'm trying to determine selected or followed dwarf id from lua script. In first case it's a matter of calling one method, but I can't find anything for "follow dwarf" part.
Seems like I can get data of a dwarf in the center of sceen (some times I'll get two or more dwarves on one tile, but that's irrelevant for now).
I need to do this only when I'm in "follow dwarf" mode, and, since it's my first attempt at scripting for DFHack, I dunno how to determine if game is in this mode.

df.global.ui.follow_unit
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Novaris on January 22, 2018, 09:33:49 am
Ok after lengthy testing it seems not related to quicksaving but rather to scared away merchants, they seem to drop everything once they leave the map, so all their stock shows up as 'unobtainable' in the stock overview. The invaders worked up to now.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Novaris on January 22, 2018, 11:22:55 am
Is there a script that deteriorates EVERYTHING that isn't stockpiled or worn/carried/owned? I have sooooo many sekeltons, bolts, arrows, armor, food, dead traders, god knows what creatures lying dead in front of my gates and cleaning everything up is annoyingly FPS consuming. I managed to get corpses and refuse deteriorate with the scripts but failed to manage a clever check for whether or not the stuff is in a stockpile...


I have to remedy my former statement: have a siege, wait until half of them arrive (like half the squad). quicksave, let the rest arrive, die, restart DF, load game, no more soldiers arrive.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: iceball3 on January 22, 2018, 12:46:33 pm
Is there a script that deteriorates EVERYTHING that isn't stockpiled or worn/carried/owned? I have sooooo many sekeltons, bolts, arrows, armor, food, dead traders, god knows what creatures lying dead in front of my gates and cleaning everything up is annoyingly FPS consuming. I managed to get corpses and refuse deteriorate with the scripts but failed to manage a clever check for whether or not the stuff is in a stockpile...


I have to remedy my former statement: have a siege, wait until half of them arrive (like half the squad). quicksave, let the rest arrive, die, restart DF, load game, no more soldiers arrive.
A stopgap until someone proposes a solution: dump all the junk underneath an open side-raising drawbridge and lower the drawbridge on top of it. The items will be obliterated.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Novaris on January 22, 2018, 04:45:48 pm
I do this already, designating all items I find for dumping and autodump them into an atomsmasher but still, related to the trade bug, I want it to occur automatically and also affect items that can't be selected by hand on the map. Anyway thanks for the suggestion :-)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: PatrikLundell on January 22, 2018, 04:55:40 pm
I *think* this script should reveal, claim, and dump mark merchant stuff. I don't have any bugged merchants to try it on, though.
Make a backup of your save before trying it.

Spoiler (click to show/hide)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Max™ on January 22, 2018, 06:04:34 pm
snip- found what i was looking for in search.

someone already made an adventure mode quick teleportation script called Flashstep

Im not sure how to get a script into DF and then set it to a hotkey but ill figure it out.
Save in df/hack/scripts as flashstep.lua.
In dfhack.init try like: keybinding add Ctrl-F flashstep or whichever key combo you prefer.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Warmist on January 24, 2018, 04:19:53 am
Hey could someone look into how wounds work/get updated. I know there is some "calculated_XXX" flags but they did not seem to work when i removed brains from a dwarf (it should get him paralyzed?). I know that heart could be removed without any problems so maybe some info on how much bleeding should be correct for specific organ? Or just wound workings info would be appreciated.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Novaris on January 24, 2018, 10:42:49 am
I have it!

I found an error using dfhack, items are not lying were the carrier "died". I found gloves and armor in the df.world.items.all list with a position of -30000 and traced its carrier in the units.all and units.active list. The swordsman was not part of the units.active but found in the units.all with a valid position right on the map edge (I don't know why he died there but he never made it onto the map) so my plan is now to traverse the lists, find dead units that have a valid map position, check their items and if their position is invalid, I update the position or even mark them for garbage_collection.

Many thanks from everybody :D
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: PatrikLundell on January 24, 2018, 11:22:59 am
I have it!

I found an error using dfhack, items are not lying were the carrier "died". I found gloves and armor in the df.world.items.all list with a position of -30000 and traced its carrier in the units.all and units.active list. The swordsman was not part of the units.active but found in the units.all with a valid position right on the map edge (I don't know why he died there but he never made it onto the map) so my plan is now to traverse the lists, find dead units that have a valid map position, check their items and if their position is invalid, I update the position or even mark them for garbage_collection.

Many thanks from everybody :D
The reason those items do not have an explicit position is because they're either in a container or in a unit inventory. Containers may be in inventories as well, so their positions are the positions of the containers/units carrying them. That's not a bug in DFHack, but DF glitching the carrying creature (assuming you look at cases where they haven't arrived/left properly). Also note that the unit flag called "dead" by DFHack isn't actually an indicator of the unit being dead, but rather something more like inactive, so I think merchants on the way onto the map and those that have just left have that flag set. Likewise, invaders who haven't arrived properly yet can have this flag set.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Roses on January 24, 2018, 11:43:58 am
I have it!

I found an error using dfhack, items are not lying were the carrier "died". I found gloves and armor in the df.world.items.all list with a position of -30000 and traced its carrier in the units.all and units.active list. The swordsman was not part of the units.active but found in the units.all with a valid position right on the map edge (I don't know why he died there but he never made it onto the map) so my plan is now to traverse the lists, find dead units that have a valid map position, check their items and if their position is invalid, I update the position or even mark them for garbage_collection.

Many thanks from everybody :D
The reason those items do not have an explicit position is because they're either in a container or in a unit inventory. Containers may be in inventories as well, so their positions are the positions of the containers/units carrying them. That's not a bug in DFHack, but DF glitching the carrying creature (assuming you look at cases where they haven't arrived/left properly). Also note that the unit flag called "dead" by DFHack isn't actually an indicator of the unit being dead, but rather something more like inactive, so I think merchants on the way onto the map and those that have just left have that flag set. Likewise, invaders who haven't arrived properly yet can have this flag set.

Yeah, it sounds more like you have a unit that didn't arrive/leave properly (although I think arrival problems are more common than leaving problems, at least for me) and so is stuck on the edge of the map and that the unit has an inventory and that that is actually what you are looking at for the items with a -30000 x coordinate.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Novaris on January 24, 2018, 11:46:27 am
Actually I meant I found a dfhack workaround for a DF glitch :D I finally can mark all the damn "edge items" using a single script and then autodump them away :D dfhack was the saviour, not the offender :P

I have yet to find a way to add the items to the map block though, I see them using the cursor but I cant select them, only dump them using autodump which complains about the items not being part of a block. But if "dead" doesn't mean dead, I still have to figure out how to distinguish between alive breathing entities and ... well ... guys who died at the border of the map.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Roses on January 24, 2018, 12:35:53 pm
Actually I meant I found a dfhack workaround for a DF glitch :D I finally can mark all the damn "edge items" using a single script and then autodump them away :D dfhack was the saviour, not the offender :P

I have yet to find a way to add the items to the map block though, I see them using the cursor but I cant select them, only dump them using autodump which complains about the items not being part of a block. But if "dead" doesn't mean dead, I still have to figure out how to distinguish between alive breathing entities and ... well ... guys who died at the border of the map.

I'm pretty sure there is a dfhack.items command to move an item from an inventory to the ground. The issue you are experiencing is that the item isn't a part of a block because it is part of an inventory. And to make matters worse it is a part of an inventory for a unit that is "stuck" in an inactive state. You can do a couple things

1. Unstuck the unit somehow. There are various scripts that try to do this, I think fix-migrants or fix-merchants or something like that deals with getting those units "unstuck"
2. Remove the unit entirely. I'm not sure if this would cause issues, but it might work.
3. If all you care about is the items, you can remove the items from the units inventory and place them on the ground. I believe dfhack.items.moveToGround would work for this.

As for checking whether the unit is dead (inactive) or Dead (as a doorknob), you should be able to check the corspe pieces and look for a corpse object if the unit is Dead. But actually if a unit dies they drop their items and so the items would actually be in a valid block if the unit is actually Dead.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Pvt. Pirate on January 24, 2018, 04:08:47 pm
for testing purposes it could be useful to have more options for autosave:
weekly and daily could help create gamesaves closer to the actual crash

i suggested this a while back for the game in general, because back then i had a lot of crashes.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 24, 2018, 04:12:25 pm
Yeah, it should be pretty easy to do with repeat and quicksave. I don't remember the exact requirements of the repeat script, but it should be in the docs.

Also, I finally fixed the issue where the "saving" indicator often wouldn't show up when using quicksave, so that'll look nicer in the next version.

Are there any major issues we should be aware of before releasing r1? I'm working on a couple long-standing bugs for now, like digv not setting priorities, but I haven't heard of any disastrous stability issues.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Novaris on January 24, 2018, 05:06:54 pm
Nope I must say the alpha is very very stable. It rarely crashed for me and when it crashed it was always when I tried to build something like farm plots or walls and this I had also with 0.42.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 24, 2018, 06:33:56 pm
Nope I must say the alpha is very very stable. It rarely crashed for me and when it crashed it was always when I tried to build something like farm plots or walls and this I had also with 0.42.
Ok, you should still generally report crashes even if they're not new, but that one has been reported already and linked to TWBT. I'm not sure if it's been fixed yet, but check the TWBT thread for details. Other than that, that's good news. I should have time to finish things up for a r1 in a couple days.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Rose on January 24, 2018, 09:13:44 pm
I found the address of a function in DF that I would like to call from a DFHack plugin.

How would I go about doing that?

It takes a pointer to and art_image_ref and an int pointer, and returns a pointer to an art_image, generating a new one if necessary.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: mifki on January 24, 2018, 10:36:13 pm
I found the address of a function in DF that I would like to call from a DFHack plugin.

How would I go about doing that?

It takes a pointer to and art_image_ref and an int pointer, and returns a pointer to an art_image, generating a new one if necessary.

Well, you just define a pointer to a function with the same signature and assign the right address to it...
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Rose on January 24, 2018, 11:10:35 pm
Well I'd also like to know how to keep the pointers stored in DF-structures, so they can be updated for newer versions.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: mifki on January 24, 2018, 11:50:44 pm
Well I'd also like to know how to keep the pointers stored in DF-structures, so they can be updated for newer versions.

I don't think df-structures have support for storing addresses of and/or calling arbitrary functions (as opposed to vmethods).

Btw, I'm just using viewscreen_image_creatorst to make it load all art_image_chunks.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Rose on January 25, 2018, 12:01:12 am
right now, I just stuck a void pointer that I'm casting to the right function, until the functionality for function pointers is added. Currently building to test.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Warmist on January 25, 2018, 12:39:05 am
Well I'd also like to know how to keep the pointers stored in DF-structures, so they can be updated for newer versions.

I don't think df-structures have support for storing addresses of and/or calling arbitrary functions (as opposed to vmethods).

Btw, I'm just using viewscreen_image_creatorst to make it load all art_image_chunks.

Actually you can store "void" pointers in symbols.xml:  both start_dwarf_count and twbt_render_map  (https://github.com/DFHack/df-structures/blob/twbt_experiments_symbols/symbols.xml#L1131) are void pointers with no type and into a code region. However these are not automated and afaik harder to find then other offsets
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: aexsar on January 25, 2018, 12:53:19 am
So I saw someone had a similar problem to me, but they never pasted the output. I am unable to get DFHack to load any plugins upon start, I am unzipping Vanilla DF to a folder, extracting DFHack right on top (and get the dialog box asking if I want to overwrite SDL.dll so I know the files should be dropping where they should be), but I'm getting error messages upon start. I've tried both r3, then r1 and am getting the same problem with both; stderr.txt output is as follows:
Spoiler (click to show/hide)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Rose on January 25, 2018, 01:11:28 am
Which version of DF do you have and which version of dfhack are you trying to install?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Rose on January 25, 2018, 01:13:34 am
I got everything in place, but I ran into a different problem...

Despite compiling RelWithDebInfo, no pdb files are being generated, so I can't debug.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: aexsar on January 25, 2018, 01:16:56 am
Which version of DF do you have and which version of dfhack are you trying to install?

DF version is df_43_05_win32
DFHack version I've tried is dfhack-0.43.05-r3.1-Windows-32 and then dfhack-0.43.05-r1-Windows-32

This is on a windows XP machine if that matters.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 25, 2018, 09:44:56 am
Btw, I'm just using viewscreen_image_creatorst to make it load all art_image_chunks.
Japa: if you can get this to work, I'd prefer it to having a function pointer in symbols.xml.

So I saw someone had a similar problem to me, but they never pasted the output. I am unable to get DFHack to load any plugins upon start, I am unzipping Vanilla DF to a folder, extracting DFHack right on top (and get the dialog box asking if I want to overwrite SDL.dll so I know the files should be dropping where they should be), but I'm getting error messages upon start. I've tried both r3, then r1 and am getting the same problem with both; stderr.txt output is as follows:
Spoiler (click to show/hide)
For some reason it can't read any files, except dfhack.init-example somehow. Did you install DFHack as a different user?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Rose on January 25, 2018, 09:55:31 am
Code: [Select]
df::art_image * (__thiscall *getImage)(df::world*,df::art_image_ref *, int *) = (df::art_image * (__thiscall*)(df::world*, df::art_image_ref *, int *))df::global::getArtImage;works. Not sure if the first argument needs to be world though.

Calling it with an art image ref that is full of - 1 vars allocates a new empty art image at the end of the list and returns a pointer to the new image.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Robsoie on January 25, 2018, 02:44:35 pm
For some reason it can't read any files, except dfhack.init-example somehow. Did you install DFHack as a different user?
DF version is df_43_05_win32
DFHack version I've tried is dfhack-0.43.05-r3.1-Windows-32 and then dfhack-0.43.05-r1-Windows-32

This is on a windows XP machine if that matters.

There may be a problem with how dfhack is looking for file on XP actually :
I gave a try to current dfhack on a 32bits PC that has XP and exact same problem : dfhack does not find any plugin despite they're all there.
Last time i used dfhack on that same system XP 32bits machine, it was dfhack 42.06 alpha-2 a couple of years ago, and it worked without a problem.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 25, 2018, 02:50:34 pm
There may be a problem with how dfhack is looking for file on XP actually :
I doubt that - the last time the plugin-loading code changed significantly was before DFHack 0.40.24-r4 (https://github.com/DFHack/dfhack/commit/4fc6cb6f175aebc96bf7ec4629a90cd05b71e8ee#diff-bcb993821b53968bc228a308c6193963).
Quote
I gave a try to current dfhack on a 32bits PC that has XP and exact same problem : dfhack does not find any plugin despite they're all there.
Last time i used dfhack on that same system XP 32bits machine, it was dfhack 42.06 alpha-2 a couple of years ago, and it worked without a problem.
Ok, what if you try the older one?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Pvt. Pirate on January 25, 2018, 03:20:06 pm
Nope I must say the alpha is very very stable. It rarely crashed for me and when it crashed it was always when I tried to build something like farm plots or walls and this I had also with 0.42.
it ran stable enough for 5 hours without any problems and 2 years into the game for me.
keep up the good work, mates!
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: martinuzz on January 25, 2018, 03:51:58 pm
44.05-alpha1 been running my fort stable and with no crashes for 25 years now
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Robsoie on January 25, 2018, 06:40:53 pm
Quote
I gave a try to current dfhack on a 32bits PC that has XP and exact same problem : dfhack does not find any plugin despite they're all there.
Last time i used dfhack on that same system XP 32bits machine, it was dfhack 42.06 alpha-2 a couple of years ago, and it worked without a problem.
Ok, what if you try the older one?

I'm not sure what you mean by the older one, but i just re-downloaded that old DF 42.06 and  old dfhack 42.06 alpha-2 (https://github.com/DFHack/dfhack/releases/tag/0.42.06-alpha2) , then after trying it looks like it works as it did last i played that DF version.
Spoiler (click to show/hide)

While DF 44.05 + dfhack 44.05 alpha1
Spoiler (click to show/hide)
interestingly on the first line "could not load dfhack-config\script-paths.txt" there's actually no script-paths.txt in the dfhack-config\ folder , the script-paths.txt is in dfhack-config\default\
But copying that file into dfhack-config\ does not change anything out of removing the "could not load dfhack-config\script-paths.txt" message as expected, it still can't find any of the plugin that are still in their correct locations.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 25, 2018, 07:16:43 pm
That was what I was looking for. It looks like it matches the behavior described here (http://www.bay12forums.com/smf/index.php?topic=139553.msg7289387#msg7289387). DFHack is supposed to copy files from dfhack-config/default/ to dfhack-config/, so somehow it wasn't able to do that.

Again, did you install DFHack as a different user?

Can you upload your stderr.log file (in the DF folder)?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: iceball3 on January 25, 2018, 09:12:32 pm
Question: Is the a DFHack script or view that offers a breakdown of everything affecting a dwarf's stress level notating the point value of each thought's effect on the current level, or is that not tracked after the thought is issued?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 25, 2018, 09:30:13 pm
I think it's tracked to an extent, and would be possible to display with DFHack, but I don't believe there's a tool like the one you described.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: iceball3 on January 25, 2018, 09:44:34 pm
I think it's tracked to an extent, and would be possible to display with DFHack, but I don't believe there's a tool like the one you described.
Understood, thanks for the info.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Robsoie on January 26, 2018, 07:02:04 am
That was what I was looking for. It looks like it matches the behavior described here (http://www.bay12forums.com/smf/index.php?topic=139553.msg7289387#msg7289387). DFHack is supposed to copy files from dfhack-config/default/ to dfhack-config/, so somehow it wasn't able to do that.

Again, did you install DFHack as a different user?

Can you upload your stderr.log file (in the DF folder)?

It's the same user as for the 42.06 that has the dfhack that has no problem, both the DF 44.05 and 42.06 are located in C:\  directly ( i mean C:\df_42_06_win\ and C:\df_44_05_win32\ ) in case it's important.

Here's the content of stderr.log
Spoiler (click to show/hide)

And if it can help for a comparison, here's the stderr.log of the 42.06 that works
Spoiler (click to show/hide)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 26, 2018, 11:04:47 am
Weird, it managed to open symbols.xml. What about the file "hack/scripts/gui/no-dfhack-init.lua" - does it exist, can you open it, does it have contents, etc?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Robsoie on January 26, 2018, 01:43:38 pm
Yes, there's a no-dfhack-init.lua  in my
C:\df_44_05_win32\hack\scripts\gui\
folder

the content of it
Spoiler (click to show/hide)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Roses on January 26, 2018, 01:49:50 pm
Does anyone have much experience with dissecting the reports from DF? I am trying to get the units involved in combat reports, for instance we have a combat dodge report "Dwarf 3 attacks Dwarf 4 but she jumps away!". Now I know I can use the report.id and look through all the active units to find which unit has that report.id in their reports field, but what I can't do is figure out which is which. The only thing I could think of would be to compare the names and match them that way, but that would mean I would have hard code each string option.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Robsoie on January 26, 2018, 02:07:14 pm
I did some more checks with the dfhacks releases.

I found that the last version that work correctly on the xp system is DF 43.03 + DFHack 0.43.03-r1 (https://github.com/DFHack/dfhack/releases/tag/0.43.03-r1)

The 1st version that stopped to work correctly on that system and can't detect plugins and etc is DF 43.05 + DFHack 0.43.05-alpha1 (https://github.com/DFHack/dfhack/releases/tag/0.43.05-alpha1)
(there isn't a 43.04 df hack version apparently)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 26, 2018, 05:16:00 pm
Thanks, that helps. We had to upgrade the Windows compiler to match Toady upgrading his for 0.43.04 (which is why there wasn't a release for 0.43.04 - we would have had to make some changes for 0.43.04 support, and many more for 0.43.05, so we decided to skip 0.43.04). My best guess is that MSVC 2015 breaks DFHack's filesystem layer some on XP, although since XP is 17 years old and unsupported, I can't commit to fixing it. It appears to be a bug mentioned here (https://stackoverflow.com/questions/32452777/visual-c-2015-express-stat-not-working-on-windows-xp), although I'm not sure if that's something that could be fixed on our end, Toady's end, or yours.

One possibility would be to download https://www.microsoft.com/en-us/download/details.aspx?id=49984 (https://www.microsoft.com/en-us/download/details.aspx?id=49984), locate any DLLs that it installed matching ones in the DF folder (not sure where those would be), and copy them into the DF folder. I'm not entirely sure if that would work, though.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: jecowa on January 26, 2018, 05:31:37 pm
Wow! 17 years old! And here I was thinking my 7-year-old operating system (Lion) was getting to be too old.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: PeridexisErrant on January 26, 2018, 05:51:55 pm
Please don't try to support Windows XP - it's been unsupported for almost four years now, terribly insecure and a general PITA.  If you're using it, upgrade to Linux or a newer version of Windows as soon as possible.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: jecowa on January 26, 2018, 06:29:56 pm
Kubuntu might be a good choice for playing Dwarf Fortress on older computers. Kubuntu seems to be popular with Dwarf Fortress Linux users. Kubuntu is a good choice because it is the same as the most-user-friendly Linux distribution (Ubuntu) except it uses KDE and Qt instead of Gnome, and it is also Debian-based (which is what Dwarf Fortress is built for). With Kubuntu having so many Dwarf Fortress users, it might be easier to get technical help.

For a computer with less than 2 GB of RAM, Xubuntu or Lubuntu might be better choices. They are also Debian-based forks of Ubuntu. I'd probably pick Lubuntu of those two because it includes lighter-weight office software than the full-featured LibreOffice.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Robsoie on January 26, 2018, 06:40:41 pm
Why Kubuntu and not Linux Mint ?
I had installed Mint on a relative old laptop in order to get it usable again for just browsing, as it wasn't mine i didn't had the idea to try to run DF on it, it looked easy and light enough for the browsing at least.

Is there something with Kubuntu that makes it a better choice for linux and DF than mint ?

Anyways, thanks lethosor for looking into the matter, i thought it had to do with how XP does not make use those roaming application data folders, didn't thought it had to do with a msvc 2015 problem.
No problem with me though, i'll just use latest df on my slightly more recent PC to be able to use dfhack , my old xp based laptop will still be my 34.11 base :)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 26, 2018, 06:43:54 pm
DF and DFHack are entirely self-contained and don't use data folders outside of the DF folder.

It's generally pretty easy to set DF up on Ubuntu/Debian-based distros because that's what Toady uses. That doesn't mean other distros aren't also easy to use - if you're familiar with Mint and can get DF running on it, that's fine.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Robsoie on January 26, 2018, 07:08:34 pm
Ah thanks, i see , i was wondering if there was any specifics to Kubuntu that made it more DF friendly than other distros, good to see it was just a matter of preference in the end.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: strainer on January 27, 2018, 06:22:42 pm
Development of the OS windows clone "Reactos (https://www.reactos.org/) has exploded since recently moving to github and may have an XP replacement in beta this year.

I found a personality key -
"likes working outdoors and grumbles only mildly..." is in :
Code: [Select]
unit->status.current_soul->personality.unk_v4019_1
Values are 0 =none, 1 = "...at least for a while", 2 ="...only mildly at inclement weather".

Apparently this means the unit cares less about sleeping on floors and things, but has nothing to do with caveAdapt.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: PatrikLundell on January 28, 2018, 03:14:19 am
Development of the OS windows clone "Reactos (https://www.reactos.org/) has exploded since recently moving to github and may have an XP replacement in beta this year.

I found a personality key -
"likes working outdoors and grumbles only mildly..." is in :
Code: [Select]
unit->status.current_soul->personality.unk_v4019_1
Values are 0 =none, 1 = "...at least for a while", 2 ="...only mildly at inclement weather".

Apparently this means the unit cares less about sleeping on floors and things, but has nothing to do with caveAdapt.
If you go by the text, it means the dorfs are less negative to being out on the surface than normal dorfs, including being blinded by the sun and rained/snowed upon (and I assume this applies only to normal precipitation, not evil rain). That should make those dorfs suitable candidates for jobs such as herbalists, hunters, fisherdwarves, and wood cutters.
If you look at dorf thoughts you'll see they often get negative thoughts from being irritated by the sun and being rained upon.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: strainer on January 28, 2018, 08:46:11 am
@PatriKLundell
This trait is described on the wiki and elsewhere as not especially relating to being outdoors, "they get significantly reduced happiness penalities from having to do without the comforts of civilization, "
Dwarves get unhappy and sick going outside when their "caveAdapt" counter gets high from spending several seasons without seeing daylight. After a year or two without daylight they throw up every time the go out. The caveAdapt counter is in status.misc_traits and there is a LikesOutdoors counter/key beside it, but it is inactive now and the personality.unk_v4019_1 key holds this detail.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Pvt. Pirate on January 28, 2018, 10:34:04 am
Please don't try to support Windows XP - it's been unsupported for almost four years now, terribly insecure and a general PITA.  If you're using it, upgrade to Linux or a newer version of Windows as soon as possible.
if you're not forced to use directX, i recommend any linux/ubuntu version.
example: linux mint tries to get as close as possible to XP in UI and menus etc. which makes switching to a new system easier.

enough offtopic.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Roses on January 29, 2018, 03:11:01 pm
Not sure if anyone else knows about this, but you can make a reaction take as long as you want by running a script that continually sets the job.completion_timer to -1. For example this function
Code: [Select]
function delayReaction(n,job)
 n = n - 1
 if n<1 then return end
 dfhack.timeout(1,'ticks',function () delayReaction(n,job) end)
end
Will cause a job to take as many ticks as you specify (n). Linking this with eventfuls onJobInitiated seems to be enough for delayed reactions. I tested by making a dwarf work a single reaction for a full day.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: lethosor on January 29, 2018, 03:34:08 pm
I don't see where that modifies completion_timer; is it missing something?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Roses on January 29, 2018, 03:37:49 pm
I don't see where that modifies completion_timer; is it missing something?

Yes it is!
Code: [Select]
function delayReaction(n,job)
 n = n - 1
 if n<1 then return end
 job.completion_timer = -1
 dfhack.timeout(1,'ticks',function () delayReaction(n,job) end)
end
That's what I get for not copy/pasting
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Warmist on January 30, 2018, 03:15:08 am
Does anyone have much experience with dissecting the reports from DF? I am trying to get the units involved in combat reports, for instance we have a combat dodge report "Dwarf 3 attacks Dwarf 4 but she jumps away!". Now I know I can use the report.id and look through all the active units to find which unit has that report.id in their reports field, but what I can't do is figure out which is which. The only thing I could think of would be to compare the names and match them that way, but that would mean I would have hard code each string option.
I've done some report work for multiplayer:  probably this (https://github.com/warmist/df_multiplay/blob/master/messages.lua#L60) is what you are looking for?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: mifki on January 30, 2018, 03:56:01 am
Does anyone have much experience with dissecting the reports from DF? I am trying to get the units involved in combat reports, for instance we have a combat dodge report "Dwarf 3 attacks Dwarf 4 but she jumps away!". Now I know I can use the report.id and look through all the active units to find which unit has that report.id in their reports field, but what I can't do is figure out which is which. The only thing I could think of would be to compare the names and match them that way, but that would mean I would have hard code each string option.
I've done some report work for multiplayer:  probably this (https://github.com/warmist/df_multiplay/blob/master/messages.lua#L60) is what you are looking for?

I think he wants to know IDs of Dwarf 3 and Dwarf 4 in "Dwarf 3 attacks Dwarf 4 but she jumps away!". If so, maybe you can't do it at all - something happened, the game generated a report, and that's it, only the text is stored.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Roses on January 30, 2018, 10:21:00 am
Does anyone have much experience with dissecting the reports from DF? I am trying to get the units involved in combat reports, for instance we have a combat dodge report "Dwarf 3 attacks Dwarf 4 but she jumps away!". Now I know I can use the report.id and look through all the active units to find which unit has that report.id in their reports field, but what I can't do is figure out which is which. The only thing I could think of would be to compare the names and match them that way, but that would mean I would have hard code each string option.
I've done some report work for multiplayer:  probably this (https://github.com/warmist/df_multiplay/blob/master/messages.lua#L60) is what you are looking for?

I think he wants to know IDs of Dwarf 3 and Dwarf 4 in "Dwarf 3 attacks Dwarf 4 but she jumps away!". If so, maybe you can't do it at all - something happened, the game generated a report, and that's it, only the text is stored.

Yes, that's exactly what I wanted, but I think you are correct, I don't think that information is stored anywhere, which is disappointing. I wonder if all the report strings begin with the name of the "actor". Since I know which two units are involved I could just check the name of one of them and figure it out from there, maybe?
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: martinuzz on February 02, 2018, 07:04:34 am
Is there a command that shows the raws of a creature? I just changed my save raws, so that cave dragons will grow to full size in 125 years instead of 1000, and I want to check if newly hatched dragons use the new raws.

Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Rose on February 02, 2018, 07:36:28 am
Raws aren't stored per creature at all, only per race, but you can check the sizes of creatures using gm-editor.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: martinuzz on February 02, 2018, 08:40:28 am
Ah, I'll see if I can figure out how gm-editor works.

I'm mostly sure that the newly hatched dragons will have been generated from the new raws.
You saying that raws aren't stored per creature makes me a bit more sure even.
My only doubt is whether eggs/hatchlings are generated from their parent's raws (dunno how much of genetics / hereditary traits is in the game), or just from the normal raws.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: PatrikLundell on February 02, 2018, 10:13:13 am
Changes to the raws didn't affect existing creatures of that race when I tried it, but new ones were affected (in my case I tried to name dogs and cats differently depending on gender).
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: hertggf on February 02, 2018, 04:33:36 pm
What happens is that the saved data of existing creatures will be reinterpreted according to the new raws.  So for example if you change the variation rules (height,width,hair color, etc), existing creatures will keep their
existing variation numbers but new ones will use the new rules; on the other hand if you change say the material value multiplier, it'll change existing creatures too.
You can view the raws the game is using for your race by finding the race id of your creature, then entering
Code: [Select]
for k,v in pairs(df.global.world.raws.creatures.all[RACEID].raws) do print(v.value);endinto the console, replacing RACEID with the number you found.
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Warmist on February 04, 2018, 04:23:21 pm
What happens is that the saved data of existing creatures will be reinterpreted according to the new raws.  So for example if you change the variation rules (height,width,hair color, etc), existing creatures will keep their
existing variation numbers but new ones will use the new rules; on the other hand if you change say the material value multiplier, it'll change existing creatures too.
You can view the raws the game is using for your race by finding the race id of your creature, then entering
Code: [Select]
for k,v in pairs(df.global.world.raws.creatures.all[RACEID].raws) do print(v.value);endinto the console, replacing RACEID with the number you found.
or printall(df.race.find(raceid)) (AFAIR)
Title: Re: DFHack 0.43.05-r3.1 | 0.44.05-alpha1 (dev)
Post by: Putnam on February 04, 2018, 06:00:35 pm
df.creature_raw.find, in fact
Title: Re: DFHack 0.44.05-r1
Post by: lethosor on February 05, 2018, 02:04:52 am
New release! https://github.com/DFHack/dfhack/releases/tag/0.44.05-r1
Title: Re: DFHack 0.44.05-r1
Post by: dermal_plating on February 06, 2018, 01:30:22 am
New release! https://github.com/DFHack/dfhack/releases/tag/0.44.05-r1

Thanks team!
Title: Re: DFHack 0.44.05-r1
Post by: Criperum on February 06, 2018, 08:14:29 am
I have a question. Is there a way to temporary hide UI improvements brought by DFHack from the game? I mean searches, advanced views, new windows etc.
Title: Re: DFHack 0.44.05-r1
Post by: PatrikLundell on February 06, 2018, 08:35:28 am
I have a question. Is there a way to temporary hide UI improvements brought by DFHack from the game? I mean searches, advanced views, new windows etc.
- Stop DF
- Disable DFHack
- Start DF
- Do whatever you want to do
- Stop DF
- Enable DFHack
Title: Re: DFHack 0.44.05-r1
Post by: lethosor on February 06, 2018, 09:52:57 am
Or "unload -all" to unload all plugins, which should stop most UI changes (except for a few implemented by scripts that create new screens), then "load -all" to load them again. Note that loading them won't actually enable them; you'll have to enable them all manually again, or run "script dfhack.init" to re-run dfhack.init, which would probably work for most things.

These are all the plugins that currently hook into DF virtual methods - usually this affects the UI in some way, but a few might not (like building-hacks). The corresponding "disable" command for convenience:
Code: [Select]
disable add-spatter autochop autodump autogems automaterial automelt autotrade building-hacks buildingplan confirm dwarfmonitor embark-tools eventful fix-armory hotkey-commands manipulator mousequery power-meter rename rendermax resume search siege-engine steam-engine stockflow stockpiles stocks title-version trackstop tweak zone
There's also TWBT - I'm not sure if you're using or counting that, but it can't be disabled once it's been enabled, so if you want to stop that, you do have to restart DF in the process.
Title: Re: DFHack 0.44.05-r1
Post by: Pvt. Pirate on February 06, 2018, 10:17:47 am
would it be possible to expand the right hand side list? i mean in most cases it shows like 10 rows when there's a lot of empty/black space below and i have to scroll down a terribly long list - like when watching a tile's or creature's items or selecting materials for a building.
Title: Re: DFHack 0.44.05-r1
Post by: Criperum on February 06, 2018, 10:18:20 am
Or "unload -all" to unload all plugins, which should stop most UI changes (except for a few implemented by scripts that create new screens), then "load -all" to load them again. Note that loading them won't actually enable them; you'll have to enable them all manually again, or run "script dfhack.init" to re-run dfhack.init, which would probably work for most things.

These are all the plugins that currently hook into DF virtual methods - usually this affects the UI in some way, but a few might not (like building-hacks). The corresponding "disable" command for convenience:
Code: [Select]
disable add-spatter autochop autodump autogems automaterial automelt autotrade building-hacks buildingplan confirm dwarfmonitor embark-tools eventful fix-armory hotkey-commands manipulator mousequery power-meter rename rendermax resume search siege-engine steam-engine stockflow stockpiles stocks title-version trackstop tweak zone
There's also TWBT - I'm not sure if you're using or counting that, but it can't be disabled once it's been enabled, so if you want to stop that, you do have to restart DF in the process.

Thanks
Title: Re: DFHack 0.44.05-r1
Post by: lethosor on February 06, 2018, 10:36:38 am
would it be possible to expand the right hand side list? i mean in most cases it shows like 10 rows when there's a lot of empty/black space below and i have to scroll down a terribly long list - like when watching a tile's or creature's items or selecting materials for a building.
Not easily. That might be better as a DF suggestion (not sure if it's been suggested yet). I know some of the newer sidebar menus support that, as well as some older ones like the "b" and "k" menu (is that what you meant by "watching a tile's items"? It's taking up the full screen height for me in 0.44.05).
Title: Re: DFHack 0.44.05-r1
Post by: hertggf on February 09, 2018, 04:35:34 pm
I found an error in devel/inject-raws.lua.  I haven't gotten around to figuring out git so I'll just post it here:
line 109: gloves = { df.itemdef_glovest, itemdefs.gloves, 'gloves_type' },
should be: gloves = { df.itemdef_glovesst, itemdefs.gloves, 'gloves_type' },
Title: Re: DFHack 0.44.05-r1
Post by: lethosor on February 09, 2018, 04:51:51 pm
Thanks, fixed. It's really the first s that should be added; the "st" suffix is used by a lot of DF classes. The line below had the same issue (should have been itemdef_shoesst, not itemdef_shoest).
Title: Re: DFHack 0.44.05-r1
Post by: Roses on February 10, 2018, 12:33:55 am
Alright, so I've asked similar questions before, but this one is a little more concrete. Does anyone know of a way to make attacks able to hit from more than one square away?

I just spent the last hour adding attacks to units in arena mode and changing all the flags and unk variables to try all the various combinations but I had no luck. The attacks only ever connected and generated a report when the two units were within 1 square of each other. It makes me think it isn't possible, but I'm trying to create special skills that can hit from more than one square away and still using the standard attack action (think something like a magic flame whip).
Title: Re: DFHack 0.44.05-r1
Post by: Putnam on February 10, 2018, 01:11:30 am
teleport to the square away on the tick the attack's going to hit then teleport back to starting location
Title: Re: DFHack 0.44.05-r1
Post by: Pvt. Pirate on February 10, 2018, 04:17:48 am
Alright, so I've asked similar questions before, but this one is a little more concrete. Does anyone know of a way to make attacks able to hit from more than one square away?

I just spent the last hour adding attacks to units in arena mode and changing all the flags and unk variables to try all the various combinations but I had no luck. The attacks only ever connected and generated a report when the two units were within 1 square of each other. It makes me think it isn't possible, but I'm trying to create special skills that can hit from more than one square away and still using the standard attack action (think something like a magic flame whip).
my first idea was the spear. those weapons could only hit an enemy with the point if they were far enough.
Title: Re: DFHack 0.44.05-r1
Post by: iceball3 on February 11, 2018, 03:03:20 am
Alright, so I've asked similar questions before, but this one is a little more concrete. Does anyone know of a way to make attacks able to hit from more than one square away?

I just spent the last hour adding attacks to units in arena mode and changing all the flags and unk variables to try all the various combinations but I had no luck. The attacks only ever connected and generated a report when the two units were within 1 square of each other. It makes me think it isn't possible, but I'm trying to create special skills that can hit from more than one square away and still using the standard attack action (think something like a magic flame whip).
my first idea was the spear. those weapons could only hit an enemy with the point if they were far enough.
Can't you hit someone with a spear at point blank? You can literally hold the spear right under the blade and shove it in to someone who's just about on top of you. The spear is a bit unwieldy at point blank, but is absolutely not worthless.
Title: Re: DFHack 0.44.05-r1
Post by: Pvt. Pirate on February 12, 2018, 05:13:38 am
Alright, so I've asked similar questions before, but this one is a little more concrete. Does anyone know of a way to make attacks able to hit from more than one square away?

I just spent the last hour adding attacks to units in arena mode and changing all the flags and unk variables to try all the various combinations but I had no luck. The attacks only ever connected and generated a report when the two units were within 1 square of each other. It makes me think it isn't possible, but I'm trying to create special skills that can hit from more than one square away and still using the standard attack action (think something like a magic flame whip).
my first idea was the spear. those weapons could only hit an enemy with the point if they were far enough.
Can't you hit someone with a spear at point blank? You can literally hold the spear right under the blade and shove it in to someone who's just about on top of you. The spear is a bit unwieldy at point blank, but is absolutely not worthless.
well, using a spear (3m and longer) effective would mean you keep the enemy at distance and if they come closer, you can still hit them with the blunt shaft, but no more stabby stabby.
Title: Re: DFHack 0.44.05-r1
Post by: Warmist on February 12, 2018, 08:50:05 am
Alright, so I've asked similar questions before, but this one is a little more concrete. Does anyone know of a way to make attacks able to hit from more than one square away?

I just spent the last hour adding attacks to units in arena mode and changing all the flags and unk variables to try all the various combinations but I had no luck. The attacks only ever connected and generated a report when the two units were within 1 square of each other. It makes me think it isn't possible, but I'm trying to create special skills that can hit from more than one square away and still using the standard attack action (think something like a magic flame whip).
Was it by adding action attack? Because i might be misremembering but i think i had attacks happen which ignored distance by adding a new (or modifying old) action.
Title: Re: DFHack 0.44.05-r1
Post by: Roses on February 12, 2018, 01:10:14 pm
Alright, so I've asked similar questions before, but this one is a little more concrete. Does anyone know of a way to make attacks able to hit from more than one square away?

I just spent the last hour adding attacks to units in arena mode and changing all the flags and unk variables to try all the various combinations but I had no luck. The attacks only ever connected and generated a report when the two units were within 1 square of each other. It makes me think it isn't possible, but I'm trying to create special skills that can hit from more than one square away and still using the standard attack action (think something like a magic flame whip).
Was it by adding action attack? Because i might be misremembering but i think i had attacks happen which ignored distance by adding a new (or modifying old) action.

It was adding an action attack, or more specifically adding an action with type 1 (Attack) and filling in the action.data.attack variables. Works just fine if the units are next to eachother. Doesn't work if they are more than 1 space away from eachother. If you managed to get it to work I would love to know how!

teleport to the square away on the tick the attack's going to hit then teleport back to starting location

Unless Warmist has the magic bullet I think you are right. I worry a little bit about the effects of teleporting away for 1 or 2 ticks, but if it's used sparingly it should be ok
Title: Re: DFHack 0.44.05-r1
Post by: Putnam on February 12, 2018, 06:32:15 pm
If you use the function provided in teleport.lua, it should be completely side-effect free
Title: Re: DFHack 0.44.05-r1
Post by: Roses on February 12, 2018, 07:29:59 pm
If you use the function provided in teleport.lua, it should be completely side-effect free

I more meant if the unit was being attacked or shot at and they weren't in the tile anymore they would get a free "dodge" of sorts. Or if they teleported into dragons fire or something like that
Title: Re: DFHack 0.44.05-r1
Post by: AVE on February 20, 2018, 04:09:44 am
How do I use steam engine plugin? Documentation about when it enables itself is very vague, literally "detects custom workshops with STEAM_ENGINE in their token".

So, I need to create a new building with [STEAM_ENGINE] tag? How should I define it? It is mentioned afterwards that power is transmitted through edge tiles "that looks like gearboxes". What happens if I do NOT define tiles to look like gearboxes?

BTW, I use latest LNP if it helps.
Title: Re: DFHack 0.44.05-r1
Post by: Putnam on February 20, 2018, 05:33:28 am
How do I use steam engine plugin? Documentation about when it enables itself is very vague, literally "detects custom workshops with STEAM_ENGINE in their token".

So, I need to create a new building with [STEAM_ENGINE] tag? How should I define it? It is mentioned afterwards that power is transmitted through edge tiles "that looks like gearboxes". What happens if I do NOT define tiles to look like gearboxes?

BTW, I use latest LNP if it helps.

1. That's straight up it. A building with STEAM_ENGINE in its tag will be a steam engine.

2.
Code: [Select]
out.printerr("%s has no gear tiles - ignoring.\n", wslist[i]->code.c_str());
So if you define a workshop called STEAM_ENGINE_AVE without any gearbox tiles, DFHack will give you an error saying "STEAM_ENGINE_AVE has no gear tiles - ignoring."
Title: Re: DFHack 0.44.05-r1
Post by: AVE on February 20, 2018, 06:09:58 am
Should I define "Stoke Boiler" reaction or will it be autoinjected? If not, how shoud I define it? Also, it is mentioned that workshop should be constructed from barrel, pipe and "piston". If I omit this parts in building definition, will they be autoinjected also? Because I dunno what is that aforementioned "piston" and to what item category it should belong.
Title: Re: DFHack 0.44.05-r1
Post by: Putnam on February 20, 2018, 06:30:18 am
1. I'd assume it's autoinjected unless proven otherwise.
2. I'd guess that you can let it be built however you damn well please, with any items you want it to, since it uses a building definition. If I were to implement a "piston", I'd make it a tool or trap component.
Title: Re: DFHack 0.44.05-r1
Post by: AVE on February 20, 2018, 06:58:12 am
1. I'd assume it's autoinjected unless proven otherwise.
2. I'd guess that you can let it be built however you damn well please, with any items you want it to, since it uses a building definition. If I were to implement a "piston", I'd make it a tool or trap component.
OK, I feel like an idiot now. Instead of asking (stupid) questions I should've looked into dfhack directory. There it is, hack/raw. It contains everything I asked for, every definition, every reaction. I think I'll just copy everything that belongs to steam engine from there and try to gen a world.

Thank you for your help!
Title: Re: DFHack 0.44.05-r1
Post by: iceball3 on February 20, 2018, 07:24:44 am
Alright, so I've asked similar questions before, but this one is a little more concrete. Does anyone know of a way to make attacks able to hit from more than one square away?

I just spent the last hour adding attacks to units in arena mode and changing all the flags and unk variables to try all the various combinations but I had no luck. The attacks only ever connected and generated a report when the two units were within 1 square of each other. It makes me think it isn't possible, but I'm trying to create special skills that can hit from more than one square away and still using the standard attack action (think something like a magic flame whip).
my first idea was the spear. those weapons could only hit an enemy with the point if they were far enough.
Can't you hit someone with a spear at point blank? You can literally hold the spear right under the blade and shove it in to someone who's just about on top of you. The spear is a bit unwieldy at point blank, but is absolutely not worthless.
well, using a spear (3m and longer) effective would mean you keep the enemy at distance and if they come closer, you can still hit them with the blunt shaft, but no more stabby stabby.
If you hold the spear underneath the blade, you can simply use it like a difficultly balanced dagger. That's far from being denied use of the business end of a spear. There would be a bit of hangage but at that point, it's more a question of if someone can actually command a hold on your weapon and not just whether you can touch a hostile or not.
That, and 3m spears would probably count as pikes at that point..
Title: Re: DFHack 0.44.05-r1
Post by: PatrikLundell on February 20, 2018, 08:07:17 am
Before issuing a bug report: Is hauling of damaged goods to the refuse stockpile a vanilla feature or added by DFHack? In my case it's a cage containing a captured ogre, and I don't think the cage should be discarded until it has been emptied.
Title: Re: DFHack 0.44.05-r1
Post by: lethosor on February 20, 2018, 09:45:34 am
Fairly certain that's vanilla, but try running DF without DFHack to be sure.
Title: Re: DFHack 0.44.05-r1
Post by: Pvt. Pirate on February 20, 2018, 10:52:02 am
Alright, so I've asked similar questions before, but this one is a little more concrete. Does anyone know of a way to make attacks able to hit from more than one square away?

I just spent the last hour adding attacks to units in arena mode and changing all the flags and unk variables to try all the various combinations but I had no luck. The attacks only ever connected and generated a report when the two units were within 1 square of each other. It makes me think it isn't possible, but I'm trying to create special skills that can hit from more than one square away and still using the standard attack action (think something like a magic flame whip).
my first idea was the spear. those weapons could only hit an enemy with the point if they were far enough.
Can't you hit someone with a spear at point blank? You can literally hold the spear right under the blade and shove it in to someone who's just about on top of you. The spear is a bit unwieldy at point blank, but is absolutely not worthless.
well, using a spear (3m and longer) effective would mean you keep the enemy at distance and if they come closer, you can still hit them with the blunt shaft, but no more stabby stabby.
If you hold the spear underneath the blade, you can simply use it like a difficultly balanced dagger. That's far from being denied use of the business end of a spear. There would be a bit of hangage but at that point, it's more a question of if someone can actually command a hold on your weapon and not just whether you can touch a hostile or not.
That, and 3m spears would probably count as pikes at that point..
however this maneuver puts the wielder in a high risk of losing their weapon.
also when the attacker gets past the point of the spear and gets into melee range, there's no time left for the wielder of the spear to pull back the spear and change the grip position and maneuvering the point back between them and the attacker.
Title: Re: DFHack 0.44.05-r1
Post by: Boltgun on February 21, 2018, 04:12:24 am
Create-unit need an update. Around l340 there is some old hack to avoid hostility that involve anon fields that do not exist anymore. I also took the chance to make it use the random caste selection function if you do not provide the -caste parameter, making it optional (l481).

Here's an updated version. (https://github.com/Devduweb/DF-succubus/blob/master/succubus-prod/raw/scripts/modtools/create-unit.lua) Is it big enough to require a pull request or you can handle it yourself?

By the way, it seems that units created for your civ and group is hostile for some time between 1 and ~60 frames. I think it means that the hostility cache must be invalidated. I'll give it a try and tell you if this is the case.

There is also an issue with names. In 44.05 the newly created unit get their arena name (ie Dog #12345) as their "First name" and I can't figure a way to wipe it except invoking the name method to overwrite it with a proper civ name. This does not respect the usual naming values and even emptying it cause DF reapply the name right after.
Title: Re: DFHack 0.44.05-r2
Post by: lethosor on February 22, 2018, 01:32:15 am
New (small) release: https://github.com/DFHack/dfhack/releases/tag/0.44.05-r2

I suppose a pull request would have been better there; there's no such thing as a pull request that's "too small", at least for our purposes. I'll get that change in soon.

Why are you setting first_name to "", by the way? I seem to remember taking something like that (if not exactly that) out because it produced unwanted behavior in fortress or arena mode - did you test both?
Title: Re: DFHack 0.44.05-r2
Post by: Boltgun on February 22, 2018, 03:11:33 am
Why are you setting first_name to "", by the way? I seem to remember taking something like that (if not exactly that) out because it produced unwanted behavior in fortress or arena mode - did you test both?

I tested it in for mode, and will check arena asap. It was part of an attempt to remove the arena name in fort mode but that did not work, but did not cause weird behavior in this version.
Title: Re: DFHack 0.44.05-r1
Post by: ShinyBluePen on February 27, 2018, 08:22:00 am
Hey all!

I'm having an issue with the mouse controls that I'm not sure how to resolve.  With the last version of the LNP mouse controls, it wouldn't try to go down Z levels when I moved over a ramp or open space; like it does with the current version.  Mouse controls are awesome and I'd like to keep using them, but the automatic teleporting from moving my cursor over empty space is really annoying, especially in the caverns.

Is there anything I can do to disable only the auto switching of Z-levels?

Warm regards
Title: Re: DFHack 0.44.05-r2
Post by: lethosor on February 27, 2018, 08:36:07 am
Are you using TWBT or the mousequery plugin distributed with TWBT? Those might be causing it. I haven't seen that behavior with the default mousequery plugin, anyway.
Title: Re: DFHack 0.44.05-r2
Post by: jecowa on February 27, 2018, 01:41:00 pm
I've tried with TWBT mousequery and with vanilla mousequery.
I've tried with STANDARD, 2D, and TWBT print mode.
I've tried with the intro video on and off.
I've tried with mousequery edge enabled and disabled.
I've tried with mousequery live enabled and disabled.
I've tried while pause, while not paused, and I've tried clicking on the ramps.
But I've never seen the Z levels change by just using the mouse. I have no idea how that is happening.
Title: Re: DFHack 0.44.05-r2
Post by: lethosor on February 27, 2018, 02:16:13 pm
Thanks for testing all of those. ShinyBluePen, is it possible that you have tap-to-click turned on (system-wide) and don't realize it?
Title: Re: DFHack 0.44.05-r1
Post by: Urlance Woolsbane on February 27, 2018, 03:34:51 pm
There is also an issue with names. In 44.05 the newly created unit get their arena name (ie Dog #12345) as their "First name" and I can't figure a way to wipe it except invoking the name method to overwrite it with a proper civ name. This does not respect the usual naming values and even emptying it cause DF reapply the name right after.
For what it's worth, I noticed this while messing around with the 43.05 version of Masterwork's Hermit Mode. One can order as many "hermits" from the starting workshop as you like; the kill script only triggers once the last task is finished. In the course of my borkery, I noticed that some units had the Arena naming scheme. I'm not sure what made a difference, though I wouldn't be surprised if it were something caste-related.
Title: Re: DFHack 0.44.05-r2
Post by: Putnam on February 27, 2018, 09:57:38 pm
I've tried with TWBT mousequery and with vanilla mousequery.
I've tried with STANDARD, 2D, and TWBT print mode.
I've tried with the intro video on and off.
I've tried with mousequery edge enabled and disabled.
I've tried with mousequery live enabled and disabled.
I've tried while pause, while not paused, and I've tried clicking on the ramps.
But I've never seen the Z levels change by just using the mouse. I have no idea how that is happening.

I have had this problem at random when testing mousequery compatibility with a graphical UI overhaul I was trying to make (again). I couldn't replicate it except by basically just rapidly left and right clicking randomly, and that wasn't consistent.
Title: Re: DFHack 0.44.05-r2
Post by: Pvt. Pirate on February 28, 2018, 07:59:12 am
I've tried with TWBT mousequery and with vanilla mousequery.
I've tried with STANDARD, 2D, and TWBT print mode.
I've tried with the intro video on and off.
I've tried with mousequery edge enabled and disabled.
I've tried with mousequery live enabled and disabled.
I've tried while pause, while not paused, and I've tried clicking on the ramps.
But I've never seen the Z levels change by just using the mouse. I have no idea how that is happening.
i only got problems with mousequery when using multilevel view.
Title: Re: DFHack 0.44.05-r2
Post by: mifki on February 28, 2018, 06:12:20 pm
I've tried with TWBT mousequery and with vanilla mousequery.
I've tried with STANDARD, 2D, and TWBT print mode.
I've tried with the intro video on and off.
I've tried with mousequery edge enabled and disabled.
I've tried with mousequery live enabled and disabled.
I've tried while pause, while not paused, and I've tried clicking on the ramps.
But I've never seen the Z levels change by just using the mouse. I have no idea how that is happening.
i only got problems with mousequery when using multilevel view.

What problems?
Title: Re: DFHack 0.44.05-r2
Post by: Pvt. Pirate on March 01, 2018, 05:34:46 am
I've tried with TWBT mousequery and with vanilla mousequery.
I've tried with STANDARD, 2D, and TWBT print mode.
I've tried with the intro video on and off.
I've tried with mousequery edge enabled and disabled.
I've tried with mousequery live enabled and disabled.
I've tried while pause, while not paused, and I've tried clicking on the ramps.
But I've never seen the Z levels change by just using the mouse. I have no idea how that is happening.
i only got problems with mousequery when using multilevel view.

What problems?
using meph's pack, aswell as with peridexerrant's, it often fails to react on the mouse position (mousequery edge enabled) when there are no tiles in the mouse location on the current layer. the same position scrolls perfect when multilevel view is disabled.
i do not know what method is used to check for the mouse position, but it fails too often. also with multilevel view it is impossible to place constructions (floor, fortification) on open space - you have to use the arrowkeys to navigate on open space.
Title: Re: DFHack 0.44.05-r2
Post by: mifki on March 01, 2018, 08:36:12 am
I've tried with TWBT mousequery and with vanilla mousequery.
I've tried with STANDARD, 2D, and TWBT print mode.
I've tried with the intro video on and off.
I've tried with mousequery edge enabled and disabled.
I've tried with mousequery live enabled and disabled.
I've tried while pause, while not paused, and I've tried clicking on the ramps.
But I've never seen the Z levels change by just using the mouse. I have no idea how that is happening.
i only got problems with mousequery when using multilevel view.

What problems?
using meph's pack, aswell as with peridexerrant's, it often fails to react on the mouse position (mousequery edge enabled) when there are no tiles in the mouse location on the current layer. the same position scrolls perfect when multilevel view is disabled.
i do not know what method is used to check for the mouse position, but it fails too often. also with multilevel view it is impossible to place constructions (floor, fortification) on open space - you have to use the arrowkeys to navigate on open space.

I don't know what's included in the packs, but with mousequery plugin from twbt package you definitely can place constructions on open space. Edge scroll seems to work ok too but I can't be sure as I'm not using it myself, just tested a bit now.
Title: Re: DFHack 0.44.05-r2
Post by: Pvt. Pirate on March 01, 2018, 08:48:55 am
I've tried with TWBT mousequery and with vanilla mousequery.
I've tried with STANDARD, 2D, and TWBT print mode.
I've tried with the intro video on and off.
I've tried with mousequery edge enabled and disabled.
I've tried with mousequery live enabled and disabled.
I've tried while pause, while not paused, and I've tried clicking on the ramps.
But I've never seen the Z levels change by just using the mouse. I have no idea how that is happening.
i only got problems with mousequery when using multilevel view.

What problems?
using meph's pack, aswell as with peridexerrant's, it often fails to react on the mouse position (mousequery edge enabled) when there are no tiles in the mouse location on the current layer. the same position scrolls perfect when multilevel view is disabled.
i do not know what method is used to check for the mouse position, but it fails too often. also with multilevel view it is impossible to place constructions (floor, fortification) on open space - you have to use the arrowkeys to navigate on open space.

I don't know what's included in the packs, but with mousequery plugin from twbt package you definitely can place constructions on open space. Edge scroll seems to work ok too but I can't be sure as I'm not using it myself, just tested a bit now.
why are there two different versions then, if one works as intended and the other doesn't?
Title: Re: DFHack 0.44.05-r2
Post by: lethosor on March 01, 2018, 08:57:16 am
It used to be that only the TWBT version worked with TWBT enabled. I think now the only difference is some features in the TWBT version that need to be merged back into DFHack's version but haven't yet.
Title: Re: DFHack 0.44.05-r2
Post by: Pvt. Pirate on March 01, 2018, 10:26:15 am
then who could merge them back in?
Title: Re: DFHack 0.44.05-r2
Post by: lethosor on March 01, 2018, 10:46:15 am
Anyone could. It's open source.

However, that is probably not the cause of the issue you're seeing.
Title: Re: DFHack 0.44.05-r2
Post by: mifki on March 01, 2018, 07:09:27 pm
oops nevermind
Title: Re: DFHack 0.44.05-r2
Post by: Cathar on March 10, 2018, 01:33:20 pm
Apparently DFhack 0.44.05-r2 is not compatible with the new version. Could you update it ? Or if it's not a hard process, describe how to update it ourselves so DF recognizes it ? Thanks a lot

Code: [Select]
DFHack build: 0.44.05-r2-0-g0e7ab278
Identifying DF version.
Loading hack\symbols.xml ... OK
v0.44.04 SDL win32 (windows): PE: 0x5a5687e6
v0.44.04 SDL win64 (windows): PE: 0x5a568f07
v0.44.05 SDL win32 (windows): PE: 0x5a5bb383
v0.44.05 SDL win64 (windows): PE: 0x5a5bbc62
v0.44.04 linux32 (linux): MD5: 73d7441bd0b819f9526d2ab07e4e7bf5
v0.44.04 linux64 (linux): MD5: ef636f3e494ec726d7995c1bc1423ca3
v0.44.05 linux32 (linux): MD5: 33e2bc29e7051576461ac444fdeaa191
v0.44.05 linux64 (linux): MD5: cfe90090090db079cf0ef75eda3c47c4
v0.44.04 osx32 (darwin): MD5: 4a5f7aad456d91fd073f0636cb1b2a22
v0.44.04 osx64 (darwin): MD5: bd9675557f27f4951ce3a411c371878c
v0.44.05 osx32 (darwin): MD5: a6962c195a4d7674c6e581c3609b60d8
v0.44.05 osx64 (darwin): MD5: b6a3104e7a90ed4b68f43893c5bb54c2
Loaded 12 DF symbol tables.
Unable to retrieve version information.
PE timestamp: 0x5aa2f81a
Title: Re: DFHack 0.44.05-r2
Post by: lethosor on March 10, 2018, 01:47:54 pm
What is "the new version"? 0.44.06? We will add support for it eventually, as we do for most DF versions. Note that DFHack (as well at DT, etc.) will never be compatible with DF versions newer than the one it was released for, because that would require us to predict the future.

If there's a 0.44.07 release that comes out in the next day or so to fix the crashes reported in 0.44.06, we might skip support for 0.44.06, though.
Title: Re: DFHack 0.44.05-r2
Post by: Cathar on March 10, 2018, 01:49:12 pm
Got it, thanks alot
Title: Re: DFHack 0.44.05-r2
Post by: Alu on March 13, 2018, 11:45:55 am
If there's a 0.44.07 release that comes out in the next day or so to fix the crashes reported in 0.44.06, we might skip support for 0.44.06, though.

you kind of did predict the future in the end.
Title: Re: DFHack 0.44.05-r2
Post by: Llamageddon on March 13, 2018, 12:41:17 pm
Was about to say the same thing. I now await with bated breath  :D
Title: Re: DFHack 0.44.05-r2
Post by: lethosor on March 13, 2018, 12:41:29 pm
I mean, it's a pretty typical pattern when an initial feature release has nasty bugs. Also, DFHack hasn't technically dropped support for 0.44.06 yet.
Title: Re: DFHack 0.44.05-r2
Post by: DaSwayza on March 13, 2018, 03:28:39 pm
I know I knew at some point, but I can't get the create-unit script to work. -civId and -localId \\LOCAL is not working
Title: Re: DFHack 0.44.05-r2
Post by: jeancallisti on March 14, 2018, 07:22:02 am
General question about dfhack: what's its inner timing in regards to the game's engine inner timing?
- At what point of the game loop does DFhack read and update its properties?
- Or, if all the properties are direct access to actual value in memory, then at what stage in the game loop do dfhack scripts get executed?
- what is the liberty of the scripter to move its script execution earlier or later in the game loop? (Is the timing different with DFHack plugins? Are there several native game events that can trigger a script execution from DFhack or do they always play at the same stage in the game loop?)
- can you do a very rough presentation of the order of computations that take place inside a native game loop?
Title: Re: DFHack 0.44.05-r2
Post by: Rose on March 14, 2018, 08:38:04 am
As far as I understand, there's one fixed point in the game loop where any dfhack commands are executed, which is where the DF exe polls the number of connected joysticks through SDL, which happens every frame.
Title: Re: DFHack 0.44.05-r2
Post by: lethosor on March 14, 2018, 10:06:41 am
General question about dfhack: what's its inner timing in regards to the game's engine inner timing?
- At what point of the game loop does DFhack read and update its properties?
- Or, if all the properties are direct access to actual value in memory, then at what stage in the game loop do dfhack scripts get executed?
They've been direct access since DFHack moved to being in-process. I don't remember when exactly this was, but it was probably around 2009-2010.

Like Japa said, SDL_GetNumJoysticks() is called once per game tick (corresponding to the "FPS" indicator), on the simulation thread, and DFHack hooks into that to run anything that needs to access DF data. This includes most plugin commands and all scripts.

Quote
- what is the liberty of the scripter to move its script execution earlier or later in the game loop?
Impossible, and I don't know why you would want to. Is there something specific you're trying to do? If so, there's probably already a way to do it that doesn't require hooking into the game loop at different points.

Quote
(Is the timing different with DFHack plugins? Are there several native game events that can trigger a script execution from DFhack or do they always play at the same stage in the game loop?)
Plugins have access to C++ features and can do whatever they want - they can spin off separate threads, for example, and run things whenever they want. However, the whole point of the per-tick hook is that it's safe to access game data at that point, because DF's simulation thread isn't doing anything else.

Plugins can intercept virtual method calls, which is usually safe. Scripts can't do that. In theory, a plugin could call a Lua script from an interposed vmethod (with some limitations, like being unable to make screens, I think).

Quote
- can you do a very rough presentation of the order of computations that take place inside a native game loop?
Nope. Disassembly could reveal some stuff, but it would take a lot of effort.

Again, is there something specific you're looking for? These questions seem like they have a purpose that isn't specified.
Title: Re: DFHack 0.44.05-r2
Post by: fricy on March 14, 2018, 10:52:16 am
Again, is there something specific you're looking for? These questions seem like they have a purpose that isn't specified.
Hey, long time!
I assume it's about disabling the native pathfinding loop (http://www.bay12forums.com/smf/index.php?topic=169806.0).
Title: Re: DFHack 0.44.05-r2
Post by: lethosor on March 14, 2018, 12:54:07 pm
New alpha build! https://github.com/DFHack/dfhack/releases/tag/0.44.07-alpha1

Hey, long time!
Welcome back!
Quote
I assume it's about disabling the native pathfinding loop (http://www.bay12forums.com/smf/index.php?topic=169806.0).
YIKES.

That's definitely something that can only be done in a plugin and through lots of reverse-engineering, if it can be done at all.
Title: Re: DFHack 0.44.05-r2
Post by: mifki on March 14, 2018, 03:17:46 pm
Again, is there something specific you're looking for? These questions seem like they have a purpose that isn't specified.
Hey, long time!

Wow, welcome back!
Now we will get proper access to DFgraphics repo finally  :D

I assume it's about disabling the native pathfinding loop (http://www.bay12forums.com/smf/index.php?topic=169806.0).

That's what I was thinking about it for a long time but didn't have time to dig so deep.
Title: Re: DFHack 0.44.05-r2
Post by: fricy on March 14, 2018, 03:51:37 pm
Wow, welcome back!
Hey thanks, don't get your hopes up, just checked in, heard there's something new. I see you're still hammering on the gfx. :)

Now we will get proper access to DFgraphics repo finally  :D
What do you mean? Did I not gave access to others? Sh!t.  :o
Title: Re: DFHack 0.44.05-r2
Post by: mifki on March 14, 2018, 03:59:28 pm
Wow, welcome back!
Hey thanks, don't get your hopes up, just checked in, heard there's something new. I see you're still hammering on the gfx. :)

Real life happened or lost interest, may I ask?

Now we will get proper access to DFgraphics repo finally  :D
What do you mean? Did I not gave access to others? Sh!t.  :o

AFAIK only you had full admin rights.
Title: Re: DFHack 0.44.05-r2
Post by: fricy on March 14, 2018, 04:11:24 pm
Wow, welcome back!
Hey thanks, don't get your hopes up, just checked in, heard there's something new. I see you're still hammering on the gfx. :)

Real life happened or lost interest, may I ask?

Now we will get proper access to DFgraphics repo finally  :D
What do you mean? Did I not gave access to others? Sh!t.  :o

AFAIK only you had full admin rights.
RL. Some depressing shit happened I had to deal with, by the time it was mostly over I had some other stuff on my mind.
And Peredexiserrant seems to have GOD mode turned on in the repo, so you did have someone to bugger after all.  8)
Title: Re: DFHack 0.44.05-r2
Post by: mifki on March 14, 2018, 04:15:20 pm
Wow, welcome back!
Hey thanks, don't get your hopes up, just checked in, heard there's something new. I see you're still hammering on the gfx. :)

Real life happened or lost interest, may I ask?

Now we will get proper access to DFgraphics repo finally  :D
What do you mean? Did I not gave access to others? Sh!t.  :o

AFAIK only you had full admin rights.
RL. Some depressing shit happened I had to deal with, by the time it was mostly over I had some other stuff on my mind.
And Peredexiserrant seems to have GOD mode turned on in the repo, so you did have someone to bugger after all.  8)

Hope it's better now.

I'm talking about this http://www.bay12forums.com/smf/index.php?topic=155882.msg6921078#msg6921078
Title: Re: DFHack 0.44.05-r2
Post by: fricy on March 14, 2018, 04:31:26 pm
I'm talking about this http://www.bay12forums.com/smf/index.php?topic=155882.msg6921078#msg6921078
Hmm, IDK. He is owner now. I checked the permissions, there are only two levels: member/owner. I seem to remember I did give him admin rights back then, so it beats me. :(
I'm sure he'll chip in soon.
Title: Re: DFHack 0.44.05-r2
Post by: jeancallisti on March 14, 2018, 05:35:52 pm
Quote
I assume it's about disabling the native pathfinding loop (http://www.bay12forums.com/smf/index.php?topic=169806.0).
YIKES.
That's definitely something that can only be done in a plugin and through lots of reverse-engineering, if it can be done at all.

Relax, it might not be as bad as you think. We just need to think a little bit out of the box. By overwriting unit.path.dest, we managed to hijack the native pathfinding surprisingly easily, actually (for a very basic proof of concept). More about that on the other thread.

Now back to DFHack : the reason why I'm asking questions about the game loop sequence and when DFHack steps in, is to have a general idea of when some data is written to/from the world. The goal is to have a very vague idea of when it's (kind of) OK to read from it without a big-ass mutex, and if it's even OK to read from it at all because of any unforeseen issue (something like : gotcha, the game immediately overwrites the data you've just read because you're reading a very volatile, late game state meant only for just before frame rendering). If we'rte only trying to build some search indices from the world topology, then it's OK if it's not 100% accurate or up-to-date or real-time. And if it's definitley not OK to read anything (or set unit.path.dest) at the time DFHack runs, then my goal is to have a vague idea of when can I move (within a game loop) my processing. You have answered that part very clearly : with just a DFHack script, I can't.

So you said that with a plugin (a DFHack plugin I assume, there's not such thing as a DF plugin, correct?) I can intercept any call to virtual functions. By "intercept", do you mean detect or do you mean override? Are we talking DFHack functions or native DF functions? I can't imagine that you'd have entry points (headers???) to every native function, but then again I don't have a deep understanding of DFHack plugins. Quietust said (I think, I'm already forgetting who said this and if I'm quoting properly) that the only way to hijack the call to a native DF function is to patch the game; did I misunderstand what he said?
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: Rose on March 14, 2018, 10:17:55 pm
As far as I understand (and I may be wrong) Virtual functions are called via pointer in DF, so overriding those is as easy as replacing the pointer, but not all functions are virtual. Only certain ones that are part of certain classes are.
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: PeridexisErrant on March 15, 2018, 05:55:10 am
@fricy - great to see you again, and I'm glad things are going better (even if you're just checking in :-))

@mifki - a few posts below that I did get owner-access, and there's ~10ish people with member access.  Fricy, I , and as of now Jecowa all have owner access to add new people too.  Is there something you'd like to do with the repos?

(http://www.bay12forums.com/smf/index.php?topic=155882.msg6926426#msg6926426 )
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: mifki on March 15, 2018, 06:38:17 am
@mifki - a few posts below that I did get owner-access, and there's ~10ish people with member access.  Fricy, I , and as of now Jecowa all have owner access to add new people too.  Is there something you'd like to do with the repos?

(http://www.bay12forums.com/smf/index.php?topic=155882.msg6926426#msg6926426 )

Nope, I just didn't know.
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: Cathar on March 15, 2018, 08:41:24 am
Thank you so much for the update !
Title: Re: DFHack 0.44.05-r2
Post by: lethosor on March 15, 2018, 08:51:48 am
Quote
I assume it's about disabling the native pathfinding loop (http://www.bay12forums.com/smf/index.php?topic=169806.0).
YIKES.
That's definitely something that can only be done in a plugin and through lots of reverse-engineering, if it can be done at all.

Relax, it might not be as bad as you think. We just need to think a little bit out of the box. By overwriting unit.path.dest, we managed to hijack the native pathfinding surprisingly easily, actually (for a very basic proof of concept). More about that on the other thread.

Now back to DFHack : the reason why I'm asking questions about the game loop sequence and when DFHack steps in, is to have a general idea of when some data is written to/from the world. The goal is to have a very vague idea of when it's (kind of) OK to read from it without a big-ass mutex, and if it's even OK to read from it at all because of any unforeseen issue (something like : gotcha, the game immediately overwrites the data you've just read because you're reading a very volatile, late game state meant only for just before frame rendering). If we'rte only trying to build some search indices from the world topology, then it's OK if it's not 100% accurate or up-to-date or real-time. And if it's definitley not OK to read anything (or set unit.path.dest) at the time DFHack runs, then my goal is to have a vague idea of when can I move (within a game loop) my processing. You have answered that part very clearly : with just a DFHack script, I can't.

So you said that with a plugin (a DFHack plugin I assume, there's not such thing as a DF plugin, correct?) I can intercept any call to virtual functions. By "intercept", do you mean detect or do you mean override? Are we talking DFHack functions or native DF functions? I can't imagine that you'd have entry points (headers???) to every native function, but then again I don't have a deep understanding of DFHack plugins. Quietust said (I think, I'm already forgetting who said this and if I'm quoting properly) that the only way to hijack the call to a native DF function is to patch the game; did I misunderstand what he said?
Yes, adjusting a unit's path is trivial. Patching the pathfinding engine is not, depending on what you want to do.

By virtual methods, I'm referring to these (http://en.cppreference.com/w/cpp/language/virtual). Nothing in the pathfinding engine uses these, as far as I know. DFHack has a way to intercept calls to them (meaning call your own function instead of DF's), and a way to call DF's within intercepted calls, so it's trivial to make something just to detect calls.

If it turns out that you need to patch the pathfinding engine, you probably want to do that in C++. I suspect that running your own pathfinding algorithm after DF's can be done at any time (when DF's simulation thread isn't busy), but you'll also want to keep DF's from running, and run yours instead when DF expects pathfinding to be done. Technically, you can patch executable code from Lua as well, but if you're writing your own function for DF to call, that'll need to be done in C++.
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: jeancallisti on March 15, 2018, 10:40:26 am
So if we assume that the pathfinding function is virtual and if we assume that I want to run my own code instead, written in C++ as a DFHack plugin, then what's the underlying code base? Like, would it be possible (without it being too clumsy or hard to maintain) to use stuff like C++11 and std::async ? (Don't worry about sync'ing the threads, leave that to me). Is 'std' available at all?
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: Roses on March 15, 2018, 11:48:24 am
So if we assume that the pathfinding function is virtual and if we assume that I want to run my own code instead, written in C++ as a DFHack plugin, then what's the underlying code base? Like, would it be possible (without it being too clumsy or hard to maintain) to use stuff like C++11 and std::async ? (Don't worry about sync'ing the threads, leave that to me). Is 'std' available at all?

The problem is the pathfinding doesn't use virtual methods, unless Toady has changed it I remember looking into it with others a few versions ago and the results were that the only way to effect the pathfinding was to modify the units path itself. You are free to look into it of course, but I'm pretty sure the pathfinding engine doesn't use any virtual methods that you can hook into
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: jeancallisti on March 15, 2018, 12:19:09 pm
You are free to look into it of course, but I'm pretty sure the pathfinding engine doesn't use any virtual methods that you can hook into
OK so that settled it, no worries. We'll have to stick to our hacky method that overwrites unit.path.dest.
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: PatrikLundell on March 15, 2018, 01:32:09 pm
You are free to look into it of course, but I'm pretty sure the pathfinding engine doesn't use any virtual methods that you can hook into
OK so that settled it, no worries. We'll have to stick to our hacky method that overwrites unit.path.dest.
I'm not sure what that would achieve, assuming you're looking to improve performance, not change the path as such. Having DF first calculate the path, then calculate a path using an alternative method and then replace the original path with the hacked one is bound to be costlier. In order to replace the pathing you'd at least have to hack the DF code to produce a short fake path that your alternative can pick up, but if you've managed to do that you can just as well call your replacement code from that stub to produce a real path. Obviously, in order to do this you'd have to locate the relevant code, figure out what the parameters are (including variations), and find out what the results are (quite possibly an updated path in the unit plus some kind of return value to indicate success/failure (with possible indications of the kind of failure)).

If you somehow were able to determine when DF was going to perform a path calculation, replacing the destination in between it being set and the path calculated would allow you to ensure the native calculation produces a very short (and cheap) path, of course.

And now something completely different: How do you find out if a unit is a spy? I've tried to compare the visible name string with the normal one, without getting a single mismatch, so that's probably not it. It seems the gobbos have sent multiple spies to note cage trap locations along multiple entrance paths, and ripping up the traps not triggered during the last siege and placing new ones there did not seem to help for the current one, although the revealed path is slightly different.
I haven't decided what to do with the spies, but having 50% of the visitors being monks and peddlers is FAR to high a proportion for my liking (yes, I know that can be handled by not having dedicated temples, which I'm going to do in the next fortress, but not the current one).
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: lethosor on March 15, 2018, 01:46:29 pm
You are free to look into it of course, but I'm pretty sure the pathfinding engine doesn't use any virtual methods that you can hook into
OK so that settled it, no worries. We'll have to stick to our hacky method that overwrites unit.path.dest.
I'm not sure what that would achieve, assuming you're looking to improve performance, not change the path as such. Having DF first calculate the path, then calculate a path using an alternative method and then replace the original path with the hacked one is bound to be costlier. In order to replace the pathing you'd at least have to hack the DF code to produce a short fake path that your alternative can pick up, but if you've managed to do that you can just as well call your replacement code from that stub to produce a real path.
This is exactly what I meant by having DF call a custom pathfinding function (it's what I said requires C++).

Quote
Obviously, in order to do this you'd have to locate the relevant code, figure out what the parameters are (including variations), and find out what the results are (quite possibly an updated path in the unit plus some kind of return value to indicate success/failure (with possible indications of the kind of failure)).
If you're just writing something that computes unit.path.dest, you probably don't need any of that.

So if we assume that the pathfinding function is virtual and if we assume that I want to run my own code instead, written in C++ as a DFHack plugin, then what's the underlying code base? Like, would it be possible (without it being too clumsy or hard to maintain) to use stuff like C++11 and std::async ? (Don't worry about sync'ing the threads, leave that to me). Is 'std' available at all?
It is not virtual. There might be some virtual methods that happen to get called during pathfinding, but I doubt it, so don't count on it. You'd have to go back to the 1990s for the STL not to be available. As for DFHack's purposes, we support GCC 4.8 (and newer) and MSVC 2015 (exactly), so any C++11 stuff should be available. C++14 support is dicey, and C++17 is probably not something you can rely on.
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: jeancallisti on March 15, 2018, 02:03:53 pm
Quote
C++ 11

Perfect perfect perfect. Thanks.

I'm not replying to the pathfinder bit, as it's being discussed in another thread.
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: Express on March 17, 2018, 07:33:56 pm
When I used digtype on gold nuggets in the latest alpha build my game crashed. Its happened twice so I've stopped using it. Anything I can do to help with this report?

edit: ah I saw the github site where bugs are reported. still new to all this!
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: fricy on March 18, 2018, 04:09:13 am
When I used digtype on gold nuggets in the latest alpha build my game crashed. Its happened twice so I've stopped using it. Anything I can do to help with this report?
I couldn't reproduce this. I designated a native gold vein for digging, gave the command and the dwarves started digging for me. How fast came the crash for you? Immediately, or a bit later?
For what it's worth I have to mention that I did use the 3dveins command right after embark on this map.
dfhack 44.07-a1, twbt, no raw changes.
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: Express on March 19, 2018, 05:16:04 pm
When I used digtype on gold nuggets in the latest alpha build my game crashed. Its happened twice so I've stopped using it. Anything I can do to help with this report?
I couldn't reproduce this. I designated a native gold vein for digging, gave the command and the dwarves started digging for me. How fast came the crash for you? Immediately, or a bit later?
For what it's worth I have to mention that I did use the 3dveins command right after embark on this map.
dfhack 44.07-a1, twbt, no raw changes.

I can replicate it all the time. I posted this bug on github along with my save, hopefully they find something there.
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: PatrikLundell on March 20, 2018, 04:16:00 am
Which DFHack function is responsible for producing a text saying "Units removed from active: X"? It's presumably enabled by the LNP DFHack setting "Performance Tweaks".
The reason for the question is that my fortress has a large number of questers stuck in limbo (i.e. "dead" and incoming) but with their gear showing up in the inventory screen. At least one of these units (the one I get when I follow the trail of the first inventory weapon) is in units.all but not units.active, so I'd like to check what that script/plugin does, to see if it might be responsible for the stock (and item) clutter.

Edit: Corrected the text printed.
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: Putnam on March 20, 2018, 04:52:02 am
fix/dead-units
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: PatrikLundell on March 20, 2018, 05:29:08 am
Thanks Putnam!

The script looks a bit problematic to me at a first look. It looks a the "dead" flag, which seems to really be misnamed, as incoming invaders (and probably others) have this flag set before they enter the map, so that flag seems to be more of an "inactive" flag than a "not living any more" flag.
If I remember correctly, there's a "killed" flag, but I don't know if it's connected to only a subset of death causes.

Note that the above is preliminary guesswork, not any results and definitely not based on any testing, yet.

Edit: The first unit the script wanted to remove that wasn't "killed" was an incoming bugbat that couldn't enter because there was already a bugbat in the way. After a number of days the bugbat swarm shifted within the confined area they spawned in so the one the script wanted to remove could enter, and the script no longer wants to remove it (unsurprisingly).

Edit2: I've tried to reverse the incorrect removals of the script by locating all "dead" but not "killed" units that were in the "bad" vector but not the "active" one and move them. This resulted in a number of dead units appearing on the surface: a couple of giant fire-flies, a pile of wagon wood and dead yaks (I know I've had a bugged caravan earlier), and a ton of critters appearing in the cavern entrances, with lots of units still to enter. The dead unit list filled up with a fair number of units (but smaller than the total number killed), and the bogus equipment in my stocks disappeared. Interestingly, no sapient units appeared (4 yaks from the bugged caravan did). The dead unit list was easily cleared by running fix/dead-units again (with the script modified to only remove "killed" units, not ones merely "dead").
There's still more testing needed, as I'd need to see the script trying to remove a "civilized" unit to determine whether it ought to or not. Also, I haven't investigated where all the questers stuck in limbo went, i.e. if the units actually disappeared or if they are still there, just not with their equipment showing.

Edit 3: A lot of the units that were removed prematurely won't enter the map because there are now obstructions there (walls I've built to secure 2 caverns, a cavern tree). If the units' pos is hacked to a free spot corpses of the old ones spawn there (I guess the units spawn and then die of old age immediately) at a fairly slow pace. When reaching the end of the list some of the units are actually alive, and new ones won't enter at that spot until the one already there moves (I had that happen naturally with an FB earlier today, where it was announced but did not appear until a fair while later when a cave blob moved out of the spot).

Edit 4: Yes, the script definitely causes trouble with inbound legal units. I've just had an announcement of 82 quester units in one fat dump, and when I run the script after about half of them had entered the map it seems to want to remove the other half.

Edit 5: And at least one of them is one who's been in limbo for entering my fortress 11 years ago, while another one is fresher. Anyway, it seems moving units back from "bad" to "active" can get them back into play.
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: FantasticDorf on March 21, 2018, 01:06:50 pm
Grown wood was recently discovered to be sorted as a exclusively non-plant/animal object when sorted by stockpiles, as well as its further products (cages, goods, logs, armor, training weapons) when produced by elves with the occasional bug where the objects are mis-represented, would it be at all possible to identify the boolean as mentioned by Toady and apply the value and description onto objects at will? I may just be behind in my knowledge of the GM-editor's new and/or forgetting its current functions though since i haven't used df-hack since 43.05

I would think it opens possibilities somewhere for people who want to pursue using these objects.
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: PatrikLundell on March 21, 2018, 02:15:25 pm
Grown wood was recently discovered to be sorted as a exclusively non-plant/animal object when sorted by stockpiles, as well as its further products (cages, goods, logs, armor, training weapons) when produced by elves with the occasional bug where the objects are mis-represented, would it be at all possible to identify the boolean as mentioned by Toady and apply the value and description onto objects at will? I may just be behind in my knowledge of the GM-editor's new and/or forgetting its current functions though since i haven't used df-hack since 43.05

I would think it opens possibilities somewhere for people who want to pursue using these objects.
item_flags2.grown?
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: AVE on March 27, 2018, 07:39:36 am
Can artifact-quality level items be generated with dfhack (looks like create-item can support only masterwork quality level)? If not, is it due to the need to write artifact item into the history of the world?
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: PatrikLundell on March 27, 2018, 09:45:14 am
Can artifact-quality level items be generated with dfhack (looks like create-item can support only masterwork quality level)? If not, is it due to the need to write artifact item into the history of the world?
Without knowing what the script looks like, artifacts indeed require extra efforts, such as creating an artifact record for them and enter that into the artifact structure. You'd also need to set the artifact flag in the item, but that's trivial. I don't know if you also have to enter an entry about its creation in the history. Someone has made some kind of artifake mod, which you may want to look at (although that still doesn't guarantee what's done there is "complete").
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: AVE on March 27, 2018, 10:17:09 am
Artifake just sets item quality to 6, removes wear and wear-timer (both are set to 0) and in case of weapon ups his sharpness to 10000. It is nothing done there in order to properly insert artifact into the world, it is just crude advmode cheat from its looks.
Title: Re: DFHack 0.44.05-r2 | 0.44.07-alpha1 (dev)
Post by: Putnam on March 27, 2018, 02:35:33 pm
Code: (custom-artifact.lua) [Select]
-- Makes it so that the world will always have certain artifacts in certain sites when world loads.
--@ module = true
--Author Putnam

local usage = [===[

modtools/custom-artifact
=====================
This tool, when run, checks if the specific item has an artifact record somewhere in the world
and places the artifact at a valid site (which can be constrained by arguments) if it is not found.

Arguments::

    -itemType type
        the type of item that will have an artifact spawned
        examples:
            WEAPON:ITEM_WEAPON_PICK
            RING
     -itemMat mat
         the material of the newly generated item
         examples:
            INORGANIC:IRON
            CREATURE_MAT:DWARF:BRAIN
            PLANT_MAT:MUSHROOM_HELMET_PLUMP:DRINK
     -name name
        the item's name
        should be set, will just go with no name if not
     -amount num
         the minimum artifacts required
         will continue to create new artifacts until this amount is reached
         this argument is optional and will default to 1
     -ignoreExisting
         will create (num) artifacts named (name) regardless of existing artifacts of that type
         do not use in onload scripts, will overrun world with that artifact type given enough reloads
     -specificEntityType [ entity1 entity2 ... ]
        entity filter, will only spawn in these entity's sites
        examples:
            MOUNTAIN
            EVIL
            FOREST
            PLAINS
     -specificSiteType [ site1 site2 ... ]
        site filter, will only spawn in these site types
        examples:
            CAVE_DETAILED
            DARK_FORTRESS
            TREE_CITY
            CITY
     -help
         displays this message
]===]

local utils=require('utils')

validArgs = utils.invert({
    'itemType',
    'amount',
    'itemMat',
    'specificEntityType',
    'specificSiteType',
    'ignoreExisting',
    'name',
    'help'
})

function getItemType(item) --just kinda grabbed this from item-trigger, like the help dialogue above
    local itemType
    if item:getSubtype() ~= -1 and dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()) then
        itemType = df.item_type[item:getType()]..':'..dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()).id
    else
        itemType = df.item_type[item:getType()]
    end
    return itemType
end

function mysplit(inputstr, sep) --https://stackoverflow.com/questions/1426954/split-string-in-lua
    if sep == nil then
        sep = "%s"
    end
    local t={} ; i=1
    for str in string.gmatch(inputstr, "([^"..sep.."]+)") do
        t[i] = str
        i = i + 1
    end
    return t
end

local function findTranslation(str)
    for k,v in ipairs(df.global.world.raws.language.translations) do
        if v.name==str then return k,v end
    end
    return false
end

function createArtifact(itemType,itemSubtype,name,material,entityFilter,siteFilter)
    local newArtifact = df.artifact_record:new()
    newArtifact.id=df.global.artifact_next_id
    local rng=dfhack.random.new(os.time(),df.global.artifact_next_id)
    local eligibleSites={}
    for _,site in ipairs(df.global.world.world_data.sites) do
        if site.civ_id~=-1 then
            local thisSiteType=df.site_type[site.type]
            if thisSiteType and (not entityFilter or entityFilter[df.historical_entity.find(site.civ_id).entity_raw.code]) and (not siteFilter or siteFilter[thisSiteType]) then
                table.insert(eligibleSites,site.id)
            end
        end
    end
    local pickedSite=eligibleSites[rng:random(#eligibleSites)+1]
    newArtifact.anon_1=-1000000  --TODO: REPLACE REPLACE REPLACE REPLACE REPLACE ALL OF THESE ANON IS BAD
    newArtifact.anon_2=-1000000
    newArtifact.anon_3=-1000000
    newArtifact.anon_4=pickedSite
    newArtifact.anon_5=1
    newArtifact.anon_6=-1
    newArtifact.anon_7=-1
    newArtifact.anon_8=-1
    newArtifact.anon_12=pickedSite
    newArtifact.anon_13=1
    newArtifact.anon_14=-1
    newArtifact.anon_15=-1
    newArtifact.anon_16=-1
    newArtifact.anon_17=250
    newArtifact.anon_18=0
    newArtifact.anon_19=3
    if name then
        newArtifact.name.has_name=true
        newArtifact.name.first_name=name
    end
    local newUnit = df.unit:new() --temp boi
    newUnit.pos.x=df.global.world.units.active[0].pos.x
    newUnit.pos.y=df.global.world.units.active[0].pos.y
    newUnit.pos.z=df.global.world.units.active[0].pos.z
    local newItem = df.item.find(dfhack.items.createItem(itemType,itemSubtype,material.type,material.index,newUnit))
    newUnit:delete()
    newUnit=nil
    newItem.id=df.global.item_next_id
    newItem.pos.x=-30000
    newItem.pos.y=-30000
    newItem.pos.z=-30000
    local artifactRef=df.general_ref_is_artifactst:new()
    artifactRef.artifact_id=newArtifact.id
    newItem.general_refs:insert('#',artifactRef)
    newItem.flags.artifact=true
    newItem.flags.artifact_mood=true
    newItem.maker=-1
    newItem.masterpiece_event=-1
    newItem.quality=df.item_quality.Artifact
    newArtifact.item=newItem
    local newEvent=df.history_event_artifact_storedst:new()
    newEvent.artifact=newArtifact.id
    newEvent.unit=-1
    newEvent.histfig=-1
    newEvent.site=pickedSite
    df.global.world.history.events:insert('#',newEvent)
    df.global.world.artifacts.all:insert('#',newArtifact)
    df.world_site.find(pickedSite).artifacts:insert('#',newArtifact)
    df.global.artifact_next_id=df.global.artifact_next_id+1
end

if moduleMode then
    return
end

local args = utils.processArgs({...}, validArgs)

if args.help or not args.itemType or not args.itemMat then
    print(usage)
    return
end

local itemType,itemSubtype

local itemTypeSplit=mysplit(args.itemType,':')

local itemTypeStr,itemSubtypeStr=itemTypeSplit[1],itemTypeSplit[2]

itemType=df.item_type[itemTypeStr]

if not itemType then
    qerror('Could not find item type: '..args.itemType)   
end

if #itemTypeSplit>1 then
    local temp
    for _,itemdef in ipairs(df.global.world.raws.itemdefs.all) do
        if itemdef.id == itemSubtypeStr then
            itemSubtype=itemdef.subtype
            break
        end
    end
    if not itemSubtype then
        qerror('Could not find item type: '..args.itemType)
    end
end

args.amount=args.amount and tonumber(args.amount) or 1

local totalArtifactsOfItemType=0

if not args.ignoreExisting then
    for k,v in ipairs(df.global.world.artifacts.all) do
        if getItemType(v.item)==args.itemType then
            totalArtifactsOfItemType=totalArtifactsOfItemType+1
        end
    end
end

local itemMat=args.itemMat and dfhack.matinfo.find(args.itemMat) or false

if totalArtifactsOfItemType<args.amount then
    for i=totalArtifactsOfItemType,args.amount-1,1 do
        createArtifact(itemType,itemSubtype,args.name,itemMat,args.specificEntityType and utils.invert(args.specificEntityType),args.specificSiteType and utils.invert(args.specificSiteType))
    end
end

This could likely be rather easily modified so that it keeps the artifact within the current dwarf mode site.
Title: Re: DFHack 0.44.05-r2 | 0.44.07-beta1 (dev)
Post by: lethosor on March 29, 2018, 08:51:37 am
A couple people asked for support for Toady's fixed 0.44.07 Linux build, so here is a release for that:
https://github.com/DFHack/dfhack/releases/edit/0.44.07-beta1

(In hindsight, I should have known Toady was going to release 0.44.08 around then...)
Title: Re: DFHack 0.44.05-r2 | 0.44.07-beta1 (dev)
Post by: PatrikLundell on March 29, 2018, 09:08:17 am
It's unfortunate fix/dead-units wasn't fixed, as it currently causes harm.
Title: Re: DFHack 0.44.05-r2 | 0.44.07-beta1 (dev)
Post by: lethosor on March 29, 2018, 09:23:54 am
Sorry. I checked for pull requests but not issues, so I missed it.
Edit: merged the flags2.killed change, and confirmed that it no longer affects a test caravan in ways that it shouldn't.
Title: Re: DFHack 0.44.05-r2 | 0.44.07-beta1 (dev)
Post by: PatrikLundell on March 29, 2018, 10:55:56 am
Sorry. I checked for pull requests but not issues, so I missed it.
Edit: merged the flags2.killed change, and confirmed that it no longer affects a test caravan in ways that it shouldn't.
The reason I made an issue rather than a pull request was that I had made a few other changes I wanted comments on before creating a pull request...
I don't think a caravan is a good positive test subject, as there's a specific check for merchants that should exclude those from being culled when they shouldn't. Still, the flags2.killed flag is the important part.
Title: Re: DFHack 0.44.05-r2 | 0.44.08-alpha1 (dev)
Post by: lethosor on March 29, 2018, 01:12:54 pm
New release with 0.44.08 support and that fix: https://github.com/DFHack/dfhack/releases/tag/0.44.08-alpha1
Title: Re: DFHack 0.44.05-r2 | 0.44.08-alpha1 (dev)
Post by: PatrikLundell on March 29, 2018, 01:47:09 pm
That was very quick!
Title: Re: DFHack 0.44.05-r2 | 0.44.08-alpha1 (dev)
Post by: lethosor on March 29, 2018, 01:56:35 pm
Indeed. Ben's script to automatically find symbols finished about a minute before Toady's devlog post:
Spoiler (click to show/hide)
Title: Re: DFHack 0.44.05-r2 | 0.44.08-alpha1 (dev)
Post by: funkydwarf on March 31, 2018, 06:18:47 am
Shiny pants. The future to me is crazy fast df-hack beta releases and shiny pants. I have seen some shiny pants here and there for a while now , but now...

The future is finally here...its a new damn day :o

Is this the end of the symbol find grind so many brave and selfless people have had to do countless times for the community? Is Ben's script possible because of whatever symbol-finding-helper function Toady said he would put in sometime before the last update?
Title: Re: DFHack 0.44.05-r2 | 0.44.08-alpha1 (dev)
Post by: Rose on March 31, 2018, 06:30:24 am
It is because of that, yes.

All the global addresses are stored in the exe file, and can be found by a script. That does not, however, account for any changes to the structures themselves, which requires manual verification.
Title: Re: DFHack 0.44.05-r2 | 0.44.08-alpha1 (dev)
Post by: vvAve on March 31, 2018, 10:45:36 am
I drafted a woodcutter in a squad to equip leather armor, he won't cut trees afterwards. After killing target dorf gets stuck on a tile, I teleported him somewhere else, but he still won't move. Retire/unretire - weapons are not in the equipment list now.

How likely these problems are caused by alpha dfhack?
Title: Re: DFHack 0.44.05-r2 | 0.44.08-alpha1 (dev)
Post by: PatrikLundell on March 31, 2018, 11:09:37 am
I drafted woodcutter in squad to equip leather armor, he won't cut trees afterwards. After killing target dorf gets stuck on a tile, I teleported him somewhere else, but he still won't move. Retire/unretire - weapons are not in equipment list now.

How likely these problems are caused by alpha dfhack?
Not at all. It's caused by the known vanilla issue of civilian jobs with "uniform" tools (hunter/miner/wood cutter) having the civilian uniform conflicting with the military one. In practice, this means you cannot have these jobs active while wearing a military uniform, as part of the uniform is a military weapon (which may be of the same type, but still has to be a different object). Don't draft dorfs with these jobs or you're going to have "issues".
Title: Re: DFHack 0.44.05-r2 | 0.44.08-alpha1 (dev)
Post by: vvAve on March 31, 2018, 11:16:34 am
Understandable, but usual forbid/dump/cleanowned didn't help for some reason. Other bugs are new to me though.
Title: Re: DFHack 0.44.05-r2 | 0.44.08-alpha1 (dev)
Post by: Quietust on March 31, 2018, 12:44:00 pm
Understandable, but usual forbid/dump/cleanowned didn't help for some reason. Other bugs are new to me though.
Is there a reason why you expected forbid/dump/cleanowned to solve that problem?

For the record, this particular problem has been in the game for about 8 years now (originally reported (http://www.bay12games.com/dwarves/mantisbt/view.php?id=1451) in April 2010), so it's nothing new from our perspective.
Title: Re: DFHack 0.44.05-r2 | 0.44.08-alpha1 (dev)
Post by: vvAve on April 01, 2018, 09:48:54 am
it's nothing new from our perspective.
Other bugs are new to me though.
I specifically didn't equip axes, dwarf dropped axe, picked weapon and then never picked axe again.

I was just wondering if hack's bugfixing scripts could affect these things.
Title: Re: DFHack 0.44.05-r2 | 0.44.08-alpha1 (dev)
Post by: PatrikLundell on April 01, 2018, 10:08:10 am
it's nothing new from our perspective.
Other bugs are new to me though.
I specifically didn't equip axes, dwarf dropped axe, picked weapon and then never picked axe again.

I was just wondering if hack's bugfixing scripts could affect these things.
The woodcutter's axe is part of the WOODCUTTER uniform. This uniform is REPLACED by the MILITIA uniform (which may lack weapons defined, but that doesn't matter) when the woodcutter is drafted. Once you remove the bugger from the militia an axe for wood cutting purposes will be picked up (assuming one is available, if the one used previously is rendered unavailable by being part of the uniform for a currently unfilled militia slot). This is a vanilla DF issue.

Unless a dorf selects a "job" somewhere he won't move. A dorf assigned to an active squad with no training facilities ordered to kill a target won't have any jobs matching the military profile until getting hungry/thirsty/sleepy once the target has been killed.
Title: Re: DFHack 0.44.05-r2 | 0.44.09-alpha1 (dev)
Post by: lethosor on April 02, 2018, 12:44:13 am
For 0.44.09: https://github.com/DFHack/dfhack/releases/tag/0.44.09-alpha1

Turns out I made mistakes running some manual checks against 0.44.08, so the release for 0.44.08 should have been more stable than I made it sound. By extension, this one shouldn't be too bad either, so it still supports 0.44.08 and 0.44.07, although I don't recommend using those much.
Title: Re: DFHack 0.44.05-r2 | 0.44.09-alpha1 (dev)
Post by: uioped1 on April 04, 2018, 12:25:33 am
I am attempting to make an adventurer a full citizen of a fort after retire and reclaim.
It looks like I am able to do that using the script gui/gm-editor
I found that the necessary step is to add a reference to the former adventurere's historical figure id in histfig_ids on the historical_entity for the local group.
That seems to work, however I am concerned about later crashes, as I cannot figure out how to add a reference to the historical figure object in the hist_figures array.  Will it be a problem to skip that step?

Secondly, it seems like the nemesis ids may be related, but I can't figure out what a nemesis is.

Any other things I should look out for?

Thanks for your help.
Title: Re: DFHack 0.44.05-r2 | 0.44.09-alpha1 (dev)
Post by: Rumrusher on April 04, 2018, 07:34:18 am
I am attempting to make an adventurer a full citizen of a fort after retire and reclaim.
It looks like I am able to do that using the script gui/gm-editor
I found that the necessary step is to add a reference to the former adventurere's historical figure id in histfig_ids on the historical_entity for the local group.
That seems to work, however I am concerned about later crashes, as I cannot figure out how to add a reference to the historical figure object in the hist_figures array.  Will it be a problem to skip that step?

Secondly, it seems like the nemesis ids may be related, but I can't figure out what a nemesis is.

Any other things I should look out for?

Thanks for your help.
you should be able to cross reference an Adventurer who starts from the fort for the adventurer's who don't but really it just aligning the Citizen's id (the unit's Civ, Population, and probably group ids to match with the starting citizen's ids everything else seems to be not really needed) with the rest of the fort once your in Fort mode.
I do remember someone making a script that converts units to your Fort might be Called Makeown.
Title: Re: DFHack 0.44.05-r2 | 0.44.09-alpha1 (dev)
Post by: uioped1 on April 04, 2018, 11:38:02 pm
you should be able to cross reference an Adventurer who starts from the fort for the adventurer's who don't but really it just aligning the Citizen's id (the unit's Civ, Population, and probably group ids to match with the starting citizen's ids everything else seems to be not really needed) with the rest of the fort once your in Fort mode.
I do remember someone making a script that converts units to your Fort might be Called Makeown.

Thanks.  Googling found the makeown command in the tweak plugin, but that is not sufficient to make my adventurer accept labor assignments.  (it sets the civ and some flags on the unit - resident, etc) I suspect something has changed in the game that renders that command irrelevant.   Based on a hint in the forums I found what I posted previously, which does work, however I'm not sure if I'm just missing something that is not completely working.  If anyone can tell me whether it's possible to change an existing reference using gui/gm-editor, that would be helpful.

edit: I just had an epiphany what a nemesis is: it is the corresponding unit id for the historical figure... not sure why anything worked without it, but hey.
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on April 05, 2018, 12:09:36 am
New release! https://github.com/DFHack/dfhack/releases/tag/0.44.09-r1
Also, we're experimenting with a new OS X compiler (built today!), thanks to BenLubar, so let us know if that works. It works on my system, at least.
Title: Re: DFHack 0.44.09-r1
Post by: Droggarth on April 05, 2018, 04:48:01 pm
Woah. I just got back into DF and already a few new updates to the game! Heh, at least I don't have to wait for dfhack to update. Need to gen a new adv world anyways for modding reasons and for my adventurer's personality change while also hoping to get a better spot for a draenei town to spawn.

Anyhow, is there a way to change one's own named item's/artifact's civ language the name is written in?
Heh, nevermind. Went to my new artifact two-handed broadsword's main menu and typed in names in the console. Now I gotta just hit random name generator until I get draenei language on my sword. Should've noticed that randomize the first time I named it which makes it the second time I forgot I can change the civ language that way, heh.
Title: Re: DFHack 0.44.09-r1
Post by: Cocoprimate on April 06, 2018, 07:45:32 pm
Please help!

I spawned a couple dragons via dfhack to breed them, using the following command:

modtools/create-unit -race DRAGON -caste MALE -civId //-1

I successfully captured and trained them, and put them in an animal zone so they can lay their eggs. The thing is, as soon as my dwarves start leading them to their assigned zone, monster hunting visitors chase them and try to attack the tamed dragon. This results in my fortress burning down and my dwarves attacking the visitors. Also, the dragons seem to be hostile to my military dwarves, but only the military. If I let it go on, I think this might cause a loyalty cascade between my dwarves.

To fix this, I edited their raws and removed the MEGABEAST flag and it worked.

But what happens now is that when I set them in their animal zones adjacent to each other so that they can breed, they attack each other instantly so I can't breed them. What did I do wrong? Is there anything I can do to make it work? Please keep in mind I'm mostly illiterate when it comes to dfhack. I lifted the spawn command from somewhere and I have no clue if I'm doing it correctly.
Title: Re: DFHack 0.44.09-r1
Post by: Rumrusher on April 07, 2018, 06:06:44 am
the fact they attack the military is a Vanilla hardcoded issue and not a DFhack related bit.
probably tied to the Passiveness they had in the previous versions being patched for adventurers but ended up making them hostile if anyone enlisted... due to the adventurer is part of a military group from the start.
I seen this happen when I modded the game to give me All general Poison classed creatures and the end result made it so Night trolls only attack if someone arms themselves.
now on the Dragon problem I have no clue, outside of Dfhack the dragon to plop out eggs(using an empregnate script) then editing the eggs with Gm-editor to be fertile and pray the mother doesn't try to eat her kids in the process.
if your already modding the dragons then probably scan through their raws to see if any token is causing them to attack, or if Breathing fire is a Greeting.

you probably should have set the Civid to the fort to skip the step and headache of training them as that might be the fault.
Title: Re: DFHack 0.44.09-r1
Post by: FantasticDorf on April 07, 2018, 08:53:45 am
Well its more or less a requirement to enable non-brawling behaviour in having your weapon out typically, so im not terribly suprised. There's probably very little that can be done to correct this even with mass applied scripts to set them to lethal though.

Night trolls are intelligent enough to make a assessment of a armed theat, regular cavern trolls still have the basic intelligence to do the same and will proceed to topple your workshops mostly being ignored until you send in dwarves to dispatch it, and while i occasionally see most creatures be more hostile when dwarves bumble too close, they don't exactly charge at them but rather the dwarves need to get in the way of them somehow. Known bug. #0010031 (http://www.bay12games.com/dwarves/mantisbt/view.php?id=10031)
Title: Re: DFHack 0.44.09-r1
Post by: Cocoprimate on April 07, 2018, 11:19:19 am
Quote
seen this happen when I modded the game to give me All general Poison classed creatures and the end result made it so Night trolls only attack if someone arms themselves.
now on the Dragon problem I have no clue, outside of Dfhack the dragon to plop out eggs(using an empregnate script) then editing the eggs with Gm-editor to be fertile and pray the mother doesn't try to eat her kids in the process.
if your already modding the dragons then probably scan through their raws to see if any token is causing them to attack, or if Breathing fire is a Greeting.

you probably should have set the Civid to the fort to skip the step and headache of training them as that might be the fault.

I've gone through the raws but I don't think there's anything there to affect them like this (which token would cause this?). I just added the child tag and changed the egg size. How do I set the civid to the fort?
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on April 07, 2018, 01:44:54 pm
There's a -setUnitToFort argument you can pass, which is equivalent to using the -groupId and -civId arguments: http://dfhack.readthedocs.io/en/stable/docs/_auto/modtools.html#modtools-create-unit
Title: Re: DFHack 0.44.09-r1
Post by: Cocoprimate on April 07, 2018, 05:31:48 pm
It still doesn't work. It appears some animals spawned via this way are always hostile towards members of their own species, but others don't. I tried spawning pairs of different creatures: dragons, lions, dogs, cats, elephants and cows.

Dragons, lions and dogs attacked each other mercilessly as soon as they spawned. Elephants, cows and cats didn't attack each other, though it seemed one of the two always became "overcome with mortal terror" of their fellow creature.

I always used the following command: modtools/create-unit -race ELEPHANT (for example) -caste FEMALE -setUnitToFort

What could be causing this? Some carnivore thing?
Title: Re: DFHack 0.44.09-r1
Post by: Lenny Zicree on April 08, 2018, 12:17:50 pm
using
[DFHack]# tweak adamantine-cloth-wear
[DFHack]# tweak craft-age-wear

i just found that every last unworn bit of adamantine cloth and armor in my game has f* rotted down to "xXadamantine cloakxX" inside of 19.5 months.

i dont know what to do anymore. i'm getting that ptsd look you see on toilet cleaners working in stadiums i'm so disappointed.

does anyone have a script to remove wear from all items please?
Title: Re: DFHack 0.44.09-r1
Post by: Bumber on April 08, 2018, 01:52:14 pm
i just found that every last unworn bit of adamantine cloth and armor in my game has f* rotted down to "xXadamantine cloakxX" inside of 19.5 months.
Could be the new item damage mechanics. Armor takes damage in combat, and dwarves will swap them out for new ones.
Title: Re: DFHack 0.44.09-r1
Post by: Lenny Zicree on April 08, 2018, 02:32:12 pm
Could be the new item damage mechanics. Armor takes damage in combat, and dwarves will swap them out for new ones.

no combat. it was never worn, stored in a locked 3x3.
it rotted worse than the clothing it was intended to replace.
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on April 08, 2018, 02:43:23 pm
That sounds like more wear than expected, although I haven't used those tweaks. Did you enable them yourself or were they in the default config file? You included the DFHack prompt so I'm not sure.
I think wear is determined by one or two item counters, so you should be able to change it back with gui/gm-editor, lua, etc. without a full-fledged script.
Title: Re: DFHack 0.44.09-r1
Post by: Bumber on April 08, 2018, 03:08:32 pm
no combat. it was never worn, stored in a locked 3x3.
it rotted worse than the clothing it was intended to replace.
You didn't have refuse enabled on the stockpile, did you?
Title: Re: DFHack 0.44.09-r1
Post by: Bomepie on April 09, 2018, 08:07:43 pm
Any scripters out there have experience with using dfhack.items.remove(item), particularly on corpses?

I've put together a janky-ass script to crawl a stockpile and replace Sentient Corpses with Bone Blocks (for reasons) (https://imgur.com/mzJXgXO) and I was wondering if the deletion part of the code would cause any problems when used on a large scale. I'd hope the actual corpse objects aren't just piling up somewhere, waiting to cause crashes and FPS loss, but I don't really know for certain, and would love some reassurance from you veterans.
Title: Re: DFHack 0.44.09-r1
Post by: Putnam on April 09, 2018, 09:51:24 pm
If it's a dfhack function, it should do all the requisite cleanup. There may be problems if the item is in use, perhaps.
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on April 09, 2018, 10:13:08 pm
Taking a look at the implementation (https://github.com/DFHack/dfhack/blob/b6311ec6b8bcd4453948bbe416f5af0ee3fd302c/library/modules/Items.cpp#L973) should answer some of your questions. Specifically, it sets the garbage_collect flag to true unless the last argument is true, which will remove it safely and completely (after a small delay, usually). Before doing that, it calls detachItem() (https://github.com/DFHack/dfhack/blob/b6311ec6b8bcd4453948bbe416f5af0ee3fd302c/library/modules/Items.cpp#L718), which fails and returns false if there are certain general/specific refs, if specific screens are open in specific situations, and a few other things (anything with "return false" in that function), but if detachItem returns false, so will remove(), so it should be pretty easy to detect.
Title: Re: DFHack 0.44.09-r1
Post by: Bomepie on April 09, 2018, 10:36:26 pm
Neat, thanks for the reassurance. Not it's time for the smoke test, here's hoping the lack of buriable bodies doesn't cause weirdness with ghosts and such.
Title: Re: DFHack 0.44.05-r2 | 0.44.09-alpha1 (dev)
Post by: uioped1 on April 10, 2018, 03:06:01 pm
you should be able to cross reference an Adventurer who starts from the fort for the adventurer's who don't but really it just aligning the Citizen's id (the unit's Civ, Population, and probably group ids to match with the starting citizen's ids everything else seems to be not really needed) with the rest of the fort once your in Fort mode.
I do remember someone making a script that converts units to your Fort might be Called Makeown.

Thanks.  Googling found the makeown command in the tweak plugin, but that is not sufficient to make my adventurer accept labor assignments.  (it sets the civ and some flags on the unit - resident, etc) I suspect something has changed in the game that renders that command irrelevant.   Based on a hint in the forums I found what I posted previously, which does work, however I'm not sure if I'm just missing something that is not completely working.  If anyone can tell me whether it's possible to change an existing reference using gui/gm-editor, that would be helpful.

edit: I just had an epiphany what a nemesis is: it is the corresponding unit id for the historical figure... not sure why anything worked without it, but hey.
A quick update on this, I've found that adding the references to the nemesis/hist fig entries is not necessary, since loading from a save synchronizes them.  Working on figuring out how to perform same from a script.  when I do I'll submit a pull request.  If anyone can point me to documentation of the data model exposed to scripts in dfhack, that would be _extremely_ helpful.
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on April 10, 2018, 03:32:13 pm
http://dfhack.readthedocs.io/en/stable/docs/Lua%20API.html might help. I'm not entirely sure what you're asking for, though, or what you've come up with already.
Title: Re: DFHack 0.44.09-r1
Post by: Ashtaroth on April 11, 2018, 03:36:13 pm
Possibly a daft question, so I apologise in advance;

I'm trying to use Misery to balance out happiness a little bit, but it just causes endless job cancellation spam and makes the fortress grind to a halt; there are other negative emotions besides "miserable" that don't cause job cancellations and should have the same effect on overall stress, so I want to change it. But since misery, as far as I can see, is a .dll, not a script, I don't have the slightest clue how to go about changing it? What would be the easiest way of doing that?
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on April 11, 2018, 06:31:53 pm
It's compiled from https://github.com/DFHack/dfhack/blob/master/plugins/misery.cpp, so you'll have to change it and recompile it to have changes take effect.
If you're interested in compiling DFHack, see https://dfhack.readthedocs.io/en/latest/docs/Compile.html. Otherwise, you can submit an issue and someone might get to it eventually. (I'm mostly responsible for making it use miserable thoughts, since I rewrote it some time after it broke around 0.40, but I'm also fairly busy with other things at the moment.)
Title: Re: DFHack 0.44.09-r1
Post by: YetAnotherLurker on April 13, 2018, 03:58:56 pm
So, tweak cage-butcher apparently does not check anything about the occupants of a cage before setting the slaughter flag. Thus, anything that winds up in a cage can be butchered, including sapient citizens.



I also tried flagging assorted captured invaders for butchering, but didn't manage to get one dragged to the Butcher's Shop due to immediate recaging upon release.
Title: Re: DFHack 0.44.09-r1
Post by: thefriendlyhacker on April 14, 2018, 03:36:51 am
I am having a few problems with modtools/create-unit.  I am trying to use it in an old mod I am updating to the latest DF version, but I have reproduced the problems in a vanilla .05 save moved to both DF .07/DFHack .07-alpha1 and DF .09/DFhack .09-alpha1.   I could *not* reproduce some of them in a fresh embark on a fresh .09 install, but all I did there was create a 5 year pocket world and spawn dogs next to the starting wagon.  All of this is 64bit win 7, by the way.
Spoiler: details (click to show/hide)

I am also having an issue with item-trigger. 
Spoiler: details (click to show/hide)

While I am here, is there a way to change intelligent pets to normal citizens through dfhack, or change long-term residents to citizens so they can take labors?  I tried reaction-trigger and syndrome transformations but those turn the pet into some weird kind of long-term resident that I could assign scholarships/scribing/performing but not the military or labors (not even through dwarf therapist). I might be able to skirt around this using a couple of reaction-triggers, create-unit, an instakilling syndrome and corpseitem (because intelligent pets can do skill-less reactions only for some reason), but it would be nice to not use such a hacky and limited method, especially since it won't allow intelligent pets to keep their skills.
Title: Re: DFHack 0.44.09-r1
Post by: Boltgun on April 16, 2018, 03:32:37 am
I am having a few problems with modtools/create-unit.  I am trying to use it in an old mod I am updating to the latest DF version, but I have reproduced the problems in a vanilla .05 save moved to both DF .07/DFHack .07-alpha1 and DF .09/DFhack .09-alpha1.   I could *not* reproduce some of them in a fresh embark on a fresh .09 install, but all I did there was create a 5 year pocket world and spawn dogs next to the starting wagon.  All of this is 64bit win 7, by the way.
Spoiler: details (click to show/hide)

Thank you for the testing, this give me some new theories about what causes new units to be hostile for a few frames upon spawn. I believe that it was caused by DF's enemy cache but it seems that any units keep their wild behavior as a predator, prey or curious beast until DF goes and refresh their AI. Is there a "wild animal" cache somewhere?

I need to replace some hacks in create-unit. Meanwhile, if you open the script and remove the three anon_x lines at line 344, create-unit may work again but with strange effects.
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on April 16, 2018, 09:07:39 am
Numbering for units without a name given is broken.  Most of the time, the number that the creature displays is a very large, sometimes negative number. Further spawned units of that race increment the number as expected.  Occasionally, the number starts at 1 as expected. Given that one time I saw an opossum 5(the first of its kind spawned) immediately after I just spawned a coati 5 (the 5th of its kind), I would guess that the variable for unit numbering isn't being initialized and the code branch that deals with numbering/naming creatures who are the first of their kind isn't executing or is missing the code to assign it to 1. Either that or there is a bad pointer address/pointer math somewhere (don't know whether the code for it is in C or Lua).
What mode are you in (fortress, arena, adventure)? The initialization behavior varies between them. I thought I had fixed it in one, but it might have broken in another.

Quote
The -domesticate flag throws an error, and units with it but not -setUnitToFort are friendly, not fort pets (the latter may be intended behavior, I'm not sure).  Here is the stack trace: 
...FE temp\DFFE 14.04/hack/scripts/modtools/create-unit.lua:344: Cannot write field unit.T_enemy.anon_4: not found.
stack traceback:
   [C]: in metamethod '__newindex'
   ...FE temp\DFFE 14.04/hack/scripts/modtools/create-unit.lua:344: in global 'domesticate'
   ...FE temp\DFFE 14.04/hack/scripts/modtools/create-unit.lua:537: in local 'script_code'
   ...y\Desktop\games\DFFE temp\DFFE 14.04\hack\lua\dfhack.lua:562: in function 'dfhack.run_script_with_env'
   (...tail calls...)
To script authors: this is why you NEVER use "anon" variables. Submit a PR to give them names!
Boltgun: either they were given names or some other unnamed fields were given names. I'll try to investigate what the right names should be.
Edit: fixed: https://github.com/DFHack/scripts/commit/96b118b2e7fe8d91b59e0cc1c7951bf27a5e6698
Title: Re: DFHack 0.44.09-r1
Post by: thefriendlyhacker on April 16, 2018, 09:29:44 am
I am having a few problems with modtools/create-unit.  I am trying to use it in an old mod I am updating to the latest DF version, but I have reproduced the problems in a vanilla .05 save moved to both DF .07/DFHack .07-alpha1 and DF .09/DFhack .09-alpha1.   I could *not* reproduce some of them in a fresh embark on a fresh .09 install, but all I did there was create a 5 year pocket world and spawn dogs next to the starting wagon.  All of this is 64bit win 7, by the way.
Spoiler: details (click to show/hide)

Thank you for the testing, this give me some new theories about what causes new units to be hostile for a few frames upon spawn. I believe that it was caused by DF's enemy cache but it seems that any units keep their wild behavior as a predator, prey or curious beast until DF goes and refresh their AI. Is there a "wild animal" cache somewhere?

I need to replace some hacks in create-unit. Meanwhile, if you open the script and remove the three anon_x lines at line 344, create-unit may work again but with strange effects.


As a quick test, I removed those 3 lines and tried spawning a few units in my modded .09/.09-alpha1 game that would fight previously on spawn. The short of it is that while some things are still broken, unless weird problems crop up later then I have a workable command I can use now to spawn pets from a workshop (thanks!).
Spoiler: results of quick test (click to show/hide)
What mode are you in (fortress, arena, adventure)? The initialization behavior varies between them. I thought I had fixed it in one, but it might have broken in another.
All the create-unit stuff I have been doing is in fortress mode.
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on April 16, 2018, 11:42:29 am
Can you try replacing the 3 lines with the fixed ones I linked instead of deleting them? I doubt they have much to do with your issue, but I want to be safe.

"spawnunit CAT MALE" (which uses modtools/create-unit) produced a cat called "Cat 1" in fortress mode for me, and I'm using a tool that initializes all memory to 0xAA, so if the ID weren't initialized, it should have been a large negative number. Can you provide a specific command that produces a badly-numbered unit?
Title: Re: DFHack 0.44.09-r1
Post by: Boltgun on April 17, 2018, 03:29:10 am
To script authors: this is why you NEVER use "anon" variables. Submit a PR to give them names!
Boltgun: either they were given names or some other unnamed fields were given names. I'll try to investigate what the right names should be.
Edit: fixed: https://github.com/DFHack/scripts/commit/96b118b2e7fe8d91b59e0cc1c7951bf27a5e6698

For info, create-unit broke creatures with special loyalty such as underworld or residents and long trials and errors revealed that those three anons needed to be set. Perhaps we can drop the two unks if those creatures do not turn weird, if not... we found a clown AI flag.
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on April 17, 2018, 09:07:44 am
The point is that if you determine that something needs "anon" fields, you need to give them names. Even "unk" names, like two of them have now, are better than no names ("anon" names are automatically generated).
Title: Re: DFHack 0.44.09-r1
Post by: thefriendlyhacker on April 17, 2018, 11:35:56 am
Can you try replacing the 3 lines with the fixed ones I linked instead of deleting them? I doubt they have much to do with your issue, but I want to be safe.

"spawnunit CAT MALE" (which uses modtools/create-unit) produced a cat called "Cat 1" in fortress mode for me, and I'm using a tool that initializes all memory to 0xAA, so if the ID weren't initialized, it should have been a large negative number. Can you provide a specific command that produces a badly-numbered unit?
Ok, getting out the fresh vanilla 5 year pocket embark and testing this a bit (.09+dfhack .09, 64 bit win7).

For reference, what I get without deleting or replacing any code
Spoiler: control run (click to show/hide)
After typing die in dfhack console, I then replaced the old 3 lines in the script with the ones from your link and loaded up the same fresh embark.
Spoiler: results (click to show/hide)

EDIT: I wasn't getting units attacking each other either before or after except for the wild dog, so I am going to transfer that .05 fortress over and spawn some dogs in the packed training room. 

EDIT 2: Ok, getting coords with teleport and spawning dogs in the middle of a packed training room of a large fortress.  Still have new code.
Spoiler (click to show/hide)
Title: Re: DFHack 0.44.09-r1
Post by: Bumber on April 19, 2018, 11:00:01 am
What's the deal with all the "exterminate" command's pronouns? Options include "him", "her", and "it" / "that". The script will print a message if you choose wrongly.
Seems like unnecessary confusion for something that isn't at all relevant to the function. Why not just "exterminate target" or "exterminate selected"?
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on April 19, 2018, 11:06:16 am
Agreed. I'll add those and get rid of the message.
Title: Re: DFHack 0.44.09-r1
Post by: PatrikLundell on April 19, 2018, 11:35:55 am
What's the deal with all the "exterminate" command's pronouns? Options include "him", "her", and "it" / "that". The script will print a message if you choose wrongly.
Seems like unnecessary confusion for something that isn't at all relevant to the function. Why not just "exterminate target" or "exterminate selected"?
The only reason I can see for the rejection is if it's the wrong target (e.g. two units at the same tile). However, there's only a 50% chance of it catching an error at the cost of annoyance when you just want to get rid of a bugger without examine it's gender first.
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on April 19, 2018, 12:30:21 pm
It doesn't "catch" anything - it always kills the selected unit. It just points out that you got the gender wrong.
Title: Re: DFHack 0.44.09-r1
Post by: PatrikLundell on April 19, 2018, 03:15:13 pm
It doesn't "catch" anything - it always kills the selected unit. It just points out that you got the gender wrong.
Hm, I was fairly sure I've had to change the gender in the command and try again when it said it was wrong. Ah well.
Title: Re: DFHack 0.44.09-r1
Post by: Bumber on April 20, 2018, 06:08:10 am
Agreed. I'll add those and get rid of the message.
You included "this" as one of the alternatives to "this" in the description. :P

The in-game help also needs to be changed at line 121.
Title: Re: DFHack 0.44.09-r1
Post by: Roses on April 20, 2018, 10:54:30 am
Is there a built in method for detecting fired projectiles? Right now I check every tick to see if df.global.proj_next_id has changed. If it has I go through the df.global.world.proj_list until I find the projectile with the correct id and then go from there. Just wondering if this is the best way to do it. I thought about using the eventful onProjItemCheckMovement but I wasn't sure if that would be faster/slower or what.

Also, I've been looking at reports in order to add report triggering to an action-trigger script. This became needed because the Dodge action does not get registered as a proper unit.action but does generate a combat report, so it should be possible to trigger off of that (some other things that would be fun to trigger on are charges, wrestling moves, knock outs, etc...). The trouble is the combat reports don't seem to store any information besides the type, the message, and the location it was triggered at (and a couple other things), and what we really need is the unit ids. Now it is possible to get the unit ids from the message by checking the names, but this isn't a full proof method and it requires we hard code the report message for each report type. So I was wondering if anyone else has looked at getting unit ids from reports? I feel like it should be easy, but maybe that information never becomes available?

EDIT: I already know about the onReport eventful trigger, but that only gives me the report ID which only gives me the information mentioned above
Title: Re: DFHack 0.44.09-r1
Post by: Naia on April 22, 2018, 04:37:53 pm
Is it possible to add a hotkey for changevein, similar to the one that already exists for digv ?

I like the main parts of my fortress having same wall and floor colours, so I use the changevein feature quite often to get rid of ore/gems. And while it's working perfectly, it might be something I do 50 - 100 times.
So I'm just wondering if there is a possible way to avoid bringing up the dfhack window, type the command, then switch back to df.
Title: Re: DFHack 0.44.09-r1
Post by: Xyon on April 22, 2018, 06:08:15 pm
I'm trying to figure out, is there any way to create aquifers? I was trying to use tiletype but its not that intuitive to figure out.
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on April 22, 2018, 07:45:09 pm
Is it possible to add a hotkey for changevein, similar to the one that already exists for digv ?

I like the main parts of my fortress having same wall and floor colours, so I use the changevein feature quite often to get rid of ore/gems. And while it's working perfectly, it might be something I do 50 - 100 times.
So I'm just wondering if there is a possible way to avoid bringing up the dfhack window, type the command, then switch back to df.
Yes, use the keybinding command. That's how the one for digv is set up - take a look at dfhack.init.

I'm trying to figure out, is there any way to create aquifers? I was trying to use tiletype but its not that intuitive to figure out.
An adjusted version of the drain-aquifer script might work. Getting it to show up just where you want would be tricky. It looks like it uses the "water_table" tile flag, and I'm not sure if tiletypes can change that.
Title: Re: DFHack 0.44.09-r1
Post by: Naia on April 22, 2018, 09:02:34 pm
Is it possible to add a hotkey for changevein, similar to the one that already exists for digv ?

I like the main parts of my fortress having same wall and floor colours, so I use the changevein feature quite often to get rid of ore/gems. And while it's working perfectly, it might be something I do 50 - 100 times.
So I'm just wondering if there is a possible way to avoid bringing up the dfhack window, type the command, then switch back to df.

Yes, use the keybinding command. That's how the one for digv is set up - take a look at dfhack.init.



Tried adding this to dfhack.init.
Quote
##############################
# Generic dwarfmode bindings #
##############################

# show all current key bindings
keybinding add Ctrl-F1 hotkeys
keybinding add Alt-F1 hotkeys

# toggle the display of water level as 1-7 tiles
keybinding add Ctrl-W twaterlvl

# with cursor:

# designate the whole vein for digging
keybinding add Ctrl-V digv
keybinding add Ctrl-Shift-V "digv x"

# change vein to specified inorganic stonetype
keybinding add Ctrl-Z changevein SHALE

But getting this 
Quote

Syntax: changevein < inorganic material ID >

It's probably something really basic missing, so it not getting the SHALE part.
What am I doing wrong ?
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on April 22, 2018, 09:03:31 pm
You need quotes around it, because there's a space. See the "digv x" example.
Title: Re: DFHack 0.44.09-r1
Post by: Naia on April 22, 2018, 10:37:18 pm
Thank you very much. It's working fantastic !  :)
Title: Re: DFHack 0.44.09-r1
Post by: Abadrausar on April 25, 2018, 07:48:20 am
 :o Doing some testing over the strangemood pluging I have found that the potter and glazer skills had not been implemented in the code inside of the file https://github.com/DFHack/dfhack/blob/master/plugins/strangemood.cpp (https://github.com/DFHack/dfhack/blob/master/plugins/strangemood.cpp) (as seen in lines after the line 590), even if the very similar skills glassmaker and mason are implemented.

There are some obscure technical reasons that make imposible the implementation of the skills potter and glazer in the strangemood pluging?

Or maybe they have been simply forgotten?

In https://github.com/DFHack/df-structures/blob/master/df.skills.xml (https://github.com/DFHack/df-structures/blob/master/df.skills.xml) (after the line 1132) those two skills are defined as Pottery and Glazing instead of potter and glazer (so the naming convention followed by most others skills is not respected). Could this have some relation ...
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on April 25, 2018, 09:06:36 am
Neither of those skills are listed on http://dwarffortresswiki.org/index.php/DF2014:Strange_mood#Skills_and_workshops, so they probably can't be affected by moods. It definitely has nothing to do with the naming, although that should probably be fixed.
Title: Re: DFHack 0.44.09-r1
Post by: Abadrausar on April 25, 2018, 12:04:31 pm
The question is that glazing and pottery produce quality levels in the decoration and in the core quality clay items respectively.

So... even if really DF does never produce mooded ceramic artifacts, it is probably unintended or forgotten by Toady.

Maybe a helper plugin as strangemood should permit clay-ceramic moods if it is feasible.

Dwarves dreams of either mastering a skill or creating a great work of art, moreover as a race or civilization they belong to the sphere of earth & stone, in this sense few things are more dwarfy than clay ceramics, except maybe cheese...

The only other skill that generates quality levels and is not in the wiki list of the moodable skills is cooking, but as it produces quality stacks of perishable food, it is easier to justify its absence.

Who would want to eat an artifact food or wine bottle two hundred years old?  ;)



Title: Re: DFHack 0.44.09-r1
Post by: blackreaper666 on April 29, 2018, 03:46:24 am
I'm having some smaller questions about scripting.

1. Is there a way to get the year of embark? You can get the current year, but I didn't find a way to check how many years the fort already exist

2. How can I get the 'name' of a creature that doesn't have a normal name?

3. How can I get the name of my fort?

Thanks in advance! :D
Title: Re: DFHack 0.44.09-r1
Post by: PatrikLundell on April 29, 2018, 07:33:55 am
1. If nothing else, it should exist as a history event, probably linked to by the site.
2. If you mean the race of creatures you'd use the race element of the unit/hist fig to look the race up in df.global.world.raws.creatures.all. These entries have a name field with indices for singular, plural, and a third use (possessive?).
3. dfhack.TranslateName (df.global.world.world_data.current_site

Note that none of these have been checked, so they may be off a bit.
Title: Re: DFHack 0.44.09-r1
Post by: Atomic Chicken on April 29, 2018, 08:38:51 am
I'm having some smaller questions about scripting.

1. Is there a way to get the year of embark? You can get the current year, but I didn't find a way to check how many years the fort already exist

2. How can I get the 'name' of a creature that doesn't have a normal name?

3. How can I get the name of my fort?

Thanks in advance! :D

1) This would probably work for your purpose.
Code: [Select]
fortressAgeTicks = df.global.ui.fortress_age*10
fortressAgeDays = df.global.ui.fortress_age*10/1200
fortressAgeYears = df.global.ui.fortress_age*10/403200

2) Your question is a little unclear. I'm assuming that by 'creature name' you're referring to, for example, 'dwarf', as opposed to 'Urist Tunzedot'.
Code: [Select]
creatureName = df.creature_raw.find(unit.race).caste[unit.caste].caste_name[0]
3)
Code: [Select]
fortressName = dfhack.TranslateName(df.world_site.find(df.global.ui.site_id).name)
fortressNameInEnglish = dfhack.TranslateName(df.world_site.find(df.global.ui.site_id).name,true)
Title: Re: DFHack 0.44.09-r1
Post by: Kazimuth on April 30, 2018, 02:18:50 am
I'm working on a mod that spawns a bunch of creatures of a custom race using DFHack, and I was hoping I could keep the creatures from fighting each other, while allowing them to fight other units. Does anyone know if there's some way to do this, either via raw editing or dfhack scripting?

Edit: using [OPPOSED_TO_LIFE] + [NOT_LIVING] works, but it's not ideal, because I'd prefer my creatures be animals instead of undead. i could probably also make an entity for the creatures i'm making, but again, i'd prefer for them to behave like animals instead.

Edit 2: actually i was wrong, [OPPOSED_TO_LIFE] + [NOT_LIVING] doesn't actually work :/
Title: Re: DFHack 0.44.09-r1
Post by: Roses on April 30, 2018, 08:48:55 am
I'm working on a mod that spawns a bunch of creatures of a custom race using DFHack, and I was hoping I could keep the creatures from fighting each other, while allowing them to fight other units. Does anyone know if there's some way to do this, either via raw editing or dfhack scripting?

Edit: using [OPPOSED_TO_LIFE] + [NOT_LIVING] works, but it's not ideal, because I'd prefer my creatures be animals instead of undead. i could probably also make an entity for the creatures i'm making, but again, i'd prefer for them to behave like animals instead.

Edit 2: actually i was wrong, [OPPOSED_TO_LIFE] + [NOT_LIVING] doesn't actually work :/

Check out reading from Reply #995 or so, I seem to remember there being a discussion about this
Title: Re: DFHack 0.44.09-r1
Post by: Kazimuth on April 30, 2018, 01:19:13 pm
Ah, thanks! Guess I should lurk more.
Title: Re: DFHack 0.44.09-r1
Post by: ancistrus on May 01, 2018, 04:37:00 pm
Hi, can someone help me with tiletypes? I have successfully changed some tiles to undiscovered and to subterranean, but I cant seem to make a working aquifer.
I used "paint aquifer 1", then range 10:10:1, then enter. The soil shows as damp now. But when I dig into it, it doesnt produce any water.

Title: Re: DFHack 0.44.09-r1
Post by: lethosor on May 01, 2018, 08:39:26 pm
One thing that comes to mind is the "special" subcommand for things like that, but I'm not seeing anything particularly aquifer-related there. I would try using the "probe" command on a "working" aquifer tile, save its output, then use it on yours and try to address as many differences as you can (obviously coordinates won't match, but flags and other things probably should).
Title: Re: DFHack 0.44.09-r1
Post by: milo christiansen on May 02, 2018, 02:39:55 am
IIRC, aquifers need a bunch of stuff besides just tile types to work. There needs to be a water level set somewhere, and I think the map chunks may have a flag too.

Anyway, just setting the tiletype won't be enough.
Title: Re: DFHack 0.44.09-r1
Post by: Roses on May 02, 2018, 09:19:17 am
Hi, can someone help me with tiletypes? I have successfully changed some tiles to undiscovered and to subterranean, but I cant seem to make a working aquifer.
I used "paint aquifer 1", then range 10:10:1, then enter. The soil shows as damp now. But when I dig into it, it doesnt produce any water.

Have you tried looking at the drain-aquifer script and doing the steps in reverse?
Title: Re: DFHack 0.44.09-r1
Post by: Atomic Chicken on May 02, 2018, 12:28:30 pm
Hi, can someone help me with tiletypes? I have successfully changed some tiles to undiscovered and to subterranean, but I cant seem to make a working aquifer.
I used "paint aquifer 1", then range 10:10:1, then enter. The soil shows as damp now. But when I dig into it, it doesnt produce any water.

Code: [Select]
if df.global.cursor.x < 0 then qerror('The cursor must first be placed on the screen!') end
local blockFlags = dfhack.maps.getTileBlock(pos2xyz(df.global.cursor)).flags
blockFlags.update_liquid = true
blockFlags.update_liquid_twice = true
blockFlags.update_temperature = true
blockFlags.designated = true
blockFlags.has_aquifer = true
blockFlags.check_aquifer = true

Save as a .lua file in hack\scripts.
Use by pointing the cursor at the tile you converted into an aquifer and entering the script's name into the console.
Title: Re: DFHack 0.44.09-r1
Post by: ancistrus on May 02, 2018, 12:46:46 pm
Thanks Chicken, it worked.
Title: Re: DFHack 0.44.09-r1
Post by: thefriendlyhacker on May 03, 2018, 03:29:34 am
I have a couple of scripting questions:

1. Does anyone know how to fix/work around the "intelligent pets can't take jobs" thing.  I tried a syndrome transforming them into something that isn't a pet, but then they get treated as some sort of weird visitor (no labors, can't join military, can be assigned to tavern/library, occupy long term resident bedrooms), and I couldn't find any flags or such in gm-editor that could be changed to make the game think they are just normal citizens.  Any ideas?

2. Do fort aligned units (including mercs and pets) *always* have the same civid as each other i.e. can I write a script assuming that something has the appropriate civid if and only if they are a friendly fort unit (excluding special cases like syndromes giving opposed_to_life, which I think I know how to exclude)?
Title: Re: DFHack 0.44.09-r1
Post by: Putnam on May 03, 2018, 03:43:51 am
for 2 you just want to use dfhack.units.isCitizen(unit), which checks if the unit's group_id is the fort's group_id and checks a whole lot of flags as well. (https://github.com/DFHack/dfhack/blob/48a61420b779607e2a46e084675516c769c46d7f/library/modules/Units.cpp#L437)
Title: Re: DFHack 0.44.09-r1
Post by: PatrikLundell on May 03, 2018, 03:45:52 am
1. Dwarf Therapist... As far as I understand there is nothing blocking a script from assigning jobs, only the vanilla DF UI. The developers of Dwarf Manipulator didn't want to support Gremlins (the only vanilla case of this issue) when asked, but I don't think it was on technical grounds. It doesn't matter to me though, as I use DT anyway...

2. Dwarven merchants, diplomats, and own civ visitors definitely have the same civ id. However, there are visitor and resident flags, and I think there are merchant and diplomat ones as well. Those flags can help you weed out the ones that shouldn't be included. Once members of the fortress animals and naturalized citizens should all have your civ id, though, so that should be a mandatory but not sufficient criterion. I'm not sure if residents have taken on your civ id, but think they have (but you should definitely check yourself).

And Putnam provided a much better alternative for 2 while I wrote this...
Title: Re: DFHack 0.44.09-r1
Post by: Meph on May 03, 2018, 09:34:13 am
hey, I tried running a custom plugin, but apparently I have the wrong dfhack version.

Warning: Plugin twbt compiled for DFHack 0.44.09-r1-2-g0ea35a6e, running DFHack 0.44.09-r1-0-gb6311ec6

Where can I find this elusive r1-2-g0ea35a6e version? I tried downloading the newest version from github, but it's still r1-0.
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on May 03, 2018, 09:40:52 am
Short version: the plugin was built against a dev build of DFHack (not a release). It's probably fine. Your options: ignore the warning, complain to Mifki, rebuild TWBT, and/or rebuild DFHack.

"0.44.09-r1-2-g0ea35a6e" means "2 commits after 0.44.09-r1", where "0ea35a6e" is (part of) the commit hash - see https://github.com/dfhack/dfhack/commits/develop. And it's just a warning - your plugin works fine. The way to get rid of the warning is to get a version of the plugin built against the right DFHack commit, which probably doesn't exist, but it doesn't particularly matter in this case. The warning is there to provide a diagnostic in case there is a compatibility issue between a DFHack release and later commits, but that doesn't happen very often.

In theory, you could also build DFHack commit 0ea35a6e yourself, but that's probably more effort than rebuilding TWBT.

For reference, the error you'd see if the plugin was built for the wrong version entirely is:
Code: [Select]
Plugin twbt was not built for this version of DFHack.
Plugin: (something), DFHack: 0.44.09-r1
Title: Re: DFHack 0.44.09-r1
Post by: Meph on May 03, 2018, 09:50:22 am
Curiously enough it wasn't Mifki, but Japa. He tried to get a new feature implemented, and apparently it works on his end. When I tried to test it, I just get crashes to desktop at embark. I thought it would be the difference in the dfhack builds that causes this.

But thank you for the detailed explanation. :)
Title: Re: DFHack 0.44.09-r1
Post by: thefriendlyhacker on May 03, 2018, 11:25:26 am
1. Dwarf Therapist...
I tried dwarf therapist... 

Spoiler: there were problems (click to show/hide)

So no, at this moment Dwarf Therapist is not a solution sadly. Labor scripts are an option, but they aren't ideal
for 2 you just want to use dfhack.units.isCitizen(unit), which checks if the unit's group_id is the fort's group_id and checks a whole lot of flags as well. (https://github.com/DFHack/dfhack/blob/48a61420b779607e2a46e084675516c769c46d7f/library/modules/Units.cpp#L437)
Ooh, that looks useful.  It doesn't return true for mercenaries though, which is a little bit of a problem.  However, everything there I can port over to lua and modify, so if I can adjust that to handle mercs and such then I am fine. I did some poking around and found that AFAICT long term residents never have those flags, but also are never listed as members under the player's group_id in any of their historical figure entity links, and they may or may not be linked to the player's group_id entity at all*.  The common link between all of the fort owned units appears to be the appropriate civ_id plus none of those flags.  Also, switching the civ_id and visitor flag on visitors or switching the civ_id on wandering wildlife lists them as civ members/tame pets (but with the interface behaving as if they are long term residents), so I guess that no flags + civ_id is the thing I am looking for.

Hmm, if the internal game code also uses histfig entity links to determine citizenship, then that is probably the key to fixing the ex-pet problem.  I might do some poking around in create-unit and ctrl-c ctrl-v some code learn the ways of dwarf fortress histfig creation.

Anyway, thanks for the code.

*as an aside, how do you get the full list of what is in df.histfig_entity_link_type?  I can pull out numbers for specific types like MERCENARY and MEMBER, but I can't figure out how to iterate through and see all the types and their corresponding IDs or otherwise figure out what other IDs are.  Maybe I suck at searching, but I also can't find where this stuff is defined in the git repo.  I don't need to know it (I think), but it would be nice to know for future reference.
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on May 03, 2018, 11:31:41 am
*as an aside, how do you get the full list of what is in df.histfig_entity_link_type?  I can pull out numbers for specific types like MERCENARY and MEMBER, but I can't figure out how to iterate through and see all the types and their corresponding IDs or otherwise figure out what other IDs are.  Maybe I suck at searching, but I also can't find where this stuff is defined in the git repo.  I don't need to know it (I think), but it would be nice to know for future reference.
Use ipairs(), not pairs(). In the Lua interpreter, "@" is shorthand for printall_ipairs() (which is like printall() but uses ipairs()):
Code: [Select]
@df.histfig_entity_link_type
There are other prefix characters you can use that are listed in the banner when you enter the Lua interpreter for the first time.

What stuff are you looking for in the git repo?

Edit: assuming you were looking for those names, they're defined in https://github.com/dfhack/df-structures, not the main DFHack repo.
Title: Re: DFHack 0.44.09-r1
Post by: PatrikLundell on May 03, 2018, 12:31:31 pm
@thefriendlyhacker: Gremlins cannot be given jobs until they petition to become citizens (they skip the initial petition, them being caged and trained presumably takes care of that automatically). Comparing a gremlin to a citizen shows that the citizen has a population id, while the gremlin does not (the gremlin hasn't yet become a citizen). However, hacking that wasn't sufficient for DT to allow it to be given jobs, so there's presumably something else missing.
My fortress is currently stalled due to a crash bug fixed in the next release, but a gremlin citizen petition shouldn't be very far off. I suspect that might be too long to wait, though.
Title: Re: DFHack 0.44.09-r1
Post by: PatrikLundell on May 04, 2018, 05:51:59 am
I'm trying to find a way to determine the formula for temperature DF uses. In order to do so I'd like to teleport an adventurer from world tile to world tile. At each world tile I'd like to zoom in measure the temperature(s), zoom out, reset the time (so all measurements are performed at the same time). Once all tiles have been scanned, I'd then like to redo the process after advancing the time one day, and repeat this for a year to get a series of data that might be used to deduce a formula.
  I think I've got a handle on the temperature measurement, and think I know where time is located. I also think I can handle zooming in/out by feeding the appropriate keys to DF. The part I don't know anything about is how to teleport the adventurer from world tile to world tile (walking might work as a work around, provided rivers can be crossed when zoomed out [I know very little about adventure mode]). In case it wasn't obvious, I'd like to make a script that does the job, not do it manually...

It can be noted that I'm making the assumption DF generates temperature of in game tiles the same way for both adventure mode and fortress mode, as it's the latter I'm actually interested in. Furthermore, I make the assumption water freezes when the temperature is 0 degrees Celsius and thaws at a temperature above that [as freezing/thawing is what I'm really after in the end], so if it's know to behave differently, I'd like to know.
Title: Re: DFHack 0.44.09-r1
Post by: Bumber on May 04, 2018, 07:01:19 am
Furthermore, I make the assumption water freezes when the temperature is 0 degrees Celsius and thaws at a temperature above that [as freezing/thawing is what I'm really after in the end], so if it's know to behave differently, I'd like to know.
I'm pretty sure it thaws at 0 °C and freezes when it drops just below that. In other words, nether cap won't freeze water.

As for teleporting an adventurer around, that sounds like something mapping utilities like Isoworld might do.
Title: Re: DFHack 0.44.09-r1
Post by: PatrikLundell on May 04, 2018, 08:54:07 am
Furthermore, I make the assumption water freezes when the temperature is 0 degrees Celsius and thaws at a temperature above that [as freezing/thawing is what I'm really after in the end], so if it's know to behave differently, I'd like to know.
I'm pretty sure it thaws at 0 °C and freezes when it drops just below that. In other words, nether cap won't freeze water.

As for teleporting an adventurer around, that sounds like something mapping utilities like Isoworld might do.
Thanks for the freezing info. That's useful to know.

You don't need to teleport an adventurer around for Isoworld, as far as I can determine (I'm not familiar with it, so I've just taken a quick look), but it looks like it uses DF exported maps for starters, and except for site maps, those maps only go down to the mid tile level, not the in-game one, and for that level you can just use pre embark manipulation to shift focus.
Title: Re: DFHack 0.44.09-r1
Post by: lethosor on May 07, 2018, 08:48:12 am
A bit of a late announcement, but there's an alpha up for 0.44.10:
https://github.com/DFHack/dfhack/releases/tag/0.44.10-alpha1
Title: Re: DFHack 0.44.09-r1
Post by: Vitellus on May 07, 2018, 10:50:17 am
Thanks!

Keep up the good work, the entire community is grateful!
Title: Re: DFHack 0.44.09-r1 | 0.44.10-alpha1 (dev)
Post by: Pancakes on May 07, 2018, 08:40:18 pm
Very much appreciated, thanks!
Title: Re: DFHack 0.44.09-r1 | 0.44.10-alpha1 (dev)
Post by: JezaGaia on May 10, 2018, 07:42:19 am
I've looked around for the answer to this but haven't been able to find it, hope I'm not posting in the wrong place, if so I apologize.

I've been using workflow for my clothing industry for a while now but there are 2 things I cannot make work :

1- If I want to process plants into thread with a separate constraint for each.
Say I want 50-60 threads of pig tail and 50-60 threads of hemp, I cannot make it work even using the advanced options and selecting a specific plant. I get a message telling me it's not possible.
If I do the thread of any plant then there is no issue.

2-Say I want 50-60 cloth shirts and 10-20 cloth shirts in human size, I can make both on the workshop but when I create a worflow constraint it doesn't recognize they're different so if my dwarven sized shirt limit is reached it will stop the human sized one, I've found no way to add the size as an option even in advanced mode, I can just select quality and material.

I also have two issues with planning mode.

1-I can select the min quality of items I want used but not the max, so say I want to keep my wasterwork quality beds for my nobles and furnish the other rooms with any other quality I haven't found a way for it.

2-Same with materials, I've found how to select a specific material (say fungiwood for beds) or select a type (wood/stone etc) but say I want all woods except fungiwood, that I've not managed to find how to do so.


If someone could explain how that works I would be very grateful :)
And if some of those options are simply not implemented and it's not because it's impossible to do so I would ask if it would be possible to think about adding them in a future version please ?
The thing with human clothing specially is a pain, it lzads to a lot of micro managment specially when the goal is to create a set of mastework quality armor and not just have a bunch of clothes available to them.


Thanks in advance :)
Title: Re: DFHack 0.44.09-r1 | 0.44.10-alpha1 (dev)
Post by: lethosor on May 10, 2018, 08:15:18 am
I'm not familiar enough with workflow to know for sure, but for your first one, can you just make two separate jobs? It's possible that workflow doesn't recognize size at all, and I don't know what it would take to support it.

For buildingplan, I expect a maximum quality wouldn't be too hard. Negating the selected material shouldn't be too hard, but soon enough someone will want to do more complicated stuff (e.g. a certain list of materials), and that will be harder. I'm not actually sure how buildingplan keeps track of jobs, so I'm not sure how much it would have to be modified to keep track of negated materials, but I would expect it to be possible.

If you have a GitHub account, you could add those to the issue tracker - otherwise, I'll do it in a bit.
Title: Re: DFHack 0.44.09-r1 | 0.44.10-alpha1 (dev)
Post by: JezaGaia on May 10, 2018, 10:11:39 am
Thank you very much for your answer :)

I don't have an account on Github I'll look into it.


As for the two jobs that's what I try to do, a job for normal sized clothes, one for human sized ones, then I put them on repeat, and add a limit on the first one say dwarven sized or standard as you prefer to call it.
When I go to add a limit to the human sized one the previous limit is already showing meaning for workflow apparently it's exactly the same job no matter the difference in size.

I'm used to having similar jobs like say rock cabinets but being able to separate either by quality (I want 5 maser and 10 normal for example) or type of stone (one in granite the other in bauxite) but here I have nothing I can use to separate them.
I thought about just adding a big limit but even then it's not working well for me.
Say I add a limit of 50 shirts, I have no control on how many will be dwarven and how many human and that's an issue because often I end up with 50/0 or 40 human and 10 dwarven when it's the exact opposite I need.

As for the rest if it could be added it would be wonderful but I can understand not wanting to add too many variables because people begin to ask for always more. It's possible to do without so not a huge deal if ti's never made it's just a quality of life thing but it's not the hardest to have an empty room to build all your masterwork furniture in so it can't be used for normal furnishing and just deconstructiong what you need you're building special rooms. Just takes a bit of work.

The clothing size on the other hand is very complicated and requires a lot of micro managing so that would be a huge help if it was implemented.
Title: Re: DFHack 0.44.09-r1 | 0.44.10-alpha1 (dev)
Post by: lethosor on May 10, 2018, 10:48:08 pm
Has anyone here managed to reproduce this crash (https://github.com/DFHack/dfhack/issues/1057) (related to pressing the "v" key)? We really need help tracking it down - I've never been able to reproduce it, so it might be Windows-only, but it takes some time to reproduce, apparently. As much information as possible about your setup and what exactly triggers the crash would help. I also listed a few things to try here (https://github.com/DFHack/dfhack/issues/1057#issuecomment-354582176) in that thread.
Title: Re: DFHack 0.44.09-r1 | 0.44.10-alpha1 (dev)
Post by: sawtooth on May 10, 2018, 11:50:43 pm
I don't recall ever crashing using the 'v' key but I've had several crashes while using the Ctrl-Shift-Z key to get the "Stocks show" gui.  Sometimes I'm lazy and will just search for say, ash to see if my ashery finished the jobs I left it instead of going to the workshop itself.

It has happened to me playing 44.09 and also in the 44.10 alpha release of dfhack.  I've yet to see anything in any logs at all about the crash or even what caused the error.  I guess there's a slim chance that if other screens crash that it could be something in the gui backend that is causing the issue.  The stocks screen works almost all the time and I've yet to pin down anything on my end that can reproduce the crash at all.
Title: Re: DFHack 0.44.09-r1 | 0.44.10-alpha1 (dev)
Post by: lethosor on May 11, 2018, 12:10:58 am
The entire purpose of the alpha builds is for you to report things like that. I will try to look into it. Does "stocks show" on its own also crash? Are you sure you're holding down the right modifier keys (not forgetting or missing shift/Ctrl)? What screen are you pressing ctrl-shift-z on?
Title: Re: DFHack 0.44.09-r1 | 0.44.10-alpha1 (dev)
Post by: sawtooth on May 11, 2018, 01:39:18 am
The entire purpose of the alpha builds is for you to report things like that. I will try to look into it. Does "stocks show" on its own also crash? Are you sure you're holding down the right modifier keys (not forgetting or missing shift/Ctrl)? What screen are you pressing ctrl-shift-z on?

I usually use the shortcut to get to that stocks screen, but mainly because it's a shortcut and the other way takes longer.  I've tried to call up the screen hundreds of times since the last crash trying to cause the bug again with no luck.  Tried all sorts of things so far, resized the screen, fullscreen, changed the font sizes and so on.  I did not have any of the filters set on the stocks screen, just whatever the default options were.  I was hoping it was something I was doing and not some random item being brought onto the map or created causing an issue.  I don't have any control over cavern denizens and the fights they might be getting themselves into.  I also wouldn't have any control if the item was something carried by a visitor to the who would not be around after a crash and make it quite hard to reproduce.  I guess our only hope would be to get lucky and get a save from right before the crash happens, where upon reloading a save it would crash again.
Title: Re: DFHack 0.44.09-r1 | 0.44.10-alpha1 (dev)
Post by: PatrikLundell on May 11, 2018, 01:50:28 am
Negative results on 'v' crash. Using Windoze 10.1 (auto upgrading, as I'm lazy, so it might have been an earlier version back at 0.43.05, but not as old as 7) I don't think I've ever seen a 'v' crash.
Title: Re: DFHack 0.44.09-r1 | 0.44.10-alpha1 (dev)
Post by: lethosor on May 11, 2018, 08:18:22 am
I think I've figured out how to reproduce the "v" crash here (https://github.com/DFHack/dfhack/issues/1057#issuecomment-388359242). Quick fix: run "tweak block-labors disable".
Title: Re: DFHack 0.44.09-r1 | 0.44.10-alpha1 (dev)
Post by: lethosor on May 11, 2018, 11:21:25 pm
Turns out there was another cause to the "v" crash too. I got it to happen once in normal gameplay, but I couldn't reproduce it afterwards without breaking things intentionally, but it should be addressed now too.

If all goes to plan, binaries for https://github.com/DFHack/dfhack/releases/tag/0.44.10-beta1 will be uploaded in an hour or two, and it should fix that issue (and others!).
Title: Re: DFHack 0.44.09-r1 | 0.44.10-alpha1 (dev)
Post by: Splint on May 13, 2018, 07:41:59 am
Turns out there was another cause to the "v" crash too. I got it to happen once in normal gameplay, but I couldn't reproduce it afterwards without breaking things intentionally, but it should be addressed now too.

If all goes to plan, binaries for https://github.com/DFHack/dfhack/releases/tag/0.44.10-beta1 will be uploaded in an hour or two, and it should fix that issue (and others!).

Oh thank the holy powers for that, I was always scared to death of checking for injuries and changing labors because of that.
Title: Re: DFHack 0.44.09-r1 | 0.44.10-beta1 (dev)
Post by: Criperum on May 14, 2018, 06:01:14 pm
Is there a plan to add any mission related plugins or fixes? Or may be there are some (i'm mostly interested in fixes for squads leaving on a mission forever)
Title: Re: DFHack 0.44.09-r1 | 0.44.10-beta1 (dev)
Post by: lethosor on May 15, 2018, 10:13:39 am
Is there a plan to add any mission related plugins or fixes? Or may be there are some (i'm mostly interested in fixes for squads leaving on a mission forever)
Toady is actively working on fixes, and he has an advantage when it comes to fixing complicated things like that (we barely have any information on missions, as far as I know), so no, nobody has tried fixing those in DFHack yet.
Title: Re: DFHack 0.44.09-r1 | 0.44.10-beta1 (dev)
Post by: Bob69Joe on May 15, 2018, 04:04:44 pm
Hello dudes. I am adventiring woth a dwarf buddy and he got beat up real bad by zombie boars while crossing a frozen ocean. I stood over my buddy and made campfires in each direction but now I'm stuck as I can't walk over them and I can only pass time by pressing '.' so is there a way to clear campfires from the map?

I jumped over the fire anyways. :D
Title: Re: DFHack 0.44.09-r1 | 0.44.10-beta1 (dev)
Post by: Rumrusher on May 15, 2018, 04:28:49 pm
Is there a plan to add any mission related plugins or fixes? Or may be there are some (i'm mostly interested in fixes for squads leaving on a mission forever)
Toady is actively working on fixes, and he has an advantage when it comes to fixing complicated things like that (we barely have any information on missions, as far as I know), so no, nobody has tried fixing those in DFHack yet.
a solution to this might be to insert the missing units back into a squad that is already returning from a completed mission.
but that's kinda pulling historical figures from the void to replace the ones you lost.
Title: Re: DFHack 0.44.09-r1 | 0.44.10-beta1 (dev)
Post by: PatrikLundell on May 16, 2018, 10:17:03 am
Which script/plugin is responsible for the DFHack enhanced item info (I have a feeling I've asked this before, but my memory could definitely be better)? I'm looking at a "melting upper body" save, and think I see a correlation between the melting and DFHack ceasing to provide this information on the dress of an affected dorf, so I'd like to look at the script/code to see where it fails to read data to see if I can get any further.
Title: Re: DFHack 0.44.09-r1 | 0.44.10-beta1 (dev)
Post by: lethosor on May 16, 2018, 10:21:27 am
I think you're talking about view-item-info, which you can find by searching for "More information (DFHack)" in the scripts repo: https://github.com/DFHack/scripts/search?utf8=%E2%9C%93&q=More+information+%28DFHack%29&type=

However, I don't think dwarves melting necessarily means that their clothes are also melting, and I don't even know if that script is supposed to indicate melting (it doesn't contain "melt" anywhere). I don't think it should contain unit-specific information in any case, because it applies to any items, not just items owned/worn by units.
Title: Re: DFHack 0.44.09-r1 | 0.44.10-beta1 (dev)
Post by: PatrikLundell on May 16, 2018, 10:42:40 am
Thanks Lethosor.
Removing the dress of a dwarf that would melt caused her not to melt, while others still did. I don't think the item causes melting, but rather that some kind of corruption may be involved in the melting. The thing is that when the save is loaded, the dress is displayed correctly with info, dwarf size, armor info, etc, but after a certain point only the basic dress info is shows, so I think the script fails to retrieve some piece of info and gives up at that point. Thus, I'd like to see find out what's suddenly no longer available.

Edit: Yes, you're correct. It's a bug in the script, completely unrelated to the melting issue.
The problem is that every time you view the SAME item "get_custom_item_desc" fetches a description using a different script and then adds a blank line to it. However, the next time that same info is fetched the previously added blank line is included in the data fetched, and a blank line is added...

This causes the number of blank lines between the description and the other properties to increase by one, pushing more and more data off the bottom of the view.
I assume the visible results of this can be worked around by checking if there's a blank line at the end already, and not add one if there is, but you probably shouldn't have added that line to that data in the first place, but rather have it as a lead for the DFHack added stuff.

Note that I've looked at inventory clothing items only, but looking at all items of a dorf, exiting the view, bring up the 'v' view again and viewing the items again show them all getting two blank lines. I haven't looked at other items.

Edit 2: Raised DFHack issue #1273 for it.
Title: Re: DFHack 0.44.09-r1 | 0.44.10-beta1 (dev)
Post by: xordae on May 16, 2018, 02:08:25 pm
The new vanilla Ctrl-n option to name buildings will not accept the 'w' character as that changes the wheelbarrow setting. Ctrl-Shift-n works fine. As I don't play vanilla, I'm not sure if this is an issue with DFHack or not.
Title: Re: DFHack 0.44.09-r1 | 0.44.10-beta1 (dev)
Post by: lethosor on May 16, 2018, 03:36:35 pm
The ability to type in the number of wheelbarrows is a DFHack feature; vanilla just lets you cycle from 0 to 3.
I think that hasn't been fixed yet, but in the future, could you please specify the exact version of DFHack you're using? We fixed a number of similar issues to that in 0.44.10-beta1, and have received a couple complaints from people that were still using 0.44.10-alpha1.
Title: Re: DFHack 0.44.09-r1 | 0.44.10-beta1 (dev)
Post by: xordae on May 16, 2018, 07:18:24 pm
Sorry, I'm on 0.44.10-beta1.
Title: Re: DFHack 0.44.09-r1 | 0.44.10-beta1 (dev)
Post by: lethosor on May 16, 2018, 07:27:44 pm
I apparently didn't remember to update my last post, but I did fix it, so it should work in whatever the next version ends up being.

I've been using workflow for my clothing industry for a while now but there are 2 things I cannot make work :

1- If I want to process plants into thread with a separate constraint for each.
Say I want 50-60 threads of pig tail and 50-60 threads of hemp, I cannot make it work even using the advanced options and selecting a specific plant. I get a message telling me it's not possible.
If I do the thread of any plant then there is no issue.

2-Say I want 50-60 cloth shirts and 10-20 cloth shirts in human size, I can make both on the workshop but when I create a worflow constraint it doesn't recognize they're different so if my dwarven sized shirt limit is reached it will stop the human sized one, I've found no way to add the size as an option even in advanced mode, I can just select quality and material.
I added your buildingplan stuff to the issue tracker (https://github.com/DFHack/dfhack/issues) but I'm not sure how to handle the workflow stuff. When you get a chance, could you look through the workflow-tagged issues (https://github.com/DFHack/dfhack/issues?utf8=%E2%9C%93&q=label%3Aworkflow+), make sure yours aren't already listed, then report them if they're not?
Title: Re: DFHack 0.44.09-r1 | 0.44.10-beta1 (dev)
Post by: JezaGaia on May 19, 2018, 10:54:00 am
I apparently didn't remember to update my last post, but I did fix it, so it should work in whatever the next version ends up being.

I've been using workflow for my clothing industry for a while now but there are 2 things I cannot make work :

1- If I want to process plants into thread with a separate constraint for each.
Say I want 50-60 threads of pig tail and 50-60 threads of hemp, I cannot make it work even using the advanced options and selecting a specific plant. I get a message telling me it's not possible.
If I do the thread of any plant then there is no issue.

2-Say I want 50-60 cloth shirts and 10-20 cloth shirts in human size, I can make both on the workshop but when I create a worflow constraint it doesn't recognize they're different so if my dwarven sized shirt limit is reached it will stop the human sized one, I've found no way to add the size as an option even in advanced mode, I can just select quality and material.
I added your buildingplan stuff to the issue tracker (https://github.com/DFHack/dfhack/issues) but I'm not sure how to handle the workflow stuff. When you get a chance, could you look through the workflow-tagged issues (https://github.com/DFHack/dfhack/issues?utf8=%E2%9C%93&q=label%3Aworkflow+), make sure yours aren't already listed, then report them if they're not?

Thanks for the link, I'll bookmark the site for the future. You're right my 2 issues are known and not easily (or at all )fixable.
Shame but oh well I'll have to live with it.

The one about sizes (human vs dwarf) as I got lucky enough to get 2 sources of cloth  (pig tail and rope reed) I'll simply try by making human clothes in one specific material and dwarves in the other one and set specific limits using the material and not just the item as this seems to work well.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on May 19, 2018, 01:48:43 pm
Shoot, I forgot to update this thread! There's a release up for 0.44.10, in case anyone hasn't seen it already: https://github.com/DFHack/dfhack/releases/tag/0.44.10-r1
And just in time, we got around 5 more pull requests overnight (after releasing it), so that'll be fun.
Title: Re: DFHack 0.44.10-r1
Post by: Clément on May 20, 2018, 04:17:15 am
Is there any instructions on building a C++ application with cmake using dfhack-client, particularly RemoteClient. I did not find anything in the doc and I have an issue with compatibility between dfhack's protobuf and my system protobuf.
Title: Re: DFHack 0.44.10-r1
Post by: Rose on May 20, 2018, 06:57:29 am
Just run the build scripts, pretty much.

There's a compiling page in the documentation.
Title: Re: DFHack 0.44.10-r1
Post by: Clément on May 20, 2018, 07:19:37 am
I did not mean building dfhack but separate project using dfhack-client. Or did I misunderstand and it is not supposed to be used outside of dfhack? Should I reimplement my own RemoteClient? (no doc about the protocol either I guess, I'll have to read the source code)
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on May 20, 2018, 07:21:51 am
Is there any instructions on building a C++ application with cmake using dfhack-client, particularly RemoteClient. I did not find anything in the doc and I have an issue with compatibility between dfhack's protobuf and my system protobuf.
DFHack uses an older protobuf 2, so you might have to specify that in your proto files. You could also probably use DFHack's protobuf compiler, which gets built along with DFHack. I'd need more details about the compatibility issue for anything else.
Title: Re: DFHack 0.44.10-r1
Post by: Clément on May 20, 2018, 07:37:40 am
Including RemoteClient.h from dfhack's library/include indirectly includes a generated header from protobuf (for the core messages) which contains preprocessor check for protoc version.

But I may just reimplement RemoteClient in my case, the protocol looks simple (and documented in the code).
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on May 20, 2018, 07:53:09 am
I'm not sure you need RemoteClient.h - that might be for dfhack-run. I would try using the CoreProtocol proto file to generate files for whatever language you're using and use those.
Title: Re: DFHack 0.44.10-r1
Post by: Rose on May 20, 2018, 09:56:12 am
Remoteclient is used for remotefortressreader, isoworld, and stonesense.
Title: Re: DFHack 0.44.10-r1
Post by: userpay on May 20, 2018, 04:40:45 pm
Is there a way to show magma or water being present in caverns from the embark screen? Been using embark-assistant so I know that there will be magma in a certain range but I don't know which tile it's present in which makes it harder for me to determine where exactly I want to embark.
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on May 21, 2018, 03:00:43 am
Is there a way to show magma or water being present in caverns from the embark screen? Been using embark-assistant so I know that there will be magma in a certain range but I don't know which tile it's present in which makes it harder for me to determine where exactly I want to embark.
You *could* use embark-assistant to look for single tile embarks with magma pipes as a rather heavy handed way to locate which tile the pipe is in. Apart from that, I don't think there are any ready made scripts for it, so you'd have to roll your own.

When it comes to cavern water I don't know if there is a way to determine if water will appear (apart from embarking and looking at what DF generated, discard the probe embarks until a desirable one is found and then embark "properly"). There is a parameter for the probability of water being present, and I know water will not be present if it's below 10. However, there is no value that guarantees water will be present.
Title: Re: DFHack 0.44.10-r1
Post by: userpay on May 21, 2018, 11:19:34 am
Is there a way to show magma or water being present in caverns from the embark screen? Been using embark-assistant so I know that there will be magma in a certain range but I don't know which tile it's present in which makes it harder for me to determine where exactly I want to embark.
You *could* use embark-assistant to look for single tile embarks with magma pipes as a rather heavy handed way to locate which tile the pipe is in. Apart from that, I don't think there are any ready made scripts for it, so you'd have to roll your own.

When it comes to cavern water I don't know if there is a way to determine if water will appear (apart from embarking and looking at what DF generated, discard the probe embarks until a desirable one is found and then embark "properly"). There is a parameter for the probability of water being present, and I know water will not be present if it's below 10. However, there is no value that guarantees water will be present.

Hmm... A roundabout way of going about things but that would be viable, find a spot I like normally then run embark-assistant with the 1x1 designation to figure out where it is to maximize getting the resources I wanted. I only brought up the cavern water as I thought it was odd you could search for magma in the caverns, water down to brook, but not water in caverns. Thank ya kindly.
Title: Re: DFHack 0.44.09-r1
Post by: Bumber on May 22, 2018, 01:46:31 am
Digging this back up regarding temperature testing:
You don't need to teleport an adventurer around for Isoworld, as far as I can determine (I'm not familiar with it, so I've just taken a quick look), but it looks like it uses DF exported maps for starters, and except for site maps, those maps only go down to the mid tile level, not the in-game one, and for that level you can just use pre embark manipulation to shift focus.
Turns out it was related to a script Bearskie uses to stitch together whole maps. He recently mentioned it in the IsoWorld thread, but I'm not sure if he's posted it anywhere.
Title: Re: DFHack 0.44.10-r1
Post by: Bearskie on May 22, 2018, 02:54:52 am
Ugh, I'm really not proud of it, but if it gets to help someone, here it is  (https://www.reddit.com/r/dwarffortress/comments/83dper/z/dzc7dpp). It's my first and only time writing a DFhack script, so expect errors and general fuckery.

The central logic - use Putnam's teleport.lua to teleport an adventurer 48 squares (ie. 1 embark) in one direction, simulate some adventurer movement key-presses to activate/generate the area, and rinse repeat.

The script would likely be too slow for your purposes, as mapping the world once takes long enough, not to mention 365 times in a year.

Anyway, it teleports a flying adventurer three embark tiles at a time, so in your case you'd bump that up to 16 which is the width of a world tile. Most of the code deals with enforced delays and timeouts, ie. waiting for isoworld to render a detailed tile. In your case it won't be necessary, which speeds up the teleports considerably.
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on May 22, 2018, 03:38:34 am
Thank you very much, both of you.
I'll definitely take a look at it and try to adapt it to my situation.
It's fair to warn about shoddy quality (and I definitely won't hold anyone responsible for me using things that have warnings attached), but even unfinished and unpolished things can be more than sufficient to fill out technical holes and provide techniques not thought of.

Time isn't really a huge issue (depending on what "slow" is, of course), as it would be something I'd start and then let it run in the background (or, for that matter, foreground when going to bed).
Title: Re: DFHack 0.44.10-r1
Post by: jecowa on May 23, 2018, 01:36:33 am
DFHack 64-bit GCC 7.3.0 seems to work fine in MacOS X 10.6, 10.7, and 10.12. I don't really know what to test or look for exactly. Createitem, Reveal, Unreveal, Mousequery, Autolabor, and Labormanager commands all seem to work. Then I tried installing TWBT on Lion and Sierra and the main feature and multilevel both seem to work.

Does GCC do anything cool for us? I think you told me before, but I forgot.
Title: Re: DFHack 0.44.10-r1
Post by: Clément on May 23, 2018, 07:48:03 am
Is there a way to generate a random dwarf ex nihilo or force migration waves or something similar? I'd like to check preferences of a large number of dwarves as generated by the game.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on May 23, 2018, 08:11:42 am
DFHack 64-bit GCC 7.3.0 seems to work fine in MacOS X 10.6, 10.7, and 10.12. I don't really know what to test or look for exactly. Createitem, Reveal, Unreveal, Mousequery, Autolabor, and Labormanager commands all seem to work. Then I tried installing TWBT on Lion and Sierra and the main feature and multilevel both seem to work.

Does GCC do anything cool for us? I think you told me before, but I forgot.
That's basically all I need to be confident that it works across OS X versions - thanks!

GCC is what we have to use (because DF uses it). The only really "cool" thing about GCC 7 in this case is that it's actually possible to get working on newer macOS versions without putting in excessive effort (including compiling from source if you're using Homebrew), and it was the newest GCC version when we added support for it.

Is there a way to generate a random dwarf ex nihilo or force migration waves or something similar? I'd like to check preferences of a large number of dwarves as generated by the game.
"force migrants" or maybe "migrants-now" (not sure why we have two...)
Note that the criteria for limiting migrants do apply, so you might only get 2 waves worth of migrants before no more arrive for the rest of the season.
Title: Re: DFHack 0.44.10-r1
Post by: SlimeOfSteel on May 23, 2018, 09:28:59 am
I enjoy using DFHack and I know that development on it isn't easy, but DFHack needs support for other programming applications like Eclipse (which is what I have on my flash drive).

I can only access the C: drive of my home computer, so installing Visual Studio on a flash drive is something that would benefit me greatly in development of scripts. However, after some Google searches, even if you specify the install path to somewhere besides the C: drive, a ton of files are installed to the C: drive anyways!

Here's a quote from this thread (https://social.msdn.microsoft.com/Forums/en-US/3e7160ef-505e-4c48-a1aa-78e778c13ee0/install-visual-studio-2017-in-d-drive?forum=vssetup (https://social.msdn.microsoft.com/Forums/en-US/3e7160ef-505e-4c48-a1aa-78e778c13ee0/install-visual-studio-2017-in-d-drive?forum=vssetup)) on MSDN:

Quote
this won't change location of all files, but only of those which can be (by design) installed onto different location. Be warned that there is many shared components which will be installed into shared repositories on drive C: without any possibility to change their path.

Again, I'd love to contribute to DFHack (in fact, I'm sure a lot of people would), but I think that allowing support for something like Eclipse would make plugin development easier, in my opinion.

I'm not annoyed with the developers, I'm annoyed at Microsoft because apparently, if I want a portable Visual Studio, I just need to carry around my HDD and a SATA cable, then just connect my HDD to an empty SATA port of the computer I want to use.

TL;DR: I'd like DFHack to have support for something like Eclipse because I can't get VS to run on a flash drive no matter what I do.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on May 23, 2018, 09:47:32 am
We have no choice as to what compiler to allow on Windows. You must use the Visual Studio 2015 compiler, because that's what DF uses, and if DFHack is built with a different compiler than DF, it will either fail to compile or crash on startup. Even if we wanted to allow other compilers, it's simply not possible.

We aren't opposed to other IDEs, though, and if you can get Eclipse to work with the VS2015 compiler, great. If there's a way we can adjust the CMake configuration to support that, or document the process somehow, that's even better. I don't know of anyone that has done that yet, but it might be possible.
Title: Re: DFHack 0.44.10-r1
Post by: Saiko Kila on May 23, 2018, 09:53:47 am
The crazy system disk space requirements of Visual Studio is the only reason I don't have it currently installed. But this is a recurring theme in Microsoft applications - they are just bad programmers (which I'm certain after reading some of their blogs). Even if they allow to install any suite besides C: drive, it will be flooded anyway, sometimes with duplicate files, and a total mess will be created. Huge non-Microsoft applications usually handle such issues much better. Sorry for ranting, but I'm becoming very angry every time I'm reminded about this problem.

However, I came to this thread for completely unrelated reason. DFHack includes a script extra-gamelog.lua. This script, after slight modification, allows me to log when siege is present on gameload, which I need for SoundSense, and this part works great. But, if I see correctly, this script also should log events like workshop completion, mayor election (different than vanilla DF), and most importantly to me siege end. It seems it doesn't do it by default. Anyone knows how to trigger logging of these items?
Title: Re: DFHack 0.44.10-r1
Post by: SlimeOfSteel on May 23, 2018, 09:54:23 am
We have no choice as to what compiler to allow on Windows. You must use the Visual Studio 2015 compiler, because that's what DF uses, and if DFHack is built with a different compiler than DF, it will either fail to compile or crash on startup. Even if we wanted to allow other compilers, it's simply not possible.

We aren't opposed to other IDEs, though, and if you can get Eclipse to work with the VS2015 compiler, great. If there's a way we can adjust the CMake configuration to support that, or document the process somehow, that's even better. I don't know of anyone that has done that yet, but it might be possible.

Eclipse does support C++, but I don't know how to get it to use the VS2015 compiler. Or where to find said compiler. As you said, it might be possible, but I have no idea how to do it.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on May 23, 2018, 10:06:48 am
Eclipse does support C++, but I don't know how to get it to use the VS2015 compiler. Or where to find said compiler. As you said, it might be possible, but I have no idea how to do it.
I linked to it in your last thread (http://www.bay12forums.com/smf/index.php?topic=170687.msg7763923#msg7763923): https://www.visualstudio.com/vs/older-downloads/#microsoft-build-tools-2015-update-3
Note that I don't actually know if it will work, but BenLubar thinks it would. I also don't know if it can be installed on an external drive.

However, I came to this thread for completely unrelated reason. DFHack includes a script extra-gamelog.lua. This script, after slight modification, allows me to log when siege is present on gameload, which I need for SoundSense, and this part works great. But, if I see correctly, this script also should log events like workshop completion, mayor election (different than vanilla DF), and most importantly to me siege end. It seems it doesn't do it by default. Anyone knows how to trigger logging of these items?
Not sure why it would only log sieges. You're only running the script once, right?
Title: Re: DFHack 0.44.10-r1
Post by: SlimeOfSteel on May 23, 2018, 10:18:30 am
I linked to it in your last thread

...Okay, I'll be honest, I feel a bit stupid. I wasn't absolutely sure what the compiler files were, so I wasn't sure if that VS Build Tools was what I was looking for. I'll take your word for it, though.
Title: Re: DFHack 0.44.10-r1
Post by: Saiko Kila on May 23, 2018, 10:29:39 am
However, I came to this thread for completely unrelated reason. DFHack includes a script extra-gamelog.lua. This script, after slight modification, allows me to log when siege is present on gameload, which I need for SoundSense, and this part works great. But, if I see correctly, this script also should log events like workshop completion, mayor election (different than vanilla DF), and most importantly to me siege end. It seems it doesn't do it by default. Anyone knows how to trigger logging of these items?
Not sure why it would only log sieges. You're only running the script once, right?

I assumed that if it is enabled in the *.init, it runs in loop, constantly. But I get only the "onload" part of the logs from the srcipt (like season info), not the "loop" part (like workshop completion). Maybe my assumption was wrong. Does it have to be enabled in special way to get the loop/repeated part?
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on May 23, 2018, 10:33:54 am
Well, again, I don't know for sure if that's enough. BenLubar has had luck compiling for Windows on Linux, though, so I assume he knows what works. Not sure how closely he follows this thread, but if you have questions, he's usually around on IRC/GitHub.

I assumed that if it is enabled in the *.init, it runs in loop, constantly. But I get only the "onload" part of the logs from the srcipt (like season info), not the "loop" part (like workshop completion). Maybe my assumption was wrong. Does it have to be enabled in special way to get the loop/repeated part?
Which "*.init" exactly is it enabled in? Is it running "modtools/extra-gamelog enable"? (The "enable" part is important.) Have you unloaded and loaded a world before noticing this issue?

Edit: reported several issues I identified at https://github.com/DFHack/dfhack/issues/1287
Title: Re: DFHack 0.44.10-r1
Post by: Saiko Kila on May 23, 2018, 10:52:21 am
Well, again, I don't know for sure if that's enough. BenLubar has had luck compiling for Windows on Linux, though, so I assume he knows what works. Not sure how closely he follows this thread, but if you have questions, he's usually around on IRC/GitHub.

I assumed that if it is enabled in the *.init, it runs in loop, constantly. But I get only the "onload" part of the logs from the srcipt (like season info), not the "loop" part (like workshop completion). Maybe my assumption was wrong. Does it have to be enabled in special way to get the loop/repeated part?
Which "*.init" exactly is it enabled in? Is it running "modtools/extra-gamelog enable"? (The "enable" part is important.) Have you unloaded and loaded a world before noticing this issue?

Edit: reported several issues I identified at https://github.com/DFHack/dfhack/issues/1287


dfhack.init has this:
Code: [Select]
modtools/extra-gamelog enable
I have been using it for days, so loaded the world many times, but never was interested in the "loop" part till recently. Only then I checked gamelog.txt and noticed, that there's no information about mayor election or siege breaks. Only these things which are logged on load are present.

EDIT: Oh, I see, these are issues I'm talking about.

EDIT2: I moved call of event_loop() to log_on_load(), and changed event_loop() to global (after looking up how to do it, I didn't know LUA conventions). This causes the siege info to work as intended (I think), causes mayor info to work (though I'm not sure if as intended, because it is logged every time the fort is loaded), and the building info still doesn't work. But honestly, the only thing I personally needed was siege info for SoundSense, so I'm OK. Thanks for help.
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on May 23, 2018, 12:00:32 pm
If you install VS on a drive different from C: you can't use a number of the scripts as the are, as they're hard coded to C:, and if you change them to work you have to copy them out and replace them with the original for the blasted git to allow you to upload anything (it won't accept your local modifications staying local: you either have to commit them [which trashes the original if accepted], or delete the remove).
I've also found that I can't set up stonesense for compilation because the setup gui script uses a symbol that still points to C: (which I can't change without old stuff installed there breaking). A clean install of the computer and applications where everything goes to D: might work, unless you have stuff that's still hard coded for C:. Fortunately, I don't really care about compiling stonesense (Only tried it because of issues that turned out to be due it internal DF git setup upgrades at the same time).
Title: Re: DFHack 0.44.10-r1
Post by: Clément on May 23, 2018, 01:28:39 pm
"force migrants" or maybe "migrants-now" (not sure why we have two...)
Note that the criteria for limiting migrants do apply, so you might only get 2 waves worth of migrants before no more arrive for the rest of the season.

Nothing better than that? thistleknot (http://www.bay12forums.com/smf/index.php?topic=168411.msg7711270#msg7711270) used attribute data from 5000 dwarves. I would be interested for something on this scale, but I don't know how it was done.

Nothing happens when I type these commands after a fresh embark. Does it need time or a minimum wealth before migrants appear?
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on May 23, 2018, 02:13:37 pm
EDIT: Oh, I see, these are issues I'm talking about.

EDIT2: I moved call of event_loop() to log_on_load(), and changed event_loop() to global (after looking up how to do it, I didn't know LUA conventions). This causes the siege info to work as intended (I think), causes mayor info to work (though I'm not sure if as intended, because it is logged every time the fort is loaded), and the building info still doesn't work. But honestly, the only thing I personally needed was siege info for SoundSense, so I'm OK. Thanks for help.
What does "changed event_loop() to global" mean? I didn't say anything about that, and event_loop() having the local keyword doesn't have anything to do with the issues I mentioned.

There's no easy and good way to avoid logging mayor changes when the fort loads, unfortunately. I guess there could be a special case for the first run after a world loads.

If you install VS on a drive different from C: you can't use a number of the scripts as the are, as they're hard coded to C:, and if you change them to work you have to copy them out and replace them with the original for the blasted git to allow you to upload anything (it won't accept your local modifications staying local: you either have to commit them [which trashes the original if accepted], or delete the remove).
I've also found that I can't set up stonesense for compilation because the setup gui script uses a symbol that still points to C: (which I can't change without old stuff installed there breaking). A clean install of the computer and applications where everything goes to D: might work, unless you have stuff that's still hard coded for C:. Fortunately, I don't really care about compiling stonesense (Only tried it because of issues that turned out to be due it internal DF git setup upgrades at the same time).
You should absolutely be able to change the build scripts and avoid committing them without Git complaining. The only time Git would complain is if the build scripts also change in DFHack's repo, and that happens rarely and can be worked around without you having to get rid of (or commit) your local changes.

What stonesense build script are you referring to? The only things that contain "C:" in the build folder are build/win64/package-debug.bat and build/win64/package-release.bat, and they don't deal with stonesense. plugins/stonesense/CMakeLists.txt does not contain "C:".

Nothing better than that? thistleknot (http://www.bay12forums.com/smf/index.php?topic=168411.msg7711270#msg7711270) used attribute data from 5000 dwarves. I would be interested for something on this scale, but I don't know how it was done.

Nothing happens when I type these commands after a fresh embark. Does it need time or a minimum wealth before migrants appear?
You didn't say you wanted 5000 of them - the normal criteria for migrants apply to those scripts, so they won't work if it's too early (as well as if you have too many recent migrants). Thistleknot says he used 5000 "generated" dwarves, which could be from the arena or using spawnunit or modtools/create-unit (which use the arena unit-creation code). I don't know if the variety distribution of migrants is any different, but I can't think of a way to come up with 5000 dwarves otherwise without ~100+ fortresses.
Title: Re: DFHack 0.44.10-r1
Post by: Atomic Chicken on May 23, 2018, 02:16:23 pm
Nothing better than that? thistleknot (http://www.bay12forums.com/smf/index.php?topic=168411.msg7711270#msg7711270) used attribute data from 5000 dwarves. I would be interested for something on this scale, but I don't know how it was done.

The script "modtools/create-unit" lets the game handle preference generation (alongside a bunch of other stuff) for the units it spawns. As such, you could use something like this for your research:

Code: [Select]
local spawnNumber = 10 -- replace this with the number of dwarves you want to spawn

local x,y,z = pos2xyz(df.global.cursor)
if not z then
  qerror('First place your cursor on the screen to choose a spawn location!')
end


for n = 1,spawnNumber do
  dfhack.run_command("modtools/create-unit -race DWARF -caste MALE -name MOUNTAIN -setUnitToFort -location [ "..x.." "..y.." "..z.." ]")
end

Specify the number of dwarves you want to spawn where indicated in the script before running it. Note that it's entirely possible to generate and observe 5000 dwarves at a go with this, but your FPS will be absolutely murdered if you attempt to unpause.

Come to think of it, perhaps it'd be a good idea to add this functionality to the actual script.
Title: Re: DFHack 0.44.10-r1
Post by: Saiko Kila on May 23, 2018, 02:31:44 pm
EDIT: Oh, I see, these are issues I'm talking about.

EDIT2: I moved call of event_loop() to log_on_load(), and changed event_loop() to global (after looking up how to do it, I didn't know LUA conventions). This causes the siege info to work as intended (I think), causes mayor info to work (though I'm not sure if as intended, because it is logged every time the fort is loaded), and the building info still doesn't work. But honestly, the only thing I personally needed was siege info for SoundSense, so I'm OK. Thanks for help.
What does "changed event_loop() to global" mean? I didn't say anything about that, and event_loop() having the local keyword doesn't have anything to do with the issues I mentioned.

I had to remove "local" from line
Code: [Select]
local function event_loop()
Otherwise I get DFHack error:
Quote
...ames\DFv44.10-64/hack/scripts/modtools/extra-gamelog.lua:67: attempt to call a nil value (global 'event_loop')
stack traceback:
   ...ames\DFv44.10-64/hack/scripts/modtools/extra-gamelog.lua:67: in function <...ames\DFv44.10-64/hack/scripts/modtools/extra-gamelog.lua:13>
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on May 23, 2018, 02:45:12 pm
I had to remove "local" from line
Code: [Select]
local function event_loop()
Otherwise I get DFHack error:
Quote
...ames\DFv44.10-64/hack/scripts/modtools/extra-gamelog.lua:67: attempt to call a nil value (global 'event_loop')
stack traceback:
   ...ames\DFv44.10-64/hack/scripts/modtools/extra-gamelog.lua:67: in function <...ames\DFv44.10-64/hack/scripts/modtools/extra-gamelog.lua:13>
Oh, okay, that's because of Lua's scoping rules - inside functions, you can only access things that are global (without the "local" keyword), or things that are local and defined before the current function. event_loop is defined near the end of the script, so that makes sense. Thanks - that'll be good to keep in mind for whoever fixes the script.

Atomic Chicken: use "for n = 1, spawnNumber", not the stuff with the while loop. I agree that a quantity flag would be useful (like modtools/create-item), and was thinking of adding one but never got around to it.
Title: Re: DFHack 0.44.10-r1
Post by: Atomic Chicken on May 23, 2018, 03:30:38 pm
Atomic Chicken: use "for n = 1, spawnNumber", not the stuff with the while loop. I agree that a quantity flag would be useful (like modtools/create-item), and was thinking of adding one but never got around to it.

Oh wow, brain fart right there. Edited accordingly. I'll get a PR for that quantity arg in place shortly.
Title: Re: DFHack 0.44.10-r1
Post by: userpay on May 23, 2018, 03:46:43 pm
Is there a way/script to use DFhack to change a dwarf's emotions to counteract the current 'bug' of sorts that's leading to emotion runaway? Or perhaps another utility? I updated from 9 to 10 because I'd heard the stability was better but didn't realize 10 was where the emotion issue was occurring.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on May 23, 2018, 03:50:32 pm
Atomic Chicken: use "for n = 1, spawnNumber", not the stuff with the while loop. I agree that a quantity flag would be useful (like modtools/create-item), and was thinking of adding one but never got around to it.

Oh wow, brain fart right there. Edited accordingly. I'll get a PR for that quantity arg in place shortly.
To be fair, while loops aren't always bad, of course - I'm a bit paranoid after https://github.com/DFHack/dfhack/issues/1285. Thanks for the soon-to-be-PR.

Is there a way/script to use DFhack to change a dwarf's emotions to counteract the current 'bug' of sorts that's leading to emotion runaway? Or perhaps another utility? I updated from 9 to 10 because I'd heard the stability was better but didn't realize 10 was where the emotion issue was occurring.
Some people have had luck with the remove-stress command, although it only works for the short term (you'll have to run it repeatedly). Thoughts can definitely be modified/removed (the misery plugin does the opposite) but I haven't looked at the issues in 0.44.10 much. You could look at what misery does and see if there's a way to modify thoughts (maybe with gui/gm-editor?).
Title: Re: DFHack 0.44.10-r1
Post by: userpay on May 23, 2018, 04:08:44 pm
Atomic Chicken: use "for n = 1, spawnNumber", not the stuff with the while loop. I agree that a quantity flag would be useful (like modtools/create-item), and was thinking of adding one but never got around to it.

Oh wow, brain fart right there. Edited accordingly. I'll get a PR for that quantity arg in place shortly.
To be fair, while loops aren't always bad, of course - I'm a bit paranoid after https://github.com/DFHack/dfhack/issues/1285. Thanks for the soon-to-be-PR.

Is there a way/script to use DFhack to change a dwarf's emotions to counteract the current 'bug' of sorts that's leading to emotion runaway? Or perhaps another utility? I updated from 9 to 10 because I'd heard the stability was better but didn't realize 10 was where the emotion issue was occurring.
Some people have had luck with the remove-stress command, although it only works for the short term (you'll have to run it repeatedly). Thoughts can definitely be modified/removed (the misery plugin does the opposite) but I haven't looked at the issues in 0.44.10 much. You could look at what misery does and see if there's a way to modify thoughts (maybe with gui/gm-editor?).

Hmm... Sounds promising. While my programming is rusty (much less I've never programmed for DF) it should be relatively simple to swap out the added negative thought for a positive one no? I'll have to look into it if issues start arising in my fort. Kinda surprised the opposite hasn't been made already but I guess since the negative emotion thing is relatively recent that would explain it.
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on May 23, 2018, 04:44:31 pm
:
If you install VS on a drive different from C: you can't use a number of the scripts as the are, as they're hard coded to C:, and if you change them to work you have to copy them out and replace them with the original for the blasted git to allow you to upload anything (it won't accept your local modifications staying local: you either have to commit them [which trashes the original if accepted], or delete the remove).
I've also found that I can't set up stonesense for compilation because the setup gui script uses a symbol that still points to C: (which I can't change without old stuff installed there breaking). A clean install of the computer and applications where everything goes to D: might work, unless you have stuff that's still hard coded for C:. Fortunately, I don't really care about compiling stonesense (Only tried it because of issues that turned out to be due it internal DF git setup upgrades at the same time).
You should absolutely be able to change the build scripts and avoid committing them without Git complaining. The only time Git would complain is if the build scripts also change in DFHack's repo, and that happens rarely and can be worked around without you having to get rid of (or commit) your local changes.

What stonesense build script are you referring to? The only things that contain "C:" in the build folder are build/win64/package-debug.bat and build/win64/package-release.bat, and they don't deal with stonesense. plugins/stonesense/CMakeLists.txt does not contain "C:".
:
When I tried to push things with the scripts changed but not added and commited git complained. It was a while ago as I've given up (as is typically the case with git...) and copy the blasted install-debug.bat script back and forth (and git didn't like a working copy of the script with a different name either).
Stonesense:The annoying thing there is that it's not even a build script, but the generate-MSVC-gui.bat script, which starts to download stuff and then barf when the stonesense checkbox has been checked, so it blows up during configuration of what to build eventually. It's probably due to the %XXX% symbol having to point to the C drive for old stuff (like the web browser) to continue to work.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on May 23, 2018, 05:09:19 pm
When I tried to push things with the scripts changed but not added and commited git complained.
That's not a situation where Git can complain.
Quote
Stonesense:The annoying thing there is that it's not even a build script, but the generate-MSVC-gui.bat script, which starts to download stuff and then barf when the stonesense checkbox has been checked, so it blows up during configuration of what to build eventually. It's probably due to the %XXX% symbol having to point to the C drive for old stuff (like the web browser) to continue to work.
Is this just an assumption, or did you see an error message pertaining to the C drive? I checked again, and "C:\" and "%XXX%" don't appear in stonesense (and if the latter was just a placeholder, there aren't any batch files in stonesense that could be using a symbol like that). An error message would help us figure out what's going wrong.

Anyway, I'm sorry you're having trouble with Git. Are you using the command line or some graphical Git client? I recommend the former as it has more documentation available. I can try to find some good tutorials if it would help - DFHack's workflow is based on "git flow", so searching for that might help with the DFHack-specific Git workflow.
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on May 24, 2018, 02:03:29 am
%XXX% is a placeholder for %program files (86)% or something along those lines.

I believe I did see an error message saying that something or other couldn't be found at the C: drive, and I think it pointed down the program file guff path to where VS would have been placed if it had been on the C: drive.

I'm using the the command line (git xxx <guess at parameters here>). "git help" provides a dozen commands, most of which I've never used, and most of the ones I need aren't listed. The "documentation" is horrible, resulting in a web page that only provides overall syntax, but not any parameters, nor any description of the commands. Web searches are needed to find commands, and sub repo juggling was found in a comment somewhere half way through a discussion of failed attempts.
As it currently stands, I can stumble by with git and a frequent "remove everything and download from scratch" approach. For instance, I won't create a new pull request in a (sub) repo before the previous one is done as I don't want to try to juggle several instances of it (and the complete DFHack surrounding it that's required for the sub repo stuff to be tested), as pull requests are frequently requested to be changed, so the local copy needs to be prepared for making changes to be pushed up.
Title: Re: DFHack 0.44.10-r1
Post by: Rose on May 24, 2018, 02:15:03 am
There's a dozen or so gui frontends for git that make it a lot easier.
Title: Re: DFHack 0.44.10-r1
Post by: jecowa on May 24, 2018, 02:48:36 am
Git front ends do not seem to make git easier to understand. The ones I've seen just add buttons for the different commands. Still have to wrap your head around how it works.

Here's how I use github most of the time:

Note: If you're not on the group for the GitHub project, you'll probably want to fork the project first from the UI on GitHub.com so that you can upload your edits back to your fork.
Key: Terminal commands are in light blue. Text that you should edit for your case are in italics.


If you have any problems, backup the project to another folder and reclone it from the github.
Title: Re: DFHack 0.44.10-r1
Post by: Clément on May 24, 2018, 04:55:45 am
The script "modtools/create-unit" lets the game handle preference generation (alongside a bunch of other stuff) for the units it spawns. As such, you could use something like this for your research:

[...]
Thanks for the script.
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on May 24, 2018, 05:27:41 am
Thanks jecowa.
That's partially covered here: https://dfhack.readthedocs.io/en/stable/docs/Compile.html (https://dfhack.readthedocs.io/en/stable/docs/Compile.html) (I've gotten that from Lethosor).
I'm not interested in cloning "my" project (I wouldn't put any development stuff there unless forced to): I'm interested in contributing to DFHack, so its various (sub)repos is what's of interest. My stuff on github is there only because it's required for pull requesting to work (apart from my scripts, which are there only so they can be downloaded by others: I don't do any work on them there).
You're also skipping the essential steps of making branches and connecting to them, as well as how to connect to your fork on github (since you assume connection to your own project rather than DFHack).
git status lies. It can tell you things are up to date while you can clearly see the local file differs from the one on github. It also doesn't tell you which branch it thinks you're on, and it couldn't care less about whether it's in sync with your github fork branch (it probably doesn't even know about it).
Essential git commands not mentioned:
git remote -v and git remote add <get the path syntax right for your DFHack (sub)repo fork> (and git remote remove <got the path syntax wrong> to undo it without nuking).
git branch <your_update_branch>
git checkout <your_update_branch>

When I run into problems I copy the file I've changed to a safe place, nuke the failed local repo and reclone to wipe git's faulty internal state. I'm getting better at it, so it's probably down to less than once per pull request.

Also, don't use the web interface to update your fork's files, as it changes the <EOL> indication to one Travis rejects.

And now something completely different: Temperature measurements/predictions:
Bearskie's script provided the nudges I needed to move forward. I've got measurements of the temperature every day for a year for a single point in 117 world tiles in a vertical line (out of 257), and it's taken its time (somewhere between 12 and 18 hours, at a guess) before DF crashed, but that data is saved on a file. It seems to make sense when looked at in that the temperature increases over the summer and decreases during the winter (except at the equator, where the temperature seems to be constant). However, looking closer at it it doesn't quite make sense, as temperature changes essentially linearly and then makes a jump back to a temperature it had a few days earlier before changing linearly again, and these discontinuities seem to appear at the same date for multiple (all I've looked at) locations, and those dates don't hold any obvious significance, e.g. 76-78, 120-121, 166-167, 232-238, (the ranges are because of trouble reading the data points from the spreadsheet as I haven't pinpointed it in the measurements themselves).
The temperatures seem to increase more in the summer than they decrease in the winter, as measured from the starting point in spring, but possible the center point should be mid spring, rather than the start of spring.
Obviously, the measurement process may be flawed so the values measures aren't the correct ones.

@Bearskie: You may want this for your script to save on entering the unit id manually:
  local unit = df.unit.find (df.global.ui_advmode.player_id)
Title: Re: DFHack 0.44.10-r1
Post by: Atomic Chicken on May 24, 2018, 06:11:24 am
@Bearskie: You may want this for your script to save on entering the unit id manually:
  local unit = df.unit.find (df.global.ui_advmode.player_id)

player_id refers to the adventurer's nemesis id, which isn't necessarily identical to the unit id (although it often is in practice) so it'd probably be more appropriate to use "df.nemesis_record.find(df.global.ui_advmode.player_id).unit". Alternatively, you could use "df.global.world.units.active[0]", which generally corresponds to the player unit in adventure mode.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on May 24, 2018, 08:19:59 am
%XXX% is a placeholder for %program files (86)% or something along those lines.

I believe I did see an error message saying that something or other couldn't be found at the C: drive, and I think it pointed down the program file guff path to where VS would have been placed if it had been on the C: drive.
So your program files folder is on your C: drive but VS isn't in that? BenLubar made this change (https://github.com/DFHack/dfhack/commit/43be1c7a6a2aedcd8eed4a204bf98bae91b4481f) 10 days ago - does that help?
Quote
I'm using the the command line (git xxx <guess at parameters here>). "git help" provides a dozen commands, most of which I've never used, and most of the ones I need aren't listed. The "documentation" is horrible, resulting in a web page that only provides overall syntax, but not any parameters, nor any description of the commands. Web searches are needed to find commands, and sub repo juggling was found in a comment somewhere half way through a discussion of failed attempts.
As it currently stands, I can stumble by with git and a frequent "remove everything and download from scratch" approach. For instance, I won't create a new pull request in a (sub) repo before the previous one is done as I don't want to try to juggle several instances of it (and the complete DFHack surrounding it that's required for the sub repo stuff to be tested), as pull requests are frequently requested to be changed, so the local copy needs to be prepared for making changes to be pushed up.
You should be using branches instead of several copies of the repo, which can get rather large. And I think you have been using branches, which confuses me more. You should be able to use "git checkout" to switch between branches, and changes you've made and committed on a branch will only be visible when that branch is checked out, so you can do work on multiple branches/PRs in the same clone.

This is "git help" from Git 2.17:
Spoiler (click to show/hide)
I can't think of any I use regularly that aren't listed here. Maybe you're using an old Git version that doesn't list all of these? I would highly recommend upgrading to something newer if you are - core behavior doesn't change, but some output is in a nicer format by default.

"git help COMMAND" or "man git-COMMAND" or "git COMMAND --help" will all give you detailed help about individual commands. https://git-scm.com/docs/ is the same information, and I've pointed people at https://git-scm.com/book/en/v2 before (it's long but thorough).

  • git clone yourproject.git - downloads the project from github the first time (you theoretical only need to do this once)
<snip>
If you have any problems, backup the project to another folder and reclone it from the github.
For the record, my DFHack clone dates back to 2014, when I first started working on DFHack. So yes, you can get by with only cloning it once. (I do have a second clone for some administrative stuff, like syncing branches on GitHub without touching all of the files in my main clone and needing a rebuild, but I haven't had to re-clone that either.)

  • git add filename.file - adds a file to the list of files getting sent. (or git add . to add all the red untracked files)
  • git status - do this once more to make sure it all looks right
  • git commit -am "change description" - this makes a save point or something with a comment of what you just changed.
DO NOT DO THIS! The "-a" flag to git commit will commit EVERYTHING (except untracked files), so if you picked out individual changes to add with "git add", "git commit -a" will throw away all of that and commit everything (and lead to confusion because it doesn't match what "git status" showed).

Thanks jecowa.
That's partially covered here: https://dfhack.readthedocs.io/en/stable/docs/Compile.html (https://dfhack.readthedocs.io/en/stable/docs/Compile.html) (I've gotten that from Lethosor).
I'm not interested in cloning "my" project (I wouldn't put any development stuff there unless forced to): I'm interested in contributing to DFHack, so its various (sub)repos is what's of interest. My stuff on github is there only because it's required for pull requesting to work (apart from my scripts, which are there only so they can be downloaded by others: I don't do any work on them there).
Jecowa was talking about DFHack forks, which is also what you're talking about.
Quote
git status lies. It can tell you things are up to date while you can clearly see the local file differs from the one on github. It also doesn't tell you which branch it thinks you're on, and it couldn't care less about whether it's in sync with your github fork branch (it probably doesn't even know about it).
It doesn't lie, if you use "git fetch" or "git pull" to update your local copy. I use it constantly, and it does help avoid confusion.
"On branch X" is literally the first line of its output in my Git version. Again, if you're using an old version and don't see that, you should upgrade.
Quote
Essential git commands not mentioned:
git remote -v and git remote add <get the path syntax right for your DFHack (sub)repo fork> (and git remote remove <got the path syntax wrong> to undo it without nuking).
git branch <your_update_branch>
git checkout <your_update_branch>
You can change remote URLs with "git remote set-url": https://git-scm.com/docs/git-remote. No need to nuke anything.
Are you saying Jecowa's post is missing that, or DFHack's documentation? I still don't think we need to recreate Git tutorials in the DFHack documentation, but I'm okay with adding things specific to DFHack's process. We kind of assume a basic knowledge of Git, though.
Quote
When I run into problems I copy the file I've changed to a safe place, nuke the failed local repo and reclone to wipe git's faulty internal state. I'm getting better at it, so it's probably down to less than once per pull request.
I wouldn't describe it as faulty myself, but if you need help sorting something out, I'd be willing to work with you if you can provide "git status" output and a description of what you're trying to do.

Quote
Also, don't use the web interface to update your fork's files, as it changes the <EOL> indication to one Travis rejects.
It has never done this for me. It might be due to your editor using DOS-style newlines (\r\n), so change that if you can. Git locally changes newlines to \n by default on Windows, but maybe GitHub's UI does not, so copying a file in like that could be problematic.
By the way, I want to be clear that this is also documented in Contributing (https://dfhack.readthedocs.io/en/latest/Contributing.html) - it's not a surprise check that Travis throws in at the last minute or anything.
Title: Re: DFHack 0.44.10-r1
Post by: SlimeOfSteel on May 24, 2018, 09:14:30 am
Okay, one more thing. The Visual C++ 2015 Redistributable Update 3 is standalone, and doesn't depend on the C: drive, right?

I know I should probably have figured this all out by now, but there were other things in my life that needed my attention first. You can also blame my terrible memory for this as well.

Listen, I know you're probably sick of this whole thing, but I honestly have to thank you for being so patient.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on May 24, 2018, 09:55:17 am
I wouldn't know; I haven't tried it. It's fairly small, though. Is there a reason you can't install it on multiple computers if necessary?
Title: Re: DFHack 0.44.10-r1
Post by: Clément on May 24, 2018, 09:57:07 am
So your program files folder is on your C: drive but VS isn't in that? BenLubar made this change (https://github.com/DFHack/dfhack/commit/43be1c7a6a2aedcd8eed4a204bf98bae91b4481f) 10 days ago - does that help?

I have never built DFHack on Windows, so I am not sure it help: when I build Dwarf Therapist, I use %VS140COMNTOOLS%VsDevCmd.bat to setup the environment for cmake. It is not the same directory you are using in the linked patch, but it works with non-standard install paths (my MSVC2015 is not installed on the system disk).
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on May 24, 2018, 09:58:36 am
@Lethosor:
BenLubar's change *should* result in me not having to change install-debug for every clone. However, %ProgramFiles(x86)% is the variable that points to C: and has to do so. There is one structure on the C: drive where old program installs are and one on D: where new ones, including most of VS (it's installation placed versions older than 14 on C: anyway), are (I had to change the install location when bloatware filled the OS partition, as the PC vendor apparently doesn't care that this happens).

I don't have multiple clones as I nuke them when done, and yes, I'm using branches, but given how much I trust git not to screw up things I don't trust it to switch between branches and not destroy/corrupt data. It's fairly easy to get into a state I can't get out of (I know you can do HEAD surgery and whatnot, but I don't know how to do that).

git remote is one command that isn't listed by the help (and my git installation is less than a year old and made according to DFHack instructions, so it shouldn't be ancient). When I've tried git help <command> it hasn't produced anything useful (like e.g. listing parameters), and I think it didn't seem to recognize the command at all.

I do add and commit files individually (and have to do so to not include install-debug.bat when in the top/main structure).

I certainly don't want to download the old junk in my fork, as I want to work with the latest stuff, and apparently the fork cannot be updated without first downloading the data locally and then push it up (apart from nuking the fork and recreating it, of course). The fork's main branch only acts as an administrative placeholder to create github branches so pull request can be made (and those branch copies have to be updated by pushing the newly cloned/pulled stuff up).

Missing commands: I was referring to jecowa's list. As I said, "git remote remove" can be used to remove failures so so "git remote add" can be tried again, without nuking, and I assume your command has parameters for modifying the path of an existing element, thus allowing the usage of one command instead of two.
The mentioning of which of a bazillion different git structure organizations DFHack uses ought to be required even for those familiar with git (i.e. "git flow" as mention in your earlier post), and the usage of a main repo with multiple sub-repos (docked in the top structure under other names, at least in the case of df-structures->xml) ought to be documented as well, as I assume that isn't immediately apparent.

<EOL>: I've changed my text editor settings to satisfy Travis' demands, but I'm unsure if it had rejected things before that or if the change was made because I read it would demand it (and I haven't checked that the settings have been retained when it has updated itself). When I tried the web UI to cut out the administrative steps in updating a minor change Travis rejected the file, while it was accepted when pushed up (and I didn't touch it in between). I wouldn't exactly be surprised if the web UI behavior differed between browsers and OS's, though (Firefox on Windows, in my case). Also, I haven't changed any settings in VS (and don't know if you can modify line terminations there), but I don't remember what kind of file it was (i.e. script, XML, or code).

@SlimeOfSteel: When I installed VS partial older versions insisted on ending up on the C: drive, with 14.0 correctly landing on D:. However, I suspect it may be due to the %ProgramFiles(x86)% variable pointing at C:\..., so you may want to check that variable. Note that I'm mostly guessing, though. It that guess is correct, you'd probably have to make sure nothing dependent on it is installed on the C: drive, or keep switching it back and forth depending on what you do.
Title: Re: DFHack 0.44.10-r1
Post by: SlimeOfSteel on May 24, 2018, 10:47:05 am
I wouldn't know; I haven't tried it. It's fairly small, though. Is there a reason you can't install it on multiple computers if necessary?

I don't have the permissions to install VS on the computers.

@SlimeOfSteel: When I installed VS partial older versions insisted on ending up on the C: drive, with 14.0 correctly landing on D:. However, I suspect it may be due to the %ProgramFiles(x86)% variable pointing at C:\..., so you may want to check that variable. Note that I'm mostly guessing, though. It that guess is correct, you'd probably have to make sure nothing dependent on it is installed on the C: drive, or keep switching it back and forth depending on what you do.

Well, I guess I'll have to give it a shot once I can get to my home computer and maybe stop procrastinating so much.
Title: Re: DFHack 0.44.10-r1
Post by: Clément on May 24, 2018, 10:59:54 am
I have no idea what are the differences between the two scripts but replacing call "%ProgramFiles(x86)%\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64 with call "%VS140COMNTOOLS%VsDevCmd.bat" worked for me.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on May 24, 2018, 03:31:56 pm
So your program files folder is on your C: drive but VS isn't in that? BenLubar made this change (https://github.com/DFHack/dfhack/commit/43be1c7a6a2aedcd8eed4a204bf98bae91b4481f) 10 days ago - does that help?

I have never built DFHack on Windows, so I am not sure it help: when I build Dwarf Therapist, I use %VS140COMNTOOLS%VsDevCmd.bat to setup the environment for cmake. It is not the same directory you are using in the linked patch, but it works with non-standard install paths (my MSVC2015 is not installed on the system disk).
Interestingly enough, the win32 build/install/package scripts all use
Code: [Select]
call "%VS140COMNTOOLS%vsvars32.bat"
I don't remember if there was an issue doing that with the win64 scripts, and I'm not sure why it wasn't done for win32 package scripts. Ben or others might know.

@Lethosor:
BenLubar's change *should* result in me not having to change install-debug for every clone. However, %ProgramFiles(x86)% is the variable that points to C: and has to do so. There is one structure on the C: drive where old program installs are and one on D: where new ones, including most of VS (it's installation placed versions older than 14 on C: anyway), are (I had to change the install location when bloatware filled the OS partition, as the PC vendor apparently doesn't care that this happens).
Ok, yeah, that sounds like something the existing scripts can't support without changes. Maybe there's a way we can make the VS tools path user-configurable (and ignored by Git), but I'm not familiar enough with batch scripts to do that.
Quote
I don't have multiple clones as I nuke them when done, and yes, I'm using branches, but given how much I trust git not to screw up things I don't trust it to switch between branches and not destroy/corrupt data. It's fairly easy to get into a state I can't get out of (I know you can do HEAD surgery and whatnot, but I don't know how to do that).
It's really hard to destroy or corrupt data. Sometimes you'll end up with merge conflicts that are hard to resolve when pulling or merging, but Git will keep you from pulling/merging things that will overwrite your changes, and some form of "git reset" will get you out of a merge if you decide to give up on it.
Quote
git remote is one command that isn't listed by the help (and my git installation is less than a year old and made according to DFHack instructions, so it shouldn't be ancient). When I've tried git help <command> it hasn't produced anything useful (like e.g. listing parameters), and I think it didn't seem to recognize the command at all.
Fair, but "git help remote" gives me a 233-line man page that definitely lists parameters and is basically the same as https://git-scm.com/docs/git-remote. The syntax for commands is in the "Synopsis" section.

Out of curiosity, what does "made according to DFHack instructions" mean? Do we give instructions on building Git or something? Or did you download binaries from some recommended source? Check on your actual version with "git --version" if it's the latter, since some binaries can be extremely out of date.
Quote
I do add and commit files individually (and have to do so to not include install-debug.bat when in the top/main structure).
Yeah, that complaint was directed at Jecowa. That's good.
Quote
I certainly don't want to download the old junk in my fork, as I want to work with the latest stuff, and apparently the fork cannot be updated without first downloading the data locally and then push it up (apart from nuking the fork and recreating it, of course). The fork's main branch only acts as an administrative placeholder to create github branches so pull request can be made (and those branch copies have to be updated by pushing the newly cloned/pulled stuff up).
This is true, but you can fetch from the upstream remote ("git fetch origin" if "origin" is your name for DFHack's copy), then create a new branch based on origin/some-branch (e.g. origin/master or origin/develop) if you use "origin" ("git checkout origin/some-branch", then "git checkout -b my-new-branch"), and that will give you a new branch "my-new-branch" that's based on DFHack's some-branch without having to update your own some-branch.

I guess this is a tip that could be documented.
Quote
Missing commands: I was referring to jecowa's list. As I said, "git remote remove" can be used to remove failures so so "git remote add" can be tried again, without nuking, and I assume your command has parameters for modifying the path of an existing element, thus allowing the usage of one command instead of two.
Yeah, it does. "git remote set-url [--push] <name> <newurl>" from the man page (https://git-scm.com/docs/git-remote), so e.g. "git remote set-url bob https://github.com/bob/dfhack"
Quote
The mentioning of which of a bazillion different git structure organizations DFHack uses ought to be required even for those familiar with git (i.e. "git flow" as mention in your earlier post), and the usage of a main repo with multiple sub-repos (docked in the top structure under other names, at least in the case of df-structures->xml) ought to be documented as well, as I assume that isn't immediately apparent.
Honestly, "we do all work on the develop branch" has been enough people familiar with Git for most development. The "git flow" page is interesting for theory and all, but in most cases, working off the develop branch is all that matters for contributors.

Quote
<EOL>: I've changed my text editor settings to satisfy Travis' demands, but I'm unsure if it had rejected things before that or if the change was made because I read it would demand it (and I haven't checked that the settings have been retained when it has updated itself). When I tried the web UI to cut out the administrative steps in updating a minor change Travis rejected the file, while it was accepted when pushed up (and I didn't touch it in between). I wouldn't exactly be surprised if the web UI behavior differed between browsers and OS's, though (Firefox on Windows, in my case). Also, I haven't changed any settings in VS (and don't know if you can modify line terminations there), but I don't remember what kind of file it was (i.e. script, XML, or code).
I suspect Firefox on Windows (or maybe anything on Windows) includes the carriage returns when pasting, which causes the issue. Are you sure your editor is saving with UNIX-style newlines?
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on May 24, 2018, 04:47:10 pm
According to the instructions: Same as before: https://dfhack.readthedocs.io/en/stable/docs/Compile.html (https://dfhack.readthedocs.io/en/stable/docs/Compile.html), i.e. via Chocolatey.

"origin" is what DFHack (on github) is called when cloned. So far I've mostly nuked the local clone and recloned it to get the latest, but I've had some success with fetching it, creating a branch locally (same name as in my github repo) from it, check it out, and push that up to my github repo (with the occasional accidental attempt to push it up to origin, which (fortunately) doesn't work). I haven't used any -b switch, though.

Those who do not know git and try to figure out anything about the organization by reading the git documentation will just have to guess at which workflow description sort of matches what's used, and using the insider description that you're just working off develop doesn't help one bit (and it is correct only for the top repo anyway) when you don't know what a "develop" is or what git hierarchy item it might be an instance of.

<EOL>: Given that browser file uploading involves drag&drop of the file, not its contents, I'm fairly sure it's not a cut-and-paste issue. Checking Notepad++ it claims to use "Unix (LF)" still, but as I said, it might have been code, in which case VS is the "editor".
Title: Re: DFHack 0.44.10-r1
Post by: Roses on May 24, 2018, 06:21:43 pm
As a contribution to the git discussion. Some of my favorite commands are git rebase and git stash. They are great for moving across branches and forks.

I highly suggest those interested in using git to take one of the multitude of online tutorials. Most of them go through step by step processes involving all/almost all of the commands you would ever want/need. It can be a very steep learning curve, but once you becomes more proficient you can easily keep dozens of versions of the same code on your system.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on May 24, 2018, 08:01:12 pm
According to the instructions: Same as before: https://dfhack.readthedocs.io/en/stable/docs/Compile.html (https://dfhack.readthedocs.io/en/stable/docs/Compile.html), i.e. via Chocolatey.

"origin" is what DFHack (on github) is called when cloned. So far I've mostly nuked the local clone and recloned it to get the latest, but I've had some success with fetching it, creating a branch locally (same name as in my github repo) from it, check it out, and push that up to my github repo (with the occasional accidental attempt to push it up to origin, which (fortunately) doesn't work). I haven't used any -b switch, though.
Yeah, "origin" is the default name for the remote for the URL you passed to "git clone". Some people clone their own fork and make a new remote called "upstream" or something that points to DFHack's. Others (like me and you) clone DFHack's and make a new remote for their own fork. Either way works.
Quote
Those who do not know git and try to figure out anything about the organization by reading the git documentation will just have to guess at which workflow description sort of matches what's used, and using the insider description that you're just working off develop doesn't help one bit (and it is correct only for the top repo anyway) when you don't know what a "develop" is or what git hierarchy item it might be an instance of.
It's not an "insider description" - it's mentioned on https://dfhack.readthedocs.io/en/latest/Contributing.html, and it says "develop branch" in both cases.
Looking at recently closed PRs (https://github.com/DFHack/dfhack/pulls?q=is%3Apr+is%3Aclosed), I only see one made against the wrong branch, although I think there was a second one that I override somehow. Several PRs (correctly made) came from first-time PR authors too.

Now, I don't mean to alienate anyone with a lack of git knowledge. Adding a more detailed page on DFHack's Git/GitHub process has been on my list for a while, although a low priority, but it has moved up thanks to discussions here.

At the same time, I'm not sure how to improve what we currently have. The process involving being on the develop branch is a bit different from some repos, but I think it's documented so that anyone who is somewhat familiar with Git, including how to submit pull requests and use branches, can understand the information provided. The activity I've seen on GitHub agrees with that. If you, or anyone else, has ideas for ways that we can make it better while the Git-documentation process is happening, feel free to suggest them.

Quote
<EOL>: Given that browser file uploading involves drag&drop of the file, not its contents, I'm fairly sure it's not a cut-and-paste issue. Checking Notepad++ it claims to use "Unix (LF)" still, but as I said, it might have been code, in which case VS is the "editor".
Oh, I didn't know you were uploading the file directly (that's a newer feature than the online editor, which I'm more familiar with and does allow editing file contents).
Title: Re: DFHack 0.44.10-r1
Post by: jecowa on May 24, 2018, 11:08:01 pm
GCC 7.3.0 64-bit build works on Mac OS X 10.10 Yosemite as well.

On Mac OS X 10.5.8, the GCC 7.3.0 builds did not run in either 32-bit or 64-bit Dwarf Fortress. The same was true with both of the GCC 4.8.5 builds. The thing the error logs had in common in all 4 versions was:
Code: [Select]
Trace/BPT trap          DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@"
error logs for the versions:
Test status of different Mac versions:
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on May 26, 2018, 03:56:21 am
My attempt to describe how DFHack is organized on github, as well as an attempt to describe how to work with it (Warning! don't try to use the workflow description, as it probably is not correct).
Spoiler (click to show/hide)
Title: Re: DFHack 0.44.10-r1
Post by: Manzeenan on May 26, 2018, 04:53:23 am
So... is there a hack that allows one to engrave built floors or walls? Or to fix engravings being on only one side of a wall?
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on May 26, 2018, 05:19:53 am
So... is there a hack that allows one to engrave built floors or walls? Or to fix engravings being on only one side of a wall?

Wall and floor buildings do not have the fields required for engravings, and since those structures are defined by DF, DFHack can't add them.

Looking at the data structure for engravings, it actually looks like it would be possible to have engravings in multiple directions concurrently, as it's a flag array rather than a field. The motif would be the same in all directions, though, and it would probably be tricky to persuade dorfs to actually engrave the same item multiple times. Just hacking the tile to set multiple bits should be fairly easy, although it's anybody's guess how DF would process it (probably just by looking if the bit of current interest is set, in which case it ought to works well, although an engraved pillar in a room might inflate the rooms value in that case).
Title: Re: DFHack 0.44.10-r1
Post by: Rose on May 26, 2018, 05:25:40 am
Actually, engravings, once made, can be moved literally anywhere.

When I was investigating the egnraving definitions, I was able to move engravings onto grass, where they worked as normal.
Title: Re: DFHack 0.44.10-r1
Post by: Pvt. Pirate on May 26, 2018, 06:02:13 am
regarding the size of such a pillar, it's absolutely sane to give it such value: it's as big or even bigger than a dragon!
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on May 26, 2018, 07:24:35 am
Actually, engravings, once made, can be moved literally anywhere.

When I was investigating the egnraving definitions, I was able to move engravings onto grass, where they worked as normal.

Hm, yes, it looks like you're correct. Engravings appear to just be tied to a position rather than to what's in that position, in which case building definitions are irrelevant for the placement. Whether DF will display engravings moved everywhere or only in certain locations (such as natural surfaces) is a different issue. How would DF display an engraving claiming to face in one (or many) directions in the air or in a building (such as a trade depot), and single tile constructions (such as build walls/floors)? It's not impossible an engraving in the same location as a built floor would be "displayed" under the floor, for instance.
Title: Re: DFHack 0.44.10-r1
Post by: Rose on May 26, 2018, 07:50:28 am
DF doesn't show the facing of engravings at all. That only comes up checking the room value.

they also will show up literally anywhere, so engravings on constructed walls will show fine.
Title: Re: DFHack 0.44.10-r1
Post by: Putnam on May 26, 2018, 02:46:21 pm
regarding the size of such a pillar, it's absolutely sane to give it such value: it's as big or even bigger than a dragon!

nah, a pillar is 12 meters3
Title: Re: DFHack 0.44.10-r1
Post by: Rose on May 26, 2018, 04:02:28 pm
akthually… it's 11.2 m3
Title: Re: DFHack 0.44.10-r1
Post by: Pvt. Pirate on May 27, 2018, 06:32:52 am
akthually… it's 11.2 m3
but then what size is one tile ? i found out.
Title: Re: DFHack 0.44.10-r1
Post by: Rose on May 27, 2018, 07:03:42 am
Physics calculations assume a tile size of 2x2x2.8m tiles, with a realtime FPS of 10.
Title: Re: DFHack 0.44.10-r1
Post by: FantasticDorf on May 27, 2018, 12:45:49 pm
So... you could transfer a entire engraving into a location like a custom piece of furniture (along the lines of a display case) for your art nouveau gallery? Or have it bound to the XYZ of a destined object?

I've heard of knowledge stone boulders used for a product to cheat experience gain for masterwork mods, art_boulders would be a first.
Title: Re: DFHack 0.44.10-r1
Post by: Rose on May 27, 2018, 09:37:57 pm
Difference is that the engraving would be hidden by any item or building its following.
Title: Re: DFHack 0.44.10-r1
Post by: Pvt. Pirate on May 28, 2018, 03:02:30 am
Physics calculations assume a tile size of 2x2x2.8m tiles, with a realtime FPS of 10.
so you mean 2x2x2.8m and 0,20m for the floor?
Title: Re: DFHack 0.44.10-r1
Post by: Rose on May 28, 2018, 08:49:57 am
No, including the floor.

I investigated how the physics work, and those were the actual measurements used.
Title: Re: DFHack 0.44.10-r1
Post by: Pvt. Pirate on May 28, 2018, 09:33:54 am
No, including the floor.

I investigated how the physics work, and those were the actual measurements used.
time to update the wiki then :)
Title: Re: DFHack 0.44.10-r1
Post by: Rose on May 28, 2018, 09:41:06 am
No, including the floor.

I investigated how the physics work, and those were the actual measurements used.
time to update the wiki then :)

Done.
Title: Re: DFHack 0.44.10-r1
Post by: MuthSera on May 28, 2018, 07:52:32 pm
Edit: Nevermind.
Title: Re: DFHack 0.44.10-r1
Post by: Max™ on May 31, 2018, 11:50:28 pm
So... is there a hack that allows one to engrave built floors or walls? Or to fix engravings being on only one side of a wall?

I removed the constructed wall check from the advfort engraving job and it works fine so you should totally be able to slap a new job into the queue for a dorf and have them pop out an engraved whatever.
Title: Re: DFHack 0.44.10-r1
Post by: Rumrusher on June 02, 2018, 10:27:46 am
so currently fiddling with the army raid stuff still no good idea on what's preventing me from getting units back from sieges with out the game crashing. the only work around I can see is either using a fort to start then swap between that or gm-editor find the missing link that makes a fort played on a dfhack made site vs a fort played on a natural made one.
the only minor progress made in the study was discovering a way to make dfhack made sites pop up in the reclaim/retire mode, which I guess could experiment in figuring out how to toggle those on for other sites so one could go around razing a site to later claim it with their own units.
Title: Re: DFHack 0.44.10-r1
Post by: snjwffl on June 03, 2018, 12:29:43 pm
I have a question about the "blueprint" command syntax.  The first three arguments ("<x> <y> <z>") specify the size of the designations to copy, but how do you specify where to copy?  I've tried having my cursor (in both "d" and "k" viewing modes) at the top left, and at the center, but when I use "digfort" it just designates gibberish.
Title: Re: DFHack 0.44.10-r1
Post by: strainer on June 05, 2018, 03:28:19 pm
sorry, dont about that command snjwffl

@PatrickLundell (from other topic)
Quote
still not completely certain every dead unit has the flags2.killed flag set
I tried it and all the dead/missing list, even bridge-squashed units, and starved ones have it so it does look like it could be the real "dead" flag. "deactivated" could be a name for 'dead' if its decided to fix it.
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on June 05, 2018, 03:35:25 pm
Thanks for checking things up, strainer.

Here's the issue on github: https://github.com/DFHack/df-structures/issues/247#issuecomment-394754758 (https://github.com/DFHack/df-structures/issues/247#issuecomment-394754758).

I have a lack of ghosts, so I have trouble checking how their flags are set.
I've proposed the name "inactive" as a new name for the current "dead" flag.
Title: Re: DFHack 0.44.10-r1
Post by: Bumber on June 05, 2018, 04:16:49 pm
What about raised corpses? Are they considered an entirely different entity?
Title: Re: DFHack 0.44.10-r1
Post by: strainer on June 05, 2018, 08:42:55 pm
Undead dont seem to have a 'current_soul', Ive avoided reading them in Cavern Keeper because trying access missing information crashes C++, and I gave up trying to track down exactly whats missing. Should have another crack at it sometime, a debugger would help ay.
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on June 06, 2018, 04:02:03 am
I believe a reanimated corpse is a different unit from the creature the corpse was generated from, and it may be that ghosts are also different units (all of them would need to refer back to the same hist fig, if any). Given that a corpse can be reanimated, have the arms and head lopped off, and then have those being reanimated concurrently there's definitely more than one unit involved (and slaughtered animals can yield hair and skin that reanimate and gets killed to reanimate head and arm parts for each if it's an animal with grasping fore limbs).

@strainer: Yes, C(++) considers checks to be wasteful stuff that should be added by the programmer only when absolutely necessary, unlike high level languages where checks can be removed as compiler optimizations. Checking whether current_soul is null and don't access anything it would have pointed to if it is ought to work around that problem. However, there are other things that may have null pointers, so care needs to be taken. The things I'm thinking of are probably in the hist fig structure tree though.
Title: Re: DFHack 0.44.10-r1
Post by: Atomic Chicken on June 06, 2018, 06:20:17 am
Ghost creation doesn't involve the creation of new units; ghosts are just the old unit with unit.flags3.ghostly set, alongside relevant stuff in unit.ghost_info and a flag in the historical figure data. They maintain their current_soul info, and both flags1.dead and flags2.killed are set to false.

Reanimated undead are indeed entirely new units lacking soul data, with relevant stuff set in unit.enemy.undead (including a string that determines their display name, allowing for stuff like "Urist's left arm"). They're generated with their own historical figure data, but refer back to the original unit's historical figure via unit.hist_figure_id2. Both flags1.dead and flags2.killed are false.
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on June 06, 2018, 06:48:26 am
Thanks for those explanations, Atomic Chicken.
That would mean normal ghosts go through the process of:
- Unit dies. both "dead" and "killed" are set, and a death cause incident is generated (the incident presumably is generated when the incident happened, which may be relevant for a drawn out death).
- Unit returns as a ghost, and "dead" and "killed" are reset.
- Ghost expires/gets slabbed/buried, and "dead" and "killed" are set again?
Title: Re: DFHack 0.44.10-r1
Post by: Rumrusher on June 08, 2018, 10:34:56 am
Thanks for those explanations, Atomic Chicken.
That would mean normal ghosts go through the process of:
- Unit dies. both "dead" and "killed" are set, and a death cause incident is generated (the incident presumably is generated when the incident happened, which may be relevant for a drawn out death).
- Unit returns as a ghost, and "dead" and "killed" are reset.
- Ghost expires/gets slabbed/buried, and "dead" and "killed" are set again?
ghosts are the lingering dead units that stay on the map that have a ghost timer, until they get put to rest or the map unloads them, which I guess is why adventure mode doesn't seem to make ghosts unless a player hangs out in a spot long enough to cause one to rise(not to say ghosts don't exist in adventure mode just that would be amazing to see someone create a ghost).
but yeah they pretty much act like mummies in that they are resurrected vs the other undead which are reanimated

oh and Ghosts can get killed again through physical means if you somehow bring back their body via transformation regeneration then uhh Fire arrows or hit one with a minecart the ghost could re-die from their wounds. but I guess that could just reset the ghost timer for that dead again unit.
Title: Re: DFHack 0.44.10-r1
Post by: scourge728 on June 08, 2018, 12:26:22 pm
Are dwarves in fell moods still able to use ghosts?
Title: Re: DFHack 0.44.10-r1
Post by: Bumber on June 08, 2018, 08:17:56 pm
What about husks? Do they keep their souls?

Are dwarves in fell moods still able to use ghosts?
Still open on the bug tracker. (http://www.bay12games.com/dwarves/mantisbt/view.php?id=4681)
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on June 08, 2018, 10:03:52 pm
It was last updated in 2011, though, so it's possible that it was fixed unintentionally at some point since then. If anyone can reproduce it in 0.44 or so, that would be helpful.
Title: Re: DFHack 0.44.10-r1
Post by: Atomic Chicken on June 09, 2018, 05:28:31 am
---
- Ghost expires/gets slabbed/buried, and "dead" and "killed" are set again?

This is correct.

What about husks? Do they keep their souls?

I haven't looked into this, but I think that the changes observed in husks were just regular old syndrome effects, so the soul data is probably left intact.

It was last updated in 2011, though, so it's possible that it was fixed unintentionally at some point since then. If anyone can reproduce it in 0.44 or so, that would be helpful.

I tested this by inducing a fell mood using the "strangemood" plugin and teleporting a ghost into the same room as the target unit. The ghost was subsequently murdered, so it appears that this particular bug hasn't been fixed yet. Note that no corpse is generated since ghosts are produced with all body parts missing, so the mood material requirement remains unfulfilled.
Title: Re: DFHack 0.44.10-r1
Post by: scourge728 on June 09, 2018, 12:39:05 pm
So how do I actually USE the remove-stress script, I put it in using the all argument and I get an error, do I actually have to remove-stress from EVERY dwarf individually?
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on June 09, 2018, 03:04:54 pm
So how do I actually USE the remove-stress script, I put it in using the all argument and I get an error, do I actually have to remove-stress from EVERY dwarf individually?
Can you copy and paste the exact error here? Right clicking the title bar should give you an option to copy if selecting doesn't work on Windows.

Also, what argument exactly did you use?
Title: Re: DFHack 0.44.10-r1
Post by: scourge728 on June 09, 2018, 03:15:37 pm
remove-stress all

Spoiler (click to show/hide)
Title: Re: DFHack 0.44.10-r1
Post by: Atomic Chicken on June 09, 2018, 03:28:25 pm
remove-stress all

Arguments in the majority of DFHack scripts must be preceded by a hyphen. So in this case, what you need to enter is as follows:
Code: [Select]
remove-stress -all
Title: Re: DFHack 0.44.10-r1
Post by: scourge728 on June 09, 2018, 03:32:11 pm
and now I have
Spoiler (click to show/hide)
Title: Re: DFHack 0.44.10-r1
Post by: Atomic Chicken on June 09, 2018, 03:54:25 pm
and now I have
Spoiler (click to show/hide)

Ah, the problem is that you've got soulless units on the map. The script was updated a few weeks ago to deal with this issue, so the version you're using is likely to be outdated. To solve the problem, replace the contents of your copy with the version found here (https://github.com/DFHack/scripts/blob/master/remove-stress.lua).
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on June 09, 2018, 06:49:25 pm
Yeah, that's the issue that I fixed in that script recently. To be fair, that fix wasn't in 0.44.10-r1, so it's not that it's an outdated version of that script specifically, at least if you only consider official releases of DFHack. I'm not sure on a timeline for r2 yet, so upgrading the script yourself is your best bet.
Title: Re: DFHack 0.44.10-r1 - Planning Mode
Post by: Oafsalot on June 10, 2018, 01:47:20 pm
I've come across a bug with Planning Mode.

I don't know if this has been mentioned elsewhere.

I started a new fort, in the latest version, and used planning mode extensively.

I abandoned and reclaimed the fort. The dwarves were all too depressed to work.

Upon trying to use Planning Mode I now get the error and the job is removed:

Kol Lorbanunib, Miner cancels Construct Building: Needs item.
The dwarves were unable to complete the unknown material Table.

It should be noted I have the items that match the job. And even if I just try to place a basic table, with no modifiers, it still won't place it.

I've read that this could be to do with workflow. However I set it to disabled and reloaded the fort to no avail.

Does anyone know why this happens. Perhaps a way to reinitialise Planning Mode to fix it.

Thanks

  Oafsalot


Title: Re: DFHack 0.44.10-r1
Post by: lethosor on June 10, 2018, 02:26:51 pm
Have you restarted DF? If that doesn't fix it, please upload the save.
Title: Re: DFHack 0.44.10-r1
Post by: Oafsalot on June 10, 2018, 04:56:07 pm
I restarted twice, no go. However I thought I'd just try it again and it worked.

If it repeats I'll be sure to get a save.

Thanks

  oafsalot
Title: Re: DFHack 0.44.10-r1
Post by: Oafsalot on June 11, 2018, 12:53:39 pm
I tracked down the problem to 'autounsuspend'. Basically as soon as you enable it all the ghosted furniture will try to complete, be unable to do so and then remove itself.

Autounsuspend treats it as if it's a suspended job.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on June 11, 2018, 01:07:30 pm
Yeah, they basically are suspended jobs. Were you using autounsuspend before you reclaimed?

Maybe there's a way for autounsuspend to detect buildingplan jobs, but I'm not sure. Checking for "unknown material" might do it.
Title: Re: DFHack 0.44.10-r1
Post by: Markrath on June 11, 2018, 06:21:45 pm
Not sure if this is the right place to ask, but I remember seeing or hearing, a few years ago, that there is a way to find the position of a specific creature in the game using dfhack. Is that still (or was it ever) possible? I'm having trouble finding a beast in the place where it was last seen.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on June 11, 2018, 06:31:35 pm
It's almost certainly possible - DFHack can access pretty much anything that DF stores in memory, which includes unit positions. And if it ever was possible, it wouldn't have been removed. The exact strategy depends on what you're looking for. Are you looking for a unit on the fortress mode map (i.e. can you select it with u or v)? Or is it something on the world map? Or the local adventure mode map?
Title: Re: DFHack 0.44.10-r1
Post by: Markrath on June 12, 2018, 03:27:10 am
It's almost certainly possible - DFHack can access pretty much anything that DF stores in memory, which includes unit positions. And if it ever was possible, it wouldn't have been removed. The exact strategy depends on what you're looking for. Are you looking for a unit on the fortress mode map (i.e. can you select it with u or v)? Or is it something on the world map? Or the local adventure mode map?
There was this Roc who is most certainly alive (it doesn't show him dying in legends mode), and apparently he's in a fortress called Treatymyths, but I've explored the whole place and I can't quite find anything. So I guess he could be anywhere on the world map
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on June 12, 2018, 04:08:37 am
If your adventurer is in the fortress and the roc is hiding somewhere in it, the roc should be in df.global.world.units.active and once located the pos(ition) field should give the coordinates. However, I don't know how to locate off site creatures.
Title: Re: DFHack 0.44.10-r1
Post by: Markrath on June 12, 2018, 06:46:24 am
df.global.world.units.active
Where can I find that?
Title: Re: DFHack 0.44.10-r1
Post by: Oafsalot on June 12, 2018, 07:20:08 am
Yeah, they basically are suspended jobs. Were you using autounsuspend before you reclaimed?

Maybe there's a way for autounsuspend to detect buildingplan jobs, but I'm not sure. Checking for "unknown material" might do it.

I thought I was, but I spun up a new fortress and I can't have been. I must have had it off while I was building the initial fortress.
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on June 12, 2018, 08:54:47 am
df.global.world.units.active
Where can I find that?
That's the DFHack location of one of the unit vectors inside of DF which can be accessed with scripts (which you'd probably have to write yourself to get exactly what you want) or the DFHack gui/gm-editor.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on June 12, 2018, 09:33:40 am
Yeah, they basically are suspended jobs. Were you using autounsuspend before you reclaimed?

Maybe there's a way for autounsuspend to detect buildingplan jobs, but I'm not sure. Checking for "unknown material" might do it.

I thought I was, but I spun up a new fortress and I can't have been. I must have had it off while I was building the initial fortress.
The "resume" plugin draws over planned buildings (which are suspended) with a green X, and other suspended buildings with a yellow X. I've found what it uses to do that, so I think I can get it to work with autounsuspend too.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on June 12, 2018, 12:03:59 pm
A fixed autounsuspend script: https://github.com/DFHack/scripts/blob/master/autounsuspend.rb
Title: Re: DFHack 0.44.10-r1
Post by: DizzyCrash on June 12, 2018, 12:52:17 pm
I really really really need help.. I didnt embark with enough food but i have no idea how to spawn in more...  createitem CHEASE:COW 200 isnt working...
DF Hack is my only chance at fixing this.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on June 12, 2018, 01:11:14 pm
I really really really need help.. I didnt embark with enough food but i have no idea how to spawn in more...  createitem CHEASE:COW 200 isnt working...
DF Hack is my only chance at fixing this.
Ok, for one thing, you spelled "cheese" wrong. And for another thing, you can't just guess syntax for commands and expect it to work. createitem takes an item type, then a space, then a material (then optionally a number). You gave it just one argument before the number, and it's unclear if it's supposed to be the item type or material, so it won't work like that.

Here is a page on the DF wiki about createitem: http://dwarffortresswiki.org/Utility:DFHack/createitem
I searched for "cheese" and found "CHEESE" listed under Materials -> Body parts. The example syntax given is:
Code: [Select]
item CREATURE_MAT:creature:material
where "material" should be replaced with "CHEESE", "creature" with the creature you want (e.g. "COW"), and "item" with the item type.

That same page links to http://dwarffortresswiki.org/index.php/DF2014:Item_token for a list of valid item types. I searched for "cheese" and found "CHEESE" listed, so replace "item" with "CHEESE".

I'll test it in a moment, but I think that should do it. You can add a number at the end if you want, of course.

Edit: yeah, that works.

You could also try gui/create-item if you prefer GUIs. See dfhack.readthedocs.io for help - it takes an argument that lets it create multiple items at once.
Title: Re: DFHack 0.44.10-r1
Post by: DizzyCrash on June 12, 2018, 01:25:07 pm
I really really really need help.. I didnt embark with enough food but i have no idea how to spawn in more...  createitem CHEASE:COW 200 isnt working...
DF Hack is my only chance at fixing this.
Ok, for one thing, you spelled "cheese" wrong. And for another thing, you can't just guess syntax for commands and expect it to work. createitem takes an item type, then a space, then a material (then optionally a number). You gave it just one argument before the number, and it's unclear if it's supposed to be the item type or material, so it won't work like that.

Here is a page on the DF wiki about createitem: http://dwarffortresswiki.org/Utility:DFHack/createitem
I searched for "cheese" and found "CHEESE" listed under Materials -> Body parts. The example syntax given is:
Code: [Select]
item CREATURE_MAT:creature:material
where "material" should be replaced with "CHEESE", "creature" with the creature you want (e.g. "COW"), and "item" with the item type.

That same page links to http://dwarffortresswiki.org/index.php/DF2014:Item_token for a list of valid item types. I searched for "cheese" and found "CHEESE" listed, so replace "item" with "CHEESE".

I'll test it in a moment, but I think that should do it. You can add a number at the end if you want, of course.

Edit: yeah, that works.

You could also try gui/create-item if you prefer GUIs. See dfhack.readthedocs.io for help - it takes an argument that lets it create multiple items at once.

I get overwhelmed easily.. Could you show me what the full command would look like?
Title: Re: DFHack 0.44.10-r1
Post by: DizzyCrash on June 12, 2018, 01:28:03 pm
createitem CREATURE_MAT:COW:CHEESE didnt work.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on June 12, 2018, 02:24:59 pm
Yeah, that was unclear, sorry. You need the item type and material. You're still only giving it one. ("item" above is an argument to "createitem", not equivalent to "createitem", so you need "createitem" followed by the item type, then the material.)
Try
Code: [Select]
createitem CHEESE CREATURE_MAT:COW:CHEESE
or
Code: [Select]
createitem CHEESE CREATURE_MAT:COW:CHEESE 200
etc.

Did you try gui/create-item? I found that it worked pretty well here.
Title: Re: DFHack 0.44.10-r1
Post by: DizzyCrash on June 12, 2018, 02:54:01 pm
When i type in gui/create-item nothing happens... also I used createitem CHEESE CREATURE_MAT:COW:CHEESE 200 that you just posted and nothing happened.. it just said no unit selected
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on June 12, 2018, 03:24:17 pm
When i type in gui/create-item nothing happens... also I used createitem CHEESE CREATURE_MAT:COW:CHEESE 200 that you just posted and nothing happened.. it just said no unit selected
gui/create-item opens a screen in the DF window. Did you check there?

Also, what version of DFHack are you using? If createitem says "no unit selected", you need to select a unit for it to work (in game, with u, v, k, or pretty much anything else that can select a unit), but that shouldn't be necessary in recent DFHack versions. Running "help" should give you the DFHack version near the end.
Title: Re: DFHack 0.44.10-r1
Post by: DizzyCrash on June 12, 2018, 03:33:24 pm
got it to work.
Title: Re: DFHack 0.44.10-r1
Post by: thefriendlyhacker on June 12, 2018, 03:45:35 pm
When i type in gui/create-item nothing happens... also I used createitem CHEESE CREATURE_MAT:COW:CHEESE 200 that you just posted and nothing happened.. it just said no unit selected
You need to select a unit using (k), (v) or the (u)nits screen.  Press v, move the cursor over one of your units, and run createitem with the same arguments again.

EDIT: derp, that's what I get for not previewing and checking for more posts before replying.  Ignore this.
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on June 12, 2018, 04:16:42 pm
Except you don't need to do that for createitem since at least a year or two ago, which is why I asked what the DFHack version was. If it's not really old, there's a bug that needs to be fixed. So what version are you using?

I'd also like to know if gui/create-item worked or not.
Title: Re: DFHack 0.44.10-r1
Post by: DizzyCrash on June 13, 2018, 05:15:35 am
Is it possible to delete objects with DF hack?
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on June 13, 2018, 07:28:53 am
Is it possible to delete objects with DF hack?
Yes. Autodump can do that, for instance (man autodump to get a description of the command).
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on June 13, 2018, 07:58:12 am
"help autodump" is the same and might be easier to remember.

We also have documentation at https://dfhack.readthedocs.io/en/stable/. Autodump can be found at https://dfhack.readthedocs.io/en/stable/docs/Plugins.html#autodump (or by searching).
Title: Re: DFHack 0.44.10-r1
Post by: DizzyCrash on June 13, 2018, 10:41:17 am
Can somebody post the whole command string for both autodump destroy and clean map
Title: Re: DFHack 0.44.10-r1
Post by: DizzyCrash on June 13, 2018, 10:50:14 am
I dont know how this is suppose to work
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on June 13, 2018, 12:28:41 pm
Can somebody post the whole command string for both autodump destroy and clean map
It's literally what you posted. "clean map" and "autodump destroy" work fine for me. For autodump, you need to mark items for dumping in-game, like the link I posted says: https://dfhack.readthedocs.io/en/stable/docs/Plugins.html#autodump

Is that still unclear? If so, what exactly is the problem? "I don't know" or "it doesn't work" aren't enough for us to help you much more than that. At least console output or a screenshot of DF+DFHack would help if you can't describe what's happening.
Title: Re: DFHack 0.44.10-r1
Post by: DizzyCrash on June 13, 2018, 03:18:20 pm
Another question.. Can you use DF hack to delete dwarves?

Alright it said 34 items marked for destroy but i dont know how to finish it, the items are still there.
Title: Re: DFHack 0.44.10-r1
Post by: DizzyCrash on June 13, 2018, 03:19:24 pm
Oh wait, they are gone now
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on June 13, 2018, 03:36:59 pm
You can use "exterminate" to kill dwarves. "exterminate it" kills the currently-selected unit. More: https://dfhack.readthedocs.io/en/latest/docs/_auto/base.html?highlight=exterminate#exterminate
This does leave a corpse behind. You could use autodump to get rid of that if you want.

I guess the autodump documentation could be improved some. Any takers?
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on June 13, 2018, 04:30:53 pm
Another question.. Can you use DF hack to delete dwarves?

Alright it said 34 items marked for destroy but i dont know how to finish it, the items are still there.
The reason items don't disappear immediately when you destroy them is that the command marks them for destruction, but they're not actually removed until DF resumes. This, in turn, is because you can't just disintegrate items, but have to clean them out properly so ownership, container contents/holder, etc. are removed without leaving references to objects that just vanished.
The same goes for eliminating creatures: owned items have to be dealt with, nobility inheritance has to be taken care of, pet/spouse/... loss depression processed, etc.
Title: Re: DFHack 0.44.10-r1
Post by: DizzyCrash on June 14, 2018, 07:49:22 pm
Can you exile dwarves?
Title: Re: DFHack 0.44.10-r1
Post by: Quietust on June 14, 2018, 08:52:13 pm
The reason items don't disappear immediately when you destroy them is that the command marks them for destruction, but they're not actually removed until DF resumes. This, in turn, is because you can't just disintegrate items, but have to clean them out properly so ownership, container contents/holder, etc. are removed without leaving references to objects that just vanished.
And the reason you have to unpause is because DFHack doesn't actually know how to do all of that cleanup, so it just sets a special flag and tells Dwarf Fortress itself to do that cleanup, and that only happens when the game is unpaused (once every 100 frames, if I recall correctly).

Can you exile dwarves?
Why do you want to do that?
Title: Re: DFHack 0.44.10-r1
Post by: DizzyCrash on June 14, 2018, 09:13:33 pm
The reason items don't disappear immediately when you destroy them is that the command marks them for destruction, but they're not actually removed until DF resumes. This, in turn, is because you can't just disintegrate items, but have to clean them out properly so ownership, container contents/holder, etc. are removed without leaving references to objects that just vanished.
And the reason you have to unpause is because DFHack doesn't actually know how to do all of that cleanup, so it just sets a special flag and tells Dwarf Fortress itself to do that cleanup, and that only happens when the game is unpaused (once every 100 frames, if I recall correctly).

Can you exile dwarves?
Why do you want to do that?

Cause throwing them off bridges is overloading me with tombstones.
Title: Re: DFHack 0.44.10-r1
Post by: Rose on June 14, 2018, 09:59:19 pm
You will be able to exile them in the next version.

In the mean time, you can send them solo to attack the goblin capitol.
Title: Re: DFHack 0.44.10-r1
Post by: DizzyCrash on June 14, 2018, 10:56:24 pm
Oh? How do i do that?
Title: Re: DFHack 0.44.10-r1
Post by: DizzyCrash on June 14, 2018, 11:20:25 pm
I am just extremely particular who joins my civilization and gets remembered in our halls of heroes. I have spartan levels of high expectations... Except that instead of looking for strong capable warriors i am looking for unique and interesting dwarves with personalities and appearances that i do not currently have.
Title: Re: DFHack 0.44.10-r1
Post by: Sorg on June 14, 2018, 11:45:21 pm
Oh? How do i do that?
Just send undesirable dwarves on a mission. You don't need dfhack for that.
http://dwarffortresswiki.org/index.php/DF2014:Mission
Title: Re: DFHack 0.44.10-r1
Post by: DizzyCrash on June 15, 2018, 10:47:40 pm
Oh? How do i do that?
Just send undesirable dwarves on a mission. You don't need dfhack for that.
http://dwarffortresswiki.org/index.php/DF2014:Mission
And the children go off the cliff?
Title: Re: DFHack 0.44.10-r1
Post by: Rose on June 15, 2018, 10:57:45 pm
Ah yes, sadly, not much you can do with the children besides day care.
Title: Re: DFHack 0.44.10-r1
Post by: Clément on June 16, 2018, 02:32:09 am
unit_soul's unk_4410_1 and unk_4410_2 are focus related. They could be unit_personality's current_focus and undistracted_focus which have moved two field further. I am not sure since I don't really know how they supposed to work. Maybe strainer can confirm.

PS: unit_soul.unk_4410_2 is initially 1 (just after embark) but as soon as a need is changed it is set to 4 times the number of needs, so it really looks like it.
Title: Re: DFHack 0.44.10-r1
Post by: PatrikLundell on June 16, 2018, 04:44:02 am
@DizzyCrash:
You might want to try an old DFHack script called emigration which is intended to make unhappy dorfs leave on their own accord. The version the current DFHack release is broken, but this version ought to work (functionally the same as the one in the next DFHack release):
Spoiler (click to show/hide)
It ought to be possible to just use the leaving part of the logic to kick out targeted dorfs.

Edit: The script logic was screwed up (again). Should be fixed now.
Title: Re: DFHack 0.44.10-r1
Post by: Rose on June 16, 2018, 05:04:54 am
Alternately wait till next week, when you'll be able to just flat out tell dwarfs to get lost. Sadly won't work on nobles, which would be the prime use case for such a feature.
Title: Re: DFHack 0.44.10-r1
Post by: strainer on June 16, 2018, 11:05:56 am
Quote from: Clément
unit_soul's unk_4410_1 and unk_4410_2 are focus related. They could be unit_personality's current_focus and undistracted_focus which have moved two field further. I am not sure since I don't really know how they supposed to work. Maybe strainer can confirm.
Thanks for working this out Clément. When I use ..soul->unk_4410_1 as current_focus and ..soul->unk_4410_2 as undistracted_focus my previous rating system works just like before. After embark their working range seems to be around 75 to 125 each. Ill copy this table you posted in Therapists thread for the record here:

""""
The current_focus thresholds for "Overall, <name> is [...] with satisfied needs/by unmet needs, are relative to undistracted_focus:
This is based on only two different values for undistracted_focus.
""""

I also compared the colors and phrases used to describe the focus changes, looking for some difference in 'current_focus' and 'undistracted_focus' changes, but nothing stands out.
"he is (this) after..."

edit - I see there, the yellow is worse than brown ^^
Title: Re: DFHack 0.44.10-r1
Post by: Clément on June 19, 2018, 03:39:26 pm
Is there a script or program that would format the data from df-structures so it can be imported in IDA?
Title: Re: DFHack 0.44.10-r1
Post by: lethosor on June 19, 2018, 03:42:03 pm
https://github.com/jjyg/df_misc/blob/master/codegen_c_hdr.pl
https://github.com/jjyg/df_misc/blob/master/dump_df_globals.rb also supports an IDC format
Title: Re: DFHack 0.44.10-r1
Post by: Clément on June 20, 2018, 02:48:22 am
Thanks. I fear then generated codegen.h may have some issues with gcc builds. Generated structure for derived classes use
Code: [Select]
struct derived {
    struct base super;
    /* ... */
};
Although, this is usually how you do inheritance in C, it may not use the exact same layout as C++ classes. When deriving non-POD types, GCC optimize for space and and does not count the padding at the end of the base class. Among offsets used by DT, this affects history_event_hist_figure_diedst and item_crafted.

It should work fine with MSVC, where, IIRC, the tail padding is kept.
Title: Re: DFHack 0.44.10-r1
Post by: mifki on June 20, 2018, 06:44:10 am
Thanks. I fear then generated codegen.h may have some issues with gcc builds. Generated structure for derived classes use
Code: [Select]
struct derived {
    struct base super;
    /* ... */
};
Although, this is usually how you do inheritance in C, it may not use the exact same layout as C++ classes. When deriving non-POD types, GCC optimize for space and and does not count the padding at the end of the base class. Among offsets used by DT, this affects history_event_hist_figure_diedst and item_crafted.

It should work fine with MSVC, where, IIRC, the tail padding is kept.

Yes. When I was recently using codegen_c_hdr to analyse osx binary, I modified it to just output all the fields from base class directly, and then all the layouts were correct.
Title: Re: DFHack 0.44.10-r1
Post by: Quietust on June 20, 2018, 06:36:35 pm
Interestingly, IDA 7.0 actually understands the "struct [class] : [base]" syntax in imported header files (despite its documentation stating that it doesn't understand C++), though it just translates it into a "baseclass_0" field at the beginning, which sadly doesn't help with this problem.
Title: Re: DFHack 0.44.10-r1
Post by: Clément on June 22, 2018, 04:06:47 am
Yes. When I was recently using codegen_c_hdr to analyse osx binary, I modified it to just output all the fields from base class directly, and then all the layouts were correct.

Can you share your modifications?

Edit: I tried to do it myself:
Code: [Select]
diff --git a/codegen_c_hdr.pl b/codegen_c_hdr.pl
index de6a3d2..1f73ec7 100644
--- a/codegen_c_hdr.pl
+++ b/codegen_c_hdr.pl
@@ -225,7 +225,7 @@ sub render_global_class {
     }
     indent {
         if ($parent) {
-            push @lines, "struct $parent super;";
+            push @lines, "struct $parent super;" if (!$linux);
         } elsif ($has_rtti) {
             push @lines, "struct vtable_$rtti_name *vtable;";
         }
@@ -245,12 +245,21 @@ sub render_global_class {
     push @lines_full, @lines;
 }
 sub render_struct_fields {
-    my ($type) = @_;
+    my ($type, $super_prefix) = @_;
+    $super_prefix = '' if (!$super_prefix);
+
+    my $parent = $type->getAttribute('inherits-from');
+    if ($linux && $parent) {
+        my $ptype = $global_types{$parent};
+        render_struct_fields($ptype, $super_prefix.'super_');
+        push @lines, "/* end of parent: $parent */";
+    }
 
     for my $field ($type->findnodes('child::ld:field')) {
         my $name = $field->getAttribute('name') ||
                    $field->getAttribute('ld:anon-name');
         $name = '_' . $name if !$stdc and $name and $name =~ /^(sub|locret|loc|off|seg|asc|byte|word|dword|qword|flt|dbl|tbyte|stru|algn|unk)_|^effects$/;
+        $name = $super_prefix . $name if $name;
         render_item($field, $name);
         $lines[$#lines] .= ';';
     }
Does it look right?
Title: Re: DFHack 0.44.10-r2
Post by: lethosor on June 22, 2018, 05:51:14 am
New release! https://github.com/DFHack/dfhack/releases/tag/0.44.10-r2
Thanks to everyone who submitted fixes - several long-standing issues were found and fixed.
Title: Re: DFHack 0.44.10-r1
Post by: mifki on June 22, 2018, 07:04:11 am
Yes. When I was recently using codegen_c_hdr to analyse osx binary, I modified it to just output all the fields from base class directly, and then all the layouts were correct.

It's on another computer, so the next time I get there.
Title: Re: DFHack 0.44.10-r2
Post by: Grey977 on June 25, 2018, 04:47:13 pm
Good day.

 I cant find gui\autogem UI in game menus and in DFHack’s documentation no keybinding to this function like other gui scripts... Can someone help me?
Title: Re: DFHack 0.44.10-r1
Post by: mifki on June 25, 2018, 04:58:20 pm
Yes. When I was recently using codegen_c_hdr to analyse osx binary, I modified it to just output all the fields from base class directly, and then all the layouts were correct.

Can you share your modifications?


https://gist.github.com/pronvit/19e4cd34427ccddd7b7d6cf0f61cc5ef
Title: Re: DFHack 0.44.10-r2
Post by: lethosor on June 25, 2018, 05:38:48 pm
Good day.

 I cant find gui\autogem UI in game menus and in DFHack’s documentation no keybinding to this function like other gui scripts... Can someone help me?
First, it's gui/autogems, not gui\autogem. You can literally run "gui/autogems" in the console at any time (like most other commands) and the screen will open, as long as you have a world loaded. There's also a "G: Opts" option in the o-W menu, right next to "g: Auto cut gems", which will also open the screen.
Title: Re: DFHack 0.44.10-r2
Post by: Grey977 on June 25, 2018, 11:47:13 pm
Quote
First, it's gui/autogems, not gui\autogem. You can literally run "gui/autogems" in the console at any time (like most other commands) and the screen will open, as long as you have a world loaded. There's also a "G: Opts" option in the o-W menu, right next to "g: Auto cut gems", which will also open the screen.

Ths for response. Yes, it is "gui/autogems", it was a typo.

There was another one... No gui script in giu folder. :-) Ths.
Title: Re: DFHack 0.44.10-r2
Post by: FantasticDorf on June 26, 2018, 03:32:59 am
As ever, its very amusing that Toady publishes the next release the day after a preceeding DF_hack update for the now previous release, may i ask how the follow up for the current (as of this post 44.11) DF version's DF_hack is coming along?
Title: Re: DFHack 0.44.10-r2
Post by: PatrikLundell on June 26, 2018, 04:44:01 am
As ever, its very amusing that Toady publishes the next release the day after a preceeding DF_hack update for the now previous release, may i ask how the follow up for the current (as of this post 44.11) DF version's DF_hack is coming along?
This time it wasn't that unexpected, as Toady said he'd make a release about a week from the previous post. However, I think it was still a good idea to wrap the changes up in a release, since there are people who won't upgrade to the latest DF until there's a DFHack for it, so I expect the release will still see some use.

Asking about when a new DFHack (or DT, or LNP) will become available is rather pointless. It will be done when sufficient prerequisites have been fulfilled, which depends on the amount of trouble encountered when (re)mapping structures and adapting to the changes. The first one may well be an alpha, though, intended more for fault finding and further mapping than play usage.
Title: Re: DFHack 0.44.10-r2
Post by: Darkond2100 on June 28, 2018, 03:57:11 pm
Maybe if you update faster, Toady will too.
Title: Re: DFHack 0.44.10-r2
Post by: lethosor on June 28, 2018, 06:28:57 pm
There's an alpha up as of around 4 hours ago: https://github.com/DFHack/dfhack/releases/tag/0.44.11-alpha1 (forgot to announce it here)

It's worth mentioning that we don't choose how much changes in DF updates. This one had a few things to fix. If you've gotten used to the last few DFHack pre-releases being fast, that's rarely the case - we jut got lucky with those DF updates. Nearly every DFHack release back in 0.40.x took at least a week, and that was considered fast.
Title: Re: DFHack 0.44.11-alpha1 (dev)
Post by: Darkond2100 on June 28, 2018, 06:35:26 pm
Cool, now Toady will release a bugfix tomorrow.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: Cathar on June 28, 2018, 07:35:36 pm
You guys are awesome. Thanks so much
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: KittyTac on June 28, 2018, 09:30:38 pm
Yay! I mostly use DFHack for adv mode messing around, so I don't care too much about bugs.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: scourge728 on June 29, 2018, 06:39:27 pm
Is there any way to disable the thing when you're selecting materials to build things and it automatically pulls up the one you used last?
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: Bumber on June 29, 2018, 08:44:56 pm
Is there any way to disable the thing when you're selecting materials to build things and it automatically pulls up the one you used last?
Remove the line "enable automaterial" from dfhack.init.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: scourge728 on June 29, 2018, 11:26:20 pm
Is there any way to disable the thing when you're selecting materials to build things and it automatically pulls up the one you used last?
Remove the line "enable automaterial" from dfhack.init.
So, can I just copy the contents of the example into a file named dfhack.init in order to create one or...?

Also, remove-wear isn't working for me, I don't get any errors, but nothing is happening, adding -all to it does nothing as well... is it borked in the 44.11 alpha?
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: Putnam on June 29, 2018, 11:32:49 pm
Or rename init-example, as I'm pretty sure it suggests.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: lethosor on June 29, 2018, 11:49:15 pm
Is there any way to disable the thing when you're selecting materials to build things and it automatically pulls up the one you used last?
Remove the line "enable automaterial" from dfhack.init.
So, can I just copy the contents of the example into a file named dfhack.init in order to create one or...?
Or remove the line "enable automaterial" from whatever file it's in...
Quote
Also, remove-wear isn't working for me, I don't get any errors, but nothing is happening, adding -all to it does nothing as well... is it borked in the 44.11 alpha?
From checking the docs, it takes "all", not "-all".
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: scourge728 on June 29, 2018, 11:50:45 pm
Well look at that, it DOES work when you use "all", it's confusing, since some commands accept "all" some accept "-all"  :-[
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: lethosor on June 30, 2018, 12:10:35 am
Upon closer investigation, that script is utter trash. I fixed it so that (a) it's actually readable, (b) it follows sane coding conventions, (c) it's significantly faster with large numbers of items, (d) it produces error messages when you give it bad arguments, instead of silently failing, and (e) it accepts "-all" as well. You can find the fixed version at https://github.com/DFHack/scripts/blob/master/remove-wear.lua

Just want to double-check - was that the only issue you were having with remove-wear? (Or were there issues with passing it individual item IDs?) In any case, issues with it probably aren't 0.44.11-specific, but do feel free to report other weirdness with scripts that you encounter.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: scourge728 on June 30, 2018, 09:54:20 am
That was in fact the only issue I was having
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: Jazz Cat on June 30, 2018, 01:41:36 pm
Just letting you know, the link on the first post of this thread that says "Alpha 44.11 alpha-1" leads to the the 44.10 alpha-1 release.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: lethosor on June 30, 2018, 03:50:07 pm
Thanks, fixed (I remembered most of them, just not the link...)
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: Rumrusher on July 04, 2018, 06:44:41 am
hmm I probably should look into finding out how to give labors to units who end up with the "No labors available" screen

edit: oh it seems there's no unit_flags1.dead flag in this alpha
edit: or got a name changed to inactive?
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: Clément on July 04, 2018, 07:34:18 am
"dead" has been renamed "inactive" since 0.44.10-r2 (https://github.com/DFHack/df-structures/commit/321bd48b10c4c3f694cc801a7dee6be392c09b7b).
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: PatrikLundell on July 04, 2018, 07:38:35 am
hmm I probably should look into finding out how to give labors to units who end up with the "No labors available" screen

edit: oh it seems there's no unit_flags1.dead flag in this alpha
"dead" has been renamed "inactive" since 0.44.10-r2.
And the reason for that is that flags2.killed is the one that tells if a unit is dead. All killed units are inactive, but all inactive units are not killed (e.g. inbound/outbound). Also consider whether you actually need to access the flags directly, or can use the Units.isKilled/.isActive/.isMerchant etc. functions instead.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: Rumrusher on July 04, 2018, 07:43:58 am
oh hmm I probably should have refresh the page before editing the post. oh well this means modifying my heal scripts to fit the new changes then.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: Saiko Kila on July 05, 2018, 02:27:14 am
I have a problem with function dfhack.units.getVisibleName() in lua script.

When I want the script to show real name, I use simply
Code: [Select]
string.gsub(unit.first_name,"^%l",string.upper)
When I wanted to show fake name, I tried this:
Code: [Select]
string.gsub(dfhack.units.getVisibleName(unit).first_name,"^%l",string.upper)
However, the last code still shows the same real first name as the first one (and thus reveals an identity of a vampire). According to description the function  should show the fake name, right? So why would it show the real one?

And the reason for that is that flags2.killed is the one that tells if a unit is dead. All killed units are inactive, but all inactive units are not killed (e.g. inbound/outbound). Also consider whether you actually need to access the flags directly, or can use the Units.isKilled/.isActive/.isMerchant etc. functions instead.

After the rename I just changed the names of flags in my scripts from "flags1.dead " to "flags1[1]", so they will work with both names under different dfhacks. Problems with functions is that you need to test them first, because they are not always working as expected. Using a flag is quicker and less stressful, if you know what it's supposed to do.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: Putnam on July 05, 2018, 03:59:05 am
...the reason for the rename is because it did not mean what we thought it meant and using it to mean "dead" is incorrect so it should be replaced in anything that assumes that having that flag be "true" must mean that unit is dead.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: PatrikLundell on July 05, 2018, 07:26:05 am
Yes, as Putnam said, just changing scripts to use the same flag (regardless of access method) without checking the logic for why that flag is used isn't a winning strategy. Sometimes the logic turns out to work out as desired, and sometimes it needs to be revised. All the scripts and plugins in DFHack have been examined, and many of them had to have their logic revised.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: lethosor on July 05, 2018, 08:31:30 am
Also, flags1[1] is much less readable. Saying you need to "test functions first" is a bad excuse - you can look at the source of isDead here (https://github.com/DFHack/dfhack/blob/8a1979b8a7aecee299c0d74720ee37eeaef9fee5/library/modules/Units.cpp#L387) - it's literally just two flag checks that indicate dead units. If you really care about inactive units instead, either use "flags1.inactive" or "not dfhack.units.isActive(unit)".
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: Saiko Kila on July 05, 2018, 11:51:26 am
Also, flags1[1] is much less readable. Saying you need to "test functions first" is a bad excuse - you can look at the source of isDead here (https://github.com/DFHack/dfhack/blob/8a1979b8a7aecee299c0d74720ee37eeaef9fee5/library/modules/Units.cpp#L387) - it's literally just two flag checks that indicate dead units. If you really care about inactive units instead, either use "flags1.inactive" or "not dfhack.units.isActive(unit)".

I do care about inactive units. Flag flags1.inactive/flags1.dead (on) and flags2.killed (off) together are used to determine that the unit just went off the map or is coming in (like migrants, merchants, invaders or animals do). So both flags are useful. If I want to make my script usable in two different versions of DF, then I have to use more direct method of accessing, because of this name change. This is much less pain than editing the script for every version separately, when I change something.

That, and some functions are not available in earlier dfhacks, or do not work like I think they should (like this dfhack.units.getVisibleName() I have problem with now, or dfhack.units.isCitizen() I had problems with).
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: lethosor on July 05, 2018, 02:15:48 pm
You should write your own function, then, or just drop support for older DFHack versions. Never use flags1[1] or anything like that - it's just not readable.

The point of functions is that they'll work correctly across DFHack versions, barring bugs. If you find an issue, reporting it is a better solution than ignoring it and using something that will break later. Of course, new functions don't exist in old DFHack versions, but you can implement your own version of a function in a script if that's an issue.

There is a reported issue with getVisibleName: https://github.com/DFHack/dfhack/issues/1279. I think it has to do with new false identity stuff in 0.44. Not quite sure how to fix it.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-alpha1 (dev)
Post by: PatrikLundell on July 05, 2018, 04:52:24 pm
The way I deal with support for multiple, incompatible, versions in scripts is to write version dependent scripts, so if it's older than the new structure I use the old name/location, while if it's new I use the new one. One of the few advantages with scripts not checking semantics legality is this ability. I certainly don't complain about newer DFHack versions updating things to be more correct, like e.g. naming anon fields, or removing a nesting level that's probably artificial.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-beta1 (dev)
Post by: lethosor on July 06, 2018, 07:39:09 pm
0.44.11-beta1 is up: https://github.com/DFHack/dfhack/releases/tag/0.44.11-beta1
Thanks to BenLubar for handling most of the things I forgot to do when publishing the release.

This should fix the getVisibleName issue, I think. If it doesn't, a save that has issues would be very helpful.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-beta1 (dev)
Post by: Radipon on July 07, 2018, 05:57:43 am
The console seems to hang on startup. Encountered on the x86_win64 build and reproduced with a fresh install.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-beta1 (dev)
Post by: scourge728 on July 07, 2018, 12:37:53 pm
I can't actually USE the console, it loads and everything, but typing does nothing.....
Title: Re: DFHack 0.44.10-r2 | 0.44.11-beta1 (dev)
Post by: Imperator314 on July 07, 2018, 02:21:12 pm
I can't actually USE the console, it loads and everything, but typing does nothing.....

Same here. I did a 100% fresh install and I still can't figure it out.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-beta1 (dev)
Post by: lethosor on July 07, 2018, 03:20:51 pm
If you could all specify that you're using Windows, that would help.
In any case, we're aware of the issue: https://github.com/DFHack/dfhack/issues/1345
Title: Re: DFHack 0.44.10-r2 | 0.44.11-beta1 (dev)
Post by: Imperator314 on July 07, 2018, 04:10:10 pm
If you could all specify that you're using Windows, that would help.

Yes, Windows 10.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-beta1 (dev)
Post by: lethosor on July 07, 2018, 06:59:58 pm
We've found the issue, and 0.44.11-beta2 should be up in an hour or two at https://github.com/dfhack/dfhack/releases to fix it.

Edit: Stonesense is garbage and broke the build. The 64-bit Windows one worked, though, so it's up at https://github.com/DFHack/dfhack/releases/tag/0.44.11-beta2. Just in time for 0.44.12, too! We'll try to get a beta2.1 or something up before moving away from 0.44.11.
Title: Re: DFHack 0.44.10-r2 | 0.44.11-beta2.1 (dev)
Post by: lethosor on July 07, 2018, 10:26:11 pm
https://github.com/DFHack/dfhack/releases/tag/0.44.11-beta2.1 is up now. 0.44.12 support is coming up, although we have no timeline for that yet.
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: lethosor on July 08, 2018, 05:04:46 pm
0.44.12 build! https://github.com/DFHack/dfhack/releases/tag/0.44.12-alpha1

Unfortunately someone reported a remove-stress issue just before the build was finished. You can fix it by changing "Enraged" to "Enranged" in hack/scripts/remove-stress.lua. (Yes, that's introducing a typo to match another typo. The name in the next release should be fixed.)
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: Saiko Kila on July 09, 2018, 03:24:47 am
Anyone else has this problem with Win x64 build (0.44.12-alpha1):
 When using "die" to exit DF, the DF's window disappear, but the DFHack's window still hangs there, and the whole Dwarf Fortress.exe process doesn't exit too? I need to kill it manually with process explorer.
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: clinodev on July 09, 2018, 03:37:36 am
Anyone else has this problem with Win x64 build (0.44.12-alpha1):
 When using "die" to exit DF, the DF's window disappear, but the DFHack's window still hangs there, and the whole Dwarf Fortress.exe process doesn't exit too? I need to kill it manually with process explorer.

With Win x64 build (0.44.12-alpha1), and the 0.44.11 alpha as well, the DFHack window does hang for me for longer than expected, closing on its own after 15s or so. I haven't had to end the process (after noting it indeed did eventually close the first few times, now I just go on with my business. I only use "die" when testing quick things in disposable worlds.) Windows 10.
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: Saiko Kila on July 09, 2018, 05:00:21 am
Anyone else has this problem with Win x64 build (0.44.12-alpha1):
 When using "die" to exit DF, the DF's window disappear, but the DFHack's window still hangs there, and the whole Dwarf Fortress.exe process doesn't exit too? I need to kill it manually with process explorer.

With Win x64 build (0.44.12-alpha1), and the 0.44.11 alpha as well, the DFHack window does hang for me for longer than expected, closing on its own after 15s or so. I haven't had to end the process (after noting it indeed did eventually close the first few times, now I just go on with my business. I only use "die" when testing quick things in disposable worlds.) Windows 10.

Thank you, this prompted me to check it out on Win 10. I have a dual boot PC with Windows Vista and Windows 10.

On Windows 10 it works as you said: first time in hangs for several seconds, subsequently it stops for only a second or two (so overall: correctly). I thought that problem may be due to a difference in antivirus (Avast on Vista, Kaspersky on Win10), but disabling Avast on Vista apparently didn't help. Something has changed between 0.44.11-alpha1 and 0.44.12-alpha1, which prevents the "die" to work in full on my system.
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: plenum on July 09, 2018, 05:24:47 am
Hey!
Have anyone tried to copy burrow? Can't find anything on that... I wonder how hard is it do in script?
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: Meph on July 09, 2018, 05:28:28 am
Just wanted to say that you guys are amazing and keep up the good work. :-) Today is just waiting for your updates before he releases the next version.  ;)
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: iceball3 on July 09, 2018, 11:57:33 pm
Hey, all this new update hype made me wanna to drop by and say, thank you all who work on DFHack between updates. <3
No rush, just saying that I really appreciate the work y'all have done to get this stuff going well!
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: Rumrusher on July 10, 2018, 03:30:02 am
it seems the new dfhack adds a new folder called 'included' which I'm wondering if that suppose to add something?
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: Saiko Kila on July 10, 2018, 03:43:16 am
it seems the new dfhack adds a new folder called 'included' which I'm wondering if that suppose to add something?

This "include" directory looks like a part of source code that was included mistakenly.

This may be related to my problem, which I described a few posts back - that the console window doesn't go away after the "die" command, and this holds the whole Dwarf Fortress.exe process (which must be killed by external means).

I have checked all released versions of DFHack for 0.44.11, and the last one which didn't have the problem was DFHack 0.44.11-alpha1.
The next version, DFHack 0.44.11-beta1 was bugged (console not initialised at all), and all the subsequent versions, starting with DFHack 0.44.11-beta2, hang on "die" on my system. They also include these directories "include" and "lib", coincidentally or not.

Something was changed with the bugged version, and this change does affect my system, even though it doesn't affect Windows 10. It looks like the console doesn't quit cleanly.
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: lethosor on July 10, 2018, 06:53:13 am
The "include" and "lib" folders are due to jsoncpp changes and were included accidentally. They won't be in future releases. They're unused and are entirely unrelated to your console issues.

I'd recommend reading the release notes. The ones for beta2 list a few significant console changes, which are the reason for any new console bugs, like the one in beta2. We're not hiding anything - in fact, the announcement on GitHub explicitly asked people to look for and report console issues.

Anyway, "die" calls _exit() and nothing else, which is defined to kill the current process immediately. As far as I know, it's not even possible for it to hang, so I have no idea what's going on there. Can you report this on GitHub so it won't be forgotten? https://github.com/DFHack/dfhack/issues/1356
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: Quietust on July 10, 2018, 07:02:47 am
Anyone else has this problem with Win x64 build (0.44.12-alpha1):
 When using "die" to exit DF, the DF's window disappear, but the DFHack's window still hangs there, and the whole Dwarf Fortress.exe process doesn't exit too? I need to kill it manually with process explorer.
I'm actually seeing a totally different problem - with the 32-bit version on Windows 7 x64, it outright crashes if I type "die" in the console, but if I exit the game cleanly, it works fine. The 64-bit version doesn't seem to be affected.
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: Rose on July 10, 2018, 08:06:55 am
I've had hangs from pressing die in the console, but reproducing them has been tricky.
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: Saiko Kila on July 10, 2018, 10:38:36 am
I've checked threads of bugged process. The function which hangs in my case is called _crt_at_quick_exit (it's a kernel function), which has state "Wait, executive". This means it waits for thread scheduler, which never shows interest in the thread. I can speculate that memory management or garbage collection mechanisms of Windows 10 take care of this, while ones from Vista can't, and from Win7 maybe partially can.

I'm not a specialist in this matter, but the quick exit function has some precautions, like registering I/O and generally functions to be flushed when it's called, so it's not exactly fire and forget. Maybe they are not registered properly.
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: lethosor on July 10, 2018, 11:11:49 am
Suokko and BenLubar traced it down to _exit and _Exit not doing their job properly on Windows, basically (the standard specifies that _Exit shouldn't call global destructors, but it is). Suokko produced a fix that might work: https://github.com/DFHack/dfhack/pull/1357
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: lethosor on July 11, 2018, 01:13:36 pm
Here is a test build (http://files.dfhack.org/180711000/) that should fix the Windows "die" issues. Can some of you test it?
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: iceball3 on July 11, 2018, 04:39:13 pm
Probably not the platform you're looking for tests, but I managed to use "die" successfully ingame using that new 64 bit build.
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: lethosor on July 11, 2018, 04:44:03 pm
Probably not the platform you're looking for tests, but I managed to use "die" successfully ingame using that new 64 bit build.
Ok, then what platform are you using?
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: iceball3 on July 11, 2018, 04:47:47 pm
Probably not the platform you're looking for tests, but I managed to use "die" successfully ingame using that new 64 bit build.
Ok, then what platform are you using?
Crap, forgot to finish the description. Windows 64 bit.
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: clinodev on July 11, 2018, 05:03:24 pm
Using:

DFHack version 0.44.12-alpha1 (development build 0.44.12-alpha1-35-g350ead26) on x86_64 [build ID: 180711000]

on: Windows 10 64 bit,

my results using "die" in Fortress Mode from a paused play screen are the same as I reported with the other build above, Dwarf Fortress window closes immediately, DFHack closes some seconds later, noticeably later than I recall from earlier versions, but not problematically hanging like Saiko Kila reported.
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: lethosor on July 11, 2018, 06:53:55 pm
Probably not the platform you're looking for tests, but I managed to use "die" successfully ingame using that new 64 bit build.
Ok, then what platform are you using?
Crap, forgot to finish the description. Windows 64 bit.
That was exactly the platform I was looking for. People above reported issues with Windows, so I put up Windows builds to test. (Then I put up other ones as they finished.) Thanks for the feedback.

Using:

DFHack version 0.44.12-alpha1 (development build 0.44.12-alpha1-35-g350ead26) on x86_64 [build ID: 180711000]

on: Windows 10 64 bit,

my results using "die" in Fortress Mode from a paused play screen are the same as I reported with the other build above, Dwarf Fortress window closes immediately, DFHack closes some seconds later, noticeably later than I recall from earlier versions, but not problematically hanging like Saiko Kila reported.
Okay, that's not great. Has it occurred in older DFHack versions for you? Ab9rf said it happened for her a while ago too (on Windows), i.e. before 0.44.10.

Also, is it possible that DF is actually crashing? Some people turn off crash reports and then think DF is just closing silently when it's actually crashing - could that be the case? Also, sometimes the Ruby plugin can interfere with crash reports - maybe delete hack/plugins/ruby.plug.dll and see what happens?

At any rate, we've done all that we can think of at this point to fix the issue. We already know that MSVC isn't standards-compliant in at least some respect here (with _Exit() not working as it should), so I'm inclined to leave it as-is and blame MSVC for any further "die" issues, unless other people have ideas for fixing it.
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: surazal on July 11, 2018, 08:05:17 pm
So I just started running into an issue with newer builds of dfhack. dfhack 0.44.11-alpha1 worked fine for me, but when I tried upgrading to 0.44.11.beta-2.1 I got one of the following errors. I just tried testing 0.44.12.-alpha1 and I still get the same error. I'm not sure what library I'm missing or supposed to install (like I said this just started happening in the past couple of weeks and I'm pretty up-to-date on my packages). Error is:

./libs/Dwarf_Fortress: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by ./hack/libdfhack.so)

I'm not sure what "glibcxx-3.44.22" refers to as I don't have that installed anywhere in my system and "apt-cache search" returns no results for glibcxx or anything similarly named. The message suggested I run this:

cp libs/libstdc++.so.6.backup libs/libstdc++.so.6

But if I do, I get another error:

./libs/Dwarf_Fortress: /home/dfinton/DF/df_linux/libs/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by ./hack/libdfhack.so)
./libs/Dwarf_Fortress: /home/dfinton/DF/df_linux/libs/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by ./hack/libdfhack.so)
./libs/Dwarf_Fortress: /home/dfinton/DF/df_linux/libs/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./hack/libdfhack.so)
./libs/Dwarf_Fortress: /home/dfinton/DF/df_linux/libs/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by ./hack/libprotobuf-lite.so)

The message suggested I try adding the following line to ~/.dfhackrc as well, but that didn't do anything. I even ran the export command directly on the command line but I got the same result.

export DFHACK_NO_RENAME_LIBSTDCXX=1

I'm running Ubuntu 16.04. on x64. I installed the gcc7 version of the 64 bit build of dfhack (same as I've always run). Google suggests installing libstdc++6, but I have that installed already. I'm update-to-date on all my packages as well.

Anyone know what's going on? I'm kind of stumped on this one. Thanks!
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: lethosor on July 11, 2018, 08:36:12 pm
Have you tried the GCC 4.8 version? From https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html, GLIBCXX_3.4.22 is from GCC 6.1.0, so if you don't have that or newer, you will need the GCC 4.8 build.
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: clinodev on July 11, 2018, 09:24:52 pm

Okay, that's not great. Has it occurred in older DFHack versions for you? Ab9rf said it happened for her a while ago too (on Windows), i.e. before 0.44.10.

Also, is it possible that DF is actually crashing? Some people turn off crash reports and then think DF is just closing silently when it's actually crashing - could that be the case? Also, sometimes the Ruby plugin can interfere with crash reports - maybe delete hack/plugins/ruby.plug.dll and see what happens?

At any rate, we've done all that we can think of at this point to fix the issue. We already know that MSVC isn't standards-compliant in at least some respect here (with _Exit() not working as it should), so I'm inclined to leave it as-is and blame MSVC for any further "die" issues, unless other people have ideas for fixing it.

Nothing interesting in stderr.log or stdout.log, no errorlog.txt generated. Repeated the process with ruby.plug.dll removed, no change.

I don't know how to turn off crash reports, but if you tell me where to check, I will. I doubt it's turned off, because the copy I used to test "die" was a newly extracted vanilla copy with your new DFHack installed, and no settings changed other than choosing a smaller world and a shorter world gen.

I often just throw my old game folders into a "DF Stuff" folder rather than deleting them, on the theory I might want to recover something later, and searching that I find my most recent (and only) errorlog.txt is 0.44.03, and looks unrelated.
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: surazal on July 11, 2018, 09:38:40 pm
Have you tried the GCC 4.8 version? From https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html, GLIBCXX_3.4.22 is from GCC 6.1.0, so if you don't have that or newer, you will need the GCC 4.8 build.

The gcc 4.8 build did in fact work. On my system, gcc --version comes back with version 5.4.0.

For fun I checked to see if newer versions of gcc were available for ubuntu 16.04 and I did find 6.0.1 which still wasn't high enough. Huh, I know that ubuntu could be a little slow in updating its dev tools but I had no idea it was that bad.

Anyways, it works now. Thanks!
Title: Re: DFHack 0.44.10-r2 | 0.44.12-alpha1 (dev)
Post by: lethosor on July 12, 2018, 08:43:07 am
I don't know how to turn off crash reports, but if you tell me where to check, I will. I doubt it's turned off, because the copy I used to test "die" was a newly extracted vanilla copy with your new DFHack installed, and no settings changed other than choosing a smaller world and a shorter world gen.
Crash reports are a system setting - nothing to do with how new your DFHack installation is, or other DFHack settings. I just thought Ruby could be interfering with them, but if you have them turned off, it could still be that DFHack is crashing without you knowing. I'm not sure how to turn them on on Windows.

You could try this and see how it behaves (warning: this will crash, use with caution):
Code: [Select]
:lua ~df.reinterpret_cast('int32_t', 1)
Quote
I often just throw my old game folders into a "DF Stuff" folder rather than deleting them, on the theory I might want to recover something later, and searching that I find my most recent (and only) errorlog.txt is 0.44.03, and looks unrelated.
errorlog.txt is DF only - DFHack doesn't touch it. And it's really mostly harmless warnings from DF.

Have you tried the GCC 4.8 version? From https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html, GLIBCXX_3.4.22 is from GCC 6.1.0, so if you don't have that or newer, you will need the GCC 4.8 build.

The gcc 4.8 build did in fact work. On my system, gcc --version comes back with version 5.4.0.

For fun I checked to see if newer versions of gcc were available for ubuntu 16.04 and I did find 6.0.1 which still wasn't high enough. Huh, I know that ubuntu could be a little slow in updating its dev tools but I had no idea it was that bad.

Anyways, it works now. Thanks!
Ubuntu almost never updates packages across major versions. From the GCC release history (https://gcc.gnu.org/releases.html), in April 2016, GCC 5.3 was the newest available (5.4 was released after Ubuntu 16.04 came out, so it probably replaced the 5.3 package later on since it was a minor upgrade).

Also, GCC 6.0.1 doesn't exist. The first release of the GCC 6 series was 6.1.0, so that's probably what you saw. Still won't work with things compiled for GCC 7, though.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on July 13, 2018, 09:55:46 pm
New release! https://github.com/DFHack/dfhack/releases/tag/0.44.12-r1
Title: Re: DFHack 0.44.12-r1
Post by: iceball3 on July 14, 2018, 03:08:22 am
Thanks! I think with this I'll get started on the new version, finally! Lots of hype.
I'll let you know if I hit any roadbumps with the new features, in case DFHack might interact somehow (with units moving between nearby sites and the general hillocks interactions existing now).
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on July 14, 2018, 10:08:31 am
Question for anyone building on macOS/Linux: are you strongly attached to the current "make" build system? There have been discussions on IRC and GitHub about fixing issues with generated files in other build systems, which would require introducing issues with make, because CMake's make backend doesn't have proper support for generated files. Ninja is a cross-platform make alternative that we've been considering, which actually handles generated files properly and is somewhat faster.

Basically, partial rebuilds on Windows (with Visual Studio/MSBuild) often require rebuilding twice, because generated headers don't get generated at the right time. The same issue currently exists with Ninja. The only way we know of to fix it in both Ninja and VS is to introduce an issue where make will update the timestamp of every generated file every time it runs, making partial rebuilds take much longer (basically making make unusable for serious development). Full builds with make should still run as they do currently, although they might regenerate files twice sometimes, so they could be slower.

The current pull request (https://github.com/DFHack/dfhack/pull/1325) includes instructions on how to set up Ninja - it requires installing it, of course, and passing -G Ninja to CMake on the first run. Otherwise, it's just a matter of running "ninja" instead of "make". Any comments there (or here) are welcome.
Title: Re: DFHack 0.44.12-r1
Post by: DwarfToys on July 15, 2018, 12:31:48 am
A quick comment on the forum-dwarves lua script:

The docs mention code page 437, but most software refers to this as OEM-DOS, which is what you have to switch to in Notepad++ to get it to show up correctly.  I did the runaround on that and converted the page body text (I'm guessing title wasn't old ASCII at least with TWBT?) to UTF-8 so it will open in notepad.exe and Notepad++ without doing anything special.  Another thing that works but is less convenient is dumping the printable output directly to the DFHack console window, where the windows clipboard will magically convert it to an encoding compatible with whatever you happen to be pasting it into. 

My hackish modification is below (accidentally grabbed GPL stuff for conversion but that shouldn't stop anyone from the forum using it if the want).  I don't mess with lua really so I make no guarantees, other than it not crashing my machine thus far and the files looking correct.  YMMV.   

Spoiler (click to show/hide)

Title: Re: DFHack 0.44.12-r1
Post by: lethosor on July 15, 2018, 08:03:43 am
There's a built-in function, dfhack.df2utf, for converting CP437 to UTF-8. Is that what you're trying to do? If you're printing to the console, use df2console instead, because the console encoding varies across platforms. See the Lua API docs for more.
Title: Re: DFHack 0.44.12-r1
Post by: DwarfToys on July 15, 2018, 01:21:18 pm
That would do things without my mess.   :P

Console output works / looks fine already.  I may add a "show" flag or something that outputs the BBCode to console instead of the raw screen data info for convenience.  I don't program very much anymore since getting away from doing it for a living.  20 years of assembly languages and compiler intermediate languages broke my brain.

All this does is allow direct usage of the text file output, otherwise it has to be remapped to the correct code page by the user, which is a minor step but enough of one that screenshot / paste / save is more attractive on a machine that only has standard windows programs. 

As far as I know, the built-in text editors on all platforms will handle UTF-8 well as long as the file mime type is correct, but the only one called out in the help text is Windows so I'm guessing the others don't need this type of thing done anyway. 
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on July 15, 2018, 04:22:38 pm
Yeah, everything writing text to files should do it in UTF-8. That isn't the default behavior for DF-encoded text, though, so many tool authors forget this. I'm not sure why it wasn't fixed when the encoding note was added.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on July 16, 2018, 07:16:20 am
@lethosor: No particular attachment to make. Though I couldn't find ninja's minimum requirements at glance (I guess it might possibly want multi-core computer), no idea if they're significant for anyone.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on July 16, 2018, 08:10:32 am
Neither could care less how many cores your computer has - the only difference is that Ninja uses multiple cores by default, while Make does not, but that's configurable with the -j option for both.
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on July 17, 2018, 10:59:14 am
DFHack structure research request: Does anyone know how to look for volcanoes?

I know volcanoes are present as features, but when you view volcanoes pre embark they have names, which implies there should be a structure for them specifically akin to the one for rivers or the one for mountain peaks. A volcano structure also ought to contain the world tile coordinates of the volcano, and probably the mid level (region) tile coordinates within that tile as well.

The reason I'm looking for this data is that I've tried to hack a volcano in and then tried to embark on top of it, and DF has crashed every time. Apart from that, the volcano is visible only on the region view, not on the world tile level, which is another indication that there's something missing, and DF creates a region feature for the volcano where it feels like it, not where I want it (if I create it and move away from the tile, it's back where DF creates it when returning).

Edit: It looks like volcanoes are a special case of mountain peaks. It's possible flags[0] is "is_volcano".
Edit 2: And hacking in a "volcano" mountain peak caused a volcano to appear: the other structures were created automatically, and embarking on top of it worked. I've failed to see anything indicating which mid level tile the volcano would appear in, though.
Title: Re: DFHack 0.44.12-r1
Post by: mifki on July 17, 2018, 07:29:46 pm
I've failed to see anything indicating which mid level tile the volcano would appear in, though.

What?
Title: Re: DFHack 0.44.12-r1
Post by: Meph on July 18, 2018, 02:39:23 am
Cant you simulate a volcano?  change the tiletype to open-space and magma flows, the edges to obsidian. Repeat for x zlvls till the magma lake is reached.
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on July 18, 2018, 02:54:09 am
I've failed to see anything indicating which mid level tile the volcano would appear in, though.

What?
Mid level tile = the 16 * 16 tiles that make up a world tile. The term "mid level tile" is the one Toady used when asked in a FotF about what he called the different levels a year or two ago. Thus, a default embark covers 4*4 mid level tiles. (I assume that's what the rather terse "What?" was asking).

Cant you simulate a volcano?  change the tiletype to open-space and magma flows, the edges to obsidian. Repeat for x zlvls till the magma lake is reached.
Not pre embark, as the structure you'd hack hasn't been generated yet. I assume you could build a simulated "volcano" that way post embark, though, although I don't know if that would provide any magma rain to fill it. Anyway, that's not what I'm interested in doing.
Title: Re: DFHack 0.44.12-r1
Post by: mifki on July 18, 2018, 04:48:58 am
I've failed to see anything indicating which mid level tile the volcano would appear in, though.

What?
Mid level tile = the 16 * 16 tiles that make up a world tile. The term "mid level tile" is the one Toady used when asked in a FotF about what he called the different levels a year or two ago. Thus, a default embark covers 4*4 mid level tiles. (I assume that's what the rather terse "What?" was asking).

Yep, thanks. I've never heard that and was rather confused thinking about z-levels or I don't know what. Don't we usually call them embark tiles?
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on July 18, 2018, 05:22:05 am
They've also been called region tiles, although region tiles have also been used for a different level. Because of the risk for confusion, I've decided to adopt the terminology Toady provided when asked. I tried searching for Toady's answer, but failed to find it, though (I'm not very compatible with either the board or bug tracker search functions).
Title: Re: DFHack 0.44.12-r1
Post by: Sorg on July 19, 2018, 12:04:34 am
They've also been called region tiles, although region tiles have also been used for a different level. Because of the risk for confusion, I've decided to adopt the terminology Toady provided when asked. I tried searching for Toady's answer, but failed to find it, though (I'm not very compatible with either the board or bug tracker search functions).
I think this (http://www.bay12forums.com/smf/index.php?topic=159164.msg7526005#msg7526005) is the answer you are talking about (it's from FotF 08.2017)
Title: Re: DFHack 0.44.12-r1
Post by: mifki on July 19, 2018, 12:28:13 am
I think this (http://www.bay12forums.com/smf/index.php?topic=159164.msg7526005#msg7526005) is the answer you are talking about (it's from FotF 08.2017)

Quote
Ha ha, I'm not sure official names are useful -- they are often the worst names since the purpose of the structures has changed over the years, etc.  In any case, we have the 16x16 world tiles, which are called "feature shells" <...>

Nope I'm not ready to use "feature shells" :)
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on July 19, 2018, 04:08:30 am
Thanks Sorg for digging up Toady's definitions.

I'm using "feature shells" when I need to refer to them, which isn't often, as the only case I know of is the weird organization of features.
Title: Re: DFHack 0.44.12-r1
Post by: Tryble on July 20, 2018, 03:06:47 pm
I just ran into the game-ending open-legends script bug described here (https://github.com/DFHack/dfhack/issues/805#issuecomment-195660593).  The embark explodes in brutal fashion a little while after loading the save (http://dffd.bay12games.com/file.php?id=13910), revealing all tiles, regenerating the map, etc.  Odd, since it looks like this commit (https://github.com/DFHack/lethosor-scripts/pull/3/commits) fixed that problem.

Anyway, judging from the comments in the issue page and related pages, I guess this save is done for?


To help any possible future searchers: Save is massively bugged, one a certain day the entire map is revealed, including HFS.  All dug stone is changed to undug stone as if the dwarves never mined out the fortress, and all buildings on the surface collapse.  The only tiles not replaced by their original stone are those which have items or dwarves standing in them.  In short, just about the entire embark is obliterated.  This is the same thing described in this reddit post (https://www.reddit.com/r/dwarffortress/comments/3htqdx/wtf_just_happened_all_tiles_are_revealed_and_map/), this mantis issue (http://www.bay12games.com/dwarves/mantisbt/view.php?id=9052), and these (https://github.com/DFHack/dfhack/issues/805#issuecomment-195660593) DFHack (https://github.com/DFHack/dfhack/issues/886) threads (https://github.com/DFHack/lethosor-scripts/pull/3).
Title: Re: DFHack 0.44.12-r1
Post by: Meph on July 20, 2018, 03:28:54 pm
Oh no. I just included a little workshop to run open-legends in my pack.  :-/

I hope this can be fixed, or i have to delete it again.
Title: Re: DFHack 0.44.12-r1
Post by: comnom on July 20, 2018, 10:09:57 pm
Hey guys, longtime player/luker/fan of DF and all her utilities.

Couple questions:

How interested would you guys be in an updated(graded) make-monarch script?
I've used the underlying logic to make the script applicable to all noble positions in entity.positions.own ("MONARCH", "DUKE", "COUNT", "BARON", "DIPLOMAT", "GENERAL", "LIEUTENANT", "CAPTAIN", "OUTPOST_LIAISON") and made it so that you can "demote" a unit without raising another.

Spoiler (click to show/hide)

(dead group barons borking my site's progression and "inhereted" barons were the impetus for the script if you were wondering).

I noticed the github repo doesn't have a contributing guidelines, so here I am rather than just doing a PR. Also the original make-monarch doesn't have any licensing attached to it, so while I'd be happy to release under a GNU GPLv3 I'm not quite sure if that's kosher.



With the above script in mind; What do we know about the event(s) concering elevating a fortress (barony/county/duchy)?

Ideally, I'd like to have the script elevate the fort if you assign a position you're not yet on, but I've failed in finding anything relevant.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on July 20, 2018, 10:59:16 pm
I just ran into the game-ending open-legends script bug described here (https://github.com/DFHack/dfhack/issues/805#issuecomment-195660593).  The embark explodes in brutal fashion a little while after loading the save (http://dffd.bay12games.com/file.php?id=13910), revealing all tiles, regenerating the map, etc.  Odd, since it looks like this commit (https://github.com/DFHack/lethosor-scripts/pull/3/commits) fixed that problem.

Anyway, judging from the comments in the issue page and related pages, I guess this save is done for?


To help any possible future searchers: Save is massively bugged, one a certain day the entire map is revealed, including HFS.  All dug stone is changed to undug stone as if the dwarves never mined out the fortress, and all buildings on the surface collapse.  The only tiles not replaced by their original stone are those which have items or dwarves standing in them.  In short, just about the entire embark is obliterated.  This is the same thing described in this reddit post (https://www.reddit.com/r/dwarffortress/comments/3htqdx/wtf_just_happened_all_tiles_are_revealed_and_map/), this mantis issue (http://www.bay12games.com/dwarves/mantisbt/view.php?id=9052), and these (https://github.com/DFHack/dfhack/issues/805#issuecomment-195660593) DFHack (https://github.com/DFHack/dfhack/issues/886) threads (https://github.com/DFHack/lethosor-scripts/pull/3).

The reason https://github.com/DFHack/dfhack/issues/805 is still open is because of https://github.com/DFHack/lethosor-scripts/pull/3#issuecomment-195966083 - the commit you linked isn't a full fix. I'm not sure a full fix is possible. The solution I planned was a large warning telling people not to save after running open-legends (i.e. "quicksave" before, "die" after is safe), and maybe detect if the world has been unpaused since it was loaded too. Evidently I never implemented that, so sorry, but it's on the list for r2 now.

I'm unaware of a way to fix it unless you have backups (it might be possible to copy over the region-*.dat files).

Oh no. I just included a little workshop to run open-legends in my pack.  :-/

I hope this can be fixed, or i have to delete it again.
Can the workshop work within the constraints I mentioned above? They seem strict, but maybe people will still find it useful. Worth noting that this issue has probably been around since open-legends was written in 0.40-ish.

In any case, I haven't seen this locally in the (admittedly few) times I've tried open-legends, and it seems like a pain to reproduce, and there are lots of things that legends mode could touch, depending on what you do in legends mode, so that's why a full fix is very hard. I can try for some partial fixes in addition to a warning message if that would help.

Hey guys, longtime player/luker/fan of DF and all her utilities.

Couple questions:

How interested would you guys be in an updated(graded) make-monarch script?
I've used the underlying logic to make the script applicable to all noble positions in entity.positions.own ("MONARCH", "DUKE", "COUNT", "BARON", "DIPLOMAT", "GENERAL", "LIEUTENANT", "CAPTAIN", "OUTPOST_LIAISON") and made it so that you can "demote" a unit without raising another.
This sounds good! I saw someone ask for that somewhere recently (maybe Reddit?), so it will be appreciated.
Some things could be changed (tabs to spaces, naming conventions, etc.) but those aren't hard.

Quote
I noticed the github repo doesn't have a contributing guidelines, so here I am rather than just doing a PR. Also the original make-monarch doesn't have any licensing attached to it, so while I'd be happy to release under a GNU GPLv3 I'm not quite sure if that's kosher.
Which repo? DFHack/dfhack has https://github.com/DFHack/dfhack/blob/master/Contributing.rst and https://github.com/DFHack/dfhack/blob/master/LICENSE.rst. DFHack/scripts is exclusively a subproject of DFHack/dfhack, so all DFHack guidelines/licensing/etc. apply to it as well. That includes the DFHack license, which is Zlib. For that reason, I'm strongly opposed to GPLv3 - the current script is already Zlib-licensed, and I have no idea what kinds of hoops we'd have to jump through to deal with something GPL-licensed instead (I'd much rather not include it in that case).

Now, admittedly, it's not clear how to find those docs if you just look at DFHack/scripts, but that's one reason for the link back to the main DFHack repo (the docs cover all of the DFHack project). Maybe we could add a readme to the scripts repo explaining this better, although I'm not sure if that will break Sphinx (our HTML doc generator).
Title: Re: DFHack 0.44.12-r1
Post by: comnom on July 20, 2018, 11:14:50 pm
https://github.com/DFHack/dfhack/blob/master/Contributing.rst and https://github.com/DFHack/dfhack/blob/master/LICENSE.rst.

Ah, missed those, sorry about that. I'm used to a contributing.md on github. Any license is fine, just didn't want to conflict with what the original author used.

I'll review all that, and once I flesh out a couple maybe features (elevate the fort, promote an offsite histfig if you demote one), I'll see about a PR since there's interest.
Title: Re: DFHack 0.44.12-r1
Post by: Tryble on July 21, 2018, 11:43:37 am
Evidently I never implemented that, so sorry, but it's on the list for r2 now.

I'm unaware of a way to fix it unless you have backups (it might be possible to copy over the region-*.dat files).

I actually do have some (kind of old) backups, so I'll see how copying the files discussed in the commit works - thanks for the suggestion.
I'm not terribly bummed about probably losing the save.  Better me as a sacrificial dummy than who knows how many people later down the line.  I'm actually kind of surprised there's so few reports about this...only two or three discussions over two years!  I woulda thunk that people exported legends more often to look at how sieges (and especially raids, nowadays) played out.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on July 21, 2018, 12:07:24 pm
The commit doesn't discuss files (only in-game structures). The files I was referring to are the region-X.dat files inside your data/save/regionY folder. It's possible that they were corrupted, and it's possible that overwriting them will break parts of your fort, but I'm not really sure.

I've seen a few more reports of open-legends issues than that over the years, but not as frequently as I would expect for a common issue either, so maybe it's not consistent.
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on July 22, 2018, 02:09:25 am
I too was under the impression the open-legends corruption bug was fixed, and so have tried to dispel the previous advice to quicksave, open-legends, die. Apparently that was unsuitable (and I've continued playing such saves without suffering a crash myself). Time to go back to the old practice and advice, then.
Title: Re: DFHack 0.44.12-r1
Post by: carewolf on July 22, 2018, 06:27:14 am
Does the fix-fat-dwarf script still make any sense? The bug it originally referred to has been closed for a long time. Perhaps some of the other fixes are now also redundant?
Title: Re: DFHack 0.44.12-r1
Post by: zaporozhets on July 22, 2018, 09:30:38 am
Apologies in advance if this is not the right place to ask and for asking a potentially scrubbish question, but is there any way to call the dfhack.units.getUnit() function or something analogous from inside the anonymous-script modtool?
I'm at my wits' end and I'd greatly appreciate some help if anybody would be willing.
Title: Re: DFHack 0.44.12-r1
Post by: Rumrusher on July 22, 2018, 12:29:46 pm
so I take it open-legends doesn't break down on Advmode given the nature of that game loading and unloading maps?
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on July 22, 2018, 12:32:00 pm
Does the fix-fat-dwarf script still make any sense? The bug it originally referred to has been closed for a long time. Perhaps some of the other fixes are now also redundant?
It could probably be removed. I don't think any others are outdated, though.

Apologies in advance if this is not the right place to ask and for asking a potentially scrubbish question, but is there any way to call the dfhack.units.getUnit() function or something analogous from inside the anonymous-script modtool?
I'm at my wits' end and I'd greatly appreciate some help if anybody would be willing.
What function? Are you thinking of dfhack.gui.getSelectedUnit() or something else? If you have a unit selected in-game, there's no situation where that function wouldn't work.

so I take it open-legends doesn't break down on Advmode given the nature of that game loading and unloading maps?
I don't think that's a safe assumption. I don't know if anyone has ever even used it in adventure mode.
Title: Re: DFHack 0.44.12-r1
Post by: zaporozhets on July 22, 2018, 01:52:37 pm
What function? Are you thinking of dfhack.gui.getSelectedUnit() or something else? If you have a unit selected in-game, there's no situation where that function wouldn't work.

Something else, I have a unit ID provided through modtools/item-trigger //ATTACK_ID and I want to call dfhack.units.getUnit() (located in dfhack/Units.cpp at line 92) in order to get the unit object itself so I can pass it to dfhack.units.getPosition() all within my anonymous-script.

When the script tries to call dfhack.units.getUnit() I get the error "(anonymous lua script):1: attempt to call a nil value (field 'getUnit')" and I don't know why.
Could the function be outside of the scope of anonymous-script for some reason? I am not a smart man.

I hope I've explained the problem better. Thanks.
Title: Re: DFHack 0.44.12-r1
Post by: Putnam on July 22, 2018, 02:04:29 pm
For that you want df.unit.find(id).
Title: Re: DFHack 0.44.12-r1
Post by: zaporozhets on July 22, 2018, 02:33:55 pm
For that you want df.unit.find(id).
Yes! I could kiss you. Whereabouts is "unit" located, though? I can't seem to find it to take a look.
Title: Re: DFHack 0.44.12-r1
Post by: Putnam on July 22, 2018, 02:44:01 pm
df.unit is a type; you'll find there's similar functions for historical figures, buildings, nemesis records and basically anything else with an ID.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on July 22, 2018, 03:16:27 pm
When the script tries to call dfhack.units.getUnit() I get the error "(anonymous lua script):1: attempt to call a nil value (field 'getUnit')" and I don't know why.
Could the function be outside of the scope of anonymous-script for some reason? I am not a smart man.
The function doesn't exist, and has never existed. "Attempted to call a nil value" means the thing you're trying to call (right before the parentheses) is nil, similar to "undefined" in other languages, and therefore can't be called.

I'm not sure where you're looking to find "df.unit.find" - it's a function, much like dfhack.units.[anything](), and is defined by DFHack as well - it doesn't have a location, whatever that means.
Title: Re: DFHack 0.44.12-r1
Post by: zaporozhets on July 22, 2018, 04:37:34 pm
The function doesn't exist, and has never existed. "Attempted to call a nil value" means the thing you're trying to call (right before the parentheses) is nil, similar to "undefined" in other languages, and therefore can't be called.

I'm new to doing anything like this, sorry if this is like pulling teeth with me.
Putnam solved it but I'm still curious, if I were to call "dfhack.units.getPosition(unit)" for example that would refer to dfhack/library/modules/Units.cpp line 131 "Units::getPosition(df::unit *unit)", right?

Why then am I not be able to refer to Units.cpp line 92 "*Units::getUnit (const int32_t index)" as dfhack.units.getUnit(index)?
I don't understand what you mean when you say the function doesn't exist when I can see it right there at line 92. Am I missing something fundamental? Go easy on me. ;)

I'm not sure where you're looking to find "df.unit.find" - it's a function, much like dfhack.units.[anything](), and is defined by DFHack as well - it doesn't have a location, whatever that means.

I was just wondering in which file in the dfhack directory the unit type (and find function) is defined, I guess 'location' is confusing or just plain wrong terminology. My apologies. Either way I'm further along to getting it working now. Thanks for the help.
Title: Re: DFHack 0.44.12-r1
Post by: Clément on July 22, 2018, 05:08:42 pm
There is no lua wrapper for getUnit, but there is one for getPosition. The wrappers are defined in library/LuaApi.cpp. But you should use the documentation (https://dfhack.readthedocs.io/en/stable/docs/Lua%20API.html#units-module) to see what functions are available.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on July 22, 2018, 05:38:32 pm
The function doesn't exist, and has never existed. "Attempted to call a nil value" means the thing you're trying to call (right before the parentheses) is nil, similar to "undefined" in other languages, and therefore can't be called.

I'm new to doing anything like this, sorry if this is like pulling teeth with me.
Putnam solved it but I'm still curious, if I were to call "dfhack.units.getPosition(unit)" for example that would refer to dfhack/library/modules/Units.cpp line 131 "Units::getPosition(df::unit *unit)", right?

Why then am I not be able to refer to Units.cpp line 92 "*Units::getUnit (const int32_t index)" as dfhack.units.getUnit(index)?
I don't understand what you mean when you say the function doesn't exist when I can see it right there at line 92. Am I missing something fundamental? Go easy on me. ;)

I'm not sure where you're looking to find "df.unit.find" - it's a function, much like dfhack.units.[anything](), and is defined by DFHack as well - it doesn't have a location, whatever that means.

I was just wondering in which file in the dfhack directory the unit type (and find function) is defined, I guess 'location' is confusing or just plain wrong terminology. My apologies. Either way I'm further along to getting it working now. Thanks for the help.
Sorry, I didn't realize you were looking in the C++ files - my mistake, "location" makes sense then. The C++ API is defined there. As Clément pointed out, exactly which functions are exposed to the Lua API are different, and defined in LuaApi.cpp (and the docs, assuming they're kept up-to-date).

For reference, df.unit.find() is in some file generated at compile time - it's generated because df.unit has an ID field, but it's not easy to locate the actual definition.

Edit: Also, Units::getUnit is useless and should never be used. It doesn't look up a unit by ID - it's literally just a wrapper to index world->units.all, and that's not indexed by ID (there are gaps)! It probably dates back to when DFHack was out-of-process and that sort of thing was necessary, but it's not necessary now, so the proper solution is to just remove it from DFHack entirely.
Title: Re: DFHack 0.44.12-r1
Post by: zaporozhets on July 22, 2018, 08:56:15 pm
I dislike gumming up the thread with stupid questions, but when:
Quote
modtools/anonymous-script "print(pos2xyz(dfhack.gui.getSelectedUnit().pos))"
returns something like: "83  86  4", which I'm pretty sure is three integers, why will modtools/spawn-flow not accept the resulting xyz as its location argument using something like:
Quote
modtools/spawn-flow -location [ modtools/anonymous-script "pos2xyz(dfhack.gui.getSelectedUnit().pos)" ] -flowType Mist
I get "spawn-flow.lua:82: Cannot write field coord.x: integer expected". Is the anonymous script failing to return the result to spawn-flow, or is really a type mismatch?

I may have to prepare for myself a dunce cap...
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on July 22, 2018, 09:05:11 pm
modtools/spawn-flow doesn't execute commands in its arguments - it isn't equipped to handle that, and neither are most scripts. It's trying to interpret the "location" argument literally as 2 strings:
Code: [Select]
modtools/anonymous-script
pos2xyz(dfhack.gui.getSelectedUnit().pos)
and can't turn either of those into numbers that it expects. (I think it also requires 3 numbers, in any case.)

The bracket syntax is just a way to pass multiple values under a single a command-line argument - it's not a special "execute this command" syntax.

You might have to modify spawn-flow for this (maybe add support for a -unit argument?).

Edit: you could also use dfhack.run_script() from modtools/anonymous-script, which would allow you to run things like spawn-flow with computed arguments (like a unit position), but that could quickly get messy, and I'm not sure if you would run into issues with nested quotes.
Title: Re: DFHack 0.44.12-r1
Post by: Meph on July 24, 2018, 03:53:39 am
Lethosor: yeah, a little warning popup about "dont do X" would be great. :)
Title: Re: DFHack 0.44.12-r1
Post by: hertggf on July 25, 2018, 01:58:32 pm
so I take it open-legends doesn't break down on Advmode given the nature of that game loading and unloading maps?
I don't think that's a safe assumption. I don't know if anyone has ever even used it in adventure mode.
In adventure mode the script can cause demons to escape from hell when you leave the area you ran open-legends in.  Other people have mentioned this so I thought it was well known.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on July 25, 2018, 02:40:06 pm
so I take it open-legends doesn't break down on Advmode given the nature of that game loading and unloading maps?
I don't think that's a safe assumption. I don't know if anyone has ever even used it in adventure mode.
In adventure mode the script can cause demons to escape from hell when you leave the area you ran open-legends in.  Other people have mentioned this so I thought it was well known.
I've literally never heard of that happening, ever. It certainly wasn't mentioned in this thread, which it should have been. Where did you see this? As this conversation has established, the issues caused by open-legends are not well-known.
Title: Re: DFHack 0.44.12-r1
Post by: hertggf on July 25, 2018, 04:49:25 pm
wew chill bro.  Come to think of it, I wonder if it's related to http://www.bay12games.com/dwarves/mantisbt/view.php?id=7216 and/or http://www.bay12games.com/dwarves/mantisbt/view.php?id=9499
Because I had those happen all the time back when I was using open-legends without thinking about it.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on July 25, 2018, 05:00:17 pm
If the open-legends issues result in corrupted map features only, they wouldn't explain the first one. It's more likely that they could explain the second one, so I left a comment there.

I admit I was a bit harsh there - it's hardly your fault that other people didn't tell us about these issues either. It's somewhat of a collective issue. If people don't report issues here or on the issue tracker (https://github.com/DFHack/dfhack/issues), we frequently don't know about them at all - there aren't enough of us to comb through the entire forums and other sites often enough.
Title: Re: DFHack 0.44.12-r1
Post by: Rumrusher on July 26, 2018, 10:04:45 am
so I take it open-legends doesn't break down on Advmode given the nature of that game loading and unloading maps?
I don't think that's a safe assumption. I don't know if anyone has ever even used it in adventure mode.
In adventure mode the script can cause demons to escape from hell when you leave the area you ran open-legends in.  Other people have mentioned this so I thought it was well known.
hmm this didn't hit me that this could happen as revealing the world also kinda unleashes demons from hell
then again I'm currently playing a DF modded world that tamed demons through Animal tokens so I couldn't tell if it's the Script or just tamed demons roaming about.
doesn't help every time an unleashed random demon pop up it's when I'm trying to do passive simple non violent runs of DF like being a fortress guard.
Title: Re: DFHack 0.44.12-r1
Post by: Gooblin on July 29, 2018, 07:16:25 am
Not sure if this is the right place for this as it's related to the biome-manipulator script, but whenever I try to use the morph in the Geo Manipulation mode of biome-manipulator nothing happens, either when trying to either type the name of layer or selecting the layer through the list of options. I'm posting this in the dfhack thread because when trying to type I get an error message related to the gui plugin in dfhack console:

Code: [Select]
...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:792: bad argument #1 to 'match' (string expected, got nil)
stack traceback:
        [C]: in function 'string.match'
        ...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:792: in method 'setFilter'
        ...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:813: in function <...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:812>
        [C]: in field 'on_change'
        ...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:166: in method 'onInput'
        ...top\Dorf\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui.lua:484: in method 'inputToSubviews'
        ...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:722: in method 'onInput'
        ...top\Dorf\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui.lua:484: in method 'inputToSubviews'
        ...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\dialogs.lua:224: in function <...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\dialogs.lua:217>
        [C]: in ?

I get this problem with a clean install of dwarf fortress 44.12 and the latest release of dfhack with nothing added but the biome-manipulator script itself. So I assume it should be completely reproducible.
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on July 29, 2018, 08:32:47 am
Not sure if this is the right place for this as it's related to the biome-manipulator script, but whenever I try to use the morph in the Geo Manipulation mode of biome-manipulator nothing happens, either when trying to either type the name of layer or selecting the layer through the list of options. I'm posting this in the dfhack thread because when trying to type I get an error message related to the gui plugin in dfhack console:

Code: [Select]
...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:792: bad argument #1 to 'match' (string expected, got nil)
stack traceback:
        [C]: in function 'string.match'
        ...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:792: in method 'setFilter'
        ...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:813: in function <...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:812>
        [C]: in field 'on_change'
        ...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:166: in method 'onInput'
        ...top\Dorf\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui.lua:484: in method 'inputToSubviews'
        ...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:722: in method 'onInput'
        ...top\Dorf\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui.lua:484: in method 'inputToSubviews'
        ...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\dialogs.lua:224: in function <...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\dialogs.lua:217>
        [C]: in ?

I get this problem with a clean install of dwarf fortress 44.12 and the latest release of dfhack with nothing added but the biome-manipulator script itself. So I assume it should be completely reproducible.
Please don't double post. When an issue is with a specific tool that has its own thread, its better to post the issue there (only), and if it turns out to be a deeper DFHack issue, the tool maintainer would then identify if there's actually a DFHack issue.
In this case it's a matter of an incorrect usage of a widget, and the issue has been fixed.
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on July 30, 2018, 06:40:19 am
Double posting (of the other type)... but it's a different question:
df.map.xml:feature_type has a number of values I've never seen and don't know what they are. Am I correct in assuming the "deep_surface_portal", "subterranean_from_layer", "magma_core_from_layer", and "underworld_from_layer" are obsolete features DF no longer generates?
Title: Re: DFHack 0.44.12-r1
Post by: xzaxza on July 31, 2018, 03:06:46 am
Hi,

I'm new. DFHack's pretty neat. Some of the documentation is bit poor though. :P

Also, I've noticed some... thingies. I don't have a github account, so.

Quote
embark-skills

Adjusts dwarves’ skills when embarking.

Note that already-used skill points are not taken into account or reset.
points N:   Sets the skill points remaining of the selected dwarf to N.
points N all:   Sets the skill points remaining of all dwarves to N.
max:   Sets all skills of the selected dwarf to “Proficient”.
max all:   Sets all skills of all dwarves to “Proficient”.
legendary:   Sets all skills of the selected dwarf to “Legendary”.
legendary all:   Sets all skills of all dwarves to “Legendary”.

Of that script, the points function doesn't seem to work. Similarly, this one doesn't work either:
Quote
points

Sets available points at the embark screen to the specified number. Eg. points 1000000 would allow you to buy everything, or points 0 would make life quite difficult.

And this one gave me some crashes:
Quote
prefchange

Sets preferences for mooding to include a weapon type, equipment type, and material. If you also wish to trigger a mood, see strangemood.

Valid options:
show:   show preferences of all units
c:   clear preferences of selected unit
all:   clear preferences of all units
axp:   likes axes, breastplates, and steel
has:   likes hammers, mail shirts, and steel
swb:   likes short swords, high boots, and steel
spb:   likes spears, high boots, and steel
mas:   likes maces, shields, and steel
xbh:   likes crossbows, helms, and steel
pig:   likes picks, gauntlets, and steel
log:   likes long swords, gauntlets, and steel
dap:   likes daggers, greaves, and steel

Feel free to adjust the values as you see fit, change the has steel to platinum, change the axp axes to great axes, whatnot.

If I used, say, the xbh option on a dwarf with too many preferences (possibly of certain type), the game would crash when viewing their thoughts and preferences ingame.

At least I managed to avoid the crashes after editing the source code a bit. I don't really understand how preferences work, but I patched up some new functions, like:
Code: [Select]
function clear_craft_preferences()
    local unit = dfhack.gui.getSelectedUnit()
    local prefs = unit.status.current_soul.preferences
    local crafttype = 4
    local count = 0

    local kk,vv,unk_counter
    unk_counter=31415926

    for kk,vv in ipairs(prefs) do
        if vv.type == crafttype then
            vv.type = -1
            vv.item_type = -1
            vv.creature_id = -1
            vv.color_id = -1
            vv.shape_id = -1
            vv.plant_id = -1
            vv.item_subtype = -1
            vv.mattype = -1
            vv.matindex = -1
            vv.active = false
            vv.prefstring_seed = unk_counter
            count = count + 1
            unk_counter = unk_counter + 1
        end
    end
    print(count.." crafting preferences cleared.")
end
Code: [Select]
function clear_material_preferences()
    local unit = dfhack.gui.getSelectedUnit()
    local prefs = unit.status.current_soul.preferences
    local material = -1
    local count = 0

    local kk,vv,unk_counter
    unk_counter=31415926

    for kk,vv in ipairs(prefs) do
        if vv.mattype == material then
            vv.type = -1
            vv.item_type = -1
            vv.creature_id = -1
            vv.color_id = -1
            vv.shape_id = -1
            vv.plant_id = -1
            vv.item_subtype = -1
            vv.mattype = -1
            vv.matindex = -1
            vv.active = false
            vv.prefstring_seed = unk_counter
            count = count + 1
            unk_counter = unk_counter + 1
        end
    end
    print(count.." material preferences cleared.")
end

So err, I had a save with a dwarf working in a strange mood, always resulting in a bone battle axe, and I wanted to see if I could change the end result to something little less stupid. Clearing all of his preferences would've felt wrong, so I wanted to clear only type == 4 preferences, as they seemed to be what mattered at that point, possibly to restore them after the artifact was finished. The latter function was useful in another case, where I guess a dwarf preferred too many materials or something.

The script seems fairly buggy overall, for example, it's possible to get the same preference twice.

There is (was) also no option to show preferences of selected unit only, and the output isn't extremely human-readable either. Is there a resource containing information of the preferences stuff? I perhaps could be bothered to edit out a script that'd check if a preference exists before setting it, allow exporting/importing a dwarf's preference "identity" and allow setting/clearing a single preference (instead of these groups of three preferences). Unless such thing exists already? At least the dfhack scripts I've seen seem to concentrate on optimizing preferences, but I personally dislike the idea of ruining the uniqueness in that.

[edit: now that I gave a closer look to the latter of those two functions... there's an equality condition where there should be inequality condition, so it clears preferences with which the material doesn't matter. Oh well.]
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on July 31, 2018, 08:45:14 am
Hi,

I'm new. DFHack's pretty neat. Some of the documentation is bit poor though. :P

Anything specifically? Feel free to suggest improvements - I can't guarantee that I can improve docs for tools I'm unfamiliar with, but other people might.

"embark-skills points" and "points" are separate, but I think they work on the same screen, so it's possible that DFHack's layout for that screen is wrong (I don't remember checking that one). I'll investigate.

I'm pretty sure preferences are just stored in a vector, so I can't think of an obvious reason why adding "too many" would crash, or why "too many" would even be a possible state. Maybe the preferences it makes are malformed sometimes? In any case, that script is garbage (many hardcoded options for arbitrary preference combinations, lots of duplicated code, etc.), so it'd probably have to be rewritten some anyway.

Edit: you need to run "points" on the embark site-choosing screen (before the screen where you select items). That works in 0.44.12 for me. I can probably add support for the item-choosing screen too, but I can't support anything before a world is loaded, since the relevant field (df.global.world.worldgen.worldgen_parms.embark_points) is reset to the world-specific value when a world is loaded.

Edit: fixed "embark-skills points" as well. Its other options appeared to work fine.
Title: Re: DFHack 0.44.12-r1
Post by: Meph on July 31, 2018, 03:02:21 pm
How would you run points (and startdwarf)  from an init file in that case?  Can you just add it to the onload.init, or do you need to specify when it runs somehow?
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on July 31, 2018, 04:00:04 pm
Startdwarf is completely different and will work from anywhere because it patches code, which only needs to be done once.
You could probably run points from onLoadWorld.init, like other things that require a world to be loaded. I'm not sure exactly when that runs, but it should be after world general params are loaded.
Title: Re: DFHack 0.44.12-r1
Post by: Saiko Kila on August 01, 2018, 07:16:19 am
I have an issue with syndrome effect value, specifically with the "end". If I want to show other named value, like "start", I can print for example
Code: [Select]
~df.global.world.raws.syndromes.all[123].ce[0].startHowever, I cannot do it with end, since it's a reserved keyword in Lua (and technically it shouldn't be used at all for names). Invoking this will cause error:
Code: [Select]
~df.global.world.raws.syndromes.all[123].ce[0].end
So, any smart way to list this value with a script?
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 01, 2018, 07:19:27 am
Replace .end with ["end"]
Title: Re: DFHack 0.44.12-r1
Post by: Saiko Kila on August 01, 2018, 08:13:52 am
Replace .end with ["end"]

Thanks, it works.
Title: Re: DFHack 0.44.12-r1
Post by: baldamundo on August 01, 2018, 01:19:28 pm
Hey guys, longtime player/luker/fan of DF and all her utilities.

Couple questions:

How interested would you guys be in an updated(graded) make-monarch script?
I've used the underlying logic to make the script applicable to all noble positions in entity.positions.own ("MONARCH", "DUKE", "COUNT", "BARON", "DIPLOMAT", "GENERAL", "LIEUTENANT", "CAPTAIN", "OUTPOST_LIAISON") and made it so that you can "demote" a unit without raising another.

Spoiler (click to show/hide)

(dead group barons borking my site's progression and "inhereted" barons were the impetus for the script if you were wondering).

I noticed the github repo doesn't have a contributing guidelines, so here I am rather than just doing a PR. Also the original make-monarch doesn't have any licensing attached to it, so while I'd be happy to release under a GNU GPLv3 I'm not quite sure if that's kosher.



With the above script in mind; What do we know about the event(s) concering elevating a fortress (barony/county/duchy)?

Ideally, I'd like to have the script elevate the fort if you assign a position you're not yet on, but I've failed in finding anything relevant.

How would you need to modify this to work with mod added civs with different noble positions?

Have gotten as far as editing the first part so it recognises the position as valid, but then it still throws a "Could not find position ID" error.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on August 01, 2018, 03:05:13 pm
Is the 'prospect' command compiled into dfhack or is it implemented (or implementable?) via python or ruby script?

And if the latter, can it be made to run during pre-embark on an arbitrary area of the world, or does it rely on reading memory that the game only populates for the actually currently selected embark zone?
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on August 01, 2018, 04:49:19 pm
Is the 'prospect' command compiled into dfhack or is it implemented (or implementable?) via python or ruby script?

And if the latter, can it be made to run during pre-embark on an arbitrary area of the world, or does it rely on reading memory that the game only populates for the actually currently selected embark zone?
"prospector.cpp" (which is the name of the plugin, but not the command it implements) is a compiled plugin, but I don't think there's anything preventing the logic from being implemented in script (I've copied parts of the logic at various time for use in my scripts).

"prospect" has to be run where sufficient context has been loaded for some data to be accessed, but it is capable of running pre embark, where it makes an estimate rather than a tally of what's actually there. However, it's possible to have a script change the context by providing simulated movement key input, causing the region_details structure to load the mid level tile info for the current world tile.
Title: Re: DFHack 0.44.12-r1
Post by: Quietust on August 01, 2018, 10:00:20 pm
"prospector.cpp" (which is the name of the plugin, but not the command it implements) is a compiled plugin, but I don't think there's anything preventing the logic from being implemented in script (I've copied parts of the logic at various time for use in my scripts).

Converting the post-embark version of prospector to a Lua script would be a bad idea, because it iterates across every single map tile in order to count up all of the details - it would "work", but it'd take a rather long time to run (i.e. measured in minutes). The pre-embark version, on the other hand, would probably work just fine as a script.
Title: Re: DFHack 0.44.12-r1
Post by: thefriendlyhacker on August 02, 2018, 05:50:01 am
Hello, it is me again. I am having a few problems.

Spoiler: spoiled for length (click to show/hide)
EDIT: I tried fixing the error in the siege engine lua code.  There is another error - math.pow on line 175 is throwing an "attempted to call a nil value" error. I just checked using the dfhack console lua interpreter, and the function math.pow doesn't exist.
Title: Re: DFHack 0.44.12-r1
Post by: Rose on August 02, 2018, 08:18:40 am
Is there a list of what body parts have what clothing layers in them, or do I just need to calculate it from the inventory?
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 02, 2018, 01:25:54 pm

First off, the siege engine plugin is throwing an error.

Code: [Select]
... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:166: Cannot read field unit.relations: not found.
stack traceback:
[C]: in metamethod '__index'
... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:166: in function 'plugins.siege-engine.getBaseUnitWeight'
... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:174: in function 'plugins.siege-engine.getUnitWeight'
... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:182: in local 'get_weight'
... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:191: in function 'plugins.siege-engine.scoreTargets'
... Redux 07.26 - v0.41.4\hack\lua\plugins\siege-engine.lua:295: in function 'plugins.siege-engine.doAimProjectile'
[C]: in ?
I took a quick gander at the lua code for siege-engine and checked it against the current data structure for units.  It looks like the unit.relations vector and the fields within it were renamed at some point but siege-engine wasn't updated to match.
That was renamed a long time ago. It should be unit.relationship_ids.GroupLeader instead - does that work for you?

Edit: almost 2 years: https://github.com/DFHack/df-structures/commit/25cb373055257532c0a3df2faa7aa68d17f7b853
Quote
Second, there is a problem with reaction-trigger.  When a work order is placed (either through jobs/manager or by placing a work order in the individual workshop), commands are not executed/syndromes are not applied unless the reaction is the last one in the work order e.g. if I run the command "modtools/reaction-trigger -reactionName MAKE_PEARLASH -command [ devel/print-args "test" ]", place an order for 3 "make pearlash", the first and second reactions carried out at the kiln will not print anything, while the third will print "test".  I extracted a fresh vanilla df+dfhack copy and did a bit of printlining, and it looks like the function in eventful.onJobCompleted.reactionTrigger is only called on the last reaction in a work order (which would mean that the underlying bug is in eventful).
This is probably because since the new manager in 0.43, manager-created jobs have an "order" flag set on them, and there's just one per workshop (which is done repeatedly until the order is completed), rather than many jobs based on what was requested in the manager. I'm not familiar enough with the script to fix it quickly - any takers?
Quote
Thirdly, I am having weird intermittent problems with creating pets via modtools/create-unit.  Sometimes the game will crash shortly after creating a unit.  On one occasion, I also saw a created pet get into a full on fight with a citizen a while after it was created (with attack interactions used by the pet and melee weapons by the citizen).  I made an attempt to reproduce the above bugs by spamming workshop reactions that run create-unit through reaction-trigger (which is how I normally use create-unit), but they didn't happen again.  However, after leaving DF to run for a few minutes while this was going on, the game for some reason decided to consume about 17GB of memory (FYI, I have 16GB of ram), after which I had to kill DF because it was making my operating system unstable.  I have never seen anything like that happen before.
Sounds like something triggered undefined behavior that would usually crash (e.g. reading from a string that isn't actually a string) but you got unlucky.

Are you using the -setUnitToFort argument, or anything else to adjust civ IDs? Better question: how exactly are you running create-unit (what arguments)?

Quote
Lastly, as a minor little thing I noticed, should the field "maker_race" in items be renamed something else?  AFAICT it just controls the sizing of an item.  The var name maker_race seems like a misnomer when dwarf produced, human sized equipment will have "maker_race" equal to the ID for humans.
No idea how this stuff works, but if you test other combinations (e.g. human-produced dwarf-size equipment) and they behave the same, feel free to submit a PR or suggest a new name here.

Quote
EDIT: I tried fixing the error in the siege engine lua code.  There is another error - math.pow on line 175 is throwing an "attempted to call a nil value" error. I just checked using the dfhack console lua interpreter, and the function math.pow doesn't exist.
Geez, has nobody used siege-engine in the past 2 years? math.pow was replaced with the ^ operator when we switched to Lua 5.3 in 0.43.05 - try that.
Title: Re: DFHack 0.44.12-r1
Post by: thefriendlyhacker on August 02, 2018, 10:03:22 pm
...
That was renamed a long time ago. It should be unit.relationship_ids.GroupLeader instead - does that work for you?
Yep, that fixed the error.
Quote
math.pow was replaced with the ^ operator when we switched to Lua 5.3 in 0.43.05 - try that.
Ok, did that. There was also one other place where pow was used instead of ^.  After replacing both of them with ^, I fired about 30 ballista rounds at a siege that showed up at the perfect moment without any errors or other problems.  Hopefully that is it for siege-engine bugs.
Quote
Geez, has nobody used siege-engine in the past 2 years?
Bear in mind that this doesn't show up if you just play around with siege-engine a bit using unskilled operators.  I tried embarking in vanilla to test a couple of things, lucked out and landed on top of a Roc lair, and fired ballista bolts at both the Roc and a herd of boars for a while without any errors.  I had to dig around in the c++ code to figure out why, but dabbling operators can't aim at specific creatures (only an area), and the buggy code is only executed when weighting targets for the random target creature selection algorithm.  You have to fire a siege weapon with a trained operator at an area containing creatures to get an error thrown.
Quote
Are you using the -setUnitToFort argument, or anything else to adjust civ IDs? Better question: how exactly are you running create-unit (what arguments)?
Here are the relevant script calls:
Code: [Select]
foe/reaction-trigger -reactionName DEPLOY_MINE_HE -command [ modtools/create-unit -race LANDMINE -caste HE -domesticate -location [ \\LOCATION ] ]
foe/reaction-trigger -reactionName MANUFACTURE_PROTECTAPONY_MINIGUN -command [ modtools/create-unit -race PROTECTAPONY_MINIGUN -caste NORMAL -domesticate -location [ \\LOCATION ] ]
foe/reaction-trigger -reactionName MANUFACTURE_SPRITEBOT -command [ modtools/create-unit -race SPRITEBOT -caste MALE -domesticate -location [ \\LOCATION ] ]
FYI foe/reaction-trigger is literally just modtools/reaction-trigger with bug fixes/expanded functionality (which doesn't matter in this case).  I put the code for it here (http://www.bay12forums.com/smf/index.php?topic=171191.msg7813840#msg7813840) a couple of weeks back, if you want to take a look.

Now that you mention it, the script call has -domesticate but not -setUnitToFort.  Going by the lua code for create-unit, -setUnitToFort sets the civ and group ID to your fort's, while -domesticate only sets the group ID. I just created a unit to confirm it, and gui/gm-editor says that it's civ_id is -1.  That might be the problem.  I will add -setUnitToFort to my create-unit calls and see if it fixes things.
Title: Re: DFHack 0.44.12-r1
Post by: Saiko Kila on August 03, 2018, 04:03:30 am
Geez, has nobody used siege-engine in the past 2 years?
Bear in mind that this doesn't show up if you just play around with siege-engine a bit using unskilled operators.  I tried embarking in vanilla to test a couple of things, lucked out and landed on top of a Roc lair, and fired ballista bolts at both the Roc and a herd of boars for a while without any errors.  I had to dig around in the c++ code to figure out why, but dabbling operators can't aim at specific creatures (only an area), and the buggy code is only executed when weighting targets for the random target creature selection algorithm.  You have to fire a siege weapon with a trained operator at an area containing creatures to get an error thrown.

I think the most important reason was the long-standing bug which caused crashes when using siege ammo (and weapon traps). It was introduced in June 2016, and fixed only in late November 2017. Most people stopped using siege engines because of that.
Title: Re: DFHack 0.44.12-r1
Post by: iceball3 on August 03, 2018, 04:33:29 am
I wonder, is there existing or a possibility of a dfhack command that can work during worldgen or other high-lag states, that allow dfhack to inject a keyboard input on the next frame that DF advances? For instance, allowing one to pause worldgen's time advancement in it's tracks when the worldgen has become laggy enough to start ignoring key inputs. A similar case could be asked in times of extreme DF Fortmode lag, where it's difficult to regain control as the game doesn't seem to like listening for key inputs when a frame is taking more than a few seconds to pass.
Title: Re: DFHack 0.44.12-r1
Post by: Putnam on August 03, 2018, 04:40:03 am
Code: [Select]
dfhack.timeout(1,'frames',function() gui.simulateInput(dfhack.gui.getCurViewscreen(),tostring(...)) end)
there's a one-liner that should work, replace "..." with the code of whatever key you want pressed OR save it to a file and have the key's code as the argument to what you saved it as
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on August 03, 2018, 05:20:30 am
I think it should work to just set the "paused" flag appropriate to the mode in DF, as I think DF will detect the flag's changed state on the next frame.
Title: Re: DFHack 0.44.12-r1
Post by: Putnam on August 03, 2018, 05:33:54 am
i'm not sure that's advisable, since i'd apply chesterton's fence (https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence) to worldgen ending 3 years after pressing the enter key (i.e. if you press enter on year 497, it'll let you finish at 500); then again, it's possible just setting that flag will also do the same
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on August 03, 2018, 07:26:36 am
I avoid interrupting the worldgen with enter and always use ESC, as enter after world gen means accept, which might be what Putnam refers to.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 03, 2018, 09:19:04 am
I'm pretty sure "a" is accept.

I wonder, is there existing or a possibility of a dfhack command that can work during worldgen or other high-lag states, that allow dfhack to inject a keyboard input on the next frame that DF advances? For instance, allowing one to pause worldgen's time advancement in it's tracks when the worldgen has become laggy enough to start ignoring key inputs. A similar case could be asked in times of extreme DF Fortmode lag, where it's difficult to regain control as the game doesn't seem to like listening for key inputs when a frame is taking more than a few seconds to pass.
This is exactly what the "fpause" command is for - it's worked in fortress mode since before I joined, and it supports worldgen now too (as of 0.44.10-alpha1). No need to roll your own for this.

I think the most important reason was the long-standing bug which caused crashes when using siege ammo (and weapon traps). It was introduced in June 2016, and fixed only in late November 2017. Most people stopped using siege engines because of that.
I don't remember seeing this linked to siege ammo on the weapon tracker - I think the main reason is that siege engines aren't used much, due to limitations which the plugin intends to address. Also, there were longstanding compatibility issues with TWBT (fixed in DFHack 0.43.05-r2) which may have discouraged people who insisted on TWBT from using it.

Ok, did that. There was also one other place where pow was used instead of ^.  After replacing both of them with ^, I fired about 30 ballista rounds at a siege that showed up at the perfect moment without any errors or other problems.  Hopefully that is it for siege-engine bugs.
Ok, I think I fixed it in https://github.com/DFHack/dfhack/blob/1c137f9a358ff01346567cc0354b2096599428e5/plugins/lua/siege-engine.lua . If you could double-check and make sure my fixes work, since you're good at reproducing it, that'd be great.
Quote
Bear in mind that this doesn't show up if you just play around with siege-engine a bit using unskilled operators.  I tried embarking in vanilla to test a couple of things, lucked out and landed on top of a Roc lair, and fired ballista bolts at both the Roc and a herd of boars for a while without any errors.  I had to dig around in the c++ code to figure out why, but dabbling operators can't aim at specific creatures (only an area), and the buggy code is only executed when weighting targets for the random target creature selection algorithm.  You have to fire a siege weapon with a trained operator at an area containing creatures to get an error thrown.
Yeah, I figured it was something non-trivial - I played with it a bit when testing the above TWBT fixes, but probably not enough to trigger that. Thanks for the explanation.
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on August 04, 2018, 06:40:54 am
'a' is "abort" and "Enter" is "Accept" at the end of world gen. 'a' is "abort" during an interrupted world gen, while 'u' is "use as is" and 'c' is "continue". Both "Enter" and "ESC" can be used to interrupt world gen. (This hasn't stopped me from trying to 'a'ccept generated worlds, with disappointing effects, though).
Title: Re: DFHack 0.44.12-r1
Post by: iceball3 on August 04, 2018, 08:59:10 am
I wonder, is there existing or a possibility of a dfhack command that can work during worldgen or other high-lag states, that allow dfhack to inject a keyboard input on the next frame that DF advances? For instance, allowing one to pause worldgen's time advancement in it's tracks when the worldgen has become laggy enough to start ignoring key inputs. A similar case could be asked in times of extreme DF Fortmode lag, where it's difficult to regain control as the game doesn't seem to like listening for key inputs when a frame is taking more than a few seconds to pass.
This is exactly what the "fpause" command is for - it's worked in fortress mode since before I joined, and it supports worldgen now too (as of 0.44.10-alpha1). No need to roll your own for this.
Nice! That's good to hear, thank you.
Title: Re: DFHack 0.44.12-r1
Post by: zaporozhets on August 04, 2018, 10:34:27 pm
With regards to the Modtools 'special args' (such as '\\PROJECTILE_ID' in projectile-trigger), what is the proper usage of \\anything and can it be used to access other fields (say args.projectile.origin_pos rather than args.projectile.id)?
I've tried a few things and searched around, otherwise I wouldn't ask.
Perhaps it would be easier for me to simply modify projectile-trigger to supply the field I want as \\ORIGIN_POS but I felt I should ask first.

On a related note, using projectile-trigger with two marksdwarves in the testing arena in this way:
Code: [Select]
modtools/projectile-trigger -material INORGANIC:IRON -command [ modtools/anonymous-script "print(df.unit.find(tonumber(args[1])).pos)" \\FIRER_ID ]
is seemingly at random outputting some coords and some "attempt to index a nil value (field 'firer')" error throws.
This does not happen when \\PROJECTILE_ID is called instead. Why does not every projectile that's impacting have a firer?

Thanks for all the work you guys put in.
Title: Re: DFHack 0.44.12-r1
Post by: Putnam on August 04, 2018, 11:11:49 pm
Each individual script manually implements any \\ arguments and should list all that are possible.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 04, 2018, 11:43:52 pm
Backslashes were a poor decision... really, internally, they're stored as single backslashes, but the DFHack console requires escaping them with backslashes so that they don't get interpreted as something else. They also have to be written as "\\" in Lua for the same reason. I've seen mentions of mods that need to use even more backslashes due to passing arguments through other scripts, which really shouldn't be necessary.

Does anyone have suggestions on other characters that could be used instead (that aren't commonly used in other arguments)? Maybe "!" or something similar? I know that changing this entirely could pose a challenge for some mods, and I'm not sure I'm comfortable with all of the modtools scripts, but maybe we could support both \ and another option for a while and see what happens.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on August 05, 2018, 12:40:48 am
Preamble: Have not used the modtools triggers.

! is not in some languages, so that's not ideal.

@, #, and ~ are already used with lua. Hm, don't really know an use for ¤, though? (I know £ isn't on every keyboard, however, so that one is a bad choice. Not sure about ¤.)

I've seen _ having been used before for internal stuff elsewhere, which kinda matches this usage, but I don't know if it has particular significance in lua. As every keyboard has it, it might be best?

Documentation uses `for commands iirc, that might be another possibility to consider.
Title: Re: DFHack 0.44.12-r1
Post by: Putnam on August 05, 2018, 12:49:37 am
¤ is nowhere on my keyboard and i have no idea what it represents; @# and ~ being in lua already are moot, since we're talking about strings here
Title: Re: DFHack 0.44.12-r1
Post by: Meph on August 05, 2018, 02:27:30 am
If you replace the backslashes with another icon, PLEASE support both.

Completely scrapping the old way of reaction trigger with the newer version was... jarring, to say the least. At least when you have a mod that relies on around a thousand entries of it.
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on August 05, 2018, 03:38:57 am
¤ is nowhere on my keyboard and i have no idea what it represents; @# and ~ being in lua already are moot, since we're talking about strings here
'¤' is a generic currency sign, but I'm not aware of it being used for anything anywhere, so it's rather pointless.
Title: Re: DFHack 0.44.12-r1
Post by: thefriendlyhacker on August 05, 2018, 04:53:16 am
Ok, I think I fixed it in https://github.com/DFHack/dfhack/blob/1c137f9a358ff01346567cc0354b2096599428e5/plugins/lua/siege-engine.lua . If you could double-check and make sure my fixes work, since you're good at reproducing it, that'd be great.
I got around to testing siege-engine.  I fired about 50 rounds at a siege, and rounds were getting aimed correctly with no errors being thrown in the process.  The code changes themselves look right too.  I think everything is good.

As an aside, wow siege weapons are weak against well armored invaders - 200lb chunks of iron thrown into a siege blob should not be pulling a few ligaments and bouncing harmlessly off bronze torso armor.

Oh, and -setUnitToFort seems to have fixed my create-unit woes.  No crashes, no DF eating my memory, no fighting between spawned pets and citizens, no other bizarre behavior.  Thanks.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on August 05, 2018, 10:27:59 am
@Putnam: ah well on ¤. IMHO expressions like #("#") is bit of a 'you can, but should you?"; even before considering typos with them being functional, but on the wrong side of " (thus possibly doing something like passing same number each time, but not throwing an error).
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 05, 2018, 11:50:47 am
If you replace the backslashes with another icon, PLEASE support both.

Completely scrapping the old way of reaction trigger with the newer version was... jarring, to say the least. At least when you have a mod that relies on around a thousand entries of it.
It should be a find-and-replace matter - not sure what exactly happened with reaction-trigger, as I'm not involved with modtools scripts much. I don't mind supporting both for a while, but eventually (if we go down this route) I'll probably introduce warnings and then remove backslash support, to discourage people from using it and complaining when things don't work because they need 8 backslashes for it to work.

Hm, don't really know an use for ¤, though?
Turns out this is the one symbol you mentioned that I've never even seen before. It's definitely not on American keyboards, and unlike £, I'm not even sure how to type it on my keyboard. I'd rather stick with ASCII characters, but thanks for the input.

By the way, it doesn't really matter what's used in Lua here, or any language for that matter, because the arguments aren't run through an interpreter. Also, "#" and "~" are the only real Lua (unary) operators - we implemented "@" and "!" (and "~" and "=") as shortcuts in the DFHack Lua interpreter, but those are only checked in the first character of the input line. We can definitely use ! and @ for anything we want - the others are ok too, but "#" could break because it marks comments in DFHack commands and would need to be escaped (leading to things like "\\\#" instead, potentially).
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on August 05, 2018, 12:51:35 pm
Och, good I didn't mention more obscure options not visible on my keyboard.

Hm, I'm curious: What do ! and = do, here? Lua API docs don't mention single-character commands.
Title: Re: DFHack 0.44.12-r1
Post by: Clément on August 05, 2018, 02:45:17 pm
I don't find them in the doc, but it is the help message when entering the lua console:
Code: [Select]
[DFHack]# lua
Type quit to exit interactive lua interpreter.
Shortcuts:
 '= foo' => '_1,_2,... = foo'
 '! foo' => 'print(foo)'
 '~ foo' => 'printall(foo)'
 '^ foo' => 'printall_recurse(foo)'
 '@ foo' => 'printall_ipairs(foo)'
All of these save the first result as '_'.
Title: Re: DFHack 0.44.12-r1
Post by: Meph on August 05, 2018, 05:07:03 pm
Maybe I'm blind, but what happened to item-syndrome?

Was it merged into item-trigger?
Title: Re: DFHack 0.44.12-r1
Post by: thefriendlyhacker on August 05, 2018, 05:14:25 pm
Maybe I'm blind, but what happened to item-syndrome?

Was it merged into item-trigger?
Use item-trigger + add-syndrome.  Here is an example for an item that provides a constant buff:
Code: [Select]
modtools/item-trigger -itemType ITEM_ARMOR_POWER -onEquip [ Worn ] -command [ modtools/add-syndrome -syndrome "power armor" -target \\UNIT_ID  -resetPolicy DoNothing ]
modtools/item-trigger -itemType ITEM_ARMOR_POWER -onUnequip [ Worn ] -command [ modtools/add-syndrome -syndrome "power armor" -erase -target \\UNIT_ID ]
Title: Re: DFHack 0.44.12-r1
Post by: Splint on August 06, 2018, 07:11:05 am
I don't suppose there will ever be something that can address rain-induced stress will there? Surface living near any body of water is all but impossible because of it, and this seemed like the place to ask, given the utility of the brainwash script with problem dwarves and soldiers.

EDIT: Let me be clear, I know it's easier to just shut off weather, but I'd prefer that not be a requirement to settle near anything remotely resembling a coastline or lake.

Title: Re: DFHack 0.44.12-r1
Post by: Meph on August 07, 2018, 06:26:03 am
Thanks both to Lethosor and the friendlyhacker for the quick replies. :)
Title: Re: DFHack 0.44.12-r1
Post by: taleden on August 07, 2018, 02:36:19 pm
Would it be possible for dfhack to add any or all of these?


For managing a poultry industry I find it convenient to cage all hatchlings until they're ready for slaughter, but right now there's no way to mark an animal for slaughter from the same screen that says whether they're caged (i.e. the ones I want to slaughter) or uncaged (i.e. the breeders I want to leave in their pasture). I've been using Dwarf Therapist so far but it'd be nice to have it in-game, plus I'm always unsure what order DT is listing things in; I like that the in-game animal lists are sorted by arrival date (which becomes a proxy for animal age after the industry is up and running).
Title: Re: DFHack 0.44.12-r1
Post by: AVE on August 07, 2018, 02:49:00 pm
Why not use autobutcher (https://dfhack.readthedocs.io/en/stable/docs/Plugins.html#autobutcher)? It butchers oldest adults and youngest kids (in order to allow oldest kids to became adult faster) and there is no need for caging (it actually completely ignores caged animals).
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 07, 2018, 03:31:29 pm
  • "Slaughter" (and possibly "Geld"?) hotkeys and corresponding flag indicators to the (q)Building menu of a built cage
This one already exists as "tweak cage-slaughter". The rest would be possible, although possibly hard to fit in the UI, and I'm not sure if just setting the relevant flags is enough to trigger jobs.
Title: Re: DFHack 0.44.12-r1
Post by: carewolf on August 07, 2018, 03:35:12 pm
Has anyone ever made script to watch for clothes/armor shortages? it is always hard to know how much you need to make of stuff to make your dwarves stop running around in rags.
Title: Re: DFHack 0.44.12-r1
Post by: Warmist on August 08, 2018, 02:09:50 am
Has anyone ever made script to watch for clothes/armor shortages? it is always hard to know how much you need to make of stuff to make your dwarves stop running around in rags.

Imho vanilla df job manager works very well in that case (e.g. just order that there would be 5 non-decayed, robes - each picked up would lower it and job would restart)
Title: Re: DFHack 0.44.12-r1
Post by: taleden on August 08, 2018, 08:21:06 am
Why not use autobutcher (https://dfhack.readthedocs.io/en/stable/docs/Plugins.html#autobutcher)? It butchers oldest adults and youngest kids (in order to allow oldest kids to became adult faster) and there is no need for caging (it actually completely ignores caged animals).
The problem with autobutcher is actually precisely that it can't discriminate by caged status. Birds lay a lot of eggs and I don't want the FPS hit of having up to 300 of them running around (pop cap 50 for each of 6 bird species), so I prefer to just cage all the hatchlings since they don't need to graze anyway. But when those hatchlings mature in the cages, autobutcher will happily slaughter my (older) breeding adults in the pasture and "replace" them with (younger) adults in the cages, which I'd then have to manually put back in the pasture every 3 months so they could lay new eggs. Besides which, managing slaughters is not that big a deal that it requires full automation, it's just a little tedious now because not all the relevant information is on one screen.

  • "Slaughter" (and possibly "Geld"?) hotkeys and corresponding flag indicators to the (q)Building menu of a built cage
This one already exists as "tweak cage-slaughter". The rest would be possible, although possibly hard to fit in the UI, and I'm not sure if just setting the relevant flags is enough to trigger jobs.
Oh, neat, I'll give that a try.

That raises are more general question though: what's the criteria for which of the various tweaks and UI extensions are enabled by default (i.e. labor manager, tweak eggs-fertile) and which are hidden behind commands that have to be run explicitly every time (i.e. embark-assistant, tweak cage-butcher)?
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 08, 2018, 09:10:37 am
That raises are more general question though: what's the criteria for which of the various tweaks and UI extensions are enabled by default (i.e. labor manager, tweak eggs-fertile) and which are hidden behind commands that have to be run explicitly every time (i.e. embark-assistant, tweak cage-butcher)?
Actually, labormanager is not enabled by default, and tweak cage-butcher is. Maybe you're using a pack that has overridden these? labormanager is a play-style preference that shouldn't be forced on everyone by default. Also, tweak eggs-fertile was disabled for being too "cheaty" until https://github.com/DFHack/dfhack/pull/970 - I didn't remember accepting that, but apparently I did.

(tweak cage-butcher only has to be run once on startup to be enabled, and that's what's in the default dfhack.init-example. Not sure if that's what you meant by "run explicitly each time" - it doesn't have to be run every time you want to butcher something.)

In general, there are only a few categories of tools that are enabled by default:
- things that are fairly uncontroversially improvements (tweak stable-cursor, tweak burrow-name-cancel, tweak kitchen-prefs-all, search, etc.)
- things that, when enabled, only add options in-game to start using them, but don't actually do anything until then (manipulator, autogems, autochop, automelt, autotrade, etc.)
- bugfixes
- keybindings (that don't conflict with vanilla keys and are unlikely to be triggered accidentally)
Title: Re: DFHack 0.44.12-r1
Post by: taleden on August 08, 2018, 10:40:07 am
Actually, labormanager is not enabled by default, and tweak cage-butcher is.
Oh, when I wrote labormanager I guess I meant manipulator; I think I got them mixed up since the title bar of the manipulator interface says "Manage Labors", which of course is what it lets me do. :)

And you're right, cage-butcher is enabled and I somehow completely failed to notice those extra hotkeys down there. I guess I was looking for them up by the "a: Assign" and "+-: Select" labels. So that'll suffice for my needs, thanks and sorry to bother! Though I still think it'd be neat to have the extra hotkeys/indicators on the units and stocks pages too; as to whether setting the flag is sufficient to generate the job, if it works for cage-butcher, it must be doable elsewhere.

In general, there are only a few categories of tools that are enabled by default:
- things that are fairly uncontroversially improvements (tweak stable-cursor, tweak burrow-name-cancel, tweak kitchen-prefs-all, search, etc.)
- things that, when enabled, only add options in-game to start using them, but don't actually do anything until then (manipulator, autogems, autochop, automelt, autotrade, etc.)
- bugfixes
- keybindings (that don't conflict with vanilla keys and are unlikely to be triggered accidentally)
Has a case been made already for embark-assistant to be enabled by default, or at least enable-able with a red hotkey on the pre-embark screen so more people realize it exists? It seems to me that it's a straight upgrade over the vanilla site finder; it can do all the same things and more, without forcing the user to employ any of its extra filters. The main objection I could think of is maybe some folks don't want to know in advance what ores are present, but I can't imagine it would be too hard to leave that part of it off by default and give it a separate hotkey for people who want to display that information.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 08, 2018, 10:53:18 am
If by enabling embark-assistant you mean running it every time the embark screen shows up, that would negatively impact user experience, for one thing, since you'd have to press "esc" twice after (seemingly) entering the embark screen to get to the options menu (i.e. you have to "exit" a screen you didn't explicitly enter). It also has some screen size requirements, and would display poorly for people with smaller screens.

Adding an option to enter it in the UI should definitely be doable, though.

For butcher/slaughter indicators, my concern about the unit list is a lack of available space, but I can look at it. What "stocks page" are you referring to? The vanilla z -> Animals screen definitely has both a slaughter and geld option, and I'm not aware of a separate one (even provided by DFHack) that lists animals.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on August 08, 2018, 11:21:16 am
If by enabling embark-assistant you mean running it every time the embark screen shows up, that would negatively impact user experience, for one thing, since you'd have to press "esc" twice after (seemingly) entering the embark screen to get to the options menu (i.e. you have to "exit" a screen you didn't explicitly enter). It also has some screen size requirements, and would display poorly for people with smaller screens.
Doesn't look that way to me; when I run "embark-assistant" all that happens at first is the "f: Find Desired Location" label disappears from the bottom area (because it's replaced by new hotkeys on the right), the new i/f/c/q hotkeys appear on the right, and the layers/materials details appear below the local map. A single "esc" still goes directly to the options menu; the only previous behavior that changes is "f" opens the advanced site finder instead of the stock one, but that's exactly the point. :)

As for screen space it seems to work just fine down to 80 columns wide (which looks like the minimum supported by the embark screen as a whole), but I see your point that embark-assistant doesn't do well at 25 rows; it looks like it expects at least 33 rows for its right-hand hotkeys and probably 35-40 rows to accommodate the layer materials on the left, under the local map. So that's an issue, but probably solvable by the author by simply cutting off the materials list before it runs into the bottom text area; the right-hand hotkeys should be easy enough to fold into the bottom area if it were enabled by default, since "q" wouldn't be needed any more, "f" and "c" could be combined into the space where the original "f" hotkey was displayed (that's how the default finder works -- it's "f" until you search, then turns into "c" to clear those results), which leaves only "i" to squeeze in probably just to the right of "n: Notes".

Adding an option to enter it in the UI should definitely be doable, though.

But all that aside, yeah, even just displaying a hotkey to activate it I think would be great. Whenever anyone mentions embark-assistant in any thread I've seen, invariably a bunch of people reply "oh wow I didn't even know that existed!", so just presenting the option would probably satisfy a desire that a lot of users don't even realize they have. :)

For butcher/slaughter indicators, my concern about the unit list is a lack of available space, but I can look at it. What "stocks page" are you referring to? The vanilla z -> Animals screen definitely has both a slaughter and geld option, and I'm not aware of a separate one (even provided by DFHack) that lists animals.
I think even at 80 columns the unit list has enough space to stick a little 2 or 4 character "Sl"/"Ge" or "Sltr"/"Geld" flag over on the right side, and hotkey labels on the bottom row just to the right of the ones DFHack already adds ("l: Manage Labors (DFHack)" and "q: Search").

On the stocks page (z->Animals) yes the slaughter/geld options and flags are there, what's missing on that page is the restrained/caged/pastured status indicator, which I think there's be plenty of room for alongside the existing flags ("D" for Domesticated, "T" for train, "W" for war; just add "R" for restrained, "C" for caged, "P" for pastured?).
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on August 08, 2018, 10:19:09 pm
  • "Slaughter" (and possibly "Geld"?) hotkeys and corresponding flag indicators to the (u)Units:Pets/Livestock page
This would be relatively easy (haven't looked at other pages). For hotkeys, just add these into dfhack.init:
Code: [Select]
keybinding add S@unitlist/Livestock ":lua dfhack.gui.getSelectedUnit().flags2.slaughter = not dfhack.gui.getSelectedUnit().flags2.slaughter"
keybinding add X@unitlist/Livestock ":lua if(not dfhack.units.isFemale(dfhack.gui.getSelectedUnit())) then dfhack.gui.getSelectedUnit().flags3.unk29 =  not dfhack.gui.getSelectedUnit().flags3.unk29 end"
These keys are also used by native suspend job/remove worker hotkeys, but my pets don't do jobs.

Making it properly scrollable, clickable ui is bit annoying (I've done two recently for jobs and death dates, but it's a bit much when there's already dwarf therapist - kinda replicating existing stuff there), but for just hotkeys that I can give you with just two lines (well, 1 after smushing) utilizing gui/indicator_screen (http://www.bay12forums.com/smf/index.php?topic=167495):
Code: [Select]
keybinding add U@dwarfmode/Default ":lua dfhack.script_environment('gui/indicator_screen').getScreen({{text =  function() if(dfhack.gui.getCurFocus():find('Livestock')) then return 's' else return '' end end, color = (8+COLOR_RED), notEndOfLine=true}, {text =  function() if(dfhack.gui.getCurFocus():find('Livestock')) then return ': slaughter  ' else return '' end end, color = function() if (#df.global.gview.view.child.child.units[df.global.gview.view.child.child.page]>0 and dfhack.gui.getSelectedUnit().flags2.slaughter) then return COLOR_YELLOW else return COLOR_WHITE end end}},{x=47, y = -3, width=14}):show()  dfhack.script_environment('gui/indicator_screen').getScreen({{text = function() if(dfhack.gui.getCurFocus():find('Livestock')) then return 'x' else return '' end end, color = COLOR_LIGHTRED, notEndOfLine=true}, {text =  function() if(dfhack.gui.getCurFocus():find('Livestock')) then return ': geld            ' else return '' end end, color = function() if (#df.global.gview.view.child.child.units[df.global.gview.view.child.child.page]<1) then return COLOR_DARKGREY else if (dfhack.gui.getSelectedUnit().flags3.unk29) then return COLOR_YELLOW elseif(dfhack.units.isFemale(dfhack.gui.getSelectedUnit()) or dfhack.units.isGelded(dfhack.gui.getSelectedUnit())) then return COLOR_DARKGREY else return COLOR_WHITE end end end}},{x=62, y = -4, width=16}):show()"
(Also into dfhack.init)
Tbh checking for units state already makes it rather longer than 1-2 lines oughta, but ah well.

  • "Slaughter" (and possibly "Geld"?) hotkeys and corresponding flag indicators to the (q)Building menu of a built cage
This one already exists as "tweak cage-slaughter". The rest would be possible, although possibly hard to fit in the UI, and I'm not sure if just setting the relevant flags is enough to trigger jobs.
Yeah, I've gelded and butchered people (pfft) just by setting the flag. (flags3.unk29, flags2.slaughter)

|(https://i.imgur.com/LFMXUp1.png)|
|(https://i.imgur.com/UeZfAq3.png)|
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 08, 2018, 11:40:04 pm
If unk29 is the geld flag, that should be changed to a proper name (and ideally you would mention it rather than just using it in scripts). As for the long line - yeah, you're probably better off giving that as a script, because it's awfully hard to troubleshoot something like that.

Edit: ok, flag 28 is called "gelded". Is flag 29 "to be gelded" or something, or did we just get 28 wrong entirely?

Taleden, maybe I was mistaken about how to exit embark-assistant, but it does replace vanilla functionality and has an "exit" option of some kind, which would be confusing if an "enter" action wasn't taken. I put the UI option idea in the issue tracker, so hopefully I remember to get to it. Also, keybindings wouldn't be as good as UI additions because they wouldn't be visible to the user in-game at all.

I think even at 80 columns the unit list has enough space to stick a little 2 or 4 character "Sl"/"Ge" or "Sltr"/"Geld" flag over on the right side, and hotkey labels on the bottom row just to the right of the ones DFHack already adds ("l: Manage Labors (DFHack)" and "q: Search").

On the stocks page (z->Animals) yes the slaughter/geld options and flags are there, what's missing on that page is the restrained/caged/pastured status indicator, which I think there's be plenty of room for alongside the existing flags ("D" for Domesticated, "T" for train, "W" for war; just add "R" for restrained, "C" for caged, "P" for pastured?).
Drawing indicators in the middle of the unit list is a bit tricky because of highlighting (and figuring out where dwarves are displayed on the screen). Fitting in the options at the bottom shouldn't be hard, now that I'm actually looking at the screen.
For the "z" -> Animals screen, that makes a lot more sense, since gelding and butchering options and flags are already displayed. However, it does not appear be trivial to figure out where individual animals or the column with flags are displayed on-screen, let alone how many flags are displayed next to each unit. We might also need to put a legend somewhere to avoid confusion, since the displayed flags currently are only related to training status.
Title: Re: DFHack 0.44.12-r1
Post by: Rose on August 08, 2018, 11:45:04 pm
How hard would it be to display a warning every time an unk of anon variable is referred to via script?
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on August 09, 2018, 02:57:28 am
How hard would it be to display a warning every time an unk of anon variable is referred to via script?
Not a good idea!
I use unk variables for five reasons:
1. Because I'm trying to figure out what they do (which may eventually lead to a pull request for naming).
2. Because the pull request for the naming of the fieldI've submitted hasn't materialized in a new DFHack release yet.
3. Because I want scripts to support older version where the variable wasn't yet named (using variant pathing).
4. A pull request naming the field hinges on restructuring the mess the relevant part of the XML is, but nobody is willing to discuss it, so it will probably happen only when someone else makes the pull request to fit it into the existing mess, which can take time.
5. Because I don't understand what it does, but whoever wrote it originally seems to get it right but didn't name it (e.g. prospector's usage of an unk field for ocean biomes to determine whether they are rock or soil supporting. Prospector is a plugin, not a script, though, but my usage of the logic shows up both in scripts and in a plugin).

You're free to make a tool to scan scripts (and code) for "unk" indications, look at the results, and bug those you can find behind the scrips/code about the issue, though.
Title: Re: DFHack 0.44.12-r1
Post by: thefriendlyhacker on August 09, 2018, 03:19:35 am
If unk29 is the geld flag, that should be changed to a proper name (and ideally you would mention it rather than just using it in scripts). As for the long line - yeah, you're probably better off giving that as a script, because it's awfully hard to troubleshoot something like that.

Edit: ok, flag 28 is called "gelded". Is flag 29 "to be gelded" or something, or did we just get 28 wrong entirely?
...
unk 29 in flags3 is set to true when gelded is toggled through the normal DF ui.

After a citizen takes a flagged unit to the farmer's workshop to be gelded, unk 29 in flags3 is set to false, appropriate changes are made in body, and gelded in flags3 is set to true. Setting gelded in flags3 to false lets you reorder gelding in the DF ui. Going by that, it looks like the variable gelded aka flag 28 is "has been gelded", and unk 29/flag 29 is "marked for gelding".

By the way, the changes in body include "23" in body.components.body_part_status[1] being set to "true".  Since there is also a gelding wound in the wounds section to the same body part(1), which I assume to be the lower torso of the dog I was testing this on, and I can't see any named variable that would correspond to a gelding injury in the body part status, I think 23 may be the body part status flag for that body part suffering a gelding blow.  In any case, it serves some sort of purpose related to gelding.
Title: Re: DFHack 0.44.12-r1
Post by: Saiko Kila on August 09, 2018, 05:21:58 am
About the modtools/extra-gamelog.lua... I love the soundsense utility, and am relying on this script to make better use of soundsense. I commented about issues with this script some moths ago, but then modified my own version and used it since. Recently I tested the version in current release (0.44.12-r1), and noticed that it still doesn't work mostly, unfortunately.

The main issues are:

There are also some minor issues, like logging everything at once (once the other issues are resolved), which is particularly troublesome with nobles and with buildings built, and logging a specific line when besieged, regardless if this line is appropriate (undead sieges have different line).

For these reasons I suggest to change the script to something like this:
Spoiler (click to show/hide)
(The line 170 171 can be integrated into the next if statement, it's excluded here to show better.)

This causes every part to trigger when necessary, it seems, with some caveats:


EDIT: replaced the script, in previous version I managed to include the older version (specifically the log_siege() was old, it wasn't working correctly with load and reload of save without exiting the game).
Title: Re: DFHack 0.44.12-r1
Post by: taleden on August 09, 2018, 11:02:31 am
Taleden, maybe I was mistaken about how to exit embark-assistant, but it does replace vanilla functionality and has an "exit" option of some kind, which would be confusing if an "enter" action wasn't taken. I put the UI option idea in the issue tracker, so hopefully I remember to get to it. Also, keybindings wouldn't be as good as UI additions because they wouldn't be visible to the user in-game at all.

Yeah, looking more closely at the embark-assistant site finder options, it would need a few more tweaks to ensure that it is strictly an enhancement and completely replicates all vanilla functionality (i.e. right now it cannot search by elevation as such, although it can search for waterfalls or for flat embark zones). But if that were done then I think it would not need the "exit" option at all any more, since the only vanilla functionality that it masks is "f: Find Desired Location"; it might need a toggle to display the more detailed layer/ore information to satisfy folks who consider that a spoiler, but it could otherwise just stay on.

Meanwhile, when I suggested the interim hotkeys or keybinding to toggle it on, I meant to also imply the UI addition to make the user aware of the option, i.e. "a: Enable Advanced Finder"; I agree of course a hotkey with no on-screen label would be no better than the current situation, the whole idea there was to make more users aware of the existence of the tool. :)
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 09, 2018, 11:51:13 am
Taleden, maybe I was mistaken about how to exit embark-assistant, but it does replace vanilla functionality and has an "exit" option of some kind, which would be confusing if an "enter" action wasn't taken. I put the UI option idea in the issue tracker, so hopefully I remember to get to it. Also, keybindings wouldn't be as good as UI additions because they wouldn't be visible to the user in-game at all.

Yeah, looking more closely at the embark-assistant site finder options, it would need a few more tweaks to ensure that it is strictly an enhancement and completely replicates all vanilla functionality (i.e. right now it cannot search by elevation as such, although it can search for waterfalls or for flat embark zones). But if that were done then I think it would not need the "exit" option at all any more, since the only vanilla functionality that it masks is "f: Find Desired Location"; it might need a toggle to display the more detailed layer/ore information to satisfy folks who consider that a spoiler, but it could otherwise just stay on.

Meanwhile, when I suggested the interim hotkeys or keybinding to toggle it on, I meant to also imply the UI addition to make the user aware of the option, i.e. "a: Enable Advanced Finder"; I agree of course a hotkey with no on-screen label would be no better than the current situation, the whole idea there was to make more users aware of the existence of the tool. :)
My "hotkey with no on-screen label" remarks were about Fleeting Frames' slaughter/geld suggestions, not related to yours at all.

I'm confused about why an "a: Advanced Finder" option isn't good enough (from your comments in the embark-assistant thread (http://www.bay12forums.com/smf/index.php?topic=169634.msg7827305#new)). embark-assistant isn't an always-on tool that needs to be enabled once - it's a tool that users run specifically when they want it. It's like manipulator - I have no problem whatsoever adding an option to an existing screen to use it, but replacing the units screen with manipulator would be confusing. It's possible that Patrik wasn't familiar with how to modify existing screens - not all plugin authors do it.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on August 09, 2018, 12:06:29 pm
I think "a: Advanced Finder" is certainly good enough. It's the only good approach right now while embark-assistant has issues at < 35 rows and doesn't fully replicate *all* vanilla finder options, and on reflection you're probably right that an explicit toggle will always be preferable to just running it all the time, since the vanilla finder should always remain available as a fallback option in case a bug is found in embark-assistant. But even in that case I think it could use some tweaks to UI element placement (including removal of "q: Exit" since it could be replaced with "a" as a toggle), hence my comment in its thread.
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on August 09, 2018, 03:25:27 pm
As indicated, I don't know how to modify existing screens, just how to overlay things on top of it. I was aware that it was possible, but haven't looked into how it's done, partially because I thought it safer to use an active opt-in before having any idea if the tool would be well received or not. An integrated toggle sounds like a good idea, though.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on August 09, 2018, 04:54:28 pm
@lethosor: Once it becomes a script (or needs troubleshooting), there's less justification to make it a proper handling UI :P

I've never seen the location of dwarves/animals/etc. in unit list change, though. It's always been scrollable list, maximum length of df height - 9, sorted into pages (for scrolling, I've used both changing text on scrolling and adjusting its y1 position with currentpage*pagelength). Are there exceptions I'm not aware of?

hotkeys with no on-screen label...It works fine for me for some things like toggle water level or set job material, but I've forgotten about sort-units so thoroughly I noticed I didn't account for it in relations-indicator when sorting units by death date and displaying these dates (oops *tosses to the growing TODO pile*).


@known unk#s

Not aware of what I suggested though. Submitting a pull request with naming unk29?

I've known about unk29 since months before releasing relations-indicator (had to have some way to test for sterility), but I cba to log into github for something so minor. The script would still have to use the flag for reasons PatrikLundell said.

On a whim, I might mention that other known unit unk#s might be, by any chance, found in Gorlak dancer, please join us (http://www.bay12forums.com/smf/index.php?topic=165187.30).

While oldmansutton supposedly posted a year ago, gui/gm-editoring a visitor in 44.10 I still notice obvious flags like flags3.unk31.
Title: Re: DFHack 0.44.12-r1
Post by: bwbill on August 10, 2018, 08:57:33 am
I think "a: Advanced Finder" is certainly good enough.

Just about anything but "a", please! I already hit that key accidentally on occasion in worldgen, and don't want to train my fingers to seek it any more than they already do. I'd suggest shift-f instead.
Title: Re: DFHack 0.44.12-r1
Post by: Trotskisaurus on August 11, 2018, 03:30:17 am
I'm sorry if this is a stupid question, i've tried searching for the answer but I haven't been able to find one. I have ran one or two of the 'deteriorate' scripts but i'm unsure whether these are permenantly stored once ran or if they need to be activated each time a game is loaded.

I work strange hours so I have the habit of playing the game, saving it onto a memory stick by coping the region data in the save file, and then using that to continue the game when i'm on another computer; should I be running the scripts each time?

Is there a simple way to see which scripts are and are not running?
Title: Re: DFHack 0.44.12-r1
Post by: feelotraveller on August 12, 2018, 09:17:12 am
dfhack-0.44.12-r1-Linux-64-gcc-7

tweak hotkey-clear is misbehaving (for me)

Firstly no matter what hotkey is selected 'c' clears the F1 hotkey.
Secondly when 'c' is used in a name it clears the F1 hotkey (and does not appear in the name).
Title: Re: DFHack 0.44.12-r1
Post by: Rafatio on August 12, 2018, 12:16:43 pm
dfhack-0.44.12-r1-Linux-64-gcc-7

tweak hotkey-clear is misbehaving (for me)

Firstly no matter what hotkey is selected 'c' clears the F1 hotkey.
Secondly when 'c' is used in a name it clears the F1 hotkey (and does not appear in the name).
Not linux specific, happens on the windows version too.
Title: Re: DFHack 0.44.12-r1
Post by: Stiqy on August 15, 2018, 04:33:34 pm
I don't think there is a thread just for labormanager... but just have one small request.... that it be able to be disabled on a per-dwarf basis (by something simple like ignoring dwarfs that have the unused "Alchemist" labor set.)
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 15, 2018, 07:48:36 pm
(I was away for a few days - sorry for delays)
dfhack-0.44.12-r1-Linux-64-gcc-7

tweak hotkey-clear is misbehaving (for me)

Firstly no matter what hotkey is selected 'c' clears the F1 hotkey.
Secondly when 'c' is used in a name it clears the F1 hotkey (and does not appear in the name).
Yeah, some stuff was added to "ui" in 0.44.12, and it's entirely in the wrong place - it appears to be related to the issue that broke squads in df-ai in 0.44.12. More details here: https://github.com/DFHack/dfhack/issues/1393 - obviously this is something we want to fix for r2.

I don't think there is a thread just for labormanager... but just have one small request.... that it be able to be disabled on a per-dwarf basis (by something simple like ignoring dwarfs that have the unused "Alchemist" labor set.)
I feel like this may have been suggested before. https://github.com/DFHack/dfhack/issues/185 is a similar suggestion for autolabor - out of curiosity, does labormanager also skip dwarves in burrows? I haven't checked.

One thing to note - "tweak block-labors" will prevent toggling alchemy.

I'm sorry if this is a stupid question, i've tried searching for the answer but I haven't been able to find one. I have ran one or two of the 'deteriorate' scripts but i'm unsure whether these are permenantly stored once ran or if they need to be activated each time a game is loaded.

I work strange hours so I have the habit of playing the game, saving it onto a memory stick by coping the region data in the save file, and then using that to continue the game when i'm on another computer; should I be running the scripts each time?

Is there a simple way to see which scripts are and are not running?
They are not "permanently stored" (I mean, the script files themselves are permanently stored on disk in hack/scripts, but their enabled status is not stored in any way, like most tools'). You'll need to run them every time you load a save where you want them to be run. However, you can do this automatically by either putting the commands in onLoad.init in your DF folder (if you want them to apply to every save), or data/save/regionX/raw/onLoad.init if you want them run in individual save(s). Create those files as needed; more details at  https://dfhack.readthedocs.io/en/latest/docs/Core.html#init-files. (Particularly if you go with a global .init file for this, you might need to use onMapLoad.init to avoid errors with those scripts in worldgen.)

There is no centralized place where scripts' enabled statuses are tracked, mainly because scripts currently have no way of reporting this. You can view the status of plugins that can be enabled by running "enable" with no arguments (https://dfhack.readthedocs.io/en/latest/docs/Core.html#enable), though. A few Lua scripts can also be enabled with the enable command ("enable scriptname" instead of, or as well as, "scriptname enable"), although they have no way of reporting their status back, so they're not listed either.
Title: Re: DFHack 0.44.12-r1
Post by: ab9rf on August 15, 2018, 09:00:06 pm
I don't think there is a thread just for labormanager... but just have one small request.... that it be able to be disabled on a per-dwarf basis (by something simple like ignoring dwarfs that have the unused "Alchemist" labor set.)
Assigning a dwarf to a burrow (even if the burrow covers the entire embark) will cause that dwarf to be entirely ignored by labormanager (see https://github.com/DFHack/dfhack/blob/develop/plugins/labormanager/labormanager.cpp#L1333). I had no reason to remove that behavior (which I added to autolabor many many moons ago: https://github.com/ab9rf/dfhack/commit/78fc850ce20e14d7a37e44c18dc4486ee61796b4) when I forked autolabor to make labormanager.

I don't want to use the ALCHEMY labor for this purpose; there are other people who are using it for incompatible purposes, and, as lethosor points out, "tweak block-labors" prevents toggling the ALCHEMY labor.
Title: Re: DFHack 0.44.12-r1
Post by: Bob69Joe on August 16, 2018, 02:28:51 pm
Is there a script to 'T'ravel through mountains?
Title: Re: DFHack 0.44.12-r1
Post by: taleden on August 16, 2018, 09:28:06 pm
Is there something I can run in the dfhack console to advance the game N steps, as if pressing "." that many times? I've been doing some mechanics timing tests and it sure is tedious counting "." presses manually. :)
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on August 17, 2018, 03:44:45 am
I use :lua dfhack.timeout(N, "ticks", function () dfhack.run_command('fpause') end)

Also something similar in a script (http://dwarffortresswiki.org/index.php/User:Fleeting_Frames#cposchange) for minecarts.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on August 17, 2018, 08:27:42 am
I use :lua dfhack.timeout(N, "ticks", function () dfhack.run_command('fpause') end)

Also something similar in a script (http://dwarffortresswiki.org/index.php/User:Fleeting_Frames#cposchange) for minecarts.
Great, thanks! I wrapped that in a little script so I can type "step 10" for example and it seems to work, with two quirks: I have to manually unpause the game after issuing the command in order for it to then step forward N frames, and after it does so it prints "The game was forced to pause!" as if this were cause for concern. Is there any way to make my script automatically unpause the game after setting the pause timer, and to trigger that timer without the associated warning text?
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 17, 2018, 08:49:51 am
Use "df.global.pause_state = true" instead of "dfhack.run_command('fpause')". run_command() is slow and should only be used when there is no other option. Also, "df.global.pause_state = false" will unpause the game, so you could run this before (or after) the call to dfhack.timeout.

Is there a script to 'T'ravel through mountains?
I'm not aware of one. It might be simple to do if there's a way to bypass the checks in the adventure mode UI, or it might be incredibly complicated if there isn't. The adventure mode UI hasn't been researched much.

Edit: Fleeting Frames: I fixed your script display at http://dwarffortresswiki.org/index.php/User:Fleeting_Frames/cposchange (didn't change any contents). <code> is an inline element that should only be used for short fragments, never more than part of a line. Use <pre> for multi-line code blocks.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on August 17, 2018, 08:58:09 am
Use "df.global.pause_state = true" ... Also, "df.global.pause_state = false"
Thanks, this works perfectly!
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on August 17, 2018, 09:40:35 am
@lethosor: Awesome. I looked at formatting help, but didn't notice it.

Also noted on run_command. I guess importing the script with script_environment is better?
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 17, 2018, 09:59:00 am
You should ideally use reqscript() which ensures that the script claims it's safe to import (with a "--@ module=true" comment). Or use run_script() if you just want to run the script, which avoids jumping back and forth between C++ and Lua. However, neither of those will work for things that aren't Lua scripts, like fpause.

(Also, script_environment should never be used to run a script - it only actually runs the body of the script, which populates the script environment, if the script has never been loaded or has changed since it was last loaded. If you're relying on things that run when the script is loaded, it won't work - use run_script() instead.)
Title: Re: DFHack 0.44.12-r1
Post by: Saiko Kila on August 18, 2018, 05:23:24 am
In the 32-bit version of DF/dfhack on Windows, two plugins cannot be enabled: search and stocks. It's in version 0.44.12-r1:

Could not enable plugin: search
Could not enable plugin: stocks


These plugins work in the 64-bit version of DF/dfhack. I've got it on Vista x64, haven't tested other versions of Windows.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 18, 2018, 09:20:27 am
Are you sure you're using a clean installation? Can you upload your stderr.log?
Title: Re: DFHack 0.44.12-r1
Post by: Saiko Kila on August 18, 2018, 09:51:16 am
I've got something like this as stderr.log :
Spoiler (click to show/hide)

This is a clean installation, just contents of df_44_12_win32.zip overwritten with contents of dfhack-0.44.12-r1-Windows-32.zip.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 18, 2018, 11:30:04 am
Ah, it's because the vtable-address-finding script failed for viewscreen_storesst. Can you enter the z->stocks screen, then search for "viewscreen_storesst" near the end of stderr.log?

For reference, in symbols.xml, this is the problem:
Code: [Select]
        <!-- CONFLICT vtable-address name='viewscreen_storesst' value='0x1e4c23c or 0x1e4b994 or 0xf694f8'/ -->
It should be something like
Code: [Select]
        <vtable-address name='viewscreen_storesst' value='0xSOMETHING'/>
and stderr.log should contain the appropriate line to replace it - please let us know what this is.
Title: Re: DFHack 0.44.12-r1
Post by: Saiko Kila on August 18, 2018, 12:01:41 pm
Yes, the line is
Code: [Select]
<vtable-address name='viewscreen_storesst' value='0xf694f8'/>
When I replaced the line in symbols.xml then plugins apparently work.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 18, 2018, 12:44:03 pm
What does "apparently" mean? Does the search option show up in the stocks screen, and does the "e"xtended stocks screen work? If so, then they work, as far as I'm concerned.
Title: Re: DFHack 0.44.12-r1
Post by: Saiko Kila on August 18, 2018, 01:22:52 pm
What does "apparently" mean? Does the search option show up in the stocks screen, and does the "e"xtended stocks screen work? If so, then they work, as far as I'm concerned.

Apparently means I have never used stocks plugin, so don't know how it works. It's just that there is no error in console anymore.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 18, 2018, 01:23:58 pm
Ok, then can you check the things I asked about (z->stocks->'s'earch and 'e'xtended view)? If those don't crash, then it's fine.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on August 18, 2018, 03:27:26 pm
@lethosor: Thanks noting run_script, didn't know of/had forgotten it.

And yeah, intended to mean loading with script_environment (in this context, most of what you'd load would lack the module comment), then executing functions therein - good to clarify and note failure conditions (that I didn't consider, having not used so far for this purpose).
Title: Re: DFHack 0.44.12-r1
Post by: Saiko Kila on August 18, 2018, 03:52:59 pm
Ok, then can you check the things I asked about (z->stocks->'s'earch and 'e'xtended view)? If those don't crash, then it's fine.

Search plugin definitely works, and pressing "e" (or CTRL+SHIFT+Z) invokes extended view.
Title: Re: DFHack 0.44.12-r1
Post by: Rumrusher on August 19, 2018, 02:52:22 am
Is there a script to 'T'ravel through mountains?


Doesn't really allow for escaping from the mountains if you're in there, it's more of a 'now I can cross through a mountain in a straight line, or cross a river or cut through a town or city that block access off. there's a "warp me to a different spot" script but uhh kinda tricky to pull off constantly given the new quest log making you have to press Q-M to get free access to the map instead of being able to warp to the hotspot or point of interest.
Title: Re: DFHack 0.44.12-r1
Post by: Kat on August 19, 2018, 03:04:05 am
how well is dwarfvet working now ? been a while since I used it, but it had a tendency to crash if enabled.
Title: Re: DFHack 0.44.12-r1
Post by: Putnam on August 19, 2018, 05:14:11 am
not sure how useful this might be, but

Code: [Select]
utils=require('utils')

validArgs = utils.invert({
 'reaction',
 'skill',
 'level'
})

args = utils.processArgs({...}, validArgs)

if not (args.skill and args.reaction and args.level) then qerror("Must have -level, -reaction and -skill arguments!") end

require('plugins.eventful').onReactionComplete[skillRequirement..args.reaction]=function(reaction,reaction_product,unit,input_items,input_reagents,output_items,call_native)
    if dfhack.units.getEffectiveSkill(unit,df.job_skill[args.skill])<=tonumber(args.level) then
        call_native.value=false
        dfhack.gui.makeAnnouncement('CANCEL_JOB',{D_DISPLAY=true},unit.pos,dfhack.TranslateName(dfhack.units.getVisibleName(unit)..' cancels '..reaction.name..': not skilled enough.',COLOR_RED,true))
    end
end

should make there be a minimum skill level for a given reaction to go through, that's about it, simple enough, easy syntax i hope, though i could be misunderstanding what "reaction" is referring to
Title: Re: DFHack 0.44.12-r1
Post by: Kat on August 19, 2018, 06:40:37 am
Also, I saw there's a "cannibalism" script now, to unmark things as having "dead_dwarf" so that they can be butchered. Works in fortress mode, looking at a corpse's detail, which is fine for megabeasts and such, but with goblins, it's a bit less convenient, as there are many corpses to go through. Is it possible to make it so that it would work with all items under the cursor ?
Title: Re: DFHack 0.44.12-r1
Post by: Roses on August 22, 2018, 02:22:22 pm
Question about script_environment. I currently use it quite extensively to call functions from scripts and from other functions and it works great, but I am wondering what information the functions that I call have access to. For example if I had a lua file set up like
Code: (functions.lua) [Select]
somevalue = 0
function blahblah()
 -- Do something with the function
end
and call it from a script like
Code: (somescript.lua) [Select]
-- Script stuff
dfhack.script_environment('functions').blahblah()
-- More script stuff
will the function blahblah know what the value of somevalue is?

EDIT: Another question, I am almost positive the answer is no, but are there keyword arguments (such as in python) in lua or should I use tables if I want to simulate keyword arguments?
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 22, 2018, 02:33:27 pm
Absolutely. blahblah() always has access to its containing environment regardless of where it's called from.
Note that in the example you gave, re-running functions.lua (e.g. if you ran it at the command prompt) would reset somevalue to 0 ("somevalue = somevalue or 0" would avoid that). script_environment() usually won't reset that, but it might if the script file is modified. run_script() is what the DFHack console actually uses to run Lua scripts, I think, so it should always reset that.
Title: Re: DFHack 0.44.12-r1
Post by: Roses on August 22, 2018, 02:39:33 pm
Absolutely. blahblah() always has access to its containing environment regardless of where it's called from.
Note that in the example you gave, re-running functions.lua (e.g. if you ran it at the command prompt) would reset somevalue to 0 ("somevalue = somevalue or 0" would avoid that). script_environment() usually won't reset that, but it might if the script file is modified. run_script() is what the DFHack console actually uses to run Lua scripts, I think, so it should always reset that.

I was planning on just using somevalue as a static/parameter (C/Fortran) value so no functions would ever change it, but if I do decide to make it a changing value I'll make sure to keep in mind that it will reset under certain circumstances.

EDIT: Looking through the currently written scripts I see there is full-heal which can heal and resurrect units (and it seems regrow limbs and such). Are there any scripts that replicate the animation of units and unit corpse pieces? I am going over some of the stuff I wrote which allows for more complex resurrections and reanimations, but it would be nice to have other working examples to go off of.

EDIT2: Or other wound heal scripts that aren't quite so full? Particularly ones that heal but don't necessary regrow lost limbs.
Title: Re: DFHack 0.44.12-r1
Post by: fortunawhisk on August 22, 2018, 10:18:00 pm
Hi, I'm trying to retrieve the default belief values for a civilization, but I'm having a hard time determining how to get to them.
I can see them with gm-editor here: "gui/gm-editor world.cultural_identities.all". Unfortunately, I can't seem to get LUA to recognize the same location, and all my attempts fail with "attempt to index a nil value".
I've seen Atkana's script on setting them, but the location used there doesn't seem to work either (df.cultural_identity.find(upers.cultural_identity).values[beliefId]).
Can anyone throw out a lua print statement that dumps out the contents of "world.cultural_identities.all[0].values"?
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on August 22, 2018, 10:26:43 pm
EDIT: Looking through the currently written scripts I see there is full-heal which can heal and resurrect units (and it seems regrow limbs and such). Are there any scripts that replicate the animation of units and unit corpse pieces? I am going over some of the stuff I wrote which allows for more complex resurrections and reanimations, but it would be nice to have other working examples to go off of.

EDIT2: Or other wound heal scripts that aren't quite so full? Particularly ones that heal but don't necessary regrow lost limbs.
If you mean in DFHack, no. We almost never make duplicate copies of tools just to remove features from one copy. If you want to modify full-heal to take more options to skip certain steps (I think there are some already), feel free, and feel free to submit a pull request as well.

I can see them with gm-editor here: "gui/gm-editor world.cultural_identities.all". Unfortunately, I can't seem to get LUA to recognize the same location, and all my attempts fail with "attempt to index a nil value".
Can you specify where exactly you're using this and what you've attempted? If you're literally using "world.cultural_identities.all" in a Lua script ("Lua" isn't an acronym, by the way), that won't work - you'll need to replace "world" with "df.global.world". A few scripts, such as the Lua interpreter (run "lua") and gui/gm-editor search for undefined variables in other places, including fields in df.global (so the "df.global." part can be dropped), but in normal scripts that won't work.
Quote
I've seen Atkana's script on setting them, but the location used there doesn't seem to work either (df.cultural_identity.find(upers.cultural_identity).values[beliefId]).
That looks like it should work to me. What exactly is the issue? Obviously "upers" needs to be defined as well, and I'm not sure what it's supposed to be (it's not an English word, at least).

Minor nitpick, but that's also just an expression - there's no location in there.
Quote
Can anyone throw out a lua print statement that dumps out the contents of "world.cultural_identities.all[0].values"?
(In case you're unaware, printall() might produce more useful output - it's also available as the "~" prefix in the Lua interpreter.)
Title: Re: DFHack 0.44.12-r1
Post by: Atkana on August 23, 2018, 01:42:03 am
Hi, I'm trying to retrieve the default belief values for a civilization, but I'm having a hard time determining how to get to them.
I can see them with gm-editor here: "gui/gm-editor world.cultural_identities.all". Unfortunately, I can't seem to get LUA to recognize the same location, and all my attempts fail with "attempt to index a nil value".
I've seen Atkana's script on setting them, but the location used there doesn't seem to work either (df.cultural_identity.find(upers.cultural_identity).values[beliefId]).
Can anyone throw out a lua print statement that dumps out the contents of "world.cultural_identities.all[0].values"?

Code: [Select]
for k, v in pairs(df.global.world.cultural_identities.all[0].values) do
print(k .. " = " .. v)
end

Or yeah, just use printall(df.global.world.cultural_identities.all[0].values). Plus I think you can use df.cultural_identity.find(0).values as a slightly shorter way of writing out df.global.world.cultural_identities.all[0].values... I never really did learn how the find()s actually worked :b

Quote
I've seen Atkana's script on setting them, but the location used there doesn't seem to work either (df.cultural_identity.find(upers.cultural_identity).values[beliefId]).
That looks like it should work to me. What exactly is the issue? Obviously "upers" needs to be defined as well, and I'm not sure what it's supposed to be (it's not an English word, at least).

Minor nitpick, but that's also just an expression - there's no location in there.
I used upers as a shorthand for unit personality because if I'm going to be too lazy to type out unit.status.current_soul.personality every time, I figured I might as well go full shorthand :P
Title: Re: DFHack 0.44.12-r1
Post by: Putnam on August 23, 2018, 01:45:22 am
find() gets the object with that particular ID, which (esp. in the case of historical figures) may not line up with the array placement.
Title: Re: DFHack 0.44.12-r1
Post by: fortunawhisk on August 23, 2018, 01:10:48 pm
Excellent, exactly what I needed. Thanks!
Title: Re: DFHack 0.44.12-r1
Post by: BassDwarf on August 30, 2018, 04:51:38 pm
Unsure if there is a specific board for this or thread but a suggestion for a utility (which would most likely use DFHack), something similar to the RCT2 thoughts tab.
https://vignette.wikia.nocookie.net/rct/images/2/26/Rct-vandalism2.png/revision/latest?cb=20140121104704 (https://vignette.wikia.nocookie.net/rct/images/2/26/Rct-vandalism2.png/revision/latest?cb=20140121104704)

I know that recently someone published the Sentient Dwarf Fortress/It was inevitable bot on twitter, but having something like that as a utility/window would be interesting, especially if it could tally up common thoughts like said RCT thoughts monitor, so the player could know the common issues of the fort and avoid mass negative thoughts.
Title: Re: DFHack 0.44.12-r1
Post by: Putnam on August 30, 2018, 04:56:30 pm
I made something like that in 0.34.11, before I knew how to write UIs (or, indeed, before I was any good at programming at all), but it only showed the most common. An in-game UI for this wouldn't be too difficult.
Title: Re: DFHack 0.44.12-r1
Post by: Bumber on August 31, 2018, 02:19:17 am
"I want to get off Mr. Urist's Wild Ride!"
Title: Re: DFHack 0.44.12-r1
Post by: Rumrusher on September 02, 2018, 12:07:33 am
Code: [Select]
function flymode()
local flyuser = df.global.world.units.active[0]
flyuser.enemy.unk_4406_1[4]=true -- dont know what these do
flyuser.enemy.unk_4406_1[10]=true --dont know what these do
flyuser.enemy.unk_4406_1[19]=true --this unlocks flymode
end
ok so broke down and figured out how to just Fly with out needing flier, so uhh now I guess the whole turning on ghostly flag being bugged is fixed with this.
also bonus silly things with testing with flying is the drag script causes the draggee to float up 1 tile if you drag them up there.
Title: Re: DFHack 0.44.12-r1
Post by: Atomic Chicken on September 02, 2018, 02:43:25 am
Code: [Select]
function flymode()
local flyuser = df.global.world.units.active[0]
flyuser.enemy.unk_4406_1[4]=true -- dont know what these do
flyuser.enemy.unk_4406_1[10]=true --dont know what these do
flyuser.enemy.unk_4406_1[19]=true --this unlocks flymode
end
ok so broke down and figured out how to just Fly with out needing flier, so uhh now I guess the whole turning on ghostly flag being bugged is fixed with this.
also bonus silly things with testing with flying is the drag script causes the draggee to float up 1 tile if you drag them up there.

It's just become apparent to me that the bit array in
Code: [Select]
unit.enemy.unk_4406_1 corresponds to the creature token flags for the unit's caste, as found in
Code: [Select]
df.creature_raw.find(unit.race).caste[unit.caste].flags
Assuming this is correct, in Rumrusher's segment above:
flyuser.enemy.unk_4406_1[4] would be 'PATTERNFLIER'
flyuser.enemy.unk_4406_1[10] would be 'SWIMS_LEARNED'
flyuser.enemy.unk_4406_1[19] would be 'FLIER'

So I suppose it's possible to modify and set creature tokens for a single unit without affecting the entire race (though I imagine they'd be reset upon reloading).
Title: Re: DFHack 0.44.12-r1
Post by: Putnam on September 02, 2018, 03:22:29 am
I tested every unit on a map with this one-liner to corroborate this:

Code: [Select]
for _,unit in ipairs(df.global.world.units.all) do for k,v in ipairs(df.creature_raw.find(unit.race).caste[unit.caste].flags) do if unit.enemy.unk_4406_1[k]~=v then print(unit.id,k,v) end end end
Nothing printed at all, so that checks out.

I also checked if it saves with the world; it does not.
Title: Re: DFHack 0.44.12-r1
Post by: Rumrusher on September 02, 2018, 06:18:30 am
I tested every unit on a map with this one-liner to corroborate this:

Code: [Select]
for _,unit in ipairs(df.global.world.units.all) do for k,v in ipairs(df.creature_raw.find(unit.race).caste[unit.caste].flags) do if unit.enemy.unk_4406_1[k]~=v then print(unit.id,k,v) end end end
Nothing printed at all, so that checks out.

I also checked if it saves with the world; it does not.
welp I just saved in the air with a giant wagon train, pulling off some neverending story nonsense.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on September 03, 2018, 08:30:12 pm
Is there any way for dfhack to make a "meeting zone" active for only animals or only dwarves?

The tendency for animals to try to path to a meeting zone can be a huge pain, in part because (for example) dozens of turkey chicks will escape the coop and run to the dining room the moment a dwarf opens the door, and in part because of the bug that makes animals try to path through pet-forbidden doors all the time regardless, killing FPS. So it'd be nice to just make pastures also be meeting zones to help encourage the occupants to want to stay there, but without having all the dwarves also want to hang out with the animals.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 04, 2018, 05:10:23 am
Don't know, but as a workaround, you can make your taverns zones be inactive/non-meeting zones immediatelly after designating the zone as tavern - dwarves will still use it as location even if the name is invisible when it isn't marked as meeting one, but animals will not path to it.

(You might need to add a way for dwarves to go there though if it turns out they won't (haven't done prolonged testing); station orders makes the location 'default idle area' even once it is turned off, and bedrooms, drink/food stockpiles or inactive barracks could maybe work as well.)
Title: Re: DFHack 0.44.12-r1
Post by: Pvt. Pirate on September 06, 2018, 01:09:13 pm
i forgot how to fix mousequery... i think it was just a fixed dfhack .plug.so somewhere on github though.
copypastinging the mousequery.plug.so from the 44.09 just doesnt work - saying it were written for another version of dfhack.
the only thing that doesnt work is the scrolling on screenborder when not in any dmode or lmode or qmode.
i'll post this in dfhack and twbt support threads, because i remember something about twbt having its own version of mousequery.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on September 06, 2018, 04:21:35 pm
i forgot how to fix mousequery... i think it was just a fixed dfhack .plug.so somewhere on github though.
Here's what you're referring to: http://www.bay12forums.com/smf/index.php?topic=126076.msg7830622#msg7830622
It would be helpful if you could remember to link to what you're talking about instead of just randomly cross-posting in other threads. Few people in this thread would have any idea what issue you're referring to otherwise.

Also, DFHack itself has only ever distributed one mousequery plugin per release. We didn't put up a "fixed" build anywhere special - as far as we know, it's not a DFHack-caused issue. TWBT distributed its own for a while, but stopped
Quote
copypastinging the mousequery.plug.so from the 44.09 just doesnt work - saying it were written for another version of dfhack.
This behavior has always been the case since before 2010. Loading plugins for a non-matching DFHack version is unsafe, so DFHack prevents it.
Quote
the only thing that doesnt work is the scrolling on screenborder when not in any dmode or lmode or qmode.
Mousequery has a number of features, each of which you have to enable individually. Run "mousequery help" or maybe "help mousequery" for a list, then enable everything listed and see if that solves your issue.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 08, 2018, 09:52:45 pm
While working on two different but related scripts (in 43.03, if that matters) that both deal with designations, I noticed that non-digging designations may be offloaded. Ok, dfhack.designations.isPlantMarked points me to the joblist, and I find at least smoothing (e: and accessible digging...probably all of them, I guess) seems to be also there.

I also notice that smoothing and engraving a floor both use df.job_type.DetailFloor. Art specification is all -1s for both. Comparing two such jobs with my diffrecursive script, seems they only differ in position, worker, id, completion timer and unk4. And looks like df.global.world.engravings only lists already done engravings (though that does have the use case of carving tracks on all flies engraved on the floor). Well, thankfully, distinguishing recent engravings and smoothing is easy enough; just look if smooth flag is set to 1 or 2.

Does anybody know how to distinguish between offloaded engraving and smooth designations?
Title: Re: DFHack 0.44.12-r1
Post by: Pvt. Pirate on September 10, 2018, 12:47:11 pm
i forgot how to fix mousequery... i think it was just a fixed dfhack .plug.so somewhere on github though.
Here's what you're referring to: http://www.bay12forums.com/smf/index.php?topic=126076.msg7830622#msg7830622
It would be helpful if you could remember to link to what you're talking about instead of just randomly cross-posting in other threads. Few people in this thread would have any idea what issue you're referring to otherwise.

Also, DFHack itself has only ever distributed one mousequery plugin per release. We didn't put up a "fixed" build anywhere special - as far as we know, it's not a DFHack-caused issue. TWBT distributed its own for a while, but stopped
Quote
copypastinging the mousequery.plug.so from the 44.09 just doesnt work - saying it were written for another version of dfhack.
This behavior has always been the case since before 2010. Loading plugins for a non-matching DFHack version is unsafe, so DFHack prevents it.
Quote
the only thing that doesnt work is the scrolling on screenborder when not in any dmode or lmode or qmode.
Mousequery has a number of features, each of which you have to enable individually. Run "mousequery help" or maybe "help mousequery" for a list, then enable everything listed and see if that solves your issue.
it is that it only ignores the bottom and right screen border for scrolling. otherwise it works fine. that's the only thing weird about mousequery. manually enabling it helped if it wasnt working at all, but it does work, but oddly.

thanks to Lethosor, i found the solution again: redownloading a clean version of dfhack and it works.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 11, 2018, 05:53:57 am
So, tangent to my post right above, figured I need to be able to simulate vanilla d-x behaviour, and that means erasing jobs and returning worker to No Job, even after they're taken.
Spoiler: So, this (click to show/hide)
seemed to accomplish that objective, buuut when I was escaping back into the screen of viewing the now-erased job in gui/gm-editor, the game segfaulted.

Predictable and expected with nil pointer.

...But I can't predict every common access. Would this cause an issue elsewhere (outside of using it while in, say, manipulator's screen)? I'm half expecting eventful to be unhappy if job is started and erased instead of finished, though I'd expect it might cause an issue with dfhack.jobs.removeWorker then too.
Title: Re: DFHack 0.44.12-r1
Post by: Warmist on September 11, 2018, 06:34:54 am
So, tangent to my post right above, figured I need to be able to simulate vanilla d-x behaviour, and that means erasing jobs and returning worker to No Job, even after they're taken.
Spoiler: So, this (click to show/hide)
seemed to accomplish that objective, buuut when I was escaping back into the screen of viewing the now-erased job in gui/gm-editor, the game segfaulted.

Predictable and expected with nil pointer.

...But I can't predict every common access. Would this cause an issue elsewhere (outside of using it while in, say, manipulator's screen)? I'm half expecting eventful to be unhappy if job is started and erased instead of finished, though I'd expect it might cause an issue with dfhack.jobs.removeWorker then too.

So you have arrived at one of "fun" things in dfhack: deleting a job. It's not complicated per.se. but you need to have very good accounting of all the links and not to forget to unlink-erase-destroy everything related to that thing.

E.g. if you have a job it can have many different references to various things. Items that are marked in job will be "stuck" in job, workers would reference the job and crash df. IIRC there are even nasty "special reference" structures that are used for various screens or sth.

So my suggestion is that we would gather all of that knowledge in one place and write "cancel job" or "delete job" function that handles ALL the general refs.
Partial implementations (that i know of):  here  (https://github.com/DFHack/scripts/blob/master/gui/advfort.lua#L305) also  in dfhack itself  (https://github.com/DFHack/dfhack/blob/master/library/modules/Job.cpp#L103) and  here  (https://github.com/DFHack/dfhack/blob/master/library/modules/Job.cpp#L326) also  this comment says basically that  (https://github.com/DFHack/dfhack/blob/master/library/modules/Job.cpp#L366)

Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 11, 2018, 02:21:24 pm
Well, I can simply prevent the crashing if I leave the job hanging outside of joblist (it'd function exactly as it did before for whoever managed to get to it, just the jobs around it wouldn't have way back to it, but the designation is gone from the tile), but I imagine that would cause memory creep. Not much, but bad practice, that. However, no way to see which potential future third-party screens may want to access it.

However, seems like vanilla has some behaviour that resembles that, as I can still access the job struct after it is erased with d-x. With some interesting changes:


Most of this comes across as garbage data, though - ex, the historical figure of the worker was 40959, and there's infinite specific refs. Though matching the garbage data shouldn't hurt and matching the cleanup ones should be helpful. Anyway, job.flags[17] might be something like "active"?


Are there actually any general refs that are not workers or buildings? I notice logic for cancelling for those, but no handling of anything else, which implies there could be but presently aren't any known.

However, it seems the the safest option would be to save the designations I don't want to erase, let vanilla d-x do its thing, then replace them. Makes those with jobs on 'unerased' designations lose their job (e: but not engraving images?!) but should be safe otherwise.


Edit:

Noticed that dfhack has unnamed flags for carve track jobs (that should be named):

job.item_category: 18/19/20/21 true/false values correspond to carve_track_north/south/east/west. Tested and successfully altered track carving jobs with this.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on September 12, 2018, 10:11:23 pm
Is there any way dfhack could extend manager orders to add item quality as a conditional? i.e. I can set an order to require "thrones < 10" or even "undecorated quartzite thrones < 10" but I'd love to be able to specify "masterful thrones < 10".
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 12, 2018, 11:02:08 pm
DF doesn't track item quality there, so you'd have set required thrones to desired masterful thrones+number of non-masterful thrones in fortress (either regularly or whenever the second number changes), and then change the display(or place a "sticker" i.e. another viewscreen on) to change the number of player sees to be number of desired thrones - number of non-masterful thrones.


So, distantly related to the above:

Is there a way to change abstract building internal extents in lua? dfhack.buildings can tell and iterate over building.room, telling me whether a tile is part of it, but attempting to do the same in lua is a failure (and the building.room.extent only has 1 lonely value).

Example use case: I earlier placed 151 adjacent 1x1 pond zones in freezing climate with a macro (not knowing dwarves will spam cancel warnings on pond zones that are entirely on floors). It'd be nice if I could merge together the adjacent pond zones, or even place a new large one that has all tiles removed from it that don't overlap the previous ponds.

Near as I can tell, I can only do the latter via hijacking keyboard with gui.simulateInput, which is bit undesirable in the case of stockpiles (and will lose jobs, etc. that targeted to-be merged stockpiles) and unworkable in case of overlapping zones.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on September 13, 2018, 09:03:38 am
Is there a way to change abstract building internal extents in lua? dfhack.buildings can tell and iterate over building.room, telling me whether a tile is part of it, but attempting to do the same in lua is a failure (and the building.room.extent only has 1 lonely value).
extent is a pointer, which points to the first element of the "extent" array in C, but you can index it (e.g. extents[1]) to access other elements. There's also the _displace() method, mentioned in https://dfhack.readthedocs.io/en/stable/docs/Lua%20API.html, which does the same thing. Note that you are responsible for determining the appropriate maximum index in this case, as you would be in C as well - an out-of-bounds index can cause undefined behavior/crashes.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 13, 2018, 11:56:21 am
Awesome, that works (I tried indexing its parent value like that earlier, which failed).
Title: Re: DFHack 0.44.12-r1
Post by: Pvt. Pirate on September 13, 2018, 01:43:30 pm
Is there any way dfhack could extend manager orders to add item quality as a conditional? i.e. I can set an order to require "thrones < 10" or even "undecorated quartzite thrones < 10" but I'd love to be able to specify "masterful thrones < 10".
had to do a workaround before, seperating the items in different stockpiles and selling the unwanted.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on September 14, 2018, 02:25:30 pm
Does the "petcapRemover" plugin work for eggs? If not, could it?

I've discovered that if eggs are laid while the species is above its breeding limits (>50 total, or >75% children) then they won't become fertilized. I assumed this check was done at the time a male would have otherwise fertilized them, but it looks like even when the population is brought back under limits, those eggs will remain infertile forever, as if the female herself was infertile; new eggs have to be laid (by a different female, or a month later after clearing the bad clutch) while the population is able to breed in order for the eggs to be fertilizable.

It would be great if the "petcapRemover" plugin (or something like it) could operate on already-laid eggs by setting their "fertilizable" flag (or whatever it is) to true in the case that it sees infertile eggs of a species that is actually below the population limits.
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on September 14, 2018, 04:37:40 pm
Real life bird eggs are fertilized before they're laid (punching a hole in the shell afterwards would probably damage the eggs badly, or at least provide a path in for pathogens, apart from the minor detail of birds lacking any syringe like equipment for performing the task [some insects punch a hole through the carapace of the female at a random location for seed placement, so the general principle is not without precedent in the broader animal kingdom]).
Egg laying fish typically perform fertilization after the eggs are laid, but I'm not aware of that technique being used outside of water.

As far as I understand, DF simulates the real life process to some extent, thus requiring the male to fertilize the female a suitable time before the eggs are laid (females swarming to nest boxes to immediately drop egg clutches when doors are opened is probably not a very good simulation, and only a few domesticated species regularly lay eggs without fertilization (which may fail to take effect, resulting in non viable eggs anyway)).
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 15, 2018, 01:44:00 am
In other words: Yeah, it probably could.

Pregnancies in DF only check cap at conception, not birth; poultry in particular can lay off multiple fertile batches off 1 pregnancy, even after the male is slaughtered, even with over 75% children(had 3 turkey hens lay 2 successfull batches); hence how you can get crocsplosions in the hundreds.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on September 15, 2018, 12:41:08 pm
I realize real-world bird eggs must be fertilized prior to laying, I just misunderstood the wiki's description (http://dwarffortresswiki.org/index.php/DF2014:Egg) of how DF simulates it (where it does actually say "the male must be able to path to the eggs to fertilize," strongly implying that fertilization happens after laying). Regardless, the issue with the current vanilla mechanics is that it's nigh impossible to maintain a consistent bird breeding program with even a single hen per species.

In theory it should be doable by keeping exactly 13 adults all the time (including the breeding pair with its nest box) and 9 hatchlings per clutch; with four clutches per year that makes 36 chicks + 13 adults at any given time, which is just within the default bounds (13 + 36 < 50; 36 / (13 + 36) < 75%). That should allow exactly 9 to be slaughtered consistently every season in order to stay within bounds and keep getting fertile clutches.

But in practice this doesn't work because when the fourth clutch hatches the population will be over 50 for at least a few days until the newly matured adults can be slaughtered, and during those few days the next clutch will already be laid and flagged infertile because the population is over limit. So it would be great if DFhack could provide a mechanism to periodically check for this situation and, when the slaughtering is all done and the population is back under limit, change the eggs' flag to fertile.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 15, 2018, 01:37:27 pm
Well the wiki is clearly wrong on that, as my poults can attest *goes to edit*. The male must be able to meet up with the female to get them pregnant, as with all other females in-game. (it also suggests fertilization chances might differ per animal, which is ..new claim to me.)

Also, the 75% ratio isn't checked for eggs; shown as I had 3 hens to something like 36 chicks at the time second set of eggs.
Title: Re: DFHack 0.44.12-r1
Post by: Rumrusher on September 15, 2018, 02:40:41 pm
Screwing around to see if it possible to send different squads from a different civ in fort mode using dfhack, if possible it opens up to an idea of building and training a group of mercenaries for other civs.

from what I tested it is totally possible to just send a squad over to attack or explore sites for you if you lack any squads of your own.
sadly my next big hurdle is solving for
Code: [Select]
df.global.gview.view.child.child.squad_unk
as if I don't have this align with the new squad that's been added the game will crash. which means making a script that checks the list of how many squads there are and inserting them to the Gview squad pool, and also equally inserting a new squad_unk for each of them.
Title: Re: DFHack 0.44.12-r1
Post by: zaporozhets on September 15, 2018, 10:28:31 pm
Is it currently known if it's possible to manually trigger a cave-in check after a tiletype change or, failing that, how to complete a remove construction job without a worker unit in proximity in order to trigger one automatically?

Attempted to set df.world.cavein_flags and job.completion_timer with no luck respectively, didn't find anything that looked relevant in map_block fields or df.job/unit.job.current_job fields and I'm out of ideas as to how to get these free floating floors to collapse.

Input from someone more experienced would be appreciated.
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on September 16, 2018, 03:51:38 am
I have no idea if it works, but have you tried changing the DF settings to disable cave-ins, remove what you want to remove, save, exit, enable cave-ins, and start your save again? I generally set up my cave-ins to be triggered by a lever pull removing a support.
Title: Re: DFHack 0.44.12-r1
Post by: Kat on September 16, 2018, 04:30:14 am
I see that DfHack has a thing to adjust dwarfs preferences. the "pref-adjust" script.

I am wondering if it is possible, to make a similar script, that I could use to insert a preference for my drow civilisation - I have a couple citizens who have food preferences for things that are not available locally or from any of the caravans. I just want to insert a preference for one of the common drinks, not alter any of their other preferences.

And if so, how, because I find the script language very difficult to understand.

if it helps, the drink I want is made from the plant "RHENAYAS_DROW_LICHEN_BLUE"
Title: Re: DFHack 0.44.12-r1
Post by: zaporozhets on September 16, 2018, 11:49:59 am
I have no idea if it works, but have you tried changing the DF settings to disable cave-ins, remove what you want to remove, save, exit, enable cave-ins, and start your save again? I generally set up my cave-ins to be triggered by a lever pull removing a support.

I can see why that might work, but unfortunately it's for a script mod with explosive weapons and I'm trying to get them to be able to "destroy" constructions during combat, rather than a specific thing I want gone.
ATM the script just does a check in a square around the point of impact and changes any walls found into floors.
This works well enough for my purposes, but messing about with this in the arena made me realize that it could leave stranded floating floors with no supports and so the cave-in would need to ideally be triggered straight away, either by manual invocation of the check or by utilizing an artificially created and completed "remove construction" job rather than changing tiletype.
Using the 'job method' I've gotten as far as creating the job (the construction is flashing), but I haven't yet managed to get it to complete artificially.

Thank you for your help nonetheless.

Edit: As an update to this, I've gotten as far as being able to complete a deconstruct job artificially and trigger the cave-in some of the time, but I've no real idea as to what determines if it works or not.

Edit2: No longer bothering with the synthesized job stuff, figured out how to trigger cave-ins by setting df.global.world.cavein_flags[0] and df.global.world.map.map_block_columns[].flags[0] to true, seems to be producing small amounts of magma, which is strange.
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on September 16, 2018, 12:00:22 pm
@Kat

I think this script might work
Code: [Select]
[code]
function z ()
 local unit = dfhack.gui.getSelectedUnit (true)
 local material = dfhack.matinfo.find ("PLANT:SINGLE-GRAIN_WHEAT:DRINK")

 local preference = df.unit_preference:new ()
 preference.type = df.unit_preference.T_type.LikeFood
 preference.item_type = df.item_type.DRINK
 preference.item_subtype = -1
 preference.mattype = material.type
 preference.matindex = material.index
 preference.mat_state = df.matter_state.Solid  --  Stupid for drinks, but everything seems to be specified as solid
 preference.active = true
 preference.prefstring_seed = 1  --  Or whatever
         
 unit.status.current_soul.preferences:insert ("#", preference)
end

z ()
[/code]

You'd have to replace "SINGLE-GRAIN_WHEAT" in the string on the third line with your plant name.
At least it added single-grain wheat beer to my test subject's preferences in addition to the pre-existing prickleberry one. Note that the unit to be subjected to the script has to be selected with 'v' or in the units list.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 16, 2018, 11:34:45 pm
Question about iterating through active jobs: Looking in my save, there's 438 elements in job list linkedlist, and 379 not-dead/547 total in job_postings. I've also seen both used in places(isPlantMarked, Altaree's priority.lua respectively). Which is more 'proper' to use?
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on September 16, 2018, 11:42:34 pm
job_postings is used to track some limited data about future jobs, not current jobs. If you want actual jobs, use job_list.
Title: Re: DFHack 0.44.12-r1
Post by: thefinn on September 17, 2018, 06:56:54 am
What ever happened to being able to set AUTODUMP on a stockpile? (Like you can with AUTOMELT and AUTOTRADE)

That used to be incredibly useful.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on September 17, 2018, 08:30:56 am
"enable autodump"
Title: Re: DFHack 0.44.12-r1
Post by: taleden on September 17, 2018, 08:34:18 am
Also, the 75% ratio isn't checked for eggs; shown as I had 3 hens to something like 36 chicks at the time second set of eggs.

I'm not sure that's true; I tried slaughtering all my extra adult turkeys and the next clutch was infertile, even though their total population including the newest poults was under 50. So something other than the species population cap is causing eggs to remain infertile even from two fertile adults, and the only other such mechanic I've ever heard of is the 75% child rule.
Title: Re: DFHack 0.44.12-r1
Post by: thefinn on September 17, 2018, 09:00:08 am
"enable autodump"

Awesome thanks.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 17, 2018, 12:41:14 pm
@taledan:

When did you slaughter? I suspect that poultry, once pregnant, can't get pregnant again until they stop being pregnant, which means you might have had the previous batch laid in later half of pregnancy.

I can provide saves for both turkey hens being pregnant and having laid eggs after first set hatched and of second clutch of turkey poults hatching with no turkey hens of gobblers alive (though as I've seen, that's not something to rely on).
Title: Re: DFHack 0.44.12-r1
Post by: Kat on September 17, 2018, 12:41:35 pm
@Kat

I think this script might work
Code: [Select]
[code]
function z ()
 local unit = dfhack.gui.getSelectedUnit (true)
 local material = dfhack.matinfo.find ("PLANT:SINGLE-GRAIN_WHEAT:DRINK")

 local preference = df.unit_preference:new ()
 preference.type = df.unit_preference.T_type.LikeFood
 preference.item_type = df.item_type.DRINK
 preference.item_subtype = -1
 preference.mattype = material.type
 preference.matindex = material.index
 preference.mat_state = df.matter_state.Solid  --  Stupid for drinks, but everything seems to be specified as solid
 preference.active = true
 preference.prefstring_seed = 1  --  Or whatever
         
 unit.status.current_soul.preferences:insert ("#", preference)
end

z ()
[/code]

You'd have to replace "SINGLE-GRAIN_WHEAT" in the string on the third line with your plant name.
At least it added single-grain wheat beer to my test subject's preferences in addition to the pre-existing prickleberry one. Note that the unit to be subjected to the script has to be selected with 'v' or in the units list.


Looks like it works. Thanks muchly !
Title: Re: DFHack 0.44.12-r1
Post by: taleden on September 17, 2018, 12:57:16 pm
@taledan:

When did you slaughter? I suspect that poultry, once pregnant, can't get pregnant again until they stop being pregnant, which means you might have had the previous batch laid in later half of pregnancy.

I can provide saves for both turkey hens being pregnant and having laid eggs after first set hatched and of second clutch of turkey poults hatching with no turkey hens of gobblers alive (though as I've seen, that's not something to rely on).

How does a bird's pregnancy relate to their eggs, exactly? Is the bird flagged as not-pregnant as soon as the eggs are laid, so that they can become pregnant again while sitting on that clutch and thus be ready to immediately lay the next clutch when they hatch? Or do they remain technically pregnant as long as they're sitting on the eggs, until they hatch and can then immediately become pregnant again and then lay the next clutch?

From what I've seen hens will reliably lay their next clutch almost instantly (within a game day) after the previous one hatches, or rather, almost exactly 3 months after the previous clutch was laid (whether or not the previous eggs were removed or allowed to hatch). If the hens were able to get pregnant during that 3 month post-egg-laying time, that would imply that getting the population within bounds at any point during that period should let the next clutch be fertile, but that is definitely not the behavior I see. Rather, it looks to me very much more like the population has to be within breeding bounds (species cap, child ratio) at some (or all?) points between the hatching of the previous clutch and the laying of the next one.

That said, it's definitely possible that the male's presence is required at a different point than when the eggs are actually laid, which could explain your fertile-clutches-post-males behavior.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 17, 2018, 01:06:49 pm
Neither. Near as I can tell, bird's pregnancy ticks down like normal for six months, and if they lay eggs during that time those eggs are marked fertile. Since eggs take 3 months to hatch, can get 2 rounds off. (This mirrors the real life behaviour of some birds, but it applies to all in DF).

I presume population has to be within bounds both when the hen becomes pregnant and when they actually lay eggs,  but I haven't checked.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on September 17, 2018, 01:20:01 pm
Oh, interesting; I guess I just assumed that their pregnancy duration would match their egg laying frequency, but I suppose it makes a kind of sense that their pregnancy mechanics were just copied from mammals with their 6 month cycles, and then the egg laying tacked on.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on September 18, 2018, 04:04:51 pm
Is there already a script somewhere to add a hotkey to set yourself a reminder for later?

I often find I have so many projects and processes ongoing at once that I forget some and realize months later that I forgot to go back and designate the next phase of digging/construction/whatever because I was distracted looking at something else. It'd be great to have a hotkey to just let me type in a little reminder and a game date, and have that message pop up at the specific time; bonus points if it could also be tied to construction, building or job completion if such a thing is currently highlighted.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 19, 2018, 11:34:37 am
Not to my knowledge. You can type into console stuff like :lua dfhack.timeout(10, 'days', function() dfhack.gui.showPopupAnnouncement('Do the dishes!',COLOR_GREEN) end)

It would be near trivial to add a hotkey and two (require 'gui.dialogs').showInputPrompts to it. Looking at job completions requires eventful, making that bit more complicated.

Really, the biggest problem is that you forget you have the option. An indicator can help against that and is the purpose behind my 3rd-party gui/indicator_screen.lua*, but displaying one everywhere can be undesirable due visual clutter, non-keybound commands and some plugins (automaterial, most importantly) requiring fitting top screen (haven't written a workaround yet). (A nonexistent plugin equivalent would be better, but would still suffer from first and needing compiles each version.)

*...(which I should update with the new features in dev copy, I guess.)
Title: Re: DFHack 0.44.12-r1
Post by: taleden on September 19, 2018, 11:54:31 am
I don't think the reminder hotkey should have a permanent label on screen; a red hotkey just on the main menu list (i.e. down below the "Space: Resume   .: One-Step") would be great, but even that isn't necessary -- people who find they like the feature will soon remember what the key combo is anyway.

Regardless, I guess ideally it would have its own screen kind of like the job manager, listing all set reminders so they could be edited or deleted. Then a key to add/edit a reminder would just prompt for a date and then a text string, and on that date the game will pause with that text string as a popup alert. The date string could be flexible, so i.e. "125-*-1" would alert on the first of each month in the year 125, or "*-4-*" for the first of summer every year, or "+20 days" for 20 days from the current date. Oh, can lua scripts save data into the game save to be reloaded later, or is all state lost between sessions?

If I ever find some time to dig into dfhack's API I'll take a stab at this, but for now I just wanted to toss the idea out there in case it piqued anyone else's interest. :)
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 19, 2018, 12:30:39 pm
That should remove the third issue, to my knowledge.

Pretty expansive idea; someone other than me would have to pick it up, though. At least while I still have scripts I want to write more.

Yup, dfhack's lua can totally save data in game save (https://dfhack.readthedocs.io/en/latest/docs/Lua%20API.html#persistent-configuration-storage).
Title: Re: DFHack 0.44.12-r1
Post by: thefriendlyhacker on September 19, 2018, 02:46:07 pm
That should remove the third issue, to my knowledge.

Pretty expansive idea; someone other than me would have to pick it up, though. At least while I still have scripts I want to write more.

Yup, dfhack's lua can totally save data in game save (https://dfhack.readthedocs.io/en/latest/docs/Lua%20API.html#persistent-configuration-storage).
There is also the far less arcane persist-table wrapper, which is AFAICT completely undocumented aside from the comments in its file in the lua folder for some reason, despite the fact that it is really useful.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on September 19, 2018, 03:20:29 pm
Then document it! The documentation was probably never written for that, but there's a reason it's open-source. I don't know enough to document it myself.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 19, 2018, 03:42:56 pm
Looking at it (https://github.com/DFHack/dfhack/blob/master/library/lua/persist-table.lua), I'd guess the some reason is "All stored values MUST be strings. Numbers can be supported later but are not yet supported.".

Still, storing tables recursively? Assigning/retrieving things with less code? Could be pretty useful, and didn't know about it. (It's not useful now, though, since I already wrote what I was storing, but...Hm. Could make for, say, persistent context-script pairs without editing init for each one.)
Title: Re: DFHack 0.44.12-r1
Post by: Roses on September 19, 2018, 05:29:22 pm
Looking at it (https://github.com/DFHack/dfhack/blob/master/library/lua/persist-table.lua), I'd guess the some reason is "All stored values MUST be strings. Numbers can be supported later but are not yet supported.".

Still, storing tables recursively? Assigning/retrieving things with less code? Could be pretty useful, and didn't know about it. (It's not useful now, though, since I already wrote what I was storing, but...Hm. Could make for, say, persistent context-script pairs without editing init for each one.)

I use persistent tables extensively in my scripts. A single fort that runs for a couple years could have thousands of them. They are extremely useful

EDIT: And yes, all stored information must be strings. An unfortunate limitation but one that is fairly easy to get around.
Title: Re: DFHack 0.44.12-r1
Post by: Putnam on September 19, 2018, 06:08:12 pm
I use persistent tables extensively in my scripts. A single fort that runs for a couple years could have thousands of them.

I've run profiling in Fortbent before I stopped using your class system and doing this caused something like 20% of the CPU time during processing of the game in a later fort and by itself was dropping the FPS below 100 in the early game, so I wouldn't recommend this too much. In fact, that's why I stopped using your class system; the heavy use of persist-table was causing massive slowdown. (Well, that and a bit of NIH syndrome and a lot of "wanted a wheel but got a whole car with it")

Personally, I abjure persist-table entirely cause I'd rather use the persistent config storage's ints and such.

Oh, that reminds me: persistent configuration storage uses only the names of the generated historical figures. Is there a particular reason for this? It could use, say, orientation flags without side effects.
Title: Re: DFHack 0.44.12-r1
Post by: thefriendlyhacker on September 20, 2018, 01:45:20 am
I use persistent tables extensively in my scripts. A single fort that runs for a couple years could have thousands of them.
I've run profiling in Fortbent before I stopped using your class system and doing this caused something like 20% of the CPU time during processing of the game in a later fort and by itself was dropping the FPS below 100 in the early game, so I wouldn't recommend this too much. In fact, that's why I stopped using your class system; the heavy use of persist-table was causing massive slowdown.
...
I am almost afraid to ask, but...how many persistent tables are getting used in your scripts, Rose?  And how often are you reading from them? 

I ask because I have a TLCM randomizer script that keeps track of what creatures have had their appearance randomized via persist-table, and in a developed fort it could have as many as 3000 entries (3-4 records for the majority of civilized creatures that have been active at some stage).  The persistent entries only get read once per save load cycle before a non-persistent table of checked creatures is filled, but those entries are still there, and now Putnam has me worried that I am unwittingly nuking a fort's late game FPS.
Title: Re: DFHack 0.44.12-r1
Post by: Putnam on September 20, 2018, 01:59:13 am
I probably would've stuck with roses stuff if I'd been able to get the JSON saving to reliably save with the game. I couldn't figure out a way to tell if quicksaving/autosaving was going on. The problem was more that every single table check was a persist-table check, IIRC.
Title: Re: DFHack 0.44.12-r1
Post by: Roses on September 20, 2018, 11:02:25 am
I use persistent tables extensively in my scripts. A single fort that runs for a couple years could have thousands of them.
I've run profiling in Fortbent before I stopped using your class system and doing this caused something like 20% of the CPU time during processing of the game in a later fort and by itself was dropping the FPS below 100 in the early game, so I wouldn't recommend this too much. In fact, that's why I stopped using your class system; the heavy use of persist-table was causing massive slowdown.
...
I am almost afraid to ask, but...how many persistent tables are getting used in your scripts, Rose?  And how often are you reading from them? 

I ask because I have a TLCM randomizer script that keeps track of what creatures have had their appearance randomized via persist-table, and in a developed fort it could have as many as 3000 entries (3-4 records for the majority of civilized creatures that have been active at some stage).  The persistent entries only get read once per save load cycle before a non-persistent table of checked creatures is filled, but those entries are still there, and now Putnam has me worried that I am unwittingly nuking a fort's late game FPS.

I probably would've stuck with roses stuff if I'd been able to get the JSON saving to reliably save with the game. I couldn't figure out a way to tell if quicksaving/autosaving was going on. The problem was more that every single table check was a persist-table check, IIRC.

If I recall correctly that was back when I loaded EVERYTHING into persistent tables instead of just what was needed/used. With Fortbent you had hundreds of classes (if I recall correctly) and I used to make a persistent table for each unit that was on the map and each units table would track all of the class tables. Now it only assings a unit table to units that need them, and the only information that gets added to the tables are the required information. For the Class System that means a unit that only ever switches between 3 classes will only have those 3 classes in their unit table, and I unit that never gets a class won't even have a unit table to begin with. I also changed the whole constantly doing persistent-table checks that it used to do.

This fixed a lot of the issues that used to be there. I'm sure there is still some slow down, but I haven't noticed anything too harsh, although it's been awhile since I played a fort to 100+ people. One thing I should work on is making the persistent-table stuff only used on save/reload and populating a normal non-persistent table with the information to be used while the game is running. Not sure how much work it would be to transfer what I have now to doing that, but it would make sure that you only get the overhead of calling persistent-tables at the start.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 20, 2018, 01:04:40 pm
Wouldn't it be simpler to change the persist-table to use globals on further requests to the same table, as it suggests for performance in the comments?

EDIT: So, after spending hours going over code, I finally discovered why it's not possible (by default) to just pass "Esc" key in dwarfmode view: allow_options check in Screen.cpp (thanks for the hint, Putnam, couldn't have found it without seeing it possible in gui/overhaul) for that case in particular.

I'd cheerfully tagging that onto a screen, but I can only assume it is disabled by default for a reason. Any ideas why it's better to keep it off?

E2: Ah. Seems if it is on, options are shown even on non-dwarfmode.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on September 22, 2018, 12:54:17 pm
Is there a plugin or script, or could one be made, to alter the expanded furniture placement submenu (the one that shows each individual item available to place) so that the "Dist" could be toggled to show "Value" instead (or else "Value" added as a second column, the way the non-expanded list has both "Dist" and "Num")?

When furnishing noble rooms, the value of the item to be placed is much more relevant than the hauling distance. As it is I find I often have to keep going down the list hitting "v" to locate the particular items that I just had encrusted with the valuable gems, for example.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 22, 2018, 07:50:16 pm
There isn't, but could be made. The distances are stored in df.global.ui_build_selector.choices, for what's it is worth.
Title: Re: DFHack 0.44.12-r1
Post by: Pvt. Pirate on September 23, 2018, 03:19:07 am
could someone add some more options to the furniture planning mode?
there's min quality, but not max quality

for when i want to plan my dining hall all the way and not have my dorfs place masterwork or even artifact tables and thrones there.
same with regular dorfs rooms with bed etc. and the noble rooms and hospitals.
Title: Re: DFHack 0.44.12-r1
Post by: zaporozhets on September 28, 2018, 04:36:13 pm
Is anybody well-versed on constructions and materials?
I'm able to insert a lua created construction into df.world.constructions with a corresponding tiletype on the map, but it refuses to display a material and item type unless inserted onto an existing construction (e.g. a new wooden construction spawned on a stone wall displays correctly as an oak block fortification, whereas one spawned in the air is simply a "fortification").
Am I missing something obvious that links the map tile and the construction properties?
Would appreciate any help whatsoever.

Also, is there a gui element (with the onInput() method) or another means of receiving keypresses that doesn't require the game being paused like a framed screen does?
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on September 28, 2018, 07:34:09 pm
could someone add some more options to the furniture planning mode?
there's min quality, but not max quality
This was done in https://github.com/DFHack/dfhack/pull/1284. I don't think that's part of a release yet. Maybe we should make another release.

Also, is there a gui element (with the onInput() method) or another means of receiving keypresses that doesn't require the game being paused like a framed screen does?
Nearly all screens will pause the game. You might be able to advance fortress mode by calling logic() on the dwarf mode screen, but there's usually a good reason for the game to be paused.

What are you doing, anyway? This sounds suspiciously like some kind of always-present UI element that you're trying to add with Lua. Lua isn't very well-suited for that (well, custom screens aren't suited for that, but they're basically the only way to do that in Lua). It's easy to break the game (e.g. by not handling the options/help/movies keys properly, or just leaving the screen around at inappropriate times). I would recommend writing a plugin if that's what you're trying to do, because you can modify existing screens in C++ (and can still write the rest in Lua, if you want).
Title: Re: DFHack 0.44.12-r1
Post by: zaporozhets on September 28, 2018, 08:04:58 pm
Nearly all screens will pause the game. You might be able to advance fortress mode by calling logic() on the dwarf mode screen, but there's usually a good reason for the game to be paused.

What are you doing, anyway? This sounds suspiciously like some kind of always-present UI element that you're trying to add with Lua. Lua isn't very well-suited for that (well, custom screens aren't suited for that, but they're basically the only way to do that in Lua). It's easy to break the game (e.g. by not handling the options/help/movies keys properly, or just leaving the screen around at inappropriate times). I would recommend writing a plugin if that's what you're trying to do, because you can modify existing screens in C++ (and can still write the rest in Lua, if you want).

I'm working on a construction-based boat for adventure mode, the UI element is just a workaround to receive input as I couldn't find any another way of getting it (my experience and ability being somewhat limited), I want the player to be able to control it in a semi-native fashion by using the arrow keys rather than with a menu or just reactions.

I didn't really want to post anything on the forums until I had something more substantial to show than this crude prototype, but here's an idea of what I'm trying to do:
(https://i.imgur.com/oEpx7fo.gif)

I really hope I don't have to look into making a plugin and there's another method, I've no experience with C++ and only a little experience with Java and lua.
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on September 28, 2018, 08:20:45 pm
Huh, I thought that buildingplan was abandoned for further work. Is there a way to access/place buildings that link to it? (I looked into it when making constructmultiz, but couldn't find a way to get at it - at least, without modifying buildingplan, which seemed like a nonstarter.)

@zaporozhets: Yeah, it's doable - see putnam's abandoned Mouse overlay (http://www.bay12forums.com/smf/index.php?topic=171276.0).

I've worked around some of the issues lethosor mentions in indicator_screen (the one mentioned in links in my could use an update from home copy, but planning to release multiple ~ready things at once), but three remain:

1) Many commands expect appropriate dwarmode screen on top. Not really a problem when they're in keybinds, but an issue when called directly from commandline.

2) Some plugins (automaterial, stockpile menus in particular, but not the buildingplan you're interested in) also expect that. Can be worked around with dummy layering, but have to do it for each such case.

3) TWBT doesn't allow for clicking on the menu side of dwarmode view for partial screens, and screens are placed according to text mode  dimensions (i.e. screwing with things with mouse clicks/hovers).


But there is another - no, rather even the primary - means of receiving keypresses: The default keybinding command.

Note that with that plugin, the default DF behaviour is called first, then the command linked. So I have stuff like S bound to copying stockpile links with track stops, with no screen to receive input or show anything.

(I'm trying to move away from it for compatibility and due later adds having priority, but it's incredibly useful).

However, it doesn't allow one to look at left/right/up/down keys. Though you could theoretically avoid both C and gui screen by, say, using engravings on tiles as letters.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on September 28, 2018, 08:29:33 pm
could someone add some more options to the furniture planning mode?
there's min quality, but not max quality
This was done in https://github.com/DFHack/dfhack/pull/1284. I don't think that's part of a release yet. Maybe we should make another release.
I'm using DFHack 0.44.12-r1 from PESP 0.44.12-r03 and I see a "Max Quality" setting for building plan, which I've made good use of. But some other additions I'd find useful are a "Non-Decorated Only" (there's already Decorated Only, but sometimes I want to specifically avoid using that stuff), and/or even better, a way to set a minimum or maximum item value (i.e. to make sure the really good decorated stuff goes in the royal throne room, while the mediocre decorated stuff goes in the suite of the new baron who just inherited from some other site I don't care about).
Title: Re: DFHack 0.44.12-r1
Post by: taleden on September 28, 2018, 08:38:31 pm
Is there any way with dfhack to forcibly cancel whatever job is associated with a specific item, and/or unflag that item as being part of a job?

Somehow I ended up with two minecarts floating in open space 1z above a ramp, flagged "TSK" so I can't get them moved or dumped somewhere else, but there is no job in the list that refers to them and forbidding/unforbidding doesn't un-TSK them.

edit: nevermind! I misunderstood what was going on; it was a couple of minecarts refusing to fall down into a space already containing other minecarts, and I didn't realize the lower ones would block the upper ones from falling, so the "TSK" actually indicated the item was "in flight". As soon as I bumped the upper ones sideways to interrupt their fall, the "TSK" went away and I was able to get them moved.
Title: Re: DFHack 0.44.12-r1
Post by: zaporozhets on September 28, 2018, 09:02:43 pm
@Fleeting Frames
Thank you very much for this, gives me a lot to go off.
Title: Re: DFHack 0.44.12-r1
Post by: Pvt. Pirate on September 29, 2018, 03:33:12 am
could someone add some more options to the furniture planning mode?
there's min quality, but not max quality
This was done in https://github.com/DFHack/dfhack/pull/1284. I don't think that's part of a release yet. Maybe we should make another release.
I'm using DFHack 0.44.12-r1 from PESP 0.44.12-r03 and I see a "Max Quality" setting for building plan, which I've made good use of. But some other additions I'd find useful are a "Non-Decorated Only" (there's already Decorated Only, but sometimes I want to specifically avoid using that stuff), and/or even better, a way to set a minimum or maximum item value (i.e. to make sure the really good decorated stuff goes in the royal throne room, while the mediocre decorated stuff goes in the suite of the new baron who just inherited from some other site I don't care about).
oh, thanks. i haven't played with 0.44.12-r1 any further after seeing that mousequery edge wouldn't work properly. it still doesn't as i read twbt and dfhack have been merged and it seems the one that had the fixed mousequery was dropped in that process.
Title: Re: DFHack 0.44.12-r1
Post by: Rumrusher on September 30, 2018, 06:39:50 pm
Nearly all screens will pause the game. You might be able to advance fortress mode by calling logic() on the dwarf mode screen, but there's usually a good reason for the game to be paused.

What are you doing, anyway? This sounds suspiciously like some kind of always-present UI element that you're trying to add with Lua. Lua isn't very well-suited for that (well, custom screens aren't suited for that, but they're basically the only way to do that in Lua). It's easy to break the game (e.g. by not handling the options/help/movies keys properly, or just leaving the screen around at inappropriate times). I would recommend writing a plugin if that's what you're trying to do, because you can modify existing screens in C++ (and can still write the rest in Lua, if you want).

I'm working on a construction-based boat for adventure mode, the UI element is just a workaround to receive input as I couldn't find any another way of getting it (my experience and ability being somewhat limited), I want the player to be able to control it in a semi-native fashion by using the arrow keys rather than with a menu or just reactions.

I didn't really want to post anything on the forums until I had something more substantial to show than this crude prototype, but here's an idea of what I'm trying to do:
-snip-
I really hope I don't have to look into making a plugin and there's another method, I've no experience with C++ and only a little experience with Java and lua.
welp time to cross off boats and movable constructions off the personal todo list, I guess that means building a mobile house is possible now.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on October 01, 2018, 11:30:19 am
Is it possible for a lua or ruby script to augment the in-game GUI on a specific screen or submenu? I just noticed that all the examples of this that I can think of (cage-butcher showing the "Bu" flag indicator in the cage's "q" menu, eggs-fertile showing the status in the nest's "q" and "t" menus) are plugins, not scripts.

I found a few scripts that detect the current screen or submenu (i.e. to read which unit is highlighted in the "u"nits screen or cage "q" occupants menu), but I can't find any examples of a script adding text to the screen in those contexts. So if it's possible to do this I'd love a pointer to an example!
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on October 01, 2018, 01:57:27 pm
My last post (http://www.bay12forums.com/smf/index.php?topic=164123.msg7862419#msg7862419) is somewhat related. Basically, you have to use C++ to modify existing screens. You can use Lua (but not Ruby) to create entirely new screens which draw the screen below them plus some extra text to achieve a similar effect (see gui/extended-status), but it's not recommended, and particularly dangerous in the main fortress/adventure mode screens. A plugin is usually preferable.

Incidentally, I'm not sure what examples you were looking at to find the selected unit. No tool should have to check what the current screen is to do that - DFHack has a Gui::getSelectedUnit() function that will work on nearly any screen where a unit can be selected. Was that a core DFHack script you were looking at?

Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on October 02, 2018, 04:01:23 am
Some DF viewscreens do provide you access to some data on them, which you can then modify, but afaik none of them allow you to set new keybinds.

I personally use a fair few screens like lethosor describes, but in hindsight the lua gui screen support structure I wrote for it is more workarounds for issues linked to this than support. Well, I already spent moths writing things reliant on it or it itself and they work well enough, but if I had known in the beginning I'd might have written the gui section as a lua-facing arbitrary-text C plugin (in fact, I suspect this idea is how the existing lua gui options came to be). Or not written anything substantial at all *shrug*
Title: Re: DFHack 0.44.12-r1
Post by: Rumrusher on October 02, 2018, 04:32:06 pm
for adventure mode wise probably make it work like the minecarts push and ride system, where you do loads of menu key press setups to pilot it.
Title: Re: DFHack 0.44.12-r1
Post by: Giant Ostrich Bone [29] on October 04, 2018, 11:20:35 am
Hello, totally new to the forums here and a bit of a novice at DF. (haven't learned how to make a TOTALLY good military yet, make ore, use lava, a well, etc.) I wanted to use DFHack to view legends mode while having a current/on-going fort because I noticed there are two people I'm having issues with. As in, one is dead and buried but I can't make a memorial slab for him (it doesn't appear on the menu) while the other is a memorial slab I produced assuming it belonged to one of my dead dwarves but this guy has never even set foot in my fortress! I don't want issues with ghosts and I have absolutely no idea why they carved this other memorial to someone I don't know. Finding out about these people would help I think. So...

Whenever I open DFHack the window is open for a split second but closes immediately, displaying no graphics it is so fast. I've looked at my task manager to no avail. I have a Windows 64-bit system and took care to install that one. Can anyone help me? Thank you!

(I just found out one tidbit that may have at least answered my first question. The slain guy was a Monster Slayer instead of a typical dwarf. Can I not make a memorial to him because he was a member of a different race, as a visitor?)
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on October 04, 2018, 11:33:26 am
Some basic details would help. How did you install DFHack? What version of DFHack and DF are you using?
Title: Re: DFHack 0.44.12-r1
Post by: Giant Ostrich Bone [29] on October 04, 2018, 12:07:32 pm
I downloaded it from this url: https://github.com/dfhack/dfhack/releases

Under the DFHack 0.44.12-r1 heading, it was this: dfhack-0.44.12-r1-Windows-64.zip

I have a Windows 64-bit laptop, and am using the most current version, 0.44.12
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on October 04, 2018, 01:11:29 pm
Are you using the 32-bit or 64-bit version of DF? Can you verify that you installed DFHack correctly from the instructions (https://dfhack.readthedocs.io/en/stable/docs/Introduction.html#installing-dfhack)? If you uninstall DFHack, does DF start normally? (You can do this minimally by renaming SDL.dll to something else, then renaming SDLreal.dll to SDL.dll.)
Title: Re: DFHack 0.44.12-r1
Post by: Staalo on October 08, 2018, 02:50:53 am
Hello all and thanks for the invaluable tool you're providing us. I was directed here from the other forum, since the funny features I'm seeing might have something to do with DFHack.

In short, I can access the information of some dwarves who are not residents in my fort by selecting (v)iew in some citizens' relationships screen. There are also some additional effects related to the same thing, a longer description can be found in this thread. (http://www.bay12forums.com/smf/index.php?topic=172314.0)

This is happening on Mac DF .44.12 with DFHack 0.44.12-r1 installed without any other mods.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on October 08, 2018, 12:14:00 pm
Is there a way for a Lua script to tell if a female egglayer is currently busy sitting on eggs in a nestbox? "unit.job.currentjob" and "unit.actions" don't seem to show it. I can use dfhack.buildings.findAtTile(), :getType() and .claimed_by to check that the bird is standing on her own claimed nest box which is probably close enough, but I wondered if someone knows a more direct way to test for egg-sitting.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on October 08, 2018, 02:36:34 pm
Replied at http://www.bay12forums.com/smf/index.php?topic=172314.msg7868194#msg7868194, for reference

Is there a way for a Lua script to tell if a female egglayer is currently busy sitting on eggs in a nestbox? "unit.job.currentjob" and "unit.actions" don't seem to show it. I can use dfhack.buildings.findAtTile(), :getType() and .claimed_by to check that the bird is standing on her own claimed nest box which is probably close enough, but I wondered if someone knows a more direct way to test for egg-sitting.
From what I remember, this isn't an exact science in DF - egglayers can move away from the nestbox for a short time, and the eggs will be fine (unless that's changed). Maybe there's an egg-related timer somewhere in the unit that you can check. I don't know much off the top of my head here, unfortunately.

Edit: maybe a combination of building.claimed_by and eggs.flags.fertile (egg_flags.fertile? not sure) would work, unless you care about birds sitting on unfertilized eggs.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on October 08, 2018, 08:56:27 pm
Edit: maybe a combination of building.claimed_by and eggs.flags.fertile (egg_flags.fertile? not sure) would work, unless you care about birds sitting on unfertilized eggs.
I'm trying to work around this issue (http://bay12games.com/dwarves/mantisbt/view.php?id=10924) so the question is only whether the hen is sitting on eggs (and thus unable to mate again in time to lay her next clutch), I don't think it matters for my purpose whether the eggs are fertile or not. So I'll try it for now with just the building claim condition, I think that'll suffice.

I do wonder what the actual mechanics are though, it seems like there's a ton of guesses and assumptions around bird breeding.
Title: Re: DFHack 0.44.12-r1
Post by: canneddeath on October 09, 2018, 08:58:14 pm
In Dwarf Manipulator, how do you delete saved professions? I have like 15 clogging up my professions apply list and I want to get rid of them
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on October 09, 2018, 09:37:07 pm
They're saved in the "manipulator" folder in your DF folder. You can delete them from there.

I know someone was writing a patch to add this to the in-game UI, but apparently they never made a PR, so I have no idea where it is.
Title: Re: DFHack 0.44.12-r1
Post by: Kat on October 12, 2018, 12:21:49 pm
my current fortress is well over the population cap, and many citizens have off-site spouses, which causes a few unhappy thoughts about being away from family, unable to make romance, etc.

If I used the "migrants-now" script, how likely is it that any of these off-site spouses would be amongst the wave ?
Title: Re: DFHack 0.44.12-r1
Post by: taleden on October 12, 2018, 06:01:22 pm
A few assorted questions for Lua scripts:

edit: Nevermind, no longer relevant to what I'm working on.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on October 18, 2018, 03:39:07 pm
Has anyone experimented with manually creating social activities to coax a dwarf into, for example, praying or socializing to satisfy an unmet need? Or does anyone know what structure flags or values cause a dwarf's social activity to be urgent (shown in purple)?

I've tried a few times to replicate the structures that I can see when a dwarf is engaged in a particular activity (i.e. praying), but I can't seem to make them stick; the dwarf just cancels the activity and finds something else to do, as if it were invalid or something. So I'm not sure if I've missed something or if the game just decides to cancel it and override with a higher priority activity (which could also be why the dwarf never meets that need on their own in the first place).

Does anyone have any knowledge to share about manipulating social activities or is this uncharted territory?
Title: Re: DFHack 0.44.12-r1
Post by: Saiko Kila on October 19, 2018, 01:58:23 am
Is there a way for a Lua script to tell if a female egglayer is currently busy sitting on eggs in a nestbox? "unit.job.currentjob" and "unit.actions" don't seem to show it. I can use dfhack.buildings.findAtTile(), :getType() and .claimed_by to check that the bird is standing on her own claimed nest box which is probably close enough, but I wondered if someone knows a more direct way to test for egg-sitting.

You probably solved that on you own, but this is a function I use in my script to tell the birth time for pregnant females, it also checks for egglayers:
Spoiler (click to show/hide)

It takes unit as input, and returns a string which shows how many months, days or hours of pregnancy (or incubation) are left. "round" is a rounding function defined elsewhere.

I'd like to add, that the hen can be repeatedly imprisoned or even killed and the chicks would still hatch successfully, at least if the time left is small (like couple of days).
Title: Re: DFHack 0.44.12-r1
Post by: Atkana on October 19, 2018, 03:12:58 am
Has anyone experimented with manually creating social activities to coax a dwarf into, for example, praying or socializing to satisfy an unmet need? Or does anyone know what structure flags or values cause a dwarf's social activity to be urgent (shown in purple)?

I've tried a few times to replicate the structures that I can see when a dwarf is engaged in a particular activity (i.e. praying), but I can't seem to make them stick; the dwarf just cancels the activity and finds something else to do, as if it were invalid or something. So I'm not sure if I've missed something or if the game just decides to cancel it and override with a higher priority activity (which could also be why the dwarf never meets that need on their own in the first place).

Does anyone have any knowledge to share about manipulating social activities or is this uncharted territory?
I've not ever really gone much into social stuff, but I know some things I could point you to that might help:
Title: Re: DFHack 0.44.12-r1
Post by: xzaxza on October 19, 2018, 09:45:59 am
Hi,

I'm new. DFHack's pretty neat. Some of the documentation is bit poor though. :P

Anything specifically? Feel free to suggest improvements - I can't guarantee that I can improve docs for tools I'm unfamiliar with, but other people might.

"embark-skills points" and "points" are separate, but I think they work on the same screen, so it's possible that DFHack's layout for that screen is wrong (I don't remember checking that one). I'll investigate.

I'm pretty sure preferences are just stored in a vector, so I can't think of an obvious reason why adding "too many" would crash, or why "too many" would even be a possible state. Maybe the preferences it makes are malformed sometimes? In any case, that script is garbage (many hardcoded options for arbitrary preference combinations, lots of duplicated code, etc.), so it'd probably have to be rewritten some anyway.

Edit: you need to run "points" on the embark site-choosing screen (before the screen where you select items). That works in 0.44.12 for me. I can probably add support for the item-choosing screen too, but I can't support anything before a world is loaded, since the relevant field (df.global.world.worldgen.worldgen_parms.embark_points) is reset to the world-specific value when a world is loaded.

Edit: fixed "embark-skills points" as well. Its other options appeared to work fine.
Hi, I'm slow.

Well, mainly I think there could be more details about the arguments of many functions, and perhaps examples. Some of the functions took a while to figure out, even with the documentation. I could of course try to contribute myself too.

Yeah, it might be that I was trying some of the embark thingies at wrong screen, but good to know you fixed the ones that were affected!

I'm not sure what exactly was the problem with the preferences, but it seemed so, when adding new values would cause a crash, but if you also removed some values it wouldn't crash. But eh, could be the script added wrong values or corrupted something somehow. Especially considering it sometimes stored the same preference multiple times.
Title: Re: DFHack 0.44.12-r1
Post by: taleden on October 19, 2018, 10:20:16 am
the ones that might be relevant to social/break-related things being "TIME_SINCE_BREAK" and "ON_BREAK". In lua, these counters (and a lot more) can be found in the unit's status.misc_traits (provided they're active/whatever)
Hm, I can try those, although I'm not sure they're used any more in the current game version; in my fort of 112 citizens, not a single one has a misc_trait with id 16 (TimeSinceBreak) or 17 (OnBreak). Also, the problem I'm having isn't just with dwarves aborting my forced social activity for an actual job (teal text); they'll take a few steps pathing toward my activity and then stop and switch to a different idle activity (i.e. stop walking to the temple and instead go to Individual Combat Drill or to the library to read). That's why I was hoping to figure out the criteria for Purple! idle activities, to maybe get them to stick with what I assigned and not switch to something else.

The strength of a need can be modified in the unit's status.personality.current_soul.personality.needs, by changing its focus level. I know that a value of 400 is what it's set to when the need is met, and I believe that the value lowers as they get less focused, into the negatives. The numbers listed on the wiki (http://dwarffortresswiki.org/index.php/DF2014:Need) are probably right for reference. You might be able to get dwarves having purple needs by just setting the focus value super low.
Yes, those are the focus level values that I'm scanning for dwarves with severely unmet needs (for example I had a military dwarf with -200000 PrayOrMedidate, which I think is the lower limit, because he would always drill in his idle time and never pray).

After some experimentation though, I'm pretty sure the Purple! indicator isn't really very meaningful. I just compared the need data for a bunch of dwarves currently engaged in purple "Socialize!"/"Pray!" and green "Socialize"/"Pray" activities, and the determining factor seems to be whether the dwarf has Socialize, PrayOrMedidate, BeCreative, Excitement or AdmireArt focus levels of -10000 or lower, but there was no link between the activity and the actual urgent need -- a dwarf with -10k Socialize and +10k PrayOrMedidate would still show "Pray!", a dwarf with -10k BeCreative and +10k everything else would still "Socialize!", etc.
Title: Re: DFHack 0.44.12-r1
Post by: Quietust on October 19, 2018, 09:01:09 pm
Syndromes have some special triggers that allow their effects to activate based on the value of special counters (http://dwarffortresswiki.org/index.php/DF2014:Syndrome#Counter_Triggers), with the ones that might be relevant to social/break-related things being "TIME_SINCE_BREAK" and "ON_BREAK".
Funny you should mention those ones in particular - I just checked a disassembly of version 0.44.12, and those two actually don't exist anymore. "MOUNTAIN" is also no longer a Counter, but instead has its own distinct field in unit_soul.personality.
Title: Re: DFHack 0.44.12-r1
Post by: Atkana on October 20, 2018, 02:36:10 am
Syndromes have some special triggers that allow their effects to activate based on the value of special counters (http://dwarffortresswiki.org/index.php/DF2014:Syndrome#Counter_Triggers), with the ones that might be relevant to social/break-related things being "TIME_SINCE_BREAK" and "ON_BREAK".
Funny you should mention those ones in particular - I just checked a disassembly of version 0.44.12, and those two actually don't exist anymore. "MOUNTAIN" is also no longer a Counter, but instead has its own distinct field in unit_soul.personality.
Aw, that's a shame - I was getting some dumb ideas for syndromes I could make that use them :b
Title: Re: DFHack 0.44.12-r1
Post by: Clément on October 20, 2018, 03:13:52 am
When I run DFHack with valgrind, I get a lot of libruby.so errors. Is that expected and is there a way to suppress them?
Title: Re: DFHack 0.44.12-r1
Post by: Pvt. Pirate on October 20, 2018, 05:45:05 am
Has anyone experimented with manually creating social activities to coax a dwarf into, for example, praying or socializing to satisfy an unmet need? Or does anyone know what structure flags or values cause a dwarf's social activity to be urgent (shown in purple)?

I've tried a few times to replicate the structures that I can see when a dwarf is engaged in a particular activity (i.e. praying), but I can't seem to make them stick; the dwarf just cancels the activity and finds something else to do, as if it were invalid or something. So I'm not sure if I've missed something or if the game just decides to cancel it and override with a higher priority activity (which could also be why the dwarf never meets that need on their own in the first place).

Does anyone have any knowledge to share about manipulating social activities or is this uncharted territory?
I've not ever really gone much into social stuff, but I know some things I could point you to that might help:
  • Syndromes have some special triggers that allow their effects to activate based on the value of special counters (http://dwarffortresswiki.org/index.php/DF2014:Syndrome#Counter_Triggers), with the ones that might be relevant to social/break-related things being "TIME_SINCE_BREAK" and "ON_BREAK". In lua, these counters (and a lot more) can be found in the unit's status.misc_traits (provided they're active/whatever). You may have to manipulate these to encourage them to take breaks and stay on said breaks. It looks like there's also some counters that haven't been mapped(?) - I noticed that one of my units had a misc_trait of ID 63 (I think), which according to gm-editor is nil. As a side note, I may have now found a hacky way using this to stop all my civs that don't even have access to clothing from complaining about not having any clothes to wear!
  • The strength of a need can be modified in the unit's status.personality.current_soul.personality.needs, by changing its focus level. I know that a value of 400 is what it's set to when the need is met, and I believe that the value lowers as they get less focused, into the negatives. The numbers listed on the wiki (http://dwarffortresswiki.org/index.php/DF2014:Need) are probably right for reference. You might be able to get dwarves having purple needs by just setting the focus value super low. Bear in mind, also, that what needs units have varies from unit to unit. Apparently, I made a modtool for setting a unit's needs (https://github.com/Atkana/Dwarf-Fortress-Mods/blob/master/modtools/set-need.lua), don't know if I ever shared it anywhere :P
this calls for a special case of a dwarven mood that gets triggered by being unable to worship their deity for too long - "craft religios symbol":
the dorf claims a workshop and crafts a symbol of their deity - then goes to either their own room, a temple or the meeting hall and prays for an extended time.
Title: Re: DFHack 0.44.12-r1
Post by: Atkana on October 20, 2018, 06:16:17 am
I've been running into a problem with the following code, which I know used to be how you went about spawning creatures via reactions a while ago:
Code: [Select]
modtools/reaction-trigger -reactionName FOE_SPAWN_SPRITE -command [ modtools/create-unit -race FOE_ICE_SPRITE -setUnitToFort -name FOE_TUNDRA -location [ \\LOCATION ] -age 0 ]
I get the error
Code: [Select]
0.44.12\hack\lua\utils.lua:598: error: invalid arg: 5: race Looking into it, it seems like it's treating the commands for modtools/create-unit as commands for modtools/reaction-trigger (-race happens to be in the position where a fifth arg would be) when checking for valid args. If I add "race" to reaction-trigger's valid args list, I then get an error for setUnitToFort not being valid.

Have I simply screwed up the formatting for this, or is the script busted? Either way, I guess I can hack create-unit's args into reaction-trigger's valid args and see where that gets me for now :P
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on October 20, 2018, 02:26:57 pm
When I run DFHack with valgrind, I get a lot of libruby.so errors. Is that expected and is there a way to suppress them?
libruby.so isn't something we wrote (it's from Ruby), and we don't control what it does. Valgrind probably has a way to disable warnings for a specific library.

I get the error
Code: [Select]
0.44.12\hack\lua\utils.lua:598: error: invalid arg: 5: race
I think your syntax is ok, and the bracket looks like a normal bracket, not some funky Unicode one. Please post the full traceback, not just the one line - that will help identify whether this is originating from create-unit or reaction-trigger.
Title: Re: DFHack 0.44.12-r1
Post by: Atkana on October 21, 2018, 01:55:59 am
I think your syntax is ok, and the bracket looks like a normal bracket, not some funky Unicode one. Please post the full traceback, not just the one line - that will help identify whether this is originating from create-unit or reaction-trigger.
Haha, yeah sorry - I originally intended to post it all but couldn't figure out how to copy from the command prompt. I've got it now (unless there's a file everything's logged to and this is just a bit of it?)
Code: [Select]
...1\PERIDE~1.12-\Dwarf Fortress 0.44.12\hack\lua\utils.lua:598: error: invalid arg: 5: race
stack traceback:
        [C]: in function 'error'
        ...1\PERIDE~1.12-\Dwarf Fortress 0.44.12\hack\lua\utils.lua:598: in function 'utils.processArgs'
        ...tress 0.44.12/hack/scripts/modtools/reaction-trigger.lua:226: in local 'script_code'
        ...\PERIDE~1.12-\Dwarf Fortress 0.44.12\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
        (...tail calls...)
The exact line for reaction-trigger might be off by 8 because I just commented out my additions to the valid args table to get it erroring again :P The line that's mentioned in the error (line 226 for my commented-out-additions version) is the line local args = utils.processArgs({...}, validArgs)
Title: Re: DFHack 0.44.12-r1
Post by: Clément on October 21, 2018, 04:03:50 am
libruby.so isn't something we wrote (it's from Ruby), and we don't control what it does. Valgrind probably has a way to disable warnings for a specific library.

It's just to be sure. You could have uninitialized data passed into the library and only used later.

Here are the suppressions, I came up with:
Code: [Select]
{
ignore_rb_newobj_cond
Memcheck:Cond
...
fun:rb_newobj
}
{
ignore_rb_newobj_read8
Memcheck:Value8
...
fun:rb_newobj
}
{
ignore_ruby_xmalloc_cond
Memcheck:Cond
...
fun:ruby_xmalloc
}
{
ignore_ruby_xmalloc_read8
Memcheck:Value8
...
fun:ruby_xmalloc
}

I saw new errors, not related to ruby:
Code: [Select]
==4507== Conditional jump or move depends on uninitialised value(s)
==4507==    at 0x3E696CF3: mousequery_hook::interpose_fn_render() (mousequery.cpp:580)
==4507==    by 0x3D31DC8C: autochop_hook::interpose_fn_render() (autochop.cpp:822)
==4507==    by 0x6008A06: render_things() (graphics.cpp:537)
==4507==    by 0x5FD6E64: enablerst::async_loop() (enabler.cpp:319)
==4507==    by 0x5FD825E: call_loop(void*) (enabler.cpp:708)
==4507==    by 0x5C872EB: ??? (in /usr/lib64/libSDL-1.2.so.0.11.4)
==4507==    by 0x5CCA73E: ??? (in /usr/lib64/libSDL-1.2.so.0.11.4)
==4507==    by 0x7B96593: start_thread (pthread_create.c:463)
==4507==    by 0x7027E6E: clone (clone.S:95)
==4507==
==4507== Mismatched free() / delete / delete []
==4507==    at 0x4C3078C: operator delete[](void*) (vg_replace_malloc.c:621)
==4507==    by 0xB59DB3: ??? (in /home/clement/games/df/df_44_12_linux/libs/Dwarf_Fortress)
==4507==    by 0xB5A060: ??? (in /home/clement/games/df/df_44_12_linux/libs/Dwarf_Fortress)
==4507==    by 0x10AD3A1: ??? (in /home/clement/games/df/df_44_12_linux/libs/Dwarf_Fortress)
==4507==    by 0x8CACAA: ??? (in /home/clement/games/df/df_44_12_linux/libs/Dwarf_Fortress)
==4507==    by 0x9A3756: ??? (in /home/clement/games/df/df_44_12_linux/libs/Dwarf_Fortress)
==4507==    by 0x600DCDF: interfacest::loop() (interface.cpp:863)
==4507==    by 0x9CCDED: mainloop() (in /home/clement/games/df/df_44_12_linux/libs/Dwarf_Fortress)
==4507==    by 0x5FD6F59: enablerst::async_loop() (enabler.cpp:337)
==4507==    by 0x5FD825E: call_loop(void*) (enabler.cpp:708)
==4507==    by 0x5C872EB: ??? (in /usr/lib64/libSDL-1.2.so.0.11.4)
==4507==    by 0x5CCA73E: ??? (in /usr/lib64/libSDL-1.2.so.0.11.4)
==4507==  Address 0x5f331440 is 0 bytes inside a block of size 2 alloc'd
==4507==    at 0x4C2EBAB: malloc (vg_replace_malloc.c:299)
==4507==    by 0x543FD22: df::historical_figure::historical_figure() (in /home/clement/games/df/df_44_12_linux/hack/libdfhack-debug.so)
==4507==    by 0x5678200: DFHack::World::AddPersistentData(std::string const&) (World.cpp:270)
==4507==    by 0x3D319294: initialize() (autochop.cpp:227)
==4507==    by 0x3D319E00: plugin_onstatechange (autochop.cpp:919)
==4507==    by 0x548B179: DFHack::Plugin::on_state_change(DFHack::color_ostream&, DFHack::state_change_event) (PluginManager.cpp:566)
==4507==    by 0x548D393: DFHack::PluginManager::OnStateChange(DFHack::color_ostream&, DFHack::state_change_event) (PluginManager.cpp:981)
==4507==    by 0x53A8F7C: DFHack::Core::onStateChange(DFHack::color_ostream&, DFHack::state_change_event) (Core.cpp:2283)
==4507==    by 0x53A7940: DFHack::Core::doUpdate(DFHack::color_ostream&, bool) (Core.cpp:2015)
==4507==    by 0x53A7B7D: DFHack::Core::Update() (Core.cpp:2071)
==4507==    by 0x568318D: SDL_NumJoysticks (Hooks-linux.cpp:53)
==4507==    by 0x5FD6FF2: enablerst::async_loop() (enabler.cpp:348)
Using my own debug build of "DFHack version 0.44.12-r1 (development build 0.44.12-r1-53-ge56cb2a2) on x86_64"
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on October 21, 2018, 07:43:28 pm
libruby.so isn't something we wrote (it's from Ruby), and we don't control what it does. Valgrind probably has a way to disable warnings for a specific library.

It's just to be sure. You could have uninitialized data passed into the library and only used later.

Here are the suppressions, I came up with:
(snip)
Fair. The first one looks like a mousequery bug. It sounds a little familiar, although I can't find an open PR fixing it, so maybe I'm mistaken. The second one looks like a mismatch between our historical_figure constructor and DF's destructor - maybe DF is dynamically allocating memory in the constructor? I've run into a likely-related issue where overriding operator new and operator delete crashes when freeing something allocated (I think?) in df::historical_figure::historical_figure(). Not really sure how to fix that one, so let me know if you uncover anything.

I think your syntax is ok, and the bracket looks like a normal bracket, not some funky Unicode one. Please post the full traceback, not just the one line - that will help identify whether this is originating from create-unit or reaction-trigger.
Haha, yeah sorry - I originally intended to post it all but couldn't figure out how to copy from the command prompt. I've got it now (unless there's a file everything's logged to and this is just a bit of it?)
Code: [Select]
...1\PERIDE~1.12-\Dwarf Fortress 0.44.12\hack\lua\utils.lua:598: error: invalid arg: 5: race
stack traceback:
        [C]: in function 'error'
        ...1\PERIDE~1.12-\Dwarf Fortress 0.44.12\hack\lua\utils.lua:598: in function 'utils.processArgs'
        ...tress 0.44.12/hack/scripts/modtools/reaction-trigger.lua:226: in local 'script_code'
        ...\PERIDE~1.12-\Dwarf Fortress 0.44.12\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
        (...tail calls...)
The exact line for reaction-trigger might be off by 8 because I just commented out my additions to the valid args table to get it erroring again :P The line that's mentioned in the error (line 226 for my commented-out-additions version) is the line local args = utils.processArgs({...}, validArgs)
Just to confirm, you haven't modified hack/lua/utils.lua at all, right?
Title: Re: DFHack 0.44.12-r1
Post by: Atkana on October 22, 2018, 01:18:32 am
Just to confirm, you haven't modified hack/lua/utils.lua at all, right?
Not to my knowledge, no. I've only opened it before to check the place it was erroring.
Title: Re: DFHack 0.44.12-r1
Post by: em312s0n on October 29, 2018, 11:33:02 pm
Does anyone know how to edit custom stockpiles via editing the .dfstock files from Dwarf Fortress 0.44.12\stocksettings ? I tried opening it and I just couldn't make sense of it.

I was trying to make a custom stockpile for every food and drink that all of my dwarves like to eat but having to go through and search for every ingredient via the menu is pretty tedious (90 solid consumables and 41 drinks).
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on October 30, 2018, 11:13:25 am
They're binary files - you can't edit them directly. A script could probably create the stockpile settings that you want, though
Title: Re: DFHack 0.44.12-r1
Post by: Betrix5068 on November 01, 2018, 06:30:42 pm
3dveins is giving me a "Discontinuous layer 1 at (73,86,120)" error. I'm guessing this might be because I have an ocean embark, but am not sure.

Is there any way to rectify this? Already tried fixveins but it didn't seem to do anything. I like using 3dveins.

I'd like to know this too. seaside, lakeside, and riverside settlements are quite fun IMO and it's a damn shame if 3dveins doesn't work on them. That "discontinuous layer 1 at (30,510,80)" thing is pretty sad to see. Is there some way to force it?
Title: Re: DFHack 0.44.12-r1
Post by: Mike Mayday on November 13, 2018, 01:53:46 pm
Hello,
I'm having a bit of trouble with keybindings. I want to switch the mousewheel to execute
twbt tilesize 16 16
and
twbt tilesize 32 32

1. what should I input in dfhack.init to achieve this?
2. when i press CTRL+F1, a list of keybindings is brought up. There's Shift-O and Shift-P there, which exectute twbt tilesize smaller and bigger.
This should not happen because Shift-P opens petitions. Where can I disable this setting?
Title: Re: DFHack 0.44.12-r1
Post by: Rumrusher on November 13, 2018, 02:08:02 pm
(http://www.truimagz.com/host/rumrusher/folder6/daynight-cycle-for-fortmode.gif)
so kinda was wondering if it possible to get the advmode day night cycle working for fortmode?
what I got here is a gamemode set to 1 and Gametype set to 0.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on November 13, 2018, 02:10:20 pm
Hello,
I'm having a bit of trouble with keybindings. I want to switch the mousewheel to execute
twbt tilesize 16 16
and
twbt tilesize 32 32

1. what should I input in dfhack.init to achieve this?
The keybinding command does not support the mouse wheel, so that's not possible.
Quote
2. when i press CTRL+F1, a list of keybindings is brought up. There's Shift-O and Shift-P there, which exectute twbt tilesize smaller and bigger.
This should not happen because Shift-P opens petitions. Where can I disable this setting?
dfhack.init (or a file it loads)
Title: Re: DFHack 0.44.12-r1
Post by: Pvt. Pirate on November 13, 2018, 03:24:47 pm
(http://www.truimagz.com/host/rumrusher/folder6/daynight-cycle-for-fortmode.gif)
so kinda was wondering if it possible to get the advmode day night cycle working for fortmode?
what I got here is a gamemode set to 1 and Gametype set to 0.
looks promising!
Title: Re: DFHack 0.44.12-r1
Post by: Saiko Kila on November 15, 2018, 07:33:44 am
There's one bug with position.lua script, which manifests itself on the last day of the year.

Spoiler (click to show/hide)

This is caused by algorithm calculating the month to be 13th. This algorithm actually causes each last day of the month to be treated as the 0th day of the subsequent month.
Title: Re: DFHack 0.44.12-r1
Post by: Roses on November 15, 2018, 03:01:00 pm
Background: For my detailed unit viewer I am getting description information by reading the unit description screen and parsing the text by color and order so that I can use different parts of it in different places. This works, but if the colors are ever changed or the order the description is outputted in changes it will break my system. I was thinking of instead generating the description myself by reading the units various values and creating the corresponding description strings.

Question: I think I remember seeing a script that created descriptions from the units numbers (e.g. a unit with >41 LAW would have "is an absolute believer in the rule of law"), does anyone know where/if this script exists? Or if it doesn't exist does anyone know a better method for recreating the description screen without reading from the description screen?
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on November 15, 2018, 05:53:36 pm
@Roses: This script ought to carry you some of the way: https://github.com/PatrikLundell/scripts/blob/own_scripts/thoughts.lua (https://github.com/PatrikLundell/scripts/blob/own_scripts/thoughts.lua). Note that it's a web page with the script on it, not a link to a .lua file.
Title: Re: DFHack 0.44.12-r1
Post by: Roses on November 16, 2018, 12:07:43 pm
@Roses: This script ought to carry you some of the way: https://github.com/PatrikLundell/scripts/blob/own_scripts/thoughts.lua (https://github.com/PatrikLundell/scripts/blob/own_scripts/thoughts.lua). Note that it's a web page with the script on it, not a link to a .lua file.

That's the exact script I remembered! Yay, I wasn't being silly this time. Do you mind if I use some/all of it (with credit of course)? Then I would just need to do something similar for attributes, appearance, and health and it would be perfect.
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on November 16, 2018, 01:56:20 pm
@Roses: This script ought to carry you some of the way: https://github.com/PatrikLundell/scripts/blob/own_scripts/thoughts.lua (https://github.com/PatrikLundell/scripts/blob/own_scripts/thoughts.lua). Note that it's a web page with the script on it, not a link to a .lua file.

That's the exact script I remembered! Yay, I wasn't being silly this time. Do you mind if I use some/all of it (with credit of course)? Then I would just need to do something similar for attributes, appearance, and health and it would be perfect.
I don't care much about credits, apart from when people explicitly claim to have made stuff they've gotten from elsewhere. After all, the whole DFHack script thing is a process of building upon stuff others have made before (mine being no exception, of course). You're free to make use of it as is or take the parts you need, although it would probably be best if your script didn't end up with the same name, as that can lead to confusion down the line.
I believe some parts of the script will have to be adjusted when a new DFHack version appears, as I think there are references in there to fields that have been identified in DFHack pull requests, but not yet incorporated into a new version (I know a couple of new thoughts ought to be adjusted, but I believe they'll still work with indices rather than names).

As you may see, I started out trying to replicate the thoughts screen (for use with gremlins, visitors, and the odd distracted cat), but changed course to rather try to display all the info in the structures, rather than the truncated display DF provides such as e.g. which song Urist enjoyed singing, or who Urist fought when in conflict (DF provides some of that in the top thought at times).

When it comes to attributes, etc. I can't provide any support as I haven't messed with those parts.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on November 16, 2018, 02:01:45 pm
There's one bug with position.lua script, which manifests itself on the last day of the year.

Reported on GitHub (https://github.com/DFHack/dfhack/issues/1413), thanks.
Title: Re: DFHack 0.44.12-r1
Post by: Roses on November 20, 2018, 12:27:23 pm
Which version of lua are we using? And more specifically, does it handle integer divide (i.e. '//')? I would test but I'm going to be away from a DF enabled computer for a couple days and I don't really like using math.floor(), not really sure why.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on November 20, 2018, 12:30:19 pm
5.3 as of DF 0.43.05
Title: Re: DFHack 0.44.12-r1
Post by: Fleeting Frames on November 23, 2018, 04:20:57 am
Hello,
I'm having a bit of trouble with keybindings. I want to switch the mousewheel to execute
twbt tilesize 16 16
and
twbt tilesize 32 32
Within dfhack, one option I can think of is to have invisible lua screen overlaying game screen, set zoom speed to 0 in init, and then have the lua screen catch mousewheels and pass these commands to dfhack.

The reasons why this is not optimal was most recently discussed here (http://www.bay12forums.com/smf/index.php?topic=164123.msg7862300#msg7862300).

I think for your idea a much better option might be utilizing things other than plain dfhack; dfhack-run allows execution of command in currently running df(hack) instance, so you could use, say, your OS' mouse gestures binding to call them when mouse is over df (may not be available in all OSes).
Title: Re: DFHack 0.44.12-r1
Post by: Roses on November 27, 2018, 10:31:45 am
I'm having some trouble with the custom screen gui stuff. I can't seem to get the correct widget as the "active" one. I set active to true, and set the other parts widgets on the viewscreen to false, but I'm still not able to scroll through the list. I can hit enter and go deeper in the tree, but I can only ever do it for the first item since I can't change what was selected. I had this working before, but I must have broken something. I do have several viewscreens open/created (but only one visible at a time), do I need to set all of their actives to false? Is there an easier way to change the focus that I don't know about?
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on November 27, 2018, 10:40:24 am
Are you sure you're using the correct scrolling keys? The list widgets support either the primary or secondary scroll keys, depending on how they're configured. Otherwise, there's not a lot I can do without code.
Title: Re: DFHack 0.44.12-r1
Post by: Roses on November 27, 2018, 11:03:43 am
Are you sure you're using the correct scrolling keys? The list widgets support either the primary or secondary scroll keys, depending on how they're configured. Otherwise, there's not a lot I can do without code.

I thought I tried both. Here is the code, the relevant parts are probably the viewing functions and the screen functions. Sorry for the formatting, it looks a lot better in my text editor with custom colors/indents/etc... I can switch views easy enough, and all the information is displayed correctly it's just the lists are always colored with the inactive_pen color

Code: [Select]
local gui = require 'gui'
local dialog = require 'gui.dialogs'
local widgets =require 'gui.widgets'
local guiScript = require 'gui.script'
local utils = require 'utils'
local split = utils.split_string
local persistTable = require 'persist-table'
local textC     = COLOR_DARYGRAY
local cursorC   = COLOR_LIGHTRED
local inactiveC = COLOR_CYAN
local views = {'main','detailedView','healthView','thoughtView','classView','featView','spellView'}

classSystem     = false
featSystem      = false
spellSystem     = false
civSystem       = false
ECreatureSystem = false

function center(str, length)
 local string1 = str
 local string2 = string.format("%"..tostring(math.floor((length-#string1)/2)).."s"..string1,"")
 local string3 = string.format(string2.."%"..tostring(math.ceil((length-#string1)/2)).."s","")
 return string3
end

function tchelper(first, rest)
  return first:upper()..rest:lower()
end

function Set (list)
  local set = {}
  for _, l in ipairs(list) do set[l] = true end
  return set
end

function getTargetFromScreens()
 local my_trg
 if dfhack.gui.getSelectedUnit(true) then
  my_trg=dfhack.gui.getSelectedUnit(true)
 else
  qerror("No valid target found")
 end
 return my_trg
end

local guiFunctions = dfhack.script_environment('functions/gui')
 
DetailedUnitView = defclass(DetailedUnitView, gui.FramedScreen)
DetailedUnitView.ATTRS={
                        frame_style = gui.BOUNDARY_FRAME,
                        frame_title = "Detailed Unit Viewer",
               }

function DetailedUnitView:init(args)
 self.target = args.target
 if persistTable.GlobalTable.roses then
  systems = persistTable.GlobalTable.roses.Systems
  if systems.Class            == 'true' then classSystem     = true end
  if systems.Feat             == 'true' then featSystem      = true end
  if systems.Spell            == 'true' then spellSystem     = true end
  if systems.Civilization     == 'true' then civSystem       = true end
  if systems.EnhancedCreature == 'true' then ECreatureSystem = true end
 end
 self.ClassSystem    = classSystem
 self.SpellSystem    = spellSystem
 self.FeatSystem     = featSystem
 self.CivSystem      = civSystem
 self.EnhancedSystem = ECreatureSystem

 -- Bottom UI
 self:addviews{
   widgets.Panel{
     view_id  = 'bottomView',
     frame    = { b = 0, h = 1},
     subviews = {
       widgets.Label{
         view_id = 'bottom_ui',
         frame   = { l = 0, t = 0},
         text    = 'filled by updateBottom()'
       }
     }
   }
 }
 self.subviews.bottomView.visible = true -- Alwayes true

 -- Create Frames
 ---- Main
 self:addMainScreen()     -- 3x3 - AX, AY, AZ, BX, BY, BZ, CX, CY, CZ

 ---- Sub Views
 self:addDetailsScreen()  -- 3x2 - D_ABX, D_ABY, D_AZ, D_BZ
 self:addHealthScreen()   -- 2x1 - H_AX, H_AY
 self:addThoughtsScreen() -- 3x1 - T_AX, T_AY, T_AZ
 self:addClassScreen()    -- 2x2 - C_AX, C_BX, C_ABY
 self:addFeatScreen()     -- 2x2 - F_AX, F_BX, F_ABY
 self:addSpellScreen()    -- 2x2 - S_AX, S_BX, S_ABY

 -- Fill Frames
 self:fillMain()
 self:fillDetails()
 self:fillHealth()
 self:fillThoughts()
 if self.ClassSystem then self:fillClasses('All','List') end
 if self.FeatSystem  then self:fillFeats('All','List')   end
 if self.SpellSystem then self:fillSpells('All','List')  end

 -- Set Starting View
 for _,view in pairs(self.subviews) do
  view.visible = true
 end
 self:viewMain()
end

--= Screen Functions (create the screens)
function DetailedUnitView:addMainScreen()
---- Main
 --[[ Positioning
 Main:
   |       X            |      Y         |       Z           |
 --|--------------------|----------------|-------------------|
 A | Base Information   | Description    | Attributes        |
 --|--------------------|----------------|-------------------|
 B | Membership/Worship | Appearance     | Skills            |
 --|--------------------|----------------|-------------------|
 C | Class Information  | Health         | Stats/Resistances |
 -------------------------------------------------------------
 Bottom UI:
  Details
 ]]
 self:getPositioningMain()
 self:addviews{
   widgets.Panel{
     view_id     = 'main',
     frame       = { l = 0, r = 0 },
     frame_inset = 1,
     subviews    = {
       widgets.List{
         view_id = 'AX',
         frame   = {l = self.AX.anchor.left, t = self.AX.anchor.top, w = self.X_width, h = self.AX.height},
       },
       widgets.List{
         view_id = 'AY',
         frame   = {l = self.AY.anchor.left, t = self.AY.anchor.top, w = self.Y_width, h = self.AY.height},
       },
       widgets.List{
         view_id = 'AZ',
         frame   = {l = self.AZ.anchor.left, t = self.AZ.anchor.top, w = self.Z_width, h = self.AZ.height},
       },
       widgets.List{
         view_id = 'BX',
         frame   = {l = self.BX.anchor.left, t = self.BX.anchor.top, w = self.X_width, h = self.BX.height},
       },
       widgets.List{
         view_id = 'BY',
         frame   = {l = self.BY.anchor.left, t = self.BY.anchor.top, w = self.Y_width, h = self.BY.height},
       },
       widgets.List{
         view_id = 'BZ',
         frame   = {l = self.BZ.anchor.left, t = self.BZ.anchor.top, w = self.Z_width, h = self.BZ.height},
       },
       widgets.List{
         view_id = 'CX',
         frame   = {l = self.CX.anchor.left, t = self.CX.anchor.top, w = self.X_width, h = self.CX.height},
       },
       widgets.List{
         view_id = 'CY',
         frame   = {l = self.CY.anchor.left, t = self.CY.anchor.top, w = self.Y_width, h = self.CY.height},
       },
       widgets.List{
         view_id = 'CZ',
         frame   = {l = self.CZ.anchor.left, t = self.CZ.anchor.top, w = self.Z_width, h = self.CZ.height},
       },
     }
   }
 }
end
function DetailedUnitView:addDetailsScreen()
------ Detailed Information
 --[[
 Detailed Information:
   |      X       |      Y      |      Z      |
 --|--------------|-------------|-------------|
 A |              |             | Resistances |
 --| Attributes   | Skills      |-------------|
 B |              |             | Stats       |
 ----------------------------------------------
 Bottom UI:
  Back
 ]]
 self:getPositioningDetails()
 self:addviews{
   widgets.Panel{
     view_id     = 'detailedView',
     frame       = { l = 0, r = 0 },
     frame_inset = 1,
     subviews    = {
       widgets.List{
         view_id = 'D_ABX',
         frame   = {l = self.D_ABX.anchor.left, t = self.D_ABX.anchor.top, w = self.D_X_width, h = self.D_ABX.height},
       },
       widgets.List{
         view_id = 'D_ABY',
         frame   = {l = self.D_ABY.anchor.left, t = self.D_ABY.anchor.top, w = self.D_Y_width, h = self.D_ABY.height},
       },
       widgets.List{
         view_id = 'D_AZ',
         frame   = {l = self.D_AZ.anchor.left, t = self.D_AZ.anchor.top, w = self.D_Z_width, h = self.D_AZ.height},
       },
       widgets.List{
         view_id = 'D_BZ',
         frame   = {l = self.D_BZ.anchor.left, t = self.D_BZ.anchor.top, w = self.D_Z_width, h = self.D_BZ.height},
       },
     }
   }
 }
end
function DetailedUnitView:addHealthScreen()
------ Health
 --[[
 Health Information:
   |      X       |      Y      |
 --|--------------|-------------|
 A | Health Stats | Syndromes   |
 --------------------------------
 Bottom UI:
  Back
 ]]
 self:getPositioningHealth()
 self:addviews{
   widgets.Panel{
     view_id     = 'healthView',
     frame       = { l = 0, r = 0 },
     frame_inset = 1,
     subviews    = {
       widgets.List{
         view_id = 'H_AX',
         frame   = {l = self.H_AX.anchor.left, t = self.H_AX.anchor.top, w = self.H_X_width, h = self.H_AX.height},
       },
       widgets.List{
         view_id = 'H_AY',
         frame   = {l = self.H_AY.anchor.left, t = self.H_AY.anchor.top, w = self.H_Y_width, h = self.H_AY.height},
       },
     }
   }
 }
end
function DetailedUnitView:addThoughtsScreen()
------ Thoughts
 --[[
 Thoughts and Preferences:
   |    X     |      Y      |   Z    |
 --|----------|-------------|--------|
 A | Thoughts | Preferences | Traits |
 -------------------------------------
 Bottom UI:
  Back
 ]]
 self:getPositioningThoughts()
 self:addviews{
   widgets.Panel{
     view_id     = 'thoughtView',
     frame       = { l = 0, r = 0 },
     frame_inset = 1,
     subviews    = {
       widgets.List{
         view_id = 'T_AX',
         frame   = {l = self.T_AX.anchor.left, t = self.T_AX.anchor.top, w = self.T_X_width, h = self.T_AX.height},
       },
       widgets.List{
         view_id = 'T_AY',
         frame   = {l = self.T_AY.anchor.left, t = self.T_AY.anchor.top, w = self.T_Y_width, h = self.T_AY.height},
       },
       widgets.List{
         view_id = 'T_AZ',
         frame   = {l = self.T_AZ.anchor.left, t = self.T_AZ.anchor.top, w = self.T_Z_width, h = self.T_AZ.height},
       },
     }
   }
 }
end
function DetailedUnitView:addClassScreen()
------ Class Information
 --[[
 Classes:
   |      X       |      Y      |
 --|--------------|-------------|
 A | Header       |             |
 --|--------------| Details     |
 B | Class List   |             |
 --------------------------------
 Bottom UI:
  Back
 ]]
 self:getPositioningClasses()
 self:addviews{
   widgets.Panel{
     view_id     = 'classView',
     frame       = { l = 0, r = 0 },
     frame_inset = 1,
     subviews    = {
       widgets.List{
         view_id = 'C_AX',
         frame   = {l = self.C_AX.anchor.left, t = self.C_AX.anchor.top, w = self.C_X_width, h = self.C_AX.height},
       },
       widgets.List{
         view_id    = 'C_BX',
         frame      = {l = self.C_BX.anchor.left, t = self.C_BX.anchor.top, w = self.C_X_width, h = self.C_BX.height},
         on_select  = self:callback('fillClasses'),
         text_pen   = textC,
         cursor_pen = cursorC,
inactive_pen = inactiveC
       },
       widgets.List{
         view_id = 'C_ABY',
         frame   = {l = self.C_ABY.anchor.left, t = self.C_ABY.anchor.top, w = self.C_Y_width, h = self.C_ABY.height},
       },
     }
   }
 }
end
function DetailedUnitView:addFeatScreen()
------ Feat Information
 --[[
 Feats:
   |      X       |      Y      |
 --|--------------|-------------|
 A | Header       |             |
 --|--------------| Details     |
 B | Feat List    |             |
 --------------------------------
 Bottom UI:
  Back
 ]]
 self:getPositioningFeats()
 self:addviews{
   widgets.Panel{
     view_id     = 'featView',
     frame       = { l = 0, r = 0 },
     frame_inset = 1,
     subviews    = {
       widgets.List{
         view_id = 'F_AX',
         frame   = {l = self.F_AX.anchor.left, t = self.F_AX.anchor.top, w = self.F_X_width, h = self.F_AX.height},
       },
       widgets.List{
         view_id    = 'F_BX',
         frame      = {l = self.F_BX.anchor.left, t = self.F_BX.anchor.top, w = self.F_X_width, h = self.F_BX.height},
         on_select  = self:callback('fillFeats'),
         text_pen   = textC,
         cursor_pen = cursorC,
       },
       widgets.List{
         view_id = 'F_ABY',
         frame   = {l = self.F_ABY.anchor.left, t = self.F_ABY.anchor.top, w = self.F_Y_width, h = self.F_ABY.height},
       },
     }   
   }
 }
end
function DetailedUnitView:addSpellScreen()
------ Spell Information
 --[[
 Spells:
   |      X       |      Y      |
 --|--------------|-------------|
 A | Header       |             |
 --|--------------| Details     |
 B | Spell List   |             |
 --------------------------------
 Bottom UI:
  Back
 ]]
 self:getPositioningSpells()
 self:addviews{
   widgets.Panel{
     view_id     = 'spellView',
     frame       = { l = 0, r = 0 },
     frame_inset = 1,
     subviews    = {
       widgets.List{
         view_id = 'S_AX',
         frame   = {l = self.S_AX.anchor.left, t = self.S_AX.anchor.top, w = self.S_X_width, h = self.S_AX.height},
       },
       widgets.List{
         view_id    = 'S_BX',
         frame      = {l = self.S_BX.anchor.left, t = self.S_BX.anchor.top, w = self.S_X_width, h = self.S_BX.height},
         on_select  = self:callback('fillSpells'),
         text_pen   = textC,
         cursor_pen = cursorC,
       },
       widgets.List{
         view_id = 'S_ABY',
         frame   = {l = self.S_ABY.anchor.left, t = self.S_ABY.anchor.top, w = self.S_Y_width, h = self.S_ABY.height},
       },
     }   
   }
 }
end

--= Positioning Functions (get the width, height, and anchor points for each screen)
function DetailedUnitView:getPositioningMain()
 local AX = {anchor = {}, width = 40, height = 10}
 local AY = {anchor = {}, width = 40, height = 10}
 local AZ = {anchor = {}, width = 40, height = 10}
 local BX = {anchor = {}, width = 40, height = 10}
 local BY = {anchor = {}, width = 40, height = 10}
 local BZ = {anchor = {}, width = 40, height = 10}
 local CX = {anchor = {}, width = 40, height = 10}
 local CY = {anchor = {}, width = 40, height = 10}
 local CZ = {anchor = {}, width = 40, height = 10}
 local X_width = math.max(AX.width,BX.width,CX.width)
 local Y_width = math.max(AY.width,BY.width,CY.width)
 local Z_width = math.max(AZ.width,BZ.width,CZ.width)
----
 AX.anchor.top  = 0
 AY.anchor.top  = 0
 AZ.anchor.top  = 0
 AX.anchor.left = 0
 AY.anchor.left = X_width + 4
 AZ.anchor.left = X_width + Y_width + 8
 BX.anchor.top  = AX.height + 1
 BY.anchor.top  = AY.height + 1
 BZ.anchor.top  = AZ.height + 1
 BX.anchor.left = 0
 BY.anchor.left = X_width + 4
 BZ.anchor.left = X_width + Y_width + 8
 CX.anchor.top  = AX.height + BX.height + 2
 CY.anchor.top  = AY.height + BY.height + 2
 CZ.anchor.top  = AZ.height + BZ.height + 2
 CX.anchor.left = 0
 CY.anchor.left = X_width + 4
 CZ.anchor.left = X_width + Y_width + 8
----
 self.AX = AX
 self.AY = AY
 self.AZ = AZ
 self.BX = BX
 self.BY = BY
 self.BZ = BZ
 self.CX = CX
 self.CY = CY
 self.CZ = CZ
 self.X_width = X_width
 self.Y_width = Y_width
 self.Z_width = Z_width
end
function DetailedUnitView:getPositioningDetails()
 local ABX = {anchor = {}, width = 40, height = 40}
 local ABY = {anchor = {}, width = 40, height = 40}
 local AZ  = {anchor = {}, width = 40, height = 20}
 local BZ  = {anchor = {}, width = 40, height = 20}
 local X_width = ABX.width
 local Y_width = ABY.width
 local Z_width = math.max(AZ.width,BZ.width)
----
 ABX.anchor.top  = 0
 ABY.anchor.top  = 0
 ABX.anchor.left = 0
 ABY.anchor.left = X_width + 4
 AZ.anchor.top  = 0
 AZ.anchor.left = X_width + Y_width + 8
 BZ.anchor.top  = AZ.height + 1
 BZ.anchor.left = X_width + Y_width + 8
----
 self.D_ABX = ABX
 self.D_ABY = ABY
 self.D_AZ  = AZ
 self.D_BZ  = BZ
 self.D_X_width = X_width
 self.D_Y_width = Y_width
 self.D_Z_width = Z_width
end
function DetailedUnitView:getPositioningHealth()
 local AX = {anchor = {}, width = 60, height = 40}
 local AY = {anchor = {}, width = 60, height = 40}
 local X_width = AX.width
 local Y_width = AY.width
----
 AX.anchor.top  = 0
 AY.anchor.top  = 0
 AX.anchor.left = 0
 AY.anchor.left = X_width + 4
----
 self.H_AX = AX
 self.H_AY = AY
 self.H_X_width = X_width
 self.H_Y_width = Y_width
end
function DetailedUnitView:getPositioningThoughts()
 local AX = {anchor = {}, width = 40, height = 40}
 local AY = {anchor = {}, width = 40, height = 40}
 local AZ = {anchor = {}, width = 40, height = 40}
 local X_width = AX.width
 local Y_width = AY.width
 local Z_width = AZ.width
----
 AX.anchor.top = 0
 AY.anchor.top = 0
 AZ.anchor.top = 0
 AX.anchor.left = 0
 AY.anchor.left = X_width + 4
 AZ.anchor.left = X_width + Y_width + 8
----
 self.T_AX = AX
 self.T_AY = AY
 self.T_AZ = AZ
 self.T_X_width = X_width
 self.T_Y_width = Y_width
 self.T_Z_width = Z_width
end
function DetailedUnitView:getPositioningClasses()
 local AX  = {anchor = {}, width = 40, height = 3}
 local BX  = {anchor = {}, width = 40, height = 37}
 local ABY = {anchor = {}, width = 80, height = 40}
 local X_width = math.max(AX.width,BX.width)
 local Y_width = ABY.width
----
 AX.anchor.top  = 0
 AX.anchor.left = 0
 BX.anchor.top  = AX.height + 1
 BX.anchor.left = 0
 ABY.anchor.top  = 0
 ABY.anchor.left = X_width + 4
----
 self.C_AX  = AX
 self.C_BX  = BX
 self.C_ABY = ABY
 self.C_X_width = X_width
 self.C_Y_width = Y_width
end
function DetailedUnitView:getPositioningFeats()
 local AX  = {anchor = {}, width = 40, height = 3}
 local BX  = {anchor = {}, width = 40, height = 37}
 local ABY = {anchor = {}, width = 80, height = 40}
 local X_width = math.max(AX.width,BX.width)
 local Y_width = ABY.width
----
 AX.anchor.top  = 0
 AX.anchor.left = 0
 BX.anchor.top  = AX.height + 1
 BX.anchor.left = 0
 ABY.anchor.top  = 0
 ABY.anchor.left = X_width + 4
----
 self.F_AX  = AX
 self.F_BX  = BX
 self.F_ABY = ABY
 self.F_X_width = X_width
 self.F_Y_width = Y_width
end
function DetailedUnitView:getPositioningSpells()
 local AX  = {anchor = {}, width = 40, height = 3}
 local BX  = {anchor = {}, width = 40, height = 37}
 local ABY = {anchor = {}, width = 80, height = 40}
 local X_width = math.max(AX.width,BX.width)
 local Y_width = ABY.width
----
 AX.anchor.top  = 0
 AX.anchor.left = 0
 BX.anchor.top  = AX.height + 1
 BX.anchor.left = 0
 ABY.anchor.top  = 0
 ABY.anchor.left = X_width + 4
----
 self.S_AX  = AX
 self.S_BX  = BX
 self.S_ABY = ABY
 self.S_X_width = X_width
 self.S_Y_width = Y_width
end

--= Filling Functions (call functions/gui to get the information to put on the screen)
function DetailedUnitView:fillMain()
 local unit = self.target
 local grid = {'AX', 'AY', 'AZ', 'BX', 'BY', 'BZ', 'CX', 'CY', 'CZ'}
 local output = {}
 for i,g in pairs(grid) do
  output[g] = guiFunctions.getMainOutput(g, unit, self[g].width, self.ClassSystem)
  self.subviews[g]:setChoices(output[g])
 end
end
function DetailedUnitView:fillDetails()
 local unit = self.target
 local grid = {'D_ABX', 'D_ABY', 'D_AZ', 'D_BZ'}
 local output = {}
 for i,g in pairs(grid) do
  output[g] = guiFunctions.getDetailsOutput(g, unit, self[g].width)
  self.subviews[g]:setChoices(output[g])
 end
end
function DetailedUnitView:fillHealth()
 local unit = self.target
 local grid = {'H_AX', 'H_AY'}
 local output = {}
 for i,g in pairs(grid) do
  output[g] = guiFunctions.getHealthOutput(g, unit, self[g].width)
  self.subviews[g]:setChoices(output[g])
 end
end
function DetailedUnitView:fillThoughts()
 local unit = self.target
 local grid = {'T_AX', 'T_AY', 'T_AZ'}
 local output = {}
 for i,g in pairs(grid) do
  output[g] = guiFunctions.getThoughtsOutput(g, unit, self[g].width)
  self.subviews[g]:setChoices(output[g])
 end
end
function DetailedUnitView:fillClasses(filter,details)
 local unit = self.target
 local output = {}
 if details == nil then return end
 
 if details and details ~= 'List' then
  output = guiFunctions.getClassesOutput('C_ABY', unit, self.C_ABY.width, details)
  self.subviews.C_ABY:setChoices(output)
 else
  local grid = {'C_AX','C_BX'}
  local output = {}
  for i,g in pairs(grid) do
   output[g] = guiFunctions.getClassesOutput(g, unit, self[g].width, filter)
   self.subviews[g]:setChoices(output[g])
  end
 end
end
function DetailedUnitView:fillFeats(filter,details)
 local unit = self.target
 local output = {}
 if details == nil then return end
 
 if details and details ~= 'List' then
  output = guiFunctions.getFeatsOutput('F_ABY', unit, self.F_ABY.width, details)
  self.subviews.F_ABY:setChoices(output)
 else
  local grid = {'F_AX','F_BX'}
  for i,g in pairs(grid) do
   output[g] = guiFunctions.getFeatsOutput(g, unit, self[g].width, filter)
   self.subviews[g]:setChoices(output[g])
  end
 end
end
function DetailedUnitView:fillSpells(filter,details)
 local unit = self.target
 local output = {}
 if details == nil then return end
 
 if details and details ~= 'List' then
  output = guiFunctions.getSpellsOutput('S_ABY', unit, self.S_ABY.width, details)
  self.subviews.S_ABY:setChoices(output)
 else
  local grid = {'S_AX','S_BX'}
  local output = {}
  for i,g in pairs(grid) do
   output[g] = guiFunctions.getSpellsOutput(g, unit, self[g].width, filter)
   self.subviews[g]:setChoices(output[g])
  end
 end
end

--= Viewing Functions (change which screen is active and visible)
function DetailedUnitView:updateBottom(screen)
 if      screen == 'Main' then
   text = {
           { key = 'CUSTOM_SHIFT_A', text = ': Details   ', on_activate = self:callback('viewDetails')  },
           { key = 'CUSTOM_SHIFT_H', text = ': Health    ', on_activate = self:callback('viewHealth')   },
           { key = 'CUSTOM_SHIFT_T', text = ': Thoughts  ', on_activate = self:callback('viewThoughts') },
          }
   if self.ClassSystem then table.insert(text, {key = 'CUSTOM_SHIFT_C', text = ': Classes  ', on_activate = self:callback('viewClasses')}) end
   if self.ClassSystem then table.insert(text, {key = 'CUSTOM_SHIFT_F', text = ': Feats    ', on_activate = self:callback('viewFeats')  }) end
   if self.ClassSystem then table.insert(text, {key = 'CUSTOM_SHIFT_S', text = ': Spells   ', on_activate = self:callback('viewSpells') }) end
  elseif screen == 'Details' then
   text = {
           { text = 'ESC: Back  '},
          }
  elseif screen == 'Health' then
   text = {
           { text = 'ESC: Back  '},
          }
  elseif screen == 'Thoughts' then
   text = {
           { text = 'ESC: Back  '},
          }
  elseif screen == 'Classes' then
   text = {
           { key = 'CUSTOM_SHIFT_A', text = ': Show All Classes          ', on_activate = function () self:fillClasses('All','List')       end },
           { key = 'CUSTOM_SHIFT_C', text = ': Show Civilization Classes ', on_activate = function () self:fillClasses('Civ','List')       end },
           { key = 'CUSTOM_SHIFT_K', text = ': Show Known Classes        ', on_activate = function () self:fillClasses('Learned','List')   end },
           { key = 'CUSTOM_SHIFT_V', text = ': Show Available Classes    ', on_activate = function () self:fillClasses('Available','List') end },
           { text = 'ESC: Back'}
          }
  elseif screen == 'Feats' then
   text = {
           { key = 'CUSTOM_SHIFT_A', text = ': Show All Feats   ', on_activate = function () self:fillFeats('All','List')     end },
           { key = 'CUSTOM_SHIFT_C', text = ': Show Class Feats ', on_activate = function () self:fillFeats('Class','List')   end },
           { key = 'CUSTOM_SHIFT_K', text = ': Show Known Feats ', on_activate = function () self:fillFeats('Learned','List') end },
           { text = 'ESC: Back'}
          }
  elseif screen == 'Spells' then
   text = {
           { key = 'CUSTOM_SHIFT_A', text = ': Show All Spells          ', on_activate = function () self:fillSpells('All','List')     end },
           { key = 'CUSTOM_SHIFT_C', text = ': Show Civilization Spells ', on_activate = function () self:fillSpells('Civ','List')     end },
           { key = 'CUSTOM_SHIFT_K', text = ': Show Known Spells        ', on_activate = function () self:fillSpells('Learned','List') end },
           { key = 'CUSTOM_SHIFT_L', text = ': Show Classes Spells      ', on_activate = function () self:fillSpells('Class','List')   end },
           { text = 'ESC: Back'}
          }
  end
  self.subviews.bottom_ui:setText(text)
end
function DetailedUnitView:resetView()
 for _,view in pairs(views) do
  self.subviews[view].visible = false
  self.subviews[view].active  = false
 end
 --self.subviews.bottom_ui.visible = true
end
function DetailedUnitView:viewMain()
 self:updateBottom('Main')
 self:resetView()

 self.subviews.main.visible = true
end
function DetailedUnitView:viewDetails()
 self:updateBottom('Details')
 self:resetView()

 self.subviews.detailedView.visible = true
end
function DetailedUnitView:viewHealth()
 self:updateBottom('Health')
 self:resetView()

 self.subviews.healthView.visible = true
end
function DetailedUnitView:viewThoughts()
 self:updateBottom('Thoughts')
 self:resetView()

 self.subviews.thoughtView.visible = true
end
function DetailedUnitView:viewClasses()
 self:updateBottom('Classes')
 self:resetView()

 self.subviews.classView.visible = true
 self.subviews.classView.active = true
 self.subviews.C_BX.active  = true
 self.subviews.C_BX:setSelected(2)
printall(self.subviews.classView.subviews.C_BX.frame)
end
function DetailedUnitView:viewFeats()
 self:updateBottom('Feats')
 self:resetView()

 self.subviews.featView.visible = true
 self.subviews.F_BX.active      = true
end
function DetailedUnitView:viewSpells()
 self:updateBottom('Spells')
 self:resetView()
 
 self.subviews.spellView.visible = true
 self.subviews.S_BX.active       = true
end

--= Base Functions
function DetailedUnitView:onInput(keys)
 if keys.LEAVESCREEN then
  if self.subviews.main.visible then
   self:dismiss()
  else
   self:viewMain()
  end
 else
  DetailedUnitView.super.onInput(self, keys)
 end
end
function show_editor(trg)
 local screen = DetailedUnitView{target=trg}
 screen:show()
end

show_editor(getTargetFromScreens())
Title: Re: DFHack 0.44.12-r1
Post by: Silverwing235 on November 29, 2018, 04:01:41 pm
Apologies if its the wrong place....How to put this? You know how the default of exportlegends unpacking into DF root can be rather annoying for some people, myself included? Well,  I suggest that it unpack into the empty folder 'legends' in DF root instead.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on November 29, 2018, 07:17:51 pm
It matches the behavior of the vanilla legends exporter, which we cannot change (in particular, it directly triggers some of the vanilla export features, e.g. maps). It might be possible to do this by comparing the contents of the DF folder before and after exporting and moving any new files, although that seems potentially risky if users make their own files for whatever reason. In any case, this is a good place to ask.
Title: Re: DFHack 0.44.12-r1
Post by: Droggarth on December 01, 2018, 08:39:06 pm
Is there a way to change one's species after selecting a species during character creation with dfhack? I've been doing that with DF Tool previously but he hasn't updated it for a while and so it doesn't work for .44.12.

Mainly posting for curiosity and in hopes of being able to do same with dfhack.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on December 01, 2018, 09:05:58 pm
Everything that can be done with DF Tool can be done with DFHack. I don't know the exact field in question off the top of my head, but it's probably in the adventurer setup viewscreen.
Title: Re: DFHack 0.44.12-r1
Post by: Droggarth on December 01, 2018, 10:37:26 pm
Ah, nice so it's doable. All I need then now are some commands, windows.. something, more info basically. Gonna look up some.
Title: Re: DFHack 0.44.12-r1
Post by: Droggarth on December 01, 2018, 10:38:09 pm
(Accidental double post)
Title: Re: DFHack 0.44.12-r1
Post by: bloop_bleep on December 09, 2018, 09:43:04 pm
I have two questions.
Title: Re: DFHack 0.44.12-r1
Post by: PatrikLundell on December 10, 2018, 04:00:12 am
@bloop_bleep: Firstly, why do you perform all of these narrowing type conversions, rather than keep the original types? Secondly, if you actually need to perform a narrowing type conversion and are sure it actually is safe, it's usually better to perform an explicit conversion in each of those cases than to turn off warnings.
Title: Re: DFHack 0.44.12-r1
Post by: FantasticDorf on December 10, 2018, 09:36:42 am
the ones that might be relevant to social/break-related things being "TIME_SINCE_BREAK" and "ON_BREAK". In lua, these counters (and a lot more) can be found in the unit's status.misc_traits (provided they're active/whatever)
Hm, I can try those, although I'm not sure they're used any more in the current game version; in my fort of 112 citizens, not a single one has a misc_trait with id 16 (TimeSinceBreak) or 17 (OnBreak). Also, the problem I'm having isn't just with dwarves aborting my forced social activity for an actual job (teal text); they'll take a few steps pathing toward my activity and then stop and switch to a different idle activity (i.e. stop walking to the temple and instead go to Individual Combat Drill or to the library to read). That's why I was hoping to figure out the criteria for Purple! idle activities, to maybe get them to stick with what I assigned and not switch to something else.

'SeekStation' goal paths in 'Path' of gui/editor causes a lot of this erratic behaviour in conjunction with how locations are defined . I believe Toady fixed up a blew up error regarding this when he fixed museum zones not working  (http://www.bay12games.com/dwarves/mantisbt/view.php?id=10646)(they still dont work but they don't flat out not work) by simply tagging it to correct the mistake so that in theory dwarves without 'buildings/locations' would go there.

Seekstation is not voluntarily shut off either, as the most blatent effects can be seen by setting to idle activitity none <1> or (MeetingLocation <18> / MeetingLocationBuilding <19>) which do the same but are location-friendly. Dwarves will run into libraries without books or meeting zones without location areas and immediately reroute to the nearest other one upon realising there's nowhere to go for the goal.

When they arrive at a 'building' they will unset their goalpathing to 'none' and remain -3000 xyz still until they have a job or pressing need presented to them. Which is the critical flaw why setting needs in 'status' to 10,000 will never yield any kind of result because the actual pathfinding is abysmally poor and will always throw and abandon them in a room to fill needs they dont need endlessly.

Taking a guess, combat drills must probably also be doing this.
Title: Re: DFHack 0.44.12-r1
Post by: Zeronet on December 10, 2018, 05:09:52 pm
Is stonesense maintained by anybody? There seems to be an issue where constructed walls & floors are using the sprite for smoothed stone walls & floors, rather than the sprite for constructed walls.

Title: Re: DFHack 0.44.12-r1
Post by: bloop_bleep on December 10, 2018, 07:07:56 pm
@bloop_bleep: Firstly, why do you perform all of these narrowing type conversions, rather than keep the original types?

Haha, believe me, I tried. It usually happens in the case where I’m dividing two values, and I can’t seem to be able to find the right combination of types such that the division is allowed and works as expected while also the end result matches the type desired by DF.

As for explicit typecasting, I might do that, but honestly sometimes I just can’t be bothered. Besides, it produces the same effect, and probably hurts readability.

If you know, is there any way to set compiler options globally (i.e. for the entire DFHack build)?

Additionally, could I have the username of the person who wrote steam-engine.cpp, so I could message them.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on December 11, 2018, 12:33:17 am
Is stonesense maintained by anybody? There seems to be an issue where constructed walls & floors are using the sprite for smoothed stone walls & floors, rather than the sprite for constructed walls.
I always dread questions that start out like that, because the question usually contains "Stonesense is crashing" and the answer is usually "no". This is probably one of the most benign issues I've heard of with it. But unfortunately, we don't have anyone around who's familiar with Stonesense any more, and I don't really know how to fix that either. (Stonesense is pretty broken on macOS, and even more so on newer versions due to Stonesense's architectural choices, so I don't have a good way to develop it or test fixes.)

@bloop_bleep: Firstly, why do you perform all of these narrowing type conversions, rather than keep the original types?

Haha, believe me, I tried. It usually happens in the case where I’m dividing two values, and I can’t seem to be able to find the right combination of types such that the division is allowed and works as expected while also the end result matches the type desired by DF.
I mean, on principle, I don't want to tell you how to disable warnings, because you should fix the warnings instead. What types specifically are you trying to divide? What's the warning you're getting? Can you give an example (or all) of the code you're trying to compile?

Quote
As for explicit typecasting, I might do that, but honestly sometimes I just can’t be bothered. Besides, it produces the same effect, and probably hurts readability.
Yeah, I was about to suggest typecasting everything as an ugly solution.

Quote
If you know, is there any way to set compiler options globally (i.e. for the entire DFHack build)?
Absolutely, but it requires recompiling literally everything.
Quote
Additionally, could I have the username of the person who wrote steam-engine.cpp, so I could message them.
You can answer this with "git log" or on GitHub: go to https://github.com/DFHack/dfhack/blob/master/plugins/steam-engine.cpp, click "History", and go to the end. That takes me here (https://github.com/DFHack/dfhack/commits/master/plugins/steam-engine.cpp). (Angavrilov = ag on the forums, although he hasn't been active in a long time.)
I can try to ask questions about steam-engine... are they about the code in general or specific features of the plugin?

Edit: if it's this:
I have two questions.
  • df::item::addWear takes three arguments, an int16_t (which I assume is the amount of wear) and two other Booleans. What do these last two arguments mean? I ask because steam-engine.cpp seems to use both the (true, false) and (true, true) combinations, and neither of these seem to actually change the wear value when inspected with lua.
the answer is in df.items.xml in df-structures (https://github.com/DFHack/df-structures/blob/0.44.12-r1/df.items.xml#L404-L406):
Code: [Select]
            <vmethod ret-type='bool' name='addWear'>
                <int32_t name='delta'/> <bool name='simple'/> <bool name='lose_masterwork'/>
            </vmethod>
Vmethod parameter names don't get transferred to the generated headers like field names do, unfortunately.
Title: Re: DFHack 0.44.12-r1
Post by: bloop_bleep on December 15, 2018, 11:20:50 pm
The code is at this (https://github.com/bloop-bleep-b12/moving-machines) git repository. (Erm... sorry about the inconsistent tabs/spaces. I haven't noticed that before, since kate displays them the same. I'll fix it next commit; in the meantime your text editor should be able to replace one with the other, or you could just look past it for now.) Looking at some of the warnings in the compilation log, I actually have no idea why some of them are there, given that none of the types involved are defined in my code...

For example, lines 259-263:
Code: [Select]
        return df::coord {
            pos.x - ref.x,
            pos.y - ref.y,
            pos.z - ref.z
        };

gcc warns on the middle three lines that
Code: [Select]
home/misha/df_linux/dfhack/plugins/moving-machines.cpp: In member function ‘df::coord MovingMachine::get_rel_pos(df::coord)’:
/home/misha/df_linux/dfhack/plugins/moving-machines.cpp:260:19: warning: narrowing conversion of ‘(((int)pos.df::coord::x) - ((int)((MovingMachine*)this)->MovingMachine::ref.df::coord::x))’ from ‘int’ to ‘uint16_t {aka short unsigned int}’ inside { } [-Wnarrowing]
             pos.x - ref.x,
             ~~~~~~^~~~~~~
/home/misha/df_linux/dfhack/plugins/moving-machines.cpp:261:19: warning: narrowing conversion of ‘(((int)pos.df::coord::y) - ((int)((MovingMachine*)this)->MovingMachine::ref.df::coord::y))’ from ‘int’ to ‘uint16_t {aka short unsigned int}’ inside { } [-Wnarrowing]
             pos.y - ref.y,
             ~~~~~~^~~~~~~
/home/misha/df_linux/dfhack/plugins/moving-machines.cpp:262:19: warning: narrowing conversion of ‘(((int)pos.df::coord::z) - ((int)((MovingMachine*)this)->MovingMachine::ref.df::coord::z))’ from ‘int’ to ‘uint16_t {aka short unsigned int}’ inside { } [-Wnarrowing]
             pos.z - ref.z
             ~~~~~~^~~~~~~

despite that pos and ref are both of type df::coord. Note that gcc says that the coordinate values are casted to type int, though they clearly aren't. This is truly baffling.
Title: Re: DFHack 0.44.12-r1
Post by: FantasticDorf on December 16, 2018, 05:37:30 am
Is stonesense maintained by anybody? There seems to be an issue where constructed walls & floors are using the sprite for smoothed stone walls & floors, rather than the sprite for constructed walls.

Similarly it is lacking some artistic assets like stuff for pedistals/ + objects (plus probably instruments) which would be really neat introduced in the newer version since right now they are replaced by yellow empty boxes, i don't think @Dirst is still availbile but watching this space if any of us can pull together for a collaborative art project to maintain it i think would be useful.

A third party tool to draw/view file XML images might be useful in this regard, unless other such applications already exist.
Title: Re: DFHack 0.44.12-r1
Post by: Clément on December 16, 2018, 06:00:37 am
...

I found some explanations here (https://stackoverflow.com/questions/10047956/c-uint16-t-subtraction-behavior-in-gcc).
Title: Re: DFHack 0.44.12-r1
Post by: bloop_bleep on December 16, 2018, 01:11:19 pm
...

I found some explanations here (https://stackoverflow.com/questions/10047956/c-uint16-t-subtraction-behavior-in-gcc).

Well that is truly strange. Subtract two int16_ts and get an int, which generates a warning when you try to stuff it into another int16_t. Using explicit typecasting would be very messy and confusing, as well as not at all necessary, so in this case I’d rather just disable these specific warnings. If anyone could inform me how to do that it would be greatly appreciated.

EDIT: Thank you, lethosor, for where to find parameter names. Guess the problem is not the Boolean arguments, then, even though I thought I made sure that df::item::addWear was being called with the correct wear delta... Does it not do what I think it does? That is, does it not change the wear member variable of the item?
Title: Re: DFHack 0.44.12-r1
Post by: Silverwing235 on December 16, 2018, 04:11:58 pm
A third party tool to draw/view file XML images might be useful in this regard, unless other such applications already exist.
So, maybe something like this (https://download.cnet.com/XML-Viewer/3000-7241_4-10223729.html) would be appropriate, unless I'm badly misreading the request here, let alone outright mistaken? 
Title: Re: DFHack 0.44.12-r1
Post by: Clément on December 16, 2018, 05:19:52 pm
Why are your warnings mentioning uint16_t, if int16_t are used in df::coord? The reason it is cast to int is the same: C/C++ doesn't do operation on types smaller than int. But there maybe something more.

-Wno-narrowing disables the warnings for gcc, but it may hide warnings in other places where it would be useful.
Title: Re: DFHack 0.44.12-r1
Post by: bloop_bleep on December 16, 2018, 07:14:31 pm
Why are your warnings mentioning uint16_t, if int16_t are used in df::coord? The reason it is cast to int is the same: C/C++ doesn't do operation on types smaller than int. But there maybe something more.

-Wno-narrowing disables the warnings for gcc, but it may hide warnings in other places where it would be useful.

Yes, but I would like to know how to set certain compiler flags for a specific plugin, or failing that, DFHack in entirety.
Title: Re: DFHack 0.44.12-r1
Post by: Clément on December 16, 2018, 08:09:52 pm
Try target_compile_options (https://cmake.org/cmake/help/v3.0/command/target_compile_options.html).

Nevermind, try DFHACK_PLUGIN(pluginname COMPILE_FLAGS_GCC options_here) instead.
Title: Re: DFHack 0.44.12-r1
Post by: Rumrusher on December 20, 2018, 06:43:35 am
in should have tested this sooner news I found away to bypass blocks on entering the travel menu, uhh I realized I should have just deleted the message that pop up using  dfhack which boots you directly to freely move where ever. so folks in flight can just write a script that clears the "you can't fast travel if your in the air' message and be able to move around the map whereever and whenever.
sadly this doesn't say help when you can't move to activate the fast travel mode like say being surrounded by all sides but it's a start.

this also means one could write up a script to fast travel during the cackling.
Though it's possible to just clear the bogeyman timer in the UI_advmode section to do that.

or probably when one's bleeding to death.
Title: Re: DFHack 0.44.12-r1
Post by: bloop_bleep on December 23, 2018, 05:42:27 pm
More questions!

How does PersistentDataItem... um, work? That is, what functions am I supposed to call and when? I only have to retrieve data with a certain key when the world is loaded and save data when the world is unloaded. E.g., do I need to call anything special when I get an SC_MAP_UNLOADED event or do I just modify the value of the PersistentDataItem? And do I call GetPersistentData again in the store_data function or do I keep the PersistentDataItem that I obtained in the load_data function?

A simple code skeleton to demonstrate this would be greatly appreciated.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on December 23, 2018, 05:43:42 pm
What language?
For C++, autogems uses it in a fairly simple manner. autochop is a little more advanced.
Title: Re: DFHack 0.44.12-r1
Post by: bloop_bleep on December 23, 2018, 06:25:24 pm
C++, please.

As for autogems, I couldn’t glean much useful information from that because it didn’t use the string member of PersistentDataItem, just the integr values. I looked at workflow earlier, but there was so much surrounding code and not very many comments so I couldn’t parse that at all.

In my case, just to clarify, I’m trying to make it so that when the map is loaded, it attempts to read the a single persistent data item and unpack the binary data, but do nothing if it doesn’t exist. When the map is unloaded, it writes to the item with the same key, and does create it if it doesn’t exist.

EDIT: And the problem arises from the fact that whenever I boot up a save with plugin data saved, it says that the return value of GetPersistentData is valid, but the size of the binary data is inexplicably only 1 byte, which causes my unpacking function to crash. Which is why I was thinking I wasn’t saving the data properly.
Title: Re: DFHack 0.44.12-r1
Post by: lethosor on December 23, 2018, 07:09:44 pm
The string member is a string, which means that if you're storing arbitrary binary data in it, it will get truncated at the first null character.

If you can't represent your data as a <16KB ASCII string, you might want to use a different solution, like files. One feature of DF is that any .dat files in data/save/current will get copied into the region folder when the game is saved. You can copy them from the region folder when the game is loaded yourself, read/write to them there, and DF will take care of making sure they're only copied back when the game is saved. Of course, you'd want to avoid excessive reads/writes for performance reasons (one benefit of the PersistentData API is that everything is in memory).
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on December 27, 2018, 10:18:03 pm
0.44.12-r2 is up (finally): https://github.com/DFHack/dfhack/releases/tag/0.44.12-r2

It contains fixes for several longstanding issues from r1, including issues with ui.main and ui.squads, which broke "tweak hotkey-clear" among other things. I'm sorry it's taken this long to get these fixes out, and merge some people's additions. Real life happened and this kept getting delayed.

I think we could use more active people on the "core" DFHack team (i.e. the GitHub org) - I'd much rather have other people reviewing pull requests than have me continue to be a bottleneck. If you're decently familiar with the DFHack codebase, or interested in DFHack development in general, feel free to shoot me a PM or reply here. There's not much onboarding to speak of, unfortunately; documenting our GitHub workflow has been on my list of things to do for a long time, and I will try again to get that done soon. Let me know if anything else would be useful for devs new to DFHack as well.

Anyway, many thanks to BenLubar for maintaining and fixing the build server earlier today. Also, thanks to those who contributed to this release in any way. I had to enforce a "feature freeze" of sorts, so I know some PRs didn't make it in, but I'll do my best to get r3 out quickly with those included.
Title: Re: DFHack 0.44.12-r2
Post by: feelotraveller on December 29, 2018, 07:18:31 pm
lethosor (and the rest of the DFHack team) your efforts are legendary in the mountainhome.

Thanks for the new release.  :)
Title: Re: DFHack 0.44.12-r2
Post by: FantasticDorf on January 01, 2019, 08:57:09 am
Point of discussion for 44.12 r1 units you embark with sentient pets, you can set labours for them from labour manager, however if you import (legally using [ANIMAL] tags, everything counts with [ANIMAL_ALWAYS_AVAILIBLE]) sentient or half sentient creatures in via caravans you can't modify their labours. I've messed around with different things  but i can't find anything determinable or out of place to explain this, imported creatures are rarely plain peasants though and usually specialised into a role.
Quote
  • Children of the original intelligent pets i embark with are legal to change the labours of as long as my original trolls breed with each other, as for my function im creating a 'slave force' (just a profession name) of trolls that do jobs such as strong stand-in's for squad members, digging work and creating clothing & armor sized properly for other trolls when manipulated via labour manager with success

Its kind of vexing to know there's a value somewhere or some combinations that enable and disable labour manager utility like this, how exactly are sentients configured and changed to exclude them from R2's changelog?

Same applies for trying to set captured creatures in cages like gorlaks, its all very fiddly and im not sure if im overlooking some functions, even when set properly into civilised populations they're hard to intergrate or put into a position of a sentient pet so that they might petition later without a natural [PET_EXOTIC] tag (which i might have to fiddle with animal classes later to get around and implement)
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on January 01, 2019, 12:16:32 pm
I assume you're talking about manipulator (u-l), not labormanager? If that's the case, here is the code (https://github.com/DFHack/dfhack/blob/0.44.12-r2/plugins/manipulator.cpp#L1154-L1170) determining which units can't be edited in manipulator. Other than that, I'm not sure what you're saying about r1 vs r2. Looking at the changes (https://github.com/DFHack/dfhack/compare/0.44.12-r1...0.44.12-r2), neither library/modules/Units.cpp or plugins/manipulator.cpp changed between 0.44.12-r1 and 0.44.12-r2.
Title: Re: DFHack 0.44.12-r2
Post by: FantasticDorf on January 01, 2019, 12:42:26 pm
I assume you're talking about manipulator (u-l), not labormanager? If that's the case, here is the code (https://github.com/DFHack/dfhack/blob/0.44.12-r2/plugins/manipulator.cpp#L1154-L1170) determining which units can't be edited in manipulator. Other than that, I'm not sure what you're saying about r1 vs r2. Looking at the changes (https://github.com/DFHack/dfhack/compare/0.44.12-r1...0.44.12-r2), neither library/modules/Units.cpp or plugins/manipulator.cpp changed between 0.44.12-r1 and 0.44.12-r2.

Perhaps, yeah that looks like it, oops, not labour manager (you can see where its misleading on name in u-l). I was looking directly at the changelog on the git screen regarding my comments on that, i haven't ported over to R2 yet (which where the new tame function might be handy if it takes a lot of the work out of gm-editing handling my second complaint)

Quote
labormanager:

    stopped assigning labors to ineligible dwarves, pets, etc.
    stopped assigning invalid labors
So obviously getting this straight, without touching the manipulator it should be a upgrade for a seperate plugin that i wasn't tapping into. Alright, all sweet.

Also
Code: [Select]
if (!ENUM_ATTR(profession, can_assign_labor, unit->profession))
cur->allowEdit = false;
could be the culprit since they arrived pre-specialised, so ill just gui set them to peasant or none and it should free them up, ill keep it in mind. Thanks again and nice work.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on January 01, 2019, 12:55:17 pm
Yeah, the labormanager changes are unrelated.

"tame" is a Lua script, not a function you can use from a plugin easily (although it literally just sets one or two training level fields, from what I remember, so it's not hard to reimplement).

Also
Code: [Select]
if (!ENUM_ATTR(profession, can_assign_labor, unit->profession))
cur->allowEdit = false;
could be the culprit since they arrived pre-specialised, so ill just gui set them to peasant or none and it should free them up, ill keep it in mind. Thanks again and nice work.
What profession specifically are they arriving with?
can_assign_labor is an attribute of each item in the "profession" enum, defined in the xml files here (https://github.com/DFHack/df-structures/blob/master/df.skills.xml). Specifically, only professions with <item-attr name='can_assign_labor' value='false'/> would be excluded by this check, which are:
CHILD
BABY
DRUNK
MONSTER_SLAYER
SCOUT
BEAST_HUNTER
SNATCHER
MERCENARY

If the units don't have one of those professions, the check you quoted can't be the issue. My guess would be one of the civ membership checks instead, so check those.
Title: Re: DFHack 0.44.12-r2
Post by: FantasticDorf on January 01, 2019, 01:25:40 pm
Oh right, occupation profession, no not those. They're arriving with regular job professions but overall they're pretty unworkable and locked into doing those defined jobs, unlike the ones i brought with me on embark that were stray and assignable (via manipulator) to anything and inherit that state.

And uh, heh didn't mean to say function, just not the best choice of words, i knew you meant lua.

Its all possible labour professions that im seeing (besides ones like alchemist, druid, per civ defined), they arrive with them randomly assigned and if you were to look around in a dark tower site, many of the Trolls there also have professions, compared to some that do not so i wonder whether it's abducting the wrong sort for merchants. My recently bought aquisition i was dissapointed with not being able to manipulate was a troll with a bright green animal caretaker profession with relevant skill attached.

Its a easy experiment to replicate, if you dont mind having a slightly odd world, doing and observing a dwarf site would be easier in general. I've put some basic code below which would quick start, wherin you can wait for the caravan to bring some in a cage, or order some when making a trade agreement with the liason. Or just embark with one or two if they have no pet-value assigned for the free state i described at the start compared to merchant brought ones.
Spoiler (click to show/hide)
Title: Re: DFHack 0.44.12-r2
Post by: bloop_bleep on January 02, 2019, 02:04:54 am
Hey, it seems in my plugin, burrows that I create are not saved in the save file, since whenever I boot it up again it doesn’t appear in the ‘w’ menu or df.building.get_vector() according to lua. I made sure to allocate the burrow on the heap, placement-new all non-trivial data members, set all data members to valid values, then insert_into_vector the burrow using its id as a key, in that order. What could I be doing wrong?

EDIT: Nevermind, it seems that in my SC_MAP_UNLOADED event handling I inadvertently deleted the burrows.

EDIT 2: A different question now. How does add_subdirectory work? Does it just add all files in a certain directory to a plugin of the same name? Can I still set compiler flags?
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on January 02, 2019, 04:43:19 am
Code: [Select]
df.global.ui_advmode.message=""
oh here's a single line script that probably good for bypassing messages that prevent you from entering the travel menu.
kinda have a hunch on gaining access to traveling around the world but probably requires converting a Campsite to a town, then having said town move with the player.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on January 02, 2019, 11:35:00 am
EDIT 2: A different question now. How does add_subdirectory work? Does it just add all files in a certain directory to a plugin of the same name? Can I still set compiler flags?
add_subdirectory is a CMake feature, not specific to DFHack at all. It looks for a CMakeLists.txt in the specified folder and includes it (with a few things like CMAKE_CURRENT_SOURCE_DIR changed accordingly). DFHack uses it in a lot of CMakeLists.txt files to include others - you'll see it a few times in the root CMakeLists.txt file too. In the case of plugins, the CMakeLists.txt in the subfolder typically creates a plugin of the same name, but it doesn't have to.

FantasticDorf: in order to figure out what's causing the issue with the trolls, you can highlight one of them in the units list and run the checks I linked individually from the lua interpreter. For example:
Code: [Select]
[DFHack]# lua
[lua]# ~dfhack.units.isOwnCiv(unit)
[lua]# ~unit.flags2.bits.visitor
(If the professions aren't ones I listed, the ENUM_ATTR check isn't relevant.)
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on January 03, 2019, 02:33:08 am
Spoiler: 'boat science' (click to show/hide)
Title: Re: DFHack 0.44.12-r2
Post by: TV4Fun on January 03, 2019, 04:29:00 pm
Does DFHack provide a straightforward way to find out what method a particular address in memory belongs to? I know that DFHack has a pretty complete symbol table, and that at least on Windows, these addresses are relocatable. I'm trying to profile DF to find out where the most CPU time is being hogged. It's possible in Windows to attach to an existing executable and profile the CPU usage, but without a symbol table, all I can get are memory addresses. My quick profile of DF 0.44.12 64 bit with DFHack on Windows 10 shows that 87.56% of its time is spent in Dwarf Fortress.exe!0x007ff65d3f68ef. Is there a way I can find out what that address is in the executable?
Title: Re: DFHack 0.44.12-r2
Post by: bloop_bleep on January 03, 2019, 04:47:46 pm
It depends on the executable format. I know that it's ELF for Linux and MZ for Windows, so which operating system are you using, and is it 32-bit or 64-bit?

EDIT: Nvm, you said you were using 64-bit Windows. I need to read up again on the MZ format, but I think there's probably a section header of some kind near the beginning of the executable (that is, before the code/program data.) You would have to find the entry for the .text section, look up the file and memory offsets, and use that to calculate the location of the function in the file.

EDIT2: Just to verify, open up the executable in any editor (hex or otherwise) and check whether it says MZ in the beginning.

EDIT3: Actually, apparently it's in PE format, because PE files also start with MZ. Wow, good job, Microsoft.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on January 03, 2019, 05:49:46 pm
I don't know why you would need to parse the executable header. It should simply be a matter of translating an in-memory address to a file address, from what I understand, which involves subtracting a fixed offset (at least, that's how the process works for every data, code, and vtable offset that DFHack cares about). The only difference on Windows is that the offset isn't fixed across DF runs, but I think dfhack.internal.getRebaseDelta() in Lua will give you the appropriate offset.

Does DFHack provide a straightforward way to find out what method a particular address in memory belongs to? ... Is there a way I can find out what that address is in the executable?
The first question to me sounds like "what does the function at address X do", which is harder to answer. First off, are you sure your profiler isn't just reporting a main loop of some kind?
If it's a virtual method, those are fairly straightforward, since we have all of the vtable addresses available, but chances are it isn't. Quietust is fairly good at reverse-engineering these sorts of these things, but I'm not.
(I answered the second question above, I think.)
Title: Re: DFHack 0.44.12-r2
Post by: TV4Fun on January 03, 2019, 06:32:30 pm
EDIT3: Actually, apparently it's in PE format, because PE files also start with MZ. Wow, good job, Microsoft.
I think the MZ prefix on PE files is done for backward compatibility. The MZ format was used by DOS, and if you try to open a Windows executable in DOS, it will show a message saying it needs to be run under Windows.
Title: Re: DFHack 0.44.12-r2
Post by: bloop_bleep on January 03, 2019, 08:35:24 pm
The only difference on Windows is that the offset isn't fixed across DF runs

Really? That doesn't make much sense, because the address for every instruction would vary, so the loader would have to change the parameter for every absolute jump every time DF runs. Or am I missing something?

I think the way you calculate the file offset from the memory address is using the formula

file_offset = memory_address - (VirtualAddress + ImageBase) + PointerToRawData

where ImageBase is in the optional header and VirtualAddress & PointerToRawData are in the section header entry for .text. I looked in the executable and apparently

ImageBase = 0x00 40 00 00
VirtualAddress = 0x00 10 00 00
PointerToRawData = 0x00 04 00 00

so that should be enough to calculate any file offset you wish.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on January 04, 2019, 01:03:34 am
Yes, really, it's ASLR. Specifically, ImageBase in your formula isn't fixed across runs. DF disables ASLR on every platform but Windows. As for jumps, most jumps are relative, not absolute. Those that are absolute probably do some calculations to account for this.

Process-windows.cpp deals with this extensively, by the way, as does devel/find-offsets.lua and the lua libraries it uses.
Title: Re: DFHack 0.44.12-r2
Post by: bloop_bleep on January 04, 2019, 01:47:51 am
Wow, sorry, I forgot that existed.

I'll take a look at those files to see how they work, out of curiosity. Man, it must be difficult to delve into such a low level and understand all the myriad, obscure systems at play there, and I can only imagine how much more difficult it must be to debug it when your program inadvertently jumps into the middle of printf which then attempts to read about a dozen floats from its arguments, thus completely destroying the stack and any trace of what went wrong or even which function caused the problem.

I think I'll stay with my safe, predictable high-level programming for now.  :P
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on January 04, 2019, 05:11:08 am
so uhh this camp boat stuff seem to be opening to weird discoveries

so far to list things off, Camps keep every change done to it, also keeps any units that were on the site, and any smaller sites that can load up onto the camp will be saved to the camp when you unload the map, and those changes keep with the camp including anyone from the site that got merged with the camp are now with the camp citizens.

if someone say builds a camp in the ocean then moves the camp the camp would probably be a giant pool of water.

Title: Re: DFHack 0.44.12-r2
Post by: TV4Fun on January 04, 2019, 12:16:18 pm
 According to Wikipedia (https://en.wikipedia.org/wiki/Portable_Executable#Relocations), the PE format generally includes absolute addresses, and if it's not loaded at its preferred address, the loader has to manually go through and change every address in the code before running. Yes, really.
Title: Re: DFHack 0.44.12-r2
Post by: Warmist on January 04, 2019, 04:45:46 pm
According to Wikipedia (https://en.wikipedia.org/wiki/Portable_Executable#Relocations), the PE format generally includes absolute addresses, and if it's not loaded at its preferred address, the loader has to manually go through and change every address in the code before running. Yes, really.
Yeah that usually happens for DLLs. You can not expect the code to be loaded in same location as there could be other dlls that want to be in that location (even without ASLR). So there is such thing as relocation table that list all addresses that need to be fixed when loading. You could compile code as PIC (https://en.wikipedia.org/wiki/Position-independent_code) however i have no idea what are the pros and cons of that.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on January 04, 2019, 05:02:37 pm
DF isn't a DLL though, although maybe the same thing applies. In any case, what matters for the matter at hand is that we know the DF executable isn't always loaded at the same place in memory, because we have to account for that to adjust everything in symbols.xml when DFHack starts. getRebaseDelta should help; if not, let me know.
Title: Re: DFHack 0.44.12-r1
Post by: Roses on January 10, 2019, 05:09:16 pm
I probably would've stuck with roses stuff if I'd been able to get the JSON saving to reliably save with the game. I couldn't figure out a way to tell if quicksaving/autosaving was going on. The problem was more that every single table check was a persist-table check, IIRC.

So, circling back to this, I recently tried moving some of the persist-table stuff I use to use the JSON save/load stuff. It seemed to go fine and was able to bypass the slowdown with persist-table checks and the overhead associated with the persistent tables itself, so I was thinking to moving almost entirely to the JSON stuff, but you mentioned it had trouble, so I wanted to ask about any troubles associated with it before I spent any more time working on it.
Title: Re: DFHack 0.44.12-r2
Post by: Putnam on January 11, 2019, 01:34:08 am
Straight up couldn't find a way to get it to save only when the game saves.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on January 11, 2019, 12:43:24 pm
Straight up couldn't find a way to get it to save only when the game saves.

Yeah, I just reread your first post, don't know why I didn't really understand what you were talking about the first time I read it. I saw it and I thought, isn't that what the ON_UNLOAD (or whatever it's called) event is for, but I forgot about autosaves and quicksaves. Hmmm, well I'm going to have to look into it a bit, because even if I don't use the JSON stuff I would still like to load the persistent data tables into global tables on start and unload them on save/exit and that will have the same problem. I'll let you know if I can find anything, but if you weren't able to I'm not super thrilled about my chances.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on January 11, 2019, 01:45:17 pm
Does saving .dat files into data/save/current not work? That's what https://github.com/DFHack/dfhack/pull/1402/files does, at least.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on January 11, 2019, 02:32:10 pm
I can save and load the files into/from data/save/current on world unload/load just fine. But autosaves and quicksaves are giving me trouble, although it looks like that link you gave does save on each save (no matter how the save is initiated). Now how to translate that into something available to lua
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on January 11, 2019, 03:29:09 pm
I was on mobile earlier, so that probably wasn't clear enough. I'm saying you can save what you want into data/save/current/foo.dat when the data changes, not when DF saves. When DF saves (regardless of the type of save), those files will be copied into the region folder. The only save detection in that PR is to allow plugins to do anything special needed when the game is saved. Granted, if you're writing stuff to disk frequently, that will be bad for performance, and plugins in that PR could potentially only write to disk in plugin_save, but you almost certainly don't need to write very often in most cases.
Title: Re: DFHack 0.44.12-r2
Post by: bloop_bleep on January 11, 2019, 06:52:44 pm
I found I had to load from the main world folder (not /data/save/current) even though I could save to either.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on January 11, 2019, 07:56:16 pm
I found I had to load from the main world folder (not /data/save/current) even though I could save to either.
Oh, sorry, I thought that part was obvious. The current folder gets cleared after saving, after its contents are copied into the region folder. Writing directly to the region folder will lead to incorrect behavior if DF quits without saving.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on January 11, 2019, 08:02:18 pm
I think I can make that work. Periodically saving to the current folder should be fine. I might have to modify the quick save script to trigger a write though to make sure the save and the files dont get out of sync if a crash happens between the two.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on January 11, 2019, 08:31:38 pm
If a crash happens "between the two" what? If a crash happens while saving, it should only affect files in the current folder - that's how DF is designed, to cut down on corruption. A crash when moving files into the region folder is exceptionally unlikely.
Title: Re: DFHack 0.44.12-r2
Post by: Bumber on January 11, 2019, 08:46:44 pm
I think the issue would be if the game saves with a stale version of foo.dat in current.
Title: Re: DFHack 0.44.12-r2
Post by: Tat45 on January 11, 2019, 09:59:29 pm
I'm getting a CTD under a very specific scenario: I'm trying to set up a zone ('i') submenu as a rectangular area with the mouse enabled. If I select the second corner in an unmined area and then hit "Enter" to place the zone, Dwarf Fortress immediately crashes with no discernibly related log output that I can see.
Title: Re: DFHack 0.44.12-r2
Post by: Quietust on January 12, 2019, 11:08:52 am
I found I had to load from the main world folder (not /data/save/current) even though I could save to either.
That should actually be the other way around - when reading, you should try data/save/current first and then fall back to data/save/regionX, but when writing, you should always go to data/save/current.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on January 12, 2019, 03:35:58 pm
If a crash happens "between the two" what? If a crash happens while saving, it should only affect files in the current folder - that's how DF is designed, to cut down on corruption. A crash when moving files into the region folder is exceptionally unlikely.

I think the issue would be if the game saves with a stale version of foo.dat in current.

Yes, sorry. I meant if the game saves and moves an out of date dat file then updates the dat file in the data/save/current directory but crashes before that can get moved to the data/save/regionX folder. For normal saves this isn't an issue since there is the ON_WORLD_UNLOAD thing, and for autosaves it shouldn't be an issue since they happen at specific times and I can always make sure to get the updated dat file in the /current directory in the correct order. But quicksaves aren't predictable. Luckily it is easy enough to hook into the quicksave script and just make sure that the dat file is updated in the correct order.
Title: Re: DFHack 0.44.12-r2
Post by: Romi on January 18, 2019, 07:05:33 pm
Is it possible to use DFHack to remove engravings?

I just noticed that all my main areas were engraved by low quality engravers, because I forgot to tick off stone detailing from the "peasant" squad that helped smoothed up the place. This a 5 year Fortress that I have meticulously micromanaged, and this really soured my playthrough.
Title: Re: DFHack 0.44.12-r2
Post by: Bumber on January 18, 2019, 09:13:17 pm
Is it possible to use DFHack to remove engravings?

I just noticed that all my main areas were engraved by low quality engravers, because I forgot to tick off stone detailing from the "peasant" squad that helped smoothed up the place. This a 5 year Fortress that I have meticulously micromanaged, and this really soured my playthrough.
You could use gui/liquids to spawn magma on them, then remove it a tick later. Not sure that works for walls, however.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on January 19, 2019, 03:35:26 am
@Romi: Note that you can achieve it without DFHack by manually designating each sub standard tile for smoothing again (which of course is a pain, but if you're hard into perfect, that's the way to do it). It would presumably be possible to write a script that designated all non masterworks engravings for smoothing, although I don't know the details. In both cases the dorfs would actually do the work themselves, so it wouldn't be "cheating".
Title: Re: DFHack 0.44.12-r2
Post by: Romi on January 19, 2019, 05:34:13 am
@Romi: Note that you can achieve it without DFHack by manually designating each sub standard tile for smoothing again (which of course is a pain, but if you're hard into perfect, that's the way to do it). It would presumably be possible to write a script that designated all non masterworks engravings for smoothing, although I don't know the details. In both cases the dorfs would actually do the work themselves, so it wouldn't be "cheating".

I didn't know that, I much prefer this safe and sound method, Thanks!  There is no need for the script i'll just redo everything.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on January 19, 2019, 11:51:38 am
Yes, sorry. I meant if the game saves and moves an out of date dat file then updates the dat file in the data/save/current directory but crashes before that can get moved to the data/save/regionX folder.
If the game crashes, the updated .dat file shouldn't get copied to the regionX folder. That's how the current persistent API works as well.

Quote
For normal saves this isn't an issue since there is the ON_WORLD_UNLOAD thing, and for autosaves it shouldn't be an issue since they happen at specific times and I can always make sure to get the updated dat file in the /current directory in the correct order. But quicksaves aren't predictable. Luckily it is easy enough to hook into the quicksave script and just make sure that the dat file is updated in the correct order.
Keep in mind that the quicksave script doesn't run on "normal" autosaves so you won't be able to detect those. edit: I guess you can use the fact that autosave times are fixed, yeah.

Again, I'm saying you should write to data/save/current/foo.dat whenever something changes, and you will be fine. You don't need to worry about detecting save events at all. Granted, if you need to write to disk a lot (as in multiple times a second), it would be better to detect saves, and writing only periodically could risk saving slightly stale data. As part of BenLubar's persistent JSON PR, I'll try to make sure scripts have a way to access the save events as well as plugins. But for non-intensive use, you don't have to detect save events.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on January 19, 2019, 03:23:43 pm
Yes, sorry. I meant if the game saves and moves an out of date dat file then updates the dat file in the data/save/current directory but crashes before that can get moved to the data/save/regionX folder.
If the game crashes, the updated .dat file shouldn't get copied to the regionX folder. That's how the current persistent API works as well.

Quote
For normal saves this isn't an issue since there is the ON_WORLD_UNLOAD thing, and for autosaves it shouldn't be an issue since they happen at specific times and I can always make sure to get the updated dat file in the /current directory in the correct order. But quicksaves aren't predictable. Luckily it is easy enough to hook into the quicksave script and just make sure that the dat file is updated in the correct order.
Keep in mind that the quicksave script doesn't run on "normal" autosaves so you won't be able to detect those. edit: I guess you can use the fact that autosave times are fixed, yeah.

Again, I'm saying you should write to data/save/current/foo.dat whenever something changes, and you will be fine. You don't need to worry about detecting save events at all. Granted, if you need to write to disk a lot (as in multiple times a second), it would be better to detect saves, and writing only periodically could risk saving slightly stale data. As part of BenLubar's persistent JSON PR, I'll try to make sure scripts have a way to access the save events as well as plugins. But for non-intensive use, you don't have to detect save events.

For testing I am just going to have it write out to data/save/current once a week (in game time), the problem with writing it every time something changes is that it could theoretically be changing a lot given that it tracks a large amount of information. If I find that in actuality it doesn't change that often I will move to just writing it out whenever it changes.

Questions about SC_WORLD/MAP_LOADED/UNLOADED
1. For loading, does it matter if I use world or map? There will just be a single file for an entire region and it's just being read into a global table for access by other scripts.
2. For unloading, what is the order of operations? If I save to current as part of an unload state change, will the file be moved correctly?
Title: Re: DFHack 0.44.12-r2
Post by: bloop_bleep on January 20, 2019, 02:19:49 pm
I have a bug report/fix.

kittens.cpp fails to compile on Windows with the Visual Studio C++ compiler because of the missing <array> include. I guess on the author's platform, one of the other standard library includes includes <array> itself, but that isn't true on Visual Studio.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on January 21, 2019, 11:34:06 pm
(http://www.truimagz.com/host/rumrusher/folder7/well-now-I-can-build-an-island-of-stolen-landmasses.gif)
well finish working on a refined script that teleports multiple campsites that are named BOAT.

pretty much spending my time in advmode with this script walking up to ambush points and plopping down a camp so that the ambush ends up being attacked by personal body guards... or undead camel, then realizing I'm also taking the ambush party with me when I leave.
combination of this saving everyone at the camp with zones and telling companions to leave one could build a small community anywhere.
Title: Re: DFHack 0.44.12-r2
Post by: feelotraveller on January 28, 2019, 06:32:40 pm
Um, apologies in advance if I'm just too simple but...

At https://github.com/DFHack/dfhack (https://github.com/DFHack/dfhack) the 'scripts' folder seems broken.

Edit: it's okay, I've found them.  Just confused by the (non)linking.  Yep, too simple.  ;)
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on January 28, 2019, 09:04:32 pm
We actually submitted a bug report to GitHub about that (it's because the scripts submodule uses a relative URL now, ../../DFHack/scripts). They know it's broken but it's presumably not a high-priority issue.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on January 31, 2019, 08:29:18 pm
We actually submitted a bug report to GitHub about that (it's because the scripts submodule uses a relative URL now, ../../DFHack/scripts). They know it's broken but it's presumably not a high-priority issue.

That's been an issue for years on github. I spent a good month refactoring a large code base for use on github with submodules when they figured out that relative paths were causing issues.

A couple questions;

1. If I tie a save file function into the onUnload event should I save to current or the region save file?
2. For the GUI stuff is there a way to distinguish between the arrow keys, numpad keys, and numbers for the keys or are they all treated the same?
3. Are unit or item ids every reused while playing? I'm guessing historical unit ids are unique, but several of my scripts assume unit ids are also unique.
4. There are a lot of great functions available in dfhack.units and the other dfhack.BLANK stuff. If I was interested in porting some of my functions that I currently use that I think other people might find useful from my lua functions to built in functions how should I go about that? (I am familiar with writing C code so that isn't an issue)

EDIT: Another question I forgot, is there an easy way to detect when custom view screens "turn on and off". My detailed unit viewer currently let's you access the gui/gm-editor for the unit directly for it, but if you change anything in the editor you have to exit out of the viewer and start it again. I was hoping to be able to automatically reload my viewer when exiting the editor but my tests with screen:onShow haven't been successful

EDIT2: Do we know the speed change calculations for calculating gait speed based on strength/agility? I wrote a small script to calculate the kph value of a unit based on the gaits file in the raws but it doesn't takes into account and modifiers (the current dhack.units.computeMovementSpeed always returns 0)
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on February 01, 2019, 06:29:15 pm
1. If I tie a save file function into the onUnload event should I save to current or the region save file?
That is probably too late to access any world data. It might fire after DF copies the current folder to the region folder too. If you can't do it any earlier, you might have to save to the region folder, but even that name might not be accessible any more. I would experiment with saving something to current and see where that ends up.
Quote
2. For the GUI stuff is there a way to distinguish between the arrow keys, numpad keys, and numbers for the keys or are they all treated the same?
You should be using DF's key IDs, which depend on the keybindings that are set. Use STANDARDSCROLL_UP/DOWN. when you're scrolling through a list and CURSOR_UP/etc. when you're moving a cursor (like the X on the map) around the screen. DF and DFHack don't have a way to distinguish between arrow keys and number keys once they've been translated to IDs.
Quote
3. Are unit or item ids every reused while playing? I'm guessing historical unit ids are unique, but several of my scripts assume unit ids are also unique.
Don't know about this. They might potentially be reused in different forts in the same world, but I doubt it. Histfig IDs are unique (I'm pretty sure those are the IDs used in the unit-X.dat files in the save folders). If you're concerned, you could tack on the fort/site ID as well for whatever you're doing.
Quote
4. There are a lot of great functions available in dfhack.units and the other dfhack.BLANK stuff. If I was interested in porting some of my functions that I currently use that I think other people might find useful from my lua functions to built in functions how should I go about that? (I am familiar with writing C code so that isn't an issue)
Files that need to be changed:
https://github.com/DFHack/dfhack/blob/master/library/modules/Units.cpp (for dfhack.units; other files for other modules, of course)
https://github.com/DFHack/dfhack/blob/master/library/include/modules/Units.h (again, depends on the module)
https://github.com/DFHack/dfhack/blob/master/library/LuaApi.cpp (usually just a WRAP macro works)
https://github.com/DFHack/dfhack/blob/master/docs/Lua%20API.rst
Ideally the changelog too, but that's not as important.

Quote
EDIT: Another question I forgot, is there an easy way to detect when custom view screens "turn on and off". My detailed unit viewer currently let's you access the gui/gm-editor for the unit directly for it, but if you change anything in the editor you have to exit out of the viewer and start it again. I was hoping to be able to automatically reload my viewer when exiting the editor but my tests with screen:onShow haven't been successful
Looking at https://github.com/DFHack/dfhack/blob/master/plugins/manipulator.cpp, I think the logic() vmethod gets called periodically when the screen is active (render() should too - logic() might be onIdle() in higher Lua APIs, but render() or onRender() or whatever you're using should work for your purpose). Your screen could set a flag when it opens the screen, and the next time logic() or render() are called, it could refresh itself and reset the flag. "do_refresh_names" is the flag manipulator uses. Does that help?
Quote
EDIT2: Do we know the speed change calculations for calculating gait speed based on strength/agility? I wrote a small script to calculate the kph value of a unit based on the gaits file in the raws but it doesn't takes into account and modifiers (the current dhack.units.computeMovementSpeed always returns 0)
Not seeing anything in the XML files about it, sorry. Someone else might know.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on February 02, 2019, 05:06:54 pm
--snip--

Thanks, I played around with saving through the unUnload function and it is indeed after DF copies the current folder to the region folder. In fact if you use the getSavePath() function you will get nil back. It's not a big deal though since I am saving into the current folder regularly, so everything is already getting correctly copied over to the region folder.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on February 09, 2019, 05:19:26 pm
Is there a way to access the plant raw strings like we can access the creature raw strings? I figure the plant_raw.anon_1 is the list of strings similar to creature_raw.raws, but it's all userdata entries.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on February 09, 2019, 07:37:27 pm
Is there a way to access the plant raw strings like we can access the creature raw strings? I figure the plant_raw.anon_1 is the list of strings similar to creature_raw.raws, but it's all userdata entries.
Yup:
Code: [Select]
[lua]# ~df.reinterpret_cast('string',df.plant_raw.find(0).anon_1[0])
<string: 0x112e5b010>
value                  = [NAME:single-grain wheat]
Obviously don't use this in a script, but I'll add a name to the xml files.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on February 10, 2019, 01:30:51 pm
Is there a way to access the plant raw strings like we can access the creature raw strings? I figure the plant_raw.anon_1 is the list of strings similar to creature_raw.raws, but it's all userdata entries.
Yup:
Code: [Select]
[lua]# ~df.reinterpret_cast('string',df.plant_raw.find(0).anon_1[0])
<string: 0x112e5b010>
value                  = [NAME:single-grain wheat]
Obviously don't use this in a script, but I'll add a name to the xml files.

Great, perfect!
Title: Re: DFHack 0.44.12-r2
Post by: Roses on February 13, 2019, 12:19:29 pm
Is there a way to access a non-existent item in a DF struct without it crashing? I seem to recall doing something once with a pcall, but I don't quite remember the right syntax. For instance, with a normal table I can do
Code: [Select]
a = Table.FOO or BARand if the table Table doesn't have the FOO entry I will get BAR. But I can't do
Code: [Select]
a = itemRaw.adjective or ""because some item raws don't have the adjective entry, so it will give me an error instead of just a blank string.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on February 13, 2019, 01:08:35 pm
To be clear, you don't mean actually crashing, right? Crashes aren't possible to prevent after the fact.

pcall takes a function to call (optionally with arguments) and returns a boolean representing whether an error occurred, followed by the function's return values or the error. So something like this should work:
Code: [Select]
field_exists = pcall(function() return object.some_field end)
Something like this ought to be in utils.lua or exposed through the C++/Lua bridge...
Title: Re: DFHack 0.44.12-r2
Post by: Roses on February 13, 2019, 02:56:18 pm
To be clear, you don't mean actually crashing, right? Crashes aren't possible to prevent after the fact.

pcall takes a function to call (optionally with arguments) and returns a boolean representing whether an error occurred, followed by the function's return values or the error. So something like this should work:
Code: [Select]
field_exists = pcall(function() return object.some_field end)
Something like this ought to be in utils.lua or exposed through the C++/Lua bridge...

Yes, sorry, crashing is definitely not what it is doing. It is just printing an error "Cannot read field itemdef_foodst.adjective: not found". And it's only printing the error because I am looping through all the item raws and didn't really want to take the time to handle each itemdef separately. The pcall trick is exactly what I need, granted it would be awesome if trying to access itemdef_foodst.adjective just returned nil instead of an error, but this works just as well
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on February 13, 2019, 03:31:07 pm
Worth noting that pcall will be significantly slower than handling individual types, if that's something you can do, so don't use the pcall approach in anything performance-intensive. I assume there are good reasons for not returning nil for nonexistent fields, although I wasn't around when that decision was made - it's probably better for those accesses to fail early instead of silently succeeding for typos and such.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on February 13, 2019, 04:36:40 pm
Worth noting that pcall will be significantly slower than handling individual types, if that's something you can do, so don't use the pcall approach in anything performance-intensive. I assume there are good reasons for not returning nil for nonexistent fields, although I wasn't around when that decision was made - it's probably better for those accesses to fail early instead of silently succeeding for typos and such.

I suppose I could just do a
Code: [Select]
b={}
for k,v in pairs(itemdef_XXX) do
    b[k]=v
end
adjective = b.adjective or ""

Would that be faster than pcall? I know a list of if statements would probably be faster, but could also get very long
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on February 13, 2019, 06:37:00 pm
Almost certainly slower if you're running the loop more than once. Maybe a table of types you know have the field you want, indexed by the type so you don't have to do a linear scan, would work and be cleaner than an if statement chain.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on February 14, 2019, 12:08:22 pm
Almost certainly slower if you're running the loop more than once. Maybe a table of types you know have the field you want, indexed by the type so you don't have to do a linear scan, would work and be cleaner than an if statement chain.

That's a good idea actually, then I can have a table that I can use across multiple scripts, it only needs to be generated at startup and I can add/remove things from it easily as things change. No idea why I didn't think of that, it's a much more elegant solution than a list of if statements and avoids constant loops and pcalls. Thanks!
Title: Re: DFHack 0.44.12-r2
Post by: Roses on February 15, 2019, 11:55:06 pm
Trying to use the onBuildingCreatedDestroyed eventful trigger, it worked in the past when I tested it, but now, instead of returning the buliding_id it seems to just be returning a random number, a different number in each world I've generated, but the same number every time. I've reloaded the eventful plugin several times and even tried completely closing DF and reopening and starting a new world, but nothing seems to help.

This is the eventful code, fairly simple but not working.
Code: [Select]
eventful.enableEvent(eventful.eventType.BUILDING, 10)
eventful.onBuildingCreatedDestroyed.buildingTrigger = function(buildingID)
 print(buildingID)
 building = df.building.find(buildingID)
 if building then
  checkBuildingCreated(buildingID)
 else
  checkBuildingDestroyed(buildingID)
 end
end
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on February 16, 2019, 02:31:21 pm
Not seeing an obvious reason, but I'm not familiar with eventful. What does the 10 argument mean?
Title: Re: DFHack 0.44.12-r2
Post by: Roses on February 16, 2019, 02:47:42 pm
The 10 is how often it runs the check. The odd thing is that it is correctly triggering on each building created/destroyed, but it isn't giving the right buildingID, which means I must have royally screwed something up. I just can't figure out what
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on February 16, 2019, 02:53:59 pm
If print(buildingID) is printing garbage, that's not your fault. (Can you give an example?) Also, is eventful.eventType.BUILDING equal to 5?
Title: Re: DFHack 0.44.12-r2
Post by: Roses on February 16, 2019, 03:30:21 pm
Yeah, the eventType is 5, I've stripped everything else out of the script and just run
Quote
eventful.onBuildingCreatedDestroyed.test = function(a) print('test',a) end
on the command line. Then tried built and destroyed a couple of the default workshops (Leatherworker's and Kitchen) and the Soap Maker's custom workshop, each time it printed 1840249752 when I both created and destroyed the buildings (although in another world I tried this in it was printing a large negative number, so that isn't always the same).
Title: Re: DFHack 0.44.12-r2
Post by: Warmist on February 18, 2019, 01:25:08 am
Yeah, the eventType is 5, I've stripped everything else out of the script and just run
Quote
eventful.onBuildingCreatedDestroyed.test = function(a) print('test',a) end
on the command line. Then tried built and destroyed a couple of the default workshops (Leatherworker's and Kitchen) and the Soap Maker's custom workshop, each time it printed 1840249752 when I both created and destroyed the buildings (although in another world I tried this in it was printing a large negative number, so that isn't always the same).

I have no idea how it worked before:  this is pointer  (https://github.com/DFHack/dfhack/blob/master/library/modules/EventManager.cpp#L612)
And it's used:  not a pointer  (https://github.com/DFHack/dfhack/blob/master/plugins/eventful.cpp#L175). So you are getting an address of your id.

Also:  this is related  (https://github.com/DFHack/dfhack/commit/19695b4ee7e8b370c8ce53aa2dcd399e1e9ca94d) and this broke it (https://github.com/DFHack/dfhack/commit/a7dfacd1c57490d08fc92a43eea963cff47c05eb)
Title: Re: DFHack 0.44.12-r2
Post by: Roses on February 18, 2019, 12:36:55 pm
Interesting. So it did used to work, at least sometimes. So I'm not crazy. Is there a way to get the id from the pointer? I suppose I can also just loop over all buildings and see what's new when a building gets created. Or I could link it to the on job completed eventful
Title: Re: DFHack 0.44.12-r2
Post by: Warmist on February 19, 2019, 02:33:57 am
Interesting. So it did used to work, at least sometimes. So I'm not crazy. Is there a way to get the id from the pointer? I suppose I can also just loop over all buildings and see what's new when a building gets created. Or I could link it to the on job completed eventful
I suggest using job complete. Or waiting for release with a fix. Also there is a way to get id from the pointer, but i suggest not to think about that because it's very close to summoning chtulian monstrosities from the computational multiverse. (also it would be broken after fix).

Lastly - yes you could just do the same thing plugin does - personally i find all that "iterate over everything every N frames" very ugly and suggest leaving it in one place (i.e. the plugin). It's also a bit finicky to get right, however you probably have very similar systems in place.
Title: Re: DFHack 0.44.12-r2
Post by: Golbolco on February 19, 2019, 04:02:52 pm
Is it possible to spawn in a wagon using DFhack?
Title: Re: DFHack 0.44.12-r2
Post by: thefriendlyhacker on February 19, 2019, 04:09:05 pm
Is it possible to spawn in a wagon using DFhack?
For a lark, I tried spawning one in arena with modtools/create-item. It spawned, but was scuttled a tick later. I doubt fort/adv mode behavior will be any different.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on February 20, 2019, 09:13:24 am
well wagons do seem to work fine in adv mode, but they totally scuttle in Fort mode or fort mode like modes.
that's mostly the Creature wagon though.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on February 20, 2019, 10:06:17 am
Interesting. So it did used to work, at least sometimes. So I'm not crazy. Is there a way to get the id from the pointer? I suppose I can also just loop over all buildings and see what's new when a building gets created. Or I could link it to the on job completed eventful
I suggest using job complete. Or waiting for release with a fix. Also there is a way to get id from the pointer, but i suggest not to think about that because it's very close to summoning chtulian monstrosities from the computational multiverse. (also it would be broken after fix).

Lastly - yes you could just do the same thing plugin does - personally i find all that "iterate over everything every N frames" very ugly and suggest leaving it in one place (i.e. the plugin). It's also a bit finicky to get right, however you probably have very similar systems in place.

Combining onJobInitiated (for checking if the building is eligible to be built, like the outside-only script) and onJobCompleted (for checking that the building actually was constructed) works perfectly. Gives me all the information needed and even gives me extra stuff which allows me to speed up/slow down the construction of buildings among other things.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on February 20, 2019, 05:45:51 pm
Is there a way to properly destroy a building? I know there is dfhack.buildings.deconstruct(), but all that does for an already constructed building is add a job for removal, and I want to actually remove the building from existence. I can probably kludge something together, but was wondering if there was already something out there.

EDIT: Nevermind, figured it out. If you set the construction stage to 0 then use dfhack.buildings.deconstruct() it will correctly deconstruct the building.
Title: Re: DFHack 0.44.12-r2
Post by: neutrino431 on February 22, 2019, 06:56:17 pm
How do you spawn a quire with createitem?
Title: Re: DFHack 0.44.12-r2
Post by: thefriendlyhacker on February 22, 2019, 09:13:04 pm
Try this:
Code: [Select]
modtools/create-item -creator *id* -material PLANT:GRASS_TAIL_PIG:THREAD -item TOOL:ITEM_TOOL_QUIRE
Use teleport -showunitid to get the ID of one of your units

There is also gui/create-item, which brings up a screen for you to pick your item/material from.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on February 24, 2019, 08:32:02 pm
That translates pretty directly to createitem, by the way (I'm copying the materials you gave, so hopefully they're correct):
Code: [Select]
createitem TOOL:ITEM_TOOL_QUIRE PLANT:GRASS_TAIL_PIG:THREAD
This will select a valid unit ID automatically if one isn't selected.
Title: Re: DFHack 0.44.12-r2
Post by: blackreaper666 on March 02, 2019, 02:47:10 pm
Just a little question about the lua api. Is there a straightforward way to get the character, foreground and background color of a tile that is on the screen?

EDIT: Found the screen.readTile function. Unfortunately a lot of tiles return 0 as char code and color. Menus and Borders work but not the "game-view" where my little dwarfs run around. Is there something I'm missing?

EDIT2: So this was the result of using TWBT. So I solved all my problems :)
Title: Re: DFHack 0.44.12-r2
Post by: Roses on March 03, 2019, 11:30:20 am
What's the best way to use a global global table (one that is accessed by many different scripts fairly regularly for both reading and modifying)? Right now I'm just using the dfhack.script-environment to get the table, but I wasn't sure if that was the best way
Title: Re: DFHack 0.44.12-r2
Post by: thefriendlyhacker on March 04, 2019, 07:04:38 am
What's the best way to use a global global table (one that is accessed by many different scripts fairly regularly for both reading and modifying)? Right now I'm just using the dfhack.script-environment to get the table, but I wasn't sure if that was the best way
The "best practice" way to do it would probably be to refactor all your shared functionality into one or more lua files in dfhack's lua folder, and then require them in like you would with utils, plugins.eventful or syndrome-util.
Title: Re: DFHack 0.44.12-r2
Post by: Putnam on March 04, 2019, 07:32:10 pm
I use script-environment nigh exclusively for that, occasionally persistent storage.
Title: Re: DFHack 0.44.12-r2
Post by: blackreaper666 on March 05, 2019, 06:41:41 am
Could it be that
Code: [Select]
dfhack.screen.getWindowSize() is broken in the lua api?

As per Screen.cpp Screen::getWindowSize() returns a coord2d, so it has a x and a y field. Reference:
Code: [Select]
df::coord2d Screen::getWindowSize()
{
    if (!gps) return df::coord2d(80, 25);

    return df::coord2d(gps->dimx, gps->dimy);
}

but lua treats it as a single number.
Code: [Select]
dfhack.screen.getWindowSize() will just return the x value (width), but if you print it it will show x and y in the console but there is no way to select either x or y.

Code: [Select]
dfhack.screen.getWindowSize().x
dfhack.screen.getWindowSize().y
dfhack.screen.getWindowSize().X
dfhack.screen.getWindowSize().Y
dfhack.screen.getWindowSize()[0]
dfhack.screen.getWindowSize()[1]
...

all fail because of "attempt to index a number value" which makes sense because lua thinks getWindowSize returns a single number.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on March 05, 2019, 09:10:23 am
Could it be that
Code: [Select]
dfhack.screen.getWindowSize() is broken in the lua api?

As per Screen.cpp Screen::getWindowSize() returns a coord2d, so it has a x and a y field. Reference:
Code: [Select]
df::coord2d Screen::getWindowSize()
{
    if (!gps) return df::coord2d(80, 25);

    return df::coord2d(gps->dimx, gps->dimy);
}

but lua treats it as a single number.
Code: [Select]
dfhack.screen.getWindowSize() will just return the x value (width), but if you print it it will show x and y in the console but there is no way to select either x or y.

Code: [Select]
dfhack.screen.getWindowSize().x
dfhack.screen.getWindowSize().y
dfhack.screen.getWindowSize().X
dfhack.screen.getWindowSize().Y
dfhack.screen.getWindowSize()[0]
dfhack.screen.getWindowSize()[1]
...

all fail because of "attempt to index a number value" which makes sense because lua thinks getWindowSize returns a single number.

You sure it isn't just returning two values? x, y = dfhack.screen.getWindowSize()
Title: Re: DFHack 0.44.12-r2
Post by: blackreaper666 on March 05, 2019, 10:33:23 am
You sure it isn't just returning two values? x, y = dfhack.screen.getWindowSize()

 :o You are right! Thanks. Now I feel dumb... I didn't knew multiple returns where possible in lua and the error didn't really help. I would have expected a different kind of error that somehow indicates that there are multiple values returned and not just taking the first one and working with that. That's what I'm used to from other languages. Thanks again for your help!
Title: Re: DFHack 0.44.12-r2
Post by: Roses on March 05, 2019, 03:20:54 pm
:o You are right! Thanks. Now I feel dumb... I didn't knew multiple returns where possible in lua and the error didn't really help. I would have expected a different kind of error that somehow indicates that there are multiple values returned and not just taking the first one and working with that. That's what I'm used to from other languages. Thanks again for your help!

Yeah, it took me awhile to work out multiple return values versus returns of tables with multiple values and making sure that I was getting the right stuff from the dfhack functions
Title: Re: DFHack 0.44.12-r2
Post by: Clément on March 18, 2019, 09:58:46 am
I've been experimenting with using Qt in DFHack plugins and it's mostly working (much better that I thought it would at first).

There is no issue that I could see on Windows. On Linux, it crashes on exit when SDL tries to clean up some X11 related resources. I understand it is an issue from Xlib no supporting concurrency. It can be fixed by using Wayland backend for the Qt part, or by replacing SDL 1.2 with SDL2 thanks to sdlcl (https://github.com/MrAlert/sdlcl) (I guess the newer sdl12-compat (https://www.patreon.com/posts/project-sdl12-25321792) would work too). I did not test with macOS.

I pushed the code on this github (https://github.com/cvuchener/dfhack-qt). The qapplication plugin manages the main Qt thread and provides a few basic commands for configuration or diagnostics. Other plugins can call addTopLevelWidget from include/TopLevelWidget.h to create widgets. qapplication needs to be enabled before Qt widgets can be created.

The labors (https://github.com/cvuchener/dfhack-qt/tree/labors) branch contains a very basic DT-like plugin that can serve as a demo. If you want to try it you will need to have the default_gridviews.dtg (https://raw.githubusercontent.com/Dwarf-Therapist/Dwarf-Therapist/master/resources/default_gridviews.dtg) file from DT copied in DF root directory. Data is only accessed when the game is suspended (use the "suspend" and "resume" buttons in the tool bar).

Multi-threading make such plugins a little difficult to write since you need to either suspend the game or copy all the data you need. But I think it is still easier than external applications since you can take advantage of all DFHack helper functions and you would need to copy the data anyway in an external application.

I currently only access/modify DF data when a CoreSuspender is locked, but I wonder if this could be relaxed. Can any assumption be made on some pointers validity with regards to state change events (SC_WORLD_LOADED, SC_WORLD_UNLOADED, SC_MAP_LOADED, SC_MAP_UNLOADED, SC_PAUSED, SC_UNPAUSED, ...) for read-only access?
Title: Re: DFHack 0.44.12-r2
Post by: ragundo on March 18, 2019, 03:49:43 pm
I've been experimenting with using Qt in DFHack plugins and it's mostly working (much better that I thought it would at first).


I pushed the code on this github (https://github.com/cvuchener/dfhack-qt). The qapplication plugin manages the main Qt thread and provides a few basic commands for configuration or diagnostics. Other plugins can call addTopLevelWidget from include/TopLevelWidget.h to create widgets. qapplication needs to be enabled before Qt widgets can be created.

The labors (https://github.com/cvuchener/dfhack-qt/tree/labors) branch contains a very basic DT-like plugin that can serve as a demo. If you want to try it you will need to have the default_gridviews.dtg (https://raw.githubusercontent.com/Dwarf-Therapist/Dwarf-Therapist/master/resources/default_gridviews.dtg) file from DT copied in DF root directory. Data is only accessed when the game is suspended (use the "suspend" and "resume" buttons in the tool bar).



So with this I could create a Qt application directly linked with DFhack and access all the data?.
This is great.
I tried to do something similar using protocol buffers, but perfomance suffers.
I can generate Qt models for every df structure in DFhack and visualize them. I'll play with your repository for sure!!
Would it work also with QML?
Title: Re: DFHack 0.44.12-r2
Post by: Clément on March 18, 2019, 04:48:02 pm
I don't know QML very well, so I am not sure. But in the worst case you should be able to embed it in a QWidget (https://doc.qt.io/qt-5/qwidget.html#createWindowContainer). The limitation is that there can be only one application object, it is of type QApplication and managed by the qapplication plugin. All other plugins can do is only creating more windows (top-level widgets) for this common application. QApplication inherits QGuiApplication which used in QML apps, so maybe it's okay and it just need the API to create windows from QML.

For protobuf you need to aggregate the messages as much as you can. Performance can become acceptable if you send few messages with a lot of data. I tried to quickly hack dfhack protobuf protocol into Dwarf Therapist once: first try was really slow (10 minutes or something to load DT), but with a simple optimization I managed to get it nearly as fast as the current DT (although the current backend could also benefit from such optimization and be even faster).
Title: Re: DFHack 0.44.12-r2
Post by: ragundo on March 18, 2019, 05:19:18 pm
Not working for me in ubuntu.
I opened a issue in github.

What a coincidence that I got working my plugin that sends everything via protocol buffers to a remote Qt application just when you published your work :)
Title: Re: DFHack 0.44.12-r2
Post by: Clément on March 18, 2019, 07:15:11 pm
I have a Qt-based library for dfhack clients I could publish too if you are interested.
Title: Re: DFHack 0.44.12-r2
Post by: ragundo on March 19, 2019, 01:37:27 pm
I have a Qt-based library for dfhack clients I could publish too if you are interested.

Yes please!
By the way, with this Qt application you could recreate Dwarf Therapist entirely in DFHack, isn't?.
No need for .ini files, etc.
Just curious why you still keep using the original way
Title: Re: DFHack 0.44.12-r2
Post by: Clément on March 19, 2019, 02:04:26 pm
Yes, I'm am experimenting with other ways to make Dwarf Therapist. But re-creating it is a lot of work, don't expect it any time soon. I am not even sure I'll do it. And the debugging API currently used in DT is not that bad, except on macOS where it seems to require root permissions whatever you try.
Title: Re: DFHack 0.44.12-r2
Post by: ViolinAnon on March 19, 2019, 06:46:39 pm
I was using the 'liquids' plugin to create a large tower of obsidian for a special project.
However, when mined out by dwarves, the floors/ramps left behind are made of other material, such as fire clay or random stone.

I was wondering if I was perhaps doing something wrong, or if it's to be expected from creating obsidian that way?
Title: Re: DFHack 0.44.12-r2
Post by: bloop_bleep on March 19, 2019, 07:32:04 pm
I think it’s to be expected. There’s no layer material defined in air zones, so the game chooses one at random when the tile is mined.
Title: Re: DFHack 0.44.12-r2
Post by: ViolinAnon on March 19, 2019, 07:37:19 pm
Ah, damn.
I guess I can try an alternative method, by creating magma then water to cast obsidian. It'll be very time consuming.

Thanks for the confirmation, though!
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on March 20, 2019, 03:18:56 am
I fail to see how obsidianizing using magma+water would give a different result from spawning obsidian directly. The problem comes from mining out of a huge block, so spawn only walls (and build floors out of obsidian [blocks]). It's still more work to spawn parts rather than a block that's mined out, of course.

Also note that the biome in the air may differ from the one at ground level, so any farming may support crops different from the ones expected (the air biome is the one of the world tile to the NW of the embark tile [and there's a "shear" bug that causes random 16*16 areas in the air to take on any of the up to 9 biomes of the embark world tile and the 8 surrounding ones]).
Title: Re: DFHack 0.44.12-r2
Post by: Roses on March 20, 2019, 08:00:02 am
Also note that the biome in the air may differ from the one at ground level, so any farming may support crops different from the ones expected (the air biome is the one of the world tile to the NW of the embark tile [and there's a "shear" bug that causes random 16*16 areas in the air to take on any of the up to 9 biomes of the embark world tile and the 8 surrounding ones]).

That's interesting, I didn't know that about air biomes. Now I kind of want to make a "hanging garden".

Ah, damn.
I guess I can try an alternative method, by creating magma then water to cast obsidian. It'll be very time consuming.

Thanks for the confirmation, though!
Like Patrik said, I'm not sure that that will produce any different results, but what you could do is use dfhack to manually change the tile type of the ramps and floors to obsidian. Also time consuming, and if you are going to do it a lot I would suggest writing a script for it. But definitely doable
Title: Re: DFHack 0.44.12-r2
Post by: Rose on March 20, 2019, 08:51:11 am
Is there a function to find the center of the viewport that works with things like TWBT?
Title: Re: DFHack 0.44.12-r2
Post by: ViolinAnon on March 20, 2019, 10:35:08 am
I fail to see how obsidianizing using magma+water would give a different result from spawning obsidian directly. The problem comes from mining out of a huge block, so spawn only walls (and build floors out of obsidian [blocks]). It's still more work to spawn parts rather than a block that's mined out, of course.
I just assumed, for some reason, that casting obsidian that way would change the tile from air to obsidian.
Since my final goal is to have the entire tower smoothed out, then engraved, I think I'll be able to just create the giant block of obsidian, mine out the inside to create the rooms and whatnot, then use the 'tiletypes' commands to replace the floors, ramps and stairs into obsidian.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on March 20, 2019, 12:01:30 pm
Is there a function to find the center of the viewport that works with things like TWBT?
Gui::getDwarfmodeViewDims() is modified by TWBT (specifically the map_* fields). I'm guessing you can use that to find the center of whatever you need.
Title: Re: DFHack 0.44.12-r2
Post by: Clément on March 21, 2019, 06:23:54 am
I have a Qt-based library for dfhack clients I could publish too if you are interested.

Yes please!
By the way, with this Qt application you could recreate Dwarf Therapist entirely in DFHack, isn't?.
No need for .ini files, etc.
Just curious why you still keep using the original way

Here it is. (https://github.com/cvuchener/dfhack-client-qt) I tried to write some documentation (in README and headers), not sure if it is clear. It is also missing pkg-config or cmake find_package stuff so you'll have to add the compile and link flags manually. There is nothing special though, simply add the usual include path (-I/install/path/include), lib path (-L/install/path/lib) and link flags (-ldfhack-client-qt).

It is not much tested and the API may need improvements. Don't hesitate to report issues or make suggestions or improve it yourself.
Title: Re: DFHack 0.44.12-r2
Post by: ragundo on March 21, 2019, 03:21:57 pm
I have a Qt-based library for dfhack clients I could publish too if you are interested.

Yes please!
By the way, with this Qt application you could recreate Dwarf Therapist entirely in DFHack, isn't?.
No need for .ini files, etc.
Just curious why you still keep using the original way

Here it is. (https://github.com/cvuchener/dfhack-client-qt) I tried to write some documentation (in README and headers), not sure if it is clear. It is also missing pkg-config or cmake find_package stuff so you'll have to add the compile and link flags manually. There is nothing special though, simply add the usual include path (-I/install/path/include), lib path (-L/install/path/lib) and link flags (-ldfhack-client-qt).

It is not much tested and the API may need improvements. Don't hesitate to report issues or make suggestions or improve it yourself.

Thanks!!
I continued some time ago just where you finished with this repo.
I parse codegen,out.xml from DFHack and generate automatically a proto file and a remote C++ object for each df structure, so you write something like this

    rdf::DF_Instance d;
    d.connect();
    auto& global = *d.global();
    auto& world = global.world();
    auto& units = world.units();
    auto& units_all = units.all();
    auto& a_unit_pointer = units_all[0];
    auto& a_unit = *a_unit_pointer;
    auto& unit_name = a_unit.name();


But I fell in love with your qt.widget dfhack plugin. It's a wonderful solution to the problem of creating graphical DF tools. You just access the DF data directly from the plugin.
My solution works, but it's overengineered, used a lot of disk space and compilation times were atrocious.

I'm working in a graphical viewer for df structures (like gui-gm editor). I made it work in linux using my library, but, for the reasons mentioned above, I didn't publish it.

This changes now with your plugin. I can generate automatically a QAbstractItemModel and custom nodes for each df structure/field and recreate the graphical viewer easily without the overhead of my library.

So, again, thanks for your work and I hope that soon I could publish the plugin.
Title: Re: DFHack 0.44.12-r2
Post by: Clément on March 21, 2019, 06:15:51 pm
You just access the DF data directly from the plugin.

Not that directly. Don't forget you are running in a different thread. DF may change the data unexpectedly.
Title: Re: DFHack 0.44.12-r2
Post by: Clément on March 25, 2019, 09:31:14 am
Does Units::getVisibleName really require a mutable df::unit pointer?
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on March 25, 2019, 09:53:00 pm
A lot of functions in modules don't need to mutate anything but take a non-const pointer anyway. (Some are related to all methods from df-structures being non-const, from what I remember, even if they're const in DF.)
Title: Re: DFHack 0.44.12-r2
Post by: Clément on March 26, 2019, 03:57:27 am
Should I change my code to use non-const pointers or can the functions be fixed? Adding const shouldn't require to much code changes, but it may break ABI (plugins are recompiled for each version, so not a problem?).
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on March 26, 2019, 11:40:18 am
Yeah, it'd change some symbol names. There would still be the issue of calling non-const virtual methods on a const object, though, which would be harder to fix (and would require codegen changes to work properly). It's not impossible, and a temporary solution could make only "const" additions that compile, but it's potentially tedious.
I think your easiest solution at the moment (even though it's bad) is to just cast away the const for library functions that require it.
Title: Re: DFHack 0.44.12-r2
Post by: Clément on March 26, 2019, 01:55:29 pm
Okay, I'll use mutable pointers, it is not really issue for me. I just wanted to know if it was an easy fix.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on March 26, 2019, 06:50:23 pm
ok wrote a script that purges all but the adventurer from the site in hopes of easing FPS so far this script kinda needs to run multiple times to get everyone.
Code: [Select]
function Gigapurge()
local adv=df.global.world.units.active[0]
for k,v in pairs(df.global.world.units.active) do
if v.civ_id ~= adv.civ_id then
df.global.world.units.active:erase(k)
end
for ko,vp in pairs(df.global.world.units.all) do
if adv.id ~= vp.id then
df.global.world.units.all:erase(k)
end
end
end
end
Gigapurge()

so far this script spits out and error a couple of times but repeated use will work. said script will wipe companion, I don't know what pandora's box this script will open wiping out the units in the all and active lists will do.

oh and I notice the unit levels return to normal after a long long jog away from the camp in slow travel so I guess it's a mix of needing to dump the cache of wild animals spawn in the camp, and walking away from the camp so the game will unload and save the camp new set up.... and toggling town flag on the camp.


edit: this might lead to save corruption so uhh yeah probably be wary on using this.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on March 27, 2019, 02:26:35 am
I suspect you're playing with fire, Rumrusher. This is unpleasantly similar to the bugged DFHack clearing of "dead" (inactive in reality) units that just left them in limbo at map entry. I'd recommend you to take a very close look at what you're doing

I don't know how the "pairs" operator handles iteration over lists that are modified in the process, but the normal way to purge things from dense lists (which these lists are) is to iterate over each index backwards. If you remove element i, that will move all elements beyond that one one step forward, and you'd then take a look at i - 1, which has not been affected except possibly of a "next" link, if one is present. If you were to do it forwards you'd have to refrain from increasing the index when you delete an element (and I suspect that's why you have to run it several times, as each deletion probably skips looking at the next element).

Note that I still advocate a great deal of caution and to analyze what's done. I haven't, so this warning is a gut feeling one.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on March 28, 2019, 12:20:24 am
I suspect you're playing with fire, Rumrusher. This is unpleasantly similar to the bugged DFHack clearing of "dead" (inactive in reality) units that just left them in limbo at map entry. I'd recommend you to take a very close look at what you're doing

I don't know how the "pairs" operator handles iteration over lists that are modified in the process, but the normal way to purge things from dense lists (which these lists are) is to iterate over each index backwards. If you remove element i, that will move all elements beyond that one one step forward, and you'd then take a look at i - 1, which has not been affected except possibly of a "next" link, if one is present. If you were to do it forwards you'd have to refrain from increasing the index when you delete an element (and I suspect that's why you have to run it several times, as each deletion probably skips looking at the next element).

Note that I still advocate a great deal of caution and to analyze what's done. I haven't, so this warning is a gut feeling one.
yeah this script is pretty much a big risk for being a solution for what I would pretty much avoid if it happen to me in adv mode, but was made to solve 'accidental influx of animal and wildlife filling up a camp.' which I noticed is caused by folks slow traveling around the camp edges repeatedly and ended up triggering the adv mode wildlife fill in in the campgrounds which ends up filling it up.

and it took me this long to notice this due to all the fast travel scripts I use bypass all that by plopping the adventurer into the camp instead of walking towards it or fast traveling near the camp barrier move in a bit then fast traveling to the part of the camp where I set up my stuff if I did this with out dfhack.
that said thanks for the helpful tip.
Title: Re: DFHack 0.44.12-r2
Post by: MobRules on March 30, 2019, 04:12:18 pm
OK, apologies if this is a dumb question, but google and readthedocs have failed me, so...

In the enhanced stocks view, some items have a blue asterix right before the quality marker. I have been unable to find anything that tells what this asterix is intended to indicate, nor can I find any pattern in which items have it and which items don't. It's driving me batty :).

So, what does the blue asterix indicate?
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on March 31, 2019, 10:35:55 am
OK, apologies if this is a dumb question, but google and readthedocs have failed me, so...

In the enhanced stocks view, some items have a blue asterix right before the quality marker. I have been unable to find anything that tells what this asterix is intended to indicate, nor can I find any pattern in which items have it and which items don't. It's driving me batty :).

So, what does the blue asterix indicate?
According to the code (https://github.com/DFHack/dfhack/blob/c11f2b5ffa7434afca44e9ad44ea61d2f1aec37c/plugins/stocks.cpp#L471-L472) it's for improved items. It does seem like something that ought to be in a legend somewhere.
Title: Re: DFHack 0.44.12-r2
Post by: MobRules on April 01, 2019, 01:56:19 pm
According to the code (https://github.com/DFHack/dfhack/blob/c11f2b5ffa7434afca44e9ad44ea61d2f1aec37c/plugins/stocks.cpp#L471-L472) it's for improved items. It does seem like something that ought to be in a legend somewhere.

Ah! Thanks :)
Title: Re: DFHack 0.44.12-r2
Post by: neutrino431 on April 01, 2019, 08:51:05 pm
Can you create teeth to use in decoration with any of the available item spawning tools?
Title: Re: DFHack 0.44.12-r2
Post by: Pvt. Pirate on April 03, 2019, 09:44:02 am
i am redirecting an issue with mousequery:
I am getting the same mouse problem jaynixxo was having as well, it seems to be 87 by 43 tiles that the mouse will let me click on in full screen, so the problem goes away if I play very zoomed in. 

I'm getting this problem as well, the mousequery only works inside a set area, if i zoom out the mouse doesn't scale to the now larger view area, doesn't matter if i'm windowed or fullscreen.

But in my case i also can't use right-click to pan around the map properly and it seems related to zoom level. At some levels i can only pan up or left and up, sometimes it pans up and down but not left or right.
this problem might relate to my mousequery problem, where it works fine for top and left mouse scrolling, but not the right and bottom border. i use 5:4 screen and 1280x960 windowed mode. so far none of the widescreen players confirmed if they get the same problem when they chose windowed and smaller res.

Yeah, most of the time i can scroll left or up, but not right or down.

I play with 1920x1080 and the problem remains the same in windowed or fullscreen. And i just tried windowed with a low resolution (800x600) and the problem remains the same.

If i zoom the map all the way out, mousequery only works on a part of the top-left corner that is 87x40 tiles, which i designated on this image. The entire map is 192x192 tiles.
Spoiler (click to show/hide)

the problem got introduced in 44.09, but there still was a fix back then:
installing an alternative dfhack version including different mousequery code

ever since 44.12 the fix doesn't work, because that dfhack fork was dropped.
Title: Re: DFHack 0.44.12-r2
Post by: Clément on April 06, 2019, 07:13:33 am
Are Core::runCommand or printing to Core::getConsole thread-safe?

Edit:
I currently only access/modify DF data when a CoreSuspender is locked, but I wonder if this could be relaxed. Can any assumption be made on some pointers validity with regards to state change events (SC_WORLD_LOADED, SC_WORLD_UNLOADED, SC_MAP_LOADED, SC_MAP_UNLOADED, SC_PAUSED, SC_UNPAUSED, ...) for read-only access?

I did not have any answer for this question. I am asking again a more precise version: can raws be read between SC_WORLD_LOADED and SC_WORLD_UNLOADED without suspending the core?
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on April 07, 2019, 07:42:26 am
Without having any proof, I assume the data structures populated from raws are all created/read during world gen, with potential additional entries added as part of the world gen (e.g. syndromes). I see no point in ever removing any entries as they're not that many, and in many cases they don't even have numeric identifiers (e.g. creatures and plants), with indices being used in other data structures. If any changes would occur, they'd probably be in the form of new entries added at the end. Even if you were to make modifications, such as e.g. a ritual that turned all strawberries blue and poisonous, you'd probably still have to keep track of the old kind (e.g. in a depiction of a dorf eating a strawberry), from the new kind, hunting down and replacing all applicable entries (i.e. all the berries and plants in existence).
Similarly, I'd suspect art and art forms only grow through addition at the end of the vectors, with nothing being removed.

Regardless, if you access data while DF is running, you'd have to determine whether it's probably safe on a case-by-case basis.
Also note that nothing is safe from DFHackery, but I'd rather use a disclaimer for that case.
Title: Re: DFHack 0.44.12-r2
Post by: Clément on April 07, 2019, 08:37:48 am
Adding at the end is still an issue because DF mostly uses std::vector which may invalidate pointers/references to existing elements when it is resized (you need std::deque or std::list to avoid that). Although a lot of vectors contain pointers, so only the pointers are moved, not the pointees. So if the raws are never removed, I could keep these pointers, as long as I don't read through vectors, it should be safe.

For example, if I want to access item information at any time, I could copy world.raws.itemdefs, then look for itemdefs in my own copy. Reading itemdefs would then be safe except maybe for complex objects like std::string if a DFHack script or plugin decide to modify them during the game.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on April 07, 2019, 12:19:55 pm
As far as I know, the raws entries are never modified after world gen except if a script uses dfhack to do it, although they are re-read every time you start df which is why changes made with dfhack revert. I don't see why you couldn't just create a copy of the raws structure on start and access it whenever you want. Of course if you want to access other information this no longer is true since almost all of the other information changes through the game (I do believe that PatrikLundell is correct though and that most things append instead of prepend or replace)
Title: Re: DFHack 0.44.12-r2
Post by: Staalo on April 07, 2019, 02:56:37 pm
I have noticed an increasing tendency to segfault without warning in my latest fort. Now the save is finally in a state where I can't let the game run more than a week before crashing; the message is typically like this:

Quote
line 15: 80035 Segmentation fault: 11  DYLD_INSERT_LIBRARIES=./hack/libdfhack.dylib ./dwarfort.exe "$@"

Earlier I thought this was about TWBT, since I was trying it out with this fort, but with a clean DF install (the latest Mac version) with only DFHack added the problem still persists.
Any ideas what could be causing this? I saw a mention to weapon traps, but apparently that bug got fixed few versions ago.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on April 07, 2019, 04:14:03 pm
The main crash reason for the current version is caused corruption related to raiding. The troop equipment lists (where you select equipment for troops) get corrupted to contain various books/codices, and not long after that DF crashes. Presumably this is caused by improper handling of equipment carried away from the fortress on raids and then restoring equipment as the troops return, so never raiding is probably safe from that bug, and I speculate that it may be safe if you don't save a fortress when any squads (and parts thereof) are out of the embark, but that speculation is untested, as far as I know.

The weapon trap bug has been fixed.

Have you tested without DFHack and verified that the problem goes away? If so it's likely to be DFHack related, while a remaining problem may still be caused by damage caused by some earlier DFHacking.
Title: Re: DFHack 0.44.12-r2
Post by: Staalo on April 08, 2019, 02:19:33 am
Tested it with a fresh clean DF install with no changes or additions; it still crashes after few game days without warning.

Interesting point about raiding corruption though; I'm doing a "conquer the continent" challenge with this fort so there are constant raids coming and going. There have been dozens of occupation squads who were sent out permanently (with their gear and all) and might contribute to this corruption.
I have tried to avoid saving when there are units off screen (remembering earlier bugs with lost squads) but most likely at least auto saves have happened while a raid team was out.

So maybe this isn't about DFHack, it's just Dwarf Fortress itself not being ready for this style of playing?
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on April 08, 2019, 03:00:18 am
You're unlikely to be able to conquer the continent due to the raiding bug. Check all kinds of military equipment (Armor,Gauntlets, etc.) and go down to the bottom of the list for each category. When the bug manifests itself there are nonsensical entries at the bottom of at least one category. All my fortresses trying raiding have died due to this bug (except the first, which couldn't raid at all due to a bug preventing dead civ raids from ever getting anywhere). Thus, I consider raiding to be FUBAR and expect it to remain so at least until the post villain bug fixing (While Toady has acknowledging not fixing the weapon trap crash bug was bad and indications he'll change to a more parallel development style with support for the current release while working on the next one in the future, there's no indication he'll switch earlier than he's forced to).
Title: Re: DFHack 0.44.12-r2
Post by: Staalo on April 08, 2019, 04:48:52 am
You're probably refering to stocks screen, right? I can't see anything out of ordinary in any category; all items seem to make sense and can be confirmed to exist somewhere within the fortress. Everything else seems to point at the raiding corruption bug, though; most likely it's going to be impossible to complete this challenge.

Anyway I'll drop this topic since obviously it isn't a DFHack problem. Many thanks for your help.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on April 08, 2019, 08:20:10 am
I'm not referring to the stocks screen, but to the militia equipment screen, where you typically specify broad categories such as helmet, or metal helmet, but you can also specify an exact piece of equipment, and that's where the corruption can be visible.
Title: Re: DFHack 0.44.12-r2
Post by: Staalo on April 08, 2019, 02:19:38 pm
Ah, yes. Well, looking at this

Spoiler (click to show/hide)

I'd say that yes, this definitely looks like the bug you mentioned.  Funny that I didn't notice that earlier while playing with equipment. So this probably means that the fort is pretty much done?
Title: Re: DFHack 0.44.12-r2
Post by: Roses on April 08, 2019, 03:14:30 pm
Ah, yes. Well, looking at this

Spoiler (click to show/hide)

I'd say that yes, this definitely looks like the bug you mentioned.  Funny that I didn't notice that earlier while playing with equipment. So this probably means that the fort is pretty much done?

You might be able to go through with DFHack and manually delete all uniform information, but I'm guessing it's probably just completely FUBAR
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on April 08, 2019, 03:27:48 pm
Well, technically the fortress can continue to exist as long as you disband all militia and never create any (which means any camping invaders can only be removed through random visits of mercs or other invaders hostile to them...).

Regarding Roses' suggestion, I've tried to clear the equipment lists of "garbage" with DFHack, but that has no effect as the garbage is back the next time the UI is brought up, probably because the UI lists are populated from some other structure I was unable to locate (and which may not be mapped by DFHack). I looked at the item lists, and they looked the same as usual (i.e. stuff not matching the DFHack names at times, but that's probably more a matter of the DFHack structure identification being slightly off when it comes to the purpose of the item structures).
Title: Re: DFHack 0.44.12-r2
Post by: Staalo on April 08, 2019, 04:16:47 pm
All right. In that case it seems the best option is to mothball this fort in hopes that the bug can be fixed in some future version, and concentrate on more peaceful pursuits. Too bad, I had managed to steamroll over half the continent already before it became impossible to continue.

Thanks for your help.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on April 09, 2019, 10:07:23 am
Patrik/Roses, is it possible to identify the issue programmatically (i.e. not just by visual inspection)? A script to at least detect the issue would be somewhat useful, even if it's not recoverable at the moment.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on April 09, 2019, 10:43:12 am
Patrik/Roses, is it possible to identify the issue programmatically (i.e. not just by visual inspection)? A script to at least detect the issue would be somewhat useful, even if it's not recoverable at the moment.

I haven't actually looked at this particular issue programmatically, but if Patrik was able to find the garbage with DFHack it shouldn't be too hard, to at least set up a periodic check of the issue. Since the garbage kept returning I'm guessing there is a secondary location where that information is stored that kept repopulating the garbage. Doing a brief cursory search through the df-structures it appears the error might creep up in the df.military, squad_uniform_spec. If I get a chance sometime this week I can look and see if that is true, but like Patrik mentioned it may be arising from a location that hasn't been mapped
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on April 09, 2019, 11:05:05 am
Unless the locations mentioned by Roses show corruption it might be a bit messy, as the identification involves bringing up the squad equipment UI and specific equipment sub menu, and I expect those structures to exist only when viewed (as their part of the view structure). If a permanent structure showing the corruption can be found it should be reasonably easy to detect: just go through all items and see if there are non wearable items there (you may want to handle shields and weapons too, though, and possibly weird wielded artifacts [like cabinets]).
Having a script bring up the squad equipment menu/specific equipment sub menu is probably possible, though, but it's not suitable as a background activity.

I'm currently not doing anything with DF itself due to this bug, though: it's forum activity only for the next half a year or so (until a somewhat stable Villains release exist).
Title: Re: DFHack 0.44.12-r2
Post by: fortunawhisk on April 09, 2019, 09:50:32 pm
All right. In that case it seems the best option is to mothball this fort in hopes that the bug can be fixed in some future version, and concentrate on more peaceful pursuits. Too bad, I had managed to steamroll over half the continent already before it became impossible to continue.

@Stallo, could you upload the save to dffd (if you haven't already) and post the link? It might be handy to have a copy where the problem already exists, rather than trying to replicate.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on April 10, 2019, 01:22:54 am
@fortunawhisk: There's no lack of saves with the bug (including a couple of mine). Most of the crash reports for the current version on the bug tracker is caused by this bug. Someone with a tag I can't catch (ruisuif or something like that) went through the crashing saves and verified the cause in the majority of those (finding the corruption of the data and verifying the repeatable crashes went away of all militia was disbanded). Thus, there's not much point in more saves containing this bug.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on April 10, 2019, 03:20:12 am
hmm kinda wonder if it possible to just create another fort in this save or is that world just doomed
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on April 10, 2019, 04:06:03 am
hmm kinda wonder if it possible to just create another fort in this save or is that world just doomed
My unsubstantiated guess is that a new fortress probably would be fine (until you raid), because the items you equip soldiers with are (supposed to) be items local to the fortress, so it's that information that gets corrupted, and the corruption is somehow caused by a bugged handling of what originally was fortress equipment held by raiding soldiers when they return, so if you never raid in a new fortress you probably would start from a blank slate. However, a quick embark with some embark points spent on armor would show if the equipment lists are corrupted from the start. That won't guarantee that corruption isn't hiding somewhere, of course.
Title: Re: DFHack 0.44.12-r2
Post by: Bumber on April 10, 2019, 04:21:15 am
What about just retiring then un-retiring? Would that help at all?
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on April 10, 2019, 06:38:58 am
What about just retiring then un-retiring? Would that help at all?
I just tried it, and DF died on saving the retired fortress (both with and without DFHack)... so there's no save to unretire. It's only one world, though, but still an indication. Wouldn't exactly be surprise if DF is unable to package up the corrupted data.

Abandoning worked, though, and reclaiming with default embark parameters worked (with the surface being an absolute mess of items once inside the fortress, as well as an immediate "ambush" from the locals). Initially the specific equipment in all categories except weapons were empty (as nothing was brought). Reclaiming the junk on the surface populated the lists with legal items (no corruption seen) in all categories except shield (empty) and weapons (standard tools only still). Presumably the shield and weapons are inside the fortress down in unrevealed areas. Thus, embarking afresh might work, as might abandoning/reclaiming (assuming you're prepared with the mess that's involved with reclaiming, but I guess you can send off all citizens except one to other places (unless they have offsite kids) before abandoning so you don't have to slaughter the locals on reclaiming.

Regarding the structures Roses mentioned, they seem to be used for squads, and I assume DF crashes when DF tries to place an unsuitable object in those structures. We probably need to get at the lists from which DF selects those items to DFHack around the issue.
Title: Re: DFHack 0.44.12-r2
Post by: Clément on April 10, 2019, 08:16:49 am
I'd like to know if my Qt experiment works on macOS (I am worried by this (https://bugreports.qt.io/browse/QTBUG-7393)). But, since I cannot use macOS myself, I need help from a macOS user who knows how to compile DFHack plugins.

Download and compile the plugin from here (https://github.com/cvuchener/dfhack-qt/tree/master). You will need to install Qt (homebrew can help with that) and pass its installation directory to cmake with -DCMAKE_PREFIX_PATH (-DCMAKE_PREFIX_PATH=/usr/local/opt/qt for homebrew installation).

Try enabling the plugin ("enable qapplication"), then try commands like "qt-info" or "qt-log". Please tell me if windows appear and if DF survives it. Also check the content of "qt_log.txt" in DF directory (or the content of the log window if it works).
Title: Re: DFHack 0.44.12-r2
Post by: fortunawhisk on April 10, 2019, 08:24:45 am
@fortunawhisk: There's no lack of saves with the bug (including a couple of mine). Most of the crash reports for the current version on the bug tracker is caused by this bug. Someone with a tag I can't catch (ruisuif or something like that) went through the crashing saves and verified the cause in the majority of those (finding the corruption of the data and verifying the repeatable crashes went away of all militia was disbanded). Thus, there's not much point in more saves containing this bug.

Adding a link to the equipment corruption / crash bug report. There ARE a lot of linked saves.
http://www.bay12games.com/dwarves/mantisbt/view.php?id=11014 (http://www.bay12games.com/dwarves/mantisbt/view.php?id=11014)

Title: Re: DFHack 0.44.12-r2
Post by: Roses on April 10, 2019, 08:38:25 am
Regarding the structures Roses mentioned, they seem to be used for squads, and I assume DF crashes when DF tries to place an unsuitable object in those structures. We probably need to get at the lists from which DF selects those items to DFHack around the issue.

I was worried that might be the case
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on April 10, 2019, 09:17:31 am
so I guess if you want to raid in this buggy state you have to remove all items from your military uniform and send them out?
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on April 10, 2019, 10:48:45 am
so I guess if you want to raid in this buggy state you have to remove all items from your military uniform and send them out?
No, the bug probably doesn't have to do with uniforms in the sense of a set of equipment, but rather with uniforms in the sense of the equipment allocated to militia in their capacity of militia. A uniform is just a template of selection criteria for items, and as far as I know these criteria get copied to the militia member when the uniform is allocated, so there's no difference in the militia squad info between a selection of a metal helmet and a user selection of a metal helmet for the head slot. Sure, civilian clothing and no shield nor weapons might not provoke the bug (we don't know for sure that civilian clothing doesn't corrupt things as well: after all, it also gets removed from the fortress and then gets returned to it when the buggers return), but their survivability isn't that great should it come to blows (but a squad that doesn't return probably doesn't generate corruption). If I was to gamble, I'd try to never load a save where any troops are outside of the embark and see if the corruption is caused by restoring offloaded data, as it might be that data that's retained in the item structure is fine, but I haven't heard of that being tested. The only safe action currently is never to raid.
Title: Re: DFHack 0.44.12-r2
Post by: Atarlost on April 12, 2019, 03:33:40 pm
Is there some way to truly erase trees?  I tried using tiletypes to turn them into empty air and they reappear the next time plants are processed and "plants extirpate" seems to no longer be implemented. 

They're kind of a problem when they're in edge connected water where I'd need to drop my dam to drain the lake. 
Title: Re: DFHack 0.44.12-r2
Post by: Bumber on April 12, 2019, 04:22:25 pm
Is there some way to truly erase trees?  I tried using tiletypes to turn them into empty air and they reappear the next time plants are processed and "plants extirpate" seems to no longer be implemented. 

They're kind of a problem when they're in edge connected water where I'd need to drop my dam to drain the lake.
Fire a ballista at them.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on April 12, 2019, 04:28:37 pm
Bumber beat me to it...

Is there some way to truly erase trees?  I tried using tiletypes to turn them into empty air and they reappear the next time plants are processed and "plants extirpate" seems to no longer be implemented. 

They're kind of a problem when they're in edge connected water where I'd need to drop my dam to drain the lake. 
It sounds that your problem is cavern trees standing in the lake. My standard method to get rid of those is to fire at them with a ballista: A ballista arrow hitting a tree will disintegrate it completely. It's even possible to fire at tree stems under water if you've got a drain to protect the ballista operator. Note that any part of the tree can be hit for the tree to disappear, so most of the time you don't need to attack them from beneath.

It's possible to remove them from using DFHack, but I don't know if there's a command for it. Changing the tile doesn't help, as you've discovered, because the tree exists in the plants list as well (there's a bug involving repeated cave-ins due to maturing trees that were caved in originally, as DF apparently missed to remove those trees, so when growing they pop into existence and grow in the air, and then falls as they find there's no ground supporting them).
Title: Re: DFHack 0.44.12-r2
Post by: zaporozhets on April 14, 2019, 09:15:52 pm
Changing the tile doesn't help, as you've discovered, because the tree exists in the plants list as well (there's a bug involving repeated cave-ins due to maturing trees that were caved in originally, as DF apparently missed to remove those trees, so when growing they pop into existence and grow in the air, and then falls as they find there's no ground supporting them).
That's really interesting, and quite pertinent to something I'm working on, couldn't you just remove the tree from the plants list to prevent this from happening?
Title: Re: DFHack 0.44.12-r2
Post by: Rose on April 15, 2019, 12:14:06 am
A script request, if anybody feels up for it.

Add a clothing item sized for each member of your fort to the manager screen, to help with multiracial forts.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on April 15, 2019, 03:12:40 am
@zaporozhets: Here's the removingflyingtrees script written some time ago to deal with trees caving in.
Spoiler (click to show/hide)

In that case the only thing that needed to be removed was the plant entry. If you want to remove a specific tree you need to both get rid of it from the plants list and get rid of the tile info. However, I don't know if there's something else that would have to be dealt with as well.
Title: Re: DFHack 0.44.12-r2
Post by: zaporozhets on April 16, 2019, 09:02:28 am
Thanks. Appreciated.
Title: Re: DFHack 0.44.12-r2
Post by: rel1c on April 18, 2019, 04:02:27 pm
Not sure where to ask this as I've scoured google for an answer..

I'm looking to cure only infection from my adventurer. I tried forking full-heal, but alas I can't seem to figure it out. I can get a list of wounds in unit.body.wounds, but they just look like memory addresses. Example:

<unit_wound: 0000025C0216BC10>
<unit_wound: 0000025C0216BD60>
<unit_wound: 0000025C0216C540>
<unit_wound: 0000025C0216BCF0>
<unit_wound: 0000025C0216BF90>
<unit_wound: 0000025C0216D420>

Any pointers? Thanks
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on April 18, 2019, 06:26:04 pm
Not sure where to ask this as I've scoured google for an answer..

I'm looking to cure only infection from my adventurer. I tried forking full-heal, but alas I can't seem to figure it out. I can get a list of wounds in unit.body.wounds, but they just look like memory addresses. Example:

<unit_wound: 0000025C0216BC10>
<unit_wound: 0000025C0216BD60>
<unit_wound: 0000025C0216C540>
<unit_wound: 0000025C0216BCF0>
<unit_wound: 0000025C0216BF90>
<unit_wound: 0000025C0216D420>

Any pointers?
Looks like you found the pointers just fine to me! :)

Anyway, those are pointers to objects. You can access properties of each individual object, e.g. wounds[0] will be a unit_wound object. I've done this enough that I'm not really sure how to explain it better than that. If that doesn't help, can you post exactly what you're doing to get that output?
Title: Re: DFHack 0.44.12-r2
Post by: rel1c on April 18, 2019, 10:18:36 pm
haha yeah i guess i did!

I'm specifically trying to find out what each wound object is named. So which pointer points to the object that represents say a nose cut that's infected.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on April 19, 2019, 07:50:55 pm
They don't really have names like that. Here's the XML definition for unit_wound (https://github.com/DFHack/df-structures/blob/0.44.12-r2/df.units.xml#L1303). I'd guess "parts" has some stuff that's useful for you.
Title: Re: DFHack 0.44.12-r2
Post by: Atomic Chicken on April 20, 2019, 03:36:41 am
I'm looking to cure only infection from my adventurer. I tried forking full-heal, but alas I can't seem to figure it out. I can get a list of wounds in unit.body.wounds, but they just look like memory addresses.

Use the 'gui/gm-editor' command. It's the most convenient way to visualise structures and allows for manual editing.

A script like this is probably what you're after:
Code: (adv-cure-infection.lua) [Select]
local unit = df.nemesis_record.find(df.global.ui_advmode.player_id).unit
unit.body.infection_level = 0
for _,wound in ipairs(unit.body.wounds) do
  wound.flags.infection = false
end
Title: Re: DFHack 0.44.12-r2
Post by: Alatun on April 20, 2019, 04:37:47 pm
Hi!

I've got a question regarding "eventful.lua" in DF-Hack. I'd like to track some information about dwarfs over multiple years. I've written a small LUA script to export data in a kind of XML style. Now I'm looking for way get this LUA script being triggered automatically and thought there could be an event (like at the 1st of each month).

But what I found so far is:

Code: [Select]
eventType=invertTable{
    [0]="TICK",
    "JOB_INITIATED",
    "JOB_COMPLETED",
    "UNIT_DEATH",
    "ITEM_CREATED",
    "BUILDING",
    "CONSTRUCTION",
    "SYNDROME",
    "INVASION",
    "INVENTORY_CHANGE",
    "REPORT",
    "UNIT_ATTACK",
    "UNLOAD",
    "INTERACTION",
    "EVENT_MAX"
}
Looks like an event being triggered at the beginning of each month is not available. There is an event called "TICK". I was thinking about using this event, but it looks "dangerous" and I found no other script using it so far. As I'm no LUA expert, I'm also unsure how to setup an event handler for this case.

The "TICK" seems to correspond to 0. When looking at the C++ source of the event plugin I saw this:

Code: [Select]
static const handler_t eventHandlers[] = {
 NULL,
 ev_mng_jobInitiated,
 ev_mng_jobCompleted,
 ev_mng_unitDeath,
 ev_mng_itemCreate,
 ev_mng_building,
 ev_mng_construction,
 ev_mng_syndrome,
 ev_mng_invasion,
 ev_mng_inventory,
 ev_mng_report,
 ev_mng_unitAttack,
 ev_mng_unload,
 ev_mng_interaction,
};
So eventHandlers[0] == NULL.

My assumption so far: the TICK event is not implemented. Is my assumption correct or did I miss something?

If it should work, can anybody give me an example, how it could be used?
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on April 20, 2019, 05:04:22 pm
There's already a "repeat" script that can run other scripts periodically, if that's what you want. If it doesn't work for you, it uses a separate timeout API that's probably easier to use than eventful for your purposes.
Title: Re: DFHack 0.44.12-r2
Post by: Alatun on April 20, 2019, 05:42:11 pm
Ok, thx. I will take a look if that could suit my need.
Title: Re: DFHack 0.44.12-r2
Post by: Rose on April 20, 2019, 11:21:49 pm
Will a plugin built for an R2 DFhack work with an R1 dfhack of the same DF version, or vice versa?
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on April 21, 2019, 12:36:20 am
Nope, it'll fail the DFHack version check in both cases.
Title: Re: DFHack 0.44.12-r2
Post by: Alatun on April 21, 2019, 08:19:22 am
Just discovered that LUA's

io.stdout:write(...) gets written to stdout.log. To get something printed in the dfhack console window, you must use "print".

When using loops to generate output print is a problem, because each call appends a newline automatically. Is there another way to write something to the df console using the io.stream ... api?

I know, I can concatenate strings, but this is ugly.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on April 21, 2019, 11:45:44 am
Just discovered that LUA's

io.stdout:write(...) gets written to stdout.log. To get something printed in the dfhack console window, you must use "print".

When using loops to generate output print is a problem, because each call appends a newline automatically. Is there another way to write something to the df console using the io.stream ... api?

I know, I can concatenate strings, but this is ugly.
You're looking for "dfhack.print", with "dfhack.println" adding a newline (which you didn't want).
Title: Re: DFHack 0.44.12-r2
Post by: Alatun on April 22, 2019, 01:55:03 am

You're looking for "dfhack.print", with "dfhack.println" adding a newline (which you didn't want).

Thank you.
Title: Re: DFHack 0.44.12-r2
Post by: vjek on April 24, 2019, 06:01:41 pm
Updated scripts/pref-adjust.lua (https://github.com/vjek/scripts/blob/patch-1/pref-adjust.lua) on the weekend, submitted the pull request (https://github.com/DFHack/scripts/pull/92).  Working great for me, the previous version was crashing 0.44.12 (along with prefchange. I PM'd Max) due to not handling the new music/dance/poetry entries.

In case anyone was curious, it's much better now and fixed.  :o

As always, there's more options to add, but I figured fixing the crash bug was important.
Title: Re: DFHack 0.44.12-r2
Post by: Clément on April 28, 2019, 08:26:31 am
I'd like to know if my Qt experiment works on macOS (I am worried by this (https://bugreports.qt.io/browse/QTBUG-7393)). But, since I cannot use macOS myself, I need help from a macOS user who knows how to compile DFHack plugins.

Download and compile the plugin from here (https://github.com/cvuchener/dfhack-qt/tree/master). You will need to install Qt (homebrew can help with that) and pass its installation directory to cmake with -DCMAKE_PREFIX_PATH (-DCMAKE_PREFIX_PATH=/usr/local/opt/qt for homebrew installation).

Try enabling the plugin ("enable qapplication"), then try commands like "qt-info" or "qt-log". Please tell me if windows appear and if DF survives it. Also check the content of "qt_log.txt" in DF directory (or the content of the log window if it works).

Hi, I am still looking for a macOS user who can help me.
Title: Re: DFHack 0.44.12-r2
Post by: Schmaven on May 01, 2019, 06:16:10 pm
I saw the command in another thread but haven't been able to find it again yet...  Does anyone remember how to tell what types of animals exist on a particular embark?  It's likely in 1 of the 100+ pages here I am still digging through. 
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on May 01, 2019, 07:37:37 pm
What do you mean by "exist"? Are you looking for the animals on the map, or animals that could appear on the map? Regular creatures or vermin? Is this before or after embarking?
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on May 01, 2019, 09:11:09 pm
so poking around unit enemy 4406_1 flags I ended up finding out that the flag 57 is the toggle for if the unit can talk or not.
which means with a dfhack script you can give anyone the ability to fly, and talk.
but if the creature it self can't talk then you can't talk and this set up won't work.
though I did found out you can just bypass that block by looking at stuff in adventure mode and while looking use dfhack to switch the advmode_ui menu from look to conversationaddress which brings up the talk menu.
Title: Re: DFHack 0.44.12-r2
Post by: Schmaven on May 02, 2019, 04:06:21 am
What do you mean by "exist"? Are you looking for the animals on the map, or animals that could appear on the map? Regular creatures or vermin? Is this before or after embarking?

My goal is to capture certain regular animals.  Before or after embarking would both be okay as I could simply abandon the fort and re-embark if those animals were not amongst the expected groups that wander in from time to time. 
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on May 02, 2019, 04:19:31 am
@Schmaven: I would guess you're looking for region-pops. If I remember correctly, the script finds the populations of plants and creatures in a 7*7 world tile area centered at the embark, which means some of them area actually out of reach (you can e.g. get ocean creatures in the list because there's an ocean 3 world tiles away).

Schmaven posted while I wrote this:
I'm not aware of any script that shows what's actually available to an embark. You could use the Biome Manipulator http://www.bay12forums.com/smf/index.php?topic=164658.msg7495705#msg7495705 (http://www.bay12forums.com/smf/index.php?topic=164658.msg7495705#msg7495705) to find the information by looking at each of the regions that are present on your embark (prior to embarking you can't know whether biomes present in neighboring mid level tiles will spill over into your intended embark rectangle or not). You can also use the Biome Manipulator to add creatures/plants you'd like to have as potential visiting groups if they're missing.
Title: Re: DFHack 0.44.12-r2
Post by: Rose on May 06, 2019, 01:47:46 pm
Is there an issue with the build system currently?

Also, is there a way to tell if a copy of DFHack is compiled for GCC 4.8 or 7? (From within DFHack)
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on May 06, 2019, 05:08:07 pm
An issue with what specifically?

I don't believe there's a way to tell those apart.
Title: Re: DFHack 0.44.12-r2
Post by: Rose on May 06, 2019, 05:17:05 pm
The last build on my PR failed on linux because of an unmet dependency of some sort. I didn't change anything that would effect that.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on May 07, 2019, 06:58:39 am
If you mean buildmaster, looks like the last build failed on the older Linux because it's using python 3.4, which Sphinx doesn't support anymore.
Title: Re: DFHack 0.44.12-r2
Post by: Rose on May 07, 2019, 10:07:48 am
That's exactly what I was meaning.
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on May 08, 2019, 03:03:18 pm
I need know hardcoded properties of ballista arrow and catapult rock.
Title: Re: DFHack 0.44.12-r2
Post by: risusinf on May 11, 2019, 10:57:47 pm
Someone with a tag I can't catch (ruisuif or something like that)
That would be me.
I expect those structures to exist only when viewed
Seems to be true. I was able to put a debugger breakpoint on the function that populates equip lists, but i don't really know how that memory mapping thing is done, what can i do from there?
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on May 12, 2019, 04:09:40 am
Sorry for not getting your tag correctly, risusinf, but I have a problem with some tags just not sticking, and though it better to give imperfect credit than none at all.

If you've managed to put a breakpoint at the function, it ought to be possible to read the assembly code to locate (with the help of the debugger, of course) the addresses of the structures the code looks at (my first guess is that those structures would be vectors the code then iterates over). With that in hand I'd try to iterate over all DFHack mapped structures, e.g. with a DFHack script, to find a matching address. If such an address match is found, I'd then identify the DF structure path to the structure(s).
However, there's a significant risk the structures DF populates the UI from haven't been mapped by DFHack, but we may be lucky to get unk_X matches.
Title: Re: DFHack 0.44.12-r2
Post by: risusinf on May 12, 2019, 10:50:14 pm
Thanks, i might try to figure that out at some point. I'll go with other, much more feasible insights for now.
Title: Re: DFHack 0.44.12-r2
Post by: Pvt. Pirate on May 13, 2019, 04:44:57 am
can someone finally fix the mousequery bug?
now with a 16:9 monitor, i can say the "mousequery edge" bug is not dependant on resolution.
it is well explained in its symptoms and exists ever since 44.9 (and there was a possible fix until 44.10, which got dropped)
all tilesets and mods move towards 44.12 and it's a pita (and most times impossible) making them work on 44.9.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on May 13, 2019, 05:36:36 pm
can someone finally fix the mousequery bug?
now with a 16:9 monitor, i can say the "mousequery edge" bug is not dependant on resolution.
it is well explained in its symptoms and exists ever since 44.9 (and there was a possible fix until 44.10, which got dropped)
all tilesets and mods move towards 44.12 and it's a pita (and most times impossible) making them work on 44.9.
Please link to a description of the bug. I've seen you mention it as if everyone knows about it several times, but I can't find a complete description of the problem you're having easily, and can't even attempt to fix it without one. The DFHack bug tracker (linked in the first post) would be the best place to report it in any case.
Some important information to include is what exact builds of mousequery you are using, both when you see the issue and when you don't. I know TWBT used to distribute its own. If you can give that information, I can try to compare the source code and look for any obvious causes, but I'm fairly confident that the merge back into DFHack was done correctly and there should be no functional differences.
And regarding "finally", it's not like we've been intentionally not fixing it to annoy you. We all work on DFHack in our free time, and I have had very little of that recently.

Edit: ok, some Googling turned up some posts. It sounds like mousequery edge "doesn't work" on the right or bottom side of the screen. Is this correct? If so, some follow-up questions:
(a) What exactly are you doing that works in some places and not in others? I have never used this feature, so I need to know exactly how to make it work. It's not entirely intuitive for me. Are you left/right/middle clicking/hovering over the edge of the window? Answer: hovering, but it needs "mousequery edge enable" to enable. "mousequery edge" isn't enough.
(b) Do you have intro movies turned off?
(c) Are you ever resizing the game window? If not, does resizing it fix the issue? (Exit fullscreen mode if you have to.)
(d) Can you provide links to the mousequery.plug.(dll/so/dylib) files that (i) work and (ii) don't work?
(e) What tileset are you using? Is it square or rectangular? If it's not a vanilla tileset (curses 8x12 or 16x16), can you try one of those and see if it works?
(f) Are you using TWBT? If so, does disabling TWBT entirely help?
Title: Re: DFHack 0.44.12-r2
Post by: Pvt. Pirate on May 14, 2019, 03:31:56 am
sorry for having been rude.

you found the description before I started searching.
i can't link you to the old version, as i do not have a link myself.
i could upload the 44.09 version of mousequery that works, but i do not know if its the one from twbt or not.
a) it is enabled by that command and doesn't work correctly also if it weren't enabled, the scrolling on top and left side wouldn't work either, but those work.
b) movies off - always
c) i usually don't resize window. i never use fullscreen either.
d) (i) working one https://www.dropbox.com/s/v3gjhco764p28uw/mousequery.plug.so?dl=0 (ii) not working http://www.bay12forums.com/smf/index.php?topic=163211.0 and http://www.bay12forums.com/smf/index.php?topic=161047.0 (as tested both on my LINUX-PC and the Win8-Laptop of a friend)
e) Mephs lite + curses 800x600 font // Phoebus + curses 800x600 font
f) TWBT always on testing turning it off, but i think i remember it not changing a thing.
Title: Re: DFHack 0.44.12-r2
Post by: Will_Tuna on May 14, 2019, 09:09:29 am
Q: Can you make a Guest that is 'ready to leave' a permanent resident of the fortress? maybe with tweak makeown?

in the description of makeown, it says to "select the creature", is that using 'k' or 'v'?

thanks for the help and thanks for all the work on dfhack!

PS: It is a wild boar woman fighter
Title: Re: DFHack 0.44.12-r2
Post by: Prismatic on May 14, 2019, 10:14:24 am
Basic learner's question. Looking through lua script examples from DFHack, I'm confused by this point: when should a global variable be used instead of a local variable?
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on May 14, 2019, 11:15:39 am
@Prismatic: Almost never.
Most cases of global variables being used are probably bugs. A global variable clutters the Lua global variable space. The case where you MIGHT consider using a global variable is when you want to retain data between script invocations but don't want it to survive DF restart. Also note that you'd probably want to use a very specific variable name for that case to avoid two scripts using the same one accidentally. Writing/Reading to/from a file is a way to store data in way to survive restarts. There's also a DFHack method to store data in the DF save game, but I've never used it. There's also a way to start a script that makes callbacks either at trigger points or at specified intervals, allowing you to keep the local data inside the script.
Title: Re: DFHack 0.44.12-r2
Post by: Pvt. Pirate on May 14, 2019, 11:22:45 am
added link to the working mousequery.plug.so https://www.dropbox.com/s/v3gjhco764p28uw/mousequery.plug.so?dl=0
could not find any .dll or whatever, but that might be because it's in the linuxLNP
Title: Re: DFHack 0.44.12-r2
Post by: Quietust on May 14, 2019, 05:57:33 pm
added link to the working mousequery.plug.so https://www.dropbox.com/s/v3gjhco764p28uw/mousequery.plug.so?dl=0
could not find any .dll or whatever, but that might be because it's in the linuxLNP
When lethosor asked for the dll/so/dylib, he meant that you should provide the one that matches your platform - DFHack uses .dll files for plugins on Windows, .so files on Linux, and .dylib files on MacOS.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on May 15, 2019, 07:46:47 pm
Pvt Pirate: sorry, I should have been nicer about that.
e) Mephs lite + curses 800x600 font // Phoebus + curses 800x600 font
f) TWBT always on testing turning it off, but i think i remember it not changing a thing.
I'd appreciate it if you could test without TWBT and test with just the 800x600 font (i.e. set everything to use the 800x600 font, or maybe just all the same font - no separate text/map tiles). The potential issue with square tiles is that they take up more space than rectangular tiles, so fewer of them can fit on the screen. This could cause issues because the "20th tile from the top" could be close to the bottom of the screen in the map view, but not at all close in the menu view, if that makes sense.
It's also possible that TWBT is interfering with mousequery even when the tilesets are all the same size, which is why I suggest disabling it entirely too.

When lethosor asked for the dll/so/dylib, he meant that you should provide the one that matches your platform - DFHack uses .dll files for plugins on Windows, .so files on Linux, and .dylib files on MacOS.
Yup. I couldn't remember which platform you were using, so I included all the possible extensions.


Basic learner's question. Looking through lua script examples from DFHack, I'm confused by this point: when should a global variable be used instead of a local variable?
By "local variables" do you mean ones declared inside a function, or ones declared with the "local" keyword anywhere (including outside a function)?
Anything declared without the "local" keyword ends up in the global namespace for that script, even if it's only declared inside functions. This can cause all sorts of fun bugs, so you should always use the "local" keyword when doing that (unless you really want a global, see below). Globals also persist across runs of the same script, which allows them to store persistent state in memory until DF exits. They can also be accessed by other scripts if needed.

Anything with the "local" keyword is limited to the scope where it's declared, or any nested scopes (let me know if that doesn't make sense and I can give some examples). If it's in the main body of a script (outside of any function), it won't persist across runs of the script, unlike globals, and it can't be accessed by other scripts (it's essentially destroyed after the script finishes running, just like any local variable inside a function).

@Prismatic: Almost never.
Most cases of global variables being used are probably bugs. A global variable clutters the Lua global variable space. <snip - this was a good point, see above>. Also note that you'd probably want to use a very specific variable name for that case to avoid two scripts using the same one accidentally.
No, each script has its own completely separate environment where its globals live. Globals in one script are (almost) entirely separate from those in another. That's why reqscript() and dfhack.script_environment() exist. Granted, there are a few special ones that are shared between scripts (df, dfhack, and the built-in functions, and maybe something else I'm forgetting), but scripts cannot create their own globals that are shared across all scripts.

Granted, globals are generally not a good idea, but when you need them, you don't have to give them unique names to prevent clashes with other scripts.


Q: Can you make a Guest that is 'ready to leave' a permanent resident of the fortress? maybe with tweak makeown?

in the description of makeown, it says to "select the creature", is that using 'k' or 'v'?

thanks for the help and thanks for all the work on dfhack!

PS: It is a wild boar woman fighter
"tweak makeown" predates visitors/guests by many years, so I wouldn't expect it to work, although I don't think I've tried. It's definitely something I've wanted to work, though.
As for how to use it: it uses DFHack's standard unit-selection API, which allows selecting a unit with 'v', 'k' (although you also have to make sure the unit is actually selected in the sidebar for this to work), and pretty much anywhere else you can select a unit in-game, like the 'u' menu. Most things that ask you for a unit, item, building, etc. should use a standard API for it. If you find a tool that doesn't allow you to select a unit/building/whatever in a place where other tools do allow it, that's probably a bug, so feel free to report it.
Title: Re: DFHack 0.44.12-r2
Post by: Pvt. Pirate on May 16, 2019, 02:55:53 am
Pvt Pirate: sorry, I should have been nicer about that.
e) Mephs lite + curses 800x600 font // Phoebus + curses 800x600 font
f) TWBT always on testing turning it off, but i think i remember it not changing a thing.
I'd appreciate it if you could test without TWBT and test with just the 800x600 font (i.e. set everything to use the 800x600 font, or maybe just all the same font - no separate text/map tiles). The potential issue with square tiles is that they take up more space than rectangular tiles, so fewer of them can fit on the screen. This could cause issues because the "20th tile from the top" could be close to the bottom of the screen in the map view, but not at all close in the menu view, if that makes sense.
It's also possible that TWBT is interfering with mousequery even when the tilesets are all the same size, which is why I suggest disabling it entirely too.
so with render mode "standard" and curses 800x600 it works.
now how do i get it working with TWBT and Meph's?
i mean if it works perfectly fine with a 16x16 set, why shouldn't we be able to make it work with a 32x32 too. (edit: doesn't work with twbt and 16x16 either)
is it necessary to define the scrolling border as the 20th tile or could one adjust that number to fit the tileset?
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on May 16, 2019, 02:58:59 pm
I need know size of chain.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on May 16, 2019, 06:32:35 pm
on the subject of getting guest to join the fort, it's possible with setting their civ and group ids to match the fort civ, usually another means is to retire before they leave so they permanently stay with the site on unretire, then mess with their civ and group ids so they join the fort proper mostly with gui/gm-editor.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on May 16, 2019, 10:04:22 pm
so with render mode "standard" and curses 800x600 it works.
Ok, good to know! I ought to be able to figure out why it's not working now.
Quote
now how do i get it working with TWBT and Meph's?
i mean if it works perfectly fine with a 16x16 set, why shouldn't we be able to make it work with a 32x32 too. (edit: doesn't work with twbt and 16x16 either)
is it necessary to define the scrolling border as the 20th tile or could one adjust that number to fit the tileset?
The "20" was just an example of how the number of rows in different parts of the screen can be different with TWBT; that number doesn't actually appear anywhere in mousequery.

Edit: I think I see a reason why it wouldn't behave properly with TWBT enabled. I want to make sure my fix doesn't break non-TWBT installs; then I'll put up a plugin for you to try.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on May 16, 2019, 11:16:40 pm
You can grab a build of mousequery from my PR (https://github.com/DFHack/dfhack/pull/1440) at https://files.dfhack.org/pr1440-1/dfhack-0.44.12-r2-pr1440-1-Linux-64-gcc-7/hack/plugins/ (for 64-bit Linux, GCC 7). Let me know if it fixes the issue.
If anyone wants a different build I can put it up there too.
Title: Re: DFHack 0.44.12-r2
Post by: Pvt. Pirate on May 17, 2019, 01:32:27 am
You can grab a build of mousequery from my PR (https://github.com/DFHack/dfhack/pull/1440) at https://files.dfhack.org/pr1440-1/dfhack-0.44.12-r2-pr1440-1-Linux-64-gcc-7/hack/plugins/ (for 64-bit Linux, GCC 7). Let me know if it fixes the issue.
If anyone wants a different build I can put it up there too.
thanks :) trying it.

IT WOOORKS! :D

Thank you again :)
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on May 17, 2019, 02:07:06 am
I NEED KNOW SIZE OF CHAIN!
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on May 17, 2019, 07:35:47 am

IT WOOORKS! :D
Would you mind testing with smaller map tiles than text tiles (zooming out in the map view should do the trick). I'm not sure how it'll handle that case.

I NEED KNOW SIZE OF CHAIN!
I'm not quite sure what you're looking for or why you need it. Can you explain what you need it for?

My understanding is that sizes of objects aren't necessarily fixed, although maybe chains are all the same size. If they have a size, it should be tracked somewhere, so looking for it through DFHack should be possible (I doubt anyone can tell you off the top of their head).
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on May 17, 2019, 09:00:56 am

IT WOOORKS! :D
Would you mind testing with smaller map tiles than text tiles (zooming out in the map view should do the trick). I'm not sure how it'll handle that case.

I NEED KNOW SIZE OF CHAIN!
I'm not quite sure what you're looking for or why you need it. Can you explain what you need it for?

My understanding is that sizes of objects aren't necessarily fixed, although maybe chains are all the same size. If they have a size, it should be tracked somewhere, so looking for it through DFHack should be possible (I doubt anyone can tell you off the top of their head).
I need chain size for weapon made from one trap component and one chain. I know trap component size, but not know chain size.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on May 17, 2019, 11:19:11 am

I NEED KNOW SIZE OF CHAIN!
I'm not quite sure what you're looking for or why you need it. Can you explain what you need it for?

My understanding is that sizes of objects aren't necessarily fixed, although maybe chains are all the same size. If they have a size, it should be tracked somewhere, so looking for it through DFHack should be possible (I doubt anyone can tell you off the top of their head).
I need chain size for weapon made from one trap component and one chain. I know trap component size, but not know chain size.

There are nicer ways to ask. As far as I can tell chains don't have a size, at least not in the traditional sense (they have no item subtype so there is no [SIZE] token. However, if we look at a trap component made of iron and a chain made of iron and compare their weight we can guess a size. An enormous iron corkscrew weighs 12.56 and has a size of 160, an iron chain has a weight of 39.25, therefore, if SIZE is a unit of volume, the chain would have a size of 500. As a comparison, an iron two-handed sword has a weight of 7.65, which would be a SIZE of 97.45, compared to it's listed size of 90. So obviously it's not exact, and for some reason it's huge, but that's the closest you can get. Of course you could also just use the size of whip as an approximation for a weapon chain, since a weapon made with a chain will probably cut off some of the chain anyway.
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on May 17, 2019, 11:56:33 am

I NEED KNOW SIZE OF CHAIN!
I'm not quite sure what you're looking for or why you need it. Can you explain what you need it for?

My understanding is that sizes of objects aren't necessarily fixed, although maybe chains are all the same size. If they have a size, it should be tracked somewhere, so looking for it through DFHack should be possible (I doubt anyone can tell you off the top of their head).
I need chain size for weapon made from one trap component and one chain. I know trap component size, but not know chain size.

There are nicer ways to ask. As far as I can tell chains don't have a size, at least not in the traditional sense (they have no item subtype so there is no [SIZE] token. However, if we look at a trap component made of iron and a chain made of iron and compare their weight we can guess a size. An enormous iron corkscrew weighs 12.56 and has a size of 160, an iron chain has a weight of 39.25, therefore, if SIZE is a unit of volume, the chain would have a size of 500. As a comparison, an iron two-handed sword has a weight of 7.65, which would be a SIZE of 97.45, compared to it's listed size of 90. So obviously it's not exact, and for some reason it's huge, but that's the closest you can get. Of course you could also just use the size of whip as an approximation for a weapon chain, since a weapon made with a chain will probably cut off some of the chain anyway.
This will be ogre's weapon, so chain may be long.
Title: Re: DFHack 0.44.12-r2
Post by: Rose on May 17, 2019, 12:33:20 pm
A chain inside a well can stretch from the surface down to the depths of hell, potentially, so....
Title: Re: DFHack 0.44.12-r2
Post by: Roses on May 17, 2019, 01:40:47 pm
A chain inside a well can stretch from the surface down to the depths of hell, potentially, so....

Very true. Still I was surprised it was so heavy when I looked. Granted the weight -> size comparison/ratios don't really work, because there are several items with 0 weight and non-zero size. It also seems to be off by about 10% for all of the items I compared with weights and sizes, so there is probably some other factors that go into the calculation of weight.
Title: Re: DFHack 0.44.12-r2
Post by: Pvt. Pirate on May 17, 2019, 01:50:00 pm

IT WOOORKS! :D
Would you mind testing with smaller map tiles than text tiles (zooming out in the map view should do the trick). I'm not sure how it'll handle that case.
i already zoomed in and out and scrolling worked fine (meph32lite+curses800x600)
i don't know what you changed axactly, but it does the trick.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on May 18, 2019, 01:25:48 pm
i already zoomed in and out and scrolling worked fine (meph32lite+curses800x600)
i don't know what you changed axactly, but it does the trick.
Basically, mousequery was always checking the cursor position against the window size in text tiles to determine when to scroll the map. TWBT modifies the cursor position that gets reported when you're hovering over the map so that it reports map tile coordinates instead. This meant that when the map tiles are larger than the text tiles, the cursor position in the lower/right areas of the map would never get large enough to trigger mousequery's scrolling. Thanks for the help diagnosing it - the fix is merged now, so it'll be in the next DFHack release.
Title: Re: DFHack 0.44.12-r2
Post by: Pvt. Pirate on May 18, 2019, 01:46:30 pm
i already zoomed in and out and scrolling worked fine (meph32lite+curses800x600)
i don't know what you changed axactly, but it does the trick.
Basically, mousequery was always checking the cursor position against the window size in text tiles to determine when to scroll the map. TWBT modifies the cursor position that gets reported when you're hovering over the map so that it reports map tile coordinates instead. This meant that when the map tiles are larger than the text tiles, the cursor position in the lower/right areas of the map would never get large enough to trigger mousequery's scrolling. Thanks for the help diagnosing it - the fix is merged now, so it'll be in the next DFHack release.
i'll also tell my friend who had the same problem.
also thanks for the great explanation.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on May 28, 2019, 04:37:18 pm
poking around dwarf fortress tunnels/road constructions to see if it's possible to make new tunnel systems for adventuring. the hardest part of this is finding the tunnel that shows signs of editing happen, also feels like tunnels/roads use a different position data than the region or embark.
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on May 29, 2019, 12:17:55 pm
How make reaction for create bed? I want make beds from feather or hair and some cloth. This technically is pillow, but named bed is fine too.
Title: Re: DFHack 0.44.12-r2
Post by: FantasticDorf on May 29, 2019, 12:30:05 pm
This is the wrong place to ask, you should try [MODDING] 0.44.x GENERAL MODDING QUESTIONS THREAD - NOW IN ALLCAPS EDITION (http://www.bay12forums.com/smf/index.php?topic=168353.0) as this is for DFhack related questions using the third party scripts and all that jazz.

To answer in short here's a item list for reactions (http://dwarffortresswiki.org/index.php/DF2014:Item_token#BED), when you've got a applicable text file to add it to like furniture.txt you can simply reference material from the reagent to use into the produced bed. I forget if there's anything further to it materially defining.
Title: Re: DFHack 0.44.12-r2
Post by: Pvt. Pirate on June 01, 2019, 04:47:06 am
can we have a plugin that causes monthly saves? like triggering quicksave at the beginning of each month (except those where seasonal save does)?
the seasonal autosaves aren't enough when the game crashes too often and too unpredictable and i tend to forget to quicksave often enough.
Title: Re: DFHack 0.44.12-r2
Post by: Bumber on June 01, 2019, 06:44:05 am
can we have a plugin that causes monthly saves? like triggering quicksave at the beginning of each month (except those where seasonal save does)?
the seasonal autosaves aren't enough when the game crashes too often and too unpredictable and i tend to forget to quicksave often enough.

Maybe something like this added to the "onLoad" init file would suffice:
Code: [Select]
repeat -name monthly_save -time 1 -timeUnits months -command [ quicksave ]It wouldn't skip seasonal saves, though. (Not sure if that causes a problem.)

Or if you want it to save every 10 mins, even while paused, this might work:
Code: [Select]
repeat -name ten_min_save -time 60000 -timeUnits frames -command [ quicksave ]Assuming a max FPS cap of 100. Not sure what happens if you're in a menu when it activates. Maybe it just fails.
You could cancel it while going AFK using "repeat -cancel ten_min_save". You'd have to re-enter the main command to reactivate it, or save&quit then reload.

If you want anything more complex, you'd need a script/plugin.
Title: Re: DFHack 0.44.12-r2
Post by: Pvt. Pirate on June 01, 2019, 07:10:33 am
thanks :) i'll see if that works and afaik it shouldn't make it crash - only freeze for as long as it takes to save.
Title: Re: DFHack 0.44.12-r2
Post by: Bumber on June 01, 2019, 07:29:45 am
Hmm... It looks like "-timeUnits months" just results in a month's worth of ticks, not at the beginning of each month. This results in a save every 28 dwarf days after the save was loaded, which is not exactly what was intended. Might as well just use an arbitrary number of days, adjusted based on how close to FPS death your fort is. E.g, every 10 days if you've dropped to 30 FPS.
Title: Re: DFHack 0.44.12-r2
Post by: Pvt. Pirate on June 01, 2019, 07:49:54 am
that's already fine - having to redo all the stuff done in a month is already much better than redoing a whole season.
Title: Re: DFHack 0.44.12-r2
Post by: Putnam on June 02, 2019, 05:02:31 pm
I have never once in my life managed to successfully compile DFHack. Right now I can't even get past the CMake step:

Code: [Select]
Project "C:\Users\Putnam\Documents\Projects\C++\dfhack\build\win64\VC2015\CMakeFiles\3.14.0\VCTargetsPath.vcxproj" on node 1 (default targets).
    C:\Users\Putnam\Documents\Projects\C++\dfhack\build\win64\VC2015\CMakeFiles\3.14.0\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
    Done Building Project "C:\Users\Putnam\Documents\Projects\C++\dfhack\build\win64\VC2015\CMakeFiles\3.14.0\VCTargetsPath.vcxproj" (default targets) -- FAILED.

    Build FAILED.

    "C:\Users\Putnam\Documents\Projects\C++\dfhack\build\win64\VC2015\CMakeFiles\3.14.0\VCTargetsPath.vcxproj" (default target) (1) ->
      C:\Users\Putnam\Documents\Projects\C++\dfhack\build\win64\VC2015\CMakeFiles\3.14.0\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

        0 Warning(s)
        1 Error(s)

    Time Elapsed 00:00:00.15

Can't find anything about these parts, based on my complete failure to ever compile a C++ project in my entire life I'd guess it's cause I somehow never manage to install MSVC correctly (because I have two hard drives? Because I'm a fuckup? Could be anything). Googling it reveals that there's some ways to fix it by explicitly including stuff in the command line, but I don't really like doing hammer-swing break-shit changes like that for my own personal use to git projects.
Title: Re: DFHack 0.44.12-r2
Post by: Pvt. Pirate on June 03, 2019, 06:30:18 am
can we have a plugin that causes monthly saves? like triggering quicksave at the beginning of each month (except those where seasonal save does)?
the seasonal autosaves aren't enough when the game crashes too often and too unpredictable and i tend to forget to quicksave often enough.

Maybe something like this added to the "onLoad" init file would suffice:
Code: [Select]
repeat -name monthly_save -time 1 -timeUnits months -command [ quicksave ]It wouldn't skip seasonal saves, though. (Not sure if that causes a problem.)

Or if you want it to save every 10 mins, even while paused, this might work:
Code: [Select]
repeat -name ten_min_save -time 60000 -timeUnits frames -command [ quicksave ]Assuming a max FPS cap of 100. Not sure what happens if you're in a menu when it activates. Maybe it just fails.
You could cancel it while going AFK using "repeat -cancel ten_min_save". You'd have to re-enter the main command to reactivate it, or save&quit then reload.

If you want anything more complex, you'd need a script/plugin.
using your first script really helps alot! it saves on every 15th day of the month (can't interfere with seasonal saves) and that somehow seems to make fps smoother after saving.
Title: Re: DFHack 0.44.12-r2
Post by: ragundo on June 03, 2019, 12:38:48 pm
I have never once in my life managed to successfully compile DFHack. Right now I can't even get past the CMake step:

Code: [Select]
Project "C:\Users\Putnam\Documents\Projects\C++\dfhack\build\win64\VC2015\CMakeFiles\3.14.0\VCTargetsPath.vcxproj" on node 1 (default targets).
    C:\Users\Putnam\Documents\Projects\C++\dfhack\build\win64\VC2015\CMakeFiles\3.14.0\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
    Done Building Project "C:\Users\Putnam\Documents\Projects\C++\dfhack\build\win64\VC2015\CMakeFiles\3.14.0\VCTargetsPath.vcxproj" (default targets) -- FAILED.

    Build FAILED.

    "C:\Users\Putnam\Documents\Projects\C++\dfhack\build\win64\VC2015\CMakeFiles\3.14.0\VCTargetsPath.vcxproj" (default target) (1) ->
      C:\Users\Putnam\Documents\Projects\C++\dfhack\build\win64\VC2015\CMakeFiles\3.14.0\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

        0 Warning(s)
        1 Error(s)

    Time Elapsed 00:00:00.15

Can't find anything about these parts, based on my complete failure to ever compile a C++ project in my entire life I'd guess it's cause I somehow never manage to install MSVC correctly (because I have two hard drives? Because I'm a fuckup? Could be anything). Googling it reveals that there's some ways to fix it by explicitly including stuff in the command line, but I don't really like doing hammer-swing break-shit changes like that for my own personal use to git projects.

Yeah, compiling DFHack in Windows is not as easy as in Linux.

You need to have installed MSVC, git, perl, and cmake as the instructions in dfhack.readthedocs.org says



Hope this helps people if they want to compile DFHack by themselves and not wait for the LNP to be updated.

Also, in IRC #dfhack channel we can provide more specific help (for compiling in Linux and  MacOS)

Greetings
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on June 04, 2019, 12:02:20 pm
How make dwarf and other sapient corpses butcherable and usable?
Title: Re: DFHack 0.44.12-r2
Post by: FantasticDorf on June 04, 2019, 01:07:28 pm
How make dwarf and other sapient corpses butcherable and usable?

DFhack scripts like this one can automate the process (http://www.bay12forums.com/smf/index.php?topic=165414.0), there's some more discussion and installation instructions i described to someone else on this thread (http://www.bay12forums.com/smf/index.php?topic=168353.msg7966033#msg7966033)
Title: Re: DFHack 0.44.12-r2
Post by: Prismatic on June 05, 2019, 07:02:11 am
Another basic question:

What is the difference between the following methods? They appear to do the same thing, but is either preferable over the other?

Code: [Select]
for k,unit in ipairs(df.global.world.units.all) do
  unit.name.first_name = 'Testing'
end
Code: [Select]
for k = 0,#df.global.world.units.all-1 do
  local unit = df.global.world.units.all[k]
  unit.name.first_name = 'Testing'
end

Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on June 05, 2019, 07:17:01 am
Yes, both scripts achieve the same thing. The first one saves some typing, as well as removing the need to keep track of whether the index uses the C convention (i.e. starting at 0) or the Lua one (defaulting to start at 1).
Title: Re: DFHack 0.44.12-r2
Post by: Clément on June 20, 2019, 01:09:56 pm
I'd like to know if my Qt experiment works on macOS (I am worried by this (https://bugreports.qt.io/browse/QTBUG-7393)). But, since I cannot use macOS myself, I need help from a macOS user who knows how to compile DFHack plugins.

Download and compile the plugin from here (https://github.com/cvuchener/dfhack-qt/tree/master). You will need to install Qt (homebrew can help with that) and pass its installation directory to cmake with -DCMAKE_PREFIX_PATH (-DCMAKE_PREFIX_PATH=/usr/local/opt/qt for homebrew installation).

Try enabling the plugin ("enable qapplication"), then try commands like "qt-info" or "qt-log". Please tell me if windows appear and if DF survives it. Also check the content of "qt_log.txt" in DF directory (or the content of the log window if it works).

I finally found a macos vm I could work with and I can confirm that running the Qt gui loop off the main thread is an issue (Qt does not initialize correctly and windows don't show). :(
Title: Re: DFHack 0.44.12-r2
Post by: Schmaven on June 20, 2019, 05:44:48 pm
I hope that I'm just missing something, but I believe this to be true: Running "reveal" then saving and exiting the game does not allow un-revealing the map when that save is re-opened.
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on June 20, 2019, 08:38:02 pm
Can DFhack automatically forbid fertile eggs? I need this for test egg-laying civ.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on June 20, 2019, 11:00:14 pm
I hope that I'm just missing something, but I believe this to be true: Running "reveal" then saving and exiting the game does not allow un-revealing the map when that save is re-opened.
That is correct. The previous state is only saved in memory. "revflood" should be helpful in reproducing the unrevealed state for the most part, though.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on June 21, 2019, 04:27:46 am
Can DFhack automatically forbid fertile eggs? I need this for test egg-laying civ.
You can write a DFHack Lua script to forbid fertile eggs, but it would probably cost you in FPS, because I don't think there's any trigger for the laying of eggs, so you'd have to use a script that makes a callback at fixed intervals. If those intervals are too long, eggs may be laid and collected in between script callbacks.

Also note that egg laying creatures that need to eat are tricky to breed, as they'll suffer from dehydration and starvation while sitting on their eggs (Elk Birds, for instance, need to graze). I'm not sure if that problem affects citizens, though, as the "give food/water" mechanism MIGHT kick in. With Elk Birds I've hauled the female off to a cage where she was promptly food and then led her back to the pasture, The eggs hatched, eventually.
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on June 21, 2019, 08:17:25 am
A thought, since I'm posting anyway: Alongside with the fixing of fat dwarves and buckets, maybe the script in this post (http://www.bay12forums.com/smf/index.php?topic=167804.msg7983376#msg7983376) would also fit in in fps fixes folder? (Though it could use replacing tabs with spaces and comment for documentation. And maybe making the repeat internal.)

@PatrikLundell: JSYK, iirc they'll also feed ones on a chain. Install one next to a nestbox, maybe?

@DerMeister: Here's quick and dirty one that forbids new fertilized eggs every tick.

repeat -name forbid-eggs -time 1 -command [ ":lua eggtable = eggtable or {} for index, egg in ipairs(df.global.world.items.other.EGG) do if not eggtable[egg.id] then if egg.egg_flags.fertile then egg.flags.forbid = true end eggtable[egg.id]=true end end" ]
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on June 21, 2019, 08:29:33 am
Yes, I've used a chain, and I think that worked. However, unless they've been sentenced, you can't chain up citizens...
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on June 21, 2019, 10:10:22 am
Unless one uses Script to restrain creatures (http://www.bay12forums.com/smf/index.php?topic=161795.msg7287486#msg7287486).

Mind, iirc I've seen haulers bring water to thirsty but free-walking miners, so this might be more of a matter of difference for civ culture.
Title: Re: DFHack 0.44.12-r2
Post by: Aelwen on June 29, 2019, 08:01:28 am
Is there a way to edit, modify appearance with DFHACK? I mean those descritions: "He is tall/short. His hair is curvy/straight" and so on.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on June 29, 2019, 08:32:11 am
I believe all of that information has been mapped, which means it should be possible to use gui/gm-editor to modify it. I don't know if there are any scripts specifically for it, though.
Title: Re: DFHack 0.44.12-r2
Post by: Aelwen on June 29, 2019, 10:53:23 am
I believe all of that information has been mapped, which means it should be possible to use gui/gm-editor to modify it. I don't know if there are any scripts specifically for it, though.
I don't know where to find it.

I use gm-editor, find appearance - bp-modifier and then I see numbers.
0 98
1 95
2 92...


What do they mean?
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on June 29, 2019, 01:43:10 pm
I believe all of that information has been mapped, which means it should be possible to use gui/gm-editor to modify it. I don't know if there are any scripts specifically for it, though.
I don't know where to find it.

I use gm-editor, find appearance - bp-modifier and then I see numbers.
0 98
1 95
2 92...


What do they mean?
It's probably related to the body parts defined by the raws in some way. I haven't mucked around in this area so I don't know any details.
There's something called Dwarf Portrait (included in the LNP) that seems to make sense of some related info, so I guess the code of that might provide some clues.
Title: Re: DFHack 0.44.12-r2
Post by: Rose on June 29, 2019, 02:19:51 pm
In order to make sense of that list, you need to also read the associated creature raw, which has some tables setting what the numbers do.
Title: Re: DFHack 0.44.12-r2
Post by: Atkana on June 30, 2019, 02:20:50 am
Is there a way to edit, modify appearance with DFHACK? I mean those descritions: "He is tall/short. His hair is curvy/straight" and so on.
I made a modification to gui/gm-unit a while back for editing appearances which can be found in my DF dumping repo (https://github.com/Atkana/Dwarf-Fortress-Mods#gm-newnit) :p
Title: Re: DFHack 0.44.12-r2
Post by: Prismatic on July 03, 2019, 01:14:39 pm
I'm trying to write a script which at some point obtains and identifies the current viewscreen (the inbuilt kind, not screens produced by DFHack) using dfhack.gui.getCurViewscreen(). I now want the script to wait for the player to close this particular viewscreen before running a function. What I can't figure out is how to make the function run when the viewscreen is closed. Any ideas for how to go about this?
Title: Re: DFHack 0.44.12-r2
Post by: Putnam on July 03, 2019, 05:26:25 pm
Using a variable within the script combined with the SC_VIEWSCREEN_CHANGED argument to the dfhack.onStateChange callback
Title: Re: DFHack 0.44.12-r2
Post by: Prismatic on July 04, 2019, 02:06:17 am
Using a variable within the script combined with the SC_VIEWSCREEN_CHANGED argument to the dfhack.onStateChange callback

That worked perfectly! Thanks!
Title: Re: DFHack 0.44.12-r2
Post by: nimbus25 on July 04, 2019, 07:21:55 pm
Is there any way to convert a tile into a specific soil type? I embarked in a super specific location thinking it would have sand but apparently the "sand" was just sandy loam and completely worthless.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on July 05, 2019, 04:20:40 am
Is there any way to convert a tile into a specific soil type? I embarked in a super specific location thinking it would have sand but apparently the "sand" was just sandy loam and completely worthless.
Experimenting, it turns out to be surprisingly easy to do with the Biome Manipulator http://www.bay12forums.com/smf/index.php?topic=164658.0 (http://www.bay12forums.com/smf/index.php?topic=164658.0). Start the fortress, invoke the Biome Manipulator and change ("morph") the offending geo biome layer from sandy loam to the kind of sand you want. Note that you should probably save and reload DF to make sure DF does recalculate things properly, and I'd also make a backup of the save before manipulating it to have something to return back to if things go horribly wrong. Also note that your embark may have multiple (geo) biomes or the geo biome of a neighboring world tile, so you may need to search around the neighborhood to find the right geo biome to manipulate.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on July 05, 2019, 07:11:04 am
The built-in "changelayer" command might also work for this. "tiletypes" contains some support for changing single vein tiles, I think, but I'm not sure if it can change individual soil tiles.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on July 05, 2019, 08:11:56 am
I don't think you can change single tiles, because it seems the tile itself doesn't specify the material, but rather references the layer  that does that (and, I presume, vein and inclusion to use, when appropriate). Thus, it ought to be possible to swap a single tile to belong to a different layer that's still present in the geo biome, but not something that's not present.

However, given its name (I didn't know about it, and haven't looked at what it does), it sounds like "changelayer" would be the easiest tool to use in this situation.
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on July 05, 2019, 09:38:17 am
Though builder (http://www.bay12forums.com/smf/index.php?topic=167487.0) doesn't place soils in drop-down box, you can place individual tiles with it. However, the lack of placement may be very well justified by how sand mineral walls are not acceptable options for sand collection, and changing tiletype to soil changes material to layer material.

Haven't checked whether soil mineral walls are acceptable for plant growth, but I suspect not.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on July 06, 2019, 10:05:45 am
Though builder (http://www.bay12forums.com/smf/index.php?topic=167487.0) doesn't place soils in drop-down box, you can place individual tiles with it. However, the lack of placement may be very well justified by how sand mineral walls are not acceptable options for sand collection, and changing tiletype to soil changes material to layer material.

Haven't checked whether soil mineral walls are acceptable for plant growth, but I suspect not.
I've taken a look at "builder", and it seems it creates walls from veins/inclusions, and that DF doesn't actually reference the veins and inclusions in the geo biome for the actual data, but rather creates a local list for the tile block to draw from (and presumably this list was drawn from the geo biome when DF generated the block). There's nothing except script selection logic that blocks the creations of soil "vein" walls, and it was possible to create a "milk of lime" vein floor with the script. Changing a floor tile to be a red sand vein floor (after removing the script part that blocks selection of soils) results in a floor tile that's not suitable for sand collection nor farm plot placement, presumably because it's not actually a natural floor.

Thus, it seems you can only create sand that can be collected by changing a layer material in the geo biome.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on July 06, 2019, 12:15:44 pm
I don't think you can change single tiles, because it seems the tile itself doesn't specify the material, but rather references the layer  that does that (and, I presume, vein and inclusion to use, when appropriate).
This is correct. The "tiletypes" feature I was thinking of creates new veins on the fly to resolve this (but I don't know if it works for soil).
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on July 06, 2019, 04:18:30 pm
I don't think you can change single tiles, because it seems the tile itself doesn't specify the material, but rather references the layer  that does that (and, I presume, vein and inclusion to use, when appropriate).
This is correct. The "tiletypes" feature I was thinking of creates new veins on the fly to resolve this (but I don't know if it works for soil).
I was wrong about veins and inclusions, as indicated by my previous post, as they're local to the map block, allowing for the creation of new ones (as you said). Given my brief fiddling with "builder", I see no reason why you can't create veins of soil, when you can create them out of milk of lime and refined metals: it ought to work with any inorganic material. However, soil vein floors didn't work for farming or sand extraction, as I mentioned, so there's little reason to do so. I'd expect "grass" won't grow of such soil either, although I didn't attempt to test that (the test bed save I used doesn't have any anywhere, anyway).
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on July 10, 2019, 06:59:09 pm
A test build with a fix (hopefully) for a stonesense wagon-related crash is up at https://github.com/DFHack/stonesense/issues/54#issuecomment-510273737 if anyone here is interested in testing that.
Title: Re: DFHack 0.44.12-r2
Post by: VislarRn on July 12, 2019, 10:06:49 am
A test build with a fix (hopefully) for a stonesense wagon-related crash is up at https://github.com/DFHack/stonesense/issues/54#issuecomment-510273737 if anyone here is interested in testing that.

Tried it yesterday. No more wagon crashes from my side anymore.   :)
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on July 14, 2019, 02:56:53 pm
Hey, couldn't find it on my own, but asking JIC, does anybody know where is stored/how do I get the minimum floorspace for a dance?

(Pondering what's the largest minimum floorspace for all dances in fort in my given world.)
Title: Re: DFHack 0.44.12-r2
Post by: ibanix on July 16, 2019, 03:44:37 pm
Is anyone else using the 'emigration' script?  (https://dfhack.readthedocs.io/en/stable/docs/_auto/base.html?highlight=emigration#emigration)

Everytime I enable this, half my dwarves leave, even with low stress levels.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on July 17, 2019, 06:50:19 am
Spoiler: egg splicing script (click to show/hide)
well here's a script for implanting an adventurer's genes into an egg for reasons I can't grasp be warn it's probably for the best to change the mother genes to father genes if you don't want the game to crash trying to grasp the horror's true form
oh and probably should poke around their genes after birth as some times their colors could hit the 1000 to 6000 range which I guess is probably why the game crashes on looking at them.
Title: Re: DFHack 0.44.12-r2
Post by: ragundo on July 18, 2019, 02:44:08 pm
Spoiler: egg splicing script (click to show/hide)
well here's a script for implanting an adventurer's genes into an egg for reasons I can't grasp be warn it's probably for the best to change the mother genes to father genes if you don't want the game to crash trying to grasp the horror's true form
oh and probably should poke around their genes after birth as some times their colors could hit the 1000 to 6000 range which I guess is probably why the game crashes on looking at them.

Hmmm.
Shouldn't you check that the item type that Invcheck return is a item_egg?. 

My unit has a inventory item of type 1, but is a item_weapon, not a item_egg, so no mother_genes, etc.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on July 21, 2019, 07:53:11 am
Spoiler: egg splicing script (click to show/hide)
well here's a script for implanting an adventurer's genes into an egg for reasons I can't grasp be warn it's probably for the best to change the mother genes to father genes if you don't want the game to crash trying to grasp the horror's true form
oh and probably should poke around their genes after birth as some times their colors could hit the 1000 to 6000 range which I guess is probably why the game crashes on looking at them.

Hmmm.
Shouldn't you check that the item type that Invcheck return is a item_egg?. 

My unit has a inventory item of type 1, but is a item_weapon, not a item_egg, so no mother_genes, etc.
oh yeah forgot this script was made for adv mode, and that the person is holding no items but the egg itself, this probably wouldn't work universally in fort mode either.
Title: Re: DFHack 0.44.12-r2
Post by: Ulfarr on July 24, 2019, 02:48:58 am
Do the "migrants-now" and "force migrants" create said migrants from thin air (like the starting dwarves) or do they pull them from the already existing population?
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on July 24, 2019, 07:17:09 am
They use DF's migrant logic, which I believe does the latter most of the time, although that also means that they can do nothing at all if you've had too many migrants recently, among other things.
Title: Re: DFHack 0.44.12-r2
Post by: Atkana on July 30, 2019, 07:54:52 am
While digging into modtools/create-unit for one of my scripts (thank you whoever made those createFigure and createNemesis functions, you saved me a lot of time), I noticed a slight error but I'm too inept to work out how to have two separate pulls on the go at the same time so I'll just mention it here :P

For a historical figure, their unit_id2 is the ID for their nemesis. During createFigure, the created figure is instead being assigned the unit's id a second time. The differences between unit_id and unit_id2 is easy to miss because I think a bunch of the worldgen figures(?) happen to have unit and nemesis IDs that are the same value.

I think the only edits that need to be are:
... or do something better than that. As far as I can tell, a historical figure that's attached to a unit always needs a nemesis, so it's fine to assume that createNemesis will always be used.

Edit: In the process of acquiring knowledge on how companions work that'll probably be invalidated come next update when that system is possibly getting overhauled, I've worked out a couple of anon values, but couldn't find/work out which file I was supposed to edit.
For a histfig_hf_link_companionst (which is a histfig_hf_link stored in a historical_figure's histfig_links), the value of anon_1 is the ID of the agreement that was made between the player and the companion to have them join the adventurer (see df.global.world.agreements), and the value of anon_2 is the ID of the party involved in that agreement that the historical figure that this histfig link is on appears in (not the party that the listed target_hf appears in)... if that makes any sense, I can try to elaborate a bit more if not :P

Edit Edit: I also figured out that unk_1, unk_2, and unk_3 in df.global.ui_advmode are the last x, y, and z coordinates of the adventurer's army (set/updated when the travel screen is opened, or you move on the travel screen)... then I discovered this was already known because it was used in questport Q.Q These style of coordinates are also anon_1, anon_2, and anon_3 in agreements, but I'm not sure if it represents the army position of one of the parties, or whether it just represents where the agreement took place.

Does anybody know how the army position style of coords are calculated? I'm fake generating some agreements and so need to know how to make the coords, otherwise I'll just slap in the adventurer's last army coords and call it good enough :P
Title: Re: DFHack 0.44.12-r2
Post by: strainer on August 03, 2019, 10:21:14 am
That's good research on the Anons Atkana.

In the histfig structure, is it the case that unit_id2 should be set to the units nemesis_id ?
Its my understanding that the nemesis record normally just points to the unit and units histfig record rather than to a different unit.

Those scripts are maintained in their own little repo here: https://github.com/DFHack/scripts, and get imported to the central dfhack repo with the "git submodule update" commands. If you open a file in it on github and make a small edit, github automatically forks the repo so you can make a pull request quickly. Seems like it can all be done conviently online when logged into github account so that shouldnt have to complicate your local repos state.
Title: Re: DFHack 0.44.12-r2
Post by: Clément on August 03, 2019, 02:35:14 pm
When I was reversing some code for assigning noble position, I remember that nemesis records were looked up by comparing historical_figure's unit_id2 with nemesis_record's id (not unit_id).
Title: Re: DFHack 0.44.12-r2
Post by: strainer on August 03, 2019, 03:30:37 pm
Thanks - I just had to doublecheck. That nemesis structure is an odd thing, maybe it was designed once to allow units to pretend to be an other historical figure  :-\
Title: Re: DFHack 0.44.12-r2
Post by: Atomic Chicken on August 04, 2019, 12:31:26 am
I can't check anything at the moment, but I seem to remember noticing that reanimated undead histfigs had a unit_id2 value corresponding to what might have been the unit ID or the nemesis ID of the unit from which they were produced (reanimation involves the creation of entirely new units so as to support the zombification of individual body parts).

Edit Edit: I also figured out that unk_1, unk_2, and unk_3 in df.global.ui_advmode are the last x, y, and z coordinates of the adventurer's army (set/updated when the travel screen is opened, or you move on the travel screen)... then I discovered this was already known because it was used in questport Q.Q

These were identified and pushed to df-structures a couple of months ago, alongside some other stuff in ui_advmode, but a new DFHack version has yet to be released. I've found that it's always a good idea to check the latest structures on Github when dealing with supposed unknowns so as to avoid needless duplication of effort.
Title: Re: DFHack 0.44.12-r2
Post by: Clément on August 04, 2019, 03:45:17 am
What are the nemesis records used for? In the case I've seen it was mostly redundant information.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on August 08, 2019, 11:49:01 am
Nemesis records are mostly used to retain a list of unit, historical figure and other data based on the unit. personally use nemesis to track down the unit's historical figure data as playing around with putnam's dbz mod kinda makes aligning that stuff hell as I think they use the historical figure pool for Dfhack data and script storage so like there just a big chunk of historical figures that are just dummy data and the result just causes a unit HF id number to be off if someone trys to search for that number in the pool of historical figures


so far trying to figure out how sites equip inhabitants with gear, and wondering it tied to items in the mead hall or not. I ended up getting 1 inhabitant created unit to have a weapon but couldn't seem to recreate the process again.


edit: false alarm that one inhabitant ended up being a night troll with a habit that gives them a random weapon on spawn, which uhh only seems to be just the 'any melee weapon' and not range.
Title: Re: DFHack 0.44.12-r2
Post by: darkhog on August 14, 2019, 05:14:30 pm
I want to report a bug in Dfhack (mousequery thing, to be precise). Even when I set mousequery edge disable, it still scrolls on edge, particularly after clicking on a tile and moving around. The second issue is that I have set mousequery drag right so I can rmb-drag the world (which is a better scrolling method IMO) and while painting the designations (with box mode disabled) when I scroll (using rmb-drag) so the cursor is outside the screen rgiht when I click the world with LMB the camera snaps back so the cursor is in view which led me to mining stuff I never intended to mine and other stuff.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on August 14, 2019, 06:16:22 pm
I want to report a bug in Dfhack (mousequery thing, to be precise). Even when I set mousequery edge disable, it still scrolls on edge, particularly after clicking on a tile and moving around.
Does it only scroll when you click near the edge of the screen? If so, that's probably intentional - that's how DF's cursor works when moved with the arrow keys too.
Title: Re: DFHack 0.44.12-r2
Post by: darkhog on August 14, 2019, 08:24:44 pm
No, it's enough that I move mouse after clicking, say, in the middle of the screen.
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on August 15, 2019, 12:21:47 am
Noticed I can change what dwarfmonitor's dwarfmode viewscreen widgets display by editing the dwarfmonitor.lua (in 43.03 in case it matters).

Ability to add arbitrary widgets without having to git & compile, merely by editing said file, struck me as useful (even if it is only on dwarfmode viewscreen).

The usefulness has unexpected limitation, though - it seems like neither require of dwarfmonitor nor script_environment of another script won't share the environment when I call it again from a separate :lua line, and using persistent configuration storage (after world has loaded) freezes the game (while getting/setting them by getting an exact copy by require and :lua works).

Editing json and reloading dwarfmonitor still works, though, but is there perhaps a better way to share values between the the plugin and another lua script already available?
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on August 18, 2019, 03:52:42 pm
Noticed I can change what dwarfmonitor's dwarfmode viewscreen widgets display by editing the dwarfmonitor.lua (in 43.03 in case it matters).
Do you mean dwarfmonitor.json? That's the file you're intended to edit (should be in the dfhack-config folder).

Quote
The usefulness has unexpected limitation, though - it seems like neither require of dwarfmonitor nor script_environment of another script won't share the environment when I call it again from a separate :lua line, and using persistent configuration storage (after world has loaded) freezes the game (while getting/setting them by getting an exact copy by require and :lua works).

Editing json and reloading dwarfmonitor still works, though, but is there perhaps a better way to share values between the the plugin and another lua script already available?
I believe "reload('plugins.dwarfmonitor')" in Lua will reload the config and the lua file properly (although you shouldn't have to edit the lua file ordinarily).

script_environment shouldn't work for this at all, though, so I might be confused about what you're doing exactly.
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on August 18, 2019, 10:16:47 pm
No, I mean hack/lua/plugins/dwarfmonitor.lua. (While I did notice one can use the cursor widget to display some text at some point with it, it's somewhat limited.)

I noticed dfhack.screen natives can be edited inside its render functions and work. Well, paintString at least.

I want to pass data to thus modified dwarfmonitor from another script during runtime (rather than putting all code inside dwarfmonitor before start).
Though the reload command is useful tip if that isn't possible and rewriting the dwarfmonitor.json during gameplay is the simplest way.

Issue with partial rewriting is, of course, departing from DF's "keep all in memory" paradigm, which could cause problems when dwarfmonitor gets passed something to something newly created and process is killed.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on August 20, 2019, 10:33:16 pm
No, I mean hack/lua/plugins/dwarfmonitor.lua. (While I did notice one can use the cursor widget to display some text at some point with it, it's somewhat limited.)
The cursor widget should always be displaying text at the same point, but you can choose where various widgets display by editing dwarfmonitor.json. I'm kind of confused - what exactly are you trying to do by editing the lua file?

Quote
I noticed dfhack.screen natives can be edited inside its render functions and work. Well, paintString at least.
Editing things in dfhack.screen is generally not a good idea because it will affect all scripts.

Quote
I want to pass data to thus modified dwarfmonitor from another script during runtime (rather than putting all code inside dwarfmonitor before start).
Though the reload command is useful tip if that isn't possible and rewriting the dwarfmonitor.json during gameplay is the simplest way.

Issue with partial rewriting is, of course, departing from DF's "keep all in memory" paradigm, which could cause problems when dwarfmonitor gets passed something to something newly created and process is killed.
What data are you trying to pass to dwarfmonitor?

It should be fairly straightforward to add a dwarfmonitor widget, by the way, and the plugin is set up so that additional widgets can be added to dwarfmonitor.json easily enough. Is that what you're trying to do?
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on August 21, 2019, 03:37:51 am
Ah, the "its" in the context of second quote was dwarfmonitor('s renders), not dfhack.screen's. Additional widgets is pretty much right (editing just json will not display invalid widget types, so have to edit the .lua file - but not like one can include code in .json by its lonesome anyway.)

Ideally, I'd want to pass lua table(s), but any data might work - the issue is passing data without modifying files on disk, so that if DF is killed the next start will begin in same state as previous (which could be accomplished via cleanup on startup), and so that one doesn't need to worry about excessive disk access (which couldn't be accomplished when passing data through .json or the like).
Title: Re: DFHack 0.44.12-r2
Post by: Warmist on August 26, 2019, 09:48:33 am
Playing around with creating armies (for adventure mode stuff):  here if anyone is interested  (https://github.com/warmist/wm_scripts/blob/master/summon-army.lua). Has anyone tried doing migrants/invaders on new army mechanics?
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on August 26, 2019, 09:00:10 pm
oh hey warmist was playing around with this stuff for a while but usually end up with uhh fort mode recruitment options of adding units to an army that on return brings back in a new historical unit. but I think the current update broke the army mission data so I can't change that while the units are out.
so far messing around with camp site data and inhabitants and pondering how to get the inhabitants in gear like say start with crossbows?
was looking forward to cracking the Raid option in fort mode and converting that for adventure mode by being able to send out companions on missions.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on August 26, 2019, 10:30:25 pm
Ah, the "its" in the context of second quote was dwarfmonitor('s renders), not dfhack.screen's. Additional widgets is pretty much right (editing just json will not display invalid widget types, so have to edit the .lua file - but not like one can include code in .json by its lonesome anyway.)
(I thought you meant you were editing dfhack.screen itself, not really from somewhere in particular)

Yeah, you have to add them in the Lua file. I think I wrote most of that system, and it should be extensible, but let me know if you have questions. Once you've implemented a widget type, you should be able to use that type in the JSON file.

Quote
Ideally, I'd want to pass lua table(s), but any data might work - the issue is passing data without modifying files on disk, so that if DF is killed the next start will begin in same state as previous (which could be accomplished via cleanup on startup), and so that one doesn't need to worry about excessive disk access (which couldn't be accomplished when passing data through .json or the like).
I'm still kind of confused about what exactly you're doing. Can you explain? Are you trying to display some data that a separate script is generating in a widget? Is there a reason you can't do that in the widget itself? (Passing it in memory is definitely better than going through disk - at the very least, reqscript() / script_environment() should work from dwarfmonitor.lua.)
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on August 27, 2019, 06:27:35 pm
"Are you trying to display some data that a separate script is generating in a widget?" Yes, exactly.

Tried script_environment on a dummy script (also tried reqscript now; same result) and dwarfmoniter alike, adding/editing variables in during runtime, didn't work even with disable-enable or by editing variables from console before enabling dwarfmonitor for first time in current process. It looks like the environment dwarfmonitor generates and the environment console generates are different. (Adding something to BASE_G obviously failed too; wildly speculating might be that they're on separate C lua states).


As to why separate, there are couple reasons why not put all the code in the widget itself, but the chiefmost of them is sharing and multi-user extensibility of the codebase; atm I'm thinking of working off a paradigm that - on first call opens and edits a widget in dwarfmonitor just before the last line (and edits json as needed) - the widget is given things to render in a file of scripts to require - hereafter new things are added in that file whose presence is checked on enabling.


Another reason is dfhack.timeout being null and lack of persistent configuration storage, and what those imply. Now, while I use it fairly often, I guess timeout could be worked around via render reading in-game ticks. Things that take input like constructmultiz though require somehow matching display to internal conditions. I also don't know what else I might find missing for dozen other ideas, such as df.historical_figure.find, which would be absolutely necessary for, say, importing the widget displaying spouse from relations-indicator.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on August 27, 2019, 09:08:54 pm
"Are you trying to display some data that a separate script is generating in a widget?" Yes, exactly.

Tried script_environment on a dummy script (also tried reqscript now; same result) and dwarfmoniter alike, adding/editing variables in during runtime, didn't work even with disable-enable or by editing variables from console before enabling dwarfmonitor for first time in current process. It looks like the environment dwarfmonitor generates and the environment console generates are different. (Adding something to BASE_G obviously failed too; wildly speculating might be that they're on separate C lua states).
They are! (https://github.com/DFHack/dfhack/blob/0.44.12-r2/plugins/dwarfmonitor.cpp#L2027) Yeah, that might cause some issues. That's almost certainly why dfhack.timeout and persistent storage aren't available, as you mentioned - widgets haven't needed those, and running Lua code from DF's render() as the widgets do can sometimes break in weird ways, which I think is why I isolated it by using a separate Lua state.

I feel like reqscript and script_environment ought to work, but I could be wrong (and can't say I've tested it). One thing that trips people up: those only give you access to the global state from the last time the script was run, so calling them more than once won't re-run the script in question (only running the script from the console will do that). But if you're already aware of that, and aren't seeing things populated on the dwarfmonitor side after running the script and accessing its environment again, then it probably is related to the separate Lua state as you suggested.

Now that I think about it, passing data between Lua states might not be easy without going through C++, since they have separate Lua stacks and may be getting accessed from different threads.
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on August 28, 2019, 12:43:40 am
Yeah, they don't work for sharing data (but thanks for warning about having script modify its values on repeated running, I previously modified the values directly by editing the environment instead and checking that sticking with :lua console).

The render does have access to, say, df.global, so there's probably way to share at least plaintext values, if not objects. But it looks like that would have to be written from ground up (or be a rewrite of persistent data storage; not sure in which file the code for that is). Provided that wouldn't be itself a thing that breaks things in weird ways, I guess.
Title: Re: DFHack 0.44.12-r2
Post by: strainer on August 29, 2019, 09:47:57 am
After a bit of curious scanning, I couldn't find in dfhack.lua any way a script can get run without having a reference to its `env` stored in dfhack.lua's local `scripts` table which records when scripts where last run, their `env` (a reference to their local meta-table (?)) and other things. It looks as though env references have to be working in order for the module system to be working (by sharing script state through them)
Since it seems all handled within dfhack.lua, some logging about the `scripts` tables updates might reveal why its not sharing scripts `env` as expected.
Title: Re: DFHack 0.44.12-r2
Post by: Warmist on August 29, 2019, 03:57:42 pm
After a bit of curious scanning, I couldn't find in dfhack.lua any way a script can get run without having a reference to its `env` stored in dfhack.lua's local `scripts` table which records when scripts where last run, their `env` (a reference to their local meta-table (?)) and other things. It looks as though env references have to be working in order for the module system to be working (by sharing script state through them)
Since it seems all handled within dfhack.lua, some logging about the `scripts` tables updates might reveal why its not sharing scripts `env` as expected.

Well... There is other way to run lua. In this case it's being run from plugin code. For some reason it's creating a new (totally new everything) lua_state which is not recommended. I've talked with Lethosor in IRC and IMHO it's a bug. I recall having doing the same thing when somebody smarter told me that i've needed locks in some places. My thinking is like this:

Disclaimer: i've been away from this for a looong time so i might be very wrong.
Title: Re: DFHack 0.44.12-r2
Post by: strainer on August 29, 2019, 07:37:38 pm
Thanks, I missed Lethosor's link to dwarfmonitor.cpp and that it sets up (https://github.com/DFHack/dfhack/blob/315852a2513679ca1afe0d53b34974cefd946f89/plugins/dwarfmonitor.cpp#L156) its own lua state. I guess if dm and maybe others are initializing lua state themselves then it would be best behaviour if they could pass the reference to dfhack.lua so it can put it in the `scripts` table it manages.
Title: Re: DFHack 0.44.12-r2
Post by: Meph on September 04, 2019, 05:42:13 am
Quick question: The use of this create-unit line sometimes crashes the game, sometimes it works. Any idea why?

Code: [Select]
modtools/reaction-trigger -reactionName SUMMON_CRUNDLE_MALE -command [ modtools/create-unit -race CRUNDLE -caste MALE -setUnitToFort -location [ \\LOCATION ] -age 1 ]
I tried searching through the thread, but found not much, besides this post: http://www.bay12forums.com/smf/index.php?topic=164123.msg8003175;topicseen#msg8003175
Title: Re: DFHack 0.44.12-r2
Post by: VictorAB on September 17, 2019, 05:00:46 am
When trying to run the scripts "adv-max-skills" or "make-legendary" I just get the error message "Error loading script"
Is the scripts old and need an update to work right again?

Image to show what I did...
https://gyazo.com/bd4e3048fc3f4ce2e839b925d751457d (https://gyazo.com/bd4e3048fc3f4ce2e839b925d751457d)

(I don't know how to "upload" images to this site, so i use Gyazo... sorry for that mild inconvenience)

EDIT: Forgot to mention that i use Meph's Tileset x32 v5.4 found here: http://www.bay12forums.com/smf/index.php?topic=161047.0 (http://www.bay12forums.com/smf/index.php?topic=161047.0)
The Tileset comes with it's own launcher and DFHack and all... But i'm sure you guys know that by now :P
Title: Re: DFHack 0.44.12-r2
Post by: Warmist on September 17, 2019, 05:14:57 am
When trying to run the scripts "adv-max-skills" or "make-legendary" I just get the error message "Error loading script"
Is the scripts old and need an update to work right again?

Image to show what I did...
https://gyazo.com/bd4e3048fc3f4ce2e839b925d751457d (https://gyazo.com/bd4e3048fc3f4ce2e839b925d751457d)

(I don't know how to "upload" images to this site, so i use Gyazo... sorry for that mild inconvenience)

EDIT: Forgot to mention that i use Meph's Tileset x32 v5.4 found here: http://www.bay12forums.com/smf/index.php?topic=161047.0 (http://www.bay12forums.com/smf/index.php?topic=161047.0)
The Tileset comes with it's own launcher and DFHack and all... But i'm sure you guys know that by now :P

You don't need to write "script" before scriptname. It's enough to write "adv-max-skills" and "make-legendary" and it automagically figures out you mean you want to run script named "adv-max-skills.lua" (or .rb or etc...)
Title: Re: DFHack 0.44.12-r2
Post by: Roses on September 17, 2019, 12:28:12 pm
Quick question: The use of this create-unit line sometimes crashes the game, sometimes it works. Any idea why?

Code: [Select]
modtools/reaction-trigger -reactionName SUMMON_CRUNDLE_MALE -command [ modtools/create-unit -race CRUNDLE -caste MALE -setUnitToFort -location [ \\LOCATION ] -age 1 ]
I tried searching through the thread, but found not much, besides this post: http://www.bay12forums.com/smf/index.php?topic=164123.msg8003175;topicseen#msg8003175

I don't suppose there is any error log printed? Do any of your other create-unit uses do this as well?
Title: Re: DFHack 0.44.12-r2
Post by: VictorAB on September 17, 2019, 04:34:40 pm
When trying to run the scripts "adv-max-skills" or "make-legendary" I just get the error message "Error loading script"
Is the scripts old and need an update to work right again?

Image to show what I did...
https://gyazo.com/bd4e3048fc3f4ce2e839b925d751457d (https://gyazo.com/bd4e3048fc3f4ce2e839b925d751457d)

(I don't know how to "upload" images to this site, so i use Gyazo... sorry for that mild inconvenience)

EDIT: Forgot to mention that i use Meph's Tileset x32 v5.4 found here: http://www.bay12forums.com/smf/index.php?topic=161047.0 (http://www.bay12forums.com/smf/index.php?topic=161047.0)
The Tileset comes with it's own launcher and DFHack and all... But i'm sure you guys know that by now :P

You don't need to write "script" before scriptname. It's enough to write "adv-max-skills" and "make-legendary" and it automagically figures out you mean you want to run script named "adv-max-skills.lua" (or .rb or etc...)
Ah i see, just tried as of typing this.
The way i understand it:
If i type "script adv-max-skills" DFHack actually reads it as "script script adv-max-skills" well, it's a theory any ways since it fails when i type the command initially.

But yeah, without the word "script" in front, it works just fine :D

Thanks, never would have occurred to me to omit "script".
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on September 17, 2019, 05:13:47 pm
Actually, "script" is its own command that tries to read DFHack commands from the file you give it. It's not a prefix that's getting dropped, and DFHack is never using "script script" for anything internally. It's just a command that happens to be named "script", just like there's a command named "adv-max-skills".

Out of curiosity, why did you try putting "script" in front? Was there a documentation page that led you to try that? I'd like to clear up any future confusion, if possible.
Title: Re: DFHack 0.44.12-r2
Post by: Bainin on September 19, 2019, 01:29:25 pm
I got a bit of a Problem, i wanted to play again after a long time then i noticed that DFHack window is not starting. i was confused tried restarting checked my lazy newb pack and it says it is enabled and if i disable Dfhack it says it can't run stuff if i do that, the window is gone and in the start screen there is no dfhack version in the corner.
Strange thing is i have the same issue when i start up a super old version of DF the DFhack just won't start ctrl shift P does not make it appear either But then i tested another Old save and there it works.
when i try and run DFhackrun it instantly closes.  Also the stdout and stderr have like nothing in them.
Can anyone help me with this?

truly weirdest thing to me is that the DFHack 0.43.03-r1 runs when i start that version but the latest (0.44.12) and 0.44.02 don't run smh.

only message stderr is this:
Running PyLNP 0.13b (OS: win, Compiled: True)
INFO: Read installed graphics (Phoebus) from log
INFO: Rebuilding .\Dwarf Fortress 0.44.12\dfhack_PyLNP.init with the enabled hacks
INFO: Rebuilding .\Dwarf Fortress 0.44.12\onMapLoad_PyLNP.init with the enabled hacks
INFO: Rebuilding .\Dwarf Fortress 0.44.12\onMapLoad_PyLNP.init with the enabled hacks
INFO: Rebuilding .\Dwarf Fortress 0.44.12\dfhack_PyLNP.init with the enabled hacks
INFO: Rebuilding .\Dwarf Fortress 0.44.12\dfhack_PyLNP.init with the enabled hacks
INFO: Rebuilding .\Dwarf Fortress 0.44.12\dfhack_PyLNP.init with the enabled hacks
INFO: Rebuilding .\Dwarf Fortress 0.44.12\onMapLoad_PyLNP.init with the enabled hacks
INFO: Rebuilding .\Dwarf Fortress 0.44.12\onMapLoad_PyLNP.init with the enabled hacks
INFO: Rebuilding .\Dwarf Fortress 0.44.12\dfhack_PyLNP.init with the enabled hacks
INFO: F:\Games\DWARFF~1\201919~1.09\Dwarf Fortress 0.44.12\Dwarf Fortress.exe is already running
INFO: F:\Games\DWARFF~1\201919~1.09\Dwarf Fortress 0.44.12\Dwarf Fortress.exe is already running
INFO: F:\Games\DWARFF~1\201919~1.09\Dwarf Fortress 0.44.12\Dwarf Fortress.exe is already running
INFO: F:\Games\DWARFF~1\201919~1.09\Dwarf Fortress 0.44.12\Dwarf Fortress.exe is already running
INFO: F:\Games\DWARFF~1\201919~1.09\Dwarf Fortress 0.44.12\Dwarf Fortress.exe is already running
INFO: F:\Games\DWARFF~1\201919~1.09\Dwarf Fortress 0.44.12\Dwarf Fortress.exe is already running
INFO: F:\Games\DWARFF~1\201919~1.09\Dwarf Fortress 0.44.12\Dwarf Fortress.exe is already running
INFO: Rebuilding .\Dwarf Fortress 0.44.12\onMapLoad_PyLNP.init with the enabled hacks
INFO: Rebuilding .\Dwarf Fortress 0.44.12\onMapLoad_PyLNP.init with the enabled hacks
INFO: Rebuilding .\Dwarf Fortress 0.44.12\dfhack_PyLNP.init with the enabled hacks
INFO: Rebuilding .\Dwarf Fortress 0.44.12\dfhack_PyLNP.init with the enabled hacks
INFO: Rebuilding .\Dwarf Fortress 0.44.12\dfhack_PyLNP.init with the enabled hacks
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on September 19, 2019, 03:57:53 pm
Judging by the reports in the LNP thread, there's something wrong with the latest version: The second latest version ought to be a very good alternative until the issue has been sorted out.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on September 19, 2019, 04:04:27 pm
Yes, see http://www.bay12forums.com/smf/index.php?topic=126076.msg8025916#msg8025916. I might have time to look at it, but it sounds like DFHack was bundled in that pack incorrectly, which is not something we can fix ourselves.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on September 24, 2019, 09:38:27 am
Is anyone doing any work on the persist-table module (allowing numbers to be stored instead of just strings, changing how it works, etc...)? I am working on completely re-writing my stuff and it heavily uses the persistent stuff, just wanted to make sure any work I do isn't going to be invalidated or pointless based on someone elses work
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on September 24, 2019, 10:18:03 am
Not on that as such, no.

Though maybe worth consideration when doing this: When I looked sharing things with dwarfmonitor off df. (as dm doesn't have persistent storage module loaded), I found I could use positions listed in df.global.ui.main.fortress_entity.positions.own, which might provide roughly 16 strings, numbers and unknown number of booleans. i.e. I could have dwarfmonitor pull data from there, alter the data from lua console, and have the results reflected in dwarmonitor's display.

(I haven't actually written anything for that yet, leaving it off for when I do need it and only implementing "simpler" widgets for now.)

I recall putnam mentioned too intense usage of persist-table can drag the game down; if that's down to the size of historical unit vector this could perhaps help streamline it a little bit.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on September 24, 2019, 10:44:05 am
Not on that as such, no.

Though maybe worth consideration when doing this: When I looked sharing things with dwarfmonitor off df. (as dm doesn't have persistent storage module loaded), I found I could use positions listed in df.global.ui.main.fortress_entity.positions.own, which might provide roughly 16 strings, numbers and unknown number of booleans. i.e. I could have dwarfmonitor pull data from there, alter the data from lua console, and have the results reflected in dwarmonitor's display.

(I haven't actually written anything for that yet, leaving it off for when I do need it and only implementing "simpler" widgets for now.)

I recall putnam mentioned too intense usage of persist-table can drag the game down; if that's down to the size of historical unit vector this could perhaps help streamline it a little bit.

Yes, I know my previous attempts at using persistent table storage had a notable impact because I was constantly saving to and loading from it. I've since been experimenting with using global variables during game play and only using the persistent storage on game load/save. Also experimenting with using json files in a similar manner, but allowing for more complex data types. That way you aren't storing a lot of information in the historical unit vectore
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on September 24, 2019, 05:29:54 pm
Worth noting that https://github.com/DFHack/dfhack/pull/1402 was merged and will be in the next release - specifically, it changes the underlying persistent storage API from using histfigs to using global structures that get saved/loaded to/from JSON files as needed, much like you mentioned.
However, both the new and previous implementations should be relatively fast, since all changes are made in memory. Any slowness you're observing with persist-table is likely due to issues specific to persist-table (my understanding is that it has to do some weird and slow things to store tables across multiple histfigs) or due to you making a LOT of writes (which the new JSON-based implementation wouldn't address either). Granted, with the new API from that PR, persist-table could be made a lot faster, if I'm right about why it's slow right now, but migrating old data would take a decent amount of effort and I haven't really looked into it.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on September 27, 2019, 10:04:21 am
Worth noting that https://github.com/DFHack/dfhack/pull/1402 was merged and will be in the next release - specifically, it changes the underlying persistent storage API from using histfigs to using global structures that get saved/loaded to/from JSON files as needed, much like you mentioned.
However, both the new and previous implementations should be relatively fast, since all changes are made in memory. Any slowness you're observing with persist-table is likely due to issues specific to persist-table (my understanding is that it has to do some weird and slow things to store tables across multiple histfigs) or due to you making a LOT of writes (which the new JSON-based implementation wouldn't address either). Granted, with the new API from that PR, persist-table could be made a lot faster, if I'm right about why it's slow right now, but migrating old data would take a decent amount of effort and I haven't really looked into it.

Interesting. For now I will stick with my json work around that just stores everything in global arrays and then writes it out every so often to the data/save/current directory. I'll check out the new API in the next release and see if I can tie it in to what I am doing.

A new question though, I have been using lua for a different project and have gotten more comfortable with some of the more advanced features that I have completely ignored for my dfhack work. My question is, is there a preferred method for dfhack scripts for class constructions (e.g. table-based vs closure-based)? I've noticed most scripts seem to use the table-based method but have been trying to decide which one to use. They each have their advantages/disadvantages, but if one is more preferred for this then I'll gladly just use that.
Title: Re: DFHack 0.44.12-r2
Post by: Warmist on September 27, 2019, 12:07:42 pm
Worth noting that https://github.com/DFHack/dfhack/pull/1402 was merged and will be in the next release - specifically, it changes the underlying persistent storage API from using histfigs to using global structures that get saved/loaded to/from JSON files as needed, much like you mentioned.
However, both the new and previous implementations should be relatively fast, since all changes are made in memory. Any slowness you're observing with persist-table is likely due to issues specific to persist-table (my understanding is that it has to do some weird and slow things to store tables across multiple histfigs) or due to you making a LOT of writes (which the new JSON-based implementation wouldn't address either). Granted, with the new API from that PR, persist-table could be made a lot faster, if I'm right about why it's slow right now, but migrating old data would take a decent amount of effort and I haven't really looked into it.

Interesting. For now I will stick with my json work around that just stores everything in global arrays and then writes it out every so often to the data/save/current directory. I'll check out the new API in the next release and see if I can tie it in to what I am doing.

A new question though, I have been using lua for a different project and have gotten more comfortable with some of the more advanced features that I have completely ignored for my dfhack work. My question is, is there a preferred method for dfhack scripts for class constructions (e.g. table-based vs closure-based)? I've noticed most scripts seem to use the table-based method but have been trying to decide which one to use. They each have their advantages/disadvantages, but if one is more preferred for this then I'll gladly just use that.
I'm not sure what you mean by closure based. There is only one class implementation in dfhack (i.e. defclass) and it uses table based single inheritance model.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on September 28, 2019, 11:38:43 am
I'm not sure what you mean by closure based. There is only one class implementation in dfhack (i.e. defclass) and it uses table based single inheritance model.

Closure based just uses a closed function to store the class so that you can generate both public and private variables and functions. It is generally slightly faster as everything is just an upvalue instead of needed to go through an __index search, but it is also more memory intensive as it creates a hash for each function for each instance of the class you create. Since dfhack has defclass which uses a single inheritance table based model I will just stick with that since I don't think the speed advantage of the closure approach is that big of an impact (the only reason I was thinking about using the closure approach is because I like it better asthetically)
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on September 30, 2019, 11:48:30 pm
I request script or plugin that will make sapients (example, ogress) milkable. This script will temporary add syndrome of removing can_learn (and slow_learner, and intelligent) for milkable creature. After creature milking, syndrome will removed.
Title: Re: DFHack 0.44.12-r2
Post by: Silverwing235 on October 01, 2019, 11:19:49 am
Requesting/suggesting an adjustment to exportlegends commands: that they look in DF root for a folder called 'legends'. If not found, then they go through the ISO standard user dialogue of "legends does not exist. Would you like to create it (Y/N)?" 'cause I'm rather fed up with, say, exportlegends info dumping to root like it does, and mess-making as a result. 
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on October 01, 2019, 06:13:04 pm
Also I request plugin thet make corpses of sapients unsapient if you play as civ with goblinish etics.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on October 01, 2019, 06:30:03 pm
Requesting/suggesting an adjustment to exportlegends commands: that they look in DF root for a folder called 'legends'. If not found, then they go through the ISO standard user dialogue of "legends does not exist. Would you like to create it (Y/N)?" 'cause I'm rather fed up with, say, exportlegends info dumping to root like it does, and mess-making as a result.
Some of the files that get dumped into the main DF folder are put there by vanilla DF's legends exporter - it's not something that DFHack controls. Having exportlegends move those afterwards is probably doable, though, and has been suggested before.
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on October 02, 2019, 02:05:53 am
So, while writing a script that, amongst other things, would allow to limit allowed workers on farmplots and stockpiles via job cooldowns looked at dfhack.job.setJobCooldown - specifically, the part where it will not decrement current cooldown or set it below zero. The initial commit five and half years ago didn't mention why, but does anybody here still know why the limit?

(The -1 setting seems particularly useful for "Never", as it would take over five hundred thousand years to overflow.)

PS: Also, the documentation should probably mention the timeout should is/should be in hundreds of ticks.
Title: Re: DFHack 0.44.12-r2
Post by: Silverwing235 on October 02, 2019, 01:46:57 pm
Some of the files that get dumped into the main DF folder are put there by vanilla DF's legends exporter - it's not something that DFHack controls. Having exportlegends move those afterwards is probably doable, though, and has been suggested before.

"Janitorial duties, however..." Yeah, consider my vote cast in favour of that notion, if you please.
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on October 02, 2019, 04:26:34 pm
I need plugin that will make sapients milkable and sapientr corpses usable if play as civ with eat sapient other etics.
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on October 03, 2019, 01:17:45 am
A quick search brings up Unbutcherable sentient workaround (http://www.bay12forums.com/smf/index.php?topic=165414.msg7553808#msg7553808) for the latter.
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on October 03, 2019, 02:00:10 am
A quick search brings up Unbutcherable sentient workaround (http://www.bay12forums.com/smf/index.php?topic=165414.msg7553808#msg7553808) for the latter.
Thank you. Whats about milking sentients?
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on October 03, 2019, 09:33:38 pm
I guess it may be theoretically possible, but nobody has put it into practice yet as far as I know.
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on October 03, 2019, 11:56:15 pm
I guess it may be theoretically possible, but nobody has put it into practice yet as far as I know.
So I request this script.
Title: Re: DFHack 0.44.12-r2
Post by: Warmist on October 04, 2019, 02:45:38 am
I guess it may be theoretically possible, but nobody has put it into practice yet as far as I know. everyone is scared of how it will be weaponized.

There, fixed it for ya :D
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on October 07, 2019, 01:15:07 pm
Just a headsup, but farm plots with planted seeds report wrong extents in r1 at least (and some previous versions of DF).

Couldn't find correct numbers for _displace atm (trying random numbers is crashy), but looking at the seeds' locations should work as workaround if necessary. Though this probably messes with dfhack.buildings.checkFreeTiles if someone were to call it in the middle of a seeded farmplot.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on October 07, 2019, 01:21:42 pm
How are you determining that they're wrong? Extents are reported by DF, not DFHack, at least as far as I know.
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on October 07, 2019, 01:34:29 pm
The impossibly incorrect values, mainly. Here's an example for 31x1 farm plot:
Code: [Select]
[DFHack]# :lua local bld = dfhack.gui.getSelectedBuilding() printall(bld.room) print(dfhack.buildings.countExtentTiles(bld.room,0))
extents                = nil
x                      = -390889336
y                      = 0
width                  = 0
height                  = 0
0
Title: Re: DFHack 0.44.12-r2
Post by: Rose on October 07, 2019, 01:37:55 pm
I believe extents only exist if the farm plot has holes in it.
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on October 07, 2019, 01:52:09 pm
Hm, few tests suggest that indeed. Though those farm plots appear to report the correct coordinates, unlike the seeded rectangle plots. (A quick one-seed planting tests suggests that complex shapes do still report correct coords/extents when planted).
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on October 07, 2019, 02:50:32 pm
The impossibly incorrect values, mainly. Here's an example for 31x1 farm plot:
Code: [Select]
[DFHack]# :lua local bld = dfhack.gui.getSelectedBuilding() printall(bld.room) print(dfhack.buildings.countExtentTiles(bld.room,0))
extents                = nil
x                      = -390889336
y                      = 0
width                  = 0
height                  = 0
0
The large negative value is most likely an uninitialized value, not anything meaningful.
As for countExtentTiles returning 0, that's what it's supposed to do when "extents" is nil/null: https://github.com/DFHack/dfhack/blob/8a1979b8a7aecee299c0d74720ee37eeaef9fee5/library/modules/Buildings.cpp#L667-L668
Passing width*height instead of 0 as the default value (the second parameter) would probably be a sensible behavior.
Title: Re: DFHack 0.44.12-r2
Post by: scriver on October 10, 2019, 01:02:42 pm
I'm not sure if I've done something wrong but the startdwarf comand doesn't seem to be working for me.

It returns the following:
Code: [Select]
[DFHack]# startdwarf 10
E: Encoding::ConverterNotFoundError: code converter not found (ASCII-8BIT to UTF-8)
 eval:2:in `load'
 eval:2:in `block in <main>'
 eval:2:in `catch'
 eval:2:in `<main>'
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on October 10, 2019, 01:11:55 pm
Wow, that's a new one. What's your system language? Do other Ruby scripts work, like "source"?
Title: Re: DFHack 0.44.12-r2
Post by: scriver on October 10, 2019, 01:39:33 pm
I'm not savvy enough to know what system language refers to specifically but I'm on windows (10), if that helps. I downloaded the dfhack version for Windows 64-bit

Also there's also a bunch of error when I start up DF, which I forgot to mention. I don't know if these are related either but here's what it says:
Code: [Select]
E: Encoding::ConverterNotFoundError: code converter not found (ASCII-8BIT to UTF-8)
 eval:1:in `require'
 eval:1:in `<main>'
E: NoMethodError: undefined method `onstatechange' for DFHack:Module
 eval:1:in `<main>'
E: NoMethodError: undefined method `onstatechange' for DFHack:Module
 eval:1:in `<main>'
DFHack is ready. Have a nice day!
DFHack version 0.44.12-r2 (release) on x86_64
Type in '?' or 'help' for general help, 'ls' to see all commands.
E: NoMethodError: undefined method `onstatechange' for DFHack:Module
 eval:1:in `<main>'
E: NoMethodError: undefined method `onstatechange' for DFHack:Module
 eval:1:in `<main>'
[DFHack]#   

Attempting to run "source" or "source add magma 7" results in the same answer as "setdwarf".
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on October 10, 2019, 03:38:52 pm
Is your computer set to English or something else?
Title: Re: DFHack 0.44.12-r2
Post by: scriver on October 10, 2019, 03:52:16 pm
Oh! Swedish.
Title: Re: DFHack 0.44.12-r2
Post by: scriver on October 12, 2019, 08:57:11 am
Update: Moving the DF folder from D: to C: drive solved the issue.

While I don't mind since I was going to put it on C: anyway, I still have no idea why. I'm going to assume it is because D: is the grumpy drive and C: is the happy one.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on October 12, 2019, 12:23:42 pm
Did you just move the DF folder to a different partition/drive, or did you also change the path? If the path had some Swedish characters in it I could understand a failure to interpret a full path (but I don't see any need to use anything but relative ones).

Furthermore, if your PC is configured with an "OS partition/disk" there typically isn't room for a lot of other stuff on it (such as DF saves, which can get fairly large).
Title: Re: DFHack 0.44.12-r2
Post by: scriver on October 12, 2019, 12:47:26 pm
Yeah, there are letters of the Swedish variety in the old address, but not in the new. That could be it!
Title: Re: DFHack 0.44.12-r2
Post by: Clément on October 14, 2019, 05:16:45 am
A quick question about DF structures documentation. In the Enum type definition section (https://dfhack.readthedocs.io/en/stable/library/xml/SYNTAX.html#enum-type-definition), it is written "Every attribute must be declared at the top level of the enum". Isn't it supposed to be "at the top of the enum" instead (or more precisely before any enum-item element)? Mentioning the top level in this context feels strange and all enum attributes being defined before use makes it easier to parse.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on October 15, 2019, 02:15:26 am
screwing around with gm-editor I realize it's possible to just capture a ruin with dfhack. though I haven't got around to writing a script for this, but it opens up to expansion after say a site got totaled or you razed it by accident and want to move folks in afterwards, or want to capture caves and other sites.
Title: Re: DFHack 0.44.12-r2
Post by: Warmist on October 15, 2019, 05:57:21 am
A quick question about DF structures documentation. In the Enum type definition section (https://dfhack.readthedocs.io/en/stable/library/xml/SYNTAX.html#enum-type-definition), it is written "Every attribute must be declared at the top level of the enum". Isn't it supposed to be "at the top of the enum" instead (or more precisely before any enum-item element)? Mentioning the top level in this context feels strange and all enum attributes being defined before use makes it easier to parse.

I don't think it matters as afaik we are using xml-lib for parsing. If you are saying for human parsing then yes, it would be useful.

For exact answer you probably need to read:  here  (https://github.com/DFHack/df-structures/blob/master/Enum.pm) however i can't read it :D
Title: Re: DFHack 0.44.12-r2
Post by: Clément on October 15, 2019, 09:00:27 am
It is not about the library. In my own parser I'd prefer to read all the children of enum-type in order. I hope that when I come across an enum-item, all the enum-attr it references have already been parsed. It is the case with the current state of the xmls, but I don't know if it will stay that way. The documentation is not clear about that. "top level" usually means root/document node in the context of XML. Was it supposed to be only "top"? Or does mean its that enum-attr should be a direct child of enum-type? But it is weird to insist on that when it is not specified for other elements.

Enum.pm uses "findnodes('child::enum-attr')" and "findnodes('child::enum-item')", so I guess it does not rely on one being before the other.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on October 15, 2019, 05:12:54 pm
I think "top level" is correct (df-structures codegen does multiple passes, and the findnodes() calls you pointed out definitely suggest that the placement ). Maybe someone tried to put a <enum-attr> inside a <enum-item> at some point (rather than an <item-attr>) and that broke things badly enough to warrant a specific mention in the docs. <enum-attr>s should be at the top of their <enum-type> for consistency, though.

At any rate, if you're parsing df-structures, I would highly recommend using a proper XML parser (if you aren't already) and taking a look at library/include/df/codegen.out.xml, which is supposed to be easier for tools to parse than the source XML files (but it does require running codegen).
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on October 15, 2019, 05:18:47 pm
Yeah, there are letters of the Swedish variety in the old address, but not in the new. That could be it!
Yeah, the Ruby plugin has a somewhat sketchy way of loading scripts, which has broken with single quotes (https://github.com/DFHack/dfhack/issues/1146) before. However, that should have been fixed as of this change (https://github.com/DFHack/dfhack/commit/08656a3ca7d433c43e052920836e650880c18b90).
If you still have your broken installation, can you try running these two commands and paste their output here?
Code: [Select]
lua print(dfhack.internal.getScriptPaths())

Code: [Select]
lua print(dfhack.filesystem.getcwd())
(feel free to remove any personal info from this one)
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on October 16, 2019, 03:53:06 am
Changing "Games" to "Gämes" in my path to DF causes the LNP launcher to fail to launch.

Code: [Select]
lua print(dfhack.internal.GetScriptPaths()[1])(the original command just gave a table, and
"D:\Gõmes\Dwarf Fortress\Dwarf Fortress 44_12 Starter Pack r05\Dwarf Fortress 0.44.12/raw/scripts"

and the second command resulted in
"D:\Gõmes\Dwarf Fortress\Dwarf Fortress 44_12 Starter Pack r05\Dwarf Fortress 0.44.12"

Note that I'm unable to copy/paste from the DFHack window, so there may be typing errors above. However, it can be noted that the "ä" character was mangled into "õ" (I think that's it: it's somewhat hard for my poor eyes to determine the mangled character exactly, but it's not "ö", but definitely "a" -> "o" translation of the character being decorated).

Presumably the script interprets the non ASCII character in the path differently than the OS does.
Title: Re: DFHack 0.44.12-r2
Post by: vettlingr on October 16, 2019, 06:41:07 am
I tested it on Mac too.

path:
Applications\Älgstubben\Bäverdammen\Järvträsket\Lazy Mac Pack v0.44.12 dfhack-r2/Dwarf Fortress 0.44.12/

I can confirm that LNP won´t launch when there are common Swedish words in the path.
Title: Re: DFHack 0.44.12-r2
Post by: scriver on October 16, 2019, 10:03:09 am
I don't know if it matters for me to respond as well, but three data points is better than two right?

My original, faulty path was "D:\Gustav\detsomfallitfrånträden\övrigt\DF\df_44_12_win". As you can see I manage to score all three Swedish letters in there. In alphabetic order, even. Go me.

Running the commands you asked:
Code: [Select]
[DFHack]# lua print(dfhack.internal.getScriptPaths())
table: 0000026AE1010560

Code: [Select]
[DFHack]# lua print(dfhack.filesystem.getcwd())
D:\Gustav\detsomfallitfrÕntrõden\÷vrigt\DF\df_44_12_win

Õ appears to be an O with a ~ over it.

å=Õ
ä=õ
ö=÷

I don't if you want to know what symbols they become, just continuing off of Lundell's musings, but anyway to get all the capital letters as well I moved the DF map to "D:\...\DF\Å\Ä\Ö\df_44_12_win

Code: [Select]
[DFHack]# lua print(dfhack.filesystem.getcwd())
D:\...\DF\┼\─\Í\df_44_12_win

Å=┼
Ä=─
Ö=Í
Title: Re: DFHack 0.44.12-r2
Post by: brolol.404 on October 16, 2019, 12:08:46 pm
This command isn't working for me:

Code: [Select]
dfhack.run_command("modtools/force -eventType NightCreature")
The script is running (as the print command works), but nothing is happening for that line.

I am trying to get a random werecreature to spawn in fortress mode. Am I missing something in that code?
Title: Re: DFHack 0.44.12-r2
Post by: Clément on October 16, 2019, 03:11:41 pm
The encoding issue looks like a conversion from cp1252 to cp850 (or something similar). But why this kind of code page would be used on a modern system?

Edit: It seems windows console uses cp850, so it could be a simple display error (read the path from syscalls as cp1252 and displays it in the cp850 console without converting). The other loading errors may be unrelated.
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on October 16, 2019, 04:30:02 pm
Request plugin that make sapients milkable in fortress mode when goblin ethics.
Title: Re: DFHack 0.44.12-r2
Post by: Bumber on October 16, 2019, 11:56:44 pm
Request plugin that make sapients milkable in fortress mode when goblin ethics.
http://www.bay12forums.com/smf/index.php?topic=121451.0
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on October 17, 2019, 05:20:34 am
So just notice the entity animal token issue with migrants can be fixed with writing up a script that checks the new migrants for missing a population id... oh wait these units also don't have a historical figure id, hmm uhh I wonder if it's easier to just use spawn unit to create a historical figure id for these units then?
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on October 17, 2019, 05:53:36 pm
I don't know if it matters for me to respond as well, but three data points is better than two right?

My original, faulty path was "D:\Gustav\detsomfallitfrånträden\övrigt\DF\df_44_12_win". As you can see I manage to score all three Swedish letters in there. In alphabetic order, even. Go me.

Running the commands you asked:
Code: [Select]
[DFHack]# lua print(dfhack.internal.getScriptPaths())
table: 0000026AE1010560
Sorry, I wanted printall, not print! (I didn't actually test it first). This is the one I'm more concerned about, really, so if you can double-check, that would be great.

Quote
Code: [Select]
[DFHack]# lua print(dfhack.filesystem.getcwd())
D:\Gustav\detsomfallitfrÕntrõden\÷vrigt\DF\df_44_12_win

Õ appears to be an O with a ~ over it.

å=Õ
ä=õ
ö=÷

I don't if you want to know what symbols they become, just continuing off of Lundell's musings, but anyway to get all the capital letters as well I moved the DF map to "D:\...\DF\Å\Ä\Ö\df_44_12_win

Code: [Select]
[DFHack]# lua print(dfhack.filesystem.getcwd())
D:\...\DF\┼\─\Í\df_44_12_win

Å=┼
Ä=─
Ö=Í
Yeah, the letters changing is weird. As Clement pointed out, it's probably something to do with the DFHack console using a different encoding (I think it uses CP437 like DF on Windows?). It's probably not the cause of the issue you were having, but it could be a related issue.


I tested it on Mac too.

path:
Applications\Älgstubben\Bäverdammen\Järvträsket\Lazy Mac Pack v0.44.12 dfhack-r2/Dwarf Fortress 0.44.12/

I can confirm that LNP won´t launch when there are common Swedish words in the path.
Changing "Games" to "Gämes" in my path to DF causes the LNP launcher to fail to launch.

I should clarify - I don't care at all about LNPs; I'm just interested in the DFHack issue (which is that running Ruby scripts from these paths doesn't work). I do have macOS and Linux systems available, but if you can test running just DFHack (without going through PyLNP) from a path with special characters, that would be great. PyLNP issues like the one you described should go here: http://www.bay12forums.com/smf/index.php?topic=140808.0

Quote from: PatrikLundell
Note that I'm unable to copy/paste from the DFHack window
Yeah, Windows is a bit weird here, but you should be able to do it by right-clicking on the title bar of the DFHack console.

This command isn't working for me:

Code: [Select]
dfhack.run_command("modtools/force -eventType NightCreature")
The script is running (as the print command works), but nothing is happening for that line.

I am trying to get a random werecreature to spawn in fortress mode. Am I missing something in that code?
Does running "modtools/force -eventType NightCreature" in the DFHack console do what you expect?
Title: Re: DFHack 0.44.12-r2
Post by: scriver on October 17, 2019, 07:42:53 pm
Is this what you meant?

Code: [Select]
[DFHack]# lua printall(dfhack.internal.getScriptPaths())
1                        = D:\Gustav\detsomfallitfrÕntrõden\÷vrigt\DF\df_44_12_win/raw/scripts
2                        = D:\Gustav\detsomfallitfrÕntrõden\÷vrigt\DF\df_44_12_win/hack/scripts
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on October 17, 2019, 10:33:13 pm
Is this what you meant?

Code: [Select]
[DFHack]# lua printall(dfhack.internal.getScriptPaths())
1                        = D:\Gustav\detsomfallitfrÕntrõden\÷vrigt\DF\df_44_12_win/raw/scripts
2                        = D:\Gustav\detsomfallitfrÕntrõden\÷vrigt\DF\df_44_12_win/hack/scripts
Yup! To explain further: these two folders are where DFHack will look for scripts. To work around some issues with special characters, it will remove the DF path from the beginning, but it has to match exactly (which it should, but if it doesn't, that could explain the issue you saw). However, it looks like this does match the DF path you posted earlier, so that rules out the specific problem I was thinking of:
Code: [Select]
[DFHack]# lua print(dfhack.filesystem.getcwd())
D:\Gustav\detsomfallitfrÕntrõden\÷vrigt\DF\df_44_12_win
Title: Re: DFHack 0.44.12-r2
Post by: Clément on October 18, 2019, 05:01:38 am
I think it uses CP437 like DF on Windows?

On my system (french locale), it uses CP850 (it matches scriver case too). It is a DOS encoding, I guess it is there for compatibility with old console applications.

There is SetConsoleOutputCP (https://docs.microsoft.com/en-us/windows/console/setconsoleoutputcp) that would let you change the console encoding (use it with GetACP (https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getacp) to have the same encoding everywhere).

Another solution is to use the unicode API for windows calls, everything will be UTF-16 in this case (even the console).

There is still the ruby error, but I don't know how that part works.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on October 18, 2019, 07:45:02 am
In the short term (before Toady expands the character set with the Premium arc), it sounds like it would be appropriate for the DF console to use the same code page as DF does (CP437) to get the output to match what DF produces, but I suspect this is a pure display issue, while the path incompatibility issue lies elsewhere. I guess it would make sense to check the non Windows DFHack console for display issues while investigating this, but since we've got a Mac report of path incompatibilities as well (although no printed output has been provided, since it was requested after that report), the deeper issue is probably not tied to the console version.

When it comes to post Premium DF the suitable solution ought to depend on how DF is changed, which remains to be seen: as far as I can see, the output ought to match what DF displays as closely as possible. And, when at it, the DF color palette expansion will require something different from the current mapping if it should follow suit, and might even be expanded to support background color in the console.
Title: Re: DFHack 0.44.12-r2
Post by: Clément on October 18, 2019, 08:25:33 am
Changing the windows console encoding is the easy fix, but you won't be able to display both paths (or error strings or whatever windows gives you) and df strings correctly. The best solution is to use unicode everywhere, but it will require more work.

Running dfhack on linux in a directory containing "éçà" does not generate any error (ruby or other).
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on October 18, 2019, 12:31:31 pm
Changing the windows console encoding is the easy fix, but you won't be able to display both paths (or error strings or whatever windows gives you) and df strings correctly. The best solution is to use unicode everywhere, but it will require more work.

Running dfhack on linux in a directory containing "éçà" does not generate any error (ruby or other).
When using the command scriver has issues with ("startdwarf 10")? I had no problems with DFHack itself with the funny path: DF started just fine when invoked directly, and the commands lethosor provided worked without issues. I assume it's scripts written in Ruby that get into trouble.

You can't easily differentiate between strings that originated within DF(Hack) from those that originated from buried calls to external functionality, unless you convert everything everywhere to use Unicode (or something else) at every interfacing function internally in DFHack and then convert it back to CP437 when feeding it to DF, and printing things as DF(Hack) perceives them is probably the least confusing option. String manipulation gets messy with variable size encodings as well.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on October 18, 2019, 05:06:39 pm
I think it uses CP437 like DF on Windows?
On my system (french locale), it uses CP850 (it matches scriver case too). It is a DOS encoding, I guess it is there for compatibility with old console applications.
In the short term (before Toady expands the character set with the Premium arc), it sounds like it would be appropriate for the DF console to use the same code page as DF does (CP437)

Interesting - my understanding was that it was supposed to use CP437 on Windows by default (at least, I have never seen complaints that printing CP437-encoded names from DF with accented characters to the console displays the wrong characters on Windows, while I've seen several complaints about the same issue on Linux/macOS). Can you double-check whether print(dfhack.TranslateName(some_unit.name)) displays the right characters in the Windows console?

Title: Re: DFHack 0.44.12-r2
Post by: Clément on October 18, 2019, 07:00:43 pm
Interesting - my understanding was that it was supposed to use CP437 on Windows by default (at least, I have never seen complaints that printing CP437-encoded names from DF with accented characters to the console displays the wrong characters on Windows, while I've seen several complaints about the same issue on Linux/macOS). Can you double-check whether print(dfhack.TranslateName(some_unit.name)) displays the right characters in the Windows console?

(https://framapic.org/h98PF20lrrEk/XcDKNosXdJFQ.png)

è from the unit name is displayed correctly, but the è from the path is displayed as Þ which is not part of CP437.
For reference, è is 0x8a is CP437 and CP850, but 0xe8 in CP1252. 0xe8 gives Þ in CP850, but Φ in CP437. You may just have been lucky because non-ASCII characters used in DF names are compatible between CP437 and CP850. Or CP437 may be the default for the US locale. I wonder what happens with other locales using different alphabets (like cyrillic, arabic, ...).

I thought there was a conversion with the DF2CONSOLE function, but apparently it is only for Linux.

When using the command scriver has issues with ("startdwarf 10")? I had no problems with DFHack itself with the funny path: DF started just fine when invoked directly, and the commands lethosor provided worked without issues. I assume it's scripts written in Ruby that get into trouble.
I did not test that, on Windows starting DF is enough to get the error messages. I'll try that later.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on October 18, 2019, 08:01:34 pm
You may just have been lucky because non-ASCII characters used in DF names are compatible between CP437 and CP850. Or CP437 may be the default for the US locale. I wonder what happens with other locales using different alphabets (like cyrillic, arabic, ...).
Oh, that's probably it, actually!
Quote
I thought there was a conversion with the DF2CONSOLE function, but apparently it is only for Linux.
It's defined to "do the right thing" on all platforms, which is specifically a no-op on Windows. Seems that we might need to adjust that. Thanks for the insight.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on October 18, 2019, 09:52:50 pm
hmm starting to wonder if it's possible for me to add retired adventurers to a site via workers and recruit them that way? like I recently poke around the recall workers list and notice it draws from the nemesis pool, but only if said nemesis has a unit id tied to them.
Title: Re: DFHack 0.44.12-r2
Post by: Clément on October 19, 2019, 03:38:37 am
When using the command scriver has issues with ("startdwarf 10")? I had no problems with DFHack itself with the funny path: DF started just fine when invoked directly, and the commands lethosor provided worked without issues. I assume it's scripts written in Ruby that get into trouble.

No issue with startdwarf on Linux with a "é" and even a "𝄋" (U+1D10B) in the path. No error message in the console and I get the expected number of dwarf.
Title: Re: DFHack 0.44.12-r2
Post by: Heretic on October 19, 2019, 07:08:47 am
That is scale of army coords?
As i can manually test it's look close to 1/3 of chunk.
But I absolutely not sure.
EDIT: Then i use this size it works mostly fine, but i'm still unsure.
Title: Re: DFHack 0.44.12-r2
Post by: Heretic on October 19, 2019, 12:56:26 pm
Another thing - need to teleport adventurer to world coords. How can i do it? teleport.lua work only inside one global tile for me.
okey, i found a solution - questport works fine. But i can't make it teleport for choosen numbers coords on global map, not by q-menu. Can somebody help please?
Title: Re: DFHack 0.44.12-r2
Post by: Omemega The seal on October 19, 2019, 02:17:51 pm
how can i give me a back pack on adventure mode? i Lost mine and i have been 9 days on that run
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on October 20, 2019, 04:16:24 am
So, a thought occurs to me, recarding persistent data, persist-tables, it's limitation of only storing strings and json:

Anything limiting/stopping encoding all your script's data into a json, setting it in 1 persistent key's value, then decoding on retrivial?

@Roses: Btw, instead of patching quicksave, I found this example

Code: [Select]
repeat -time 1 -timeUnits frames -command [ ":lua if df.global.ui.main.autosave_request and not already_saved then dfhack.persistent.save({key='testname',value='hi'}) print('autosave request') already_saved = true end" ] -name autodetectto save persistent data before save goes through in one test, i.e. the testname is set after kill+restart. Not sure if it is useful or always happens, but an idea.

@Heretic: iirc army coords are on the scale of 9 tiles in 1x1 embark, the so-called mid-level. Toady mentions it in FotF somewhere in 2018 iirc.

Also, for teleporting over grand distances, Bearskie's mapdragon.lua for mapping whole world with isoworld (https://www.reddit.com/r/dwarffortress/comments/83dper/df_pocket_world_isoworld_10445_x_5382px_scaled_16/dzc7dpp/) might be helpful starting point.

@Omemega The Seal:

Try gui/create-item?
Title: Re: DFHack 0.44.12-r2
Post by: Silverwing235 on October 20, 2019, 08:33:28 am
Not certain what else to do, so: Updated AV recently, and it's DFHack that blares the following at me upon every (LNP-organised) DF startup since:
Quote from: DFHack
Warning: Plugin RemoteFortressReader compiled for DFHack 0.44.12-r2-80-gc793b101, running DFHack 0.44.12-r2-0-g315852a2

Apologies for disturbing JapaMala's self-care routine over this.
Title: Re: DFHack 0.44.12-r2
Post by: Rose on October 20, 2019, 05:07:44 pm
That's a harmless warning. As long as the actual dwarf fortress version matches, which it does, things should be fine.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on October 21, 2019, 07:27:34 am
Another thing - need to teleport adventurer to world coords. How can i do it? teleport.lua work only inside one global tile for me.
okey, i found a solution - questport works fine. But i can't make it teleport for choosen numbers coords on global map, not by q-menu. Can somebody help please?
what you want is an old script made by warmist that used waypoints for teleporting for a selected destination but from what I remember it hasn't been updated.
Title: Re: DFHack 0.44.12-r2
Post by: Atkana on October 28, 2019, 12:17:07 pm
Is the need_type for praying / meditating supposed to be "PrayOrMedidate", or is that a typo in the structures / the game itself? And if I were to be submitting some scripts to the repo sometime soon should I still keep the current value in, or pre-emptively change them?
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on October 28, 2019, 02:26:51 pm
It's a typo in structures (https://github.com/DFHack/df-structures/blob/c192f9798b5d134e777b1f37c8ebc0df4bd53bda/df.units.xml#L470) (it's also a 4-year-old typo (https://github.com/DFHack/df-structures/commit/2066af87ef7f812e394894b62554f0ac3201cf55) - nice catch!).

if I were to be submitting some scripts to the repo sometime soon should I still keep the current value in, or pre-emptively change them?
Changing the names of existing enum items is always painful for this reason. I've fixed it in df-structures, and it doesn't look like any of our code uses this name. For the purposes of something that you want included in the next DFHack release, I would use the new name - but this means that you'll have to change it to use the old name for 0.44.12-r2. I'll try my best to get a DFHack release out soon-ish, but that hasn't happened for several months now...
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on October 28, 2019, 03:12:14 pm
Hm, while we're speaking of structures anyway, any idea what's the minimum change to convert 43.03 units.xml unit from struct-type to class-type? It just spits errors at me (such as unit has no .name) if I just change the type as in the commit that changed it and add the three virtual methods, and don't want to paste wholesale since that'll break plugins relying on old relationship compounds.
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on October 28, 2019, 03:24:19 pm
I need plugin that make sentient creatures (example trolls) milkable.
Title: Re: DFHack 0.44.12-r2
Post by: Bumber on October 28, 2019, 03:40:29 pm
I need plugin that make sentient creatures (example trolls) milkable.
You've posted this 3 times in this thread and created your own thread, and I'm thinking maybe nobody's interested.
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on October 28, 2019, 04:42:40 pm
I need plugin that make sentient creatures (example trolls) milkable.
You've posted this 3 times in this thread and created your own thread, and I'm thinking maybe nobody's interested.
I will stop only when someone make this.
Title: Re: DFHack 0.44.12-r2
Post by: bloop_bleep on October 28, 2019, 11:20:49 pm
You could also try looking up some documentation and existing scripts, then writing one yourself.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on October 29, 2019, 08:54:54 am
I need plugin that make sentient creatures (example trolls) milkable.
You've posted this 3 times in this thread and created your own thread, and I'm thinking maybe nobody's interested.
I will stop only when someone make this.
If you don't stop pestering people with unreasonable demands to satisfy your whims for modded games with limited to no utility for anyone else someone will probably request that you're banned from the forum. The only thing you achieve by your repeated posting all over the place is to annoy people. Asking once (nicely, as is the English custom, as opposed to the brutal directness of your supposed native language) is fine. No response means no interest/no relevant knowledge.

Your demands are unreasonable:
- People who DO help writing scripts for others do so in their own time and when the issue is of at least some interest to them, in particular if it's an easy task.
- The number of people who care about or are interested in your particular demand is probably very small (around 0).
- A plugin is a substantial effort up from a script and would either have to be accepted into DFHack (unlikely, given that it has no usability at all in vanilla DF), in which case you'd have to wait until a new DFHack release is made (which may take many months), or the setup of development environments for all OS/bitness versions DF is provided in, and then provided through links to repositories. That's a lot of work for someone who stomps in with a demand of no general interest.
- If you want extremely niche utilities you'll either have to find someone with similar interests to help you, or learn to provide those tools yourself.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on October 30, 2019, 05:02:52 am
like with dfhack's item spawning you can produce unlimited amounts of liquid milk in any container you want and probably attach the milk origins to any person, though I think no one here probably too keen on wanting to use dfhack to force sapient folks into milking factories... when one could just craft milk via modding... that said kinda wonder how the whole process of milking works in adventure mode to some what improve on the advfort stuff.
Title: Re: DFHack 0.44.12-r2
Post by: Warmist on October 30, 2019, 09:35:35 am
like with dfhack's item spawning you can produce unlimited amounts of liquid milk in any container you want and probably attach the milk origins to any person, though I think no one here probably too keen on wanting to use dfhack to force sapient folks into milking factories... when one could just craft milk via modding... that said kinda wonder how the whole process of milking works in adventure mode to some what improve on the advfort stuff.
In advfort - haven't tested but general idea is this: create just enough df stuff that it's job handling logic takes over and then if player presses "pass time" it controls your char as if it's one of the fort mode dwarves (well more like your units ) and does all the complicated stuff. And that fails in many ways (e.g. plant gathering... have no idea why it does not work). Sometimes you need to setup a lot more stuff than other times (e.g. fill out various references)...

Anyway my newest attempt at "job creation utils" is  here but it looks very bad already  (https://github.com/warmist/df_multiplay/blob/master/jobs.lua) :< need to revisit all this job thing (for my undead doing the dirty jobs for you mod)
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on October 30, 2019, 01:14:22 pm
What about reaction, that can be done by only milkable worker and produce milk of this worker? How make this with dfhack?
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on October 30, 2019, 03:44:45 pm
Yeah, that's much easier - Eventmanager (https://dfhack.readthedocs.io/en/stable/docs/Lua%20API.html#events-from-eventmanager) would let you fill in milk from creature into bucket when they complete a job to milk themselves, provided they're milkable. (That takes a bucket and produces that same bucket.)

There might have been a way to ensure only suitable creatures can take the job without cancellations; not sure. But you could cancel milk self when the unit can't be milked due not being milkable or being milked too recently.

(Though you can't assign same creature as the milker and the milkee in vanilla job; they'll cancel the job due being in custody.)
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on October 30, 2019, 04:26:19 pm
Yeah, that's much easier - Eventmanager (https://dfhack.readthedocs.io/en/stable/docs/Lua%20API.html#events-from-eventmanager) would let you fill in milk from creature into bucket when they complete a job to milk themselves, provided they're milkable. (That takes a bucket and produces that same bucket.)

There might have been a way to ensure only suitable creatures can take the job without cancellations; not sure. But you could cancel milk self when the unit can't be milked due not being milkable or being milked too recently.

(Though you can't assign same creature as the milker and the milkee in vanilla job; they'll cancel the job due being in custody.)
So I need only reaction raw code? Or also need script?
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on October 30, 2019, 05:56:15 pm
You need both, but script would be over ten times simpler to do than before.
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on October 30, 2019, 06:36:27 pm
You need both, but script would be over ten times simpler to do than before.
Can you make new script and reaction?

Also I want know: is any way to teleport worldgen artifacts from location (especially lost in wilds) to my fort?
Title: Re: DFHack 0.44.12-r2
Post by: fortunawhisk on October 31, 2019, 12:49:44 am
I saw this in the ThreeToe's stress thread:
- Dorfs that have had a strange mood are immune to insanity. I had one that was tantruming and had maximum stress, but once I managed to get the finicky bugger to pick up a trinket of a desired material (wouldn't take anything else hauled), a slow trek towards recovery started. Unfortunately, the fortress was cut short by raid corruption when the stress level had improved from -100000 to -70000 (which is still extremely bad). I believe I also did other things apart from the crucial trinket acquisition to improve the condition of this starting 7 dorf, though.

Is there a data structure somewhere in the unit that contains a list of desired trinkets and their material(s)? A 'I want to acquire a ring, preferably dolomite' entry, if you will?

Separately, has anyone worked out how the 'stress_boost' / 'stress_drain' system from the unit personality section works?
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on October 31, 2019, 02:38:48 am
Yeah, you can access preferred things in .status.current_soul.preferences, and needs in ..soul.personality.needs. I bet latter is more important than the former.

@DerMeister: Maybe one day when I'm also on a mod dealing with milkable sapients; for now working on other stuff. It's a lot more interesting at least, allowing stuff like snakemen milking themselves for venom.
Title: Re: DFHack 0.44.12-r2
Post by: Atkana on October 31, 2019, 02:49:07 am
Is there a data structure somewhere in the unit that contains a list of desired trinkets and their material(s)? A 'I want to acquire a ring, preferably dolomite' entry, if you will?
That would be the unit's preferences (that list you can see where it explains materials, creatures, art forms, etc. that they like). The preferences are stored in the unit's unit.status.current_soul.preferences.

For a material preference: type will be 0 (df.unit_preference.T_type[0] is LikeMaterial). mattype and matindex are the type and index of the material. You can use dfhack.matinfo.find(TOKEN), where TOKEN is the material's token (e.g. "INORGANIC:GOLD", "COW:MILK") to find the material, and then use its .type and .index info to fill in mattype and matindex respectively.

For an item preference: type will be 4 (df.unit_preference.T_type[4] is LikeItem). item_type will be the item's type (df.item_type). Conveniently, the numerical ids and tokens are listed on this wiki page (https://dwarffortresswiki.org/index.php/DF2014:Item_token), so set the item_type value to either the number listed or use df.item_type[TOKEN] (e.g. for blocks use 2 or df.item_type.BLOCKS). item_subtype will be -1 for items without subtype. For items with subtypes (weapons, trap components, toys, tools, instruments, armor, ammo, siege_ammo, gloves, shields, helms, pants, food) you use that item's subtype. I don't know if there's any direct way of finding a subtype by a string, but all items with subtypes are listed in df.global.world.raws.itemdefs.all (or instead of .all you can use stuff like .weapons to only get the weapon itemdefs). From within that table, it'd simply be a case of looping through it until you find the desired id (the token of the item subtype e.g. "ITEM_WEAPON_CROSSBOW") and using the subtype entry for the item_subtype (so again in this example crossbows have a subtype of 6).

You're lucky I just recently looked into all of this :P
Title: Re: DFHack 0.44.12-r2
Post by: Clément on October 31, 2019, 05:34:02 am
You don't need to know the values for the preference type, use df.unit_preference.T_type.LikeMaterial instead of 0.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on October 31, 2019, 07:47:08 am
I haven't seen anything like a "desired item" list, and I don't expect one to exist. Instead, I'd expect the current logic (which ought to be revised to allow non haulers to be catered for) to go the other way, i.e. "I'm currently hauling a dolomite ring. How does that match my trinket preferences?".
From there, I'd guess the results can be (note guess):
- Well, it's a quality trinket, I need one, and I'm not too picky. I'll take it.
- Well, it's a quality dolomite ring, I need a trinket, and I require it to be either a ring or made from gabbro. I'll take it.
- MOMMY!!! I WANT A GABBRO RING!!! (stomping optional).

Most dorfs appear to be satisfied by any trinket, possibly with a quality threshold, with my finicky dorf an exception. Also note that some dorfs have material preferences, some have item type preferences, and some have both (hence nobles demanding things like bronze beds), and some neither (with nobles without item preferences being safe from ordering mandate violation murders. Materials are OK).
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on October 31, 2019, 04:10:27 pm
Hm, while we're speaking of structures anyway, any idea what's the minimum change to convert 43.03 units.xml unit from struct-type to class-type?

It's impossible. struct-type is for structs or classes that don't have virtual methods, and class-type is for ones that do. Going from no virtual methods to some virtual methods changes the layout of the class (specifically, it adds a pointer at the beginning pointing to all the virtual methods). While the methods that became virtual in 0.43.05 existed before, there's no easy way to call them from 0.43.03 because they weren't virtual then.
Quote
It just spits errors at me (such as unit has no .name) if I just change the type as in the commit that changed it and add the three virtual methods, and don't want to paste wholesale since that'll break plugins relying on old relationship compounds.
However, this might be something else. What specific commit are you trying to compile? What changes are you looking at? Links and error messages would help (pastebin is fine if they're long).

Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on October 31, 2019, 06:07:17 pm
Just this change will result in breakage (https://github.com/DFHack/df-structures/commit/83bb414f59abf405240ab0ce597804a235344b49).

Anyway, good to know it's impossible. I think I found at least partial workaround while editing something similar (in regards to vermin with no vmethods), thankfully.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on October 31, 2019, 11:02:13 pm
To clarify, you're using 0.43.03 structures and changing struct-type to class-type? And the "name" field isn't defined? Its name hasn't changed, so maybe something else named "name" is breaking - the messages from the compiler might help here.
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on October 31, 2019, 11:24:49 pm
Yes. And wait, I think I got confused with a different error, it does compile but segfaults when looking at unit and using gui/gm-editor (confirmed this by compile, check, revert, check again).

Of course, given can't include the vmethods anyway the point is moot.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on November 01, 2019, 04:17:31 am
like with dfhack's item spawning you can produce unlimited amounts of liquid milk in any container you want and probably attach the milk origins to any person, though I think no one here probably too keen on wanting to use dfhack to force sapient folks into milking factories... when one could just craft milk via modding... that said kinda wonder how the whole process of milking works in adventure mode to some what improve on the advfort stuff.
In advfort - haven't tested but general idea is this: create just enough df stuff that it's job handling logic takes over and then if player presses "pass time" it controls your char as if it's one of the fort mode dwarves (well more like your units ) and does all the complicated stuff. And that fails in many ways (e.g. plant gathering... have no idea why it does not work). Sometimes you need to setup a lot more stuff than other times (e.g. fill out various references)...

Anyway my newest attempt at "job creation utils" is  here but it looks very bad already  (https://github.com/warmist/df_multiplay/blob/master/jobs.lua) :< need to revisit all this job thing (for my undead doing the dirty jobs for you mod)
so during the first time advfort broke and noticing it doesn't really break on npcs I modified it to be a 'companion' fort script that just sends the jobs over to them. which while works does mean I have to pass a lot of time and probably could just re-write it to just send them job commands or something.

but most of this is a vacation from the head scratcher that is figuring out where the Mission data went in the new version of Dfhack and poking around how armies work.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on November 01, 2019, 12:54:23 pm
Yes. And wait, I think I got confused with a different error, it does compile but segfaults when looking at unit and using gui/gm-editor (confirmed this by compile, check, revert, check again).

Of course, given can't include the vmethods anyway the point is moot.
Oh, if it's crashing when you're reading "name", that's a different problem. Since name is the first field, struct-type vs. class-type is probably what's causing it. You have to use struct-type in 0.43.03 or class-type in 0.43.05; flipping those will cause crashes.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on November 05, 2019, 07:40:37 am
so it's possible to add more retired or ruin sites to the embark menu through the old_sites, old_site_x, old_site_y though this did lead to a weird bit of the game having me reclaim a non ruin site than unretiring it, this does open the door to just playing an adventurer's camp site in fort mode
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on November 07, 2019, 07:17:13 am
How make incubator workshop by DFhack?
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on November 07, 2019, 08:34:33 am
This could work (based on me being able to make unfertilized eggs hatch in a tick and Rumrusher's similar experiments with vermin eggs): Have a job that takes an egg, and outputs that same egg.

Then add onJobCompleted hook that gets the output item (egg), then sets egg's incubation_counter to 100800 (or 100799, both work) and .egg_flags fertile to true.

I guess you might and could add a initialization hook to make sure the job takes long time to complete (though thirst/hunger/sleep prevents you normally from using whole three months it'd take normally).

(PS: Also noticed it's possible to add some tags to offspring on egg item, such as marking them for butchering the moment they're born. Neat!)
Title: Re: DFHack 0.44.12-r2
Post by: Warmist on November 07, 2019, 09:46:04 am
This could work (based on me being able to make unfertilized eggs hatch in a tick and Rumrusher's similar experiments with vermin eggs): Have a job that takes an egg, and outputs that same egg.

Then add onJobCompleted hook that gets the output item (egg), then sets egg's incubation_counter to 100800 (or 100799, both work) and .egg_flags fertile to true.

I guess you might and could add a initialization hook to make sure the job takes long time to complete (though thirst/hunger/sleep prevents you normally from using whole three months it'd take normally).

(PS: Also noticed it's possible to add some tags to offspring on egg item, such as marking them for butchering the moment they're born. Neat!)

You can go one step forward and the job would only add the egg to the building (and maybe disable jobs on that building?) and then speed up the egg incubation with periodic kicks to the timer. Though not sure what will happen if egg inside the building hatches :D
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on November 07, 2019, 10:02:39 am
I expect same thing when egg inside nestbox hatches.

If using periodic kicks, might want to make it a magma workshop and forbid the egg.

Though should try to get the most basic form working first.
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on November 07, 2019, 10:05:30 am
This could work (based on me being able to make unfertilized eggs hatch in a tick and Rumrusher's similar experiments with vermin eggs): Have a job that takes an egg, and outputs that same egg.

Then add onJobCompleted hook that gets the output item (egg), then sets egg's incubation_counter to 100800 (or 100799, both work) and .egg_flags fertile to true.

I guess you might and could add a initialization hook to make sure the job takes long time to complete (though thirst/hunger/sleep prevents you normally from using whole three months it'd take normally).

(PS: Also noticed it's possible to add some tags to offspring on egg item, such as marking them for butchering the moment they're born. Neat!)

You can go one step forward and the job would only add the egg to the building (and maybe disable jobs on that building?) and then speed up the egg incubation with periodic kicks to the timer. Though not sure what will happen if egg inside the building hatches :D

having done this in adventure mode you can instantly construct a unit this way
(http://www.truimagz.com/host/rumrusher/folder7/one-way-to-spawn-units.gif)
though this also has the affect of making vermin creatures so one could hatch a fairy and ...after one raise the baby they would be able to talk and do jobs.
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on November 07, 2019, 10:20:38 am
I not understand how write scripts. And currently not need long incubation period. Just reaction that make creatures from eggs (bigger stack - more creatures) will be fine too. But this one reaction must work with all types of eggs, I want breed kobolds and harpies (and antmen, amphibian men, reptile men and serpent men). 
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on November 07, 2019, 09:55:14 pm
so far uhh doing this in fort mode is tricky as advfort breaks the item requirements needed for eggs and it seems like The eggs slowly incubate themselves in adventure mode.
Title: Re: DFHack 0.44.12-r2
Post by: DerMeister on November 08, 2019, 03:42:45 am
How see ID of dead unit? I want back someone to live.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on November 08, 2019, 12:25:59 pm
"lua print(unit.id)" with the unit selected (e.g. in the dead units tab)

If you're using the full-heal script, you can just run it with the unit selected. You don't need to find the ID first.
Title: Re: DFHack 0.44.12-r2
Post by: Tentacle Demon on November 17, 2019, 07:43:03 am
Exist any way to tranfrorm tamed/dead vermin into creature vermin?
Title: Re: DFHack 0.44.12-r2
Post by: Roses on November 20, 2019, 05:10:18 pm
Is it possible to add a new folder search location to DFHack so that it will looks for scripts in raw/blah/ in addition to raw/scripts/?
Title: Re: DFHack 0.44.12-r2
Post by: mwanafalsafa on November 23, 2019, 09:25:00 am
I've tried using the "emigration enable" script on a couple fortresses. It immediately causes a huge portion of my dwarves to emigrate. This includes many with negative stress, but not certain dwarves with extremely high stress (on one occasion the exact dwarf I was hoping would emigrate). I assume this is not how the script is intended to work.

I have DF v0.44.12 and DF v0.44.12-r2. I am running on Mac OS X, so I entered the command in the OS Terminal window that pops up whenever I start the game. The only thing I've modded outside of what DFHack does is edit the raw for Stress Vulnerability of dwarves, making them less vulnerable to stress. (I did this before generating the worlds.)

Any ideas?
Title: Re: DFHack 0.44.12-r2
Post by: Warmist on November 25, 2019, 07:20:15 am
Is it possible to add a new folder search location to DFHack so that it will looks for scripts in raw/blah/ in addition to raw/scripts/?
Yes: search for "addScriptPath" in https://dfhack.readthedocs.io/en/stable/docs/Lua%20API.html
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on November 25, 2019, 10:25:14 am
dfhack-config/script-paths.txt is a more permanent place to set that up, if you prefer.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on November 25, 2019, 10:47:03 am
Is it possible to add a new folder search location to DFHack so that it will looks for scripts in raw/blah/ in addition to raw/scripts/?
Yes: search for "addScriptPath" in https://dfhack.readthedocs.io/en/stable/docs/Lua%20API.html

dfhack-config/script-paths.txt is a more permanent place to set that up, if you prefer.

Thank you both!
Title: Re: DFHack 0.44.12-r2
Post by: doublestrafe on December 01, 2019, 03:58:52 pm
I've got the formerly reanimated corpse of one of my dwarves being carried back and forth from a refuse stockpile in the kitchen to his tomb...which happens to be in the middle of the inn. For reasons. My still-alive dwarves don't seem to be super happy about it.

This is described in this bug (http://www.bay12games.com/dwarves/mantisbt/view.php?id=10396), in which the reporter says:

Quote from: PatrikLundell
Using DFHack to change the "dead_dwarf" flag on the skeleton in a52's save causes the corpse to be laid to rest in the coffin...

I don't see anything in the DFHack documentation that explains how one would even begin to go about changing an arbitrary flag on an item. Can someone point me in the right direction please?
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on December 01, 2019, 05:00:17 pm
Typing gui/gm-editor into console with the item selected in DF is one possible right direction.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on December 01, 2019, 06:24:59 pm
As Fleeting Frames indicated, the comment skipped a fair number of "obvious" steps:
- gui/gm-editor is the typical tool to use, with is "obvious" to everyone hacking around, but not to those who just want to solve their problems.
- Once you start the tool with the right item (i.e. the corpse) selected, you have to navigate the data structure, which is reasonably easy to get used to. I don't have DF active at the moment, but there typically is one or more elements called flags (or some variation of that), and in one of these (going down a level and back up if it was the wrong set of flags) you'd find the flag you're looking at, and you can then flip it (boolean flags flip between true and false, which value fields bring up a box that allows you to select/type a new value).
Title: Re: DFHack 0.44.12-r2
Post by: doublestrafe on December 02, 2019, 01:03:04 am
That's what I needed. Lokum has been laid to rest. Thanks!
Title: Re: DFHack 0.44.12-r2
Post by: Clément on December 03, 2019, 08:26:02 am
I am trying to import df structures in ghidra, using codegen_c_hdr.pl from df_misc (https://github.com/jjyg/df_misc). But I have issues with nested types, for example: unitst.job use type unit_action::T_job instead of unitst::T_job, leading to invalid offsets. Has anyone successfully imported df structures into ghidra and how?
Title: Re: DFHack 0.44.12-r2
Post by: fortunawhisk on December 04, 2019, 11:11:06 pm
Does anyone know what's required to force dwarves to take a bath? I'm trying to write a script that recreates the conditions on the dwarf that makes them decide to take a bath as their next job. Unfortunately, I can't seem to find whatever is required. It doesn't appear to be unit's bodypart grime number, spatter, spatter content, etc. I also tried just directly forcing them to do a "Clean Self" job, but that got really complicated by having to find well and soap stockpile coordinates.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on December 06, 2019, 01:28:13 pm
Is it possible to add faux virtual methods to objects with lua. For instance if you have an item (say from item = df.item.find(#)) you can do item:getSubtype(), but I'd like to be able to be able to do something like item:getRandomAttack().

I have it working so far where I create a new metatable that has all the functions I want, but I can't seem to get inheritance to work for df structures. Below is a small excerpt of the ITEM metatable I am using at the moment (it's called by just doing item = ITEM(#))

Code: [Select]
ITEM = {}
ITEM.__index = ITEM
setmetatable(ITEM, {
__call = function (cls, ...)
local self = setmetatable({},cls)
self:_init(...)
return self
end,
})
function ITEM:_init(item)
if tonumber(item) then item = df.item.find(tonumber(item)) end
self.id = item.id
end

function ITEM:getRandomAttack()
local item = df.item.find(self.id)
local rand = dfhack.random.new()
local weights = {}
weights[0] = 0
local n = 0
for _,attacks in pairs(item.subtype.attacks) do
if attacks.edged then x = 100 else x = 1 end
n = n + 1
weights[n] = weights[n-1] + x
end
local pick = rand:random(weights[n])
for i = 1,n do
if pick >= weights[i-1] and pick < weights[i] then attack = i-1 break end
end
if not attack then attack = n end
return item.subtype.attacks[attack]
end
Title: Re: DFHack 0.44.12-r2
Post by: Warmist on December 07, 2019, 04:00:53 am
Is it possible to add faux virtual methods to objects with lua. For instance if you have an item (say from item = df.item.find(#)) you can do item:getSubtype(), but I'd like to be able to be able to do something like item:getRandomAttack().

I have it working so far where I create a new metatable that has all the functions I want, but I can't seem to get inheritance to work for df structures. Below is a small excerpt of the ITEM metatable I am using at the moment (it's called by just doing item = ITEM(#))
<...>

This seems to work, but i'm pretty sure there is still a better way:
Code: [Select]
ITEM = defclass(ITEM)
function ITEM:__index(key)
if rawget(self,key) then return rawget(self,key) end
if rawget(ITEM,key) then return rawget(ITEM,key) end
local item = df.item.find(self.id)
return item[key]
end
function ITEM:init(item)
--??
if tonumber(item) then item = df.item.find(tonumber(item)) end
self.id = item.id
end

function ITEM:getRandomAttack()
local item = df.item.find(self.id)
local rand = dfhack.random.new()
local weights = {}
weights[0] = 0
local n = 0
for _,attacks in pairs(item.subtype.attacks) do
if attacks.edged then x = 100 else x = 1 end
n = n + 1
weights[n] = weights[n-1] + x
end
local pick = rand:random(weights[n])
for i = 1,n do
if pick >= weights[i-1] and pick < weights[i] then attack = i-1 break end
end
if not attack then attack = n end
return item.subtype.attacks[attack]
end

local it=ITEM(0)
printall(it:getRandomAttack())
Title: Re: DFHack 0.44.12-r2
Post by: Rumrusher on December 07, 2019, 08:36:59 pm
well worked on a script on what if you could dodge farther distances which in turn became what if you can just dodge and attack in a way that kills the opponent setting you up to take on the next person.
 (http://www.truimagz.com/host/rumrusher/folder7/Dodge-attack.gif)
Code: (Dodgeport.lua) [Select]
local D=df.global.world.units.active[0]
local Xi=df.global.cursor.x
local Yi=df.global.cursor.y
local Zi=df.global.cursor.z
for k,v in pairs(D.actions) do
if v.type == 1 then
v.data.attack.attack_velocity=910000009
v.data.attack.attack_accuracy=100
v.data.attack.timer1=1
v.data.attack.timer2=0
end
if v.type == 11 then
v.data.dodge.timer= 0
v.data.dodge.x2=Xi
v.data.dodge.y2=Yi
v.data.dodge.z2=Zi

end
end

the result turn out to be dodge teleporting next to someone doesn't give you your turn back and you're just placing yourself in position for an attack, also teleporting behind someone would lead to the person doing a 180 and hit you if they have an attack primed.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on December 10, 2019, 01:22:34 pm
Is it possible to add faux virtual methods to objects with lua. For instance if you have an item (say from item = df.item.find(#)) you can do item:getSubtype(), but I'd like to be able to be able to do something like item:getRandomAttack().

I have it working so far where I create a new metatable that has all the functions I want, but I can't seem to get inheritance to work for df structures. Below is a small excerpt of the ITEM metatable I am using at the moment (it's called by just doing item = ITEM(#))
<...>

This seems to work, but i'm pretty sure there is still a better way:

Thanks, this works perfectly. It's odd that I never got it to work, I swear I tried something similar, but I probably messed up the rawget().

well worked on a script on what if you could dodge farther distances which in turn became what if you can just dodge and attack in a way that kills the opponent setting you up to take on the next person.

<snip>

the result turn out to be dodge teleporting next to someone doesn't give you your turn back and you're just placing yourself in position for an attack, also teleporting behind someone would lead to the person doing a 180 and hit you if they have an attack primed.

Commenting on the 180 turn thing, I've found that once an attack is queued up with an action and everything has been calculated, nothing can stop it (short of modifying the action itself). I was even getting attacks to land when the attacker was many squares away from the target by teleporting right next to them, triggering the attack and then teleporting away, all in one tick. That *may* have been fixed though as the code I had that did that no longer seems to work 100% of the time, but it doesn't surprise me at all about the 180 degree turn.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on December 11, 2019, 12:44:06 am
This seems to work, but i'm pretty sure there is still a better way:
Code: [Select]
ITEM = defclass(ITEM)
function ITEM:__index(key)
if rawget(self,key) then return rawget(self,key) end
if rawget(ITEM,key) then return rawget(ITEM,key) end
local item = df.item.find(self.id)
return item[key]
end
One suggestion to improve efficiency: set "self._item = df.item.find(id)" in the constructor (init()) and then look up fields on that in __index() (i.e. replace the last two lines with "return self._item[key]").
Of course, this will crash if the underlying item is ever deleted from DF, so be aware of that (I'm not sure what the use case is; if you're accessing item fields infrequently, then calling find() every time should be fine).
Title: Re: DFHack 0.44.12-r2
Post by: methylatedspirit on December 11, 2019, 09:23:09 pm
I'm trying to run DF 0.44.12 with DFhack on my phone using Exagear. It crashes whenever I try to load a world (Arena loads fine, though). It doesn't crash when I copy the installation to my computer, which probably means it's a problem with Exagear or something.

Spoiler: stderr.log (click to show/hide)

Spoiler: stdout.log (click to show/hide)


Unfortunately, I can't get the details.
Title: Re: DFHack 0.44.12-r2
Post by: Roses on December 11, 2019, 10:15:49 pm
This seems to work, but i'm pretty sure there is still a better way:
Code: [Select]
ITEM = defclass(ITEM)
function ITEM:__index(key)
if rawget(self,key) then return rawget(self,key) end
if rawget(ITEM,key) then return rawget(ITEM,key) end
local item = df.item.find(self.id)
return item[key]
end
One suggestion to improve efficiency: set "self._item = df.item.find(id)" in the constructor (init()) and then look up fields on that in __index() (i.e. replace the last two lines with "return self._item[key]").
Of course, this will crash if the underlying item is ever deleted from DF, so be aware of that (I'm not sure what the use case is; if you're accessing item fields infrequently, then calling find() every time should be fine).

The main use case is essentially to replace any dfhack.item.find() calls in my scripts with this class, which should allow me to do everything I am doing now, plus give me access to any extra functions and such I write. I will be doing this same thing for units, buildings, entities, etc... so that all of my scripts use the same base class, which should make it easier to update any scripts if information moves around as I will only have to update the class definition stuff.

I don't expect there to be frequent calls or for it to ever try and access a deleted item. But I will make sure to keep that in mind. Thank you
Title: Re: DFHack 0.44.12-r2
Post by: 520farmer on December 12, 2019, 08:54:51 pm
I'm trying to install dfhack 0.34.11-r3 with dwarf fortress 34.11 on an old old old IBM thinkpad that will only support 32-bit ubuntu mate and i cannot get it to run. The main goal for me is to try and get dwarf therapist or something similar working. I've gone through ever thing i can find online to fix it, please, send help!!
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on December 13, 2019, 12:20:14 am
A quick search of "starter pack 34.11" gives this thing on dffd: http://dffd.bay12games.com/file.php?id=8990

Search for linux 34.11 additionally gives http://dffd.bay12games.com/file.php?id=8692 and http://dffd.bay12games.com/file.php?id=6702

Haven't tested though, but did these not work for you?
Title: Re: DFHack 0.44.12-r2
Post by: feelotraveller on December 13, 2019, 09:24:31 pm
I'm trying to install dfhack 0.34.11-r3 with dwarf fortress 34.11 on an old old old IBM thinkpad that will only support 32-bit ubuntu mate and i cannot get it to run. The main goal for me is to try and get dwarf therapist or something similar working. I've gone through ever thing i can find online to fix it, please, send help!!

In terms of files I'd use the originals since the links are still available (haven't confirmed downloads myself)

DF: http://www.bay12games.com/dwarves/df_34_11_linux.tar.bz2 (http://www.bay12games.com/dwarves/df_34_11_linux.tar.bz2)
DFHack: https://github.com/DFHack/dfhack/releases/download/0.34.11-r3/dfhack-0.34.11-r3-Linux.tar.gz (https://github.com/DFHack/dfhack/releases/download/0.34.11-r3/dfhack-0.34.11-r3-Linux.tar.gz)

After unpacking and copying the dfhack files across to the df folder open up a terminal in the location of the 'dfhack' file and try to run it - ./dfhack - should be some feedback if it doesn't work.  Best background reference is http://dwarffortresswiki.org/index.php/DF2014:Installation (http://dwarffortresswiki.org/index.php/DF2014:Installation) which covers most likely df issues.

Beyond that it is up to you to provide some more information than 'it doesn't work'  ;).
Title: Re: DFHack 0.44.12-r2
Post by: Enemy post on December 15, 2019, 10:43:00 pm
I'm trying to track down and kill the world's last werebeast. It's not in its lair though, and I can't find it in the surrounding wilderness. Is there a command I can use to locate it?
Title: Re: DFHack 0.44.12-r2
Post by: Roses on December 17, 2019, 04:53:06 pm
I'm looking to generate a list of positions based on certain criteria when the fortress map is loaded (e.g. all surface positions, all cavern positions, etc...). Is there a more efficient way to go about it than just brute forcing through each tile? I can get all the surface tiles fairly quickly by starting at the top in a corner, going down in z until I go underground, and then starting from that z in the next tile over and iterating through all the x,y pairs that way. But getting all cavern positions would require going through potentially millions of tiles, which I'd rather avoid if possible.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on December 17, 2019, 05:41:00 pm
I'm trying to run DF 0.44.12 with DFhack on my phone using Exagear. It crashes whenever I try to load a world (Arena loads fine, though). It doesn't crash when I copy the installation to my computer, which probably means it's a problem with Exagear or something.

--snip--
Invoking: warn-starving
I would try removing or renaming "onLoad.init-example" and see if that helps.

I'm trying to install dfhack 0.34.11-r3 with dwarf fortress 34.11 on an old old old IBM thinkpad that will only support 32-bit ubuntu mate and i cannot get it to run. The main goal for me is to try and get dwarf therapist or something similar working. I've gone through ever thing i can find online to fix it, please, send help!!
If the suggestions above don't help, we'll need more details to help you. For example: what instructions have you followed? What files did you download (links would help) and where did you put them?

I'm trying to track down and kill the world's last werebeast. It's not in its lair though, and I can't find it in the surrounding wilderness. Is there a command I can use to locate it?
Not as far as I know. You could probably find it through lua (or gui/gm-editor) but I'm not familiar enough with adventurer mode to know exactly where to look.

I'm looking to generate a list of positions based on certain criteria when the fortress map is loaded (e.g. all surface positions, all cavern positions, etc...). Is there a more efficient way to go about it than just brute forcing through each tile? I can get all the surface tiles fairly quickly by starting at the top in a corner, going down in z until I go underground, and then starting from that z in the next tile over and iterating through all the x,y pairs that way. But getting all cavern positions would require going through potentially millions of tiles, which I'd rather avoid if possible.
Not that I know of. That's why things like "reveal" are implemented in C++.
Title: Re: DFHack 0.44.12-r2
Post by: Enemy post on December 17, 2019, 05:47:49 pm
Thanks.
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on December 17, 2019, 09:12:14 pm
I'm looking to generate a list of positions based on certain criteria when the fortress map is loaded (e.g. all surface positions, all cavern positions, etc...). Is there a more efficient way to go about it than just brute forcing through each tile? I can get all the surface tiles fairly quickly by starting at the top in a corner, going down in z until I go underground, and then starting from that z in the next tile over and iterating through all the x,y pairs that way. But getting all cavern positions would require going through potentially millions of tiles, which I'd rather avoid if possible.

There's some data structures that might be relevant:

df.global.features.map_features[#].layer, although I'm not sure what the number means.
df.global.world.map.map_block_columns.cave_columns[#][#].item - anon_2 seems like it could be z-level, looking at values and comparing them with embark's (internal) surface zlevel.

It was a while ago,but iirc when I deleted the bottom/right edges in 1x1 embark, I only got wildlife from top and left edges, so might be relevant for areas the game considers pathable.

PS: Also, it's faster to use dfhack.maps.getTileFlags(x,y) than block.designation[x%16][y%16]. Though ultimately it seems it's about the number of calls; recently managed to cut down time taken by 20ish% just by replacing text .. tostring(number) with text .. number in a bit of code when dealing with maps.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on December 18, 2019, 06:24:15 am
I'm looking to generate a list of positions based on certain criteria when the fortress map is loaded (e.g. all surface positions, all cavern positions, etc...). Is there a more efficient way to go about it than just brute forcing through each tile? I can get all the surface tiles fairly quickly by starting at the top in a corner, going down in z until I go underground, and then starting from that z in the next tile over and iterating through all the x,y pairs that way. But getting all cavern positions would require going through potentially millions of tiles, which I'd rather avoid if possible.

There's some data structures that might be relevant:

df.global.features.map_features
  • .layer, although I'm not sure what the number means.

:
Layer typically indicates whether it's Surface, Cavern 1, Cavern 2, Cavern 3, Magma Sea or none of those (if it's a specific feature, such as e.g. a volcano/magma pipe, or a candy spike, etc.). However, that's not useful for Roses' purposes, as it doesn't specify the exact extents of the corresponding Layer feature (this is probably generated from seeds when the in-game tiles are generated).
Title: Re: DFHack 0.44.12-r2
Post by: Fleeting Frames on December 18, 2019, 11:24:10 am
Exact extents would be nice, but if you can know an appropriate z-level then checking nearby tiles ought to be much quicker than every z-level.

A quick check shows that finding and printing 156k (~67,85 embark tiles) marked priority 4 downstair designations takes me about 11? secs without doing anything else with them, and under 2 secs without printing, and under half a second for something nonexistent (like priority 5 downstairs), while iterating through all blocks (though probably could be rewritten to be more efficient as it was done before I knew about .maps functions being faster - in any case, it was 11870 blocks total on map). Even the first value is probably acceptable if annoying if it's just on load, and could be potentialy spread out via dfhack.timeout.
Title: Re: DFHack 0.44.12-r2
Post by: Atomic Chicken on December 18, 2019, 12:01:14 pm
Tile blocks within a cavern refer to the relevant cavern feature via their global_feature field. So you can assess 16*16 tiles all at once by going through the list of blocks checking for this reference. Then process the tiles within each valid block as required. I did something similar for  this script (https://github.com/DFHack/scripts/pull/110/files).
Title: Re: DFHack 0.44.12-r2
Post by: Roses on December 18, 2019, 03:37:57 pm
Thanks all for the responses. It sounds like I can whip something together that does most of what I want using blocks and layers (at least very roughly), but to implement what I want exactly as I was envisioning it probably requires writing a c++ plugin, which I may do at some point, but this was more of a "hey, this would be cool" thought than a "I need this" thought so for now I will try to implement something that's very rough that only takes a few seconds at load.
Title: Re: DFHack 0.44.12-r2
Post by: Romeofalling on December 19, 2019, 03:45:07 pm
I'm running DF on an OSX system, and it was installed via the Lazy Mac Pack. I can't seem to access the GUI version of Workflow, nor find documentation for the hot key in the DFHack docs. Was this feature removed?
Title: Re: DFHack 0.44.12-r2
Post by: Bumber on December 20, 2019, 03:24:05 am
I'm running DF on an OSX system, and it was installed via the Lazy Mac Pack. I can't seem to access the GUI version of Workflow, nor find documentation for the hot key in the DFHack docs. Was this feature removed?

It hasn't been removed for dfhack (https://dfhack.readthedocs.io/en/stable/docs/_auto/gui.html#gui-workflow). Search for "workflow" in your dfhack.init or ask around the Lazy Mac Pack thread. The default is alt-w, but IDK what the LMP has it set to.
Title: Re: DFHack 0.44.12-r2
Post by: Romeofalling on December 20, 2019, 03:37:28 am
Thanks!

Totally different question: Are there any more robust collections of stockpile settings for DFHack/stocksettings? One that's been updated to include all the new items from the last year or two?

And if not, where/how would I submit an updated collection of stockpiles?
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on December 22, 2019, 01:40:32 am
I'm running DF on an OSX system, and it was installed via the Lazy Mac Pack. I can't seem to access the GUI version of Workflow, nor find documentation for the hot key in the DFHack docs. Was this feature removed?
Note that this shortcut was removed for a few DFHack versions. Make sure you're using a recent DF version - some Mac packs are still on 0.44.05, but the most recent DF version is 0.44.12. (I think the workflow shortcut should be enabled in all versions of DFHack for 0.44, though - if it's not working for you, see Bumber's advice.)

Totally different question: Are there any more robust collections of stockpile settings for DFHack/stocksettings? One that's been updated to include all the new items from the last year or two?
More robust than what? I couldn't find an existing collection on the wiki, and I'm not aware of one that comes with DFHack.
Title: Re: DFHack 0.44.12-r2
Post by: Romeofalling on December 24, 2019, 10:02:36 pm
I'm running DF on an OSX system, and it was installed via the Lazy Mac Pack. I can't seem to access the GUI version of Workflow, nor find documentation for the hot key in the DFHack docs. Was this feature removed?
Note that this shortcut was removed for a few DFHack versions. Make sure you're using a recent DF version - some Mac packs are still on 0.44.05, but the most recent DF version is 0.44.12. (I think the workflow shortcut should be enabled in all versions of DFHack for 0.44, though - if it's not working for you, see Bumber's advice.)

I'm running 0.44.12, and dfhack.init seems to be set up correctly: ...had commented out the commands. Problem fixed! Thanks, Bumber!

Totally different question: Are there any more robust collections of stockpile settings for DFHack/stocksettings? One that's been updated to include all the new items from the last year or two?
More robust than what? I couldn't find an existing collection on the wiki, and I'm not aware of one that comes with DFHack.

The LNP and LMP both come with a Gems stockpile setting group (Rough Ornamental. Rough Rare, Rough Semiprecious), a Magma Safe group (different Stone and Ore settings), and a MechGuides group.

So since I'm going to go through the trouble of making [Workshop]_Input stockpiles for everything, how do I submit those for inclusion into df-hack?
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on December 27, 2019, 05:38:48 pm
The LNP and LMP both come with a Gems stockpile setting group (Rough Ornamental. Rough Rare, Rough Semiprecious), a Magma Safe group (different Stone and Ore settings), and a MechGuides group.

So since I'm going to go through the trouble of making [Workshop]_Input stockpiles for everything, how do I submit those for inclusion into df-hack?

Submitting a pull request on GitHub is probably easiest for us. However, this case is a bit tricky because we currently don't distribute any stockpile profiles with DFHack, so there's not really a place in the repository to put them (but we can figure out how to address that and make sure they get bundled properly). They're also binary files, from what I remember, which tend not to play very well with Git - if they're large, we might just distribute them separately.

As a side thought, if it's possible to generate these profiles programmatically, it might be more maintainable to have the plugin generate them (although built-in workshops are hardcoded, and reactions for custom workshops can be pretty complicated... so your solution is probably easiest for now).
Title: Re: DFHack 0.44.12-r2
Post by: Romeofalling on December 27, 2019, 06:24:08 pm
Is it out of scope for DFHack? Perhaps I should submit it to LNP instead? I feel like a true DFHack implementation would involve adding those options to the GUI, which is the opposite quantity of work than I want to generate. :)

I've successfully opened the stockpile files in a text editor, so unless my understanding of what Smultron is capable of doing is deeply outdated, they're text files.

The stockpile files I've created since my last post are industry based rather than workshop based, so you can, for example, keep one Quern & stockpile adjacent to your Dyers Workshop and another one next to the Kitchen.
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on December 27, 2019, 08:29:27 pm
I feel like a true DFHack implementation would involve adding those options to the GUI, which is the opposite quantity of work than I want to generate. :)
Well, they'd show up in the existing list of profiles in the GUI, wouldn't they? I think that's good enough - yeah, making more complicated options would take some work.

Quote
The stockpile files I've created since my last post are industry based rather than workshop based, so you can, for example, keep one Quern & stockpile adjacent to your Dyers Workshop and another one next to the Kitchen.
Ah, so those would be somewhat harder to generate programmatically than I was thinking. As long as they're compatible with vanilla, I'm fine with bundling them with DFHack (although it's possible that some mods would break compatibility with them). LNP authors would probably also be willing to include them if you reached out (most of those threads are in the DF General Discussion forum).

Quote
I've successfully opened the stockpile files in a text editor, so unless my understanding of what Smultron is capable of doing is deeply outdated, they're text files.
I double-checked a .dfstock file I have laying around from 0.43.05 (it's using protobuf's default format, I think, and I don't think the plugin has changed its format since then). It's a "binary" file in the sense that it has a lot of non-printable and non-ASCII characters, but it also uses ASCII for a lot of stuff. So you'd probably be able to read these files in a text editor and get an idea of what they're doing, but editing them would probably break them. I don't know how Git would handle this exactly, but the (basic) file I have isn't very big, so I'm not too concerned about that anymore.
Title: Re: DFHack 0.44.12-r2
Post by: darkhog on January 04, 2020, 07:42:48 am
I tested it on Mac too.

path:
Applications\Älgstubben\Bäverdammen\Järvträsket\Lazy Mac Pack v0.44.12 dfhack-r2/Dwarf Fortress 0.44.12/

I can confirm that LNP won´t launch when there are common Swedish words in the path.

This may point to lack of unicode path support. Try it with other national characters (cyrillic, Polish letters, japanese moonrunes...) - if they don't work either we'll know the answer. I've seen similar stuff happen wit other software as well, particularly an old version of ToonBoom (not sure if it still happens in the new versions) - these programs simply don't get unicode in paths and they try to interpret two byte unicode sequences as two ascii characters, then freak out when they encounter characters that shouldn't be there (such as control codes belonging in the 0x00-0x1F range).
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on January 04, 2020, 04:37:40 pm
I tested it on Mac too.

path:
Applications\Älgstubben\Bäverdammen\Järvträsket\Lazy Mac Pack v0.44.12 dfhack-r2/Dwarf Fortress 0.44.12/

I can confirm that LNP won´t launch when there are common Swedish words in the path.

This may point to lack of unicode path support. Try it with other national characters (cyrillic, Polish letters, japanese moonrunes...) - if they don't work either we'll know the answer. I've seen similar stuff happen wit other software as well, particularly an old version of ToonBoom (not sure if it still happens in the new versions) - these programs simply don't get unicode in paths and they try to interpret two byte unicode sequences as two ascii characters, then freak out when they encounter characters that shouldn't be there (such as control codes belonging in the 0x00-0x1F range).

If you're referring to PyLNP, that's written in Python, and Unicode handling in Python is particularly easy to do wrong (especially in Python 2, which PyLNP is using). Looks like this is a known PyLNP issue and unrelated to DFHack: http://www.bay12forums.com/smf/index.php?topic=140808.msg8041496#msg8041496 (but if DFHack itself can't handle Unicode characters, do let us know!)
Title: Re: DFHack 0.44.12-r2
Post by: darkhog on January 04, 2020, 06:29:18 pm
Can someone make a plugin that would automatically back up saves to certain location (and would be called upon save completion)? My goal is to make it backup in my file server that is barely being used right now.
//edit: @lethosor the earlier discussion suggested that it happens outside of PyLNP as well and if python's unicode handling is so terrible, isn't it a sign it would be a good idea to rewrite PyLNP in another, better language or at least upgrade the code to Python 3?
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on January 04, 2020, 09:04:50 pm
//edit: @lethosor the earlier discussion suggested that it happens outside of PyLNP as well and if python's unicode handling is so terrible, isn't it a sign it would be a good idea to rewrite PyLNP in another, better language or at least upgrade the code to Python 3?
That bug is specific to the Ruby plugin. Also, paths are being printed incorrectly in the console on Windows, but (at least from my understanding) other features like plugins and Lua scripts worked.

Per the discussion I linked to, updating PyLNP to use Python 3 is planned.
Title: Re: DFHack 0.44.12-r2
Post by: Mim on January 05, 2020, 07:14:28 pm
How do I run a DFHack script with a syndrome?
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on January 06, 2020, 06:49:32 am
How do I run a DFHack script with a syndrome?
That seems like a very incomplete question. I, at least, fails to understand what the question actually is:
- Is the question one of how to run scripts in general (but then, where does the syndrome fit in)?
- Is it a question of how to use a particular, but unspecified, script?
- Is it about how to write scripts that involve syndromes in unspecified ways?

To have a decent chance to get a useful answer you probably have provide enough info.
Title: Re: DFHack 0.44.12-r2
Post by: Sulter on January 06, 2020, 07:25:22 am
Hello all.
I've made a script, which will locate historical figures, and I want to hear whatever there is any interest in having it added to DFHack.

You can input a historical figure name (or part of name, in either translated or native language). And it will print out its position.
This is whatever the historical figure is traveling the world, spawned in a site, or in a site but not spawned yet. If the historical figure is inside the same site as you (like in a town, fortress, lair etc.), it will tell you its local site coordinates (as well as your own).
The script is obviously most useful in adv-mode.

Examples:
(https://i.imgur.com/uUS2Dh0.png)

(https://i.imgur.com/i4WSn6h.png)

(https://i.imgur.com/daaQPts.png)


I'm trying to track down and kill the world's last werebeast. It's not in its lair though, and I can't find it in the surrounding wilderness. Is there a command I can use to locate it?
Well there is now :)
Title: Re: DFHack 0.44.12-r2
Post by: Mim on January 06, 2020, 10:37:37 am
How do I run a DFHack script with a syndrome?
That seems like a very incomplete question. I, at least, fails to understand what the question actually is:
- Is the question one of how to run scripts in general (but then, where does the syndrome fit in)?
- Is it a question of how to use a particular, but unspecified, script?
- Is it about how to write scripts that involve syndromes in unspecified ways?

To have a decent chance to get a useful answer you probably have provide enough info.
Whoops! I should clarify. I am asking how to run a script in general (anything in the scripts folder) upon the triggering of a syndrome.
Title: Re: DFHack 0.44.12-r2
Post by: Atomic Chicken on January 06, 2020, 07:07:51 pm
Whoops! I should clarify. I am asking how to run a script in general (anything in the scripts folder) upon the triggering of a syndrome.

Easily done using modtools/syndrome-trigger (https://dfhack.readthedocs.io/en/stable/docs/_auto/modtools.html#modtools-syndrome-trigger) as follows:
Code: [Select]
modtools/syndrome-trigger -syndrome SYN_NAME -command [ script ]You could place this in an onLoad.init file in your raw folder to have it run automatically whenever the game is loaded.
Title: Re: DFHack 0.44.12-r2
Post by: Atkana on January 09, 2020, 02:50:10 am
Hello all.
I've made a script, which will locate historical figures, and I want to hear whatever there is any interest in having it added to DFHack.
[snip]
Well if nobody's commenting on this I'd at least like to mention that I'd like a copy of that script if you have it available somewhere :P
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on January 09, 2020, 05:02:00 am
Hello all.
I've made a script, which will locate historical figures, and I want to hear whatever there is any interest in having it added to DFHack.
[snip]
Well if nobody's commenting on this I'd at least like to mention that I'd like a copy of that script if you have it available somewhere :P
Sulter provided it here: http://www.bay12forums.com/smf/index.php?topic=175307.0 (http://www.bay12forums.com/smf/index.php?topic=175307.0)
Title: Re: DFHack 0.44.12-r2
Post by: darkhog on January 10, 2020, 05:57:18 pm
Could you add an option of "just save" to ESC menu that would save the game, but then return to the fort/adventure (i.e. saving without quitting)?
Title: Re: DFHack 0.44.12-r2
Post by: Bumber on January 10, 2020, 08:37:21 pm
Could you add an option of "just save" to ESC menu that would save the game, but then return to the fort/adventure (i.e. saving without quitting)?
The default dfhack.init lets you quicksave with Alt+Ctrl+S.
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on January 11, 2020, 06:33:53 am
Could you add an option of "just save" to ESC menu that would save the game, but then return to the fort/adventure (i.e. saving without quitting)?
The default dfhack.init lets you quicksave with Alt+Ctrl+S.
And you can type "quicksave" into the DFHack console as well.

Something completely different: I've failed to find where DF stores info about what growths each plant sports (leaves, fruit, etc.). The plant_raw contains info of what it CAN have (and when), but shrubs without usable structure parts can have their growths picked while leaving the structure part behind (e.g. bitter melon vines left behind when gathering the leaves and the melons), and fruit pickers climb ladders to pick fruit from different parts of trees, so the info obviously resides somewhere. The logical place (at least according to my logic) would be a reference in the plant structure (the one in the vector that's used to hold info of every plant on the map), but it has no specific info on shrubs, and only generic info for trees (branches, twigs, roots). Can someone point me in the right direction, or hasn't that info been mapped yet?
Title: Re: DFHack 0.44.12-r2
Post by: therahedwig on January 11, 2020, 11:27:35 am
It should be mapped, I distinctly recall making graphics for stonesense that rely on SS knowing where the growths are in DF, but I can't tell you where that would be...
Title: Re: DFHack 0.44.12-r2
Post by: Roses on January 11, 2020, 11:32:17 am
Could you add an option of "just save" to ESC menu that would save the game, but then return to the fort/adventure (i.e. saving without quitting)?
The default dfhack.init lets you quicksave with Alt+Ctrl+S.
And you can type "quicksave" into the DFHack console as well.

Something completely different: I've failed to find where DF stores info about what growths each plant sports (leaves, fruit, etc.). The plant_raw contains info of what it CAN have (and when), but shrubs without usable structure parts can have their growths picked while leaving the structure part behind (e.g. bitter melon vines left behind when gathering the leaves and the melons), and fruit pickers climb ladders to pick fruit from different parts of trees, so the info obviously resides somewhere. The logical place (at least according to my logic) would be a reference in the plant structure (the one in the vector that's used to hold info of every plant on the map), but it has no specific info on shrubs, and only generic info for trees (branches, twigs, roots). Can someone point me in the right direction, or hasn't that info been mapped yet?

IIRC there is the df.global.world.plants.all table (which I believe is what you are referencing in your post) and then there are further details in the map block and columns. I'm not sure if the information you want is there, but it could be
Title: Re: DFHack 0.44.12-r2
Post by: PatrikLundell on January 11, 2020, 12:32:20 pm
Thanks to therahedwig and Roses for the answers.

Regarding growths: Unless I'm blind (which cannot be ruled out) it's not in df.global.world.plants.all (which is what I referred to), and I've failed to find anything useful in the map blocks or columns. The closest thing is a list of references to plants present in the block, but that's just the same type as in the vector (and, I assume, are the same objects as those in the vector). There's also a vector of items on those tiles, but growths don't become items until they've been collected (I counted the number of bitter lemons in the item list [10] with a script, and that matched the number on the stocks screen, but that's far less than the 50-60 plants designated for gathering).

I tried to take a quick look at Stonesense (searching for "growth"), and it looks to me that growths are added based on whether the plant_raw data shows that the time is right for the growths, rather than whether the growths are actually there (I guess users of Stonesense could confirm whether a tree stripped of fruit looks different from a neighbor that hasn't been designated for fruit gathering). The Stonesense code also uses the data that specifies where growths should appear (trunk, branch, etc.), from the plant_raws, coupled with the generic tree info in the plant vector object that specifies where branches, etc. of each tree are located, so if there's a branch there and the tree species has a growth that grows on branches and the time is right growth tile processing is performed.
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on January 19, 2020, 01:23:51 am
It has been far too long, but we finally have a new release up for 0.44.12!
https://github.com/DFHack/dfhack/releases/tag/0.44.12-r3

Thanks to everyone who helped out with this, including the 12 (!) new contributors.

Looking at Toady's recent posts about a new DF release coming soon, this will probably be the last release for 0.44.12, and the last stable release for a while.
Title: Re: DFHack 0.44.12-r3
Post by: Roses on January 19, 2020, 01:30:14 pm
It has been far too long, but we finally have a new release up for 0.44.12!
https://github.com/DFHack/dfhack/releases/tag/0.44.12-r3

Thanks to everyone who helped out with this, including the 12 (!) new contributors.

Looking at Toady's recent posts about a new DF release coming soon, this will probably be the last release for 0.44.12, and the last stable release for a while.

Oooh boy... questions time!

1. I am digging the assign-X scripts, I have something very similar in my set of scripts, but I would obviously prefer to use the ones in the default package. My only question is speed. Is there much (if any) overhead in calling one of the assign-X scripts using the dfhack.script_environment() system?

2. Could we get some information on the new Persistence module and how it works? I switched from using the persistent tables to a global table that gets saved to a JSON file whenever the game saves and loads from the JSON file whenever the game loads (I was doing a lot with them and it was faster to go through global tables than the old persistent tables). It seems like the new system is using JSON files, but I am just wondering how it all works.

3. I'll probably have a bunch of questions about the persistence stuff, are there any scripts currently included in the package that use the new system (or is it the same syntax as the old one, with ._children and such)?
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on January 19, 2020, 02:13:32 pm
1. I am digging the assign-X scripts, I have something very similar in my set of scripts, but I would obviously prefer to use the ones in the default package. My only question is speed. Is there much (if any) overhead in calling one of the assign-X scripts using the dfhack.script_environment() system?
Nope, it's actually the same system that running Lua scripts uses under the hood. I'd recommend reqscript() instead because it does some extra safety checks (and it's shorter) but either should work. As long as you only import the script once (i.e. not every time you call a function), it shouldn't be noticeable.

Quote
2. Could we get some information on the new Persistence module and how it works? I switched from using the persistent tables to a global table that gets saved to a JSON file whenever the game saves and loads from the JSON file whenever the game loads (I was doing a lot with them and it was faster to go through global tables than the old persistent tables). It seems like the new system is using JSON files, but I am just wondering how it all works.

3. I'll probably have a bunch of questions about the persistence stuff, are there any scripts currently included in the package that use the new system (or is it the same syntax as the old one, with ._children and such)?
From Lua it shouldn't be any different. It'll be stored differently under the hood, though. C++ plugins have access to a bit of extra stuff, but I expect persist-table and whatever else is available to Lua to continue to work normally. The functions in the World module are now just wrappers around the Persistence module.
Title: Re: DFHack 0.44.12-r3
Post by: 9joseph9 on January 20, 2020, 09:27:49 am
I've got trouble trying to use the set-orientation command. If anybody could help, I'd be real grateful.
 Here's the error log
Invoking: set-orientation view
C:\Users\Me\Downloads\df_44_12_win\hack\lua\utils.lua:610: error parsing arg 1: view
stack traceback:
   [C]: in function 'error'
   C:\Users\Me\Downloads\df_44_12_win\hack\lua\utils.lua:610: in function 'utils.processArgs'
   ...\Downloads\df_44_12_win/hack/scripts/set-orientation.lua:189: in global 'main'
   ...\Downloads\df_44_12_win/hack/scripts/set-orientation.lua:265: in local 'script_code'
   C:\Users\Me\Downloads\df_44_12_win\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
   (...tail calls...)
Title: Re: DFHack 0.44.12-r3
Post by: Atkana on January 20, 2020, 09:46:27 am
I've got trouble trying to use the set-orientation command. If anybody could help, I'd be real grateful.
 Here's the error log
Invoking: set-orientation view
C:\Users\Me\Downloads\df_44_12_win\hack\lua\utils.lua:610: error parsing arg 1: view
stack traceback:
   [C]: in function 'error'
   C:\Users\Me\Downloads\df_44_12_win\hack\lua\utils.lua:610: in function 'utils.processArgs'
   ...\Downloads\df_44_12_win/hack/scripts/set-orientation.lua:189: in global 'main'
   ...\Downloads\df_44_12_win/hack/scripts/set-orientation.lua:265: in local 'script_code'
   C:\Users\Me\Downloads\df_44_12_win\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
   (...tail calls...)
Make sure to begin the arguments with a -, so in this example set-orientation -view. I don't think I mentioned the necessity for doing that in any of the scripts I added, and this is one where I neglected to include an example usage so that's understandable. It's kinda the standard formatting for dfhack script arguments, but I don't know how many scripts actually use it over their own methods :b
Title: Re: DFHack 0.44.12-r3
Post by: 9joseph9 on January 20, 2020, 10:29:39 am
I've got trouble trying to use the set-orientation command. If anybody could help, I'd be real grateful.
 Here's the error log
Invoking: set-orientation view
C:\Users\Me\Downloads\df_44_12_win\hack\lua\utils.lua:610: error parsing arg 1: view
stack traceback:
   [C]: in function 'error'
   C:\Users\Me\Downloads\df_44_12_win\hack\lua\utils.lua:610: in function 'utils.processArgs'
   ...\Downloads\df_44_12_win/hack/scripts/set-orientation.lua:189: in global 'main'
   ...\Downloads\df_44_12_win/hack/scripts/set-orientation.lua:265: in local 'script_code'
   C:\Users\Me\Downloads\df_44_12_win\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
   (...tail calls...)
Make sure to begin the arguments with a -, so in this example set-orientation -view. I don't think I mentioned the necessity for doing that in any of the scripts I added, and this is one where I neglected to include an example usage so that's understandable. It's kinda the standard formatting for dfhack script arguments, but I don't know how many scripts actually use it over their own methods :b

It worked! Thanks a ton, man. I'm not verse in DFHack so alot of common sense stuff escapes me. If you have anything you'd like to have drawn, I'd be more than happy to make you one as my thanks.
Title: Re: DFHack 0.44.12-r2
Post by: PeridexisErrant on January 22, 2020, 07:40:40 am
The stockpile files I've created since my last post are industry based rather than workshop based, ...
LNP authors would probably also be willing to include them if you reached out (most of those threads are in the DF General Discussion forum).
Can confirm, I'd be happy to ship these  :D
Title: Re: DFHack 0.44.12-r3
Post by: Roses on January 24, 2020, 12:19:05 pm
Couple questions;

1. Does the defclass() support overloading operators? I know with "normal" metatables you can put functions for things like __add, __eq, etc... Just making sure that I can still do that.

2. I'm trying to decide how to organize my scripts and functions collection and am wondering what some of my options might be. Currently I am adding expanding on some of the current df-structures objects by using classes. As an example, I have a UNIT class which adds functions like UNIT:makeProjectile(vx,vy,vz) which turns the unit into a projectile. Now for the question, my current thoughts for organization are 1) Putting the defclass and all the functions associated with that class in their own file, or 2) put the defclass for each of the different classes in a single file with descriptions of each class, and then put the functions for the class in a seperate file, 3) group classes and functions into categories and create files for each category. Is there a "best" way to handle this in terms of performance (I'm guessing #3)? If they are all roughly equal I was thinking of using #2 because it would be the easiest to read and create help files for. Is there another way that I'm not thinking of?

3. I noticed in some of the scripts in the repository there is the line
Code: [Select]
if not dfhack_flags.module then
    main(...)
end
Just wanted to make sure I understand this, if a script gets called from the command line or with run_script/run_command it will call main, if it gets access with reqscript() it will not call main, correct?
Title: Re: DFHack 0.44.12-r3
Post by: Kat on January 24, 2020, 09:03:13 pm
Hi people :) great seeing DFHack still being updated.

Anyway I have something I am struggling with in my game, and I am wondering if any of you have ever come across this, and what solution if any, you found.

So, I have temples in my fort. I want to assign at least one performer to each of the temples.

I can find citizens with dancing skills etc via Dwarf Therapist. But... I can't tell which gods those citizens worship, except by viewing their unit info. So I can't easily tell which citizens to assign to which temples.

is it possible, or would it be possible in future, to display or sort the available performers, so that you can find ones that worship the god of the temple ?

Here's a picture of what I mean:
https://i.imgur.com/F6K2uNt.png
Title: Re: DFHack 0.44.12-r3
Post by: PatrikLundell on January 25, 2020, 05:10:43 am
@Kat: It's possible to write a DFHack script that does what you want, but you'd likely have to (learn to, if needed) write it yourself, given that you'd need a fair bit of luck to find someone else who shares your particular needs and who's interested in writing it.
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on January 25, 2020, 03:39:09 pm
Couple questions;

1. Does the defclass() support overloading operators? I know with "normal" metatables you can put functions for things like __add, __eq, etc... Just making sure that I can still do that.
Looks like it:
Code: [Select]
[lua]# x = defclass()
[lua]# function x:__add() print('adding') end
[lua]# print(x() + 2)
adding
nil

Quote
2. I'm trying to decide how to organize my scripts and functions collection and am wondering what some of my options might be. Currently I am adding expanding on some of the current df-structures objects by using classes. As an example, I have a UNIT class which adds functions like UNIT:makeProjectile(vx,vy,vz) which turns the unit into a projectile. Now for the question, my current thoughts for organization are 1) Putting the defclass and all the functions associated with that class in their own file, or 2) put the defclass for each of the different classes in a single file with descriptions of each class, and then put the functions for the class in a seperate file, 3) group classes and functions into categories and create files for each category. Is there a "best" way to handle this in terms of performance (I'm guessing #3)? If they are all roughly equal I was thinking of using #2 because it would be the easiest to read and create help files for. Is there another way that I'm not thinking of?
I wouldn't split up the defclass and function definitions - defclass is really just one line. Personally, I would go with #1, unless you have a lot of classes, and then #3 might be a bit faster. One disadvantage of #2 is that if you forget to include the file that defines all the functions, you'll just end up with a class that does nothing.

Quote
3. I noticed in some of the scripts in the repository there is the line
Code: [Select]
if not dfhack_flags.module then
    main(...)
end
Just wanted to make sure I understand this, if a script gets called from the command line or with run_script/run_command it will call main, if it gets access with reqscript() it will not call main, correct?
Yup! It's the same as the "moduleMode" check you might see in some scripts, but that's deprecated.
Title: Re: DFHack 0.44.12-r3
Post by: Rumrusher on January 28, 2020, 04:08:53 am
just checking dfhack r3 and oh finding out units just have caste flags in their enemy section is a deep life savor. this opens up for like getting creatures and reanimated beings that don't talk to uhh talk.
Title: Re: DFHack 0.44.12-r3
Post by: darkhog on January 29, 2020, 12:12:03 pm
Any timetable on how soon dfhack can be updated for the new version?
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on January 29, 2020, 12:52:09 pm
We can't make any guarantees - we don't know exactly how much has changed that concerns us yet. It will probably be at least a week before we have something partially usable, but even then it will likely be unstable for a while longer.

If anyone's interested, we do have an IRC channel where you can see more up-to-date activity (see the first post for details - just please don't bug us there with questions about when DFHack will be updated).
Title: Re: DFHack 0.44.12-r3
Post by: jecowa on January 29, 2020, 11:17:12 pm
Thanks for keeping us apprised.
Title: Re: DFHack 0.44.12-r3
Post by: PatrikLundell on January 30, 2020, 03:53:54 am
I wouldn't mind if a post was made in this thread when the first cut of the (re)mapping has been made so "amateur" mapping activities can be started.
Title: Re: DFHack 0.44.12-r3
Post by: HungThir on January 30, 2020, 05:32:55 am
is it possible to build dfhack usefully in an msys2 shell?  i think this is an abi compatibility question, i don't really understand how the mingw/msys2 posix/win64 translation layers work or to what extent stuff built with the mingw toolchain is able to interact with native win64 apps.  i'm a linux/posix programmer, and would like to be able to contribute, but i don't run linux on my gaming pc, i don't run dwarf fortress on the work laptop, and i don't know thing one about the windows toolchains, really

i could potentially figure out (and document) how to build it under msys2, if i knew before sinking time into it that it would actually work. but my current understanding is that it wouldn't work. am i right?
Title: Re: DFHack 0.44.12-r3
Post by: Clément on January 30, 2020, 05:54:00 am
The issue is that MSVC and GCC C++ ABIs are incompatible (there is no standard C++ ABI). It is not about posix/win32 translation. You are stuck with whatever compiler Toady uses.
Title: Re: DFHack 0.44.12-r3
Post by: HungThir on January 30, 2020, 05:57:42 am
The issue is that MSVC and GCC C++ ABIs are incompatible (there is no standard C++ ABI). It is not about posix/win32 translation. You are stuck with whatever compiler Toady uses.

gotcha, cheers
Title: Re: DFHack 0.44.12-r3
Post by: Quietust on January 30, 2020, 07:03:29 am
The issue is that MSVC and GCC C++ ABIs are incompatible (there is no standard C++ ABI). It is not about posix/win32 translation. You are stuck with whatever compiler Toady uses.
My understanding was that it was mainly a runtime library issue, specifically the memory layouts of std::string/std::vector and the fact that DF's heap is managed by the VC++ 2015 runtime library (which MingW does not use).
Title: Re: DFHack 0.44.12-r3
Post by: Clément on January 30, 2020, 08:54:40 am
By C++ ABI, I meant both compiler and standard library ABIs. On the compiler side you'll get issues with name mangling, class layout, call conventions, ...
Title: Re: DFHack 0.44.12-r3
Post by: Roses on January 31, 2020, 10:56:51 am
Is there a way to check if a dfhack structure has a specific member? What I mean is that if I have a normal table I can do "if rawget(table,key) then..." or "if table[key] then..." but trying the first one results in the error that a table is expected but got userdata, and the later gives the error that the field is not found.
Title: Re: DFHack 0.44.12-r3
Post by: PatrikLundell on January 31, 2020, 11:56:25 am
The method I've used to detect if a field is present (to determine if the DF version is the current one or an older one) is to iterate over the fields with "pairs". If it's present I'll eventually get a match.

Code: [Select]
  --  Backwards compatibility detection
  -- 
  local river_type_updated = false
  if true then  --  To get the temporary variable's context expire
    local river = df.world_river:new()
    for i, k in pairs (river) do
      if i == "flow" then
        river_type_updated = true
        break
      end
    end
    river:delete ()
  end
Title: Re: DFHack 0.44.12-r3
Post by: Roses on January 31, 2020, 12:01:52 pm
The method I've used to detect if a field is present (to determine if the DF version is the current one or an older one) is to iterate over the fields with "pairs". If it's present I'll eventually get a match.

Code: [Select]
  --  Backwards compatibility detection
  -- 
  local river_type_updated = false
  if true then  --  To get the temporary variable's context expire
    local river = df.world_river:new()
    for i, k in pairs (river) do
      if i == "flow" then
        river_type_updated = true
        break
      end
    end
    river:delete ()
  end

That is my current method as well, was just wondering if there was a more efficient way, but if not thats ok, the lists usually aren't too long.
Title: Re: DFHack 0.44.12-r3
Post by: PatrikLundell on January 31, 2020, 04:47:47 pm
It ought to be possible to use the operations that catch thrown exceptions, whatever they're called (I'm not sure I've ever used them, but I think you can find them in the Lua API document). However, iteration is good enough for my cases, and I do it only once for each mutable field.
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on January 31, 2020, 06:00:33 pm
Lua calls them errors (and they're not DFHack-specific, although DFHack adds some extra information to them). pcall (and its variants) will let you catch errors, although the API is a bit messy compared to some languages. Iterating over keys is probably fine, and you could use a per-type cache of field names if performance becomes an issue.
Title: Re: DFHack 0.44.12-r3
Post by: Fleeting Frames on January 31, 2020, 06:34:49 pm
@Roses: iirc last time lethosor mentioned pcall is less efficient than normal call but more efficient than iterating pairs each time.

While a table of possible values would be even better, memoization would ensure only using pairs once:

Code: [Select]
function getFlag(dfvalue, key)
    -- Utility function for safely requesting info from df data
    if not dfvalue or not key then return nil end --pairs crash prevention
    flagtypetable = flagtypetable or {} --memoization so it doesn't iterate through the dfvalue if we've already checked that type of value for given flag
    if flagtypetable[dfvalue._type] and flagtypetable[dfvalue._type][key] then return dfvalue[key] end
    if flagtypetable[dfvalue._type] and flagtypetable[dfvalue._type][key]==false then return nil end
    if not flagtypetable[dfvalue._type] then flagtypetable[dfvalue._type] = {} end
    for akey, avalue in pairs(dfvalue) do
        if akey == key then
            flagtypetable[dfvalue._type][key] = true
            return dfvalue[akey]
        end
    end
    flagtypetable[dfvalue._type][key] = false
end
Title: Re: DFHack 0.44.12-r3
Post by: HungThir on January 31, 2020, 07:39:15 pm
what key binding do people mostly use for toggling gui/gm-editor? it doesn't seem to have a default?
Title: Re: DFHack 0.44.12-r3
Post by: PatrikLundell on February 01, 2020, 04:42:46 am
what key binding do people mostly use for toggling gui/gm-editor? it doesn't seem to have a default?
Typing "gui/gm-editor" into the console window. Most of the time I need a parameter to open the structure I want to look at anyway.
Title: Re: DFHack 0.44.12-r3
Post by: Roses on February 06, 2020, 10:18:45 am
Question about the upcoming release since I don't remember how it worked for DF 44, new field structures won't necessarily have names that go with them right? I mean, we don't have names associated with structures from Toady, we have to figure it out, correct?
Title: Re: DFHack 0.44.12-r3
Post by: PatrikLundell on February 06, 2020, 12:13:28 pm
Yes, fields located but not identified are typically named unk_offset, where "offset" is the offset in hex from the start of the structure (there are a lot of those that never have been identified reaching back a very long time).
As far as I understand, Toady provides some offset of some major structures, but the rest is for the community to figure out.
Title: Re: DFHack 0.44.12-r3
Post by: Abadrausar on February 06, 2020, 04:21:35 pm
Possible bug in dfhack r3 in digfort exporting a multilevel nanofort
Code: [Select]
blueprint 47 47 30 nfort
digfort nfort-dig.csv
Faults to
Spoiler (click to show/hide)
however the csv file seems well formed (however Quickfort takes it without problem)
Spoiler (click to show/hide)
So maybe the sentinel over the y axis or dimension is incorrect
Code: [Select]
blueprint 48 48 30 nfort
digfort nfort-dig.csv

faults instead to
Spoiler (click to show/hide)
Looking at the ruby code it seems there are three problems (in my very misinformed opinion):
1-) it counts each occurrence of the semantic empty lines (in relation to designations)
Code: (nfort-dig.csv) [Select]
#dig
 , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,#
from the csv into the variable max_y when clearly it should not. (see point 3 final part)
2-) The line
Code: [Select]
if x < 0 or y < 0 or x+max_x >= map.x_count or y+max_y >= map.y_countshould be instead
Code: [Select]
if x < 0 or y < 0 or x+max_x > map.x_count or y+max_y > map.y_countbecause we could only have an problem if the dimensions of the blueprint are bigger than those of the map, never if they are the same. Even when the blueprint dimensions are bigger than those of the map; maybe a better implementation than raising an exception before any work is done would be to stamp the part of the blueprint that effectively can be fit into the map and print a warning about the number of rows and/or lines not stamped to inform the user. More work done before trapping, more debug aware and in the worst case, the user can always delete the designations if they were not what he intended.
3-) The line
Code: [Select]
        max_x = x if x > max_x and not t.empty?test correctly for semantic empty cells but
Code: [Select]
    max_y = y if y > max_y does not take into account the semantic empty lines that we have identified that exist (example: #dig, ...), we must remember the fact that any border of the map (in X or Y) is by definition undesignable hence semantically empty in any case with respect to designations, that is, in any map the TOP and BOTTOM lines of the map are undesignable... Hope this helps to identify the issue.

I have tried to find a solution but I dont know Ruby any more than to have a general idea of what is happening, so any kind soul with the required Ruby expertise to catch the problem will be most welcome ;)
Code: (digfort.rb) [Select]
# designate an area based on a '.csv' plan
=begin

digfort
=======
A script to designate an area for digging according to a plan in csv format.

This script, inspired from quickfort, can designate an area for digging.
Your plan should be stored in a .csv file like this::

    # this is a comment
    d;d;u;d;d;skip this tile;d
    d;d;d;i

Available tile shapes are named after the 'dig' menu shortcuts:
``d`` for dig, ``u`` for upstairs, ``j`` downstairs, ``i`` updown,
``h`` channel, ``r`` upward ramp, ``x`` remove designation.
Unrecognized characters are ignored (eg the 'skip this tile' in the sample).

Empty lines and data after a ``#`` are ignored as comments.
To skip a row in your design, use a single ``;``.

One comment in the file may contain the phrase ``start(3,5)``. It is interpreted
as an offset for the pattern: instead of starting at the cursor, it will start
3 tiles left and 5 tiles up from the cursor.

additionally a comment can have a < for a rise in z level and a > for drop in z.

The script takes the plan filename, starting from the root df folder (where
``Dwarf Fortress.exe`` is found).

=end

fname = $script_args[0].to_s

if not $script_args[0] then
    puts "  Usage: digfort <plan filename>"
    throw :script_finished
end
if not fname[-4..-1] == ".csv" then
    puts "  The plan file must be in .csv format."
    throw :script_finished
end
if not File.file?(fname) then
    puts "  The specified file does not exist."
    throw :script_finished
end

planfile = File.read(fname)

if df.cursor.x == -30000
    puts "place the game cursor to the top-left corner of the design and retry"
    throw :script_finished
end

offset = [0, 0]
tiles = []
max_x = 0
max_y = 0
y = 0
planfile.each_line { |l|
    if l =~ /#.*start\s*\(\s*(-?\d+)\s*[,;]\s*(-?\d+)/
        raise "Error: multiple start() comments" if offset != [0, 0]
        offset = [$1.to_i, $2.to_i]
    end
    if l.chomp == '#<'
        l = '<'
        y = 0
    end

    if l.chomp == '#>'
        l = '>'
        y = 0
    end

    l = l.chomp.sub(/#.*/, '')
    next if l == ''
    x = 0
    tiles << l.split(/[;,]/).map { |t|
        t = t.strip
        x = x + 1
        max_x = x if x > max_x and not t.empty?
        (t[0] == '"') ? t[1..-2] : t
    }
    y = y + 1
    max_y = y if y > max_y
}

x = df.cursor.x - offset[0]
y = df.cursor.y - offset[1]
z = df.cursor.z
starty = y - 1

map = df.world.map

if x < 0 or y < 0 or x+max_x >= map.x_count or y+max_y >= map.y_count
    max_x = max_x + x + 1
    max_y = max_y + y + 1
    raise "Position would designate outside map limits. Selected limits are from (#{x+1}, #{y+1}) to (#{max_x},#{max_y})"
end

tiles.each { |line|
    next if line.empty? or line == ['']
    line.each { |tile|
        if tile.empty?
            x += 1
            next
        end
        t = df.map_tile_at(x, y, z)
        s = t.shape_basic
        case tile
        when 'd'; t.dig(:Default) if s == :Wall
        when 'u'; t.dig(:UpStair) if s == :Wall
        when 'j'; t.dig(:DownStair) if s == :Wall or s == :Floor
        when 'i'; t.dig(:UpDownStair) if s == :Wall
        when 'h'; t.dig(:Channel) if s == :Wall or s == :Floor
        when 'r'; t.dig(:Ramp) if s == :Wall
        when 'x'; t.dig(:No)
        when '<'; y=starty; z += 1
        when '>'; y=starty; z -= 1
        end
        x += 1
    }
    x = df.cursor.x - offset[0]
    y += 1
}

puts '  done'





PD: I have loved the new version with all those additional content especially the possibility of embarking in the caverns or even in the circus. Hope the team keeps all these good work :-*
Title: Re: DFHack 0.44.12-r3
Post by: vixeyrose on February 07, 2020, 11:13:05 am
not sure if this general question should go here or somewhere else.I figured I would try here because its based off information gathered with a script. I couldn't find an understandable answer. My question is, when I use "gui/unit-info-viewer" how do i interpret the size value? examples:

Puppy 'she appears to be about 1199:725 cubic decimeters in size

giant crab 'she appears to be about 545:988 cubic decimeters in size

and how does these numbers coincide with the size page on the wiki?
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on February 08, 2020, 07:51:44 pm
not sure if this general question should go here or somewhere else.I figured I would try here because its based off information gathered with a script. I couldn't find an understandable answer. My question is, when I use "gui/unit-info-viewer" how do i interpret the size value? examples:

Puppy 'she appears to be about 1199:725 cubic decimeters in size

giant crab 'she appears to be about 545:988 cubic decimeters in size

and how does these numbers coincide with the size page on the wiki?


I looked at the code here (https://github.com/DFHack/scripts/blob/2aee2e1666cea3db3630e02b415d72c75ce1f4de/gui/unit-info-viewer.lua#L741) - looks like the first number is related to strength and the second is related to agility. I'm not sure how this is related to size at all. Unfortunately, this dates back to the original version of the script added here (https://github.com/DFHack/scripts/commit/9ded4ff9210150370c4c6c2e7ef791ed965c66df), so it's difficult to say where this originated from. I personally think they're unrelated to size, though.


Possible bug in dfhack r3 in digfort exporting a multilevel nanofort
Curious, have you tried the version from 0.44.12-r2? digfort did change a bit between the two versions (to fix a similar issue) and I'm wondering if the fix broke your case.
Quote
2-) The line
Code: [Select]
if x < 0 or y < 0 or x+max_x >= map.x_count or y+max_y >= map.y_countshould be instead
Code: [Select]
if x < 0 or y < 0 or x+max_x > map.x_count or y+max_y > map.y_countbecause we could only have an problem if the dimensions of the blueprint are bigger than those of the map, never if they are the same.
I'm pretty sure the code as-is is correct - most things in DF, including the map, are 0-indexed, so while x_count is the number of things in the X dimension, the valid things range only from 0 to X-1.

Quote
3-) The line
Code: [Select]
        max_x = x if x > max_x and not t.empty?test correctly for semantic empty cells but
Code: [Select]
    max_y = y if y > max_y does not take into account the semantic empty lines that we have identified that exist (example: #dig, ...), we must remember the fact that any border of the map (in X or Y) is by definition undesignable hence semantically empty in any case with respect to designations, that is, in any map the TOP and BOTTOM lines of the map are undesignable... Hope this helps to identify the issue.
This does sound like it could be an issue to me. Does your fixed script work properly for you? (I wasn't sure if you meant your version didn't work at all, or if you weren't sure that it always worked.)
Title: Re: DFHack 0.44.12-r3
Post by: CyberianK on February 09, 2020, 06:19:09 am
is there any way to revert remove-stress command?

So set stress to 0 again or so?

also revflood does not work with constructed walls right? did not work here for me:
(https://i.imgur.com/SQ5BzUe.png)

edit: I used tiletypes painting and revflood after to hack the wall dont like different colors
Title: Re: DFHack 0.44.12-r3
Post by: feelotraveller on February 09, 2020, 02:34:36 pm
Interesting, didn't know that.  Can't comment about the intentions or logic of revflood.

A slightly labourious way to hide those tiles is to use the 'hidden' flag in tiletypes, from within tiletypes
Code: [Select]
paint hidden 1

Then run over each tile or brush area you want to hide.  It can be combined with other commands if you want.  paint hidden 0 should be the reverse (reveal) tile command from memory.
Title: Re: DFHack 0.44.12-r3
Post by: Flying Teasets on February 09, 2020, 04:53:20 pm
PTW
Title: Re: DFHack 0.44.12-r3
Post by: Bumber on February 09, 2020, 08:26:37 pm
I'm pretty sure revflood worked on constructions in past versions.
Title: Re: DFHack 0.44.12-r3
Post by: NikoKun on February 09, 2020, 11:18:05 pm
I'm pretty sure revflood worked on constructions in past versions.
revflood hasn't worked for me in ages. It's been broken for several versions now at least. I can't imagine what use it would be, if it didn't work on constructed walls, that's like it's only purpose. heh
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on February 09, 2020, 11:30:22 pm
I'm pretty sure revflood worked on constructions in past versions.
revflood hasn't worked for me in ages. It's been broken for several versions now at least. I can't imagine what use it would be, if it didn't work on constructed walls, that's like it's only purpose. heh
It worked for me just now in 0.47.02, and I don't recall seeing it broken before.
That said, its purpose is to replicate the vanilla DF reveal logic (e.g. when reclaiming a site), which ignores constructions last I checked, so it's working as intended. Its logic hasn't changed much since 2014, but maybe DF's has - if someone would like to test reclaiming a site with constructions, feel free to let us know if DF's behavior has changed.
Title: Re: DFHack 0.44.12-r3
Post by: Warmist on February 10, 2020, 03:41:00 am
I'm pretty sure revflood worked on constructions in past versions.
revflood hasn't worked for me in ages. It's been broken for several versions now at least. I can't imagine what use it would be, if it didn't work on constructed walls, that's like it's only purpose. heh
It worked for me just now in 0.47.02, and I don't recall seeing it broken before.
That said, its purpose is to replicate the vanilla DF reveal logic (e.g. when reclaiming a site), which ignores constructions last I checked, so it's working as intended. Its logic hasn't changed much since 2014, but maybe DF's has - if someone would like to test reclaiming a site with constructions, feel free to let us know if DF's behavior has changed.

The issue in making constructions hide stuff is that when you deconstruct them DF does not reveal the darkness thus making parts of map perma-hidden and broken. IIRC it was an issue some time ago.

Edit: namely this http://www.bay12games.com/dwarves/mantisbt/view.php?id=1871 (from sourcecode of reveal.cpp)
Title: Re: DFHack 0.44.12-r3
Post by: Fleeting Frames on February 10, 2020, 05:33:47 am
Interesting, didn't know that.  Can't comment about the intentions or logic of revflood.

A slightly labourious way to hide those tiles is to use the 'hidden' flag in tiletypes, from within tiletypes
Code: [Select]
paint hidden 1

Then run over each tile or brush area you want to hide.  It can be combined with other commands if you want.  paint hidden 0 should be the reverse (reveal) tile command from memory.

A faster option might be using unrevealdesignated (http://www.bay12forums.com/smf/index.php?topic=168607.0) for same thing.
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on February 10, 2020, 08:16:39 pm
A couple quick updates:
- There are automated builds available at https://buildmaster.lubar.me/applications/3/overview for anyone who would like to test those (click on the most recent build number, currently "#200210001", to get to it). Note that these really don't work well at the moment, but if people want to test and give us reports of what's broken, we do appreciate it. (Please remember to include the build number in any such reports)
- We have a special domain for documentation now: http://docs.dfhack.org/ (HTTPS may kick in eventually, we'll see). If anyone runs into a broken page or redirects that don't work, please let me know.
Title: Re: DFHack 0.44.12-r3
Post by: clinodev on February 10, 2020, 09:12:49 pm
These are 0.44.12 (as marked,) or 0.47.02, for clarity?
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on February 10, 2020, 09:46:52 pm
They're for 0.47.02 - they use the last Git tag, which makes sense for nightly builds once a DFHack version has been released for a specific DFHack version, but doesn't make as much sense before then :( (but any other DFHack build at this point would also report being a change after "0.44.12-r3", unless manually changed)
Title: Next DFHack version => 0.47 ?
Post by: dwarffun on February 11, 2020, 04:20:09 am
Hi,

just wanted so say "thanks for a great tool" and ask ... if there could be released some kind like a "minimal alpha" for 0.47.

Due to the new religious stuff my forts keep producing "fun" ... because of dwarfes not able to pray to one god or another god.
I have a population of 19 Dwarfs and a total of about 74(!) deities (not kidding). Dwarfes pray to 5 to 10 gods, and I can't keep up with providing temples to avoid tantrums.

Being able to at least run "remove stress" would be of great help :)
Title: Re: Next DFHack version => 0.47 ?
Post by: clinodev on February 11, 2020, 05:42:59 am
Hi,

just wanted so say "thanks for a great tool" and ask ... if there could be released some kind like a "minimal alpha" for 0.47.

Due to the new religious stuff my forts keep producing "fun" ... because of dwarfes not able to pray to one god or another god.
I have a population of 19 Dwarfs and a total of about 74(!) deities (not kidding). Dwarfes pray to 5 to 10 gods, and I can't keep up with providing temples to avoid tantrums.

Being able to at least run "remove stress" would be of great help :)

That's what the three messages right above yours are about, an early alpha for 0.47.02. I don't know if remove-stress is tested yet.
Title: Re: Next DFHack version => 0.47 ?
Post by: dwarffun on February 11, 2020, 08:56:54 am
That's what the three messages right above yours are about, an early alpha for 0.47.02. I don't know if remove-stress is tested yet.

Thanks man. My Grandson just tought an artifact (me) about build artifacts  :D
Finally I would say: remove_stress works as designed.
Title: Re: DFHack 0.44.12-r3
Post by: Psiclops on February 12, 2020, 12:12:57 am
Is there a way to download a win64 build already compiled? I only find the previous version.
Title: Re: DFHack 0.44.12-r3
Post by: HungThir on February 12, 2020, 04:06:48 am
They're for 0.47.02 - they use the last Git tag, which makes sense for nightly builds once a DFHack version has been released for a specific DFHack version, but doesn't make as much sense before then :( (but any other DFHack build at this point would also report being a change after "0.44.12-r3", unless manually changed)

when i have packages that introspect their version during build from the most recent git tag, and i need it to be distinctly "a pre-release build of the new version, not a patch on top of the old version", i throw down a tag with a name like [newversion]-alpha0 at the point in the tree where that switchover happened, even though i have no intention of publishing a "[newversion]-alpha0" release (and, later, when the release is ready, it gets tagged "[newversion]")

... aaaand i just went looking through the dfhack tags to see what your naming scheme is, and it looks like you've already done exactly this (https://github.com/DFHack/dfhack/releases/tag/0.47.02-alpha0), carry on  :D
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on February 12, 2020, 09:11:33 am
... aaaand i just went looking through the dfhack tags to see what your naming scheme is, and it looks like you've already done exactly this (https://github.com/DFHack/dfhack/releases/tag/0.47.02-alpha0), carry on  :D
Yup :) We haven't triggered a build yet since making that tag, though, so the most recent one on BuildMaster still reports "0.44.12-r3" at the moment. Hopefully that will change soon.

Is there a way to download a win64 build already compiled? I only find the previous version.
If you're looking for a test 0.47.02 build, see the 6 posts above yours (noting that it might still be labeled "0.44.12-r3" per this post, but if the build number starts with at least "2002", it should work for 0.47.02). Also note that these builds are very experimental and will probably crash.
Title: Re: DFHack 0.44.12-r3
Post by: Nopenope on February 12, 2020, 11:58:31 am
Are there any lines that may come in handy in your .dfhackrc? I was thinking of adding the following after reading the wiki on increasing framerate on Linux:

Spoiler (click to show/hide)
Title: Re: DFHack 0.44.12-r3
Post by: bloop_bleep on February 12, 2020, 07:37:15 pm
That, uh. May be inadvisable.

Setting nice priority to -20 has a high chance of freezing up your system since all of the important system processes would have very little time to do what they want to do. I would recommend setting it to around -5 or -10.
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on February 12, 2020, 10:32:59 pm
DF_POST_CMD only runs (https://github.com/DFHack/dfhack/blob/e9a295c788df1b32dff350951759ec82decdb0d0/package/linux/dfhack#L155) after DF exits, so that wouldn't do what you want anyway. The PRELOAD_LIB line probably works, though - you can verify that the library is in memory with "devel/lsmem".
Title: Re: DFHack 0.44.12-r3
Post by: Nopenope on February 13, 2020, 04:43:19 am
Alright I see. So I guess something within the dfhack script would be more appropriate? Like:

Spoiler (click to show/hide)

Quote
The PRELOAD_LIB line probably works, though - you can verify that the library is in memory with "devel/lsmem".

Can confirm that it is indeed in memory - though I still need to verify whether the FPS gain announced by the wiki is worth it.
Title: Re: DFHack 0.44.12-r3
Post by: PeridexisErrant on February 13, 2020, 07:33:23 am
Does anyone know what's happening with TwbT?  The repo hasn't updated in almost a year, which makes me nervous  :-\
Title: Re: DFHack 0.44.12-r3
Post by: Nopenope on February 13, 2020, 09:04:30 am
The cool kids have switched to this repo (https://github.com/nshcat/df-twbt/tree/04702) to build manually. I believe some people have uploaded builds for various platforms on DFFD as well.
Title: Re: DFHack 0.44.12-r3
Post by: jecowa on February 13, 2020, 05:17:19 pm
How was this TWBT update patch created? Does DFHack have a tool to generate TWBT memory codes?
Title: Re: DFHack 0.44.12-r3
Post by: Nopenope on February 13, 2020, 06:53:01 pm
I believe the repo's author kindly figured out the proper offsets for us. I don't know of any specific tool for TWBT in particular though.
Title: Re: DFHack 0.44.12-r3
Post by: Clément on February 13, 2020, 06:56:19 pm
You follow the instructions (https://github.com/mifki/df-twbt/blob/master/PATCHES.md).
Title: Re: DFHack 0.44.12-r3
Post by: jecowa on February 13, 2020, 08:11:28 pm
Thank you, I feel like a hacker now.

Spoiler (click to show/hide)
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on February 13, 2020, 11:53:41 pm
Does anyone know what's happening with TwbT?  The repo hasn't updated in almost a year, which makes me nervous  :-\
Related: https://github.com/mifki/df-twbt/pull/94#issuecomment-586006257
Title: Re: DFHack 0.44.12-r3
Post by: Zarathustra30 on February 14, 2020, 12:09:21 am
I just downloaded and installed 200213003 (0.47.02-alpha0-27-gf7f7bd7c?) on Windows 10 x86_64 and the `fix/loyaltycascade` command is returning "no loyalty cascade found".

http://dffd.bay12games.com/file.php?id=14798
Title: Re: DFHack 0.44.12-r3
Post by: PatrikLundell on February 14, 2020, 06:43:24 am
I just downloaded and installed 200213003 (0.47.02-alpha0-27-gf7f7bd7c?) on Windows 10 x86_64 and the `fix/loyaltycascade` command is returning "no loyalty cascade found".

http://dffd.bay12games.com/file.php?id=14798
As far as I can understand it is because whatever is causing the mess isn't a loyalty cascade, or at least not the type the script tries to fix. To me it looks like other odd kinds of hiddenly hostile behavior that has been reported for 0.47.X, as well as the older mess triggered by a sneaking artifact seeker group member getting into a fight while other members are inside the fortress.

There is a conflict with 17 on one side and 6 on the other, and it seems hacking that conflict entry to reduce the hostility level from no quarter to brawl on both sides caused it to end. I have no idea what such hacking would do in any other cases, though.

One of those involved in the conflict was married to a were (now dead) and the other had had a lover killed.
Title: Of interest for linux and OSX users that needs blueprints to play
Post by: Abadrausar on February 14, 2020, 10:02:46 am
01/29/2020 Released Dwarf Fortress 0.47.01
... automated builds available at https://buildmaster.lubar.me/applications/3/overview for anyone who would like to test those ...

Only 10 days later we have a workable DFHACK for testing. This community work is simply awesome!  :o
During the debugging of the new version of digfort I have tested that some other DFHACK parts works like intended (reveal, unreveal, liquids plugin, ls, mouse control, ...)

... Does your fixed script work properly for you? (I wasn't sure if you meant your version didn't work at all, or if you weren't sure that it always worked.)

Well at the time you asked, it do not even existed. So the modified script that works (for me at least) with DF 47.02 plus the most recent dfhack automatic build.
Code: (digfort.rb) [Select]
# designate an area based on a '.csv' plan
=begin

digfort
=======
A script to designate an area for digging according to a plan in csv format.

This script, inspired from quickfort, can designate an area for digging.
Your plan should be stored in a .csv file like this::

    # this is a comment
    d;d;u;d;d;skip this tile;d
    d;d;d;i

Available tile shapes are named after the 'dig' menu shortcuts:
``d`` for dig, ``u`` for upstairs, ``j`` downstairs, ``i`` updown,
``h`` channel, ``r`` upward ramp, ``x`` remove designation.
Unrecognized characters are ignored (eg the 'skip this tile' in the sample).

Empty lines and data after a ``#`` are ignored as comments.
To skip a row in your design, use a single ``;``.

One comment in the file may contain the phrase ``start(3,5)``. It is interpreted
as an offset for the pattern: instead of starting at the cursor, it will start
3 tiles left and 5 tiles up from the cursor.

additionally a comment can have a < for a rise in z level and a > for drop in z.

The script takes the plan filename, starting from the root df folder (where
``Dwarf Fortress.exe`` is found).

=end

fname = $script_args[0].to_s
map = df.world.map
Xsentinel = map.x_count - 1
Ysentinel = map.y_count - 1
Xstamp = false
Ystamp = false
if not $script_args[0] then
    puts "  Usage: digfort <plan filename>"
    throw :script_finished
end
if not fname[-4..-1] == ".csv" then
    puts "  The plan file must be in .csv format."
    throw :script_finished
end
if not File.file?(fname) then
    puts "  The specified file does not exist."
    throw :script_finished
end

planfile = File.read(fname)

if df.cursor.x == -30000
    puts "place the game cursor to the top-left corner of the design and retry"
    throw :script_finished
end

offset = [0, 0]
tiles = []
max_x = 0
max_y = 0
y = 0
planfile.each_line { |l|
    if l =~ /#.*start\s*\(\s*(-?\d+)\s*[,;]\s*(-?\d+)/
        raise "Error: multiple start() comments" if offset != [0, 0]
        offset = [$1.to_i, $2.to_i]
    end
    if l.chomp == '#<'
        l = '<'
        y = 0
    end

    if l.chomp == '#>'
        l = '>'
        y = 0
    end

    l = l.chomp.sub(/#.*/, '')
    next if l == ''
    x = 0
    tiles << l.split(/[;,]/).map { |t|
        t = t.strip
        if x < Xsentinel then x += 1 else x = Xsentinel ; Xstamp = true end
        max_x = x if x > max_x and not t.empty?
        (t[0] == '"') ? t[1..-2] : t
    }
    if y < Ysentinel then y += 1 else y = Ysentinel ; Xstamp = true end

}
 
x = df.cursor.x - offset[0]
y = df.cursor.y - offset[1]
z = df.cursor.z
starty = y - 1

if x < 0 or y < 0 or x+max_x >= map.x_count or y+max_y >= map.y_count
    max_x = max_x + x + 1
    max_y = max_y + y + 1
    raise "Position would designate outside map limits. Selected limits are from (#{x+1}, #{y+1}) to (#{max_x},#{max_y})"
end

tiles.each { |line|
    next if line.empty? or line == ['']
    line.each { |tile|
        if tile.empty?
            if x < Xsentinel then x += 1 else x = Xsentinel ; Xstamp = true end
            next
        end
        t = df.map_tile_at(x, y, z)
        s = t.shape_basic
        case tile
        when 'd'; t.dig(:Default) if s == :Wall
        when 'u'; t.dig(:UpStair) if s == :Wall
        when 'j'; t.dig(:DownStair) if s == :Wall or s == :Floor
        when 'i'; t.dig(:UpDownStair) if s == :Wall
        when 'h'; t.dig(:Channel) if s == :Wall or s == :Floor
        when 'r'; t.dig(:Ramp) if s == :Wall
        when 'x'; t.dig(:No)
        when '<'; y=starty; z += 1
        when '>'; y=starty; z -= 1
        end
        if x < Xsentinel then x += 1 else x = Xsentinel ; Xstamp = true end
    }
    x = df.cursor.x - offset[0]
    if y < Ysentinel then y += 1 else y = Ysentinel ; Ystamp = true end
}

if Xstamp or Ystamp then
  puts 'Warning: ' + (Xstamp ? 'the columns': '') + (Xstamp and Ystamp ? ' and ': '') + (Ystamp ? 'the rows' : '') + ' of the blueprint that overflow the designable area of the Dwarf Fortress embark have been ignored'
  puts '         if your blueprint X or Y dimension is close to that of the embark map, this warning is probably a false positive due to faulty logic in this script'
end

puts '  done'

Seeing that the available workforce is working frenetically; I had tasked myself to accomplish my own desired feature set:
... maybe a better implementation than raising an exception before any work is done would be to stamp the part of the blueprint that effectively can be fit into the map and print a warning about the number of rows and/or lines not stamped to inform the user. More work done before trapping, more debug aware and in the worst case, the user can always delete the designations if they were not what he intended...
The modified script as of now just work eagerly before trapping and has some new nice features:
- it stamps the safe part of blueprints that are same size than the embark. (with some more tinkering and 4 additional params partial stamping should be in the reachable zone)
- it warns when some lines and/or rows of the blueprint could had been ignored because the dimensions of the blueprint are bigger than the design-able zone of the embark.
- well formed multilevel nanoforts of 48x48 or 47x47 tiles faultily rejected by the previous script over an 1x1 embark are now possible.

I am ashamed to admit that I am almost unable to play without blueprints, at least if taking joy in it is an objective.

I am concerned with the fact that before tinkering with this script by harsh need, I did not know anything about Ruby, but were instead able to read and modify lua and C snippets.
I have only been able of correcting the bad effects of the flaw in the design, but not his source, that rest hidden for me in the part of Ruby that I do not understand :(

So it can be said that the new script recover more gracefully from his inherent flaw and does more work for the end user, without attacking the root problem sadly, for a 1x1 embark with 48x48 tiles the anterior script only worked when the blueprint has been taken of the area really design-able of at most 46x46 tiles.

I believe that the flaw comes because it counts the TOP and BOTTOM lines that represents areas non design-able of the blueprint in the current embark.

To resume the actual state of things, the bug has been conveniently hammered until it was almost unrecognizable but it has not been memorialized so that his ghost could potentially haunt us in the future. :D
Urist McAbadrausar, dabbler Ruby tinkerer, is ecstatic to have been able to tackle in a truly dwarvenly  :P manner a long standing problem, for the nanofort forgotten designers. (Linux and OSX do not have complete support for QuickFort)

Title: Re: DFHack 0.44.12-r3
Post by: lethosor on February 15, 2020, 11:32:46 am
We have a new page up for builds: https://dfhack.org/builds/
I hope to make it automatically update in the future, but this should at least be an easier link to pass around.

Well at the time you asked, it do not even existed. So the modified script that works (for me at least) with DF 47.02 plus the most recent dfhack automatic build.
Code: (digfort.rb) [Select]
# designate an area based on a '.csv' plan
=begin

digfort
=======
A script to designate an area for digging according to a plan in csv format.

This script, inspired from quickfort, can designate an area for digging.
Your plan should be stored in a .csv file like this::

    # this is a comment
    d;d;u;d;d;skip this tile;d
    d;d;d;i

Available tile shapes are named after the 'dig' menu shortcuts:
``d`` for dig, ``u`` for upstairs, ``j`` downstairs, ``i`` updown,
``h`` channel, ``r`` upward ramp, ``x`` remove designation.
Unrecognized characters are ignored (eg the 'skip this tile' in the sample).

Empty lines and data after a ``#`` are ignored as comments.
To skip a row in your design, use a single ``;``.

One comment in the file may contain the phrase ``start(3,5)``. It is interpreted
as an offset for the pattern: instead of starting at the cursor, it will start
3 tiles left and 5 tiles up from the cursor.

additionally a comment can have a < for a rise in z level and a > for drop in z.

The script takes the plan filename, starting from the root df folder (where
``Dwarf Fortress.exe`` is found).

=end

fname = $script_args[0].to_s
map = df.world.map
Xsentinel = map.x_count - 1
Ysentinel = map.y_count - 1
Xstamp = false
Ystamp = false
if not $script_args[0] then
    puts "  Usage: digfort <plan filename>"
    throw :script_finished
end
if not fname[-4..-1] == ".csv" then
    puts "  The plan file must be in .csv format."
    throw :script_finished
end
if not File.file?(fname) then
    puts "  The specified file does not exist."
    throw :script_finished
end

planfile = File.read(fname)

if df.cursor.x == -30000
    puts "place the game cursor to the top-left corner of the design and retry"
    throw :script_finished
end

offset = [0, 0]
tiles = []
max_x = 0
max_y = 0
y = 0
planfile.each_line { |l|
    if l =~ /#.*start\s*\(\s*(-?\d+)\s*[,;]\s*(-?\d+)/
        raise "Error: multiple start() comments" if offset != [0, 0]
        offset = [$1.to_i, $2.to_i]
    end
    if l.chomp == '#<'
        l = '<'
        y = 0
    end

    if l.chomp == '#>'
        l = '>'
        y = 0
    end

    l = l.chomp.sub(/#.*/, '')
    next if l == ''
    x = 0
    tiles << l.split(/[;,]/).map { |t|
        t = t.strip
        if x < Xsentinel then x += 1 else x = Xsentinel ; Xstamp = true end
        max_x = x if x > max_x and not t.empty?
        (t[0] == '"') ? t[1..-2] : t
    }
    if y < Ysentinel then y += 1 else y = Ysentinel ; Xstamp = true end

}
 
x = df.cursor.x - offset[0]
y = df.cursor.y - offset[1]
z = df.cursor.z
starty = y - 1

if x < 0 or y < 0 or x+max_x >= map.x_count or y+max_y >= map.y_count
    max_x = max_x + x + 1
    max_y = max_y + y + 1
    raise "Position would designate outside map limits. Selected limits are from (#{x+1}, #{y+1}) to (#{max_x},#{max_y})"
end

tiles.each { |line|
    next if line.empty? or line == ['']
    line.each { |tile|
        if tile.empty?
            if x < Xsentinel then x += 1 else x = Xsentinel ; Xstamp = true end
            next
        end
        t = df.map_tile_at(x, y, z)
        s = t.shape_basic
        case tile
        when 'd'; t.dig(:Default) if s == :Wall
        when 'u'; t.dig(:UpStair) if s == :Wall
        when 'j'; t.dig(:DownStair) if s == :Wall or s == :Floor
        when 'i'; t.dig(:UpDownStair) if s == :Wall
        when 'h'; t.dig(:Channel) if s == :Wall or s == :Floor
        when 'r'; t.dig(:Ramp) if s == :Wall
        when 'x'; t.dig(:No)
        when '<'; y=starty; z += 1
        when '>'; y=starty; z -= 1
        end
        if x < Xsentinel then x += 1 else x = Xsentinel ; Xstamp = true end
    }
    x = df.cursor.x - offset[0]
    if y < Ysentinel then y += 1 else y = Ysentinel ; Ystamp = true end
}

if Xstamp or Ystamp then
  puts 'Warning: ' + (Xstamp ? 'the columns': '') + (Xstamp and Ystamp ? ' and ': '') + (Ystamp ? 'the rows' : '') + ' of the blueprint that overflow the designable area of the Dwarf Fortress embark have been ignored'
  puts '         if your blueprint X or Y dimension is close to that of the embark map, this warning is probably a false positive due to faulty logic in this script'
end

puts '  done'
Thanks! I'll put this up in a GitHub issue so it doesn't get lost.
Title: Re: DFHack 0.44.12-r3
Post by: jecowa on February 15, 2020, 06:32:54 pm
So people wanting to try it out should probably ignore the ones labeled "Build" and instead download "Plugin" deployments?

I'm guessing "Rejected" just means that it wasn't chosen as a release, and "Active" means that it hasn't been rejected yet.

And the √ and (!) indicate whether or not it made it past the build stage into the plugin stage. So probably click the top-most build # with a √?

Spoiler: screenshot (click to show/hide)
Title: Re: DFHack 0.44.12-r3
Post by: Ziusudra on February 15, 2020, 06:48:03 pm
Deployment history can filter for that: https://buildmaster.lubar.me/applications/3/executions/history?StageName=Plugins&Status=S
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on February 15, 2020, 06:57:36 pm
I'm guessing "Rejected" just means that it wasn't chosen as a release, and "Active" means that it hasn't been rejected yet.
"Rejected" means there was an error or the build was cancelled. Some rejected builds still have some downloads available, e.g. https://buildmaster.lubar.me/applications/3/builds/build?buildId=6879 - that's because the Linux builds using GCC 4.8 are currently failing, but everything else is working. Ziusudra's link is useful, but it'll exclude newer builds in this case (this isn't typical, though).
Title: Re: DFHack 0.44.12-r3
Post by: Abadrausar on February 15, 2020, 07:42:19 pm
Thanks! I'll put this up in a GitHub issue so it doesn't get lost.
Thank you! (https://github.com/DFHack/dfhack/issues/1498)
Title: Re: DFHack 0.44.12-r3
Post by: xZippy on February 16, 2020, 11:58:19 pm
How far along is the updated DFHack? Like, percent wise.
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on February 17, 2020, 12:27:34 am
0.47.03 will probably delay it more, but hopefully not a lot more. It really depends on how many issues there are and how much time people have to fix them.
Title: Re: DFHack 0.44.12-r3
Post by: Iliithid on February 17, 2020, 10:40:47 am
The latest release (as of a few hours ago, I guess) crashes immediately on launching DF. The develop branch that was released in January did too. Not sure what changed, but something is interfering with the game launching properly. I'm using the 32-bit version of DF and Hack, for reference.
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on February 17, 2020, 11:17:43 am
The latest release (as of a few hours ago, I guess) crashes immediately on launching DF. The develop branch that was released in January did too. Not sure what changed, but something is interfering with the game launching properly. I'm using the 32-bit version of DF and Hack, for reference.
We need version numbers of both DF and DFHack to diagnose anything. (I'm also not sure what you mean by "the develop branch" - we released one official build for 0.44.12 in January, and several unstable nightly builds for 0.47.)
Title: Re: DFHack 0.44.12-r3
Post by: Iliithid on February 17, 2020, 04:01:31 pm
DF version 47.0.3 and DFHack 44.12 r-3, both 32-bit. The issue happened with 47.0.2 and 44.12 r-2 as well. I was trying the nightly builds before that I guess, but I'm less worried about those since they weren't meant to be stable in the first place.

:EDIT: My dumb ass realized that the stable releases are still being put out for the previous DF version. I'll give the new nightly a shot.
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on February 17, 2020, 06:19:36 pm
Back when DFHack 0.44.12-r3 was released, 0.44.12 was the newest DF version. We couldn't have supported anything newer than 0.44.12 when it was released, because nothing newer existed.  https://docs.dfhack.org/en/stable/docs/Introduction.html#installing-dfhack has some more details.

https://dfhack.org/builds should have 0.47.03 builds available now, as soon as the build server is back up. Note that we've done pretty much the bare minimum to support 0.47.03 so far, so you may have better luck with an older build for 0.47.02 instead.
Title: Re: DFHack 0.44.12-r3
Post by: Nopenope on February 18, 2020, 04:13:20 am
What's a usable plugin to play "mutliplayer" (hotseat screen sharing) these days? Web Fortress hasn't been updated since 2015 and DFTerm3 since 2014. (DFRemote only works on iOS.) Have the structures changed significantly enough since then that it would be nontrivial to port either to .47.xx?
Title: Re: DFHack 0.44.12-r3
Post by: Warmist on February 18, 2020, 04:21:38 am
What's a usable plugin to play "mutliplayer" (hotseat screen sharing) these days? Web Fortress hasn't been updated since 2015 and DFTerm3 since 2014. (DFRemote only works on iOS.) Have the structures changed significantly enough since then that it would be nontrivial to port either to .47.xx?

Afaik nothing important changed. It's just that they got outdated.

Edit: looked over in more detail (not very much more but a bit more):

Both of them depend on least changing part of df and/or dfhack: the rendering part so "porting" is just building it to new dfhack.
Title: DFHack 0.47.03 - 200217005
Post by: dwarffun on February 19, 2020, 11:22:50 am
There already is feedback for dfhack/tiletypes aquifer on github issues tracker.
Due to not being a developer and not having a github account, my additional info here:

tiletypes aquifer does not work as expected.
The aquifer flag can be set. Obviously the aquifer information exists somehow, because revealing the map and pressing "d" (dig) shows a blue/blinking aquifer area where it was set by tiletypes. But ... dwarfes digging into the aquifer area do not start water flooding the digged tunnel.

I tried this before on a "granite" level. Set tiletypes to range 7/7/1, material soil, shape wall, special normal, aquifer 1. And replaced 7/7 granite by soil aquifer.
Former channeling into the aquifer area created a soil downward slope ... and water. Currently it produces a granite downward slope ... and no water.
It looks like the aquifer and material information is lost, when a tile becomes "digged in/out".
Title: Re: DFHack 0.44.12-r3
Post by: FantasticDorf on February 19, 2020, 11:52:25 am
This could relate to this bug on the tracker 0011382: Unmarked aquifer embarks spread water from non-aquifer stones (http://www.bay12games.com/dwarves/mantisbt/view.php?id=11382) , Aquifers on 47.xx seem to not be setting themselves correctly as they'll pick out non-aquifer stones never defined to hold them with buggy responsive behaviour to getting wet.

I would guess that if you made your tileset aquifers wet already by putting a pond zone over them (or just generating water by summoning 3/7's or more) it would start working.

The DFhack observations might be useful for fixing the problem temporarily with main DF via a script or helpful analysis.
Title: Re: DFHack 0.47.03 - 200217005
Post by: lethosor on February 19, 2020, 12:25:10 pm
There already is feedback for dfhack/tiletypes aquifer on github issues tracker.
Due to not being a developer and not having a github account, my additional info here:

tiletypes aquifer does not work as expected.
The aquifer flag can be set. Obviously the aquifer information exists somehow, because revealing the map and pressing "d" (dig) shows a blue/blinking aquifer area where it was set by tiletypes. But ... dwarfes digging into the aquifer area do not start water flooding the digged tunnel.

I tried this before on a "granite" level. Set tiletypes to range 7/7/1, material soil, shape wall, special normal, aquifer 1. And replaced 7/7 granite by soil aquifer.
Former channeling into the aquifer area created a soil downward slope ... and water. Currently it produces a granite downward slope ... and no water.
It looks like the aquifer and material information is lost, when a tile becomes "digged in/out".

Are you using 0.47? Aquifers changed significantly in that version, from my understanding, but we haven't made any changes to support that, so any aquifer-related stuff probably won't work well.
Title: Re: DFHack 0.44.12-r3
Post by: PatrikLundell on February 19, 2020, 12:32:17 pm
Adding to lethosor's comment, I'm unaware of any aquifer tiletype issue on github (someone had some idea for something tiletype related in the past, but never came back with an implementation being the closest I could find). There's one for Embark-Tools somehow causes the native DF aquifer UI string to go AWOL, but it has nothing to do with manipulation.

Not only haven't aquifer related changes been made, but the identification of how DF determines the kind of aquifer to use and where the resultant decision is stored haven't been worked out either, so the basics info is still missing.
Title: Re: DFHack 0.47.03 - 200217005
Post by: dwarffun on February 19, 2020, 04:46:49 pm
Are you using 0.47? Aquifers changed significantly in that version, from my understanding, but we haven't made any changes to support that, so any aquifer-related stuff probably won't work well.

Yes I do. DFHack 0.47.03(alpha0 dev) - 200217005(build) See subject.
Well, it does not crash, so it could be worse :)
Title: Re: DFHack 0.44.12-r3
Post by: dwarffun on February 19, 2020, 04:51:32 pm
There's one for Embark-Tools somehow causes the native DF aquifer UI string to go AWOL, but it has nothing to do with manipulation.

https://github.com/DFHack/dfhack/issues/1499
Yes, that's the one I thought it might relate. But again, I'm no developer... and might be completely wrong. Nevermind then.
Title: Re: DFHack 0.44.12-r3
Post by: Taras on February 19, 2020, 11:01:24 pm
How make reaction with product made of local material of worker who do this reaction?
Title: Re: DFHack 0.44.12-r3
Post by: Atomic Chicken on February 20, 2020, 01:15:25 am
How make reaction with product made of local material of worker who do this reaction?

What do you mean by "local material of worker"?
Title: Re: DFHack 0.44.12-r3
Post by: Taras on February 20, 2020, 02:20:55 am
How make reaction with product made of local material of worker who do this reaction?

What do you mean by "local material of worker"?
Like if serpent man doing this reaction, product made of serpent's man venom, if spider man do this reaction, product made of spider man venom.
Title: Re: DFHack 0.44.12-r3
Post by: Manzeenan on February 20, 2020, 02:28:40 pm
I just wanted to say thank you guys for maintaining and improving df-hack, its core to my experience and I'm glad it's still around :)
Title: Re: DFHack 0.44.12-r3
Post by: Nilsolm on February 20, 2020, 02:59:59 pm
Is there possibly something wrong with the autogems plugin? It does not appear to be working. Gems are available and there are dwarves assigned to gem cutting, and yet it isn't creating tasks at the workshops. Build ID is  200218004.
Title: Re: DFHack 0.44.12-r3
Post by: Tonren on February 20, 2020, 03:33:20 pm
I'm trying to build the current alpha so I can try to build There Will Be Text (https://github.com/mifki/df-twbt) so I can try out the GemSet (https://github.com/DFgraphics/GemSet) graphics pack and currently striking out. I usually play on OS X and Windows, but I'm building on an Ubuntu 18.04 VPS because I'm more comfortable with Linux development. Maybe this is barking up the wrong tree and I should just try to build on Windows or OS X (though I'd rather not OS X since I only have a dinky Air for building anything). When I run cmake .. -G Ninja -DCMAKE_BUILD_TYPE:string=Release -DCMAKE_INSTALL_PREFIX=/home/changemewtf/df_linux, cmake fails complaining that CMakeLists.txt doesn't exist in various places, and the error log has the following:

Quote from: build/CMakeFiles/CMakeError.log
Determining if the pthread_create exist failed with the following output:
Change Dir: /home/changemewtf/dfhack/build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/ninja" "cmTC_57f82"
[1/2] Building C object CMakeFiles/cmTC_57f82.dir/CheckSymbolExists.c.o
[2/2] Linking C executable cmTC_57f82
FAILED: cmTC_57f82
: && /usr/bin/cc -fvisibility=hidden -mtune=generic -m64 -mno-avx  -rdynamic CMakeFiles/cmTC_57f82.dir/CheckSymbolExists.c.o  -o cmTC_57f82   && :
CMakeFiles/cmTC_57f82.dir/CheckSymbolExists.c.o: In function `main':
CheckSymbolExists.c:(.text+0x1b): undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

File /home/changemewtf/dfhack/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include <pthread.h>

int main(int argc, char** argv)
{
  (void)argv;
#ifndef pthread_create
  return ((int*)(&pthread_create))[argc];
#else
  (void)argc;
  return 0;
#endif
}

I see from the DFHack docs (https://docs.dfhack.org/en/stable/docs/Compile.html) pthread is specifically mentioned, and I made sure to compile the latest stable version of cmake from source. But I still got the pthread errors.

Not sure if this would be better off as a GitHub issue; like I said, I'm not even sure if it's supposed to be able to build on a headless Ubuntu installation, so I might try building on Windows later, though the idea of tracking down all those dependencies by hand or becoming an overnight chocolatey expert is not very appealing...

Edit: Just found /u/clinodev (https://www.reddit.com/r/dwarffortress/comments/f67u62/preview_win64_04703_pack_caveat_emptor_edition/fi4vrpk/)'s comments on Reddit indicating they might have a successful build running for Windows already... I'll update as I go!
Title: Re: DFHack 0.44.12-r3
Post by: thurin on February 20, 2020, 05:21:00 pm
You can grab a TWBT plugin for the 3 platforms from https://github.com/thurin/df-twbt/releases/tag/0.47.03-alpha0-200218004 that'll work with the 200218004 DFHack build until official builds and starter packs are available.
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on February 20, 2020, 06:12:09 pm
I'm trying to build the current alpha so I can try to build There Will Be Text (https://github.com/mifki/df-twbt) so I can try out the GemSet (https://github.com/DFgraphics/GemSet) graphics pack and currently striking out.
If all you want is a build for 0.47.03, check https://dfhack.org/builds (see a page or two back for more information). If you do want to build it yourself, though:

Quote
I see from the DFHack docs (https://docs.dfhack.org/en/stable/docs/Compile.html) pthread is specifically mentioned, and I made sure to compile the latest stable version of cmake from source. But I still got the pthread errors.
Did you install libpthread, though? And did the one you installed match the architecture you're building DFHack for? (e.g. CMake won't pick up on a 32-bit libpthread if you're building 64-bit DFHack.)

Is there possibly something wrong with the autogems plugin? It does not appear to be working. Gems are available and there are dwarves assigned to gem cutting, and yet it isn't creating tasks at the workshops. Build ID is  200218004.
You're sure the plugin is enabled, right? Is it showing up in the "o": standing orders menu?
(Note that all builds are considered unstable at this point, so running into stuff like this isn't unexpected.)
Title: Re: DFHack 0.44.12-r3
Post by: Nilsolm on February 20, 2020, 06:54:33 pm
Is there possibly something wrong with the autogems plugin? It does not appear to be working. Gems are available and there are dwarves assigned to gem cutting, and yet it isn't creating tasks at the workshops. Build ID is  200218004.
You're sure the plugin is enabled, right? Is it showing up in the "o": standing orders menu?
(Note that all builds are considered unstable at this point, so running into stuff like this isn't unexpected.)
[/quote]
Never mind, actually. I went back to look at what might be causing it again in the meantime, and the problem turned out to have been related to stockpile setup. The plugin itself seems to be working as intended.
Title: Re: DFHack 0.44.12-r3
Post by: Nopenope on February 21, 2020, 07:09:30 am
Just a heads-up, the current DFHack repo is pointing at outdated commits for the submodules isoworld and stonesense. This is important because isoworld was considerably harder to build before BenLubar updated it a month ago.
Title: Re: DFHack 0.44.12-r3
Post by: Atomic Chicken on February 22, 2020, 03:24:35 am
Is it possible to determine whether a script has been called directly from the DFHack console as opposed to onLoad.init?
Title: Re: DFHack 0.44.12-r3
Post by: PatrikLundell on February 22, 2020, 05:58:02 am
Is it possible to determine whether a script has been called directly from the DFHack console as opposed to onLoad.init?
I would guess:
"dfhack.is_interactive()

Checks if the thread can access the interactive console and returns true or false.
"
from https://dfhack.readthedocs.io/en/stable/docs/Lua%20API.html#enabling-and-disabling-scripts (https://dfhack.readthedocs.io/en/stable/docs/Lua%20API.html#enabling-and-disabling-scripts)
Title: Re: DFHack 0.44.12-r3
Post by: Atomic Chicken on February 22, 2020, 08:52:46 am
dfhack.is_interactive()

This seems to get the job done; thanks!
Title: Re: DFHack 0.44.12-r3
Post by: hagger on February 23, 2020, 12:50:57 pm
Quick note - the "feature" script seems to be broken for me. feature list doesn't return anything, and feature magma tells me that it "Could not find a magma-bearing feature." Map doesn't have a magma pool, so its just the sea, however normally the caverns/etc would be listed as well.

Happy to provide logs/etc - not experiencing any other issues though. Arch 64 bit :)
Title: Re: DFHack 0.44.12-r3
Post by: PatrikLundell on February 23, 2020, 01:25:56 pm
Quick note - the "feature" script seems to be broken for me. feature list doesn't return anything, and feature magma tells me that it "Could not find a magma-bearing feature." Map doesn't have a magma pool, so its just the sea, however normally the caverns/etc would be listed as well.

Happy to provide logs/etc - not experiencing any other issues though. Arch 64 bit :)
Not being familiar with the script, but running "feature list" on the same save in 0.44.12 and 0.47.03 gives the same result for me (9 different ones), and "feature magma" resulted in "Enabled magma furnaces" on both (there are already working magma furnaces, though). However, the DF structures I'm using were downloaded 10 or so hours ago, and so may be newer than the ones you used.
Title: Re: DFHack 0.44.12-r3
Post by: Rumrusher on February 23, 2020, 08:26:09 pm
Code: [Select]
if dfhack.gui.getCurFocus() ~= 'setupadventure' then
    qerror('Must be called on adventure mode setup screen')
end

local adv = dfhack.gui.getCurViewscreen().party_members  -- hint:df.viewscreen_setupadventurest
for Pm, Ad in pairs(adv) do 

for k in pairs(Ad.skills) do
    Ad.skills[k] = df.skill_rating.Legendary5
end
for k in pairs(Ad.physical_levels) do
    Ad.physical_levels[k] = df.adventurer_attribute_level.Superior
end
for k in pairs(Ad.mental_levels) do
    Ad.mental_levels[k] = df.adventurer_attribute_level.Superior
end
end

here's a rework on the adv max skills script though this one will max out all the skills for every new adventurer in the party.
Title: Re: DFHack 0.44.12-r3
Post by: Taras on February 24, 2020, 08:21:25 am
How resurrect my dead adventurer?
Title: Re: DFHack 0.44.12-r3
Post by: Atomic Chicken on February 24, 2020, 10:54:33 am
How resurrect my dead adventurer?

Code: [Select]
local fullHeal = reqscript('full-heal')

if df.global.gamemode ~= df.game_mode.ADVENTURE then
  qerror("This script can only be used in adventure mode!")
end

local adventurer = df.nemesis_record.find(df.global.ui_advmode.player_id).unit
if not adventurer or not adventurer.flags2.killed then
  qerror("Your adventurer hasn't died yet!")
end

fullHeal.heal(adventurer, true)
df.global.ui_advmode.player_control_state = 1

Copy-paste the above into a text editor and save it as a .lua file (name it something like resurrect-adv.lua) in the hack\scripts folder. Then run it by entering the file's name in the DFHack console after you've been presented with the "You are deceased" message.
Title: Re: DFHack 0.44.12-r3
Post by: hagger on February 24, 2020, 12:10:37 pm
Quick note - the "feature" script seems to be broken for me. feature list doesn't return anything, and feature magma tells me that it "Could not find a magma-bearing feature." Map doesn't have a magma pool, so its just the sea, however normally the caverns/etc would be listed as well.

Happy to provide logs/etc - not experiencing any other issues though. Arch 64 bit :)
Not being familiar with the script, but running "feature list" on the same save in 0.44.12 and 0.47.03 gives the same result for me (9 different ones), and "feature magma" resulted in "Enabled magma furnaces" on both (there are already working magma furnaces, though). However, the DF structures I'm using were downloaded 10 or so hours ago, and so may be newer than the ones you used.

Updating structures by installing the latest nightly build worked for me, thanks! I worked around it by actually discovering the magma sea, but nice to see it working again. I think it's always given back that "Enabled magma furnaces" message regardless of whether you're already able to use them - I tended to choose a magma-y feature from the list anyway.

Cheers again.
Title: Re: DFHack 0.44.12-r3
Post by: Tonren on February 24, 2020, 12:37:08 pm
Did you install libpthread, though? And did the one you installed match the architecture you're building DFHack for? (e.g. CMake won't pick up on a 32-bit libpthread if you're building 64-bit DFHack.)

I have installed libevent-pthreads-2.1-6 and libpthread-stubs0-dev, which are the closest I can find to a reputable package with "pthread" in the name. apt list --installed suggests that I have the correct AMD64 versions:

Code: [Select]
libevent-pthreads-2.1-6/bionic,now 2.1.8-stable-4build1 amd64 [installed]
libpthread-stubs0-dev/bionic,now 0.3-4 amd64 [installed]

Maybe I downloaded the wrong arch or misconfigured a build option somehow? I'll keep tinkering... it would be nice to be able to build it myself, but the villain update is absorbingly fun... :->
Title: Re: DFHack 0.44.12-r3
Post by: Clément on February 24, 2020, 02:16:47 pm
libpthread is part of the standard (posix) library, and thus it is part of the base system. The development files should be installed automatically with gcc (the package is libc6-dev if you want to check).
Title: Re: DFHack 0.44.12-r3
Post by: PatrikLundell on February 25, 2020, 03:13:02 am
Technical question: Is there a way to check if a pointer is valid in Lua, i.e. if a df structure pointer address is within the range allocated to DF?
Title: Re: DFHack 0.44.12-r3
Post by: Warmist on February 25, 2020, 03:50:55 am
Technical question: Is there a way to check if a pointer is valid in Lua, i.e. if a df structure pointer address is within the range allocated to DF?

part of answer:  here  (https://gist.github.com/warmist/26319f3b49dbd7ac4733306621bcb386#file-find_twbt-lua-L39)

full answer: you need to get all the segments that df has allocated and check if pointer is inside that segment. You can get all memory segments with "dfhack.internal.getMemRanges()".
Also related  mem scan stuff  (https://github.com/DFHack/dfhack/blob/82f082d7cbd6b823ab4c54d0dfbbf578f7fb1c4a/library/lua/memscan.lua)
Title: Re: DFHack 0.44.12-r3
Post by: Taras on February 25, 2020, 03:52:05 am
How resurrect my dead adventurer?

Code: [Select]
local fullHeal = reqscript('full-heal')

if df.global.gamemode ~= df.game_mode.ADVENTURE then
  qerror("This script can only be used in adventure mode!")
end

local adventurer = df.nemesis_record.find(df.global.ui_advmode.player_id).unit
if not adventurer or not adventurer.flags2.killed then
  qerror("Your adventurer hasn't died yet!")
end

fullHeal.heal(adventurer, true)
df.global.ui_advmode.player_control_state = 1

Copy-paste the above into a text editor and save it as a .lua file (name it something like resurrect-adv.lua) in the hack\scripts folder. Then run it by entering the file's name in the DFHack console after you've been presented with the "You are deceased" message.
Thanks!
Title: Re: DFHack 0.44.12-r3
Post by: PatrikLundell on February 25, 2020, 05:43:00 am
Thanks Warmist!
Title: Re: DFHack 0.44.12-r3
Post by: Erendir on February 25, 2020, 02:14:28 pm
There is one thing I still want. I saw https://botsin.space/@it_was_inevitable (https://botsin.space/@it_was_inevitable) (live feed of interesting dwarf conversation of a fortress) and thought, I'm missing on so much of my dwarfs' lives!

So, step 1 was adding D_D to [REGULAR_CONVERSATION:A_D:D_D] and [CONFLICT_CONVERSATION:A_D:UCR_A:D_D] in announcements.txt.

This ends up with A TON of uninteresting spam in announcements screen.
So, the next step is: figure out how to filter and/or redirect this.

We can hear to reports like this (those enabled in announcements.txt):
Code: [Select]
eventful=require('plugins.eventful')
eventful.onReport.print_report_text = function(id) local report=df.report.find(id); print(id, report.text); end
eventful.enableEvent(eventful.eventType.REPORT, 1)

We can also delete an entry at a given index with
Code: [Select]
df.report.get_vector():erase(idx)

but this doesn't delete it from announcements view.

This does, but only when the screen is open.
Code: [Select]
dfhack.gui.getViewscreenByType(df.viewscreen_announcelistst, 0).reports:erase(idx)

So, what I'm asking is,
  1. is there an easy way to prevent reports from appearing on announcements screen (like set some flag inside the eventful.onReport or something);
  2. lacking that, is there a way to access that `getViewscreenByType(df.viewscreen_announcelistst, 0).reports` when the screen isn't loaded;
  3. and lacking that, is it possible to execute a script when the announcements screen opens?
Title: Re: DFHack 0.44.12-r3
Post by: lethosor on February 25, 2020, 07:32:57 pm
So, what I'm asking is,
  1. is there an easy way to prevent reports from appearing on announcements screen (like set some flag inside the eventful.onReport or something);
I think world.status.display_timer (https://github.com/DFHack/df-structures/blob/master/df.world.xml#L997) is what you want - setting it to 0 should clear the bottom of the screen.

The other questions might be useful for other purposes, though, so:
Quote
  2. lacking that, is there a way to access that `getViewscreenByType(df.viewscreen_announcelistst, 0).reports` when the screen isn't loaded;
No, that's a copy that is made specifically for the screen when the screen is opened, and is destroyed when the screen is closed. Modifying it won't affect the global list of reports.

Quote
  3. and lacking that, is it possible to execute a script when the announcements screen opens?
You could use an onStateChange handler - I think that would probably be the easiest way.
Title: Re: DFHack 0.44.12-r3
Post by: Rumrusher on February 26, 2020, 10:47:05 am
Code: (GiftSomeone.lua) [Select]
local dlg=require("gui.dialogs")
local testdia=df.global.ui_advmode.conversation
testdia.choices:insert("#",{new=df.ui_advmode.T_conversation.T_choices,})
for nu,choi in pairs(df.global.ui_advmode.conversation.choices) do
if choi.choice==nil then
choi.choice=df.talk_choice:new()
testdia.choices[nu].title:insert("#",df.new("string"))
testdia.choices[nu].keywords:insert("#",df.new("string"))
testdia.choices[nu].choice.type=247
testdia.choices[nu].choice.unk.anon_2=testdia.activity_event[0].participants[1].histfig_id
testdia.choices[nu].title[0].value=("Gift someone themselves")
testdia.choices[nu].keywords[0].value=("Gift")
end
for nod,mof in pairs(df.global.ui_advmode.conversation.page_bottom_choices) do
if nod == 1 then
testdia.page_bottom_choices[nod]=nu
elseif nod == 0 then
testdia.page_bottom_choices[nod]=nu
elseif nod == 1 and 0 then
break
end
end
end

ok so this adventure mode dialog script will hopefully make it so who ever you're talking to will accept the gift of themselves, though given how I set this up it might end up gifting someone you previously talked to so uhh best end conversations with companions before you end up gifting them to some random peasant, or use that to your advantage and end up gifting folks to others.
Title: Re: DFHack 0.44.12-r3
Post by: MaxTheFox on February 26, 2020, 12:00:26 pm
unretire-anyone seems to start the people you unretire naked and without any items, only with any artifacts they hold. Is there any way to fix that? e.g by giving them clothing and items appropriate to their civ?
Title: Re: DFHack 0.44.12-r3
Post by: Rumrusher on February 26, 2020, 02:01:35 pm
unretire-anyone seems to start the people you unretire naked and without any items, only with any artifacts they hold. Is there any way to fix that? e.g by giving them clothing and items appropriate to their civ?
hmm have you tested this with any historical figure that shown up before? or just random ones? this might be the 'historical figure not having a unit body thus when the game gives them one it's only holding what they were told to hold during world gen, vs seeing them at a site which the game loads them into the site themed outfits.

fake edit: ok just tested this with historical figures I seen before in adventure mode and yeah it looks like the issue here is that grabbing anyone from the game's history pool that didn't show up before as a unit will not load in with clothes if you use them.
so it basically unretire anyone allows you to grab any historical figure including those with no unit tied to them and play them, which often ends up with creating a unit for them that doesn't have any standard clothes or inventory.

I guess the solution for this is to uhh retire then unretire the naked adventurer then see if the game would give them clothes in the 2 weeks~ time jump, or only use unretire anyone on folks you have seen before in adventure mode or probably fort mode.
edit:
Spoiler: 'questport fix' (click to show/hide)
for anyone who want to use questport again in the new dfhack
Title: Re: DFHack 0.44.12-r3
Post by: Erendir on February 26, 2020, 03:19:13 pm
Does it make sense to post incomplete info I found out on unknown variables, and if so, what is the proper place?

Title: Re: DFHack 0.44.12-r3
Post by: lethosor on February 26, 2020, 06:43:56 pm

Spoiler: 'questport fix' (click to show/hide)
for anyone who want to use questport again in the new dfhack
Could you please make a pull request with this fix so it doesn't get lost? I hadn't even seen any reports of issues with that script.
Title: Re: DFHack 0.44.12-r3
Post by: Rumrusher on February 26, 2020, 11:44:17 pm

Spoiler: 'questport fix' (click to show/hide)
for anyone who want to use questport again in the new dfhack
Could you please make a pull request with this fix so it doesn't get lost? I hadn't even seen any reports of issues with that script.
well sent an issue with the fix, so that at least it's there.
Title: Re: DFHack 0.44.12-r3
Post by: MaxTheFox on February 27, 2020, 03:56:11 am
Is there a "retire anywhere" script that allows you to retire in lairs and such?
Title: Re: DFHack 0.44.12-r3
Post by: IndigoFenix on February 27, 2020, 04:34:32 am
Is there a way to get the soul information of a selected histfig in legends viewer?  I can write lua scripts but I can't find the variables needed.

(I'm trying to scan the personality and values of historical figures to see if there's a reason behind the things they do... The better to mod secrets and entities to manipulate unit behavior.)

EDIT: Never mind, figured it out.
Title: Re: DFHack 0.44.12-r3
Post by: Rumrusher on February 27, 2020, 07:35:32 am
Is there a way to get the soul information of a selected histfig in legends viewer?  I can write lua scripts but I can't find the variables needed.

(I'm trying to scan the personality and values of historical figures to see if there's a reason behind the things they do... The better to mod secrets and entities to manipulate unit behavior.)

EDIT: Never mind, figured it out.
hmm it should be in the info section of their data, some how the historical figure info section which holds data on if they read books and reputation and relationship towards others also holds their personality which ends up being inserted into the unit's soul.
I haven't poke around that to see if there's a personality trait that pushes folks towards doing necromancy stuff so far if I even figure out the event data for necromancers making a new unit
Title: Re: DFHack 0.44.12-r3
Post by: Erendir on February 27, 2020, 02:53:24 pm
  3. and lacking that, is it possible to execute a script when the announcements screen opens?
You could use an onStateChange handler - I think that would probably be the easiest way.

That worked (https://github.com/DFHack/scripts/pull/123). Now I only need some useful filters.
Title: Re: DFHack 0.44.12-r3
Post by: IndigoFenix on February 28, 2020, 02:48:02 am
I have a question concerning the nature of DFHack - are the variable names of objects created by Toady, or does the DFHack team have to actually figure out what they do and name them that way?
Title: Re: DFHack 0.44.12-r3
Post by: MaxTheFox on February 28, 2020, 02:56:30 am
Is a script as I described even possible?
Title: Re: DFHack 0.44.12-r3
Post by: Rumrusher on February 28, 2020, 05:50:32 am
Is a script as I described even possible?
so far give one could make a camp(slap a civ to said camp) and retire there the idea of moving into a lair would require scrubbing the restrictions on the site then adding a civ to it.

so far dfhack already could just move the campsite around and teleport it to your exact location so retiring adventurers anywhere isn't impossible just a different method is needed.
so I guess one could just convert the lair into a camp and just set up an main hall to claim it.
Title: Re: DFHack 0.44.12-r3
Post by: IndigoFenix on February 28, 2020, 07:13:45 am
Is there any way of getting a list of all historical events related to a historical figure?  Like what is shown on the legends screen?
Title: Re: DFHack 0.44.12-r3
Post by: PatrikLundell on February 28, 2020, 07:38:25 am
I have a question concerning the nature of DFHack - are the variable names of objects created by Toady, or does the DFHack team have to actually figure out what they do and name them that way?
I don't think there's a single answer to the question:
- I think some information has been extracted through disassembly.
- Some info probably comes from Toady.
- The bulk of it is retaining what has been mapped earlier, sometimes with a bit of shifting around.
- Much of the "new" things (i.e. identification of things that hasn't been identified earlier, even if the mapping has been known for a long time) is named by "inventing" a suitable name, while trying to use the names DF uses when possible.

Is there any way of getting a list of all historical events related to a historical figure?  Like what is shown on the legends screen?
Mostly, I would say. Either you'd have to scour the historical info for entries that refer to the historical figure, and that means you'll have to know the fields where HF Ids are stored, which relies on DFHack mapping of the fields (and a lot of processing of the entries to get the rest of the info), or use the alternative approach that is to scour the exported legends info (which e.g. Legends Viewer uses, to great effect). Neither method probably provides the full picture, however, as Toady doesn't export everything in the entries, and DFHack hasn't mapped everything (in the ideal world, where DFHack structures has mapped everything, you'd be able to extract more than what Legends Mode tells you).
Title: Re: DFHack 0.44.12-r3
Post by: IndigoFenix on February 28, 2020, 08:27:14 am
Is there any way of getting a list of all historical events related to a historical figure?  Like what is shown on the legends screen?
Mostly, I would say. Either you'd have to scour the historical info for entries that refer to the historical figure, and that means you'll have to know the fields where HF Ids are stored, which relies on DFHack mapping of the fields (and a lot of processing of the entries to get the rest of the info), or use the alternative approach that is to scour the exported legends info (which e.g. Legends Viewer uses, to great effect). Neither method probably provides the full picture, however, as Toady doesn't export everything in the entries, and DFHack hasn't mapped everything (in the ideal world, where DFHack structures has mapped everything, you'd be able to extract more than what Legends Mode tells you).

Yeah that's basically what I'm doing (I'm able to get the personality, values, skills, entity positions, and syndromes of a unit while viewing it on the legends screen) but I'm having a very hard time finding their associated events.  Scouring the entire event list is possible, but there are a lot of events, and I very, very much doubt that that's what the game is doing when you open up the history viewer (or it would take a lot longer to open up), which means there should be some place where the events that appear on a given histfig's screen are indexed.

I'm trying to perform scans of all units that perform particular actions, then average out their personalities to try to figure out which personality or value traits cause which kinds of behaviors.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on February 28, 2020, 09:08:11 am
A bit late, but we have an official pre-release, 0.47.03-beta1, up now: https://github.com/DFHack/dfhack/releases/tag/0.47.03-beta1 (just in time for 0.47.04, probably)
Title: Re: DFHack 0.44.12-r3
Post by: Rumrusher on February 28, 2020, 09:31:41 am
yeah finding the event that tells you when the god or entity makes a creature is probably not even discovered so scouring through all the history to find it is uhh a pain.

oh crud I just notice DFhack doesn't have all interactions flags/tokens including the new night creature experimenter one that applies on necromancers.

for the experimental alpha build, I don't know if it the same for the beta.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: ZayZe on February 28, 2020, 10:46:28 am
A bit late, but we have an official pre-release, 0.47.03-beta1, up now: https://github.com/DFHack/dfhack/releases/tag/0.47.03-beta1 (just in time for 0.47.04, probably)

Most likely lol

I assume the next release after this one will be a while though regarding the past dev logs.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on February 28, 2020, 11:50:24 am
@Rumrusher and IndigoFenix: If there is a history event list for each hist fig it hasn't been mapped, as far as I can see.

It's not surprising that a lot of stuff hasn't been mapped yet, as it depends on people doing that, which, obviously, tends to be in areas they like to poke around in, or at least report what the find missing as issues on github (with as much info as possibly, to get the poor sod who may well be going to try to map something he's not familiar with a reasonable chance of doing a good job).
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: jecowa on February 29, 2020, 10:31:53 am
A couple of suggestions for /hack/scripts/modtools/extra-gamelog.lua (soundsense support script):

1. Make the current weather get logged 3 seconds before the current season. This way with the big "official" pack you start to hear the relaxing weather sounds a few seconds before the seasonal music start, and more importantly with the "toikkus" pack, you don't hear "The weather has cleared" and "It is now spring" talking over each other.


2. Second suggestion: Don't log "The weather has cleared." or log a shortened version of it. The "official" pack doesn't have any sound or music to play when then weather has cleared. And for the "toikkus" pack, it doesn't really make sense to hear "The weather has cleared" announced when loading the save. But maybe someday someone will want to make some special clear-weather music that can load when the save loads. So maybe change the logged message from "The weather has cleared." to "weather has cleared." This way sound pack makers can choose to either target all weather cleared messages or target all weather cleared messages except the one that gets logged when the save file is first loaded.

Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on February 29, 2020, 10:57:32 am
1. Make the current weather get logged 3 seconds before the current season. This way with the big "official" pack you start to hear the relaxing weather sounds a few seconds before the seasonal music start, and more importantly with the "toikkus" pack, you don't hear "The weather has cleared" and "It is now spring" talking over each other.
It looks to me like this freezes DF for 3 seconds whenever the weather (or season?) changes. That's not a great user experience and is bound to lead to bug reports.

Quote
2. Second suggestion: Don't log "The weather has cleared." or log a shortened version of it. The "official" pack doesn't have any sound or music to play when then weather has cleared. And for the "toikkus" pack, it doesn't really make sense to hear "The weather has cleared" announced when loading the save. But maybe someday someone will want to make some special clear-weather music that can load when the save loads. So maybe change the logged message from "The weather has cleared." to "weather has cleared." This way sound pack makers can choose to either target all weather cleared messages or target all weather cleared messages except the one that gets logged when the save file is first loaded.
My opinion on the matter: there are multiple sound utilities (SoundSense, SoundCenSe, SoundSense-RS, and maybe others). Just because one doesn't support a message doesn't mean we should remove that message for other utilities as well. And I'm really not sure what removing "The" accomplishes - both messages look equally easy to parse to me, and by changing a message, we risk breaking compatibility with existing utilities for no clear benefit. (A similar argument could be made for weather - the script's job is to log events when they occur, and sound utilities could fairly easily add a delay before certain sounds if they want to.)
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: IndigoFenix on February 29, 2020, 12:23:12 pm
@Rumrusher and IndigoFenix: If there is a history event list for each hist fig it hasn't been mapped, as far as I can see.

It's not surprising that a lot of stuff hasn't been mapped yet, as it depends on people doing that, which, obviously, tends to be in areas they like to poke around in, or at least report what the find missing as issues on github (with as much info as possibly, to get the poor sod who may well be going to try to map something he's not familiar with a reasonable chance of doing a good job).

That's a surprising thing to be missing...it's just all the info that appears when you open up a unit's page in Legends mode, and that's been around for...basically forever.
Maybe it's in another legends-related place rather than in the histfig object itself, indexed by the histfig id or something?  Where do I ask about this?
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: jecowa on February 29, 2020, 12:47:45 pm
My opinion on the matter: there are multiple sound utilities (SoundSense, SoundCenSe, SoundSense-RS, and maybe others). Just because one doesn't support a message doesn't mean we should remove that message for other utilities as well. And I'm really not sure what removing "The" accomplishes - both messages look equally easy to parse to me, and by changing a message, we risk breaking compatibility with existing utilities for no clear benefit. (A similar argument could be made for weather - the script's job is to log events when they occur, and sound utilities could fairly easily add a delay before certain sounds if they want to.)

Imo, the script is a little too enthusiastic about reporting clear weather. It reports clear weather when creating a new world, and it reports clear weather when starting a new game (before an embark location is chosen), and it reports it as clear when loading an existing save. I would like the sound packs to have the option to only play the clear weather sound when the weather changes from stormy to clear.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on February 29, 2020, 02:54:58 pm
Oh, that makes more sense - it should be easy enough to not print weather information when a fort isn't loaded. (edit: was backwards)
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Erendir on February 29, 2020, 03:28:33 pm
Oh, that makes more sense - it should be easy enough to not print weather information when a game is actually loaded.

Adding 2 dashes does the trick (extra-gamelog.lua line 35):
Code: [Select]
    if (not snowing and not raining) then --msg("The weather has cleared.")
    elseif raining then msg("It has started raining.")
    elseif snowing then msg("A snow storm has come.")
    end
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on February 29, 2020, 04:02:31 pm
Well, that disables the message entirely by commenting it out, including when a fort is loaded. Looking at it again, I'm pretty sure this script is supposed to log weather information when a fort is loaded, because DF only logs it when it changes (when an announcement is displayed). I just realized there was a typo in my earlier post - I meant when a fort isn't loaded (e.g. worldgen and other situations Jecowa mentioned), that message isn't as useful.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Roses on March 01, 2020, 12:14:20 am
I unfortunately won't be able to take a look at the new dfhack version for a couple weeks, but I am wondering what, if any, of the new stuff has been mapped, or at least it's level of mapping. When I can I would like to start looking at some of the new healing syndromes available through interactions and I'm wondering if that's something I'll be able to look at
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on March 01, 2020, 03:34:01 am
- There's been a lot of mapping of the "shape" of structures, i.e. introduction of new, unidentified, fields to align structures so that fields previously known again contain the known contents, as well as new unidentified fields at the end of structures.
- Similarly, a lot of enum values have been located, and a fair number identified.
- A number of new fields and structures have been (partially) identified.
- There's been a fair bit of at least identification of new derived types, although the identification of the contents may be lagging behind.

If you've got an interest in a particular area, such as e.g. syndromes, you ought to be better suited than most to help in the identification of the fields within it. Things that those active in field identification are interested in ought to be more likely to be identified than things peripheral to their interests. The syndrome and interaction complex is a particularly messy area that I, personally, avoid unless I need to deal with it.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Alatun on March 01, 2020, 12:24:32 pm
I just discovered an "unknown thought" in DwarfTherapist and checked with gui/gm-editor:  (262)

(http://www.rosen-berg.de/pics/dwarf/NewThought.png)

Because it's the only thought of type "dismay" in her "thoughts and preferences" it must be "reliving". The wording in game seems a bit strange, because "reliving" should refer to something (perhaps the subthought 4746).

(http://www.rosen-berg.de/pics/dwarf/NewThought2.png)
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on March 01, 2020, 01:04:08 pm
"Reliving" means it's a remembered thought, i.e. not a current one. The actual thought text should appear instead of " ." at the end. You can get this when hacking DF to check what they are, in particular if you don't have valid subthought/and or severity value.
You'll get the same display when hacking in 257, for instance.
Thoughts 243 - 259, with 257 missing, have been identified to a lesser or greater extent in https://github.com/DFHack/df-structures/issues/363 (https://github.com/DFHack/df-structures/issues/363), but nobody has entered it into the mess that describes it.

Also, some thoughts are intended for other purposes than as fortress thoughts, e.g. in history events (251 [from afar], for example, is quite common for artifact claims), and so might not have any fortress thought mapping at all.

It is a bug if this has occurred naturally, as descriptions shouldn't be cut short.

A guess is that a guild hall or temple might have been removed, in which case DF might have failed to find the referenced "building". If you can check what entity 4746 is you might find a religion or guild.

Edit: Didn't manage to provoke any text for 260-262 when starting with a guildhall thought.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Alatun on March 01, 2020, 02:40:14 pm
It is a bug if this has occurred naturally, as descriptions shouldn't be cut short.

A guess is that a guild hall or temple might have been removed, in which case DF might have failed to find the referenced "building". If you can check what entity 4746 is you might find a religion or guild.

Edit: Didn't manage to provoke any text for 260-262 when starting with a guildhall thought.

I think it should be a natural tought. I only "fixed" the stress level of 2 dwarfs (others than the one with this thought) and did a "cleanowned" to cleanup scattered clothing items.

I only relocated a temple and a guildhall to a new spot. Two or three artifacts got stolen (from members of my community, being under the influence of a goblin - as far as my counterintelligence detected so far).

How do I get information for a certain entity ID? I retired the fort and did a legends export. The identity with 4746 is an elf - maybe a guest or from an elven caravan. I also could provide the save, if it is helpful.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on March 01, 2020, 05:14:53 pm
Relocating a temple might be considered razing it, though.

No, an entity is an organization, such as a civ, site government, or religion. A HF (historical figure) is a creature, such as an elf.
Entities are actually rather simple, as they're never culled, so they're in df.global.world.entities.all
The save after retiring is likely rather useless, unfortunately, as the unit (and its thoughts) are no longer present (a unit is a creature that's involved somewhat immediately with what happens in a fortress [and, I would assume, adventure mode]. HF's can also be units, but a lot of units are not, but rather faceless entities, such as wild animals and most members of invading forces. Non HF creatures become HFs when they make notable kills, though, such as an invader goblin killing one of your citizens).
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Alatun on March 01, 2020, 05:47:18 pm
Ok, got it: entity 4746 is called "The hall of Rock" - the "Guild of Farmers" of my dwarven community.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Roses on March 01, 2020, 07:09:43 pm
- There's been a lot of mapping of the "shape" of structures, i.e. introduction of new, unidentified, fields to align structures so that fields previously known again contain the known contents, as well as new unidentified fields at the end of structures.
- Similarly, a lot of enum values have been located, and a fair number identified.
- A number of new fields and structures have been (partially) identified.
- There's been a fair bit of at least identification of new derived types, although the identification of the contents may be lagging behind.

If you've got an interest in a particular area, such as e.g. syndromes, you ought to be better suited than most to help in the identification of the fields within it. Things that those active in field identification are interested in ought to be more likely to be identified than things peripheral to their interests. The syndrome and interaction complex is a particularly messy area that I, personally, avoid unless I need to deal with it.

That's great, I was mainly concerned about the first part. As long as there are the correct alignments finding out what the unknown fields are can be kind of fun. I remember doing it for some of the army stuff last release. I will definitely start poking around in various places in a week or two. Syndromes and interactions are definitely more of a mess than some of the other stuff, but I'm hoping I'll be able to make some sense of them.

Edit: Here is a more specific question. The syndrom utility plugin that is used to add and remove syndromes, is that something that is going to need updating with the various new effects? Just wondering if I should start my research there or assume that it works and start research from there?
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Atkana on March 04, 2020, 04:32:01 am
I've kept meaning to ask, is there a plugin or script available that disables the indoors requirement for furniture placement in fort mode? It's not fair that adventurers get to easily build all those nice outdoor rooms without having to temporarily build scaffolding over it / use tiletypes to set the areas as indoors for a frame so you can designate the placements :P
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: jecowa on March 04, 2020, 05:15:21 am
I'm pretty sure I've built an altar outdoors when testing out graphics for the new items. I didn't realize an indoor requirement existed.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Atkana on March 04, 2020, 06:25:31 am
I'm pretty sure I've built an altar outdoors when testing out graphics for the new items. I didn't realize an indoor requirement existed.
Certain furniture (namely beds, tables, and chairs) are coded to not allow designating to build outside in fort mode. Most other furniture can be - and all can in adventure mode, as far as I know - it's just some weird restriction on a certain few :c
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: iceball3 on March 04, 2020, 06:51:26 am
Do bridges count for roofing? If so that can help speed up your scaffolding setup before taking it down.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: luisedgm on March 04, 2020, 08:41:55 am
Hello, is there an ETA for the 47.04 version?
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on March 04, 2020, 10:59:59 am
Hello, is there an ETA for the 47.04 version?
No. It's done when it's done.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on March 04, 2020, 11:09:18 am
If you'd like it to be ready faster, feel free to download one of the nightly builds linked in the first post and let us know if you run into any issues (just don't count on it being stable for actual gameplay!)
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: feelotraveller on March 04, 2020, 01:18:54 pm
Just as a point of interest I used the dfhack-0.47.03-beta1-200301001-Linux-64-gcc-7 build for a few days with 47.04 and had no problems - although I didn't use any of the dfhack 'hacking' functions (outside of the core) only information providers like prospect etc. and more or less the default dfhack-init  Which is not so say that I was expecting long term stability!

Just downloaded dfhack-0.47.04-alpha0-200303002-Linux-64-gcc-7 so that experiment ('histories of impatience and recklessness') has come to an end...
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Alatun on March 05, 2020, 06:08:33 pm
I've got a question regarding programming LUA scripts for dfhack. I hope this is the right place to ask.

First a rather specific one:
If you view the "Stocks" and press TAB the item list gets expanded. Items there are colored and according to the wiki, red items are "Not owned by the fort".
I'm interested in items in the category "Bars" or "Cloth"
In the list I see some white (traded items), a lot of dark yellow (created by the fort) and some red (not owned by the fort - e.g. if a caravan is currently at the depot). If you have opened a cavern already, uncollected spider silk cloth is also marked red.

How do I test an item, if is owned by the fort (which is NOT red) in the stocks list. Here is a small script I was using, to find all items that can be used for crafting.
Code: [Select]
local utils = require('utils')

for i,item in ipairs(df.global.world.items.all) do
if not item.flags.rotten and not item.flags.dump and not item.flags.forbid and not item.flags.construction then
if item:getMaterial() == df.builtin_mats.INORGANIC and item:getType() == df.item_type.BAR then
print(utils.getItemDescription(item,0))
end
end
end

I saw that there should be a flag "item.flags.owned". If I add this flag to the other flag checks, NO item will be printed. As I'm currently seeing items in dark yellow and red, there should always be printing something.
Code: [Select]
if item.flags.owned and not item.flags.rotten and not item.flags.dump and not item.flags.forbid and not item.flags.construction then

It seems, this flag is false for all items. Is this a bug? Does this flag represent something else? Is there another way to check the "owned" status? (I'm using DF 0.43.03 with DFHack 0.47.03-beta1).

Then a more general question. Is there a "useful resource" when looking for documentation regarding programming LUA in connection with DFHack.
I was looking at: https://dfhack.readthedocs.io/en/stable/docs/Lua API.html
and I'm currently browsing the available scripts already provided by DFhack. But this is quite cumbersome and may not always be lead to success.

some examples, where I was struggling to find a solution:

Code: [Select]
item:getMaterial() == df.builtin_mats.INORGANIC
What are other material types, I could check? I found "df.builtin_mats.COAL", but there should be much more.
I was looking for wood, leather, cloth, bone, glass, ....
 
I found a function
Code: [Select]
df.inorganic_raw.find(matIndex).material.state_name.Solid to get the material name for an inorganic item, if I have the materialIndex.

There are other "resources types" (cloth, thread, leather, bones,...) and was looking for a similar function to get the material name for "organic" materials, if I have the material index.
I found a global "df.material_common" which seems to get exported for DT, but I failed to get more information, what methods may be sent.


Any help is appreciated. Thanks in advance.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: HungThir on March 06, 2020, 03:05:36 am
I saw that there should be a flag "item.flags.owned". If I add this flag to the other flag checks, NO item will be printed. As I'm currently seeing items in dark yellow and red, there should always be printing something.

...

It seems, this flag is false for all items. Is this a bug? Does this flag represent something else? Is there another way to check the "owned" status? (I'm using DF 0.43.03 with DFHack 0.47.03-beta1).

i don't know, but i believe, that the owned flag refers to whether some dwarf "owns" the item (as in, the clothes and trinkets they wear/carry around or stash in their bedroom), not whether it belongs to the fort.  if i'm right, i wouldn't expect to see this flag on craft materials like bars or cloth, so it would make sense that your script prints no items
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on March 06, 2020, 03:40:43 am
Look at the item flags to try to figure out which ones you need.
in_job: already allocated, and so shouldn't be allocated again.
spider_web: Would include all the one in the caverns.
construction: used in construction, and thus not available.
encased: in magma. Obviously not available.
foreign: not made in the fortress.
trader: "owned" by traders. Sometimes set buggily on items that belonged to visitors that have ceased to be.
owned: belongs to someone, as HungTir said, and thus not available. I believe items carried/worn by visitors are owned by them as well.
artifact_mood: I assume this means in_job, but specifically for an artifact.

There are other flags that may be applicable for various purposes.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Alatun on March 06, 2020, 10:02:22 am
Thanks for your response.

So it seems there is no item flag that has the information whether the item is owned by the fort (as being indicated by the stockpile color red) and I must check other states that might block access.

Look at the item flags to try to figure out which ones you need.
That's part of the general question above. Where should I look up such an information?

Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Erendir on March 06, 2020, 01:24:03 pm
I recently (with 0.47 release) got interest in writing dfhack scripts (in Lua), an was facing same problems you do now.

The built-in `lua` REPL is actually a great help. F.e.

Code: [Select]
[DFHack]# lua
Type quit to exit interactive lua interpreter.
Shortcuts:
 '= foo' => '_1,_2,... = foo'
 '! foo' => 'print(foo)'
 '~ foo' => 'printall(foo)'
 '^ foo' => 'printall_recurse(foo)'
 '@ foo' => 'printall_ipairs(foo)'
All of these save the first result as '_'.
[lua]# ^ df.global.world.items.all[0]
gives me lots of info, especially interesting
Code: [Select]
flags                   = <item_flags: 00000206A2E739C0>
    artifact                = true
    artifact_mood           = true
flags2                  = <item_flags2: 00000206A2E739C4>

The types exist in Lua scope under `df`; flag types can be enumerated like this.

Code: [Select]
[lua]# @ df.item_flags

this prints a list with 32 flags with their names.

This was enough for me for the beginning, and then I switched to a full-text search for keywords in dfhack sources.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on March 06, 2020, 01:43:42 pm
Thanks for your response.

So it seems there is no item flag that has the information whether the item is owned by the fort (as being indicated by the stockpile color red) and I must check other states that might block access.

Look at the item flags to try to figure out which ones you need.
That's part of the general question above. Where should I look up such an information?
That's the part of the "try to figure out" above. You've got the names that somebody assigned at some time, which typically was done without writing a description of how that was done, although in some cases you may have comments in the XML files. From there you'll guess at the detailed meaning, and perform experiments to see if you've got it correctly.

For instance, if all webs are red, then you can assume the spider_web flag is one criterion of several that can cause the items to be colored red. If only some are red, then look at one uncollected web (e.g. in the cavern) and one collected web (in an inventory or workshop) and try to see which flags differ.

I use gui/gm-editor to look at things in DF.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Roses on March 06, 2020, 02:12:26 pm
Thanks for your response.

So it seems there is no item flag that has the information whether the item is owned by the fort (as being indicated by the stockpile color red) and I must check other states that might block access.

Look at the item flags to try to figure out which ones you need.
That's part of the general question above. Where should I look up such an information?
That's the part of the "try to figure out" above. You've got the names that somebody assigned at some time, which typically was done without writing a description of how that was done, although in some cases you may have comments in the XML files. From there you'll guess at the detailed meaning, and perform experiments to see if you've got it correctly.

For instance, if all webs are red, then you can assume the spider_web flag is one criterion of several that can cause the items to be colored red. If only some are red, then look at one uncollected web (e.g. in the cavern) and one collected web (in an inventory or workshop) and try to see which flags differ.

I use gui/gm-editor to look at things in DF.

Or to be more explicit, there isn't anywhere you can go to look up that information (very rarely there will be comments in the df-structures xml files (https://github.com/DFHack/df-structures), but that is the exception not the rule). It's basically just experimenting through look ups to figure the stuff out.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Alatun on March 06, 2020, 03:28:22 pm
Thanks for your replies, Erendir, PatrikLundell, Roses. I've already done some small scripts by experimenting, reading scripts of others. Sometimes I had the feeling I was running against a wall, because after a whole evening of trial and error, I hardly got 20-30 lines of working code. So the question was: did I overlook something? This should be easier. But it seems, I need to develop more skill in researching the available code base.

I recently (with 0.47 release) got interest in writing dfhack scripts (in Lua), an was facing same problems you do now.

The built-in `lua` REPL is actually a great help. F.e.
...
This was enough for me for the beginning, and then I switched to a full-text search for keywords in dfhack sources.

The LUA REPL looks promising, I will surely give it a try. I already tried to use the dfhack sources, but I was not able to make much use of that information in LUA so far. One of my approaches was to find the namespace the LUA interpreter is using to resolve the symbols being used in the LUA code. Any pointers here? Is this idea a dead end?

I use gui/gm-editor to look at things in DF.

Already did that for stuff related to creatures. But it seems, it is not really usefull for general world items. Am I overlooking something here, too?
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Roses on March 06, 2020, 03:42:20 pm
Thanks for your replies, Erendir, PatrikLundell, Roses. I've already done some small scripts by experimenting, reading scripts of others. Sometimes I had the feeling I was running against a wall, because after a whole evening of trial and error, I hardly got 20-30 lines of working code. So the question was: did I overlook something? This should be easier. But it seems, I need to develop more skill in researching the available code base.

I recently (with 0.47 release) got interest in writing dfhack scripts (in Lua), an was facing same problems you do now.

The built-in `lua` REPL is actually a great help. F.e.
...
This was enough for me for the beginning, and then I switched to a full-text search for keywords in dfhack sources.

The LUA REPL looks promising, I will surely give it a try. I already tried to use the dfhack sources, but I was not able to make much use of that information in LUA so far. One of my approaches was to find the namespace the LUA interpreter is using to resolve the symbols being used in the LUA code. Any pointers here? Is this idea a dead end?

I use gui/gm-editor to look at things in DF.

Already did that for stuff related to creatures. But it seems, it is not really usefull for general world items. Am I overlooking something here, too?

The df structures xml files are the actual variable name spaces being used by the dfhack lua, for instance, df.items.xml has
Code: [Select]
...
    <bitfield-type type-name='item_flags'>
        <flag-bit name='on_ground' comment='Item on ground'/>
        <flag-bit name='in_job' comment='Item currently being used in a job'/>
        <flag-bit name='hostile' comment='Item owned by hostile'/>
        <flag-bit name='in_inventory' comment='Item in a creature, workshop or container inventory'/>

        <flag-bit name='removed' comment='completely invisible and with no position'/>
        <flag-bit name='in_building' comment='Part of a building (including mechanisms, bodies in coffins)'/>
        <flag-bit name='container' comment='Set on anything that contains or contained items?'/>
        <flag-bit name='dead_dwarf' comment='Dwarfs dead body or body part'/>

        <flag-bit name='rotten' comment='Rotten food'/>
        <flag-bit name='spider_web' comment='Thread in spider web'/>
        <flag-bit name='construction' comment='Material used in construction'/>
        <flag-bit name='encased' comment='Item encased in ice or obsidian'/>

        <flag-bit name='unk12' comment='unknown, unseen'/>
        <flag-bit name='murder' comment='Implies murder - used in fell moods'/>
        <flag-bit name='foreign' comment='Item is imported'/>
        <flag-bit name='trader' comment='Item ownwed by trader'/>

        <flag-bit name='owned' comment='Item is owned by a dwarf'/>
        <flag-bit name='garbage_collect' comment='Marked for deallocation by DF it seems'/>
        <flag-bit name='artifact' comment='Artifact'/>
        <flag-bit name='forbid' comment='Forbidden item'/>

        <flag-bit name='already_uncategorized' comment='unknown, unseen'/>
        <flag-bit name='dump' comment='Designated for dumping'/>
        <flag-bit name='on_fire' comment='Indicates if item is on fire, Will Set Item On Fire if Set!'/>
        <flag-bit name='melt' comment='Designated for melting, if applicable'/>

        <flag-bit name='hidden' comment='Hidden item'/>
        <flag-bit name='in_chest' comment='Stored in chest/part of well?'/>
        <flag-bit name='use_recorded' comment='transient in unit.used_items update'/>
        <flag-bit name='artifact_mood' comment='created by mood/named existing item'/>

        <flag-bit name='temps_computed' comment='melting/boiling/ignite/etc. points'/>
        <flag-bit name='weight_computed'/>
        <flag-bit name='unk30' comment='unknown, unseen'/>
        <flag-bit name='from_worldgen' comment='created by underground critters?'/>
    </bitfield-type>
...

while df.item-raws.xml has
Code: [Select]
...
    <enum-type type-name='item_type' base-type='int16_t'>
        <enum-attr name='caption'/>
        <enum-attr name='is_rawable' type-name='bool'/>
        <enum-attr name='is_stackable' type-name='bool'/>
        <enum-attr name='is_caste_mat' type-name='bool'
                   comment='instead of material, uses a creature/caste pair'/>
        <enum-attr name='classname'/>

        <enum-item name='NONE' value='-1'/>
        <enum-item name='BAR' comment='Bars, such as metal, fuel, or soap.'>
            <item-attr name='caption' value='bars'/>
            <item-attr name='classname' value='item_barst'/>
        </enum-item>
        <enum-item name='SMALLGEM' comment='Cut gemstones usable in jewelers workshop'>
            <item-attr name='caption' value='cut gem'/>
            <item-attr name='classname' value='item_smallgemst'/>
        </enum-item>
        <enum-item name='BLOCKS' comment='Blocks of any kind.'>
            <item-attr name='caption' value='blocks'/>
            <item-attr name='classname' value='item_blocksst'/>
        </enum-item>
        <enum-item name='ROUGH' comment='Rough gemstones.'>
            <item-attr name='caption' value='rough gem'/>
            <item-attr name='classname' value='item_roughst'/>
        </enum-item>
        <enum-item name='BOULDER' comment='Raw mined stone.'>
            <item-attr name='caption' value='boulder'/>
            <item-attr name='classname' value='item_boulderst'/>
        </enum-item>
        <enum-item name='WOOD' comment='Wooden logs.'>
            <item-attr name='caption' value='logs'/>
            <item-attr name='classname' value='item_woodst'/>
        </enum-item>
...

It can be difficult to parse through the files since there is a lot of information, and only some of them have comments, but I pretty much am always looking through those files
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on March 06, 2020, 04:53:58 pm
gui/gm-editor can show the info about items just the same way it can show info about creatures. The difference is that you'd have to have the right viewing mode in DF, so for a creature it would be 'v', while for an item it would be 'k', and I think workshops show different info with 'k' and 't'.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Alatun on March 06, 2020, 05:30:21 pm

The df structures xml files are the actual variable name spaces being used by the dfhack lua, for instance, df.items.xml ...

I did a git clone of dfhack and found nothing. Until I discovered a few minutes ago that there is another repo, which contains the xml files you mentioned:
https://github.com/DFHack/df-structures

It looks, like this is the key!


gui/gm-editor can show the info about items just the same way it can show info about creatures. The difference is that you'd have to have the right viewing mode in DF, so for a creature it would be 'v', while for an item it would be 'k', and I think workshops show different info with 'k' and 't'.

Another helpful hint. I was using it mostly from the units list, so I never had the idea to try it with other viewing modes.

Hopefully, with this information my progress will be better. Thanks guys.

Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Putnam on March 06, 2020, 10:35:03 pm
Uhh, someone said it outright but surrounded by other stuff so the flag you are looking for is "foreign". If that is false, then it is a fort item.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Atomic Chicken on March 07, 2020, 02:19:04 am
artifact_mood: I assume this means in_job, but specifically for an artifact.

No, this is set for any item that is a 'genuine' artifact, in the sense that it was produced via a strange mood, item creation interaction, etc as opposed to artifacts created by simply bestowing a name on items (which have the 'artifact' item flag set but lack 'artifact_mood'). If I remember correctly, artifact_mood is also what makes artifact items indestructible.


Another helpful hint. I was using it mostly from the units list, so I never had the idea to try it with other viewing modes.

Even more useful than that is the fact that you can use commands like "gui/gm-editor df.global", "gui/gm-editor df.global.world", "gui/gm-editor df.global.ui_advmode", "gui/gm-editor dfhack.gui.getCurViewscreen()", etc. I've got a whole bunch of these in hotkey form to facilitate research.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on March 07, 2020, 04:16:06 am
Thanks Atomic Chicken. I guess that illustrates the "try to figure out" part, including how it can lead you astray...
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Erendir on March 07, 2020, 05:31:21 am

The df structures xml files are the actual variable name spaces being used by the dfhack lua, for instance, df.items.xml ...

I did a git clone of dfhack and found nothing. Until I discovered a few minutes ago that there is another repo, which contains the xml files you mentioned:
https://github.com/DFHack/df-structures

It looks, like this is the key!

dfhack is using git submodules, they are a bit tricky, see dfhack docs (https://docs.dfhack.org/en/stable/docs/Compile.html#how-to-get-the-code) for how to:
Code: [Select]
git clone --recursive https://github.com/DFHack/dfhack
`recursive` is the important part.

On another note, Lua the programming language's name isn't an acronym (http://www.lua.org/about.html#name).
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Quietust on March 07, 2020, 09:49:05 am
So it seems there is no item flag that has the information whether the item is owned by the fort (as being indicated by the stockpile color red) and I must check other states that might block access.

In this case, you are correct - the criteria for "foreign" items in the stocks screen showing up Red is that they are stored in the inventory of a unit who is not a member of your fortress. Determining this involves looking at item.general_refs and following them until you get to the owner, then using a DFHack builtin function to tell you if that unit is a citizen.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Alatun on March 07, 2020, 02:19:36 pm
So it seems there is no item flag that has the information whether the item is owned by the fort (as being indicated by the stockpile color red) and I must check other states that might block access.

In this case, you are correct - the criteria for "foreign" items in the stocks screen showing up Red is that they are stored in the inventory of a unit who is not a member of your fortress. Determining this involves looking at item.general_refs and following them until you get to the owner, then using a DFHack builtin function to tell you if that unit is a citizen.

It seems I found a solution that works for me now:
Code: [Select]
not item.flags.rotten and not item.flags.dump and not item.flags.forbid and not item.flags.construction and not item.flags.trader and not item.flags.spider_web
If it turns out, that this is not enough I will try to add your proposal. Thx.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: ragundo on March 07, 2020, 03:40:11 pm
If you are on Windows, you can take also a look at my plugin Dwarfexplorer (I need to promote it  ;D)

(https://i.imgur.com/JzlZyp1.png)

You get:
https://github.com/ragundo/DwarfExplorer

Also I'm working actively right now in the version 2 of the plugin which features:

(https://i.imgur.com/vcG7GwB.png)





Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Erendir on March 08, 2020, 04:09:49 am
this Dwarfexplorer looks very promising. Unfortunately, the v1.2 release's `DwarfExplorer_0.44.07_Win64.zip` doesn't include the `qapplication.plug.dll`, and v1.1's is compiled against dfhack 0.44.12-r3 and wouldn't work with 0.47.03-beta1.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: ragundo on March 08, 2020, 04:47:25 am
this Dwarfexplorer looks very promising. Unfortunately, the v1.2 release's `DwarfExplorer_0.44.07_Win64.zip` doesn't include the `qapplication.plug.dll`, and v1.1's is compiled against dfhack 0.44.12-r3 and wouldn't work with 0.47.03-beta1.

Yes, you are right. I always forgot to include that dependency :o
I released a new version with the missing dll.

https://github.com/ragundo/DwarfExplorer/releases/tag/v1.2.1 (https://github.com/ragundo/DwarfExplorer/releases/tag/v1.2.1)

Thanks for the info.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Alatun on March 08, 2020, 06:53:50 am
I've encountered a "stuck caravan" problem, that matches this thread: http://www.bay12forums.com/smf/index.php?topic=128968.0

My fort is about 5 years old and a human caravan arrived in April. In the mid of May the caravan was about to leave as a werebeast arrived. I had stationed a military squad at the fort entry and after a short fight the beast was dead. But the caravan did not leave. I don't know if the beast is related to the caravan problem, but this is at least peculiar. The werebeast never made it to the depot.

Some members of the caravan leading Yaks are standing inside the walkway between the fort entry and the depot, but the wagons are still at the depot. I did not care about the caravan, because such delays sometimes happen.
But now it's June and food brought by the caravan is starting to rot and clouds of miasma are now making my dwarfs unhappy. I tried to dump the rotten stuff, but nothing happens.

There is a dfhack script, that should fix merchant stuck when entering the map. I tried it and it reported "4 wagons being removed", but the caravan is still stuck.

Deconstructing the depot seems to fix the problem, but in some other thread this "fix" was considered harmful regarding the relations to the Civ the caravan belongs to, so I wanted to avoid that.

I've written a small script that lets me dump the rotten stuff, so I can solve the miasma problem at least:
Code: [Select]
local utils = require('utils')

for i,item in ipairs(df.global.world.items.all) do
    if item.flags.rotten and item.flags.on_ground and item.flags.trader then
         for k = #item.general_refs-1, 0, -1 do
            if (item.general_refs[k].entity_id == 244) then  -- human civ
                print(utils.getItemDescription(item,0)..' '..tostring(item:getStackSize()))
                item.flags.dump = true
                item.flags.forbid = false
                item.flags.trader = false
                item.flags.foreign = false
                item.general_refs:erase(k)
            end
        end
    end
end

After a while I discovered that there are "4 deceased wagons" in the list of "dead/missing" units. Probably these are the units the "fix merchant" scrip" tried to fix/remove. dfHack's deathcause does not reveal and reason:
"The wagon died in year 255 (cause: none)." So most likely something weird must have happened, that the wagons "died" and this seems to have caused the trouble. Any ideas how to fix this? Is there a way to "revive" the wagons (toggling the "killed" flag is not sufficient).
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Bumber on March 08, 2020, 07:31:16 am
Is there a way to "revive" the wagons (toggling the "killed" flag is not sufficient).

"full-heal" command?
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Alatun on March 08, 2020, 07:45:46 am
Is there a way to "revive" the wagons (toggling the "killed" flag is not sufficient).

"full-heal" command?

full-heal currently does not work with wagons. There is a check, that prevents this (for whatever reason).

Code: [Select]
if unit.flags2.killed and not unit.flags3.scuttle then -- scuttle appears to be applicable to just wagons, which probably shouldn't be resurrected

EDIT:
I removed the check and tried the full-heal. I don't know if it really succeeded, but it did not fix the "stuck caravan" problem.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Atomic Chicken on March 08, 2020, 09:36:02 am
full-heal currently does not work with wagons. There is a check, that prevents this (for whatever reason).

I added that check whilst implementing the arg that allows full-heal to target all the units on the map, after accidentally resurrecting a herd of scuttled wagons during testing. I assumed that most players would consider wagon resurrection to be a buggy quirk of the script, especially since the resurrected wagons are weird single-tile units that don't act as one might expect.

I removed the check and tried the full-heal. I don't know if it really succeeded, but it did not fix the "stuck caravan" problem.

I don't know whether resurrecting wagons is going to solve your problem, but removing the scuttle check should have been sufficient. Did you remember to add -r in addition to selecting the target unit?

There is a dfhack script, that should fix merchant stuck when entering the map. I tried it and it reported "4 wagons being removed", but the caravan is still stuck.


What version are you running? As far as I can tell, "fix/stuck-merchants.lua" only works on merchants which are stuck outside the local map, and "fix/merchants.lua" supposedly allows humans to make trade agreements; neither is relevant in this case.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Alatun on March 08, 2020, 10:05:41 am
I removed the check and tried the full-heal. I don't know if it really succeeded, but it did not fix the "stuck caravan" problem.

I don't know whether resurrecting wagons is going to solve your problem, but removing the scuttle check should have been sufficient. Did you remember to add -r in addition to selecting the target unit?

What version are you running? As far as I can tell, "fix/stuck-merchants.lua" only works on merchants which are stuck outside the local map, and "fix/merchants.lua" supposedly allows humans to make trade agreements; neither is relevant in this case.

I'm running 0.47.03.

I just tried the "wagon resurrection" a second time (with -r) to make sure, I did not make a mistake the first time. But no luck so far. It seems the death of the wagons has broken something. I tried to understand what the  "fix/stuck-merchants.lua" script is doing and it only sets the "left" flag, which is surely not a solution here.

My current assumption, why the caranvan is stuck could be:
- when looking at the depot it tells "no merchants trading"
- when using "t" to examine the building a lot of items are still listed with the "trading" flag.

Maybe because the caravan has no capacity to put all the stuff somewhere (as the wagons are no longer available) they won't leave. When the depot is deconstructed all the items will be removed from the building and probably no longer belong to the caravan, so the caravan will start moving again.

I'm just working on a script to remove all the foreign items lying on the ground and that are in the depot. Maybe this way I get them moving without affecting relations.

EDIT: It seems my assumption was correct. With the following script, the caravan starts moving! Maybe some "script expert" can take a look, if I'm doing something wrong, since this is the first script I'm manipulating/modifying internal structures.
Code: [Select]
local utils = require('utils')

function mark_dumped(aitem)
    aitem.flags.dump = true
    aitem.flags.forbid = false
    aitem.flags.trader = false
    aitem.flags.foreign = false
end

for i,item in ipairs(df.global.world.items.all) do
    -- item.flags.rotten and
    if item.flags.on_ground and item.flags.trader and not item.flags.container then
        if #item.general_refs>0 and (item.general_refs[0].entity_id == 244) then
            print(utils.getItemDescription(item,0)..' '..tostring(item:getStackSize()))
            mark_dumped(item)
            item.general_refs:erase(0)
        end
    end
    if item.flags.on_ground and item.flags.trader and item.flags.container then
        if #item.general_refs>0 and (item.general_refs[0].entity_id == 244) then
            print(utils.getItemDescription(item,0)..' '..tostring(item:getStackSize()))
            for k = #item.general_refs-1 , 0, -1 do
                if item.general_refs[k]._type == df.general_ref_contains_itemst then
                    local item_id = item.general_refs[k].item_id
                    local cont_item = df.item.find(item_id)
                    print(' ',utils.getItemDescription(cont_item,0)..' '..tostring(cont_item:getStackSize()))
                    mark_dumped(cont_item)
                end
                item.general_refs:erase(0)
                mark_dumped(item)
            end
        end
    end
end
-- remove all items stuck in depot

local depot_items = df.global.world.buildings.other.TRADE_DEPOT[0].contained_items

for k = #depot_items-1 , 0, -1 do
    local item = depot_items[k].item
    print(tostring(item))
    print(utils.getItemDescription(item,0))
    if item.flags.trader then
        mark_dumped(item)
        depot_items:erase(k)
    end
end
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Rumrusher on March 08, 2020, 01:05:02 pm
ok so it seems advfort got broke because unit_action.data.job is currently unit_action.data.Job due to all the unit action data names got capitalized between 47.03 and 47.04 so heads up this might break some scripts if they need to use actions.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: feelotraveller on March 08, 2020, 01:34:25 pm
So Stonesense.  (No it's not crashing.  ;))

Using dfhack-0.47.04-alpha0-200308001-Linux-64-gcc-7 (although its been this way for quite a while) I noticed that what are presumably meant to be symlinks to the appropriate libraries are unpacked as plain text files on my system, this explains the messages in the stderr.log
Code: [Select]
./hack/libs/liballegro.so.5.0: file too short
Can't load plugin stonesense
This is just a heads up about something I noticed while digging for what is my real question -

How do I disable stonesense from attempting to load when I start dfhack?

I couldn't find anything in the inits or startup scripts but it is possible that I missed something...
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on March 08, 2020, 02:22:11 pm
So Stonesense.  (No it's not crashing.  ;))

Using dfhack-0.47.04-alpha0-200308001-Linux-64-gcc-7 (although its been this way for quite a while) I noticed that what are presumably meant to be symlinks to the appropriate libraries are unpacked as plain text files on my system, this explains the messages in the stderr.log
Code: [Select]
./hack/libs/liballegro.so.5.0: file too short
Can't load plugin stonesense
This is just a heads up about something I noticed while digging for what is my real question -

How do I disable stonesense from attempting to load when I start dfhack?

I couldn't find anything in the inits or startup scripts but it is possible that I missed something...

All plugins in the hack/plugins folder that end with the correct extension (.plug.so on Linux) are loaded when DFHack starts. The only way to prevent this is by changing the plugin's extension or removing it from the plugins folder.

Regarding the symlink issue, what are you using to extract the DFHack package? All of the releases are built on Linux, so symlinks should be preserved.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: feelotraveller on March 08, 2020, 02:41:28 pm
Brillant, thanks on both accounts.

Renaming the stonesense.plugin.so works for me :).  I was using p7zip (laziness since I use it to unzip)  :-[, using untar preserves the symlinks correctly.  My bad.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Morning_Oak on March 08, 2020, 03:35:04 pm
I have a question regarding the gui/create-item command, I hope it's ok to ask here. I have created a handful of various gemstone warhammers for my militia squad in fort mode, and I cannot get the dwarves to equip the weapons. I have tried naming each of the hammers and then gifting them to one of my dwarves, then switching back to see if they would be more inclined to use them but they won't even store them in my weapons stockpile. They are scattered around the map & show up in my Artifacts menu, so at the very least the game seems them for what they are. I can't select the hammers in the Specific Weapons menu (nor any weapons, it seems to kick the menu back to the starting squad screen when I try to select that option). Anything I can do using gm-editor or something similar to get these hammers to be recognized as available for my dwarves so I can have them equip them?
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on March 08, 2020, 04:20:48 pm
It might be related to the material - do hammers you create using the same process but made out of metal work?
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: darkhog on March 09, 2020, 09:47:16 am
Any news on 47.04 or have you paused development until interim builds (if any) are done?
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: jecowa on March 09, 2020, 10:16:28 am
The Nightly Builds are on 0.47.04. The most recent one came out yesterday.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Kraiger on March 09, 2020, 01:01:24 pm
I do not understand how to compile/build the latest release from the github. I have even downloaded the main folder and all of the programs necessary to perform the task, but I fail to comprehend what needs to be done.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: jecowa on March 09, 2020, 01:07:18 pm
I've never been able to build a completely-working version either. There's a link to the latest pre-built versions on the original post.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Kraiger on March 09, 2020, 01:16:56 pm
I see. Totally missed that the first time I went to the Nightly Builds site. Thanks!
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Taras on March 09, 2020, 02:07:03 pm
How automatically butcher sentient corpses?
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on March 09, 2020, 03:48:25 pm
How automatically butcher sentient corpses?
You can't in vanilla. Ask in the mod section. There's a bunch of people there obsessed with that issue, so they may or may not know.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on March 09, 2020, 06:27:08 pm
I do not understand how to compile/build the latest release from the github. I have even downloaded the main folder and all of the programs necessary to perform the task, but I fail to comprehend what needs to be done.
Does https://docs.dfhack.org/en/stable/docs/Compile.html help? What OS are you building on? If you have any specific questions about it, we'd be happy to answer them. It should build on all supported OSes, as far as I know.
(If you're okay with a nightly build, though, it probably doesn't matter.)
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Putnam on March 10, 2020, 11:15:58 pm
I've personally never managed to get that working on windows 10 64-bit but I figure that's because I've already messed up my setup's C++ environment in a variety of strange ways.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: thurin on March 11, 2020, 01:24:41 am
I can try to help out with any build issues on the different platforms if you'd like.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on March 11, 2020, 03:11:42 am
I've personally never managed to get that working on windows 10 64-bit but I figure that's because I've already messed up my setup's C++ environment in a variety of strange ways.
Microsoft has changed things with MSVC since the documentation for DFHack were written, but I eventually managed to get the installation to work and DFHack to build on a new computer (requiring quite a few attempts to get all the parts needed installed. Windows 7 support in particular is required, but the errors resulting from not having it give no clue whatsoever about that being the cause. For MSVC 2017 I ended up with an everything and the kitchen sink installation rather than trying to guess what's needed, and I think Windows 7 support still needed to be added).
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: HungThir on March 12, 2020, 12:22:27 am
is there known yet a way to determine which god a particular divination shrine/die belongs to (in adventure mode)?

considering the risk of rolling the same god’s dice more than twice, i think that info would make for a pretty useful ui addon
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Warmist on March 14, 2020, 04:54:28 am
Random thing i noticed: fixing advfort and you char keeps moving around (maybe because of companion) while working.

Edit: yeah it's just default DF - while waiting companions/pets move you, or your char moves somewhat...
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Fatace on March 14, 2020, 03:20:02 pm
Out of curiosity, is there a line of code that I could remove within the Full-Heal.lua script that will remove the resetting of syndromes applied? (meaning, so when its used, syndromes such as secrets wont be removed upon being used on the character). and Yeah im aware that counts towards all syndromes.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: thefriendlyhacker on March 15, 2020, 01:25:43 pm
Is it intended that eventful's onUnload triggers every time a site is offloaded in adventure mode? The documentation doesn't actually say what it does, but I have only ever seen it used as if it is only meant to run on unloading the entire world (i.e. when the user saves and quits to main menu or ends their run with that fort/adventurer). As such, a lot of dfhack scripts break as soon as you travel through the travel screen, since moving even a single tile unloads the current site. This happens on the current 0.47.03-beta1 version, but I set up an older version of df/dfhack and confirmed that this behavior was also present in 0.44.12.

Out of curiosity, is there a line of code that I could remove within the Full-Heal.lua script that will remove the resetting of syndromes applied? (meaning, so when its used, syndromes such as secrets wont be removed upon being used on the character). and Yeah im aware that counts towards all syndromes.
I took a skim through the full-heal script then did a quick arena test to be sure, and there doesn't seem to be anything in that script that touches syndromes at all.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Fatace on March 15, 2020, 02:07:29 pm
Wait, then how are syndromes being removed/reset from a creature then when its used? o_o
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: thefriendlyhacker on March 15, 2020, 03:08:26 pm
I took a look at what it does edit to see if any of it links to syndromes indirectly, and it looks like wounds are created for syndromes. What might be happening is that some syndrome effects reference either just the wound or both the wound and the syndrome, and deleting the wound breaks those effects. However, I tried a couple of tests and full heal only deleted those wounds for a single tick - they were back again in the wounds vector the next tick, and stuff like nausea was applied properly despite being momentarily removed by full-heal. I wouldn't be surprised if the recreation of syndrome related wounds and the correct reapplication of the associated effects wasn't universal, though.

If that is what is creating your problem, then the fix for full-heal would require skipping the deletion of wounds that have associated syndromes. This may potentially lead to undefined behavior when it comes to things like werecreature bites, however, since as far as I know wounds created by those would have both a syndrome and "conventional" wound info (or it might be fine, who knows).

Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Warmist on March 15, 2020, 03:26:30 pm
Is it intended that eventful's onUnload triggers every time a site is offloaded in adventure mode? The documentation doesn't actually say what it does, but I have only ever seen it used as if it is only meant to run on unloading the entire world (i.e. when the user saves and quits to main menu or ends their run with that fort/adventurer). As such, a lot of dfhack scripts break as soon as you travel through the travel screen, since moving even a single tile unloads the current site. This happens on the current 0.47.03-beta1 version, but I set up an older version of df/dfhack and confirmed that this behavior was also present in 0.44.12.
<...>

Afaik it was always that way. In the source (not eventful as it wraps (among other stuff) eventmanager module)  here  (https://github.com/DFHack/dfhack/blob/develop/library/modules/EventManager.cpp#L210) it's called more explicit: SC_MAP_UNLOADED.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on March 15, 2020, 03:36:33 pm
Yeah, map unloads happen a lot more frequently in adventure mode than fortress mode. What kinds of scripts are breaking specifically?
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Atomic Chicken on March 15, 2020, 04:49:34 pm
I took a look at what it does edit to see if any of it links to syndromes indirectly, and it looks like wounds are created for syndromes. What might be happening is that some syndrome effects reference either just the wound or both the wound and the syndrome, and deleting the wound breaks those effects. However, I tried a couple of tests and full heal only deleted those wounds for a single tick - they were back again in the wounds vector the next tick, and stuff like nausea was applied properly despite being momentarily removed by full-heal. I wouldn't be surprised if the recreation of syndrome related wounds and the correct reapplication of the associated effects wasn't universal, though.

If that is what is creating your problem, then the fix for full-heal would require skipping the deletion of wounds that have associated syndromes. This may potentially lead to undefined behavior when it comes to things like werecreature bites, however, since as far as I know wounds created by those would have both a syndrome and "conventional" wound info (or it might be fine, who knows).

This is correct; most of the effects of a syndrome are mediated through a special wound created upon infection (via the wound_curse_info data), and deleting this wound hence removes the pertinent syndrome effects. However, the persistence of the syndrome within unit.syndromes causes the generation of a new wound as soon as the game realises that this is missing. (Similarly, the early version of syndrome-utils consistently failed at properly removing syndromes as it deleted the syndrome data whilst leaving the wound untouched). The issue is rather easy to solve; just add an "if not wound.curse" check and clear any actual injury data instead of deleting the wound outright in that case. In addition, thorough syndrome removal could be implemented and made optional via a separate arg, possibly with the option of whitelisting certain syndromes to prevent their deletion (specified by syndrome name or class). Thoughts?

Afaik it was always that way. In the source (not eventful as it wraps (among other stuff) eventmanager module)  here  (https://github.com/DFHack/dfhack/blob/develop/library/modules/EventManager.cpp#L210) it's called more explicit: SC_MAP_UNLOADED.

Why is SC_MAP_UNLOADED used as opposed to SC_WORLD_UNLOADED? It seems to me that the latter would surely make more sense in the context of adventure mode, with no difference in fort mode functionality (I think).
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Warmist on March 16, 2020, 01:00:59 am
<...>
Afaik it was always that way. In the source (not eventful as it wraps (among other stuff) eventmanager module)  here  (https://github.com/DFHack/dfhack/blob/develop/library/modules/EventManager.cpp#L210) it's called more explicit: SC_MAP_UNLOADED.

Why is SC_MAP_UNLOADED used as opposed to SC_WORLD_UNLOADED? It seems to me that the latter would surely make more sense in the context of adventure mode, with no difference in fort mode functionality (I think).

Both have their uses. However most stuff is developed without adventure mode in mind. I.e. what scripts are braking? Why are they running in adventure mode in first place?

Also IIRC map unload might still have useful data not destroyed, while world unload would have more stuff unavailable (same applies to map vs world load).
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: thefriendlyhacker on March 16, 2020, 04:27:25 am
<...>
Afaik it was always that way. In the source (not eventful as it wraps (among other stuff) eventmanager module)  here  (https://github.com/DFHack/dfhack/blob/develop/library/modules/EventManager.cpp#L210) it's called more explicit: SC_MAP_UNLOADED.

Why is SC_MAP_UNLOADED used as opposed to SC_WORLD_UNLOADED? It seems to me that the latter would surely make more sense in the context of adventure mode, with no difference in fort mode functionality (I think).

Both have their uses. However most stuff is developed without adventure mode in mind. I.e. what scripts are braking? Why are they running in adventure mode in first place?
...
modtools/item-trigger breaks, for starters. All the set item triggers get cleared on site offloading.

The scripts interaction-trigger, random-trigger, syndrome-trigger, projectile-trigger and outside-only (all modtools scripts) use the same style of clearing triggers using onUpload, and thus have the same problem.

modtools/reaction-trigger and modtools/reaction-product-trigger are exceptions solely because they currently do not support adventure mode at all. If support was added (AFAICT just handling reactions/jobs without associated buildings), then they would have the same problem.

modtools/invader-item-destroyer also has the same problem, but frankly I have no idea how adventure mode armies/invasions work so I can't say whether this even should be running at all in adventure mode. EDIT: I suppose the same goes for outside-only, should it even run in adv mode?

These are all the scripts that use onUpload, according to the github search I did. Every script that touches onUpload uses it as if it is synonymous with leaving a world, and as such every one of those scripts that could apply to adventure mode breaks as soon as a site is offloaded.

EDIT:
The issue is rather easy to solve; just add an "if not wound.curse" check and clear any actual injury data instead of deleting the wound outright in that case.
Would that play nicely with syndromes that do stuff on a body part by body part basis? Like, say, bruising or blistering whatever body parts the syndrome's material comes in contact with?
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Roses on March 19, 2020, 10:43:39 am
<...>
Afaik it was always that way. In the source (not eventful as it wraps (among other stuff) eventmanager module)  here  (https://github.com/DFHack/dfhack/blob/develop/library/modules/EventManager.cpp#L210) it's called more explicit: SC_MAP_UNLOADED.

Why is SC_MAP_UNLOADED used as opposed to SC_WORLD_UNLOADED? It seems to me that the latter would surely make more sense in the context of adventure mode, with no difference in fort mode functionality (I think).

Both have their uses. However most stuff is developed without adventure mode in mind. I.e. what scripts are braking? Why are they running in adventure mode in first place?
...
modtools/item-trigger breaks, for starters. All the set item triggers get cleared on site offloading.

The scripts interaction-trigger, random-trigger, syndrome-trigger, projectile-trigger and outside-only (all modtools scripts) use the same style of clearing triggers using onUpload, and thus have the same problem.

modtools/reaction-trigger and modtools/reaction-product-trigger are exceptions solely because they currently do not support adventure mode at all. If support was added (AFAICT just handling reactions/jobs without associated buildings), then they would have the same problem.

modtools/invader-item-destroyer also has the same problem, but frankly I have no idea how adventure mode armies/invasions work so I can't say whether this even should be running at all in adventure mode. EDIT: I suppose the same goes for outside-only, should it even run in adv mode?

These are all the scripts that use onUpload, according to the github search I did. Every script that touches onUpload uses it as if it is synonymous with leaving a world, and as such every one of those scripts that could apply to adventure mode breaks as soon as a site is offloaded.
I believe all of those scripts were originally just made with fort mode in mind (Expwnent was the author for most of them IIRC). It probably would be a good idea to update them though so that they don't break in adventure mode

EDIT:
The issue is rather easy to solve; just add an "if not wound.curse" check and clear any actual injury data instead of deleting the wound outright in that case.
Would that play nicely with syndromes that do stuff on a body part by body part basis? Like, say, bruising or blistering whatever body parts the syndrome's material comes in contact with?
Sort of. Syndromes are notoriously tricky in their application and removal, although removal usually is easier. You will typically just get a single wound with a single syndrome, but for each instance of the syndrome you can get a different wound for a different body part. I'm not sure if syndrome-util handles all of that (I know it was previously not working for any syndromes that needed to function through wounds, both for application and removal), but you should be able to handle removal fairly easily with a lua script
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Rumrusher on March 21, 2020, 03:10:36 am
then there's the historical figure syndromes and interactions that come back on reload of the map or a while if you use any heal script.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on March 21, 2020, 05:54:30 am
I cooked up a script to dampen the not quite regular loyalty cascade conflicts that seems to have become more common:
It seemed to work on two test cases, although I had to reapply the script when a character died (anyway?) in one case.
Spoiler (click to show/hide)
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Lewa263 on March 23, 2020, 03:48:13 pm
Does anybody know of a nightly build with a working exportlegends command, that gives functional XML files for Legends Viewer? I had it working fine a little over a week ago, but all the more recent builds seem to be unable to generate the files correctly. I don't know which build it was that I got it to work on, so I guess I'm just hoping that somebody else still has a build where it works and can give me the number for it.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on March 23, 2020, 03:58:58 pm
Does anybody know of a nightly build with a working exportlegends command, that gives functional XML files for Legends Viewer? I had it working fine a little over a week ago, but all the more recent builds seem to be unable to generate the files correctly. I don't know which build it was that I got it to work on, so I guess I'm just hoping that somebody else still has a build where it works and can give me the number for it.
If you have problems, please report them. Nobody's going to fix problems unless they're reported or accidentally detected by someone who actually goes about fixing the issues.

Having said that, I made a pull request 12 hour ago or so for an updated version that fixes the things I encountered. Due to the way DF is organized, it won't appear in a "nightly build" until it's been approved and then "imported" into the main DFHack repository. However, it should be possible for you to get that version off of Github to see if it works for your problems. The good thing with scripts is that they don't need to be compiled, so you don't need the rest of the infrastructure. The bad thing with scripts is that they're not compiled, so there is no compiler available to flag things that don't compile (any longer).
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Lewa263 on March 23, 2020, 04:34:57 pm
Does anybody know of a nightly build with a working exportlegends command, that gives functional XML files for Legends Viewer? I had it working fine a little over a week ago, but all the more recent builds seem to be unable to generate the files correctly. I don't know which build it was that I got it to work on, so I guess I'm just hoping that somebody else still has a build where it works and can give me the number for it.
If you have problems, please report them. Nobody's going to fix problems unless they're reported or accidentally detected by someone who actually goes about fixing the issues.

Having said that, I made a pull request 12 hour ago or so for an updated version that fixes the things I encountered. Due to the way DF is organized, it won't appear in a "nightly build" until it's been approved and then "imported" into the main DFHack repository. However, it should be possible for you to get that version off of Github to see if it works for your problems. The good thing with scripts is that they don't need to be compiled, so you don't need the rest of the infrastructure. The bad thing with scripts is that they're not compiled, so there is no compiler available to flag things that don't compile (any longer).

OK, I don't have much useful to give as a bug report because most of this stuff is beyond my understanding. But here's a screenshot of the error that I get with the current build 200322005: https://imgur.com/a/Z9cq8p4 (https://imgur.com/a/Z9cq8p4). Before I downloaded that one, the other nightly build that I had wouldn't give any errors in the DFHack window, but Legends Viewer would always say the file needed repair when it got down to the Events part. Allowing it to attempt a repair never accomplished anything, which was disappointing but not surprising. I have to assume the problem there was still on the DFHack side, because I didn't have that problem before I downloaded a newer build. I should probably stop doing that just because it's new and there are green checks on the nightly build site.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on March 24, 2020, 12:32:11 am
Thanks - PatrikLundell fixed it here (https://github.com/DFHack/scripts/pull/135). The error was probably causing the script to leave behind a partial/truncated XML file, which isn't exactly easy to repair. Build 200324000 (https://buildmaster.lubar.me/applications/3/builds/build?buildId=7480) should work (when it's done, anyway); hopefully newer versions don't break again.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on March 24, 2020, 01:46:08 am
And, for your information Lewa263, what's in the screenshot is exactly what we'd need to understand the problem in most cases.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Silverwing235 on March 24, 2020, 06:35:45 pm
*ahem* I wonder if, perhaps, a codeblock would also suffice as a substitute?  Like so:
Code: [Select]
...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:228: Cannot read field abstract_building_templest.deity: not found.
stack traceback:
        [C]: in metamethod '__index'
        ...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:228: in global 'export_more_legends_xml'
        ...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:826: in global 'export_legends_info'
        ...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:879: in local 'script_code'
        ...\DF4704W64VettlingrPack\df_47_04_win\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
        (...tail calls...)
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on March 24, 2020, 07:13:21 pm
*ahem* I wonder if, perhaps, a codeblock would also suffice as a substitute?  Like so:
Code: [Select]
...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:228: Cannot read field abstract_building_templest.deity: not found.
stack traceback:
        [C]: in metamethod '__index'
        ...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:228: in global 'export_more_legends_xml'
        ...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:826: in global 'export_legends_info'
        ...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:879: in local 'script_code'
        ...\DF4704W64VettlingrPack\df_47_04_win\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
        (...tail calls...)
Yes - in fact, text is usually better, in case we need to copy something from it. (It's a bit annoying to copy from the console on Windows - one way to do it is by right-clicking in the title bar, or maybe in the console too, depending on your Windows version.)
Also, is this a separate bug report? I'm not sure, but I'll double-check that part of the script to see if it's up-to-date.

Edit: your error appears to be related to something accessing the "deity" field, which the current version doesn't do - my advice (if you're experiencing the issue) is to try upgrading.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on March 25, 2020, 01:30:39 am
Expanding on lethosor's response, the field(s) Silverwing235's version of the script tries to read is most likely one that changed its name during the last month or so, and the current version of the script (well, as of about 24 hours ago, which is the latest time I synchronized the data) actually does provide the contents of the deity_type field as well as the deity_data.Deity one. Thus, the current version of the script should handle it correctly.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Fleeting Frames on March 25, 2020, 05:09:36 am
How automatically butcher sentient corpses?
This doesn't do it automatically (http://www.bay12forums.com/smf/index.php?topic=165414.msg7553808#msg7553808), but does make them butcherable as normal. This thread (http://www.bay12forums.com/smf/index.php?topic=78108) could be helpful for figuring out how to script making it happen automatically.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Silverwing235 on March 25, 2020, 06:04:07 am
*ahem* I wonder if, perhaps, a codeblock would also suffice as a substitute?  Like so:
Code: [Select]
...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:228: Cannot read field abstract_building_templest.deity: not found.
stack traceback:
        [C]: in metamethod '__index'
        ...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:228: in global 'export_more_legends_xml'
        ...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:826: in global 'export_legends_info'
        ...ettlingrPack\df_47_04_win/hack/scripts/exportlegends.lua:879: in local 'script_code'
        ...\DF4704W64VettlingrPack\df_47_04_win\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
        (...tail calls...)
Yes - in fact, text is usually better, in case we need to copy something from it. (It's a bit annoying to copy from the console on Windows - one way to do it is by right-clicking in the title bar, or maybe in the console too, depending on your Windows version.)
Also, is this a separate bug report? I'm not sure, but I'll double-check that part of the script to see if it's up-to-date.

Edit: your error appears to be related to something accessing the "deity" field, which the current version doesn't do - my advice (if you're experiencing the issue) is to try upgrading.
Was referring to Lewa263's musing, actually, but thanks. However, the problem then becomes either relying on Github (unsure if its to spec like you've stated) or digging for direct download links in the nightlies (worse than useless so far, it's a freaking warren).





























 
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on March 25, 2020, 07:53:33 am
Most scripts work only with the versions compatible with the part of the code they're supposed to work with, and there's no reason at all for scripts distributed with DFHack to explicitly support other versions (i.e. add additional scripting to handle variations). The DF structures have been in a bit of flux since 0.47.04 due to introduction of new background functionality to handle "tagged unions" better, naming essentially unnamed fields ("unknown1b", for instance), and renaming of a few fields with misleading/no longer correct names. This means that grabbing a script newer than the code base you're using will work only if the structures it was written for are included in your older code. A script fixed today for code you grabbed yesterday will probably work, but if the code was grabbed a week ago it depends. Due to DFHack being spread over 3 repositories, updates will be out of phase from time to time, as you need to have the structures in place when scripts using them are updated, and the scripts then have to be imported into the main repository (together with the structures, of course).
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Silverwing235 on March 25, 2020, 08:29:36 am
Most scripts work only with the versions compatible with the part of the code they're supposed to work with, and there's no reason at all for scripts distributed with DFHack to explicitly support other versions (i.e. add additional scripting to handle variations). The DF structures have been in a bit of flux since 0.47.04 due to introduction of new background functionality to handle "tagged unions" better, naming essentially unnamed fields ("unknown1b", for instance), and renaming of a few fields with misleading/no longer correct names. This means that grabbing a script newer than the code base you're using will work only if the structures it was written for are included in your older code. A script fixed today for code you grabbed yesterday will probably work, but if the code was grabbed a week ago it depends. Due to DFHack being spread over 3 repositories, updates will be out of phase from time to time, as you need to have the structures in place when scripts using them are updated, and the scripts then have to be imported into the main repository (together with the structures, of course).

Translating this into layman's terms, then...(stop me if I've got something wrong here):
As of 25/03, the current Git version is valid for using with Legends Viewer, due to subsequent fixing of the exportlegends issue I reported earlier, correct?

OTOH, the only kind of download links I could find in the nightlies were under 'Build Artifacts' (example (https://buildmaster.lubar.me/applications/3/builds/build?buildId=7490)) should I not have been doing that?
 
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on March 25, 2020, 08:39:21 am
"Build artifacts" is exactly where you should be looking; I'll add a note to the builds page.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Nilsolm on March 27, 2020, 07:21:05 am
A question: Would it be possible to implement a search functionality for the interrogation selection screen? It sounds like it could useful in 47.xx, so you don't have to sift through the entire unit list manually when you want to interrogate suspicious visitors or citizens
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on March 27, 2020, 09:25:44 am
I'm not familiar with that - is it an option in the adventure mode dialog menu or somewhere else? We can certainly take a look, although it might require additional research into adventure mode that we haven't done yet.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Silverwing235 on March 27, 2020, 09:31:52 am
More weirdness ahoy, frankly...
Code: [Select]
...op\dwarfplug\df_47_04_win/hack/scripts/exportlegends.lua:348: Cannot read field historical_entity.unknown1b: not found.
stack traceback:
        [C]: in metamethod '__index'
        ...op\dwarfplug\df_47_04_win/hack/scripts/exportlegends.lua:348: in global 'export_more_legends_xml'
        ...op\dwarfplug\df_47_04_win/hack/scripts/exportlegends.lua:906: in global 'export_legends_info'
        ...op\dwarfplug\df_47_04_win/hack/scripts/exportlegends.lua:959: in local 'script_code'
        ...kwell\Desktop\dwarfplug\df_47_04_win\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
        (...tail calls...)
...at first, I thought it was something to do with the 'histfig culling' protocol being active versus otherwise, apparently not.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on March 27, 2020, 09:40:35 am
That's the same as http://www.bay12forums.com/smf/index.php?topic=164123.msg8111921#msg8111921, which was already fixed.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Nilsolm on March 27, 2020, 09:41:24 am
I'm not familiar with that - is it an option in the adventure mode dialog menu or somewhere else? We can certainly take a look, although it might require additional research into adventure mode that we haven't done yet.

I meant the justice screen in fortress mode. When you convict/interrogate somebody, that screen will display a unit list on the right side that is a bit awkward to navigate and currently not searchable.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on March 27, 2020, 09:46:41 am
Ah! I've investigated that screen before, and that should be easier. Do you happen to have a save where that screen is available? Getting to that point could be a bit time-consuming.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Nilsolm on March 27, 2020, 10:38:44 am
Ah! I've investigated that screen before, and that should be easier. Do you happen to have a save where that screen is available? Getting to that point could be a bit time-consuming.

Not at the moment, unfortunately. I'll upload one if I get there.

Edit: Never mind, I managed to artificially create one by modifying remove-stress to increase stress, so dwarves start tantruming. Here it is: http://dffd.bay12games.com/file.php?id=14969
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Bloodyharbinger on March 27, 2020, 03:17:54 pm
Ah! I've investigated that screen before, and that should be easier. Do you happen to have a save where that screen is available? Getting to that point could be a bit time-consuming.
http://dffd.bay12games.com/file.php?id=14968

Loaded this save for a totally different issue, but if you want to see a full on Justice event involving investigations then you can check here.

This was started from a visitor stealing an artifact.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on March 27, 2020, 09:31:46 pm
I'm hoping to put up a "beta" release soon - we'd still like some help testing scripts on Windows (e.g. I'm unsure if feature and modtools/create-unit work yet) if anyone is able.

http://dffd.bay12games.com/file.php?id=14968
Heh, I have this one downloaded already! (Thanks Nilsolm too)

Update: turns out the interrogations list hadn't been identified at all, so that's fixed now. Adding search support should be doable.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Nilsolm on March 30, 2020, 05:56:27 am
Cheers! Are you planning on implementing it yourself? Otherwise, I'd try my hand at it as I was looking to contribute anyway.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on March 30, 2020, 02:10:37 pm
If you're interested, go for it! plugins/search.cpp is the place to look - there are a bunch of existing implementations for other screens there already.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Temujin on March 31, 2020, 03:05:29 pm
Hello, my apologies if this is the wrong place to ask this. . .

I would like to make two dwarves friends, but it seems that this is difficult as the friendship data is stored in history as a vector.   Is there a script that can accomplish this?

thanks for your help.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: PatrikLundell on March 31, 2020, 03:49:10 pm
I don't know if there's a ready made script for it, but you can use vanilla processes, assuming they have compatible personalities and don't dislike each other: Subject them to the Nuptial Encouragement Treatment, i.e. lock them up together with food, drinks and (their own) beds in a zone associated to the tavern and give them no work. The area should be fairly small (I use 3*3 bedrooms) so their socialization actually has some effect (the new version should have them be better at it in itself). Let them socialize for a few months, but if you want them to go no further than friendship you should break it off once they've reached that level, as they "risk" proceeding to lovers and marriage if compatible. Also make sure to check their food/drink stockpiles so they don't die of starvation/thirst.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Roses on April 01, 2020, 01:32:58 pm
I'm hoping to put up a "beta" release soon - we'd still like some help testing scripts on Windows (e.g. I'm unsure if feature and modtools/create-unit work yet) if anyone is able.

Forgive the question, as I was away from the forums for a bit and might have lost track of various conversations. Is this a plan for getting the 47.04 beta up? I am just wondering because I would like to test my scripts on the 47 version, but if the 04 beta is still a little ways out I will just test with the 03 version. I'm pretty sure all of my scripts will still work as intended, but I'm also looking at writing new ones and figured I'd move to a 47 version for that. I can test whatever is needed on Windows
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on April 01, 2020, 01:37:15 pm
It might be 2-3 days still - I got wrapped up in other things, and plan on merging in some more PRs before putting it out. I don't expect many breaking changes between .03 and .04, although I haven't written a changelog yet (which is honestly one of the more time-consuming parts).
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Roses on April 01, 2020, 02:16:52 pm
It might be 2-3 days still - I got wrapped up in other things, and plan on merging in some more PRs before putting it out. I don't expect many breaking changes between .03 and .04, although I haven't written a changelog yet (which is honestly one of the more time-consuming parts).

I hate writing changelogs, easily the worst part in my opining. I'm not in any immediate hurry, so I'll just wait for 04 whenever that comes out as it seems some of the pull requests are interesting. Thanks for all your hard work
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lastofthelight on April 01, 2020, 03:50:06 pm
Dumb question but: I'm trying to use the changelayer script, but dfhack doesn't recognize it. The error message suggests I try loading the script (though dfhack doesn't recognize load...) - but its irrelevent as I don't see any script file with that name in the appropriate directory. Anyone know where I could get a copy of the appropriate file, and what the alternative to LOAD is?

DFhack is not something I've messed with in a long, long time. Sorry for the dumb question.

Edit: This is going to sound even crazier, but though I made *100% sure* I wasn't typing changelayer wrong....its now recognizing the command, but claiming there's no such material. "changelayer marble" is all I'm trying to do.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Quietust on April 01, 2020, 04:05:30 pm
Dumb question but: I'm trying to use the changelayer script, but dfhack doesn't recognize it. The error message suggests I try loading the script (though dfhack doesn't recognize load...) - but its irrelevent as I don't see any script file with that name in the appropriate directory. Anyone know where I could get a copy of the appropriate file, and what the alternative to LOAD is?

DFhack is not something I've messed with in a long, long time. Sorry for the dumb question.

Edit: This is going to sound even crazier, but though I made *100% sure* I wasn't typing changelayer wrong....its now recognizing the command, but claiming there's no such material. "changelayer marble" is all I'm trying to do.

First, changelayer is a plugin, not a script. This is an important difference, because plugins are C++ and have to be recompiled for every DFHack version, while scripts are written in Lua and can usually be copied between different versions.

Second, changelayer wants the material's ID as specified in the raws (https://dwarffortresswiki.org/index.php/DF2014:Marble/raw), so you need to specify it as "MARBLE".
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: feelotraveller on April 01, 2020, 04:39:50 pm
Dumb question but: I'm trying to use the changelayer script, but dfhack doesn't recognize it. The error message suggests I try loading the script (though dfhack doesn't recognize load...) - but its irrelevent as I don't see any script file with that name in the appropriate directory. Anyone know where I could get a copy of the appropriate file, and what the alternative to LOAD is?

DFhack is not something I've messed with in a long, long time. Sorry for the dumb question.

Edit: This is going to sound even crazier, but though I made *100% sure* I wasn't typing changelayer wrong....its now recognizing the command, but claiming there's no such material. "changelayer marble" is all I'm trying to do.

Quietust already has your answer but for future reference I manage to answer most of my own 'dumb questions' by looking at the documentation, in this case http://docs.dfhack.org/en/stable/docs/Plugins.html#changelayer (http://docs.dfhack.org/en/stable/docs/Plugins.html#changelayer) is the charm.  :)
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on April 01, 2020, 04:51:09 pm
Dumb question but: I'm trying to use the changelayer script, but dfhack doesn't recognize it. The error message suggests I try loading the script (though dfhack doesn't recognize load...) - but its irrelevent as I don't see any script file with that name in the appropriate directory. Anyone know where I could get a copy of the appropriate file, and what the alternative to LOAD is?
Just curious, what exactly was the error message (if you still have it)? Since changelayer is a plugin, it does need to be loaded in order to work - but DFHack loads all plugins it can find on startup, so I'm not really sure why it wouldn't have been loaded.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Jan Kaspsan on April 02, 2020, 03:30:51 am
I'm new to using DFHack and I've been trying to use advfort, but I continue to get the error at the focus of this issue: https://github.com/DFHack/dfhack/issues/1520 . I have the most recent version of advfort from this commit: https://github.com/DFHack/scripts/commit/678c015e42a341ad350cc341b8325e579c76ef8f and I'm unsure if I missed a step here.
     
Spoiler (click to show/hide)
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Warmist on April 02, 2020, 03:38:15 am
...

Use one commit before (as the job re-rename is still not in dfhack). Also I suggest replacing all "local function" to just "function" as it breaks some stuff...
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Jan Kaspsan on April 02, 2020, 08:17:20 am
...

Use one commit before (as the job re-rename is still not in dfhack). Also I suggest replacing all "local function" to just "function" as it breaks some stuff...
It worked! Thank you, Warmist.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on April 02, 2020, 09:23:15 am
...

Use one commit before (as the job re-rename is still not in dfhack). Also I suggest replacing all "local function" to just "function" as it breaks some stuff...
Wait, what? I'm pretty sure I updated structures, and I tested that code snippet to make sure it worked.
Jan: You will have to upgrade DFHack, though - just upgrading the script won't work in this case.
Warmist: could you fix the function declarations when you get a chance? Thanks.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Jan Kaspsan on April 02, 2020, 04:37:40 pm
When I first commented I was using the "Vettlingr Returns" v2 tileset which includes some DFHack utilities:
http://dffd.bay12games.com/file.php?id=14952
I copied over the files from this commit:
https://github.com/DFHack/dfhack/tree/5598b332f20cd3addcdce59cc7bfc8d0b1d95a84
With this version of advfort:
https://github.com/DFHack/scripts/commit/678c015e42a341ad350cc341b8325e579c76ef8f
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on April 02, 2020, 06:09:24 pm
According to the DFFD description, that DFHack build is from March 22. Several fixes have been made since then, and yes, the new script won't work with the older DFHack.
In other news, I'm basically done with what I wanted to get in for the beta release, other than changelogs, so hopefully it'll arrive tomorrow.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Roses on April 03, 2020, 01:51:12 pm
Not sure if this is of interest to people (or maybe it is already known), but in the unit counters unit.counters, the think_counter, controls how fast a unit can shoot a crossbow. Testing in arena, as soon as my dwarf shot the crossbow, think_counter went to 80, if I then manually set it back to 0 the dwarf fired again immediately. It should be possible then to modify firing rates by checking if a projectile has been fired and then setting the units think_counter to a specific level.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: thefriendlyhacker on April 03, 2020, 08:47:37 pm
Not sure if this is of interest to people (or maybe it is already known), but in the unit counters unit.counters, the think_counter, controls how fast a unit can shoot a crossbow. Testing in arena, as soon as my dwarf shot the crossbow, think_counter went to 80, if I then manually set it back to 0 the dwarf fired again immediately. It should be possible then to modify firing rates by checking if a projectile has been fired and then setting the units think_counter to a specific level.
A while back (2 years ago, now?), a few people including myself did some dfhackery on this, and there are at least a couple of scripts floating around (including the one in my mod) that will change that counter on the fly to simulate faster firing weapons.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Jan Kaspsan on April 03, 2020, 09:33:57 pm
Is there a utility for exporting entities for use between worlds? I've wanted something like that since day 1.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: lethosor on April 04, 2020, 02:07:36 am
0.47.04-beta1 is up! https://github.com/DFHack/dfhack/releases/tag/0.47.04-beta1
There are a couple small breaking changes in structures to watch out for (related to tagged unions). A lot of stuff is new too.

Please test if you can! I'm hoping to promote 0.47.04 support to stable soon (or put out another beta), and feedback from people testing will help that process quite a lot.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: PatrikLundell on April 04, 2020, 02:22:03 am
Is there a utility for exporting entities for use between worlds? I've wanted something like that since day 1.
No, and I don't see how one could be made with a reasonable effort. It might be possible to export the properties of a civ and interrupt world gen as soon as the first civ of that entity_raw is placed and replace the properties of it with those collected, but I don't see any point in doing so. You could probably achieve essentially the same thing by defining an entity_raw with rigidly fixed parameters and specify that there should only be one of these.
Everything in DF is connected to everything else, so transplanting things also means you'd have to somehow transplant the connections by grafting them onto something that might resemble what those of the original.

This assumes "entities" is used in the sense it's used in the DFHack structures.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Jan Kaspsan on April 04, 2020, 02:55:47 am
Is there a utility for exporting entities for use between worlds? I've wanted something like that since day 1.
This assumes "entities" is used in the sense it's used in the DFHack structures.
I meant in reference to historical figures, namely my self-insert garystu adventurer.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Nilsolm on April 04, 2020, 05:09:18 am
If you're interested, go for it! plugins/search.cpp is the place to look - there are a bunch of existing implementations for other screens there already.

Just a heads-up, I am still on it. It should hopefully be done this weekend. I might also look into adding search to a few other screens like the report list, if I can swing it.
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: Warmist on April 04, 2020, 05:28:37 am
...

Use one commit before (as the job re-rename is still not in dfhack). Also I suggest replacing all "local function" to just "function" as it breaks some stuff...
Wait, what? I'm pretty sure I updated structures, and I tested that code snippet to make sure it worked.
Jan: You will have to upgrade DFHack, though - just upgrading the script won't work in this case.
Warmist: could you fix the function declarations when you get a chance? Thanks.

Sorry that i've didn't do it earlier. Just for future reference, if we actually want BenLubar's changes for lua linting (if i understood correctly) then somebody (prob me) needs forward declare functions that are used later.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: PatrikLundell on April 04, 2020, 07:52:46 am
Is there a utility for exporting entities for use between worlds? I've wanted something like that since day 1.
This assumes "entities" is used in the sense it's used in the DFHack structures.
I meant in reference to historical figures, namely my self-insert garystu adventurer.
As with other things in DF, hist figs have ties to other hist figs, sites, entities (civs, etc.), and history, and the items they carry likewise have ties. It would presumably be possible to create a new character in a new word and change it to get the stats of the "exported" one, as well as items that are technically similar to those used originally, but all links will be severed. The transplanted character would either have no history at all if DFHacked in from scratch, or would inherit the history of the character "grafted" onto.
You can't have any history of having visited HillPeak, because HillPeak doesn't exist in the new world (there may be some other HillPeak, but it's another one). Thus, hacking name and stats to resemble the old character can be done with a limited effort, but that's about what's reasonable.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Erendir on April 04, 2020, 08:23:09 am
I was looking at soundsense and discovered there is a soundsense.lua file providing extra information to the gamelog, like repeating season or weather information on SC_WORLD_LOADED. And then I realized there is the extra-gamelog.lua that includes almost all of the features from soundsense.lua, but not all of them.

Is there a reason the part about skills was omitted? (like, "<dwarf_name> is now very rusty <job_name>.")
Title: Re: DFHack 0.44.12-r3 | 0.47.03-beta1
Post by: lethosor on April 04, 2020, 06:31:59 pm
So far, the only issue that has been reported is exportlegends failing to generate maps. A fixed version of the script is available here, thanks to Thurin: https://github.com/DFHack/scripts/blob/8618cd0b0a17935fe07f329b249726cda61f5bdf/exportlegends.lua

Sorry that i've didn't do it earlier. Just for future reference, if we actually want BenLubar's changes for lua linting (if i understood correctly) then somebody (prob me) needs forward declare functions that are used later.
Yeah, I was in a hurry and remembered this last-minute before putting up 0.47.04-beta1, but I suspect it's just the function definition order that needs adjusting. Removing "local" was the quickest fix. (We might be able to silence that particular luacheck warning for advfort, too, if that's easier.)

I was looking at soundsense and discovered there is a soundsense.lua file providing extra information to the gamelog, like repeating season or weather information on SC_WORLD_LOADED. And then I realized there is the extra-gamelog.lua that includes almost all of the features from soundsense.lua, but not all of them.

Is there a reason the part about skills was omitted? (like, "<dwarf_name> is now very rusty <job_name>.")
Looking at that script's history (https://github.com/DFHack/scripts/commits/master/modtools/extra-gamelog.lua), I'm not seeing anything that removed it. It was combined (https://github.com/DFHack/scripts/commit/ce514b45f5112d92f0f513cceab14b02fd74b8c2) from soundsense-season and log-region, both of which only logged what their names imply.
The other possibility is that the version of the script distributed with Soundsense was modified more recently, and that information never made its way into DFHack's extra-gamelog script. I suggest getting in touch with the Soundsense maintainer(s) to find out if this was the case.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Nilsolm on April 05, 2020, 06:17:01 am
Right, I have managed to make both the conviction and interrogation choices list searchable. So far it seems to be working well, but I'll do some more testing and tidy up the code a bit, then I'll open a PR.

After that, I'll see if I can find out how to make the list of cases on the left side searchable as well.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: jecowa on April 06, 2020, 12:09:47 am
I got an error using gui/color-schemes:

Spoiler: Terminal (click to show/hide)

Spoiler: Screenshot (click to show/hide)

I put my color palettes in the /raw/colors/ folder.

Edit: Sorry, I tried again from the main menu like the manual says, and the error message went away, but there's still no color schemes showing up in the menu.

Edit 2: Oh, the error only shows up when I try to register my palettes folder.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: 1eb on April 07, 2020, 09:12:27 am
Is there a DFHack which supports DF 0.47.04 ? I got an error about an unknown DF version.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: thurin on April 07, 2020, 09:20:55 am
Is there a DFHack which supports DF 0.47.04 ? I got an error about an unknown DF version.

Yes, the info is in the first post.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: LordBalkan on April 14, 2020, 07:48:12 am
So, I'm having problems while using DFHack.
To be fair, the game runs normally and so far there was no crashes or that sort of things.
But there is this Error Flood on DFHack console that is annoying and I don't know how to fix.

Spoiler (click to show/hide)

I've tried with PyLNP and with a fresh new downloaded vanilla version+DFhack direct from GitHub.

As I said, its not preventing me to play but I would like to know how to fix this, if its possible of course.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: lethosor on April 14, 2020, 01:03:16 pm
From http://www.bay12forums.com/smf/index.php?topic=164123.msg8037202#msg8037202, that may have something to do with non-ASCII characters in the path to DF, so you could try addressing this by either renaming parts of the path to DF that have special characters in them or by moving DF somewhere else. We haven't figured out how to fix it yet. Are you using 64-bit DF? (I'm assuming it's at least on Windows, from the screenshot, but let me know if it's not.)
It should only prevent Ruby scripts from working in any case.

(For reference, you can copy text from the console on Windows by right-clicking in the console or in the title bar. That makes it possible for other people to search and find these posts more easily - a screenshot isn't searchable.)

Spoiler: text version (click to show/hide)
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: LordBalkan on April 14, 2020, 01:33:32 pm
(For reference, you can copy text from the console on Windows by right-clicking in the console or in the title bar. That makes it possible for other people to search and find these posts more easily - a screenshot isn't searchable.)
Oh me, oh my!! Sorry about that!

Here follows the code as was present in console itself:

Spoiler (click to show/hide)

About your sugestion on special characters and move the game to a different folder, yeah it totally works. I was using a "ã" letter to name the folder the game was in and when I renamed it the dfhack was back on trail.

Thanks for that!
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Vorox on April 15, 2020, 09:47:51 am
Does siege-engine work with ballistae or catapults only? Can I put ballistae on a tower above ground and have it shoot down into a target area?
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: lethosor on April 15, 2020, 06:20:21 pm
Oh me, oh my!! Sorry about that!

Here follows the code as was present in console itself:

-snip-

About your sugestion on special characters and move the game to a different folder, yeah it totally works. I was using a "ã" letter to name the folder the game was in and when I renamed it the dfhack was back on trail.
No worries; I'd already copied the text from the earlier post above.

Unfortunately I was unable to reproduce this on Linux, so it seems to be a Windows-specific bug, probably either in Ruby's string handling or DFHack's filesystem layer. Someone else may need to tackle this.

Just to help us out, are you using 64-bit or 32-bit DF+DFHack? I think the Ruby versions bundled with those are different.

Does siege-engine work with ballistae or catapults only? Can I put ballistae on a tower above ground and have it shoot down into a target area?
It appears to work with a ballista in 0.47.04 for me (at least, gui/siege-engine recognizes and rotates the ballista properly; I didn't try actually firing anything).

Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: LordBalkan on April 15, 2020, 06:29:02 pm
Just to help us out, are you using 64-bit or 32-bit DF+DFHack? I think the Ruby versions bundled with those are different.

I'm using a 64bit DF + DFHack.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Nilsolm on April 15, 2020, 06:40:04 pm
I've managed to cobble together a script that lists all guildhall and temple petitions in fortress mode. I've tested it on a few saves I had strewn about on my hard drive and it seems to work reliably.

Spoiler: list-agreements.lua (click to show/hide)

It outputs all agreements in a list. It prints out the location tier (temple/temple complex or guildhall/grand guildhall, resp.), the profession in the case of guildhalls, the religion in the case of temples, and the date on which the agreement was made. It also shows whether the agreement was satisfied or denied. Here are some examples:

Spoiler: Example output (click to show/hide)

One thing I am not sure about is what happens if the petition is accepted but not satisfied in time. I haven't been able to test that.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Vorox on April 16, 2020, 04:44:07 am
Thanks for answering my question.

Also, is tweak makeown supposed to work on invaders? Because I tried it, and it doesn't make them join me, just gives me "ownership for x clothes fixed". If the answer is no, then is there any script/plugin that can do this?
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: lethosor on April 16, 2020, 04:52:24 pm
I've managed to cobble together a script that lists all guildhall and temple petitions in fortress mode. I've tested it on a few saves I had strewn about on my hard drive and it seems to work reliably.

Just a couple things I noticed that you might want to keep in mind for future development (not asking you to address them or anything):

Quote
Code: [Select]
function get_location_type(agr)
    loctype = agr.details[0].data.Location.type
    return loctype
end

function get_location_name(agr)
    if get_location_type(agr) == 2 and get_location_tier(agr) == 1 then
        return "temple"

...

    elseif get_location_type(agr) == 11 and get_location_tier(agr) == 2 then
        return "grand guildhall"
    end

You should generally use named enum values instead of magic numbers (1, 2, 11, etc). In this case, I had to look in df.entities.xml (https://github.com/DFHack/df-structures/blob/96a8df43d1c4508800c209701ce39ca972579e3b/df.entities.xml#L1451-L1460) to find the definition of the agreement_details_data_location type. The "type" field's type is abstract_building_type (https://github.com/DFHack/df-structures/blob/96a8df43d1c4508800c209701ce39ca972579e3b/df.world-site.xml#L37-L51), so in Lua, 2 = df.abstract_building_type.TEMPLE and 11 = df.abstract_building_type.GUILDHALL. gui/gm-editor will also show a human-friendly list if you can navigate to this structure in it.

tier doesn't correspond to an enum, though - it's different for each abstract_building_type value, as you've found.


Quote
Code: [Select]
function is_satisfied(agr)
    satisfied = agr.anon_3.convicted_accepted
    return satisfied
end

function is_denied(agr)
    denied = agr.anon_3.petition_not_accepted
    return denied
end

You should generally avoid using anon names, because they're generated (for fields that don't have a "name=" attribute in the XML files at all) and not stable (any changes to whether nearby fields have names affect the number after "anon_" for other fields). I realize this isn't particularly helpful when you need that field, so the best practice is generally to make a pull request in df-structures or suggest a name for the field some other way.

In this case, anon_3 should probably be named "flags" for convention, so I'll tackle that. (If you're curious, it was identified as a bitfield here (https://github.com/DFHack/df-structures/commit/b3c27bcfee3bfccee9a44526a88f876ea4c66cfb#diff-1edbbd1bbd99084f1d1a36a4f8787f2dR1238) and flags were identified here (https://github.com/DFHack/df-structures/commit/a4a9c23bf8b1a4192a622846fbcab608103350f5#diff-1edbbd1bbd99084f1d1a36a4f8787f2dR1301), but the bitfield itself never got named.)

Quote
Code: [Select]
for agr, _ in pairs(allagreements) do
    if allagreements[agr].details[0].data.Location.site == playerfortid then
        if get_location_type(allagreements[agr]) == 2 then
            table.insert(templeagreementids, agr)
        elseif get_location_type(allagreements[agr]) == 11 then
            table.insert(guildhallagreementids, agr)
        end
    end
end

The second thing returned by pairs is the item itself, so you could rewrite the loop as "for _, agr in pairs(...)" and then just use "agr" everywhere you're using "allagreements[agr]". The only place I see you using the index by itself is in table.insert() - the agreements you're getting are just pointers, so there isn't really any more overhead in storing the agreements themselves in the tables instead of storing their indices.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: PatrikLundell on April 16, 2020, 05:30:26 pm
Adding to lethosor's comments: gui/gm-editor doesn't just provide the names of enums, but it does also provide the names of the types the enums belong to. I find it very much easier to use that to find the exact name of types rather than guessing at which XML files they might be defined in.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Nilsolm on April 16, 2020, 06:17:44 pm
Alright, thanks for the suggestions! I see if I can improve the script a bit over the weekend.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Iä! RIAKTOR! on April 18, 2020, 05:16:35 am
I report about some bugs in beta1. When I play testing fort, I spawn two harpies. They was asexual, so I try to change their orientation to "marry females", but multiple using of script has no effect - in DT harpies still was asexual, also not work current orientation showing by command. I try catsplosion to harpies without marring, but this cause crash. What go wrong? For elven visitors and spawned trolls catsplosion work normal, babies from it has no fathers. 
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Atomic Chicken on April 18, 2020, 06:58:35 am
I report about some bugs in beta1. When I play testing fort, I spawn two harpies. They was asexual, so I try to change their orientation to "marry females", but multiple using of script has no effect - in DT harpies still was asexual, also not work current orientation showing by command. I try catsplosion to harpies without marring, but this cause crash. What go wrong? For elven visitors and spawned trolls catsplosion work normal, babies from it has no fathers.

Providing the exact script commands used would be beneficial.

I suspect that the orientation problem is due to harpies being a female-only species. Units created using modtools/create-unit have their orientation set by the game, so if this isn't happening for female-only creatures it's likely a bug in the game itself, not DFHack.

I successfully set the "marry female" orientation of a spawned harpy via "set-orientation -female 2" with the target unit selected.

The catsplosion crash appears to be due to following on line 81:
Code: [Select]
female.pregnancy_caste = 1The script for some reason assumes that a caste ID of 1 is valid for all creatures instead of checking for it. Harpies only have one caste with an ID of 0. On testing, changing the value from 1 to 0 before running this on a harpy allowed it to give birth without crashing the game.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Iä! RIAKTOR! on April 18, 2020, 12:12:42 pm
I report about some bugs in beta1. When I play testing fort, I spawn two harpies. They was asexual, so I try to change their orientation to "marry females", but multiple using of script has no effect - in DT harpies still was asexual, also not work current orientation showing by command. I try catsplosion to harpies without marring, but this cause crash. What go wrong? For elven visitors and spawned trolls catsplosion work normal, babies from it has no fathers.

Providing the exact script commands used would be beneficial.

I suspect that the orientation problem is due to harpies being a female-only species. Units created using modtools/create-unit have their orientation set by the game, so if this isn't happening for female-only creatures it's likely a bug in the game itself, not DFHack.

I successfully set the "marry female" orientation of a spawned harpy via "set-orientation -female 2" with the target unit selected.

The catsplosion crash appears to be due to following on line 81:
Code: [Select]
female.pregnancy_caste = 1The script for some reason assumes that a caste ID of 1 is valid for all creatures instead of checking for it. Harpies only have one caste with an ID of 0. On testing, changing the value from 1 to 0 before running this on a harpy allowed it to give birth without crashing the game.
Thanks! Now catsplosion works fine. Maybe, harpy orientation bug needs some RAW solving.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Iä! RIAKTOR! on April 19, 2020, 07:45:27 am
Tweak makeown is useful for making haulers. But they are not citizens. How make unit a citizen of fortress, with changeable labors?
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Fleeting Frames on April 22, 2020, 05:50:57 pm
Try the script in this thread (http://www.bay12forums.com/smf/index.php?topic=165187.30) perhaps?
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Warmist on April 23, 2020, 04:06:39 am
on somewhat related note: do we know enough to add a petition? maybe that would sidestep all this hackery and just make df do the work?
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: lethosor on April 23, 2020, 02:28:33 pm
on somewhat related note: do we know enough to add a petition? maybe that would sidestep all this hackery and just make df do the work?
Looks like agreement is the relevant struct, and there are some unknown fields in it and in agreement_party, so it may or may not be possible to create working petitions.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Chai on April 23, 2020, 08:13:32 pm
Using rejuvenate successfully changes dwarves to 20 in fortress mode; however, retiring the fort and checking the dwarves in Legends Mode will state they were born in their original birth date. Reclaiming the fort will show they are all, however, still 20 as I left them.
Rejuvenate on Adventurer Mode will appear to work on a never-before-retired character, giving the message that <name> is 20 and will live at least a hundred years, but retiring them will show they were born at some other completely different time, and attempting to use rejuvenate on a previously retired character, who thus already has an age set in legends, will just crash the game.
Why? I realize this function wasn't intended for Adventurer Mode, I am curious though.

Does the supposed birth date actually matter? If I remove the birth date change and make rejuvenate only use unit.old_year = current_year + 100, would that work fine? It'd take a lot more time investment for me to check this part myself.

I understand rejuvenate isn't meant to be used in Adventurer, but does anyone know how it might be used that way? Taking the function and only slightly changing it lets you put in any number into the argument so you can pick the age of the target, I tested this with 20, 34, 15, and 9, and stuff changed just fine, retaining it. If something along these lines could be used to customize your adventurer's age, that'd be nice. Maybe it'd have to be something done on the setup screen, much like adv-max-skills, though in this case to avoid crashes and make it stick in legends mode (I would hope).
Any input would be appreciated, I don't know how anything works.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: lethosor on April 23, 2020, 09:07:38 pm
Using rejuvenate successfully changes dwarves to 20 in fortress mode; however, retiring the fort and checking the dwarves in Legends Mode will state they were born in their original birth date. Reclaiming the fort will show they are all, however, still 20 as I left them.
My guess is that this is because the script is only changing unit.birth_year, and legends mode is checking the corresponding historical figure instead of the unit (since units don't really exist in legends mode). Maybe it should be changing the histfig age too.

Quote
Rejuvenate on Adventurer Mode will appear to work on a never-before-retired character, giving the message that <name> is 20 and will live at least a hundred years, but retiring them will show they were born at some other completely different time, and attempting to use rejuvenate on a previously retired character, who thus already has an age set in legends, will just crash the game.
Why? I realize this function wasn't intended for Adventurer Mode, I am curious though.
Ideally it wouldn't be able to cause a crash, so I'm also curious. What happens if you run the script with "-dry-run" in this case? (I'm wondering if it's crashing when actually setting the age or at some point before.)

Quote
Does the supposed birth date actually matter? If I remove the birth date change and make rejuvenate only use unit.old_year = current_year + 100, would that work fine? It'd take a lot more time investment for me to check this part myself.
From comments in df-structures (https://github.com/DFHack/df-structures/blob/9bf18dfc6647e1ff51deddac9da042baa1655987/df.units.xml#L655), old_year isn't when the unit was born - it may be when they die, although it's unclear if this was ever confirmed.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: someone12345 on April 23, 2020, 10:03:40 pm
I am not very familiar with dfhack or lua, but how would I go about making remove-wear remove wear only from armor and weapons, and not from clothing?

Code: [Select]
local args = {...}
local count = 0

if args[1] == 'help' then
    print(help)
    return
elseif args[1] == 'all' or args[1] == '-all' then
    for _, item in ipairs(df.global.world.items.all) do
        if item.wear > 0 then --hint:df.item_actual
            item:setWear(0)
            count = count + 1
        end
    end
else
    for i, arg in ipairs(args) do
        local item_id = tonumber(arg)
        if item_id then
            local item = df.item.find(item_id)
            if item then
                item:setWear(0)
                count = count + 1
            else
                dfhack.printerr('remove-wear: could not find item: ' .. item_id)
            end
        else
            qerror('Invalid item ID: ' .. arg)
        end
    end
end

print('remove-wear: removed wear from '..count..' objects')



Would I add a section like so:

Code: [Select]
elseif args[1] == 'equipment' or args[1] == '-equipment' then
    for _, item in ipairs(df.global.world.items.all) do
        if item.wear > 0 then --hint:df.item_actual -- Here?????
            item:setWear(0)
            count = count + 1
        end
    end

I'm thinking you would add some condition with item.type == armor or item.type == weapon, but I do not know how to use lua or how dfhack's internal syntax works. How would I go about doing this?
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: lethosor on April 23, 2020, 11:20:58 pm
You have the right spot identified, I think. You'll want to check "item.type", I think - to find the right type, you could run gui/gm-editor with an item selected and inspect the type field. It's an enum, so you should get a list of valid values - make sure you use df.item_type.SOME_TYPE and not the raw number.

Unfortunately, looking at https://dwarffortresswiki.org/index.php/DF2014:Item_token, item types don't make a distinction between armor and other clothing. The item subtype might be what distinguishes between those, but I don't know as much about that off the top of my head.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Atomic Chicken on April 24, 2020, 05:22:26 am
It'd be possible to check the subtype info of valid item types for a non-clothing armorlevel (https://dwarffortresswiki.org/index.php/DF2014:Armor_token#ARMORLEVEL), but there's a very convenient vmethod that does all the work for us. The following one-liner should serve as a general weapon/armour check (including shields):

Code: [Select]
if item._type == df.item_weaponst or item:isArmorNotClothing() then
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Fleeting Frames on April 24, 2020, 01:41:47 pm
Hm, what's a safe way to convert df::item to, say, df::item_threadst or df::item_constructed?

Atm I've managed to compile

Spoiler: this cant be right... (click to show/hide)

And while it works, it seems wrong. (More obvious (to me) conversion methods throw compiling errors at me.)
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Clément on April 24, 2020, 02:43:37 pm
dynamic_cast ? I'm not sure if that works in DFHack.

I see there is a virtual_cast in DataDefs.h, I guess that's better.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: lethosor on April 24, 2020, 04:20:32 pm
Yeah, virtual_cast is definitely what you want here - it'll return null if the type you specify doesn't match the type of the object (similar to dynamic_cast). The important difference is that virtual_cast checks the type information of the types defined in DF, while dynamic_cast uses type information from the stubs defined in DFHack, which it considers completely unrelated types from the ones in DF.

It can be shortened like this:
Code: [Select]
if (auto threaditem = virtual_cast<item_threadst>(item)) {
  // do stuff with threaditem
}
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Fleeting Frames on April 24, 2020, 07:02:08 pm
Yeah, that worked. Thanks!
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: lethosor on April 25, 2020, 01:07:12 am
Heads up: the current dev build (https://dfhack.org/builds/) is likely to be one of the last before we release 0.47.04-r1 (the last couple things on the r1 to-do list (https://github.com/orgs/DFHack/projects/8) probably don't need to be addressed urgently). I don't know exactly when this build will be ready because the one before it in the queue got stuck, but hopefully within the next 12 hours hour or so. (Update: BenLubar fixed the stuck build)
Anyway, we haven't gotten a lot of reports of urgent issues in 0.47.04-beta1 - hopefully that means there aren't any left to fix, but if you've been encountering any issues with the beta build(s), please let us know!
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Roses on April 25, 2020, 03:23:42 am
Heads up: the current dev build (https://dfhack.org/builds/) is likely to be one of the last before we release 0.47.04-r1 (the last couple things on the r1 to-do list (https://github.com/orgs/DFHack/projects/8) probably don't need to be addressed urgently). I don't know exactly when this build will be ready because the one before it in the queue got stuck, but hopefully within the next 12 hours hour or so. (Update: BenLubar fixed the stuck build)
Anyway, we haven't gotten a lot of reports of urgent issues in 0.47.04-beta1 - hopefully that means there aren't any left to fix, but if you've been encountering any issues with the beta build(s), please let us know!

I ran all my scripts and tests, no issues detected with the beta build
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Pieniadz9 on April 25, 2020, 03:27:16 am
Do cage traps work differently when placed with Advfort? I've tried to capture a dragon with a cage trap by setting one up in his lair and luring him into it, but the trap didn't work. Later tried the same with a random mountain goat and got the same result. I'm using the 0.47.04 version of DFHack.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Atomic Chicken on April 25, 2020, 04:37:14 am
Do cage traps work differently when placed with Advfort? I've tried to capture a dragon with a cage trap by setting one up in his lair and luring him into it, but the trap didn't work. Later tried the same with a random mountain goat and got the same result. I'm using the 0.47.04 version of DFHack.

Cage traps are disabled in adventure mode; \data\init\d_init.txt contains a note by Toady regarding this matter. This was presumably done as getting the player character caught in a cage trap used to give rise to buggy behaviour in earlier versions; escaping cages or otherwise acting from within them hasn't been implemented yet.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: clinodev on April 25, 2020, 05:09:27 am
Heads up: the current dev build (https://dfhack.org/builds/) is likely to be one of the last before we release 0.47.04-r1 (the last couple things on the r1 to-do list (https://github.com/orgs/DFHack/projects/8) probably don't need to be addressed urgently). I don't know exactly when this build will be ready because the one before it in the queue got stuck, but hopefully within the next 12 hours hour or so. (Update: BenLubar fixed the stuck build)
Anyway, we haven't gotten a lot of reports of urgent issues in 0.47.04-beta1 - hopefully that means there aren't any left to fix, but if you've been encountering any issues with the beta build(s), please let us know!

Purely anecdotal, but PeridexisErrant's latest Starter Pack release has only generated one "DFhack problem" comment on reddit at 2k downloads and a week, and that could be Pack settings or, as it's singular, user issues: https://www.reddit.com/r/dwarffortress/comments/g1c1gc/the_peridexiserrant_windows_starter_pack_has/fnr5pxy/

No issues for me personally.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Pieniadz9 on April 25, 2020, 06:45:41 am
Do cage traps work differently when placed with Advfort? I've tried to capture a dragon with a cage trap by setting one up in his lair and luring him into it, but the trap didn't work. Later tried the same with a random mountain goat and got the same result. I'm using the 0.47.04 version of DFHack.

Cage traps are disabled in adventure mode; \data\init\d_init.txt contains a note by Toady regarding this matter. This was presumably done as getting the player character caught in a cage trap used to give rise to buggy behaviour in earlier versions; escaping cages or otherwise acting from within them hasn't been implemented yet.
I see, thanks! Is there any way i could re-enable them?
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Iä! RIAKTOR! on April 25, 2020, 03:11:48 pm
Who are authors of SPATTER_ADD and steam engine? I have idea of stuff like this, but maybe even harder to code (or easier, I dunno).
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Bumber on April 25, 2020, 03:13:13 pm
It doesn't look like automaterial is working in 0.47.04-beta1. Enable shows the plugin is on, but the last selected material doesn't end up at the top of the list.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: lethosor on April 25, 2020, 03:51:06 pm
It doesn't look like automaterial is working in 0.47.04-beta1. Enable shows the plugin is on, but the last selected material doesn't end up at the top of the list.
I was unable to reproduce the issue just now (in 0.47.04-beta1-93-g4dce9f20) when building constructed walls. Were you building another type of construction?

Who are authors of SPATTER_ADD and steam engine? I have idea of stuff like this, but maybe even harder to code (or easier, I dunno).
From GitHub (note that the most recent commits are at the top):
https://github.com/DFHack/dfhack/commits/develop/plugins/add-spatter.cpp
https://github.com/DFHack/dfhack/commits/develop/plugins/steam-engine.cpp
Angavrilov (ag on the forums) isn't really active these days, though.

I see, thanks! Is there any way i could re-enable them?
That's hardcoded functionality (i.e. not in the raws), so the only way I can think of (that doesn't involve reimplementing traps entirely in DFHack, which is hard) would be to override building vmethods. These (https://github.com/DFHack/df-structures/blob/951975f89920fa665675be42f91daa0183dab4e3/df.buildings.xml#L459-L465) might be relevant, judging by their names, but I have no idea what they do or if they're trap-related. So unless we're lucky, it's probably not feasible.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Pieniadz9 on April 25, 2020, 04:09:12 pm
I see, thanks! Is there any way i could re-enable them?
That's hardcoded functionality (i.e. not in the raws), so the only way I can think of (that doesn't involve reimplementing traps entirely in DFHack, which is hard) would be to override building vmethods. These (https://github.com/DFHack/df-structures/blob/951975f89920fa665675be42f91daa0183dab4e3/df.buildings.xml#L459-L465) might be relevant, judging by their names, but I have no idea what they do or if they're trap-related. So unless we're lucky, it's probably not feasible.
Shame. Still, gonna see if i can do somenthing with theese. Thanks.
Tho i'm not that good with modding DF so i doubt i'm gonna manage to get them working.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: PatrikLundell on April 25, 2020, 04:35:10 pm
It doesn't look like automaterial is working in 0.47.04-beta1. Enable shows the plugin is on, but the last selected material doesn't end up at the top of the list.
I was unable to reproduce the issue just now (in 0.47.04-beta1-93-g4dce9f20) when building constructed walls. Were you building another type of construction?
:
Using LNP r03 (which uses beta1) I've seen no problems with constructions. It appears to be working as normal for me (mostly floors and walls, but I believe I've seen it work with ramps as well).
This indicates it might be system/OS issue rather than a general one.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Bumber on April 25, 2020, 05:16:41 pm
It doesn't look like automaterial is working in 0.47.04-beta1. Enable shows the plugin is on, but the last selected material doesn't end up at the top of the list.
I was unable to reproduce the issue just now (in 0.47.04-beta1-93-g4dce9f20) when building constructed walls. Were you building another type of construction?

Bridges.

Can confirm it's working all right for walls.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: lethosor on April 25, 2020, 06:53:09 pm
Bridges.

Can confirm it's working all right for walls.
I'm pretty sure it only supports constructions (things like bridges and roads that aren't in the b-C menu are separate building types). At least, the docs (https://docs.dfhack.org/en/stable/docs/Plugins.html?highlight=automaterial#automaterial) indicate that, and there are a couple checks (https://github.com/DFHack/dfhack/blob/02c118335f3f399ea41f9c0129cd13e840abc7c7/plugins/automaterial.cpp#L109-L124) in the plugin that only allow constructions. I feel like support for more buildings types has been suggested before, and we could look into it.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: neo6633 on April 25, 2020, 07:21:01 pm
deleted
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Arkangel on April 26, 2020, 09:31:03 am
I'm having trouble getting the tailor plugin to work. I've enabled it, and a status check confirms it's enabled, but even after several years ingame it has yet to actually do anything. There is plenty of worn clothing in need of replacement, and a bookkeeper is assigned, with an office. However, no clothing orders are ever placed, nor is any clothing produced. Am I missing a step? The documentation (https://docs.dfhack.org/en/stable/docs/Plugins.html#tailor) doesn't indicate anything more.
I remember reading in the past that bookkeepers, after reaching a certain skill level, basically never go back to update the stockpile records, essentially becoming clairvoyant. If the update records job is never triggered, I suppose the clothing check would not trigger either? However, I cannot confirm this is how bookkeeping works at the moment, the wiki doesn't seem to mention anything like this anymore, even though I could have sworn reading that somewhere at some point.

I really like the idea of the tailor plugin, so I'd love to get it to work!
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Iä! RIAKTOR! on April 26, 2020, 10:11:04 am
It doesn't look like automaterial is working in 0.47.04-beta1. Enable shows the plugin is on, but the last selected material doesn't end up at the top of the list.
I was unable to reproduce the issue just now (in 0.47.04-beta1-93-g4dce9f20) when building constructed walls. Were you building another type of construction?

Who are authors of SPATTER_ADD and steam engine? I have idea of stuff like this, but maybe even harder to code (or easier, I dunno).
From GitHub (note that the most recent commits are at the top):
https://github.com/DFHack/dfhack/commits/develop/plugins/add-spatter.cpp
https://github.com/DFHack/dfhack/commits/develop/plugins/steam-engine.cpp
Angavrilov (ag on the forums) isn't really active these days, though.

I see, thanks! Is there any way i could re-enable them?
That's hardcoded functionality (i.e. not in the raws), so the only way I can think of (that doesn't involve reimplementing traps entirely in DFHack, which is hard) would be to override building vmethods. These (https://github.com/DFHack/df-structures/blob/951975f89920fa665675be42f91daa0183dab4e3/df.buildings.xml#L459-L465) might be relevant, judging by their names, but I have no idea what they do or if they're trap-related. So unless we're lucky, it's probably not feasible.
Only Angavrilov can code some mod-usable plugins or not?
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: lethosor on April 26, 2020, 11:01:29 am
Only Angavrilov can code some mod-usable plugins or not?
It's open source, so anyone can submit changes. My point is that the original author isn't very active, so sending him feature requests probably isn't what you want. If you post your suggestions at https://github.com/dfhack/dfhack/issues or on the forums, someone might be willing to implement them or direct you towards resources you could use to implement them.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on April 26, 2020, 12:48:37 pm
0.47.04-r1 is up! (https://github.com/DFHack/dfhack/releases/tag/0.47.04-r1)
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Iä! RIAKTOR! on April 26, 2020, 04:43:27 pm
Only Angavrilov can code some mod-usable plugins or not?
It's open source, so anyone can submit changes. My point is that the original author isn't very active, so sending him feature requests probably isn't what you want. If you post your suggestions at https://github.com/dfhack/dfhack/issues or on the forums, someone might be willing to implement them or direct you towards resources you could use to implement them.
I need some fully new plugins. DONOR plugin about reactions that give as product, example, blood or tears of worker (and only workers who have this material, example tears, will do this reaction - for prevent bugs). Second plugin will read CREATURE:CASTE from item PET (maybe, VERMIN or even REMAINS) and transform it into live creature, for re-using bugged purring maggots.
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Warmist on April 27, 2020, 01:54:12 am
<...>
I need some fully new plugins. DONOR plugin about reactions that give as product, example, blood or tears of worker (and only workers who have this material, example tears, will do this reaction - for prevent bugs). Second plugin will read CREATURE:CASTE from item PET (maybe, VERMIN or even REMAINS) and transform it into live creature, for re-using bugged purring maggots.

IMHO this does not need plugins and can be done in script. Plugins usually have more work involved and are only used when you need high performance (e.g. doing work on most of tiles of map) or impossible to do in scripts.

This being said: first idea is possible in scripts (with second part impossible at all - AFAIK we cannot limit workers for a job), second one is also a simple script.
Title: Re: DFHack 0.47.04-r1
Post by: Fleeting Frames on April 27, 2020, 11:35:41 am
Would be better to put it to github myself, but a headsup: item_plant_growthst.anon_1 (this line in structures (https://github.com/DFHack/df-structures/blob/master/df.items.xml#L1020)) determines which GROWTH_PRINT (https://dwarffortresswiki.org/index.php/DF2014:Plant_token#GROWTH_PRINT) it uses in item form. Counts up from from 0, and out of range defaults to withered tile.

@Warmist: For this application, I wonder if you couldn't work around it by making the actual labor for the task something no unit has enabled, then every 100 ticks check for idle dwarves with actual desired tear processing labor enabled and assign the job to first/most skilled/closest (taking advantage of the fact that dwarves keep working even if their labour is disabled).
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Iä! RIAKTOR! on April 27, 2020, 12:36:28 pm
<...>
I need some fully new plugins. DONOR plugin about reactions that give as product, example, blood or tears of worker (and only workers who have this material, example tears, will do this reaction - for prevent bugs). Second plugin will read CREATURE:CASTE from item PET (maybe, VERMIN or even REMAINS) and transform it into live creature, for re-using bugged purring maggots.

IMHO this does not need plugins and can be done in script. Plugins usually have more work involved and are only used when you need high performance (e.g. doing work on most of tiles of map) or impossible to do in scripts.

This being said: first idea is possible in scripts (with second part impossible at all - AFAIK we cannot limit workers for a job), second one is also a simple script.
I don't understand differences between script and plugin, what of them may be started by reaction? Can you write this scripts for me, please?
Title: Re: DFHack 0.47.04-r1
Post by: PatrikLundell on April 28, 2020, 04:06:51 am
@Iä! RIACTOR!: A script is interpreted text (e.g. Lua), while a plugin is code that has to be compiled with the same compiler using exactly the same DFHack code base as the DFHack version you're using it with. Thus, a script is portable and works across versions as long as the particular pieces of information it uses hasn't changed, while a plugin has to be recompiled for every new version and has to be provided for each DFHack version (OS/bitness, etc.) separately. The advantage of the more cumbersome plugin is that it runs a lot faster than interpreted text, which can matter when heavy work is done or it is run frequently. A positive side effect of the plugins compiler dependence is that the compiler will point out where the code no longer works because the underlying DFHack structure has changed (i.e. it will fail to compile), while a script will only detect such changes when it happens to try to interpret such lines of the script.
There are a few things that are available from code that isn't available to scripts, but very much can be done with scripts.
Title: Re: DFHack 0.47.04-r1
Post by: Iä! RIAKTOR! on April 28, 2020, 04:30:24 pm
@Iä! RIACTOR!: A script is interpreted text (e.g. Lua), while a plugin is code that has to be compiled with the same compiler using exactly the same DFHack code base as the DFHack version you're using it with. Thus, a script is portable and works across versions as long as the particular pieces of information it uses hasn't changed, while a plugin has to be recompiled for every new version and has to be provided for each DFHack version (OS/bitness, etc.) separately. The advantage of the more cumbersome plugin is that it runs a lot faster than interpreted text, which can matter when heavy work is done or it is run frequently. A positive side effect of the plugins compiler dependence is that the compiler will point out where the code no longer works because the underlying DFHack structure has changed (i.e. it will fail to compile), while a script will only detect such changes when it happens to try to interpret such lines of the script.
There are a few things that are available from code that isn't available to scripts, but very much can be done with scripts.
Can script work "automatic" like SPATTER_ADD, without starting by command for every playing session?
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on April 28, 2020, 07:31:58 pm
Can script work "automatic" like SPATTER_ADD, without starting by command for every playing session?
Not in the same way as add-spatter, but it's possible for a script to be run once and register handlers that run when the game state changes. The easiest way to ensure that it gets run would be to add it to dfhack.init, and there are already several plugins enabled in dfhack.init too, so it would feel about the same to a user.
Title: Re: DFHack 0.47.04-r1
Post by: Iä! RIAKTOR! on April 28, 2020, 07:46:02 pm
Can script work "automatic" like SPATTER_ADD, without starting by command for every playing session?
Not in the same way as add-spatter, but it's possible for a script to be run once and register handlers that run when the game state changes. The easiest way to ensure that it gets run would be to add it to dfhack.init, and there are already several plugins enabled in dfhack.init too, so it would feel about the same to a user.
Could you make this scripts for me? Please!
Title: Re: DFHack 0.47.04-r1
Post by: A_Curious_Cat on April 29, 2020, 02:39:05 pm
Could anybody tell me how (if it is possible) to teleport a bunch of stuff from the bottom of a waterfall onto dry ground?  Preferably something that can be used with multiple items at once.
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on April 29, 2020, 02:45:35 pm
Could anybody tell me how (if it is possible) to teleport a bunch of stuff from the bottom of a waterfall onto dry ground?  Preferably something that can be used with multiple items at once.

Designate them for dumping, move your cursor to where you want them, then use autodump.
Title: Re: DFHack 0.47.04-r1
Post by: A_Curious_Cat on April 29, 2020, 03:00:51 pm
Designate them for dumping, move your cursor to where you want them, then use autodump.

Thanks.
Title: Re: DFHack 0.47.04-r1
Post by: PatrikLundell on April 29, 2020, 04:23:07 pm
Could anybody tell me how (if it is possible) to teleport a bunch of stuff from the bottom of a waterfall onto dry ground?  Preferably something that can be used with multiple items at once.

Designate them for dumping, move your cursor to where you want them, then use autodump.
Note that this teleports everything marked for dumping to the given location, so either make sure you don't have (too many) other things marked for dumping, select a target location that's somewhat suitable for all the things marked, or mark the items you actually wanted elsewhere for dumping again and autodump them to a new location (you may have to unforbid them first).
Title: Re: DFHack 0.47.04-r1
Post by: Oafsalot on May 02, 2020, 02:07:43 pm
Concerning changes to modtools/create-unit. - http://www.bay12forums.com/smf/index.php?topic=176272.0 (http://www.bay12forums.com/smf/index.php?topic=176272.0)
Title: Re: DFHack 0.47.04-r1
Post by: A_Curious_Cat on May 04, 2020, 04:17:14 pm
Nevermind.  I've figured out the problem.  Seems one of the saves that I thought couldn't possibly be the one I wanted (because of the dates and directory modification times) actually was the one I wanted.  To avoid confusion, I've deleted all the other saves from this world and renamed the remaining save to "region1".

Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 04, 2020, 08:23:29 pm
I'm not really sure. What OS are you using, and what folders are in your data/save folder?
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: Quietust on May 04, 2020, 09:50:37 pm
I see, thanks! Is there any way i could re-enable them?
That's hardcoded functionality (i.e. not in the raws), so the only way I can think of (that doesn't involve reimplementing traps entirely in DFHack, which is hard) would be to override building vmethods. These (https://github.com/DFHack/df-structures/blob/951975f89920fa665675be42f91daa0183dab4e3/df.buildings.xml#L459-L465) might be relevant, judging by their names, but I have no idea what they do or if they're trap-related. So unless we're lucky, it's probably not feasible.
Shame. Still, gonna see if i can do somenthing with theese. Thanks.
Tho i'm not that good with modding DF so i doubt i'm gonna manage to get them working.
In case you're still interested, "updateAction" is the vmethod that handles traps being triggered, but the class involved (building_trapst) handles all of the different trap types, including levers, pressure plates, and track stops. You might be able to temporarily set gamemode=0 for the duration of the vmethod if it's the correct subtype, but that might also cause the trap to malfunction (e.g. from trying to invoke Fortress-specific behavior in Adventurer mode).
Title: Re: DFHack 0.47.04-r1
Post by: Iä! RIAKTOR! on May 05, 2020, 04:07:48 am
How make adding syndrome of regeneration and body parts regrowing for blizzard men from any contact with water? Water is hardcoded, so standard way of adding syndromes is not our way. Adding new material will not work too, I need regeneration from rain, rivers and snow.
Title: Re: DFHack 0.47.04-r1
Post by: Atomic Chicken on May 05, 2020, 08:28:46 am
How make adding syndrome of regeneration and body parts regrowing for blizzard men from any contact with water? Water is hardcoded, so standard way of adding syndromes is not our way. Adding new material will not work too, I need regeneration from rain, rivers and snow.

This was fairly straightforward, so I went ahead and wrote a script for adding syndromes to inbuilt materials:

Code: [Select]
-- Add a syndrome to an inbuilt material.
-- Author: Atomic Chicken

local utils = require 'utils'

local validArgs = utils.invert({
  'material',
  'syndrome',
})

local args = utils.processArgs({...}, validArgs)

if not args.material then
  qerror('Material not specified!')
end
if not args.syndrome then
  qerror('Syndrome not specified!')
end

addedSynMats = addedSynMats or {}

local matInfo = dfhack.matinfo.find(args.material)
if not matInfo then
  qerror('Material not found: ' .. args.material)
end
if matInfo.mode ~= 'builtin' then
  qerror('This script should only be used with inbuilt materials.')
end
local material = matInfo.material

local foundSyn = false
for _, syndrome in ipairs(df.global.world.raws.syndromes.all) do
  if syndrome.syn_name == args.syndrome then
    material.syndrome:insert('#', syndrome)
    if syndrome.flags.SYN_INJECTED then
      material.flags.ENTER_BLOOD = true -- reverses on reload
    end
    if not addedSynMats[args.material] then
      addedSynMats[args.material] = true
    end
    foundSyn = true
    break
  end
end

if not foundSyn then
  qerror('Syndrome not found: ' .. args.syndrome)
end

-- Clear added syndromes when unloading; prevents crashes when reloading
dfhack.onStateChange.InbuiltMatSynMonitor = function(event)
  if event == SC_WORLD_UNLOADED then
    for k,_ in pairs(addedSynMats) do
      local material = dfhack.matinfo.find(k).material
      material.syndrome:resize(0)
      addedSynMats[k] = nil
    end
  end
end

It worked as expected when I tested it (which is to say that I managed to transform my adventurer into a cat by jumping into a river), but I can't guarantee that it won't cause problems, so use with caution. I might add a -help printout and make it possible to specify multiple syndromes simultaneously at a later stage if no problems crop up.

To use, paste the code into a text editor and save it as a .lua file (such as inbuilt-material-syndrome.lua) in \hack\scripts. You can then run it either manually from the console after loading the a save, or place the command in onLoad.init in \raw to have it run automatically when a world is loaded (create this file if it doesn't exist already). Call as follows:
Code: [Select]
inbuilt-material-syndrome -material WATER -syndrome YOUR_SYN_NAME
Other inbuilt materials (https://dwarffortresswiki.org/index.php/DF2014:Hardcoded_material), such as "VOMIT", may also be specified. The syndrome needs to have been defined elsewhere.
Title: Re: DFHack 0.47.04-r1
Post by: bloop_bleep on May 05, 2020, 11:46:56 am
Actually, this might be something where DFHack is not required, maybe. I believe in interactions you are able to specify a requirement that a given target must be in water. You can look up interaction token on the wiki for more information. Then you can make a CLEAN_SELF or defense interaction on the blizzard that targets SELF_ONLY and has the aforementioned water requirement.
Title: Re: DFHack 0.47.04-r1
Post by: Su on May 07, 2020, 01:32:29 am
i hope this is the right place to ask - i'm wanting to make a script to automatically nickname my dwarves, but unfortunately i'm not very bright and the documentation is very confusing for me. is there anywhere else i can look to try and understand what i need to be doing?

manipulator is fantastic by the way, thank you.
Title: Re: DFHack 0.47.04-r1
Post by: bloop_bleep on May 07, 2020, 11:32:52 am
I believe you can use dfhack.units.setNickname(<unit>, <nickname>) inside a lua script to change a unit's nickname, if that's what you were looking for.
Title: Re: DFHack 0.47.04-r1
Post by: Su on May 07, 2020, 01:48:16 pm
I believe you can use dfhack.units.setNickname(<unit>, <nickname>) inside a lua script to change a unit's nickname, if that's what you were looking for.

right - i gathered that much from the docs - but how do i tell what value <unit> should be, or if they already have a nickname?
Title: Re: DFHack 0.47.04-r1
Post by: bloop_bleep on May 07, 2020, 02:19:30 pm
Unit should be a lua userdata representing a DF unit. There are many ways you can get a unit object; use df.unit.find(<id>) to find one with a specific id, use df.global.world.units.active to get a list of all active units (units that are currently loaded) and df.global.world.units.all to get a list of all units recorded in the world.

If you want to explore the data exposed to you by DFHack, you could cursor over a unit, item, whatever, then run "gui/gm-editor" in the DFHack console. That will bring up a list of fields and their values for the selected object. You could also explore with the lua console you get when you run "lua" in the DFHack prompt.

For doing things automatically, look into the "eventful" utility.
Title: Re: DFHack 0.47.04-r1
Post by: Su on May 07, 2020, 02:42:22 pm
use df.global.world.units.active to get a list of all active units (units that are currently loaded) and df.global.world.units.all to get a list of all units recorded in the world.

ah, that's exactly the type of thing i'm looking for! where did you find out about these? they aren't referenced in the docs at all.
Title: Re: DFHack 0.47.04-r1
Post by: PatrikLundell on May 07, 2020, 03:11:31 pm
use df.global.world.units.active to get a list of all active units (units that are currently loaded) and df.global.world.units.all to get a list of all units recorded in the world.

ah, that's exactly the type of thing i'm looking for! where did you find out about these? they aren't referenced in the docs at all.
The DF structures are found under "df.global", with most of the interesting things found under "df.global.world". These structures can be explored using e.g. gui/gm-editor, or by reading the XML files (in the df structures project on github) mapping them. Documenting DF's internal structures would be a massive undertaking: it's hard enough to try to figure out what things are and describe them in XML form, and a fair bit of that is tentative. The way I got started on getting some kind of understanding of how the structures hang together was to read scripts that do something in the vicinity of what I'm looking for, use gui/gm-editor to view the corresponding structures, trying to understand the scripts, and build from there.

While df.global.world.units.active includes all active units, it is not restricted to your citizens, but includes every active unit, be it buzzard, goblin invader, dog, visitor, underworld denizen, or citizen. Thus, you'd need to filter the units to locate the ones you actually want. Also, I think the dead units are in that list as well.
Title: Re: DFHack 0.47.04-r1
Post by: Su on May 07, 2020, 06:03:33 pm
The DF structures are found under "df.global", with most of the interesting things found under "df.global.world". These structures can be explored using e.g. gui/gm-editor, or by reading the XML files (in the df structures project on github) mapping them.

..."world.units.active" doesn't seem to be defined anywhere in the df.global xml, though? am i looking in the wrong place? https://github.com/DFHack/df-structures/blob/a7dae6083d295821afe2ba91073d9b7547395b45/df.globals.xml

While df.global.world.units.active includes all active units, it is not restricted to your citizens, but includes every active unit, be it buzzard, goblin invader, dog, visitor, underworld denizen, or citizen. Thus, you'd need to filter the units to locate the ones you actually want. Also, I think the dead units are in that list as well.

ok. how would i go about doing that filtering? i think i might be able to get something working with that.
Title: Re: DFHack 0.47.04-r1
Post by: Fleeting Frames on May 07, 2020, 06:10:09 pm
Here's an example (https://dwarffortresswiki.org/index.php/User:Fleeting_Frames/max-wave).
Title: Re: DFHack 0.47.04-r1
Post by: bloop_bleep on May 07, 2020, 06:41:26 pm
I usually don't bother with the XML files, to be honest. Mostly I just look at the header files for the DF structures in the library/include/df folder of my cloned DFHack repo.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 07, 2020, 07:19:43 pm
The DF structures are found under "df.global", with most of the interesting things found under "df.global.world". These structures can be explored using e.g. gui/gm-editor, or by reading the XML files (in the df structures project on github) mapping them.

..."world.units.active" doesn't seem to be defined anywhere in the df.global xml, though? am i looking in the wrong place? https://github.com/DFHack/df-structures/blob/a7dae6083d295821afe2ba91073d9b7547395b45/df.globals.xml

Things are split up across multiple files; it can be a bit of a pain to hunt them down sometimes. The world global (https://github.com/DFHack/df-structures/blob/a7dae6083d295821afe2ba91073d9b7547395b45/df.globals.xml#L194) is defined as being a pointer to the "world" type, which is defined in df.world.xml (https://github.com/DFHack/df-structures/blob/a7dae6083d295821afe2ba91073d9b7547395b45/df.world.xml#L771), and world.units is here (https://github.com/DFHack/df-structures/blob/a7dae6083d295821afe2ba91073d9b7547395b45/df.world.xml#L832-L843).

I would really recommend using gui/gm-editor as an easier way to track these down - if you run "gui/gm-editor world", then selecting "units" then "active" would get you to the same spot. The script Fleeting Frames posted is a decent starting point.
Title: Re: DFHack 0.47.04-r1
Post by: Su on May 08, 2020, 03:19:33 am
thanks all. i appreciate it.
i think i have something with this script - most of the parts i could test worked, but i'm getting an error when i try the full thing, so i can't be sure...

Spoiler (click to show/hide)

where should i be putting names.txt so my script can find it? /hack doesn't seem to work, and neither does hack/scripts.
Title: Re: DFHack 0.47.04-r1
Post by: PatrikLundell on May 08, 2020, 07:34:21 am
@Su:

Line from one of my scripts:
Code: [Select]
local in_file = io.open (dfhack.getDFPath ().."\\data\\init\\exported_map.txt", "r")

I think that provides you with the basic info you need.
Title: Re: DFHack 0.47.04-r1
Post by: Fleeting Frames on May 08, 2020, 07:45:39 am
Also, you probably want unit.name.nickname ~= "", as the == is never met due explicitly avoiding putting "" into names table.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 08, 2020, 11:42:59 am
i think i have something with this script - most of the parts i could test worked, but i'm getting an error when i try the full thing, so i can't be sure...
where should i be putting names.txt so my script can find it? /hack doesn't seem to work, and neither does hack/scripts.

If you could post the error, that would help us help you resolve it. (If you weren't able to copy text from the console on Windows, you can do that by right-clicking either in the console or in the title bar.)

For reference, the current working directory (where relative paths like "names.txt" are relative to) is basically always the DF folder itself. (It's technically possible to change, but doing so can cause DF to crash.) So you don't really need getDFPath() from Patrik's suggestion, but it's best to use it for the purposes of being explicit.

@Su:

Line from one of my scripts:
Code: [Select]
local in_file = io.open (dfhack.getDFPath ().."\\data\\init\\exported_map.txt", "r")

I think that provides you with the basic info you need.

A side note: you should generally use forward slashes in paths, not backslashes, to make scripts portable. With the system calls DFHack uses, either will work on Windows, but only forward slashes will work on other platforms (and they have the added advantage of not needing to be escaped).

Also, you probably want unit.name.nickname ~= "", as the == is never met due explicitly avoiding putting "" into names table.
To clarify, this only applies to the first occurrence - the second is intentionally checking for units without nicknames.
Title: Re: DFHack 0.47.04-r1
Post by: Su on May 08, 2020, 09:38:01 pm
thank you ever so much, everyone! i think i've got it working perfectly now. there's probably inefficiencies and poor choices all over since i don't really know the language, but it seems to work fine, which is all i wanted.

here's the [hopefully] final script:

Spoiler (click to show/hide)

lethosor - i didn't think it was important since it looked like a simple case of me not knowing where to put things, but i'll be sure to post errors if i encouter them again. thanks again for the help!
Title: Re: DFHack 0.47.04-r1
Post by: Rekov on May 09, 2020, 12:26:40 am
Is it possible to create fruits with the createitem thing?

The wiki says:
Code: [Select]
createitem [Item token] [Material] [Quantity (optional)]
My best guess was:

createitem PLANT_GROWTH:FRUIT PLANT_MAT:BILBERRY:FRUIT 5

It doesn't seem to recognize "PLANT_GROWTH:FRUIT" as an Item token, probably because it has a subtype. If you just put in PLANT_GROWTH as the item token it does create "a stack of 5", but it doesn't appear to be a stack of 5 anythings in particular.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 09, 2020, 11:58:39 am
Is it possible to create fruits with the createitem thing?

The wiki says:
Code: [Select]
createitem [Item token] [Material] [Quantity (optional)]
My best guess was:

createitem PLANT_GROWTH:FRUIT PLANT_MAT:BILBERRY:FRUIT 5

It doesn't seem to recognize "PLANT_GROWTH:FRUIT" as an Item token, probably because it has a subtype. If you just put in PLANT_GROWTH as the item token it does create "a stack of 5", but it doesn't appear to be a stack of 5 anythings in particular.
Here (https://github.com/DFHack/dfhack/blob/d0c030c3da62b88d97a05c417fce3d86e80fa7de/library/modules/Items.cpp#L108-L121) is the list of item subtypes that createitem supports internally. PLANT and PLANT_GROWTH aren't listed, so you can't specify (item) subtypes for them.


As for creating bilberries, my first attempt, "createitem PLANT PLANT:BILBERRY:STRUCTURAL", gave a "bilberry bush" item, as did "createitem PLANT PLANT:BILBERRY:FRUIT". I was able to find an embark that had bilberries, harvested some in the fall, and observed this:
Code: [Select]
[lua]# ~df.item_type[item:getType()]
PLANT_GROWTH
[lua]# ~item:getSubtype()
2
[lua]# ~dfhack.matinfo.decode(item.mat_type, item.mat_index)
<material 423:86 PLANT:BILBERRY:FRUIT>
plant                  = <plant_raw: 0x7fffcd96f330>
mode                    = plant
type                    = 423
subtype                = 4
index                  = 86
material                = <material: 0x7fffcd973230>

In contrast, using "createitem PLANT_GROWTH PLANT:BILBERRY:FRUIT" gives an item with these properties:
Code: [Select]
[lua]# ~df.item_type[item:getType()]
PLANT_GROWTH
[lua]# ~item:getSubtype()
-1
[lua]# ~dfhack.matinfo.decode(item.mat_type, item.mat_index)
<material 423:86 PLANT:BILBERRY:FRUIT>
plant                  = <plant_raw: 0x7fffcd96f330>
mode                    = plant
type                    = 423
subtype                = 4
index                  = 86
material                = <material: 0x7fffcd973230>

So it does appear that the subtype is important, and the Items module can't handle plants or plant growths with subtypes (at least without significant modifications) because world.raws.itemdefs doesn't have vectors specific to those item types.

You might be able to use "gui/create-item" for this - it uses a bit of a different strategy, but might run into the same limitation.

Update: setting item.subtype = 2 still gives an item with a different icon (but the right description, "bilberry"). Both the naturally-gathered and DFHack-created items show up under "Leaves" in the stocks screen, and are grouped together, so maybe this is enough to create normal bilberries. gui/create-item is able to do exactly the same thing as createitem (plant growth -> plant -> bilberry bush -> fruit), with a subtype of -1.

Long story short, plant growths are still relatively new relative to other things in DFHack, and not everything has first-class support for them yet. Other people might have more ideas than I do.
Title: Re: DFHack 0.47.04-r1
Post by: Fleeting Frames on May 09, 2020, 07:26:49 pm
It still has wrong icon because it still has wrong GROWTH_PRINT index (-1 with createitem). Setting it to 0 gives correct image.
Spoiler: "From two pages back" (click to show/hide)
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 09, 2020, 08:13:42 pm
It still has wrong icon because it still has wrong GROWTH_PRINT index (-1 with createitem). Setting it to 0 gives correct image.
Spoiler: "From two pages back" (click to show/hide)
Thanks, I opened a report here (https://github.com/DFHack/df-structures/issues/403). For reference, pressing the "y" key in a code view on GitHub will give you a permalink - linking to a specific line on the master branch could end up pointing to the wrong place in the future as changes are made.
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on May 13, 2020, 06:37:02 pm
How do I go about getting and setting tiletype information in a lua script? Specifically light/dark and subterranean/above ground.
Title: Re: DFHack 0.47.04-r1
Post by: A_Curious_Cat on May 13, 2020, 06:48:40 pm
Does anyone know if the thing that marks eggs as fertile or infertile when you examine the nest box is part of DFHack, or just a part of vanilla DF?  I'm asking because I'd like to know the difference between "Infertile" and "N. Fertile".  I've searched both the DF Wiki, and the DFHack documentation on readthedocs.org, and neither even mentions this feature at all.

Edit:  I just used git pull to download the latest changes on the stable branch and tried building again.  It gave me this error message:

Code: [Select]
[17/123] Building CXX object plugins/l.../labormanager.dir/joblabormapper.cpp.o
FAILED: plugins/labormanager/CMakeFiles/labormanager.dir/joblabormapper.cpp.o
ccache /usr/bin/c++  -DHAVE_CUCHAR -DLINUX_BUILD -DLUA_BUILD_AS_DLL -DPROTOBUF_USE_DLLS -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_CXX11_ABI=0 -D_LINUX -Dlabormanager_EXPORTS -I../depends/protobuf -I../depends/lua/include -I../depends/md5 -I../depends/tinyxml -I../depends/tthread -I../depends/clsocket/src -I../library/include -I../library/proto -I../plugins/proto -I../library/depends/xgetopt -fvisibility=hidden -mtune=generic -m32 -march=i686 -Wl,-z,defs -O3 -DNDEBUG -fPIC     -std=c++11 -MD -MT plugins/labormanager/CMakeFiles/labormanager.dir/joblabormapper.cpp.o -MF plugins/labormanager/CMakeFiles/labormanager.dir/joblabormapper.cpp.o.d -o plugins/labormanager/CMakeFiles/labormanager.dir/joblabormapper.cpp.o -c ../plugins/labormanager/joblabormapper.cpp
../plugins/labormanager/joblabormapper.cpp: In constructor ‘JobLaborMapper::JobLaborMapper()’:
../plugins/labormanager/joblabormapper.cpp:900:38: error: ‘unk_fake_no_job’ is not a member of ‘df::enums::job_type::job_type’
     job_to_labor_table[df::job_type::unk_fake_no_job] = jlf_no_labor; // added for 47.04 - see #1561
                                      ^~~~~~~~~~~~~~~
../plugins/labormanager/joblabormapper.cpp:901:38: error: ‘InterrogateSubject’ is not a member of ‘df::enums::job_type::job_type’
     job_to_labor_table[df::job_type::InterrogateSubject] = jlf_no_labor; // added for 47.04 - see #1561
                                      ^~~~~~~~~~~~~~~~~~
../plugins/labormanager/joblabormapper.cpp:902:38: error: ‘unk_fake_no_activity’ is not a member of ‘df::enums::job_type::job_type’
     job_to_labor_table[df::job_type::unk_fake_no_activity] = jlf_no_labor; // added for 47.04 - see #1561
                                      ^~~~~~~~~~~~~~~~~~~~
[23/123] Building CXX object library/CMakeFiles/dfhack.dir/LuaApi.cpp.o
ninja: build stopped: subcommand failed.


IIRC, ccmake also gave me a warning.  I'll see if I can get it again...

Ah, here it is:
Code: [Select]
CMake Warning at depends/jsoncpp-sub/src/lib_json/CMakeLists.txt:36 (MESSAGE):
   Locale functionality is not supported



Title: Re: DFHack 0.47.04-r1
Post by: Bumber on May 13, 2020, 07:54:22 pm
Does anyone know if the thing that marks eggs as fertile or infertile when you examine the nest box is part of DFHack, or just a part of vanilla DF?  I'm asking because I'd like to know the difference between "Infertile" and "N. Fertile".  I've searched both the DF Wiki, and the DFHack documentation on readthedocs.org, and neither even mentions this feature at all.

https://github.com/DFHack/dfhack/blob/develop/plugins/tweak/tweaks/eggs-fertile.h

I don't use nestboxes, but if I'm understanding the code correctly, the nestbox uses the term "Eggs infertile" and the eggs themselves use the term "N.Fert".
Title: Re: DFHack 0.47.04-r1
Post by: A_Curious_Cat on May 13, 2020, 08:10:13 pm
Does anyone know if the thing that marks eggs as fertile or infertile when you examine the nest box is part of DFHack, or just a part of vanilla DF?  I'm asking because I'd like to know the difference between "Infertile" and "N. Fertile".  I've searched both the DF Wiki, and the DFHack documentation on readthedocs.org, and neither even mentions this feature at all.

https://github.com/DFHack/dfhack/blob/develop/plugins/tweak/tweaks/eggs-fertile.h

I don't use nestboxes, but if I'm understanding the code correctly, the nestbox uses the term "Eggs infertile" and the eggs themselves use the term "N.Fert".

Yeah, I just looked at the code you linked to and it appears that the only difference is if you use 't' or 'q' to look at the nest box.  It'd be less confusing if someone would change it to say the same thing (e.g. "Infertile") in both cases.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 13, 2020, 08:32:47 pm
Yeah, I just looked at the code you linked to and it appears that the only difference is if you use 't' or 'q' to look at the nest box.  It'd be less confusing if someone would change it to say the same thing (e.g. "Infertile") in both cases.
The reason I did that is simple: "infertile" doesn't fit in the 't' menu (at least not for some eggs). The colors also serve as a bit of an indicator ("fertile" and "fert" are both green, "infertile" and "N. fert" are both red) but I understand that color alone isn't always enough to distinguish between them.

The tweak docs are here (https://docs.dfhack.org/en/stable/docs/Plugins.html?highlight=eggs-fertile#tweak), by the way.


Edit:  I just used git pull to download the latest changes on the stable branch and tried building again.  It gave me this error message:

Code: [Select]
[17/123] Building CXX object plugins/l.../labormanager.dir/joblabormapper.cpp.o
FAILED: plugins/labormanager/CMakeFiles/labormanager.dir/joblabormapper.cpp.o
ccache /usr/bin/c++  -DHAVE_CUCHAR -DLINUX_BUILD -DLUA_BUILD_AS_DLL -DPROTOBUF_USE_DLLS -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_CXX11_ABI=0 -D_LINUX -Dlabormanager_EXPORTS -I../depends/protobuf -I../depends/lua/include -I../depends/md5 -I../depends/tinyxml -I../depends/tthread -I../depends/clsocket/src -I../library/include -I../library/proto -I../plugins/proto -I../library/depends/xgetopt -fvisibility=hidden -mtune=generic -m32 -march=i686 -Wl,-z,defs -O3 -DNDEBUG -fPIC     -std=c++11 -MD -MT plugins/labormanager/CMakeFiles/labormanager.dir/joblabormapper.cpp.o -MF plugins/labormanager/CMakeFiles/labormanager.dir/joblabormapper.cpp.o.d -o plugins/labormanager/CMakeFiles/labormanager.dir/joblabormapper.cpp.o -c ../plugins/labormanager/joblabormapper.cpp
../plugins/labormanager/joblabormapper.cpp: In constructor ‘JobLaborMapper::JobLaborMapper()’:
../plugins/labormanager/joblabormapper.cpp:900:38: error: ‘unk_fake_no_job’ is not a member of ‘df::enums::job_type::job_type’
     job_to_labor_table[df::job_type::unk_fake_no_job] = jlf_no_labor; // added for 47.04 - see #1561
                                      ^~~~~~~~~~~~~~~
../plugins/labormanager/joblabormapper.cpp:901:38: error: ‘InterrogateSubject’ is not a member of ‘df::enums::job_type::job_type’
     job_to_labor_table[df::job_type::InterrogateSubject] = jlf_no_labor; // added for 47.04 - see #1561
                                      ^~~~~~~~~~~~~~~~~~
../plugins/labormanager/joblabormapper.cpp:902:38: error: ‘unk_fake_no_activity’ is not a member of ‘df::enums::job_type::job_type’
     job_to_labor_table[df::job_type::unk_fake_no_activity] = jlf_no_labor; // added for 47.04 - see #1561
                                      ^~~~~~~~~~~~~~~~~~~~
[23/123] Building CXX object library/CMakeFiles/dfhack.dir/LuaApi.cpp.o
ninja: build stopped: subcommand failed.

You probably need to run "git submodule update", or "git pull" from within the library/xml folder. See https://docs.dfhack.org/en/stable/docs/Compile.html for more details, specifically the note in this section (https://docs.dfhack.org/en/stable/docs/Compile.html#how-to-get-the-code).

(Also, which branch is "the stable branch"? We recently switched the default branch to "develop", because that's what most people who build from source typically want, but the most recent stable release, currently 0.47.04-r1, is on the "master" branch.)

Quote
Ah, here it is:
Code: [Select]
CMake Warning at depends/jsoncpp-sub/src/lib_json/CMakeLists.txt:36 (MESSAGE):
   Locale functionality is not supported
Looking at the file in question, that should just be a warning, and the build should be able to continue despite that. That said, what compiler are you using? We only support MSVC 2015 on Windows (which is a hard requirement) and GCC 4.8+ on other platforms, and I don't recall seeing this particular warning before, but maybe it's something system-specific, not compiler-specific.
Title: Re: DFHack 0.47.04-r1
Post by: A_Curious_Cat on May 13, 2020, 09:08:20 pm
Yeah, I just looked at the code you linked to and it appears that the only difference is if you use 't' or 'q' to look at the nest box.  It'd be less confusing if someone would change it to say the same thing (e.g. "Infertile") in both cases.
The reason I did that is simple: "infertile" doesn't fit in the 't' menu (at least not for some eggs). The colors also serve as a bit of an indicator ("fertile" and "fert" are both green, "infertile" and "N. fert" are both red) but I understand that color alone isn't always enough to distinguish between them.

The tweak docs are here (https://docs.dfhack.org/en/stable/docs/Plugins.html?highlight=eggs-fertile#tweak), by the way.
Yeah, that makes sense.  Thanks for the link to the docs.  Interesting that the search engine in the page couldn't pull that up...

Edit:  I just used git pull to download the latest changes on the stable branch and tried building again.  It gave me this error message:

Code: [Select]
[17/123] Building CXX object plugins/l.../labormanager.dir/joblabormapper.cpp.o
FAILED: plugins/labormanager/CMakeFiles/labormanager.dir/joblabormapper.cpp.o
ccache /usr/bin/c++  -DHAVE_CUCHAR -DLINUX_BUILD -DLUA_BUILD_AS_DLL -DPROTOBUF_USE_DLLS -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_CXX11_ABI=0 -D_LINUX -Dlabormanager_EXPORTS -I../depends/protobuf -I../depends/lua/include -I../depends/md5 -I../depends/tinyxml -I../depends/tthread -I../depends/clsocket/src -I../library/include -I../library/proto -I../plugins/proto -I../library/depends/xgetopt -fvisibility=hidden -mtune=generic -m32 -march=i686 -Wl,-z,defs -O3 -DNDEBUG -fPIC     -std=c++11 -MD -MT plugins/labormanager/CMakeFiles/labormanager.dir/joblabormapper.cpp.o -MF plugins/labormanager/CMakeFiles/labormanager.dir/joblabormapper.cpp.o.d -o plugins/labormanager/CMakeFiles/labormanager.dir/joblabormapper.cpp.o -c ../plugins/labormanager/joblabormapper.cpp
../plugins/labormanager/joblabormapper.cpp: In constructor ‘JobLaborMapper::JobLaborMapper()’:
../plugins/labormanager/joblabormapper.cpp:900:38: error: ‘unk_fake_no_job’ is not a member of ‘df::enums::job_type::job_type’
     job_to_labor_table[df::job_type::unk_fake_no_job] = jlf_no_labor; // added for 47.04 - see #1561
                                      ^~~~~~~~~~~~~~~
../plugins/labormanager/joblabormapper.cpp:901:38: error: ‘InterrogateSubject’ is not a member of ‘df::enums::job_type::job_type’
     job_to_labor_table[df::job_type::InterrogateSubject] = jlf_no_labor; // added for 47.04 - see #1561
                                      ^~~~~~~~~~~~~~~~~~
../plugins/labormanager/joblabormapper.cpp:902:38: error: ‘unk_fake_no_activity’ is not a member of ‘df::enums::job_type::job_type’
     job_to_labor_table[df::job_type::unk_fake_no_activity] = jlf_no_labor; // added for 47.04 - see #1561
                                      ^~~~~~~~~~~~~~~~~~~~
[23/123] Building CXX object library/CMakeFiles/dfhack.dir/LuaApi.cpp.o
ninja: build stopped: subcommand failed.

You probably need to run "git submodule update", or "git pull" from within the library/xml folder. See https://docs.dfhack.org/en/stable/docs/Compile.html for more details, specifically the note in this section (https://docs.dfhack.org/en/stable/docs/Compile.html#how-to-get-the-code).

I ran git pull from the dfhack directory.  I'll try and see if what you suggested makes any difference.

(Also, which branch is "the stable branch"? We recently switched the default branch to "develop", because that's what most people who build from source typically want, but the most recent stable release, currently 0.47.04-r1, is on the "master" branch.)
Yeah, I'm using the default branch as that is what the compile doc said was the stable branch.  There is a possibility that I did the original cloning before you made the change.  How long ago did you change the default branch to the development branch?

Quote
Ah, here it is:
Code: [Select]
CMake Warning at depends/jsoncpp-sub/src/lib_json/CMakeLists.txt:36 (MESSAGE):
   Locale functionality is not supported
Looking at the file in question, that should just be a warning, and the build should be able to continue despite that. That said, what compiler are you using? We only support MSVC 2015 on Windows (which is a hard requirement) and GCC 4.8+ on other platforms, and I don't recall seeing this particular warning before, but maybe it's something system-specific, not compiler-specific.

I'm using GCC 8.3.0 on Linux.  It might be system specific.  If I can get DFHack to compile, I'll just probably just ignore it.

Edit:

Well I ran git submodule update from the dfhack directory.  It compiled just fine.  I did have to edit the DFHack script to include a reference to libz.so.1, though I had to do that when I originally installed dfhack too (also had to make a similar change to ./df in order to get that to work).

Still says I'm using the beta1, though for some reason.

Edit2:

Just tried running git checkout master and then git submodule update from the dfhack directory.

git submodule update gave me this error message:
Code: [Select]
Submodule path 'depends/clsocket': checked out '6a9153d053a250be34996b3fd86ac1166c3e17cb'
Submodule path 'library/xml': checked out '4053321b202a29f667d64d824ba8339ec1b1df4f'
error: The following untracked working tree files would be overwritten by checkout:
agui/include/Agui/ActionEvent.hpp
agui/include/Agui/ActionListener.hpp
agui/include/Agui/Agui.hpp
agui/include/Agui/Backends/Allegro5/Allegro5.hpp
agui/include/Agui/Backends/Allegro5/Allegro5CursorProvider.hpp
agui/include/Agui/Backends/Allegro5/Allegro5Font.hpp
agui/include/Agui/Backends/Allegro5/Allegro5FontLoader.hpp
agui/include/Agui/Backends/Allegro5/Allegro5Graphics.hpp
agui/include/Agui/Backends/Allegro5/Allegro5Image.hpp
agui/include/Agui/Backends/Allegro5/Allegro5ImageLoader.hpp
agui/include/Agui/Backends/Allegro5/Allegro5Input.hpp
agui/include/Agui/BaseTypes.hpp
agui/include/Agui/BlinkingEvent.hpp
agui/include/Agui/BorderLayout.hpp
agui/include/Agui/Clipboard/Clipboard.hpp
agui/include/Agui/Clipboard/OSXClipboard.hpp
agui/include/Agui/Clipboard/WinClipboard.hpp
agui/include/Agui/Color.hpp
agui/include/Agui/CursorProvider.hpp
agui/include/Agui/Dimension.hpp
agui/include/Agui/EmptyWidget.hpp
agui/include/Agui/Enumerations.hpp
agui/include/Agui/EventArgs.hpp
agui/include/Agui/FlowLayout.hpp
agui/include/Agui/FocusListener.hpp
agui/include/Agui/FocusManager.hpp
agui/include/Agui/Font.hpp
agui/include/Agui/FontLoader.hpp
agui/include/Agui/Graphics.hpp
agui/include/Agui/GridLayout.hpp
agui/include/Agui/Gui.hpp
agui/include/Agui/Image.hpp
agui/include/Agui/ImageLoader.hpp
agui/include/Agui/Input.hpp
agui/include/Agui/KeyboardListener.hpp
agui/include/Agui/Layout.hpp
agui/include/Agui/MouseListener.hpp
agui/include/Agui/Platform.hpp
agui/include/Agui/Point.hpp
agui/include/Agui/Rectangle.hpp
agui/include/Agui/ResizableBorderLayout.hpp
agui/include/Agui/ResizableText.hpp
agui/include/Agui/SelectionListener.hpp
agui/include/Agui/TableLayout.hpp
agui/include/Agui/TopContainer.hpp
agui/include/Agui/Transform.hpp
agui/include/Agui/UTF8.hpp
agui/include/Agui/Widget.hpp
agui/include/Agui/WidgetListener.hpp
agui/include/Agui/Widgets/Button/Button.hpp
agui/include/Agui/Widgets/Button/ButtonGroup.hpp
agui/include/Agui/Widgets/Button/ButtonListener.hpp
agui/include/Agui/Widgets/CheckBox/CheckBox.hpp
agui/include/Agui/Widgets/CheckBox/CheckBoxListener.hpp
agui/include/Agui/Widgets/DropDown/DropDown.hpp
agui/include/Agui/Widgets/DropDown/DropDownListener.hpp
agui/include/Agui/Widgets/Frame/Frame.hpp
agui/include/Agui/Widgets/Frame/FrameListener.hpp
agui/include/Agui/Widgets/ImageWidget/ImageWidget.hpp
agui/include/Agui/Widgets/Label/Label.hpp
agui/include/Agui/Widgets/Label/LabelListener.hpp
agui/include/Agui/Widgets/ListBox/ListBox.hpp
agui/include/Agui/Widgets/ListBox/ListBoxListener.hpp
agui/include/Agui/Widgets/PopUp/PopUpMenu.hpp
agui/include/Agui/Widgets/PopUp/PopUpMenuItem.hpp
agui/include/Agui/Widgets/RadioButton/RadioButton.hpp
agui/include/Agui/Widgets/RadioButton/RadioButtonGroup.hpp
agui/include/Agui/Widgets/RadioButton/RadioButtonListener.hpp
agui/include/Agui/Widgets/ScrollBar/HScrollBar.hpp
agui/include/Agui/Widgets/ScrollBar/HScrollBarListener.hpp
agui/include/Agui/Widgets/ScrollBar/VScrollBar.hpp
agui/include/Agui/Widgets/ScrollBar/VScrollBarListener.hpp
agui/include/Agui/Widgets/ScrollPane/ScrollPane.hpp
agui/include/Agui/Widgets/Slider/Slider.hpp
agui/include/Agui/Widgets/Slider/SliderListener.hpp
agui/include/Agui/Widgets/Tab/Tab.hpp
agui/include/Agui/Widgets/Tab/TabbedPane.hpp
agui/include/Agui/Widgets/Tab/TabbedPaneListener.hpp
agui/include/Agui/Widgets/TextBox/ExtendedTextBox.hpp
agui/include/Agui/Widgets/TextBox/TextBox.hpp
agui/include/Agui/Widgets/TextBox/TextBoxListener.hpp
agui/include/Agui/Widgets/TextField/TextField.hpp
agui/include/Agui/Widgets/TextField/TextFieldListener.hpp
agui/include/Agui/Widgets/ToolTip/ToolTip.hpp
Please move or remove them before you switch branches.
Aborting
Submodule path 'plugins/stonesense': checked out '4fdb2be54365442b8abea86f21746795f83fbdc2'
Submodule path 'scripts': checked out '790e2efbe9d987d8678375ee634991fe4c324f1d'
Unable to checkout 'fbbf9e46458e41707c27f2a4438452a579490db1' in submodule path 'plugins/isoworld'

Any Ideas.  IIRC, I've had problems with Agui before.  It's not available for debian based systems when using the package manager, and I'm not sure how to install libraries by hand.  There used to be some instructions on how to get Agui, Isoworld, and Stonesense working, but they stopped working in newer versions.  Usually, I just set ccmake to not compile Isoworld and Stonesense.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 13, 2020, 10:11:43 pm
Apparently parts of our docs are very outdated. I've started to update some of them, but it will be a while before they're all done. I wish I had gotten to the Compile doc sooner; I can imagine parts of it have confused people recently. Some updates are at https://docs.dfhack.org/en/latest/docs/Compile.html if anyone would like to provide feedback (note that "latest" on ReadTheDocs corresponds to "develop" on GitHub, and "stable" = "master"). I may try to backport some of these changes to the master/stable version before the next release, if a lot of people are looking there for instructions too.

Yeah, that makes sense.  Thanks for the link to the docs.  Interesting that the search engine in the page couldn't pull that up...
I kind of cheated and searched for "eggs-fertile" because I knew what it was, but even then, it didn't show up in the first couple results. Searching for just "fertile" pulls up the plugins page as expected, but result #5 out of 5, and quotes the nestboxes plugin. The Sphinx search engine isn't always the best (but also neither are our docs).

Quote
Yeah, I'm using the default branch as that is what the compile doc said was the stable branch.  There is a possibility that I did the original cloning before you made the change.  How long ago did you change the default branch to the development branch?
Maybe in March? I don't really know. That particular part of the docs was last updated in 2015, and I realized as soon as I posted that it was probably the source of the confusion. https://docs.dfhack.org/en/latest/docs/Compile.html#how-to-get-the-code should be up-to-date now (see my comment about the URL earlier in this post) - does that help? I'm happy to tweak it further.

Quote
Well I ran git submodule update from the dfhack directory.  It compiled just fine.  I did have to edit the DFHack script to include a reference to libz.so.1, though I had to do that when I originally installed dfhack too (also had to make a similar change to ./df in order to get that to work).

Still says I'm using the beta1, though for some reason.
The DFHack script you're referring to is the "dfhack" launcher in the DF folder, right? You should also be able to set the PRELOAD_LIB environment variable to do that (instead of editing the launcher), and you can set that in ~/.dfhackrc or /path/to/df/.dfhackrc. (Yet another mostly-undocumented feature that we should address...)


Update:

Still says I'm using the beta1, though for some reason.
Not sure on this. Things you could try: running "git describe --tags" in the source folder, or running "install-info" from the DFHack console.

Quote
Edit2:

Just tried running git checkout master and then git submodule update from the dfhack directory.

git submodule update gave me this error message:
Code: [Select]
Submodule path 'depends/clsocket': checked out '6a9153d053a250be34996b3fd86ac1166c3e17cb'
Submodule path 'library/xml': checked out '4053321b202a29f667d64d824ba8339ec1b1df4f'
error: The following untracked working tree files would be overwritten by checkout:
agui/include/Agui/ActionEvent.hpp
agui/include/Agui/ActionListener.hpp
agui/include/Agui/Agui.hpp
-snip-
Any Ideas.  IIRC, I've had problems with Agui before.  It's not available for debian based systems when using the package manager, and I'm not sure how to install libraries by hand.  There used to be some instructions on how to get Agui, Isoworld, and Stonesense working, but they stopped working in newer versions.  Usually, I just set ccmake to not compile Isoworld and Stonesense.
I'm assuming you set BUILD_ISOWORLD to ON? I've probably never run into this because I've never built Isoworld locally before. Does it still work? (I honestly don't know; it defaults to OFF in plugins/CMakeLists.txt, and I don't think we distribute it currently.)

Did you do anything special to get a copy of isoworld besides cloning DFHack? I'm mostly confused because at least the first one, agui/include/Agui/ActionEvent.hpp, exists in plugins/isoworld on my end, and Git seems to know about them. Actually, it looks like these files were only added to the repo in January 2020 (they were probably ignored before then) - is your clone earlier than that? Those files are pretty easy to replace, assuming you haven't changed them at all, so you could just try adding "--force" to the "git submodule update" command and see if that works.
Title: Re: DFHack 0.47.04-r1
Post by: A_Curious_Cat on May 13, 2020, 10:52:59 pm
Apparently parts of our docs are very outdated. I've started to update some of them, but it will be a while before they're all done. I wish I had gotten to the Compile doc sooner; I can imagine parts of it have confused people recently. Some updates are at https://docs.dfhack.org/en/latest/docs/Compile.html if anyone would like to provide feedback (note that "latest" on ReadTheDocs corresponds to "develop" on GitHub, and "stable" = "master"). I may try to backport some of these changes to the master/stable version before the next release, if a lot of people are looking there for instructions too.
Yeah, I just took a look at that doc and it still says that you have to run git checkout develop in order to get the development branch (implying that the default branch is the stable branch).

Quote
Yeah, I'm using the default branch as that is what the compile doc said was the stable branch.  There is a possibility that I did the original cloning before you made the change.  How long ago did you change the default branch to the development branch?
Maybe in March? I don't really know. That particular part of the docs was last updated in 2015, and I realized as soon as I posted that it was probably the source of the confusion. https://docs.dfhack.org/en/latest/docs/Compile.html#how-to-get-the-code should be up-to-date now (see my comment about the URL earlier in this post) - does that help? I'm happy to tweak it further.
I cloned it after that.  I'm probably on the development branch then...

Quote
Well I ran git submodule update from the dfhack directory.  It compiled just fine.  I did have to edit the DFHack script to include a reference to libz.so.1, though I had to do that when I originally installed dfhack too (also had to make a similar change to ./df in order to get that to work).

Still says I'm using the beta1, though for some reason.
The DFHack script you're referring to is the "dfhack" launcher in the DF folder, right? You should also be able to set the PRELOAD_LIB environment variable to do that (instead of editing the launcher), and you can set that in ~/.dfhackrc or /path/to/df/.dfhackrc. (Yet another mostly-undocumented feature that we should address...)
How would I go about doing that?  just make a file called ".dfhackrc" and include a line that says "PRELOAD_LIB=libz.so.1"?


Still says I'm using the beta1, though for some reason.
Not sure on this. Things you could try: running "git describe --tags" in the source folder, or running "install-info" from the DFHack console.

git describe --tags gives me

    0.44.12-r3

install-info gives me:

Code: [Select]
DFHack 0.47.04-r1 on linux/x86

Version information:
    DF version: v0.47.04 linux32
    DFHack version: 0.47.04-r1
    DFHack release: r1
    DFHack build ID:
    Compiled DF version: 0.47.04
    Git description: 0.47.04-beta1-122-g0ffafbde
    Git commit: 0ffafbde298cc84003ebec0de75013d6baa547e9
    Git XML commit: efc5c2610bd0345e9102279be0a9f154e5862050
    Git XML expected commit: efc5c2610bd0345e9102279be0a9f154e5862050
    Git XML match: true
    Is release: false
    Is prerelease: false
    Is world loaded: false
    Is map loaded: false

Output of "devel/save-version":
    devel/save-version: no world loaded
   

Output of "plug":
                              Name      State Cmds  Enabled
                           3dveins     loaded    1      n/a
              RemoteFortressReader     loaded    2  enabled
                       add-spatter     loaded    0 disabled
                          autochop     loaded    1  enabled
                      autoclothing     loaded    1 disabled
                          autodump     loaded    3  enabled
                          autofarm     loaded    1 disabled
                          autogems     loaded    1  enabled
                        autohauler     loaded    1 disabled
                         autolabor     loaded    1 disabled
                      automaterial     loaded    0  enabled
                          automelt     loaded    1  enabled
                         autotrade     loaded    0  enabled
                         blueprint     loaded    1      n/a
                    building-hacks     loaded    0      n/a
                      buildingplan     loaded    1  enabled
                           burrows     loaded    1 disabled
                        changeitem     loaded    1      n/a
                       changelayer     loaded    1      n/a
                        changevein     loaded    1      n/a
                        cleanconst     loaded    1      n/a
                          cleaners     loaded    2      n/a
                        cleanowned     loaded    1      n/a
                    command-prompt     loaded    1      n/a
                           confirm     loaded    1  enabled
                        createitem     loaded    1      n/a
                        cursecheck     loaded    1      n/a
                         cxxrandom     loaded    0      n/a
                             debug     loaded    1      n/a
                            deramp     loaded    1      n/a
                               dig     loaded    7      n/a
                          digFlood     loaded    1 disabled
                   diggingInvaders     loaded    1 disabled
                      dwarfmonitor     loaded    1  enabled
                          dwarfvet     loaded    1 disabled
                  embark-assistant     loaded    1  enabled
                      embark-tools     loaded    1  enabled
                          eventful     loaded    0      n/a
                         fastdwarf     loaded    1 disabled
                       filltraffic     loaded    4      n/a
                        fix-armory     loaded    1 disabled
                fix-unit-occupancy     loaded    1 disabled
                          fixveins     loaded    1      n/a
                             flows     loaded    1      n/a
                            follow     loaded    1 disabled
                        forceequip     loaded    1      n/a
                          fortplan     loaded    1 disabled
        generated-creature-renamer     loaded    2 disabled
                         getplants     loaded    1      n/a
                           hotkeys     loaded    1      n/a
                       infiniteSky     loaded    1 disabled
                    isoworldremote     loaded    0      n/a
                          jobutils     loaded    3      n/a
                      labormanager     loaded    1 disabled
                              lair     loaded    1      n/a
                           liquids     loaded    2      n/a
                         luasocket     loaded    0      n/a
                       manipulator     loaded    0  enabled
                        map-render     loaded    0      n/a
                            misery     loaded    1 disabled
                              mode     loaded    1      n/a
                        mousequery     loaded    1  enabled
                         nestboxes     loaded    1 disabled
                            orders     loaded    1      n/a
                          pathable     loaded    0      n/a
                     petcapRemover     loaded    1 disabled
                            plants     loaded    1      n/a
                       power-meter     loaded    0 disabled
                             probe     loaded    3      n/a
                        prospector     loaded    1      n/a
                           regrass     loaded    1      n/a
                            rename     loaded    1 disabled
                         rendermax     loaded    1      n/a
                            resume     loaded    1  enabled
                            reveal     loaded    6 disabled
                              ruby     loaded    2  enabled
                            search     loaded    0  enabled
                         seedwatch     loaded    1 disabled
                          showmood     loaded    1      n/a
                      siege-engine     loaded    0 disabled
                              sort     loaded    2      n/a
                      steam-engine     loaded    0 disabled
                         stockflow     loaded    1 disabled
                        stockpiles     loaded    3  enabled
                            stocks     loaded    1  enabled
                       strangemood     loaded    1      n/a
                            tailor     loaded    1 disabled
                         tiletypes     loaded    4      n/a
                      title-folder     loaded    0 disabled
                     title-version     loaded    0  enabled
                         trackstop     loaded    0  enabled
                          tubefill     loaded    1      n/a
                             tweak     loaded    1  enabled
                           workNow     loaded    1      n/a
                          workflow     loaded    2 disabled
                              zone     loaded    3  enabled
   
Tweak log entries:
    loading plugin tweak
    loaded plugin tweak; DFHack build 0.47.04-beta1-122-g0ffafbde
    Invoking: tweak stable-cursor
    Enabled tweak stable-cursor (stable_cursor_hook::feed)
    Invoking: tweak advmode-contained
    Enabled tweak advmode-contained (advmode_contained_hook::feed)
    Invoking: tweak fast-trade
    Enabled tweak fast-trade (fast_trade_assign_hook::feed)
    Enabled tweak fast-trade (fast_trade_select_hook::feed)
    Invoking: tweak military-stable-assign
    Enabled tweak military-stable-assign (military_assign_hook::feed)
    Invoking: tweak military-color-assigned
    Enabled tweak military-color-assigned (military_assign_hook::render)
    Invoking: tweak craft-age-wear
    Enabled tweak craft-age-wear (craft_age_wear_hook::ageItem)
    Invoking: tweak farm-plot-select
    Enabled tweak farm-plot-select (farm_select_hook::feed)
    Enabled tweak farm-plot-select (farm_select_hook::render)
    Invoking: tweak import-priority-category
    Enabled tweak import-priority-category (takerequest_hook::feed)
    Enabled tweak import-priority-category (takerequest_hook::render)
    Invoking: tweak condition-material
    Enabled tweak condition-material (condition_material_hook::feed)
    Invoking: tweak hotkey-clear
    Enabled tweak hotkey-clear (hotkey_clear_hook::feed)
    Enabled tweak hotkey-clear (hotkey_clear_hook::render)
    Invoking: tweak embark-profile-name
    Enabled tweak embark-profile-name (embark_profile_name_hook::feed)
    Invoking: tweak block-labors              # Prevents labors that can't be used from being toggled
    Enabled tweak block-labors (block_labors_hook::feed)
    Enabled tweak block-labors (block_labors_hook::render)
    Invoking: tweak burrow-name-cancel
    Enabled tweak burrow-name-cancel (burrow_name_cancel_hook::feed)
    Invoking: tweak cage-butcher
    Enabled tweak cage-butcher (cage_butcher_hook::feed)
    Enabled tweak cage-butcher (cage_butcher_hook::render)
    Invoking: tweak civ-view-agreement
    Enabled tweak civ-view-agreement (civ_agreement_view_hook::render)
    Invoking: tweak eggs-fertile
    Enabled tweak eggs-fertile (egg_fertile_hook::render)
    Invoking: tweak fps-min
    Enabled tweak fps-min (fps_min_hook)
    Invoking: tweak hide-priority
    Enabled tweak hide-priority (hide_priority_hook::feed)
    Enabled tweak hide-priority (hide_priority_hook::render)
    Invoking: tweak kitchen-prefs-all
    Enabled tweak kitchen-prefs-all (kitchen_prefs_all_hook::feed)
    Enabled tweak kitchen-prefs-all (kitchen_prefs_all_hook::render)
    Invoking: tweak kitchen-prefs-empty
    Enabled tweak kitchen-prefs-empty (kitchen_prefs_empty_hook::render)
    Invoking: tweak max-wheelbarrow
    Enabled tweak max-wheelbarrow (max_wheelbarrow_hook::render)
    Enabled tweak max-wheelbarrow (max_wheelbarrow_hook::feed)
    Invoking: tweak shift-8-scroll
    Enabled tweak shift-8-scroll (shift_8_scroll_hook::feed)
    Invoking: tweak stone-status-all
    Enabled tweak stone-status-all (stone_status_all_hook::feed)
    Enabled tweak stone-status-all (stone_status_all_hook::render)
    Invoking: tweak title-start-rename
    Enabled tweak title-start-rename (title_start_rename_hook::feed)
    Enabled tweak title-start-rename (title_start_rename_hook::render)
    Invoking: tweak tradereq-pet-gender
    Enabled tweak tradereq-pet-gender (pet_gender_hook::render)


Quote
Edit2:

Just tried running git checkout master and then git submodule update from the dfhack directory.

git submodule update gave me this error message:
Code: [Select]
Submodule path 'depends/clsocket': checked out '6a9153d053a250be34996b3fd86ac1166c3e17cb'
Submodule path 'library/xml': checked out '4053321b202a29f667d64d824ba8339ec1b1df4f'
error: The following untracked working tree files would be overwritten by checkout:
agui/include/Agui/ActionEvent.hpp
agui/include/Agui/ActionListener.hpp
agui/include/Agui/Agui.hpp
-snip-
Any Ideas.  IIRC, I've had problems with Agui before.  It's not available for debian based systems when using the package manager, and I'm not sure how to install libraries by hand.  There used to be some instructions on how to get Agui, Isoworld, and Stonesense working, but they stopped working in newer versions.  Usually, I just set ccmake to not compile Isoworld and Stonesense.
I'm assuming you set BUILD_ISOWORLD to ON? I've probably never run into this because I've never built Isoworld locally before. Does it still work? (I honestly don't know; it defaults to OFF in plugins/CMakeLists.txt, and I don't think we distribute it currently.)
I have BUILD_ISOWORLD set to OFF.

Did you do anything special to get a copy of isoworld besides cloning DFHack? I'm mostly confused because at least the first one, agui/include/Agui/ActionEvent.hpp, exists in plugins/isoworld on my end, and Git seems to know about them. Actually, it looks like these files were only added to the repo in January 2020 (they were probably ignored before then) - is your clone earlier than that? Those files are pretty easy to replace, assuming you haven't changed them at all, so you could just try adding "--force" to the "git submodule update" command and see if that works.

I didn't do anything special.  All I did was change from the default branch to the master branch and run git submodule update.  I also cloned the project well after January 2020.  I'll try using git submodule update --force.

Edit:

running git submodule update gave me this:

Code: [Select]
Submodule path 'depends/clsocket': checked out '6a9153d053a250be34996b3fd86ac1166c3e17cb'
Submodule path 'depends/jsoncpp-sub': checked out 'ddabf50f72cf369bf652a95c4d9fe31a1865a781'
Submodule path 'library/xml': checked out '4053321b202a29f667d64d824ba8339ec1b1df4f'
warning: unable to rmdir 'agui': Directory not empty
warning: unable to rmdir 'allegro': Directory not empty
Submodule path 'plugins/isoworld': checked out 'fbbf9e46458e41707c27f2a4438452a579490db1'
Submodule path 'plugins/stonesense': checked out '4fdb2be54365442b8abea86f21746795f83fbdc2'
Submodule path 'scripts': checked out '790e2efbe9d987d8678375ee634991fe4c324f1d'

Running ccmake .. and choosing [c]onfigure resulted in this:
Code: [Select]
CMake Warning (dev) at CMakeLists.txt:376 (find_package):
   Policy CMP0074 is not set: find_package uses <PackageName>_ROOT variables.
   Run "cmake --help-policy CMP0074" for policy details.  Use the cmake_policy
   command to set the policy and suppress this warning.

   CMake variable ZLIB_ROOT is set to:

     /usr/lib/i386-linux-gnu

   For compatibility, CMake is ignoring the variable.
 This warning is for project developers.  Use -Wno-dev to suppress it.


 CMake Warning at depends/jsoncpp-sub/src/lib_json/CMakeLists.txt:36 (MESSAGE):
   Locale functionality is not supported

Currently running ninja -j8 install...

Edit2:

ninja -j8 install gave me some warning about files that were present but not configured.

creating a file called .dfhackrc, putting the line "PRELOAD_LIB=libz.so.1" in it (without the  parentheses), and running dfhack made dfhack spit out this:

Code: [Select]
Loading bindings from data/init/interface.txt
New window size: 800x300
Font size: 10x12
Resizing grid to 80x25
Resizing font to 10x12

Resetting textures
./dfhack: line 83: 15504 Segmentation fault      setarch "$setarch_arch" -R env LD_PRELOAD="$PRELOAD_LIB" ./libs/Dwarf_Fortress "$@"

Edit3:

removing .dfhackrc, editing dfhack directly, and then running dfhack, results in:

Code: [Select]
Loading bindings from data/init/interface.txt
New window size: 800x300
Font size: 10x12
Resizing grid to 80x25
Resizing font to 10x12

Resetting textures
./dfhack: line 83: 15577 Segmentation fault      setarch "$setarch_arch" -R env LD_PRELOAD="$PRELOAD_LIB libz.so.1" ./libs/Dwarf_Fortress "$@"


Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 14, 2020, 12:14:27 am
Yeah, I just took a look at that doc and it still says that you have to run git checkout develop in order to get the development branch (implying that the default branch is the stable branch).
Where are you seeing that? The link I posted is a different version of the docs:
Quote from: https://docs.dfhack.org/en/latest/docs/Compile.html#how-to-get-the-code
This will check out the code on the default branch of the GitHub repo, currently develop, which may be unstable. If you want code for the latest stable release, you can check out the master branch instead:

git checkout master
git submodule update
It did change recently, so if your browser has it cached, you could try hard-refreshing (e.g. ctrl-shift-r in Chrome) or clearing your cache.

Quote
How would I go about doing that?  just make a file called ".dfhackrc" and include a line that says "PRELOAD_LIB=libz.so.1"?
Yeah, that should do it. The launcher just sources .dfhackrc, so you shouldn't even need "export" (like you would in a shell, for instance).

Quote
git describe --tags gives me

    0.44.12-r3

install-info gives me:

Code: [Select]
DFHack 0.47.04-r1 on linux/x86

Version information:
    DF version: v0.47.04 linux32
    DFHack version: 0.47.04-r1
    DFHack release: r1
    DFHack build ID:
    Compiled DF version: 0.47.04
    Git description: 0.47.04-beta1-122-g0ffafbde
    Git commit: 0ffafbde298cc84003ebec0de75013d6baa547e9
    Git XML commit: efc5c2610bd0345e9102279be0a9f154e5862050
    Git XML expected commit: efc5c2610bd0345e9102279be0a9f154e5862050
    Git XML match: true
    Is release: false
    Is prerelease: false
    Is world loaded: false
    Is map loaded: false

I'm confused. 0ffafbde298cc84003ebec0de75013d6baa547e9 is from May 9, and "git describe --tags 0ffafbde298cc84003ebec0de75013d6baa547e9" gives me "0.47.04-r1-18-g0ffafbde" - at the very least, you should get more detail than just "0.44.12-r3". The only explanation I can think of is that you're missing recent tags, but that should only occur if you didn't clone the repo recently. Just in case that's what happened, try running "git fetch --tags" and see if that changes anything? At any rate, according to "install-info", the Git description is the only thing that's different, and that's really just for diagnostic purposes, so I wouldn't worry much more about it.



Quote
I have BUILD_ISOWORLD set to OFF.
I think your best bet is clearing the entire plugins/isoworld folder and trying again. Turns out that my earlier guess about the files being added earlier was wrong - in this commit (https://github.com/dfhack/isoworld/commit/0b483bae30c0d8b4b148d82fe594ae262286e979), they were actually changed to submodules, and that tends to lead to confusing errors like this when switching between branches (since in one revision, the files are part of the DFHack repo, and in the other, the files exist but the DFHack repo isn't tracking them). You might also need some extra options to get isoworld's submodules to update (which I should add to the docs...): "git submodule update --init --recursive"

Quote
Running ccmake .. and choosing [c]onfigure resulted in this:
Code: [Select]
CMake Warning (dev) at CMakeLists.txt:376 (find_package):
   Policy CMP0074 is not set: find_package uses <PackageName>_ROOT variables.
   Run "cmake --help-policy CMP0074" for policy details.  Use the cmake_policy
   command to set the policy and suppress this warning.

   CMake variable ZLIB_ROOT is set to:

     /usr/lib/i386-linux-gnu

   For compatibility, CMake is ignoring the variable.
 This warning is for project developers.  Use -Wno-dev to suppress it.
This one is weird. I made a fix here (https://github.com/dfhack/dfhack/commit/d3a007489) specifically for this issue, and it should be on both develop and master by now. What CMake version are you using?
Title: Re: DFHack 0.47.04-r1
Post by: martinuzz on May 14, 2020, 08:08:28 am
So I wanted to give my starting dwarves some musician skills, and tried
'embark-skills points 20'
but nothing happened.
is embark-skills not working in the new version?

EDIT: I did find a workaround by using embark-skills max all.
4170 minus key, 860 down arrow, 7 left arrow and 7 right arrow keypresses later... All 7 dwarves now have 620 skillpoints to spend hahaha
I guess I can just put 10 points in musician skills and leave the rest untouched, and then I can embark with my performance troupe.
Title: Re: DFHack 0.47.04-r1
Post by: A_Curious_Cat on May 14, 2020, 10:06:11 am
Ok. It looks like I got it to work.

What I did was to:
  1.  rm -rf the dfhack directory
  2.  git clone --recursive https://github.com/DFHack/dfhack
  3.  cd dfhack
  5.  git checkout master
  6.  git submodule update
  7.  cd build
  8.  ccmake .. -G Ninja
  9.  ninja -j8 install
 10. cd to the df_linux directory and create the .dfhackrc file.


After that it seems to work just fine.

Edit:  Edited to use corrwect command.
Title: Re: DFHack 0.47.04-r1
Post by: martinuzz on May 14, 2020, 11:47:38 am
Oh hahaha. Now all my dwarves are strand extractor - druid - climber blowgunners.
Apparently the max all gave them all possible skills at proficient, including the ones not in the list at embark.
They also know all musical instruments, dances and musical performances.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 14, 2020, 06:40:00 pm
Ok. It looks like I got it to work.

What I did was to:
  1.  rm -rf the dfhack directory
  2.  git clone --recursive https://github.com/DFHack/dfhack
  3.  cd dfhack
  5.  git clone checkout master
Cool! Sometimes submodule changes are hard to resolve without just starting with a fresh clone of DFHack. (By the way, in case anyone tries to copy that, step 5 should just be "git checkout master".)

So I wanted to give my starting dwarves some musician skills, and tried
'embark-skills points 20'
but nothing happened.
is embark-skills not working in the new version?
I was able to reproduce the issue with the command you gave in 0.47.04-r1 (64-bit Linux). There were close to 150 (!) new fields added to that screen in 0.47, so it's entirely possible that one is wrong and broke the script. I've opened an issue here (https://github.com/DFHack/dfhack/issues/1572). In the future, it would be helpful to specify the DFHack version and OS you're using to help us figure out how to reproduce it.
Title: Re: DFHack 0.47.04-r1
Post by: martinuzz on May 15, 2020, 07:00:58 am
Thanks for looking into it!Sorry, I am using the latest DFhack version, 47.04 DF, Win10
Could the issue not stem from 'points' being used as a script of it's own?
What happens if you change the 'points' command of the embark-skills to 'pts' ?
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 15, 2020, 06:22:28 pm
Could the issue not stem from 'points' being used as a script of it's own?
What happens if you change the 'points' command of the embark-skills to 'pts' ?
No, definitely not - once DFHack starts running a script, it doesn't get it confused with another script. (Scripts can run other scripts, but this one doesn't.)

In case you didn't see https://github.com/DFHack/dfhack/issues/1572, to paraphrase it: skill_points_remaining is in the wrong place following some changes in 0.47.01, so the script is setting something to 20, just not the right thing.
Title: Re: DFHack 0.47.04-r1
Post by: MaxTheFox on May 16, 2020, 08:37:09 am
Are there any scripts for cheating in adventurer equipment points? A cursory search revealed nothing.
Title: Re: DFHack 0.47.04-r1
Post by: Rumrusher on May 16, 2020, 09:18:53 am
Are there any scripts for cheating in adventurer equipment points? A cursory search revealed nothing.
last I mess around with that the game crashed, chances are the best you can get is max skill points but I think the one currently made is set up for solo adventurers and not adv parties so you end up with 1.
fake edit: that said after testing,  I think you could use gm-editor to change the value of the points.
 if you use 'gm-editor scr ' during the adv character creation screen and just go to the party member tab and poke around there until you find a value called 'equip points remaining' which is where you want to go if you want to change the point total.
Title: Re: DFHack 0.47.04-r1
Post by: fortunawhisk on May 16, 2020, 07:14:53 pm
I found an unexpected error when trying to use "k" to select a body part for the deathcause.rb script in v47.04-r05 (Win10 64bit). Other methods of selecting a target seem to work fine (Unit list, stock screen, etc).
Code: [Select]
[DFHack]# deathcause
E: NoMethodError: undefined method `item' for #<DFHack::UiLookList_TItems:0x00017950e15ee0>
 C:/DOWNLO~1/PERIDE~2.04-/Dwarf Fortress 0.47.04/hack/ruby/item.rb:25:in `item_find'
 hack/scripts/deathcause.rb:44:in `<top (required)>'
 eval:2:in `load'
 eval:2:in `block in <main>'
 eval:2:in `catch'
 eval:2:in `<main>'

After digging a bit, this looks like it might be caused by a difference in the way the UiLookList class is set up in ruby-autogen-win.rb for 47.04 vs 44.12? I'm not familiar with ruby at all, but I was able to get the script to work for historical creature parts by just pasting the field definition(?) for :item from an older version outside the :data field block it currently lives in. I wasn't able to get the :item version that lives in the :data block to work by just moving it. Looking at non-historical creature parts with the modified ruby-autogen-win.rb caused errors and occasional crashes. 
Title: Re: DFHack 0.47.04-r1
Post by: Iä! RIAKTOR! on May 17, 2020, 06:31:13 am
How make script for reaction of creating live creatures from items?
Title: Re: DFHack 0.47.04-r1
Post by: Fleeting Frames on May 17, 2020, 06:55:48 am
You need eventful. Here's a "magma buckets" example: Link (http://www.bay12forums.com/smf/index.php?topic=141497.msg5526201#msg5526201).
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 17, 2020, 08:32:15 am
I found an unexpected error when trying to use "k" to select a body part for the deathcause.rb script in v47.04-r05 (Win10 64bit). Other methods of selecting a target seem to work fine (Unit list, stock screen, etc).
Code: [Select]
[DFHack]# deathcause
E: NoMethodError: undefined method `item' for #<DFHack::UiLookList_TItems:0x00017950e15ee0>
 C:/DOWNLO~1/PERIDE~2.04-/Dwarf Fortress 0.47.04/hack/ruby/item.rb:25:in `item_find'
 hack/scripts/deathcause.rb:44:in `<top (required)>'
 eval:2:in `load'
 eval:2:in `block in <main>'
 eval:2:in `catch'
 eval:2:in `<main>'

After digging a bit, this looks like it might be caused by a difference in the way the UiLookList class is set up in ruby-autogen-win.rb for 47.04 vs 44.12? I'm not familiar with ruby at all, but I was able to get the script to work for historical creature parts by just pasting the field definition(?) for :item from an older version outside the :data field block it currently lives in. I wasn't able to get the :item version that lives in the :data block to work by just moving it. Looking at non-historical creature parts with the modified ruby-autogen-win.rb caused errors and occasional crashes.
You're right that it was a change we made in 0.47. I've already fixed it, although the fix isn't part of a release yet: https://github.com/DFHack/dfhack/issues/1563. You could probably install a development build with the fix if you want.

The file you're modifying is automatically generated (as its name implies) and is generally not intended to be modified. Rather, the file(s) using the definitions should be modified. I tracked down the file in question in the issue linked above, but the actual change I made does most of the work in C++, which helps us catch future issues like these sooner.
Title: Re: DFHack 0.47.04-r1
Post by: Mim on May 17, 2020, 08:35:29 am
Is playing with DFHack's digging invaders any fun?
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on May 18, 2020, 01:10:33 am
Is it possible to call map.rb's map_tile_at(x,y,z) from a lua script, or do I have to implement my own?
Title: Re: DFHack 0.47.04-r1
Post by: Warmist on May 18, 2020, 02:38:37 am
Is it possible to call map.rb's map_tile_at(x,y,z) from a lua script, or do I have to implement my own?
not sure what is map.rb's but there is  this module  (https://docs.dfhack.org/en/stable/docs/Lua%20API.html#maps-module) and tile is usually collection of type+flags+occupancy(+ some other stuff that is harder to explain). Most of the things can be done with
Code: [Select]
local ttype=dfhack.maps.getTileType(x,y,z)
local des,occ=dfhack.maps.getTileFlags(x,y,z)
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on May 18, 2020, 03:22:13 am
not sure what is map.rb's but there is  this module  (https://docs.dfhack.org/en/stable/docs/Lua%20API.html#maps-module) and tile is usually collection of type+flags+occupancy(+ some other stuff that is harder to explain). Most of the things can be done with
Code: [Select]
local ttype=dfhack.maps.getTileType(x,y,z)
local des,occ=dfhack.maps.getTileFlags(x,y,z)
https://github.com/DFHack/dfhack/blob/master/plugins/ruby/map.rb

It contains some convenient helper functions as part of a MapTile class (such as returning the relevant df.world.world_data.geo_biomes entry for the tile.) Also an iterator that iterates through every map block on the map.

I can try the maps module, it's just a bit of extra work.
Title: Re: DFHack 0.47.04-r1
Post by: bloop_bleep on May 18, 2020, 12:10:03 pm
Hello all, I'm coming from a discussion on another thread.

I'd like to mention that for building on Windows, I found it required to add C:\Strawberry\perl\vendor\lib\auto\XML\LibXML to PATH, in addition to the paths listed in the docs. The reason is that otherwise, the generate build script throws a rather cryptic error, whose root cause seems to be not being able to find the LibXML dll. Additionally, I've found that in the cmake line in generate-MSVC-all.bat, the -G and -T options needed to be set to

-G"Visual Studio 15 Win64" -T v141

whereas previously, as-downloaded, they were something like

-G"Visual Studio 14 Win64" -T v140_xp
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 18, 2020, 06:24:38 pm
Thanks for bringing it here! I'll make an issue for it. Would this be the appropriate path to add to the docs (https://docs.dfhack.org/en/latest/docs/Compile.html#perl-strawberry-perl), then?
Code: [Select]
<path to perl>\perl\vendor\lib\auto\XML\LibXML

As for the build scripts, I'm pretty sure your changes switch from the 2015 compiler to the 2017 one. We don't want to break things for users of the 2015 compiler, since we recommend it, but it would be worthwhile to document how to build with the 2017 compiler too. (I would rather not introduce separate versions of the scripts for 2015 and 2017, because we've already made one or two choices that have doubled the number of build scripts, and that's not really maintainable. If someone would like to come up with a cleaner way to make the Windows build scripts configurable, that would be great.)
Title: Re: DFHack 0.44.12-r2
Post by: Romeofalling on May 18, 2020, 08:26:21 pm
Oh, hey. I set up those By-Industry custom stockpiles and then never did anything with them. Almost overwrote them when I downloaded the latest versions.

A) Are you still interested in trying to find some way to distribute these custom stockpiles with dfhack, or do you think it would be simpler to submit these to the LNP and LMacP folks, since they already have folders for such things?

B) If yes, uh....where on Github? I've never submitted a pull request via Github before.

The LNP and LMP both come with a Gems stockpile setting group (Rough Ornamental. Rough Rare, Rough Semiprecious), a Magma Safe group (different Stone and Ore settings), and a MechGuides group.

So since I'm going to go through the trouble of making [Workshop]_Input stockpiles for everything, how do I submit those for inclusion into df-hack?

Submitting a pull request on GitHub is probably easiest for us. However, this case is a bit tricky because we currently don't distribute any stockpile profiles with DFHack, so there's not really a place in the repository to put them (but we can figure out how to address that and make sure they get bundled properly). They're also binary files, from what I remember, which tend not to play very well with Git - if they're large, we might just distribute them separately.

As a side thought, if it's possible to generate these profiles programmatically, it might be more maintainable to have the plugin generate them (although built-in workshops are hardcoded, and reactions for custom workshops can be pretty complicated... so your solution is probably easiest for now).
Title: Re: DFHack 0.44.12-r2
Post by: lethosor on May 18, 2020, 11:04:02 pm
Oh, hey. I set up those By-Industry custom stockpiles and then never did anything with them. Almost overwrote them when I downloaded the latest versions.

A) Are you still interested in trying to find some way to distribute these custom stockpiles with dfhack, or do you think it would be simpler to submit these to the LNP and LMacP folks, since they already have folders for such things?

B) If yes, uh....where on Github? I've never submitted a pull request via Github before.
We still don't really have a place for them. I'd post them in the LNP thread(s) for now, since they're better equipped to distribute that sort of thing (similar to embark profiles, etc).
Title: Re: DFHack 0.47.04-r1
Post by: Stargazer on May 19, 2020, 01:10:05 pm
Did anyone ever sort out the bug with the building planner? The one where your dwarves build your furniture directly out of bars of various materials? Mine are doing it right now with iron bars. I'll place the ghost furniture icon and a while later a dwarf with an inventory of iron bars comes up and builds it. I have on Masterful cabinets of any material selected to build with none in my stocks. It even does this when I specifically designate stone as a material.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 19, 2020, 04:20:57 pm
Did anyone ever sort out the bug with the building planner? The one where your dwarves build your furniture directly out of bars of various materials? Mine are doing it right now with iron bars. I'll place the ghost furniture icon and a while later a dwarf with an inventory of iron bars comes up and builds it. I have on Masterful cabinets of any material selected to build with none in my stocks. It even does this when I specifically designate stone as a material.
This is the first time I've ever heard of this issue, so as far as I'm concerned, it was never reported to us (at least through GitHub, here, or another official channel - have you seen reports of it elsewhere?). The plugin doesn't seem to have changed recently (https://github.com/DFHack/dfhack/commits/develop/plugins/buildingplan.cpp) either. I'll see if I can reproduce it on my end. Any idea if this is new to 0.47, or was it happening earlier?
Title: Re: DFHack 0.47.04-r1
Post by: Stargazer on May 19, 2020, 04:37:46 pm
Did anyone ever sort out the bug with the building planner? The one where your dwarves build your furniture directly out of bars of various materials? Mine are doing it right now with iron bars. I'll place the ghost furniture icon and a while later a dwarf with an inventory of iron bars comes up and builds it. I have on Masterful cabinets of any material selected to build with none in my stocks. It even does this when I specifically designate stone as a material.
This is the first time I've ever heard of this issue, so as far as I'm concerned, it was never reported to us (at least through GitHub, here, or another official channel - have you seen reports of it elsewhere?). The plugin doesn't seem to have changed recently (https://github.com/DFHack/dfhack/commits/develop/plugins/buildingplan.cpp) either. I'll see if I can reproduce it on my end. Any idea if this is new to 0.47, or was it happening earlier?

I was browsing and searching to see if I could find an answer for the issue and noticed a few other mentions of it back from 2017.

Right, sorry I should have said all the technical stuff :)

I'm using the LNP (PeridexisErrant's Starter Pack 0.43.05-r03) which has DF 43.05 along with DFHack 0.43.05-r1 (thread: http://www.bay12forums.com/smf/index.php?topic=126076.0)

To be clear, I have the min quality set to ordinary and filter set to *any.  I have say 4 beds prebuilt.  I place 1 bed down in planning mode and a dwarf hauls a bar of coke over.

I don't think this happens on a new game.  I feel like I did something at some point that triggered this behaviour because it reliably does this as soon as I load up the save (even if I already have the furniture constructed).  But when I load an earlier save, it doesn't happen and dwarfs will wait until I construct a bed even if there is coke bars available.

I tried forbidding all my coke bars from the stocks screen.  When they are forbidden, dwarfs properly use normal constructed beds.   After unforbidding, it seems this has fixed the behaviour...  Very strange!!!  I'll post again if anything interesting happens...

Hello, wasn't sure where to put this and I haven't see anyone talk about this, but can someone explain why doors, tables and I guess other furniture are built with coke when they are put down in planning mode?
By coke, I mean they haul bars of coke to the location and then create a door or table from scratch!  I can deconstruct it and I get bars of coke back...  I've never seen this behaviour before.

Planning mode was working normally a while ago where it would wait until I'd build the funiture item and then a dwarf would go haul the constructed item to the spot and install it.  But suddenly (and I'm not sure exactly when as 'coke bar' furniture looks like gabbro) any planned furniture immediately gets made out of coke bars...  and it's always coke bars.  Any ideas?

Except with me it's not coke bars. It's iron bars.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 19, 2020, 10:27:42 pm
Thanks for tracking it down! It sounds like it's an intermittent issue and an old one (both not great, but at least it's not a regression in 0.47). I've been trying to hunt down segfaults in recent DFHack development builds for a couple days now, but I will try to reproduce it when I get a chance.
Title: Re: DFHack 0.47.04-r1
Post by: HungThir on May 20, 2020, 04:26:23 am
oh, i think i've seen this before!

iirc, "iron bars" are the default object (first one listed in the raws?) that gets used if somehow no other object was provided.  (maybe, back in 2017, the first one was coke?)

i believe it's not that the script is "constructing the cabinet on the spot out of iron bars", but rather, something has gotten corrupted, and instead of collecting a cabinet object from the stockpile, the dwarf has "collected" some nonsense unitialised object that's being interpreted as iron bars

i haven't used plannng mode in a while, but i _think_ maybe you can reproduce this on demand by placing some furniture in planning mode, specifying objects you don't have yet (so that it creates a suspended job, which will be unsuspended by the script once the desired object exists), and then going into the jobs screen and unsuspending the job yourself -- some dwarf will execute the job, with whatever placeholder object it had been originally created with...

the simple answer might be "well, don't do that then".  but maybe there's a new bug that has surfaced and creates similar weirdness, when the player hasn't manually unsuspended an unready planning-mode job? idk

maybe Stargazer can chime in as to whether they recently unsuspended some jobs just before this happened
Title: Re: DFHack 0.47.04-r1
Post by: Stargazer on May 20, 2020, 08:40:26 am
oh, i think i've seen this before!

iirc, "iron bars" are the default object (first one listed in the raws?) that gets used if somehow no other object was provided.  (maybe, back in 2017, the first one was coke?)

i believe it's not that the script is "constructing the cabinet on the spot out of iron bars", but rather, something has gotten corrupted, and instead of collecting a cabinet object from the stockpile, the dwarf has "collected" some nonsense unitialised object that's being interpreted as iron bars

i haven't used plannng mode in a while, but i _think_ maybe you can reproduce this on demand by placing some furniture in planning mode, specifying objects you don't have yet (so that it creates a suspended job, which will be unsuspended by the script once the desired object exists), and then going into the jobs screen and unsuspending the job yourself -- some dwarf will execute the job, with whatever placeholder object it had been originally created with...

the simple answer might be "well, don't do that then".  but maybe there's a new bug that has surfaced and creates similar weirdness, when the player hasn't manually unsuspended an unready planning-mode job? idk

maybe Stargazer can chime in as to whether they recently unsuspended some jobs just before this happened

I don't think I did but I might have. I vaguely recall accidentally unsuspending one of the ghost furniture but I can't remember for sure.
Title: Re: DFHack 0.47.04-r1
Post by: Roses on May 21, 2020, 01:46:37 pm
Question about speed in lua, is there a notable difference between these two?

Code: [Select]
if Table.SubTable then
  for k,v in pairs(Table.SubTable) do
    ...
  end
end

vs

Code: [Select]
for k,v in pairs(Table.SubTable or {}) do
  ...
end
Title: Re: DFHack 0.47.04-r1
Post by: bloop_bleep on May 21, 2020, 02:01:01 pm
I wouldn't see why... I mean, if this isn't in some extremely hot loop, overhead from checking table size or setting up the iteration through an empty table is pretty insignificant.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 21, 2020, 04:17:36 pm
Exactly - I would be more concerned about optimizing the loop body, since that's presumably run more often.
Title: Re: DFHack 0.47.04-r1
Post by: vjek on May 22, 2020, 12:30:55 am
Regarding stonesense.. Is the expectation that it's currently supposed to be working, in -r1?  Or is that a future revision goal?
I've tried a default/brand-new install of both 0.47.04 + dfhack 0.47.04-r1, and attempting to launch stonesense crashes df and dfhack.
There's a few exceptions/errors thrown, but if they're all known, I won't bother pursuing it..

last lines of stonesense.log (with [VERBOSE_LOGGING:YES]):
Reading xml stonesense\items\greiger items\Grei_items.xml...
New image: stonesense\items\greiger items\Grei_items.png

last lines of stderr.log:
Reading xml stonesense\buildings\Shop.xml...
stonesense\buildings\Shop.xml: <building


possibly relevant errors in stderr.log:(?)
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: cHRM chunk does not match sRGB
(many of each)
Title: Re: DFHack 0.47.04-r1
Post by: Rumrusher on May 22, 2020, 07:14:22 am
wonder if it's possible to trigger an event in world gen to generate a new creature?

Since there are moments where a deity could make a new species and necromancers and demons can legit get bored enough to make a new species there should be something that tells the game to generate a new being from scratch.
Title: Re: DFHack 0.47.04-r1
Post by: Roses on May 22, 2020, 10:03:34 am
Exactly - I would be more concerned about optimizing the loop body, since that's presumably run more often.

More just wanted to make sure that the x = y or z syntax wasn't stupidly expensive (it's not in the other languages I code in, so I didn't have a good handle on it). That being said, I should have just run a little test case (which I just did) with a million calls there was no appreciably difference in run times (when the SubTable was present the second was slightly faster, when the SubTable was not present the first was slightly faster, but within a few percent of eachother each time I ran)
Title: Re: DFHack 0.47.04-r1
Post by: Rose on May 22, 2020, 10:32:22 am
Regarding stonesense.. Is the expectation that it's currently supposed to be working, in -r1?  Or is that a future revision goal?
I've tried a default/brand-new install of both 0.47.04 + dfhack 0.47.04-r1, and attempting to launch stonesense crashes df and dfhack.
There's a few exceptions/errors thrown, but if they're all known, I won't bother pursuing it..

last lines of stonesense.log (with [VERBOSE_LOGGING:YES]):
Reading xml stonesense\items\greiger items\Grei_items.xml...
New image: stonesense\items\greiger items\Grei_items.png

last lines of stderr.log:
Reading xml stonesense\buildings\Shop.xml...
stonesense\buildings\Shop.xml: <building


possibly relevant errors in stderr.log:(?)
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: cHRM chunk does not match sRGB
(many of each)

There's fixes made in stonesense that aren't in R1 currently.
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on May 22, 2020, 11:00:13 am
How do I get info about a tiletype in lua? The code below just gives me numbers:
Code: [Select]
tt = dfhack.maps.getTileBlock(x,y,z).tiletype[x%16][y%16]
tt_info = df.tiletype.attrs[tt]

print(tt)
print(tt_info.shape..','..tt_info.material..','..tt_info.special)
How do I use them as the enums that show up in "df-structures/df.tile-types.xml", etc.? There's matinfo (https://docs.dfhack.org/en/0.47.04-r1/docs/Lua%20API.html#material-info-lookup) for materials, but I'm not sure how to use that. (tile-material.lua (https://github.com/DFHack/dfhack/blob/master/library/lua/tile-material.lua) seems to have some additional stuff on materials.)

Also, what's the difference between "dfhack.maps.getTileBlock(x,y,z)" and "dfhack.maps.ensureTileBlock(x,y,z)"?
Title: Re: DFHack 0.47.04-r1
Post by: PatrikLundell on May 22, 2020, 11:44:52 am
@Bumber:

Code: [Select]
dfhack.println (df.tiletype [dfhack.maps.getTileBlock(x,y,z).tiletype[x%16][y%16]]) should print the tile type enum value. You're essentially going one step too far to try to get attributes for the enum value.

Matinfo is a pain in general, where you have to feed the mat_type and mat_index (with or without underscore depending on location in the structures) into the appropriate conversion operations (I always have to look them up in the DFHack Lua documentation) in the materials section). In the other direction you can feed strings in to get the corresponding tuple, but getting the strings right isn't trivial either (often I end up somehow getting hold of the tuple, e.g. from a stockpiled plant, and feed it into the operation that will give me the string (buried in a structure, I think), to then use the string for tuple generation in scripts (to protect against number shuffling due to changes to raws)).
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on May 22, 2020, 06:40:48 pm
Code: [Select]
dfhack.println (df.tiletype [dfhack.maps.getTileBlock(x,y,z).tiletype[x%16][y%16]]) should print the tile type enum value. You're essentially going one step too far to try to get attributes for the enum value.

Thanks. I actually need the attributes, which works using "df.tiletype_shape[tt_info.shape]", etc.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 22, 2020, 09:55:29 pm
Regarding stonesense.. Is the expectation that it's currently supposed to be working, in -r1?  Or is that a future revision goal?
I've tried a default/brand-new install of both 0.47.04 + dfhack 0.47.04-r1, and attempting to launch stonesense crashes df and dfhack.
For reference, here (https://github.com/DFHack/stonesense/issues/68) is the issue. It's been around for a while, but Stonesense is large, complicated, and has few active devs (so thank you Rose for the fix!) so I didn't think it was worth holding off 0.47.04-r1 indefinitely for a fix. In retrospect, I probably should have made that more clear in the release notes. Our release notes are semi-generated now and really just focus on changes since the last release(s), not release-specific notes, but this is something we could improve.

At the same time, there is a weird and nasty bug (https://github.com/DFHack/dfhack/issues/1576) on develop (well, hopefully just this one) that would definitely hold up an r2. Maybe we should start making smaller and more frequent "point" releases (like r1.1) with fixes like these, now that I think about it.

Exactly - I would be more concerned about optimizing the loop body, since that's presumably run more often.

More just wanted to make sure that the x = y or z syntax wasn't stupidly expensive (it's not in the other languages I code in, so I didn't have a good handle on it). That being said, I should have just run a little test case (which I just did) with a million calls there was no appreciably difference in run times (when the SubTable was present the second was slightly faster, when the SubTable was not present the first was slightly faster, but within a few percent of eachother each time I ran)
Lua does short-circuit and/or, for what it's worth, so it's about as inexpensive as it can get:
Code: [Select]
> 5 or f()
5
> nil or f()
stdin:1: attempt to call a nil value (global 'f')
stack traceback:
stdin:1: in main chunk
[C]: in ?

Also, what's the difference between "dfhack.maps.getTileBlock(x,y,z)" and "dfhack.maps.ensureTileBlock(x,y,z)"?
From docs:
Quote from: https://docs.dfhack.org/en/stable/docs/Lua%20API.html#maps-module
dfhack.maps.ensureTileBlock(coords), or ensureTileBlock(x,y,z)

Like getTileBlock, but if the block is not allocated, try creating it.
I'd have to dig into the source here to give you a better answer: https://github.com/DFHack/dfhack/blob/f20446534bb7f39425e102bd70daec46e328004f/library/modules/Maps.cpp#L181-L223

Regarding enums, if you can navigate in gui/gm-editor to the structure containing the fields you're interested in, editing it will give you a popup containing a list of enum items as well as the enum type name.
Title: Re: DFHack 0.47.04-r1
Post by: PatrikLundell on May 23, 2020, 02:38:21 am
I don't really see the point of point releases skipping parts of the development in normal cases (when not held up by weird bugs), as the normal case ought to be to release the current state of DFHack and DF structures. If there's extensive testing involved in releasing a new DFHack version that can largely be bypassed by a targeted point release of something deemed to be important there's a case for it, though.
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on May 23, 2020, 02:50:40 am
Regarding enums, if you can navigate in gui/gm-editor to the structure containing the fields you're interested in, editing it will give you a popup containing a list of enum items as well as the enum type name.
Can I do that with tiles? All I get is "No valid target found". I've just been using "printall" in lua to examine the fields, then doing another printall if there's another structure.

Now I've just got to figure out how to get the base material of a tile so I can determine if a construction is built in air. It shows up in probe.cpp as "mc.baseTiletypeAt(cursor)", where "mc" is a MapCache object. The "original_tile" field of a "df.global.world.constructions" entry just gives a soil layer, even in air. Edit: Never mind, it's working now. Not sure what I was doing wrong.
Title: Re: DFHack 0.47.04-r1
Post by: ragundo on May 23, 2020, 10:56:37 am
Regarding enums, if you can navigate in gui/gm-editor to the structure containing the fields you're interested in, editing it will give you a popup containing a list of enum items as well as the enum type name.
Can I do that with tiles? All I get is "No valid target found". I've just been using "printall" in lua to examine the fields, then doing another printall if there's another structure.

Now I've just got to figure out how to get the base material of a tile so I can determine if a construction is built in air. It shows up in probe.cpp as "mc.baseTiletypeAt(cursor)", where "mc" is a MapCache object. The "original_tile" field of a "df.global.world.constructions" entry just gives a soil layer, even in air.


You can also use df::global::world.map.map_blocks vector and interate over each entry looking for the desired [x,y,z] coordinate in the map_pos field and getting the tiletypes values in the tiletype array


(https://i.imgur.com/3KckXrm.png)
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 23, 2020, 11:42:30 am
Regarding enums, if you can navigate in gui/gm-editor to the structure containing the fields you're interested in, editing it will give you a popup containing a list of enum items as well as the enum type name.
Can I do that with tiles? All I get is "No valid target found". I've just been using "printall" in lua to examine the fields, then doing another printall if there's another structure.
You would have to pass in the expression you're looking at as an argument to gui/gm-editor ("gui/gm-editor world.something.tile"). It doesn't support selecting tiles in the GUI because there's no single "tile object" that it could display (some tile attributes are located in different structures).
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on May 23, 2020, 05:45:02 pm
Thanks, everyone, for the help! Hopefully you'll be seeing the end result soon-ish.

@ragundo
Forgot about your tool. Dwarf Explorer would be a good way to do it in the future.
Title: Re: DFHack 0.47.04-r1
Post by: doloresjane on May 26, 2020, 05:08:08 pm
Hello, I am writing this in hopes that someone can get back to me, I have been exporting xml files and it says "unknown df.identity_type value encountered:-1. please report to DFhack team"
Not sure what the error is and I also had another a thing id like to ask, in the future could you include how to Report errors to you because when you read the readme it says we can help out by reporting errors but give no way to do so, i mean i figured it out but some other people might not be able to. just a thought, have a great day
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on May 26, 2020, 08:08:37 pm
For reference, I replied in the GitHub thread (https://github.com/DFHack/dfhack/issues/1578#issuecomment-634355415). I'm curious about what readme you were looking at - the first post of this thread links to the GitHub issue tracker, but it's definitely possible that things are missing from our docs.
Please report bugs in the GitHub issue tracker (http://github.com/DFHack/dfhack/issues).
Title: Re: DFHack 0.47.04-r1
Post by: Rumrusher on May 30, 2020, 01:45:47 am
well I think df.global.ui_advmode.unk_3124 has access to the adv build menu
and unk_2 and unk_4 has something to do with being able to with the red tile boundary box.
(http://www.truimagz.com/host/rumrusher/folder8/well-then-progress3-uhh-oh-big-camp.png)

so after testing this and finding away to leave the site I notice I made a really really large camp doing this.

edit: unk_1 to unk 4 in unk_3124 controls the build menu zone that lets you designate and build. 1 and 3 are min and 2 and 4 are the max

this means when making a camp it takes this as measurement for the size of the camp which might help improve my campboat scripts.
Title: Re: DFHack 0.47.04-r1
Post by: PatrikLundell on May 30, 2020, 03:10:55 am
@Rumrusher: That kind of research is probably better noted as an issue on Github (https://github.com/DFHack/df-structures/issues (https://github.com/DFHack/df-structures/issues)), as it's likely to get buried over time in this thread (although a mention here as well is useful if you think it's of general interest too).
Title: Re: DFHack 0.47.04-r1
Post by: Rumrusher on May 30, 2020, 09:20:51 am
@Rumrusher: That kind of research is probably better noted as an issue on Github (https://github.com/DFHack/df-structures/issues (https://github.com/DFHack/df-structures/issues)), as it's likely to get buried over time in this thread (although a mention here as well is useful if you think it's of general interest too).
figure once I map out most of the stuff I'll send in a issue report on my findings.
edit: well learn 143 is the tile size of an adv camp... which with combined with my boatcamp mod means I could probably make a camp inside towns and sites.

which after doing that I learn it legit copies what ever chunk was designated as a camp so it's possible for me to say make a smaller camp under a group of people to copy and move them around the world. this knowledge feels like I'm taking a magic photo and placing it down in other places.
Title: Re: DFHack 0.47.04-r1
Post by: Rekov on May 31, 2020, 07:04:37 pm
Following from some discussion Discord: Does DFHack include any script that deals with the handedness problem with gloves/gauntlets created by custom reactions?

I've found the odd mentions of script on the forum here (http://www.bay12forums.com/smf/index.php?topic=164123.msg7459370#msg7459370) and there (http://www.bay12forums.com/smf/index.php?topic=127141.msg4443856#msg4443856). I couldn't get Meph's script to work, which doesn't surprise me given how old it is it. But maybe I was doing something wrong with it.

Is there anything included by default that handles this?
Title: Re: DFHack 0.47.04-r1
Post by: Quietust on June 02, 2020, 10:23:21 am
There will be soon - I've just written a new Tweak to make custom reactions produce gloves in sets based on the maker's body plan (e.g. a Dwarf will produce 1 left glove and 1 right glove, while an Antman will produce 2 left gloves and 2 right gloves).

The PR is here (https://github.com/DFHack/dfhack/pull/1585) in case you want to try it out - I've only tested it in Arena mode using the "createitem" plugin (which already contains a similar fix but is coded to disable said fix if it detects that DF is already doing the right thing), but it should work in Fortress and Adventurer mode too.
Title: Re: DFHack 0.47.04-r1
Post by: Rekov on June 02, 2020, 11:34:58 am
Very cool.

Just to check I understand you though, I would want to modify my reaction to produce a single glove/gauntlet/etc instead of two, because your script handles the duplication?
Title: Re: DFHack 0.47.04-r1
Post by: Quietust on June 02, 2020, 04:44:48 pm
Very cool.

Just to check I understand you though, I would want to modify my reaction to produce a single glove/gauntlet/etc instead of two, because your script handles the duplication?
It won't be a script, but a compiled plugin that overrides DF's internal behavior when performing any custom reactions.

The way I've coded it, it will treat both count=1 and count=2 as "produce one set" while treating count>2 as "produce [count] sets", so it won't matter whether your reaction produces 1 glove or 2 gloves.
Title: Re: DFHack 0.47.04-r1
Post by: xzaxza on June 04, 2020, 05:32:24 am
Why doesn't dfhack.TranslateName() capitalize non-ascii letters? For example, it outputs äs Nêcikled, instead of Äs Nêcikled?
Title: Re: DFHack 0.47.04-r1
Post by: PatrikLundell on June 04, 2020, 07:18:43 am
Why doesn't dfhack.TranslateName() capitalize non-ascii letters? For example, it outputs äs Nêcikled, instead of Äs Nêcikled?
The general, simple answer is that to do that the code will have to know which character codes are letters and which are not, as well as what the opposite case character code of each letter code is. For the ASCII subset there are simple rules for both, but I'd expect CP437 (if the number is correct) letters to be all over the place, which would require someone to write a translation table for codes that are deemed to be letters.
It can also be noted that character coding will change with the Premium release (I've seen no indication of how, only that the 8 bit restriction is intended to be replaced), but a changed implementation would still probably be valid for half a year.

Edit: Also, I'm not sure there's a consensus about what upper case versions of lower case letters is between languages. I believe English has a tendency to drop a trema over an 'ï' for instance resulting in 'I' rather than 'Ï'.
Title: Re: DFHack 0.47.04-r1
Post by: xzaxza on June 04, 2020, 08:49:47 am
Why doesn't dfhack.TranslateName() capitalize non-ascii letters? For example, it outputs äs Nêcikled, instead of Äs Nêcikled?
The general, simple answer is that to do that the code will have to know which character codes are letters and which are not, as well as what the opposite case character code of each letter code is. For the ASCII subset there are simple rules for both, but I'd expect CP437 (if the number is correct) letters to be all over the place, which would require someone to write a translation table for codes that are deemed to be letters.
It can also be noted that character coding will change with the Premium release (I've seen no indication of how, only that the 8 bit restriction is intended to be replaced), but a changed implementation would still probably be valid for half a year.
Half a year, sounds optimistic. :D

Edit: Also, I'm not sure there's a consensus about what upper case versions of lower case letters is between languages. I believe English has a tendency to drop a trema over an 'ï' for instance resulting in 'I' rather than 'Ï'.
Well, at least in this case the game itself shows the first letter of that name as a capital one.

Oh and I noticed that CP437 actually doesn't even contain upper case versions of all of the accented letters, which sort of is an extra problem. It could still be done in df2utf() or df2console() maybe.
Title: Re: DFHack 0.47.04-r1
Post by: Worgensnack on June 05, 2020, 07:08:19 pm
for some reason I can't get dwarfvet to work. I turn it on, set a zone to be a hospital and animal training area, but the animals just send a steam of inaccessible messages but I've seen them in the room. am I doing something wrong or is it something with the plugin?
Title: Re: DFHack 0.47.04-r1
Post by: Rusty_knight on June 12, 2020, 09:29:49 am
Is there any scripts or other ways to edit biome/region parameters of an already running fortress?
I've finally found a decent site after a week of world-genning, but it rains EVERY SINGLE DAY there.
Title: Re: DFHack 0.47.04-r1
Post by: PatrikLundell on June 12, 2020, 11:37:08 am
Is there any scripts or other ways to edit biome/region parameters of an already running fortress?
I've finally found a decent site after a week of world-genning, but it rains EVERY SINGLE DAY there.
You can change it, but whether it will take effect I don't know. The Biome Manipulator http://www.bay12forums.com/smf/index.php?topic=164658.msg7495705#msg7495705 (http://www.bay12forums.com/smf/index.php?topic=164658.msg7495705#msg7495705) allows you to change things on a world tile level, but it's really intended to be used before embark, and I haven't tried it after.

You can, however, regenerate the same world from its seeds, manipulate it, and then embark in a fresh copy (assuming you didn't make a backup of the world before embarking).
Title: Re: DFHack 0.47.04-r1
Post by: Fleeting Frames on June 12, 2020, 02:21:06 pm
At least temperature takes effect, but for this you can simply disable weather in init.
Title: Re: DFHack 0.47.04-r1
Post by: xzaxza on June 13, 2020, 03:17:38 pm
Does anyone know where and how economical linking is stored? Or is it stored even? I tried looking around in df.global.world.entities with gui/gm-editor, but the only entity_link I found was to the parent civilization. And site_links doesn't seem to be that either, there's just a site that has the residence flag. Also, looks like the parent civ has an entity_link to each child, and a site_link to each child with the land_for_holding tag. Maybe that's enough, in combination with the later site having no baron and having a founding event, or something?

Although, there seems to be a site id, so there is data for the sites themselves, containing this data? I haven't found those, at least yet.
Title: Re: DFHack 0.47.04-r1
Post by: PatrikLundell on June 14, 2020, 03:17:08 am
It's in your site's entity_links. There's a link to the government of the site (i.e. the entity, not the site), and flags.local_market is set. Land for holding links have to go from an entity to a site, and I believe those are between the civ and the site, not the site government and a site (with a possible exception for necro towers). In my case I have an economic link to a gobbo conquered (formerly human) site, but no land for holding claim on it from the (dead) civ. The civ has claims only on the (lost) capital and my fortress.
I believe it's a bug that nobility for land holding sites other than your own nevertheless demand to be given noble quarters at your site. You really should have to satisfy your own nobles only (if nobility over other sites are keen on noble treatment they should go to their sites to demand it...).
Title: Re: DFHack 0.47.04-r1
Post by: xzaxza on June 14, 2020, 05:54:41 am
It's in your site's entity_links. There's a link to the government of the site (i.e. the entity, not the site), and flags.local_market is set. Land for holding links have to go from an entity to a site, and I believe those are between the civ and the site, not the site government and a site (with a possible exception for necro towers). In my case I have an economic link to a gobbo conquered (formerly human) site, but no land for holding claim on it from the (dead) civ. The civ has claims only on the (lost) capital and my fortress.
I believe it's a bug that nobility for land holding sites other than your own nevertheless demand to be given noble quarters at your site. You really should have to satisfy your own nobles only (if nobility over other sites are keen on noble treatment they should go to their sites to demand it...).
Thanks! I had trouble finding the site data apart from df.global.world.world_data.active_site[0], but df.world_site.find() helped with that. I also noticed that there's a site_link that matches my site's id in the entity of the linked economy, and removing that seems to get rid of the message on the civilizations view, but I'll also remove the entity_link from my site to be safer.

I'll also make that into a script, just need to figure out how to delete things safely.
Title: Re: DFHack 0.47.04-r1
Post by: xzaxza on June 14, 2020, 10:33:36 am
Here's the script, in case anyone's interested. Doesn't seem to crash the game for me at least.

Code: [Select]
-- show and sever economic links, by xzaxza
local help = [====[
economiclinks
======================
Displays the economic links of a site, or optionally severs them.

Usage:
economiclinks [sever] [site_id]

Both options are optional. If absent, site_id defaults to the current site.

Examples:
Running `economiclinks` without arguments displays the economic links of the current site.
Running `economiclinks 7` displays the economic links of the site with id 7.
Running `economiclinks sever` severs the economic links of the current site.
Running `economiclinks sever 7` severs the economic links of the site with id 7.
]====]
function fullname(item) --lifted from modtools/extra-gamelog
    return dfhack.TranslateName(item.name)..' ('..dfhack.TranslateName(item.name ,true)..')'
end
function CountLinks(site_id)
    if df.world_site.find(site_id) == nil then
        print "Error: site not found."
        return nil
    end
    local site = df.world_site.find(site_id)
    local local_markets = {}

    for k,v in pairs(site.entity_links) do
        if v.flags.local_market then
            local_markets[#local_markets+1] = v.entity_id
        end
    end
    return #local_markets
end
function ShowLinks(site_id)
    if df.world_site.find(site_id) == nil then
        print "Error: site not found."
        return
    end
    local site = df.world_site.find(site_id)
    local local_markets = {}
    print(dfhack.df2console('Site '..site_id..': '..fullname(site)..' at coordinates ('..site.pos.x..','..site.pos.y..')'))

    for k,v in pairs(site.entity_links) do
        if v.flags.local_market then
            local_markets[#local_markets+1] = v.entity_id
        end
    end
    if #local_markets > 0 then
        print(dfhack.df2console('The site has the following economic links:'))
        for k,v in pairs(local_markets) do
            tmp_ent = df.historical_entity.find(v)
            if tmp_ent ~= nil then
                print(dfhack.df2console('  Entity '..v..', '..fullname(tmp_ent)))
            else
                print('  Entity '..v..', <unknown entity>')
            end
        end
    else
        print(dfhack.df2console('The site has no economic links.'))
    end
end
function SeverLinks(site_id)
    if df.world_site.find(site_id) == nil then
        print "Error: site not found."
        return
    end

    local site = df.world_site.find(site_id)
    local tmp_ent
    local tmp_ent_id

    for k,v in pairs(site.entity_links) do
        tmp_size1 = #site.entity_links
        if v.flags.local_market then
            tmp_ent_id = v.entity_id
            tmp_ent = df.historical_entity.find(tmp_ent_id)

            for k2,v2 in pairs(tmp_ent.site_links) do
                if v2.target == site_id and v2.flags.local_market then
                    tmp_ent.site_links:erase(k2)
                    break
                end
            end
            site.entity_links:erase(k)
            return
        end
    end
end
-- main script
local opt = ...
local args = {...}
local site_id = df.global.ui.site_id
local link_count

if opt and opt ~= "" then
    if opt=="sever" then
        if tonumber(args[2]) then
            site_id = math.floor(tonumber(args[2]))
        end
        link_count = CountLinks(site_id)
        for i = 1,link_count,1 do
            SeverLinks(site_id)
        end
        return
    elseif tonumber(opt) then
        site_id = math.floor(tonumber(opt))
        ShowLinks(site_id)
        return
    else
        print(help)
    end
else
    ShowLinks(site_id)
end
Title: Re: DFHack 0.47.04-r1
Post by: Tokeli on June 22, 2020, 03:41:21 pm
I've been poking around trying to learn DFHack for some tile-designation manipulation, and since there's no documentation on the why-

Is there documentation of, or does anyone know the purpose of the crazy coordinate system used for map tiles? At first I figured "block.map_pos" was the proper coordinates but they increment oddly instead of reflecting the real coords.

Digging through other scripts reveals a crazy 2D array in some of the fields such "block.designation", which I can't figure out the purpose or function of. I've managed to get something working by copying what other people have done, but I'd sure love to know what this structure's for.


(https://cdn.discordapp.com/attachments/173908541088858113/724716402014945431/unknown.png)
Title: Re: DFHack 0.47.04-r1
Post by: ragundo on June 22, 2020, 05:15:38 pm
I've been poking around trying to learn DFHack for some tile-designation manipulation, and since there's no documentation on the why-

Is there documentation of, or does anyone know the purpose of the crazy coordinate system used for map tiles? At first I figured "block.map_pos" was the proper coordinates but they increment oddly instead of reflecting the real coords.

Digging through other scripts reveals a crazy 2D array in some of the fields such "block.designation", which I can't figure out the purpose or function of. I've managed to get something working by copying what other people have done, but I'd sure love to know what this structure's for.


(https://cdn.discordapp.com/attachments/173908541088858113/724716402014945431/unknown.png)

The tiles are stored in the df.global.world.map structure.
Inside this structure the datais stored in different ways. There's a 3 dimmensional array (x)(y)(z) of map_blocks called block_index and, also, a vector of pointers to map_blocks called map_blocks.

You can access a map_block of coordinates (x)(y)(z) directly using block_index or iterate over the map_blocks_vector to reach the desired coordinate, or better, use DFHack.

Each map_block stores a 16x16 array of tyletypes, that is the data you are looking for.

It's better to explain it with a image

(https://i.imgur.com/lAUGhTg.png)
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on June 22, 2020, 06:24:44 pm
(https://cdn.discordapp.com/attachments/173908541088858113/724716402014945431/unknown.png)
Map blocks are 16x16x1 tiles. Looks to me like getTileBlock returns the block that a tile is in, and the map_pos field is the coordinates of one corner of that block. Some attributes are stored in 16x16 arrays in each block and some are stored at the block level. It is a little complicated.

As for your question about designations, they're mostly stored in the "designation" field of each block, which is a 16x16 array of tile_designation, each of which have a "dig" field of type tile_dig_designation. I can try to track down an example if that would help - I suspect the "dig" plugin works with these, but I'm not sure about Lua scripts.
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on June 22, 2020, 07:06:42 pm
map_pos field is the coordinates of one corner of that block.

This is handy info for something I'm currenty working on. I was using an ugly "math.modf(cursor_x/16)*16" instead.
Title: Re: DFHack 0.47.04-r1
Post by: Archereon on June 23, 2020, 06:58:25 pm
Hey, I was screwing around, and it seems like the "names" script, which lets you use the native interface to rename units, is broken unless I'm using it wrong, it seems to be throwing an error.




https://imgur.com/Im6t0M9
Title: Re: DFHack 0.47.04-r1
Post by: Tokeli on June 23, 2020, 07:06:23 pm
Heck, thank you both lethosor and ragundo. Knowing it's a 16x16 chunk format more or less ala Minecraft has it make a helluva lot more sense now. The way it's all organized made it confusing. And having the chunks be named "blocks".
Title: Re: DFHack 0.47.04-r1
Post by: Quietust on June 24, 2020, 08:40:33 am
The way it's all organized made it confusing. And having the chunks be named "blocks".
We don't know what they're actually called, because the actual structure name isn't exposed anywhere within the executable - we know the names of all of the C++ classes that have virtual methods (e.g. "building_civzonest", "feature_init_deep_special_tubest", "world_construction_wallst") thanks to RTTI (https://en.wikipedia.org/wiki/Run-time_type_information), but for everything else we have to guess what it's called based on how it's used.

In the case of map_block, it might actually be called something like "block_squarest" (based on the various "block_square_eventst" subclasses used to keep track of stuff like minerals, spatters, grass, and designation priorities), but unless Toady outright tells us the class's name (or adds a virtual method to it), we'll never know.

But given that Dwarf Fortress predates Minecraft by over 3 years (and has used the "map_block" structure at least since late 2006), you probably shouldn't expect them to be called "chunks".
Title: Re: DFHack 0.47.04-r1
Post by: Atomic Chicken on June 24, 2020, 03:30:43 pm
Here’s an overview of the way the DF map is organised, as copied from my notes. Note that these names aren't official and others might refer to them differently, but I believe I had based them on various references in the structures at the time. ("region tile" might be particularly confusing as it isn't directly related to actual regions).

At the lowest level we have local tiles; 1 local tile is the space the cursor takes up during regular fortress/adventure mode play. Coordinates of units, items, projectiles, etc are written in the local tile scale, where (x = 0, y = 0, z = 0) is the tile at the upper left corner of the lowest z-level on the currently loaded map.

Local tiles on each z-level are grouped into blocks, where
1 block = 16*16*1 local tiles
Blocks are visible during zoomed-in fast travel in adventure mode. Army coordinates use this scale.

Columns of blocks are grouped into region tiles as such:
1 region tile
  = 3*3 block columns
  = 48*48 local tile columns
Region tiles are visible when resizing your fort before embarking, or during zoomed-out fast travel in adventure mode.

Finally comes the world tile:
1 world tile
  = 16*16 region tiles
  = 48*48 block columns
  = 768*768 local tile columns
These are the largest map tiles, visible on the world map before embarking, when checking the dwarf mode civilization screen map and when checking the adventure mode quest log.
Title: Re: DFHack 0.47.04-r1
Post by: PatrikLundell on June 24, 2020, 05:08:56 pm
I believe Toady referred to "region tiles" as "Mid Level Tiles" (MLT) when asked about scales used at some point (also note that the "Region Map" displayed pre embark is the middle one, not the left one, to add to the confusion).

There's also one level above world tiles, namely the "feature shell", which consists of 16 * 16 world tiles. These are strange creatures that take quite some time to load/generate, and after that they're still only populated as needed for some info (and trying to read a feature shell other than the current one typically results in an access violation crash). The main known data in feature shells are "features", i.e. things like volcanoes, magma pipes, candy spires, as well as caverns and the other underground levels, but only on a fairly high level.

There's also a 2 * 2 MLT scale used for candy spire locations.

Edit: Something completely different:
I've run into the problem of trying to compare a Z coordinate in the local (embark) coordinate system with an elevation Z coordinate that's used in a different structure (plant vs picked plant growths, for those curious). However, I don't know of any straight forward way to translate between the coordinate systems. Could someone provide me with the missing relation?

Edit 2: In case someone else looks for the answer to the question in Edit: df.global.world.map.map_block_column [<appropriate 16 * 16 block>].z_base contains the value to be removed from the elevation value to get the local z coordinate).
Title: Re: DFHack 0.47.04-r1
Post by: Iä! RIAKTOR! on June 26, 2020, 11:39:38 pm
How extract raws of generated noble position from saved world?
Title: Re: DFHack 0.47.04-r1
Post by: Tokeli on June 30, 2020, 01:16:53 am
I'm still unsure if this is the best place to be asking questions, but-

I've been trying to make a plugin for the embark screen and have been pretty successful, but, is there a way to access the names of the dwarves in the Prepare Carefully screen?

Checking the fields in in
Code: [Select]
dfhack.gui.getCurViewscreen().dwarf_info[0].name.has_name is false, and all the other name fields are also empty, revealing that the dwarves have no name at all. But they're there on the screen! Does anyone know where these specific names are stored before they're applied to the dwarves? I've dug through the structure files for the setupdwarfgame screen but can't find anything that leads to the mysterious intermediate names, if they're accessible at all.
Title: Re: DFHack 0.47.04-r1
Post by: PatrikLundell on June 30, 2020, 02:01:48 am
df.global.world.units.all is populated by 7 creatures at that point, and the first one had a name of "kogsak" when I checked. Thus, I'm fairly sure that's where you've got your dorfs. When you enter the embark carefully screen the dorfs have been generated, with names and all.
(Dwarf Therapist can display the dorfs as well, at that point).
Title: Re: DFHack 0.47.04-r1
Post by: Clément on June 30, 2020, 03:54:15 am
df.global.world.units.all is populated by 7 creatures at that point, and the first one had a name of "kogsak" when I checked. Thus, I'm fairly sure that's where you've got your dorfs. When you enter the embark carefully screen the dorfs have been generated, with names and all.
(Dwarf Therapist can display the dorfs as well, at that point).

Actually df.global.world.units.all has more than 7 creatures. I had to change Dwarf Therapist to use the view screen instead since the more units in the world were activated. But I use viewscreen_setupdwarfgamest.units instead viewscreen_setupdwarfgamest.dwarf_info.
Title: Re: DFHack 0.47.04-r1
Post by: Tokeli on June 30, 2020, 05:04:57 am
df.global.world.units.all is populated by 7 creatures at that point, and the first one had a name of "kogsak" when I checked. Thus, I'm fairly sure that's where you've got your dorfs. When you enter the embark carefully screen the dorfs have been generated, with names and all.
(Dwarf Therapist can display the dorfs as well, at that point).

Actually df.global.world.units.all has more than 7 creatures. I had to change Dwarf Therapist to use the view screen instead since the more units in the world were activated. But I use viewscreen_setupdwarfgamest.units instead viewscreen_setupdwarfgamest.dwarf_info.

HECK, I can't believe I didn't just check through the viewscreen's fields instead, the names and everything else are perfectly accessible under the units section, thank you!

Edit: Well their first name is there at least, but that's good enough!
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on June 30, 2020, 12:38:34 pm
Edit: Well their first name is there at least, but that's good enough!
If you want a human-readable version of a language_name object, you'll want dfhack.TranslateName(some_unit.name) (in Lua, anyway). Also worth mentioning: TranslateName returns a CP437-encoded string, so if you're printing these names somewhere, you should use df2utf or df2console as appropriate: https://docs.dfhack.org/en/stable/docs/Lua%20API.html#c-function-wrappers
Title: Re: DFHack 0.47.04-r1
Post by: Salperticon on June 30, 2020, 03:33:09 pm
While looking at the world map, I am currently trying to get an overview of the creatures available at the embark, so I can chose a location that has a certain species for my fort.
In the past, I think I used the "region-pops" command in DFHack for this. However, "region-pops list" now gives me only:

Quote
Plants:

Creatures and vermin:

There is nothing shown. What am I doing wrong? Can I only use this after embark?
Title: Re: DFHack 0.47.04-r1
Post by: PatrikLundell on June 30, 2020, 04:16:32 pm
While looking at the world map, I am currently trying to get an overview of the creatures available at the embark, so I can chose a location that has a certain species for my fort.
In the past, I think I used the "region-pops" command in DFHack for this. However, "region-pops list" now gives me only:

Quote
Plants:

Creatures and vermin:

There is nothing shown. What am I doing wrong? Can I only use this after embark?
I wouldn't be surprised if the structure region-pops uses isn't populated until you embark as DF has no use for it until then. You can use the Biome Manipulator http://www.bay12forums.com/smf/index.php?topic=164658.msg7495705#msg7495705 (http://www.bay12forums.com/smf/index.php?topic=164658.msg7495705#msg7495705), although it's a bit more cumbersome, as you have to manually identify all regions your planned embark has, and then locate a "parent" world tile for each of those regions (basically embark world tile some of the 8 surrounding ones). On the other hand you can add desired creatures with it.
Title: Re: DFHack 0.47.04-r1
Post by: Rumrusher on July 04, 2020, 07:24:36 pm
Well went and ponder what happens if dfhack did mess with the farmer workshop and discovered yeah you can mess with the general ref of the Milkee's unit id for that job, which lets you drag anyone over to the farmer workshop.

the kicker to this is uhh if they aren't fit via the raws to produce stuff they will produce nothing even though they got dragged over there. but there's something else to this you can re-target the same cattle again and constantly get resources from them.
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on July 04, 2020, 11:33:31 pm
@Rumrusher
But will you fulfill the late DerMeister's dreams of a plugin for milkable ogresses (http://www.bay12forums.com/smf/index.php?topic=174898.0)?
Title: Re: DFHack 0.47.04-r1
Post by: Rumrusher on July 05, 2020, 05:18:25 am
@Rumrusher
But will you fulfill the late DerMeister's dreams of a plugin for milkable ogresses (http://www.bay12forums.com/smf/index.php?topic=174898.0)?
i just got done with repeatedly milking a sheep, and realizing no you can't just toggle the milkable enemy caste flag on folks
like I Was thinking 'oh hey can I use this one job reaction to say harvest bone from someone or blood. does it have to be milk?'  and so far it seems like 'yeah it totally does there nothing in the unit data that controls what body part is milk or not' and I think it's tied to the raws which also ....
fake edit : I just look in the extract section in the creature caste and notice that's where the milkable material section is. I'm tired but combination of messing with the milker's jobs to target who ever you wanted to be milked, with the combination of either Making a mod where you set up the milkee or dfhacking the milkee's caste extract to a material so the game will produce something and or making a milk material for the milkee

so far having got a farmer market to milk blood from a god sheep I'm pretty much done on this as I do not want to pursuit this mess any further at best I can direct you to the gm-editor command lines I used to mess with this .
Code: [Select]
gui/gm-editor df.global.world.nemesis.all[milker nemesis id here].unit.job.current_job.general_refs
- this here is where you can edit the job of the unit hopefully you wrote a script that inserts a milking job for them so that they go do this but if you haven't you probably need to insert "general_ref_unit_milkeest" in the job's general ref section after the general ref of the building and worker. other wise you just edit the job's milkee unit id before the worker grabs the default milkee-

gui/gm-editor df.global.world.raws.creatures.all[insert milkees creature id here].caste[the caste id of the milkee here].extracts

-and here is where you need to fill out which material do you want to have this creature extracting if you already have a creature with raw mods set for this you can skip this step for others uhh you need to edit the materials of the creature's raws to have a liquid that you can produce... or this just grabs any raws and makes it work regardless either way this is needed to produce stuff or else the stuff above will be getting nothing-

(http://www.truimagz.com/host/rumrusher/folder8/blood-from-the-Sheep-god-Buckets-for-the-bucket-throne.gif)

and like given messing with creature raws resets the changes after saving and or exiting the save this idea just seems like you need to run the script every time you want to do this or some complex auto fort mode triggers tied to an custom modded in workshop reaction that edits the milking job or something.

man do hope the next dfhack project I do at least involves adventure mode and or is fun.
Title: Re: DFHack 0.47.04-r1
Post by: PatrikLundell on July 05, 2020, 05:29:48 am
The Armok dream of producing barrels of blood can finally be made true...

Interesting results from a theoretical point of view. Gremlin tears, dwarf sweat, barrels of venom, ...
Now you just have to figure out how to extract the really interesting substances produced by FBs (and some of the new experiments).
What about scraping contaminants from dwarf boot soles?
Title: Re: DFHack 0.47.04-r1
Post by: Roses on July 05, 2020, 02:12:46 pm
You certainly could fairly easily combine a few things and create a script that allows you to extract blood, tears, pus, etc... You could even have it set up like the gui/create-item script where you select an extractor, an extractee, and the material to extract. You could also turn it into a more automated thing by creating reactions for extracting blood and such, and then tie the script into those reactions so that they functions similarly to how the milking reaction goes.
Title: Re: DFHack 0.47.04-r1
Post by: Iä! RIAKTOR! on July 06, 2020, 04:54:04 am
You certainly could fairly easily combine a few things and create a script that allows you to extract blood, tears, pus, etc... You could even have it set up like the gui/create-item script where you select an extractor, an extractee, and the material to extract. You could also turn it into a more automated thing by creating reactions for extracting blood and such, and then tie the script into those reactions so that they functions similarly to how the milking reaction goes.
How make script and reactions for this script?
Title: Re: DFHack 0.47.04-r1
Post by: Roses on July 06, 2020, 11:48:59 am
You certainly could fairly easily combine a few things and create a script that allows you to extract blood, tears, pus, etc... You could even have it set up like the gui/create-item script where you select an extractor, an extractee, and the material to extract. You could also turn it into a more automated thing by creating reactions for extracting blood and such, and then tie the script into those reactions so that they functions similarly to how the milking reaction goes.
How make script and reactions for this script?

You would need to combine the work that Rumrusher did with a heavily modified create-item script. You could also use the reaction-trigger hooks to set up a script, that would probably be more work, but also more configurable.

If you were asking if someone would make the script for you, probably not, as it is probably not of a lot of interest to most of the people that routinely write scripts. But it would be a great exercise for you to learn how to write scripts.
Title: Re: DFHack 0.47.04-r1
Post by: Rumrusher on July 06, 2020, 08:36:18 pm
You certainly could fairly easily combine a few things and create a script that allows you to extract blood, tears, pus, etc... You could even have it set up like the gui/create-item script where you select an extractor, an extractee, and the material to extract. You could also turn it into a more automated thing by creating reactions for extracting blood and such, and then tie the script into those reactions so that they functions similarly to how the milking reaction goes.
How make script and reactions for this script?

You would need to combine the work that Rumrusher did with a heavily modified create-item script. You could also use the reaction-trigger hooks to set up a script, that would probably be more work, but also more configurable.

If you were asking if someone would make the script for you, probably not, as it is probably not of a lot of interest to most of the people that routinely write scripts. But it would be a great exercise for you to learn how to write scripts.
the work I did mostly discovered you could probably set the extract material to anything of that creature's material, though this does mean you could end up with milked flesh.

also trying to get this to work in adv fort just made me realize how much of an headache getting jobs to work in adv fort vs just assigning said job to an non playable adventurer or Adventurer party member.
so far the only result I got from this is getting a designated campsite inhabitant to drag one of my adventurers off their mount to the farmer's workshop but unable to finish the job so they are just continuing dragging this adventurer around.
Title: Re: DFHack 0.47.04-r1
Post by: Iä! RIAKTOR! on July 06, 2020, 08:50:32 pm
Is possible to make genderless creature pregnant by DFhack? How modify 'Catsplosion' script for this? Any way to make genderless creatures (snail man) breed automatic?
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on July 06, 2020, 09:07:38 pm
so far the only result I got from this is getting a designated campsite inhabitant to drag one of my adventurers off their mount to the farmer's workshop but unable to finish the job so they are just continuing dragging this adventurer around.

I wonder what happens at the butcher's workshop.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on July 06, 2020, 09:39:34 pm
Is possible to make genderless creature pregnant by DFhack? How modify 'Catsplosion' script for this? Any way to make genderless creatures (snail man) breed automatic?
You could try changing this line (https://github.com/DFHack/scripts/blob/0.47.04-r1/catsplosion.lua#L52) to
Code: [Select]
    table.insert(females[id], unit)
That would add all units to the "females" list, which is used to attempt to trigger pregnancies later. I'm not sure what will happen, though - it might work, do nothing, crash, or something else (so save first!).
Title: Re: DFHack 0.47.04-r1
Post by: Iä! RIAKTOR! on July 07, 2020, 04:24:12 am
Is possible to make genderless creature pregnant by DFhack? How modify 'Catsplosion' script for this? Any way to make genderless creatures (snail man) breed automatic?
You could try changing this line (https://github.com/DFHack/scripts/blob/0.47.04-r1/catsplosion.lua#L52) to
Code: [Select]
    table.insert(females[id], unit)
That would add all units to the "females" list, which is used to attempt to trigger pregnancies later. I'm not sure what will happen, though - it might work, do nothing, crash, or something else (so save first!).
This does not cause crash. And even create pregnancies, as DFhack told me. But creatures don't give birth, if they are not females or if they lay eggs (I don't try with nestboxes).
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on July 08, 2020, 10:59:27 pm
I've been continuing work on the DFHack documentation for the past week or so, particularly the more developer-facing docs, in an effort to bring them up to date. https://docs.dfhack.org/en/latest/ currently has my latest changes, particularly https://docs.dfhack.org/en/latest/docs/index-dev.html. I would be glad to hear people's thoughts on these changes and what else needs updating. Some things that are on my list include:

- Documenting the RPC (remote) interface - https://github.com/DFHack/dfhack/issues/1574 has some information, and BenLubar put together a description of the format (https://github.com/DFHack/dfhack/issues/1574#issuecomment-637916990), so this mostly just involves integrating this into the docs
- Documenting tests/continuous integration (we recently switched from Travis to GitHub Actions, so some explanation of what the various jobs running on PRs involve could be useful)
- More comprehensive API documentation for all languages (e.g. modules are mostly only documented for Lua).  This is quite a large undertaking, so will probably take a while.

Anything else stand out to people that could use updating (link again (https://docs.dfhack.org/en/latest/) for reference)?

Recent changes to the docs folder (i.e. the source code for most of the documentation) on the develop branch can be found here: https://github.com/dfhack/dfhack/commits/develop/docs
Title: Re: DFHack 0.47.04-r1
Post by: Roses on July 09, 2020, 01:08:43 am
<snip>

It's looking really good, I will try and take some time in the next couple of days to really go through in detail, but I'm liking what I am seeing. I don't really have much to say about it right now, but I wanted to make sure I took the time to thank you for your work.
Title: Re: DFHack 0.47.04-r1
Post by: Warmist on July 09, 2020, 01:26:04 am
<snip>

Oh wow. Thanks! This is a huge undertaking.
Title: Re: DFHack 0.47.04-r1
Post by: knutor on July 10, 2020, 11:19:08 pm
dfHack createunit REPTILE_MAN Male, works  and produces the 'r'. dfHack gui/gm-unit on r, edits it, fine. However, once game is unpaused, the entire game crashes to the desktop.

dfHack add-thought on a tamed war elephant, crashes the game to desktop, if he is chained and cannot find a bed to sleep on. Must use dfHack tame and gui/gm-unit to tame and set war animal flags, for this crashing to occur.

dfHack emptycaged all, will work on a caged entity carrying a book. Book will however become permenantly flagged with the dump flag, D. No dumping will ever occur, as books normally are unable to be flagged. dfHack autodump skips the book, aswell. So does area of effect undumps.

dfHack fixmerchants, has helped me on lost returning raid pets. But not with the forever traveling soldier, bug.

Nothing occurs with that facet command on a unit.

If this stuff has been reported alrdy, I am sorry. Thanks for the great tool.
Title: Re: DFHack 0.47.04-r1
Post by: Iä! RIAKTOR! on July 11, 2020, 01:02:14 am
If we can unretire any histfig, why there is no way to embark as necromancer governments?
Title: Re: DFHack 0.47.04-r1
Post by: PatrikLundell on July 11, 2020, 03:40:22 am
@knutor: The reason books aren't dumped is because they're typically marked as Trader, and as long as that flag is set the item won't be touched. Items that can't be dump flagged from the DF UI can't have the flag removed from it either, which is rather reasonable: The UI does not allow manipulation of that flag, so if you use DFHackery to set it you'll have to use DFHackery to reset it (but the flag gets removed once the artifact has been dumped, assuming you used DFHackery to clear the Trader flag).
Title: Re: DFHack 0.47.04-r1
Post by: Rumrusher on July 11, 2020, 04:05:38 am
If we can unretire any histfig, why there is no way to embark as necromancer governments?
because adv mode is set up in a way that grabs a historical figure from the poll of histfigs that are flagged for adv mode the script uses the 'unretire function of adventure mode to unretire anyone'
it's probably alot more work to figure out how DF does fort embarks to manipulate that to control who shows up.
Title: Re: DFHack 0.47.04-r1
Post by: Iä! RIAKTOR! on July 11, 2020, 04:57:25 am
If we can unretire any histfig, why there is no way to embark as necromancer governments?
because adv mode is set up in a way that grabs a historical figure from the poll of histfigs that are flagged for adv mode the script uses the 'unretire function of adventure mode to unretire anyone'
it's probably alot more work to figure out how DF does fort embarks to manipulate that to control who shows up.
Just add SITE_CONTROLLABLE to necromancer tower entity. Is this too uneasy for scripting?
Title: Re: DFHack 0.47.04-r1
Post by: Atomic Chicken on July 11, 2020, 05:45:19 am
dfHack createunit REPTILE_MAN Male, works  and produces the 'r'. dfHack gui/gm-unit on r, edits it, fine. However, once game is unpaused, the entire game crashes to the desktop.

dfHack add-thought on a tamed war elephant, crashes the game to desktop, if he is chained and cannot find a bed to sleep on. Must use dfHack tame and gui/gm-unit to tame and set war animal flags, for this crashing to occur.

...

Nothing occurs with that facet command on a unit.


Hi knutor, please provide the full commands that you used in the above scenarios to help identify the cause. In addition, try to describe exactly what you did with gui/gm-unit.

...why is an elephant trying to sleep on a bed?

If we can unretire any histfig, why there is no way to embark as necromancer governments?

I had messed around with fortress mode to a similar effect whilst I was writing the 'unretire-anyone' script. It was definitely possible to embark under a normally unavailable parent civilisation using the same method (i.e. by adding the desired entity to the viewscreen selection). The game gave me starting units of the correct race, with the fort/group naming language and equipment/pet options appropriately corresponding to the selected entity. This worked even for the underground civilisations like amphibian men. However, there was some quirky behaviour such as an inability to assign noble positions and units refusing to pick up axes for woodcutting jobs (even when using a goblin civilisation). I'm not familiar with what it is that modders do to make non-dwarf races playable, but I assume that those sorts of changes would be required to make it work properly.

Embarking as a specific necromancer group isn't technically possible as you create a new entity (a site government) upon embarking (unless unretiring a site); the necromancer group would probably be listed as your parent civilisation, but I have no clue how it'd work out. Also, necromancer groups aren't civilisation type entities, but site governments; this may or may not cause issues. In addition, your embark party wouldn't contain necromancers or undead units without additonal hacking, and any opposed-to-life units would still be hostile to living units. I'm also not sure whether the regular reanimated units are capable of performing jobs.

I had also attempted to directly unretire small non-player sites such as necromancer towers at one point, but never got it to work well.

Just add SITE_CONTROLLABLE to necromancer tower entity. Is this too uneasy for scripting?

It doesn't work like this.
Title: Re: DFHack 0.47.04-r1
Post by: Iä! RIAKTOR! on July 11, 2020, 08:24:54 am
dfHack createunit REPTILE_MAN Male, works  and produces the 'r'. dfHack gui/gm-unit on r, edits it, fine. However, once game is unpaused, the entire game crashes to the desktop.

dfHack add-thought on a tamed war elephant, crashes the game to desktop, if he is chained and cannot find a bed to sleep on. Must use dfHack tame and gui/gm-unit to tame and set war animal flags, for this crashing to occur.

...

Nothing occurs with that facet command on a unit.


Hi knutor, please provide the full commands that you used in the above scenarios to help identify the cause. In addition, try to describe exactly what you did with gui/gm-unit.

...why is an elephant trying to sleep on a bed?

If we can unretire any histfig, why there is no way to embark as necromancer governments?

I had messed around with fortress mode to a similar effect whilst I was writing the 'unretire-anyone' script. It was definitely possible to embark under a normally unavailable parent civilisation using the same method (i.e. by adding the desired entity to the viewscreen selection). The game gave me starting units of the correct race, with the fort/group naming language and equipment/pet options appropriately corresponding to the selected entity. This worked even for the underground civilisations like amphibian men. However, there was some quirky behaviour such as an inability to assign noble positions and units refusing to pick up axes for woodcutting jobs (even when using a goblin civilisation). I'm not familiar with what it is that modders do to make non-dwarf races playable, but I assume that those sorts of changes would be required to make it work properly.

Embarking as a specific necromancer group isn't technically possible as you create a new entity (a site government) upon embarking (unless unretiring a site); the necromancer group would probably be listed as your parent civilisation, but I have no clue how it'd work out. Also, necromancer groups aren't civilisation type entities, but site governments; this may or may not cause issues. In addition, your embark party wouldn't contain necromancers or undead units without additonal hacking, and any opposed-to-life units would still be hostile to living units. I'm also not sure whether the regular reanimated units are capable of performing jobs.

I had also attempted to directly unretire small non-player sites such as necromancer towers at one point, but never got it to work well.

Just add SITE_CONTROLLABLE to necromancer tower entity. Is this too uneasy for scripting?

It doesn't work like this.
I can embark as amphibian men or goblins even by using just RAW changing, no DFhack. The only exception is generated civs of vault guardians. So I want to test your script.

Civ will not assign nobles, if this civ lack of noble positions (tribes) or have no position without requirements (like dwarven expedition leader) that will appoint other nobles or grow into them.

I only want necromancer entity for embarking with experiments as pets. Script for exporting generated raws from already run world will be fine too. So I can try to add experiment to pet list by ANIMAL definition.

I know - necromancer is syndrome, not specie. But I don't really need necromancers. Starting with them is strange, when playing as necrofortress is possible even in vanilla - if your fortress steal secrets of life and death written in a book. But taming experiments isn't possible. So I want start with them.

Unretiring sites is really good idea! I want this script too. Will you make script that make unretireable small settlements like tower and monastery? Because I want also unretire small structure that is part of big site. Like unretire only Underworld Spire, but not all dark fortress.
Title: Re: DFHack 0.47.04-r1
Post by: Rumrusher on July 11, 2020, 09:01:43 am
so far in my experience with making the necro site as one of the civs you can start as in fort mode is that the game treats them like any other entity and they don't get any special bonuses
shoot one could say they pull from the main entity they originally come from so a dwarf necro tower will follow dwarf laws and ethics and the human tower will follow human ones and so on.

the big kicker is with the experiment stuff is the way the game made them hardcoded is tied to the historical figure Id number and that makes it so you need to get lucky on the right historical figure number for your experiment raw name or some weird plan like 'post editing the animal tokens so it matches with the experiments the necromancers make.'  would ever work.
Title: Re: DFHack 0.47.04-r1
Post by: Iä! RIAKTOR! on July 11, 2020, 01:52:16 pm
so far in my experience with making the necro site as one of the civs you can start as in fort mode is that the game treats them like any other entity and they don't get any special bonuses
shoot one could say they pull from the main entity they originally come from so a dwarf necro tower will follow dwarf laws and ethics and the human tower will follow human ones and so on.

the big kicker is with the experiment stuff is the way the game made them hardcoded is tied to the historical figure Id number and that makes it so you need to get lucky on the right historical figure number for your experiment raw name or some weird plan like 'post editing the animal tokens so it matches with the experiments the necromancers make.'  would ever work.
No changes? But why they act so different in worldgen?

I can search world.dat for experiment Id full name. Then I put them to ALWAYS_PRESENT pets. Only issue: I cannot unpack world.dat from already generated world. And cannot force necromancers to make experiments in worldgen. Even with modded creature who can do experiments directly in civ - I don't know how make them creating more experiments.
Title: Re: DFHack 0.47.04-r1
Post by: knutor on July 11, 2020, 02:48:00 pm
dfHack createunit REPTILE_MAN Male, works  and produces the 'r'. dfHack gui/gm-unit on r, edits it, fine. However, once game is unpaused, the entire game crashes to the desktop.

dfHack add-thought on a tamed war elephant, crashes the game to desktop, if he is chained and cannot find a bed to sleep on. Must use dfHack tame and gui/gm-unit to tame and set war animal flags, for this crashing to occur.

Hi knutor, please provide the full commands that you used in the above scenarios to help identify the cause. In addition, try to describe exactly what you did with gui/gm-unit.

...why is an elephant trying to sleep on bed?
It was the last msg before crash. Elephant was unable to find a place to rest. I may have added fat to him. 999,999. Hard to remember.

On the reptile man crash, I used gui/gm-unit to put the newly created male in my civ. Nothing else but maybe uping merriment and leasure time, did I do.

The plan was he would spore fertilize the 6 sterile eggs on map, in nestbox with mothers ontop. The cheat tamed males fail to do this. Game crashed to desktop, upon unpausing.

I run teleport all the time. Fastdwarf 0 1 and Superdwarf on Hunters. Ive got default dfHacks on. With dwarfvet, autofarm and tailor.

Ive a perpetually fighting cheat tamed Fire Man, fighting crabs and imps in magma. Gave him wrestling 5 in gm-unit, now his combat ends.

In a 2hr session of play, I issue 30x this:
multicmd removestress;healall;rejuvinate
Title: Re: DFHack 0.47.04-r1
Post by: Rumrusher on July 11, 2020, 06:53:20 pm
so far in my experience with making the necro site as one of the civs you can start as in fort mode is that the game treats them like any other entity and they don't get any special bonuses
shoot one could say they pull from the main entity they originally come from so a dwarf necro tower will follow dwarf laws and ethics and the human tower will follow human ones and so on.

the big kicker is with the experiment stuff is the way the game made them hardcoded is tied to the historical figure Id number and that makes it so you need to get lucky on the right historical figure number for your experiment raw name or some weird plan like 'post editing the animal tokens so it matches with the experiments the necromancers make.'  would ever work.
No changes? But why they act so different in worldgen?

I can search world.dat for experiment Id full name. Then I put them to ALWAYS_PRESENT pets. Only issue: I cannot unpack world.dat from already generated world. And cannot force necromancers to make experiments in worldgen. Even with modded creature who can do experiments directly in civ - I don't know how make them creating more experiments.
well that's because experiments are like angels where they are generated After world gen and all the sites been made.
so a necromancer legit creating a new creature species the reason they act so differently in world gen is because the historical figure the necromancer is doing stuff than the Site.
like the necromancer has access to a new feature toady added which was scheme and plot.


but like even if you get through all these hoops to get a bunch of necromancers showing up to your fort you still have this one big issue of their resurrection/reanimation is tied to combat, and undead zombies oppose to living causes them to be hostile to everyone in the fort including their own necromancers
Title: Re: DFHack 0.47.04-r1
Post by: Iä! RIAKTOR! on July 12, 2020, 01:08:35 am
so far in my experience with making the necro site as one of the civs you can start as in fort mode is that the game treats them like any other entity and they don't get any special bonuses
shoot one could say they pull from the main entity they originally come from so a dwarf necro tower will follow dwarf laws and ethics and the human tower will follow human ones and so on.

the big kicker is with the experiment stuff is the way the game made them hardcoded is tied to the historical figure Id number and that makes it so you need to get lucky on the right historical figure number for your experiment raw name or some weird plan like 'post editing the animal tokens so it matches with the experiments the necromancers make.'  would ever work.
No changes? But why they act so different in worldgen?

I can search world.dat for experiment Id full name. Then I put them to ALWAYS_PRESENT pets. Only issue: I cannot unpack world.dat from already generated world. And cannot force necromancers to make experiments in worldgen. Even with modded creature who can do experiments directly in civ - I don't know how make them creating more experiments.
well that's because experiments are like angels where they are generated After world gen and all the sites been made.
so a necromancer legit creating a new creature species the reason they act so differently in world gen is because the historical figure the necromancer is doing stuff than the Site.
like the necromancer has access to a new feature toady added which was scheme and plot.


but like even if you get through all these hoops to get a bunch of necromancers showing up to your fort you still have this one big issue of their resurrection/reanimation is tied to combat, and undead zombies oppose to living causes them to be hostile to everyone in the fort including their own necromancers
If I need necromancers in my fort, I can just raid for books and create ny own fort of necromancers only. But I want experiments, not necromancers.
Title: Re: DFHack 0.47.04-r1
Post by: Rumrusher on July 12, 2020, 04:34:59 am
so far in my experience with making the necro site as one of the civs you can start as in fort mode is that the game treats them like any other entity and they don't get any special bonuses
shoot one could say they pull from the main entity they originally come from so a dwarf necro tower will follow dwarf laws and ethics and the human tower will follow human ones and so on.

the big kicker is with the experiment stuff is the way the game made them hardcoded is tied to the historical figure Id number and that makes it so you need to get lucky on the right historical figure number for your experiment raw name or some weird plan like 'post editing the animal tokens so it matches with the experiments the necromancers make.'  would ever work.
No changes? But why they act so different in worldgen?

I can search world.dat for experiment Id full name. Then I put them to ALWAYS_PRESENT pets. Only issue: I cannot unpack world.dat from already generated world. And cannot force necromancers to make experiments in worldgen. Even with modded creature who can do experiments directly in civ - I don't know how make them creating more experiments.
well that's because experiments are like angels where they are generated After world gen and all the sites been made.
so a necromancer legit creating a new creature species the reason they act so differently in world gen is because the historical figure the necromancer is doing stuff than the Site.
like the necromancer has access to a new feature toady added which was scheme and plot.


but like even if you get through all these hoops to get a bunch of necromancers showing up to your fort you still have this one big issue of their resurrection/reanimation is tied to combat, and undead zombies oppose to living causes them to be hostile to everyone in the fort including their own necromancers
If I need necromancers in my fort, I can just raid for books and create ny own fort of necromancers only. But I want experiments, not necromancers.
I would probably say the experiments are at this case toady making them one part night trolls where they are historical figures and angels where their raw name and existance is co-dependent to the historical figure that makes them that you would have a harder time getting one.

like I guess one could mess with the mainland site entity to insert said experiments in via dfhack post worldgen.

though I guess there's the adventure route where you just make a bunch of experiment adventurers for the retired player fort and just retire them there and unretire the fort.
Title: Re: DFHack 0.47.04-r1
Post by: knutor on July 12, 2020, 10:35:05 pm
I best be a playtester, tried a simple thing like giving my Reptile Man a tail slap. Copied its attack from Orca. Stuck in raw by his other 4 attacks. No joy. DF log says no such BP, guess they mean body part. What goods a tail, if he cannot slap with it, I say.

that multicmd was wrong, btw. Has heal, fillneeds, rem stress. I dont use rejuvinate. In case your researching my war elephant wanting a bed.
Title: Re: DFHack 0.47.04-r1
Post by: Hiul on July 13, 2020, 03:06:36 am
dfhack dont support 32bit anymore right? if it still support it, can someone add the link for me to download? or the original zip already include it? i cant go into github for some reason, never try dfhack before though.
Title: Re: DFHack 0.47.04-r1
Post by: Warmist on July 13, 2020, 03:10:02 am
dfhack dont support 32bit anymore right? if it still support it, can someone add the link for me to download? or the original zip already include it? i cant go into github for some reason, never try dfhack before though.
Afaik we support 32bits but github is currently down. I would recommend patience as github should sort it out soon.
Title: Re: DFHack 0.47.04-r1
Post by: Ziusudra on July 13, 2020, 03:26:28 am
It's up for me. There's 32bit versions at the bottom of this page: https://github.com/DFHack/dfhack/releases/tag/0.47.04-r1

Or 32bit testing builds available through: https://dfhack.org/builds/
Title: Re: DFHack 0.47.04-r1
Post by: Hiul on July 13, 2020, 03:43:51 am
Afaik we support 32bits but github is currently down. I would recommend patience as github should sort it out soon.

It's up for me. There's 32bit versions at the bottom of this page: https://github.com/DFHack/dfhack/releases/tag/0.47.04-r1

Or 32bit testing builds available through: https://dfhack.org/builds/

thanks  :D
Title: Re: DFHack 0.47.04-r1
Post by: Iä! RIAKTOR! on July 13, 2020, 08:54:36 am
Any way to script tortures in fort mode?
Title: Re: DFHack 0.47.04-r1
Post by: knutor on July 13, 2020, 09:26:36 am
My cheat tamed, add-thought War Elephant just visited the booze stockpile, grabbed a mug and drank up. He thinks he is a dorf. Pulled up his info in gui/gm-unit. I gave him no fat. So I gave him 1mil fat storage, checked the skills with tab, mostly combat, but he has balance at 2, and coordination at 2. His beliefs/preferences are all over the place.
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on July 14, 2020, 04:06:42 pm
Is it possible to write data to a file using a script or plugin? Purpose is to save fort tiles as a .csv (or other text file format.)
Title: Re: DFHack 0.47.04-r1
Post by: PatrikLundell on July 14, 2020, 04:45:07 pm
Is it possible to write data to a file using a script or plugin? Purpose is to save fort tiles as a .csv (or other text file format.)
Yes, on both accounts. Exportmap exports data and tweakmap reads it, allows modification, and writes it http://www.bay12forums.com/smf/index.php?topic=161188.msg7228166#msg7228166 (http://www.bay12forums.com/smf/index.php?topic=161188.msg7228166#msg7228166). Embark Assistant can also write a search profile file and read it back.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on July 14, 2020, 09:22:53 pm
Is it possible to write data to a file using a script or plugin? Purpose is to save fort tiles as a .csv (or other text file format.)
All languages that DFHack uses (C++, Lua, Ruby) have native support for reading and writing files - there's nothing DFHack-specific about it, and DFHack hasn't disabled it, so the language documentation would be the place to look for details (or existing examples like PatrikLundell's).

However, this question made me think of the project that Myk is taking on to make a Quickfort-like utility:
http://www.bay12forums.com/smf/index.php?topic=176889.0
https://github.com/DFHack/dfhack/issues/499
It might be worth looking at these to make sure you're not duplicating effort, or to see if you might be able to help out.

(Also, if anyone else would like to provide feedback, feel free to take a look at that thread.)
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on July 14, 2020, 10:09:40 pm
However, this question made me think of the project that Myk is taking on to make a Quickfort-like utility:
http://www.bay12forums.com/smf/index.php?topic=176889.0
https://github.com/DFHack/dfhack/issues/499
It might be worth looking at these to make sure you're not duplicating effort, or to see if you might be able to help out.

I was thinking of doing it for AutoFort:
http://www.bay12forums.com/smf/index.php?topic=176774.0

The exported data will probably be way different, since it's going to be used to proc-gen a fort layout. Maybe he could create a quickfort blueprint for import, though.
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on July 19, 2020, 05:46:55 pm
Is there some way to determine the lowest valid z-level of a map block? Or do we just have to check if there's a map block at each given location?

For example, on one embark the eerie glowing pits were located on z=1. On another, they were on z=6, with no valid map blocks from z=1 to z=5.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on July 19, 2020, 07:03:50 pm
Is there some way to determine the lowest valid z-level of a map block? Or do we just have to check if there's a map block at each given location?

For example, on one embark the eerie glowing pits were located on z=1. On another, they were on z=6, with no valid map blocks from z=1 to z=5.
I think you just have to check whether each block is allocated or not. (For reference, there are also some sky blocks at higher z-levels that aren't allocated by default until you build in them.)
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on July 20, 2020, 01:14:38 am
Thanks. One last question:
In many lua scripts I see the lines "--@module = true" and "if not dfhack_flags.module then". What is the point of these?
Title: Re: DFHack 0.47.04-r1
Post by: Warmist on July 20, 2020, 01:39:47 am
Thanks. One last question:
In many lua scripts I see the lines "--@module = true" and "if not dfhack_flags.module then". What is the point of these?

Lua has "modules" which are like script-library. We (i.e. dfhack team) has extended this functionality to scripts. Thus a script can be used as a module but it needs to know if it should just run the functionality (e.g. teleport a unit to cursor) or give the functions (e.g. if you are making a building or a spell that teleports creatures). More info  here  (https://docs.dfhack.org/en/stable/docs/Lua%20API.html#scripts)
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on July 20, 2020, 02:12:04 am
Lua has "modules" which are like script-library. We (i.e. dfhack team) has extended this functionality to scripts. Thus a script can be used as a module but it needs to know if it should just run the functionality (e.g. teleport a unit to cursor) or give the functions (e.g. if you are making a building or a spell that teleports creatures). More info  here  (https://docs.dfhack.org/en/stable/docs/Lua%20API.html#scripts)

Still a bit unclear to me. Does this mean that putting these lines allows the function definitions to be used by other scripts without executing the main function? Similar to Python's if __name__ == "__main__"?
Title: Re: DFHack 0.47.04-r1
Post by: Warmist on July 20, 2020, 02:24:02 am
Lua has "modules" which are like script-library. We (i.e. dfhack team) has extended this functionality to scripts. Thus a script can be used as a module but it needs to know if it should just run the functionality (e.g. teleport a unit to cursor) or give the functions (e.g. if you are making a building or a spell that teleports creatures). More info  here  (https://docs.dfhack.org/en/stable/docs/Lua%20API.html#scripts)

Still a bit unclear to me. Does this mean that putting these lines allows the function definitions to be used by other scripts without executing the main function? Similar to Python's if __name__ == "__main__"?

As far as I understand it's the same as Python's if __name__ == "__main__".
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on July 20, 2020, 02:32:04 am
Okay, thanks!
Title: Re: DFHack 0.47.04-r1
Post by: Atomic Chicken on July 20, 2020, 09:16:45 am
Thanks. One last question:
In many lua scripts I see the lines "--@module = true" and "if not dfhack_flags.module then". What is the point of these?

"--@ module = true" permits the script to be used as a module, which basically means that other scripts can call functions from it via "reqscript".

Consider the following snippet from "resurrect-adv.lua", which calls the "heal()" function of "full-heal.lua":
Code: (resurrect-adv.lua) [Select]
local fullHeal = reqscript('full-heal')
...
fullHeal.heal(adventurer, true)

If "full-heal.lua" lacked "--@ module = true", the above code would fail at the reqscript line with the error "full-heal: Cannot be used as a module."

"dfhack_flags.module" is set when the script is being called through reqscript. It's added to module-enabled scripts to prevent unnecessary code from running when they are being used as modules (if omitted, the whole script would run as if it had been called from console).

For example:
Code: [Select]
if not dfhack_flags.module then
  print("foo")
end
Prevents "foo" from being printed during a reqscript call.

Code: [Select]
if dfhack_flags.module then
  return
end
print("foo")
An alternative way to do the above.

"moduleMode" is sometimes used instead of "dfhack_flags.module"; they do the same thing as far as I'm aware.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on July 20, 2020, 09:36:03 am
Yeah, dfhack_flags.module and moduleMode do basically the same thing. The latter was older, and was kept for compatibility with existing scripts.

Either way, though, you should prefer reqscript() for importing other scripts. It will ensure that the script has the "--@ module = true" flag set before attempting to execute the script, which usually means that a script was written to handle being imported by other scripts. Not all scripts handle this - e.g. if you tried to load https://github.com/DFHack/scripts/blob/master/devel/all-bob.lua with script_environment, it would actually execute the script before returning the script's environment. (This is similar to attempting to import a Python file that doesn't guard its entrypoint with "if __name__ == '__main__'".)

There are also a couple other flags (https://github.com/DFHack/dfhack/blob/0.47.04-r1/library/lua/dfhack.lua#L573-L586) available in dfhack_flags sometimes - some are only used internally, but enable and enable_state are documented (https://docs.dfhack.org/en/stable/docs/Lua%20API.html#enabling-and-disabling-scripts).
Title: Re: DFHack 0.47.04-r1
Post by: Iä! RIAKTOR! on July 20, 2020, 01:59:40 pm
I have an idea. Changed Catsplosion script can make male creatures pregnant, but male cannot give birth. But male creature can lay eggs! So will this work for monogendered creature breeding? Who can test?
Title: Re: DFHack 0.47.04-r1
Post by: Putnam on July 21, 2020, 07:13:42 pm
You can also transform male creatures to a female caste during the pregnancy, though I think that ruins the "monogendered" criterion.
Title: Re: DFHack 0.47.04-r1
Post by: Iä! RIAKTOR! on July 23, 2020, 10:01:37 am
You can also transform male creatures to a female caste during the pregnancy, though I think that ruins the "monogendered" criterion.
Transformation heal all injures. And satyrs, blendecs, grimelings, blizzard men has no female caste at all. So, can you test my idea? I am very bad with lua coding.
Title: Re: DFHack 0.47.04-r1
Post by: knutor on July 24, 2020, 11:06:55 pm
Probably reported in one of 1xx's of dfHack pages, but in the event it hasn't been reported.

Fastdwarf teleport does not bring along the visiting mercs.

Ive a hu mercenary in shock squad, 4. S4 is filled to 10 souls. It was ordered to kill something in caverns. 9 soldiers teleported to  thing in cavern. All the dwarfs minus the mercenary.

Crossing fingers. To me teleport works like marching orders, for the squad soldiers. I hope someone out there in forumland, can fix this.
Title: Re: DFHack 0.47.04-r1
Post by: Schmaven on July 24, 2020, 11:23:47 pm
...
To me teleport works like marching orders, for the squad soldiers.
...

That's a cool idea.  Like a forced march in the military - everyone has to stop what they're doing and go there.

Except the mercenaries it seems. 
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on July 24, 2020, 11:40:38 pm
Fastdwarf teleport does not bring along the visiting mercs.

Ive a hu mercenary in shock squad, 4. S4 is filled to 10 souls. It was ordered to kill something in caverns. 9 soldiers teleported to  thing in cavern. All the dwarfs minus the mercenary.

Crossing fingers. To me teleport works like marching orders, for the squad soldiers. I hope someone out there in forumland, can fix this.
Looks like there's a check (https://github.com/DFHack/dfhack/blob/0.47.04-r1/plugins/fastdwarf.cpp#L54) to skip non-citizens. That part was last changed in 2012, well before mercenaries and other visitors were added, so presumably it was meant to exclude livestock, invaders, etc.. I'm not sure what a better check would be - maybe Units::isOwnGroup()?

Quote
Probably reported in one of 1xx's of dfHack pages, but in the event it hasn't been reported.
A quick search of the DFHack issue tracker (https://github.com/DFHack/dfhack/issues) turned up https://github.com/DFHack/dfhack/issues/664, which is a similar issue. Unclear if the reporter there wanted it to apply to visitors or some other group of units, though.

In any case, thanks for the report! Feel free to report issues if you can't find them already reported. 2-3 reports are better than no reports. (There is such a thing as too many reports, but that's not an issue here.)
Title: Re: Of interest for linux and OSX users that needs blueprints to play
Post by: lethosor on July 27, 2020, 10:59:07 pm
The modified script as of now just work eagerly before trapping and has some new nice features:
- it stamps the safe part of blueprints that are same size than the embark. (with some more tinkering and 4 additional params partial stamping should be in the reachable zone)
- it warns when some lines and/or rows of the blueprint could had been ignored because the dimensions of the blueprint are bigger than the design-able zone of the embark.
- well formed multilevel nanoforts of 48x48 or 47x47 tiles faultily rejected by the previous script over an 1x1 embark are now possible.
It has been a while, but I finally got around to this. It turns out the map boundary check was off by one, so it thought any blueprint that touched the bottom or right edge of the map went off the map. I fixed that, and added a "force" option to allow drawing partial blueprints instead of failing. I hope this is what you were aiming to do with your changes - if not, feel free to let me know.

I'm no Ruby expert either, but you can see the changes I made to the script here (https://github.com/DFHack/scripts/compare/1bf46cf14ec1...ef428bec5269). This change (https://github.com/DFHack/scripts/commit/01a08c430e9845ecd1d72143d0e7d118278c5a3c#diff-5a446a9a321bb7208b755e897f6c8e20L103-R103) specifically fixed the off-by-one error I mentioned.


Some things that are on my list include:

- Documenting the RPC (remote) interface - https://github.com/DFHack/dfhack/issues/1574 has some information, and BenLubar put together a description of the format (https://github.com/DFHack/dfhack/issues/1574#issuecomment-637916990), so this mostly just involves integrating this into the docs
Here's some remote API documentation (forgot to mention it a week or so ago when I put it up): https://docs.dfhack.org/en/latest/docs/Remote.html
I know some of you have struggled to get information about the remote API, and I'm not very familiar with it either, so this is a bunch of information I've pulled together from various places. If there's more information that would be helpful to include, let me know and I can try to integrate it.
Title: Re: DFHack 0.47.04-r1
Post by: knutor on July 29, 2020, 09:46:32 am
Stumbled upon a confirmed mantis bug in 47.04 last night.

http://www.bay12games.com/dwarves/mantisbt/view.php?id=9943&nbn=6#bugnotes

Thank you dfHack, using the changeitem command, I was able to fix things. All good now. I only wanted to, thank you.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on July 29, 2020, 09:41:28 pm
Thanks for the feedback!

A heads up: I'm planning on releasing 0.47.04-r2 "soon", if all goes well (rough progress here (https://github.com/orgs/DFHack/projects/9)). I encourage people to try out a development ("unstable") build from https://dfhack.org/builds/ and let us know if you spot any issues with it - it should be at least as stable as 0.47.04-r1, with some extra fixes (https://docs.dfhack.org/en/latest/docs/NEWS.html#dfhack-future), and probably won't change very much before r2.

Edit: and even if you don't do that, please consider taking a look at the new documentation: https://docs.dfhack.org/en/latest/
There are some new pages and some organizational changes, so let me know if anything needs fixing. This will become the new "stable (https://docs.dfhack.org/en/stable/)" version when r2 is released.
Title: Re: DFHack 0.47.04-r1
Post by: knutor on July 30, 2020, 03:49:45 pm
clearowned all

This does not clear all owned objects on the embark map, like a player would think it would. It ignores visitors items, which are held in their inventory. Call these item(vb)

Autodumping item(vb) dumps it right out of a visitors inventory. Once on ground cleanowned all, still fails on item(vb). However oddly, cleanowned scattered works. Turning item into item(c). Cleaned of ownership. This is a lagubrious click intensive way to circumnavigate the ALL feature, failing to work on item(vb).

Not sure item(c) is usable, however. It sits where dumped, alone.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on July 30, 2020, 09:55:38 pm
I'm not sure what items it's supposed to handle - I don't see an explicit check for owners' citizenship, like some other plugins, but the logic is a bit complicated: https://github.com/DFHack/dfhack/blob/0.47.04-r1/plugins/cleanowned.cpp#L58

It looks like there are a couple messages that this plugin can print. For an item that you're having issues with, does the plugin say that it was handled, say that it was handled "(unsuccessfully)", or not mention it at all?
Title: Re: DFHack 0.47.04-r1
Post by: knutor on July 30, 2020, 11:47:41 pm
When it fails, it scrolls past, before I can tell. I do not remeber seeing a notice of failure.

cleanowned

 -does junk on ground with ownerships, like socks.

cleanowned all

-clears every ownership on every item on embark map, except gear being tracked for special names, I wanna say. I could be mistaken, however I dont ever remember a conflict with the equipment naming code, before, when using this command.

Ive never used scatter before, but oddly, it did work on that visitor's instrument, once it was on the ground. It was another civ's instrument, the dwarfs from my fort could not make that item.

Bumped into this problem, while trying to move my higher quality instruments all into the public tavern from unused temples.
Title: Re: DFHack 0.47.04-r1
Post by: knutor on July 31, 2020, 12:09:48 am
I had a look at that link. I'm guessing the problem is around lines 17,18,19. It calls for unit.h, item.h, translation.h but there is some additional options now, these days, visitor.h and instrument.h <--- hunch, no idea if these even exist. I am no programer, but this seems to me to be where it breaks.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on July 31, 2020, 12:58:40 am
Those actually aren't part of the logic for cleaning items at all (line 58, which I linked to, is roughly where that starts). A basic explanation: the lines you mentioned are just the plugin including other files that it needs to work with certain types of data - everything in question is an item, so the "item"-related lines are enough, but also don't affect cleaning directly. The link was mostly for my own reference (and in case someone more familiar with the plugin could chime in) - sorry for the confusion.

If you want someone else to take a look at this, it would be helpful if you could upload a save with some items that show this issue, as well as a clear description of how to find the problematic items.
Title: Re: DFHack 0.47.04-r1
Post by: knutor on July 31, 2020, 04:42:34 pm
Buggy Reproduction for cleanowned.
It is done all in one pause, in any fort with a public tavern, with an entertainer guest with an owned instrument.

Open an entertainer(bard) visitor's inventory
Attempt the Magneto Gambit+.
While instrument sits on the ground, observe it. Owned.
Run cleanowned all. Reobserve it. Still owned. #1 Bug verified.
Run cleanowned scattered. Reobserve it. Instrument cleaned.++

Backup, retry another bard visitor's inventory without Magneto Gambit.
cleanowned all. observe it. Still in bard's inventory, still owned #2 Bug verified.

The -all extension fails on owned instruments in inventory AND on ground.

+autodump metal straight from inventory, in this case not goblinite, but the visitor's randomly generated, owned, foreign crafted, music instrument
++workaround, repurcusions on cleaned object unknown.
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on August 01, 2020, 12:17:07 am
Buggy Reproduction for cleanowned.
It is done all in one pause, in any fort with a public tavern, with an entertainer guest with an owned instrument.
Thanks for the detailed instructions, but I don't have a save that has most of the things needed to reproduce it. Can you upload a save to make it easier for us to reproduce? http://dffd.bay12games.com/ is one site that takes DF-related files, but somewhere else would also work. (In case you're unfamiliar with the process, we would only need a compressed copy of the data/save/regionX folder you're using.)
Title: Re: DFHack 0.47.04-r1
Post by: Bumber on August 03, 2020, 12:18:12 am
I've noticed that lua scripts use `` in their help text instead of ". Is there a reason for this convention?
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on August 03, 2020, 11:12:18 pm
I've noticed that lua scripts use `` in their help text instead of ". Is there a reason for this convention?
It produces inline code blocks in ReStructuredText, which is what our documentation system uses.
Example: https://github.com/DFHack/scripts/blob/0.47.04-r1/add-thought.lua#L9 gives https://docs.dfhack.org/en/0.47.04-r1/docs/_auto/base.html#add-thought

https://docs.dfhack.org/en/latest/docs/Documentation.html goes into a bit more detail (this page is relatively new, although bits of it were taken from other pages, so let me know if it needs improving)
Title: Re: DFHack 0.47.04-r1
Post by: Warmist on August 04, 2020, 12:26:34 am
Btw i'm still impressed how nicely this all works
Title: Re: DFHack 0.47.04-r1
Post by: Roses on August 06, 2020, 01:37:09 pm
Question about the onReactionComplete eventful trigger. IIRC it only triggers when a product is actually created, is that still true? Also, if using both onReactionComplete and onJobCompleted will the always trigger in the same order, or will it be somewhat random which one triggers first?
Title: Re: DFHack 0.47.04-r1
Post by: Warmist on August 07, 2020, 01:10:05 am
Question about the onReactionComplete eventful trigger. IIRC it only triggers when a product is actually created, is that still true? Also, if using both onReactionComplete and onJobCompleted will the always trigger in the same order, or will it be somewhat random which one triggers first?

Could be wrong but onReactionComplete(and the ing) is actually badly named (mea culpa). Should be along the lines "reaction product create". It triggers when reaction is creating a product. IIRC it does trigger more than once when it's doing reaction with multiple products and other strange stuff. onJobCompleted on the other hand is way different - it uses the eventmanager system where it periodically scans the jobs and sees if they changed (in this case got completed). Not sure on the specs of it (is it 100% accurate) there are some notes about false positives though.
Title: Re: DFHack 0.47.04-r1
Post by: Roses on August 07, 2020, 10:32:16 am
Question about the onReactionComplete eventful trigger. IIRC it only triggers when a product is actually created, is that still true? Also, if using both onReactionComplete and onJobCompleted will the always trigger in the same order, or will it be somewhat random which one triggers first?

Could be wrong but onReactionComplete(and the ing) is actually badly named (mea culpa). Should be along the lines "reaction product create". It triggers when reaction is creating a product. IIRC it does trigger more than once when it's doing reaction with multiple products and other strange stuff. onJobCompleted on the other hand is way different - it uses the eventmanager system where it periodically scans the jobs and sees if they changed (in this case got completed). Not sure on the specs of it (is it 100% accurate) there are some notes about false positives though.

That sounds right, I remember looking into this a bunch a year or two ago and what you are saying is jogging my memory. I did forget about the multiple trigger, although if I had looked at the reaction-product-trigger script I would have seen that it explicitly says it triggers once per product.

As for onJobCompleted, looking at reaction-trigger it says that the frequency for the event needs to be set to 0 so that it ignores cancelled jobs. What does a frequency of 0 mean? I was under the impression that the frequency for the eventful stuff was just how ever many ticks in between the check (e.g. item-trigger has a 5 for INVENTORY_CHANGE, so every 5 ticks it checks for inventory changes), so is 0 a special case?
Title: Re: DFHack 0.47.04-r1
Post by: Prismatic on August 07, 2020, 10:41:02 am
Reporting an issue with the "names.lua" script. Attempting to use it to rename a unit fails with the following error message:
Code: [Select]
...\Dwarf Fortress\DF 0.47/hack/scripts/names.lua:67: Cannot read field viewscreen_setupadventurest.adventurer: not found.
stack traceback:
        [C]: in metamethod '__index'
        ...\Dwarf Fortress\DF 0.47/hack/scripts/names.lua:67: in local 'fun'
        ...\Dwarf Fortress\DF 0.47\hack\lua\class.lua:98: in upvalue 'invoke_after_rec'
        ...\Dwarf Fortress\DF 0.47\hack\lua\class.lua:127: in global 'namescr'
        ...\Dwarf Fortress\DF 0.47/hack/scripts/names.lua:89: in local 'script_code'
        ...\Dwarf Fortress\DF 0.47\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
        (...tail calls...)
Title: Re: DFHack 0.47.04-r1
Post by: lethosor on August 08, 2020, 12:45:35 am
Reporting an issue with the "names.lua" script. Attempting to use it to rename a unit fails with the following error message:
Code: [Select]
...\Dwarf Fortress\DF 0.47/hack/scripts/names.lua:67: Cannot read field viewscreen_setupadventurest.adventurer: not found.
stack traceback:
        [C]: in metamethod '__index'
        ...\Dwarf Fortress\DF 0.47/hack/scripts/names.lua:67: in local 'fun'
        ...\Dwarf Fortress\DF 0.47\hack\lua\class.lua:98: in upvalue 'invoke_after_rec'
        ...\Dwarf Fortress\DF 0.47\hack\lua\class.lua:127: in global 'namescr'
        ...\Dwarf Fortress\DF 0.47/hack/scripts/names.lua:89: in local 'script_code'
        ...\Dwarf Fortress\DF 0.47\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
        (...tail calls...)
Thanks for the report! I've figured out a fix, which will be in the next release.

If you're interested: creating the in-game name-editing screen is complicated, so instead of doing that, the script would create an adventurer setup screen, copy in the relevant name, and trigger that screen's logic to create the name-editing screen. However, the adventurer setup screen changed significantly in 0.47.01, to the point where this strategy is no longer possible (at least, I couldn't figure out how to set it up properly). Fortunately, the fortress setup screen can still be used for the same purpose, so I switched the script to use that.
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on August 08, 2020, 10:15:48 pm
New release! https://github.com/DFHack/dfhack/releases/tag/0.47.04-r2 (Maybe some day I will update the changelog generator to produce a Bay12-friendly changelog too, but for now, you can find release notes there.)
This also means that the "stable" branch of the docs has been updated: https://docs.dfhack.org/en/stable/

I've been thinking a bit about how our release cycles have been going, particularly regarding bugfixes being delayed - for example, this one took a couple months to finally make its way into a release, which isn't ideal:
Regarding stonesense.. Is the expectation that it's currently supposed to be working, in -r1?  Or is that a future revision goal?
I've tried a default/brand-new install of both 0.47.04 + dfhack 0.47.04-r1, and attempting to launch stonesense crashes df and dfhack.
For reference, here (https://github.com/DFHack/stonesense/issues/68) is the issue. It's been around for a while, but Stonesense is large, complicated, and has few active devs (so thank you Rose for the fix!) so I didn't think it was worth holding off 0.47.04-r1 indefinitely for a fix. In retrospect, I probably should have made that more clear in the release notes. Our release notes are semi-generated now and really just focus on changes since the last release(s), not release-specific notes, but this is something we could improve.

At the same time, there is a weird and nasty bug (https://github.com/DFHack/dfhack/issues/1576) on develop (well, hopefully just this one) that would definitely hold up an r2. Maybe we should start making smaller and more frequent "point" releases (like r1.1) with fixes like these, now that I think about it.
I've been using project boards (https://github.com/orgs/DFHack/projects/) on GitHub for a while to organize releases. They primarily have two benefits: keeping track of things that are part of a release (fixed issues, merged PRs), and keeping track of things that need to be addressed before the next release. The latter category has historically included lots of features, some of which can be time-consuming to get around to. Going forward, I think I would like to make smaller but more-frequent releases with whatever happens to be ready at the time (and maybe delaying for some important bugfixes). These would still follow the current versioning convention ("0.47.04-r3", "0.47.04-r4", etc.).

I realize this will impact third-party plugins, notably TWBT, because they will need to be recompiled more often due to DFHack requiring the plugin version to be compiled against the same DFHack version. I'm thinking of relaxing this restriction a bit, although I didn't think coming up with a proper approach was worth delaying r2 for. Once DFHack has reached stable status for a certain DF version, we usually haven't had structures issues that would warrant a plugin compatibility break, so I'm considering allowing plugins built for a stable DFHack version to be loaded under any other stable DFHack version for the same DF version (e.g. a plugin built for 0.47.04-r3 could load under 0.47.04-r4 and vice versa). We do already have a plugin ABI version indicator that we could use to prevent incompatible plugins from loading if the plugin ABI ever changes (although the last notable case I'm aware of was in 0.34.11-r4, when the structure of vmethod hooks changed). Open to suggestions here.
Title: Re: DFHack 0.47.04-r2
Post by: PatrikLundell on August 09, 2020, 01:21:41 am
Thanks for the work!

I think smaller, more frequent releases would be useful, perhaps with an aim for one every month or so (assuming there's enough stuff to make it worthwhile, of course, resulting in less frequent releases as a version matures), with extra ones for the occasional "nasty bug" cases. If post Premium DF development results in minor releases of the current version results in monthly releases we'd get a natural pace setter there, but there is a way to go before we reach that stage.
Title: Re: DFHack 0.47.04-r2
Post by: PeridexisErrant on August 09, 2020, 07:43:32 am
I'm a huge fan of frequent and thus small releases - I've known some open source projects to automate the whole process to automatically ship the stable branch from a weekly cron job if it's changed, or even cut a new release after merging every single pull request.

I'm also not too worried about external plugins - though a more relaxed approach where compatibility is based on ABI rather than exact version would be good.  It would be lovely if TwbT could be merged upstream into DFHack now that it's no longer under development too, which would solve that distribution problem...
Title: Re: DFHack 0.47.04-r2
Post by: waterphage13 on August 10, 2020, 04:47:15 am
https://drive.google.com/file/d/11L_co26cN2ba3ugrASdxN6zXydNUppdo/view?usp=sharing
<a href="http://www.imgzilla.ru/view-image/aac9956a425651da86cb009974a9345e.png" target="_blank">(http://www.imgzilla.ru/image.uploads/2020-08-10/original-aac9956a425651da86cb009974a9345e.png)[/url]
What can cause this errors?
P.S.:
Found that path was not on a latin symbols.
Title: Re: DFHack 0.47.04-r2
Post by: Roses on August 10, 2020, 11:58:50 am
Some questions about the lua API

1. dfhack.gui.getDepthAt(x, y) - This states that it "Returns the distance from the z-level of the tile at map coordinates (x, y) to the closest ground z-level below". I'm not really sure what it is tying to say, since it doesn't take a z level as an argument.
2. dfhack.job.getGeneralRef(job, type) - By type, does it mean something like "df.general_ref_building_holderst"
3. dfhack.items.moveToBuilding(item,building[,use_mode[,force_in_building]) - When using force_in_building, should use_mode = 2? Is force_in_building temporary?
4. dfhack.buildings.checkFreeTiles(pos,size[,extents,change_extents,allow_occupied]) - What is the format for size?
Title: Re: DFHack 0.47.04-r2
Post by: Bumber on August 10, 2020, 12:03:41 pm
How do I check the type of a block_events struct in Lua? I want the one of type df.block_square_event_type.frozen_liquid (if it exists for the block.)

I see the line <vmethod ret-type='block_square_event_type' name='getType'/> in df/structures, but I'm sure if I can call that in Lua.

Is there a proper way to do this, or should I just check for the existence of a "tiles" array (which only the frozen_liquid type seems to have?)



Found something odd in MapCache.cpp: (https://github.com/DFHack/dfhack/blob/f2b0f012c9895aa3fd743ad50fab9e6fb78b479d/library/modules/MapCache.cpp#L855)
Code: [Select]
case SOIL:
{
    auto &biome = mblock->biomeInfoAt(pos);
    rv.mat_index = biome.layer_stone[mblock->layerIndexAt(pos)];

    if (getGroundType(rv.mat_index) == G_STONE)
    {
        int idx = biome.default_soil;
        if (idx >= 0)
            rv.mat_index = idx;
    }

    break;
}

case STONE:
{
    auto &biome = mblock->biomeInfoAt(pos);
    rv.mat_index = biome.layer_stone[mblock->layerIndexAt(pos)];

    if (getGroundType(rv.mat_index) == G_SOIL)
    {
        int idx = biome.default_stone;
        if (idx >= 0)
            rv.mat_index = idx;
    }

    break;
}

The checks for G_SOIL and G_STONE seem to be swapped. Is this a mistake or not?
Title: Re: DFHack 0.47.04-r2
Post by: Warmist on August 10, 2020, 12:41:19 pm
Some questions about the lua API

1. dfhack.gui.getDepthAt(x, y) - This states that it "Returns the distance from the z-level of the tile at map coordinates (x, y) to the closest ground z-level below". I'm not really sure what it is tying to say, since it doesn't take a z level as an argument.
Not sure, but it seems as it's for twbt and similar stuff. It reports it for current screen?
Quote
2. dfhack.job.getGeneralRef(job, type) - By type, does it mean something like "df.general_ref_building_holderst"
Nope it's df.general_ref_type enum (https://github.com/DFHack/scripts/blob/aed35fdefa7a7818e99c5a6ed9a0c878458cdb7c/devel/nuke-items.lua#L15)
Quote
3. dfhack.items.moveToBuilding(item,building[,use_mode[,force_in_building]) - When using force_in_building, should use_mode = 2? Is force_in_building temporary?
Don't know this one. But only use_mode=0 or use_mode=2 supported and you can use it with use_mode==0 force_in_building.  Does not help that both are my scripts :<  (https://github.com/DFHack/scripts/search?q=moveToBuilding&unscoped_q=moveToBuilding). The lever one creates a lever with real mechanisms.

4. -- don't know


How do I check the type of a block_events struct in Lua? I want the one of type df.block_square_event_type.frozen_liquid (if it exists for the block.)

I see the line <vmethod ret-type='block_square_event_type' name='getType'/> in df/structures, but I'm sure if I can call that in Lua.

You can just do "event:getType()" as lua supports vmethods (even if it does not enumerate them when printing members).

As for onJobCompleted, looking at reaction-trigger it says that the frequency for the event needs to be set to 0 so that it ignores cancelled jobs. What does a frequency of 0 mean? I was under the impression that the frequency for the eventful stuff was just how ever many ticks in between the check (e.g. item-trigger has a 5 for INVENTORY_CHANGE, so every 5 ticks it checks for inventory changes), so is 0 a special case?

IIRC 0 is just every frame (i.e. triggers when tick==current_tick)?
Title: Re: DFHack 0.47.04-r2
Post by: Bumber on August 10, 2020, 01:24:41 pm
You can just do "event:getType()" as lua supports vmethods (even if it does not enumerate them when printing members).

Works, thanks!
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on August 10, 2020, 10:26:52 pm
1. dfhack.gui.getDepthAt(x, y) - This states that it "Returns the distance from the z-level of the tile at map coordinates (x, y) to the closest ground z-level below". I'm not really sure what it is tying to say, since it doesn't take a z level as an argument.
Like Warmist said, it's for TWBT. Maybe the docs should read "distance in z-levels" or something. Basically, it's supposed to take in x and y map coordinates, and calculate the number of z-levels you would need to move down to reach a solid tile. This only happens when TWBT or another plugin is enabled that implements this behavior, though. The default behavior (https://github.com/DFHack/dfhack/blob/0.47.04-r2/library/modules/Gui.cpp#L1834) is to always return 0.

Quote
3. dfhack.items.moveToBuilding(item,building[,use_mode[,force_in_building]) - When using force_in_building, should use_mode = 2? Is force_in_building temporary?
force_in_building is only used here (https://github.com/DFHack/dfhack/blob/0.47.04-r2/library/modules/Items.cpp#L1008). It looks to me like the opposite of what you said - if you want the item to be "in" the building, and don't set use_mode = 2, you'll need to set force_in_building = true. I'm not very familiar with why this behavior makes sense, though.

Quote
4. dfhack.buildings.checkFreeTiles(pos,size[,extents,change_extents,allow_occupied]) - What is the format for size?
From its definition (https://github.com/DFHack/dfhack/blob/0.47.04-r2/library/modules/Buildings.cpp#L575), it takes a df::coord2d. Not sure off the top of my head whether there's a shorthand, but passing in a table with "x" and "y" keys set might work.



How do I check the type of a block_events struct in Lua? I want the one of type df.block_square_event_type.frozen_liquid (if it exists for the block.)

I see the line <vmethod ret-type='block_square_event_type' name='getType'/> in df/structures, but I'm sure if I can call that in Lua.

Is there a proper way to do this, or should I just check for the existence of a "tiles" array (which only the frozen_liquid type seems to have?)
A couple other ways, in addition to what Warmist mentioned:
Code: [Select]
df.block_square_event_frozen_liquidst:is_instance(event)
event._type == df.block_square_event_frozen_liquidst

https://docs.dfhack.org/en/stable/docs/Lua%20API.html#struct-references mentions vmethod calls, by the way, although it is a very brief mention.

Quote
Found something odd in MapCache.cpp: (https://github.com/DFHack/dfhack/blob/f2b0f012c9895aa3fd743ad50fab9e6fb78b479d/library/modules/MapCache.cpp#L855)
<snip>

The checks for G_SOIL and G_STONE seem to be swapped. Is this a mistake or not?
At first glance, I think it's intentional. In the soil case, it looks up the material at the specified position. If it happens to actually be stone, instead of soil, then it tries to look up the default soil type, and uses that for the return value instead if it's available.
Are you seeing behavior that would suggest that this is incorrect, or did this just look surprising from a read-through?
Title: Re: DFHack 0.47.04-r2
Post by: Bumber on August 11, 2020, 06:36:00 pm
Are you seeing behavior that would suggest that this is incorrect, or did this just look surprising from a read-through?

Just stumbled across it while looking up how base tiles are calculated.
Title: Re: DFHack 0.47.04-r2
Post by: Silverwing235 on August 17, 2020, 08:08:50 am
Not quite the place to do this, I know, but could the  self-closing tag stuff (https://github.com/DFHack/dfhack/releases/tag/0.47.04-r2) be related to some of  the problems (http://www.bay12forums.com/smf/index.php?topic=154617.375) that have arisen, or not? *

(*Exhibit 2. (https://www.reddit.com/r/dwarffortress/comments/i9bh6c/biweekly_df_questions_thread/g1e1438/)) Edit: all solved - just getting rid of an error that spellcheck did not pick up, and got into my freaking marrow to roast it when gazed upon. 
Title: Re: DFHack 0.47.04-r2
Post by: PatrikLundell on August 17, 2020, 11:41:46 am
Not quite the place to do this, I know, but could the  self-closing tag stuff (https://github.com/DFHack/dfhack/releases/tag/0.47.04-r2) be related to some of  the problems (http://www.bay12forums.com/smf/index.php?topic=154617.375) that have arisen, or not? *

(*Exibit 2. (https://www.reddit.com/r/dwarffortress/comments/i9bh6c/biweekly_df_questions_thread/g1e1438/))
Legends Viewer hasn't been updated to parse things that export differently from before. The tool can handle a certain amount of things it can't recognize (according to my experience), but when the amount is too large it goes belly up. Changing types from boolean to tag present/absent is one of the things the tools does not recognize (it can be noted that Toady uses "self closing tags" in his standard exports, so the export-legends changes were made to use the same logic while also cutting down on the amount of useless fluff exported [all of those tags that were previously False are now simply not present]).
That change is in addition to things that is exported differently because the mapping of DF structures has progressed.

As far as I understand, Legends Viewer is a bit on the back burner because Real Life is making demands.
Title: Re: DFHack 0.47.04-r2
Post by: iii22 on August 17, 2020, 02:54:21 pm
I noticed that dfhack has a new "unretire-anyone" script. It sounds pretty crazy, since you could unretire necromancers or werebeast or something. Has anybody experimented with it?
Title: Re: DFHack 0.47.04-r2
Post by: Kromtec on August 18, 2020, 12:23:52 am
Not quite the place to do this, I know, but could the  self-closing tag stuff (https://github.com/DFHack/dfhack/releases/tag/0.47.04-r2) be related to some of  the problems (http://www.bay12forums.com/smf/index.php?topic=154617.375) that have arisen, or not? *

(*Exibit 2. (https://www.reddit.com/r/dwarffortress/comments/i9bh6c/biweekly_df_questions_thread/g1e1438/))
Legends Viewer hasn't been updated to parse things that export differently from before. The tool can handle a certain amount of things it can't recognize (according to my experience), but when the amount is too large it goes belly up. Changing types from boolean to tag present/absent is one of the things the tools does not recognize (it can be noted that Toady uses "self closing tags" in his standard exports, so the export-legends changes were made to use the same logic while also cutting down on the amount of useless fluff exported [all of those tags that were previously False are now simply not present]).
That change is in addition to things that is exported differently because the mapping of DF structures has progressed.

As far as I understand, Legends Viewer is a bit on the back burner because Real Life is making demands.
Haha, yeah I had a lot of things on my plate the last few month.
But I am currently working on making Legends Viewer compatible to the new changes in the exportlegends script.
Expect a new version this week.
Title: Re: DFHack 0.47.04-r2
Post by: Atomic Chicken on August 18, 2020, 02:51:09 am
I noticed that dfhack has a new "unretire-anyone" script. It sounds pretty crazy, since you could unretire necromancers or werebeast or something. Has anybody experimented with it?

I'm the author of that particular script, so I'd say I've experimented with it quite a bit. It enables you to play adventure mode as any living (or undead) historical figure with the exception of deities (as they currently lack physical manifestations). This includes necromancers, werewolves, fortress citizens, random villagers, nobles, important animals, forgotten beasts, various other monstrosities, and anyone else mentioned in Legends mode (as well as a number of unlisted individuals who wouldn't have done anything noteworthy yet). People will interact with you as appropriate, and you should have access to whatever powers and knowledge the figure possesses (as well as their limitations; it turns out that cats aren't very good at opening doors). That said, be aware that this won't give you a whole lot of additional functionality beyond that which the game normally provides; playing as a monarch, for example, won't enable you to do anything especially significant with your status at present.
Title: Re: DFHack 0.47.04-r2
Post by: Asendre on August 18, 2020, 01:24:41 pm
Hello!

Not sure if this is the right place to post this, but the plugin that allows you to load/save stockpile settings seems to have broken for me as of 47.04-r2.
Saving works fine, but attempting to load any settings crashes the entire game. I wasn't having this problem at all before (in the previous version), so it must be somehow related to the new version.

I'm not sure how to collect crash logs and whatnot from DFHack, but if anyone is interested in having a look at it i'll gladly follow instructions and share whatever can help fix the issue.
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on August 18, 2020, 07:31:07 pm
Thanks for the report - I was able to reproduce with a pretty simple stockpile, so I made an issue here (https://github.com/DFHack/dfhack/issues/1628) for it. It should be fixed in r3, which I hope will be within a couple weeks. I'll update this with whatever I find.

(To answer your other questions - the issue tracker, which is linked from the first post of this thread, is a better place, although it does require a GitHub account. When it comes to forum threads, this is definitely the appropriate thread to post something like this. There typically isn't a way to get much of a useful crash report in situations like this - on my end, I'm building the plugin with debug symbols and attaching a debugger to figure this out.)

Update: it was a pretty simple fix (https://github.com/DFHack/dfhack/commit/45a0b7b3a6cd45e96f6ab4a6547a6d947fc32204). There were a couple values recently added (https://github.com/DFHack/df-structures/commit/ecd6bcc9ed67c62fa605561b27574467df792342) to an enum, which were already present in DF, but this broke some code in the stockpiles plugin that assumed the size of this enum would never change. It looks like this issue just limited to loading stockpiles with any sort of food enabled - other types seem to be unaffected.

Once the build is done, you can extract a fixed plugin from the latest unstable build at https://dfhack.org/builds.
Title: Re: DFHack 0.47.04-r2
Post by: Rumrusher on August 18, 2020, 07:58:07 pm
I noticed that dfhack has a new "unretire-anyone" script. It sounds pretty crazy, since you could unretire necromancers or werebeast or something. Has anybody experimented with it?

I'm the author of that particular script, so I'd say I've experimented with it quite a bit. It enables you to play adventure mode as any living (or undead) historical figure with the exception of deities (as they currently lack physical manifestations). This includes necromancers, werewolves, fortress citizens, random villagers, nobles, important animals, forgotten beasts, various other monstrosities, and anyone else mentioned in Legends mode (as well as a number of unlisted individuals who wouldn't have done anything noteworthy yet). People will interact with you as appropriate, and you should have access to whatever powers and knowledge the figure possesses (as well as their limitations; it turns out that cats aren't very good at opening doors). That said, be aware that this won't give you a whole lot of additional functionality beyond that which the game normally provides; playing as a monarch, for example, won't enable you to do anything especially significant with your status at present.
you could probably get deities if you give them a nemesis id which just fully gives them a unit when they load in so with a few pokes and prods you could probably play as any historical figure in the game. which from what I can tell form testing legit gives them a body based off their historical figure descriptions.
which means a cat god will look like a cat, and a goblin god will look like a goblin.
Title: Re: DFHack 0.47.04-r2
Post by: Roses on August 19, 2020, 03:36:14 pm
Thanks all for the answers to my previous questions, I've got a couple new one now. Does ``dfhack.job.removeWorker(job,timeout)`` add a timeout to the worker stopping them from picking up the job again, or does it put the cooldown on the job, stopping all units from picking up the job again?
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on August 19, 2020, 04:05:36 pm
Thanks all for the answers to my previous questions, I've got a couple new one now. Does ``dfhack.job.removeWorker(job,timeout)`` add a timeout to the worker stopping them from picking up the job again, or does it put the cooldown on the job, stopping all units from picking up the job again?
It calls setJobCooldown (https://github.com/DFHack/dfhack/blob/0.47.04-r2/library/modules/Job.cpp#L277) internally, which either creates (https://github.com/DFHack/dfhack/blob/0.47.04-r2/library/modules/Job.cpp#L289-L292) or updates (https://github.com/DFHack/dfhack/blob/0.47.04-r2/library/modules/Job.cpp#L296-L297) an entry in job_claim_suppress. Looks like it prevents the unit from picking up a job at that workshop for the specified cooldown period. From the API docs (https://docs.dfhack.org/en/0.47.04-r2/docs/Lua%20API.html#job-module), I can see why it wouldn't be clear that removeWorker uses the same logic, so I'll update that.

(By the way, you can use [tt] on the forums to get preformatted text, like this)
Title: Re: DFHack 0.47.04-r2
Post by: Roses on August 19, 2020, 04:26:29 pm
Thanks all for the answers to my previous questions, I've got a couple new one now. Does ``dfhack.job.removeWorker(job,timeout)`` add a timeout to the worker stopping them from picking up the job again, or does it put the cooldown on the job, stopping all units from picking up the job again?
It calls setJobCooldown (https://github.com/DFHack/dfhack/blob/0.47.04-r2/library/modules/Job.cpp#L277) internally, which either creates (https://github.com/DFHack/dfhack/blob/0.47.04-r2/library/modules/Job.cpp#L289-L292) or updates (https://github.com/DFHack/dfhack/blob/0.47.04-r2/library/modules/Job.cpp#L296-L297) an entry in job_claim_suppress. Looks like it prevents the unit from picking up a job at that workshop for the specified cooldown period. From the API docs (https://docs.dfhack.org/en/0.47.04-r2/docs/Lua%20API.html#job-module), I can see why it wouldn't be clear that removeWorker uses the same logic, so I'll update that.

(By the way, you can use [tt] on the forums to get preformatted text, like this)

Thanks for the answer (and the tip!)

EDIT: Follow up question. I know I can use dfhack.matinfo.decode (or find, I always forget which one until I look it up) to turn something like INORGANIC:SLADE to the correct mat_type and mat_index. Is there something similar to change something like SHIELD:ITEM_SHIELD_BUCKLER into the correct item_type and item_subtype?

EDIT2: Follow up, follow up question. All of my old scripts that use dfhack.maps.spawnFlow require using an inorganic for flows. Is that an old requirement (I don't see it mentioned anywhere in the documents), or did I just randomly make that a thing?
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on August 19, 2020, 10:30:57 pm
This (https://github.com/DFHack/dfhack/blob/0.47.04-r2/library/modules/Items.cpp#L209) is what createitem uses (but it's written in C++). Looks like there are findType and findSubtype wrappers (https://github.com/DFHack/dfhack/blob/0.47.04-r2/library/LuaApi.cpp#L1753-L1765) available to Lua (e.g. dfhack.item.findType("SHIELD:ITEM_SHIELD_BUCKLER") == df.item_type.SHIELD) but they're not in the API docs. That should probably be addressed. Some of the docs aren't in sync with the Lua API, unfortunately, because they're manually-updated.

I don't see anything in spawnFlow (https://github.com/DFHack/dfhack/blob/0.47.04-r2/library/modules/Maps.cpp#L280) that requires inorganic materials, but I don't know what would happen if you used something else.
Title: Re: DFHack 0.47.04-r2
Post by: goldenvixen on August 25, 2020, 07:24:27 pm
I cannot for the life of me, get the exportlegends.lua to work properly on linux. It exports everything properly right up until we get to legends_plus xml in which it gets an error, saying simply "exportlegends: Could not move into the save folder." I'm guessing its something involving the feature of moving the legends into a folder instead of just plopping it in the dwarf fortress directory. I wish I could give more of an error report, but this is all I get when I export legends:

Spoiler (click to show/hide)
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on August 25, 2020, 09:33:44 pm
I cannot for the life of me, get the exportlegends.lua to work properly on linux. It exports everything properly right up until we get to legends_plus xml in which it gets an error, saying simply "exportlegends: Could not move into the save folder." I'm guessing its something involving the feature of moving the legends into a folder instead of just plopping it in the dwarf fortress directory. I wish I could give more of an error report, but this is all I get when I export legends:

Spoiler (click to show/hide)

My best guess is that this has something to do with permissions - can you run these two commands?
Code: [Select]
:lua print(dfhack.getDFPath())
:lua print(dfhack.filesystem.chdir(dfhack.getDFPath()))
The first should print the path to DF - you don't have to include its output if it contains anything personal, but try creating a file in that folder and see if you're able to.
The second should print either "true" or "false", and I'd like to know what it says.

The strange thing is that the code that's failing in this case has already run once, before the "Exporting:  World map/gen info" message, so I'm not sure why it would fail when run a second time.

Some other things to check would be whether you can create a new file in the "legends-region1-00150-01-01" folder, and whether you have any free disk space on whatever disk that folder is on.

You can also pass a directory as the second argument to exportlegends, so as a possible workaround, "exportlegends info ." should avoid changing directories at all. I'd still be interested in getting to the bottom of this, if you don't mind. I've been testing on Linux and have yet to reproduce this issue (with either "info" or "custom").
Title: Re: DFHack 0.47.04-r2
Post by: goldenvixen on August 26, 2020, 12:32:46 am
My best guess is that this has something to do with permissions - can you run these two commands?
Code: [Select]
:lua print(dfhack.getDFPath())
:lua print(dfhack.filesystem.chdir(dfhack.getDFPath()))
The first should print the path to DF - you don't have to include its output if it contains anything personal, but try creating a file in that folder and see if you're able to.
The second should print either "true" or "false", and I'd like to know what it says.

The strange thing is that the code that's failing in this case has already run once, before the "Exporting:  World map/gen info" message, so I'm not sure why it would fail when run a second time.

Some other things to check would be whether you can create a new file in the "legends-region1-00150-01-01" folder, and whether you have any free disk space on whatever disk that folder is on.

You can also pass a directory as the second argument to exportlegends, so as a possible workaround, "exportlegends info ." should avoid changing directories at all. I'd still be interested in getting to the bottom of this, if you don't mind. I've been testing on Linux and have yet to reproduce this issue (with either "info" or "custom").

I tried running both! Here's what I got:

Spoiler (click to show/hide)

I doubt it's a permission errors, I am able to create folders and files just fine within the directory and the "legends-region1-00150-01-01" folder. Space isn't the problem either, the hard drive currently has 114.7GiB of available space left. I keep my games and distro on separate hard drives if that helps in some way! I've been strictly using the "info" and I haven't tried custom yet. How exactly can I pass a directory as the second argument to exportlegends? It's currently very late over here and my mind is a blank on how to do that. lol
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on August 26, 2020, 06:50:30 pm
How exactly can I pass a directory as the second argument to exportlegends? It's currently very late over here and my mind is a blank on how to do that. lol

I gave an example, although it may have been hard to read with the quotes. Here it is again but with code formatting:
Code: [Select]
exportlegends info .
(the dot at the end is the second argument)

For more troubleshooting, can you try these commands?
Code: [Select]
:lua print(dfhack.filesystem.chdir("legends-region1-00150-01-01"))
:lua print(dfhack.filesystem.chdir(dfhack.getDFPath()))
You could run them a couple times, and each command should print "true", as long as you run them in this order. You should end with the last one to be safe - if you don't, you'll leave DF in a directory it doesn't expect, which will probably cause it to crash. (Maybe do this without a save loaded... it shouldn't make a difference, anyway.)
This is essentially what the script is doing when it prints the error message. If this doesn't print "false", I don't really have other ideas.
Title: Re: DFHack 0.47.04-r2
Post by: goldenvixen on August 27, 2020, 02:03:20 am
For more troubleshooting, can you try these commands?
Code: [Select]
:lua print(dfhack.filesystem.chdir("legends-region1-00150-01-01"))
:lua print(dfhack.filesystem.chdir(dfhack.getDFPath()))

Both came out as true!
I gave an example, although it may have been hard to read with the quotes. Here it is again but with code formatting:
Code: [Select]
exportlegends info .
(the dot at the end is the second argument)

This actually gave me an error list! Here it is:

Spoiler (click to show/hide)
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on August 27, 2020, 12:17:08 pm
For more troubleshooting, can you try these commands?
Code: [Select]
:lua print(dfhack.filesystem.chdir("legends-region1-00150-01-01"))
:lua print(dfhack.filesystem.chdir(dfhack.getDFPath()))

Both came out as true!
Weird. Even when you run them more than once? I have no idea why exportlegends could be failing, let alone reliably.

I made some tweaks to the script to try to narrow this down. Here (https://github.com/lethosor/scripts/blob/exportlegends-chdir-debug/exportlegends.lua) is a version that you can download and replace your hack/scripts/exportlegends.lua with (direct link to download (https://raw.githubusercontent.com/lethosor/scripts/exportlegends-chdir-debug/exportlegends.lua)). Try running "exportlegends info" (no second argument) afterwards, and it should print some extra debugging information (lines including "entering:").

Quote
This actually gave me an error list! Here it is:

Spoiler (click to show/hide)
This one also doesn't make sense, although it's an unrelated error. abstract_building_templest has a deity_type field in both DFHack 0.47.04-r1 and r2 (I checked the release builds of both).
How did you obtain DFHack? What version of DFHack are you using (run "help" if you don't know)?
Can you try running the following command (it should print -1)?
Code: [Select]
:lua print(df.abstract_building_templest:new().deity_type)
Title: Re: DFHack 0.47.04-r2
Post by: Vantezzle on August 27, 2020, 06:38:20 pm
My Bitdefender keeps deleting my dfhack-run.exe saying that it contains a Trojan.GenericKD.34432417...Should I worry?
Title: Re: DFHack 0.47.04-r2
Post by: goldenvixen on August 27, 2020, 06:57:21 pm
This one also doesn't make sense, although it's an unrelated error. abstract_building_templest has a deity_type field in both DFHack 0.47.04-r1 and r2 (I checked the release builds of both).
How did you obtain DFHack? What version of DFHack are you using (run "help" if you don't know)?
Can you try running the following command (it should print -1)?
Code: [Select]
:lua print(df.abstract_building_templest:new().deity_type)

Good news! I finally got it to work and it was thanks to this post that I got that idea that maybe there was something buggy with the LNP version I was using. The dfhack version I was using was from this (https://dffd.bay12games.com/file.php?id=14911) LNP pack and the version number the dfhack gave me was 0.47.04-alpha0. I bit behind, but the exportlegends.lua that came with the game would not work, and I used the most recent version of the lua off the github in hopes it would work and as you could see--It was giving me a bunch of issues. At first I attempted to upgrade the dfhack manually but could not find a linux version of TWBT that supports the newest version of dfhack, so I reverted back to the alpha0. However, I recently discovered that the LNP for linux has a github itself and there, it has a much more newer release than dffd.bay12games.com had. I downloaded, extracted it and started it up and exportlegends.lua now works perfectly. No crashes what so ever and legends_plus is able to generate. I gotta admit, it's pretty satisfying when something starts working after you spend a few days head scratching and wondering what's wrong. I am so sorry about the extra work that had to be put in this when the solution ended up being pretty simple. Would you like me to trouble shoot for the version I was using still? Or should we call this case closed?

My Bitdefender keeps deleting my dfhack-run.exe saying that it contains a Trojan.GenericKD.34432417...Should I worry?

I would make an exception in my antivirus so that it would stop deleting dfhack. Most antiviruses probably don't like applications like dfhack because it links up with the game and runs it's own scripts. So long as you downloaded dfhack straight from the source or from a LNP pack, it should be safe to use.
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on August 27, 2020, 07:21:09 pm
Ah, yeah, all of those issues were related to things that changed between alpha0 and r2, so no need to troubleshoot further if it works in r2. No worries.

My Bitdefender keeps deleting my dfhack-run.exe saying that it contains a Trojan.GenericKD.34432417...Should I worry?
Probably not, although if you're not downloading from https://github.com/dfhack/dfhack/releases, you could download a copy from there and check that its dfhack-run.exe matches yours.
It's interesting that dfhack-run.exe would be flagged, of all things. All it does is allow you to run commands by connecting to DFHack over the local network. You don't strictly need it for DFHack to work, unless you want that feature, so it's up to you whether you decide to keep it.
Title: Re: DFHack 0.47.04-r2
Post by: Schmaven on August 27, 2020, 07:38:00 pm
Does that mean you could have a DFHack console running on one computer, working with Dwarf Fortress running on another computer?
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on August 27, 2020, 08:24:42 pm
Does that mean you could have a DFHack console running on one computer, working with Dwarf Fortress running on another computer?
Sort of, although it wouldn't exactly be the DFHack console - dfhack-run needs to be run from a system command prompt, only runs one command at a time, and doesn't support interactive commands (like tiletypes, lua, liquids, etc. with no arguments).
Also, I probably should have clarified that by "local network" I meant local to your computer, so other computers can't connect, at least by default. You can configure (https://docs.dfhack.org/en/0.47.04-r2/docs/Remote.html#server-configuration) DFHack to allow other machines to connect to it remotely, but I don't think dfhack-run can currently connect to other machines (other clients like Armok Vision do support that, though).
Title: Re: DFHack 0.47.04-r2
Post by: Rose on August 27, 2020, 09:11:38 pm
DFHack-run and the interface it uses very specifically do not allow you to run it over a network, because it would mean that, theoretically, somebody could use it to write to any memory on your computer. The other interfaces have some limitations, at least, but dfhack-run allows you to just run any command supported by DFHack, including random memory writes if you know what you're doing, so it's specifically disallowed from remote access.
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on August 27, 2020, 10:10:24 pm
Oh, right. There's a flag that remote methods have to set to allow remote machines to call them, and it's disabled by default, as it should be for dfhack-run. (And you added that feature, so it makes sense that you would know better than I would.)
Title: Re: DFHack 0.47.04-r2
Post by: Vantezzle on August 27, 2020, 11:40:30 pm
Ah, yeah, all of those issues were related to things that changed between alpha0 and r2, so no need to troubleshoot further if it works in r2. No worries.

My Bitdefender keeps deleting my dfhack-run.exe saying that it contains a Trojan.GenericKD.34432417...Should I worry?
Probably not, although if you're not downloading from https://github.com/dfhack/dfhack/releases, you could download a copy from there and check that its dfhack-run.exe matches yours.
It's interesting that dfhack-run.exe would be flagged, of all things. All it does is allow you to run commands by connecting to DFHack over the local network. You don't strictly need it for DFHack to work, unless you want that feature, so it's up to you whether you decide to keep it.
Both the one from LNP and from your link get flagged.
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on August 27, 2020, 11:48:04 pm
The one from GitHub was built automatically, so I'm pretty confident that it hasn't been tampered with. But use your best judgement. If it helps, this isn't the first false positive we've had reported, but the majority of users seem to not run into any. (I was suggesting that you check that the file you have is identical to the one from GitHub, not just whether both of them get flagged.)
Title: Re: DFHack 0.47.04-r2
Post by: Vantezzle on August 28, 2020, 07:44:05 am
The one from GitHub was built automatically, so I'm pretty confident that it hasn't been tampered with. But use your best judgement. If it helps, this isn't the first false positive we've had reported, but the majority of users seem to not run into any. (I was suggesting that you check that the file you have is identical to the one from GitHub, not just whether both of them get flagged.)
Admittedly I'm not entirely sure how to check that, but out of curiousity I downloaded the github zip on my two old laptops, one with Bitdefender, another with Windows Defender and they both flagged it.
I first downloaded LNP last Sunday and everything was fine until yesterday.
Title: Re: DFHack 0.47.04-r2
Post by: Putnam on August 30, 2020, 10:42:48 am
It's not too surprising, since DFHack does do everything a virus does. In a sense it is a literal trojan horse: it impersonates another piece of code (SDL.dll) for its own nefarious purposes (modifying working memory... of a video game, to be fair)
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on August 30, 2020, 11:09:10 am
It's not too surprising, since DFHack does do everything a virus does. In a sense it is a literal trojan horse: it impersonates another piece of code (SDL.dll) for its own nefarious purposes (modifying working memory... of a video game, to be fair)
Right, the surprising part is that (only?) dfhack-run was flagged, which doesn't do that.

Admittedly I'm not entirely sure how to check that, but out of curiousity I downloaded the github zip on my two old laptops, one with Bitdefender, another with Windows Defender and they both flagged it.
I first downloaded LNP last Sunday and everything was fine until yesterday.
You could check the hash of both files or use some file-comparison tool.
I suspect that your anti-virus definitions got updated recently and triggered this, which can happen pretty often depending on the software you're using. Redownloading like you did is probably the best way to ensure that something didn't actually change the file itself.
Title: Re: DFHack 0.47.04-r2
Post by: Arson on August 31, 2020, 04:57:24 am
Hey there folks. Just curious if there is a way to utilize the buildingplan plug so that every time I close DF it saves the parameters. Every time I open the game I have to reset all the build-able items and their materials, etc.

Using: DFHack 0.47.04-r2



Thanks in advance!
Title: Re: DFHack 0.47.04-r2
Post by: Vantezzle on August 31, 2020, 08:41:51 am
It's not too surprising, since DFHack does do everything a virus does. In a sense it is a literal trojan horse: it impersonates another piece of code (SDL.dll) for its own nefarious purposes (modifying working memory... of a video game, to be fair)
Right, the surprising part is that (only?) dfhack-run was flagged, which doesn't do that.

Admittedly I'm not entirely sure how to check that, but out of curiousity I downloaded the github zip on my two old laptops, one with Bitdefender, another with Windows Defender and they both flagged it.
I first downloaded LNP last Sunday and everything was fine until yesterday.
You could check the hash of both files or use some file-comparison tool.
I suspect that your anti-virus definitions got updated recently and triggered this, which can happen pretty often depending on the software you're using. Redownloading like you did is probably the best way to ensure that something didn't actually change the file itself.

Yeah the hash matches.
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on August 31, 2020, 06:16:04 pm
Hey there folks. Just curious if there is a way to utilize the buildingplan plug so that every time I close DF it saves the parameters. Every time I open the game I have to reset all the build-able items and their materials, etc.
That's currently not supported, at least as far as I know (most plugins don't support this). It may be worth putting up a feature request for it on the issue tracker (https://github.com/dfhack/dfhack/issues) if it would be a good feature to have. I'd be happy to help anyone interested in working on this, although I may not have a lot of time for it myself in the near future. There have been some (sort of) recent persistent storage changes that might make things like this easier, although part of it also depends on how complicated the buildingplan settings are to save/load.
Title: Re: DFHack 0.47.04-r2
Post by: myk on September 01, 2020, 02:45:54 pm
Another/additional option for persisting buildingplan filters could be to use json-based export/import like the orders plugin. Not quite as automatic as persistent data (unless we auto-export on save and auto-import on load), but more useful for copying across forts.

I do have some dev tasks for buildingplan on my short list for quickfort integration:
If filter persistence is still unimplemented when I'm done with that, I could look into implementing it.

Might be a while, though. There might be a raft of bug reports for quickfort when it goes out in the next release that I'll need to focus on.
Title: Re: DFHack 0.47.04-r2
Post by: Roses on September 03, 2020, 11:47:12 am
Another/additional option for persisting buildingplan filters could be to use json-based export/import like the orders plugin. Not quite as automatic as persistent data (unless we auto-export on save and auto-import on load), but more useful for copying across forts.

I do have some dev tasks for buildingplan on my short list for quickfort integration:
  • respect item filters that are passed in from the api
  • support all teh buildings (starting with constructions)
If filter persistence is still unimplemented when I'm done with that, I could look into implementing it.

Might be a while, though. There might be a raft of bug reports for quickfort when it goes out in the next release that I'll need to focus on.

It's fairly easy to auto-save/auto-load json files using the import/export stuff. Depending on how the data for the plugin is stored it may only be a few lines of code.
Title: Re: DFHack 0.47.04-r2
Post by: Arson on September 03, 2020, 04:05:40 pm
Another/additional option for persisting buildingplan filters could be to use json-based export/import like the orders plugin. Not quite as automatic as persistent data (unless we auto-export on save and auto-import on load), but more useful for copying across forts.

I do have some dev tasks for buildingplan on my short list for quickfort integration:
  • respect item filters that are passed in from the api
  • support all teh buildings (starting with constructions)
If filter persistence is still unimplemented when I'm done with that, I could look into implementing it.

Might be a while, though. There might be a raft of bug reports for quickfort when it goes out in the next release that I'll need to focus on.

It's fairly easy to auto-save/auto-load json files using the import/export stuff. Depending on how the data for the plugin is stored it may only be a few lines of code.

Thanks to everyone for answering. I'm afraid any coding portion it outside my realm of knowledge though.
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on September 03, 2020, 04:46:35 pm
It's fairly easy to auto-save/auto-load json files using the import/export stuff. Depending on how the data for the plugin is stored it may only be a few lines of code.

Are you talking about Lua-side persistent tables? Unfortunately it's not nearly as trivial in C++, because C++ types can't be serialized by default - plugins have to serialize their own data manually, which is why a lot of them don't. For example, here (https://github.com/DFHack/dfhack/blob/8728056674c7249f1a15f80c62e3ded16507bb56/plugins/autochop.cpp#L196-L231) is what autochop does to save/load its config. Granted, it still uses the old histfig-based system, which is now a wrapper around the new JSON-based system - the new system would result in code that's a bit more readable, but just as verbose.
Title: Re: DFHack 0.47.04-r2
Post by: Roses on September 04, 2020, 09:16:58 am
It's fairly easy to auto-save/auto-load json files using the import/export stuff. Depending on how the data for the plugin is stored it may only be a few lines of code.

Are you talking about Lua-side persistent tables? Unfortunately it's not nearly as trivial in C++, because C++ types can't be serialized by default - plugins have to serialize their own data manually, which is why a lot of them don't. For example, here (https://github.com/DFHack/dfhack/blob/8728056674c7249f1a15f80c62e3ded16507bb56/plugins/autochop.cpp#L196-L231) is what autochop does to save/load its config. Granted, it still uses the old histfig-based system, which is now a wrapper around the new JSON-based system - the new system would result in code that's a bit more readable, but just as verbose.

I was thinking lua side json.decode_file stuff, but didn't realize we were talking about a plugin.
Title: Re: DFHack 0.47.04-r2
Post by: myk on September 06, 2020, 04:44:13 pm
After reading through the buildingplan code, it looks like there is already support for serializing ItemFilters to persistent storage, which is cool. The problem is that the item filter state is directly accessible and mutable, which means that we won't know when it changes and needs copying into persistent storage.

I'm planning on reworking the buildingplan API to remove "abstraction leaks" like this. Once the API is solidified, I think persisting the ItemFilter settings will be very doable.
Title: Re: DFHack 0.47.04-r2
Post by: myk on September 17, 2020, 08:57:10 pm
As I refactor buildingplan and get it in shape to handle the remaining building types for quickfort, I noticed that it is inconsistent with how it handles artifacts. It allows the filters to accept artifacts, and you can even set them to accept *only* artifacts, but when it scans for available items it filters artifacts out so they can never be matched.

Unless there are any objections, I'm thinking of changing this so that artifacts can be properly matched, but the default quality settings allow only ordinary though masterwork. If you want to match artifacts, you would have to manually increase the quality filter to include them.
Title: Re: DFHack 0.47.04-r2
Post by: nezclaw on September 20, 2020, 09:34:03 pm
hey uh sorry to sound like a n00b but i was trying to install dfhack to go with the most recent version of the game instead of downloading the LNP since the most recent DF version is updated when i do a system update and i didn't see a point in downloading another copy via the pack. i think i installed it properly, but when i run it it only gives me the builtin commands and no scripts or plugins.
Spoiler (click to show/hide)
the stderr.log
i'm running arch linux (which i didn't set up my brother did, he's more computer savvy than i am)
Title: Re: DFHack 0.47.04-r2
Post by: Ziusudra on September 20, 2020, 11:13:20 pm
hey uh sorry to sound like a n00b but i was trying to install dfhack to go with the most recent version of the game instead of downloading the LNP since the most recent DF version is updated when i do a system update and i didn't see a point in downloading another copy via the pack. i think i installed it properly, but when i run it it only gives me the builtin commands and no scripts or plugins.
Spoiler (click to show/hide)
the stderr.log
i'm running arch linux (which i didn't set up my brother did, he's more computer savvy than i am)
Did you install dfhack manually? Or did you use an AUR package (https://aur.archlinux.org/packages/?O=0&K=dfhack)?
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on September 20, 2020, 11:37:59 pm
I'm guessing you used a package - the output in stderr.log appears to indicate that you don't have any plugins (since it would log a message for every plugin that's loaded). This is probably due to some parts of DFHack being installed in the wrong place relative to other parts. It will be tricky to troubleshoot, though, since the interactive "lua" interpreter is itself a Lua script, and I suspect those are installed in the wrong place as well. I should also be clear that this isn't necessarily your fault - we made a change in 0.47.04-r2 that changes the way DFHack computes the DF root path on Linux, sometimes. In a fresh install with vanilla DF, the behavior should be the same as in previous versions, but maybe it breaks a package.

Can you locate the path to libdfhack.so? By default, it should be in a "hack" folder, which should have subfolders named "plugins" and "scripts".
Title: Re: DFHack 0.47.04-r2
Post by: nezclaw on September 21, 2020, 02:21:27 pm
i installed it manually, i didn't feel like running a -Syu yet. i can find libdfhack.so, and the scripts and plugins folders have things in them.
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on September 21, 2020, 05:41:33 pm
i installed it manually, i didn't feel like running a -Syu yet. i can find libdfhack.so, and the scripts and plugins folders have things in them.
Ok, thanks, disregard my speculation in my earlier post. I probably should have asked "is libdfhack.so in the hack folder", although I think that's what you meant.

Can you verify that you're the owner of everything in the hack/plugins folder and that the read and execute permissions are enabled? e.g. with "ls -l hack/plugins"

If that doesn't help, just to get an idea of what your installation looks like, can you run this command in your DF folder and upload its output somewhere? Make sure it has some lines starting with "./hack" first. It may be large, so a site like Pastebin would probably be a better choice than pasting it directly in a reply.
Code: [Select]
find . -path ./data/save -prune -or -print


Title: Re: DFHack 0.47.04-r2
Post by: Ziusudra on September 21, 2020, 06:38:28 pm
i installed it manually, i didn't feel like running a -Syu yet. i can find libdfhack.so, and the scripts and plugins folders have things in them.
Installing things manually on Arch is usually a bad idea especially with DF being installed as a package. The DF package installs things to /opt/dwarffortess and includes a script to make sure everthing is linked in ~/.dwarffortress and that the game is run with the correct working directory. The dfhack package works the same way and makes sure dfhack can find all its and DF's files.
Title: Re: DFHack 0.47.04-r2
Post by: nezclaw on September 21, 2020, 07:10:07 pm
i installed it manually, i didn't feel like running a -Syu yet. i can find libdfhack.so, and the scripts and plugins folders have things in them.
Installing things manually on Arch is usually a bad idea especially with DF being installed as a package. The DF package installs things to /opt/dwarffortess and includes a script to make sure everthing is linked in ~/.dwarffortress and that the game is run with the correct working directory. The dfhack package works the same way and makes sure dfhack can find all its and DF's files.
yeah, i figured it was gonna be something like that. i'll run a -Syu when mom goes to bed and grab it that way. (our internet is Not Great)
Title: Re: DFHack 0.47.04-r2
Post by: nezclaw on September 21, 2020, 07:19:25 pm
https://pastebin.com/Y4w5q6Hm (https://pastebin.com/Y4w5q6Hm) there you go.
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on September 21, 2020, 11:17:20 pm
Oh, I didn't realize you had installed DF as a package - I figured it was also installed manually. Yeah, mixing the two approaches is generally not a good idea (I should have realized when you mentioned that your system updates DF, but I guess I assumed you would have installed DF separately too). Thanks for catching that, Ziusudra! If there's an easy way for me to get my hands on the launcher script that the Arch package uses, I'll try to make DFHack give a better error when this sort of thing happens.
Title: Re: DFHack 0.47.04-r2
Post by: Ziusudra on September 21, 2020, 11:48:00 pm
For DF https://github.com/archlinux/svntogit-community/tree/packages/dwarffortress/trunk

For dfhack https://aur.archlinux.org/cgit/aur.git/tree/?h=dfhack
Title: Re: DFHack 0.47.04-r2
Post by: nezclaw on September 22, 2020, 12:17:40 am
it's giving me 'target not found' when i try to install dfhack as a package ugh i'll have to bother my brother about it tomorrow. i should probably change my OS to something less complicated but idk how to do that either so ::)
Title: Re: DFHack 0.47.04-r2
Post by: Ziusudra on September 22, 2020, 01:12:07 am
it's giving me 'target not found' when i try to install dfhack as a package ugh i'll have to bother my brother about it tomorrow. i should probably change my OS to something less complicated but idk how to do that either so ::)
Yeah, dfhack is in the AUR (https://wiki.archlinux.org/index.php/Arch_User_Repository), not the official repositories. Another option is to install DF manually (https://dwarffortresswiki.org/index.php/DF2014:Installation#Manual_or_multiple_installations) to a directory in your home directory and install dfhack to there.
Title: Re: DFHack 0.47.04-r2
Post by: nezclaw on September 22, 2020, 04:09:36 pm
it's giving me 'target not found' when i try to install dfhack as a package ugh i'll have to bother my brother about it tomorrow. i should probably change my OS to something less complicated but idk how to do that either so ::)
Yeah, dfhack is in the AUR (https://wiki.archlinux.org/index.php/Arch_User_Repository), not the official repositories. Another option is to install DF manually (https://dwarffortresswiki.org/index.php/DF2014:Installation#Manual_or_multiple_installations) to a directory in your home directory and install dfhack to there.
at that point i'd be better off just installing the latest LNP
Title: Re: DFHack 0.47.04-r2
Post by: joostheger on September 25, 2020, 06:16:39 am
I noticed that dfhack has a new "unretire-anyone" script. It sounds pretty crazy, since you could unretire necromancers or werebeast or something. Has anybody experimented with it?

I'm the author of that particular script, so I'd say I've experimented with it quite a bit. It enables you to play adventure mode as any living (or undead) historical figure with the exception of deities (as they currently lack physical manifestations). This includes necromancers, werewolves, fortress citizens, random villagers, nobles, important animals, forgotten beasts, various other monstrosities, and anyone else mentioned in Legends mode (as well as a number of unlisted individuals who wouldn't have done anything noteworthy yet). People will interact with you as appropriate, and you should have access to whatever powers and knowledge the figure possesses (as well as their limitations; it turns out that cats aren't very good at opening doors). That said, be aware that this won't give you a whole lot of additional functionality beyond that which the game normally provides; playing as a monarch, for example, won't enable you to do anything especially significant with your status at present.
you could probably get deities if you give them a nemesis id which just fully gives them a unit when they load in so with a few pokes and prods you could probably play as any historical figure in the game. which from what I can tell form testing legit gives them a body based off their historical figure descriptions.
which means a cat god will look like a cat, and a goblin god will look like a goblin.

Can you play as a ghost or reanimated person?
Title: Re: DFHack 0.47.04-r2
Post by: Atomic Chicken on September 25, 2020, 07:25:24 am
Can you play as a ghost or reanimated person?

Yeah, I believe I had tested both ghosts and undead at some point (in fact, I distinctly recall fixing the way their names are displayed on the selection list), but it's been a while now. It should be possible so long as such a person exists as a historical figure in your world. I don't think that ghosts manifest during world generation, so you'd probably need to produce one during fortress mode first.

It's also possible to turn any adventurer into a ghost via the "ghostly" command, in case you're not aware of it.

Note that there's currently an issue with attempting to fly as a ghostly non-flying creature, whereby your adventurer gets stuck in mid-air, unable to be controlled.
Title: Re: DFHack 0.47.04-r2
Post by: Rumrusher on September 26, 2020, 01:29:34 am
Can you play as a ghost or reanimated person?

Yeah, I believe I had tested both ghosts and undead at some point (in fact, I distinctly recall fixing the way their names are displayed on the selection list), but it's been a while now. It should be possible so long as such a person exists as a historical figure in your world. I don't think that ghosts manifest during world generation, so you'd probably need to produce one during fortress mode first.

It's also possible to turn any adventurer into a ghost via the "ghostly" command, in case you're not aware of it.

Note that there's currently an issue with attempting to fly as a ghostly non-flying creature, whereby your adventurer gets stuck in mid-air, unable to be controlled.

which can be solved by toggling the flier enemy caste flag on the adventurer
so making a script to flip on ghostly would pretty much require toggling that on and off if you want ghost flight to not soft lock you.

edit: hmm got an idea on an adventure mode script that takes the currency that players would get from starting a new game and converting it into points for when they retire. would require writing a script that changes the point value for character creation, and probably have a function that fills up the equipment and pet page.
thinking about this more and it's probably more possible to convert the inventory into the equipment screen and see if you can sell them for points.


edit: ok so I poke around the big deal with animal token visitors not having any labors and it seems to be the entity links for the creature historical figure is missing a few bits of data that the other normal citizens have.

like the animal token acquired units are just citizens of a site but not members of the group or members of the entity so the solution to fix that with dfhack would just be giving them entity links tied to the main fort's civ... or copy and paste some other fort resident's entity links over to the one that doesn't have them.

this discovery at least means one could make a script that gives labors to those who don't have them.


Code: ('animaltokencivpatch.lua') [Select]
for k,v in pairs(df.global.world.units.active) do
local HF=df.global.world.history.figures
if v.hist_figure_id==-1 then break else
for c,q in pairs(HF[v.hist_figure_id].entity_links) do
if q.entity_id==df.global.ui.civ_id and v.population_id==-1 and q.entity_id~=df.global.ui.group_id then
print(v.hist_figure_id)
HF[v.hist_figure_id].entity_links:insert("#",{new=df.histfig_entity_link_memberst})
HF[v.hist_figure_id].entity_links[c].entity_id=df.global.ui.group_id
HF[v.hist_figure_id].entity_links[c].link_strength=100
end
end
end
end
--this script should add labors to different race migrants that arrived from animal token entity modding

edit: I realize a major flaw with this script... it works on migrants that got historical figures, but if they don't have any this doesn't work.
Title: Re: DFHack 0.47.04-r2
Post by: PatrikLundell on October 01, 2020, 11:24:05 am
Script to detect equipment corruption, attempting to fix equipment that's not assigned.

Spoiler (click to show/hide)

Based on Toady's answer in FotF, but the script's testing has been limited to verifying that a corrupt entry doesn't reappear.
Note that the script doesn't try to fix corrupt assigned equipment I've seen that in a save), as that likely requires additional handling to deal with the unit to which the equipment has been assigned.
Title: Re: DFHack 0.47.04-r2
Post by: Roses on October 01, 2020, 01:36:58 pm
So here is a question I thought of recently. How difficult would it be to create fake entries for the built-in buildings and reactions? What I mean is, the custom building information can be accessed like;
Code: [Select]
[lua]# ~df.global.world.raws.buildings.all[0]
<building_def_workshopst: 0000025F649D4010>
code                     = SOAP_MAKER
id                       = 0
name                     = Soap Maker's Workshop
building_type            = 13
building_subtype         = 23
name_color               = <int16_t[]: 0000025F649D4068>
tile                     = <uint8_t[31][31][]: 0000025F649D406E>
tile_color               = <uint8_t[31][31][4][]: 0000025F649D4F72>
tile_block               = <uint8_t[31][]: 0000025F649D7C7E>
build_key                = 150
needs_magma              = false
build_items              = <vector<building_def_item*>[2]: 0000025F649D8048>
dim_x                    = 3
dim_y                    = 3
workloc_x                = 1
workloc_y                = 1
build_labors             = <vector<unit_labor>[1]: 0000025F649D8070>
labor_description        = Soap Making
build_stages             = 3

but there isn't a similar structure for the Leatherworker. It would be great if there was a way to access the information for the built-in stuff the same way I can with the custom ones. I know they would need to be hand built, but I'm just wondering if it would even be possible, and if possible how much work it would be.
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on October 01, 2020, 03:02:48 pm
Script to detect equipment corruption, attempting to fix equipment that's not assigned.
...
Based on Toady's answer in FotF, but the script's testing has been limited to verifying that a corrupt entry doesn't reappear.
Note that the script doesn't try to fix corrupt assigned equipment I've seen that in a save), as that likely requires additional handling to deal with the unit to which the equipment has been assigned.
I'd say it's worth including, maybe under "devel/" if it doesn't actually fix things, or under "fix/" if it does.

Note that your loops that are erasing items from vectors have a bug that will skip consecutive items (e.g. erasing item 3 will move item 4 into item 3's spot, causing it to be skipped by the loop, even if it should be erased). Some scripts deal with this by iterating over vectors in reverse order - not sure if there's a utility function to do this.

So here is a question I thought of recently. How difficult would it be to create fake entries for the built-in buildings and reactions? What I mean is, the custom building information can be accessed like;
...
but there isn't a similar structure for the Leatherworker. It would be great if there was a way to access the information for the built-in stuff the same way I can with the custom ones. I know they would need to be hand built, but I'm just wondering if it would even be possible, and if possible how much work it would be.
You're referring to the craftdwarf's workshop (https://dwarffortresswiki.org/index.php/DF2014:Craftsdwarf%27s_workshop) in this case, right?
You should be able to create a building_def_workshopst instance with "df.building_def_workshopst:new()" and assign its fields to whatever values you want; putting this instance in world.raws.buildings.all will likely cause all sorts of issues, though. Figuring out the right values for every field could also be hard. I know Quietust has reverse-engineered raws for some built-in materials, like amber (https://dwarffortresswiki.org/index.php/DF2014:Amber), but not workshops to my knowledge. Maybe you could get some of the right values from a built workshop, but other than that, I'm not sure.

Is there anything in particular that you need this information for? There may be another way to get at the relevant portions of it.
Title: Re: DFHack 0.47.04-r2
Post by: Roses on October 01, 2020, 03:23:47 pm
So here is a question I thought of recently. How difficult would it be to create fake entries for the built-in buildings and reactions? What I mean is, the custom building information can be accessed like;
...
but there isn't a similar structure for the Leatherworker. It would be great if there was a way to access the information for the built-in stuff the same way I can with the custom ones. I know they would need to be hand built, but I'm just wondering if it would even be possible, and if possible how much work it would be.
You're referring to the craftdwarf's workshop (https://dwarffortresswiki.org/index.php/DF2014:Craftsdwarf%27s_workshop) in this case, right?
You should be able to create a building_def_workshopst instance with "df.building_def_workshopst:new()" and assign its fields to whatever values you want; putting this instance in world.raws.buildings.all will likely cause all sorts of issues, though. Figuring out the right values for every field could also be hard. I know Quietust has reverse-engineered raws for some built-in materials, like amber (https://dwarffortresswiki.org/index.php/DF2014:Amber), but not workshops to my knowledge. Maybe you could get some of the right values from a built workshop, but other than that, I'm not sure.

Is there anything in particular that you need this information for? There may be another way to get at the relevant portions of it.

Yes, that is one of the built-in buildings I would like to be able to create an entry for. Just creating a building_def_workshopst instance would be more than enough, I wouldn't need them to the in the world.raws.buildings.all. This is more of a "would be nice to have" type QoL thing than anything else. Right now I just have scripts that check for custom vs. built-in buildings/reactions and then does different stuff for them. Having these structures would just simplify that, but it sounds basically how I expected it to be, possible but hard.

It is kind of strange though, you would think that the built-in buildings/reactions/materials etc... would still need to have a similar structure to the custom ones that the game accesses. I guess they are probably just stored in a different area that isn't mapped or isn't accessible.
Title: Re: DFHack 0.47.04-r2
Post by: PatrikLundell on October 01, 2020, 03:28:55 pm
Yes, I was aware that there was a risk of the iterator skipping elements, but decided to get something out there quickly rather than polishing it.
Iterating in reverse isn't hard to do, so that will be a task for tomorrow.

I've verified that removing a bugged entry from an unassigned list caused the list to remain clean a month or so later, but since my test save originally took quite some time to crash it's a bit tricky to say when it's fine and won't crash.

Dealing with corrupted assigned equipment would require a fair bit of investigation, I think, as it would have to find and remove all references from both directions, of which I guess you'd always have squad (somewhere in the structures, but I don't know where) for military equipment and usually soldier, while civilian uniforms (if they can get corrupted) always would have the dorf, but are there anything else that would need to be dealt with?
Title: Re: DFHack 0.47.04-r2
Post by: lethosor on October 01, 2020, 07:39:59 pm
It is kind of strange though, you would think that the built-in buildings/reactions/materials etc... would still need to have a similar structure to the custom ones that the game accesses. I guess they are probably just stored in a different area that isn't mapped or isn't accessible.
It's possible that they're stored somewhere else that isn't mapped - if we know enough values, I could probably come up with a script to search for a matching building_def_workshopst instance somewhere in memory.
It's also possible that built-in workshop definitions are stored in a completely different format, or their fields' values are hardcoded wherever the corresponding fields of custom workshops are looked up.
Title: Re: DFHack 0.47.04-r2
Post by: Quietust on October 01, 2020, 08:20:41 pm
It is kind of strange though, you would think that the built-in buildings/reactions/materials etc... would still need to have a similar structure to the custom ones that the game accesses. I guess they are probably just stored in a different area that isn't mapped or isn't accessible.
It's possible that they're stored somewhere else that isn't mapped - if we know enough values, I could probably come up with a script to search for a matching building_def_workshopst instance somewhere in memory.
It's also possible that built-in workshop definitions are stored in a completely different format, or their fields' values are hardcoded wherever the corresponding fields of custom workshops are looked up.
Builtin workshops populate the "Add Job" menu using the buildingst::fillSidebarMenu() vmethod, which creates instances of various interface_button_buildingst subclasses and inserts them into ui_sidebar_menus.workshop_job.choices_all[]. Exactly which jobs are added depends on the workshop/furnace's subtype, and some workshops don't add anything because their UI is 100% hardcoded (and they typically don't permit custom reactions either).

I actually took advantage of this (https://github.com/quietust/dfhack-23a/blob/master/plugins/more_jobs.cpp) in my DFHack backport for version 0.23.130.23a to add the ability to craft wooden blocks and trap components, glass trap components, and metal mechanisms.
Title: Re: DFHack 0.47.04-r2
Post by: PatrikLundell on October 02, 2020, 05:14:38 am
An improved version of fix_equipment:

Spoiler (click to show/hide)

I haven't found any links between corrupt items in the "assigned" list and squad members, so it seems safe to remove the corrupted "assigned" entries. I've also tried to check for equipment assigned to squad members that are not in the list, but there's a lot of that even in an uncorrupted save, so that's probably intentional.
The latter part of the script looks for anomalies in the equipment actually assigned to squads, but neither of those checks have triggered in my experiments with corrupted saves, so it's likely those cases won't happen.
I haven't been able to verify that the script actually stops crashing from occurring, because the saves I've tried take too long to crash without intervention (10+ minutes), and thus would have to be checked for an even longer time after using the script.
Title: Re: DFHack 0.47.04-r2
Post by: Rumrusher on October 02, 2020, 05:56:50 am
Code: ('AnimaltokenCitizenPatch.lua') [Select]
local function allocateNewChunk(hist_entity)
  hist_entity.save_file_id = df.global.unit_chunk_next_id
  df.global.unit_chunk_next_id = df.global.unit_chunk_next_id+1
  hist_entity.next_member_idx = 0
  print("allocating chunk:",hist_entity.save_file_id)
end

local function allocateIds(nemesis_record,hist_entity)
  if hist_entity.next_member_idx == 100 then
    allocateNewChunk(hist_entity)
  end
  nemesis_record.save_file_id = hist_entity.save_file_id
  nemesis_record.member_idx = hist_entity.next_member_idx
  hist_entity.next_member_idx = hist_entity.next_member_idx+1
end

function createFigure(unit,he,he_group)
  local hf = df.historical_figure:new()
  hf.id = df.global.hist_figure_next_id
  df.global.hist_figure_next_id = df.global.hist_figure_next_id+1

  hf.unit_id = unit.id
  hf.nemesis_id = -1
  hf.race = unit.race
  hf.caste = unit.caste
  hf.profession = unit.profession
  hf.sex = unit.sex
  hf.name:assign(unit.name)

  hf.appeared_year = df.global.cur_year
  hf.born_year = unit.birth_year
  hf.born_seconds = unit.birth_time
  hf.curse_year = unit.curse_year
  hf.curse_seconds = unit.curse_time
  hf.birth_year_bias = unit.birth_year_bias
  hf.birth_time_bias = unit.birth_time_bias
  hf.old_year = unit.old_year
  hf.old_seconds = unit.old_time
  hf.died_year = -1
  hf.died_seconds = -1

  hf.civ_id = unit.civ_id
  hf.population_id = unit.population_id
  hf.breed_id = -1
  hf.cultural_identity = unit.cultural_identity
  hf.family_head_id = -1

  df.global.world.history.figures:insert("#", hf)

  hf.info = df.historical_figure_info:new()
  hf.info.whereabouts = df.historical_figure_info.T_whereabouts:new()
  hf.info.whereabouts.death_condition_parameter_1 = -1
  hf.info.whereabouts.death_condition_parameter_2 = -1
  -- set values that seem related to state and do event
  --change_state(hf, dfg.ui.site_id, region_pos)


  --let's skip skills for now
  --local skills = df.historical_figure_info.T_skills:new() -- skills snap shot
  -- ...
  -- note that innate skills are automaticaly set by DF
  hf.info.skills = {new=true}

  if he then
    he.histfig_ids:insert('#', hf.id)
    he.hist_figures:insert('#', hf)
    hf.entity_links:insert("#",{new=df.histfig_entity_link_memberst,entity_id=unit.civ_id,link_strength=100})

    --add entity event
    local hf_event_id = df.global.hist_event_next_id
    df.global.hist_event_next_id = df.global.hist_event_next_id+1
    df.global.world.history.events:insert("#",{new=df.history_event_add_hf_entity_linkst,year=unit.birth_year,
    seconds=unit.birth_time,id=hf_event_id,civ=hf.civ_id,histfig=hf.id,link_type=0})
  end

  if he_group and he_group ~= he then
    he_group.histfig_ids:insert('#', hf.id)
    he_group.hist_figures:insert('#', hf)
    --hf.entity_links:insert("#",{new=df.histfig_entity_link_memberst,entity_id=he_group.id,link_strength=100})
  end

  local soul = unit.status.current_soul
  if soul then
    hf.orientation_flags:assign(soul.orientation_flags)
  end

  unit.flags1.important_historical_figure = true
  unit.flags2.important_historical_figure = true
  unit.hist_figure_id = hf.id
  unit.hist_figure_id2 = hf.id

  return hf
end

function createNemesis(unit,civ_id,group_id)
  local id = df.global.nemesis_next_id
  local nem = df.nemesis_record:new()

  nem.id = id
  nem.unit_id = unit.id
  nem.unit = unit
  nem.flags:resize(31)
  nem.unk10 = -1
  nem.unk11 = -1
  nem.unk12 = -1
  df.global.world.nemesis.all:insert("#",nem)
  df.global.nemesis_next_id = id+1
  unit.general_refs:insert("#",{new = df.general_ref_is_nemesisst, nemesis_id = id})

  nem.save_file_id = -1

  local he
  if civ_id and civ_id ~= -1 then
    he = df.historical_entity.find(civ_id)
    he.nemesis_ids:insert("#",id)
    he.nemesis:insert("#",nem)
    allocateIds(nem,he)
  end
  local he_group
  if group_id and group_id ~= -1 then
    he_group = df.historical_entity.find(group_id)
  end
  if he_group then
    he_group.nemesis_ids:insert("#",id)
    he_group.nemesis:insert("#",nem)
  end
  nem.figure = unit.hist_figure_id ~= -1 and df.historical_figure.find(unit.hist_figure_id) or createFigure(unit,he,he_group) -- the histfig check is there just in case this function is called by another script to create nemesis data for a historical figure which somehow lacks it
  nem.figure.nemesis_id = id
  return nem
end
function sigh()
for k,v in pairs(df.global.world.units.active) do
local HF=df.global.world.history.figures
local HI=df.global.ui.civ_id
local EN=df.global.world.entities.all[HI]
local HP=df.global.ui.group_id
if v.hist_figure_id==-1 and v.civ_id==df.global.ui.civ_id then
createNemesis(v,HI,HP)
--createFigure(v,EN,HP)
print(k)
end
end
end

for k,v in pairs(df.global.world.units.active) do
local HFN=df.global.world.history.figures
local HN=df.global.ui.civ_id
sigh()
if v.hist_figure_id==-1 then break else
for c,q in pairs(HFN[v.hist_figure_id].entity_links) do
if q.entity_id==df.global.ui.civ_id and v.population_id==-1 and q.entity_id~=df.global.ui.group_id then
print(v.hist_figure_id)
HFN[v.hist_figure_id].entity_links:insert("#",{new=df.histfig_entity_link_memberst})
HFN[v.hist_figure_id].entity_links[c].entity_id=df.global.ui.group_id
HFN[v.hist_figure_id].entity_links[c].link_strength=100
end
end
end
end
ok so spent a deep amount of time trying to solve the animal token sapient migrants not having labors in a fort with this.
mostly solving the historical figure and nemesis issue of the previous script with dipping into create-unit's script for functions.

so now this script will allow one to play around with the animal tokens with sapient beings and build a multi-culture fort... also a side effect of this was buying new members for the fort.

tested this with my 'normal cat main civ race, ALL demon secondary citizens' entity the infurn which gives off an weird feeling of starting with one or two workers and a bunch of cats to slowly buying and building a community made up of different types of demons and their cat traders.
Title: Re: DFHack 0.47.04-r2
Post by: Roses on October 02, 2020, 11:45:21 am
It is kind of strange though, you would think that the built-in buildings/reactions/materials etc... would still need to have a similar structure to the custom ones that the game accesses. I guess they are probably just stored in a different area that isn't mapped or isn't accessible.
It's possible that they're stored somewhere else that isn't mapped - if we know enough values, I could probably come up with a script to search for a matching building_def_workshopst instance somewhere in memory.
It's also possible that built-in workshop definitions are stored in a completely different format, or their fields' values are hardcoded wherever the corresponding fields of custom workshops are looked up.
Builtin workshops populate the "Add Job" menu using the buildingst::fillSidebarMenu() vmethod, which creates instances of various interface_button_buildingst subclasses and inserts them into ui_sidebar_menus.workshop_job.choices_all[]. Exactly which jobs are added depends on the workshop/furnace's subtype, and some workshops don't add anything because their UI is 100% hardcoded (and they typically don't permit custom reactions either).

I actually took advantage of this (https://github.com/quietust/dfhack-23a/blob/master/plugins/more_jobs.cpp) in my DFHack backport for version 0.23.130.23a to add the ability to craft wooden blocks and trap components, glass trap components, and metal mechanisms.

Interesting... The more I think about it, the more I feel like the values for the built-in workshops are probably just hardcoded somewhere and there really isn't a way to automatically look up the values. I could construct each workshop in the game, look at the building ref and then create a cooresponding table. There are only 23 hardcoded workshops and 7 hardcoded furnaces, so it's not a hugely complicated task. I'll have to think harder on if it will be worth it.

EDIT: So looking into this further I think I found a sort of work around. Picking a position at the top of the map and using the following
Code: [Select]
require "dfhack.buildings"
-- loop over built in workshops
    bldg = dfhack.buildings.constructBuilding({pos=pos,type=13,subtype=#,custom=-1,filters={{},{}}})
    -- get building information here
    dfhack.buildings.deconstruct(bldg)
-- end loop
I can access the required information to create my own <building_def_workshopst> refs for the vanilla buildings. Running this when the game starts up is fairly quick and I get almost everything needed in a more automatic method.
Title: Re: DFHack 0.47.04-r2
Post by: Quietust on October 09, 2020, 08:03:50 am
Interesting... The more I think about it, the more I feel like the values for the built-in workshops are probably just hardcoded somewhere and there really isn't a way to automatically look up the values.
There's no "probably" involved - if you disassemble the 64-bit Windows version of 0.47.04, the relevant function is at address 0x14045f210, though I'll warn you that it doesn't use a convenient data table, but instead a giant switch() statement filled with code like this:
Code: [Select]
    interface_button_building_new_jobst *button;

    button = create_interface_button_building_new_jobst();
    button->hotkey_id = HOTKEY_FARMER_PROCESS;
    button->building = this;
    button->job_type = ProcessPlants;

    button = create_interface_button_building_new_jobst();
    button->hotkey_id = HOTKEY_FARMER_PROCESS_VIAL;
    button->building = this;
    button->job_type = ProcessPlantsVial;

    button = create_interface_button_building_new_jobst();
    button->hotkey_id = HOTKEY_FARMER_PROCESS_BARREL;
    button->building = this;
    button->job_type = ProcessPlantsBarrel;

    button = create_interface_button_building_new_jobst();
    button->hotkey_id = HOTKEY_FARMER_CHEESE;
    button->building = this;
    button->job_type = MakeCheese;

    button = create_interface_button_building_new_jobst();
    button->hotkey_id = HOTKEY_FARMER_MILK;
    button->building = this;
    button->job_type = MilkCreature;

    button = create_interface_button_building_new_jobst();
    button->hotkey_id = HOTKEY_FARMER_SHEAR_CREATURE;
    button->building = this;
    button->job_type = ShearCreature;

    button = create_interface_button_building_new_jobst();
    button->hotkey_id = HOTKEY_FARMER_SPIN_THREAD;
    button->building = this;
    button->job_type = SpinThread;
    button->material_category = job_material_category_strand;
As you can probably guess, the above code was taken from the Farmer's Workshop, and it's simple because everything is hardcoded. Some of the others are more complicated, though - for example, the Metalsmith's Forge creates multiple submenus to select the Item Category (weapon/armor/furniture/etc.), the Material (determined based on your civilization and the item category), and finally the Job (also determined based on your civilization and the item category).
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on October 10, 2020, 06:17:49 pm
0.47.04-r3 is up! Featuring a new DFHack-native Quickfort implementation, among other things. Please let us know of any feedback - ideally on the issue tracker (https://github.com/DFHack/dfhack/issues), but this thread or the quickfort script thread (http://www.bay12forums.com/smf/index.php?topic=176889.0) would also work.

Release notes and download: https://github.com/DFHack/dfhack/releases/tag/0.47.04-r3
Docs (including new quickfort user guide): https://docs.dfhack.org/en/0.47.04-r3/
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 10, 2020, 06:32:16 pm
Good!

Maybe there'll be some change to embark-assistant that'll cause it to find one of the embarks I'm looking for instead of always finding none.

Btw, what are the other changes?
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on October 10, 2020, 07:41:35 pm
I forgot to link it in my post, but you can find the downloads and release notes here: https://github.com/DFHack/dfhack/releases/tag/0.47.04-r3

Some more details about the issue you're encountering would be helpful - we can't fix it without more information. Are you sure that a matching site exists?
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 10, 2020, 08:47:31 pm
I'm having trouble compiling.

I did "ninja -j 8 install" and ended up with this:

Code: [Select]
[115/578] Building C object depends/libzip/lib/CMakeFiles/zip.dir/zip_add.c.o
FAILED: depends/libzip/lib/CMakeFiles/zip.dir/zip_add.c.o
ccache /usr/bin/cc -DHAVE_CUCHAR -DLINUX_BUILD -DLUA_BUILD_AS_DLL -DPROTOBUF_USE_DLLS -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_CXX11_ABI=0 -D_LINUX -I../depends/protobuf -I../depends/lua/include -I../depends/md5 -I../depends/tinyxml -I../depends/tthread -I../depends/clsocket/src -I../depends/xlsxio/include -I../depends/libzip/lib -Idepends/libzip -fvisibility=hidden -mtune=generic -m32 -march=i686 -O3 -DNDEBUG -fPIC -MD -MT depends/libzip/lib/CMakeFiles/zip.dir/zip_add.c.o -MF depends/libzip/lib/CMakeFiles/zip.dir/zip_add.c.o.d -o depends/libzip/lib/CMakeFiles/zip.dir/zip_add.c.o   -c ../depends/libzip/lib/zip_add.c
In file included from depends/libzip/config.h:4,
                 from ../depends/libzip/lib/zipint.h:37,
                 from ../depends/libzip/lib/zip_add.c:36:
depends/libzip/zipconf.h:28:10: warning: type defaults to ‘int’ in declaration of ‘zip_int16_t’ [-Wimplicit-int]
 typedef  zip_int16_t;
          ^~~~~~~~~~~
depends/libzip/zipconf.h:29:10: warning: type defaults to ‘int’ in declaration of ‘zip_uint16_t’ [-Wimplicit-int]
 typedef  zip_uint16_t;
          ^~~~~~~~~~~~
In file included from ../depends/libzip/lib/zipint.h:38,
                 from ../depends/libzip/lib/zip_add.c:36:
../depends/libzip/lib/compat.h:146:2: error: #error unsupported size of off_t
 #error unsupported size of off_t
  ^~~~~
[122/578] Building C object depends/libexpat/expat/CMakeFiles/expat.dir/lib/xmltok.c.o
ninja: build stopped: subcommand failed.

Any Ideas?
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on October 10, 2020, 10:54:49 pm
What OS are you compiling on?
What compiler are you using?
In your build folder, what does running the following command print?
Code: [Select]
grep SIZEOF_OFF_T ./depends/libzip/config.h
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on October 11, 2020, 02:43:11 am
:
Maybe there'll be some change to embark-assistant that'll cause it to find one of the embarks I'm looking for instead of always finding none.
:
The known bugs in the Embark Assistant have been fixed (or are at least believed to be fixed), although I don't remember if all went into -r2, or some may be in -r3 instead. No unknown bugs have been addressed, and that includes all bug reports sent telepathically.
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 11, 2020, 05:12:20 am
What OS are you compiling on?

Linux.

What compiler are you using?

gcc 8.3.0

In your build folder, what does running the following command print?
Code: [Select]
grep SIZEOF_OFF_T ./depends/libzip/config.h

Code: [Select]
/* #undef SIZEOF_OFF_T */
I'm gonna see about upgrading my compiler (if possible) and try again.

Edit:  Looks like I've already got the latest stable version of gcc 8.  I tried installing gcc 10, but it wanted to permanently remove over half the packages on my system including both glibc and sysvinit, so I wasn't able to install it.

Edit2:

Tried doing it again with "git checkout master" and "git submodule update" to check out the master branch.  It compiled just fine, but when I went to load it up it says it's version "0.47.04-r2 (release)".

help? :-\
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on October 11, 2020, 09:20:11 am
Edit2:

Tried doing it again with "git checkout master" and "git submodule update" to check out the master branch.  It compiled just fine, but when I went to load it up it says it's version "0.47.04-r2 (release)".

help? :-\
I forgot to update master so it was still on r2. Fixed. For reference, you can see when the branch was last updated at https://github.com/dfhack/dfhack/tree/master - previously, it said "0.47.04-r2" and "August 8".

Quote
Code: [Select]
/* #undef SIZEOF_OFF_T */

This is a problem. It looks like either your compiler doesn't define off_t (unlikely) or libzip can't find it somehow.

What Linux distro are you using?
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 11, 2020, 11:36:32 am
What Linux distro are you using?

I'm using a derivative of debian.  It's modified in such a way that the package dependencies are broken right out of the box (see my earlier comment concerning glibc and sysvinit...), and it's also some strange hybrid system where the kernel is 64-bit and everything else is 32-bit.  The developer also has staunchly refused to make a fully 64-bit system (something about wanting to make his product available to people who still have 32-bit systems).  Because of this I'm actually planning on switching to a different (fully 64-bit) distro if I can find the time for it.
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 11, 2020, 11:47:47 am
I forgot to update master so it was still on r2. Fixed. For reference, you can see when the branch was last updated at https://github.com/dfhack/dfhack/tree/master - previously, it said "0.47.04-r2" and "August 8".

I think I'll try again, then...

Also:

I am extremely angry.  The first time I posted the post above this one, the forum software ate half my post.  Then when I went to edit the post, it wouldn't let me save the changes.  So, then I copied the changes, went out of the thread and came back in, clicked modify, deleted everything and pasted only to have it paste in something else instead of what I had just copied.  At that point I just gave up and made this (second) post.  >:(

Edit:

Currently got all 8 cores compiling...

Also, should I be concerned about this warning ccmake gave me:
Code: [Select]
CMake Warning at depends/jsoncpp-sub/src/lib_json/CMakeLists.txt:36 (MESSAGE):
   Locale functionality is not supported



 CMake Warning (dev) at depends/libzip/CMakeLists.txt:186 (find_package):
   Policy CMP0074 is not set: find_package uses <PackageName>_ROOT variables.
   Run "cmake --help-policy CMP0074" for policy details.  Use the cmake_policy
   command to set the policy and suppress this warning.

   CMake variable ZLIB_ROOT is set to:

     /usr/lib/i386-linux-gnu

   For compatibility, CMake is ignoring the variable.
 This warning is for project developers.  Use -Wno-dev to suppress it.
?
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 11, 2020, 12:17:26 pm
Here's the entire output of "ninja -j8 install":

Code: [Select]
[121/578] Building C object depends/libzip/lib/CMakeFiles/zip.dir/zip_add_dir.c.o
FAILED: depends/libzip/lib/CMakeFiles/zip.dir/zip_add_dir.c.o
ccache /usr/bin/cc -DHAVE_CUCHAR -DLINUX_BUILD -DLUA_BUILD_AS_DLL -DPROTOBUF_USE_DLLS -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_CXX11_ABI=0 -D_LINUX -I../depends/protobuf -I../depends/lua/include -I../depends/md5 -I../depends/tinyxml -I../depends/tthread -I../depends/clsocket/src -I../depends/xlsxio/include -I../depends/libzip/lib -Idepends/libzip -fvisibility=hidden -mtune=generic -m32 -march=i686 -O3 -DNDEBUG -fPIC -MD -MT depends/libzip/lib/CMakeFiles/zip.dir/zip_add_dir.c.o -MF depends/libzip/lib/CMakeFiles/zip.dir/zip_add_dir.c.o.d -o depends/libzip/lib/CMakeFiles/zip.dir/zip_add_dir.c.o   -c ../depends/libzip/lib/zip_add_dir.c
In file included from depends/libzip/config.h:4,
                 from ../depends/libzip/lib/zipint.h:37,
                 from ../depends/libzip/lib/zip_add_dir.c:36:
depends/libzip/zipconf.h:28:10: warning: type defaults to ‘int’ in declaration of ‘zip_int16_t’ [-Wimplicit-int]
 typedef  zip_int16_t;
          ^~~~~~~~~~~
depends/libzip/zipconf.h:29:10: warning: type defaults to ‘int’ in declaration of ‘zip_uint16_t’ [-Wimplicit-int]
 typedef  zip_uint16_t;
          ^~~~~~~~~~~~
In file included from ../depends/libzip/lib/zipint.h:38,
                 from ../depends/libzip/lib/zip_add_dir.c:36:
../depends/libzip/lib/compat.h:146:2: error: #error unsupported size of off_t
 #error unsupported size of off_t
  ^~~~~
[122/578] Building C object depends/libzip/lib/CMakeFiles/zip.dir/zip_add_entry.c.o
FAILED: depends/libzip/lib/CMakeFiles/zip.dir/zip_add_entry.c.o
ccache /usr/bin/cc -DHAVE_CUCHAR -DLINUX_BUILD -DLUA_BUILD_AS_DLL -DPROTOBUF_USE_DLLS -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_CXX11_ABI=0 -D_LINUX -I../depends/protobuf -I../depends/lua/include -I../depends/md5 -I../depends/tinyxml -I../depends/tthread -I../depends/clsocket/src -I../depends/xlsxio/include -I../depends/libzip/lib -Idepends/libzip -fvisibility=hidden -mtune=generic -m32 -march=i686 -O3 -DNDEBUG -fPIC -MD -MT depends/libzip/lib/CMakeFiles/zip.dir/zip_add_entry.c.o -MF depends/libzip/lib/CMakeFiles/zip.dir/zip_add_entry.c.o.d -o depends/libzip/lib/CMakeFiles/zip.dir/zip_add_entry.c.o   -c ../depends/libzip/lib/zip_add_entry.c
In file included from depends/libzip/config.h:4,
                 from ../depends/libzip/lib/zipint.h:37,
                 from ../depends/libzip/lib/zip_add_entry.c:37:
depends/libzip/zipconf.h:28:10: warning: type defaults to ‘int’ in declaration of ‘zip_int16_t’ [-Wimplicit-int]
 typedef  zip_int16_t;
          ^~~~~~~~~~~
depends/libzip/zipconf.h:29:10: warning: type defaults to ‘int’ in declaration of ‘zip_uint16_t’ [-Wimplicit-int]
 typedef  zip_uint16_t;
          ^~~~~~~~~~~~
In file included from ../depends/libzip/lib/zipint.h:38,
                 from ../depends/libzip/lib/zip_add_entry.c:37:
../depends/libzip/lib/compat.h:146:2: error: #error unsupported size of off_t
 #error unsupported size of off_t
  ^~~~~
[123/578] Building C object depends/libzip/lib/CMakeFiles/zip.dir/zip_add.c.o
FAILED: depends/libzip/lib/CMakeFiles/zip.dir/zip_add.c.o
ccache /usr/bin/cc -DHAVE_CUCHAR -DLINUX_BUILD -DLUA_BUILD_AS_DLL -DPROTOBUF_USE_DLLS -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_CXX11_ABI=0 -D_LINUX -I../depends/protobuf -I../depends/lua/include -I../depends/md5 -I../depends/tinyxml -I../depends/tthread -I../depends/clsocket/src -I../depends/xlsxio/include -I../depends/libzip/lib -Idepends/libzip -fvisibility=hidden -mtune=generic -m32 -march=i686 -O3 -DNDEBUG -fPIC -MD -MT depends/libzip/lib/CMakeFiles/zip.dir/zip_add.c.o -MF depends/libzip/lib/CMakeFiles/zip.dir/zip_add.c.o.d -o depends/libzip/lib/CMakeFiles/zip.dir/zip_add.c.o   -c ../depends/libzip/lib/zip_add.c
In file included from depends/libzip/config.h:4,
                 from ../depends/libzip/lib/zipint.h:37,
                 from ../depends/libzip/lib/zip_add.c:36:
depends/libzip/zipconf.h:28:10: warning: type defaults to ‘int’ in declaration of ‘zip_int16_t’ [-Wimplicit-int]
 typedef  zip_int16_t;
          ^~~~~~~~~~~
depends/libzip/zipconf.h:29:10: warning: type defaults to ‘int’ in declaration of ‘zip_uint16_t’ [-Wimplicit-int]
 typedef  zip_uint16_t;
          ^~~~~~~~~~~~
In file included from ../depends/libzip/lib/zipint.h:38,
                 from ../depends/libzip/lib/zip_add.c:36:
../depends/libzip/lib/compat.h:146:2: error: #error unsupported size of off_t
 #error unsupported size of off_t
  ^~~~~
[126/578] Building C object depends/libzip/lib/CMakeFiles/zip.dir/zip_algorithm_deflate.c.o
FAILED: depends/libzip/lib/CMakeFiles/zip.dir/zip_algorithm_deflate.c.o
ccache /usr/bin/cc -DHAVE_CUCHAR -DLINUX_BUILD -DLUA_BUILD_AS_DLL -DPROTOBUF_USE_DLLS -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_CXX11_ABI=0 -D_LINUX -I../depends/protobuf -I../depends/lua/include -I../depends/md5 -I../depends/tinyxml -I../depends/tthread -I../depends/clsocket/src -I../depends/xlsxio/include -I../depends/libzip/lib -Idepends/libzip -fvisibility=hidden -mtune=generic -m32 -march=i686 -O3 -DNDEBUG -fPIC -MD -MT depends/libzip/lib/CMakeFiles/zip.dir/zip_algorithm_deflate.c.o -MF depends/libzip/lib/CMakeFiles/zip.dir/zip_algorithm_deflate.c.o.d -o depends/libzip/lib/CMakeFiles/zip.dir/zip_algorithm_deflate.c.o   -c ../depends/libzip/lib/zip_algorithm_deflate.c
In file included from depends/libzip/config.h:4,
                 from ../depends/libzip/lib/zipint.h:37,
                 from ../depends/libzip/lib/zip_algorithm_deflate.c:34:
depends/libzip/zipconf.h:28:10: warning: type defaults to ‘int’ in declaration of ‘zip_int16_t’ [-Wimplicit-int]
 typedef  zip_int16_t;
          ^~~~~~~~~~~
depends/libzip/zipconf.h:29:10: warning: type defaults to ‘int’ in declaration of ‘zip_uint16_t’ [-Wimplicit-int]
 typedef  zip_uint16_t;
          ^~~~~~~~~~~~
In file included from ../depends/libzip/lib/zipint.h:38,
                 from ../depends/libzip/lib/zip_algorithm_deflate.c:34:
../depends/libzip/lib/compat.h:146:2: error: #error unsupported size of off_t
 #error unsupported size of off_t
  ^~~~~
[127/578] Building C object depends/libzip/lib/CMakeFiles/zip.dir/zip_buffer.c.o
FAILED: depends/libzip/lib/CMakeFiles/zip.dir/zip_buffer.c.o
ccache /usr/bin/cc -DHAVE_CUCHAR -DLINUX_BUILD -DLUA_BUILD_AS_DLL -DPROTOBUF_USE_DLLS -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_CXX11_ABI=0 -D_LINUX -I../depends/protobuf -I../depends/lua/include -I../depends/md5 -I../depends/tinyxml -I../depends/tthread -I../depends/clsocket/src -I../depends/xlsxio/include -I../depends/libzip/lib -Idepends/libzip -fvisibility=hidden -mtune=generic -m32 -march=i686 -O3 -DNDEBUG -fPIC -MD -MT depends/libzip/lib/CMakeFiles/zip.dir/zip_buffer.c.o -MF depends/libzip/lib/CMakeFiles/zip.dir/zip_buffer.c.o.d -o depends/libzip/lib/CMakeFiles/zip.dir/zip_buffer.c.o   -c ../depends/libzip/lib/zip_buffer.c
In file included from depends/libzip/config.h:4,
                 from ../depends/libzip/lib/zipint.h:37,
                 from ../depends/libzip/lib/zip_buffer.c:37:
depends/libzip/zipconf.h:28:10: warning: type defaults to ‘int’ in declaration of ‘zip_int16_t’ [-Wimplicit-int]
 typedef  zip_int16_t;
          ^~~~~~~~~~~
depends/libzip/zipconf.h:29:10: warning: type defaults to ‘int’ in declaration of ‘zip_uint16_t’ [-Wimplicit-int]
 typedef  zip_uint16_t;
          ^~~~~~~~~~~~
In file included from ../depends/libzip/lib/zipint.h:38,
                 from ../depends/libzip/lib/zip_buffer.c:37:
../depends/libzip/lib/compat.h:146:2: error: #error unsupported size of off_t
 #error unsupported size of off_t
  ^~~~~
../depends/libzip/lib/zip_buffer.c: In function ‘_zip_buffer_get_64’:
../depends/libzip/lib/zip_buffer.c:111:35: warning: left shift count >= width of type [-Wshift-count-overflow]
     return ((zip_uint64_t)data[7] << 56) + ((zip_uint64_t)data[6] << 48) + ((zip_uint64_t)data[5] << 40) + ((zip_uint64_t)data[4] << 32) + ((zip_uint64_t)data[3] << 24) + ((zip_uint64_t)data[2] << 16) + ((zip_uint64_t)data[1] << 8) + (zip_uint64_t)data[0];
                                   ^~
../depends/libzip/lib/zip_buffer.c:111:67: warning: left shift count >= width of type [-Wshift-count-overflow]
     return ((zip_uint64_t)data[7] << 56) + ((zip_uint64_t)data[6] << 48) + ((zip_uint64_t)data[5] << 40) + ((zip_uint64_t)data[4] << 32) + ((zip_uint64_t)data[3] << 24) + ((zip_uint64_t)data[2] << 16) + ((zip_uint64_t)data[1] << 8) + (zip_uint64_t)data[0];
                                                                   ^~
../depends/libzip/lib/zip_buffer.c:111:99: warning: left shift count >= width of type [-Wshift-count-overflow]
     return ((zip_uint64_t)data[7] << 56) + ((zip_uint64_t)data[6] << 48) + ((zip_uint64_t)data[5] << 40) + ((zip_uint64_t)data[4] << 32) + ((zip_uint64_t)data[3] << 24) + ((zip_uint64_t)data[2] << 16) + ((zip_uint64_t)data[1] << 8) + (zip_uint64_t)data[0];
                                                                                                   ^~
../depends/libzip/lib/zip_buffer.c:111:131: warning: left shift count >= width of type [-Wshift-count-overflow]
     return ((zip_uint64_t)data[7] << 56) + ((zip_uint64_t)data[6] << 48) + ((zip_uint64_t)data[5] << 40) + ((zip_uint64_t)data[4] << 32) + ((zip_uint64_t)data[3] << 24) + ((zip_uint64_t)data[2] << 16) + ((zip_uint64_t)data[1] << 8) + (zip_uint64_t)data[0];
                                                                                                                                   ^~
../depends/libzip/lib/zip_buffer.c: In function ‘_zip_buffer_put_64’:
../depends/libzip/lib/zip_buffer.c:273:32: warning: right shift count >= width of type [-Wshift-count-overflow]
     data[4] = (zip_uint8_t)((i >> 32) & 0xff);
                                ^~
../depends/libzip/lib/zip_buffer.c:274:32: warning: right shift count >= width of type [-Wshift-count-overflow]
     data[5] = (zip_uint8_t)((i >> 40) & 0xff);
                                ^~
../depends/libzip/lib/zip_buffer.c:275:32: warning: right shift count >= width of type [-Wshift-count-overflow]
     data[6] = (zip_uint8_t)((i >> 48) & 0xff);
                                ^~
../depends/libzip/lib/zip_buffer.c:276:32: warning: right shift count >= width of type [-Wshift-count-overflow]
     data[7] = (zip_uint8_t)((i >> 56) & 0xff);
                                ^~
[128/578] Building C object depends/libzip/lib/CMakeFiles/zip.dir/zip_close.c.o
FAILED: depends/libzip/lib/CMakeFiles/zip.dir/zip_close.c.o
ccache /usr/bin/cc -DHAVE_CUCHAR -DLINUX_BUILD -DLUA_BUILD_AS_DLL -DPROTOBUF_USE_DLLS -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_CXX11_ABI=0 -D_LINUX -I../depends/protobuf -I../depends/lua/include -I../depends/md5 -I../depends/tinyxml -I../depends/tthread -I../depends/clsocket/src -I../depends/xlsxio/include -I../depends/libzip/lib -Idepends/libzip -fvisibility=hidden -mtune=generic -m32 -march=i686 -O3 -DNDEBUG -fPIC -MD -MT depends/libzip/lib/CMakeFiles/zip.dir/zip_close.c.o -MF depends/libzip/lib/CMakeFiles/zip.dir/zip_close.c.o.d -o depends/libzip/lib/CMakeFiles/zip.dir/zip_close.c.o   -c ../depends/libzip/lib/zip_close.c
In file included from depends/libzip/config.h:4,
                 from ../depends/libzip/lib/zipint.h:37,
                 from ../depends/libzip/lib/zip_close.c:35:
depends/libzip/zipconf.h:28:10: warning: type defaults to ‘int’ in declaration of ‘zip_int16_t’ [-Wimplicit-int]
 typedef  zip_int16_t;
          ^~~~~~~~~~~
depends/libzip/zipconf.h:29:10: warning: type defaults to ‘int’ in declaration of ‘zip_uint16_t’ [-Wimplicit-int]
 typedef  zip_uint16_t;
          ^~~~~~~~~~~~
In file included from ../depends/libzip/lib/zipint.h:38,
                 from ../depends/libzip/lib/zip_close.c:35:
../depends/libzip/lib/compat.h:146:2: error: #error unsupported size of off_t
 #error unsupported size of off_t
  ^~~~~
In file included from depends/libzip/config.h:4,
                 from ../depends/libzip/lib/zipint.h:37,
                 from ../depends/libzip/lib/zip_close.c:35:
../depends/libzip/lib/zip_close.c: In function ‘zip_close’:
depends/libzip/zipconf.h:49:25: warning: conversion from ‘long long unsigned int’ to ‘zip_uint64_t’ {aka ‘long unsigned int’} changes value from ‘18446744073709551615’ to ‘4294967295’ [-Woverflow]
 #define ZIP_UINT64_MAX  0xffffffffffffffffULL
                         ^~~~~~~~~~~~~~~~~~~~~
../depends/libzip/lib/zip_close.c:91:24: note: in expansion of macro ‘ZIP_UINT64_MAX’
     unchanged_offset = ZIP_UINT64_MAX;
                        ^~~~~~~~~~~~~~
depends/libzip/zipconf.h:49:25: warning: conversion from ‘long long unsigned int’ to ‘zip_uint64_t’ {aka ‘long unsigned int’} changes value from ‘18446744073709551615’ to ‘4294967295’ [-Woverflow]
 #define ZIP_UINT64_MAX  0xffffffffffffffffULL
                         ^~~~~~~~~~~~~~~~~~~~~
../depends/libzip/lib/zip_close.c:122:32: note: in expansion of macro ‘ZIP_UINT64_MAX’
      zip_uint64_t last_index = ZIP_UINT64_MAX;
                                ^~~~~~~~~~~~~~
ninja: build stopped: subcommand failed.
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 11, 2020, 12:33:40 pm
just looked up "off_t".  Found something saying it should be defined in bits/types.h.  Looked in there and it does appear that it isn't defined.
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on October 11, 2020, 01:32:02 pm
If you're using something Debian-based, I would expect the binaries from https://github.com/dfhack/dfhack/releases/0.47.04-r3 to work. Probably the 32-bit ones if you have a 32-bit userspace. https://docs.dfhack.org/en/latest/docs/Installing.html explains the difference between the various builds a bit more.

It looks like bits/types.h is from the "libc6-dev" package on Debian. Do you have that package installed? If so, what version?

Edit: off_t might also be defined in sys/types.h.
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 11, 2020, 01:43:14 pm
If you're using something Debian-based, I would expect the binaries from https://github.com/dfhack/dfhack/releases/0.47.04-r3 to work. Probably the 32-bit ones if you have a 32-bit userspace. https://docs.dfhack.org/en/latest/docs/Installing.html explains the difference between the various builds a bit more.

It looks like bits/types.h is from the "libc6-dev" package on Debian. Do you have that package installed? If so, what version?

looks like I've got libc6-dev 2.29-2.  It says the latest stable version is 2.31-4, but when I try and upgrade it does that thing again where it wants to uninstall half the packages on my system.

Edit:

Ok.  It looks like the binary is working.  So far...
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 11, 2020, 02:49:01 pm
Some more details about the issue you're encountering would be helpful - we can't fix it without more information.

I've been generating multiple worlds almost every day for what seems like the past 2 months, and when I run embark-assistant on them it almost always tells me that the are 0 matching world tiles.  Before I learned to run the find function twice, it was finding only 1-3 embarks in only one of the world that I genned in a week (and those almost always had some problem that made them unusable).  Since I started running find twice, it hasn't found anything.

Are you sure that a matching site exists?

No, come to think of it, I'm not.
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on October 11, 2020, 04:29:03 pm
Some more details about the issue you're encountering would be helpful - we can't fix it without more information.

I've been generating multiple worlds almost every day for what seems like the past 2 months, and when I run embark-assistant on them it almost always tells me that the are 0 matching world tiles.  Before I learned to run the find function twice, it was finding only 1-3 embarks in only one of the world that I genned in a week (and those almost always had some problem that made them unusable).  Since I started running find twice, it hasn't found anything.

Are you sure that a matching site exists?

No, come to think of it, I'm not.
Identifying and fixing a match bug would probably require a case where the search profile is known and a save where a matching location has been located manually (and info of where that location is).

However, a full description of the profile might give some indication about whether it's likely to be a bug or a case of the profile being too specific for worlds to be likely to have any matching sites (in which case relaxing the criteria might give you sites that are acceptable, but not perfect).  If the world generated are highly tweaked that info would be needed as well, although I won't be much good in predicting how meshes this way or that would affect things.
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 11, 2020, 06:42:51 pm
Some more details about the issue you're encountering would be helpful - we can't fix it without more information.

I've been generating multiple worlds almost every day for what seems like the past 2 months, and when I run embark-assistant on them it almost always tells me that the are 0 matching world tiles.  Before I learned to run the find function twice, it was finding only 1-3 embarks in only one of the world that I genned in a week (and those almost always had some problem that made them unusable).  Since I started running find twice, it hasn't found anything.

Are you sure that a matching site exists?

No, come to think of it, I'm not.
Identifying and fixing a match bug would probably require a case where the search profile is known and a save where a matching location has been located manually (and info of where that location is).

However, a full description of the profile might give some indication about whether it's likely to be a bug or a case of the profile being too specific for worlds to be likely to have any matching sites (in which case relaxing the criteria might give you sites that are acceptable, but not perfect).  If the world generated are highly tweaked that info would be needed as well, although I won't be much good in predicting how meshes this way or that would affect things.

Here's the world creation parameters:

(https://i.postimg.cc/1zWQdTx6/Creation.png)

Here's the search parameters:

(https://i.postimg.cc/HLKpxKSm/Search-Parameters.png)

Any help would be appreciated.  Note that I'm specifically trying to stay away from goblins as I'm still learning the ropes and haven't figured out the military yet (I also haven't figured out how to use the manager for food and booze either).

Thanks in advance.
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on October 12, 2020, 03:10:59 am
Thanks.
It's a large non evil embark (so the evil weather parameters are redundant, but won't cause any harm either), no aquifer, min height waterfall (where brook has been excluded as the source), non freezing (which would probably always be the case for moist broadleaf anyway).
However, demanding fire clay, iron, gypsum, kaolinite and bit-coal is very demanding even without the other restrictions, despite the world gen mineral occurrence is set to Everywhere in a Large world.

For starters, is there any specific reason you demand bit-coal, rather than just any coal (further up in the list)? That would about double the chance for a match.

A short history reduces the impact of the demand for no necros in range, while staying away from gobbos typically excludes most of the world.

My conclusion from looking at it is that the chances of finding any locations matching those requirements in any given world would be rather low, and I'd either ease up on the requirements, or find a site that's near what's wanted, and then hack the site to match the requirements, e.g. using the Biome Manipulator to "correct" the biome, evilness, and/or geo biome.
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 12, 2020, 09:24:55 am
Thanks.
It's a large non evil embark (so the evil weather parameters are redundant, but won't cause any harm either),

I'm still learning show I can't handle evil embarks and weather.

no aquifer,

I don't know how to handle aquifers yet.  The last time I tried doing the double slit method, the dwarves wouldn't pump long enough to do anything because they kept spending all their time hanging out by the river.

min height waterfall (where brook has been excluded as the source),

I need the waterfall to be at least 2-z high in order to get "donations".  I need at least a stream for the same reason.

non freezing (which would probably always be the case for moist broadleaf anyway).

I'm still learning so I don't want to have to worry about ice.

Thanks.
However, demanding fire clay,

I'd like to be able to make at least one type of ceramic that doesn't need to be glazed (I'd prefer not to waste all my wood making ash glaze and then not have enough for everything else).

iron,

I'd like to eventually create a military and steel armor and weapons are necessary to defeat the goblins (I'd also like to be able to deal with things like the problem I had in my last fort where a human maceman kept finding his way back from the caverns where I repeatedly gui/teleported him to after he started sneaking around and scaring my dwarves while looking for an artifact that had already been given to somebody else and taken off the map).

gypsum,

Gypsum is needed to set broken bones.

kaolinite and

See above under "fire clay" (although it is more of a nice to have and not a necessity).

bit-coal is very demanding even without the other restrictions, despite the world gen mineral occurrence is set to Everywhere in a Large world.

For starters, is there any specific reason you demand bit-coal, rather than just any coal (further up in the list)? That would about double the chance for a match.

I'm looking for bit-coal because it gives more coke (but I suppose I could do with any kind of coal.  I'd also prefer not to use up all my wood firing furnaces and kilns).

A short history reduces the impact of the demand for no necros in range,

How?

while staying away from gobbos typically excludes most of the world.

I haven't figured out the military yet (I'd prefer not getting curb stomped into oblivion before I can really get anything set up).

My conclusion from looking at it is that the chances of finding any locations matching those requirements in any given world would be rather low, and I'd either ease up on the requirements,

I'll try, but I'm not sure it'll work.  Some of the things listed above seem like necessities to me.

Also, it would be nice to be able to search for embarks that have at least one of either elves or humans instead of having to search for ones that have both.

or find a site that's near what's wanted, and then hack the site to match the requirements, e.g. using the Biome Manipulator to "correct" the biome, evilness, and/or geo biome.

Biome Manipulator?

I looked in the documentation for DFHack and the only thing I found was for something called Manipulator (which looks to be an attempt at making an in-game replacement for DT), but it didn't seem to have anything about "correct"ing any of the stuff you talked about above.

Also, what is a "geo biome"?
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on October 12, 2020, 10:16:41 am
Biome Manipulator is one of PatrikLundell's scripts: http://www.bay12forums.com/smf/index.php?topic=164658.0
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on October 12, 2020, 11:25:53 am
The geo biome is the definition of what the mineral layers are at various locations. This definition also lists veins and inclusions (while I don't think those are guaranteed to show up if there are too many of them, as there is only so much room for those if you hack it).

The comments about the requirements weren't meant as complaints, just comments on what's there.

When it comes to aquifers, the light one is quite easy to deal with, although there's still room to screw up (I know, as I've done that).

I usually make my pots out of rock, rather than clay.

Gypsum isn't required. You can get by with splints and traction racks.

I think kaolinite is fairly rare, so requiring it reduces the chances of finding a match.

I don't use charcoal (or fossil coal) to fire my facilities, but go for magma powered ones. That means you'd only need coal for steel, and wood should be sufficient for that (fossil coal is convenient, though).

The DFHack Manipulator is indeed an alternative to DT, although the takes are slightly different, and thus cater to different tastes. I don't know which one came first, though.
Title: Re: DFHack 0.47.04-r3
Post by: daishi5 on October 12, 2020, 01:27:04 pm
I have been working on some embark issues, and I found this bug https://www.bay12games.com/dwarves/mantisbt/view.php?id=10267

I also helpfully found that you guys already wrote this script that seems to fix the bug https://github.com/PatrikLundell/scripts/blob/own_scripts/candy_corrector.lua

However, I cannot figure out how to run the script, so how do I run the candy corrector?
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on October 12, 2020, 01:38:47 pm
Copy the script text (not the whole web page) into a "text" file in <DF>\hack\scripts called "candy_corrector.lua" (without the quotes). Then type "candy_corrector" (again without quotes) into the DFHack console window. Note that it will take the script quite some time to to run because it caused DF to perform quite time consuming data loading actions. The script should be run pre embark, i.e. at the screen showing the world, asking you where to embark. After the script has run you have to find your future location again as the data loading is prompted by moving the cursor over each world tile.
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 13, 2020, 06:33:03 am
Btw, in embark-assistant it would be nice if there was a way after doing a search to search again using less restrictive search parameters without having to "abort game" and reload the world.  I tried using "cancel/clear find" but it didn't seem to do anything.
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on October 13, 2020, 07:23:39 am
Btw, in embark-assistant it would be nice if there was a way after doing a search to search again using less restrictive search parameters without having to "abort game" and reload the world.  I tried using "cancel/clear find" but it didn't seem to do anything.
The functionality is there...
Cancel aborts a currently ongoing search (you realize after a couple of minutes that you want a different profile, and don't want to wait until the current search is done to try again). Clear just removes the match indicators, as they can be annoying to see when you've already made up your mind.

To search again you go back to the search criteria screen, adjust the criteria, and order a new search, using those.
To try it out, you can do a search and then change the criteria to something really simple (like your 8*8 being non evil, and nothing else) to see that the new search will find a lot of matches.
The "real" use case may be to search for your ideal site and then relax the criteria when you don't find it, or go in the opposite direction when your criteria result in a lot of matches, so you thing you ought to be able to add additional wishes and still get a match.
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 13, 2020, 08:18:27 am
The "real" use case may be to search for your ideal site and then relax the criteria when you don't find it,

That's what I've been trying to do.

If I set the search criteria so that it only takes one change to not provide any results (searching with the "relaxed" search criteria first to ensure that I do get results), and then search with the more "restricted" criteria (resulting in no results), when I go and change the criteria back to the "relaxed" criteria and do a search I don't get any results (even though a previous search with those exact same criteria did yield results).
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 13, 2020, 08:56:59 am
Also, how many tiles on the pre-embark "Local" map does each tile in biome manipulator represent?  How many on the "Region" map and how many on the "World" map?
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on October 13, 2020, 11:22:51 am
Apart from the first search being incomplete, I'm not aware of any case where a later search gives a result different from the previous one with exactly the same criteria.

The Biome Manipulator operates on World Tiles, i.e. the ones on the middle map on the pre embark screen. The one to the right mashes several world tiles together in blocks and have those blocks represented by one of the world tiles within the block. The number of world tiles per block depends on the world size, your screen resolution, and "rounding" (some represent larger areas than others due to the number of tiles not being evenly divisible by the tile resolution).

The Local map represents the area within the current world tile, and literally does not exist for any other tile (while playing, a 3*3 world tile area centered on the fortress [and I assume the adventurer] exists). The tiles are generated as they come into focus, and almost all attempts to manipulate them is lost when the focus is moved to another world tile and back again. If you manipulate the tile and then embark without leaving the world tile the changes are frozen into the embark, but I don't think those hacks are retained if you retire and try to embark somewhere else in that world tile.
The Region Manipulator (poorly named) http://www.bay12forums.com/smf/index.php?topic=164136.msg7454345#msg7454345 (http://www.bay12forums.com/smf/index.php?topic=164136.msg7454345#msg7454345) operates on the scale of Mid Level Tiles (the ones on the Local view).

The scale finer that that does not exist until DF generates it at embark (or when an adventurer enters the area).
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 13, 2020, 12:57:03 pm
Apart from the first search being incomplete, I'm not aware of any case where a later search gives a result different from the previous one with exactly the same criteria.

I'm currently waiting for my confirmation email from DFFD.  When I get it I'll post something demonstrating the problem.

btw,  what would be the best compression format for?  Is tar.bz2 OK?  I'm on a Linux system...

The Biome Manipulator operates on World Tiles, i.e. the ones on the middle map on the pre embark screen.

Ah! So each tile in Biome Manipulator corresponds to one tile in the Region map (the middle map on the pre embark screen).  Thanks!

The Region Manipulator (poorly named) http://www.bay12forums.com/smf/index.php?topic=164136.msg7454345#msg7454345 (http://www.bay12forums.com/smf/index.php?topic=164136.msg7454345#msg7454345) operates on the scale of Mid Level Tiles (the ones on the Local view).

Interesting.  I didn't know that script existed!  I might try it sometime...

Thanks!
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on October 13, 2020, 03:11:53 pm
The zip format is compatible with everyone, with the 7z one compatible with many. The basic .tar format can be read by 7zip (which I use), but I have no idea about the various Unix compression options.
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 13, 2020, 04:01:25 pm
The zip format is compatible with everyone, with the 7z one compatible with many. The basic .tar format can be read by 7zip (which I use), but I have no idea about the various Unix compression options.

Got it zipped up in 7z format.  Still waiting for that email...
Title: Re: DFHack 0.47.04-r3
Post by: daishi5 on October 13, 2020, 06:42:56 pm
Copy the script text (not the whole web page) into a "text" file in <DF>\hack\scripts called "candy_corrector.lua" (without the quotes). Then type "candy_corrector" (again without quotes) into the DFHack console window. Note that it will take the script quite some time to to run because it caused DF to perform quite time consuming data loading actions. The script should be run pre embark, i.e. at the screen showing the world, asking you where to embark. After the script has run you have to find your future location again as the data loading is prompted by moving the cursor over each world tile.

First off, thank you for your help and all your hard work on this.

I think I got the script to run once, but my memory could be wrong.  Every attempt to run the script after the first time has generated this error:

...\Dwarf Fortress 0.47.04/hack/scripts/candy_corrector.lua:51: attempt to index a nil value (field 'features')
stack traceback:
        ...\Dwarf Fortress 0.47.04/hack/scripts/candy_corrector.lua:51: in global 'candy_corrector'
        ...\Dwarf Fortress 0.47.04/hack/scripts/candy_corrector.lua:78: in local 'script_code'
        D:\DF\Dwarf Fortress 0.47.04\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
        (...tail calls...)

I have tried installing the latest version of DFhack (I am using the LNP which has R2), but that broke TWBT and I still got the same error. 

I re-downloaded the LNP and tried it again, got the same error.

I generated a world with 3 layers, I get the message that there are 3 layers and nothing needs to be done. 

I generated two more worlds with 2 layers, both get the same error.

I deleted the candy_corrector.lua file, grabbed the text again from the website and made a new candy_corrector file, same error.

Not sure what else to try.



On a completely unrelated note, are there any other scripts that I should run in a normal game to fix bugs?
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on October 14, 2020, 03:31:56 am
@daishi5:
I've tried to reproduce the issue. The script worked correctly on a couple of 17*17 maps, but does indeed fail on a max sized one. I do believe I understand why it fails, but it will take some time to address and test that, so I'll return later with an update.

I can't think of any other world gen bugs that have scripts correcting them: I don't use any, in any case.

Edit:
OK, I've finally updated the script https://github.com/PatrikLundell/scripts/blob/own_scripts/candy_corrector.lua (https://github.com/PatrikLundell/scripts/blob/own_scripts/candy_corrector.lua) (same link as before).
The script should be a bit faster, show a progress indication of sorts (feature shells progressed), and not suffer from feature shells being unloaded again before being accessed (by doing the processing immediately after the loading, rather than in two separate passes).
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 14, 2020, 07:50:14 am
Btw, does anyone know how long it takes to get the confirmation email from DFFD?
Title: Re: DFHack 0.47.04-r3
Post by: daishi5 on October 14, 2020, 10:15:35 am
@daishi5:
I've tried to reproduce the issue. The script worked correctly on a couple of 17*17 maps, but does indeed fail on a max sized one. I do believe I understand why it fails, but it will take some time to address and test that, so I'll return later with an update.

I can't think of any other world gen bugs that have scripts correcting them: I don't use any, in any case.

Edit:
OK, I've finally updated the script https://github.com/PatrikLundell/scripts/blob/own_scripts/candy_corrector.lua (https://github.com/PatrikLundell/scripts/blob/own_scripts/candy_corrector.lua) (same link as before).
The script should be a bit faster, show a progress indication of sorts (feature shells progressed), and not suffer from feature shells being unloaded again before being accessed (by doing the processing immediately after the loading, rather than in two separate passes).

Wow, that was fast and I can confirm it seems to have worked for me.  Thank you.
Title: Re: DFHack 0.47.04-r3
Post by: Roses on October 15, 2020, 01:25:18 pm
Not sure if this is a question for here or in the general modding section, but do we have a list or do we know all the different numbers that are capped from the raws, but not from the game itself? As an example, you can't set a units attributes above 5000 in the raws (it will treat any higher numbers as being 5000), but you can set the attributes higher with DFHack, and they actually still have an effect. Similarly the size from the raws is capped. Those are the only two I know about, but are there any more?
Title: Re: DFHack 0.47.04-r3
Post by: Uthimienure on October 15, 2020, 04:14:05 pm
Anybody know if there's a script or plugin that provides a "timer" or "alarm clock" function in the game?

Example:  I want a reminder to put the squad of migrants in quarantine 3 days before the were transformation date, so I set an alarm clock for the date and the game pauses and gives me a message of some sort.

Example:  Having stationed a squad of xbow dorfs somewhere to shoot down keas, I would set a timer to count down 8 days then pause & center on the squad.


(edit:  I did search the DFHack documentation and the forum with no luck.)
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 15, 2020, 04:29:49 pm
Anybody know if there's a script or plugin that provides a "timer" or "alarm clock" function in the game?

Example:  I want a reminder to put the squad of migrants in quarantine 3 days before the were transformation date, so I set an alarm clock for the date and the game pauses and gives me a message of some sort.

Example:  Having stationed a squad of xbow dorfs somewhere to shoot down keas, I would set a timer to count down 8 days then pause & center on the squad.


(edit:  I did search the DFHack documentation and the forum with no luck.)

Hmmm....

It looks like what you need is a DFHack command that pauses the game with a message box that contains a custom message.  This could then be used with the "repeat" command.  I'm not sure if such a command exists...

Edit:

I'd think "warn-starving" would be a good starting point for such a script, but I'm too busy learning C++ to learn Lua right now.

Edit2:

"gui/hello-world" looks like a better starting point.
Title: Re: DFHack 0.47.04-r3
Post by: Uthimienure on October 15, 2020, 04:42:36 pm
It really doesn't need to be customized or center on the squad, those were "wishes".
Any kind of simple timer/alarm that pauses would be neato.
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 15, 2020, 04:46:54 pm
It really doesn't need to be customized or center on the squad, those were "wishes".
Any kind of simple timer/alarm that pauses would be neato.

In that case take a look at "repeat" and "fpause".
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on October 15, 2020, 07:04:39 pm
I would also suggest taking a look at the Lua announcements API: https://docs.dfhack.org/en/stable/docs/Lua%20API.html#announcements
You can use this to create native DF announcements, that can optionally pause the game and/or show an in-game popup (similar to the cavern discovery message). If you don't need to customize their appearance, this may be an easier approach than warn-starving and gui/hello-world. Pausing announcements also wouldn't need "fpause".

I would definitely recommend "repeat" or the repeat-util module (https://github.com/DFHack/dfhack/blob/develop/library/lua/repeat-util.lua) to get something to run e.g. every in-game day.
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 15, 2020, 07:37:12 pm
I would also suggest taking a look at the Lua announcements API: https://docs.dfhack.org/en/stable/docs/Lua%20API.html#announcements
You can use this to create native DF announcements, that can optionally pause the game and/or show an in-game popup (similar to the cavern discovery message). If you don't need to customize their appearance, this may be an easier approach than warn-starving and gui/hello-world. Pausing announcements also wouldn't need "fpause".

I would definitely recommend "repeat" or the repeat-util module (https://github.com/DFHack/dfhack/blob/develop/library/lua/repeat-util.lua) to get something to run e.g. every in-game day.

Looking through the Lua API, I couldn't find anything to return the current day-of-month.  Is there anything like that ?
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on October 15, 2020, 08:25:00 pm
dfhack.world.ReadCurrentDay()
dfhack.world.ReadCurrentMonth()
dfhack.world.ReadCurrentYear()

These are unfortunately not documented. Looks to me like the day ranges from 1-28 and the month ranges from 0-11 (inclusive).
https://dwarffortresswiki.org/index.php/DF2014:Calendar goes into a bit more detail about how DF handles time.
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 15, 2020, 09:36:16 pm
Interesting.  With that, the burrows module, and the units module, the only thing missing is a way to check if a unit is a were and somebody could write a script that automatically burrows were-citizens just before the full moon and then automatically releases them afterwords...
Title: Re: DFHack 0.47.04-r3
Post by: Uthimienure on October 15, 2020, 09:51:23 pm
I've never written one, and wouldn't know where to begin, unfortunately.  Perhaps in a couple of weeks after I get some domestic business out of the way, but not sure even then.
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on October 16, 2020, 04:50:43 am
I wouldn't trust a small number of days to get anyone into a burrow that isn't a civilian alert.

Dorfs only go to designated burrow areas when they have a "job" there (where eating/sleeping counts as jobs, but dorf designated lever pulling [probably smashed when turned], or anything that isn't dependent on the dorf's needs is more likely to be taken up). If they don't find any job to perform within the burrow they typically just stand rooted on the spot.

Uninterruptible needs satisfaction activities won't be interrupted by burrows: the buggers will just continue until done. In fact, they can start need satisfaction activities outside of the burrow when burrowing block them from performing their current activity if there is no real job in the burrow, only need satisfaction ones (as an alternative to sprouting roots).

If they're hauling stuff when burrowed and the target isn't in the burrow you're in for cancellation spam until you either give up and remove them from the burrow, or somehow get the morons to drop the stuff hauled.
Title: Re: DFHack 0.47.04-r3
Post by: Schmaven on October 16, 2020, 05:54:45 am
Forbidding their hauled item gets them to drop it.  But you can't forbid it from their inventory screen, you have to select the item from there, and view its details first.  I do this when I want an item moved out of a dry well cistern or something like that, but don"t want them to haul the item all the way to the atom smasher.
Title: Re: DFHack 0.47.04-r3
Post by: HungThir on October 18, 2020, 11:36:46 pm
is there a way to use dfhack to fix the "void tiles" that appear from d-z'ing ice ramps (http://www.bay12games.com/dwarves/mantisbt/view.php?id=1981)?

the wiki mentions (https://www.dwarffortresswiki.org/index.php/DF2014:Ice#Bugs) that casting ice on the void tile and channeling it out again can fix it, but i'm hoping for a way to just have the computer do the work...
Title: Re: DFHack 0.47.04-r3
Post by: Bumber on October 19, 2020, 02:37:42 pm
is there a way to use dfhack to fix the "void tiles" that appear from d-z'ing ice ramps (http://www.bay12games.com/dwarves/mantisbt/view.php?id=1981)?

the wiki mentions (https://www.dwarffortresswiki.org/index.php/DF2014:Ice#Bugs) that casting ice on the void tile and channeling it out again can fix it, but i'm hoping for a way to just have the computer do the work...

https://docs.dfhack.org/en/stable/docs/Plugins.html#tiletypes
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on October 19, 2020, 04:25:04 pm
is there a way to use dfhack to fix the "void tiles" that appear from d-z'ing ice ramps (http://www.bay12games.com/dwarves/mantisbt/view.php?id=1981)?

the wiki mentions (https://www.dwarffortresswiki.org/index.php/DF2014:Ice#Bugs) that casting ice on the void tile and channeling it out again can fix it, but i'm hoping for a way to just have the computer do the work...

https://docs.dfhack.org/en/stable/docs/Plugins.html#tiletypes

Additionally, the "probe" command will give you some relevant information about any tile you select with "k", which you could use to compare the problematic tile(s) to existing tiles and figure out which attributes to copy. "tiletypes" doesn't yet have a more user-friendly wrapper, unfortunately, but people here might be able to help if you run into issues with it.
Title: Re: DFHack 0.47.04-r3
Post by: HungThir on October 19, 2020, 06:30:01 pm
great, thanks!  in my current fort i've already repaired the damage by casting ice, but i seem to trip over this every time i play an embark with a frozen winter, so it's very nice to have some tricks up my sleeve for next time

(though, now that i understand what causes it, maybe i won't trip over it so much :-[)
Title: Re: DFHack 0.47.04-r3
Post by: Rinin_Rus on October 24, 2020, 02:50:17 pm
Is it any way to implement everyday (ingame) starting of some lua script?

It seems right now scripts could be executed once. Which is still amazing. But some kind of "cron" for dfhack may expand homebrew scripts possibilities to a new level. Am I overlooking any technical problems which prevents developing of such "cron" plugin?
Title: Re: DFHack 0.47.04-r3
Post by: myk on October 24, 2020, 03:15:47 pm
I don't think there is any barrier to a cron-type plugin. Buildingplan schedules itself to run twice per game day by looking at the tick count. It doesn't run exactly at day start, and ticks advanced while the game is paused throws off the accounting, but buildingplan doesn't need to be very accurate. A cron plugin could run every X tick counts and poll the in-game time and date to be more accurate.

The repeat script might also meet your needs: https://docs.dfhack.org/en/latest/docs/_auto/base.html#repeat
Title: Re: DFHack 0.47.04-r3
Post by: Rinin_Rus on October 24, 2020, 05:27:23 pm
Yep, seems "problem" does not exist, it's just me not properly understand LUA and API. It's possible to make "running" script without any extra plugins.
Title: Re: DFHack 0.47.04-r3
Post by: Rinin_Rus on October 27, 2020, 07:04:52 am
Is it possible to receive enum names in Lua?

Right now i'm making dictionary (table?)
Code: [Select]
Dict = {
    Socialize = df.need_type.Socialize,
    DrinkAlcohol = df.need_type.DrinkAlcohol,
    PrayOrMeditate = df.need_type.PrayOrMeditate,
    ...
}
Does any other way exist to access enum names, and list all enum values? Because such dictionary will require future maintenance. It's not like we have DF updates too often, but still.
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on October 27, 2020, 07:52:19 am
Is it possible to receive enum names in Lua?

Right now i'm making dictionary (table?)
Code: [Select]
Dict = {
    Socialize = df.need_type.Socialize,
    DrinkAlcohol = df.need_type.DrinkAlcohol,
    PrayOrMeditate = df.need_type.PrayOrMeditate,
    ...
}
Does any other way exist to access enum names, and list all enum values? Because such dictionary will require future maintenance. It's not like we have DF updates too often, but still.
df.need_type
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on October 27, 2020, 10:36:07 am
Since the forum software messed up the formatting, what Patrik posted was
Code: [Select]
df.need_type[x]

DF enums are exposed to Lua as a bidirectional map - here's some examples from the lua interpreter:
Code: [Select]
[lua]# ~df.need_type[0]
Socialize
[lua]# ~df.need_type.Socialize
0
[lua]# ~df.need_type['Socialize']
0

I guess this is another thing that is a bit lacking in documentation - https://docs.dfhack.org/en/stable/docs/Lua%20API.html#named-types contains the following, but doesn't go into much more detail:
Quote from: https://docs.dfhack.org/en/stable/docs/Lua%20API.html#named-types
In addition to this, enum and bitfield types contain a bi-directional mapping between key strings and values, and also map _first_item and _last_item to the min and max values.

If you need to iterate over the enum, you can use ipairs(df.need_type) for that (but there's no need to do that just to build the table you want, since it already exists).
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on October 27, 2020, 12:18:09 pm
Thanks for sorting that out, lethosor.
Title: Re: DFHack 0.47.04-r3
Post by: andrian on October 28, 2020, 05:58:26 pm
So, I know nothing about LUA scripting, and I know that what I want should be relatively simple, so I'm hoping someone can help me out here. I want a script that will run periodically and just do some basic maintenance to my fort. Everything I want to do is stuff I can do in DFHack with basic scripts, but which I'd rather not type out regularly. Simple things like making the dwarves happy (since that's basically impossible to do any other way right now), removing the frayed socks nobody is wearing, destroying any seeds that might be stuck in cages, and whatever other things I might want done regularly - say every season or so. I know there are scripts that do similar things, but I don't really know how to read them, and as I can't imagine wanting to do anything more complicated than this right now, I thought I'd ask if someone could help me out by writing up a script that will run automatically when the season changes and telling me how to call DFHack scripts and commands using lua, and where to put them within the script.
Title: Re: DFHack 0.47.04-r3
Post by: myk on October 28, 2020, 07:19:53 pm
If you know the individual commands that you need to run, you can just write them to a text file and then auto-run those commands with the repeat script.

For example, say you want to run the 'cleanowned' script and save your game once a month. You could write a text file named maintenance.txt in your DF directory with the following contents:

Code: [Select]
cleanowned X
quicksave

then put this in your onMapLoad.init file:

Code: [Select]
repeat -name maintenance -time 1 -timeUnits months -command [ script maintenance.txt ]
I haven't tested the above, so if anyone spots any errors in those instructions, please chime in. But this general technique should be able to get you what you want.
Title: Re: DFHack 0.47.04-r3
Post by: Bumber on October 28, 2020, 07:45:17 pm
You could also use multicmd instead of a separate text file.
Title: Re: DFHack 0.47.04-r3
Post by: andrian on October 29, 2020, 12:58:50 am
If you know the individual commands that you need to run, you can just write them to a text file and then auto-run those commands with the repeat script.

For example, say you want to run the 'cleanowned' script and save your game once a month. You could write a text file named maintenance.txt in your DF directory with the following contents:

Code: [Select]
cleanowned X
quicksave

then put this in your onMapLoad.init file:

Code: [Select]
repeat -name maintenance -time 1 -timeUnits months -command [ script maintenance.txt ]
I haven't tested the above, so if anyone spots any errors in those instructions, please chime in. But this general technique should be able to get you what you want.

I don't see any file labeled onMapLoad.init. If I create one in the main DF directory, will DFHack run it automatically when the map loads?
Title: Re: DFHack 0.47.04-r3
Post by: myk on October 29, 2020, 01:27:27 am
That's the idea, yeah :-) more info on init files here (https://docs.dfhack.org/en/latest/docs/Core.html#other-init-files)
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 29, 2020, 05:03:45 pm
I still haven't gotten any confirmation email from DFFD.  How long is this supposed to take?
Title: Re: DFHack 0.47.04-r3
Post by: myk on October 29, 2020, 05:35:04 pm
I don't know, but I'd suggest:

1. Check your spam folder, and if nothing relevant is in there, then
2. Upload the archive to your Google drive and set the share settings to allow public access. You can always delete it later and get the space back
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 29, 2020, 06:54:41 pm
Just found the confirmation in my spam folder.  The link expired yesterday.  Gonna have to register again.

Edit:

Ok, the part in the email about the link expiring in 15 days turned out to not exactly be true.  I've activated the account and I can now log in.

Now to remember what I was going to do back on the 13th...

Ah, yes!  Time to fire up DF for the first time in more than 2 weeks and make some screenshots...

Edit2:

Interesting...  Now I seem to be unable to reproduce the problem I had on the 13th.

Anyways, I've edited the embarks geo biome with biomemanipulator.  Time to embark carefully...

Edit3:

I aborted the game because I rolled a bad starting seven and for some reason when I went back in it appears that all the changes I made with biomemanipulator were lost.  Does anyone know how to make biomemanipulator changes permanent?
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on October 30, 2020, 04:05:08 am
To make Biome Manipulator changes stick the game has to be saved, and I don't know a way to save while in the embark mode. You can embark somewhere uninteresting, and then abandon, as that ought to lead to a save (I've never actually tried that method, though).

However, you can avoid a repeat to some extent by using Dwarf Therapist to check your starting 7 (it does work during your careful planning phase) and abort the embark effort if you don't like the dorfs. You're then back to the embark screen and can make a new attempt at the same location. Since you haven't exited DF the changes remain (but be careful with Region Manipulation changes: they are lost when focus is changed, so there's a significant risk those changes have to be redone).
Title: Re: DFHack 0.47.04-r3
Post by: myk on October 30, 2020, 10:58:33 am
If you restart when you get a bad starting seven, the armoks-blessing (https://docs.dfhack.org/en/stable/docs/_auto/base.html#armoks-blessing) script might be useful for you. I've actually written a variant of that script that is slightly less overpowered. instead of setting all skill for all dwarves to 20, it bumps the skills that already have at least a point in them to 5 (in addition to elevating all mental and physical attributes to an ideal). I can submit that variation for inclusion in DFHack if there is interest.
Title: Re: DFHack 0.47.04-r3
Post by: A_Curious_Cat on October 30, 2020, 01:24:30 pm
However, you can avoid a repeat to some extent by using Dwarf Therapist to check your starting 7 (it does work during your careful planning phase) and abort the embark effort if you don't like the dorfs. You're then back to the embark screen and can make a new attempt at the same location. Since you haven't exited DF the changes remain

That's exactly what I did.  And the changes still got lost, even though I never actually fully exited out of DF.

Btw, the ability to look at the starting seven's stats during the planning carefully stage is one of the best things since sliced bread.
Title: Re: DFHack 0.47.04-r3
Post by: Uthimienure on October 30, 2020, 08:59:30 pm
Is it just me, or is dwarfvet not working properly?

I've followed the instructions below. In DFHack "dwarfvet enable" works, and "dwarfvet report" shows an animal hospital at the correct location, which is accessible to all the injured animals.  DFHack lists them all "Telling intelligent unit 17843 (etc.) to report to the hospital".  They wander around looking for it and I get spammed repeatedly:  "(animal) cancels Rest: Area inaccessible."
Spoiler (click to show/hide)
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on October 30, 2020, 10:23:45 pm
That sounds to me like this issue, which was reported recently: https://github.com/DFHack/dfhack/issues/1681
Unless that's you under a different name, it's not just you having the issue, although I'm not aware of any further attempts at diagnosing/fixing it at this point.
Title: Re: DFHack 0.47.04-r3
Post by: Nilsolm on October 31, 2020, 09:16:03 am
Is it just me, or is dwarfvet not working properly?

I've followed the instructions below. In DFHack "dwarfvet enable" works, and "dwarfvet report" shows an animal hospital at the correct location, which is accessible to all the injured animals.  DFHack lists them all "Telling intelligent unit 17843 (etc.) to report to the hospital".  They wander around looking for it and I get spammed repeatedly:  "(animal) cancels Rest: Area inaccessible."
Spoiler (click to show/hide)

Strangely enough, I can't reproduce the issue with DFHack 0.47.04-r3. Animals seem to be able to path to the hospital area just fine. Can you upload a save file maybe? I can have a look at it.
Title: Re: DFHack 0.47.04-r3
Post by: Uthimienure on October 31, 2020, 11:14:57 am
That sounds to me like this issue, which was reported recently: https://github.com/DFHack/dfhack/issues/1681
Unless that's you under a different name, it's not just you having the issue, although I'm not aware of any further attempts at diagnosing/fixing it at this point.

That's not me, but it sounds exactly like what's happening.
BTW I'm on DF 0.47.04 with Hack 0.47.04-r1-Windows-64bit

Quote
Nilsolm:
Strangely enough, I can't reproduce the issue with DFHack 0.47.04-r3. Animals seem to be able to path to the hospital area just fine. Can you upload a save file maybe? I can have a look at it.

Thanks! Here's the save:
https://dffd.bay12games.com/file.php?id=15281
Title: Re: DFHack 0.47.04-r3
Post by: Nilsolm on October 31, 2020, 03:30:23 pm

Quote
Nilsolm:
Strangely enough, I can't reproduce the issue with DFHack 0.47.04-r3. Animals seem to be able to path to the hospital area just fine. Can you upload a save file maybe? I can have a look at it.

Thanks! Here's the save:
https://dffd.bay12games.com/file.php?id=15281

Cheers, I had a look, but I can't reproduce it with your save either. I can slap down an animal hospital zone anywhere and animals will be able to path to it. You mentioned that you're using  DFHack 0.47.04-r1. You could try upgrading to 0.47.04-r3, because the problem doesn't seem to occur with that version.

I am running into other problems though:
I'll try to debug these issues once I get access to a functioning Linux system.
Title: Re: DFHack 0.47.04-r3
Post by: Uthimienure on October 31, 2020, 05:05:10 pm
Thanks for taking the time to do that.  Yes, I debated upgrading to 0.47.04-r2 and then r3 when they were released but I'm afraid of messing things up and decided to wait until I start a new fort because this one has been one of my most fun forts.  This animal hospital problem isn't a game killer so I'm alright.
Title: Re: DFHack 0.47.04-r3
Post by: Rinin_Rus on October 31, 2020, 05:45:54 pm
What should I do to prepare a dwarf before sending him to burrow to avoid being stuck with previous activity?

Right now I'm doing only
Code: [Select]
dfhack.job.removeWorker(unit.job.current_job, 1)But it seems it's not enough, because I already had dwarfs stuck "socialising", and plant gatherers can't finish the task because "dropoff inaccessible" inside burrow. It also probably not gonna work with different noble interactions.
Could I do something like:
Code: [Select]
unit.military.individual_drills = {}
unit.social_activities = {}
unit.conversations = {}
unit.activities = {}
And if I could, should I? What pitfalls may arise from it?
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on November 01, 2020, 04:52:06 am
What should I do to prepare a dwarf before sending him to burrow to avoid being stuck with previous activity?

Right now I'm doing only
Code: [Select]
dfhack.job.removeWorker(unit.job.current_job, 1)But it seems it's not enough, because I already had dwarfs stuck "socialising", and plant gatherers can't finish the task because "dropoff inaccessible" inside burrow. It also probably not gonna work with different noble interactions.
Could I do something like:
Code: [Select]
unit.military.individual_drills = {}
unit.social_activities = {}
unit.conversations = {}
unit.activities = {}
And if I could, should I? What pitfalls may arise from it?

- Any dorf in the process of delivering something to a stockpile will probably have to be relieved of the object hauled.
- Based on my burrowing experience, forcibly cutting off needs activities is unlikely to be successful, as I've had dorfs take up socializing after they were burrowed: it seems there is no check that the "work target" is within the burrow if the dorf is in the tavern when the job check is performed. I'm not sure about this, but I think I've see dorfs being burrowed when outside of the tavern walk to the tavern and then start socializing.
- In my view "individual drill" is a stupid thing that shouldn't be in DF, as it almost totally negates the effect of giving militia time off, as they'll spend almost all their time on drills rather than catching up on civilian jobs and fulfilling needs. I work around it by manually removing the training facilities from squads when they're taken off duty and adding them back they they're sent on duty. Of course, that means that the schedule has to be managed manually, so setting up a long term schedule becomes pointless.

The best way to block need fulfillment "jobs" to be taken illegally is probably to ensure there is a "proper" job available in the burrow (such as e.g. a lever pull for a lever with that particular dorf as the only permitted user). You still have the issue with uninterruptible needs fulfillment, but I'd hesitate to try to override that.

Side effects? Who knows? Those who try to hack it are those who will find out.
Title: Re: DFHack 0.47.04-r3
Post by: Rinin_Rus on November 01, 2020, 09:38:49 am
Quote
- Any dorf in the process of delivering something to a stockpile will probably have to be relieved of the object hauled.
Seems so, but I'm still can't find how to do so, using dfhack.

Quote
as I've had dorfs take up socializing after they were burrowed:
Did they start socializing before or after burrow assignment? Because I had the same issue, but they probably started before assignment, and even the destruction of the guild hall didn't stop them from socialising in it's former location.

Quote
The best way to block need fulfillment "jobs" to be taken illegally is probably to ensure there is a "proper" job available in the burrow (such as e.g. a lever pull for a lever with that particular dorf as the only permitted user). You still have the issue with uninterruptible needs fulfillment, but I'd hesitate to try to override that.
That's exactly opposite of what I'm doing now. Basically I want to move dwarfs to burrows based on their needs, so they have no other jobs to do till they are finished fulfiling their needs. If someone is interested script could be found here (http://needburrow.rinin.ru/)
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on November 01, 2020, 01:52:32 pm
I have no idea if it's useful, but it's possible to use DFHack to change the location of an item (to the ground beneath the character, and to remove the connection of the item being in the inventory of the dorf from both.

The experience I had was that they took up socializing after being interrupted from their previous task by the burrowing.

Yes, you want them to get to the burrow to socialize, procreate, etc., but a "proper" job task will help you to actually get the buggers to haul their sorry asses there. Note, though the they have a tendency to escape the burrow because the perform the job, then walk away for 10 steps or so before checking what to do next. The "walk away" thing does not respect burrows, and so can easily take the bugger out of it. Once outside, the won't go back inside unless given a "job" there, and if they don't feel the need to socialize/eat/drink/sleep/... they just root themselves on the spot until the eventually do feel a need.
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on November 09, 2020, 10:11:42 pm
A heads-up: I'm planning to do another release soon (maybe in a week? real life things have caught up to me and delayed this a bit)

It would be great to have people test it out beforehand - there are lots of buildingplan and quickfort changes, thanks to Myk. I'm reasonably confident that they work, but more eyes on it would always be appreciated. As usual:
- Nightly builds can be found at https://dfhack.org/builds
- Issues can be reported here or at https://github.com/dfhack/dfhack/issues - if you're using a nightly build, please include the exact version number (as reported by the console, e.g. "0.47.04-r3-92-g3aa902bd") or build number
Title: Re: DFHack 0.47.04-r3
Post by: Rumrusher on November 11, 2020, 06:17:33 am
ok just now notice my copy of advfort isn't working with buildings and just realize it's because someone changed the module stuff to be a dfhack_flag. check in advfort_items.
odd time to realize there been a revamp to the code structure but I hope I don't have to like edit some important dfhack file to connect a different script to advfort_items, or dummy out that line of code in advfort_item?
edit: it seems the 'require' code got changed to reqscripts .... so I dread if I have to rewrite a whole bunch of my scripts or just the scripts that touch dfhack stuff.
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on November 11, 2020, 01:03:59 pm
ok just now notice my copy of advfort isn't working with buildings and just realize it's because someone changed the module stuff to be a dfhack_flag. check in advfort_items.
odd time to realize there been a revamp to the code structure but I hope I don't have to like edit some important dfhack file to connect a different script to advfort_items, or dummy out that line of code in advfort_item?
edit: it seems the 'require' code got changed to reqscripts .... so I dread if I have to rewrite a whole bunch of my scripts or just the scripts that touch dfhack stuff.

Could you clarify exactly what is broken? Is advfort.lua in the DFHack repository not working, or is this your own copy? If it's your own, is there any particular reason you're maintaining your own copy? Are there changes that you would like included in DFHack's version?

I did change how advfort_items needs to be imported in https://github.com/DFHack/scripts/commit/ad67c79f8074a491c144144b2825cd05c80a2236 - it was previously the only script in the scripts repo to use mkmodule() and work with require(), so I changed it for consistency. This did also require changing the require() calls in two places in advfort.lua (see the diff (https://github.com/DFHack/scripts/commit/ad67c79f8074a491c144144b2825cd05c80a2236#diff-0050b00a1fb3cc1d2c200b0f5faa661bf560d515cb852531424a2522c6a16566) for exactly what changed) - those should be all that you need to change on your end, unless you've added more. advfort_items should still be able to be used in exactly the same way, but let me know if there are other issues.

Edit: oh, I think you might have figured it out already. The recommended way to share functions/etc. between scripts is to use reqscript() or script_environment() along with a module check - see the diff above for examples. There is no hard requirement to do it this way for scripts outside of the DFHack/scripts repo, and advfort is the only one I know of that changed recently.
Title: Re: DFHack 0.47.04-r3
Post by: Rumrusher on November 13, 2020, 09:41:05 am
ok just now notice my copy of advfort isn't working with buildings and just realize it's because someone changed the module stuff to be a dfhack_flag. check in advfort_items.
odd time to realize there been a revamp to the code structure but I hope I don't have to like edit some important dfhack file to connect a different script to advfort_items, or dummy out that line of code in advfort_item?
edit: it seems the 'require' code got changed to reqscripts .... so I dread if I have to rewrite a whole bunch of my scripts or just the scripts that touch dfhack stuff.

Could you clarify exactly what is broken? Is advfort.lua in the DFHack repository not working, or is this your own copy? If it's your own, is there any particular reason you're maintaining your own copy? Are there changes that you would like included in DFHack's version?

I did change how advfort_items needs to be imported in https://github.com/DFHack/scripts/commit/ad67c79f8074a491c144144b2825cd05c80a2236 - it was previously the only script in the scripts repo to use mkmodule() and work with require(), so I changed it for consistency. This did also require changing the require() calls in two places in advfort.lua (see the diff (https://github.com/DFHack/scripts/commit/ad67c79f8074a491c144144b2825cd05c80a2236#diff-0050b00a1fb3cc1d2c200b0f5faa661bf560d515cb852531424a2522c6a16566) for exactly what changed) - those should be all that you need to change on your end, unless you've added more. advfort_items should still be able to be used in exactly the same way, but let me know if there are other issues.

Edit: oh, I think you might have figured it out already. The recommended way to share functions/etc. between scripts is to use reqscript() or script_environment() along with a module check - see the diff above for examples. There is no hard requirement to do it this way for scripts outside of the DFHack/scripts repo, and advfort is the only one I know of that changed recently.
the thing that got me confused was the module check otherwise thanks for the clear up.
to answer the question about having a copy of advfort... it's so I could do modifications and add fort mode jobs and or see if I could add more fort mode jobs... which now that I remember this I might have to change and patch my companionfort scripts as they were old copies of advfort that used that old set up to connect to advfort_items.
Title: Re: DFHack 0.47.04-r3
Post by: Evans on November 14, 2020, 07:11:43 pm
timestream.lua

In new version you have removed the ability to slow down calendar speed.

Why?


I was using timestream exclusively for this reason, because I hate how one day takes 14 seconds in vanilla.
Would you kindly reconsider adding ability to slow down time back in?
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on November 15, 2020, 12:41:27 am
We've only included timestream.lua since 0.47.04-r3, which is currently the latest version. It is a heavily modified version of a script originally by IndigoFenix, though - were you using that? I didn't think it worked in 0.47.04 as-is. If not, where did you get timestream.lua from previously?

We could try adding that feature, but since I'm not aware of it being intentionally removed, I'm not really sure where to look. Are you asking for something like "-rate 0.25" to work? From looking through the code briefly, I think that should work as-is (at least, I don't see anything actively preventing it from working).
Title: Re: DFHack 0.47.04-r3
Post by: Rumrusher on November 16, 2020, 11:21:48 am
We've only included timestream.lua since 0.47.04-r3, which is currently the latest version. It is a heavily modified version of a script originally by IndigoFenix, though - were you using that? I didn't think it worked in 0.47.04 as-is. If not, where did you get timestream.lua from previously?

We could try adding that feature, but since I'm not aware of it being intentionally removed, I'm not really sure where to look. Are you asking for something like "-rate 0.25" to work? From looking through the code briefly, I think that should work as-is (at least, I don't see anything actively preventing it from working).
ok so I thought timestream was something that mess with the calendar for loading in fort mode or adventure mode but yeah good to see someone legit uses it... but it is in my copy of r3.
Title: Re: DFHack 0.47.04-r3
Post by: Luckyowl on November 16, 2020, 02:31:58 pm
Hi guys, I want to know if it's possible to give an armor attributes boost using the item-tigger mod tool?
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on November 16, 2020, 05:35:15 pm
ok so I thought timestream was something that mess with the calendar for loading in fort mode or adventure mode but yeah good to see someone legit uses it... but it is in my copy of r3.

Yes, it's part of 0.47.04-r3, but so far, DFHack has only included it in that version, hence my confusion. To my knowledge, the version we've included is an updated and fixed version of an older script that didn't work in 0.47, so in order to address Evans' feedback (i.e. "why did you remove X, can you please re-add it"), I would need to know where the version of the script that Evans was previously using came from.

Hi guys, I want to know if it's possible to give an armor attributes boost using the item-tigger mod tool?
modtools/item-trigger, right? I've never used it, but it does appear to make the ID of the defending unit available (as \\DEFENDER_ID), so you could probably adjust the defending unit's armor on the fly. Perhaps it would be easier to adjust armor attributes beforehand, though.
Title: Re: DFHack 0.47.04-r3
Post by: Luckyowl on November 16, 2020, 06:20:54 pm

Hi guys, I want to know if it's possible to give an armor attributes boost using the item-tigger mod tool?
modtools/item-trigger, right? I've never used it, but it does appear to make the ID of the defending unit available (as \\DEFENDER_ID), so you could probably adjust the defending unit's armor on the fly. Perhaps it would be easier to adjust armor attributes beforehand, though.

Thank you for replying! Can you tell me how I can adjust armor attributes beforehand?
Title: Re: DFHack 0.47.04-r3
Post by: Uthimienure on November 16, 2020, 06:53:08 pm
You can adjust values in:

DF folder/raw/objects/item_armor.txt

But to make it apply to an in-progress game, you have to also make the changes in the same raw file of the saved game.
I'm assuming the changes would only apply to newly created armor, but not sure on that.
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on November 16, 2020, 06:55:38 pm
Thank you for replying! Can you tell me how I can adjust armor attributes beforehand?
Well, it depends on what you want to do. I was thinking just modifying the raws would work for some changes to armor, if you want them to always be in effect. I'm also not very familiar with how the combat system works in general, so other people might have better ideas.

Edit: thanks, Uthimienure!
My understanding is that modifying some traits in the save-specific raws would affect all matching items in-game, but some (e.g. the initial state of certain values) would only apply to new items. Adding new items wouldn't work in an existing world, though - this thread (http://www.bay12forums.com/smf/index.php?topic=29157.0) in the modding forum goes into some detail about it.
Title: Re: DFHack 0.47.04-r3
Post by: Luckyowl on November 16, 2020, 07:06:17 pm
You can adjust values in:

DF folder/raw/objects/item_armor.txt

But to make it apply to an in-progress game, you have to also make the changes in the same raw file of the saved game.
I'm assuming the changes would only apply to newly created armor, but not sure on that.


Oh no, What I want to do is to give an armor an effect only when the armor is worn. Like for example: If unit_1 has a tier 1 attribute and if unit_1 equips an armor that gives 1+ to atribute then Unit_1 now has a tier 2 attribute. That's what I'm trying to do. But I can't find any threads about this and to be honest the DFhack Lua doc overwhelms me with vast possibilities.
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on November 16, 2020, 07:17:33 pm
Oh, so you're probably more interested in detecting when a unit puts on a piece of armor, then. From what I can gather from the docs (https://docs.dfhack.org/en/stable/docs/_auto/modtools.html#modtools-item-trigger), something like this might help:

Code: [Select]
modtools/item-trigger -onEquip Worn -itemType ARMOR -command [ my-script \\ITEM_ID \\UNIT_ID ]

This would rely on a separate my-script.lua that you write, which would receive an item ID and unit ID as arguments, and could use df.item.find() and df.unit.find() to obtain references to the items/units themselves. (From that point, I don't know exactly how you'd check or adjust the traits you're interested in off the top of my head.)
Title: Re: DFHack 0.47.04-r3
Post by: Luckyowl on November 16, 2020, 08:10:13 pm
Oh, so you're probably more interested in detecting when a unit puts on a piece of armor, then. From what I can gather from the docs (https://docs.dfhack.org/en/stable/docs/_auto/modtools.html#modtools-item-trigger), something like this might help:

Code: [Select]
modtools/item-trigger -onEquip Worn -itemType ARMOR -command [ my-script \\ITEM_ID \\UNIT_ID ]

This would rely on a separate my-script.lua that you write, which would receive an item ID and unit ID as arguments, and could use df.item.find() and df.unit.find() to obtain references to the items/units themselves. (From that point, I don't know exactly how you'd check or adjust the traits you're interested in off the top of my head.)

ah! thank you, quick question, what do I put in  df.item.find() and df.unit.find()? do I do something like this?

df.item.find(ITEM_ARMOR_HELM)?
 
Title: Re: DFHack 0.47.04-r3
Post by: Luckyowl on November 16, 2020, 08:22:58 pm
Spoiler (click to show/hide)

would something like this work?
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on November 16, 2020, 09:22:00 pm
find() takes the ID, which would be passed to my-script.lua by the modtools/item-trigger command when a matching event occurs. You wouldn't need to check for "onEquip" in the script itself - armorType couldn't be equal to "ITEM_ARMOR_HELM" and "onEquip" at the same time, and modtools/item-trigger would already only run your custom script for equip events of the "Worn" mode.

I guess I was thinking something along these lines for my-script.lua (which can be renamed, of course):
Code: [Select]
local args = ...
local item = df.item.find(args[1])
local unit = df.unit.find(args[2])
-- do stuff with unit, item

I'm not sure if there are any existing examples for what you want to do - have you written a Lua script before? If not, https://www.lua.org/start.html has some resources that might be useful for Lua in general.
Title: Re: DFHack 0.47.04-r3
Post by: MC on November 17, 2020, 11:08:06 am
Question about the family affairs plugin, was there some specific reason it was limited to fortress mode? As far as I can tell virtually none of the checks it runs to see if someone is eligible for marriage actually matter (from a "not crashing the game" sense at least, I get that filtering out hostiles, children, and the insane help prevent accidentally sticking yourself with unproductive relationships). Is there some adv mode specific weirdness I'm missing?
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on November 17, 2020, 05:26:59 pm
Question about the family affairs plugin, was there some specific reason it was limited to fortress mode? As far as I can tell virtually none of the checks it runs to see if someone is eligible for marriage actually matter (from a "not crashing the game" sense at least, I get that filtering out hostiles, children, and the insane help prevent accidentally sticking yourself with unproductive relationships). Is there some adv mode specific weirdness I'm missing?
Apart from adventurers being a special kind of asexual?
Title: Re: DFHack 0.47.04-r3
Post by: MC on November 17, 2020, 05:48:52 pm
I mean it doesn't have to target the adventurer does it? I was just wondering if there was some weird crash with unloading sites or something that I was missing. I don't think family affairs even cares about orientation all that much anyways.
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on November 18, 2020, 07:13:49 am
The other good reason I can think of is testing. If the script author isn't interested in adventure mode there is very little incentive to test the script in it (or to deal with complaints about it not working in adventure mode).
Title: Re: DFHack 0.47.04-r3
Post by: MC on November 18, 2020, 08:39:45 am
Sounds reasonable. Just wanted to make sure there wasn't some arcane reasoning I was missing. Thanks!
Title: Re: DFHack 0.47.04-r3
Post by: Evans on November 19, 2020, 09:51:00 am
We've only included timestream.lua since 0.47.04-r3, which is currently the latest version. It is a heavily modified version of a script originally by IndigoFenix, though - were you using that? I didn't think it worked in 0.47.04 as-is. If not, where did you get timestream.lua from previously?

We could try adding that feature, but since I'm not aware of it being intentionally removed, I'm not really sure where to look. Are you asking for something like "-rate 0.25" to work? From looking through the code briefly, I think that should work as-is (at least, I don't see anything actively preventing it from working).
-rate 0.25 resets to default fps instead, making game to run at 1x speed.
Code: [Select]
        if rate ~= 1 then
            last_frame = df.global.world.frame_counter
            --if rate > 0 then            -- Won't behave well with unit simulation
            if rate > 1 and not simulating_desired_fps then
                print('timestream: Time running at x'..rate..".")
            else
                print('timestream: Time running dynamically to simulate '..desired_fps..' FPS.')
                if rate ~= 0 then
                    print('timestream: Rate setting ignored.')
                end

I'm using some older version, but it works very well - at least at slowing calendar, I'm sure other things may be affected in funny way.


Anyway, I'm having crashes in DF by totally different reasons now:
Class not in symbols.xml: 'viewscreen_unitlaborsst': vtable = 0x7fedc200ff0

This happens when I try to manage labour and enable herbalist job for my dwarves.
File search points to \Dwarf Fortress\hack\plugins\manipulator.plug.dll

I have dfhack-0.47.04-r3-Windows-64bit now.
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on November 19, 2020, 01:08:31 pm
-rate 0.25 resets to default fps instead, making game to run at 1x speed.
Okay, I see the relevant code now, although it's right after the snippet you posted - if you comment out the "rate = 1" line (add "--" to the beginning of it), does that do what you want?
Quote
I'm using some older version, but it works very well
If my suggestion doesn't work, it would be very helpful to know where you got this older version from (or to have a copy of it).

Quote
Anyway, I'm having crashes in DF by totally different reasons now:
Class not in symbols.xml: 'viewscreen_unitlaborsst': vtable = 0x7fedc200ff0
The message you pasted is a harmless diagnostic message that is not related to the crash. It's in stderr.log because it's occasionally useful for development. Is there any way we could make it clearer that it is not an error? Would having something like "INFO:" prepended make it clearer?

Quote
This happens when I try to manage labour and enable herbalist job for my dwarves.
I'm having trouble reproducing this. I was able to enable herbalism on around 100 dwarves across two forts with no crash.
Does it happen exactly when you press "Enter" with herbalism selected for a dwarf, or at some later time? Are you able to reproduce it consistently? Does it only occur for specific dwarves? Are you using any mods?
Title: Re: DFHack 0.47.04-r3
Post by: Evans on November 20, 2020, 03:43:27 am
-rate 0.25 resets to default fps instead, making game to run at 1x speed.
Okay, I see the relevant code now, although it's right after the snippet you posted - if you comment out the "rate = 1" line (add "--" to the beginning of it), does that do what you want?
I'll give it a go.


Quote
Quote
I'm using some older version, but it works very well
If my suggestion doesn't work, it would be very helpful to know where you got this older version from (or to have a copy of it).
Mkay. I'm sure I got it from *somewhere* near the original author. If the above does not work, I'll post my ancient script here.


Quote
I'm having trouble reproducing this. I was able to enable herbalism on around 100 dwarves across two forts with no crash.
Does it happen exactly when you press "Enter" with herbalism selected for a dwarf, or at some later time? Are you able to reproduce it consistently? Does it only occur for specific dwarves? Are you using any mods?
Mods were most likely conflict source. I've refreshed DFhack from the latest release and now all the problems are gone.
For the moment anyway.

Thank you for your answers. I'll take a look at timestream.
Title: Re: DFHack 0.47.04-r3
Post by: Evans on November 20, 2020, 04:44:14 am
commenting that line out does not seem to be doing anything.

I don't think it will help you much, but here is what is inside my ancient timestream.lua:
Spoiler (click to show/hide)
Title: Re: DFHack 0.47.04-r3
Post by: Ramiel. on November 21, 2020, 07:29:55 pm
Hey, just wanted to throw out real quick that I just got dfhack-run.exe reported as a trojan like several others recently.  I see it's happened to multiple users now, such as here (http://www.bay12forums.com/smf/index.php?topic=177538.0) and here (http://www.bay12forums.com/smf/index.php?topic=177456.0).  Using dfhack 0.47.04-r2, downloaded and installed directly from github on 8/30, run several times since then with no issues but only today it registered as a Trojan. I didn't even run Dwarf Fortress, just opened the folder containing it. Microsoft Security Essentials (on Win7) detected it as "MSIL/Stealer.RS!MTB". Microsoft's page (https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?name=Trojan%3aMSIL%2fStealer.RS!MTB&threatid=2147764475) on the file was made/updated on Sept 23.
I'm sure it's just a false positive, and I'll just be adding it as an exception in my system, but I thought I'd give my experience as an extra data point, give what info I have in case developers want to look into why this is happening/how to stop it.  Either way keep up the fantastic work you guys do, it's so very appreciated.
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on November 21, 2020, 08:38:15 pm
There isn't much we can do about that, unfortunately. dfhack-run itself hasn't changed very much (https://github.com/DFHack/dfhack/commits/develop/library/dfhack-run.cpp) in recent years, so this is almost certainly an issue with antivirus definitions.

I would be curious to know if 0.47.04-r3 also triggers the same detection, though. If it does, and 0.47.03-beta1 does not, then it could be related to the color change from March. Otherwise, my reasoning above would still apply.
Title: Re: DFHack 0.47.04-r3
Post by: Evans on November 22, 2020, 10:56:45 am
Scripting question.

I'm trying to restore ancient cage-thrower script into working order.
I'm java guys myself, and LUA was always incredibly weird for me, but after scouring through dozen lua files and some mods, I have finally managed to (almost) restore this script.

Here is how it looks like now (I might refactor it later):
Spoiler (click to show/hide)
Now the gun shots nets, they hit the target and put it in the cages just fine.

But I'm getting this error here:
Quote
hack/scripts/cageammo.lua:74: Cannot read field unit.relations: not found.

Say waaat?

How do I access relations now? How do I change 'following' flag?

And finally - is there a list of these fields for different objects somewhere?
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on November 22, 2020, 11:21:09 am
All the fields known by the DFHack community are documented as XML files, and yes, I think the relations thing has changed over the years.

In addition to using the XML files, you can also use gui/gm-editor to look at structures (which is often easier). For the unit structure, select any unit in a fortress (probably works in adventure mode as well) and invoke gui/gm-editor from the DFHack terminal. This allows you to browse the structure, and thus see what the current one looks like.
Title: Re: DFHack 0.47.04-r3
Post by: Evans on November 22, 2020, 12:58:26 pm
All the fields known by the DFHack community are documented as XML files, and yes, I think the relations thing has changed over the years.
Where would these xml files? I can only see symbols and some files in stonesense folder.

Quote
In addition to using the XML files, you can also use gui/gm-editor to look at structures (which is often easier). For the unit structure, select any unit in a fortress (probably works in adventure mode as well) and invoke gui/gm-editor from the DFHack terminal. This allows you to browse the structure, and thus see what the current one looks like.
Thanks. I have ocd when it comes to dealing with problems in the code. To the point, where I can sit for two days straight doing nothing else. But I'm learning to deal with it by asking other people. Kind of works ;)

Anyway.
The field following is there, but its nil and does not seem to be do anything.
After fixing the code, it seems like it is doing nothing now, but LUA keeps executing and now this:
Code: [Select]
unit_ref = df.general_ref_contains_unitst:new()
unit_ref.unit_id = unit.id
cage.general_refs:insert('#',unit_ref)
...causes everybody interested to follow the caged creature.

I'll comment it out and see if it works (previously as execution broke earlier, this block wasn't executing and at least my hunter ignored caged animal).

If I get this all working I'll upload whole this as a standalone package for anyone interested.



Edit:
...and they no longer follow the cage with an animal, but now game does not know how to get to this animal either.
Any quick way to clear their interest?
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on November 22, 2020, 05:27:51 pm
The XML files are on github, in one of the DFHack projects you'd download if you wanted to develop code.
Title: Re: DFHack 0.47.04-r3
Post by: mross on November 22, 2020, 05:40:08 pm
what does the second column in the auto cut gems menu represent? documentation doesn't say anything about it
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on November 22, 2020, 05:59:57 pm
what does the second column in the auto cut gems menu represent? documentation doesn't say anything about it
Could you clarify which screen you're talking about or provide a screenshot?
Title: Re: DFHack 0.47.04-r3
Post by: mross on November 22, 2020, 06:03:00 pm
what does the second column in the auto cut gems menu represent? documentation doesn't say anything about it
Could you clarify which screen you're talking about or provide a screenshot?

(https://i.imgur.com/diN6zbE.png)
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on November 22, 2020, 07:30:22 pm
Those are the tiles that are specified in the raws for those gems. If those aren't the tiles you see in-game, are you using TWBT? We likely wouldn't be able to support tilesets that require TWBT in this particular screen, unfortunately.
Title: Re: DFHack 0.47.04-r3
Post by: mross on November 22, 2020, 07:35:29 pm
Those are the tiles that are specified in the raws for those gems. If those aren't the tiles you see in-game, are you using TWBT? We likely wouldn't be able to support tilesets that require TWBT in this particular screen, unfortunately.
Got it, thanks. I was wondering if they were like an indication of rarity or value or something.
Title: Re: DFHack 0.47.04-r3
Post by: Rumrusher on November 25, 2020, 08:18:42 am
so went back and reworked some of my recruit scripts to now steal members from other sites and bring them to your fort.

Code: ('SnatchErase.lua') [Select]
for de,oe in pairs(df.global.world.army_controllers.all) do
if oe.mission_report == nil then else
print ( de,oe.mission_report.title)
for si,te in pairs(df.global.world.world_data.sites) do
local Sito=te.id
if oe.site_id== Sito then
local SitePool=df.global.world.world_data.sites[si].unk_1.nemesis
for e,o in pairs(df.global.world.armies.all) do
if oe.id == o.controller_id then
print (e)
local forv=df.global.world.armies.all[e].members[0]
df.global.world.armies.all[e].members:insert("#",{new=true,nemesis_id=SitePool[dfhack.random.new():random(#SitePool)],
stored_fat = forv.stored_fat,
unk_2c= forv.unk_2c,
unk_28= forv.unk_28,
unk_1= forv.unk_1,
unk_30= forv.unk_30,
unk_34= forv.unk_34})

for Del,ete in pairs(df.global.world.armies.all[e].members) do
for De,ee in pairs(SitePool) do
if ete.nemesis_id== ee then
SitePool:erase(De) 
end
end
end
end
end
end
end
end
end
so you run this script while your squad is off on a mission now this works if the squad is targeting a site, so far it doesn't work with searching for artifacts or going on messenger missions.
and you can repeatedly use the script so if you say see a 20 population site you could use this script 20 times and grab the whole population.

the folks you snatch will seek sanctuary so their labors will not work but they can take occupations ...also there's probably a dfhack solution for that labor assignment with a different script.

oh and here's Snatch(this one copies the member of the site to the army) and Recruit (grabs a random nemesis from the world this one works on any mission.) scripts in case anyone want those
 
Code: ('recruit.lua') [Select]
for de,oe in pairs(df.global.world.army_controllers.all) do
if oe.mission_report == nil then else
print ( de,oe.mission_report.title)
for e,o in pairs(df.global.world.armies.all) do
if oe.id == o.controller_id then
print (e)
local forv=df.global.world.armies.all[e].members[0]
df.global.world.armies.all[e].members:insert("#",{new=true,nemesis_id=df.global.world.nemesis.all[dfhack.random.new():random(#df.global.world.nemesis.all)].id,
stored_fat = forv.stored_fat,
unk_2c= forv.unk_2c,
unk_28= forv.unk_28,
unk_1= forv.unk_1,
unk_30= forv.unk_30,
unk_34= forv.unk_34})
end
end
end
end

Code: ('Snatch.lua') [Select]
for de,oe in pairs(df.global.world.army_controllers.all) do
if oe.mission_report == nil then else
print ( de,oe.mission_report.title)
for si,te in pairs(df.global.world.world_data.sites) do
local Sito=te.id
if oe.site_id== Sito then
local SitePool=df.global.world.world_data.sites[si].unk_1.nemesis
for e,o in pairs(df.global.world.armies.all) do
if oe.id == o.controller_id then
print (e)
local forv=df.global.world.armies.all[e].members[0]
df.global.world.armies.all[e].members:insert("#",{new=true,nemesis_id=SitePool[dfhack.random.new():random(#SitePool)],
stored_fat = forv.stored_fat,
unk_2c= forv.unk_2c,
unk_28= forv.unk_28,
unk_1= forv.unk_1,
unk_30= forv.unk_30,
unk_34= forv.unk_34})
end
end
end
end
end
end

so with this you could probably steal back children and babies from goblin snatchers, potentially steal the goblin snatchers, and the known famous members of the dark fortress including the leaders with this script or use recruit to grab a random nemesis having historical figure which might end up getting you an animal.
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on November 25, 2020, 10:55:43 am
Quote
Code: [Select]
unk_2c= forv.unk_2c,
unk_28= forv.unk_28,
unk_1= forv.unk_1,
unk_30= forv.unk_30,
unk_34= forv.unk_34})
Is there a particular reason you're assigning these fields and not the other "unk" fields? Do you know what they are? If you do, we should give them proper names.
Title: Re: DFHack 0.47.04-r3
Post by: Rumrusher on November 26, 2020, 06:24:48 am
Quote
Code: [Select]
unk_2c= forv.unk_2c,
unk_28= forv.unk_28,
unk_1= forv.unk_1,
unk_30= forv.unk_30,
unk_34= forv.unk_34})
Is there a particular reason you're assigning these fields and not the other "unk" fields? Do you know what they are? If you do, we should give them proper names.
uhh I don't really I just notice the numbers were filled in and figured why not match that with the rest of the members in the party so to avoid crashes or any weirdness.
I did had to filter out anon_1 in that set with unk_1 as I didn't know what fit in to anon_1 when it go renamed.

also I think the other unk_ fields are already set to 0 so I didn't really need to change them or apply copying of the first member of the army to the new members.
Title: Re: DFHack 0.47.04-r3
Post by: Iä! RIAKTOR! on November 27, 2020, 06:12:30 pm
I need Catsplosion script analogue that can breed creatures of specie selected by cursor (like for full-heal). For breeding necro's experiments.
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on November 29, 2020, 12:12:04 pm
I need Catsplosion script analogue that can breed creatures of specie selected by cursor (like for full-heal). For breeding necro's experiments.

You could likely adapt catsplosion fairly easily - this section (https://github.com/DFHack/scripts/blob/befaee514d6260797d65dc874c4e2e015d104374/catsplosion.lua#L72-L83) appears to be the code that creates/shortens pregnancies, and creating a script containing just the highlighted code, as well as the following line before it, should work:
Code: [Select]
female = dfhack.gui.getSelectedUnit()
Edit: you'll also need to remove the lines referencing variables with "total_" in their names.

A longer-term solution could be to add support for "catsplosion this", similar to "exterminate this" - it would be more complicated than the process I described above, but if that's something that would be useful, we could add support for it.
Title: Re: DFHack 0.47.04-r3
Post by: Rumrusher on November 30, 2020, 11:28:15 am
I need Catsplosion script analogue that can breed creatures of specie selected by cursor (like for full-heal). For breeding necro's experiments.

You could likely adapt catsplosion fairly easily - this section (https://github.com/DFHack/scripts/blob/befaee514d6260797d65dc874c4e2e015d104374/catsplosion.lua#L72-L83) appears to be the code that creates/shortens pregnancies, and creating a script containing just the highlighted code, as well as the following line before it, should work:
Code: [Select]
female = dfhack.gui.getSelectedUnit()
Edit: you'll also need to remove the lines referencing variables with "total_" in their names.

A longer-term solution could be to add support for "catsplosion this", similar to "exterminate this" - it would be more complicated than the process I described above, but if that's something that would be useful, we could add support for it.
I remember warmist made an impregnate script that was basically this years back when dfusion existed and I think catsplosion was an adaptation of that script.



Code: [Select]
function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end

function getCreatureAtPos(x,y,z) -- gets the creature index @ x,y,z coord
--local x,y,z=getxyz() --get 'X' coords
local vector=df.global.world.units.all -- load all creatures
for i = 0, #vector-1 do -- look into all creatures offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==x and cy==y and cz==z then --compare them
return vector[i] --return index
end
end
--print("Creature not found!")
return nil

end

function empregnate(unit)
    if unit==nil then
        unit=getCreatureAtPos(getxyz())
    end
    if unit==nil then
        error("Failed to empregnate. Unit not selected/valid")
    end
    if unit.curse then
        unit.curse.add_tags2.STERILE=false
    end
    local genes = unit.appearance.genes
    if unit.pregnancy_genes == nil then
        print("creating preg ptr.")
        if false then
            print(string.format("%x %x",df.sizeof(unit:_field("pregnancy_genes"))))
            return
        end
        unit.pregnancy_genes = { new = true, assign = genes }
    end
    local ngenes = unit.pregnancy_genes
    if #ngenes.appearance ~= #genes.appearance or #ngenes.colors ~= #genes.colors then
        print("Array sizes incorrect, fixing.")
        ngenes:assign(genes);
    end
    print("Setting preg timer.")
    unit.pregnancy_timer=10
    unit.pregnancy_caste=1
end
so here's my copy of this old script and the functions that make it work.
Title: Re: DFHack 0.47.04-r3
Post by: CaptainArchmage on December 03, 2020, 09:01:10 am
Is there any kind of DFHack script that allows an artifact to be undestroyed? I've just noted the bug where artifacts are destroyed when migrants bring them in i.e. as family heirlooms and wonder whether this can be fixed.
Title: Re: DFHack 0.47.04-r3
Post by: Roses on December 13, 2020, 01:28:45 am
Couple questions

1. I am looking into adding new features into the eventful plugin, but am wondering how reasonable that is, in particular a call to check for unit actions. Currently I use a script that uses a custom eventful call in my scripts that I got from one of Putnam's scripts but was thinking that it would be more elegant and more useful to other modders if it were to be added into the actual DFHack eventful plugin. I am currently looking at the plugins/lua/eventful.lua, plugins/eventful.cpp, and library/modules/EventManager.cpp for an idea of how I would go about this and I think I understand how the current calls are working, but my question is, before I do too much more work thinking about how to add new calls, is this something that can be done? From what I understand it is, but just wanted to make sure that there wasn't something I was missing that makes it not possible.

2. I want to update my old journal/detailed unit viewer to my new set of scripts. My previous iteration used the "In-game UI library" from the dfhack lua api page extensively. Just wanted to double check that that was still the "correct" way to add custom screens?

3. Is there a list somewhere of what people are working on for DFHack? I know everyone has there own set of scripts and such in lua and various mods, and can submit pull requests about anything they are working on, but I was wondering if there was a central list of things people are looking to add to the core DFHack repository, just in case there is something I think I would like to add, it would be nice to know if anyone else was working on it.
Title: Re: DFHack 0.47.04-r3
Post by: Warmist on December 13, 2020, 07:10:07 am
Couple questions

1. I am looking into adding new features into the eventful plugin, but am wondering how reasonable that is, in particular a call to check for unit actions. Currently I use a script that uses a custom eventful call in my scripts that I got from one of Putnam's scripts but was thinking that it would be more elegant and more useful to other modders if it were to be added into the actual DFHack eventful plugin. I am currently looking at the plugins/lua/eventful.lua, plugins/eventful.cpp, and library/modules/EventManager.cpp for an idea of how I would go about this and I think I understand how the current calls are working, but my question is, before I do too much more work thinking about how to add new calls, is this something that can be done? From what I understand it is, but just wanted to make sure that there wasn't something I was missing that makes it not possible.

2. I want to update my old journal/detailed unit viewer to my new set of scripts. My previous iteration used the "In-game UI library" from the dfhack lua api page extensively. Just wanted to double check that that was still the "correct" way to add custom screens?

3. Is there a list somewhere of what people are working on for DFHack? I know everyone has there own set of scripts and such in lua and various mods, and can submit pull requests about anything they are working on, but I was wondering if there was a central list of things people are looking to add to the core DFHack repository, just in case there is something I think I would like to add, it would be nice to know if anyone else was working on it.

1. IIRC this would be probably added to evenmanager and then to eventful. EventManager has the infrastructure for "every n ticks check this thing" which would be the way to go with this. Eventful itself adds vmethod based callbacks. Though if it's some ease of use script thing it may even live in eventful.lua.

2. Yup. Use as far as possible in inheritance. IIRC usually widgets?

3. I think usual convention is [WIP] marked pull-req in github.
Title: Re: DFHack 0.47.04-r3
Post by: Roses on December 14, 2020, 12:35:37 am
Couple questions

1. I am looking into adding new features into the eventful plugin, but am wondering how reasonable that is, in particular a call to check for unit actions. Currently I use a script that uses a custom eventful call in my scripts that I got from one of Putnam's scripts but was thinking that it would be more elegant and more useful to other modders if it were to be added into the actual DFHack eventful plugin. I am currently looking at the plugins/lua/eventful.lua, plugins/eventful.cpp, and library/modules/EventManager.cpp for an idea of how I would go about this and I think I understand how the current calls are working, but my question is, before I do too much more work thinking about how to add new calls, is this something that can be done? From what I understand it is, but just wanted to make sure that there wasn't something I was missing that makes it not possible.

2. I want to update my old journal/detailed unit viewer to my new set of scripts. My previous iteration used the "In-game UI library" from the dfhack lua api page extensively. Just wanted to double check that that was still the "correct" way to add custom screens?

3. Is there a list somewhere of what people are working on for DFHack? I know everyone has there own set of scripts and such in lua and various mods, and can submit pull requests about anything they are working on, but I was wondering if there was a central list of things people are looking to add to the core DFHack repository, just in case there is something I think I would like to add, it would be nice to know if anyone else was working on it.

1. IIRC this would be probably added to evenmanager and then to eventful. EventManager has the infrastructure for "every n ticks check this thing" which would be the way to go with this. Eventful itself adds vmethod based callbacks. Though if it's some ease of use script thing it may even live in eventful.lua.

2. Yup. Use as far as possible in inheritance. IIRC usually widgets?

3. I think usual convention is [WIP] marked pull-req in github.

1. Hmm, the more I think about it, the more I'm not sure if it is something that should go in the C++ or in the lua side of things. It would be nice to put it in the C++ so that it works like all the other eventful things, but I suppose if it gets put into the lua eventful side of things it would work for other users just the same. I'm not sure, I guess I will need to think about it some more.

2. Yep, lots of widgets. It does what I want it to do, so I'm glad it's still that way. Don't have to change much then.

3. That works great. I got a little confused because I was looking under the df-structures git repo and only saw like two pull requests. But now I realize that each repo under the DFHack account has it's own list of pull requests. On a side note, has it always been that way? I thought I remembered them being in a single repo.
Title: Re: DFHack 0.47.04-r3
Post by: Warmist on December 14, 2020, 06:26:02 am
Ah another thought i had relation to 1st question: it might be useful to implement the core in c++ just because of performance as it would be probably walking over many units and checking their actions each tick as action are shortlived and need to be as up-to-date as possible.
Title: Re: DFHack 0.47.04-r3
Post by: Putnam on December 14, 2020, 10:31:02 am
Check the modtools folder in sparking. I already got an on-action event in Lua which is "fast enough", though I have been thinking avout moving it to C++.
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on December 14, 2020, 11:44:49 am
3. That works great. I got a little confused because I was looking under the df-structures git repo and only saw like two pull requests. But now I realize that each repo under the DFHack account has it's own list of pull requests. On a side note, has it always been that way? I thought I remembered them being in a single repo.

"df-structures" has been its own repo since structure definitions were implemented in XML (around 2011). "scripts" was split out in 2016, and has issues disabled, since it usually makes more sense to report them in the "dfhack" repo anyway. PRs always need to be made in the repo containing the code being modified, though.

I loosely keep track of issues/PRs with projects, to make it a bit easier to see what issues/PRs were addressed in a release, but they need to be manually added currently: https://github.com/orgs/DFHack/projects/
Title: Re: DFHack 0.47.04-r3
Post by: Roses on December 14, 2020, 04:21:55 pm
Check the modtools folder in sparking. I already got an on-action event in Lua which is "fast enough", though I have been thinking avout moving it to C++.

Yes, that is what I am using now. Was also just pondering about moving it to C++, but since you are the author of what I am using right now, and you are also thinking about it, I'll let you decide how best to handle that. I think you are right that it is fast enough, at least in my limited testing.

"df-structures" has been its own repo since structure definitions were implemented in XML (around 2011). "scripts" was split out in 2016, and has issues disabled, since it usually makes more sense to report them in the "dfhack" repo anyway. PRs always need to be made in the repo containing the code being modified, though.

I loosely keep track of issues/PRs with projects, to make it a bit easier to see what issues/PRs were addressed in a release, but they need to be manually added currently: https://github.com/orgs/DFHack/projects/

Wow, 4 years ago already. Crazy how time flies, feels like just a couple years ago that I started using DFHack. Thanks for the projects link.
Title: Re: DFHack 0.47.04-r3
Post by: Atkana on December 18, 2020, 04:48:45 am
Fair warning, this post is basically an incoherent mess of topics that I've been building up to posting. If you're just looking for one post to answer, skip to the last one, since that's really what I came for :b

Eventful's interaction event still seems to be broken (though I think it has been for some time)
The following doesn't seem to trigger in any mode (I'd done the testing in r2, but didn't notice anything in the changelogs about fixes to it, so I assume the same still applies to the current version):
Code: [Select]
eventful = require "plugins.eventful"

eventful.enableEvent(eventful.eventType.INTERACTION,1)
eventful.onInteraction.test = function()
print("An interaction happened!")
end

Just thought I'd bring it up in case for some reason it hasn't been already :P

While messing around with the action menu (viewscreen_layer_unit_actionst) for a script, I noted down a few possibilities for currently unmapped values:

On the topic of finding out what everyone's working on: in addition to checking github, we could also encourage scripters to make more use of the What's going on in your modding? thread (http://www.bay12forums.com/smf/index.php?topic=165213.0) as a way of keeping people up to date. I for one will at least try to post more there when working on my own stuff.

I've been going crazy trying to figure out how, as a lua scripter, I'm supposed to make data persistent.
Title: Re: DFHack 0.47.04-r3
Post by: PatrikLundell on December 18, 2020, 07:36:31 am
@Atkana:
While the suspicions regarding mapping of DF elements aren't exactly out of place in this thread, it's probably better to note it in an issue on github (or do that as well: things in this thread tend to get forgotten if not acted upon fairly quickly, while issues have a longer shelf life), or, even better, continue the investigation to the level of fairly certain and produce a Pull Request to update the fields on github.
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on December 19, 2020, 12:03:00 am
The first one would also warrant a bug report.

As for persistent data: the limitations of the "old" system were due to it saving data in histfigs - specifically, creating histfigs with negative IDs and using fields of their language_name allowed for storing a string name, a string value (both of these limited to around 32k characters), and 7 integers. The underlying storage backend uses JSON now and no longer has these limitations, but the APIs on top of it (including dfhack.persistent and persist-table) haven't changed much yet (the main difference is that the string limitation no longer applies; we could also bump up the number of integers allowed as an intermediate improvement).

You are correct that there is a "pre-save" sort of hook that allows plugins to make any last-minute changes before data is saved (although it could also be used for any custom data-saving logic). The exact logic that triggers it is here: https://github.com/DFHack/dfhack/blob/de21e0cdb86b9002cdcadabd5e8f1dbb68270467/library/Core.cpp#L2008-L2013
Unfortunately, this doesn't appear to be exposed to Lua yet. You could likely catch regular saves with an onStateChange handler, but not autosaves/"quicksave"s. Assuming this would be useful to have in Lua, a GitHub issue would help keep track of this as well.
Title: Re: DFHack 0.47.04-r3
Post by: Atkana on December 19, 2020, 03:27:18 am
Alright, I've dropped issues for each of them. I should really get in the habit of doing them more often in the future :P
Title: Re: DFHack 0.47.04-r3
Post by: Fleeting Frames on December 23, 2020, 06:06:51 am
Lua-wise, I've had some success checking df.global.ui.main.autosave_request every tick in earlier versions, though haven't extensively tested:

Code: [Select]
local function repeatfunction(rfunc, N)
--repeats a function every N frames, until the function returns false or nil
local myrfunc

myrfunc = function ()
  local timeoutid = dfhack.timeout(N, "frames", function(options)
if rfunc(timeoutid) then myrfunc() end
   end)
end

myrfunc()
end

function detectSave(func)
if not func then return false end
--detect quicksaves
repeatfunction(
function()
if not already_saved and (
df.global.ui.main.autosave_request --quicksaves
or dfhack.gui.getCurFocus()=="options" --normal saves, maybe??
) then
already_saved=true
func()
end
return true
end
,1)
--set already_saved to false every six seconds
--(assumes the player doesn't do anything that changes persistent values in less than that)
repeatfunction(
function()
already_saved=false
return true
end
,600)
end

(With the func being saving persistent data entry.)

Didn't know about the 32k characters being the limitation and also the limitation on keys. I've tried tossing internal JSON encodings into value field, but with that length could do sparse single tile-based tables.
Title: Re: DFHack 0.47.04-r3
Post by: lethosor on December 23, 2020, 11:33:40 am
In case it wasn't clear: the 32k limit only applied to the old backend that stored data in histfigs. Since 0.44.12-r3, that isn't an issue, so you can make keys and values as long as you want (within reason, of course).
Title: Re: DFHack 0.47.04-r4
Post by: lethosor on December 24, 2020, 02:41:31 pm
0.47.04-r4 is up! https://github.com/DFHack/dfhack/releases/tag/0.47.04-r4

Lots of buildingplan and quickfort improvements here, as well as several fixes.
Title: Re: DFHack 0.47.04-r4
Post by: A_Curious_Cat on December 24, 2020, 06:47:31 pm
0.47.04-r4 is up! https://github.com/DFHack/dfhack/releases/tag/0.47.04-r4

Lots of buildingplan and quickfort improvements here, as well as several fixes.

Merry Christmas to you, too!
Title: Re: DFHack 0.47.04-r4
Post by: myk on December 24, 2020, 11:18:59 pm
Woohoo! Thank you, Lethosor!
Title: Re: DFHack 0.47.04-r4
Post by: Iä! RIAKTOR! on December 25, 2020, 05:00:37 pm
Could someone help me with vampire race? I just need one script.

They has blood in raws. But when they are part of fort (like citizen or, if mute caste, as livestock), they get removing of HAS_BLOOD (like generated undead syndromes). But they get HAS_BLOOD back when counter trigger DRINKING_BLOOD has value from 1 to 20. And HAS_BLOOD will be removed when vampire lost DRINKING_BLOOD counter.
Title: Re: DFHack 0.47.04-r4
Post by: Pyrite on December 26, 2020, 03:13:15 am
Is there a script for removing or fulfilling the need for decent meals? I find this need so frustrating and difficult to fulfill on many dwarves that I basically consider it a bug. Having a dwarf constantly get bad thoughts because I can't provide a source of magpie meat or millet beer gets old fast.

I can deal with all the other needs, as finicky as they are, but I'd really just like to kick this one to the curb.
Title: Re: DFHack 0.47.04-r4
Post by: Atkana on December 26, 2020, 04:27:10 am
Is there a script for removing or fulfilling the need for decent meals? I find this need so frustrating and difficult to fulfill on many dwarves that I basically consider it a bug. Having a dwarf constantly get bad thoughts because I can't provide a source of magpie meat or millet beer gets old fast.

I can deal with all the other needs, as finicky as they are, but I'd really just like to kick this one to the curb.
You should be able to satisfy all of your citizen's need for decent meals with:
Code: [Select]
modtools/set-need -edit -need EatGoodMeal -focus 400 -citizens
Or alternatively, you could get rid of their needs to eat a good meal with
Code: [Select]
modtools/set-need -remove -need EatGoodMeal -citizens

Execute one of those periodically (or set up something using repeat (https://github.com/DFHack/scripts/blob/master/repeat.lua) to repeat it automatically), and you won't have to worry about that annoying as heck need again :P
Title: Re: DFHack 0.47.04-r4
Post by: Pyrite on December 26, 2020, 02:07:44 pm
Thank you so much! That seems to have worked, and I chose to just remove the need entirely as that seems like the most balanced option. I really wish I could actually modify it to be satisfied with meals of a certain value, with favorite ingredients being present like doubling that value for the dwarf, and maybe having the value set by some personality trait. But having every single ingredient conceivable is just not a reasonable requirement for running a low-stress fortress.

That leaves the needs for friendship and family as the most difficult ones to satisfy, but at least I can consistently solve those by shoving dwarves together into a tiny locked room for a couple of seasons.
Title: Re: DFHack 0.47.04-r4
Post by: Rumrusher on December 29, 2020, 04:24:04 am
hmm looks like ui_advmode.unk_v42_1 is tied to adventurer performances ala the sermons.
though since most of the content there is userdata I don't think it's possible to modify any of it.
though I don't know if this is true in the new version of DFhack.
Title: Re: DFHack 0.47.04-r4
Post by: Erendir on December 29, 2020, 07:51:05 am
Please help: can't remember what was that script allowing visually inspecting Lua game state (or am I totally confused?).
Title: Re: DFHack 0.47.04-r4
Post by: lethosor on December 29, 2020, 10:07:20 am
gui/gm-editor?
Title: Re: DFHack 0.47.04-r4
Post by: Erendir on December 29, 2020, 11:04:46 am
gui/gm-editor?

That's the one! Thanks!

Another question: does anybody know what kind of work order (as in an entry in `df.global.world.manager_orders`) does NOT have item_type = -1 (NONE)? I can't find any.
Title: Re: DFHack 0.47.04-r4
Post by: PatrikLundell on December 29, 2020, 02:06:53 pm
I don't know (and don't use the manager), but I'd expect specific orders to get specific parameters. If you look at the kitchen, orders in it don't fill out the parameters, letting the games decides what to make, but using DFHack or a script it's possible to specify exactly what to use, so it's really a matter of the UI not supporting all of the underlying functionality.
Thus, if you want to examine it you should try to make as specific orders as you can (and "NONE" frequently means "ANY").
Title: Re: DFHack 0.47.04-r4
Post by: Erendir on December 29, 2020, 04:57:13 pm
I don't know (and don't use the manager), but I'd expect specific orders to get specific parameters.
[...]
Thus, if you want to examine it you should try to make as specific orders as you can (and "NONE" frequently means "ANY").

I've tried but gave up :) It's just the orders plugin (and the part of it I converted to Lua in workorder) has some special handling for export/import of item_type and item_subtype, but I'm not sure anymore the game actually uses them -- this is why I'm looking for an example to prove my suspicion wrong.
Title: Re: DFHack 0.47.04-r4
Post by: Libash_Thunderhead on December 29, 2020, 09:46:49 pm
Hello, I'm trying to read the source code, however, I can't figure out how to locate some header files.
For example: "df/viewscreen_dungeon_monsterstatusst.h"

Can anybody help me with this?
Title: Re: DFHack 0.47.04-r4
Post by: Jack_Caboose on December 29, 2020, 11:12:43 pm
Is there a command/plugin to make two units fight? I built an arena but all the creatures refuse to fight eachother (damn bastards are working together just to spite me)
Title: Re: DFHack 0.47.04-r4
Post by: Rose on December 30, 2020, 12:39:37 am
You can put them on opposing factions, maybe?
Title: Re: DFHack 0.47.04-r4
Post by: PatrikLundell on December 30, 2020, 05:01:55 am
Hello, I'm trying to read the source code, however, I can't figure out how to locate some header files.
For example: "df/viewscreen_dungeon_monsterstatusst.h"

Can anybody help me with this?
<DFHack>\library\include\df\viewscreen_dungeon_monsterstatusst.h
Title: Re: DFHack 0.47.04-r4
Post by: Libash_Thunderhead on December 30, 2020, 05:23:31 am
Quote
<DFHack>\library\include\df\viewscreen_dungeon_monsterstatusst.h
But I didn't find the files in that folder.
https://github.com/DFHack/dfhack/tree/develop/library/include/df
Title: Re: DFHack 0.47.04-r4
Post by: PatrikLundell on December 30, 2020, 08:21:23 am
Quote
<DFHack>\library\include\df\viewscreen_dungeon_monsterstatusst.h
But I didn't find the files in that folder.
https://github.com/DFHack/dfhack/tree/develop/library/include/df
You didn't specify that you were looking at github rather than a local repository. I gave the location of the file in the local repository. If you look at github it may not be present at all, as these files are generated from the XML by the code generation process, so to get at their info you'd have to locate the XML file that defines what is then generated into that .h file (without checking, I'd guess df.viewscreen.xml, although the XML file may not be intuitive). The alternative would be to install the source code locally and generate the .h files, which would give you the C header format.

Having the generated .h files float around on github would result in issues when you generate them locally (e.g. after updating the XML locally), unless there's a way get them to be visible on github but be exempt from source control so they are readily replaced by local generation after being downloaded (but how would that logic know when to download and when not to?).
Title: Re: DFHack 0.47.04-r4
Post by: lethosor on December 30, 2020, 12:07:21 pm
Right - the way to generate them is to set up a build environment and build DFHack (specifically, at least the "generate_headers" target). If you're only interested in the type definitions and don't need the exact headers, they are generated from df.*.xml files in https://github.com/dfhack/df-structures/ (loosely organized into separate files, as PatrikLundell mentioned). The specific class you asked about is defined here (https://github.com/DFHack/df-structures/blob/0.47.04-r4/df.viewscreen.xml#L846-L865).

https://docs.dfhack.org/en/stable/docs/Structures-intro.html goes into a bit of detail about how DF-structures works, and links to some other pages.

Having the generated .h files float around on github would result in issues when you generate them locally (e.g. after updating the XML locally), unless there's a way get them to be visible on github but be exempt from source control so they are readily replaced by local generation after being downloaded (but how would that logic know when to download and when not to?).
codegen.pl will always generate new headers and replace the existing ones if necessary, although it's only run by CMake if codegen.out.xml is "out-of-date", i.e. older than the df.*.xml files. There are a couple reasons we don't include the headers in the DFHack repo:
- They're generated, and including generated files in source control usually isn't a good idea (among other reasons, it isn't necessary since the files can be generated, and it leads to larger diffs)
- They're generated from source files in another repo (from df-structures, and stored in library/include/df of the main DFHack repo), so keeping them in sync with the source files would be an additional challenge
- There are a lot of them (around 1750 as of 0.47.04-r4), so keeping them in source control would lead to rather large diffs

There is actually a CMake option that installs the generated headers (and as a result, includes them in release packages), but we haven't enabled it in a while because it leads to larger archives that take a long time for some unzipping tools to extract, and there isn't a very well-defined process for using the headers outside of DFHack currently.
Title: Re: DFHack 0.47.04-r4
Post by: Libash_Thunderhead on December 31, 2020, 01:38:24 am
Thank you! I think I understand now. :)
Title: Re: DFHack 0.47.04-r4
Post by: Libash_Thunderhead on January 04, 2021, 03:48:56 am
I'm trying to build dfhack on windows, but win32\generate-MSVC-release.bat says there are errors. I checked CMakeError.txt, and there are something like missing header files, such as:

fatal error C1083: Cannot open include file: 'dlfcn.h'
fatal error C1083: Cannot open include file: 'strings.h'
fatal error C1083: Cannot open include file: 'sys/mman.h'
...

I'm using visual studio 2015 build tools, installed with default settings. Did I miss something?
Title: Re: DFHack 0.47.04-r4
Post by: lethosor on January 04, 2021, 08:56:08 am
Can you post the full error log somewhere? It looks like it's trying to include Linux headers, and I'm not sure why that would be happening if you're using MSVC. Another possibility is that these errors were produced by test programs checking whether those headers exist, in which case they would be harmless, but I would need more context to determine that.
Title: Re: DFHack 0.47.04-r4
Post by: Libash_Thunderhead on January 04, 2021, 07:08:01 pm
Here it is:

CMakeError.txt
Spoiler (click to show/hide)

By the way I'm using a VirtualBox machine, everything is freshly installed.
Title: Re: DFHack 0.47.04-r4
Post by: lethosor on January 04, 2021, 07:58:47 pm
Those actually all look harmless to me - CMake (maybe due to some of our dependencies) checks for a lot of files/functions, but is able to handle cases where they don't exist, and this all looks like output just from those checks to me.

I guess I'm more interested in output from the batch script itself:
I'm trying to build dfhack on windows, but win32\generate-MSVC-release.bat says there are errors.

Can you post the full console output from running the batch script? I realize it's tricky to copy text from cmd.exe sometimes - I think you can usually do it by right-clicking in the title bar (or by using a different command prompt, possibly).
Title: Re: DFHack 0.47.04-r4
Post by: Libash_Thunderhead on January 04, 2021, 09:42:50 pm
Code: [Select]
C:\dfhack\dfhack\build\win32>call "C:\Program Files\Microsoft Visual Studio 14.0\Common7\Tools\vsvars32.bat"
ERROR: Cannot determine the location of the VS Common Tools folder.

C:\dfhack\dfhack\build\win32>cd VC2015_32

C:\dfhack\dfhack\build\win32\VC2015_32>msbuild /m /p:Platform=Win32 /p:Configuration=Release ALL_BUILD.vcxproj
'msbuild' is not recognized as an internal or external command,
operable program or batch file.

C:\dfhack\dfhack\build\win32\VC2015_32>cd ..

C:\dfhack\dfhack\build\win32>pause
Press any key to continue . . .

This is what happens if I run build-release.bat.
It appears msbuild can't be found. Maybe I should reinstall the tools.
Title: Re: DFHack 0.47.04-r4
Post by: lethosor on January 04, 2021, 10:10:31 pm
Oh, well, the issue is that "C:\Program Files\Microsoft Visual Studio 14.0\Common7\Tools\vsvars32.bat" doesn't exist. If it did exist, it would have set up the correct paths/environment variables so that msbuild could be located.


Update: I misread. Could you check whether "C:\Program Files\Microsoft Visual Studio 14.0\Common7\Tools\vsvars32.bat" exists? If it does, I suspect you have issues with your 2015 build tools installation, and might need to reinstall that component. If it doesn't exist, see below:

You might need to install the Visual Studio 2015 build tools (sometimes listed as "14.0"). You can typically do this even from VS2017/2019. The link from our build docs (https://docs.dfhack.org/en/stable/docs/Compile.html#microsoft-visual-studio-2015) appears to still work as well (you would want "Microsoft Build Tools 2015 Update 3" as of today). If this doesn't help, let us know so we can fix the docs!
Title: Re: DFHack 0.47.04-r4
Post by: Libash_Thunderhead on January 04, 2021, 11:00:01 pm
Yeah, vsvars32.bat exists. Otherwise it won't display that message.
And yes I downloaded "Microsoft Build Tools 2015 Update 3", I will try to uninstall it to see what options I missed.
Title: Re: DFHack 0.47.04-r4
Post by: Libash_Thunderhead on January 05, 2021, 12:12:37 am
Here's the cmd output:
Spoiler (click to show/hide)

PS, Still, msbuild can't be found in a normal cmd box, but I can use one of the build tools command prompts so it is not a big problem.
Title: Re: DFHack 0.47.04-r4
Post by: Clément on January 05, 2021, 09:43:02 am
There used to be a VS140COMNTOOLS envvar that would help with finding these tools. But it is no longer set by VS2017/2019. I always use the "Developer Command Prompt" now.

It seems that Microsoft has a vswhere tool now that could help (https://github.com/microsoft/vswhere/wiki/Start-Developer-Command-Prompt). The doc says it can be found in "%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" if Visual Studio 15.2 or later is installed (https://github.com/microsoft/vswhere/wiki/Installing), but I don't know if that is reliable. Someone with Visual Studio installed outside of Program Files should check, mine is the default path.

Code: [Select]
>"%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" -property installationPath
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
Title: Re: DFHack 0.47.04-r4
Post by: Libash_Thunderhead on January 05, 2021, 07:48:13 pm
@lethosor
Thank you for the help.
You are right those missing header files are harmless, because the generate-minimal script works. The generate-release script fails because of Sphinx (or lack of it).

Code: [Select]
CMake Error at CMakeLists.txt:440 (message):
  Sphinx not found but BUILD_DOCS enabled
Title: Re: DFHack 0.47.04-r4
Post by: lethosor on January 05, 2021, 08:01:40 pm
Yes, the only issue I'm seeing is that you don't have Sphinx installed, but you (or the script, rather) are enabling the BUILD_DOCS setting. Disabling this setting (with -DBUILD_DOCS=0 or just by removing it from the script) would address this, and so would installing Sphinx (docs here (https://docs.dfhack.org/en/latest/docs/Documentation.html)). As you found, there are other batch scripts that leave out BUILD_DOCS as well. The "release" script is likely intended to match the configuration we use to build release packages, and we do include user-facing HTML documentation in those, which requires Sphinx.
Title: Re: DFHack 0.47.04-r4
Post by: saintclair on January 06, 2021, 12:11:57 pm
I recently backported the fix/corrupt-equipment script to the 44.12 version of DFHack, and I'll share what I had to do here to make it work. DFHack did not change substantially between the 44.12 version and the first inclusion of this script, but some functionality changed and some data structures changed, which need to be noted:

We need to backport the addressof function from https://github.com/DFHack/dfhack/commit/fb44b26b47eca729646e316efc22cfe2a138691e (https://github.com/DFHack/dfhack/commit/fb44b26b47eca729646e316efc22cfe2a138691e)

Then, we need to revert these changes https://github.com/DFHack/df-structures/commit/063b3cadceb32c4e7515b7096cee0d821d428ba3 (https://github.com/DFHack/df-structures/commit/063b3cadceb32c4e7515b7096cee0d821d428ba3)

Specifically, these data structures changed, so a find-and-replace of "items_unmanifested" to "items_by_type1" reverts the change in this (and any other script you backport) to make it work. These two changes are, as far as I can tell, the only ones needed to make the script work. Once you've changed the script, place it in the hack/scripts/fix folder and you can run it as the comments in the file suggest. For convenience I added a line to print when it was running so I wouldn't forget that I had it on repeat while waiting for those dwarves to return from raids with their broken equipment, but you don't need to do that.

Hope this helps someone!
Title: Re: DFHack 0.47.04-r4
Post by: Libash_Thunderhead on January 07, 2021, 04:12:20 am
Code: [Select]
Link:
  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\link.exe /ERRORREPORT:QUEUE /OUT:".\CompilerIdC.exe" /INCREMENTAL:NO /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:".\CompilerIdC.pdb" /SUBSYSTEM:CONSOLE,"5.02" /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:".\CompilerIdC.lib" /MACHINE:X64 Debug\CMakeCCompilerId.obj
LINK : fatal error LNK1181: cannot open input file 'kernel32.lib' [C:\dfhack\dfhack\build\win64\VC2015\CMakeFiles\3.19.2\CompilerIdC\CompilerIdC.vcxproj]

Strange, I saw this error after I swtiched to 64 bit version. It seem Any idea?
Title: Re: DFHack 0.47.04-r4
Post by: lethosor on January 08, 2021, 07:40:09 pm
Code: [Select]
Link:
  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\link.exe /ERRORREPORT:QUEUE /OUT:".\CompilerIdC.exe" /INCREMENTAL:NO /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:".\CompilerIdC.pdb" /SUBSYSTEM:CONSOLE,"5.02" /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:".\CompilerIdC.lib" /MACHINE:X64 Debug\CMakeCCompilerId.obj
LINK : fatal error LNK1181: cannot open input file 'kernel32.lib' [C:\dfhack\dfhack\build\win64\VC2015\CMakeFiles\3.19.2\CompilerIdC\CompilerIdC.vcxproj]

Strange, I saw this error after I swtiched to 64 bit version. It seem Any idea?
When/where does this show up? It doesn't look DFHack-related to me - is this in CMakeError.log? Are there any console errors from running whatever build command you're running?

The batch scripts we provide under "build/win32" and "build/win64" should make separate subdirectories; if you're building on your own, I suppose you could change the build architecture in an existing build directory, but this has occasional issues on Linux and I have no idea if it works on Windows at all.
Title: Re: DFHack 0.47.04-r4
Post by: Uthimienure on January 09, 2021, 11:58:42 am
I've been wondering (and can't find it with searches) if anyone knows of a way to measure the pathing distance between two cursor locations in fort mode.
Title: Re: DFHack 0.47.04-r4
Post by: Warmist on January 09, 2021, 02:53:28 pm
I've been wondering (and can't find it with searches) if anyone knows of a way to measure the pathing distance between two cursor locations in fort mode.

I don't think that there is one. However there is a quick way to do "Is this reachable" check.
Title: Re: DFHack 0.47.04-r4
Post by: Uthimienure on January 09, 2021, 06:28:26 pm
I've been wondering (and can't find it with searches) if anyone knows of a way to measure the pathing distance between two cursor locations in fort mode.

I don't think that there is one. However there is a quick way to do "Is this reachable" check.

I've used trying to build furniture in a location to do that, but if you mean another way please share.

I should have given more info in my original musing... I was checking some places aboveground in a 4x4 mountain embark where I've got constructions spread over 50+ z-levels on the surface. As I was trying to figure out which way dwarfs would be traveling to get to certain constructions (through tunnels or overland), I thought a path measuring tool would be neat because I wanted them to use tunnels to avoid a bunch of dead goblins on the surface.

I already have designated traffic areas for high, low, restricted travel... I was just musing that it would be quick & easy to estimate things with a path measuring tool  :)
Title: Re: DFHack 0.47.04-r4
Post by: Libash_Thunderhead on January 10, 2021, 10:54:58 pm
When/where does this show up?
It seems to be the script that determines c++ compiler.
Code: [Select]
C:\dfhack\dfhack\build\win64\VC2015>cmake ..\..\.. -G"Visual Studio 14 Win64" -T v140_xp -DCMAKE_INSTALL_PREFIX="C:\dfhack\dfhack\build\win64\DF" -DBUILD_DEVEL=0 -DBUILD_DEV_PLUGINS=0 -DBUILD_DOCS=1 -DBUILD_STONESENSE=1
-- Selecting Windows SDK version  to target Windows 10.0.19041.
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:6 (project):
  No CMAKE_C_COMPILER could be found.



CMake Error at CMakeLists.txt:6 (project):
  No CMAKE_CXX_COMPILER could be found.



-- Configuring incomplete, errors occurred!
See also "C:/dfhack/dfhack/build/win64/VC2015/CMakeFiles/CMakeOutput.log".
See also "C:/dfhack/dfhack/build/win64/VC2015/CMakeFiles/CMakeError.log".
Title: Re: DFHack 0.47.04-r4
Post by: lethosor on January 11, 2021, 12:14:28 am
Is it possible that you only have 32-bit build tools installed? I'm not sure what options you have available when installing those. You are on a 64-bit system, right?

And just to double-check, what are you aiming to do by building DFHack - plugin development, for instance?
Title: Re: DFHack 0.47.04-r4
Post by: Libash_Thunderhead on January 11, 2021, 12:54:18 am
Is it possible that you only have 32-bit build tools installed? I'm not sure what options you have available when installing those. You are on a 64-bit system, right?

And just to double-check, what are you aiming to do by building DFHack - plugin development, for instance?
CMakeOutput.txt
Code: [Select]
The system is: Windows - 10.0.19041 - AMD64
It is 64 bit os. I installed Microsoft Build Tools 2015 Update 3, using default settings. There is also this "Visual C++ 2015 x64 Native Build Tools Command Prompt", so I guess everything is set.
 :P I wanted to learn how twbt works at first and do some experiment(curious), didn't expect this kind of trouble.

By the way, 32 bit works just fine. I sucessfully built dfhack several days ago.

Title: Re: DFHack 0.47.04-r4
Post by: Rose on January 11, 2021, 01:27:26 am
So, I've only ever gotten luck with the full Visual Studio 2015 installed, personally.

Just having the build tools has been very hard to get to work.
Title: Re: DFHack 0.47.04-r4
Post by: Libash_Thunderhead on January 11, 2021, 02:59:57 am
So, I've only ever gotten luck with the full Visual Studio 2015 installed, personally.

Just having the build tools has been very hard to get to work.
Thanks. Maybe I should do a full installation to see if it works.

----
Edit*
Yeah, installing vs 2015 fixed the problem.  :)
Title: Re: DFHack 0.47.04-r4
Post by: iii22 on January 11, 2021, 08:50:23 am
Has anyone figured out how to use the gm-editor to force a site to send a siege?
Title: Re: DFHack 0.47.04-r4
Post by: Libash_Thunderhead on January 14, 2021, 04:06:30 am
This time, vs studio (or msbuild) shows errors in post-build event part. It says cmd.exe could not be run because "function incorrect". 

This is the post-build script in INSTALL.vcxproj
Code: [Select]
setlocal
"C:\Program Files\CMake\bin\cmake.exe" -DBUILD_TYPE=$(Configuration) -P cmake_install.cmake
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd

Edit*

Strange, if I run the script manually in cmd box and it works just fine.

Edit* 2

Nevermind, it is fixed if I remove /m option from msbuild.
Title: Re: DFHack 0.47.04-r4
Post by: Rumrusher on January 14, 2021, 10:02:44 am
(http://www.truimagz.com/host/rumrusher/folder9/lasi-batters.gif)
well working on a script that commands ghosts.
Code: (ghostbook.lua) [Select]
--this script uses warmist dialog layout as a base, and some overviews from Max and Rose and Putnam scripts, series of ghost script commands
local dlg=require("gui.dialogs")
function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end
function getItemAtKPos(x,y,z) -- gets the item index @ x,y,z coord
--local x,y,z=getxyz() --get 'X' coords
local vector=df.global.world.item.all -- load all items
local kickpos=df.global.world.units.active[0].pos
for i = 0, #vector-1 do -- look into all items offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==kickpos.x and cy==kickpos.y and cz==kickpos.z then --compare them
return vector[i] --return index
end
end
--print("item not found!")
return nil

end
function getCreatureAtPos(x,y,z) -- gets the creature index @ x,y,z coord
--local x,y,z=getxyz() --get 'X' coords
local vector=df.global.world.units.all -- load all creatures
for i = 0, #vector-1 do -- look into all creatures offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==x and cy==y and cz==z then --compare them
return vector[i] --return index
end
end
--print("Creature not found!")
return nil

end
function Ghosto(Gho)
local Gho= getCreatureAtPos(getxyz())
Gho.flags3.ghostly=true
Gho.ghost_info=df.unit_ghost_info:new()
end
function Cleanse(Gho)
local Gho= getCreatureAtPos(getxyz())
Gho.flags3.ghostly=false
end

function Ghosta()
local Targ= getCreatureAtPos(getxyz())
--if Gho.Ghost_info= nil then
--Ghosto()end
for k,v in pairs (df.global.world.units.active) do
if v.flags3.ghostly==true then
local Gho=v
Gho.ghost_info.goal=0
Gho.ghost_info.target.unit=Targ.id
end
end
end
function Ghostb()
local Targ= getCreatureAtPos(getxyz())
--if Gho.Ghost_info= nil then
--Ghosto()end
for k,v in pairs (df.global.world.units.active) do
if v.flags3.ghostly==true then
local Gho=v
Gho.ghost_info.goal=1
Gho.ghost_info.target.unit=Targ.id
end
end
end

function Ghostc()
local Targ= getCreatureAtPos(getxyz())
--if Gho.Ghost_info= nil then
--Ghosto()end
for k,v in pairs (df.global.world.units.active) do
if v.flags3.ghostly==true then
local Gho=v
Gho.ghost_info.goal=2
Gho.ghost_info.target.unit=Targ.id
end
end
end

function Ghostd()
local Targ= getCreatureAtPos(getxyz())
--if Gho.Ghost_info= nil then
--Ghosto()end
for k,v in pairs (df.global.world.units.active) do
if v.flags3.ghostly==true then
Gho=v
Gho.ghost_info.goal=3
Gho.ghost_info.target.unit=Targ.id
end
end
end

function Ghoste()
local Targ= getCreatureAtPos(getxyz())
--if Gho.Ghost_info= nil then
--Ghosto()end
for k,v in pairs (df.global.world.units.active) do
if v.flags3.ghostly==true then
local Gho=v
Gho.ghost_info.goal=5
Gho.ghost_info.target.unit=Targ.id
end
end
end
function Gigapurge()
local adv=df.global.world.units.active[0]
for k,v in pairs(df.global.world.units.active) do
if v.civ_id ~= adv.civ_id then
df.global.world.units.active:erase(k)
end
end
end

MOVEMENT_KEYS = {
    A_CARE_MOVE_N = { 0, -1, 0 }, A_CARE_MOVE_S = { 0, 1, 0 },
    A_CARE_MOVE_W = { -1, 0, 0 }, A_CARE_MOVE_E = { 1, 0, 0 },
    A_CARE_MOVE_NW = { -1, -1, 0 }, A_CARE_MOVE_NE = { 1, -1, 0 },
    A_CARE_MOVE_SW = { -1, 1, 0 }, A_CARE_MOVE_SE = { 1, 1, 0 },
    --[[A_MOVE_N = { 0, -1, 0 }, A_MOVE_S = { 0, 1, 0 },
    A_MOVE_W = { -1, 0, 0 }, A_MOVE_E = { 1, 0, 0 },
    A_MOVE_NW = { -1, -1, 0 }, A_MOVE_NE = { 1, -1, 0 },
    A_MOVE_SW = { -1, 1, 0 }, A_MOVE_SE = { 1, 1, 0 },--]]
    A_CUSTOM_CTRL_D = { 0, 0, -1 },
    A_CUSTOM_CTRL_E = { 0, 0, 1 },
    CURSOR_UP_Z_AUX = { 0, 0, 1 }, CURSOR_DOWN_Z_AUX = { 0, 0, -1 },
    A_MOVE_SAME_SQUARE={0,0,0},
    SELECT={0,0,0},
}
ALLOWED_KEYS={
    A_MOVE_N=true,A_MOVE_S=true,A_MOVE_W=true,A_MOVE_E=true,A_MOVE_NW=true,
    A_MOVE_NE=true,A_MOVE_SW=true,A_MOVE_SE=true,A_STANCE=true,SELECT=true,A_MOVE_DOWN_AUX=true,
    A_MOVE_UP_AUX=true,A_LOOK=true,CURSOR_DOWN=true,CURSOR_UP=true,CURSOR_LEFT=true,CURSOR_RIGHT=true,
    CURSOR_UPLEFT=true,CURSOR_UPRIGHT=true,CURSOR_DOWNLEFT=true,CURSOR_DOWNRIGHT=true,A_CLEAR_ANNOUNCEMENTS=true,
    CURSOR_UP_Z=true,CURSOR_DOWN_Z=true,
}

listofspells={
{text="nothing", spell=doNothing,icon='*'},
{text="Convert-to-Ghost", spell=Ghosto,icon='*'},
{text="Ghost: Scare to death", spell=Ghosta,icon='*'},
{text="Ghost:Stun", spell=Ghostb,icon='*'},
{text="Ghost:Batter", spell=Ghostc,icon='*'},
{text="Ghost:Possess", spell=Ghostd,icon='*'},
{text="Revert-from-ghost", spell=Cleanse,icon='*'},
{text="Ghost:Haunt", spell=Ghoste,key="CUSTOM_X"},
}
 
dlg.showListPrompt("Directions","Choze Direct",nil, listofspells,function(index,choice) choice.spell() end)

so far this script can be used universally in fort mode and adventure mode though in the current update might make getting a fort mode ghost to show up in adventure mode a bit tricky... so this script also has means of converting folks into ghosts for adventure mode
Title: Re: DFHack 0.47.04-r4
Post by: Eric Blank on January 27, 2021, 03:06:27 am
Hey, I've been having a problem with df freezing up for 1-20 minutes on startng DF or generating a new world, only with dfhack installed. any ideas what could be causing this?
Title: Re: DFHack 0.47.04-r4
Post by: FantasticDorf on January 27, 2021, 03:51:37 am
Hey, I've been having a problem with df freezing up for 1-20 minutes on startng DF or generating a new world, only with dfhack installed. any ideas what could be causing this?

Longshot nontechnical question but do you have anything passively in your onload.init that shouldnt be there if you've been repurposing the file between editions of DFhack? Just wrench it open with notepad++ and have a look inside to make sure its pretty much default as it should be.

Thats the kind of thing from when i ported some file configurations outright, even though the raws its targeting all line up it still gave me significant CTD induced by DFhack after loading rivers early on in worldgen.
Title: Re: DFHack 0.47.04-r4
Post by: Eric Blank on January 27, 2021, 11:26:49 am
No, i havent made any customizations at all. I did manage to pinpoint the worldgen slowdown to a worldgen.txt issue; replacing it with a default one removes that, but it still hangs for a few minutes on startup.
Title: Re: DFHack 0.47.04-r4
Post by: lethosor on January 27, 2021, 08:27:16 pm
make sure its pretty much default as it should be.

I want to clarify: the .init files are absolutely intended to be customized. We happen to ship defaults that have been tuned based on user feedback (enabling things that are generally useful and relatively uncontroversial) but they are text files specifically so that you can edit them.

If you were running some third-party tool that introduced a crash from a .init file, then that's not something we can address, of course. However, if you were running any tool that's part of a DFHack distribution, and it was causing a crash, that should be considered a bug in almost all cases, and please tell us about it.

Hey, I've been having a problem with df freezing up for 1-20 minutes on startng DF or generating a new world, only with dfhack installed. any ideas what could be causing this?
Are you using Windows? If so, hangs on startup can be due to antivirus software. For instance, Windows Defender tends to slow down DFHack at startup, sometimes significantly, probably because of the 100+ DLLs (plugins) that DFHack loads individually. You could check task manager to see if some antivirus service is using up a lot of CPU cycles on startup - if this is happening, my best recommendation would be to exempt the entire DF folder in your antivirus settings.
Title: Re: DFHack 0.47.04-r4
Post by: Atkana on January 28, 2021, 06:11:57 am
So uh, I made that resource for handling persistently saving lua tables directly with the json implementation a while ago, but dragged my feet on getting the documentation written up :P It's intended to be used as a module, and handles either saving data globally (available anywhere) or as world data (specific to the save). World data is saved automatically whenever the world is unloaded, as well as whenever the game is saved via autosave or quicksave.

If it's acceptable enough I'll get around to submitting it to the repo, but I'd appreciate if some people went over it first:

Spoiler (click to show/hide)
Title: Re: DFHack 0.47.04-r4
Post by: A_Curious_Cat on January 28, 2021, 09:57:53 pm
Whelp (http://www.bay12forums.com/smf/index.php?topic=177989.0)!  I look forward to trying out DFHack 0.47.05-r1!
Title: Re: DFHack 0.47.04-r4
Post by: lethosor on January 28, 2021, 11:03:14 pm
I am thinking of putting out a 0.47.04-r5 release soon to address a couple crashes (some from quickfort that I remember off the top of my head).

This would likely delay 0.47.05 work a little, but the good news is that our automated upgrade script worked (https://github.com/DFHack/df-structures/pull/418) (thanks BenLubar!) so that takes care of a decent amount of overhead when it comes to researching .05.
Title: Re: DFHack 0.47.04-r4
Post by: lethosor on January 28, 2021, 11:46:15 pm
So uh, I made that resource for handling persistently saving lua tables directly with the json implementation a while ago, but dragged my feet on getting the documentation written up :P It's intended to be used as a module, and handles either saving data globally (available anywhere) or as world data (specific to the save). World data is saved automatically whenever the world is unloaded, as well as whenever the game is saved via autosave or quicksave.

If it's acceptable enough I'll get around to submitting it to the repo, but I'd appreciate if some people went over it first:

I'm a bit preoccupied with other things at the moment (see above post) and there's a risk of me forgetting about this.

Could you make a pull request against the DFHack repo for this? I think it would go best in the "library/lua" folder (which installs to "hack/lua", for reference), but we can figure it out there. At first glance, it looks good, but there is certainly an opportunity to implement some things natively, like the save event checking (which you already requested (https://github.com/DFHack/dfhack/issues/1733) :) ) Thanks for taking this on!
Title: Re: DFHack 0.47.04-r4
Post by: towerator on January 29, 2021, 05:05:47 am
PTW and wait for the 47 05 release of DFhack.


btw, I must say that you're doing a great job, so thank you all to the DFhack team!
Title: Re: DFHack 0.47.04-r5
Post by: lethosor on January 31, 2021, 10:22:21 am
A new release is up for 0.47.04 (not 0.47.05 yet) - there were a couple important fixes made since 0.47.04-r4 that we felt warranted a new release before we broke compatibility with 0.47.04.

Download link: https://github.com/DFHack/dfhack/releases/tag/0.47.04-r5

0.47.05 support is in progress - I know some people have had luck with a build from Buildmaster (https://dfhack.org/builds/) and the newest builds on there should improve support for 0.47.05 pretty soon.
Title: Re: DFHack 0.47.04-r5
Post by: feelotraveller on February 02, 2021, 07:43:43 pm
I have noticed an issue with the prospect plugin.

(Using df47.05 with dfhack-0.47.05-alpha0-210131001-Linux-64bit-gcc-7.)

Occasionally running prospect pre-embark gives a result for Blue Diamonds which is an order of magnitude (or two) off.
From the embark where I first noticed the issue both results using the 'all' option (the post embark after a reveal all)
Code: [Select]
(pre-embark)
DIAMOND_BLUE :       496 Z:  75..91
DIAMOND_FY :          72 Z:  75..139
KIMBERLITE :        6317 Z:  75..139
(post embark)
DIAMOND_BLUE :         3 Z:  81..85
DIAMOND_FY :          35 Z:  81..138
KIMBERLITE :        9470 Z:  75..139

Checking sites on the same worldgen the strange pre-embark results reoccurred at a number of sites across the world, repeatedly 400-1000 blue diamonds predicted.  I probably tried about 100 sites spread across the world and about 10 of them had these results.  Predictions for faint yellow diamonds were only a fraction of those for blue diamonds at each site.  I did not notice any results predicted for other colours of single occurence diamonds (black, green, clear, red, yellow), certainly there were none of this magnitude.
Title: Re: DFHack 0.47.04-r5
Post by: lethosor on February 02, 2021, 09:12:01 pm
Good news: check-structures-sanity passed on linux64 (as part of trying to debug the above issue) so I think we can put up at least a beta release fairly soon for 0.47.05 here. Granted, the one structures change we've made would only have been caught on linux32, so there's not a guarantee that everything is perfect yet.

I have noticed an issue with the prospect plugin.

(Using df47.05 with dfhack-0.47.05-alpha0-210131001-Linux-64bit-gcc-7.)

Occasionally running prospect pre-embark gives a result for Blue Diamonds which is an order of magnitude (or two) off.
From the embark where I first noticed the issue both results using the 'all' option (the post embark after a reveal all)
Code: [Select]
(pre-embark)
DIAMOND_BLUE :       496 Z:  75..91
DIAMOND_FY :          72 Z:  75..139
KIMBERLITE :        6317 Z:  75..139
(post embark)
DIAMOND_BLUE :         3 Z:  81..85
DIAMOND_FY :          35 Z:  81..138
KIMBERLITE :        9470 Z:  75..139

Checking sites on the same worldgen the strange pre-embark results reoccurred at a number of sites across the world, repeatedly 400-1000 blue diamonds predicted.  I probably tried about 100 sites spread across the world and about 10 of them had these results.  Predictions for faint yellow diamonds were only a fraction of those for blue diamonds at each site.  I did not notice any results predicted for other colours of single occurence diamonds (black, green, clear, red, yellow), certainly there were none of this magnitude.
As for this: first off, thanks for the detailed report! A couple questions:
- Is it consistently reproducible if you look in the same spot in the same world? If so, could you upload the save and report an issue on GitHub? If the save is small enough, you might be able to attach it on GitHub while reporting it there.
- Have you made any mods / changes to the raws? I'm not sure if this would affect prospect, but it might.
Title: Re: DFHack 0.47.04-r5
Post by: feelotraveller on February 03, 2021, 02:31:52 pm
Good news: check-structures-sanity passed on linux64 (as part of trying to debug the above issue) so I think we can put up at least a beta release fairly soon for 0.47.05 here. Granted, the one structures change we've made would only have been caught on linux32, so there's not a guarantee that everything is perfect yet.

Yay, glad to hear good things came.  :)

Quote
As for this: first off, thanks for the detailed report! A couple questions:
- Is it consistently reproducible if you look in the same spot in the same world? If so, could you upload the save and report an issue on GitHub? If the save is small enough, you might be able to attach it on GitHub while reporting it there.
- Have you made any mods / changes to the raws? I'm not sure if this would affect prospect, but it might.

Sorry for the delay - I was using CLA graphics which did make some changes to the raws so I wanted to rule that out (it didn't make a difference).
Also the save uses my custom worldgen and I had hoped to reproduce from a vanilla worldgen but the difficulty of finding 'any' single occurence diamonds got the better of my after trying a couple of times in two hour plus sessions. Not that it should make a difference - mentioned for completeness.

Yes it is consistent to the same spot in the same world.

Github issue created (https://github.com/DFHack/dfhack/issues/1772).

I uploaded the pre-embark save separately on dffd (https://dffd.bay12games.com/file.php?id=15400) (linked in above report).
If top left of map is (1,1) and embark rectangle is default 4x4 then
(1,25) with embark rectangle bottom right corner (diamond_blue 894 diamond_fy 128)
(65,41) with embark rectangle top left corner (diamond_blue 1287 diamond_fy 307)
(14,35) with embark rectangle centred (diamond_blue 704 diamond_fy 128)
are all locations to reproduce the issue (there are others...).
Numbers are a bit different to above since I was originally using a 3x3 embark rectangle as part of my personal init edits.
Title: Re: DFHack 0.47.04-r5
Post by: lethosor on February 03, 2021, 06:57:07 pm
Sounds good, and thanks for including your worldgen params on GitHub too! The save should certainly help track down whether this is an issue on the DFHack or DF side, at least.
Title: Re: DFHack 0.47.04-r5
Post by: PatrikLundell on February 04, 2021, 07:20:11 am
I think I understand why feelotraveller's prospecting gets wildly optimistic yields:
Using the Biome Manipulator to view the geo biome at the first location pointed out and the lowest (gabbro) layer , I see that % (in Biome Manipulator, being "size" in prospector) is 9 for DIAMOND_FY but 86 for DIAMOND_BLUE, but DIAMOND_BLUE is a CLUSTER_ONE nested within the DIAMOND_FY CLUSTER_SMALL.

I believe the problem here is that to get an estimate of the amount of a material you'll have to weigh not only the material itself, but also the ones transitively enclosing it (DIAMOND_FY at 9 and KIMBERLITE at 85, in this case).

The relevant code in Prospector is at lines 453-480, and the TODO comment is probably an indication of the original author being aware of difficulties.
Adjusting the code would require both to "unwind" the nesting to get at the enclosing percentages/sizes, and to determine if the scale factors (1*5, 6*7, and 700 *1 respecitvely for CLUSTER_ONE, CLUSTER_SMALL, and CLUSTER) would have to be adjusted if an additional reduction factor is introduced.

Anyway, I don't think the DF logic has changed, but rather that we have cases where low probability clusters enclose high probability ones.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: lethosor on February 10, 2021, 11:08:25 pm
New release - officially in beta now: https://github.com/DFHack/dfhack/releases/tag/0.47.05-beta1

We think things are stable, and haven't really heard any reports of issues with 0.47.05. That said, please let us know as soon as possible if you're experiencing issues with DFHack specific to 0.47.05. (It has been a while, but as a reminder, we rely heavily on user feedback when it comes to new DF releases.)
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: clinodev on February 10, 2021, 11:23:57 pm
Nice!

I'll try to make a set of mini Packs with this, and get it out there.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: feelotraveller on February 11, 2021, 03:21:22 am
New release - officially in beta now: https://github.com/DFHack/dfhack/releases/tag/0.47.05-beta1

We think things are stable, and haven't really heard any reports of issues with 0.47.05. That said, please let us know as soon as possible if you're experiencing issues with DFHack specific to 0.47.05. (It has been a while, but as a reminder, we rely heavily on user feedback when it comes to new DF releases.)

Thanks for the quick early release(s).  :)

I get a bunch of messages about plugins not being built for this version, although as far as I can tell they are trival.
Spoiler (click to show/hide)
Using dfhack-0.47.05-beta1-Linux-64bit-gcc-7.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: clinodev on February 11, 2021, 05:19:23 am
New release - officially in beta now: https://github.com/DFHack/dfhack/releases/tag/0.47.05-beta1

We think things are stable, and haven't really heard any reports of issues with 0.47.05. That said, please let us know as soon as possible if you're experiencing issues with DFHack specific to 0.47.05. (It has been a while, but as a reminder, we rely heavily on user feedback when it comes to new DF releases.)

Thanks for the quick early release(s).  :)

I get a bunch of messages about plugins not being built for this version, although as far as I can tell they are trival.
Spoiler (click to show/hide)
Using dfhack-0.47.05-beta1-Linux-64bit-gcc-7.

Did you by chance install the beta over one of the previous versions of DFhack? I tried that to quickly update my little single tileset "packs", and got the same result, but when I deleted the old /hack folder and tried again, it was clean and error-free.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: feelotraveller on February 11, 2021, 06:14:30 am
New release - officially in beta now: https://github.com/DFHack/dfhack/releases/tag/0.47.05-beta1

We think things are stable, and haven't really heard any reports of issues with 0.47.05. That said, please let us know as soon as possible if you're experiencing issues with DFHack specific to 0.47.05. (It has been a while, but as a reminder, we rely heavily on user feedback when it comes to new DF releases.)

Thanks for the quick early release(s).  :)

I get a bunch of messages about plugins not being built for this version, although as far as I can tell they are trival.
Spoiler (click to show/hide)
Using dfhack-0.47.05-beta1-Linux-64bit-gcc-7.

Did you by chance install the beta over one of the previous versions of DFhack? I tried that to quickly update my little single tileset "packs", and got the same result, but when I deleted the old /hack folder and tried again, it was clean and error-free.

That's exactly what I did!  Thank you that fixed it.

Not sure exactly how though, since I confirmed that the actual plugin files had been updated to the newer versions (according to timestamps). Although I guess dfhack could be looking at the creation date of the plugins folder... or something?
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: xordae on February 11, 2021, 09:51:27 am
So far, the 47.05 beta is working well.

Earlier, I fucked up the walls behind my archery targets and re-painted them with tiletypes. There is a 1 z-level drop behind the targets, and bolts are properly recovered down there. Now that I expanded my fortress, exactly below the bolt drop there are new rooms. Now the bolts drop through the existing floor tiles at z-level 1 and land at z-level 2 down in those rooms. I assume this is because I recreated solid stone there with tiletypes. How can I use tiletypes to completely regenerate a z-level wall? Only doing Paint: STONE WALL INORGANIC:GRANITE CLUSTER is apparently not enough to regenerate the proper ceiling and floor parts.

Painting floors on the same level as the archery targets makes bolts break as they're supposed to.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: feelotraveller on February 11, 2021, 11:10:05 am
I think the explanation is that walls provide a floor above them (and hence not below them strange as it seems).  Try either making a floor on the archery level and then turning that to a wall with tiletypes, or alternatively creating a wall on the level below first (which can be returned to a floor for your bedrooms after with tiletypes or otherwise, now leaving behind a proper roof).
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: lethosor on February 11, 2021, 11:22:30 am
I get a bunch of messages about plugins not being built for this version, although as far as I can tell they are trival.
Using dfhack-0.47.05-beta1-Linux-64bit-gcc-7.
Glad that a clean install fixed it. I checked the build you downloaded, and all of the plugin versions in it are correct, so my guess would be that you didn't overwrite the existing plugins the first time you installed DFHack. DFHack just looks at the contents of plugins, not their modification times. Also, it's not a "trivial" error, per se - the plugins would be ignored entirely if you see that message. Maybe that message should be clearer that this is the case.

Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: xordae on February 11, 2021, 12:13:27 pm
Cheers feelotraveller, I'll probably throw a "nuke" at the problem and create floors, then walls on all z-levels from the bottom up and see if that sticks.

..Well, that unfortunately did not work.

Oddly, constructing floors does not work either. I'm starting to think this is a DF bug and has nothing to do with tiletypes.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: feelotraveller on February 11, 2021, 12:16:05 pm
I get a bunch of messages about plugins not being built for this version, although as far as I can tell they are trival.
Using dfhack-0.47.05-beta1-Linux-64bit-gcc-7.
Glad that a clean install fixed it. I checked the build you downloaded, and all of the plugin versions in it are correct, so my guess would be that you didn't overwrite the existing plugins the first time you installed DFHack. DFHack just looks at the contents of plugins, not their modification times. Also, it's not a "trivial" error, per se - the plugins would be ignored entirely if you see that message. Maybe that message should be clearer that this is the case.

Hmm.  What I did was overwrite alpha0 with beta1 with a copy-paste replace all.  However I checked after encountering problems and the plugins were those provided by beta1 when I was getting that message, so something else was triggering it.  Given that clinodev experienced the same, or similar, something strange does appear to be going on.  (I'm sure we won't be the last to try the shortcut of overwriting an existing installation.)
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: lethosor on February 11, 2021, 05:56:10 pm
Hmm.  What I did was overwrite alpha0 with beta1 with a copy-paste replace all.  However I checked after encountering problems and the plugins were those provided by beta1 when I was getting that message, so something else was triggering it.  Given that clinodev experienced the same, or similar, something strange does appear to be going on.  (I'm sure we won't be the last to try the shortcut of overwriting an existing installation.)

My next best guess is that your copy-and-paste technique put things into a separate subfolder of the DF folder (e.g. something like hack/hack/plugins/foo.plug.so instead of hack/plugins/foo.plug.so). This would result in a folder that appears to have new plugins but is being ignored by DFHack.

For reference, this is what I ran to check the versions of the plugins in the copy I downloaded. It will probably print a couple garbage characters, but any recognizable version strings should just be the expected DF or DFHack version (0.47.05-beta1 or 0.47.05-beta1-0-g49b6e814 in this case).
Code: [Select]
strings hack/plugins/* | grep '0.47' | sort | uniq

Overwriting an existing installation should usually work (documented here (https://docs.dfhack.org/en/stable/docs/Installing.html#upgrading-dfhack), but not with any more detail than what you described).
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: feelotraveller on February 12, 2021, 02:29:03 am
My next best guess is that your copy-and-paste technique put things into a separate subfolder of the DF folder (e.g. something like hack/hack/plugins/foo.plug.so instead of hack/plugins/foo.plug.so). This would result in a folder that appears to have new plugins but is being ignored by DFHack.

For reference, this is what I ran to check the versions of the plugins in the copy I downloaded. It will probably print a couple garbage characters, but any recognizable version strings should just be the expected DF or DFHack version (0.47.05-beta1 or 0.47.05-beta1-0-g49b6e814 in this case).
Code: [Select]
strings hack/plugins/* | grep '0.47' | sort | uniq

Overwriting an existing installation should usually work (documented here (https://docs.dfhack.org/en/stable/docs/Installing.html#upgrading-dfhack), but not with any more detail than what you described).

I reproduced the behaviour on my end.  (It was not a file structure problem, although that's a fair enough guess.)
Got the same error message I originally posted for 20 plugins.
After some talking to myself about how the problem was beyond me it turned out to be very simple.

Those 20 plugins don't exist in the beta1 version.  So that's a case covered by the DFHack documentation.  Apologies for taking up your time.  (Although perhaps you could confirm that they were meant to be removed?)
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: lethosor on February 12, 2021, 08:54:37 am
Those plugins shouldn't have been included in a release at all - they are dev plugins, intended mainly for testing. Did you compile the original build yourself? If not, I'll take a look at our build server settings - it's possible that the non-release builds are including those.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: feelotraveller on February 12, 2021, 10:05:38 am
Ah, that makes sense.

No I did not build it myself but got it from buildmaster.  Specifically - dfhack-0.47.05-alpha0-210131001-Linux-64bit-gcc-7.tar.bz2
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: lethosor on February 12, 2021, 07:40:08 pm
Sorry about that, all. I tracked down the logs for that build - looks like Buildmaster is indeed enabling dev plugins for development builds, and not for release builds. It has been a while since the sorts of errors in your log have been reported, so I only downloaded a release build to check, not realizing that none of the plugins in your log were actually in the package I downloaded.

Anyway, ignoring those warnings if you don't want those plugins is fine (they're not very useful for day-to-day use anyway) and it won't affect the rest of DFHack. The best solution here, as you've already mentioned, is to go with the approach of uninstalling the old version of DFHack before installing the new one.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: javascripter on February 19, 2021, 06:52:20 am
not sure if good place to ask this, if there is better place let me know and i can move it there.

I've modded a custom race and screwed up a bit in the entity so that my equivelent of militia captains cannot be assigned (forgot to change ID of assigner from dwarfs), and for various reasons including using dfhack I didn't test for a way into making a fort.

Can I with dfhack / lua assign them manually that way? I found a lua script here http://www.bay12forums.com/smf/index.php?topic=121272.0 for assigning monarches, but I've got no idea how to adapt it for nobles with [SITE]. I thought I would just need to figure out what the assignment ID was and insert something to the units entity_links, but it seems [SITE] nobles don't show up searching through the entity list and extrapolating a number from nobles without [SITE] gives no result.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: PatrikLundell on February 19, 2021, 07:32:44 am
I believe there assigned roles for entities overlap in a somewhat messy way so that some things are only in the civ entity, while others are only in the site government ENTITY (emphasized, as it's not in the site structure). The way these structures are used differ between the civ and the site government. I have no idea whether hacking dorfs into these structures is sufficient, though (I think there are multiple places where they are, or at least may be, included.

Somewhat vague and possibly incorrect, as it's from my flaky memory of the structures. Regardless, you'll need to familiarize yourself with the entity structure, as you'd have to be very lucky for someone else to have written a suitable script already, so you'd have to expect to do it yourself.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: javascripter on February 19, 2021, 08:44:26 am
I can write a script; but is that structure (object, struct, whatever) documented somewhere?

For example, because of previous script I linked I know how to get nemesis record of a unit and insert something into the entity_links of the nemesis record; but I have no idea what a nemesis record is or what entity links is, and google only finds other scripts an no documentation or wherever whoever made the first script using entity_links figured that out from (https://docs.dfhack.org/en/stable/docs/Lua%20API.html has the function for getting nemesis record, but nothing else about it)

I can even print the nemesis record and entity_link (or values for each index since it is array) but it just gives some text that gives nothing useful (I found this https://peridexiserrant.neocities.org/docs-structures-test/docs/_auto/structures/refs.html but it doesn't seem to be very useful for this purpose) EDIT: and some hex, which is even less useful than the text

For example, if I want to find for what values of df.global.ui.xxx xxx is valid, what is best place to look?
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: Rumrusher on February 19, 2021, 11:07:55 am
Code: [Select]
function Memorypurge()
local adv=df.global.world.units.active[0]
local mem=df.global.world.history.figures[adv.hist_figure_id].info.known_info.known_events
for k,v in pairs(mem) do

if v==nil then break else
mem:erase(k)

end
end
end
Memorypurge()

so currently wrote this WIP proof of concept script to help cut down adventurer Memory bloat it could be optimized a bit to say save certain reports and rumors and possibly cull out seeing a wild animal attack another wild animal, also don't know how to stop it from throwing out an error half the time so shrugs on that bit.

also said script is a revised version of the old gigapurge script that I feel probably the same warnings of be careful on using this.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: PatrikLundell on February 19, 2021, 11:18:19 am
df.global.world contains almost everything of interest (there are things outside, like df.global.ui). gui/gm-editor is the standard tool for looking at df structures, but you can also look at the XML source for it (either in a local copy of dfhack if you compile it yourself, or on github (approximately named dfhack/df-structures). The XML has the advantage that there are some comments in there, but gui/gm-editor is usually easier to use because you don't have to guess at the file things are stored in).

Entities are stored in df.global.world.entities.all.

I don't really know what a nemesis record is for, but there are references to them and they, in turn, reference the hist fig targeted, which has been sufficient for my purposes so far.

"gui/gm-editor df.global.ui" will show you the top level of ui, and allows you to traverse further down the tree (when the elements are compound, of course), but, as indicated above, you probably want df.global.world as your top exploration level.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: lethosor on February 19, 2021, 11:48:54 am
not sure if good place to ask this, if there is better place let me know and i can move it there.

I've modded a custom race and screwed up a bit in the entity so that my equivelent of militia captains cannot be assigned (forgot to change ID of assigner from dwarfs)
...
I thought I would just need to figure out what the assignment ID was and insert something to the units entity_links, but it seems [SITE] nobles don't show up searching through the entity list and extrapolating a number from nobles without [SITE] gives no result.

If I'm understanding this correctly, this is a position that you want to be able to assign from the "n" screen, but can't due to a mistake in the raws, yes? If that's the case, I would actually suggest trying to change this on the entity level, to allow the position to be assigned, rather than trying to forcibly assign a position that can't be assigned. I think it would be easier and less error-prone to leave the actual position assignment logic to DF.

The relevant data is probably stored at the entity level (e.g. "df.historical_entity.find(unit.civ_id)") but might be stored in the entity raws only instead ("df.entity_raw.find(unit.civ_id)"). Changes to raws (technically the in-memory versions of raws in this case) typically only affect new entities/objects, so I would recommend looking at the entity itself first.

I would recommend making a backup of your save first, in case you corrupt something irreversibly.

As a side note, you can actually drop the "df.global." prefix in both the "lua" interpreter and "gui/gm-editor" for convenience, e.g. "gui/gm-editor world" will work.

For example, if I want to find for what values of df.global.ui.xxx xxx is valid, what is best place to look?
That depends on quite a lot - what type(s) are you asking about here? My best answer is for enums, which would typically show up as numbers in Lua. Editing an enum field in gui/gm-editor would bring up a dialog with each (known) valid value, along with their names, and the enum name itself at the top. You could also track down the field in df-structures, like PatrikLundell mentioned. For scripting, you should always use the name ("df.enum_name.ValueName"), never the number, because the raw numbers can change. Valid values for other fields can vary greatly, and df-structures might have more relevant information on a case-by-case basis.

I can even print the nemesis record and entity_link (or values for each index since it is array) but it just gives some text that gives nothing useful... EDIT: and some hex, which is even less useful than the text
Try printall() (shorthand: "~" in the "lua" interpreter). I'm guessing you were just getting something like "<nemesis_record: 0x25f25a0>", but if not, an example of what you are seeing would be helpful. Note that gui/gm-editor would also make it a bit easier to browse structures.

As for what a nemesis record is, I suppose that is something that could be documented. I would need to track down past discussions on it. Many structures don't have documentation outside of the XML files, because as of 0.47.05, there are 1721 of them, and both writing the documentation and keeping it up-to-date would be a massive undertaking.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: javascripter on February 19, 2021, 12:56:07 pm
df.global.world contains almost everything of interest (there are things outside, like df.global.ui). gui/gm-editor is the standard tool for looking at df structures, but you can also look at the XML source for it (either in a local copy of dfhack if you compile it yourself, or on github (approximately named dfhack/df-structures). The XML has the advantage that there are some comments in there, but gui/gm-editor is usually easier to use because you don't have to guess at the file things are stored in).

Entities are stored in df.global.world.entities.all.

I don't really know what a nemesis record is for, but there are references to them and they, in turn, reference the hist fig targeted, which has been sufficient for my purposes so far.

"gui/gm-editor df.global.ui" will show you the top level of ui, and allows you to traverse further down the tree (when the elements are compound, of course), but, as indicated above, you probably want df.global.world as your top exploration level.

So, my problem was a lack of understanding of gui/gm-editor, I thought it was only used for editing unit personalities and things like that.

After posting I found the df structures git, but discarded it after not reading enough since it just looked like a massive list of enums and I didn't read far enough to get to the structs.

I've found gui/gm-editor is nice for seeing orders of things, and then when I run into an issue with pointers findstr (grep for linux) is pretty useful with the xml files.




If I'm understanding this correctly, this is a position that you want to be able to assign from the "n" screen, but can't due to a mistake in the raws, yes? If that's the case, I would actually suggest trying to change this on the entity level, to allow the position to be assigned, rather than trying to forcibly assign a position that can't be assigned. I think it would be easier and less error-prone to leave the actual position assignment logic to DF.

The relevant data is probably stored at the entity level (e.g. "df.historical_entity.find(unit.civ_id)") but might be stored in the entity raws only instead ("df.entity_raw.find(unit.civ_id)"). Changes to raws (technically the in-memory versions of raws in this case) typically only affect new entities/objects, so I would recommend looking at the entity itself first.

I would recommend making a backup of your save first, in case you corrupt something irreversibly.

As a side note, you can actually drop the "df.global." prefix in both the "lua" interpreter and "gui/gm-editor" for convenience, e.g. "gui/gm-editor world" will work.


had already started considering this, I found that site nobles are in entity_links, just under a totally different entity_ID, I guess each site gets a separate ID. I was thinking just telling that unit to be a militia captain might not make it possible to actually make a second squad and may just lead to the unit being on duty with no barracks or something unfortunate like that.


That depends on quite a lot - what type(s) are you asking about here? My best answer is for enums, which would typically show up as numbers in Lua. Editing an enum field in gui/gm-editor would bring up a dialog with each (known) valid value, along with their names, and the enum name itself at the top. You could also track down the field in df-structures, like PatrikLundell mentioned. For scripting, you should always use the name ("df.enum_name.ValueName"), never the number, because the raw numbers can change. Valid values for other fields can vary greatly, and df-structures might have more relevant information on a case-by-case basis.

apologies for unclarity, what I meant by that was exactly what gui/gm-editor does; where i can see a list of all the properties (for example, dfhack.units has .isGelded, .isEggLayer, ...)

whoever wrote this utility must be pretty smart person as well, the options for enums works pretty nicely


Try printall() (shorthand: "~" in the "lua" interpreter). I'm guessing you were just getting something like "<nemesis_record: 0x25f25a0>", but if not, an example of what you are seeing would be helpful. Note that gui/gm-editor would also make it a bit easier to browse structures.

As for what a nemesis record is, I suppose that is something that could be documented. I would need to track down past discussions on it. Many structures don't have documentation outside of the XML files, because as of 0.47.05, there are 1721 of them, and both writing the documentation and keeping it up-to-date would be a massive undertaking.

printall is very helpful, again whoever wrote this must be pretty smart person

I think it isn't a big deal if it has explanatory documentation; I just thought from the name it was something that would be somehow more meaningful, while after looking at what it contains it just has stuff about units

What would be cool to have documentation on is what you and patrik just told me; though I guess that probably exists and I just am not great at google and didn't even know what I was trying to find.



EDIT: it seems the raws you mentioned in gui/gm-editors are changed by modifying the txt raws, as they seem to already have the fix

EDIT: found where to solve the problem, was very easy after you mentioned df.historical_entity.find(unit.civ_id) (though I actually changed for the site entity rather than the civilization entity)
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: lethosor on February 19, 2021, 07:00:18 pm
So, my problem was a lack of understanding of gui/gm-editor, I thought it was only used for editing unit personalities and things like that.
Ah, you might have been thinking of gui/gm-unit. They have similar names, but gui/gm-editor came first.

Quote
I think it isn't a big deal if it has explanatory documentation; I just thought from the name it was something that would be somehow more meaningful, while after looking at what it contains it just has stuff about units

What would be cool to have documentation on is what you and patrik just told me; though I guess that probably exists and I just am not great at google and didn't even know what I was trying to find.
There are a couple places where unit-related data is stored: besides the "unit" type, there are also "historical_figure" and "nemesis_record", with references between each other. "identity" might also be relevant sometimes. I was mostly thinking that it would be worth documenting the reasons why some of them only exist sometimes (a wild animal typically only has a "unit" instance, for example), and in certain cases, which source overrides the others (for things like names). I don't have a great source on why "nemesis_record" exists at the moment, but there is a reason.

Quote
EDIT: found where to solve the problem, was very easy after you mentioned df.historical_entity.find(unit.civ_id) (though I actually changed for the site entity rather than the civilization entity)
If it's something presentable, sharing it here might be useful to others :)
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: javascripter on February 19, 2021, 11:56:18 pm
Ah, you might have been thinking of gui/gm-unit. They have similar names, but gui/gm-editor came first.

That is exactly what i was thinking


Quote
If it's something presentable, sharing it here might be useful to others :)

So first you need to find the civilization entity ID or site entity ID (I think first one affects new forts while second affects current forts, but have only done it for site entity ID), if you go to nemesis record, for example:
gui/gm-editor dfhack.units.getNemesis(dfhack.gui.getSelectedUnit())
then there is an entry entity_links, which all your dwarves should have two memberst entries, one for civilization entity ID and one for site entity ID. Your nobles/administrators should have a positionst entry for your site ID, while I would expect a monarch to have a positionst entry for the civilization ID
I'm sure there are other ways to find civlization ID / site ID

then with gui/gm-editor df.historical_entity.find(ID), there will be an entry for positions, which has an entity "own" (maybe "site" for the civilization level ID, not sure)
that is a list of all positions, each has the name, an ID, and then what i care about is appointed_by and appointed_by_civ fields, in my case they were empty and I needed to add (alt+i) to the first one an entry with no name (leave blank) and value of the ID of another position in my fort and for the second one an entry with no name and value of the ID of the site entity (not sure if this was neccessary, but all the other positions had it)
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: Warmist on February 24, 2021, 01:42:56 am
So, my problem was a lack of understanding of gui/gm-editor, I thought it was only used for editing unit personalities and things like that.
Ah, you might have been thinking of gui/gm-unit. They have similar names, but gui/gm-editor came first.

Quote

Yeah it was supposed to be a suite of "Game Master" tools for editing everything like you would be in DnD or GURPS pen and paper rpg.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: jecowa on February 28, 2021, 12:37:24 am
Something in DFHack reveals information that is supposed to be hidden to the player. (Vampire true name).

source: https://www.reddit.com/r/dwarffortress/comments/ltzu82/if_i_wasnt_sure_i_found_the_vampire_before/gp3mycq/
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: lethosor on February 28, 2021, 12:45:41 am
Looking at the rest of the thread, that's a feature of the "confirm" plugin, specifically a feature new in https://github.com/DFHack/dfhack/issues/1593. Looks like it's just reading "unit.name", so likely a call to getVisibleName() would fix it. I'll open an issue.

Edit: fixed it in https://github.com/DFHack/dfhack/commit/1b2eed7c5e4878f057aab13e2adb7c8293af45d6
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: xordae on February 28, 2021, 01:55:21 am
Spoiler (click to show/hide)
After what PatrikLundell said in another thread maybe this is a DF bug after all.

I also stole some dude's script and adapted it to untag all in_job flagged objects, fixing instruments that are stuck with TSK after aborted performances. Maybe someone finds this useful.

fixjobs.lua
Code: [Select]
for i, item in ipairs (df.global.world.items.all) do
    if item.flags.in_job then
     item.flags.in_job = false
        dfhack.println ("Job Flags Unset!")
     end
  end
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: PatrikLundell on February 28, 2021, 04:12:33 am
I don't think the bug concerning flying stuff sometimes falling through floors is the reason hacked floors don't work correctly, but rather a failure somewhere in the hacking to fill in all the info that's should be filled in.

The fixjobs script is not a good one, as it will remove all items that are tasked for jobs from their tasks. If you're lucky, it will just result in occasional cancellation message that items are lost or destroyed when they targeted again by someone else (such as e.g. the boulder targeted for building a wall gets hauled away to a stone stockpile, failing the construction job). If you're unlucky it will have worse consequences.

Items are marked as tasked for a reason, namely because that stops the items from being considered for usage by other tasks. The only case where you want to forcibly remove the flag is when it remains erroneously (such as for the dropped instruments). In order to determine that you'd have to find out which items are marked for tasks that no longer exist. At a guess, it might be possible to iterate through the two(?) jobs lists for each tasked item to see if they're targeted by any job, and remove the flags only for the ones that aren't targeted by any jobs, but there may be cases where things are targeted without any explicit jobs being posted (picking up/sorting owned/assigned items?).
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: xordae on February 28, 2021, 04:22:32 am
I ran it a bunch and only got job cancellations.

But if anyone is up for doing a more indepth instrument fix then by all means. ;)
I think just narrowing the type to "instruments" would also be enough to make the script harmless for all intents and purposes.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: Roses on February 28, 2021, 01:04:30 pm
I don't think the bug concerning flying stuff sometimes falling through floors is the reason hacked floors don't work correctly, but rather a failure somewhere in the hacking to fill in all the info that's should be filled in.

To comment on this, I was able to get hacked floors to work properly (for multi-level buildings) but there was a whole list of things/flags that need to be set (you can't just change the tiletype or artificially construct a floor). IIRC it had something to do with setting the occupancy and walkable settings of the tiles (and maybe some other things)
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: xordae on March 01, 2021, 01:02:53 am
If you could lay out your steps so that I can try it, that'd be awesome.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: Bumber on March 02, 2021, 07:37:21 am
How much do we know about the interaction between ballista bolts and trees? Could be useful for an updated script that destroys trees.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: PatrikLundell on March 02, 2021, 01:00:00 pm
How much do we know about the interaction between ballista bolts and trees? Could be useful for an updated script that destroys trees.
Are you sure ballista bolt tree removal is a good model itself? Unless something has changed recently, tree obliteration still leaves holes in water, for instance, and I don't know if anyone has investigated whether it might cause falling tree cave-ins if you channel away the tile it stood on (and I'd investigate that on a tree that didn't stand in an underground lake for ease of testing).

As a minimum you'd have to remove the tree from the list of plants associated with the tile block (I think the list is in the top left corner 16*16 block of the MLT it belongs to, with the lists for the other tiles being empty), replace the tree tile with the underlying surface tile (and there you could chose between the actual underlying surface or use the soil type DF would produce), and you'd probably have to mark one or more of these structures as modified to trigger DF to update them.
  You might also have to go through the upper levels of the tree to process any items stuck there to get DF to realize they should now start to fall down (this obviously has to be done before you destroy the tree object).
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: Uthimienure on March 02, 2021, 08:30:45 pm
I use digcircle all the time, but I can't see how (if possible) to make it use "Marker Only" mode, which I would find tremendously helpful.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: lethosor on March 02, 2021, 10:21:15 pm
I use digcircle all the time, but I can't see how (if possible) to make it use "Marker Only" mode, which I would find tremendously helpful.

It doesn't look possible currently, but there is support for priorities, so it might not be too hard to add. I opened a request for it at https://github.com/DFHack/dfhack/issues/1783

You might be able to use DF's existing "toggle marker mode" (d-M) for this, though. If you're designating a circle in an unmarked area, you could fairly easily convert it to marker mode after designating it. This becomes more complicated if there are already designations in the area, but you could still work around it if they're all one type (marker or non-marker). For instance, if you have only non-marker designations that you want to preserve, you could convert them to markers with d-M, then run "digcircle", then toggle everything with d-M, leaving just your circle as a marker. The same would work if the existing designations are only markers.

That is rather complicated, though, and hopefully a "-m" option to the dig commands wouldn't be too hard. I probably can't get to it any time soon, but I'd be willing to point someone in the right direction.
Title: Re: DFHack 0.47.04-r5 | 0.47.05-beta1 (dev)
Post by: Uthimienure on March 02, 2021, 10:30:13 pm
Thanks for the quick reply!  Yes, I use d-M to change the circles to marker-only, but indeed it can be a messy proposition.  Thank you for opening a request  :)
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on March 06, 2021, 04:43:19 pm
New release! https://github.com/DFHack/dfhack/releases/tag/0.47.05-r1
Title: Re: DFHack 0.47.05-r1
Post by: HungThir on March 07, 2021, 11:47:39 pm
Quote
lair

This command allows you to mark the map as a monster lair, preventing item scatter on abandon. When invoked as lair reset, it does the opposite.

hmm... is it known whether this works for adventurer camps?
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on March 08, 2021, 12:04:50 am
I think there's a decent chance, but trying it out yourself is the only way to know for sure. (And let us know what you find if you do - it would be good to document, as you've noticed.)
Title: Re: DFHack 0.47.05-r1
Post by: Rumrusher on March 08, 2021, 09:19:21 am
Quote
lair

This command allows you to mark the map as a monster lair, preventing item scatter on abandon. When invoked as lair reset, it does the opposite.

hmm... is it known whether this works for adventurer camps?
from my understanding you can put stuff on tables in adv camps to prevent scatter but also like adv camps don't really scatter stuff... outside of books and artifacts which bypass the item placement unless you place them on a table or pedestal.
Title: Re: DFHack 0.47.05-r1
Post by: ibanix on March 09, 2021, 04:27:51 pm
Does dfhack have a way to unconvict someone of a crime? Or failing that, to force-cancel the job that chains up a dwarf for justice?
Title: Re: DFHack 0.47.05-r1
Post by: Schmaven on March 09, 2021, 04:37:48 pm
Does dfhack have a way to unconvict someone of a crime? Or failing that, to force-cancel the job that chains up a dwarf for justice?

I heard that sending a dwarf on a mission will null their pending sentences.  I have yet to test that, but if true, maybe there's a way to DFHack them into some sort of micro-mission?
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on March 09, 2021, 06:46:41 pm
Worth noting that the "confirm" plugin does add a confirmation dialog when convicting anyone of a crime (as of 0.47.04-r2: https://github.com/DFHack/dfhack/issues/1593).

I'm not aware of an easy way to "un-convict" someone, or of much research being done on the justice system in general, really. It would almost certainly be reversible in theory, but there could be a fair number of references to a dwarf/conviction/etc. that would need to be changed, depending on how DF implements it.
Title: Re: DFHack 0.47.05-r1
Post by: ibanix on March 09, 2021, 07:17:35 pm
Unfortunately, what happened is that I created a Captain of the Guard and didn't realize I had pending punishments. I removed the captain and even tried force-moving him as military via another squad, but he always ends up still trying to chain up some poor dwarf who just didn't meet a silly mandate.
Title: Re: DFHack 0.47.05-r1
Post by: feelotraveller on March 09, 2021, 09:25:56 pm
Is there a way to split stacks with dfhack?  If so how?

(Background: The immediate use would be to split a 70 stack of prepared food so that it can be stored in a container.  It was produced by an unfortunate-fortunate accident involving booze cooking.  In order not to vermin up the tavern it will otherwise spend the next couple of months sitting in the trade depot until, hopefully, a caravan arrives but that solution is far from ideal.)



Thanks Patrik for following up on the diamond issue,  Your efforts are Legend.  :)
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on March 09, 2021, 11:11:42 pm
Is there a way to split stacks with dfhack?  If so how?

(Background: The immediate use would be to split a 70 stack of prepared food so that it can be stored in a container.  It was produced by an unfortunate-fortunate accident involving booze cooking.  In order not to vermin up the tavern it will otherwise spend the next couple of months sitting in the trade depot until, hopefully, a caravan arrives but that solution is far from ideal.)

Did a bit of searching: it looks like DF's base "item" class actually has a splitStack() virtual method (I didn't know this until now), which means that DFHack can call it too. It returns the new item, and reduces the stack size of the existing item. Here (https://github.com/DFHack/dfhack/blob/7ea44010e084c2b4b03d08f4d97324137bbaefd1/plugins/tweak/tweak.cpp#L450-L451) is the only use of it that I found, in C++. It looks like you would want to call categorize() too so that the new item gets inserted into the right vectors under world.items.

In Lua, this would translate as:
Code: [Select]
new_item = item:splitStack(stackSize, true)
if new_item then
    new_item:categorize(true)
end
(I'm not sure what "true" means for either, or whether stackSize is the number of items in the new or the old stack, so you'll probably need to experiment.)
Title: Re: DFHack 0.47.05-r1
Post by: feelotraveller on March 10, 2021, 02:43:42 am
Is there a way to split stacks with dfhack?  If so how?

(Background: The immediate use would be to split a 70 stack of prepared food so that it can be stored in a container.  It was produced by an unfortunate-fortunate accident involving booze cooking.  In order not to vermin up the tavern it will otherwise spend the next couple of months sitting in the trade depot until, hopefully, a caravan arrives but that solution is far from ideal.)

Did a bit of searching: it looks like DF's base "item" class actually has a splitStack() virtual method (I didn't know this until now), which means that DFHack can call it too. It returns the new item, and reduces the stack size of the existing item. Here (https://github.com/DFHack/dfhack/blob/7ea44010e084c2b4b03d08f4d97324137bbaefd1/plugins/tweak/tweak.cpp#L450-L451) is the only use of it that I found, in C++. It looks like you would want to call categorize() too so that the new item gets inserted into the right vectors under world.items.

In Lua, this would translate as:
Code: [Select]
new_item = item:splitStack(stackSize, true)
if new_item then
    new_item:categorize(true)
end
(I'm not sure what "true" means for either, or whether stackSize is the number of items in the new or the old stack, so you'll probably need to experiment.)

Fantastic.  :)  I figured DF was able to do this natively by observing how food tasked for eating was split from the stack before a dwarf collected it, but never would have found the C++ function, or been able to convert it to lua myself.  This is what I came up with:

Spoiler (click to show/hide)

I'm not a coder so I just cobbled together some bits and piece from other scripts until it worked 'well enough' for the case I wanted.  It works okay (as far as I can tell) for food items, and can even multiply raw mussels  ;) but testing other materials shows strange behaviour, bones copy regardless of stack size supplied rather than split (splitstack 5 on cat bone [4] produces another stack of cat bone [4]), and thread and cloth can be 'split' into stacks of multiple items.  No doubt someone who actually knows what they are doing could sanitise it.

To answer your one of your questions, the stackSize variable is the new stack (I'm pretty sure/as far as I can tell) and it inherits the properties of the original stack (e.g. forbidden status).

(It would be relatively easy to limit the behaviour to only splitting by checking if the stack was of sufficient size but sorting out the material variability would be for me much more time than I am willing to dedicate.)
Title: Re: DFHack 0.47.05-r1
Post by: Quietust on March 10, 2021, 09:24:46 am
In Lua, this would translate as:
Code: [Select]
new_item = item:splitStack(stackSize, true)
if new_item then
    new_item:categorize(true)
end
(I'm not sure what "true" means for either, or whether stackSize is the number of items in the new or the old stack, so you'll probably need to experiment.)
If you look in df-structures, the 2nd parameter of "splitStack" is named "preserve_containment", and it controls whether the newly-split stack will be placed in the world in the same location as its parent item (i.e. if you set it to false then you need to explicitly place it in the world, just like the "createitem" plugin does).
Similarly, the paramter for "categorize" is named "in_play", and it controls whether or not the item gets added to world.items.other[IN_PLAY].

As for the "stackSize" parameter, disassembly indicates that it's the number of items you get in the new stack.
Title: Re: DFHack 0.47.05-r1
Post by: HungThir on March 10, 2021, 10:41:19 pm
from my understanding you can put stuff on tables in adv camps to prevent scatter but also like adv camps don't really scatter stuff... outside of books and artifacts which bypass the item placement unless you place them on a table or pedestal.

ohh, that's really helpful, thanks.  i had made a bookcase and placed it in a room (with advfort), but was unable to [p]ut my books into it, so i just dropped them onto the same tile's, and then they were scattered when i came back from a walk.  i usually keep food/items/etc in camps in containers, not just on the floor, and so when those don't scatter i had assumed it was because they were contained, not because only books/artifacts scatter.  so that's one detail now understood.  and it hadn't occurred to me that tables were useful, but i'll start building them from now on.  thanks!
Title: Re: DFHack 0.47.05-r1
Post by: Quantum Drop on March 11, 2021, 05:49:58 am
Having used advfort to build a smelter in adventure mode, I attempted to select the 'melt a metal item' option in the workshop menu. Despite having both fuel (coal) and a metal item (several candy bolts and coins; also tested with an iron sword) to melt, this did not seem to do anything (no reagents-products screen; the menu just vanished after I selected it and pressed enter). Am I doing something wrong here, and if so, does anyone know what to do with it?
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on March 11, 2021, 07:32:31 pm
the menu just vanished after I selected it and pressed enter
Sounds like a possible script error. Is there any red text printed to the DFHack console when this happens? If so, could you paste it here?
Title: Re: DFHack 0.47.05-r1
Post by: HungThir on March 11, 2021, 10:46:58 pm
normally (i.e. fortress mode) when you melt small things whose yield is less than a bar, the fractional bars accumulate internally until you've melted enough small things to produce a whole bar, and then the bar appears.  i bet this is really confusing for advfort...

there's a yield table on the wiki (http://dwarffortresswiki.org/index.php/DF2014:Melt_item#Yield); what happens if you melt one of the objects that's guaranteed to produce at least a whole bar?
Title: Re: DFHack 0.47.05-r1
Post by: Quantum Drop on March 12, 2021, 04:23:52 am
Sounds like a possible script error. Is there any red text printed to the DFHack console when this happens? If so, could you paste it here?
No red text showed up in the console.

However, I will note that when building the smelter, it required me to put in the building material then alt-move into it (causing it to go to the menu where you'd choose the material for building it, now showing as 01. Filled 0/0 as opposed to the earlier 01. Filled 150/1) before it would finish building. This caused the text 'Could not put item:     0       <item_barst: 000002069EEC4640>' to appear in the console, though it was the usual grey rather than red.
Title: Re: DFHack 0.47.05-r1
Post by: HungThir on March 12, 2021, 07:00:13 am
that sounds like what happens when you start building while standing on what will become one of the workshop’s impassable tiles? it can’t finish with you standing there, so you have to move and then continue construction, but since construction was already started the material is both used up and no longer required (thus 0/0)
Title: Re: DFHack 0.47.05-r1
Post by: sheepish_gorilla on March 12, 2021, 12:37:05 pm
Hi guys,
Is this also the place to post feedback on the DFhack documentation?

If so, I'd like to suggest an addition to the tiletypes info:
something I found out recently: 'paint special normal' makes everything into natural stone. It took me a while to find this and I see a lot of questions on the reddit about how to create natural stone. So I think it's useful to add this, in the explanation but also as an example.

for instance:
use [k] to position your cursor
in DFHack:
paint shape wall
paint special normal
run or [enter]

and you have a natural stone wall
Title: Re: DFHack 0.47.05-r1
Post by: sheepish_gorilla on March 12, 2021, 02:09:58 pm
separate post for a question:
Where are the saved stockpile profiles stored? I thought they were linked to saves, but just noticed they're gone after moving my fort to a new starter pac


edit: never mind, I found the folder, how do I delete this bloody post?
Title: Re: DFHack 0.47.05-r1
Post by: Schmaven on March 12, 2021, 03:30:50 pm
separate post for a question:
Where are the saved stockpile profiles stored? I thought they were linked to saves, but just noticed they're gone after moving my fort to a new starter pac


edit: never mind, I found the folder, how do I delete this bloody post?

What folder is it stored in?  If I could just copy it to new versions, that would save me some time re-doing all the same configurations I regularly use.

Also, I don't think you can delete a post.  The forum moderators might be able to though.  There is a little "Report to moderator" hyperlink on the lower right.
Title: Re: DFHack 0.47.05-r1
Post by: feelotraveller on March 13, 2021, 02:11:02 am
Hi guys,
Is this also the place to post feedback on the DFhack documentation?

If so, I'd like to suggest an addition to the tiletypes info:
something I found out recently: 'paint special normal' makes everything into natural stone. It took me a while to find this and I see a lot of questions on the reddit about how to create natural stone. So I think it's useful to add this, in the explanation but also as an example.

for instance:
use [k] to position your cursor
in DFHack:
paint shape wall
paint special normal
run or [enter]

and you have a natural stone wall

It would be good to mention in the documentation that the default setting is 'smooth' and that 'normal' gives rough/natural instead, as that is not obvious at first.

However to make sure a stone wall is created it is also needed to specify:

paint material stone

since otherwise you get a 'wall' tile appropriate to the layer - soil for a soil layer, air for an air layer, semi-molten rock for a magma layer... and only stone in a stone layer.

Title: Re: DFHack 0.47.05-r1
Post by: sheepish_gorilla on March 13, 2021, 12:15:51 pm
What folder is it stored in?  If I could just copy it to new versions, that would save me some time re-doing all the same configurations I regularly use.

Also, I don't think you can delete a post.  The forum moderators might be able to though.  There is a little "Report to moderator" hyperlink on the lower right.

It's in the stocksettings folder in the main DF folder
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on March 13, 2021, 01:09:29 pm
separate post for a question:
Where are the saved stockpile profiles stored? I thought they were linked to saves, but just noticed they're gone after moving my fort to a new starter pac


edit: never mind, I found the folder, how do I delete this bloody post?

It would be better to edit your post to include the answer to your question instead of deleting your question, because someone might have the same question in the future (in fact, Schmaven did have the same question in this case).

For reference: the GUI (specifically, the "gui/stockflow" script, which can be run by pressing "l" with a stockpile selected) should store saved stockpiles in the "stocksettings" folder. The "savestock" command might allow you to store them somewhere else. I'll double-check and add this information to the plugin docs (https://docs.dfhack.org/en/stable/docs/Plugins.html#stockpiles) (the docs for the script (https://docs.dfhack.org/en/stable/docs/_auto/gui.html#gui-stockpiles) already mention this, but it could be clearer).

(ninja'd)
Title: Re: DFHack 0.47.05-r1
Post by: Moeteru on March 20, 2021, 08:25:18 am
I'm very new to dfhack scripting, so apologies if this is obvious and/or already documented somewhere.
I want to read the "divider" attribute of the "emotion_type" enum in df.unit-thoughts.xml (https://github.com/DFHack/df-structures/blob/master/df.unit-thoughts.xml) from within a lua script, but I can't figure out where that metadata is stored in the lua API.

Also, I think I figured out what four of the unnamed parameters in one of the structs are for. Specifically the four int32_t variables in the reflected_on struct df.units.xml#L1970-L1974 (https://github.com/DFHack/df-structures/blob/master/df.units.xml#L1970-L1974). The first two store the old and new values for the facet which was changed (range: 0 to 100), while the second two store the old and new values for the changed value (range: -50 to +50). If either changed_facet or changed_value is -1 then the corresponding old and new variables will be uninitialised.
I posted a script (http://www.bay12forums.com/smf/index.php?topic=177991.msg8261041#msg8261041) over in the stress and psyche thread which may help in verifying this hypothesis. I've tested it on a few random dwarves and the values all seem consistent with what is shown in the thoughts and personality screen.
Title: Re: DFHack 0.47.05-r1
Post by: Putnam on March 20, 2021, 04:46:51 pm
I'm very new to dfhack scripting, so apologies if this is obvious and/or already documented somewhere.
I want to read the "divider" attribute of the "emotion_type" enum in df.unit-thoughts.xml (https://github.com/DFHack/df-structures/blob/master/df.unit-thoughts.xml) from within a lua script, but I can't figure out where that metadata is stored in the lua API.

df.emotion_type.attrs[type].divider
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on March 20, 2021, 07:39:28 pm
Also worth noting that you can index attrs with either the enum item name or value, just like the enum, so
Code: [Select]
[lua]# ~df.emotion_type.attrs[0] == df.emotion_type.attrs.ACCEPTANCE
true

attrs don't appear to be documented at all currently. I'll open an issue for it. (update: https://github.com/DFHack/dfhack/issues/1802)
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on March 20, 2021, 08:17:40 pm
I've noticed you can open and use gui/gm-editor from the in-game command prompt (Ctrl+Shift+P), but for other scripts like gui/liquids and gui/teleport the prompt remains open and won't allow you to move your cursor. Is this fixable?
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on March 20, 2021, 09:13:38 pm
I'm not sure how hard that is to fix, but I didn't know it was an issue, so thanks for reporting it. Reported here, with details on what I think the issue is and some possible fixes: https://github.com/DFHack/dfhack/issues/1803

Not to complain, but I would like to request that bugs get reported in the issue tracker. This definitely includes documentation issues too, as well as feature requests. I've opened several tickets there recently (not only from things reported in this thread!), but I don't always have time to do that, and things can easily be forgotten if they aren't tracked there. From the first post of this thread (which I will shortly update to include more detail):
Please report bugs in the GitHub issue tracker (http://github.com/DFHack/dfhack/issues). (Bugs reported in this thread can be buried sometimes.)
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on March 20, 2021, 09:38:57 pm
Reported here, with details on what I think the issue is and some possible fixes: https://github.com/DFHack/dfhack/issues/1803

It's definitely not a rendering issue. Liquid is placed exactly where the unmovable cursor is.
Title: Re: DFHack 0.47.05-r1
Post by: Moeteru on March 20, 2021, 11:10:12 pm
Thanks a lot for the help.
In return I've been doing a bit more experimentation with emotions and I've made some progress towards figuring out some of the unknown flags (https://github.com/DFHack/df-structures/blob/master/df.units.xml#L1890-L1893):

emotion.flags.unk0 seems to be set to true for thoughts which cause the creature to be "overcome by terror" or other similar extreme states.

emotion.flags.unk1 is related to goals/dreams being fulfilled. I've only seen it set to true on CraftMasterwork thoughts for dwarves who dream of crafting a masterwork or creating a great work of art, and on MasterSkill thoughts for dwarves who dream of mastering a skill. Weirdly it didn't get set for my baron's BecomeNoble thought, despite the fact that it realized his dream of "attaining rank in society". One dwarf had received two MasterSkill thoughts in quick succession and both had this flag set. More science is definitely needed here.
EDIT: It can apparently be set to true for emotions which would satisfy the dwarf's dream even if their dream is already satisfied.

emotion.flags.unk2 is almost always true for the thoughts of citizens and traders, always false for wild and domesticated animals, and varies for sentient invaders. I think it's probably some kind of flag to mark which thoughts have been "processed" by the game engine in some sense. After a dwarf made an artifact I viewed their thoughts without unpausing the game and it showed flags.unk2 to be false for their two most recent thoughts (MadeArtifact and ImproveSkill). Advancing the game by one tick didn't change anything, but after two ticks the ImproveSkill thought got flagged with unk2=true. Another ~20 ticks later the MadeArtifact thought also received the unk2 flag. The same thing happened when looking at a dwarf who had just given birth while the game was still paused, and I also managed to catch a regular "satisfied at work" thought before the unk2 flag got set.

emotion.flags.unk3 causes the emotion to display as "didn't feel anything". I can't actually take credit for this one since PatrikLundell pointed it out earlier in the thread. Interestingly this isn't the only way to get the "didn't feel anything" message. Sometimes the game uses this flag and other times it sets emotion.type to -1.
EDIT: The difference seems to be that this flag only affects thoughts after they leave the present-tense section of the thoughts screen and move into the "within the last season, ..." section.
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on March 21, 2021, 07:54:51 pm
Reported here, with details on what I think the issue is and some possible fixes: https://github.com/DFHack/dfhack/issues/1803

It's definitely not a rendering issue. Liquid is placed exactly where the unmovable cursor is.

Thanks for clarifying, although that doesn't necessarily rule out a rendering issue too. In fact, the fortress screen is actually not re-rendering, at least in the case of gui/liquids - I moved the cursor through Lua, and I was able to paint liquid over a larger area, but the screen didn't update to reflect this until command-prompt was closed. (You can confirm this with ":lua cursor.x = cursor.x + 10") The input issue had a separate cause, though, and the cursor keys just weren't making it to the DF screen to begin with (i.e. that part wasn't a rendering issue).

Here's a preliminary fix: https://github.com/DFHack/dfhack/pull/1804
Tested with gui/liquids, gui/teleport, and "dwarfmonitor stats". Feel free to try it out and let me know if there are still issues with other things. Binaries should be available here (https://buildmaster.lubar.me/applications/17/builds/build?buildId=9807) in under an hour.

Title: Re: DFHack 0.47.05-r1
Post by: lethosor on March 21, 2021, 08:26:15 pm
Thanks a lot for the help.
In return I've been doing a bit more experimentation with emotions and I've made some progress towards figuring out some of the unknown flags (https://github.com/DFHack/df-structures/blob/master/df.units.xml#L1890-L1893):
Thanks! By the way, this is something that can go in the DF-structures issue tracker. Opened here: https://github.com/DFHack/df-structures/issues/424
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on March 24, 2021, 07:41:24 pm
So, how would I go about checking how the tree cutting code works? I have some experience in programming in Assembly language, and I'd like to take a crack at it.

Is it something I should be doing with a special compile of DFHack, or do I just use Visual Studio debugger to attach to the process?
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on March 24, 2021, 08:42:14 pm
I'm not sure how useful the Visual Studio debugger will be, since DF doesn't have symbols. https://docs.dfhack.org/en/latest/docs/Memory-research.html has some information about tools that various people use, but it's still a bit sparse, sadly. In terms of disassembly, I know Quietust uses IDA and BenLubar uses Ghidra. I personally barely do any disassembly at the moment, but they might have more information to add.

I don't know how much debugging of DFHack specifically you'll need to do, but if you need more DFHack symbols, you can get those with a RelWithDebInfo build: https://docs.dfhack.org/en/stable/docs/Compile.html#build-type
Title: Re: DFHack 0.47.05-r1
Post by: Clément on March 25, 2021, 11:17:45 am
I use IDA Freeware, but the freeware version doesn't do debugging, so I have to use GDB separately. I tried ghidra once, but I hated its decompiler, it produces less readable code than the original assembly, maybe it's because I don't know how to use it.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on March 29, 2021, 05:17:06 am
Tried Ghidra the other day, but I couldn't even figure out how to get to its disassembler. IDA was so much easier to get working. I couldn't figure out what to do with the scripts, though. When I try to run them, I get "Function declaration is expected" errors. I've also got to figure out how to check stuff just within DF's executable, since I start out lost in a dll.

Using minGW64 for GDB on Windows:
"Reading symbols from C:\Dwarf Fortress\df_47_05_win\Dwarf Fortress.exe...(no debugging symbols found)...done."
I'll try the RelWithDebInfo build later.
Title: Re: DFHack 0.47.05-r1
Post by: Clément on March 29, 2021, 05:26:08 am
IDA was so much easier to get working. I couldn't figure out what to do with the scripts, though.

I don't know about the .idc scripts, but a useful one is codegen_c_hdr.pl, it will a generate a C header that you can import in IDA.
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on March 29, 2021, 04:11:13 pm
Tried Ghidra the other day, but I couldn't even figure out how to get to its disassembler. IDA was so much easier to get working. I couldn't figure out what to do with the scripts, though. When I try to run them, I get "Function declaration is expected" errors.
What scripts are you running, and do you have more complete errors?
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on March 30, 2021, 04:39:27 am
What scripts are you running, and do you have more complete errors?

For instance, vtable.idc (https://github.com/DFHack/df_misc/blob/master/vtable.idc), having no clue what it actually does.
Code: [Select]
C:\Program Files\IDA Freeware 7.0\idc\DFHack\vtable.idc: C:\Program Files\IDA Freeware 7.0\idc\DFHack\vtable.idc,7: Function declaration is expected
Title: Re: DFHack 0.47.05-r1
Post by: Quietust on March 31, 2021, 09:28:35 am
What scripts are you running, and do you have more complete errors?

For instance, vtable.idc (https://github.com/DFHack/df_misc/blob/master/vtable.idc), having no clue what it actually does.
Code: [Select]
C:\Program Files\IDA Freeware 7.0\idc\DFHack\vtable.idc: C:\Program Files\IDA Freeware 7.0\idc\DFHack\vtable.idc,7: Function declaration is expected
I'm pretty sure that's an old script that requires you to manually specify each individual vtable you want to add - for 64-bit Windows binaries, run "ms_rtti64.idc" and it'll automatically find and name everything.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on March 31, 2021, 10:41:01 am
I'm pretty sure that's an old script that requires you to manually specify each individual vtable you want to add - for 64-bit Windows binaries, run "ms_rtti64.idc" and it'll automatically find and name everything.

Same error:
Quote
C:\Program Files\IDA Freeware 7.0\idc\DFHack\ms_rtti64.idc: C:\Program Files\IDA Freeware 7.0\idc\DFHack\ms_rtti64.idc,7: Function declaration is expected
Title: Re: DFHack 0.47.05-r1
Post by: Fleeting Frames on March 31, 2021, 11:59:02 am
Not sure if I should put this into here or TWBT thread, but...

Noticed few very weird things with my custom TWBT. It's not behaving as it used to.



My question is then: Is it possible that one of the linux updates changed my setup? If not, any other known ways ➂ could happen?
Title: Re: DFHack 0.47.05-r1
Post by: Quietust on March 31, 2021, 06:44:02 pm
Same error:
Quote
C:\Program Files\IDA Freeware 7.0\idc\DFHack\ms_rtti64.idc: C:\Program Files\IDA Freeware 7.0\idc\DFHack\ms_rtti64.idc,7: Function declaration is expected
What exact version of IDA are you running? I've got 7.0.191002 and it runs that script just fine, though I'm not running it from within IDA's "idc" directory - I'm running it directly from where I cloned the df_misc repo, which is on a different drive and is right next to my DFHack and DF directories.

Also, what is the exact file size of the script, and what sort of line endings does it have? Mine is 27,133 bytes and has DOS line endings, but IDA still seems to handle it just fine even when it has UNIX line endings (and is 26,049 bytes long).
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on March 31, 2021, 07:10:32 pm
Not sure if I should put this into here or TWBT thread, but...

Noticed few very weird things with my custom TWBT. It's not behaving as it used to.
...

My question is then: Is it possible that one of the linux updates changed my setup? If not, any other known ways ➂ could happen?
What Linux updates are you referring to? We haven't changed our toolchain or build machine recently, as far as I know (and aren't you running this on an old DF version anyway?), and OS upgrades on your end would be out of our control.

My instinct in this sort of situation is to suspect either a binary produced from unexpected source code or unexpected modifications to source code. Unfortunately, these sorts of questions are hard to answer without version control, so I would definitely recommend using git (or some other version control system) for your development if you aren't already.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on April 01, 2021, 09:44:25 am
What exact version of IDA are you running? I've got 7.0.191002 and it runs that script just fine, though I'm not running it from within IDA's "idc" directory - I'm running it directly from where I cloned the df_misc repo, which is on a different drive and is right next to my DFHack and DF directories.

Also, what is the exact file size of the script, and what sort of line endings does it have? Mine is 27,133 bytes and has DOS line endings, but IDA still seems to handle it just fine even when it has UNIX line endings (and is 26,049 bytes long).

Didn't know I needed the whole df_misc repo. Looks like that fixed it.

Now how do I find my way into DF's game loop?
Title: Re: DFHack 0.47.05-r1
Post by: Fleeting Frames on April 02, 2021, 11:42:15 am
Spoiler: quotes (click to show/hide)

Note: Solved.

Was talking of regular software updates to whole system. I don't really keep track of system updates for, say, past month, though there's probably a way to find the log for them somewhere - but I'm unsure how I could tell something is meaningful. And yeah, I can imagine introducing a bug - ah what the heck, let me recompile with debug setting on, see what I find....

...Well never mind, I find PEBCAK for ➂ >///< - When I was narrowing down what was causing the crash, one of the first things I did was removing init files. These init files which included things like workshop transparency. Which I forgot isn't enabled by default and is required to keep track of workshop building tiles. Oops.

As for crash issue, seems it's been lurking in code since May 2020 going by testing. Pretty rare, but I do know what code I added back then -

Quote
"While your at it, make it not randomly crash :P" - Rose, back then.

- but a better solution was using the tip you provided some months ago to run with -g (https://github.com/DFHack/dfhack/commit/9e935f67f83bc98df8e688689861ac5b45a208c4). Turns out, this time it told me exactly in which function the crash was in.

Anyway, 1/2 turned out to have been caused by rare plant_growth items (a cherry, a desert lime, a bayberry - harvested after falling, perhaps?) had anon_1/print_type set to -1 (which makes them take the withered leaf symbol). Since this was used as an array index that would ordinarily start from zero, well....it'd hit undefined behaviour whenever unit walked on a tile where freshest item was one of those.


Anyway, seems that was it. Ah, DF, will you ever stop providing new things to learn about you?
Title: Re: DFHack 0.47.05-r1
Post by: Buckley on April 06, 2021, 05:25:21 pm
Back to playing DF after a few months.  Sometime in the last few releases of DF Hack someone took time to tweak the exportlegends behavior (I think) to dump files into a file instead of loose.  It also appears they added a message in the console when it's done. "Done exporting."

Thanks.  Little quality of life thing that made me very happy.  I'm often updating my legends file as a play and it's so much easier moving the files to where I keep them now.

 ;)
Title: Re: DFHack 0.47.05-r1
Post by: Moeteru on April 08, 2021, 12:25:44 pm
My most recent fort has suffered from some very severe military equipment corruption (thankfully not the crash-causing kind) which has left half my military unable to dress themselves. The basic problem is that DF will assign the same item to multiple dwarves.

I've made some significant progress towards writing a dfhack script to fix the problem. The script searches through the global list of all items, builds up a list of candidate items sorted by quality, then matches them to the uniforms assigned to each squad position. After overwriting the item assignments in both position.assigned_items and position.uniform, the dwarves happily drop any incorrect items and pick up the new ones. 69 out of 70 military dwarves will now dress themselves properly without any fiddly micromanagement.

The one thing I couldn't figure out is how to deal with different sized armor for my single human squad member. How do I check if a particular piece of armor will fit a particular unit? Toady gives the numerical constraints in this FOTF reply (http://www.bay12forums.com/smf/index.php?topic=140544.msg6843526#msg6843526), but I can't find where those size values are stored in the item_armorst (or similar) structures.
Title: Re: DFHack 0.47.05-r1
Post by: Atomic Chicken on April 08, 2021, 01:24:03 pm
The one thing I couldn't figure out is how to deal with different sized armor for my single human squad member. How do I check if a particular piece of armor will fit a particular unit? Toady gives the numerical constraints in this FOTF reply (http://www.bay12forums.com/smf/index.php?topic=140544.msg6843526#msg6843526), but I can't find where those size values are stored in the item_armorst (or similar) structures.

The maker_race (https://github.com/DFHack/df-structures/blob/0c640542c43256aa7c245f4a0d0c7918c4100a73/df.items.xml#L718) value of an item marks it as being sized for a particular creature race. This size is numerically the adultsize (https://github.com/DFHack/df-structures/blob/0c640542c43256aa7c245f4a0d0c7918c4100a73/df.creature-raws.xml#L1218) of the race in question. In other words:

Code: [Select]
local size = df.creature_raw.find(item.maker_race).adultsize
(Confirmed this by spawning a dragon equipped with a helm in arena mode, taking control of a dwarf, and viewing the helm before and after changing the adultsize of dragons to that of dwarves; the helm lost its "large" descriptor after the change).
Title: Re: DFHack 0.47.05-r1
Post by: Moeteru on April 08, 2021, 08:18:22 pm
Awesome, thanks a lot.
My code is still rather brittle and probably doesn't handle edge-cases properly, but it seems to work. For the first time in a very long time I have a fully equipped military even down to the correct flasks and backpacks.
Here it is in case anyone is curious. I wouldn't recommend running it without making a full save backup first. I really can't guarantee that it won't cause corruption. https://ghostbin.co/paste/qwph54 (https://ghostbin.co/paste/qwph54)
Also there are a bunch of TODO notes for functionality which I don't personally need. Things like quivers, the partial match setting, individual choice weapons, etc.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on April 11, 2021, 12:56:56 am
Do we know how to make an item fall? Writing a script to deal with floating webs.

Edit: Looks like it involves creating a projectile entry. Might be simpler just to erase them, although I think Rumrusher has a script for launching stuff.
Edit II: Looks like "dfhack.items.makeProjectile" does what I need.
Title: Re: DFHack 0.47.05-r1
Post by: vettlingr on April 12, 2021, 02:06:54 pm
I have been using 3dveins for a long time, it being my favourite plugin.
It has gotten so bad that I can't almost bother playing on a map without it. I love Geology, and DF is one of those games which has great potential in representing geology in an interesting way, that is why I wish to address some hickups with 3dveins, mostly regarding its stability.

Usually, several parameters dictate if 3dveins will be able to complete or not, if a faulty parameter is detected, the plugin terminates, such as with the code below.
Foward Vein Placement:
Spoiler (click to show/hide)
I am wondering what this does? is it that the vein extends or originates in tiles outside of the map?

If I for example add the tag in bold, 3dveins will terminate pre completion. Removing [SOIL] works, but then the layer will act as a rock in purposes for digging and will produce boulders.
Code: [Select]
[INORGANIC:CLAY]
[USE_MATERIAL_TEMPLATE:SOIL_TEMPLATE]
[STATE_NAME_ADJ:ALL_SOLID:clay][DISPLAY_COLOR:7:7:0][TILE:23]
[SOIL][b][ENVIRONMENT:SOIL:CLUSTER:100][/b]
[SOLID_DENSITY:1210] SCS = 20/60/20
[MATERIAL_REACTION_PRODUCT:FIRED_MAT:INORGANIC:CERAMIC_EARTHENWARE]
[DISPLAY_UNGLAZED]

3dveins will not run since Inorganic->Soil is not viable for veins(and clusters) according to this line. Is there a way to circumvent this. How about just removing the line, would that work?

Code: [Select]
if (!isStoneInorganic(key.first))
            {
                out.printerr(
                    "Invalid vein material: %s\n",
                    MaterialInfo(0, key.first).getToken().c_str()
                );

                return false;
            }

Lastly, when using a map with extreme mineral frequency, the "Parent vein not placed" usually terminates 3dveins.
I'm not familiar with the -> markers, but I believe that it says if QUEUE[j] has parent and the QUEUE[j] parent is not placed.
Code: [Select]
for (size_t j = 0; j < queue.size(); j++)
    {
        if (queue[j]->parent && !queue[j]->parent->placed)
        {
            out.printerr(
                "\nParent vein not placed for %s %s.\n",
                MaterialInfo(0,queue[j]->vein.first).getToken().c_str(),
                ENUM_KEY_STR(inclusion_type, queue[j]->vein.second).c_str()
            );

            return false;
        }
[...]
I would like to know what makes a parent vein not placed? I'm guessing it is somewhere in void "VeinExtent::place_tiles()"
Title: Re: DFHack 0.47.05-r1
Post by: myk on April 12, 2021, 04:14:44 pm
I have no familiarity with the 3dveins plugin, but I looked through the code for a few minutes and I think I can answer some of your questions.

Parentage: some veins appear within other, larger veins. The parent of a vein is the vein that encompasses it. Veins that are just surrounded by basic layer material don't have a parent (that is, the parent field is set to -1).

Forward vein placement: parents have to be defined before they are referenced as some child vein's parent. if the veins are declared out of order in in vein_nested_in array, you get this error.

Soil not allowed as a vein material: I'm not sure if this should be circumvented. changelayer has a warning (https://docs.dfhack.org/en/latest/docs/Plugins.html?#changelayer) about not trying to make non-soil layer rock into soil. DF might not be able to handle it properly.

Parent vein not placed: There's a lot of logic here that I haven't fully traced out, but in absence of another error message that tells you something more specific, it appears that a vein can fail to be placed if the allowed global tile count for the vein's material has fallen to 0.
Title: Re: DFHack 0.47.05-r1
Post by: vettlingr on April 13, 2021, 01:21:28 pm
I would like to modify 3dveins to be more reliable when redrawing 500+ veins. Usually it terminates after not being able to place "CLUSTER_ONE" in absent parent, even though these are least common in the raws, but terminations due to *Parent not being placed due to "x" "CLUSTER_SMALL"* is also common, though less so.

I could add some printing out variables to the code to see what is going on. I'm guessing it is trying to place the certain Mineral before its parent has been placed. Rather than the parent having run out of "bricks". A possible fix if this is the case is to sort the veins better. Either that or put the parentless mineral in the back of the queue and continue.
Title: Re: DFHack 0.47.05-r1
Post by: PatrikLundell on April 13, 2021, 04:30:40 pm
@vettlingr: Note that some minerals can occur within different environments, so if you want to make sure all the preconditions have been placed before you try to place those, you ought to go through all the possible parents, not only the first one. An alternative would be to generate each level from the outside inwards, i.e. placing e.g. a small cluster within a large cluster is made after the parent large cluster has been placed, while placing the same mineral within a vein would be done after that vein had been placed, and not really care whether the inclusions happen to be the same mineral or not.
I would expect e.g. blue diamonds to fail to find any potential hosts reasonably often, though, as they only occur in faint yellow small clusters (if I remember the type correctly), and if all the small clusters to generate happened to be of other types of small clusters (or the kimberlite veins the small clusters would have been potential candidates for didn't win a place in the race because all veins were of different minerals), there would be zero available places for them.

I haven't looked at 3dvein, though, so the above may be irrelevant.
Title: Re: DFHack 0.47.05-r1
Post by: vettlingr on April 13, 2021, 04:40:59 pm
Blue/green/black Diamonds are notorious in my testing for terminating 3dveins or any vein which is at least 3 parents deep. CLUSTER_ONE in CLUSTER_SMALL in VEIN in CLUSTER in LAYER.

Wether it is possible to sort it depends on if it is possible to extract it's 3rd in line parent and treat all subseries of parents as the minerals original parents for the purposes of sorting. If not, putting it in the back of the queue could solve it (?)

Best solution would be placing all clusters first, then veins, then small clusters, then single clusters.
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on April 13, 2021, 05:01:18 pm
Yeah, I think some sort of sorting improvements might help, based on what I'm reading here. Do you have a set of worldgen/embark parameters that tends to reproduce this? e.g. does it tend to happen more often on larger/smaller embarks, with more/fewer minerals at worldgen time, etc.?
Title: Re: DFHack 0.47.05-r1
Post by: Warmist on April 14, 2021, 12:55:26 am
My 2 cents: while i love 3dveins, i would love to have more variety of vein generations models. One of the top of my head and easy to implement: biased random walk. You could set a cluster center and random walk with some "gravity" towards center (or if you want a tighter cluster, some spring force).

As for the issues here: easiest way to 'fix' them would be to place everything you can and then report what you couldn't. Imho few lost diamonds are not that big of an issue.
Title: Re: DFHack 0.47.05-r1
Post by: vettlingr on April 14, 2021, 04:41:29 am
Yeah, I think some sort of sorting improvements might help, based on what I'm reading here. Do you have a set of worldgen/embark parameters that tends to reproduce this? e.g. does it tend to happen more often on larger/smaller embarks, with more/fewer minerals at worldgen time, etc.?
Usually the problems stated arise when playing on a world with Minerals:Everywhere. In vanilla DF, it is usually Anhydrite that is the main culprit, since it's a CLUSTER_ONE in Satinspar (CLUSTER_SMALL) in Gypsum (CLUSTER). If that doesn't terminate 3dveins, Forward vein in "" usually does.

With Minerals:everywhere, 3dveins will only work around 1/8 times it is run

Embark size does not seem to matter, since any embark that uses the same biome will have the same problem.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on April 14, 2021, 01:05:51 pm
Made a silly script that takes vermin remains in your fort and teleports them as a projectile to hit the cursor, destroying any tree there (like a ballista bolt):
Code: (destroy-tree.lua) [Select]
--Yeet vermin remains to destroy trees
--keybinding add Ctrl-X destroy-tree

function destroy_tree()
if not dfhack.isMapLoaded() then
qerror("Error: Map not loaded!")
end

local x,y,z = pos2xyz(df.global.cursor)
if x == nil or x < 0 then
qerror("Error: Cursor not active!")
end

for i, item in ipairs(df.global.world.items.other.REMAINS) do
if item.flags.on_ground and not item.flags.in_job then
local proj = dfhack.items.makeProjectile(item)
proj.flags.no_impact_destroy = true
proj.flags.piercing = true
proj.origin_pos.x, proj.origin_pos.y, proj.origin_pos.z = x,y-1,z
proj.target_pos.x, proj.target_pos.y, proj.target_pos.z = x,y,z
proj.cur_pos.x, proj.cur_pos.y, proj.cur_pos.z = x,y-1,z
proj.prev_pos.x, proj.prev_pos.y, proj.prev_pos.z = x,y-1,z
proj.fall_threshold = 1
item.flags.forbid = true
return
end
end
print("No available vermin remains found!")
end

destroy_tree()

Maybe I'll have it create its own projectiles out of some material that evaporates shortly after. Also have it automatically deploy them against every tree chopping designation instead of using the cursor.

Of interest to note is that if "no_impact_destroy" is false, the remains can break and litter the ground with purple "broken arrow" tiles.

I still haven't made any progress on figuring out how to reverse engineer the tree chopping code.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on April 15, 2021, 04:48:45 pm
Could "unk_v40_1" on projectiles be related to abilities/powers? It's set to 4885 for magma crab globs, 7035 for intelligent undead icicles, and -1 for bolts fired from a crossbow. Falling objects seem to have it set to really high garbage values. Could be the "parabolic" or "unk9" flag that has the game ignore that.

Edit: I don't see any relevant arrays going that high, though. Any chance they're flags?
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on April 15, 2021, 06:51:32 pm
It would be an unusually large number of flags (and pattern of set flags) compared to other bitfields, so my guess would be no. -1 would also have every bit set, which is usually an indication that the field is a number, not a bitfield.
Code: [Select]
>>> bin(7035)
'0b1101101111011'
>>> bin(4885)
'0b1001100010101'

From https://github.com/DFHack/df-structures/blob/f7118215ec98ef754579864d92353c59588ba24a/df.projectile.xml#L57, apparently this field is uninitialized, so you might just be seeing garbage data sometimes (or always).
Title: Re: DFHack 0.47.05-r1
Post by: vettlingr on April 21, 2021, 06:53:27 am
I've been looking more into 3dveins. A long standing Issue has been that the plugin has been unable to run if the map contains lake or sea tiles. Giving the result "Discontinuous layer 1 at *water body coordinates*". If this also applies to glaciers, I do not know.

Code: [Select]
           else
            {
                if (z != min_level[idx]-1 && min_level[idx] <= top_solid)
                {
                    out.printerr(
                        "Discontinuous layer %d at (%d,%d,%d).\n",
                        layer->index, x+column.x*16, y+column.y*16, z
                    );
                    return false;
                }

                min_level[idx] = z;
            }
        }
    }

A fix could be to add lake and ocean sediments to this list:

Code: [Select]
static bool isTransientMaterial(df::tiletype tile)
{
    using namespace df::enums::tiletype_material;

    switch (tileMaterial(tile))
    {
        case AIR:
        case LAVA_STONE:
        case PLANT:
        case ROOT:
        case TREE:
        case MUSHROOM:
            return true;

        default:
            return false;
    }
}

To do that however, I need to figure out the correct tag or token.
Title: Re: DFHack 0.47.05-r1
Post by: PatrikLundell on April 21, 2021, 11:39:33 am
your second snippet should probably exclude frozen liquid (water) as well to deal with glaciers.

Could your problem be caused by the weird thing Prospector detects for some lake and ocean tiles where the soil layer is absent, and so the geo biome gets shifted as if the soil layers had been eroded away (and how does the code deal with "normal" erosion of soil at high elevations)?
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on April 22, 2021, 04:12:38 am
Could somebody write a step-by-step guide on how to reverse engineer some DF code using IDA or Ghidra?

I've been trying with IDA and haven't really even been able to get started. Some questions:
1. Should I start DF with IDA, or attach to an existing process? With or without DFHack?
2. When should I run a script (e.g., ms_rtti64.idc,) and how will I know if it worked?
3. How do I constrain myself to the DF segment instead of being lost in dll's?
(I tried setting it to hardware break upon entering the DF module, but this results in constant exceptions, which eventually crashes the game. Just trying to step through code to reach it also results in this eventually.)

Should I open an issue asking for info to be added to the docs (Memory-research.html)?
Title: Re: DFHack 0.47.05-r1
Post by: Clément on April 22, 2021, 04:36:29 am
1. Start with the debugger or attach later, whatever works for you. With DFHack and its debug info.
2. I don't know about the rtti scripts, but you should run codegen_c_hdr.pl from df_misc using the codegen from the matching DFHack version, import the resulting header in IDA.
3. Depends on what you are looking for, I've used a lot of watchpoints as starting points for reversing since the data is the most well documented part. Alternatively, you could start with a breakpoint on a known function (exported symbol or virtual method).
Title: Re: DFHack 0.47.05-r1
Post by: Rumrusher on April 22, 2021, 10:52:33 am
ok so ended up writing a script for checking on armies that roam the world map ... through nicknaming a unit and tracking the army through that.
this possibly means in adventure mode one could say edit the army controller and mess with the army orders.
and probably set up visitors that could show up to the fort or create sieges from guards or roaming locals.
Code: (getArmyAtName) [Select]
function getArmyAtName()
for k,v in pairs(df.global.world.nemesis.all) do
if v.figure.name.nickname=='DFCAT' then
print(k)
local Cat=df.global.world.armies.all
for k1,v1 in pairs(Cat) do
if v1.members==nil then break else
for Del,ete in pairs(v1.members) do
if ete.nemesis_id==v.id then
print(k1)
end
end
end
end
end
end
end
getArmyAtName()

hopefully I can use this as a stepping stone for figuring out how to do fort mode raids in adventure mode...

edit: ok so made two scripts that use this one
a recruit script that grabs anyone that has a nemesis to join the army in waiting
Code: (NemArm-Recruit) [Select]
function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end
function getItemAtKPos(x,y,z) -- gets the item index @ x,y,z coord
--local x,y,z=getxyz() --get 'X' coords
local vector=df.global.world.item.all -- load all items
local kickpos=df.global.world.units.active[0].pos
for i = 0, #vector-1 do -- look into all items offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==kickpos.x and cy==kickpos.y and cz==kickpos.z then --compare them
return vector[i] --return index
end
end
--print("item not found!")
return nil

end
function getCreatureAtPos(x,y,z) -- gets the creature index @ x,y,z coord
--local x,y,z=getxyz() --get 'X' coords
local vector=df.global.world.units.all -- load all creatures
for i = 0, #vector-1 do -- look into all creatures offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==x and cy==y and cz==z then --compare them
return vector[i] --return index
end
end
--print("Creature not found!")
return nil

end

function getArmyAtName()
for k,v in pairs(df.global.world.nemesis.all) do
if v.figure.name.nickname=='DFCAT' then
print("Nem",k)
local Cat=df.global.world.armies.all
for k1,v1 in pairs(Cat) do
if v1.members==nil then break else
for Del,ete in pairs(v1.members) do
if ete.nemesis_id==v.id then
print("Army",k1)
return k1
end
end
end
end
end
end
end
 local horse=getCreatureAtPos(getxyz())
 local nem=df.global.world.history.figures[horse.hist_figure_id].nemesis_id --dfhack.units.getNemesis(horse)
 local NeArmy=getArmyAtName()
  df.global.world.armies.all[NeArmy].members:insert("#",{new=true,nemesis_id=nem,})

and here's the script for moving the station army around which works wonders for nicknaming a hostile bandit member and luring the bandits into a goblin patrol
Code: (NemArm-Station) [Select]
function getArmyAtName()
for k,v in pairs(df.global.world.nemesis.all) do
if v.figure.name.nickname=='DFCAT' then
print("Nem",k)
local Cat=df.global.world.armies.all
for k1,v1 in pairs(Cat) do
if v1.members==nil then break else
for Del,ete in pairs(v1.members) do
if ete.nemesis_id==v.id then
print("Army",k1)
return k1
end
end
end
end
end
end
end


local Ned=getArmyAtName()
for k,v in pairs(df.global.world.armies.all) do
if v.flags[0]== true  then
print("ArmyOrders Station"," Moving Stationed group To Adv Position")
print("id",k,"X position",(v.pos.x),"y position",(v.pos.y))
df.global.world.armies.all[Ned].controller.pos_x=v.pos.x
df.global.world.armies.all[Ned].controller.pos_y=v.pos.y

end
end
well I could somewhat cross off controlling armies on the list of stuff I wanted to do in DF through DFhack.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on April 26, 2021, 10:39:04 am
1. Start with the debugger or attach later, whatever works for you. With DFHack and its debug info.
2. I don't know about the rtti scripts, but you should run codegen_c_hdr.pl from df_misc using the codegen from the matching DFHack version, import the resulting header in IDA.
3. Depends on what you are looking for, I've used a lot of watchpoints as starting points for reversing since the data is the most well documented part. Alternatively, you could start with a breakpoint on a known function (exported symbol or virtual method).

Finally got DFHack with debug info built after finding the right packages to install for VS2017 and deleting VS2015 (which I couldn't find packages for and was messing up VS2017.)

I ran the script on library\include\df\codegen.out.xml to produce codegen.h. Then I attached to the DF process in IDA using "Local Windows debugger", set the compiler to "Visual C++" with the default settings, and did "Load file -> Parse C header file..." and selected codegen.h. Output says "codegen.h: successfully compiled". Is that all I'm supposed to do?

Not sure how to find the data or functions to put the breakpoints on. I found the address of a tiletype vector using the lua interpreter, and set a breakpoint and watch there in IDA. Each tiletype seems to be 2 bytes, and I found the lines:
Code: [Select]
db 5Dh ; ]
db 0h
Representing a tree trunk tiletype (93) in the tile of a tree one tick away from being chopped down. I allow the program to resume (so it responds,) then pass one tick (using .) and quickly suspend execution before the tree is cut. I enable the breakpoint and resume execution. Unfortunately, it stops some time after the breakpoint, which doesn't get me the instructions that accessed the data. I tried stepping further through the code, but it doesn't reach the check again in a human time frame. After several continues, the data eventually changes to:
Code: [Select]
db 4Eh ; N
db 1h
And the tree is chopped. The tiletype should be 335 for stone floor. I assume 4E 01 represents that in the proper order and endianness?

This at least gets me into DF's instructions, but not where I want. The addresses of the vectors also change each time DF is loaded, and loading the saved memory in IDA doesn't give you a live program, AFAIK.
Title: Re: DFHack 0.47.05-r1
Post by: Warmist on April 26, 2021, 11:22:52 am
Huh... Last time i tried the data breakpoints worked okay. Though yeah the randomization is a pain. Last time i did this i went the other way around. From the i think "logic" vmethod of main screen search for anything that acceses the data (in my case it was world->sth->sth) and it was only a few hits. Though i imagine finding what modifies tiles would have a lot of hits...
Title: Re: DFHack 0.47.05-r1
Post by: Clément on April 26, 2021, 02:53:39 pm
I ran the script on library\include\df\codegen.out.xml to produce codegen.h. Then I attached to the DF process in IDA using "Local Windows debugger", set the compiler to "Visual C++" with the default settings, and did "Load file -> Parse C header file..." and selected codegen.h. Output says "codegen.h: successfully compiled". Is that all I'm supposed to do?

From memory (I cannot check right now), you should now be able to add df structures in your structure window or whatever it is called. You can then use the types to annotate the disassembly code, or memory regions.

Unfortunately, it stops some time after the breakpoint, which doesn't get me the instructions that accessed the data. I tried stepping further through the code, but it doesn't reach the check again in a human time frame.
Watchpoints are triggered when the memory is accessed, the instruction pointer has already been changed and it points to the next instruction. The instruction changing the value should be the one just before where you stopped.

After several continues, the data eventually changes to:
Code: [Select]
db 4Eh ; N
db 1h
And the tree is chopped. The tiletype should be 335 for stone floor. I assume 4E 01 represents that in the proper order and endianness?
x86 is little-endian, so the first byte is the LSB. But 0x14e is 334, not 335. You should be able to tell IDA to view this part of memory as a 16 bits word (or better: use the type imported from codegen.h), then endianness will no longer be an issue.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on April 28, 2021, 07:48:59 pm
[snip]

Edit: Is IDA treating DF as a 32-bit program? All the data types are half the size they should be, and "db" is the same size as "dw".

How do I deal with something like:
Code: [Select]
Dwarf_Fortress.exe:00007FF7B6D20840 db  40h ; @
Dwarf_Fortress.exe:00007FF7B6D20841 db    0
Dwarf_Fortress.exe:00007FF7B6D20842 db  15h
Dwarf_Fortress.exe:00007FF7B6D20843 db 0DCh ; Ü
Dwarf_Fortress.exe:00007FF7B6D20844 db  45h ; E
Dwarf_Fortress.exe:00007FF7B6D20845 db    0
Dwarf_Fortress.exe:00007FF7B6D20846 db    0
Dwarf_Fortress.exe:00007FF7B6D20847 db    0
Which is a 64-bit (8 byte) pointer to the memory address "00000045DC150040"? None of the options I've looked at made it more readable.

Haven't had any luck making sense of vectors, either, such as "world.T_plants". I get this:
Code: [Select]
Dwarf_Fortress.exe:00007FF7B6D20840 world::T_plants <<0BAC86020h, 8Bh, 0BAC9D5C8h>, <8Bh, 0BAC9DB70h, 8Bh>,\
Dwarf_Fortress.exe:00007FF7B6D20840                  <0C52BD900h, 8Bh, 0C52C8EA0h>, <8Bh, 0C52CD5E0h, 8Bh>,\
Dwarf_Fortress.exe:00007FF7B6D20840                  <0C25E17B0h, 8Bh, 0C25E2018h>, <8Bh, 0C25E2190h, 8Bh>>
None of this seems to lead to the address in memory (0000008BB9A80F70) that contains the plant at index 0, nor an area in memory I found through searching (0000008BA0AFD038) that has a pointer to that address. (I didn't find any pointers to that pointer through searching.)


I also can't figure out an easy way to jump to addresses in the hex-editor or stack views, which is a bit annoying. I can only sync them with RIP, etc., or bring the disassembly view to them.
Title: Re: DFHack 0.47.05-r1
Post by: Clément on April 29, 2021, 03:49:56 am
Edit: Is IDA treating DF as a 32-bit program? All the data types are half the size they should be, and "db" is the same size as "dw".

I've just realized there was an update to IDA Freeware (since one and a half year ago, I'm slow). The old version I had was 64 bits only, so there was no possible confusion. But now it can be used for 32 bits too. That's why you were able to use a debugger too!

dw is 16 bits and not enough for a pointer: b = byte (8 bits), w = word (16 bits), d = double word (32 bits), q = quad word (64 bits).

Title: Re: DFHack 0.47.05-r1
Post by: Bumber on April 30, 2021, 05:05:49 am
dw is 16 bits and not enough for a pointer: b = byte (8 bits), w = word (16 bits), d = double word (32 bits), q = quad word (64 bits).

I think I found the issue. There's a bug in the right-click menu, where choosing "quad word" results in a 32-bit floating point.

The buttons in from "Options -> Setup data types..." work as intended. I enabled "float" for the right-click menu and that results in a quad word.
Title: Re: DFHack 0.47.05-r1
Post by: jecowa on April 30, 2021, 10:33:35 pm
Issue report: "gui/unit-info-viewer" gives Strength:Agility values instead of the size in cubic deciliters.
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on May 02, 2021, 03:32:21 pm
Ah, thanks for tracking that down. Sounds like something that confused me when I saw it, but I don't use the script often and didn't realize it was a bug.

This is something that is best reported in the issue tracker. I opened a report here: https://github.com/DFHack/dfhack/issues/1844
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on May 05, 2021, 04:07:14 pm
Alternatively, you could start with a breakpoint on a known function (exported symbol or virtual method).

How do you find known functions? I don't see anything under IDA's function list. Are they listed with the structs? Are they at known fixed addresses?
Title: Re: DFHack 0.47.05-r1
Post by: Clément on May 05, 2021, 05:46:08 pm
vtable addresses are in symbols.xml. I guess the rtti scripts are supposed to find them too, but I've never used them.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on May 06, 2021, 06:28:12 pm
vtable addresses are in symbols.xml. I guess the rtti scripts are supposed to find them too, but I've never used them.

Not sure how to use that to locate the right addresses in IDA. I tried adding a Win64 hex value in symbols.xml to the start address of the DF module, but that doesn't seem to lead to the right place. Is there a way to automatically load that data into the disassembler?

I just noticed that running DF from IDA loads a lot more info than attaching to process. Not sure if it's useful info for DF, though, and it assigns certain data as XMM instead of the quad words I need.
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on May 06, 2021, 11:03:32 pm
My guess is that Clément was referring to one of the ms_rtti*.idc scripts from df_misc (https://github.com/DFHack/df_misc) (but I don't know exactly which one - perhaps ms_rtti64.idc for 64-bit DF?)
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on May 07, 2021, 01:37:06 am
My guess is that Clément was referring to one of the ms_rtti*.idc scripts from df_misc (https://github.com/DFHack/df_misc) (but I don't know exactly which one - perhaps ms_rtti64.idc for 64-bit DF?)

Yeah, but I'm not sure what running it actually accomplishes.
Title: Re: DFHack 0.47.05-r1
Post by: Quietust on May 07, 2021, 10:21:34 am
The primary purpose of the "ms_rtti64" script is to apply names to all of the vtable objects in the disassembly, so that if you find code that creates a virtual object you'll be able to immediately recognize what it is.

In other words, it'll change this:
Code: [Select]
.text:00000001407ED382                 lea     rax, off_140F20958into this:
Code: [Select]
.text:00000001407ED382                 lea     rax, ??_7item_chainst@@6B@ ; const item_chainst::`vftable'
The most important thing to do, after running codegen_c_hdr.pl and importing the resulting header file, is to run ruby.exe dump_df_globals.rb --idc "..\path\to\Dwarf Fortress.exe" and then copy all of the MakeName(...) calls and paste them into the IDA "Execute Script" window (File -> Script Command, or Shift+F2). Once you do that (and press "Run"), all of the global variables will be named and the various global structures will be instantiated in-place, so when you look through the code you'll be able to see all of the names instead of just meaningless numbers.

In other words, it'll change this:
Code: [Select]
.text:000000014042E4B8                 movzx   eax, cs:byte_141699288
.text:000000014042E4BF                 xor     r12d, r12d
.text:000000014042E4C2                 cmp     cs:byte_14167EC63, r12b
.text:000000014042E4C9                 movzx   ecx, cs:word_141C3D260
.text:000000014042E4D0                 cmovnz  eax, r12d
.text:000000014042E4D4                 mov     cs:byte_141699288, al
.text:000000014042E4DA                 test    cx, cx
.text:000000014042E4DD                 jz      short loc_14042E502
.text:000000014042E4DF                 cmp     cx, di
.text:000000014042E4E2                 jnz     loc_14042F407
.text:000000014042E4E8                 cmp     cs:byte_141C3D368, r12b
.text:000000014042E4EF                 jnz     loc_14042F407
.text:000000014042E4F5                 cmp     cs:byte_141C3D360, r12b
.text:000000014042E4FC                 jnz     loc_14042F407
into this:
Code: [Select]
.text:000000014042E4B8                 movzx   eax, cs:_pause_state
.text:000000014042E4BF                 xor     r12d, r12d
.text:000000014042E4C2                 cmp     cs:_debug_nopause, r12b
.text:000000014042E4C9                 movzx   ecx, cs:_ui.main.mode
.text:000000014042E4D0                 cmovnz  eax, r12d
.text:000000014042E4D4                 mov     cs:_pause_state, al
.text:000000014042E4DA                 test    cx, cx
.text:000000014042E4DD                 jz      short loc_14042E502
.text:000000014042E4DF                 cmp     cx, di
.text:000000014042E4E2                 jnz     loc_14042F407
.text:000000014042E4E8                 cmp     cs:_ui.squads.in_kill_order, r12b
.text:000000014042E4EF                 jnz     loc_14042F407
.text:000000014042E4F5                 cmp     cs:_ui.squads.in_move_order, r12b
.text:000000014042E4FC                 jnz     loc_14042F407
Title: Re: DFHack 0.47.05-r1
Post by: Garfunkel on May 08, 2021, 09:13:37 am
How do I run the script to remove uninteresting dead units from mut 'u'nits list?
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on May 08, 2021, 10:58:22 am
How do I run the script to remove uninteresting dead units from mut 'u'nits list?
If you're asking for the name of the script, it's "fix/dead-units (https://docs.dfhack.org/en/stable/docs/_auto/fix.html#fix-dead-units)". To run it, just enter that in the DFHack console.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on May 08, 2021, 09:00:29 pm
paste them into the IDA "Execute Script" window (File -> Script Command, or Shift+F2). Once you do that (and press "Run"), all of the global variables will be named and the various global structures will be instantiated in-place, so when you look through the code you'll be able to see all of the names instead of just meaningless numbers.

There's no indication that the Run button has done anything after I press it. Script Command window doesn't close, no log output. Is this expected?

Is there an easy place to look to verify if it worked? Skimming through, I don't see much readable labeling besides the strings that are loaded just by loading DF with IDA (e.g., aDwarfMode ; "Dwarf mode") and non-DF stuff like "basic_ostream" and "cs:memmove".

There's no "_pause_state" in the names window, so I think that's a good indicator it didn't work. There are no names at all when attaching to DF (rather than running it from IDA) and the script is used.





That range of addresses doesn't exist in IDA, with nothing visible between the end of "debug001" and the beginning of "debug038":
Code: [Select]
debug001:000000007FFE0FFF debug001 ends
debug001:000000007FFE0FFF
debug038:0000007700000000 ; ===========================================================================
Title: Re: DFHack 0.47.05-r1
Post by: Garfunkel on May 09, 2021, 05:41:31 am
How do I run the script to remove uninteresting dead units from mut 'u'nits list?
If you're asking for the name of the script, it's "fix/dead-units (https://docs.dfhack.org/en/stable/docs/_auto/fix.html#fix-dead-units)". To run it, just enter that in the DFHack console.
Thanks a lot, that worked!
Title: Re: DFHack 0.47.05-r1
Post by: Quietust on May 09, 2021, 12:59:05 pm




That range of addresses doesn't exist in IDA, with nothing visible between the end of "debug001" and the beginning of "debug038":
Code: [Select]
debug001:000000007FFE0FFF debug001 ends
debug001:000000007FFE0FFF
debug038:0000007700000000 ; ===========================================================================
I suppose I should've mentioned beforehand: if you want those scripts to work, you must not attach to an existing process (as you would with a debugger). Instead, you need to run IDA, go to File -> Open, select the EXE file, let it finish analyzing it, and then run those scripts. You can attach to a running EXE afterwards if you want, but I would strongly recommend saving before doing so (and not saving it afterwards).
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on May 11, 2021, 04:55:22 pm
Okay, I've got that working, it seems.

Watch points don't seem to interrupt when their value is changed. They don't even show the change until DF is interrupted. I set a hardware breakpoint for when a value of interest in the plants.all vector is written to, but it seems to interrupt even when just read. This is unfortunate because it looks like the vector is iterated even while the game is paused.

Another annoyance is that while I can turn the whole vector into qwords by using the array option in the right-click menu, they're all treated as one address when I do. Is there a better way to handle things than searching for the sequence of bytes that contain the address of the plant struct of interest, and turning just that into a qword?

This function seems to be of interest, but it doesn't use anything that's named:
Spoiler (click to show/hide)

The code under loc_140CF1080 is what's iterating and triggering the interrupts.
Title: Re: DFHack 0.47.05-r1
Post by: Quietust on May 12, 2021, 07:33:07 am
This function seems to be of interest, but it doesn't use anything that's named:
If you don't see any named addresses then you missed a step somewhere, because there should be 3 named addresses in there:
Code: [Select]
.text:0000000140CF1009                 cmp     eax, cs:_world.map.x_count
.text:0000000140CF100F                 jge     loc_140CF11A2
.text:0000000140CF1015                 test    cx, cx
.text:0000000140CF1018                 js      loc_140CF11A2
.text:0000000140CF101E                 movsx   eax, cx
.text:0000000140CF1021                 cmp     eax, cs:_world.map.y_count
.text:0000000140CF1027                 jge     loc_140CF11A2
.text:0000000140CF102D                 mov     r8, cs:_world.map.column_index
Just below that, it's necessary to manually annotate various structure offsets:
1. Select the Structures window by pressing Shift+F9
2. Press the Insert key, click "Add standard structure", and locate the structure you want to add
3. In the main disassembly view, select an instruction containing an offset and press "t", then select the structure you think it's referencing

In this case, I selected ".text:0000000140CF105E                 mov     rcx, [r8+1A68h]" and marked it as a "map_block_column" offset (since the code immediately above it indexes into _world.map.column_index) and got ".text:0000000140CF105E                 mov     rcx, [r8+map_block_column.plants.ptr]" (and the same with the next instruction, getting "[r8+map_block_column.plants.endptr]"). Below, I determined that "r11" refers to a "plant" object and "rbx" refers to a "plant_tree_info" object.

From my own analysis, the function you found appears to be "df::plant *getPlantAtCoords(int x, int y, int z)" - the code immediately below "loc_140CF1080" checks for an exact coordinate match (e.g. for shrubs), the code just above "loc_140CF115B" checks if it's part of a tree branch, and the code below "loc_140CF115B" checks if it's a tree root.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on May 14, 2021, 08:39:47 am
I started over from compiling DFHack, and I still don't see them. (DFHack version says "release" now instead of "development build 0.47.05-r1-130-g1c32783d" because I didn't use develop branch this time.)

1. Built DFHack, RelWithDebInfo, on a fresh install of "df_47_05_win".
2. Ran codegen_c_hdr.pl on codegen.out.xml to produce codegen.h.
3. Ran ruby.exe dump_df_globals.rb --idc "..\path\to\Dwarf Fortress.exe" to produce MakeName statements.
4. Open Dwarf Fortress.exe in IDA Freeware 7.0, wait for it to finish analysis.
5. File -> Load File -> Parse C header file..., select codegen.h.
6. File -> Script file..., select ms_rtti64.idc, wait for script to finish.
7. File -> Script command..., paste in MakeName statements. Confirm _pause_state exists in Names window.
8. Save the project.
9. Filter for sub_140CF0F90 in the function menu and double-click it. No named addresses present.

I can add the structure map_block_column to the Structures window. Right-clicking the value gives an option for [r8+map_block_column.plants.ptr]. (The 't' option doesn't appear in this menu, but the shortcut works while the offset's selected. UX annoyance.) Right-clicking on the next one gives the option [r8+map_block_column.plants.endptr], so IDA seems to be pretty smart about that.

I'm still stuck with:
Code: [Select]
.text:0000000140CF1009                 cmp     eax, dword ptr cs:xmmword_141D69550+4instead of "cs:_world.map.x_count", though.

There's no result for "x_count" in the Names window. It's not in the MakeName output, which has only 159 lines.

I found an "x_count" in codegen.h in the "T_map" struct. I assume that's not going to help.

There are zero results for "getPlantAtCoords" on the internet (including your post and mine,) so that's kind of puzzling. (Tried Google, DuckDuckGo, and GitHub. At least Bay12Forums can find my post.)
Title: Re: DFHack 0.47.05-r1
Post by: Quietust on May 14, 2021, 10:57:20 am
1. Built DFHack, RelWithDebInfo, on a fresh install of "df_47_05_win".
For what it's worth, you can just clone the "df-structures" respository and run codegen.pl directly - there's no need to build all of DFHack too.
In fact, it's probably better to clone df-structures directly, since that way you can be sure you're looking at the absolute latest definitions.

5. File -> Load File -> Parse C header file..., select codegen.h.
7. File -> Script command..., paste in MakeName statements. Confirm _pause_state exists in Names window.
Apparently, you need to do these in the opposite order - first run the MakeName statements, then import codegen.h.
Fortunately, you don't need to start over if you've gotten this far already - just import codegen.h again and it'll fix it.
You can also edit the structure XML files, rerun codegen.pl and codegen-c-hdr.pl, and reimport codegen.h in order to update the structure definitions in IDA.

I can add the structure map_block_column to the Structures window. Right-clicking the value gives an option for [r8+map_block_column.plants.ptr]. (The 't' option doesn't appear in this menu, but the shortcut works while the offset's selected. UX annoyance.) Right-clicking on the next one gives the option [r8+map_block_column.plants.endptr], so IDA seems to be pretty smart about that.
When you right-click, do you see any key name in the right column of the "Structure offset" menu item (or in any of the other menu items, for that matter)? It's possible that's something I manually configured in my own installation, since I believe it was a default setting in IDA 5.0.

9. Filter for sub_140CF0F90 in the function menu and double-click it. No named addresses present.
Unless this is another one of my custom settings, you should be able to press "g" to open a "Jump to address" prompt, then you can type in either an address (such as 0x140CF0F90) or a symbol name (sub_140CF0F90).

There are zero results for "getPlantAtCoords" on the internet (including your post and mine,) so that's kind of puzzling. (Tried Google, DuckDuckGo, and GitHub. At least Bay12Forums can find my post.)
That's because I made up that name myself, based on its apparent function. After all, we already do the exact same thing with the names of fields in df-structures.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on May 14, 2021, 09:44:35 pm
Apparently, you need to do these in the opposite order - first run the MakeName statements, then import codegen.h.

Looks like that fixed it! Thanks!

When you right-click, do you see any key name in the right column of the "Structure offset" menu item (or in any of the other menu items, for that matter)? It's possible that's something I manually configured in my own installation, since I believe it was a default setting in IDA 5.0.

(https://i.postimg.cc/vmLsFPNN/ida.png)

It actually appears on some of the others, like "[rax+rcx*8]" just above.

Unless this is another one of my custom settings, you should be able to press "g" to open a "Jump to address" prompt, then you can type in either an address (such as 0x140CF0F90) or a symbol name (sub_140CF0F90).

That works. It shows up when right-clicking on the ".text:" area. Didn't know it worked with symbols.

That's because I made up that name myself, based on its apparent function. After all, we already do the exact same thing with the names of fields in df-structures.

Figured as much. Should I rename the function "getPlantAtCoords_140CF0F90" for easier identification? Is there some kind of best practices standard?
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on May 24, 2021, 06:55:21 pm
I updated the first post of this thread (http://www.bay12forums.com/smf/index.php?topic=164123.0) with some new chat options. We have a Discord server and an IRC channel on Libera now. (I'm avoiding linking them here in case any links become stale, so check out the first post (http://www.bay12forums.com/smf/index.php?topic=164123.0) for links.)
Title: Re: DFHack 0.47.05-r1
Post by: vettlingr on June 03, 2021, 10:37:09 am
I have a request:
 Make a "tweak nestbox-color" for hives. to show material hive is made out of
Title: Re: DFHack 0.47.05-r1
Post by: Quietust on June 03, 2021, 04:45:44 pm
I have a request:
 Make a "tweak nestbox-color" for hives. to show material hive is made out of

Should it also affect the color that shows up when you <q>uery the building? If so, it could be done by overriding building_hivest::getNameColor() with something like this:
Code: [Select]
MaterialInfo mat(mat_type, mat_index);
gps.screenf = mat.material.basic_color[0];
gps.screenbright = mat.material.basic_color[1];
(with some extra error checks to make sure the material is actually valid - if not, it should fall back to 6:1).

The same change could also be made to the nestbox-color tweak, if that behavior is desired.

If not, it could be done the same as the existing nestbox-color tweak.
Title: Re: DFHack 0.47.05-r1
Post by: Meph on June 08, 2021, 04:35:08 pm
I couldn't find any in the dfhack documentation, so I'll just ask: Is there a script floating around that could give me the temperature of a tile?
Title: Re: DFHack 0.47.05-r1
Post by: myk on June 08, 2021, 05:03:51 pm
The probe plugin can do this.  Docs here: https://docs.dfhack.org/en/latest/docs/Plugins.html#probe
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on June 09, 2021, 03:20:41 am
Could "unk_v40_1" on projectiles be related to abilities/powers? It's set to 4885 for magma crab globs, 7035 for intelligent undead icicles, and -1 for bolts fired from a crossbow. Falling objects seem to have it set to really high garbage values. Could be the "parabolic" or "unk9" flag that has the game ignore that.

Update on this: Looks like it's the target unit's id. Magma crab was aiming at one of my undead, my undead were all aiming at the magma crab, and the bolt was aimed at an archery target.
Title: Re: DFHack 0.47.05-r1
Post by: Quietust on June 09, 2021, 09:13:53 am
Could "unk_v40_1" on projectiles be related to abilities/powers? It's set to 4885 for magma crab globs, 7035 for intelligent undead icicles, and -1 for bolts fired from a crossbow. Falling objects seem to have it set to really high garbage values. Could be the "parabolic" or "unk9" flag that has the game ignore that.

Update on this: Looks like it's the target unit's id. Magma crab was aiming at one of my undead, my undead were all aiming at the magma crab, and the bolt was aimed at an archery target.
Are the other nearby fields still correct? It's possible the structure might be misaligned and you might actually be looking at the "unk_unit_id" field immediately above it.
Title: Re: DFHack 0.47.05-r1
Post by: Meph on June 09, 2021, 12:40:55 pm
The probe plugin can do this.  Docs here: https://docs.dfhack.org/en/latest/docs/Plugins.html#probe
Thank you :)
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on June 09, 2021, 08:48:15 pm
Are the other nearby fields still correct? It's possible the structure might be misaligned and you might actually be looking at the "unk_unit_id" field immediately above it.

As near as I can tell. For a bolt fired at a porcupine:
Code: [Select]
...
hit_rating 251
unk_21 0
unk_22 40
bow_id 176393
unk_item_id -1
unk_unit_id -1
unk_v40_1 7040
pos_x 0
pos_y 0
pos_z 0
speed_x 0
speed_y 0
speed_z 0
accel_x 0
accel_y 0
accel_z 0
item <item_ammost: 000000C5CCF690E0>
Title: Re: DFHack 0.47.05-r1
Post by: wooks on June 13, 2021, 10:20:43 pm
I'm getting that old bug (in DF) where conscious dwarfs refuse to go get diagnosed in the hospital even though they have serious problems like the inability to stand. Is there a way for me to force him to go to the hospital without outright healing him? My first thought is to just make him unconscious, is there an easy way to do that with DFhack?

Figured it out: gui/gm-unit is your friend future search bar warrior.
However, being unconscious alone was not a solution, as the dwarf in question had only lost the inability to stand, despite having no nerve damage, and thus did 'not require a crutch'. I just fixed his wounds till he walked again because wtf is that.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on June 14, 2021, 03:24:53 pm
From my own analysis, the function you found appears to be "df::plant *getPlantAtCoords(int x, int y, int z)" - the code immediately below "loc_140CF1080" checks for an exact coordinate match (e.g. for shrubs), the code just above "loc_140CF115B" checks if it's part of a tree branch, and the code below "loc_140CF115B" checks if it's a tree root.

Okay, I think I've got a complete understanding of the function.

The assembly seems to use rdx, r8, and r9 for the coordinates. Is this just an optimization?

Or would the real thing be something like:
getPlantAtCoords(unused, unused, x, unused, y, z, &rbp_value, &x_mod_48, &y_mod_48, &rbx_value)

Can we call this function using dfhack, or do we have to write our own version?

I wrote an equivalent in Lua:
Code: [Select]
function getPlantAtCoords(x_coord, y_coord, z_coord)
if ((x_coord // 48) * 48) < 0 then
return nil
elseif ((x_coord // 48) * 48) >= df.global.world.map.x_count then
return nil
elseif ((y_coord // 48) * 48) < 0 then
return nil
elseif ((y_coord // 48) * 48) >= df.global.world.map.y_count then
return nil
elseif not df.global.world.map.column_index then
return nil
end

local mbc = df.global.world.map.column_index[x_coord//48*3][y_coord//48*3]
if not mbc then
return nil
end
for _, p in ipairs(mbc.plants) do
if p.pos.x == x_coord and p.pos.y == y_coord and p.pos.z == z_coord then
return p
else
local t = p.tree_info
if t then
local x_index = t.dim_x // 2 - p.pos.x%48 + x_coord%48
local y_index = t.dim_y // 2 - p.pos.y%48 + y_coord%48
local z_dis = z_coord - p.pos.z

if x_index >= 0 and x_index < t.dim_x and
y_index >= 0 and y_index < t.dim_y and
z_dis < t.body_height and z_dis >= -t.roots_depth then
local bits
if z_dis >= 0 then
bits = t.body[z_dis]:_displace(x_index + y_index*t.dim_x)
else
bits = t.roots[-1 - z_dis]:_displace(x_index + y_index*t.dim_x)
end
if bits[0] or bits[1] or bits[2] or bits[3] or bits[4] or bits[5] or bits[6] then
return p
end
end
end
end
end
return nil
end

Is there a way to access the tree_tile bitfield as a number in Lua so I can use bitwise logic instead?
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on June 14, 2021, 04:33:29 pm
Generally, due to optimizations (possibly including the ones you've noted), we cannot call DF functions directly from DFHack in a cross-platform way. There are some exceptions, like virtual methods, where it's easy, however. There's some precedent in existing library modules for reimplementing pieces of DF logic in DFHack (e.g. Units::getNominalSkill, Units::getVisibleName).

Apparently there are holes in our documentation about bitfields. There's a special "whole" field that provides the raw integer value of a bitfield (i.e. "bits.whole"). That said, I would prefer using symbolic names (e.g. "flags.trunk" instead of "flags[0]") except in cases where it makes a significant difference in performance.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on June 14, 2021, 05:12:33 pm
I'll just leave a comment:
Code: [Select]
if bits.whole & 0x7F > 0 then --Any non-blocked tree_tile
It should probably be implemented in C++, really, since you get type checking (coords are int16_t?) and loop continue, which would look more like the assembly. I had to flip some of the conditions.

Edit: Actually, Lua supports GOTO, so I could really make my script look like assembly if I wanted.

Apparently there are holes in our documentation about bitfields. There's a special "whole" field that provides the raw integer value of a bitfield (i.e. "bits.whole").

Maybe it should be printed for "gui/gm-editor" and the Lua "printall". Could something be done about allowing tree_tiles to be indexed (beyond the z-level) instead of using "_displace", or is that not possible due to them not being vectors? I'll add this to the issue tracker it if it's possible.
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on June 14, 2021, 11:52:49 pm
I'll just leave a comment:
Code: [Select]
if bits.whole & 0x7F > 0 then --Any non-blocked tree_tile
It should probably be implemented in C++, really, since you get type checking (coords are int16_t?) and loop continue, which would look more like the assembly. I had to flip some of the conditions.

Edit: Actually, Lua supports GOTO, so I could really make my script look like assembly if I wanted.
Yeah, there are some limitations to Lua (not that it's necessarily a bad thing, but code can't always correspond one-to-one). Higher-level languages often limit what "goto" can do, at least compared to assembly. In Lua's case, for instance:
Quote from: https://www.lua.org/manual/5.3/manual.html#3.3.4
A goto may jump to any visible label as long as it does not enter into the scope of a local variable.

Quote
Maybe it should be printed for "gui/gm-editor" and the Lua "printall". Could something be done about allowing tree_tiles to be indexed (beyond the z-level) instead of using "_displace", or is that not possible due to them not being vectors? I'll add this to the issue tracker it if it's possible.
There's a substantial risk of breaking code by doing that (e.g. if existing code relies on all fields returned by pairs() being booleans); I'd say it's better just to document.

Your _displace() note is due to the fact that those fields are 2D arrays implemented as double pointers. The Lua layer doesn't have great support for these - I don't know exactly why, but I suspect it has to do with "references" that are exposed to Lua (like an "<int32: ...>" field you see somewhere) not supporting multiple layers of indirection (to be clear, I'm pretty sure that's a limitation in our implementation, not Lua itself). https://docs.dfhack.org/en/stable/docs/Lua%20API.html#container-references has a brief note that stemmed from https://github.com/DFHack/dfhack/issues/597.
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on June 15, 2021, 12:05:51 am
I updated the first post of this thread (http://www.bay12forums.com/smf/index.php?topic=164123.0) with some new chat options. We have a Discord server and an IRC channel on Libera now. (I'm avoiding linking them here in case any links become stale, so check out the first post (http://www.bay12forums.com/smf/index.php?topic=164123.0) for links.)
Update: Freenode has effectively been dismantled at this point - user and channel registrations have been wiped, and most previous servers have been split from the network. Sad to see it go. Fortunately, both Discord and Libera are alive and well (the latter has most of the Freenode staff, from my understanding), so those two are our "official" real-time channels for the time being.

Our documentation has a new page listing all of the relevant support channels (which were previously listed on the "Introduction" page, so hopefully this change makes them easier to find): https://docs.dfhack.org/en/latest/docs/Support.html
Title: Re: DFHack 0.47.05-r1
Post by: Clément on June 15, 2021, 03:07:02 am
The assembly seems to use rdx, r8, and r9 for the coordinates. Is this just an optimization?

Or would the real thing be something like:
getPlantAtCoords(unused, unused, x, unused, y, z, &rbp_value, &x_mod_48, &y_mod_48, &rbx_value)

This is a method on Windows, right? It seems to follow the call convention. Parameter are in rcx, rdx, r8, and r9. rcx is "this" if it is a method call. What were you expecting?
Title: Re: DFHack 0.47.05-r1
Post by: PatrikLundell on June 15, 2021, 03:28:01 am
One problem with the 2D arrays requiring usage of _displace() is that Lua (or our usage of it) is capable of describing those matrices only when they're static, but we don't have the means to specify that the first dimension is according to this field, and the second dimension is according to that one. In fact, we can't even describe one dimensional arrays whose length is determined by the value of a specific field (we can still address the elements blindly, C style, but not check the bounds without specific code for checking it [as opposed to code generated from the usage of a specified field]).
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on June 15, 2021, 07:48:10 pm
This is a method on Windows, right? It seems to follow the call convention. Parameter are in rcx, rdx, r8, and r9. rcx is "this" if it is a method call. What were you expecting?

Conventional parameters 1 (rdi) and 2 (rsi) aren't used. The calling functions seem to leave their garbage data in them. I would have expected rdi, rsi, rdx for x, y, z.

As a result, it ends up putting extra parameters on the stack. (Assuming they even are parameters, and not just local variables being stored in rsp+ instead of rsp-.) It doesn't even modify rbp or rbx, just restores them to registers from the stack (without popping) at end of the function. The mod_48 values are calculated by the function and later loaded back into registers with each loop iteration. I haven't checked if there's a calling function that uses them.

Spoiler: Some context: (click to show/hide)

rdi actually holds a copy of the x coord in this instance, but it's just a register to be restored by the function, since the one in rdx is used.
Title: Re: DFHack 0.47.05-r1
Post by: Clément on June 16, 2021, 05:59:10 am
You must be confusing Windows and SysV (used on Linux, macOS, ...) call conventions. Windows is rcx, rdx, r8, r9, then stack. SysV is rdi, rsi, rdx, rcx, r8, r9 then stack.

See Microsoft documentation (https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention) or the nice recap on wikipedia (https://en.wikipedia.org/wiki/X86_calling_conventions#List_of_x86_calling_conventions).

The four "arguments" you are seeing must be the "shadow store".
Quote from: Microsoft
The x64 Application Binary Interface (ABI) uses a four-register fast-call calling convention by default. Space is allocated on the call stack as a shadow store for callees to save those registers. [...] The caller must always allocate sufficient space to store four register parameters, even if the callee doesn't take that many parameters. [...] The callee is responsible for dumping the register parameters into their shadow space if needed.

So a function always gets space for four registers but it can do whatever it wants with it.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on June 19, 2021, 06:56:01 pm
Does this look all right?
Code: [Select]
using df::global::world;

df::plant *getPlantAtCoords(int32_t x, int32_t y, int32_t z)
{
    if ( (x / 48) * 48 < 0 )
        return NULL;
    else if ( (x / 48) * 48 >= world->map.x_count )
        return NULL;
    else if ( (y / 48) * 48 < 0 )
        return NULL;
    else if ( (y / 48) * 48 >= world->map.y_count )
        return NULL;
    else if ( !world->map.column_index )
        return NULL;
   
    auto mbc = world->map.column_index[ (x / 48) * 3 ][ (y / 48) * 3 ];
    if ( !mbc )
        return NULL;
   
    int32_t x_mod_48 = x%48;
    int32_t y_mod_48 = y%48;
    for(size_t i = 0 ; i < mbc->plants.size(); i++)
    {
        auto p = mbc->plants[i];
        if ( p->pos.x == x && p->pos.y == y && p->pos.z == z )
            return p;
       
        auto t = p->tree_info;
        if ( !t )
            continue;
       
        int32_t x_index = t->dim_x / 2 - p->pos.x%48 + x_mod_48;
        int32_t y_index = t->dim_y / 2 - p->pos.y%48 + y_mod_48;
        int32_t z_dis = z - p->pos.z;
        if ( x_index < 0 || x_index >= t->dim_x )
            continue;
        else if ( y_index < 0 || y_index >= t->dim_y )
            continue;
        else if ( z_dis >= t->body_height )
            continue;
       
        if ( z_dis < 0 )
        {
            if ( z_dis < -( t->roots_depth ) )
                continue;
            if ( (t->roots[z_dis][ x_index + y_index * t->dim_x ].whole & 0x7F) != 0 ) //any non-blocked tree_tile
                return p;
        }
        else if ( (t->body[ -1 - z_dis ][ x_index + y_index * t->dim_x ].whole & 0x7F) != 0 )
            return p;
    }
   
    return NULL;
}
I haven't tested it at all yet.

Is there an existing .cpp I should put it in, or should I create a new .h and .cpp for plant-related DF functions?
Title: Re: DFHack 0.47.05-r1
Post by: PatrikLundell on June 20, 2021, 04:49:32 am
@Bumber:
The x and y negative tests can be simplified to "if (x < -47)", etc., although I don't understand why negative values should be accepted at all (and I think some indexing would blow up later if the index is negative).
Similarly, values greater-equal to the embark size bound will be rejected even if you truncate them back to the boundary (i.e. equal), so why not:
"if (x < 0 || y < 0 || x >= world->max.x_count || y >= world->map.y_count) return NULL;" (but formatted nicely, not an ugly one-liner)?
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on June 20, 2021, 11:56:47 pm
Did the "x / 48 * 48 < 0"-style checks come directly from disassembly? I agree with PatrikLundell that there is a bounds issue there: -47 / 48 == 0, so some small negative numbers will slip through those checks.

I think the first section could be simplified (or corrected) to:
Code: [Select]
if (x < 0 || x >= world->map.x_count || y < 0 || y >= world->map.y_count)
  return NULL;
x_count and y_count do happen to be multiples of 48 currently, so the "/48 * 48" bits don't affect checks against those fields, but I suppose the behavior could be different if map sizes change in the future.

I think this could be a good fit for the Maps module (modules/Maps.cpp), by the way. Gui::getAnyPlant() could definitely stand to be optimized by using your logic, but I don't think yours really belongs in the Gui module.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on June 21, 2021, 12:18:22 am
The x and y negative tests can be simplified to "if (x < -47)", etc., although I don't understand why negative values should be accepted at all (and I think some indexing would blow up later if the index is negative).

That would be caught by the checks on x_index and y_index, though there might be potential for an incorrect result if it falls in bounds somehow.

Did the "x / 48 * 48 < 0"-style checks come directly from disassembly?

Yes:
Code: [Select]
movsx   r13d, dx ; x_coord into r13
mov     eax, 2AAAAAABh ; (2^32 / 6) + 1 into rax {magic number to divide by 6}
mov     esi, r13d ; x_coord into rsi
imul    r13d ; x_coord / 6 into rdx
sar     edx, 3 ; (x_coord / 6) / 8 = x_coord / 48 into rdx
mov     eax, edx ; x_coord / 48 into rax
shr     eax, 1Fh ; sign bit of (x_coord / 48) into rax
add     edx, eax ; add 1 to (x_coord / 48) if negative {correct result for negative numbers}
lea     eax, [rdx+rdx*2] ; (x_coord / 48) * 3 into rax
movzx   edx, r13w ; x_coord into edx
shl     eax, 4 ; (x_coord / 48) * 3 * 16 = (x_coord / 48) * 48 into rax {x tile coord of MLT}
sub     esi, eax ; x_coord - ((x_coord / 48) * 48) = x_coord%48 into rsi
sub     dx, si ; x_coord - x_coord%48 = (x_coord / 48) * 48 into rdx {x tile coord of MLT (again)}
mov     [rsp+30h+arg_10], esi ; save x_coord%48
js      loc_7FF65FC211A2 ; if (x_coord - x_coord%48) negative, return null
movsx   eax, dx ; (x_coord / 48) * 48 into rax
cmp     eax, cs:_world.map.x_count
jge     loc_7FF65FC211A2 ; if ((x_coord / 48) * 48) >= map.x_count, return null
I've cut out the y_coord stuff that's mixed with the x_coord stuff for clarity. (Function arguments are actually supposed to be int16_t instead of int32_t. Don't think this makes a difference.)

I think I'll ask about it in the FotF thread.
Title: Re: DFHack 0.47.05-r1
Post by: PatrikLundell on June 21, 2021, 01:45:12 am
:
x_count and y_count do happen to be multiples of 48 currently, so the "/48 * 48" bits don't affect checks against those fields, but I suppose the behavior could be different if map sizes change in the future.
:
All of that code is directly tied to the current organization of the map, and so would have to be reviewed at a minimum after the map rewrite (which probably would split the plants data into one vector per layer at a minimum, and possibly rework things completely), and probably rewritten from scratch to provide a new logic appropriate for the new logic organization. I'm fairly certain embark size granularity won't change before the map rewrite, unless the rewrite is postponed significantly for some reason.
Title: Re: DFHack 0.47.05-r1
Post by: Clément on June 21, 2021, 04:49:58 pm
Did the "x / 48 * 48 < 0"-style checks come directly from disassembly?

Yes:
Code: [Select]
...

This assembly is compiled from "x - x%48" not "(x/48)*48". It's funny because the compiler compute "x%48" from "x - (x/48)*48", so it ends up computing "x - (x - (x/48)*48)" and not seeing the useless double subtraction. (reproduced with compiler explorer (https://gcc.godbolt.org/z/o4MhGPr17), msvc only, gcc and clang don't do the double subtraction).

This does not change the issue with negative numbers. But forgetting that C integer division is rounded toward 0 and not toward negative infinity is a common error.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on June 22, 2021, 05:21:55 am
Why do some functions in Maps.h use "extern" and others don't? E.g.:
Code: [Select]
extern DFHACK_EXPORT bool RemoveBlockEvent(uint32_t x, uint32_t y, uint32_t z, df::block_square_event * which );

DFHACK_EXPORT bool canWalkBetween(df::coord pos1, df::coord pos2);

How do I add my function to the Lua API? Seems like it's a bit more complicated than adding the line "WRAPM(Maps, getPlantAtCoords)," to LuaApi.cpp.
Edit: Trying to do it like "maps_ensureTileBlock" gives me the error "return value type does not match the function type".

Also, what am I looking at here: "WRAPN(getBlock, (df::map_block* (*)(int32_t,int32_t,int32_t))Maps::getBlock),"
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on June 22, 2021, 09:33:53 am
Why do some functions in Maps.h use "extern" and others don't? E.g.:
Code: [Select]
extern DFHACK_EXPORT bool RemoveBlockEvent(uint32_t x, uint32_t y, uint32_t z, df::block_square_event * which );

DFHACK_EXPORT bool canWalkBetween(df::coord pos1, df::coord pos2);

How do I add my function to the Lua API? Seems like it's a bit more complicated than adding the line "WRAPM(Maps, getPlantAtCoords)," to LuaApi.cpp.

Edit: Trying to do it like "maps_ensureTileBlock" gives me the error "return value type does not match the function type".
If you could provide the function signature and any relevant pieces of the error you're getting, that would help. WRAPM should be all that's necessary in most cases, but sometimes weird argument or return types can trip it up.

maps_ensureTileBlock() is an example of a custom-implemented function that uses the Lua C API (section 4 of https://www.lua.org/manual/5.3/manual.html). That is an option, but the WRAP macros are much less maintenance effort.

Quote
Also, what am I looking at here: "WRAPN(getBlock, (df::map_block* (*)(int32_t,int32_t,int32_t))Maps::getBlock),"
There are two implementations of Maps::getBlock - one takes three int32_ts and one takes a df::coord. Casting to a function pointer specifies which one to select. Without it, we'd get a fairly confusing error:
Spoiler (click to show/hide)

On that note: thanks for taking the time to expose this to Lua!
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on June 22, 2021, 10:19:08 am
If you could provide the function signature and any relevant pieces of the error you're getting, that would help. WRAPM should be all that's necessary in most cases, but sometimes weird argument or return types can trip it up.

Code: [Select]
extern DFHACK_EXPORT df::plant *getPlantAtCoords(int32_t x, int32_t y, int32_t z);

inline df::plant *getPlantAtCoords(df::coord pos) { return getPlantAtCoords(pos.x, pos.y, pos.z); }

Was getting a red squiggly line for "return Lua::PushDFObject" in "static int maps_getPlantAtCoords(lua_State *L)" with the message. Error was result of copying from "maps_getTileBiomeRgn" and editing to "PushDFObject", instead of from "maps_ensureTileBlock" (which returns 1.)

Doing it like getBlock with WRAPN seems to work. Not used to working with function pointers, so the syntax was confusing.

How does the Lua C API way determine which implementation it's using?


Edit: Doesn't look like it's accepting DFCoord (using xyz2pos) in Lua using WRAPN with cast. C API works for both DFCoord and three int32_ts.

It's also crashing on tree branches, so I've got to debug that. I had the z indexes for "body" and "roots" swapped, causing it to always use a negative index.
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on June 22, 2021, 06:15:39 pm
Code: [Select]
extern DFHACK_EXPORT df::plant *getPlantAtCoords(int32_t x, int32_t y, int32_t z);

inline df::plant *getPlantAtCoords(df::coord pos) { return getPlantAtCoords(pos.x, pos.y, pos.z); }

Was getting a red squiggly line for "return Lua::PushDFObject" in "static int maps_getPlantAtCoords(lua_State *L)" with the message. Error was result of copying from "maps_getTileBiomeRgn" and editing to "PushDFObject", instead of from "maps_ensureTileBlock" (which returns 1.)

Doing it like getBlock with WRAPN seems to work. Not used to working with function pointers, so the syntax was confusing.

How does the Lua C API way determine which implementation it's using?


Edit: Doesn't look like it's accepting DFCoord (using xyz2pos) in Lua using WRAPN with cast. C API works for both DFCoord and three int32_ts.
The function passed to WRAP is the one that's exposed to Lua. Casting the function to a specific type essentially forces the compiler to pick the implementation of that function that can be cast to that type - otherwise it would be ambiguous (I could have phrased this better earlier). if you're choosing to expose the one that takes (int32, int32, int32) params to Lua, you will only be able to pass those from Lua, not a df::coord object, and vice versa if you expose the other implementation. There isn't a way to support both types of arguments without using the Lua C API. If you want to do that, there are several examples - maps_getTileBlock() might be a good one since it returns a map_block pointer.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on June 25, 2021, 11:07:28 am
I made a small script that uses the new function to get a tree at the cursor and print a representation of its tree_tiles:
Code: (print-tree.lua) [Select]
--Print the tree at cursor
--@module = true

function printTreeTile(bits,roots)
local old_color = dfhack.color()
local none = true
if bits.trunk then
dfhack.color(COLOR_BROWN)
if roots then
dfhack.print(string.char(172)) --1/4
else
dfhack.print("O")
end
none = false
end
if bits.branches then
dfhack.color(COLOR_GREEN)
dfhack.print(string.char(172)) --1/4
none = false
end
if bits.twigs then
dfhack.color(COLOR_GREEN)
dfhack.print(";")
none = false
end
if bits.connection_north then
dfhack.color(COLOR_RESET)
dfhack.print(string.char(24)) --up arrow
none = false
end
if bits.connection_south then
dfhack.color(COLOR_RESET)
dfhack.print(string.char(25)) --down arrow
none = false
end
if bits.connection_west then
dfhack.color(COLOR_RESET)
dfhack.print(string.char(27)) --left arrow
none = false
end
if bits.connection_east then
dfhack.color(COLOR_RESET)
dfhack.print(string.char(26)) --right arrow
none = false
end
if bits.blocked then
dfhack.color(COLOR_RED)
dfhack.print("x")
none = false
end
if none then
dfhack.color(COLOR_RESET)
dfhack.print(".")
end
dfhack.color(old_color)
end

function printTree(t)
if not t then
return
end
print("---------------------------------------------------------")
for z = t.body_height-1, 0, -1 do
for i = 0, t.dim_x*t.dim_y-1 do
printTreeTile(t.body[z]:_displace(i))
if i%t.dim_x == t.dim_x-1 then
print("\t|")
else
dfhack.print("\t")
end
end
print("---------------------------------------------------------")
end
for z = 0, t.roots_depth-1 do
for i = 0, t.dim_x*t.dim_y-1 do
printTreeTile(t.roots[z]:_displace(i),true)
if i%t.dim_x == t.dim_x-1 then
print("\t|")
else
dfhack.print("\t")
end
end
print("---------------------------------------------------------")
end
end

if not dfhack_flags.module then
p = dfhack.maps.getPlantAtTile(pos2xyz(df.global.cursor))

if p then
printTree(p.tree_info)
end
end

Bits:
O/¼ - Trunk/Roots
¼ - Branches
; - Twigs
↑/↓/←/→ - Connects N/S/W/E
x - Blocked
. - Empty



Title: Re: DFHack 0.47.05-r1
Post by: A_Curious_Cat on July 03, 2021, 08:36:41 pm
Is there any way to use DFHack to recover a book that has fallen over a waterfall, or is using pumps (including  some that would has to be placed at the bottom of a ravine) to dam and drain the riverbed the only way?  I tried using autodump, but it seems that books can’t be marked for dumping.  Any help would be greatly appreciated.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on July 03, 2021, 08:49:22 pm
Is there any way to use DFHack to recover a book that has fallen over a waterfall, or is using pumps (including  some that would has to be placed at the bottom of a ravine) to dam and drain the riverbed the only way?  I tried using autodump, but it seems that books can’t be marked for dumping.  Any help would be greatly appreciated.

Try "gui/gm-editor" with your cursor on the book. You should be able to edit its coordinates.

Maybe I should write a teleport-item script that can move any item anywhere.
Title: Re: DFHack 0.47.05-r1
Post by: A_Curious_Cat on July 03, 2021, 09:26:57 pm
Is there any way to use DFHack to recover a book that has fallen over a waterfall, or is using pumps (including  some that would has to be placed at the bottom of a ravine) to dam and drain the riverbed the only way?  I tried using autodump, but it seems that books can’t be marked for dumping.  Any help would be greatly appreciated.

Try "gui/gm-editor" with your cursor on the book. You should be able to edit its coordinates.

Maybe I should write a teleport-item script that can move any item anywhere.

How do I find out what coordinates to send it to?
Title: Re: DFHack 0.47.05-r1
Post by: PatrikLundell on July 04, 2021, 02:05:28 am
Place the cursor on the location you want to teleport the item to (any of the cursor types will do, such as k, v, or t). Type gui/gm-editor df.global.cursor. The coordinates you see are the coordinates of the cursor location.
Title: Re: DFHack 0.47.05-r1
Post by: Fleeting Frames on July 04, 2021, 03:21:54 am
Is there any way to use DFHack to recover a book that has fallen over a waterfall, or is using pumps (including  some that would has to be placed at the bottom of a ravine) to dam and drain the riverbed the only way?  I tried using autodump, but it seems that books can’t be marked for dumping.  Any help would be greatly appreciated.

Try "gui/gm-editor" with your cursor on the book. You should be able to edit its coordinates.

Maybe I should write a teleport-item script that can move any item anywhere.

You want dfhack.items.moveToGround instead. Catches corner issues like occupancy.

Btw, already wrote something like that:
Spoiler: hackdump.lua (click to show/hide)
For safety, by default only dumps forbidden items on ground that aren't in job or inventory, but  this can be altered ofc.
Title: Re: DFHack 0.47.05-r1
Post by: A_Curious_Cat on July 04, 2021, 05:37:03 pm
I followed PatrikLundell and Bumber’s advice (didn’t see Freeting Flames’ post until afterwards).  The only problem is that the ‘k’ look command stopped working until I saved and reloaded.  Thanks, everyone!
Title: Re: DFHack 0.47.05-r1
Post by: chickrickepachimecho on July 05, 2021, 02:33:03 pm
I want to make 3 plugins for dfhack.

One that can cut down the one non food tree that will give the most wood.
Another for taking all the dwarves bad thoughts and listing them with the number of times it has occurred.
The last one would count all the dwarves worn clothes and print out a list with numbers of how many worn clothes there are of each subtype.

Do these sound feasible? Are they replicating functionality already built in?

I plan on starting with the tree one since autochop is a thing.
Title: Re: DFHack 0.47.05-r1
Post by: Kat on July 05, 2021, 03:25:11 pm
Hello,
I was using the "show unit syndromes" in my game, and it was throwing an error on one of the citizens, who had a vampire curse active on them. It wouldn't show syndromes on any other citizens after it found the cursed one.

in the stderr.log, it has this:

Invoking: show-unit-syndromes
E: NoMethodError: undefined method `unk_6c' for #<DFHack::CreatureInteractionEffectBodyMatInteractionst:0x000000090e48c8>
 hack/scripts/show-unit-syndromes.rb:840:in `get_effect'
 hack/scripts/show-unit-syndromes.rb:886:in `block (2 levels) in <top (required)>'
 E:/Dwarf stuff/df_47_05_win/hack/ruby/ruby-autogen-defs.rb:439:in `block in each'
 E:/Dwarf stuff/df_47_05_win/hack/ruby/ruby-autogen-defs.rb:439:in `each'
 E:/Dwarf stuff/df_47_05_win/hack/ruby/ruby-autogen-defs.rb:439:in `each'
 hack/scripts/show-unit-syndromes.rb:886:in `collect'
 hack/scripts/show-unit-syndromes.rb:886:in `block in <top (required)>'
 hack/scripts/show-unit-syndromes.rb:947:in `[]'

Once I used add-syndrome to remove the syndrome (I used -eraseClass with both VAMPCURSE and DISTURBANCE_CURSE), then show-unit-syndromes ran properly with all citizens with syndromes shown.

Would this be because I am using modded creatures in my game ? Or because those kinds of curses cause a problem with the show-unit-syndromes command ?
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on July 05, 2021, 11:28:53 pm
Hello,
I was using the "show unit syndromes" in my game, and it was throwing an error on one of the citizens, who had a vampire curse active on them. It wouldn't show syndromes on any other citizens after it found the cursed one.

in the stderr.log, it has this:

Invoking: show-unit-syndromes
E: NoMethodError: undefined method `unk_6c' for #<DFHack::CreatureInteractionEffectBodyMatInteractionst:0x000000090e48c8>
 hack/scripts/show-unit-syndromes.rb:840:in `get_effect'
 hack/scripts/show-unit-syndromes.rb:886:in `block (2 levels) in <top (required)>'
 E:/Dwarf stuff/df_47_05_win/hack/ruby/ruby-autogen-defs.rb:439:in `block in each'
 E:/Dwarf stuff/df_47_05_win/hack/ruby/ruby-autogen-defs.rb:439:in `each'
 E:/Dwarf stuff/df_47_05_win/hack/ruby/ruby-autogen-defs.rb:439:in `each'
 hack/scripts/show-unit-syndromes.rb:886:in `collect'
 hack/scripts/show-unit-syndromes.rb:886:in `block in <top (required)>'
 hack/scripts/show-unit-syndromes.rb:947:in `[]'

Once I used add-syndrome to remove the syndrome (I used -eraseClass with both VAMPCURSE and DISTURBANCE_CURSE), then show-unit-syndromes ran properly with all citizens with syndromes shown.

Would this be because I am using modded creatures in my game ? Or because those kinds of curses cause a problem with the show-unit-syndromes command ?
It's an issue with the script. Looks like you're the first one that's reported it since it broke a year or so ago, so thank you! (It may be a rare case - I don't seem to have a save where I can reproduce the issue easily.)

Here's a fix (https://github.com/DFHack/scripts/commit/2b2967c84697d70eb4dd73c641b8d17767f871e2) that should work. If you can test it out, that'd be great. You can either make the changes manually to hack/scripts/show-unit-syndromes.rb, or replace that file with the new version (https://raw.githubusercontent.com/DFHack/scripts/2b2967c84697d70eb4dd73c641b8d17767f871e2/show-unit-syndromes.rb) (be sure to save the new one with a ".rb" extension and overwrite the existing one).

This fix will also be in the next DFHack release, which is hopefully soon.
Title: Re: DFHack 0.47.05-r1
Post by: PatrikLundell on July 06, 2021, 01:43:50 am
I want to make 3 plugins for dfhack.

One that can cut down the one non food tree that will give the most wood.
Another for taking all the dwarves bad thoughts and listing them with the number of times it has occurred.
The last one would count all the dwarves worn clothes and print out a list with numbers of how many worn clothes there are of each subtype.

Do these sound feasible? Are they replicating functionality already built in?

I plan on starting with the tree one since autochop is a thing.
I'd suggest writing Lua scripts rather than plugins, as it seems these are intended to be used as commands entered by the player, and neither of them should require compiled code for efficiency reasons.
All of them seem to be quite possible to implement.

As a starting point for the first one, here's one of my scripts intended to control which trees to cut, sparing one of each resource providing kind of tree, selecting the ones closest to the center of the embark. It skips cavern trees, and deals with elven logging restrictions.
Spoiler (click to show/hide)
Title: Re: DFHack 0.47.05-r1
Post by: Kat on July 06, 2021, 01:25:58 pm
It's an issue with the script. Looks like you're the first one that's reported it since it broke a year or so ago, so thank you! (It may be a rare case - I don't seem to have a save where I can reproduce the issue easily.)

Here's a fix (https://github.com/DFHack/scripts/commit/2b2967c84697d70eb4dd73c641b8d17767f871e2) that should work. If you can test it out, that'd be great. You can either make the changes manually to hack/scripts/show-unit-syndromes.rb, or replace that file with the new version (https://raw.githubusercontent.com/DFHack/scripts/2b2967c84697d70eb4dd73c641b8d17767f871e2/show-unit-syndromes.rb) (be sure to save the new one with a ".rb" extension and overwrite the existing one).

ah, I don't have an earlier save. I _do_ know the curse that was inflicted on the unit concerned though. Can I apply that again somehow ? curse was "DEITY_CURSE_VAMPIRE_19"
Title: Re: DFHack 0.47.05-r1
Post by: stroppycarpet on July 07, 2021, 01:32:57 pm
Hello everybody.


I'm running a modded DF that adds special military castes that have a really bad learning rate in all skills except a few skills they're specialized in. (a few skills are +100% exp, and all others are -1% or raw value -101 meaning they will never level up)
Unfortunately the mod author forgot to add a very crucial skill (discipline) to the list of skills that have a bonus, meaning they can never level up discipline.
It's running an older verion of dfhack, namely 0.44.12-r2.

My first go-to fix was to search the dfhack documentation and there's a script mentioned there, assign-skills which allows you to set skill levels.
I dragged and dropped the assign-skills.lua into the folder with all my dfhack scripts from the mod, and it did work.

However, it left me curious on how to mod learning rate for individual dwarves if I wanted to. I noticed that in assign-skills.lua theres a line that says "unit.status.current_soul.skills" in order to access the skill levels. Is there a similar 'method' for skill rate like .e.g.  unit.status.current_soul.skillrates? Does this exist? If I were to assign something to that, how do I assign to it?

Or you could point me to a list of all the possible methods or objects within "unit", because I can't find it.

thanks in advance!
Title: Re: DFHack 0.47.05-r1
Post by: Clément on July 07, 2021, 02:13:22 pm
If Dwarf Therapist is doing it correctly, there is no individual skill rate, it's only in castes (caste_raw.skill_rates). Did you try fixing the raws first? It might not need to re-run worldgen.
Title: Re: DFHack 0.47.05-r1
Post by: chickrickepachimecho on July 07, 2021, 09:05:05 pm
Is there a way to use this struct

Code: [Select]
  struct DFHACK_EXPORT plant_tree_info {
    df::plant_tree_tile** body; /*!< dimension body_height */
    int16_t* extent_east; /*!< dimension body_height */
    int16_t* extent_south; /*!< dimension body_height */
    int16_t* extent_west; /*!< dimension body_height */
    int16_t* extent_north; /*!< dimension body_height */
    int32_t body_height;
    int32_t dim_x;
    int32_t dim_y;
    df::plant_tree_tile** roots; /*!< dimension roots_depth */
    int32_t roots_depth;
    int16_t unk6;
    static struct_identity _identity;
  public:
    plant_tree_info();
  };
to find the number of logs that the tree will produce?
Title: Re: DFHack 0.47.05-r1
Post by: myk on July 07, 2021, 09:27:56 pm
If you are writing code to programmatically chop down trees then I am intrigued and would like to subscribe to your newsletter. This is the last bit of missing functionality from my dig-now plugin.
Title: Re: DFHack 0.47.05-r1
Post by: PatrikLundell on July 08, 2021, 02:02:42 am
@chickrickepachimecho: Probably, as all the info is in there, although I don't know if anyone has researched how to calculate it.

My first attempt would be to simply walk through the tiles of the tree and count the number of trunks, cut down the tree, and compare the number to the number of logs found (obviously the area should either be free of other logs, or the preexisting logs should be marked with e.g. the 'f'orbidden flag to distinguish the new logs from the old ones).

I'd examine blood thorn (very high yield) as well as two and three tile diameter trees (I think highwood is the only one to produce 3 tile one, with some "normal" tree(s) being capable of producing 2 tile diameter trunks).

Also note that the "body" field has an odd description, saying "dimension body_height", while also describing the matrix as "dimension dim_x*dim_y" (the latter isn't shown in the C struct, but it's in the XML source for the C struct). This leads to the suspicion that it's actually a 3 dimensional array (body_height*dim_x*dim_y), which is what would be required to actually contain the info for all of the relevant tiles. However, be prepared for DF crashing if you try to access the structure that way, as it may well refer to unallocated memory if it's only a two dimensional structure. I'd also try to see if the bit combinations aren't nonsensical, as you shouldn't have "blocked" set together with anything else, and "trunk", "branches", and "twigs" probably should be mutually exclusive).

Edit: I've looked at my woodcutter cutting trees and counted the number of trunk segments present before cutting (using the Mk I eyeball) against the number of logs produced, and they've matched so far (surface trees, producing 2-7 logs). I don't have any wide trunk trees.
Title: Re: DFHack 0.47.05-r1
Post by: stroppycarpet on July 08, 2021, 06:16:26 am
If Dwarf Therapist is doing it correctly, there is no individual skill rate, it's only in castes (caste_raw.skill_rates). Did you try fixing the raws first? It might not need to re-run worldgen.

Unfortunately editing the raws contained in the save folder of my world does not fix it. At least, it doesn't fix it in my already-running fortress game. if I were to abandon and reclaim my fortress it might work, but I can't be bothered to do it.

I've noticed that since the rate is effectively -1%, my military commander that has this special caste (race: human, caste: Squire, female; in the masterwork mod, most recent download) she loses discipline over time when training in barracks if you hack her to have a score of .e.g. 7 in dfhack with assign-skills. So every now and then I need to check up on her and discipline her (literally).

For now I'll live with the minor invonvenience of having to give her discipline once every 2 years and keep soldiering on.

At least until I figure out the method or function to edit caste skill rates.
Title: Re: DFHack 0.47.05-r1
Post by: chickrickepachimecho on July 08, 2021, 12:46:13 pm
How do you go about debugging a plugin that crashes? So far, I've been commenting code out, but I would like a faster way.
Title: Re: DFHack 0.47.05-r1
Post by: chickrickepachimecho on July 08, 2021, 01:49:22 pm
@chickrickepachimecho: Probably, as all the info is in there, although I don't know if anyone has researched how to calculate it.

My first attempt would be to simply walk through the tiles of the tree and count the number of trunks, cut down the tree, and compare the number to the number of logs found (obviously the area should either be free of other logs, or the preexisting logs should be marked with e.g. the 'f'orbidden flag to distinguish the new logs from the old ones).

I'd examine blood thorn (very high yield) as well as two and three tile diameter trees (I think highwood is the only one to produce 3 tile one, with some "normal" tree(s) being capable of producing 2 tile diameter trunks).

Also note that the "body" field has an odd description, saying "dimension body_height", while also describing the matrix as "dimension dim_x*dim_y" (the latter isn't shown in the C struct, but it's in the XML source for the C struct). This leads to the suspicion that it's actually a 3 dimensional array (body_height*dim_x*dim_y), which is what would be required to actually contain the info for all of the relevant tiles. However, be prepared for DF crashing if you try to access the structure that way, as it may well refer to unallocated memory if it's only a two dimensional structure. I'd also try to see if the bit combinations aren't nonsensical, as you shouldn't have "blocked" set together with anything else, and "trunk", "branches", and "twigs" probably should be mutually exclusive).

Edit: I've looked at my woodcutter cutting trees and counted the number of trunk segments present before cutting (using the Mk I eyeball) against the number of logs produced, and they've matched so far (surface trees, producing 2-7 logs). I don't have any wide trunk trees.

So yea, the following code does indeed crash the game.
Code: [Select]
                    for (int i = 0; i < plant->tree_info->dim_x; i++) {
                        tilesRow = tiles[i];
                        for (int j = 0; j < plant->tree_info->dim_y; j++) {
                            trunks += tilesRow[j].bits.trunk;
                        }
                    }

Edit: Of course it does... should have looked like this
Code: [Select]
                    for (int i = 0; i < plant->tree_info->body_height; i++) {
                        tilesRow = tiles[i];
                        for (int j = 0; j < plant->tree_info->dim_y*plant->tree_info->dim_x; j++) {
                            trunks += tilesRow[j].bits.trunk;
                        }
                    }

The above code runs fine now.
Title: Re: DFHack 0.47.05-r1
Post by: chickrickepachimecho on July 08, 2021, 02:49:17 pm
Can anyone tell me why the print statements are not working? I know the code is being run because feeding a null pointer to markPlant(tallestTree); causes the program to crash.

Code: [Select]
#include "Core.h"
#include "Console.h"
#include "Export.h"
#include "PluginManager.h"
#include "DataDefs.h"

#include "df/map_block.h"
#include "df/material.h"
#include "df/tiletype_material.h"
#include "df/plant.h"
#include "df/plant_raw.h"
#include "df/plant_tree_info.h"
#include "df/plant_tree_tile.h"
#include "df/world.h"

#include "modules/Designations.h"
#include "modules/Maps.h"
#include "modules/World.h"

#include <algorithm>
#include <sstream>
#include <string>

using namespace DFHack;
using namespace df::enums;

#define PLUGIN_VERSION 0.1
DFHACK_PLUGIN("talltree");
REQUIRE_GLOBAL(world);

static void markPlant(df::plant* plant);

static void markPlant(df::plant* plant) {
    if (Designations::canMarkPlant(plant)) {
        Designations::markPlant(plant);
    }
}

command_result talltree(color_ostream &out, std::vector<std::string> & params);

command_result talltree(color_ostream &out, std::vector<std::string> & params) {
    // Suspend the core before changing internal data
    CoreSuspender suspend;
    out.print("Valid?");
    if (Maps::IsValid()) {
        const df::plant_raw *plantRaw;
        bool chop = true;
        int maxLogs = 0;
        df::plant* tallestTree = 0;
        std::vector<df::plant*> doneGrowing{};
        for (auto & plant : world->plants.all) {
            int x = plant->pos.x % 16;
            int y = plant->pos.y % 16;
            df::map_block* tileBlock = Maps::getTileBlock(plant->pos);
            if (plant->flags.bits.is_shrub ||
                (plant->material != df::tiletype_material::TREE) ||
                !tileBlock ||
                tileBlock->designation[x][y].bits.hidden) {
                chop = false;
            }
            else {
                plantRaw = df::plant_raw::find(plant->material);
                if (plantRaw->material_defs.type[plant_material_def::drink]) {
                    chop = false;
                }
                for (auto material : plantRaw->material) {
                    if (material->flags.is_set(material_flags::EDIBLE_RAW) ||
                        material->flags.is_set(material_flags::EDIBLE_COOKED)) {
                        chop = false;
                    }
                }
                std::stringstream ss1;
                ss1 << "Chop: " << chop;
                out.print(ss1.str().c_str());
                if (chop) {
                    df::plant_tree_tile** tiles = plant->tree_info->body;
                    df::plant_tree_tile* tilesRow;
                    int trunks = 0;

                    for (int i = 0; i < plant->tree_info->body_height; i++) {
                        tilesRow = tiles[i];
                        for (int j = 0; j < plant->tree_info->dim_y*plant->tree_info->dim_x; j++) {
                            trunks += tilesRow[j].bits.trunk;
                        }
                    }
                    std::stringstream ss;
                    ss << "Trunks: " << trunks;
                    out.print(ss.str().c_str());
                    maxLogs = std::max(maxLogs, trunks);
                    if (maxLogs == trunks) {
                        tallestTree = plant;
                    }
                    if (plantRaw->max_trunk_height*plantRaw->max_trunk_diameter <= trunks) {
                        doneGrowing.push_back(plant);
                    }
                }

            }
        }
        //markPlant(tallestTree);
        for (auto & plant : doneGrowing) {
            markPlant(plant);
        }

    }
    return CR_OK;
}

DFhackCExport command_result plugin_init(color_ostream &out, std::vector <PluginCommand> &commands) {
    commands.push_back(
        PluginCommand(
            "talltree",
            "Cuts down the non fruit trees that will give the most wood, and the ones that are done growing\n",
            talltree,
            false,
            "Finds the non fruit tree that wil give the most wood and designates it for cutting.\n"
            "Also cuts down all the non fruit trees that are done growing.\n"
        )
    );
    return CR_OK;
}

DFhackCExport command_result plugin_shutdown(color_ostream &out);

DFhackCExport command_result plugin_shutdown(color_ostream &out) {
    return CR_OK;
}

Edit: Needed std::endl
Title: Re: DFHack 0.47.05-r1
Post by: chickrickepachimecho on July 08, 2021, 03:44:54 pm
I got the tallest tree. The number of logs for the tree was correct. Not sure on the ginkgos et al yet.

Code: [Select]
command_result talltree(color_ostream &out, std::vector<std::string> & params) {
    // Suspend the core before changing internal data
    CoreSuspender suspend;
    out << ("Valid?") << std::endl;
    if (Maps::IsValid()) {
        const df::plant_raw *plantRaw;
        bool chop = true;
        int maxLogs = 0;
        df::plant* tallestTree = 0;
        std::vector<df::plant*> doneGrowing{};
        for (auto & plant : world->plants.all) {
            chop = true;
            int x = plant->pos.x % 16;
            int y = plant->pos.y % 16;
            df::map_block* tileBlock = Maps::getTileBlock(plant->pos);
            if (tileBlock) {
                df::tiletype_material material = tileMaterial(tileBlock->tiletype[x][y]);
                if (material != df::tiletype_material::TREE ||
                    tileBlock->designation[x][y].bits.hidden) {
                    chop = false;
                }
            }
            else {
                chop = false;
            }
            if (plant->flags.bits.is_shrub) {
                chop = false;
            }
            else {
                plantRaw = df::plant_raw::find(plant->material);
                if (plantRaw->material_defs.type[plant_material_def::drink] != -1) {
                    chop = false;
                }
                for (auto material : plantRaw->material) {
                    if (material->flags.is_set(material_flags::EDIBLE_RAW) ||
                        material->flags.is_set(material_flags::EDIBLE_COOKED)) {
                        chop = false;
                    }
                }
                if (chop) {
                    df::plant_tree_tile** tiles = plant->tree_info->body;
                    df::plant_tree_tile* tilesRow;
                    int trunks = 0;
                    for (int i = 0; i < plant->tree_info->body_height; i++) {
                        tilesRow = tiles[i];
                        for (int j = 0; j < plant->tree_info->dim_y*plant->tree_info->dim_x; j++) {
                            trunks += tilesRow[j].bits.trunk;
                        }
                    }
                    out << "Trunks: " << trunks << std::endl;;
                    maxLogs = std::max(maxLogs, trunks);
                    if (maxLogs == trunks) {
                        tallestTree = plant;
                    }
                    if (plantRaw->max_trunk_height*plantRaw->max_trunk_diameter*plantRaw->max_trunk_diameter <= trunks) {
                        doneGrowing.push_back(plant);
                    }
                }
            }
        }
        markPlant(tallestTree);
        /*
        for (auto & plant : doneGrowing) {
            markPlant(plant);
        }
        */
    }
    return CR_OK;
}

The problem now is that pretty much all trees are getting marked as done growing.

Code: [Select]
plantRaw->max_trunk_height*plantRaw->max_trunk_diameter*plantRaw->max_trunk_diameter <= trunks
max_trunk_height and max_trunk_diameter must not be what I think they are. Does anyone know how to see if a tree is done growing?
Title: Re: DFHack 0.47.05-r1
Post by: chickrickepachimecho on July 08, 2021, 06:35:18 pm
If you are writing code to programmatically chop down trees then I am intrigued and would like to subscribe to your newsletter. This is the last bit of missing functionality from my dig-now plugin.

I was able to chop down the tallest non fruiting tree using the code above.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on July 09, 2021, 12:56:52 am
If you are writing code to programmatically chop down trees then I am intrigued and would like to subscribe to your newsletter. This is the last bit of missing functionality from my dig-now plugin.

I've made some progress on reverse engineering that:
Code: [Select]
void chopTree(int32_t x, int32_t y, int32_t z, df::unitst &unit) //might take more parameters
{
int32_t unit_dis_x = (x - unit->pos.x);
int32_t unit_dis_y = (y - unit->pos.y);
auto plant = dfhack.maps.getPlantAtTile(x,y,z);
if (plant == NULL)
return;

auto tree = plant->tree_info;
if (tree == NULL)
return;

int32_t tree_min_x = plant->pos.x - (tree->dim_x / 2);
int32_t tree_min_y = plant->pos.y - (tree->dim_y / 2);
int32_t tree_min_z = plant->pos.z;
int32_t tree_max_x = (tree->dim_x - 1) + tree_min_x;
int32_t tree_max_y = (tree->dim_y - 1) + tree_min_y;
int32_t tree_max_z = (tree_min_z - 1) + tree->body_height;

for (int32_t loop_x=0, tile_x=tree_min_x; loop_x < tree->dim_x; loop_x++, tile_x++)
{
for (int32_t loop_y=0, tile_y=tree_min_y; loop_y < tree->dim_y; loop_y++, tile_y++)
{
for (int32_t loop_z=(tree->body_height-1), tile_z=tree_max_z; loop_z >= 0; loop_z--, tile_z--)
{
if (tree->body[loop_z][(tree->dim_x * loop_y) + loop_x].trunk == false)
continue;
int32_t mat = plant->material;
if (mat < 0)
continue;
auto raw_plants = df->global->world->raws->plants->all;
if (mat >= raw_plants.size())
continue;
auto plant_raw = raw_plants[mat];
int32_t mattype = plant_raw->material_defs.type[plant_material_def::tree];
int32_t matindex = plant_raw->material_defs.idx[plant_material_def::tree];
if (mattype == -1)
continue;
//need to update item counts and fulfill mandates
//auto log = createItem(-1,item_type::WOOD,mattype,matindex); //function has more parameters than this
log->pos.x = tile_x;
log->pos.y = tile_y;
log->pos.z = tile_z;
//need to create new df::item_projst;
proj->origin_pos.x = tile_x;
proj->origin_pos.y = tile_y;
proj->origin_pos.z = tile_z;
proj->prev_pos.x = tile_x;
proj->prev_pos.y = tile_y;
proj->prev_pos.z = tile_z;
proj->item = log;
proj->cur_pos.x = tile_x;
proj->cur_pos.y = tile_y;
proj->cur_pos.z = tile_z;
//insert proj.id into log general_ref
proj->firer = unit;
//set no_impact_destroy|bouncing|piercing|parabolic|unk9|no_collide:
proj->flags.whole |= 0xB15;
proj->pos_x = 0;
//proj->pos_y = 0; //this isn't used?
proj->pos_z = 0;
proj->speed_x = unit_dis_x * 10000;
proj->speed_y = unit_dis_y * 10000;
proj->speed_z = 0;
//proj->accel_x = 0; //this isn't used?
proj->accel_y = 0;
//proj->accel_z = 0; //this isn't used?
//need to calculate proj->hit_rating
log->flags.in_job = true;
}
}
}
}
//need to handle tiletypes, etc. It's in a separate loop for some reason.
(They aren't all int32_t, I just didn't bother to double check.)

Unfortunately, I haven't gotten to the tiletypes part yet. I got distracted by item creation logic, which leads to fulfilling mandates, which leads to adding good thoughts to nobles...

On the plus side, we might be able to create items without a unit if I keep digging in that direction.
Title: Re: DFHack 0.47.05-r1
Post by: PatrikLundell on July 09, 2021, 01:46:41 am
How do you go about debugging a plugin that crashes? So far, I've been commenting code out, but I would like a faster way.
Start the game, hook up a debugger to it, and catch the crash (or set up a breakpoint at the plugin entry and single step through the code).
If, for whatever reason, you don't (want to) use a debugger, I'd try to add trace printouts.

As an aside, I'd consider updating posts with additional info rather than multiposting.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on July 09, 2021, 03:08:03 am
Does anyone know how to see if a tree is done growing?

Consider using the plant's age? Counting trunk tiles isn't going to work for that because tree growth can be stunted due to obstacles, including other trees. (In addition to any randomness in layout.)
Title: Re: DFHack 0.47.05-r1
Post by: chickrickepachimecho on July 09, 2021, 08:15:27 am
Does anyone know how to see if a tree is done growing?

Consider using the plant's age? Counting trunk tiles isn't going to work for that because tree growth can be stunted due to obstacles, including other trees. (In addition to any randomness in layout.)

Yea, I was able to find plant.grow_counter, but am not sure what values it would have when a tree is done growing. It probably would not be the same for every tree according to the wiki, but I am not sure where to find the info for every tree. It's possible to check if a tree is being blocked using plant.plant_tree_info.plant_tree_tile.blocked. Once I understand how trunk branching works, it should be possible to take blocking into account.

Also, counting trunks is weird. Birch has a max trunk height of 8, but there is one with a trunk height of 10. Same with alder. Birch and alder have trunk branchings of 0, so perhaps trees can have 2 extra trunks acting like end points rather than contributing to the height.

Plus, willow's max trunk diameter is 1, but there is a willow which appears to have a trunk diameter of 3. This appears to be due to a trunk branching of 2. I wonder if this means a willow could have trunks in a 25 tile square, giving the appearance of having a trunk diameter of 5. There is a larch that kind of confirms this, and it appears the branching can happen every z-level, increasing the diameter of the branching area. It would probably be easier just to check that a tree has reached max height + 2 than to figure out how branching works.

As for the other plugin I want to create that will replace worn clothes. It appears that worn clothes getWear value go from 1 to 4, at the least, based on code, and 0 means no wear. The code does not show whether there is an upper limit, but that 4 and 5 would have the same wear label. At what point is worn clothing scrapped by a dwarf?
Title: Re: DFHack 0.47.05-r2
Post by: lethosor on July 09, 2021, 09:38:28 pm
New release! https://github.com/DFHack/dfhack/releases/tag/0.47.05-r2

I have a bit of catching up to do - I'll reply to a couple questions in a separate post.
Title: Re: DFHack 0.47.05-r1
Post by: lethosor on July 09, 2021, 09:58:23 pm
As a starting point for the first one, here's one of my scripts intended to control which trees to cut, sparing one of each resource providing kind of tree, selecting the ones closest to the center of the embark. It skips cavern trees, and deals with elven logging restrictions.
Code: [Select]
<snip>
                  if trees_designated < max_trees then
                    cur.designation [x % 16] [y % 16].dig = df.tile_dig_designation.Default
                    cur.flags.designated = true
I would recommend using `dfhack.designations.markPlant()` instead - it does the same thing, but the inverse, `unmarkPlant()`, is significantly more complicated and it's good to use library functions for consistency. This one admittedly seems to be missing from the Lua API docs.

Incidentally, autochop already uses these library functions, so there wouldn't be any change necessary there.

Or you could point me to a list of all the possible methods or objects within "unit", because I can't find it.

The source of the structure descriptions we use is in XML form at https://github.com/dfhack/df-structures/ - it is a bit tricky to parse if you're unfamiliar with it. The definition for the "unit" type in 0.47.05-r2 starts here: https://github.com/DFHack/df-structures/blob/0.47.05-r2/df.units.xml#L587

As a more interactive alternative, I might suggest gui/gm-editor (https://docs.dfhack.org/en/0.47.05-r2/docs/_auto/gui.html#gui-gm-editor). Running it with a unit selected will give you a UI that lets you navigate all fields of a unit, including sub-structs. There are some other useful features that you can see by pressing "?".

Is there a way to use this struct

Code: [Select]
  struct DFHACK_EXPORT plant_tree_info {
<snip>
to find the number of logs that the tree will produce?
This recent script by Bumber (http://www.bay12forums.com/smf/index.php?topic=164123.msg8290143#msg8290143) might be useful as a reference to figure out how to interpret and count the number of tiles in the structure. I don't know if the number of logs produced by a tree corresponds exactly to anything (e.g. the number of trunk tiles), but there's a chance it does, or that it's close.

Edit: it seems that you all have figured out that it's more complicated. I mainly just wanted to track down this script again. Carry on!

How do you go about debugging a plugin that crashes? So far, I've been commenting code out, but I would like a faster way.
That depends - what platform are you developing on?

For instance, https://docs.dfhack.org/en/0.47.05-r2/docs/Memory-research.html#gdb (perhaps not the best page for this) explains how to use GDB on Linux.
Title: Re: DFHack 0.47.05-r2
Post by: PatrikLundell on July 10, 2021, 02:33:47 am
:
As for the other plugin I want to create that will replace worn clothes. It appears that worn clothes getWear value go from 1 to 4, at the least, based on code, and 0 means no wear. The code does not show whether there is an upper limit, but that 4 and 5 would have the same wear label. At what point is worn clothing scrapped by a dwarf?
I don't think dorf clothing behavior has been identified in detail. On the top level, dorfs tend to replace clothing worn down to the 'x' level (which I expect to be 1) as soon as there's a replacement available. If there isn't a replacement, they'll wear clothes until they rot off their bodies and are destroyed, resulting in a bad thought (I suspect that might be level 5, which, in that case, would exist only very briefly until the clothing item is destroyed by a DF cleanup sweep).

However, dorfs are often caught hoarding pristine clothing, including masterworks ones, so there's something going on on top of wear. Some or all dorfs probably replace clothes of a lower quality with higher quality ones, and some probably replace clothes of the same quality but with a lower value with more valuable ones. I don't think this behavior has been researched, but I wouldn't be surprised if personality traits affect how much "better" a piece of clothing would have to be to be claimed.
Title: Re: DFHack 0.47.05-r2
Post by: FantasticDorf on July 10, 2021, 05:51:36 am
:
As for the other plugin I want to create that will replace worn clothes. It appears that worn clothes getWear value go from 1 to 4, at the least, based on code, and 0 means no wear. The code does not show whether there is an upper limit, but that 4 and 5 would have the same wear label. At what point is worn clothing scrapped by a dwarf?
I don't think dorf clothing behavior has been identified in detail. On the top level, dorfs tend to replace clothing worn down to the 'x' level (which I expect to be 1) as soon as there's a replacement available. If there isn't a replacement, they'll wear clothes until they rot off their bodies and are destroyed, resulting in a bad thought (I suspect that might be level 5, which, in that case, would exist only very briefly until the clothing item is destroyed by a DF cleanup sweep).

However, dorfs are often caught hoarding pristine clothing, including masterworks ones, so there's something going on on top of wear. Some or all dorfs probably replace clothes of a lower quality with higher quality ones, and some probably replace clothes of the same quality but with a lower value with more valuable ones. I don't think this behavior has been researched, but I wouldn't be surprised if personality traits affect how much "better" a piece of clothing would have to be to be claimed.

The logic is easily presentable through the military screen.

If you simply create a replace-clothes uniform in the military screens composing of a simple trousers, shoes socks etc, dwarves during inactive phases of having no schedule within a active squad will always prioritize to change their clothes for masterwork articles, even if its premature because the military screen always nessecitates the best availible specified 'armor' is used.

There are also instances where preferences for a finished goods object and high amounts of desire to aquire objects often creates a dwarf which weighs themselves down possibly to death with a amount of rings and crowns they wear from interacting with a bin of finished good materials (which each object inside the container is noticed by the dwarf as a wearing candidate/seperate to clothing where every dwarf is meta-aware of the location and quality of clothes to put on related to the military-clothing situation). Normallly dwarf clothes that have become unowned and obsolete due to damage will be dropped in their rooms/stored in cabinets or instantly returned to a designated open armor pile when the totally destroyed threshold is met, i dont know why your dwarves still persist to wear broken clothes unless that open armor pile is just inacessable/not made likely.
Title: Re: DFHack 0.47.05-r2
Post by: PatrikLundell on July 10, 2021, 06:03:35 am
@FantasticDorf: You've made the assumption that the military equipment replacement scheme is the same as the civilian one, which I don't think has been proven.

Dorfs wear clothing items until those rot off when there are no replacements. That situation typically occurs with underwear, as dorfs can't produce them, and the influx from elven caravans and gobbo invaders typically is very insufficient to meet the demand. You'll get the same situation if you try to use a minimalistic clothing production strategy of only producing the minimum number of clothing items required to cover the body, as the unsatisfied clothing layers will be filled with clothing grabbed from invaders as soon as those become available.
Title: Re: DFHack 0.47.05-r1
Post by: Bumber on July 10, 2021, 07:00:53 am
I don't know if the number of logs produced by a tree corresponds exactly to anything (e.g. the number of trunk tiles), but there's a chance it does, or that it's close.

Edit: it seems that you all have figured out that it's more complicated. I mainly just wanted to track down this script again. Carry on!

Logs do correspond exactly to trunk tiles. Mushroom trees only drop 1 log because they use "connection_north" for their caps instead of "trunk" (as seen with my script you linked.)

Figuring out if a tree is fully grown is a separate issue that can't be determined by trunks.

Title: Re: DFHack 0.47.05-r1
Post by: Kat on July 12, 2021, 12:09:25 pm
It's an issue with the script. Looks like you're the first one that's reported it since it broke a year or so ago, so thank you! (It may be a rare case - I don't seem to have a save where I can reproduce the issue easily.)

Here's a fix (https://github.com/DFHack/scripts/commit/2b2967c84697d70eb4dd73c641b8d17767f871e2) that should work. If you can test it out, that'd be great. You can either make the changes manually to hack/scripts/show-unit-syndromes.rb, or replace that file with the new version (https://raw.githubusercontent.com/DFHack/scripts/2b2967c84697d70eb4dd73c641b8d17767f871e2/show-unit-syndromes.rb) (be sure to save the new one with a ".rb" extension and overwrite the existing one).

This fix will also be in the next DFHack release, which is hopefully soon.

Didn't have an earlier save of the game with the cursed unit that caused an error, unfortunately.

Though some other werecreatures and vampires turned up later, and the new script didn't seem to cause any issues, if that's any help.
Title: Re: DFHack 0.47.05-r2
Post by: FantasticDorf on July 12, 2021, 12:22:34 pm
Whats the longest amount of time people have managed to the new run post fort wg script for? We should run a QA test competition.
Title: Re: DFHack 0.47.05-r2
Post by: Bumber on July 13, 2021, 02:29:51 am
Something's off with the map_block_column struct in IDA, at least in my setup:
Spoiler (click to show/hide)

gui/gm-editor browses it fine.

Edit: Never mind. Data was actually a map block, not a column.
Title: Re: DFHack 0.47.05-r2
Post by: Rumrusher on July 13, 2021, 08:31:55 am
Code: [Select]
function sigh2()
for k,v in pairs(df.global.world.squads.all) do
if v.alias == 'DFHACK' then
print(df.global.world.squads.all[k].alias)
for ki,vi in pairs(df.global.world.squads.all[k].positions) do
if df.global.world.squads.all[k].positions[ki].occupant ~= -1 then
local occup=vi.occupant
--local occup=df.global.world.squads.all[k].positions[ki].occupant
--print(occup)
local nemoccup=df.global.world.history.figures[occup].nemesis_id
insertreport(nemoccup)
end
end
end
end
end
--end
function insertreport(nemoccup)
for de,oe in pairs(df.global.world.army_controllers.all) do
if oe.mission_report == nil then else
print ( de,oe.mission_report.title)
for e,o in pairs(df.global.world.armies.all) do
if oe.id == o.controller_id then
print (e)
--return e,o
local forv=df.global.world.armies.all[e].members[0]
df.global.world.armies.all[e].members:insert("#",{new=true,nemesis_id=nemoccup,
stored_fat = forv.stored_fat,
unk_2c= forv.unk_2c,
unk_28= forv.unk_28,
unk_1= forv.unk_1,
unk_30= forv.unk_30,
unk_34= forv.unk_34})
end
end
end
end
end
sigh2()

ok just remember I forgot to post this script for returning squad members here uhh I probably need to test this for R2 when I get around to installing r2
but uhh yeah here's a script for
a, you went around the world in adventure mode as a military commander and recruited folks to the military and want to recall them all back to the player fort.
b, you lost some squad members after unretiring and want them back
c, other... mostly you mess with the other military army scripts I work on and decided to add a kobold that tried to steal some socks to the military and want to return them back to the site.
had to do a safety test on this to see if it work on my copy of Dfhack r1 and I want to advise caution on using this script as I just had lost everyone to the void and the only means of them returning was when I added another person to the squad then sent them out after which I had the chance to insert the missing folks to the new army.
Title: Re: DFHack 0.47.05-r2
Post by: Silverwing235 on July 14, 2021, 05:46:50 am
Not certain where this came from originally - more of a chance subreddit discovery, at that - but it is a spelling error, seemingly having polluted the documentation:

Quote from: ui_advmode
idenfitied several fields

Thoughts?
Title: Re: DFHack 0.47.05-r2
Post by: lethosor on July 14, 2021, 10:51:17 am
Yes, that's a typo. Can't be fixed in the release docs, unfortunately, but it can be fixed on develop.
Title: Re: DFHack 0.47.05-r2
Post by: DwarfStar on July 14, 2021, 01:32:07 pm
Dear DFHack team,

I use this revealdesignated script a lot while playing:

http://www.bay12forums.com/smf/index.php?topic=168607.0

It's the best way I know of to dig out a bunch of warm or damp tiles that I know are safe without endless cancellations. Is there another way to solve that problem? I think this is a better way to eliminate cancellations than disabling them altogether, because you might forget to turn them back on.

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. :)
Title: Re: DFHack 0.47.05-r2
Post by: A_Curious_Cat on July 18, 2021, 12:49:39 am
I've got a question:

(https://i.postimg.cc/g2KDN7RK/Invalid-Vein-Code.png)
Title: Re: DFHack 0.47.05-r2
Post by: Bumber on July 18, 2021, 01:50:50 am
Just discovered that DF uses binary search to find a construction at a tile. It's probable that DF does so in a number of places.

So then: Does DFHack take into account that some DF vectors must be sorted when it inserts new entries into them?

Does a vector insert handle that on its own?
Title: Re: DFHack 0.47.05-r2
Post by: FantasticDorf on July 18, 2021, 03:44:40 am
Just discovered that DF uses binary search to find a construction at a tile. It's probable that DF does so in a number of places.

So then: Does DFHack take into account that some DF vectors must be sorted when it inserts new entries into them?

Does a vector insert handle that on its own?

Isn't this bit of information somewhat related to Quietust's and other's binary-patches for ageing past versions regarding things like weaponstands etc?
Title: Re: DFHack 0.47.05-r2
Post by: lethosor on July 18, 2021, 09:57:49 pm
Just discovered that DF uses binary search to find a construction at a tile. It's probable that DF does so in a number of places.

So then: Does DFHack take into account that some DF vectors must be sorted when it inserts new entries into them?

Does a vector insert handle that on its own?
We're aware. A lot vectors are sorted by a primitive "id" field of each item they contain (or something with a similar name), and "df.some_type.find()" uses this to speed up searches. For insertions, there is "insert_into_vector" (in C++, in MiscUtils.h) and "utils.insert_sorted" in Lua. However, in most cases, IDs cannot be reused, so newly-created items should have the largest ID and can be inserted at the end of vectors without causing problems. 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.

The insert() method of a vector in both languages is the native C++ implementation (or a wrapper), which doesn't handle sorting.
Title: Re: DFHack 0.47.05-r2
Post by: myk on July 19, 2021, 03:22:35 pm
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
Title: Re: DFHack 0.47.05-r2
Post by: myk on July 19, 2021, 04:33:57 pm
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 (https://github.com/DFHack/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
Title: Re: DFHack 0.47.05-r2
Post by: Bumber on July 20, 2021, 06:21:14 pm
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.
Title: Re: DFHack 0.47.05-r2
Post by: myk on July 20, 2021, 07:05:10 pm
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 :-)
Title: Re: DFHack 0.47.05-r2
Post by: lethosor on July 20, 2021, 07:16:08 pm
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).
Title: Re: DFHack 0.47.05-r2
Post by: Bumber on July 21, 2021, 03:12:38 pm
Is there a way to test if everything has been deleted?
Title: Re: DFHack 0.47.05-r2
Post by: myk on July 21, 2021, 07:04:32 pm
On Linux I believe we have valgrind integration, which will report any unfreed memory.
Title: Re: DFHack 0.47.05-r2
Post by: Bumber on July 22, 2021, 12:19:02 pm
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.
Title: Re: DFHack 0.47.05-r2
Post by: lethosor on July 22, 2021, 12:38:22 pm
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.

Quote
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).
Title: Re: DFHack 0.47.05-r2
Post by: Bumber on July 22, 2021, 12:41:55 pm
@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?
Title: Re: DFHack 0.47.05-r2
Post by: lethosor on July 22, 2021, 12:59:40 pm
@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.

Quote
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?
Title: Re: DFHack 0.47.05-r2
Post by: Bumber on July 22, 2021, 04:18:28 pm
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()?
Title: Re: DFHack 0.47.05-r2
Post by: lethosor on July 22, 2021, 06:54:18 pm
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.
Title: Re: DFHack 0.47.05-r2
Post by: PatrikLundell on July 23, 2021, 02:41:56 am
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]).
Title: Re: DFHack 0.47.05-r2
Post by: Erendir on July 23, 2021, 04:46:51 am
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
Quote
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 :)
Title: Re: DFHack 0.47.05-r2
Post by: Bumber on July 23, 2021, 12:27:48 pm
what is the nicest way to check from Lua if a structure has a field?

Code: [Select]
if gref.unit_id != nil and gref.unit_id == some_unit_id thenDoes this work? (I think it might still work if you remove "!= nil", unless it breaks when unit_id == 0.)



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 [...]

I'm just going with the code I disassembled. If it's removed from the map block (or wherever,) it's not done in the plant deconstructor. (Probably while changing the tiletype, which is different between shrubs/saplings and trees.)

The disassembly just uses the "free" syscall on the vector's memory range.



(https://i.postimg.cc/ZK56bDyk/remove-Plants.png)
Beautiful.
Title: Re: DFHack 0.47.05-r2
Post by: Erendir on July 23, 2021, 02:10:10 pm
what is the nicest way to check from Lua if a structure has a field?

Code: [Select]
if gref.unit_id != nil and gref.unit_id == some_unit_id thenDoes this work? (I think it might still work if you remove "!= nil", unless it breaks when unit_id == 0.)


No, it runs into the very same problem: if there is no "unit_id" in the gref, the current implementation of `__index` throws an exception.
Title: Re: DFHack 0.47.05-r2
Post by: lethosor on July 23, 2021, 05:39:57 pm
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
Quote
Cannot read field general_ref_building_holderst.unit_id: not found.
stack traceback:
        [C]: in metamethod '__index'
The usual solution is to use pcall() around a function that just accesses the field, then handle any errors as you see fit. For example:
Code: [Select]
local ok, val = pcall(function()
  return gref.unit_id
end)
Feel free to use better variable names, of course. Docs for pcall() can be found here: https://www.lua.org/manual/5.3/manual.html#pdf-pcall

This might not be very performant. If you run into bottlenecks, I don't believe there is a way to look up what fields a given type has from Lua (although the C++ layer that __index calls definitely has this information), but you could build a table of "type => fields" or "type => has_unit_id_field" mappings yourself, or cache it as you go.

Quote
Ideally, it would just return nil in this case, but this may be too much to ask :)
I think it would be too big of a compatibility break at this point. I think the behavior is mostly for parity with other languages where accessing an invalid field throws an error. Granted, in C++, that error occurs at compile-time, but in Ruby it would occur at runtime like in Lua. There's also the matter of existing fields that can be defined but nil (i.e. null pointers in C++), which the current behavior makes more clear to Lua.
Title: Re: DFHack 0.47.05-r2
Post by: Erendir on July 24, 2021, 03:20:09 am
what is the nicest way to check from Lua if a structure has a field?
I don't believe there is a way to look up what fields a given type has from Lua (although the C++ layer that __index calls definitely has this information), but you could build a table of "type => fields" or "type => has_unit_id_field" mappings yourself, or cache it as you go.
What I was hoping for is access to the same information __index has in some form. Usually, the place to look would be the metatable of the object, but it's a string in this case. But maybe we could have some meta-info in the basic type structures in the df-table, so we can do something like the following.
Code: [Select]
if df[getmetatable(gref)].fields.unit_id then
     print('Has unit_id field!')
end
The getmetatable(gref) is here a string like "general_ref_building_holderst".

And, I mean, we already kind of have this info, just not in a clean way.
Code: [Select]
local function getFieldOrNil(obj, field)
for k,v in pairs(obj) do
if k == field then
return v
end
end
return nil
end

if getFieldOrNil(gref, 'unit_id') == unit.id then
doStuff()
end
Title: Re: DFHack 0.47.05-r2
Post by: Fleeting Frames on July 24, 2021, 05:07:13 am
Yeah, I use something like that alongside building a table for what was already checked
Code: [Select]
(function getFlag(dfvalue, key)
    -- Utility function for safely requesting info from df data
    if not dfvalue or not key then return nil end --pairs crash prevention
    flagtypetable = flagtypetable or {} --memoization so it doesn't iterate through the dfvalue if we've already checked that type of value for given flag
    if flagtypetable[dfvalue._type] and flagtypetable[dfvalue._type][key] then return dfvalue[key] end
    if flagtypetable[dfvalue._type] and flagtypetable[dfvalue._type][key]==false then return nil end
    if not flagtypetable[dfvalue._type] then flagtypetable[dfvalue._type] = {} end
    for akey, avalue in pairs(dfvalue) do
        if akey == key then
            flagtypetable[dfvalue._type][key] = true
            return dfvalue[akey]
        end
    end
    flagtypetable[dfvalue._type][key] = false
end
The first lookup will iterate, further lookups will be just function calls that checks table.

I think there might have been some cases where memoriziation was undesirable, but don't recall them right now.
Title: Re: DFHack 0.47.05-r2
Post by: Erendir on July 24, 2021, 07:22:18 am
Yeah, I use something like that alongside building a table for what was already checked

I think there might have been some cases where memoriziation was undesirable, but don't recall them right now.

Thanks, I'll use this.
Title: Re: DFHack 0.47.05-r2
Post by: Quietust on July 25, 2021, 11:42:02 am
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.
If you're not performing the check very often, you might be better off just calling gref:getUnit() and examining the value returned - if it's a reference to a unit, it will give you a pointer to the unit itself (and you can then check its ID accordingly), and if it's a reference to something else you'll get a null pointer instead.
Title: Re: DFHack 0.47.05-r2
Post by: Erendir on July 25, 2021, 12:19:42 pm
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.
If you're not performing the check very often, you might be better off just calling gref:getUnit() and examining the value returned - if it's a reference to a unit, it will give you a pointer to the unit itself (and you can then check its ID accordingly), and if it's a reference to something else you'll get a null pointer instead.

Well, this is definitely better.

Although it begs the question: how would I discover this function on my own? There is no mention in the Lua API doc (https://docs.dfhack.org/en/stable/docs/Lua%20API.html), getmetatable(gref) is a string, df.general_ref is of no help either.
Title: Re: DFHack 0.47.05-r2
Post by: Quietust on July 25, 2021, 01:57:23 pm
how would I discover this function on my own? There is no mention in the Lua API doc (https://docs.dfhack.org/en/stable/docs/Lua%20API.html), getmetatable(gref) is a string, df.general_ref is of no help either.
You would discover this function by looking at the structure definitions (https://github.com/DFHack/df-structures) - in this specific case, you would have found it here (https://github.com/DFHack/df-structures/blob/master/df.refs.xml#L90).
Title: Re: DFHack 0.47.05-r2
Post by: Erendir on July 26, 2021, 02:16:11 am
how would I discover this function on my own? There is no mention in the Lua API doc (https://docs.dfhack.org/en/stable/docs/Lua%20API.html), getmetatable(gref) is a string, df.general_ref is of no help either.
You would discover this function by looking at the structure definitions (https://github.com/DFHack/df-structures) - in this specific case, you would have found it here (https://github.com/DFHack/df-structures/blob/master/df.refs.xml#L90).

Oh wow, thanks for that - I haven't even thought structure definitions would have functions in them!
Title: Re: DFHack 0.47.05-r2
Post by: Erendir on July 28, 2021, 04:03:07 pm
I have a question about jobs. I have an onJobCompleted-handler with "The job that is passed to this function is a copy". It looks something like this.

Code: [Select]
<job: 000001D919322E30>
id                      = 37238
list_link               = nil
posting_index           = -1
completion_timer        = 0
unk4                    = 0
flags                   = <job_flags: 000001D919322E5C>
    working                 = true
    by_manager              = true
expire_timer            = 0
recheck_cntdn           = 0
wait_timer              = 0
unk11                   = -1
order_id                = 192

It is not part of the df.global.world.jobs.list and is probably destroyed after the event handler is done. I'd like to convert it to an actual active once again job. Comparing this job with a fresh one, I notice following differences: working is not set (which is trivial to achieve), posting_index is not -1 and also list_link is not nil.

The question is how do I append a job to the df.global.world.jobs.list from Lua correctly and how do I (and should I) find a posting for it?
Title: Re: DFHack 0.47.05-r2
Post by: Atkana on July 29, 2021, 01:35:02 am
The question is how do I append a job to the df.global.world.jobs.list from Lua correctly and how do I (and should I) find a posting for it?
Luckily for you, I've got a job helper script I never finished just sitting around :P

For appending the job, use dfhack's dfhack.job.linkIntoWorld function (see this section (https://docs.dfhack.org/en/stable/docs/Lua%20API.html#job-module) of the docs).

For making a posting, you only need to do that if you want to advertise it as available for a unit to take. If you're manually assigning a unit to the job, you won't need to make a posting. This is the code I was using, but it might not be the best way.
Code: [Select]
-- I don't fully understand how this works, so this might be horribly wrong
-- The DF job assigner needs a job to be in postings for it to automatically be assigned to a unit.
function addJobToPostings(job)
local addedIndex = false
-- Find the first free empty postings to add a job to
for index, posting in ipairs(df.global.world.jobs.postings) do
if posting.job == nil then
-- It's free real estate!
posting.job = job
posting.anon_1 = 0
posting.flags.dead = false

job.posting_index = posting.idx
addedIndex = posting.idx
break
end
end
if addedIndex then
print("Added job " .. job.id .. " to postings as index " .. addedIndex)
else
print("Couldn't find posting slot to add in job " .. job.id)
end

return addedIndex
end
Title: Re: DFHack 0.47.05-r2
Post by: Erendir on July 29, 2021, 02:34:57 am
The question is how do I append a job to the df.global.world.jobs.list from Lua correctly and how do I (and should I) find a posting for it?
Luckily for you, I've got a job helper script I never finished just sitting around :P

For appending the job, use dfhack's dfhack.job.linkIntoWorld function (see this section (https://docs.dfhack.org/en/stable/docs/Lua%20API.html#job-module) of the docs).

For making a posting, you only need to do that if you want to advertise it as available for a unit to take. If you're manually assigning a unit to the job, you won't need to make a posting. This is the code I was using, but it might not be the best way.

Nice, thanks. Did you figure what posting.anon_1 does since you are setting it to 0?

And in the rather unlikely case all postings are in use, can we just create a new one?

Another thing I notice I'm missing for what I have in mind: is there a way to find the building the job in onJobCompleted originated from (if there is any)?
Title: Re: DFHack 0.47.05-r2
Post by: Atkana on July 30, 2021, 02:03:57 am
Nice, thanks. Did you figure what posting.anon_1 does since you are setting it to 0?
I don't think so (?). I likely just copied what I saw happening in regular jobs I was checking and hoped for the best :P The comment in the structs (https://github.com/DFHack/df-structures/blob/master/df.world.xml#L630) says "not saved" - I'm not sure if that means that value is never saved (and so is useless) or if it's supposed to be some flag determining if the job is saved or not (yay ambiguity).

And in the rather unlikely case all postings are in use, can we just create a new one?
Also not sure on that. The game has a lot of postings available, so it's unlikely to run out. I think I had intended at some point to manually create enough jobs in vanilla to fill all the postings just to see what happens (does the game handle that by preventing you from making new jobs?).

Another thing I notice I'm missing for what I have in mind: is there a way to find the building the job in onJobCompleted originated from (if there is any)?
This (https://github.com/DFHack/scripts/blob/master/modtools/reaction-trigger.lua#L75) is what modtools/reaction-trigger does for getting the unit and building from a job. (tl;dr Find the general ref with type of df.general_ref_type.BUILDING_HOLDER, take building_id from it, then use df.building.find(building_id) to get the building.
Title: Re: DFHack 0.47.05-r2
Post by: Erendir on July 30, 2021, 05:06:52 am
Nice, thanks. Did you figure what posting.anon_1 does since you are setting it to 0?
Another thing I notice I'm missing for what I have in mind: is there a way to find the building the job in onJobCompleted originated from (if there is any)?
This (https://github.com/DFHack/scripts/blob/master/modtools/reaction-trigger.lua#L75) is what modtools/reaction-trigger does for getting the unit and building from a job. (tl;dr Find the general ref with type of df.general_ref_type.BUILDING_HOLDER, take building_id from it, then use df.building.find(building_id) to get the building.
Thanks, I somehow completely missed the job.general_refs. But seeing how reaction-trigger does it makes me wonder: is it better to check gref:getType() == df.general_ref_type.BUILDING_HOLDER or building = gref:getBuilding(); if building then?

On another note, the job from eventful.onJobCompleted kept being destroyed resulting in some strange stuff happening (mostly crashes :))) as I kept trying to use it. The fix was making a clone at the very beginning (job = dfhack.job.cloneJobStruct(job)). So, I'm wondering: is this (job being destroyed after leaving the event handler) by design? The job parameter in eventful.onJobCompleted is already a copy, so it feels kind of strange to make yet another copy of it in order to use it. (But it may be actually is by design because of object ownership and stuff -- if that's the case, pretty please put a note about it in the docs)
Title: Re: DFHack 0.47.05-r2
Post by: Quietust on July 30, 2021, 08:24:21 am
is it better to check gref:getType() == df.general_ref_type.BUILDING_HOLDER or building = gref:getBuilding(); if building then?
If you know that you're looking for one specific reference type, it's better to check getType() because that just calls a function which immediately returns an integer, while getBuilding has to perform a binary search through the list of every building in your fortress to find the one to which it refers (which isn't too slow but is definitely slower than checking the reference type).
Title: Re: DFHack 0.47.05-r2
Post by: lethosor on July 31, 2021, 04:15:05 pm
On another note, the job from eventful.onJobCompleted kept being destroyed resulting in some strange stuff happening (mostly crashes :))) as I kept trying to use it. The fix was making a clone at the very beginning (job = dfhack.job.cloneJobStruct(job)). So, I'm wondering: is this (job being destroyed after leaving the event handler) by design? The job parameter in eventful.onJobCompleted is already a copy, so it feels kind of strange to make yet another copy of it in order to use it. (But it may be actually is by design because of object ownership and stuff -- if that's the case, pretty please put a note about it in the docs)
Did you have to make a copy of the job to use it safely inside the event handler, or after the event handler returned? Relying on the latter is generally not safe (not limited to this case) because the copy of the job is destroyed after the handler returns, and usually results in a crash more often in cases where you know the object you're dealing with is about to be deleted (as is the case with jobs that have completed). I'm not opposed to adding a note about it in the docs, but it's not necessarily specific to this event. If you are accessing the job long after it has been destroyed, I might suggest only making a copy of the data you need, as opposed to everything that's part of the job - that way, you don't need to worry about freeing your copy of the job.
Title: Re: DFHack 0.47.05-r2
Post by: Erendir on August 01, 2021, 04:31:14 am
On another note, the job from eventful.onJobCompleted kept being destroyed resulting in some strange stuff happening (mostly crashes :))) as I kept trying to use it. The fix was making a clone at the very beginning (job = dfhack.job.cloneJobStruct(job)). So, I'm wondering: is this (job being destroyed after leaving the event handler) by design? The job parameter in eventful.onJobCompleted is already a copy, so it feels kind of strange to make yet another copy of it in order to use it. (But it may be actually is by design because of object ownership and stuff -- if that's the case, pretty please put a note about it in the docs)
Did you have to make a copy of the job to use it safely inside the event handler, or after the event handler returned? Relying on the latter is generally not safe (not limited to this case) because the copy of the job is destroyed after the handler returns, and usually results in a crash more often in cases where you know the object you're dealing with is about to be deleted (as is the case with jobs that have completed). I'm not opposed to adding a note about it in the docs, but it's not necessarily specific to this event.

It was after the event handler returned. Inside everything worked. I think the main source of my confusion is the fact that the job object passed to the event handler already is already a copy (and that I haven't programmed for systems without garbage collector for quite some time). I kind of assumed the original was destroyed but the copy will live on.

Quote
If you are accessing the job long after it has been destroyed, I might suggest only making a copy of the data you need, as opposed to everything that's part of the job - that way, you don't need to worry about freeing your copy of the job.

Does this mean I should free the job created using dfhack.job.cloneJobStruct(job) somehow? What about my case, where this job is linked into the world?
Title: Re: DFHack 0.47.05-r2
Post by: lethosor on August 01, 2021, 11:20:11 pm
It was after the event handler returned. Inside everything worked. I think the main source of my confusion is the fact that the job object passed to the event handler already is already a copy (and that I haven't programmed for systems without garbage collector for quite some time). I kind of assumed the original was destroyed but the copy will live on.
Yeah, the lack of a garbage collector is part of the issue here, as well as the fact that the conventional use-case is for event handlers to be the only users of the cloned job. EventManager can't know whether anything retained a reference to the job copy it made, so the only logical options are to free the job copy immediately after event handlers return, or to never free it (and leak memory), so it chooses the former.

Quote
Does this mean I should free the job created using dfhack.job.cloneJobStruct(job) somehow? What about my case, where this job is linked into the world?
I forgot that you were trying to do that (I thought your own code was doing things with the copy of the job, not DF). In this case, ignore my advice - you will need to create a new job (like with dfhack.job.cloneJobStruct()) and link it back into the world.
Title: Re: DFHack 0.47.05-r2
Post by: Erendir on August 15, 2021, 09:56:38 am
On a somewhat related note. Jobs from work orders seem to be placed to the workshops once a day. I.e. the process is something like this:
 1. a work order is created.
 2. manager gets the job to manage, arrives at his office and validates/activates the work order. It gets the green checkmark in the list.
 3. on the next day (as soon as date changes), actual jobs are created in workshops

Any chance we can call the function doing the job assignments from Lua?
Title: Re: DFHack 0.47.05-r2
Post by: lethosor on August 15, 2021, 08:17:41 pm
Any chance we can call the function doing the job assignments from Lua?
The usual answer to this type of question is "no", unless the function is virtual (which doesn't appear to be the case) and there is actually a single function doing what you want (which isn't guaranteed).

I was about to recommend taking a look at the "prioritize" script from this PR (https://github.com/DFHack/scripts/pull/317), but on second glance, I don't think this would have the effect you're hoping for for manager-created jobs.
Title: Re: DFHack 0.47.05-r2
Post by: myk on August 15, 2021, 09:26:10 pm
Yeah, "prioritize" would help make sure the job gets done promptly once it is assigned to a workshop, but it wouldn't help getting the job to the workshop any faster.
Title: Re: DFHack 0.47.05-r2
Post by: PatrikLundell on August 16, 2021, 01:18:54 am
Scripts can assign jobs to workshops (e.g. to cook with specific ingredients), but then you bypass the whole Management thingy with your own logic.
Title: Re: DFHack 0.47.05-r2
Post by: Bumber on August 17, 2021, 04:55:51 am
Has any research been done on pathing flags? I see add_path_flags in units.xml and unit_path_flags in advmode.xml, but they're just int32's.

If you search for the byte sequence 93F833 in the disassembly, you should end up in a subfunction that seems to be calculating them from unit flags. A ghostly unit carrying items seems to return 0x93F833 for the flags. I'd research them myself, but I'm busy with stuff relating to tree chopping (such as fluid pathing, which just uses an immediate value 0x0 for the pathing flags.)
Title: Re: DFHack 0.47.05-r2
Post by: Quietust on August 17, 2021, 09:23:42 pm
Has any research been done on pathing flags? I see add_path_flags in units.xml and unit_path_flags in advmode.xml, but they're just int32's.

If you search for the byte sequence 93F833 in the disassembly, you should end up in a subfunction that seems to be calculating them from unit flags. A ghostly unit carrying items seems to return 0x93F833 for the flags. I'd research them myself, but I'm busy with stuff relating to tree chopping (such as fluid pathing, which just uses an immediate value 0x0 for the pathing flags.)
I've done some limited research against those path flags in version 0.28.181.40d, and it's quite likely that most of them will still be correct. I've been mainly posting my findings on the DFHack Discord server (in the "#reverse-engineering" channel), but this is what I was able to find:
Code: [Select]
* 0x00000001 - desperate (set when very hungry or thirsty)
* 0x00000002 - reckless (set when insane or when force-moving as an Adventurer)
* 0x00000004 - BuildingDestroyer1 (allow wooden doors)
* 0x00000008 - Lockpicker (allow doors not connected to levers), also set for BuildingDestroyer2
* 0x00000010 - stuck in impassable building
* 0x00000020 - allow unrevealed tiles
* 0x00000040 - can't open doors
* 0x00000080 - unknown, related to doors
* 0x00000100 - creature can learn
* 0x00000200 - unknown
* 0x00000400 - can jump off cliffs (when insane)
* 0x00000800 - can fly
* 0x00001000 - allow shallow water (1-5)
* 0x00002000 - allow deep water (6+)
* 0x00004000 - allow underwater (7 and 3+ water above)
* 0x00008000 - allow shallow magma (1-5)
* 0x00010000 - allow deep magma (6+)
* 0x00020000 - allow under magma (7 and 3+ magma above)
* 0x00040000 - already in water
* 0x00080000 - already in magma
* 0x00100000 - walk on normal land
* 0x00200000 - immobile_land
* 0x00400000 - dwarf, walk_tag equals zero
* 0x00800000 - unknown, tied to an unused "tile liquid" flag
Title: Re: DFHack 0.47.05-r2
Post by: Bumber on August 18, 2021, 12:42:56 am
@Quietust

Thanks. For the pathing subfunction I'm looking at:
Code: [Select]
0x4: True causes a check for the material of a hatch to be in range 419d to 618d (both inclusive.) Still BuildingDestroyer1.
0x8: True skips a check for pet_passable on hatch. Still Lockpicker.
0x10: True skips a check for pet_passable on hatch. Still "stuck in impassible building".
0x40: True causes a check for any hatch. Still "can't open doors".

From what little of the path flag code I've looked at:
Can learn is still 0x100.
exit_vehicle1 and exit_vehicle2 from unit_flags3 result in path flag 0x400. Not sure if it shares that with "jump off cliffs" or if that's been moved.
Title: Re: DFHack 0.47.05-r2
Post by: Bumber on August 20, 2021, 06:20:17 am
What's the process for mapping a DF global variable? I found a large global array used in (fluid) pathing. It starts 8 bytes after "agreement_next_id" (on Windows 64-bit, 0.47.05.)

Entries are structs of size 12 (not pointers,) which I'm calling path_tile for now. The struct contains the block x, y, and z (for use with block_index,) then the x%16 and y%16 tile offset, and finally an unknown/unused value (potentially used in other kinds of pathing.) All these are int16_t.

I'm guessing the array has 240000 entries total, since it adds entries at (base of array + 0x15F900), then flip-flops on which part is reading/writing each iteration. There aren't any checks done on the length of the array, it just keeps going until an iteration finishes where it didn't find a tile with a fluid and a path_cost less than world.next_path_cost.

Function I'm looking at is sub_140157F80. Here's where it puts the initial block x into the start of the array:
Code: [Select]
.text:000000014015804E mov     cs:word_1416B1990, ax
Title: Re: DFHack 0.47.05-r2
Post by: Quietust on August 20, 2021, 04:13:20 pm
What's the process for mapping a DF global variable? I found a large global array used in (fluid) pathing. It starts 8 bytes after "agreement_next_id" (on Windows 64-bit, 0.47.05.)

Entries are structs of size 12 (not pointers,) which I'm calling path_tile for now. The struct contains the block x, y, and z (for use with block_index,) then the x%16 and y%16 tile offset, and finally an unknown/unused value (potentially used in other kinds of pathing.) All these are int16_t.

I'm guessing the array has 240000 entries total, since it adds entries at (base of array + 0x15F900), then flip-flops on which part is reading/writing each iteration. There aren't any checks done on the length of the array, it just keeps going until an iteration finishes where it didn't find a tile with a fluid and a path_cost less than world.next_path_cost.

Function I'm looking at is sub_140157F80. Here's where it puts the initial block x into the start of the array:
Code: [Select]
.text:000000014015804E mov     cs:word_1416B1990, ax
The variable you're looking at is named "line", and it's mentioned in the Global Variable Table (which is marked by 0x12345678+0x12345678+0x87654321+0x87654321 and begins at address 0x1410b5040 on Win64).
From what I recall, that array is only used as a temporary buffer for pathfinding calculations, and none of its state ever persists between operations.

If you think there's value in adding it to structures, then we can certainly add it.
Title: Re: DFHack 0.47.05-r2
Post by: Bumber on August 20, 2021, 09:21:45 pm
The variable you're looking at is named "line", and it's mentioned in the Global Variable Table (which is marked by 0x12345678+0x12345678+0x87654321+0x87654321 and begins at address 0x1410b5040 on Win64).
From what I recall, that array is only used as a temporary buffer for pathfinding calculations, and none of its state ever persists between operations.

If you think there's value in adding it to structures, then we can certainly add it.

Adding it would probably be better than creating my own huge array for calculations. On the other hand, Maps::enableBlockUpdates might cause DF to handle everything itself.

Here's some almost properly formatted code of the fluid pathing function:
Spoiler (click to show/hide)

At least I know how it works now, if nothing else.
Title: Re: DFHack 0.47.05-r2
Post by: A_Curious_Cat on August 21, 2021, 11:33:51 pm
Hi!  I’ve been having a few problems with autochop. 

The first problem is that it seems to designate way too many trees for felling.  On one of my previous forts, my stocks screen listed something like 25,000+ logs and my computer ground to a halt for at least five minutes when ever I cursored down to the line for logs.  I checked the autochop dashboard and it said that it was set to keep only a maximum of 100 logs on hand at a time.  Something is obviously going wrong here if autochop is ignoring it’s maximum limit.

The second problem is that, because there are so many trees being felled (and therefore so many logs to be hauled), my dwarves are spending most of their time endlessly hauling logs.  This makes it take an extraordinarily long time to get anything else done (to the point that I think the delays involved have probably been an important factor in the failure of my past several forts).

The third is that, with the trees being felled all over the map, I tend to have dwarves spread out all over the map gathering and hauling logs.  This makes it impossible to call everyone inside and shut the bridge before a large portion of my dwarves are slaughtered by some titan or werecreature.

Any help/advice would be very much appreciated.

Thanks.
Title: Re: DFHack 0.47.05-r2
Post by: Schmaven on August 22, 2021, 12:16:42 am
Hi!  I’ve been having a few problems with autochop.
...

Not real solutions, but you can toggle your wood stockpiles to take only from linked stockpiles.  That would stop dwarves from hauling the logs and the associated troubles with that.  If it's a combination stockpile, you can forbid wood.  Then change it back when you need more logs brought in.

I've also had the lag spike issue with the stocks screen.  Using shift to jump over that line item, or scrolling the other direction in the list can dodge it.
Title: Re: DFHack 0.47.05-r2
Post by: PatrikLundell on August 22, 2021, 02:17:05 am
Reducing the size of the wood stockpile would result in hauling to it only until it gets full. If you're using quantum stockpiles you can have the feeder stockpile use wheelbarrows to restrict the number of haulers (and change it to take from links only when you want the buggers to do something important, as mentioned).
Title: Re: DFHack 0.47.05-r2
Post by: lethosor on August 22, 2021, 03:49:09 pm
Hi!  I’ve been having a few problems with autochop. 

The first problem is that it seems to designate way too many trees for felling.  On one of my previous forts, my stocks screen listed something like 25,000+ logs and my computer ground to a halt for at least five minutes when ever I cursored down to the line for logs.  I checked the autochop dashboard and it said that it was set to keep only a maximum of 100 logs on hand at a time.  Something is obviously going wrong here if autochop is ignoring it’s maximum limit.


I pulled up a test fort and set autochop to a maximum of 10 logs. Autochop did designate every tree for chopping, but as soon as my woodcutter had cut down enough trees, it undesignated every tree again. It seems to check every in-game day, so if you have a lot of woodcutters, this behavior might result in a few too many logs. I let it run for a couple more in-game days and it didn't designate any more trees, so it seems to be working on my end, at least over the short term.

There is a feature request here (https://github.com/DFHack/dfhack/issues/876) to limit the number of trees designated, but it hasn't been completed yet. There is also this one (https://github.com/DFHack/dfhack/issues/1269) for an annual limit on trees chopped (to keep elves happy).

A couple questions:
- How old is this fort?
- What DFHack version are you using? (The version number from running "help" or in the options (Esc) menu is ideal.)
- Do you have enough logs that are accessible? (i.e. not forbidden, in jobs, etc). One possibility I can think of is that if a lot of logs are queued to be placed in a bin, autochop might not consider them as available, and could end up causing more trees to be cut down. The "z"-stocks screen would still show a lot of logs in this case.
Title: Re: DFHack 0.47.05-r2
Post by: myk on August 25, 2021, 03:10:36 pm
I'm thinking of implementing a military uniforms importer/exporter (as per issue #651 (https://github.com/DFHack/dfhack/issues/651)). What other military-related functionality would be useful? That is, if I built a "military" plugin, what would you want it to do?

If the answer is "not much", I'll probably keep it simple and just write a "uniforms" plugin that just does uniform import/export like how the "orders" plugin works for manager orders.
Title: Re: DFHack 0.47.05-r2
Post by: A_Curious_Cat on August 25, 2021, 03:56:33 pm
Hi!  I’ve been having a few problems with autochop. 

The first problem is that it seems to designate way too many trees for felling.  On one of my previous forts, my stocks screen listed something like 25,000+ logs and my computer ground to a halt for at least five minutes when ever I cursored down to the line for logs.  I checked the autochop dashboard and it said that it was set to keep only a maximum of 100 logs on hand at a time.  Something is obviously going wrong here if autochop is ignoring it’s maximum limit.


I pulled up a test fort and set autochop to a maximum of 10 logs. Autochop did designate every tree for chopping, but as soon as my woodcutter had cut down enough trees, it undesignated every tree again. It seems to check every in-game day, so if you have a lot of woodcutters, this behavior might result in a few too many logs. I let it run for a couple more in-game days and it didn't designate any more trees, so it seems to be working on my end, at least over the short term.

There is a feature request here (https://github.com/DFHack/dfhack/issues/876) to limit the number of trees designated, but it hasn't been completed yet. There is also this one (https://github.com/DFHack/dfhack/issues/1269) for an annual limit on trees chopped (to keep elves happy).

A couple questions:
- How old is this fort?
- What DFHack version are you using? (The version number from running "help" or in the options (Esc) menu is ideal.)
- Do you have enough logs that are accessible? (i.e. not forbidden, in jobs, etc). One possibility I can think of is that if a lot of logs are queued to be placed in a bin, autochop might not consider them as available, and could end up causing more trees to be cut down. The "z"-stocks screen would still show a lot of logs in this case.

It was less than 3 years old when it fell.
DFHack 0.47.05-r2
The fort’s been deleted to save space, so I can’t check any more.  I didn’t have any bins.

Edit:  I’m going to see what happens if I make sure that there’s only ever one woodcutter.
Title: Re: DFHack 0.47.05-r2
Post by: DwarfStar on August 25, 2021, 06:54:14 pm
I'm thinking of implementing a military uniforms importer/exporter (as per issue #651 (https://github.com/DFHack/dfhack/issues/651)). What other military-related functionality would be useful? That is, if I built a "military" plugin, what would you want it to do?

If the answer is "not much", I'll probably keep it simple and just write a "uniforms" plugin that just does uniform import/export like how the "orders" plugin works for manager orders.

Not sure if this is the best way to express/handle this, but here's an idea. Could you modify the uniform application (or write an alternate one) so it optionally only changes armor and leaves the weapons alone? The reason is that I usually set the weapon for each unit manually, and applying a uniform erases all those choices. If I could leave the weapon choices in place, the uniform system would be a lot more useful.
Title: Re: DFHack 0.47.05-r2
Post by: myk on August 25, 2021, 08:40:17 pm
It is probably possible to apply a uniform while not touching weapons, but I want to understand a little more about what you're doing. I believe the usual flow is to assign uniforms first, and then specify weapon choices. How exactly are you accustomed to interacting with your military if you are assigning weapons first and then changing the uniform?
Title: Re: DFHack 0.47.05-r2
Post by: Schmaven on August 26, 2021, 07:13:25 pm
It is probably possible to apply a uniform while not touching weapons, but I want to understand a little more about what you're doing. I believe the usual flow is to assign uniforms first, and then specify weapon choices. How exactly are you accustomed to interacting with your military if you are assigning weapons first and then changing the uniform?

I too would find that useful.  I often assign members a weapon of their preferred type, then later being able to change everyone's cloaks around, or add / remove hoods, maybe force downgrade them from steel to bronze to kit out a higher priority squad... All those changes are independent of the weapon I want them to have.
Title: Re: DFHack 0.47.05-r2
Post by: A_Curious_Cat on August 28, 2021, 12:37:21 am
Whelp!  I tried limiting my most recent fort to only one woodcutter.  I set autochop to a minimum of 100 logs, and a maximum of 120 logs (enough to fill up my four 5x6 wood stockpiles).  The fort fell to a major mining disaster, but the logs never went above 130.
Title: Re: DFHack 0.47.05-r2
Post by: ldog on August 28, 2021, 01:47:09 pm
Generally the idea is to create uniforms and then assign them to squads and then tweak individuals.
What other flow is there? I think people are misunderstanding (or maybe I am)
Myk is talking about making a utility so you can define the uniforms by config files instead of having to do them in game every time.
I used to do a steel uniform for every weapon, then I paired it down to 2, individual choice-melee & crossbow.
Right now I'm doing metal instead of steel.
Now I'm leaning towards going back to leather for crossbow.
If I didn't have to make all these uniforms by hand every new embark (enter utility) then I'd likely experiment with all that and more.

I can't see any need to ever have said utility actually try and touch live soldiers in a squad so the requests to ignore weapons seem pointless.
Title: Re: DFHack 0.47.05-r2
Post by: ab9rf on August 28, 2021, 02:55:07 pm
- Do you have enough logs that are accessible? (i.e. not forbidden, in jobs, etc). One possibility I can think of is that if a lot of logs are queued to be placed in a bin, autochop might not consider them as available, and could end up causing more trees to be cut down. The "z"-stocks screen would still show a lot of logs in this case.
I'm pretty sure that logs cannot be placed in bins.

It's possible that the job cancel bug I discovered the other day is involved here. My current test fort, which is running using the new job cancel method, does not exhibit the behavior that is being reported here; rather, it works as expected, autodesignating every tree on the map, and then undesignating them as soon as enough trees are cut down, as expected. But if the jobs are not cancelling properly (as I was seeing in my prior test fort), then it might continue to chop even though autochop tried (but failed) to cancel the jobs.
Title: Re: DFHack 0.47.05-r2
Post by: ldog on August 28, 2021, 03:08:24 pm
- Do you have enough logs that are accessible? (i.e. not forbidden, in jobs, etc). One possibility I can think of is that if a lot of logs are queued to be placed in a bin, autochop might not consider them as available, and could end up causing more trees to be cut down. The "z"-stocks screen would still show a lot of logs in this case.
I'm pretty sure that logs cannot be placed in bins.

It's possible that the job cancel bug I discovered the other day is involved here. My current test fort, which is running using the new job cancel method, does not exhibit the behavior that is being reported here; rather, it works as expected, autodesignating every tree on the map, and then undesignating them as soon as enough trees are cut down, as expected. But if the jobs are not cancelling properly (as I was seeing in my prior test fort), then it might continue to chop even though autochop tried (but failed) to cancel the jobs.

Please tell me it still leaves manually designated trees alone.
Title: Re: DFHack 0.47.05-r2
Post by: lethosor on August 28, 2021, 03:18:19 pm
Please tell me it still leaves manually designated trees alone.
As far as I can tell, autochop has never left manually designated trees alone. The point of the plugin is that it controls when trees get cut down, so it will designate or undesignate them as appropriate. ab9rf's work isn't changing that.

However, you can configure trees to be ignored (via burrows or disabling e.g. fruit trees in autochop settings), and those restrictions apply to both designating and undesignating trees.
Title: Re: DFHack 0.47.05-r2
Post by: ldog on August 28, 2021, 03:49:12 pm
Please tell me it still leaves manually designated trees alone.
As far as I can tell, autochop has never left manually designated trees alone. The point of the plugin is that it controls when trees get cut down, so it will designate or undesignate them as appropriate. ab9rf's work isn't changing that.

However, you can configure trees to be ignored (via burrows or disabling e.g. fruit trees in autochop settings), and those restrictions apply to both designating and undesignating trees.

Hmmm...I coulda swore it still left them. Dreamfort designates some trees for cutting, and then I usually throw in a few extra's I want done, and I tend to have autochop on. Possibly because I usually have more than the threshold at that point autochop doesn't activate?

Consider it a feature request then :)
Title: Re: DFHack 0.47.05-r2
Post by: Bumber on August 30, 2021, 03:15:21 pm
What's the deal with this syntax?
Code: [Select]
movzx   eax, ds:(byte_7FF67649E388 - 7FF676350000h)[rdx+rax]
mov     ecx, ds:(off_7FF67649E380 - 7FF676350000h)[rdx+rax*4]

Using IDA disassembler, where 7FF676350000h (and value in rdx) is the address of hInstance, byte_7FF67649E388 is the indirect table, and off_7FF67649E380 is the jump table.

I know "ds" is "data segment", but not why that expression is in the parentheses.

Is it starting at address 14E380h, then offsetting by rdx (7FF676350000h, resulting in byte_7FF67649E388 again,) then adding rax to that and moving the value there into eax? (With that value being an index for off_7FF67649E380?) Are my assumptions correct?

Why wouldn't it be something like "movzx eax, ds:(byte_7FF67649E388)[rax]" instead?
Title: Re: DFHack 0.47.05-r2
Post by: Quietust on August 30, 2021, 06:41:55 pm
Is it starting at address 14E380h, then offsetting by rdx (7FF676350000h, resulting in byte_7FF67649E388 again,) then adding rax to that and moving the value there into eax? (With that value being an index for off_7FF67649E380?) Are my assumptions correct?
Yes, that's exactly what it's doing - in 64-bit binaries, VC++ implements switch() statement jump tables using 32-bit relative offsets for everything, probably because it makes the code smaller.
Why wouldn't it be something like "movzx eax, ds:(byte_7FF67649E388)[rax]" instead?
Because that would presumably require using a 64-bit absolute address (with fixup), and I'm not sure whether that's actually possible in amd64 assembly.
Title: Re: DFHack 0.47.05-r3
Post by: lethosor on September 04, 2021, 02:11:34 pm
New release! https://github.com/DFHack/dfhack/releases/tag/0.47.05-r3

Several new tools in this one, including dig-now and build-now. Try them out and let us know how they work!
Title: Re: DFHack 0.47.05-r3
Post by: ldog on September 07, 2021, 10:51:43 am
Does anyone know a way to make a pet not a pet?
I tried poking through gm-edit but I can't find anything obvious.
I absolutely despise livestock as pets, normally I teleport them into magma, but I'm looking for a "kinder, gentler" approach (and more meat).
Title: Re: DFHack 0.47.05-r3
Post by: Rumrusher on September 08, 2021, 03:31:55 am
Does anyone know a way to make a pet not a pet?
I tried poking through gm-edit but I can't find anything obvious.
I absolutely despise livestock as pets, normally I teleport them into magma, but I'm looking for a "kinder, gentler" approach (and more meat).
you could just force the slaughtering of the pet with dfhack by messing with the creature's unit flags to set to slaughter if you're already tossing them into magma.

Code: [Select]
function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end

function getCreatureAtPos(x,y,z) -- gets the creature index @ x,y,z coord
--local x,y,z=getxyz() --get 'X' coords
local vector=df.global.world.units.all -- load all creatures
for i = 0, #vector-1 do -- look into all creatures offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==x and cy==y and cz==z then --compare them
return vector[i] --return index
end
end
--print("Creature not found!")
return nil

end

function Butcherunit(unit)
if unit==nil then
unit=getCreatureAtPos(getxyz())
end
if unit==nil then
error("Failed to Heal unit. Unit not selected/valid")
end
unit.flags2.slaughter = true
unit.flags1.tame = true

though this set of functions if you covert them into a lua script will require looking at the pet to target them for butchery also probably might also lead to butchery of say anyone you aim this at like sapient folks.
Title: Re: DFHack 0.47.05-r3
Post by: ldog on September 08, 2021, 07:31:42 am
Does anyone know a way to make a pet not a pet?
I tried poking through gm-edit but I can't find anything obvious.
I absolutely despise livestock as pets, normally I teleport them into magma, but I'm looking for a "kinder, gentler" approach (and more meat).
you could just force the slaughtering of the pet with dfhack by messing with the creature's unit flags to set to slaughter if you're already tossing them into magma.

Code: [Select]
function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end

function getCreatureAtPos(x,y,z) -- gets the creature index @ x,y,z coord
--local x,y,z=getxyz() --get 'X' coords
local vector=df.global.world.units.all -- load all creatures
for i = 0, #vector-1 do -- look into all creatures offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==x and cy==y and cz==z then --compare them
return vector[i] --return index
end
end
--print("Creature not found!")
return nil

end

function Butcherunit(unit)
if unit==nil then
unit=getCreatureAtPos(getxyz())
end
if unit==nil then
error("Failed to Heal unit. Unit not selected/valid")
end
unit.flags2.slaughter = true
unit.flags1.tame = true
though this set of functions if you covert them into a lua script will require looking at the pet to target them for butchery

That works! Thanks!
also probably might also lead to butchery of say anyone you aim this at like sapient folks.

Added bonus!
Title: Re: DFHack 0.47.05-r3
Post by: ldog on September 08, 2021, 11:27:52 am
Setting the slaughter flag isn't enough :(
I've tried removing important historical figure too. No go. Need to find the pet flag and remove it.
Aha! I found it, relationship_ids, pet, set to -1

Title: Re: DFHack 0.47.05-r3
Post by: Quietust on September 08, 2021, 12:56:18 pm
Setting the slaughter flag isn't enough :(
I've tried removing important historical figure too. No go. Need to find the pet flag and remove it.
Aha! I found it, relationship_ids, pet, set to -1
You might also want to check for `histfig_hf_link_pet_ownerst` records and remove them, otherwise the owner is likely to get an unhappy thought about losing a pet.
Title: Re: DFHack 0.47.05-r3
Post by: ldog on September 08, 2021, 01:46:56 pm
Setting the slaughter flag isn't enough :(
I've tried removing important historical figure too. No go. Need to find the pet flag and remove it.
Aha! I found it, relationship_ids, pet, set to -1
You might also want to check for `histfig_hf_link_pet_ownerst` records and remove them, otherwise the owner is likely to get an unhappy thought about losing a pet.

Thanks!
Title: Re: DFHack 0.47.05-r3
Post by: Bumber on September 13, 2021, 07:35:00 pm
Figured it's worth posting this here:

DF has a function for getting local time, which it uses in adventure mode to calculate tile temperature_2 and when sleeping until dawn (which infers it's used for the position of the sun as well.)
If I've got it correct, the function is this:
Code: [Select]
int32_t getLocalTime(int16_t region_x) //returns local time in hundredths of an hour
{
if (gametype == DWARF_ARENA || gametype == ADVENTURER_ARENA)
{
return world->arena_settings->time;
}
else
{
int32_t center_displace = region_x - world->world_data->world_width / 2;
return ( (center_displace + cur_year_tick%10 + cur_season_tick*10 + 1200) % 1200 )*2
}
}

If my math is correct, then the time difference from one side of a region to another is:
Code: [Select]
Pocket (17): 0.32 hours
Smaller (33): 0.64 hours
Small (65): 1.28 hours
Medium (129): 2.56 hours
Large (257): 5.12 hours

Any implications from this?
Title: Re: DFHack 0.47.05-r3
Post by: Rose on October 02, 2021, 12:13:57 pm
This does allow us to estimate the size of the DF world
Title: Re: DFHack 0.47.05-r3
Post by: Ziusudra on October 02, 2021, 06:40:02 pm
Oh yeah. So, if a large DF "world" is 481km (https://dwarffortresswiki.org/index.php/DF2014:Tile) across and that is 5.12/24ths of a spherical globe that would give a equatorial circumference of 2,254.6875km - compared to the 40,075.017km of Earth. And that should be equatorial relative radiuses of 358.845km and 6,378.1km.
Title: Re: DFHack 0.47.05-r3
Post by: Clément on October 03, 2021, 05:38:03 am
Is DF world really spherical? Or is it cylindrical?
Title: Re: DFHack 0.47.05-r3
Post by: PatrikLundell on October 03, 2021, 12:25:13 pm
DF's world is currently rectangular, although it could be considered to be a rectangular cut from a cylindrical world that has a considerably larger diameter than height. Past discussions indicates that Toady might eventually make the world wrap around horizontally (as a cylinder) with or without vertically (so leaving at the south edge would bring you to the north one), but spheres (and spheroids, lumpy potatoes, etc.) aren't on the table due to all the issues with coordinates not lining up and/or being of differing lengths.
Title: Re: DFHack 0.47.05-r3
Post by: Ziusudra on October 05, 2021, 12:03:11 am
The problem with a cylindrical world is that you'd need some other mechanism to explain seasons and cold "pole(s)" (for those worlds that hav them), as both of those and differences in local time are presumably caused by curvature of the surface. There's already plenty of unnatural/magical things in DF, though.

Hmm, I would guess that DF worlds that do hav poles don't actually model having different seasons at opposite ends - but I also wouldn't be completely surprised if they do. If not, then that some other mechanism is already needed. Edit: Axial tilt of a cylindrical world alone could explain having only a single world-wide season at a time, but not the existence of poles.

(BTW, my math above works for either spherical or cylindrical.)
Title: Re: DFHack 0.47.05-r3
Post by: Bumber on October 05, 2021, 03:28:32 am
Reverse engineering the DF announcement/report code, I noticed it uses '&' as an escape character. "&r" is used to split up an announcement, "&&" results in "&", and any other combination of '&' results in the next char being ignored.

I tried nicknaming a dwarf "&r&r&r&r", and it results in several newlines in announcements. That was with dfhack, but I don't have vanilla handy to test. If it's solely a result of dfhack, then the input needs to be sanitized as & -> &&, and the allowed length checked against that.

Edit: Looks like it's a vanilla bug. Toady can handle it in the announcement code without it affecting nickname length.
Title: Re: DFHack 0.47.05-r3
Post by: Stench Guzman on October 11, 2021, 10:57:23 pm
Is there a script somewhere that can force a state of peace or war between two civilizations?
Title: Re: DFHack 0.47.05-r3
Post by: Rumrusher on October 14, 2021, 10:08:14 pm
Code: ("RaidMove.lua") [Select]
function MobileFort()
local MapCurx=df.global.gview.view.child.child.map_x
local MapCury=df.global.gview.view.child.child.map_y
local Fortsite=df.global.ui.site_id
df.global.world.world_data.sites[Fortsite-1].pos.x=MapCurx
df.global.world.world_data.sites[Fortsite-1].pos.y=MapCury
end

if df.global.gview.view.child.child==nil then
print("this script requires you to be in the raid menu to work")
else
MobileFort()
end

ok so here's a script for bypassing the 'inaccessible mission location' for raiding folks on different islands and continents across oceans and mountains, just be in the raid menu world tab and move the x near the place you want to raid then run the script, after doing refreshing the raid menu by exiting out and entering you should now have access to make a mission on any sites on that land mass.

oh and word for the wise probably best to re-run the script but move your fort back to the original location after you're done making missions.
edit: here's gifs showing off this script in action
(https://i.imgur.com/fpal0Gx.gif)
(https://i.imgur.com/FK4Vbsv.gif)
Title: Re: DFHack 0.47.05-r3
Post by: Uthimienure on October 20, 2021, 07:09:32 pm
I haven't been able to find it searching here or on the DFHack page, is there a script that sorts the artifact lists in-game.

Would be cool to:
- Sort the "L" list
- Sort the "q" list for display furniture
- Sort artifacts in the stock screen
Title: Re: DFHack 0.47.05-r3
Post by: Schmaven on October 24, 2021, 12:28:08 pm
There's probably another way to do it, but I had a human caravan arrive, and all but 1 wagon enter the depot.  The last wagon just sat in the 9 adjacent tiles and no merchants were available to trade.  The command "caravan happy" immediately caused the last wagon to arrive and trading commensed.  The "dir" list is helpful for sure.

Though perhaps there is another issue, the following Dwarven caravan had its last wagon park on a brand new depot, but never arrived.  Just perpetually unloading goods until they left.  "caravan happy" did not fix it for those Dwarven traders. 
Title: Re: DFHack 0.47.05-r3
Post by: Bumber on October 25, 2021, 03:19:50 am
Title: Re: DFHack 0.47.05-r3
Post by: Rumrusher on November 04, 2021, 12:09:36 am
well whip up a script after noticing the mounts are controlled by unit path so now there's a less lethal riding script  that doesn't cause the mount to hop around or skid on the floor.
Code: ('riding-reform.lua') [Select]
function Riding2(unitSource,unitTarget)
local curpos
if df.global.ui_advmode.menu==1 then
curpos=df.global.cursor
else
print ("No cursor located!  You would have slammed into the ground and exploded.")
return
end
unitSource.path.dest.x=curpos.x
unitSource.path.dest.y=curpos.y
unitSource.path.dest.z=curpos.z
unitSource.path.goal=209

end
 
unitTarget = curpos
if df.global.world.units.active[0].relationship_ids.RiderMount==nil then
unitSource = df.global.world.units.active[0]
else
for k,v in pairs(df.global.world.units.active) do
if v.id==df.global.world.units.active[0].relationship_ids.RiderMount then
unitSource=v
end
end
end

Riding2(unitSource,unitTarget)
this script works with looking in the direction you want the mount to go and just mashing the wait key as the mount goes in that direction... or get confused and double backs to the starting position...

which I guess makes the previous riding scripts more a mount jump and control the mount like a missile.
Title: Re: DFHack 0.47.05-r3
Post by: ArmokGoB on November 04, 2021, 10:27:39 am
Is there any way to make it so that revealing damp stone doesn't remove designations with DFHack, without using reveal?
Title: Re: DFHack 0.47.05-r3
Post by: Vattic on November 11, 2021, 12:13:42 am
Is there a plugin similar to prospect, but will give me a list of creatures, split into castes, with their population counts for the given tiles?
Title: Re: DFHack 0.47.05-r3
Post by: Bumber on November 11, 2021, 03:18:47 am
Is there any way to make it so that revealing damp stone doesn't remove designations with DFHack, without using reveal?

I don't think it's been done yet:
https://github.com/DFHack/dfhack/issues/1812
Title: Re: DFHack 0.47.05-r3
Post by: Bumber on November 11, 2021, 04:31:47 am
I've finished reverse engineering DF's announcement function into C++ code. I might be able to use this to improve existing DFHack code. (And create yet another announcement function, this one taking a report_init struct as an argument.)

In the function Gui::revealInDwarfmodeMap (https://github.com/DFHack/dfhack/blob/aa7f60530ef56f15de087057966528dd78d9e3dc/library/modules/Gui.cpp#L1706), while loops are used:
Code: [Select]
while (*window_x + w < pos.x+5) *window_x += 10;
while (*window_y + h < pos.y+5) *window_y += 10;
while (*window_x + 5 > pos.x) *window_x -= 10;
while (*window_y + 5 > pos.y) *window_y -= 10;

DF uses something like:
Code: [Select]
if (*window_x < (pos.x + 5 - w))
*window_x += ((pos.x + 5 - w) - *window_x - 1)/10*10 + 10;
if (*window_y < (pos.y + 5 - h))
*window_y += ((pos.y + 5 - h) - *window_y - 1)/10*10 + 10;
if (*window_x > (pos.x - 5))
*window_x -= (*window_x - (pos.x - 5) - 1)/10*10 + 10;
if (*window_y > (pos.y - 5))
*window_y -= (*window_y - (pos.y - 5) - 1)/10*10 + 10;

Is there a way to clean that up some more? Not sure if the -1 is part of a flooring operation, or what.

Also, the bool "center" of the function might correspond to a check for "report_zoom_type::Unit" in the DF code, if I'm not mistaken.
Title: Re: DFHack 0.47.05-r3
Post by: Uthimienure on November 16, 2021, 02:03:14 pm
I hate asking stupid questions, but in 0.47.05-r1 I'm not able to get these to work.
They're not listed when I do "ls".  Do I need to load them first somehow?

[DFHack]# fix/drop-webs -all
fix/drop-webs is not a recognized command.
[DFHack]# fix/drop-webs
fix/drop-webs is not a recognized command.

[DFHack]# fix-webs -all
fix-webs is not a recognized command.
[DFHack]# drop-webs
drop-webs is not a recognized command.


(edit: Or is this because I'm using r1 ? )
Title: Re: DFHack 0.47.05-r3
Post by: thurin on November 16, 2021, 07:19:04 pm
I hate asking stupid questions, but in 0.47.05-r1 I'm not able to get these to work.
They're not listed when I do "ls".  Do I need to load them first somehow?

[DFHack]# fix/drop-webs -all
fix/drop-webs is not a recognized command.
[DFHack]# fix/drop-webs
fix/drop-webs is not a recognized command.

[DFHack]# fix-webs -all
fix-webs is not a recognized command.
[DFHack]# drop-webs
drop-webs is not a recognized command.


(edit: Or is this because I'm using r1 ? )

fix/drop-webs was added in 0.47.05-r2.  See https://docs.dfhack.org/en/stable/docs/NEWS.html#dfhack-0-47-05-r2 for the release notes.  You'd probably want to head straight to R3 though.
Title: Re: DFHack 0.47.05-r3
Post by: Uthimienure on November 17, 2021, 02:12:10 pm
fix/drop-webs was added in 0.47.05-r2.  See https://docs.dfhack.org/en/stable/docs/NEWS.html#dfhack-0-47-05-r2 for the release notes.  You'd probably want to head straight to R3 though.
Ah, now I see that the stupidity on my part was not looking for release notes in the newer version, and they're right there in the docs!!!
Thanks for answering and getting me on hack-track  :)
Title: Re: DFHack 0.47.05-r3
Post by: Rekov on December 06, 2021, 05:19:57 pm
I did my best to search the docs, but didn't find anything, so I thought I'd just ask:

Is there any script/plugin which can add and remove mud from tiles? Adding mud to facilitate farming, removing mud as a matter of cleaning?

I know you can indirectly add mud with liquids, by spawning water, but this can be problematic in frozen environments.
Title: Re: DFHack 0.47.05-r3
Post by: feelotraveller on December 07, 2021, 07:22:30 am
For cleaning spotclean will remove mud and other contaminants from individual tiles.



Title: Re: DFHack 0.47.05-r3
Post by: Rekov on December 07, 2021, 11:50:14 am
For cleaning spotclean will remove mud and other contaminants from individual tiles.
Fantastic! Thanks.
Title: Re: DFHack 0.47.05-r3
Post by: A_Curious_Cat on December 07, 2021, 12:18:04 pm
Looking at the DFHack docs, it doesn’t appear that there’s any command to add contaminants to a tile.  Perhaps someone should write one?
Title: Re: DFHack 0.47.05-r3
Post by: ldog on December 07, 2021, 08:15:24 pm
I did my best to search the docs, but didn't find anything, so I thought I'd just ask:

Is there any script/plugin which can add and remove mud from tiles? Adding mud to facilitate farming, removing mud as a matter of cleaning?

I know you can indirectly add mud with liquids, by spawning water, but this can be problematic in frozen environments.

The Tiletypes command lets you modify anything and everything about a tile. You should be able to add mud with it.
Title: Re: DFHack 0.47.05-r3
Post by: Ziusudra on December 07, 2021, 10:49:57 pm
The Tiletypes command lets you modify anything and everything about a tile. You should be able to add mud with it.
That might be the one thing you can't do with tiletypes (https://docs.dfhack.org/en/stable/docs/Plugins.html#tiletypes) - there's no MUDDY FLOOR shape, no MUDDY STONE material, no MUDDY special, and no Muddy option.

Though you could just use it to make the FLOOR be SOIL instead of STONE.
Title: Re: DFHack 0.47.05-r3
Post by: Quietust on December 08, 2021, 10:28:12 am
That might be the one thing you can't do with tiletypes (https://docs.dfhack.org/en/stable/docs/Plugins.html#tiletypes) - there's no MUDDY FLOOR shape, no MUDDY STONE material, no MUDDY special, and no Muddy option.
That's because there is no generic "MUDDY" flag (like there was back in 40d) - you have to create a "material_spatter" event with its material set to MUD:NONE (and state set to SOLID), add it to the map block in question, then set the "amount" for the appropriate tile within it.

Unfortunately, there don't appear to be any plugins or scripts which do this, but it shouldn't be too difficult to write a new one - it's mostly the same process as creating new mineral veins (which is supported within at least one plugin).
Title: Re: DFHack 0.47.05-r3
Post by: PatrikLundell on December 09, 2021, 03:55:04 am
Well, the "liquids" script/plugin allows you to drop 1/7 water on tiles, which will cause them to become muddy as the water evaporates, so you can muddy tiles using existing tools even if there's no tool that allows you to modify splatter directly.
Title: Re: DFHack 0.47.05-r3
Post by: Rekov on December 09, 2021, 10:58:15 am
Well, the "liquids" script/plugin allows you to drop 1/7 water on tiles, which will cause them to become muddy as the water evaporates, so you can muddy tiles using existing tools even if there's no tool that allows you to modify splatter directly.
Unless those tiles are in a permanently frozen biome, which was the bizarre use-case which led me to bring up the topic to begin with. It's easy enough to create that 1/7 water with buckets otherwise.
Title: Re: DFHack 0.47.05-r3
Post by: Roses on December 09, 2021, 11:09:10 am
That might be the one thing you can't do with tiletypes (https://docs.dfhack.org/en/stable/docs/Plugins.html#tiletypes) - there's no MUDDY FLOOR shape, no MUDDY STONE material, no MUDDY special, and no Muddy option.
That's because there is no generic "MUDDY" flag (like there was back in 40d) - you have to create a "material_spatter" event with its material set to MUD:NONE (and state set to SOLID), add it to the map block in question, then set the "amount" for the appropriate tile within it.

Unfortunately, there don't appear to be any plugins or scripts which do this, but it shouldn't be too difficult to write a new one - it's mostly the same process as creating new mineral veins (which is supported within at least one plugin).

Out of curiosity, is it the spatter that facilitates farming, or does another flag get set when the spatter is detected?
Title: Re: DFHack 0.47.05-r3
Post by: Quietust on December 09, 2021, 02:10:11 pm
That might be the one thing you can't do with tiletypes (https://docs.dfhack.org/en/stable/docs/Plugins.html#tiletypes) - there's no MUDDY FLOOR shape, no MUDDY STONE material, no MUDDY special, and no Muddy option.
That's because there is no generic "MUDDY" flag (like there was back in 40d) - you have to create a "material_spatter" event with its material set to MUD:NONE (and state set to SOLID), add it to the map block in question, then set the "amount" for the appropriate tile within it.

Unfortunately, there don't appear to be any plugins or scripts which do this, but it shouldn't be too difficult to write a new one - it's mostly the same process as creating new mineral veins (which is supported within at least one plugin).

Out of curiosity, is it the spatter that facilitates farming, or does another flag get set when the spatter is detected?
I haven't checked, but I suspect it's the spatter itself that permits farm plot placement since there's no "mud" flag in tile_occupancy/tile_designation (like there was in 40d and earlier).
Title: Re: DFHack 0.47.05-r3
Post by: Roses on December 09, 2021, 02:31:10 pm
Very interesting. Thank you
Title: Re: DFHack 0.47.05-r3
Post by: Bumber on December 13, 2021, 09:26:04 am
You can mud the entire map by entering
Code: [Select]
:lua df.global.ui.main.mode = df.ui_sidebar_mode.ArenaWeatherand pressing 'm' for "Mud everywhere". :P

(I don't think messing with the temperature does anything outside arena mode.)

Looks like "df.ui_sidebar_mode.ArenaTrees" functions, too. Just need to turn the filter on and off for the tree list to appear. More convenient for creating multiple trees than "gui/create-tree".
Title: Re: DFHack 0.47.05-r3
Post by: Mugh on January 04, 2022, 09:15:58 pm
Is there a way to slow down the passing of time? I wanted to experiment with playing a fortress on a "real time" scale more in line with Adventure Mode's slower day/night cycle.

I was hoping the timestream script could be used for this - it seems to ignore any value lower than 1 though, so I wasn't able to get it to work. Any help would be appreciated!
Title: Re: DFHack 0.47.05-r3
Post by: PatrikLundell on January 05, 2022, 04:12:02 am
Fortress Mode is designed to run at an accelerated rate in order to get things done in a reasonable amount of time (for players outside the extreme outliers), so you can't go below the one tick per tick ratio, but reducing the maximum FPS will slow everything down. Ideally you'd go to 1/72, but that's not an integer, so you'll have to select between 1/50 and 1/100 (i.e. an FPS of 1 or 2).

However, dorfs will still move at a speed of 1/72 and eat, drink, and sleep very rarely as a result of the 1:72 ratio. You're probably better off trying to manipulate Adventure Mode (which probably won't be easy at all) and build the whole Fortress Mode logic yourself on top of the 1:1 time framework.
Title: Re: DFHack 0.47.05-r3
Post by: A_Curious_Cat on January 07, 2022, 08:38:51 pm
I've got a quick question:

Quote from: DFHack
Loading bindings from data/init/interface.txt
New window size: 800x300
Font size: 10x12
Resizing grid to 80x25
Resizing font to 10x12

Resetting textures
Can't load plugin stonesense
DFHack is ready. Have a nice day!
DFHack version 0.47.05-r3 (release) on x86
Type in '?' or 'help' for general help, 'ls' to see all commands.
[DFHack]#

./dfhack: line 89: 18696 Segmentation fault      setarch "$setarch_arch" -R env LD_PRELOAD="$PRELOAD_LIB" ./libs/Dwarf_Fortress "$@"


This is the fifth time DFHack has segfaulted on me in the last 24 hours!
Title: Re: DFHack 0.47.05-r3
Post by: Ziusudra on January 07, 2022, 09:32:52 pm
That's not necessarily a DFHack crash, that line 89 is actually in a script that runs DF - the code that actually seg faulted could be in DF, DFHack, or some library.

Do you know how to find core dumps in your distro?
Title: Re: DFHack 0.47.05-r3
Post by: A_Curious_Cat on January 07, 2022, 09:43:55 pm
That's not necessarily a DFHack crash, that line 89 is actually in a script that runs DF - the code that actually seg faulted could be in DF, DFHack, or some library.

Do you know how to find core dumps in your distro?

I’m on a Debian based distro.  I’ve found some information and I think I’ve just enabled core dumps.  Now to wait and see if it segfaults again…
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: HunterZ on February 03, 2022, 11:56:49 pm
I'm having trouble getting the tailor plugin to work. I've enabled it, and a status check confirms it's enabled, but even after several years ingame it has yet to actually do anything. There is plenty of worn clothing in need of replacement, and a bookkeeper is assigned, with an office. However, no clothing orders are ever placed, nor is any clothing produced. Am I missing a step? The documentation (https://docs.dfhack.org/en/stable/docs/Plugins.html#tailor) doesn't indicate anything more.
I remember reading in the past that bookkeepers, after reaching a certain skill level, basically never go back to update the stockpile records, essentially becoming clairvoyant. If the update records job is never triggered, I suppose the clothing check would not trigger either? However, I cannot confirm this is how bookkeeping works at the moment, the wiki doesn't seem to mention anything like this anymore, even though I could have sworn reading that somewhere at some point.

I really like the idea of the tailor plugin, so I'd love to get it to work!
I seem to be having this problem as well. Has anyone figured out how to get this to work reliably?
Title: Re: DFHack 0.44.12-r3 | 0.47.04-beta1
Post by: HunterZ on February 05, 2022, 01:04:19 pm
I'm having trouble getting the tailor plugin to work. I've enabled it, and a status check confirms it's enabled, but even after several years ingame it has yet to actually do anything. There is plenty of worn clothing in need of replacement, and a bookkeeper is assigned, with an office. However, no clothing orders are ever placed, nor is any clothing produced. Am I missing a step? The documentation (https://docs.dfhack.org/en/stable/docs/Plugins.html#tailor) doesn't indicate anything more.
I remember reading in the past that bookkeepers, after reaching a certain skill level, basically never go back to update the stockpile records, essentially becoming clairvoyant. If the update records job is never triggered, I suppose the clothing check would not trigger either? However, I cannot confirm this is how bookkeeping works at the moment, the wiki doesn't seem to mention anything like this anymore, even though I could have sworn reading that somewhere at some point.

I really like the idea of the tailor plugin, so I'd love to get it to work!
I seem to be having this problem as well. Has anyone figured out how to get this to work reliably?
Update: I had a thought to try increasing bookkeeper accuracy from the default lowest setting to see if it would trigger the tailor plugin. It didn't go well - consistently results in the tailor plugin crashing the game. Created a dfhack ticket: https://github.com/DFHack/dfhack/issues/2006
Title: Re: DFHack 0.47.05-r3
Post by: A_Curious_Cat on March 01, 2022, 07:52:52 pm
I just dropped by to mention that it appears that “enable nestboxes” doesn’t seem to work.  I’ve seen dwarves gather fertilized eggs even with it enabled.  I’m using DFHack 0.47.05-r3.
Title: Re: DFHack 0.47.05-r3
Post by: lethosor on March 02, 2022, 12:14:35 am
I just dropped by to mention that it appears that “enable nestboxes” doesn’t seem to work.  I’ve seen dwarves gather fertilized eggs even with it enabled.  I’m using DFHack 0.47.05-r3.
Can you double-check the output of "plug nestboxes" when this happens?
Title: Re: DFHack 0.47.05-r3
Post by: A_Curious_Cat on March 02, 2022, 12:22:05 am
I just dropped by to mention that it appears that “enable nestboxes” doesn’t seem to work.  I’ve seen dwarves gather fertilized eggs even with it enabled.  I’m using DFHack 0.47.05-r3.
Can you double-check the output of "plug nestboxes" when this happens?

I can try.
Title: Re: DFHack 0.47.05-r3
Post by: doublestrafe on March 02, 2022, 06:06:16 am
Is there documentation somewhere on how to read the output of show-unit-syndromes?
Title: Re: DFHack 0.47.05-r3
Post by: Atkana on March 03, 2022, 03:24:53 am
Is there documentation somewhere on how to read the output of show-unit-syndromes?
The output varies a lot based on all of the effects of each syndrome, so it's hard to give a concise answer that covers everything. Most of the terminology used is straight from the game, so familiarising yourself with the syndrome tokens (http://dwarffortresswiki.org/index.php/DF2014:Syndrome#The_anatomy_of_a_syndrome) will likely explain a lot.

Something not immediately obvious for me when first using the script (which was just now xP) was what the numbers in square brackets represented, so I'll mention them here:
There's also the confusing "###" that you'll sometimes see written at the front of certain effects when you're inspecting a syndrome on someone. It means that the effect currently isn't active because the syndrome hasn't progressed far enough to reach that effect's start point. Why it doesn't just say "[inactive]", I don't know.
Title: Re: DFHack 0.47.05-r3
Post by: doublestrafe on March 03, 2022, 06:15:12 am
Thanks, that's helpful. It's surprising to me how many of the dfhack tools aren't documented or even acknowledged in the dfhack docs.

Quote
- Beast sickness [permanent]
 -  - Bleeding [permanent] (size delays,size dilutes,vascular only,localized) power=100
 -  - Drowsiness [permanent] (size delays,size dilutes) power=100
 -  - ###Fever [332-1059-2434] (size delays,size dilutes) power=100

So when there are three numbers in square brackets, is that related to START/PEAK/END? It still doesn't seem right, because this guy has had the syndrome for months or a year now, so 300 ticks away seems unlikely, and when I first looked at the output months ago I don't remember those numbers being in the hundreds of thousands. And is power equivalent to SEV? The wiki says SEV 1000 is pretty severe, so 100 seems not so bad, which is consistent with my dwarf not bleeding out or starving to death in bed. I've got a kitten with it, too, and it doesn't seem to be affected other than "Urvad Oltarosod, Kitten (Tame) cancels Sleep: In Custody" when I gelded him.
Title: Re: DFHack 0.47.05-r3
Post by: Atkana on March 03, 2022, 07:51:26 am
Quote
- Beast sickness [permanent]
 -  - Bleeding [permanent] (size delays,size dilutes,vascular only,localized) power=100
 -  - Drowsiness [permanent] (size delays,size dilutes) power=100
 -  - ###Fever [332-1059-2434] (size delays,size dilutes) power=100

So when there are three numbers in square brackets, is that related to START/PEAK/END? It still doesn't seem right, because this guy has had the syndrome for months or a year now, so 300 ticks away seems unlikely, and when I first looked at the output months ago I don't remember those numbers being in the hundreds of thousands. And is power equivalent to SEV? The wiki says SEV 1000 is pretty severe, so 100 seems not so bad, which is consistent with my dwarf not bleeding out or starving to death in bed. I've got a kitten with it, too, and it doesn't seem to be affected other than "Urvad Oltarosod, Kitten (Tame) cancels Sleep: In Custody" when I gelded him.
I think I slightly mis-explained what the ### means (oops). They should be showing whenever that effect is inactive, either because the START is yet to be reached, or because the END has been passed. I only mentioned the possibility of it not having yet started, but like in your case, it's likely that the ###s are appearing for the fever effect because that effect's end has long since passed.

Yeah, power is just SEV. SEV is one of those weird things that's hard to actually quantify because it means different things for different effects, and even different things for the same effects depending on how its implemented, and also there isn't any clear documentation on what levels of SEV do what... For example (and I'm just going off old memories, so I could be wrong) the SEV for a CE_FEEL_EMOTION affects the intensity of an emotion, with a SEV of 100 being 100%, and lower SEV potentially downgrading the emotion to a weaker one, or higher upgrading it to a stronger one, based on the emotion. Meanwhile just 1 SEV of CE_DROWSINESS makes a unit grow sleepier at 16 times(?) the normal rate (when the game is working properly, at least)*, and a SEV of 2 will outpace the speed that sleeping recovers tiredness. When tiredness can lead to poor productivity or even insanity, almost any level of SEV seems "pretty severe" when it comes to drowsiness. Don't worry, I'm sure your permanently drowsy guy will do just fine (hopefully the fact that the effect in this instance is diluted by size will make a difference)...

Thanks, that's helpful. It's surprising to me how many of the dfhack tools aren't documented or even acknowledged in the dfhack docs.
Most of the dfhack scripts should be listed in the documentation, like this script in question here (https://docs.dfhack.org/en/stable/docs/_auto/base.html#show-unit-syndromes). I think the main problems with the script is that it doesn't follow the normal dfhack conventions for sending arguments (usually you're supposed to have them lead with a -, e.g. -help), and it's documentation not really explaining what some of the things actually mean (like the ###).

Spoiler: * (click to show/hide)
Title: Re: DFHack 0.47.05-r3
Post by: myk on March 10, 2022, 04:40:14 pm
New release! DFHack-0.47.05-r4 is out!

Lots of improvements to blueprint (https://docs.dfhack.org/en/stable/docs/Plugins.html#blueprint) and quickfort (https://docs.dfhack.org/en/stable/docs/_auto/base.html#quickfort). In particular, quickfort now protects masterwork engravings from destruction and can rotate blueprints, flip them around, and repeat them up and down z-levels. There are some notable additions to the blueprint library (https://docs.dfhack.org/en/stable/docs/guides/quickfort-library-guide.html) as well; there are now blueprints for pump stacks and aquifer water taps (and detailed walkthroughs for how to use them without flooding your fort).

See the full list of improvements (and download the binaries) here: https://github.com/DFHack/dfhack/releases/tag/0.47.05-r4
Title: Re: DFHack 0.47.05-r4
Post by: Rumrusher on March 21, 2022, 12:37:04 pm
(http://cdn.discordapp.com/attachments/302956330304667649/955517229854781541/GodSummoningShowcase.gif)
Code: ('Godsummon.lua') [Select]
local dlg=require("gui.dialogs")
-- ok so this script is made for summoning gods into DF, to make this work you need to nickname someone historical that would form an army.
-- so the best choice would be either another adventurer or adv follower if you want the god to show up after fast traveling or assign the DFCAT nickname on some random peasant you talk to once.
-- going to give a warning about how this script messes with nemesis and probably unstable.
-- so BEST not use this on any important saves you care about and just test this out on an disposable save.
-- oh and the gods you summon won't really talk back if you reply to them.
-- this script uses coding from spawn unit and gui scripting to make it work, don't think this works in fort mode as this was made and tested in adv mode.
-- hopefully you have a better time getting gods to fight each other better than I did.
function deitysummoning()
local Ark={}
for k,v in pairs(df.global.world.history.figures) do
if v.flags.deity==true or v.flags.force==true or v.flags.skeletal_deity==true or v.flags.rotting_deity==true then
BoaName=dfhack.TranslateName(v.name)
table.insert (Ark,{dfhack.TranslateName(v.name).." "..v.name.nickname,nil,v})
end
end
local f=function(Name,C)
  deitysummoning2(C[3])
end
dlg.showListPrompt("pantheon list","Select your deity for summoning",COLOR_WHITE,Ark,f)
end
function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end


local function allocateNewChunk(hist_entity)
  hist_entity.save_file_id = df.global.unit_chunk_next_id
  df.global.unit_chunk_next_id = df.global.unit_chunk_next_id+1
  hist_entity.next_member_idx = 0
  print("allocating chunk:",hist_entity.save_file_id)
end

local function allocateIds(nemesis_record,hist_entity)
  if hist_entity.next_member_idx == 100 then
    allocateNewChunk(hist_entity)
  end
  nemesis_record.save_file_id = hist_entity.save_file_id
  nemesis_record.member_idx = hist_entity.next_member_idx
  hist_entity.next_member_idx = hist_entity.next_member_idx+1
end


function createNemesis(HistfigID)
  local id = df.global.nemesis_next_id
  local nem = df.nemesis_record:new()

  nem.id = id
  nem.flags:resize(31)
  nem.unk10 = -1
  nem.unk11 = -1
  nem.unk12 = -1
  df.global.world.nemesis.all:insert("#",nem)
  df.global.nemesis_next_id = id+1

  nem.save_file_id = -1

  local he
  if civ_id and civ_id ~= -1 then
    he = df.historical_entity.find(civ_id)
    he.nemesis_ids:insert("#",id)
    he.nemesis:insert("#",nem)
    allocateIds(nem,he)
  end
  local he_group
  if group_id and group_id ~= -1 then
    he_group = df.historical_entity.find(group_id)
  end
  if he_group then
    he_group.nemesis_ids:insert("#",id)
    he_group.nemesis:insert("#",nem)
  end
  nem.figure=HistfigID
  nem.figure.nemesis_id = id
  return nem
end


function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end
function getItemAtKPos(x,y,z) -- gets the item index @ x,y,z coord
--local x,y,z=getxyz() --get 'X' coords
local vector=df.global.world.item.all -- load all items
local kickpos=df.global.world.units.active[0].pos
for i = 0, #vector-1 do -- look into all items offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==kickpos.x and cy==kickpos.y and cz==kickpos.z then --compare them
return vector[i] --return index
end
end
--print("item not found!")
return nil

end
function getCreatureAtPos(x,y,z) -- gets the creature index @ x,y,z coord
--local x,y,z=getxyz() --get 'X' coords
local vector=df.global.world.units.all -- load all creatures
for i = 0, #vector-1 do -- look into all creatures offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==x and cy==y and cz==z then --compare them
return vector[i] --return index
end
end
--print("Creature not found!")
return nil

end

function getArmyAtName(Divineslot)
for k,v in pairs(df.global.world.nemesis.all) do
if v.figure.name.nickname=='DFCAT' then
print("Nem",k)
local Cat=df.global.world.armies.all
for k1,v1 in pairs(Cat) do
if v1.members==nil then break else
for Del,ete in pairs(v1.members) do
if ete.nemesis_id==v.id then
print("Army",k1)
return k1
end
end
end
end
end
end
end

function deitysummoning2(HistfigID)
Divineslot=createNemesis(HistfigID)
 local horse=Divineslot
 print('God Nem ID',Divineslot.id)
 print('God Nem.figure ID',Divineslot.figure.id)
 local NeArmy=getArmyAtName()
  df.global.world.armies.all[NeArmy].members:insert("#",{new=true,nemesis_id=horse.id,})
end

deitysummoning()

well here's a script I worked on for a project that imploded mostly from being unable to get two beings to beat the stew out of each other
so this script is made for folks who want to summon the deities of dwarf fortress into their game though they don't really do much these divine beings are the real deal, I guess for the fort mode version you need to nickname someone DFCAT then send them on a mission then while they are on a mission run the script to grab a god then I guess the deity would return seeking asylum and you get a divine being in your fort.


uses for doing this uhh shrugs, I know some gods contain loads of secrets and spells that one probably could coax into writing down if they probably learn how to read and write.
fun interactions of watching someone marry a god and witness DF version of Zeus in play.
 
also like to give a warning this might mess up your saves It does create a new nemesis and forces the game to make a new unit based off the inserted hist fig.

edit: ok so it seems like I miss one line of coding and it corrupted one of the saves mostly the one from the gif. so far hope this fixes the issue.
Title: Re: DFHack 0.47.05-r4
Post by: doublestrafe on March 23, 2022, 04:02:40 am
It would be super helpful if autonick listened for "autonick help" or "autonick -help" instead of just irreversibly running itself when you try to find out the details of what it does. Even erroring out on any argument would be an improvement.
Title: Re: DFHack 0.47.05-r4
Post by: myk on March 25, 2022, 11:22:13 pm
That sounds like a good idea. Could you maybe add that as a feature request at the DFHack issue tracker? https://github.com/DFHack/dfhack/issues
Title: Re: DFHack 0.47.05-r4
Post by: doublestrafe on March 26, 2022, 01:41:20 am
Done. Never used github before, hope I did that right.
Title: Re: DFHack 0.47.05-r4
Post by: myk on March 26, 2022, 09:10:01 am
Done. Never used github before, hope I did that right.
That (https://github.com/DFHack/dfhack/issues/2050) looks good. Thanks!
Title: Re: DFHack 0.47.05-r4
Post by: Su on March 28, 2022, 09:51:15 pm
It would be super helpful if autonick listened for "autonick help" or "autonick -help" instead of just irreversibly running itself when you try to find out the details of what it does. Even erroring out on any argument would be an improvement.

as the author of autonick, i'd like to personally apologize for the inconvenience. it's fixed now.
Title: Re: DFHack 0.47.05-r4
Post by: doublestrafe on March 29, 2022, 04:43:34 am
That is an amazing turnaround time and it's fascinating to see the review process on github. Thanks so much!
Title: Re: DFHack 0.47.05-r4
Post by: Silverwing235 on March 30, 2022, 05:03:21 am
The GUI wrapper for createitem throws an 'unrecognized command' when I poke at it - any help for that? Seems to very much not be working as intended, any how.
Title: Re: DFHack 0.47.05-r4
Post by: Putnam on March 30, 2022, 12:24:17 pm
The GUI wrapper for createitem throws an 'unrecognized command' when I poke at it - any help for that? Seems to very much not be working as intended, any how.

gui/create-item? It's not actually a wrapper around createitem, it does its own thing; I made it as a sort of nethack-ish "wish" thing before it was renamed since it has similar functionality. Keep in mind the hyphen. What does the console look like when it says unrecognized command?
Title: Re: DFHack 0.47.05-r4
Post by: Ziusudra on March 31, 2022, 01:57:46 am
so there's a basic script
Code: [Select]
[DFHack]# create-items
Create first necessity items under the cursor.
...

a plugin
Code: [Select]
[DFHack]# createitem
Usage:
Syntax: createitem <item> <material> [count]
...

and a gui script
Code: [Select]
[DFHack]#  gui/create-item
gui/create-item: A unit needs to be selected to use gui/create-item.
Title: Re: DFHack 0.47.05-r4
Post by: lethosor on March 31, 2022, 02:05:12 am
The GUI wrapper for createitem throws an 'unrecognized command' when I poke at it - any help for that? Seems to very much not be working as intended, any how.
Please give more details. What exact command are you running? What exact output are you getting?
Title: Re: DFHack 0.47.05-r4
Post by: Su on April 01, 2022, 09:52:06 pm
is there a way to only execute a command if a manager has been assigned?
i use

Code: [Select]
repeat -name autoShearCreature -time 14 -timeUnits days -command [ workorder ShearCreature ]

in my onMapLoad.init, but when starting a new fortress i get errors telling me to assign a manager first.

if it's not been done already, i can probably write a script to do it.
Title: Re: DFHack 0.47.05-r4
Post by: myk on April 01, 2022, 11:05:32 pm
It looks like it isn't that hard to determine if you have a manager assigned. This is how workorder itself does it: https://github.com/DFHack/scripts/blob/master/workorder.lua#L144

I'm a little surprised, though, that you'd rather silence the warning that you have no manager assigned. Isn't it a good indication that you've forgotten to assign a manager? Granted that you don't really *need* a manager until your fort reaches 20 citizens, but why put it off?
Title: Re: DFHack 0.47.05-r4
Post by: Su on April 02, 2022, 07:50:15 pm
It looks like it isn't that hard to determine if you have a manager assigned. This is how workorder itself does it: https://github.com/DFHack/scripts/blob/master/workorder.lua#L144

I'm a little surprised, though, that you'd rather silence the warning that you have no manager assigned. Isn't it a good indication that you've forgotten to assign a manager? Granted that you don't really *need* a manager until your fort reaches 20 citizens, but why put it off?

not particularly in this case; i use the manager manually a lot, so forgetting to assign would be rather hard. but even if i were to assign a manager on the first frame possible, i still wouldn't be able to do so before the map loads - not without scripting, at least. but either way, optimising away that particular bit of gameplay would suck out some of the fun for me.

my use case is more working around the vanilla manager's inability to see how many creatures need shearing / milking: once i've assigned a manager i want those jobs to be added to the work orders, but until then it's not a priority, making the warning just an ugly distraction.
Title: Re: DFHack 0.47.05-r4
Post by: Silverwing235 on April 03, 2022, 09:26:49 am
The GUI wrapper for createitem throws an 'unrecognized command' when I poke at it - any help for that? Seems to very much not be working as intended, any how.
Please give more details. What exact command are you running? What exact output are you getting?

With apologies also to
@Putnam, that was in fact a mistype; gui/createitem vs, as was intended, gui/create-item, which latter obviously gives:
Quote
gui/create-item: A unit needs to be selected to use gui/create-item.
  ...being currently in process of supplying a remedy for that.
Title: Re: DFHack 0.47.05-r4
Post by: Putnam on April 04, 2022, 03:30:58 pm
you can use v to do it, or, if you're in adventure mode, the z menu works.
Title: Re: DFHack 0.47.05-r4
Post by: Heretic on April 13, 2022, 05:25:59 am
What is modern analogs of DwarfExplorer?
How can i get info about ingame structure i have access fur making lua script?
Title: Re: DFHack 0.47.05-r4
Post by: myk on April 13, 2022, 08:51:03 am
Is gui/gm-editor what you're looking for? https://docs.dfhack.org/en/stable/docs/_auto/gui.html#gui-gm-editor

There is also the DFHack/dt-structures repository for data structure information in xml format
https://github.com/DFHack/df-structures
Title: Re: DFHack 0.47.05-r4
Post by: Heretic on April 13, 2022, 08:56:56 am
Exactly. Found it myself already, but was about to search smoother alternatives.
Title: Re: DFHack 0.47.05-r4
Post by: Heretic on April 13, 2022, 08:57:24 am
Also, need script for teleporting long distances.
(Wanna visit all squares of the world with single character for data exporting purpose)
Old teleport doesn't seem work.
(Dont generate bugs, just don't TP)
Any help?
Title: Re: DFHack 0.47.05-r4
Post by: Ziusudra on April 13, 2022, 10:14:15 am
questport (https://docs.dfhack.org/en/stable/docs/_auto/base.html#questport) is for teleporting to different world tiles, teleport is for local tiles.
Title: Re: DFHack 0.47.05-r4
Post by: Heretic on April 13, 2022, 10:20:29 am
questport (https://docs.dfhack.org/en/stable/docs/_auto/base.html#questport) is for teleporting to different world tiles, teleport is for local tiles.
Is it possible to use it automaitc, without manually enter Quest screen?
Title: Re: DFHack 0.47.05-r4
Post by: Ziusudra on April 13, 2022, 10:28:34 am
Wanna visit all squares of the world with single character for data exporting purpose
Why? Would reveal-adv-map (https://docs.dfhack.org/en/stable/docs/_auto/base.html#reveal-adv-map) do what you want?
Title: Re: DFHack 0.47.05-r4
Post by: Heretic on April 13, 2022, 10:40:32 am
Only particulary. I want map all map in Isoworld oversized mod. For this i need to
1)TP to global map tile.
2)Wait until Isoworld load data
Size of 3x3 embark size will be mapped automatically.
3)Repeat from point 1. Where are else a lot of little additions to this, but this is basic idea. I need do it fully automatically because it's thousands little jumps to explore all the map.
Title: Re: DFHack 0.47.05-r4
Post by: Heretic on April 13, 2022, 11:29:21 am
One more diffrent question...
How can i give dfhack commands via powershell?
https://docs.dfhack.org/en/stable/docs/Core.html#using-an-os-terminal
dfhack-run etc from this documentation doesn't work for me
Title: Re: DFHack 0.47.05-r4
Post by: lethosor on April 13, 2022, 03:55:57 pm
dfhack-run etc from this documentation doesn't work for me
Can you explain how it "doesn't work"? What command are you trying to run?
Title: Re: DFHack 0.47.05-r4
Post by: A_Curious_Cat on April 13, 2022, 09:17:08 pm
I’m getting a message on startup saying that fortplan was built with r3 and not r4.
Title: Re: DFHack 0.47.05-r4
Post by: lethosor on April 13, 2022, 11:15:34 pm
I’m getting a message on startup saying that fortplan was built with r3 and not r4.
Fortplan was removed in 0.47.05-r4 (https://docs.dfhack.org/en/stable/docs/NEWS.html#dfhack-0-47-05-r4) in favor of quickfort. I'm guessing this message is coming up because you upgraded to r4 by writing over an existing r3 installation, and the fortplan plugin simply does not exist in r4 so it was not overwritten. Our recommended approach to upgrading DFHack (https://docs.dfhack.org/en/stable/docs/Installing.html#upgrading-dfhack) involves deleting the entire hack folder first, which avoids situations like this.

In this case, the message should be harmless. You can ignore it, delete the fortplan plugin from the hack/plugins folder, or follow the linked procedure to obtain a "clean" install of r4. Up to you.
Title: Re: DFHack 0.47.05-r4
Post by: Bumber on April 14, 2022, 01:57:41 am
So, docs/Compile.rst says to use "git clone --recursive https://github.com/DFHack/dfhack". However, GitHub made security changes quite some time ago that require you to go through additional hoops to push your changes back to the GitHub repository. One option involves using "git@github.com:DFHack/dfhack" instead and generating an SSH key.

The guide should probably be updated to give info on this.
Title: Re: DFHack 0.47.05-r4
Post by: Rumrusher on April 14, 2022, 04:41:37 am
Only particulary. I want map all map in Isoworld oversized mod. For this i need to
1)TP to global map tile.
2)Wait until Isoworld load data
Size of 3x3 embark size will be mapped automatically.
3)Repeat from point 1. Where are else a lot of little additions to this, but this is basic idea. I need do it fully automatically because it's thousands little jumps to explore all the map.
ok so what you need to do is write a weird script that connect isoworld load data with moving around the adventurer's army position.
which probably possible but would require messing with
Code: [Select]
df.global.world.armies coding and maybe
Code: [Select]
df.global.ui_advmodebut I don't know how isoworld works and if you need to leave fast travel... if you do then mapping out the ocean locations would be a bit tricky as you can't really fast travel away on an ocean tile and the current fast travel teleport scripts probably need you to be unloaded from the game field
I guess you could use warmist waypoint system and probably my boatcamp script to move across the oceans and scan those regions but that's going off the idea of you needing to exit fast travel otherwise the script would probably be more writing a script macro to move the adventurer's army a set amount of space to save repeated key strokes.
Title: Re: DFHack 0.47.05-r4
Post by: myk on April 14, 2022, 12:30:41 pm
So, docs/Compile.rst says to use "git clone --recursive https://github.com/DFHack/dfhack". However, GitHub made security changes quite some time ago that require you to go through additional hoops to push your changes back to the GitHub repository. One option involves using "git@github.com:DFHack/dfhack" instead and generating an SSH key.

The "git clone https://github.com/DFHack/dfhack.git" format should be just fine for retrieving the code to compile it, which is what Compile.rst is about. It's the "git clone git://github.com/dfhack/dfhack" format that was deprecated (see here (https://github.com/DFHack/scripts/commit/2d7842239435bd189c471008c4f70ff99b6f1a2c) for where we adjusted to this in DFHack).

If you are trying to get changes back into DFHack, https://docs.dfhack.org/en/stable/docs/Contributing.html has info on creating a GitHub account and a fork for development.
Title: Re: DFHack 0.47.05-r4
Post by: lethosor on April 15, 2022, 11:52:19 pm
GitHub did drop password-based auth over HTTPS within the past year (you have to use a token or an alternative to push now) - I'm assuming that's what Bumber is referring to. They also dropped the git:// protocol more recently.

I definitely want to keep HTTPS as the default in Compile.rst for the reasons Myk said - for read-only access, it is the simplest and does not require extra setup steps. If you'd like to update Contributing.rst with instructions on switching to SSH (maybe references to existing GitHub docs?), that would be welcomed.
Title: Re: DFHack 0.47.05-r4
Post by: Heretic on April 16, 2022, 10:54:58 am
Seems like Civilization(actyally, any entity) name via DFhack always empty. Was trying to get civilizations to which armies belong too - but wasn't able get names.
Names of leader working fine.
Any help?
Also, any way to get info about armies non-historic unnamed members?
Title: Re: DFHack 0.47.05-r4
Post by: doublestrafe on April 16, 2022, 03:42:12 pm
Anybody know why autochop might be marking my trees in marker instead of standard? Google is failing me, my d menu is not set to marker, and it's frustratingly intermittent. I had some of the surface designated (to channel) in marker as a building layout scheme, and I thought that might be causing it somehow, but I created a new burrow on a different z-level and did some marking in it, but when I set autochop to that burrow it designated for chopping just fine. And then I set it back to the original burrow and it designated the trees in marker again. At one point I fiddled and fussed with it until it started working correctly, but I couldn't isolate anything I did in particular, and then last night Windows rebooted on me and I lost the changes. Am I missing something obvious?
Title: Re: DFHack 0.47.05-r4
Post by: Atkana on April 18, 2022, 05:35:16 am
What other things are necessary when splitting an item stack using splitStack? Currently when using it (in this case, on an item on the floor) it will create the split item as a phantom item, invisible and uninteractable, though listed if you mouse over the tile with the look menu. I've tried then using dfhack.items.moveToGround in case it needed placing somewhere, but that doesn't seem to fix it.
Title: Re: DFHack 0.47.05-r4
Post by: Quietust on April 18, 2022, 04:44:44 pm
What other things are necessary when splitting an item stack using splitStack? Currently when using it (in this case, on an item on the floor) it will create the split item as a phantom item, invisible and uninteractable, though listed if you mouse over the tile with the look menu. I've tried then using dfhack.items.moveToGround in case it needed placing somewhere, but that doesn't seem to fix it.
Somewhat counterintuitively, dfhack.items.moveToGround only works on items that are properly located somewhere in the world - if they're already in the "detached" state (as they are immediately after splitting a stack), the operation will fail. What you need to do is call the moveToGround(x,y,z) vmethod on the item itself.
Title: Re: DFHack 0.47.05-r4
Post by: Atkana on April 19, 2022, 02:20:20 am
What other things are necessary when splitting an item stack using splitStack? Currently when using it (in this case, on an item on the floor) it will create the split item as a phantom item, invisible and uninteractable, though listed if you mouse over the tile with the look menu. I've tried then using dfhack.items.moveToGround in case it needed placing somewhere, but that doesn't seem to fix it.
Somewhat counterintuitively, dfhack.items.moveToGround only works on items that are properly located somewhere in the world - if they're already in the "detached" state (as they are immediately after splitting a stack), the operation will fail. What you need to do is call the moveToGround(x,y,z) vmethod on the item itself.
Unfortunately, even after changing to use the vmethod version, I'm still having the same problem with phantom items :c
Title: Re: DFHack 0.47.05-r4
Post by: myk on April 23, 2022, 12:21:43 am
Anybody know why autochop might be marking my trees in marker instead of standard?
DF is not very good about clearing flags from tiles, so it is very possible that there are leftover "marker" flags on the surface tiles that are getting in the way. That being said, autochop should really handle this case and ensure the marker flag is off for trees that it designates. Could you file a bug for this at https://github.com/DFHack/dfhack/issues ?
Title: Re: DFHack 0.47.05-r4
Post by: Quietust on April 25, 2022, 04:39:21 pm
What other things are necessary when splitting an item stack using splitStack? Currently when using it (in this case, on an item on the floor) it will create the split item as a phantom item, invisible and uninteractable, though listed if you mouse over the tile with the look menu. I've tried then using dfhack.items.moveToGround in case it needed placing somewhere, but that doesn't seem to fix it.
Somewhat counterintuitively, dfhack.items.moveToGround only works on items that are properly located somewhere in the world - if they're already in the "detached" state (as they are immediately after splitting a stack), the operation will fail. What you need to do is call the moveToGround(x,y,z) vmethod on the item itself.
Unfortunately, even after changing to use the vmethod version, I'm still having the same problem with phantom items :c
Now that I think about it, I'm pretty sure you also need to categorize(true) the item after it's been split.

Also, it looks like moving the item to the ground is only necessary if you specify false for the last parameter - if you specify true, then the newly-split item will be placed in the exact same location as the original item (on the floor, in a container, in a building, or even in another creature's inventory), just like when food items get claimed for eating.
Title: Re: DFHack 0.47.05-r4
Post by: A_Curious_Cat on April 26, 2022, 01:14:37 pm
What other things are necessary when splitting an item stack using splitStack? Currently when using it (in this case, on an item on the floor) it will create the split item as a phantom item, invisible and uninteractable, though listed if you mouse over the tile with the look menu. I've tried then using dfhack.items.moveToGround in case it needed placing somewhere, but that doesn't seem to fix it.
Somewhat counterintuitively, dfhack.items.moveToGround only works on items that are properly located somewhere in the world - if they're already in the "detached" state (as they are immediately after splitting a stack), the operation will fail. What you need to do is call the moveToGround(x,y,z) vmethod on the item itself.
Unfortunately, even after changing to use the vmethod version, I'm still having the same problem with phantom items :c
Now that I think about it, I'm pretty sure you also need to categorize(true) the item after it's been split.

Also, it looks like moving the item to the ground is only necessary if you specify false for the last parameter - if you specify true, then the newly-split item will be placed in the exact same location as the original item (on the floor, in a container, in a building, or even in another creature's inventory), just like when food items get claimed for eating.
Out of curiosity, what does categorize(true) do?  I searched through the DFHack documentation and could find anything about a function with that name.
Title: Re: DFHack 0.47.05-r4
Post by: Quietust on April 26, 2022, 05:41:22 pm
Out of curiosity, what does categorize(true) do?  I searched through the DFHack documentation and could find anything about a function with that name.
It's not part of DFHack, but a virtual method within Dwarf Fortress itself.

If you look at df.global.world.items, you will see a list named "all" and a whole bunch of lists inside "other". What categorize() does is insert references to the item into all of the "other" lists according to the item's properties (and the "true" parameter in particular adds it to the "IN_PLAY" list at the top).

These "other" lists are used primarily for finding job items more quickly - instead of a hungry dwarf having to check every single item in your fortress (including all of the rocks in your mining tunnels), it just needs to look in the "ANY_EDIBLE_RAW" list to find something to eat. In case you're curious, Buildings are "categorized" in the exact same way.

For what it's worth, I just checked the "find food" code (which uses splitStack) in an older DF version and it does immediately call categorize(true) on the newly-split item. Of course, it's also possible the version I'm looking at is too old (which is certainly possible since the version I checked was v0.23.130.23a) and that the current version needs to do more stuff afterwards, but it'll take me a while to find the relevant code in 0.47.05.
Title: Re: DFHack 0.47.05-r4
Post by: A_Curious_Cat on April 26, 2022, 06:11:13 pm
Out of curiosity, what does categorize(true) do?  I searched through the DFHack documentation and could find anything about a function with that name.
It's not part of DFHack, but a virtual method within Dwarf Fortress itself.

If you look at df.global.world.items, you will see a list named "all" and a whole bunch of lists inside "other". What categorize() does is insert references to the item into all of the "other" lists according to the item's properties (and the "true" parameter in particular adds it to the "IN_PLAY" list at the top).

These "other" lists are used primarily for finding job items more quickly - instead of a hungry dwarf having to check every single item in your fortress (including all of the rocks in your mining tunnels), it just needs to look in the "ANY_EDIBLE_RAW" list to find something to eat. In case you're curious, Buildings are "categorized" in the exact same way.

For what it's worth, I just checked the "find food" code (which uses splitStack) in an older DF version and it does immediately call categorize(true) on the newly-split item. Of course, it's also possible the version I'm looking at is too old (which is certainly possible since the version I checked was v0.23.130.23a) and that the current version needs to do more stuff afterwards, but it'll take me a while to find the relevant code in 0.47.05.
Fascinating.  Thanks for the explanation.  I assume I can look at this with gui/gm-editor, right?  If it requires Lua, than I’m currently putting off learning Lua while I try and learn C++ first (I first tried to learn C, but it turned out the book I got was too old.  Then I found a found a good website for learning C++…)
Title: Re: DFHack 0.47.05-r4
Post by: Atkana on April 27, 2022, 08:09:14 am
What other things are necessary when splitting an item stack using splitStack? Currently when using it (in this case, on an item on the floor) it will create the split item as a phantom item, invisible and uninteractable, though listed if you mouse over the tile with the look menu. I've tried then using dfhack.items.moveToGround in case it needed placing somewhere, but that doesn't seem to fix it.
Somewhat counterintuitively, dfhack.items.moveToGround only works on items that are properly located somewhere in the world - if they're already in the "detached" state (as they are immediately after splitting a stack), the operation will fail. What you need to do is call the moveToGround(x,y,z) vmethod on the item itself.
Unfortunately, even after changing to use the vmethod version, I'm still having the same problem with phantom items :c
Now that I think about it, I'm pretty sure you also need to categorize(true) the item after it's been split.

Also, it looks like moving the item to the ground is only necessary if you specify false for the last parameter - if you specify true, then the newly-split item will be placed in the exact same location as the original item (on the floor, in a container, in a building, or even in another creature's inventory), just like when food items get claimed for eating.
That did it - thanks! I could finally release one of the mods I've been sitting on :D

There was a bit of jank I ran into (though managed to avoid): Weirdly the categorized items would disappear completely if splitStack was used with copying contaminants set to false, and while split items usually ended up in the same location as the original item, that didn't happen for items in unit's inventories (in that case I had to use the moveToGround method first before then using a function to work out where the original stack is equipped + dfhack.items.moveToInventory).
Title: Re: DFHack 0.47.05-r4
Post by: Quietust on April 27, 2022, 08:52:54 am
Weirdly the categorized items would disappear completely if splitStack was used with copying contaminants set to false
That flag isn't for copying contaminants - it's for preserving contAINment (i.e. putting it inside the same building, item, or unit inventory as the original item). I suppose "same_location" might've been a better name for that parameter, since even I've misread it in the same way that you did.
Title: Re: DFHack 0.47.05-r4
Post by: Atkana on April 27, 2022, 09:19:03 am
Weirdly the categorized items would disappear completely if splitStack was used with copying contaminants set to false
That flag isn't for copying contaminants - it's for preserving contAINment (i.e. putting it inside the same building, item, or unit inventory as the original item). I suppose "same_location" might've been a better name for that parameter, since even I've misread it in the same way that you did.
Oh whoops, I guess since I'd been making a mod based around contaminants while reading the documentation, I had them on my mind :P That makes more sense.
Title: Re: DFHack 0.47.05-r4
Post by: Deon on April 29, 2022, 06:18:51 pm
Hello, I am trying to understand how to use Eventful.

In the Musket mode, there's a check that is supposed to delete bullets on impact (but doesn't, I cannot figure out why yet).
I tried to test and explicitly delete projectiles by name, it didn't work.

Spoiler (click to show/hide)

To understand it better, I would like to know why is it called like this:
"eventful.onProjItemCheckImpact.musket"

Can someone explain to me what does ".musket" at the end mean in this call?
Title: Re: DFHack 0.47.05-r4
Post by: Putnam on April 29, 2022, 06:32:33 pm
That's just the name of the function. Lua functions are first-class, i.e. they're just variables like anything else. That line is adding a function named musket to the onProjItemCheckImpact table; every function in that table is called when a projectile impacts something.
Title: Re: DFHack 0.47.05-r4
Post by: Deon on April 29, 2022, 07:29:47 pm
Gotcha, so I dont need to register it in some magical place I couldn't find. I was missing the fact that it auto-calls all functions loaded. Thank you, Putnam.
Title: Re: DFHack 0.47.05-r4
Post by: lethosor on April 29, 2022, 09:33:47 pm
Fascinating.  Thanks for the explanation.  I assume I can look at this with gui/gm-editor, right?  If it requires Lua, than I’m currently putting off learning Lua while I try and learn C++ first (I first tried to learn C, but it turned out the book I got was too old.  Then I found a found a good website for learning C++…)
Depends on what "this" is. You can definitely look at df.global.world or other globals (you can actually leave off the "df.global" prefix in gui/gm-editor and the Lua interpreter, so running "gui/gm-editor world" will work, or "gui/gm-editor world.items" if you want to pull up the items collection directly).

Methods, on the other hand, are not easily enumerable from Lua. You can call them, if you know their name, but if you don't know them, you'd need to look up a list in the df-structures XML files. gui/gm-editor also doesn't support calling arbitrary methods.
Title: Re: DFHack 0.47.05-r4
Post by: Bumber on May 01, 2022, 04:10:26 am
GitHub did drop password-based auth over HTTPS within the past year (you have to use a token or an alternative to push now) - I'm assuming that's what Bumber is referring to. They also dropped the git:// protocol more recently.

I definitely want to keep HTTPS as the default in Compile.rst for the reasons Myk said - for read-only access, it is the simplest and does not require extra setup steps. If you'd like to update Contributing.rst with instructions on switching to SSH (maybe references to existing GitHub docs?), that would be welcomed.

Looks like the easiest way is just to create a PAT and use that instead of your password when pushing:
https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token

This doesn't require switching from https.

The relevant documents for SSH are:
https://docs.github.com/en/get-started/getting-started-with-git/managing-remote-repositories
https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent

Those show how to use set-url to switch the remote to SSH, generate the key, and use ssh-agent to tie your key to a passphrase.
Title: Re: DFHack 0.47.05-r4
Post by: myk on May 04, 2022, 11:33:22 pm
DFHack 0.47.05-r5 released!

This release brings improvements to autofarm, quickfort, autochop, autonick, blueprint, and others. There are also many new widgets available for Lua GUI script writers.

Modders! This release includes custom-raw-tokens: a brand new library for reading mod-added tags in the raws. This allows you to write scripts that modify the game when tagged items are used.

Binaries available on the release page (https://github.com/DFHack/dfhack/releases/tag/0.47.05-r5)

Changelog:
Spoiler (click to show/hide)
Title: Re: DFHack 0.47.05-r5
Post by: Rumrusher on May 22, 2022, 04:01:46 pm
(https://cdn.discordapp.com/attachments/302956330304667649/978035769056821338/adv2fort-script-test2.gif)
(https://cdn.discordapp.com/attachments/302956330304667649/978035795963314186/adv2fort-script-test.gif)
don't know why I never tested adding a view to the game but yeah
I think this mini script probably decent enough of a step to get to switching between fort mode and adventure mode.
 and possibly bringing back the old dfhack fort retire, and uhhh give players the means to quicksave in adventure mode.

ok so as I was writing this I got hit with two issues, one being if fort mode side ever unpause you will auto ruin the run which will end the run which could be fixed with a test to see if fort mode is unpaused then re-pausing it.
and if you made a quicksave you pretty much have to do a manual save after that to clean the save state or the game will crash if you try to fast travel.

Code: ("Adv2Fortswap.lua") [Select]
if  dfhack.world.isFortressMode() then
df.global.gview.view.child=df.viewscreen_dungeonmodest:new()
df.global.gview.view.child.parent=df.global.gview.view
df.global.gamemode=1
df.global.gametype=1
else
df.global.gview.view.child=df.viewscreen_dwarfmodest:new()
df.global.gview.view.child.parent=df.global.gview.view
df.global.gamemode=0
df.global.gametype=0
end

so here's the code beware this could lead to some other unstable stuff down the road I haven't tested or found but I think for a fort mode player perspective this should let one just jump into playing anyone if you set the unit up as an adventurer or well unit active 0

(https://cdn.discordapp.com/attachments/302956330304667649/978044094414749706/adv2fort-script-test3.gif)

edit: additional quick test to see how well switching between adv mode and fort mode goes.

extremely experimental adv mode quicksave test which requires use of the previous script to fix the autosaves when you reload.
Code: ("advquicksave.lua") [Select]
-- Makes the game immediately save the state.
--[====[

Adv quicksave
=========
If called in adv mode, makes DF immediately switches to fort mode then saves the game by setting a flag
normally used in seasonal auto-save. then switches back to adv mode big warning the saves that are backup are set to fort mode so probably best run say a mode set script to switch back to adv mode then save the game again as last I check that seems to fix one crash after switching back to adv mode and fast traveling a bit.

]====]

local gui = require("gui")

--luacheck: defclass={run:bool}
QuicksaveOverlay = defclass(QuicksaveOverlay, gui.Screen)

function QuicksaveOverlay:render()
    if not self.run then
        self.run = true
        save()
        self:renderParent()
        self:dismiss()
    end
end

if not dfhack.isMapLoaded() then
    qerror("World and map aren't loaded.")
end
function adv2fort ()
if  dfhack.world.isFortressMode() then
df.global.gview.view.child=df.viewscreen_dungeonmodest:new()
df.global.gview.view.child.parent=df.global.gview.view
df.global.gamemode=1
df.global.gametype=1
else
df.global.gview.view.child=df.viewscreen_dwarfmodest:new()
df.global.gview.view.child.parent=df.global.gview.view
df.global.gamemode=0
df.global.gametype=0
end
end
if not dfhack.world.isFortressMode() then
adv2fort()
end

local ui_main = df.global.ui.main
local flags4 = df.global.d_init.flags4


local function restore_autobackup()
    if ui_main.autosave_request and dfhack.isMapLoaded() then
        dfhack.timeout(10, 'frames', restore_autobackup)
    else
        flags4.AUTOBACKUP = true
    end

end

function save()
    -- Request auto-save
    ui_main.autosave_request = true

    -- And since it will overwrite the backup, disable it temporarily
    if flags4.AUTOBACKUP then
        flags4.AUTOBACKUP = false
        restore_autobackup()
    end

    print 'The game should save the state now.'
end

QuicksaveOverlay():show()
dfhack.timeout(10, 'frames',adv2fort)


edit: ok so went and fix some issues that came up with this script mostly the fort mode side tends to break if you attempt to zoom on a unit, and the solution was I was missing the parent section on the viewscreen open legends had this solved since 2015 and I should have scan that lua script for tips.
so this should probably work for fort mode players who want to switch from fort mode to adv mode then back to fort mode if they don't leave the fort site and also if they assign an unit on field as an adventurer.

there's a tofort script warmist made that would benefit on this update but like I'm currently checking that one out and seeing if there's any more unforeseen errors that comes from using that and making minor tweaks.

oh while I'm here I should probably post the script I use to clear designation spam from using these scripts
Code: ("select-map.lua") [Select]
df.global.ui.main.mode=10
df.global.selection_rect.start_x=0
df.global.selection_rect.start_y=0
df.global.selection_rect.start_z=610
df.global.selection_rect.end_x=-1430
df.global.selection_rect.end_y=900
df.global.selection_rect.end_z=0
df.global.cursor.x=400
df.global.cursor.y=400
df.global.cursor.z=0

this script should select the entire map and let you clear designations with little scrolling as possible... though this will clear previously set designations so probably best to use this for returning to a fort after finishing up or making an adv closet to shove the adv in, to make the designation spam that would pop up from the adventurer's field of view be smaller to deal with and not lead to the entire fort digging up the place.

edit: ok so went back and updated the clear designation script to include the script selecting the clear designation menu so all you need to do is just hit enter after running the script... but also click on the header of the window of DF as any mouse support will mess with the cursor placement.

also here's the current attempt at modifying warmist's tofort script with viewscreen switching here (https://gist.github.com/Rumrusher/5a83f2bc103cc270f9bdf77c1f1dbd06)
should be warned it's unstable to a degree so far in my testing it's possible to at least build on just about any site and any scripts that un-residents the whole town would be advised to be used.

like this one
Code: [Select]
function DeresidentCiv(unit,trgunit)
local adv=df.global.world.units.active[0].civ_id
for k,v in pairs(df.global.world.units.active) do
if v.civ_id==adv then

if v== nil then
error("Invalid creature")
end
v.flags2.resident=false
end
end
return true
end
edit edit: ok so I ended up making two different versions of warmist's tofort(well 8ish this one is 6.0) and this one has the accidental mechanic of letting you keep access to your fort's military and squad while you explore the world in adv mode and switch back into fort mode, setting up means to do Squad level attack commands if you brought along your fort military on the trip or lets you enlist folks on site and command them to fight.

this is still a work in progress as it's potential to say lose progress or crash, or accidentally maroon your citizens in locations.
edit: ok so after some time I think I got most of my concerns with switching between fort mode and adv mode and now probably don't need to run a bunch of extra scripts after running the modified tofort script warmist made
which I updated and added under the title tofort7.lua so all you really need is for going from fort mode to adv mode is that you assign an adventurer first using any bodyswap script.
(https://cdn.discordapp.com/attachments/302956330304667649/987094381775446056/switching-between-adv-and-fort-mode.gif)
edit: ok so uhh went and added another additional tofort modification called tofort8.
Title: Re: DFHack 0.47.05-r5
Post by: myk on May 23, 2022, 08:31:28 pm
Just a public service announcement, we're planning on turning down Ruby support within the next few DFHack releases. If you don't know what this means, then it probably won't affect you at all, and you don't need to worry about it and you can stop reading now : )

For those of you still reading, here's the longer explanation. There are currently two scripting languages supported by DFHack: Lua and Ruby. Lua is (by a large margin) the better supported of the two languages. Most of DFHack's scripts are written in Lua. Some developers have preferred writing scripts in Ruby, and there was enough support for Ruby scripts to modify DF game state and call a subset of the DFHack API. However, the Ruby runtime has become very difficult to maintain and is causing compatibility issues on some systems. The plan is:
1) rewrite DFHack's Ruby scripts in Lua (commands you run on the DFHack prompt won't change)
2) print a warning if a Ruby script is run
3) sometime in the future, remove the Ruby plugin entirely

The warning in (2) should only ever be seen by players who have written their own ruby scripts. We'll keep the warning in place for a while, hopefully giving those players enough time to migrate their scripts to Lua.

If you have any strong objections to this plan, please make your voice heard here or on the GitHub issue (https://github.com/DFHack/dfhack/issues/2081).
Title: Re: DFHack 0.47.05-r5
Post by: catagris on May 27, 2022, 12:18:49 am
I am running into an issue, when I run the command ./dfhack I get the error:
Code: [Select]
env: ‘./libs/Dwarf_Fortress’: No such file or directory
The install directory is
Code: [Select]
/usr/share/games/dwarf-fortress/gamedata
My GCC version is
Code: [Select]
gcc (Debian 10.2.1-6) 10.2.1 20210110
I installed dfhack version
Code: [Select]
dfhack-0.47.05-r5-Linux-64bit-gcc-7.tar.bz2
Thank you for any help
Title: Re: DFHack 0.47.05-r5
Post by: myk on May 27, 2022, 01:21:44 am
This sounds like a symlink problem. In the directory where you run ./dfhack, what is the output of

ls -l . ./libs

? Are there symlinks that point to non-existent directories?
Title: Re: DFHack 0.47.05-r5
Post by: Ziusudra on May 27, 2022, 04:02:12 am
The install directory is
Code: [Select]
/usr/share/games/dwarf-fortress/gamedata
I installed dfhack version
Code: [Select]
dfhack-0.47.05-r5-Linux-64bit-gcc-7.tar.bz2
You can't install DFHack directly onto the Debian DF packages - those packages change the locations of DF's files in ways that DFHack can't find them.

If you want to use DFHack on Debian, you either need to do a manual install (https://www.bay12games.com/dwarves/) of DF in your home and install/run DFHack on that, or find or create a DFHack deb package that somehow accounts for where the DF deb package put the DF files. For example, the experimental DF deb package (https://packages.debian.org/experimental/amd64/dwarf-fortress/filelist) puts the missing file in /usr/lib/games/dwarf-fortress/libs/Dwarf_Fortress, and that /usr/games/dwarf-fortress is probably a script that creates a folder in your home that mimics the default DF folder layout so that DF can find it's files.

Edit: Or use the LinuxDwarfPack (http://www.bay12forums.com/smf/index.php?topic=157712) release deb package (https://github.com/McArcady/lnp-forge/releases/tag/0.47.05-r3) instead - though that's a bit behind, you can find more recent versions here (https://github.com/McArcady/lnp-forge/actions?query=workflow%3A%22Build+LinuxDwarfPack+package%22).
Title: Re: DFHack 0.47.05-r5
Post by: A_Curious_Cat on June 08, 2022, 03:10:25 am
The recent FotF talk about keyboard and mouse support (especially, iirc, about the possibility of removing the ability to move the cursor with the keyboard) has got me wondering…

How will DFHack be affected by the Steam release?
Title: Re: DFHack 0.47.05-r5
Post by: myk on June 08, 2022, 10:25:08 am
It's certainly been on my mind. Most viewscreens will have to be re-reverse engineered. A lot of code interacts with the input system, intercepting keys or feeding keys into the UI. Depending on how the input system is changing, that might all have to get adapted.

Quickfort should work fine for #dig, #build, and #zone blueprints since they modify memory structures directly. #query and #config blueprints do actually send keystrokes, so that might need rework. #place blueprints have a hybrid approach (memory is modified directly to create the stockpiles, but they are configured via the UI), so they'll need some thought too.

We did spend some time preparing for potential toolchain changes (e.g. compiler version), but Toady confirmed that no toolchain changes are planned for the steam release. That will help things go a little faster (if it remains true) since memory layouts are unlikely to change for existing structures.

The short of it is that we won't really know what we have to do until we get our hands on a release binary. I do expect a lot of work verifying the functionality of each and every plugin and script. If functionality is broken in ways that are not easy to fix, we might do a limited release that only includes stuff that works, adding elements back to the release as we adapt them.

In preparation, I've started writing more integration tests for scripts. That will help cut down on the manual testing required. If we do limited releases, the scripts with integration tests will likely get released first since we can be more confident that they will *keep* working as we make other internal changes.
Title: Re: DFHack 0.47.05-r5
Post by: Rumrusher on June 08, 2022, 09:35:00 pm
ok so poking around with the switching between adv mode and fort mode script warmist made years ago, and stumble upon some weird quirk from not filling out the ui.main.fortress_entity and ui.main.fortress_site data.

mostly that if those are still connected to the previous fort site this will connect to the squads and military and nobles from that site.
also the civ id, site id, group id mostly controls who you control on the current site.
so technically it's possible to dfhack switch between groups of different civilians from different civ ids then control them in fort mode.
but also assign them to the military and add them to the main civ that's off site... or assign them to the noble position off site.

though it does feel a bit bittersweet given if I knew about this sooner I could have been interweaving fort mode and adv mode together with dfhack back when warmist originally made the tofort script.

but other than wishful thinking of the past, I ended up tweaking it so the script will check to see if you're on the correct site and assign the correct fortress entity and fortress site to fort mode.
Title: Re: DFHack 0.47.05-r5
Post by: lethosor on June 08, 2022, 10:45:30 pm
The recent FotF talk about keyboard and mouse support (especially, iirc, about the possibility of removing the ability to move the cursor with the keyboard) has got me wondering…

How will DFHack be affected by the Steam release?
If the initial release is Windows-only, that will significantly slow development. We may not be able to make much progress at all until there are releases for other platforms because a lot of us are using Linux, and most of our CI only runs in Linux too.

There was a suggestion that came up on Discord within hours of the FotF post about re-adding the keyboard cursor with a plugin. I think it would be doable - we effectively already support the opposite of this with mousequery. Any tools that rely on the existing keyboard cursor for user input (gui/liquids, gui/teleport, etc.) will probably need to be adjusted to work with the mouse and/or a keyboard cursor plugin.
Title: Re: DFHack 0.47.05-r5
Post by: Quarque on June 11, 2022, 07:46:45 am
Is this the right place to report a bug in the eventful module? If you use the registerReaction(reaction_name,callback) to modify a reaction, it seems that the callback function never receives the 7th argument (call_native).

Can be reproduced with the following script, that should make brewing require water:

Spoiler (click to show/hide)
Title: Re: DFHack 0.47.05-r5
Post by: myk on June 11, 2022, 09:34:50 am
Thanks for bringing this to our attention! It's best to report issues like this on the issue tracker (https://github.com/DFHack/dfhack/issues) so we can assign someone to look into it. That way, you'll also get notified when the issue is fixed!

(Btw I looked at the code, and you're absolutely right. The parameter just isn't being passed)

Actually actually, there are two callbacks, onReactionCompleting, which passes call_native, and onReactionComplete, which does not (because by the time that event fires, the native callback has already been called). Iow, I'll look into this more. It might be a documentation issue.
Title: Re: DFHack 0.47.05-r5
Post by: Quarque on June 11, 2022, 10:03:12 am
Thank you for checking so quickly! I will report the issue on the tracker.
Title: Re: DFHack 0.47.05-r5
Post by: Rumrusher on June 14, 2022, 01:01:45 pm
ok wrote a script that grabs the squad members from your fort and plops them into your adv mode session
though after running into a bunch of roadblocks the rough coding only checks for the df.global.ui.squad data than say scanning through squads and checking his figs being tied to the adventurer.
so the use of this script is for mainly for grabbing an militia commander adventurer and enlisting folks into your fort's military then summoning them to your location, and making it so your fort's militia could show up and be used when you switch over to fort mode with the previously posted modified tofort scripts which sets up doing site invasions.

Code: [Select]
function SummonSquad()
for ks,vs in pairs(df.global.world.armies.all) do
if vs.flags[0]== true  then
if df.global.ui.squads.list~=nil then
for li2,nk2 in pairs (df.global.ui.squads.list) do
for li3,nk3 in pairs (nk2.positions) do
Awombo=df.global.world.nemesis.all[vs.members[0].nemesis_id].figure
if nk3.occupant~=-1 or nk3.occupant==Awombo.id then
wombo=df.global.world.history.figures[nk3.occupant].nemesis_id
Awombo=df.global.world.history.figures[nk3.occupant].nemesis_id
vs.members:insert("#",{new=true,nemesis_id=wombo})
end
end
end
end
end
end
end

Title: Re: DFHack 0.47.05-r5
Post by: myk on June 17, 2022, 11:19:01 pm
I'm thrilled to announce the release of DFHack 0.47.05-r6

Download it from the github release page: https://github.com/DFHack/dfhack/releases/tag/0.47.05-r6

We have some great new visual tools in this release! gui/petitions gives you a scrollable list of your pending (or previous) petitions. Now you no longer have to remember what deity you just agreed to build a temple for : )
(https://user-images.githubusercontent.com/348150/129481445-b030b275-a0f4-417d-a72c-85b40044e5d2.png)

gui/quickfort is a brand new UI for Quickfort. You can preview how your blueprint will be applied in the live game map, position it interactively, and see whether the blueprint will be successfully applied before you apply it.
(https://user-images.githubusercontent.com/977482/174410780-3938cac3-099d-4a69-8218-97a092413457.png)

and gui/quantum is a point and click interface for setting up quantum stockpiles. It will even manage the minecarts for you!
(https://user-images.githubusercontent.com/977482/174410663-21b88659-ac29-41d3-bf6f-589a800f22e0.png)

Full changelog below:

Spoiler (click to show/hide)
Title: Re: DFHack 0.47.05-r6
Post by: Rumrusher on June 20, 2022, 04:55:06 am
(https://cdn.discordapp.com/attachments/302956330304667649/988365188073922560/ok-we-got-something-here.gif)

so exploring viewscreens some more led to realizing oh yeah I could probably get access to adv mode while in the middle of the world generating.

Code: (worldgenadv.lua) [Select]
--thanks warmist for the help on getCurViewscreen
local old_screen=dfhack.gui.getCurViewscreen()
local new_screen=df.viewscreen_setupadventurest:new()
old_screen.child=new_screen
new_screen.parent=old_screen
new_screen.page=2
for k,v in pairs(df.global.world.history.figures) do
if df.global.world.nemesis.all==nil then
df.global.world.nemesis.all:insert("#",{new=true,figure=df.global.world.history.figures[k]})
end
end
for ki,vi in pairs(df.global.world.nemesis.all) do
new_screen.nemesis_ids:insert("#",ki)
end

Code: (worldgenload.lua) [Select]
local old_screen=dfhack.gui.getCurViewscreen()
local new_screen=df.viewscreen_new_regionst:new()
old_screen.child=new_screen
new_screen.parent=old_screen
new_screen.worldgen_paused=true

so this stuff is a bit experimental but if you pause the game then run the worldgen adv script you could shuffle into playing a bunch of random folks from a list then after that if you want to set up adv party members you could use unretire anyone after that as that works once you run worldgen adv.
the second script lets you load back into the world generations that you paused prior note this only works if you were in the middle of generating a world than loading up a post generated world.
Title: Re: DFHack 0.47.05-r6
Post by: myk on June 22, 2022, 07:09:12 pm
When a new DF release comes out, DFHack devs need to spend time adapting to code and behavior changes. This means that we have to go through all our tools and make sure they still work! We need your help figuring out which are the most important DFHack tools to look at first when the Steam release comes out.

If you can, please help us by writing down the DFHack tools you depend on most in this (very short) survey: https://docs.google.com/forms/d/e/1FAIpQLSfXMmRZNi1Fyb5fOsa2W5RC_MTeu9IGucC-PRDLzkn_0r51Lw/viewform

This is the same survey we posted to Reddit (and the DF General Discussion forum here), so if you've already submitted something, thank you! and no need to submit again from here.

Feel free to comment in this thread, but please fill out the survey form too! Those are the responses that we're looking at.

I'll put out a more thorough analysis later, but here's a quick summary of the first 400 responses from Reddit and DF General Discussion:

Dwarf mode players outnumber Adventure mode players by 4:1 (probably no surprise here)

Fewer than 1 in 20 players use mods

The aspects of DFHack that people love the most are:


The greatest requests of DFHack are for more GUI integration and better tool discoverability.

The top 20 DFHack tools that people named (or described accurately enough for me to guess the name) are:


Note that manipulator got the votes for "Dwarf Therapist" since it was clear that many people were uncertain about the difference. Even if manipulator did not get those votes, though, it would still be in the top 20.
Title: Re: DFHack 0.47.05-r6
Post by: myk on June 27, 2022, 12:40:34 pm
The results are in!

I (myk) am one of the DFHack core developers. I created this survey in order to understand what DFHack's users appreciate and need most so we can set development priorities for the future. This survey allowed me to understand how strongly our users feel about particular pain points (spoiler: our users have a lot to say about GUI integration and documentation!).

Overall, there were 470 people who submitted responses. This is more than enough to get some real, statistically significant results. Thank you all for your help! It really means a lot to us!

Q1: "I Play:"
470 responses.

(https://user-images.githubusercontent.com/977482/175793949-2d705800-c924-42db-954b-22af813d40bc.png)

Q1 analysis and opinion
Almost everybody who uses DFHack plays at least fort mode. About a quarter of respondents also play adventure mode. A small percentage play with mods, and most are small personal mods the players themselves have created. Only Squamous's mods (The Long Night, Fall from Grace, etc.) and Masterwork have more than one respondent playing them.

From my point of view as a DFHack developer, this shows that tools that are useful in fort mode will have the most impact. However, adventure mode has a significant presence. Tools specifically for adventure mode will still be appreciated and used.

I note that mods do not have a huge presence right now. This could be because mods and tilesets -- especially the newer, more complete tilesets -- don't play well together, and people would rather keep their tileset than explore a mod that requires them to play in text mode. However, this all might change drastically once DF supports Steam Workshop and mods can be distributed via Steam. Watch this space!

Q2: "I use DFHack to:"
468 responses.

(https://user-images.githubusercontent.com/977482/175794028-4823884b-94af-4be2-905c-c2c5e9a61d15.png)

Q2 analysis and opinion
The top categories all have to do with productivity, toil reduction, and access to information. This is where people are most keenly aware of DFHack's benefits.

These categories are closely followed by bug fixing. Bugfixing happens in the background and is mostly invisible. I was surprised that there were this many people who were aware enough of the bugfixes that they selected this option, though I suspect if people knew the extent of DFHack's bugfixing, the number would be even higher.

Every aspect of DFHack has a significant number of users that care about it, though.

Q3: "What are the DFHack tools that you rely on most?"
306 responses.

There are more than 350 tools in DFHack (including individual bugfixes and tweaks), but only the top 20 are called out here.

Note that these are plugin/script names, not command names. For example, many people wrote `digv` as the tool they use, but it was consolidated in this graph with the other `dig` plugin commands. Also, many people seemed uncertain about what to call the `manipulator` plugin. Many just called it "Dwarf Therapist" or "that DT screen" or "labor spreadsheet". These were all consolidated into the `manipulator` category, even the ones that were clearly referring the the *real* external (non-DFHack) tool named Dwarf Therapist, with the rationale being that "a tool that does labor assignment is important to our users".

(https://user-images.githubusercontent.com/977482/175794838-eeb5672c-9b33-4141-a63c-70647045928f.png)

Q3 analysis and opinion
This is a poll of perception, not actual records of usage, so we must remember that these are not necessarily the most valuable tools, but rather the most valued tools. All the tools listed here are definitely high-value, but the list is not guaranteed to be exhaustive. We will be using the rankings here to identify the "marquee" tools, and we'll combine this list with the rankings in Q2 above to prioritize our work in getting tools ready for the Steam release.

That being said, let's map those tools back to the categories in Q2 and see what we get (note that many tools map to more than one category):


UI improvements and bug fixes are important to users, but I'm not surprised at all that they don't get named (other than search). They are not usually tools that users run directly, so their names are not going to be at the forefront of anyone's minds.

The rest of the tools seem reasonably distributed based on the Q2 orderings, which validates both what users *say* they value and what tools they *actually* value.

I am a tad surprised that the smaller productivity tools like unsuspend and unforbid didn't make the list. I know I use those all the time!

Q4: "What do you wish DFHack would do better?"
176 responses. This is the "user pain points" section. The responses here indicate where DFHack users are feeling frustration.

(https://user-images.githubusercontent.com/977482/175794257-f67993d0-5406-454e-9856-470f61420d7e.png)

Q4 analysis and opinion
The results could not be more clear. DFHack has a lot of great, powerful features, but users are frustrated with not being able to find them and not being able to use them effectively. There is a large call to make DFHack more accessible from the Dwarf Fortress game screen (the GUI). DFHack should be concentrating developer effort to fix these usability issues. Ideas from the community are welcome here!

Q5: "If you could write your own DFHack feature, what would it be?"
161 responses. Here are the areas where users think DFHack could make an impact if we were to develop a new feature. I made up tool names to combine similar ideas from multiple users, which I will explain below. Only ideas that appeared more than once are included in the charts below.

(https://user-images.githubusercontent.com/977482/175750013-06a2ca88-d9f9-4dc7-8e3a-846ea6fe220a.png)

Now, you may recognize some of the "feature requests" in that chart. Many users were just not aware that DFHack already includes the tool they were requesting. In fact, about 1 in 3 feature requests were for features or tools that already exist in DFHack. Another vote for the "Discoverability" pain point.

Here is the chart with only requests for features that don't already exist in DFHack:

(https://user-images.githubusercontent.com/977482/175750191-4f5c9af3-793a-412d-93a1-9681389f85d2.png)

Again, these are made-up names that I used to represent the ideas I was combining from the responses. Here's what they mean:


Q5 analysis and opinion
These requests indicate the areas where players feel they don't have enough control or information. Military-related tools were the number one requested feature, but all of these are good suggestions and we'll take them under consideration. A number of these top requests are being worked on right now, such as `filter-reports` and `max-wave`. `gui/assistant` is an excellent suggestion for improving the usability of DFHack and will be given high priority, given the pain points our users made clear in Q4!

Developers out there: if you want to make a contribution to DFHack but don't know what to write, that is the list of the tools that will be most appreciated by the community!

In an effort to aid discovery, here are the most popular "feature requests" for tools that DFHack already has, in order of popularity, along with brief descriptions and links to each existing tool's documentation:

Title: Re: DFHack 0.47.05-r6
Post by: Rumrusher on June 28, 2022, 07:45:20 am
Code: (Open-advmode.lua) [Select]
local old_screen=dfhack.gui.getCurViewscreen()
local new_screen=df.viewscreen_setupadventurest:new()
old_screen.child=new_screen
new_screen.parent=old_screen
for Rawid,Creature in pairs (df.global.world.raws.creatures.all) do
new_screen.races_info:insert("#",{new=true,race=Rawid,anon_1=20000,playable=true})
if Creature.flags.HAS_ANY_INTELLIGENT_LEARNS==true then
new_screen.race_ids:insert("#",Rawid)
end
end

new_screen.highlighted_entity_ids:insert("#",'-1')
for Civ_id,Ent in pairs (df.global.world.entities.all) do
new_screen.highlighted_entity_ids:insert("#",Ent.id)
for _,Setup in pairs (new_screen.races_info) do
if Ent.race==Setup.race then
 Setup.entity_id=Ent.id
end
end
end


df.global.gamemode=df.game_mode.ADVENTURE
df.global.gametype=df.game_type.ADVENTURE_MAIN

(https://cdn.discordapp.com/attachments/302956330304667649/991313694556434432/advmode-on-the-fly2.gif)

ok so while screwing around with viewscreens here's a slightly better open advmode creation screen script which from my tests works well for making new adventurers... if you're fast traveling as having a game field loaded will cause the game to layer additional game field over the previous and has been prone to crash if done near adv camps and player forts.

I guess with a bit more poking into this scripts one could say mess with the next set of adventurers loadout and probably open the door to hiring reinforcements and updating the party system with new members.
though I haven't figure out how to say... manipulate the character creation to go back to a previous adventurer made to change their gear or update their look or buy them more pets.

oh yeah this pretty much works in legend mode and world generation(warning uhh you might wanna clear the nemesis pool after your done screwing around or you might crash the game before the world gen is finished ... also if you have the go to world generation script I made earlier) fort mode is a bit tricky as technically it's still on a game field and probably result in the same land overlaying issue as with using this script while not fast traveling. also I don't know if this leads to any weird bugs or save corruptions down the line so probably a good idea to make backups of the saves you like before fiddling with this.

Code: (open-worldgen.lua) [Select]
--thanks to Warmist for the old_screen new_screen addition and Open-legends devs for inspiration
local old_screen=dfhack.gui.getCurViewscreen()
local new_screen=df.viewscreen_new_regionst:new()
old_screen.child=new_screen
new_screen.parent=old_screen
new_screen.worldgen_paused=true
df.global.gamemode=3
df.global.gametype=11
local WorldGenStat=df.global.world.worldgen_status
WorldGenStat.state=8
if new_screen.worldgen_presets~=0 then
local WGParms=df.global.world.worldgen.worldgen_parms
WGParms.beast_end_year=df.global.world.worldgen.worldgen_parms.beast_end_year+1000
WGParms.end_year=df.global.world.worldgen.worldgen_parms.end_year+1000
new_screen.worldgen_presets:insert("#",df.global.world.worldgen.worldgen_parms)
else
old_screen.worldgen_presets:insert("#",{new=true,df.global.world.worldgen.worldgen_parms})
end

(https://cdn.discordapp.com/attachments/302956330304667649/991321411299840101/post-worldgen-worldgen2.gif)

ok so this revised version of the worldgen viewscreen script will now access world generation for the world save.
the big issue is in most of my tests with this it crashed if you fast travel and it crash if you unpause fort mode
so the only way to use this is if you world gen then instantly go and retire the adv or fort then load it back up.
probably one of the more unstable scripts but this does get you access to probably the world gen history event happening to your fort and adventurers...

also word for the wise probably best not to World gen like a over 100+ years or you will have your citizens dying of old age if they aren't already immortal, as in my test the citizens would be idle in the exact same spots you left them when you started world generating... might need to see if this works on necromancers though.

Title: Re: DFHack 0.47.05-r6
Post by: Tyxaar on July 08, 2022, 05:09:02 am
Heyo, question about scripts here. I know hardly anything about how to write DFhack scripts, but how would I go about modifying the cannibalism script to apply to all sentient corpses as soon as they die? Note that I have written literally 0 dfhack scripts or plugins, but if someone could let me know, that'd be neat.
Title: Re: DFHack 0.47.05-r6
Post by: Atkana on July 14, 2022, 10:59:29 am
I'm currently having a problem when assigning syndromes via script. I have a syndrome that's supposed to immediately grant the ability to perform an interaction, however the way syndrome-util applies syndromes means that any syndrome effects added won't come into effect until the next syndrome tick (which can be quite a while in adventure mode), meaning the ability won't become available until then. Is there an alternative way to apply syndromes, or maybe some way to forcibly trigger the game to re-check a creature's syndromes without having to wait for the next syndrome tick?



Heyo, question about scripts here. I know hardly anything about how to write DFhack scripts, but how would I go about modifying the cannibalism script to apply to all sentient corpses as soon as they die? Note that I have written literally 0 dfhack scripts or plugins, but if someone could let me know, that'd be neat.

Here's something I just quickly threw together - it might need a little testing. It should automatically do the cannibalism thing whenever an item is created (except ones created due to traders, migrants, invaders and spider webs - some limitation on the event used), and yeah, a creature dying counts as creating a corpse :b.
Code: (auto-cannibalism.lua) [Select]
-- Makes any creature that dies cannibal-able
local eventful = require "plugins.eventful"

function on_item_created(item_id)
local item = df.item.find(item_id)

item.flags.dead_dwarf = false
end

--------------------
initialized = initialized or false

function init()
-- Set up everything to default values here
initialized = true

eventful.enableEvent(eventful.eventType.ITEM_CREATED, 1)
eventful.onItemCreated["auto-cannabalism"] = on_item_created
end

function reset()
-- Set things to nil/default here
initialized = false

eventful.onItemCreated["auto-cannabalism"] = nil
end

dfhack.onStateChange["auto-cannabalism"] = function(code)
-- Wipe / reset data whenever loaded state changes
if code == SC_WORLD_UNLOADED then
reset()
elseif code == SC_WORLD_LOADED then
if ( not initialized ) then
init()
end
end
end

if ( not initialised ) then
init()
end
I think I may have used the wrong template, meaning that the script will always be running for the whole game session rather than per-world, but I'm too lazy at the moment to check/fix it :p

edit: I've released a more improved version on my github (https://github.com/Atkana/Dwarf-Fortress-Mods/blob/master/auto-cannibalism.lua). Still waiting to find out about a workaround for my syndrome-assigning problem, though :c
Title: Re: DFHack 0.47.05-r6
Post by: lethosor on July 16, 2022, 01:37:25 am
Looks to me like the onStateChange handler is clearly checking for SC_WORLD_(UN)LOADED to determine when to enable/disable the event handler, so it should work the way you want. Cool idea to use the ITEM_CREATED event, by the way - I had been thinking of using UNIT_DEATH, but it's a bit more work to connect to the item that way.
Title: Re: DFHack 0.47.05-r6
Post by: Atkana on July 16, 2022, 03:56:24 am
Looks to me like the onStateChange handler is clearly checking for SC_WORLD_(UN)LOADED to determine when to enable/disable the event handler, so it should work the way you want. Cool idea to use the ITEM_CREATED event, by the way - I had been thinking of using UNIT_DEATH, but it's a bit more work to connect to the item that way.
Yeah, I originally tried using the UNIT_DEATH event, looping through the unit's corpse pieces and removing the dead_dwarf flag, but it didn't seem to work - I think maybe a delay before setting the flag is required with that method, and that's too much faff :P

After thinking, I have realised the part I was supposed to cut from the template: the elseif code == SC_WORLD_LOADED then section. That's restarting the script any time a world is loaded in the same game session as the script is run, when really it should be a conscious choice to run it (or at least, a per-save choice to automatically run it via an onLoad*.init). Wouldn't want to finish playing your modded post-apocalyptic cannibal-fest save, then switch to one of your regular dwarf fortress saves and see your dwarves butcher the recently deceased mayor or something.
Title: Re: DFHack 0.47.05-r6
Post by: FantasticDorf on July 16, 2022, 07:18:56 am
Heyo, question about scripts here. I know hardly anything about how to write DFhack scripts, but how would I go about modifying the cannibalism script to apply to all sentient corpses as soon as they die? Note that I have written literally 0 dfhack scripts or plugins, but if someone could let me know, that'd be neat.

Here's something I just quickly threw together - it might need a little testing. It should automatically do the cannibalism thing whenever an item is created (except ones created due to traders, migrants, invaders and spider webs - some limitation on the event used), and yeah, a creature dying counts as creating a corpse :b.

This was already done by Burritoman's 'Fix sentient butcher' script (http://www.bay12forums.com/smf/index.php?topic=165414.msg7553808#msg7553808), but i dont believe they're around for comment anymore. It's still working to this day, even if you configure as usually in session (and between DFhack saves at the same root-file) and can trigger it remotely from .Load etc subfiles which can be written on the spot in the OS df folder raw location but it does have caveats in coverage, like those deep in the caverns/sudden deaths where its turned off and lead to a backlog or exceptions where you'd have to work around it.

Going by item creation would possibly be similar to the smart-pets//nemesis updating aspect of the modern create-unit, but the status is passed along (exemplified by the times i've restored troll hair, by checking the GUI connected entity materials list which when you jump to the part and-re activate dead dwarf true, the object takes the nemesis name prefix), and workshops won't take dead_dwarf true items for being "rotten" or cause they're too small (often with teeth that get beat out while subject is still alive and dead_dwarf=true).
Title: Re: DFHack 0.47.05-r6
Post by: Tyxaar on July 19, 2022, 06:57:04 am
Atkana and I talked about it and they found a workaround that works fine! Here's the full script if anyone else wants to use it. It hasn't been tested with necromancy though.

Spoiler (click to show/hide)
Title: Re: DFHack 0.47.05-r6
Post by: doublestrafe on August 03, 2022, 04:48:57 pm
Few questions about assign-prefences:

Is there a token that will allow a dwarf to like to eat [CREATURE] eggs?
Is there a limit to the number of preferences you can assign?
Will really generic preferences work? Like, will -likeitem PANTS give good thoughts for both a civilian putting on a -hemp skirt- from an elf corpse and an armorer making ☼steel greaves☼?

Thanks!
Title: Re: DFHack 0.47.05-r6
Post by: Rumrusher on August 05, 2022, 08:16:19 am
Code: ('Add2Party.lua') [Select]
function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end

function getCreatureAtPos(x,y,z) -- gets the creature index @ x,y,z coord
--local x,y,z=getxyz() --get 'X' coords
local vector=df.global.world.units.all -- load all creatures
for i = 0, #vector-1 do -- look into all creatures offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==x and cy==y and cz==z then --compare them
return vector[i] --return index
end
end
--print("Creature not found!")
return nil

end

unit=getCreatureAtPos(getxyz())
df.global.ui_advmode.interactions.party_core_members:insert("#",unit.hist_figure_id)

ok so stumbled upon the data in advmode ui that holds where the 'core party members' are or well  what I been calling Adv party members.
so now uhh here's a script that works like bodyswap but uses the in game swap mechanics to switch around adventurers... also doubles as a companion maker since all adv party members are following each other. currently realizing I could have been playing around with this when adv mode got party members... oh well better late than never.


edit: oh this was also added to the repo's body swap hmm though that doesn't really add more adventurers to your party unless you make them companions then swap over to them with the repo body swap script

edit 2: well while I'm here, probably good enough time to dump this modified update on the open-advmode script which now attempts to grab campboats but mostly lets the player start from their player site... and start as any sapient creature.

Code: ('Open-Advmode2.lua') [Select]
local old_screen=dfhack.gui.getCurViewscreen()
local new_screen=df.viewscreen_setupadventurest:new()
old_screen.child=new_screen
new_screen.parent=old_screen
for Rawid,Creature in pairs (df.global.world.raws.creatures.all) do
new_screen.races_info:insert("#",{new=true,race=Rawid,anon_1=20000,playable=true})
if Creature.flags.HAS_ANY_INTELLIGENT_LEARNS==true then
new_screen.race_ids:insert("#",Rawid)
end
end

new_screen.highlighted_entity_ids:insert("#",'-1')
for Civ_id,Ent in pairs (df.global.world.entities.all) do
new_screen.highlighted_entity_ids:insert("#",Ent.id)
for _,Setup in pairs (new_screen.races_info) do
if Ent.race==Setup.race then
 Setup.entity_id=Ent.id
end
end
end



for Civ_id,Ent in pairs (df.global.world.entities.all) do
for boat,camp in pairs (df.global.world.world_data.sites) do
if camp.name.first_name=="BOAT" or camp.type==0 then
local Campent=camp.entity_links
for _2,Campe in pairs(Campent) do
if Campe.flags.residence==true or  Campe.flags.land_for_holding==true then
new_screen.highlighted_entity_ids:insert("#",Campe.entity_id)
for _,Setup in pairs (new_screen.races_info) do
 Setup.entity_id=Campe.entity_id
end
end
end
end
end
end


df.global.gamemode=df.game_mode.ADVENTURE
df.global.gametype=df.game_type.ADVENTURE_MAIN
so I probably should advise to use this you probably want to have a player fort made or use one of my many old camp boat scripts so that the starting site gets picked up.
so far you probably don't want to use this on a fresh adventurer if you want to keep said fresh adventurer around as any new adv's made wouldn't been saved to the game and won't be able to unretire since they never retired in the first place... if you go with the fast travel set up to avoid site overlay issues and crashing if you attempt this while on the camp site.


Title: Re: DFHack 0.47.05-r6
Post by: doublestrafe on August 09, 2022, 04:10:54 am
So maybe I'm in over my head, but armed with a 20 year old knowledge of just enough vba experience to look like a genius in a small office, and a frustration with trying to figure out how and when stuff happened looking through gamelog.txt, I sat down today to try to teach myself lua.

Fortunately, it's similar to all the other coding I've ever done, which is to say that the best way to approach it is to steal liberally from any possible source. I've managed to get as far as writing a script that will, with the help of "repeat", print the time and date to the announcement log on a regular basis. It uses no loops and ought to give any seasoned coder a good laugh. Of course, now that that part's complete, I found dfhack.gui.WriteToGameLog, so now I'll have to rewrite it to be quiet.

But I've run into another problem with the gamelog.txt, which is that it doesn't care at all what save you're running from. Everything from every fort goes in willy-nilly. So I thought, while I'm writing a timestamp, why not write the name of the fortress? How hard can that be?

I am at an utter loss here. I had been able to find df.global.cur_year only because timestream uses it--I learned a lot from timestream, actually. And I found where it came from, in https://github.com/DFHack/df-structures/blob/master/df.globals.xml (had to go online--despite the Lua API docs' assurance, \hack\library\xml only contains how-to-update and SYNTAX). There are some interesting things there, but not, as far as I can tell, the name of the fortress.

Really, this is a more general question, though I really do want to know how to return the fortress name, or at least the world name. But how do you find what you're looking for in the dozens of xml files? Is it just a question of sheer dogged perseverance and trial and error?
Title: Re: DFHack 0.47.05-r6
Post by: Schmaven on August 09, 2022, 05:33:18 am
Is it possible to run a search on the xml files for the fort / world name text strings?
Title: Re: DFHack 0.47.05-r6
Post by: PatrikLundell on August 09, 2022, 07:09:23 am
@doublestrafe:

The key to finding info from the DF data structures is to gradually learn how they're structured so you can make educated guesses as which place to look for the info you want. gui/gm-editor is a very good tool for that.

df.global.world.world_data.name is (presumably) a name, and I would expect it to be the name of the world. You'd need the DFHack operation to unpack the name (too long since I did anything with DFHack, so I'd have to locate it in some script or look at the documentation if I was to say what it is).

df.global.world.world_data.active_site is the current fortress in a vector of size 1. The first element of the the structure in that vector is a name, which should be the name of the fortress. Again, you'd need to use the operation to extract a string from it (and a boolean is used to specify if the string should be English or the "native" language).
As an aside, this same entry is also found in the vector containing all sites (because the vector entries are references to the data, not the data itself, so it's not a duplication), so you could find it there by looking for the type being PlayerFortress, but you'd get all of them if you have embarked multiple times in the same world.

Hope that's clear enough for you to find what you need.
Title: Re: DFHack 0.47.05-r6
Post by: lethosor on August 10, 2022, 12:39:37 am
But I've run into another problem with the gamelog.txt, which is that it doesn't care at all what save you're running from. Everything from every fort goes in willy-nilly. So I thought, while I'm writing a timestamp, why not write the name of the fortress? How hard can that be?
It depends on what you mean by "name of the fortress". Patrik's suggestion of "world.world_data.name" is the in-game name that you see on the right side of the screen in the "load game" menu, among other places. If you want the folder, that is "world.cur_savegame.save_dir" (and if you want the full path, use "dfhack.getSavePath()" in Lua).

Quote
I am at an utter loss here. I had been able to find df.global.cur_year only because timestream uses it--I learned a lot from timestream, actually. And I found where it came from, in https://github.com/DFHack/df-structures/blob/master/df.globals.xml (had to go online--despite the Lua API docs' assurance, \hack\library\xml only contains how-to-update and SYNTAX). There are some interesting things there, but not, as far as I can tell, the name of the fortress.

Really, this is a more general question, though I really do want to know how to return the fortress name, or at least the world name. But how do you find what you're looking for in the dozens of xml files? Is it just a question of sheer dogged perseverance and trial and error?
I second the recommendation to use gui/gm-editor. Specifically, you can start with "gui/gm-editor df.global". A lot of game-specific stuff is under "world", and a lot of other things are under "ui". Those are probably the biggest two. You can get to globals directly with just their name, e.g. "gui/gm-editor world".

If you prefer a text-based UI, you can also run "lua" and navigate through an interpreter. I do this a lot, using the "~" shortcut for printall().

I can see why the documentation telling you to look in library/xml could be confusing - what it means is to look at that path in the DFHack source code, i.e. https://github.com/dfhack/dfhack -> library -> xml (or locally), which takes you to https://github.com/dfhack/df-structures (so you found the right XML files eventually). Based on the wording in that paragraph, I am pretty confident that it pre-dates any sort of generated+hosted documentation. Our intra-documentation links should always be actual links, not references to paths that you have to follow manually (if you find an exception, please let us know!). In fact, even the external link in that paragraph, if followed, takes you to https://github.com/DFHack/df-structures

As for how I find things: I usually guess a couple names, and then search through the files locally. All types are defined in df.*.xml files. As an example, searching for "cur_savegame.save_dir": the field name likely contains the word "save", so grepping for "save" gives 98 results. Of those, 43 are "save_version", which I can rule out immediately. I can also be pretty sure this is a global, so I can rule out any files that primarily define non-global objects (such as df.viewscreen.xml, df.*raws.xml). At this point, I have 25 results that are part of an XML tag (not a comment), and the one I'm looking for happens to be the last one alphabetically:
Code: [Select]
df.world.xml:1512:            <stl-string name='save_dir'/>

A text search for "name" unfortunately gives an unreasonable number of results, because "name" is also the attribute used to name every field, type, etc.

Usually people are happy to point you to the right spot for questions about fields, and over time, people tend to get a feeling for where things are likely to be (I say "likely" because DF is not always consistent with itself). We have a Discord server as well (https://docs.dfhack.org/en/latest/docs/Support.html) where response rates vary but tend to be quick.
Title: Re: DFHack 0.47.05-r6
Post by: doublestrafe on August 10, 2022, 02:30:12 am
Thanks! PatrickLundell's help was the first thing I needed...but it took me a long time to figure that out. I'd only ever used gm-editor to play God with dwarves' very souls, and it took me a significant chunk of the day to figure out how to use it to look at anything else. (The example in the docs that uses it to look at all the items was a clue--I glazed over it a little because I knew how to look at items, and it took longer than it should have to realize that the command in the example was formatted just like what Patrick gave me.) Right now, my script is doing what I want it to do, despite the fact that finishing it generated a huge list of would-be-nice to-dos. Think I'll take a little break before I burn myself out, though. After all these years, coding projects still feel like a fey mood.

Of course, having the names of a couple of the df.global.world* commands is a huge help anyway, because searching on them pulls up other scripts that people have used them in.

I was going to complain about searching for "name" earlier but I figured I'd been whiny enough.

Discord! Good to know! It feels a little weird conversing on such general topics in the single dfhack thread. Dfhack is just so big, because half the questions are actually about Dwarf Fortress, but dfhack is the only way to get to where you can even ask the question.

One more question:

@doublestrafe:

You'd need the DFHack operation to unpack the name (too long since I did anything with DFHack, so I'd have to locate it in some script or look at the documentation if I was to say what it is).
Are you saying that there's documentation on what some of these are? If so, and you don't just mean the API docs, any pointers?
Title: Re: DFHack 0.47.05-r6
Post by: PatrikLundell on August 10, 2022, 03:07:16 am
I'm feeling slightly less lazy today than yesterday, so I spent a few minutes locating an example of the command:
"dfhack.TranslateName (df.global.world.world_data.rivers [current_river].name, true)"
The first parameter is the name field of whatever you want the name of, and the second parameter is whether it should be in the "native" language (basically dwarven, elven, or goblin) or English (in this case it's the name if a river).

While trying to get to grips with gui/gm-editor was probably frustrating, I think it's probably time well spent (doesn't mean resting isn't in order). The "documentation" I was referring to was indeed the API documentation.
Title: Re: DFHack 0.47.05-r6
Post by: Jostino on August 16, 2022, 04:40:47 am
I don't know if is something already happened to someone, but I experienced this event with the "reveal" command.
(I've already posted in the bi-weekly thread on reddit and I received already some answers about, but I would share here also, if I can)

I revealed the map, then I saved the game. Game crashed, I loaded the game, but the map was still all visible, and it wasn't possible to use the unreveal command on DFHack, because is not allowed while the map is not revealed (even if it is actually).
Title: Re: DFHack 0.47.05-r6
Post by: Rumrusher on August 16, 2022, 06:34:43 am
I don't know if is something already happened to someone, but I experienced this event with the "reveal" command.
(I've already posted in the bi-weekly thread on reddit and I received already some answers about, but I would share here also, if I can)

I revealed the map, then I saved the game. Game crashed, I loaded the game, but the map was still all visible, and it wasn't possible to use the unreveal command on DFHack, because is not allowed while the map is not revealed (even if it is actually).
at that point you use revflood to fill in the rest of the map and hopefully fix the issue.



so kinda hit an roadblock on the modifications of tofort where I think I mostly got most of the crashes out But the one that ties into Advfort crashing if you do foraging which means there some Fort mode data that is missing in Adv mode that would cause DF to crash if ran.
also went into a bit more disjointed detail on this topic in the spoiler.
Title: Re: DFHack 0.47.05-r6
Post by: Jostino on August 16, 2022, 12:24:31 pm
I don't know if is something already happened to someone, but I experienced this event with the "reveal" command.
(I've already posted in the bi-weekly thread on reddit and I received already some answers about, but I would share here also, if I can)

I revealed the map, then I saved the game. Game crashed, I loaded the game, but the map was still all visible, and it wasn't possible to use the unreveal command on DFHack, because is not allowed while the map is not revealed (even if it is actually).
at that point you use revflood to fill in the rest of the map and hopefully fix the issue.

Solved with revflood! Thanks!
Title: Re: DFHack 0.47.05-r6
Post by: Rumrusher on August 26, 2022, 11:40:23 am
(https://cdn.discordapp.com/attachments/302956330304667649/1012759129288351896/onthefly-Fort2Adv-patch.gif)
ok so after intense testing and rage, and stress I finally got around to a mostly some what stable version of warmist's tofort with viewscreen switching implementation.

Code: ("tofort-v15.lua") [Select]
-- changes from advmode to fort safely and back (hopefully)
--[[Now to warn you about saving and loading in either game mode might lead
    to some side issues, for saving in fort mode switching to adv mode needs the adv to be `bodyswap`
    back in again. for Saving in Adv to switch to Fort mode you probably be safe-ish if the site.
    isn't a nano fort or a site that isn't 3x3 small. otherwise the game will try to resize the map.
    oh and switching to fort mode on any pre-gen site larger than 4x4 might implode one pc if
    you don't have like 20 gigs of memory for the 16x16 embark size.

ok so this version of this script has be updated so that caravans and visitors and migrants
could show up at any edge of the map... and maybe leave from any spot... of the z level you assign the site too.
should be warned if a caravan decides to exit not from the assign z level you set like above or below the plane the game will crash.
so uhh I probably should get to figuring out how to map the surface at some point...]]--

if df.global.gamemode==df.game_mode.ADVENTURE then
local adv=df.global.world.units.active[0]
local comp={}
local ui=df.global.ui

function advGlobalPos()
    local wd=df.global.world.world_data
    return wd.adv_region_x*16+wd.adv_emb_x,wd.adv_region_y*16+wd.adv_emb_y
end
--[[function inSite()
    local tx,ty=advGlobalPos()
    for k,v in pairs(df.global.world.world_data.sites) do
        local tp={v.pos.x,v.pos.y}
        if tx>=tp[1]*16+v.rgn_min_x and tx<=tp[1]*16+v.rgn_max_x and
            ty>=tp[2]*16+v.rgn_min_y and ty<=tp[2]*16+v.rgn_max_y then
            return v
        end
    end
end]]--
function inSite()
    local tx,ty=advGlobalPos()
    for k,v in pairs(df.global.world.world_data.sites) do
        local tp2={v.global_min_x, v.global_min_y, v.global_max_x, v.global_max_y}
        if tx>=tp2[1] and tx<=tp2[3] and
            ty>=tp2[2] and ty<=tp2[4] then
            return v
        end
    end
end
local site=inSite()
if site==nil then
    qerror("No site you are in found.")
end
local nomad={}
local h_ent
if ui.main.fortress_entity~=nil or ui.main.fortress_site~=nil then
ui.main.fortress_entity=nil
ui.main.fortress_site=nil
end
    --[[for k,v in pairs(df.global.world.history.figures[adv.hist_figures_id].entity_links) do
if v==df.histfig_entity_link_positionst then
nomad=v.entity_id
break
end
end]]--
for k,v in pairs(df.global.world.history.figures[adv.hist_figure_id].entity_links) do
if v~=histfig_entity_link_memberst and not v==nil then
nomad=df.global.world.entities.all[v.entity_id]
print(v.entity_id)
else if v==histfig_entity_link_memberst then
nomad=df.global.world.history.figures[adv.hist_figure_id].entity_links[0]
end
end
end

if ui.main.fortress_entity==nil then
    for k,v in pairs(df.global.world.entities.all) do
        --if v.type==df.historical_entity_type.SiteGovernment and v.id==nomad.id then --maybe match race too?
        if v.id==nomad.id then --maybe match race too?
            if nomad.positions.own==nil then
break else
h_ent=v
            break
        end
        end
if v.id~=nomad.id then
if v.type==df.historical_entity_type.SiteGovernment then

h_ent=v
end
end
    end
    if h_ent==nil then
        qerror("Valid historical entity not found. sorry...")
    end
    ui.main.fortress_entity=h_ent
else
    h_ent=ui.main.fortress_entity
end
function cleardesignate(adv)
local adv=df.global.world.units.active[0]
df.global.ui.main.mode=10
df.global.selection_rect.start_x=0
df.global.selection_rect.start_y=0
df.global.selection_rect.start_z=610
df.global.selection_rect.end_x=-14300
df.global.selection_rect.end_y=9000
df.global.selection_rect.end_z=0
df.global.cursor.x=400
df.global.cursor.y=400
df.global.cursor.z=0
dfhack.gui.getCurViewscreen():feed_key(1)
df.global.cursor.x=adv.pos.x
df.global.cursor.y=adv.pos.y
df.global.cursor.z=adv.pos.z
dfhack.gui.getCurViewscreen():feed_key(1)
dfhack.run_command('revflood')

end
local carter={}
function addToEntity(entity,unit,addtoLead)
    local nem=dfhack.units.getNemesis(unit)
    local hfig=nem.figure
        for k,v in pairs(hfig.entity_links) do
--print(v.entity_id,entity.id)
if v.entity_id==entity.id then break else
carter=true
end
end
if carter==true then
hfig.entity_links:insert("#",{new=df.histfig_entity_link_memberst,entity_id=entity.id,link_strength=100})
    entity.nemesis_ids:insert("#",nem.id)
    entity.nemesis:insert("#",nem)
    entity.histfig_ids:insert("#",hfig.id)
    entity.hist_figures:insert("#",hfig)
end
    if addtoLead then
        local lead_id
        for k,v in pairs(entity.positions.own) do
            if v.flags.IS_LEADER==true then
                lead_id=v.id
                break
            end
        end
        if lead_id~=nil then
            for k,v in pairs(entity.positions.assignments) do
                if v.position_id==lead_id  then
                        v.histfig=hfig.id
                    break
                end
            end
        end
    end
end

ui.civ_id=adv.civ_id
ui.race_id=adv.race
df.global.pause_state=true


ui.unk_races:insert("#",adv.race)
ui.site_id=site.id
if ui.main.fortress_site==nil then ui.main.fortress_site=site end
if site.entity_links==nil then site.entity_links:insert("#", {new=true, df.entity_site_link, target=site.id, entity_id=ui.fortress_entity.id,entity_site_link_flags.residence, entity_site_link_flags.trade_partner }) end
ui.group_id=h_ent.id
ui.game_state=2


if #ui.tasks.discovered_plants==0 then
df.global.ui.tasks.discovered_creature_foods:insert("#",0)
df.global.ui.tasks.discovered_creatures:insert("#",0)
df.global.ui.tasks.discovered_plants:insert("#",0)
df.global.ui.tasks.discovered_plant_foods:insert("#",0)
end
if #ui.alerts.list==0 then
    ui.alerts.list:insert("#",{new=true,name="Dummy alert"})
    ui.alerts.next_id=1
end


    local nem2=dfhack.units.getNemesis(adv)
    local hfig2=nem2.figure
    local nomad2=hfig2.entity_links[0]
    local nomad3=hfig2.entity_links
    local Test={}
    for co2,mp2 in pairs(nomad3) do
--print(mp2.entity_id,h_ent.id)
        if mp2.entity_id~=h_ent.id then Test=true else
            Test=false
            end
        end   
        if Test==true then
            addToEntity(h_ent,adv,true)
        end
    for co,mp in pairs(df.global.world.units.active) do
        if mp.relationship_ids.GroupLeader==adv.id then
            local comp=mp
        if test==true then
            addToEntity(h_ent,comp,false)
        end
    end
end

function sigh()
 mapcheck()
for k,v in pairs(df.global.ui.map_edge.surface_z) do
df.global.ui.map_edge.surface_z[k]=adv.pos.z
--v=152
end
end
function mapcheck()
for k,v in pairs(df.global.ui.unk2a8c[0]) do
if v.unk1==0 then
v.unk1=12
v.unk2=12
end
if df.global.ui.unk_mapedge_x~=nil then
df.global.ui.unk_mapedge_x:insert("#","0")
df.global.ui.unk_mapedge_x:insert("#",math.random(0,143))
df.global.ui.unk_mapedge_x:insert("#","143")
df.global.ui.unk_mapedge_x:insert("#",math.random(0,143))
df.global.ui.unk_mapedge_y:insert("#",math.random(0,143))
df.global.ui.unk_mapedge_y:insert("#","0")
df.global.ui.unk_mapedge_y:insert("#",math.random(0,143))
df.global.ui.unk_mapedge_y:insert("#","143")
df.global.ui.unk_mapedge_z:insert("#",adv.pos.z)
df.global.ui.unk_mapedge_z:insert("#",adv.pos.z)
df.global.ui.map_edge.surface_x:insert("#",0)
df.global.ui.map_edge.surface_x:insert("#",math.random(0,143))
df.global.ui.map_edge.surface_y:insert("#",math.random(0,143))
df.global.ui.map_edge.surface_y:insert("#",0)

df.global.ui.map_edge.surface_x:insert("#",143)
df.global.ui.map_edge.surface_x:insert("#",math.random(0,143))
df.global.ui.map_edge.surface_y:insert("#",math.random(0,143))
df.global.ui.map_edge.surface_y:insert("#",143)
df.global.ui.map_edge.surface_z:insert("#",adv.pos.z)
df.global.ui.map_edge.surface_z:insert("#",adv.pos.z)
df.global.ui.map_edge.surface_z:insert("#",adv.pos.z)
df.global.ui.map_edge.surface_z:insert("#",adv.pos.z)
for _,Lay in pairs(df.global.ui.map_edge.layer_x) do
Lay:insert("#",math.random(0,143))
end
for _,Lay in pairs(df.global.ui.map_edge.layer_y) do
Lay:insert("#",math.random(0,143))
end
for _,Lay in pairs(df.global.ui.map_edge.layer_z) do
Lay:insert("#",adv.pos.z)
end
end
end
end
Tab={}
Tab2={}
for k,Lay2 in pairs(df.global.ui.map_edge.layer_z) do
for k2,Lay3 in pairs(df.global.ui.unk2a8c[0]) do
if k then break else
Tab:insert("#",k)
end
Tab2:insert("#",k2)
return Tab,Tab2
end
end
if #df.global.ui.map_edge.layer_z[0] == 0 then
print("map edge empty proceed to fill")
sigh()
 else
print("welp map edge currently full")
 end


if #ui.kitchen.item_types==0 then
ui.kitchen.item_types:insert("#",0)
ui.kitchen.item_subtypes:insert("#",0)
ui.kitchen.mat_types:insert("#",0)
ui.kitchen.mat_indices:insert("#",0)
ui.kitchen.exc_types:insert("#",0)
end
if #ui.unk_9==0 then
ui.unk_9:insert("#",0)
ui.unk_9:insert("#",0)
ui.unk_10:insert("#",0)
ui.unk_10:insert("#",0)
ui.unk_11:insert("#",0)
ui.unk_11:insert("#",0)
end
--fix training info
if h_ent.training_knowledge == nil then
    h_ent.training_knowledge={new=true}
end
df.global.gamemode=df.game_mode.DWARF
df.global.gametype=df.game_type.DWARF_MAIN
if df.global.gview.view.child.child==nil then df.global.gview.view.child=df.viewscreen_dwarfmodest:new()
df.global.gview.view.child.parent=df.global.gview.view
 end
 cleardesignate()
    print("Mode change complete.")
else
    local adv=dfhack.gui.getSelectedUnit(true)
    if adv then
        --swap units...
    end
    df.global.gamemode=df.game_mode.ADVENTURE
    df.global.gametype=df.game_type.ADVENTURE_MAIN
df.global.gview.view.child=df.viewscreen_dungeonmodest:new()
df.global.gview.view.child.parent=df.global.gview.view
    print("Mode change complete.")
end
ok so mapedge-z is used for when you're exploring the world and to prevent shifting to a site and noticing all the visitors are now underground due to being in a higher location than the last time you used the tofort(as tofort only fills in the map edge once and stops once it checks to see it's filled)
Code: ("mapedge-z.lua") [Select]
adv=df.global.world.units.active[0]
for _,Lay in pairs(df.global.ui.map_edge.layer_z) do
Lay=adv.pos.z
end
for _,Lay in pairs(df.global.ui.unk_mapedge_z) do
Lay=adv.pos.z
end
for _,Lay in pairs(df.global.ui.map_edge.surface_z) do
Lay=adv.pos.z
end
Spoiler: "v14" (click to show/hide)

ok so with this modified script of warmist's old tofort script you can probably safely* switch between adv mode and fort mode.
*so far from what I tested be advise to back up any saves when using any of my scripts. if I remember you probably shouldn't have advfort active while running this or it will throw a monkey wrench into the script and you need to re-run it again to get it to work properly.

(https://cdn.discordapp.com/attachments/302956330304667649/1012763164372373574/goblinmoodfix.png)
hope folks have fun with this more than the tireless testing I had to go through.

edit: oh yeah there this one weird quirk with syndromes that freezes the timer that I noticed with bogeymen going from adv mode to fort mode it's temporary as I notice it reverting the bogeymen back when I swap back to adv mode and fast traveled but heads up if you use mods that rely on timers using this script


edit 2: ok so went back and edited the script after figuring out a way to do mapedges so the latest version has migrant and visitor support... kinda but it also kinda bloaty and set to camp size for the map edge so I don't know how well this would work on different map sizes.
oh  probably best to set up a fort and or camp at a location that is flat and even as I haven't sanity check for all zlevel surfaces
Title: Re: DFHack 0.47.05-r6
Post by: Gimli-McGloinFace on September 01, 2022, 06:32:42 pm
So I posted a suggestion to DF Suggestions for a feature I feel would help Military RP a bit, but now I'm thinking it might be possible to make a script for dfhack to do it myself. Is this possible and is there any tutorials on where to begin, I have no experience but it could make for a !fun! mega-project haha.
Title: Re: DFHack 0.47.05-r6
Post by: myk on September 01, 2022, 07:22:57 pm
There is a lot of potential for DFHack to help with organizing and managing the military, but I'd be wary of starting something large this close to the steam release. Military mechanics might change and invalidate your work. However, of you can choose a small, focused project, we'd be happy to help you get it off the ground. You'll find more active DFHack discussion on the DFHack discord server (https://dfhack--2247.org.readthedocs.build/en/2247/docs/Introduction.html#getting-help).
Title: Re: DFHack 0.47.05-r6
Post by: Gimli-McGloinFace on September 02, 2022, 07:36:25 am
TBH if any update invalidated my work I'd be happy I guess since my thing would be in the official version. I think my idea is quite simple but I've no idea in practice how difficult it would be to implement. I'll link the full suggestion here: http://www.bay12forums.com/smf/index.php?topic=180252.msg8402347#msg8402347

Basically I was imagining a macro of a sort (trying the built in macro system is hit or miss for this since I'm relying on when I press Q after the hotkey press it doesn't always start in the same place) that checks when a new month ends and goes through certain barracks of a specific name and resets sleeping positions.
Title: Re: DFHack 0.47.05-r6
Post by: myk on September 02, 2022, 12:27:36 pm
If it's expressible with a macro, you'd probably be better off using a quickfort blueprint to make the changes, and run it on a timer to execute once per season (or on the first of the month of you want monthly).

You can write some light Lua code to detect when the season/month starts, but ideally you could modify the repeat utility to do the calculations for you.

So, the final form of your project could be a command that looks something like this:

Code: [Select]
repeat --name barracks-beds --onday 1 --timeUnits months --command [ quickfort run swap_barracks_beds.csv --cursor=26,54,137 ]
You just would need to put the right coordinates in the quickfort cursor param (or write some code to autodetect position based on a particularly named bed or something)

So, implementation:
1) modify repeat.lua to support the --onday parameter
2) represent your macro in a quickfort blueprint
3) either find the correct cursor position manually with the position command or come up with an autodetection strategy

Relevant docs:
Repeat: https://docs.dfhack.org/en/stable/docs/_auto/base.html#repeat
Quickfort (what you want is a "query" blueprint): https://docs.dfhack.org/en/stable/docs/_auto/base.html#quickfort
Also the blueprint guide: https://docs.dfhack.org/en/stable/docs/guides/quickfort-user-guide.html#creating-blueprints

If you don't want to be constrained by a particular barracks layout, you can dynamically generate a quickfort blueprint based on scanning the map and then apply the changes via the programmatic quickfort API:

Code: [Select]
local quickfort = reqscript('quickfort')
quickfort.apply_blueprint{mode='query', data=myblueprintdata}
Title: Re: DFHack 0.47.05-r6
Post by: Gimli-McGloinFace on September 03, 2022, 09:26:17 am
Thank you, had a good look at all that stuff, I don't know any LUA or programming so would learning python help me at all with this wee project?
If I manage to wrap my head around this well enough, (I don't know even where to begin, where to even write code, my experience is copy and paste to get things working on Ubuntu) my plan is then to make 16 quickfort query blueprints (4 for each barracks, 1 per squad set) then have it so that all 4 Squad-1s get sets on 01/01, 05/01, 09/01, then all 4 Squad-2s on 02/01, 06/01, 09/01.
If possible I was hoping to make a check thing for if there is a siege then reset the beds daily but after some !science! research the beds don't reset instantly as you go through the squads pressing Z twice on all the squad, the squad must be unassigned long enough for the next squad to take the bed or as soon as you reactivate the sleep status it defaults to who had it last. So without good luck and the odd dwarf sleeping on the floor or 160 all at once now and again this won't work how I imagine for sieges.
So I ripped up my ceiling last night and installed another floor of sleeping barracks just for siege time(empty at all other time). If possible is there a checker that activates when its siege time, depending on which month it is will activate the remaining squads on these barracks. I think it should be possible using the quickfort query blueprint, I would just need it to activate preferably when I set Squads to specific Alerts or when a siege is detected.

Title: Re: DFHack 0.47.05-r6
Post by: myk on September 03, 2022, 02:45:43 pm
That all looks perfectly doable, but it will take a bit of scripting. Python, unfortunately, won't be of much help here. DFHack scripts are written in Lua. Lua is easier than most languages to learn. The Lua language guide (https://www.lua.org/pil/contents.html) is very approachable. Also, there are a lot of Lua scripts distributed with DFHack (https://github.com/DFHack/scripts) that you can look at for guidance and examples.

Here is a possible approach:
First, write the quickfort blueprints and manually apply them with gui/quickfort to test.
Then, once the blueprints are tested, start experimenting with Lua. Read the language guide, and then look at how some other scripts use DFHack to do similar things. autounsuspend.lua (https://github.com/DFHack/scripts/blob/master/autounsuspend.lua#L25) runs a daily check, which you could modify to detect the first day of the month and take the appropriate action. autounsuspend also runs another script, which you can modify to run quickfort to apply the correct blueprint for the current month. Siren.lua has some code (https://github.com/DFHack/scripts/blob/master/siren.lua#L85-L90) that you can use for detecting sieges.

Make a new directory in your home directory for your script, and register the directory with DFHack by editing the dfhack-config/script-paths.txt (https://docs.dfhack.org/en/stable/docs/Core.html#script-paths) file. For example, my script-paths.txt file has the following line: +/home/myk/src/dfhack-scripts. Then you can run your script by name from the DFHack terminal.
Title: Re: DFHack 0.47.05-r6
Post by: doublestrafe on September 04, 2022, 01:14:45 pm
Is dfhack.world.cur_year_tick_advmode working as intended? Instead of giving the number of adventure mode ticks from the beginning of the year like dfhack.world.cur_year_tick, it's giving the number of ticks since the adventurer was created. There doesn't seem to be an obvious tick counter that can be used to find the current time in adventure mode.
Title: Re: DFHack 0.47.05-r6
Post by: myk on September 04, 2022, 01:36:32 pm
 
Is dfhack.world.cur_year_tick_advmode working as intended?

You mean df.global.world, not dfhack.world, right? cur_year_tick_advmode only exists in the former. Those variables are set by DF, not DFHack. They "work as intended" by definition. It's just that we might not fully understand what they mean.
Title: Re: DFHack 0.47.05-r6
Post by: doublestrafe on September 04, 2022, 03:12:11 pm
Is dfhack.world.cur_year_tick_advmode working as intended?

You mean df.global.world, not dfhack.world, right? cur_year_tick_advmode only exists in the former. Those variables are set by DF, not DFHack. They "work as intended" by definition. It's just that we might not fully understand what they mean.
Bleh. I was in fact thinking of df.global.cur_year_tick_advmode. Too many similarly named places and too much staring at them in the last few days. Think I was thinking of functions like dfhack.world.ReadCurrentTick(), which would be under your control and could theoretically be pointing at the wrong thing.
Title: Re: DFHack 0.47.05-r6
Post by: myk on September 07, 2022, 11:21:41 pm
Hi all! The first cycle of DFHack's usability overhaul is just about complete, and we're looking for beta testers.

Specifically, we're looking for feedback about:

1. The new in-game command launcher with autocomplete, history search, mouse controls, and integrated help (bring up the launcher from any screen with the backtick hotkey)

2. The contents, formatting, and readability of the help text that is displayed in the help area of the launcher

You should be able to do everything you want with DFHack and get all the help you need without having to leave the game to read online docs or type things in the DFHack terminal.

There are, of course, a few caveats. Number one is that mouse controls are fairly basic. You can click on "buttons" and move the text cursor with a mouse click, but scrolling with the mouse wheel, click-and-drag, and copy/pasting with the operating system-provided clipboard are just not possible in dwarf fortress. You scroll the help text in the launcher by left/right clicking to jump by half-pages or by using the Pgup/Pgdn keys. I'm not sure if we can do better than that right now. Maybe the next version of DF will provide a more consistent way to scroll. If it does, DFHack will be sure to integrate with it. (Note that you *can* map your scroll wheel in DF to simulate the keystrokes that would scroll the text, but this is not the default configuration)

The second caveat is that while we have rewritten hundreds of pages of documentation over the past few months, we haven't updated the devel or modtools script help yet. These scripts are hidden in the launcher by default, so you might not even notice, but if you do investigate those scripts and find some "TODO" notes, that's why.

Please DM me or reply to this post if you're interested in giving feedback!
Title: Re: DFHack 0.47.05-r6
Post by: myk on September 12, 2022, 01:18:58 pm
The steps to install the DFHack pre-release are:


Note that the location of DFHack init files has changed from the root of the Dwarf Fortress folder to dfhack-config/init. If you have made custom changes to your DFHack init files, copy just your changes to dfhack-config/init. If you haven't made any custom changes to DFHack init files, you don't have to do anything.

Here are some things you can try:

Title: Re: DFHack 0.47.05-r6
Post by: Rumrusher on September 19, 2022, 02:33:26 am
ok so got around to finishing testing the latest version of the 'tofort for player forts only' script called topfort.

so far going from fort mode to adv mode would work, though probably best to make the player fort size around 3x3 until the day I/someone figures out how to adjust the size of the mapedge borders for the site size.

while I might say this version of warmist script is more stable than the previous one it still has some stuff that I probably missed in testing and some bugs that might come up during modded gameplay... or drinking in taverns.
Spoiler: "topfort6.lua" (click to show/hide)

so probably best to use this script in the middle of your fort on the surface first if you're going from adv to fort mode, or you might set the mapedge to the middle of solid rock and soil if you do this underground.
that is if the mapedge is cleared.
and if there is any screw ups with fort mapedges at least there's the z level resetting script I made before.

oh yeah syndromes might linger indefintantly still with this use and probably get fixed on map unload via fast traveling... but doing that might cause you to re-set a bunch of fort settings like locations being not adjusted and some folks not having their beds assigned but this script does seem to make some assigned rooms stick so I don't know if that's due to stored ui data or what.

I probably stick with saving the game in the game mode you started in for sanity safety checks... and beware of important location overlaying your site when switching into the different game mode as it might pick up that site instead.
other than that have fun:
 using adv mode talking and personal actions in fort mode scenarios like convincing some guest their book they been carrying is worth the tradeexchange for a looted battleaxe from some random keep you visited, or applying a chokehold on someone who ambushed the site leading to someone jumping in to kill them for you.
or convince the local 'agent villian' to join your militia dwarves and send them off on a mission to fight some mercinaries and make bets on if they come back alive or not.
exchange goods with folks that trading prevents you too, like hauling corpses and rotting goods off your lands for charity.
be able to interrogate folks with out need of a crime to pin on them.

explore the world then use the discovered locations as prime invasion targets for your group of hand pick militia of different shapes and sizes and possibly use the event rumor of their arrival to mass rescue the locals of the location to then later convert them into another militia group to kickstart another invasion operation.

set up arenas where winner gets to join the fort and the loser gets to also join the fort just later after you resurrect them.

deal with vampires personally
and many more fort mode scenarios I could possibly think of that could use an adventurer's skill set.

edit: ok after some long period of testing I for sure figure out the issue with caravans.
I would have dump the code here but I already gone past the character limit so instead here's a Github link to both updated versions of Tofort and topfort ... called tofort16 and topfort7.
https://gist.github.com/Rumrusher/5a83f2bc103cc270f9bdf77c1f1dbd06 (https://gist.github.com/Rumrusher/5a83f2bc103cc270f9bdf77c1f1dbd06)
oh yeah

you probably want to use this for mapedge(and additional ui bonus) clearing though I should warn you run this in adv mode before running the tofort scripts. 

Code: ("ui-clean.lua") [Select]
while #df.global.ui.tasks.discovered_creatures > 0 do
df.global.ui.tasks.discovered_creatures:erase(#df.global.ui.tasks.discovered_creatures-1)
end
while #df.global.ui.tasks.discovered_creature_foods > 0 do
df.global.ui.tasks.discovered_creature_foods:erase(#df.global.ui.tasks.discovered_creature_foods-1)
end
while #df.global.ui.tasks.discovered_plants > 0 do
df.global.ui.tasks.discovered_plants:erase(#df.global.ui.tasks.discovered_plants-1)
end
while #df.global.ui.tasks.discovered_plant_foods > 0 do
df.global.ui.tasks.discovered_plant_foods:erase(#df.global.ui.tasks.discovered_plant_foods-1)
end
while #df.global.ui.unk_mapedge_x > 0 do
df.global.ui.unk_mapedge_x:erase(#df.global.ui.unk_mapedge_x-1)
end

   while #df.global.ui.unk_mapedge_y > 0 do
    df.global.ui.unk_mapedge_y:erase(#df.global.ui.unk_mapedge_y-1)
    end
   while #df.global.ui.unk_mapedge_z > 0 do
    df.global.ui.unk_mapedge_z:erase(#df.global.ui.unk_mapedge_z-1)
    end
while #df.global.ui.map_edge.surface_x > 0 do
    df.global.ui.map_edge.surface_x:erase(#df.global.ui.map_edge.surface_x-1)
    end
while #df.global.ui.map_edge.surface_y > 0 do
    df.global.ui.map_edge.surface_y:erase(#df.global.ui.map_edge.surface_y-1)
    end
while #df.global.ui.map_edge.surface_z > 0 do
    df.global.ui.map_edge.surface_z:erase(#df.global.ui.map_edge.surface_z-1)
    end
while #df.global.ui.map_edge.layer_z[0] > 0 do
    df.global.ui.map_edge.layer_z[0]:erase(#df.global.ui.map_edge.layer_z[0]-1)
    end
while #df.global.ui.map_edge.layer_z[1] > 0 do
    df.global.ui.map_edge.layer_z[1]:erase(#df.global.ui.map_edge.layer_z[1]-1)
    end
while #df.global.ui.map_edge.layer_z[2] > 0 do
    df.global.ui.map_edge.layer_z[2]:erase(#df.global.ui.map_edge.layer_z[2]-1)
    end
while #df.global.ui.map_edge.layer_z[3] > 0 do
    df.global.ui.map_edge.layer_z[3]:erase(#df.global.ui.map_edge.layer_z[3]-1)
    end
while #df.global.ui.map_edge.layer_z[4] > 0 do
    df.global.ui.map_edge.layer_z[4]:erase(#df.global.ui.map_edge.layer_z[4]-1)
    end
while #df.global.ui.map_edge.layer_x[0] > 0 do
    df.global.ui.map_edge.layer_x[0]:erase(#df.global.ui.map_edge.layer_x[0]-1)
    end
while #df.global.ui.map_edge.layer_x[1] > 0 do
    df.global.ui.map_edge.layer_x[1]:erase(#df.global.ui.map_edge.layer_x[1]-1)
    end
while #df.global.ui.map_edge.layer_x[2] > 0 do
    df.global.ui.map_edge.layer_x[2]:erase(#df.global.ui.map_edge.layer_x[2]-1)
    end
while #df.global.ui.map_edge.layer_x[3] > 0 do
    df.global.ui.map_edge.layer_x[3]:erase(#df.global.ui.map_edge.layer_x[3]-1)
    end
while #df.global.ui.map_edge.layer_x[4] > 0 do
    df.global.ui.map_edge.layer_x[4]:erase(#df.global.ui.map_edge.layer_x[4]-1)
    end
while #df.global.ui.map_edge.layer_y[0] > 0 do
    df.global.ui.map_edge.layer_y[0]:erase(#df.global.ui.map_edge.layer_y[0]-1)
    end
while #df.global.ui.map_edge.layer_y[1] > 0 do
    df.global.ui.map_edge.layer_y[1]:erase(#df.global.ui.map_edge.layer_y[1]-1)
    end
while #df.global.ui.map_edge.layer_y[2] > 0 do
    df.global.ui.map_edge.layer_y[2]:erase(#df.global.ui.map_edge.layer_y[2]-1)
    end
while #df.global.ui.map_edge.layer_y[3] > 0 do
    df.global.ui.map_edge.layer_y[3]:erase(#df.global.ui.map_edge.layer_y[3]-1)
    end
while #df.global.ui.map_edge.layer_y[4] > 0 do
    df.global.ui.map_edge.layer_y[4]:erase(#df.global.ui.map_edge.layer_y[4]-1)
    end

function fillunk(tbl,low,high)
  for v =low, high do
    tbl[v].unk1=0
    tbl[v].unk2=0
  end
end
fillunk(df.global.ui.unk2a8c[0],0,143)
fillunk(df.global.ui.unk2a8c[1],0,143)
fillunk(df.global.ui.unk2a8c[2],0,143)
fillunk(df.global.ui.unk2a8c[3],0,143)
so this mostly means switching between fort mode and adv mode is mostly stable.
like I could probably flip between the two and not have to worry about Too much stuff going wrong.

outside of like sending the adventurer on a raid which shuffles the active unit list and makes shifting into adv mode a risk where you could pop into the body of some cavern critter... but that' something that could be avoided with remembering that could happen.
Title: Re: DFHack 0.47.05-r6
Post by: myk on September 30, 2022, 03:36:19 pm
DFHack 0.47.05-r7 has been released!

Download it here (https://github.com/DFHack/dfhack/releases/tag/0.47.05-r7)!

This is the first usability-focused DFHack release. The major new feature is the in-game command launcher with integrated help, autocomplete, command history (including history search), related tools display, and mouse integration.

You can access the new command launcher by clicking on the "[ DFHack Launcher ]" button in the lower left corner of the screen or by tapping the backquote (`) key. If the backquote key isn't convenient or isn't available for your keyboard layout, there is an alternate hotkey of Ctrl-Shift-D.

You can type part of a command to see autocomplete options. Hit Tab or click on an option to autocomplete. To pull a full commandline from your history, hit Alt-S or click on the "history search" button instead. When you type a command, its help text will be displayed in the large panel at the bottom. Hit Enter or click on the 'run" button to run. That's it! More info on the launcher here (https://docs.dfhack.org/en/latest/docs/tools/gui/launcher.html#gui-launcher) (which you can also see in-game when you type "gui/launcher" in the command box : )

From the screenshots, you may notice that text areas now have scrollbars. Click on the arrows at the end to scroll by one line, or on the empty area above or below the green part of the bar to scroll by half pages. You can also click on the command text that you are writing to reposition the cursor for editing.

Many thanks to the community members and beta testers who provided feedback on the launcher! Many of the best usability features were suggested by them! In particular, u/ZergTDG, u/Skitlee5, u/Thebuda, and u/tmPreston. You're awesome! Also D.B. Cooper, Quietust, and everyone else on the DFHack discord who gave feedback throughout development.

DFHack help itself has also been overhauled. More than 300 pages of help text has been reformatted and rewritten to make them more informative, easier to read, and easier to understand. Moreover, all DFHack tools are now tagged so that you can find them easier. Try running the new tags (https://docs.dfhack.org/en/latest/docs/tools/tags.html#tags) command to explore the categories! These tags also control what is in the list of related tools that appears in the right panel of the launcher when you are running a command.

New stuff


Apart from the aforementioned gui/launcher and tags, there's a bunch of great new stuff in this release:

- u/wolfboyft wrote the DFHack modding guide (https://docs.dfhack.org/en/latest/docs/guides/modding-guide.html), which will get you up to speed if you'd like to explore how to use DFHack to extend your raws modding.
- run enable gui/kitchen-info to add more info to the Kitchen screen, including what each ingredient is good for besides cooking.
- Hit "D" on the workorder details screen (where you can, say, set which kind of stone to use for a particular workorder) to get more control over the materials used to fulfill workorder jobs.
- We finally have a good way to dynamically limit the size of the next migration wave with max-wave and limit growth over time with pop-control (or even enforce a hermit challenge!).
- Get notified when creatures that may steal your food, drinks, or items become visible (e.g. keas) with warn-stealers.
- DFHack now comes with a super useful library of manager orders! See them with orders list and import them into your game with orders import. Try orders import library/basic to get a great set of orders for basic fort necessities! More info here (https://docs.dfhack.org/en/latest/docs/tools/orders.html#the-orders-library).
- DFHack's implementation of DwarfTherapist (manipulator -- accessible from the u-l screen) now comes with a library of pre-made professions that you can apply to your dwarves. More info here (https://docs.dfhack.org/en/latest/docs/tools/manipulator.html#the-professions-library).

We are also working mouse controls into more of the DFHack tools. For example, you can now move the blueprint preview around by clicking on the map when using gui/quickfort. You can interact with the map with the mouse in similar ways when using gui/quantum and gui/blueprint. Expect more mouse capabilities for DFHack tools in the future!

How to upgrade


A few files have moved around in this release, so if you're upgrading an existing installation, please read this section.

- When upgrading to this release, please *remove* the dfhack-config/dwarfmonitor.json file. It will get regenerated the next time you run DF. If you don't regenerate this file, the weather indicator (e.g. "Rain") will overlap with the new DFHack button in the lower left corner. If you have custom modifications to this file that you'd like to keep, please merge them back in once the file has been regenerated.
- DFHack init scripts (dfhack.init, onLoad.init, onMapLoad.init, etc.) have moved into dfhack-config/init/. If you have not made any custom modifications to these files, you don't need to do anything. Default configuration will be generated and used. If you have custom changes, please run DF once to generate the default config files and then move *just your custom changes* into the corresponding init files. See the docs (https://docs.dfhack.org/en/latest/docs/Core.html#init-files) for details.
- The history files for the various interactive DFHack commandline tools have moved into dfhack-config/. If you want to keep your command histories, please move your existing *.history files into dfhack-config/. Note that the new gui/launcher interface will make the commands in your old dfhack.history file available for searching even if you never get around to moving that file to the new directory.

And, just like every DFHack release, please remove the hack/ directory in your DF game folder before extracting the new version of DFHack into your DF folder. There were several scripts and other files that were removed in this release. If you don't remove the hack/ directory before upgrading, the old, unusable scripts will clutter the autocomplete list in the command launcher.

Screenshots


(https://user-images.githubusercontent.com/977482/192902807-dbe3a187-85b0-4cfc-a6ca-9344d3beeaa2.png)
(https://user-images.githubusercontent.com/977482/192899728-58b5dc7b-d836-4284-8944-912fd8cede94.png)
(https://user-images.githubusercontent.com/977482/192899837-e8bb2d16-f258-43ab-8eaa-a352cc8a6fd6.png)
(https://user-images.githubusercontent.com/977482/192899950-79630bbc-6341-454b-8783-d47e1d6ca625.png)
(https://user-images.githubusercontent.com/977482/192900154-b5012370-00bd-485c-bc5b-b6f8ff7d4b6f.png)
(https://user-images.githubusercontent.com/977482/192900128-5a3c2752-aa82-4cb1-80b0-3ca780820ef4.png)
(https://user-images.githubusercontent.com/977482/192900191-1e3068aa-5e12-48b2-81d2-a75a5d0fd20e.png)
Title: Re: DFHack 0.47.05-r6
Post by: myk on September 30, 2022, 03:37:44 pm
Full changelog:
Spoiler (click to show/hide)
Title: Re: DFHack 0.47.05-r6
Post by: A_Curious_Cat on September 30, 2022, 11:05:25 pm
Full changelog:
Spoiler (click to show/hide)

Looks amazing!  Why did this have to come out when I’m really invested in my current fort?…  :D
Title: Re: DFHack 0.47.05-r7
Post by: myk on October 01, 2022, 01:26:15 am
You can absolutely upgrade in the middle of a fort! You can just upgrade DFHack without touching anything else.
Title: Re: DFHack 0.47.05-r7
Post by: A_Curious_Cat on October 01, 2022, 04:02:05 am
You can absolutely upgrade in the middle of a fort! You can just upgrade DFHack without touching anything else.

Yeah, but this particular update sounds like it’d be best to do a clean install.  I’m particularly concerned about the init files and history files…



I wonder if I can do a clean install and copy my save over…
Title: Re: DFHack 0.47.05-r7
Post by: lethosor on October 01, 2022, 02:19:32 pm
I wonder if I can do a clean install and copy my save over…
As long as you're already using 0.47.05, then this should absolutely work. DFHack itself doesn't break save compatibility. You could always make a backup copy of your save folder first to be safe, though.
Title: Re: DFHack 0.47.05-r7
Post by: JPapas on October 02, 2022, 10:25:21 am
Sad to report that in the latest version, the behaviour of gui/gm-unit skill editor is still bugged, with + and - being picked up by the search filter instead of modifying values. Behaviour is happening in Adventurer mode, have not tested in Fortress mode.
Title: Re: DFHack 0.47.05-r7
Post by: myk on October 02, 2022, 10:45:28 am
Just to be sure, you're using DFHack 0.47.05-r7, the version just released two days ago, correct? This issue was marked as fixed (https://github.com/DFHack/scripts/pull/424) in -r7.
Title: Re: DFHack 0.47.05-r7
Post by: JPapas on October 02, 2022, 01:09:39 pm
Just to be sure, you're using DFHack 0.47.05-r7, the version just released two days ago, correct? This issue was marked as fixed (https://github.com/DFHack/scripts/pull/424) in -r7.

Yes, I made a fresh install just today for the sole purpose of trying this out.
Title: Re: DFHack 0.47.05-r7
Post by: A_Curious_Cat on October 02, 2022, 02:21:08 pm
Alright, I’m doing a fresh install (I was told this embark had iron.  There’s no iron…) and I’ve got a question.  Where should I put .dfhackrc?  Does it still go in the main DF directory, or has it moved somewhere else?

Edit:

Never mind, I just looked in dfhack.  It looks like it first looks for $HOME/.dfhackrc and sources that, then looks for ./dfhackrc and sources that too.

Anyways, it’s working and I’m now generating a world!
Title: Re: DFHack 0.47.05-r7
Post by: PatrikLundell on October 03, 2022, 02:31:09 am
What told you there would be iron, and how did you decide there wasn't any?

DF has a bug that causes it to report the presence of deep resources that aren't actually available if they're present in layers that are specified to be at depths deeper than the bottom of the magma sea. However, DF only declares the presence of metal, not the specific kind(s) of metal, so presumably some DFHack tool(s) was used to determine iron presence.

Apart from that, the pre embark logic can't "know" that what it reports actually is going to be there, because the content hasn't actually been generated yet, but remains a prediction. It is theoretically possible for a layer to specify veins of something that then doesn't actually show up in an embark because veins of "competing" materials were generated instead, in particular if the presence is for a single mid level tile ("embark tile"), the layer is only a single Z level deep, and abundance is set very high (so there is a lot of competition for the limited number of veins that can be generated [I don't remember the details, but it's something like a maximum of 4 veins per mid level tile and Z level]).
Title: Re: DFHack 0.47.05-r7
Post by: A_Curious_Cat on October 03, 2022, 04:23:33 am
What told you there would be iron, and how did you decide there wasn't any?

Embark-Assistant told me there was iron.  None of the layers I dug through had any iron ore that I could see.  Of course, I didn’t run prospect, so there could have still been some.  Just not where I was digging.  On another note, I had plenty of cassiterite.  I should try my hand at making bronze sometime.   Also, I forgot to run 3dveins when I first embarked on that fortress.  I need to remember next time.  Same thing with noting down the name of the local stream/river…



Also, why isn’t the name of the local stream/river available on the civ screen?
Title: Re: DFHack 0.47.05-r7
Post by: myk on October 03, 2022, 01:11:48 pm
Just to be sure, you're using DFHack 0.47.05-r7, the version just released two days ago, correct? This issue was marked as fixed (https://github.com/DFHack/scripts/pull/424) in -r7.

Yes, I made a fresh install just today for the sole purpose of trying this out.

I filed https://github.com/DFHack/dfhack/issues/2308 for this. I'll look into it for the next version. Thanks!
Title: Re: DFHack 0.47.05-r7
Post by: myk on October 03, 2022, 01:28:39 pm
And lethosor fixed (https://github.com/DFHack/scripts/pull/446/files) the typo I introduced. You can edit the scripts/internal/gm-unit/editor_skills.lua file yourself if you don't want to wait until the next DFHack release:
On line 71, replace "ignore_keys" with "edit_ignore_keys"
Title: Re: DFHack 0.47.05-r7
Post by: JPapas on October 04, 2022, 02:35:21 am
And lethosor fixed (https://github.com/DFHack/scripts/pull/446/files) the typo I introduced. You can edit the scripts/internal/gm-unit/editor_skills.lua file yourself if you don't want to wait until the next DFHack release:
On line 71, replace "ignore_keys" with "edit_ignore_keys"

Made this change and it works perfectly :)
Title: Re: DFHack 0.47.05-r7
Post by: PatrikLundell on October 04, 2022, 03:31:50 am
@A_Curious_Cat: Embark-Assistant uses the same logic that Prospector does (the code is essentially copied and massaged slightly to fit into its more confined context). I'd try to use Prospect to see what it says, though, because it tells the truth of the situation post embark (as things have been defined at that time, so there's no longer any need for predictions).

However, you may just have gotten unlucky with the RNG such that no vein rolled the iron mineral, but rather something else instead.
I don't know if the vein (and cluster) RNG rolls are independent or if they are re-balanced after each allocation (in the first case a 25% A, 25% B, and 50% C in a case where you have 4 veins would allow for all veins being the same mineral if the rolls happened to be that way, while in the latter the probability of a mineral to get a second vein would be reduced, either with the full or a reduced weight, for each vein whose mineral is specified).
Title: Re: DFHack 0.47.05-r7
Post by: MaxTheFox on October 12, 2022, 04:19:34 am
World generation tends to ignore stop commands after it gets slow enough. Is there a way to use a script to force-stop worldgen at a certain year?
Title: Re: DFHack 0.47.05-r7
Post by: myk on October 12, 2022, 03:12:21 pm
I believe DF only checks the "stop" flag once every few years. It doesn't ignore it, it just takes longer and longer to process that many years before it checks. That said, there might be a way to speed it up, but I don't know what it is.
Title: Re: DFHack 0.47.05-r7
Post by: Rose on October 12, 2022, 03:26:52 pm
One solution is to wait for the premium release, where that's fixed.
Title: Re: DFHack 0.47.05-r7
Post by: Salmeuk on October 13, 2022, 01:44:21 am
World generation tends to ignore stop commands after it gets slow enough. Is there a way to use a script to force-stop worldgen at a certain year?

Spoiler (click to show/hide)
at timing your stop entry just 4 years ahead of your intended date

Spoiler (click to show/hide)
Title: Re: DFHack 0.47.05-r7
Post by: PatrikLundell on October 13, 2022, 02:50:53 am
As mentioned, DF has a tendency to not check input every year, so your logic to stop will have to account for that by stopping when the year is within a given range of the desired year (before, after, or around, depending on what you're aiming for).
https://github.com/PatrikLundell/scripts/blob/own_scripts/worldgen_breakout_box.lua (https://github.com/PatrikLundell/scripts/blob/own_scripts/worldgen_breakout_box.lua) is a web page with a lua script (NOT just the script iself) harness for breaking out of world gen at various points that may be of interest.
Title: Re: DFHack 0.47.05-r7
Post by: Rumrusher on October 13, 2022, 03:33:20 am
(https://cdn.discordapp.com/attachments/302956330304667649/1030030933287510098/force-milking-of-pets.png)
ok so here's a script for a niche issue... where you couldn't use pets in the farmers workshop, well now you can... at least for milking so far I think the other jobs are possible when I figure out their general refs.
Code: [Select]
local Uni=dfhack.gui.getSelectedUnit()


  local buildings={}
for _,izm in pairs (df.global.world.buildings.all) do
if df.building_workshopst:is_instance(izm) and izm.type==1 then
milk=izm.jobs[0]
print(milk.id)
milk.general_refs:insert("#",{new=df.general_ref_unit_milkeest,unit_id=Uni.id})
end
end

this script works as follows, you make a milk animal job in the workshop, while the game is still paused you highlight the creature you want to be milked with the cursor which the game will go through the rest of the job process.

(https://cdn.discordapp.com/attachments/302956330304667649/1030033722902335498/oh-right-that-factor.gif)

as seen in this gif.... and also seen in this gif best check the creature you want to milk is milk-able as you might end up dragging some poor sap to extract literally nothing

(they still end up getting the milked trait and have a milk counter if you do this)

Title: Re: DFHack 0.47.05-r7
Post by: 0x517A5D on October 18, 2022, 04:47:21 pm
How expensive is Eventful?  Specifically for announcements/reports.

Not looking for precision here, just gut feelings.

I kind of want to have some code triggered by certain report types (specifically the migrant wave announcements).

I think I've figured out that Eventful doesn't trigger as reports are issued, but checks every n ticks after-the-fact for new reports.  True?

Then it will pass every new report to a script callback function, but it can't filter on e.g. D_MIGRANTS_ARRIVAL.  Also true?

So I would look at world.status.reports[id_number].type to check for D_MIGRANTS_ARRIVAL and similar.

Since I'm processing every report anyway, it doesn't matter too much if I just process them every tick?  Or would getting the reports in batches be less costly?  It's the same number of callbacks, but maybe not as much setup/teardown between C++ EventManager and eventful.

I haven't done any experimenting, I'm just looking at eventful.lua, eventful-client.lua, and annc-monitor.lua.


The other way I've thought of is to have an every-n-ticks callback that examines #world.units.active to see if the array size has changed since last time.  Any thoughts on whether that's less expensive?
Title: Re: DFHack 0.47.05-r7
Post by: Putnam on October 18, 2022, 10:36:03 pm
The overhead between Lua and C++ is significantly smaller than the amount of processing done by just doing things in Lua
Title: Re: DFHack 0.47.05-r7
Post by: Rumrusher on November 01, 2022, 09:18:11 pm
(https://cdn.discordapp.com/attachments/302956330304667649/1037186212118659164/force-petition-showcase.gif)
ok so went and worked on a script that lets one force petitions to your fort.
kind of an alternative version to Makeown that forces the game to go through the citizenship process.
Code: ('force-petition.lua') [Select]
function petition()


local Shell=dfhack.gui.getSelectedUnit(true)
--local Shell=getCreatureAtPos(getxyz())
local Agree=df.global.world.agreements.all
Agree:insert("#",{new=true,id='-10',next_party_id=2,next_details_id=1})
local dd=Agree[#Agree - 1]
--for d,dd in ipairs(Agree) do
--if dd.id==(-10) then
--print('oh no')
dd.id = df.global.agreement_next_id
df.global.agreement_next_id = df.global.agreement_next_id + 1
dd.details:insert("#",{new=true,type=3})
dd.parties:insert("#",{new=true})
dd.parties:insert("#",{new=true})
dd.details[0].data.Citizenship=df.agreement_details_data_citizenship:new()
dd.details[0].data.Citizenship.applicant=0
dd.details[0].data.Citizenship.government=1
dd.details[0].data.Citizenship.site=df.global.ui.site_id
dd.parties[0].histfig_ids:insert("#",0)
dd.parties[0].histfig_ids[0]=Shell.hist_figure_id
dd.parties[1].id=1
dd.parties[1].entity_ids:insert("#",0)
dd.parties[1].entity_ids[0]=df.global.ui.group_id
df.global.ui.petitions:insert("#",dd.id)

end
function petition2()


local Shell=dfhack.gui.getSelectedUnit(true)
--local Shell=getCreatureAtPos(getxyz())
local Agree=df.global.world.agreements.all
Agree:insert("#",{new=true,id='-10',next_party_id=2,next_details_id=1})
local dd=Agree[#Agree - 1]
--for d,dd in ipairs(Agree) do
--if dd.id==(-10) then
--print('oh no')
dd.id = df.global.agreement_next_id
df.global.agreement_next_id = df.global.agreement_next_id + 1
dd.details:insert("#",{new=true,type=2})
dd.parties:insert("#",{new=true})
dd.parties:insert("#",{new=true})
dd.details[0].data.Residency=df.agreement_details_data_residency:new()
dd.details[0].data.Residency.reason=3
--dd.details[0].data.Residency.reason=48
dd.details[0].data.Residency.applicant=0
dd.details[0].data.Residency.government=1
dd.details[0].data.Residency.site=df.global.ui.site_id
dd.parties[0].histfig_ids:insert("#",0)
dd.parties[0].histfig_ids[0]=Shell.hist_figure_id
dd.parties[1].id=1
dd.parties[1].entity_ids:insert("#",0)
dd.parties[1].entity_ids[0]=df.global.ui.group_id
df.global.ui.petitions:insert("#",dd.id)

end
petition2()
petition()

just use the cursor and run the script, and unpause the game as it takes awhile for the petition option to show up.
now the original script had one(three) functions but with help of lethosor it was cut down to two(the other function is for residency after realizing granting citizenship might not always work)

probably should give out a warning as this script probably has some unseen bugs but so far pretty stable the most part of my tests.

you probably should not use this if you don't have a noble who can receive petitions as the game will prevent you from accepting/denying them.

this script opens the door to other agreement related mechanics you want to mess with.

edit: ok so here's an artifact spawner script that plops any artifact item into anyone's inventory... the kicker is you probably don't wanna drop this.

Code: ('itemsummon.lua') [Select]
local dlg=require("gui.dialogs")
-- ok so this script is made for summoning gods into DF, to make this work you need to nickname someone historical that would form an army.
-- so the best choice would be either another adventurer or adv follower if you want the god to show up after fast traveling or assign the DFCAT nickname on some random peasant you talk to once.
-- going to give a warning about how this script messes with nemesis and probably unstable.
-- so BEST not use this on any important saves you care about and just test this out on an disposable save.
-- oh and the gods you summon won't really talk back if you reply to them.
-- this script uses coding from spawn unit and gui scripting to make it work, don't think this works in fort mode as this was made and tested in adv mode.
-- hopefully you have a better time getting gods to fight each other better than I did.

--that been edited to spawn items so it less likely to crash and corrupt saves hopefully
function deitysummoning()
local Ark={}
for k,v in pairs(df.global.world.artifacts.all) do
if v.item.flags.artifact==true or v.flags.artifact_mood==true then
BoaName=dfhack.TranslateName(v.name)
table.insert (Ark,{dfhack.TranslateName(v.name).." "..v.name.nickname,nil,v})
end
end
local f=function(Name,C)
  deitysummoning2(C[3])
end
dlg.showListPrompt("artifact list","Select your item for summoning",COLOR_RED,Ark,f)
end
function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end

function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end
function getItemAtKPos(x,y,z) -- gets the item index @ x,y,z coord
--local x,y,z=getxyz() --get 'X' coords
local vector=df.global.world.item.all -- load all items
local kickpos=df.global.world.units.active[0].pos
for i = 0, #vector-1 do -- look into all items offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==kickpos.x and cy==kickpos.y and cz==kickpos.z then --compare them
return vector[i] --return index
end
end
--print("item not found!")
return nil

end
function getCreatureAtPos(x,y,z) -- gets the creature index @ x,y,z coord
--local x,y,z=getxyz() --get 'X' coords
local vector=df.global.world.units.all -- load all creatures
for i = 0, #vector-1 do -- look into all creatures offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==x and cy==y and cz==z then --compare them
return vector[i] --return index
end
end
--print("Creature not found!")
return nil

end



function deitysummoning2(HistfigID)
Divineslot=HistfigID
 local horse=getCreatureAtPos(getxyz())
 print('God Nem ID',Divineslot.id)
 print('God Nem.figure ID',horse.id)
  horse.inventory:insert("#",{new=true,item=HistfigID.item,mode=2,body_part_id=0})
end

deitysummoning()



(https://cdn.discordapp.com/attachments/302956330304667649/1040633009541488670/item-summon-uhh-yeah.gif)

probably useful for getting a slab or a book or random trinkets from the world with out needing to search for it hard you do need to know the name of the artifact you're looking for.
also probably unstable I haven't tested how this works with saving yet.
Title: Re: DFHack 0.47.05-r7
Post by: Gnomedevourer on November 12, 2022, 01:31:38 pm
Is Advfort's tame animal job bugged? I couldn't get it to work, sadly, or was it always kind of not something possible to do?
if it is, is there any way for me to try and "tame" animals in adv mode?
(sorry if this is kind of out of place but this seemed like the right place to me at the time)
Title: Re: DFHack 0.47.05-r7
Post by: Rumrusher on November 13, 2022, 02:08:09 am
Is Advfort's tame animal job bugged? I couldn't get it to work, sadly, or was it always kind of not something possible to do?
if it is, is there any way for me to try and "tame" animals in adv mode?
(sorry if this is kind of out of place but this seemed like the right place to me at the time)
oh yeah advfort tame animal job is probably not possible to do, at best you could... toggle the tame flag on an animal through gm-editor... or use tofort to switch into fort mode while on site and go through the animal taming process through there.
there some jobs and options in adv fort that would have work but after I think 30.xx era they stop and the quick access to fort mode assign job stuff is now mostly doable with companions and npcs.

edit: ok so someone asked for an all doors script so I went and modified an earlier doors script to now give the player means to set all doors to be close, or pet accessible and or 7 different options.

Code: ('gui-doors.lua') [Select]
local dlg=require("gui.dialogs")

--warmist corpse explosion script modified to open doors now with gui function...
-- the F options will set door flags to false and the T options will set them to true
-- the ------- line option does nothing and there for visual to help separate the list
  local items={}


function doors()
  for _,checked_item in pairs(df.global.world.items.all) do
    if df.item_doorst:is_instance(checked_item) and checked_item.flags.in_building then
      table.insert(items,checked_item)
    end
  end

if #items==0 then
print"no Doors"
else
  for k,v in pairs(items) do
   knock=v.general_refs[0].building_id
  for o,lay in pairs(df.global.world.buildings.all) do
if lay.id==knock then
lay.door_flags[0]=true
end
  end
  end
      return true
end
end
  function doors1()
  for _,checked_item in pairs(df.global.world.items.all) do
    if df.item_doorst:is_instance(checked_item) and checked_item.flags.in_building then
      table.insert(items,checked_item)
    end
  end

if #items==0 then
print"no Doors"
else
  for k,v in pairs(items) do
   knock=v.general_refs[0].building_id
  for o,lay in pairs(df.global.world.buildings.all) do
if lay.id==knock then
lay.door_flags[1]=true
end
  end
  end
      return true
end
end
  function doors2()
  for _,checked_item in pairs(df.global.world.items.all) do
    if df.item_doorst:is_instance(checked_item) and checked_item.flags.in_building then
      table.insert(items,checked_item)
    end
  end

if #items==0 then
print"no Doors"
else
  for k,v in pairs(items) do
   knock=v.general_refs[0].building_id
  for o,lay in pairs(df.global.world.buildings.all) do
if lay.id==knock then
lay.door_flags[2]=true
end
  end
  end
      return true
end
end
  function doors3()
  for _,checked_item in pairs(df.global.world.items.all) do
    if df.item_doorst:is_instance(checked_item) and checked_item.flags.in_building then
      table.insert(items,checked_item)
    end
  end

if #items==0 then
print"no Doors"
else
  for k,v in pairs(items) do
   knock=v.general_refs[0].building_id
  for o,lay in pairs(df.global.world.buildings.all) do
if lay.id==knock then
lay.door_flags[3]=true
end
  end
  end
      return true
end
end
 function doors4()
  for _,checked_item in pairs(df.global.world.items.all) do
    if df.item_doorst:is_instance(checked_item) and checked_item.flags.in_building then
      table.insert(items,checked_item)
    end
  end

if #items==0 then
print"no Doors"
else
  for k,v in pairs(items) do
   knock=v.general_refs[0].building_id
  for o,lay in pairs(df.global.world.buildings.all) do
if lay.id==knock then
lay.door_flags[4]=true
end
  end
  end
      return true
end
end
 function doors5()
  for _,checked_item in pairs(df.global.world.items.all) do
    if df.item_doorst:is_instance(checked_item) and checked_item.flags.in_building then
      table.insert(items,checked_item)
    end
  end

if #items==0 then
print"no Doors"
else
  for k,v in pairs(items) do
   knock=v.general_refs[0].building_id
  for o,lay in pairs(df.global.world.buildings.all) do
if lay.id==knock then
lay.door_flags[5]=true
end
  end
  end
      return true
end
end
 function doors6()
  for _,checked_item in pairs(df.global.world.items.all) do
    if df.item_doorst:is_instance(checked_item) and checked_item.flags.in_building then
      table.insert(items,checked_item)
    end
  end

if #items==0 then
print"no Doors"
else
  for k,v in pairs(items) do
   knock=v.general_refs[0].building_id
  for o,lay in pairs(df.global.world.buildings.all) do
if lay.id==knock then
lay.door_flags[6]=true
end
  end
  end
      return true
end
end
function fdoors()
  for _,checked_item in pairs(df.global.world.items.all) do
    if df.item_doorst:is_instance(checked_item) and checked_item.flags.in_building then
      table.insert(items,checked_item)
    end
  end

if #items==0 then
print"no Doors"
else
  for k,v in pairs(items) do
   knock=v.general_refs[0].building_id
  for o,lay in pairs(df.global.world.buildings.all) do
if lay.id==knock then
lay.door_flags[0]=false
end
  end
  end
      return true
end
end
  function fdoors1()
  for _,checked_item in pairs(df.global.world.items.all) do
    if df.item_doorst:is_instance(checked_item) and checked_item.flags.in_building then
      table.insert(items,checked_item)
    end
  end

if #items==0 then
print"no Doors"
else
  for k,v in pairs(items) do
   knock=v.general_refs[0].building_id
  for o,lay in pairs(df.global.world.buildings.all) do
if lay.id==knock then
lay.door_flags[1]=false
end
  end
  end
      return true
end
end
  function fdoors2()
  for _,checked_item in pairs(df.global.world.items.all) do
    if df.item_doorst:is_instance(checked_item) and checked_item.flags.in_building then
      table.insert(items,checked_item)
    end
  end

if #items==0 then
print"no Doors"
else
  for k,v in pairs(items) do
   knock=v.general_refs[0].building_id
  for o,lay in pairs(df.global.world.buildings.all) do
if lay.id==knock then
lay.door_flags[2]=false
end
  end
  end
      return true
end
end
  function fdoors3()
  for _,checked_item in pairs(df.global.world.items.all) do
    if df.item_doorst:is_instance(checked_item) and checked_item.flags.in_building then
      table.insert(items,checked_item)
    end
  end

if #items==0 then
print"no Doors"
else
  for k,v in pairs(items) do
   knock=v.general_refs[0].building_id
  for o,lay in pairs(df.global.world.buildings.all) do
if lay.id==knock then
lay.door_flags[3]=false
end
  end
  end
      return true
end
end
 function fdoors4()
  for _,checked_item in pairs(df.global.world.items.all) do
    if df.item_doorst:is_instance(checked_item) and checked_item.flags.in_building then
      table.insert(items,checked_item)
    end
  end

if #items==0 then
print"no Doors"
else
  for k,v in pairs(items) do
   knock=v.general_refs[0].building_id
  for o,lay in pairs(df.global.world.buildings.all) do
if lay.id==knock then
lay.door_flags[4]=false
end
  end
  end
      return true
end
end
 function fdoors5()
  for _,checked_item in pairs(df.global.world.items.all) do
    if df.item_doorst:is_instance(checked_item) and checked_item.flags.in_building then
      table.insert(items,checked_item)
    end
  end

if #items==0 then
print"no Doors"
else
  for k,v in pairs(items) do
   knock=v.general_refs[0].building_id
  for o,lay in pairs(df.global.world.buildings.all) do
if lay.id==knock then
lay.door_flags[5]=false
end
  end
  end
      return true
end
end
 function fdoors6()
  for _,checked_item in pairs(df.global.world.items.all) do
    if df.item_doorst:is_instance(checked_item) and checked_item.flags.in_building then
      table.insert(items,checked_item)
    end
  end

if #items==0 then
print"no Doors"
else
  for k,v in pairs(items) do
   knock=v.general_refs[0].building_id
  for o,lay in pairs(df.global.world.buildings.all) do
if lay.id==knock then
lay.door_flags[6]=false
end
  end
  end
      return true
end
end
function none()
--"divider line for gui"
end

  listofspells={
{text="forbidden", spell=doors,icon='T'},
{text="internal", spell=doors1,icon='T'},
{text="taken_by_invaders", spell=doors2,icon='T'},
{text="used_by_intruder", spell=doors3,icon='T'},
{text="closed", spell=doors4,icon='T'},
{text="operated_by_mechanisms", spell=doors5,icon='T'},
{text="pet_passable", spell=doors6,icon='T'},
{text="----------", spell=none,icon='-'},
{text="forbidden", spell=fdoors,icon='F'},
{text="internal", spell=fdoors1,icon='F'},
{text="taken_by_invaders", spell=fdoors2,icon='F'},
{text="used_by_intruder", spell=fdoors3,icon='F'},
{text="closed", spell=fdoors4,icon='F'},
{text="operated_by_mechanisms", spell=fdoors5,icon='F'},
{text="pet_passable", spell=fdoors6,icon='F'},
}

dlg.showListPrompt("Doorections","Choze Doorect option 'T'rue or 'F'alse",nil, listofspells,function(index,choice) choice.spell() end)

Title: Re: DFHack 0.47.05-r7
Post by: Gnomedevourer on November 13, 2022, 04:46:42 am
ah, thank you! I suppose that'd be what I'll be doing from now on!
Title: Re: DFHack 0.47.05-r7
Post by: mross on November 24, 2022, 11:14:08 pm
How do I stop dfhack from autosaving my game?
Title: Re: DFHack 0.47.05-r7
Post by: Putnam on November 24, 2022, 11:45:19 pm
How do I stop dfhack from autosaving my game?

Uninstall the vettlingr tileset, which adds a monthly quicksave for some reason. Or remove that from the install, don't quite recall how.
Title: Re: DFHack 0.47.05-r7
Post by: Ziusudra on November 25, 2022, 12:04:02 am
How do I stop dfhack from autosaving my game?
In the file PE-0.47.05-r11/LNP/graphics/Vettlingr/raw/onLoad_gfx_Vettlingr.init add a # to the beginning of the line that contains -command [ quicksave ], that will make that line a comment and prevent it from running.

Edit: there's maybe a similar file copied into the save folder somewhere that might also need to be changed
Title: Re: DFHack 0.47.05-r7
Post by: Rumrusher on November 28, 2022, 09:29:27 am
Code: ('justSum4.lua') [Select]
local dlg=require("gui.dialogs")
-- ok so this script is made for summoning gods into DF re-re-edited to just summon any historical figure so far, for this to work all you need is to be in fast traveling.
-- after which the game will spawn in a unit directly next to you.
-- going to give a warning about how this script messes with nemesis and probably less unstable than summoning gods though you might get killed summoning a larger hostile foe.
-- so BEST not use this on any important saves you care about and just test this out on an disposable save.
-- so far as a script that summons folks go this cuts down looking for them.
-- this script uses coding from spawn unit and gui scripting to make it work, don't think this works in fort mode as this was made and tested in adv mode.
-- so far getting two folks to hostile creatures and beasts fight with this is a breeze.

function justsummoning()
local Ark={}
for k,v in pairs(df.global.world.history.figures) do
BoaName=dfhack.TranslateName(v.name)
table.insert (Ark,{dfhack.TranslateName(v.name).." "..v.name.nickname,nil,v,search_key = dfhack.TranslateName(v.name):lower()})
end
local f=function(Name,C)
  justsummoning2(C[3])
end
dlg.showListPrompt("HistFig list","Select your figure for summoning",COLOR_WHITE,Ark,f,nil,nil,true)
end


function getArmyAtName(Divineslot)
for k,v in pairs(df.global.world.nemesis.all) do
if v.flags.ACTIVE_ADVENTURER then
print("Adv Nem",k)
local Cat=df.global.world.armies.all
for k1,v1 in pairs(Cat) do
if v1.members==nil then break else
for Del,ete in pairs(v1.members) do
if ete.nemesis_id==v.id then
print("Adv Army",k1)
return k1
end
end
end
end
end
end
end

function justsummoning2(HistfigID)
Divineslot=HistfigID.nemesis_id
 local horse=Divineslot
 print('Summon Nem ID',Divineslot)
 local NeArmy=getArmyAtName()
  df.global.world.armies.all[NeArmy].members:insert("#",{new=true,nemesis_id=horse})
end


justsummoning()

ok so here's a script made for locating key folks in your adventurers... by just warping them to your location with use of fast travel armies.
be warn the folks with no name are an mix bag on what you might pull. also this version of the script has a bare bones search function for user ease... but not super user ease like the other scripts in the dfhack repo.
would give the same warning about not knowing how unstable this script would do to the game but given it's inserting a one time hist fig into your party I feel like it's more stable than the usual.
Title: Re: DFHack 0.47.05-r7
Post by: A_Curious_Cat on December 01, 2022, 12:59:07 am
Any news on the agui library?  I’m asking because it isn’t available as a precompiled package for my system and it’s needed for stonesense and isoworld.  I did have it working before on an older version of DFHack using instructions that somebody had posted to an older DFHack thread, but those instructions stopped working with newer versions of DFHack.
Title: Re: DFHack 0.47.05-r7
Post by: lethosor on December 01, 2022, 08:34:43 pm
Any news on the agui library?  I’m asking because it isn’t available as a precompiled package for my system and it’s needed for stonesense and isoworld.  I did have it working before on an older version of DFHack using instructions that somebody had posted to an older DFHack thread, but those instructions stopped working with newer versions of DFHack.
Can you link to those instructions? The only thing I see that uses agui is isoworld, and it appears to bundle agui, so I'm not sure why installing it separately is necessary.
Title: Re: DFHack 0.47.05-r7
Post by: A_Curious_Cat on December 01, 2022, 09:07:23 pm
Any news on the agui library?  I’m asking because it isn’t available as a precompiled package for my system and it’s needed for stonesense and isoworld.  I did have it working before on an older version of DFHack using instructions that somebody had posted to an older DFHack thread, but those instructions stopped working with newer versions of DFHack.
Can you link to those instructions? The only thing I see that uses agui is isoworld, and it appears to bundle agui, so I'm not sure why installing it separately is necessary.

Huh?  Interesting, I was getting an error about not being able to find agui when I was compiling 0.47.05-r6 and I could’ve sworn it wouldn’t go away until I disabled compilation of both isoworld and stonesense…

Anyways, I’m only seeing two other posts about agui in this forum other than this one and my previous one.  This one (http://www.bay12forums.com/smf/index.php?topic=139553.msg6904610#msg6904610) seems to be the most relevant (the other (http://www.bay12forums.com/smf/index.php?topic=70700.msg6454943#msg6454943) just states that they compiled agui by hand but doesn’t say how). 

I could’ve sworn I was able to compile agui by hand on an older version, but that the instructions stopped working after a newer version of DFHack came out.  I also could’ve sworn there were more precise instructions. 

In any case, I believe that the root problem is that DFHack assumes that the person compiling it already has agui available on their system (which is a problem if they are using a Linux distribution (such as Debian, for example) that doesn’t include agui in it’s package repository).  It’d be nice DFHack could pull in and compile agui automatically whenever it is compiled.

Edit:

Maybe the best thing for me to do would be to try recompiling DFHack again and post the output. Also, maybe try and do the same with agui.

Edit2:

Whelp!  The fun stops here.

I cloned DFHack and then proceeded to use ccmake to configure it for compilation but it spat out an error message about me needing a newer version of allegro.  “Fine.  I can just upgrade to the new version.”, I thought.  Then, when I went to upgrade, the package manager spat out a bunch of error that seem to be related to changes that the author of the distribution made when deriving the distribution from Debian (I’ve had problems updating before (for example, the package manager wanting to completely remove both the init system and glibc).  I’ve now got two choices:  A) wait for the author to release a new version of the distribution (it’s already more than a year past when one would’ve expected that to happen based on previous releases), or B) switch to a different distribution (I already know which one I’m going to choose)…
Title: Re: DFHack 0.47.05-r7
Post by: myk on December 02, 2022, 10:03:06 am
Allegro is downloaded by the stonesense build code. You shouldn't have to do anything at the system level. There is a CMake build option called "Link with prebuilt internal allegro libs and headers" that is on by default. Maybe check to see if this option has somehow been disabled?
Title: Re: DFHack 0.47.05-r7
Post by: myk on December 02, 2022, 02:55:40 pm
DFHack 0.47.05-r8 has been released!

Download it here (https://github.com/DFHack/dfhack/releases/tag/0.47.05-r8)



This is the second usability-focused release of DFHack. In the previous release (https://github.com/DFHack/dfhack/releases/tag/0.47.05-r7), we made initial progress with the in-game command launcher with autocomplete and integrated command help. This release builds on that start with improved mouse controls (like draggable scrollbars) and a brand new framework for on-screen informational overlays and interactive widgets that respond to what's currently happening in the game.

The cool thing is that this overlay framework is ready for use by mods, including Steam Workshop mods! All modders have to do is declare an OverlayWidget in their script code and the overlay framework will discover it and attach it to the correct Dwarf Fortress screens. Players can enable, disable, or reposition overlay widgets with the new click-and-drag gui/overlay (https://docs.dfhack.org/en/stable/docs/tools/gui/overlay.html#gui-overlay) configuration interface. You can start playing with this interface with the overlay widgets that we've already ported to the new framework, such as the date, happiness meter, and weather indicator from dwarfmonitor (https://docs.dfhack.org/en/stable/docs/tools/dwarfmonitor.html#widget-configuration).

Q: Wait! Go back! So DFHack is ready for the steam release now??

A: No, sorry, not yet. We have a lot of work to do to adapt DFHack to the new Dwarf Fortress release. It might take us a few months, but you will have your favorite tools back. And we hope to have even more usability improvements ready for you then too!

Q: So, like, why are you releasing now? Don't you know that the Steam release is in a few days?

A: Yeah, we know. This release is more for those who aren't upgrading right away, like players who aren't on Steam, adventure mode players, and, of course, players who want to wait for DFHack to become available for the new version before they switch to it : )

Highlights


The Hotkeys Hotspot

(https://user-images.githubusercontent.com/977482/205192543-8cd25c6a-c4e0-42e2-abbb-1fac9377b0c2.gif)

The major new feature is the Hotkeys Hotspot (https://docs.dfhack.org/en/stable/docs/tools/hotkeys.html#menu-overlay-widget). You may not know this, but DFHack has many default keybindings that are bound to specific Dwarf Fortress screens (like the manager orders screen or the main map) that run useful DFHack commands. For example, when you're on the manager orders screen and have a manager order selected, you can hit Alt-Q to change the number of items that the workorder will produce.

The Hotkeys Hotspot uses the new overlay framework to provide a mouse rollover menu that makes these bound commands available to you in a clickable list. You can also right-click on them to open them in the in-game launcher to modify the command and/or see the associated command help. You can add more commands to this list (or take some away) via the DFHack keybinding (https://docs.dfhack.org/en/stable/docs/tools/keybinding.html#keybinding) command, too.

You can show the rollover menu by moving your mouse near the upper left corner of the screen, a little down from the top. On the main map, this spot is marked by an exclamation point (!), but the spot is "hot" on every screen, even if the exclamation point is covered up by something. You can reposition the hotspot with gui/overlay if you want it in a more convenient place. You can also bring it up with the keyboard instead of the mouse by hitting the Ctrl-Shift-C hotkey.

gui/overlay

(https://user-images.githubusercontent.com/977482/205193369-42d8bbb6-3a74-42fc-8991-7421619409a0.gif)

gui/overlay (https://docs.dfhack.org/en/latest/docs/tools/gui/overlay.html#gui-overlay) is the beginning of a new trend for DFHack: in-game configuration that remembers your choices from game to game without any editing of init files. Also, notice the fancy new mouse controls like mouse hover reactions and click-and-drag widgets. Expect to see more of this from DFHack in the future!

spectate

The spectate (https://docs.dfhack.org/en/stable/docs/tools/spectate.html#spectate) plugin has seen a good bit of improvement in this release. Once your fort is in a good, steady state, try firing this tool up to automatically follow dwarves around, switching among them periodically, so you can sit back and watch your dwarves be dwarfy!

channel-safely

The new channel-safely (https://docs.dfhack.org/en/stable/docs/tools/channel-safely.html#channel-safely) tool protects your dwarves from digging themselves to death while channeling out large projects. Digging a large drowning trap or a magma piston? Give this tool a try!

How to upgrade



Full upgrade instructions are available online here (https://docs.dfhack.org/en/stable/docs/Installing.html#upgrading-dfhack)

Full changelog


Spoiler (click to show/hide)
Title: Re: DFHack 0.47.05-r8
Post by: HammerDave on December 03, 2022, 02:48:28 pm
I will have a window of opportunity to work on upgrade, if doing so looks like it will be a net add.  If it looks like it would take more effort to bring a legendary but rusty coder up to speed than the benefit then I'll just stay out of your way.   8)
Title: Re: DFHack 0.47.05-r8
Post by: myk on December 03, 2022, 04:03:48 pm
There are several active projects within DFHack that you are welcome to get involved with (and that we really need help with!). Let me list a few:

1. Ruby turndown
DFHack is looking at options for distribution via Steam. One of the blockers for this is DFHack's support for Ruby as a scripting language. It causes too many support issues. We need to rewrite existing Ruby scripts in Lua so we can remove ruby support without losing popular functionally.

2. Initless
As part of DFHack's ongoing usability overhaul, we're trying to make init scripts completely optional. This means that many tools need to be updated to persist their state so that init files don't need to be edited by the user to get the game back into a preferred configuration. Plugins can (and some already do) reload their state when the plugin is loaded, but we need to design and implement a similar mechanism for scripts, which have no analogous "load" hook. We have some thoughts about how this can be accomplished, but it needs more careful and thorough design.

3. GUI config for automation tools
Also part of the usability track. Many of DFHack's most popular automation tools lack in-game configuration UIs. Moreover, many of the existing UIs need to be rethought for the steam release. The DFHack UI widget library has matured significantly in recent releases, so there are many useful primatives for building UIs now.

So, lots and lots of opportunities. What sounds interesting to you? We do most of our discussion and planning on discord nowadays. https://dfhack.org/discord

Of course, there's also the immediate need of reverse engineering, if you'd like to get involved with that too!
Title: Re: DFHack 0.47.05-r8
Post by: Bumber on December 05, 2022, 08:12:47 am
"channel-safely" certainly sounds handy.
Title: Re: DFHack 0.47.05-r8
Post by: Rumrusher on December 17, 2022, 02:36:45 pm
Code: ("crabhistory.lua") [Select]
for k,v in pairs(df.global.world.history.events_death) do
if df.history_event_hist_figure_diedst:is_instance(v) and v.slayer_hf==-1 and v.death_cause~=0 then
v.slayer_hf=0
end
end

ok so wrote a script for folks who care about legendary beasts dying in legendary ways and not by a the site's population well... here's a silly quick fix that applies all non-historical figure kills to historical figure id 0 which usually be a megabeast.

so now you can have uhh some bronze colossus get sniped by a dragon while said bronze colossus was rampaging a local town,
a whole lot more deaths done by the first megabeast, them probably dying to themselves.

so for the changes to stick best run this script during world generation usually pausing world gen to run it works best, and to probably make most of the history be mapped to one histfig uhh probably end the world gen after running the script.

(https://cdn.discordapp.com/attachments/302956330304667649/1053756787498688613/this-hydra-died-to-this-roc.png)
Title: Re: DFHack 0.47.05-r8
Post by: Afghani84 on December 19, 2022, 05:36:28 pm
do all of the DFHack features need to be reworked for the Steam release or are some already working? I'm especially interested in autodump.

thanks to everyone working on this awesome tool!
Title: Re: DFHack 0.47.05-r8
Post by: myk on December 19, 2022, 06:52:10 pm
You can track which tools have been validated in the steam release here: https://docs.google.com/spreadsheets/d/1hiDlo8M_bB_1jE-5HRs2RrrA_VZ4cRu9VXaTctX_nwk/edit?usp=drivesdk

Check the Tools sheet. We're validating them in "waves". Right now we're in wave 2.
Title: Re: DFHack 0.47.05-r8
Post by: Dr. Hieronymous Alloy on December 20, 2022, 07:09:23 pm
You can track which tools have been validated in the steam release here: https://docs.google.com/spreadsheets/d/1hiDlo8M_bB_1jE-5HRs2RrrA_VZ4cRu9VXaTctX_nwk/edit?usp=drivesdk

Check the Tools sheet. We're validating them in "waves". Right now we're in wave 2.

Yoinks, that's a lot of work to be done.
Title: Re: DFHack 0.47.05-r8
Post by: Robsoie on December 22, 2022, 08:28:57 pm
It's been a while i haven't used dfhack, so i downloaded the latest r8 version.
When i wanted to check the dfhack.init-example file i noticed there was none anymore, checked the ...\hack\examples\init\ and there's only a onMapLoad_dreamfort.init

So question : can i simply use an old (i think it was one of the last of the 44.x serie of DF) dfhack.int and move it to dfhack-config\init\  or have thing changed so much that chances are very high that things will just break (it seems to work but i don't know how much dfhack has changed since that) ?

Title: Re: DFHack 0.47.05-r8
Post by: myk on December 22, 2022, 09:38:18 pm
Unless you have specific custom settings that you want to keep, you don't need your own dfhack.init file. The defaults are automatically handled for you now. You can still add/override settings in dfhack-config/init/dfhack.init if you wish, though.
Title: Re: DFHack 0.47.05-r8
Post by: Robsoie on December 23, 2022, 08:37:27 am
Ah ok thanks, i was worried nothing was enabled by default.
Title: Re: DFHack 0.47.05-r8
Post by: Felius on December 24, 2022, 08:02:23 pm
You can track which tools have been validated in the steam release here: https://docs.google.com/spreadsheets/d/1hiDlo8M_bB_1jE-5HRs2RrrA_VZ4cRu9VXaTctX_nwk/edit?usp=drivesdk

Check the Tools sheet. We're validating them in "waves". Right now we're in wave 2.
Is there some particular install instructions to install it in the Steam version, even if only to get the already validated tools? Tried to just override, but then DF refuses to work because of the SQL override.
Title: Re: DFHack 0.47.05-r8
Post by: myk on December 24, 2022, 08:19:49 pm
There are builds at dfhack.org/builds as usual, but we're still very early in the process of reverse engineering the memory layout changes. I can vouch that DFHack itself can be loaded and you can use Lua to inspect data structures, but it's not ready for actually playing the game yet. Unless you're interested in the programming side of things, you're better off waiting until we have an official alpha release.
Title: Re: DFHack 0.47.05-r8
Post by: PatrikLundell on December 25, 2022, 11:51:28 am
I'm having trouble with upgrading my DFHack build environment to work with what's currently in DFHack, as things apparently have changed since I last did anything DFHack related (probably early this year).

I've started with https://docs.dfhack.org/en/stable/docs/dev/Compile.htm (https://docs.dfhack.org/en/stable/docs/dev/Compile.htm) when things didn't work right away. The document's Compiling DFHack/Windows section indicates you have an option of using MSVC 2022 or MSVC 2019, but indications are that this isn't correct, as <DFHack>\build\win64\generate-MSVC-gui.bat first suspiciously creates a VC2022 directory, and then fails due to an inability of cmake to find generator "Visual Studio 17 2022". Installing VC2022 (in addition to the preexisting 2015, 2017, and 2019 versions, the last two of which were updated) didn't help in getting cmake find the required generator, nor did a forced reinstall of cmake (in case the identification of those "generators" were somehow  part of that package but failed to be identified as a version update).
It can also be noted that I wasn't able to select "C++ Windows XP Support for VS 2017 (v141) toos [Deprecated]" as it wasn't available in the list, but given that it was already install and I carefully refrained from selecting to purge the system of unsupported stuff it should still remain, but might cause problems for people starting from scratch.

My intended use is currently structure mapping.
Title: Re: DFHack 0.47.05-r8
Post by: lethosor on December 25, 2022, 12:09:47 pm
I think 2022 is required on Windows now - that sounds familiar. DF definitely upgraded to a newer compiler than 2015, but I can't quite tell from our build image changes (https://github.com/BenLubar/build-env/commits/master/msvc) whether it was 2022.

Also, you're looking at the docs for the last stable release, which was for 0.47.05, so that will still say 2015 until we have a stable release for v50. You can find docs for the develop branch at https://docs.dfhack.org/en/latest/docs/dev/Compile.html or by selecting "latest" in the version selector at the bottom right. That page still isn't updated, but it will be updated sooner than the stable page.

(Glad to have your help!)
Title: Re: DFHack 0.47.05-r8
Post by: ab9rf on December 25, 2022, 07:11:42 pm
I think 2022 is required on Windows now - that sounds familiar. DF definitely upgraded to a newer compiler than 2015, but I can't quite tell from our build image changes (https://github.com/BenLubar/build-env/commits/master/msvc) whether it was 2022.
We know for certain that it's at least 2019, and I believe Toady told us (possibly through a backchannel) that he was moving to 2022.
Title: Re: DFHack 0.47.05-r8
Post by: Bumber on December 26, 2022, 05:41:25 pm
Installing VC2022 (in addition to the preexisting 2015, 2017, and 2019 versions, the last two of which were updated) didn't help in getting cmake find the required generator, nor did a forced reinstall of cmake (in case the identification of those "generators" were somehow  part of that package but failed to be identified as a version update).

I've always had to run the .bat files from the Developer Command Prompt (under Programs->Visual Studio 20XX->Visual Studio Tools) to have it be found properly.
Title: Re: DFHack 0.47.05-r8
Post by: PatrikLundell on December 27, 2022, 03:29:09 am
Thanks lethosor for pointing out both that I was barking up the wrong tree, but that barking would have ensued even if I'd found the right one.

Also thanks to Bumber for the suggestion, although it didn't work.
In the past I've used the fallback of the Powershell command prompt when .bat files started directly from the File Explorer failed to work, and I've tried that here as well. I believe I've found the tool Bumber refers to (rather different path on my system, but it seems to be the same tool, which can also be invoked from VS itself), but unfortunately that doesn't help cmake find the version it's looking for. It was worth trying, however.
Title: Re: DFHack 0.47.05-r8
Post by: ab9rf on December 27, 2022, 04:12:50 am
Thanks lethosor for pointing out both that I was barking up the wrong tree, but that barking would have ensued even if I'd found the right one.

Also thanks to Bumber for the suggestion, although it didn't work.
In the past I've used the fallback of the Powershell command prompt when .bat files started directly from the File Explorer failed to work, and I've tried that here as well. I believe I've found the tool Bumber refers to (rather different path on my system, but it seems to be the same tool, which can also be invoked from VS itself), but unfortunately that doesn't help cmake find the version it's looking for. It was worth trying, however.
if you have more than one version of VS installed, cmake may not find the one you want (it picks one "at random"). You need to tell cmake which version you want it to use by setting the CMAKE_GENERATOR_INSTANCE variable. See https://cmake.org/cmake/help/latest/variable/CMAKE_GENERATOR_INSTANCE.html (https://cmake.org/cmake/help/latest/variable/CMAKE_GENERATOR_INSTANCE.html)
Title: Re: DFHack 0.47.05-r8
Post by: PatrikLundell on December 27, 2022, 05:57:49 am
@ab9rf: Thanks for your suggestion. I may well fail to understand things correctly, but I don't think the issue is designation of the version as "cmake ..\..\.. -G"Visual Studio 17 2022" -A x64 -DCMAKE_INSTALL_PREFIX="%_DF_PATH%" seems to insist on using the 2022 version, producing the following error message:

CMake Error: Could not create named generator Visual Studio 17 2022

Generators
* Visual Studio 16 2019        = Generates Visual Studio 2019 project files.
                                 Use -A option to specify architecture.
  Visual Studio 15 2017 [arch] = Generates Visual Studio 2017 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 14 2015 [arch] = Generates Visual Studio 2015 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 12 2013 [arch] = Generates Visual Studio 2013 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 11 2012 [arch] = Generates Visual Studio 2012 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 10 2010 [arch] = Generates Visual Studio 2010 project files.
                                 Optional [arch] can be "Win64" or "IA64".
  Visual Studio 9 2008 [arch]  = Generates Visual Studio 2008 project files.
                                 Optional [arch] can be "Win64" or "IA64".
  Borland Makefiles            = Generates Borland makefiles.
  NMake Makefiles              = Generates NMake makefiles.
  NMake Makefiles JOM          = Generates JOM makefiles.
  MSYS Makefiles               = Generates MSYS makefiles.
  MinGW Makefiles              = Generates a make file for use with
                                 mingw32-make.
  Unix Makefiles               = Generates standard UNIX makefiles.
  Green Hills MULTI            = Generates Green Hills MULTI files
                                 (experimental, work-in-progress).
  Ninja                        = Generates build.ninja files.
  Watcom WMake                 = Generates Watcom WMake makefiles.
  CodeBlocks - MinGW Makefiles = Generates CodeBlocks project files.
  CodeBlocks - NMake Makefiles = Generates CodeBlocks project files.
  CodeBlocks - NMake Makefiles JOM
                               = Generates CodeBlocks project files.
  CodeBlocks - Ninja           = Generates CodeBlocks project files.
  CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
  CodeLite - MinGW Makefiles   = Generates CodeLite project files.
  CodeLite - NMake Makefiles   = Generates CodeLite project files.
  CodeLite - Ninja             = Generates CodeLite project files.
  CodeLite - Unix Makefiles    = Generates CodeLite project files.
  Sublime Text 2 - MinGW Makefiles
                               = Generates Sublime Text 2 project files.
  Sublime Text 2 - NMake Makefiles
                               = Generates Sublime Text 2 project files.
  Sublime Text 2 - Ninja       = Generates Sublime Text 2 project files.
  Sublime Text 2 - Unix Makefiles
                               = Generates Sublime Text 2 project files.
  Kate - MinGW Makefiles       = Generates Kate project files.
  Kate - NMake Makefiles       = Generates Kate project files.
  Kate - Ninja                 = Generates Kate project files.
  Kate - Unix Makefiles        = Generates Kate project files.
  Eclipse CDT4 - NMake Makefiles
                               = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - MinGW Makefiles
                               = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Ninja         = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.

I've looked at the environment variables, and found VS140COMNTOOLS and the corresponding ones for 12 and 10, but notably not 16, which is still picked up by cmake, indicating cmake uses something other than these variables to locate VS generators. Manually adding the 17 version for VS2022 doesn't help cmake find it.

I've also tried to set up the CMAKE_GENERATOR_INSTANCE variable to point to the same location as the VS170COMNTOOLS variable. That failed with the new message "Warning: Environment variable CMAKE_GENERATOR_INSTANCE will be ignored, because CMAKE_GENERATOR is not set." Looking at the CMAKE_GENERATOR documentation, it indicates this variable is used only when there is no generator specified via the -G parameter, so I suspect this set of environment variables isn't really applicable to the DFHack usage.
Title: Re: DFHack 0.47.05-r8
Post by: Clément on December 27, 2022, 06:08:35 am
You should update cmake. It is not that it does not find MSVC, it's that it doesn't know it.
Title: Re: DFHack 0.47.05-r8
Post by: ab9rf on December 27, 2022, 11:02:48 am
@ab9rf: Thanks for your suggestion. I may well fail to understand things correctly, but I don't think the issue is designation of the version as "cmake ..\..\.. -G"Visual Studio 17 2022" -A x64 -DCMAKE_INSTALL_PREFIX="%_DF_PATH%" seems to insist on using the 2022 version, producing the following error message:

CMake Error: Could not create named generator Visual Studio 17 2022
Your cmake is too old. cmake versions prior to 3.21 do not know what VS 2022 is and thus cannot use it.
Title: Re: DFHack 0.47.05-r8
Post by: PatrikLundell on December 27, 2022, 01:42:33 pm
I tried to check for a cmake update, but "choco install git cmake.portable strawberryperl -y", which is also claimed to be useful for updating them, does not think there is anything to update.

I then went one step back to try to see going to the chocolatey web page and install it again would work. Firstly, that web page has changed, so the command you're instructed to locate isn't present (i.e. the Compile.html document needs to be update). Secondly, using the "choco upgrade chocolatey" command buried in the script for when it's already installed does not upgrade the cmake.portable version past v3.16.2 (I didn't note what version it used before running that command, so it may or may not have been the same), which is lower than the one required.
Trying to run the installation script resulted in the expected result, i.e. refusal to proceed due to the presence of an earlier installation and the recommendation to run the upgrade command.

Ah, bugger. "choco upgrade chocolatey" apparently only upgrades itself, not any of its sub packages. "choco find cmake" shows that it actually "knows" about newer versions that the higher level installation decided not to mention were available, in favor for what was installed. Thus "choco upgrade cmake.portable" actually installs a current version. Presumably the same manual upgrade process has to be applied to git and strawberryperl as well. It's possible "choco upgrade all --noop" might do this in one go, but I haven't tried it (I'm just finding choco commands in choco.summary.log, trying to find what needs/can be done).

Well, strawberryperl doesn't want to be updated on my system, so I'll just leave it be.
I'm currently at the stage where I'm actually able to generate DFHack. Hopefully this rambling might be helpful to someone else trying to upgrade to the current standard.

Thanks to @ab9rf for identifying the root of the issue.

Edit:
OK, it looks like I'm stuck for the time being. DFHack doesn't seem to recognize the Classic version, which is what I'd intended to use until keyboard support has been restored (at which time I intend to buy it via Itch.io, not Steam, which may have a different layout from the 4 steam versions it seems to recognize, based on the stderr.log contents).
Title: Re: DFHack 0.47.05-r8
Post by: lethosor on December 27, 2022, 03:05:51 pm
OK, it looks like I'm stuck for the time being. DFHack doesn't seem to recognize the Classic version, which is what I'd intended to use until keyboard support has been restored (at which time I intend to buy it via Itch.io, not Steam, which may have a different layout from the 4 steam versions it seems to recognize, based on the stderr.log contents).
I believe Steam, Itch, and Classic are all different executables. Steam is definitely different, at least. I might be able to generate symbols for classic. We do fully intend to support all of them, but most analysis has been happening on the Steam build so far.

It's also worth noting that the three builds have exactly the same keyboard support (not quite sure if you were aware).
Title: Re: DFHack 0.47.05-r8
Post by: PatrikLundell on December 27, 2022, 04:03:09 pm
Thanks @lethosor for confirming that there are probably 3 different executables.

I was indeed aware that the underlying code (and thus keyboard support) was the same for all versions. However, since I don't actually intend to play DF in the near term, but I don't want to pay for an unplayable version (being a stubborn old bugger), I thought Classic would be a good version to use for layout investigations. After all, the layout differences between the versions ought to be a matter of an offset (or possibly a small number of them), so any layout investigation results ought to apply to all of them once the version offsets have been figured out.

However, don't bend over backwards for my sake, as I'm not in a great hurry: I won't cry if someone beats me to finding something :). I did think, though, that many of the prominent DFHack figures were using Linux, and thus that there might be a bit of a shortage of Windows using investigators compared to the normal situation.
Title: Re: DFHack 0.47.05-r8
Post by: lethosor on December 27, 2022, 05:53:05 pm
Yeah, lack of a Linux build is slowing us down a bit. We've gotten DF and MSVC running through Wine, but some of the Linux-specific tools don't work.
Title: Re: DFHack 0.47.05-r8
Post by: ab9rf on December 27, 2022, 06:17:30 pm
OK, it looks like I'm stuck for the time being. DFHack doesn't seem to recognize the Classic version, which is what I'd intended to use until keyboard support has been restored (at which time I intend to buy it via Itch.io, not Steam, which may have a different layout from the 4 steam versions it seems to recognize, based on the stderr.log contents).
we have yet to analyze either the itch.io or classic executables yet, so we only have symbols.xml for steam releases. it's on the agenda, certainly, but i haven't done it in part because we know that a major structure (gamest) is larger in Steam than in classic (and probably also itch) because there's stuff in there for the steam workshop, and so we need to come up with a strategy for dealing with having a structure that is different between releases of the same version on the same platform, which we've never had to deal with before now. we discussed this a few days ago, but honestly i've been sick since christmas eve and haven't had the chance to process the discussion and turn the results of it into a working strategy
Title: Re: DFHack 0.47.05-r8
Post by: PatrikLundell on December 28, 2022, 04:41:41 am
Thanks for the info. It's probably better to wait with decisions that aren't urgent until the brain is back up to speed than to rush things only to potentially redo them later (and forcing a reluctant body to do things that aren't required is no fun either).

I guess the variant handling strategy would differ depending on whether the extra guff is just a big lump somewhere or whether it's sprinkled in little annoying pieces throughout the structure.
Title: Re: DFHack 0.47.05-r8
Post by: Clément on December 28, 2022, 08:47:24 am
I have built the latest DFHack using BenLubar's docker image. When I copy the files over the Steam directory it seems to work (at least the basics, I get a console window and I can load a game). If I do the same with a copy of the steam version outside of steam and run it with Fedora's wine (wine-7.22 (Staging), running "wine Dwarf\ Fortress.exe"), I don't get a console and DF freezes when I load a game or quit. Without dfhack the same wine version and prefix appears to work. Does dfhack requires a special wine configuration that Steam has, but my distribution wine doesn't?
Title: Re: DFHack 0.47.05-r8
Post by: lethosor on December 28, 2022, 12:51:07 pm
Try
Code: [Select]
wine explorer "Dwarf Fortress.exe"
Another oddity I've noticed under Wine is that "die" seems to hang indefinitely, but closing the console window has been a working alternative for me (and works before or after I run "die")
Title: Re: DFHack 0.47.05-r8
Post by: Clément on December 29, 2022, 07:57:12 am
Thanks, it worked.
Title: Re: DFHack 0.47.05-r8
Post by: jecowa on December 29, 2022, 07:57:54 pm
Wow, you already have a build of DFHack going. Is v50 a bigger load of work to update DFHack for than previous major updates? Or is every major update about the same for DFHack?
Title: Re: DFHack 0.47.05-r8
Post by: ab9rf on December 29, 2022, 11:58:28 pm
Wow, you already have a build of DFHack going. Is v50 a bigger load of work to update DFHack for than previous major updates? Or is every major update about the same for DFHack?
This one is easily the most substantial amount of work to update for since the shift to 64-bit builds in 2015.
Title: Re: DFHack 0.47.05-r8
Post by: Roses on December 30, 2022, 03:47:01 pm
So I'm thinking about getting back into modding after years away, but I was recently reminded that the Steam version was released and have been reading through this thread to try to understand the impact of that release. Are there any immediate changes that I should be concerned about? I know I saw that ruby is planned to not be supported anymore, but I only wrote in lua anyway so that doesn't impact me. Nothing else jumped out at me, but I'm unsure if there was something I missed.
Title: Re: DFHack 0.47.05-r8
Post by: myk on December 30, 2022, 04:39:42 pm
There are a lot of changes in where data is stored. Most viewscreens have been merged into dwarfmodest. Zones are very different, as is the labor system. All graphics-related structures have seen significant changes. The set of available keybindings is very different.

Not sure how much any of that affects what you want to do, but those are the changes that have jumped out at me so far.
Title: Re: DFHack 0.47.05-r8
Post by: PatrikLundell on December 30, 2022, 05:12:35 pm
And, obviously, all UI you may need will have to be different. I don't know how much change there is to the scripter if you just want to throw up windows with info or queries but don't care about alignment, though. I don't even know if that functionality works decently currently or if it has to be modified to work properly, and how the call profiles will have to be modified to deal with the different grids used, for cases where you actually want things placed precisely.

When it comes to key bindings we ought to expect DF to gobble up more keys than those used currently when keyboard support is restored in coming versions, so anything you define may need to be adjusted.
Title: Re: DFHack 0.47.05-r8
Post by: Roses on December 30, 2022, 06:15:21 pm
Thanks, makes sense that any UI related information will be different, I think I will hold off on trying to do any of my previous UI work as I can foresee that changing a lot with the new graphics stuff. Where information is stored is too be expected I suppose as it usually changes somewhat every DF release. I guess I will have to just see what might have been impacted with what I use, but at least it seems like, beside the UI stuff, I can still work with what I was doing prior to my hiatus.

On the DFHack side of things, has there been (or are there any plans to) changes to the persistent storage stuff? Previously I was using that heavily, but I moved to mixing it with writing/reading a basic JSON file when the game was saved/loaded. Wondering if I should keep doing that or if I should go back to using the persistent storage, or if I should use a completely different system?
Title: Re: DFHack 0.47.05-r8
Post by: ab9rf on December 30, 2022, 07:05:20 pm
On the DFHack side of things, has there been (or are there any plans to) changes to the persistent storage stuff? Previously I was using that heavily, but I moved to mixing it with writing/reading a basic JSON file when the game was saved/loaded. Wondering if I should keep doing that or if I should go back to using the persistent storage, or if I should use a completely different system?
We implemented a persistence API some time ago (in DFHack 0.44.12-r3), using JSON written to a cosave file in the game folder.
Title: Re: DFHack 0.47.05-r8
Post by: myk on December 30, 2022, 07:15:05 pm
Yes, internally, DF works about the same (for the most part).

Regarding DFHack, persistent storage itself hasn't changed much, but the way plugins and scripts keep state has changed a bit. There is a much stronger push for tools to persist the state that players set while playing. The rallying cry is "initless", since the idea is to allow players to use DFHack tools effectively with zero init file editing (though init files still work if that's how the player wants to do things). As part of this effort, scripts have gained a way to automatically re-enable themselves according to their saved state. Before, a player would have to explicitly run a script (either manually or from an init file) before the script would have a chance to check any saved state. This prevented scripts from automatically reloading their state and continuing where they left off.

Now, scripts have a standard way to load state and set hooks at DF startup like plugins have always enjoyed: https://docs.dfhack.org/en/latest/docs/dev/Lua%20API.html#enabling-and-disabling-scripts

In UI news, the DFHack widget library is getting an overhaul. Two overhauls, actually. The current widget library is getting a lot more mouse support, like dragging, resizing, and being able to scroll the widget under the mouse cursor with the mouse wheel.

We're also working on an entirely new widget API that will allow much more "professional" UIs. This is still in the experimental phase, but it's coming along nicely.

Another big advancement is the DFHack overlay, which allows you to easily inject information and functionality into existing viewscreens. See https://docs.dfhack.org/en/latest/docs/dev/overlay-dev-guide.html

So, fun times ahead for modders : )
Title: Re: DFHack 0.47.05-r8
Post by: Roses on December 31, 2022, 02:35:11 am
On the DFHack side of things, has there been (or are there any plans to) changes to the persistent storage stuff? Previously I was using that heavily, but I moved to mixing it with writing/reading a basic JSON file when the game was saved/loaded. Wondering if I should keep doing that or if I should go back to using the persistent storage, or if I should use a completely different system?
We implemented a persistence API some time ago (in DFHack 0.44.12-r3), using JSON written to a cosave file in the game folder.

Awesome, sounds like it basically just does what I was doing already, so it's nice that there is an API for it now.

Yes, internally, DF works about the same (for the most part).

Regarding DFHack, persistent storage itself hasn't changed much, but the way plugins and scripts keep state has changed a bit. There is a much stronger push for tools to persist the state that players set while playing. The rallying cry is "initless", since the idea is to allow players to use DFHack tools effectively with zero init file editing (though init files still work if that's how the player wants to do things). As part of this effort, scripts have gained a way to automatically re-enable themselves according to their saved state. Before, a player would have to explicitly run a script (either manually or from an init file) before the script would have a chance to check any saved state. This prevented scripts from automatically reloading their state and continuing where they left off.

Now, scripts have a standard way to load state and set hooks at DF startup like plugins have always enjoyed: https://docs.dfhack.org/en/latest/docs/dev/Lua%20API.html#enabling-and-disabling-scripts

In UI news, the DFHack widget library is getting an overhaul. Two overhauls, actually. The current widget library is getting a lot more mouse support, like dragging, resizing, and being able to scroll the widget under the mouse cursor with the mouse wheel.

We're also working on an entirely new widget API that will allow much more "professional" UIs. This is still in the experimental phase, but it's coming along nicely.

Another big advancement is the DFHack overlay, which allows you to easily inject information and functionality into existing viewscreens. See https://docs.dfhack.org/en/latest/docs/dev/overlay-dev-guide.html

So, fun times ahead for modders : )

Interesting, so it sounds like I should do some real digging into the changes, from a cursory glance it seems a lot of the more esoteric things I was doing are now available through actual hooks and API interfaces. Should greatly simplify a lot of things, and hopefully make what I was doing more consistent.

The widget library overhaul also sounds very nice, so I am definitely just going to scrap all the stuff I was doing that was UI based, and come back to it once the changes move out of the experimental stage (or maybe I'll play with the experimental stage a bit).

Guess it's time to dust off the ol' lua scripting hat
Title: Re: DFHack 0.47.05-r8
Post by: Clément on January 04, 2023, 09:49:37 am
I started looking at invalid offsets in Dwarf Therapist. Are you interested in me reporting my issues for df-structures or are you busy enough right now?
Title: Re: DFHack 0.47.05-r8
Post by: myk on January 04, 2023, 09:57:16 am
The conversation for that is happening on the DFHack discord in the #reverse-engineering channel. Your input would be appreciated there, I think.

https://dfhack.org/discord
Title: Re: DFHack 0.47.05-r8
Post by: lethosor on January 04, 2023, 12:41:30 pm
Issues on GitHub are welcome too, although there is some risk of duplicating work there (we're trying to get PRs up for changes within a reasonable time, but it doesn't always happen)
Title: Re: DFHack 0.47.05-r8
Post by: Clément on January 05, 2023, 05:32:06 am
I prefer asynchronous discussions. I'll create a github issue.
Title: Re: DFHack 0.47.05-r8
Post by: ab9rf on January 05, 2023, 07:12:02 am
Issues on GitHub are welcome too, although there is some risk of duplicating work there (we're trying to get PRs up for changes within a reasonable time, but it doesn't always happen)
we are definitely behind in merging structures updates, but this isn't really surprising given that (a) it's been holidays and (b) there is a lot going on right now
Title: Re: DFHack 0.47.05-r8
Post by: Gamerlord on January 11, 2023, 07:29:25 pm
I would quite literally KILL for a script to run that creates individual work details for every labor and sets them all to Only Selected. I spend 5-10 minutes just setting that shit up every damn time I play.
Title: Re: DFHack 0.47.05-r8
Post by: Putnam on January 12, 2023, 02:55:34 pm
I would quite literally KILL for a script to run that creates individual work details for every labor and sets them all to Only Selected. I spend 5-10 minutes just setting that shit up every damn time I play.

Better yet, just play the game as designed until the utilities come out which are actually designed to do this and use the global flag that turns off the work details system completely, instead of repeatedly banging your head against the wall to get a system to do something you don't want it to?
Title: Re: DFHack 0.47.05-r8
Post by: FantasticDorf on January 12, 2023, 03:09:04 pm
I would quite literally KILL for a script to run that creates individual work details for every labor and sets them all to Only Selected. I spend 5-10 minutes just setting that shit up every damn time I play.

Better yet, just play the game as designed until the utilities come out which are actually designed to do this and use the global flag that turns off the work details system completely, instead of repeatedly banging your head against the wall to get a system to do something you don't want it to?

Without trying to wade in, that's partially what DT is for. Even in 47.x there were things doable with therapist that couldn't be accessed elsewhere or really had time to be acknowledged as features. Giving semi-intelligents additional labors for instance, than just what the default ambusher skill does for vanilla gremlins + hauling etc was unrecognised gameplay advantages it offered.

DF does figure in a lot of repetitiveness in 50. for turning off tutorial menus/preferred stockpile (barrel/bins constantly reset and default rather than stay 0) / and labor settings because of a lack of persistency. A DT that could automatically work with the squad system with some advanced commands (ability to draft anybody in) and pre-set uniforms/script written uniform templates would be the same vein as the original comment.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha1 (pre-release)
Post by: lethosor on January 16, 2023, 09:40:43 pm
New pre-release for 50.05! See the release announcement for details: https://github.com/DFHack/dfhack/releases/tag/50.05-alpha1
Title: Re: DFHack 0.47.05-r6
Post by: DAOWAce on January 17, 2023, 03:54:16 am
(https://user-images.githubusercontent.com/977482/192902807-dbe3a187-85b0-4cfc-a6ca-9344d3beeaa2.png)
How do we move/remove this launcher text?

Tried to read the rest of the thread and look at the help section (http://) for it, but can't see any mention of this.

Besides being new (which to me means uncomfortable), it's overlapping with the weather status.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha1 (pre-release)
Post by: myk on January 17, 2023, 07:12:05 am
In steam DF, the position is configurable. For 0.47, you can run `disable overlay` if it's in the way. For anyone reading this who is running version 50 (the steam version), do *not* disable the overlay since it's now used by a large number of DFHack tools.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha1 (pre-release)
Post by: lethosor on January 17, 2023, 01:22:45 pm
It should also be configurable in DFHack 0.47.05-r8, but not r7 (if you have PeridexisErrant's pack, you probably have r7, but you can upgrade).

As for the weather indicator, we did move it, but you might have an older copy of the config file. You can delete "dfhack-config/dwarfmonitor.json" (assuming you haven't modified it yourself) to cause the default to be regenerated, and that should make the weather indicator visible once again.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha1 (pre-release)
Post by: DeDeRon on January 19, 2023, 09:06:20 am
Is the old way of working in a terminal still available? Will dfhack-run still work? I prefer working in a command line over text user interfaces. dfhack-run e.g. is very useful when using grep to find stuff in a long list.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha1 (pre-release)
Post by: myk on January 19, 2023, 09:36:50 am
Yes, dfhack-run, the terminal window, and the commandline interface in general aren't going anywhere. There are just more GUI-accessible options now.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha1 (pre-release)
Post by: myk on January 20, 2023, 08:49:55 pm
New pre-release for 50.05! See the release announcement for details: https://github.com/DFHack/dfhack/releases/tag/50.05-alpha2
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: muffinbottoms on January 21, 2023, 02:49:22 am
I don't think this is a DF Hack issue, but I encountered something odd when trying to change the caste, sex, orientation of my dwarves for a play-through based on my friends. Whenever I used gui/gm-unit and gui/gm-editor to edit the caste, sex, and orientation of my dwarves from female to male, I would save and re-open my save so that the changes in sprite would take effect, but as soon as a few ticks go by in game they would immediately transform back into females.
Am I editing the wrong values? Or is there another way to go about changing my dwarves?
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Putnam on January 21, 2023, 04:46:42 am
You have to edit unit.enemy.were_caste and unit.enemy.normal_caste as well
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Kat on January 21, 2023, 09:11:44 am
Hi people.
Been playing DF again, getting in the mood before contemplating a move to the new version. Anyway...

I encountered something, not sure if it would fall under DFHack's scope though, but it relates to information presented to the user, which is usually something that DFHack enhances.

So what it was is this:
I had to build a temple for one of my religions, which was easy enough, and to enhance it, I wanted to build statues as I usually do.
So, forge gold statue, select details, pick "related to civilisation or other group", find the religion's name and.... there are two entries. Another civilisation of the same race has a religion of the same name. Which one is mine ? I have no way to tell.

It would be really good if the religions of your civilisation were highlighted in some way. Not sure if that's even possible though.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: muffinbottoms on January 21, 2023, 09:51:56 pm
You have to edit unit.enemy.were_caste and unit.enemy.normal_caste as well

Whoooo! Putnam you're the best, thank you!

Now I can watch my friends endlessly struggle to build a fort!
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Pillbo on January 22, 2023, 05:17:18 pm
I don't think quicksave is working correctly, no saves were created for me.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Boltgun on January 23, 2023, 08:34:27 am
I have a pretty generic question. Do we have a plan to ease the distribution of scripted mods in the workshop?

From my memory, it was this way on 0.47: make a scripts subfolder in the raws, then DF copy it in the saves and dfhack handles it from there. Now that df put each mod into its own folder, it seems more complicated. Telling the users to go into game files sounds like trouble.

This is interesting because the easier for Steam users to get a mod working, the best. Ideally I'll even make dfhack optional and inject reactions that use scripts at runtime, if it's installed.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: myk on January 23, 2023, 04:35:54 pm
I don't think quicksave is working correctly, no saves were created for me.
Saving is funky nowadays. It appears that quicksave will trigger an **autosave**, and increment the autosave counter. At least this is what it did for me when I tested it and tracked down where the saves were going. I updated the docs to reflect this in the next version.

I have a pretty generic question. Do we have a plan to ease the distribution of scripted mods in the workshop?
Some initial thoughts here: https://github.com/DFHack/dfhack/issues/2667
which will allow mods to automatically get added to the script path under the right conditions.
this depends a bit on how .lua files are handled in mods uploaded to Steam Workshop. Research must still be done.

Hi people.
It would be really good if the religions of your civilisation were highlighted in some way.
Sounds perfectly possible. Could you file a feature request at https://github.com/DFHack/dfhack/issues ?
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Pillbo on January 23, 2023, 09:22:29 pm
I don't think quicksave is working correctly, no saves were created for me.
Saving is funky nowadays. It appears that quicksave will trigger an **autosave**, and increment the autosave counter. At least this is what it did for me when I tested it and tracked down where the saves were going. I updated the docs to reflect this in the next version.

In my game it didn't create an autosave or a standard save, I only have my pre-existing saves.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Martenzo on January 24, 2023, 02:29:43 am
I'm following the instructions to "Cross-compile windows files for running DF in Steam for Linux (http://"https://docs.dfhack.org/en/latest/docs/dev/compile/Compile.html#id20")" and I'm running into a snag. Part-way through building the MSVC builder image (didn't work without sudo, so I went with that), docker proclaims I'm out of drive space in /opt. According to "df -h", this is not actually the case, though this might be because I only checked after it had aborted and cleaned up after itself. How much drive space does docker require to build the MSVC image? Can't seem to find this in docs.dfhack.org.

EDIT: I figured out it really is running out of space; in /var, not in /opt. The question still stands: how much space do I need to free up in /var?
EDIT2: Question is moot. It's docker alone that's literally filling up nearly the entirety of my /var partition when it downloads things to build the MSVC image. I literally can't free up enough space to let docker finish the job without repartitioning my system drive. And to people having this issue in the future: temporarily symlinking the folder to a larger drive/partition doesn't work, because docker won't proceed through symlinks.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Clément on January 24, 2023, 03:30:54 pm
EDIT2: Question is moot. It's docker alone that's literally filling up nearly the entirety of my /var partition when it downloads things to build the MSVC image. I literally can't free up enough space to let docker finish the job without repartitioning my system drive. And to people having this issue in the future: temporarily symlinking the folder to a larger drive/partition doesn't work, because docker won't proceed through symlinks.

Try a bind mount instead of a symlink maybe.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Gamerlord on January 25, 2023, 12:52:18 am
Does the alpha release have a quick way of handling work details (like automatically making a single detail for each labour)?
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Gamerlord on January 25, 2023, 09:33:11 pm
Like, this is the biggest stumbling block keeping me from playing more. It takes me 10-20 minutes to set up work details alone every single time I play a new fortress. It's made worse by how slow back-spacing out the default title of the work detail is.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Putnam on January 25, 2023, 11:03:09 pm
there is a flag that completely removes the work details system so you can use therapist or whatever instead, which I strongly recommend doing instead of trying to do that
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Gamerlord on January 26, 2023, 12:20:34 am
I'd rather not, the work detail system in concept isn't that bad, it works well for migrant waves imo. But it's the mandatory investment of time for a fort that might not even survive two years that is a problem.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Putnam on January 26, 2023, 12:25:57 am
i have run a fort for 25 years without even opening the work detail screen, it is not a mandatory investment by any means

like, either switch to therapist or let go of the idea that you need to micromanage every single individual dwarf's every individual labors when most of those labors are unimportant and transient?
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Martin on January 26, 2023, 12:28:17 am
Like, this is the biggest stumbling block keeping me from playing more. It takes me 10-20 minutes to set up work details alone every single time I play a new fortress. It's made worse by how slow back-spacing out the default title of the work detail is.
Yeah, I agree. My two gripes:


1) That there isn't a detail for each job by default.
2) That you can't edit the base details.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Putnam on January 26, 2023, 12:38:23 am
1) That there isn't a detail for each job by default.

because we don't want the player to think they have to torture theirself for no reason making sure every single individual has a very specific set of jobs assigned, yes, this was the single biggest actual gameplay hurdle to new players starting the game in previous versions and it was a literal requirement to the point that the single most common thing you heard about the game is "you literally need therapist to play it". Now this is not necessary and to make the UX appear like it's to be encouraged would be antithetical to the goal of the game being actually playable on its own.

you do not have to torture yourself by making sure you can assign soap makers, it's okay, you can make fantastically successful forts with only two or three custom work details, please don't act like it's our problem that you feel the need to wrestle with a UI that is screaming at you to do something else, this is what third-party utilities are for

2) That you can't edit the base details.

yeah i made this edit myself as soon as i started working, it's not really ready for primetime and on the backburner, unfortunately, but it is on my mind
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Bumber on January 26, 2023, 04:25:45 am
you do not have to torture yourself by making sure you can assign soap makers, it's okay, you can make fantastically successful forts with only two or three custom work details, please don't act like it's our problem that you feel the need to wrestle with a UI that is screaming at you to do something else, this is what third-party utilities are for

However, one for each that creates item quality would be appreciated. (Or just the return of skill limits on workshops.)
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Clément on January 26, 2023, 07:03:11 am
Does the alpha release have a quick way of handling work details (like automatically making a single detail for each labour)?

Code: [Select]
local labors = {
"CARPENTER",
"STONE_CARVER",
"MASON",
"ANIMALTRAIN",
"ANIMALCARE",
"BUTCHER",
"TRAPPER"
}
for i,l in ipairs(labors) do
local detail = df.work_detail:new()
detail.name = df.unit_labor.attrs[l].caption
detail.work_detail_flags.enabled = true
detail.allowed_labors[df.unit_labor[l]] = true
detail.icon = 10+((i-1)%8)
df.global.plotinfo.hauling.work_details:insert('#', detail)
end
Fill the "labors" list from https://github.com/DFHack/df-structures/blob/c4d78c229aa0edd68a69cd5b19d5ad35a5b71098/df.skills.xml#L841
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: dan84 on January 26, 2023, 03:16:08 pm
Running 50.05 Steam Version and 50.05-alpha2 DFHack.  The game runs fine without DFHack. Once I install DFHack and overwrite the SDL file, I get the following error Popup trying to run Dwarf Fortress:


Dwarf Fortress.exe - Entry Point Not Found
The procedure entry point SDL_ListModes could not be located in the dynamic link library C:\Program Files (x86)\Steam\steamapps\common\Dwarf Fortress\Dwarf Fortress.exe

Any ideas?
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Putnam on January 26, 2023, 03:37:06 pm
You put SDLreal in there too? It's not just a backup, the replacement SDL.dll calls into it for display etc
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Gamerlord on January 26, 2023, 05:23:50 pm
Does the alpha release have a quick way of handling work details (like automatically making a single detail for each labour)?

Code: [Select]
local labors = {
"CARPENTER",
"STONE_CARVER",
"MASON",
"ANIMALTRAIN",
"ANIMALCARE",
"BUTCHER",
"TRAPPER"
}
for i,l in ipairs(labors) do
local detail = df.work_detail:new()
detail.name = df.unit_labor.attrs[l].caption
detail.work_detail_flags.enabled = true
detail.allowed_labors[df.unit_labor[l]] = true
detail.icon = 10+((i-1)%8)
df.global.plotinfo.hauling.work_details:insert('#', detail)
end
Fill the "labors" list from https://github.com/DFHack/df-structures/blob/c4d78c229aa0edd68a69cd5b19d5ad35a5b71098/df.skills.xml#L841
Thank you my friend. My OCD is truly grateful.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Gamerlord on January 26, 2023, 05:58:44 pm
Damnit, having trouble figuring out how to do that Clement, is there a location I copy that code into?
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Clément on January 26, 2023, 07:05:15 pm
In hack/scripts in a file with a .lua extension. Then type the name of the file (without the extension) in dfhack command prompt to run the script. See the documentation (https://docs.dfhack.org/en/latest/docs/dev/Lua%20API.html#scripts)
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Gamerlord on January 26, 2023, 07:41:49 pm
In hack/scripts in a file with a .lua extension. Then type the name of the file (without the extension) in dfhack command prompt to run the script. See the documentation (https://docs.dfhack.org/en/latest/docs/dev/Lua%20API.html#scripts)
Thanks, that worked! There was a weird error thing generated afterward, but the actual work details were still put in.

EDIT: No it didn't, it just spammed the first few work details in the list over and over.

Here's error:
...\steamapps\common\Dwarf Fortress//hack/scripts/labor.lua:58: Invalid index in enum.attrs[]
stack traceback:
        [C]: in metamethod '__index'
        ...\steamapps\common\Dwarf Fortress//hack/scripts/labor.lua:58: in local 'script_code'
        ...team\steamapps\common\Dwarf Fortress\hack\lua\dfhack.lua:808: in function 'dfhack.run_script_with_env'
        (...tail calls...)

EDIT2: Seems to be human error on my end, gonna try again.
EDIT3: Yup got it right this time. Including text of labor.lua if anyone else wants it - note, does not assign hauling/construction labors.

Spoiler (click to show/hide)
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: myk on January 26, 2023, 10:17:53 pm
In the most recent versions of DFHack, you now have a dfhack-config/scripts directory to put your own scripts in. Anything you put in hack/scripts will likely be lost when you upgrade DFHack, especially once we get distribution on Steam working and upgrades become automated.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: dan84 on January 27, 2023, 08:58:00 am
You put SDLreal in there too? It's not just a backup, the replacement SDL.dll calls into it for display etc

Yes. I followed the instructions; it is in there. I re-installed DFHack, but still the same issue. SDLreal.dll is in there. I am thinking of doing a clean install, but I don't want to lose my world. Maybe I'll try after I finish this current game I'm on.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: PatrikLundell on January 27, 2023, 09:16:16 am
You don't need to lose your world. Copy the world elsewhere and then reinstall (in the Classic version I make new installations and copy the saved world over, but I guess things work differently with the Premium ones. It ought to be possible to reinstall on top of a Premium version installation without losing the save if they've implemented it in a reasonable way, but I'd recommend copying the save anyway, just in case).
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: Kat on January 27, 2023, 04:09:20 pm
Hi people.
It would be really good if the religions of your civilisation were highlighted in some way.
Sounds perfectly possible. Could you file a feature request at https://github.com/DFHack/dfhack/issues ?

I asked a friend with a github account to put a feature request in for this, at https://github.com/DFHack/dfhack/issues/2730

checked with version 50.05 of dwarf fortress and the same phenomenon occurs there - large worlds with long histories can result in multiple religions (and other things) of the same name, and you can't really tell which is which when specifying details of images in jobs.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: dan84 on January 29, 2023, 10:54:52 am
You don't need to lose your world. Copy the world elsewhere and then reinstall (in the Classic version I make new installations and copy the saved world over, but I guess things work differently with the Premium ones. It ought to be possible to reinstall on top of a Premium version installation without losing the save if they've implemented it in a reasonable way, but I'd recommend copying the save anyway, just in case).

Thanks, I removed Dwarf Fortress except for the save file, reinstalled and re-downloaded and installed Hack and it worked.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha2 (pre-release)
Post by: thefinn on February 03, 2023, 10:22:32 am
Thank you guys for all you do with this. It's so nice to have this on the new steam version, I couldn't really live without it :)
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha3 (pre-release)
Post by: myk on February 03, 2023, 05:56:52 pm
DFHack 50.05-alpha3 released!

Get it here: https://github.com/DFHack/dfhack/releases/tag/50.05-alpha3
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha3.1 (pre-release)
Post by: PatrikLundell on February 04, 2023, 03:11:11 am
The notes for 50.05-alpha3 mentions that Itch.io and Classic support is scheduled to come with DF 50.06. Can you explain why?

My guess would be that Toady/Putnam (quite possibly the latter) has identified a layout solution that would make the layout of DF proper data the same in all versions, and move all vendor specific data to vendor specific locations outside of the space used by DF natively, but that's obviously just a guess.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha3.1 (pre-release)
Post by: ab9rf on February 05, 2023, 08:00:19 pm
The notes for 50.05-alpha3 mentions that Itch.io and Classic support is scheduled to come with DF 50.06. Can you explain why?

My guess would be that Toady/Putnam (quite possibly the latter) has identified a layout solution that would make the layout of DF proper data the same in all versions, and move all vendor specific data to vendor specific locations outside of the space used by DF natively, but that's obviously just a guess.
No, it's that the DFHack team identified a structural issue with data layout. This was really evident to us almost immediately, the first time we analyzed an itch.io image, which would have around December 10 or so, well before Putnam was hired. Putnam subsequently confirmed our conclusion. The issue itself arises from some #ifdefs in the middle of the definition of gamest for data specific to mod management, which has extra functionality for Steam editions which requires extra data.

We could have accommodated this by either splitting the gamest up into two (or possibly three, I'd have to go look) chunks which would have to manually realigned (we locate the global variable game automatically off of the global table Toady provides, but that won't work as well if we have to chop up gamest into pieces), or else make two (or even three) different editions of DFHack for each release, one with a version of gamest that works with Steam editions and one that works with non-Steam editions. We obviously can do this, but doing it complicates our build process but more importantly makes using DFHack more difficult for end users, who would have to be careful to choose the correct edition of DFHack to install. The mechanism by which DFHack determines which version of DF it's been installed to run against would prevent catastrophic misoperation, as DFHack will detect that it is being run against a version of DF it is not compatible with and will shut down, but this would still be annoying for end users and is something we would like to avoid. DFHack is supposed to make DF easier to play, not harder.

When we discussed this issue with Putnam we found her agreeable to proposing a solution to Toady that would obviate the complexities that the above solutions entail. Our specific recommendation was to move the Steam-specific data elements to the end of the structure in question or to a separate structure, but Putnam instead elected to recommend replacing them with equivalent padding when the Steam configuration parameter is not set, which means gamest will have the same alignment on Steam and non-Steam builds. (This is probably because from our point of view gamest is one very large structure, while from Toady's point of view it is a compound of several smaller structures, one of which contains the mod-related stuff. Moving the Steam-specific data to the end of gamest as a whole would force a fairly complex restructuring of gamest from Toady's point of view, which is obviously not desirable.) The communications we have indicate that Toady is agreeable in principle to these proposals, but we have not (to date) received any definite confirmation that they will, in fact, be in the next release (which I personally attribute to simply the fact that Toady and Putnam both have a lot of stuff to deal with right now, and accommodating the DFHack team's requests is quite reasonably neither of their highest priorities). If they don't show up in the near future rest assured that we will implement a Plan B, and it is certainly not our intent to permanently leave itch.io and Classic players in the lurch, but we remain hopeful that Toady will remain agreeable to the solution that we worked out with Putnam and that the changes we jointly recommended, or some other equivalent solution to this problem, will find their way into a future release, which we also fervently hope will be the next release. At the same time, we recognize that making Dwarf Fortress more compatible with DFHack is not a development priority for Toady, and totally understand if Toady elects to defer, or even to decline, implementing such proposals in favor of advancing any other aspect of development that seems to him to be more fruitful.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha3.1 (pre-release)
Post by: PatrikLundell on February 05, 2023, 09:05:35 pm
Thanks for that thorough explanation!
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha3.1 (pre-release)
Post by: Clément on February 06, 2023, 05:57:28 am
"equivalent padding", that sounds tricky. I would have thought hiding the steam stuff behind a pointer indirection would have been enough. But I did not really look what is this steam-specific data and how it is organized. I may be missing something.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha3.1 (pre-release)
Post by: ab9rf on February 06, 2023, 06:13:58 am
"equivalent padding", that sounds tricky. I would have thought hiding the steam stuff behind a pointer indirection would have been enough. But I did not really look what is this steam-specific data and how it is organized. I may be missing something.
While I can't speak for Putnam here, my take on that decision would be that it is the one that requires no changes at all outside of the single header file that defines the structure in question. Indirecting the Steam-specific data behind a pointer to another structure would necessitate adding code to allocate (and deallocate) that additional structure and to use indirections when accessing its content, which is therefore a more "involved" change than just adding an #else and some dummy variables to an #ifdef that is already there.
Title: Re: DFHack 0.47.05-r8 | 50.05-alpha3.1 (pre-release)
Post by: myk on February 10, 2023, 03:38:50 pm
DFHack 50.07-alpha1 released!

(https://user-images.githubusercontent.com/4482627/216727452-dcc3eeac-35dd-4314-a5d3-ffff6ac037b9.gif)

Get it here: https://github.com/DFHack/dfhack/releases/tag/50.07-alpha1
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: Clément on February 11, 2023, 08:07:51 am
Where is the "init.d" directory mentioned in the documentation (https://docs.dfhack.org/en/latest/docs/Core.html#init-d-lua) supposed to be created? It says "main DF directory" but it does not work for me. The only occurence of init.d I find in the code is for "raw/init.d".

Or what is the best way to run a lua command on startup? Should I rather create a "dfhack-config/init/dfhack-....init" file containing ":lua ..."?
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: Clément on February 11, 2023, 08:47:40 am
Also I have a weird bug with the classic version only where game.external_flag is always reset to 0 when a fortress is loaded (I can set it in the main menu but not in game).
Code: [Select]
[DFHack]# :lua df.global.game.external_flag=1
[DFHack]# :lua !df.global.game.external_flag
0
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: Clément on February 11, 2023, 09:07:55 am
Also I have a weird bug with the classic version only where game.external_flag is always reset to 0 when a fortress is loaded (I can set it in the main menu but not in game).
Code: [Select]
[DFHack]# :lua df.global.game.external_flag=1
[DFHack]# :lua !df.global.game.external_flag
0

Commenting the "Steam-only stuff" in df.ui-menus.xml solves this (at least it solves Dwarf Therapist, I did not recompile DFHack). The layout for gamest seems to be different between steam and classic still.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: ab9rf on February 11, 2023, 05:57:39 pm
I checked during initial analysis to verify that gamest in classic was _not smaller_ than it was in steam. I neglected to check whether it was _larger_, in part because it didn't make sense for it to be.

Sadly, it is. We know that the external flag is the last element in gamest, and so the length of gamest is the difference between the address of game and the address of external flag (plus four bytes). In Steam, this length is 0x141e2554 - 0x141e1adc0 + 4 = 0xa7a8; in Classic this length is 0x141e193d4 - 0x141e0ebc0 + 4 = 0xa818. For some reason that is inexplicable to me, gamest is now actually _longer_ on Classic than on Steam.

I don't have an analyzed 50.05 Classic image handy, but in 50.04-Classic this was 0x141dbf3c - 0x141db4fc0 +4 = 0xa400, while in 50.04-Steam this was 0x141dcb52c - 0x141dc10b0 + 4 = 0xa480.

I honestly do not know what Bay12 is doing here.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: Clément on February 11, 2023, 06:54:43 pm
I had to remove fields to make external_flag work on classic, so I made gamest smaller. If it is actually bigger, it means there are extra fields after external_flag.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: lethosor on February 11, 2023, 07:01:58 pm
I had to remove fields to make external_flag work on classic, so I made gamest smaller. If it is actually bigger, it means there are extra fields after external_flag.
Well, if you had to remove fields to make external_flag align, it means there is something larger before external_flag on classic (vs Steam). It could be extra fields, or the padding Putnam added in an attempt to align gamest.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: Putnam on February 11, 2023, 11:03:30 pm
I honestly do not know what Bay12 is doing here.

finding it difficult to measure what the changes i'm making are actually doing, mostly
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: Clément on February 12, 2023, 04:52:24 am
50.07-classic, external_flag offset is 0xa724
(https://i.ibb.co/WgJK5DP/Capture-d-cran-du-2023-02-12-10-41-13.png) (https://ibb.co/WgJK5DP)
50.07-steam, external_flag offset is 0xa7a4
(https://i.ibb.co/VDbg5dZ/Capture-d-cran-du-2023-02-12-10-44-16.png) (https://ibb.co/VDbg5dZ)

The difference is in mod_manager. classic is smaller than steam, at least until external_flag.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: ab9rf on February 12, 2023, 09:03:20 am
I checked during initial analysis to verify that gamest in classic was _not smaller_ than it was in steam. I neglected to check whether it was _larger_, in part because it didn't make sense for it to be.

Sadly, it is. We know that the external flag is the last element in gamest, and so the length of gamest is the difference between the address of game and the address of external flag (plus four bytes). In Steam, this length is 0x141e2554 - 0x141e1adc0 + 4 = 0xa7a8; in Classic this length is 0x141e193d4 - 0x141e0ebc0 + 4 = 0xa818. For some reason that is inexplicable to me, gamest is now actually _longer_ on Classic than on Steam.

I don't have an analyzed 50.05 Classic image handy, but in 50.04-Classic this was 0x141dbf3c - 0x141db4fc0 +4 = 0xa400, while in 50.04-Steam this was 0x141dcb52c - 0x141dc10b0 + 4 = 0xa480.

I honestly do not know what Bay12 is doing here.
I figured out my error above: I transposed two digits while manually doing these calculations. The address of game in .07-Classic is 0x141e0ecb0, which is not what I used above.

Clément's analysis is correct, and thus it would appear that the decision to implement padding (as previously mentioned) has not gone forward. That was my mistake; I misinterpreted our initial reverse-engineering results. I apologize for any inconvenience this may have created for DFHack users.

For DFHack, we'll be moving forward with a Plan B approach that doesn't depend on Bay12 keeping the game structure aligned between versions.

Code: [Select]
PS E:\Kelly\Projects\df_misc> & ruby -I../metasm dump_df_globals.rb --raw 'E:\kelly\df\df_50_07_steam\Dwarf Fortress.exe' | where-object {$_.contains("game")}
Global table starts at 141318080h
<global-address name='game.external_flag' value='0x141e25564'/>
<global-address name='game' value='0x141e1adc0'/>
<global-address name='gamemode_cansave' value='0x141876a15'/>
<global-address name='gamemode' value='0x141319840'/>
<global-address name='gametype' value='0x14131983c'/>
PS E:\Kelly\Projects\df_misc> & ruby -I../metasm dump_df_globals.rb --raw 'E:\kelly\df\df_50_07_classic\Dwarf Fortress.exe' | where-object {$_.contains("game")}
Global table starts at 14130c050h
<global-address name='game.external_flag' value='0x141e193d4'/>
<global-address name='game' value='0x141e0ecb0'/>
<global-address name='gamemode_cansave' value='0x14187e18c'/>
<global-address name='gamemode' value='0x14130d804'/>
<global-address name='gametype' value='0x14130d7dc'/>

steam: game.external_flag - game = 0x141e25564 - 0x141e1adc0 = 0xa7a4
classic: game.external_flag - game = 0x141e193d4 - 0x141e0ecb0 = 0xa724L
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: PatrikLundell on February 12, 2023, 11:53:08 am
Despite that, I can still get some data from the Classic version using DFHack, with many things seemingly working (gui/gm-editor, some basic scripts to look at some data of interest, such as units, for instance). I've run a script over the DF data structures to try to find things that I might be able to fix, and after blacklisting parts of it (crashing or running out of memory on "broken" structures) I've been able to go through it, although without finding anything that's within my capability to fix so far, unfortunately.

Still, it's usable as a probe (with extra caution) with Classic, despite there apparently being a big wart on it.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: ab9rf on February 12, 2023, 07:00:29 pm
Despite that, I can still get some data from the Classic version using DFHack, with many things seemingly working (gui/gm-editor, some basic scripts to look at some data of interest, such as units, for instance). I've run a script over the DF data structures to try to find things that I might be able to fix, and after blacklisting parts of it (crashing or running out of memory on "broken" structures) I've been able to go through it, although without finding anything that's within my capability to fix so far, unfortunately.

Still, it's usable as a probe (with extra caution) with Classic, despite there apparently being a big wart on it.
To the best of my knowledge, the only variable that is mislocated due to this issue that is actually used in DFHack is, ironically, the external flag, which is only used at present by autolabor. With this single exception, none of the variables in the "tail" of gamest (the members that appear after mod_manager) that is misaligned due to this issue are currently being used by any tool or script that is being distributed with DFHack.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: 0x517A5D on February 15, 2023, 10:11:50 pm
I've found start_dwarf_count for 50.07 Classic.

Unfortunately, it's not going to be that easy.  Setting it above 9 causes a crash.

Quote from: 50.07
.text:0000000140CB5976                         loc_140CB5976:                          ; CODE XREF: sub_140CB3AD0+1E35↑j
.text:0000000140CB5976 BF 07 00 00 00                          mov     edi, 7          ; START_DWARF_COUNT
.text:0000000140CB597B 48 8B 74 24 60                          mov     rsi, [rsp+2C0h+unit]
.text:0000000140CB5980 4C 8B 75 B8                             mov     r14, [rbp+1C0h+var_208]
.text:0000000140CB5984 44 8D 67 F8                             lea     r12d, [rdi-8]   ; OKAY!  This parameter needs to be set to -1 !
.text:0000000140CB5984                                                                 ; That chooses caste at random.
.text:0000000140CB5984                                                                 ; If it's >= 0, it selects that caste.
.text:0000000140CB5988
.text:0000000140CB5988                         loc_140CB5988:                          ; CODE XREF: sub_140CB3AD0+1FEB↓j
.text:0000000140CB5988 FF CF                                   dec     edi
.text:0000000140CB598A E8 A1 49 3B FF                          call    new_unit
.text:0000000140CB598F 48 8B D8                                mov     rbx, rax
.text:0000000140CB5992 48 89 44 24 60                          mov     [rsp+2C0h+unit], rax
.text:0000000140CB5997 45 8B C4                                mov     r8d, r12d
.text:0000000140CB599A 45 33 C9                                xor     r9d, r9d
.text:0000000140CB599D 0F B7 15 28 26 15 01                    movzx   edx, cs:word_141E07FCC ; example value: 23Ch, 572, DWARF.  Unit type.
.text:0000000140CB59A4 48 8B C8                                mov     rcx, rax
.text:0000000140CB59A7
.text:0000000140CB59A7                         this call crashes when startdwarf is 10 or higher.
.text:0000000140CB59A7                         turns out that's because of the caste flag in r12d
.text:0000000140CB59A7                         (passed in r8d, per above code).
.text:0000000140CB59A7                         This parameter should be -1.  When startdwarf is forced to 10,
.text:0000000140CB59A7                         r12d is set to (10-8) = 2, which is a nonexistant caste.
.text:0000000140CB59A7 E8 94 4D 27 00                          call    sub_140F2A740   ; parameters: rcx=*unit,
.text:0000000140CB59A7                                                                 ; dx = creature type index (572=DWARF),
.text:0000000140CB59A7                                                                 ; r8w = caste (-1 for random),
.text:0000000140CB59A7                                                                 ; r9b flag: set unit 6-byte field @ 0D70h

This excessively-optimized code depends on knowing that EDI is set to 7 as a space-saving way to set R12D to -1, using the calculation (7-8).

R12 is then used to select the caste of the unit being generated.  -1 means random; 0 means FEMALE; 1 means MALE; 2 or higher lead to a crash.

We need to enter the call to sub_140F2A740 with R8 == -1.  I don't see a way to squeeze that into the current code.

Anyone have thoughts?
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: lethosor on February 16, 2023, 12:55:28 am
Oh, that is interesting. We have deliberately been leaving start_dwarf_count out of symbols.xml (thereby blocking startdwarf) because of this crash, but hadn't tracked down the specific reason why > 9 crashed more reliably. Good to know why that happens!

We've been considering asking Bay12 to make start_dwarf_count a proper global, or something similarly useful to us. Obviously that's not a high priority for them, and it's not near the top of our list either, so that hasn't happened yet. I'm no x86 expert so I don't have a great idea of how to squeeze in a patch in the meantime.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: ab9rf on February 16, 2023, 03:23:52 am
I've found start_dwarf_count for 50.07 Classic.

Unfortunately, it's not going to be that easy.  Setting it above 9 causes a crash.

Quote from: 50.07
.text:0000000140CB5976                         loc_140CB5976:                          ; CODE XREF: sub_140CB3AD0+1E35↑j
.text:0000000140CB5976 BF 07 00 00 00                          mov     edi, 7          ; START_DWARF_COUNT
.text:0000000140CB597B 48 8B 74 24 60                          mov     rsi, [rsp+2C0h+unit]
.text:0000000140CB5980 4C 8B 75 B8                             mov     r14, [rbp+1C0h+var_208]
.text:0000000140CB5984 44 8D 67 F8                             lea     r12d, [rdi-8]   ; OKAY!  This parameter needs to be set to -1 !
.text:0000000140CB5984                                                                 ; That chooses caste at random.
.text:0000000140CB5984                                                                 ; If it's >= 0, it selects that caste.
.text:0000000140CB5988
.text:0000000140CB5988                         loc_140CB5988:                          ; CODE XREF: sub_140CB3AD0+1FEB↓j
.text:0000000140CB5988 FF CF                                   dec     edi
.text:0000000140CB598A E8 A1 49 3B FF                          call    new_unit
.text:0000000140CB598F 48 8B D8                                mov     rbx, rax
.text:0000000140CB5992 48 89 44 24 60                          mov     [rsp+2C0h+unit], rax
.text:0000000140CB5997 45 8B C4                                mov     r8d, r12d
.text:0000000140CB599A 45 33 C9                                xor     r9d, r9d
.text:0000000140CB599D 0F B7 15 28 26 15 01                    movzx   edx, cs:word_141E07FCC ; example value: 23Ch, 572, DWARF.  Unit type.
.text:0000000140CB59A4 48 8B C8                                mov     rcx, rax
.text:0000000140CB59A7
.text:0000000140CB59A7                         this call crashes when startdwarf is 10 or higher.
.text:0000000140CB59A7                         turns out that's because of the caste flag in r12d
.text:0000000140CB59A7                         (passed in r8d, per above code).
.text:0000000140CB59A7                         This parameter should be -1.  When startdwarf is forced to 10,
.text:0000000140CB59A7                         r12d is set to (10-8) = 2, which is a nonexistant caste.
.text:0000000140CB59A7 E8 94 4D 27 00                          call    sub_140F2A740   ; parameters: rcx=*unit,
.text:0000000140CB59A7                                                                 ; dx = creature type index (572=DWARF),
.text:0000000140CB59A7                                                                 ; r8w = caste (-1 for random),
.text:0000000140CB59A7                                                                 ; r9b flag: set unit 6-byte field @ 0D70h

This excessively-optimized code depends on knowing that EDI is set to 7 as a space-saving way to set R12D to -1, using the calculation (7-8).

R12 is then used to select the caste of the unit being generated.  -1 means random; 0 means FEMALE; 1 means MALE; 2 or higher lead to a crash.

We need to enter the call to sub_140F2A740 with R8 == -1.  I don't see a way to squeeze that into the current code.

Anyone have thoughts?
We found the startdwarf location relatively early on in the development cycle (we have a script for it that worked, so it was trivial), but we decided (as lethosor notes) not to publish it because our testing showed that it failed for counts greater than 9. I never investigated deeply to figure out why, since we wanted to get a release out and it wasn't worth blocking for this, and honestly I've never worked back to the problem.

Good find. I'm not inclined to try to try to come up with a patch that will make this work "as desired". If someone else wants to, more power to them. If someone comes up with a patch that works for start dwarf counts less than 7 (such as, oh I don't know, one), that I might be more interested in...

Poking at it a bit, the obvious solution is to patch n into the startdwarf location and (255-n) in the last byte of the LEA instruction, exactly 16 bytes later.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: 0x517A5D on February 16, 2023, 12:24:45 pm
If someone comes up with a patch that works for start dwarf counts less than 7 (such as, oh I don't know, one), that I might be more interested in...

But... you can.  I just did it in the debugger.  The only trick is, you need to embark with at least 6 animals.  (4 purchased animals and the 2 wagon animals.)

Poking at it a bit, the obvious solution is to patch n into the startdwarf location and (255-n) in the last byte of the LEA instruction, exactly 16 bytes later.

On inspection, that would work.  The limit would be 126 127 dwarves before the LEA starts adding instead of subtracting.

Fragile as anything, though.  There's no telling what the optimizer will do to the code in future releases.  I sure wouldn't want to hardcode a 16 byte offset in hopes that it magically will always work.

Thank you for looking at this.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: Clément on February 16, 2023, 02:42:48 pm
Where is the "init.d" directory mentioned in the documentation (https://docs.dfhack.org/en/latest/docs/Core.html#init-d-lua) supposed to be created? It says "main DF directory" but it does not work for me. The only occurence of init.d I find in the code is for "raw/init.d".

Or what is the best way to run a lua command on startup? Should I rather create a "dfhack-config/init/dfhack-....init" file containing ":lua ..."?
I'm asking again. Sorry for spamming, I think it may have been forgotten at the end of the previous page.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: Uthimienure on February 16, 2023, 04:47:44 pm
I know the DFHack devs are focusing on .50.xx, but is there any chance you could do a small QoL improvement for those that prefer .47.05 ?

When a dwarf makes an artifact that's a family heirloom, I put a display case in their room for it.  Finding the artifact among the dozens of pages of Non-Sortable artifacts is a real pain that gets more painful as the decades pass... can it be made sortable?

This would really make the game less frustrating and I still love .47.05
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: ab9rf on February 16, 2023, 04:49:08 pm
If someone comes up with a patch that works for start dwarf counts less than 7 (such as, oh I don't know, one), that I might be more interested in...

But... you can.  I just did it in the debugger.  The only trick is, you need to embark with at least 6 animals.  (4 purchased animals and the 2 wagon animals.)

Poking at it a bit, the obvious solution is to patch n into the startdwarf location and (255-n) in the last byte of the LEA instruction, exactly 16 bytes later.

On inspection, that would work.  The limit would be 126 127 dwarves before the LEA starts adding instead of subtracting.

Fragile as anything, though.  There's no telling what the optimizer will do to the code in future releases.  I sure wouldn't want to hardcode a 16 byte offset in hopes that it magically will always work.

Thank you for looking at this.
Not to mention it's not remotely likely to work with any future linux builds, which will presumably be built with gcc (or perhaps clang) and thus won't have the same optimizer as MSVC.

I can't say I blame MSVC here, though; the compiler is not under any obligation to make code that can be blithely patched in arbitrary ways by poking at it with a stick, especially when optimization is requested. The resulting code is smaller than any of the alternatives and, as far as I know, is not slower.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: ab9rf on February 16, 2023, 04:53:38 pm
I know the DFHack devs are focusing on .50.xx, but is there any chance you could do a small QoL improvement for those that prefer .47.05 ?

When a dwarf makes an artifact that's a family heirloom, I put a display case in their room for it.  Finding the artifact among the dozens of pages of Non-Sortable artifacts is a real pain that gets more painful as the decades pass... can it be made sortable?

This would really make the game less frustrating and I still love .47.05
It is unlikely that we will make any further official releases for 47.05 for any reason other than to fix a serious bug. We had to significantly redesign our workflow automation to make builds for v50, which means we no longer have the ready means to make release builds for prior versions. Any release for 47.05 would have to be hand-rolled, and we're not likely to go to all the trouble required to do that for anything less than the discovery of a showstopper-level bug.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: Uthimienure on February 16, 2023, 09:35:39 pm
I know the DFHack devs are focusing on .50.xx, but is there any chance you could do a small QoL improvement for those that prefer .47.05 ?

When a dwarf makes an artifact that's a family heirloom, I put a display case in their room for it.  Finding the artifact among the dozens of pages of Non-Sortable artifacts is a real pain that gets more painful as the decades pass... can it be made sortable?

This would really make the game less frustrating and I still love .47.05
It is unlikely that we will make any further official releases for 47.05 for any reason other than to fix a serious bug. We had to significantly redesign our workflow automation to make builds for v50, which means we no longer have the ready means to make release builds for prior versions. Any release for 47.05 would have to be hand-rolled, and we're not likely to go to all the trouble required to do that for anything less than the discovery of a showstopper-level bug.
Thanks for the reply.  It's hard being a dinosaur.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: myk on February 17, 2023, 03:03:24 pm
Where is the "init.d" directory mentioned in the documentation (https://docs.dfhack.org/en/latest/docs/Core.html#init-d-lua) supposed to be created? It says "main DF directory" but it does not work for me. The only occurence of init.d I find in the code is for "raw/init.d".

Or what is the best way to run a lua command on startup? Should I rather create a "dfhack-config/init/dfhack-....init" file containing ":lua ..."?
I'm asking again. Sorry for spamming, I think it may have been forgotten at the end of the previous page.

and you again somehow got the last slot on the page : p

You *can* use the "init.d" directory, but I think the best solution for you, as you surmised, would be to add a file to "dfhack-config/init/dfhacksomething.init"
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: myk on February 17, 2023, 03:07:30 pm
Thanks for the reply.  It's hard being a dinosaur.

Note that we made a branch for 0.47.05-compatible code, so if you do want to make a code change that implements a feature, you can check out that branch, make whatever changes are needed, and build it yourself. Docs for how to do that are here: https://docs.dfhack.org/en/0.47.05-r8/docs/dev/Compile.html

The branch is named "v0.47.05", so you'll need to switch to that branch from the default "develop" branch.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: Uthimienure on February 17, 2023, 07:23:34 pm
Thanks for the reply.  It's hard being a dinosaur.

Note that we made a branch for 0.47.05-compatible code, so if you do want to make a code change that implements a feature, you can check out that branch, make whatever changes are needed, and build it yourself. Docs for how to do that are here: https://docs.dfhack.org/en/0.47.05-r8/docs/dev/Compile.html

The branch is named "v0.47.05", so you'll need to switch to that branch from the default "develop" branch.

Thank you myk.  It's nice to have an option, even if I would need to learn to program in C++
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: Rumrusher on February 21, 2023, 03:41:17 am
ok so screwing around with DF 50 and decided to poke around with jumping into viewscreens again.
this here is the game mode view screen script which lets you force DF to bring up the game mode menu screen.
which has some interesting interactions mid fort mode session as if you embark again near your current fort the game will load in the next land mass chunk
Spoiler (click to show/hide)
Code: ("game-menu.lua") [Select]
local old_screen=dfhack.gui.getCurViewscreen()
local new_screen=df.viewscreen_choose_game_typest:new()
old_screen.child=new_screen
new_screen.parent=old_screen

new_screen.gametypes:insert("#",0)
new_screen.gametypes:insert("#",2)

which leads to the next port of an old script. the mobile campboats got remade into a nanofort shuttle script which lets one take a nano fort and move it around the embark screen when combined with the game menu script to jump back into the embark menu again you can unretire your nano fort and connect said fort to the previous fort.
another thing of note for doing this I been calling the process of unloaded map chunks digging and exploring the void and kinda been seeing this set up as Void forts where your main void fort is latching on to these other forts as a source for supplies and equipment and when you have your fill with the place you just move everyone back to the main void fort location and retire.
edit 4/21/2023: I went back and edited the name of the old station name script to reflect that these forts don't need to be nano to move around.
Spoiler (click to show/hide)
Code: ("StationMove.lua") [Select]
--nano-boat-station-for-void-forts

local dlg=require("gui.dialogs")

function teleportboatnames2()
local Ark={}
for k,v in pairs(df.global.world.world_data.sites) do
if v.name.first_name=="STATION" then
BoaName=dfhack.TranslateName(v.name)
table.insert (Ark,{dfhack.TranslateName(v.name).." "..v.name.nickname,nil,v})

end
end
local f=function(Name,C)
  MobileFortNano(C[3])
  --teleportboatlista(C[3])
end
dlg.showListPrompt("list of stations","Select Station(s) to settle here",COLOR_WHITE,Ark,f)
end

function MobileFortNano(siteID)
local MapCure=df.global.gview.view.child.location
local MapCurx=MapCure.region_pos.x
local MapCury=MapCure.region_pos.y
local MapCurEmbark=MapCure.embark_pos_min
local Fortsite=siteID.index
df.global.world.world_data.sites[Fortsite].pos.x=MapCurx
df.global.world.world_data.sites[Fortsite].pos.y=MapCury
df.global.world.world_data.sites[Fortsite].rgn_min_x=MapCurEmbark.x
df.global.world.world_data.sites[Fortsite].rgn_max_x=MapCurEmbark.x
df.global.world.world_data.sites[Fortsite].rgn_min_y=MapCurEmbark.y
df.global.world.world_data.sites[Fortsite].rgn_max_y=MapCurEmbark.y
df.global.world.world_data.sites[Fortsite].global_min_x=MapCurEmbark.x
df.global.world.world_data.sites[Fortsite].global_max_x=MapCurEmbark.x
df.global.world.world_data.sites[Fortsite].global_min_y=MapCurEmbark.y
df.global.world.world_data.sites[Fortsite].global_max_y=MapCurEmbark.y
end

if df.global.gview.view.child==nil then
print("this script requires you to be in the raid menu to work")
else
teleportboatnames2()
end
and
Code: ("StationSetup.lua") [Select]
local dlg=require("gui.dialogs")

function nameStation()
df.global.world.world_data.sites[df.global.plotinfo.site_id-1].name.first_name="STATION"
df.global.world.world_data.sites[df.global.plotinfo.site_id-1].name.nickname="VoidShuttle"
dlg.showMessage("Travel-Hack","Converting fort into VoidStation")
end
nameStation()
so Station move script functions in embark menu as you set up your embark size and select the destination while not confirming the warning prompt that shows up as you use that to lock the coord in place so the script can function.
the script will then pull a list of 'Stations' to put into that spot, you probably want to then back to selecting a spot to embark to actually embark.
the second script is for setting up the nano fort to be a 'Nano Fort Station' so you can select said site from the pool of other Stations.
the process works as running the script while playing the nano fort then I guess save and or retire the nano fort.

should be warned void fort playstyle is a bit open to either being a novelty gimmick or potentially run ending levels of dangerous if you don't keep tabs on your important citizens while preparing to break off from the site you latch on too.
oh and you can totally dig into the void/un-allocated space doing this.
 the script works on nano forts so making it take any size of your fort to move would take a bit more work and probably more ram space to load up two larger forts next to each other.
that said you could make a large first fort then move and second embark a nano void fort next to that site to tap into the resources.

oh and be careful on z level stuff moving around the world map and connecting to other forts might lead to having one fort higher or lower than the other and might require digging into the other site to connect to it.
oh and if you want to preserve the stuff you made and the units you gotten, you may want to move into the second/last/latest fort in the chain of game mode caused fort re-embarkings.
anything built in the void is temporary on retire and back in 47 visiting the place in adv mode led to the locations being filled back in to the normal terrain. so you might end up with dwarves trapped in soil and rock.

so have fun exploring the world through void traveling into other forts(or just connecting the fort directly to the other fort side by side)

oh yeah I should dump the script that hides other sites and unhides them so you can embark on pre-gen sites and loot them as well

Code: ("hide-sites.lua") [Select]
for k,v in pairs(df.global.world.world_data.sites) do
if v.type~=0 then
v.flags[0]=true
end
end


Code: ("reveal-sites.lua") [Select]
for k,v in pairs(df.global.world.world_data.sites) do
if v.type~=0 then
v.flags[0]=false
end
end

these scripts will hide and reveal sites that are not player sites.
should also note if you hide the sites at the start of the game and play fort mode for a bit longer and retire and unretire the game will spawn in more sites, so you could end up with means to raid and attack folks and also accidentally embark over a tomb or dark pit's burial grounds.


edit : ok here's a short script that converts explore ruin missions to be one that let's you conquer them,

Code: ("site-reclaim.lua") [Select]
local si2=df.global.gview.view.child.child.army_controller
local si=df.global.gview.view.child.child.army_controller[0].site_id
for fo,rm in pairs (si2) do
if rm.type==2 then
if rm.data.InvasionOrder.unk_1==5 then
rm.data.InvasionOrder.unk_1=2
end
end
end

just run this while in the world map screen in DF 50. for the folks who overkilled a location and didn't get the chance to conquer it and or not feeling like reclaiming and retiring a ruin site.


edit: ok so here's an update to station move that lets you move any size void fort
Code: ("stationmovemath.lua") [Select]
local dlg=require("gui.dialogs")


function teleportboatnames3()
local Ark={}
for k,v in pairs(df.global.world.world_data.sites) do
if v.name.first_name=="STATION" then
BoaName=dfhack.TranslateName(v.name)
table.insert (Ark,{dfhack.TranslateName(v.name).." "..v.name.nickname,nil,v})
end
end
local f=function(Name,C)
  MobileFortNano(C[3])
end
dlg.showListPrompt("list of stations","Select Station(s) to settle here",COLOR_WHITE,Ark,f)
end
function stationmove()
if df.global.gview.view.child==nil then
print("this script requires you to be in the raid menu to work")
else
teleportboatnames3()
end
end


function MobileFortNano(siteID)
--local MapCurx=df.global.gview.view.child.location._x
local MapCure=df.global.gview.view.child.location
--local MapCure=df.global.gview.view.child.child.location
local MapCurx=MapCure.region_pos.x
local MapCury=MapCure.region_pos.y
local MapCurEmbark=MapCure.embark_pos_min
local MapCurEmbark2=MapCure.embark_pos_max
local Fortsite=siteID.index
local FortSize=df.global.world.world_data.sites[Fortsite]
local math1=FortSize.rgn_min_x-FortSize.rgn_max_x
local math1a=FortSize.rgn_min_y-FortSize.rgn_max_y
local math2=MapCurEmbark.x-MapCurEmbark2.x
local math2a=MapCurEmbark.y-MapCurEmbark2.y
if math1==math2 and math1a==math2a then
--print("works")
df.global.world.world_data.sites[Fortsite].pos.x=MapCurx
df.global.world.world_data.sites[Fortsite].pos.y=MapCury
df.global.world.world_data.sites[Fortsite].rgn_min_x=MapCurEmbark.x
df.global.world.world_data.sites[Fortsite].rgn_max_x=MapCurEmbark2.x
df.global.world.world_data.sites[Fortsite].rgn_min_y=MapCurEmbark.y
df.global.world.world_data.sites[Fortsite].rgn_max_y=MapCurEmbark2.y
df.global.world.world_data.sites[Fortsite].global_min_x=MapCurEmbark.x
df.global.world.world_data.sites[Fortsite].global_max_x=MapCurEmbark2.x
df.global.world.world_data.sites[Fortsite].global_min_y=MapCurEmbark.y
df.global.world.world_data.sites[Fortsite].global_max_y=MapCurEmbark2.y
else
dlg.showMessage("Travel-Hack-Error","incorrect fort size change to correct size")

print('incorrect fort size change to correct size')
end
end

stationmove()
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: Inatun on February 22, 2023, 12:56:43 pm
Is there a way to create a specific amount of mud on a tile? I'm running a test on new soil quality mechanics that involves artificially irrigated stone and I want fine control over how much mud is made just to reduce variables.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: Schmaven on February 22, 2023, 08:34:05 pm
The liquids spawning command should do what you want.  I think there's only 3 levels of mud: pile of mud; dusting of mud; and no mud.  A dusting is created by first contact with water.  Subsequent contacts produce the thicker mud.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha1 (pre-release)
Post by: myk on February 24, 2023, 07:24:55 pm
DFHack 50.07-alpha2 released!

Clear things away with gui/mass-remove:
(https://user-images.githubusercontent.com/977482/221298277-16785888-1429-44a4-acd9-46c084db6536.gif)

Trade with less clicking:
(https://user-images.githubusercontent.com/977482/221301094-073ccd82-1919-401e-ae47-591a349f94e8.gif)

Lay down designs with gui/dig:
(https://user-images.githubusercontent.com/977482/221315199-844f7067-f982-49e3-89dd-ca496030d648.gif)

Get it here: https://github.com/DFHack/dfhack/releases/tag/50.07-alpha2
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha2 (pre-release)
Post by: Rumrusher on March 01, 2023, 05:42:26 pm
Code: ("force-petition.lua") [Select]
--this script is made as means to petition folks to join a fort manually requires mining cursor to work
--doesn't work on folks who don't have a historical figure so watch out.
--this script re-uses warmist and other folks in the dfhack community functions to get access to the cursor
local ui=plotinfo
function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end
function getCreatureAtPos(x,y,z) -- gets the creature index @ x,y,z coord
--local x,y,z=getxyz() --get 'X' coords
local vector=df.global.world.units.all -- load all creatures
for i = 0, #vector-1 do -- look into all creatures offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==x and cy==y and cz==z then --compare them
return vector[i] --return index
end
end
return nil

end

function petition()
local ui=plotinfo

local Shell=getCreatureAtPos(getxyz())
local Agree=df.global.world.agreements.all
Agree:insert("#",{new=true,id='-10',next_party_id=2,next_details_id=1})
local dd=Agree[#Agree - 1]
print('oh no')
dd.id = df.global.agreement_next_id
df.global.agreement_next_id = df.global.agreement_next_id + 1
dd.details:insert("#",{new=true,type=3})
dd.parties:insert("#",{new=true})
dd.parties:insert("#",{new=true})
dd.details[0].data.Citizenship=df.agreement_details_data_citizenship:new()
dd.details[0].data.Citizenship.applicant=0
dd.details[0].data.Citizenship.government=1
dd.details[0].data.Citizenship.site=df.global.plotinfo.site_id
dd.parties[0].histfig_ids:insert("#",0)
dd.parties[0].histfig_ids[0]=Shell.hist_figure_id
dd.parties[1].id=1
dd.parties[1].entity_ids:insert("#",0)
dd.parties[1].entity_ids[0]=df.global.plotinfo.group_id
df.global.plotinfo.petitions:insert("#",dd.id)

end
function petition2()
local ui=plotinfo

local Shell=getCreatureAtPos(getxyz())
local Agree=df.global.world.agreements.all
Agree:insert("#",{new=true,id='-10',next_party_id=2,next_details_id=1})
local dd=Agree[#Agree - 1]
print('oh no')
dd.id = df.global.agreement_next_id
df.global.agreement_next_id = df.global.agreement_next_id + 1
dd.details:insert("#",{new=true,type=2})
dd.parties:insert("#",{new=true})
dd.parties:insert("#",{new=true})
dd.details[0].data.Residency=df.agreement_details_data_residency:new()
dd.details[0].data.Residency.reason=3
dd.details[0].data.Residency.applicant=0
dd.details[0].data.Residency.government=1
dd.details[0].data.Residency.site=df.global.plotinfo.site_id
dd.parties[0].histfig_ids:insert("#",0)
dd.parties[0].histfig_ids[0]=Shell.hist_figure_id
dd.parties[1].id=1
dd.parties[1].entity_ids:insert("#",0)
dd.parties[1].entity_ids[0]=df.global.plotinfo.group_id
df.global.plotinfo.petitions:insert("#",dd.id)

end
petition2()
petition()

well here's a revised DF50 version of the force petition script I made some time ago.

it uses the mining cursor to function and mostly works on folks with a historical figure so non-hist figs might not join.

Title: Re: DFHack 0.47.05-r8 | 50.07-alpha2 (pre-release)
Post by: Jazz Cat on March 06, 2023, 07:33:15 pm
I apologize if this has been asked before, but is there a utility in the works that removes the work detail system entirely so it can be replaced with other stuff (ie, Kloker or Therapist)?
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha2 (pre-release)
Post by: myk on March 06, 2023, 08:41:29 pm
DF has a flag that can disable the work details system to allow for external control. both DT and DFHack's autolabor set this flag so they can work. There has been some discussion about some sort of central mechanism for handling the flag state so multiple applications won't step on each other's edits. For now, it's probably up to the player to ensure they're only using one of the "flag clients" at a time.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha2 (pre-release)
Post by: myk on March 11, 2023, 07:09:03 pm
DFHack 50.07-alpha3 released!

Easily plan out buildings before you have materials with buildingplan:
(https://user-images.githubusercontent.com/977482/224515695-e240e8ee-342b-410e-8078-d2c8f1f6522e.gif)

Ensure your screw pumps are magma-safe with just one click:
(https://user-images.githubusercontent.com/977482/224515954-f4741444-d5cd-42dc-8454-b496377b2b70.gif)

Control the quality of items used as materials:
(https://user-images.githubusercontent.com/977482/224516161-5481dbb7-4f6f-4e13-9c53-785bc8f4827d.gif)

Select which materials you want to build with:
(https://user-images.githubusercontent.com/977482/224516476-a8e78c6d-4eb1-454a-8d04-c92bf04d6145.gif)

Select specific items if you want to:
(https://user-images.githubusercontent.com/977482/224516607-d93fc424-b5a1-4dec-af77-14f16dd89f34.gif)

Symmetrical shapes with gui/dig:
(https://user-images.githubusercontent.com/4482627/223886026-b12ec0f3-1136-45b0-b070-55b8de5101b0.gif)

Get it here: https://github.com/DFHack/dfhack/releases/tag/50.07-alpha3
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha2 (pre-release)
Post by: Rumrusher on March 16, 2023, 04:22:12 am
(https://cdn.discordapp.com/attachments/302956330304667649/1085874661155418152/starting-seven-script-showcase-revised.gif)
Code: ("7start.lua") [Select]
local MapCure=df.global.gview.view.child.child

local options = {}

local argparse = require('argparse')
local commands = argparse.processArgsGetopt({...}, {
    {'d', 'dead', handler=function() options.dead = true end}
})


--this script uses my old campboat set up to make a gui list for the starting 7
--and a list for the creatures you would be converting them into.

local dlg=require("gui.dialogs")

function teleportboatnames2()
local Ark={}
for k,v in pairs(MapCure.s_unit) do
BoaName=dfhack.TranslateName(v.name)
table.insert (Ark,{dfhack.TranslateName(v.name).." "..v.name.nickname,nil,v,search_key = BoaName:lower()})
end
local f=function(Name,C)
unretire_all(C[3])
end
dlg.showListPrompt("list of units","Select starting unit to settle here",COLOR_WHITE,Ark,f,nil,nil,true)
end

function unretire_all(unit2)
Ark2={}
for num,se in pairs(df.global.world.raws.creatures.all) do
CreatureName=se.creature_id
table.insert (Ark2,{se.creature_id.." "..se.name[0],nil,num,search_key = CreatureName:lower()})
end
local f=function(Name,C2)
unit2.name.nickname=df.global.world.raws.creatures.all[C2[3]].name[0]
unit2.enemy.normal_race=C2[3]
for cas,cast in pairs(df.global.world.raws.creatures.all[C2[3]].caste) do
if unit2.enemy.normal_caste > cas then
unit2.enemy.normal_caste=cas
end
end
end
dlg.showListPrompt("list of creatures","Select creature to change here",COLOR_WHITE,Ark2,f,nil,nil,true)
end

if df.global.gview.view.child==nil then
print("this script requires you to be in the raid menu to work")
else
teleportboatnames2()
end

this has to be done on the prepare carefully embark screen, and this wouldn't save the profile to these creature ids.


edit: ok having now test this script on embark it might need some time testing. highly likely to crash currently working on the caste issue.


edit 2: ok so got the embark crash issue fixed now it should transform the dwarves(or citizens if you play modded) into the forms you set them... and for player experience made it so you can tell which citizen is going to turn into.
also the caste issue is also set.
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha2 (pre-release)
Post by: Morning_Oak on March 16, 2023, 02:11:27 pm
This is awesome, thank you.

Using the 7start function, any way to not make them all female?
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha2 (pre-release)
Post by: Schmaven on March 16, 2023, 07:09:09 pm
Now to try an octopus fort!
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha2 (pre-release)
Post by: Roses on March 16, 2023, 07:42:24 pm
Wonderful work! Very excited to try all the new features
Title: Re: DFHack 0.47.05-r8 | 50.07-alpha2 (pre-release)
Post by: myk on March 17, 2023, 02:42:35 pm
DFHack 50.07-beta1 released!

Prevent missed corners with the new suspendmanager (active in video on the right side):
(https://user-images.githubusercontent.com/977482/225996471-32004486-dce0-4af6-8c80-05e027dcb4f4.gif)

Turn suspendmanager on in gui/control-panel:
(https://user-images.githubusercontent.com/977482/225998702-1aadc115-1f42-4017-a714-62b526c48d98.gif)

Get it here: https://github.com/DFHack/dfhack/releases/tag/50.07-beta1
Title: Re: DFHack 0.47.05-r8 | 50.07-beta1 (pre-release)
Post by: Not a Cylon on March 18, 2023, 04:55:59 pm
Nice! Manually suspending stuff has been driving me nuts. It seems it misses cases that aren't corners, though. My setup:

FfffffFfWWfFfffffF
R                R

Here W is a bit of wall that's already there, R is where the ramps up to this level are, and f or F is a floor. The spaces are empty space. I'm trying to place walls on all the floors. The capital Fs are the ones where the wall job is suspended. But of course it's wrong - everything but the floors closest to the middle walls should be suspended. Was really hoping to use suspendmanager to help with this sort of thing (building high walls) since it's a massive pain to have to unsuspend them one by one (or build a floor which then needs to be removed carefully).
Title: Re: DFHack 0.47.05-r8 | 50.07-beta1 (pre-release)
Post by: myk on March 18, 2023, 10:52:54 pm
That is a good idea to handle that case. Could you file a feature request at https://github.com/DFHack/dfhack/issues ? I'll ping the suspendmanager author to see if they would be interested in figuring out how to implement this.
Title: Re: DFHack 0.47.05-r8 | 50.07-beta1 (pre-release)
Post by: Not a Cylon on March 19, 2023, 02:11:23 pm
Sure, done: https://github.com/DFHack/dfhack/issues/3049

Something else I'd love to see: I desperately need to see announcements for ghosts of non-citizens. (Is that a known bug? Seems very consistent for me that non-citiizen ghosts don't produce announcements.) I have lost four dwarves in this fort because I have a lot of non-citizens around, they never get buried, and I only learn that there's a ghost when they scare someone to death. At this point I'm motivated enough to write a script if it's not too hard (looking at the API, I can see how to find whether a unit is a ghost and how to make an announcement, but it's not obvious how to know whether the announcement has been made before).
Title: Re: DFHack 0.47.05-r8 | 50.07-beta1 (pre-release)
Post by: myk on March 19, 2023, 04:57:06 pm
Instead of an announcement, we *could* instead have an on-screen alert widget that shows important status messages (with options to hide, jump to target, etc.). It could appear near the lower left corner when there is trouble to report.

It could replace warn-starving and warn-stealers, for example, and be a central place to scan for other issues that are important to bring to the player's attention.

also, are non-citizens not handled by autoslab? if not, should they be?
Title: Re: DFHack 0.47.05-r8 | 50.07-beta1 (pre-release)
Post by: Dwarf Kitty on March 19, 2023, 08:03:18 pm
Just updated DFHack to the beta1 release, first one I have with buildingplan.


Been building up a stone fort, all one variety of stone.  I have boulders and blocks of said stone.  Buildingplan grouped both boulders and blocks together.  I'd rather have them separate, since I might still need boulders for furniture, and blocks are more valuable anyway.


Even with the need to manually select from the item list, though, it's still faster and a bit easier than vanilla DF.
Title: Re: DFHack 0.47.05-r8 | 50.07-beta1 (pre-release)
Post by: myk on March 19, 2023, 08:06:14 pm
This will be more discoverable in the future, but there is a global setting for whether boulders will be chosen for building constructions. You can set it via the commandline

buildingplan set boulders false

Or in any filter dialog in the "global settings" tab
Title: Re: DFHack 0.47.05-r8 | 50.07-beta1 (pre-release)
Post by: Not a Cylon on March 20, 2023, 04:25:15 pm
Instead of an announcement, we *could* instead have an on-screen alert widget that shows important status messages (with options to hide, jump to target, etc.). It could appear near the lower left corner when there is trouble to report.

That would be great, yeah!

Quote
also, are non-citizens not handled by autoslab? if not, should they be?

Dunno, I don't have it on. I don't so much mind having to engrave so long as I'm aware of the problem.
Title: Re: DFHack 0.47.05-r8 | 50.07-beta1 (pre-release)
Post by: Dwarf Kitty on March 20, 2023, 07:24:19 pm
This will be more discoverable in the future, but there is a global setting for whether boulders will be chosen for building constructions. You can set it via the commandline

buildingplan set boulders false

Or in any filter dialog in the "global settings" tab


Yep, those settings are in the buildingplan help documentation, which I forgot to read.  Went straight to the gui instead.
Title: Re: DFHack 0.47.05-r8 | 50.07-beta1 (pre-release)
Post by: myk on March 31, 2023, 03:01:58 pm
DFHack 50.07-beta2 released!

keep your civilians safe during sieges with gui/civ-alert:
(https://user-images.githubusercontent.com/977482/229216736-925209ce-69be-4596-9ba4-c417854216e3.gif)

enable the general strike bug fix in gui/control-panel:
(https://user-images.githubusercontent.com/977482/229214894-b20ac437-8a28-4b87-9b4c-2bb3996299a0.gif)

Get it here: https://github.com/DFHack/dfhack/releases/tag/50.07-beta2
Title: Re: DFHack 0.47.05-r8 | 50.07-beta1 (pre-release)
Post by: 0x517A5D on March 31, 2023, 11:14:04 pm
Quote from: Release Notes
Support for scripts in DF mods

Whaaaat?? Yes, it's true. Scripts with mods now work automatically as soon as you activate them for a world. No more manual copying of scripts after "installation". This allows everything from single scripts to total conversion mods that add new scripted gameplay elements to work seamlessly, straight from the DF Steam Workshop. See the DFHack modding guide for details. You can also subscribe to the example Workshop mod to see a real example of how to distribute scripts via Steam Workshop (though the format is applicable to mods distributed by non-Steam means as well).

This is very interesting and looks well-thought-out.  Thank you.
Title: Re: DFHack 0.47.05-r8 | 50.07-beta1 (pre-release)
Post by: myk on April 01, 2023, 12:34:08 am
Thanks! The goal is to make scripted modding more accessible to modders and to make installation (and update) of these mods painless for players. I hope to make the process even smoother for the next DFHack version -- right now mods need to be marked "active" at least once for DFHack to pick them up. This doesn't really make sense for script-only mods that have no effect on worldgen. By the next version of DFHack, just subscribing to those mods in Steam Workshop should be enough for DFHack to find them and make them available in a running game.
Title: Re: DFHack 0.47.05-r8 | 50.07-beta2 (pre-release)
Post by: Rumrusher on April 03, 2023, 10:36:56 pm
(https://cdn.discordapp.com/attachments/302956330304667649/1092653280577998890/announcement-showcase.png)

Code: ("ann.lua") [Select]
--proof of concept of an announcement menu.

local dlg=require("gui.dialogs")

local JUNK={}
local Dang=df.global.world.status.announcements

  for ultimate,checked_Ann in pairs(Dang) do
local mono=checked_Ann.text

      table.insert(JUNK,{mono,search_key = mono:lower()})
end
 
 dlg.showListPrompt("Announcement list","scroll through the list of Announced alerts",COLOR_WHITE,JUNK,nil,nil,nil,nil,true)

ok so out of boredom I decided to write up a script that grabs all the alerts/reports and shoves them into a list... there was a previous version of this script that grab every report but some folks don't want to sift through combat logs so I made this instead. there was an attempt at adding a filter on it but shrugs.
Title: Re: DFHack 0.47.05-r8 | 50.07-beta2 (pre-release)
Post by: 0x517A5D on April 06, 2023, 03:33:10 pm
So, scripts included in mods.

I can only get them to auto-run if I make them into modules:
Code: (example_mod.lua) [Select]
--@ module = true

if not dfhack_flags.module then
    print("data/installed_mods/example_mod (100)/scripts_modactive/example_mod.lua ran.")
else
    print("data/installed_mods/example_mod (100)/scripts_modactive/example_mod.lua ran as a module.")
end

This will log the 'ran as a module' line the first time a world is loaded.  (One that uses the mod, of course.)

But only the first time.  If I exit back to the startup menu, and reload the world, the script doesn't run again.

Is this expected behavior?  Do I need to figure out how to make hooks/callbacks for the module?

Is there any (implemented or planned) support for onLoad.init and friends?  I couldn't make it work.
Title: Re: DFHack 0.47.05-r8 | 50.07-beta2 (pre-release)
Post by: myk on April 06, 2023, 03:59:51 pm
To run code on world load/unload, you should add a hook to  dfhack.onStateChange. There's a full example you can follow in the DFHack modding guide: https://docs.dfhack.org/en/latest/docs/guides/modding-guide.html#putting-it-all-together

The script itself only "runs" once right now because of caching. That's usually the correct behavior, but I should actually change that in this case so active mods can completely remove their hooks on world unload and still have a chance to recreate them for the next world load. Active mods shouldn't let their state change hooks be permanent since otherwise they might load into worlds where they're not active.
Title: Re: DFHack 0.47.05-r8 | 50.07-beta2 (pre-release)
Post by: xzaxza on April 07, 2023, 05:32:40 am
Hi,

I'm not a lua expert, so when I'm making dfhack scripts I run into the occasional problem. Like, when I made a script to list links of a workshop, I figured I could make it more complete and include stockpiles too. But for workshops, links are apparently stored in building.profile.links, while for stockpiles they're at building.links. Then this might happen:

...47.05-r5/df_47_05_linux/hack/scripts/cust/links_test.lua:47: Cannot read field building_stockpilest.profile: not found.

I've managed to work around that this time, but my actual question is: is there a sane way to test if a field exists? That is, in such a way that doesn't cause an error.

Also, sort-items doesn't work with building materials, so I've been kinda thinking about making something that'd allow searching for a specific material or furniture from the menu. Or has it been done? Also, I've been missing similar functionality for display furniture, because it's a pain to find an item there. Or does that exist already?
Title: Re: DFHack 0.47.05-r8 | 50.07-beta2 (pre-release)
Post by: myk on April 07, 2023, 03:00:39 pm
In general, you can protect yourself from errors with pcall. For example:
Code: [Select]
local ok, ret = pcall(function()
    -- do something sketchy
end)

but in this case, you'd probably be best off with testing the type of the pointer before trying to access fields that only exist in some types.

Code: [Select]
local bld = thebuidlinginquestion
if bld:getType() == df.building_type.Workshop then
    -- access workshop fields
elseif bld::getType() == df.building_type.Stockpile then
    -- access stockpile fields
end
Title: Re: DFHack 0.47.05-r8 | 50.07-beta2 (pre-release)
Post by: 0x517A5D on April 11, 2023, 11:06:53 am
Is this the proper way to do a mod's auto-run module?  Are there best practices that I'm not following?



Code: (info.txt) [Select]
[ID:lighter_green_glass]
[NUMERIC_VERSION:100]
[DISPLAYED_VERSION:1.00]
[EARLIEST_COMPATIBLE_NUMERIC_VERSION:100]
[EARLIEST_COMPATIBLE_DISPLAYED_VERSION:1.00]
[AUTHOR:0x517A5D]
[NAME:Lighter Green Glass Items]
[DESCRIPTION:Reduces the density of green glass, which reduces the weight of green glass items.  Requires DFHack.]



Code: (lighter_green_glass.lua) [Select]
--@ module = true
local utils = require('utils')

local mod_ID = 'lighter_green_glass' -- ID of the mod, per init.txt.
local script_name = 'lighter_green_glass' -- name of this script, without the .lua extension.
local GLOBAL_KEY = script_name -- unique key for the state-change callback.

if not dfhack_flags.module then
    print(string.format("The %s script is auto-executed when the %s mod is loaded;", script_name, mod_ID))
    print('It is not intended to be invoked directly.  No action taken.')
    return
end

---- define locals.  Note: only initialize locals that will never change, even on world reload.

local gg_original_density = df.global.world.raws.mat_table.builtin.GLASS_GREEN.solid_density

---- implementation code

local function activate_mod_raws_changes()
    df.global.world.raws.mat_table.builtin.GLASS_GREEN.solid_density = math.floor(gg_original_density/5)
end

local function deactivate_mod_raws_changes()
    df.global.world.raws.mat_table.builtin.GLASS_GREEN.solid_density = gg_original_density
end

local function mod_is_loaded()
    -- df.global.world.object_loader.object_loader_order_id[] is an array of strings.
    -- search it for the ID of our mod.  if it exists, the mod is loaded.
    return(utils.linear_index(df.global.world.object_loader.object_load_order_id, mod_ID, 'value') ~= nil)
end

---- install hook for callbacks.

if dfhack_flags.module then
    dfhack.onStateChange[GLOBAL_KEY] = function(event)
if event == SC_WORLD_LOADED and mod_is_loaded() then
            activate_mod_raws_changes()
elseif event == SC_WORLD_UNLOADED and mod_is_loaded() then
            deactivate_mod_raws_changes()
end
    end
end



This mod doesn't need any user interaction.  I tried to get it to load as an internal module, but was not successful.  Here's a list of the directories I tried:
Title: Re: DFHack 0.47.05-r8 | 50.07-beta2 (pre-release)
Post by: myk on April 11, 2023, 11:43:22 am
Is this the proper way to do a mod's auto-run module?  Are there best practices that I'm not following?

Let me see if I can do code review in this format. Hopefully it will be easy enough to follow.

First of all, "internal" modules refer to modules that are internal relative to your mod. They are explicitly ignored by the DFHack mod scanning. The script should go in
Code: [Select]
lighter_green_glass (100)/scripts_modactive in order to get picked up and loaded.

This *does* allow your script to be shown in gui/launcher as a runnable script, but that's not a bad thing. That gives you a mechanism to show your help text, reminding the user what the mod does and telling them how to control it (if/when you implement adjustable controls).

Incidentally, this file needs help text : ) The format is documented here: https://docs.dfhack.org/en/latest/docs/dev/Documentation.html#external-scripts-and-plugins

Quote
Code: [Select]
local function mod_is_loaded()
    -- df.global.world.object_loader.object_loader_order_id[] is an array of strings.
    -- search it for the ID of our mod.  if it exists, the mod is loaded.
    return(utils.linear_index(df.global.world.object_loader.object_load_order_id, mod_ID, 'value') ~= nil)
end
You don't need this part. Once your script is in the correct location, it will load if and only if it is active for the current world.

Quote
Code: [Select]
if dfhack_flags.module then
    dfhack.onStateChange[GLOBAL_KEY] = function(event)
if event == SC_WORLD_LOADED and mod_is_loaded() then
            activate_mod_raws_changes()
elseif event == SC_WORLD_UNLOADED and mod_is_loaded() then
            deactivate_mod_raws_changes()
end
    end
end
You don't need to check for dfhack_flags.module since you've already filtered out the cases where that variable is not true. Also, as mentioned above, you don't need to check if the mod is loaded since being in the correct path will do that for you.

Also, be sure to completely remove your state change handler on world unload, otherwise your handler will still run in a later-loaded world where the mod is not active. I just recently realized this was a problem and updated the example in the modding guide (https://docs.dfhack.org/en/latest/docs/guides/modding-guide.html#putting-it-all-together). If a world with your mod active is loaded a second time, the script will be reloaded as a module before the world loaded event and will have an opportunity to reattach the handler.

Suggested replacement code:
Code: [Select]
dfhack.onStateChange[GLOBAL_KEY] = function(event)
    if event == SC_WORLD_LOADED then
        activate_mod_raws_changes()
    elseif event == SC_WORLD_UNLOADED then
        deactivate_mod_raws_changes()
        dfhack.onStateChange[GLOBAL_KEY] = nil
    end
end

It is not required, but if you implement the enabled API, it would:
1. feature your mod in the DFHack control panel (in the "Fort" tab), including a link to show your help text
2. allow players to use the enable and disable commands to dynamically control your mod

Implementing the enabled API just means adding a --@enable=true tag at the top of the file, implementing an isEnabled() function, and handling the dfhack_flags.enable_state flag. The example in the modding guide does this.

I have to say, this is a beautifully simple mod. Do you mind if I use it as an example in the modding guide?
Title: Re: DFHack 0.47.05-r8 | 50.07-beta2 (pre-release)
Post by: 0x517A5D on April 12, 2023, 03:22:11 pm
Quote
Code: [Select]
local function mod_is_loaded()
    -- df.global.world.object_loader.object_loader_order_id[] is an array of strings.
    -- search it for the ID of our mod.  if it exists, the mod is loaded.
    return(utils.linear_index(df.global.world.object_loader.object_load_order_id, mod_ID, 'value') ~= nil)
end
You don't need this part. Once your script is in the correct location, it will load if and only if it is active for the current world.
This was a workaround, because I was experiencing the mod being active.  I was pretty sure the mod wasn't being loaded into the new world, but rather that it was still active in the dfhack.onStateChange[] table.  I'll  put in your patch to remove the onStateChange[], hopefully removing the need for this.

Quote
You don't need to check for dfhack_flags.module since you've already filtered out the cases where that variable is not true. Also, as mentioned above, you don't need to check if the mod is loaded since being in the correct path will do that for you.
I did know that.  That test is in there for development debugging.  Like:

Code: [Select]
if dfhack_flags.module then
    dfhack.onStateChange[GLOBAL_KEY] = function(event)
if event == SC_WORLD_LOADED and mod_is_loaded() then
            activate_mod_raws_changes()
elseif event == SC_WORLD_UNLOADED and mod_is_loaded() then
            deactivate_mod_raws_changes()
end
    end
else -- this branch is only for debugging.
    print(string.format('%s: manually invoking activate_mod_raws_changes()', script_name))
    activate_mod_raws_changes()
end

I've been thinking about the help text and the enable/disable capability.  I certainly understand why those are useful/necessary for standard scripts.  But I feel that, if you don't want the mod, don't install it into your world.

Actually, I don't even see the need for the scripts_modactive/internal subdirectory, except maybe for some absolutely massive total-conversion mod.  I think most people will just lump all their code into one script.

Quote
I have to say, this is a beautifully simple mod. Do you mind if I use it as an example in the modding guide?

You have my permission.

My intent was to write the simplest mod that actually did something useful.  (My intended use case is making green glass terrariums easier to haul around, but now I'm thinking that green glass trap components will be less effective.)



IMPORTANT EDIT:

If a world with your mod active is loaded a second time, the script will be reloaded as a module before the world loaded event and will have an opportunity to reattach the handler.

This bit is not true (dfhack 50.07-beta2).  I'm guessing you've implemented this but not yet had a release that contains it.  For now, I'm reverting to NOT unhooking the event handler and using mod_is_loaded().
Title: Re: DFHack 0.47.05-r8 | 50.07-beta2 (pre-release)
Post by: myk on April 13, 2023, 07:30:20 pm
I've been thinking about the help text and the enable/disable capability.  I certainly understand why those are useful/necessary for standard scripts.  But I feel that, if you don't want the mod, don't install it into your world.

Actually, I don't even see the need for the scripts_modactive/internal subdirectory, except maybe for some absolutely massive total-conversion mod.  I think most people will just lump all their code into one script.

Help text should always be included, since otherwise your script will show up as "No description" in ls and gui/launcher. But yes, for simple script-based mods, there is no need for an internal/ subdir or explicit enablement.

Quote
You have my permission.

Thank you!

Quote
IMPORTANT EDIT:

If a world with your mod active is loaded a second time, the script will be reloaded as a module before the world loaded event and will have an opportunity to reattach the handler.

This bit is not true (dfhack 50.07-beta2).  I'm guessing you've implemented this but not yet had a release that contains it.  For now, I'm reverting to NOT unhooking the event handler and using mod_is_loaded().

You are absolutely right. Sorry about that. There has been so much activity lately that I forgot which release that went out with. It's in the release I tagged today (50.07-r1) which is available on our GitHub page as usual. I was planning on announcing it tomorrow, concurrently with the debut of our Steam release (which is exactly the same as what's on GitHub), but people who read this can sneak the release early : )

https://github.com/DFHack/dfhack/releases/tag/50.07-r1
Title: Re: DFHack 50.07-r1
Post by: myk on April 14, 2023, 02:26:08 am
DFHack 50.07-r1 released!

Get it here: https://github.com/DFHack/dfhack/releases/tag/50.07-r1

Or install from Steam: https://store.steampowered.com/app/2346660/DFHack
Title: Re: DFHack 0.47.05-r8 | 50.07-beta2 (pre-release)
Post by: Heretic on April 21, 2023, 08:27:31 am
(https://cdn.discordapp.com/attachments/302956330304667649/1092653280577998890/announcement-showcase.png)

Code: ("ann.lua") [Select]
--proof of concept of an announcement menu.

local dlg=require("gui.dialogs")

local JUNK={}
local Dang=df.global.world.status.announcements

  for ultimate,checked_Ann in pairs(Dang) do
local mono=checked_Ann.text

      table.insert(JUNK,{mono,search_key = mono:lower()})
end
 
 dlg.showListPrompt("Announcement list","scroll through the list of Announced alerts",COLOR_WHITE,JUNK,nil,nil,nil,nil,true)

ok so out of boredom I decided to write up a script that grabs all the alerts/reports and shoves them into a list... there was a previous version of this script that grab every report but some folks don't want to sift through combat logs so I made this instead. there was an attempt at adding a filter on it but shrugs.

Amazing job!
Really wish to see full-functional annoncement menu.
Title: Re: DFHack 0.47.05-r8 | 50.07-beta2 (pre-release)
Post by: xzaxza on April 22, 2023, 04:47:40 am
In general, you can protect yourself from errors with pcall. For example:
Code: [Select]
local ok, ret = pcall(function()
    -- do something sketchy
end)

but in this case, you'd probably be best off with testing the type of the pointer before trying to access fields that only exist in some types.

Code: [Select]
local bld = thebuidlinginquestion
if bld:getType() == df.building_type.Workshop then
    -- access workshop fields
elseif bld::getType() == df.building_type.Stockpile then
    -- access stockpile fields
end
Yeah, I had a similar structure in the end. But thanks, pcall's been useful elsewhere.

Another sort of Lua question: if a value in game data is set to nil, how does one set it to something other than nil? I've given it a couple of tries, and an error message like this appears: Cannot write field: null and autovivify not requested.

I guess I could just create a new entry and copy the other fields and insert a non-null value there, and remove the old one, but is there a better way?
Title: Re: DFHack 50.07-r1
Post by: myk on April 22, 2023, 12:48:22 pm
That's exactly right -- you create a new entry and insert it into the appropriate place. Here's an example from build-now where it allocates a new construction and integrates it into the DF state:
Code: [Select]
local function create_and_link_construction(pos, item, top_of_wall)
    local construction = df.construction:new()
    utils.assign(construction.pos, pos)
    construction.item_type = item:getType()
    construction.item_subtype = item:getSubtype()
    construction.mat_type = item:getMaterial()
    construction.mat_index = item:getMaterialIndex()
    construction.flags.top_of_wall = top_of_wall
    construction.flags.no_build_item = not top_of_wall
    construction.original_tile = get_original_tiletype(pos)
    utils.insert_sorted(df.global.world.constructions, construction,
                        'pos', pos_cmp)
end

See the context here: https://github.com/DFHack/scripts/blob/master/build-now.lua#L349-L361
Title: Re: DFHack 0.47.05-r8 | 50.07-beta2 (pre-release)
Post by: lethosor on April 22, 2023, 07:31:56 pm
Myk's approach is one way of doing it. However, the error message you posted isn't one I see very often:
Cannot write field: null and autovivify not requested.

I guess I could just create a new entry and copy the other fields and insert a non-null value there, and remove the old one, but is there a better way?
Can you provide an example of the code you're using that triggers this error? There are a couple ways I could interpret your last statement, and I'm not sure which one you mean.

If you're assigning a table to a structure field, like this:
Code: [Select]
object.some_construction_field = {
  item_type = df.item_type.Foo,
  item_subtype = -1,
  -- more stuff
}
where "some_construction_field" is normally a pointer to an object, that is one case I know of that could cause the error you saw. In order for this to work, you can add a special "new=true" entry to the table, which indicates to our C++/Lua wrapper that a new object should be created based on the type of the field you're assigning the table to, like this:
Code: [Select]
object.some_construction_field = {
  new = true,
  item_type = df.item_type.Foo,
  item_subtype = -1,
  -- more stuff
}
This process is referred to as "auto-vivification" in our Lua API docs: https://docs.dfhack.org/en/stable/docs/dev/Lua%20API.html#recursive-table-assignment
Note that per (2)(b), you can also pass a type as the value under "new" to indicate the object's type, if the assignment target could have multiple types (e.g. if it's a pointer to an object of a class that has subclasses). For instance:
Code: [Select]
object.some_construction_field = {
  new = df.construction,
  item_type = df.item_type.Foo,
  item_subtype = -1,
  -- more stuff
}


In any case, this "new=" syntax is somewhat of a shorthand syntax provided for convenience. Myk's version is a more verbose equivalent.

It's also entirely possible that my guess about what you're trying to do was incorrect, so let me know if the code you're having trouble with is different.
Title: Re: DFHack 50.07-r1
Post by: xzaxza on April 23, 2023, 05:31:39 am
I was trying to get a manager workorder to use only rock nuts for paste-making to avoid running low on hemp seeds, so I tried to copy "job_item" of a workshop job I'd adjusted with `job item-material`, and add it to the the workorder's "items" element (which happens to be nil for that specific order). Dunno if it'd even work, but I saw that for many work orders, items is a vector with "job_item" elements in it, so I thought it'd be worth a shot.

That was also before I learned of gui/workorder-details, since I've been using DFHack version 0.47.05-r5.

Code: [Select]
local help = [====[
======================

]====]

utils = require('utils')
--debug.setmetatable(nil, {__index = function()end})
function findworkorder(workorder_id)
-- does something like this exist? df.global.world.manager_orders.find(workorder_id)
for _, mgr_order in ipairs(df.global.world.manager_orders) do
if mgr_order.id == workorder_id then
return mgr_order
end
end
qerror('not found')
end
function processworkorder(workorder_id)
--df.global.world.manager_orders
local workorder
local job
local mode = 1 -- for quickly switching between different approaches to the problem
local workorder_jobitems = {}

if pcall(findworkorder, workorder_id) then
workorder = findworkorder(workorder_id)
else
qerror('Work order not found')
end
job = dfhack.gui.getSelectedJob(true) or qerror('No job selected')

print("test")
if mode == 1 then
table.remove(workorder,'items')
workorder['items'] = workorder_jobitems
workorder.items = utils.clone(job.job_items, true)
else
--workorder.items = {}
workorder['items'] = workorder_jobitems
for _, copy_job_item in ipairs(job.job_items) do
--workorder.items:insert('#', copy_job_item)
table.insert(workorder.items, copy_job_item)
end
end
end


-- main script
local opt = ...
if opt and opt ~= "" then
if tonumber(opt) then
if tonumber(opt) >= 0 then
processworkorder(math.floor(tonumber(opt)))
else
print("The number should be non-negative.")
end
return
else
print(help)
end
else
print("No work order provided, here's a list of existing work orders:")
for _, mgr_order in ipairs(df.global.world.manager_orders) do
if mgr_order.reaction_name ~= nil and mgr_order.reaction_name ~= "" then
print(mgr_order.id .. ": " .. df.job_type[mgr_order.job_type] .. " (" .. mgr_order.reaction_name .. ")")
else
print(mgr_order.id .. ": " .. df.job_type[mgr_order.job_type])
end
end
end
Title: Re: DFHack 50.07-r1
Post by: myk on April 23, 2023, 05:58:58 pm
Are you essentially trying to get gui/workorder-details working for the Steam version? Or is this still for 0.47.05 and the existing gui/workorder-details meets your needs?
Title: Re: DFHack 50.07-r1
Post by: lethosor on April 23, 2023, 09:19:01 pm
Oh, so you're trying to create a vector<df::job_item*> in Lua. Unfortunately we don't have a way to create vectors containing arbitrary types from Lua. You might be able to come up with one by duplicating an existing work order that already has a non-null items vector. From a quick test, df.new(workorder) should make a shallow copy of the given work order (note that you will need to delete it to avoid leaking memory, e.g. with df.delete()).

Once you have a vector, you can call :insert() on it, with a table similar to what I was describing, e.g.
Code: [Select]
new_workorder.items:insert({
  new = true,
  field1 = value,
  -- ...
})

I also want to note that table.remove(workorder,'items') won't work. workorder (by my reading, anyway) is an instance of df.manager_order, and all instances of DF objects are actually userdata (https://www.lua.org/manual/5.3/manual.html#2.1), not tables. Essentially, they are wrappers around native C++ classes. Their fields are fixed, and you can't add or remove fields. You can set them, and since items is a pointer to a vector, you can set it to nil (Lua's equivalent of null) with workorder.items = nil (although this will leak memory).
Title: Re: DFHack 50.07-r1
Post by: xzaxza on April 24, 2023, 12:43:44 am
Are you essentially trying to get gui/workorder-details working for the Steam version? Or is this still for 0.47.05 and the existing gui/workorder-details meets your needs?
Nah, I'm in no hurry to try 0.50. I didn't get workorder-details to work with 0.47.05-r5, but it appears to work, and function as needed with r8. So, the problem I had with my Dwarf Fortress experience has been resolved (thanks!), it was more about me trying to learn why the approach I took with DFHack didn't work, and lethosor cleared that up. Thanks!
Title: Re: DFHack 50.07-r1
Post by: Salmeuk on April 24, 2023, 08:46:07 pm
https://github.com/DFHack/dfhack/issues/3256

Quote
our in-game Dwarf Therapist-like interface needs an entirely new UI. Existing functionality (and maybe design elements) might be salvageable from the old plugin.

Integrate with or replace work details?

I, for one, used the old Manipulator religiously and thought it was a perfect medium between Therapist and Vanilla (or Autolabor). The new work details are not very convenient to work with, and I miss most dearly these two features from Manipulator:

1. ability to sort a list of units showing each enabled skill for that unit
2. ability to copy-paste skill loadouts from unit to unit

despite what people claim, a spreadsheet is the ultimate tool for bureaucratic labor management. the compact and efficient style of the previous manipulator will be hard to beat, but even something merely copying that layout would be a wondrous improvement.
Title: Re: DFHack 50.07-r1
Post by: lethosor on April 24, 2023, 09:51:10 pm
Left a reply on Github: https://github.com/DFHack/dfhack/issues/3256#issuecomment-1521087200
(Not to discourage you from discussing this here, but it does help people looking at Github to have all the discussion in one place. Github accounts are free to create.)

I think the word "need" may have been too strong. Our new-style UI tools have diverged significantly, but as far as I know, there's no technical requirement that manipulator's UI be replaced in order to work in v50. The plugin does need to compile to be usable, though. It's currently commented out in our build files, which likely means that it didn't compile at one point during early work on v50 DFHack. I don't expect any of the UI code to cause compilation issues now, but some of the other code might.
Title: Re: DFHack 50.07-r1
Post by: 0x517A5D on April 26, 2023, 02:09:06 pm
Is there a way to probe a userdata object to see it it contains a particular field?

I was trying to iterate all buildings to study their .contained_items, but had the problem that some buildings (e.g. zones) don't have that field.

I get why accessing somezone.contained_items throws an error, but I expected somezone:_field('contained_items') to return nil.  Instead it also throws an error.

I resorted to enumerating pairs(somebuilding) to see if there is a key == 'contained_items' in the object.  This feels clumsy.

Thoughts?

Here's my actual code, a oneliner at the [lua#] prompt.
Code: [Select]
for _,b in ipairs(df.global.world.buildings.all) do for key,_ in pairs(b) do if key == 'contained_items' then for j,v in ipairs(b.contained_items) do i=v.item; f=i.flags; if v.use_mode == 0 and f.in_building and not f.trader then print(b._type,j,dfhack.items.getDescription(i,0)); end; end; end; end; end;
Title: Re: DFHack 50.07-r1
Post by: myk on April 26, 2023, 02:15:49 pm
If you're exploring a type, you're better off browsing using gui/gm-editor. FWIW, that script also uses pairs to iterate through a userdata object's fields: https://github.com/DFHack/scripts/blob/ad1998a0032ce50e90d05429a4178b668c0840ba/gui/gm-editor.lua#L567
Title: Re: DFHack 50.07-r1
Post by: 0x517A5D on April 26, 2023, 03:09:08 pm
I do make heavy use of gui/gm-editor, very nice tool.

But one of my test forts has 4000 buildings with 32000 total contained_items.  Manually probing that is... not practical.

Anyway.



Documenting this because it took me far too long to figure it out:

Items in a Trade Depot are ready to be traded (i.e. they have been selected by Move goods to/from depot) if they have item.flags.in_building == true.

Here's a one-liner that sets as tradeable all fort-produced items that are sitting in the Trade Depot.  It assumes you only have one Trade Depot.  Run it at the [lua]# prompt.

Code: [Select]
b=df.global.world.buildings.other.TRADE_DEPOT[0]; for j,v in ipairs(b.contained_items) do i=v.item; if v.use_mode == 0 and not i.flags.foreign and not i.flags.trader then i.flags.in_building = true; end; end;

Note that this code probably also should test other flags like .in_job, .owned, .dump, .melt, etc.  Use at your own risk.
Title: Re: DFHack 50.07-r1
Post by: lethosor on April 27, 2023, 11:12:46 pm
_field() is similar to the C++ & operator - the field you're referencing must exist.

Another option is to use pcall() to catch and ignore errors. A couple scripts do that for "safe" indexing of DF objects.
Title: Re: DFHack 50.07-r1
Post by: myk on May 02, 2023, 05:04:53 pm
DFHack 50.08-r1 released!

Get it here: https://github.com/DFHack/dfhack/releases/tag/50.08-r1

Or install from Steam: https://store.steampowered.com/app/2346660/DFHack
Title: Re: DFHack 50.08-r1
Post by: Criperum on May 08, 2023, 05:57:28 am
How can I make a DF shotcut that starts the game without DFHack?
Title: Re: DFHack 50.08-r1
Post by: lethosor on May 08, 2023, 10:03:59 am
How can I make a DF shotcut that starts the game without DFHack?
We don't support this currently for the Windows build of DF (i.e. the only one for v50). You could probably write a custom script that renames the necessary DLLs, although then you would need to write another script that renames them back if you want to run with DFHack. For 50.08-r1 and newer (again, on Windows) you would want to rename "dfhooks.dll" to something else to disable DFHack.
Title: Re: DFHack 50.08-r1
Post by: Criperum on May 08, 2023, 06:52:25 pm
Thank you
Title: Re: DFHack 50.08-r1
Post by: A_Curious_Cat on May 13, 2023, 03:23:40 pm
I’ve been thinking…

I’ve alway’s though that it’s be nice if the dwarves could move the embark wagon after they embark.  I know that this would require several new systems that are not in the game right now.

In the meantime, however, is there a DFHack command that will teleport the embark wagon (and it’s contents) to a chosen position on the map?  It’d make things a lot faster if my dwarves didn’t have to walk so long when transferring items from the wagon to the initial stockpile.
Title: Re: DFHack 50.08-r1
Post by: ldog on May 13, 2023, 03:44:58 pm
So I went ahead and upgraded my 47.05-r11 LNP installation to the last (R8) dfhack version and I get almost constant:
...05-r11\Dwarf Fortress 0.47.05/hack/scripts/unsuspend.lua:130: attempt to index a nil value (local 'bld')
stack traceback:
        ...05-r11\Dwarf Fortress 0.47.05/hack/scripts/unsuspend.lua:130: in method 'refresh_screen_buildings'
        ...05-r11\Dwarf Fortress 0.47.05/hack/scripts/unsuspend.lua:165: in method 'onRenderFrame'
        ...Pack 0.47.05-r11\Dwarf Fortress 0.47.05\hack\lua\gui.lua:524: in method 'render'
        ...-r11\Dwarf Fortress 0.47.05\hack\lua\plugins\overlay.lua:459: in local 'fn'
        ...-r11\Dwarf Fortress 0.47.05\hack\lua\plugins\overlay.lua:392: in upvalue 'detect_frame_change'
        ...-r11\Dwarf Fortress 0.47.05\hack\lua\plugins\overlay.lua:459: in function 'plugins.overlay.render_viewscreen_widgets'
Failed Lua call to 'plugins.overlay.render_viewscreen_widgets'

Doesn't seem tied to anything I am doing, although I really don't know what widgets I should even see or not see. The one from R7 that was kinda handy is gone. I looked at the mouse coordinates one briefly but decided it was kinda useless and turned it off. The rest I don't know what/where they are.

It also seems a bit unstable, particularly it is crashing on saving which is annoying AF, although it seems tied to the latest migrant wave.
Title: Re: DFHack 50.08-r1
Post by: myk on May 13, 2023, 05:45:18 pm
if the dwarves could move the embark wagon after they embark

I believe all the related state is known, so yes. I think moving buildings is within the realm of possibility. In fact, moving the wagon is already implemented for deep-embark. The logic would just need refactoring. Could you file a feature request at https://github.com/DFHack/dfhack/issues ?
Title: Re: DFHack 50.08-r1
Post by: myk on May 13, 2023, 06:03:21 pm
...05-r11\Dwarf Fortress 0.47.05/hack/scripts/unsuspend.lua:130: attempt to index a nil value (local 'bld')

I believe this bug was fixed in January. We're unlikely to do another release for DF-0.47.05, but you can manually apply the change to the unsuspend.lua in the hack/scripts directory. The code change is detailed here: https://github.com/DFHack/scripts/commit/49b8fde00a441c21b9e65fbab472f33f36823094

There were certainly a lot of overlay and UI changes at about that time. Which other features are you looking for but can't find? There should be nothing missing, just moved.
Title: Re: DFHack 50.08-r1
Post by: A_Curious_Cat on May 13, 2023, 06:13:13 pm
if the dwarves could move the embark wagon after they embark

I believe all the related state is known, so yes. I think moving buildings is within the realm of possibility. In fact, moving the wagon is already implemented for deep-embark. The logic would just need refactoring. Could you file a feature request at https://github.com/DFHack/dfhack/issues ?

How’s this (https://github.com/DFHack/dfhack/issues/3366)?
Title: Re: DFHack 50.08-r1
Post by: myk on May 13, 2023, 07:12:56 pm
Perfect. Thanks!
Title: Re: DFHack 50.08-r1
Post by: ldog on May 13, 2023, 09:12:03 pm
...05-r11\Dwarf Fortress 0.47.05/hack/scripts/unsuspend.lua:130: attempt to index a nil value (local 'bld')

I believe this bug was fixed in January. We're unlikely to do another release for DF-0.47.05, but you can manually apply the change to the unsuspend.lua in the hack/scripts directory. The code change is detailed here: https://github.com/DFHack/scripts/commit/49b8fde00a441c21b9e65fbab472f33f36823094

There were certainly a lot of overlay and UI changes at about that time. Which other features are you looking for but can't find? There should be nothing missing, just moved.

Ahh, you're a lifesaver.
I didn't have any particular reason to upgrade, just was checking the latest and greatest since I figure there will be no more LNP. I don't know what I'm supposed to be looking for, was just looking to see what's new. I did use the R7 one in the bottom left corner a little (that let you tab fill and run commands).

It doesn't look like the crashing is R8 related either, it is the same old bug I run into once in a while (usually when my fort gets going good and then it has to all go to shit). So I start incrementing through the season and saving regularly (really angry because I lost out on an artifact steel mail shirt!) and usually that gets me past whatever shenanigans is going on. It figures this would happen because my magma cart fill operation went flawlessly.
Title: Re: DFHack 50.08-r1
Post by: Rumrusher on May 13, 2023, 10:24:59 pm
I’ve been thinking…

I’ve alway’s though that it’s be nice if the dwarves could move the embark wagon after they embark.  I know that this would require several new systems that are not in the game right now.

In the meantime, however, is there a DFHack command that will teleport the embark wagon (and it’s contents) to a chosen position on the map?  It’d make things a lot faster if my dwarves didn’t have to walk so long when transferring items from the wagon to the initial stockpile.
(https://cdn.discordapp.com/attachments/302956330304667649/1107144843437801472/wagonmove-script-showcase.gif)
so like this?
currently working on a series of nomad focus scripts that converts the wagon as the main building for storing items and moving around the map as having it be stationary would lead to it being lost when I unload the map chunk that has it.


Code: ("wagonmove.lua") [Select]
function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end
function movewagon(curx,cury,curz)
for de,oe in pairs(df.global.world.buildings.other.WAGON) do
if oe.name == 'Nomad' then
oe.centerx=curx
oe.x1=curx-1
oe.x2=curx+1
oe.centery=cury
oe.y1=cury-1
oe.y2=cury+1
oe.z=curz
end
end
end

movewagon(getxyz())
this script requires you to name the wagon Nomad and use the keyboard cursor for it to work
Title: Re: DFHack 50.08-r1
Post by: ldog on May 13, 2023, 10:28:08 pm
So I have isolated my crash to editing a...piglet...with gui/gm-editor.

My SOP for pets is NO FUCKING LIVESTOCK AS PETS, EVER. You can have a dog. I even allow cats. Exotic killing machine type pets? Absolutely! A keet? Don't even fucking think about it. A cavy? I will dump you and your cavy into magma.

So normally I go in and remove the important historical figure flags from 1 & 2 and then clear the pet relationship. Then autobutcher takes over. However since I actually do keep pigs and it is a piglet and I am under my cap it's hanging out. This one I cleared it's name too, but with or w/o changing the name it crashes. So when I go and try to save the game doesn't like that for some reason.

By the way if someone could make a script to "unpet" that would be great.

Hey that's pretty cool Rumrusher! Does it work with 47 or only the new version?
Title: Re: DFHack 50.08-r1
Post by: A_Curious_Cat on May 13, 2023, 11:57:04 pm
I’ve been thinking…

I’ve alway’s though that it’s be nice if the dwarves could move the embark wagon after they embark.  I know that this would require several new systems that are not in the game right now.

In the meantime, however, is there a DFHack command that will teleport the embark wagon (and it’s contents) to a chosen position on the map?  It’d make things a lot faster if my dwarves didn’t have to walk so long when transferring items from the wagon to the initial stockpile.
(https://cdn.discordapp.com/attachments/302956330304667649/1107144843437801472/wagonmove-script-showcase.gif)
so like this?
currently working on a series of nomad focus scripts that converts the wagon as the main building for storing items and moving around the map as having it be stationary would lead to it being lost when I unload the map chunk that has it.


Code: ("wagonmove.lua") [Select]
function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end
function movewagon(curx,cury,curz)
for de,oe in pairs(df.global.world.buildings.other.WAGON) do
if oe.name == 'Nomad' then
oe.centerx=curx
oe.x1=curx-1
oe.x2=curx+1
oe.centery=cury
oe.y1=cury-1
oe.y2=cury+1
oe.z=curz
end
end
end

movewagon(getxyz())
this script requires you to name the wagon Nomad and use the keyboard cursor for it to work

Does it move the wagon’s contents along with the wagon?  I mainly want it so that I can move the wagon to just outside my initial stockpile to reduce hauling time.  Keep in mind, also, that I currently don’t have a working DF installation.  I’m waiting for the Linux version to become stable enough for an official release before I try it, and I can’t use the old one because my distribution doesn’t support pre-SDL2 libraries.
Title: Re: DFHack 50.08-r1
Post by: Rumrusher on May 14, 2023, 05:30:20 am
so far in my nomad runs the contents in the wagon stayed when loading and unloading chunks of the map.
though if you unretire the most of the contents would be out of the wagon so moving it would just be moving the main standing idle location.
Title: Re: DFHack 50.08-r1
Post by: ldog on May 14, 2023, 08:35:32 am
Still trying to isolate this crash. It is interesting that it is just THIS piglet.
The latest migrant wave had 2 keets and some other bs and I butchered them all and saved the game without incident.
Stepping through this with the gm-editor, it is the important historical figure for some reason, I guess there was actually an event with the pig?
Removing the relationship was fine, so was removing the name. The historical figure flags set to false and it crashes on save. I guess I'll just butcher it and move on.
Title: Re: DFHack 50.08-r1
Post by: A_Curious_Cat on May 14, 2023, 10:04:55 am
so far in my nomad runs the contents in the wagon stayed when loading and unloading chunks of the map.
though if you unretire the most of the contents would be out of the wagon so moving it would just be moving the main standing idle location.

Is there any way to make it so that you don’t need to name the wagon?
Title: Re: DFHack 50.08-r1
Post by: Rumrusher on May 15, 2023, 07:18:20 am
so far in my nomad runs the contents in the wagon stayed when loading and unloading chunks of the map.
though if you unretire the most of the contents would be out of the wagon so moving it would just be moving the main standing idle location.

Is there any way to make it so that you don’t need to name the wagon?
usually I have it like that as a sanity check for the code to not scoop up any other wagons if I move to a location that has one.
You could take out the' if wagon building name is nomad' line of code so one could just grab the wagon on site.
like so:

Code: ("movewagon2.lua") [Select]
function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end
function movewagon(curx,cury,curz)
for de,oe in pairs(df.global.world.buildings.other.WAGON) do
oe.centerx=curx
oe.x1=curx-1
oe.x2=curx+1
oe.centery=cury
oe.y1=cury-1
oe.y2=cury+1
oe.z=curz
end
end


movewagon(getxyz())
Title: Re: DFHack 50.08-r1
Post by: Bumber on May 19, 2023, 02:07:03 pm
Don't you need to update the building occupancy on tiles, or something?

Also, I think you can do something like "copyall(df.global.cursor)" instead of using a custom function. (Might be "pos2xyz" otherwise.)
Title: Re: DFHack 50.08-r1
Post by: A_Curious_Cat on May 19, 2023, 06:59:02 pm
Don't you need to update the building occupancy on tiles, or something?

Also, I think you can do something like "copyall(df.global.cursor)" instead of using a custom function. (Might be "pos2xyz" otherwise.)

“Building occupancy”?

Also, I just checked the DFHack Lua API docs and it appears that pos2xyz(df.global.cursor) should replace the getxyz() custom function (assuming there isn’t an easier way using copyall()…).

Anyways, I don’t really know anything about Lua (I’m currently too busy trying to learn C++)…
Title: Re: DFHack 50.08-r1
Post by: 0x517A5D on May 23, 2023, 02:59:41 pm
Does anyone know much about pets and war animals?  I'm looking at the ties between pets and owners, with the aim of automating assignment of war animals to soldiers.  I've found:

I cannot find links from an owner to their pets/assigned animals.  Not in the owning unit or their historical_figure.

I can replicate all of this except the pet unit's name.  Is there a known way to get DF to generate a random unit name?

I suspect that the historical_figure is needed to allow the unit to leave the map and come back e.g. following a soldier on a raid.  Manually creating a new historical figure looks possible but hard.

historical_figures without names exist, so that's not an error state.

If I manually create a nemesis_record, how would I set the .save_file_id (unit_chunk) field?  Just assign it from df.global.unit_chunk_next_id and increment that?

And similar for a new historical_figure?  Append it to world.history.figures[], increment df.global.hist_figure_next_id?

And similar for a nemesis record.  Append it to world.nemesis.all and world.nemesis.bad, increment df.global.nemesis_next_id?

I guess I'm asking too many obscure questions.  I'll experiment.


Thinking about it, is there a way to parse the gui and manually call the routine that would be called when a button is clicked?  That might be an easier route.
Title: Re: DFHack 50.08-r1
Post by: Bumber on May 25, 2023, 01:36:26 pm
“Building occupancy”?

https://github.com/DFHack/df-structures/blob/29801b0043b884d04a7e63a995258ebf2b67cbaf/df.map.xml#L114
Title: Re: DFHack 50.08-r1
Post by: Rumrusher on May 25, 2023, 02:55:05 pm
Nomad Script or hey this loads map chunks like how adv mode does it script for traveling the world... in fort mode.

(https://cdn.discordapp.com/attachments/302956330304667649/1111374985282461756/nomad-script-attempted-to-show-case.gif)
old recording of the script as I realize the script probably doesn't need FTgo's surface and cavern fast travel adv mode functions
(https://cdn.discordapp.com/attachments/302956330304667649/1107141877758701638/nomad-fort-showcase-gif2.gif)
and here's the end result ... from a different fort as this process takes a bit too long to fully capture.
Code: ("nomad.lua") [Select]
--script using warmist spellbook code to make a cheap gui for expanding and contracting a player fort.
-- this script is pretty dangerous in that it reveals the expanded map chunk, and when contracting it culls anyone in that map chunk.
-- so far probably best to use this with the void fort scripts as it allows one to expand and explore the world while keeping your site.
--oh warning if you're about to collapse a map chunk make sure to clear any stockpiles and civ zones you made in that map chunk.
--oh and don't retire unless you're back to the original fort embark size or the game will corrupt that fort and or crash.
--also it will take a while for any results to happen. I have no idea on speeding up the process.
--if you use this for some nomad playstyle best learn how to haul goods across map and burrowing folks.
--as you might lose folks while traveling.
 
local dlg=require("gui.dialogs")

function GoN()
local Site=df.global.plotinfo.main.fortress_site
local Nor=Site.global_min_y-1
Site.global_min_y=Nor
end

function NoN()
local Site=df.global.plotinfo.main.fortress_site
local Nor=Site.global_min_y+1
Site.global_min_y=Nor
end
function GoS()
local Site=df.global.plotinfo.main.fortress_site
local Sor=Site.global_max_y+1
Site.global_max_y=Sor
end
function NoS()
local Site=df.global.plotinfo.main.fortress_site
local Sor=Site.global_max_y-1
Site.global_max_y=Sor
end
function GoE()
local Site=df.global.plotinfo.main.fortress_site
local Eor=Site.global_max_x+1
Site.global_max_x=Eor
end
function NoE()
local Site=df.global.plotinfo.main.fortress_site
local Eor=Site.global_max_x-1
Site.global_max_x=Eor
end
function GoW()
local Site=df.global.plotinfo.main.fortress_site
local Wor=Site.global_min_x-1
Site.global_min_x=Wor
end
function NoW()
local Site=df.global.plotinfo.main.fortress_site
local Wor=Site.global_min_x+1
Site.global_min_x=Wor
end

function Go()
for k,v in pairs(df.global.world.armies.all) do
if v.flags[0]== true  then
local Nor=v.pos.y-1
v.pos.y=Nor
end
end
end
function doNothing()
print("doing nothing real good but here have a site")
--require("plugins.dfusion.adv_tools").addSite(nil,nil,nil,nil,nil,nil,df.global.world.units.active[0].civ_id)
end
function doNothing2()
dlg.showMessage("Travel-Hack","Bypassing Message to access FastTravel")
df.global.ui_advmode.message=""
--require("plugins.dfusion.adv_tools").addSite(nil,nil,nil,nil,nil,nil,df.global.world.units.active[0].civ_id)
end

function greetAndStuff()
dlg.showMessage("Greetings", "Seasons greatings and lols")
end
MOVEMENT_KEYS = {
    A_CARE_MOVE_N = { 0, -1, 0 }, A_CARE_MOVE_S = { 0, 1, 0 },
    A_CARE_MOVE_W = { -1, 0, 0 }, A_CARE_MOVE_E = { 1, 0, 0 },
    A_CARE_MOVE_NW = { -1, -1, 0 }, A_CARE_MOVE_NE = { 1, -1, 0 },
    A_CARE_MOVE_SW = { -1, 1, 0 }, A_CARE_MOVE_SE = { 1, 1, 0 },
    --[[A_MOVE_N = { 0, -1, 0 }, A_MOVE_S = { 0, 1, 0 },
    A_MOVE_W = { -1, 0, 0 }, A_MOVE_E = { 1, 0, 0 },
    A_MOVE_NW = { -1, -1, 0 }, A_MOVE_NE = { 1, -1, 0 },
    A_MOVE_SW = { -1, 1, 0 }, A_MOVE_SE = { 1, 1, 0 },--]]
    A_CUSTOM_CTRL_D = { 0, 0, -1 },
    A_CUSTOM_CTRL_E = { 0, 0, 1 },
    CURSOR_UP_Z_AUX = { 0, 0, 1 }, CURSOR_DOWN_Z_AUX = { 0, 0, -1 },
    A_MOVE_SAME_SQUARE={0,0,0},
    SELECT={0,0,0},
}
ALLOWED_KEYS={
    A_MOVE_N=true,A_MOVE_S=true,A_MOVE_W=true,A_MOVE_E=true,A_MOVE_NW=true,
    A_MOVE_NE=true,A_MOVE_SW=true,A_MOVE_SE=true,A_STANCE=true,SELECT=true,A_MOVE_DOWN_AUX=true,
    A_MOVE_UP_AUX=true,A_LOOK=true,CURSOR_DOWN=true,CURSOR_UP=true,CURSOR_LEFT=true,CURSOR_RIGHT=true,
    CURSOR_UPLEFT=true,CURSOR_UPRIGHT=true,CURSOR_DOWNLEFT=true,CURSOR_DOWNRIGHT=true,A_CLEAR_ANNOUNCEMENTS=true,
    CURSOR_UP_Z=true,CURSOR_DOWN_Z=true,
}

listofspells={
{text="nothing", spell=doNothing,icon='*'},
{text="expand: North+", spell=GoN,key="CUSTOM_W"},
{text="expand: South+", spell=GoS,key="CUSTOM_S"},
{text="expand: East+", spell=GoE,key="CUSTOM_D"},
{text="expand: West+", spell=GoW,key="CUSTOM_A"},
{text="Contract: North-", spell=NoN,key="CUSTOM_W"},
{text="Contract: South-", spell=NoS,key="CUSTOM_S"},
{text="Contract: East-", spell=NoE,key="CUSTOM_D"},
{text="Contract: West-", spell=NoW,key="CUSTOM_A"},
}
 
dlg.showListPrompt("Directions","Choze Direct",nil, listofspells,function(index,choice) choice.spell() end)

so here's the nomad script for the dfhack required nomad playstyle and probably adding another way to play with void forts as this cuts down embarking twice and allows void forts to interact with larger pre-generated sites like towns and forest retreats although you're probably be a bit lost figuring out where the structures would be or where everyone is currently at.
big warning the game might reveal chunks of the map and one might require to deal with the DF50's new special map feature pop ups.
I been using this lua command for most part to clear them as depending on how big you expand the fort you might end up with like 50 to 300+ of these warnings.
Code: [Select]
:lua df.global.world.status.popups:resize(0) hmm I guess one could write a lua script that turns off the announcement pop up for that so you can ignore them
oh yeah one probably want to use revflood if they want to hide the expanded map chunks


now I normally just use gm-editor to do this via going into
Code: [Select]
gui/gm-editor df.global.plotinfo.main.fortress_site then messing with the global min/max x and y coords

another big warning with using this is you can store drinks and items offsite and they won't spill over if you unload the map chunk containing them and retire... then unretire the fort.
you do need to expand into the location you store the drinks or you will end up forcing your fort to go with out drinks until the game finally expand into the drink storage.
oh and you could unload the entire fort and send everyone into the void which will cause the game to consider that a "fort end" so probably best remember to kill the process if that ever happens to revert back to a previous save.
well anyway this is pretty fun if you want to explore the world you generated and possibly harvest said world for resources and units and gear and crafts to build a large empire.

it's also possible to say with returning to the right embark size with retiring, one could take over other spots in the world map and with void fort move around the world map with the map chunk you stole.
so if you like the hills in a hilltop you could swipe that and build your fort there, or you had plans on an ocean fort this could help, wanna do an Oregon trail like fort session where you stop at some destination? would take some getting use to constantly moving and you might need to figure out how to keep your tools and gear with you but yeah that's possible.

oh yeah another big warning probably backup your saves before and after using this, and I don't know if this let you do raids?
Title: Re: DFHack 50.08-r1
Post by: A_Curious_Cat on May 25, 2023, 03:34:44 pm
“Building occupancy”?

https://github.com/DFHack/df-structures/blob/29801b0043b884d04a7e63a995258ebf2b67cbaf/df.map.xml#L114

Ok.  I think I understand everything except why it’s called “occupancy”…
Title: Re: DFHack 50.08-r1
Post by: myk on May 25, 2023, 06:45:08 pm
It marks how the tile is "occupied", e.g. is it part of the footprint of the building? is it passable by units or are units blocked from moving through that tile? etc.
Title: Re: DFHack 50.08-r1
Post by: xzaxza on May 28, 2023, 01:35:12 am
Uh, I recently started using autodump for a bunch of feeder stockpiles surrounding a quantum stockpile... and the problem I have is that occasionally the wheelbarrow assigned to the stockpile gets dumped. Dunno why, but I guess it could be because a hauling job involving the wheelbarrow was interrupted and the wheelbarrow had to be hauled back.

Perhaps there should be a check if the item is assigned to the stockpile. I see the stockpile interface section is commented out in the repository currently, so maybe the stockpiles plugin will handle it, or maybe it does already, dunno.
Title: Re: DFHack 50.08-r1
Post by: myk on May 28, 2023, 09:14:51 pm
checking for stockpile assignment is a good idea, if the flags check doesn't already mask those wheelbarrows out. This might be an issue for the upcoming gui/autodump as well. Could you file an issue on Github? https://github.com/DFHack/dfhack/issues

Btw, the commented out code you were looking at is for an unrelated "autodump" function that marks items brought to a stockpile for dumping. The code is being migrated to a new "logistics" plugin. That code does, as you said, check for stockpile assignment before marking the item.
Title: Re: DFHack 50.08-r1
Post by: xzaxza on May 28, 2023, 10:26:49 pm
It's actually the stockpile functionality that is in question. But yeah, ok.
Title: Re: DFHack 50.08-r1
Post by: A_Curious_Cat on May 29, 2023, 01:56:13 am
I though garbage dumps and stockpiles were two separate things, and dumping (including autodumping) moved things to the closest garbage dump regardless of where those items were.  Isn’t this just regular behavior?
Title: Re: DFHack 50.08-r1
Post by: myk on May 29, 2023, 03:26:00 am
normally, dwarves will bring items marked for dumping to the garbage dump zone, but autodump actually doesn't teleport items to the garbage dump zone. it teleports them to the cursor.

the confusion here is that the autodump plugin has historically been two very separate tools. There's the item teleportation code that teleports items marked for dumping to the cursor, and then there's the stockpile monitor that lets you register stockpiles for "autodump". Items brought to that stockpile will be marked for dumping, then dwarves will move those items to the garbage dump.

@xzaxza, so to clarify, you're saying that the stockpile autodump feature (presumably in 0.47.05 since that feature is still in an open PR for v50) is sometimes marking wheelbarrows that are ostensibly owned by the stockpile? Yeah, I'm not sure what's going on there. A github issue would be appreciated so I can remember to look into it when I finish https://github.com/DFHack/dfhack/pull/3285
Title: Re: DFHack 50.08-r1
Post by: feelotraveller on May 29, 2023, 04:49:15 am
Uh, I recently started using autodump for a bunch of feeder stockpiles surrounding a quantum stockpile... and the problem I have is that occasionally the wheelbarrow assigned to the stockpile gets dumped. Dunno why, but I guess it could be because a hauling job involving the wheelbarrow was interrupted and the wheelbarrow had to be hauled back.

I don't think that autodump is responsible here.  At least this happens in the base game without autodump (or even dfhack).  All evidence I've seen points to job interruption causing the behaviour, as you suspect.  Unfortunately once it starts the wheelbarrow often gets stuck in a cycle of being dumped into the quantum stockpile and then returned to the feeder stockpile endlessly.  (The way to break the cycle is to temporarily forbid the wheelbarrow so that it's stockpile assignement gets reset.) 

Although I guess it's possible that autodump could be triggering whatever in the base game causes the problem?
Title: Re: DFHack 50.08-r1
Post by: xzaxza on May 29, 2023, 06:55:37 am
@xzaxza, so to clarify, you're saying that the stockpile autodump feature (presumably in 0.47.05 since that feature is still in an open PR for v50) is sometimes marking wheelbarrows that are ostensibly owned by the stockpile? Yeah, I'm not sure what's going on there. A github issue would be appreciated so I can remember to look into it when I finish https://github.com/DFHack/dfhack/pull/3285
Yes, I'm talking about the stockpile integration functionality of autodump, not the magical item mover/destroyer part. I made one: https://github.com/DFHack/dfhack/issues/3430

Uh, I recently started using autodump for a bunch of feeder stockpiles surrounding a quantum stockpile... and the problem I have is that occasionally the wheelbarrow assigned to the stockpile gets dumped. Dunno why, but I guess it could be because a hauling job involving the wheelbarrow was interrupted and the wheelbarrow had to be hauled back.

I don't think that autodump is responsible here.  At least this happens in the base game without autodump (or even dfhack).  All evidence I've seen points to job interruption causing the behaviour, as you suspect.  Unfortunately once it starts the wheelbarrow often gets stuck in a cycle of being dumped into the quantum stockpile and then returned to the feeder stockpile endlessly.  (The way to break the cycle is to temporarily forbid the wheelbarrow so that it's stockpile assignement gets reset.) 

Although I guess it's possible that autodump could be triggering whatever in the base game causes the problem?
Hmm, I didn't notice it before I enabled autodump. I'm 27 years and 6000+ stones in, and all that time before enabling autodump I dumped all the stones manually, and I didn't really see wheelbarrows marked for dumping and/or them ending up forbidden in quantum stockpiles. Of course it's always possible the root cause is something else, but it looks like autodump to me.
Title: Re: DFHack 50.08-r1
Post by: xzaxza on May 29, 2023, 07:02:22 am
I though garbage dumps and stockpiles were two separate things, and dumping (including autodumping) moved things to the closest garbage dump regardless of where those items were.  Isn’t this just regular behavior?
Yeah, they're two separate thinks, but I have a following setup:

Code: [Select]
F F F
F Q F
F F F
Where the F's are a stone stockpile, in this case set to receive only one of the main layer stones on the map, and Q is a 1x1 stockpile and also a dump zone. So, the process is essentially this:

1. dwarves haul stones to the feeder stockpile (F)
2. the stones in F are marked for dumping
3. lots of forbidden stones in Q

The end goal is that eventually, there are no cluttered stones all over fortress. There is the additional plus that if you reclaim the stones in Q and build a mason/stonecrafter next to it, then you have easy access to just one type of stone, which can be neat and handy.
Title: Re: DFHack 50.08-r1
Post by: myk on June 01, 2023, 03:54:46 pm
DFHack 50.08-r2 released!

Get it here: https://github.com/DFHack/dfhack/releases/tag/50.08-r2

Or install from Steam: https://store.steampowered.com/app/2346660/DFHack
Title: Re: DFHack 50.08-r2
Post by: xzaxza on June 05, 2023, 12:35:22 pm
So, a while back I posted in this issue: https://github.com/DFHack/dfhack/issues/1784

In short, emigration.lua worked in past, but no longer works. I fixed it (https://github.com/wsfsbvchr/dfhack-utils/blob/main/emigration-fix.lua). Do you want it?

In the issue people didn't seem to believe that it's broken, but I also made a test script (https://github.com/wsfsbvchr/dfhack-utils/blob/main/stress-tests.lua) that can be used with a more debug-friendly version (https://github.com/wsfsbvchr/dfhack-utils/blob/main/emigration-debug.lua).

I found that my solution works with merchants and without merchants, but leaving with diplomats didn't seem to work work + there was an announcement about a diplomat leaving unhappy, so I commented that part out. Another pitfall is that it's tested only on 0.47.05, so dunno if stuff's changed since. My solution also attempts to find a new group for the emigrants to join, and a new site, and it has your own civilization as fallback. I only tried it with merchants from own civ, though. I also am not exactly sure if the units travel to their new homes after they leave the embark, or what happens to them.

The script could also use some optimizing, but I didn't do a complete rewrite. Also, I don't know if the algorithm could use some tuning. I mean, 250k stress is when there's 50% chance for a dwarf to join merchants of your own civilization, and at that point they're already going insane. Maybe the chance should rise faster, since it runs only once per month. At 50k stress it's still at about 90% chance to stay, despite it causing mental breakdowns. But maybe the fact that it runs monthly compensates for the percentages. Sometimes even a slightly stressed dwarf leaves if the roll is a 100.

I also implemented the solution in a script that allows choosing a dwarf for emigration, because I wanted a world where my dwarves make a gazillion babies and then send them to the world at adulthood.
Title: Re: DFHack 50.08-r2
Post by: Rumrusher on June 05, 2023, 01:59:05 pm
ok so finished a big test on nomad and cut down on most of the crashes.

(https://cdn.discordapp.com/attachments/302956330304667649/1115351769527091250/cross-the-ocean2.gif)
mostly found what usually make the game crash and plan to avoid it.
like I mostly think new civ zones might need to be cleared before leaving and also stockpiles but shrugs if that was tied to a different thing that align with me doing those two things.
edit: oh yeah you do need to rename the wagon to "Nomad" for these scripts to work to stop potential accidents from nomading onto other player forts that kept their wagon
Code: ("wagonmove3.lua") [Select]
function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end
function movewagon(curx,cury,curz)
for de,oe in pairs(df.global.world.buildings.other.WAGON) do
if oe.name == 'Nomad' then
oe.centerx=curx
oe.x1=curx-1
oe.x2=curx+1
oe.centery=cury
oe.y1=cury-1
oe.y2=cury+1
oe.z=curz

for Del,ete in pairs(oe.contained_items) do
ete.item.pos.x=oe.centerx
ete.item.pos.y=oe.centery
ete.item.pos.z=oe.z
end
end
end
end

movewagon(getxyz())
this script requires the mining cursor to function and this new version of the wagon move will now update the positions of the items store on the wagon.
which I guess opens the research path on figuring out what causes the contents of items to spill out on unretire.

another script that's still currently in the works is this one Wagon store which copies and stores the contents of workshops(and now furnaces ) on to the wagon then attempts to remove said contents from the workshop and furnace.
this would take a few multiple attempts at emptying out the workshops and furnaces and I'm not sure this is perfectly save as it's mostly stable, if you craft way too much stuff it will take awhile to load it all onto the wagon and might look like a soft lock.
Code: ("wagon-store2.lua") [Select]
local contain={}
function stuffwagon(curx,cury,curz)
for k,v in pairs(df.global.world.buildings.other.WORKSHOP_ANY) do
for con,tain in pairs(v.contained_items) do
for de,oe in pairs(df.global.world.buildings.other.WAGON) do
if oe.name == 'Nomad' then
if tain.use_mode==0 then
oe.contained_items:insert("#",{new=true,item=v.contained_items[con].item,use_mode=0})
clearitems(oe,tain,v.contained_items)
end
end
end
end
end
for k,v in pairs(df.global.world.buildings.other.FURNACE_ANY) do
for con,tain in pairs(v.contained_items) do
for de,oe in pairs(df.global.world.buildings.other.WAGON) do
if oe.name == 'Nomad' then
if tain.use_mode==0 then
oe.contained_items:insert("#",{new=true,item=v.contained_items[con].item,use_mode=0})
clearitems(oe,tain,v.contained_items)
end
end
end
end
end

end
function clearitems(oe,tain,Vcon)
for Del,ete in pairs(oe.contained_items) do
for De2,ee in pairs(Vcon) do
if ete.item.id== ee.item.id then
Vcon:erase(De2)
end
end
end
end


stuffwagon()

Code: ("wagon-store-C.lua") [Select]
--this script uses old dfhack code to store items on to the wagon via keyboard cursors.
--probably more stable than the other scripts that store items onto the wagon but requires it to be on the floor.
local contain={}
 function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end

function stuffwagon(curx,cury,curz)

for de,oe in pairs(df.global.world.buildings.other.WAGON) do
if oe.name == 'Nomad' then


local vector=df.global.world.items.all -- load all items
for i = 0, #vector-1 do -- look into all items offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==curx and cy==cury and cz==curz then --compare them
dfhack.items.moveToBuilding(vector[i],oe) --return index
end
end

end
end
end

stuffwagon(getxyz())

the test I done was seeing if I could cross the ocean to settle on an remote island and uhh going through the caverns in DF50 is adventurous one could say as you're at the mercy of the agitation system and if you say stay too long and or dig up too much stuff down in the cavern layer you might get swarmed by the other residents of the area and possibly make the trip harder.

edit: realize I already made a wagonmove2 so updated lua file name for consistency.

edit: ok so uhh made a cursor version of the wagon store script so now one could scoop up random items on the field to store back on the wagon. it probably more stable than the previous ones given it uses dfhack for the item placement but user be ware.
edit: it's also a modification of the wagon un-retire script after realizing moving the wagon over an item to scoop the item into itself was a bit silly to do.
Title: Re: DFHack 50.08-r2
Post by: myk on June 05, 2023, 03:21:45 pm
In short, emigration.lua worked in past, but no longer works. I fixed it (https://github.com/wsfsbvchr/dfhack-utils/blob/main/emigration-fix.lua). Do you want it?

Please! Could you open a PR against the scripts repo? https://github.com/DFHack/scripts/pulls
We can discuss it over the code review.
Title: Re: DFHack 50.08-r2
Post by: myk on June 05, 2023, 09:04:17 pm
DFHack 50.08-r3 released!

Get it here: https://github.com/DFHack/dfhack/releases/tag/50.08-r3

Or install from Steam: https://store.steampowered.com/app/2346660/DFHack
Title: Re: DFHack 50.08-r3
Post by: Rumrusher on June 07, 2023, 01:16:36 am
Code: ("AnimalTokenCivPatch6.lua") [Select]
--old old script made to update the hist_fig_less migrants and second citizens gain from messing with animal entity tokens
--this script uses code from dfhack's spawn unit code mostly the histfig data stuff and I guess the nemesis record stuff looking at it now.
-- this is a run to patch citizens script and not automated
-- uhh stability warning on what it does to histfigs and any future issues that comes from it down the line.



ui=df.global.plotinfo

local function allocateNewChunk(hist_entity)
  hist_entity.save_file_id = df.global.unit_chunk_next_id
  df.global.unit_chunk_next_id = df.global.unit_chunk_next_id+1
  hist_entity.next_member_idx = 0
  print("allocating chunk:",hist_entity.save_file_id)
end

local function allocateIds(nemesis_record,hist_entity)
  if hist_entity.next_member_idx == 100 then
    allocateNewChunk(hist_entity)
  end
  nemesis_record.save_file_id = hist_entity.save_file_id
  nemesis_record.member_idx = hist_entity.next_member_idx
  hist_entity.next_member_idx = hist_entity.next_member_idx+1
end

function createFigure(unit,he,he_group)
  local hf = df.historical_figure:new()
  hf.id = df.global.hist_figure_next_id
  df.global.hist_figure_next_id = df.global.hist_figure_next_id+1

  hf.unit_id = unit.id
  hf.nemesis_id = -1
  hf.race = unit.race
  hf.caste = unit.caste
  hf.profession = unit.profession
  hf.sex = unit.sex
  hf.name:assign(unit.name)

  hf.appeared_year = df.global.cur_year
  hf.born_year = unit.birth_year
  hf.born_seconds = unit.birth_time
  hf.curse_year = unit.curse_year
  hf.curse_seconds = unit.curse_time
  hf.birth_year_bias = unit.birth_year_bias
  hf.birth_time_bias = unit.birth_time_bias
  hf.old_year = unit.old_year
  hf.old_seconds = unit.old_time
  hf.died_year = -1
  hf.died_seconds = -1

  hf.civ_id = unit.civ_id
  hf.population_id = unit.population_id
  hf.breed_id = -1
  hf.cultural_identity = unit.cultural_identity
  hf.family_head_id = -1

  df.global.world.history.figures:insert("#", hf)

  hf.info = df.historical_figure_info:new()
  hf.info.whereabouts = df.historical_figure_info.T_whereabouts:new()
  hf.info.whereabouts.death_condition_parameter_1 = -1
  hf.info.whereabouts.death_condition_parameter_2 = -1
  -- set values that seem related to state and do event
  --change_state(hf, dfg.plotinfo.site_id, region_pos)


  --let's skip skills for now
  --local skills = df.historical_figure_info.T_skills:new() -- skills snap shot
  -- ...
  -- note that innate skills are automaticaly set by DF
  hf.info.skills = {new=true}

  if he then
    he.histfig_ids:insert('#', hf.id)
    he.hist_figures:insert('#', hf)
    hf.entity_links:insert("#",{new=df.histfig_entity_link_memberst,entity_id=unit.civ_id,link_strength=100})

    --add entity event
    local hf_event_id = df.global.hist_event_next_id
    df.global.hist_event_next_id = df.global.hist_event_next_id+1
    df.global.world.history.events:insert("#",{new=df.history_event_add_hf_entity_linkst,year=unit.birth_year,
    seconds=unit.birth_time,id=hf_event_id,civ=hf.civ_id,histfig=hf.id,link_type=0})
  end

  if he_group and he_group ~= he then
    he_group.histfig_ids:insert('#', hf.id)
    he_group.hist_figures:insert('#', hf)
    hf.entity_links:insert("#",{new=df.histfig_entity_link_memberst,entity_id=he_group.id,link_strength=100})
  end

  local soul = unit.status.current_soul
  if soul then
    hf.orientation_flags:assign(soul.orientation_flags)
  end

  unit.flags1.important_historical_figure = true
  unit.flags2.important_historical_figure = true
  unit.hist_figure_id = hf.id
  unit.hist_figure_id2 = hf.id

  return hf
end

function createNemesis(unit,civ_id,group_id)
  local id = df.global.nemesis_next_id
  local nem = df.nemesis_record:new()

  nem.id = id
  nem.unit_id = unit.id
  nem.unit = unit
  nem.flags:resize(31)
  nem.unk10 = -1
  nem.unk11 = -1
  nem.unk12 = -1
  df.global.world.nemesis.all:insert("#",nem)
  df.global.nemesis_next_id = id+1
  unit.general_refs:insert("#",{new = df.general_ref_is_nemesisst, nemesis_id = id})

  nem.save_file_id = -1

  local he
  if civ_id and civ_id ~= -1 then
    he = df.historical_entity.find(civ_id)
    he.nemesis_ids:insert("#",id)
    he.nemesis:insert("#",nem)
    allocateIds(nem,he)
  end
  local he_group
  if group_id and group_id ~= -1 then
    he_group = df.historical_entity.find(group_id)
  end
  if he_group then
    he_group.nemesis_ids:insert("#",id)
    he_group.nemesis:insert("#",nem)
  end
  nem.figure = unit.hist_figure_id ~= -1 and df.historical_figure.find(unit.hist_figure_id) or createFigure(unit,he,he_group) -- the histfig check is there just in case this function is called by another script to create nemesis data for a historical figure which somehow lacks it
  nem.figure.nemesis_id = id
  return nem
end
function sigh()
for k,v in pairs(df.global.world.units.active) do
local HF=df.global.world.history.figures
local HO=df.global.plotinfo.civ_id
local EN=df.global.world.entities.all[HO]
local HP=df.global.plotinfo.group_id
if v.hist_figure_id==-1 and v.civ_id==df.global.plotinfo.civ_id then
createNemesis(v,HO,HP)
--createFigure(v,EN,HP)
print(k)
end
end
end

for k,v in pairs(df.global.world.units.active) do
local HFN=df.global.world.history.figures
local HN=df.global.plotinfo.civ_id
sigh()
if v.hist_figure_id==-1 then break else
for c,q in pairs(HFN[v.hist_figure_id].entity_links) do
if q.entity_id==df.global.plotinfo.civ_id and v.population_id==-1 and q.entity_id~=df.global.plotinfo.group_id then
print(v.hist_figure_id)
HFN[v.hist_figure_id].entity_links:insert("#",{new=df.histfig_entity_link_memberst})
HFN[v.hist_figure_id].entity_links[c].entity_id=df.global.plotinfo.group_id
HFN[v.hist_figure_id].entity_links[c].link_strength=100
end
end
end
end

ok so this script is an update to the 3 year old version that probably doesn't work well in DF50 due to the ui to plotinfo change said script also been updated to include uhh 3 year old spawn unit coding for making histfigs and nemesis records as that's a good source to draw from.
this is mostly a modder tool to help with sapient historical-figureless citizen scenario that animal entity tokens do with multi-cultural forts. This script for df50 mostly gives them noble access and means to join squads as I think df50 already gives them labor access.

should note this will not help the 'oops main civ is cats and now no one a noble' issue that one would require a separate custom script for appointing a civ unit to a noble position.


Code: ("wagon-unretire2.lua") [Select]
local contain={}
function unretirewagon(curx,cury,curz)

for de,oe in pairs(df.global.world.buildings.other.WAGON) do
if oe.name == 'Nomad' then


local vector=df.global.world.items.all -- load all items
for i = 0, #vector-1 do -- look into all items offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==oe.centerx and cy==oe.centery and cz==oe.z then --compare them
dfhack.items.moveToBuilding(vector[i],oe) --return index
end
end

end
end
end

unretirewagon()


here's another wagon script that stores items directly in the center of the wagon back into the wagon for events of retiring and unretiring while nomading, it works with void forts and normal stationary forts ... as so long you name the wagon 'Nomad' ... or delete the if line of code checking if a wagon is named nomad.
Title: Re: DFHack 50.08-r2
Post by: xzaxza on June 08, 2023, 07:28:18 am
In short, emigration.lua worked in past, but no longer works. I fixed it (https://github.com/wsfsbvchr/dfhack-utils/blob/main/emigration-fix.lua). Do you want it?

Please! Could you open a PR against the scripts repo? https://github.com/DFHack/scripts/pulls
We can discuss it over the code review.

Took a while, but I got around to do it. https://github.com/DFHack/scripts/pull/735 for 0.47.05 branch, https://github.com/DFHack/scripts/pull/736 for current version. The latter will require some changes, dunno about the former.
Title: Re: DFHack 50.08-r3
Post by: Boltgun on June 13, 2023, 01:17:41 pm
What's the best way to add an announcement on the last version ? For example, I'm trying to add a cancellation message with this line
Code: [Select]
dfhack.gui.autoDFAnnouncement(df.announcement_type.cancel_job, unit.pos, message, COLOR_YELLOW)But it opens the embark "Strike the earth" message. Maybe I got the type wrong.
Title: Re: DFHack 50.08-r3
Post by: myk on June 13, 2023, 02:14:25 pm
Looking at a real cancellation announcement, it looks like you have the type correct and the enum value is correct. The internal announcement behavior mapping (the data read from prefs/announcements.txt) looks rational as well.

In short, I'm not sure what's going on here. Could you file an issue at https://github.com/DFHack/dfhack/issues ? This appears to be some sort of bug, though I'm not sure where.
Title: Re: DFHack 50.08-r3
Post by: Boltgun on June 15, 2023, 02:55:30 am
Thanks will do.
Title: Re: DFHack 50.08-r3
Post by: Rumrusher on June 19, 2023, 12:48:45 am
Code: ("recruitorder.lua") [Select]
--this is a script that is a modified version of the recruit script as this doesn't randomly select a historical figure but choose one out of a list.
--for this to work you need to send someone off on a mission probably a safe one like exploring ruins and in the middle of the mission run this script.
-- it might take a few tries to see if it works but if you see two printed out messages showcasing the army id and the mission report info then it might have worked.
--oh it also reuses the campboat script for list gui functions   
local dlg=require("gui.dialogs")
function teleportboatnames2()
local Ark={}
for k,v in pairs(df.global.world.nemesis.all) do
BoaName=dfhack.TranslateName(v.figure.name)
table.insert (Ark,{dfhack.TranslateName(v.figure.name).." "..v.figure.name.nickname,nil,v,search_key = BoaName:lower()})
end
local f=function(Name,C)
  OrderRecruit(C[3])
end
dlg.showListPrompt("list of Nemesis havers","Select Being(s) to settle here",COLOR_WHITE,Ark,f,nil,nil,true)
end

function OrderRecruit(Nemes)
for de,oe in pairs(df.global.world.army_controllers.all) do
if oe.mission_report == nil then else
print ( de,oe.mission_report.title)
for e,o in pairs(df.global.world.armies.all) do
if oe.id == o.controller_id then
print (e)
local forv=df.global.world.armies.all[e].members[0]
df.global.world.armies.all[e].members:insert("#",{new=true,nemesis_id=Nemes.id,
stored_fat = forv.stored_fat,
unk_2c= forv.unk_2c,
unk_28= forv.unk_28,
unk_1= forv.unk_1,
unk_30= forv.unk_30,
unk_34= forv.unk_34})
end
end
end
end
end

teleportboatnames2()
ok so here's a modified version of the old recruit script for targeting one nemesis having hist fig in the world.
hmm ok it seems this script will just shove the historical figure into any squad in an active mission so I don't know if this would dupe the being if you have 2 armies out or insert them into a conquer attempt and accidentally migrated someone to a new site?  still don't know if this is stable so user beware on save stability.

Code: ("recruit-inhabitants.lua") [Select]
--modification of the recruit script that uses the squad option in armies to pad out your army troops and to summon 30 unknown no name units at your enemies and possibly sending them back to you.
--these are inhabitants beings with no historical figures so if you got a script that could give them one or retire you're probably going to have some troubles getting them army ready.
--this script requires the squad to be mid mission to work if you don't see 2 printed info then it didn't stick.
function RecruitInhabit(Nemes)
for de,oe in pairs(df.global.world.army_controllers.all) do
if oe.mission_report == nil then else
print ( de,oe.mission_report.title)
for e,o in pairs(df.global.world.armies.all) do
if oe.id == o.controller_id then
print (e)
local forv=df.global.world.armies.all[e].members[0]
local long=df.global.world.nemesis.all[forv.nemesis_id].unit.population_id
df.global.world.armies.all[e].squads:insert("#",{new=true,count=30,race=df.global.plotinfo.race_id,population_id=long,entity_id=df.global.plotinfo.civ_id})
end
end
end
end
end

RecruitInhabit()
edit ok so here's another script that uses a modified recruit script to instead fill out the army's squad data with inhabitants... this holds potential for putting any creature in the game and any creature with any interaction.
so someone could return to the fort with like an army of necromancers or revenants/intel undead... or zombies/werebeasts (and just ruin your fort's day.)
this messes with the inhabitant mechanic that towns uses to pad out the place so these beings returning to the site will be historical figureless citizens that would require figuring out a way to get them historical figures either by having them kill a historical figure in self defense or retiring and unretiring the place... which may or may not also require them to petition to join the fort which also takes like 2 in-game years to pull off. or use a script that speeds up that process.
Title: Re: DFHack 50.08-r3
Post by: myk on June 23, 2023, 09:36:54 pm
DFHack 50.08-r4 released!

Get it here: https://github.com/DFHack/dfhack/releases/tag/50.08-r4

Or install from Steam: https://store.steampowered.com/app/2346660/DFHack

If you're on the DF beta branch on Steam, subscribe to the DFHack beta_experimental_sdl2 branch
Title: Re: DFHack 50.08-r4
Post by: myk on June 29, 2023, 12:22:53 am
DFHack 50.09-r1 released!

Get it here: https://github.com/DFHack/dfhack/releases/tag/50.09-r1

Or install from Steam: https://store.steampowered.com/app/2346660/DFHack
Title: Re: DFHack 50.08-r4
Post by: Rumrusher on June 29, 2023, 05:44:02 am
poppin in here to say the current Dfhack release does not respect classic build's settings of having ascii mode turn on.
some how the build just forces it self to check it off on start up... even though premium mode would load no art assets and have everything on screen be invisible.
outside of strangely enough some art assets like the grass and some floor tiles... the ui is also hidden outside of the text.


edit: ok so this some how is a vanilla issue which probably being look at... though this does open the door to figuring out a way to patch this with dfhack.
Title: Re: DFHack 50.09-r1
Post by: myk on July 05, 2023, 10:29:05 pm
We're working on some screens to help with trading:

(https://user-images.githubusercontent.com/977482/251333791-d79474d4-e984-481b-b59b-037c91d7b348.png)

Selecting multiple items is very simple. You can click on an item to toggle whether it will be brought to the depot, or you can use the arrow keys and hit Enter to toggle the highlighted item.

You can also shift-click on an item, and all items from the previously-selected item to the one you shift-click on will be toggled.

Some common workflows:

Sell all damaged items

Sell all items that the caravan requested in last year's trade agreement

Sell high-value pots of food

Here's the current feature list:

- item condition slider
- quality slider
- item value slider
- toggle for whether to include forbidden items (if you mark a forbidden item for trade, it will be automatically unforbidden)
- information on export agreements with the civilizations of the visiting caravan(s)
- option for filtering items by whether they were requested by the export agreement
- information on the ethical restrictions of the visiting caravan(s)
- option for filtering items by ethical acceptability
- information on current export mandates
- option for filtering out items banned for export
- option for additionally filtering out items that your nobles might ban *as the caravan is leaving* (which they do uncomfortably often) which would cause your dwarves to be punished just the same as if they brought a banned item to the depot for sale
- info on value of items brought/to be brought to the depot
- items that are not reachable from the trade depot or are otherwise not tradable (e.g. the item is on fire) are filtered out of the list

Do you have more thoughts/suggestions? What do you think of the screen layout? There is a lot of space given to the informational/filter widgets, but I'm not sure if that can be helped. The alternative is to show them dynamically, but I don't know if that's a better or worse user experience. You can always resize the window or maximize it by double-clicking on the "Select trade goods" header.
Title: Re: DFHack 50.09-r1
Post by: A_Curious_Cat on July 05, 2023, 11:52:17 pm
Looks good to me! 👍

Btw, are you caught up on issue #3366 (https://github.com/DFHack/dfhack/issues/3366)?  I got AtomicChicken to reply to it.

Also, are you telling me that I can’t trade an item if it’s on fire?!  What if I use a minecart delivery service?
Title: Re: DFHack 50.09-r1
Post by: Clatch on July 06, 2023, 06:44:14 pm
OMG! I just found toggle-kbd-cursor....

Thank you!!!!!
Title: Re: DFHack 50.09-r1
Post by: Rumrusher on July 07, 2023, 12:49:27 pm
Spoiler: " gif showcase" (click to show/hide)
Code: (nomadfast.lua) [Select]
--script using warmist spellbook code to make a cheap gui for expanding and contracting a player fort.
-- this script is pretty dangerous in that it reveals the expanded map chunk, and when contracting it culls anyone in that map chunk.
-- so far probably best to use this with the void fort scripts as it allows one to expand and explore the world while keeping your site.
--oh warning if you're about to collapse a map chunk make sure to clear any stockpiles and civ zones you made in that map chunk.
--oh and don't retire unless you're back to the original fort embark size or the game will corrupt that fort and or crash.
--also it will take a while for any results to happen. I have no idea on speeding up the process.
--:edit 7/7/2023 this version of nomad script speeds up the process instantly due to messing with cur_season_ticks
--if you use this for some nomad playstyle best learn how to haul goods across map and burrowing folks.
--as you might lose folks while traveling.
 
local dlg=require("gui.dialogs")

function GoN()
local Site=df.global.plotinfo.main.fortress_site
local Nor=Site.global_min_y-1
Site.global_min_y=Nor
df.global.cur_season_tick=3999
end

function NoN()
local Site=df.global.plotinfo.main.fortress_site
local Nor=Site.global_min_y+1
Site.global_min_y=Nor
df.global.cur_season_tick=3999
end
function GoS()
local Site=df.global.plotinfo.main.fortress_site
local Sor=Site.global_max_y+1
Site.global_max_y=Sor
df.global.cur_season_tick=3999
end
function NoS()
local Site=df.global.plotinfo.main.fortress_site
local Sor=Site.global_max_y-1
Site.global_max_y=Sor
df.global.cur_season_tick=3999
end
function GoE()
local Site=df.global.plotinfo.main.fortress_site
local Eor=Site.global_max_x+1
Site.global_max_x=Eor
df.global.cur_season_tick=3999
end
function NoE()
local Site=df.global.plotinfo.main.fortress_site
local Eor=Site.global_max_x-1
Site.global_max_x=Eor
df.global.cur_season_tick=3999
end
function GoW()
local Site=df.global.plotinfo.main.fortress_site
local Wor=Site.global_min_x-1
Site.global_min_x=Wor
df.global.cur_season_tick=3999
end
function NoW()
local Site=df.global.plotinfo.main.fortress_site
local Wor=Site.global_min_x+1
Site.global_min_x=Wor
df.global.cur_season_tick=3999
end

function Go()
for k,v in pairs(df.global.world.armies.all) do
if v.flags[0]== true  then
local Nor=v.pos.y-1
v.pos.y=Nor
df.global.cur_season_tick=3999
end
end
end
function doNothing()
print("doing nothing real good but here have a site")
--require("plugins.dfusion.adv_tools").addSite(nil,nil,nil,nil,nil,nil,df.global.world.units.active[0].civ_id)
end
function doNothing2()
dlg.showMessage("Travel-Hack","Bypassing Message to access FastTravel")
df.global.ui_advmode.message=""
--require("plugins.dfusion.adv_tools").addSite(nil,nil,nil,nil,nil,nil,df.global.world.units.active[0].civ_id)
end

function greetAndStuff()
dlg.showMessage("Greetings", "Seasons greatings and lols")
end
MOVEMENT_KEYS = {
    A_CARE_MOVE_N = { 0, -1, 0 }, A_CARE_MOVE_S = { 0, 1, 0 },
    A_CARE_MOVE_W = { -1, 0, 0 }, A_CARE_MOVE_E = { 1, 0, 0 },
    A_CARE_MOVE_NW = { -1, -1, 0 }, A_CARE_MOVE_NE = { 1, -1, 0 },
    A_CARE_MOVE_SW = { -1, 1, 0 }, A_CARE_MOVE_SE = { 1, 1, 0 },
    --[[A_MOVE_N = { 0, -1, 0 }, A_MOVE_S = { 0, 1, 0 },
    A_MOVE_W = { -1, 0, 0 }, A_MOVE_E = { 1, 0, 0 },
    A_MOVE_NW = { -1, -1, 0 }, A_MOVE_NE = { 1, -1, 0 },
    A_MOVE_SW = { -1, 1, 0 }, A_MOVE_SE = { 1, 1, 0 },--]]
    A_CUSTOM_CTRL_D = { 0, 0, -1 },
    A_CUSTOM_CTRL_E = { 0, 0, 1 },
    CURSOR_UP_Z_AUX = { 0, 0, 1 }, CURSOR_DOWN_Z_AUX = { 0, 0, -1 },
    A_MOVE_SAME_SQUARE={0,0,0},
    SELECT={0,0,0},
}
ALLOWED_KEYS={
    A_MOVE_N=true,A_MOVE_S=true,A_MOVE_W=true,A_MOVE_E=true,A_MOVE_NW=true,
    A_MOVE_NE=true,A_MOVE_SW=true,A_MOVE_SE=true,A_STANCE=true,SELECT=true,A_MOVE_DOWN_AUX=true,
    A_MOVE_UP_AUX=true,A_LOOK=true,CURSOR_DOWN=true,CURSOR_UP=true,CURSOR_LEFT=true,CURSOR_RIGHT=true,
    CURSOR_UPLEFT=true,CURSOR_UPRIGHT=true,CURSOR_DOWNLEFT=true,CURSOR_DOWNRIGHT=true,A_CLEAR_ANNOUNCEMENTS=true,
    CURSOR_UP_Z=true,CURSOR_DOWN_Z=true,
}

listofspells={
{text="nothing", spell=doNothing,icon='*'},
{text="expand: North+", spell=GoN,key="CUSTOM_W"},
{text="expand: South+", spell=GoS,key="CUSTOM_S"},
{text="expand: East+", spell=GoE,key="CUSTOM_D"},
{text="expand: West+", spell=GoW,key="CUSTOM_A"},
{text="Contract: North-", spell=NoN,key="CUSTOM_T"},
{text="Contract: South-", spell=NoS,key="CUSTOM_G"},
{text="Contract: East-", spell=NoE,key="CUSTOM_H"},
{text="Contract: West-", spell=NoW,key="CUSTOM_F"},
}
 
dlg.showListPrompt("Directions","Choze Direct",nil, listofspells,function(index,choice) choice.spell() end)

ok so here's an updated version of nomad now with less waiting all thanks to cur_season_tick being set to 3999 and letting time progress to 4000
this does mean going through nomad fast might require seeing what happens if you mess with seasonal timers.

also here's an liquids gui edit for future proofing scripts with
the personal keyboard cursor gui script
Spoiler: gif showcase 2 (click to show/hide)

Code: (keyboardcursor.lua) [Select]
--keyboard cursor that uses the widget of gui/liquids as I don't know how to write widgets
--proof of concept for adding an extra keyboard cursor to df50 that doesn't rely on mining tools.

local gui = require('gui')
local guidm = require('gui.dwarfmode')
local widgets = require('gui.widgets')



local SpawnLiquidCursor = {
    [df.tile_liquid.Water] = dfhack.screen.findGraphicsTile('MINING_INDICATORS', 0, 0),
    [df.tile_liquid.Magma] = dfhack.screen.findGraphicsTile('MINING_INDICATORS', 1, 0),
    [df.tiletype.RiverSource] = dfhack.screen.findGraphicsTile('LIQUIDS', 0, 0),
}

SpawnLiquid = defclass(SpawnLiquid, widgets.Window)
SpawnLiquid.ATTRS {
    frame_title='Cursor Keyboard menu',
    frame={b = 4, r = 4, w = 50, h = 12},
}

function SpawnLiquid:init()
    self.type = df.tile_liquid.Water
    self.tile = SpawnLiquidCursor[self.type]

    self:addviews{
        widgets.Label{
            frame = {l = 0, t = 0},
            text = {{ text = self:callback('getLabel') }}
        },
        widgets.HotkeyLabel{
            frame = {l = 0, b = 1},
            label = 'does nothing',
            auto_width = true,
            key = 'KEYBOARD_CURSOR_LEFT',
            on_activate = self:callback('moveleft'),
            disabled = function() return self.level == 1 end
        },
        widgets.HotkeyLabel{
            frame = { l = 19, b = 1},
            label = 'also Does nothing',
            auto_width = true,
            key = 'KEYBOARD_CURSOR_RIGHT',
            on_activate = self:callback('moveright'),
            disabled = function() return self.level == 7 end
        },
        widgets.HotkeyLabel{
            frame = { l = 19, b = 1},
            label = 'also Does nothing',
            auto_width = true,
            key = 'KEYBOARD_CURSOR_UP',
            on_activate = self:callback('moveup'),
            disabled = function() return self.level == 7 end
        },
        widgets.HotkeyLabel{
            frame = { l = 19, b = 1},
            label = 'also Does nothing',
            auto_width = true,
            key = 'KEYBOARD_CURSOR_DOWN',
            on_activate = self:callback('movedown'),
            disabled = function() return self.level == 7 end
        },
        widgets.CycleHotkeyLabel{
            frame = {l = 0, b = 2},
            label = 'cursor color:',
            auto_width = true,
            key = 'CUSTOM_Q',
            options = {
                { label = "Water", value = df.tile_liquid.Water, pen = COLOR_CYAN },
                { label = "Magma", value = df.tile_liquid.Magma, pen = COLOR_RED },
                { label = "River", value = df.tiletype.RiverSource, pen = COLOR_BLUE },
            },
            initial_option = 0,
            on_change = function(new, _)
                self.type = new
                self.tile = SpawnLiquidCursor[new]
            end,
        },
    }
end

-- TODO: More reactive label dependant on options selected.
function SpawnLiquid:getLabel()
    return ([[Click on a tile to spawn a %s/7 level of %s]]):format(
        self.level,
        self.type == 0 and "Water" or self.type == 1 and "Magma" or "River"
    )
end

function SpawnLiquid:getLiquidLevel(position)
    local tile = dfhack.maps.getTileFlags(position)

    if self.mode == SpawnLiquidMode.ADD then
        return math.max(0, math.min(tile.flow_size + self.level, 7))
    elseif self.mode == SpawnLiquidMode.REMOVE then
        return math.max(0, math.min(tile.flow_size - self.level, 7))
    end

    return self.level
end

function SpawnLiquid:increaseLiquidLevel()
    self.level = math.min(self.level + 1, 7)
end

function SpawnLiquid:decreaseLiquidLevel()
    self.level = math.max(self.level - 1, 1)
end
function SpawnLiquid:moveleft()
    local move=df.global.cursor
move.x=move.x-1
end
function SpawnLiquid:moveright()
    local move=df.global.cursor
move.x=move.x+1
end
function SpawnLiquid:moveup()
    local move=df.global.cursor
move.y=move.y-1
end
function SpawnLiquid:movedown()
    local move=df.global.cursor
move.y=move.y+1
end

function SpawnLiquid:spawn(pos)
--local MapCure=df.global.gview.view.child
mouse_pos = dfhack.gui.getMousePos()
df.global.cursor.x=mouse_pos.x
df.global.cursor.y=mouse_pos.y
df.global.cursor.z=mouse_pos.z
end

function SpawnLiquid:getPen()
    return self.type == df.tile_liquid.Water and COLOR_BLUE or COLOR_RED, "X", self.tile
end

function SpawnLiquid:getBounds(start_position, end_position)
    return {
        x1=math.min(start_position.x, end_position.x),
        x2=math.max(start_position.x, end_position.x),
        y1=math.min(start_position.y, end_position.y),
        y2=math.max(start_position.y, end_position.y),
        z1=math.min(start_position.z, end_position.z),
        z2=math.max(start_position.z, end_position.z),
    }
end

function SpawnLiquid:onRenderFrame(dc, rect)
    SpawnLiquid.super.onRenderFrame(self, dc, rect)

    local mouse_pos = dfhack.gui.getMousePos()

    if self.is_dragging then
        if df.global.enabler.mouse_lbut == 0 then
            self.is_dragging = false
        elseif mouse_pos and not self:getMouseFramePos() then
            self:spawn(mouse_pos)
        end
    end

       guidm.renderMapOverlay(self:callback('getPen'), self:getBounds(
  self.area_first_pos or df.global.cursor, df.global.cursor
  ))
end

function SpawnLiquid:onInput(keys)
    if SpawnLiquid.super.onInput(self, keys) then return true end

    if keys._MOUSE_L_DOWN and not self:getMouseFramePos() then
        local mouse_pos = dfhack.gui.getMousePos()
            self:spawn()
end
end

SpawnLiquidScreen = defclass(SpawnLiquidScreen, gui.ZScreen)
SpawnLiquidScreen.ATTRS {
    focus_path = 'spawnliquid',
    pass_movement_keys = true,
    pass_mouse_clicks = false,
    force_pause = true,
}

function SpawnLiquidScreen:init()
    self:addviews{SpawnLiquid{}}
end

function SpawnLiquidScreen:onDismiss()
    view = nil
end

view = view and view:raise() or SpawnLiquidScreen{}:show()

oh and here's a script for telling where you are on the global min x and y coords of the site you're on the info shown is going off the top left corner of the map to the bottom right it probably best to not use this after changing the site's coords as the script looks at the site's current global min and max coords to get the second info from for the folks who dip into gui gm-editoring as their means to nomad around the world.

oh and this only works if the wagon is named Nomad as do most of my nomad scripts as it grabs the wagon's coords to check where it is on the game field embark space wise.
Code: (wagon-sense) [Select]
function wagon(curx,cury,curz)
for de,oe in pairs(df.global.world.buildings.other.WAGON) do
if oe.name == 'Nomad' then

local regionx=math.floor(oe.centerx/47)
local regiony=math.floor(oe.centery/47)
print("X region", regionx,
"Y region", regiony)
local site=df.global.plotinfo.main.fortress_site
print("X region + min", regionx + site.global_min_x,
"Y region + min", regiony + site.global_min_y )

end
end
end

wagon()
I think this is prime for folks to fully explore the worlds with their fort citizens... combine this with that force petition script and you could play out series of oregon trail like sessions.
usually with the nomad scripts
oh and uhh if you leave your starting location and you dig out a bunch of stuff in the process the game will undo any changes you did on a digging and construction wise, buildings are safe though. folks stored in cages that are stored in the wagon will stay in the wagon while you travel around the world.

getting mayors and nobles who like to stay in a room would make nomad playstyle a bit rough as you would be building up and tearing down their rooms while you prep to travel to a new location.
this playstyle does open up to some different challenges one could take on like the no-build run where you just strip mine the land and harvest the fields to trek to one of the dwarven fortress entrances that houses all workshops for you to use.
this also means no trading until you get to a trade depot this challenge is probably more rough if you play it with dwarves as the strange mood would mean ditching the dwarf to avoid the mood hit or dealing with staying at the dwarven fortress entrance longer for hoping to get that artifact built.

I just realize folks could build a magma pump that leads to a tunnel that pours the magma into the ocean to make an island then just settle their group on the island... and probably with a lil extra void fort set up sail the seas on their remote obsidian casts landmass and harvest all the fish from the sea.
Title: Re: DFHack 50.09-r1
Post by: Bjorn on July 08, 2023, 01:17:21 pm
Is there any command to forcefully assign a specific noble position to a dwarf? (The current dwarf holding the position can't be removed)
Title: Re: DFHack 50.09-r1
Post by: myk on July 08, 2023, 03:27:07 pm
Not an easy command, no. A tool like that is under discussion, though.
Title: Re: DFHack 50.09-r1
Post by: scriver on July 17, 2023, 03:15:08 am
DFhack on steam frontpage? :D

Quote
(https://i.ibb.co/stWBRN6/bild.png)
Title: Re: DFHack 50.09-r1
Post by: myk on July 17, 2023, 03:16:51 pm
Thanks for the rec, Putnam!
Title: Re: DFHack 50.09-r1
Post by: myk on July 18, 2023, 08:57:19 pm
New unit pasture assignment screen coming in the next DFHack version:


(https://media.discordapp.net/attachments/807444515194798090/1130602437300998196/image.png)
Title: Re: DFHack 50.09-r1
Post by: myk on July 22, 2023, 06:49:26 pm
DFHack 50.09-r2 released!

Get it here: https://github.com/DFHack/dfhack/releases/tag/50.09-r2

Or install from Steam: https://store.steampowered.com/app/2346660/DFHack
Title: Re: DFHack 50.09-r2
Post by: 0x517A5D on July 25, 2023, 12:48:11 pm
Will tubefill be returning anytime soon?

I experimented a bit in Lua, and it looks like the entire pipe, not just the raw adamantine tiles, are now flagged as .local_feature type feature_init_deep_special_tubest .

I don't see a way to tell which already-mined tiles had adamantine.

All the jewels are in map_block.block_events, but the raw adamantine 'vein' isn't.

I'm at a loss.  I'm just hoping someone who knows more can figure it out.
Title: Re: DFHack 50.09-r1
Post by: ab9rf on July 25, 2023, 01:03:14 pm
DFhack on steam frontpage? :D

Quote
(https://i.ibb.co/stWBRN6/bild.png)
Steam's "front page" is dynamically generated by Steam for each user, but yes, DFHack is (now) eligible for consideration in that process and so it is possible that Steam's adaptive marketing system will promote DFHack to people that Steam thinks might be interested.
Title: Re: DFHack 50.09-r2
Post by: myk on July 28, 2023, 01:24:38 am
I experimented a bit in Lua, and it looks like the entire pipe, not just the raw adamantine tiles, are now flagged as .local_feature type feature_init_deep_special_tubest .

I don't see a way to tell which already-mined tiles had adamantine.

Accurate is preferable, but it might not be terrible to just fill all non-wall deep_special tiles with walls of adamantine. If the player is using tubefill, then they probably won't complain if they get a little extra adamantine.
Title: Re: DFHack 50.09-r2
Post by: 0x517A5D on July 29, 2023, 11:05:42 am
Proposal for a 99% solution:

The tubefill plugin runs at every map load.

If it hasn't seen the map yet, it inspects and records the locations of all raw adamantine tiles.

This could be recorded as plugin-specific persistent data, or recorded by actually creating the mineral vein definition that really ought to be there in the first place.

When invoked manually, the plugin just uses that list of raw adamantine tiles to recreate the feature.

The only way this fails is the case where mining has already taken place before the tool first analyzes the map.

I would also note that this could be done in a mod Lua script, with the serious downside that the player would need to install and select the mod at world generation time.

I'm kind of tempted to write this as a mod, and figure out how to retrofit it into my current 23-year-old fort.
Title: Re: DFHack 50.09-r2
Post by: myk on July 31, 2023, 07:11:30 am
I would also note that this could be done in a mod Lua script, with the serious downside that the player would need to install and select the mod at world generation time.

This is something I anticipated, and the downside is no longer a downside. If you put your script in a folder named scripts_modinstalled inside your mod, then DFHack will find and load the script without requiring that the player make the mod "active" in a generated world. If the mod is on the Steam Workshop, DFHack will find the script if the player is subscribed to the mod.

More info at: https://docs.dfhack.org/en/stable/docs/guides/modding-guide.html#dfhack-modding-guide
Title: Re: DFHack 50.09-r2
Post by: Eric Blank on August 01, 2023, 01:40:56 am
Is it possible to get a function to read and display wilderness/cavern agitation levels, to say monitor how close you are to attracting agitated wildlife or cavern ambushes?
Title: Re: DFHack 50.09-r2
Post by: A_Curious_Cat on August 01, 2023, 12:29:16 pm
Is it possible to get a function to read and display wilderness/cavern agitation levels, to say monitor how close you are to attracting agitated wildlife or cavern ambushes?

If I’m reading df.map.xml right, it should be under df.map.feature.irritation_level.  Dividing that by 10K should give the chance of an attack.

Also, @Myk, df.map.xml also says:

Quote from: df.map.xml
<int16_t name='irritation_attacks' comment='maxes at 10?'/>

Does that mean that there can be no more than 10 attacks by agitated creatures at one time?
Title: Re: DFHack 50.09-r2
Post by: 0x517A5D on August 01, 2023, 01:33:26 pm
If I’m reading df.map.xml right, it should be under df.map.feature.irritation_level.  Dividing that by 10K should give the chance of an attack.

Also, @Myk, df.map.xml also says:

Quote from: df.map.xml
<int16_t name='irritation_attacks' comment='maxes at 10?'/>

Does that mean that there can be no more than 10 attacks by agitated creatures at one time?

gui/gm-editor tells me the structure is
    df.global.world.features.map_features[].feature.irritation_level
and
    df.global.world.features.map_features[].feature.irritation_attacks


Is it possible to get a function to read and display wilderness/cavern agitation levels, to say monitor how close you are to attracting agitated wildlife or cavern ambushes?

This horrible one-liner prints (some of) the data for each map feature.  But I don't think it covers the surface.  I don't know at the moment where that data is.  Run from the DFHack prompt.
Code: [Select]
:lua for i,mf in ipairs(df.global.world.features.map_features) do l=-1;pcall(function()l=mf.layer;end);print(string.format("feature %d %s %s-%s underground_region #%d irritation_level %d irritation_attacks %d",i,mf._type,df.layer_type[mf.start_depth],df.layer_type[mf.end_depth],l,mf.feature.irritation_level,mf.feature.irritation_attacks));end;
Sample output:
Code: [Select]
feature 0 <type: feature_init_subterranean_from_layerst> Cavern1-Cavern1 underground_region #11 irritation_level 4008 irritation_attacks 0
feature 1 <type: feature_init_subterranean_from_layerst> Cavern2-Cavern2 underground_region #31 irritation_level 7924 irritation_attacks 0
feature 2 <type: feature_init_subterranean_from_layerst> Cavern3-Cavern3 underground_region #56 irritation_level 11408 irritation_attacks 0
feature 3 <type: feature_init_magma_core_from_layerst> MagmaSea-MagmaSea underground_region #81 irritation_level 3180 irritation_attacks 0
feature 4 <type: feature_init_underworld_from_layerst> Underworld-Underworld underground_region #106 irritation_level 0 irritation_attacks 0
feature 5 <type: feature_init_outdoor_riverst> Surface-Surface underground_region #-1 irritation_level 288 irritation_attacks 0
feature 6 <type: feature_init_subterranean_from_layerst> Cavern1-Cavern1 underground_region #6 irritation_level 1760 irritation_attacks 0
feature 7 <type: feature_init_deep_special_tubest> MagmaSea-Underworld underground_region #-1 irritation_level 20040 irritation_attacks 0
feature 8 <type: feature_init_deep_special_tubest> MagmaSea-Underworld underground_region #-1 irritation_level 0 irritation_attacks 0

Hmm.  Outdoor irritation is kept separate from that, in a variable in plotinfo.
Code: [Select]
:lua print(string.format("outdoor_irritation:%d",df.global.plotinfo.outdoor_irritation))
Sample output:
Code: [Select]
outdoor_irritation:35000
Title: Re: DFHack 50.09-r2
Post by: 0x517A5D on August 01, 2023, 02:01:09 pm
@myk, @lethosor, please tell me about persistent configuration storage.

I think I see how dfhack.persistent.get(key) works.

Is there a (soft or hard) size limit on the value string?

Is it preferable to have one entry with a very (very) long string, or many (many) entries with empty strings, using the ints[] instead?

Or should I look for another way?  I could modify the map itself....
Title: Re: DFHack 50.09-r2
Post by: lethosor on August 01, 2023, 09:34:33 pm
If I’m reading df.map.xml right, it should be under df.map.feature.irritation_level.  Dividing that by 10K should give the chance of an attack.
Nope, that's not quite how you read the file. Each XML file is a collection of loosely-related types, and you are looking at the definition of the "feature" struct (https://github.com/DFHack/df-structures/blob/fc4961f51f2773cff0dfe76e3ad719c027051046/df.map.xml#L581-L603). So if you can find an instance of feature, it will have these fields.

This type is a little hard to search for since a lot of other types/fields also have "feature" in their name. I ended up searching for ='feature' and determined that there are no instances of the feature type itself, but there are a bunch of instances of subclasses of feature contained within subclasses of feature_init (these are all in df.map.xml still). The vector that 0x517A5D pointed out (df.global.world.features.map_features (https://github.com/DFHack/df-structures/blob/fc4961f51f2773cff0dfe76e3ad719c027051046/df.world.xml#L1675)) is a vector of feature_init objects. It very likely contains subclasses of feature_init, but all of those (https://github.com/DFHack/df-structures/blob/fc4961f51f2773cff0dfe76e3ad719c027051046/df.map.xml#L698-L745) do contain an instance of a feature subclass named "feature", so you ought to be able to get to the irritation fields from there, as shown by 0x517A5D.

Is there a (soft or hard) size limit on the value string?

Is it preferable to have one entry with a very (very) long string, or many (many) entries with empty strings, using the ints[] instead?
I believe there is no longer a hard limit. There used to be a 65k limit when we stored data as histfig names, but now it should be getting stored in JSON instead. You can verify this by looking for a .dat file in your save folder named something starting with "dfhack" - it should actually contain JSON.

That said, you should limit yourself to a reasonable amount of data. Users will probably not be happy if you write 1GB of data in there.

Quote
Or should I look for another way?  I could modify the map itself....
What exactly are you trying to store? I believe we still have a way to associate a custom bitmap with map blocks, if you're trying to save some data that relates to map tiles.
Title: Re: DFHack 50.09-r2
Post by: myk on August 02, 2023, 12:54:56 am
a convenient way to store arbitrary data is to have a Lua table, encode it as JSON, and store it in a string (which gets persisted in a file as JSON-encoded JSON, but you don't have to be aware of that)

e.g.
Code: (lua) [Select]
local json = require('json')
local persist = require('persist-table')

local GLOBAL_KEY = 'myscriptname'

g_state = g_state or {} -- fill me with data (can be in nested tables)

-- call when your state changes and you want to make sure it is saved
local function persist_state()
    persist.GlobalTable[GLOBAL_KEY] = json.encode(g_state)
end

-- add a hook to load persisted state when a fort is loaded
dfhack.onStateChange[GLOBAL_KEY] = function(sc)
    if sc ~= SC_MAP_LOADED or df.global.gamemode ~= df.game_mode.DWARF then
        return
    end
    g_state = json.decode(persist.GlobalTable[GLOBAL_KEY] or '') or {}
end
Title: Re: DFHack 50.09-r2
Post by: Eric Blank on August 02, 2023, 01:35:46 am
If I’m reading df.map.xml right, it should be under df.map.feature.irritation_level.  Dividing that by 10K should give the chance of an attack.

Also, @Myk, df.map.xml also says:

Quote from: df.map.xml
<int16_t name='irritation_attacks' comment='maxes at 10?'/>

Does that mean that there can be no more than 10 attacks by agitated creatures at one time?

gui/gm-editor tells me the structure is
    df.global.world.features.map_features[].feature.irritation_level
and
    df.global.world.features.map_features[].feature.irritation_attacks


Is it possible to get a function to read and display wilderness/cavern agitation levels, to say monitor how close you are to attracting agitated wildlife or cavern ambushes?

This horrible one-liner prints (some of) the data for each map feature.  But I don't think it covers the surface.  I don't know at the moment where that data is.  Run from the DFHack prompt.
Code: [Select]
:lua for i,mf in ipairs(df.global.world.features.map_features) do l=-1;pcall(function()l=mf.layer;end);print(string.format("feature %d %s %s-%s underground_region #%d irritation_level %d irritation_attacks %d",i,mf._type,df.layer_type[mf.start_depth],df.layer_type[mf.end_depth],l,mf.feature.irritation_level,mf.feature.irritation_attacks));end;
Sample output:
Code: [Select]
feature 0 <type: feature_init_subterranean_from_layerst> Cavern1-Cavern1 underground_region #11 irritation_level 4008 irritation_attacks 0
feature 1 <type: feature_init_subterranean_from_layerst> Cavern2-Cavern2 underground_region #31 irritation_level 7924 irritation_attacks 0
feature 2 <type: feature_init_subterranean_from_layerst> Cavern3-Cavern3 underground_region #56 irritation_level 11408 irritation_attacks 0
feature 3 <type: feature_init_magma_core_from_layerst> MagmaSea-MagmaSea underground_region #81 irritation_level 3180 irritation_attacks 0
feature 4 <type: feature_init_underworld_from_layerst> Underworld-Underworld underground_region #106 irritation_level 0 irritation_attacks 0
feature 5 <type: feature_init_outdoor_riverst> Surface-Surface underground_region #-1 irritation_level 288 irritation_attacks 0
feature 6 <type: feature_init_subterranean_from_layerst> Cavern1-Cavern1 underground_region #6 irritation_level 1760 irritation_attacks 0
feature 7 <type: feature_init_deep_special_tubest> MagmaSea-Underworld underground_region #-1 irritation_level 20040 irritation_attacks 0
feature 8 <type: feature_init_deep_special_tubest> MagmaSea-Underworld underground_region #-1 irritation_level 0 irritation_attacks 0

Hmm.  Outdoor irritation is kept separate from that, in a variable in plotinfo.
Code: [Select]
:lua print(string.format("outdoor_irritation:%d",df.global.plotinfo.outdoor_irritation))
Sample output:
Code: [Select]
outdoor_irritation:35000

Thanks. Ive tried putting these in .lua files in the dfhack-config/scripts folder, but when i attempt to call them from the dfhack gui launcher using lua -f "printial" or "printial.lua" it outputs "cannot open printial.lua: no such file or directory."

I usually dont try to mess with dfhack at all, so i really dont know what im doing. attempting to run the last one you gave there directly through the launcher only outputs "(lua command):1: ')' expected near '.'"
Title: Re: DFHack 50.09-r2
Post by: 0x517A5D on August 02, 2023, 09:55:38 am
Thanks. Ive tried putting these in .lua files in the dfhack-config/scripts folder, but when i attempt to call them from the dfhack gui launcher using lua -f "printial" or "printial.lua" it outputs "cannot open printial.lua: no such file or directory."

I usually dont try to mess with dfhack at all, so i really dont know what im doing. attempting to run the last one you gave there directly through the launcher only outputs "(lua command):1: ')' expected near '.'"

Scripts are normally invoked with just their name, without the '.lua' extension.  Does just 'printial' work?

The command 'lua -f printial.lua' is kind of advanced.  The necessary syntax would be 'lua -f dfhack-config/scripts/printial.lua'.  Since you put the script in the proper directory, it's normal to just use the script name, without the extension.

The next point that might trip you up is that the contents of the script should not have the text ':lua ' at the start of any line.  That syntax is for running a Lua command directly from the DFHack commandline.





@lethosor,

I want to record the coordinates of tiles that contain raw adamantine, for later use to replenish the tube (ala the tubefill plugin).

I thought to record coordinates in int32's with the math x + y*1024 + z*1024*1024 .

This morning, it occurred to me that I could further compress this as runs of data since the max run would be 16.  x + y*1024 + z*1024*1024 + (runlength-1)*1024*1024*256 would occupy an entire uint32.

My other thought was to create new vein definition for the affected tiles.  Gems in the pipe have vein definitions, the adamantine logically should as well.

I now see entry:getTilemask() which looks like the right way to do this.  Fifty to a hundred entries per pipe, block coordinates in ints[1],ints[2],ints[3], 16x16 tiles, 1 bit per tile would work.

To confirm,

There are no examples to crib from in hack/scripts or hack/lua.


Thinking about it, all of the stuff about .entry_id and .key and .value and .ints[7] and .mask.bits[16]; that's all legacy.  If we now store data in separate JSON files, that's the path forward.
Title: Re: DFHack 50.09-r2
Post by: Eric Blank on August 02, 2023, 11:13:16 pm
Thank you, that worked :D
Title: Re: DFHack 50.09-r2
Post by: A_Curious_Cat on August 08, 2023, 05:33:54 pm
@Myk, did you get my message about AtomicChicken replying to issue #3366 (https://github.com/DFHack/dfhack/issues/3366)?  What do you think of the matter?
Title: Re: DFHack 50.09-r2
Post by: myk on August 08, 2023, 11:11:25 pm
I responded on the issue, tl;dr: yes, a building teleporter looks perfectly feasible
Title: Re: DFHack 50.09-r2
Post by: Boltgun on August 09, 2023, 03:39:35 am
Is there an easy way to clear the enemy status cache?

I'm a bit on a dead end to my old "corrupt enemies into friends" script. The script is simple and involve makeown, but it does not seem to clear hostility right. The targeted creatures walk through the fort before getting into a fight with what I believe to be specific units that see it as an enemy. Closing the save and reloading after running makeown prevent that issue.

I tried setting all the units cache slot to -1, setting the entire cache rel_map to -1 and slot_used to false. Got any idea what else I could do ?
Title: Re: DFHack 50.09-r2
Post by: PatrikLundell on August 09, 2023, 04:08:16 am
@Boltgun

Have you cleared out any conflict they are involved in?

I essentially haven't done anything with DF for a couple of years (still waiting for a playable version, first it was the mess left when the Premium tangent started, and then it was the removal of keyboard support), so the memory is rather fuzzy, but there's a structure that keeps track of conflicts and you could deal with invasion triggered conflict cascades by setting the conflict level in these structures to a non lethal brawl level rather than to the death. I suspect (former) enemies may still have such a lingering hostility structure.
Title: Re: DFHack 50.09-r2
Post by: Boltgun on August 09, 2023, 07:04:45 am
@Boltgun

Have you cleared out any conflict they are involved in?

I essentially haven't done anything with DF for a couple of years (still waiting for a playable version, first it was the mess left when the Premium tangent started, and then it was the removal of keyboard support), so the memory is rather fuzzy, but there's a structure that keeps track of conflicts and you could deal with invasion triggered conflict cascades by setting the conflict level in these structures to a non lethal brawl level rather than to the death. I suspect (former) enemies may still have such a lingering hostility structure.
That seems to be the case. In this case, the creature was in a cage but as soon as they are freed, the activities fills will conflicts. Time to make a script to sort that out. Thanks.
Title: Re: DFHack 50.09-r2
Post by: myk on August 09, 2023, 09:59:11 am
Once you figure it out, could you update makeown? This sounds like it should always be done when making a unit part of the fort.
Title: Re: DFHack 50.09-r2
Post by: Boltgun on August 09, 2023, 10:57:37 am
Once you figure it out, could you update makeown? This sounds like it should always be done when making a unit part of the fort.

I'll send you a PR once I get a proper script.

Edit: Turns out this is not the root of my problem. While it may be worth clearing conflicts if you use makeown after a fight, I don't have any before the fight breaks through. So it must be something else.
Title: Re: DFHack 50.09-r2
Post by: Rumrusher on August 11, 2023, 02:56:55 am
Is there an easy way to clear the enemy status cache?

I'm a bit on a dead end to my old "corrupt enemies into friends" script. The script is simple and involve makeown, but it does not seem to clear hostility right. The targeted creatures walk through the fort before getting into a fight with what I believe to be specific units that see it as an enemy. Closing the save and reloading after running makeown prevent that issue.

I tried setting all the units cache slot to -1, setting the entire cache rel_map to -1 and slot_used to false. Got any idea what else I could do ?
ok so from my time messing with my own petition script uhh you might need to mess with the historical figure data as their relationship with the civ might be stained or with other folks.
like if someone remembers hey this person was part of another civ that tried to kill you, or 'remembers they were part of a raid to kill you' this might throw up some red flags and lead to an uneasy truce.

though I feel like the sending the person off on a mission and returning back should clear some of the checks.
Title: Re: DFHack 50.09-r2
Post by: Boltgun on August 11, 2023, 12:51:10 pm
I found nothing on the targets (2 out of 3 are not historical figures before running makeown), I currently going through all the units to find a relationship. I think that once these specific units see them, the game create conflict activities and it's a mess, no loyalty cascade tho.

On the bright side I found some stuff that should go into the transform script. You need to update the soul and the historical figure so the game find what blood it need to paint the ground with.

Update : I went through histfig_links, entity_links, site_links, and info.relationships and found nothing. I'm contemplating just splitting it in two, with invader being zombified and call it a day.
Title: Re: DFHack 50.09-r2 | 50.09-r3rc1 pre-release (with Linux support)
Post by: lethosor on August 18, 2023, 11:41:48 pm
50.09-r3rc1 is up on the Steam "beta" branch, with support for a new Linux build on DF's Steam "beta" branch.

Release notes: https://www.reddit.com/r/dwarffortress/comments/15v194s/dfhack_5009r3rc1_released_on_the_steam_beta_branch/
Source code: https://github.com/dfhack/dfhack/tree/50.09-r3rc1
(We don't yet have a workflow figured out for direct downloads of pre-releases like this.)
Title: Re: DFHack 50.09-r2 | 50.09-r3rc1 pre-release (with Linux support)
Post by: myk on August 19, 2023, 05:02:06 am
The 50.09-r3rc1 with Linux support is now available at https://github.com/DFHack/dfhack/releases/tag/50.09-r3rc1
Title: Re: DFHack 50.08-r1
Post by: ldog on August 23, 2023, 11:36:00 am
oops
Title: Re: DFHack 50.09-r2 | 50.09-r3rc1 pre-release (with Linux support)
Post by: myk on September 01, 2023, 05:05:44 pm
50.09-r3rc3 with Linux support is now available at https://github.com/DFHack/dfhack/releases/tag/50.09-r3rc3 with some new goodies ; ) Stable release likely out next week.
Title: Re: DFHack 50.09-r2 | 50.09-r3rc1 pre-release (with Linux support)
Post by: A_Curious_Cat on September 01, 2023, 09:12:48 pm
Out of curiosity, any ETA on the steam-engine (https://docs.dfhack.org/en/stable/docs/tools/steam-engine.html) plug-in becoming available again?
Title: Re: DFHack 50.09-r2 | 50.09-r3rc3 pre-release (with Linux support)
Post by: myk on September 01, 2023, 10:17:33 pm
It hasn't been on our radar. Is anyone interested in updating it? It looks like a good candidate to be converted to Lua and distributed as an external mod as an example of how to do mod integration.
Title: Re: DFHack 50.09-r2 | 50.09-r3rc3 pre-release (with Linux support)
Post by: A_Curious_Cat on September 01, 2023, 11:04:47 pm
It hasn't been on our radar. Is anyone interested in updating it? It looks like a good candidate to be converted to Lua and distributed as an external mod as an example of how to do mod integration.

Am I reading this correctly that the building-hacks (https://docs.dfhack.org/en/stable/docs/dev/Lua%20API.html#building-hacks) plugin could be used for this purpose?
Title: Re: DFHack 50.09-r2 | 50.09-r3rc3 pre-release (with Linux support)
Post by: myk on September 01, 2023, 11:19:30 pm
Both `steam-engine` and `building-hacks` are plugins that affect buildings, but they are not the same. Much of the low level logic will probably still work for both plugins, but the UI components will need a makeover.
Title: Re: DFHack 50.09-r2 | 50.09-r3rc3 pre-release (with Linux support)
Post by: A_Curious_Cat on September 01, 2023, 11:48:09 pm
Both `steam-engine` and `building-hacks` are plugins that affect buildings, but they are not the same. Much of the low level logic will probably still work for both plugins, but the UI components will need a makeover.

Ok.  I was mainly asking if building-hacks could be used to reimplement steam-engine.

Edit:

After looking at it, I think the problem is in getting a non-magma-based “steam-engine” to start producing power whenever a custom reaction starts and stop producing power a certain number of ticks after the reaction ends (with the possibility of continuous power output if a new reaction is started quickly enough).  My suggestion is to rename mod-tools/reaction-trigger to mod-tools/reaction-trigger-end and add an option to have it optionally trigger a certain number of ticks after the reaction completes, as well as to add a new tool called mod-tools/reaction-trigger-start that would run commands when a reaction was started.

Edit2:

Just realized that mod-tools/reaction-trigger is UNAVAILABLE.  still might be a good idea though.  On third thought, I think what’s needed is to extend eventful to include an onReactionStarting() event.  Now if only there was a way to get DFHack to run Lua code when a mod was loaded…
Title: Re: DFHack 50.09-r2 | 50.09-r3rc3 pre-release (with Linux support)
Post by: myk on September 02, 2023, 03:09:28 am
DFHack provides an API for triggering a callback after a certain number of ticks: dfhack.timeout(), so I don't think it would be that hard to schedule something to happen some time in the future (though timeout callbacks are *not* persisted with the save, so the mod would have to take care of that and reload callbacks as necessary on load).

It's also not hard for a mod to run code on load -- that's how all the enableable lua scripts work. They add a callback to the state change handler and enable themselves if they were enabled the last time the game was saved. The DFHack modding guide gives some examples for this. https://docs.dfhack.org/en/latest/docs/guides/modding-guide.html#putting-it-all-together
Title: Re: DFHack 50.09-r2 | 50.09-r3rc3 pre-release (with Linux support)
Post by: Clément on September 03, 2023, 06:56:14 am
How do you get the linux version? I have switched both DF and DFHack to "beta" branch in Steam, but it is still running in wine (and crashing). Steam Play is not forced.

Edit: Forcing Steam Linux Runtime, solved it.
Title: Re: DFHack 50.09-r2 | 50.09-r3rc3 pre-release (with Linux support)
Post by: myk on September 03, 2023, 07:44:39 am
I've found that sometimes you need to switch the compatibility layer settings on and off a few times before Steam will "stick" to giving you the Linux version. Force it back to proton, then disable it again, and see if that triggers a "downloading update" progress bar.
Title: Re: DFHack 50.09-r2 | 50.09-r3rc3 pre-release (with Linux support)
Post by: Ineth Grumblepot on September 04, 2023, 08:13:33 am
I'm using the 50.09-r2 Steam version of DFHack with the Steam version of the game.

When I try to use "createitem item" with a bag selected, I get this message: "The selected item cannot be used for item storage!"

Does the Steam version of createitem not work with bags, or have I managed to corrupt bags somehow? I can't see this posted anywhere else so I'm thinking I must be doing something wrong.

(Many thanks for any replies and sorry if I've posted this in the wrong place)
Title: Re: DFHack 50.09-r2 | 50.09-r3rc3 pre-release (with Linux support)
Post by: myk on September 04, 2023, 12:33:18 pm
Bags got their own item type in DF v50. It wouldn't surprise me if createitem needs a small update to recognize them again. Could you file an issue on GitHub? https://github.com/DFHack/dfhack/issues
Title: Re: DFHack 50.09-r2 | 50.09-r3rc3 pre-release (with Linux support)
Post by: Ineth Grumblepot on September 04, 2023, 01:09:47 pm
@myk I followed your link and had a go at submitting one. As someone used to TeamCity, I was a bit surprised by the way it didn't immediately fall over and catch fire.

Thank you for the help, by the way.
Title: Re: DFHack 50.09-r2 | 50.09-r3rc3 pre-release (with Linux support)
Post by: myk on September 05, 2023, 03:44:22 am
Absolutely -- and thank you for the bug report. It was an easy fix, and will be in the next release (later this week)
Title: Re: DFHack 50.09-r2 | 50.09-r3rc3 pre-release (with Linux support)
Post by: myk on September 07, 2023, 12:09:54 pm
DFHack 50.09-r3 released!

Get it here: https://github.com/DFHack/dfhack/releases/tag/50.09-r3

Or install from Steam: https://store.steampowered.com/app/2346660/DFHack
Title: Re: DFHack 50.09-r3 (with Linux support)
Post by: Saiko Kila on September 08, 2023, 02:34:25 pm
Has it started crashing for anyone else with DFHack 50.09-r3? It crashes when I load my fort (Windows, Steam version).

I allowed a debugger (Visual Studio Just-In Time Debugger), which showed me there are problems with seedwatch.plug.dll. When I delete the file, my fort loads without crashing. When I restore the file, Dwarf Fortress crashes upon loading the fort. I don't use the plugin as far as I know, but it still causes the crash somehow.

Title: Re: DFHack 50.09-r3 (with Linux support)
Post by: myk on September 09, 2023, 12:48:38 am
We did make a small change to the seedwatch plugin, but I haven't seen any crashes with it. Do you have any mods installed? Could you possibly zip up the savegame that crashes (plus your mods directory) so we can take a look at it?
Title: Re: DFHack 50.09-r3 (with Linux support)
Post by: Saiko Kila on September 09, 2023, 03:22:25 am
We did make a small change to the seedwatch plugin, but I haven't seen any crashes with it. Do you have any mods installed? Could you possibly zip up the savegame that crashes (plus your mods directory) so we can take a look at it?

I have uploaded the save file. My mod directory is empty, so no mods here.

https://dffd.bay12games.com/file.php?id=16837 (https://dffd.bay12games.com/file.php?id=16837)
Title: Re: DFHack 50.09-r3 (with Linux support)
Post by: myk on September 09, 2023, 09:33:38 am
Crash confirmed. Thanks! I'm looking into it.
Title: Re: DFHack 50.09-r3 (with Linux support)
Post by: myk on September 09, 2023, 09:43:13 am
Ok, this appears to be caused by a bad data migration from earlier versions of seedwatch. You can fix it by editing the dfhack-legacy-data.dat file in the savegame directory and removing all the seedwatch/seed data elements. That is, remove all the elements that look like this:
Code: [Select]
    {
        "i" :
        [
            -1,
            30,
            -1,
            -1,
            -1,
            -1,
            -1
        ],
        "k" : "seedwatch/seed/34",
        "s" : ""
    },

We'll get this fixed properly for the next release. Thank you very much, and sorry for the frustration!
Title: Re: DFHack 50.09-r3 (with Linux support)
Post by: Saiko Kila on September 09, 2023, 03:33:02 pm
Thank you myk! Somehow editing the active savefile caused me such error "One of the compressed files on disk has errors in it. Restore from backup if you are able.", but editing older, manual saves (including the one I uploaded), doesn't produce this and works. I'm mentioning this for completeness sake, because the active save was only a minimally never than the other save, so nothing lost, but a bit curious why could that be.
Title: Re: DFHack 50.09-r3 (with Linux support)
Post by: myk on September 09, 2023, 06:04:05 pm
DF would only give that error if one of the core vanilla files (like world.sav) failed to decompress properly. The dfhack-legacy-data.dat file is completely separate and *shouldn't* have any way of causing that error, even if was corrupted itself. DFHack would show an error, but DF doesn't read it.

So in short, I have no idea what's going on with that, but I am glad that no significant playtime was lost!
Title: Re: DFHack 50.09-r3 (with Linux support)
Post by: Saiko Kila on September 10, 2023, 11:57:26 am
Yeah, I thought that maybe it keeps some checksum of files from save listed as active (for some reason) and thus the error, but maybe it's just a one-off corruption or whatever. Anyway, I'm glad it works now :)
Title: Re: DFHack 50.09-r1
Post by: myk on September 14, 2023, 03:46:30 pm
DFHack 50.09-r4 released!

Get it here: https://github.com/DFHack/dfhack/releases/tag/50.09-r4

Or install from Steam: https://store.steampowered.com/app/2346660/DFHack

DFHack 50.10-beta1 also available on Steam in the 50.10-beta release branch or at GitHub here: https://github.com/DFHack/dfhack/releases/tag/50.10-beta1
Title: Re: DFHack 50.09-r3 (with Linux support)
Post by: Roses on September 14, 2023, 09:58:15 pm
So I'm finally thinking about getting back into DF and continuing the modding I was previously doing. I'm trying to catch up on all the changes (amazing work everyone!) But just wanted to check, is the LUA API reference stuff up to date? I use the function wrappers and plugins quite a lot and just wanted to make sure.
Title: Re: DFHack 50.09-r4 | 50.10-beta1 (pre-release) (with Linux support)
Post by: myk on September 15, 2023, 12:08:30 am
Welcome back! Yes, we have carefully kept the Lua API docs up to date. The largest changes have been in the gui and gui.widgets namespaces. The bulk of the C++ module APIs have stayed largely the same. Plugins, on the other hand, have seen a lot of changes, and not all of them have been updated for v50 yet.
Title: Re: DFHack 50.09-r4 | 50.10-beta1 (pre-release) (with Linux support)
Post by: Roses on September 15, 2023, 05:22:47 pm
Interesting. Do you know if the eventful plugins have been updated for v50?
Title: Re: DFHack 50.09-r4 | 50.10-beta1 (pre-release) (with Linux support)
Post by: myk on September 15, 2023, 06:05:44 pm
eventful has had some additions, but it hasn't needed any v50-specific changes. I haven't personally verified that the Lua-only events function as expected, though, just the ones from EventManager.
Title: Re: DFHack 50.09-r4 | 50.10-beta1 (pre-release) (with Linux support)
Post by: Roses on September 16, 2023, 11:27:48 pm
Sounds like a perfect place for me to start. Luckily I wrote a bunch of tests for my stuff before I stepped away so I should be able to help track down what is still working, and what needs updates.
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: lethosor on September 19, 2023, 12:13:29 pm
DFHack 50.10-r1 released!

Full support for all 50.10 releases, including Linux.

Get it from:

Full installation instructions: https://docs.dfhack.org/en/latest/docs/Installing.html
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: lethosor on September 19, 2023, 05:52:20 pm
r1.1 has been put up on GitHub, which fixes a crash on startup with the Windows Itch build of DF. Everything else is identical to 50.10-r1.

GitHub download: https://github.com/DFHack/dfhack/releases/tag/50.10-r1.1

(This release has not been put up on Steam because it doesn't affect Steam DF.)
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: Clément on September 20, 2023, 10:10:13 am
Has ASLR been removed from the latest linux versions? I read somewhere it was an issue for dfhack. Did you ask for it to be removed? Do we know if it will stay that way? I wrote some code for it in DT during the beta, but it is broken now (the base address changed). I'd like to know if I should fix that code or if I should just throw it away as it won't be needed.
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: myk on September 20, 2023, 11:46:36 am
We worked with bay 12 to build with the -nopie GCC flag, so ASLR on Linux should be gone for now. It *may* return in the future, of course, but I'm not aware of any immediate reason for why it should.
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: thefinn on September 20, 2023, 05:07:50 pm
Sometimes you just want to create a quantum stockpile of something like copper bars or steel bars - simply so you can see what you have easily.

Does anyone have a macro or command or something to empty all the bins with bars (or more specific bars) in them all at once?

It's a total pain trying to find all the bar bins. (Same with cloth and lots of other things)

If not that's ok ;)

Thanks.

(Sorry, is this the right place to ask this?)
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: myk on September 21, 2023, 01:01:53 am
Here's a Lua script that will empty bars out of bins:
Code: [Select]
local count = 0
for _, item in ipairs(df.global.world.items.other.BAR) do
    if not item.flags.in_inventory then goto continue end
    local gref = dfhack.items.getGeneralRef(item, df.general_ref_type.CONTAINED_IN_ITEM)
    if not gref then goto continue end
    local bin = df.item.find(gref.item_id)
    if not bin or not df.item_binst:is_instance(bin) then goto continue end
    if dfhack.items.moveToGround(item, bin.pos) then count = count + 1 end
    ::continue::
end
print(('dumped %d bar(s) out of bins'):format(count))
If you save that into a file named dfhack-config/scripts/barbin.lua, you can run it by running barbin in the DFHack command launcher.
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: 0x517A5D on September 21, 2023, 01:02:47 pm
Huh.  I thought item.flags.in_inventory specifically meant that it's in a unit's inventory.  I guess it's overloaded?

I guess that's one way to implement the nonexistent continue keyword.  I didn't even know that Lua has goto.
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: thefinn on September 21, 2023, 06:26:41 pm
If you save that into a file named dfhack-config/scripts/barbin.lua, you can run it by running barbin in the DFHack command launcher.

Truly, a prince among men.
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: joostheger on September 22, 2023, 07:17:22 am
Hi all, I'am new to dfhack, its a great adventure to dive into this!

Question: I'd like to run a onMapLoad.init with a event-subscription to some reaction-trigger for my mod.
I know I have to place stuff into my mod-main folder, with the Objects, Graphics, Info.txt and so on. I've creature-raws and stuff
But the dfhack documentation says that I need to place the onMapLoad.init in the dfhack-config/init folder.
Can I  pack these into my main mod somehow? How can I deploy my init-files together with my main mod?
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: joostheger on September 22, 2023, 11:49:12 am
Never mind, got it working by following the tutorial.
What a joy!
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: myk on September 22, 2023, 05:58:38 pm
I'm always happy to hear when the documentation helps ; )

If you have any trouble getting things to work, just ask!
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: joostheger on September 23, 2023, 01:28:00 am
Are you one of its writers? Its great! I learned really a lot ladt night!

I have some little things.
I had trouble with running a modtools command. Can you apply one in the tutorial?
Further: I missed the definition of the variable modId in the final example.
Lastly: de mod deactivates by closing the game, but doesnt reactivatie. Id like to have my script always active, if my main mod is loaded .
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: Martenzo on September 23, 2023, 01:55:06 am
Hey, having problems with getting dfhack running on Linux Mint. Obviously, the libc and libc++ libraries I have installed are the wrong version, but at this point it seems I've tried everything reasonable that I can install and upgrade through my package manager. I do have the Linux version of DF installed, based on the "dwarfort" executable rather than "Dwarf Fortress.exe" test mentioned in the install instructions. And yet this keep being the result of launching dfhack:

Code: [Select]
SteamLibrary/steamapps/common/Dwarf Fortress$ ./dfhack
./dwarfort: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./dwarfort)
./dwarfort: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./dwarfort)
./dwarfort: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ./dwarfort)
./dwarfort: /lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.13' not found (required by ./dwarfort)
./dwarfort: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./hack/libdfhack.so)
./dwarfort: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./hack/libdfhack.so)
./dwarfort: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by ./hack/libdfhack.so)
./dwarfort: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./libg_src_lib.so)
./dwarfort: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./libg_src_lib.so)
./dwarfort: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./libg_src_lib.so)
./dwarfort: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ./libg_src_lib.so)
./dwarfort: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by ./libg_src_lib.so)
./dwarfort: /lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.13' not found (required by ./libg_src_lib.so)
./dwarfort: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by hack/libprotobuf-lite.so)
./dwarfort: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by hack/liblua.so)

/lib/x86_64-linux-gnu/libc.so.6 does exist, but is apparently not the right version. Any suggestions for where I could dig further to sort this out?
EDIT: Ah goddamit, I'm probably looking at upgrading my distro to the next major version. Because apparently manually forcing an update to glibc is a sure-fire way to experience Fun in the DF sense of the word on Linux.
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: Clément on September 23, 2023, 05:49:20 am
I guess it does not work without dfhack either (GLIBC_2.34 is required by dwarfort, not only libdfhack.so). According to distrowatch, Linux Mint 21.2 Victoria (released two month ago) has glibc 2.35. I guess you have Linux Mint 20.3 Una from 2022, it only has glibc 2.31. It's not that old, DF should have been built using an older version.

Edit: Ubuntu 20.04 uses glibc 2.31, so it is older than 2022. Still, it should be the best target version.
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: myk on September 23, 2023, 12:34:58 pm
EDIT: Ah goddamit, I'm probably looking at upgrading my distro to the next major version. Because apparently manually forcing an update to glibc is a sure-fire way to experience Fun in the DF sense of the word on Linux.
It's not that old, DF should have been built using an older version.

Yeah, we're working with Bay 12 to standardize on a more widely compatible build environment. It's not as easy as just switching build systems, though, since DF actually *uses* functionality only available in more recent versions of glibc and the c++ standard library.

I had trouble with running a modtools command. Can you apply one in the tutorial?
any script can be run with the dfhack.run_script() command, modtools or otherwise (see https://docs.dfhack.org/en/latest/docs/dev/Lua%20API.html#general-script-api). Which one were you having trouble running? Does the script have the "unavailable" tag (https://docs.dfhack.org/en/stable/unavailable-tag-index.html#cap-m )? If so, it hasn't been updated yet and you can't expect it to work.

Quote
I missed the definition of the variable modId in the final example.
It's just a string that's set to the name of your mod. There are a few examples of the variable being set in the modding guide. Ctrl-F for "modid".

Quote
de mod deactivates by closing the game, but doesnt reactivatie. Id like to have my script always active, if my main mod is loaded .
This is what the onStateChange handler is for in https://docs.dfhack.org/en/stable/docs/guides/modding-guide.html#putting-it-all-together
There's more information about this mechanism here: https://docs.dfhack.org/en/latest/docs/dev/Lua%20API.html#enabling-and-disabling-scripts
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: ab9rf on September 25, 2023, 06:21:22 pm
I guess it does not work without dfhack either (GLIBC_2.34 is required by dwarfort, not only libdfhack.so). According to distrowatch, Linux Mint 21.2 Victoria (released two month ago) has glibc 2.35. I guess you have Linux Mint 20.3 Una from 2022, it only has glibc 2.31. It's not that old, DF should have been built using an older version.

Edit: Ubuntu 20.04 uses glibc 2.31, so it is older than 2022. Still, it should be the best target version.
if i understand what i've heard correctly, the dwarf fortress linux builds were built using Ubuntu 22.04, so you need to be at least as new as Ubuntu 22.04 to ride this particular ride.

the problem with using, e.g. Ubuntu 20.04 for doing builds is that the gcc in that release is too old to compile Dwarf Fortress. DF uses C++17 and C++20 (and even C++23, but only on Windows at present) features that are not implemented in the version of gcc that ships with Ubuntu 20.04 LTS. from my understanding, there simply isn't a gcc release that both supports the C++ features that DF uses and is also compatible with any glibc older than 2.34. last i heard there was some experimentation around using clang, but that too was not conclusive
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: Clément on September 26, 2023, 11:02:59 am
Using flatpak runtime 22.08 can be solution for older distributions. I managed to run DF+DFHack on Linux Mint 20.3 (in a vm) with it.

Spoiler: How to (click to show/hide)

There are issues with flatpak though: since DF is no longer redistributable, I cannot share the built package, and the lack of support for XDG directories make it require some tricks to work (and I may be missing some writable directories, I did not do much testing).
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: myk on October 03, 2023, 12:09:10 pm
DFHack 50.11-r1 released!

Full support for all 50.11 releases, including Linux.

Get it from:

Full installation instructions: https://docs.dfhack.org/en/latest/docs/Installing.html
Title: Re: DFHack 50.11-r1 | 50.11-r2rc1 (pre-release)
Post by: myk on October 12, 2023, 03:41:56 pm
DFHack 50.11-r2rc1 released!

Full support for all 50.11 releases. Highlight: Search! Search! Search!

Get it from:

Full installation instructions: https://docs.dfhack.org/en/latest/docs/Installing.html
Title: Re: DFHack 50.11-r1 | 50.11-r2rc1 (pre-release)
Post by: Crystalizedmire on October 18, 2023, 02:57:53 pm
Is there any way of using DFHack to turn my dwarves into vampires?
Title: Re: DFHack 50.11-r1 | 50.11-r2rc1 (pre-release)
Post by: myk on October 18, 2023, 03:40:50 pm
Since vampire curses are generated anew with each world, the process for making a unit a vampire is not as straightforward as it could be. It helps a great deal if you already have a vampire accessible that you can examine. Then you can:
1. use gui/unit-syndromes to examine the vampire and take note of the syndrome ID that unit is afflicted with
2. use modtools/add-syndrome to apply that syndrome to the unit of your choice

If you don't have a vampire unit yet, maybe save your game, run migrants-now until you get a migrant vampire (use cursecheck to identify them), examine them with gui/unit-syndromes to get the syndrome ID, then load back your original save and modify your other unit.

docs are here: https://docs.dfhack.org/en/stable/docs/tools/modtools/add-syndrome.html#modtools-add-syndrome
Title: Re: DFHack 50.11-r1 | 50.11-r2rc1 (pre-release)
Post by: myk on October 19, 2023, 10:06:55 am
DFHack 50.11-r2 released!

Full support for all DF 50.11 releases.

Highlights: Search! Search! Search!, Preserve tomb assignments, Collapse all for stocks screen, Automatic tomb zones, Stranded citizen alert

Get it from:

Full installation instructions: https://docs.dfhack.org/en/latest/docs/Installing.html
Title: Re: DFHack 50.11-r1 | 50.11-r2rc1 (pre-release)
Post by: Bumber on October 19, 2023, 07:15:27 pm
If you don't have a vampire unit yet, maybe save your game, run migrants-now until you get a migrant vampire (use cursecheck to identify them), examine them with gui/unit-syndromes to get the syndrome ID, then load back your original save and modify your other unit.

This will print the IDs of all vampire syndromes in the world:
Code: [Select]
:lua for k,v in ipairs(world.raws.syndromes.all) do for a,b in ipairs(v.ce) do if df.creature_interaction_effect_add_simple_flagst:is_instance(b) and b.tags1.BLOODSUCKER then print(k) end end end
Title: Re: DFHack 50.11-r2
Post by: myk on October 19, 2023, 07:58:39 pm
Oh nice, I could integrate that into `gui/sandbox` so you can spawn vampire/necromancer/whatever units directly.
Title: Re: DFHack 50.11-r2
Post by: yamster on October 22, 2023, 12:57:57 am
Is there a way to use spawn cut gems or polished stones in a specific design?
Title: Re: DFHack 50.11-r2
Post by: Rumrusher on October 25, 2023, 05:35:06 am
ok so kinda been working on a script that lets one swap sites, so far it seem mostly useful for switching on to pre-gen sites,

(https://cdn.discordapp.com/attachments/302956330304667649/1166682447556124713/siteswap-11-showcase2.gif)

Code: (siteswap.lua) [Select]
local nomad={}
local dlg=require("gui.dialogs")

local h_ent=nil
--local test= tonumber(...)

function teleportboatnames3()
local Ark={}
for k,v in pairs(df.global.world.world_data.sites) do
BoaName=dfhack.TranslateName(v.name, true)
table.insert (Ark,{dfhack.TranslateName(v.name, true).." "..v.name.nickname,nil,v,search_key = BoaName:lower()})
end
local f=function(Name,C)
  WarpEntityNames(C[3])
end
dlg.showListPrompt("list of stations","Select Station(s) to settle here",COLOR_WHITE,Ark,f,nil,nil,true)
end

function WarpEntityNames(Siteid)
local entity=Siteid.entity_links
local Ark1={}
for k1,v1 in pairs(entity) do
local BoaName1=dfhack.TranslateName(df.global.world.entities.all[v1.entity_id].name, true)
table.insert (Ark1,{dfhack.TranslateName(df.global.world.entities.all[v1.entity_id].name, true).." "..df.global.world.entities.all[v1.entity_id].name.nickname,nil,v1.entity_id,search_key = BoaName1:lower()})
end
local f=function(Name,C)
  unretire_all(C[3],Siteid)
end
dlg.showListPrompt("list of groups","Select group(s) to switch here",COLOR_WHITE,Ark1,f,nil,nil,true)
end


function stationmove()
if df.global.gview.view.child.child==nil then
print("this script requires you to be in the raid menu to work")
else
teleportboatnames3()
end
end


function MouseSeek3(siteID)
for x,y in pairs(df.global.world.entities.all) do
for x2,y2 in pairs(siteID) do
if y.name.first_name=="CREW" and y.id==y2.entity_id then
local EntMouse2=y2.entity_id
if y2.former_flag.residence==true then
y2.former_flag.residence=false
y2.flags.residence=true
end
return EntMouse2
end
end
end
end
function MouseSeek4(siteID)
for x,y in pairs(siteID) do
if y.flags.land_for_holding==true then
local EntMouse3=y.entity_id
print(EntMouse3)
return EntMouse3
end
if y.former_flag.land_for_holding==true then
y.former_flag.land_for_holding=false
y.flags.land_for_holding=true

end
end
end
function unretire_all(enti,siteID)
local Selectpark=df.global.world.entities.all[enti]
if df.global.plotinfo.main.fortress_entity~=nil or df.global.plotinfo.main.fortress_site~=nil then
df.global.plotinfo.main.fortress_entity=nil
df.global.plotinfo.main.fortress_site=nil
end
df.global.plotinfo.main.fortress_site=siteID
df.global.plotinfo.main.fortress_entity=Selectpark
df.global.plotinfo.site_id=siteID.id
df.global.plotinfo.group_id=enti
if MouseSeek4(siteID.entity_links)==nil then
df.global.plotinfo.civ_id=enti else
df.global.plotinfo.civ_id=MouseSeek4(siteID.entity_links)
end

aftermath()
end

function DeresidentAll(unit,trgunit)
for k,v in pairs(df.global.world.units.active) do
if v== nil then
error("Invalid creature")
end
v.flags2.resident=false
end
return true
end

function clearpopups()
df.global.world.status.popups:resize(0)
df.global.game.main_interface.options.open=false
df.global.game.main_interface.options.context=0
df.global.plotinfo.game_over=false
end

teleportboatnames3()
function aftermath()
df.global.cur_season_tick=3998
dfhack.gui.getCurViewscreen():feed_key(2)
 df.global.pause_state=false
print("unpaused", df.global.enabler.frame_last)
df.global.pause_state=false
if df.global.pause_state==true then
df.global.pause_state=false
end
dfhack.timeout(20,"frames",function() df.global.pause_state=false  end)
dfhack.timeout(33,"frames",function() df.global.pause_state=true DeresidentAll() print("unpaused") end)
dfhack.timeout(40,"frames",function() df.global.pause_state=true DeresidentAll()  clearpopups() print("unpaused") end)
dfhack.timeout(100,"frames",function() df.global.pause_state=true DeresidentAll()  clearpopups() print("unpaused") end)
dfhack.timeout(500,"frames",function() df.global.pause_state=true DeresidentAll()  clearpopups() print("unpaused") end)
dfhack.timeout(1,"ticks",function() dfhack.gui.getCurViewscreen():feed_key(278)
 DeresidentAll()

print("paused",  df.global.enabler.frame_last) end)
end


so you might also need these

Code: (clearpopups.lua) [Select]
function clearpopups()
df.global.world.status.popups:resize(0)
df.global.game.main_interface.options.open=false
df.global.game.main_interface.options.context=0
df.global.plotinfo.game_over=false
end
clearpopups()

Code: (deresident.lua) [Select]
function DeresidentAll(unit,trgunit)
for k,v in pairs(df.global.world.units.active) do
if v== nil then
error("Invalid creature")
end
v.flags2.resident=false
end
return true
end
dfhack.gui.getCurViewscreen():feed_key(278)
print("unpaused")
df.global.pause_state=false
dfhack.timeout(1,"ticks",function()  end)
 DeresidentAll()
 print("paused")

these two are already in the main script but I spent a bit too long trying to bypass the game over screen and the process on how I did that was toggling the entire site to have the resident unit flag off and clearing the prompt off the screen which these two scripts will do... the one for clearing the screen is the clearpopups one and the hopefully working toggle off residence unit flag so you can get citizens again is the second one.

will note this is extremely unstable in that expect repercussions of bypassing the game over screen every time you jump to a new site, swapping to a player fort might require using revflood and moving the camera to the game field.
oh yeah be careful with loading in a 17x17 size sites(towns, hamlets, hilltops, forest retreats, dark fortresses, dark pits, mountain halls) you might eat all your ram and memory trying to load those sites.
it best to have a pc with like 30 gigs of ram or something beefy to handle like 8 gigs being used on the spot for memory.

if you got like a reveal all sites script you could gain access to reading the names of camps and have a chance at loading into those also.

oh and another thing if you're playing a vanilla raw expect none of the noble stuff to work or partially working if you jump into any non dwarf entity group and expect it to mostly to not work if you land on a dwarven one.
in comparison to the nomad and void fort scripts this one a bit more sandbox-like given complete control over the civs you generated than just your dwarves/modded in civilizations.
so learn how it feels to control a necro tower then realize you got no pick or axe or anvil.

any way here's body swap but for sites.
Title: Re: DFHack 50.11-r2
Post by: joostheger on October 25, 2023, 01:48:51 pm
Question:

where can i find the content of some enums of df-structures, like:
unit_labor
entity_position_responsibility

which are which.
wiki doesnt seem to be complete, because dfstructures mentions 94 labors, but wiki mentions 80
Title: Re: DFHack 50.11-r2
Post by: Clément on October 25, 2023, 02:03:41 pm
Use the search function on github, or download it and search locally. Some unit_labor values are unused.

unit_labor (https://github.com/DFHack/df-structures/blob/b9c0733e943fb0d22a6717596128b8d44ba4ce04/df.skills.xml#L841)
entity_position_responsibility (https://github.com/DFHack/df-structures/blob/b9c0733e943fb0d22a6717596128b8d44ba4ce04/df.entity-raws.xml#L395)
Title: Re: DFHack 50.11-r2
Post by: myk on October 25, 2023, 02:19:24 pm
You can also list them in-game. For example, open gui/launcher and run:

Code: [Select]
:lua @df.unit_labor
Title: Re: DFHack 50.11-r2
Post by: A_Curious_Cat on October 25, 2023, 08:47:27 pm


I will investigate if I'm able to do so only when DF becomes playable, i.e. keyboard support is returned. That doesn't stop mouse tolerant people to take up the task earlier, as this is part of DFHack.

I can mention two things here:
- The biome determination logic was changed prior to the Premium release, so some biome determinations were incorrect. The underlying logic could use an update, although it's no longer part of this plugin itself. The differences were not huge, but present.
- I've noticed that mousing around pre embark causes mid level tiles to get loaded, so once you can order the cursor to move with keyboard input again you should be able to load all of this info into memory before performing any processing, thus removing issues with having to cache information and processing the data in two passes. It can be noted that the information is loaded unordered, but that can be handled e.g. with an intermediate coordinate translation matrix.

Any chance of anyone who knows Lua and isn’t mouse-adverse updating embark-assistant for 50.x?  Also, I searched DFHack/scripts on GitHub for the embark-assistant script but couldn’t find it…
Title: Re: DFHack 50.11-r2
Post by: myk on October 25, 2023, 11:09:21 pm
It's a c++ plugin, though it's possible it could be rewritten in Lua. Source code is here: https://github.com/DFHack/dfhack/tree/develop/plugins/embark-assistant

Note that it's an entire directory of files, not just one.
Title: Re: DFHack 50.11-r2
Post by: A_Curious_Cat on October 26, 2023, 01:40:49 am
Interesting.  I thought it was in Lua.  I was asking about other people who knew Lua because I don’t know it and I’m currently learning C++ (and learning two programming languages at once is a bad idea…).  Anyways, I took a look at embark-assistant.cpp, and it’s chock  full of stuff I haven’t learned about yet (although, I have noticed that it uses ‘#pragma once’ in the header files, which the site I’m learning from recommends against as it makes the program non-portable, recommending a “header guard” using #ifdef, #define, and #endif instead).
Title: Re: DFHack 50.11-r2
Post by: joostheger on October 26, 2023, 02:19:50 am
You can also list them in-game. For example, open gui/launcher and run:

Code: [Select]
:lua @df.unit_labor
thanks! exaclty what i needed
Title: Re: DFHack 50.11-r2
Post by: PatrikLundell on October 26, 2023, 03:53:02 am
The reason embark-assistant is written in code rather than as a script is performance. My prototype was written in Lua, but as I expected from the start, the performance was completely unacceptable. It's was slow enough when compiled (although the majority of the time in the compiled code was spent loading DF data structures done by DF itself: I don't know how the current, changed, data loading logic of DF will affect this).
Title: Re: DFHack 50.11-r2
Post by: myk on October 26, 2023, 10:31:47 am
I've been collecting thoughts on how embark-assistant can be updated here: https://github.com/DFHack/dfhack/issues/3327

tl;dr we might be able to hook into the new vanilla site search interface and algorithm to extend it rather than replace it.
Title: Re: DFHack 50.11-r2
Post by: lethosor on October 26, 2023, 08:22:04 pm
Interesting.  I thought it was in Lua.  I was asking about other people who knew Lua because I don’t know it and I’m currently learning C++ (and learning two programming languages at once is a bad idea…).  Anyways, I took a look at embark-assistant.cpp, and it’s chock  full of stuff I haven’t learned about yet (although, I have noticed that it uses ‘#pragma once’ in the header files, which the site I’m learning from recommends against as it makes the program non-portable, recommending a “header guard” using #ifdef, #define, and #endif instead).

We use "#pragma once" because it's portable enough for our purposes. All compilers we use support it, and we are limited to those specific compilers because DF uses them. it has a couple advantages over header guards - it's harder to make mistakes (e.g. by forgetting one of the three lines a header guard requires), and it's guaranteed to avoid name conflicts with header guards using the same name.
Title: Re: DFHack 50.11-r2
Post by: A_Curious_Cat on October 26, 2023, 09:46:08 pm
Interesting.  I thought it was in Lua.  I was asking about other people who knew Lua because I don’t know it and I’m currently learning C++ (and learning two programming languages at once is a bad idea…).  Anyways, I took a look at embark-assistant.cpp, and it’s chock  full of stuff I haven’t learned about yet (although, I have noticed that it uses ‘#pragma once’ in the header files, which the site I’m learning from recommends against as it makes the program non-portable, recommending a “header guard” using #ifdef, #define, and #endif instead).

We use "#pragma once" because it's portable enough for our purposes. All compilers we use support it, and we are limited to those specific compilers because DF uses them. it has a couple advantages over header guards - it's harder to make mistakes (e.g. by forgetting one of the three lines a header guard requires), and it's guaranteed to avoid name conflicts with header guards using the same name.

Interesting.  I guess that makes sense.

Also, out of curiosity, what are the compilers that DFHack uses?
Title: Re: DFHack 50.11-r2
Post by: myk on October 26, 2023, 11:20:25 pm
Currently, we compile with latest MSVC on Windows and GCC 10 on Linux. We also run additional tests with GCC 12.
Title: Re: DFHack 50.11-r2
Post by: joostheger on October 31, 2023, 04:41:38 am
Is there a script to elevate a fortress, or to trigger elevation in some way?
Title: Re: DFHack 50.11-r2
Post by: Roses on October 31, 2023, 01:00:24 pm
I've got to say, I am very impressed with the amount of work that seems to have gone into the many many changes since I was last active. I have been spending a lot of time reading the documentation and looking through examples and it has been very exciting. I am sure I am going to have more and more questions as I read more, but the following are some of the first questions that have come to my mind.

List of Questions:
Code: [Select]
[ITEM_SHIELD:ITEM_SHIELD_EXAMPLE]
[NAME:Example Shield]
{DESCRIPTION:Knocks enemy backwards half the time when you block}
... DF Item Stuff ...
{ON_BLOCK}
{SCRIPT:unit/propel -unit OPPONENT -source BLOCKER -velocity [ 50 50 0 ] -mode Relative:50}

[ITEM_WEAPON:RAPID_FIRE_CROSSBOW]
[NAME:Fast Shooting Crossbow]
{DESCRIPTION:Shoots bolts very fast}
... DF Item Stuff ...
{FIRE_RATE:10:2:1} -- Base fire rate is 10, increases by 2 for each skill level, max shot speed is 1

[ITEM_WEAPON:BLOOD_SWORD]
[NAME:Blood Sword]
{DESCRIPTION:Drains blood from opponent when wounded}
... DF Item Stuff ...
{ON_WOUND}
{SCRIPT:unit/change-body -unit OPPONENT -blood \-10:100}
{SCRIPT:unit/change-body -unit HOLDER -blood 10:100}

I think that is good for now. I am sure that as I get deeper into getting my old codes running I will have more questions.
Title: Re: DFHack 50.11-r2
Post by: myk on October 31, 2023, 03:43:42 pm
I will defer to Tachytaenius for questions on custom-raw-tokens, but I can answer the others:

> are there any limitations in the new system that weren't in the previous?

Not that I know of. To my knowledge (which isn't complete) the syntax and capabilities of the raws have not changed

> Are subfolders still allowed, or does everything have to be flat in scripts_modactive and scripts_modactive/internal?

The folder structure under the scripts directories is up to you. DFHack essentially adds scripts_modinstalled and scripts_modactive to its script search path, and script modules can be organized however you like. Scripts in the internal subdirectory won't clutter up the autocomplete list in ls or gui/launcher and cannot be run by the player, but they can still be reqscript'd from your top-level scripts.

> saved a lua table to a json file ... or used persist-table... Is this still the best way to handle persistant data storage and function callbacks?

Persisting data to json manually (for state not tied to a savegame) or with persist-table (for savegame state) are still the best options. The biggest related change is how you reload on start. Before, the player had to manually invoke a script or you had to specifically start your script from an init file. Now, all (non-internal) scripts that declare themselves to be module loadable are parsed at game start (and again before the game is loaded). You can reload your state (including whether your script was enabled, if it can be enabled/disabled) in a callback hook attached to dfhack.onStateChange. A good, simple example is emigration.lua, which stores state with the savegame via persist-table and restores its enabled state on game load: https://github.com/DFHack/scripts/blob/master/emigration.lua

> Syndromes

Syndromes haven't changed since 0.47. I don't have a lot of experience with using them for actual modding, but to my knowledge, they're still the best way to apply unit based modifications.

> I am wondering if there has been any work on the DFHack side of things to track things like custom DF structures.

Even if DFHack adds to the structures or extends the enum values, it's DF that will be interpreting them. Adding new enum values, for example, might cause DF to take unexpected paths through switch statements. I don't think this can be supported. I think a safer architecture would be to keep your own mapping of units to extended attributes and reference that map when you need to make a decision based on the value for a unit.

> Custom Files - Where should custom files that aren't technically raw objects or scripts go?

You can distribute whatever files you want in a mod, even when it is distributed via the Steam Workshop. You can look up your mod source path in df.global.world.object_loader.object_load_order_src_dir. You shouldn't write there, though. Dynamic data/configuration can be saved to dfhack-config/mods/yourmodid/somefile
Title: Re: DFHack 50.11-r2
Post by: myk on October 31, 2023, 03:53:43 pm
Is there a script to elevate a fortress, or to trigger elevation in some way?

do you mean change the displayed elevation relative to sea level? or do you mean physically transporting it to a different z-level?
Title: Re: DFHack 50.11-r2
Post by: joostheger on October 31, 2023, 04:06:10 pm
Is there a script to elevate a fortress, or to trigger elevation in some way?

do you mean change the displayed elevation relative to sea level? or do you mean physically transporting it to a different z-level?
sorry for the vagueness :-)
Elevating a site to barony or to county or duchy. So land_holder comes and stuff.
Title: Re: DFHack 50.11-r2
Post by: myk on October 31, 2023, 04:41:57 pm
Ha, boy did I interpret that incorrectly : P

We've looked into it, and while it is very feasible to *replace* a baron or other noble, elevating a site from scratch is much trickier and may not be safe to do with our current understanding. If you're a member of the DFHack discord (https://dfhack.org/discord), here's a link to the discussion: https://discord.com/channels/793331351645323264/1017471248567124049/1158850122671739010
Title: Re: DFHack 50.11-r2
Post by: Tachytaenius on October 31, 2023, 05:13:53 pm
Custom tokens - I see that custom tokens are now supported by DFHack, which is very nice. I had previously done this using curly brackets and parsing the raws when the game was started (see examples below). Looking through the custom-raw-tokens.lua code it seem that multi-line tokens aren't a thing though, is this correct? No problem if it is, I can just change my stuff to be a single line(s) as needed.

Hi, yea, custom-raw-tokens' dev (wolfboyft) here. I'm glad you like it! It's been a while since I made it, I don't really remember the reasonings behind everything, but yeah, it does indeed only support single line tokens, and only once in an instance of item subtype or whatever. It's just a search for the first instance of a token, returning the token's extra info. It's basically just for simple key:value(s) stuff, not working with/like the raw parsing state machine, like vanilla tokens often do. It's not super gorgeous in how it does it either, in that multiple instances of a tag don't raise errors (iirc), etc. Multi-line tokens would be pretty cool, though. I can't think off the top of my head how they would work, but I've forgotten a lot so...

Glad to see some interest! Good luck with your projects.
Title: Re: DFHack 50.11-r2
Post by: Roses on October 31, 2023, 06:59:27 pm
<sniped>

Thanks, that all sounds like it's fairly similar to the old system, just moved around a little. Should make my plans much easier.

Custom tokens - I see that custom tokens are now supported by DFHack, which is very nice. I had previously done this using curly brackets and parsing the raws when the game was started (see examples below). Looking through the custom-raw-tokens.lua code it seem that multi-line tokens aren't a thing though, is this correct? No problem if it is, I can just change my stuff to be a single line(s) as needed.

Hi, yea, custom-raw-tokens' dev (wolfboyft) here. I'm glad you like it! It's been a while since I made it, I don't really remember the reasonings behind everything, but yeah, it does indeed only support single line tokens, and only once in an instance of item subtype or whatever. It's just a search for the first instance of a token, returning the token's extra info. It's basically just for simple key:value(s) stuff, not working with/like the raw parsing state machine, like vanilla tokens often do. It's not super gorgeous in how it does it either, in that multiple instances of a tag don't raise errors (iirc), etc. Multi-line tokens would be pretty cool, though. I can't think off the top of my head how they would work, but I've forgotten a lot so...

Glad to see some interest! Good luck with your projects.

Hmm, only allowing a single use of a token per raw and it just being simple key:value means it probably won't work for my intentions. I'll have to see what I can do. I'd rather not go back to using the curly bracket method, but it might be the simplest method. I'll have to think about it some more.
Title: Re: DFHack 50.11-r2
Post by: myk on November 01, 2023, 02:25:52 pm
Extending the custom-raw-tokens functionality to support your use case is likely possible too. If you need it, others might as well.
Title: Re: DFHack 50.11-r2
Post by: Roses on November 01, 2023, 09:29:14 pm
Extending the custom-raw-tokens functionality to support your use case is likely possible too. If you need it, others might as well.

Yeah, it's something I am looking into as well. Reading through the code I think it would be possible to extend it to encompass my use case, but I've gotta think more on what that would look like.
Title: Re: DFHack 50.11-r2
Post by: Rumrusher on November 04, 2023, 09:42:31 am
ok so it seems like I forgot to dump
this cage unit script... though I guess it seem to have a weird quirk with non-historical figures where it just also selects an artifact slab.
so it's mostly stable-ish but probably save before using it.


Code: ("cage-unit.lua") [Select]
local dlg=require("gui.dialogs")
--script that selects a unit from the active unit list and shove them in the currently selected cage
--for nameless units probably nickname them to make it easier to pick them out of the list
--might crash and or try to shove an artifact item in the list if you mess with non-historical figure units
function deitysummoning()
local Ark={}
for k,v in pairs(df.global.world.units.active) do
BoaName=dfhack.TranslateName(v.name)
if v.flags1.inactive==false then
table.insert (Ark,{dfhack.TranslateName(v.name).." "..v.name.nickname ..df.global.world.raws.creatures.all[v.race].creature_id,nil,v})

end
end
local f=function(Name,C)
  shove(C[3])
end
dlg.showListPrompt("unit list","Select a unit for shoving into a cage",COLOR_WHITE,Ark,f)
end

function shove(unit)
for ko,vo in pairs(df.global.world.buildings.other.IN_PLAY) do
if vo.id==df.global.game.main_interface.view_sheets.viewing_bldid then
vo.assigned_units:insert("#",unit.id)
end
end

end


deitysummoning()


so for folks who want to cage trap any visitors that shows up and or wildlife with out needing to go through the cage trap set up.


edit: crud uhh I need more space for this next post
so  uhh finish working on a necromancy in fort mode script and a bunch of gui side scripts that mess with that.

(https://staging.cohostcdn.org/attachment/a07eea98-cf68-4dbc-aaa5-16e2bd806ac6/necrobook-showcase2.gif)

Code: ("necrobook.lua") [Select]
--this is a gui warmist spellbook modification to house a bunch of Curse tomb modification scripts/rumpack/DisTomb
 -- there one spell the create tomb cursor one that you want to do first or the other spell scripts wouldn't work
 -- the other spells are used for editing the curse tomb you selected if you make more uhh hope you remember which triggering point is which.
local dlg=require("gui.dialogs")

function getItemAtPos(x,y,z) -- gets the item index @ x,y,z coord
--local x,y,z=getxyz() --get 'X' coords
local vector=df.global.world.items.all -- load all items
for i = 0, #vector-1 do -- look into all items offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==x and cy==y and cz==z  and df.item_corpsest:is_instance(vector[i]) or cx==x and cy==y and cz==z and df.item_corpsepiecest:is_instance(vector[i]) then --compare them
return vector[i] --return index
end
end
--print("item not found!")
return nil

end


function Tomb2()
local Ark2={}
for k,v in pairs(df.global.world.cursed_tombs) do
--BoaName=dfhack.TranslateName(v.name)
table.insert (Ark2,{k.." "..k,nil,v})
--end
end
local f=function(Name,C)
  Tombmaker5(C[3])
end
dlg.showListPrompt("Tomb list","Select a tomb to start the next part",COLOR_WHITE,Ark2,f)
end
function Tomb3()
local Ark2={}
for k,v in pairs(df.global.world.cursed_tombs) do
--BoaName=dfhack.TranslateName(v.name)
table.insert (Ark2,{k.." "..k,nil,v})
--end
end
local f=function(Name,C)
  Tombmaker2(C[3])
end
dlg.showListPrompt("Tomb list","Select a tomb to start the next part",COLOR_WHITE,Ark2,f)
end
function Tomb3a()
local Ark2={}
for k,v in pairs(df.global.world.cursed_tombs) do
--BoaName=dfhack.TranslateName(v.name)
table.insert (Ark2,{k.." "..k,nil,v})
--end
end
local f=function(Name,C)
  CorpsePoint(C[3])
end
dlg.showListPrompt("Tomb list","Select a tomb to start the next part",COLOR_WHITE,Ark2,f)
end
function Tomb4()
local Ark2={}
for k,v in pairs(df.global.world.cursed_tombs) do
--BoaName=dfhack.TranslateName(v.name)
table.insert (Ark2,{k.." "..k,nil,v})
--end
end
local f=function(Name,C)
  Tombfinder(C[3])
end
dlg.showListPrompt("Tomb list","Select a tomb to start the next part",COLOR_WHITE,Ark2,f)
end
function Tomb5()
local Ark2={}
for k,v in pairs(df.global.world.cursed_tombs) do
--BoaName=dfhack.TranslateName(v.name)
table.insert (Ark2,{k.." "..k,nil,v})
--end
end
local f=function(Name,C)
  Tombmove(C[3])
end
dlg.showListPrompt("Tomb list","Select a tomb to start the next part",COLOR_WHITE,Ark2,f)
end

function Tombmaker2(e)
local Ark2={}
for k,v in pairs(df.global.world.items.other.IN_PLAY) do
    if df.item_corpsest:is_instance(v) or df.item_corpsepiecest:is_instance(v) then -- checked_item.flags.in_building then
--if v.unit_id=nil then else
--if v.hist_figure_id=nil then end

for k2,v2 in pairs(df.global.world.units.active) do
if v.unit_id==v2.id and v2.flags1.inactive==true then
BoaName=dfhack.TranslateName(v2.name)
table.insert (Ark2,{dfhack.TranslateName(v2.name).." "..v2.name.nickname,nil,v.id})
end
end
end
end
local f=function(Name,corpse)
e.coffin_skeletons:insert("#",corpse[3])
end
dlg.showListPrompt("Corpse list","Select a body to add to the cursed tomb",COLOR_WHITE,Ark2,f)
end


function Tombfinder(e)
e.triggered=false
end

function Tombmaker5(e)
local Ark2={}
for k1,v1 in pairs(df.global.world.raws.interactions) do
for k,v in pairs(v1.effects) do
    --if df.interaction_effect_animatest:is_instance(v.effects) or df.interaction_effect_resurrectst:is_instance(v.effects) then -- checked_item.flags.in_building then
    if df.interaction_effect_animatest:is_instance(v) or df.interaction_effect_resurrectst:is_instance(v) then -- checked_item.flags.in_building then

table.insert (Ark2,{v1.name.." "..v1.id,nil,v1.id})
end
end

end
local f=function(Name,C)
e.disturbance=C[3]
end
dlg.showListPrompt("spell list","Select a interaction for shoving into a tomb",COLOR_WHITE,Ark2,f)
end

function Tombmove(e)
e.coffin_pos.x=df.global.cursor.x
e.coffin_pos.y=df.global.cursor.y
e.coffin_pos.z=df.global.cursor.z
local v1=df.global.cursor.x-1
local v2=df.global.cursor.y-1
local v3=df.global.cursor.x+1
local v4=df.global.cursor.y+1
local v5=df.global.cursor.z

e.trigger_regions[0].x_min=v1
e.trigger_regions[0].y_min=v2
e.trigger_regions[0].z_min=v5
e.trigger_regions[0].x_max=v3
e.trigger_regions[0].y_max=v4
e.trigger_regions[0].z_max=v5


end


function SpellSeal()

function Tombmaker(v1,v2,v3,v4,v5,corpse,necro)
Mum=df.global.world.cursed_tombs
Mum:insert("#",{new=true,triggered=false,disturbance=necro,site_id=df.global.plotinfo.site_id})
local clu2=Mum[#Mum-1]
if necro==nil then
necro=Tombmaker6(clu2)
end
clu2.coffin_pos.x=df.global.cursor.x
clu2.coffin_pos.y=df.global.cursor.y
clu2.coffin_pos.z=df.global.cursor.z

clu2.trigger_regions:insert("#",{new=true,
x_min=v1,
y_min=v2,
z_min=v5,
x_max=v3,
y_max=v4,
z_max=v5})

end

function Tombmaker6(e)
local Ark2={}
for k,v in pairs(df.global.world.raws.interactions) do
    if df.interaction_effect_animatest:is_instance(v.effects) or df.interaction_effect_resurrectst:is_instance(v.effects) then -- checked_item.flags.in_building then

table.insert (Ark2,{v.name.." "..v.id,nil,v.id})
end
end
local f=function(Name,C)
e.disturbance=C[3]
end
dlg.showListPrompt("spell list","Select a spell for shoving into a tomb",COLOR_WHITE,Ark2,f)
end

Tombmaker(df.global.cursor.x-1,df.global.cursor.y-1,df.global.cursor.x+1,df.global.cursor.y+1,df.global.cursor.z,nil,12)

--dofile("hack/scripts/rumpack/DisTomb.lua")
end
function CorpsePoint(e)

corpse=getItemAtPos(pos2xyz(df.global.cursor))
e.coffin_skeletons:insert("#",corpse.id)
end
function doNothing()
print("doing nothing real good but here have a message")
end

listofspells={
{text="nothing", spell=doNothing,icon='*'},
{text="Necro:Alter Spell", spell=Tomb2,key="CUSTOM_V"},
{text="Necro:Add Corpses", spell=Tomb3,key="CUSTOM_M"},
{text="Necro:Add Corpses-cursor", spell=Tomb3a,key="CUSTOM_X"},
{text="Necro:Reset Curse", spell=Tomb4,key="CUSTOM_T"},
{text="Necro:Move Tomb-cursor", spell=Tomb5,key="CUSTOM_O"},
{text="Necro:CreateTomb-cursor", spell=SpellSeal,key="CUSTOM_N"},
}
 
dlg.showListPrompt("Directions","Choze order",nil, listofspells,function(index,choice) choice.spell() end)
ok so the list of working spell commands
'alter spell' is the script that lets you choose an interaction to be slotted in the 'disturbance' section of the curse tomb which takes in from what I tested resurrection and animation focus spells the script filters the others out for just those with those effects
'add corpses' and 'add corpses-cursor' will slot in a corpse and corpse piece into the cursed tomb data the cursor one lets you just use the in game keyboard cursor to select a corpse item.
the 'reset curse' will toggle the 'trigger' flag state to false. priming the cursed tomb to animate/resurrect(these are two different interactions) the corpses you added when someone step in the trigger zone
'move tomb-cursor' is to move the triggering zone good for re-aligning a spot to a place with more units wandering about to prox the spell and 'create tomb-cursor' is the command that creates a cursed-tomb though it's filled with mostly dummy data with idea of the player setting it up with the other spell commands also there the whole site id stuff which is align to the player's fort site... also the structure data I found isn't needed for the script but it probably goes to the civ zone building for the tomb.
overall was  rough set of days getting this to work and figuring out if it work.

so now you can revive your dead dwarves if they didn't get mangled and turn them into revenants/intel undead and or mummies.
this probably goes well with mods that dip into resurrection and animation interactions.

so stability warning uhh you are messing with necromancy and making someone a necromancer in form of a mummy if you mess with this ... or a revenant. expect old grudges to spring up and folks getting murdered in droves.
(https://staging.cohostcdn.org/attachment/44f75b69-d2dd-4d2f-9ad7-2564356c8be6/remote-necromancy-doodle.png)
edit 2024: updated the images
edit 2024 april/3: updated for df50.12 changes with the unit selector that broke the script.
Title: Re: DFHack 50.11-r2
Post by: Überzwerg on November 08, 2023, 03:46:01 pm
I have the problem that every few hours the game is taking over 5 minutes to start when DFHack is enabled. When I rename the dfhooks.dll it's starting instantly, with the dll in place it's taking ages again.

I figured out that it is the Windows Defender Cloud Protection that is slowing the start down. I can see it in the Windows event log. And in the task manager you see that the antimalware process is taking minimal processor load, but that it is generating network traffic.
It seems to upload and check every plugin. When I abort the start of the game I see in the stderr.log that it always had stopped at some "loading plugin" entry.

Funnily this does not happen when you freshly install the game and DFHack. I reinstalled it several times at first because I was under the impression that my install is broken. A fresh install is starting instantly, but after a few hours it will take ages again. When you wait until it is done (5 minutes later...) it will start again instantly on the next restarts. Until a few hours later it will again taking ages.

I'm using the free 50.11 version of DF, which is not signed, so Windows is classifying it as PUA.

I'm mostly writing this down so that the devs of DFHack know this issue when reports of the game not starting anymore may come in.
(And I don't understand why that cloud shit is taking so long, my upload is not the bottleneck with 40 MBit/s.)
Title: Re: DFHack 50.11-r2
Post by: myk on November 08, 2023, 10:45:48 pm
Binary signing is a complicated area -- anything involving crypto and trust is, really. According to https://github.com/sigstore/fulcio/issues/250 **maybe** we could get free signing services. It wouldn't be perfect since the root CA wouldn't be trusted by Windows, but it may (and that's just a "may" since I don't really understand the entire signing system and how what we would get would interact with it) result in fewer warnings for players overall. Those like you who know more about what they're doing could potentially install the signpath root CA and avoid the warnings/slowdowns altogether, but again, I'm not sure about that. The GitHub issue I was reading refers to "Smart Screen" which may or may not be the same (or react the same) as Windows Defender Cloud Protection.

It would at least involve building a relationship with signpath and changing our build and release process to involve the remote servers, and I don't really have a sense for how much work that would be.

Edit: After some discussion on the Discord server, the consensus is that what you describe is *not* normal behavior for Windows Defender Cloud Protection. This assessment is somewhat bolstered by the fact that we have never heard of issues like this before, despite being used by tens of thousands of people. It may be that your system is having some other basic trouble or misconfiguration, or even potentially a malware infection that is doing its best to hide from AV, and thus making it malfunction. I hope that's not the case here, but I'm not sure where to point you next.
Title: Re: DFHack 50.11-r2
Post by: Rumrusher on November 09, 2023, 02:51:40 am
sitting here thinking about 'yeah it does take a while for DF to boot up' but then I just figured that due to how I store DF which is on an external drive.
but I guess loading DF onto the cloud probably takes a bit more longer than just having it on the harddrive or some external drive.
Title: Re: DFHack 50.11-r2
Post by: Überzwerg on November 09, 2023, 11:36:20 am
Binary signing is a complicated area ...
That "smart screen" warning is caused by the Dwarf Fortress.exe, not from DFHack, because Dwarf Fortress itself isn't signed. When running Dwarf Fortress.exe the first time it's triggering the warning:
"Windows Protected your PC
Microsoft Defender SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk.
..."

Installing and running DFHack (by starting Dwarf Fortress) isn't causing any warning. And the first cloud scan is only starting after about 6 hours.

I can imagine that DFHack is suspicious for the scanner because it is hooking in another app, just like malware would do it.
And I imagine that most of your user base is now on the Steam version of DF, while I am using the free version. I'm curious if you could replicate it with the free version. You need to have set "cloud protection" and "automatic sample submission" both on ON. (I did set "automatic sample submission" OFF some time ago when I was developing some program, but some upgrade installation of Windows must have turned it back to ON...)

I checked my event log again and the cloud protection is only triggered by DFHack regulary. Other cloud scans I can find are rare and only every few months one entry. (It's under Applications and Services/Microsoft/Windows/Windows Defender/Operational in the event viewer, search there for "cloud").

My main intention to post this behaviour was that your are aware of this when others report that DF isn't starting anymore with DFHack (such a long starting time is looking at first like it isn't starting at all). And there isn't much you can do, expect telling affected users to wait it out or to disable the "automatic sample submission" or to set an exception for the DF folder in the Defender.
Title: Re: DFHack 50.11-r2
Post by: myk on November 09, 2023, 04:03:17 pm
The warning is appreciated -- as you can probably tell, I don't have much experience with recent (that is, < 20 years old) Windows AV.

For the record, DFHack no longer hooks into DF by replacing the SDL library and intercepting the calls. DF detects the DFHack library and *intentionally* loads it into its process space. There's a proper API nowadays. Of course, the scanner might still disapprove of other things DFHack is doing.

I'll add your advice to our docs!

By the way, I've heard that there is a "this file was downloaded from the internet" checkbox that you can untick before extracting DFHack from its distribution archive. Do you happen to remember if you unticked that box?
Title: Re: DFHack 50.11-r2
Post by: Überzwerg on November 09, 2023, 06:10:04 pm
...
By the way, I've heard that there is a "this file was downloaded from the internet" checkbox that you can untick before extracting DFHack from its distribution archive. Do you happen to remember if you unticked that box?
I didn't touched that checkbox. The "df_50_11_win.zip" and the "dfhack-50.11-r2-Windows-64bit.zip" were still marked with this text (under file properties):
"Security: This file came from another computer and might be blocked to help protect this computer."
Followed by a checkbox: "Unblock".
When you click "unblock" this text and the checkbox will go away.

So I checked my install and the various .exe from DFHack had this security warning text (The .dlls under plugins also had that text, but not the dfhooks.dll?!?). The "Dwarf Fortress.exe" did not had that text anymore, confirming the SmartScreen dialog when opening it first seems to do the same as clicking the "Unblock" checkbox.

Did a new install now with the archives "unblocked". Then I didn't got a SmartScreen dialog for "Dwarf Fortress.exe". And of course the warning text is gone from all .exe and .dll files. So far it's working fine and starting fast (while my old install is just again taking a while to start).

I'm quiete sure that this was the trick, but I will report back tomorrow.
Title: Re: DFHack 50.11-r2
Post by: Le Zenith Troglodyte on November 10, 2023, 02:10:20 pm
Hello everyone! Was wondering if there are any plans to add classic keyboard support and keybinds to the .50 version of the game? Really missing those old keybinds.
Title: Re: DFHack 50.11-r2
Post by: ab9rf on November 10, 2023, 06:43:06 pm
I can imagine that DFHack is suspicious for the scanner because it is hooking in another app, just like malware would do it.
DFHack behaves just like any other DLL. There's nothing in DFHack that will look like malware to a heuristic scanner. DFHack does not "hook" another app, it actually loads as an invited DLL (using the 'dfhooks' mechanism provided by Bay12) and uses Bay12's published endpoints to connect to DF.
Title: Re: DFHack 50.11-r2
Post by: Überzwerg on November 10, 2023, 07:25:59 pm
The problem is solved, the long loading times are gone.
All that was needed is to remove the warning "Security: This file came from another computer and might be blocked to help protect this computer" from the downloaded archive by clicking unblock.

Thanks myk for that piece of advice, I couldn't see the forest for the trees.

RANT: I don't get why the cloud scan is not performed at the first execution of those as "unsafe" marked files. Instead Windows let me run those files without problems, but then hours later it will decide to check those files now by sending them to the cloud. And because Windows isn't trusting those files it's sending them to their cloud every 6 hours, again and again...
Title: Re: DFHack 50.11-r2
Post by: PatrikLundell on November 11, 2023, 02:43:44 am
Hello everyone! Was wondering if there are any plans to add classic keyboard support and keybinds to the .50 version of the game? Really missing those old keybinds.
Toady One has said that keyboard support will be restored (July last year), although there's no time line. This is not a DFHack issue, but one for the base game.

Note that you won't get the old key bindings back, but rather new ones. The plan is to use the same set of keys for the same actions everywhere (not a lot of different schemes for cursor movement in different places), and while things are shaken up keys will be assigned to more logical characters (rather than the gradual accumulation of assignment to one of the unused keys over the decades). It won't be possible to restore the old key bindings even if there's a rebinding option (unknown if one will be provided), as functionality has been moved around, so some things have been split or even rearranged such that part of the functionality now is in one action together with other stuff, while other parts may be in another action.
Title: Re: DFHack 50.11-r2
Post by: Rumrusher on November 13, 2023, 08:09:08 am
Hello everyone! Was wondering if there are any plans to add classic keyboard support and keybinds to the .50 version of the game? Really missing those old keybinds.
so I went and made a DF50 keyboard cursor (http://www.bay12forums.com/smf/index.php?topic=164123.msg8487568) script that just a modified version of a different gui liquids script that display an x where the in game cursor is currently placed.
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: myk on November 16, 2023, 11:28:47 am
DFHack 50.11-r3 released!

Highlights: Selection dimension indicator, Choose mechanisms for linking, Burrows!

Get it from:

Full installation instructions: https://docs.dfhack.org/en/stable/docs/Installing.html
Title: Re: DFHack 50.11-r3
Post by: joostheger on November 17, 2023, 07:02:54 am
What do I do when I have found out information, that is currently not in df-structurers?
Or when I have a suggestion for a script-improvement?

Well, it is this: you can kill a unit "by old age". by setting old_age and old_time to any low number. old_age is the age in which the unit dies, and old_time is the time THAT YEAR in which it dies.
So the script 'exterminate' can be updated by a new way of killing people. How nice.

Whats better: this can probably be used to kill off-site units, if you know their unit-id.
Title: Re: DFHack 50.11-r3
Post by: Saiko Kila on November 17, 2023, 01:39:10 pm
What do I do when I have found out information, that is currently not in df-structurers?
Or when I have a suggestion for a script-improvement?

Well, it is this: you can kill a unit "by old age". by setting old_age and old_time to any low number. old_age is the age in which the unit dies, and old_time is the time THAT YEAR in which it dies.
So the script 'exterminate' can be updated by a new way of killing people. How nice.

Whats better: this can probably be used to kill off-site units, if you know their unit-id.

Units can die of old age before and after the old age time, so it's only approximate. Actually, units practically never die on the exact old age date.

When the new year starts, some of the units with old age in the future also die (especially from the first half of the new year), randomly. And if an unit with old age date in the past is off-screen, it won't die on that date, it will die either after entering the map, or in the beginning of new year. Also, some necromancers have the date set, but of course they won't die, because they are necromancers.
Title: Re: DFHack 50.11-r3
Post by: joostheger on November 17, 2023, 02:35:12 pm
Well, I let a unit die by setting old_age and old_time on 1, so I'm sure it works.
Maybe the units dieing in the future is because of old_time was negative or something like that. Do you know how those values were related?
Title: Re: DFHack 50.11-r3
Post by: Clément on November 18, 2023, 08:12:44 am
What could be causing "Too many failed accepts, shutting down RemoteServer"? It happens when I disconnect/reconnect my client too many times (on Linux, both native and wine, dfhack 50.11-r3 built from sources with extra custom plugins). Although the remote server is disabled, the client connection that caused the error is still working after that (but I cannot make new ones). There is no other error message.

Edit: in "void ServerMainImpl::threadFn(std::promise<bool> promise, int port)", acceptFail counts all accept calls, not only failed ones (commit 0914869 (https://github.com/DFHack/dfhack/commit/09148698c808d83d9952aff7824b3baf6f52bc3f)). I'm surprised I did not notice this sooner. (reported here (https://github.com/DFHack/dfhack/issues/4040))
Title: Re: DFHack 50.10-r1 (with Linux support)
Post by: myk on November 22, 2023, 02:39:42 pm
DFHack 50.11-r4 released!

Important bugfixes and QoL improvements.

Get it from:

Full installation instructions: https://docs.dfhack.org/en/stable/docs/Installing.html
Title: Re: DFHack 50.11-r4
Post by: Telgin on November 24, 2023, 11:26:36 pm
Does anyone know if there's a Lua one-liner to print the agitation level of a fort?  Or are there potentially several map regions?  I've been trying to figure out how to get any of the fort's map data from the Lua interpreter but haven't had much luck.

Also, is there a way to "undiscover" cavern layers with the Lua interpreter?
Title: Re: DFHack 50.11-r4
Post by: 0x517A5D on November 25, 2023, 01:30:19 am
Does anyone know if there's a Lua one-liner to print the agitation level of a fort?  Or are there potentially several map regions?  I've been trying to figure out how to get any of the fort's map data from the Lua interpreter but haven't had much luck.

This post (http://www.bay12forums.com/smf/index.php?topic=164123.msg8491942;topicseen#msg8491942) has a couple of one-liners that print that info.
Title: Re: DFHack 50.11-r4
Post by: Quietust on November 25, 2023, 10:29:24 am
Also, is there a way to "undiscover" cavern layers with the Lua interpreter?

If you want to mark a map feature as "not discovered", there's already a script for that - run "feature list" to see which ones are there, then "feature hide N" to undiscover the one you don't want.

Though, it's possible that digging around that feature might cause it to get rediscovered, so you might need to re-disable it again from time to time.
Title: Re: DFHack 50.11-r4
Post by: Telgin on November 25, 2023, 11:28:42 am
Perfect, thanks both of you.

Yeah, for the caverns, I accidentally caused a cave-in while digging an open pit mine that collapsed and punched through to the caverns.  I wanted to avoid them entirely so I think undiscovering it once should help.

Edit: I hid the feature, but I see I'm still getting visitors who want to slay monsters.  Is there another flag I have to toggle to stop that?

The cavern is still visible too, which is fine, but I guess that's also controlled by other map data.
Title: Re: DFHack 50.11-r4
Post by: A_Curious_Cat on November 27, 2023, 11:29:09 pm
So... I'm getting back into the game (now that I've figured out how to exit Steam without it leaving behind zombie processes), and I'm trying to set up autochop so that it excludes trees with products that are brewable, edible, and/or cookable.

I tried first by running gui/autochop, but there apparently weren't any options to exclude trees based on their products.  after searching the DFHack manual, I decided to try using autochop from the command line...

And I got this:

(https://i.postimg.cc/LhdXFqgr/autochop-problem.png)

Any help?
Title: Re: DFHack 50.11-r4
Post by: Madde on November 28, 2023, 03:01:11 pm
I'm sorry in advance if this is not the right place to post this as I'm still using the 47.05 version of DF and DFhack, but I just can't seem to get item-trigger working at all.

I tried it with these two lines in onMapLoad.init:
modtools/item-trigger -itemType ITEM_WEAPON_SABRE -onEquip -command [ modtools/add-syndrome -syndrome "test syndrome" -resetPolicy ResetDuration -target \\UNIT_ID ]
modtools/item-trigger -itemType ITEM_WEAPON_SABRE -onUnequip -command [ modtools/add-syndrome -syndrome "test syndrome" -erase -target \\UNIT_ID ]

... but despite everything looking alright the game just crashes or closes to desktop during the loading screen.
It even happens if I just type in modtools/item-trigger and no further arguments, other commands seem to work fine.
Title: Re: DFHack 50.11-r4
Post by: myk on November 28, 2023, 04:08:12 pm
Edit: I hid the feature, but I see I'm still getting visitors who want to slay monsters.  Is there another flag I have to toggle to stop that?

The cavern is still visible too, which is fine, but I guess that's also controlled by other map data.
If the cavern is blocked off with natural walls, you could use revflood to hide them, but that won't work with constructed walls (by design). If you use tiletypes to add in natural walls, though, you could use revflood to hide the caverns again. That *might* help with the monster slayers, but I'm not sure.

I tried first by running gui/autochop, but there apparently weren't any options to exclude trees based on their products.

There is no global setting for protecting those types of trees. You have to define a burrow and set the protections on the burrow. This is true for the commandline as well. The error message you're seeing should obviously be better phrased, but the issue is that the command you ran has a syntax error. The syntax is:

autochop (protect|unprotect) <type>[,<type>...] <burrow>[,<burrow>...]

and you're missing the burrow specification at the end.

It even happens if I just type in modtools/item-trigger and no further arguments

modtools/item-trigger enables some EventManager events when it is run. My guess is that there is a crash bug in EventManager for one of those event types. What are you trying to build? This may be worth releasing a new 47.05 version of DFHack for.
Title: Re: DFHack 50.11-r4
Post by: Madde on November 29, 2023, 07:28:13 am
modtools/item-trigger enables some EventManager events when it is run. My guess is that there is a crash bug in EventManager for one of those event types. What are you trying to build? This may be worth releasing a new 47.05 version of DFHack for.

I tried with a few older versions of DFhack, 47.05 r8 and r5 crashes when an item-trigger script is run, while r2 seems to work fine.
I didn't test r3 and r4 yet, as r2 seems to suffice for the few scripts that I need.

As for what I'm trying to make, I have been working on a Bloodborne and Darkest Dungeon inspired conversion mod for quite a while now, and I'll probably make use of the item-trigger and reaction-trigger scripts here and there to bring some variety into fort mode and adv mode gameplay.
One such thing would be the Moonlight Basin, a workshop where infused wax idols could be used to summon various ethereal creatures depending on the current phase of the moon.
I've already tried it with the boiling rock syndrome method and it seems to work, but I think using DFhack to more consistently grant the syndrome and make the building OUTSIDE_ONLY would be great.
Title: Re: DFHack 50.11-r4
Post by: myk on November 29, 2023, 09:52:59 pm
EventManager received some restructuring in 0.47.05-r5, which may have broken something. 0.47.05-r4 would likely work for you.
Title: Re: DFHack 50.11-r4
Post by: Rumrusher on December 10, 2023, 01:18:56 am
ok realize I been testing this script for some time now and uhh here's two scripts that reveal the world map of hidden sites and adds an embark note marker to them to show where they are when you zoom in,
Code: ('revealsites.lua') [Select]
for k,v in pairs(df.global.world.world_data.sites) do
if v.type~=0 then
v.flags[0]=false
end
if v.type==2 or v.type==6 or v.type==7 or v.type==9 or v.type==10 then
Mum=df.global.world.world_data.embark_notes
Mum:insert("#",{new=true,tile=32, fg_color=12, bg_color=2, name=dfhack.TranslateName(v.name),left=v.rgn_min_x,right=v.rgn_max_x,top=v.rgn_min_y,bottom=v.rgn_max_y})
local clu2=Mum[#Mum-1]
clu2.pos.x=v.pos.x
clu2.pos.y=v.pos.y
end
end

and another for mapping out the realization buildings on big pre-gen sites which requires one to embark on top of the site first to scan the large site for realizations... it's mostly a voidfort assistant script. also this will hide the site as the embark notes seem to be under the normal site rectangle I guess in premium the visual is like transparent so this is probably not necessary but shrugs.
Code: ('map-a-site2.lua') [Select]
for k,v in pairs(df.global.world.world_data.sites) do
if v.type==1 or v.type==3 or v.type==4 or v.type==5 or v.type==10 then
if v.realization==nil then else
v.flags[0]=true

for ok,oe in pairs(v.realization.buildings) do
local regionx=math.floor(oe.min_x/47)
local regionx2=math.floor(oe.max_x/47)
local regiony=math.floor(oe.min_y/47)
local regiony2=math.floor(oe.max_y/47)
local regionmath1=math.floor((v.global_min_x+regionx)/16)
local regionmath2=math.floor((v.global_max_x+regionx2)/16)
local regionmath3=math.floor((v.global_min_y+regiony)/16)
local regionmath4=math.floor((v.global_max_y+regiony2)/16)
local globalmath1=math.floor((v.global_min_x+regionx)-(regionmath1*16))
local globalmath2=math.floor((v.global_max_x+regionx2)-(regionmath2*16))
local globalmath3=math.floor((v.global_min_y+regiony)-(regionmath3*16))
local globalmath4=math.floor((v.global_max_y+regiony2)-(regionmath4*16))
function embarknote(oe,v,regionmath1,regionmath3,globalmath1,globalmath2,globalmath3,globalmath4)
local buildcolor=oe.type
Mum=df.global.world.world_data.embark_notes
Mum:insert("#",{new=true,tile=buildcolor, fg_color=10, bg_color=5, name=dfhack.TranslateName(v.name),
left=globalmath1,
right=globalmath2,
top=globalmath3,
bottom=globalmath4})
local clu2=Mum[#Mum-1]

clu2.pos.x=regionmath1
clu2.pos.y=regionmath3

end
print (oe.type)
if oe.type~=16 then
embarknote(oe,v,regionmath1,regionmath3,globalmath1,globalmath2,globalmath3,globalmath4)
end

end
end
end
end
(https://cdn.discordapp.com/attachments/302956330304667649/1183289548478890024/map-gif-showcase.gif)


I have been working on an revise of the armview script where it just points at the army on march so one could embark on top of your squad... but I feel like if the player didn't set the calendar timer to 0 ticks this will just end up not working for them on top of that the squad will just march out of the new embark so you got a small window of time to mess with them.



Code: ('build-store-c.lua') [Select]
--this script uses old dfhack code to store items on to the wagon via keyboard cursors.
--probably more stable than the other scripts that store items onto the wagon but requires it to be on the floor.
local contain={}
 function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end

function stuffwagon(curx,cury,curz)

for de,oe in pairs(df.global.world.buildings.all) do
if oe.name == 'Target' then


local vector=df.global.world.items.all -- load all items
for i = 0, #vector-1 do -- look into all items offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==curx and cy==cury and cz==curz then --compare them
dfhack.items.moveToBuilding(vector[i],oe) --return index
end
end

end
end
end

stuffwagon(getxyz())

edit 12/28/2023 : here's a version of the wagon store script that now just stuff items into buildings if you select them with the cursor... probably if you don't have the keyboard cursor script the mining one.
this here mess could say let you stuff things that normally can't be traded into the trade depot if you name the trade depot Target.

Title: Re: DFHack 50.11-r4
Post by: darkhog on December 31, 2023, 09:13:37 pm
IMO you should add a command that would destroy all non-immediately useful items (such as corpses, broken items, etc.) that aren't in stockpiles, because I've had several large sieges and now my FPS is very low, with too many corpses, skeletons and other garbage items being a likely culprit (tested by atom smashing some of them which brought in a brief increase in FPS).

Basically a radical, last resort FPS command when all other ways to increase FPS fail.
Title: Re: DFHack 50.11-r4
Post by: lethosor on January 01, 2024, 12:08:13 am
(tested by atom smashing some of them which brought in a brief increase in FPS).
If the increase was only brief/temporary and your FPS dropped back down, there is probably a different underlying cause.

Anyway, I suspect something along these lines may already be possible with "autodump" plus some filtering tool (extended stocks screen?), so that would probably be our recommendation. If there are filters missing that you think would be useful, we're open to suggestions. Generally, for this sort of thing, I'd prefer to extend existing commands over creating new single-purpose ones.
Title: Re: DFHack 50.11-r4
Post by: darkhog on January 01, 2024, 11:01:01 am
(tested by atom smashing some of them which brought in a brief increase in FPS).
If the increase was only brief/temporary and your FPS dropped back down, there is probably a different underlying cause.

Anyway, I suspect something along these lines may already be possible with "autodump" plus some filtering tool (extended stocks screen?), so that would probably be our recommendation. If there are filters missing that you think would be useful, we're open to suggestions. Generally, for this sort of thing, I'd prefer to extend existing commands over creating new single-purpose ones.

The thing is, I was fighting a massive invasion at the time, so the bodies kept pilling up. It's definitely that as the FPS stabilized after it was over. And yes, this is definitely possible with the autodump (used it to teleport bodies to the bridge for atom smashing), but marking all the bodies and other trash for dumping is a hassle, even with rectangle mass marking feature.
Title: Re: DFHack 50.11-r4
Post by: myk on January 01, 2024, 02:24:19 pm
Note that with the newer gui/autodump, you don't actually have to mark anything for dumping first. If you area select with the mouse, it will act on the selected items instead of those marked for dumping.
Title: Re: DFHack 50.11-r4
Post by: Bumber on January 02, 2024, 11:15:02 am
Sounds like you want something similar to cleanowned (https://docs.dfhack.org/en/stable/docs/tools/cleanowned.html) that also handles non-butcherable, non-buriable corpses? autodump destroy (https://docs.dfhack.org/en/stable/docs/tools/autodump.html) can be called after this for immediate destruction instead of dumping.
Title: Re: DFHack 50.11-r4
Post by: myk on January 02, 2024, 03:30:50 pm
we're working on an "items" tool that can filter by properties and make specific changes (like mark for dumping). this sounds like it might be useful to specify filters for in that tool
Title: Re: DFHack 50.11-r4
Post by: lethosor on January 03, 2024, 11:25:07 pm
we're working on an "items" tool that can filter by properties and make specific changes (like mark for dumping). this sounds like it might be useful to specify filters for in that tool
FWIW, this is similar to the set of features I had in mind when I was referring to the extended stocks screen (https://docs.dfhack.org/en/stable/docs/tools/stocks.html).

The thing is, I was fighting a massive invasion at the time, so the bodies kept pilling up. It's definitely that as the FPS stabilized after it was over. And yes, this is definitely possible with the autodump (used it to teleport bodies to the bridge for atom smashing), but marking all the bodies and other trash for dumping is a hassle, even with rectangle mass marking feature.
Right - my point was that the "stocks" plugin allows (well, allowed) you to search by criteria other than location. e.g. you could select all items with "corpse" in their name and mark them for dumping, then use autodump if you wanted.

I realize now that that "stocks" plugin hasn't been ported to v50 yet, and the "items" tool sounds like a likely replacement for it. So my advice was only really useful for any 0.47 players.
Title: Re: DFHack 50.11-r4
Post by: myk on January 05, 2024, 06:15:34 am
DFHack 50.11-r5rc1 (beta) released!

Highlights: gui/control-panel, gui/autobutcher, confirm, uniform-unstick, gui/mass-remove

Get it from:

Full installation instructions: https://docs.dfhack.org/en/stable/docs/Installing.html
Title: Re: DFHack 50.11-r4
Post by: myk on January 14, 2024, 06:11:35 am
DFHack 50.11-r5rc2 (beta) released!

Highlights: gui/control-panel, gui/autobutcher, confirm, uniform-unstick, gui/mass-remove, gui/reveal, gui/biomes, gui/teleport

Get it from:

Full installation instructions: https://docs.dfhack.org/en/stable/docs/Installing.html
Title: Re: DFHack 50.11-r4
Post by: myk on January 19, 2024, 05:21:49 pm
DFHack 50.11-r5rc3 (beta) released!

Highlights: gui/embark-anywhere, item bulk management, difficulty settings and standing orders auto-restore, retire unused locations

Get it from:

Full installation instructions: https://docs.dfhack.org/en/stable/docs/Installing.html
Title: Re: DFHack 50.11-r4
Post by: myk on January 25, 2024, 03:50:10 pm
DFHack 50.11-r5 released!

Highlights: gui/embark-anywhere, bulk item and building management, squad equipment fixer, gui/biomes, auto-restore difficulty settings and standing orders, and lots more!

Get it from:

Full installation instructions: https://docs.dfhack.org/en/stable/docs/Installing.html
Title: Re: DFHack 50.11-r4
Post by: myk on February 02, 2024, 06:17:22 pm
DFHack 50.11-r6 and 50.12-beta released!

Get it from:

Full installation instructions: https://docs.dfhack.org/en/stable/docs/Installing.html

50.12-beta is available on Steam for subscribers to the 50.12-beta branch.
Title: Re: DFHack 50.11-r5
Post by: A_Curious_Cat on February 04, 2024, 06:20:30 pm
Button recently created a suggestion (http://www.bay12forums.com/smf/index.php?topic=182380.0) to have DF allow custom work details to be saved/restored to/from disk.  In the meantime, would it be possible to extend DFHack with this ability while we wait for Toady One to implement the suggestion?



Also, would it be possible to create a fix that makes egg-layers that are assigned to a pen/pasture only claim nestboxes that are within that pen/pasture?
Title: Re: DFHack 50.11-r5
Post by: myk on February 04, 2024, 08:16:52 pm
custom work details to be saved/restored to/from disk

Very possible. I just did something similar for difficulty settings and standing orders.

Quote
egg-layers that are assigned to a pen/pasture only claim nestboxes that are within that pen/pasture?

This one I'm less sure about. I don't know exactly how egg layers choose their nestboxes. I've noticed that *most* of the time, they'll claim the one that `autonestbox` assigns them to, but not always. I'd have to look into it.

Could you create feature requests for these two at https://github.com/DFHack/dfhack/issues ? Right now we're focused on getting ready for DF 50.12, and I don't want to forget about these.
Title: Re: DFHack 50.11-r5
Post by: A_Curious_Cat on February 05, 2024, 09:38:29 am
custom work details to be saved/restored to/from disk

Very possible. I just did something similar for difficulty settings and standing orders.

Quote
egg-layers that are assigned to a pen/pasture only claim nestboxes that are within that pen/pasture?

This one I'm less sure about. I don't know exactly how egg layers choose their nestboxes. I've noticed that *most* of the time, they'll claim the one that `autonestbox` assigns them to, but not always. I'd have to look into it.

Could you create feature requests for these two at https://github.com/DFHack/dfhack/issues ? Right now we're focused on getting ready for DF 50.12, and I don't want to forget about these.

Done (https://github.com/DFHack/dfhack/issues/4253) and done (https://github.com/DFHack/dfhack/issues/4254).
Title: Re: DFHack 50.11-r6
Post by: Quantum Drop on February 11, 2024, 06:29:10 am
Quick question for anyone familiar with the 47.05 releases: is there any way I can use DFhack to transform a creature into a generated creature?

The specific scenario being that I'm trying to turn a human into a generated Experiment from the world.dat file; modtools/transform-unit doesn't seem to like the creature name in the raws due to the spacing and I've no clue how to make gui/gm-editor work.
Title: Re: DFHack 50.11-r6
Post by: Ziusudra on February 11, 2024, 04:36:21 pm
modtools/transform-unit doesn't seem to like the creature name in the raws due to the spacing
You can enclose strings such as that in quotes to pass them into a tool. Like with createitem ROUGH "INORGANIC:LAPIS LAZULI".
Title: Re: DFHack 50.11-r6
Post by: Rumrusher on February 12, 2024, 07:31:36 am
Spoiler: "gif showcase" (click to show/hide)
Code: ("tradebook.lua") [Select]
--book made for messing with trading warning might mess things up down the road with the save... this script uses warmist spellbook gui script as a basic layout
local dlg=require("gui.dialogs")
function traderlocate()-- seeks traders
for k,v in pairs (df.global.world.units.active) do
if v.flags1.merchant==true then
return v
end
end
end
function getxyz() -- this will return pointers x,y and z coordinates.
local x=df.global.cursor.x
local y=df.global.cursor.y
local z=df.global.cursor.z
return x,y,z -- return the coords
end
function getItemAtKPos(x,y,z) -- gets the item index @ x,y,z coord
local vector=df.global.world.item.all -- load all items
local kickpos=df.global.world.units.active[0].pos
for i = 0, #vector-1 do -- look into all items offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==kickpos.x and cy==kickpos.y and cz==kickpos.z then --compare them
return vector[i] --return index
end
end
return nil
end
function getCreatureAtPos(x,y,z) -- gets the creature index @ x,y,z coord
local vector=df.global.world.units.all -- load all creatures
for i = 0, #vector-1 do -- look into all creatures offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==x and cy==y and cz==z then --compare them
return vector[i] --return index
end
end
return nil
end
function getItemAtPos(x,y,z) -- gets the item index @ x,y,z coord
local vector=df.global.world.items.all -- load all items
for i = 0, #vector-1 do -- look into all items offsets
local curpos=vector[i].pos --get its coordinates
local cx=curpos.x
local cy=curpos.y
local cz=curpos.z
if cx==x and cy==y and cz==z then --compare them
return vector[i] --return index
end
end
return nil
end
function Mount (rider,horse)--swiped the old dragging script for this
rider.relationship_ids.Draggee=horse.id
horse.relationship_ids.Dragger=rider.id
return
end
function traderpack()
unit_1 = traderlocate()
if unit_1 == nil then
print ("You must make a merchant. Use merch-add first.")
return
end
unit_2 = getCreatureAtPos(getxyz())
if unit_2 == nil then
print ("You must place the cursor over the second target.")
return
end
dfhack.with_suspend(Mount, unit_1, unit_2)
end
function merchadd()
 local unit=getCreatureAtPos(getxyz())
unit.flags1.merchant=true
end
function merchminus()
 local unit=getCreatureAtPos(getxyz())
unit.flag.merchant=false
end
function traderadd()--you run this in the trade menu
local Trado=df.global.game.main_interface.trade
for k,v in pairs (df.global.world.units.active) do
if v.flags1.merchant==true then
Trado.merchant_trader=v
Trado.civ=df.global.world.entities.all[v.civ_id]
Trado.havetalker=1
end
end
end
function caravan()
for k,v in pairs (df.global.world.units.active) do
if v.flags1.merchant==true then
Vcivid=v.civ_id
caravan2(Vcivid)
end
end
end
function Caravanfinish()
 df.global.plotinfo.caravans[0].time_remaining=100
end
function caravan2(Vcivid)
local Carav=df.caravan_state:new()
 df.global.plotinfo.caravans:insert("#",{new=true, total_capacity=10000, trade_state = 1, time_remaining= 4000, mood=100, entity=Vcivid})
end
local options = {}
local argparse = require('argparse')
local commands = argparse.processArgsGetopt({...}, {
    {'d', 'dead', handler=function() options.dead = true end}
})
listofspells={
{text="trade:merch-add", spell=merchadd,key="CUSTOM_T"},
{text="trade:merch-minus", spell=merchminus,key="CUSTOM_R"},
{text="trade:packholder-add", spell=traderpack,icon='*'},
{text="trade:caravan-add", spell=caravan,icon='*'},
{text="trade:caravan-finish", spell=Caravanfinish,icon='*'},
{text="trade:menu-swap", spell=traderadd,icon='*'},
}
dlg.showListPrompt("Spelz","Choze spel",nil, listofspells,function(index,choice) choice.spell() end)

ok so I normally would have an example gif showcasing what you can do here but uhhh shrugs. example gifs updated for now.

these series of commands allows one to assign a unit as a merchant, assign someone to be dragged by the merchant, add an caravan entry which lets one set up trade, and if you have issues getting access to the trade menu allows one to toggle into trading, oh and also speed up the trade session so the merchant can just leave.

beware this set of scripts can lead to 'merchant wandering off to do something else, losing out the means to gift items to the trader because they are part of the came civ, lose lifestock and folks because they were dragged away off site, trying to figure out a new playstyle that uses this and having FUN doing so, not working well when actual caravan shows up or you make more than one caravan instance, and the usual unstable warning I give with my scripts.'
any way probably should figure out how to put items in the trader side so I could exchange wares with visitors... next
Title: Re: DFHack 50.11-r6
Post by: myk on March 06, 2024, 03:23:36 pm
DFHack 50.12-r1.1 released!

Get it from:

Full installation instructions: https://docs.dfhack.org/en/stable/docs/Installing.html
Title: Re: DFHack 50.11-r6
Post by: myk on March 12, 2024, 04:10:57 am
DFHack 50.12-r2rc1 (beta) released!

Ready for testing: agitation-rebalance, fix/stuck-worship, work details import/export, autoretrain livestock, labor and skill restrictions for workshops

Get it from:

Full installation instructions: https://docs.dfhack.org/en/stable/docs/Installing.html
Title: Re: DFHack 50.11-r6
Post by: Rumrusher on March 14, 2024, 08:11:24 pm
Code: ("cook-served-tavern.lua") [Select]
--this script is a rough concept of seeing if one could serve food to others
-- this script will search for prepared meals and slam them into a cup a tavern keeper is holding
-- which kinda requires monitoring the tavern keeper to see if they are holding a cup to use this script.
-- for the person who wants a resturant feel to the fort or got goblins and want to see them eat stuff.
--potentially unstable and may leave uncleared general refs in cups which makes them look like they are full.

local crab=df.global.plotinfo.main.fortress_site
local lobster=df.global.world.activities.all
local shrimp=df.global.world.items.other.FOOD
  local items={}
  for _,checked_item in pairs(df.global.world.items.other.IN_PLAY) do
    if df.item_foodst:is_instance(checked_item) and not df.general_ref_activity_eventst:is_instance(checked_item.general_refs) then
      table.insert(items,checked_item)
    end
  end

for _3,craft in pairs(lobster) do
if craft.type==10 then
for _4,act in pairs(craft.events) do
act.unk_v42_1:insert("#",{new=true, item_id=items[dfhack.random.new():random(#items)].id ,unk_1=1, unk_2=0} )

local u_ref=df.general_ref_activity_eventst:new()
u_ref.activity_id=craft.id
u_ref.event_id=act.event_id

local u_store=df.general_ref_contains_itemst:new() -- the cup
local u_contain=df.general_ref_contained_in_itemst:new() -- the stuff in the cop
u_store.item_id=items[dfhack.random.new():random(#items)].id
u_contain.item_id=act.unk_v42_1[0].item_id
local salmon2=df.global.world.items.other.IN_PLAY

for _dc,serve3b in pairs(salmon2) do
if serve3b.id==act.unk_v42_1[0].item_id then
local tuna3=serve3b.general_refs
tuna3:insert(#tuna3,u_store)
end
end

local salmon=act.unk_v42_1[0].item_id

for _5,serve in pairs(items,act.unk_v42_1) do
for _6,serve2 in pairs(act.unk_v42_1) do
 if serve.id==serve2.item_id then
 serve.general_refs:insert(#serve.general_refs,u_ref)
serve.general_refs:insert(#serve.general_refs,u_contain)
end
end
end
end
end
end
ok so here's a script that started off on a normal idea of can I control what tavern serve to folks?
which spiral into a series of hard coded responses to stuff where I just give up and just default to just shoving the food into the cup the tavern keeper is serving and wash my hands of this concept.

so now it's possible to watch a 40 stack prepared meal's value go down due to someone drinking it all away.

(https://staging.cohostcdn.org/attachment/0caa134a-3fa3-4f5b-b26b-254169c50ffe/all-this-work-leading-up-to-this.png)
Title: Re: DFHack 50.11-r6
Post by: myk on March 21, 2024, 12:20:24 pm
DFHack 50.12-r2.1 released!

Highlights: Taking the frustration out of irritation, fixing longstanding vanilla bugs, instrument component lookup, automatically retrain partially trained livestock, skill level and labor type restrictions for workshops.

Get it from:

Full installation instructions: https://docs.dfhack.org/en/stable/docs/Installing.html
Title: Re: DFHack 50.11-r6
Post by: Rumrusher on March 25, 2024, 08:54:26 am
ok so it seems like I wrote an open-legends script that actually opens legends and a open fort mode script that kinda opens fort mode afterwards.
but like
Code: ("open-leg.lua") [Select]
local old_screen=dfhack.gui.getCurViewscreen()
local new_screen=df.viewscreen_legendsst:new()
old_screen.child=new_screen
new_screen.parent=old_screen
new_screen.page:insert("#",{new=true,header="Open Legends",mode=0,index=-1,scroll_position_list=0,scrolling_list=false,
scroll_position_text=0,
scrolling_text=false
})
Code: ("open-fortmode.lua") [Select]
df.global.gamemode=df.game_mode.DWARF
df.global.gametype=df.game_type.DWARF_MAIN
local old_screen=dfhack.gui.getCurViewscreen()
--local new_screen=df.viewscreen_choose_game_typest:new()
local new_screen=df.viewscreen_dwarfmodest:new()
old_screen.child=new_screen
new_screen.parent=old_screen

like you run the first script to open legends, and run the second script to go back to fort mode.
but given the the original open legends had warnings about save corruption that also applies with using these scripts
Title: Re: DFHack 50.11-r6
Post by: myk on March 26, 2024, 06:47:28 am
new_screen.page:insert("#",{new=true,header="Open Legends",mode=0,index=-1,scroll_position_list=0,scrolling_list=false,
scroll_position_text=0,
scrolling_text=false
})

I believe this is the bit that the existing open-legends script is missing. This might finally allow that script to work! Thanks!
Title: Re: DFHack 50.12-r2.1
Post by: myk on April 04, 2024, 03:59:16 am
DFHack 50.12-r3rc1 (beta) released!

Highlights: Dig through warm or damp tiles without interruption, open legends mode directly from an active fort, unlink levers.

Get it from:

Full installation instructions: https://docs.dfhack.org/en/stable/docs/Installing.html
Title: Re: DFHack 50.12-r2.1
Post by: myk on April 05, 2024, 05:02:53 pm
I just opened a discussion for requirements for the new unit overview screen here: https://www.reddit.com/r/dwarffortress/comments/1bwue80/dfhack_adventure_mode_poll_results_and_next_steps/

Anyone who doesn't want to comment on reddit can of course reply here too.
Title: Re: DFHack 50.12-r2.1
Post by: myk on April 11, 2024, 03:32:23 pm
DFHack 50.12-r3 released!

Highlights: Open legends mode directly from an active fort, Dig through warm or damp tiles without interruption, Unlink buildings from levers.

Get it from:

Full installation instructions: https://docs.dfhack.org/en/stable/docs/Installing.html
Title: Re: DFHack 50.12-r3
Post by: elilla on April 18, 2024, 02:18:08 pm
It seems that if I create rock nuts with "createitem SEEDS BUSH_QUARRY 10", I can't mill the resulting seeds? am I missing something?

moreover I tried modding almond seeds to be oil-bearing and I found if I create almond seeds with "createitem PLANT_GROWTH ALMOND:NUT", the resulting almonds are millable.  but I do "createitem SEEDS ALMOND", they aren't.  the resulting items look the same in the UI.
Title: Re: DFHack 50.12-r2.1
Post by: Salmeuk on April 18, 2024, 11:53:43 pm
I just opened a discussion for requirements for the new unit overview screen here: https://www.reddit.com/r/dwarffortress/comments/1bwue80/dfhack_adventure_mode_poll_results_and_next_steps/

Anyone who doesn't want to comment on reddit can of course reply here too.

so I am glad to see this option win!! here are my thoughts

1. copy pasting labor assignments AND profession titles across multiple dwarves, quickly.

   thus enabling the creation of large groups of laborers with duplicated assignment settings and titles

2. allow for a 'free labor' on / off switch for the entire fortress, allowing a quick return to the default (anarchic) state, should you need to just get things completed

3. a screen-space efficient overview of enabled labors. seeing the dwarves laid out in a spreadsheet-esque fashion seems to be the most practical

4. perhaps a separate screen to review dwarf skills, or needs even, but I would hesitate to include too much overlapping information.

again, the previous iteration of dfhack's labor management interface from the 47.05 versions was superb and well designed in all regards.... props to whomever created that beast of an interface. I only wish premium had taken more heed
Title: Re: DFHack 50.12-r3
Post by: myk on April 23, 2024, 11:11:42 am
DFHack 50.13-r1.1 released!

Highlights: Point and click quantum stockpiles, Extended unit info summary.

Get it from:

Full installation instructions: https://docs.dfhack.org/en/stable/docs/Installing.html

If you are subscribed to the DF default branch on Steam, please subscribe to the DFHack default branch as well. If you are subscribed to the DF beta branch, please subscribe to the DFHack adventure-beta branch.