Topic: PyLNP 0.14e-pre1 - Cross-platform launcher with graphics pack patching (Read 325990 times)

Pidgeot · « **Reply #150 on:** October 23, 2014, 07:54:07 am »

Quote from: kahrkunne on October 23, 2014, 07:23:16 am

I'm probably just really stupid, but how do I use this?
I have no idea what I'm doing, and the readme isn't really helping either.
Dowloaded the source code, but trying to run it just gives me this error

kahr[python-lnp]>./launch.py
WARNING: LNP folder is missing!
Traceback (most recent call last):
File "./launch.py", line 11, in <module>
lnp.PyLNP()
File "./core/lnp.py", line 66, in __init__
self.userconfig = JSONConfiguration('PyLNP.user')
File "./core/json_config.py", line 21, in __init__
self.data = json.load(open(filename), encoding='utf-8')
File "/usr/lib/python3.4/json/__init__.py", line 268, in load
parse_constant=parse_constant, object_pairs_hook=object_pairs_hook, **kw)
File "/usr/lib/python3.4/json/__init__.py", line 318, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.4/json/decoder.py", line 343, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.4/json/decoder.py", line 361, in raw_decode
raise ValueError(errmsg("Expecting value", s, err.value)) from None
ValueError: Expecting value: line 1 column 1 (char 0)

That error message is a bug - I've fixed that now, so please re-download the source code and try again. (It will still display a message on the first run, but it is harmless, and the program will simply continue).

If that doesn't fix it for you - I don't know how to explain it better than it is in the latest README, so you'll have to tell me what part of it you're not understanding.

kahrkunne · « **Reply #151 on:** October 23, 2014, 09:17:11 am »

I think I understand how things work now.
I'll retry using the source code later, but I'm trying to get the premade binary to work right now.
Trying to run it with bash 4.3, it prints out "/bin/sh: symbol lookup error: /bin/sh: undefined symbol: rl_signal_event_hook" when pressing the "start dwarf fortress!" button. Using bash 4.2 it doesn't do this, but instead says "xdg-terminal: configured terminal program 'rxvt-unicode-256color' not found or not executable". It does the same thing when launched for xterm (except substitute rxvt-unicode-256color with xterm).

Pidgeot · « **Reply #152 on:** October 23, 2014, 09:24:57 am »

That means the xdg-terminal script couldn't figure out how to launch a terminal, which is necessary for DFHack to work.

I have no way of fixing that without a lot more information about your Linux installation (distribution, desktop environment, terminal emulator used, etc.), since I need to get a similar setup running to test.

kahrkunne · « **Reply #153 on:** October 23, 2014, 09:35:26 am »

Damn. Can you do something about it not working with bash 4.3 though? The lastest version of bash 4.2 I could find was from august 2013, and there's been a serious bash vulnerability (shellshock I believe it was called) since then, so I don't really want to run an outdated version of bash.

I'll give you some info about my setup:
Distro: Arch Linux
DE: None, running i3wm
Terminal emulator used: Rxvt-unicode-256color, but also occurs with xterm (and probably with others as well)
Output of uname -a: Linux K-02 3.16.4-1-ARCH #1 SMP PREEMPT Mon Oct 6 08:22:27 CEST 2014 x86_64 GNU/Linux

You need anything else? Also you know of some hotfix I can apply where I can just hardcode a specific terminal?

EDIT: Okay, it works with bash 4.3 if I create my own excecutable from the source code.
Pressing "Play dwarf fortress!" however prints out the following:

Spoiler (click to show/hide)

As you can see, very similar to the earlier output.
I've tracked down the error to this bit of code in core/launcher.py:

Spoiler (click to show/hide)

run_program(os.path.join(paths.get('df'), 'dfhack'), force, True, True) appears to return False

Pidgeot · « **Reply #154 on:** October 23, 2014, 10:02:28 am »

Quote from: kahrkunne on October 23, 2014, 09:35:26 am

Damn. Can you do something about it not working with bash 4.3 though? The lastest version of bash 4.2 I could find was from august 2013, and there's been a serious bash vulnerability (shellshock I believe it was called) since then, so I don't really want to run an outdated version of bash.

A bit of googling suggests this may be related to old versions of the Readline library.

Note that even 4.2 has received patches against shellshock, so it's not *that* much of a concern, so long as you are running the latest build.

Quote from: kahrkunne on October 23, 2014, 09:35:26 am

I'll give you some info about my setup:
Distro: Arch Linux
DE: None, running i3wm
Terminal emulator used: Rxvt-unicode-256color, but also occurs with xterm (and probably with others as well)
Output of uname -a: Linux K-02 3.16.4-1-ARCH #1 SMP PREEMPT Mon Oct 6 08:22:27 CEST 2014 x86_64 GNU/Linux

