Woohoo!
It works. Dunno why, but it works.
I just did a bit of testing. I figured since the default flatbed cargoes were being the problem last time I looked at this stuff, I should start with them and go through them one by one to see which ones were locked to CarSideView_1.
Found the answer.
None of them are. ![Very Happy :-D](./images/smilies/icon_biggrin.gif)
I got all of them loading perfectly with a custom car name and custom Profile.imb calling a custom profile icon. No problems.
So the obvious question now is why wouldn't it work before? This time around I did three things different.
1/ I made a custom .cct file for each cargo, calling a custom car name.
2/ I used a custom (out of the default range) car id number in the .car file at bytes 8 to 11 inclusive.
3/ I edited bytes 252-255 inclusive of the .car file to 00 00 00 00. These are the bytes which usually tell the game which part of CarSideView_1.dds the car will call for its profile icon. Setting them to all zeroes was my totally-without-rational-basis hopeful gesture towards not calling that image at all.
So which one of these three changes made the difference? No idea, and frankly don't care. It's probably either 2 or 3/ though, because I tried .cct files before. Anyway it's not important. This combination is bulletproof and easy to implement, and that's all that matters.
Bytes 10 and 11 in the .cct file, which define car type (as in boxcar, flatbed, etc) and are different to the car
name (which can be anything you want) can be set to either flatbed or boxcar without problems, with the same cargo. So for example, Weapons was loading fine in the custom car when its type was set to 11 (boxcar) and was still fine when I changed that to type 4 (flatbed). Either worked just as well.
So the obvious next thing to try was the CargoModel .3dp added into the mix. That was fine too. It seems that the game doesn't care what sort of car you are using when it comes to cargo models. If there's a cargo model file tied to that car name, it will be used. Easy. So I had the Weapons cargo model of grotty green guns poking out of the top of my test boxcar models, and it ran just fine with the car type defined as either boxcar or flatcar.
So this is all good. So far I have tested Aluminum, Automobiles, Bauxite, Clothing, Coal, Corn, Goods, Grain, Iron, Logs, Lumber, Mail, Passengers, Produce, Pulpwood, Rubber, Steel, Troops, Uranium and Weapons and they all work. It looks like the rest of the cargoes should work too (famous last words) so I'll check them to make sure.
-----------------------------------------------------------
Oh yeah, the only catch of course is that any cargoes that were on flatcars or in open hoppers by default were also not hooked into the cargo icon system, so if any of those cargoes are moved to a closed car type they won't have a cargo icon to tell you what's inside. This is not really a bug as such, and in any case is easy to work around with a bit of custom skinning. In fact, it would even be possible to hijack the default cargo models system to do the job for you.
All that would be necessary is to rename a copy of the CargoIcon file to CargoModel, and then edit a section of the CargoModels DDS to have the required cargo icons on it. Use the UV coordinates for the icon in question as the code in the CargoModel .3dp, and it would happily display the correct cargo icon as a "cargo model". This would be fail safe, because if the cargo in question has no hookup to cargo icons by default it just doesn't process that file. Ditto for cargo models. So the mesh for both could be superimposed, and the correct one should be visible with the other not being seen.