Print

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

[Pidgeot]

I was a little confused. You mention copying the source, I assume that running 'launch.py' in what I then need to run, then you mention it would behave like the binary, that confused me

What I meant was "the binary doesn't do anything the source code doesn't do". It's provided as a convenience for people who don't have the right libraries and such installed.

but I just discovered the existence of that binary, downloading the launcher from bitbucket (not cloning the source), tried that as well. Both give me a different problem. With the source code and binary, things  look fine, the program identifies the utilities, knowns where the df folder is etc, so all seems to work. However launching gives different errors with both python 2.7 and 3 and the binary. Python3 talks about a type error for 's' in program_is_running, 2.7 talks about something with an unsupported buffer also citing various lines, the binary results in:

Code: [Select]

/bin/sh: symbol lookup error: /bin/sh: undefined symbol: rl_signal_event_hook You can find the full trace from python as well below, however I get the feeling I might be messing up somehow.

If it's any consolation, it doesn't look like you're doing anything wrong.

Python2.7

Spoiler (click to show/hide)

Code: [Select]

Traceback (most recent call last):
  File "core/launcher.py", line 102, in run_program
    retcode = subprocess.call(term + [path], cwd=workdir)
  File "/usr/lib/python2.7/subprocess.py", line 522, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1486, in __call__
    return self.func(*args)
  File "core/launcher.py", line 51, in run_df
    raise Exception('Failed to run Dwarf Fortress.')
Exception: Failed to run Dwarf Fortress.


[/quote]
Oddly, it works on some systems, but I am indeed seeing one of my VMs complain here. Will try to figure out why.

Python3

Spoiler (click to show/hide)

Code: [Select]

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.4/tkinter/__init__.py", line 1533, in __call__
    return self.func(*args)
  File "/home/alexander/Dwarf Fortress/core/launcher.py", line 49, in run_df
    result = run_program(executable, force, True, spawn_terminal)
  File "/home/alexander/Dwarf Fortress/core/launcher.py", line 92, in run_program
    is_running = program_is_running(path, check_nonchild)
  File "/home/alexander/Dwarf Fortress/core/launcher.py", line 132, in program_is_running
    return path in s
TypeError: Type str doesn't support the buffer API


I thought I'd fixed that one... will get it sorted.

Anyway, I just posted a new binary built with the updated Python2 moments ago, so I would suggest trying that for the time being.

Should I maybe contact you in private or find you in some irc channel? I'm beginning to feel I'm spamming the this thread with information that'll only benefit me.

Should be fine, I think I got all the info I need anyway.

EDIT: Both of those bugs should be fixed now.

[rangi]

Thank you for maintaining this starter pack.

With newest starter pack (40.15), I got following error when click 'Play Dwarf Fortress' button, no program is started.

Code: [Select]

$ ./startlnp
Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/michael/Desktop/df/python_lnp/build/lnp/out00-PYZ.pyz/Tkinter", line 1473, in __call__
  File "/home/michael/Desktop/df/python_lnp/build/lnp/out00-PYZ.pyz/core.launcher", line 35, in run_df
  File "/home/michael/Desktop/df/python_lnp/build/lnp/out00-PYZ.pyz/core.launcher", line 68, in run_program
  File "/home/michael/Desktop/df/python_lnp/build/lnp/out00-PYZ.pyz/core.launcher", line 109, in check_program_not_running
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 10913: ordinal not in range(128)

My OS is Ubuntu 14.04

[Ucarty]

Python2.7

Spoiler (click to show/hide)

Code: [Select]

Traceback (most recent call last):
  File "core/launcher.py", line 102, in run_program
    retcode = subprocess.call(term + [path], cwd=workdir)
  File "/usr/lib/python2.7/subprocess.py", line 522, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1486, in __call__
    return self.func(*args)
  File "core/launcher.py", line 51, in run_df
    raise Exception('Failed to run Dwarf Fortress.')
Exception: Failed to run Dwarf Fortress.


Oddly, it works on some systems, but I am indeed seeing one of my VMs complain here. Will try to figure out why.

Python3

Spoiler (click to show/hide)

Code: [Select]

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.4/tkinter/__init__.py", line 1533, in __call__
    return self.func(*args)
  File "/home/alexander/Dwarf Fortress/core/launcher.py", line 49, in run_df
    result = run_program(executable, force, True, spawn_terminal)
  File "/home/alexander/Dwarf Fortress/core/launcher.py", line 92, in run_program
    is_running = program_is_running(path, check_nonchild)
  File "/home/alexander/Dwarf Fortress/core/launcher.py", line 132, in program_is_running
    return path in s
TypeError: Type str doesn't support the buffer API


I thought I'd fixed that one... will get it sorted.

Anyway, I just posted a new binary built with the updated Python2 moments ago, so I would suggest trying that for the time being.

EDIT: Both of those bugs should be fixed now.

Well that was really fast! Python2.7 and Python3 now both work for me! So thanks for fixing it so quick.

The PyLNP binary (.8a) doesn't manage to launch df, and doesn't give me anything stdout/err either. So I'm not sure what's happening there. Let me know if you want me to do something and pursue this.

[Ucarty]

This message is for other Arch users trying to get LNP to work.

The pack works but Archers face some other problems.

libpng
fixed this by copying the libgpng link from the official arch package that links to our libpng that works fine, but df fails to find/use it. You can fix this yourself by creating a link named libpng.so.3 and linking it to /usr/lib32/libpng32.so.

