Another Connie (coz we need an uglier one)

[Gumboots]

Yeah I had fun with it. The first couple of attempts looked rough as guts, so I decided defeat was not an option.

The only catch at the moment is the rope that runs to the cab so you can ring the bell. It would have to run in a natural catenary for looks, but it's really thin, so with the binary alpha you have to use the result is that it would look like jaggy crap. The only way around that would be to segment the mesh and make it out of a dozen or so really skinny tris. Which is possible, and TBH wouldn't be that much of a performance hit, and can be dropped on the first LOD anyway. But then how far do you go?

Edit: Just tried it, as a last gesture before I have to go do other things. This has an additional 28 tris to do the two bell ropes, which is about as few as you can use to make it look convincing. I might throw them in just for fun, but details like this can rapidly add a lot of tris if you get into them. Maybe we could afford one or two. I must say it does look cool, and really helps bring the thing to life.

[Gumboots]

Got some more done. I feel like it's on the home stretch now. It won't be getting bell ropes either. I've set a limit of 1,500 tris just to see what can be done within that, and the last few will be better used for other things. Still looks ok though.

[Gumboots]

More bits on the beastie.

I finally noticed some things about the original, which I somehow hadn't noticed even though I've had pix of the thing for ages.

There is no handle on the smokebox door. The numberplate stands off the door on studs, and acts as a handle. So why was I messing around with a stupid handle? I'd just assumed it must have one. Anyway it doesn't now. I just used the same two tris to do it properly, and it looks much better.

Got some windows in the front of the cab, even though they still need refining. In fact the whole thing needs a bit of cleaning up and balancing, but I can see the light at the end of the tunnel and in this case it really is an oncoming train. Which is good. I think the skinning is now close enough that it's time to test it live for balance before applying the grunge, so I'll whip up the required hex files in the next day or two.

And yes, I know the smokebox door still needs hinges.

---

Notes for anyone who wants to do skinning:

I'm finding out more about what Photoshop can and can't do at this scale. It has some odd quirks.

There's the obvious stuff like not being able to do lining finer than one pixel. The painters don't have any half pixel brushes in their kit, so one pixel is what you get. This means I can't really line off the cowcatcher the same way as the original, because the lining would take over most of the area of the slats. What I've had to do is use single instead of double lining, and make the slats slighter wider than they are IRL. This looks the part, even though it's not quite kosher, so that's good enough IMO.

There's other stuff which is weirder. Some of the lining is done by just whacking down a basic raster rectangle, setting fill to 0%, and putting an inside stroke around the thing. Same deal with a vector rounded rectangle too. Quick and effective. The weird stuff comes when you try to re-size them to adjust the looks. Although I'd expect a raster rectangle to automatically snap to pixels and stay clean, in practice it doesn't. Dragging it for size makes it all go muddy. The way that works is to use crop or fill to extend or reduce the layer. This is still quick and easy now that I know.

Vectors are a bit trickier. They will drag to a new size cleanly only for some values. You have to mess around with them and nail it right on the pixels, otherwise (being vectors) they don't care about pixels and it all turns to mud again. I'm finding it's just about as quick and easy, and guaranteed clean results, to just whip up new vectors to guides.

[Gumboots]

Have started exporting .3dp files. All tender files have been done. Have knocked off the.lco and .car file for EngineTypes, and LengthPoint, TrackPoint, Smoke and Steam files for the locomotive .3dp's, and have the bogies and drivewheels ready to go. The rest shouldn't take long. I am determined to see this thing running this weekend.

It'll all work, but I still want to refine the skinning and realistically will probably take another week to do that, what with other stuff. However if anyone wants to play with a beta version in the meantime they'll be welcome to it.

Provisional stats are:

Top speed = 52
Free weight = 58
Pulling power = 12
Locomotive weight = 80
Tender weight = 0

Reliability = Above Average
Fuel rating = Below Average
Acceleration = Below Average
Passenger Appeal = Gruesome (60% revenue)*

Purchase Cost = $140k
First year maintenance cost = $9k

These settings will generate speeds and running costs as shown in the shot, for default pre-1900 and post-1900 freight. The top speed is not intended to compete with the default PopTop Connie's ludicrous top speed of 60 mph. This one is intended to be used with better-balanced loco stats, with the Connie wound back to around 50 and the Mogul to around 47.

