Print

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

[jecowa]

The trick would be to only retain twbt_X files that are different to the standard ones - I think that would cut the file size down some more.

That sounds good. So first it would install everything from the "data" and "raw/objects" folders, and then it would install everything from the "twbt_data" and "raw/twbt_objects" folders?

[PeridexisErrant]

Yep, but the latter only when TwbT is enabled.

Supporting this isn't going to be a priority for me though - there's a lot to do still in documenting the current setup, writing tests, and maybe some tools for (semi-) automatic updates.

[jecowa]

TWBT allows for non-square fonts to be used in conjunction with square tilesets. The biggest advantage of non-square fonts is that they are easier to read. GemSet and DungeonSet both take advantage of this if you want to see an example. I'm working on one for Phoebus, and was planning on making one for Spacefox and Afro next, unless maybe Nopal would rather do it. Just something to consider.

If you want to make one, its tile height needs to be the same as the tile height of your main tilesheet, but the tile width should be more narrow. GemSet, for example, is a 24x24 tileset with a 16x24 font. It would probably look best to draw the text a little bit shorter on the TWBT text tilesheet so that there's a little more vertical space between the lines of text. I didn't do that with first draft for Phoebus, and wasn't happy with the way it looked. (seen in first spoiler below)

Spoiler: example of rectangular font without extra vertical space (click to show/hide)

Spoiler: normal square font for comparison (click to show/hide)

[jecowa]

I'd tend to ship all the tilesets, and stick with the original sizes by default (for better small-screen and creature tile compatibility).  However we should probably take any references to tilesize out of the pack names, and maybe think about improving PyLNP support for variable-tilesize packs and a target tilesize.

Supporting multiple tile sizes sounds awesome! I guess it would need to swap out the graphics folder, the art folder, and the init.txt file?

There's several tilesets that can currently take advantage of this.(e.g. AutoReiv, Bisasam, Curses, DawnFortress, GeoDuck, Jolly Bastion, Taffer, Tergel, Wanderlust, and probably others). I'm also considering adding more TWBT text sizes to some of the more popular old ones (Phoebus, Spacefox, Ironhand, Mayday, Obsidian, and maybe others).

[jecowa]

PyLNP is adding a new line to the manifest.json file called "folder_prefix". I'm guessing we want to use it, but I'm fine with whatever.

Just put the name of your pack there. It supports spaces and punctuation (just tested it with "Rally Ho!").

If Nopal or AutoReiv are here, I've already added it to your packs. (I thought you two would probably be okay with that.)

[CLA]

What's it for?

[jecowa]

The folder_prefix tells PyLNP which folder(s) to look in to find a graphics pack. I think it's supposed to allow a user to have two versions of a graphics pack installed at the same time and allow the folders to be renamed from, for example, "Phoebus" to something like "Phoebus 0.42.06" and "Phoebus 0.42.03". (That feature doesn't work on Mac, though. On Mac the folder_prefix has to be exactly the same as the folder name.)

In PyLNP v0.10f and v0.11, it was the job of the manifest title to determine what the folder name should start with. The "folder_prefix" change moves that functionality to its own field so that the manifest title and folder name don't have to have anything to do with each other. This allows users to have two different packs with similar titles, like "Geoduck 12x12" and "Geoduck 16x16", for example.

The "folder_prefix" field will probably make it easier to transfer a save file from one LNP to another while still being able to switch the graphics pack (if both LNPs are using the same folder_prefixes, that is.) This could be convenient for players of succession games.

If you don't put a folder_prefix in the manifest, then the LNP will identify the pack by it's folder name. This is how graphics pack were identified back in PyLNP v0.10e and earlier.

[jecowa]

I noticed Rally Ho getting some support for Fortress Defense (one of the most popular mods). Is it okay to start adding mod support to some of other graphics packs (i.e. Afro, GemSet, Ironhand, Mayday, Obsidian, Phoebus, and Spacefox)?

[PeridexisErrant]

I noticed Rally Ho getting some support for Fortress Defense (one of the most popular mods). Is it okay to start adding mod support to some of other graphics packs (i.e. Afro, GemSet, Ironhand, Mayday, Obsidian, Phoebus, and Spacefox)?

