Print

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

[billybobfred]

I can't confirm that it works 100% but haven't noticed any issues so far.

Well, it thinks "Make rock mugs" is "Forge rope", but as long as it can detect idlers and mass-assign labors (fyi it can), I'm not too bothered.

[DwarfEngineer]

New layouts for linux and windows version 0.31.25 have been posted online.  If you are using Dwarf Therapist 0.6.9 or later, 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.25, 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

There will be a release.

I'm less sure of when.

[peterix]

Addition: I was able to confirm that the offset in the INI file is correct (0x003c for me) and I see the c-string located at that offset. I told DT to change the custom profession name and the pointer to a c string did not change, and the memory pointed to did not change either.

It is NOT a C string. It's a STL string. That's a big difference.

STL strings on windows (programs compiled with MSVC) have a small fixed buffer of 16 bytes that can be set without allocating extra memory. On linux, there's no such buffer, just dynamically allocated string. It's not possible to manipulate that safely without some extra hacks in place.

I don't know how DT handles it, but it should be possible to set strings that have been already allocated to values that are equally long or shorter.

[vrga]

Just to note, compiled from the repo on gentoo, works damn fine

[Daskinor]

Wish I could also participate in the general bug-free happy dance, but something in the latest DT crashes for me in a way that I've never seen DT do before, and have been using it since early 0.31.x

Running 64 bit Linux compiled from source pulled from the hg tree as of current date (identifying itself as v0.6.11), and also under gentoo. I've also checked and compiled the latest of all the packages DT uses that are dynamically linked against the DT binary - still no improvement.

For the curious these are

Spoiler (click to show/hide)

x11-libs/libXau
x11-libs/libxcb
dev-libs/expat
sys-apps/util-linux
x11-libs/libX11
x11-libs/libXext
media-libs/fontconfig
x11-libs/libXrandr
x11-libs/libXrender
x11-libs/libICE
x11-libs/libSM
media-libs/mesa
dev-libs/glib
media-libs/freetype
media-libs/libpng
sys-libs/glibc
x11-libs/qt-core
x11-libs/qt-script
x11-libs/qt-gui
sys-devel/gcc
sys-libs/zlib

What happens is an immediate crash (that brings up gnomes 'bug-buddy' tool that cant identify the application but still offers to generate a debug trace regardless) whenever i click on any of the labour items for all dwarves listed bar.. one. Why this dwarf (a high master milker with some ability as an animal trainer, fisher and bonecarver) is exempt from the crash I have no idea.. and it still crashes for him when I try and click on his name to bring up traits, all skill levels and xp to next level and the like - as it does for all the other dwarves.

Going back to dt circa December 30th 2010 (0.6.7 I believe) which worked perfectly under 0.31.18 also works for 0.31.25 as long as I have the newer memory_layouts for 0.31.25 and if I can live with not having any of the new skills like beekeeping, glazing and pottery represented, listed or controllable - as these options were not present at the time. Which is a far sight better than having it be completely unusable I guess, and my fortress isn't at a level yet where desperation to know who my bee-keepers are and how good they are is a burning need.

But still is bothersome. Anyone seen anything similar? Older dt versions that are working and linked against the same libraries when current ver is broken is suggestive of some new feature or capability that isnt right yet that's involved with GUI popups or setting active labors.

[vrga]

Wish I could also participate in the general bug-free happy dance, but something in the latest DT crashes for me in a way that I've never seen DT do before, and have been using it since early 0.31.x

Running 64 bit Linux compiled from source pulled from the hg tree as of current date (identifying itself as v0.6.11), and also under gentoo. I've also checked and compiled the latest of all the packages DT uses that are dynamically linked against the DT binary - still no improvement.

For the curious these are

Spoiler (click to show/hide)

x11-libs/libXau
x11-libs/libxcb
dev-libs/expat
sys-apps/util-linux
x11-libs/libX11
x11-libs/libXext
media-libs/fontconfig
x11-libs/libXrandr
x11-libs/libXrender
x11-libs/libICE
x11-libs/libSM
media-libs/mesa
dev-libs/glib
media-libs/freetype
media-libs/libpng
sys-libs/glibc
x11-libs/qt-core
x11-libs/qt-script
x11-libs/qt-gui
sys-devel/gcc
sys-libs/zlib

