Print

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

[Atomic Chicken]

I can't check anything at the moment, but I seem to remember noticing that reanimated undead histfigs had a unit_id2 value corresponding to what might have been the unit ID or the nemesis ID of the unit from which they were produced (reanimation involves the creation of entirely new units so as to support the zombification of individual body parts).

Edit Edit: I also figured out that unk_1, unk_2, and unk_3 in df.global.ui_advmode are the last x, y, and z coordinates of the adventurer's army (set/updated when the travel screen is opened, or you move on the travel screen)... then I discovered this was already known because it was used in questport Q.Q

These were identified and pushed to df-structures a couple of months ago, alongside some other stuff in ui_advmode, but a new DFHack version has yet to be released. I've found that it's always a good idea to check the latest structures on Github when dealing with supposed unknowns so as to avoid needless duplication of effort.

[Clément]

What are the nemesis records used for? In the case I've seen it was mostly redundant information.

[Rumrusher]

Nemesis records are mostly used to retain a list of unit, historical figure and other data based on the unit. personally use nemesis to track down the unit's historical figure data as playing around with putnam's dbz mod kinda makes aligning that stuff hell as I think they use the historical figure pool for Dfhack data and script storage so like there just a big chunk of historical figures that are just dummy data and the result just causes a unit HF id number to be off if someone trys to search for that number in the pool of historical figures


so far trying to figure out how sites equip inhabitants with gear, and wondering it tied to items in the mead hall or not. I ended up getting 1 inhabitant created unit to have a weapon but couldn't seem to recreate the process again.


edit: false alarm that one inhabitant ended up being a night troll with a habit that gives them a random weapon on spawn, which uhh only seems to be just the 'any melee weapon' and not range.

[darkhog]

I want to report a bug in Dfhack (mousequery thing, to be precise). Even when I set mousequery edge disable, it still scrolls on edge, particularly after clicking on a tile and moving around. The second issue is that I have set mousequery drag right so I can rmb-drag the world (which is a better scrolling method IMO) and while painting the designations (with box mode disabled) when I scroll (using rmb-drag) so the cursor is outside the screen rgiht when I click the world with LMB the camera snaps back so the cursor is in view which led me to mining stuff I never intended to mine and other stuff.

[lethosor]

I want to report a bug in Dfhack (mousequery thing, to be precise). Even when I set mousequery edge disable, it still scrolls on edge, particularly after clicking on a tile and moving around.

Does it only scroll when you click near the edge of the screen? If so, that's probably intentional - that's how DF's cursor works when moved with the arrow keys too.

[darkhog]

No, it's enough that I move mouse after clicking, say, in the middle of the screen.

[Fleeting Frames]

Noticed I can change what dwarfmonitor's dwarfmode viewscreen widgets display by editing the dwarfmonitor.lua (in 43.03 in case it matters).

Ability to add arbitrary widgets without having to git & compile, merely by editing said file, struck me as useful (even if it is only on dwarfmode viewscreen).

The usefulness has unexpected limitation, though - it seems like neither require of dwarfmonitor nor script_environment of another script won't share the environment when I call it again from a separate :lua line, and using persistent configuration storage (after world has loaded) freezes the game (while getting/setting them by getting an exact copy by require and :lua works).

Editing json and reloading dwarfmonitor still works, though, but is there perhaps a better way to share values between the the plugin and another lua script already available?

[lethosor]

Noticed I can change what dwarfmonitor's dwarfmode viewscreen widgets display by editing the dwarfmonitor.lua (in 43.03 in case it matters).

Do you mean dwarfmonitor.json? That's the file you're intended to edit (should be in the dfhack-config folder).

The usefulness has unexpected limitation, though - it seems like neither require of dwarfmonitor nor script_environment of another script won't share the environment when I call it again from a separate :lua line, and using persistent configuration storage (after world has loaded) freezes the game (while getting/setting them by getting an exact copy by require and :lua works).

Editing json and reloading dwarfmonitor still works, though, but is there perhaps a better way to share values between the the plugin and another lua script already available?

