Writing Events to Count Trains?

[mukpile123]

Quick question: "Can you write an event that counts the number of trains you own?"

Basically, I want to limit your ability to purchase locomotives in a scenario I'm building; I'm doing this in the 1.05 version of RT3, if that's of any significance. I've already figured out how to limit what types of engines your can purchase and I've also crafted a choice event which allows you to pick which of 3 engines you want to be available for purchase. However, in order to keep this scenario balanced and historically realistic, I would like make an event that prevents you from buying any additional engines once you've purchased your first one.

So, is this something I can feasibly code, or should I head back to the drawing board?

[RulerofRails]

This is a no-go. As far as I know, RT3's train ID# system is bugged somehow. In Patch 1.03 there was a trigger that appeared to allow the effect "Retire Train" to check ID#. But when I tried it, it would only retire the train at the top of the list. By patch 1.05 this trigger had been dropped entirely. Functionality of the effect "Retire Train" is still the same IIRC: you will get rid of the first train on the players list. Please note that I didn't do a dedicated "test" to analyze the behavior, just casual observation, don't take my word for it. But, of course, even if this worked there is no way to check for number of trains owned.

But as with a lot of things there are nefarious workarounds, not pretty, with some less than great side-effects (such as fixed starting location), but you can control engine purchase in a crude fashion. It may constrict playstyles in your scenario, but if it's sufficiently important to the story, please give me more details of exactly what you want to do. Is it only one engine for the entire game?

There is the possibility to use a confiscate event for an engine bought when setting the map up in the editor (fixed location, could have others available later). An example is the PopTop campaign "War Effort." Another possibility is to tightly control cash amount for a period, see Gilligan's Isle for 1.06. This map tightly restrains economy throughout, but for one engine in early game consequence in otherwise unrestrained economy may be semi-manageable.

[mukpile123]

I kinda want to keep my scenario private until it's ready to be beta tested, but I can give you some general details about how I was expecting it to work.

• The primary objective of the scenario is to connect a port city to a bustling city far inland, with the secondary objective of hauling a certain quantity of freight to each city.
• Historically, the railroad company that will be portrayed in this scenario had access to primarily second-hand locomotives that were either salvaged from local mining/logging railways or slowly shipped up the coast by boat . This scarcity meant that this railroad company would have only had 1 or 2 engines operating on the entire line for the first couple of years.
• The map terrain is extremely mountains, so there is very little room for cities to build their houses; definitely not enough room for several branch lines dedicated to several engines that would be spawned in during map generation.
• What I was hoping to do was just have an event count how many engines your company owned, compare that number to a set value (in this case, 1), and then determine if you are allowed to purchase a new train / replace your existing one.
• As more cities are connected, similar events would be triggered that would allow you to buy more engines.
• This forced scarcity is meant to give this scenario a uncommon twist which would cause players to treat each engine with extra attention and care, since they wouldn't be able to instantly replace / upgrade them at the drop of a hat. While some people will probably view this game mechanic as restrictive and limiting for game-play, I see it as clever and genuine way of infusing interest back into playing the game.

Anyways, I've still got an idea or two to test out before I call it quits on this for today, so I'll check back in later to see if any more solutions pop up.

[Gumboots]

You'll need to fudge it with some sort of workaround, because there's no way of coding events to count locomotives.

TBH I hate the RT3 editor. They filled up the event options list with all sorts of crap that nobody ever has any use for, presumably because they weren't really thinking and just kept mindlessly adding things. There's a lot of potentially useful information that the game engine keeps track of, but there's no way of using it in events.

[mukpile123]

Yeah, it's so frustrating trying to get the code just right so that it does what I want it do; feels like I'm painting the Mona Lisa with only a brush held between my toes .

Just now I tried to be clever and make a work-around. Unfortunately, there several roadblocks to that idea:

1. I was hoping that there was some code that would force the game to spawn an engine at a particular station (I knew it was possible to spawn buildings at specific coordinates, so why not locomotives too?), but there weren't any such commands to be found.
2. There doesn't seem to be anyway to toggle Special Conditions on/off, so I can't just switch "Disable Buying a Train" on and off at will.
3. And no matter how I set-up the "make all steam engines unavailable" command to occur, the game seems to override it so that there is always 1 steam engine available for purchase.
   

[Gumboots]

