# mod-personal-isle — Plan

FFXIV Island Sanctuary-inspired: a private, persistent instanced island per character. Reached via
a teleport NPC and/or a dedicated "Isle Hearthstone" item (own icon/spell, long cooldown, same
family as the retail Hearthstone). Scoped down hard for v0/v1: cosmetic personal space first,
gathering/automation deferred.

## Design pillars

- **WoW-flavored presentation, FFXIV-inspired mechanic.** Same pattern as `mod-hirelings`
  (Hirelings, not Retainers): the *system* (personal instanced getaway) is the FFXIV idea worth
  borrowing, the *name and dressing* should read as native WoW content, not an import. Real
  in-fiction name/flavor is an open question below -- "Personal Isle" is a working title only.
- **Terrain is real, authored art**, not reused/repurposed existing WoW geography (this was an
  explicit choice over the lower-effort "reuse an existing landmass + phasing" alternative,
  2026-08-20). Consequence: this module's code can't produce the terrain itself -- that's manual
  Noggit3 (or similar) work, and it gates everything else. The module's actual code scope is
  everything downstream of a finished terrain file.
- **Cosmetic MVP, not a production sim.** No building placement, no gathering/crafting automation
  in v0/v1. The goal is proving the personal-instance + entry/exit mechanics end-to-end before any
  economy/automation design. See "Later ideas" for where the sim depth goes eventually.
- **Persistent per-player instance, not phasing.** Considered hiding players from each other on a
  shared continent via the existing phasing system (cheaper to build) vs. a true per-player
  instanced map (like a dungeon, but never resets). Went with true instancing because future
  per-player decoration/placement (a later-ideas item, not v0) needs each player to have an
  independently-stateful copy of the map, which phasing alone doesn't give cleanly.

## Technical shape (agreed 2026-08-20, not yet implemented)

1. **Terrain** (manual, outside this module's code): WDT/ADT authoring in Noggit3, texturing,
   doodad placement. Long pole on the whole project -- nothing else below can be finished/tested
   until at least a first-pass terrain file exists.
2. **Client-side DBC wiring** (once terrain exists):
   - `Map.dbc` -- new entry, type continuous-but-instanced: no group requirement, no reset,
     conceptually closer to how retail Garrisons work than to a dungeon.
   - `AreaTable.dbc` + `WorldMapArea.dbc` -- correct minimap/world map display.
   - `LoadingScreens.dbc` -- dedicated loading screen entry.
   - `Light.dbc` -- only if the terrain needs lighting the default doesn't cover.
   - Ships as an MPQ patch; every connecting player needs it. Uses the same client-distribution
     flow already in place for the server.
3. **Server-side instancing (this module's actual C++):**
   - Map script: on first visit, create a persistent personal instance of the island map for that
     character; same instance ID reused on every subsequent visit (not reset like a dungeon).
   - Entry: a teleport NPC (safe default, placed in a home city) **and** an "Isle Hearthstone" item
     -- both call the same teleport-to-personal-instance logic, so the item is a convenience
     duplicate of the NPC, not a separate system.
   - Exit: a matching return point on the island (NPC or item) that sends the player back to
     wherever a normal Hearthstone would.

## MVP feature list (cosmetic, minimal loop)

- One fixed island layout -- no per-player variation, no building placement.
- A handful of static decorative spawns (vendor, maybe a fishing spot, a couple of ambient
  critters) so it doesn't feel dead. Not gameplay-relevant.
- No gathering nodes with real yields, no automation, no currency. Explicitly deferred.

## Status

- **v0 (2026-08-20, not yet in-game tested):** hello-world scaffold only. Module loads
  (`PersonalIsle_World::OnStartup` logs a confirmation), `PersonalIsle.Enable` config flag reads
  correctly, `.isle` command registers and responds with a placeholder line. No terrain, no DBC
  work, no instancing, no SQL yet.

## Later ideas (explicitly deferred past MVP)

- **Hireling tie-in**: send a `mod-hirelings` hireling to the island to gather passively while
  offline -- the actual Island-Sanctuary-idle-production feel, once both modules exist. Explicitly
  not v0/v1 -- keeps the two modules decoupled until the personal-instance mechanics are proven.
- **Building/decoration placement** per player -- workshop-adjacent, meaningfully bigger scope than
  the cosmetic MVP.
- **A real economy** (FFXIV's cowries-equivalent currency, shop) if/once production automation
  exists -- pointless before that.
- **Visiting other players' islands** (read-only tour, FFXIV-style) -- would need the persistent
  per-player instance to support a visitor flag; not needed for MVP.

## Open questions for whoever picks this up next

- **Real in-fiction name/flavor.** "Personal Isle" is a placeholder working title (and the repo/
  module name). Needs an actual WoW-native identity before this ships to players -- e.g. what
  faction/entity "sells" or "grants" access to the island, matching how `mod-hirelings` anchored
  itself to the Steamwheedle Cartel.
- **Terrain authoring status/pipeline** -- no terrain work has started as of this commit. Needs an
  owner and a first-pass layout before any DBC/server work can be meaningfully tested.
- **Exact DBC IDs** (`Map.dbc` etc.) -- can't be picked until terrain exists; note in README that
  this is a separate ID space from the module's reserved 950000-953099 world-DB block.
- **Entry NPC placement** -- which home city, exact coordinates -- not decided, low-stakes,
  decide at implementation time (same pattern as `mod-hirelings`' Contract Board placement).
- **Isle Hearthstone item specifics** -- icon, cooldown length, whether it shares a cooldown
  category with the real Hearthstone or runs independently -- not decided.