Participation and reward intervals, oh my

[impishfae]

I've taken a look at the latest code dump and I think my brain broke.

I guess mainly what I don't understand is why there is the capacity to separate the participation intervals from the reward intervals, now that it's so easy to manipulate the participation interval data. Given you can change your participation interval data to perfectly reflect how you'd like your reward intervals to work, I'm missing the distinction on why they are different entities.

Obviously, a participation interval just records the start/stop times for an interval with the people present within that timeframe... but isn't that basically what a reward interval is too? The reward interval may have other characteristics (padding at start/end, weighting, etc) which affects how the DKP is calculated, but they're sorta attributes attached to the participation interval which controls how it's interpreted for DKP.

(I loaded up my latest raid log, cleaned up my participation intervals using the new tool which is a breeze to use: great stuff. Then switched tabs to check out the reward intervals and found myself surprised to see they had remained in the start/stop times my original participation intervals had started with. Then I found myself wondering why I was surprised as I know they're discrete entities. Then I wondered why they were discrete entities. Then I came here and posted delicious, tasty, glorious, SPAM. Oh lordy, save me from the spam)

[Lokorin]

The main reason that participation intervals exist are events. The problem with replacing the participation with reward intervals recording their own participation (instead of sampling the participation intervals') is that it would all of a sudden be hard to give the events a correct participation. Without the participation intervals one would have to keep two separate participation systems: one for reward intervals and one for events, changing one of them would not affect the other (which could lead to situation where one is present during 11:00 to 12:00 in one system, but not present during 11:30 in the other).

A good example of why this is useful is to parse a CT RT log from WoW (there are a few test-logs in the repository in com.lokorin.dkplp.test). They use the join/leave mode and therefor contains a lot more information about the participation than what's needed for the reward intervals. Discarding all but the reward interval participation would cause a large loss of information which could affect events.

[impishfae]

Hmm! There must be more to events than I'm aware of...

I just assumed that an event was attached to a single timestamp and that the event dkp value would be assumed to the people who were present for whatever reward interval that event timestamp fell into.
(And if you manipulated your reward intervals or changed your event timestamp so that the event was outside any reward interval, then you're a noodle.)

Am I missing something?

[Lokorin]

It used to be that way in 1.3.10. In 1.4.0 however that changed so that one can be present in an event at 11:30 without being present in an reward interval spanning 11:00 to 12:00 (e.g. if one joined the raid at 11:20). The events now sample the participation directly (as shown in some diagram in some other post), hence they are now on the same level as reward intervals, they do not depend on reward intervals in any way.

Another reason for the change is the event-only reward system which does not have any reward intervals, only a participation and events.

[impishfae]

Soooo... (see images below)

Participationrewards.png shows the raid before anything has been altered (whether the attendance details are generated via classic or first/last or join/leave doesn't really matter)

Participationrewards-1.4.png shows the raid after a spare participation record was removed so now the second reward interval has a different set of participants: A gets to stay for the whole interal since he was present at the start and the end. But the event in reward interval 2 is only awarded to C and D because A wasn't present during that reward interval.
(The grey letters up the top are the members receiving DKP for the reward/event)

Do I understand correctly?

So the system actually retains the participation record information behind the scenes, even after you remove it using the UI (via remove or joining intervals together), so that it can correctly generate the event award recipients?

(head promptly explodes)

There's gotta be a better way to get this info to the user.

Maybe have a 'simple' mode where reward intervals are tied explicitly to the participation records: you edit the participation details and the reward intervals automatically update to match them. (and in which case the second event above would be awarded to A,C,D) Then an 'advanced' mode where events and reward intervals are separated from the participation records and editing any of participation/events/rewards doesn't alter the others.

Or even (how fiendish would this be to implement! but still) a graphical representation of all this stuff, much as the diagrams we've been drawing.
So you've got the timeline going horizontal across the screen: this is immutable.
Then a number of little widget sliders underneath it for the participation: selecting one shows you the participation details for that point. Moving it back and forth along the line changes the start/end points for that participation interval. These can be moved off the end of the timeline, which extends the timeline with it.

Then a number of little widget sliders on top of the time line for the reward intervals. These can be deleted (effectively performing a join) or new ones added (performing a split/add). You can move the sliders to change when the reward intervals start/finish. (but you can't make them off the end of the timeline)

And a third set of other widget sliders for the events.

A lil palette to one side lets you drag out a new slider (creates a new thing) or if you pull an old slider onto it, it deletes that thing.

This could still have simple/advanced mode where the reward sliders auto-move when you change the participation bits in simple mode.

It might even be cleaner if this had an event view and a reward interval view, so you weren't dealing with both simultaneously. (toggle the events on/off, toggle the reward intervals on/off: affects view only, not the calculation)

Urg. I'm not describing it too well, so another graphical version attached: fiendishgraphicalui.png
Where sliders are blue, they're highlighting the thing which is listed in the appropriate box beneath.

[Lokorin]

[impishfae]

It was late late late last night when I wrote that last post. I cannot be held responsible for my actions!

[Lokorin]

Something like that should probably not be too hard to make, so it will be attempted in some future version.