Print

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

[Roses]

Check the modtools folder in sparking. I already got an on-action event in Lua which is "fast enough", though I have been thinking avout moving it to C++.

Yes, that is what I am using now. Was also just pondering about moving it to C++, but since you are the author of what I am using right now, and you are also thinking about it, I'll let you decide how best to handle that. I think you are right that it is fast enough, at least in my limited testing.

"df-structures" has been its own repo since structure definitions were implemented in XML (around 2011). "scripts" was split out in 2016, and has issues disabled, since it usually makes more sense to report them in the "dfhack" repo anyway. PRs always need to be made in the repo containing the code being modified, though.

I loosely keep track of issues/PRs with projects, to make it a bit easier to see what issues/PRs were addressed in a release, but they need to be manually added currently: https://github.com/orgs/DFHack/projects/

Wow, 4 years ago already. Crazy how time flies, feels like just a couple years ago that I started using DFHack. Thanks for the projects link.

[Atkana]

Fair warning, this post is basically an incoherent mess of topics that I've been building up to posting. If you're just looking for one post to answer, skip to the last one, since that's really what I came for :b
Eventful's interaction event still seems to be broken (though I think it has been for some time)
The following doesn't seem to trigger in any mode (I'd done the testing in r2, but didn't notice anything in the changelogs about fixes to it, so I assume the same still applies to the current version):

Code: [Select]

eventful = require "plugins.eventful"

eventful.enableEvent(eventful.eventType.INTERACTION,1)
eventful.onInteraction.test = function()
print("An interaction happened!")
end

Just thought I'd bring it up in case for some reason it hasn't been already
While messing around with the action menu (viewscreen_layer_unit_actionst) for a script, I noted down a few possibilities for currently unmapped values:

• anon_1 might be where reaction categories are stored, based on how the already mapped reactions entry works. Basically, the reactions entry is an indexed table the length of the number of options available in the "create" list of the menu. Each of the entries links to the reaction associated with the option at that position in the create list, however since reaction categories also appear in the create list, and aren't reactions, the entries at their position in the table are nil, rather than linking to a reaction. Since the information for what on the create list is actually a reaction category (rather than a reaction) has to be stored somewhere, and anon_1 happens to grow and shrink in size to match the number of options in the create list, it makes sense that that information is probably stored there (possibly following a similar format to reactions, but with options for reactions being nil).
• anon_8 might be options for natural abilities. As a creature with 3 natural abilities, it's the only option with a length of 3. With 2 abilities, it's length of 2.
• anon_15 might be related to the compose option. A unit that knows 1 form of poem has that at length 1. A unit that knows no forms has length 0.
• anon_11, anon_12, and anon_13 are in some way related to acquired powers. While they were previously all length 0, after learning a necromancer secret with 2 powers, anon_11 became 2 length, while anon_12 and anon_13 became 1 length.

On the topic of finding out what everyone's working on: in addition to checking github, we could also encourage scripters to make more use of the What's going on in your modding? thread as a way of keeping people up to date. I for one will at least try to post more there when working on my own stuff.
I've been going crazy trying to figure out how, as a lua scripter, I'm supposed to make data persistent.

• There's the persistence module that got added/updated, but I'm not sure how that works. The documentation for dfhack.persistent hasn't changed at all since it was added, so does it just work the same as it always did? How does it work? As someone who's more of a scripter than a programmer, the explanation is a bit too confusing for me. Am I misunderstanding that entries seem to each be limited to a single string / 7 ints? If so how come? I thought that having json as the storage method would mean that it wouldn't need to be so limited (though that could just be because it's old documentation).
• There's persist-table, which hasn't been updated since the persistence module change, and notes that it is limited to only saving strings. Whereas just directly using the json library to save data wouldn't have that limitation (if I've read up on jf json correctly).
• Then there's just creating my own method for saving that uses the json library. How would I go about ensuring that I save the data at the right times? I vaguely know that with the persistence module, there was an event added to tell plugins to save before the world is unloaded. Is that event just for plugins, or is it also available to lua scripts, and if it is, how can I access it? If it's not available, is there anything better than this hack to reliably trigger saves during autosaves?

[PatrikLundell]

@Atkana:
While the suspicions regarding mapping of DF elements aren't exactly out of place in this thread, it's probably better to note it in an issue on github (or do that as well: things in this thread tend to get forgotten if not acted upon fairly quickly, while issues have a longer shelf life), or, even better, continue the investigation to the level of fairly certain and produce a Pull Request to update the fields on github.

[lethosor]

The first one would also warrant a bug report.

As for persistent data: the limitations of the "old" system were due to it saving data in histfigs - specifically, creating histfigs with negative IDs and using fields of their language_name allowed for storing a string name, a string value (both of these limited to around 32k characters), and 7 integers. The underlying storage backend uses JSON now and no longer has these limitations, but the APIs on top of it (including dfhack.persistent and persist-table) haven't changed much yet (the main difference is that the string limitation no longer applies; we could also bump up the number of integers allowed as an intermediate improvement).

