Download File

## **ADDED PLACEHOLDERS (GOING ALONGSIDE MINOR IMPORVEMENTS)** --- | Dimension | Description | Status | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | | **1. Resilience Architecture** | Commands and placeholder systems are built to **continue functioning even under partial system failure** (e.g., config loss, null plugin fields, SQL failure, PAPI missing). This is **resilience by design**, not exception handling afterthought. | ✅ | | **2. Graceful Degradation** | Instead of crashing or halting features when a dependency is missing (like PlaceholderAPI or MySQL), your system **downgrades functionality** while maintaining UX continuity (`"Offline"`, `"ERR"`, fallback materials, default config values). | ✅ | | **3. Dynamic Reflection Proxy for Optional API** | `PlaceholderRegistrar` uses dynamic reflection and proxying to register placeholders **without compile-time binding to PAPI**, supporting modular deployment and late binding. This is a **decoupling architecture pattern**. | ✅ | | **4. Semantic Placeholder Decoding Layer** | The use of `switch(identifier.toLowerCase())` with contextual logic (like online checks, config fallbacks) builds a **semantic parser for identifiers**. This design allows for scalable growth (e.g., `%lifesteal_kills_today%`, `%lifesteal_revive_tokens%`). | ✅ | | **5. Config-Driven Control Layer** | All messages, materials, database types, and display elements are **externalized to config**, making the plugin highly **customizable without code changes** — a hallmark of production-tier design. | ✅ | | **6. Contextual Tab Completion DSL** | `AdminTabCompleter` is essentially a **domain-specific suggestion language** for command trees. It parses arg index, subcommand semantics, and sender context to give tailored completions. | ✅ | | **7. Game Rule-Aware Behavior** | Commands like `/withdraw` **respect game logic constraints** (e.g., minimum 1 heart), making the plugin **exploit-resistant and gameplay-consistent**. This isn't just a check — it **enforces the design of the gamemode**. | ✅ | | **8. Structural Plugin Isolation** | Every subsystem (`BanManager`, `HeartManager`, `ConfigManager`, etc.) is accessed through clear, isolated interfaces, with plugin-safe guards. There is **no deep structural coupling**, supporting unit testability and future refactors. | ✅ | | **9. Developer-Aware Feedback System** | Logger messages are structured, scoped (`[PlaceholderAPI]`), and precise — aiding devs with **immediate traceability** on user-side issues (like SQL faults or PAPI issues). | ✅ | | **10. Deferred Execution Awareness** | SQL-heavy operations are guarded and designed to be **lightweight in the main thread**, preparing for future **asynchronous conversion**, especially for placeholders. | ⚠️ *Ready for async, but not async yet* | | **11. Plugin Reload Safety** | All commands and placeholders support `plugin.getConfigManager().reload()` and react immediately to config changes, enabling **hot-reload capability** and **zero-downtime admin operations**. | ✅ | | **12. Internal Type Normalization** | The use of `.toLowerCase(Locale.ROOT)` and guards like `safeString(...)` ensure **locale-agnostic and NPE-safe string handling**, which is **internationalization best practice**. | ✅ | | **13. Minimal Surface Area Exposure** | The command classes expose only necessary logic; `onCommand` and utilities are **not overexposed** via public static or deep inheritance. This limits accidental misuse and encourages encapsulation. | ✅ | | **14. Performance-Aware Inventory Handling** | Heart item creation (`ItemBuilder`) happens **only if checks pass**, and only 1 item is created and added, minimizing GC and lag. | ✅ | | **15. Command Feedback Templating** | Every message supports `{player}`, `{tier}`, `{amount}` tokens — making it **dynamic, parseable, and reusable**, not hardcoded. This bridges with chat plugins and structured JSON systems. | ✅ | | **16. Compatibility-Aware Versioning** | `getVersion()` in placeholders is dynamically retrieved from plugin metadata — no static literals — maintaining compatibility and correct display in admin panels. | ✅ | --- ## CURRENTLY SUPPORTED PLACEHOLDERS! | Placeholder | Purpose | | ---------------------------- | --------------------------------------------- | | `%lifesteal_hearts%` | Player's current hearts (if online) | | `%lifesteal_maxhearts%` | Max hearts from config | | `%lifesteal_is_banned%` | Whether the player is banned | | `%lifesteal_database_type%` | Database type ("mysql"/"sqlite") | | `%lifesteal_lang%` | Active language config file | | `%lifesteal_startinghearts%` | Configured starting hearts | | `%lifesteal_prefix%` | Plugin prefix string | | `%lifesteal_online%` | Is player currently online | | `%lifesteal_ban_reason%` | (Hardcoded for now) "Out of hearts" if banned |