MoP 5.4.8 Dungeon Finder entrance data (+ Proving Grounds instance_template) - #4
Conversation
23.03.009 added a dungeonfinder_entrance row for dungeon 640 on map 1148, but the server rejected it every boot: Table `dungeonfinder_entrance` has unusable coordinates for dungeon 640 on map 1148; skipping row. >> Loaded 0 Dungeon Finder entrances Map 1148 is ProvingGrounds with InstanceType 5, and MapEntry::IsDungeon() counts MAP_SCENARIO, so MapManager::IsValidMAP requires an instance_template row. There was none. The coordinates were never the problem -- they are corpus-derived and correct. Dungeon 640 is a concrete, corpus-observed LFG destination, so the entrance is kept and the missing lifecycle metadata supplied rather than dropping valid routing evidence. Added as a new 23.03.010 migration because 23.03.009 is already applied; it requires exactly 23.03.009, upserts (1148,0,0,0) idempotently, tolerates the MyISAM/InnoDB split, and validates both the instance row and the dungeon 640 entrance before advancing the version. Also records why areatriggers 610 and 612 still target map 189: it is the only populated Scarlet content (450 creatures / 116 gameobjects, against zero on both 1001 and 1004), so repointing them would send players into empty instances. The inconsistency is deliberate and should stay until spawn data exists. Authored by Codex; migration gates verified against the live schema (db_version and dungeonfinder_entrance InnoDB, instance_template MyISAM) and the inline comment confirmed to parse inside the VALUES list. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3e9c2619c0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Two review findings, both in content this branch adds. P1: the dungeonfinder_entrance shape gate matched information_schema column_type against literals carrying the integer display width -- 'mediumint(8) unsigned', 'smallint(5) unsigned'. MySQL 8.0.19 and later drop the deprecated width, reporting 'mediumint unsigned', so on a supported MySQL none of the six predicates match, v_exact stays below 6, and the update stops at the shape gate on the table it had just created. It never inserts the entrances and never advances the version. MariaDB still reports the width, which is why it passed here. Match on data_type instead, which carries neither width nor sign, and test signedness separately with a LIKE on column_type. Verified against the live schema: the rewritten predicate returns 6 where data_type reads 'mediumint' and column_type reads 'mediumint(8) unsigned', so it holds on both dialects. P2: make_full_WorldDB.sh concatenates Setup and FullDB without applying updates, so a generated FullDB install got the dungeon 640 entrance while instance_template.sql still ended at map 967. The server then rejects that entrance for want of a template row -- exactly what Rel23_03_010 fixes for upgrades, but fresh installs never run it. Seed (1148,0,0,0) in the FullDB table so both paths agree. Rel23_03_010 needs no equivalent change; it gates on storage engines, not column types. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 32f099675f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…th the dump tools Two more review findings on the fresh-install path. The FullDB snapshot is rebuilt by make_full_WorldDB.sh without applying update migrations, so instance_template.sql must already carry every map a destination points at -- IsValidMAP rejects a dungeon without one. The previous commit added only 1148 and missed that the changed areatrigger_teleport targets nine more. Three of those are this branch's doing: 45, 614 and 2567 were repointed from the deprecated 189/289 onto 1001, 1004 and 1007. The other six -- 959, 960, 961, 962, 994 and 1011 -- were already destinations before this branch and their template rows were established by Rel23_02_074 but never folded back into the snapshot, so they were broken on fresh installs already. Fixing three and knowingly leaving six is worse than fixing the file, so all nine are seeded with the values the live database carries (0,0,0), verified rather than invented. Separately, dungeonfinder_entrance was absent from both dump tools: Tools/dump_tables.sh and Tools/backupDB.cmd each jump from disenchant_loot_template straight to dungeonfinder_item_rewards, where the new table sorts between them. Regenerated FullDB data would silently go stale and Windows backups could not restore the table or its row. Added to both, preserving their CRLF line endings. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
FullDB is a regenerated snapshot, not a hand-edited surface: maintainers
rebuild it from a database with the updates already applied. Contributors
provide the update files and nothing else there.
This branch had been editing it three ways, all of them duplicating what
the migrations already do:
areatrigger_teleport.sql -- Rel23_03_009 performs these same row
changes, ten references to the table
dungeonfinder_entrance.sql -- Rel23_03_009 creates the table and inserts
the dungeon 640 row
instance_template.sql -- Rel23_03_010 supplies map 1148, and the
nine MoP destinations come from the
already-merged Rel23_02_074
The instance_template edit was mine, added in response to a review finding
about fresh installs. The finding was real, but the remedy belongs in the
snapshot regeneration rather than in a contributor's diff -- a rebuilt
FullDB picks all of it up, because it is dumped from a database that has
run every update.
The Tools additions stay: dungeonfinder_entrance genuinely was missing
from both dump lists, and those are hand-maintained.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6a459b9b84
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| INSERT INTO `dungeonfinder_entrance` | ||
| (`dungeon_id`, `target_map`, `target_position_x`, `target_position_y`, | ||
| `target_position_z`, `target_orientation`) VALUES |
There was a problem hiding this comment.
When the database is generated with make_full_WorldDB.sh, only mangosdLoadDB.sql and World/Setup/FullDB/*.sql are concatenated, so this migration-only insert is never executed and the newly created table remains empty. A repo-wide search of the current tree finds no dungeonfinder_entrance data file or other insert, meaning dungeon 640 cannot load even after its instance template is supplied. Fresh evidence relative to the existing thread is that the final FullDB revert removed the data file that the prior comment assumed was present.
Useful? React with 👍 / 👎.
| INSERT INTO `areatrigger_teleport` | ||
| (`id`, `name`, `required_level`, `required_item`, `required_item2`, | ||
| `heroic_key`, `heroic_key2`, `required_quest_done`, | ||
| `required_quest_done_heroic`, `target_map`, `target_position_x`, | ||
| `target_position_y`, `target_position_z`, `target_orientation`) VALUES |
There was a problem hiding this comment.
For databases generated by make_full_WorldDB.sh, this migration is not applied and the current World/Setup/FullDB/areatrigger_teleport.sql still sends IDs 45, 614, and 2567 to maps 189, 189, and 289 rather than the new maps 1004, 1001, and 1007; it also retains the old coordinates for the other MoP entrances. Fresh evidence relative to the existing thread is that the final FullDB revert restored this stale snapshot even though the earlier comment assumed the FullDB teleport file had been updated.
Useful? React with 👍 / 👎.
1 participant
What this is
The 5.4.8 entrance data the Dungeon Finder needs, plus the instance metadata that makes it load.
Two migrations:
Rel23_03_009— createsdungeonfinder_entrance, adds the six MoP entrance targets, and repoints three deprecated physical portals at their revamped maps.Rel23_03_010— adds theinstance_templaterow for map 1148, without which the server rejects the only LFG-only entrance row at every boot.Evidence
Every coordinate is a decoded build-18414
SMSG_NEW_WORLDbody from the sniff corpus (catalogue2BE10C89…), not a reference-fork value. Five of the ten rows were re-decoded independently and matched byte-for-byte.Both migrations are idempotent, transactional, validate their own postconditions on re-run, and gate on the exact preceding version.
Verified live
Applied to a running 5.4.8 server and walked with a client. All 11 areatriggers routed to exactly the expected map, confirmed from server-side map transitions rather than by eye:
After
23.03.010the boot line changes fromLoaded 0 Dungeon Finder entrancesto 1.Two deliberate decisions
610 and 612 still target deprecated map 189. Map 189 is the only populated Scarlet content — 450 creatures and 116 gameobjects, against zero on both 1001 and 1004. Repointing them would send players into empty instances. The reasoning is recorded inline so it reads as a choice. They should move when spawn data exists.
Map 1148 keeps its entrance rather than dropping it. Dungeon 640 is a concrete corpus-observed LFG destination;
MapEntry::IsDungeon()countsMAP_SCENARIO, soIsValidMAPdemands aninstance_templaterow. Supplying the missing metadata beats discarding valid routing evidence.Pairing
Pairs with mangosfour/Server
fix/pr82-lfg-followup. That branch declares this dependency viaWORLD_DB_CONTENT_NR, so a server without these migrations warns rather than silently loading nothing. The server degrades rather than breaks without it — physical entrances still work — but the LFG-only path does nothing.Also worth knowing: maps 994 and 1011 have zero spawns. Pre-existing content gap, unrelated to this PR, but those dungeons will be empty on arrival.
🤖 Generated with Claude Code