NetRay Compile - IDL Compiler - v0.1.1

Resources Community Resources
, , ,
1

Vector
Vector5391×1167 716 KB

NetRay Compile is an IDL compiler written in Luau.

Plugin | Documentation | GitHub

Features

Blink-style syntax support
Roblox Studio plugin for easy authoring and compilation
Two-way communication on a single remote (send + receive), instead of maintaining separate events with different From settings
Supports events, unreliable, remote functions, and namespaces/scopes
Passthrough, allowing you to send data outside the buffer, for example, instances and unsupported types

Compared to Roblox

~2.7–6.2x faster than Roblox remotes
Up to 1000x lower bandwidth usage than Roblox remotes

Benchmarks

Compared to Blink (average/median):
~4% lower bandwidth usage
~66.7% faster

About NetRay Compile

NetRay Compiler aims to deliver similar or better bandwidth performance than Blink, while improving execution speed.

Support, feedback, and pull requests are highly appreciated.

Beta Note

NetRay Compiler is currently in beta.
It was started very recently (8/2/2026), and not all features are fully supported or rigorously tested yet.
The project is inspired by Blink/Zap, with thanks to their creators.

Benchmark

Benchmark Summary (240 FPS, Studio, empty baseplate):

  • Blink and NetRay achieve identical throughput (~12k msgs/sec) and identical RTT (~21–22 ms, scheduler-bound).
  • NetRay consistently uses ~2% less bandwidth and ~43% less client CPU per message (418 ns vs 737 ns).
  • Roblox Performance Stats corroborate the bandwidth difference (≈253 KB/s vs ≈268 KB/s).
  • NetRay uses ~5–6% less bandwidth than Blink according to Roblox Performance Stats, while delivering identical throughput and latency.

Benchmark Tested Entities struct

  • 50 Fires Per Frame
  • 3,000 Frames

Benchmark also includes 200 fires per step for 8 second test function (you must change the code to use it)

Benchmark.rbxl (77.1 KB)

If there is anything wrong with the Benchmark Place, let me know!

6 Likes
2

Github is Live!
Documentation Website is also live!

More peformance and features to be added soon!

3

Throughput tests, latency tests, CPU tests ??? Where?

2 Likes
4

i have sent the template privately to him recently, so its soon..

1 Like
6

Just from observation when testing bandwidth usage ping and cpu timing the rest seemed unchanged or no different to blink (except for being faster then blink)

I will be doing the test place later, the one eternity provided, today once I’m free

7

To be honest, I dont really like IDL compilers, so Im wary of this project. Many peoples think IDL - future, but IDL = more faster serialization and more boilerplate. In 2000s many programmers also thinks about IDL and thought it was the future, only Protobuf survived lol. The true future of Roblox networking belongs to libraries that implement real congestion control: CoDel, PI/PID - not just serialization and naive batching

8

While you’re correct in that CoDel/PID control would be helpful those are transport layer concerns, Roblox doesn’t give use accses to the UDP sockets or RakNet buffer, so implementing active queue management in luau is just boilerplate ontop of the engines internal queueing. Your suggestions would better suit engine suggestions as it belongs in the engines C++ networking stack

Edit: after some searching I believe Roblox already has this implemented in a way? Apparently it uses a sliding window algorithm

9

CoDel + PID requires simple math and algorithms, we dont need BBR in roblox lol. Only CoDel, PID and simple math is best solution. Also UDP doenst need, Delay-Based Congestion Control like TCP-Vegas, CoDel, PI/PID/PIE can realized on any sockets and Remote event too, Raw UDP sockets is not required

10

Technically, you can implement almost any CC based on RemoteEvent, even BBR, but such code will be crooked and not precise compared to the C++ network stack

11

It’s still extra boilerplate and complexity ontop of Roblox’s pretty good networking.

To add on, a IDL compiler and your suggestion aren’t mutually exclusive, you would want to use a idl compiler to make the packets as small as possible and use a congestion control

But I would still say adding congestion control is overkill and boilerplate and any congestion control should be in the engine in C++

12

Decide for yourself its your project, not mine. But I think App-Layer CoDel and PID are a very good solution for burst traffic

