It’d be nice to have some documentation on the teleportOptions instance.
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?
Extra url parameters can be injected with ServerInstanceId. Not dangerous but perhaps needs fixed.
local options = Instance.new("TeleportOptions")
options.ServerInstanceId = tostring(game.JobId) .. "&isTeleport=false#"
game.Players.PlayerAdded:Connect(function(PlayerAdded)
game:GetService("TeleportService"):TeleportAsync(game.PlaceId,game.Players:GetPlayers(),options)
end)
2 Likes
Will reserve server be deprecated/not working? As our game is using it to teleport the players to their own assigned servers, that we do not want to be publicly joinable.
1 Like
Could you please remind the backstage team to add Chinese translations? Thank you
Epic API, I was never able to test it with FFlags because Studio cant do teleport requests 
Going to test it in a bit though 
1 Like
Roblox staff said yes, it will still work and not be removed even if deprecated.
2 Likes
Do you know if this new API has anything like the reserve server function?
or to be able to make a server that noone else can join?
You should read the documentation for TeleportAsync. A code sample for “Teleporting to a Reserved Server” is provided:
1 Like
Thank you, will do! Im glad that is there!
This was implemented incorrectly. TeleportOptions is not a valid instance, its only purpose takes form of a DataType.
This adds bloat to both the base Instance class, and to code itself.
Redo this, and recreate this to not be an instance type, rather a DataType.
TweenService uses TweenInfo.new, so should TeleportOptions.
You additionally, cannot use “re-use” as a form of argument against this.
TweenInfo.new can easily be reused for multiple operations without being an Instance.
There is no justification for TeleportOptions being an Instance.
2 Likes
This “info + one method that does everything” idea is the step in the right direction, but alas, there are problems with it
We have two methods with a similar architecture.
Workspace:Raycast
TweenService:Create
These two methods take in datatypes that (TweenInfo for TweenService:Create and RaycastParams for Workspace:Raycast)
However, now we have TeleportService:TeleportAsync that takes in a TeleportOptions instance?
So right now, in the Roblox API we have
TweenInfo - A dataType that is immutable, so its information is passed through the constructor (REALLY BAD IDEA BTW).
RaycastParams - A dataType that is mutable (which solves the problem with TweenInfo). You set its information through the . operator. (I’m not 100% sure about this so correct me if I’m wrong) The FilterDescendantsInstances table is immutable. This is kinda awkward since I expect to use table.insert or table.remove onto the table. Again, it is sort of creating an inconsistency between what I expect a table to be (+ what functionality it has) and what RaycastParams says it should be. Again, correct me if I’m wrong though because I’m not 100% if the table is immutable.
TeleportOptions - An Instance. Adds bloat to the TeleportOptions class since it’s inherited. For example, you would have methods such as :ClearAllChildren() or properties such as Name (I mean, do you REALLY have to set the name of your teleportOptions instance?) when you don’t really need it. (sorry the blurred stuff was false information, thanks BulldThomas for correcting me) When I don’t need this instance, I’m going to have to destroy it (the Tween class also has this problem where inexperienced developers just toss away the instance instead of destroying it whenever it isn’t needed).
Inconsistincies
Inconsistent Types: two out of the three is a dataType, but now TeleportOptions is an Instance??
Inconsistent Naming: We got xInfo vs. xParams vs. xOptions
Inconsistent paramater ordering: Workspace:Raycast and TeleportService:TeleportAsync has consistent ordering (origin, direction, raycastParams) and (placeId, players, teleportOptions), but
TweenService:Create has (instance, tweenInfo, table) instead of (instance, table, tweenInfo)
Now do you see the problem? How can roblox expect new developers to pick up this engine easily if there are different ways to do the “info/params/options + one method that does everything” architecture.
You could ask, “Why does this matter?” Well, I have a feeling that the Region3 API + the Terrain API will go down this route (and maybe the Widgets too?). However, they cannot continue if they don’t stick to one idea/style. Personally, Roblox should’ve thought this through before releasing the new API at all, because, now they have to deprecate again (and it sucks to learn something twice). Roblox already has it’s own mess and I’m glad they’re cleaning it up, but the way things are looking right now is not (IMO) going to work out for the future
2 Likes
That shouldn’t be needed, if you don’t parent an instance to the DataModel it will be garbage collected when it has no Lua references anymore.
See Does Roblox automatically garbage collect Tween Constructors? - #8 by BanTech for a longer explanation.
4 Likes