The saga continues. I thought i’d continue from the last article and maybe make a series of Event Editor articles as i progess with my work and encounter interesting and somehow challenging things – particularly as i think other TOAW scenario designers may find this helpfull and rookie designers may get an insight into the Event Editor’s capabilities – and pitfalls.
In the last post i described how i got the PO to activate a certain event on a certain turn that is depending on a random event, but before I continue I think i first need to explain the background a bit more detailed. In ‘Anzio 1944’ the Allied player has a series of theater options for additional air support. There are three different formations available to him, US XII ASC (U.S. XII Air Support Corps), MATBF (Mediterranean Allied Tactical Bomber Force) and MASAF (Mediterranean Allied Strategical Air Force), each one will be available for two turns. Let’s take MATBF: the Allied player has five activations of MATBF, each one brings in a new formation from the TOAW OOB after the ‘previous’ formation has withdrawn. The formation that is activated by the first theater option already starts on the map, but in garrison mode. This is the according event sequence (left column is the event number, right column is for explanation and comments):
However, the Allied player must take care of weather and daytime. The scenario has 6 hour turns; each day is represented by four turns, two AM turns (morning and afternoon) and two PM turns (night and pre-dawn). There is an air shock of 5% on PM turns. Additionally, each day (beginning on turn 26) there is a 40% chance for stormy weather which will prevent effective use of aircraft by a severe air shock on the two AM turns. This is handled by a repetitive loop that produces a storm warning each pre-dawn turn in the ‘recent news’. We can leave the effects of the event chain aside (air shock, theater recon etc) and just look at the loop itself:
So, what we need is to prevent the PO from selecting an Air Support Option on such a storm turn. This has been handled by the previous article.
But that article described only how the PO should handle one Air Support Option – or better: the first option that is subject to the ‘storm turn problem’. As it turned out this was a bit more complicated for following options of the same formation. Again we take a look at MATBF, this time the third activation. Needless to say, the third activation should occur on the next non-storm day after MATBF’s second activation (note that MATBF’s first activation occurs before turn 25 when the weather loop starts).
The relevant events start at #609. I included MATBF (2) and again the ‘weather loop’ as MATBF (3)’s events refer to these. Note that we need almost twice as many events as for the previous activation events for MATBF (2).
The first two events, #609 and #610, prevent the actual activation event (#615) from triggering immediately after event #604 (MATBF’s 2nd activation) has been activated. Events #611 and #612 kill this perpetual loop upon activation of MATBF (2) by event 604. Note that i had to insert these four events before the actual activation sequence. If i hadn’t put them on top of the sequence, but at the end, event #615 would have fired one turn after event #604. This is because the Editor goes through the events in numerical order. Event #613, being dependent on event #78, which would have triggered event #604 by a failed probability check, would have enabled #615 before the perpetual loop could have cancelled it.
Yet, that’s not all. Event #609 is again fired one last time one turn after event #604 (and thus #611 and #612) is triggered. This again prevents immediate triggering of event #615.
Next follows the activation sequence in almost the same pattern as described in the previous article, except for two variencies. According to the event pattern of MATBF (2) i would have needed a delay of 1 for event #613, but inexplicably this didn’t work and MATBF (3) entered the map already on the pre-dawn turn. I then set event #615 to trigger an additional event (#620) that triggers yet an other event (#621) which has a delay of 1. Then it did work as intended.
I hope that was not too confusing. Rookie designers calm down, the above is quite pushing the Event Editor to its limits. Most scenarios have not that demanding and special set-ups. Also note that a lot of work with the Event Editor, especially in such a demanding case, is try and error. As it was in this case. It took numerous runs with a test scenario until i found a working event pattern. Feel free to comment or criticize.