Page 1 of 1
TYPE, TRIGGER and CONDITION_POSITION
Posted: Fri Oct 26, 2018 10:07 pm
by El Condoro
I am finding my understanding of the conditions for events to be very hit and miss and so I thought I'd ask those who know to perhaps help out.
When the word 'Trigger' is used does it only refer to #TRIGGER or all the conditions set for the event? If #TRIGGER= 30, the event will fire 30% of turns (if other conditions are met)?
#TYPE is my first problem. You'd think the description in the text file is enough but I am still struggling. Am I right to say (With other fields satisfied):
0: The event will run once if the trigger has been met. If the TRIGGER= 100, then the event will run once.
1: The event will run once the trigger is met. If the TRIGGER= 100, then the event will run. If the TRIGGER= 30 the event will run 30% of turns and only once.
2: The event runs every turn once the #DATE has been met.
3: Fires once, whether trigger is met or not and that's it for that event.
So, specific example: I want a decision check to be made every turn and fire just once when the trigger is met. I use #TYPE= 0 if #TRIGGER= 100 and I use 1 if #TRIGGER is less than 100?
#CONDITION_POSITION uses 'OR' logic, so any of them will meet the conditions.
Specific example: I want a Decision Event to fire if 1 or more of AXIS units come within 4 hexes of hex position (34,56). The condition would be #CONDITION_POSITION= 34,56 [1,4] [1,20] [1] [0]?
The situation I have is a Neutral offers to assist a (not yet mobilised) Major when AXIS units come within x hexes of the Neutral's one capital. It fires properly when the Major is not yet mobilised but not when it mobilises and an AXIS unit comes within the condition parameters.
Sorry for such a long post.
RE: TYPE, TRIGGER and CONDITION_POSITION
Posted: Sat Oct 27, 2018 4:27 pm
by BillRunacre
ORIGINAL: El Condoro
When the word 'Trigger' is used does it only refer to #TRIGGER or all the conditions set for the event?
Hi
It can be used for both, as when we use the word trigger in talking about scripts, we mean all the things required to make the script happen (or fire).
But the #TRIGGER= setting is something else, and the % means the chance of it happening that turn.
So #TRIGGER= 30 means a 30% chance of the script firing in the turn that all its conditions have been met.
#TYPE is my first problem. You'd think the description in the text file is enough but I am still struggling. Am I right to say (With other fields satisfied):
0: The event will run once if the trigger has been met. If the TRIGGER= 100, then the event will run once.
1: The event will run once the trigger is met. If the TRIGGER= 100, then the event will run. If the TRIGGER= 30 the event will run 30% of turns and only once.
2: The event runs every turn once the #DATE has been met.
3: Fires once, whether trigger is met or not and that's it for that event.
Not quite,
0 = it won't fire, this script is in the game but not activated.
1 = it will fire if its conditions are met, but it will only fire once in the game.
2 = it will fire every turn that its conditions are met.
3 = it will only fire on the specific date set, if its conditions are met.
In your example I would use #Type= 1
#CONDITION_POSITION uses 'OR' logic, so any of them will meet the conditions.
Specific example: I want a Decision Event to fire if 1 or more of AXIS units come within 4 hexes of hex position (34,56). The condition would be #CONDITION_POSITION= 34,56 [1,4] [1,20] [1] [0]?
It does use OR logic, and this is how I would write that specific line:
#CONDITION_POSITION= 34,56 [4,4] [1,1] [1] [0]
The [1,4] would mean that the engine would randomly choose between a range of 1-4 hexes, so in one turn it might look at 1 hex, in another at 3 hexes away.
In terms of the number of units, it works the same way, and you just need it to look for 1 in this example.
I hope this helps, but if not then post the full script and we'll see if we can help. [:)]
RE: TYPE, TRIGGER and CONDITION_POSITION
Posted: Sat Oct 27, 2018 6:28 pm
by El Condoro
Thank you - that helps so much. The random hex check I would never have worked out and the rest of your response makes everything (about these topics) clear.
I also have a question about global variables. In my experience a GV is set (e.g. SetGlobalVar x = y) and then can be called from any script (e.g. GetGlobalVar x). In the text files it says a #GV= 1[min,max] is set randomly, so I'm not sure a) if I can set a GV and b) how it is used in the game. I'll have a search through the text files for a SC campaign and see if I can work it out but I am not using them ATM so it's not urgent.
RE: TYPE, TRIGGER and CONDITION_POSITION
Posted: Sat Oct 27, 2018 10:41 pm
by El Condoro
ORIGINAL: BillRunacre
Not quite,
0 = it won't fire, this script is in the game but not activated.
I just checked and saw that I had quite a few set to 0 but they were firing. I must admit I was confused why this value would stop the script firing when #FLAG = 0 does the same thing. Could #TYPE= 0 have a different use?
RE: TYPE, TRIGGER and CONDITION_POSITION
Posted: Sun Oct 28, 2018 1:37 pm
by BillRunacre
Yes, you are right.
Flag= 0 means it won't fire in the game.
Type= 0 means the engine will only check once when all other conditions have been met, this only really works differently to type= 1 if it has a trigger % less than 100%, i.e. there is a less than 100% chance of the event happening in the game, and it only checks once.
So the reason to use Type= 0 is if you want the event to happen in some games, but not necessarily all. I use this for many of the historical Pop Up scripts, so players won't see them all every game.
For GV numbers, the engine sets them, but you can use them to make it so that a result may only happen in some games. So let's say that you want an event (e.g. Anglo-French expedition to Finland) to have a 50% chance of success.
There needs to be a result, i.e. success or failure, with scripts describing whichever is the outcome.
So, those scripts using GV1= 1,50 could denote success, those with GV1= 51,100 could denote failure.
The engine randomly sets the GV numbers at the start of the game.
If you use the GV numbers a lot then it's best to use different numbers for different scripts, i.e. don't just use GV1, use GV2, 3, 4 etc for maximum variability.
RE: TYPE, TRIGGER and CONDITION_POSITION
Posted: Fri Nov 02, 2018 10:30 pm
by El Condoro
Can the engine check to see that a condition does NOT occur?
I want to affect the mobilization of a country ID when a resource is unoccupied by an alignment [2]. So if resource at x,y does not have a unit of alignment [2] in it, the country will mobilize 15-20%.
I tried
#CONDITION_POSITION= x,y [1,1] [0,0] [2] [0]
but it fired even if a unit of alignment [2] was in the resource.
[Edit]: This won't work because the engine is looking for at least 0 units, so it will fire every time.
The manual does say mobilization_2.txt can check for the absence of units, so I am missing something!
[Edit]: I think I worked it out by looking at how it is done with the Axis units around Warsaw in SoE. Basically, 2 events run - one that (almost) always fires that mobilizes towards one alignment, and another that fires only when certain unit position conditions are met. So, when those units positions are NOT met, the first event is the one that has the desired effect.
[Edit]: Sorry to be keeping a journal here! It seems all that is needed is
#CONDITION_POSITION= x,y [1,1] [0,0] [2] [0]
which means the event fires if no alignment [2] units are within 1 hex of x,y.
RE: TYPE, TRIGGER and CONDITION_POSITION
Posted: Sat Nov 03, 2018 12:28 am
by sPzAbt653
when a resource is unoccupied by an alignment ... The manual does say mobilization_2.txt can check for the absence of units
What if you make the Unit Parameter (1,1), then it checks for at least one unit. So if it is unoccupied by [2] then it will fire, won't it ?
RE: TYPE, TRIGGER and CONDITION_POSITION
Posted: Sat Nov 03, 2018 12:41 am
by El Condoro
I think my problem was with the alignment status of the units being checked for. The script was firing every time because the condition was looking for aligned units when they had not yet mobilized. Once I set the correct #VARIABLE_CONDITION to make sure they had actually mobilized, it all worked correctly.