aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDaniel Schadt <kingdread@gmx.de>2018-04-25 14:07:00 +0200
committerDaniel Schadt <kingdread@gmx.de>2018-04-25 14:07:00 +0200
commit6d0e4a82f298dbd282214d458d2e00e8a52c0768 (patch)
tree36dc09260b25084a6c8e5e54b0fa0c4c56e48b87
parent7d35d1a4ecf4d7fe6689c83defd9163b7a66f915 (diff)
downloadevtclib-6d0e4a82f298dbd282214d458d2e00e8a52c0768.tar.gz
evtclib-6d0e4a82f298dbd282214d458d2e00e8a52c0768.tar.bz2
evtclib-6d0e4a82f298dbd282214d458d2e00e8a52c0768.zip
add a note on how boon queues work
-rw-r--r--src/statistics/boon.rs30
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,