Loading...
  OR  Zero-K Name:    Password:   

Suggestion: delay before units are returned to AFK players

36 posts, 768 views
Post comment
Filter:    Player:  
Page of 2 (36 records)
sort
I'd like a delay before players returning from AFK status receive their units back. Often I'm actually using "their" units in combat, them coming back makes these units die since I lose control over them in a dangerous situation.

Something like a minute or two would be enough.

Additionally, all units/buildings that were finished while the player was AFK (despite the AFK player starting the construction) should remain under my control. It makes no sense to lose control of a unit I spent more metal on than the AFK player.
+2 / -3
24 days ago
Plus maybe, just maybe would discourage people to afk. Maybe delay could grow if you go afk multiple times in 5he same game...
+0 / -1
24 days ago
http://zero-k.info/Forum/Thread/31388?page=1

This was talked about 2 years ago. Now we have a red ball.
+1 / -0

23 days ago
I see what you guys are saying, but there are definitely times, and maybe even most of the time, when people don't go AFK on purpose. Even though that goes against the whole meaning of AFK, I have gone AFK multiple times, and every time it's because either my game crashed or my computer crashed, I would already be annoyed for having to reboot my game and even more annoyed if I had to reboot my computer (cause believe me that's a lot of work), and if I came back into the game and had to wait another 2 minutes to get my stuff back, I would just be more annoyed.
Annoyed people don't make the environment better either.

Perhaps there is a way to detect if the person's game was actually closed or just left open. Even then though, you would still run into some problems.
+1 / -0
23 days ago
I guess crash is not the AFK we were talking about. If you want that in case of quit and rejoin the 2 minute delay does not apply sounds reasonable and probably not hard to do (rejoining players show that they are behind simulation).

Also try to think from the others perspective as well: there is one player annoyed that got your units, and probably rest of the team annoyed they are one less team mate - so letting people AFK without any downside is not ideal either. Most of people playing seem to be able to not go AFK, so it is feasible.

Isn't the current AFK system (the kind of there is someone at the door) also kicking in after some time of inactivity as well? This already gives some slack for urgent things.
+2 / -0
Review the common reasons why people go afk during gameplay:
- Crash
- Lag (Cannot keep up with sim / network slowdown / etc)
- Low amount of things that need attention (IE: Building big thing in rear): Non-engagement (Common when building large things or having few units)
- Life Happening: Door, phone, baby, emergencies, biological needs, etc.
- Pregame caching / long loads.
- Running to get food/drink/bathroom/etc during pre-game, expecting to return before game starts.

Out of all the above, I see zero reason to punish anyone for these events. A delay before units are given back is just wrong because all that will do is encourage further afk / frustration (See reason 3), especially when the suggestion is "a minute or two". This defeats the purpose of the solution by reintroducing the problem. Nobody is going to wait a minute or two to reengage with the game, instead you're going to see more quits, which is even worse than AFK -> returning because it is a permanent reduction in team attention capacity and risks collapse of that lobby. Given one room culture, this can lead people to actually quit the game for the day, which is terrible for engagement. I do not see this being remotely healthy for the community or the game in the run long in any form.

The only acceptable part of this suggestion is the "track metal input into a unit to determine ownership", but even then this risks perf issues because of the nature of AllowBuildStep. You could, perhaps, track afk nanoframes at ~1-2hz to reduce the perf cost and I'm sure that might get approved since they'll probably be few and far between.
+1 / -1
20 days ago
The arguments are given without metrics, which makes it look like the conclusion is stronger:
  • 3 out of the list (crash, lag, caching) should not be included separately as they are basically one, and previous message already suggested not to include lag in the method
  • "life happening" assumes somehow that it's normal to play only one game mode. I think if you have often events like that, other modes are more appropriate than 10x10 team game.
  • "low amount of things that need attention" that's very subjective and I find it counterproductive. It's like saying "sometimes you win the game when resigning because team fights for you" - I prefer to play with people that actually play.
  • "running ... during pre-game" is reasonable, but think can be easily fix (by starting this after 5 minutes, making delay larger as times goes by, etc.)

quote:
Nobody is going to wait a minute or two to reengage with the game,
I would find it only fair. I doubt I am the only one, so saying "nobody" seems exaggerated.

This is mostly a problem for well rated player (which I end not being very often), but couple of times that it did happen to me, was very annoying. Especially the "unit return" part, as mentioned.

In some games I have seen people asking nicely "can we pause have something to do". If it happens once/twice per game, people are fine with it. Even otherwise saying "sorry for afk" would go a long way to reduce annoyance and the feeling that AFK player are thinking "why should I care I play with 20 other people they are there for me to make big robot and suicide it in 2 minutes." (or variations)
+2 / -1
USrankShaman why am I being punished for someone else going AFK?

Fact is that the reason for going AFK is irrelevant to the outcome, be it a crash or malice. Result is the same and the result is what I want to change, I am given no warning that I am about to lose control of units I'm controlling. I don't care how punished the AFK people are.

It's also extremely dishonest to even argue about "crashes" as those are so extremely rare, even if they do happen then players stand practically no chance of reconnecting into a longer game as their hardware will never permit them to catch up.

I'm 99.9% of the time the highest ranking player in a team game, I don't even remember the last time I didn't receive someone elses base in a game. If this is not addressed then I will start gifting these units to random people on the team, most likely the lowest ranked ones, until people that lack empathy can understand how annoying this is. Perhaps this can be even automated.

There's little more tilting than having an AFKer/leaver and being simultaneously spammed with unit shared messages/beeping, while not even being able to retain control or do anything about it. Allow me to opt out, mitigate the penalty for me or I will opt out in my own way.

Perhaps something like this?
local function GiveUnit(unitID,newTeamID)
	local oldSelectedUnits = Spring.GetSelectedUnits()
	Spring.SelectUnitArray({unitID})
	Spring.ShareResources(newTeamID,"units")
	Spring.SelectUnitArray(oldSelectedUnits)
end

function widget:UnitGiven(unitID, unitDefID, unitTeamID, oldTeamID)
	if Spring.ValidUnitID(unitID) and unitTeamID == Spring.GetMyTeamID() then
		if Spring.AreTeamsAllied(unitTeamID, oldTeamID) then
			GiveUnit(unitID,oldTeamID)
		end
	end
end
+3 / -1
quote:
I think if you have often events like that, other modes are more appropriate than 10x10 team game.

There are better ways to do this than to tell people to go play a different game because they have a life.

quote:
This is mostly a problem for well rated player (which I end not being very often), but couple of times that it did happen to me, was very annoying. Especially the "unit return" part, as mentioned.

I am not a very "well rated player", and this happens to me more than you would think, and I don't think it's bad (other than the fact that someone left); I don't get annoyed at it. You are getting free units, and free stuff, and when it's gone, you aren't worse off then you were before, you could even be better off, so why get annoyed? And if their units die in a battle cause they just got back and you aren't controlling them anymore (as TinySpider said), so what? it's their units now! Getting your units destroyed mid-battle should be punishment enough for going AFK.

quote:
USrankShaman why am I being punished for someone else going AFK?

You're not, unless you're punishing yourself by getting annoyed.

quote:
I don't care how punished the AFK people are.

...
you should care

quote:
It's also extremely dishonest to even argue about "crashes" as those are so extremely rare, even if they do happen then players stand practically no chance of reconnecting into a longer game as their hardware will never permit them to catch up.

This sounds like it would be true, but it absolutely is NOT true. Take me for an example. I have some amazing hardware and my computer crashes way more often than you'd think it would. Why? Because my computer is set up in a very complicated way so that 4 people can play on it at once, and it also runs several servers at the same time. It's running them all on Virtual machines, so since it's much more complicated than a normal PC, it crashes a lot more than it should because it's weird in the way it's set up.
Yes I do have a rare setup that probably no one else has, but a lot of my friends' games crash sometimes and they can still catch up.

quote:
If this is not addressed then I will start gifting these units to random people on the team, most likely the lowest ranked ones, until people that lack empathy can understand how annoying this is.

That's fine with me lol, I like free stuff.

You purple players should be able to control many things at once (unlike me), so it shouldn't be a huge problem.

quote:
mitigate the penalty for me or I will opt out in my own way.

I don't think anyone is going to do anything when you demand things like that. You're only really caring about yourself.

Another way of saying what USrankShaman was saying:

Let me get this straight.
The Problem: People are temporarily leaving the game for various reasons, and you'd rather them stay and not leave.
Your Solution: Make them leave for longer.
+1 / -1
quote:
Your Solution: Make them leave for longer.

I want them to be annoyed instead of me, since this problem is caused by the AFK players, not me. I would rather a player leave the match for good instead of going AFK multiple times during it.

If the AFK player cannot suffer 1 minute longer after returning from AFK, then they shouldn't have left their computer.
+1 / -1
Read all of the above.

Another note:
You can't stop people from going AFK. It's going to happen, no matter what you do. That's just how life works. You can reduce it, but I don't think that any of these things will reduce the problem at all. I am saying that I think there is already enough punishment. If someone goes AFK, whoever gets their units could very well be 1) getting them destroyed when AFK player returns, and 2) altering the entire game for that player, who knows you could have ruined some of their plans.

