Print

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

[Dirst]

PE is worried about the bandwidth required to include mods, so I figured we could go the other way if there was a painless-to-the-player method of getting graphics packs out of the base download.

The key word being "painless."

[jecowa]

I think PE might want to keep it really simple for now. I'm wondering if filename switching is more complicated than what he wants to implement at this time. If PyLNP would install the graphics from the mods, then install the graphics pack, then install the mods' raws and stuff, I think think that would work just fine for initial support.

This would allow mods to have their own default graphics. It would allow graphics packs to override a mod's graphics with their own (or with nothing for ASCII-ish packs). And it would allow the mods' raw objects files to override the graphics pack's raw objects files.

[Dirst]

I think PE might want to keep it really simple for now. I'm wondering if filename switching is more complicated than what he wants to implement at this time. If PyLNP would install the graphics from the mods, then install the graphics pack, then install the mods' raws and stuff, I think think that would work just fine for initial support.

This would allow mods to have their own default graphics. It would allow graphics packs to override a mod's graphics with their own (or with nothing for ASCII-ish packs). And it would allow the mods' raw objects files to override the graphics pack's raw objects files.

Pro: I can support this standard with my current distro, meaning zero marginal effort on my part.  Artists can support modded stuff at their own pace with no compatibility-breaking jumps in the graphics pack format.  And, did I mention zero marginal effort for me?
Con: Seems likely to cause filesize creep in the LNP.  This was precisely what PE was trying to avoid, though this plan inflates the size a lot less than the original idea of bundling a couple dozen mods.

[jecowa]

It wouldn't save as much space, but it would be easier to implement. And it would allow mod packs to install their own graphics while still allowing Rally Ho to have its own graphics for mods too.

Being able to switch file names depending on the pack installed would be great, though, if PE's okay with that.

[Tallcastle]

i confess i haven't gone back to read this entire conversation so i'm kind of jumping in the middle here.  If "Filesize Creep" is an issue, why not include the graphics packs as a separate download?  Like an Expansion pack.  This also arranges it so that the "Graphics" component of the LNP can be updated regularly without needing to repackage the entire LNP.

Again, i haven't taken the time to see what came before.  so if this has been suggested earlier than sorry for the necromancy.

[jecowa]

Making users download and install graphics packs seperately seems like it might be confusing for new players, and there's probably several users annoyed at the more complicated installation process.

[Dirst]

If it could be dead simple, such as fetch-on-first-use, that should work just fine.  The hard part is the player with intermittent/slow Internet who wants to prefetch some packs (at the extreme, think of someone downloading to a thumb drive on a library computer that is too locked down to actually run the LNP).

It shouldn't be too easy to prefetch everything (for example, a "fully loaded" pack) since a large number of players would simply pick that pack.  The ability to "fetch" from a local file should suffice for the constrained users without enticing general players to download everything at once.

[PeridexisErrant]

Alright, I'm caught up and finally have time for a longish response. 

I started by replying to individual posts, but that got too long and hard to follow; so instead it's organised by topic.
Quotes omitted due to length and duplication, so if I've missed or misrepresented anything let me know please!

And now, the essay:


I think we're actually discussing a couple of separate things together, and it would be useful to distinguish them.

Types of content (for things added by mods):
 - Native DF creature graphics
 - TwbT item and building overrides
 - Stonesense content and other visualizers

Issues:
 - Should graphics support for mods be part of the mod, or the graphics?
 - What file structure or conventions should we use?


Where should graphics extensions be stored?

Ruling:  A graphics pack should be for vanilla DF only.  A mod in PyLNP format may include a "graphics extension" for one [or more] graphics packs.

Rationale summary:

• There are very many more mods than there are graphics packs, and many people who use graphics do not use mods.
• Cumulative file size is a real issue and would affect many packages (including mine).  This approach minimizes the impact on people who will not use graphics extensions.
• The graphics maintainer and the modder providing a graphics extension will often be different people.  This minimizes my concern about 'spreading the art out' - that's actually the point, as it allows anyone to add some graphics to their mod without a gatekeeper or single point of failure.
• I would like mods to support multiple graphics extensions, but this may overcomplicate the format (hence the [brackets] in the ruling).  See format discussion below.

