^^ Title. I’m writing a plugin that stores settings per-place (as in the setting are stored as NumberValues and such) and I want it to work smoothly with TeamCreate.
Oh. I did not check if Players.LocalPlayer actually worked. And it did…
Is this a fool-proof way of checking if studio is in TeamCreate or should I do something else?
Why would you need your plugin to understand if Studio is in team-create or not with the sole function of saving values?
AFAIK, the players list shows the users in studio only within Team Create and not within regular places. Though I am not too sure myself.
Will break when you’re in test mode.
@XAXA There isn’t a definitive API for establishing if the game is in Cloud Editing / TeamCreate Mode, but a hacky solution would be ensuring the game isn’t live (i.e. not a test server) and there are player instances in the game.
You might be able to find an internal API that a plugin could access establishing if the game is in TeamCreate.
Because I don’t want multiple players messing with each other’s settings.
Would checking that we’re in edit mode (RunService:IsEdit()) and that game.Players.LocalPlayer isn’t nil be good enough?
Couldn’t find any. I checked both RunService and Players.
Effectively - I can’t think of an edge case that’d break it.
4 Likes
Because that isn’t per place and that can’t store models.
You could make some sort of serializer in your plugin to store models as text, and also store all data per place using game.PlaceId
The PlaceId of a game that isn’t published is fixed (your UserId) so I can’t use it to save stuff per-place and it’s not feasible to serialize any arbitrary model.
If you’re familiar with Tag Editor it saves your settings somewhere in ServerStorage. There really isn’t any other way to save settings per place that I could think of other than stowing it away in a folder somewhere in your place file.
2 Likes
You could put the data in a hidden-service or use SetSetting and save the data in a way that the model saves the info inside in a manageable way say as a dictionary with data inside.
1 Like
I don’t know if you have tried, but, can’t you just generate a GUID or UUID and save it using set/get setting?
Then you would be able to check if it is the user’s data or not. Like with your NumberValue, you make the value’s name the GUID and the value to whatever.
EDIT: I forgot that you said you did not want them to mess with each other’s values. You could use some kind of encrypter to verify?
Whether or not I store it in a service that’s hidden doesn’t really make a difference…
Then the list of places would grow indefinitely. And this doesn’t really answer HOW to store models in the settings.
Settings are stored locally, anyway. So doing some sort of verification system is completely unecessary.
We’re going a bit off-topic. Stop suggesting Set/GetSetting.
1 Like
We’re not forcing you to use Set/GetSetting, but it is a viable option that CAN be used per-place if you know how to.
Also, using a hidden service such as Geometry prevents clutter building up in your explorer, a lot of people who would consider using a plugin for whatever you are creating would really appreciate it.
I’ve used Geometry to store stuff in a previous plugin before (See: BrushTool), but thanks for the suggestion 
I’m staying away from using Geometry because it sticks with your place file forever, even after uninstalling the plugin, and I can’t easily direct users to reset their settings by deleting a folder.
Get/SetSettings is not made to store per place. I’ll point out that Tag Editor, which was create by a staff member, stores stuff in ServerStorage, so I believe that this is a good practice.
1 Like
Another thing you could do is also make a settings UI. Then you could verify the change because they would edit it through the UI, and not through explorer. Listen to the Changed event on all of the Values and then if it was edited in the UI, it is verified.
However, this wouldn’t stop other people from editing the values when the user left the Team Create session.
Topic requested to be closed by OP.
1 Like