Strictly-Typed(Warp is written with strictly-typed for better typing, unlike FastNet2)
Rate Limit(Warp & FastNet2 also have rateLimit but Warp have better rateLimit system without sacrifice any performance with better configuration)
Performance(Warp have better performance than FastNet2, up to 40%)
Efficient(Warp might have better system management to make it more efficient)
Smaller(Warp have ~5.5% (2 bytes) less overhead network bandwidth over FastNet2)
Structure(Warp is way more structured than FastNet2)
Limitation(Warp allows you to connect a event more than one unlike FastNet2)
Flexibility(Warp is slightly flexible compared to FastNet2 like on firing a event with reliable or unreliable without require to creating another event)
Order(Warp have better queue management over FastNet2 to make it more optimized)
Modern Serialization(Warp use new serialization that use buffer over string.pack)
Middleware(integration with a middleware feature to validate incoming packets)
Small(Warp is more light over FastNet2 on their size)
Test Benchmark
(*Note: for packet size counter using Packet Profiler Plugin)
Could you please provide examples and short usage guides on the main post? Also you make a lot of claims why to use this over FastNet2 and provide statistics without any evidence, it would be nice if those could be provided!
Also your documentation page is a work-in-progress entirely, you should consider providing usage here and finalize the documentation page as currently it is up to reading the source code to figure it how to use this as intended.
Reading the source code even further I realize there’s a few files that seemingly haven’t been tested, did you post this without proper testing? Why have you made your own Assert module instead of just using the built-in assert?
I agree,as no evidence of these claims and features,I wouldnt use it without seeing the Test evidence and features that are being claimed are there,so for now I wont use it just till I see Evidence of these claims.
hey, you should add 2 more functions ConnectEventClient and ConnectEventServer the server one connects any event that is created in a server script then you can listen to it the client connects any event that is created in the client then listen it, it would make the module easier to use.
implemented Warp on my other games to send strings as messages like a:fires(‘hi’) got this err:ReplicatedStorage.Warp.Index.Server.ServerProcess:156: attempt to get length of a nil value - Server - ServerProcess:156 *also i cant pass on the script since i have many scripts that are connected to the same events. as for the other events they do nothing so its a issue with the module.
my question for this is what was the motive behind creating it? I see you already created two networking libraries. whats the point of making a third one? does this library depreciate the others?
make sure you have read the documentation site, on :Fires you have to add reliable argument before you given the data arguments like this :Fires(true, ...) if it true then it use reliable or else.
I agree with this sentiment, why not just update one of the other ones to be more optimized instead of making a new one to deprecate an older one? It makes it harder for developers to quickly switch over to a better system since they’d have to fully change it in their workflow.
update fixed the issues in my bot game , but still my render cant retrieve colours.
besides from the chat bit i think it got confused since there’s a server connected to it, client connected and another client. its created in one client script then accessed by the others server and client how do i control the flow of the event? shall i use the rateLimit?
