[ARCHIVED] Warp - very fast & powerful networking library

Resources Community Resources
, , , ,
#94

this is nice as i just literally switched from Tyridge (easynetwork)

#95

have u read this yet?

This text will be blurred

#96

It’s similar but not quite the same thing.

If you have a RemoteEvent instance on the client (assuming you didn’t create it in the client), you can already do everything with it and get reasonable results; you can fire, connect, etc.

In Warp, if you call .Client(), you’ll have something that looks ready but isn’t. This would be really simple to fix (it would require a major update, though); all that needs to be done is to expose a function that yields until the client is actually ready. You could technically do this already by connecting a dummy function, but that’s really ugly.

#97

I read that and understand your thought process.

However, what I fail to understand is why it needs to wait for the rate limit configuration. Wouldn’t it make sense to simply throw an error if there is no rate limit config and you try to fire to the server? Yielding the thread to wait for a remote to spawn when all I want is to queue up a function for an event that may not be created yet makes no sense

#98

its about security

sacrifice performance required

#99

bud did u forgot find/replace all option? or u even dont know if it ever exists??

#100

Replace all isn’t an option here because of the different format of API’s.

Setting up listeners for remotes in Tyridge’s EasyNetwork module is as such:

Network:BindEvents({
    EventName = function(player, ...)
        ...
    end,
    EventName2 = function(player, ...)
        ...
    end
})

Meanwhile Warp is as such:

Warp.Server(eventName):Connect(function(player, ...)
    ...
end)

Warp.Server(eventName2):Connect(function(player, ...)
    ...
end)
#101

How does it sacrifice performance when the thread would stop anyway

#102

its not about the thread

This text will be blurred

#105

bro rate limit configuration only allowed on server not client.

why u send player argument to server.

#106

Its because in the client script it prints out a message with who send the message so i can ban who ever says bad stuff on it.

#107

Hi, when will the documentation be available again?

#109

lol i already did that i think its just your mistake

#110

github is on high volume on processing support tickets.

#111

Warp | 1.0.4

  • Add .fromServerArray (to create new server events with arrays, without need to create each by each)
  • Add .fromClientArray (to create new client events with arrays, without need to create each by each)
  • Fix Duplicate possible on creating Warp Event (Internal)
-- Server
local Events = Warp.fromServerArray({
["Test"] = {
maxEntrance = 50,
interval = 1
}, -- with rateLimit
"Test2", -- without rateLimit
["Test3"] = {
maxEntrance = 10,
}, -- with rateLimit
})

Events.Test:Connect(function(...) end)
Events.Test2:Connect(function(...) end)
Events.Test3:Connect(function(...) end)

-- Client

local Events = Warp.fromClientArray({ "Test", "Test2", "Test3" })

Events.Test:Connect(function(...) end)
Events.Test2:Connect(function(...) end)
Events.Test3:Connect(function(...) end)

Get .RBXM from github
With Wally
Get Module (Roblox Creator)
Download .RBXM file - v1.0.4

#112

is the warp event with arrays have better performance then the regular warp event. Since iit wont be creating events for each screenshot, it would be alot faster.

#113

its the same (performance), it just make you easier and faster to creating events.

#114

When will the wally package version release for this?

#116

Good news! my github account just unlocked recently so now i can publish new version to github & wally!

Edit: new update version updated to wally & github, also repo & documentation is back!

Edit 2: Sorry for missing v1.0.3, accidently skipped v1.0.3.

Edit 3: updated docs for version 1.0.4

#117

Upcoming update in 1.0.5:

  • Cached incoming packets data for undefined events (aka event is not created yet on client), Once the client-side defined the event, that cached packets will processed as pre-process, This internal-feature for preventing potential packet-loss.