hi all,

my map has bases players can control and steal from each other by bringing the most units to the base beacon.

this works great in true inequality of ownership, but if two players bring say, one unit each to the beacon, it tosses it back and forth rapidly (hyper triggers) and spams both players with my "beacon acquired" message.

is there any way to remedy this? I'm pretty saddened that "command most at" doesn't wait for true inequality of command before re-firing. any thoughts are appreciated!

I need a "commands exactly the same at" condition

If you have at each location a beacon, and Player 8 as a computer player, you can do the following (Be sure to keep the triggers IN THIS ORDER):

Triggername
Players

Force 1
Conditions

Player 7 Brings at least 1 "Zerg Hydralisk" to Location X
Current Player Commands the most men at Location X
Current Player Brings at least 1 "Beacon" to Location X
Actions

Remove 1 "Zerg Hydralisk" at Location X for Player 7
Preserve Trigger

Triggername
Players

Force 1
Conditions

Player 7 Brings exactly 1 "Zerg Hydralisk" to Location X
Current Player Commands the most men at Location X
Actions

Remove 1 "Zerg Hydralisk" at Location X for Player 7
Give 1 Beacon owned by Any Player at Location X to Current Player
Display Text("You captured the beacon!")
Preserve Trigger


Triggername
Players

Force 1
Conditions

Player 7 brings at least "Zerg Zergling" to Location X
Current Player Commands the most men at Location X
Actions

Remove 1 "Zerg Zergling" at Location X for Player 7 at Location X
Create 1 burrowed, invincible "Zerg Drone" for Player 7 At Location X


Triggername
Players

Force 1
Conditions

Current Player brings exactly 0 Beacon to Location X
Player 7 brings exactly 0 "Zerg Zergling" to Location X
Player 7 brings exactly 0 "Zerg Hydralisk" to Location X
Player 7 brings exactly 0 "Zerg Drone" to Location X
Current Player Commands the most men at Location X
Actions

Create 1 burrowed, invincible "Zerg Zergling" for Player 7 at Location X
Preserve Trigger



Triggername
Players

Player 8
Conditions

Player 7 brings at least "Zerg Zergling" to Location X
Actions

Remove 1 "Zerg Zergling" at Location X for Player 7
Create 1 burrowed, invincible "Zerg Hydralisk" for Player 7 at Location X
Preserve Trigger


Triggername
Players

Player 8
Conditions

Player 7 brings at least "Zerg Drone" to Location X
Actions

Remove 1 "Zerg Drone" at Location X for Player 7
Preserve Trigger

Post has been edited 1 time(s), last time on Apr 15 2017, 11:04 pm by Zoan.

Thinking about this, a solution much simpler (logically, perhaps not in number of triggers) than Zoan's should be possible.

Assume beacon starts with P12 to begin with.

• If current player brings most men to location && beacon belongs to P12 -> give to current player [owned by P1 and P2]
  
• Set switches 10,11,20,21 to FALSE
  
• If beacon belongs to P1 && P1 brings most men to location -> set switch 10 to TRUE
  
• If beacon belongs to P1 && P2 brings most men to location -> set switch 11 to TRUE
  
• If beacon belongs to P2 && P2 brings most men to location -> set switch 20 to TRUE
  
• If beacon belongs to P2 && P1 brings most men to location -> set switch 21 to TRUE
  
• If switch 11 is TRUE and switch 10 is FALSE, give beacon to P2
  
• If switch 21 is TRUE and switch 20 is FALSE, give beacon to P1
  

