What CFrame issue??? It works fine for me 
When i am a sending data too frequently from multiple clients its like module is overloaded and cframe every now and then turns nil. This also happens with small amounts of data too
I think i am using old version so it maybe a bug in old version but in new one you maybe have infact fixed it
Are you available to update module on this devforum page rn or no
It could just be something with how the f16 read/writer I have works, try doing data.cframe(“f32”, “f32”) for your schemas
Also yeah ill update the download rq holdon
The download link has been updated, try the new one to see if the issue is fixed
1 Like
I would love to see auto schema feature that takes input data and outputs a functional schema for BufferConverter2. This would be especially helpful for already established games looking to integrate this into their games. I came across this, really liked it, and then realized how many schemas I’d have to manually build to make it work in my games.
1 Like
Hi, there is currently the infer schema which is basically any, tho ill probably make a plugin which can give you an automatically generated schema from a piece of sample data
I did make a module a while ago that serves a similar purpose as this one but doesn’t require schemas and works with any table structure.
Sorry for the shameless plug but I haven’t really seen much attention to mine so I decided to link mine here. This one is still great but the trouble of switching over to schemas for an already established codebase is pretty annoying.
1 Like
Hi, this is what the first BufferConverter did,the reason why the second one uses schemas is because not using schemas is wayy slower and can be undesirable for alot of people 
Also it is harder to customize the data to fit your needs, e.g if your number is only 20-50 theres no need to serialize it as an f32
Although I guess the convenience makes the downsides worth it for people, I don’t judge for plugging since i do it too sometimes :V
Mine is optimized to be as fast as possible for as many use cases as possible, and its performance is very close to httpservice’s JSONEncode and JSONDecode, which are very fast already.
I have some benchmarks for it that i sent in the post for bufferencoder, but I can make more.
1 Like
Though yeah, customizing how your data is saved is impossible without forking if its done automatic for you, but most of the time you probably don’t need to do that and solutions like your module exist if the need exists
I mean fair enough that’s pretty fast
Notice how bufferconverter1 timed out 
(note this test was done with a rewrite of bufferconverter2)
I don’t really like how BufferEncoder uses null terminators though, using a length byte is a few bytes of overhead for more performance and also less limitations (you cant store numbers like 0 with null terminators without bit magic)
It doesn’t use null terminators though?
Except at the end of the buffer to indicate end of content, though this is redundant since the buffer length can be used instead.
Ahh my bad, mustve misread the source, yeah idkw hy you dont jsut use the buffer length
Also, I wanted to point something out about the CFrame serde, heres a test:
As you can see the precision is pretty good
But here is what you do for serde vs mine:
Idk if it works good it works good, but this is alot of lines for what can be achieved in a few… it’d be good for both users wanting to understand how it works and maintainability to not have things too complicated to follow
I originally did it that way to ensure that buffer content is okay, since if it doesn’t end with null then there’s something wrong with the encoding or decoding process
It stuck since then, but it’s not a big deal since its only one byte which would be much much less than the rest of the data
1 Like
Yeah it’s fine lol //30charlimit//
Cool I’ll take a look at it, thanks!
1 Like