Decision Events

[mcaryf1]

This is a question aimed at those familiar with developing scenarios. If you are not into doing that I suggest you do not bother to read this post.

I would be grateful to know if there is a detailed explanation over and above the comments in the various files as to how the AI and the AI and Decision Events actually work.

I have been struggling a bit with a scenario when attempting to create a repeated pattern of events that have various consequences for the player. One example is that I have established an area in the North Atlantic where Axis raiders can cause trouble for the Allies in addition to standard convoy routes. In practice many ships sailed independently from convoys and U- Boats took a toll of these. I have used DE's that vary depending on how many raiders are in area e.g. for one raider the UK might have to pay 25 MPP in replacement shipping cost, for 4 or more raiders there will be supply impacts as well as costs. Things work reasonably well if the player accepts the charge required by the DE but there are problems if the charge is refused and one of my supply or morale events is triggered. What seems to occur is that the DE remains set at the refusal to pay for subsequent turns even if all the raiders have left the area. Essentially the DE is not triggered so it stays set at NO. Unfortunately my supply and morale sanctions then kick in and the Allied player does not get an opportunity to change his response to the DE until that number of raiders are in the N Atlantic again.

I have considered making a different supply or morale event for every month to operate on a single occasion. However, that is both a lot of work and I am not sure it would be effective. It seems that timed supply events are sometimes stored up, if not triggered on their due date and all those from earlier dates happen in one go once the event satifies its other criteria.

Finally I experimented with putting both a conditional statement in the supply event along with a link to the Decision the player took. Thus I include in the Supply event a condition that there should be so many raiders in the area as well as a link to the DE where the Allied player refused to buy more ships to replace those sunk. My impression here is that the supply event is triggered by the decision link and it ignores the condition that there should be so many raiders. Thus am I right in thinking that Supply Events in this case are triggered by either criteria (OR) rather than both criteria (AND)?

Sorry this is rather rambling but if you have a users guide to writing AI and DE I would be happy to read that rather than you answering the detailed points.

Regards

Mike

[Bill101]

Hi Mike

The Decision will trigger the relevant supply script, and I think that setting the Decision relating to the Atlantic to be Type = 2 should work best, as then it will fire every turn when it's condition is realized.

This does mean that the Allies will frequently have to take this decision.

Or, so that the Allies aren't bugged every turn by having to make the same decision, you could ask them earlier in the scenario whether they will agree to cover all costs incurred using one Decision.

Then your second Decision is triggered by the relevant conditions, and depends on the answer to the first. This second one could charge MPPs without needing player approval if it doesn't have any Pop Up text.

You would also need a third Decision, which is if the Allies said no to the first Decision, and this would handle what happens when raiding occurs.

I hope that makes sense?

Bill

[mcaryf1]

Hi Bill

Thank you for the suggestions unfortunately I am not sure they would get round my main difficulty or give the right playability. For playability the players really need to know that raiding has occurred before the end of their turn otherwise they might not take action to find and deal with the raiders. I have tried out a scenario having triggers in all the major oceans and it is not too onerous to give 4 or 5 quick decisions.

The main issue would still not be resolved - it is this. If a condition such as 4 raiders triggers a DE then that DE becomes active - I presume it is previously set to some sort of dormant state. The player then responds to the DE with a YES or NO answer. If, in the next turn, the conditions are no longer satified e.g. one raider has been destroyed the DE is not triggered so no decision is available to the player, however, it seems that the DE is not put back to a dormant state but rather it remains set at whatever decision the player took. I am not 100% sure if this is true for a Yes response because usually I use a one-off payment to replace sunk MS but I am pretty sure that it is the case for a NO as I have seen repeated losses of morale or supplies even though the original condition no longer applies.

If I am right, it effectively means that you cannot use a DE with a type 2 setting because it would continue to trigger whatever happens if the player has said No for as long as the original trigger is not satisfied again.

Regards

Mike

[Bill101]

Hi Mike

I still think there might be a way to do it, as Type 2s are returned to a dormant state every turn, because they check again for their trigger conditions being met.

But to work, it might require both the Decision and its related scripts to be a type 2.

Going back to my original suggestion, as far as advising the players of raiding is concerned, one could have a Pop Up script, again type 2, to advise them that it has occurred.

I'll await to hear from you, with a little hopeful optimism!

Bill

[mcaryf1]

Hi Bill

My experience is that Type 2 decision events are not returned to dormant state. In case I am doing something wrong here are a couple of examples of the events I am using. In the first case if raiders are off the Persian Gulf then Russia has to pay for replacement ships or suffer supply penalties. In a multiplayer game I put an IJN sub in position and had Russia refuse to pay. She got penalised with supply events. Next Axis turn I moved the IJN sub away, in the Allied turn there was no DE for the Russians but they were supply penalised and again for every succeeding turn.

In the IJN case I assembled 3 Allied raiders in the area and had Japan refuse to pay. She was penalised with the two supply events triggered. I moved the US raiders away. Then there was a gap (I use 14 day simultaneous turns) but after second turn Japan was penalised again so the DE was still set to NO and triggering the next month's supply events.

Here is my coding it is using a map that for these locations is the same as Axis High Tide:

Example - simple Russian repeating DE

{

#NAME= DE 12 - USSR: Shall we build more Merchant Ships For Lend Lease Shipments

#POPUP= Should we spend 20 MPP to replace Merchant Ships which have been sunk bringing Lend Lease to Persia

#IMAGE=

#SOUND=

#FLAG= 1

#TYPE= 2

#AI= 0

#LEVEL= 0

#COUNTRY_ID= 4

#TRIGGER= 75

#DISPLAY_ORDER= 1

; Set global variable condition to always trigger (dummy value)

#GV= 1[1,100]

; Set link value to always trigger (dummy value)

#LINK= 0[0]

; Set decision value

#DECISION= 12

; Set how many MPPs should be collected over X turns if player selects 'yes'

#MPP_UPDOWN= -20

#MPP_TURNS= 1

#MPP_TEXT= Building more Merchant Ships for Lend Lease

; Set AI acceptance % (AI will accept 100% of the time)

#AI_RESPONSE= 100

#AI_RESPONSE_POPUP=

#DATE= 1939/09/01

#TEXT_RGB= 0,0,0

#SHADOW_RGB= 228,221,198

#NATIONAL_MORALE_TRIGGER= 0 [0]

#FRIENDLY_POSITION= 17,23

; Set variable conditions:

; 2nd and 3rd lines - US still fighting

#VARIABLE_CONDITION= 3 [2] [100] [0]

; One or more raiders in Indian Ocean

#CONDITION_POSITION= 116,32 [3,2] [1,1] [1] [0]

}

Supply Event

{

#NAME= USSR Lend Lease losses off Persian Gulf

#POPUP= Lend Lease Aid interdicted Persian Gulf

#IMAGE=

#SOUND= convoy.wav

#FLAG= 1

#TYPE= 2

#AI= 0

#LEVEL= 0

#GV= 1[1,100]

#LINK= 12[0]

#COUNTRY_ID= 6

#FLAG_ID= 4

#TRIGGER= 100

#SEASON_FLAG= 0

#DATE= 1939/09/01

#SOURCE_POSITION=

#DESTINATION_RESOURCE= 109,15 [3,5]

#DESTINATION_RESOURCE= 119,10 [2,4]

#DESTINATION_RESOURCE= 111,20 [2,3]

; US at war and not surrendered

#VARIABLE_CONDITION= 3 [2] [100] [0]

}

Example Japanese DE’s with non-repeating supply events each month

{

#NAME= DE 13 - Japan: Shall we build more Tankers to replace losses

#POPUP= Should we spend 30 MPP to replace Tankers sunk bringing oil to Japan

#IMAGE=

#SOUND=

#FLAG= 1

#TYPE= 2

#AI= 0

#LEVEL= 0

#COUNTRY_ID= 8

#TRIGGER= 100

#DISPLAY_ORDER= 1

; Set global variable condition to always trigger (dummy value)

#GV= 1[1,100]

; Set link value to always trigger (dummy value)

#LINK= 0[0]

; Set decision value

#DECISION= 13

; Set how many MPPs should be collected over X turns if player selects 'yes'

#MPP_UPDOWN= -30

#MPP_TURNS= 1

#MPP_TEXT= Building more Tankers 1 or 2 raiders

; Set AI acceptance % (AI will accept 100% of the time)

#AI_RESPONSE= 100

#AI_RESPONSE_POPUP=

#DATE= 1939/09/01

#TEXT_RGB= 0,0,0

#SHADOW_RGB= 228,221,198

#NATIONAL_MORALE_TRIGGER= 0 [0]

;Manila still controlled

#FRIENDLY_POSITION= 162,32

; Set variable conditions:

; 2nd and 3rd lines - US still fighting

#VARIABLE_CONDITION= 3 [2] [100] [0]

; One or more raiders in South China Sea

#CONDITION_POSITION= 165,31 [11,3] [1,1] [2] [0]

}

