Cargo weight revamping

[Gumboots]

Well hey, I have great admiration for their bug-creation skills. I would not put anything past such a talented and determined team.

Anyway having posted all that crud I then tweaked it (previous post is already corrected). If we go for 140% as the top level, and 8 levels, that brings us to 70% for the bottom level. This is an even half, so easy on the brain.

Even better, I just realised there's no need to use pax price events. Instead of worrying about editing every map to have pax price events, which would be a real PITA, we can just adjust the running costs of any loco which has a rating higher than 120%. This keeps all the adjustments in the .lco and .car files, so is backwards compatible with existing maps.

We can't go any lower than a 70% value for the bottom level or the sandbox time options start getting messier. I think it's important to keep the default "Normal day/night cycling" and "Frozen at midnight" at the start, just to make the interface reasonably clear.

[Gumboots]

Got around to doing some solid testing of the new express weights. Used the Express D'Orient scenario as it's one of my favourite maps, and has a good range of terrain and trip lengths.

First thing is that I noticed the bug in the caboose pack that Jim mentioned (it makes various bits go missing sometimes). I checked the packing files for the cabeesi and can tell that some of them were exported with mipmaps. These have 347 kb for the A skins instead of what it should be: 256 kb. Since RT3 is not coded to deal with mips as part of an image, it throws a bit of a sulk about them.