What happens is an immediate crash (that brings up gnomes 'bug-buddy' tool that cant identify the application but still offers to generate a debug trace regardless) whenever i click on any of the labour items for all dwarves listed bar.. one. Why this dwarf (a high master milker with some ability as an animal trainer, fisher and bonecarver) is exempt from the crash I have no idea.. and it still crashes for him when I try and click on his name to bring up traits, all skill levels and xp to next level and the like - as it does for all the other dwarves.

Going back to dt circa December 30th 2010 (0.6.7 I believe) which worked perfectly under 0.31.18 also works for 0.31.25 as long as I have the newer memory_layouts for 0.31.25 and if I can live with not having any of the new skills like beekeeping, glazing and pottery represented, listed or controllable - as these options were not present at the time. Which is a far sight better than having it be completely unusable I guess, and my fortress isn't at a level yet where desperation to know who my bee-keepers are and how good they are is a burning need.

But still is bothersome. Anyone seen anything similar? Older dt versions that are working and linked against the same libraries when current ver is broken is suggestive of some new feature or capability that isnt right yet that's involved with GUI popups or setting active labors.

you're in a multilib enviroment, right?


try compiling 32-bit DT. default symlinks IIRC all point to x64 libs.

[mrbaggins]

DT/etc/memory_layouts/windows/

Duplicate the latest (should be 31.21_graphics) and rename the copy 31.35. Replace it's text with what is shown.

Did you mean "rename the copy 31.25"?

[Oscard]

Still no chance for an update version of the mac client? Is it possible to cider wrap the current client? I know the last non official version you had to target DF...I know alot of mac player dont get very far because of the time it takes to assign workers and remember which workers are doing what, looking through the in game UI for this is fairly clunky.

[profit]

Still no chance for an update version of the mac client? Is it possible to cider wrap the current client? I know the last non official version you had to target DF...I know alot of mac player dont get very far because of the time it takes to assign workers and remember which workers are doing what, looking through the in game UI for this is fairly clunky.

It is open source, if you have a mac, go to it.

[Oscard]

Still no chance for an update version of the mac client? Is it possible to cider wrap the current client? I know the last non official version you had to target DF...I know alot of mac player dont get very far because of the time it takes to assign workers and remember which workers are doing what, looking through the in game UI for this is fairly clunky.

It is open source, if you have a mac, go to it.

I have no way of knowing how to go about it. I guess i could look into some sort of way to do it. I have zero coding/compiling experience.

[yamamushi]

Still no chance for an update version of the mac client? Is it possible to cider wrap the current client? I know the last non official version you had to target DF...I know alot of mac player dont get very far because of the time it takes to assign workers and remember which workers are doing what, looking through the in game UI for this is fairly clunky.

It is open source, if you have a mac, go to it.

I have no way of knowing how to go about it. I guess i could look into some sort of way to do it. I have zero coding/compiling experience.

It doesn't look like anyone wants to take on the challenge of maintaining a Mac Dwarf Therapist build. I made a post about it on Reddit:

http://www.reddit.com/r/dwarffortress/comments/gjscl/dwarf_therapist_for_mac_osx/

It looks like there are references in place for a Mac Build, if my assumptions from my glances over the source files are correct. I had a few problems when trying to compile it in qt, but it got quite far which leads me to believe that an OSX build isn't that far off. Perhaps if I am able to get pointers from some devs in the irc room, I'd be happy to start maintaining an OSX build for the community.

If anyone can help out or can shoot me some pointers in the right direction, please send me a PM.

Note: I did take a look at the source code for jofarrel's build, but he was basing his code on an older release of DT and I felt like I was being pulled down the wrong path the further I dug in.

[yamamushi]

Scratch that, the references are only a "shell" of code, to be filled in by a developer at a later time. I guess that leaves me a project to work on this week :-)

[forsaken1111]

Is the demand for a mac version really all that strong?

[ral]

I would use it. I'm actually playing DF on a pc right now simply due to the lack of dwarf therapist on os x. My mac might actually be faster too.

[devek]

Is the demand for a mac version really all that strong?

But it doesn't outweigh the demand to laugh at mac users.

(just kidding, mac <3)