Rolling Stock skinning ideas

[RulerofRails]

Nice. If it was running in game . . . it's good enough for me to use it.

[Gumboots]

It's a bit rough for a finished product, although I admit it would look decent enough when zoomed out.

[Gumboots]

Just had a go at the proposed G era double boxcars, since I figure I should finish some more cargo cars. They work, but I found another RT3 bug/glitch/whatever.

These are the doubles that use two different sized cars: a 40' PS-1 and a 50' X58. Obviously both are mapped to the same skin. Anyway, although they trundle down the track like they should, the catch is that they are scrunched into the back of the tender at the front, and there's an excessive gap to the caboose at the rear.
.

.
What is happening is that although I set the body origin exactly centred between the inner ends of the two boxcars, because the front one is longer than the back one the game engine tries to even the lengths out. The halfway point between the outer ends of the two boxcars is shown by the Blender cursor in the middle section of the screenshot.

What's happening is that RT3 is shunting the cars forward so that their outer ends are centred around this point. Despite this, the LengthPoint and TrackPoint files are not affected. They work normally, AFAICT, because the front of the first boxcar is protruding out past where the front length point is.

This all means the front boxcar gets shunted into the tender, and the back one will have a large gap to whatever is behind it (caboose, in this case). The way to fix it, obviously, is to reposition the boxcars so that their outer ends are centred on the Y=0 point. Which I will do shortly, then test again.

[Gumboots]

Alrighty then. Shunted the model bits around, exported them to .3dp again, sorted the hex attachment/length/track points, and gave them another run in the game.

It works. They behave perfectly now, which is gratifying since I was a tad concerned RT3 might do something even weirder this time. Fortunately, it didn't. Not this time. So, we now know how to do multiple units with unequal length cars: simply set them up so that the outer ends, or outer wheels, are centered on Y=0. Easy.

I have noticed one catch with another idea though. I also tried adding a transparent rectangle to the body file, in the hope that would give a large, easy-to-hit, non-visible target to allow seeing the cargo type just by hovering over the gap between the first and second cars. Turns out the devs very helpfully coded things so that hovering to see cargo type only works on non-transparent pixels. Transparent ones aren't visible to the cursor, so that idea is cactus.

This means the only ways of seeing the cargo type are a/ hover the cursor over the middle bogie, which works but is tricky on a moving train, or b/ look at the cargo icon if it's a cargo which has one available, or c/ use some custom skinning of various cargoes if necessary, or d/ check it out in the train list profile. Which is all workable, just not quite as convenient as I would have liked. It's RT3. You get that.

[Gumboots]

Hey just on a whim, because I've been using Camelbacks as shunters* the last day or so, I got to thinking about a quick and easy revamp. The Camelback is one of the default models that is just a bit too rough IMO. The octagonal smokebox and candy cane paint job are a bit more than I can stomach for normal use.

Fixing the paint job isn't a big deal. Fixing the basics of the mesh, without going crazy pedantic everywhere, is also pretty easy. I had a quick go at the mesh just for fun, and it looks a lot better.
.

.
This could easily be combined with a revamp of the stats. The default stats are:

Available: 1896-1926
Purchase price: $80,000
Annual maintenance: $7,000
Fuel economy: Very Good
Acceleration: Poor
Reliability: Average
Pax appeal: Ugly
Top speed: 60 mph
Free weight: 30
Pulling power: 5

For re-purposing as a good shunter, these could be changed to:

Available: 1896-1956
Purchase price: $80,000
Annual maintenance: $7,000
Fuel economy: Very Good
Acceleration: Above average
Reliability: Good
Pax appeal: Gruesome
Top speed: 23 mph
Free weight: 120
Pulling power: 6

This would be perfectly usable for short hops between stations, but too slow for trips of any distance. It would be reliable enough to haul freight of the era without a caboose (caboose on shunters seems stupid) and would be strong enough to haul it at top speed on flat terrain, while being about the same as the default stats up hard grades (ie: pretty crap). It would also be cheap to run, which is important for a shunter as any cargo price differentials are going to be minimal.

If it's done like this, suddenly the Camelback has a valid use in the game, and one that fits with how similar locomotives were used IRL.

*The game's beastie is a Reading B7a, very roughly done, and they really were shunters. They were useless for anything else. Some were in service until the early 1950's.

[Gumboots]

Got it running. I like it.

They make an excellent shunter with these stats. Would also be an acceptable little unit for freight on short branch lines. Too slow for long distances though, which is what was intended, and not so good on heavy grades. They're best suited for grades of 3% or less.

