Print

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

[lethosor]

I'm not really sure. What OS are you using, and what folders are in your data/save folder?

[Quietust]

I see, thanks! Is there any way i could re-enable them?

That's hardcoded functionality (i.e. not in the raws), so the only way I can think of (that doesn't involve reimplementing traps entirely in DFHack, which is hard) would be to override building vmethods. These might be relevant, judging by their names, but I have no idea what they do or if they're trap-related. So unless we're lucky, it's probably not feasible.

Shame. Still, gonna see if i can do somenthing with theese. Thanks.
Tho i'm not that good with modding DF so i doubt i'm gonna manage to get them working.

In case you're still interested, "updateAction" is the vmethod that handles traps being triggered, but the class involved (building_trapst) handles all of the different trap types, including levers, pressure plates, and track stops. You might be able to temporarily set gamemode=0 for the duration of the vmethod if it's the correct subtype, but that might also cause the trap to malfunction (e.g. from trying to invoke Fortress-specific behavior in Adventurer mode).

[Iä! RIAKTOR!]

How make adding syndrome of regeneration and body parts regrowing for blizzard men from any contact with water? Water is hardcoded, so standard way of adding syndromes is not our way. Adding new material will not work too, I need regeneration from rain, rivers and snow.

[Atomic Chicken]

How make adding syndrome of regeneration and body parts regrowing for blizzard men from any contact with water? Water is hardcoded, so standard way of adding syndromes is not our way. Adding new material will not work too, I need regeneration from rain, rivers and snow.

This was fairly straightforward, so I went ahead and wrote a script for adding syndromes to inbuilt materials:

Code: [Select]

-- Add a syndrome to an inbuilt material.
-- Author: Atomic Chicken

local utils = require 'utils'

local validArgs = utils.invert({
  'material',
  'syndrome',
})

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

if not args.material then
  qerror('Material not specified!')
end
if not args.syndrome then
  qerror('Syndrome not specified!')
end

addedSynMats = addedSynMats or {}

local matInfo = dfhack.matinfo.find(args.material)
if not matInfo then
  qerror('Material not found: ' .. args.material)
end
if matInfo.mode ~= 'builtin' then
  qerror('This script should only be used with inbuilt materials.')
end
local material = matInfo.material

local foundSyn = false
for _, syndrome in ipairs(df.global.world.raws.syndromes.all) do
  if syndrome.syn_name == args.syndrome then
    material.syndrome:insert('#', syndrome)
    if syndrome.flags.SYN_INJECTED then
      material.flags.ENTER_BLOOD = true -- reverses on reload
    end
    if not addedSynMats[args.material] then
      addedSynMats[args.material] = true
    end
    foundSyn = true
    break
  end
end

if not foundSyn then
  qerror('Syndrome not found: ' .. args.syndrome)
end

-- Clear added syndromes when unloading; prevents crashes when reloading
dfhack.onStateChange.InbuiltMatSynMonitor = function(event)
  if event == SC_WORLD_UNLOADED then
    for k,_ in pairs(addedSynMats) do
      local material = dfhack.matinfo.find(k).material
      material.syndrome:resize(0)
      addedSynMats[k] = nil
    end
  end
end

It worked as expected when I tested it (which is to say that I managed to transform my adventurer into a cat by jumping into a river), but I can't guarantee that it won't cause problems, so use with caution. I might add a -help printout and make it possible to specify multiple syndromes simultaneously at a later stage if no problems crop up.

