Staredit Network > Forums > SC1 UMS Mapmaking Assistance > Topic: Message guards for multiple players
Message guards for multiple players
Jan 11 2019, 8:02 pm
By: Pr0nogo  

Jan 11 2019, 8:02 pm Pr0nogo Post #1



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.




Jan 11 2019, 8:55 pm Dem0n Post #2

ᕕ( ᐛ )ᕗ

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.



Memes gather, and now my watch begins. It shall not end until my death. I shall take no wife, hold no lands, father no children. I shall wear no crowns and win no glory. I shall live and die at my post. I am the sword in the darkness. I am the memer on the walls. I am the shield that guards the realms of memes. I pledge my life and honor to the Meme's Watch, for this meme and all the memes to come.

Jan 11 2019, 9:01 pm O)FaRTy1billion[MM] Post #3

👻 👾 👽 💪

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



TinyMap2 - Latest in map compression! ( 7/09/14 - New build! )
EUD Action Enabler - Lightweight EUD/EPD support! (ChaosLauncher/MPQDraft support!)
EUDDB - topic - Help out by adding your EUDs! Or Submit reference files in the References tab!
MapSketch - New image->map generator!
EUDTrig - topic - Quickly and easily convert offsets to EUDs! (extended players supported)
SC2 Map Texture Mask Importer/Exporter - Edit texture placement in an image editor!
\:farty\: This page has been viewed [img]http://farty1billion.dyndns.org/Clicky.php?img.gif[/img] times!

Jan 12 2019, 12:37 am Pr0nogo Post #4



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.




Jan 12 2019, 2:10 am DarkenedFantasies Post #5

Roy's Secret Service

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):
Trigger owned by computer/neutral player.
Players

  • Player 8
  • Conditions

  • Force 1 has suffered exactly 0 deaths of DC.
  • (Any other conditions required for the transmission to happen.)
  • Actions

  • Modify death counts for Force 1: Set to 1 for DC.

  • Trigger owned by human players
    Players

  • Force 1
  • Conditions

  • Current Player has suffered exactly 1 deaths of DC.
  • Actions

  • Send Transmission.
  • Modify death counts for Current Player: Set to 0 for DC.

  • 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.




    Jan 12 2019, 2:29 am Pr0nogo Post #6



    I'll give that solution a try, thanks.




    Jan 12 2019, 4:01 pm NudeRaider Post #7

    We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch

    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)
    IF dc_Trans >= 2^29
    AND dc_Trans <= 2^30
    THEN add to dc_Trans 2^30
    subtract 2^29 from dc_Trans
    play transmission
    subtract 2^30 from dc_Trans


    2nd trigger (in order)
    IF dc_Trans >= 2^28
    AND dc_Trans <= 2^30
    THEN add to dc_Trans 2^30
    subtract 2^28 from dc_Trans
    play transmission
    subtract 2^30 from dc_Trans

    ...

    30th trigger (in order)
    IF dc_Trans >= 1
    AND dc_Trans <= 2^30
    THEN add to dc_Trans 2^30
    subtract 1 from dc_Trans
    play transmission
    subtract 2^30 from dc_Trans


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




    Jan 12 2019, 8:03 pm Pr0nogo Post #8



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




    Jan 12 2019, 8:12 pm Roy Post #9

    An artist's depiction of an Extended Unit Death

    Quote from Pr0nogo
    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.




    Jan 12 2019, 8:24 pm DarkenedFantasies Post #10

    Roy's Secret Service

    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:
    Event 1
    Players

  • (Any)
  • Conditions

  • Elapsed scenario time is at least 5 game seconds.
  • Actions

  • Modify death counts for Force 1: Add 100 for DC.

  • Event 2
    Players

  • (Any)
  • Conditions

  • Elapsed scenario time is at least 7 game seconds.
  • Actions

  • Modify death counts for Force 1: Add 99 for DC.

  • Transmission 1
    Players

  • Force 1
  • Conditions

  • Current Player has suffered at least 100 deaths of DC.
  • Current Player has suffered at most 5050 deaths of DC.
  • Actions

  • Modify death counts for Current Player: Add 5051 for DC.
  • Modify death counts for Current Player: Subtract 100 for DC.
  • Send Transmission.
  • Modify death counts for Current Player: Subtract 5051 for DC.

  • Transmission 2
    Players

  • Force 1
  • Conditions

  • Current Player has suffered at least 99 deaths of DC.
  • Current Player has suffered at most 5050 deaths of DC.
  • Actions

  • Modify death counts for Current Player: Add 5051 for DC.
  • Modify death counts for Current Player: Subtract 99 for DC.
  • Send Transmission.
  • Modify death counts for Current Player: Subtract 5051 for DC.





  • Jan 12 2019, 10:31 pm Pr0nogo Post #11



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




    Jan 13 2019, 9:04 am NudeRaider Post #12

    We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch

    Quote from Pr0nogo
    Why do you use powers of two? It seems that way I'd be limited to 30 transmissions per map.
    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. :P

    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.




    Options
      Back to forum
    Please log in to reply to this topic or to report it.
    Members in this topic: None.
    [11:23 am]
    Moose -- LMAOOOO
    [11:22 am]
    Pr0nogo -- alex jones was right
    [11:22 am]
    Pr0nogo -- also known as being gay
    [11:22 am]
    Pr0nogo -- sounds like your opinions aren't based in objective assessments or even personal experiences but instead conform to the antithesis of everyone around you
    [08:14 am]
    KrayZee -- I don't get it. When a video game is unreasonably criticized harshly, I have fun playing those games. When a game is overhyped, I can't enjoy it for some reason. Bah.
    [07:25 am]
    NudeRaider -- Vrael
    Vrael shouted: lil-Inferno lil-Inferno don't worry I'll probably finish before Starcraft 6
    "probably" :lol:
    [03:00 am]
    RIVE -- xd
    [02:35 am]
    O)FaRTy1billion[MM] -- xd
    [02:33 am]
    Moose -- xd
    [01:40 am]
    lil-Inferno -- xd
    Please log in to shout.


    Members Online: lifebot, Roy, Pr0nogo, jjf28, unanumum, Moose