Skip to content

Conversation

@Tohkai
Copy link

@Tohkai Tohkai commented Jan 9, 2026

Added devel/export-dt-linux which uses the export-dt-init script to export the current memory layout to the right linux path with the correct name for DT

"Automatic" might be an exaggeration as you still need to call it. I made this script on my own at some point to automatically export the memory layout with the right name under the right path on linux, so that dwarf therapist can connect immediately after using this command on any new version.

I thought later on that I might as well commit it but I do realize now that I am doing this that I don't really know if there are any development practices in place for this project. This is also my first time doing anything in lua at all so I may not be aware of better practices.

Notably...

  1. I'm not sure if there are naming conventions to which I should adapt for the script's/command's name
  2. It did say "no help available" in DF which seems to indicate that I should be able to put some documentation somewhere
  3. I'm not sure if there is anyway to do an ifdef linux/win32 or whatever else in order for this command to only appear on systems where it will function
  4. I did consider, instead of calling that other script, which does all the heavy lifting, modifying said script instead but I was not sure if it would be considered ethical. EG I would have probably checked for an argument, and, provided the argument was there, I would have altered the behavior so that it writes the file right away in the right place, instead of stupidly calling that command to make a file at the root of dwarf fortress, and then copy it and delete it. I'm willing to change that if preferable
  5. Maybe the right approach would be to have it run automatically every time and check if that directory exists, and if that .ini exists, and then run the actual logic if we have that directory available (indicating that the user uses DT) but no memory layout for this version

Currently tested & working on linux, steam version.

…xport the current memory layout to the right linux path with the correct name for DT
@ab9rf
Copy link
Member

ab9rf commented Jan 9, 2026

the problem with this idea is that there is no reliable means to determine the "right path" to write the file to. DFHack has no way of knowing where you've chosen to unpack/install Dwarf Therapist. The path you've hardcoded will work in some distributions and configurations, but it will not work on others. And since this code doesn't even check to see if the target path is even writable, this is a nonstarter as it stands. Note that if any of the directories in that path don't exist, the file open will simply fail and the tool will not write the file anywhere, which breaks the tool entirely.

This will not be merged without addressing these issues.

@Tohkai
Copy link
Author

Tohkai commented Jan 9, 2026

Understandable. So I should have it figure where the XDG path is, or others if using a flatpak/snap version (are there snap and flatpak versions of dt ? )

@ab9rf
Copy link
Member

ab9rf commented Jan 9, 2026

Understandable. So I should have it figure where the XDG path is, or others if using a flatpak/snap version (are there snap and flatpak versions of dt ? )

someone could also just download hte source from github and compile it themselves and run it in some random directory

to be completely frank dealing with the abject madness of linux application packaging is not something we're particularly looking to bake into DFHack

what i will entertain is adding a "write here" option to the export dt.ini program; there's no reason why we can't let a user specify a target location if they want

@Tohkai
Copy link
Author

Tohkai commented Jan 9, 2026

You mean, like giving an argument to the existing devel/export-dt-ini to give a destination path, and keeping current directory as default without an argument?

I could probably do that but what about the name of the file? currently it outputs it to a hardcoded "therapist.ini". I don't know if there is a reason for this. It's worth noting that I'm not very familiar with the way DFhack works so the way I make the name of the file might be a little bit dirty as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants