Print

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

[Andys]

Did you have a dfhack.init file? If you didn't, DFHack should have loaded dfhack.init-example and told you.

I don't think so.
That's an old way to provide a config documentation - you name it "something...example" and include every possible configuration option with comments.
User himself copies the file, removes the "example" path and comments out those option he doesn't need.
This "example" file itself is not loaded, it's only acts as more practical version of documentation.

Yes, but DFHack is supposed to load dfhack.init-example if it can't find dfhack.init and display a warning, because at one point enough people who installed DFHack didn't read the documentation and were complaining that DFHack tools weren't working.
(Apparently the problem here was that DFHack would treat any dfhack*.init file as acceptable, and PE's pack was still distributing dfhack_onload_pylnp.init or something similar, so DFHack loaded that and didn't check for dfhack.init.)

You're right, I just tested this.
I always played with valid dfhack.init so never saw that message box about example file

[Brody]

I don't think this issue is new to 42.XX, as I feel like I ran into it in one of the masterwork packs, but I am having an intermittent issue with designations. Sometimes, after attempting to use the mouse to designate tiles for digging/channel/ramps, the designate tool will not designate any of the "dig" commands except whichever it happened to break while using. It will then start working later. I apologize for the lack of information on the issue. Its certainly not game breaking, just a little annoying when it happens.

[Boltgun]

I don't think this issue is new to 42.XX, as I feel like I ran into it in one of the masterwork packs, but I am having an intermittent issue with designations. Sometimes, after attempting to use the mouse to designate tiles for digging/channel/ramps, the designate tool will not designate any of the "dig" commands except whichever it happened to break while using. It will then start working later. I apologize for the lack of information on the issue. Its certainly not game breaking, just a little annoying when it happens.

Are you sure you did not try to dig with the 'automine ore/vein' or other related options activated? It happens to me all the time.

[Brody]

No, the only automation I had running was autolabor. It just flat out would not designate new tiles to be dug, or dug into upward ramps, I could, however, channel.

[lethosor]

Boltgun is asking about the "a" option in the vanilla designations menu, not a DFHack feature.

[Demki]

Are you sure you didn't have this on(that's not a DFhack option, it's a default option that messes with you at times, and makes some things so much better):

Spoiler (click to show/hide)

EDIT: lethosor beat me to it.

[Brody]

I mean, I may have turned that on, but I don't know why that would make designating any area on the entire map not work for [D]ig or [R]amp, but still work for C[h]annel.

[Demki]

Designating with it set to anything other than "designate all" would make it only designate ores/gems(depending on the setting) and not care about normal rock. This is true for both Up [r]amp and [d]igging, since these dig the current level's tile and thus can see what that tile is.
C[h]annel doesn't have the option to only designate ore since it digs the tile below it, thus unable to know what it is.

In short: specific ore/gem designation is only available for [d] Mine, [r] Up Ramp, [j] Down Stair, [¸u] Up Stair, and [¸i] U/D Stair.
It is NOT available for [h] Channel so it does not affect it

[Brody]

Weird, I guess I just assumed that channel would follow the same "digging" rules. I apologize for my obtuseness.

[forsaken1111]

Weird, I guess I just assumed that channel would follow the same "digging" rules. I apologize for my obtuseness.

Because channeling designates the tile below to be dug, it doesn't follow the same rules.

[Kromtec]

Hi, I get an error when trying to export the additional legends_plus.xml file with the prerelease version.

Spoiler (click to show/hide)

Another issue with exportlegends I came across in DFHack 0.40.24-r5 is that when you retire a fortress and export the legends data, the legends_plus.xml file has an one day younger timestamp than the other files.

Spoiler (click to show/hide)

[Meph]

Thank you Splinterz

Edit: Wrong thread. Should have been in the therapist thread, sorry.

[Max™]

Well here's a first run for this, I left in the utils/args bits so it can be extended or folded into one of the add-thought/add-emotion/remove-stress type scripts.

Code: (fillNeeds.lua) [Select]

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

local unit = args.unit and df.unit.find(args.unit) or dfhack.gui.getSelectedUnit(true)

if not unit then qerror('A unit must be specified or selected.') end

function satisfyNeeds(unit,needs)
    local needs=unit.status.current_soul.personality.unk_v4201_1a
    for k,v in ipairs(needs) do
       needs[k].unk_8 = 400
    end

end

    satisfyNeeds(unit,needs)
I've just been building around the annoying/flat-out impossible to fulfill needs as is, but I figured before I go in and see why a couple of other things are broken (names is targeting something weird) I'd knock out an easy one.

[expwnent]

Currently that won't accept any arguments. You need something like

Code: [Select]

local validArgs = utils.invert({
  'unit',
  'someOtherArgument'
})

(untested)

edit: Actually I'm wrong. If you leave validArgs null then it will accept all arguments, but that will silently ignore mistyped arguments.

[Max™]

Yeah, I was just gonna strip it out but it worked my first try with them in there, so I figured I'd leave it in case I wanted to try to figure out if you could make it fill a specific need or something, or apply to all units, etc.