Dfterm3+Dwarf Fortress on Linux causes 100% cpu utilization

[Noeda]

Additionally, Dfhack console cannot be used.

This is caused by Dfterm3 and Dfhack trying to use the same terminal and things going awry.

[Noeda]

Launching Fortresses works now but not entirely without problems. I'm keeping the issue open until it fully works.
6caa284

[Ramblurr]

Does this mean dfterm3 won't work on Linux as of now? I don't want to go through the trouble of setting up a haskell platform env (distro repos are out of date) if its not even gonna work :\

[Noeda]

It works but there is a CPU burn problem.

At the moment, the Dfhack console tries to use the same terminal as Dfterm3 and goes crazy. This causes 100% cpu utilization. Otherwise, it works completely, as far as I know.

[Ramblurr]

Any plans or ideas on how to make dfterm3 use a separate console?

Hm, perhaps dfterm's plugin should actually communicate with a dfterm in a separate process communicating over the protobuf rpc server.

[Noeda]

I've tried internally creating pseudo-terminal for Dwarf Fortress where Dfhack could run (it would have its own terminal) but then DF freezes for some reason at start up.

One solution I've thought is to modify Dfhack itself to be more flexible about where it will have its console. At the moment I'm not working on this because few people have shown real interest on using this on Linux. I'll work on this when I have time.

[Ramblurr]

Ah, interesting. I would have figured Linux installs would be more popular. I'm in the process of setting up a remote dfterm server, on linux obviously.

[lethosor]

From what I can tell, DFHack on Linux uses a custom input system, which causes it to run out of control when it's not reading directly from a terminal (the same is true on OS X; Windows doesn't have this problem because it uses a custom DLL to open the DFHack window when DF launches, independent from a normal terminal).
A workaround I've found on OS X is using open - passing it the path to the dfhack executable causes it to open in a new terminal window. xdg-open appears to do the same thing on Linux, but it could vary on different systems – different environments could use gnome-open, kde-open, and exo-open.

[satelliteoflove]

Noeda, first of all THANK YOU for all you do - it is greatly appreciated. I was wondering if there was any more work being done to get the Linux port working? Running dfterm on a Linux VPS is something my friends and I would very much enjoy. Currently (for me) dfterm and dfhack will compile from your git repositories, and dfhack runs just fine, but dfterm won't connect to it.

Edit: I have been able to get dfterm working on a headless linux server. Essentially, to get the dfterm3 plugin to load dfhack must be given a terminal. However, if you start df in TEXT mode (necessary for an ssh session), dfhack doesn't load properly as it gets clobbered by df and has no interactive console. The trick is to switch back to 2D mode, and to use Xvfb to create a virtual framebuffer device. Then when you start dfhack, the df window goes to the virtual fb, and dfhack's interactive console gets the terminal. Run the dfterm3 executable in a separate terminal (I use screen to manage the different running applications), and it should now connect to dfhack properly when you issue the "start-dfterm3" command. I've noticed no problems whatsoever with CPU consumption or connections, though it doesn't appear that dfhack is loading everything in my dfhack.ini just right.

To implement this on my headless OpenSUSE server, I installed the xorg-x11-server package (just the most basic stuff to get the Xvfb), then put the following lines at the top of my dfhack:

Xvfb :1 -screen 0 1024x768x16 &
export DISPLAY=:1

You could probably add "/path/to/dfterm3 --daemon" to this, to get it all rolled into one script.

[lethosor]

Hopefully I can get a Linux system set up this week to test on. From what I can tell, dfterm3 works on Linux, but the plugin isn't as well-supported yet (and it's kind of buggy). I'm also trying to get it to work on OS X, since it's pretty similar (and has the same bugs). The main issue at this point, as mentioned above, is that DFHack runs in a standard terminal on OS X/Linux but doesn't use standard I/O, so running it from another process causes problems.

[satelliteoflove]

Just an FYI, after more testing I can say that though dfterm/dfhack work under Linux, they aren't without bugs. Most notable for my VPS is that occasionally the dfterm web interface becomes unresponsive. Dfhack can still be interacted with from the terminal, but not much else works. I have to kill dfhack ("die") and restart it to get the web interface working again. This seems to be intermittent - I'm still trying to peg down what causes the interface to hang. I can say for certain that when it hangs, CPU usage is higher than usual.

[lethosor]

I've implemented a solution for the CPU usage problems (assuming they were due to the infinite loop in the DFHack console) in lethosor/dfhack@c2deaf0. ./dfhack & can now be run with reasonable CPU usage.