Print

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

[PeridexisErrant]

I'm assuming you were thinking of running commands through the web interface. This wouldn't necessarily require running them through the DF interface - a separate prompt could be set up fairly easily to run simple commands from the web interface, but I don't know if interactive I/O would be possible (basically, commands using the command line like "tiletypes" would be tricky).

If it's possible to pass commands from a dfterm client, that's a big improvement - you can (eg) toggle workflow, force sieges, turn on auto-whatever, etc.  Full interactive I/O would be very nice, but even input alone would be pretty nice. 

[Putnam]

Related:

DFHack-run works fine for connecting to the DFHack console, however, it does not have the ability to connect over a network, and this is intentional, as a security feature. If you want that ability, you need to modify the source to allow connections to and from other computers.

[Meph]

Does anyone know how I could target a worker with removebadthoughts.rb ? I can run "removebadthoughts all" without problem, but not "removebadthoughts him" while using autosyndrome, because it only get a location, not the unit id, as a target.

In the end, I would like a reaction that removes the bad thoughts from the worker. Any ideas?

[Putnam]

I think what Meph is saying is that every script should have an option to include a unit ID as an argument

(I've started doing it because it's really convenient)

[ag]

If it's possible to pass commands from a dfterm client, that's a big improvement - you can (eg) toggle workflow, force sieges, turn on auto-whatever, etc.  Full interactive I/O would be very nice, but even input alone would be pretty nice.

It's easy to run commands from a c++ plugin, you just need to implement the color_ostream interface to feed the output wherever you need it, and then call the command. Making sure you don't mess up access to whatever mutexes you use and cause a deadlock is on you though. Also, when commands and scripts want to output text from background handlers and suchlike, they use the true console directly, so you won't get that output.

For interactive commands it would be necessary to introduce some kind of abstract interactive_ostream interface too (or add the necessary methods to color_ostream); currently that is still baked in into the normal console class.

[Putnam]

This code

Code: [Select]

local function fusion(reaction,unit,input_items,input_reagents,output_items,call_native)
    local tbl={}
    for k,u in ipairs(df.global.world.units.active) do
local name=dfhack.TranslateName(dfhack.units.getVisibleName(u))
if name=="" then name="?" end
if (df.global.gamemode==1 and u.race==df.global.world.units.active[0].race) or (df.global.gamemode==0 and dfhack.units.isDwarf(u) and dfhack.units.isCitizen(u)) then table.insert(tbl,{name,nil,u}) end
end
table.sort(tbl,function(a,b) return getPowerLevel(a[3])>getPowerLevel(b[3]) end)
    script.start(function()
local unitsToFuse={}
local f=function(name,C)
table.insert(unitsToFuse,C[3])
script.mkresume(true)
end
repeat
dialog.showListPrompt("Unit Selection","Choose first Saiyan to fuse (by power level)",COLOR_WHITE,tbl,f)
script.wait()
dialog.showListPrompt("Unit Selection","Choose second Saiyan to fuse (by power level)",COLOR_WHITE,tbl,f)
script.wait()
if unitsToFuse[1]==unitsToFuse[2] then unitsToFuse[1]=nil unitsToFuse[2]=nil unitsToFuse={} end
until unitsToFuse[1] and unitsToFuse[2] and unitsToFuse[1]~=unitsToFuse[2]
fuseUnits(unitsToFuse[1],unitsToFuse[2])
end)
call_native.value=false
end
Produces this error

Code: [Select]

...\Dwarf Fortress\Mods\Dragon Ball\hack\lua\gui\script.lua:46: Not in a gui scr
ipt coroutine.
stack traceback:
        [C]: in function 'error'
        ...\Dwarf Fortress\Mods\Dragon Ball\hack\lua\gui\script.lua:46: in function 'getinst'
        ...\Dwarf Fortress\Mods\Dragon Ball\hack\lua\gui\script.lua:68: in function 'mkresume'
        ...Fortress\Mods\Dragon Ball/data/save/region5/raw/init.lua:277: in function 'on_select'
        ...Dwarf Fortress\Mods\Dragon Ball\hack\lua\gui\dialogs.lua:193: in function 'on_submit'
        ...Dwarf Fortress\Mods\Dragon Ball\hack\lua\gui\widgets.lua:576: in function 'submit'
        ...Dwarf Fortress\Mods\Dragon Ball\hack\lua\gui\widgets.lua:588: in function 'onInput'
        ...y Games\Dwarf Fortress\Mods\Dragon Ball\hack\lua\gui.lua:472: in function 'inputToSubviews'
        ...Dwarf Fortress\Mods\Dragon Ball\hack\lua\gui\dialogs.lua:224: in function <...Dwarf Fortress\Mods\Dragon Ball\hack\lua\gui\dialogs.lua:217>
        [C]: in ?
The error says that this:

Code: [Select]

local f=function(name,C)
table.insert(unitsToFuse,C[3])
script.mkresume(true)
end

Is not a gui script coroutine.

