Warp - very fast & powerful networking library

Resources Community Resources
, , , ,
#89

An absolute must-have for Warp is for Events to be connectable before they’re created on the server.

If I do:

Warp.Client(event):Connect(function(0
    print("Test")
end)

But on the server I do

task.wait(5)
Warp.Server(event):Fire(true, player)

The client won’t see anything.

Make it so if the client requests an event handler for a remote that doesn’t exist yet, they just can’t send out any messages but can wait for events to happen. Add the functions that are connected to a queue that are all fired once the event exists and is fired from the server.

This behavior is unexpected and unacceptable:

#90

why u dont just doing this

local Remote1 = Warp.Server(event)
-- usages
Remote1:Fire(...)

instead of calling .Server every calling Fire

#91

How is that unexpected? It’s a similar behavior to using a normal roblox event, as you’d need to wait for the event instance to be created before connecting to it.

The yielding is also beneficial in many scenarios, you can simply separate it to yield in a different thread if necessary.

I don’t mean to come out as rude (in case I might have), I just don’t understand how that is a “must-have”.

#92

I don’t think that’s what he’s complaining about.
From what I could understand, he wants the events to be possible to connect to in the CLIENT side, BEFORE the server creates them.
He doesn’t want it to yield his CLIENT code.
Although as I had said earlier, a simple thread separation could solve it already (not inside Warp, but on his script).

#93

I am currently using the old Network module by Tyridge. I want to switch over to Warp. Tyridge’s network module allows you to connect events on the client without it being initialized on the server yet.

To make the switch over to Warp, I can’t simply go into every script and change every Network:FireServer/FireClient and Network:BindEvents/BindFunctions to the Warp equivalent. Instead, I’m creating a wrapper around Warp using the same API naming scheme as Tyridge’s network module.

For example:

function Network:FireClient(player, eventName, ...)
    Warp.Server(eventName):Fire(true, player, table.pack(...)
end

function Network:BindEvents(connections)
    for eventName, connectionFunction in pairs(connections)
        Warp.Client(eventName):Connect(function(args)
            connectionFunction(table.unpack(args))
        end)
    end
end

This is also critical for other games that want to make this switch from Tyridge’s legacy Network module over to Warp module without editing every script. I want to hear what your suggestion is for people in situations similar to mine.

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

#104

i tested client to server, with a simple print statement it works but in my bot game when i send text of a textbox thru the event it doesn’t go thru since i put some print statements, i added a identifier to it but still doesn’t work , heres how i send it:

Warp.Server('ChatEvent'):Connect(function(player, message)

gets the chat from the client script

local ChatEvent = Warp.Client('ChatEvent',{
	interval = 0,
	maxEntrance = 9999999
})

then firing with this thing:

local chatInstance = TextBox.Text
		ChatEvent:Fire(false,player,chatInstance)


in the client side
also i name my things with instance but its not actually a instance it just sends text of a textbox.

then the strange thing is warp likes small stuff but back when i show my screen to roblox every screenshot every pixel every color is send thru warp and it can work with that so it would have like 15k strings stuff to send.

heres is a video

basically the game id box works fine and it sends the numbers in the textbox correctly but the chat box when i enter a message like hello then i click chat it and it does nothing but if it was working it would say send messaged.

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

#108

i removed the rate config from the client but why dont you change the part in ur docs with ‘while the client is diffrent’ to ‘the client cannot have rate config’ or smth . it would make people understand it better.

#109

lol i already did that i think its just your mistake