Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Perhaps items should graphically default to their copy-from parent? #22498
This is something I've noticed that really limits modding items in if you're playing with/modding for a tileset install (such as MShock,) because of the way the game expects the graphic set to specify where each individual item ID comes instead of the item's block specifying where in the graphics it is found.
For example, supposing I wanted to mod in a skill book which took the form of a samurai novel; I could copy-from it from the existing samurai novel and change only the read time and change it from a just-for-fun to a skill book and leave it the same, and it would thus have the same weight, volume, and yield the same amount of paper, etc, as the standard samurai novel.
But in world, it would appear as a gargantuan ? sign, which is jarring in an otherwise graphically-realized game. I am proposing thus that alphanumerics would be resorted to only if absolutely necessary; either, or perhaps both, of the following should be implemented:
1] If an item has no unique graphics assigned to its specific ID, but it has a copy-from tag assigned, it would be treated graphically as if it were its copy-from parent, using the graphic thereof.
This would make item-content packs a lot simpler, by allowing modders to easily reuse graphics that fit the part, rather than setting the bar so high as to either fork a graphics pack to go with their item content packs (and the inevitable cluster that would bring when multiple item packs collide,) or to require that they get the attention of the maintainers of the popular graphics packs to set the item tags.
The second option has promise, map entities can have a graphical attribute seperate from their id, which defaults to the id, the difference being that several entities can share a graphical id. It's also a superset of the other option, because the graphical id would be just another attribute for copy-from to act on.
Shorter term though, we could have tilesets use sym as a fallback tileset id.
This is already implemented, but it requires the tileset to have an ASCII fallback defined (the characters are not rendered via SDLs font rendering, but as normal tiles from the tilesets png file).
Some tilesets (e.g. Hoder, Tsu, Deon) don't have this ASCII fallback defined.