In any given trigger run, it is impossible for all 4 switches to be true; at most 10 and 11 can be true, or 20 and 21 can be true. This is because there can be only 1 owner of the beacon. All of the triggers except the first one need to be owned by a neutral computer player, so they are only run once per trigger cycle (if both P1 and P2 own these triggers, they won't work as expected).

Basically ownership of the beacon is only changed when one player has more men than the other. If there is a tie in a given trigger cycle, P1 always wins it. That's not super fair, so you could go further and add some randomisation to this scheme if you want. However in practice since triggers fire 12 times a second, it's unlikely you'll have both players bring equal number of units to the location at the precise same time, unless it's possible to spawn units inside the location.

Post has been edited 1 time(s), last time on Apr 15 2017, 9:17 pm by Lanthanide.

This is a lot easier to understand, though if there are multiple bases you would burn through a lot of switches, and it's not as easy to copy-paste the triggers to be applied to other locations.

I edited my trigger text slightly after you quoted, so if anyone reads this and gets confused, that's why.

Any operation done with switches can be re-written to use death counts instead. Eg set a DC to 1000, and add or subtract 10, or 100. So you don't need to burn through switches; I just wrote it this way for clarity / convenience.

There's another solution, if you have a computer player that can do the logic. Requires the comp to be at slot 1 if you want to use elegant (and dynamic) current player triggers.

1. P1 (comp): sets dc_x to 0 for P1
2. P1: if P2 commands the most at x, add 1 to dc_x for P1
3. P1: if P3 commands the most at x, add 1 to dc_x for P1
... for every possible player in force 1

so dc_x ends up being 1 if only one player has the majority of units at beacon x. it's greater than 1 if it's contested.

Now all you gotta do for the capture triggers is to check for dc_x = 1:

1. Force1: if dc_x of P1 is exactly 1 AND current player controls most -> give beacon to current player

I may end up letting the ownership fluctuate (will this cancel units in production?), but tie the messages to a different system so they don't spam the players.

this is really interesting and seems easy to do. I'll experiment.

Really the only problem here is that we need to rely on who owns the beacon in the triggers. If you can delay the "give beacon" action till after all players have calculated the ownership, then you don't need any of these to be owned by a CPU player, whether P1 or otherwise. Or alternatively, if you can determine that it is P1 who should own the beacon, then you just need to prevent P2 from running the same triggers and taking ownership in the same cycle.

And actually there's a simple way to do that - have the trigger that Gives the beacon also set a switch to true (or any other locking mechanism you want, eg DCs), and predicate all triggers to only run if that switch is false. Then set the switch to false at the beginning of each trigger cycle.

So if P1 (human) does the calculations and concludes that it is P2 who should own the beacon, then they don't execute the Give trigger and the switch remains false. P2 then does the same calculations and concludes that it should own the beacon, so it sets the switch to true. P3 skips all their checks for this trigger cycle because the switch is true. So thus you avoid the beacon flipping between P2 and P3 if they had equal geatest numbers.

Post has been edited 1 time(s), last time on Apr 15 2017, 11:15 pm by Lanthanide.

I love the Nude's solution most. As far as I understand it doesn't assume that beacon is owned by P1, but only uses P1 as an arbiter to execute stuff. This can be done without computer players if needed.

This actually prevents giving the beacon to a competitive player only on current cycle. The next cycle the beacon would be given to the competitive player, provided you have conditions that prevent running capture actions for the player that already owns a beacon of course.

Lanthanide solution can be made as simple as Nude's though. You just split events when a player loses beacon or gains control of it. Essentially two-three triggers owned by all players (trigger #1 can be reused by similar subsystems that require to always clear the switch or DC):
1. Always clear switch S.
2. If current player commands the most units at location L and beacon is neutral then gain control of it and set switch S.
2. If switch S is clear and current player controls the beacon then take it away from current player to neutral.

As mentioned there is an inherent unfairness coming from players order. To make everything fair a kind of an arbiter player with a technique like Nude described or similar is required. Then again selection of a dedicated computer player as an arbiter is the simplest but not the only solution.

ADDITION:
As practice shows it is easier to expand over the solution that separates lose/attain events than over the one with only triggers to gain control. The lose control trigger is getting handy in case you need something happening for an offended player: from a simple display message or play sound to charge penalty points or steal resources.


ADDITION2:
By the way, in the SC:R perspective this is the place where we would benefit from a more flexible Command The Most/The Least At condition which could allow to specify the group of players instead of relying only on the current player. That way something like: Allies/Foes command the most units at location would allow allies to help defend or attack over beacons. It shouldn't be a hard thing to implement, but it doesn't seem like we have this in the proposal list.

ADDITION3:
I've read a discussion about using physical units to represent logic states versus using switches and DCs. Would prefer the latter for one more reason: it tends to generate less lag for the map. Actions and conditions that manipulate units are much heavier versus their switches and DCs counterparts. Even though it's much less important for smaller maps, it does count in large projects (and who would know how big one's project is going to grow?).

Even using a beacon to represent base state can ultimately be reduced in favor of DCs. The solution however nearly requires to use some kind of triggers replication tool to be effectively maintained. Also extra precautions must be made for the scenario when a player leaves the game etc.

Post has been edited 7 time(s), last time on Apr 16 2017, 9:16 am by Wormer.

thank you all for the ideas and expertise.

I agree that simple, improvable things like this should be pitched to blizz for the remaster. being free of certain quirks and limitations would be extremely liberating for the UMS crowd.

How? I don't see it.

At least it's as I read your words. Probably I didn't understand.


Don't you imply that switch is set to true in the trigger that gives the beacon from one player to another?

Each player has a trigger that can give the beacon to them. That only occurs if the pre-conditions (most men, etc) are met; the switch being set to false is one precondition.

As soon as the first player makes the transfer (and there's no requirement that the transfer take place in each trigger cycle - in most cycles there will be no transfer), the trigger is set to true, to prevent any other player from also doing a transfer in that same cycle.

Basically we want at most 1 transfer of ownership per trigger cycle.

Maybe I don't understand something, but I thought we were going to prevent the "blink", when two competitive players with the same amount of men repetitively take ownership of the beacon: one player on it's trigger cycle, the other on the next one and so on.

It is exactly what will happen the next trigger cycle after the first player taken the ownership, because the second player still has the most men and switch will be false.

No.

Each player independently performs precisely the same calculation. If there is a tie in men, the current owner maintains ownership. In trigger cycle 1, p1 takes the beacon because they have 1 man there. P2 brings a man for the next cycle so they're tied - both p1 and p2 calculate that p1 should maintain ownership, and so no beacon transfer occurs. On the next trigger cycle, nothing has changed, both p1 and p2 independently calculate that p1 should maintain ownership, and nothing changes.

Repeat until something changes, at which point both players will calculate the correct owner, and the one that wins will take ownership.

Guise, we're great theoreticians there Figuring out there is no such a thing as "Specified player commands the most units at location", only current player is allowed for this condition. Thus, we have hard times precomputing the condition for players independently, also some improvements must be made to Nude's solution to make the thing fair.

Post has been edited 2 time(s), last time on Apr 18 2017, 9:06 am by Wormer.

Doesn't matter too much, if you only have 2 players (would be a bit trickier with more than 2, but still doable).

Set a DC to 1000 to start (or another number of your choice). Have P1 run the "commands most" trigger, and add 10 to the DC. Have P2 run the "commands most" trigger and subtract 10 to the DC.

In P2's cycle, once bother players have run the triggers, if the value is 1000, it means they're tied. If it's 1010, then P1 should have the beacon, if its 990, then P2 should have the beacon. Then simply have the "give beacon" triggers owned by P2 only. This means for P1, any text or other player-specific action like a sound being played can't be played until the next trigger cycle, but that's only 1/12th of a second away so not too noticeable.

:><: I was afraid this is the case but since nobody complained I didn't bother to look it up.

Well then you definitely can't do everything in 1 trigger loop. But you can still use a similar method where every player contributes to a common DC. E.g.: Force1: Current Player Commands the most at dc_x -> add 1 to dc_x for P9.

Don't have too much time to think about it since I'm at work, but probably things would get really tricky, if not impossible without a computer player resetting and processing the dc states. I'll see if I can come up a complete system later.