Print

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

[leopap]

Experimental memory layouts for 50.11

• linux classic
• linux itch
• linux steam
• windows classic
• windows itch
• windows steam

Thank you very much!

[Clément]

New version released: 42.1.1

This release only adds the memory layouts for 50.11 with no change since I posted links here. If you already have installed the memory layouts, you don't really need this release.

Changelog:

• added memory layouts for 50.11

[Clément]

New version released: 42.1.2

Changelog:

• fixed equipment update for military dwarves

[Inarius]

Thanks for your work !

[CEHA]

I installed and compiled from GIT on Debian, the question is how to remove it?

[Clément]

I installed and compiled from GIT on Debian, the question is how to remove it?

Sadly, you have to do it manually. CMake may have left a file in your build directory listing the files it installed (I don't remember the exact name).

For a complete cleanup you may want to delete the files it may have created in your home (~/.config/dwarftherapist, ~/.local/share/dwarftherapist, ~/.cache/dwarftherapist)

[Clément]

I uploaded several new repos on github.
https://github.com/cvuchener/libdfs

I initially wrote this for generating memory layouts for Dwarf Therapist directly from df-structures xml files several years ago and reused it for various experimental projects. It grew into a library for introspecting DF types, parsing DF memory and generating code (enums and bitfields only for now).

It can read memory more efficently than DT by grouping more data together. This allow using slower methods like network protocol to access DF data.
https://github.com/cvuchener/dt-memory-layout

The tool that can produce Dwarf Therapist memory layouts using the previous library. Unlike the dfhack script, it does not need to be run on the target platform so it can generate memory layouts for all targets at once.
https://github.com/cvuchener/df-workdetailtest

A prototype for what could be become the next Dwarf Therapist.

This far from a DT replacement yet. It does show much data, has no grouping/filtering and very limited sorting. The purpose of this release is mostly testing interactions with the game.

Main changes from DT:

• DFHack is mandatory (with extra plugins, see below)
• It can connect to DF at any point when it's running, no need for a loaded save.
• It (optionally) check for world/map/viewscreen changes and automatically reload on world/map changes and when the dwarves setup screen is open.
• Changes are sent immediately to the game, no need for "commit changes". (Does this break some usage?)

You can download a build for windows: https://github.com/cvuchener/df-workdetailtest/releases/tag/v0.1 (I hope it works on other computers than mine, it's built using mingw64, I have some weird issue with msvc and qcoro that may take time to solve)

You need two plugins: workdetailtest is mandatory, and llmemreader is only used if the native api cannot be used (because of security settings or for accessing the process remotely)
You can download builds for DFHack 50.11-r4:

• https://github.com/cvuchener/dfhack-plugin-workdetailtest/releases/tag/v1
• https://github.com/cvuchener/dfhack-plugin-llmemreader/releases/tag/v1

It can currently edit:

• work detail assignment (by clicking the corresponding cell)
• specialized worker flag (by clicking the corresponding cell)
• work details name/icon/mode (by right-clicking the header)
• unit nickname (by double-clicking or right-clicking the name)

Known issues:

• DF may hang when quitting while a client is still connected.
• Log files are not created unless you create the directory manually (on Windows: AppData/Local/WorkDetailTest/log)

Don't hesitate to ask questions, give feedback, report bugs.

[Starver]

Main changes from DT:

• Changes are sent immediately to the game, no need for "commit changes". (Does this break some usage?)

I could/would work around this, personally (I probably spend more time with DF paused than running, historically), but I'd suggest an option to override this default where some is inclined to set/unset things in groups or runs before fine-tuning. (E.g. adding in <foo>-hauling for everyone then immediately undoing it for miners, or undoing smoothing for everyone then adding it back on for the select few chosen by some other criteria... Or whatever options work under the premise of "workdetail"ness, which I'm still a little hazy about.)

Having to get used to so many possible changes, I'm of course really just suggesting this out of old habit. Before even playing with the new tool, in situ.

[Clément]

adding in <foo>-hauling for everyone then immediately undoing it for miners, or undoing smoothing for everyone then adding it back on for the select few chosen by some other criteria...

These use cases work well with work details, this is switch between "Everyone does this except specialists" and "Only assigned do this". Any way if you do this while the game is paused, it does not change anything. If it was unpaused, the worst is a miner may have started hauling something.

I was thinking more of something like doing a lot of changes then review them and revert a few you are unhappy with before committing.

This remind me of another related change I should make explicit: DT was reloading data after committing, here it is not the case, only the individual change is applied locally (if it succeeds). You will need to click "update" manually if you want to be sure to be synced with the game (you should update every time you look at the application after playing for while with the old or the new system alike).

[Clément]

I added a flatpak bundle for linux users at https://github.com/cvuchener/df-workdetailtest/releases/tag/v0.1, it requires the org.kde.Platform runtime. It is not a repo so it won't update automatically, but I think it's better for experimental program.

