# HunterPie v2 is a C# overlay split into eight projects with native interop

> HunterPie v2 is a rewritten Monster Hunter overlay built in C# on the .NET Desktop Runtime 10.0, with a solution organised into separate Core, DI, Integrations, Native, Platforms, UI and Playground projects and a Windows installer. The overlay is assembled from widget modules, each documented separately, and it reads the game through native interop rather than screen scraping.

**HunterPie/HunterPie** — A clean, modern and robust overlay for Monster Hunter games.

- Repository: https://github.com/HunterPie/HunterPie
- Website: https://hunterpie.com/
- Stars: 1,311 · Forks: 129
- Language: C#
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/hunterpie-hunterpie

## The feature list is a list of widgets, not a list of features

The README presents the features as a list of widget documentation pages, and that is the clearest description of how the overlay is put together.

There is a Monster Widget, an Abnormality Tray Widget, a Wirebug Widget, an Activities Widget, a Chat Widget, a Damage Meter Widget, a Specialized Tool Widget and a Player HUD Widget, and each of the eight named widgets links to its own documentation page on docs.hunterpie.com. There is a Clock Widget that is listed without a link, and then there are three things that are not widgets at all, Discord Rich Presence, automatic save backups and export of completed quests.

So the overlay is a frame plus a set of independently documented modules. The damage meter is the module people know the tool for, and the wirebug and abnormality widgets are the ones that track specific game mechanics, the wirebug in particular being a Monster Hunter mechanic with its own state that has to be read from the game. The Player HUD Widget is the classic overlay content, health, stamina and buffs drawn over the game.

The three non-widget features are worth separating out because they answer different needs. Discord Rich Presence publishes the player's current hunt state to Discord, which is a social feature rather than an information feature. Automatic save backups protect the player's save data, which is a defensive feature, since a corrupted or lost save in Monster Hunter is a real loss. Export of completed quests gives you a record of what you have hunted.

The documentation site at docs.hunterpie.com is a first class part of the project rather than an afterthought, with a page per widget describing what it does and how it behaves.

## A rewrite, not a reskin

The About section makes the scope of the v2 work explicit. HunterPie v2 is a version of HunterPie completely rewritten from scratch, however it follows the same principles of its predecessor, being a modern, powerful and easy to use overlay with support for plugins, modules and custom widgets for Monster Hunter games.

The three principles it inherits are the ones worth holding on to, because they explain why the project looks the way it does. Modern, in the sense of a current runtime and a current UI stack rather than a WinForms application from the previous era. Powerful, which in this context means the overlay reads real game state rather than approximating it. And easy to use, with the widget model and the automatic backups and the one-click update path all serving that goal.

The plugin, module and custom widget distinction is three levels of extension. Plugins are the top level, for adding capabilities that need their own logic. Modules are the built-in feature units, the widgets. Custom widgets are the pieces a user can rearrange or add within the overlay layout, which is a user facing concept rather than a developer one.

A full rewrite is a big commitment for a project with an existing user base, and it means the v1 and v2 codebases have nothing in common. The installation instructions point at the HunterPie-v2 releases repository separately from this one, and the Nexus Mods page is for the Rise mod, so the distribution is split between the mod site for one game and GitHub for the other. The project also carries a Discord server, a Patreon and a PayPal button in the header, so it has a community and a funding model around it.

## Eight projects in one solution

The repository top level listing is the clearest technical description of the codebase, and it is a well organised solution.

```
HunterPie.Core/
HunterPie.Core.Tests/
HunterPie.DI/
HunterPie.Integrations/
HunterPie.Native/
HunterPie.Platforms/
HunterPie.UI/
HunterPie.Playground/
HunterPie/
Installer/
Scripts/
Localization/
```

HunterPie.sln is the solution file that ties them together. The naming tells you the layering, and it is a layering that separates concerns that are usually tangled together in an overlay application.

HunterPie.Core is the domain logic, and HunterPie.Core.Tests sits next to it as a separate test project, so the tests are a first class artefact rather than a folder inside the main project. HunterPie.DI is the dependency injection container, which is the piece that keeps the widget modules from having to know how to construct their own dependencies. HunterPie.Integrations is where the third party integrations live, and Discord Rich Presence is the obvious member. HunterPie.Native is the interop layer with the game, which is the part that has to be correct and is the part that changes when the game changes.

