diff options
author | Daniel Schadt <kingdread@gmx.de> | 2018-04-25 14:07:00 +0200 |
---|---|---|
committer | Daniel Schadt <kingdread@gmx.de> | 2018-04-25 14:07:00 +0200 |
commit | 6d0e4a82f298dbd282214d458d2e00e8a52c0768 (patch) | |
tree | 36dc09260b25084a6c8e5e54b0fa0c4c56e48b87 /src | |
parent | 7d35d1a4ecf4d7fe6689c83defd9163b7a66f915 (diff) | |
download | evtclib-6d0e4a82f298dbd282214d458d2e00e8a52c0768.tar.gz evtclib-6d0e4a82f298dbd282214d458d2e00e8a52c0768.tar.bz2 evtclib-6d0e4a82f298dbd282214d458d2e00e8a52c0768.zip |
add a note on how boon queues work
Diffstat (limited to 'src')
-rw-r--r-- | src/statistics/boon.rs | 30 |
1 files changed, 29 insertions, 1 deletions
diff --git a/src/statistics/boon.rs b/src/statistics/boon.rs index 65e5c89..4d0348e 100644 --- a/src/statistics/boon.rs +++ b/src/statistics/boon.rs @@ -16,7 +16,35 @@ pub enum BoonType { /// # A quick word about how boon queues work /// /// For each boon, you have an internal *boon queue*, limited to a specific -/// capacity. +/// capacity. When the current stack expires, the next one is taken from the +/// queue. +/// +/// The queue is sorted by boon strength. This means that "weak" boons are +/// always at the end (and as such, are the first ones to be deleted when the +/// queue is full). This prevents "bad" boons (e.g. the Quickness from Lightning +/// Hammer #2) to override the "good" boons (e.g. the Quickness from your +/// friendly neighborhood Chrono with 100% boon duration). +/// +/// This also means that boons can be "lost". If the queue is full, the boon +/// might not get applied, or it might replace another boon, thus wasting some +/// of the boon duration. +/// +/// Intensity-stacked boons (such as Might) work a bit differently: as time +/// passes, all stacks are decreased simultaneously! As soon as a stack reaches +/// 0, it is dropped. +/// +/// Now, you might ask *"How do I know how big the boon queues are?"* and sadly, +/// I do not have a satisfactory answer for this. For intensity-based boons, the +/// answer is "the number of maximum stacks". However, most boons are not +/// intensity-based. For all other boons, either check the source code of other +/// people who (claim to) know, or just make up a value. Your calculations might +/// be off by fractions of a second, but it should be good enough for most use +/// cases. +/// +/// Interesting fun fact: Most (if not all) boons don't have a hardcoded limit +/// on how much you can have at a time, it rather depends on the boon duration +/// of the person who applies them. The only limitation is the size of the boon +/// queue. #[derive(Clone, Debug)] pub struct BoonQueue { capacity: u32, |