Sockets: A remotes alternative

Help and Feedback Creations Feedback
#1

Sockets

Overview

For a while now I have found that remotes just don’t cut it for me. They feel a bit unorganized and every game I create I find myself wasting valuable time deciding on the correct way to handle things. I often found myself repeating blocks of code and writing massive wait chains to ensure the remotes existed when I needed them.

To solve this I have created a system based off of socket.io which is a wonderful api that allows client-server communication.

I am always open to feedback and I would appreciate any you might have.

Source

The modules are available on GitHub and I’ve got a few updates planned to really perfect this module.

Description

Sockets is a module that serves as an alternative method of communication between the client and server on ROBLOX.

Updates

04/15/17

  • Groups - These allow you to group requests of similar purpose together.
  • Rooms - Clients can now be assigned to a room that you can send requests to.

Documentation

At a glance

Server

local sockets = require('server.lua')
sockets.Connected:connect(function (socket)

    local player = socket.Player
    print(player, "has connected")
    
    socket:Listen("Message", function (msg)
        print(player, "said", msg)
    end)
    
    socket:Listen("Double", function (n)
        return n + n
    end)
    
    socket.Disconnected:connect(function ()
        print(player, "has disconnected")
    end
    
end)

Client

local socket = require('client.lua')
socket:Emit("Message", "Howdy")
print(socket:Request("Double", 5))

Output

Player has connected
Player said Howdy
10
Player has disconnected
16 Likes
Remote Module - Public Release
#2

This looks interesting, can you provide sample client/server code to make it easier for people to evaluate?

#3

I’ll make a better example another time, but here is one of the uses I have so far.

sockets.Connected:connect(function (player, socket)
	
	socket:Listen("Party Find", function ()
		local party
		for i = 1, #parties do
			if #parties[i].Players < maxPlayers then
				party = parties[i]
				break
			end
		end
		if party then
			party:AddPlayer(player)
		else
			party = newParty(targetPlace)
			table.insert(parties, party)
			party:AddPlayer(player)
		end
		return party.Players
	end)
	
end)

menu.Clicked:connect(function (button)
	if button == "Join" then
		menu.Hide()
		party.Show()
		local members = socket:Query("Party Find")
		for _, player in pairs(members) do
			party.AddPlayer(player.Name, player.UserId)
		end
	end
end)
5 Likes
#4

and having a callback be the last parameter… I think I found a JQuery fan.

1 Like
#5

I feel like this topic has been questioned a lot but I’m an incapable searcher so I wonder if having multiple separate remotes is better than funneling everything through one master remote.

edit: found answer

#6

This hasn’t been an issue for me just yet. The module has an internal queue so that if a user isn’t hooked up to an event then it’ll wait until one exists.

Actually, I try to avoid it whenever possible. But yes, I have spent a lot of time working with it so old habits die hard I guess.

#7

I have just updated the module. Method/event names are now final and actually make sense. The documentation is much clearer (on GitHub) and I have added groups and rooms as planned.

I’ve got a small update on the way just to deal with dead sockets but that shouldn’t change much on your end.

#8

I’ve been using ModRemote by Vorlias to get rid of the fuss that comes with dealing with remotes so far,
but I’ll take a look at this for sure!

1 Like