I would argue that quite a bit, like maybe 40% of the times people go AFK, they are going AFK for a good reason. People's games can crash whether they have good hardware or not. I don't think people should have to decide between their life and the game, they should be able to keep on living and also have some fun playing ZK. It's no fun when you have to wait a whole minute or two to rejoin the game because the mailman just dropped a computer part off at the top of your long driveway and it was raining.

There will always be people who go AFK for a bad reason as well, but that's because you can't know; there's no way of knowing the true reason why someone went AFK, so there is no way to know who to punish, who to annoy.
+1 / -0


20 days ago
Share the afk-given units away and they're not your problem; write a widget to do that automatically on receipt, and they're never your problem.

If noone wants them, i guess they just stay afk.
+1 / -0
omg. stop being lame and offer solution than winge, ie,

when player is back join units into groups of epsylon,


for all units in epsylon of unit:
if groupid(unit)==null and distance(unit,unit[n]) < epsilon
then
....if groupid(unit[n])==null
....then
........group(unit, next_free_groupid())
....else
........if groupid(unit) == null
........then
............group(unit, groupid(unit[n]) )
........else
............merge_group_ids(groupid(unit),groupid(unit[n]))


and if there are more than epsylon2 enemy in area of epsylon3 of average centre of group, then paint a massive fucking arrow on centre of the screen in the direction of group centre. and auto ctrl group that group.

