Fixes #134 normal hostnames could be resolve without a port. it was only Ip adresses that could not.

The name you can see in the server list is the same as the adress.

Before

Now

I have simplified the code and it can still connect to server where it is protected by TCPShield. I did throw in a empty server where the field is empty. also kkmp.dk does not exits.

FIY this pr also removes regex

Since GitHub hasn't updated macos-latest I bumped up the macOS version from 10.15 to 10.16 (For some reason, the macOS 10.15 CI uses the Xcode 11 SDK, while the macOS 10.16 CI uses the Xcode 12.X SDK, which lead to less compatibility with the Rosetta 2 interpreter)

Flatpak is a universal package manager for Linux. Flathub is one of Flatpak's repo (remote) which includes a build system. Alternatively we can use GitHub CI to create Flatpak bundles: https://github.com/marketplace/actions/flatpak-builder.

I'm quite familiar with Flatpak so I can create a manifest.

I don't have a Minecraft account, so I'd like others to test it for me. If you want to test, please read the instructions at https://github.com/terrarier2111/Leafish/issues/104#issuecomment-913779965.

Closes https://github.com/terrarier2111/Leafish/issues/104.

Since this MR requires approval, test CIs will be available at https://github.com/TheEvilSkeleton/Leafish/pull/1.

Fix a panic where screen tries to subtract 1 from 0 0 - 1 = -1 this panic only happens in debug builds, I think it is because rust builds it with checking for overflow there. Not sure why it don't do it in a release build

Not sure if it should be fixed like this or there i a logic error some place? I have not looked into it

    Finished dev [optimized + debuginfo] target(s) in 0.12s
     Running `target/debug/leafish`
[main.rs:220][INFO] Starting Leafish...
[main.rs:284][INFO] Shader version: #version 150
thread 'main' panicked at 'attempt to subtract with overflow', src/screen/mod.rs:269:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
zsh: segmentation fault (core dumped)  cargo run

I've added basic support for moving items around inventory windows using single left clicks. This works for player inventory and chests at the moment. I was testing on a 1.14 server, but can do testing for a few other versions tomorrow.

One of the architecture changes I made was to store the 36 inventory slots that are common to most window types in the base inventory, rather than making it proxy those the player slots. This made rendering updates easier to manage since we didn't need to use different rules between player and chest inventories.

Sorry about the large PR. I'm happy to make changes to the structure if you had another design in mind.

We seem to be reading 4096 bytes rather than 2048 bytes per section in some cases. The array should always be 2048, 4 bits for each block in the chunk section (https://wiki.vg/index.php?title=Protocol&oldid=16317#Update_Light).

I tried running a local Spigot 1.16.5 server, and connecting to it with Leafish (on commit fcdfa40), but about half a second after I connected, the client crashes with the following console output:

leafish_crash.txt

I did get a couple of frames rendered before it crashed, but I could only see my own body and some boxes without textures on them.

Hello this is a work in progress, I don't know if you want a huge match statement like this or you would like to use something else.

When I run it from minecraft server 1.16.4 it tries too set item 902. but is is not in the list.

do somebody know where to look for minecraf block id's?

I am going to remove log::info later. it is just for debugging purpose.

~~This requires too much passing around of the background_image variable, but good enough for now till the settings system has been reworked~~

EDIT: This depends on #139 and shouldn't be merged first.

I several times had a protocol/target folder which I kept accidentally committing. Let's ignore that directory (and others).

I'm not entirely sure this does the right thing so needs testing, but right now I can't get the folder to appear again.

Are we pointing at a commit that does not exist as a dep (in the lockfile)?

$ cargo build --release
    Updating git repository `https://github.com/terrarier2111/bevy`
error: failed to get `bevy_ecs` as a dependency of package `leafish v0.1.0 (/home/iphands/prog/Leafish)`

Caused by:
  failed to load source for dependency `bevy_ecs`

Caused by:
  Unable to update https://github.com/terrarier2111/bevy#a58b4936

Caused by:
  object not found - no match for id (a58b4936d0e1ccd241dca74bceae78a1b6d4f949); class=Odb (9); code=NotFound (-3)

I started doing some benchmarking on the code that loads chunk since I noticed the game becomes a bit jumpy when entering a new area. After doing a bit of testing with a few different methods of optimisation, it seems like the main causes were:

• The chunk DashMap hash function
• The locking while loading a chunk
• The BlockStorage structure

The first thing I noticed was that a large amount of the time was used up by DashMap hash function. I tried to switch to a faster one, but nothing really seemed to beat the custom FNV hash that we have already. Since the chunk hashmap is indexed with two i32s, I tried to use a BTreeMap instead since the comparison should be faster than using a hash function for such a simple key. It ended up dropping from ~6.2ms to ~4.1ms per chunk.

One of the downsides of using BTreeMap rather than DashMap was that chunks couldn't be loaded concurrently since it keeps a write lock for the entire load_chunk() call. Using DashMap allows for locking multiple chunks if accessing values in different shards inside the DashMap. To resolve this issue while still using a BTreeMap, I changed load_chunk() to make a copy of the chunk at the start, update the chunk, and then write the copy back at the end. I was expecting this to add a little more time to the process, but I couldn't see any difference on the benchmark results. This also allows any number of chunks to be loaded concurrently, only blocking other threads while attempting to replace the chunk at the end.

The next thing I found was the BlockStorage struct. It seemed to be using a structure similar to the palette structure the chunk is sent in. When I switched this to use a Vec<Block>, it dropped from ~4.1ms to ~2.9ms per chunk. I tested the effect this had on memory by running the client with both implementations, and it seems like it only used ~20mb of extra memory.

After making these changes, the game was noticeably less jumpy when going into new regions. I think the majority of this was changing the locking structure, since anything that needed to read the world state was less likely to conflict with the load_chunk() write lock. The other optimisations are less important but still make chunks load faster in new regions.

We really should make a clause that licenses all code under one license. By default if someone doesn't put in a license for their code, it's assumed to be all rights reserved.

In this function you use the unsafe keyword for almost the entrie function body.

We need to mark unsafe operations more precisely using unsafe keyword. Keeping unsafe blocks small can bring many benefits. For example, when mistakes happen, we can locate any errors related to memory safety within an unsafe block. This is the balance between Safe and Unsafe Rust. The separation is designed to make using Safe Rust as ergonomic as possible, but requires extra effort and care when writing Unsafe Rust.

Hope this PR can help you. Best regards. References https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

This aims to fix varint/varlong decoding, based on the example implementations from wiki.vg. Is yet to be tested. When this gets merged, please don't forget to delete the fix-varint-decoding branch, as it's not needed anymore.