Print

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

[lethosor]

I looked at a few and it seems that a lot of DF variables are uninitialized when they should be empty strings or null pointers. I don't much about DF internals so I don't how to properly fix that. As long as DT detects it is reading garbage, it should be fine.

That's probably a DT issue. DFHack does care if DF strings/etc. aren't initialized, and would crash, so given that things like manipulator aren't crashing, uninitialized data is probably not the issue here.

[Micro102]

Anyway, after months and months we finally have a working 64-bit DF (from what I've seen). Barring any other bug reports it might be time to poke the relevant channels like the OP and the LNP to have this included. Congrats.

Is it true? Link please!

[Sorg]

Anyway, after months and months we finally have a working 64-bit DF (from what I've seen). Barring any other bug reports it might be time to poke the relevant channels like the OP and the LNP to have this included. Congrats.

Is it true? Link please!

OMG, u people are so lazy
check this post

[Clément]

That's probably a DT issue. DFHack does care if DF strings/etc. aren't initialized, and would crash, so given that things like manipulator aren't crashing, uninitialized data is probably not the issue here.

I looked with gdb and IDA, DT is reading the correct value. If something is wrong it is the offset then. But other fields of the object are there, so the location looks good. There are some kind of "holes" in the objects with values like 0xbaadf00d. I find it weird, because if I understand correctly DF is written in C++, how can you get an uninitialized C++ string? (other than casting a pointer to uninitialized memory)

I saw words that were lacking some variant (plural, adjective, ...), where the variant would be uninitialized instead of empty. Or items with an invalid subtype pointer (are there items without a subtype?).

It has been a few weeks since I looked at these issues, so I may be mixing up a few details, but that is the general idea. I can try to get you a more precise example if you want.

Edit: looking at the first invalid string, it happens while reading the adjective for an instrument. The object (item_subtype) as seen from IDA:

Code: [Select]

000000002CC58570 dq 1407131D8h                           ; vtable
000000002CC58570 db 'ENT216 INK1',0,0Dh,'­¡¦'            ; field_8.data
000000002CC58570 dq 0Bh                                  ; field_8.length
000000002CC58570 dq 0Fh                                  ; field_8.capacity
000000002CC58570 dw 0                                    ; subtype
000000002CC58570 db 0ADh, 0BAh, 0Dh, 0F0h, 0ADh, 0BAh, 0C0h, 71h, 0C5h, 2Ch, 0, 0, 0, 0
000000002CC58570 db 1, 0, 0, 0, 0Dh, 0F0h, 0ADh, 0BAh, 0FFh, 0FFh, 0FFh, 0FFh, 0D8h, 0
000000002CC58570 db 0, 0, 0C0h, 97h, 0C5h, 2Ch, 0, 0, 0, 0, 68h, 98h, 0C5h, 2Ch, 0, 0, 0
000000002CC58570 db 0, 0A0h, 98h, 0C5h, 2Ch, 0, 0, 0, 0
000000002CC58570 db 'sezuk',0,'¡¦',0Dh,'­¡¦',0Dh,'­¡¦'   ; name.data
000000002CC58570 dq 5                                    ; name.length
000000002CC58570 dq 0Fh                                  ; name.capacity
000000002CC58570 db 'sezuk',0,'¡¦',0Dh,'­¡¦',0Dh,'­¡¦'   ; name_plural.data
000000002CC58570 dq 5                                    ; name_plural.length
000000002CC58570 dq 0Fh                                  ; name_plural.capacity
000000002CC58570 db 'Éf+,',0,0,0,0,2,0,0,0,0Dh,'­¡¦'     ; adjective.data
000000002CC58570 dq 6A4BAAD0079h                         ; adjective.length
000000002CC58570 dq 300000032h                           ; adjective.capacityMost fields look good, but there is uninitialized data in the middle of the object (but DT does not read that) and the name_adjective string is also uninitialized (causing the error message).

Edit2: Nevermind the uninitialized data in the middle, it must be padding.

Edit3:Next is a ItemUniform with a bad item_def pointer

Code: [Select]

00000000346CEF60 db 30h                                  ; "½½½½½½½½½½½½½½½½"
00000000346CEF60 db 0CFh                                 ; item_type
00000000346CEF60 db 6Bh, 40h, 1, 0, 0, 0, 3Bh, 0, 56h, 0, 0A2h, 0, 0ADh, 0BAh, 48h, 0, 0
00000000346CEF60 db 0, 0, 0, 0, 0, 18h, 97h, 2, 0
00000000346CEF60 dd 0BE1Eh                               ; id
00000000346CEF60 db 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
00000000346CEF60 db 0
00000000346CEF60 dq offset off_371607E0                  ; general_refs.begin
00000000346CEF60 dq offset unk_371607F0                  ; general_refs.end
00000000346CEF60 dq offset unk_371607F0                  ; general_refs.field_10
00000000346CEF60 db 0FFh, 0FFh, 0FFh, 0FFh, 0FFh, 0FFh, 0FFh, 0FFh, 0, 0, 0ADh, 0BAh, 0Dh
00000000346CEF60 db 0F0h, 0ADh, 0BAh, 0Dh, 0F0h, 0ADh, 0BAh, 0Dh, 0F0h, 0ADh, 0BAh, 0Dh
00000000346CEF60 db 0F0h, 0ADh, 0BAh, 0Dh, 0F0h, 0ADh, 0BAh, 0, 0, 0, 0, 0, 0, 0, 0
00000000346CEF60 dd 1                                    ; stack_size
00000000346CEF60 db 0Dh, 0F0h, 0ADh, 0BAh, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
00000000346CEF60 db 0, 20h, 8, 16h, 37h, 0, 0, 0, 0, 46h, 27h, 9Eh, 1
00000000346CEF60 dw 0                                    ; wear
00000000346CEF60 db 0ADh, 0BAh, 18h, 97h, 2, 0, 0FFh, 0FFh, 0FFh, 0FFh, 0FFh, 0FFh, 0FFh
00000000346CEF60 db 0FFh, 0Dh, 0F0h, 0ADh, 0BAh
00000000346CEF60 dw 26h                                  ; mat_type
00000000346CEF60 db 0ADh, 0BAh
00000000346CEF60 dd 16Bh                                 ; mat_index
00000000346CEF60 dw 0FFFFh                               ; maker_race
00000000346CEF60 dw 3                                    ; quality
00000000346CEF60 db 1, 0, 0, 0, 5Dh, 6Ah, 0, 0, 0FFh, 0FFh, 0FFh, 0FFh, 0, 0, 0, 0, 0, 0
00000000346CEF60 db 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
00000000346CEF60 dq 0ABABABABABABABABh                   ; item_defNow, that I try to look at the whole structures, I see that the problematic fields are both at the end. The uninitialized data in the middle is expected because mixing short and 64 bits pointer create a lot of padding.

I guess these fields should be skipped in those cases. I need to know what object type have these fields and those which do not, in order to fix that.

[lethosor]

Edit: looking at the first invalid string, it happens while reading the adjective for an instrument. The object (item_subtype) as seen from IDA:

If you're looking at an itemdef_instrumentst, those don't have an adjective field (it's right below name_plural for other itemdef subtypes):

Code: [Select]

<itemdef_instrumentst: 0x11ebefcf0>
id                      = ENT12 INK1
subtype                = 0
base_flags              = <BitArray<>: 0x11ebefd08>
source_hfid            = -1
source_enid            = 12
raw_strings            = <vector<string*>[17]: 0x11ebefd20>
name                    = nilim
name_plural            = nilim
flags                  = <BitArray<>: 0x11ebefd48>
...

Perhaps https://github.com/DFHack/df-structures/blob/master/df.item-raws.xml would be helpful.

Anyway, after months and months we finally have a working 64-bit DF (from what I've seen). Barring any other bug reports it might be time to poke the relevant channels like the OP and the LNP to have this included. Congrats.

Assuming you mean DT, I'd be wary of claiming that, at least for the time being. Other builds have appeared stable until people have gotten around to testing them on their machines and reporting crashes, so I don't think the fact that it didn't crash for you over a 3-hour period is enough to bug LNP people about including it (although it's certainly an improvement).

[Micro102]

Anyway, after months and months we finally have a working 64-bit DF (from what I've seen). Barring any other bug reports it might be time to poke the relevant channels like the OP and the LNP to have this included. Congrats.

Is it true? Link please!

OMG, u people are so lazy
check this post

More like ignorant. I I couldn't read all that code jargon so I assumed there was still something wrong with that version.

[Rose]

Somebody who knows QT really needs to remake this to use DFhack.

[Clément]

Thanks lethosor. I added a check based on the item type. I may be able to fix other issues in a similar manner. I hope I won't break anything, others (like the uniformitem) may require bigger changes than the adjective issue.

Somebody who knows QT really needs to remake this to use DFhack.

I am currently discovering the mess that is DT data structures, and I would not mind a complete rewrite, but that would be a lot of work. Personally, I will only make small patches: I don't know enough to be ambitious.

[PeridexisErrant]

Somebody who knows QT really needs to remake this to use DFhack.

I am currently discovering the mess that is DT data structures, and I would not mind a complete rewrite, but that would be a lot of work. Personally, I will only make small patches: I don't know enough to be ambitious.

If you ever do decide to go down this path, I strongly suggest architecting it like Armok Vision - a DFHack plugin plus a standard protocol that can be read by other clients.

[Clément]

I fixed ItemUniform and I don't get any more warning/error messages with my current fortress. I also fixed a few problems caused by the lack of fortress entity during embark (more error messages and visitor/guest filter removing every dwarf).

New builds for testing:

• mingw
• msvc
• Linux/Mac users are welcome to try their own build of the embark branch.

[xordae]

MSVC build working fine here. I noticed in the last (first) build that dwarf ages counted up from -255, but in this one it's doing it properly.

[a52]

The MinGW version is working for me. SSL context crash on reading dwarves is no longer a problem. Thanks for your work!

[gosam]

Hello

Don't know if this has been reported before, but I'm getting this :


This is a military Dwarf that's showing up as red for equipment because of "Torso uncovered", even though he's wearing a breastplate and chainmail. It's actually the same for all my militia.

This is with the version of DT packed with the linux LNP 43.05-r6, which I believe is Hello71's version.

[Clément]

Code: [Select]

    process_uncovered(PANTS,tr("Legs Uncovered!"),(has_shirt ? 1 : 0),1);
    process_uncovered(ARMOR,tr("Torso Uncovered!"),(has_pants ? 1 : 0),1);A simple variable inversion, it should be "Legs Uncovered!".

[gosam]

Indeed, adding greaves fixes it, thanks!
But I thought high boots + chain mail completely covers the legs?