HunterPie.Platforms is the abstraction over the things that differ between the supported Monster Hunter games, since the games have different process layouts and different memory structures and a shared overlay has to deal with that. HunterPie.UI is the presentation layer, where the widgets are drawn. HunterPie.Playground is a separate executable, which is a sensible way to develop a widget without launching the full overlay against a running game.

Then the supporting directories. The Installer/ directory holds the installer, Scripts/ holds the build and release scripts, and Localization/ is a top level directory rather than something buried in the UI project, which is a good sign for a project with a real translation effort. There is also a .vssettings file for Visual Studio and a sonar-project.properties file, which indicates the project runs SonarQube or a Sonar server as part of its quality workflow.

## Installation is a zip file, a runtime and one instruction

The installation section is short, and the three steps contain a real piece of advice that is easy to miss.

First, download the binaries from either Nexus Mods or the GitHub releases page. The Nexus Mods link is the Monster Hunter Rise mod page, and the GitHub link points at the HunterPie-v2 releases, so the two channels serve different purposes, with Nexus Mods being where the mod listing lives for that game and GitHub being where the build artefacts are published.

Second, extract it somewhere, except Desktop, as that is known for giving some people issues due to lack of permissions to write to files. That warning tells you the overlay writes to its own directory, which is consistent with the automatic save backups feature and with the general shape of a desktop overlay that keeps settings and cached data next to the executable rather than in the user profile. It is also a Windows specific gotcha, because the Desktop is a protected location in a way that other directories are not, and the user profile path that most applications use is not.

Third, run HunterPie.exe.

The runtime requirement is listed under Requirements, and it is the .NET Desktop Runtime 10.0 with a direct link to the Windows x64 installer. The .NET 10 requirement is a consequence of the v2 rewrite, and it is the sort of thing that catches out a user who has been running the v1 overlay for years and then updates.

The official documentation is at docs.hunterpie.com, and the version badge in the README header reads from an API endpoint, api.hunterpie.com/v1/version, which means the displayed version is the one the site considers current rather than a hard coded string.

## The contribution process asks you to open an issue first

The Suggestions and PRs section sets out two rules, and they are the kind of rule that tells you how a project actually behaves.

Open an issue before opening a PR, so we can discuss the best strategy to implement a new feature. And follow the project coding style to keep everything consistent.

The first rule is the one that matters. On a project where the widgets are documented individually and the game internals are read through native interop, a new widget is not a self contained change, and deciding how to implement one often needs a conversation about what data is available and where the widget should sit. Requiring the discussion first is a reasonable way to avoid a pull request that implements the right feature in a way that does not fit the architecture.

The second rule, following the coding style, is what the .editorconfig at the root and the presence of a .vssettings file are for. An overlay project with a C# solution of eight projects and a Sonar configuration has a house style, and the shared editor settings are how it is communicated.

The licence is Apache-2.0, with a LICENSE file at the top level, and the licence badge is linked to the file. Apache-2.0 is the permissive choice that lets a fork be closed or modified without the copyleft obligation, which is a reasonable default for a project that wants community widget contributions without requiring them to be relicensed.

The repository also has a .gitmodules file, so at least one dependency is vendored as a submodule rather than pulled from a package source, and the .github/ directory holds the workflow configuration. The release pattern tells you about the build cadence too, with tags v2.14.0.464 on 2026-08-05, v2.14.0.465 on 2026-08-07 and v2.14.0.466 on 2026-08-14, so a new build is produced every few days, which for a game overlay makes sense because the game itself is patched regularly.

## Where HunterPie is the wrong tool

The first wrong case is a platform other than Windows. The runtime requirement is the .NET Desktop Runtime 10.0 for Windows x64, the distribution is a HunterPie.exe, the installer is a Windows Installer project, and the overlay draws on top of a Windows game window. None of that translates, and there is no indication in the repository that it is intended to.

The second wrong case is a game the overlay does not support. The project is built for Monster Hunter games and the topics name Monster Hunter Rise and Monster Hunter World, and reading game memory is inherently per game. HunterPie.Platforms is the abstraction layer that absorbs that difference, but only for the games the project has implemented, so the question of which titles are covered is the first thing to check and the README does not answer it directly, the documentation site does.

The third wrong case is a player who wants no overlay at all, or wants a game trainer. HunterPie is a display tool, it shows the game state you can already see plus some you cannot, and the README makes no claim to modifying the game. Anyone looking for a cheat is looking at the wrong project, and the feature list gives no hint of that capability.