I've got mixed feelings about this actually - I like the idea of mod support, but here are some of the downsides:

• larger file size for everyone, especially if we're talking about more sprites  (this is a real concern; my pack alone averages about four terabytes of bandwidth per month)
• How do we choose which mods are 'officially' supported?  Might they clash with others?
• Slower or more difficult updates to a new DF version

My general impression comes out somewhere around "not worth it, given that mods can include the extras themselves".  The effort upstream would be better placed improving our formats or PyLNP's merge capability, to minimise the difficulty of managing "graphics extension packs" (a thing I just made up) or similar.

[CLA]

I'm against that and agree with PE's points.

[jecowa]

Eventually it would be nice for the mods to be able to include their own graphics. Currently there are some downsides to doing this, though:

• PyLNP doesn't install any graphics that are included with mods yet, and graphics are a pain to manually install – especially when they include TwbT Overrides.
• The same sprite won't look good in both a 32x32 pack and a 16x16 pack, so it would be nice for mods to be able to specify different graphics for packs of different resolutions.
• Not all graphics packs are in the same style. Even though Dungeon Set and GemSet are both 24x24 sets, ideally a mod would be able have a different set of graphics used with each one if desired.

For now, the simplest way to add graphics support for mods is to include them in the graphics packs themselves.

Initially, I was wanting to add graphics for mods that include their own graphics. (Only ones I know of are Fortress Defense, The Earth Strikes Back, and Dwarven Haberdasher aka cloth armor mod.) This would add about 0.75 MB to each graphics pack, which would be an extra 5MB total for a LNP that includes 7 graphics packs.

Graphics support for mods would mostly be chosen like graphics support for vanilla stuff; it's decided by whoever is willing to draw stuff for it. Doren, for example, decided that Phoebus (and then many other packs) should have support for most vanilla creatures. Instead of deciding which mods should be supported, we should be keeping track of which mods are supported. This info would be helpful to users picking out which graphics pack and mod(s) they want to use.

There probably isn't any need to worry about conflicts. If two mods are both adding an alien_lizard_man or dark_elf, the same sprite will probably work just fine for both mods.

Mod support shouldn't make graphics packs take any longer to update for new versions of Dwarf Fortress. Mods aren't necessarily updating at the same time that Dwarf Fortress updates, and the graphics and graphics definition files don't need to be updated often anyway. Unless Bay12 renames creatures or whatever, updating a graphics pack is mostly just updating the raw/objects files.

In a survey from last month, only a quarter of respondents reported that they use mods, but making mods more accessible to users may help to raise this. Most players who prefer playing with graphics packs are going to be using a Lazy Newb Pack, so it'd be helpful to some users to have a bit of graphics support for mods. Putting a mod's graphics in the graphics packs may not be the best way to add graphics support for a mod, but it's the best, most-user-friendly option at the moment.

[PeridexisErrant]

Eventually it would be nice for the mods to be able to include their own graphics. Currently there are some downsides to doing this, though:
<snip>
For now, the simplest way to add graphics support for mods is to include them in the graphics packs themselves.

Initially, I was wanting to add graphics for [three] mods that include their own graphics.  This would add about 0.75 MB to each graphics pack, which would be an extra 5MB total for a LNP that includes 7 graphics packs.

I am sympathetic, but this would be too large already and likely to grow.

My ruling:  no mod support in vanilla graphics packs.

To balance this: once someone designs a format for graphics to be included in mods, I'll give feedback and once happy implement it in PyLNP.

[Rydel]

If my graphics pack already includes support for some mods, would I need to remove them?  My graphics pack currently includes sprites for all the Fortress Defense races and Succubus sprites for Succubus Fortress.

[PeridexisErrant]

No need to remove support that's already in, though once a better solution exists it would be good to convert over.

[jecowa]

I am sympathetic, but this would be too large already and likely to grow.

My ruling:  no mod support in vanilla graphics packs.

To balance this: once someone designs a format for graphics to be included in mods, I'll give feedback and once happy implement it in PyLNP.

