Describe your feature

Currently instances are placed into a single large array, and then the index of the instance in that array is written to the buffer. This wastes the two bytes written to the buffer. As Zap serializes and deserializes in the same order, instances will be written to the array in the same order.

A type like this: Instance(BasePart) is currently outputted as the following:

function types.write_basePart(value: basePart)
	local pos = alloc(2)
	buffer.writeu16(outgoing_buff, pos, alloc_inst(value))
end
function types.read_basePart()
	local value;
	value = incoming_inst[buffer.readu16(incoming_buff, read(2))]
	assert(value ~= nil)
	return value
end

With this change implemented this will be changed to this:

function types.write_basePart(value: basePart)
	table.insert(outgoing_inst, value)
end
function types.read_basePart()
	local value;
	value = table.remove(incoming_inst)
	assert(value ~= nil)
	return value
end

Again, this is possible because we serialize and deserialize in the same order - so instances will be written and read from the inst buffer in the same order.

Alternatives

I have not considered any alternatives at this moment.

Implementation Details

This could cause issues if we ever have non-deterministic serialization or deserialization order in the future.

Additional context

N/A

Describe your feature

Zap should support the CFrame datatype.

Alternatives

The alternative is not supporting CFrames.

Implementation Details

The slowest way we can impliment it is by sending i32[12] from CFrame:GetComponents. This is expensive and wastes network bandwidth.

The challenge with CFrames is that Roblox uses a lot of compression methods for sending CFrames. We also should do this - we just need to research how it is done to avoid sending 12 i32s.

Describe your feature

Codegen currently has a lot of dead code if network definition files don't define enough variations of events. This makes linters upset because they flag unused functions and variables.

Alternatives

A simple workaround for this issue would be to include comments at the top of the generated code to silence Selene and the Luau linter. However, this isn't ideal and the better solution is to actually trim dead code.

Describe the bug

Luau currently reports a type error in strict mode for code generated for the client. This is due to when using :WaitForChild, the return value is Instance while we know that it's a RemoteEvent. The function FireServer does not exist on type Instance thus correctly reporting an error.

Reproduction

Just generate any code for the client. It should cause a type error in strict mode.

Expected behavior

The generated code should not give off any type error.

Potential Fix

Typecast the resulting return value to be RemoteEvent / UnreliableRemoteEvent

This change is important to support events that are fired the frame the client joins the game. Without the delay, the client won't have enough time to connect to the events.

Describe your feature

While using the CLI, you can run into filesystem errors which don't clearly describe what the issue is.

These error messages should be more descriptive, pointing users to solutions. As a quality of life feature for output directories, any nonexistent directories should be created during execution.

Examples

For instance, a config that looks like this

opt output_client = ./network/client.luau
opt output_server = ./network/server.luau

...will cause the following generic and unclear filesystem error on Windows if no ./network directory exists:

Error: The system cannot find the path specified. (os error 3)

A similar error,

Error: The system cannot find the file specified. (os error 2)

...is output if the path provided to the config file is invalid.

Alternatives

Both of these are minor issues, so creating the directories in question and/or ensuring file paths are correct both work. The docs could also cover these common mistakes.

Describe the bug

Ranges aren't max inclusive, the value is 1, but it's checking if it's < 1

Reproduction

Link to playground with accurate reproduction https://zap.redblox.dev/playground.html?code=ZXZlbnQgcm91bmQgPSB7Cglmcm9tOiBTZXJ2ZXIsCgl0eXBlOiBSZWxpYWJsZSwKCWNhbGw6IFNpbmdsZVN5bmMsCglkYXRhOiBTdHJpbmdbNF0KfQoKZXZlbnQgY29tbWFuZCA9IHsKCWZyb206IENsaWVudCwKCXR5cGU6IFVucmVsaWFibGUsCgljYWxsOiBTaW5nbGVTeW5jLAoJZGF0YTogewoJCWRlbHRhVGltZTogZjMyLAoJCVg6IGk4ICgtMS4uMSksCgkJWjogaTggKC0xLi4xKQoJfSwKfQo=

Expected behavior

That ranges are max inclusive, so that this bug doesn't happen

Firing a remote on the server inside PlayerAdded is not guaranteed to exist because the user's connection can run before zap's. This fixes the issue by initializing the player inside of fire functions instead of PlayerAdded.

Describe your feature

Zap should support the Color3 datatype.

Alternatives

Sending 3 doubles is less efficient than sending a single Color3.

Implementation Details

I think most people only need 8 bits of accuracy per color channel, but for HDR colors I guess you need to bump it to the next largest size which is 16 bits of accuracy per color channel. I would assume a Color3 channel range of [0, 1].

Docs are left to write.

The unknown type is an escape from when we do not know the structure of the data and must instead get Roblox to serialise it. This can be a footgun and only should be used in specific circumstances.

At the moment Zap generated code is at risk of hitting the local limit. This change removes the creation of a local for each write and instead uses a single local.

Describe the bug

Luau reports a type checking error on the server output since variables reliable and unreliable are of type Instance?.

Reproduction

Any server output with an event

Expected behavior

Not produce a type error

Describe your feature

Events should be able to return a value

Alternatives

Creating two events (one for each way)

Implementation Details

Careful decision will have to be made as to if we use RemoteEvents under-the-hood and then create a mock remotefunction-like interface in zap (so we don't yield the thread!).

Describe your feature

Making data optional would enable sending remotes without any data.

Alternatives

Adding a void type. This adds another type that isn't necessary and it's more difficult to maintain because you need to make sure it's being used correctly.

Adds a manual_event_loop option which exports a send_events function when true. This is useful when the user can schedule send_events after all their other code that runs in the frame.

Describe your feature

The addition of an OR operator for types will create better data definitions with less overhead, compared to tagged enum alternatives. The operator can function similar to Luau i.e. type bool_or_u8 = boolean | u8

Alternatives

Using tagged enums will in essence function as an OR, however there is more overhead. i.e.

enum "Type" {
    Number {
        Value: f64,
    },

    String {
        Value: string,
    },
}

WILL CREATE -->

({
	Type: "Number",
	Value: (number),
} | {
	Type: "String",
	Value: (string),
})

meaning that there is now an overhead of both a string and the value's type.

Describe your feature

In a large complex game, the remotes used can generally be grouped into categories. Zap should support a namespace under the event struct, and when a namespace is specified, you should be able to access it through remotes.namespace.remote_name.

Alternatives

• Do not organise the events
• Use mutiple zap config files

Implementation Details

This should be implimented under the event struct with an optional namespace field.