"However, parameters that are calculated in a first calculation can be accepted for use in a second calculation, if and only if they can not have changed between them. To provide a few examples:
Pixel scaling over several steps is permitted, as long as the size of the scaled objects usually stays constant.
Using the calculated speed of a projectile to calculate the speed of a character dodging said projectile on the very same occasion is usually permitted, as long as the projectile wouldn't have changed its speed mid flight.
Using a reliable stated timeframe and reliably stated speed something travels during that timeframe one can calculate the distance travelled. Said distance can then usually be used for calculations. (Take heed that paths don't need to be straight and that speed reliably has to be constant)
Multipliers can be used under the conditions lined out on the multiplier page.
Using speed of characters or attacks calculated at other instances can't be used, as characters and attacks can vary in speed. This is the case regardless of whether the character is seriously trying to do his best or anything similar.
However, even for these parameters calc stacking is avoided as much as possible. That means that results taking less such steps are usually taken over results that rely on more calc stacking."
I would really like opinions on this, as calc stacking is a very delicate issue with extensive consequences.
I support the clarification on what constitutes as acceptable calc stacking and what does not, though I'm also interested to hear if anyone else has any problems with any of these listed examples or if they think there are any more examples that should be included.
I'd like to think we just use common sense as to what is and isn't abusing calc stacking. So I'm fine with this. Perfect example is my most recent calc, it calcs the size of a small bit of a giant robot to then get the size of the rest of it.
Mr. Bambu wrote: I'd like to think we just use common sense as to what is and isn't abusing calc stacking. So I'm fine with this. Perfect example is my most recent calc, it calcs the size of a small bit of a giant robot to then get the size of the rest of it.
So what about your calc? Is it fine or calc stacking?
EDIT: NVM I'm dumb, the robot's size is consistent due to it being a game. Prolly is fine.
We have been doing the stuff, that the OP addressed, for a long time now and adding some specific examples for future users to reference would be helpful for them and us in the long run, as some time ago I asked about the second link, in reference to calc stacking, to a friend who had been on this wiki for a longer period of time than me.
Furthermore, maybe adding one or two links there as examples, in the page and the new explanation itself, would also provide a better perspective for these rules(?).
All left is clarifying that one sentence. What Crimzon Azoth proposes goes in the right direction, but we should maybe be more clear what we mean with consistent so that it's not confused with something in the direction of consistent feats vs inconsistent feats.
I think the examples do a lot to explain the meaning, but maybe instead of "are consistent" we could say something like "can't change".