Right now, I tested it, and at first it seemed to me that everything worked well, but in the end it turned out that now the scripts have changed places.
The one that worked - stopped working, and the other - vice versa.
Iāll send you the place file in a minute
Wow thatās pretty cool!
Say, how does it actually decrease bandwidth?
Iāve always wondered how that works with remote events.
How do you simply āreduceā what is send through a remote event?
Iāve been looking into things like how I can compress or reduce the size of numbers and Vector3 values but with little to no success.
Mind explaining how all of this works?
Iām actually surprised at the fact that a vector3 is smaller than sending over 3 numbers.
a cframe is also pretty small compared to a single number which surprises me by a lot.
How are cframes only 1 byte more than a vector3 despite having way more properties?
Why are booleans 2 bytes when itās literally just a value thatās only 1 bit?
This is because roblox uses newproxy()
internally, which is a lot smaller than regular tables.
Iād love to know more about this.
Iāve been looking into compressing or making data smaller when sending through remote events without relying on 3rd party libraries because I already wanted to write my own library and it cannot use code from other libraries so Iām looking into writing things from scratch and keeping it simple.
Slightly more lightweight than a table, and supports some meta-methods not supported on tables before it was removed again.
Source: Deduplicator
Note that the only unsupported metamethod was __len
, though it is now supported on all tables as of this RFC: RFC: Support `__len` metamethod for tables and `rawlen` function by zeux Ā· Pull Request #536 Ā· Roblox/luau Ā· GitHub
newproxy
was deprecated in Lua 5.1 (what Luau uses), and removed in Lua 5.2.
version 0.5.2: 7/15/2023
Improvements
- PlayerContainers now error if an incorrect amount of arguments is passed
Fixes
- Fixed a bug where referencing a bridge multiple times clearing connections each time
- Fixed a bug where the player loading before BridgeNet2 starts would never initialize the player
I was also looking for that, but couldnāt find it for v2 so I quickly cobbled together the d.ts from the existing luau types, havenāt checked it for errors tho
/// <reference types="@rbxts/types" />
type MetaMessage = "1";
type ServerConnectionCallback = (player: Player, content: Content) => void;
type Content = unknown;
type Identifier = string;
// Player containers
type PlayerContainerTypes = "all" | "set" | "except" | "single";
interface PlayerContainer {
kind: PlayerContainerTypes;
}
interface SetPlayerContainer extends PlayerContainer {
kind: "set";
value: Array<Player>;
}
interface ExceptPlayerContainer extends PlayerContainer {
kind: "except";
value: { [index: number]: Player };
}
interface SinglePlayerContainer extends PlayerContainer {
kind: "single";
value: Player;
}
interface AllPlayerContainer extends PlayerContainer {
kind: "all";
}
type PlayerContainerIndexes = {
All: () => AllPlayerContainer;
Except: (excludedPlayers: Array<Player>) => ExceptPlayerContainer;
Single: (player: Player) => SinglePlayerContainer;
Players: (players: Array<Player>) => SetPlayerContainer;
};
type ServerInboundPacket = {};
type ServerOutboundPacket = {
playerContainer: PlayerContainer;
content: unknown;
id: Identifier;
};
export interface Bridge {
Logging: boolean;
}
export interface ServerBridge {
Fire(this: ServerBridge, target: Player | (AllPlayerContainer | SetPlayerContainer), content: Content): void;
Connect(this: ServerBridge, callback: (player: Player, content?: Content) => void): Connection;
Once(this: ServerBridge, callback: (player: Player, content?: Content) => void): void;
Wait(this: ServerBridge, callback: (player: Player, content?: Content) => void): LuaTuple<[Player, Content?]>;
OnServerInvoke?: (player: Player, content: Content) => LuaTuple<[Content]>;
RateLimitActive: boolean;
}
export interface ClientBridge extends Bridge {
Fire(this: ClientBridge, content?: Content): void;
Connect(this: ClientBridge, callback: (content?: Content) => void): Connection;
Once(this: ClientBridge, callback: (content?: Content) => void): void;
Wait(this: ClientBridge, callback: (content?: Content) => void): Content | undefined;
InvokeServerAsync: (this: ClientBridge, content?: Content) => LuaTuple<[Content?]>;
}
export interface Connection {
Disconnect: () => void;
}
export namespace BridgeNet2 {
export function ReferenceBridge(name: string): Bridge;
export function ClientBridge(name: string): ClientBridge;
export function ServerBridge(name: string): ServerBridge;
export function ReferenceIdentifier(name: string, maxWaitTime: number): Identifier;
export function Serialize(identifierName: string): Identifier;
export function Deserialize(compressedIdentifier: string): Identifier;
export function ToHex(regularString: string): string;
export function ToReadableHex(regularString: string): string;
export function FromHex(hexadecimal: string): string;
export function Players(players: Array<Player>): SetPlayerContainer;
export function AllPlayers(): AllPlayerContainer;
export function PlayersExcept(excludedPlayers: Array<Player>): ExceptPlayerContainer;
export function CreateUUID(): string;
export function HandleInvalidPlayer(handler: (player: Player) => void): void;
}
version 0.5.3: 7/31/2023
Added
- A mock API for when BridgeNet2 is ran in edit mode. Limitations: InvokeServerAsync will infinitely yield, connections will never run.
Improvements
- BridgeNet2 nows prints the current version upon being loaded
- Improved output readability
- Potentially breaking: Bridges now are cached- this means you will have the same bridge object across scripts. This should be more expected behavior, and should overall be an improvement.
Fixes
- Potentially fixed some issues with loading and identifiers?
- Fixed a bug where referencing a bridge multiple times clearing connections each time (Except on the client this time)
Would this module assist in network-related memory usage as well?
Hi! Not sure if Iām just being a dumbo or something, but I keep running into this error when trying to fire a table to the client.
Hereās the code I am using:
--// ServerScript "Test" in workspace
task.wait(5)
local BridgeNet = require(path_To_BridgeNet2)
local Bridge = BridgeNet.ReferenceBridge("TEST")
Bridge.Logging = true
warn("Firing!")
Bridge:Fire(
{
[BridgeNet.ReferenceIdentifier("Hello", 10)] = 1,
[BridgeNet.ReferenceIdentifier("World_ExclamationMark", 10)] = 2
}
)
--// LocalScript in StarterPlayer
--there is no wait so the client should load before the bridge is fired
require(path_To_BridgeNet2).ReferenceBridge("TEST"):Once(print) --changing this to connect also results in the same error
This is using the latest version v0.5.3.
In the latest release, the module errors out.
Thereās was a commit for fixing the release. Could we get a new standalone release with this fix?
This has been fixed, I thought I replied here saying it was. I suppose I didnāt.
You should be able to get the latest standalone release and it should work.
You need to reference the identifiers before using them.
Also, the first argument on the server is for the player. Not the data.
Upcoming BridgeNet2 features
- Logging output will be recursive: you can see table contents of everything
- Logged stack traces when a bridge is called
- Identifier and middleware API overhaul
- Labeling connections in the microprofiler
- Logging specific connections (
Connection.Logging
property)
Thank you! I canāt believe I overlooked that.
It seems to work fine now that I actually inputted the player argument. I didnāt seem to have to change the identifiers since they started working when I plugged in the player, and the yield error was on my end. Turns out I had it backwards when yielding for the bridge.
version 0.5.4: 8/19/2023
Added
- You can now name connections, which will show up in logging and in the microprofiler.
- Calling script and line are now shown for connections and firing bridges
Improvements
- Type improvements
version 0.5.5: 8/26/2023
Fixes
- All coroutine.resume instances have been replaced with task.spawn. This fixes a lot of obscure bugs.