== Requested Features ===

Mod graphics addons should probably be able to do these three things at minimum:

• Add PNGs to the <DF>/data/art/ folder
• Concatenate text to the bottom of the <DF>/data/init/overrides.txt file (if one exists)
• Add PNGs, TXT files, and folders to the <DF>/raw/graphics/ folder

Bonus Points: Stonesense support
Normal graphics packs don't really need to add graphics to the Stonesense, but if a mod adds a new workshop or type of furniture, it would be nice if graphics for this could be added to Stonesense.

Stonesense support would need to at least be able to do these two things:

• Add folders to the <DF>/Stonesense directory (if it exists). These folders would be able to contain XML files, PNGs, TXTs, and more folders.
• Concatenate text to the bottom of the <DF>/index.txt file

== Graphics Addon format suggestions ==

In the root directory of a mod, have some kind of "Graphics Addons" folder. This folder could contain a bunch of different "addons". These "addons" would be like mini graphics packs. A mod could have a different addon for each graphics pack, or it could have several graphics packs share a single addon.

So inside your /LNP/mods/Fortress Defense Mod II/ folder you would have a /Graphics Addons/ folder (or whatever name works best). And inside that folder you might have several more folders. For example:

/Graphics Addons/GemSet/
/Graphics Addons/Rally Ho/
/Graphics Addons/Spacefox/
/Graphics Addons/Sphr16/
/Graphics Addons/Sphr18/
/Graphics Addons/Sphr32/

Since a graphics pack won't always have the same name in every Lazy Newb Pack, maybe it would be possible to search the value of "get_folder_prefix(pack)" to make a guess at what is currently installed. Maybe it could be made to look for either an exact match or a partial match. First it would check for exact matches, and if doesn't find any, then it would check for any partial matches. At first I was thinking it would be good to specify an addon to be the "Else" addon in case there are no matches, but you probably wouldn't want graphics addons to be installed into more ASCII-ish graphics packs like Taffer and AutoReiv.

The mod's manifest.json might be a good place to specify which addon should be used with particular graphics packs. I'm not sure if that would work very well for that, though.

Spoiler: Manifest.json mockup (click to show/hide)

Code: [Select]

Title: "Fortress Defense Mod II",
Content_Version: "v21",
Author: "darkflagrance",
Min_Version: "0.43.01",
Max_Version: "0.43.05",

Graphics Addon 1: "Sphr32",
Exact Matches 1: "DawnFortress 32" "DawnFortress_32" "DawnFortress 32x32" "DawnFortress_32x32"  "Dawn Fortress 32" "Dawn Fortress_32" "Dawn Fortress 32x32" "Dawn Fortress_32x32",

Graphics Addon 2: "Sphr16",
Partial Matches 2: "Dawn Fortress" "Dawn Fortress" "Phoebus" "Obsidian" "Mayday",

Graphics Addon 3: "GemSet",
Partial Matches 3: "GemSet" "Gem Set" "Gem_Set",

Graphics Addon 4: "Sphr18",
Partial Matches 4: "Ironhand",

Graphics Addon 5: "Spacefox",
Partial Matches 5: "Afro" "Spacefox" "Space Fox",

Graphics Addon 6: "Rally Ho",
Exact Matches 6: "Rally Ho" "Rally_Ho",
Partial Matches 6: "Rally",

...

(Sorry, I'm not very familiar with how JSON works, but it gives you an idea.)

Sorry for any parts that don't make sense.

If my graphics pack already includes support for some mods, would I need to remove them?  My graphics pack currently includes sprites for all the Fortress Defense races and Succubus sprites for Succubus Fortress.

I didn't realize Rally Ho had so much Fortress Defense support. I thought it only had graphics for its dark elf race. If you're going to continue adding support for more mod content, it would be convenient for me if there was a list somewhere (if there isn't already) that indicates what mods are supported.

Maybe not every graphics pack needs to use the same method of supporting mods. There's advantages to bundling mod-graphics with the mods, and there's advantages to bundling mod-graphics with the graphics packs.