Print

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

[Pvt. Pirate]

i forgot how to fix mousequery... i think it was just a fixed dfhack .plug.so somewhere on github though.
copypastinging the mousequery.plug.so from the 44.09 just doesnt work - saying it were written for another version of dfhack.
the only thing that doesnt work is the scrolling on screenborder when not in any dmode or lmode or qmode.
i'll post this in dfhack and twbt support threads, because i remember something about twbt having its own version of mousequery.

[lethosor]

i forgot how to fix mousequery... i think it was just a fixed dfhack .plug.so somewhere on github though.

Here's what you're referring to: http://www.bay12forums.com/smf/index.php?topic=126076.msg7830622#msg7830622
It would be helpful if you could remember to link to what you're talking about instead of just randomly cross-posting in other threads. Few people in this thread would have any idea what issue you're referring to otherwise.

Also, DFHack itself has only ever distributed one mousequery plugin per release. We didn't put up a "fixed" build anywhere special - as far as we know, it's not a DFHack-caused issue. TWBT distributed its own for a while, but stopped

copypastinging the mousequery.plug.so from the 44.09 just doesnt work - saying it were written for another version of dfhack.

This behavior has always been the case since before 2010. Loading plugins for a non-matching DFHack version is unsafe, so DFHack prevents it.

the only thing that doesnt work is the scrolling on screenborder when not in any dmode or lmode or qmode.

Mousequery has a number of features, each of which you have to enable individually. Run "mousequery help" or maybe "help mousequery" for a list, then enable everything listed and see if that solves your issue.

[Fleeting Frames]

While working on two different but related scripts (in 43.03, if that matters) that both deal with designations, I noticed that non-digging designations may be offloaded. Ok, dfhack.designations.isPlantMarked points me to the joblist, and I find at least smoothing (e: and accessible digging...probably all of them, I guess) seems to be also there.

I also notice that smoothing and engraving a floor both use df.job_type.DetailFloor. Art specification is all -1s for both. Comparing two such jobs with my diffrecursive script, seems they only differ in position, worker, id, completion timer and unk4. And looks like df.global.world.engravings only lists already done engravings (though that does have the use case of carving tracks on all flies engraved on the floor). Well, thankfully, distinguishing recent engravings and smoothing is easy enough; just look if smooth flag is set to 1 or 2.

Does anybody know how to distinguish between offloaded engraving and smooth designations?

[Pvt. Pirate]

i forgot how to fix mousequery... i think it was just a fixed dfhack .plug.so somewhere on github though.

Here's what you're referring to: http://www.bay12forums.com/smf/index.php?topic=126076.msg7830622#msg7830622
It would be helpful if you could remember to link to what you're talking about instead of just randomly cross-posting in other threads. Few people in this thread would have any idea what issue you're referring to otherwise.

Also, DFHack itself has only ever distributed one mousequery plugin per release. We didn't put up a "fixed" build anywhere special - as far as we know, it's not a DFHack-caused issue. TWBT distributed its own for a while, but stopped

copypastinging the mousequery.plug.so from the 44.09 just doesnt work - saying it were written for another version of dfhack.

This behavior has always been the case since before 2010. Loading plugins for a non-matching DFHack version is unsafe, so DFHack prevents it.

the only thing that doesnt work is the scrolling on screenborder when not in any dmode or lmode or qmode.

Mousequery has a number of features, each of which you have to enable individually. Run "mousequery help" or maybe "help mousequery" for a list, then enable everything listed and see if that solves your issue.

it is that it only ignores the bottom and right screen border for scrolling. otherwise it works fine. that's the only thing weird about mousequery. manually enabling it helped if it wasnt working at all, but it does work, but oddly.

thanks to Lethosor, i found the solution again: redownloading a clean version of dfhack and it works.

[Fleeting Frames]

So, tangent to my post right above, figured I need to be able to simulate vanilla d-x behaviour, and that means erasing jobs and returning worker to No Job, even after they're taken.

Spoiler: So, this (click to show/hide)

Code: [Select]

