Changes n WoW Armory

Apr 18, 2009 at 9:23 AM
Since the latest update to 3.1, the whole player-sync fails.
This id due to the fact, that the Armory doesn't return clas or racer, but classID and RaceID.

I've downloaded the source code, and fixed if, but I still have a bunch of questions regarding the structure of this module.
I'd like to be a part of this development, so if you want, you can reach me on email : martin@martinmoesby.com.

BTW, the fixed module can be seen at http://martinmoesby.com.
Coordinator
Apr 18, 2009 at 10:50 AM
Excellent!

To be honest, a few days ago my server exploded in a glorious cloud of white smoke. I suspect the power supply freaked out, but haven't confirmed as of yet. For this reason, the demo site is down till I can get something else lined up. I also purchased a new laptop, so I don;t even have the development environment reinstalled.

I suspect your fix was to hard code a conversion table. I think that'll work for now, but I might want to revisit the implementation later on if multi-game scenarios start to pop up.

As far as helping with the project, great! Aside from filtering, I'm kinda out of ideas on what to do next... maybe localization? Player adjustments? Different games? I dunno. What aspect of the module interests you?
Apr 21, 2009 at 9:41 AM

Hey,

Yeah, the solution was that the XML returned from armory doesn't use "class" or "race" elements, but instead "classId" and "raceId". I've enumerated them out so to avoid any further problems and so, IF new classes or races are to be implemented, it will return UNKNOWN instead of the actual class or race, but that's only valid for the WoW-part of the system.

I've begun to seperate the modules into different containers, so that the Leaderbord is in one container, the DKP management is in a second container and the Guildroster is a Module by itself.
I've also added images for classes, races and levels.
That is where I am so far, and the result can be seen on http://martinmoesby.com - login: demoadmin/admindnn:-)

In the future I see additional nice features :

  • I would like to implement ModuleActions as to keep the look'n'feel of the Portal-design, instead of the fixed design.
  • Another thing is the Raid import - I've begun constructing an import-class for importing from CT_RaidTracker's EQDkp xml format.
  • Localization -  "almost" require ModuleActions to be implemented.
  • Player Details - It would be really cool if we could suck some more infor about the player from armory
  • Management Console - For GuildSetup, default Raid-, Mob- and Loot values, importing and synchronization

Let me know if you want me to send you the latest source-code that I have.

Coordinator
Apr 21, 2009 at 11:48 AM
I'm still in the process of getting my laptop up-to-speed on software. New hardware is always a tinker's paradise.

Somethings that I'd like you to keep in mind if you're hoping to loopback your work into future releases.

First, external sources of data should be treated as optional sources of data. To specifically address the recent issues with the Player Sync, this is a great example of how the module should work. Despite an external change beyond my control in the WoW Armory configuration, player functionality in this module was maintained. Granted, we lost a nice automation feature, but the operations could still be performed manually. When you mention tying more information from WoW Armory into the Player Details, keep this principle in mind. The point of the Player Detail section is to always be able to see Raids and Loots for a player, and anything that may interrupt that should not be added.

Second, the last release which implemented Boards was in honest opinion the most redefining feature that has been added to the module since it first started. Certainly settings that could be considered Board specific should be supported in the database as data attached to the Board system. This certainly could include default values for data input and filtering. I just haven't gotten around to fully demonstrating what the Board system is really capable of doing.

Third, rather than remove the Leaderboard from the Player List page, I would add a flag to the Board data that allowed an admin to toggle the leaderboard on and off from the player listing. I think having a separate module view that just has the leaderboard is great, but I would leave the option of displaying it on the player listing.

Fourth, in regards to localization, I'm taking a hands off approach on this. It's terribly crass of me, but I speak English and the module is currently in English so I'm happy. If someone wants to take over localization to support other languages, I'm all for it, but I won't be a champion of it. I do know that ModuleActions aren't required to do it though, so I'm not entirely sold on what you're concerned about in this area. Go into a little more detail to explain where you see things are lacking, such as the "fixed design".

Lastly, just as a reminder, by developing and publishing your work, you're obligated under this project's licensing agreement to provide to anyone who might ask a copy of your published work in source code form. You're also welcome to try to sell the work that you do at the same time. Fortunately, you have already done this by posting your e-mail address, but I did want to remind you of the commitment.

You're welcome to send source anytime. I'm hoping to figure out how well Codeplex supports source development. If there's a way for me to supervise your checkins prior to merging with the main trunk, I have no problem adding you to the development team so you can intergrate with the project's TFS.
Coordinator
Apr 21, 2009 at 11:53 AM
Oh, also, I have PSD's for all of the images you might want to use like races, tradeskills, specs, etc. I can add those to the project at some point. Happened to dig them up yesterday on a USB stick that I had misplaced.

