[ARCHIVED] Warp - very fast & powerful networking library

Resources Community Resources
, , , ,
#73

added new benchmark

sdjfnldjfnsdjigronethisok

#74

But is yielding the entire script intentional behavior?

#75

not all just the next line

ex:

-- this doing something and dont effect to the bottom yields.

Warp.Client(remoteName):Connect(func) -- yield/wait

-- next lines wont be runned until the yield finish

like ur using task.wait

1 Like
#76

I’m not sure why this happens. What is the reasoning behind that decision?

I mean, if the remote isn’t ready to connect or fire yet, I’d expect that to be explictly handled with a Promise, for example.

#77

promises is slow and its the rule where if the identifier not ready being used then u cant.

#78

I got a idea you should add logging and a option to use a thingy ‘GetClientEvent’ and ‘GetServerEvent’ to connect a event since it will probably be easier to use idk

#79

dont u can just do .Server(“eventName”):Connect(fn)?

#80

Your docs link is misleading/not working

#81

Github page link is incorrect (leads to a 404 website)

#82

The Github repo link is invalid.

#83

somehow my account just got locked down for suspicious activity login so i unlocked it back, the link will restored soon

Edit: my account flagged as spam, i already contacted to github support. hopefully accepted.

2 Likes
#84

Hey There!
I made a function called FIresWithDistance
^ – Fires data from server to all clients within a given distance

To use it
add this line of code in your types module script

FiresWithDistance: (self: Server, reliable: boolean, position : Vector3, Distance : number, any) -> (),

should look like this

image
image781×264 31.9 KB

Now Head to the Index module script located under server

and add this line of code

function getDistance(pos: Vector3, distance: number)
	local playersInRange = {}

	for _, player in ipairs(Players:GetPlayers()) do
		local character = player.Character
		if character and character:FindFirstChild('Humanoid') then
			local primaryPart = character.PrimaryPart
			if primaryPart then
				local playerPosition = primaryPart.Position
				local playerDistance = (pos - playerPosition).Magnitude

				if playerDistance < distance then
					table.insert(playersInRange, player)
				end
			end
		end
	end

	return playersInRange
end


function Server:FiresWithDistance(reliable: boolean, position : Vector3, Distance : number, ...: any)
	local PlayersInRange = getDistance(position, Distance)
	for _, player: Player in ipairs(PlayersInRange) do
		ServerProcess.insertQueue(self.id, reliable, player, ...)
	end
end

Example of usage

Warp.Server("Test"):Connect(function(Player : Player)
	
	
	local Position = Vector3.zero
	local Distance = 500
	local DataToSend = {
		"Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua."
	}
	Warp.Server("Test"):FiresWithDistance(false,Position,Distance,DataToSend)
	
end)

and if your reading this @Eternity_Devs add this to the next update :pray:t6:

#85

documentation & my github repos cant be reached (due flagged account status) so for temporary you can just download with just .RBXM file or use wally package instead, and if you need a help can contact me by reply post/me or private message.

#86

why is your github account flagged?

#87

no idea, wake up with this.

This text will be blurred

#88

suggestion could you add a LogTraffic function

#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).