GP7 A+B unit (Final for real this time)

[Gumboots]

By the way, if you're into making and skinning double diesel units you might like to check out some of the classic Australian trains.





Or you could hook the Pen-y-Darren up to an SD90 just for fun.

[Just Crazy Jim]

A double-header NR class? Sure, why not?

I'm guessing for length (72 ft 2 in according to Wikipedia) they'd be about the same as the USA 103 (which looks suspiciously like the GE Dash 8 Series, which is 70 ft 8 in), same C-C arrangement at least. But for sheer gruntitude, I have to point out that Aussie trains (especially some of those BHP Billiton runs) have been somewhat legendary for about 40 years. Admittedly, if you have eight of any locomotive providing power, you can get some stagger results, but the legend goes....

I'll tinker with it and see what develops.

[Gumboots]

The Ghan and the Indian Pacific are primarily pax traffic, although they do take other stuff as well (passengers' cars, some light freight, dead donkeys, kegs of beer, baksheesh, whatever).

The Pilbara mining trains are a whole 'nother kettle of very large and stinky fish. With remote-controlled multiple units run from the cab up front. They can't put all the units at the front because the trains are too long (causes several problems) so they have to distribute them along the length of the consist.

[Gumboots]

Admittedly, if you have eight of any locomotive providing power, you can get some stagger results, but the legend goes....

Hey here's an idea for a fine bit of nuttery. So you can make double header steamers as long as the tender and loco share the same skin image. But, this is the good bit, you wouldn't necessarily have to do them as loco+tender.

What you could do, with some units which are small enough, is double them up as trucks. Similar to the way I did the multiple bauxite cars. So if you were wanting to go really mental it would be possible to have a six-headed Shay. Or a quad-headed Beuth. Or a triple. Or double Beuths piloting something else. The possibilities are quite varied.

[Just Crazy Jim]

Noted. That explains some of the confusion I was having about the livery. I was like: "that's awfully upscale livery for a general purpose railroad company." But that just tells you that special livery and names for PAX locos is all but a long ago and forgotten thing in the USA.

In any event, they look both a good deal more sexy than the beast that carried me from Perth into Kalgoorlie in 1979. And before you ask, my dad was a mining engineer, so when we left Africa, we ended up living in a lot of oddly-named places. Some of them I remember fondly... some of them....

Admittedly, if you have eight of any locomotive providing power, you can get some stagger results, but the legend goes....

Hey here's an idea for a fine bit of nuttery. So you can make double header steamers as long as the tender and loco share the same skin image. But, this is the good bit, you wouldn't necessarily have to do them as loco+tender.

What you could do, with some units which are small enough, is double them up as trucks. Similar to the way I did the multiple bauxite cars. So if you were wanting to go really mental it would be possible to have a six-headed Shay. Or a quad-headed Beuth. Or a triple. Or double Beuths piloting something else. The possibilities are quite varied.

Oh good lord.... Why is that so appealing?

[Gumboots]

Umm, because we're bonkers? I think that's the reason.

Anyway, on slightly saner lines, it did jog my brain about something else. Back before we had Blender options things were far more limited, but I just realised that the number of possible double-headed steamers (quick and easy ones) is greater than I thought.

Obviously the ones that have loco and tender on the same image are possible, but there are also some default steamers which use a 512x512 A skin. Moving UV mapping en masse is a piece of cake in Blender, so it would be possible to take the default 512x512 A skins and join them into one 1024x1024. This would allow quick and easy double heading of the Camelback, Consolidation, 8 Wheeler, Kriegslok, S3, Class A1, and Class U1.

And that's not all. Because the 1024x1024 would only be half full, it would be simple enough to double up the full bits to give a different skin on the second unit without requiring a separate image.

Or, just to really wind this up and get it going, the first and second units could easily be completely different locomotives. There's no reason why we couldn't have a P8 piloting an S3, or a Connie piloting an 8 wheeler, or several other combinations.

But double-headed Connies has just got to rock.

[Just Crazy Jim]

Milkshape 3D has a simple UV mapping tool for doing the same thing. I have used it for many years :D

It's entirely possible that the game could handle an oddball sized texture IF there is an 8 MB bitmap* limit set for a single texture.

*Here I am using "bitmap" in its original computer coding video sense, meaning decompressed digitized image data as it is pixelated to the screen, rather than the BMP file format for stored image data.

What I do know from experimenting in RT3 is that if you use mipmaps (_A, _B, _C, etc), the RT3 EXE will step down the chain based on camera distance, but if you do not use mipmaps, it is quite content to use just the 1024x1024 texture for all camera distances. But I have seen that if you try to be tricksy and use 1024x1024 for more than just the _A in the mipmap sequence, the EXE will skip down to whatever is the first mipmap that is actually smaller than 1024x1024 regardless of the name assigned. So my blind guessing is that the EXE loads all the mipmaps for a given model into a buffer. If this is true, each CAR model may have a texture buffer that is the sum of all the mipmap file sizes combined (_A + _B + ...). If there are 8 in the sequence (_A through _G) that (usually) gives 5,592,372 bytes (~5.33 MB), which is more than 4MB, but less than the next logical exponential, 8MB.

I never found in any of the games I've modded the exact part of the code that set the individual texture buffer limit, but since coders generally code such things as buffer limits based on powers of 2, the next step up from 4MB (1024x1024 TGA/BMP/etc) is 8MB, I put on my evil genius hat and went to work. Doing this, in other games that gagged on 2048x2048 textures, I have successfully used "over-sized" textures (2048x1024 (2:1), 1024x2048 (1:2), 4096x512 (8:1)).

I will need coffee before I can think any more about this.

[Gumboots]

Oh ho! Now that's thinking very much sideways.

I had already considered using a 1024x512, since it's still PO2 and I know the game will handle non-square images (at least for beauty shots, profile icons, etc). The only reason I thought of doubling up the mapping to fill a 1024x1024 was to get variation in skinning the between the A and B units. However it hadn't occurred to me to try to creep up on an 8 meg limit with non-square PO2 skins.

What I do know is that although you're right about the game not requiring B, C, etc images and being happy to stick with a single A (as long as you love Moire patterns) if you include the smaller images they do have to be half the dimensions of the one above them. If they're not, things break. Anyway, you need some coffee. A through to G is seven images, not 8, so knock 64kb off your total there. But I get your point and it's a good one.

So what we should test is non-square PO2 images, seven of the blighterz, that add up to 7,999,999 bytes with a cherry on top, or as near to that as possible. Or we could even try cutting it down to 6 images, since the amount of bytes saved on the tiniest ones is negligible anyway but Moire patterns aren't fun at all. A bit of distance fading is a nice touch too.

Ok, so thinking this through (I currently have morning coffee!) your hypothetical 8 images add up to 5,592,372 bytes. The smallest would be 8x8 so that's the base unit here. So areas, and therefore approximate byte counts, are going as 1 > 4 > 16 > 64 > 256 > 1024 > 4096 > 16384. That's a total of 21,845 little boxes on a hillside. A bit of division tells me that an 8 meg limit would give room for 31,249 little boxes all the same. So what's needed is a progression that gives roughly 31,240 boxes, and is all PO2 sizes, and with the sizes decreasing in area by a factor of 4 each step. Which is some what tautologous, but I'm thinking aloud early in the morning.

Will grab the old calculator and figure this out.

[Gumboots]

Ha. Didn't need a calculator. The problem is obvious once I starting writing it out.

All image have to have dimensions in powers of 2. The default skin chain chews up around 5.5 meg, with the A skin taking up roughly 4 meg. By halving the height of images (ie: going to 2:1 aspect ratio) we halve the byte count. Oh goody. So what happens then? We double the linear dimensions! Yay!

This gives us ((5.5)/2)(4) = 11 meg. Which is more than 8 last time I looked.

Ok, can we remove the biggest one and still end up ahead? No. It goes like this:

8 Meg limit allows for 31,249 chunks. Call it 31,240 to be safe.

Each chunk is 8 pixels by 8 pixels.

Progression 8 > 16 > 32 > 64 > 128 > 256 > 512 > 1024 takes up 21,845 chunks.

Byte counts proportional to 1 > 4 > 16 > 64 > 256 > 1024 > 4096 > 16384

Next logical progression is 2:1 aspect ratio, which if starting from 16x8 would give 43,690 chunks which is too much.

Byte counts proportional to 2 > 8 > 32 > 128 > 512 > 2048 > 8192 > 32768

We need to remove at least 12,441 chunks from that, which puts our biggest image at 8192, which is half the resolution of a 1024x1024.

Ok, let's try 4:1 aspect ratio says he merrily (with brain in neutral and great enthusiasm).

Byte counts 1 > 4 > 16 > 64 > 256 > 1024 > 4096 > 16384 > 65536

Which adds up to about 22,000 ish if the highest one is removed, with the biggest one at 16384. Which is where we started. Grumble.

8:1 aspect ratio? Hmm. Not likely to help but anyway...

Byte counts 2 > 8 > 32 > 128 > 512 > 2048 > 8192 > 32768 > 65536

Which is obviously useless. It puts our biggest image at 8192, which again is half the resolution of a 1024x1024.

------------------------------------------------------------------

At this point the problem should be obvious. The only way around it, which might possibly work at the cost of some hit to performance, would be to deliberately break the PO2 rule and hope the game doesn't spit the dummy.

I already know a 768x768 A skin will work (test pic here). What I don't know is how the game handles that internally. Obviously for rendering it has to be scaled up to 1024x1024, or down to 512x512. The key questions here are:

1/ Does the scaling count towards the game's internal limit or not? If not, and if the game only counts actual bytes of actual skins, then we could theoretically cheat up upwards towards an 8 meg limit if that is applicable.

2/ How does the game handle scaling to PO2? Will this result in a loss of image quality?

3/ Given that breaking PO2 will incur a performance hit when rendering graphics, is this going to be bad enough to outweigh any possible gains in eye candy?

[Gumboots]

Ok Jim, if you want to play around with this idea...

Assuming you can actually get away with an actual 8 meg limit on actual skin bytes, you could go as high as 1224x1224.

1216 > 608 > 304 > 152 > 76 > 38 > 19 for A through to G skins would give a 41% increase in A skin resolution.

The maximum possible (1224) only gives 2% more resolution, but won't allow as many skin levels (breaks at E).

There's no point using non-square skins for an 8 meg limit, as demonstrated in the previous post.

[Just Crazy Jim]

I think I may have left out a rather important part of what I was trying to express. I hit all around it, but missed writing it. I meant "for purposes of fitting many models (e.g. a quad-header loco, or a large clot of buildings on a single footprint - example: Hooverville, coal camp, etc) onto one giant texture when no one model will be using more than 512x512 of a texture." In such a case, it shouldn't matter terribly that there is only a single large texture and no smaller versions as mipmaps.

My brainwave was more or less aimed at things that wouldn't (or, at least, shouldn't) have 100s of instances on any given map. Although, there is a certain appeal to having quad-header locos running every train on the map I cannot think that it would have more than a few moments of appeal. So let's call the thing I was aiming my remarks at a "map decoration" rather than a universal plan for all loco models.

