Issue / Question: Currently, we do not use results, and as a result, a simple function such as u32::compose(&[0, 0, 0, 1], &mut 0) may panic, and kill the main thread. We expect a possible error here therefore it should NOT terminate the main thread, but rather just error in console, with a description of what happened.

Proposals / Details: In places where an unwrap or any function that has the potential to voluntarily panic we should be using results. Consider the following potentially erroneous code:

fn do_read(some_bytes: &[u8]) -> String {
    // read the first byte (length) of the string.
    let length = some_bytes[0];
    // now read for length
    let contents = &some_bytes(1..length);
    String::from_utf8(contents).unwrap()
}

This proposal would change the potentially erroneous code above to:

fn do_read(some_bytes: &[u8]) -> Result<String, ErrorEnum> {
    // read the first byte (length) of the string.
    let length = some_bytes[0]?;
    // now read for length
    let contents = &some_bytes(1..length);
    String::from_utf8(contents)?
}

• [x] Responds to Offline Packets (0x0 - 0x1c)
• [x] Shakes the clients connection (Connection sequence) properly
• [x] Accumulates ACK, NACK packets.
• [x] Properly handles frames and NACK responses.

Event Function not mutable with current implementation.

Currently, we have an issue with how RakNet handles events. (this may be moved to raknet after further analysis) The issuing being, the event subscriber function must be able to verify that the instance of the Server lives statically, which is unfortunately not possible. In the context of code, this looks like:

struct Server;

impl Server {
    fn start(&mut self, address: &str) {
        // We can try to create an "Arc" which references self directly
        let self_ref = Arc::new(&self);
        
        // However we can not validate that this will live statically, which
        // is required by raknet.
        let mut rak_server = RakNetServer::new(address.to_string());
        let (_send, _work) = raknet_start!(raknet, move |event: &RakNetEvent| {
			match event.clone() {
				RakNetEvent::GamePacket(address, buf) => {
					// Error: self may not live for the entirety of this thread.
                    self_ref;
					Some(RakResult::Motd(Motd::default()))
				}
				_ => None
			}
		});
    }
}

I'm still currently brainstorming how we could solve this issue, as it's something that affects the servers functionality entirely.

You're using TypeScript. Why use # to initialize a private property when you can just use the private type.

#network: RakServer can be private network: RakServer

Questions & Answers

Why?

Rust is fast, and allows us to practice better memory practicing, allowing us to write efficient code with incredible speed.

So will the Deno Typescript code be discarded?

I plan on keeping a maintained branch with a similar api to the incoming changes for the rust version; this is because I am not set on removing the TypeScript version, as I think it would be a good reference for benchmarking the rust version, as well as offering an opportunity for more people to contribute to it.

Plugin API

While the core code will be migrated to rust, we will still be using a TypeScript plugin API integrated with Deno. The plugin API will be isolated, meaning each plugin will run in it's own "context" to allow full usage of Deno's "secure by default" motive as well as better control of developing and debugging plugins.

Please only use this PR for reporting issues with this PR itself, for discussions refer to: https://github.com/NetrexMC/Netrex/discussions/8

To remove redundancies and allow more control on debugging vs actual prints there should be a logger crate that can be used in all sub-crates of netrex like raknet and protocol.

Should the server itself tick? I'm thinking probably not because each world should be reliable for ticking, as ticking on the server (because it's a mutex) will hold a handle to everything for the duration of that tick, when we only need to tick worlds as they are open.

Please provide input here 😄

Entities and Player implementation

• [ ] 1. Basic implementation of packets required to handle entities via Protocol

  • [ ] TO DO

• [ ] 2. Skins (or related)

• [ ] 3. Entity NBT

• [ ] 4. Entity Ticking

Working login sequence (player spawn)

• [ ] 1. Basic implementation of packets required to log in via Protocol

  • [x] Login
  • [x] Server to Client Handshake
  • [x] Client to Server Handshake
  • [x] Play Status
  • [ ] Resource Packs Info
  • [ ] Resource Pack Client Response
  • [ ] Resource Pack Stack
  • [ ] Start Game
  • [ ] Creative Content
  • [ ] Biome Definition List
  • [ ] Chunks

• [ ] 2. Login authenticator: Handles logins (such as XBL validation)

• [ ] 3. Pesudo packet implementation

• [ ] 4. Start Game Packet:

  • [ ] Working block tables
  • [ ] Working item tables

Questions & Answers

Why?

Rust is fast, and allows us to practice better memory practicing, allowing us to write efficient code with incredible speed.

So will the Deno Typescript code be discarded?

I plan on keeping a maintained branch with a similar api to the incoming changes for the rust version; this is because I am not set on removing the TypeScript version, as I think it would be a good reference for benchmarking the rust version, as well as offering an opportunity for more people to contribute to it.

Plugin API

While the core code will be migrated to rust, we will still be using a TypeScript plugin API integrated with Deno. The plugin API will be isolated, meaning each plugin will run in it's own "context" to allow full usage of Deno's "secure by default" motive as well as better control of developing and debugging plugins.

Please only use this issue for reporting issues with this change itself, for discussions refer to: https://github.com/NetrexMC/Netrex/discussions/8