Print

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

[0x517A5D]

@myk, @lethosor, please tell me about persistent configuration storage.

I think I see how dfhack.persistent.get(key) works.

Is there a (soft or hard) size limit on the value string?

Is it preferable to have one entry with a very (very) long string, or many (many) entries with empty strings, using the ints[] instead?

Or should I look for another way?  I could modify the map itself....

[lethosor]

If I’m reading df.map.xml right, it should be under df.map.feature.irritation_level.  Dividing that by 10K should give the chance of an attack.

Nope, that's not quite how you read the file. Each XML file is a collection of loosely-related types, and you are looking at the definition of the "feature" struct. So if you can find an instance of feature, it will have these fields.

This type is a little hard to search for since a lot of other types/fields also have "feature" in their name. I ended up searching for ='feature' and determined that there are no instances of the feature type itself, but there are a bunch of instances of subclasses of feature contained within subclasses of feature_init (these are all in df.map.xml still). The vector that 0x517A5D pointed out (df.global.world.features.map_features) is a vector of feature_init objects. It very likely contains subclasses of feature_init, but all of those do contain an instance of a feature subclass named "feature", so you ought to be able to get to the irritation fields from there, as shown by 0x517A5D.

Is there a (soft or hard) size limit on the value string?

Is it preferable to have one entry with a very (very) long string, or many (many) entries with empty strings, using the ints[] instead?

I believe there is no longer a hard limit. There used to be a 65k limit when we stored data as histfig names, but now it should be getting stored in JSON instead. You can verify this by looking for a .dat file in your save folder named something starting with "dfhack" - it should actually contain JSON.

That said, you should limit yourself to a reasonable amount of data. Users will probably not be happy if you write 1GB of data in there.

Or should I look for another way?  I could modify the map itself....

What exactly are you trying to store? I believe we still have a way to associate a custom bitmap with map blocks, if you're trying to save some data that relates to map tiles.

[myk]