:lua local job = df.unit.find(3852).job.current_job job.list_link.prev.next, job.list_link.next.prev=job.list_link.next, job.list_link.prev df.unit.find(job.general_refs[0].unit_id).job.current_job = nil print(job:delete())

seemed to accomplish that objective, buuut when I was escaping back into the screen of viewing the now-erased job in gui/gm-editor, the game segfaulted.

Predictable and expected with nil pointer.

...But I can't predict every common access. Would this cause an issue elsewhere (outside of using it while in, say, manipulator's screen)? I'm half expecting eventful to be unhappy if job is started and erased instead of finished, though I'd expect it might cause an issue with dfhack.jobs.removeWorker then too.

[Warmist]

So, tangent to my post right above, figured I need to be able to simulate vanilla d-x behaviour, and that means erasing jobs and returning worker to No Job, even after they're taken.

Spoiler: So, this (click to show/hide)

Code: [Select]

:lua local job = df.unit.find(3852).job.current_job job.list_link.prev.next, job.list_link.next.prev=job.list_link.next, job.list_link.prev df.unit.find(job.general_refs[0].unit_id).job.current_job = nil print(job:delete())

seemed to accomplish that objective, buuut when I was escaping back into the screen of viewing the now-erased job in gui/gm-editor, the game segfaulted.

Predictable and expected with nil pointer.

...But I can't predict every common access. Would this cause an issue elsewhere (outside of using it while in, say, manipulator's screen)? I'm half expecting eventful to be unhappy if job is started and erased instead of finished, though I'd expect it might cause an issue with dfhack.jobs.removeWorker then too.

So you have arrived at one of "fun" things in dfhack: deleting a job. It's not complicated per.se. but you need to have very good accounting of all the links and not to forget to unlink-erase-destroy everything related to that thing.

E.g. if you have a job it can have many different references to various things. Items that are marked in job will be "stuck" in job, workers would reference the job and crash df. IIRC there are even nasty "special reference" structures that are used for various screens or sth.

So my suggestion is that we would gather all of that knowledge in one place and write "cancel job" or "delete job" function that handles ALL the general refs.
Partial implementations (that i know of): here also in dfhack itself and here also this comment says basically that

[Fleeting Frames]

Well, I can simply prevent the crashing if I leave the job hanging outside of joblist (it'd function exactly as it did before for whoever managed to get to it, just the jobs around it wouldn't have way back to it, but the designation is gone from the tile), but I imagine that would cause memory creep. Not much, but bad practice, that. However, no way to see which potential future third-party screens may want to access it.

However, seems like vanilla has some behaviour that resembles that, as I can still access the job struct after it is erased with d-x. With some interesting changes:

Spoiler: "erased a smooth floor job" (click to show/hide)

value   before   after
id      11544   -511203432
posting_index   -1   -239520752
job_type   2   0
job_subtype   -1   4
completion_timer   26   37
unk4   1076101120   3705166224
mat_type   -1   0
mat_index -1   4
item_type  -1   0
item_subtype -1 -19396
hist_figure_id -1 37

job.flags consistent differences, across 5 different jobs (to cull garbage data)
17   TRUE   FALSE

Most of this comes across as garbage data, though - ex, the historical figure of the worker was 40959, and there's infinite specific refs. Though matching the garbage data shouldn't hurt and matching the cleanup ones should be helpful. Anyway, job.flags[17] might be something like "active"?


Are there actually any general refs that are not workers or buildings? I notice logic for cancelling for those, but no handling of anything else, which implies there could be but presently aren't any known.

However, it seems the the safest option would be to save the designations I don't want to erase, let vanilla d-x do its thing, then replace them. Makes those with jobs on 'unerased' designations lose their job (e: but not engraving images?!) but should be safe otherwise.

Edit:

Noticed that dfhack has unnamed flags for carve track jobs (that should be named):

job.item_category: 18/19/20/21 true/false values correspond to carve_track_north/south/east/west. Tested and successfully altered track carving jobs with this.

[taleden]

Is there any way dfhack could extend manager orders to add item quality as a conditional? i.e. I can set an order to require "thrones < 10" or even "undecorated quartzite thrones < 10" but I'd love to be able to specify "masterful thrones < 10".

