Taking a researched patch to a local release
Timeline · Developer guide · Player guide
This is the future release procedure. The current handbook contains research and draft specifications; no emulator, client, game database or migration has been changed.
1. Freeze the intended change
Choose the chapter and its release group in release-plan.json. Historical dates describe the original service. Assign a separate local date only when the release is ready to schedule. Morroc and Moscovia are two chapters in one Thai Episode 12.1 bundle; they should not accidentally become successive local episodes.
Record the starting stage, target stage, exact engine commit, client profile, complete world snapshot and source-register revision. List unresolved history with a decision for each: defer the feature, use a clearly labelled reconstruction, or obtain stronger evidence. A passing software test cannot resolve a historical unknown.
2. Write the before/after specification
For every changed rule or record, retain entity ID, old value, new value, units, rounding, applicable realm, source, evidence status and effective local stage. Specify removals as well as additions. Unchanged data needs an explicit inherited profile; an empty field must not silently import a modern default.
Cover natural recovery, passive recovery, item healing, EXP requirements and awards, monster stats/skills/spawns, drops, shops, quests, maps, jobs and client behavior. Treat temporary rates and events as separate overlays with eligibility, start, expiry and stacking rules.
3. Review character continuity
The intended local experience is a continuing character journey. Document any departure from original administrative wipes. For changed EXP curves, choose how levels and progress convert. Check inventory, equipped items, cards/refines, learned skills, pets, guilds, instance timers, quest flags, saved locations and warp memos.
Produce a readable migration preview. Back up characters and shared world state together with the matching engine/data/client manifest. A rollback restores that checkpoint; reverse arithmetic alone cannot recover destroyed items or lost quest state. Define how later characters and writes are handled if rollback happens after reopening.
4. Qualify the build
- Run the chapter's acceptance checks with known input/output fixtures and the exact candidate snapshot.
- Check the complete allowed-content set: later items, maps, jobs, quests and skills must not leak through alternate entry points.
- Verify the migration once, a harmless repeat, an interruption, and restoration from the checkpoint.
- Exercise the affected player path through the intended client, including Thai text and map collision/NPC alignment.
- Keep runtime evidence separate from historical evidence. Record the build hashes, results and remaining limitations.
These checks become executable work only after emulator implementation is authorized. They have not been run against a game server in this research task.
5. Prepare the player release note
Use the chapter's player guide as the draft. Replace conditional wording with only the verified local behavior. State the local date, newly available content, changed mechanics, preparation needed, continuity policy, temporary event expiry and known limitations. Include historical sources as background without suggesting that an approximation is an official Thai formula.
6. Release and record the result
When deployment is separately authorized, checkpoint, apply the reviewed migration, validate the live stage and record the actual local activation time. Update the release manifest and player notes together. Keep historical dates unchanged. If qualification fails, leave the local stage unadvanced and retain the evidence needed to diagnose it.
Release record template
| Field | Required entry |
|---|---|
| Historical chapter / release group | Stable IDs from the handbook |
| Local transition | Current stage → target stage; scheduled and actual local dates |
| Build | Engine commit, client profile and world snapshot hashes |
| History review | Accepted facts, explicit approximations and deferred gaps |
| Character migration | Policy, preview, checkpoint and migration receipt |
| Validation | Chapter checks, content exclusions, client path and restore result |
| Player communication | Final local patch note and preparation guidance |
| Result | Unreleased, qualified, active or restored; evidence link |
The progression design explains the proposed snapshot and migration architecture in more detail.