┌─ post-realm-merge-plan.md ─────────────────────────────────────────────────┐│ diff --git a/post-realm-merge-plan.md b/post-realm-merge-plan.md ││ new file mode 100644 ││ index 0000000..4601e8e ││ --- /dev/null ││ +++ b/post-realm-merge-plan.md ││ @@ -0,0 +1,104 @@ ││ +# Post-Realm-Merge Plan ││ + ││ +This plan outlines the changes needed to robustly handle Blizzard realm consolida ││ tions/renames while preserving player identity and best runs in our rebuild-from-s ││ cratch pipeline. ││ + ││ +## Goals ││ +- Preserve best runs for a character across realm/name changes (identity = Blizza ││ rd character ID). ││ +- Resolve a player's "current" realm/name at build time, without relying on prior ││ builds. ││ +- Avoid 404s after realm renames (e.g., `arugal` ? `arugal-au`). ││ +- Keep dungeon leaderboards historically accurate, and make player pages/leaderbo ││ ards stable and linkable. ││ + ││ +## Backend (Data + Fetch) ││ +- Realm source of truth ││ + - Fetch realm/connected-realm lists per region (us/eu/kr/tw) at build start and ││ build a slug?(id,name,region) map. ││ + - Derive a rename/alias map (e.g., `arugal` ? `arugal-au`) from differences vs. ││ prior constants or by connected-realm membership. ││ + - Replace/augment hardcoded lists with fetched data in the build path (keep con ││ stants as fallback only). ││ + ││ +- Player identity resolution (canonical identity per build) ││ + - While ingesting runs, collect per `player_id` all observed identities: (regio ││ n, realm_slug, name, last_seen_ts). ││ + - Select canonical identity: ││ + - Primary: latest profile identity (if profile API succeeded). ││ + - Fallback: most recent identity from runs (max `completed_timestamp`). ││ + - Keep a small ordered candidate list for profile-fallback attempts. ││ + ││ +- Profile fetch fallback logic ││ + - Before calling the Profile API, normalize realm slug via the rename map (e.g. ││ , `remulos` ? `remulos-au`). ││ + - Fallback order for a single player (stop on first success): ││ + 1) Canonical identity from `players` (name + realm_slug), after rename-normal ││ ization. ││ + 2) Connected-realm sweep: try the same name against all slugs in the same `co ││ nnected_realm_id` (e.g., Pagle group, Mirage Raceway group). ││ + 3) Last-run realm heuristic: use the realm_slug of the player's most recent r ││ un and retry the profile. ││ + 4) Optional: try other identities observed in this build (distinct (realm_slu ││ g,name) pairs ordered by most recent run timestamp). ││ + - Persist the resolved identity for this build on first success (update `player ││ s.name` and `players.realm_id`). ││ + ││ +- Realm lookup robustness ││ + - Use (region, slug) uniqueness for `realms` and lookups (done). ││ + - For unknown slugs during run ingestion, insert a scoped placeholder row to pr ││ event batch aborts (done). ││ + ││ +- DB helpers to implement ││ + - `GetPlayerCurrentIdentity(playerID int) (region string, realmSlug string, nam ││ e string, err error)` ││ + - Join `players` ? `realms` by `players.realm_id`; return `r.region, r.slug, ││ p.name`. ││ + - `GetConnectedRealmSlugs(region, realmSlug string) ([]string, error)` ││ + - Look up this realm's `connected_realm_id` and return all `slug` where `regi ││ on = ? AND connected_realm_id = ?`. ││ + - `GetLastRunRealmForPlayer(playerID int) (region string, realmSlug string, ts ││ int64, err error)` ││ + - `SELECT rr.region, rr.slug, cr.completed_timestamp FROM run_members rm JOIN ││ challenge_runs cr ON cr.id = rm.run_id JOIN realms rr ON rr.id = cr.realm_id WHER ││ E rm.player_id = ? ORDER BY cr.completed_timestamp DESC LIMIT 1`. ││ + - Tiny helper: `NormalizeRealmSlug(region, slug) string` (apply static rename m ││ ap, e.g., US OCE ? `-au`). ││ + ││ +- Ranking semantics (decide and implement) ││ + - Dungeon leaderboards: keep using the run's realm (historical accuracy). ││ + - Player leaderboards (realm scope): ││ + - Option A: current realm (canonical identity). ││ + - Option B: realm of best run per dungeon (where PRs were set). ││ + - We can compute both if desired; choose which to display by default. ││ + ││ +## Generator (Static API) ││ +- Canonical identity usage ││ + - Emit player pages/leaderboards using the canonical identity chosen above. ││ + - Add a permanent ID-based route: `/player/id/{player_id}.json` (and an Astro r ││ oute if desired) for stable linking. ││ + ││ +- Redirect stubs (no server required) ││ + - For any non-canonical identities observed this build, write a small JSON `{ " ││ redirect_to": "/player/{region}/{realm}/{name}" }` at the old path. ││ + - Frontend will follow `redirect_to` on load; preserves old links/search index. ││ + ││ +- Class/spec resiliency ││ + - When Profile API fails, derive `class_name`/`active_spec_name` from `main_spe ││ c_id` in generated JSON (implemented). ││ + ││ +## Frontend ││ +- Player profile page ││ + - Follow `redirect_to` if present in the loaded JSON and navigate to the canoni ││ cal path. ││ + - If profile API data is missing, render a "last seen" badge based on latest ru ││ n timestamp and identity. ││ + - Keep class/spec coloring via `main_spec_id` fallback (implemented). ││ + ││ +- Player leaderboards ││ + - Ensure link color derived from `class_name` or fallback via `main_spec_id` (i ││ mplemented). ││ + ││ +- Realm selectors/lists ││ + - Ensure US OCE realms use `-au` slugs in UI (updated) and allow dynamic popula ││ tion from the fetched realm map in the future. ││ + ││ +## Ops/Build ││ +- Environment & rate limits ││ + - Confirm `BLIZZARD_API_TOKEN` availability; document recommended concurrency/t ││ imeouts. ││ + - Cap profile-fallback attempts per player to avoid excessive retries. ││ + ││ +- Diagnostics ││ + - Log a summary of renamed slugs detected each build. ││ + - Emit a lightweight report of players whose profile was unresolved (for monito ││ ring). ││ + ││ +## Validation ││ +- Test cases ││ + - Player with runs only on old slug (e.g., `arugal`) and profile disabled ? use ││ s latest run identity and renders with spec-derived class color. ││ + - Player with 404 then fallback to `-au` slug ? profile resolves, identity upda ││ tes. ││ + - Players who moved realms and never ran again ? keep best runs via `player_id` ││ ; page exists under last-seen identity and ID route; redirect stubs from any alter ││ nate identities in this build. ││ + ││ +## Incremental Rollout ││ +1) Keep identity by `player_id` (already in place) and (region,slug) realm unique ││ ness (done). ││ +2) Normalize OCE slugs and TW support (added) and fetch live realm lists at build ││ start. ││ +3) Implement canonical identity selection and profile-fallback logic. ││ +4) Add redirect stubs + frontend redirect handling. ││ +5) Decide realm ranking semantics and adjust generator SQL accordingly. ││ +6) Optional: Add ID-based route and "last seen" UX. ││ + ││ +## Risks & Limitations ││ +- Classic APIs do not support character search; if a player changes both realm an ││ d name and never appears in new runs, we cannot discover the new identity. We will ││ : ││ + - Preserve their best runs under `player_id`. ││ + - Serve the page under last-seen identity (and ID route). ││ + - Use redirects for identities observed in the same build. │└────────────────────────────────────────────────────────────────────────────────────┘
┌─ post-realm-merge-plan.md ───────────┐│ diff --git a/post-realm-merge-plan.md b/post ││ -realm-merge-plan.md ││ new file mode 100644 ││ index 0000000..4601e8e ││ --- /dev/null ││ +++ b/post-realm-merge-plan.md ││ @@ -0,0 +1,104 @@ ││ +# Post-Realm-Merge Plan ││ + ││ +This plan outlines the changes needed to ro ││ bustly handle Blizzard realm consolidations/ ││ renames while preserving player identity and ││ best runs in our rebuild-from-scratch pipel ││ ine. ││ + ││ +## Goals ││ +- Preserve best runs for a character across ││ realm/name changes (identity = Blizzard cha ││ racter ID). ││ +- Resolve a player's "current" realm/name a ││ t build time, without relying on prior build ││ s. ││ +- Avoid 404s after realm renames (e.g., `ar ││ ugal` ? `arugal-au`). ││ +- Keep dungeon leaderboards historically ac ││ curate, and make player pages/leaderboards s ││ table and linkable. ││ + ││ +## Backend (Data + Fetch) ││ +- Realm source of truth ││ + - Fetch realm/connected-realm lists per r ││ egion (us/eu/kr/tw) at build start and build ││ a slug?(id,name,region) map. ││ + - Derive a rename/alias map (e.g., `aruga ││ l` ? `arugal-au`) from differences vs. prior ││ constants or by connected-realm membership. ││ + - Replace/augment hardcoded lists with fe ││ tched data in the build path (keep constants ││ as fallback only). ││ + ││ +- Player identity resolution (canonical ide ││ ntity per build) ││ + - While ingesting runs, collect per `play ││ er_id` all observed identities: (region, rea ││ lm_slug, name, last_seen_ts). ││ + - Select canonical identity: ││ + - Primary: latest profile identity (if ││ profile API succeeded). ││ + - Fallback: most recent identity from r ││ uns (max `completed_timestamp`). ││ + - Keep a small ordered candidate list for ││ profile-fallback attempts. ││ + ││ +- Profile fetch fallback logic ││ + - Before calling the Profile API, normali ││ ze realm slug via the rename map (e.g., `rem ││ ulos` ? `remulos-au`). ││ + - Fallback order for a single player (sto ││ p on first success): ││ + 1) Canonical identity from `players` (n ││ ame + realm_slug), after rename-normalizatio ││ n. ││ + 2) Connected-realm sweep: try the same ││ name against all slugs in the same `connecte ││ d_realm_id` (e.g., Pagle group, Mirage Racew ││ ay group). ││ + 3) Last-run realm heuristic: use the re ││ alm_slug of the player's most recent run and ││ retry the profile. ││ + 4) Optional: try other identities obser ││ ved in this build (distinct (realm_slug,name ││ ) pairs ordered by most recent run timestamp ││ ). ││ + - Persist the resolved identity for this ││ build on first success (update `players.name ││ ` and `players.realm_id`). ││ + ││ +- Realm lookup robustness ││ + - Use (region, slug) uniqueness for `real ││ ms` and lookups (done). ││ + - For unknown slugs during run ingestion, ││ insert a scoped placeholder row to prevent ││ batch aborts (done). ││ + ││ +- DB helpers to implement ││ + - `GetPlayerCurrentIdentity(playerID int) ││ (region string, realmSlug string, name stri ││ ng, err error)` ││ + - Join `players` ? `realms` by `players ││ .realm_id`; return `r.region, r.slug, p.name ││ `. ││ + - `GetConnectedRealmSlugs(region, realmSl ││ ug string) ([]string, error)` ││ + - Look up this realm's `connected_realm ││ _id` and return all `slug` where `region = ? ││ AND connected_realm_id = ?`. ││ + - `GetLastRunRealmForPlayer(playerID int) ││ (region string, realmSlug string, ts int64, ││ err error)` ││ + - `SELECT rr.region, rr.slug, cr.comple ││ ted_timestamp FROM run_members rm JOIN chall ││ enge_runs cr ON cr.id = rm.run_id JOIN realm ││ s rr ON rr.id = cr.realm_id WHERE rm.player_ ││ id = ? ORDER BY cr.completed_timestamp DESC ││ LIMIT 1`. ││ + - Tiny helper: `NormalizeRealmSlug(region ││ , slug) string` (apply static rename map, e. ││ g., US OCE ? `-au`). ││ + ││ +- Ranking semantics (decide and implement) ││ + - Dungeon leaderboards: keep using the ru ││ n's realm (historical accuracy). ││ + - Player leaderboards (realm scope): ││ + - Option A: current realm (canonical id ││ entity). ││ + - Option B: realm of best run per dunge ││ on (where PRs were set). ││ + - We can compute both if desired; choose ││ which to display by default. ││ + ││ +## Generator (Static API) ││ +- Canonical identity usage ││ + - Emit player pages/leaderboards using th ││ e canonical identity chosen above. ││ + - Add a permanent ID-based route: `/playe ││ r/id/{player_id}.json` (and an Astro route i ││ f desired) for stable linking. ││ + ││ +- Redirect stubs (no server required) ││ + - For any non-canonical identities observ ││ ed this build, write a small JSON `{ "redire ││ ct_to": "/player/{region}/{realm}/{name}" }` ││ at the old path. ││ + - Frontend will follow `redirect_to` on l ││ oad; preserves old links/search index. ││ + ││ +- Class/spec resiliency ││ + - When Profile API fails, derive `class_n ││ ame`/`active_spec_name` from `main_spec_id` ││ in generated JSON (implemented). ││ + ││ +## Frontend ││ +- Player profile page ││ + - Follow `redirect_to` if present in the ││ loaded JSON and navigate to the canonical pa ││ th. ││ + - If profile API data is missing, render ││ a "last seen" badge based on latest run time ││ stamp and identity. ││ + - Keep class/spec coloring via `main_spec ││ _id` fallback (implemented). ││ + ││ +- Player leaderboards ││ + - Ensure link color derived from `class_n ││ ame` or fallback via `main_spec_id` (impleme ││ nted). ││ + ││ +- Realm selectors/lists ││ + - Ensure US OCE realms use `-au` slugs in ││ UI (updated) and allow dynamic population f ││ rom the fetched realm map in the future. ││ + ││ +## Ops/Build ││ +- Environment & rate limits ││ + - Confirm `BLIZZARD_API_TOKEN` availabili ││ ty; document recommended concurrency/timeout ││ s. ││ + - Cap profile-fallback attempts per playe ││ r to avoid excessive retries. ││ + ││ +- Diagnostics ││ + - Log a summary of renamed slugs detected ││ each build. ││ + - Emit a lightweight report of players wh ││ ose profile was unresolved (for monitoring). ││ + ││ +## Validation ││ +- Test cases ││ + - Player with runs only on old slug (e.g. ││ , `arugal`) and profile disabled ? uses late ││ st run identity and renders with spec-derive ││ d class color. ││ + - Player with 404 then fallback to `-au` ││ slug ? profile resolves, identity updates. ││ + - Players who moved realms and never ran ││ again ? keep best runs via `player_id`; page ││ exists under last-seen identity and ID rout ││ e; redirect stubs from any alternate identit ││ ies in this build. ││ + ││ +## Incremental Rollout ││ +1) Keep identity by `player_id` (already in ││ place) and (region,slug) realm uniqueness ( ││ done). ││ +2) Normalize OCE slugs and TW support (adde ││ d) and fetch live realm lists at build start ││ . ││ +3) Implement canonical identity selection a ││ nd profile-fallback logic. ││ +4) Add redirect stubs + frontend redirect h ││ andling. ││ +5) Decide realm ranking semantics and adjus ││ t generator SQL accordingly. ││ +6) Optional: Add ID-based route and "last s ││ een" UX. ││ + ││ +## Risks & Limitations ││ +- Classic APIs do not support character sea ││ rch; if a player changes both realm and name ││ and never appears in new runs, we cannot di ││ scover the new identity. We will: ││ + - Preserve their best runs under `player_ ││ id`. ││ + - Serve the page under last-seen identity ││ (and ID route). ││ + - Use redirects for identities observed i ││ n the same build. │└──────────────────────────────────────────────┘
┌─ realm-merge-blueposts.md ─────────────────────────────────────────────────┐│ diff --git a/realm-merge-blueposts.md b/realm-merge-blueposts.md ││ new file mode 100644 ││ index 0000000..3a5fbb2 ││ --- /dev/null ││ +++ b/realm-merge-blueposts.md ││ @@ -0,0 +1,202 @@ ││ +Update! We hear your feedback on character and guild names loud and clear, we ││ +knew this would be a very painful point but felt that the overall long term ││ +health of the play experience would outweigh it. ││ + ││ +But! Late last night we did realize there was more we could do here. ││ + ││ +The following realms will now Free Character Transfer to five new destination ││ +realms that are pre-connected to Pagle. ││ + ││ +Faerlina ? Nazgrim Mankrik ? Galakras Benediction ? Ra-den Atiesh ? Lei Shen ││ +Whitemane ? Immerseus ││ + ││ +Character names and guild names are all unique on each realm, but all realms ││ +will be connected together able to join other guilds on other realms in the ││ +group and raid, dungeon and PvP together. ││ + ││ +We hope that this solution will give everyone as much opportunity to secure the ││ +names that they have come to cherish. ││ + ││ +These realms will be open and waiting for you with the character moves on ││ +Tuesday 23rd after realms go Live after maintenance. ││ + ││ +Update! We hear your feedback on character and guild names loud and clear, we ││ +knew this would be a very painful point but felt that the overall long term ││ +health of the play experience would outweigh it. ││ + ││ +But, late last night we did realize there was more we could do here utilizing ││ +some of the Connected Realm process. ││ + ││ +The following realms will now Free Character Transfer to five new destination ││ +realms that are pre-connected to Mirage Raceway. ││ + ││ +Firemaw ? Shek'zeer Gehennas ? Garalon Golemagg ? Norushen Pyrewood Village ? ││ +Hoptallus ││ + ││ +All previously closed realms will still direct to Mirage Raceway. ││ + ││ +Character names and guild names are all unique on each realm, but all realms ││ +will be connected together able to join other guilds on other realms in the ││ +group and raid, dungeon and PvP together. ││ + ││ +We hope that this solution will give everyone as much opportunity to secure the ││ +names that they have come to cherish. ││ + ││ +These realms will be open and waiting for you with the character moves on ││ +Wednesday 24th when realms go Live after maintenance. ││ + ││ +The other realms not listed have been closed for some time and have very few ││ +players left on them, I unfortunately couldn't justify creating whole new realms ││ +for the handful of players left on them. They have been closed so long that ││ +anyone left on them is likely seeking a solo experience and unlikely to move ││ +anyway, as they could have done anytime in the last few years. I hope that ││ +clears up why they weren't listed! ││ + ││ +View Original The expensive part of Connected Realms is the database work to ││ +consolidate everyone's data, this is the part that we we love to do for you but ││ +just do not have the time, it is a very old and expensive process in time and ││ +manpower that we just can't pull off here. ││ + ││ +This route creates a connected realm like environment that people can transfer ││ +themselves into with each realm having a different destination hopefully ││ +ensuring everyone can secure their existing names. ││ + ││ +Hey folks, ││ + ││ +We've been reading through your feedback and we have some things we'd love to ││ +try and clarify as well as some updates on a few things we're doing to make this ││ +as frictionless as we can within the time constraints we have. ││ + ││ +In no particular order! ││ + ││ + What the heck are Connected Realms? ││ + ││ +If you're joining us for the first time, you may have missed when we performed ││ +realm connections in mainline World of Warcraft, and also in Vanilla Era. ││ +Connected Realms are a way for us to join realms in such a way that players on ││ +multiple realms can exist in the same physical space, they can raid together, ││ +join each others guilds, everything! Players on a Connected Realm will see a ││ +"-BobsRealm" amended to theirs or others names in the world denoting which realm ││ +they are from. The easiest way to think of this is a Surname in WoW. ││ + ││ + Why aren't you just doing Connected Realms with our existing realms, what is ││ the point of these new realms? ││ + ││ +Great question, we've mentioned before that Connected Realms would be the ideal ││ +solve here, but that it is just not a possibility for us. In full transparency ││ +mode, the reason is time, Connected Realms is a massive endeavor for us. It is ││ +something we've done ...3? times in WoWs history and it is a massive task that ││ +involves a ton of bespoke work by our Database Engineers and usually months of ││ +QA testing time as we go through rounds of internal test connections and data ││ +validation. It is one of the most expensive (in terms of raw man hours) things ││ +we've ever done so while it does solve the problem of not having to move ││ +characters and guilds yourselves, it is just a massive chunk of work that the ││ +Server team cannot pick up as we are very busy with the largest most database ││ +heavy feature in WoWs history (hello Player Housing!) I understand this isn't ││ +likely the answer you would like to hear but hopefully some transparency as to ││ +why helps. ││ + ││ +So how can you connect these new realms then? Connected Realms to players is one ││ +thing, to the development team Connected Realms is a project that involves ││ +moving around and manipulating a massive amount of player data, but the other ││ +part of Connected Realms involves something we haven't actually spoken about ││ +publicly which is Virtual Realms. As part of Connected Realms, the old realms ││ +become "Virtual" and are now hosted by a "Native" realm, this means they no ││ +longer run on their own hardware, they run on the Native realms hardware (Pagle ││ +in the US for example). These Virtual Realms behave just like a normal realm, ││ +you can see them in the Realm List, you can make characters on them, you can ││ +make Guilds on them, but since they are all sharing one parent Native Realm, all ││ +of them can talk to one another, group, raid, join guilds across the realms. So ││ +to solve the issue with players losing their character names during this realm ││ +consolidation process, by utilizing multiple new Virtual Realms, we can achieve ││ +a Connected Realm like state, give everyone an empty realm that has no blocked ││ +player or guild names on it, but without the crazy time consuming part involving ││ +the database moves. ││ + ││ +We dropped a lot of new terms and tech names there you've not heard before, so ││ +the shorter recap is - ││ + ││ +These new realms are pre-connected, and importantly, totally empty of players! ││ +This means we can avoid the large chunk of work that we can't facilitate for you ││ +(the actual realm moves of your characters and guilds) but still give each of ││ +the larger realms a new realm to Free Transfer to that will have all of your ││ +character names and guild names available to you on. ││ + ││ + Are you still going to be 'freeing' names up as mentioned earlier before the ││ Connected/Virtual realm news? ││ + ││ +Yes! We will still be bringing in the date that we consider accounts to be ││ +inactive and any names they have on them become eligible to be used by other ││ +players instead. Normally this date is several expansions ago as we do not like ││ +the shock it can cause to lose a name you have had for a long time, but for ││ +Classic Mists of Pandaria we will use a much more recent time to give maximum ││ +chance everyone still playing can get the names they desire. This will apply to ││ +all the existing realms such as Pagle, Grobbulus as well as the closing realms. ││ + ││ + When exactly are the servers going live so I can secure my names? ││ + ││ +Since it is a patch day, we won't have a concrete answer on this, as you know we ││ +tend to post maintenance windows for patch days at 8 hours, but that can vary ││ +significantly depending on how the deploy goes. We're very aware that this means ││ +a lot of uncertainty around when people need to be available to try and ensure ││ +they secure their names, also in Europe the patch time is significantly earlier ││ +in the morning than the US posing other problems. ││ + ││ +We're taking this seriously as everyone has strong connections to their names ││ +they have often had for the entire lifetime of Classic, so we are going to do ││ +our best to ensure that you are as close to as possible guaranteed your name on ││ +your servers destination realm. To do that, we are going to be closing character ││ +creation entirely on the destination realms for at least one week, likely two, ││ +depending how fast we see everyone moving. What does this mean in practice? If ││ +you try and create a new character on these realms, well, you can't. The only ││ +way to get onto the destination realms is by performing a Free Character ││ +Transfer, which means you must already have the name you want on the character ││ +you are moving on your original realm. No one can take your name from you on the ││ +destination until we re-enable free-for-all character creation again. ││ + ││ +We do not want to keep this lock in place any longer than we have to as it does ││ +create an impenetrable barrier to any new players coming in during this window, ││ +but we feel like this solution will ensure we can preserve your names for you ││ +for at least the first week. During this time we will continue to allow new and ││ +existing players to create characters on the original source realms, after we ││ +have finished with this character creation block on the destination realms, we ││ +will close the old realms to new players. ││ + ││ + What are you doing about the Australian realms? ││ + ││ +We mentioned previously but for now we are leaving the AU realms out of this ││ +process as a move to the US realms does result in a significant increase in ││ +latency, as such we want to ensure that the AU community overwhelmingly wants to ││ +move before we take action here. ││ + ││ + Will you open transfers off Grobbulus? ││ + ││ +At this time no, Grobbulus has a stable but relatively small population (by ││ +comparison, it would be a queued OG Vanilla realm!) and we would like to see how ││ +many people take the chance to join this unique environment first. If Grobbulus ││ +reaches a state where no one is having fun anymore, we will take action and ││ +offer free transfers off but we would like to wait and see how things settle ││ +first. ││ + ││ + Re-creating a Guild is incredibly painful and expensive with bank tabs and ac ││ hievements, reputation etc. ││ + ││ +We definitely feel that, we are going to be making some temporary changes to try ││ +and make this transition a little less painful for everyone! With this weeks ││ +restarts the following changes will go live. ││ + ││ + Removed achievement requirements for heirlooms. ││ + Removed achievement requirements for purchasing the banner. ││ + Removed achievement requirements for purchasing 8th bank tab. ││ + Removed reputation requirement to buy a renown guild tabard ││ + Temporary buff to guild reputation (100% increase). ││ + Temporary reduced cost for guild bank tabs. ││ + ││ +We were not able to find a solution to persisting Guild Achievements through ││ +characters moves in the time available, but hopefully removing some of the ││ +requirements to some of the player power/cosmetics that were attached to them ││ +will help make this less painful ││ + ││ +We hope that this has helped address some of your concerns, but we appreciate ││ +that ultimately this change is not without a lot of friction. We are confident ││ +that the end result will be nothing but net positive for the rest of Mists of ││ +Pandaria. ││ + ││ +Have a great weekend and we'll see you on Tuesday! │└────────────────────────────────────────────────────────────────────────────────────┘
┌─ realm-merge-blueposts.md ───────────┐│ diff --git a/realm-merge-blueposts.md b/real ││ m-merge-blueposts.md ││ new file mode 100644 ││ index 0000000..3a5fbb2 ││ --- /dev/null ││ +++ b/realm-merge-blueposts.md ││ @@ -0,0 +1,202 @@ ││ +Update! We hear your feedback on character ││ and guild names loud and clear, we ││ +knew this would be a very painful point but ││ felt that the overall long term ││ +health of the play experience would outweig ││ h it. ││ + ││ +But! Late last night we did realize there w ││ as more we could do here. ││ + ││ +The following realms will now Free Characte ││ r Transfer to five new destination ││ +realms that are pre-connected to Pagle. ││ + ││ +Faerlina ? Nazgrim Mankrik ? Galakras Bened ││ iction ? Ra-den Atiesh ? Lei Shen ││ +Whitemane ? Immerseus ││ + ││ +Character names and guild names are all uni ││ que on each realm, but all realms ││ +will be connected together able to join oth ││ er guilds on other realms in the ││ +group and raid, dungeon and PvP together. ││ + ││ +We hope that this solution will give everyo ││ ne as much opportunity to secure the ││ +names that they have come to cherish. ││ + ││ +These realms will be open and waiting for y ││ ou with the character moves on ││ +Tuesday 23rd after realms go Live after mai ││ ntenance. ││ + ││ +Update! We hear your feedback on character ││ and guild names loud and clear, we ││ +knew this would be a very painful point but ││ felt that the overall long term ││ +health of the play experience would outweig ││ h it. ││ + ││ +But, late last night we did realize there w ││ as more we could do here utilizing ││ +some of the Connected Realm process. ││ + ││ +The following realms will now Free Characte ││ r Transfer to five new destination ││ +realms that are pre-connected to Mirage Rac ││ eway. ││ + ││ +Firemaw ? Shek'zeer Gehennas ? Garalon Gole ││ magg ? Norushen Pyrewood Village ? ││ +Hoptallus ││ + ││ +All previously closed realms will still dir ││ ect to Mirage Raceway. ││ + ││ +Character names and guild names are all uni ││ que on each realm, but all realms ││ +will be connected together able to join oth ││ er guilds on other realms in the ││ +group and raid, dungeon and PvP together. ││ + ││ +We hope that this solution will give everyo ││ ne as much opportunity to secure the ││ +names that they have come to cherish. ││ + ││ +These realms will be open and waiting for y ││ ou with the character moves on ││ +Wednesday 24th when realms go Live after ma ││ intenance. ││ + ││ +The other realms not listed have been close ││ d for some time and have very few ││ +players left on them, I unfortunately could ││ n't justify creating whole new realms ││ +for the handful of players left on them. Th ││ ey have been closed so long that ││ +anyone left on them is likely seeking a sol ││ o experience and unlikely to move ││ +anyway, as they could have done anytime in ││ the last few years. I hope that ││ +clears up why they weren't listed! ││ + ││ +View Original The expensive part of Connect ││ ed Realms is the database work to ││ +consolidate everyone's data, this is the pa ││ rt that we we love to do for you but ││ +just do not have the time, it is a very old ││ and expensive process in time and ││ +manpower that we just can't pull off here. ││ + ││ +This route creates a connected realm like e ││ nvironment that people can transfer ││ +themselves into with each realm having a di ││ fferent destination hopefully ││ +ensuring everyone can secure their existing ││ names. ││ + ││ +Hey folks, ││ + ││ +We've been reading through your feedback an ││ d we have some things we'd love to ││ +try and clarify as well as some updates on ││ a few things we're doing to make this ││ +as frictionless as we can within the time c ││ onstraints we have. ││ + ││ +In no particular order! ││ + ││ + What the heck are Connected Realms? ││ + ││ +If you're joining us for the first time, yo ││ u may have missed when we performed ││ +realm connections in mainline World of Warc ││ raft, and also in Vanilla Era. ││ +Connected Realms are a way for us to join r ││ ealms in such a way that players on ││ +multiple realms can exist in the same physi ││ cal space, they can raid together, ││ +join each others guilds, everything! Player ││ s on a Connected Realm will see a ││ +"-BobsRealm" amended to theirs or others na ││ mes in the world denoting which realm ││ +they are from. The easiest way to think of ││ this is a Surname in WoW. ││ + ││ + Why aren't you just doing Connected Rea ││ lms with our existing realms, what is the po ││ int of these new realms? ││ + ││ +Great question, we've mentioned before that ││ Connected Realms would be the ideal ││ +solve here, but that it is just not a possi ││ bility for us. In full transparency ││ +mode, the reason is time, Connected Realms ││ is a massive endeavor for us. It is ││ +something we've done ...3? times in WoWs hi ││ story and it is a massive task that ││ +involves a ton of bespoke work by our Datab ││ ase Engineers and usually months of ││ +QA testing time as we go through rounds of ││ internal test connections and data ││ +validation. It is one of the most expensive ││ (in terms of raw man hours) things ││ +we've ever done so while it does solve the ││ problem of not having to move ││ +characters and guilds yourselves, it is jus ││ t a massive chunk of work that the ││ +Server team cannot pick up as we are very b ││ usy with the largest most database ││ +heavy feature in WoWs history (hello Player ││ Housing!) I understand this isn't ││ +likely the answer you would like to hear bu ││ t hopefully some transparency as to ││ +why helps. ││ + ││ +So how can you connect these new realms the ││ n? Connected Realms to players is one ││ +thing, to the development team Connected Re ││ alms is a project that involves ││ +moving around and manipulating a massive am ││ ount of player data, but the other ││ +part of Connected Realms involves something ││ we haven't actually spoken about ││ +publicly which is Virtual Realms. As part o ││ f Connected Realms, the old realms ││ +become "Virtual" and are now hosted by a "N ││ ative" realm, this means they no ││ +longer run on their own hardware, they run ││ on the Native realms hardware (Pagle ││ +in the US for example). These Virtual Realm ││ s behave just like a normal realm, ││ +you can see them in the Realm List, you can ││ make characters on them, you can ││ +make Guilds on them, but since they are all ││ sharing one parent Native Realm, all ││ +of them can talk to one another, group, rai ││ d, join guilds across the realms. So ││ +to solve the issue with players losing thei ││ r character names during this realm ││ +consolidation process, by utilizing multipl ││ e new Virtual Realms, we can achieve ││ +a Connected Realm like state, give everyone ││ an empty realm that has no blocked ││ +player or guild names on it, but without th ││ e crazy time consuming part involving ││ +the database moves. ││ + ││ +We dropped a lot of new terms and tech name ││ s there you've not heard before, so ││ +the shorter recap is - ││ + ││ +These new realms are pre-connected, and imp ││ ortantly, totally empty of players! ││ +This means we can avoid the large chunk of ││ work that we can't facilitate for you ││ +(the actual realm moves of your characters ││ and guilds) but still give each of ││ +the larger realms a new realm to Free Trans ││ fer to that will have all of your ││ +character names and guild names available t ││ o you on. ││ + ││ + Are you still going to be 'freeing' nam ││ es up as mentioned earlier before the Connec ││ ted/Virtual realm news? ││ + ││ +Yes! We will still be bringing in the date ││ that we consider accounts to be ││ +inactive and any names they have on them be ││ come eligible to be used by other ││ +players instead. Normally this date is seve ││ ral expansions ago as we do not like ││ +the shock it can cause to lose a name you h ││ ave had for a long time, but for ││ +Classic Mists of Pandaria we will use a muc ││ h more recent time to give maximum ││ +chance everyone still playing can get the n ││ ames they desire. This will apply to ││ +all the existing realms such as Pagle, Grob ││ bulus as well as the closing realms. ││ + ││ + When exactly are the servers going live ││ so I can secure my names? ││ + ││ +Since it is a patch day, we won't have a co ││ ncrete answer on this, as you know we ││ +tend to post maintenance windows for patch ││ days at 8 hours, but that can vary ││ +significantly depending on how the deploy g ││ oes. We're very aware that this means ││ +a lot of uncertainty around when people nee ││ d to be available to try and ensure ││ +they secure their names, also in Europe the ││ patch time is significantly earlier ││ +in the morning than the US posing other pro ││ blems. ││ + ││ +We're taking this seriously as everyone has ││ strong connections to their names ││ +they have often had for the entire lifetime ││ of Classic, so we are going to do ││ +our best to ensure that you are as close to ││ as possible guaranteed your name on ││ +your servers destination realm. To do that, ││ we are going to be closing character ││ +creation entirely on the destination realms ││ for at least one week, likely two, ││ +depending how fast we see everyone moving. ││ What does this mean in practice? If ││ +you try and create a new character on these ││ realms, well, you can't. The only ││ +way to get onto the destination realms is b ││ y performing a Free Character ││ +Transfer, which means you must already have ││ the name you want on the character ││ +you are moving on your original realm. No o ││ ne can take your name from you on the ││ +destination until we re-enable free-for-all ││ character creation again. ││ + ││ +We do not want to keep this lock in place a ││ ny longer than we have to as it does ││ +create an impenetrable barrier to any new p ││ layers coming in during this window, ││ +but we feel like this solution will ensure ││ we can preserve your names for you ││ +for at least the first week. During this ti ││ me we will continue to allow new and ││ +existing players to create characters on th ││ e original source realms, after we ││ +have finished with this character creation ││ block on the destination realms, we ││ +will close the old realms to new players. ││ + ││ + What are you doing about the Australian ││ realms? ││ + ││ +We mentioned previously but for now we are ││ leaving the AU realms out of this ││ +process as a move to the US realms does res ││ ult in a significant increase in ││ +latency, as such we want to ensure that the ││ AU community overwhelmingly wants to ││ +move before we take action here. ││ + ││ + Will you open transfers off Grobbulus? ││ + ││ +At this time no, Grobbulus has a stable but ││ relatively small population (by ││ +comparison, it would be a queued OG Vanilla ││ realm!) and we would like to see how ││ +many people take the chance to join this un ││ ique environment first. If Grobbulus ││ +reaches a state where no one is having fun ││ anymore, we will take action and ││ +offer free transfers off but we would like ││ to wait and see how things settle ││ +first. ││ + ││ + Re-creating a Guild is incredibly painf ││ ul and expensive with bank tabs and achievem ││ ents, reputation etc. ││ + ││ +We definitely feel that, we are going to be ││ making some temporary changes to try ││ +and make this transition a little less pain ││ ful for everyone! With this weeks ││ +restarts the following changes will go live ││ . ││ + ││ + Removed achievement requirements for he ││ irlooms. ││ + Removed achievement requirements for pu ││ rchasing the banner. ││ + Removed achievement requirements for pu ││ rchasing 8th bank tab. ││ + Removed reputation requirement to buy a ││ renown guild tabard ││ + Temporary buff to guild reputation (100 ││ % increase). ││ + Temporary reduced cost for guild bank t ││ abs. ││ + ││ +We were not able to find a solution to pers ││ isting Guild Achievements through ││ +characters moves in the time available, but ││ hopefully removing some of the ││ +requirements to some of the player power/co ││ smetics that were attached to them ││ +will help make this less painful ││ + ││ +We hope that this has helped address some o ││ f your concerns, but we appreciate ││ +that ultimately this change is not without ││ a lot of friction. We are confident ││ +that the end result will be nothing but net ││ positive for the rest of Mists of ││ +Pandaria. ││ + ││ +Have a great weekend and we'll see you on T ││ uesday! │└──────────────────────────────────────────────┘