Simple(Warp has simply APIs & easy-to-use, no complex implementation stuff to do)
Typing(Warp is written with strictly-typed for better typing)
Rate Limit(Warp have better rateLimit system without sacrifice any performance with better configuration)
Performance(Warp have better performance optimized than FastNet2, up to 40%)
Flexibility(Warp is slightly flexible compared to other on firing a event with reliable or unreliable without require to creating another event)
Modern Dynamic SerDes(Warp use new serdes that use buffer over string.pack by default)
Performance Benchmark
Test Benchmark
(with Benchmarker Plugin)
(*Important Note: These benchmark are using the latest version and are using reliable event, the lower number is better, 250 iteration per attempt (total ~251 attempts per run), Specially for "BridgeNet2" here, it run separated because it always appearing bunch of errors and a bit lagging while on benchmark, which this affects to the benchmark results and "BridgeNet2" keep failing on this benchmark where it give result of 0 total packets received to bridge-event server listener.)
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.
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?
