Short engine modding tutorial

[sbaros]

I trimmed off the water tanks a bit, they were covering the driving wheels too much and removed the red toolboxes altogether. I think I'll trim these a bit more when the opportunity arises. I also decided to remove the "Pleitegeier", it went "pleite" as its creator might say. Sorry about this, Adolf !
This time, I tricked the distributed "TrainSkin.bat" to do part of my work. Till now, I prepared within Corel Photopaint the smaller _B, _C, etc skins in TGA format with manual resizing. Now, "TrainSkin.bat" packed these derivatives for me in a dummy PK4 package in DDS format, I took the skins from there to my UserExtraContent with the Watto Extractor, and then deleted the rest of the dummy PK4, not needing it any more
Strange thing, although I did no other work, especially not touching any of the 3dp stuff, this time the buffers smash halfway through the last car. It doesn't bother me so much, nevertheless I wonder about the reason. I may "Americanize" the thing removing the buffers altogether if it pisses me off in the future
By the way, I saw what I may have missed in my 1st failed attempt to clone the Sm2, a certain tiny .DSC file probably needed to link the various parts constituting the model. Perhaps this will also prove crucial for various rolling stock trickeries.

[Gumboots]

If you edit loco or car files and reload a saved game, the asset will often be a bit borked. To get an accurate test you have to replace the asset while playing. I'd try that.

Have you checked the alpha channels on the new .dds images? I wouldn't trust TrainSkin to not screw them up.

A .dsc file is only needed for adding in-game-selectable skins to an existing locomotive. It's not needed for new locomotives or cargo cars.

Did you understand my point about the .imb files? The code inside them contains the original asset name. That has to be edited to match the change to Dm2. You can edit the name of the .imb file directly inside the PK4 with a hex editor, but you can't edit the contents of the .imb file. To edit the file contents, you need to extract it first.

[sbaros]

A stupid man's approach (that's me) to minor modifications of 3D stuff
I finally found some spare time to try this, I was thinking about it since last month. So far , I haven't located any mention of it in the forum. Until I acquire more sophisticated skills on graphics manipulation, I do this:

• paste upon the skin in question a grid with numbered squares (automatically generated in a spreadsheet) and save it under a different name
• apply the skin on a purpose-created clone of the relevant model

We see this applied for example to one of Tycoon's default Mikados. Suppose that I want to change the colour of (or even eliminate altogether) the feedwater heater. I load the created clone on any map available and take the necessary screenshots. Then, I close the Tycoon again. On a clean copy of the above skin, I find the squares which I want to recolour or eliminate. The feedwater heater in our case is found to be located around the G19-G20 cells. So, I carefully apply the subtractive mask of Corel around them. Now, this texture won't be loaded. Let's reload the modified 3D model in the Tycoon for verification...
Voila! The feedwater heater is gone. Sorry about that, ELESCO ! Its base and connections are now orphans.
Actually, the Peloponnese Division had done this to a bunch of postwar Mikados near the end of their carrer.
OK, I also need to replace the feedwater pump with a second injector, don't start pressing me ! Anyway, I think the general concept is clear...
Observation: We notice how the crippled-resolution skins provided with the POP-TOP reskinning tool suck, in comparison to the 1MP originals. I'll try to use the latter as much as possible from now on.
Images displayed in reverse order.

[Gumboots]

You can do it that way. On the other hand if you get Blender you can import the .3dp, skin it with the default skin, then use the UV viewer to check out any component anywhere on the model or the skin. Make adjustments to the skin as required, refresh the image in Blender, and you get an instant update of how the changes will look. It's much faster and easier than screwing around with in-game changes.

This is even more true once you start getting into changing mesh, instead of just using alpha to hide some of it. I've done mesh changes the hard way, and I'll never do it again.

[sbaros]

