Users:Neurfur/StatTimer

Below is a theory I have put together on how the stat timers work in T5. Feel free to stress test this and prove me wrong.

Definitions

Bonus - An action that does not take any resources from the pool. There is only 1 bonus action.
Pool - A buildup of points that can be expended to do an action or multiple actions. Size is fixed at 256.
Penalty - A period of time where an action requiring a certain stat cannot be performed. That stat is bright red in the skills tab.
Cost - The cost of an action. Cost is equal to 7 * the timer. Base timer numbers can be found here. Costs never change.
Stat - The number assigned to a certain stat. Typically 0-7, but can be higher on food.

Model

Conclusions

• You cannot cheat the timer. You must wait an equal amount of time that the actions cost. However...
• The timer can cheat you. If your first action has a high cost, you wait until you almost have your bonus back, then do a small cost action. Any leftover time in the BonusTimer is lost.
• Higher stats do not let you do more actions or queue up more points. It simple refills your Pool and BonusTimer faster. Therefore...
• In burst mode, someone with 0 stats can do just as many actions as someone with high stats. The difference is the higher stat player will be ready to burst actions sooner.
• If you are fully recharged, you are guaranteed 2 actions, regardless of the cost.
• The timer is clientside.

Proof

A series of experiments used to test and understand each part of the model. All tests are performed fully recharged.

• Stats do not lower the cost.
  

Stat0 : 60s -> 60s = 23s penalty
Stat2 : 60s -> 60s = 18s penalty
Using a cost reduction model of 7/(7+stat), the anticipated penalty would be 10s.

• Stats do not increase the pool.
  

Stat0 : 40s -> 40s = 3s penalty
Stat2 : 40s -> 40s = 3s penalty
If the size of the pool had gone up, the penalty would be lower.

• Timer is clientside.
  

Stat0 : 60s -> 40s wait -> 60s ->60s = 43s timer.
If the timer was server side, an error of about 10% would be expected (slower timer). A rounding error of a second is acceptable for clientside timing.