I was also curious about the guild roster feature. Are you retrieving the roster list from the player table by BoardID and setting that BoardID in the Module settings?
Apr 21, 2009 at 2:07 PM
Yes, The GuildRoster Module uses the same data (it's basically the same control - I've just hidden some columns ans added some images...) - and I'm setting that module's Board setting to be the same.

And I have read all the KeepInMinds, you've mentioned - and I totaltty agrre with you... And so far I haven't removed any basic functionality - just hidden some of it:-)
And I have also read and understood the License agreement - in every release I create, the source code is included and the GNU Public License - so there - that should be covered:-)

I have just finished the EQDkp Import routine, and it was quite confusing to be honest, because I dont have the exact explanation for the Database scheme, but it seems to be OK....
I will later today (GMT+1 time (Denmark)), see if I can get the new version uploaded to you somehow.
In my regular work (I'm a system architect and systems developer), I am used to work with TFS, but I must admit, I have changed the basic layout of the project...Not sure, how to integrate that into the current branch.
But I will let you decide what to do with the project.
My main concern is to get it to work with as many features as possible (the features my guild are asking for:-) )

Well - that was it from me for now.. I'll be back later to get some more work done.
Coordinator
Apr 21, 2009 at 2:37 PM
Your work is definitely appreciated. :)

I wouldn't be too worried about changing things around. The fact alone that you are having to work with the project unattached to the TFS means you're already having to drop bindings and other things. Before you get to far into what you're doing, I think it would be best to figure out how to get you setup on the project because while I know we could work it out either way, we both know having your work in the system would be easier for review.
Coordinator
Apr 21, 2009 at 2:40 PM
Also, about the Database scheme, are you referring to EQDKP's or this module's? It's been a while since I've updated the docs here.

Also, if you want to havea  more formal chat, I do have a ventrilo that I hang out on with my guild. I've had some folks from here drop in there from time to time when they need help. You're more than welcome. I'll send the details in a private message.
Apr 22, 2009 at 4:54 PM
Nahh - the scheme I was talking about was the DNN database-scheme, that you designed...
I got it covered though, even if it seems a lot to have 3 item-tables:-), but I guess it has something to do with the calculation of DKP - or something like that.

I've got 0.1.10 ready - it has support for Guild-ranks and I've upd'ed the Guildlist. and of course the Import-raid function from CT_Raidtracker.
I still need to set an option as to which Raidtracker is beeing used, but it has to be a Board - setting and not a module setting, since the Module has potential use for other games, am I right - so... I have begun thinking about another way of maintaining the Boards... so that it will be easier to implement other games.

I think, that if a regular GameProvider Interface is implemented, it will be easier to implement other games into the system - even though I'll be focusing on WoW...


Coordinator
Apr 22, 2009 at 6:29 PM
A few quick comments between watching School Rumble episodes...

The "Rank" column was detached from the WoW Armory as of the last release. I also mentioned this somewhere on the discussion list. Depending on what you have there, it may be resurrected, but for now, it is not attached. I was leaning toward turning it into a free-for-all column that people could use as a sort field of choice. EQDKP+ uses something similar for sorting/filtering by role type.

In regards to the guild roster interface, I've been hesitant to include something like that in this module for some political reasons. I'm not entirely sure the community really wants to see the feature anyways. So I'll need to go back and revisit my original concerns to see if they're still relevant. The issue being that there is another project here on Codeplex that handles rosters.

Now about the raid importing, I would suggest that you don't make the import source part of the Board settings. Board settings should be considered as independent as possible. It's entirely plausible that a guild might have more than one DKP manager and each manager may have their own flavor of raid import source. So, I would make this value something stored in a cookie. That way the value could be user specific and persisted from visit-to-visit. Now assuming only register users would be able to do raid importing, you could also store it in their DNN profile... either way, the result is the same.

As far as multi-game support, for now, don't bother. If you played something other than WoW, maybe, but the problem with moving into other games is that I simply don't have access to any other contributors playing other games who are will to provide content support to me for their game. You're welcome to work on it, but I won't be spending time on integrating that work into the releases unless others start asking for it.

As far as database design... DKP calculations do add a significant degree of complexity to the design, but there are some other things that had to be considered as well.

I'm still hoping to hear about your explanation on the ModuleActions. I think I know what you're talking about, and if that is the case, we should hash that out now before you waste time on it.
Apr 23, 2009 at 7:53 AM

OK - I've read the comments... good points, especially regarging the Raid-Import vs. Board settings and I agree, that the preferred Raid-provider should be user-based and not Board-based - or maybe selected from time to time...

About the Rank Column, - I've made Boardsettings for defining the ranks from 0 to 10 which in turn is used by the Sync-function to determine the Guildrank when sunch'ing so in that aspect...

