Event Idiosyncracy Tests

[jeffryfisher]

Someday somebody should write a whole users' manual about the previously undocumented features of RRT2 events. Until then, I'll post the results of my tests here. This is a more general exploration of event idiosyncrasies growing out of my confiscation question (since confiscation failed to do what I wanted, forcing my development down other paths).

To recap discoveries posted in that other thread:

* Confiscation can't be undone. Once track and stations become owner=none, they stay that way when confiscation-"Don't Do It" executes.

* A locomotive type can be enabled for just one company.

* A locomotive type can be enabled in a scenario that does not include it. This means that companies can be forced to "earn" their loco upgrades. I plan to make all high-speed trains depend on "investments" in track re-alignment (large-radius curves) and welded rail.

Now, new discoveries made last week:

* A loco can be disallowed temporarily, and it will come back as expected.

* A sub-territory (no visible border, so it is "mapped" to a parent territory) can be used to remove a company's access rights to part of a larger territory. This works regardless of whether the right-click is also mapped (check box).

* However, granting rights to a sub-territory is weird. The grant only works if the right-click is NOT mapped (checkbox is clear).

* Even then, the added territory will not show in the mini-map of a company report's territory page (access rights version). The rights only show up when right-clicking on a cell or actually attempting to build track etc.

* Probably mentioned elsewhere, but I was surprised: When building a station on the border of accessible territory, only the track needs to be in the territory where the company has rights. The station can hang into an adjacent territory where the company has none.

* "Temporary" percentage changes in revenues or production don't do math correctly. If I reduce production 99% "temporarily", it never recovers. It appears that the 99% reduction is followed by a 99% increase... and nearly doubling 1% does not undo an embargo. I'll do more experiments to see if I can verify this (cutting 75% and then doubling twice).

* An embargo in one territory appeared to work; the commodity seemed to continue unabated in other territories.

* Changing production on a commodity does affect production at ports, not just standard sources like farms and mines.

* Territory bug: If track/mountain building is discounted by an event triggered on one territory, then only that territory gets the discount (nice). The catch is that if the effect is set to temporary, then the unwinding boosts all track/mountain costs everywhere. Not only that, but the unwinding is miscalculated the same way as the production of a commodity: After an 83% discount, there was an 83% increase... applied to the 17% temporary value. That left the unwound value at about 30% of "normal", while all other territories suddenly found themselves at 183%!!

* If a territory gets a bridge-building discount, then the cost of a bridge depends on its center square. However, all other track and mountain discounts depend on the starting square of a stretch of track: Cheap if you start from the discounted territory and stretch into another... Expensive if you build the same track in the opposite direction).

* Like the territory bug for temp track discount, temporary commodity production seems to unwind improperly. The initial increase or reduction appears to affect only the target territory, but the unwinding appears to affect the whole map.

* What this adds up to is DO NOT CODE TERRITORY GAINS AND LOSSES AS TEMPORARY EFFECTS (the rest of the map will be messed up at the unwinding).

[jeffryfisher]

* Game-start events (scenario briefing) don't allow effects. That makes game variable initialization difficult.

* If you create a map with no offset days, then month-start and year-start events will be tested before the clock starts. Therefore, if you need to initialize variables or other effects, then you probably need to leave the offset at zero (blank).

* Even if you place reserve cells under a pre-placed building, towns and regions can still fail to form. Whatever that bug is, it isn't just a collision in location.

[Gwizz]

I normally use the first or second events to set up my variables etc.

Then I do the briefings, leaving a few empty events just in case I need a top of the list event.

Then I do the start of year and month events.

I seem to remember setting an effect first before it disappeared and having the effect work. 

There may be conditions I don't remember.

I've never used off set dates.  When I did try this I didn't think it worked correctly.  I don't remember what it does anymore.

I have used slow time. (by the day time for metro maps)  But it always seemed to be too slow.

I think PopTop missed a chance to make another more programmable and successful version of RT2. 

[jeffryfisher]

I've just tested event ordering, and I found an interesting quirk. I stacked three events thus:

Start Month

Start Year

Start Month

In January, they fired as:

Start Year

Start January