1/ Nope, no can do.
2/ Nope, no can do. However, you could do things like temporarily setting purchase price to an insane level.
3/ Yup, it does that. It's a train game, so the .exe will always insist on having some available.

[RulerofRails]

TBH I hate the RT3 editor. They filled up the event options list with all sorts of crap that nobody ever has any use for, presumably because they weren't really thinking and just kept mindlessly adding things. There's a lot of potentially useful information that the game engine keeps track of, but there's no way of using it in events.

Yeah, it's too bad. I suspect probably there was a time factor involved and they just did the easy ones to fluff it with more "options."
.

---

.
One quirk of the game is that you can't forbid ALL locos from being purchased (unless you use the editor option to forbid buying locos entirely). When use an event and the checkmarks to set all to "Unavailable", the game will always spit out a random one to use. So when using confiscation events, for loco allocation, I would probably have a small ugly one like 2-D-2 or Crocodile as a dummy. If your scenario is realistic, I would guess that no electrics will be used, then all you need to do is a steep drop (-99%) the pulling power of electrics. (Pulling Power can't be adjusted on a per loco basis, only overall, for steam, for diesel, or for electric.) Might be wise to hike purchase cost, and maybe maintenance as well. You can disable retiring and replacing trains in the editor, so this mean that the player would be stuck with them and couldn't use them for exploit to store/delete cargo.

Here's some more details on possibilities, you will probably have to adapt for what you want. I haven't tested these ideas in combination in-game, so there's probably some gaps/pitfalls I can't forsee. Good luck!

Confiscation:
Well, if the locos are arriving at a port, but with tight space, maybe a tunnel (just for fun: could also experiment if you could partially sink a maint. shed into the mountain). Obviously, the engines will have to be lined up inside the tunnel and each have a separate territory (that's how confiscation influence is controlled). I don't think being invisible to the player is necessarily a problem because they will show up on the train list, which will be short in the first place.

You can also confiscate track as well, so if you wanted it based on cities connected you could have the setup that a tiny piece of the choreographed route is pre-laid, and test for territory is connected to maybe the port or main city. . . . Then as soon as you connected this track piece to your main line, the engine and track would be yours and appear seamlessly in your network.

Letting the player purchase in restricted circumstances:
The problem with price control for a short period is that there is no instant trigger that can be used (track laying/station building is the most immediate, but wont work here). So you need to plan for one week where there could be possibility for exploit if some large revenues came in. Obviously you need to set cash (dependent on loco price). To sidestep incoming revenues this as much as possible you can set industry production -99% and also train speed -99% for the week. If issuing bonds is allowed, credit rating should take a big drop (at least -20). The only way to side-step a stock issue would be to disable that option in the editor. Even after all this, a clever player might just manage to get a train to arrive in that week anyway. To get around this, you could require a large amount for purchase such as $1M. The side-effect from is that this will be quite a lot of hidden book value (the value of confiscated items don't appear in the ledger), and should the train crash, that will smash your book value. Might be wise to disable crashes entirely.

[mukpile123]

Yeah, hiding some engines in that tunnel idea sure sounds like an interesting idea to me. But I think I'll go along with scheme of making a crummy near-useless engine as the only available locomotive for sale. I think I'll use the Dorchester 4-4-0, which really makes sense when you think about it: small, light locomotives would be exactly what you'd find pulling carts around at a local mine or logging railway.

Great! I just set it up so that this is the only type of engine you can reliable purchase at the drop of hat while you wait a few months to import your real engines.

Now all I have to do is figure out how to keep exploiters from purchasing several dozen imported engines all-at-once when they are temporarily available, which doesn't sound like it's going to be an easy problem to solve. Oh well! "Let's get to it!"

[Gumboots]

I have just been thinking about this concept. My thinking was related to my NSWGR scenario, and I was wondering if there was a way of keeping loco purchases to more or less what the railway actually purchased in any given years. Not that I necessarily intend to implement it for that scenario, but I was wondering about proof of concept. I think there is a workable way to do it.

You would have to start with the plan mentioned in this thread: set one class of (nearly useless) loco available, to keep the game engine happy. Then use set events to give the option to "purchase" locomotives of a set class (or classes) at the desired intervals. This can be done simply by using "make available" and "make unavailable" events wherever you need them.

To control how many locos could be purchased at any one time, you might be able to adapt the system used in AoS V and some other scenarios. Instead of laying one unit of track in a special territory to get the option to buy more track, you might be able to use it to get the option to buy a locomotive or a series of locomotives. It would require some way of making you lay a track unit to confirm each purchase, and counting the number laid via a variable, which then sets the locos to unavailable when you have used up the quota for that period.

I think it can be made to work, but will have to do some more thinking and some testing before I can be sure.

Edit: Here's another idea. It may be possible to use a choice event, triggered by the intial laying of one track unit. The idea being that the choice event then becomes your confirmation of purchase, and simultaneously sets locos to unavailable again, so that you then have to lay another track unit to purchase the next loco.

[RulerofRails]

Don't know how such an event should be "coded" (setup). Good luck! Hopefully the game doesn't let you down.

[Gumboots]

Thinking about RT3 again, after a break (as you do...). I don't think this can be done, or at least not easily.

You can set up a trigger event a la AoS V, but once you trigger it there are no editor options that would allow you to automatically trigger something else when you purchase a loco.

You could set up a series of territories that had locos stashed in them, and trigger a confiscate event, but that is going to mean a lot of territories and a lot of stashed locos, and of course in terms of maintenance/reliability they start degrading as soon as they are in the game. I can't think of any way of reusing the territories or refreshing the locos either (ie: there's no "spawn a loco of class **** here" option).

So, AFAICT that's not really practical either, except in particularly limited circumstances. It would be possible to use it for some conceivable situations, but they will be very limited. Which is, as is common with RT3, a nuisance.

You could do it on an honour system, where you trust the player to lay a second section of track after every loco purchase. That could easily be used to trigger the required events to limit purchases to whatever you wanted, but of course it's easy to exploit (you simply don't lay the second track section, and you get unlimited purchases).