[Clément]

Mixing cell painting + live update + sorting by assignment gives annoying but kind of expected results:

It is even worse with grouping

I think I'll try to disable the cell painting if the cells are moving.

[feelotraveller]

Just a comment on the latest, resolved, issue on github: the Steamdeck OS (known as SteamOS) is basically a GUI layer built on top of Arch Linux - so any scripts, commands, installations need to use pacman rather than apt-get.  It is also 'armoured' in that steam sets the majority of the system to read-only to, um, 'protect' the OS from user interventions.  To get around this, not recommended by steam as you would expect - except for 'advanced' users - it is necessary to run

Code: [Select]

sudo steamos-readonly disablewhich then allows access to the normal range of sudo and pacman commands, for example to grab gcc, clang or other packages from the arch repositories or the AUR (user repositories).  Hopefully this might help a bit with providing support for users of steamdeck in the future.

-----

Separately, since I'm posting, re the previous post - what is the advantage (other than avoiding clicking a commit button) of having therapist do live updates?  Or was it just something you were having fun trying out.

[Clément]

Just a comment on the latest, resolved, issue on github: the Steamdeck OS (known as SteamOS) is basically a GUI layer built on top of Arch Linux - so any scripts, commands, installations need to use pacman rather than apt-get.  It is also 'armoured' in that steam sets the majority of the system to read-only to, um, 'protect' the OS from user interventions.  To get around this, not recommended by steam as you would expect - except for 'advanced' users - it is necessary to run

Code: [Select]

sudo steamos-readonly disablewhich then allows access to the normal range of sudo and pacman commands, for example to grab gcc, clang or other packages from the arch repositories or the AUR (user repositories).  Hopefully this might help a bit with providing support for users of steamdeck in the future.

I have a qemu vm with steamos, so I know a little how it works, but it is not the same as a real steam deck (no gpu driver means no game mode, only the desktop is available). I don't think using pacman is a good idea, the updates will overwrite the installed packages any way. I think it is best to provide already built binaries. At least by moving to a dfhack plugin, there won't be any issue with ptrace_scope, and it can even work from a flatpak.

Separately, since I'm posting, re the previous post - what is the advantage (other than avoiding clicking a commit button) of having therapist do live updates?  Or was it just something you were having fun trying out.

I think the main advantage is avoiding clicking a commit button. It's something I did not feel was needed, but it is only my personal opinion, so I was asking it breaks some usage I did not think of.

It should not be too difficult to re-implement the pending changes/commit mechanism, at least for cell toggling. I don't know how pending work detail creation/deleting/moving should be displayed.

[Immortal-D]

Good old Therapist (the inflexibility of labor groups in Premium is a bit silly).  Anyways, I ran into an issue and am unsure if it's a setting I changed; I assigned a Dwarf the Stonecrafting labor, committed change, then ordered a few rock pots, but that Dwarf still shows 'no job'.  Do I need to change my ingame labor groups to 'all'? (I thought DT overwrites those).  Edit: Disregard, my joy of recreating my old professions caused a rookie mistake.

[feelotraveller]

Just a comment on the latest, resolved, issue on github: the Steamdeck OS (known as SteamOS) is basically a GUI layer built on top of Arch Linux - so any scripts, commands, installations need to use pacman rather than apt-get.  It is also 'armoured' in that steam sets the majority of the system to read-only to, um, 'protect' the OS from user interventions.  To get around this, not recommended by steam as you would expect - except for 'advanced' users - it is necessary to run

Code: [Select]

sudo steamos-readonly disablewhich then allows access to the normal range of sudo and pacman commands, for example to grab gcc, clang or other packages from the arch repositories or the AUR (user repositories).  Hopefully this might help a bit with providing support for users of steamdeck in the future.

I have a qemu vm with steamos, so I know a little how it works, but it is not the same as a real steam deck (no gpu driver means no game mode, only the desktop is available). I don't think using pacman is a good idea, the updates will overwrite the installed packages any way. I think it is best to provide already built binaries. At least by moving to a dfhack plugin, there won't be any issue with ptrace_scope, and it can even work from a flatpak.

Any update will overwrite (or replace to be more precise) user package changes but for the case of the user compiling their own binary it works fine.  But yes, prebuilt binaries or flatpacks would be preferred.

Separately, since I'm posting, re the previous post - what is the advantage (other than avoiding clicking a commit button) of having therapist do live updates?  Or was it just something you were having fun trying out.

I think the main advantage is avoiding clicking a commit button. It's something I did not feel was needed, but it is only my personal opinion, so I was asking it breaks some usage I did not think of.

It should not be too difficult to re-implement the pending changes/commit mechanism, at least for cell toggling. I don't know how pending work detail creation/deleting/moving should be displayed.

Up to you really.  Nothing I know of that breaks but if someone (like me) changes their mind while reassigning dwarfs it can be a bit chaotic with job interruptions and the like.