Another complex thing is managing when users store objects within things like dictionaries and tables to be saved. I will have to traverse through and tables or dictonaries they save to determine if the object is an instance.
I dont understand the reply you provided, but it appears to be a somewhat unexpected string of words.
He is saying that #development-discussion is not the place to promote your Easy Datastore V2 which is made up of othersâ work
Thank you clarifying the reply they sent. I want to clarify some things:
-
this post is not designed to promote easy module. I understand however the biased nature of the background information section so I have gone ahead and removed traces of promotional word usage.
-
the modupe is completely original, using the best practices. It does not copy or even take inspiration from the work of others. I understand the confusion so I have gone ahead and adjusted the post for this too.
Lastly, with these adressed, do you have any recommendations for what this disucssion should be moved to?
The topic is very confusing. the title sounds like a #help-and-feedback:scripting-support topic but the main post would sound like a #help-and-feedback:creations-feedback topic. I donât know which one to be honest.
i see. Here are the changes i made:
- renamed the post
- changed the topic
I still find it confusing. It should be more like âFeedback on my instance saving feature on my datastore module?â
but to respond to the original post, I think it is a compact one since you are storing the name of the instance so that it doesnât waste too much bytes on the data saving. I think it is good since you canât store every property unless you do some hacky methods
storing strings arenât taking a lot of space unless you have stupid-long path names, which you shouldnât. Your naming convention is important to create a fluid system that can communicate easily.
And it works great and is accurate too. If you have wall types for example, you can easily store what wall types a player has by its full name. any attributes related to the walls can easily be stored alongside the data in a table and it is always accurate unless you do something to cause it to be inaccurate.
When the player loads and you load the building you donât have to deal with instances, you just use a function to basically use the path name to obtain the object and then you can do the rest of the code as follows. I use this method for storing complex customized data. When players join the game, their inventory is reloaded using full path to get the base object. Any customizations or added data is then re-applied.