เอกสารภาษาอังกฤษ

หน้านี้ยังไม่มีฉบับภาษาไทย จึงแสดงฉบับภาษาอังกฤษพร้อมแหล่งอ้างอิง

Advancing a Thai RO world through historical patches

The requested history now includes Alpha and international Beta as explicit preludes, followed by original Thai beta and progression to the state before the announced November 9, 2010 Thai Renewal maintenance. No Thai Alpha deployment has been established. The design below is proposed; no game server, database migrations or generated emulator patches are implemented yet.

Version the world, not just the episode label

Use one pinned modern emulator with a narrowly maintained historical policy layer. Generate a complete configuration/data snapshot for each selected stage from normalized source data. Upgrading means activating a reviewed stage delta, not updating to arbitrary upstream HEAD or importing an old server executable.

Every stage needs independent versions for:

1. Natural HP/SP recovery, skill recovery and item healing.
2. Combat/status formulas, skill costs and durations.
3. Base/job requirements, monster awards and allocation policies.
4. Monster combat data, AI, skill lists, spawns and respawn rules.
5. Drop slots, MVP rewards, item properties, shops and refining rules.
6. Maps, collision caches, warps, NPCs, quests and enabled classes.
7. Client protocol, map resources, UI capability and Thai text.
8. Character/account schema and explicit migration policy.

The chronological catalogue lives in research/timeline.json. Initial stages cover Thai beta, early additions, Comodo, Turtle/WoE and Juno; the later milestone spine reaches the proposed final pre-Renewal content ceiling. It deliberately retains undated and unsupported stages. A milestone spine is not a complete patch history: minor balance updates and event expiries must be inserted as they are recovered.

Korean numbering cannot determine Thai order. A feature may precede or follow its usual international episode bundle. Keep test-server dates, publication dates, announced schedules and confirmed Thai production dates in separate fields.

Each patch is an explicit transition

A future installable manifest should contain:

{
  "id": "thai-stage-transition",
  "from_stage": "prior-stage",
  "to_stage": "next-stage",
  "engine_commit": "full-sha",
  "source_snapshot_hash": "sha256",
  "client_profile": "verified-profile-id",
  "world_operations": [],
  "character_migrations": [],
  "historical_unknowns": [],
  "qualification": "research_only"
}

Operations need expected old values as well as new ones, stable entity identifiers, explicit additions/deletions, source references, regional scope, and evidence status. Preserve raw source values beside normalized values and the converter's format version. A percentage change without established absolute endpoints remains a claim, not an executable operation.

Complete generated stage snapshots prevent later items, quests and spawns from leaking through a modern base. Check each emulator's actual database-loader replacement/merge behavior before relying on import overlays: replacing a monster record does not necessarily delete every inherited drop or skill.

Do not treat these candidate examples as ready-to-apply patches:

• A flat SP skill profile transitioning to a MaxSP-scaled profile.
• A Mummy stat/reward replacement tied to a verified Thai balance date.
• A selective Poring-card change once the absolute probability and roller behavior are established.

Keep character continuity explicit

The user wants to keep playing as the world advances. Default design is continuity with backups; original administrative wipes, level reductions and economy resets are separate historical operations, not hidden side effects of selecting an episode.

For every EXP-table transition choose and record how existing characters migrate: preserve cumulative EXP, preserve level plus progress fraction, or reproduce a specifically evidenced historical migration. These are different experiences. Do not silently choose a conversion when the original behavior is unknown.

A future stage upgrade should:

1. Verify the current stage/engine/client hashes and the next manifest's prerequisites.
2. Stop new writes, checkpoint characters/world state and retain the prior generated snapshot.
3. Produce a human-readable before/after plan including disabled items, maps and jobs.
4. Apply data and character migrations once, with a durable migration receipt.
5. Start the target stage, run focused acceptance checks and record actual hashes.

Recover from a failed migration with the matching checkpoint, never by assuming reverse SQL can reconstruct lost character state. Jumping backward to a stage without a job or item needs a separate policy.

Qualification before calling a stage authentic

Research stage -> normalized candidate -> generated build -> runtime checks -> historically qualified stage.

Evidence confidence and software-test status are separate. A bug-free implementation of an unsupported historical formula remains a candidate.

Area	Useful acceptance checks
Recovery	Log individual server-side increments over 60 seconds at fixed effective stats and MaxHP/MaxSP; compare standing, sitting, walking, 49.9%/50% weight, death and buffs. Distinguish passive skill ticks from natural ticks.
EXP	Known per-level requirements; solo kill reward; split damage; party splitting/level limits; MVP; death; overflow and multi-level caps. Log integer inputs and outputs.
Monsters	Fixed player versus fixed monster fixture; HP, ATK endpoints, DEF/MDEF, accuracy, attack/movement timing and skill conditions. Stats alone are not combat proof.
Drops	Inspect roller algorithm and normalized units; deterministic RNG boundary tests, independent duplicate slots, no-drop possibilities, MVP reward ordering and special bonus paths. Statistical runs supplement this; rare-card absence in a small sample proves little.
Spawns	Enumerate enabled maps, counts and delays; ensure later monster/quest/event content is absent.
Client	Login/character/map handoff; Thai text; old map resources and collision; NPC coordinates and warps; permitted job/UI behavior.
Upgrade	Same character retains intended state after patch; migration is idempotent; checkpoint recovery works.

Compare with a contemporary official source or an authenticated AEGIS build when available. Modern emulators and old Athena are comparison subjects, not the historical oracle.

Emulator decision

Current research does not establish a historical-accuracy winner. Both need era data and policies; both have later pre-Renewal behavior. rAthena's YAML data is convenient for generated stage snapshots. Hercules offers HPM extension points, but hook coverage for recovery, EXP and loading must be verified before promising a plugin-only implementation. Keep an ordinary core patch available when a hook cannot safely express a rule.

Select after qualifying one small early-world scenario: novice/first job, Poring/Fabre, one relevant higher-level monster, natural and passive recovery, exact EXP, and known drops. This exposes the missing work before committing to full migration.

The current files support that investigation. They do not yet provide a beta profile ready to play or an automatic historical patcher.

---

อ่าน Markdown ต้นฉบับ