I have found a bug in v6.3.4+, which (while it doesn't corrupt data) might make the entire "resume on another toon" feature seem a bit underwhelming to some (people on connected realms)...
The problem in a nut Shell: Connected Realms.
For test purpose, I used the cluser containing EU realms (Hakkar, Emeriss, Bloodscalp, Crushridge, Agamaggan and Twilight's Hammer), but I see no reason it should be different on US realms..
I have a census toon on Hakkar-Horde... I let CP run a few /WHOs and the realm-list in interface is populated with all the realms (as mentioned in the list above).
I logged out while CP was running and logged into another census toon on Emeriss-Horde and began CP.. It started from scratch....
Logging back to Hakkar, proved the same.
Apparantly, Connected Realms is not supported by the resume feature, but it should be possible; save the realm-connections, when logging out and check wether the toon you log into is not EXACTLY the same realm as before, but instead check if the realm is present in the realm-list from previous toon.
I know, it's possible that there are more realms in the cluster in question, which haven't been found in the /WHOs yet.... That ofc will make it impossible to identify as being a member, but it can still be helpfull...
Hope this makes sense...
Bug in v6.3.4 and v6.4.0
Bug in v6.3.4 and v6.4.0
Doing census mainly on Draenor; Raluf - Nimsay - Lusmo - Quixx - Sosyan - Garthog - Trubin - Zalistra - Zesmi and Djaang
-
bringoutyourdead
- Forums Admin & general flunky
- Posts: 1432
- Joined: Fri Nov 07, 2008 1:11 pm
- Location: Texas, USA
Opps missed the new post flag on this one.
You caught the issues in your post.
While is is possible to spot connected realms and resume..
it is also possible to not spot the connect ream and fail to resume.
Which is why I stated in the version notes and on site.. 'Same Realm - Same Faction'
Due to the ambiguity of the situation and the flow of code, I chose the only clean solution.
CensusPlus does not work as .. I know this is a Connected Realm do this.
instead Census Plus works as .. Oh look here... this is a connected Realm, use this info for the rest of the census run and make the data available to the web site.
At this point all of my CensusPlus work is to make the Legion release better.
I have no plans to make any release before WoW V7xx is scheduled to go live.
If I should stumble upon a low effort solution to allow clean resumes of 'Same connected realm - Faction' then it will go into the Legion release.
But I wouldn't hold my breath on that happening.
You caught the issues in your post.
While is is possible to spot connected realms and resume..
it is also possible to not spot the connect ream and fail to resume.
Which is why I stated in the version notes and on site.. 'Same Realm - Same Faction'
Due to the ambiguity of the situation and the flow of code, I chose the only clean solution.
CensusPlus does not work as .. I know this is a Connected Realm do this.
instead Census Plus works as .. Oh look here... this is a connected Realm, use this info for the rest of the census run and make the data available to the web site.
At this point all of my CensusPlus work is to make the Legion release better.
I have no plans to make any release before WoW V7xx is scheduled to go live.
If I should stumble upon a low effort solution to allow clean resumes of 'Same connected realm - Faction' then it will go into the Legion release.
But I wouldn't hold my breath on that happening.
I know it can never be 100% fail safe, unless Blizzard makes it possible to extract all realms in a cluster, however....
Example: Realms A, B, C, D and E are in a cluster
Running census on realm A finds toons on A, C and E. If this list (A, C and E) was saved, the player could log out and resume on C and E. Resume on B and D would not be possible as no toons was found on those realms in this scan.
But since resume on C and E is already an improvement, it could still weigh up, that B and D cannot resume, as no data corruption occurs.
Example: Realms A, B, C, D and E are in a cluster
Running census on realm A finds toons on A, C and E. If this list (A, C and E) was saved, the player could log out and resume on C and E. Resume on B and D would not be possible as no toons was found on those realms in this scan.
But since resume on C and E is already an improvement, it could still weigh up, that B and D cannot resume, as no data corruption occurs.
Doing census mainly on Draenor; Raluf - Nimsay - Lusmo - Quixx - Sosyan - Garthog - Trubin - Zalistra - Zesmi and Djaang
I have found another issue, with the logout/resume; Loss of data 
Luckily, there is no risk of corrupted data.
I have noticed, that when you log out, the last /who isn't repeated on the new toon, causing loss of data, potentially for a whole race.
Example:
- Who 100 --> 49+
- - Who Orc 100 --> 47
- - Who Blood Elf 100 --> Logout when command is sent, but no reply received yet
- Log in on new toon
- - Who 91-99 --> 45
Blood Elves are ALWAYS present in large numbers, possibly 500+ even this late in expansion. Since the first reply is never received, the subsequent WHOs (those with classes and/or letters) are never done, causing a massive loss of data.
It's not just Belfs, but any WHO-command that will cause a tier deeper scan, that cause this behaviour.
I would think, simply repeating the last WHO-command when logging in, could solve the problem.
Luckily, there is no risk of corrupted data.I have noticed, that when you log out, the last /who isn't repeated on the new toon, causing loss of data, potentially for a whole race.
Example:
- Who 100 --> 49+
- - Who Orc 100 --> 47
- - Who Blood Elf 100 --> Logout when command is sent, but no reply received yet
- Log in on new toon
- - Who 91-99 --> 45
Blood Elves are ALWAYS present in large numbers, possibly 500+ even this late in expansion. Since the first reply is never received, the subsequent WHOs (those with classes and/or letters) are never done, causing a massive loss of data.
It's not just Belfs, but any WHO-command that will cause a tier deeper scan, that cause this behaviour.
I would think, simply repeating the last WHO-command when logging in, could solve the problem.
Doing census mainly on Draenor; Raluf - Nimsay - Lusmo - Quixx - Sosyan - Garthog - Trubin - Zalistra - Zesmi and Djaang
-
bringoutyourdead
- Forums Admin & general flunky
- Posts: 1432
- Joined: Fri Nov 07, 2008 1:11 pm
- Location: Texas, USA
Yes well aware of this.
The cause is that we need to use libwho to be friendly with other addons that also use the /who facility.
As such, and as noted before,
CensusPlus main window has the queue as known by CensusPlus addon.
Chat frame (when in verbose mode) has active who request info as presented to/from libwho
CensusPlus button has the top value of the last range of results (levels) as returned by the server.
While the example is in error (Orc is the last race requested at race break outs), the gist of the example is correct.
The currently active (sent to libwho) queue will be lost if the character leaves the world before the server responds.
Since all the non-global variables are trashed by the WoW client on character exit from the world, there is no real way to do a full complete resume as if game session had not terminated.
The only way would be to have all variables set as global variables, which is frowned upon as very bad coding.
Oh yea it is bad coding, as I have seen when an attempt to do the something similar caused the addon to infinitely loop until the WoW client crashed with out of memory condition.
As noted currently there won't be any corrupted data.
I must leave it up to the user to be aware of where they are in Census run, as to when/if they decide to force a character leaves world situation.
The cause is that we need to use libwho to be friendly with other addons that also use the /who facility.
As such, and as noted before,
CensusPlus main window has the queue as known by CensusPlus addon.
Chat frame (when in verbose mode) has active who request info as presented to/from libwho
CensusPlus button has the top value of the last range of results (levels) as returned by the server.
While the example is in error (Orc is the last race requested at race break outs), the gist of the example is correct.
The currently active (sent to libwho) queue will be lost if the character leaves the world before the server responds.
Since all the non-global variables are trashed by the WoW client on character exit from the world, there is no real way to do a full complete resume as if game session had not terminated.
The only way would be to have all variables set as global variables, which is frowned upon as very bad coding.
Oh yea it is bad coding, as I have seen when an attempt to do the something similar caused the addon to infinitely loop until the WoW client crashed with out of memory condition.
As noted currently there won't be any corrupted data.
I must leave it up to the user to be aware of where they are in Census run, as to when/if they decide to force a character leaves world situation.
-
bringoutyourdead
- Forums Admin & general flunky
- Posts: 1432
- Joined: Fri Nov 07, 2008 1:11 pm
- Location: Texas, USA
or to put it another way
re-read the original suggestion thread... last post explains just like the one above
http://www.warcraftrealms.com/forum/vie ... php?t=6032
re-read the original suggestion thread... last post explains just like the one above
http://www.warcraftrealms.com/forum/vie ... php?t=6032