Dungeons

A dungeon (Dark Hole in the code) is opened by a key item and runs by a text scenario. The key is a BattleDungeonItem.dat row (item table 23, codes ix…, the “Items” category); the scenario is a file Quest\<name>.txt (a “quest” in the code: quest → missions → jobs); the link key → scenario is Quest\Index.ini [MATCH], a derived file; the map is an ordinary type 1 map, all scenario objects (points, portals, zones) come from the dummies of its .spt.

BattleDungeonItem.dat                  Quest\Index.ini [MATCH]          Quest\<name>.txt
row N: m_strCode = ixkey01      ──►    ixkey01 = Dungeon00_1520_winBoss ──► quest → missions → jobs
Map\Dungeon00\Dungeon00.spt  ◄──────── use_map, dummy:, area, start_pos ───┘

How it works

• A channel is one running instance of the dungeon on a separate map layer; a hole is the entrance object on the field next to the opener. The channel count and closing delay on Sirin are set by ModDarkHole*.lua.
• A scenario is written in CP949 with tabs and ends with [END_OF_FILE]; quest keys follow ###, missions ##, jobs #. Order matters: use_map before dummy references, area before dummy:, type before contents, respawn_monster before its options, change_monster before its if.
• Every mission has start_pos (dp* inside area) and lim_time_sec > 0; the quest has limit_lv_max (and limit_lv_min), otherwise the key does not open. The quest number = the key's row number, so the row order of BattleDungeonItem matters; the key's m_bQualification must equal membership_party ≠ 0 of its scenario.
• reward_item rewards are thresholds, not shares; DarkHoleRewardRate from ServerRate.ini does not affect them. The description and complete_msg codes (≤ 16 bytes) must exist in the NDItem.edf texts of every client language.
• Limits unchecked by the code: blocks, groups, inner, respond, add_time, change_monster, gate_pos, reactions — the editor watches them.