The fourth wrong case is a developer who wants to build a general overlay framework. The widget model is shaped around Monster Hunter game state, the native interop layer is specific to reading a game process, and the extension points are the plugin and widget APIs of this project rather than a general component host.

## How it differs from a game trainer or a stat tracker

The comparison worth making is with the other tools in the Monster Hunter modding space, and the difference in approach is about where the information comes from.

A trainer or a cheat engine reads the game memory and writes to it, changing the behaviour of the game. A stat tracker reads the same memory and only displays it. HunterPie is firmly in the second category, and the feature list reflects that, everything on it is a widget that shows a value, a timer, a state or a history. There is nothing in the documented feature set that changes what the game does.

That distinction matters for two reasons. The first is that a display-only tool has a different risk profile, since it does not interfere with the game process in a way that anti-cheat systems or the game's own integrity checks would object to. The second is that it is a legitimate companion to a game rather than a way to get an advantage in it, which is why the project can be distributed on Nexus Mods and can be used with online play without the complications that come with modification.

The second difference is the plugin and widget architecture. A typical trainer is a single application with a settings panel, and adding a display means editing it and shipping a new build. HunterPie separates the overlay into documented widget modules with a plugin system and custom widgets, so the set of things on screen is composed rather than fixed, and each widget has its own documentation page describing its behaviour.

The third difference is the data source for the widget content. The Player HUD, the damage meter and the wirebug widget all need values that the game does not put on screen, or puts on screen in a form that is not usable. Getting them means the native interop layer and the per game platform abstractions, and that is the part of the project that is genuinely hard, since it has to be reworked when the game is patched, which is what the frequent release tags are responding to.

## Conclusion

HunterPie fits a Monster Hunter player on Windows who wants a damage meter, a monster widget, wirebug and abnormality tracking and Discord Rich Presence without paying for a premium overlay. It does not fit anyone on macOS or Linux, since the runtime, the native interop and the installer are all Windows shaped, and it does not fit a developer looking for a general overlay framework. Before installing, note that the binaries need the .NET Desktop Runtime 10.0 and that the README asks you to extract the archive somewhere other than the Desktop because of write permission issues, and note that the current release is v2.14.0.466 from 2026-08-14 with the last push on 2026-08-20.

## FAQ

### How do I install HunterPie?

Download the binaries from Nexus Mods or from the HunterPie-v2 GitHub releases, extract them somewhere other than the Desktop because of write permission problems, and run HunterPie.exe. The overlay requires the .NET Desktop Runtime 10.0 for Windows x64.

### What widgets does HunterPie v2 include?

The README lists the Monster Widget, Abnormality Tray Widget, Wirebug Widget, Activities Widget, Chat Widget, Damage Meter Widget, Specialized Tool Widget and Player HUD Widget, each with its own documentation page, plus a Clock Widget, Discord Rich Presence, automatic save backups and export of completed quests.

### What language and runtime is HunterPie built on?

It is a C# project on the .NET Desktop Runtime 10.0. The solution is split into HunterPie.Core, HunterPie.Core.Tests, HunterPie.DI, HunterPie.Integrations, HunterPie.Native, HunterPie.Platforms, HunterPie.UI and HunterPie.Playground, plus an Installer project, and the project is Apache-2.0 licensed.

### How do I contribute a new widget to HunterPie?

The README asks that you open an issue before opening a pull request, so the strategy for a new feature can be discussed first, and that you follow the project coding style. The repository also carries shared editor settings and a sonar-project.properties file for its quality workflow.

### How often is HunterPie released?

Frequently. The tagged versions are v2.14.0.464 on 2026-08-05, v2.14.0.465 on 2026-08-07 and v2.14.0.466 on 2026-08-14, and the last push to the main branch was on 2026-08-20. The version badge in the README reads from an API endpoint rather than being hard coded.

## Sources

- [HunterPie/HunterPie on GitHub](https://github.com/HunterPie/HunterPie)
- [License: Apache-2.0](https://github.com/HunterPie/HunterPie/blob/main/LICENSE)
- [Project website](https://hunterpie.com/)
- [README](https://github.com/HunterPie/HunterPie/blob/main/README.md)
- [Releases](https://github.com/HunterPie/HunterPie/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hunterpie-hunterpie