{

#NAME= DE 29 - Japan: Shall we build more Tankers to replace losses

#POPUP= Three or more raiders should we spend another 40 MPP to replace Tankers sunk bringing oil to Japan

#IMAGE=

#SOUND=

#FLAG= 1

#TYPE= 2

#AI= 0

#LEVEL= 0

#COUNTRY_ID= 8

#TRIGGER= 100

#DISPLAY_ORDER= 1

; Set global variable condition to always trigger (dummy value)

#GV= 1[1,100]

; Set link value to always trigger (dummy value)

#LINK= 0[0]

; Set decision value

#DECISION= 29

; Set how many MPPs should be collected over X turns if player selects 'yes'

#MPP_UPDOWN= -40

#MPP_TURNS= 1

#MPP_TEXT= Building more Tankers - 3 raiders

; Set AI acceptance % (AI will accept 100% of the time)

#AI_RESPONSE= 100

#AI_RESPONSE_POPUP=

#DATE= 1939/09/01

#TEXT_RGB= 0,0,0

#SHADOW_RGB= 228,221,198

#NATIONAL_MORALE_TRIGGER= 0 [0]

;Manila still controlled

#FRIENDLY_POSITION= 162,32

; Set variable conditions:

; 2nd and 3rd lines - US still fighting

#VARIABLE_CONDITION= 3 [2] [100] [0]

; Three or more raiders in South China Sea

#CONDITION_POSITION= 165,31 [11,3] [3,3] [2] [0]

}

Supply events

{

#NAME= Japanese Tanker losses S China Sea

#POPUP= Oil shipments interdicted S China Sea

#IMAGE=

#SOUND= convoy.wav

#FLAG= 1

#TYPE= 1

#AI= 0

#LEVEL= 0

#GV= 1[1,100]

#LINK= 13[0]

#COUNTRY_ID= 3

#FLAG_ID= 8

#TRIGGER= 100

#SEASON_FLAG= 0

#DATE= 1942/06/01

#SOURCE_POSITION=

#DESTINATION_RESOURCE= 170,23 [3,5]

#DESTINATION_RESOURCE= 173,23 [2,4]

; Japan at war and not surrendered

#VARIABLE_CONDITION= 8 [1] [100] [0]

}

{

#NAME= Japanese Tanker losses S China Sea

#POPUP= Oil shipments interdicted S China Sea

#IMAGE=

#SOUND= convoy.wav

#FLAG= 1

#TYPE= 1

#AI= 0

#LEVEL= 0

#GV= 1[1,100]

#LINK= 29[0]

#COUNTRY_ID= 3

#FLAG_ID= 8

#TRIGGER= 100

#SEASON_FLAG= 0

#DATE= 1942/06/01

#SOURCE_POSITION=

#DESTINATION_RESOURCE= 170,23 [8,8]

#DESTINATION_RESOURCE= 173,23 [8,8]

#DESTINATION_RESOURCE= 165,22 [8,8]

; Japan at war and not surrendered

#VARIABLE_CONDITION= 8 [1] [100] [0]

}

{

#NAME= Japanese Tanker losses S China Sea

#POPUP= Oil shipments interdicted S China Sea

#IMAGE=

#SOUND= convoy.wav

#FLAG= 1

#TYPE= 1

#AI= 0

#LEVEL= 0

#GV= 1[1,100]

#LINK= 13[0]

#COUNTRY_ID= 3

#FLAG_ID= 8

#TRIGGER= 100

#SEASON_FLAG= 0

#DATE= 1942/07/01

#SOURCE_POSITION=

#DESTINATION_RESOURCE= 170,23 [3,5]

#DESTINATION_RESOURCE= 173,23 [2,4]

; Japan at war and not surrendered

#VARIABLE_CONDITION= 8 [1] [100] [0]

}