TwbT extensions
These are actually pretty tricky right now, given that they should be flexible in PyLNP but also work when drag-and-dropped.

Support will be very easy if/when Mifki supports multiple overrides files, or changes to the alternative sprite-per-file filename-based scheme he mentioned a while ago.

@Rydel:  items can in fact be referenced by name, so we can avoid the problem of numeric IDs changing.  Perhaps we (or Mifki) should detect use of numbers and issue a deprecation warning?


Stonesense content is out of scope for this discussion.  We can - and I intend to - consider supporting utilities after native creature graphics and TwbT support works.  Armok Vision plans to use Stonesense format directly, when customization creatures are added, so no extra work will be required there.  Other utilities are further away still - let's get the basics nailed down first!


Format Ideas and Constraints

I'll list some contraints that our format must satisfy (non-negotiable); then features that would be nice if someone can work out how, and last describe a starting point for more discussion.

Constraints:

• It MUST be possible to install a mod in any proposed format simply by drag-and-drop over DF.  This promotes accessibility for anyone who (for some reason) doesn't use PyLNP.  It also means that PyLNP can use content that wasn't explicitly designed for it, massively expanding the catalog.  (Rubble takes the opposite approach; fantastic technical basis but relatively little content)
• It must be possible to make a Graphics extension compatible with an arbitrary graphics pack, without the cooperation of the graphics maintainer.  I understand that most of the people in this thread fill both roles, but the format we choose should work for more casual creators too - or we'll never see much takeup! (ie: mods mst be entirely self-contained)

Nice (but optional) features:

• Support multiple graphics extensions in a single mod.  Easy to store in a subfolder; but how would you flexibly decide which to install?  Possible:  categories like MIME types, regular expressions, something else.  (Must support a default for drag-and-drop install)

Suggested starting point:

• (recap:) A mod in PyLNP format is simply a DF install with the vanilla files removed.  We then merge the raw/ and data/speech/ files.
• To support graphics, mods just include graphics raws and images.  As long as they don't have the same name as a file in the graphics pack, this already works!  (I just checked the code - apparently I thought of this two years ago )
• Support for data/art and data/init/<overrides files> will be added once Mifki supports multiple overrides files.
• (for discussion) How should non-default graphics extensions be stored?  How should PyLNP choose which to install?  Does this work with multiple mods?

Other Comments

A few other things came up in the discussion; here are some replies.

• Graphics packs need to be bundled due to Pidgeot's (IMO reasonable) policy that PyLNP should work in offline mode by default.  I've done some work on auto-downloader scripts for my own work on the pack, but while that may eventually provide a way to download-on-demand it's a long way off and doesn't solve the more fundamental problems.  "prefetch a curated subset" will continue to be the default in my pack for a variety of reasons.
• I do actually pull and preprocess graphics for my own pack, but for this discussion I'm mostly thinking with my 'PyLNP developer' and 'DFgraphics coordinator' hats on, rather than 'Starter Pack' or other roles - so the important bit is simplicity and usability for other users.  I'm not designing the format solely for my own use!
• I don't currently include mods in my pack because it's targeted at new players, but may eventually - likely via a fecth-on-install system and online list of sources.  But that's far-future stuff...
• I think the two perspectives are summarised well by @Dirst and @Rydel.  I tend to agree with Dirst, and think that this is more representative of most players.
• Separate downloads are certainly not painless, which is the whole point of (switching hats briefly) a newb pack.  It kills the whole "here's a USB" model, for example...
• It's now 2am here, so I'm done writing for the day.  See you later!

So, uh, I hope that makes sense!  I know I'm coming across as the no-fun-guy in a few places, and maybe acting on authority I don't really have - but I hope you can see there's some reasons behind this, and I'm still happy to hear other opinions.  And frankly if anyone else wants to code up a better system they're entirely welcome to; and it's not like the format is enforcable in any way other than compatibility with the PyLNP code...