So I'll re-do all the skin images for the caboose pack. Some might be ok, but I'll do the lot just in case (it's not a huge job) and attach a fixed pack as soon as it's ready.

---

Second thing I noticed is that having the Mogul available in 1865 (with skinz even ) pretty much makes the default Connie redundant. The Mogul is 2 grades better for acceleration, and is $35k cheaper to buy, although it costs an additional $3k/year in maintenance. This means that over a 10 year life (which is about right) purchase+maintenance costs end up the same. The fuel consumption of both locos is identical, since they weigh the same and have the same economy rating. So in terms of total running costs there's no real advantage to either loco.

The Connie has a higher free weight value, and an additional 10mph top speed, but only the same pulling power. So overall the Mogul's better acceleration tends to balance out the Connie's higher top speed, except on very long runs with no interruptions. If the train has to stop to let another one past the Connie is back to 0 again, and the Mogul will take off faster from a standing start. I suppose you could argue that this is all good, in that you could use the Connie as a long run specialist and the Mogul for shorter hops, but for all I can notice in terms of stuff delivered they end up being interchangeable.

I think the stats for both should be adjusted. The Mogul's purchase price is about right compared to the Connie, but I can't see why the maintenance cost is so much higher for a smaller and simpler loco. I think it'd make sense to cut the Mogul's maintenance cost back to 7 or 8k/year. I also can't see any logic in giving them the same pulling power. I'd be inclined to rate them on the basis of adhesion. A Connie is 33% better stuck to the track (8 wheels instead of 6) so should be able to put down about 33% more tractive effort. OTOH Connie's top speed is too high, and should come back to 45 or 50 mph. So as a rough estimate boost Connie's pulling power to 6 (a 20% boost) but drop the Mogul's pulling power to 4.5 (10% drop) or even lower, and perhaps reduce its weight as well. And knock one or two levels off its acceleration, since there's no reason why it should accelerate faster than a Connie.

---

Third thing is performance of express locos. Without any changes to locomotive stats so far, the Stirling is transformed into something like what it actually was: a genuinely useful express choofer. I was running a dozen or so of them, some with full express consists (7 express + dining, no caboose) and these were going really well. They were even reliable enough to give decent service without the caboose. I found I could use them in mainline service right up until the start of the E era (1915), when the additional weight really made retiring them the best option. In the D era (1890-1914) they were still quite acceptable. Their good pax appeal rating made up for them being a bit slower point to point over undulating terrain than some of the others, and on flat terrain they were still able to hit top speed if given a decent run. On flat terrain I also ran some Stirlings with 4 express + 2 freight + dining car, and these did well up until the 1890's when I replaced them with S3's. This ties in with their actual service record, with withdrawals starting in 1899 and all of them retired by 1916.

The Atlantic also becomes useful with the new express cars, although I have only done limited testing with it so far. However, the Stirling and the Atlantic are still utterly useless as freight or general mixed traffic locos. Which was the whole idea. So more tweaks can and will be done, but the basic idea seems to be working so far.

[RulerofRails]

Yeah the Mogul always had that too-good-to-be-true feel on it's stats IMO.

The default locos with default express weights are actually not too bad (some engines are still high side) in running when used exclusively as Express engines. I'm not saying they are as good as they could be though.

However, the issue that comes up too often with the default game is where you don't have a good freight engine (your chart easily shows there are many more express engines in the game) so you end up using an engine designed for express. For NA locos, you've got nothing for Freight after the 1900 weight jump until the H10. So I forgive people for hooking up a Coal train on an Atlantic (I've done it on occasion).

Thanks to your focus on some more freighters and with no more asteroid-size weight jumps this problem is getting fixed.

[Gumboots]

IMO the Stirling has always been just too weak, even for an express loco. TBH it's now probably a bit too good. The improved reliability is handy though. It seems we can safely give pre-1890 express locos a Below Average reliability rating, and still have them give perfectly acceptable service hauling full express consists with no caboose. This applies even post-1890, when the express car weights are 5.1 tons. An Average rating would do it easily.

The other thing is that my 1.05 test installation was a bit of a mess, and I'd forgotten exactly which bits of which scheme had been implemented, so I set all the freights back to PopTop defaults for the latest test run. The express cars and the cabooses were still the new custom ones.

Anyway, default freights meant asteroids in 1900 but the Mogul still seemed to do ok. Even without a caboose. I suspect I am just idiotically happy with bouncing baby Moguls at the moment. But it's definitely alright with the default 7 ton B freights without a caboose, although the breakdowns are perhaps a bit more frequent than I would prefer. But with the new caboose being a more reasonable weight it's not such a penalty to use one.

So my current guesstimate is that an Average reliability rating will be ok for the new light freights pre-1890 (7.2 tons) without a caboose, but for the new heavy freights pre-1890 (10.8 tons) a caboose would probably be a good idea with that rating. Then when the heaviest freights jump to 15.3 tons in 1890 you'd definitely want a caboose for an Average loco, but could probably get away without one if the rating was Above Average.

[Gumboots]

Meh and bother. I just checked the skins for the express pack, and those were exported with mips as well. All of them.

Not to worry, it's only another 200 images that have to be done again. Fortunately it's just a matter of opening them in Photoshop and then saving them straight away, without mips this time, so it's not a difficult job at all. Just a few hundred clicks. The repacking is easy since I still have the .lst file set up. So that means a replacement express pack will be coming with the replacement caboose pack.

Since I have to do the cabeesi anyway, I was thinking I might destaurate the A, B and C skins to make them a bit less fire engine red and give a slightly more weathered look, without getting into weathering work as such. Am open to any other suggestions as well, as long as they are quick and easy.

[Gumboots]

Just taking a bit of a look at Stirling stats, since I have to start somewhere.

As mentioned, I think the default stats are a bit over the top with the new express cars. My feeling after playing a couple of games is that performance with the new C express cars should be about the same as the default stats give with the new D era cars. This would give a generally useful locomotive, but it would be feeling the pressure after 1889 (which is roughly what happened IRL). It would still be suitable for use with shorter consists after 1889, but would be basically obsolete after 1914 (which is also what happened IRL).

I also think the fuel bill needs to be as high as the default loco hauling default B express. For full consists with a dining car this averages out to 7.8 tons per car, due to the 13 ton weight of the default dining car. For longish runs and a priority setting, I figure about 1,000 miles is in the ballpark. That gives a default fuel bill of $32k, which seems about right for what I get in a game.

I think the default purchase price and maintenance cost are ok (open to counter arguments on that) so I left those alone and just looked at pulling power, free weight, loco weight, and fuel rating. I came up with three variations that give near-enough-to-identical performance in what I think are the relevant areas (5-8 cars, 0-5% grades).

If running without a consist due to lack of traffic, the 90 ton loco option with a fuel rating of 8 would burn a couple of K more fuel, over a whole year of running empty, compared to the 67 ton loco option with a fuel rating of 10. Which you may not notice anyway. It's literally only about $2k difference with no consist at all for an entire year, and they're even if pulling 8 cars.

I mention this because RoR and I had been discussing the best use of loco weights and fuel ratings. I'm now inclined to think it may be less important than we thought, and that there won't actually be a need to use the Very Poor and Atrocious ratings in combination with extreme low locomotive weight. Although that will certainly work too, if anyone wants to do it that way.

Anyway shots of the stats follow. I've provisionally boosted the top speed to 85 mph on the basis that the Stirling was known to hit that with short consists. "Free weight" is reduced to bring speed with full consists back to 74 mph, which again corresponds to the loco's real life performance (it was known to haul 26 cars of the period at 75 mph). Acceleration is left alone.

I think reliability should be boosted, since one of the key aspects of this design was its simplicity and strength. It was deliberately designed to be more reliable than common locos of the time. The combination of fuel rating, weight, purchase price and maintenance cost gives this loco an optimum replacement interval of 13 years. IMO it makes sense to give it a reliability rating which ties in with that timeframe, which would be Above Average. With the consists it will be hauling, that rating should keep it trundling along for 15 years without a caboose.

[Just Crazy Jim]

Taking into consideration that there were 4 readily available pigments for making red paint before the 20th century: Crimson, Carmine, Red Ochre, and Ox blood, the image is based on restoration work at Colonial Williamsburg and Historic Jamestowne in Virginia. But, the methodology of making paint did not change at all between 1600 and 1880. Paint, until 1880, was made as needed and you made it yourself with whatever you had handy.

PeriodPigments01.png (9.9 KiB) Viewed 8611 times

Crimson comes closest to what we usually think of when we say "red" in the modern era, but it was ungodly expensive, Carmine was also expensive, so I would scrap both of those. Red ochre was cheap and very easily obtained, but was somewhat like lime whitewash in that it didn't weather all that well and always had a powdery loss layer. Ox blood made a superior paint because of the proteins in the blood, so it held up better than red ochre, but ox blood was only available seasonally during the cold part of the year when animal slaughter was done.

"Red" in any period before 1900 usually meant "red ochre" or "brick red".

Edit: Cinnabar is a mineral salt of mercury that was sometimes used, but it resembles Oxblood enough that I didn't make a color swatch for it.

[Gumboots]

Ok cool. Oxblood it is. Or oxblood with a bit of red ochre in it. Whatever looks good in Photoshop (as per approved 19th century specs).

I can't see anyone going to the expense of cinnabar on a caboose, but I'm familiar with the colour. It's the standard red pigment for traditional Chinese carved lacquer work: https://en.wikipedia.org/wiki/Carved_lacquer

I don't think it's anything like your oxblood swatch myself. Cinnabar has a very distinctive colour.

[Just Crazy Jim]

There's some variation in the color of cinnabar, the most common kind in Europe, hepatic cinnabar, being the one most often used for paint in Europe, is more like oxblood - a sort of purple-red or brownish-red. The Near East and Chinese have "true", "superior", "Arabian" or "Chinese" cinnabar, the more orange-red variety (there's some variation, but it's pretty similar to red ochre and costs far, far more), and, indeed, the Chinese prefer it for their lacquer work. But during the period, they would have likely made a point of saying "Chinese red" to indicate paint made from the higher priced pigment. I can't find a cost for it from the period, but there is one receipt from 1904 for a pot (one gallon ?) of "Chinese red"... £39 10/6, about £3,857 or US $4,742 in modern money. It has certainly gotten cheaper.

Also, there is some effect on how the end result looks from the binding or fixing agent. Lacquer and varnish keep the pigment in a fairly high chroma value (much like the "wet" look of paint), if it's blended with lime, you end up with a pastel, and then there's oxidation to consider that dulls the pigment (lowers chroma value) and so on.

[Gumboots]

Had a quick play with it and came up with this, which I think is fairly close-ish, if you squint at it, in the dusk with the light behind it.

Voila! One rich attorney's elderly ugly caboose.

Haven't had time to check it under game lighting yet, but it's definitely less lurid than the default next to it. I think one of the main problems with some default skins is the amount of contrast between "highlights" (which are really "Zomg got smacked upside the head with the disco spotlight") and t'other bits.

I had to really wind back the contrast on the base skin for the caboose sides to get this result. That's had the unfortunate side effect of making the window and door frames less distinct, but getting them more distinct without a complete reskin is tricky. I might try magic-wanding out the red stuff and hopefully keeping the dark stripes (between boards, etc), then using that as an overlay to bring back some more contrast where I want it.

Meh.

[Just Crazy Jim]

The tip I am going to impart here is one of limited usefulness. It really hangs by the nail of the over all contrast of the base texture. Sometimes this is a quick and dirty that works, mostly not, but when it does, it works a charm.

Method 1.
• Make a new layer by copying the base texture.
• Desaturate and lighten each color individually using the Hue/Saturation Adjustment tool.
• Adjust the Contrast/Brightness to set the grey mid-tones to white, but keep the shadows (etc) a deeper grey.
• Change layer property to "Multiply", tinker with opacity until you like it.

Method 2.
• Make a new layer by copying the base texture.
• Use the Threshold Tool, tinker with the slider until it's close to what you want.
• Change layer property to "Multiply", tinker with opacity until you like it.

[Gumboots]

Ok thanks. I'll give those a whirl later. I just tried my idea, along with a couple of other tweaks, and it's a definite improvement. I'm inclined to think it may be good enough for now. Game lighting permitting, of course. I'll throw it into my installation tonight and give it a go.

[Gumboots]

Just got around to playing with these again. Tried your suggestions but couldn't get a result I liked quickly, so I had a look at some of the other tools. The Shadows/Highlights tool turns out to be very useful.

I left all settings on default apart from Midtone Contrast. Boosting that up (counterintuitive, but it works) evens out the disco lighting nicely. After that a slight overall drop in saturation and lightness and a slight adjustment in hue, all three courtesy of the Hue/Saturation tool of course, and the overall result is quite respectable for what it is. I'll defo try this in the game to see if it looks good there too.

And I'm sick of having this cargo scale revamp looming over me. I want it done so I can get on with modelling and skinning stuff I like. Have decided on another approach to get past the Valley of Death.

Rather than trying to design the optimal system and then finding the .exe won't let me implement it (which I am totally over at this stage) I'll take a look at what the .exe will let me do without it being a huge quest for obscure lunacy. IOW, stuff that is easy and fast and makes sense. I can do the hex coding and modelling and skinning no worries. I just don't want to waste endless amounts of time trying to circumvent idiotic booby traps in odd places. If they've set booby traps anywhere (and they certainly have) I'll just leave those areas alone and get on with stuff that actually is amenable to customisation. This will most likely mean a less-than-optimal system is what ends up being used, but less-than-optimal is another way of saying "optimal, taking into account that game devs are evil and customisers don't have million year lifespans". At this stage, "optimal" is a playable result.

[Gumboots]

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. 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.

[RulerofRails]

That's great news!

PS.
I managed to fiddle with some files to get a rough mock-up of the new scale working (uses boxcar, heavy boxcar, covered hopper, and reefer for the 4 different weights in use at any time on the latest scale). I high-jacked existing types so I didn't have to mess with model files. Don't know why I didn't try to do that before. Now I've got to go through and update the Express files to the latest weights. Then I can do full-scale testing.

[Gumboots]

I'm going to do a bit more testing of .car ID numbers (bytes 8 to 11) to see if there are any limits there. I suspect it's open-ended, which would be handy if true. I know the stop year bytes in the .car allow 0F 27 00 00 (year 9999) and use that by default for the last era, so with a bit of luck the same will apply to the ID number bytes. What I'm thinking is I should implement and document an organised system for this, just so there are no conflicts in future. I had such a thing already planned:

Code: Select all

    Cargo name          .car ID (A era to last era)
--------------------------------------------------------------

    Box                 11 01 00 00 - 18 01 00 00

    Covered_Hopper      31 01 00 00 - 38 01 00 00

    Flatbed             51 01 00 00 - 58 01 00 00

    Open_Hopper         71 01 00 00 - 78 01 00 00

    Reefer              91 01 00 00 - 98 01 00 00

    Tanker              B1 01 00 00 - B7 01 00 00


    Alcohol             A1 02 00 00 - A8 02 00 00
    Aluminum            B1 02 00 00 - B5 02 00 00
    Ammunition          C1 02 00 00 - C7 02 00 00
    Automobiles         D1 02 00 00 - D5 02 00 00

    Bauxite             E1 02 00 00 - E5 02 00 00

    Caboose             F1 02 00 00 - F8 02 00 00
    Ceramics (1.06)     01 03 00 00 - 08 03 00 00
    Cheese              11 03 00 00 - 16 03 00 00
    Chemicals           21 03 00 00 - 25 03 00 00
    Clothing            31 03 00 00 - 38 03 00 00
    Coal                41 03 00 00 - 48 03 00 00
    Coffee              51 03 00 00 - 58 03 00 00
    Concrete (1.06)     61 03 00 00 - 67 03 00 00
    Corn                71 03 00 00 - 78 03 00 00
    Cotton              81 03 00 00 - 88 03 00 00
    Crystals (1.06)     91 03 00 00 - 98 03 00 00

    Diesel              A1 03 00 00 - A6 03 00 00
    Dye (1.06)          B1 03 00 00 - B8 03 00 00

    Electronics (1.06)  C1 03 00 00 - C5 03 00 00

    Fertilizer          D1 03 00 00 - D5 03 00 00
    Furniture           E1 03 00 00 - E6 03 00 00

    Goods               F1 03 00 00 - F8 03 00 00
    Grain               01 04 00 00 - 08 04 00 00

    Ingots (1.06)       11 04 00 00 - 18 04 00 00
    Iron                21 04 00 00 - 28 04 00 00

    Livestock           31 04 00 00 - 38 04 00 00
    Logs                41 04 00 00 - 48 04 00 00
    Lumber              51 04 00 00 - 58 04 00 00

    Machinery (1.06)    61 04 00 00 - 67 04 00 00
    Mail                71 04 00 00 - 78 04 00 00
    Meat                81 04 00 00 - 88 04 00 00
    Medicine (1.06)     91 04 00 00 - 95 04 00 00
    Milk                A1 04 00 00 - A8 04 00 00

    Oil                 B1 04 00 00 - B7 04 00 00
    Ore (1.06)          C1 04 00 00 - C8 04 00 00

    Paper               D1 04 00 00 - D8 04 00 00
    Passengers          E1 04 00 00 - E7 04 00 00
    Plastic             F1 04 00 00 - F4 04 00 00
    Produce             01 05 00 00 - 08 05 00 00
    Pulpwood            11 05 00 00 - 18 05 00 00

    Rice                21 05 00 00 - 28 05 00 00
    Rock (1.06)         31 05 00 00 - 38 05 00 00
    Rubber              41 05 00 00 - 45 05 00 00

    Steel               51 05 00 00 - 57 05 00 00
    Sugar               61 05 00 00 - 68 05 00 00

    Tires               71 05 00 00 - 75 05 00 00
    Toys                81 05 00 00 - 86 05 00 00
    Troops              91 05 00 00 - 97 05 00 00

    Uranium             A1 05 00 00 - A3 05 00 00

    Waste               B1 05 00 00 - B2 05 00 00
    Weapons             C1 05 00 00 - C7 05 00 00
    Wool                D1 05 00 00 - D8 05 00 00

The important thing here being the hex code. Since it has to be done in hex anyway, it doesn't make sense to do the instinctive thing and define the number ranges in decimal. That would just be a nuisance for anyone who works on it in future, because they would have to convert from hex to decimal to understand the floats in the files.

So the real no-brainer option is to make the hex easy. If each cargo or car type starts its A era at 01 xx 00 00 and goes from there in a simple progression (01 xx 00 00, 02 xx 00 00, etc) then you would know what number to use just by what era you wanted to work on. Or by looking at the number you'd know if the era was right, or whatever. This allows up to 16 eras for each cargo, which is hopefully more than any sane person will ever want.

So put the generic (multiple cargo) car types first, with gaps between them in case we ever want to implement stuff like heavy and light boxcars, then have all the cargoes listed in alphabetical order and each with their own clear hex range. Since 1.06 has the maximum number of cargoes this should be fine. If anyone wants a custom cargo they can figure out a sane hex range for it themselves. The xx 06 00 00 range would be the obvious place to start.

Should really do the same thing with custom locos too. I might assign myself xx 0A 00 00 range for those.

I'm also thinking that since the .cct file apparently doesn't care what car type number you define there as long as the car name is correct, it probably makes sense to set them all to 11. That's boxcar, but it's an easy one to remember and to type. One less thing to worry about.

[Gumboots]

That's great news!

PS.
I managed to fiddle with some files to get a rough mock-up of the new scale working (uses boxcar, heavy boxcar, covered hopper, and reefer for the 4 different weights in use at any time on the latest scale). I high-jacked existing types so I didn't have to mess with model files. Don't know why I didn't try to do that before. Now I've got to go through and update the Express files to the latest weights. Then I can do full-scale testing.

Yeah that's a good idea for a quick test set.

I'm going to get back to whipping up a more substantial test set that will be pleasing enough to serve as defaults for a while. I had them largely sorted before I got the grumbles at stupid RT3 and temporarily gave up in favour of more rewarding things. This is supposed to be fun, y'know.

Anyway now that I know it can all be made to work, and apparently without headaches even, I'll see what I can come up with for a more polished set. Including new A era pax and mail of course, so we don't have to use those daft shopping trolleys. Then we can just get on with having fun with trains.

[Gumboots]

Just ran through the rest of the cargoes. They all work. Profile icons are fine. Cargo icons are fine. Models on tracks are fine. So that covers all 1.05 cargoes.

I expect that it will also work for all 1.06 cargoes, apart from the known bug with them that they aren't properly hooked into the cargo models and cargo icons systems. I remember that for some reason the 1.06 Dye cargo is hooked up to the icon for the deprecated Beer cargo, which always looks hilarious when you get tankers full of beer on the tracks. That could be fixed by editing CargoIcons.dds, but it might be more fun to leave it the way it is.

IIRC the rest of the 1.06 cargoes just don't call any cargo model or cargo icon at all, so would have to be dealt with by custom skinning of cars. Not that anyone seems to have bothered so far.

[Gumboots]

Have got all the CargoTypes files set up correctly now, for all cargoes, and am about halfway there with the EngineTypes files. Will do some more tomorrow night, but should be able to knock over the rest of EngineTypes then.

After that it's simply a matter of how much time and energy I want to throw at modelling and skinning. If I manage to control my baser urges*, and just do the absolute minimum required for testing at this stage, I should be able to get a complete test pack done pretty quickly.

*This is the really tricky bit. 85 foot double-decker stock cars are cool.

[Gumboots]

Got the rest of the EngineTypes files sorted, and found some earlier mistakes in the process. Fixed those too, of course. There will probably still be a couple I missed, but that's what the Bong of Doom was invented for.

So the next thing is packing asset files for in-game testing. I'm going to follow the same plan as I did for the express and caboose packs, namely keeping things close to default in terms of modelling and skinning just to get it operational. I'll add some custom stuff that I have ready to go (like the minor bugfix for open hopper cargoes) but at this stage the test pack will generally be clean, but basic. Fancy stuff can be done later.