The Guild roster - I made that because I thought i would be nice to have the information separated but still a part of the complete system. I know the WOW Guildroster project - In the beginning of that project I had a tiny relation to it, but I didn't have that much experience in the entire DNN Provider model or the Module development of DNN, so I basically just dropped out of that project. Now, I have much more experience and I feel confident, that I will be able to do lots for this project. This project has a look'n'feel
that appeal to me, and one thing I like about is, that it doesn't rely on other projects to function.

Multigame support: I too, dont have other games which I can gain acces to, but that doesn't mean, that a GameProvider interface couldn't be developed. It will still make it easier even to update WoW features in the game, and still provide others to create a "plug-in" for this module if it was to be desired :-)

ModuleActions:
I'm not sure if you now about the entire moduleactions interface, but the module actions are the actions that turn up in the module's drop-down menu. They also appear in the Containers, if the container-design has implemented the ModuleActions controls.
Personally, I've had much joy of the moduleactions, but it did require a somewhat different approach to webdevelopment from what I was used to :-)
Implementing ModuleActions would mean a much more detailed Module Definition. I would like to start with the Board, and implement that as a ModuleAction. It should pose any problem...
An advantage (at least for me) is that the different functions are seperated from the main module and the code will be easier to maintain.
The module action removes the need for the very clever ManagePageState function, that you've created, and it will remove the need to load all the controls.
It will also remove the need of handling user acces level - that will be handled in basic DotNetNuke-functionality.
I think that is the best way I can describe it - but I could show you a module that I've made, which implements module actions.

Apr 23, 2009 at 8:01 AM
Just one more thing - Since I've added the CT_RaidTracker import - the Attendance list doesnt seem to update? Even though the raid, mobs, drops, loots and roster-list is created correctly, the Attandance list still doesn't update the raid-count.

Am I missing something?

Coordinator
Apr 23, 2009 at 8:46 AM
Most problems related to Attendance involve issues with Player Join Dates and Raid Dates. Check to make sure that you are adding the raid with a raid date and time that's after the date and time associated with the players on your roster. Keep in mind attendance only calculates for the last 30 days. One of my things on my to-do list is to make this "time window" variable and a Board attribute. If you have some data loaded on your site, I can take a look at that to see what's up.

It sounds like you've done what I was dreading to do with the ranks, so I'll take a look at your source and we'll keep the rank column and simply add another column for role type later on.

In regards to the roster, I'm inclined to use your work. A while back the author of the WoW roster module added some functionality that I think jsut made the whole module a lot more complex than it needed to be. We could move forward with your work. Let's think some more on this, in particular about the situations where the player listing may not reflect an accurate guild roster. In particular, the situation where a player may leave the guild. I think it might mean that we need to add a flag to player data where an admin could say "This player needs to remain in our DKP system, but don't show them in the guild roster." I'm thinking this might be critical for guilds that have fairly forgiving "return policies" and players who leave might be allowed to come back, etc. It might also be useful for those situations where a hard-core raider becomes inactive to the point that they're in the guild and might return someday, but you don't want to show them as an active raider on your roster for recruitment reasons.

In regards to using module actions for managing data, I'm really not interested in going in this direction, but I'm open to seeing this module you've mentioned. I'll say now though, I have reservations. In particular, towards the increased data fetching and reduced data visibility. ModuleActions do have their place, but if we're merely developing them out of our own preference, and not in response to the community, I'm not sure it's a feature users will oogle over.

Now, if you want to work on something that has been on our list for a while and that I'm sure would be greatly welcomed by everyone, filtering grids is long overdue. I have a vision for the filtering system, but haven't had the time to work on it. I want something more robust than EQDKP+'s filtering, but not too complex. We also need to get this whole bookmarking issue resolved. That's the issue of not being able to bookmark right to a particular player's detail information. You always have to go through the Player section right now since we don't use request parameters in the URL. The player detail also needs to reflect all raids that could be attended, not just the raids attended. That way that section can serve as a sanity check for the hard-core raiders who are missed from a roster due to human error.

I'll send you a message with my e-mail, and you can send whatever you want when you are comfortable. I also want to share the images I have that I mentioned earlier. They'll fit a little better into your guild roster, although I'm not sure I have a set for DK's yet.



Apr 23, 2009 at 10:41 AM
I see your point regarding the ModuleActions - and maybe you're right - maybe it's just something I want to do, just do do it - because the module actually works excellent without...
So, I'll let it rest for now :-)

The GuildRoster - It shouldn't be to big a deal to add a flag on the table, if the user leaves, and therefore should'nt apper on the list...

