Module Name: EncodeDecode Module
Use: Encoding Instances into tables with descendants for things like DataStores, then decoding them into their proper Instance(s)
Copied from original “wiki” in module, did not feel like making a new one.
Method: :Encode(Instance ToEncode)
Description: Encodes the instance and it’s children to a table that can be saved via DataStores
Returns: Table for decoding
Method: :Decode(Table EncodedCode)
Description: Decodes the code from encoding into the actual instances
Returns: Instance from encode
Before encoding and decoding:
Script used for testing:
local M = require(game.Workspace.EncoderDecoderModule)
local Code = M:Encode(game.Workspace.TestModel)
wait(1)
game.Workspace.TestModel:remove()
wait(1)
local Ins = M:Decode(Code)
Ins.Parent = game.Workspace
It’s a snippet from some code that I wrote for highly compressed rotation encoding. Using variable length encoding, It encodes a rotation very accurately but using only ~3.5 bytes on average for typical part rotations (1 byte for orthogonal rotations, 3 bytes for orthogonal-except-for-a-one-axis-rotation rotations, and 7 bytes for everything else).
Because, without a clever encoding like this, if you just do something like:
out = "CFrame.new("..tostring(cf)..")"
-- or
out = {T = 'CF', V = {cf:components()}}
You will end up taking a whopping ~60 bytes on average per CFrame to encode them, making it by far the most expensive part of the model to encode. At the very least make sure that you’re encoding the CFrames as Euler angles:
out = {cf.p.X, cf.p.Y, cf.p.Z, cf:toEulerAnglesXYZ()}
Since storing the actual rotation matrix stores a lot of redundant information for no additional accuracy.
It’s a really bad idea to use Models for “folder” / “container” purposes, because they have behavior associated with them that is should not be associated with those types of things. Namely: That if the last part in that model falls off the map and is deleted by the kill-floor at -500 the model will be deleted. This is a particularly common gotcha in Roblox game coding.
but, but I can’t drag parts into anything but models. Also, I think he means for stuff in storage and whatnot in the ReplicatedStorage/ServerStorage. Models there are perfectly fine right? I mean, they have :GetPrimaryPartCFrame() and whatnot, etc, but does that really make that much of a difference?
I was able to re-write the module and get it to work where I have to edit one thing to add stuff, not 3 things.
Also compressed 500 lines into 150, time to add support for more stuff. :DDD
P0 and P1 can be done by linking a referance to what part of the table the associated parts are stored in, and when you re-load it into a game, have welds loaded last, so that the associated parts can be linked
