Print

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

[Kat]

@Kat

I think this script might work

Code: [Select]

[code]
function z ()
 local unit = dfhack.gui.getSelectedUnit (true)
 local material = dfhack.matinfo.find ("PLANT:SINGLE-GRAIN_WHEAT:DRINK")

 local preference = df.unit_preference:new ()
 preference.type = df.unit_preference.T_type.LikeFood
 preference.item_type = df.item_type.DRINK
 preference.item_subtype = -1
 preference.mattype = material.type
 preference.matindex = material.index
 preference.mat_state = df.matter_state.Solid  --  Stupid for drinks, but everything seems to be specified as solid
 preference.active = true
 preference.prefstring_seed = 1  --  Or whatever
         
 unit.status.current_soul.preferences:insert ("#", preference)
end

z ()
[/code]

You'd have to replace "SINGLE-GRAIN_WHEAT" in the string on the third line with your plant name.
At least it added single-grain wheat beer to my test subject's preferences in addition to the pre-existing prickleberry one. Note that the unit to be subjected to the script has to be selected with 'v' or in the units list.

Looks like it works. Thanks muchly !

[taleden]

@taledan:

When did you slaughter? I suspect that poultry, once pregnant, can't get pregnant again until they stop being pregnant, which means you might have had the previous batch laid in later half of pregnancy.

I can provide saves for both turkey hens being pregnant and having laid eggs after first set hatched and of second clutch of turkey poults hatching with no turkey hens of gobblers alive (though as I've seen, that's not something to rely on).

How does a bird's pregnancy relate to their eggs, exactly? Is the bird flagged as not-pregnant as soon as the eggs are laid, so that they can become pregnant again while sitting on that clutch and thus be ready to immediately lay the next clutch when they hatch? Or do they remain technically pregnant as long as they're sitting on the eggs, until they hatch and can then immediately become pregnant again and then lay the next clutch?

From what I've seen hens will reliably lay their next clutch almost instantly (within a game day) after the previous one hatches, or rather, almost exactly 3 months after the previous clutch was laid (whether or not the previous eggs were removed or allowed to hatch). If the hens were able to get pregnant during that 3 month post-egg-laying time, that would imply that getting the population within bounds at any point during that period should let the next clutch be fertile, but that is definitely not the behavior I see. Rather, it looks to me very much more like the population has to be within breeding bounds (species cap, child ratio) at some (or all?) points between the hatching of the previous clutch and the laying of the next one.

That said, it's definitely possible that the male's presence is required at a different point than when the eggs are actually laid, which could explain your fertile-clutches-post-males behavior.

[Fleeting Frames]

Neither. Near as I can tell, bird's pregnancy ticks down like normal for six months, and if they lay eggs during that time those eggs are marked fertile. Since eggs take 3 months to hatch, can get 2 rounds off. (This mirrors the real life behaviour of some birds, but it applies to all in DF).

I presume population has to be within bounds both when the hen becomes pregnant and when they actually lay eggs,  but I haven't checked.

[taleden]

Oh, interesting; I guess I just assumed that their pregnancy duration would match their egg laying frequency, but I suppose it makes a kind of sense that their pregnancy mechanics were just copied from mammals with their 6 month cycles, and then the egg laying tacked on.

[taleden]

Is there already a script somewhere to add a hotkey to set yourself a reminder for later?

I often find I have so many projects and processes ongoing at once that I forget some and realize months later that I forgot to go back and designate the next phase of digging/construction/whatever because I was distracted looking at something else. It'd be great to have a hotkey to just let me type in a little reminder and a game date, and have that message pop up at the specific time; bonus points if it could also be tied to construction, building or job completion if such a thing is currently highlighted.

[Fleeting Frames]

Not to my knowledge. You can type into console stuff like :lua dfhack.timeout(10, 'days', function() dfhack.gui.showPopupAnnouncement('Do the dishes!',COLOR_GREEN) end)

It would be near trivial to add a hotkey and two (require 'gui.dialogs').showInputPrompts to it. Looking at job completions requires eventful, making that bit more complicated.

