Print

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

[PeridexisErrant]

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

• 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

• It would be pretty easy to import /data/art/ from installed mods prior to the installed graphics pack.  Consider this an accepted proposal, conditional on enough else happening that it would be useful...
• Concatenating files is a recipe for trouble.  No overrides support until Mifki supports multiple text files; and then we have an ordering problem when an item is overridden in two files.
• Adding arbitrary content to /raw/graphics/ could clobber the graphics pack, but should be OK if we only allow files that do not yet exist.  Also approved
• No stonsense support, as we don't have a saved copy to restore later.

== Graphics Addon format suggestions ==

Hmm, I'm not a huge fan of any of these.  My instinct is to start by supporting one graphics style per mod, and if people want more they can publish variants of the mod.  This is not ideal, but much easier to get right.  Basically we need better raw merging in general before we get more complicated...


Summary:
- graphics install pulls files from /data/art/ in installed mods
- mods can add but not change files in /raw/graphics/

- other changes only possible if PyLNP magically gets much better at merging things

[Rydel]

It seems like it would be easier overall to store the mod-specific graphics with the graphics pack instead of the mod.  That way, anyone working on the graphics pack only has to deal with one location, instead of working with files spread across multiple folders.

So, instead of each mod having a Graphics Addons folder with a folder per graphics pack in it, each graphics pack would have a Mods folder with a list of mods it has graphics for.

For overrides, the best I could think of would be to allow each Graphics Mods folder to have its own overrides file, which would overwrite the one added by the graphics pack itself if present.  The problem with using multiple overrides.txt files for this (if it gets implemented) is that a lot of mods (i.e. every single one I've looked at) that add items end up changing the internal ID of existing items, which it what TWBT uses.  This also means that combinations of mods need their own overrides.txt file.

Ideally, mifki would add support for using the object's name instead (e.g. ITEM_TOOL_CAULDRON instead of "0"), since that won't change, but until then, override files will be specific to the exact combination of mods being used.

[Dirst]

Remember that changing the art style of a mod should only affect the .png file(s).  The text-based stuff is shared across all of them, so that should only exist once.

It's conceivable that an author might want to use a hunting-trained sprite it one style and color-adding in another, but frankly that's pretty weird and I have no problem skipping support for that case.

So the JSON file would only need to specify a suffix to use for each graphic pack (probably many-to-one, for example several packs assigned to each suffix _bright, _dark and _cartoon).  I would request the ability to include a null suffix, so that the old-fashion drag-and-drop install method would still work... and I would not need to make an LNP-specific build.

Stonesense support is made tricky by the absolute need to override at least one default file.  Adding a comment at the end of the default content might be enough to restore the original.  My mod is pretty rare in having Stonesense content, but it could turn out to be good practice for Armok Vision support.

[jecowa]

That gives me an idea. Mods add the PNG files, but the graphics packs add the text files. When a mod is installed, all the graphics for every graphic pack get installed, but the graphics pack can select the version of the graphics that fit best with it, since it has the text files. This way if mod graphics get added to graphics packs where you probably wouldn't want them (like into ASCII-like ones such as Taffer or AutoReiv), they don't do anything because those graphics packs probably wouldn't be including the text files for mod graphics.

Maybe the Mod addon graphics could be applied to raws before the graphics pack. That way the graphics pack can provide updated graphics for things that haven't been bundled into mods yet.

[Rydel]

Remember that changing the art style of a mod should only affect the .png file(s).  The text-based stuff is shared across all of them, so that should only exist once.

If a graphics pack doesn't have a one-to-one relationship on creatures (i.e. some very similar creatures sharing graphics), this wouldn't work.  Also, I think it would cause blank sprites if one graphics set has hunting/war sprites for an animal but another does not.

Having additional copies of the Graphics text files isn't going to use a lot of space - Fortress Defence's Graphics Text files are a combined 50 KB in Rally Ho!.

That gives me an idea. Mods add the PNG files, but the graphics packs add the text files.

This still has the issue of spreading the art assets over multiple unrelated folders, making maintenance more difficult that it needs to be.

[Meph]

Also, I think it would cause blank sprites if one graphics set has hunting/war sprites for an animal but another does not.

It would crash at worldgen. If a graphics file directs to an image that does not exist, the game crashes to desktop.

[Rydel]

I think it crashes if it points to an out of bounds area.  In some cases, like if the standardizer is used, which be be pretty much required if everyone's going to use the same text file, there's be a spot there, it would just be blank.

[Dirst]

Remember that changing the art style of a mod should only affect the .png file(s).  The text-based stuff is shared across all of them, so that should only exist once.

If a graphics pack doesn't have a one-to-one relationship on creatures (i.e. some very similar creatures sharing graphics), this wouldn't work.  Also, I think it would cause blank sprites if one graphics set has hunting/war sprites for an animal but another does not.

Having additional copies of the Graphics text files isn't going to use a lot of space - Fortress Defence's Graphics Text files are a combined 50 KB in Rally Ho!.

That gives me an idea. Mods add the PNG files, but the graphics packs add the text files.

This still has the issue of spreading the art assets over multiple unrelated folders, making maintenance more difficult that it needs to be.

Sorry I wasn't clear... I meant the sprite sheet that deals with a particular mod.  The sprite sheet that comes packaged with The Earth Strikes Back! looks like this

and if it's redrawn in a cartoonish style the same critters will still be in the same places, meaning the textfiles do not need to change.  Just rename the selected .png to be the target of that graphics file and you're done.

Edit: Now that missing pixel on the Awakened Storm is going to haunt me until I push out a new version of the mod...

[jecowa]

Having PyLNP rename PNGs sounds good to me, if PE's okay with doing it like that.

1. PyLNP merges the mod(s) into the temp folder.
2. PyLNP checks the graphics pack's manifest.json to get its "Graphics_Suffix" (or whatever that should be called).
3. PyLNP renames every PNG in the graphics folder to add "disabled_" before the file name.
4. PyLNP renames any PNG in the graphics folder whose name ends with the value of the "Graphics_Suffix" to both remove that suffix and remove the "disabled_" prefix.
5. PyLNP merges the normal graphics pack into the temp folder.

This disabled flag is so it renames the default graphics that don't have a suffix. (Which are there so the format installs easily without the PyLNP installer.)

Also, maybe we can make an exception for Rydel to add mod support directly to his graphics packs.

[Rydel]

If there's a standard for it, I can adapt my mod to fit the standard.  I'm just worried that splitting the files into a bunch of different places will make maintainance harder.

Currently, when I make a new version, I have to make a zip with and without the TWBT specific files.  With this, I'd also have to move out the mod specific files and upload them into a different location.  Same would be true for any other graphics pack with files specific to a mod.

Most of this would be fixed just by keeping the mod specific graphics in a subfolder of the graphics pack.
In that case, the steps would go more like this
1. PyLNP meges the mod into the temp folder.
2. PyLNP check's the graphic's pack's mod folder for a subfolder that matches the mod (or some identifier in the mod's manifest if they are getting those.)
3. If a subfolder was found, PyLNP renames any PNG in the graphics folder to add disabled_ in front of it
4. PyLNP merges the normal graphic pack into the temp folder.
5. PyLNP merges the graphics pack's subfolder for that mod into the temp folder's graphics folder.

