Already been suggested m8 (With a small difference, yet the end result is the same)
It's highly exploitable doing this as in reroll indefinitely untill desired winner will get game
Comment has been collapsed.
How can it be exploited if the automatic re-roll occurs only if the currently-selected winner is not a member of the group?
Comment has been collapsed.
Comment has been collapsed.
OK, what if the auto re-roll could only occur once per giveaway and any subsequent request would be escalated to support for manual review? And tracking was added to identify users or groups which are frequently involved in re-rolls?
I think we can all agree that any type of automation is going to be better than the current system where support is hopelessly overwhelmed with the sheer volume of tickets.
Comment has been collapsed.
How often is this type of reroll request encountered? I'd guess there are very few of this nature.
Comment has been collapsed.
Fair point. There's no way of knowing that information until someone from the support/admin side posts some data. If they did - even just Category/Reason/Ticket Count - I'm sure many of us would volunteer to write scripts to help address the highest offenders.
Comment has been collapsed.
Those re-rolls are only approved if we are provided screenshot proof from the group history page that the winner left/was kicked before the giveaway ended. SteamGifts cannot see that information automatically.
Now, if the winner's last sync time was before the giveaway ended and they were no longer a part of that group, it could work for those cases. However, sync is notoriously unreliable, one of the most common errors occurring is not syncing any groups. So it would automatically re-roll just because the user had a bad sync. Bad idea.
Comment has been collapsed.
Even though it makes more work and takes time for the member that goes through the re-rolls and approves them.
I personally would rather have an actual person doing it, rather than some code and script making the decision.
Comment has been collapsed.
I appreciate the reply, bobofatt. It's good to get the perspective from someone on the admin/support side.
It's interesting that you require screenshot proof when the re-roll request form makes no mention of this requirement. The group history page is typically only made available to group admins and not its members so this is not readily-available information.
I am under the impression that group membership data is public even to non-members. Is that correct? If so, it would seem to me that the sync concerns could be avoided by having a script check live group membership at the time the re-roll request is created here on SG.
Comment has been collapsed.
As bobo said, it's not about whether the winner is a member of the group now, but if he was when the giveaway ended. If you kick a user from the group after he won, then ask for a re-roll, it will not be accepted.
Comment has been collapsed.
6 Comments - Last post 2 minutes ago by Peiperissimus
9 Comments - Last post 11 minutes ago by OneManArmyStar
1 Comments - Last post 49 minutes ago by InSpec
1 Comments - Last post 1 hour ago by pb1
941 Comments - Last post 1 hour ago by InSpec
1,170 Comments - Last post 1 hour ago by Formidolosus
293 Comments - Last post 2 hours ago by Creative1989
143 Comments - Last post 29 seconds ago by OilAce
38 Comments - Last post 8 minutes ago by ColdOut
1,564 Comments - Last post 24 minutes ago by Sumnium
10,104 Comments - Last post 27 minutes ago by CurryKingWurst
27 Comments - Last post 42 minutes ago by Ignition365
1,978 Comments - Last post 43 minutes ago by MeguminShiro
115 Comments - Last post 43 minutes ago by PunishedStig
Is there any case where support would NOT approve a re-roll request in the specific case where the winner of a group giveaway left the group after the giveaway was created? I can't think of any reason why such a request would not be approved.
Ideally, when this type of re-roll is requested, an automated script would check if the winner is a member of any group(s) specified in the giveaway. Depending on the result of this check, a re-roll would then occur automatically or the ticket would be manually reviewed by a support member as is the case now.
Comment has been collapsed.