Evil Genius at work

[Gumboots]

More than 4 or 5 years. Lots of people have contributed bits and pieces for at least a decade, depending on their available time and energy. They all get some of the credit. Every time someone tries something else, we all learn a bit more. Go for it.

[Just Crazy Jim]

The my first loco is working and looks fairly good. I probably need to change the tender to a small coal hopper and definitely need to add the vertical motion parts, but no wheels on fire effect!

The price of the unit is $20K - the price shown in the image is due to a +250% loco cost effect to reflect development costs, the pricing effect declines in stages as years pass in the scenario.

It was only possible because everyone else did all the hard stuff before I even started posting on the forum! And Gumboots, the patience of a saint.

[Gumboots]

Pretty cool. I like it. I may not like it after watching go a few mph everywhere for ages, but I like it now.

The vertical motion bits are probably possible, depending on how the original was set up. The game is limited in what it will do. For instance, the drive motion on a Shay is simply impossible within RT3 coding limits. Ditto for a full simulation of Walschaerts valve gear. No can do.

[Just Crazy Jim]

I figure if I can add the distinctive giant flywheel and the driving gear in this reconstruction for the Pen-y-Darren, it'll be enough.

The Steam Elephant (stage 2 prototype) being very glaringly a beam engine is the one needing the vertical motion more than the others. It's a beast of a thing. You can very clearly see the influence Watt's low pressure steam engines had on the design.

The Grasshopper (stage 3 prototype) is a bit of bother, though. There are three distinct versions of it:

the first image is a loco that was the basis/yardstick by which the success or failure of the original "Grasshopper" was measured, another beam engine inspired by Watt's low pressure steam. It was clearly not designed by Stephenson. It was built by Davis & Gartner in York, Pennsylvania, USA. The Grasshopper prototype was scrapped and never saw actual service. The other two are later models presented to the public as the original during the Centennial of Progress in 1933-1934.

At least Trevithick got side motion on the first try. It seems others have to be convinced.

[RulerofRails]

Congrats, on getting your engine into the game.

With the low speeds, you might want to be aware of the rot factor for each cargo. The figure for express is likely hard-coded, but with those low speeds I would consider decreasing it for the freight if you are making a full-on-mod.

I guess you read in the threads that the in-game performance readout is wrong? Express is the best setting (7 tons). But really A-era freight cars are 5 tons and express are 3 tons. I need to remind myself of this every-time I look at the in-game stats. Performance is better than it looks. To calculate the real figures, use Gumboot's spreadsheet.