{

#NAME= Japanese Tanker losses S China Sea

#POPUP= Oil shipments interdicted S China Sea

#IMAGE=

#SOUND= convoy.wav

#FLAG= 1

#TYPE= 1

#AI= 0

#LEVEL= 0

#GV= 1[1,100]

#LINK= 29[0]

#COUNTRY_ID= 3

#FLAG_ID= 8

#TRIGGER= 100

#SEASON_FLAG= 0

#DATE= 1942/07/01

#SOURCE_POSITION=

#DESTINATION_RESOURCE= 170,23 [8,8]

#DESTINATION_RESOURCE= 173,23 [8,8]

#DESTINATION_RESOURCE= 165,22 [8,8]

; Japan at war and not surrendered

#VARIABLE_CONDITION= 8 [1] [100] [0]

}

Hopefully you may spot something I am doing that is wrong otherwise, if you think it should go back to dormant then I suppose it is a bug in the DE mechanism.

Regards

Mike

[PowerGmbH]

i tink a simple solution for this "Mpp-Loss" for UK would be as follows:

a DE01 (owner UK) "Replace Lost Ships" If the Player says yes comes an type 2 DE

based on

DE01 = 1 with

#POPUP= "Leave empty" so it goes automatic

and put #AI_RESPONSE= 100

without text.

This event should then fire every turin IF:

; One or more raiders in XXX Ocean

#CONDITION_POSITION= XX,XX [3,2] [1,1] [1] [0]

this means if you said NO, notzhing happens, Ennemy raiders have NO effect.

If you say Yes: then the MPP List shows you every turn a Loss on MPP, if there are Axis Ships in this specific Area.

Obviously you als Allied Player Penalize yourself, so you should put a balance Event for saying yes..

[Bill101]

I think that PowerGmbH's solution should work, as it may be the existence of the text in the POP UP area that is preventing it from working as you would like.

That does mean that the player will have to make a long term decision early on, and not regret it.

[mcaryf1]

I have tried the suggested solution in various ways but I am sorry to say it just does not work. The basic problem is that once a DE has been triggered by having its conditions satified it will not return to a null state. Thereafter it has to be passing on that it is either YES or NO. This means in my situation even if I have nested DE statements they are either picking up a YES or NO from earlier statement and will therefore be active whether or not the original trigger is still true. This is also true for Supply statements that depend on a DE to be triggered. This effectively means that Type 2 DE's cannot function effectively if a genuine decision is involved that relates to specific conditions.

The original problem was that a triggered DE to which the player had replied No would continue to send a No value even when the original trigger had stopped being true and would no longer give the player an option to change their answer to Yes until the trigger activated the DE again. When I switched this so that a second DE was triggered by the First DE having a No and using that to trigger the supply event without it also having the original condition for the first DE, it would now give the player the option of paying the cost or the supply penalty but would continue to give that option every turn until the original DE got switched back on by its conditions being satisfied. This seems to happen regardless of whether there is any text or not associated with the DE. This is a step forward of sorts in that the player can at least choose between a supply or MPP penalty but is still wrong when actually no penalty should apply!

The only way I can think to do this is to have a series of Type 1 DE's linked to specific Type 1 supply events so that each one can only be triggered once. This is going to be rather tedious to code so I will think further about it but I do feel that Type 2 DE's are effectively bugged at the moment.

Regards

Mike

[Hubert Cater]

Hi Mike,

I think both sides are right on this one.

For example, if a DE is set to type=2, as far as I can tell it is reset condition wise, as Bill suggests, to recheck if all the conditions are satisfied before it will pop up again as a decision to the player.

However, what happens internally is that once a decision is made, the decision, yes or no, is stored as a variable for the lifetime of the game to be picked up upon by subsequently linked events.

The only thing that will change the stored decision value is if the DECISION pops up again and the user changes their answer to the YES or NO question.

Not sure if this helps but this is what is happening behind the scenes code wise.

[mcaryf1]

Hi Hubert

Thank you for confirming that DE type 2 does not return to a null state with respect to the answer provided after it has first been triggered.

I have to say that I find it quite difficult to come up with many situations where it would be preferable to leave the DE set at Yes or No rather than reverting to Null but if that is the way it is meant to be I will just have to think of another way to give players choices between two bad events - paying for new merchant ships or supply/morale hits. I guess the most likely approach will be for me to look at some sort of Quarterly penalty with a limited number of one off (Type 1) supply events spread out to match Quarter days triggered if a player has declined a purchase option in the previous 3 months. In fact this is an example where I could possibly use the DE remaining set at No as a mechanism - if I add a degree of randomness via a Trigger setting then that would make it hard for the players to try to take different decisions near the end of a Quarter to avoid the 3 monthly penalty.

