Detect Current Region
 

I've been looking for ways of an addon to detect wether it is on the US, European or Chinese regions. One method I found was using the cvar "portal":

Does anyone knows if this is a reliable solution or if there is some alternative?

GetCVar("installLocale") isnt better?

But it's flaw its returns enUS for enGB clients too.

Actually i have no portal named cvar so i'm not sure what it that.

I've been using
in my addons for years, had no complaints from users so I'd guess it works :p

Edit: Install locale is irrelevant, you can be playing in the eu region and have a deDE or frFR locale client.

Like you mentioned, it is not guaranteed to distinguish same locales on different regions, so it's not a solution. But thanks for the tip!

If you have been using it, then it's good enough for me!

Blizzard define your realmList to a domain where your login server is located.

Luckily they prefix it, but they CAN use an IP directly breaking the code. It might also be different for Chinese servers.

For example http://wowchina.com/ don't even use the prefix like the us/eu does, so keep this in mind. The Chinese realmlist is cn#.grunt.wowchina.com

I would guess the API to use would depend on what you need it for. I too use the portal value in Grail:

self.portal = GetCVar("portal")

because specific quests are not available to the European servers. Since this covers Europe and not a specific language the portal value seems to be the right way to go.

However, I have not checked on whether this is still set since I originally put in in place many moons ago.

But for any EU realm, the EU realm list will be used, no? Am I missing the point?

Thanks or the heads up.

Basically, it will work as long as we don't assume realmlists start all with the same format. One might simply check the entire realmlist string, for example.

Is it possible to get the server locale? Like deDE or something if it is a german server.

Btw: GetCVar("installLocale") is the same as GetLocale(). If you need to diffentiate between enUS/enGB then use GetCVar("locale") instead. Those are just the language preference of the client though.

Nope, the insallLocale is the language of your game's disc, but since they were shipping enUS disc to enGB too its enUS for users in Europe too. At least is should be different for chinese and korean users.

The GetCVar("locale") could work that was my second tought.

I think realmlist is really the way to go, and has been working son far for me. I'm want to detect connected servers, so I don't care about languages. If one really wants to know if a server is enUS or enGB, or if it is esES or esMX, I guess the solution is to use the realmlist and GetLocale in conjunction.

GetLocale actually returns "esES" or "esMX" as appropriate, as those are separate localizations with a few differences in their translations (eg. a different word for "dungeon" is used).

However, it does return "enUS" in an enGB client, and "ptBR" in a ptPT client, as there are not actually separate localizations for the EU variants of English and Portuguese; they just use the enUS and ptBR translations, so in those cases you would need to use the realmlist if you need to distinguish between them.

The installLocale is whatever language the user chose when they first downloaded the installer, which can be any language the game is playable in. If anyone is actually still buying physical discs, I know the expansions are available in languages other than English; I'd assume the base game or "battle chest" or whatever they're calling it now is too.

