Print

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

[Roses]

Did some more research by comparing a spawned unit in arena mode with the secret (interactions work ok) with one that received the syndrome.
The wound is properly created (in 'body') by DF when the syndrome is added. It contain a curse info with all the proper data, said curse is then applied to the unit.
The only divergence was the lack of a reinfection id and count, but after modifying syndrome-util to add it, nothing changed.

Everything in body, in curse and in syndrome is adequate. I'm still searching...

Quoting myself, but after figuring it out I believe you might be interested.
Dfhack wise, the syndrome is properly added as far as interaction goes. But Kruggsmash made a video about turning dwarves into necromancers so I knew that it had to work.
I tested with an inhaled stone that provides interactions and the units were not using it either, so taking inspiration from generated necromancy I removed usage hints and it worked.

As it seems, ATTACK is not working anymore, but no hint now has the same effect (instead of "all the time" from 0.34) and the unit will use the interaction in combat. The arena does not respect those rules, so it's probably a bug. Mystery... kinda solved, I guess?

Spoiler: The interaction (click to show/hide)

[INTERACTION:HELLFIRE_SECRET]
   [I_SOURCE:SECRET]
      [IS_NAME:the secrets of hellfire]
      [IS_SPHERE:FIRE]
      [IS_SECRET:SUPERNATURAL_LEARNING_POSSIBLE]
      [IS_SECRET:MUNDANE_RESEARCH_POSSIBLE]
      [IS_SECRET:MUNDANE_TEACHING_POSSIBLE]
      [IS_SECRET:MUNDANE_RECORDING_POSSIBLE:objects/text/book_instruction.txt:objects/text/secret_fire.txt]
   [I_TARGET:A:CREATURE]
      [IT_LOCATION:CONTEXT_CREATURE]
      [IT_REQUIRES:CAN_LEARN]
      [IT_REQUIRES:CAN_SPEAK]
   [I_EFFECT:ADD_SYNDROME]
      [IE_TARGET:A]
      [IE_IMMEDIATE]
      [IE_ARENA_NAME:Pyromaniac]
      [SYNDROME]
         [SYN_NAME:Pyromaniac (fireballs, directed ash, firejet)]
         [SYN_CLASS:MAJOR_POWER]
         [SYN_NO_HOSPITAL]
         [CE_DISPLAY_TILE:TILE:64:4:0:1:START:0]
         [CE_DISPLAY_NAME:NAME:pyromaniac:paromaniacs:pyromaniac:START:0]
         [CE_CAN_DO_INTERACTION:START:0]
            [CDI:ADV_NAME:Breath flames]
            CDI:USAGE_HINT:ATTACK]
            [CDI:INTERACTION:MATERIAL_EMISSION]
            [CDI:BP_REQUIRED:BY_CATEGORY:MOUTH]
            [CDI:FLOW:FIREJET]
            [CDI:TARGET:A:LINE_OF_SIGHT]
            [CDI:TARGET_RANGE:A:10]
            [CDI:MAX_TARGET_NUMBER:A:2]
            [CDI:WAIT_PERIOD:120]
            [CDI:VERB:exhale a cloud of fire:exhales a cloud of fire:NA]
         [CE_CAN_DO_INTERACTION:START:0]
            [CDI:ADV_NAME:Hurl fireballs]
            CDI:USAGE_HINT:ATTACK]
            [CDI:INTERACTION:MATERIAL_EMISSION]
            [CDI:BP_REQUIRED:BY_CATEGORY:HAND]
            [CDI:FLOW:FIREBALL]
            [CDI:TARGET:A:LINE_OF_SIGHT]
            [CDI:TARGET_RANGE:A:10]
            [CDI:MAX_TARGET_NUMBER:A:2]
            [CDI:WAIT_PERIOD:30]
         [CE_CAN_DO_INTERACTION:START:0]
            [CDI:ADV_NAME:Raise cloud of ash]
            [CDI:USAGE_HINT:FLEEING]
            [CDI:BP_REQUIRED:BY_CATEGORY:HAND]
            [CDI:INTERACTION:MATERIAL_EMISSION]
            [CDI:MATERIAL:ASH:TRAILING_DUST_FLOW]
            [CDI:VERB:conjure a cloud of ash:conjures a cloud of ash:NA]
            [CDI:TARGET:A:LINE_OF_SIGHT]
            [CDI:TARGET_RANGE:A:10]
            [CDI:MAX_TARGET_NUMBER:A:1]
            [CDI:WAIT_PERIOD:90]
         [CE_CAN_DO_INTERACTION:START:0]
            [CDI:ADV_NAME:Spray jets of fire]
            CDI:USAGE_HINT:ATTACK]
            [CDI:INTERACTION:MATERIAL_EMISSION]
            [CDI:BP_REQUIRED:BY_CATEGORY:HAND]
            [CDI:FLOW:FIREJET]
            [CDI:TARGET:A:LINE_OF_SIGHT]
            [CDI:TARGET_RANGE:A:5]
            [CDI:MAX_TARGET_NUMBER:A:2]
            [CDI:WAIT_PERIOD:150]
            [CDI:VERB:conjures a jet of fire:conjures a jet of fire:NA]