also put a message that there are X groups in auto ctrl-1-9 nearby enemys.

done.


about finishing starating buildings there already blocks that put units on wait orders when given to you, so if you built them that was on you.
+0 / -0
I am not sure how the suggestion solves the stated problem. If you don't notice the player return then the unexpected loss of your units is still sudden, the suggestion has just delayed it. Something that makes the receiving player aware that the AFK player has returned (such as a giant popup) sounds even more annoying than the units being shared back unexpectedly. Also if there is a one minute warning on returning units, are you likely to retreat for a smooth handover or just fight harder to try to take your objective in time?

Some minimum share time sounds ok as quickly being given units only to have them taken back is annoying, and this quick case is likely to occur for people who are idle rather than crashed. Perhaps something dynamic would be smart, like a timer that is reset per-unit when it is given an order, to deal with units being shared back when they are being actively used.

Sharing units under construction is a tricky one. I recall making all constructors wait when shared, so that you don't accidentally spend resources on something the other player started. This seems to have resolved a lot of the complaints. If you deliberately finish something then there is the understanding it will share back. The alternative is people complaining about someone else taking their 99% Dante. Something that tracks how much each player contributed could be a better solution, but someone would have to add it. Projects the receiving player starts with shared units are not transferred back to the returning player.

I think this is all fiddling around the edges when the main problems with AFK could be solved. For starters, perhaps the receiving player should be the "closest" player (perhaps by average unit position, weighted by metal?) so that people are unlikely to receive units on a front that they have no context for. There could be some minimum rating, or rating weight, as well.

A quick button to opt-out or send the units to the next eligible player seems good too.
+4 / -0

