Print

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

[falcn]

I have a feature request.
Could you please make digv and digexp support priority?

Currently they have no priority, overriding all manual mining designations.

[Eldin00]

I think digv is mostly obsolete with the automining features added at the same time as the priorities (there's still a use case for digv x). But I second that adding a priority to digl and digexp would be useful.

[lethosor]

https://github.com/DFHack/dfhack/issues/481
It's a known issue that's been around since the job priority changes, but fixing it would require some changes to DFHack's map caching system that nobody's done yet.

[fbo]

Something completely different: Is there a way to read out how many wood/craft/gem/... jobs have been done already (aka when will the fortress become a metropolis)?

[Max™]

df.global.job_next_id?

[Putnam]

no

[Max™]

Oh yeah that one will include cleaning and stuff huh.

[Quietust]

Something completely different: Is there a way to read out how many wood/craft/gem/... jobs have been done already (aka when will the fortress become a metropolis)?

There is a way, but it's very much non-trivial - all of the information is present in [df.global.]ui.tasks.recent_jobs, but you'll need to parse that information out on your own. Exact details on how the game itself does this are not available at the moment, but I can locate it (later) without too much difficulty.

[Antsan]

I think digv is mostly obsolete with the automining features added at the same time as the priorities (there's still a use case for digv x). But I second that adding a priority to digl and digexp would be useful.

digv is superior to automining in one respect: It let's me check whether the command would dig into any tiles I want to keep and then unmark those. It's not nice when my dwarves punch holes into the dining halls.
I already asked this once (and I don't remember why it was denied): It would be very useful if the commands for digging had an option to ignore anything smoothed.

[lethosor]

Are you referring to DF designations or DFHack commands? Suggestions regarding both of these typically aren't "denied", but they do tend to get buried - it world be best to make suggestions for DFHack features in the DFHack issue tracker.

[Antsan]

I'm referring to the DFHack commands. I'll write a ticket.

[expwnent]

I already asked this once (and I don't remember why it was denied): It would be very useful if the commands for digging had an option to ignore anything smoothed.

That's doable. A ticket is a good way to make sure it doesn't get forgotten.

[Antsan]

It's now in the issue tracker. I hope what I wrote is sufficient.

[Bien]

Would it be possible to create a flag in Autolabor to set a certain type of labor as 'dedicated'? Like say, set "autolabor HAUL_STONE 2 4 d", where D disables all other labors in the dwarves it selects, leaving them as only stone haulers?

A generalized "HAUL" labor would also be useful, and would act as a macro that sets all of the Hauling labors to the set values.

I'd make this but sadly I have zero programming skill.

[Max™]

Ok then, I'm tired as hell but with a little more work this will be functioning properly, my brain just funked out on how to make it select the right function for the target type.

Code: (names.lua) [Select]

function factname()
 --if dfhack.gui.getCurViewscreen().parent == df.viewscreen_itemst then
  newn = dfhack.gui.getCurViewscreen().name
fact = dfhack.gui.getCurViewscreen().parent.item.general_refs[0].artifact_id
trg = df.artifact_record.find(fact)
local oldn = trg.name

oldn.first_name = newn.first_name
oldn.words[0] = newn.words[0]
oldn.words[1] = newn.words[1]
oldn.words[2] = newn.words[2]
oldn.words[3] = newn.words[3]
oldn.words[4] = newn.words[4]
oldn.words[5] = newn.words[5]
oldn.words[6] = newn.words[6]
oldn.parts_of_speech[0] = newn.parts_of_speech[0]
oldn.parts_of_speech[1] = newn.parts_of_speech[1]
oldn.parts_of_speech[2] = newn.parts_of_speech[2]
oldn.parts_of_speech[3] = newn.parts_of_speech[3]
oldn.parts_of_speech[4] = newn.parts_of_speech[4]
oldn.parts_of_speech[5] = newn.parts_of_speech[5]
oldn.parts_of_speech[6] = newn.parts_of_speech[6]
oldn.language = newn.language
oldn.has_name = newn.has_name
end

function unitname()
 --if dfhack.gui.getCurViewscreen().parent == df.viewscreen_dungeon_monsterstatusst then
  newn = dfhack.gui.getCurViewscreen().name
oldn = dfhack.gui.getCurViewscree().parent.unit.name
 
  oldn.first_name = newn.first_name
  oldn.words[0] = newn.words[0]
  oldn.words[1] = newn.words[1]
  oldn.words[2] = newn.words[2]
  oldn.words[3] = newn.words[3]
  oldn.words[4] = newn.words[4]
  oldn.words[5] = newn.words[5]
  oldn.words[6] = newn.words[6]
  oldn.parts_of_speech[0] = newn.parts_of_speech[0]
  oldn.parts_of_speech[1] = newn.parts_of_speech[1]
  oldn.parts_of_speech[2] = newn.parts_of_speech[2]
  oldn.parts_of_speech[3] = newn.parts_of_speech[3]
  oldn.parts_of_speech[4] = newn.parts_of_speech[4]
  oldn.parts_of_speech[5] = newn.parts_of_speech[5]
  oldn.parts_of_speech[6] = newn.parts_of_speech[6]
  oldn.language = newn.language
  oldn.has_name = newn.has_name
end

if df.viewscreen_layer_choose_language_namest:is_instance(dfhack.gui.getCurViewscreen()) then
 factname()
 elseif not df.viewscreen_layer_choose_language_namest:is_instance(dfhack.gui.getCurViewscreen()) then
 choices = df.new(df.viewscreen_setupadventurest) ; choices.subscreen = 3 ; gui = require 'gui' ; gui.simulateInput(choices, 'A_RANDOM_NAME') ; gui.simulateInput(choices, 'A_CUST_NAME')
endAt the moment it's set to artifacts as you can see, I intend to have it grab a string sent to it for the first name, and I gotta figure out how to make it apply the change before you exit properly but right now you just run it once and it pulls up the choices, then you run it again and it commits the change.

Again, mostly just a proof of concept but hey, it works and I'll figure out what all is wrong and a better way to do it when I get up. Like, I know there is a "for k,v in ipairs(oldn) do" method to get around typing out the words[0] through [6] stuff but it was annoying me so I just threw it in manually to make sure it worked so I could try to get the targeting stuff in.

Oh, I'm not sure if it would be cleaner to have a second script that just pulls up the choices screen and then run that from dfhack.script_environment(choices) or whatnot, from what I gather it should properly dismiss the extra screen, if there is a way to have it effectively do that inside the one script awesome, but yeah, functioning name changing with the translated names/random generator access, though only first+lastname atm, dunno how to make it choose longer... gotta experiment with pulling up the fortress name generator screen perhaps.