Help with a random placement trigger system

[Cernel]

@redrum said in Help with a random placement trigger system:

@Frostion The one other point is mathematically speaking you aren't going to get 1/6 chance for each of them the way you have it. The reason is that the chance of say the second one happening is actually 5/6*1/6 as its the chance the first one fails times the chance the second succeeds and so on. For the second one it isn't that big of a deal but once you get to the 5th one that one will almost never fire since its (5/6)^4*1/6 ~ 8%. So you probably want slightly increasing probabilities through the triggers.

The way @Frostion is presenting the coding is actually that all those activations would be tested and fire at the same time, so you could get all five of the first one or none, or anything in between, plus always the sixth one, assuming he also eventually corrects the last Booleans in them, as currently none of those activations are even testing for chances, nor conditions.

Theorically one could do what @Frostion wants with a very complex series of activations, in which the activated trigger itself activates another one, and so forth. Alternatively, you can hack it with the random placement delegate; say you create 6 boxes and let it place in one, see what get picked and test it out.

[Frostion]

I will try use the example code.

@redrum said "So you probably want slightly increasing probabilities through the triggers."

So would it be reasonable to use something like:

1. trigger: 3/18 (aka 1/6)
2. trigger: 3/16
3. trigger: 3/14
4. trigger: 3/12 (aka 1/4)
5. trigger: 3/10
6. trigger: 1/1

or

1. trigger: 3/18 (aka 1/6)
2. trigger: 3/15 ( aka 1/5)
3. trigger: 3/12 (aka 1/4)
4. trigger: 3/9 (aka 1/3)
5. trigger: 3/6 (aka 1/2)
6. trigger: 1/1

???

[redrum]

@Frostion The second set of probabilities is exactly what you want as each time one fails to fire you want to up the chance so its 1 over the remaining ones left.

[Cernel]

@Frostion Also the coding posted by @redrum would just be tested all at the same time; so the "conditionAttachmentSpawnDragon7" is substantially pointless, as, at the moment it is tested, it would be always true (accounting the "invert"), if there was not a "Young-Water-Dragon" in the map before that phase. It doesn't matter the xml order; those triggers all fire, and are tested, at the exactly same time ("before:PiratesPurchase"), and what is modified by any of them doesn't matter as far as testing for any other ones go. Besides hacking it by creating a series of otherwise pointless phases (like a bunch of no-PUs end turns one after the other, before the phase you actually want to be in), the only way of testing at the same moment, taking into account what modified by other triggers acting at the same time, is such triggers being activated by the ones that are changing the state themselves, in this case in a chain of activations.

What I was saying is that, if not with the random placement hack, what you should do is having a first trigger that surely places the sixth thing and activates a second trigger that has 5/6 probability of removing that thing, placing the fifth thing and activating a third trigger that has 4/5 probability of removing that thing, placing the fourth thing and activating a fourth trigger that has 3/4 probability of removing that thing, placing the third thing and activating a fourth trigger that has 2/3 probability of removing that thing, placing the second thing and activating a fifth trigger that has 1/2 probability of removing that thing and placing the first thing (with "that thing" I always mean the latest things (one or more) that have been placed by the preceding trigger in the sequence).

Alternatively, you can go with a coding like the one posted by @redrum, but with decreasing 1:1, 1:2... 1:6 chances, then another set of conditions and triggers, firing at a subsequent point, that removes everything placed by triggers with a higher chance than what is tested to have been successfully placed, but only as long as those units cannot be there by any other means, at that point. Or, if @redrum can tell that a trigger removal is meant and will always remove what placed by other triggers that place stuff, firing at the same point, you can integrate this on the same triggers, having each trigger also removing anything possibly placed by any other such triggers with higher chances to happen, but only as long as those units cannot be there by any other means, at that point.

[redrum]

@Cernel Yeah, there is a couple different ways to do it. I went with something kind of in between your 2 suggestions but using more conditions with switches to avoid having to place/remove units. Essentially first decide which dragon needs placed with a set of chained triggers using the inverse odds and then a set of triggers that checks the result of those triggers and places the appropriate dragon. Not really sure if that's the best way but it seems to work.