Start January

Similarly, but mirror imaged, "End Year" events follow all "End Month" events in December. Therefore, annual events can be seen as bracketing monthly events.

Be careful when passing values between events with different frequency. For instance, a one-time event checked annually at year end can't reliably cascade a triggering value to a reusable event checked monthly at month's end. The month's end event wouldn't be checked again until the end of January, by which time the variable could have been reset or reused.

[jeffryfisher]

I also started tried storing a trigger greater than 100 in a game variable. The value 32,000 passed successfully from one event to another. Testing further: 200,000,000 passes successfully as well.

[Gwizz]

FYI,  An event will stop searching after the first false part of an event is triggered.

The firing order you found for date time is interesting.

I always felt that the firing order was      Date triggers:  YEAR START, MONTH START, MONTH END, YEAR END.

Each trigger would cycle through the whole event field before the next date trigger would be accessed. 

[jeffryfisher]

FYI,  An event will stop searching after the first false part of an event is triggered.

That's reassuring, especially since I have a large number of events and I have been structuring the trigger expressions to put the simplest, most-likely-to-be-false elements in front.

I always felt that the firing order was      Date triggers:  YEAR START, MONTH START, MONTH END, YEAR END.

Each trigger would cycle through the whole event field before the next date trigger would be accessed.

BTW, it doesn't matter if there's any date condition in the expression for a trigger. If you test for GameVariable3 in a start-month event, it won't be checked in January until after all start-year events. That means that any start-year event can set G3, and then any start-month event can react to it (or accidentally clobber it), and the position of the start-year event relative to the start-month events won't give you any control.

[Gwizz]

I didn't explain very well.

I was thinking of the ranking, which one of the four triggers would fire first. 

My thought was:    start of year fires first,  start of month second,  end of month third  and  end of year fourth.

I could be wrong.  It has been a long time since I did any weaving of triggers.

My thinking is the date triggers are searched 4 times.  start of year would search all events for Start of year triggers.

Then the game searches all events for Start of month triggers and so on for end of month and the end of year.

Of course as you stated, the arrangement of all triggers in one event is also important.  For these the search is top to bottom or right to left.  And, with math, following the standard order of operation.

It is possible to become very creative as you weave though the events and triggers.  As you know you can use the same variable a number of times as long as each use is returned to a neutral setup common to all uses.

[jeffryfisher]

I tested year-end and larger trigger storage. As expected, December's end-month events ran before any year-end events. In addition, I was able to pass a 200,000,000 trigger value from one event to another.

[jeffryfisher]

I've just hit another wtf feature: If an event has a track-cost effect on a territory, it is somewhat territory specific.

First, it seems to only affect the actual rail cost, not the terrain leveling cost. I tried decreasing track building by 90%. On ultra flat ground, track was free. On any uneven ground, cell costs looked about half price.

Here's the kick in the head: When I started in the discounted territory and stretched a line into a normal one, the total build cost was about half as much as when I stretched rail over the exact same cells starting from the other territory. In other words, the rail building cost is set by the territory in which a segment is anchored.

Therefore, if you ever receive a territory-specific track-build discount in a scenario, you can extend the subsidy by running rail out of that territory.

[cogeo]

First, it seems to only affect the actual rail cost, not the terrain leveling cost. I tried decreasing track building by 90%. On ultra flat ground, track was free. On any uneven ground, cell costs looked about half price.

"Track Building" means the amount needed to only lay the tracks. The amount for moving the grounds is called "Mountainous Track Building". Trees are added to the track value, and you even pay maintenance for them. Better clear the trackbed off trees and then lay the track. Also take a look at this post.

Here's the kick in the head: When I started in the discounted territory and stretched a line into a normal one, the total build cost was about half as much as when I stretched rail over the exact same cells starting from the other territory. In other words, the rail building cost is set by the territory in which a segment is anchored.

Therefore, if you ever receive a territory-specific track-build discount in a scenario, you can extend the subsidy by running rail out of that territory.

This (exploiting a "bug" or an "oversight") is tantamount to cheating, and players should rather avoid such practices.

[jeffryfisher]

