For co-op campaign projects, I want to implement message guards (using switches, or deaths) for dialogue events. These would prevent other dialogue events from firing until the switch was cleared or the death was reset. In singleplayer, this is accomplished by checking if the switch is cleared, setting the switch before transmissions, and clearing it at the end of the trigger. The problem with this system ported 1:1 in multiplayer is that the switch is set in player 1's trigger before player 2's can fire. I'm looking for the simplest implementation of this in multiplayer. Thanks in advance.

Since player 2's triggers always fire after player 1's, you can set the switch in player 1's trigger, and then clear it in player 2's trigger. That way, the transmission will play for player 1, all of his other triggers will check if the switch is cleared (it's not), and then after the transmission is played for player 2, the switch becomes cleared, allowing the other triggers to run.

Also, it doesn't matter how you do it, but I typically like to use deaths for dialogue events as a way to organize the sequences. So if there's an event that has 5 transmissions, I'll use one unit and have a death for each transmission/event that needs to occur (0-4), and then for another event, I'll use a different unit. Either way works though.

Switches only work if both players are forced to be present in order to play (which very well may be the case), otherwise one or the other won't fire if a player is missing. The most general solution is if you have any available units for DCs just change the switches to a DC for current player. If you have multiple such switches, I assume only one would be allowed to fire at a time so you could use the same death with a unique value for each dialogue sequence.

EDIT: demon sneaked in deaths to his post before I posted mine lmao

I thought about Dem0n's solution (clearing in p2's trigger), but I'm not sure how that would prevent p2's other transmission triggers from firing while dialog events were occuring. Would p2's trigger have to detect if the message guard switch was set, rather than cleared? A simple 'switch is cleared' condition doesn't work since it's set in p1's trigger.

I'm aware of the problem posed by losing a player mid-way (through them leaving or being defeated) and I don't have plans to address this. I have a separate set of triggers that fire if the map is played singleplayer.

I think the simplest foolproof way to do this would be to give the triggers that fire a transmission to a computer/neutral player that is never defeated during the entire game, and give the human players the second part of the triggers that have the transmission actions. But every transmission will need their unique death count value.

Example (assuming both human players are in Force 1):


Then 2 deaths instead of 1 for another transmission event, and so on. Also give both human players separate triggers checking if the other player commands 0 any units, set their DC to 0, in case a player leaves in the middle of a transmission.
The computer-owned triggers should preferably not be owned by one that's between the human players, so that the latter human won't receive the transmission one trigger cycle earlier than the other.

I'll give that solution a try, thanks.

Why not use Current Player DCs? (Everything below is owned by the player force, and is checked and executed for Current Player)
This is similar to what DarkenedFantasies suggested, but instead of using a computer player that handles it for the whole force, you use an extra value in the DC so Current Player can handle it for themselves.
The advantage is that you can set the DC to play a transmission with triggers owned by the force, so you can say "Current Player enters 'loc_Cutscene1' add x to dc_Trans for Force1 (players)"

Each transmission is assigned a binary value:
Transmission1 eq 1 (2^0)
Transmission2 eq 2 (2^1)
Transmission3 eq 4 (2^2)
... etc.
Transmission30 eq ~0.5 billion (2^29)

Why stop here?
2^32 = highest value for 32 bit unsigned variable
2^31 = highest value for DCs: 32 bit signed => 2^31 positive values, while the negative values aren't used.
2^30 = signifies that a transmission is currently playing by adding ~1bil. (see how it's used below)
0 means that a transmission is neither queued nor is one playing.

1st trigger (in order)


2nd trigger (in order)

...

30th trigger (in order)


Post has been edited 4 time(s), last time on Jan 12 2019, 4:11 pm by NudeRaider.

Why do you use powers of two? It seems that way I'd be limited to 30 transmissions per map.

Per death counter, not per map, and presumably so that you can meet multiple conditions at once. For example, if you had a transmission to play at DC 1 and another to play at DC 2, then if they both fired on the same loop, it'd add to a total of 3, and the subtraction would work in reverse. It's a binary system.

If you don't need to support multiple transmissions on the same trigger loop, you don't need to make a binary system.

I like this much better. However, I'd instead use consecutive integers (to a certain value that you think you'd never reach), and use its sum plus one as the guard condition. That would increase the amount of transmission events you can have for a single death counter, and would be easier to work with, I guess.

For example, 100 transmissions:

It appears we have a winner. Thanks a lot, Nude and DF, and to the others who pitched in.

To have unique ranges for each message, to avoid bugs. Assigning values 1-100 can potentially lead to bugs. Roy mentioned one, but there's another:

When one transmission is running, and during that 2 others get queued the trigger system can't distinguish anymore.
For example:
It plays 80, but 30 and 50 get triggered before 80 is finished, it will play 80 again, instead of 30 and 50.
Of course you can add more conditions (DF suggested elapsed scenario time), but I'm not sure you can make it fool proof that way. Especially for low numbers (late game), like 5+6 while 8 is playing, I'd imagine you can't predict it with elapsed time. Using higher values would work well for that. Like that:
1bil = blocker value
1mil+1 = 1st transmisson
1mil+2 = 2nd transmisson
1mil+3 = 3rd transmisson
1mil+4 = 4th transmisson
... etc

That way there's no way the cases get confused, unless you get over 1 million messages.

About the concern of having too few transmissions available with the former method: Add more DCs if you need more transmissions. But you'll have to set and check each new DC for the 2^30 value in each trigger, adding one condition per 30 transmission, making things difficult when you hit more than 15*30 = 450 transmissions, because you will hit the max of 16 conditions.

I think you've underestimated the power of adding another condition to the trigger. If one DC has 30 available values, two DCs would have 900 available values. It's exponential.

DF and I have been racking our collective brains trying to come up with a reason why these triggers would fail. The current issue is that the wrong dialogue event trips, as if the deaths are being added in the wrong amounts. Though it may be a small maths error, it may be a shortcoming of the system we didn't oversee, so I'm posting the triggers here in the hopes that a fresh pair of eyes can spot the flaw. Click me

Specifications:
Force 1 = two human players (P1, P2)
Single frame hypertriggers are in effect through a mempatch in GPTP
These are the only triggers that deal with the deaths of the zerg mutalisk ("9gag Moderator" in the mod)

Thanks for your time.

It's trigger order. You have to start with the largest value for the transmission triggers.

I'll try that and post results, thanks!

That seemed to have resolved some of the issues in the early game, but we still ended up with some triggers playing when they shouldn't have towards the midsection of the mission. I think this is the right track so I'll take a closer look at the individual dcs a little later on. Thanks for the help!

you can temporarily use custom score instead of dcs to keep track of the values on the score board. Adding text messages also helps when debugging.

Oh and be wary when using the commands condition. Its state lingers for 1 trigger loop longer than brings, so you might accidentially add 2 of the same transmission dc.

Post has been edited 1 time(s), last time on Jan 21 2019, 8:52 pm by NudeRaider.

I thought I read somewhere that bring was slower than command, but maybe it's the inverse. I should be using bring 0 at anywhere, then?

Bring is instant, but keep in mind that bring doesn't always update the cache: http://www.staredit.net/topic/2754/#54441

So if you invalidate a bring condition by creating a unit, for example, the next trigger *within the same loop* will still give the same result as if you hadn't just created the unit. This will update before the next trigger loop.