Print

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

[PeridexisErrant]

Here's the list of commits, which serves as a changelog.
Summary for pack and content maintainers:
 - there's a button to open the DFHack readme
 - mods, graphics, etc now retain a top-level "*readme*" file (case insensitive); utilities-style support will be added someday so writing a readme is encouraged.
 - pack maintainers must configure update frequency or updates are disabled (here)
 - If graphics packs omit mouse.png and/or font.ttf the vanilla one will be used, instead of causing a DF error on OSX and linux
 - Graphics packs can now set VARIED_GROUND_TILES and ENGRAVINGS_START_OBSCURED (d_init), and GRAPHICS_BLACK_SPACE, TEXTURE_PARAM, and MOUSE_PICTURE (init)

Plus the above importer and terminal features, many minor bugfixes, and a few small fixes to work with the newest DF versions.

[jecowa]

Pidgeot, what version of Mac OS X are you building on?

And are you using the version of TK/TCL included with Mac OS X, or are you using the one from ActiveState? It looks like you're using the one included with the operating system.

I can almost build a working bundle of PyLNP, but there seems to be something wrong with my copy of TKInter.

My goals:

• Get PyLNP working on Mac OS X 10.5 Leopard.
• Fix update feature.
• Fix graphics selection outline.
• Allow spaces in the titles of graphics packs without problems.
• Add Retina Display support, if possible.

[jecowa]

I'm really excited for the upcoming version of PyLNP. Mr. Pidgeot, I would appreciate it if you would please build them again. I keep trying to build it myself, but they never turn out very good. Thank you!

[jecowa]

I've noticed some commits to maintain compatibility with 32-bit operating systems. It looks like there might be a plan to allow pack maintainers to bundle both 32- and 64-bit versions and let PyLNP select the appropriately-bitted version.

Here's an issue that might come up – a user plays at both home and work and keeps his Lazy Newb Pack synchronized over the internet, or maybe keeps the Lazy Newb Pack on a USB flash drive to play at two or more locations. What happens if the user tries to use the same pack on both a 32-bit and 64-bit computer? It might look like all the save files have been deleted.

Maybe that's not a very big deal, though. There probably aren't too many 32-bit users in 2016. I can't imagine that Dwarf Fortress would run very well on anything old enough to have included a 32-bit OS. And it would be a lot easier to include both 32- and 64-bit versions Dwarf Fortress in packs and have the user select which one to use upon launch. This would probably also prevent issues with users thinking their save files have been deleted, since they would know that they're using a different Dwarf Fortress folder.

If you really wanted to have seamless 32-bit support, though, maybe PyLNP could be set up to adjust both the 32-bit and 64-bit versions of Dwarf Fortress whenever the user adjusts the graphics, settings, mods, or whatever. Then when the user tries to launch Dwarf Fortress, PyLNP would first check the other-bitted version and move any save files that might be there over to the save folder of the version appropriately-bitted for the user's operating system.

Any thoughts on how continued support of 32-bit versions of Dwarf Fortress should be handled?

[Pidgeot]

I've not really had time to reply to any of this, so apologies for the delay - but I'll try to catch up now.

Pidgeot, what version of Mac OS X are you building on?

It's all running on 10.8, as this is the only one I have any sort of access to.

And are you using the version of TK/TCL included with Mac OS X, or are you using the one from ActiveState? It looks like you're using the one included with the operating system.

