Some suggestions and questions about future development

Mar 5, 2008 at 2:11 PM
Edited Mar 5, 2008 at 2:12 PM
I understand that project currently in very early stage but accumulated some suggestion about development during its first try. This is barely IMHO.

  • It will be nice to see which tab you currently browsing and path to it (for example Mobs > Akil'zon > Akil'zon's Talonblade)
  • What you need to import other items and instances. Which type of parser you used? Do you need to help in filling DB?
  • There are will be nice some synching with WoW Guild Roster and / or Armory and choosing player from list because creating entry manually is pain :)
  • I saw that you dont wanna depend on 3rd party armory parsing module but seems you dont have enough time to create your own.. maybe you can start use some of nice parser available and switch to your own when have enough time?
  • How you planned to automate import raid results? There are many good addons that do its raid logging works nice. Maybe you need help in implementing parsing?

Sorry for this bunch of questions but wanna start using your work in its fully potent as soon as it will be possible. I want to help to make it faster :)
Coordinator
Mar 6, 2008 at 5:13 AM
Your first suggestion is doable. I can probably code that up for the next release. I'll add it as a breadcrumb line under the navigation menu above the grids.

So far creating the library type information like instances, mobs, items, and drop tables is a manual effort. You're welcome to try loading some data yourself and letting me know your thoughts on the process.

Syncing is not on the priority list atm. The module is advertised as independent. For now, it will remain that way.

Not having an armory parser is not a result of not having time. I have plenty of time, just no use case which requires that I reference data from the armory. What I probably should do is make the fields into comboboxes to simply data entry.

The simplification of raid creation was going to be my next big task. In an effort to inspire creative thinking, I want to first assume that an in-game addon is not permitted. With this restriction in place, if I can't come up with a working solution, then an in-game addon will be needed. I can say that if an addon is needed, the method of extracting data from the game environment will probably be through copy/paste of a string that is generated by the addon in-game. I don't find LUA file importing/parsing to be that intuitive for end users.
Mar 6, 2008 at 7:44 AM
So far creating the library type information like instances, mobs, items, and drop tables is a manual effort. You're welcome to try loading some data yourself and letting me know your thoughts on the process.

Ok, I make my parser to fill your database and give sources to you. I just wonder how you fill first part of database. I thought you already have it, so there are no need in coding that again.

Syncing is not on the priority list atm. The module is advertised as independent. For now, it will remain that way.
Hope its not independent from WoW ^_^ I mean taking information from WoW Armory can make this filling a lot easier. If I create code with WoW Armory parsing on basic info needed for filling (Player Name, Player Rank, Player Class, Player Race, Player Level, Join Date), do you want to incorporate it into your module?

And btw 'sync' is not necessary 'depend'. You can just use info if it available, and dont use if user dont have required module. So for example you can check is armory data cache already available then use it (Guild Roster for example build it) to avoid duplicate info. If there are no armory cache, than build your own cache to simplify filling. This is my IMHO.

I have plenty of time, just no use case which requires that I reference data from the armory. What I probably should do is make the fields into comboboxes to simply data entry.

Why? I cant understand your point of view :( Use dictionary always when it possible is basic way to fast and simplify process of form filling. I cant find any reason to input info manually when it can be done by automatic... Can you give me more details on your opinion? Maybe I miss something.

In an effort to inspire creative thinking, I want to first assume that an in-game addon is not permitted. With this restriction in place, if I can't come up with a working solution, then an in-game addon will be needed. I can say that if an addon is needed, the method of extracting data from the game environment will probably be through copy/paste of a string that is generated by the addon in-game. I don't find LUA file importing/parsing to be that intuitive for end users.

I think you forgot about simple thing. How skilful must be user to setup DNN, incorporate your module and build site structure? How many users used addons and never heared on saved variables and cant do simple copy / pasting and still want to setup and maintain DKP module? I think you introduce difficulties for yourself that not needed really to solve.

I will prefer LUA parsing simply because it requires less interact. Copy / Paste methods that used by many tracker addons is not convenient. User should click on addon, grab result data (for example in XML), paste to site or store in some file. To many steps... Personally I prefer way in which MobMap works (http://www.mobmap.de/devblog/ or http://www.mobmap.de/index.php?language=english). Simple updater which updates your local LUA files and upload gathered data. 2 button application that not confuse user. And ask user only for permission.

Avoiding using any addons is possible by parsing logs (chat / combat) but without addon, properly configuration such logging, turn on / turn off logging in game and proper rotation of log files will challenge user a lot more than simple using addon which doing his work.
Coordinator
Mar 6, 2008 at 4:30 PM
How about I add an administrative tool to the tool section that given a Realm and Guild Name, it will add new players and update existing players; however it will not delete existing players. Deleting a player has a serious impact on the data, so I do not want to "hide" player deletes by allowing an automated tool to delete players. The manual method of player addition will remain as is, and if a mass delete is required, the checkbox delete method should work adequately.

I'm also planning to add an administrative tool that allows for the creation of dynamic Race, Class, Rank, Level lists for combo boxes on the Players panel. Yes, this module is supposed to be independent from WoW in that regard.

Eventually, there's going to be a global admin section where things like "Game" are set so that maybe features in Everquest are made active, and features in other games are turned off, etc.
Mar 7, 2008 at 8:57 AM
I have read that you planned for 0.0.9 release. Let's wait for implementation, but seems good enough to be convinient. Thank you for work.
Coordinator
Mar 10, 2008 at 8:28 PM
I have the features implemented, but I'm trying to move the project in the direction of having a Settings file where items like Realm and Guild are set as properities of the module.

Unfortunately, there seems to be some problems. I can set the values in the Settings, and if I close the Settins and go back, the values will still be there, but wheever I try to reference the Setting values in the module itself, empty strings are returned.

I'm working with some DNN folks to see what's causing the problem. No estimate on how long this will take to resolve.
Coordinator
Mar 11, 2008 at 2:33 PM
The issue has been resolved. New release should be forthcoming.
Mar 13, 2008 at 9:36 AM
Nice, waiting for new release