In my personal opinion, 1mph is too slow. Below 4mph, is what I regard as unusable, but playing your scenario might force me to reconsider. Bear in mind that it's not possible to avoid grades on the ramps to bridges, at least if you don't setup the river banks properly (some fan-made maps have done this, but I think it's harder to modify a map than build this feature in).

PS. Just an idea: For non-prototype engines when speed is still critical you might give the player some options to increase speeds while reliability takes a hit. Giving the player an opportunity to take on extra risk. Could be asked again when a new engine comes out.

[Gumboots]

Ok, all the moving parts on the Pen-y-darren can be done, with the exception of the intermediate gear on the right hand side. The catch is that gear would have to rotate backwards to be realistic, and there's no way of getting reverse rotation in RT3. It might be possible if you can figure out how to hack animation files, but those are something I haven't managed to decipher yet. It's definitely not possible with standard locomotive files.



The rest is no problem though. The connecting rods on both sides, and the flywheel and piston, are all easy to do. If you want to sort a few other things out, switching the chimney to the rear of the boiler wouldn't be hard either. Ditto for custom tender.

[Gumboots]

By the way, not to hijack your thread, but when I was looking around for stuff on Pen-y-Darren I somehow found the old LMR 57 "Lion" 0-4-2.

https://en.wikipedia.org/wiki/LMR_57_Lion

http://www.lionlocomotive.org.uk/index.php

This is great, because one thing the early years of the game lack is a really good heavy freight hauler. Lion was capable of hauling 200 tons, and had a top speed of 45 mph. This pretty much puts it on a par with the Baldwin 0-6-0 in game terms, but it comes in 7 years earlier in 1838, and is an ideal Euro/World loco. I think I may have to model this one.

[Just Crazy Jim]

Ok, all the moving parts on the Pen-y-darren can be done, with the exception of the intermediate gear on the right hand side. The catch is that gear would have to rotate backwards to be realistic, and there's no way of getting reverse rotation in RT3. It might be possible if you can figure out how to hack animation files, but those are something I haven't managed to decipher yet. It's definitely not possible with standard locomotive files.

The rest is no problem though. The connecting rods on both sides, and the flywheel and piston, are all easy to do. If you want to sort a few other things out, switching the chimney to the rear of the boiler wouldn't be hard either. Ditto for custom tender.

Excellent news that. Thank you for looking into it.

I figure maybe using an x-8-x model (like the Consolidation 2-8-0), remove the x's, and rotate one of the drives. That might get the job done for a retrograde motion, it's a trick that works with the model animations in other games. If not, my thinking on the matter is "ok, so the intermediate gear is going the wrong way, cry me a river." TBH, I'm more concerned about botching the normals by forcing a rotation along an x,y,z axis than getting the animation spot on.

Agreed on both counts, reversing the chimney position, and a modified Era A hopper or flatcar seems the right way to go for the tender.

By the way, not to hijack your thread, but when I was looking around for stuff on Pen-y-Darren I somehow found the old LMR 57 "Lion" 0-4-2.

This is great, because one thing the early years of the game lack is a really good heavy freight hauler. Lion was capable of hauling 200 tons, and had a top speed of 45 mph. This pretty much puts it on a par with the Baldwin 0-6-0 in game terms, but it comes in 7 years earlier in 1838, and is an ideal Euro/World loco. I think I may have to model this one.

I swear, I think you may be looking through my windows! I was looking at that very locomotive just yesterday!

Congrats, on getting your engine into the game.

With the low speeds, you might want to be aware of the rot factor for each cargo. The figure for express is likely hard-coded, but with those low speeds I would consider decreasing it for the freight if you are making a full-on-mod.

I guess you read in the threads that the in-game performance readout is wrong? Express is the best setting (7 tons). But really A-era freight cars are 5 tons and express are 3 tons. I need to remind myself of this every-time I look at the in-game stats. Performance is better than it looks. To calculate the real figures, use Gumboot's spreadsheet.

In my personal opinion, 1mph is too slow. Below 4mph, is what I regard as unusable, but playing your scenario might force me to reconsider. Bear in mind that it's not possible to avoid grades on the ramps to bridges, at least if you don't setup the river banks properly (some fan-made maps have done this, but I think it's harder to modify a map than build this feature in).

Thank you! And I agree with what you're saying. Trevithick aimed for 2.5 m.p.h. on a 2% grade drawing freight (5 or more wagons of coal, each laden with 2 tonnes). Trevithick's target is just too slow for a RRT3 setting, so I used 10 m.p.h. as top speed and I'm still figuring out the maths to achieve 5 m.p.h. for a 4 car consist on 2%. .

PS. Just an idea: For non-prototype engines when speed is still critical you might give the player some options to increase speeds while reliability takes a hit. Giving the player an opportunity to take on extra risk. Could be asked again when a new engine comes out.

My thinking for the stages of development are along those times. A rough sketch of the plan follows:

Stage One:
1804, player gets the unaltered Pen-y-Darren ($20K base cost), reliable beyond all expectation, but beastly slow (RRT3 slow, since 2.5 m.p.h. proved game breaking) and horrifically ugly. Using event effects to run the cost of track maintenance and engine maintenance to criminally high levels. Engine purchase cost +400%.

End of Stage One:
the player has to chose one:
A) More speed, same grade climbing, much less reliable (Trevithick's "Catch Me Who Can" 0-4-0 (to be done)($15K base cost));
B) More pulling power, better grade climbing, a bit less reliable (Steam Elephant 0-8-0 or Salamanca 0-6-0 (to be done)($15K base cost)).

Stage Two:
1810. Pen-y-Darren remains available, player-chosen new prototype model becomes available. Events reduce the criminally high costs fractionally, down from "they stole my kidney" to "it's just a flesh wound". Engine purchase cost +250%

1812. The War of 1812 (event, June 1812 – February 1815) causes demand for logs (representing ship masts), lumber (representing ship planking), weapons (representing ship building), clothing (representing ship sails) to increase (500% price hike) Presenting the player with a short-lived chance to be a war profiteer.

1815. Great September Gale of 1815 (event, September 1815 - March 1816) - all freight production decreased 75% for 6 months, all freight prices +500% for 6 months).

