Print

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

[Tengu]

I ran the Therapist with the --trace option and found out from the logs that the race index to expect was probably 220 instead of 200. I set that in the game_data.ini and the Therapist memory scan found the correct address without problems.

[0x517A5D]

This work for me (Windows SDL version):

[info]
checksum=0x4d734fb5
version_name=v0.31.20 (graphics)
complete=true

[addresses]
translation_vector=0x01724250
language_vector=0x01724230
creature_vector=0x016e0478
dwarf_race_index=0x0150cc28
squad_vector=0x0171e758

I can confirm these vectors.  My search tool independently found the same addresses.

I don't have any idea if offsets have changed.  I'm still working on probing those.

[Tatterdemalian]

This work for me (Windows SDL version):

[info]
checksum=0x4d734fb5
version_name=v0.31.20 (graphics)
complete=true

[addresses]
translation_vector=0x01724250
language_vector=0x01724230
creature_vector=0x016e0478
dwarf_race_index=0x0150cc28
squad_vector=0x0171e758

how did you found the race index? what you have to search in the address finder?

Didn't work for me, maybe because I'm using Legacy instead of Graphics... the checksums are the same, though. Here's the creature_vector values my scan came up with:

creature_vector = 0x016e04c8 (uncorrected:0x023d04c8)
creature_vector = 0x016e0478 (uncorrected:0x023d0478)
creature_vector = 0x016e047c (uncorrected:0x023d047c)
creature_vector = 0x0a45badf (uncorrected:0x0b14badf)
creature_vector = 0x0e9a69db (uncorrected:0x0f6969db)
creature_vector = 0x15855283 (uncorrected:0x16545283)
creature_vector = 0x097ecbf3 (uncorrected:0x0a4dcbf3)

If enough people test this with enough systems, we may be able to narrow it down to the correct one... so far, the three consistent ones are 0x016e04c8, 0x016e0478, and 0x016e047c.

[Moleyzz]

This work for me (Windows SDL version):

[info]
checksum=0x4d734fb5
version_name=v0.31.20 (graphics)
complete=true

[addresses]
translation_vector=0x01724250
language_vector=0x01724230
creature_vector=0x016e0478
dwarf_race_index=0x0150cc28
squad_vector=0x0171e758

Confirmed, worked for me, nice one!

[parlor_tricks]

Got this so far.. missing the dwarf race index and squad vector though..

[info]
checksum=0x4d734fb5
version_name=v0.31.20 (graphics)
complete=false

[addresses]
translation_vector=0x01724250
language_vector=0x01724230
creature_vector=0x016e04c8
dwarf_race_index=0x0
squad_vector=0x0

Confirming that this portion works.

[0x517A5D]

This work for me (Windows SDL version):

Didn't work for me, maybe because I'm using Legacy instead of Graphics...

Right.  Different executables means different offsets.

the checksums are the same, though.

Unless both programs finished compiling in the same second, the checksums won't be the same.  We use the linker timestamp field as a "checksum" to avoid problems with mods that permanently patch the executable.

My tool doesn't spit the checksum out yet, but I got 0x4D72F10D by manual inspection.  (It's 8 bytes after the "PE" signature in the EXE header.)

Here's the creature_vector values my scan came up with:

creature_vector = 0x016e04c8 (uncorrected:0x023d04c8)
creature_vector = 0x016e0478 (uncorrected:0x023d0478)
creature_vector = 0x016e047c (uncorrected:0x023d047c)
creature_vector = 0x0a45badf (uncorrected:0x0b14badf)
creature_vector = 0x0e9a69db (uncorrected:0x0f6969db)
creature_vector = 0x15855283 (uncorrected:0x16545283)
creature_vector = 0x097ecbf3 (uncorrected:0x0a4dcbf3)

If enough people test this with enough systems, we may be able to narrow it down to the correct one... so far, the three consistent ones are 0x016e04c8, 0x016e0478, and 0x016e047c.

A vector cannot end in anything but 0, 4, 8, or C.  So most of those fail the eyeball test.

My search tool got these:

language_vector          = ?
translation_vector       = ?
creature_vector          = 0x017B2D00
dwarf_race_index         = 0x015B8248
squad_vector             = ?

So I'm getting a different answer for .20 legacy creature_vector than anyone else is.

[Tatterdemalian]

Right.  Different executables means different offsets.

Unless both programs finished compiling in the same second, the checksums won't be the same.  We use the linker timestamp field as a "checksum" to avoid problems with mods that permanently patch the executable.

My tool doesn't spit the checksum out yet, but I got 0x4D72F10D by manual inspection.  (It's 8 bytes after the "PE" signature in the EXE header.)

