Feedback on the instance saving feature in my datastore module?

Help and Feedback Creations Feedback
#1

Background

I made a datastore module recently which I am currently adjusting.

Problem

I have been told by numerous users that they find it difficult to manage saving objects and models.

Question

I was wondering what you guys think of the idea of the module supporting saving objects.

How it would work

  1. WHILE roblox studio is operating. Meaning the developer is still editting scripts and the game is not running, the developer of the game populates the folder with objects they want to be “saveable.”

  2. When a developer calls module.save() on a instance, it will:

    • first determine its an instance through checking the object type,

    • then it will store the name of the instance RATHER than the actual properties and complex stuff.

  3. When a module calls module.get() on a instance, it will:

    • attempt to look inside of the folder and match the name provided with any objects found.

    • If an object is found, it will return a clone of the object (which was stored in the folder) based on the saved name.

    • Else, it will error it doesnt exist.

3 Likes
#2

to my knowledge you cant save objects or object references, though correct me if im wrong.

you can save the properties such as its name,cframe,color, etc so you could have the module match these properties to something in the game which would “reference” the object indirectly.

1 Like
#3

please read the post content before making a reply! Sorry if the title was misleading I will change it

1 Like
#4

yes you can really but theres a chance it could mess up

1 Like
#5

It would not mess up because the logic seems pretty simple

1 Like
#6

ik but how in which case do you script storing parts in a data store like what logic of scripts do you use

#7

This was actually a feature that existed in Roblox a long time ago, before DataStores were a thing. The main issue with it however was that it took up a lot of storage space, and only a few models could be saved per user.

Though if you’re making an abstraction layer around DataStores for this feature, it may be useful with some optimisation features: serialising and compressing the parts in the model, not storing default properties, and turning custom userdata types like Vector3 into strings are a few I can think of off the top of my head. If models can be compressed to take up as little space as possible, this would also allow models to be set and retrieved on the fly without having to update the experience.

Storing references to objects might work, though I’m unsure if that allows models to persist easily between sessions.

#8

all of the models are stored in a folder.

When you use module.set() on an object, rather than actually remembering all the properties and stuff, it will store the name of the model alone as well as a identifier that the string is an object and not a normal string.

Then when you call module.get() on the object, it will see that it has been identified as an object, and retrieve a clone of the model they are requesting from the folder based on the name.

The developer will have to be responsible with populating the folder in roblox studio with all the models they want to save.

1 Like
#9

How would the folder get saved then? If you store all of the objects in the folder and you keep adding objects to them, they wont be in the folder when the server restarts. This would mean that you wont be able to clone the object from the folder.

#10

the folder is populated while roblox studio is operating so it will be stored as a normal object rather than being loaded by a script. as mentioned, the developer of the game must populate the folder with all the objects they want to be “saveable” while roblox studio is running. If they try to use module.set() on a object that is not located in the folder it will throw an error.

#11

You mean Instances not objects lol.

I don’t think it would be a good idea to make your module save generic Instances. First, it will be quite difficult to add saving to instance as the properties can be many different types (NumberRange, Color3, and others), and you will have to add support to all of those properties manually.

Second, you generally wouldn’t want to save all properties of an Instance, but only specific ones, such as only the Size and Position of a BasePart. Saving additionally properties would be a waste of storage. If a user of your module want to save Instances, then they should code that themselves saving only what they need.

#12

Yes, you are able to do this. This feature could function by storing references to objects within a folder, enabling developers to retrieve clones of the objects when using the module’s get() function, thereby reducing complexity and enhancing efficiency in data management.

1 Like
#13

please refer to this reply on how it would work. I will update the section in the post as it seems to cause confusion

#14

Is this about saving Instances to datastores, or just storing instances in a server’s memory to be cloned later?

Saving merely an Instance’s name to a datastore seems very pointless if you’re not saving any value associated with it.

#15

think of this:

As developers, since its not possible to actually store objects in datastore, we save references to the objects which we use to clone later.

The module does this same thing. If you are still confused re-read the section I have in my post on how it will work. I updated it to be more clear.

#16

:red_circle: You are allowed to do anything, be as creative as you want, and I like that you are working on a simple solution for those in need of reliable data-stores without the need of using the popular complicated modules, which despite offering many things they lack simplicity which to me is more important than multiple features packed all together for the user to stack together.

Yes, it is useful, I myself do so with some extra properties.

#17

This can already be easily done just by getting the full name of the object or instance. That would return the path the object/instance and you can have a function that then fetches that object. Saving the path to me is better than the actual object. You can save all the other details related to the object within a data structure and when a player needs to get that object, you can call that function and it will retrieve it from (server storage or wherever you stored it)

#18

I understand and the proposed method provides an API that is still simpler than Roblox services like ServerStorage, so I can see how it could be useful to developers.

Since persistence of saved models between sessions is not required, you could also replace storage in DataStores with something like a set of StringValues and ObjectValues that store references and pointers to saved models. I believe this could be faster and incur less latency than going to DataStores, and wouldn’t incur as many ratelimits. These could still be saved to the experience through Studio and loaded on the serverside.

I like the library so far though, good luck with development! :+1:

#19

I dont think its a good idea to store the full path because:

  • that can take up a lot of space
  • the reference objects are likely inaccurate (building games)

Instead what im thinking is that it saves the name alone. Then it tries to find the object (to clone) in a folder dedicated to storing “saveable” objects. This folder will be populated when roblox studio is active and the game is not running so that its consistent on all servers and not required to be saved. the folder is simply loaded as part of the game.

#20

This isnt the place to promote your ModuleScript made up of other peoples stuff.

2 Likes