To use, paste the code into a text editor and save it as a .lua file (such as inbuilt-material-syndrome.lua) in \hack\scripts. You can then run it either manually from the console after loading the a save, or place the command in onLoad.init in \raw to have it run automatically when a world is loaded (create this file if it doesn't exist already). Call as follows:

Code: [Select]

inbuilt-material-syndrome -material WATER -syndrome YOUR_SYN_NAME
Other inbuilt materials, such as "VOMIT", may also be specified. The syndrome needs to have been defined elsewhere.

[bloop_bleep]

Actually, this might be something where DFHack is not required, maybe. I believe in interactions you are able to specify a requirement that a given target must be in water. You can look up interaction token on the wiki for more information. Then you can make a CLEAN_SELF or defense interaction on the blizzard that targets SELF_ONLY and has the aforementioned water requirement.

[Su]

i hope this is the right place to ask - i'm wanting to make a script to automatically nickname my dwarves, but unfortunately i'm not very bright and the documentation is very confusing for me. is there anywhere else i can look to try and understand what i need to be doing?

manipulator is fantastic by the way, thank you.

[bloop_bleep]

I believe you can use dfhack.units.setNickname(<unit>, <nickname>) inside a lua script to change a unit's nickname, if that's what you were looking for.

[Su]

I believe you can use dfhack.units.setNickname(<unit>, <nickname>) inside a lua script to change a unit's nickname, if that's what you were looking for.

right - i gathered that much from the docs - but how do i tell what value <unit> should be, or if they already have a nickname?

[bloop_bleep]

Unit should be a lua userdata representing a DF unit. There are many ways you can get a unit object; use df.unit.find(<id>) to find one with a specific id, use df.global.world.units.active to get a list of all active units (units that are currently loaded) and df.global.world.units.all to get a list of all units recorded in the world.

If you want to explore the data exposed to you by DFHack, you could cursor over a unit, item, whatever, then run "gui/gm-editor" in the DFHack console. That will bring up a list of fields and their values for the selected object. You could also explore with the lua console you get when you run "lua" in the DFHack prompt.

For doing things automatically, look into the "eventful" utility.

[Su]

use df.global.world.units.active to get a list of all active units (units that are currently loaded) and df.global.world.units.all to get a list of all units recorded in the world.

ah, that's exactly the type of thing i'm looking for! where did you find out about these? they aren't referenced in the docs at all.

[PatrikLundell]

use df.global.world.units.active to get a list of all active units (units that are currently loaded) and df.global.world.units.all to get a list of all units recorded in the world.

ah, that's exactly the type of thing i'm looking for! where did you find out about these? they aren't referenced in the docs at all.

The DF structures are found under "df.global", with most of the interesting things found under "df.global.world". These structures can be explored using e.g. gui/gm-editor, or by reading the XML files (in the df structures project on github) mapping them. Documenting DF's internal structures would be a massive undertaking: it's hard enough to try to figure out what things are and describe them in XML form, and a fair bit of that is tentative. The way I got started on getting some kind of understanding of how the structures hang together was to read scripts that do something in the vicinity of what I'm looking for, use gui/gm-editor to view the corresponding structures, trying to understand the scripts, and build from there.

While df.global.world.units.active includes all active units, it is not restricted to your citizens, but includes every active unit, be it buzzard, goblin invader, dog, visitor, underworld denizen, or citizen. Thus, you'd need to filter the units to locate the ones you actually want. Also, I think the dead units are in that list as well.

[Su]

The DF structures are found under "df.global", with most of the interesting things found under "df.global.world". These structures can be explored using e.g. gui/gm-editor, or by reading the XML files (in the df structures project on github) mapping them.

..."world.units.active" doesn't seem to be defined anywhere in the df.global xml, though? am i looking in the wrong place? https://github.com/DFHack/df-structures/blob/a7dae6083d295821afe2ba91073d9b7547395b45/df.globals.xml

While df.global.world.units.active includes all active units, it is not restricted to your citizens, but includes every active unit, be it buzzard, goblin invader, dog, visitor, underworld denizen, or citizen. Thus, you'd need to filter the units to locate the ones you actually want. Also, I think the dead units are in that list as well.

ok. how would i go about doing that filtering? i think i might be able to get something working with that.

[Fleeting Frames]

Here's an example.

[bloop_bleep]

I usually don't bother with the XML files, to be honest. Mostly I just look at the header files for the DF structures in the library/include/df folder of my cloned DFHack repo.

[lethosor]

The DF structures are found under "df.global", with most of the interesting things found under "df.global.world". These structures can be explored using e.g. gui/gm-editor, or by reading the XML files (in the df structures project on github) mapping them.

..."world.units.active" doesn't seem to be defined anywhere in the df.global xml, though? am i looking in the wrong place? https://github.com/DFHack/df-structures/blob/a7dae6083d295821afe2ba91073d9b7547395b45/df.globals.xml

Things are split up across multiple files; it can be a bit of a pain to hunt them down sometimes. The world global is defined as being a pointer to the "world" type, which is defined in df.world.xml, and world.units is here.

I would really recommend using gui/gm-editor as an easier way to track these down - if you run "gui/gm-editor world", then selecting "units" then "active" would get you to the same spot. The script Fleeting Frames posted is a decent starting point.