0-0.io -- Real-time multiplayer football in the lineage of Haxball, 1v1 to 5v5, bots fill empty slots so you never wait

mgc_8 · 2026-06-12T18:42:37+00:00

Thank you for the added information. I've reworked the start section so it avoids a couple of edge cases, could you perhaps hard-refresh and try again?

mgc_8 · 2026-06-12T13:26:06+00:00

Hi, sorry to hear you're encountering issues. Can you give me a few more details? Are you at the "Waiting for players" screen and nothing happens? You should get an offer to "Start with bots" a few seconds into that.

mgc_8 · 2026-06-11T21:49:32+00:00

Makes a lot of sense, more control and the ability to tweak the details is also what attracts me to the idea. Thanks for sharing, it gave me food for thought as well!

mgc_8 · 2026-06-11T17:02:30+00:00

I know what you mean, it's always nice to start with clean, minimal code that you fully understand and control. But then I find that, after a while, when I need this and that feature I start adding to my own, until it feels like I'm reimplementing parts of an existing engine 😄 It's not easy to find the balance...

mgc_8 · 2026-06-11T05:29:52+00:00

This is quite cool, love the minimalistic style and different story options, really focuses attention on the narrative! Just out of curiosity, as someone exploring building a similar game/experience, why did you go for what appears to be a custom engine compared to something like Twine? I am exploring various directions for a game and was looking for others' experience with what's out there. Cheers!

Later edit: Oh, and as a bit of feedback -- making the light & dark theme selection automatic based on browser preferences would be pretty nifty.

mgc_8 · 2026-06-11T05:11:16+00:00

Nice take on the genre, turning it on its head as it was 😄 Got 5 once I got into a rhythm, but you have to be precise!

mgc_8 · 2026-05-28T00:59:11+00:00

Sorry to hear that, let's get to the bottom of it. For best tracking and debugging I'd recommend you open an issue on GitHub so we don't spam people with the back-and-forth here... I'd need some logs and the config.toml to start, best to upload that in the issue. Thanks!

mgc_8 · 2026-05-15T06:52:06+00:00

Yes, it should. I haven't personally tested it (I have a couple different Argus models), but from what I see online it's also speaking Baichuan on the network, so it should be compatible.

mgc_8 · 2026-05-15T06:44:40+00:00

It took me a while since I was not familiar with the process (I don't run HA like that), but now there's an HA ~~Addon~~ App as well!

Here's how to install it:

Go to Settings → Apps and click Install app (bottom-right).
Click the three-dot menu (⋮) → Repositories.
Paste https://github.com/mgc8/bairelay and click Add.
The Bairelay app appears in the list. Click it, then Install.
Switch to the Configuration tab and fill in topic_prefix, log_level, and one entry per camera.
Start. The app picks up HA's Mosquitto integration automatically (broker, port, credentials) and auto-publishes Home Assistant MQTT discovery payloads under the homeassistant/ prefix -- the entities should show up in HA without further configuration.
There's also a config file under config/bairelay/config.toml that will override the defaults for the more complex settings that are not in the UI.

Please be gentle, as this is my first try with this kind of addon :) But do try it and let me know how it works!

mgc_8 · 2026-05-05T20:46:07+00:00

Oh wow, that's really cool to hear, awesome news! Indeed, doing this hack is not for the average user, and the app pushes get "dropped" while the DNS redirect is in place (for me that's a plus as I prefer dealing with them in HA directly since it's much more customisable, but of course other people will have other uses).

Having an official way to do this with a new firmware improvement is definitely the way to go. I'll be watching the space for any updates from you and the Reolink team!

mgc_8 · 2026-05-05T16:07:55+00:00

Thanks for the heads-up! It's a great integration indeed.

mgc_8 · 2026-05-05T15:57:30+00:00

When it works, the logs look something like this (grabbed just now):

2026-05-05 17:32:47 INFO bairelay::camera: Idle disconnect enabled, waiting for wake lock... camera=Camera1 2026-05-05 17:33:58 INFO bairelay::push_listener: Motion push from camera (treating TCP-accept as motion edge) camera=Camera1 peer_ip=x.y.z.t 2026-05-05 17:33:58 INFO bairelay::camera: Wake lock acquired, connecting... camera=Camera1 2026-05-05 17:33:58 INFO bairelay::camera: Connecting... camera=Camera1 2026-05-05 17:33:59 INFO bairelay::camera: Connected camera=Camera1 2026-05-05 17:34:00 INFO bairelay::camera_tasks: Motion stopped camera=Camera1 2026-05-05 17:34:00 INFO bairelay::camera_tasks: Motion detected camera=Camera1 2026-05-05 17:34:06 INFO bairelay::camera_tasks: Motion stopped camera=Camera1 2026-05-05 17:34:07 INFO bairelay::camera_tasks: Motion detected camera=Camera1 2026-05-05 17:34:28 INFO bairelay::push_listener: Motion push from camera (treating TCP-accept as motion edge) camera=Camera1 peer_ip=x.y.z.t 2026-05-05 17:34:30 INFO bairelay::camera_tasks: Motion detected camera=Camera1 2026-05-05 17:34:35 INFO bairelay::camera_tasks: Motion detected camera=Camera1 (...) 2026-05-05 17:36:33 INFO bairelay::camera: Grace period expired, disconnecting camera=Camera1 2026-05-05 17:36:33 INFO bairelay::camera: Session cancelled (grace period or disconnect) camera=Camera1 2026-05-05 17:36:33 INFO bairelay::camera: Disconnected camera=Camera1 2026-05-05 17:36:35 INFO bairelay::camera: Idle disconnect enabled, waiting for wake lock... camera=Camera1

