Forum:Supporting old versions in Inventory slot

There is a recurrent complaint in Discord about {{Additions table}} using anachronistic textures for blocks and items added by the version described on the article. While one could argue that players usually play modern versions and are more familiar with modern textures, completely breaking visual changes as with spawn eggs are rare and thus old textures are mostly still recognizable. Nonetheless, {{Inventory slot}}, which is used by the aforementioned template to show the blocks and items, currently has no defined way to show old textures. It’s understandable as Inventory slot’s main use cases are recipes and infoboxes, which must reflect the current game version (and possibly the new one) and thus use modern textures.

Mod-friendly wikis such as the Russian Minecraft Wiki may have similar issues in that some mods are often not supported for the latest version(s); AFAIK Java Edition 1.12.2 is still popular due to mod support, and it predates the Texture Update, so articles on mods not supporting post-Texture Update versions will have recipes mixing different texture styles. Minor texture differences between 1.19.2, 1.20.1, 1.21.1 and the current versions may also exist.

Another problematic aspect is group aliases listing potentially anachronistic features. This is mostly an issue for mod documentation: for example, pale oak wood did not yet exist in 1.20.1 and 1.21.1, which appear to be the most recent “extended mod support” versions and are the latest ones supported by e. g. Create. Mods only targeting as far as 1.19.2, which has no bamboo blocks or cherry wood, have it even worse. However, vanilla version articles do sometimes show recipes, so this issue might be relevant for EnMCW as well. Hence I’m bringing it up here, especially since RuMCW is not the only one to cover mods.

An “easy way” to solve the old texture issue would be just uploading relevant files under a name like File:Invicon Oak Planks JE 1.0.0.png. However, due to how {{Inventory slot}} currently works, the JE 1.0.0 part will appear both in the tooltip and in the link target. The former can be remedied by using the [Oak Wood Planks]Oak Planks JE 1.0.0 syntax, which redefines the tooltip title as “Oak Wood Planks”, but that takes quite some space, so adding an alias may be desirable. And given that the aforementioned Texture Update alone has changed almost every block and item, we might need a lot of such aliases. But aliases can’t fix the other issue — the link target. If we don’t want to create redirects with weird names, the only way to change the link target with {{Inventory slot}} is by using its link parameter, but the {{Additions table}} template (which is frankly written rather badly) doesn’t expose it... and if the slot cycles through multiple items, which is the case with group aliases like “Any Planks”, they all will link to the same target. Likewise, the ingredient/output link generator in Module:Recipe table (which powers templates like {{Crafting}}) has no way of ignoring the JE 1.0.0 part outside of manually overriding the relevant cells’ content with ingredients and output parameters. Hooray, a whole new set of superkludges!

Looks like we’ll have to implement a proper way for specifying block/item versions in Inventory slot. We need to consider how to specify the version(s) (preferably not as a separate Inventory slot parameter), how to name the Invicon files, and if needed, how to implement version-specific aliases. — BabylonAS 12:15, 31 May 2025 (UTC)

The easiest solution might be to implement a rarely used functionality from our normal sprite templates: +

Everything after the + is only used for the file name, while link and title use only the part before it. This currently allows for stuff like {{BlockLink|Piston+Head}} resulting in 👁 Image
Piston.

Adding this feature to Module:Inventory slot as well would allow for Oak Planks+JE 1.0.0 to be used to reach File:Invicon Oak Planks JE 1.0.0.png while the tooltip and link target both remain just Oak Planks. -- 👁 Image
MarkusRost (talk) 13:27, 31 May 2025 (UTC)

This looks very weird and is not consistent with how edition suffixes (which are necessary to specify the version) are dealt with. Also, there is always a chance for the plus sign to actually be part of the name (remember Potatiesh, Greatstaff of the Peasant?). Finally, if we are to implement version aliases (like Any Planks JE 1.21.1), it might be better to let Inventory slot know what version is being referenced... — BabylonAS 13:57, 31 May 2025 (UTC)