@Frostion Here are triggers that should achieve what you want:

        <attachment name="conditionAttachmentSpawnDragonRound1" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player">
            <option name="rounds" value="1"/>
        </attachment>        
        <attachment name="conditionAttachmentSpawnDragon1" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player">
            <option name="switch" value="true"/>
        </attachment>       
        <attachment name="conditionAttachmentNotSpawnDragon1" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player">
            <option name="conditions" value="conditionAttachmentSpawnDragon1"/>
            <option name="invert" value="true"/>
        </attachment>       
        <attachment name="conditionAttachmentSpawnDragon2" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player">
            <option name="switch" value="true"/>
        </attachment>       
        <attachment name="conditionAttachmentNotSpawnDragon2" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player">
            <option name="conditions" value="conditionAttachmentSpawnDragon2"/>
            <option name="invert" value="true"/>
        </attachment>       
        <attachment name="conditionAttachmentSpawnDragon3" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player">
            <option name="switch" value="true"/>
        </attachment>        
        <attachment name="conditionAttachmentNotSpawnDragon3" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player">
            <option name="conditions" value="conditionAttachmentSpawnDragon3"/>
            <option name="invert" value="true"/>
        </attachment>        
        <attachment name="conditionAttachmentSpawnDragon4" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player">
            <option name="switch" value="true"/>
        </attachment>       
        <attachment name="conditionAttachmentNotSpawnDragon4" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player">
            <option name="conditions" value="conditionAttachmentSpawnDragon4"/>
            <option name="invert" value="true"/>
        </attachment>        
        <attachment name="conditionAttachmentSpawnDragon5" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player">
            <option name="switch" value="true"/>
        </attachment>        
        <attachment name="conditionAttachmentNotSpawnDragon5" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player">
            <option name="conditions" value="conditionAttachmentSpawnDragon5"/>
            <option name="invert" value="true"/>
        </attachment>
        
        <attachment name="triggerAttachmentNew_Water_Dragon_5" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
            <option name="players" value="Pirates"/>
            <option name="playerAttachmentName" value="RulesAttachment" count="conditionAttachmentSpawnDragon5"/>
            <option name="playerProperty" value="switch" count="false"/>
            <option name="when" value="after:PiratesNonCombatMove"/>
            <option name="chance" value="1:2"/>
            <option name="uses" value="1"/>
        </attachment>
        <attachment name="triggerAttachmentNew_Water_Dragon_4" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
            <option name="players" value="Pirates"/>
            <option name="playerAttachmentName" value="RulesAttachment" count="conditionAttachmentSpawnDragon4"/>
            <option name="playerProperty" value="switch" count="false"/>
            <option name="activateTrigger" value="triggerAttachmentNew_Water_Dragon_5:1:false:false:false:true"/>
            <option name="when" value="after:PiratesNonCombatMove"/>
            <option name="chance" value="2:3"/>
            <option name="uses" value="1"/>
        </attachment>
        <attachment name="triggerAttachmentNew_Water_Dragon_3" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
            <option name="players" value="Pirates"/>
            <option name="playerAttachmentName" value="RulesAttachment" count="conditionAttachmentSpawnDragon3"/>
            <option name="playerProperty" value="switch" count="false"/>
            <option name="activateTrigger" value="triggerAttachmentNew_Water_Dragon_4:1:false:false:false:true"/>
            <option name="when" value="after:PiratesNonCombatMove"/>
            <option name="chance" value="3:4"/>
            <option name="uses" value="1"/>
        </attachment>
        <attachment name="triggerAttachmentNew_Water_Dragon_2" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">            
            <option name="players" value="Pirates"/>
            <option name="playerAttachmentName" value="RulesAttachment" count="conditionAttachmentSpawnDragon2"/>
            <option name="playerProperty" value="switch" count="false"/>
            <option name="activateTrigger" value="triggerAttachmentNew_Water_Dragon_3:1:false:false:false:true"/>
            <option name="when" value="after:PiratesNonCombatMove"/>
            <option name="chance" value="4:5"/>
            <option name="uses" value="1"/>
        </attachment>
        <attachment name="triggerAttachmentNew_Water_Dragon_1" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
            <option name="conditions" value="conditionAttachmentSpawnDragonRound1"/>
            <option name="players" value="Pirates"/>
            <option name="playerAttachmentName" value="RulesAttachment" count="conditionAttachmentSpawnDragon1"/>
            <option name="playerProperty" value="switch" count="false"/>
            <option name="activateTrigger" value="triggerAttachmentNew_Water_Dragon_2:1:false:false:false:true"/>
            <option name="when" value="after:PiratesNonCombatMove"/>
            <option name="chance" value="5:6"/>
            <option name="uses" value="1"/>
        </attachment>
        
        <attachment name="triggerAttachmentPlace_Water_Dragon_1" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
            <option name="conditions" value="conditionAttachmentSpawnDragon1"/>
            <option name="placement" value="Sea Zone 33:Young-Water-Dragon"/>
            <option name="placement" value="Sea Zone 33:Pirate-Ship"/>
            <option name="placement" value="Sea Zone 33:Pirate-Boat"/>
            <option name="players" value="Pirates"/>
            <option name="when" value="before:PiratesPurchase"/>
            <option name="uses" value="1"/>
        </attachment>
        <attachment name="triggerAttachmentPlace_Water_Dragon_2" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
            <option name="conditions" value="conditionAttachmentNotSpawnDragon1:conditionAttachmentSpawnDragon2"/>
            <option name="placement" value="Sea Zone 35:Young-Water-Dragon"/>
            <option name="placement" value="Sea Zone 35:Pirate-Ship"/>
            <option name="placement" value="Sea Zone 35:Pirate-Boat"/>
            <option name="players" value="Pirates"/>
            <option name="when" value="before:PiratesPurchase"/>
            <option name="uses" value="1"/>
        </attachment>
        <attachment name="triggerAttachmentPlace_Water_Dragon_3" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
            <option name="conditions" value="conditionAttachmentNotSpawnDragon1:conditionAttachmentNotSpawnDragon2:conditionAttachmentSpawnDragon3"/>
            <option name="placement" value="Sea Zone 40:Young-Water-Dragon"/>
            <option name="placement" value="Sea Zone 40:Pirate-Ship"/>
            <option name="placement" value="Sea Zone 40:Pirate-Boat"/>
            <option name="players" value="Pirates"/>
            <option name="when" value="before:PiratesPurchase"/>
            <option name="uses" value="1"/>
        </attachment>
        <attachment name="triggerAttachmentPlace_Water_Dragon_4" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
            <option name="conditions" value="conditionAttachmentNotSpawnDragon1:conditionAttachmentNotSpawnDragon2:conditionAttachmentNotSpawnDragon3:conditionAttachmentSpawnDragon4"/>
            <option name="placement" value="Sea Zone 46:Young-Water-Dragon"/>
            <option name="placement" value="Sea Zone 46:Pirate-Ship"/>
            <option name="placement" value="Sea Zone 46:Pirate-Boat"/>
            <option name="players" value="Pirates"/>
            <option name="when" value="before:PiratesPurchase"/>
            <option name="uses" value="1"/>
        </attachment>
        <attachment name="triggerAttachmentPlace_Water_Dragon_5" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
            <option name="conditions" value="conditionAttachmentNotSpawnDragon1:conditionAttachmentNotSpawnDragon2:conditionAttachmentNotSpawnDragon3:conditionAttachmentNotSpawnDragon4:conditionAttachmentSpawnDragon5"/>
            <option name="placement" value="Sea Zone 12:Young-Water-Dragon"/>
            <option name="placement" value="Sea Zone 12:Pirate-Ship"/>
            <option name="placement" value="Sea Zone 12:Pirate-Boat"/>
            <option name="players" value="Pirates"/>
            <option name="when" value="before:PiratesPurchase"/>
            <option name="uses" value="1"/>
        </attachment>
        <attachment name="triggerAttachmentPlace_Water_Dragon_6" attachTo="Pirates" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
            <option name="conditions" value="conditionAttachmentNotSpawnDragon1:conditionAttachmentNotSpawnDragon2:conditionAttachmentNotSpawnDragon3:conditionAttachmentNotSpawnDragon4:conditionAttachmentNotSpawnDragon5"/>
            <option name="placement" value="Sea Zone 71:Young-Water-Dragon"/>
            <option name="placement" value="Sea Zone 71:Pirate-Ship"/>
            <option name="placement" value="Sea Zone 71:Pirate-Boat"/>
            <option name="players" value="Pirates"/>
            <option name="when" value="before:PiratesPurchase"/>
            <option name="uses" value="1"/>
        </attachment>