Since this is probably the first time I've used Camelbacks since Noah was a lad, on account of the default one being so ugly, I just noticed that it has a few minor bugs. Wheels are a bit oval, RHS connecting rod hex needs tweaking, and there a couple of other very minor niggles. I'll whip something up to fix all of that. Since the default files are hidden in some of RT3's massive PK4's, I'll just do the reskin and debug kit as loose files for dropping into UserExtraContent. They have to be loose to override the contents of a default PK4, so that's the sensible option and will save having to repack half the game.

Anyway, with a bit of tweaking the Camelback actually becomes fun to use, so I'm going to be using it.
.

.

.

.

[AT41B]

I was just looking at the Camelback, cabin not painted in red, and I remember when I was a preteen, there was a loco that moved cotton to and fabric from the textile mill. It’s track was about 90 yards from my house. It looked very much like the camelback. It made a daily run to and from. It also served the farm implement manufacture and fertilizer plant that was within a half mile from my house.

[AT41B]

these were local yard tracks. The main lines here then were NC&St L, Southern, and L&N railroads. Oh BTW, this was in Huntsville, Alabama in the late mid to late 40s.

[Gumboots]

Cool.

Apart from the Wootton firebox it's just a basic 0-6-0 switcher, and there were stacks of those things running around yards and docks in the late days of steam. Offhand I don't know what the railroads in your area used, but it probably wouldn't be hard to find out if you wanted to.

[RulerofRails]

It looks much nicer now.

Using shunters is a concept that I haven't experimented with mainly because I don't often do multiple stations. I have always viewed short-haul count/revenue to be more of a "cheat" although probably better classified as an exploit. In saying this, there are some exploits I do think are ok to use, like buying/selling shares will game is paused when I get a bonus/buy territory access, cargo stacking. Just have trouble with the notion of hauling a few cells and getting paid for it in a process that can loop endlessly.

With overlapping stations there is the practical risk that this movement may upset industrial production (not really a concern on Riga map), since the station further from the industry can rob its stack of resources repeatedly. This is not really in-line with a low-impact plan to manage resource flows for maximizing industrial production. One could argue that it's good for rail profits, but you may not haul as much of the finished goods. Of course, for high haulage tasks this doesn't matter.

Anyway, IMO your tune ticks the boxes, except that if you really want to limit it to short-hauls you should increase fuel costs which are based on mileage. Should be higher than a freighters. You set the H3 at level 6, so I would suggest using level 7.

[Gumboots]

Yes I think you are right about the fuel cost. The Riga shunters were only burning about $7k/year of fuel. It could easily be tripled, which is what would happen if you changed the current Very Good fuel rating to Below Average. That should still allow shunters to make over $100k/year.

I'll check some of the stats for the ones on branch lines too, since I also want it to stay usable in that application.

[Gumboots]

Hey I had a brainwave. Check this.
.

.
Since the Pennsy H3 skin is already set up with layers and styles, and since some components which are transferable to the Camelback (wheels, etc) are already set up with UV mapping, there's an obvious quick and easy way of getting the Camelback looking slick.

The current screenshot is just bits of Camelback mapped to an unaltered Pennsy skin, along with the transferred wheels and drivetrain from the H3. It will need some tweaking of the skin here and there, but as it's mainly a matter of shifting and scaling some layers and changing a few colours it shouldn't be a huge gnarly deal.

The other advantage is that it won't need separate images for loco and tender. I was already thinking of doing the Camelback as a "double", with the loco and tender as two trucks, similar to the double cargo cars. Since it's so short, and since the loco/caboose combo goes weird around tight corners in RT3, the Camelback seems an obvious candidate for this treatment.

This means it will be possible to have double-headed Camelbacks.

[Gumboots]

Have been playing around with spreadsheets a bit, trying to balance stats.

Since the Latvia scenario was what got this thing started, the obvious question becomes: how does it compare with the S3 and P8 with that era's cargo?

After playing around some, I think I've got it sorted. With these stats the Camelback is about 10% cheaper to run than the P8 if annual mileage is low, but the P8 is about 10% cheaper if annual mileage is high. Obviously the speed advantage of the P8 makes it a no-brainer for longer runs, but the better acceleration (albeit to a lower top speed) and cheaper running cost for short hops will give the Camelback a viable niche.

Available: 1896-1956
Purchase price: $80,000
Annual maintenance: $5,000
Fuel economy: Above Average
Acceleration: Above Average
Reliability: Good
Pax appeal: Gruesome
Top speed: 23 mph
Free weight: 110
Pulling power: 9
Locomotive weight: 110
Tender weight: 0

