Complete event-based support

[Lokorin]

Status: Included in version 1.4.0

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. Even more so the support for raids that are only event-based is non-existent. Also the events are currently connected to the time-based participation.

Suggestion
The suggestion is to, in addition to the improved event-base support, add a way to totally ignore the event-based or the time-based part (or neither). The ignore would work on three levels: GUI, Algorithm and Export, meaning that one can continue like now without any event-based information in the GUI or the export. Or one can switch to a hybrid where both are shown in the GUI, used in the algorithm, and exported (uploaded to EQDKP and more). Or one can switch to a mode where only event-based information is shown, calculated and uploaded. In essence making the tool able to support raids that are only event-based.

The participation is to be split from the intervals and the time-based part of the program.

Another important thing is that only the data used is uploaded to the server, so if for instance a pure event-based mode is used then only raids on events are added, no events are added for intervals (which are present in the background, but not for the user). This requires that loot can be mapped to events, probably mapping each loot item to the last occurred event (or the next event if there is no prior event).

Things to consider
A question is whether additional parse formats should be added to join/leave mode and first/last mode to allow exact event credits.

How the code should be modified
Basically this will be built on top of the improved event based support.

Hiding the appropriate information from the algorithm, GUI and export should be straight forward. An abstract factory for the three modes (DayBlock) might prove useful. Consider splitting DayBlock into two classes, one for keeping track of participation and one for DKP related things.

A common source for the de facto participation is to be constructed during parsing, from which both the time-based intervals are created alongside the events.

If additional parse formats should be added then it might be possible to extract both types of information from the same class, making it three parse modes to maintain rather than six.

Pitfalls
Don't forget to have the mode affect the XML export Don't forget to update all parts that have to do with DKP, so that an event-based only raid can not accidentally reward an interval. This is going to require substantial testing.

[Lokorin]

This suggestion was originally scheduled for version 1.3.10, but I'm postponing it to a later version.

The reason is that I'm split on which way I should implement this. Making the wrong choice could have a large negative impact on maintenance and future additions, so I need some more time to think. Keeping 1.3.10 on hold until I have figured everything out would be an unnecessary delay, especially as the version already contains many wanted features and a fix. Additionally this feature has not been requested by anyone and I have not seen any interest in it, so delaying it in favor of the rest of the version seems reasonable.

[Lokorin]

This is how I'm thinking about doing it right now:

Disclaimer: The following is mad rambling from inside my head partially meant as a note to myself. If you want to know what I'm actually mean then please ask.

First off the parse modes will be responsible for creating such a good de-facto participation as possible from the data they receive through the log. They are then responsible for deciding the time intervals that the intervals should be created from. The rest of the responsibilities (creating intervals, assigning loot, but also those that only affect a single mode e.g. processing add commands) are then defined in the common superclass as methods that operates on the ParsedDay instance, they can then be overridden if needed. The extending mode is thereby only responsible for extending three abstract methods: one for extracting a de-facto participation, one for deciding what proccesses that should be performed (e.g. should add commands be processed?) and one for picking the time intervals that should be used.

The reason for this is that beyond interpreting the participation the inner working of the modes are mostly the same. The super class gets to act as a toolbox from which the subclasses can pick as they like.

Additionally as little work as possible should be done before the actual day is selected, e.g. the program should only see from which days there are lines and then present those days as the choices (currently a lot of the data structures, dare I say most, are constructed prior to the user selecting a day).

The second and slightly bolder move is to remove the whole concept of logs. As I see it they are nothing but an artificial construct that made programming easier for the classic mode and do nothing but confuse users. Instead the program should just deal with intervals and the participation during them, it should also allow the user to modify the interval times afterwards. Any creation of new intervals should be backed by the de-facto participation. E.g. it should be possible for two intervals created by splitting a larger one to contain additional participants who did not attend the entire larger interval. The de-facto participation should therefor be an integral part of the DayBlock and should be modified directly. The intervals themselves should not be modified directly, they should be backed by the de-facto participation, the same goes for events. This brings an interesting question: should the GUI allow the user to modify the de-facto participation instead of the modifying an interval's participation? That will probably require it to also be possible to break or combine the intervals in the de-facto participation. The reward intervals and the de-facto intervals should still be separate things though as one might want a more detailed participation when e.g. handling events than one wants when handling reward intervals.

At the moment I'm happy with this idea, but I will have to think a bit more about it.

What I currently got in my head is a kind of view where one is displayed a long timeline (think video editing) where the de-facto participation is displayed, overlayed with the reward intervals and then the events as sharp lines. I will tinker together a concept image and edit it into this post in a moment.

*edit*

I have attached the concept image.