DFHack
Feature Request: "orders" export/import from custom folders
The orders command can import/export a json file of orders.
Im using that feature to make a web tool to manage orders.
My issue is that browser's file access system prevent access to specific directories such as system files or user data. On Windows+Steam the folder where Dwarf Fortress is installed is in "program files", which is restricted.
Of course I can save the file somewhere else and move to DF's folder, but my goal is to make a quasi-realtime tool, so having the user copy files around at every update would defeat the purpose.
My request is to be able to specify a path when exporting/importing the orders json file.
Exemple:
order export "c:\productionOrders.json"
Thank you for your attention.
The web-app tool being used apparently has a restriction about using the Dwarf Fortress directory, preventing it from writing to, or may accessing at all, dfhack-config/orders.
Unknown if this is hard-coded against C:\Program Files*, or is due to restricted privileges forced on a browser app.
At any rate, I'm uncomfortable writing to arbitrary filenames or even arbitrary paths.
Should DFHack start using AppData/Roaming/Bay12 Games/Dwarf Fortress/dfhack-config, perhaps?
Or make its own directory Appdata/Roaming/DFHack ?
Then choose whether to use that directory or the current one based on the prefs/portable.txt file?
What other external tools are there that interact with DFHack bt reading/writing DFHack files? Not Dwarf Therapist. Not really Remote Fortress Reader based tools, those use TCP/IP.
Speaking of TCP/IP, perhaps this web app could use the existing protobuf-over-TCP/IP to interact with DFHack.
I was able to make this command-line work:
start dfhack-run "workorder" "{\"amount_total\" : 5, \"job\" : \"MakeAsh\", \"workshop_id\" : 1011 }"
That created a new 'make ash 5/5' workorder for that specific wood furnace.
If the web app can use protobufs and connect to localhost, this seems a viable route for creating new work orders. It's perhaps less viable for getting a JSON list of existing work orders.
Unfortunately, writing to %AppData% wont work either as its in the list of the restricted paths (see https://print3m.github.io/blog/filejacking-initial-access-with-file-system-api).
The goal is to fully manage work orders, and ultimately automate it even more through the app, so just creating orders is indeed not viable.
That TCP approach is interesting as I'd like a cleaner solution than having the game and the app constantly poking an intermediate file. However that would actually face even more security restrictions as a web site cannot just poke around the client's local open ports.
Im unsure whether there's a better way for a browser to communicate with the game than through that file.
Alternatively, the application could be made a standalone (so free file access), but with the caveat it would only run on one OS (Windows), and with much more design/layout constraints - and Im a web dev so Im not really interested in going that way.
Should DFHack start using
AppData/Roaming/Bay12 Games/Dwarf Fortress/dfhack-config, perhaps? Or make its own directoryAppdata/Roaming/DFHack? Then choose whether to use that directory or the current one based on theprefs/portable.txtfile?
Addressing this issue is on my (so-far private) roadmap. However, a complete solution for this issue is complicated as code that interacts with the file system in ways that this affects is currently diffused throughout the code base and so a proper solution is going to require a full survey to find all such uses, develop and implement a replacement API that can handle all the known use cases, and convert existing uses to the new API. I have yet to have the mental bandwidth for this, and to be honest probably won't until after the holidays. In any case I'd rather move on this issue with deliberation instead of implementing half measures repeatedly.
As to the underlying issue, I would recommend that the OP investigate using DFHack's remote command interface instead of using "file drops" for RPC, and this would entirely avoid the problem of finding a "safe" place on the local file system to write temporary files.
Another option might be to restructure the "web" app as an Electron app, which would give broader access to the local environment than what one gets as a sandboxed web app while having the same basic structure. Basically what I'm seeing here is a fairly severe case of "I have a hammer, and thus everything looks like a nail"...
I have a hammer thus everything looks like a nail
Well I cant deny it, though pretty severe might be a bit hard. DFHack offers a JSON file import/export feature, and with a web app I can make a proper interface to edit that in a in a form directly shareable to anyone - that does not sound like that much of a stretch.
That being said this issue is more of a limitation on the side of the browser's new file access system than a shortcoming on DFHack's side. It's very nice to be able to keep a file open for read/write operations, but then they restrict access to pretty much any folder a regular user would put his files into - desktop, user, appdata, programs... welp.
Anyways, good suggestion on using Electron, might be the wiser move for now.