Regardless, keep up the discussion - I've already learned a lot! 

[Meph]

TWBT overrides accept item subtypes now?

[Rydel]

@Rydel:  items can in fact be referenced by name, so we can avoid the problem of numeric IDs changing.  Perhaps we (or Mifki) should detect use of numbers and issue a deprecation warning?

That link shows names for Ids and Types, but last I heard, subtypes are still numerical.  This would be a problem for mod support since subtypes for existing entries can change when you install a mod.

[jecowa]

That was a well-organized post.

• It must be possible to make a Graphics extension compatible with an arbitrary graphics pack, without the cooperation of the graphics maintainer.  I understand that most of the people in this thread fill both roles, but the format we choose should work for more casual creators too - or we'll never see much takeup! (ie: mods mst be entirely self-contained)

Are you talking about making this a new folder in the /LNP/ folder? Like a /LNP/GfxExt/ folder or something? (There's probably a better name for it than that, though.)

• Support multiple graphics extensions in a single mod.  Easy to store in a subfolder; but how would you flexibly decide which to install?  Possible:  categories like MIME types, regular expressions, something else.  (Must support a default for drag-and-drop install)

Instead of trying to use existing lines in the manifest, it might be better to have new lines just for this instead of trying to use regular expressions on existing lines. Make special manifest lines just for mod graphics so that there's no need to change them except to adjust what graphics extensions get used with a graphics pack or mod. Then the manifests of the graphics extension packs could have two lists, one to list the graphics packs it should be used with and another to list the mods it should be used with. Whenever a user installs a graphics pack or a mod, PyLNP would also install every graphics extension pack that had at least one hit in both lists.

The manifest of the graphics extension would also have a line that indicates if the extension is intended to replace the mod's built-in graphics or supplement them. Graphics extensions would be installed after mods, so that the extension in "supplement" mode can still comment out any of the default graphics that it wants to replace.

• To support graphics, mods just include graphics raws and images.  As long as they don't have the same name as a file in the graphics pack, this already works!  (I just checked the code - apparently I thought of this two years ago )

I thought I tested to see if this would work like a month ago and PyLNP v0.11 wouldn't install any PNG files from mods.

[Dirst]

I think "in the mod" meant under mods/___/raw/graphics/.  The tricky part is having multiple versions for different graphics packs, which could be done with a file suffix (before the extension) or subfolders.  The mod's manifest calls out a specific set of graphics to use when specific graphics packs are active, for example the _cartoon version for GemSet and Spacefox.  Unnamed graphics packs get the mod's default.

[jecowa]

He talked about people being able to make graphics extensions without needing to collaborate with mod authors or graphics packs authors, so I thought graphics pack extensions might be getting their own spot.

Would I still be able to specify graphics packs by name instead of by category? I'd like to have the ability to specify different sets of graphics for Spacefox and GemSet.

Would each graphics pack need to tag it's manifest with categories to describe itself? Maybe use tags like "cartoon" "ASCII-shaped" "monochrome".

Maybe there could be a way to categorize by size too, so you could provide different-sized versions of graphics in the same category.

[Meph]

Once you guys figure out a standard, PLEASE, let me know. I hate doing all kinds of work, then re-do it because I have to sort it or name it differently.

[Dirst]

He talked about people being able to make graphics extensions without needing to collaborate with mod authors or graphics packs authors, so I thought graphics pack extensions might be getting their own spot.

Would I still be able to specify graphics packs by name instead of by category? I'd like to have the ability to specify different sets of graphics for Spacefox and GemSet.

Would each graphics pack need to tag it's manifest with categories to describe itself? Maybe use tags like "cartoon" "ASCII-shaped" "monochrome".

Maybe there could be a way to categorize by size too, so you could provide different-sized versions of graphics in the same category.

I was envisioning an arbitrary list in the mod's JSON file, not tagging the graphics packs themselves.