[Fleeting Frames]

DF doesn't track item quality there, so you'd have set required thrones to desired masterful thrones+number of non-masterful thrones in fortress (either regularly or whenever the second number changes), and then change the display(or place a "sticker" i.e. another viewscreen on) to change the number of player sees to be number of desired thrones - number of non-masterful thrones.


So, distantly related to the above:

Is there a way to change abstract building internal extents in lua? dfhack.buildings can tell and iterate over building.room, telling me whether a tile is part of it, but attempting to do the same in lua is a failure (and the building.room.extent only has 1 lonely value).

Example use case: I earlier placed 151 adjacent 1x1 pond zones in freezing climate with a macro (not knowing dwarves will spam cancel warnings on pond zones that are entirely on floors). It'd be nice if I could merge together the adjacent pond zones, or even place a new large one that has all tiles removed from it that don't overlap the previous ponds.

Near as I can tell, I can only do the latter via hijacking keyboard with gui.simulateInput, which is bit undesirable in the case of stockpiles (and will lose jobs, etc. that targeted to-be merged stockpiles) and unworkable in case of overlapping zones.

[lethosor]

Is there a way to change abstract building internal extents in lua? dfhack.buildings can tell and iterate over building.room, telling me whether a tile is part of it, but attempting to do the same in lua is a failure (and the building.room.extent only has 1 lonely value).

extent is a pointer, which points to the first element of the "extent" array in C, but you can index it (e.g. extents[1]) to access other elements. There's also the _displace() method, mentioned in https://dfhack.readthedocs.io/en/stable/docs/Lua%20API.html, which does the same thing. Note that you are responsible for determining the appropriate maximum index in this case, as you would be in C as well - an out-of-bounds index can cause undefined behavior/crashes.

[Fleeting Frames]

Awesome, that works (I tried indexing its parent value like that earlier, which failed).

[Pvt. Pirate]

Is there any way dfhack could extend manager orders to add item quality as a conditional? i.e. I can set an order to require "thrones < 10" or even "undecorated quartzite thrones < 10" but I'd love to be able to specify "masterful thrones < 10".

had to do a workaround before, seperating the items in different stockpiles and selling the unwanted.

[taleden]

Does the "petcapRemover" plugin work for eggs? If not, could it?

I've discovered that if eggs are laid while the species is above its breeding limits (>50 total, or >75% children) then they won't become fertilized. I assumed this check was done at the time a male would have otherwise fertilized them, but it looks like even when the population is brought back under limits, those eggs will remain infertile forever, as if the female herself was infertile; new eggs have to be laid (by a different female, or a month later after clearing the bad clutch) while the population is able to breed in order for the eggs to be fertilizable.

It would be great if the "petcapRemover" plugin (or something like it) could operate on already-laid eggs by setting their "fertilizable" flag (or whatever it is) to true in the case that it sees infertile eggs of a species that is actually below the population limits.

[PatrikLundell]

Real life bird eggs are fertilized before they're laid (punching a hole in the shell afterwards would probably damage the eggs badly, or at least provide a path in for pathogens, apart from the minor detail of birds lacking any syringe like equipment for performing the task [some insects punch a hole through the carapace of the female at a random location for seed placement, so the general principle is not without precedent in the broader animal kingdom]).
Egg laying fish typically perform fertilization after the eggs are laid, but I'm not aware of that technique being used outside of water.

As far as I understand, DF simulates the real life process to some extent, thus requiring the male to fertilize the female a suitable time before the eggs are laid (females swarming to nest boxes to immediately drop egg clutches when doors are opened is probably not a very good simulation, and only a few domesticated species regularly lay eggs without fertilization (which may fail to take effect, resulting in non viable eggs anyway)).

[Fleeting Frames]

In other words: Yeah, it probably could.

Pregnancies in DF only check cap at conception, not birth; poultry in particular can lay off multiple fertile batches off 1 pregnancy, even after the male is slaughtered, even with over 75% children(had 3 turkey hens lay 2 successfull batches); hence how you can get crocsplosions in the hundreds.