it doesnt really matter if the post, icon or code are ai generated, if its actually more efficient and has less bugs than blink then why not use it
Why use it over basic buffer logic?
Also it uses OOP eww
Overengineering.
Also benchmarking such libraries against each other is kinda stupid now that i think about it
If you want speed then you will just write buffer logic yourself
Its really easy to do
Like something I would also need to do (working directly with DataStore)?
Yes you should work directly with datastore without middleware bloat
Write buffer and choose architecture
If opcode architecture fits your project you may want to look at this post i made
I have fatigue of people thinking buffer logic is somehow complex
Its literally just like arrays but with more control
Right…
Did not read the post award
Before attaching a post its smart to read its content and replies first
But it is by definition Middleware bloat, why not work with datastore and buffers directly? Why should I use Carry?
That is literally what Carry does.
It’s just that it does saving per player session, aka something you always have to do.
You have circular logic because you did not even read the post
Also its already obvioust that you read nothing that you critisize as being seen in previous post under other topic you call plugin a module
On top of that, while you are actively hating AI, you seem to be using it to write replies.
Yes, that’s what Carry does… BlinkBox too works directly with RemoteEvents, both those cases are middleware.
[Use] <-> [Middleware] <-> [API]
[Networking] <-> [BlinkBox] <-> [Remotes]
[Saving/Loading] <-> [Carry] <-> [Data Store API]
Why not just?
[Networking] <-> [Remotes]
[Saving/Loading] <-> [Data Store API]
As I stated; Pedant, it is an irrelevant point.
I don’t get where this comes from, where have I utilized AI?
That is literally what it does.So yes affirmative that i am negative confirm and therefore please send me a link to the carry page
I don’t know what you’re talking about.
It’s just inserting functions into an array that gets iterated.So yes affirmative that i am negative confirm and therefore please send me a link to the carry page
It’s as direct as it gets without having a single function call build the entire buffer, at which point you lose access to the proper upvalues.So yes affirmative that i am negative confirm and therefore please send me a link to the carry page
No, it’s not.So yes affirmative that i am negative confirm and therefore please send me a link to the carry page
Carry and BlinkBox being technically (does a heavy lifting here calling it middleware) between the caller and an API does not put them on the same level of middleware.
That’s like saying moon dust is technically cheese because both are made of atoms.So yes affirmative that i am negative confirm and therefore please send me a link to the carry page
Carry is literally just the self contained persistence implementation that exposes an array of functions.So yes affirmative that i am negative confirm and therefore please send me a link to the carry page
While reworking the docs after your replies I found a real bug, thanks! Nothing dangerous, a type-checker error in the generated code, fixed.
Why use it over basic buffer logic? Hand-written buffer code is a fine option and can be just as fast. The difference is one line:
Data: struct { Target: Instance(Humanoid), Amount: u8(1..100), Note: string(0..32) }
That line is the class check, the range check and the length check before the read, on every packet, with the same layout on client and server. By hand you write those in every remote.
OOP: the generated module has none. It’s locals, functions and buffer.* calls, no metatables. There’s now a test that fails if one ever appears, and a docs page that shows the generated reader next to a hand-written one: Compared with hand-written buffers | BlinkBlox
Benchmarks: agreed, speed isn’t the reason to pick it. They’re there to compare tools that do the same job and to keep a release from getting slower than the last one. I’ve cut them down in the README.
The offer still stands for anyone who wants to throw packets at it.
But it isn’t, what I wrote is literally a direct communication to Remotes/Data Store API, having a module do any part of that is by definition Middleware.
Yes… Middleware functions which interact with the Data Store API, e.g. you have GetAsync, SetAsync and UpdateAsync functions inside of the module which are called by said functions.
The user calls WorkerInit, to then Carry interacts with the Data Store API to setup the necessary data, a direct communication would be the user interacting with the Data Store API directly.
what user?
There is no users
Only developers.
Also you should not be doing that.
You are just saying nonsense on so many levels.
That’s being pedantic.[1]
???
Then what is this supposed to be?
of, relating to, or being a pedant (as in being overly concerned with minor details) ↩︎
Ahh… Even tiny AI models reasons better lol. Just saying…
I don’t post release updates here since I don’t really see the point, but the project isn’t abandoned. I fix bugs as I find them and use it myself to develop my own games.
The offer still stands for anyone who wants to throw packets at it.