You are correct that there is a "pre-save" sort of hook that allows plugins to make any last-minute changes before data is saved (although it could also be used for any custom data-saving logic). The exact logic that triggers it is here: https://github.com/DFHack/dfhack/blob/de21e0cdb86b9002cdcadabd5e8f1dbb68270467/library/Core.cpp#L2008-L2013
Unfortunately, this doesn't appear to be exposed to Lua yet. You could likely catch regular saves with an onStateChange handler, but not autosaves/"quicksave"s. Assuming this would be useful to have in Lua, a GitHub issue would help keep track of this as well.

[Atkana]

Alright, I've dropped issues for each of them. I should really get in the habit of doing them more often in the future

[Fleeting Frames]

Lua-wise, I've had some success checking df.global.ui.main.autosave_request every tick in earlier versions, though haven't extensively tested:

Code: [Select]

local function repeatfunction(rfunc, N)
--repeats a function every N frames, until the function returns false or nil
local myrfunc

myrfunc = function ()
  local timeoutid = dfhack.timeout(N, "frames", function(options)
if rfunc(timeoutid) then myrfunc() end
   end)
end

myrfunc()
end

function detectSave(func)
if not func then return false end
--detect quicksaves
repeatfunction(
function()
if not already_saved and (
df.global.ui.main.autosave_request --quicksaves
or dfhack.gui.getCurFocus()=="options" --normal saves, maybe??
) then
already_saved=true
func()
end
return true
end
,1)
--set already_saved to false every six seconds
--(assumes the player doesn't do anything that changes persistent values in less than that)
repeatfunction(
function()
already_saved=false
return true
end
,600)
end

(With the func being saving persistent data entry.)

Didn't know about the 32k characters being the limitation and also the limitation on keys. I've tried tossing internal JSON encodings into value field, but with that length could do sparse single tile-based tables.

[lethosor]

In case it wasn't clear: the 32k limit only applied to the old backend that stored data in histfigs. Since 0.44.12-r3, that isn't an issue, so you can make keys and values as long as you want (within reason, of course).

[lethosor]

0.47.04-r4 is up! https://github.com/DFHack/dfhack/releases/tag/0.47.04-r4

Lots of buildingplan and quickfort improvements here, as well as several fixes.

[A_Curious_Cat]

0.47.04-r4 is up! https://github.com/DFHack/dfhack/releases/tag/0.47.04-r4

Lots of buildingplan and quickfort improvements here, as well as several fixes.

Merry Christmas to you, too!

[myk]

Woohoo! Thank you, Lethosor!

[Iä! RIAKTOR!]

Could someone help me with vampire race? I just need one script.

They has blood in raws. But when they are part of fort (like citizen or, if mute caste, as livestock), they get removing of HAS_BLOOD (like generated undead syndromes). But they get HAS_BLOOD back when counter trigger DRINKING_BLOOD has value from 1 to 20. And HAS_BLOOD will be removed when vampire lost DRINKING_BLOOD counter.

[Pyrite]

Is there a script for removing or fulfilling the need for decent meals? I find this need so frustrating and difficult to fulfill on many dwarves that I basically consider it a bug. Having a dwarf constantly get bad thoughts because I can't provide a source of magpie meat or millet beer gets old fast.

I can deal with all the other needs, as finicky as they are, but I'd really just like to kick this one to the curb.

[Atkana]

Is there a script for removing or fulfilling the need for decent meals? I find this need so frustrating and difficult to fulfill on many dwarves that I basically consider it a bug. Having a dwarf constantly get bad thoughts because I can't provide a source of magpie meat or millet beer gets old fast.

I can deal with all the other needs, as finicky as they are, but I'd really just like to kick this one to the curb.

You should be able to satisfy all of your citizen's need for decent meals with:

Code: [Select]

modtools/set-need -edit -need EatGoodMeal -focus 400 -citizens
Or alternatively, you could get rid of their needs to eat a good meal with

Code: [Select]

modtools/set-need -remove -need EatGoodMeal -citizens

Execute one of those periodically (or set up something using repeat to repeat it automatically), and you won't have to worry about that annoying as heck need again

[Pyrite]

Thank you so much! That seems to have worked, and I chose to just remove the need entirely as that seems like the most balanced option. I really wish I could actually modify it to be satisfied with meals of a certain value, with favorite ingredients being present like doubling that value for the dwarf, and maybe having the value set by some personality trait. But having every single ingredient conceivable is just not a reasonable requirement for running a low-stress fortress.

That leaves the needs for friendship and family as the most difficult ones to satisfy, but at least I can consistently solve those by shoving dwarves together into a tiny locked room for a couple of seasons.

[Rumrusher]

hmm looks like ui_advmode.unk_v42_1 is tied to adventurer performances ala the sermons.
though since most of the content there is userdata I don't think it's possible to modify any of it.
though I don't know if this is true in the new version of DFhack.