Thai beta mechanics: evidence and implementation map

Research date: 2026-10-28. Scope ends before Renewal, as requested.

Update: archive findings now recover original Thai CBT launch/reset policy and the operator's November 9, 2010 Renewal schedule. The patch history adds Alpha/international Beta preludes and separates Thai class rollouts. These additions do not authenticate the Thai CBT natural-recovery formula.

The Timeline Bible now joins 38 chapters with developer and player guides in Thai and English. Its mechanics history incorporates original Thai guide pages preserved in December 2003, newly recovered passive-skill tables and additional contemporary recovery discussions. Original documentation can be stale: capture dates are not effective patch dates, and contradictions remain explicit.

The strongest result is the discovery of an inspectable July 2003 Athena implementation with an older recovery model and a 99-row progression table. Its code can explain a plausible early experience, but it is not an official Thai beta implementation. No Thai closed-beta server snapshot has been authenticated in this work.

Evidence rules

Keep four questions separate: what a source contains, what region it describes, when it was effective, and whether the implementation reproduces it. A modern emulator setting or a contemporary Japanese emulator does not answer the Thai historical question by itself.

The source register is sources.json. Each entry records source type, scope and limitations. Primary code and contemporary player observations support specific observations; later mirrors supply provisional historical leads only.

Pinned modern revisions:

• rAthena d4b8e7b8f16061cc2496d377ac8f777ce72a4f39
• Hercules 04a422ce60402c731d9cff0724cca9a5bc3c53e9

Source evidence covers 24 pinned files, fetched successfully. No game client or server was executed.

Natural HP/SP recovery

The archived Athena Dev 2.1.1 source identifies its release as middle July 2003. Archive SHA-256 is 419affcc8d223f2f5591cd0981f9b7bdba034f6f3c8d20c8e5c72b5bf8be86fe. Its map/pc.c has an older accumulator model:

Component	Observed implementation
SP timing denominator	max(300, 7500 - 60 * effective_INT)
HP timing denominator	max(300, 3000 - 15 * effective_VIT - 14 * BaseLevel)
Sitting	Integer-divides the clamped denominator by two
Accumulator increment	floor(1000000 / denominator) + 1 every 250 ms
Recovery	Each 4000 accumulated units provides one point; status updates occur every fourth tick
Gates in this function	Dead or at least 50% weight: no recovery; HP additionally requires not walking

The source explicitly maps effective INT to paramc[3] and effective VIT to paramc[2]; the interpretation does not rely solely on array-index assumptions. Timer registration is part of the inspected source. This is timing dependent on stats, not simply a smaller modern tick amount. The actual visible increment can batch multiple points at high recovery rates.

This candidate has no MaxHP/MaxSP term in natural recovery. That is a concrete distinction from current emulators. It also clamps the SP denominator at INT 120. Do not change that to 124/126 because a later recollection mentions those values, or describe the inverse-linear recovery rate as an established quadratic formula.

Current unmodified player formula bases, before buffs/item modifiers:

Component	rAthena	Hercules
Natural HP amount	floor(VIT/5) + max(1, floor(MaxHP/200))	1 + floor(VIT/5) + floor(MaxHP/200)
Natural SP amount	1 + floor(INT/6) + floor(MaxSP/100)	Same
High-INT SP bonus	At INT >=120, add floor((INT-120)/2) + 4	Same
Configured natural intervals	HP 6000 ms, SP 8000 ms	Same
Configured recovery-skill interval	10000 ms	Same

At VIT 10 / MaxHP 1000, their natural HP amounts are 7 and 8 respectively. At VIT 1 / MaxHP 100 they both yield 1. This is a real static implementation difference, not a determination of which is historically correct. See rAthena recovery and Hercules recovery.

Required change: introduce a versioned natural-recovery policy and its timer/accumulator semantics. Preserve separate sitting, movement, weight, death, status/buff and map rules. Changing natural_healsp_interval alone cannot reproduce the archived model. Do not transplant old socket, account or filesystem code.

Passive recovery skills and consumables

An early Mage guide describes SP Recovery as 3 SP per skill level per ten seconds. A July 2003 Priest guide also describes the flat amounts and forecasts a later change. These are contemporary cross-region observations, not Thai certification.

Both inspected modern implementations calculate the recovery-skill amount as:

• HP: 5 * skill_level + floor(skill_level * MaxHP / 500).
• SP: 3 * skill_level + floor(skill_level * MaxSP / 500).

For level-10 SP Recovery and MaxSP 500, the modern amount is 40, versus 30 under the flat candidate. This must be validated separately from natural SP regeneration. A period Knight guide labels the later natural-recovery system as Juno; a Hunter guide describes the qualitative transition to larger chunks. These do not establish Thailand's exact switch date.

Required change: an independent recovery-skill policy, with period-specific buffs and rounding. For consumables, audit potion/herb base healing, VIT/INT scaling, skill bonuses, weights, shop prices and available drops. Official Juno notes describe reduced healing-item weights. That affects how much a character can carry before losing recovery, so economy and recovery cannot be isolated completely.

