Classic CensusPlus

[Balgair]

I think I'd be wary about going down the "any key triggering it" approach; if it's possible at all, I don't think it's intended, and I wouldn't want it to be mistaken by Blizz's automated tools for botting or similar. So if you do go that way, please have a toggle for a manual player-driven only version too! I'm happy mashing a macro button in my downtime

Might it be worth reaching out to the devs somehow to ask if we were intended targets of this change? As if we are, they'd probably only break it again, while if it wasn't aimed at us, they might be willing to make adjustments if they realise they broke an original vanilla addon...

[Kanegasi]

Hooking hardware events to do things is acceptable. There was an auto companion add-on I remember using a few years ago that used hardware events to summon or swap companion pets. Since pets were turned into spells before the collection tab even came out, add-ons can't cast spells on their own, so just playing the game with key strokes and mouse clicks would run your auto pet rules.

[bringoutyourdead]

can you remember the name of that addon?
I need to see some examples of how the hooking is done.

[bringoutyourdead]

reaching out to the devs is like sending a message through a Black Hole. Never to be heard from again.

And from the company point of view, it is the only thing to do.. as far as I can tell.
Back in the olden days with the original version of Blizzard's forums there was a UI forum which had direct input from one or more devs.

And sadly, in spite of how old, disjointed, scrambled, and just poorly written CensusPlus has become (if it ain't broke, don't fix it) it still reminds to this date the core of all of the Gold seller, Spam inviter, and other bad ware that needs to get character info as quickly as possible.

Most of these bad ware that I have downloaded to investigated over the years just copy and pasted major portions of CensusPlus internal functions to use in their code.

So yes, we have been an enabler for this bad ware... not that they couldn't had done the work themselves.

After spending most of my awake time (which was not that much considering on how much sleep time I lost at the end of the work week) scanning any probable source on the internet ( all of the usual suspects) and even doing a number of different google searches which lead me to the dark side.
I didn't find any useful information regarding the change made.

I did learn that what I (uncomfortably) called WoW live is called internally as Project Mainline.

I will document a macro to act as a trigger button for Census query (as we will need anything we can get.)
I also spent time in Classic.. just to track how I play the game.. i.e. how and what keys, mouse buttons, mouse movements I typically use to play the game.

And sadly for my style of play, during non-combat periods, there are not a lot of hardware events (at least with the keyboard and mouse buttons).
During combat there are many more events.. but that is exactly when the API call is prohibited.

I used the console options for the client and dumped a copy of the five Interface XML trees used.
Oddly enough the largest code segments for both the XML display code and the LUA action code is the FriendsFrame.

I also checked through Gethe's GitHub dump which has the various versions of the dumps which makes it easier to see the changes.

Unfortunately as expected the actual changes in the code are in the non-LUA area, which is not available to outside coders.

[Hybuir]

Howdy. I've been playing classic and got me a warrior again. Running C+Classic, but how do I upload? Version missmatches when uploading.

- hyb.

[bringoutyourdead]

Greetings neighbor.
C+Classic is not our addon... the data structure is different then CensusPlus.
Check with wowpop.com it should upload there.
I have been conversing with the creator of that site, to our mutual benefit.

However as you should know, that addon just like all of the rest of the Census addons were broken by Blizzard.


UPDATE:
CensusPlusClassic (the forked version) using the Beta 0.6 and patching in the diff submitted by users on the GitHub site for this project builds a version that mostly works under the new Blizzard rules.
But it is still very buggy..
It probably will need two or three more beta cycles before it is ready for general use.. i.e. you had better know programming and not be afraid to edit the code in the state it is currently.


CensusPlus & ClassicCensusPlus (our addons) are in design stage..
Balgair has been shipped sample code (other addons modified to provide user interface experience in the new rules environment.)

I spent some hours in test this past night.. and while things work.. getting a full census run in takes real dedication. It reminded me of real census work.. I was employed by the US Census for the 1980, long gruelling hours with sometimes very little to show for the time spent.

