Print

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

[Prester]

i have a question:

when i try to use tiletypes it pretty much works as advertised.

but my problem is: i wanna add some clay and sand to my map and all i manage to do is adding different stone types, but whenever i try to "paint soil sand_red" or "paint m sand" or whatever it wont work. all it does is paint soil or stone.

what i was searching for the last 2 hours is some kind of LIST of available materials but i couldnt find anything. so my question: how do i select any kind of sand or clay as painted material?

thanks for making dfhack, its amazing <3

[Fleeting Frames]

@lethosor: it's documented in the comments right after that, yeah, though not in DFHack Plugins — DFHack 0.43.05-r2 documentation.

[Max™]

Man, still can't figure out what is breaking this, it's slapped into gm-editor and it loads up the df.types properly, but I've lost track of the ways I've tried to make it pass the type from the list prompt to the input prompt so you could scroll down and find the history_event entry and get prompted to enter 334 resulting in gm-editor opening df.history_event.find(334) for you, right?

Code: (gm-editor tinkering) [Select]

function GmEditorUi:find_type()
    local list={}
    for i in pairs(df) do
        table.insert(list,{text=('%s'):format(tostring(df[i]), i)})
    end
    guiScript.start(function()
        local choice=guiScript.showListPrompt("Select type to find:",nil,3,list,nil,true)
        if choice then
            dialog.showInputPrompt(tostring(choice),"Value to find:",COLOR_WHITE,
            "",function()
                local tp = ""
                self:pushTarget(df.choice.find(tp))
            end)
        end
    end)
end

Tried having the input setup in another GmEditorUi:blah function and calling it, tried making it a local function blah inside the find_type one, tried using getSelectedValue/Key/EnumType or currentTarget but I'm clearly missing something where either you can't just pass those values from list prompts to input prompts like that or I'm overcomplicating it/overlooking an obvious method.

[Uzu Bash]

In the armies structure, army_T_members, unk_4 to unk_c are counters for hunger, thirst and stored_fat. The unit data is located in counters2.

[lethosor]

Man, still can't figure out what is breaking this, it's slapped into gm-editor and it loads up the df.types properly, but I've lost track of the ways I've tried to make it pass the type from the list prompt to the input prompt so you could scroll down and find the history_event entry and get prompted to enter 334 resulting in gm-editor opening df.history_event.find(334) for you, right?

How exactly is this different from the existing feature where you can press "i" with a numeric field highlighted (GmEditorUi:find_id())? Am I missing something?

Code: (gm-editor tinkering) [Select]

function GmEditorUi:find_type()
    local list={}
    for i in pairs(df) do
        table.insert(list,{text=('%s'):format(tostring(df[i]), i)})
    end
    guiScript.start(function()
        local choice=guiScript.showListPrompt("Select type to find:",nil,3,list,nil,true)
        if choice then
            dialog.showInputPrompt(tostring(choice),"Value to find:",COLOR_WHITE,
            "",function()
                local tp = ""
                self:pushTarget(df.choice.find(tp))
            end)
        end
    end)
end


Several things wrong that I noticed:

- guiScript.showListPrompt() returns three values, and the third one is the one you want (I think): local ret, idx, choice=guiScript.showListPrompt(...)
- "df.choice" definitely isn't what you want, since that's the same as df["choice"]. You probably want df[choice], or df[choice.something]. It's been a while since I've dealt with that.
- The "tp" argument you're passing to find() (as in df.choice.find(tp)) is always an empty string.

In the armies structure, army_T_members, unk_4 to unk_c are counters for hunger, thirst and stored_fat. The unit data is located in counters2.

A pull request would be nice. I opened https://github.com/DFHack/df-structures/issues/211 so it doesn't get buried here.

[Max™]

