Print

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

[lethosor]

Another small bug with create-unit I found.
When invoking create-unit while a modal dialog is visible, dwarf fortress is left in a pseudo arena-mode.
This is most visible with the dwarf unit lists only showing names and not professions.

I also noticed slightly fewer crashes by invoking create-unit a bunch of times inside a dfhack.with_suspend(..). But this is no big surprise.

Please report bugs in the GitHub issue tracker. (Bugs reported in this thread can be buried sometimes.)

(Really. I wasn't aware this was an issue at all.)

Also, I've never had create-unit crash, although I haven't used it a lot, or without a cursor. What types of units are you creating, and what options are you using? (Roses: I realize you asked that yourself, but it would be helpful to know what you're using too.)

It should go without saying, but please make a pull request if you figure out how to fix the issue(s) you're having, or at least let us know about the fixed version so it doesn't get left out.

Edit: thanks - that bug report was helpful. (Also, thanks to whoever posted about the masspit.rb bug as well.)

I also noticed slightly fewer crashes by invoking create-unit a bunch of times inside a dfhack.with_suspend(..). But this is no big surprise.

I missed this the first time - with_suspend shouldn't be necessary. Where are you running the script from?

[danamlund]

I missed this the first time - with_suspend shouldn't be necessary. Where are you running the script from?

It is a lua script started manually through the dfhack console (link later in post). It forces a pause before calling create-unit.

additionally since this script can be paired with "create-item", the unit can be given another civ, and invader tags, I did a little work creating mini 1 man invaders out of this for a proof of concept script created force invasion, made it about half way through it, but abandoned it when I realized I could effectively call for a 50 man army in waves of 10 and effectively guarantee a crash.  So I shelved it until someone with a little better idea of whats going on could fix the crash issues.

I made a similar script that spawns invaders. My scripts fails about half the time when spawning ~60 units with a few pieces of equipment and a few skills. (see http://www.bay12forums.com/smf/index.php?topic=164458.0 )

I ran some experiments to see how often it fails and which errors I got.
Two of the errors I saw are dfhack related. But the majority are dwarf fortress segfaulting.

Can we get interesting data from a segfault or does the code obfuscation prevent this? Are these errors helpful?

Anyway, here are my experiment results:
* Experiment 1
save: df6/r1
experiment: unpause and spawn (strength=1000, ~60 goblins)
Worked: 6, segfault: 4

* Experiment 2
save: df6/r2
experiment: unpause and spawn (strength=1000, ~60 goblins)
Worked: 8, segfault: 1, free: 1

* Experiment 3
save: df6/r2
experiment: keep paused and spawn (strength=1000, ~60 goblins)
Worked: 6, segfault: 3, gui-loop#1: 1

Errors:
* segfault:

Code: [Select]

Segmentation fault (core dumped)

* free:

Code: [Select]

[DFHack]# *** Error in `./libs/Dwarf_Fortress': free(): invalid next size (normal): 0x00007fffc4031b30 ***
                    Aborted (core dumped)

* gui-loop #1

Code: [Select]

./hack/lua/gui.lua:177: attempt to compare nil with number
stack traceback:
        ./hack/lua/gui.lua:177: in method 'inClipGlobalXY'
        ./hack/lua/gui.lua:408: in method 'getMousePos'
        ./hack/lua/gui/widgets.lua:384: in method 'onRenderBody'
        ./hack/lua/gui.lua:460: in method 'render'
        ./hack/lua/gui.lua:447: in method 'renderSubviews'
        ./hack/lua/gui.lua:462: in method 'render'
        ./hack/lua/gui.lua:563: in function <./hack/lua/gui.lua:562>
        [C]: in ?
... repeating for ever

Other errors I saw before writing down experimental results:

* linked list

Code: [Select]

*** Error in `./libs/Dwarf_Fortress': malloc(): smallbin double linked list corrupted: 0x00007fffc4072070 ***
Aborted (core dumped)

* gui loop #2

Code: [Select]

./hack/lua/gui.lua:158: attempt to perform arithmetic on a nil value (field '?')
stack traceback:
        ./hack/lua/gui.lua:158: in local 'fun'
        ./hack/lua/class.lua:98: in upvalue 'invoke_after_rec'
        ./hack/lua/class.lua:94: in upvalue 'invoke_after_rec'
        ./hack/lua/class.lua:127: in function <./hack/lua/class.lua:112>
        (...tail calls...)
        ./hack/lua/gui.lua:563: in function <./hack/lua/gui.lua:562>
        [C]: in ?
... repeating for ever

Conclusions:
We get many different errors even though the experiments were pretty similarly executed.

I might have seen fewer more errors when spawning units after waiting for 2 seconds after loading a game, but that might just be wishful thinking.

These are very limited experiments. I cannot say if the crash rate is higher or lower with other saves and in other situations.

Do anyone have any ideas for ways to reduce the crash rate?

[Hesperid]

So, now that the unit.relations structure has been dispersed so that pregnancy variables are directly under the unit, and references to other unit (or histfig?) IDs are in a new structure called "relationship_ids", I happened to notice that the names of the fields of that structure begin with capital letters. I.e. we've now got

unit.relationship_ids.Lover

unit.relationship_ids.Spouse

...

Off-hand I'm not aware of anything else in the DFhack API that has capital letters in any field names. It might be a good idea to nip this in the bud, because if we start on the road that only some of them get capital letters in them, nobody is going to remember which.

[Quietust]

unit.relationship_ids.Lover
unit.relationship_ids.Spouse
Off-hand I'm not aware of anything else in the DFhack API that has capital letters in any field names.

Those aren't field names - those are array indices (i.e. they're actually "unit.relationship_ids[unit_relationship_type.Lover]" and "unit.relationship_ids[unit_relationship_type.Spouse]", and most of those are capitalized (and some are even all caps).

[lethosor]

To add to that, unit_relationship_type is an enum, and nearly all enum items are capitalized. In C++, your only option is "unit->relationship_ids[df::unit_relationship_type::Spouse]", which translates directly to "unit.relationship_ids[df.unit_relationship_type.Spouse]" in Lua - "unit.relationship_ids.Spouse" is equivalent and is just supported to make Lua scripts more readable. (It's also equivalent to "unit.relationship_ids[1]", which is much less readable.) Changing the array indices to lowercase wouldn't make sense because it wouldn't match the case of the enum items.

Also, I'd like to point out that we didn't have much of a choice when it came to removing unit.relations - it's likely that the "relations" compound had never existed at all in DF (or at least not in the way we had it set up). We had to change it to get unit fields to line up with 64-bit DF properly.

Edit: more examples of similar things:

world.buildings.other
world.items.other
world.units.other
world.stockpile.num_jobs
world.stockpile.num_haulers
world.status.slot_id_used (this is a good example of an enum with gaps - those fields can only be accessed by numerical indices in Lua)
world.status.slot_id_idx1 (same)
world.status.slot_id_idx2 (same)
world.profession_skills.primary
world.profession_skills.secondary

Usually, the ones in all caps are names from the raws, and the rest are only capitalized.

[Hesperid]

The instance I was thinking of when referring to previous convention was that the physical attributes have been fully capitalized as STRENGTH etc.

In C++, your only option is "unit->relationship_ids[df::unit_relationship_type::Spouse]", which translates directly to "unit.relationship_ids[df.unit_relationship_type.Spouse]" in Lua - "unit.relationship_ids.Spouse" is equivalent and is just supported to make Lua scripts more readable. (It's also equivalent to "unit.relationship_ids[1]", which is much less readable.) Changing the array indices to lowercase wouldn't make sense because it wouldn't match the case of the enum items.

Usually, the ones in all caps are names from the raws, and the rest are only capitalized.

Thanks for this very detailed explanation for both the reasoning behind different caps styles used, and why what looks incongruent is only shorthand that appears in Lua (exclusively by the sound of it?).

I'm not complaining about the loss of relations, it only requires search-and-replace level maintenance in scripts.

[Uzu Bash]

As of this version using advfort to craft with items owned by a dwarven civ crashes the game. I found that this is fixed by removing general_ref_building_civzone_assignedst from general_refs. I don't know where that could be added into advfort.lua, but is this included in any other scripts? How would I write a quick function to find and remove this ref from my inventory items?


EDIT: nm the quick fix; moving the items out of warehouse and depot areas then offloading/reloading the map clears the ref.

[PatrikLundell]

Does DFHack export any operation to change the display mode? I've found dfhack.screen.inGraphicsMode, but not any operation to change it. mifki must know how to do it to get TwbT to work, but is it an internal function to TwbT?
The usage I see for such an operation (outside of TwbT) is to change the mode to text when bringing up a DFHack display (such as e.g. gui/gm-editor) so the contents is legible, and then restore the mode to what it was on exit.

[lethosor]

Does DFHack export any operation to change the display mode? I've found dfhack.screen.inGraphicsMode, but not any operation to change it. mifki must know how to do it to get TwbT to work, but is it an internal function to TwbT?
The usage I see for such an operation (outside of TwbT) is to change the mode to text when bringing up a DFHack display (such as e.g. gui/gm-editor) so the contents is legible, and then restore the mode to what it was on exit.

I'm not really sure what you're talking about. The concepts of a separate text and graphics font are entirely specific to TWBT, unless you're talking about truetype, which DFHack doesn't support. There's no "text mode" that DFHack could switch to. TWBT is far more complicated than that and handles graphics on its own.

[scourge728]

Did retiring my tavern and temple cause the dwarves that were using them to break? because most of them are just sitting there with "No Job" even though many of them have jobs, such as my animal trainers that are refusing to tame some of my baby animals for seemingly no reason

EDIT: I forgot to mention, I tried using things such as workNow, but they caused absolutely nothing to change

[Hesperid]

Did retiring my tavern and temple cause the dwarves that were using them to break?

Previously in your thread here you said using DFhack to retire your tavern and temple is what fixed this issue for you:

It appears what I needed to do was use DFhack to retire both my temple and tavern as that seems to have made them function now

So... which is it?

[scourge728]

I THOUGHT it fixed the issue, because they tamed the giraffe's, the problem being they STOPPED taming things or doing ANYTHING else again, (for some reason they will imedietly jump to war/hunting training things and then go back to doing nothing even though they have hauling enabled and there are many things to haul and many bins to put them in) similar is true for all of the workers, they will do what I put in the workshops, but then go back to doing nothing, not even hauling and I don't know why

[Hesperid]

So if the problem surfaced before you used DFhack to try to fix it, why do you now think it was your attempt to fix it by DFhack that caused the problem?

[scourge728]

Because other than the tamers, the broken dwarves were in the temple/tavern

[PatrikLundell]

Does DFHack export any operation to change the display mode? I've found dfhack.screen.inGraphicsMode, but not any operation to change it. mifki must know how to do it to get TwbT to work, but is it an internal function to TwbT?
The usage I see for such an operation (outside of TwbT) is to change the mode to text when bringing up a DFHack display (such as e.g. gui/gm-editor) so the contents is legible, and then restore the mode to what it was on exit.

I'm not really sure what you're talking about. The concepts of a separate text and graphics font are entirely specific to TWBT, unless you're talking about truetype, which DFHack doesn't support. There's no "text mode" that DFHack could switch to. TWBT is far more complicated than that and handles graphics on its own.

Well, given that a boolean function is defined, it ought to have some function, but I may very well be barking up the wrong tree regarding what that function is. (It's also use to set 'USE_GRAPHICS = dscreen.inGraphicsMode()' in the beginning of gui.lua).