When I did my testing, I never noticed moire lines, but, then, I wasn't looking for them either. I was only testing to see if it would cause a Bong of Doom or CTD.

[Gumboots]

Oh ok. In that case I won't worry about it.

[Just Crazy Jim]

Okay, it's been a week, and no one has returned to say the GP7 A+B is broken or sets their hard drive on fire, so Ima submit it for the downloads page.

[Gumboots]

Must admit I haven't even tested it, having been up to my eyeballs in Moguls. But if you tested it and it works, I'd say that's good enough.

[RulerofRails]

Finally gave it a go.

It needs a beauty shot. Smaller issue is that the profile icon has the default color scheme.

One other comment after seeing it in the game. The burgundy/red part of the skin doesn't show the details super well. At partial zoom, not that far out (so that most of the train is visible) the step area melds together with the walk-way level (underframe?) and up towards the window. It's not real serious just thought I would mention it.

Shots from in-game fully zoomed in, vs. the original:

After close inspection, it's impossible to not notice that PopTop ignored the wheels on this one.

PS. Shot of the V200 detail, notice how clear the writing is, which is still pretty good since I used 1600x1024 resolution to capture a non-fullscreen shot and then converted to JPG for upload.

[Just Crazy Jim]

Much thanks for the feedback, RoR. It is greatly appreciated.

