ffrostflame/bytenet

An advanced, modern networking library for Luau/Roblox

bytenet's Issues

Consistent error when firing events on PlayerAdded.

In cases where you are firing events on PlayerAdded it is highly likely that the following error will be produced:

This seems to occur because perPlayerReliable[player]/perPlayerReliable[player] are nil.

I was able to fix this issue by making the following modications to the server module:

server.start:

[...]
local function playerAdded(player: Player)
	if not perPlayerReliable[player] then
		perPlayerReliable[player] = create()
	end
	
	if not perPlayerUnreliable[player] then
		perPlayerUnreliable[player] = create()
	end		
end

for _, player in Players:GetPlayers() do
	playerAdded(player)
end
Players.PlayerAdded:Connect(playerAdded)
[...]

server.sendPlayerReliable:

function serverProcess.sendPlayerReliable(
	player: Player,
	id: number,
	writer: (value: any) -> (),
	data: { [string]: any }
)
	if not perPlayerReliable[player] then
		perPlayerReliable[player] = create()
	end
	load(perPlayerReliable[player])

	alloc(1)
	u8(id)
	writer(data)

	perPlayerReliable[player] = bufferWriter.export()
end

server.sendPlayerUnreliable:

function serverProcess.sendPlayerUnreliable(
	player: Player,
	id: number,
	writer: (value: any) -> (),
	data: { [string]: any }
)
	if not perPlayerUnreliable[player] then
		perPlayerUnreliable[player] = create()
	end
	load(perPlayerUnreliable[player])

	alloc(1)
	u8(id)
	writer(data)

	perPlayerUnreliable[player] = bufferWriter.export()
end

CFrames sent from client to server have malformed orientation.

I am sending the client printed CFrame value to the server and then printing it server side. The value on the server side does not match the one the client sent.

Using Float64 type cause error. Float32 type causes slightly malformed number.

Float64 Error:

Float32 Error:

Packet type has invalid methods defined.

Packet type has method sendToList defined, but this method does not exist (should be sendToPlayers). It is also missing sendToAllExcept.

Corrected type:

type Packet<T> = {
	sendToAll: (data: T) -> (),
	sendTo: (data: T, target: Player) -> (),
	sendToPlayers: (data: T, targets: { Player }) -> (),
	sendToAllExcept: (data: T, except: Player) -> (),
	
	wait: () -> T,
	send: (data: T, target: Player?) -> (),
	listen: (callback: (data: T, player: Player?) -> ()) -> (),
}

struct's inside of array's are not typed correctly (ts)

For some reason, using a struct inside of an array causes the struct to need the value key when being declared.

ex:

export const reflex = defineNamespace("reflex", () => {
	const broadcastAction = struct({
		name: string,
		arguments: array(unknown),
	});

	return {
		dispatch: definePacket({
			value: array(broadcastAction),
			reliabilityType: "reliable",
		}),
	};
});

reflex.dispatch.sendToAll([{ name: "a", arguments: [] }]); // does not work
reflex.dispatch.sendToAll([{ value: { name: "a", arguments: [] } }]); // works

reflex.dispatch.sendToAll([{ name: "a", arguments: [] }]);
-----------------------------^^^^
Object literal may only specify known properties, and 'name' does not exist in type 'struct<{ name: ByteNetType<string>; arguments: array<ByteNetType<unknown>>; }>'.

`Packet:sendExcept` and `Packet:sendList` methods

Convenient methods to avoid writing for loops

Suggestion for even higher performance gains

Checking out your current encode/decode logic the system seems neat and could be relatively easily adjusted to drop the need for dynamically growing buffer object by allocating just the right size buffer.

I think this could be achived by adding new method to the dataTypeInterface<T> called size, which would then compute and return size of the value it represents.

Not only this would greatly speed up your encoding/decoding process, but also simplify the code by removing explicit memory management via bufferWriter.alloc which scatters dynamic allocations across the codebase.

This same idea could be also applied to the server and client queueing logic. Instead of appending the new packet's buffer to the pending buffer, keep all the pending buffers in a table, which will be your queue and then right before sending compute the total packet size, allocate one large buffer and copy each buffers content into the final buffer.

I use similar method in my Luau msgpack implementation and given that it can outperform native JSON encode/decode methods shows that now one can actually reason about memory allocation patterns in Luau and do a better job than native code that most likely neglected these concerns.