LB Connection v2.3.0-beta - a module that offers an alternative to RemoteEvent, RemoteFunction, BindableEvent, and BindableFunction in Roblox Studio

Thank you for the suggestions you provided. I will take them into consideration and work to optimize the module.

thanks for making this module really appreciate ur effort!

1 Like

OMG, This is the best thing that has ever happened to me on the devforums!
:pray:

1 Like

v2.2.0-beta

  • New syntax for the functions of LBConnection.RemoteEvent, LBConnection.RemoteFunction, and LBConnection.Bindable. The object itself must be passed as the first argument when calling these functions
  • LBConnection.RemoteEvent:FireDistance function has been updated to search for the character’s PrimaryPart instead of the character’s HumanoidRootPart. This change is made to prevent any issues with custom rigs
  • New method has been introduced for yielding LBConnection objects
  • Each time an object is created, the functions within the object are no longer anonymous functions. Instead, they are derived from named functions
  • The code structure has been optimized for better efficiency and readability

I am currently contemplating renaming LB Connection. If any of you have a suitable name in mind, please feel free to share it with me :>

idk the first thing that came to my mind was “reflux” idk y did i even think about that

That sounds like a good idea. It reminds me of the medicine lol

v2.2.1-beta

  • A new approach has replaced the current method of yielding LBConnection objects.
  • The issues with LBConnection.GetRemoteEvent, LBConnection.GetRemoteFunction, and LBConnection.GetBindable not yielding when the LBConnection objects are not found have been fixed.

V2.3.0-beta

  • Removing LBConnection.Bindable
  • Adding LBConnection.BindableEvent and LBConnection.BindableFunction
  • The LB objects types have been altered
  • Minor optimization has been implemented

I have problems with the remote events, no errors, no warns, the event is being fired correctly on the client, the callback connection is established but the call never reaches the callback

image

I did a quick test on client-to-server communication using LB Connection, and I’m certain that there should be no issues with the callback connection. Would you be willing to share your client code for further analysis?

Sure!, It’s a part of my framework therefore I’ll share that in a private message, but I plan to open source it but first I need to be sure I got rid of bad practices

Not creating a new RemoteEvent object is actually bad, as this can overload a RemoteEvent depending on the game network usage. Apart for that, everything you mentioned actually makes code readability worse. The need to use :FireServer and :FireClient is for telling who is reading that you are communicating to another end, apart for :Fire that is used on Bindables for telling you’re communicating inside the same machine (local events vs remote events). Removing this “Server” or “Client” of the syntax just makes things worse and more confusing. Overall, your code is just a slower version of RemoteEvents using all the bad practices you could for a networking module.

1 Like

Please note that the current version of LB Connection utilizes multiple remote events, and the message you are responding to pertains to version 1.0 of LB Connection. Additionally, LB Connection employs a method of queuing packets to the next frame, ensuring that all packets are sent every frame to prevent traffic overload. (A reminder: Roblox also employs a similar approach in networking, but I chose to implement it independently to ensure network stability).

In my personal opinion, I don’t believe that :Fire would compromise the readability of communication. In fact, it offers a convenient way to invoke the function since we already know the destination of the packet(s).

I concur that my code might have a tendency to slow down the bandwidth, as it prioritizes functionality over performance. Consequently, I am presently in the process of developing version 3.0 with a new name, and it will be geared towards optimizing performance.

Another important point to highlight is that a single remote isn’t inherently problematic. When multiple packets are sent over the network in quick succession, they are consolidated into one packet, a feat that multiple remotes cannot achieve. The only potential drawback could be the transmission of an additional argument and string through the network. Nonetheless, this approach remains superior to using multiple remotes, as it significantly reduces the number of bytes when sending multiple packets simultaneously.

Great work! I’ve done some testing and I already seem to prefer using your module over the standards provided by Roblox.

One Issue I’ve come accros is the Code Syntax.
Overall, the module is very strong in terms of providing a safer ground to maintain memory-leaks and seems to have an overall lower latency; Especially with the usage of Rate Limits (Which I love by the way)

Coming back to the code syntax issue, the main reason I think this module won’t stick out too much as a really useful ressource is because the syntax of the module can be rather difficult to understand for beginners…

Overall, I haven’t had any code-related issues using the module; and I believe that’s also the case for the majority of the other users of the module. Keep it up! :smile:

1 Like