Also, moving to Mapmaking.
We should really define better what is the difference between Maps & Mods and Mapmaking, because, as it is, we might as well merge the two. I would reserve Maps & Mods for the official threads only.
@RogerCooper You need to specify the players. Don't forget Neutral, in case.
Personally, I much dislike that if not specified it applies to none. I would change the behaviour as if not specified it applies to all, but this would bug off a few games (shouldn't be too hard to track them, but some may be overlooked, as that's usually used in complex maps when you give support with triggers during them). Of course, also with the ability to have it and leaving it empty (to define it applies to none).
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".
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 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.
@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.
@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.
@Ondis A lot of Medieval warfare consisted in raiding, especially for the Turks in Anatolia. Assuming that retreating is possibly only the consequence of a fail and that you always and only aim at taking and staying with all your attacking forces in the territory you invaded is ahistorical. Of course, this adds the fact that TripleA doesn't allow you to represent booty, as the triggers giving you PUs for destroyed TUV are very basic, and anyways that is not taking into account the resources of the target territory itself.
@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.