It is added with :

Code: [Select]

local synName = 'Pyromaniac (fireballs, directed ash, firejet)'
dfhack.run_script('modtools/add-syndrome', '-target', unit.id, '-syndrome', synName, '-resetPolicy', 'DoNothing')

That does not explain issues with bleeding or drowsiness. Those symptoms are a little complicated as those counters were not in body, probably in body parts. Again, it is worth testing it with inhalation before going further.

Interesting results, I wonder why USAGE_HINT:ATTACK isn't working anymore. Was that information anywhere in the change logs? I think I need to start doing all my testing in fortress mode, it seems arena mode has some issues.

[lethosor]

Thanks Quietust - this should relieve me of much future puzzling !

You can also use df.type.is_instance() instead of link:getType():

Code: [Select]

unit = dfhack.gui.getSelectedUnit()
for _, link in ipairs(df.historical_figure.find(unit.hist_figure_id).histfig_links) do
    if df.histfig_hf_link_deityst:is_instance(link) then
        deity = df.historical_figure.find(link.target_hf)
        -- do something with deity
    end
end


[dragdeler]

There seems to be a problem where working pumps don't pump, after you changed a tile upon which a machine part lies with "tiletypes".

god that'll teach me not to cheat instead of spending a day to do minor improvements... i'm so done

[Pvt. Pirate]

i got problems with mousequery not responding to the mouse being in the bottom or right border.
this did not occur in 43.x.x but only in 44.x.x
i'm using a 5:4 screen and running DF windowed 1280x960.
maybe there's something wrong with the calculation of the position and/or size of the areas for mouse scrolling.

[iceball3]

Also, I'll test it again tomorrow, but I'm pretty sure that the stonesense bundled in dfhack is currently non-functional. Wouldn't even close when i tried to force it to, aside from closing DF.

[KittyTac]

Can you write me a script that teleports you in adv mode to the cursor with "l"? It would make navigating laggy areas more bearable.

[Quietust]

Thanks Quietust - this should relieve me of much future puzzling !

You can also use df.type.is_instance() instead of link:getType():

Code: [Select]

unit = dfhack.gui.getSelectedUnit()
for _, link in ipairs(df.historical_figure.find(unit.hist_figure_id).histfig_links) do
    if df.histfig_hf_link_deityst:is_instance(link) then
        deity = df.historical_figure.find(link.target_hf)
        -- do something with deity
    end
end


You can, but it's generally much more efficient to use .getType() - the only time you really need to use is_instance is when you're dealing with a class that doesn't have a .getType() vmethod (e.g. a Viewscreen).

[mifki]

Thanks Quietust - this should relieve me of much future puzzling !

You can also use df.type.is_instance() instead of link:getType():

Code: [Select]

unit = dfhack.gui.getSelectedUnit()
for _, link in ipairs(df.historical_figure.find(unit.hist_figure_id).histfig_links) do
    if df.histfig_hf_link_deityst:is_instance(link) then
        deity = df.historical_figure.find(link.target_hf)
        -- do something with deity
    end
end


You can, but it's generally much more efficient to use .getType() - the only time you really need to use is_instance is when you're dealing with a class that doesn't have a .getType() vmethod (e.g. a Viewscreen).

I always use instance._type myself. It should be the most efficient as it's already populated, and doesn't depend on getType() availability.

Obviously the main difference between all this and is_instance() is that the latter can be used to check if an instance is of a subclass of a base class, but I don't think this is ever needed, so it's an overkill.

[strainer]

I think is_instance is nice and descriptive, but here Im getting the type of each hflink and switching on it to grow a digest which is part of making a condensed 2 or 3 line description of the units circumstances, likes, strongest traits and beliefs. Think im still missing a few like 'friendly terms' though, leaving this for now...

The info displays while the unit is focused in the list so they can be browsed without rifling through other screens. If the process runs fast enough ill do it for the whole list when screen is loaded so efficiency is relevant, if it causes any delay for maybe a couple of hundred units, it can run individually on the units the first time they are focused.

[strainer]

Just to note - I havent found the relationships of friends, friendly terms, aquaintances, or detailed family relations though those could be constructed from mother,father and children which appear in figure.histfig_links. Aunts, cousins, grandfather, "SonEldest5" ... etc are enumed in histfig_relationship_type.h (which is not the type of histfig_links).

Some more correctly enumed relations like enemy and squad members appear in figure->entity_links