We may be referring to different checksums... this is the "version recognition checksum" that DT returns if it can't connect to the Dwarf Fortress instance currently running. The one I got was 0x4d734fb5, the same as the people using the graphics version have been using, and DT wouldn't be able to connect if it wasn't the correct checksum.

[Tengu]

My theory is that DF creates a creature vector for each of the dwarves. In this case the address to use would be the address of the first vector. That probably is the lowest of the addresses,  0x016e0478 in this case. I did some testing, using the other creature_vector addresses and keeping the others unchanged. This otherwise works but some of the dwarves are not displayed. I take this as circumstantial evidence supporting my theory.

[0x517A5D]

We may be referring to different checksums... this is the "version recognition checksum" that DT returns if it can't connect to the Dwarf Fortress instance currently running. The one I got was 0x4d734fb5, the same as the people using the graphics version have been using, and DT wouldn't be able to connect if it wasn't the correct checksum.

No, same checksum.
.20 SDL = 4D734FB5 = Sun Mar  6 09:11:17 UTC 2011
.20 legacy = 4D72F10D = Sun Mar  6 02:27:25 UTC 2011

Do you possibly have both the SDL and legacy executables running at the same time?  Check via Ctrl-Alt-Delete.

[peterix]

My theory is that DF creates a creature vector for each of the dwarves. In this case the address to use would be the address of the first vector. That probably is the lowest of the addresses,  0x016e0478 in this case. I did some testing, using the other creature_vector addresses and keeping the others unchanged. This otherwise works but some of the dwarves are not displayed. I take this as circumstantial evidence supporting my theory.

No. There are only three real creature vectors that contain dwarves after embark. Rest can't be traced back to stable addresses properly, so it's probably shadows remaining after reallocations... And then there's the fourth vector that contains creatures under the active cursor.

Code: [Select]

0x1877e88 -- creature under cursor
vectors (subtract 4 to get DT-friendly vectors):
0x16e048c
0x16e047c -- I use this one in dfhack
0x16e04cc

[Tengu]

My theory is that DF creates a creature vector for each of the dwarves. In this case the address to use would be the address of the first vector. That probably is the lowest of the addresses,  0x016e0478 in this case. I did some testing, using the other creature_vector addresses and keeping the others unchanged. This otherwise works but some of the dwarves are not displayed. I take this as circumstantial evidence supporting my theory.

No. There are only three real creature vectors that contain dwarves after embark. Rest can't be traced back to stable addresses properly, so it's probably shadows remaining after reallocations... And then there's the fourth vector that contains creatures under the active cursor.

Code: [Select]

0x1877e88 -- creature under cursor
vectors (subtract 4 to get DT-friendly vectors):
0x16e048c
0x16e047c -- I use this one in dfhack
0x16e04cc

Oh. Then I just happened to stumble upon partially intact vectors when tinkering with the incorrect addresses. Thanks for the information.

[Tatterdemalian]

No, same checksum.
.20 SDL = 4D734FB5 = Sun Mar  6 09:11:17 UTC 2011
.20 legacy = 4D72F10D = Sun Mar  6 02:27:25 UTC 2011

Do you possibly have both the SDL and legacy executables running at the same time?  Check via Ctrl-Alt-Delete.

Nope, just Dwarf Fortress.exe and DwarfTherapist.exe. I guess I must have downloaded the graphics version by mistake.

That said, none of the addresses posted so far have made even a single dwarf appear in my list. I'm going to try changing the expected_dwarf_race to 220 as one of the posters suggested, and see if that works any better.

EDIT: Actually, I think I'll redo the whole thing using v0.31.19_graphics.ini instead of v0.31.19_legacy.ini as the template. That's almost certainly the problem.

[DwarfEngineer]

New layouts for linux and windows have been posted online.  If you are using Dwarf Therapist 0.6.9, it should download them automatically the next time you start DT with the new version of Dwarf Fortress running.  If you have a partial memory layout for v31.20, you'll want to delete it, otherwise Dwarf Therapist may not download the newest version.

If you have problems or want to update therapist manually, you can also download the layouts here:

• Windows SDL
• Windows Legacy
• Linux

[Tatterdemalian]

Man, I suck at this. Thanks, DwarfEngineer!

[Carcanken]

New layouts for linux and windows have been posted online.  If you are using Dwarf Therapist 0.6.9, it should download them automatically the next time you start DT with the new version of Dwarf Fortress running.  If you have a partial memory layout for v31.20, you'll want to delete it, otherwise Dwarf Therapist may not download the newest version.

If you have problems or want to update therapist manually, you can also download the layouts here:

• Windows SDL
• Windows Legacy
• Linux

Yay! I can finnally play .20 now! Thanks!