|
|
Author |
Message |
Lokorin Site Admin
Joined: 03 Apr 2006 Posts: 697
|
Posted: Wed Apr 05, 2006 2:30 pm Post subject: Improved event-based support |
|
|
Status: Included in version 1.3.10
Nothing of the following is set in stone. The reason for this thread is to discuss the following suggestion, and to improve it where possible. So the following is just an initial draft, that will hopefully be improved with the help of others.
Problem
The DKP Log Parser was initially made with only time-based models in mind, so the support for event-based rewards is lacking.
Suggestion
The suggestion is to add a new pattern for event-based rewards and have it produce an event, with a specified note and time, that is rewarded with a specified amount of DKP. Everyone present at the time of the event then recieve the specified reward amount. The event would then be represented as an additional raid when uploaded to the server. The GUI would have to be augmented with an additional table, similar to the loot table.
Things to consider
Including an option to upload the event as an adjustment should be considered. Whether the client or server should decide how the event should be displayed is also a question. Another question is whether the GUI is starting to get to cluttered or not, should it be split into tabs instead?
How the code should be modified
Adding an additional pattern is no problem. The events should probably be represented as a new subclass to ParsedBlock, hereby named EventBlock for its similarity with LogBlock and LootBlock.
The EventBlock should keep track of a timestamp, a reward, a name and a textual note. EventBlock should not itself contain information about who was present at the time, simply because that's redundant information and it would mean that altering the logs inside the program would also have to affect the data in EventBlock.
The EventBlock should be added to ParsedDay, which then passes it on to the DayBlock. They could be handled like LootBlock and passed onto the corresponding IntervalBlock, but the problem with that would be that IntervalBlock would have to take some kind of co-responsibilty in the calculation of reward. It's easier to just have DayBlock check the events when getTotalReward() is called.
Then there's the uploading to the server. I suggest that an getParticipantsAt(timestamp) method is added to DayBlock. And that Server then requests a collection of events, then uses the new method, along with the event's data to create the new raid.
Pitfalls
Don't forget to include events into the XML export/import. Don't forget to update getDkpIn(). Don't forget to update the guaranteed DKP per participant things.
Last edited by Lokorin on Sat May 13, 2006 11:43 am; edited 6 times in total |
|
Back to top |
|
 |
Nomad_Wanderer
Joined: 04 Apr 2006 Posts: 30
|
Posted: Wed Apr 05, 2006 8:27 pm Post subject: |
|
|
This thread rocks.
It would be nice to pull event names, as well as event times, if possible. |
|
Back to top |
|
 |
Lokorin Site Admin
Joined: 03 Apr 2006 Posts: 697
|
Posted: Thu Apr 06, 2006 1:32 pm Post subject: |
|
|
| Nomad_Wanderer wrote: |
| It would be nice to pull event names, as well as event times, if possible. |
Thanks, it has been added to the suggestion. |
|
Back to top |
|
 |
Nomad_Wanderer
Joined: 04 Apr 2006 Posts: 30
|
Posted: Thu Apr 06, 2006 4:05 pm Post subject: |
|
|
I agree that while more work, having the event be reported as either a Raid, or an adjustment is neccesary. Some guilds may want to look at the bosskill attendance at a future date, and having the raid in place would help that.
I don't think that is possible in using the adjustment model, though it does help significantly in the clutter aspect.
Supporting both if possible is best. |
|
Back to top |
|
 |
Lokorin Site Admin
Joined: 03 Apr 2006 Posts: 697
|
Posted: Mon Apr 10, 2006 8:40 am Post subject: |
|
|
A note about GUI cluttering:
Creating an additional tab for the middle section of the GUI (interval table + logs) should work. So that one can click a tab to switch the middle section into a table of events with a list of participants to the right (immutable at the moment). The participation table ought to be switched to event-based information at that point though.
Another thought:
The suspected errors should probably be expanded with an event gap error. |
|
Back to top |
|
 |
|