Every round we see fams struggling with inactives at sor, which can’t be removed for 48h.
A solution to this could be a check-in 24h before sor. Players that did not checked in the 24h leading up to sor will get removed at round start.
Love it!
^ updated detail. I really like the 8-hr “last chance” bit for replacements.
So this means the check would actually start 32 hrs before round starts, with 24 hours from then to keep your spot.
1 Like
this is TOP!!! gj!!! you realized exactly what i said i am so proud of you!!!
Could you add a feature to that checkin? When you checkin, leader (if chosen) gets automated message of it, with the infra you have prebuilt.
bump
12 Votes … Bumpedy Bump.
best idea in the forums tbh
I’ve added Remove inactive players 8-hours before SoR to #roadmap:to-do.
It is slightly different than the original idea here, in that we don’t need a separate “check in” action, but the effect should be (mostly) the same.
We shouldn’t require additional actions to avoid getting deleted, as that would create a higher barrier of entry than already exists. Logging in is good enough.
I’m re-opening this one, per @The_LiGhTgUnS’s feedback.
If an inactive check based on login is sufficient for you, you can safely remove/reclaim your vote here as that will happen via Remove inactive players 8-hours before SoR.
If that isn’t enough and you want to require players to do a manual check-in on top of logging in, that’s what this thread is for.
For now, I don’t agree that an additional check is needed, and don’t plan to implement it. I am open to hearing more though.
So we have 13 votes, and you disagree. Does it make sense for me to keep my vote here or can we just remove the votes and forget about?
Or is it something you might reconsider when we reach 20 votes for example?
Being in the fam playing with 5 people untill expo phase ended i say this is needed!
None of these solutions actually fix the problem - they just make it easier to fix the symptoms.
Why are players creating accounts, joining a galaxy, but never playing? That’s the problem I’d like to fix… and I don’t believe that any of these solutions resolve these.
Giving leaders more power to just remove players sounds like something that will just be abused.
2 Likes
@Hala what this idea needs for reconsideration is discussion and specifics. More votes alone won’t make much of a difference.
The question for me is why the similar feature being planned is not sufficient.
Players can either answer that question, or use their votes elsewhere.
Having multiple topics and different discussions for the same problem isn’t making this easier…
Central issue:
Inactives at sor have a big impact and ruin your chance to win. This needs a solution.
I think everyone agrees on this.
Generic idea / solution
Inactives need to be removed a little before sor so the fam can fill and start with a full active fam.
A cross the topics I think this idea has around 17 votes.
Implementation
Here you get the discussion going. How to check for removal and when to remove?
- Automatic check and removal as @I_like_pie wants to do imho has 2 major issues.
- There are a few situations an active player doesn’t need to do anything till sor. This active player will get removed.
- An active player could be offline for first 5 ticks due to vacation and the fam wants to keep him and he still gets removed
- Imho bor there should always be confirmation by the leader that he agrees to the conclusion of the removal script. Or better. Give a leader the option to cancel the removal. Make a yellow blinking banner for leader stating: The following players are inactive: @I_like_pie, @I_like_pie and @I_like_pie If you do nothing they will be removed in 24h. 23h, 22h.
Side question:
Why do people go inactive in the first place? My guess:
- Multi account to market aid (fixed with 48 delay)
- Multi account to delay other fams (fixed with multi checks)
- Bor takes too long
- Real life issues (can’t fix this)
It’s a tradeoff, it’s making it much easier for me to manage actual code changes. These are technically 2 different solutions, so they need 2 different places on the roadmap to evaluate and track, or in this case: reject.
Regardless, thanks for your explanation. 
This is helpful.
Regarding the unwanted removals, this is solved by an additional check that the player must also be marked inactive. This gives the confirmation you describe, as the script can’t do anything until the leader marks a player as eligible for deletion. This change has made it into the other feature’s thread.
As far as I can tell, that solves the problem entirely in a way that doesn’t need a literal manual checkin as described in this thread here.
4 Likes
Agreed. Looking forward to this!