---

Ok, other workarounds... I have a couple of ideas. These would only work in 1.06 (1.05 cannot set the necessary variables).

If you know the number of units you want to limit purchases to, and the class of them, and the cost per unit, you could use the "lay one track section" to trigger saving current company cash as a variable, and current company debt as another variable, and current stock price as another variable. You could also save current book value if necessary.

The plan here is to save the current financial state of the company immediately before allowing loco purchases, then compare that with the company finances after the loco purchases, and do something thoroughly evil if the player has bought more locos than they should have. I think this could be made to work*, in a somewhat convoluted and nefarious manner. It could even add extra interest if done carefully (the player would have to decide if having the extra locos was worth the penalty).

One obvious penalty would be a hit to credit rating. Another would be eviction from your position as chairman (so you'd need enough stock to get back in). This is still of limited applicability though. If you just want a straightforward number limit to loco purchases, you're basically out of luck. The editor simply won't let you set that up.

*The only catch I can think of is: what triggers the next check on company finances, after you by locos? It could be done by a timer (automatic check after one week, which I think is the minimum time the game will do). Not sure if there are any other worthwhile options.

[Gumboots]

I figured out how to do this (for 1.06).

Note: This can't all be done in 1.05, because 1.05 can't use a variable to set the value of another variable. That means setting a variable to company cash value is impossible in 1.05. However, this entire scheme will work in 1.06. The credit rating and stock price changes also work in 1.05.

---

Assume company cash is enough to buy the limited number of locos you want to allow.
An event is triggered by laying one track unit in a trigger territory (a la AoSV) and it does this:

1. Set credit rating to -6 levels (ie: no issuing bonds).
2. Set stock price to -95% (ie: to prevent issuing stock).
3. Set a variable to the current value of company cash (so you can restore it later).
4. Set company cash to loco price multiplied by allowed number (ie: $100k x 4 units).
5. Set loco to available. Player can now buy 4 locos.

The player now goes and buys 4 locos. Their company is broke and has no credit.
A second event, triggered by laying a track unit in another trigger territory, does this:

1. Set credit rating to +6 levels (ie: back to original level).
2. Set stock price to +95% (ie: back to the original price).
3. Set company cash back to the stored value of the variable.
4. Subtract the value of the purchased locos (ie: $100k x 4 units = $400k).
5. Set loco to unavailable again. Player cannot buy more locos.

Result: the company is back to its original state, except that it now has four new locos of the allowed type, and the cost of the allowed locos has been deducted from company cash.

---

Re credit rating: A rating of AAA has to be dropped 6 levels (to CCC) to prevent taking out bonds. If the credit rating is D, minus 6 levels puts it at F (the lowest level the game displays). However, the correct value will always be stored internally, even if you start with a rating of BB and drop it 20 levels. When you add 20 levels back to it, the rating goes back to the original BB. This means minus 6 levels will always be fine, regardless of what the credit rating is. The reset event will always put it back to the correct value. This will work in both 1.05 and 1.06.

---

Re stock: Issuing stock after the first event could give you more cash and more locos than intended. You can't disallow issuing stock temporarily, and you can't store the current stock price as a variable (not even in 1.06). You can get "player stock value", but you can't get the current price per share. The solution is to use the first event to massively drop stock prices (-95% seems good) then have the second event restore the original stock price.

This works, but with a twist. You have to boost it by +95% in the second event to restore the original stock price. In this instance RT3 is taking the original stock price, storing that value, deducting 95% of that in the first event, then correctly calculating 95% of the original price in the second event, The test case was a company with 420,000 shares already and a share price of $51. Dropping that price by 95% results in the game refusing to issue stock. This works in 1.05 and 1.06 too.

---

It still needs a couple more safeguards. It would need a way of preventing human error screwing the game, by accidentally triggering the second event first. That could set your company cash to zero (default value of any variable) with no way to get it back to where it should be. A condition/tracking variable of some sort is necessary here, but I'm sure this can be sorted.

I can think of one other possible issue: what happens if a trains crashes? Breakdowns are no problem, but a crash will remove one of your locos from play, and if you have a strictly limited roster size that could screw the whole game for you. So, I think this would have to be done with crashes disabled. I would leave breakdowns enabled, but that is personal preference.

---

Edit: After re-reading the earlier posts in the thread, there is one more possible exploit. I was assuming this would all be done with the game paused. However, if the game is left to run for a while before triggering the second (reset) event there could be a lucrative amount of cargo dropped at a station, or some significant industry profit generated. That needs to be nobbled too. The simplest option seems to be to treat cargo prices the same way as stock price: just drop them all by 95% in the first event, then restore them in the second event. This will ensure that if someone tries to cheat by leaving the game running between the two events, it won't do them any good. It will also mean they will have to trigger the second event to make any more progress in the game, which is an incentive to do it all on pause. This would all be explained in the briefing, so should be fine.

Also, re event triggers: there is the option of using "After an event choice" creatively. If dropping one section of track in the trigger territory brings up a choice, maybe that can be used to set a variable value to track the number of locos purchased (although I haven't thought this through yet). But even without using that, it's clear that restricting numbers and classes of locos is feasible, while still preventing exploits.

[RulerofRails]

Sounds like a decent plan, for situations with limited track laying, no issuing stock, and no stock market. You didn't mention revenue that's coming in. Suppose we have a train arrive during the week. Revenue for a train can easily be >$100k.

I mentioned above that setting industry profits and train speed at -99% might help. But there's always a bit of an "if", a train might just arrive anyway, possibly through no fault of the player in trying to "abuse" the system. This is why scenarios like Gilligan's Isle used a higher value. Around $700-800k per engine if I recall correctly. Higher engine costs do "mess up" book value though. But if the stock market is disabled and CBV is not a scenario goal, AFAICT there is no obvious downside.

PS. NSW quite handily meets all conditions I mentioned.

[Gumboots]

Sounds like a decent plan, for situations with limited track laying, no issuing stock, and no stock market.

This system already deals with the stock market and stock issues. That's no problem at all. Neither is unlimited track.

I just dropped in an edit about incoming revenue. That can be dealt with the same way stock is handled. If cargo prices are (temporarily) near enough to zero, industry profits will be too. You could also drop industry production. And, as you say, you can drop train speed. You could even drop train reliability to the minimum. If you encourage the maximum amount of economic havoc with the first event, anyone with half a brain will probably pause the game to do the loco purchases.

---

I suppose someone could still try exploiting this if they really wanted to. What they could do is set up a stack of lucrative trains stopped just before suitable stations. Once the trains were all lined up you would pause the game, trigger the first purchase option event, un-stop the trains, and wait until they had all crawled into their stations and dropped their cargo. Then you could go nuts on loco purchases.

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.

And, if you go with that safeguard, you don't really need any of the others. That alone would be enough to prevent any shenanigans. It's brutally effective. It's also not at all tolerant of human error, but the briefing can explain the situation clearly (and can also recommend saving before triggering loco purchases).

[RulerofRails]

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.

Sounds pretty cunning.

I can explain a bit better what I was thinking. If an effect design to thwart stock issuing, also "modifies" the stock price in some way, what will prevent the player from buying some very cheap shares with his personal cash/margin?

I mentioned limited track laying. The possible shenanigan here is if loco price is high and the player could use the money for locos for something else. With your idea above to give a more robust defense from arriving revenue, this becomes less and less cause for concern.

It will be interesting to see this idea in practice.

[Gumboots]

I can explain a bit better what I was thinking. If an effect design to thwart stock issuing, also "modifies" the stock price in some way, what will prevent the player from buying some very cheap shares with his personal cash/margin?

Good point. Obvious option: also save the initial value for "player stock value". Check that again in the second event, after boosting the stock price back to its initial value. If PSV > GV2, do something evil.

But really I think just checking for company cash = 0 is going to be the simplest and most bulletproof solution.

I mentioned limited track laying. The possible shenanigan here is if loco price is high and the player could use the money for locos for something else. With your idea above to give a more robust defense from arriving revenue, this becomes less and less cause for concern.

True, they could. However, if they are short of locos they will probably go for locos anyway.

The other way of doing it would be to make it a limited track scenario, and temporarily set buildable pieces to zero with the same event. That could work even if you did not want track to be a limitation most of the time. You'd just set it to 50,000 or whatever at the start of the game, then set to 0 whenever you wanted to stop them building, then back to 50,000. If it's meant to be unlimited most of the time there would be no need to save the current number of pieces as a variable.

This could be useful in some situations even if you did not want to restrict loco purchases, like if you wanted to emulate the effect of a large flood that made track building temporarily impossible.

---

Just thinking some more, taking the NSWGR as an example.
In 1865 they acquired:

1. 3 units of the 14 Class
2. 6 units of the 17 Class
3. 9 units of the 23 Class

That's 18 locos, of 3 classes, with 3 different purchase prices, all coming in one "shipment". That's a lot of scope for human error in purchasing them. To be fair to the player I think there would have to be a safety feature built in, so that it wasn't too confusing. Realistically, this probably means three different events: one for each class.

That way all purchases controlled by that event are the the same price, and the cash provided is an even multiple of that price, and no other loco classes are available until you trigger the next event anyway, so it's pretty much impossible to make a mistake. You just keep buying choofs (ie: 14 Class) until cash is zero. Easy. Then you would have a second event that handles the next class (17 Class in this case). Then a third event handles the third class (23 Class in this case).

[Gumboots]

I went through (most of) the list of which locos NSWGR had delivered in which years. After looking at that I think going for complete historical accuracy would be bonkers.

I still like the general concept of restricting purchases. It could give the general feel of the actual historical situation in a lot of scenarios, and it should make the player think more about purchases and how they get assigned. So, in the interest of sanity (ie: keeping a game as a game instead of a bizarre new method of torture) I think some reasonable compromises would be advisable.

Any scenario that wants to use this concept may run into similar issues, so they are worth thinking about. Off the top of my head:

1. Obvious first point: the number of orders should be kept to a sane number with sane spacing between them.
2. If multiple classes are "delivered", and you pay full price on "delivery", each class should have its own event.
3. However, I like the idea that locos have to be ordered in advance, like they would in a real situation.
4. Six months feels good (you should have an idea of what you will want, but you need to think).
5. I also think there should be part payment in advance. Again, for added realism. So...
6. Six months in advance you get a choice to order more locos, for $***k deposit.
7. You can decide to order all classes, or decline one or more available classes.
8. If you decide to order, the deposit gets deducted from your company cash.
9. You get notified 6 months later, and drop a track unit in a trigger territory.
10. Company cash gets reset to $**k x number of units.
11. You buy any available choofs until the cash runs out.
12. Drop one more unit of track in the trigger territory to restore original cash balance, etc (minus "delivery" cost).

Although, part payment in advance does open up another option for "delivery". Different classes will probably have different price tags, which is why you would use separate events. But you could do it this way...

1. The "deposit" payment could be calculated so the remainder is the same for all classes.
2. IOW, calculate the deposit based on historical orders, but allow the player to vary the "delivery".
3. This allows a simplified "delivery": you get cash for x locos, and choose how many of each available class.

This may result in locos costing more, if you "deliver" a cheap class after paying a deposit on an order which included an expensive class. OTOH, if the more expensive locos were more immediately useful (not necessarily true) then you might get them a bit cheaper this way.

Doing it that way is more flexible strategically, with more replay options, and means multiple classes could use one purchase event. I can see this being made to work with up to three classes. Choice events give four choices, so as an example...

1. Do not order anything.
2. Only order one class (freight).
3. Order two classes (freight and mixed).
4. Order all classes (freight, mixed, express).

All of these possibilities should not be hard to code, particularly if the simple option of checking that company cash = 0 after "delivery" can be used to prevent massively exploiting the purchase procedure. It's probably time to run some test cases and see what happens.

[Gumboots]

OK, next step: the actual choice events...

If the roster is restricted you will probably always choose to buy some locos when you get a chance. That means you probably don't need the option of not buying any locos. So, the remaining possibilities are:

1. Buy freight locos only (F).
2. Buy mixed locos only (M).
3. Buy express locos only (E).
4. Buy F + M.
5. Buy F + E.
6. Buy E + M.
7. Buy F + M + E.

These can be covered by two consecutive choice events.
First event:

1. Buy freight locos only (F).
2. Buy mixed locos only (M).
3. Buy express locos only (E).
4. Give me more options.

If you want more options, you get the second event:

1. Buy F + M.
2. Buy F + E.
3. Buy E + M.
4. Buy F + M + E.

Then, based on whatever you selected, the deposit gets calculated and deducted from your company cash. That part should be easy. Six months later you get your delivery options. Those should be easy too, since they are just a matter of calculating "delivery" charges, setting company cash, and making locos available.

[Gumboots]

Just had another idea. This will only work if you have the ability to change companies, which means an active stock market, at least to some extent.*

IRL any money paid for locos would go to the manufacturer, and possibly to a shipping agent (ie: in the case of imported locos). So, you could set up a separate company for manufacturer/agent**. The process then could be:

1. Get a pop-up warning you to order locos.
2. Say yes, me want locos, and pick which ones you want.
3. The deposit amount gets deducted from your company cash.
4. Six months later you get "delivery", and have to pay the balance.

So far this is the same as the other way of doing it. Now comes the tricky part...

1. The company for manufacturer/agent is restricted to a small territory, with a low credit rating.
2. This means it can't do anything. It just exists to buy locos (life support for it should be feasible).
3. The deposit from your company cash becomes the manufacturer/agent's company cash.
4. This gets coded as company cash = $****k, so the previous balance gets wiped.
5. You swap companies, buy locos, then resign from the manufacturer/agent.
6. Resume chairmanship of your main company.
7. Run a confiscation event on the new locos.
8. You have the right number and classes of new locos.

The company jumping is a slight inconvenience, and will also cut your chairman's salary. The advantage is that it is almost impossible to exploit, and would be tolerant of human error. It would not be necessary to pause the game to make this work. You could let the AI run your main company for 5 or 10 minutes while you sorted out loco purchases.

The manufacturer/agent company will be permanently broke, with no ability to go anywhere, so it will have no way of generating income. This means no way of running any exploits. Stock price will be only $1 or $2, so stock issues will not gain you anything significant (even if the game allows them). You won't be able to take out any bonds. All you can do is buy locos with whatever company cash it has at the time.

This means no need to run checks, save variables, mess with stock/cargo prices, etc. If you can't use exploits there is no need for safeguards. If you select a combination of locos that leaves some company cash when you are done, it won't matter. In fact this way of doing things means you have total freedom on the choice of locos in the final "delivery", up to the amount of cash available. This should give more strategy/replay options.

Another point is that, providing the deposits for each order are known in advance, it would be possible to make this work in 1.05 (because there is no need to save company cash as a variable) and using 1.05 could be better for scenarios that have haulage goals. By using a variable count combined with pre-set purchase options (ie: F, F + M, F + M + E) it should even be possible to allow some flexibility for orders in 1.05 (ie: if delivery TV1 = 1 set delivery company cash to $X k - or - if delivery TV1 = 2 set delivery company cash to $Y k).

A possible drawback is that all new locos will appear in one small territory. In reality all imported locos will turn up at a port anyway, then you have to run them from there to where you want them. If you want to emulate that, having them turn up in one small territory should be fine. OTOH, if you don't want to emulate that it would just be a nuisance, but probably not a huge one in the scheme of things.

You could even set up more than one delivery territory. For example, the NSWGR Sydney and Newcastle networks were separate before 1889. Locos for Newcastle had to be delivered to Newcastle, and were often different to the locos delivered to Sydney (NSWGR had an crazy plethora of classes in the early days). It would be easy to set up a delivery territory in both cities, with individual deliveries taken from historical examples.

---

*Note: It should be possible to set this up even for a scenario where you don't really want an active stock market. You could use the editor to set up majority player ownership of both companies at the scenario start, and then impose these restrictions:

1. Disable Stock Buying and Selling.
2. Disable Company Issue/Buy Back Stock.
3. Disable Declaring Bankruptcy.
4. Disable Changing the Dividend Rate.
5. Disable Being Fired as Chairman.
6. Disable Merging Companies.

It would probably also be a good idea to impose:

1. Disable Replacing a Locomotive.
2. Disable Train Crashes.

---

**Note: To make this work it is necessary for the delivery company/territory to have access to 2 stations (you can't purchase of a loco unless it has a valid route). I ran a test on two small stations. Each time you build a small station it comes with 5 sections of track attached. This is the minimum spacing for small stations. You can't bulldoze any of those 5 sections without bulldozing the small stations, and you can't put the stations closer together than those lengths of track. However, if you space them one more section apart (ie: 11 track units total) that extra section in the middle can be bulldozed.

This could be used to keep the delivery company under control. If you break the track of an AI company, the company goes into stasis. When you take over control of the company you could fill in that one section, giving a "valid route" for the new locos. When you are finished, delete that section of track to put the company back into stasis. This step could maybe be automatic, via test against main company and delivery territory.

Note that you could not use a general "Destroy Track" event effect on the delivery territory, because that also takes out the track the stations come with, and it destroys them so it can destroy the track. IOW, a "Destroy Stations" event will only destroy stations, but a "Destroy Track" events destroys track and stations! This means a test against main company would be necessary to automate this step, so that only the one section of track laid by your main company was destroyed.

---

Another option: the purchase event could temporarily give the delivery company access to the main company's territory. The delivery station could then be tacked onto the main station (like a "shed out the back"). This could be better because a/ it takes up less space, and b/ you may not need to delete any track, and c/ you could set the initial routes anywhere in the main company's territory.

You may not even need a delivery company station at all. If the delivery company is not allowed access to any territories (will have to test if that is viable), that should stop it doing anything. Then you can give it temporary access to the main company territory when you want to do purchases, and use main company stations to set the routes, then set it back to no access.

[Gumboots]

Started doing some basic testing on this. Found a couple of things so far.

1. You can't just deny all territories to the AI company. That doesn't work.
2. Doing that will deny the AI building/buying any industries/stations, but...
3. ...it will still allow complete access to your track for any trains the AI company buys.

In other words, denying the AI access to all territories means it can still buy trains that will run between stations your main company owns, even though (theoretically) the AI does not have access to the territory those stations are built on. I assume this is another example of the thinking which always forces at least one loco to be available, even if you attempt to deny all locos by event: if you just attempt to deny all territories to locos, the game will force one to be available.

To get it to work you need at least one other territory that the AI has access to, and that AI territory needs to have at least one square of land and a visible border. You can hide the visible border underwater if you like, but you still need it, and you do need at least one square of land. Then you allow the AI access to that one square of land (which keeps the game happy) but the AI still won't have enough room to build anything. It won't be able to buy any industries there either, because there is not enough room to seed there. It won't be able to buy trains to run on your track between your stations, because now the denial of access to your main territory is working even for AI trains.

Logically you would also use this one square of land as your trigger territory for the purchase events. Just drop your track there to trigger your purchase event (force test against territory + track units > 0) and allow AI access to your main territory. When purchases are done, run a destroy track event on the AI territory and deny AI access to your main territory.

This is good. This is what is wanted. It will work.

---

Ok, that's the simple way of doing it. What if you want more than one delivery territory, and you want to restrict access to one delivery territory at a time?

In that case each delivery territory would need a visible border, and enough space for a minimum of two stations. Two stations are required to allow setting up a valid route, because you can't purchase a loco without a valid route. This arrangement would allow you to grant access to either delivery territory, without granting full access to your main territory.