I'm not sure why. I've tried 5 different completely hackish solutions (none of which I'm proud of), culminating in this:

Code: [Select]

local function fusion(reaction,unit,input_items,input_reagents,output_items,call_native)
    local tbl={}
    for k,u in ipairs(df.global.world.units.active) do
local name=dfhack.TranslateName(dfhack.units.getVisibleName(u))
if name=="" then name="?" end
if (df.global.gamemode==1 and u.race==df.global.world.units.active[0].race) or (df.global.gamemode==0 and dfhack.units.isDwarf(u) and dfhack.units.isCitizen(u)) then table.insert(tbl,{name,nil,u}) end
end
table.sort(tbl,function(a,b) return getPowerLevel(a[3])>getPowerLevel(b[3]) end)
local unitsToFuse={}
local f=function(name,C)
end
repeat
script.showListPrompt("Unit Selection","Choose first Saiyan to fuse (by power level)",COLOR_WHITE,tbl,function() table.insert(unitsToFuse,C[3]) local inst = getinst() return curry(invoke_resume, inst, inst.gen, false) --[[yeah I had to make it an in-line function to work... but it still doesn't]] end)
script.showListPrompt("Unit Selection","Choose second Saiyan to fuse (by power level)",COLOR_WHITE,tbl,function() table.insert(unitsToFuse,C[3]) local inst = getinst() return curry(invoke_resume, inst, inst.gen, false) end)
if unitsToFuse[1]==unitsToFuse[2] then unitsToFuse[1]=nil unitsToFuse[2]=nil unitsToFuse={} end
until unitsToFuse[1] and unitsToFuse[2] and unitsToFuse[1]~=unitsToFuse[2]
fuseUnits(unitsToFuse[1],unitsToFuse[2])
call_native.value=false
end
Combined with editing gui.scripts from this:

Code: [Select]

function showListPrompt(title, text, tcolor, choices, min_width, filter)
    dlg.ListBox{
        frame_title = title,
        text = text,
        text_pen = tcolor,
        choices = choices,
        frame_width = min_width,
        with_filter = filter,
        on_select = mkresume(true),
        on_cancel = mkresume(false),
        on_close = qresume(nil)
    }:show()

    return wait()
end

to this:

Code: [Select]

function showListPrompt(title, text, tcolor, choices, on_select, min_width, filter)
    dlg.ListBox{
        frame_title = title,
        text = text,
        text_pen = tcolor,
        choices = choices,
        frame_width = min_width,
        with_filter = filter,
        on_select = on_select,
        on_cancel = mkresume(false),
        on_close = qresume(nil)
    }:show()

    return wait()
end
And none of it's working.

Am I misunderstanding some basic aspect of the code? The example given is too basic for me to work with, given what I'm doing. Reading the prompts reveals that they are apparently only capable of resuming the script and showing the user various prompts that do nothing, so it's not really useful. Am I overcomplicating asking for two inputs?

[Warmist]

It basically says what is wrong: it's not in gui script coroutine. The script thingies are designed to run in gui screens.

[Putnam]

So then I have a better question:

Am I overcomplicating asking for two inputs?

Also, has anyone ever... used... the script code? I mean, there's a typo on github right now that prevents it from working in r3, an unclosed paren on line 156. I had to manually edit that to get it to work in the first place.

[ag]

Am I misunderstanding some basic aspect of the code? The example given is too basic for me to work with, given what I'm doing. Reading the prompts reveals that they are apparently only capable of resuming the script and showing the user various prompts that do nothing, so it's not really useful. Am I overcomplicating asking for two inputs?

Yes, you are utterly misunderstanding how coroutines work. You are not supposed and should not edit anything in script. This is how you are supposed to use it:

Code: [Select]

local ok, name, C = script.showListPrompt("Unit Selection","Choose first Saiyan to fuse (by power level)",COLOR_WHITE,tbl)
if ok then table.insert(unitsToFuse,C[3]) end

Some details may be wrong, but this is how it works.
         

[Putnam]

Ok, cool!

This is why when I do anything I feel is stupid, I do it in a test copy far away from the master copy of the mod I'm working on.

[ag]

A good analogy to understand coroutines in more conventional terms is think that code can execute in two role contexts: coroutine (similar to a thread in a cooperatively multitasking os) and supervisor (non-threaded os kernel that chooses which thread runs). The confusing thing about lua is that those roles can only exist in your mind and aren't separated in any way by the actual interpreter.

Thus, you can imagine that the code executes like that:

• The default supervisor role calls script.start with a function to start it in a new thread. It is immediately started and gets control.
• In the thread context you call script.mkresume(args...), which returns a closure.
• Then call script.wait(), which suspends execution of the thread and returns control to the supervisor.
• The gui screen code, which runs in the default supervisor context, calls the mkresume closure. This resumes the thread, and makes wait return the arguments to mkresume, followed by the arguments to the closure. Thus, you get a true or false flag from mkresume(true) etc, and then the arguments of the callback.

(In a real os with separate address spaces script.showListPrompt would probably execute in kernel mode, but scheduled on the application thread.)

The main thing the script.lua does actually is keeping a counter to make all mkresume closures for a specific thread expire once a wait returns: you don't want resuming some other wait with unexpected return values if the gui screen glitches out and calls the closure multiple times.

[Urist Da Vinci]

https://github.com/angavrilov/df-structures/blob/master/df.projectile.xml#L22
Projectile flag unk6 is set when objects are thrown during tantrums that will hit friendly creatures in the projectile's path.

https://github.com/angavrilov/df-structures/blob/master/df.projectile.xml#L54
Projectile unk22 is the speed or velocity used on non-parabolic (older-code) projectiles.

[catvanbrian]

is it possible to make it rain blood without going to a evil biome using dfhack

[Putnam]

https://github.com/angavrilov/df-structures/blob/master/df.projectile.xml#L22
Projectile flag unk6 is set when objects are thrown during tantrums that will hit friendly creatures in the projectile's path.

That's absolutely wonderful.

is it possible to make it rain blood without going to a evil biome using dfhack

It's an interaction effect. It's likely possible, but I'm not sure how it could be done.

[catvanbrian]

https://github.com/angavrilov/df-structures/blob/master/df.projectile.xml#L22
Projectile flag unk6 is set when objects are thrown during tantrums that will hit friendly creatures in the projectile's path.

That's absolutely wonderful.

is it possible to make it rain blood without going to a evil biome using dfhack

It's an interaction effect. It's likely possible, but I'm not sure how it could be done.

can you show me a example of the interaction effect