I believe "reload('plugins.dwarfmonitor')" in Lua will reload the config and the lua file properly (although you shouldn't have to edit the lua file ordinarily).

script_environment shouldn't work for this at all, though, so I might be confused about what you're doing exactly.

[Fleeting Frames]

No, I mean hack/lua/plugins/dwarfmonitor.lua. (While I did notice one can use the cursor widget to display some text at some point with it, it's somewhat limited.)

I noticed dfhack.screen natives can be edited inside its render functions and work. Well, paintString at least.

I want to pass data to thus modified dwarfmonitor from another script during runtime (rather than putting all code inside dwarfmonitor before start).
Though the reload command is useful tip if that isn't possible and rewriting the dwarfmonitor.json during gameplay is the simplest way.

Issue with partial rewriting is, of course, departing from DF's "keep all in memory" paradigm, which could cause problems when dwarfmonitor gets passed something to something newly created and process is killed.

[lethosor]

No, I mean hack/lua/plugins/dwarfmonitor.lua. (While I did notice one can use the cursor widget to display some text at some point with it, it's somewhat limited.)

The cursor widget should always be displaying text at the same point, but you can choose where various widgets display by editing dwarfmonitor.json. I'm kind of confused - what exactly are you trying to do by editing the lua file?

I noticed dfhack.screen natives can be edited inside its render functions and work. Well, paintString at least.

Editing things in dfhack.screen is generally not a good idea because it will affect all scripts.

I want to pass data to thus modified dwarfmonitor from another script during runtime (rather than putting all code inside dwarfmonitor before start).
Though the reload command is useful tip if that isn't possible and rewriting the dwarfmonitor.json during gameplay is the simplest way.

Issue with partial rewriting is, of course, departing from DF's "keep all in memory" paradigm, which could cause problems when dwarfmonitor gets passed something to something newly created and process is killed.

What data are you trying to pass to dwarfmonitor?

It should be fairly straightforward to add a dwarfmonitor widget, by the way, and the plugin is set up so that additional widgets can be added to dwarfmonitor.json easily enough. Is that what you're trying to do?

[Fleeting Frames]

Ah, the "its" in the context of second quote was dwarfmonitor('s renders), not dfhack.screen's. Additional widgets is pretty much right (editing just json will not display invalid widget types, so have to edit the .lua file - but not like one can include code in .json by its lonesome anyway.)

Ideally, I'd want to pass lua table(s), but any data might work - the issue is passing data without modifying files on disk, so that if DF is killed the next start will begin in same state as previous (which could be accomplished via cleanup on startup), and so that one doesn't need to worry about excessive disk access (which couldn't be accomplished when passing data through .json or the like).

[Warmist]

Playing around with creating armies (for adventure mode stuff): here if anyone is interested . Has anyone tried doing migrants/invaders on new army mechanics?

[Rumrusher]

oh hey warmist was playing around with this stuff for a while but usually end up with uhh fort mode recruitment options of adding units to an army that on return brings back in a new historical unit. but I think the current update broke the army mission data so I can't change that while the units are out.
so far messing around with camp site data and inhabitants and pondering how to get the inhabitants in gear like say start with crossbows?
was looking forward to cracking the Raid option in fort mode and converting that for adventure mode by being able to send out companions on missions.

[lethosor]

Ah, the "its" in the context of second quote was dwarfmonitor('s renders), not dfhack.screen's. Additional widgets is pretty much right (editing just json will not display invalid widget types, so have to edit the .lua file - but not like one can include code in .json by its lonesome anyway.)

(I thought you meant you were editing dfhack.screen itself, not really from somewhere in particular)

Yeah, you have to add them in the Lua file. I think I wrote most of that system, and it should be extensible, but let me know if you have questions. Once you've implemented a widget type, you should be able to use that type in the JSON file.

Ideally, I'd want to pass lua table(s), but any data might work - the issue is passing data without modifying files on disk, so that if DF is killed the next start will begin in same state as previous (which could be accomplished via cleanup on startup), and so that one doesn't need to worry about excessive disk access (which couldn't be accomplished when passing data through .json or the like).

I'm still kind of confused about what exactly you're doing. Can you explain? Are you trying to display some data that a separate script is generating in a widget? Is there a reason you can't do that in the widget itself? (Passing it in memory is definitely better than going through disk - at the very least, reqscript() / script_environment() should work from dwarfmonitor.lua.)

[Fleeting Frames]

"Are you trying to display some data that a separate script is generating in a widget?" Yes, exactly.

Tried script_environment on a dummy script (also tried reqscript now; same result) and dwarfmoniter alike, adding/editing variables in during runtime, didn't work even with disable-enable or by editing variables from console before enabling dwarfmonitor for first time in current process. It looks like the environment dwarfmonitor generates and the environment console generates are different. (Adding something to BASE_G obviously failed too; wildly speculating might be that they're on separate C lua states).


As to why separate, there are couple reasons why not put all the code in the widget itself, but the chiefmost of them is sharing and multi-user extensibility of the codebase; atm I'm thinking of working off a paradigm that - on first call opens and edits a widget in dwarfmonitor just before the last line (and edits json as needed) - the widget is given things to render in a file of scripts to require - hereafter new things are added in that file whose presence is checked on enabling.


Another reason is dfhack.timeout being null and lack of persistent configuration storage, and what those imply. Now, while I use it fairly often, I guess timeout could be worked around via render reading in-game ticks. Things that take input like constructmultiz though require somehow matching display to internal conditions. I also don't know what else I might find missing for dozen other ideas, such as df.historical_figure.find, which would be absolutely necessary for, say, importing the widget displaying spouse from relations-indicator.