Hi I’m TrossCraft and i’m making a game is called Youtubers Life and i’m making you can upgrade your computer and anything but i have a problem…
if the player leaves the game and rejoin he will lost all he buy…
i only know how to make a savable leaderboard but i don’t know how to make a savable models.
I think you should just save a value like ‘computer level’ and then when player joins check for that level value and clone the corresponding model of the computer from Replicated Storage for example and parent it to workspace for the client.
A DataStore is incapable of storing instances. You cannot create this. On the other hand, @Ancient_Orange raises a good alternative method which states that you should save a value of some kind for reference. Upon loading, this reference is used to determine the kind of model you should fetch from a storage (e.g. ServerStorage).
@Ancient_Orange already stated what I was gonna say. However if you want a clearer idea, what I would do is:
game.ReplicatedStorage.Items.Computers['4'] --computer of level 4
in the datastores you would do:
Levels = {
Computer = 4;
Headphones = 2;
ect
},
OtherDataSuchAsCash = 50;
}
Then, you would save that array just like your leaderboard.
Note that you can save your array in JSON, which will do like if it was a string and so would take less time to save/load.
How to do that would be:data=game.httpService:JSONEncode(data);
loading: data =game.httpService:JSONDecode(receivedData);
JSON encoding and decoding is handled for you by Roblox, no need to do it yourself,
It is impossible to store instances using DataStores, however there are some workarounds to this. One method has been listed by @Ancient_Orange, though there is another one which can be used if there are no set “levels” for your items, such as in Welcome to Bloxburg where players can build their own, completely custom houses. In the latter case you could make a table for each instance, have all information stored in this table such as size, position, orientation, and whatever else needed, and save these tables to the DataStore. When the player joins, create instances according to the tables. I recommend going with Orange’s method if you have specific models which are not custom-made by players. Hope I helped. 
More trouble than it’s worth. I wouldn’t serialise a model. Models are bound to change anyway while you update, so relying on explicit data regarding a part is not recommended. I can see it working for very rudimentary properties like position and rotation, but I would not delve any further.
Saving reference values (e.g. Building Tier) is subjectively more effective than relying on part data. It varies based on your use case.
I find it hard to believe that you would hit a 260K string character limit in a DataStore quicker by saving only what you require to identify what model to use over serialising entire models. This also does not take into account what I said - that a model can change during the course of development, meaning that an outdated model will be pulled from a DataStore when fetched. Saving identifiers and references is far more effective over unnecessarily wasting your character space for a large value.
You yourself have identified the problems of serialising models in part by stating large data chunks would be produced as a result of serialisation, as well as mentioning this uncomfortable phrase “work for a while”. I do not trust this. With references, you gain more benefit than not.
Like I said. Serialisation is more trouble than it is worth.
I’m not sure of your situation, but you likely don’t need to save a model, but rather a table of data that represents the model.
Say, for example, that you let players buy new houses in the game. You don’t need to save the house, you can save a value that points to the house. Allow me to clarify.
Imagine this scenario: You have a folder of 100 possible houses, levels 1-100.
Rather than save the actual house model that the player is up to, you’d save the level number, and reload the house model from the folder when they rejoin. It might look something like this:
--Some fake code, not certain it's done correctly off the top of my head
--To save
local success, err = pcall(function()
DataStore:SetAsync("Player_"..plr.UserId, {House = 23; Money = 2193;})
end)
--To load
local HouseModel = HouseFolder["House"..PlayerData.House]:Clone()
If you absolutely must save a model (if you let players create custom models, such as a sandbox tycoon), you’d serialize the model into a table that represents every property of each descendant, and then save it and use that table upon rejoining to recreate the model. This is complicated, and I don’t really recommend it.
If you’re looking for a well made serializer, check out CrazyMan32’s plugin. The source code is obviously open source (on your machine once it’s installed) so you can look through it to see how it works!
You could try saving the type of computer he has as a string value, and then further modifying that when the player joins. As an example, save his computer as “Good PC”(best name I could think of), and then further store their computers specifications in another data store. You could save the rgb of his pc’s lights, and load that in or separately save the type of fans they have, the position of the computer, ect. As far as I know, there is no way of saving a model, but you can save and load in the properties of parts within the model, and re-create the pc. In case you’re wondering how to save properties of a part, here is an example of a color data store I used for one of my game’s hair loading.
local hair1savetable = {r = hair1col.r, g = hair1col.g, b = hair1col.b}
then set the color datastore to be your table.
When you need to load that data, you can use:
hair.Handle.Color = Color3.new(SavedStuff1.r, SavedStuff1.g, SavedStuff1.b)
thanks @boatbomber
To highlight something as a code block, you write ```Lua
and then write the code, and then end it by writing 3 `s again
Like so:
local x = 1
Oh, thanks! That really helps!
local hair1savetable = {r = hair1col.r, g = hair1col.g, b = hair1col.b}
hair.Handle.Color = Color3.new(SavedStuff1.r, SavedStuff1.g, SavedStuff1.b)
It works!
You can edit your original reply to have this highlight format! Use the pencil button to change it!
Then, but only then. There’s no good reason to make a system far more complex than currently required, when it’s only to make it easier if the entire game concept would undergo a radical change.
Yes I very clearly noted that. OP is not making such a system so serialisation is unnecessary in this case. A custom building system obviously needs serialisation because you can’t just pull prefabs and assume that’s what the player built. On the other hand, for something that has no customisable value in it, serialisation is a waste of characters in a key.