Users will be able to edit the properties through the instance, which I guess was the design philosophy behind it, especially when catering to new users of Roblox Studio. I was really expecting TeleportOptions to mimic TweenInfo.
The answer to this is really that we’re not 100% sure ourselves which way is better at the moment. It’s likely we’ll choose one direction or the other (for future APIs) and stick with it pretty soon.
2 Likes
Our current focus is to simplify the API so it is easier to understand and add to your code. The backend performance should be the same. We are definitely working on improving the stability of the service. Stay tuned!
3 Likes
Will this take care of the old problem that was occurring not allowing some players to teleport?
1 Like
We are aware of supporting private servers for teleport, and understand the challenges today. This is something planned in our future roadmap.
12 Likes
I’m going to be honest, not really a fan of this new API. I understand that Roblox wants to consolidate a bunch of old APIs into single-methods with options datatypes to reduce how many methods need to be memorised, but this just feels weird to use.
A question I do have is working with the TeleportResult because now you only get your data after you initiate a teleport - what happens for closing servers that initiated a teleport? Does the server still get time to run this code outside of a BindToClose function? If not, then how exactly are we supposed to work with the TeleportResult?
I still prefer explicit declaration of reserved servers. What if I don’t want to teleport the player immediately? The new API declares that I have to make a teleport to get an access code as well as any other data from the teleport. If ReserveServer is on the list of APIs to be deprecated, then it’s not expected that I use ReserveServer if I want private server data and then teleport with ShouldReserveServer off but the ReservedServerAccessCode set.
The one thing I am glad about is that the client is unable to use the new teleport API, I literally wrote a feature request about blocking the client from using teleport methods, but the old APIs will still be usable so it’s not a complete resolution for my problem.
Pretty sure that passing a custom loading screen as part of teleport parameters was superseded by the method SetTeleportGui, so you should be using that regardless.
3 Likes
The existing APIs still work. We are considering deprecating them in the future, and encourage you to use the new API going forward. Even if we deprecate the old APIs, it only means no future improvements will be added to them, but they will continue to work as is.
6 Likes
Isn’t it going to be slow to have RayCastParams and RayCastResult as instances, if you go this direction? For example, instances have a lot of bloat coming along with them (replication to the client, allowing children, etc). Also creating instances is pretty expensive.
1 Like
The existing group teleport API (TeleportPartyAsync) can only be used to teleport a group of players within the same game / universe. The documentation for the new TeleportAsync API states, “Teleport any number of players to a Public Server”, and it accepts an array of Player instances. Is it now possible to teleport a group of players between games / universes?
Edit: Tested this. The answer is: No. When teleporting a group of players, the placeId provided to the TeleportAsync API must be within the same game / universe.
1 Like
Indeed, but there are some mitigating factors. Just like with RaycastParams you would likely create a single object and re-use it multiple times setting the properties inbetween, so you would only have to pay the Instance creation cost once. Plus if something is an Instance you would get any future reflection APIs on it. Either way though, yes, it has quite a few costs too, which is why we’re still undecided.
4 Likes
Don’t worry: To be clear, I’m only talking about direction for future new APIs here, not that we’re going to be going back and changing the way the existing APIs work to make them uniform.
3 Likes
Ok. The thing is, I need TeleportData. There is no area in :TeleportAsync() that talks about TeleportData.
Also, is this more reliable then just doing :Teleport() or :TeleportToPrivateServer()? I mean… What is like the point of releasing a new API if :Teleport() or :TeleportToPrivateServer() are not getting deprecated?
If they do get deprecated and I have no way to use TeleportData, I will be pretty upset. I rely on TeleportData for my games, so I don’t have a spam full of places in my universe.
Even though I don’t use SpawnName or Custom Loading Screen, those should also be implemented.
1 Like
Your questions have already been answered in the post and the responses. Just out of courtesy, I will still respond to them. Please be sure to read the responses more carefully prior to creating a response.
Everything that would typically encompass the typical TeleportData argument can be used with the TeleportOptions instance for TeleportAsync. Old methods of TeleportService, including their existing arguments, will still exist so older games won’t break.
You should still be able to use the TeleportData argument in Teleport, TeleportPartyAsync, TeleportToPlaceInstance, TeleportToPrivateServer, and TeleportToSpawnName, regardless if they are deprecated or not.
1 Like
Instances seem safer because they don’t add new globals to the environment, however, instances are usually very expensive to create and come with properties like Name and Parent that might not make sense for features like this.
An ideal solution might be able to facilitate complex server-only features without bloating the client in any way. This would probably only save a few kb though. I also don’t know if TeleportAsync is server only or not.
3 Likes
On the page TeleportService | Documentation - Roblox Creator Hub, there is a typo on line 7 of the code. The code uses another type of double quotes (”) instead of ", which is used for strings. Code:
local teleportOptions = Instance.new(“TeleportOptions”)
Correct:
local teleportOptions = Instance.new("TeleportOptions")
4 Likes
New API is appreciated but underwhelming.
I don’t see how the New API adds new Functionality to TeleportService, we can’t do anything new with it afaik.
Why can’t we use Get TeleportData from the Server, when this has been requested multiple times over many years…
I was excited at first when I thought we’d get new stuff to play with… now I’m disappointed
Now its getting even more strange…
If they are trying to simplify things, why separate features of TeleportToPlaceInstance to 3 different things?
SetTeleportData, SetTeleportGui and InstanceId are now awkwardly separated and need to be called 1 by 1, instead of just throwing them as the TeleportToPlaceInstance arguments
1 Like
This seems really cool!
Will the simple teleport service get removed?