Compared to the S3, the Camelback is always much cheaper to run but not nearly as fast with light loads on fairly flat terrain. However, it is as fast as the S3 up heavy grades. The S3 is still viable for intermediate pax service, where its good top speed with a light load and much better acceleration than the P8 give it an edge.

Haven't done a comparison to the Class 500 yet. I don't tend to use many of those anyway, due to their lower reliability. They need a caboose to operate reliably for any length of time, which cuts paying load compared to the others.

A quick and rough check against the Pennsy H3 stats indicates that the Camelback will work well with that locomotive too. Same deal: Pennsy is better for long hauls due to its speed, although it's more expensive to run. Camelback is better for short hops, due to being cheaper to run.

[Gumboots]

If anyone wants to test this out, I've added a zip with the relevant files. Note that this is the basic revamp as shown back in this post. I haven't got the flasher skinning (and new wheels, etc, etc) done yet, but even the basic revamp makes the thing much more appealing to use.

Also included are EngineTypes files, with the same stats as mentioned in the post just above. The only difference is that I decided to leave the stop year at the default 1926, since that will mean no possibility of conflict with events in existing scenarios. Naturally, the new Latvia map includes an event to make the Camelback available after 1926.

[Gumboots]

Had an idea this morning for a bit of fun. Those ships I was messing with a while back got shelved because it was pretty much impossible to make the tracks look decent when playing, and also due to several other issues. The whole moving-ships-carrying-cargo thing would really only work if an entire scenario and its assets were developed specifically for shipping. Which is possible, but gets to the point where you might as well buy a game that has working ships.

However ships for eye candy in RT3 is a piece of cake. Turns out the A skin for docks is 512x512. Since the game handles 1024x1024 without dramas it would be simple enough to shunt the dock's UV mapping to the corner of a 1024x512 or 1024x1024, and then have the rest of the image available for extras.
.

.
So I might whip something up for this sometime. The extra poly count wouldn't be an issue, and it would be kinda fun.

[Gumboots]

This is not rolling stock, but I couldn't be bothered starting a new thread. Windmills. Juriko included some in his original Latvia map, and they are apparently a traditional thing over there (get used as logos for lots of products) but the "space age" version that comes with the game doesn't really fit the 1930's. It's not even a good representation of real modern turbines, which have much more practical styling and structure. So I started wondering if anything could be done with the PopTop version.

It has the usual body .3dp file for the base unit, but the prop is done with RT3's mysterious Anim files. These come in pairs: upper case first letter "Anim1" and lower case first letter "anim" without the 1. The Anim1 does the prop's mesh and the other one (and I have no idea how it works) makes the prop turn around slowly.

So I looked at the hex for the Anim1 and it seemed to have the usual attachment point like any other .3dp file even though it had a different header. The attachment point, or pivot point, had hex that matched the centre of the prop's hub so I thought maybe it just works like wheels. As a quick test I took the prop's mesh, rotated the existing three blades around the hub until they were 90 degrees apart instead of 120 degrees, then added a fourth blade. I then moved the whole thing vertically down by 30 units, which is about as close to the ground as it can go. Exported that as a .3dp and edited the new pivot point height in, and dropped the file into UserExtraContent to see what happened.
.

.
It works. Obviously the prop no longer lines up with the base structure, because I haven't touched that mesh yet, but they are four-bladed props and they turn nicely around their centres at the same speed as the originals. This means that if anyone wants to it is possible to hijack the PopTop windmill files to make anything that uses a similar basic structure and motion. For example, if for some weird reason you wanted a water mill it would be easy to make.

The obvious question now is are there any useful ways that other anim.3dp files can be hijacked? Just off the top of my head, the Auto Plant has them to move little cars around, and the Lumber Mill has them to move logs around, so maybe we can have cows wandering around our fields. Not that I would be likely to bother with cows, but just as an example. I'm sure it's possible with a bit of experimentation.

Edit: Oh and the other things is can Anim1 and anim files be used on moving objects? Can you add extra animated bits to locomotives? Probably not, but it may be worth trying. The in-game aeroplanes don't appear to use anim files, or not that I can see.

[Gumboots]

I had an idea which might work for revamping of default PopTop Locomotives. Could work with other assets too. It's pretty obvious in retrospect so I'll have to test it soon.

The hang-up with default locos is that you can't pack revamp files into PK4's if you want them to override the default files, which means you can end up with a lot of loose files floating around. This bugs me since I'm always pigging around in those folders testing things. Much better if everything can be neatly packed.

