Bay 12 Games Forum

You need a version of DFHack that supports the 50.10 betas. You can get that by switching to DFHack's beta or testing branch (not sure which) on Steam, or if you prefer to download it manually, you can get it from the "5010-beta" branch on GitHub by following the instructions at https://docs.dfhack.org/en/latest/docs/Installing.html#development-builds

Be warned that it is not very stable yet, and DF is rapidly releasing new builds - so even if you do manage to get DT working, DF could well update within a day and require another DFHack update. If you want stability, I would probably wait a couple days.

May I also softly hint that MacOS users comprise about a third of the market (I could find the source but that would be pedantic even for me) and that as MacOS has switched to ARM64/aarch64 it might be prudent to release a version for the mac and linux users on ARM? I know that I at least have not bought a copy yet as it doesn't run on my personal computer. Perhaps this is true for a significant number of people.

At least historically, DF users on Linux have far exceeded users on macOS. My understanding is that's part of the reason why Linux is being prioritized.

Many of the delays on Linux have been due to library issues. DF v50 on Windows recently upgraded to SDL2, but had also needed to upgrade FMOD for sound, upgraded to a new compiler for newer C++ features, and probably more that I am forgetting. Linux DF needed similar upgrades for modernization (and I believe an entirely new SDL_mixer backend for music was added), and those all have taken time. I expect macOS to face similar upgrades and delays.

Getting DF built on ARM will certainly add more work on its own - that has never been done before, and although the source code likely won't have to be changed, the build system almost certainly will need changes, and dependencies might as well. Hardware access is likely another big challenge - if Bay12 wants to test these builds themselves, they would need ARM hardware, and likely also newer x86 hardware to run x86 builds, since my understanding is that their previous Mac hardware is well past its EOL.

I've seen written by Putnam that it 'could be' as simple as pressing a button

I'm skeptical that this is the case, but it is true that once DF is compiling on Linux, getting it to compile on macOS has generally been pretty easy in the past. They have historically used the same compiler (GCC); new macOS builds might transition to Clang, but GCC and Clang typically behave much more similarly than GCC and MSVC (on Windows), so I expect building DF on macOS to be fairly straightforward once it's building on Linux. Getting it to run is another story, which is what I was getting at above.

Step by step instructions to create the memory map file required for Dwarf Therapist to work with new, experimental or beta builds:

1. Install DF Hack if not already installed
2. Run devel/export-dt-ini in DF Hack, which creates an ini file in the base DF directory
3. Copy that file into your dwarf therapist folder in "dwarf therapist base folder"\data\memory_layouts\windows (or whatever platform you're on) folder
4. Not sure if this is required, but I did it: rename the ini file to the version name contained within it. Line three in the file I just created was version_name=v0.50.09 win64 STEAM so I renamed the ini file v0.50.09 win64 STEAM.ini

For anyone still looking, you can skip steps 1-2 and download a pre-made memory layout from https://github.com/Dwarf-Therapist/Dwarf-Therapist/pull/301/files, then use that file in step 3. Hopefully this will be merged soon.

Sure... but, here's a newbie question. How do I bring up the in-game console to see a readout? Where am I looking?

By "DFHack console" I actually meant the out-of-game console, i.e. the separate console window, which you can bring up with "show" if it's not visible. I only asked because the devel/annc-monitor script is also supposed to print to the standalone console, and error messages typically also get printed there, so it would be a good place to check for issues. It's not required to run the script from there for it to function.

My bad. It works. So awesome!  I'd suggest just turning off music and weather on soundsense-rs and run the sounds together with the DF 50 system.

Does Dfhack have any startup configuration abilities?

Was it working the whole time or did you change something?

DFHack has lots of startup configuration abilities. You can configure commands to run on startup, whenever a world is loaded, when a specific world is loaded, and more. https://docs.dfhack.org/en/stable/docs/Core.html#configuration-files

There are also ways to do some of this in the DFHack launcher ("gui/launcher").

If ran ... devel/annc-monitor start ... from within dfhack's console, but nothing different is added to the gamelog. Any ideas?

That should work... Putnam's suggestion is for how the Soundsense authors could reimplement Soundsense as a mod.

Are announcements getting printed to the DFHack console if you pull it up? Or are there any errors? Your log() implementation there should print to both the console and gamelog.txt.

Try running the script after the world is loaded and see if that makes a difference.

Fantastic project, so much faster than LegendsBrowser 1.0!

I'm using it with xml exports from the steam version. It works, but there are many "UNKNOWN POSITION", "UNKNOWN OCCASION", "UNKNOWN JOB", etc. Is there a plan to extend functionality for this version of Dwarf Fortress?

It would probably be helpful to open an issue at https://github.com/robertjanetzko/LegendsBrowser2/issues and attach the problematic file. To your question: yes, there has already been some effort to add support for DF 50.x, judging by the release notes at https://github.com/robertjanetzko/LegendsBrowser2/releases. It's difficult to support every new DF feature because there isn't an exhaustive list of new features, so getting extra data like your XML file is generally helpful for third-party tools like this to support more features.

There's a DLL you might need to download to get it to work though, msvcp140_atomic_wait. Just throw that dll into your main directory and you're airborne.

This alone typically isn't enough on Wine 8, and for Wine 7 it typically isn't necessary. For Wine 8, these instructions might work, but I haven't tested them out yet.

I'm using wine 8.11.

It's pretty straightforward for Wine directly.  You get a copy of msvcp140_atomic_wait.dll (from various places on the internet).  You put it in the Dwarf fortress folder.  Then you run winecfg.  Go to the "libraries" tab. In the "New override for library" drop down you select msvcp140_atomic_wait.dll and then hit the "Add" button.   Finally "Apply" or "OK".  After that wine DF will work with wine.

For doing it with Proton, it's a bit more complex because you have to run winecfg specifying the the directory that Proton is installed in.  Also, the default prefix seems to have problems for me, so you have to find the DF prefix (which is in the Steam folder somewhere) and update that.  After that, it's the exact same procedure as per normal wine.