There is a small flat array in unit named relationship_ids which only contains refs to 10 things like mother, father, pet, ridermount. These are the first 10 enums in unit_relationship_type.h. Perhaps that array is longer than currently defined, but it doesnt seem capable of containing multiple links of same type anyhow. Maybe its just a small cache of those first 10 rels.

Finally? there is a figure.info.relationships.list which looks a likely suspect, but is mostly anonymous as yet.

Seems like an area to look out for / fill out in the future.

[iceball3]

Hmm, just had a sudden "hard close". Not exactly sure what caused it.
Has taverns or missions been tested with DFhack yet?

[strainer]

I found a bugged save after a hard close can possibly be fixed by escaping immediately after load, selecting export local image, and cycling through the levels. Then the game might save again and be playable, to observe the hard close again...

[lethosor]

There is a small flat array in unit named relationship_ids which only contains refs to 10 things like mother, father, pet, ridermount. These are the first 10 enums in unit_relationship_type.h. Perhaps that array is longer than currently defined, but it doesnt seem capable of containing multiple links of same type anyhow. Maybe its just a small cache of those first 10 rels.

It cannot be longer than it is currently, because if that were the case, everything following it (including unit.job, unit.body, unit.counters, unit.status, and more) would be wrong, because it's a C array ("int32_t relationship_ids[10];" in df/unit.h).

Hmm, just had a sudden "hard close". Not exactly sure what caused it.
Has taverns or missions been tested with DFhack yet?

I think the word you're looking for is "crash". There aren't any other situations I can think of where DF would suddenly close except when it crashes.
As for your question, are you asking if DFHack not being tested with taverns/missions could be the cause of the crash? If so, the answer is almost certainly no, because if DFHack research hasn't been done on those things, nothing in DFHack can possibly touch them (unless layouts of globals like "world" are wrong, but those have been fixed for 0.44). Also, taverns were new in 0.42, so they're not likely to be a cause of any new bugs/crashes related to DFHack at this point.

I found a bugged save after a hard close can possibly be fixed by escaping immediately after load, selecting export local image, and cycling through the levels. Then the game might save again and be playable, to observe the hard close again...

If DF crashes, it will not touch the actual save folder itself at all (it saves temporary files to data/save/current, but ignores them when you restart DF). In other words, a crash (except when saving the game) will not permanently affect your save. I highly doubt that exporting images has anything to do with a crash, because that feature pretty much only reads from the map and hasn't been changed in years. If you think you observed it affecting a crash in some way, then that crash is probably due to undefined behavior somewhere, which means that exporting a map could affect it somehow, sometimes, if you're lucky, due to any number of semi-random factors (that could vary depending on your system, etc.). And I know I'm being pedantic, but please don't be afraid to use the word "crash" - it's a lot easier to search for.

[Max™]

Can you write me a script that teleports you in adv mode to the cursor with "l"? It would make navigating laggy areas more bearable.

Write one for you, personally?

Absolutely not.

Already have one?

Probably.

Code: (flashstep.lua) [Select]

--Teleports unit to cursor
--[====[

flashstep
=========
A hotkey-friendly teleport that places you where your cursor is.

]====]
function flashstep(flash,step)
    local flash = df.global.world.units.active[0]
    local step
        if df.global.ui_advmode.menu == df.ui_advmode_menu.Look then
            step = df.global.cursor
        else
            qerror("No [l] cursor located! You kinda need it for this script.")
        end
    local unitoccupancy = dfhack.maps.getTileBlock(flash.pos).occupancy[flash.pos.x%16][flash.pos.y%16]
        flash.pos.x = step.x
        flash.pos.y = step.y
        flash.pos.z = step.z
            if flash.pos.x==step.x then
            local stepvisibility = dfhack.maps.getTileBlock(flash.pos).designation[flash.pos.x%16][flash.pos.y%16]
                stepvisibility.hidden=false
            end
    if not flash.flags1.on_ground then unitoccupancy.unit = false else unitoccupancy.unit_grounded = false end
end
flashstep(flash,step)


[strainer]

Lethosor:   "Maybe its just a small cache of those first 10 rels." - It *cannot* be longer than it is currently, ...

Ok, thats something. We all still seem to be in the situation that *no one here knows* where to find units friends, friendly terms, aquaintances... And whatever info is in figure.info.relationships.links is unkeyed.

Im just putting that info as I find it, here, for others to notice, or duckduckgo later.

Lethosor: a crash (except when saving the game) will not permanently affect your save.

I wouldnt have expected it to because I noticed task-killing a game is usually fine, but I have bugged dozens of game saves, with silly division by zero, infinite loops or null pointer crashes occuring while in manipulator (while not doing any saving). I dont know the mechanism but a hard crash while in manipulator, on linux, can kill a save, and the process I described can repair it (not necessary to actually export the levels, just scan through them - maybe even just open and close the feature).