Start by establishing whether the server loaded the file, whether the relevant mob/group and item references exist, and whether this kill was eligible for that drop rule. Only then interpret the configured chance.
Check format and references first
Compare the changed block with a known-working block from the same branch. Check group boundaries, required fields, duplicate identifiers, the mob target and each item VNUM. If the server starts without the changed file but fails with it, capture the parser/startup error before trying repeated kills.
Then identify the rule type and its eligibility conditions. A field can be a weight, a rate, a threshold or a branch-specific parameter; the number 10 does not universally mean a ten-percent independent chance. Determine the semantics from the actual parser and drop implementation.
Why a small test can mislead
In an explicitly hypothetical model where every eligible attempt has an independent 1% chance, the chance of seeing zero successes in 100 attempts is 0.99 raised to 100, about 36.6%. That calculation does not describe every Metin2 drop mode; it explains why a short no-drop run alone cannot prove a broken one-percent rule.
Test record:
Build/data revision:
Rule type and its actual chance semantics:
Mob/group/item identifiers:
Eligibility conditions:
Number of eligible attempts:
Observed successes:
Other rates/events affecting the test:Test one hypothesis
Use staging and one known item. Change one condition at a time, record the outcome and restore the intended rate afterward. Keep parser failures separate from runtime rules and random outcomes.
References
A mob_drop_item startup-error question and a discussion of different drop fields show why format and rule semantics matter. The diagnostic sequence and hypothetical probability example here are original; they are not a claim that every numeric field in those threads is interpreted identically by your branch.