Yes, that's why I confined it to minor, purely cosmetic alterations for telling individual trains apart. One can subtract stuff, but adding stuff will understandably require the aforementioned mesh changes. I don't know if I'll find enough spare time to learn Blender before my retirement !
Observation #2: All numbered squares in the attached screenshots are the same size, which means that all parts of the bitmap texture are applied to the 3D solids at the same scale. I wonder whether this is obligatory or individual parts of the texture could be stretched / tiled at varying scales, individually for each of the surfaces defining the model. In the latter case we would be capable of superdetailing some parts locally, while less demanding ones could be covered at a lower resolution.

[Gumboots]

Yes you can do that. It's pretty common. I can't recall specific examples offhand, but I seem to remember it being done in some default models. I've certainly done it in some of my custom models, and I've read of other people doing it for non-RT3 assets elsewhere.

I find the best approach is generally to do most of the model at the same scale, to makes things easier on my brain when I'm building a new asset from scratch. It makes dimensions easier, and allows layer styles to be pasted to several layer while giving the same look. Then I may use a different scale (smaller or larger) with some specific components.

Flat areas with little detail, particularly if not visible most of the time, can be done at a smaller scale to save space. Prominent details that will look crappy at the standard scale, due to binary alpha causing jagged edges, can be done at a larger scale for cleaner looks. These are often fairly small components anyway, so if you're careful you can often still fit them in. One example was the bell hanger on the Pennsy H3.

[sbaros]

I don't know if this has been documented elsewhere, but in an effort to exchange tenders between engines, I realised the filenames of tender .CAR files play absolutely no role in matching it to a specific loco. No matter if you rename for example the "Class 01 Tender.CAR" after your uncle or anybody else, it will still couple to the 01. What seems to matter is the engine's 3DP filename, which has to be written in the intended tender's .CAR file (byte address 132) followed by the suffix "T" (for tender).
This fact makes the definition in byte 50 of the .lco files redundant, and as I found out, Gumboots is right that this is deprecated code

We know a value of FF (255) for byte 50 means no tender. The Shay and Fairlie and others have FF there, but default locos that have tenders have a range of values that AFAIK have never had much (if any) testing. Now these might be meaningful, or they might not. We know there is deprecated code in RT3

I tried 255 for byte 50 in 2 cases, but the tender remained the same
Unexpectedly, in contrast to the 3DP filename, the bitmap skin file of the tender can be freely defined in the .CAR file (byte address 162), so that one can change the colouring, but not the shape of parts.
So, it seems inevitable that an exchange of tenders between engines forces the duplication of all 3DP files of the intended tender in the UserExtraContent directory under the target loco 3DP filename (plus that "T" suffix).
I haven't tested yet what happens if there are more than 1 different .CAR files with the same loco 3DP prefix in byte address 132, but I guess the program will pick up the alphabetically preceding one for the given locomotive.

[Gumboots]

That makes sense. So we could set byte 50 to 00 in any custom assets, just to save confusion. I do the same with tender weight and .cgo weight. Zeroes are easy on the brain. Less "imposter" hex code to confuse things. IMO all deprecated hex code should be set to zero.

No matter if you rename for example the "Class 01 Tender.CAR" after your uncle or anybody else, it will still couple to the 01.

I prefer to keep naming consistent anyway. It just makes things easier to keep track of.

[sbaros]

Serious inaccuracy in PJay's Stuff "LCOspec"
That supposed "loco short name / unique id" at byte address 4 of LCO is not just a randomly picked name, but it has to be specifically the corresponding .CAR filename, as I happened to realise just now after a frustrating series of trials and errors.
Is anyone keeping track of the reported findings concerning the various instructions published, with the authority to update the uploaded versions?

[Gumboots]

Not sure. I suppose we should start a pinned bug list somewhere. There are quite a few glitches in the game itself (non-working events) as well as the various third party files, etc.

[sbaros]

Another strange reference in Pjay's CARspec: Byte 072 is supposedly the LCO file name, yet unpowered CARs still have this field occupied (with the car's name, which lacks a LCO file altogether). So, either this field is another deprecated feature, or the information is nonsense and the aforementioned Byte address actually corresponds to something else (anyone knows what?).
Also, a tender's supposed start date is also indifferent, it always accompanies its engine regardless of any inconsistency in the start/finish dates.

