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!
OMG, This is the best thing that has ever happened to me on the devforums!
v2.2.0-beta
- New syntax for the functions of
LBConnection.RemoteEvent
,LBConnection.RemoteFunction
, andLBConnection.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
, andLBConnection.GetBindable
not yielding when the LBConnection objects are not found have been fixed.
V2.3.0-beta
- Removing
LBConnection.Bindable
- Adding
LBConnection.BindableEvent
andLBConnection.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
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.
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!