13

I would like to adopt this compiler for Shatterbox, but I am wary given that you haven’t provided any unit tests. Maybe in the near future I will do these tests myself, but it would be good for you to include these in this thread. This seems very promising if your claims are true, because I use Blink mainly for the reduced CPU utilization. If you have reduced it even further, I applaud you.

14

The test/benchmark is on GitHub, I am going to add a download to the benchmark place in the forum thread in the next hour. I am just adding an average bandwidth print

And just from observation, the CPU time has not changed compared to not firing events/blink.

I will mention you and attach a place file for self-verification

2 Likes
15

Benchmark Summary (240 FPS, Studio, empty baseplate):

  • Blink and NetRay achieve identical throughput (~12k msgs/sec) and identical RTT (~21–22 ms, scheduler-bound).
  • NetRay consistently uses ~2% less bandwidth and ~43% less client CPU per message (418 ns vs 737 ns).
  • Roblox Performance Stats corroborate the bandwidth difference (≈253 KB/s vs ≈268 KB/s).
  • NetRay uses ~5–6% less bandwidth than Blink according to Roblox Performance Stats, while delivering identical throughput and latency.

Benchmark Tested Entities struct

  • 50 Fires Per Frame
  • 3,000 Frames

Benchmark also includes 200 fires per step for 8 second test function (you must change the code to use it)

Benchmark Place

Benchmark.rbxl (77.1 KB)

If there is anything wrong with the Benchmark Place, let me know!

Mentions those who looked for benchmark

@PELMEN4IK125
@azavier123
@Eternity_Devs

1 Like
16

Can you give some more examples on how to use this?, It seems good but confusing, is this also like The Old Netray? for remove events and what not?

1 Like
17

Yes it’s for remote events and remote functions.

On the documentation page, there is an example of the schema. Just open the plugin editor to your desired schema, and it will generate a folder called NetRay in Replicated storage

Examples

1 Like
18

Are schemas really needed?, Personally I don’t want to use them, is there any way to not use them?

1 Like
19

Unfortunatly not, since this is a compiled networking script, you must define it. Eseentially you’re generating a event and what data it’s supposed to take before you play the game instead of at runtime

1 Like
20

NetRay Compile v0.1.1 [BETA]

Changelog

  • Expanded IDL type coverage, event call-mode APIs, parser/analyzer capabilities, and runtime generation performance.

Added

  • New IDL type support: f16, buffer, vector/vector3, cframe, brickcolor, color3, datetime, datetimemillis, instance(...), and unknown.
  • set declarations and tagged enums (enum Name { ... } with default Type tag, or enum Name = Tag { ... } / enum Name = "tag-name" { ... }).
  • Inline type declarations in schemas (struct { ... }, inline enum { ... }).
  • fixedarray<T, N> support plus shorthand forms like T[N].
  • Map shorthand support ({[K]: V}).
  • Extended bounds syntax for numeric/string/collection types (range-style and bracket forms).
  • option remote_scope = ... support in compiler scope resolution.

Changed

  • Parser/analyzer improvements across type resolution, declaration analysis, and option handling.
  • Event call-mode generation updates (SingleSync, ManySync, SingleAsync, ManyAsync, Polling with Iter()).
  • Blink-style event/function block parsing is now supported alongside legacy syntax.
  • Function Yield parsing remains restricted to SingleSync in current generator behavior.
  • Runtime generation improvements (segmented queue batching, canonical encode/decode paths, stricter validation flow).
  • Generator architecture has been split into dedicated modules (Runtime, Emitters, EmitTypes, Utilities, Types) for maintainability.
  • Lower byte usage per payload, including reduced metadata overhead in bounded collections.

Performance

  • Lower bandwidth usage (approximately ~1-2% for reliable and unreliable paths).
  • Decoding speed has improved significantly.
  • Encoding speed has improved slightly.
  • Lower packet byte usage overall.

Both GitHub and Roblox Plugin have been updated

21

Looks like this is coming along great! Do you plan to add command line integration so the compiler can easily be used within Visual Studio Code?

1 Like