Auto-booting afk players

[ShadowTek]

I recently found out that my current method of booting inactive players was buggy. (After a little testing I found that active players were sometimes getting booted and that inactive players could still remain in the game.) So I did a forum search and found this:
http://www.thehelper.net/forums/showthread.php?t=18129&highlight=inactive+players

All the methods that were discussed in this thread were basically similar to what I have been using. They all rely heavily on idea that using the events "Unit - A unit is issued an order..." to set a variable for the owner of that unit as a means of keeping track of player activity. There are several problems that I have discovered with relying on these events.

First, the event where "a unit is issued an order..." seems to be regularly triggered by events that do not involve player input. I tested this by having special effects occur at the positions of the triggering units so that I could see exactly which units where being "given orders". Then I had the name of the owner of the triggering unit be displayed. I also had the camera to pan instantly to any triggering unit. The following setup is what I was using to test with:

Record Actions
    Events
        Unit - A unit owned by Player 1 (Red) Is issued an order targeting an object
        Unit - A unit owned by Player 2 (Blue) Is issued an order targeting an object
        Unit - A unit owned by Player 3 (Teal) Is issued an order targeting an object
        Unit - A unit owned by Player 4 (Purple) Is issued an order targeting an object
        Unit - A unit owned by Player 5 (Yellow) Is issued an order targeting an object
        Unit - A unit owned by Player 6 (Orange) Is issued an order targeting an object
        Unit - A unit owned by Player 7 (Green) Is issued an order targeting an object
        Unit - A unit owned by Player 8 (Pink) Is issued an order targeting an object
        Unit - A unit owned by Player 9 (Gray) Is issued an order targeting an object
        Unit - A unit owned by Player 10 (Light Blue) Is issued an order targeting an object
        Unit - A unit owned by Player 12 (Brown) Is issued an order targeting an object
        Unit - A unit owned by Player 1 (Red) Is issued an order targeting a point
        Unit - A unit owned by Player 2 (Blue) Is issued an order targeting a point
        Unit - A unit owned by Player 3 (Teal) Is issued an order targeting a point
        Unit - A unit owned by Player 4 (Purple) Is issued an order targeting a point
        Unit - A unit owned by Player 5 (Yellow) Is issued an order targeting a point
        Unit - A unit owned by Player 6 (Orange) Is issued an order targeting a point
        Unit - A unit owned by Player 7 (Green) Is issued an order targeting a point
        Unit - A unit owned by Player 8 (Pink) Is issued an order targeting a point
        Unit - A unit owned by Player 9 (Gray) Is issued an order targeting a point
        Unit - A unit owned by Player 10 (Light Blue) Is issued an order targeting a point
        Unit - A unit owned by Player 12 (Brown) Is issued an order targeting a point
        Unit - A unit owned by Player 1 (Red) Is issued an order with no target
        Unit - A unit owned by Player 2 (Blue) Is issued an order with no target
        Unit - A unit owned by Player 3 (Teal) Is issued an order with no target
        Unit - A unit owned by Player 4 (Purple) Is issued an order with no target
        Unit - A unit owned by Player 5 (Yellow) Is issued an order with no target
        Unit - A unit owned by Player 6 (Orange) Is issued an order with no target
        Unit - A unit owned by Player 7 (Green) Is issued an order with no target
        Unit - A unit owned by Player 8 (Pink) Is issued an order with no target
        Unit - A unit owned by Player 9 (Gray) Is issued an order with no target
        Unit - A unit owned by Player 10 (Light Blue) Is issued an order with no target
        Unit - A unit owned by Player 12 (Brown) Is issued an order with no target
    Conditions
    Actions
        Set ActivityCount[(Player number of (Triggering player))] = (ActivityCount[(Player number of (Triggering player))] + 1)
        Game - Display to (All players) for 1.00 seconds the text: (Name of (Owner of (Triggering unit)))
        Player Group - Pick every player in (All players) and do (Actions)
            Loop - Actions
                Camera - Pan camera for (Picked player) to (Position of (Triggering unit)) over 0.00 seconds
        Special Effect - Create a special effect attached to the overhead of (Triggering unit) using Abilities\Spells\Other\TalkToMe\TalkToMe.mdl

