Rpg Maker Developers Group

Original Source

• Original title: MZ YS_ExtraDrop
• Original author: YamiSakin
• Original date: May 19, 2026
• Source thread: https://forums.rpgmakerweb.com/threads/ys_extradrop.183707/
• Source forum path: Game Development Engines > RPG Maker Javascript Plugins > JS Plugin Releases (RMMZ)

Summary

YS_ExtraDrop (v4.0) Creator: YamiSakin { "lightbox_close": "Close",

Archived First Post

YS_ExtraDrop (v4.0)
Creator: YamiSakin

Introduction
YS_ExtraDrop is a comprehensive loot expansion and reward management engine designed explicitly for RPG Maker MZ. It modernizes how enemies distribute rewards by moving completely away from the rigid percentage slots found in the default editor. The plugin works via intelligent backend interceptors, completely reorganizing the victory reward loop without taxing your game's frame rate during intensive combat sequences.

By handling data indexing, text parsing, and string comparisons exactly when the database loads, the engine can execute conditional scripts, calculate complex mathematical formulas, track drop streaks, and inject scaled items instantly the second an enemy is defeated. It provides game designers with total control over drop tables, bad-luck protection mechanisms, and state-dependent environmental rewards. All source code references and raw symbols have been removed from this guide to ensure a clean, purely descriptive text presentation.

Features/Notetags
This section details how to structure your configurations within the Notes field of your Database. Every parameter must be separated correctly to be processed by the engine during startup.

The Master ContainersAll drop instructions must reside within a valid block container. Anything written outside of these tags inside the notes box will be ignored by the engine.

• Local Enemy Pools: This container tells the engine that the lines inside belong directly to the enemy hosting them. It isolates loot data for specific encounters.
• Global Drop Tables: This container registers a named array in the shared game memory. This creates a reusable master list. You can build these lists inside an enemy note box or dedicate completely blank dummy entries in your database to act as separate loot storage files.

Line Syntax Breakdown
Inside a container, every single line represents an individual loot rule. The system reads each rule from left to right using a precise structural pattern. Every piece of the line serves a specific mathematical or logical purpose:

• Item Classification Identifier (Optional): You can prefix your line with specific terms to designate the item category. This explicitly forces the engine to look into that specific database tab. If you omit this identifier, the system defaults to searching the standard item database tab automatically.
• Target Designation (ID or Name): You can type the exact numerical ID of the item or its literal name as written in your database. If choosing to write out names, ensure they match perfectly and avoid trailing spaces after the text.
• Probability Coefficient: Represents the base drop rate. You can input a fixed percentage number from zero to one hundred. Alternatively, you can input a dynamic formula enclosed within evaluation brackets. Inside these brackets, you can use core engine value variables or active switches to adjust the drop rate dynamically based on game progression, player level, or team stats.
• Quantity Evaluator (Optional): Expressed using a quantity indicator connected to an integer. A single value forces exactly that number of items to drop if the probability check succeeds. A ranged bound triggers a chained evaluation loop. The engine rolls for the first item, and if successful, runs consecutive probability checks for subsequent copies until a roll fails or the maximum range boundary is reached.
• Bad Luck Protection (Optional): Expressed by entering a pity tracking indicator connected to an integer. This activates a persistent failure counter tied directly to the player's save file. Every time this enemy is defeated and the item fails to drop naturally, the internal counter increases by one. When the counter reaches your specified integer, the engine bypasses the probability coefficient entirely, forces the item to drop, and resets that item's specific failure tracker back to zero.
• The Logical Conditional Gate (Optional): Created by inserting a separating vertical divider line at the end of your item configuration. Anything to the right of this vertical line is treated as a hard conditional gate. If the statement evaluates to false, the entire line is skipped instantly, ignoring both natural drop rates and active pity counters.

Advanced Condition Shorthand Dictionary
To make writing conditional gates easier, the engine translates simplified keywords into deep engine scripts behind the scenes. You can combine multiple conditions on a single line using logical connectors to require that all conditions are met, or alternative connectors to allow any of them to pass.

• Switch ID Checking: Validates whether a specific storyline switch is currently turned on.
• Variable Value Checking: Compares a designated game variable against a target control value using standard mathematical comparison rules like greater than, less than, or equal to.
• Inventory Stock Checking: Checks how many copies of a specific item the party currently holds in their shared inventory.
• Active Lineup Checking: Evaluates the exact number of active members inside the immediate battle team.
• Environment Time Checking: Automatically hooks into your registered global time tracking system to instantly check the current environmental day or night cycle phase.

How to Use

1. Place the plugin script file inside your project directory subfolder dedicated to game plugins.
2. Open your editor, enter the Plugin Manager, select the file, and toggle its status to active.
3. Set your general project parameters, such as registering your core hour variable identity if planning to use automated time-of-day condition keywords.
4. Open your database, go to the Enemies tab, and use the notes box area to define your reward pools using the structural rules explained below.

In-Game Note Box Setup Examples

General Drop Table Template (e.g., Assigned to Dummy Enemy ID 50)​

<Drop Table: Grassland_Pool>
Item Potion: 50 x1-2
Antidote: 35
Item 15: 60 x1-3
Item 22: 20 pity:5
</Drop Table>

Call Global Table inside a Regular Monster Box (e.g., Slime or Wolf)​

<Extra Drops>
Table: Grassland_Pool
Item 34: 40 pity:10
</Extra Drops>

High-End Boss with Guaranteed Legendary Equipment​

<Extra Drops>
Weapon King_Blade: 5 pity:20
Armor Imperial_Shield: 8 pity:15
Item 55: 12 pity:10 x1
</Extra Drops>

Advanced Crafting Materials with Chained Iterations (Ranged Bounds)​

<Extra Drops>
Item Mithril_Shard: 25 x1-5 pity:8
Item Dragon_Scale: 15 x1-3 pity:12
</Extra Drops>

Day/Night Alternation and Quest Progression Gates​

<Extra Drops>
Item Night_Flower: 80 | nighttime
Item Solar_Essence: 75 | daytime & sw:5
Armor Shadow_Cloak: 15 pity:25 | nighttime & v:10 >= 3
</Extra Drops>

Party Scaling Hurdles & Inventory Saturation Checks​

<Extra Drops>
Item Field_Rations: 90 x2 | partysize == 4
Weapon Hunter_Dagger: 40 | item:15 == 0
Item 10: 50 | v:12 < 50 & partysize >= 3
</Extra Drops>

Real-Time Probability Alteration based on Party Level or Game Values​

<Extra Drops>
Item Energy_Crystal: {Math.min(90, $gameVariables.value(10) * 3)} x1
Weapon Battle_Axe: {$gameParty.highestLevel() >= 30 ? 50 : 5} pity:40
Item 18: {$gameParty.gold() < 1000 ? 70 : 15} | sw:8
</Extra Drops>

Ultimate Secret Boss Configuration Array​

<Extra Drops>
Table: Grassland_Pool
Weapon Soul_Reaper: {sw:50 ? 25 : 2} pity:50 | nighttime & sw:20
Armor Adamant_Mail: {Math.max(10, $gameVariables.value(5))} pity:30 | partysize == 4
Item Phoenix_Egg: 1 x1 pity:100 | sw:20 & item:85 == 0
</Extra Drops>

Plugin Commands / Script Calls
This system focuses on a pure automation experience using database notes parsing and native victory loop interceptors. To maximize compatibility with external layout frameworks and prevent bloat in your global game save variables, all configuration values, dynamic formulas, and structural boundaries are managed exclusively through the note tags format detailed above, leaving map event logic clean and decoupled.

DownloadThe official, tested versions of this engine are hosted across these distribution networks:

• Itch.io Project Distribution Page: Garbage Crew Itch.io

Terms and Credits

• Commercial Use: Fully authorized for use in both free and commercial game packages.
• Mature Content Restrictions: Permitted for use in games containing mature, horror, or adult content.
• Code Customization: You are free to modify or extend the source file to fit your project's needs.
• Attribution: Credit must be assigned to YamiSakin within your game's credits file or ending sequence. No secondary framework credits are required.

Author Note & Developer Support
If you decide to integrate this plugin into your project, please leave a comment on this thread or drop me a direct message letting me know you are using it! Keeping track of active projects helps me immensely, and by letting me know you are running the system, I can prioritize and assist you directly with any advanced syntax calibration, troubleshooting, or formula adjustments without any issues.

Features Mentioned

• This section details how to structure your configurations within the Notes field of your Database. Every parameter must be separated correctly to be processed by the engine during startup.
• The Master ContainersAll drop instructions must reside within a valid block container. Anything written outside of these tags inside the notes box will be ignored by the engine.
• Local Enemy Pools: This container tells the engine that the lines inside belong directly to the enemy hosting them. It isolates loot data for specific encounters.
• Global Drop Tables: This container registers a named array in the shared game memory. This creates a reusable master list. You can build these lists inside an enemy note box or dedicate completely blank dummy entries in your database to act as separate loot storage files.
• Line Syntax Breakdown
• Inside a container, every single line represents an individual loot rule. The system reads each rule from left to right using a precise structural pattern. Every piece of the line serves a specific mathematical or logical purpose:
• Item Classification Identifier (Optional): You can prefix your line with specific terms to designate the item category. This explicitly forces the engine to look into that specific database tab. If you omit this identifier, the system defaults to searching the standard item database tab automatically.
• Target Designation (ID or Name): You can type the exact numerical ID of the item or its literal name as written in your database. If choosing to write out names, ensure they match perfectly and avoid trailing spaces after the text.
• Probability Coefficient: Represents the base drop rate. You can input a fixed percentage number from zero to one hundred. Alternatively, you can input a dynamic formula enclosed within evaluation brackets. Inside these brackets, you can use core engine value variables or active switches to adjust the drop rate dynamically based on game progression, player level, or team stats.
• Quantity Evaluator (Optional): Expressed using a quantity indicator connected to an integer. A single value forces exactly that number of items to drop if the probability check succeeds. A ranged bound triggers a chained evaluation loop. The engine rolls for the first item, and if successful, runs consecutive probability checks for subsequent copies until a roll fails or the maximum range boundary is reached.
• Bad Luck Protection (Optional): Expressed by entering a pity tracking indicator connected to an integer. This activates a persistent failure counter tied directly to the player's save file. Every time this enemy is defeated and the item fails to drop naturally, the internal counter increases by one. When the counter reaches your specified integer, the engine bypasses the probability coefficient entirely, forces the item to drop, and resets that item's specific failure tracker back to zero.
• The Logical Conditional Gate (Optional): Created by inserting a separating vertical divider line at the end of your item configuration. Anything to the right of this vertical line is treated as a hard conditional gate. If the statement evaluates to false, the entire line is skipped instantly, ignoring both natural drop rates and active pity counters.
• Advanced Condition Shorthand Dictionary
• To make writing conditional gates easier, the engine translates simplified keywords into deep engine scripts behind the scenes. You can combine multiple conditions on a single line using logical connectors to require that all conditions are met, or alternative connectors to allow any of them to pass.
• Switch ID Checking: Validates whether a specific storyline switch is currently turned on.
• Variable Value Checking: Compares a designated game variable against a target control value using standard mathematical comparison rules like greater than, less than, or equal to.
• Inventory Stock Checking: Checks how many copies of a specific item the party currently holds in their shared inventory.
• Active Lineup Checking: Evaluates the exact number of active members inside the immediate battle team.

Downloads / Referenced Files

License / Terms Note

Terms and Credits Commercial Use: Fully authorized for use in both free and commercial game packages. Mature Content Restrictions: Permitted for use in games containing mature, horror, or adult content. Code Customization: You are free to modify or extend the source file to fit your project's needs.