4 and 5 could be switched, but this order allows mod specific stuff to override generic graphics if someone feels the need to do that.

[jecowa]

Putting the mod support in the graphics pack would be easier, but PE doesn't want mod graphics included in his pack (to keep his pack's download size small). So mods need to be able to add their own graphics to make mods more user-friendly for Lazy Newb Pack users to install.

But since it will make it harder for artists to maintain their packs, I think artists should be allowed to add mod support to their packs directly. I think the only graphics pack artists who might be interested in making mod art would be you, utkonos, and Tallcastle. For packs whose artists are inactive (such as Afro, GemSet, Ironhand, Mayday, Obsidian, Phoebus, and Spacefox), it's probably okay to add their mod graphics to the mods.

[Rydel]

Will the LNP be pulling the graphics from the repo directly, or will they be bundled before it's uploaded?
If it's the latter, it should be easy to programatically remove the mods folder from all the graphics set.  This way, they won't increase the size for the end user.

Wouldn't moving the extra graphics from the graphics pack to the mod not change the size at all? Or is PE not going to include mods in his?

Come to think of it, it may be possible to have the best of both worlds if the LNPs will move folders before release.
Each Graphics set would have a Mods folder, with subfolders for each mod they have unique graphics for.
A script could then iterate over each graphics pack and move the folders for each mod to the folder where the mod itself it stored.

[jecowa]

Or is PE not going to include mods in his?

I get the impression that he doesn't want mods included in his pack. Otherwise, he probably wouldn't mind graphics packs having built-in mod support.

[Dirst]

I think that mod-specific graphics belong in the mods... just have the LNP fish out the appropriate graphics from the mods/raw/graphics folder during the merge process.

Now, that opinion is based on a couple assumptions that I want to verify with the experts in the room:

1. There are more LNP players who use multiple graphics packs and zero/one mods than there are LNP players who use multiple mods and zero/one graphics packs.

2. Mods will be a separate download from the LNP.

Though not essential, the case is stronger if the major graphics packs are going to remain bundled with the LNP.

While it's better to have a simple solution than a complex one, the complexity largely falls on the mod authors, graphic artists and pack maintainers (rather than players), so as far as I'm concerned technical complexity is not a major concern.

So, the reasoning for keeping graphics-pack-specific files in a mod rather than mod-specific files in a graphics-pack is to minimize the amount of content that gets downloaded and never used.  The Earth Strikes Back! contains about 7 KB of images for creature graphics (out of 312KB).  Even if I went overboard and made twenty different versions and they were different enough to get no gains from ZIP compression, that's still adds less than 50% to the size of the pack.  This is about the same amount of space as if each graphics pack included its own graphics for The Earth Strikes Back!, but with the crucial difference that the content is only downloaded by people who choose to sample/play the mod.

For reasons that elude me, somewhat less than 100% of LNP players use my mod   Therefore, it makes sense to package extended graphics content with the mod than with the graphics pack.  As the amount of graphic content goes up in a mod, the potential impact on non-users increases.

Even if the LNP were split up so that graphics packs are downloaded separately (perhaps upon first selection in the GUI), the same reasoning holds.  In fact I would suggest the LNP go to a fetch-on-first-use model for both graphics packs and mods, with some option to pre-fetch for those who don't play connected to the Internet (How do you survive without the wiki?!).

[Rydel]

I've been working with the assumption that both 1 and 2 are false.
For one, I mostly am thinking off personal experience - I try a lot of mods, but stuck almost entirely to Phoebus until I created my own graphic set.
With two, since the graphics packs are already in the download, and I'd figured mods would be the same.

If mods aren't a separate download, then the amount of data that's downloaded but not used is the same in either method.

As for complexity, both put the complexity on the mod authors, graphic set artists, and pack maintainers.
Additionally, I work in IT, and one of the security principles is "Principle of least privilege" - you give someone the lowest level of access necessary to do what they need.
If all graphics pack specific files are with the graphic pack, each artist needs access only to graphics packs they work on.
If graphics pack specific files are stored with the mods, then each artist also needs the ability to commit changes to every mod they plan to include support for.