[FuxieDK]

This is sad news, indeed.

I really hope that Blizzard realise they have made a mistake (intentional or not) and "fix" this problem.

For me, it's unacceptable to be required to press a button every 8 seconds (or how long a single /WHO takes), for 30-60 minutes., only to repeat it over and over again, for the duration of my wow session.

For now, I have disabled the addon, as it's not working. But sadly, I won't re-enable it, unless Blizzard make it possible to run this as an automated process.

BOYD, you have done an outstanding job and still does. You've kept this addon running for years when no one else could/wanted to..

I will ofc, follow the news here, but unless it somehow becomes automated, I won't be uploading any more data
Sadly, it seems, it have been in vain

[Poisonenvy]

From what I understand (which is very little!) it looks like the intention is possibly for the addon to "automate" sort of, by using any hardware events to trigger the next /who? So when you do a keyboard press, or mouse press? It will take longer to take a full census, but I often play for more than an hour at a time, so as long as I'm actually physically doing something in-game (rather than /afking), I'm guessing it will still work?

That's my understanding at the moment but completely open to correction :p

[bringoutyourdead]

Unfortunately the press any key or react to any mouse click.. seems to just not work

I did find code that allowed a pass through feature so you could effectively hook key press event
and use that to do a coded process while still having the original reason for the key press to function with no issue.
This meant I could for example press the mapped movement keys, have that key value saved and displayed to the screen... and still have your character move.
But when trying to issue the sendwho function.. it is still trapped as protected.

Key binding and having a script fire works.. but that means the key is no longer available for any other game use.. effectively limiting you to a very small numbers of unique keys.. probably only one key depending on how the player normally interacts with the game.

Mouse button clicks are tied to a specified frame (typically a display element.. like a displayed button.) Attempting to generalize this would be a massive programming challenge if it is even doable without breaking the play-ability of the game.

[bringoutyourdead]

As noted above the forked version has been made sort of workable.. if you have some coding skills.. i.e. understanding how to edit the text code files and what a 'diff' file is in this context.

But to be truthful it is at this time a very ugly hack... working.. but a hack still.

I have figured out how I want CensusPlus and our classic version to be presented to the user, and how the user will need to interact with the addon under the new rules.
I have started making the modifications to the UI part of addon.. once these are working to my satisfaction it will be fairly easy to relink the queuing and queue processing to have the addon actually gather data.

But you will have to be patient... Real life work has gone into overdrive.
My 'Yesterday' went like this.. get up, eat something for breakfast while checking my mailboxes etc., go to work, leave work, do a load of laundry so I have something to wear for today, drink a glass of Orange, lay down, pass out.
Unfortunately this might be my life routine for some time to come.


The New Rules suck.

The comment we got from FuxieDK is exactly what I expect from many users of CensusPlus under the old rules.
I personally am leaning toward that side of the spectrum.
While testing the forked code.. I had no interest in just sitting in one place and repeatedly pressing a screen button or a hard coded key combination.

Besides the default key combination was chosen by someone who had never really played the Hunter or (Warlock?) classes. [check your key bindings to see if SHIFT-T is already used.. hint it is]

Since the dirty fix mouse click requires you to have the main census screen open.. the game is unplayable that way.
Using the coded key combination does allow you to play the game.. but you have no idea when you can effectively fire off a query or just have that key press ignored.
I also found that while moving from one location to another I could remember to press the key at effective intervals.. while in combat or devoting my time to handling quests etc. I would forget to press the key.

edit (I submitted this post by mistake.)

The user changes that I will be incorporating into CensusPlus mostly has to do with the little census button.
It will morph a bit.. you will easily be able to tell what state the addon is in under the new rules. Idle, queued, working.
Each state will have its own look and feel for the button, and you will get basic information in each state.

Idle will have no extra info