*The pax appeal of Gruesome is one of the new custom settings by RoR and myself. It will work just fine, in terms of gameplay, with a standard RT3.lng file. However it will show the text string "Frozen at 1 am" in the stats pop-up.

This is because we're hijacking some non-essential hex to extend the range of pax appeal. For anyone who wants it I'll be providing an RT3.lng with the strings edited to suit the new scale. This will be a straight drop-in for either 1.05 or 1.06, and will not cause any dramas. It still uses the default hex settings for 90%, 100%, 110% and 120% revenue, so is totally compatible with existing .lco files. However the naming will change to the following:

Code: Select all

Customised passenger appeal ratings.
-----------------------------------------
#ID....Rating Name....Revenue.....Hex value.........Default string
--------------------------------------------------------------------
2702 - Ultra Cool.....130%........11 00 00 00.......Frozen at 7 am
2688 - Very Cool......120%........03 00 00 00.......Ultra Cool
2687 - Looks Sharp....110%........02 00 00 00.......Looks Sharp
2686 - Looks Good.....100%........01 00 00 00.......Acceptable
3173 - Acceptable......90%........00 00 00 00.......Ugly
2697 - Ugly............80%........0C 00 00 00.......Frozen at midnight
2696 - Very Ugly.......70%........0B 00 00 00.......Frozen at 2 am
2695 - Gruesome........60%........0A 00 00 00.......Frozen at 1 am
------------------------------------------------------------------------

[Gumboots]

Ok, it works. All the round and round bits go round and round, and even do it in the right locations. Amazing. Just needs the skinning tweaked, and a couple of little extra bits I won't mention yet.

[Hawk]

You go man! Lookin' great!

[Gumboots]

Ok, back onto this. Time to get it sorted.

I've been going over some details, and have found out something about the nVidia plug-in for exporting from Photoshop to DDS. I went and got the latest version. The short version is that it's borked. I've run some tests on it, and if you use the non-binary alpha export option it will very helpfully put non-binary alpha pixels into areas you specifically went to the trouble of making binary. This is another way of saying it will create random glow in the dark, along with other crud.