So the idea is that although the default loco name has to be kept for backwards compatibility with existing scenarios, the rest of the naming in the .lco and .car files might not have to be the same. If it doesn't (and given RT3 coding it may all turn to crap) then the way around the problem would be easy: just rename the .3dp and .dds files and change the calls in .lco and .car to suit, while leaving the default loco name and ID numbers alone.

If that works (and doesn't all turn to crap just because it can) then it would be easy to revamp default .3dp and .dds files, and still be able to pack them up the way we want them. Which would be very cool. I'd much rather have a Camelback.PK4 than a pile of loose files.

I'm gonna try this and see what explodes.
.

---

.
Hey it works! Nothing exploded. The game just ran normally, and recognised the Camelback even though it was calling different .3dp and .dds files with different names. All the CamelbackL files were renamed to CamelbackGBL, and all the CamelbackT files were renamed to CamelbackGBT. The relevant bytes in the .lco and .car files were changed to match, and that's it. Only took a few minutes.
.

.

.
This is great, because it means bugfixes for most default assets can be packed up nice and tidy. There may be some exceptions, but offhand I can't think of any.

It will even be possible to have bugfixes for multiple default assets in one PK4, because the game doesn't care what a PK4 is called or how many thing you cram into it. All the game cares about is that the files inside the PK4 have the correct syntax and calls everywhere. So a Camelback bugfix could be packed with a Penn462 bugfix or a Connie bugfix or a Big Boy bugfix, or anything else, and it should be fine with one Fixes_for_cruddy_PopTop_choofers.PK4 sitting in PopTopExtraContent. Or they can be done as separate PK4's. Either way will work.

Dunno why I didn't think of this before. In retrospect it's a no-brainer.

[Gumboots]

I was looking at the default port & port upgrade models in Blender, and after a bit of thinking realised it would be possible to save enough tris to easily cover one ship. This is without making the port itself more basic. It's just different use of mesh to amalgamate a lot of pointless faces into fewer separate units, by taking advantage of a bigger texture image (which would be needed to add ships anyway). It may even be a bit better for performance, because it would get rid of a lot of draw calls.

[Gumboots]

Got to thinking about flatcar cargoes again. The default PopTop weapons cargoes bug me, at least the late era ones do, and the thought of having to do anything with them was an irritation. Obvious solution: don't anything with them, and do something else.

Some time back I mentioned the idea of using missiles for late era weapons loads. They fit the post-WW2 timeframe, and I figured they would be easy to model and skin. Turns out they are. Started out playing with the idea of using Tomahawks. I've never seen pix of these being shipped on flatcars, presumably because the military don't want people nicking them, but this is RT3 so why not? Tomahawks are easy to model and skin, being basically just just a hemisphere with a tube stuck on it and a couple of fins. Engine nacelle too, but that's not a big deal. After playing around with it a bit I got 6 Tomahawks stacking nicely on a 75 foot flatcar. All good.

Only catch is that the poly count was getting up over 900, which is a bit more than I'm really happy with for a cargo car. Obvious solution: shorter flatcar and not as many Tomahawks. Four of them fit nicely on a 60 foot car, and the poly count is much more reasonable. It'd probably be possible to get away with the higher-poly 6 missile car, because it's rare to ship oodles of loads of weapons anyway, but having a lower poly option makes sense.

Tomahawks only started being deployed sometime in the 1970's, so they really fit the post-1990 time slot for my cargo revamp scale. That's when they've had the most use. For the period before that something else is needed, so I looked around a bit and found drawings for the old Nike Hercules. These were first deployed in the late 1950's and were in service until the late 1980's. This thing also turns out to be easy to model and skin, and has the advantage of seriously looking like a weapon. If I saw one of these heading towards me I'd definitely get the impression that somebody wasn't happy. It fits nicely on a 60 foot flatcar, only has a poly count equal to the two default PopTop post-1950 guns (or less than two Tomahawks) and looks a lot better. It would even be possible to bung two of them on an 89 foot flatcar and still have slightly fewer polys than a 60 foot car with four Tomahawks.

[Gumboots]

Played around with it some more. Managed to cut the polys on the Tomahawks and Nikes without making them look gruesome. Then I started thinking some more about arrangements on flatcars, and wondered what other missiles were around. I've pretty much settled on this one for the 21st century era: https://en.wikipedia.org/wiki/BrahMos

It's an interesting piece of kit, and it seems to work, and it looks better than Tomahawks and can be done with fewer polys. It's also easier to skin. Half a dozen of these things looks good on an 89 foot flatcar, so I'm going with them for post 1990 and the double Nikes on an 89 for 1965-1989. If I'm gonna do this stuff, I gotta have fun with it.