Print

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

[jecowa]

Thanks for the updates and maintaining compatibility with Snow Leopard!

This new feature is very helpful:

V0.13
…
Copy missing tilesets to data/art folder when tileset list is being read

Makes it super intuitive for users to install new Tilesets.

Those improvements to mod merging from v0.12b look like they could be really helpful too. I'm kind of excited to see what three-way merge can really do.

[jecowa]

Over the past couple of years, the number of users with 2560 and 4K displays has maybe doubled. At these sizes, a 32x graphics pack takes up as much screen real estate as a 16x graphics pack uses on 720p and 1080p screens respectively.

Maybe graphics packs could provide a list of options in a file that pYLNP would read and allow users to switch between pre-configured sets of graphic/font tilesets, overrides, and creature graphics. A pack could set up a "16x16" and a "32x32" option which each use their own versions of all the png files.

It could be used for other things than just tile sizes. A graphics pack could have a "hollow wall" option and a "solid wall" option that both share all the same files except for the main tilesheet and the overrides tilesheet.

[jecowa]

I think there's a bug. PyLNP allows me to update graphics in outdated save files.

It will install v0.44.03 raws on top of save files that are using raws from 0.44.02, 0.43.03, or even 0.28.40. I thought it would previously give a warning and refuse if I tried to do this.

