Modular Remotes [Remote Events/Functions]

Resources Community Resources
#1

Introduction

Modular Remotes is a utility designed to modularize RemoteEvents and RemoteFunctions.

Managing a large amount of remotes can be a hassle at times, and because of this I created Modular Remotes, free for anyone to use!

This utility is designed for programmers who have experience with the following:

  • RemoteEvents and Remote Functions
  • Module Scripts
  • Object-Oriented Programming

What the system is

Modular Remotes is not a module on its own, it is instead a backend system for networking. This means that it is required to be setup inside of your place, the same as you would do with your own game internals. Although it is recommended to start off with this system from the beginning instead of porting over other systems.

Modular Remotes uses 2 remotes in total to function: A RemoteEvent and a RemoteFunction. All of the remote traffic that your game has will be routed through the 2 remotes that this utility implements.

Each Remote Module that you create is basically the same as having a RemoteEvent and a RemoteFunction mixed together.

This system is designed to be smaller than most other libraries that achieve similar things, but that is because it was made to be simple and easy to use, as well as heavily modifiable.

Before you read any further, if you want to understand a bit more, then load the asset into a blank studio and see how it works

Documentation

Client Module

-- OBJECT EVENT HOOKS
.ClientEvent(self, ...) --This is executed when the server fires the client
.ClientInvoke(self, ...) --This is executed when the server invokes the client
-- OBJECT METHODS
:Fire(...) --This will fire the server
:Invoke(...) --This will invoke the server, returning a value

Server Module

-- OBJECT EVENT HOOKS
.ServerEvent(self, Player, ...) --This is executed when the client fires the server
.ServerInvoke(self, Player, ...) --This is executed when the client invokes the server
-- OBJECT METHODS
:Fire(Player,...) --This will fire the client of the given player
:FireAll(...) --This will fire the clients of all players
:Invoke(Player,...) --This will invoke the client of the given player, returning a value

More documentation can be found inside the READ ME script inside the asset (see asset section)

Example Code

Test:Server (ModuleScript in Server Remotes Folder)

return {
	ServerEvent = function(self,Player,Text)
		self:Fire(Player,Text)
		print(Text," from ServerEvent")
		print(self:Invoke(Player,Text))
	end,
	ServerInvoke = function(self,Player,Text)
		print(self.TestVariable)
		return Text.." from ServerInvoke"
	end,
}

Test:Client (ModuleScript in Client Remotes Folder)

return {
	TestVariable = "Hello, world!",
	ClientEvent = function(self,Text)
		print(Text," from ClientEvent")
	end,
	ClientInvoke = function(self,Text)
		return Text.." from ClientInvoke"
	end,
}

TestScript (LocalScript in StarterCharacterScripts)

local Remotes = _G.Remotes --This is the global created by the client of Modular Remotes

Remotes.Test:Fire("Test!")
print(Remotes.Test:Invoke("Test!"))

Did you notice something in Test:Server? The module has access to TestVariable that is inside of the Test:Client module.

Modules on the server will inherit all of the methods and properties that are present in their respective client modules. But, the client module will not inherit anything from its server counterpart.

This example can be found inside the asset (see asset section)

Asset

Modular Remotes Asset

Version History

v0.0

  • Created and released
2 Likes
#2

Why would this be useful?

What makes your resource something that BridgeNet can’t do?

1 Like
#3

The resource is designed to be simple. The goal of the resource is to have all remote code inside of the remote modules you create, to help clean up other scripts in your games where you would leave the code for remotes. Although BridgeNet2 may be faster, with a lot more features, the point of this resource is to allow you to easily manage your remotes (for games with a large number of remotes).

The resource will get updates eventually, adding new and useful features to improve it.

Now, considering the resource is designed to be built directly into your game, you can modify it and have it use BridgeNet2, rather than what it currently uses. I guess I can say the resource is mainly for use as a starter template when designing the networking for a game.

#4

I still do not see the purpose of this? I’m not trying to be rude, but there really isn’t much point to this. For ‘large number of remotes’, there’s frankly no need for any of that as you can reference the specific event in BridgeNet.

1 Like
#5

One thing I see at the moment is that I couldn’t figure out a way to invoke the client using BridgeNet2. (It could be the build I was using, or maybe I wasn’t using it properly)

I made an example that invokes a player’s client, and the client will return the client memory usage to the server to be printed.

Using this resource, I can achieve the code for this on the client in 5 lines.

The server remote module for the remote is useless, and because of how the remote objects are created I do not have to create a server remote module to have it register the remote on the server.

GetMemory:Client (ModuleScript inside the Client Remotes folder)

return {
	ClientInvoke = function(self)
		return stats():GetTotalMemoryUsageMb()
	end,
}

This is the server code that requests the client’s memory

local Remotes = _G.Remotes
local Players = game:GetService("Players")

Players.PlayerAdded:Connect(function(Player)
	if not Player.Character then Player.CharacterAdded:Wait() end
	
	local Memory = Remotes.GetMemory:Invoke(Player)
	
	print(("%s has a total memory usage of %.2f MB"):format(Player.Name,Memory))
end)

If you were to use BridgeNet2, you would have to create the bridge on the server and the client yourself, with code. Using this resource, you just have to create respective modules for the server and the client (Like the example above, you don’t always have to have a server remote module)

This is just an example though, and from what I can see both have ups and downs (albeit, BridgeNet2 is most definitely better for optimization and speed)

#6

not supported as this is an antipattern https://www.youtube.com/watch?v=0H_xcA-0LDE

5 Likes