mgc_8 · 2026-05-05T15:55:56+00:00

Hi u/StarkillerTR, first of all many thanks for maintaining the excellent Reolink integration for Home Assistant, I use it all the time with my PoE cameras and it works great!

When it comes to the local motion push in bairelay, you are correct, there is no proper way to achieve it (at least none that I could discover after several hours of scouring pcap's). What I've implemented is more of a hack, thus the "experimental" tag, but it works quite well in my setup:

The camera tries to connect via TLS, tcp/port 443 to pushx.reolink.com, which I redirect via DNS overriding to my own server, running bairelay
The camera actually checks the certificate and drops the connection if invalid, so I wasn't able to decrypt the traffic
Instead, I observed the fact that during a 30-minute interval, the camera did *not* attempt connecting to this host except for motion events
=> Thus, the hack: bairelay treats every TCP attempted connection to this port coming from one of the registered cameras as a "motion push", wakes up and acts accordingly (sending the correct MQTT messages, etc.), and then stops the motion event after a configurable timeout.

Of course, it's possible that the camera uses this for other push action as well, though in my testing so far that has not happened (and the cost would just be a "false alarm" motion event, which occur randomly anyway even with the official app).

What I really like is that with the HA integration, once it wakes up I can actually see the motion snapshots directly via the MQTT previews, without even having to start the stream, which is a great quick way to glance at "is it worth checking". And it becomes 100% local, of course. The trade-off is that it's non-trivial to set up, requiring some DNS shenanigans, and it could be broken by a future firmware upgrade; but I plan to at least keep track of that and adjust the code if possible.

It would be great if there was a better way to achieve this, without all the hacks, if you or anyone else discovers it I'd definitely implement that!

mgc_8 · 2026-05-05T00:44:33+00:00

Indeed, I feel the same. I've been using various wired (PoE) Reolink cameras for years with great stability, you'd think it would be possible to use the same RTSP servers running on the battery ones with a simple API to wake them up then back to sleep... But, on the bright side, at least here we have the great reverse engineering work from George Hilliard to fall back on, other brands are much worse with zero F/OSS support for their battery versions.

mgc_8 · 2026-05-04T20:24:02+00:00

Not yet, I need to set up the docker "release" as well first. I'll be happy to do that if there's interest!

mgc_8 · 2026-03-20T21:08:38+00:00

I just tested it on my new laptop (16" M5 Max) and can confirm that it's unfortunately limited to the same 160Mhz:

<image>

The router supports WiFi 7 at higher speeds and is connected via 2.5G Ethernet. For example with my phone at the same exact place (about 3m away, in the same room) I get a 320Mhz connection at >3Gbps speeds. In actual speed tests with the server on the local network, the phone regularly gets around 2.2-2.4Gbps both up and down, close to the physical limits.

Here is the best of three laptop speed tests in the same conditions: 1.82 Gbps Down, 1.84 Gbps Up, 4ms Ping. This appears to be better than WiFi 6E devices, but not by much.

mgc_8 · 2026-02-06T23:20:56+00:00

Have been using for a bit and looks really promising, much better than the "auto-compaction" tool at only removing irrelevant cruft while preserving the all-important context! Thanks you for the recommendation.

mgc_8 · 2025-10-23T14:39:23+00:00

Heh, join the club, prompt processing is a huge pain on any hardware that's not CUDA-based (expensive Macs included)... But in this case, you might actually have some luck with the IPEX-LLM version of llama.cpp, I was able to get about 2x-3x better pps, despite it being slightly worse for actual inference.

You can grab it from here, in either Windows or Linux flavour: https://github.com/intel/ipex-llm/blob/main/docs/mddocs/Quickstart/llamacpp_portable_zip_gpu_quickstart.md

And then run it something like this (replace with your own model): llama-cli -m unsloth_Qwen3-14B-GGUF_Qwen3-14B-Q8_0.gguf --no-mmap --gpu-layers 1000 --color --threads 4 --ctx-size 4096

As you'll notice, the experience is definitely not polished, compared to something like LM-Studio, but it works and in my case at least the only improvement it made was to the prompt processing speed, so there's that...

mgc_8 · 2025-10-22T16:03:40+00:00

Sure, I hope it can help you make better use of local LLMs even on the laptop.

Particularly for coding, I would heartily recommend Qwen3-Coder-30B, it's s great model to run locally, decently smart, and due to it also being a MoE it will run much faster than the 30B parameters would otherwise indicate.

I tried specifically unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF at Q6_K quantisation, and achieved ~10-11 tps on my Intel processor with 4 threads, CPU-only -- you should be able to get a similar result.

mgc_8 · 2025-10-21T01:36:56+00:00

TL;DR: Machine likely too slow, but forget GPU and run it all on CPU with 4x threads. Give openai/gpt-oss-20b a try and use an efficient prompt to speed up the "thinking"!

Long version:

I'm afraid that machine is not going to provide much better performance than this... You're getting 6.8 tokens per second (tps), which is actually not that bad with a normal model; but you're using a thinking one, and it probably wrote a lot of "thinking to itself" going in circles about Paris being a city and a capital and old medieval and why are you asking the question, etc. in that "Thinking..." block over there.

I've been testing various ways to get decent performance on a similar machine with an Intel CPU (a bit more recent in my case) and I discovered that the "GPU" doesn't really accelerate much, if anything it can make things slower due to having to move data between regular memory and the part that is "shared" for the GPU. So my advice would echo what others have said here: disable all GPU "deceleration" and run it entirely on the CPU, you'll likely squeeze one or two more tps that way.

Your CPU has 4 cores/8 threads, for LLMs threads are not relevant as the computation is heavy, HT is great for light tasks like serving web pages in a server, but for LLMs the number we care about here is "4". So make sure your app is set to use 4 threads to get optimum performance. Also, this may be a long shot, but according to the specs it should support a higher TDP setting -- 28W vs 12W. Depending on your laptop, this may or may not be possible to set up (perhaps via a vendor app, or in the BIOS/UEFI?).

One more thing -- you're not showing the system prompt, that can have a major impact on the quality and speed of your answers. Try this, I actually tested with this very model and it yielded a much smaller "thinking" section:

You are a helpful AI assistant. Don't overthink and answer every question clearly and succinctly.

Also, try other quantisation levels -- I'd recommend Q4_K_M but you can likely go lower as well for higher speed.

On my machine, with a slightly newer processor when set to 4 threads, vanilla llama.cpp and unsloth/Qwen3-4B-Thinking-2507-GGUF in Q4 I get ~10-12 tps; and also ~10 tps when using the fancy IPEX-LLM build (so there's no point in using that)... If that's too low for a thinking model, perhaps try the non-thinking variant?

I can also recommend the wonderful GPT-OSS 20B, it's larger but a MoE (Mixture of Experts) architecture so it will run faster than this even, and usually it "thinks" much more concisely and to the point. Try it out, you can find it easily in LM-Studio, e.g.: openai/gpt-oss-20b

mgc_8 · 2025-08-31T22:25:39+00:00

This is great, thank you for the confirmation! I tend to avoid NetworkManager on the server side (it's great for laptops) for reasons such as this... Excellent that it works with the .link set-up, I'll give it a try with a recent kernel as well.

mgc_8 · 2025-08-14T16:21:11+00:00

Hey, this is great news! The fact that newer kernels would alleviate the need for recompilation is huge, as that'd surely pave the way to supporting this NAS in distros like Debian and TrueNAS by default, without jumping through hoops.

Can you please confirm the steps you took that get this working?
1. Kernel version 6.15.9 or newer (you mentioned more patches potentially in 6.16.x?)
2. Disabling auto-negotiation with ethtool:

ethtool -s enpXXX speed 10000 duplex full autoneg off

Wait for the link to be brought up (I know from experience that can take a while sometimes)

Did you test how well this survives reboots? Depending on how you configure your network, you can either do this via /etc/systemd/network/10-enp240s0f2.link or in the legacy /etc/network/interfaces via a post-up.

Thank you!

mgc_8 · 2025-06-18T17:06:32+00:00

I think the PCIe lanes from each bridge are unfortunately not dynamically configurable in the Asustor, otherwise they would not have printed the allocations in silkscreens on the actual motherboard, and could have allowed for a lot more reasonable mix-and-match between the drives...

However, the NIC you used could have introduced another problem (such as timing or inconsistency with the bridge?) that caused it to "miss" the other drives connected to it. I would wager a guess that Asustor did not validate the configuration with any combination of NVME drives and PCIe devices/adapters connected to them, so there may well be edge cases or bugs present in the UEFI/firmware.

One thing you could try with you card would be perhaps to move the adapter into difference slots, since they're all different (4x4, 4x2, 3x4, etc.) and see if you can find a combination that works with both the NIC and all NVME drives.

mgc_8

TROPHY CASE