Some might know, others might not but i'm recoding RaidTracker for 1.7.x with an admin-panel.
Depending on what's going to happen with CTRaidTracker, wether we'll figure out if we can integrate/use the raidinfo from ingame or manually add the raidid's this is what's going to happen.

If using manually adding raidid:
- Only raids with a raidid will be added, sorry if you don't like that but that saves coding and time, it has to come both ways you know

This is actually the easiest way for me facing the fact that i don't have to check for different fields anymore to see wether the raids are the same or not
Let go in a bit deeper and presume your guild is called Doomcraft and you have this kind of raidid's DC001, DC002, etc. Some might also be in another guild, lets say The Smouldering Forge and have this kind of raidid's TSF001, TSF002, etc.
Now what i'm trying to say is, i'll add an option to specify witch raids can be added depending if it contains for example TSF, that is if we go the direction of adding raidid's manually

If we manage to find out if blizz is using unique raidid's and never ever uses them again then we can modify CTRT to use those.
That will ask some more work from my side then but hey i'm having fun atm
Now what will i do then, all raids will be added end of story.

But hey what if you have multiple users uploading i hear you think.
Well if a duplicated raidid is found it will, in contrary of whats happening now, update the excisting raid in the db and "merge" its data.

Now the fun part, the admin-panel. As i've said before these are the options i'm planning to integrate, depending on the two options above:
Manual raidid's:
- Would an admin-panel still be needed?

Blizz's raidid's:
- Delete raids, more hiding them or they'll be added again
- Merging? not need as that will happen when uploading

Now that i think about this, if we would use blizz's raidid's you would ofc have a huge raid with only 1 entry, so i'll have to look into splitting them by date, but that won't be to hard i think

Other then that i'm open for suggestions and idea's

There should always be an option to delete raids using an admin panel of some sort, but the issue comes in of people continuing to upload their lua file and the raid being placed back into the database.

What I suggest is a "soft" delete, which would pull the raid off the viewable site, but still update it whenever a user uploads raid info.

Also, our guild runs multiple AQ20's, ZG's, Onyxias, and other outdoor bosses, so some sort of filtering option would be great. I notice in the current version of the modded raidtracker, it has the zone name beside alot of the raids I have been in. If there could be some sort of checklist in the admin panel for what raids you want to track, that would be great. For example, my guild does not really care that much for keeping track of loot that drops in the 20 man instances, or even outdoor bosses such as kazzak, so I would want them to be filtered out and not displayed on the raid tracking site, but on the other side of things, another guild might care alot about who got loot in a 20 man, and not care for getting raid updates from a handful of members that attend 40 mans after offering gold for loot, or just going with a friend. Battlegrounds raids are also being tracked.

So when it comes down to it, we need to be able to filter out raids on a per-content basis. 20 mans, 40 mans, outdoor bosses, and un-named raids (bgs)

edit:

you said if we used blizzards raidID we would have 1 giant entry, are you sure? I believe it is 1 ID per instance, and it changes on a weekly basis.

What i mean about blizz raids is if you raid MC on tuesday, wednesday and thursday (not taking in account the resets) you will have the same raidid for each run you do, resulting in one "big" raid

I wouldn't see that being much of an issue unless you have an incredibly high turnover of people that attend it


so long as the date of loot drops and people being there is notated somewhere, it shouldnt be that big of a deal..

maybe on the mage page you could have some sort of expanding list

+Naxxramas 1068
-08/05/2006
-08/06/2006
-08/08/2006

Apart from deleting a raid or even manually adding a raid, it'd be nice to see a way to EDIT an existing raid. Like if you need to add some people to the list of people in attendance (for example, people who were on standby if needed but never actually joined the raid). Or if you needed to manually add a piece of loot that dropped but the scanner didn't pick it up. If that's even possible.

Hey Polo.

Just wanted to say thank you very much for this rockin addon as it stands. The changes you outline in this thread would also go far to increase the ease of use, accuracy of data, and overall 'wow that's awesome' factor.

Kudos!

Bajah wrote:Like if you need to add some people to the list of people in attendance (for example, people who were on standby if needed but never actually joined the raid)

Why would you do that? ??: if you haven't attend, you havent been there no?

@ Rihlsul

Thx, i will also try to make the addon compatible with Mathos' rosterDKP addon, nothing much, just when you have rosterDKP installed it will try to link to the raids, display dkp points in tooltip, etc etc

PoloDude wrote:

Bajah wrote:Like if you need to add some people to the list of people in attendance (for example, people who were on standby if needed but never actually joined the raid)

Why would you do that? ??: if you haven't attend, you havent been there no?

We tend to have people on Standby that never actually join the raid, but for record purposes they are counted as having attended the raid. AKA they didn't make it onto the raid, but were there and ready to go. They still get credit as having gone. If we could manually list them as having gone, that'd be awesome. At present, I've just been manually updating the RaidTracker.lua into thinking there were more people there.

If that makes any sense.

I would like an option to turn off everything except the Boss Progress page. All of the other stuff ppl can see on our EQdkp page and is redundant.

One of the things I've noticed is that the addon as is can't sort out difference in events even if the data between the two is identicle when you have multiple people uploading. My guess is that this is a time baised issue; the CT_RaidTracer (modded) is recording the time of the event using the local bios clock of the computer, instead of the wow server time...

I'm still going though the posts - I was new to this whole thing a month ago, and then went out of town for a while... I came back and wow, our guild loves this mod, but - they all feel as I do - and you are posting here... more control is needed.

I'm not sure which mod you are talking about using to gather the raid tracking info if CTRTmodded will no longer function - is this a built in blizzard mod that you are talking about gathering the info from?

Also I assume that when you would have a merger function in the mod and on the control panel, that the time baised issues would be eliminated with the new data gathered by using the raidid - but would there be capability to go back to previous data recorded and in the tables to merge the old data using the new admin panel?

As I've mentioned before, awesome addon. BUT....you know there is always a BUT for those who want their icing and cake.

My wish list:

1st: When you click a person's name, it shows a display of all the loot they have received, date they received it, raid they were in and which boss it dropped off.

2nd: When you click an item, it shows a display of all the times that item has dropped with the player receiving it, date it dropped, raid it dropped in and which boss it dropped off.

3rd: On Raid Attendance page, it would be nice to have the labels clickable so you can see attendance numbers in descending order (and you can lose the 'x' in front of a number such as 'x3' for 3 times. Not really necessary. Also, you could just show a blank space code ;nbsp or a 0 if no attendance as the '/' is not sortable.

I'll think up some more goodies but these are the obvious ones right off the bat.

I'd like to see this compatible with 2.0 patch.