What I was trying to do was let you pull up something like that find id (which I never actually got working because it never did anything when I tried it since I didn't aim it at a nuimber) except have it work like opening "gui/gm-editor df" and then let you search for an entry from the df.type list.

[lethosor]

Ah, that makes more sense. Essentially the equivalent of "gui/gm-editor df.type.find(id)", right? (I don't think it supports expressions like that, so your thing would be useful.) Are you thinking of having it be an in-editor option like the existing "i" key, or a flag to pass to gui/gm-editor (like "gui/gm-editor -i" to open that menu)?

[Max™]

I was working on it as an in-editor keybind to make use of the gui power baked in, just got stumped on making it grab the chosen entry from the listprompt and pass it to an inputprompt so it pulls up that df.type.find(id) page.

[PatrikLundell]

DFHack plugin writing question (win32 currently, if it makes a difference):
I'm trying to write a plugin, but I'm puzzled by some random DF crashes, and I'm unsure whether I am to blame or whether my plugin is merely a canary exposing existing DF bugs.
DF occasionally crashes at game cleanup or game exit and the cause every time I've looked at it has been pointer access violation in ntdll.dll, and I've seen similar DF behavior (without knowledge of where it crashed) in the past, in particular with the 0.40.X versions (LNP, so DFHack was present). My plugin allocates memory but does not write to any DF structure (but reads a lot), although simulated key input is used to order the cursor on the pre embark map to move (and the underlying data structures to be loaded by DF).
However, the crashes happen when DF cleans up its data, not when my plugin tries to clean up its own stuff (of course, I've screwed up that as well, numerous times), which has already happened at that point. If I understand it correctly, failure on my part to clean up plugin memory allocation will merely result in a memory leak, not a crash, as DF itself has no knowledge of that memory and thus shouldn't do anything at all with it.
Writing data outside of the bounds of my own structures could potentially corrupt DF data, but most of the time it results in a crash at the time the plugin writes it, and it seems unlikely that kind of error would occasionally screw up DF's data but never cause the plugin to crash despite quite a few plugin test/fix/retest cycles for various errors/added code.

[ab9rf]

DFHack plugin writing question (win32 currently, if it makes a difference):
I'm trying to write a plugin, but I'm puzzled by some random DF crashes, and I'm unsure whether I am to blame or whether my plugin is merely a canary exposing existing DF bugs.
DF occasionally crashes at game cleanup or game exit and the cause every time I've looked at it has been pointer access violation in ntdll.dll, and I've seen similar DF behavior (without knowledge of where it crashed) in the past, in particular with the 0.40.X versions (LNP, so DFHack was present). My plugin allocates memory but does not write to any DF structure (but reads a lot), although simulated key input is used to order the cursor on the pre embark map to move (and the underlying data structures to be loaded by DF).
However, the crashes happen when DF cleans up its data, not when my plugin tries to clean up its own stuff (of course, I've screwed up that as well, numerous times), which has already happened at that point. If I understand it correctly, failure on my part to clean up plugin memory allocation will merely result in a memory leak, not a crash, as DF itself has no knowledge of that memory and thus shouldn't do anything at all with it.
Writing data outside of the bounds of my own structures could potentially corrupt DF data, but most of the time it results in a crash at the time the plugin writes it, and it seems unlikely that kind of error would occasionally screw up DF's data but never cause the plugin to crash despite quite a few plugin test/fix/retest cycles for various errors/added code.

Crashes at exit in the runtime library are almost always caused by memory arena corruption, which means that you're writing to a freed pointer or overrunning an allocated buffer, which usually means a fencepost error somewhere.

[Roses]

So I am finally digging myself out from a large pile of work and getting back to DF modding/script writing. Something I had thought about while I was away was an ability to link my journal entries (for reference the post about my journal can be foundhere). Ideally you could look up a creature, see its butcher components, select one and see the material information, then if there are reactions that use it for a reagent you could select that to see the reaction, then look at the buildings that have that reaction, etc... With simply pressing escape taking you to the previous screen.

Now I think I can do this by redoing the way I create the journal entries and creating a tree structure and simply creating new viewscreens each time you select something, but I was wondering if there was a more efficient way to "link" two or more separate viewscreens instead of having to construct a complex tree.

[PatrikLundell]

Thanks ab9rf, that's the info I needed (although not the one I wanted, of course, but rather an unpleasant correct one than a pleasing lie).

[Fleeting Frames]

Hm. Toying with gui.FramedScreen for an indicator. Noticed that when fps/gfps < 1+numbers of screen I'm dismissing, screen:dismiss() can briefly blink game screen black.

Given that, is there a reason beyond onDismiss() to not just set the screen object to nil and have it poof without blinking? Graphical glitches, or..?

[lethosor]

Hm. Toying with gui.FramedScreen for an indicator. Noticed that when fps/gfps < 1+numbers of screen I'm dismissing, screen:dismiss() can briefly blink game screen black.

All screens will do that, sometimes. If you decrease your FPS setting to 10 (you can use [Alt][-] by default) and enter and exit the options (esc) menu, you'll notice a black screen when exiting but not when entering (probably).

Given that, is there a reason beyond onDismiss() to not just set the screen object to nil and have it poof without blinking? Graphical glitches, or..?

No! First, that won't work without modifying the list of screens in df.global.gview.view (although maybe that's what you meant). Also, it will leak memory, because the screen won't be deleted properly, and might result in feed()/render()/logic() getting called on the wrong screen for a frame (or worse, crashing).

Besides calling DFHack's onDismiss(), screen.dismiss() pretty much only sets the screen's breakdown_level, which results in DF cleaning up the screen safely at an appropriate time (not instantly). You should generally always use that (except maybe in weird cases, e.g. where the screen has never been displayed).

[Fleeting Frames]

Yeah, I noticed the behaviour for vanilla screens too. In fact, setfps 10 is my litmus test, since I know at least some players run with at least gfps at 10 (not that it'd matter if actual fps is higher).

I initially went by modifying screen._native.parent.child or df.global.gview.view, but then I realized that screen._native.parent.child is screen._native, and tested that both poof it without blinking.

Shame it leaks memory, then - I'd have assumed that lua garbage collection would clean up the table that I don't know is being used anywhere, but I guess it is not so. (And yes, badly toying with this does indeed result in errors or even DF crashes. i.e. setting the parent.child to nil and then calling screen:dismiss() without waiting two frames in-between, amongst many, many, many other variants.)

For reference, code that seemed to work fine:

Code: [Select]

local myscreen = dfhack.gui.getCurViewscreen()-- df.global.gview.view.child.child

dfhack.timeout(100, "frames", function()
myscreen.parent.child = nil
dfhack.timeout(2, "frames", function()
newscreen:dismiss()
dfhack.println("screen is dismissed " .. tostring(newscreen:isDismissed()))
end)

end)
Tested it while running firefox in background (with slightly complicated screen object) by pasting 101 lines of screen-making into console and DF went from 383,3 MB to up to highest point 663 MB while using 1 CPU at full blow, then down to 628,2 MB after all were gone and game had returned to dwarfmode/Default - which averages to a 2,42 MB of RAM per screen.

However,  doing that same test with just :dismiss() after 100 frames resulted in 384,0 MB → high of 900+ before even being done *killed at this point and reran with quit firefox RAM* - high of 508→ remained there after all were gone, an average of 1,23 MB. Unlike before threw a bunch of errors.

Then reran initial to be fair with also less demand on ram and got 381,3 → high of 431,1 → remained there, for average of 0,49 MB per screen.

It seems this has less of a memory leak, in both cases? Couldn't even run 101 screens with firefox eating vast majority of RAM with the default :dismiss().

*befuddled*

Anyway, it seems that one can improve on DF's cleanup. No crashes with that, but just few tests in dwarfmode. Though I do have the question of what is still left hanging with the above method?
(It'd be also nice if you could know if this was fine, but ain't nobody who knows that for sure.)

Hmm...Maybe screen object itself. *Tests with newscreen= nil after the line and fox restarted* 380,2 →429,5. 0,49 still.