IIRC, it's the built-in one. I think I looked at the ActiveState Tcl/Tk at one point, but something wasn't working (or it didn't pick up on it, or something) - it's been a while, so I'm afraid I don't remember exactly what went wrong.

I'm really excited for the upcoming version of PyLNP. Mr. Pidgeot, I would appreciate it if you would please build them again. I keep trying to build it myself, but they never turn out very good. Thank you!

It will be a little while longer, I think, but should be soon. There's one or two more things I'd like to take a look at before an update is released (0.12a, most likely), but I haven't had the time yet - hoping to find it during this week (possibly the weekend).

I've noticed some commits to maintain compatibility with 32-bit operating systems. It looks like there might be a plan to allow pack maintainers to bundle both 32- and 64-bit versions and let PyLNP select the appropriately-bitted version.

I assume you're talking about this commit? I added this mainly in case we would end up needing it, but this was before the first proper 64-bit release was made, and it wasn't clear at the time exactly how they would end up being packaged. (There are also a few regarding baselines, but that's just to allow different versions of the downloads to be used.)

Here's an issue that might come up – a user plays at both home and work and keeps his Lazy Newb Pack synchronized over the internet, or maybe keeps the Lazy Newb Pack on a USB flash drive to play at two or more locations. What happens if the user tries to use the same pack on both a 32-bit and 64-bit computer? It might look like all the save files have been deleted.

Maybe that's not a very big deal, though. There probably aren't too many 32-bit users in 2016. I can't imagine that Dwarf Fortress would run very well on anything old enough to have included a 32-bit OS. And it would be a lot easier to include both 32- and 64-bit versions Dwarf Fortress in packs and have the user select which one to use upon launch. This would probably also prevent issues with users thinking their save files have been deleted, since they would know that they're using a different Dwarf Fortress folder.

If you really wanted to have seamless 32-bit support, though, maybe PyLNP could be set up to adjust both the 32-bit and 64-bit versions of Dwarf Fortress whenever the user adjusts the graphics, settings, mods, or whatever. Then when the user tries to launch Dwarf Fortress, PyLNP would first check the other-bitted version and move any save files that might be there over to the save folder of the version appropriately-bitted for the user's operating system.

Any thoughts on how continued support of 32-bit versions of Dwarf Fortress should be handled?

IMO, the best way to handle that from PyLNP's side is currently to just have two different folders.

Keeping two DFs in sync is *possible*, e.g. using symlinks, but I don't feel that integrating this into the UI is a particularly good idea, given that the number of people who would need this is very limited and it's a destructive operation to do this link (one of the DFs to be linked has all its data removed, and if done in the wrong order, that might lose a fair amount of important stuff). The only thing that couldn't easily be handled like that is the DFHack toggle, since it involves renaming files on Windows (and those files would not have the same content, so PyLNP would have to explicitly know about the link).

*Personally* I would have preferred that DF simply provided both sets of binaries, and then PyLNP could possibly provide an option (Auto/32-bit/64-bit), but of course that's not really feasible given the way the DF builds are distributed (the binary file contents differ, but the file names are the same).

In general, of course, playing the same save on both a 32-bit and a 64-bit build could be a problem anyway, due to the memory limit. If one needed to play at multiple locations, it would be best to use the same DF for that very reason, so I don't see it as something that really needs any major changes at the moment.

[jecowa]

Thanks for all the info! With 0.12a coming soon, I'll wait for that.

I assume you're talking about this commit? I added this mainly in case we would end up needing it, but this was before the first proper 64-bit release was made, and it wasn't clear at the time exactly how they would end up being packaged. (There are also a few regarding baselines, but that's just to allow different versions of the downloads to be used.)

Yeah, those were the changes I saw. Having different folders for the two versions sounds good. Then users can optionally delete the folder for the version that they don't need so they don't have to pick one every time they launch the launcher.

[Pidgeot]

PyLNP 0.12a is now up, adding a few more display options, fixing bugs in the new terminal handling, as well as various other minor tweaks and improvements.

[jecowa]

Awesome!

[jecowa]

What are the basic steps that goes on when PyLNP switches graphics packs from like Phoebus to Spacefox, for example? Is this about how it does it:?

• Check for the graphics pack(s) that's currently installed in the Dwarf Fortress and its save files. (Phoebus is currently installed in all of them.)
• Get a list of files from /LNP/graphics/Phoebus/ and remove those files from Dwarf Fortress and its save files.
• Add files from the /LNP/graphics/Spacefox/ to Dwarf Fortress and its save files.
• If there are some files in the baselines folder that aren't in the Dwarf Fortress folder and its save files, add those back now.

[PeridexisErrant]

What are the basic steps that goes on when PyLNP switches graphics packs from like Phoebus to Spacefox, for example? Is this about how it does it:?

Nope!  It's more like:

• Check that we can recreate the current setup (graphics+mods) and abort if not.
• Create temporary folder, containing baseline raws.
• Install all current mods in temp folder
• Install new graphics in temp folder
• Remove old raws and copy temp folder over.

This means that you always get the same result from the same components, which is good.  (It also means that mods have to come from LNP/Mods/ or get overwritten...)

[jecowa]

Nope!  It's more like:

• Check that we can recreate the current setup (graphics+mods) and abort if not.
• Create temporary folder, containing baseline raws.
• Install all current mods in temp folder
• Install new graphics in temp folder
• Remove old raws and copy temp folder over.

This means that you always get the same result from the same components, which is good.  (It also means that mods have to come from LNP/Mods/ or get overwritten...)

Thank you for the explanation. It sounds like you get a completely fresh raw files every time you switch graphics packs. That makes things easy for me.

By the way, is there any reason that it needs to be able to completely recreate the current setup? (Why does Phoebus need to still be in the /LNP/graphics/ folder when we are trying to install Spacefox?)

If there's a community save file and one person is using his favorite custom graphics pack ("koolset 11x11"), it would be kind of nice if the other community save players could switch that to something better without having a graphics pack named "koolset 11x11" installed. This would also help when different noob packs have different names for a graphics pack or when one has a graphics pack that another doesn't. It's not a very big deal, though, if it's not possible to safely do something like this.

[PeridexisErrant]

Yep, fresh files every time!

The ability to rebuild is just because I worry about breaking things - if the new one have raw issues or something I want users to be able to revert.

[jecowa]

A Sierra user reported that PyLNP 0.12a fixed a problem that prevented PyLNP from launching for him back in v0.11. Do you think the change to PyInstaller 3.2 in v0.12 could be what fixed it? Not a big deal, just curious.

[Pidgeot]

Without knowing how the problem presented itself, it's hard to say for sure... but my guess is no.

There were apparently some circumstances where it could affect some *utilities*, but PyInstaller shouldn't have affected DF itself.

[lethosor]

I think it's likely. The issue was with UPX, according to the errors some people posted. This PyInstaller issue could also be related.

Just to be clear, the issue (that I'm talking about) was PyLNP not launching itself, not DF failing to start.