[Cernel]

@redrum You don't have to assign any when to the triggers meant to be activated only, when they have no conditions (so will never fire on their own).

You can just test for the immediately preeceding "conditionAttachmentNotSpawnDragon", not all of them.

[Cernel]

@redrum Keeping placing and removing stuff is not wonderful, I know, but I like the idea to split a logically same thing amongst two different unrelated points, as this is also confusing and a liability, in managing the phase order.

I would do five true switches. Then a trigger that activates two other triggers. The first activated trigger is a trigger that 1:6 both places the first thing and set to false the first switch and the second activated trigger is a trigger that tests for the first switch to be true and, if so, it fires another trigger that does the same, but for the second thing and the second switch, and at 1:5. So on and so forth, with increasing 1:4, 1:3, 1:2, 1:1 probabilities for the third, fourth, fifth and sixth things, except the sixth doesn't switch anything.

I haven't tested anything, and here the question would be if an activated trigger testing for conditions will test for a condition at the state after what has been modified by another trigger activated by the same original trigger, as long as such option is listed beforehand, in it.

I would say it should. But should it and does it?

The matter, practically, would be that when I have a trigger doing multiple things, listed in sequence, if one of these things is a trigger activation testing for conditions, should this condition state take into account what that trigger may have modified beforehand only or thereafter too, and only what the trigger changes directly, or what is done through activation all the same?

