Print

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

[FantasticDorf]

A plugin that freezes grazing states/stops grazing hunger, so that we can maintain animals with 'problematic' grazing habits without in-game workarounds (keeping them exclusively as pets/in cages) or altering the grazing co-efficient so they don't starve.

Either by counting all creatures co-efficients then passively nullifying numbers above a certain level or allowing the player to target animals wished to inflict with the plugin (such as tame elk-birds) ideally.

[Bumber]

A plugin that re-evaluates which tiles are underground vs. above ground.

[lethosor]

What exactly are you thinking of?

[Bumber]

Basically, a script that redoes this check:

The entire fortress site starts out as Inside Dark Subterranean. After that, a ray for Outside and a ray for Light Above Ground falls straight down from the highest z-level for every (x,y) position on the local map, changing each tile's modifiers until something that blocks that particular "ray" is encountered.

Constructions (Edit: maybe only walls) would block the ray, allowing a return to subterranean darkness in tiles that have been exposed to light. The script could run map-wide, or on a single column.

Ideally, we could have a feature that automatically calls the column check whenever a light above ground space is filled via construction or obsidian cast.

[FantasticDorf]

Id like to look into a script that makes dwarves queue up 'talk' for the next-action field in the gui/gmeditor since while they're hanging around with no job they don't seem to activate this at all, mostly thinking about wandering to the next spot, least not frequently in a effort to get them to socialise through keeping the script running.

Initially, testing this made them move over ontop the tile of a friend whom they embarked with and gave them the spoke to thought, though im not sure if this even works outside of a meeting zone.

The player targeting dwarf A and dwarf B locked in a burrow or shared public space to run 'talk' on each other until they develop some social skills and relationship traction would i think would be the useful application though a autocoupling script to make dwarves seek others automatically when needs get too low would be over and beyond.

[Putnam]

What, a script that basically just force-inserts a talk action into dwarves who are near other dwarves? Not a bad idea at all, actually. Main problem is there's a lot of crust in the talk part of the action union, as you can probably see (all the unk values, boy!). I'd have to do research into determining what they refer to. It should be possible by just talking in adventure mode, mind.

[FantasticDorf]

Talking subjects are not important in fortress mode, unless of course there are special interactions with spilling the beans to visitors about artifacts (in which animals in a resolved bug shouldnt have been doing at all) I just used the general 'invasion' talk subject that was the default and closest value in the list when i went through to inspect it to serve as something to talk about.

Something nice and non-conflictive for lack of arguements unless they disagree that the defenders deserved it. Though i think dwarves would autonomously pick a topic if abstractly prompted without gm/guieditor, but it may not be the case like they say.

Spoiler (click to show/hide)

the ones that might be relevant to social/break-related things being "TIME_SINCE_BREAK" and "ON_BREAK". In lua, these counters (and a lot more) can be found in the unit's status.misc_traits (provided they're active/whatever)

Hm, I can try those, although I'm not sure they're used any more in the current game version; in my fort of 112 citizens, not a single one has a misc_trait with id 16 (TimeSinceBreak) or 17 (OnBreak). Also, the problem I'm having isn't just with dwarves aborting my forced social activity for an actual job (teal text); they'll take a few steps pathing toward my activity and then stop and switch to a different idle activity (i.e. stop walking to the temple and instead go to Individual Combat Drill or to the library to read). That's why I was hoping to figure out the criteria for Purple! idle activities, to maybe get them to stick with what I assigned and not switch to something else.

Some quotes from the DFhack main thread

The strength of a need can be modified in the unit's status.personality.current_soul.personality.needs, by changing its focus level. I know that a value of 400 is what it's set to when the need is met, and I believe that the value lowers as they get less focused, into the negatives. The numbers listed on the wiki are probably right for reference. You might be able to get dwarves having purple needs by just setting the focus value super low.

Yes, those are the focus level values that I'm scanning for dwarves with severely unmet needs (for example I had a military dwarf with -200000 PrayOrMedidate, which I think is the lower limit, because he would always drill in his idle time and never pray).

After some experimentation though, I'm pretty sure the Purple! indicator isn't really very meaningful. I just compared the need data for a bunch of dwarves currently engaged in purple "Socialize!"/"Pray!" and green "Socialize"/"Pray" activities, and the determining factor seems to be whether the dwarf has Socialize, PrayOrMedidate, BeCreative, Excitement or AdmireArt focus levels of -10000 or lower, but there was no link between the activity and the actual urgent need -- a dwarf with -10k Socialize and +10k PrayOrMedidate would still show "Pray!", a dwarf with -10k BeCreative and +10k everything else would still "Socialize!", etc.

I think these might impede a possible socialisation script also @Putnam, though the latter observation is correct and a known issue anyway since you can manually cap off a dwarf at maximum value like Talden says for no gameplay difference simply because the zone is very posessive of dwarves who walk into it.

Purple and green don't really matter overall because its all the same with different scopes of activities to give dwarves too much time into repositioning constantly in the location zone, and not talking between listening to some poetry or doing a little jig.

[Blucher]