1819. Panic of 1819 (event, 1819-1821 (inclusive)) - stock prices -75%, credit rating -4.

End of Stage Two:
the player has to chose one:
A) Better fuel economy, less reliable (result: Royal George 0-6-0 ($15K base cost)(to be done));
B) Lower engine cost, less reliable (result: Grasshopper 0-4-0 ($10K base cost)(to be done));
C) Higher passenger appeal, no change in reliability (result: H. R. Campbell's 4-4-0 ($20 base cost)(to be done)).

Stage Three:
1822-1829. Pen-y-Darren no longer available, player-chosen prototype in stage 2 remains available, player-chosen new prototype model becomes available. Over the period, costs of commodities normalize, financial aspects normalize, costs of operations normalize. Track maintenance costs decrease radically (reflecting the change from cast iron to worked iron rails). Engine purchase cost +100%.

End of Stage Three:
1829. End scenario, enter normal RRT3. Trevithick's "Catch Me Who Can"/Steam Elephant 0-8-0 or Salamanca 0-6-0 no longer available. Purchase cost of engines goes to normal pricing.
1845. Royal George 0-6-0 and H. R. Campbell's 4-4-0 no longer available
1850. Grasshopper 0-4-0 no longer available

Scenario Objectives:
Bronze: Haul 100 loads of coal + 100 loads of iron ore + 100 loads of logs + 50 loads of weapons (to Boston?).
Silver: Bronze + Connect Boston with New York + lifetime industry profits >= $10 million.
Gold: Silver + Connect Boston with Albany and Buffalo + lifetime company profits >= $25 million.

[Gumboots]

Ok, all the moving parts on the Pen-y-darren can be done, with the exception of the intermediate gear on the right hand side. The catch is that gear would have to rotate backwards to be realistic, and there's no way of getting reverse rotation in RT3. It might be possible if you can figure out how to hack animation files, but those are something I haven't managed to decipher yet. It's definitely not possible with standard locomotive files.

The rest is no problem though. The connecting rods on both sides, and the flywheel and piston, are all easy to do. If you want to sort a few other things out, switching the chimney to the rear of the boiler wouldn't be hard either. Ditto for custom tender.

Excellent news that. Thank you for looking into it.

I figure maybe using an x-8-x model (like the Consolidation 2-8-0), remove the x's, and rotate one of the drives. That might get the job done for a retrograde motion, it's a trick that works with the model animations in other games. If not, my thinking on the matter is "ok, so the intermediate gear is going the wrong way, cry me a river." TBH, I'm more concerned about botching the normals by forcing a rotation along an x,y,z axis than getting the animation spot on.

Nope, that won't work. The game's loco drivegear animation is really basic. All you can do is make wheels. These roll along the ground. That sets which direction they roll and how fast they roll. This means you can't make them go backwards. No can do.

Anyway, conrods and pistons are driven off the wheels, so that part is going to be fine. It's only the intermediate gear that will be borked. The basic idea is your flywheel is coded as a normal drivewheel, but just has graphics that don't reach the ground. This is fine. It will still spin in the right direction, and it will still make the piston and linkages work. Your actual wheels are going to need one pair coded as drivewheels to make the coupling bars work, and the other pair as just normal wheels. This way it will all go round and round just fine, apart from your intermediate gear. That can be a normal wheel too, but will spin the wrong way. Hey ho.

[Gumboots]

Oh and while I think of it: there's another dodge you can use to adjust wheel rotation. The rotation speed depends on 1/ the diameter (obviously) but also 2/ the X axis value of the "wheel attachment point" for want of a better name.

Setting the WAP further in or out sideways makes the wheel speed change, so you can use that dodge to have different wheels doing different revs. This might be useful.

And your scenario concept sounds like a good one.

[Just Crazy Jim]

Updated stats for the Pen-y-Darren

About cross-eyed from fiddling with hex code and maths... time for bed :D

[Gumboots]

Now for the fun part: put racing stripes on it and set top speed to 1,000 mph. You'll love it.

[sleepy]

RT3 has a problem with a lossy save formula.

This game never fails to surprise me with its "quirks"...

[Gumboots]

If this starts to look promising, I will get to work on making custom content locomotives for the prototypes. A team of horses as a locomotive will be the closing phase of this madness. I've never done much with Blender, mostly because the interface gives me a tendency to cuss the paint off the wall. I've worked with MilkShape 3D, since it had import/export plug-ins for the games I played. But if Blender is the tool that must be used, then Blender it will be.

Out of idle curiosity I just took a look at the info page for MilkShape 3D. It won't import RT3 .3dp files, but will import and export .3ds, .fbx and Wavefront .obj files.

These are also default options for Blender, and we have the import/export script for .3dp/.blend anyway. So if you aren't into messing with Blender and would prefer to work with MilkShape that should be fine. Just import the .3dp into Blender, then export as .obj or whatever, and import that to MilkShape. Reverse to procedure to get a playable custom .3dp.

Basic imports and exports to and from Blender aren't much of a strain on the brain.

[RulerofRails]

The discussion moved right along, so this will seem out of place compared to the current conversation topic. Just to say that when I was explaining that the in-game read-out is wrong, I forgot to explain the probable cause. The cgo file has a "weight" figure. Both the cgo and car files have identical weights in the default game. Turns out the cgo figure is inactive. Whoever setup the in-game readout, counted both the cgo and car file weights. This effectively makes the read-out an entire scale ahead. What you see in 1900 in the default game (weight goes up by 2x each change) is accurate for 1950. If you mod any cars, don't bother with the cgo file weight.

[Gumboots]

You're not quite right there, but it does remind me of another possibility.

The deprecated .cgo weights are double the weights in the .car files. So a 40 ton freight .car will have a .cgo setting of 80. It may be that the pop-up stats were set to use the .cgo figure back in development, and this was never corrected due to time and money constraints.

But yeah, the .cgo weight can be ignored. I set it to zero in any files I modify. Same for tenders. I set them to zero, and just do weight adjustments on the locomotive itself. The gives exactly the same result, but is simpler.

[Just Crazy Jim]

If this starts to look promising, I will get to work on making custom content locomotives for the prototypes. A team of horses as a locomotive will be the closing phase of this madness. I've never done much with Blender, mostly because the interface gives me a tendency to cuss the paint off the wall. I've worked with MilkShape 3D, since it had import/export plug-ins for the games I played. But if Blender is the tool that must be used, then Blender it will be.

Out of idle curiosity I just took a look at the info page for MilkShape 3D. It won't import RT3 .3dp files, but will import and export .3ds, .fbx and Wavefront .obj files.

These are also default options for Blender, and we have the import/export script for .3dp/.blend anyway. So if you aren't into messing with Blender and would prefer to work with MilkShape that should be fine. Just import the .3dp into Blender, then export as .obj or whatever, and import that to MilkShape. Reverse to procedure to get a playable custom .3dp.

Basic imports and exports to and from Blender aren't much of a strain on the brain.

Heh. Again, you are reading my mind. My plan is to try doing precisely that.

If it works out, fine. If not, well, sometimes that's the way it breaks. At least, with RT3 models I won't have to set complex weights on the vertices to seamlessly mimic a variety of human animations. Here, it's just the wheels go round-and-round, bits go to and fro, and keeping everything close to the center-line of the track.

At least, that's what I keep telling myself. Don't burst my bubble quite yet.

I've generally used LithUnwrap in the past for UV-mapping. But that's the same story as MilkShape 3D, if it works, yay! If not, oh, well.

The discussion moved right along, so this will seem out of place compared to the current conversation topic. Just to say that when I was explaining that the in-game read-out is wrong, I forgot to explain the probable cause. The cgo file has a "weight" figure. Both the cgo and car files have identical weights in the default game. Turns out the cgo figure is inactive. Whoever setup the in-game readout, counted both the cgo and car file weights. This effectively makes the read-out an entire scale ahead. What you see in 1900 in the default game (weight goes up by 2x each change) is accurate for 1950. If you mod any cars, don't bother with the cgo file weight.

You're not quite right there, but it does remind me of another possibility.

The deprecated .cgo weights are double the weights in the .car files. So a 40 ton freight .car will have a .cgo setting of 80. It may be that the pop-up stats were set to use the .cgo figure back in development, and this was never corrected due to time and money constraints.

Good to know. I had read some about how the consists were calculated. My thinking was along these lines: The cars/wagons are representational of annual output, not a precise real world unit per se. Because, really, if a coal mine only produces 2 wagon loads of coal per year, that coal mine is going to fail hard in the real economic world.

Also, I have this hard and fast rule: If I don't understand something, don't, just don't. I learned this years ago when I hacked just one Homeworld (maybe it was Homeworld 2) file on a Cyrix-based IBM laptop... all the graphics were carried on the CPU, having 100 (can't remember the exact number, but it was the max allowed) extra models fly out of the mothership after the jump caused the CPU to run so hot it melted the innards of the laptop. Which unbeknownst to me, was a known problem with Cyrix-based ThinkPads. Point being: Lesson learned.