The simplest case, currently, is if I have a trigger directly doing something and, also, activating another trigger that does something else. The question here would be, if this activation testes for condition, whether or not what the trigger already did matters for the condition testing or not.

Then the matter should be expanded to clarify if anything changes in case, in the trigger, first I've the trigger activation, and, then, some direct effect for that trigger.

Then the matter should be expanded to clarify the case of multiple trigger activations with conditions testing, within the same trigger.

Regardless of this matter, I'd like to clarify this item, and update pact of steel as to make it official, please.

[Frostion]

it would be so much simpler if triggers just activated in the order that they are listed in the XML, top down. I actually thought that it worked that way.

[Cernel]

@Frostion That is ok working the current way, as all simple triggers firing at the same moment are simultaneous, so the state is and should be tested as it was before any of them firing. It would be nice if they are listed in history in the same order as in the xml, but this would be for display only.

Just obtaining a simple sequential firing of trigger at the same moment is not too complex. You just need to make a trigger A that activates a trigger B, then the trigger B activates a trigger C, then the trigger C activates a trigger D, etc..

However, this should be probably all documented in pos2, as it is not the first time it comes out.

[Cernel]

For example, if we have a trigger "0" that does something directly and also activates triggers "A1" and "B1", that also do things directly. Moreover, "A1" activates another trigger "A2", that does things directly and also activates another trigger "A3", that just does thing directly. "B1" also activates "B2" and "C2" triggers, both just doing things directly.
If all activated triggers test for conditions (to actually be activated), what state these conditions should see (thus test for)?

For example, should the activation of "B1" test the state as modified by what "0" did directly. Should "B1" test the state as modified by what "A1" did directly, or indirectly ("A2" and "A3").

Logically, I tend to think that, for example, "B1" should test the state as modified by what "0" did directly, but without accounting what any other triggers did, while, for example, "C2" should test the state as modified by what "0" and "B1" did directly, but without accounting what other triggers did, not even "A1".

Amirite?

This matters not only for conditions, but for the state in general. For example, if we assume activated triggers happen after the trigger that activate them, "A2" would be able to remove a unit directly placed by "A1", but "A1" would not be able to remove a unit that is going to be placed by "A2", because the unit is not already there.

This also opens the question whether or not a simple (not activated) trigger removing units should be able to remove the units placed by another simple trigger firing at the same point (moment) (this is actually what "Blue vs. Gray" does, and it works). Like if I make a trigger placing 1 infantry in Germany and a trigger removing 1 infantry in Germany, and fire them independently at the same moment, assuming there are no infantries in Germany already, should the infantry be removed?

[Frostion]

When a trigger is activated by another trigger, does the activated trigger make use of any conditions it maybe has listed inside itself? Or are its own conditions just ignored, as the trigger is fired by another trigger?

[Cernel]

@Frostion For the activated trigger, the conditions are tested only if the penultimate Boolean or the "activateTrigger" option is true.

[Frostion]

@Redrum @Cernel Thanks for the help guys! I have chosen to just use the last set of conditions and triggers made by Redrum. They seem to work as intended. I must admid though that I don’t really grasp the technical process happening in those triggers. Maybe if I studied them for some days, I could realize how they work