Writing Events to Count Trains?

[matthew s]

2023 and you are still learning how a game from 2 decade ago works. That says something amazing about our game and you specificly. Love it.

[Gumboots]

For some unknown reason, I was just thinking about this again. It just popped into my head after a long absence.

Anyway... I may still set up a test example of the events proposed earlier in this thread: the ones that aim to allow purchasing pre-defined numbers of particular classes, for both one delivery territory and two separate delivery territories. I think those are feasible, and it would probably be a worthwhile experiment. If it can be made to work, someone will probably use it sooner or later.

However, I am currently thinking the best option may be to just use one placeholder class (small and/or obsolete) to keep the game engine happy all the time, and just use allow/disallow purchases of the relevant classes at the right times. This is very simple to code, and would not have to be tested and proofed against weird RT3 shenanigans. It will just work. Doing it this way won't allow restricting purchases to a specific number of locos, but it will still approximate the real life situation. Purchases (and maybe saving for them) will have to be made with forethought, and you won't be able to endlessly spam a class outside the set purchase windows. You could also still include a requirement for some sort of deposit in advance, just a set amount that approximates a realistic deposit.

For an example, take the Class 6N in the NSW scenario. In real life there were only two of them, purchased in 1863. In the NSW scenario (as currently coded) you tend to end up running 6N's all over the place, simply because they are a good unit for the early to mid 1860's. If you could only purchase them for one month in 1863, you wouldn't be spamming them in 1864. The roster would more closely approximate the real roster, without requiring terribly convoluted code and extra territories. Six months in advance of the purchase window you could be charged 25% (or whatever) of the cost of a few 6N's. If you don't want to pay the deposit, you don't get the purchase option six months later.

I could test this on a modified copy of the NSW scenario and see how it goes.

---

Edit: Just thought of something else. If anyone wants a placeholder locomotive, for any scenario, it would be easy to make one that had no graphics and no actual hauling power. You'd just need the .lco and .car files set to appropriate stats (ie: pulling power = 0, free weight = 0, loco weight = 100, fuel economy = 10, acceleration = 1) plus a simple body file (no actual mesh, just basic file calls, etc) plus one 16x16 DDS as the required texture image (even though it would be blank). It could have purchase price set to $1k, and start date set to 1830 so it sits at the bottom of the loco list, out of the way. At $1k cost it would not matter if anyone accidentally bought one.

Locomotive type could be set to steam, diesel, or electric. Making three placeholder locos, one for each type, would be as easy as making one. Then you are covered for any scenario where you want a placeholder available all the time, just to keep the game engine happy, but you don't want it to do anything else.

[Gumboots]

Just thought of something else. This may not work...

Ok, how to prevent this? If you buy the legitimate number of locos, your company cash after the purchases will be exactly 0. If you cheat by letting trains crawl into stations, then buying more locos than you should, it is very unlikely that your company cash will exactly equal 0 when you are done. Even when you try to run it down to 0 by laying and bulldozing track, you will usually get a pop-up saying you don't have enough cash to bulldoze even one section, but it will still not be exactly 0 (ie: might be $458 or whatever).

So, if you have a check on the second (reset) event, such that you can only trigger the reset if your company cash is exactly 0, that should provide a strong disincentive for cheating. It would still be theoretically possible to unload a train that was carrying an exact multiple of a loco price, but I think arranging that in practice would be very difficult.

The reason is that you have to place at least one section of track in the trigger territory to trigger the purchase event, which means company cash has to be set to loco purchase amount + cost of one section of track. But, the cost of one section of track with 0% grade is $1.48k (see post here). This means you can't set company cash to be exactly equal to loco price + one track section, because you can only set company cash in whole $k.

The closest you could get it would be to set company cash to loco purchase price + $2k, and then check for company cash < $1k after purchases. That will still allow shenanigans, because when trashing entire companies for robber baron tricks it's common to use build/bulldoze track to get company cash under $1k.

Short version: the "clever, easy, and bulletproof" option won't work. You are going to need something more convoluted. If you want to restrict purchases to defined numbers of defined classes, using a separate company for purchases is probably the best option. This could even be used while still allowing robber baron tricks on other companies, if you set up a restriction that the purchase company could not be merged (ie: Company #2 must always exist).

[Gumboots]

Aha! Brainwave! It can be made to work.

The relevant event trigger option is "When track or a station is placed". Stations are always a fixed price, in whole $k, so you could set company cash to loco(s) purchase price + one small station ($50k). That would allow using a small station to trigger the reset event after purchasing locos, and company cash would end up exactly zero.

---

EDIT: Just thought of another caveat.

The idea of using a small station as a trigger will work, but it means the trigger territory has to be large enough to accept a small station. That rules out using one or two squares of land surrounded by ocean. Offhand I don't know the minimum acceptable size, but having water nearby also adds the "Too close to ocean, etc" restriction on station placement.

Presumably there will still be plenty of space on the map to make a suitable trigger territory somewhere. The only possible catch is that if you provide enough room to build a small station, the AI might build something there while it was controlling the loco purchase company (if you are using one). A simple way to prevent this would be to make the entire trigger territory reserved cells. That will stop the AI building there, and will also stop the game engine seeding anything there. The territory will always be empty, and available for placing a small station.

---

I thought of an added refinement too. Disallowing the reset event if company cash is not exactly equal to 0 will work, but is brutal. It is instant end of the game if anyone tries to cheat it, or even if anyone makes an honest mistake.

So, the added refinement would be to allow the reset event (getting your original company state back, minus loco purchase cost) even if company cash is not exactly zero, but penalise your company for the assumed attempt to cheat. There are plenty of options for dialling in suitable penalties (company cash, credit rating, economy state, etc).

EDIT 2: One of the best penalties might be dropping loco reliability by two or three levels for 12 months. That adds an element of randomness without requiring much in the way of code.