Warp - very fast & powerful networking library

Resources Community Resources
, , , ,
#153

ok ill look into my own code.
#154

v1.0.6

#155

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 :frowning:

#156

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.

#157

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
#158

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!

#160

its not possible to make like this.

#161

hey could you also add the FiresWithDistance function i suggested, i hate having to readd every update

#162

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
#163

1.0.7

  • use --!optimize 2
  • replaced string.pack to buffer instead
  • updated graph benchmark

note: pushing update to github seems not updated correctly, i suggest use .rbxm file instead

#164

1.0.8 (pre-release)

#165

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

#166

interesting, could you sent your code in pm? also could u do scriptprofiler? did u use :Fires function on server?

#167

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 :frowning: (I can’t risk our players)

#168

you can use script profiler to know what script that on heavy or the most load (%) on server and client, warp in PostSimulation category.

#169

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.

#170

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. :sweat_smile:

#171

that seems to be a mistaken when cleaning up.

#172

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.

#173

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)
1 Like