EDIT:
Basically, I was talking about storing references to instances, and how it was in-progress and i was going to upload the update soon…
Alright i updated, however there is a problem. Scripts cannot read the .Source of other scripts so its impossible for this module to save scripts /w source. However, a plugin version of this module could.
wait slow down… i dont understand what you mean here because your replies are all over the place. Please explain to me thoroughly the changes made to the module and the explain to me what you meant by cyclic instance references and what do you mean here:
Sorry about that LOL. Now the module can store references things like welds or Adornee properties.
As long as ; The referenced instance is a decedent of the serialized instance.
E.G ; As long as the weld doesnt try to weld to something random in workspace
So you mean, that now the module supports storing welds! YAY!!
However question: I think in one of ur replies you were talking about the scripts… for my questions if the module supports scripts in the chosen model?
Due to Script Identity, you cannot read or write the contents of a script(.Source). Plugins have this ability however.
aw damn, would be so useful lol. Aight, ima use this module and test it.
does it support mesh doe? like meshID and etc.
Would you mind adding texture id’s of meshes and meshparts if you dont mind
Encoding sibling parts with the same name causes them to be parented inside of each other after decoding. I would add this to limitations.
Also, the PrimaryPart property of a model cannot be encoded and decoded, which is another notable limitation.
Alright for the PrimaryPart issue I’ll fix this is the next update. it has something to do how it only allows decedants of the main model to have instance references. But its an easy fix,
I have also fixed this, really werid issue that only showed up in this version. It happens mainly because i changed how root names are decoded. Hopefullly theese fixes will come out later today as a do some more testing.
Thanks for letting me know!
1 Like
Alright both issues have been fixed! Thanks again.
1 Like
It works more on the datatype then the property name,
But i beileve TextureIDs are a Content DataType and should already be saved.
MeshIDs cannot be modified, if there are any issues while decoding it should show up in
your console. Which is a reminder that I should be filtering out any non-scriptable properties.
I’ve been thinking about adding some type of non-scriptable cache to the module, but i dont know if it would be worth it.
Heres from the documentation
The MeshId is the content ID of the mesh that is to be displayed on the
MeshPart.
Note that this property currently cannot be changed by scripts as the collision model of the mesh cannot be recomputed during runtime. Developers should not rely on this behavior as it may change in the future. Those looking for a custom mesh object that can be updated during runtime should useSpecialMesh.
MeshPart.MeshID.
So i should be using SpecialMesh, huh i didnt know. But does the module even support that?
Another Question that I should ask… How do i find out the name of the datastore… or to be more precise, How can i encode a model from 1 place then decode in another? I dont know what the module names the datastore the serialized model is in or if the module can recognize models that arent defined in the script (To decode the model) but are stored in the datastore as something.
The string is storable in datastores, so as long as you can access it, you can decode it…
How you manage all of the players parts is up to you, however i think the best way probably is with a folder . Decode when they join, encode when they leave.
waat? So this 1 string can actually let you have access to an entire model (If it exist in the datastore)?! damn, thats like having a security code to get something important.
You still havent answered my question of if the module supports specialMeshes
If it doesnt, then its a good idea to add in support. Unlike MeshParts, SpecialMeshes do not calculate the collision bounds of the Mesh but instead use the collision bounds of the basepart (“No precise collision, Just a square-ish type of collision”). Because of that, scripts can actually modify the “MeshID” of the SpecialMesh instance. Infact, its the sole reason why the MeshPart’s MeshID property cannot be modified… because of the fact it needed to recalculate the collision of the mesh and that roblox does not have a system/engine to recalculate collisionBounds in real-time.
I beileve SpecialMeshes do work. Again as long as the properties are scriptable it most likely can be serialized. Only really one way to know, and thats to try and see. I havent tested every instance myself, as the serializer only caches information and references it really doesn’t know what its storing.
A rule of finding out if properties are supported is, as long as the property datatype matches the supported datatypes aswell as being scriptable.
Also, I probably wont add any specialized support that makes me do anything else.
Instance support is almost 100% dependent on my API Dump which working on to update.
Unlike most of the available instance serializes, the data is stored in raw data instead of a serialized table. But its essentially the same thing as storing a json string.
Tried this using SpecialMeshes and turns out im kinda right… you do need parts with special meshes for it to work.
This is perfect for a project I’m working on! Thanks!
Just two questions: I’m working on a package manager (spm: Studio Package Manager) and I’ve been working to find a way to serialize Instances in plugin:Set/GetSetting-compatible format. Just a few questions:
- Is this able to serialize
LuaSourceContainer.Source? - Can I use this with plugin settings APIs even though you mostly mention DataStore serialization as a use?
I’ve seen a n issue /w attaschments and certain instance references not working properly i’ll put an update soon.