I bought my German physical discs in Germany. I chose enGB (you can't choose enUS in europe) and I play on a German server. "installLocale" is still enUS for me for whatever reason. It is common to meet people playing in English. It is not uncommon to even see Russian. I can even take Italian and am still able to login to my German server. I think automated responses like those about boss encounter progress are better delivered in the server language as I can expect that the large majority of players on a German server can understand German. I can't expect them to know Italian. That would be my reason to look for the exact server locale and not just the region.

Well, the server language is really just a human protocol. See for instance Aggra EU, it's even in the english category but it's a portuguese server.
Anyway, given the region you can have a table mapping every realm to it's language. You only need to check the region because names in EU and US servers are shared.

A heads-up to users of GetCVar("realmList") - you will need another solution for WoD. That CVar is managed by the BNet app and is deprecated. Fresh installs will no longer have it set.

GetCVar("portal") does seem to still work. It returns "public-test" on PTRs/beta realms though, so make sure to account for that (I would test the returned value and call test realms 'xx' personally, since that's what realmList did).

This change breaks many addons, including part of Ace3.

I've got a new alpha build out of Ace3 that addresses this cvar change.

Let me know if there's any issues with it. :)

Portal appears to be incomplete solution
 

One of my testers has a Battlenet account with WoW accounts in both US and EU regions.
The tester confirmed the following query of her exact setup and results.

Just to make sure I fully understand.. from your home in the UK
You have one Battlenet accountID
in that account you have two EU-Wow accounts. a US-Wow account starter account, and a WoD beta account
You have a single copy of WoW installed for the live accounts and a copy for the WoD beta account.

You launch with battlenet desktop app
you login using your battlenet accountID

At the battlenet games starter screen...
with Wow selected you select your desired WoW account and press the PLAY button launching the WoW client.

On launch you are logged into the WoW client and are at the character selection screen of the realm you last played.
Assuming you want to play on a different realm you press the CHANGE REALM button and get the realm list for the region associated with your selected WoW account


Once in game on a character selected running our addon or running the script
/script local rk = GetCVar("portal") == "public-test" and "PTR" or GetCVar("portal"); print(rk)

You get the expected output of EU while in the EU region, but you still get the output of EU when in the US region?
While looking at WoD beta the script prints PTR

Changing the Battlenet region before logging on to Battlenet has no impact on the results.

It sounds like that CVAR may get set once on first install? or perhaps it's based on geographics rather than the other?

If we could get someone who's never had WoW installed on an EU computer go and sign into the US first that'd help us know more.

I can only confirm that my portal is set to EU when I log my US trial, normally playing on EU accounts.

Not sure how useful this is, as I don't fit that exact scenario, but I'm located in the US, with a US client, and when I'm logged into into my EU WoW account -- regardless of whether I logged in through the Battle.net launcher or directly through Wow.exe -- my tickets still go to the US support team, in spite of this:

/dump GetCVar("portal") -> "EU"
/dump GetCVar("realmList") -> "eu.logon.worldofwarcraft.com"

When logging in directly through Wow.exe it seems to automatically pick US or EU depending on the value of theinstallLocale CVar in Config.wtf -- eg. "deDE" logs into EU servers, or "enUS" to log into US servers. A setting of "enGB" still logs into US servers. The value of the locale CVar doesn't seem to make any difference.

Same as Lombra

Standard Edition account on EU
Starter Edition account on US, logged on to the starter edition account
* I did not sign in to the US account first ><

I'm in EU

Fresh (Win8+WoW) install and logged into US starter edition account first

Afterwards logged in to EU account, it's still the same

Are we talking about the CVars on Live servers or the WoD beta servers? I'm a bit confused now

info? From Blizzard support
 

https://us.battle.net/support/en/art...he-game-region

I have 2 different WoW client installs each attached to a different Battlenet ID, my original US and a testing starter EU (Battlenet app installed with newer EU client)
both have SET installLocale "enUS"
both have SET locale US has "enUS" EU has "enGB"
neither have SET portal

All testing on original US client when using Battlenet account.. allowing app to shutdown on game start.
test 1 on US client
edit WTF/Config.wtf add SET portal "EU" change SET local "enGB"
launch wow-64.exe login using my EU test ID
get EU's read TerminationWithoutNotice
after back and forth finally get realm.. and EU realm list. login character.. exit client
WTF/Config.wtf Set portal is gone.

test 2 same client Config.wtf reset to normal
launch World of Warcraft Launcher.exe Battlenet app launches.. login with EU test ID
in game wrong realm get EU realm list .. login character.. exit client
WTF/Config.wtf only changes gametip and realmname .. playing in EU with US settings!

test 3 same client config.wtf reset to normal
launch battlenet desktop app.. battlenet region = US login with EU test account
verify game settings are correct in install and game play directories
{Note with 2 clients the launcher frequently modifies the directories to the wrong client.. and often triggers a 10MB download before client ready to play}
results same as test 2

test 4 same client config.wtf reset to normal then change SET local "enGB"
launch battlenet desktop app .. battlenet region = US login with US existing battlenet account
launch game find WoW client setting up a new account.. region/realm/new character setups
log in on character and exit game.
retart battlenet desktop app find my US test account now has two starter game setups 1 EU 1 US

launcher.db changes but not always.. not sure what triggers the change.

Both.
With CVar(realmslist) no longer being correctly set by the Battlenet Desktop app launcher which is now the de facto launcher those of us who need to know which region a character is in are hurting.

The addon I maintain (CensusPlus) and the website it supports are in real trouble since we can't insure data integrity.

At this point all we can do is ask people to not play in both US & EU regions on the same WoW client directory while using our addon.

As far I know Battle.net App passes region and login data to client directly using shared memory (file mapping). Value for "portal" from config.wtf are only used when starting wow client without battle.net app.

battlenet app to wow testing.
 

Conclusion from testing.
Battlenet desktop app appears to trigger launch with: Program to launch (full path), AccountID, Account password (hash presumed)
Wow client launches with configuration based upon Config.wtf locale setting
(this is seen where if locale is an EU variant the client has a prominent LANGUAGE button whereas the US client has that option buried in settings.)
client is directed to authentication server based upon accounts last region usage.

Tests and results.

Battlenet account with 2 WoW starter editions attached 1-US, 1- EU
Edited Config.wtf to SET locale "enUS" --Note: previous testing had "enGB"
Launch Battlenet .. and then Wow-US

/logs/connection.log
7/24 21:25:34.402 Login program=WoW platform=Wn64 locale=enUS
7/24 21:25:34.435 Component WoW.Wn64.18414
7/24 21:25:34.457 Component WoW.base.18273 --Note: version id of base language packs
7/24 21:25:34.480 Component WoW.deDE.18414 --Note: EU packs installed when WoW-EU first activated.
7/24 21:25:34.502 Component WoW.enGB.18414
7/24 21:25:34.524 Component WoW.enUS.18273
7/24 21:25:34.547 Component WoW.esES.18414
7/24 21:25:34.568 Component WoW.frFR.18414
7/24 21:25:34.591 Component WoW.itIT.18414
7/24 21:25:34.633 Battle.net is Component Bnet.Wn64.37165
7/24 21:25:34.658 LOGIN: state: LOGIN_STATE_CONNECTING result: LOGIN_OK --Note: initial client log in
7/24 21:25:34.770 Connecting to 213.248.127.130:1119 --Note: Paris data center
7/24 21:25:36.400 LOGIN: state: LOGIN_STATE_AUTHENTICATED result: LOGIN_OK
7/24 21:25:36.864 ClientConnection Initiating: COP_CONNECT code=CSTATUS_CONNECTING
7/24 21:25:36.893 LOGIN: state: RESPONSE_CONNECTED result: LOGIN_OK
7/24 21:25:37.863 ClientConnection Completed: COP_CONNECT code=RESPONSE_CONNECTED result=TRUE
7/24 21:25:37.944 ClientConnection Initiating: COP_AUTHENTICATE code=CSTATUS_AUTHENTICATING
7/24 21:25:38.951 ClientConnection Completed: COP_AUTHENTICATE code=AUTH_OK result=TRUE
7/24 21:25:41.948 ClientConnection Initiating: COP_GET_CHARACTERS code=43
7/24 21:25:43.026 ClientConnection Completed: COP_GET_CHARACTERS code=44 result=TRUE
7/24 21:25:53.124 ClientConnection Initiating: COP_GET_CHARACTERS code=43
7/24 21:25:53.545 ClientConnection Completed: COP_GET_CHARACTERS code=44 result=TRUE
7/24 21:25:55.784 ClientConnection Initiating: COP_GET_REALMS code=REALM_LIST_IN_PROGRESS
7/24 21:25:55.881 ClientConnection Completed: COP_GET_REALMS code=REALM_LIST_SUCCESS result=TRUE
7/24 21:26:02.984 ClientConnection Completed: COP_GET_REALMS code=RESPONSE_CANCELLED result=FALSE
7/24 21:26:03.014 Client Disconnect due to reason:12

exit out to edit Config.wtf to SET locale "enGB"
rename connection.log to save
Launch Battlenet .. and then Wow-US

/logs/connection.log
7/24 22:12:09.953 Login program=WoW platform=Wn64 locale=enGB
--note: identical Component list removed to cut wall of text
7/24 22:12:10.326 LOGIN: state: LOGIN_STATE_CONNECTING result: LOGIN_OK
7/24 22:12:10.373 Connecting to 12.129.206.130:1119 --Note:Los Angeles data center
7/24 22:12:10.871 LOGIN: state: LOGIN_STATE_AUTHENTICATED result: LOGIN_OK
7/24 22:12:11.427 ClientConnection Initiating: COP_CONNECT code=CSTATUS_CONNECTING
7/24 22:12:11.485 LOGIN: state: RESPONSE_CONNECTED result: LOGIN_OK
7/24 22:12:11.714 ClientConnection Completed: COP_CONNECT code=RESPONSE_CONNECTED result=TRUE
7/24 22:12:11.780 ClientConnection Initiating: COP_AUTHENTICATE code=CSTATUS_AUTHENTICATING
7/24 22:12:12.454 ClientConnection Completed: COP_AUTHENTICATE code=AUTH_OK result=TRUE
7/24 22:12:15.527 ClientConnection Initiating: COP_GET_CHARACTERS code=43
7/24 22:12:15.940 ClientConnection Completed: COP_GET_CHARACTERS code=44 result=TRUE
7/24 22:15:28.304 ClientConnection Initiating: COP_LOGIN_CHARACTER code=78
7/24 22:15:31.099 ClientConnection Completed: COP_LOGIN_CHARACTER code=79 result=TRUE
7/24 22:16:18.103 ClientConnection Completed: COP_LOGIN_CHARACTER code=79 result=TRUE
7/24 22:16:22.502 ClientConnection Initiating: COP_GET_CHARACTERS code=43
7/24 22:16:22.904 ClientConnection Completed: COP_GET_CHARACTERS code=44 result=TRUE

exit out to edit Config.wtf to SET locale "enGB" --note: edit not needed as already set
rename connection.log to save
Launch Battlenet .. and then Wow-EU --NOTE:different WoW account

/logs/connection.log
7/25 08:38:13.755 Login program=WoW platform=Wn64 locale=enGB
--note: identical Component list removed to cut wall of text
7/25 08:38:14.207 LOGIN: state: LOGIN_STATE_CONNECTING result: LOGIN_OK
7/25 08:38:14.347 Connecting to 213.248.127.130:1119 --Note: Paris data center
7/25 08:38:15.939 LOGIN: state: LOGIN_STATE_AUTHENTICATED result: LOGIN_OK
7/25 08:38:16.703 ClientConnection Initiating: COP_CONNECT code=CSTATUS_CONNECTING
7/25 08:38:16.734 LOGIN: state: RESPONSE_CONNECTED result: LOGIN_OK

exit out to edit Config.wtf to SET locale "enUS"
rename connection.log to save
Launch Battlenet .. and then Wow-EU

/logs/connection.log
7/25 10:25:23.966 Login program=WoW platform=Wn64 locale=enGB
--note: identical Component list removed to cut wall of text
7/25 10:25:24.200 LOGIN: state: LOGIN_STATE_CONNECTING result: LOGIN_OK
7/25 10:25:24.216 Connecting to 12.129.206.130:1119 --Note:Los Angeles data center
7/25 10:25:24.543 LOGIN: state: LOGIN_STATE_AUTHENTICATED result: LOGIN_OK
7/25 10:25:25.058 ClientConnection Initiating: COP_CONNECT code=CSTATUS_CONNECTING
7/25 10:25:25.089 LOGIN: state: RESPONSE_CONNECTED result: LOGIN_OK
7/25 10:25:25.199 ClientConnection Completed: COP_CONNECT code=REALM_LIST_REALM_NOT_FOUND result=FALSE
7/25 10:26:50.588 ClientConnection Completed: COP_CONNECT code=RESPONSE_CANCELLED result=FALSE
7/25 10:26:50.636 ClientConnection Initiating: COP_CONNECT code=CSTATUS_CONNECTING
7/25 10:26:50.803 ClientConnection Completed: COP_CONNECT code=RESPONSE_CONNECTED result=TRUE
7/25 10:26:50.842 ClientConnection Initiating: COP_AUTHENTICATE code=CSTATUS_AUTHENTICATING
7/25 10:26:51.532 ClientConnection Completed: COP_AUTHENTICATE code=AUTH_OK result=TRUE
--Note: fingers went auto-pilot and pressed cancel had to reconnect..log continues
--Note: part of above was client getting confused with data.. and defaulting to no known realm/character status.
7/25 10:27:19.116 ClientConnection Initiating: COP_GET_CHARACTERS code=43
7/25 10:27:19.630 ClientConnection Completed: COP_GET_CHARACTERS code=44 result=TRUE
7/25 10:27:58.773 ClientConnection Initiating: COP_CREATE_CHARACTER code=46
7/25 10:27:59.179 ClientConnection Completed: COP_CREATE_CHARACTER code=47 result=TRUE
7/25 10:27:59.210 ClientConnection Initiating: COP_GET_CHARACTERS code=43
7/25 10:27:59.756 ClientConnection Completed: COP_GET_CHARACTERS code=44 result=TRUE
7/25 10:29:00.180 ClientConnection Initiating: COP_LOGIN_CHARACTER code=78
7/25 10:29:03.003 ClientConnection Completed: COP_LOGIN_CHARACTER code=79 result=TRUE

region detection fallback
 

Unless something comes available to ID realm-region.
I am looking at providing a user option for users who plan to play in multiple regions.
The option will pop up a reminder notice and allowing users to override select their current region.

On the web side of the CensusPlus data, I expect we will have to do generate a unique identifier each time the addon is loaded and associate that identifier with the data collected during the character login session.
After data is sent to the web site, we will need to do sample cross checks with Blizzards Community Platform API to confirm validity of data.

BNGetToonInfo and BNGetFriendToonInfo both provide a realmID, though as I only have access to a trial account at the moment, I can't actually check whether it's different for the US and EU realms of the same name. If it is, then you could set up a hardcoded table mapping each realmID to its region, and then check the player's Battle.net friends (assuming they have any) to find out which region they were playing on.

If the realmID proves useful, it might also be worth asking Blizzard to add it to non-Battle.net functions that currently return a realm name, eg. UnitName, UnitFullName, GetRealmName, though I'm not sure how much they really listen to that kind of suggestion...

Looks like realm id's are unique:
EU realms
US realms
TW realms
CN realms

You can even get your own realm id like this:

You can actually query yourself using BNGetToonInfo(BNGetInfo()) (although I'm not sure if your own "presence ID" is ever something other than 1).

I'm also not sure what this would do if you got disconnected from battle net.

Your own ID is probably 1 always yes. But there is an issue if BNet is not available, or disabled.

Good method but not perfect. :(

How would you be able to log in without battle.net? Well it might struggle if the battle.net goes down after login.

Just cache realm id right after login. Chances that battle.net goes down between login and entering world pretty low.

Isn't the Battle.net chat a separate system? I've witnessed several times that the chat was down on login. There's also the fact that one may completely opt out of Battle.net chat on the account level. (I think?) All in all it doesn't seem like a very reliable solution, but if it's the only way.. meh. All these cvars always seemed a bit clunky to me, as well. I hope they'll implement a proper API for it, a la GetServerRegion().

You can use the new Unit GUID format in WoD to get the server id.
This may also be a great way to deliver localized messages to others in the language of the server they play on.

@TOM_RUS
How did you get the server id lists? Can one break them down into deDE, frFR and so on?

I believe it is a internal ID assignment to the various realms. I guess datamining is one way to retrieve this list. Haven't found an easier method just yet.

*Edit* You can find, at least the public available realms, over at character transfer. The page HTML contains javascript data on realm names and internal ID's. So far this is the easiest way to extract the list of realms and their IDs:

1. https://eu.battle.net/account/manage...ct-select.html
2. Select account with at least one character.
3. Select character.
4. Run the following script on the page to get the realm list in return.
   
   Code:

   ---

   var r=RealmSelector;if(r){var d=[];for(var i=0;i<RealmSelector.realmID.length;i++){d[i]=[parseInt(r.realmID[i]),r.realmName[i].trim(),r.realmType[i].trim(),r.realmLocale[i].trim()]}console.log(JSON.stringify(d))}else{console.log("Can't find RealmSelector object.")}

   ---

   The script will simply read from the RealmSelector object on the page and extract realmID, realmName, realmType and realmLocale, store it in an array and return that array in the console as JSON for easy copy-paste.

The downside is this requires you to login, do some actions then finally get the list. It's also limited to your region, so you need another account from other regions if you want to copy their realm information. Mine is EU and this is what the script above dumped:

http://pastebin.com/rqTWCPWj

Here are the US realms: http://pastebin.com/XBqWFQzn

And like Rainrider said, your GUID is probably the best way to get the realm ID in WoD.

Do UnitGUID("player") and/or BNGetToonInfo(BNGetInfo()) always report the correct serverID, even when you're not on your server or you're in an instance?

Also - a bunch of important hardcoded data that many addons will want to use? Sounds like library time! Any volunteers?

The player's GUID is static and should only ever change if a character has a paid transfer to another server.

It doesn't represent where a unit currently is, only where it was created.

Ah, forgot about the GUID changes coming up. That's probably a better solution than querying Battle.net.

I thought there was a way to do that, but couldn't remember what it was offhand, and was too lazy to go look it up. >_>

Sure, why not, though I don't think the list of addons needing this info will actually be that long. I'll edit this post shortly once I get a repo set up.

Edit:
https://github.com/Phanx/LibRealmInfo

If anyone can get data for Chinese, Taiwanese, or Korean realms please post it here and I'll add it to the lib.

TW realms (they share realmlist?)
CN realms

That first one doesn't seem to include any Korean realms, or at least none of the realm names are in Korean?

Also would you mind using Vlad's script to pick up the realm type (pvp/pve/etc) on those?

kr and tw seems to use same logon server:
kr.logon.battle.net = 121.254.200.130
tw.logon.battle.net = 121.254.200.130

and as a result I was getting exactly same realm list. May be they show realm list based on account type, who knows...

Unfortunately I don't have retail accounts in those regions, so I can't open character transfer page.

Also there's seems to be no way to get KR starter edition account, so I can't even grab theirs realm list.

What about realm type, you can get it from blizz web api by searching realm name from my list in data from http://tw.battle.net/api/wow/realm/status
and
http://www.battlenet.com.cn/api/wow/realm/status

That's a lot of manual work.

May be someone can make a suggestion to add realmid to web api?

Actually:
CN realms with type
TW realm with type (25 realms in game, only 24 in realm status)

realms without type not present in realm status data

Any idea what those type-less realms are? Should I bother including them in the lib data?

Mostly realms for a special use: internal realms, event realms (dreamhack, blizzcon etc), cybersport etc.

Okay, leaving all those out of the lib for now then. I've also added timezones for enUS realms and battlegroups for all realms, and changed the storage format to significantly reduce the memory footprint (from ~300KiB to ~120KiB). All the data for Korean realms is in, but commented out until I get realm IDs for them.

Yes, finally beta time =)

-- Off-topic
I had to change the portal CVar in Config.wtf from "cn-test" to "public-test" in order to connect to the beta servers, even though I selected English as the installed/default language and located in Europe. Maybe because my Windows OS is in chinese?

Deleting the Config.wtf still made it rebuild with "cn-test"

Just wondering if other people had similar problems

Was skimming over this post a while back and remembered it when i was working on updating my addon for patch 6.0.

Dont know if this has been said before or not but here we go.


GUID's are changing for the next expansion.
The new format for players are: Player:[server ID]:[player UID] (Example: "Player:976:0002FD64")

local strGUID = UnitGUID("player");

New GUID format: http://wowpedia.org/Patch_6.0.1/API_changes#Changes
Old documentation on GUID: http://wowpedia.org/GUID

Maybe you could use the server ID part of the guid to identify what server you are on (presuming that the ID are uniqe in the world and are persistant).
Combining that along with a hardcoded list of ID's in a library you could maybe get something working?

Yes, that was brought up.

I noticed that according to diffs a new GetCurrentRegion function is available, but I don't know whether it not being mentioned here at all means that it's all good - case closed, or that it's something completely different.

Hmm. yes "GetCurrentRegion()" is a function in the latest build but i dont know if it's working or not.


I did a "/dump GetCurrentRegion()" on two of the the current Beta servers ("Level 100 PvE" and "Beta Leveling Realm 01") and the only returned result was "1".


Got no clue if this is just a placeholder value or what "1" actually refers too. (Beta?, Datacenter? Continent?, Region of a map)

Return value of this API is based on value of "portal" cvar. They are checking if value of this cvar matches something from this array http://paste2.org/x9c1Wkw2 and return an index at first match. If nothing matches, they return 1. Theres's also special case for "cn-test".

That sounds rather useless, then, considering that the "portal" CVar has already been established to be unreliable if you're using the Battle.net launcher... maybe they're going to fix that? :confused:

I don't think its reliability has anything to do with the App; somebody earlier in the thread showed that starting the game via the exe and then logging into an EU account after a US account made it still show 'US'.

Fortunately, realmlist CVar apparently has the same limitations, so there is no harm in Ace3 using the portal CVar at least since it will mimic the old behavior perfectly (even if that old behavior was flawed).

If you have an EU account, and log in via Wow.exe while it's configured to connect to US login servers, it still connects to US servers, and automatically creates a US trial account on your Battle.net account and logs you into that. You can have both EU and US WoW accounts on the same Battle.net account.

Trying LibRealmInfo-5

and ran into a couple of problems

First I'm clueless.. lol I tried various ways to get results from library but keep getting nil as result..
copied LibRealmInfo as sub directory of my addon
updated my copy of Libstub from your LibRealmInfo
added LibRealmInfo into my toc
libs\LibStub\LibStub.lua
libs\CallbackHandler-1.0\CallbackHandler-1.0.lua
libs\LibWho-2.0\LibWho-2.0.lua
libs\LibRealmInfo\LibRealmInfo.lua

example logging in on US Cenarius

after event ADDON_LOADED for addon
local regionKey = GetCVar("portal") == "public-test" and "PTR" or GetCVar("portal")
print ("Regionkey ="..regionKey)
local uinID = UnitGUID("Player"); print(uinID) -- character not in world yet.. invalid

response was for me:
US
nil

after all initialization events fired and system stable character in world

local uinID = UnitGUID("Player"); print(uinID)
local realmID, name, apiName, rules, locale, battlegroup, region, timezone, connected, latinName = LibStub("LibRealmInfo"):GetRealmInfoByUnit("Player")
print (realmID) ... print(latinName) all returned nil

response for me was:
Player-1168-066A8EE3
nil


Second I found when doing x = UnidGUID("Player");print(x) that some realms have been renumbered.

US Cenarius which was 2 is now reporting as 1168
US Terokkar which was 1563 is now 1070
US Elune and Maelstrom have retained their numbers

edit: follow up .. 1168 is in the character transfer list as realm Blackmoore
1070 is the response code for both terokkar and Alexstrasza !!!

Well, there's your first problem, as we're up to v7 now. :p

It doesn't matter where you put it, as long as the paths in your TOC file are correct. Also, you have to completely exit and restart WoW before it will detect any new files. Since the paths you posted look fine I can only assume the latter is the problem. If it's not, ZIP up your whole addon, libs and all, and attach it to your post.

Can you please do the following:

1. Log into your account on the Battle.net website.
2. Click on your WoW account in the "Your Game Accounts" list on the right.
3. Click on "Character Transfer" at the bottom of the page.
4. Click on a character.
5. Right-click on the page and select "View Source".
6. Save the HTML file somewhere.
7. Attach the HTML file to a post here. You'll probably have to rename it with a .txt extension, as I don't think the forum is configured to accept .html attachments.

Thanks!

Edit: I just checked the EU realms and there are no ID mismatches, so just need US data.

Note that in game ServerID's do not match Character Transfer ServerID's at all times.

in game Cenarius has id that matches non-existant Chracter Transfer realm Blackmoore.

also see edit on my previous about 2 in game realms having same ServerID

Well, that's rather awkward.

Is anyone actually even using this lib? Now that they've added GetCurrentRegion() and we already have GetAutoCompleteRealms() do any addons actually have a use for a realm info database?

Sad to say the GetCurrentRegion() is also a bogus solution.

From my US installed setup
Logging in to battlenet via an EU created account
Logging in to Pozzo dell'Eternità
and running
/script print(GetCurrentRegion())
returns 1 aka US