WarcraftRealms.com

I consider several of you here to be pretty sharp folks so I'm going to describe a problem I have and see what kind of options we can all come up with together to handle it.

So the data on this site comes from primarily 3 different areas. Of course all three are done via the Census+ mod, but here they are:

- Census data, cyclical /who queries which is generally reliable and good data
- Target data, gathers data on people you target
- Guild roster data, gathers data from your guild roster, reliable data, but does not include RACE which becomes a problem as I'll note below

Now, the problem that is becoming bigger and bigger is like this: A player creates a character, say a troll rogue named Barney. A player plays Barney for 20 levels and decides he really wants to be an undead rogue, so he deletes his troll rogue and re-rolls an undead rogue which he also names Barney.

Now, this poses a problem as thus. Due to guild data not containing race information, when I am looking for a character to update from a data submission, I look based on Name, Server, Faction and Class. Now, this becomes a non issue when updating Census data as I have the race in that circumstance. I just also include Race. This allows me to find the character I want when processing census data.

When I am processing GUILD data, I do not have the luxery of the Race clarifier. I can only look for a Horde rogue named Barney. Now I have a problem. Really the only thing I can do is look for the last Horde rogue named Barney that was added to the database.

But what if this happens. Troll Barney is added but Undead Barney has not. Undead Barney appears in guild data, but not census data. Now it will attempt to udate Troll Barney since that is the last one available. Which produces an error.

So I could just stop processing guild data since that is the major sticking point. That would alleviate this problem, but would create other problems. Primarily, there are people who utilize the guild exports here to display their guild data on their own site. Do I shut this feature down? Or do I continue to try to facilitate it by maintaining additional guild roster data on the side, outside of the census data?

I hope some of you can see my dilemna here and might even be able to pose some possible solutions or options. I'm just not sure what to do here but what I have decided is that I am not okay with the degree of error that this is creating.

Thoughts?

Having never seen your back end, and not knowing enough about database design (yet), I'd say that maybe maintaining a separate guild roster would be the way to go. You could then *maybe* link that data to the census data with a caveat that this is the best match for the character but due to the nature of the data collected, this may not be 100% reliable.

This would allow for the guild roster which is indespensible to some guild (web)masters. This would allow for the fairly accurate linking of guild to character history.

What sort of error is produced? Do you have the scripts balk if guild data shows a level decrease from what has been observed by /who?

I've actually done this myself. I had a Level 16 Tauren Druid "Aestus" on Burning Legion, at one time in Raven Guard. I deleted him ages ago, but I recently created an Undead Mage of the same name to submit census data. He's currently at Level 4. His character profile has been updated, but not his datasheet.

I think you have two options:

1. Blitz the old character data when it appears that a character has been replaced, ie. some piece of data from /who or guild scan conflicts with existing data for that name.
2. Create an identically-named character, apply new data to this character and leave the old one for posterity.

Verification from multiple sources is always nice, but not the easiest thing to code in. Do you dislike either of those options for any reason? (The first obviously being pretty destructive.)

Edit: That being said, a seperate guild roster wouldn't be so bad, but it is nice to have racial data included. (ie. We have priests, but do we have dwarf priests or are we fresh out of Fear Wards?)

Ceto -

Actually you have brought another bug to the forfront, heh...

Lookie lookie:

http://www.warcraftrealms.com/charsheet/18353030 - Your undead mage
http://www.warcraftrealms.com/char/6762750 - The old tauren druid, but has the profile associated with him

This is the same type of problem where an update gets plugged to the wrong character.

This doesn't create any syntax bugs (no breaks) only semantic bugs where the wrong character gets updated with another character's data. Or a character's race doesn't reflect what they really are.

I'd say split it. Not worth losing the guild exports, and not worth all the errors. Best option atm. Unless you can somehow check to make sure the lvl is an increase, ie if i had the lvl 20 then went to 4? I'd erase/create a new one.

1.9 is changing the guild display isn't it? So won't race data be included now?

I don't think they are adding race info, but I'll have to check up on that. If so, then that'd be great!

Like others have mentioned, if the current Character Level is less than the stored Character Level, (assume the character has been deleted and the name re-used) Delete the record and create a new record for the current character.

I think it would be better to loose some guild history than to have the wrong information applied to the wrong character.

But I thought that information was dropped after 30 days of innactivity (not being spotted). By eliminating that character information all together then it would alleviate the innacurate updates.

To be totally honest, I don't think any amount of lobbying will get WoW to change... they dont even recognize what rollie does for the WoW community

It's dropped in that it's not included in the census stats. It's not dropped in the sense that it's not deleted.

Maybe this is would be the best option... trimming information on unused/innactive characters while still holding the integrity of the guild information.

The only problem is that innactives in guilds would still hold up.