At a glance
Quick facts
- Strongest evidence
- Deployed code/configuration plus a controlled live test
- Engine default
- A reproducible baseline, not proof of a production server setting
- Owner statement
- Authoritative for intent, subject to live verification
- Community report
- Useful corroboration, not sufficient for exact formulas by itself
Every exact fact needs a profile
Open Tibia servers deliberately modify the game. A fact such as Dragon has 1,000 health is meaningful only when attached to a profile such as TFS 1.6 reference data or verified on Server X at a specific date. Without that profile, accurate source data can become false production information.
| Layer | What it establishes | What it cannot establish alone |
|---|---|---|
| Official documentation | Current official-game rules and terminology | A private server copied those rules |
| Engine tag or commit | The implementation at that source revision | The live server deployed it unchanged |
| Data pack and configuration | Configured values and content definitions | Runtime scripts or database overrides are inactive |
| Owner-verified statement | The intended production rules | The deployment matches the statement |
| Controlled live test | Observed behavior under recorded conditions | Every untested branch behaves the same |
| Community report | Potential issue, change, or player experience | Exact causation without reproducible evidence |
Publication status model
| Status | Minimum evidence | Presentation rule |
|---|---|---|
| Source-backed | Pinned primary source and named profile | Exact values may be indexed with the profile visible |
| Owner verified | Authenticated owner claim plus source or live corroboration | Show owner verification date and changed fields |
| Observed | Controlled live test with conditions and timestamp | Describe the test boundary; do not generalize beyond it |
| Partial | Some facts sourced; material gaps remain | Do not place in the main index or sitemap as a complete guide |
| Disputed | Credible sources conflict | Show both claims, evidence dates, and the unresolved question |
| Retired | Historical profile no longer deployed | Preserve for history with a prominent archival label |
Mechanic verification procedure
- 01
Identify the deployment
Record engine family, tag or commit, client protocol, data pack, world, and test date.
- 02
Collect intended values
Read configuration, XML, Lua, database values, and owner documentation.
- 03
Trace the execution path
Find the code and callbacks that consume those values, including ordering and rounding.
- 04
Construct a controlled test
Change one variable at a time; fix level, skill, equipment, target, zone, and random sample size.
- 05
Retain evidence
Store exact input, logs, observed output, commit identifiers, and screenshots where useful.
- 06
Publish the boundary
State what was proven, what remains server-dependent, and when the result should be rechecked.
Change control for a living directory
- Hash or version source snapshots so a later upstream edit cannot silently change the evidence.
- Separate automated telemetry fields from editorial mechanics fields.
- Require authenticated owner edits to produce an audit event with old value, new value, actor, and timestamp.
- Re-run targeted checks after engine updates, season resets, balance patches, map changes, and website relaunches.
- Expire volatile claims such as online counts and event schedules; retain stable formula profiles until a source changes.
- Never fill missing facts by copying another server with a similar client version or map label.
Apply the guide
Find servers using this profile
Server names, protocol labels, and map labels do not guarantee matching mechanics. Use these filters to find candidates, then verify the listing, owner documentation, and deployed ruleset.