The Eye

👁️ WubarrksEye (TheEye)

"Stop guessing what the IL does. Stop decompiling 130,000 lines just to find out if CanSenseTarget is virtual or static. The truth is in the assembly, and now it's in your hands."

WubarrksEye (TheEye) is a deterministic, cross-platform Valheim extraction tool. It is, without exaggeration, a vibe coder's wet dream. But let's be real, with this data at your fingertips you're not just a vibe coder anymore. You're an AI-augmented game mod designer, and your dreams can come true. When Valheim 1.0 drops and the API shifts under everyone's feet, this is the tool that maps the new world, tells you exactly what changed against your pre-1.0 baseline, and feeds it straight to your AI pair programmer.

Forget hand-grepping decompiled source for hours. Forget guessing why your Harmony patches misfire because you bound the wrong overload, or realising months later that your custom monster AI was inert because vanilla's Character.OnDamaged never fires for most creatures. TheEye gives you the ground truth of the game's architecture, serialized data, method call graphs and live world state, straight from memory.

This isn't a dumper. It's an autopsy table for the game engine, and as of 2.3.0 it comes with a before/after report and a mod impact report.

⚔️ What's new in 2.3.0 (the 1.0 migration release)

Built against the 1.0 public-test build (0.221.13, network version 37) and verified headless on both the last pre-1.0 server and the playtest server.

🛡️ Survives the build change

0.221.13 moved sectors from Vector2i to Vector2s, replaced the seven ZDOExtraData.Get*s(ZDOID) readers with one GetData(out...), and turned World.m_worldVersion into an enum. Every member TheEye touches that moved is now late-bound: it is looked up by name at first use and a missing one costs one field in one record, never a whole extractor. Manifest.json gains a Compatibility section listing every game member TheEye relies on and whether this build has it, and the BepInEx log says the same at startup.

🧩 ModImpact_Dump.json — which of your mods break on this build

Every plugin BepInEx loaded, plus any folder you point it at ([ModImpact] ScanPluginDirs or dump_eye scan=), is read with Mono.Cecil and every reference it makes into a game assembly is resolved against the running build. Per plugin: the exact unresolved methods, fields and types, the plugin methods that use them, every [HarmonyPatch] target that is missing or now ambiguous (a new overload appeared), and whether a preloader patcher such as Valheim10Compatibility bridged the gap in memory. Then the live Harmony patch map: who patches which game method. Run it from a clean profile with scan= pointing at your mod-manager profile's plugins folder and you have the day-one breakage list without loading a single mod. What it cannot see: targets found by string name or TargetMethod() show as Unchecked, and a field whose type changed is not bridgeable by any preloader, only by the mod (on 1.0 that is VisEquipment's item fields and the ZoneSystem / ZDOMan sector containers).

🧬 IL fingerprints: Huginn now sees body changes

Each API type carries a MethodBodies table, a hash of every method's normalized IL (opcodes, resolved operand names, relative branch targets). A method whose signature did not move but whose code did now shows up as BodyChanged. That is most of what a game update is (392 of the changes between 0.221.12 and 0.221.13), and it is what transpilers and behaviour-dependent patches trip over.

🐦‍⬛ Huginn's Report, classified

CHANGED API records carry a Members list that names each change the way an assembly differ would: Added, Removed, SignatureChanged, BodyChanged, TypeOnlyRipple (only Vector2i/Vector2s or Int16/Int32 moved) and Renamed (same IL fingerprint under a new name). Huginn_Summary.json gets a Breaking block (types and members removed, signature changes, ripples, RPCs and ZDOVars and console commands removed, plugins broken).

📝 Huginn_Report.md

The report a person reads fir