You need anything else? Also you know of some hotfix I can apply where I can just hardcode a specific terminal?

Near the bottom of xdg-terminal is a line:

Code: [Select]

case "$DE" in
Please add

Code: [Select]

echo DE is $DE just before this and tell me what that adds to the output.

If it says "DE is generic" (I expect it will), then it uses a fallback, which you can try to apply: $TERM needs to point to the name of the terminal emulator, and "which $TERM" must give you the path of that terminal emulator's executable. If $TERM is not set, it will try xterm as a further fallback.

The only alternative to changing your configuration is to modify the script to let it know how to handle your system - which is generally going to mean detecting i3wm, and figuring out how to launch a terminal. I cannot find any information on how to do this, and thus it is highly unlikely I can fix it myself - but if you know enough to come up with something, I'd be happy to hear it.

By the way, this is going to be a problem for *all* graphical launchers for you; DFHack *needs* to be spawned with exclusive access to a terminal in order to behave correctly, and there is no cross-distro way of doing this (xdg-terminal is the closest equivalent I've been able to find, which really just works on a case-by-case basis - and even then, I've had to hack in MATE support). I've documented most of my efforts with this here in the thread; see page 4-6.

kahrkunne · « **Reply #155 on:** October 23, 2014, 10:06:34 am »

where is xdg-terminal supposed to be? 'locate xdg-terminal' doesn't give any results.
EDIT: nvm found it
Output is

Spoiler (click to show/hide)

I see no reason why it wouldn't at least launch an xterm. After all, xterm is install on my system

EDIT: changed that bit to say:

Spoiler (click to show/hide)

That seems to have fixed it, but now it gives me the following:

Not found: data/art/ironhand16.png

The file is there, in df_linux/data/art/ironhand16.png
How do I fix this?

EDIT: issue occurs even when using the default ascii graphics, albeit with a different filename

Pidgeot · « **Reply #156 on:** October 23, 2014, 10:12:52 am »

What does "which xterm" give you?

EDIT: Yeah, that would indicate urxvt is at least installed. At least that's running.

kahrkunne · « **Reply #157 on:** October 23, 2014, 10:29:23 am »

Any idea what might be causing the Not found: error?
If needed I can put my entire installation on github or something

Pidgeot · « **Reply #158 on:** October 23, 2014, 10:36:34 am »

Quote from: kahrkunne on October 23, 2014, 10:06:34 am

Not found: data/art/ironhand16.png

The file is there, in df_linux/data/art/ironhand16.png
How do I fix this?

Well, that would suggest that DF doesn't have the right working directory - but I explicitly set that on launch, and it works on the Linux systems I have available for testing.

If it works when you launch DF directly, then that would indicate urxvt is messing with the working directory somehow, but it shouldn't. If that doesn't work either, something would be even more wrong, and I couldn't tell you what.

On a related note: re-reading the script, it looks like the generic fallback wouldn't actually ever work, but it should be fixed now. Maybe it'll work for you now, and magically fix the oter issue.

kahrkunne · « **Reply #159 on:** October 23, 2014, 10:45:33 am »

Quote from: Pidgeot on October 23, 2014, 10:36:34 am

Quote from: kahrkunne on October 23, 2014, 10:06:34 am
Not found: data/art/ironhand16.png

The file is there, in df_linux/data/art/ironhand16.png
How do I fix this?

Well, that would suggest that DF doesn't have the right working directory - but I explicitly set that on launch, and it works on the Linux systems I have available for testing.

If it works when you launch DF directly, then that would indicate urxvt is messing with the working directory somehow, but it shouldn't. If that doesn't work either, something would be even more wrong, and I couldn't tell you what.

On a related note: re-reading the script, it looks like the generic fallback wouldn't actually ever work, but it should be fixed now. Maybe it'll work for you now, and magically fix the oter issue.

Ok so first of all:
My directory structure looks like this: http://pastebin.com/nBjFM3q6
Is that correct?
Second, it does not work when I run df directly, even though all the files are there. The terminal output is:

Spoiler (click to show/hide)

Part of that is something related to gtk themes that's probably not relevant to this

Pidgeot · « **Reply #160 on:** October 23, 2014, 10:59:37 am »

Quote from: kahrkunne on October 23, 2014, 10:45:33 am

Ok so first of all:
My directory structure looks like this: http://pastebin.com/nBjFM3q6
Is that correct?

Directory-wise, yes, but the file you mentioned (ironhand16.png) is indeed not where it should be (df_linux/data/art). If that's because you switched graphics sets, fine, otherwise that would seem to be the issue.

All I can say is that apart from the xdg-terminal stuff, it doesn't seem to be a PyLNP issue. You might have more luck asking in the general forum; I don't play DF on Linux myself, so I'm probably not the best person to help with DF issues.

