A permission-first, server-authoritative menu framework that turns chaotic admin panels into calm, elegant operator consoles.
PF-vMenu is not simply another trainer overlay or a hastily stitched-together admin panel. It is an opinionated philosophy about how authority should feel inside a live game session. Every action an operator performs flows through a carefully stratified permission lattice, meaning the server owner — not the script — dictates the boundaries of behavior. The menu is the interface; the permission engine is the soul.
Inspired by the elegance of MenuAPI-driven interfaces but reimagined for the modern operator, this project treats every menu open as a small ceremony: deliberate, permission-checked, and server-verified. Nothing happens client-side that the server has not sanctioned first.
Where other menus blindly trust the hand that clicks, this one asks first, verifies twice, and logs everything.
Think of PF-vMenu as a trust architecture with a beautiful face. It is the difference between a bouncer who checks IDs at the door versus one who waves everyone through and hopes for the best. Here, every menu category, every toggled feature, every sub-action is gated behind an explicit permission node that the server maintains.
This design has three silent superpowers:
- Predictability — Operators always know what they can reach.
- Auditability — Every elevation is traceable to a role.
- Safety by default — A misconfigured client cannot invent authority it was never granted.
- 🔐 Granular Permission Lattice — Role-based nodes let you carve access down to individual actions, not just whole menus.
- 🖥️ Fully Server-Authoritative Logic — The menu is a puppet; the server pulls the strings.
- 🎨 Responsive Interface Layout — Adapts fluidly to varying resolutions and UI scaling without breaking alignment.
- 🌍 Multilingual Menu Strings — Ship the interface to operators around the globe with locale-aware labels.
- 🛡️ 24/7 Operator Support Readiness — Built so that even at 3 a.m. the person on shift can find what they need.
- 🧩 Modular Category System — Add, remove, or reorder feature groups without rewriting the core.
- 🕹️ Live Toggle Feedback — Visual state confirmation so no one guesses whether an action landed.
- 📜 Action Audit Trail Support — Hook into your own logging pipeline for full accountability.
- ♻️ Hot-Reload Config Surface — Adjust permission maps without restarting the whole session.
- 🧱 Framework-Agnostic Bridges — Designed to sit atop MenuAPI while remaining adaptable to surrounding stacks.
There is a persistent myth that menus should run where the player is, because it feels faster. Speed, however, is not the same as correctness. A menu that runs on the client is like a suggestion box in a building with no manager — anyone can slip in whatever they want.
PF-vMenu flips the equation. The client renders, the server decides. This separation produces a system that is:
- Resistant to local tampering — The client cannot pre-elevate itself.
- Consistent across players — Everyone sees the same truth.
- Easier to debug — Logs live in one authoritative place.
This is the quiet strength of server-sided design: it removes the illusion of control and replaces it with the reality of it.
| Path | Purpose |
|---|---|
src/core/ |
Permission engine, identity resolution, and role mapping |
src/menu/ |
Menu construction, category registry, and item factories |
src/actions/ |
Individual executable features behind permission gates |
src/i18n/ |
Locale files and translation resolvers |
src/logging/ |
Audit hooks and event emitters |
config/ |
Permission matrices and category ordering |
docs/ |
Extended documentation and integration guides |
A lattice is stronger than a wall because it bends without breaking. The permission system here follows the same idea: instead of a single yes-or-no gate, you get a hierarchy.
- Root roles inherit the widest reach.
- Mid roles inherit scoped subsets.
- Fine roles touch only the smallest, safest actions.
When an operator opens the menu, the server walks the lattice, discovers which branches their identity can reach, and renders only those. Anything deeper is invisible until earned. This prevents the common failure mode where an operator sees options they cannot use — a small UX wound that erodes trust over time.
Menu labels are pulled from locale files, so a server community in one region can read the menu as naturally as a community in another. Adding a language is as simple as introducing a new translation file and declaring its identifier in the configuration. The interface gracefully falls back to a default locale, ensuring no operator ever stares at a blank label.
This matters more than it seems: an operator in the middle of a stressful session should never have to mentally translate their own tools.
Every toggle, slider, and submenu was designed with a single question in mind — "Can this be understood in under a second?" That constraint forced a few delightful decisions:
- Confirmation states mirror the server's answer, not a hopeful guess.
- Category icons stay consistent so muscle memory develops quickly.
- Feedback occurs without page thrash, keeping the session flow intact.
The result is a menu that feels less like a control panel and more like a well-trained assistant.
Building on top of this framework is intentionally gentle. You define a category, attach a permission node, register your action handler, and the server handles the rest — authorization, rendering, feedback, and logging all coordinate automatically.
Because the architecture is decoupled, you can add an entirely new feature family without disturbing existing ones. That modularity is why servers running this framework tend to grow features without collapsing under their own weight.
This repository is intentionally structured so that anyone searching for a server-sided trainer menu, a permission-aware admin panel, a MenuAPI-based interface framework, a role-based command surface, or a multilingual in-game menu system can find it naturally. Keywords are woven into the documentation rather than stuffed, because a README that reads like a directory listing helps no one.
Relevant phrases you might encounter naturally across the project include: server-authoritative menu framework, role-based access control for game servers, permission-gated feature toggles, responsive in-game UI, and localizable menu strings — each used where it genuinely belongs, never gratuitously.
Here are a few real-world style situations this framework handles gracefully:
- A new moderator joins — The server owner assigns a scoped role; only the relevant features appear.
- A senior admin needs temporary elevation — Roles can be rebalanced without redeploying code.
- A community expands into a new language region — A locale file is added; the menu updates for those operators automatically.
- An incident needs review — The audit trail reveals which role performed which action and when.
Each of these scenarios shares a theme: change should be safe, visible, and reversible.
Security here is not an afterthought bolted on at the end. It is an architectural premise. Because all authority is resolved server-side, a compromised or modified client simply cannot conjure permissions that were never assigned. The server is the single source of truth, and the client is a respectful guest.
Additional safeguards include:
- Strict permission checks before any action dispatch.
- Role inheritance that cannot be escalated by the client.
- Optional logging hooks for external monitoring pipelines.
Support is imagined as a 24/7 readiness model — not that humans are awake in every timezone at every hour, but that the documentation, examples, and configuration clarity are strong enough that most questions answer themselves. When they don't, the community channels and issue tracker pick up the rest.
If you find a bug, an unclear label, or a feature you wish existed, opening an issue is the highest compliment this project can receive.
PF-vMenu is provided as-is, for server operators who understand and accept the responsibility that comes with authority inside a shared environment. The authors are not liable for misuse, misconfiguration, or unintended consequences arising from granting permissions too broadly or too narrowly. Always review your role matrix before deploying to a live session. Always test in a staging environment. Always keep backups. The power this framework grants is only as safe as the hands that configure it.
This project is distributed under the MIT License. See the full text at the canonical license page:
Copyright (c) 2026 — PF-vMenu contributors.