Bay 12 Games Forum

Hmm.  Apparently I'm not the only one to find these symbols confusing, even when we have the familiar reference.

So I suggest replacing symbols for the outcome with symbols for the action, typically using the tool.

• Mining uses a pickaxe icon (as in earlier screenshots)
• Channelling is a shovel
• Wood-cutting is a (single-bladed) axe
• Gathering is a basket
• Anything to do with stairs uses a steps profile, with a sub-icon to indicate the action.  Example.  If the icon is always 'above' the stairs (and the stairs are shaded, not just a line) it's unambiguous; the use an up/down/double-ended arrow for up/down/up-down stairs, an X for removing them, etc.
• Removing ramps can use a similar shape to removing stairs, with a right-triangle instead of the steps.
• Smoothing and engraving can both use a chisel icon.  To distinguish them, add a colour or pattern to engraving.

That's not an exhaustive list, but I think it covers the most common visible designations in a way that inexperienced players will still understand.

Sounds good.  "source" is a traditional name, and add a source/README.md file that explains how to convert the source to output version.

With Dwarf Therapist only supporting 32-bit builds of Dwarf Fortress, should utility manifests have flags like "needs_64" and "needs_32"? I can't think of any other apps this would matter for, but it would be nice if the versions of apps incompatible with the active Dwarf Fortress installation were hidden.

Sounds useful - I'd call them "32bit-DF-only" and "64bit-DF-only" to make sure people don't use them for declaring system arch requirements (which are sufficiently complex that I suggest PyLNP not go there in manifests at all).

I've opened an issue on Github, but given that most of the modders are on the forums I though it would be worth cross-posting.

The DFgraphics group has a two-part feature request:

• Support multiple overrides files, eg anything matching "overrides*.txt"
• Support item subtypes by name and generally discourage use of numbers as IDs

This will allow modders to provide substantial extensions for various graphics packs, to give a native look to their new content.  I'm working on some fairly major changes to PyLNP to support the other end of this, so some indication of whether you'll be able to help out (and a timeline if so) would be awesome 

You're missing a Windows 8 option!

The 43.05 release of Ironhand graphics works with DF 43.03, but the easiest way by far is to download a package with everything preinstalled.

Short summary: 

Most of the functions of the Workflow plugin can now be accomplished by the vanilla manager.  Everyone is therefore trying to strike a balance between keep it available for crusty old players (eg me), while encouraging new players to use the manager and old players to switch.  I imagine workflow will be kept until it breaks in a particularly annoying way, and then it'll be easy to delete.

- DFHack kept Workflow, but removed the keybindings
- I removed the GUI option to enable workflow (so you need the console now), but kept the keybinds so it's easy once enabled.

Alright, time for another (shorter...) essay.

TwbT Overrides
@Meph @Rydel:  OK, apparently I'll also be asking Mifki to support subtypes by name.  (it would also be good to log a deprecation warning for numerical indicies, both to encourage change and explain to users why things are broken...).  DFHack does have access to the names - look for example at the view-item-info and item-descriptions scripts: the former looks up text in the latter by item type or subtype name.

We can't reliably merge overrides files, as they would not have the level of context that raws generally provide (ie unchanged vanilla lines).  TBH I'm surprised sometimes that the merge works for raws at all...  improving this has been a PyLNP goal for years, but it's a really hard problem.  Unique names so we can just keep adding files is therefore my favorite solution!

Preprocessing files to keep track of item subtype ID numbers... just no.  It's may be technically possible, but it's not happening.  I'd improve raws merging instead if I could do this.


Where do Graphics extensions live
As @Dirst says, it's just be whatever goes in "LNP/Mods/<some_mod>/raw/graphics" - not a new kind of thing (which would be a combinatorial explosion at best).  This is obviously a default-only thing; extensions for other graphics packs will live in subdirectories ("LNP/Mods/<some_mod>/graphics-extensions/<name-of-gfx>/", for example).

@Jecowa - creating a graphics extension for a mod makes you a mod author (or contributor, in which case you do the usual sned-changes-to-author dance); but you don't need the graphics pack to help you or even know graphics extensions exist - so they'll be backwards-compatible

No suffixes or renaming.  It's just to fragile, and prone to breaking in hard-to-diagnose ways!


How does PyLNP decide which graphics extension to install?
The manifest for a mod will have a new attribute "graphics-extensions", which is a dictionary mapping graphics packs to subdirectory names (see above).  Technically, the extension is just another mod to merge (so object files can be changed); by policy it should just override the relevant graphics bits.

PyLNP will install the default mod (which includes graphics), then if the installed graphics pack matches a subdirectory (per the mapping) will install the relevant extension.  Mod authors may therefore wish to provide nothing as the default extension (ie leave /raw/graphics and twbt files nonexistent), to avoid installation clashes.


Other comments
@Meph - we feel exactly the same way about standards; I'll be sure to let you know.  Honestly I'd love to bring PyLNP and the masterwork launcher closer together or even merge them, but that's a conversation for another time and place (and after some upgrades...).

Maybe mods writing to raw/graphics is banned by code elsewhere?  Anyway, the core code handles this OK and I should be able to make it work without too much trouble.

PyLNP copies image files and DFHack scripts, but merges .txt (eg raws) and .init files.  Otherwise we would indeed have (even more) trouble installing more than one mod at a time.