I forgot to add: One of my events played with the prime rate. During boom times, company and personal cash were "earning" -1%. That's right, we were paying to store money because the game doesn't test for zero and set a floor. It just subtracts 4 from the "prime rate" and uses that (even if negative) for cash piles.

[Gwizz]

Cogeo wrote:

This (exploiting a "bug" or an "oversight") is tantamount to cheating, and players should rather avoid such practices.

Unless I'm playing to win or in a competition, I don't consider that cheating.    ::)

90% of the time I just play for fun.  Now I have another cheat to use.  ;)

[jeffryfisher]

I've run into another possible pot-hole: It may be that the option to buy into a territory is not company specific. In other words, it may be that access to a territory can either be bought by any or bought by none.

I'm going to run a quick test where I very specifically trigger the may-buy-rights effect for one company at start. I'll look to see if other companies then have the same option to buy access.

Stay tuned...

Back from testing, and it's as I feared. Setting a territory right to "buyable" makes it buyable for every company, even if you run a one-time, company-specific event. In my test, I created a one-time company-start event to trigger true on the first computer company. When I started my company first, I could not buy into the target territory. As soon as a computer company started, I could buy.

This mangles a few of my events where I wanted companies of a nation to have an option to buy into certain territories early (but only their own nation's future states/provinces). I guess I'll rewrite them as choices. Come to think of it, I think the presentation of a choice can be made company-specific, so I can render it as "buy now or remain buyable for later".

[jeffryfisher]

Added territory bug: Temporary territory effects initially affect only the target territory, but the "unwinding" (end of temporary period) hits ALL territories. If three territories each get a 50% track discount temporarily, then when the three discounts expire, all territories on the map are hit with 150% of increase!

[jeffryfisher]

I just tried a per-company track / mountain / bridge event (temporary). The build cost went down correctly and came all of the way back to previous values correctly, at least for my company.

This is unlike the temporary territory discount in which the values came back by a percentage of the lower value (a 70% decrease followed by a 70% increase on the low value left me at 51%).

Now I need to run the event so that all of the computer companies will get it. I'll watch to see if there's a splash onto my company during or after.

[jeffryfisher]

Reverse test complete: the unaffected company was also unaffected on expiration. Whatever happened with one territory does not happen with one company. Per-company track (and mountain and bridge) building seems to work properly. I wonder how territories could have been so badly mangled.

Oh well, leave a red flag in my copy of the scenario editor manual.

[Gwizz]

(a 70% decrease followed by a 70% increase on the low value left me at 51%).

This is predictable; thus event-able .

As an example: a decrease by 70% 0f the number 100 is not the same as following with a 70% increase of the same number which is now 70.

Just add to the percent increase enough so that the answer returns to where the original number was at the start which is:

A 70% decrease needs to be about 143 % increase to return to the valve of the original number. 

[jeffryfisher]

My problem was with the "temporary" setting of effects. It would have been nice if "temporary" always meant "after x years/months, it will be as if the effect had not happened".

This is actually the case when discounting rail cost for one company. It puzzled me for a while that the game was able to do that. But then I realized that it must stack modifiers until expiration, using them again and again when applicable. On expiration, the game simply discards the now-obsolete modifier so its effect vanishes.

Unfortunately, this does not happen when discounting rail building in one territory. What's triply aggravating about this "feature" is that it's undocumented, inconsistent and counter-intuitive (even if it's understandable).

On top of that, an effect for one territory starts correctly (locally) but unwinds globally. Now that's gotta be a bug.

BTW, I called Take-2 and left a voice-mail message. No reply after a week. I should call again on Monday.

[jeffryfisher]

I've finally seen it with my own eyes: My normal-priority train halted for a computer-company's train that was crossing my track where I "owned" the intersection (where the computer had built across my pre-existing track).

Setting all three of my trains to high-priority seems to have defeated the attack in my simple test game, but that tactic would cost something in lost flexibility in a complex system.

[jeffryfisher]

Another surprise: When one of my train-stopping events fired, trains continued to move briefly. Each stopped only when it reached a cell boundary. This bodes ill for attempts to protect track-destruction events with train-stoppage.