What is the purpose of creating a remote event wrapper? I keep hearing that it’s better because it solves messy hierarchy trees, version control, and name dependencies but wouldn’t you need to memorize all the remote names? You would need to go back into the code and find the correct name in order to fire the correct event so wouldn’t this just defeat the whole purpose of name dependencies. I also know that some networking libraries like ByteNet group calls and compresses data but I don’t need that right now. I’m just wondering on why simple 50 line wrappers are so useful.
Well, having a ton of RemoteEvents doesn’t seem very pleasant as well, it makes everything very hard to work with. That’s why people go for event wrappers or network libraries, it organises everything so well and is quite easy to use, I also use network libraries sometimes because it keeps everything so tidy.
You don’t have to, I think you can keep them in a module and just require that module from the serverside and clientside, keeping everything in place.
It’s really to personal preference, but I find using wrappers and libraries way easier than huge heirarchies.
How should I handle bindable events? Networking libraries dont have bindables events but thats just cuz theyre for networking. But if we use both bindable instances and code based events then wouldnt it get messy? Should I then create a wrapper for bindables?
Use a Signal implementation for bindables.
In most cases it was made to secure remote events with cryptography and optimize them with buffering, like this.
theyre really only useful if youre working with rojo. if youre just sticking to roblox studio, good project organization already covers everything those wrappers do, and usually better. the ones that convert data into buffers can have some use, but that’s not something the average game really benefits from.
Would this be similar to the remote wrapper? Create a module that has functions to create or retrieve signals using a signal module?
Remotes are used to communicate from Server ↔ Client. They were referencing Signal implementations that act similarly to BindableEvents (which are not the same). You can also make a module script that stores signals for other scripts to view, but for clarity I will only be talking about RemoteEvent wrappers.
Because you said that you don’t care about compression, in your case, RemoteEvent wrappers are useful because they let you access Events that communicate from the client to the server from one point. (More about why this is better later)
But the main selling point of RemoteEvent wrapper modules found on the DevForum is the compression (like you mentioned) and the amount of RemoteEvents they use. This helps with the bandwidth altogether. Because the libraries that do compress the data typically ask you to define what types you pass in advance, people tend to put all the remote events declaration in a big RemoteEvent handler.
Claims from Blink:
Memorize? Not really, it’s the same thing as changing the name of a RemoteEvent. This is exactly why people do RemoteEvent wrappers because it makes it easy to reference the same RemoteEvent without needing the path to it (e.g RemoteEventHandler.Event1 instead of game.ReplicatedStorage.Events [...]). I would argue it’s easier to do the first way!
If you’re trying to make a game and want to structure it correctly, having a RemoteEvent handler will make it less confusing and more structured. I highly recommend you doing it this way, especially if you’re working with groups of people.
But know that RemoteEvent wrappers found on the devforums actually do more than the simple implementation shown in the video, and you should get familiar with them.
you better have multiple remote events.
If you have one then you have to pass some unneeded “bloated” arguments always
How do I implement signal implementation is what I was asking. Is this just like a remote wrapper but for bindables? Is there any documentation of this I can look at.
How can making a folder to store remote events be complicated? ![]()
Any of these libraries is just a pure cope.
Organize stuff yourself, and don’t give up power when you actually need it.
If you need to compress non-user-generated data, then your code is the problem to begin with.
You should have logic all static when it involves no user input. Also, yes, regular remote events usually require static logic entirely, like sending coordinates simply could be written as a signed 32-bit integer inside a buffer; minimal validation is required for this kind.
Do not use that; it’s a scam and a very huge lie.
In fact, you should never make any kind of “signal” based in your game that involves no modding or loadable content.
BindableEvent is only for sandboxing/cross VM communication.
Yarik. The dev forum is not to display your ego and to share your conspiracy theories. These modules have been documented to be a great help to performance and with code structure. I would greatly appreciate if you could help answer my questions instead of spreading misinformation. Thank you
While I agree that wrappers aren’t necessary for the majority of cases, could you explain this take? BindableEvents are used for scripts on the same side to communicate between each other via an event-based system.
Perhaps I am misunderstanding your usage of this, as I haven’t watched the full video that you’ve linked, but I would only recommend using wrappers if it solves a direct problem that you face that there isn’t already a native solution for. So then, I would ask, what issues are you trying to solve?
Harassment and slander of me were absolutely not necessary and are a direct violation of terms of service.
Guess what is also well documented (by me even)? Bytecode!
And guess what you can find by that? That these libraries 99% absolutely suck at perfomance.
![]()
Do not attack the hand that offers help next time. ![]()
You should never* use them as well as any “signal” behavior not from the Roblox API.
*BindableEvent can be used to communicate cross-VM via parallel Luau or sandboxed models, but that’s where their sane use cases end; everything beyond that is a critical hit on performance and readability.
There’s going to be signal behavior if you’re doing anything between multiple scripts, whether it’s parallel or not, unless you use modules. I don’t understand how this would be an issue in most cases either. The only time that performance concerns should arise are if you’re doing something in a loop or if you’re doing a huge thing all at once. I’ll admit that it’s rare that you would need this, but it’s not as though it’s unusable.
I’m honestly a bit confused about the purpose of this entire topic, considering that native solutions work best in most cases. Is there a specific system or architecture that we’re trying to optimize here?
I honestly don’t know either what exactly OP is trying to accomplish, just warning him about half-truths people say.
Having cross-script communication in a non-modular game that has all content static is the problem to begin with, honestly.
If you don’t write big scripts of logic (although you should in most cases), you can use module scripts to share references to a function you call.
Signal behavior only makes sense when you have deferred parallel logic that takes time to compute and may yield.
Saying that from pro optimization and pro bare metal simplification point as always.
I am currently researching on the best way on how to structure my code as I’ve struggled with this in the past. I just want to know what is the benefits on using remote wrappers besides saving bandwidth and how it can make coding easier which was already answered. Now I’m confused on how to deal with bindables since remotes are now handled by scripts and I don’t want to split communication with instances and code. I want to know how to add Signal implementation mentioned by creaco for cross script communication.
Unless you’re doing something rapidly or have a complex type of architecture, I personally don’t see much use in a generic wrapper. This sort of optimization would already occur as you’re writing the code for it.
I would say that “it depends.” I think it would be best to go as bare bones as possible for most cases as it reduces complexity and points of failure. If you’re trying to create a more complex system, then I would plan around that system specifically, in order to maximize optimization/performance.