kahrkunne · « **Reply #161 on:** October 23, 2014, 11:01:06 am »

Quote from: Pidgeot on October 23, 2014, 10:59:37 am

Quote from: kahrkunne on October 23, 2014, 10:45:33 am
Ok so first of all:
My directory structure looks like this: http://pastebin.com/nBjFM3q6
Is that correct?
Quote
Directory-wise, yes, but the file you mentioned (ironhand16.png) is indeed not where it should be (df_linux/data/art). If that's because you switched graphics sets, fine, otherwise that would seem to be the issue.

All I can say is that apart from the xdg-terminal stuff, it doesn't seem to be a PyLNP issue. You might have more luck asking in the general forum; I don't play DF on Linux myself, so I'm probably not the best person to help with DF issues.
Yeah I switched to the default graphics set to see if that'd work, but it didn't.
When I used ironhand all files were in the correct locations.

kahrkunne · « **Reply #162 on:** October 23, 2014, 11:18:08 am »

Fixed it with the instructions from http://www.bay12games.com/dwarves/mantisbt/view.php?id=2688
This does mean I have to manually edit init.txt every time I change graphics, but oh well.
EDIT: nevermind, it wasn't that easy. This breaks as soon as I install a graphics pack.
EDIT2: Okay, I know a way to fix it. I've found an alternative libz.so that makes it work, so doing LD_PRELOAD=path/to/libz.so ./df makes it work. How do I intergrate this with PyNLP? Like, what exactly is run when I press 'Play Dwarf Fortress!'?

kahrkunne · « **Reply #163 on:** October 23, 2014, 11:47:18 am »

Ok, so in your avrage use case, what does os.path.join(paths.get('df'), 'df') return?

Pidgeot · « **Reply #164 on:** October 23, 2014, 11:48:19 am »

Quote from: kahrkunne on October 23, 2014, 11:18:08 am

EDIT2: Okay, I know a way to fix it. I've found an alternative libz.so that makes it work, so doing LD_PRELOAD=path/to/libz.so ./df makes it work. How do I intergrate this with PyNLP? Like, what exactly is run when I press 'Play Dwarf Fortress!'?

It will ultimately run either the df script or the dfhack script in the Dwarf Fortress folder (depending on whether DFHack is enabled or not), so I would suggest editing those scripts.

In df, add LD_PRELOAD=path/to/libz.so in front of ./libs/Dwarf_Fortress

If dfhack, find the line PRELOAD_LIB=./hack/libdfhack.so and change it to PRELOAD_LIB="./hack/libdfhack.so path/to/libz.so" (including the quotes).

Quote from: kahrkunne on October 23, 2014, 11:47:18 am

Ok, so in your avrage use case, what does os.path.join(paths.get('df'), 'df') return?

It returns <DF folder>/df.

News:

Author Topic: PyLNP 0.14e-pre1 - Cross-platform launcher with graphics pack patching (Read 325990 times)

Pidgeot

Re: PyLNP 0.6 - Cross-platform Lazy Newb Pack port with graphics pack patching

kahrkunne

Re: PyLNP 0.6 - Cross-platform Lazy Newb Pack port with graphics pack patching

Pidgeot

Re: PyLNP 0.6 - Cross-platform Lazy Newb Pack port with graphics pack patching

kahrkunne

Re: PyLNP 0.6 - Cross-platform Lazy Newb Pack port with graphics pack patching

Pidgeot

Re: PyLNP 0.6 - Cross-platform Lazy Newb Pack port with graphics pack patching

kahrkunne

Re: PyLNP 0.6 - Cross-platform Lazy Newb Pack port with graphics pack patching

Pidgeot

Re: PyLNP 0.6 - Cross-platform Lazy Newb Pack port with graphics pack patching

kahrkunne

Re: PyLNP 0.6 - Cross-platform Lazy Newb Pack port with graphics pack patching

Pidgeot

Re: PyLNP 0.6 - Cross-platform Lazy Newb Pack port with graphics pack patching

kahrkunne

Re: PyLNP 0.6 - Cross-platform Lazy Newb Pack port with graphics pack patching

Pidgeot

Re: PyLNP 0.6 - Cross-platform Lazy Newb Pack port with graphics pack patching

kahrkunne

Re: PyLNP 0.6 - Cross-platform Lazy Newb Pack port with graphics pack patching

kahrkunne

Re: PyLNP 0.6 - Cross-platform Lazy Newb Pack port with graphics pack patching

kahrkunne

Re: PyLNP 0.6 - Cross-platform Lazy Newb Pack port with graphics pack patching

Pidgeot

Re: PyLNP 0.6 - Cross-platform Lazy Newb Pack port with graphics pack patching