New Teleport API: Now Available For Everyone

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

Yep

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 :weary:

Going to test it in a bit though :slight_smile:

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

Hello a quick question regarding teleport Async, does this teleport API only give you the ability to teleport players to private servers or could this also teleport you to a public server, thanks for reading!

It can teleport to both. I believe this new method includes all methods.

1 Like

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.