EXP requirements versus awards

The historical archive contains 99 rows with four columns. Its loader and consumers identify them as Base, Novice Job, First Job, and Second Job requirements. The row is indexed by current level minus one. Cap sentinel values are not normal playable requirements.

The static comparison with both modern ordinary pre-Renewal tables finds:

Table	Compared transitions	Differences from July 2003 Athena
Base	98	At level 98: archive 99,999,999, both modern tables 99,999,998
Novice Job	9	At job level 2: archive 20, modern 18
First Job	49	None
Second Job	49	None

Therefore the modern ordinary tables are already close to this artifact. It does not establish the September 2002 Thai table or prove that those two differences represent official changes rather than emulator errors. Avoid wholesale table replacement based on nostalgia alone.

Separately version monster BaseEXP/JobEXP; kill-contribution rules; party splitting and level range; MVP bonuses; death penalties; level-up caps; quest EXP; and event/server multipliers. Keep the distinction between per-level requirements and cumulative EXP explicit.

Required change locations:

Concern	rAthena	Hercules
Level requirements	db/pre-re/job_exp.yml	db/pre-re/exp_group_db.conf, job group assignment in job_db.conf
Monster awards	db/pre-re/mob_db.yml	db/pre-re/mob_db.conf
Rates/penalties	conf/battle/exp.conf	conf/map/battle/exp.conf
Allocation and level-ups	src/map/mob.cpp, party.cpp, pc.cpp	Corresponding files under src/map/

Monster candidates and drop semantics

RagnaDB publishes cross-episode data and provenance labels in its public application bundle. Static parsing found no beta-specific monster dataset and no Thai distribution in the timeline. Episode 1 is attributed to a December 2002 archive, Episode 2 to a 2015 RetroPack, and Episode 3 to another 2003 archive. These are candidate datasets rather than verified Thai production snapshots.

Small examples from its Episode-1-labelled candidate versus both modern databases:

Monster	Candidate HP / BaseEXP / JobEXP	Modern HP / BaseEXP / JobEXP
Poring	50 / 2 / 1	50 / 2 / 1
Fabre	63 / 3 / 2	63 / 3 / 2
Mummy	4837 / 717 / 448	5176 / 800 / 602
Doppelganger	12000 / 10680 / 3872	249000 / 51480 / 10725
Savage	1901 / 357 / 226	2092 / 521 / 248

This supports selective comparison, not one universal monster-EXP multiplier. Differences also exist in combat attributes; for example current Mummy has DEX 63 versus candidate 75. Combat formulas and AI still determine how these numbers behave.

Data quality issues discovered:

• Some candidate fields named MaxAtk are smaller than MinAtk. For Mummy, the pair is 328/55, while the July 2003 emulator explicitly stores ATK endpoints 328/383. A base-plus-spread interpretation is plausible but must be checked against original format definitions. Do not import 55 as the maximum attack.
• The Episode-8.2-labelled sample contains Poring EXP 14/7, versus 2/1 in other sampled datasets. That is a sevenfold difference requiring investigation; its cause is not established.
• Repeated drop slots for the same item must remain a list. A dictionary keyed by item name would lose independent rolls or weighting.
• Modern mob_db minimum integer drop-rate units, configured clamps, conditional bonuses and MVP reward ordering must be checked separately from stored rates. In rAthena, drop_rateincrease is an explicit option; matching a rate column does not prove matching effective probability.

The Thai announcement mirror contains candidate evidence of selective card/drop and race/size changes, including a reported tenfold increase for Poring card. It gives no authenticated old/new numerical probabilities or full monster lists. A global 10x card setting would be unjustified. Store a relative change claim with unresolved absolute rates, not a fabricated 0.001% to 0.01% transition.

Required change: version monster records, drop slots, MVP rewards, AI/skills and spawns together. Changing the database without old monster-skill lists and spawn timing would not reproduce the hunting experience.

What remains unresolved

1. An authenticated Thai beta HP/SP model, including passive skills, buffs and status interactions.
2. September/October 2002 Thai level tables, party/death rules and production multipliers.
3. Full original Thai monster/drop/spawn records and their format definitions.
4. Dates separating Thai test, announced and actually deployed balance changes.
5. The exact final Thai pre-Renewal maintenance snapshot. The recovered original notice schedules Renewal for November 9, 2010, corroborated by launch-day reporting; exact server completion times and preceding weekly patches remain unresolved.
6. Matching Thai client map revisions, protocol and localization assets.

The AEGIS archive the user is downloading has not been inspected or authenticated. Matching its README, executable versions, database schema and source files to these candidates is the next major evidence opportunity.

Research artifacts are sufficient to define experiments and locate implementation boundaries. They are insufficient to label a stage an authentic playable Thai beta.

---

Read source Markdown