I found that units owned by absent players were regularly "given orders". The units would display the special effects (and have the camera brought to them) any time I brought one of my units close enough to their units to cause those units to attack me. It also seemed that the "return to guard position" order also triggered one of these events.

This means that there are many times where units are being "given orders" when there is no player input involved. So using these events to track player input is useless, since "credit" is given even when the owning player is absent from the game! (There are no AI scripts in this map btw)


The second major problem that I ran into with these events is that players who use shared units are not recognized as being "active players". If the owner of the triggering unit is always given the credit for any orders that are given to the unit, then any players who are using another player's units to play the game will run the risk of getting booted if they don't (or can't) use units under their control.


It would seem that the only reliable way of booting inactive players is to only use player selection/deselection events to track activity. The only potential problem that I can foresee with this idea is that it would actually be possible for a player actively participate in a game for an extended period of time without actually "selecting" units. A single group of units could be repeatedly ordered to move and attack targets, such as in a hero type map.

It sure would be nice if you could use that in combination with a "unit is given order..." command, but...


So can anyone think of a better method of reliably auto-booting inactive players? I was thinking of forgetting the whole idea and just using a vote-kicking system, but what do you do about a situation where there are only 2 people left and one of them is afk? Isn't it a generally bad idea to allow a minority percentage vote to succeed in booting other players?

 

[Hikaru7]

But why auto boot in the first place? I find that its not nice. I mean, not everyone can sit on the computer all the time and just play warcraft, what if something is burning and the player has to go afk? Then they come back and its like oh, jerks, I got booted >.>

EDIT: Oh and another way you could do it is too, check if players have recently typed in any chat commands. And if players haven't done anything for 5 minutes or given an order, start a countdown timer, specific to the player, then keep checking to see if anything was done while the timer is running to see if you need to cancel the timer.

 

[ShadowTek]

The map in question requires intense team-work to combat the enemy. If a player (or god forbid, more than one) just sits in the base for the whole game and does nothing, then gameplay if affected. If a player dies (or gets booted) then certain measures of compensation of given to that player's team-mates in order to give them a better chance at survival. An afk player is a dead player from a gameplay perspective, and the proper compensations need to be made so that the game isn't ruined for the other players.

The impact of an afk player will, of course, depend on the type of map that you are referring to. If it is a TD, in which the absent player will simply screw himself out of an income by not playing, then it isn't a big deal since other players can pick up the slack, get that player's "share" of the gold, and continue to play the game with a realistic chance at winning.

I believe that the interval of the boot-check also plays a part in fairness. I have been using a 15 minute interval with my triggers, and I feel that this is a fair amount of time to give someone. 15 minutes is plenty of time fix yourself a snack, go answer the door, or even take a leisurely dump if the need suddenly hits.

And if you have such a recurrent problem with fires in your home that your online gaming is frequently interrupted, then I suggest you turn off your computer RIGHT NOW and figure out what the cause of that problem is. lol

Edit: yeah thanks, I'll add that too.

 

[emootootoo]

Maybe use

Player - Player 1 (Red) Selects a unit

 

[ShadowTek]

Thank you for your reply, but that is exactly what I was referring to when I said:

Spoiler

It would seem that the only reliable way of booting inactive players is to only use player selection/deselection events to track activity. The only potential problem that I can foresee with this idea is that it would actually be possible for a player actively participate in a game for an extended period of time without actually "selecting" units. A single group of units could be repeatedly ordered to move and attack targets, such as in a hero type map.

It sure would be nice if you could use that in combination with a "unit is given order..." command, but...

I have decided to use the player selection/deselection events in addition to 'player enters <empty> chat string' to attempt to track player activity.

It is possible that a player will actively use a single group of units, without selecting any other units, while never entering a single chat string over the course of a 15 minute period. This is the event that I wish to avoid.

Any more suggestions are appreciated.