This isn’t really a client bug, but it’s the best category imo
To this day, “GetPlayerPlaceInstanceAsync” still doesn’t return correct values. Even if they are in the same “Game (universe)”, and in a different place, it will still return all incorrect information.
Describe the bug. Describe what is happening when the bug occurs. Describe what you would normally expect to occur.
What’s happening: Calling GetPlayerPlaceInstanceAsync returns this: {Success: (this varies) true / false, errorMsg: nil, placeId: nil, instanceId: nil} It rarely returns the correct values, and its roughly 50/50 about working
Intended: Calling GetPlayerPlaceInstanceAsync should return the correct values for the placeId and instanceId if they are in the same “Game (universe)”
How often does the bug happen (Everytime/sometimes/rarely)? What are the steps that reproduce the bug? Please list them in very high detail. Provide simple example places that exhibit the bug and provide description of what you believe should be the behavior.
Happens 50% of the time you try to use it.
Calling it on the client obviously doesn’t work (since its a server-side function), but using it on the server always returns incorrect values
Where does the bug happen (www, gametest, etc) Is it level-specific? Is it game specific? Please post a link to the place that exhibits the issue.
Happens on all ROBLOX places on the normal website (as of what I know of), not game specific, as I’ve tested this issue on multiple places and received the same result
For graphics bugs, it is sometimes helpful to know your system specs, especially graphics card.
When did the bug start happening? If we can tie it to a specific release that helps us figure out what we broke.
It has been happening for quite awhile now. It seemed to work better last year, but at least for awhile it hasn’t been working at all
I remember i got around this by ignoring the error message value, but I think it was
local success, errorMsg, placeId, instanceId = TeleportService:GetPlayerPlaceInstanceAsync(targetUserId)
if instanceId ~= nil then
TeleportService:TeleportToPlaceInstance(placeId, instanceId, player)
end
probably not the best way but it seemed to work for me since then quite well. But no doubt “GetPlayerPlaceInstanceAsync” is quite buggy.
The issue still exists. I have a game that has 2 places in it. 1st is the main place and 2nd is the gameplay place. (All in the same universe) and whenever I try to call the function, the “success” value is always false.
As you can see, everything is returning correctly except for placeId which is nil.
Edit: also, for some reason, it’s giving me an error saying “Attempt to teleport to a place that does not exist” when using TeleportToPlaceInstance when the place does in fact exist…
We’re experiencing the same issue with the PlaceId being nil. This is preventing us from allowing users to join their friends sessions a majority of the time.
Having the same issue right now. PlaceId will return as nil. Small workaround I found though. You can use Player:GetFriendsOnline to get the PlaceId’s for all the friends (If they’re in games).
Example Code, creating a button for every friend online (Local Script):
--Wrap in pcall in case error
pcall(function()
--player is the player you want to get the friends of
local dict = player:GetFriendsOnline(200)
for i,friend in pairs(dict) do
local nfb = game.ReplicatedStorage.friendButton:Clone()
--placeid is an int value inside the button
nfb.placeid.Value = friend.PlaceId
--nametxt is a textlabel inside the button
nfb.nametxt.Text = friend.UserName
-- frame being where you want to put the button
nfb.Parent = frame
end
end)
friend.PlaceIdwill return the PlaceId of the place the friend is in.
Then we can use a RemoteEvent to pass the placeid to the server, and use GetPlayerPlaceInstanceAsync to get the JobID for us.
Example Code, teleporting the player that fired the remote to their friend. Be sure to fire the friend’s UserId, and the PlaceId! (Script):
game.ReplicatedStorage.JoinFriend.OnServerEvent:Connect(function(plr, friendid, realplaceid)
local success, errorMessage, placeId, jobId = pcall(function()
return TeleportService:GetPlayerPlaceInstanceAsync(friendid)
end)
if success then
TeleportService:TeleportToPlaceInstance(realplaceid, jobId, plr)
else
print(errorMessage)
end
end)
realplaceid is the placeid you got from the LocalScript (friend.PlaceId)
Hope this helps someone! EDIT 2: After I tested this, roblox returned Error Code 773, so it may not work for some
*EDIT 3: In the local script, friend.VisitorId is their UserId, so use friend.PlaceId
It turns out that there is a “hidden” and unknown value between the currentInstance and the placeId values that were returned, which seem to always be nil, private server or not. In a generic pcall that returns the results of GetPlayerPlaceInstanceAsync, it seems to be this:
success, currentInstance, unknownValue, placeId, jobId, success being the pcall success result.
This value in question isn’t documented by any means, so the most likely thing is that it’s an unintentional value that’s returned, and might be the reason why people here seem to experience issues.
Code I used to test this:
local ID = game.Players:GetUserIdFromNameAsync("YourName") -- in this case it was Crimson_Knights
local success, currentInstance, unknownValue, placeId, jobId = pcall(function()
return game:GetService("TeleportService"):GetPlayerPlaceInstanceAsync(ID)
end)
print(success)
print(currentInstance)
print(unknownValue)
print(placeId)
print(jobId)
As said previously, this is undocumented, shown here in Oops!
This is the old description for the returned parameters, from the old wiki:
succeeded - true if the player was found
errorMsg - the error message if anything went wrong with the lookup
placeId - the id of the place the player is active in
instanceId - the id of the instance of the player’s place
That’s without a pcall – with a pcall, you would naturally add another bool in front of it when catching the return value.
This API is weird in that it has some error handling of its own, but also requires you to pcall the statement to catch service failures.
