Print

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

[falconne]

Is there a command that can be run to return what screen Dwarf Fortress is currently on?  If so, does it work in both Fortress and Adventure mode?

I'm attempting a mouse-driven interface that is context-sensitive to what you are doing.

You can take a look at my mouse plugin https://github.com/Falconne/dfhack/blob/master/plugins/mousequery.cpp too see how it figures out the current context. There's also a couple of big switch statements in Gui.cpp that are for printing out the current context... the code used there is what you want.

[turabeasel]

I tried running the digfort script on osx and received this error

E: RuntimeError: ./hack/scripts/digfort.rb:3: usage: digfort <plan filename>
 ./hack/scripts/digfort.rb:3
 (eval):1:in `load'
 (eval):1
 (eval):1:in `catch'
 (eval):1

Is there anyway to fix that or does the digfort script not work? Or maybe I'm not using it as intended, can anyone help?

Thanks

[thistleknot]

so no one commented on my autosyndrome error?
http://www.bay12forums.com/smf/index.php?topic=91166.msg4142448#msg4142448

[Dragoon209]

You can take a look at my mouse plugin https://github.com/Falconne/dfhack/blob/master/plugins/mousequery.cpp too see how it figures out the current context. There's also a couple of big switch statements in Gui.cpp that are for printing out the current context... the code used there is what you want.

Thanks!! I'll have a look

[Cato]

Thought I'd go ahead and mention it here, I posted the details (with save) on the bug tracker but I'm getting a repeatable crash error relating to job cancellation. In short anytime a particular reaction ([REACTION:BLOCK_BOULDER], it's a masterwork reaction) is cancelled while active, whether I do it at the workshop screen or the dwarf does it because he doesn't have enough blocks it crashes to desktop. It doesn't appear to be the reaction itself though (or at least not independently of dfhack) because if I run the save without dfhack and cancel the job it proceeds normally.

@turabeasel I've used the digfort script on osx so it's not intrinsic to that. What was the command you activated it with? Alternatively could be the csv file itself, if I export to csv from numbers by default it doesn't use the correct separator that digfort is looking for, it uses "," instead of ";", but the script itself does work on osx so it's not that

[robertheinrich]

Thought I'd go ahead and mention it here, I posted the details (with save) on the bug tracker but I'm getting a repeatable crash error relating to job cancellation. In short anytime a particular reaction ([REACTION:BLOCK_BOULDER], it's a masterwork reaction) is cancelled while active, whether I do it at the workshop screen or the dwarf does it because he doesn't have enough blocks it crashes to desktop. It doesn't appear to be the reaction itself though (or at least not independently of dfhack) because if I run the save without dfhack and cancel the job it proceeds normally.

@turabeasel I've used the digfort script on osx so it's not intrinsic to that. What was the command you activated it with? Alternatively could be the csv file itself, if I export to csv from numbers by default it doesn't use the correct separator that digfort is looking for, it uses "," instead of ";", but the script itself does work on osx so it's not that

Generally I think you shouldn't use the bugtracker for problems which are caused by modding the game. From my understanding the bugtracker is to be used to help Toady keep track of bugs of the vanilla version and not for mods. As for dfhack, much of what it does is independent of what certain crazy people add to the game. Some of the plugins and scripts will only work properly on vanilla raws and break on modded scenarios. Don't blame dfhack if you mod the raws and something blows up into your face. Instead, come to the dfhack thread (oh, you did that ) and complain about it.

[Putnam]

Mods can reveal bugs in vanilla that normally wouldn't show up; however, I don't think DFHack is really a standard mod, so...

[Cato]

By bug tracker I meant the dfhack bug tracker (on git hub, from the first page of this thread) if I understand the dfhack release properly it's at least partially connected to dfhack. I say this because when I test it by running the fort with the df script I can cancel the job and the game proceeds normally. If I then run the dfhack script and try the same thing then after unpausing it crashes. If I correctly understand that the df script (as opposed to the dfhack) script in the r3 release runs dwarf fortress without dfhack then it is at least partially connected to dfhack, not sure about the whys or hows but thought I'd bring it up.

[Rumrusher]

okay if I remember warmist made a companion option to allow you to order them to do jobs.
at the time I didn't do much with this due to there was no way to mass order commands.
(like telling one to go dig means you need to chaperone the guy to dig out a tunnel and not like say designate a path and just order him.)
so I didn't do much with this. since r3 is out best drop the code.

Code: [Select]

function getLastJobLink()
    local st=df.global.world.job_list
    while st.next~=nil do
        st=st.next
    end
    return st
end
function AddNewJob(job)
    local nn=getLastJobLink()
    local nl=df.job_list_link:new()
    nl.prev=nn
    nn.next=nl
    nl.item=job
    job.list_link=nl
end
function MakeDig(unit,pos,job_type)
    local nj=df.job:new()
    nj.id=df.global.job_next_id
    df.global.job_next_id=df.global.job_next_id+1
    nj.flags.special=true
    nj.job_type=job_type
    nj.completion_timer=-1
    nj.unk4a=12
    nj.unk4b=0
    nj.pos:assign(pos)
    nj.general_refs:insert("#",{new=df.general_ref_unit_workerst,unit_id=unit.id})
   
    AddNewJob(nj)
    unit.job.current_job=nj
    pos.x=pos.x-1
    unit.path.dest:assign(pos)
end

{name="channel",f=function(unit_list,pos)
    if not CheckCursor(pos) then
        return false
    end
    for k,unit in pairs(unit_list) do
        MakeDig(unit,pos,df.job_type.FellTree)
    end
    return true
end},

[expwnent]

I am aware there are problems with autoSyndrome and trueTransformation but I can't work on them right now. Please document any problems in as much detail as possible, and if you have time, see if you can play around with them and find out exactly when the problem happens.

[Deon]

Expwnent, any idea why it doesn't work for me at all? I've posted the raws on the previous page.

[expwnent]

There are still some weird requirements with boiling temperature that I'm going to remove in the next version. But you said that the first transformation DID happen so that can't be it.

Try different intermediate/final forms, different durations, etc.

There's a small chance that it doesn't work in combination with autoSyndrome, but that's a HUGE flaw if true, and I'm 90% sure I tested that myself. Try the same syndrome with an interaction and see if it works.

[robertheinrich]

By bug tracker I meant the dfhack bug tracker (on git hub, from the first page of this thread)

Alright, I thought you used DF's official bug tracker at Mantis which should only be used for problems with the vanilla game. I didn't look at your savegame yet but I imagine the problem *might* be caused by workflow trying to check if it should protect a repeat job which uses a modded custom reaction.

[Cato]

The problem would have to be more specific than just workflow on a custom reaction because I have lots of other custom (from masterwork) reactions running with workflow on and managing them without any problems. It's just that particular reaction that causes problems. I don't see anything immediately stand out about the reaction itself either.

[falconne]

I didn't look at your savegame yet but I imagine the problem *might* be caused by workflow trying to check if it should protect a repeat job which uses a modded custom reaction.

I did a quick check before coming to work this morning to make sure it wasn't a workflow problem and I don't think it is. The crash happens here in autoSyndrome because "bob->mat_index" is -1.

Just guessing here without knowing anything about the code, but might it also be a bug that the autoSyndrome is processing the job as if it completed successfully, even though it was actually cancelled?