Hi. Sorry for not responding. The cause of this error was caused by me. Also could you make it warn which script which requires warp is yielding? im currently having a hard time debugging
I might be wrong, but I donât think you can detect that.
The only way youâd be able to do that is warning in every script youâre requiring it, before the line it requires.
if u asking which functions that yields then its
-- yields
Warp.Client(...)
Warp.fromClientArray(...)
Event:Invoke(...)
Event:Wait()
Event:Fires(...) -- short yield
Event:FireExcept(...) -- short yield
I couldnât initially identify the root cause, so I decided to redo the transition from RemoteEvents to Warp. The issue has been resolved, and everything is functioning smoothly now. Appreciate your module!
its not possible to make like this.
hey could you also add the FiresWithDistance function i suggested, i hate having to readd every update
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.0.7
- use
--!optimize 2
- replaced
string.pack
tobuffer
instead - 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?
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)
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.