From the admittedly small research I’ve done, it seems like you limit how many requests / receives remotes can send / get, thereby improving performance. Wouldn’t this be an issue for games that require precision? For example, if there are too many events going on in a shooter game, and you try to fire your weapon, that action would be delayed until there is less traffic?
I don’t mean to say your work is bad, it seems impressive, but it’s just a question I have.
There is the option to limit the rate at lower fps, yes. However, Roblox already does networking at 60 Hz- so capping it at 60 results in little to no additional latency. No events are queued or deferred, or limited.
Alright, thanks for clarifying.
Insane networking library! It’s really easy to rewrite current network scripts using BridgeNet as it does not require hard configuration.
oh sorry for that, i meant to send it in another thread
I’m currently working on a custom NPC system that doesn’t use humanoids and only has 1 part to represent the enemy NPC for ray projectile hit reasons, I’m also using dot product & raycasting on the server to see if the NPC is in the player’s view so they can send data packets to the client. However, when there’s 70+ NPCs, receivedNetwork & ping increases. I feel like the reason why receivedNetwork is increasing is because of Roblox’s physics replication, while ping is because of the amount of data the packets have.
NPC Data packets are sent 20 times per second (1/20) to improve network bandwidth.
I’m also thinking of making “CFrame physics” to anchor the NPC’s hitbox to prevent Roblox from using physics on that part.
I’ve been wondering if BridgeNet can optimize these replication steps above tremendously?
Thank you!
So sorry for the late reply.
Yes. BridgeNet is literally designed for use cases like that. However it’s important to note that the reason ping is increasing is most likely due to server fps- as ping is directly tied to fps. If your server frames are 30 fps, ping will increase substantially. Your server should never drop below 60fps.
No problem with late replies, take your time;
My NPC has a FindTarget and Fire Projectile function.
Each player has their own visual remotes, which the NPC will be using to replicate their bullets.
The target function simply gets the closest target on a specific table, the table doesn’t use workspace:GetChildren() per frame to get the targets on the table but simply a connection.
Fire projectile function fires projectiles in which will send a projectile data (table) via a RemoteEvent to clients for replication the server uses BindableEvent to communicate with eachother, again, sends the projectile data to the server projectile handler.
What do you think the reason why the Server’s FPS drops below 60 FPS with the information above?
Firstly: Switch your BindableEvents to GoodSignal. Might yield a better result.
Secondly: You can find this out yourself! Use the server microprofiler (F9, microprofiler)
If 2 server scripts require the same module (GoodSignal), will the module return the same Signal?
I’m using a Signal module already, it’s for firing the BindableEvent which sounds really unoptimized.
If you mean storing a constructed signal in a modulescript, then it should.
Is it possible to fire remotes from inside a module script?
Fundamentally, there is no difference between a ModuleScript and a script, except for the fact that a module can return a value. I haven’t used BridgeNet yet, but whatever can be done with Scripts/LocalScripts, can also be done with a module.
First of all, great module man I appreciate your work, and keep it up!
I came across 2 errors tho 
At line 727 in ‘ServerBridge’ self.Name seems to be nil (This caused Bridge:Destroy() to error)
serdeLayer.DestroyIdentifier(self.Name)
Fix
serdeLayer.DestroyIdentifier(self._name)
I’ve checked the key inside of receiveDict and sendDict and they both match up the self._name string so this should do.
The second error is caused by any ‘bridge’ being invoked with ServerInvoke/InvokeServerAsync from a different client.
ReplicatedStorage.Modules.BridgeNet.ClientBridge:125: invalid argument #1 to 'spawn' (function or thread expected)
Stack Begin
Script 'ReplicatedStorage.Modules.BridgeNet.ClientBridge', Line 125
Stack End
On line 120 in ‘ClientBridge’ at the elseif statement, ‘threads[uuid]’ seems to be nil for clients that did not invoke this bridge. I’ve implemented this as a simple fix although I’m unsure if this would break/ cause problems for anyone else.
local uuid = args[2]
if threads[uuid] then
table.remove(args, 1)
table.remove(args, 1)
argCount -= 2
task.spawn(threads[uuid], unpack(args, 1, argCount))
threads[uuid] = nil -- don't want a memory leak ;)
end
Don’t know how you tested it, but read the reviews on the main post. In my case BridgeNet reduced the ping 30x. This has tons of practical uses, I personally used it for waist C0 replication to server, which would be literally impossible to do without bridge net (Or it would cause the ping to be 3k+, as my tests showed).
I’m interested - what changed in your replication data? If possible, could you use my plugin to check out the differences before and after using bridgenet? https://devforum.roblox.com/t/packet-profiler-accurately-measure-remote-packet-bandwidth/1890924
I’m mainly curious since I also replicate C0 data for player head rotation, and am interested in what kind of optimizations are taking place.
So this is the code I was using without bridge net. For my game’s purposes I needed the rotation to be replicated exactly to the server, not just to other clients, + even if I replicated to other clients only, ping results would be the same if not worse.
So with this code the ping was 3K+ if there were 100 players on the same server
I only changed the repEvent:FireServer line with firing a BridgeNet remote, and on the server listening to that BridgeNet remote, nothing else changed. The ping dropped down to on average 100 ping with 100 players on the same server.
I’ve also had this problem before but managed to fix it by doing
Add task.wait() before creating a bridge.
Thanks for the report! I’ll definitely fix this in the next version alongside a bunch of other changes.
OMG, this is a fantastic module. Saved me a ton of time