If I were to implement a "ban" system for a map I make, what sort of banning mechanic should I use?

1. The ban decision system.

I have a few choices here:
-A P1 "banner" unit that bans by walking on top of beacons
-A P1 "banner" unit that bans by killing a unit corresponding to the player to be banned
-One "banner" unit per player that bans by walking on top of beacons, requiring majority rule to ban

2. How the player is actually banned

"Banning" the player can also occur in a variety of ways, with the ones I remember listed below:
-Removing all of his units from play, but allowing the player to stay and watch
-"Defeat" (Removing all units and then "defeat" also falls under this)
-Trigger which crashes the game for that player, e.g. play WAV: ".", giving vision of an invalid unit and centering view on it
-EUD desync (if that can even cause specific players to drop)

I'm leaning towards the "defeat" and majority-ban system, but there is the problem of players being unable to ban infringing parties without more than a set number cooperating, and the ban punishing the player too little. Does anyone have any suggestions as to what system is the best to use for a PvP UMS map?

I'm leaning towards the single-player moderating ban system. For general purposes, this works. Most people have a decent sense of fair play. Also, I'm a fan of crashing other players, because there are hacks that get around defeat, aren't there? Removing all units and then crashing is probably best. The second method of crashing is probably the most effective.

Random question, if you get the defeat trigger and you hack to stay in game do triggers still effect you?

1. killing a unit is easiest, and host has final word. I used reavers to ban, so you build 1 scarab, then move it onto a beacon, and if a certain number of players also do that, player 1 is banned. It's not intuitive, but it's small and easy to trigger.

2. defeat is easiest. If they hack, they hack. Pretty sure triggers don't run for you if you are defeated, but any units created for you by another trigger will run, and you can control them. You can also give away/kill all their units, and don't bother with the defeat trigger. Spam a message for them, and center screen somewhere. They'll leave eventually, and you can squelch them if you don't like it. If you find the "I'm watching gay porn" wav, you can put that one in, and play that x63 times as well for maximum loudness.

If you like to do something special: Ban the player by un-allying him. Yay for non-physical; Nay for people not getting how it works.

Personally I find dropping people via EUDs the most convenient. There's no lag box people have to go through in order to get rid of him.
Additionally kill all his units and add an annoy trigger to piss hackers off.

Damn it.. Nude beat me to it...
I was gonna say do a team ban using unallying. It's very annoying when the host starts banning people just cuz he's a dick.
And use remove all unit for current player + desync. Too often hackers will use the hack that drops everyone from the game (along with the stay alive hack). It sucks that this particular drop hack is uncounterable (at least for the public anti hacks)...

Don't use invalid units/crash sprites as some hacks (Oblivion) have protection against them.

The system I'm using is as follows:

- Each player has 2 beacons that need to be covered in order for them to be banned.
- Players 2-7 get 1 lifted barracks they can control, player 1 gets 2 barracks. This is in an area where the barracks cannot land, and if they fly outside of the area their barracks is moved back to the centre of the banning area.
- To ban player 3, both of player 3's beacons need to be covered by barracks (force 1 brings at least 1 barracks to P3 ban top, P3 ban bottom)
- When banned, all of the players units and buildings are destroyed and defeat is triggered

In my map, if someone used the hack to avoid the defeat trigger, they still wouldn't be able to do anything as the trigger to spawn new units would never occur for them. So they'd just have to leave. This system lets P1 ban whomever they want, but other players would have to co-operate to ban someone. The banning system is disabled once someone reaches their final lap, just to prevent vindictive players banning someone who is about to win.

Admittedly this system takes up quite a bit of map space (could use civilians and a simpler terrain system to condense space of course), but seems like it is pretty intuitive (Barracks is called "Ban: 2 required to ban" and beacon is called "Cover both beacons to ban").

They have? Can't we use this in a way?

How? The protection is client side only, and should not be detected by memory conditions. AH triggers find the memory usage of a hacker and then desync them. Either way, I doubt it would be hard for zyn to patch it, (just like the last 4 sets of AH trigs).

that's when the hacker starts dropping people from the game....

also, for the system you chose, doesn't that just use a lot of locations/units? Something you could do is make each player have a ranged unit in the banning area. Give the ranged unit X5 life, and 5 damage. Where X is the number of players needed to ban a player. Heal all those units every second.
ie: [I'm gonna use X=3] So P1 attacks P7's ghost - it does 5 damage to the 15hp ghost. The ghost will keep healing and won't die. If P1 and P2 attack, it does 10 damage to the 15hp ghost, and P7 is still in the game. If P1, P2, and P3 all attack P7's ghost, the ghost will die, and oj is banned.

Post has been edited 2 time(s), last time on Feb 11 2010, 2:52 am by fat_flying_pigs.

Triggers should run for defeated players, otherwise they would desync anyway.

You can always find some to crash. ;o

I prefer desynching the player, then defeat, then crash. As an added bonus, you can do annoy after that just in case the crash failed.

Ok, in that case I may also center vision for the banned player on a sprite that will make them crash. Thanks for the heads up; although I'm not going to try super-hard to definitely drop someone from the game (doesn't seem like a big deal to me, to be honest).

In terms of units, it uses up barracks and one of the beacons with unique names. Barracks is fine in my case as I actually want players to be able to build bunkers, but not barracks, so by giving each player a barracks it allows them to build bunkers. As for locations, it uses up 2 x 7 = 14 for the beacon detection (although you could reduce this to 1 location by repeatedly centering it on the beacons and detecting if there was a barracks there), 3 for the boundaries and 1 for the ban area itself, for a total of 17 locations used. In my map this is not an issue for me.

You ghost-kills idea is nice, but I'm not sure it's really intuitive without some sort of explanation, or trial and error. You'd need to indicate that the units are healed every second otherwise someone, looking at the system, will think "I can ban someone by shooting them thrice with my ghost", then they attempt to do it and find that it fails because the unit heals.

Other problems I can see with it is that the players need to attack the unit in unison; eg if P1 attacks P3, and then P2 attacks P3 just after P2 has been healed, and P2 gets healed again before P1 cooldowns, P2 will never be banned. This could probably be fixed by using a correct heal rate, such that 2 shots from ghosts must always occur before a heal, but that requires testing an fine-tuning. Finally this doesn't work if your players are enemies of each other; you would need to keep the units segregated from each other or they will constantly be firing at each other, which could lead to accidental bans as well as distracting gun shot sounds and "we're under attack!" messages.

They'll know they are doing something wrong and are probably going to get banned.

This is probably already known, but it hasn't been mentioned in this thread.

Somehow one of the sound strings in my map got deleted (don't think I did it on purpose), but I still had a transmission referencing it. When the transmission attempted to play the sound, it crashed Starcraft with a windows error box saying something about an illegal string.

Would this be an effective crash mechanism that cheating programs would be unable to avoid? I guess a compressor/protector program would probably remove the bad string reference, so that might be an issue.

You can actually hex edit your own compression...so by deleting unused stuff, you could keep the bad .wav stuffs, and still make it smaller. And yeah, it was alluded to already, in the OP:

Quote from name:doomedrusher

-Trigger which crashes the game for that player, e.g. play WAV: ".", giving vision of an invalid unit and centering view on it