I'd like a script similar to catsplosion but has only adult creatures give birth.  I was looking at the rejuvenate script to see if I could do it myself, but I'm just not knowledgeable enough.  Does something else already exist?

I have a fort from a dead/dying civ and the dwarves aren't getting "busy" enough fast enough.

[bloop_bleep]

I just found this thread, and it might be useful to know that power-using workshops are indeed definitely possible, as I have implemented them (as wheels) in the moving-machines plugin linked in my sig. Although, they suffer the same problem as steam engines, where they can only directly connect to machine components built after them.

[lethosor]

I'd like a script similar to catsplosion but has only adult creatures give birth.  I was looking at the rejuvenate script to see if I could do it myself, but I'm just not knowledgeable enough.  Does something else already exist?

I have a fort from a dead/dying civ and the dwarves aren't getting "busy" enough fast enough.

If you want something similar to catsplosion, looking at catsplosion is your best bet. I don't know how rejuvenate is similar.
Of note: it already accepts races as arguments (e.g. "catsplosion DWARF" would probably do what you expect, but it would apply to non-adult dwarves as well). Filtering just adults shouldn't be too hard to add.

I just found this thread, and it might be useful to know that power-using workshops are indeed definitely possible, as I have implemented them (as wheels) in the moving-machines plugin linked in my sig. Although, they suffer the same problem as steam engines, where they can only directly connect to machine components built after them.

I think building-hacks implements power-using workshops already (although certainly not as advanced as those!).

[Warmist]

I just found this thread, and it might be useful to know that power-using workshops are indeed definitely possible, as I have implemented them (as wheels) in the moving-machines plugin linked in my sig. Although, they suffer the same problem as steam engines, where they can only directly connect to machine components built after them.

I think building-hacks implements power-using workshops already (although certainly not as advanced as those!).

Also related: building hacks moves everything to lua land so you don't need to track it yourself. It even allows you to change power usage/generation and keeps track of that. I've also looked into the issue of machine connections but it was so long ago that i'm not sure what must be done to fix it. Toady One made some functions virtual for that to be easier however i think because they are used in non-virtual context the compiler optimizes out the virtual indirection and replaces with simple call. Related issue: here

[FantasticDorf]

A plugin that seasonally (and selectively) turns location meeting areas off (unassigns and reassigns to location id if it can when re-enabled) because this is the only way im dragging my dwarves out of the tavern. I use other non functional furniture like rented rooms in order to keep their presence constantly within the fortress itself so the outside world isn't unaware of it or disrupt anybody like monster hunters and currently occupied long term guests.

I unassign my main locations off for spring and summer, this means managing 10 different areas (4 main, 6 minor) of which im not finished building all my main sites yet fully, and it would be a great help to have this in the background for me as my fortress expands.

[lethosor]

Toady One made some functions virtual for that to be easier however i think because they are used in non-virtual context the compiler optimizes out the virtual indirection and replaces with simple call. Related issue: here

Well, the compiler optimizes out the redirection in DF's calls. The vtable is still there, and I'm pretty sure you can call the method from DFHack, which is what you need (interposing DF's calls wouldn't work, though).

A plugin that seasonally (and selectively) turns location meeting areas off (unassigns and reassigns to location id if it can when re-enabled) because this is the only way im dragging my dwarves out of the tavern. I use other non functional furniture like rented rooms in order to keep their presence constantly within the fortress itself so the outside world isn't unaware of it or disrupt anybody like monster hunters and currently occupied long term guests.

I unassign my main locations off for spring and summer, this means managing 10 different areas (4 main, 6 minor) of which im not finished building all my main sites yet fully, and it would be a great help to have this in the background for me as my fortress expands.

Does toggling the "active" flag do what you want? Reassigning zones to locations sounds a little hard, but if the active flag does what I expect it to (namely, disabling the zone while preserving its settings), that would be pretty easy to write a tool for - just toggle building.zone_flags.active on specific zones.

[FantasticDorf]

Unfortunately not, active meeting zones/locations have no effect other than deterring tavern keepers from serving wine, dwarves will still visit the place anyway to socialise/pray etc. It only stops no-job idlers from walking in there simple because the meeting zone exists and getting stuck in the long-run.

The only pernament solution has to be unassigning the location unfortunately, not that i have to retire the location itself, just turning it off over the 'i' zone for a bit. Take for example that my monster hunter's long-term resident occupation holders don't leave to actually hunt until i do this, then retire for autumn and winter to hang out and socialise all the while waiting for my scheduled spring-summer shutdown.

[bloop_bleep]

Re: machine connections.

Warmist, have you previously tried interposing canConnectToMachine() in this way?

1. If *this is a tracked machine component, then use the normal routine in determining whether it should be connected, already present in your code.
2. Otherwise:
2.1. For every tile in the machine:
2.1.1. If the tile contains the tracked machine component "other", then call other->canConnectToMachine() passing a df::machine_tile_set containing only *this's position.
2.1.2. If the call returns true, then return true.
2.2. Return the result of INTERPOSE_NEXT (assuming the function hasn't returned already in the for loop).

If you haven't, I could probably test it out myself.