Print

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

[PatrikLundell]

The tool seems to have problems with special/national characters in the path (encountered while looking at DF script issues).
The original path: "D:\Games\Dwarf Fortress\Dwarf Fortress 44_12 Starter Pack r05\Starter Pack Launcher (PyLNP).exe"
was changed to
"D:\Gämes\Dwarf Fortress\Dwarf Fortress 44_12 Starter Pack r05\Starter Pack Launcher (PyLNP).exe" by
renaming the "Games" folder to "Gämes". After the renaming, the LNP launcher failed to start, while a change to "Gemes" caused no problems.

[Pidgeot]

As a heads up, I am investigating certain changes to PyLNP development in the near future:

• Bitbucket is removing support for Mercurial repositories in 2020. As PyLNP is using a Mercurial repository, this means it'll have to move. There is already a mirror on GitHub, so I expect to simply switch over to using that as the primary repository, but I have some backend processes that I will need to update first. I'll move over existing issue reports once I'm ready to make the switch.
• With Python 2 approaching end-of-life, I'll be looking into moving all executables to be Python 3-based. The exact details here aren't finalized yet, so I can't say precisely which Python 3 version will be required - it depends on what I'm able to build executables with. Some time after that, the codebase will probably no longer target Python 2 support anymore - it'll probably stay working for a while, in case you want to run from source, but there won't be any guarantees. I'll post more details when I'm able.

The tool seems to have problems with special/national characters in the path (encountered while looking at DF script issues).
The original path: "D:\Games\Dwarf Fortress\Dwarf Fortress 44_12 Starter Pack r05\Starter Pack Launcher (PyLNP).exe"
was changed to
"D:\Gämes\Dwarf Fortress\Dwarf Fortress 44_12 Starter Pack r05\Starter Pack Launcher (PyLNP).exe" by
renaming the "Games" folder to "Gämes". After the renaming, the LNP launcher failed to start, while a change to "Gemes" caused no problems.

Yes, this is a known issue due to the executable being built as a Python 2 program (which does not have full Unicode compatibility). Any accented or non-English characters in the path will make the built version fail.

It should get fixed once I am able to build it as a Python 3 program - this hasn't been possible earlier due to issues with the tooling used to generate the executable.

I did do some basic tests recently which suggests those issues *might* not be a problem anymore, but I'll need to do a bit more testing to make sure it'll all work correctly (and coordinate it with the things I listed above).

[Matador]

Hi. The program crashes when trying to change graphics in Windows 10, 0.44.12-r08

stderr.txt says:

Code: [Select]

ERROR: Something went wrong while installing graphics
I have tried also with 0.43 builds, and same problem.

Thanks for the help.

[Pidgeot]

Sorry for the late reply.

Can you please specify exactly which graphics pack you're trying to install? Is it a specific pack causing this or any of them?

Also, if you're able to do so, please try to launch PyLNP with the parameter "-d" to turn on extra debug information. Post the contents of both stdout.txt and stderr.txt if you are able to do this.

[Aptann]

Sorry for the late reply.

Can you please specify exactly which graphics pack you're trying to install? Is it a specific pack causing this or any of them?

Also, if you're able to do so, please try to launch PyLNP with the parameter "-d" to turn on extra debug information. Post the contents of both stdout.txt and stderr.txt if you are able to do this.

I'm having the same issue. It doesn't matter which graphics pack is installed. I couldn't find any stdout logs, but here's the stderr logs:

Code: [Select]

Running PyLNP 0.13b (OS: win, Compiled: True)
WARNING: JSONConfiguration: File PyLNP.user does not exist
INFO: Installing extras content for first time
DEBUG: dfhack_PyLNP.init not found.
DEBUG: onLoad_PyLNP.init not found.
INFO: Read installed graphics (Phoebus) from log
DEBUG: dfhack_PyLNP.init not found.
DEBUG: onLoad_PyLNP.init not found.
ERROR: Something went wrong while installing graphics


[Taras]

How download this for Villains Update?

[lethosor]

