When building or placing a locomotive, players ought to have the option to choose between different model variants of that locomotive to include any variants added in the base mod or resource packs. This would allow different resource pack creators to create multiple versions of the same locomotive without one overwriting the other on a server.

If the resource pack creators assign different stats to the same rolling stock, perhaps a config option or CT script could allow players to choose which set of stats to use.

Possible with widgets or texture variants

Alternatively you could do what I did for my live steam pack. The br in the pack uses the same model, but with different stats and configurations. The way I avoided overriding each other is by having the json file names be different.

Yeah, but that won't work. OBJ/MTL pairs bind textures to a mesh. Also, the mod would still interpret that as separate stock, defeating the purpose of collapsing skins into 1 type of stock.

what do you mean it binds it to a mesh?

Each OBJ file references an MTL file. That MTL file references a set group of textures.

Intercepting and replacing the texture in memory would change ALL trains of the same type into the same skin, regardless of their scheme.

So, each piece of rollingstock isn't truly its own entity, but an copied instance, and in memory, the mod only loads one set of the rollingstock then just copies instances through the game in the world? Thats what I'm reading yes?

The problem is that the model is copied across. So if you used the same model, it could only have 1 texture set applied. The only way around this would be to remove the mtl file and individually apply textures in code.

So then, CURRENTLY, the only way to support different schemes and model variations would be seperate jsons calling out the modified obj files with their own mtl files. I wonder if there would be a way you could modify that.

correct. I mentioned the modification. We'd have to ditch mtl files.

Oh right, sorry memory made me think someone else mentioned that xD

Advantage is that legend could do challenger in multiple schemes AND have the option to do smoke deflectors/ no smoke deflectors

I had planned to do the same with the Camelback for "as delivered" and "As demoted" when they were demoted to branch service during the final years of their life, got a new tender, modified firemans porch....and would look a tad more rough

When one of us implements the mesh/skin swap, I'll collapse my F59PHI skins into one json. I think the original loader should only add the first one of each stock to the creative list as it is, because it iterates through type, not by currentSkin.

One idea I was considering for that was having the model location be an array, rather than a single item. We would iterate through using a "for-each-in" loop to get the variants. Then a brush item would be used to open a GUI for the loco that shows all elements of said array. The current value of the array pointer (activated skin) would be stored in the NBT as a "currentSkin" integer tag. (This would default to 0 if the previously used skin is no longer in the pack or the array shortens) The render system would render skins based on both the stockType and currentSkin tags.