Really, the biggest problem is that you forget you have the option. An indicator can help against that and is the purpose behind my 3rd-party gui/indicator_screen.lua*, but displaying one everywhere can be undesirable due visual clutter, non-keybound commands and some plugins (automaterial, most importantly) requiring fitting top screen (haven't written a workaround yet). (A nonexistent plugin equivalent would be better, but would still suffer from first and needing compiles each version.)

*...(which I should update with the new features in dev copy, I guess.)

[taleden]

I don't think the reminder hotkey should have a permanent label on screen; a red hotkey just on the main menu list (i.e. down below the "Space: Resume   .: One-Step") would be great, but even that isn't necessary -- people who find they like the feature will soon remember what the key combo is anyway.

Regardless, I guess ideally it would have its own screen kind of like the job manager, listing all set reminders so they could be edited or deleted. Then a key to add/edit a reminder would just prompt for a date and then a text string, and on that date the game will pause with that text string as a popup alert. The date string could be flexible, so i.e. "125-*-1" would alert on the first of each month in the year 125, or "*-4-*" for the first of summer every year, or "+20 days" for 20 days from the current date. Oh, can lua scripts save data into the game save to be reloaded later, or is all state lost between sessions?

If I ever find some time to dig into dfhack's API I'll take a stab at this, but for now I just wanted to toss the idea out there in case it piqued anyone else's interest.

[Fleeting Frames]

That should remove the third issue, to my knowledge.

Pretty expansive idea; someone other than me would have to pick it up, though. At least while I still have scripts I want to write more.

Yup, dfhack's lua can totally save data in game save.

[thefriendlyhacker]

That should remove the third issue, to my knowledge.

Pretty expansive idea; someone other than me would have to pick it up, though. At least while I still have scripts I want to write more.

Yup, dfhack's lua can totally save data in game save.

There is also the far less arcane persist-table wrapper, which is AFAICT completely undocumented aside from the comments in its file in the lua folder for some reason, despite the fact that it is really useful.

[lethosor]

Then document it! The documentation was probably never written for that, but there's a reason it's open-source. I don't know enough to document it myself.

[Fleeting Frames]

Looking at it, I'd guess the some reason is "All stored values MUST be strings. Numbers can be supported later but are not yet supported.".

Still, storing tables recursively? Assigning/retrieving things with less code? Could be pretty useful, and didn't know about it. (It's not useful now, though, since I already wrote what I was storing, but...Hm. Could make for, say, persistent context-script pairs without editing init for each one.)

[Roses]

Looking at it, I'd guess the some reason is "All stored values MUST be strings. Numbers can be supported later but are not yet supported.".

Still, storing tables recursively? Assigning/retrieving things with less code? Could be pretty useful, and didn't know about it. (It's not useful now, though, since I already wrote what I was storing, but...Hm. Could make for, say, persistent context-script pairs without editing init for each one.)

I use persistent tables extensively in my scripts. A single fort that runs for a couple years could have thousands of them. They are extremely useful

EDIT: And yes, all stored information must be strings. An unfortunate limitation but one that is fairly easy to get around.

[Putnam]

I use persistent tables extensively in my scripts. A single fort that runs for a couple years could have thousands of them.

I've run profiling in Fortbent before I stopped using your class system and doing this caused something like 20% of the CPU time during processing of the game in a later fort and by itself was dropping the FPS below 100 in the early game, so I wouldn't recommend this too much. In fact, that's why I stopped using your class system; the heavy use of persist-table was causing massive slowdown. (Well, that and a bit of NIH syndrome and a lot of "wanted a wheel but got a whole car with it")

Personally, I abjure persist-table entirely cause I'd rather use the persistent config storage's ints and such.

Oh, that reminds me: persistent configuration storage uses only the names of the generated historical figures. Is there a particular reason for this? It could use, say, orientation flags without side effects.

[thefriendlyhacker]

I use persistent tables extensively in my scripts. A single fort that runs for a couple years could have thousands of them.

I've run profiling in Fortbent before I stopped using your class system and doing this caused something like 20% of the CPU time during processing of the game in a later fort and by itself was dropping the FPS below 100 in the early game, so I wouldn't recommend this too much. In fact, that's why I stopped using your class system; the heavy use of persist-table was causing massive slowdown.
...

I am almost afraid to ask, but...how many persistent tables are getting used in your scripts, Rose?  And how often are you reading from them? 

I ask because I have a TLCM randomizer script that keeps track of what creatures have had their appearance randomized via persist-table, and in a developed fort it could have as many as 3000 entries (3-4 records for the majority of civilized creatures that have been active at some stage).  The persistent entries only get read once per save load cycle before a non-persistent table of checked creatures is filled, but those entries are still there, and now Putnam has me worried that I am unwittingly nuking a fort's late game FPS.

[Putnam]

I probably would've stuck with roses stuff if I'd been able to get the JSON saving to reliably save with the game. I couldn't figure out a way to tell if quicksaving/autosaving was going on. The problem was more that every single table check was a persist-table check, IIRC.