┌─ post-realm-merge-plan.md ─────────────────────────────────────────────────┐│ diff --git a/post-realm-merge-plan.md b/post-realm-merge-plan.md ││ deleted file mode 100644 ││ index 4601e8e..0000000 ││ --- a/post-realm-merge-plan.md ││ +++ /dev/null ││ @@ -1,104 +0,0 @@ ││ -# 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 ││ deleted file mode 100644 ││ index 4601e8e..0000000 ││ --- a/post-realm-merge-plan.md ││ +++ /dev/null ││ @@ -1,104 +0,0 @@ ││ -# 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 ││ deleted file mode 100644 ││ index 3a5fbb2..0000000 ││ --- a/realm-merge-blueposts.md ││ +++ /dev/null ││ @@ -1,202 +0,0 @@ ││ -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 ││ deleted file mode 100644 ││ index 3a5fbb2..0000000 ││ --- a/realm-merge-blueposts.md ││ +++ /dev/null ││ @@ -1,202 +0,0 @@ ││ -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! │└──────────────────────────────────────────────┘