PNOPulse doesn't automate the game window or read the game's memory. It is the client. It logs in and talks to the server exactly the way the real game does, so nothing else has to be running.

To get that right, I decompiled the live game client back into GDScript and treated it as the spec. Every request name, argument order and reply shape in PNOPulse comes from a line in that decompile. When a comment in my code says Server.gd:331, that's the line it copies. Nothing on the wire is guessed.

The networking was the hard part. The game runs on ENet with Godot's multiplayer layer on top, so I wrote both. Every packet is signed over its encoded bytes, so my encoder for Godot's Variant format had to match Godot's byte for byte. An encoder that only round-trips correctly still gets its packets rejected.

One bug taught me the most important rule in the project. Early on, the bot kept using items it didn't have anymore. The real client only updates your inventory and team when the server echoes a change back, and I had been updating mine as soon as I sent the request. Now PNOPulse does what the client does and waits for the echo.

The code is split into three layers, with one rule:

Protocol speaks, Bot decides, Desktop shows.

The protocol layer knows bytes and messages and never makes decisions. The bot makes decisions and knows nothing about the UI. The desktop app, built with Avalonia, never touches a socket. That separation is the reason I can test the bot against real Godot servers without opening a window.

The source stays private. Releases are compiled with Native AOT, so they contain machine code and no .NET IL, and a decompiler like ILSpy has nothing to turn back into C#. I use ILSpy on other people's apps all the time, so I know exactly what that blocks. Windows builds are also signed and check their own integrity every time they start.

DisplayWidget Center is a .NET app, so I opened it in ILSpy. It turned out there's no special driver behind it. Everything goes through the standard Windows monitor API, which means plain DDC/CI over the display cable to address 0x37, plus a set of ASUS-specific VCP codes: 0xDC and 0xE0–0xFF.

The ASUS app bundles a 515 MB AI engine for "AI GameVisual" scene detection. In the end, all it does is call SetVCPFeature(0xDC, mode).

AsusDisplay sends the same commands. On Linux it writes straight to /dev/i2c-*, and on Windows it goes through the same API the ASUS app uses. It has no model list. It reads each monitor's capability report and shows only the settings that panel actually has.