Print

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

[Clément]

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 to see what functions are available.

[lethosor]

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.

[zaporozhets]

I dislike gumming up the thread with stupid questions, but when:

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:

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...

[lethosor]

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.

[Meph]

Lethosor: yeah, a little warning popup about "dont do X" would be great.

[hertggf]

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.

[lethosor]

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.

[hertggf]

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.

[lethosor]

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, 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.

[Rumrusher]

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

Spoiler:  list of stuff that unleashed hell (click to show/hide)

 and also having custom demons or monsters that hang out in hell who end up getting killed and famous so they unload in the map on the surface also happen.
like there loads of ways to accidentally unleashed hell with out a fort with Dfhack and with just modding that open legends seems like a ehh really another one added to the list?

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.

[Gooblin]

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.

[PatrikLundell]

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.

[PatrikLundell]

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?

[xzaxza]

Hi,

I'm new. DFHack's pretty neat. Some of the documentation is bit poor though.

Also, I've noticed some... thingies. I don't have a github account, so.

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:

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:

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.]

[lethosor]

Hi,

I'm new. DFHack's pretty neat. Some of the documentation is bit poor though.

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.