depletionDelay has extremely divergant behavior between shields using the old regenHP/regenTime notation (including the Lazarus) and shields using the new regen notation.
Changing notations without chaning the regeneration rate can produce a factor of 12 (for regenTime="30") difference in actual shield regeneration rates as measured against weapon firerate.
Inconsistant behavior of depletionDelay
-
george moromisato
- Developer
- Posts: 2997
- Joined: Thu Jul 24, 2003 9:53 pm
- Contact:
You're totally right.
I believe the current code goes like this:
If using the new system (regen=) then depletionDelay is interpreted as the number of ticks before the shield starts recharging.
If using the old system (regenHP/regenTime) then depletionDelay is interpreted as the number of regenTime cycles before starting to recharge (i.e., ticks = depletionDelay * regenTime).
Is that roughly what you're seeing?
If so, I would love to hear preferences on how to fix it:
1. Introduce a new attribute (e.g., depletionDelayTicks) for the new system. This will (obviously) break all shields created with the new system.
2. Redefine depletionDelay so it is always expressed in ticks. Of course, this will break any shileds with the old system.
3. Leave things as they are and document them (I think, over time, everyone should be using the new system--please chime in if you disagree).
Are there other possibilities?
I believe the current code goes like this:
If using the new system (regen=) then depletionDelay is interpreted as the number of ticks before the shield starts recharging.
If using the old system (regenHP/regenTime) then depletionDelay is interpreted as the number of regenTime cycles before starting to recharge (i.e., ticks = depletionDelay * regenTime).
Is that roughly what you're seeing?
If so, I would love to hear preferences on how to fix it:
1. Introduce a new attribute (e.g., depletionDelayTicks) for the new system. This will (obviously) break all shields created with the new system.
2. Redefine depletionDelay so it is always expressed in ticks. Of course, this will break any shileds with the old system.
3. Leave things as they are and document them (I think, over time, everyone should be using the new system--please chime in if you disagree).
Are there other possibilities?
Until today I'd thought that you'd taken option 2 already, mostly because the only remaining shield under the old system has such a low regenTime, and that under the old system depletionDelay was measured in seconds.
The most important thing is that whatever the behavior is it's documented.
The most important thing is that whatever the behavior is it's documented.