You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently instances are placed into a single large array, and then the index of the instance in that array is written to the buffer. This wastes the two bytes written to the buffer. As Zap serializes and deserializes in the same order, instances will be written to the array in the same order.
A type like this: Instance(BasePart) is currently outputted as the following:
Again, this is possible because we serialize and deserialize in the same order - so instances will be written and read from the inst buffer in the same order.
Alternatives
I have not considered any alternatives at this moment.
Implementation Details
This could cause issues if we ever have non-deterministic serialization or deserialization order in the future.
Additional context
N/A
The text was updated successfully, but these errors were encountered:
After testing it appears that using table.remove will not work, as it skips over nil indexes. Instead we will need to restructure the way we send instances and the way we read them.
Before sending the instance array, we will add a non-nil value to the end of the array to ensure no elements are stripped off the end. We can use the value of true as it only uses two bytes. When we receive an instance array we will get the length - 1, as that is the length of our instances. We will store the current index value in the table, and every time an instance is read this will decrement by one.
Once again, I wish Roblox gave us Instance Ids, this is a nightmare.
Describe your feature
Currently instances are placed into a single large array, and then the index of the instance in that array is written to the buffer. This wastes the two bytes written to the buffer. As Zap serializes and deserializes in the same order, instances will be written to the array in the same order.
A type like this:
Instance(BasePart)
is currently outputted as the following:With this change implemented this will be changed to this:
Again, this is possible because we serialize and deserialize in the same order - so instances will be written and read from the
inst
buffer in the same order.Alternatives
I have not considered any alternatives at this moment.
Implementation Details
This could cause issues if we ever have non-deterministic serialization or deserialization order in the future.
Additional context
N/A
The text was updated successfully, but these errors were encountered: