Maybe you might not need to use a Network module

All of the written below is my thoughts, if I’ve made a mistake please consider warning me to fix falses

Quick note: This post was made to show a way to use Remotes without any module interface is beneficial most of the time.

Of course, some modules might be useful for you; some of them might convert your data into bytes and split them into smaller parts to send them one by one to reduce data size. But you have to consider that you never gain something without losing anything. speed = data-size / seconds (v=m/s). At the end of the day, you have to wait for other parts of the complete data.

Before the RunContext property, we were not able to run client and server scripts in the same static directory, so this situation forced us to stack our events to ReplicatedStorage with certain names. But this technique was impractical, whenever we wanted to move our scripts to different places or wanted to publish them in ToolBox for OpenSource behavior, we also had to package them to make systems functional.

We(or at least I am) tried to create them on ServerSide and had to check them on the client side to keep our Systems clear and portable. This was the reason for me to make NetTS

I’ve used it many times before the RunContext property, which helped me a lot with portable Client-Client, Server-Server, and Client-Server interactions.

Thankfully RunContext came into our lives.
From now on we can package everything in one static directory that is required for a specific system.
Ekran Resmi 2024-03-06 05.48.16

Your program overflow can be like this

--game:GetService("....")
--game:GetService("....")

local System = script.Parent
local RemoteEvent = System.RemoteEvent
local RemoteFunction = System.RemoteFunction

local Remotes = {}
RemoteEvent.OnServerEvent:Connect(function(Player, event, ...)
	-- Possible Middleware can be placed here!
	Remotes[event](Player, ...)
end)

local FunctionRemotes = {}
RemoteFunction.OnServerInvoke = function(Player, event, ...)
	-- Possible Middleware can also be placed here!
	return FunctionRemotes[event](Player, ...) -- Be sure to not forget about the "return" statement here!
end

function Remotes.HelloWorld(Player, Paremeter1, Parameter2 --[[etc...]])
	print(`{Player.Name} said {Parameter1} and {Parameter2}`)
	-- Output would be like "Monotter said Hello and World" if I run `RemoteEvent:FireServer("HelloWorld", "Hello", "World")` on the client.
end

function Remotes.Multiply(Player, Number1, Number2)
	return Number1 * Number2 -- You get the idea!
end

I hope you’ve got the point. Just be sure that the module that you want to use solves a problem that you will be faced with. They have to be made to make our lives easier, not messier.

This post made no sense at all? You did not describe runcontext vs remotes at all, and your code posted doesn’t show anything of use?

9 Likes

I already don’t use modules in general.

1 Like

top 10 chat gpt devforum posts, I love how he goes from network to run context and then doesnt even elaborates on both.

4 Likes

It’s all my writing, what do you mean by saying that?

The title summarizes the content of the post. Also, what do you mean by “runcontext vs remotes”

Your post shows nothing of using runcontext, why we should use it verses remotes, nothing. It’s not a tutorial nor a resource.

  1. RunContext made us able to run client and server scripts anywhere inside the game.
  2. Without RunContext;
  • We can run server scripts only inside the Workspace, Player, and ServerScriptService (maybe some other locations too)
  • We can run client scripts only inside the Player and the Player’s Character
  1. So the only static path to use client and server scripts is the player and its character. Which is Tools and Guis.
  2. We want to have a static path to put client and server scripts together to have a portable system environment.
  • For example, after our project had more than 10 systems that had their own client and server scripts. It becomes harder to locate between those scripts and it becomes messier to store the system’s essentials(which can be but are not limited to models, values, modules, and remotes)
  • Without placing Server Scripts and Local Scripts inside a System Folder. We need to put them in separate locations. This method has some critical disadvantages; if I want to rename a system essential I have to rename every system essential since they are in different locations. If I want to make changes or bug fixes after a long time since not touching the script I have to search for its essentials which is an unnecessary waste of time.
  1. Most of the network modules fix this issue for only Remote essentials.
  • Using network modules on separated systems is practical. (But making a separated system is impractical)
  1. With the help of the RunContext feature, we can make joint systems like in the image that I’ve placed in the post.
  2. In joint systems not using a Network module is more beneficial most of the time.
  • Some modules
  1. I am showing the practical way of using Remotes within a joint system inside the code block.

EXTRA: of course, we can also make joint systems without RunContext but that requires an initial script to carry scripts to their environments. This is impractical and unbeneficial due to relocating scripts cuts our hands from practically accessing system essentials without specifying their location path inside the script.

I don’t think you understand what proper networking modules do. The purpose is not to split data into numerous events, but to compress the data before sending and to decompress it after.

For example, you can use buffers to quickly compact raw data (strings, base10 numbers, etc) into binary, which is much more compact. You then send the binary data over, where it is converted back to raw data on the other side to be read and used.

Networking modules are important and are essential in optimization.

1 Like