[Gumboots]

I've generally used LithUnwrap in the past for UV-mapping. But that's the same story as MilkShape 3D, if it works, yay! If not, oh, well.

Hmm. Might as well just just use Blender. It does the lot in one app.

[Just Crazy Jim]

I've generally used LithUnwrap in the past for UV-mapping. But that's the same story as MilkShape 3D, if it works, yay! If not, oh, well.

Hmm. Might as well just just use Blender. It does the lot in one app.

You're probably right, but grandpa hates change...

Speaking of change....

While viewing the GMP for my scenario in HexEdit to repair the lossy save, I noticed that edits I have made to the events, like deleting an event in the editor, really don't seem to be deleted from the events section of the GMP. I recognized this because of a distinctive phase I used as filler for the 2nd panel of the Newspaper popup as a placeholder in one event (now changed to something else). I won't share that phrase with you, but - believe me - it's a real scorcher and no random hex arrangement would approximate it. So I spent some time crawling through the event section of the GMP file (what thrills we have here at my house) and found several other events I had deleted were still resident in the file.

Where I'm going with this is this: My speculation is that there is a point that repeatedly editing the file will cause the GMP (like a Word Document file) to become so bloated with useless data as to become unplayable/unloadable/unrecognized by the EXE.

Not that I'm in a rush to edit my way through 7,800,000+ hex values to trim out useless bytes, but if a man were bored enough (and careful enough) is there a guide or note that documents what is safe to strip out? In this case, I would strip Go West!.gmp down to its base and start over.

[Just Crazy Jim]

Well another fruitful experiment with events. getting the economy to flatline for 3 years has been a challenge in 1.05. I finally figured it out, but the interface and the guides were only so helpful for giving me what I needed to know.

Set the conditions for >YYYY (or >YYYYMM) AND <YYYY (or <YYYYMM)
Set to check weekly *
Set one time event as unticked
Set effect Economic status = 0

* I never even knew there were weeks in this game, but now knowing that there are, it explains why I can't always issue stock in a given month even though it has been 12 months since I last issued stock. How do you see what week it is? I even dug out my old hard copy manual from 1.0 and it never mentions weeks, not even once. And as for what it offers about using the editor... well, that could be charitably paraphrased as "Oh, yeah, there's an editor. Good luck with that."