Queued will show how many queues are waiting to be processed.. this number will go up and down depending on the status returned from the previous queue.

Working will have a countdown so you will know when you can submit the next query.

Also by using the standardized keybinding window, you will be able to chose your own key combination if your play style would prefer that over a mouse click on a small displayed button.

Also the new rules may tend to have you in a unfinished state for a census run... we will be leaning heavily on the code I added some time ago to handle disconnects.
Only now the disconnects will be mostly player choice. and not just a disconnect from the servers.
This also means I need to put more code in for the STOP function.. as you will more like then not want to save a running census instead of Stopping a run and starting from scratch.
I Stopped a long census session by mistake.. I had meant to just pause it and log out.

[Balgair]

Have to agree about the inconvenience, I'm managing maybe 1-2 runs in a play session, generally while I'm auctioning or travelling, as I just completely forget to do it when I'm fighting. Better than the big fat zero data we'd get without it, but not convenient, and the days of logging on other realms to census them are gone (unless, maybe, super low pop realms with 0 entries that'd only take a couple of minutes anyway; as someone with only one screen there is simply no way I'll be censusing high pop realms I'm not playing on). But, it's still much better than nothing

As to the continuing censuses side of things, I wonder if there might be scope for also making a command for a custom startpoint - I'm thinking on larger servers, people will often never get below max lvl, so on Classic for example, a command /census take 59 would begin the census at lvl 59 and count down, if you wanted some variety in what you're capturing rather than getting half the lvl 60s and never getting lower. As I suspect unfinished censuses will be rather common now...

Oh and keybind choice; I've had a max lvl warlock every expansion since TBC, didn't know that keybind existed (if I ever knew it, I long since forgot), I assume from context that it's pet attack but I always just made a macro to put it on an actually convenient key lol, stretching in two directions away from WASD is just plain awkward even if I knew about it

[maki123]

I like the idea of scanning in ranges, also had similar thoughts. That only interferes a bit with the “how many are online right now� numbers.

edit: I tested this morning to combine an ability with running the manualwho macro and it worked! If I would choose some ability, that I do not spam (like charge for the warrior), I could easily do the census while leveling

[bringoutyourdead]

Scanning in ranges while fine for your person use, will negate much of the reason for CensusPlus data aggregation here at WarcraftRealms.com

Since we have few census runs done on most servers every month, if the one or two people who are submitting data for a realm are only doing a small range, we won't be able to track character leveling progression.
At the ultra low census activity it is hard enough to get the data, but if you only are interested a small range (for example the top 5 levels) then the character doesn't exist until nearly at end game.

Also any pretense we might have for tracking, Race, Class & Level apparent balances is out the door.

[bringoutyourdead]

maki123 has been keeping me informed via PM on coding changes that others are trying out and implementing on the forked version.

I thank him for the assistance.. and eagerly look to see what solutions others come up with.

I am not shy about using others knowledge and time when I am limited for both.

Well my breakfast is over.. my free time is at an end for another work day (sigh)
Maybe we will have more updates tomorrow.

[Balgair]

Scanning in ranges while fine for your person use, will negate much of the reason for CensusPlus data aggregation here at WarcraftRealms.com

Since we have few census runs done on most servers every month, if the one or two people who are submitting data for a realm are only doing a small range, we won't be able to track character leveling progression.

My thought on that is: unless a change is made, we'll definitely lose the levelling progression, as how many censuses will ever reach anything below max lvl? Letting us start at a point below max level means those levels will get censused at all, it's less of an issue in Classic while people are spread (although in a few months a larger % will be at 60) but on live WoW, probably 90-95% of census time is on max lvl characters. I really think it's unlikely that levelling characters on busier realms will be picked up at all as it stands.

If a custom start point is undesirable, then perhaps reverse the order, start at lvl 20 for live, 5 for Classic, and go up? That might even be ideal, as it ensures levelling characters are picked up first.

[1974ER]

@Balgair: While reprogramming the reverse order is probably a rather timeconsuming task, I am inclined to agree with your assessment of the situation. Reverse order would insure that even a partial census would capture a fair portion of the people still levelling up. I was actually thinking about posting on this myself, but you were faster. *hugs*

[Balgair]

Hehe very good point about the programming side; I was thinking after I posted that, that it probably isn't actually as simple as just telling it to go backwards So I'll qualify my suggestion with if it's practical to implement, then it could be the ideal way to make sure we get the levelling progression

[bringoutyourdead]

Hmm I made a post yesterday before going into work.. but apparently I forgot to submit it
(Sad commentary when you are exhausted before you even start the work day )


To recap the post..
Stay away from CensusPlusClassic for now... the latest patches which were merged into the code were ill founded.. and broke standard UI functions.

[bringoutyourdead]

I just pulled some experimental code for CensusPlusClassic from GitHub.
I am going to check it out to see if they have discovered anything new.

On the other hand.. I have already seen they have made changes to code they do not understand, and it will probably break other functions in their addon.

When I first started out with no knowledge of LUA and Blizzards coding standards, it took me nearly four months to be able to understand what CensusPlus was really doing and to be able to submit suggested changes to Rollie.

[bringoutyourdead]

morphing buttons:

After 30 hours of down time from last weeks work load, I am finally able to get back to programming for CensusPlus and (ClassicC+)

It has been a long time since I had to work this part of the code, so there has been a steep relearning curve.
Finally I decided to pseudo code the UI changes I am planning to make so I don't code myself into a corner.

Here is the section for the CensusButton(s), I need to step away and let things stew for a bit.. just to see if I forgot something important.

For people who have never been involved in coding it is always amazing how a simple thought, expands to an what if all possibilities procedures framework.. to far too many lines of code and possible unintended interactions.
----------------------------------------------------

Code: Select all

User interaction with CensusPlus (Buttons)
- info about object
- - reminder to myself

Create three buttons at same location hide all disable all
 - - if button moved make sure all three buttons are moved to same new location!
if show button
 show button 1 enable button 1
 - button 1 displays default C+
 - - button animiation no longer valid - remove option?
 - button 1 default action open censusplus window
 - button 1 alternate dropdown box with actions = take, pause, stop, options, cancel

if actions button 1 take OR main window take OR command line take then
 hide button 1 disable button 1
 show button 2 enable button 2
 - button 2 displays queue depth animation
 - button 2 default action submit query
 - button 2 alternate dropdown box with actions = submit query, pause, stop, options, cancel
- - use frame update event to update queue depth display 
  if queue depth >0 AND query not active AND delay timer = 0 then
    submit query 
	set delay timer = DELAY_TIME
- - code delay finish = time(now) + DELAY_TIME
	hide button 2 disable button 2
	show button 3 enable button 3
  elseif queue depth >0 AND query not active AND delay timer > 0 then
  - - this state should not exist if I have coded properly
  - - grey out button 2 and disable button 2 until timer = 0?
  elseif queue depth = 0 then
   hide button 2 disable button 2
   show button 1 enable button 1
  
if actions button 2 submit query OR submit query via other input path then
 - - remember to code timer delay for all possible input paths  make function call
  hide button 1 disable button 1
  hide button 2 disable button 2
  show button 3 enable button 3 
- button 3 displays delay timer and status animation
- button 3 default action none
- button 3 alternate dropdown box with actions =  pause, stop, options, cancel
- - by definition query has been submitted
  if query active AND timer delay > 0 then
- - use frame update event to process timer countdown decrementing delay timer each time second has passed 
  if query active AND timer delay = 0 then
    button 3 gray out
  - - display NF in button? indication that something has gone wrong
    - - slow processing? - - server ignored query? 
  if query finished AND timer delay >0 then
    button 3 gray out with timer delay display
  if query finished AND timer delay = 0 then
    hide button 3 disable button 3
	show button 2 enable button 2