[Gumboots]

I suspect the LCO name in unpowered cars is ignored, but I haven't tested it. I just fill it out with the car name for consistency, but if you want to test it you could try just leaving it blank instead, and see what happens.

The tender automatically following the loco makes sense, but again I just use the loco dates there. It's easy to copy/paste them from the loco file, so I just do it for consistency.

By the way, in case you didn't know I always set custom tender weights to zero. The game just uses the sum of loco weight + tender weight when calcuating loco performance stats, so IMO it's easier to just put all the weight in the loco and zero in the tender. Less things to keep track of when tuning performance, and 70 ton loco + 0 ton tender gives exactly the same stats as 50 tons loco + 20 tons tender.

[sbaros]

So, this constitutes another inaccuracy in Tycoon's train performance formula. In reality, loco weight -on powered axles- contributes to tractive effort and consequently acceleration, contrary to tender weight. A total-adhesion tank engine will logically outperform its respective tendered version of equal horsepower (but need more frequent refuelling).

[Gumboots]

Lol. It's crazier than that. In RT3's algorithm, reducing locomotive weight makes it haul better up grades. You should read the thread where I reverse-engineered the formula for speed vs grades. Try this post for a starting point: viewtopic.php?p=40771#p40771

Edit: This is some more info about RT3 basics: viewtopic.php?p=43708#p43708

A total-adhesion tank engine will logically outperform its respective tendered version of equal horsepower (but need more frequent refuelling).

Sort of, maybe. Depends on several other factors too. If number of driving axles is the same, and axle loading is limited to a given upper value (normally the case) then the tank loco will need to have a lower axle loading with tanks empty to stay within the limit when they are full, and will only have the same adhesion as the tender loco when tanks are full.

[jaketrainz]

Forgive me. New here. Gumboots, I've seen quite a few of your tutorials on here and on a blender page for importing the 3dp files. I'm interested in learning how to do this, but have had some difficulty with this. I really need to learn more of blender I think, but is there a good concise guide to importing the 3dp files with Blender? I'm also looking to successfully move some models from RT3 into the Trainz series of train simulators via Blender. I apologize if this is considered of topic. I would also just like to learn enough to play around modding models for RT3 as well.

[Gumboots]

No problem. The existing Blender script was written for Blender 2.7, which was the current version at the time. I believe Blender is up to v2.9 now and I think the script would need recoding to work with either 2.8 or 2.9.

I have not tried either of those versions, because after learning the interface for 2.7 I did not want to have to relearn a new interface after they changed a lot of it in 2.8. So I still use 2.7 for any modelling work, because I'm familiar with it and it does everything I need it to do. At this stage I'm not into learning enough Python or enough of the Blender 2.9 API to recode the plug-in for that version of Blender. But, it's probably possible to get someone who knows what they are doing to update the thing in an hour or less, which should be a pretty cheap option.

The only guides available are the ones you have probably aleady seen:
viewtopic.php?p=40470#p40470
viewtopic.php?p=42746#p42746

PS: Before trying to do anything with Blender 2.7, it's best to read some of their Noob to Pro tutorials to get your head around how the interface works. You only need to read the basics, not everything in the e-book: https://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro

[jaketrainz]

Thanks. I found those posts last night after I had already posted. I will certainly have a look into the tutorials too. I successfully extracted the pk4 files and was able to import the 3dp files into Blender 2.79 and get the textures to show up. I have a question regarding the bogie animation though. Where is this information stored and is there a way to import the animation into blender? Also. lender seems to have a slight learning curve, but my prior knowledge with an old program called Gmax (used for old Trainz Simulator modeling) seems to help me so far. Again, hopefully allowed here, but importing the animation would allow me to export the bogies into a Trainz format.

[Gumboots]

There is no animation as such. The game engine handles it automatically for any files named Drivewheel or Bogie.