I tested in a much older PyLNP 10e (which I was sure wouldn't do it), but it's doing it there too. I can't figure out what's going on.

[somebears]

Hey, I've been playing around with the PyLNP Launcher and especially the Mod part of it.

Now I've come a problem I cannot solve (well, without manually merging ~1000 conflicts)

I am trying to use the Meph Tileset with the mod "revised", both not from the official source, but from other people lovingly packaging/updating them

Tileset: https://github.com/jecowa/Meph/tree/26b34d843ce608eadcc46bd6a1532667326cce6b
Mod : http://dffd.bay12games.com/file.php?id=13270

Some parts seem to produce rather strange merged versions, especially the "plant_*" and "creature_domestic"
The imgur link shows the tileset, the merged version and the mod for one of the plants.
https://imgur.com/a/eO66C

The resulting raws are not very usable, unless you like playing as goblins. And be on fire when embarking.

[jecowa]

Dwarf Fortress v0.44.01 and v0.44.02 included a plant_new_trees.txt with a bunch of spaces instead of tabs. The whitespace is back-to-normal in DF v0.44.03, but Meph 32x uses the regular whitespacing even in the versions designed to work with DF v0.44.01 and v0.44.02. It might cause some funny results when comparing files based on two different white-spacings. (That mod you linked uses the whitespacing from DF v0.44.01/02.)

There's definitely some bugs in the PyLNP mod merging, but it works better than it did in v0.12b. The good thing about the old version, though, is that it wouldn't mess up. If there was something that it though was too complicated for it to merge, it would just refuse to make the merge.

PyLNP version 0.13 it has trouble merging multiple mods that add lines to a file. It looks like it does a better job at merging if the mods only modify existing lines instead of trying to add/remove lines, though. I think it does fine if only 1 mod adds lines, but I haven't tested it very thoroughly yet.

[jecowa]

I just discovered an undocumented feature of PyLNP while checking out PeridexisErrant's keybinds setup. At first I thought there was a problem with PE's "Vanilla DF" custom keybinding file (which was empty), or that maybe PyLNP uses the keybinds from the baselines when it detects an empty custom keybinds file.

Then I saw PE's nearly-empty "Laptop with Mouse" keybinding file and thought that PyLNP must be concatenating the custom keybindings with the defaults. But after testing, that's not what it's doing; it's intelligently applying only the changed lines to the active interface.txt file. I'm impressed that it can do that and will be making changes to optimize for that. It will be nice to rarely need to update the keybind files.

[lethosor]

I remember seeing a lot of talk about that feature when it was being developed - surely it's documented somewhere? Anyway, yeah, that's supposed to avoid the need to change keybinding files when DF adds new bindings (usually).

[PeridexisErrant]

I just discovered an undocumented feature of PyLNP while checking out PeridexisErrant's keybinds setup. At first I thought there was a problem with PE's "Vanilla DF" custom keybinding file (which was empty), or that maybe PyLNP uses the keybinds from the baselines when it detects an empty custom keybinds file.

Then I saw PE's nearly-empty "Laptop with Mouse" keybinding file and thought that PyLNP must be concatenating the custom keybindings with the defaults. But after testing, that's not what it's doing; it's intelligently applying only the changed lines to the active interface.txt file. I'm impressed that it can do that and will be making changes to optimize for that. It will be nice to rarely need to update the keybind files.

Ooh, I should really document that better 

What it actually does is take the default interface.txt, then uses each entry in the selected file to replace the corresponding entry in the default one.  So you just write a file with each binding that you want to change, with all of the keys that you want it to have in the output.

This only works with the SDL edition of DF, but I wrote it for me and haven't had to touch the keybinds since

[jecowa]

Tileset selection is something that I found confusing when I was new. There were two lists, and I wasn't quite sure what the difference was.

Spoiler: current tilesheet selection menu: (click to show/hide)

The names "FONT" and "GRAPHICS_FONT" make sense for a veteran player familiar with the init file, but for a new player, it is kind of confusing. Maybe these could be changed to something like "Text Tilesheet" and "Graphics Tilesheet"? I think those are similar enough to the init.txt file names that players familiar with the old names would understand them, and they'd be more clear for new players.

And unless using TWBT, only the tilesheet in one of these lists will have any effect for the player. Perhaps the other list could be grayed-out or even hidden when the Print Mode is not set to "TWBT". When TWBT is disabled, only the "GRAPHIS_FONT" is used when creature graphics are enabled, and only the "FONT" is used when creature graphics are disabled.

Also, graphics packs with TWBT-support often include tilesheets that are intended specifically for use as either the FONT or GRAPHICS_FONT. Maybe there could be some naming system or text file that graphics packs could use to cause them to sort to the top of the appropriate lists. The tilesheets that the graphics pack intends for use as "text tilesheets" would be displayed at the top of that list, and its tilesheets intended for use as "graphics tilesheets" would be displayed at the top of that list. Then after those, the Dwarf Fortress default tilesheets and the content from the /LNP/Tilesets/ folder would be displayed. And finally the tilesheets from the graphics packs that were not intended for use in that list could be displayed at the bottom – or maybe even optionally not displayed at all. Meph_32x32.png would never be usable as its text font, for example.

Example showing different content sorting to the top in the two lists:

Spoiler: example (click to show/hide)

[Pidgeot]

PyLNP 0.13a is now up.

This improves handling of TWBT-specific files somewhat (including support for twbt_objects and twbt_graphics folders to override files when installing graphics packs with TWBT enabled), and should also make the macOS builds work a little bit better.

[clinodev]

PyLNP 0.13a is now up.

This improves handling of TWBT-specific files somewhat (including support for twbt_objects and twbt_graphics folders to override files when installing graphics packs with TWBT enabled), and should also make the macOS builds work a little bit better.

This is very exciting to see!

The installation process for the TWBT-enhanced graphics packs is just complicated enough (requiring first the base pack, then TWBT, then the TWBT_GraphicPack to be installed, in that order, to end up with the right mix, for Phoebus, at least,) to be annoying and make me really regret that it hasn't worked well in recent Starter Packs.

[carewolf]

As an early step in mod support, have you considered bundling the "Revised" mod, which is basically just a bug-fix mod at this point?

[Pidgeot]

PyLNP 0.13b is now out. Turns out I goofed, and those twbt_* override folders didn't actually get applied at all. My bad; it's fixed now.

As an early step in mod support, have you considered bundling the "Revised" mod, which is basically just a bug-fix mod at this point?

It's up to pack authors to decide what they do or do not want to include. This project only attempts to provide a common codebase to actually apply those things.

[cl3ft]

Hi, I'm not sure if this has been asked, I've searched and cannot find an answer. But is there a way in windows to force the dfhack command window that is opened by PyLNP to open in a different console than cmd.exe? I'd personally like to be able to use ConEmu for example.

[lethosor]

That's more of a DFHack question. PyLNP doesn't do anything different to launch DFHack on Windows than launching it ordinarily.
DFHack just uses a system command prompt window, and I'm pretty sure there's no way to get it to use something else easily. If you can make ConEmu the system-wide default, that might work, but I don't know if it's possible.