a convenient way to store arbitrary data is to have a Lua table, encode it as JSON, and store it in a string (which gets persisted in a file as JSON-encoded JSON, but you don't have to be aware of that)

e.g.

Code: (lua) [Select]

local json = require('json')
local persist = require('persist-table')

local GLOBAL_KEY = 'myscriptname'

g_state = g_state or {} -- fill me with data (can be in nested tables)

-- call when your state changes and you want to make sure it is saved
local function persist_state()
    persist.GlobalTable[GLOBAL_KEY] = json.encode(g_state)
end

-- add a hook to load persisted state when a fort is loaded
dfhack.onStateChange[GLOBAL_KEY] = function(sc)
    if sc ~= SC_MAP_LOADED or df.global.gamemode ~= df.game_mode.DWARF then
        return
    end
    g_state = json.decode(persist.GlobalTable[GLOBAL_KEY] or '') or {}
end


[Eric Blank]

If I’m reading df.map.xml right, it should be under df.map.feature.irritation_level.  Dividing that by 10K should give the chance of an attack.

Also, @Myk, df.map.xml also says:

<int16_t name='irritation_attacks' comment='maxes at 10?'/>

Does that mean that there can be no more than 10 attacks by agitated creatures at one time?

gui/gm-editor tells me the structure is
    df.global.world.features.map_features[].feature.irritation_level
and
    df.global.world.features.map_features[].feature.irritation_attacks

Is it possible to get a function to read and display wilderness/cavern agitation levels, to say monitor how close you are to attracting agitated wildlife or cavern ambushes?

This horrible one-liner prints (some of) the data for each map feature.  But I don't think it covers the surface.  I don't know at the moment where that data is.  Run from the DFHack prompt.

Code: [Select]

:lua for i,mf in ipairs(df.global.world.features.map_features) do l=-1;pcall(function()l=mf.layer;end);print(string.format("feature %d %s %s-%s underground_region #%d irritation_level %d irritation_attacks %d",i,mf._type,df.layer_type[mf.start_depth],df.layer_type[mf.end_depth],l,mf.feature.irritation_level,mf.feature.irritation_attacks));end;
Sample output:

Code: [Select]

feature 0 <type: feature_init_subterranean_from_layerst> Cavern1-Cavern1 underground_region #11 irritation_level 4008 irritation_attacks 0
feature 1 <type: feature_init_subterranean_from_layerst> Cavern2-Cavern2 underground_region #31 irritation_level 7924 irritation_attacks 0
feature 2 <type: feature_init_subterranean_from_layerst> Cavern3-Cavern3 underground_region #56 irritation_level 11408 irritation_attacks 0
feature 3 <type: feature_init_magma_core_from_layerst> MagmaSea-MagmaSea underground_region #81 irritation_level 3180 irritation_attacks 0
feature 4 <type: feature_init_underworld_from_layerst> Underworld-Underworld underground_region #106 irritation_level 0 irritation_attacks 0
feature 5 <type: feature_init_outdoor_riverst> Surface-Surface underground_region #-1 irritation_level 288 irritation_attacks 0
feature 6 <type: feature_init_subterranean_from_layerst> Cavern1-Cavern1 underground_region #6 irritation_level 1760 irritation_attacks 0
feature 7 <type: feature_init_deep_special_tubest> MagmaSea-Underworld underground_region #-1 irritation_level 20040 irritation_attacks 0
feature 8 <type: feature_init_deep_special_tubest> MagmaSea-Underworld underground_region #-1 irritation_level 0 irritation_attacks 0
Hmm.  Outdoor irritation is kept separate from that, in a variable in plotinfo.

Code: [Select]

:lua print(string.format("outdoor_irritation:%d",df.global.plotinfo.outdoor_irritation))
Sample output:

Code: [Select]

outdoor_irritation:35000

Thanks. Ive tried putting these in .lua files in the dfhack-config/scripts folder, but when i attempt to call them from the dfhack gui launcher using lua -f "printial" or "printial.lua" it outputs "cannot open printial.lua: no such file or directory."

I usually dont try to mess with dfhack at all, so i really dont know what im doing. attempting to run the last one you gave there directly through the launcher only outputs "(lua command):1: ')' expected near '.'"

[0x517A5D]

Thanks. Ive tried putting these in .lua files in the dfhack-config/scripts folder, but when i attempt to call them from the dfhack gui launcher using lua -f "printial" or "printial.lua" it outputs "cannot open printial.lua: no such file or directory."

I usually dont try to mess with dfhack at all, so i really dont know what im doing. attempting to run the last one you gave there directly through the launcher only outputs "(lua command):1: ')' expected near '.'"

Scripts are normally invoked with just their name, without the '.lua' extension.  Does just 'printial' work?

The command 'lua -f printial.lua' is kind of advanced.  The necessary syntax would be 'lua -f dfhack-config/scripts/printial.lua'.  Since you put the script in the proper directory, it's normal to just use the script name, without the extension.

The next point that might trip you up is that the contents of the script should not have the text ':lua ' at the start of any line.  That syntax is for running a Lua command directly from the DFHack commandline.


@lethosor,

I want to record the coordinates of tiles that contain raw adamantine, for later use to replenish the tube (ala the tubefill plugin).

I thought to record coordinates in int32's with the math x + y*1024 + z*1024*1024 .

This morning, it occurred to me that I could further compress this as runs of data since the max run would be 16.  x + y*1024 + z*1024*1024 + (runlength-1)*1024*1024*256 would occupy an entire uint32.

My other thought was to create new vein definition for the affected tiles.  Gems in the pipe have vein definitions, the adamantine logically should as well.

I now see entry:getTilemask() which looks like the right way to do this.  Fifty to a hundred entries per pipe, block coordinates in ints[1],ints[2],ints[3], 16x16 tiles, 1 bit per tile would work.

To confirm,

• entry:getTilemask() will not collide with other scripts?  It's unique per key or per entry? 
• I call entry:getTilemask(mapBlock, true), and then the entry array magically has some subkeys representing a 16x16 one-bit structure, which I can then edit? 
• Is there an entry:setTilemask() or is it all handled by dfhack.persistent.save()?

There are no examples to crib from in hack/scripts or hack/lua.


Thinking about it, all of the stuff about .entry_id and .key and .value and .ints[7] and .mask.bits[16]; that's all legacy.  If we now store data in separate JSON files, that's the path forward.

[Eric Blank]

Thank you, that worked

[A_Curious_Cat]

@Myk, did you get my message about AtomicChicken replying to issue #3366?  What do you think of the matter?

[myk]

I responded on the issue, tl;dr: yes, a building teleporter looks perfectly feasible

[Boltgun]

Is there an easy way to clear the enemy status cache?

I'm a bit on a dead end to my old "corrupt enemies into friends" script. The script is simple and involve makeown, but it does not seem to clear hostility right. The targeted creatures walk through the fort before getting into a fight with what I believe to be specific units that see it as an enemy. Closing the save and reloading after running makeown prevent that issue.

I tried setting all the units cache slot to -1, setting the entire cache rel_map to -1 and slot_used to false. Got any idea what else I could do ?

[PatrikLundell]

@Boltgun

Have you cleared out any conflict they are involved in?

I essentially haven't done anything with DF for a couple of years (still waiting for a playable version, first it was the mess left when the Premium tangent started, and then it was the removal of keyboard support), so the memory is rather fuzzy, but there's a structure that keeps track of conflicts and you could deal with invasion triggered conflict cascades by setting the conflict level in these structures to a non lethal brawl level rather than to the death. I suspect (former) enemies may still have such a lingering hostility structure.

[Boltgun]

@Boltgun

Have you cleared out any conflict they are involved in?

I essentially haven't done anything with DF for a couple of years (still waiting for a playable version, first it was the mess left when the Premium tangent started, and then it was the removal of keyboard support), so the memory is rather fuzzy, but there's a structure that keeps track of conflicts and you could deal with invasion triggered conflict cascades by setting the conflict level in these structures to a non lethal brawl level rather than to the death. I suspect (former) enemies may still have such a lingering hostility structure.

That seems to be the case. In this case, the creature was in a cage but as soon as they are freed, the activities fills will conflicts. Time to make a script to sort that out. Thanks.

[myk]

Once you figure it out, could you update makeown? This sounds like it should always be done when making a unit part of the fort.

[Boltgun]

Once you figure it out, could you update makeown? This sounds like it should always be done when making a unit part of the fort.

I'll send you a PR once I get a proper script.

Edit: Turns out this is not the root of my problem. While it may be worth clearing conflicts if you use makeown after a fight, I don't have any before the fight breaks through. So it must be something else.

[Rumrusher]

Is there an easy way to clear the enemy status cache?

I'm a bit on a dead end to my old "corrupt enemies into friends" script. The script is simple and involve makeown, but it does not seem to clear hostility right. The targeted creatures walk through the fort before getting into a fight with what I believe to be specific units that see it as an enemy. Closing the save and reloading after running makeown prevent that issue.

I tried setting all the units cache slot to -1, setting the entire cache rel_map to -1 and slot_used to false. Got any idea what else I could do ?

ok so from my time messing with my own petition script uhh you might need to mess with the historical figure data as their relationship with the civ might be stained or with other folks.
like if someone remembers hey this person was part of another civ that tried to kill you, or 'remembers they were part of a raid to kill you' this might throw up some red flags and lead to an uneasy truce.

though I feel like the sending the person off on a mission and returning back should clear some of the checks.

[Boltgun]

I found nothing on the targets (2 out of 3 are not historical figures before running makeown), I currently going through all the units to find a relationship. I think that once these specific units see them, the game create conflict activities and it's a mess, no loyalty cascade tho.

On the bright side I found some stuff that should go into the transform script. You need to update the soul and the historical figure so the game find what blood it need to paint the ground with.

Update : I went through histfig_links, entity_links, site_links, and info.relationships and found nothing. I'm contemplating just splitting it in two, with invader being zombified and call it a day.