I just did a bit of detective work and discovered that I had not updated my GP7twins.lst file to reflect a name change for the beauty shot from "GP7twins_NE" to "GP7twinsL_NE". That will correct the beauty shot.

I'm uncertain what the problem is with the profile, it displays correctly in my game. I double checked my files in the packing folder and, other than the error noted above, they're all as they should be.

I've done a repack of the PK4 and double checked the CAR and LCO files to make sure they are the revised versions. (This time making sure to delete the old PK4 before packing a new one) I took this time to revise the names of the LCO and CAR files to GP7twinsL and GP7twinsT. All added to the repacked, updated, etc ZIP file in the first post. I also edited the first post of the thread with instructions to remove the old files.

About the details. When I set out to do the recolor, I settled on a Providence & Worcester livery, which meant black and some tone of red that wouldn't be too eye-gouging. I wanted "black" rather than dark grey, ideally a very crisp black, but such proved impractical as true black consumed all detail except highlighting, which IMO looked weird without the corresponding dark areas. The detail loss on the recolour was ultimately a sacrifice made to accommodate a black portion that looked "black enough" and at the same time did not eat all detail. This had a cascade effect in that high detail in the non-black portions then looked out of place, so those bits got a hammering down. Then, what looked "right" in Adobe Photoshop and the 3D modeller did not look exactly the same in RT3 because of subtle differences in the gamma balance and lighting values in and out of the game. I went back and forth several times trying to find a happy medium before I said "meh, it's good enough" and moved forward.

