You could keep saving player data normally. And come up with your own server instance. For instance lets say you have a list of servers.
Alpha, Romeo, Zulu. Then you would save Zulu to the Zulu instance in your datastore as a global datastore. Then you can save player data under a Zulu key. Then when a new server is created, you can ask and see if a Zulu instance is running. if not you can load a Zulu instance from the datastore for persistent data.
It’s definitely a lot of data. And will definitely take some time to get a decent solution. All you have to do is try.
It’s basically saving data in the datastore under the server instances name. So for each server you have under the servers tab of your place. Each one would get its own unique name. Something similar to QuarantineZ’s server list.
Right so persistent hyper-realism. In terms of game design this definitely seems interesting, but in terms of execution:
Meshes don’t actually have to be saved, they exist and can be used, you’re fine there.
Unions will be hell, even with live CSG, store the members of each union, their positions, and the resulting position then operation type I guess.
Values are easy to save, even in a cluster of random instances, as long as the instance names are fine, a recursive selector and saving :GetFullName() and the Value on each value that needs to be saved would be fine.
Don’t save properties, have property templates based on an identifier pre-made, and save the identifier instead.
A DataStore is not the best way to do this with possible size limitations, using a proper database would be a little more forgiving.
With this much crap already planned to pollute the workspace, keeping it online constantly would be a hard hit to memory, so please don’t stick to that plan.
Keep in mind the same solution is also possible with @RigidVellerium 's suggestions. You can do the same saving but with a real database instead. Can’t imagine what that might cost though.
JobId is unique to every run, so that’s a waste of time/space. If your server has a name, sure, enjoy. I’m still against DataStores for this kind of storage though.
And yes im kinda against datastores tho, since the maps could be really large and datastores could easily fail with the amount of parts spawned or changed by players.
It’s do-able locally with a port-forwarded-access server (would allow for better pre-encoding for space storage if you had a lower level language before pushing to the database), and he seems to have no regard for his parent’s electrical cost, so this is the best alternative.
If you want to store a material for example, put it in an enumerator:
local Materials = {
Cobblestone = {--[[Cobblestone properties]]}
};
-- You would be saving "Materials.Cobblestone" instead of
-- {Material = Enum.Material.Cobblestone, BrickColor = BrickColor.new("Green")} -- (probably wrong but just an example)
The bandwidth though. I get charged $10 for every 50GB block after 1,200 GBs. So most definitely gonna be more combined with that electrical cost depending on your internet provider.
In the worst case scenario they will terminate service.
I know port forwarding is free, but my dad wont allow me to port forward stuff since the website for the router says at the port forwarding part that it will get acces to mail clients and stuff like that so thats why he wont allow me to port forward.
Not sure what this is supposed to mean, as long as you don’t inform anyone of your IP and only open the correct ports, your information and activity is entirely safe.
Not sure I understand this, but port forwarding simply makes a local address discoverable on a specific port for your public facing IP. There’s probably more technical terms for that though. Perhaps there’s more to it and you can look into this more and discuss with your dad your plans?