The binary alpha export option is completely useless. Tried that too. If the threshold is set to zero it throws random opaque pixels into the transparent portions of your alpha channel, meaning random bits of crud again (although they won't glow in the dark). If the threshold is set to anything other than zero, the exported DDS will have no alpha channel at all. Which is even more useless than random blocks of crud.

The good news is that, based on what I've seen around the nVidia dev forum, they have absolutely no interest in supporting it or fixing it.

There is another PSD>DDS plug-in by Intel, which is wonderfully advanced and up to date compared to the nVidia plug-in. In fact it's so wonderfully up to date and advanced that it only gives export options which are so esoteric that neither RT3, nor Blender, nor Photoshop, nor Irfanview even realise they exist. In other words, it makes a DDS which can only be decoded by some of the latest versions of some of the latest game engines, and not by anything else. It gives an export option for the oldest and most basic DDS format, namely DXT1, but that has no alpha channel so is useless for RT3. It lists DXT3 (the one we need for this stuff) in its help pop-up, but does not actually give DXT3 as a usable export option.

In other words, for RT3 purposes the Intel plug-in is as useless as a manure-flavoured lollipop.

The nVidia plug-in is still at least marginally useful. It's sort of like a lollipop that smells of manure a bit but still manages to taste halfway decent. And yup, that description really does give a good idea of what it's like to work with.

So, I went hunting around the web and found this: http://www.easy2convert.com/psd2dds/

This thing actually works, which is amazing. However, there's a catch. What it does is give very limited export options, with no choice about the alpha channel. it just exports as binary alpha whether you like it or not. This is both good and bad. It's bad in that you still have to do a bit more work to get a usable game skin, but it's good in that it does the binary alpha properly, with no crud. Even better, it will convert straight from a multi-layered PSD to a DDS with no problems, whereas the nVidia plug-in freaks out unless you flatten the image first. This saves a step in the processing.

Anyway, so this Easy2Convert thing gives you a DDS with crud-free binary alpha. All you need to do then is open said DDS in Photoshop (with the nVidia plug-in )and paste in the non-binary alpha bits (windows, etc) from your PSD. Then export as DDS with alpha set to non-binary. This seems to work. In fact, judging by a quick test in RT3 it seems to work even better than using the nVidia plug-in all the way through. Going via Easy2Convert first seems to clean things up a bit, such that alpha sections are less likely to show the mesh lines against a brightly lit sky (you can see this bug with some older third party skins). It will still show mesh lines from some odd angles, but they're not particularly noticeable.

So that process is pretty quick and easy and, as far as I can tell at the moment, seems to do the business. The image appears to settle down and behave, and keep the alpha channel to what you told it to be.

---

woo hoo! I just figured out something. The Easy2Convert thing is going to be really useful.

What I've been doing for components that need alpha is making the basic shape (like a connecting rod or whatever), then duplicating that and rasterising the duplicate, then applying a colour overlay to the duplicate in either bright green or bright pink, then making a rectangular backing layer in the other colour, depending on whether I chose green or pink for the duplicate. The select tool is then used by colour range to select the outline of the rasterised duplicate, and that outline is then used to cut a chunk out of the backing layer. Once the backing layer has the chunk cut out of it, select it by colour range, and that selection then becomes the one that is used to apply pure black to the alpha channel, thus giving me the transparent surrounding needed by the component.

Now this all works, and works well as long as you don't use anti-aliased selections and you watch out for a few niggles, but its a lot of tedious messing around. The only reason I was doing it is because it was the only way I could see of getting alpha working properly with the nVidia export plug-in.

This is where the Easy2Convert thing comes in. What I've just found is that there is no need to waste time on tricky alpha masking. For the test, I took one of the default PopTop DDS images (stockD_A.dds if anyone cares) and opened that up in Photoshop. I then used a select to get the transparent (black) bits from the alpha channel, converted the single RGB layer from background to free floating, and used the selection to cut out the parts that would normally be transparent. I then deleted the alpha channel and saved the resulting file as a PSD. In other words, I made a PSD with one layer that was transparent in places, no fixed background, and no alpha channel.

I then ran that PSD through the Easy2Convert thing and opened the resulting DDS in Photoshop. It's perfect. The Easy2Convert thing automatically created a suitable alpha channel with perfect binary alpha. This is awesome, because (pending further testing) it appears to mean that I'll be able to just create whatever shapes I want without having to worry about given them alpha masking manually. I can just do them as free floating layers of vector or raster shapes, with transparency outside the shape boundaries as normal, and not worry about it. This will save a stack of time and effort.

The resulting DDS will still have to be opened and exported out of PS via the nVidia plug-in to get the required non-binary alpha in places, but since that process is fast and easy and doesn't appear to cause problems, the whole thing is still looking like a winner.

[Gumboots]

Hey I just figured out something about this transparency thing. Using partial transparency (like 50% or whatever) doesn't actually make anything partially transparent. Unless the transparency is 100% the area will always be completely opaque. So you can have non-existent glass, or opaque glass, but you can't have translucent glass. It just doesn't exist in RT3.

All the partial transparency does is make things glow at night. It has no other purpose. Which is an absolute mongrel of a thing to do to people, and it beats me why anyone in the dev team ever thought it was a good idea. It's been a major PITA for modding and skinning ever since. If it wasn't for that stupid bit of coding locked into the .exe we could just skin stuff normally without worrying about it, and we wouldn't have to have jaggy edges all over the place. The currently useless PopTop train skin utility would even work properly.

There are times (not all that infrequent) when I could cheerfully strangle the original dev team.

[Gumboots]

Ok, el beastie is just getting a few finishing touches now. A bit of colour balancing, attempting to clean up some bits of crud, throwing in a bit more detailing, adding a few drop shadows, etc. I've decided I'm definitely getting it done by Sunday, or my name's not Gumboots Wellington Galoshes the Third.

[Hawk]

That's lookin' really good GWGT.

[Gumboots]

Getting better all the time. Have done a bit more. Will have another go tomorrow.

[Gumboots]

Have had another go. On the home stretch now. Just needs a little bit more tidying up, then I'll export everything and pack it.

With the open framework on this old beast (taken from the plans for the prototype) both sides of the drivetrain will be visible from some angles, so I'll use the same trick I used on the Mogul revamp and stagger the drivetrain 180 degrees between the left and right sides. It will be a good effect on this one.
.

.
The valve actuating rods work too, using a "ghost" drivewheel and connecting rod that have no visible mesh and a much shorter stroke than the main drivewheels. I did think about doing a fake of the whole inside Stephenson linkages, but decided that way lies madness. Just having the valve rods working is fine and a bit of fun.

I learned something while setting them up too. At first I did the ghost drivewheel with only an axle attachment point but no vertices or tris at all. This has a funny effect, in that the valve gear was going a million miles an hour even when the train wasn't. I figured out that the game needs some verts to give it the diameter of the wheel, from which it works out how fast it should rotate. I thought it just worked on axle height, but it doesn't. It goes from the diameter (or diagonal) of the mesh. So it set it up with the same drivewheel verts as one face of the visible wheels and hey presto, valve gear goes in synch with the rest of the drivetrain.
.

---

.
Edit: By the way, I've been doing a little bit of sandboxing with the H3 to check out colour balance and a few other things. Only serious testing of course. Not that I've been grinning like an idiot watching H3 choof all over the place. No sirree.

Anyway, I'm thinking maybe the initial stats are a bit too strong. I was testing on my Royal Tour map in the 1930's, just because that's the default starting period and I didn't bother changing it for the sandbox runs. Had the usual runs set up, some of which have fairly long 4-5% grades but mostly 3% or less.

As mentioned in an earlier post the weight is currently set to 100 "tons", all in the locomotive. "Free weight" is 58 and pulling power is 13. With those stats El Beastie will choof up a long 3% grade at an easy 20 mph hauling a full 1930's freight consist. This is currently a mix of default C freights (20 tons) and the rest the custom E freights (up to 26 tons), so probably averaging around 23 depending on what it's hauling at the time. Then I was also finding it surprisingly good on the Malawi map in the late 20th century, which is a bit over the top.

Really this thing should be targeted at the pre-1915 eras, giving it a best service life of 25 years from introduction, so that's aiming at heavy freights of 17.8 tons. I haven't yet tested that seriously, but obviously it'll be faster with those weights, and I'm thinking that's starting to get a bit too fast for what it is. Assuming it's only up against Connies, etc that have had their stats reset to saner levels, of course.

If the pulling power is dropped back to 11 and the free weight increased to 72, performance on flat ground (which I think was about right) stays the same, but performance up grades with post-1915 heavy freight just takes a bit more of a penalty without becoming complete hopeless. I think I'll release it with those changes.
.

[RulerofRails]

The figures I had were a quick attempt at half-way between the Connie you tuned and the H10. I never tested an engine with them in-game. Sounds like the light really is at the end of the tunnel.

[Gumboots]

Yup, I know those stats were a quick edumacateded guesstimate. Pretty close for a first stab at it. Just thought I'd let you know why I was thinking of revising them. Even if the speed difference isn't spectacular compared to the earlier Connie (and 19th century freight shouldn't be fast anyway) this one will still win out on fuel economy and reliability.

And yes, light is being seen at the end of the tunnel. I just made some last minute changes to the mesh and skinning this morning, detailing the front end a bit. Have a bit more skinning to do, but no more mesh tweaks. Looking good for exporting and final testing tomorrow.

BTW, the PSD is up to 37 meg now. I think I may have been getting a bit carried away. Had an idea about the dodgey nVidia DDS export from Photoshop too. Obviously I can use the Easy2Convert gizmo to go straight from PSD to DDS with clean alpha, but then I still need to touch up the alpha for stuff I do want glowing at night (headlight lens, windows, etc). Than opens the possibility of Photoshop and nVidia borking the alpha again. And yes, Photoshop does it too sometimes. Offhand I'm not sure if the root cause of the problem is PS or nVidia. I'm guessing it's a bit of both, since I know nVidia's binary export is totally screwed and I've seen PS throw grey into alpha areas which should be black.

Anyway, possible workarounds are:

1/ Just say what the heck and use TGA instead. Downsides are a bigger performance hit, and frankly image quality is not noticeably better for this particular skin.

2/ Do any final editing of the alpha channel in GIMP instead of PS. I can stand GIMP for something that trivial, as long as it keeps the alpha clean. Haven't tested that yet, but will soon. It could be a handy backup.
.

---

.
Edit: Well I just had another earning experience. After grumbling about alpha channels I decided there must be a solution, so went looking. Found plenty of examples of people answering the wrong question in a really useless and waffly manner after someone went to the trouble of being very specific and clear about what they were asking, and plenty of examples of people giving the wrong instructions. The usual internet stuff.

However, I finally figured it out. It's really easy. Photoshop has a Threshold tool (Image > Adjustments > Threshold). To set your alpha channel to binary transparency, all you have to do is switch to the alpha channel (RGB channels off for this) and select the whole thing (Select > Select All). Then, just click Image > Adjustments > Threshold and set the slider to wherever you want it, then click OK. Hey presto, the entire alpha channel is now binary even if it was loaded with crud before.

If you want a nicely shaded headlight lens to stay non-binary, just use the subtract-from-selection tool to take a chunk out of the whole channel selection you started with, then apply the threshold tool after that. The non-binary bit (being exempted from the selection) will stay non-binary and the rest will be forced to binary. Perfect.

It even seems to survive export via the nVidia plug-in.

[Gumboots]

Ok, I got the skinning finished, and I've got the LOD's done, so some bits of it are finished. Still haven't done the actual exporting and packing, and due to needing sleep I'll miss Sunday for a totally finished product, so maybe my name isn't Gumboots Wellington Galoshes the Third.

Anyway exporting and packing doesn't take long. It'll be out the door and scaring the local dogs soon, probably tomorrow my time. The final skin and mesh looks like this...
.

.
I'm pretty happy with that. Nothing's perfect in this life, but I reckon it's a good job.

Oh yeah, and that trick with the threshold tool on the alpha channel appears to be reliable, which is great. Now that I have that one up my sleeve, skinning things up will be a lot easier.

[Gumboots]

Ok, one beastie ready to rumble. Zip attached two posts down.
.

.
This one is using the expanded pax appeal scale that RoR and myself came up with. Files for that are included, if you want them.

[Gumboots]

Having played around with it in the game a bit, I'm going to make a few small tweaks to this one. Slight revision of stats, and some minor improvements to the skinning. Will upload an improved zip tonight my time.

[Gumboots]

Ok, tis done. If anyone is wondering what changed:

1/ There were a couple of minor mesh-related shading niggles, so I fixed those.

2/ I added some rivets to the cowcatcher, just because I could and I thought it needed them.

3/ The first skin was a bit too clean. It almost looked like an express loco instead of a freight beast. It was also a bit dark. So, I lightened it up some and gave it a bit of grunge, and tweaked some of the layer styles to work with all that. It looks better now, IMO.

4/ Tweaked the stats slightly.

5/Also tweaked the PopTop/1.06 Connie and the 1.06 Mogul stats a bit, so they all make more sense together.
.

.
File for all of the above are in the zip. So are files for the expanded pax appeal scale. So is a readme, which you ought to read.

[Gumboots]

Oh and some in-game shots. The only problem with it now is that it makes most of the other locos in the game look like crap.

[bombardiere]

Thank you for doing this. It is a great engine.

I have test played it and may be it is even too good. I won Campaign's East Africa Scenario with this engine. I bought one Camel as I did not have money at the beginning, but everything else was H3s.

Great Job.

Only thing I would say that the skin is darkish. Pop Top used lighter shade in boiler areas where sun would reflect. I think it is called "Burn" or something. Pop Top's methods may have been crude, but it seems that I have used to those.

I will test your modifications to Mogul and Consolidation. Connie is perhaps the most changed engine in the game. With 60 mph 1.05 is way too good. While playing the vanilla Campaing, I used it everywhere. Including the fast express, because many scenarios did not have better express engines. Getting Connie right is hard I know.

Your start date 1975 will give standard Consolidation only 15 years until H3 replace it. Not necessary a bad thing. It was too dominating in 1.05, though I will surely miss it.

The new Mogul seems to have stats very close to Consolidation. In my opinion these are too similar now. I would use this Mogul as late 19th century heavy mogul and do another early one closer to American's size. It would be weaker and would not compete with Connie and in same way as H3 substitute Connie, the early Mogul could be replaced with bigger and more powerful Mogul. Well, may be one day I can do an early Mogul, but not yet.

BTW I notice that you have given tender weight as 0. Why? Don't tell me that it is one those thing which don't do a thing. I have always thought that the tender weight is a game factor, but now I have a bad feeling that it is not so...