libgcc/libg++
Seen this before, noticed the official package doesn't have them in the libs folder. Simply removed them, and that solved my issues.

using an uncommon terminal (rxvt in my case)
This breaks the xdg-terminal script that seems to make sure your terminal does things df needs. I tried messing with it, failed to get anything useful done. I'm simply using xterm to launch the PyLNP launcher now.

Hope this helps!

[Beautato]

This message is for other Arch users trying to get LNP to work.

The pack works but Archers face some other problems.

libpng
fixed this by copying the libgpng link from the official arch package that links to our libpng that works fine, but df fails to find/use it. You can fix this yourself by creating a link named libpng.so.3 and linking it to /usr/lib32/libpng32.so.

libgcc/libg++
Seen this before, noticed the official package doesn't have them in the libs folder. Simply removed them, and that solved my issues.

using an uncommon terminal (rxvt in my case)
This breaks the xdg-terminal script that seems to make sure your terminal does things df needs. I tried messing with it, failed to get anything useful done. I'm simply using xterm to launch the PyLNP launcher now.

Hope this helps!

Thank you very much for these helpful tips.

>  libpng
I think by default df is looking for libpng12-0:i686 or libpng.i686.

> libstdc++.so.6

I delete this to get it to work with debian, these both are really something that a script should detect on first run and make a symbolic links instead of shipping separate packages for different versions. However, DF updates too quickly to keep a script always up-to-date with all the changes that are happening between the utilities. perhaps PyLNP can work in some sort of fix, but as of right now i recommend deleting "libstdc++.so.6" and your libpng32.so link are the best working solutions.

Thank you again, I do not test on arch, but your suggestions and fixes are super useful. I am going to put your suggestions into the wiki on the project repo.

[Beautato]

PyLNP Interface x64 Linux Lazy Newb Pack 0.40.16 R1

Release for Dwarf Fortress v0.40.16.r1

Pidgeot's PyLNP 0.8b Lazy Newb Pack Python interface
Uses Dwarf Fortress Linux 0.40.16
Compiled with x64 architecture
gcc 4.5.4 compiled DFhack
Dwarf Therapist v28 compiled with QT 5 with memory layouts 0.28.181 - 0.40.16

You can download it here: http://dffd.wimbli.com/file.php?id=8936

I am going to update the website now, since its nearly 2 versions behind. Then I will be adding additional releases for varying architectures and  versions of gcc/qt, and a faster link on the website later tonight.

[TV4Fun]

DFHack does not seem to work with the new version. When enabled, DF immediately closes after opening. Is anyone else having this issue?

[Pidgeot]

DFHack does not seem to work with the new version. When enabled, DF immediately closes after opening. Is anyone else having this issue?

Does it work if you launch DFHack manually through a terminal?

[int_ua]

Notice: stonesense now works again on linux.

[lethosor]

Is there a reason that libstdc++.so.6 is renamed to libstdc++.so.6.bak? DFHack built with GCC 4.5 requires that file, so renaming it would explain why DFHack doesn't work (unless GCC 4.5 happens to be installed, which is very unlikely on modern systems).
Edit: There's also a report of DFHack in the "x64 LNP DF v0.40.16 (DFhack GCC 4.5.4) (QT5 DT)" build requiring CXXABI_1.3.8, which corresponds to GCC 4.9. Are you sure that you didn't distribute a GCC 4.9 build of DFHack?

[ZEbbEDY]

on arch64 and getting error when trying to launch

was there a fix for this i tried reading thread but didnt see anything

$ ./startlnp
/bin/sh: symbol lookup error: /bin/sh: undefined symbol: rl_signal_event_hook

[rmblr]

FYI the 40.16 version works on Fedora 20, but like last time I had to compile my own libgraphics.so (from svenstaro's repo) and replace the existing one in df_linux/libs/

[chamber]

I just tried running LNP v0.40.16r1.p454 on Ubuntu 14.04 (64-bit). The startlnp script brings up a GUI successfully, but when I click "Play Dwarf Fortress!", a window comes up for a fraction of a second and then vanishes while this gets added to my console:

/tmp/_MEILKY386/xdg-terminal: 364: [: x/home/dave/.local/share/Trash/files/lnp.3/df_linux/dfhack: unexpected operator
/tmp/_MEILKY386/xdg-terminal: 367: [: x-x: unexpected operator
nohup: redirecting stderr to stdout

This is different from the "unexpected operator" error on page 1 of this discussion, and the change to startlnp that apparently fixed that issue doesn't work here and for this LNP version. The temp file in the error message doesn't exist, so I can't report on its contents.

Any idea what's wrong? This is happening for both the QT4 and QT5 versions. I'm confident I have all the dependencies.

[holiday_hawk]

I can't get the LNP to launch Dwarf Fortress. When I hit the play Dwarf Fortress button, a terminal window will pop up, and instantly disappear. I can launch DF through the terminal window myself, but it will not launch from the LNP. Any ideas why? 

Edit: I should also add that 40.15 would launch perfectly.

[rmblr]

I can't get the LNP to launch Dwarf Fortress. When I hit the play Dwarf Fortress button, a terminal window will pop up, and instantly disappear. I can launch DF through the terminal window myself, but it will not launch from the LNP. Any ideas why? 

Edit: I should also add that 40.15 would launch perfectly.

Do you have dfhack enabled? If so, does dfhack start DF from the terminal (cd DF_DIR, ./dfhack)