Tags
Creators
Details
Licensed ARR
Published last year
Updated 3 months ago
All versions
1.3.0
Release
Lifesteal Plugin 1.3.0last year 373
Compatibility
Minecraft: Java Edition
1.21–1.21.7
Platforms
Bukkit
Paper
Purpur
Spigot
Changes
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 |
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:pZ4D6mrk:ObrlBmoD"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:pZ4D6mrk:ObrlBmoD"
}

