Print

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

[thurin]

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.

Correct.  DFHack has to be detected, and it also has to detect that the TWBT plugin is installed.  If those two things are true, then the option is available.  If the option is set to Off, then it only copies the base folders from the pack.  So the PrintMode would be set to whatever is in the data/init/init.txt, typically 2D.  If the option is On, then it also copies the twbt_ folders and you end up with PrintMode being TWBT (if it's set that way in the data/init_twbt/init.txt of course).  The option defaults to On, so the user would need to explicitly set it to Off.

If TWBT plugin isn't detected, then it skips all the twbt_ handling and you end up with a standard 2D set of files.

Edit:

One thing I'm considering adding is a setting in the PyLNP.json that would allow the Pack Builder to control if the option is available.  If they want to force it to Off regardless of using graphic sets that support it.  I'm not sure why this would be the case, but I think options are good.

[jecowa]

What's going on on the GitHub? A bunch of issues got closed and a bunch of similar issues were opened.

[thurin]

What's going on on the GitHub? A bunch of issues got closed and a bunch of similar issues were opened.

It looks like all the issues got copied over from bitbucket.  previously it was only the code.

[Pidgeot]

A progress update on things I mentioned in a previous post:

• 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.

This has now been fully completed, and as thurin correctly guessed, that involved copying the issues over. Unfortunately the issue IDs had to change, so references in commit messages etc. will no longer match up.

I have also just finished migrating all binaries over to the Github releases page, so they are archived there. All future releases will go here.

The Bitbucket repository is still around for now, and will still contain a mirror of GitHub, but issues and pull requests should not be made there. AFAIK, it will disappear completely on June 1.

• 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.

This is still being looked at; I've finally managed to get Windows builds working with Python 3, but I still need to verify with the other operating systems. Hoping to get this fully sorted during Easter.

[thurin]

• 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.

This is still being looked at; I've finally managed to get Windows builds working with Python 3, but I still need to verify with the other operating systems. Hoping to get this fully sorted during Easter.

Let me know if I can help with any of this testing.  Mac is my main platform with VMs for windows and linux.  I've run and built PyLNP on all 3 with 3.8 and haven't come across any issues yet but I'm not sure what's needed for testing all the scenarios.

[jecowa]

Some users are reporting crashes when trying to install a graphics pack. One said it fixed the problem when he tried running PyLNP from souce. It seemed like a kind of unusual thing. I think all the user might have Windows 10 in common, but there's definitely lots of Windows 10 users with no problems, so i dunno.

[Pidgeot]

• 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.

This is still being looked at; I've finally managed to get Windows builds working with Python 3, but I still need to verify with the other operating systems. Hoping to get this fully sorted during Easter.

Let me know if I can help with any of this testing.  Mac is my main platform with VMs for windows and linux.  I've run and built PyLNP on all 3 with 3.8 and haven't come across any issues yet but I'm not sure what's needed for testing all the scenarios.

Generally speaking, builds are going to run fine on the same system that built them, but they don't necessarily run on *other* systems. For example, on Windows, you'll want to make sure it's bundling the VC runtime as necessary, but you won't see that problem on the build machine because it will already have the right runtime installed system-wide.

In the case of Linux, my main concern is to end up with executables that have the minimal possible requirements (e.g. minimal glibc version requirements, etc.). Due to the state of the specific VMs I was using, it's not been possible to re-use the existing ones for Python 3 builds, so I'm in the process of spinning up newer ones (...which takes a while, because I need to use Gentoo to achieve that).

For Mac, at the moment it's mainly making sure that I have a way to build it - my normal build VM no longer boots for some reason, so I need to get another one working first.

Some users are reporting crashes when trying to install a graphics pack. One said it fixed the problem when he tried running PyLNP from souce. It seemed like a kind of unusual thing. I think all the user might have Windows 10 in common, but there's definitely lots of Windows 10 users with no problems, so i dunno.

I don't have enough details to really make a good guess at the cause. If this is happening often I might need to build in extra debug output and hope to track it down that way, but first I need to have my build VMs working...

[cryzed]

Are you still actively working on this? Most Linux distros ship Python 3 by default now and the current PyLNP version that most (Lazy Newb-)packs ship with simply break when clicking the play button, because you haven't made a new release since merging the Python 3 fixes. BTW: passing "universal_newlines = True" to Popen (or run()/check_output() etc.) would probably be more future-proof instead of just trying to decode the stdout with UTF-8, because Python uses "locale.getpreferredencoding()" to determine the likely encoding instead, according to the docs.

[Pidgeot]

I've not been able to look at it for a couple of weeks now, but the current state is that I still need to get a Python 3-based build working for MacOS. Because switching to Python 3 is a very major change, I don't want to release until I know this is working for all OSes.

So far my attempts to make the build process work properly has required *far* more hacking that I'm comfortable including in a build process (which is saying a lot ). I have thought of some alternative ideas that I hope to try out over the weekend; as long as I can get one of them to work, a new release will follow immediately after.

[cryzed]

Hey that's great to hear, thanks for letting me know. I might make some additional pull requests on GitHub to get some Linux/KDE-specific stuff to work. Great project by the way .

[cryzed]

I made three new pull requests. If you get the build system issues all worked out, maybe you'll find time to merge them additionally.

[Pidgeot]

PyLNP 0.14 has been released and may be downloaded from the GitHub release page.

The main change here is an upgrade to Python 3 for the builds (specifically Python 3.6 on Linux and 3.7 on Windows and macOS).

This has required setting up entirely new build machines for Linux and macOS, and as such it *is* possible that something has changed that might cause compatibility issues that I have not noticed (as I am not a regular user of either of those operating systems). If you have issues running the latest version, please report them.

In addition to the Python upgrade, this release should improve terminal handling on Linux, and be a bit better about reporting crashes.

[PeridexisErrant]

Thanks Pidgeot!  I know that there's a *lot* of work involved in setting up a new build and dealing with cross-platform support...  on behalf of all the users who don't know they should be thanking you, thanks.

[cryzed]

I can only second this, thank you for your efforts!

[Pidgeot]

PyLNP 0.14a has been released and may be downloaded from the GitHub release page.

This fixes an issue when the program attempts to import text files from an old pack.