You can’t report someone anyway if they quickly leave after their act, once they’ve left they’re gone from the options of who to report, this bandaid of a fix isn’t even put where it should.
3 Likes
This doesn’t fix any form of exploiting at all. This just opens the door for our games to be exploited now, by allowing players to intentionally stall a teleport for up to 5 minutes even though the server, which should be the ultimate authority, is expecting the user to be transported to a new place ASAP.
This would absolutely not be an acceptable solution. My game uses matchmaking to put players into 4v4 matches, and all players need to be present before the game can start. It makes zero sense for this entire process to be stalled or errored just because someone is in the Roblox menu, maybe just doing something like changing their volume or looking at the player list. This will create a massive waste of time for so many players. Just revert this change.
If there’s a problem with Roblox’s report menus not working correctly through teleports, then fix the report menus themselves, don’t disrupt all developers with such an unnecessary change.
25 Likes
I think this update is solving a problem that shouldn’t need to exist.
Given they have a Universal App now, the Escape menu should be completely detached from the game instance, that way things like teleporting, or being kicked, won’t impact actions like reporting…
6 Likes
not okay, you basically broke teleport for everyone
TeleportService is annoyingly slow from what i noticed and a lot of times i would go to a different window to do something else while waiting to be Teleported and sometimes i have to hit escape to do that in first person camera mode
this will cause so many issues, i don’t understand how this change was considered and why it is implemented, seems like you are intentionally adding nuisances
Please for the love of builder man stop making changes without asking for feedback first
4 Likes
Hi developers,
We have reverted this change per your feedback and will explore less disruptive ways to patch this exploit. Appreciate you bearing with our mistake.
Thanks,
Seranok
97 Likes
Really? I thought teleporting would be sort of akin to a kick, where the server will always forcefully disconnect the user.
So you’re fixing this, but somehow you’re fine with the kick/disconnect screen covering up everything by design, resulting in users being unable to report any abuse in-game?
1 Like
How would this effect games which teleport players when their servers are shutting down?
Would one player stop the teleportation of a group of players?
Does this yield the server? TeleportAsync is a yielding function…
2 Likes
on-site reports do not make screenshots or have chat history including many other things
That would really depend on whether Roblox has added a timeout on their end, and how the developer chooses to handle teleport failures. Fundamentally, teleports are requests; the developer is asking the client to connect to this new server. The attack vector then, has always been theoretically open, for the client to sit on these requests, or to report back fictitious errors for means of declining.
If Roblox wanted to guarantee teleports, they could spawn a player within the new server, regardless of whether or not the client actually chooses to connect to it. But I think that the less destructive solution, would probably be to simply encourage developers to implement timeout logic, in cases where it might be beneficial.
2 Likes
What does that mean? The client still has a say in whether it actually chooses to connect to the server, deep down in the networking code.
I think the correct solution to guarantee teleports is to close the connection to the client upon attempting to teleport after a set amount of time, meaning that exploiters can neither stay in-game nor hold up anybody else since their client only has two options: accept the disconnect and close, or just connect to the server.
I suppose the closest Lua equivalent to the above would be a Player:Kick if teleporting works as you say it does.
1 Like
Admittedly I brought this up, mostly nonseriously, in order to point out the absurdity of expecting teleports to be guaranteed. The ‘solution’ here, would be to generate a player, purely for API purposes, so that developers could pretend as though teleport errors didn’t exist, and the game would technically continue to function, regardless of whether or not anyone actually showed up.
What you’re describing as the correct solution for your usecase, is a timeout, to which I most certainly agree. If the intent is to either teleport the player, or get them out of the lobby, then that’s really ideal. However matters could get a bit more nuanced; namely for games which rely on some strict count of players. What are developers to do in these cases, when the timer runs down, and someone doesn’t show up? Send everyone back, so that this bad actor can stall again? Arguably, these cases were always problematic, as a player would be in their right to leave on arrival anyway (as, if the game-mode relied on all players being present, that would force everyone back regardless). So, I’m not so much implying that any one solution should be universally preferred, rather I’m stating that a game-specific solution should already be in place to handle those edge-cases, as these concerns were presumably always an issue, with or without this update. Perhaps discouraging bad actors, and allowing players to join into active games, may be a good fix for such a situation.
The main problem I saw with this particular update’s implementation, is that it made it possible for otherwise good-natured players to mistakenly damage their own experience, by being in their menu at the wrong time. However, if a player were to instead deliberately choose to be prompted for teleports, then the responsibility to respond, would clearly be on them.
And yes, Player:Kick(), called from the server, should always be the preferred means of disconnecting players from the experience. All other methods can usually be categorized as either rule-breaking, or potentially ineffective.
I just fail to see what the player gains in terms of privacy by gaining the ability to control their own teleports. If that’s the case, why don’t we run every data store request through the client to see if they are ok with it? I hope I don’t have to explain why the ladder would be quite asinine.
In reality, by joining a developer’s game, you are putting your trust in that developer. If a developer is going to teleport you to a third party game that you don’t want to be in, then just leave?! It’s not like it causes any hardship for you, possibly mild annoyance. You’re just increasing workload for developers in the name of giving players pointless control over random features.
9 Likes
That’s the thing, I don’t think it increases the workload at all. Developers should already be implementing logic to combat stalling in the first place (see my other posts). Furthermore, when I used the word ‘data’, I wasn’t speaking on privacy (I never even used the word), but rather data in general. It takes significant loading in order to join a new server; players, especially players concerned with their connection (VPN users, mobile users, those with limited data, etc.), should probably make these shifts on their terms. When they click play, they agree to join the game they clicked play on. Not every game in some large convoluted network of games, whereby they may be shifted around nonconsensually. That all being said, you do raise a good point. I think that forcefully being teleported into a third party game is of course problematic; those teleports should always be prompted. Yes, I can ‘just leave’, but if the game is abusing some API to grab information from me as soon as I join, then it may already be too late. It’s not irrational to assume that having a player instance in the game, may expose more APIs relevant to collecting account related information. I should of course make it clear that my issue is not with games using teleporting for genuine means, it’s with the blatant disrespect for player intent when these teleports are unprompted. Functionally, giving players the power to say ‘no’ and accept the consequences, changes nothing.
1 Like
Thankful this got removed as it broke soft shutdowns, matchmaking, and many more things.
2 Likes
I would argue and say that the data they could possibly collect on you is so irrelevant that it doesn’t matter. And EVEN IF it did matter:
If a developer is willing to teleport you to another instance that will “abuse the API” to take your information, who’s to say that the developer won’t just do that in their own experience? I just don’t understand how teleporting adds any extra threat level to the player and how asking the player beforehand adds any sort of protection. If a player joins a game, they join trusting that the developer has their best interests at heart. If the developer has malicious intent, wouldn’t they be able to carry it out with or without TeleportService?
Continuing what I said before, roblox has very robust safeguards in terms of player safety and keeping information private. Any leaking of personal information could lead to a huge lawsuit for child protection laws that I’m sure roblox definitely doesn’t want to deal with, so this “API abusing for personal info” you speak of really seems negligible to me. What’re they gonna do, see what groups I’m in? Big deal.
2 Likes
Here are my thoughts:
How about this: instead of pushing new updates out with absolutely no regards to developers & existing experiences without any forewarnings whatsoever - try to give a timely heads up manner, and most importantly: ask developers for feedback prior to implementing such drastical changes.
I was actually surprised that Roblox actually took input from the replies in this post - I think this is a good change from past behavior I’ve seen. Now, while you’re at it - take another good step ahead and start publicly posting ideas before implementing them - this way, you don’t waste your engineers’ time on products that will receive so much backlash that they are removed again. This comes with a bonus - more real-life scenarios that are brought up to your product managers - so that you have more edge-cases covered.
And, you will also involve the community and make them feel listened to & valued - only a win-win situation for everyone involved.
4 Likes
Genuine, properly prompted use-cases, are not the concern here. In the past, when certain major exploits were discovered (truly problematic cases of IP grabbing, and games which charged fraudulent RB transactions), only very few experiences were malicious. The reason why the attacks became widespread, was because players abused backdoors, and admin commands, in order to forcefully teleport players from otherwise unassuming titles, into these problematic experiences. I’m not saying that Roblox will burn if the feature isn’t added, but it’s undeniable that its addition would be a good safeguard against certain worries.
What you’re dismissing, is that adding this, doesn’t, in actuality, impact anything, at all, from a developing perspective. Perhaps I have a misconception that someone can clear up, but I’ve been under the assumption that the potential for teleports to be delayed has always been real, and should have always been accounted for. Given this, there’s simply no reason, as far as I can see, not to give players the option to control which experiences they’ll be subjected to. It’s only a good thing. Pertinently for players like myself, who intend to play what we click play on, and do not want to load entirely new games nonconsensually.
1 Like
Making it so you must manually ‘accept’ a teleport is not only a major disruption to the flow and immersion of many games, it is also a non-solution to the problem that you proposed in this post. You have to tackle the problem at it’s source, in this scenario the issue is not the unprompted teleports, it is within the vulnerable API that is exposing private information.
6 Likes
Except that it just makes it easier for players to “troll” and whatnot and hold up teleports for a noticeable amount of time, given the official implementation of this feature.
I didn’t have this assumption, I always though the server had some important role in teleportation and I think a lot of other people thought so as well. I really don’t think many people expect teleport errors and yielding to be spoofed by an exploiter.
1 Like