Print

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

[Clément]

Most amusingly, it thinks half of my fort are legendary Gelders.

Skills are supposed to be fixed. Did you install the modified game_data.ini?

Work detail support wouldn't be necessary for basic labor support; as of v50.04 there is a global external flag exported by the game with the rest of the global addresses that can be flipped to disable work details completely so that utilities can do more granular operations without work details stomping on them (since they replace all dwarf labors whenever they're modified at all).

What is the name of this flag?

Anyway, work detail support will have to be added sooner or later. Adding memory management capabilities will also enable for other features like burrow management, or maybe occupations. It would be something really nice to have.

About macOS support, I cannot maintain it because Apple does not make it easy to develop applications for mac without Apple hardware. And it has bugs like requiring running as root. Replacing the macOS port with a DFHack port would fix all of this. It could still be optional for other platforms.

[ab9rf]

What is the name of this flag?

It's in Toady's "cheat sheet" as "game.external_flag". The DFHack team is treating this as an "ignored global" because it's within the larger "game" structure and we prefer to simply note its location as part of that larger structure so you won't find it in our symbols.xml as a separate entry, but of course I'm sure you know how to find Toady's handy-dandy list of globals and can get to it that way. According to what we've been told, setting the low bit of the byte at this address to 1 disables work policy processing entirely and leaves all labor management up to external tools.

[Starver]

maybe 80% of DT users also already run dfhack but some of the remaining 20% are quite adverse to dfhack.

Datum point: I might occasionally use DFHack, up to a limit (I don't want the temptation of far-too-easy autodump, e.g., unless the current project is a more a mechanical/architectural test and I'd like loads of rubble out of the way or it'd be good to teleport all the loose material of some kind to one place) and if/when I add it to the current DF I quickly write up an unhack.bat to reverse the change and leave me 'vanillafied' as soon as I'm done fooling with whatever I'm fooling.

But I'll run DT without reservations. It 'just' streamlines what I do (or would like to do) or know (or would like to know) outside the game-code, and restricts itself to altering only those things that I'd otherwise go in there and alter.

That's my (fuzzy) red-line. If DFHack is needed, I wouldn't say I'd be 'averse' (nor would it be adverse!), but I'd rather not require it as always-on 3rd- or 4th-party tool. In my own weird little manner. Though it sounds like I, in particular, shan't need it. Beyond the occasional dabble for which I do remain grateful to its various contributors.

[Arkenor]

DFHack is a must have for me, so my doctors can heal my animals. Also useful for dealing with stuff that bugs out.

[Tabris]

Skills are supposed to be fixed. Did you install the modified game_data.ini?

Really? They are still a bit scrambled for me. I put the game_data.ini file on Dwarf Therapist/data. I did notice it didn't overwrite anything. I have the latest Dwarf Therapist version from the Releases on Github. Am I supposed to be using another version?

[Clément]

Actually I was partially wrong, skills should be correct in "Dwarf Details" or in the dwarf tool-tip, but grid views needs to be updated too. If you check the tool-tip over the "Gelding", you may read something like "Gelding - Competent Musician", so the skill you see is actually "musician".

[lethosor]

I think it's probably possible to have a backend that works via native memory access and one that interfaces with DFHack, although it would probably be a bit more work to support both options at once. But if we want to support macOS and support users on other platforms who don't want to use DFHack, I think these two backends is the most feasible approach.

[Tabris]

Actually I was partially wrong, skills should be correct in "Dwarf Details" or in the dwarf tool-tip, but grid views needs to be updated too. If you check the tool-tip over the "Gelding", you may read something like "Gelding - Competent Musician", so the skill you see is actually "musician".

Oooh, I had already figured that out, just assumed from the post that Grid View had been fixed as well.

[crazyabe]

Actually I was partially wrong, skills should be correct in "Dwarf Details" or in the dwarf tool-tip, but grid views needs to be updated too. If you check the tool-tip over the "Gelding", you may read something like "Gelding - Competent Musician", so the skill you see is actually "musician".

christ, Dwarf fortress specifically has skills for Gelding Competent Musicians now? damn its getting in depth.

[Clément]

I think it's probably possible to have a backend that works via native memory access and one that interfaces with DFHack, although it would probably be a bit more work to support both options at once. But if we want to support macOS and support users on other platforms who don't want to use DFHack, I think these two backends is the most feasible approach.

One idea I want to evaluate is keeping the reading low level. That is mostly moving the calls to vm_read_overwrite/process_vm_readv/ReadProcessMemory into dfhack to avoid permission issues. The main difficulty is that DT does a lot of small reads, with a whole network RPC for each read this is not possible, reads need to be aggregated. I need to check if reading whole object at once is enough, or if I need to read and cache whole pages or group of pages. Also COW strings may be very bad for this, I hope the next version will use SSO strings.

[Rose]

The network rpc is pretty fast, and I've used it plenty for small reads.

[Rudyard_Clipping]

Hi there first message on Bay12 forums to thank you for the work you put in updating DTherapist. To react to some previous messages, I never used DFHack, while I wouldn't be able to play whithout DTherapist.

I want to ask this not to put any pressure on anyone but because I have absolutely no idea of the difficulty of the task: is having a 50.04 compatible version of DTherapist a matter of months? Of weeks? (of minutes, why not )

[Clément]

The network rpc is pretty fast, and I've used it plenty for small reads.

How much is "plenty"? DT often reads integers one at a time and this leads to hundreds of thousands of calls to read_raw for a small save. If I force reading all creature raws, it is over a million. I think I tested a naive implementation of read_raw over DFHack RPC a long time ago and it took over 15 minutes to load. Maybe it was an issue with debug performance, maybe my DFHack RPC implementation was bad. There may also have been an issue with DT attach/detach mechanisms not being used correctly. Anyway it is slower than single system calls and it reveals a lot of issue in the way DT reads its data but it should be fixable.

Hi there first message on Bay12 forums to thank you for the work you put in updating DTherapist. To react to some previous messages, I never used DFHack, while I wouldn't be able to play whithout DTherapist.

I want to ask this not to put any pressure on anyone but because I have absolutely no idea of the difficulty of the task: is having a 50.04 compatible version of DTherapist a matter of months? Of weeks? (of minutes, why not )

I cannot make any promise except that it is not minutes. As I already said, I plan to make a read-only release (or maybe with old-school labor management using Putnam trick) as soon as DFHack's df-structures is good enough for me (that is usually before it is good enough for DFHack itself since DT only uses a small subset of it). Then take my time to add support for new features like work details.

[Anonymous_Wind]

I cannot make any promise except that it is not minutes. As I already said, I plan to make a read-only release (or maybe with old-school labor management using Putnam trick) as soon as DFHack's df-structures is good enough for me (that is usually before it is good enough for DFHack itself since DT only uses a small subset of it). Then take my time to add support for new features like work details.

Thanks for the update Clément. Good luck with the coding, and happy new year!

[JezaGaia]

If you cannot wait, you may try this memory layout (save in data/memory_layouts/windows) and this game_data.ini (save in data directory). Some data may be correct (skills, attributes, personality facets, ...) but don't trust too much in it. Also existing gridviews may be incorrect (e.g. skill not matching the column title).

Hey I just saw this and I would love to try it but DV is now in v5.04 and this only goes to 5.03, is there any modification I can do to make it work ?
Tbank you so much for your help ! having the therapist even only to read the dwarf details would be incredible