As of now, my game does not have multiple worlds, but since the world is getting so big to the point where mobile players crash, I am forced to split the world up into dimensions (or places). I am familiar with TeleportService and a few of its functions using placeID and whatnot, however, I am doing this in a separate game altogether first, and then publish over to a non-team create place (which is the official game place), however, I have never done this before so I have a few questions:
Would I need to publish each place individually to the real place? The problem here, the scripts would hold the placeIDs of the test place, and when I do publish over there is a risk of someone getting into the latest server and having all these incorrect teleport IDs. Is there a way to retrospectively get placeIDs? Or perhaps teleport to a game using place names? Such as āDimension2ā instead of an ID like 9342561?
As far as I know it is not possible to predict a place Id before it is published.
When publishing, you publish a place to target place. You would indeed need to publish every place seperately.
You could perhaps create empty places for each future place and use their Place IDās. As for storing those other āliveā place IDās, you could use a datastore entry, as those do not get copied over. Do consider if your benefit from this is worth the possibility of the users not being able to teleport until these place IDās are fetched correctly.
Have you tried using StreamingEnabled? If your dimensions are spaced out, only one dimension should be on the client at any given time. (This is as far as my understanding of StreamingEnabled goes, please do correct me if I am wrong.)
(Helpful article)
My developer has mentioned something about it but unfortunately I was too hard headed to adapt my code to support StreamingEnabled, I already have a game with thousands of lines of codes, simply StreamingEnabled will break everything?
Not necessarily. I donāt know how your game is scripted but with StreamingEnabled on, you should only make sure that any BaseParts or MeshParts that local scripts need are referenced correctly. (Not local part = workspace.Part but local part = workspace:WaitForChild("Part").)
You could also parent the localscript to a part, this will make it so this script will only load in when the part it is parented to already is loaded.
This heavily depends on the game itself. I highly suggest you to try it out for yourself, see what exactly breaks and try to determine why. (In the case above, it will simply state that there is no such thing present in the workspace in the console.)
I see, Iāve managed to get it to work after parenting all camera parts to the replicated storage, much more convenient and faster load times. However, big problem is that I pass arguments such as NOC torsos to the player that are across the map so that the player can place a direction marker to them. Surely if I pass information via FireClient this will cause errors?
This is indeed something I too have researched. I havenāt tested anything yet, but to my experience parts created locally (thus in a localscript) or otherwise placed in the workspace locally will always be present no matter what. Hereās some more reading on the topic:
I myself am working on a system for flight navigation, with BillboardGuiās far away from the player. Having these placed locally has worked for me.