It’s probably faster and easier if you just do a wrapper that relies on his module, so you don’t need to re-add it when he updates, you’ll have to overwrite the module inside it with the updated one.
It’s just a suggestion though.
1 Like
1.0.7
- use
--!optimize 2 - replaced
string.packtobufferinstead - updated graph benchmark
note: pushing update to github seems not updated correctly, i suggest use .rbxm file instead
Hello, thanks for sharing with this networking library, I really liked the API and how simple to use it but unfortunately I faced into a problem when ping for our players was constant 1000ms+. When I removed Warp and replaced with default remotes it came back to normal (No network request spamming was in our scripts). Any idea why it happened? Ratelimits was set and we only used Warp in our clan system (other systems was not updated to Warp and still utilize default Remote instances) where network requests is not being used often. Our 2/3 were affected to this weird network latency (3rd game has not used Warp). Version that was used is 1.0.6.
Maybe if I share our client/server code with you in PMs will help you a lot, just inform me.
PS: Also it was fine in testing, problem only appeared after Warp was under use of 100+ players experience
interesting, could you sent your code in pm? also could u do scriptprofiler? did u use :Fires function on server?
1 Like
Not sure what I should do with scriptprofiler. I haven’t used Fires, primary used Invoke() function but I suppose it may be caused by the long timeout that I pass into arguments (10 seconds usually), can’t blame datastore that was used in system since our game spend this budget wisely. Sent you a file in PMs!
Sadly, but I can’t reproduce this problem (We removed Warp from games at the moment) since it only appear on server with a bunch of players 
(I can’t risk our players)
you can use script profiler to know what script that on heavy or the most load (%) on server and client, warp in PostSimulation category.
1.0.8
(1.0.8 - release updates not available on wally package but there version 1.0.8 on wally, its 1.0.8 pre-release not release version.)
Info
Warp are efficiently runs on over or higher 100 players, but Invokes seems not optimized for large-scale, this is unknown to be optimized to runs efficiently on large-scale.
The ids broke for me when moving from 1.0.7 to 1.0.8, I got it back to work by adding:
self.point += 1
In line 74 of the Dedicated buffer module:
function DedicatedBuffer.wu8(self: any, val: number)
DedicatedBuffer.alloc(self, 1)
writeu8(self.buffer, self.point, val)
self.point += 1 --// Added this back from 1.0.7
end
For details, what was happening for me is that all events had an empty string as id which caused all of them to fire whenever I tried to fire a single one.
I honestly do not know much over how buffers work yet, but I will be using it with this temporary fix for now, let me know if there was a deeper reason behind removing that line of code. 
that seems to be a mistaken when cleaning up.
Yeah…
I just added Warp to my codebase and was wondering why it was firing all the events. It looks like i’ll switch to 1.0.7 temporarily until it gets fixed.
If you want to use the 1.0.8 you can also just change the “Dedicated” module inside the “Buffer” module to this: (It’s not an official fix, but it fixed it for me)
--!strict
--!native
--!optimize 2
local DedicatedBuffer = {}
DedicatedBuffer.__index = DedicatedBuffer
local create = buffer.create
local copy = buffer.copy
local writei8 = buffer.writei8
local writei16 = buffer.writei16
local writei32 = buffer.writei32
local writeu8 = buffer.writeu8
local writeu16 = buffer.writeu16
local writeu32 = buffer.writeu32
local writef32 = buffer.writef32
local writef64 = buffer.writef64
local writestring = buffer.writestring
local default = {
point = 0,
next = 0,
size = 128,
bufferSize = 128,
}
function DedicatedBuffer.copy(self: any, offset: number, b: buffer?, src: buffer?, srcOffset: number?, count: number?)
if not b then
copy(create(count or default.size), offset, src or self.buffer, srcOffset, count)
else
copy(b, offset, src or self.buffer, srcOffset, count)
end
end
function DedicatedBuffer.alloc(self: any, byte: number)
local size: number = self.size
local b: buffer = self.buffer
while self.point + byte >= size do
size = math.floor(size * 1.5)
end
local newBuffer: buffer = create(size)
copy(newBuffer, 0, b)
b = newBuffer
self.point = self.next
self.next += byte
end
function DedicatedBuffer.build(self: any): buffer
local p: number = self.point
local build: buffer = create(p)
copy(build, 0, self.buffer, 0, p)
return build
end
function DedicatedBuffer.wi8(self: any, val: number)
DedicatedBuffer.alloc(self, 1)
writei8(self.buffer, self.point, val)
self.point += 1
end
function DedicatedBuffer.wi16(self: any, val: number)
DedicatedBuffer.alloc(self, 2)
writei16(self.buffer, self.point, val)
self.point += 1
end
function DedicatedBuffer.wi32(self: any, val: number)
DedicatedBuffer.alloc(self, 4)
writei32(self.buffer, self.point, val)
self.point += 1
end
function DedicatedBuffer.wu8(self: any, val: number)
DedicatedBuffer.alloc(self, 1)
writeu8(self.buffer, self.point, val)
self.point += 1
end
function DedicatedBuffer.wu16(self: any, val: number)
DedicatedBuffer.alloc(self, 2)
writeu16(self.buffer, self.point, val)
self.point += 1
end
function DedicatedBuffer.wu32(self: any, val: number)
DedicatedBuffer.alloc(self, 4)
writeu32(self.buffer, self.point, val)
self.point += 1
end
function DedicatedBuffer.wf32(self: any, val: number)
DedicatedBuffer.alloc(self, 4)
writef32(self.buffer, self.point, val)
self.point += 1
end
function DedicatedBuffer.wf64(self: any, val: number)
DedicatedBuffer.alloc(self, 8)
writef64(self.buffer, self.point, val)
self.point += 1
end
function DedicatedBuffer.wstring(self: any, val: string)
DedicatedBuffer.alloc(self, #val)
writestring(self.buffer, self.point, val)
self.point += 1
end
function DedicatedBuffer.flush(self: any)
self.point = default.point
self.next = default.next
self.size = default.size
self.buffer = create(default.bufferSize)
end
function DedicatedBuffer.new()
return setmetatable({
point = default.point,
next = default.next,
size = default.size,
buffer = create(default.bufferSize)
}, DedicatedBuffer)
end
function DedicatedBuffer.remove(self: any)
self:flush()
setmetatable(self, nil)
end
return DedicatedBuffer.new :: typeof(DedicatedBuffer.new)
2 Likes
I do know why you & others ping are so high,
it’s because of warp speeding up everytime a player joins so basically it runs another event of what you send to double the speed which is doubling the ping every time a player joins, and this can cause multiple things to happen like for example if u sent a text containing ‘hello world’ with 1 player in the game it wil send, but with 2 players it would duplicate like this ‘hello worldhelloworld’ or it can get messed up and print ‘hhheeellooworroldd’.
id recommend to use a networking library that doesnt rely on the players for performance.
Like which?
I was initially thinking this is the go-to networking library for low ping and bandwidth because it was better stats than the other libraries. But after experiencing the bug with 1.0.8 literally firing every single remote, it suggests that this library may not be tested, and therefore this library may not be reliable.
1 Like
I’m going to switch to a different networking library until this becomes more reliable.
I first used version 1.0.8, but it is broken. When i called event:Fire(), it fired to every single event, not just the event i wanted it to.
Then, I switched to version 1.0.7, and it had 2 warnings in Script Analysis:
The thing is that both of these issues could have been avoided if the creator actually took some time to test the module, and take a look at script analysis before publishing the update.
Reliability is more important than performance.
1 Like
you can update with new patch to fixes this, and 1.0.7 that u shown is just a type issue where it fixed on 1.0.8.
if you cant found .rbxm file, click here to download directly.
1 Like
I know, but the problems are too frequent. You made a patch in 1.0.7 to introduce another bug in 1.0.8
Please test it yourself before releasing a patch. I want to be able to update my libraries without worrying about whether it will work or not.
2 Likes
I fully agree, this bug was a very clear message to us, users, that this is not being tested thoroughly before release, which is a huge source of distrust.
I like using this library, but I might need to keep it to the side until it gets reliable enough to be used in production efficiently, regardless of player count.
For now I will be using something else while keeping an eye on the progress here.
5 Likes
What are you using in the meantime…?
I downgraded to 1.0.6
How did you notice the remote duplication? I haven’t seen any of it as of yet.