March 6, 2024: Dwarf Fortress 50.12 has been released.
News: February 3, 2024: The February '24 Report is up.
News: February 4, 2021: Dwarf Fortress Talk #28 has been posted.
News: November 21, 2018: A new Threetoe story has been posted.
Forum Guidelines
I don't intend to rely on TwbT, for this and the perf/correctness issues noted above. (I'd prefer a flexible declarative mini language which takes newly released raws and emits the pack)
No obvious solution, but I'm still thinking about it.
Summarising: updating graphics packs is harder than it sounds, especially in a timely manner. Collaboration is also tricky, and nobody likes it when things break.I feel as if this is addressing a different issue. Maybe something related to TWBT? I'm not familiar with DFhack. In any case, I'm positive you know that more graphic support isn't going to fix disorganization and lack of maintenance by set authors when updating to the latest version. Heh.
Hard problems remain hard. TwbT is promising, but faces performance and correctness issues when used very intensively (see: Gemset). However if we could eg stop using "tileset magic" and replace it with TwbT, the remaining required changes to the raws might be much simpler and thus easier to collaborate on and/or automate.
Basically I'd like tilesets to be completely raw-independent again, and creature graphics as independent as practical. I may set up a graphics project aimed at this, if Fricy doesn't get to it first...
For reference: I do now have my computer back and all that, but there are a few more things I need to take care of before I can really start looking at PyLNP again. I currently expect to get started again sometime next week.Looking forward to this - it would be great if you could provide a better build of the tag above ASAP.
from tkinter import *
from ttk import *
Unfortunately, I'm not familiar with shell scripting and couldn't tell you. The problem introduced by Openbox is that it doesn't really have a default terminal emulator, so whatever is put in the script is, at best, an educated guess at what a user might have.
The issue is that the script doesn't work on systems where /bin/sh is dash or zsh (and it was bundled in PyLNP, although I think you said that was unintentional).
Using openbox and zsh; I would imagine that it's the real root of the matter. Does the script have a specification for Openbox?
4) Making DFHack behave
First, leave the libs folder, get back to our hypothetical lnp/ folder, and run LNP:Code: [Select]cd ../..By now, you should be able to actually execute the df_linux/df executable and have it work. You should even be able to modify some settings in LNP, close it, and execute the df file and play normally. However, the "Play Dwarf Fortress" button in LNP will not work. We can fix that (hopefully). In the launcher, go to File>Configure Terminal and enter "xterm" (assuming you have xterm installed). You can modify this to work with your favorite terminal, for example, using MATE's terminal requires the usage of "mate-terminal -e $" in the field. Xterm seems to be the only one that works without any usage of -e or $. You should now be able to launch DF and DFHack from the "Play Dwarf Fortress" button.
./startlnp
I have implemented a small python script to fix the "unexpected operator" error without freezing PyLNP on launch.
Just download and follow the instructions here: https://github.com/jokaro/run-dwarf-fortress-script
An updated launcher is now available for those who want to use 0.42.01 with this pack (PyLNP_0.10c-win32.zip).Should I be awaiting the Linux and MacOX versions with bated breath, or are they going to take a while longer? (Honestly, I'm highly impressed that ANY version of the pack has been updated yet, even if it's for the system I don't have access to; I've been going under the assumtion that when I'm finally able to try the new version this weekend, I'll need to do so pure Vanilla. So please don't take this as a nag/complaint. Thanks for all your hard work!)