And, yes, I noticed the lack of proper bogies early on. Many of the PopTop engines have rudimentary trucks and/or static bogies. I have every confidence a man could spend a year just fixing PopTops oversights and shortcuts. I will very likely revisit this matter of the bogies after the New Year., correcting them on the PopTop original and my version at the same time.

[Gumboots]

I have every confidence a man could spend a year just fixing PopTops oversights and shortcuts.

Yup. I've just been doing this with the Mogul, which inherited Connie problems. Just as one example: the domes on top of the boiler. As you know, there are two sane ways of UV mapping a cylinder: you either squash it flat without seaming, or you seam one edge and roll it out flat. Either works, with the former being fractionally better for performance in theory.

Whoever made the Connie didn't do either. They tried to roll it out flat, but without seaming it first, with the result that one line of faces gets stretched diagonally from one end of the UV mapping to the other, overlapping all the rest of them. This is brilliant. Not only does it double up on verts at the ends, but it makes things look worse on the highest LOD. Even better when you dissolve some edges to go to the next LOD. Totally borks things wonderfully well.

[RulerofRails]

Tried the new one. Back with a report. Almost there. This is what I see now:

Not sure what's up with the beauty shot. You say yours is working correctly, well maybe it's a bug on my end.

Yeah, understand that black is a bit hard to do. Dirty/faded black transforms back to gray.

Now a comment or two about the tuning of economics and performance. First, I will state that I am comparing* this against the single GP7 as it comes in 1.05. I don't believe it has enough benefits to outweigh it's higher running costs when compared to the default "single" GP7. In fact the only I benefit I see is the reliability.

* Of course, engine choice is determined by availability. If the player doesn't have a choice, then there's no need to make a comparison with any other loco. So this is assuming you are designing this to be used in a situation that the regular GP7 is available.

Average Yearly Cost side-by-side:

Performance side-by-side:

Now, the first thing I would recommend is to wipe out the weight value (last 4 bytes) in GP7twinsT. It's confusing to have a weight in the tender file to keep track of. Adding/subtracting the necessary weight from the main GP7twinsL file works just as well.

This will bring grade-climbing ability of the twin almost up to the level of the "single". Because you reduced Pulling Power slightly, I am almost considering that you never meant the two to be compared (the player given the option to buy either one). Unless this isn't the version you tuned up.

In the first shot (detailed running costs) taking the highlighted green number (105.31, 152.36) from both sides we can see that the GP7 Twin is costing (152.36-105.31) or 47.05k more per year to run. That's (47.05/105.31) or 45% higher. Different people put different values on reliability, but I'm sure not willing to pay that. (If you wonder why the difference in running cost on the performance reading is lower at around 34% higher (99-74)/74, that's because the aging factor and the cost of eventual engine replacement aren't taken into account.)

PS.
For the new cargo progression that Gumboots and I are working on, the defaults will get some yet-to-be-determined tweaks, so I can't give you an accurate idea of how this setting will end up. For now, people will use any loose custom locos with car sets with the default weight progression, since the new cars aren't ready yet. So I would try to find some settings that are usable with those even though we know some things are borked.

[Just Crazy Jim]

I went back to the drawing board and started the LCO from scratch. I definitely want the GP7 twins to cost more to run, but I also want it to give a better performance on grades. Every time I think I understand the maths of this grade-climbing, I get a wake up call informing me that I'm not there yet. Frustrating as it is, I appreciate all you're doing to help me get to that understanding.

I have a innate dislike of seeing the top speed being the same across the top tier (0% grade), and several of my early attempts at calibrating a custom locomotive have been more or less Supertrain, so my knee-jerk reaction has been to be more conservative in tinkering with the values for grade-climbing. This time, too much so

So, I scrapped "logic" and just went with "make-believe it's not 2 incredible heavy things", then I set my eyes on the 8-cars column and kept it there, this is where I ended up:

It feels innately wrong to fudge the weight of the power units, but I am simply going to have to get over that.

I went back to my IMB and beauty shots, remade them from scratch. Double checked my completed work with the posted version and found one tiny error in the posted IMB. Don't ask me how the 2nd zero ended up getting deleted, but it had, adding it should correct the issue with the beauty shot.

So after a flurry of editing, rev.3 is ready to be added to the first post in the thread.

[Gumboots]

It feels innately wrong to fudge the weight of the power units, but I am simply going to have to get over that.

Look at it this way: the bytes in the .car files aren't actual tons. They're just bytes. Completely arbitrary. Even at 8 D era freight cars you have a total consist weight of 320 "tons". Which you wouldn't even need a DX Goods to haul on the flat, let alone double-headed GP7's.

So forget about those bytes representing weight in any meaningful way. They only really have one purpose with regard to locomotives in RT3, and that is adjusting fuel consumption. Use them for that. Don't worry about anything else.