whats the config ur using?? its perm if u dont specify it
Yeah! and its not working ive done some testing that should be clear its a obvious alt account same email, ip, hwid, etc and the alt account has not been banned at all
After testing this out with a friend, it’s practically useless. I had him test out 8 alts, only two of them were detected. This was on the same PC, same Roblox client, same HWID, same IP. No spoofers or account managers or anything. Nothing was changed, he simply logged out of one account and logged in with another.
Meanwhile a simple lua alt detector I wrote caught all 8 of them…
My theory on how it works is that it operates similar to how they track for ban waves. It takes a bit of pattern usage before it links alts together. The only alts detected were those that were regularly logged into, while the ones that don’t get frequently used went completely undetected despite being on the same PC. Which is completely useless when most troll alts sit in cold-storage until they’re needed. I imagine it’s completely simple to bypass given it doesn’t even work when we’re not even trying to bypass it…
I had him create a fresh alt and join immidiately after… the alt made it in completely undetected. It’s clear that this system requires heavy habitual use of the alt accounts before they get picked up.
These ‘anti-cheat’ measures are rather ineffective sadly. Banwaves for 1-day, alt-account detection that doesn’t work, usermode anti-tamper that gets bypassed by free cheats. While it’s a nice sentiment it’s all just rather toothless.
it uses seconds, anything under 60 seconds will default it to 1 minutes
This is also something I take issue with, particularly since it just doesn’t reflect who’s actually banning the player in lots of cases (moderators/staff of the game do, not necessarily the developers).
rest in peace the bullyfacemen
Oh that makes sense, I didn’t think it would round the number to minutes haha
Actually I’ve been putting duration that rounds up to 1 minute which is why it was displaying 1 minute lol, my bad
What about the people who have multiple accounts for developing etc???
Why would this update negatively affect you if you have alts for developing, as long as you don’t get your account banned on some games nothing will happen to your alts.
This looks like code generated by ChatGPT lol
That’s really interesting. Does this prevent previously banned players from making an account and tying it to their same email? Can alt accounts be falsely detected, and are they still allowed for game testing?
ohh okay i tought it will ban all the alts you have.
Why? They could just tell us the alt accounts that played the game already, so we know e.g when we saved some moderation data about them, that we can save the same to this person.
time to use hookmetamethod, packet spoofing and hwid spoofers
This is an API that was needed, We’ve been waiting long enough for alt detection.
oh my god this is HUGE!
i’ve been looking into workarounds for alt detection systems, better banning, etc. but this facilitates the process so much.
thank you for finally adding this much-needed api
I wonder how that would fare against data and privacy regulations.
Update is great to see, but I’m beyond disappointed with the botched OpenCloud implementation & documentation.
To start with my complaints for the documentation:
- startTime & inherited are shown as “Output Only”, despite that in the “Update User Restriction” call example it is shown that they are included in the request. So, are they included, or are they not?
- The idempotencyKey is shown in the “Update User Restriction” call, but no example is actually provided to explain where/how to generate these values. It shouldn’t require additional research on Google to attempt to guess what these values are.
- Zero real explanation of the path field, calling it a “resource path” does not mean anything, nor explain why you’re allegedly able to update it in the “Update User Restriction” call given it’s marked as Output Only – I suppose that it can be used to change a ban from universe to place or vice versa, but why not explain this?
- What actually is the user-restriction field? Is it a user ID? The comment states it’s a “user-restriction ID”, doesn’t tell you much does it…
- Are the query parameters for the “Update User Restriction” optional? If they are, this should be marked as such, and if they’re not optional, that should be changed!
For my complaints with the implementation:
- Apparently somehow missing a create user restriction call…
- How did anybody think it reasonable that you cannot actually create a ban via the API, or is it instead the case that PATCH is somehow capable of this?
- The server consistently returns 500 internal server error on that patch call instead of actually providing you a human readable explanation for how your input is malformed. If you’ve got a public facing API, it needs to validate the inputs & inform the user of the API where they are going wrong, not just leave them guessing
- Why is the user referred to as “users/156” rather than just returning their user ID?
OpenCloud ought not to be treated as an afterthought that is fine to have missing features. Frustrating.