Applies this Processor to the given input object, in the context of the given context object. NOTE if the HitDie provided is not in the global sequence of HitDie objects (defined in the Game Mode), then this method will fail to step that HitDie, and the original, unmodified HitDie will be returned
(HitDie origHD, Object context)
| 98 | * if the given HitDie is null |
| 99 | */ |
| 100 | @Override |
| 101 | public HitDie applyProcessor(HitDie origHD, Object context) |
| 102 | { |
| 103 | int steps = numSteps; |
| 104 | HitDie currentDie = origHD; |
| 105 | while (steps != 0) |
| 106 | { |
| 107 | // Order is important, dieLimit may be null |
| 108 | if (currentDie.equals(dieLimit)) |
| 109 | { |
| 110 | return currentDie; |
| 111 | } |
| 112 | if (steps > 0) |
| 113 | { |
| 114 | currentDie = currentDie.getNext(); |
| 115 | steps--; |
| 116 | } |
| 117 | else |
| 118 | { |
| 119 | currentDie = currentDie.getPrevious(); |
| 120 | steps++; |
| 121 | } |
| 122 | } |
| 123 | return currentDie; |
| 124 | /* |
| 125 | * Theoretically, the die sizes here should be stored as ... what? A |
| 126 | * AbstractSequencedConstant, effectively? This gives the ability to |
| 127 | * look up the next one... that makes HitDie not really storing an |
| 128 | * Int... so Hit Die really should be a helper, or an enumeration? |
| 129 | * |
| 130 | * So it looks like an enumeration is OUT because the MODs will actually |
| 131 | * alter to unexpected values... like 8 * 3 = 24... therefore, this |
| 132 | * really needs to be thought through to determine what is best... The |
| 133 | * behavior for these cases is undefined. |
| 134 | * |
| 135 | * There is a (short) thread on pcgen-devel "Hit Die Locking" from Nov |
| 136 | * 2006, where this issue remains unresolved. |
| 137 | */ |
| 138 | } |
| 139 | |
| 140 | /** |
| 141 | * Returns a representation of this HitDieStep, suitable for storing in an |
nothing calls this directly
no test coverage detected