Am I right in thinking that Trigger will take precedence over other criteria for a decision becoming active?

Regards

Mike

[Hubert Cater]

Actually the original idea behind the DEs (on our end) was to use them linked together, i.e. one DE then links to another DE and so on based on the previous response... so with this in mind it was critical that DE results remain applicable throughout the lifetime of the campaign as we also use them to link to other events quite often later on in the war as well.

I'm not sure if there is an easy way around that for what you have in mind but it sounds like you may have come up with a partial solution.

For the trigger, it doesn't take precedence, it is just another one of the criteria that must be true for the event to fire. But setting it to 100% guarantees it will always be true.

[mcaryf1]

Hi Hubert

I can certainly see why you would leave a DE set if it was a Type 0 or a Type 1. The Shinano decision is clearly one where the results of a decision taken in 1942 actually do not take place until 1944. Taken in isolation the best way to treat Type 2 decisions would probably have been to go for reverting to Null between decisions but I guess coding the decision process would be more complex if the various types diverged too much so I presume that tipped it in favour of your actual approach which is useful in some situations.

With respect to Trigger you said it was one of the conditions that must be true. That implies an AND relationship which is what I intended when I said it would take precedence although I admit I lacked clarity in expressing it that way.

I started this thread by asking if there was any additional documentation that might be used by scenario designers. I am particularly interested in the AI aspects as I guess there may well be interpretation issues there rather like those discussed above re handling DE Type 2.

Regards

Mike

[Hubert Cater]

I think there is a point here with the TYPE= 2 as we haven't really used them until recently so let me discuss this with Bill and see if what you propose will work, i.e. just in case I'm not missing anything on our end for TYPE= 2 and we can go from there.

The only docs we have are the headers included for each script file, the notes in the Editor Help file as well as some extras in the Extras\Docs folder.

Probably not exactly what you are looking for but some of it might help

[mcaryf1]

Hi Hubert

I will await your deliberations with interest.

Thank you for reminding me about the AI guide. I had looked at it briefly when I first got Gold but I probably need to read it more deeply now that I have some familiarity with what the AI seems to be doing in practice.

I do have another question of detail - I am trying to understand the difference between a Type 1 and a Type 0 Supply event.

This is what the file guide says:

; #TYPE= With all other factors satisfied will this be a (values range [0, 2]):

; A) Single check regardless if trigger is satisfied= 0

; Multiple check until trigger is satisfied= 1

; C) Reoccuring check until end of game= 2

I had assumed that "trigger" in statement (A) meant the first time the date and Trigger % allowed the event to fire and it would permanently fail if the other conditions such as "link" and "variable" were not satisfied. However, in practice it seems that it will actually wait until "link" is satified as well so does it only fail permanently if " variable" is wrong or does trigger actually mean the TRIGGER command?

My revised attempt at a raider process had monthly supply events waiting to fire if the DE detecting raiders was answered No rather than Yes (pay for more merchant ships). What I found was that if a player had answered Yes for 4 months and then NO or if raiders were not actually present then all the previous 4 months' penalties would fire on that turn. It is not a disaster as it just ensures that the selected locations are well and truly zapped but it looks a bit strange to see a whole set of triggered supply events happening on one turn.

I should note that it is quite useful that the National Morale event has its own CONDITIONAL_POSITION Statement like DEs so I can throw in a few of those events if there are, say, 3 or more raiders in a sea area and that should help to keep the opposing player guessing as to what is causing his problems. It would be helpful if that condition was also available in Supply Events as it is rather more powerful than SOURCE_POSITION.

Regards

Mike

[Hubert Cater]

Correct, the link needs to be active before the event is even looked at as it is only relative to the decision once made.

After that the trigger is indeed in reference to the #TRIGGER value.

So for TYPE=0 if all the other conditions are satisfied and let's say you have a #TRIGGER= 50 then there is a single check and if the #TRIGGER is satisfied the event occurs, if not it is removed and never looked at again.

This is useful if you would like to have a one time event in the game that may or may not happen.

For #TYPE=1 it will keep checking until the #TRIGGER value is satisfied. This is useful if you want the event to eventually occur but would prefer some randomness as to when it will actually happen in game.

Hope this helps,

Hubert

[Hubert Cater]

Hi Mike,

Send me an email at support@furysoftware.com as I have something for you to look at that might be of some help.

Hubert