PyLNP is just the launcher GUI - it will theoretically work with any DF version. There are several packs that use it in this board, but none of them have updated to 0.47.01 yet.

[jecowa]

I think the "Customize" menu of the "Graphics" menu is confusing. Having two tileset selection menus makes it look like you can have two, but that's only possible if you are using TWBT. Imo, one of the two tileset selection menus should be grayed-out unless the text mode is set to TWBT. Otherwise, if graphics are on, the text font selection menu should be grayed out. And if graphics are off, the graphics font selection menu should be grayed out.

[clinodev]

I wonder if you'd consider adjusting the name and logo of the project, as it's often confusing in the community.

We've had very long periods of time when literally no current pack had the initialism "LNP," and it's currently been nearly a year since one was updated.

Unfortunately, because of the blue "Lazy Newb Pack" across the top, and the launcher name, "LNP" persists.

Players are very confused that while "everyone" recommends the "LNP," they can only find links for the PeridexisErrant Starter Pack, the Linux Dwarf Pack, the Lazy Mac Pack, elpuma's Mac Starter Pack, and so on. The wiki perpetuates LNP, but discusses PE's preference (since early 2014,) for moving away from "Lazy" and "Newb", and notably the comment in that section about the Linux Pack being the last to use the LNP initialism is itself out of date, (the last LinuxLNP was nearly a year ago, with 5 Linux Dwarf Packs since, including ones for 0.47.01 and 0.47.02)

Here's an example of confusion from reddit today.

Perhaps with these new DF releases, and the Steam/itch.io looming on the horizon, it's time to move on from the old nomenclature?

[Slax]

snip

Just post this

[thurin]

What's the trick to get PyLNP to install the TWBT version of the twbt_art, twbt_init, twbt_graphics, twbt_objects folders when selecting the Graphics? I'm tinkering with a homegrown pack but it only ever installs the base versions, not TWBT.

[jecowa]

Change print mode to TWBT, then reinstall the graphics pack. Don't forget the onLoad_gfx file. You could pre-install all those folders to make it easier. Probably not too many want the non-TWBT version when playing with DFHack.

[thurin]

Change print mode to TWBT, then reinstall the graphics pack. Don't forget the onLoad_gfx file. You could pre-install all those folders to make it easier. Probably not too many want the non-TWBT version when playing with DFHack.

I think I've figured it out after looking through the code.  Need to set TWBT in the init.txt in the graphics pack.  That causes it to fall into the twbt_ copy section of the code.  But it only does the "raw" folders, not the data.   So I hacked on the code a bit to get it to do the data folders as well.  That way the twbt_art fonts like jecobus get copied as well and used.

[thurin]

I've made some modifications to hopefully make installing twbt packs easier and am looking for some feedback.

I've added a new toggle option on the graphics page in the Advanced section that shows up if TWBT is detected.  This option controls whether the twbt_* folders are copied when installing a graphics pack.  It will install the data\twbt_art, data\twbt_init, raw\twbt_graphics, raw\twbt_objects and onLoad*.init files that are prevalent in the DFGraphics packs.

I thought doing this would allow the end user more control over if they get the TWBT stuff copied rather than forcing the Starter Pack builder to setup the PrintMode in the init.txt files inside the packs they include.

Thoughts?

If folks think this sounds like a good idea I'll submit a pull request.

[jecowa]

I like that you made it only show up if TWBT is installed. This way it doesn't add more options that don't do anything to packs without TWBT.

So with this option turned on, it will automatically install the TWBT version if it is available? This seems like a good thing. I'm guessing the default setting is for it to be on if both DFHack is on and TWBT is installed, and otherwise defaults to off if either DFHack is off or TWBT is not installed?

The way I've been dealing with TWBT and non-TWBT versions of graphics packs is by only including one version in a LNP. LNPs with DFHack get the TWBT versions of graphics packs, and non-DFHack LNPs get the non-TWBT versions of graphics packs. Since probably everyone using DFHack with a graphics pack that supports TWBT would prefer to use the TWBT version of that pack. No one has complained about it, at least.