19 days ago
A short countdown for both owner and "caretaker" of the units would be ideal IMO. (Potentially in all cases of unit transfer.)

I had a situation once where some guy in my region was using a scorp and a firewalker, then went AFK, unknown to me. These went to a purple/blue who used them a bit, but then that player suddenly offloaded them to me. A minute later I decided to use the scorp to go sniff around a crab that had just presented itself. Just as the scorp was headed for this engagement, the owner returned, and the scorp walked in a straight line to its death.
+0 / -0
AUrankAdminGoogleFrog I think the worst part of all this is the huge notification spam when it happens. I don't need a separate ping, marker and chat line for every single unit received when a player goes AFK. It helps when it's a purposeful gift during a game like transferring a widow to EMP an antinuke, but it doesn't help when it's notifying about literally a whole player worth of units.


To better understand my perspective:

I cannot play with the assumption that the AFK player is coming back, as that just puts my team at a disadvantage since I am effectively throwing away all the metal invested into half-built units. When I receive a base this way, I quickly go over the area and set all redundant factories/caretakers to be reclaimed, all storages to be reclaimed and finish any larger projects that could benefit the team, like a strider.

quote:
A minute later I decided to use the scorp to go sniff around a crab that had just presented itself. Just as the scorp was headed for this engagement, the owner returned, and the scorp walked in a straight line to its death.

Unsafe units like these could use with a tiny "flag" marker next to their health bar, like a rank icon just for marking them as potentially unreliable ownership.
+1 / -0
19 days ago
my suggestion is to display a massive arrow in direction where units are in the heat of battle, to the RETURNINGPLAYER, not current owner. altho loss is sudden the returing playergets notified on the get go whereis what so it solves the problem of unit loss or uncotntrolled in thick of it all.

thats how i see it
+0 / -0
19 days ago
quote:
I think this is all fiddling around the edges when the main problems with AFK could be solved.
At which point do you think going AFK is against "Respect Other People"? I understand if it happens once. Twice maybe, but should be rare. But sometimes there are people that go AFK regularly and game after game.

As it was mentioned in the thread, if the receiver does not "use the units" that looks like not trying to win the game which is frowned upon as well, but can results in losses like in the scorpion story above...
+0 / -1
quote:
"low amount of things that need attention" that's very subjective and I find it counterproductive. It's like saying "sometimes you win the game when resigning because team fights for you" - I prefer to play with people that actually play.


If you have only a handful of units and none of them require attention, you're naturally going to sit back and not move the mouse -> "afk." This is not subjective, this is an observable behavior.


The solution to this behavior is to have a hud popup with a warning after X time saying "Warning: You're about to be marked as AFK. Move your mouse to keep your units" and extend the afk timer to account for this grace period. Add an audio alert to this, and you're good to go. This does not make all afk go away, but reduces the assumption of low engagement afk.

quote:
Some minimum share time sounds ok as quickly being given units only to have them taken back is annoying, and this quick case is likely to occur for people who are idle rather than crashed. Perhaps something dynamic would be smart, like a timer that is reset per-unit when it is given an order, to deal with units being shared back when they are being actively used.


I'd like to express concern about this: this sounds like a temptation to spam chat with "Pls give me my dante back" / label spam. This sounds like a frustration excuse for everyone involved: New guy gets his shiny unit stolen because of the above, "pro" loses "their" unit they were using when they stop ordering it around. Honestly, it is tempting to implement a solution, but consider the greater social impacts. This could lead to anti-social behavior, frustration, and lowered engagement. It can also lead to technical circumvention (IE: Anti-AFK widgets) and produce worse effects than what we have currently.

I'd recommend a better solution:
- Give away only actionable units (IE: no mexes, eco, turrets). If you do not expect the user to interact with it, do not give it away.
- Track the amount of stuff given to one user, if it exceeds some threshold, give it to the next best player. Alternatively, perhaps add a command that takes units in a circle and don't give away automatically? Perhaps the player color could change during afk to some standard color like black / white and any player can use the take cmd to gain control of those units. It could be hotkeyable and added to the global command bar. This command would automatically select the unit for the user using the command.
+2 / -0
Nevermind, useless.
+0 / -0
Page of 2 (36 records)