Any Planks JE 1.21.1 aliases will never work automatically as the alias module doesn't know which planks didn't exist yet at that time. Same with tooltip colors and values.

We currently don't have any Invicon files containing + in the title. And if they are added, we can solve them with aliases to point a + name to a file without the plus and a redirect. The + syntax would be checked last, in the part generating the html and not replace any custom tooltips. -- 👁 Image
MarkusRost (talk) 14:14, 31 May 2025 (UTC)

👁 Image
 Support 👁 Image
WillChill (Talk | Contributions) 14:24, 31 May 2025 (UTC)

I do agree that this should be fixed, but as for the technical bits of it, I must admit I'm very confused... -~- Nerdyguy2000   Talk   Edits  14:35, 31 May 2025 (UTC)

Block and item additions👁 Invicon Bee Spawn Egg Revision 1.png: Inventory sprite for Bee Spawn Egg in Minecraft as shown in-game linking to Bee Spawn Egg with description: Bee Spawn Egg
👁 Invicon Bee Spawn Egg.png: Inventory sprite for Bee Spawn Egg in Minecraft as shown in-game linking to Bee Spawn Egg with description: Bee Spawn Egg

Actually, looking at Module:Inventory slot we already have full support for Revision X suffixes since February which works fine in the additions table. So this whole topic is kinda mood. Though it might be worth considering to also add support for our currently used JE1, BE1 and JE1 BE1 suffixes as well. -- 👁 Image
MarkusRost (talk) 15:14, 31 May 2025 (UTC)

So I guess the question would be about the exact format of naming. My intent was to identify visual variants by versions that introduced them, instead of JE1 or BE1. Also, we still need to consider aliases. — BabylonAS 15:20, 31 May 2025 (UTC)

What exactly is there to consider about aliases? If you need an alias to use old texture you can just add one returning Revision 1 names. -- 👁 Image
MarkusRost (talk) 15:25, 31 May 2025 (UTC)

I assumed that the “old” aliases would be set in and loaded from a module separate from the main aliases module. — BabylonAS 16:21, 31 May 2025 (UTC)

That seems unnecessarily complex, they can just be added in a section of the existing module. We won't need a lot of old aliases anyway, as most of them are only used on very few pages (specially any group aliases) so that defining the list directly in the article is often the easier solution compared to a proper alias. -- 👁 Image
MarkusRost (talk) 16:26, 31 May 2025 (UTC)

I guess I’ll keep that idea for RuMCW mod articles. Anyway, what about using JE 1.0.0 (the game version that added or changed the texture) instead of Revision 1 or JE1? And how to deal with simultaneous Java & Bedrock version specification? — BabylonAS 16:30, 31 May 2025 (UTC)

I'm not sure it's a good idea to start adding a third variant for old file versions. With all the different ways versions can be named, it would also be more difficult to safely cut the version name from the name in the module. The JE1, BE1 and JE1 BE1 suffixes can just be removed using name:gsub(' BE%d+$',''):gsub(' JE%d+$',''). In fact I made the existing inventory slot suffixes work like revision, so we no longer need to define edition specific items in the aliases module. Adding BE1 and JE1 to those suffixes in that order should support all three versions. -- 👁 Image
MarkusRost (talk) 17:06, 31 May 2025 (UTC)

But having actual versions will make it easier for users to understand. In fact I’d propose naming the “big” images in this fashion. Maybe it’s me preparing for the unlikely, but it will also safeguard us against having to renumerate all images in case some other texture is discovered in an old version. — BabylonAS 19:12, 31 May 2025 (UTC)

Oh I certainly agree with the reasoning, we already had the mess of numbering changes with Indev version pages. I just don't think we should introduce a new format just for the Invicon images, that should be changed consistently across all files. However it would be about of scope for this topic, which at this point should probably just be closed as "already implemented". -- 👁 Image
MarkusRost (talk) 19:21, 31 May 2025 (UTC)

Forum:Rethinking image revision naming. BabylonAS 08:09, 1 June 2025 (UTC)