And the issues you mention, seems like good stuff .
It's nice to have an actual goal, instead of me sitting and making up new stuff - better to get the issues at hand out of the way before implementing new ones..:-)
So - I'll get startet on the Filtering - and maybe we shoul have some more infos on the Items list - Which boss/instance it comes from.. it'll make it a lot easier to update items with DKP values if there was filtering on the lists...



BTW, I've redesigned the tss_GetPlayersByPage procedure - I simply couldn't see through it - the result is the same, but it's a bit more reader-friendly - I hope you dont mind...

 

Coordinator
Apr 23, 2009 at 10:55 AM
Considering the pain that is unraveling that query when I have to modify it, I probably won't mind. I look forward to seeing your mod.

As far as adding more info to various grids, I agree. The thing I was kinda struggling with was the inevitable need to then create two types of each class that represents these objects... i.e. creating a tss_InstancesInfo and tss_InstancesGridInfo or something like that.

The additional columns require these members to be added to the classes, and when you don't make a second version, it can get kinda confusing as to what members you need to provide values for when editing/adding data.

For example, the tss_PlayerInfo class has three members that are optional due to RaidAttendance, which is cool, but these same members popup via intellisense when using the class in other places while coding. We should probably just break and extend the class or something for clarity.
Apr 23, 2009 at 11:21 PM
I see what you mean, but before I get startet on creating filtering, I would like some more info on, what you had in mind  - particularly the GridOnfo object. I have made some thoughts on how to implement a subclass for each class, with out too much additional coding  but so far it's not been a huge succes, since VB doesn't support multiple inheritance... But I will get it to work somehow:-)

But for now I have a "nearly" stable build 0.1.10 with the following features added since 0.1.7:

  • Support for WoWArmory synching since Last update. Both Race and Class are now sync'ed properly
  • Prepared for WoWArmory sunching for Korea, China and Taiwan - which all have a seperate Armorysite.
  • Support for Guildranks - Board-based- They are now defined under borad settings..
  • Support for Importing from CT_Raidtracker. It is now an option for each Raid-import
  • Added 2 new Module : A regular GuildRoster and a Leaderboard. Both can be placed seperately from the Main DKP module and on different pages, but they use the same Board-settings as the DKP module.
  • Added 4 more columns on Items, to support the data recieved from CT_RaidTracker. The COlumns are : ItemIcon, ItemColor, ItemClass and ItemSubClass. All columns are optional though, and can be maintained manually, if so desired.
  • Optimized some Stored Procedures
  • Added some FK contraints for Cascading on Updating and deleting Raids.

I say that the build is "nearly" stable, but I think there may be some more Cascading Constraints, that needs to be implemented.

Now, all I need is a place to upload the module, for you to see and approve :-) 

But before approving, I will need to "reactivate" the leaderboard on the Main DKP.
I imagine that the seperate Leaderbord then wouldn't have to be limited to top 10 of each class, but could actually show All players.. just to give the module a chance to make itself usefull:-)

Well - that's it for now . It's 1:20 AM in the morning, and I am getting a bit sleepy.

Coordinator
Apr 24, 2009 at 12:27 AM
I messaged you with my e-mail. Just send the new code to that address with a database script representing your database changes.
Coordinator
Apr 24, 2009 at 2:53 AM
I would add that there should be no cascade constraints via FK's due to a design restriction based on the DKP calculations. This method was also selected due to a circular constraint that forms if you use FK's between Items, Mobs, Raids, Players and Rosters.

All cascade effects need to implemented via the triggers that currently support cascading effects.
Apr 24, 2009 at 8:18 AM
Hehe - Yeah, after carefully reading all the SqlDataProvider Scripts, I found all the triggers...

But I have some difficulties with the scripts...
They produce an error during install of the module, and I simply cant locate the damn script error...

The funny thing is, that when installing on dnn 5.00, the module doesn't produce error during install - same database server, different database.
Coordinator
Apr 24, 2009 at 10:43 AM
Define "they". I presume you're referring to script you've tried to create.

Writing script for the DNN installer is considerably annoying. I don't need to see it from you in that form. Actually, I'd prefer to not see it as output directly from ms sql's definition export.
Apr 26, 2009 at 4:18 PM
When executing the script from SqlDataProvider 00.01.03  the dataprovider produces an SQL-script error - and I cant seem to locate the error, other than it has something to do with the triggers..

And of course, when 03 doesn't install correctly - several other script errors occure during install.

FUnny thing is, though, when installing on 5.01 there's no script error, only on 4.9.3...



Coordinator
Apr 28, 2009 at 2:46 PM
Martin

Your email is getting bounced by gmail, and I suspect possibly other routers as well. Do you have a gmail address by chance?
Apr 30, 2009 at 1:43 PM
Yup - i have martinmoesby@gmail.com - and I'll check up on my mailserver - it's been giving me issues lately....