/tg/Station 13

Dmi files are easily the most annoying ones to track on the git repo, is there an actual reason to condense so many things in a few dmis?

Can you have wearables span across multiple dmi files for instance?

My question is mostly related to the ease of maintenance of forks when it comes to custom icons, so they don't have to touch the same dmi files as the master branch.

We have alternate_worn_icon, so you can already have any new clothing use a seperate .dmi

Excellent, a long time ago when I made some sprite stuff i just added to the existing dmi files, but this is prone to constant merge conflicts.

So there is no actual drawback to using a separate dmi per item/feature?

It's just the old way of doing things, no particular reason other than "someone else did it so it is like this". dmi files actually have a limitation regarding the number of states, I think.

Scott wrote:It's just the old way of doing things, no particular reason other than "someone else did it so it is like this". dmi files actually have a limitation regarding the number of states, I think.

no they don't.
dmis can keep growing until they reach the maximum size of a png file.
they won't open in DM's editor past around 255 states though, but that's just DM being shit, the dmi itself is fine.

Right, it's DM's limitation.

DM doesn't test if icon_states are valid but it would throw up an error if it can't find an icon file referenced in single quotes like icon = 'icons/mob/aibots.dmi'

It's hard to catch every case, but I would love to add a Travis test that makes sure all objects have a valid icon and icon_state combo. This would miss overlays, but those are pretty difficult to test for reliably frankly.

So there would be no harm in breaking down our current dmi files into a few hundred separate ones?

As long as it makes sense.

Kyrah Abattoir wrote:So there would be no harm in breaking down our current dmi files into a few hundred separate ones?

You'd have to go through every object in the game that uses a dmi, including mobs and structures, and edit their icon lines to point to their new icon locations in those several hundred new dmis.

Have fun

Couldn't you reference a entire clothing set with
Etc? we already automatically call on hydroponic tray sprites just by referencing where they are held, because it reads the DMI names such as "potato-harvest" on conjunction with the rest of the sprites after defining how many growth stages to expect, as well as any expected abnormalities like poppies & mutations sharing the same growth but with different harvests & a similar death sprite.

Im not very proficient in code, but as far as choosing sprites non remotely, the way we pick out randomised floor tiles i would say is a good example of referencing appropriate images via tags we could use here.

For reference he's the basalt randomization in its original form

What would it matter if you did