New Teleport API: Now Available For Everyone

[twistedtempo50 (Twist)]

This seems really cool!
Will the simple teleport service get removed?

[IdkHowToWhistle]

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)

[Gatorzgaming (Gatorz)]

Yep

[DR_TRAY11111 (SeanLuaTech)]

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.

[Tipic_faker (Tipic_faker4166)]

Could you please remind the backstage team to add Chinese translations? Thank you

[metatablecatmaid (metatablecat)]

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

[Satrience (Vlale)]

Roblox staff said yes, it will still work and not be removed even if deprecated.

@dragonknightflies

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.

[DR_TRAY11111 (SeanLuaTech)]

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?

[Grargror]

You should read the documentation for TeleportAsync. A code sample for “Teleporting to a Reserved Server” is provided:

[DR_TRAY11111 (SeanLuaTech)]

Thank you, will do! Im glad that is there!

[RaterixRGL (Raterix)]

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.

[sas_rbx (sas)]

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

[buildthomas]

@saSlol2436

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).

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.

[Jackoob_YT (Jackoob)]

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!

[MightyDantheman (Fate)]

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