shuyun

Yes, that would be awesome.

Thanks!

[ QUOTE ]
FYI - I just found out that this will be removed. We need to keep test global chat separate from live global chat so that we can test updates over there. Sorry about that!

I will look into getting the PDF in HTML format and/or added to the support documentation.

CJ

[/ QUOTE ]

I think many people would value keeping Training Room on live global chat.

Can't testing of new versions or improvements be handled via a /chatbeta switch like how it is now? That way, the same mechanism can be used to include the live servers into test.

HotFeet is 0.6944 (25/36) in issue 3; an increase of 25% from the previous value (20/36).

Only tested Controller version.

Btw, how was it determined to use +0.005 and +0.015 for the display value's adjustments to get the actual possible damage ranges?

Ugh. I was almost done with a reply and accidentally closed my browser. ...darn thing called work getting in the way... :P

Anyway, you see increases of 6 to 7 END per tick. This is like what's observed with Base Regen. It's 6.667 END per Tick (or 20/3 EPT). I'm pretty sure that the amount per tick stays the same. Even a 5% increase would bump the EPT to 21/3, or 7. This is not what you're seeing with Stamina or the Atlas Medallion in place.

So if the EPT is not increasing, then the ticks are coming faster. Base regen seems to be once every 4 seconds. It takes exactly 15 ticks to regen 100 Endurance. If we time how long it takes to go from 0 to 100 END, it should be anywhere from 56 to 60 seconds. Why the spread? It depends on when the first tick occurs. The final tick occurs 56 seconds (14 * 4 sec) after the initial tick, which can occur anywhere from 0 to 4 seconds after we start timing.

Ok, let's figure out the frequency with Stamina. Stamina effectively adds 25% to regen rate. We can calculate frequency with the following equation:

Frequency = (Base Frequency) / (1 + additional_regen)
= (4 sec) / (1 + 0.25)
= 4 sec / 1.25
= 3.2 sec

Stamina's tick rate is once every 3.2 seconds. It's difficult to measure each tick, but we can sort of verify by observing how long it takes to go from 0 to 100. (14 * 3.2) = 44.8; 15 * 3.2 = 48. The expected time is from 44.8 seconds to 48 seconds over a total of 15 ticks.

Now let's try for 6 slotted Stamina. Using Even SO's, additional regen becomes 75%.
Frequency = (Base Frequency) / (1 + Additional_regen)
= (4 sec) / (1 + 0.75)
= 4 sec / 1.75
= 2.286 sec

The frequency of each tick is once per 2.286 seconds. Expected 0 to 100 time is 32 to 34.29 seconds.

Can someone run a few quick tests to confirm the 6 slot times fall between 32 and 34.3 seconds over 15 ticks? That'd help tremendously.


Now for ZeroG's tests with Stamina and the Atlas Medallion. With 105 max END, it would take 16 ticks (106.667 END) to get to full. The times were all less than and within 0.5 second of 45.7, so we have a time range of 45.2 to 45.7 seconds. The possible frequencies are as follows:

Time ... Frequency range
45.2 ... 2.825 to 3.013.(45.2/16 to 45.2/15)
45.7 ... 2.856 to 3.047 (45.7/16 to 45.7/15)

Knowing the frequency range, we can work backwards to overall regen vs base.

Regen = (Base frequency) / (Frequency)

Freq ... Regen
2.825 ... 141.59%
3.047 ... 131.29%

So Base + Stamina + Atlas Medallion has an effective endurance regen rate of 131.3 EPM to 141.6 EPM. This range could be narrowed further if we knew the starting time of the first tick.

Zero G,

If possible, could you also get the Times and Endurance on the 2nd and 2nd to last regen ticks? I'm interested these to eliminate a few possible sources of error.
<ul type="square">[*] The final regen tick would bring you over Max END (105 in your case). Base regen is 6.667 END per 4 seconds (any different with Stamina or Atlas?), so the overall change in END could be 106 when assuming it's 100.[*] The regen tick and timer are unsynchronized. If the first regen tick comes right after your stopwatch is started, then you're getting a lot of END in little or no time. Recorded times might be off by a whole regen cycle. That's up to 4 seconds with base regen![/list]
I noticed those problems during some tests of Fly + Sprint. Out of curiosity, I timed how long it took for me to regen to full END after Fly alone shut off. I timed 72.2 seconds for Sprint + Base regen to get back to full. Plugging that into some rough calculations...

Overall EPS of (Base &amp; Sprint) = (Change in END) / (time)
= (100 - 0)E / 72.2 s
= 1.385 EPS

Sprint EPS = Base EPS - Overall EPS
= 1.667 EPS - 1.385 EPS
= 0.282 EPS (or 16.90 EPM)

The commonly accepted Sprint EPS is 0.33 to 0.35 EPS (20 to 21 EPM), so what was wrong?

I started timing when Fly shut off. I assumed that END was 0, but that might not have been the case. Fly seems to tick every half second at 1 END per Tick (1 EPT); Sprint also ticks every half second at 0.175 EPT. If I had 0.9 END, Fly would have shut off, but it would have been more than sufficient for Sprint. That's one possible source of error.

Another mistake was that the Regen might have ticked right after I started timing. My recorded time was 72.2 seconds. Counting regen ticks backwards every 4 seconds, my first tick would have been at 0.2 seconds. 6.667 END in 0.2 seconds time!

The last mistake was stopping when I saw my END bar fill to 100. I *think* I had about 96 END before the final tick, roughly extrapolating to an actual ending value of 102 END.

Here's my calculations if I adjust for those errors:

Assume Change in END is about 101.5 (102 - 0.5).

During the 72.2 seconds, I had 19 END ticks.
Base END gain = 19 ticks * 6.667 EPT = 126.667 END

Sprint END loss = Base END - Change in END
= 126.667 - 101.5
= 25.167 END

Sprint EPS = 25.167 END / 72.2 seconds
= 0.349 EPS (20.91 EPM)

This value is much closer to the common Sprint EPS values. I should really do the tests again but with synchronized start times and such. That way I have much less assumptions for the calculations.

[ QUOTE ]
Why would you add 5 EPM?

[/ QUOTE ]

Because all endurance rates we've seen so far are additive, and not multiplicative. I can see making an exception with the Atlas Medal and making it multiply by 105% once due to increasing max END. However, I don't understand why it would be multiplying twice. Using the Add-then-multiply calculation for Base+Stamina+Atlas, the expected 0 to 105 time is 46.15 seconds -- within 1% of 45.7 from the two-multiply calculation.

[ QUOTE ]
The Atlas Medallion

I also have one character with the Atlas Medallion. That character has Stamina. Going into this test I expected one of two likely scenarios. Base regen and Stamina are 100EPM and 25EPM absolute values respectively or base regen and stamina are +100%EPM and +25%EPM of maximum endurance.

Expected time if regen values are absolute is 50.4 seconds since the total end to be recovered is 105 instead of 100. Expected time if regen values are based on max end is 48 seconds, the normal time for unenhanced Stamina. This would translate to an EPM of 131.25, 5% over normal.

Over and over and over endurance went from 0 to 105 in 45 seconds and change!!! Let's start with that 131.25EPM value for percentage based regen and consider the Atlas Medallion is adding +5% to total regeneration rate in addition to the boost gained from having a higher max end. 105% of 131.25 is 137.8125EPM. This would yield an expected recovery time of 45.7 seconds which is extremely close to what I was seeing over and over again.


[/ QUOTE ]

Are you certain it's 45.7 seconds? Because that means your END regen is multiplied by 105% twice for a total of 10.25%!

(100 + 25) * 1.05 * 1.05 = 137.8125

It's much different from adding 5 EPM, then multiplying the entire thing by 105%.

(100 + 25 + 5) * 1.05 = 136.5

This difference would be even more pronounced as natural regen rate increases. With 6-slotted Quick recovery and Stamina...

(100 base + (25 * 3) stamina + (33.3 * 3) Quick) * 1.05 * 1.05
= (275) * 1.05 * 1.05
= 303.1875 EPM

compare to adding then multiply:

(275 + 5 Atlas) * 1.05
= 294 EPM

Makes it oh so very nice =)

[ QUOTE ]
I'm lazy so I have to ask; what would you get if you instead assumed Sprint drains 20 epm? I've done a series of measurements and they all seem to indicate sprint drains closer to 20 epm. Most recently I calculated Fly+Sprint to 140.2 epm.

I prefer to use linear regression of several samples taken after a recovery tick. More samples tends to even out rounding off errors.

[/ QUOTE ]

Assuming that Sprint is lowered by 1 to 20 EPM, then Fly's EPM is raised by 1. This change would only affect Grotus' figures:

Fly + Sprint + base regen: -100 End in 140 sec.
=&gt; 122.857 EPM (2.0476 EPS)
Fly + Sprint + Base + Stamina: -100 End in 386 sec.
=&gt; 121.304 EPM (2.0217 EPS)

BTW, can you post the times for the tests you ran?

[ QUOTE ]
[ QUOTE ]

=&gt; 121.053 EPM (2.0175 EPS)
=&gt; 121.857 EPM (2.0310 EPS)
=&gt; 120.304 EPM (2.0051 EPS)

The times were at least 140 seconds, so timing errors wouldn't be a large factor. Even when calculating from + and - 1 second times, the results of those three trials still do not match up.

[/ QUOTE ]

So, let me get this straight: You're comparing these 3 rates, and getting a spread of difference that ammounts to just over 1%? And you think this can't be accounted for by timing errors?

[/ QUOTE ]

To get Grotus' figures to come up with a matching rate, he would have needed times of 144 and 360. That's being slow by 4 seconds and fast by 8 seconds! For balfour to match up too would have required a time of 290 (slow by 5 seconds). How likely is it that they're both mis-timing by that much?

I've gone through this thread and gathered some of the reported raw data for Fly. The problem is, they all end up with different rates.

by balfour:
Fly + base regen: -100 End in 285 sec.
=&gt; 121.053 EPM (2.0175 EPS)

by Grotus:
Fly + Sprint + base regen: -100 End in 140 sec.
=&gt; 121.857 EPM (2.0310 EPS)
Fly + Sprint + Base + Stamina: -100 End in 386 sec.
=&gt; 120.304 EPM (2.0051 EPS)

Used Sprint 21 EPM (0.3500 EPS), and Stamina 25 EPM (0.4167 EPS).

The times were at least 140 seconds, so timing errors wouldn't be a large factor. Even when calculating from + and - 1 second times, the results of those three trials still do not match up.

[ QUOTE ]
[ QUOTE ]
When I recalculated those powers with EPM, I got less than 1% difference between observed and calculated times.

edit: noticed that some powers work best in 0.5 EPM increments (e.g., stealth 22.5, lightning field). Changed round function to reflect such.

[/ QUOTE ]

Looks like you might have actually found, as an above poster put it, 'the continium where all the numbers are nice and round'. Of course, the numbers need to be tested from Venmon's massive raw data and see if we get corrilations. Still, very interesting.

[/ QUOTE ]

Actually, Ian_of_Moore first put his numbers as EPM in this post. It made much more sense than the EPS numbers, and taken to the nearest 0.5 EPM, more precise than 0.01 EPS.

And yeah, Vennom's collection of raw data would be great.

[ QUOTE ]
[ QUOTE ]
Great thread.

So I just did some testing, having a near optimum build to test out Stamina and Lightning field, and my results seem to strongly indicate, unless there is an erorr in the values for my other powers used (listed below), that Stamina is in fact a 0.56 value. That a full drain recovers back in 45 seconds seems to support this.

[/ QUOTE ]
Ouch...if the regen values being used all along are inaccurate then the results are skewed. Certainly some people have tested with stamina and some without.

I'll copy some characters to test tonight and measure base end regen, regen with stamina, and regen with stamina and QR.

Vennom probably still has all the times that have been submitted to him and could correct for different regen values. If he's still around...

[/ QUOTE ]

Searching for Vennom, seems like he's been posting on the defender board.

In any case, the recharge difference between stamina at 0.56 and 0.42 is only 3 seconds (45s and 48s), so it's critical to be precise. On top of that, the END bar ticks up at 3 or 4 second intervals, so multiple tries are needed. Ian of Moore explained early in the thread how measurements can be skewed by starting and stopping at different points in the Endurance regen cycle. Furthermore, each toggle you run goes on varying cycles, so that also fuzzes precise measurement. Hopefully, the errors cancel each other out, but there may be times that they stack.

Another way of determining whether Stamina is +25 End/Min or +33.3 End/Min is to try a combination of toggles with a total cost between 125 EPM and 133 EPM. That way, simply seeing if you gain or lose End would be conclusive.

Hmm, can someone test this? Put an even or green SO Endurance Regen into Stamina. Then run Fly and Sprint at the same time -- this is about -141 EPM. If unenhanced Stamina is 33.3 EPM, you'll regen at least 144 EPM and won't lose Endurance. If unenhanced Stamina is 25.0 EPM, you'll regen at most 138.3 EPM and will start losing Endurance.

[ QUOTE ]

Results for:
Frozen Armor: calculated to +0.35 eps, approximately 75 (74) seconds to recharge from 0-100 endurance
Chilling Embrace: calculated to +0.35 eps, approximately 75 (74) seconds to recharge from 0-100 endurance
Icicles: calculated to +0.72 eps, approximately 105 (104) seconds to recharge from 0-100


[/ QUOTE ]

Balfour,

I took your observed times and recalculated. I got:
<ul type="square">[*]Frozen Armor: 20 END per minute (0.3333 EPS)[*]Chilling Embrace: 20 END per minute (0.3333 EPS)[*]Icicles: 43 END per minute (0.7167 EPS)[/list]
I did it by calculating from Endurance per Minute, which is a bit more accurate that EPS. It's also interesting that when looked at Endurance per Minute, you get nice looking values.

Here's the calculations that I used (i'm listing columns from Excel):<font class="small">Code:[/color]<hr /><pre>DATA:
A) Frozen Amor, base regen
B) start END: 0
C) end END: 100
D) Observed time (sec): 75

CALCULATIONS:
E) Change in END: = C - B = +100
F) Observed time (min): = D / 60 = 1.2500
G) Observed Rate of Change in END = E / F = 80.0000
H) Known Regen per min : = BASE regen = 100
I) Known Use per min: = nothing else used = 0
J) Unknown RATE: REGEN - USE - ObservedRate = H - G - I = 100 - 0 - 80 = 20.0000

RESULTS:
K) Rounded RATE (This is END per Min): round(j/0.5, 0) * 0.5 = 20.0
L) END per Sec: = K / 60 = 0.3333

VERIFICATION:
M) Calculated Total Rate: REGEN - USE - EPM = H - I - K = 100 - 0 - 20 = 80
N) Time to recreate END Change: END Change / Calculated rate = 100 END / 80 EPM = 1.25 Min
O) Time in seconds: = N * 60 = 1.25 * 60 = 75
P) Percent difference: (Observed - Calculated) / Calculated = (D - 0)/ D = 0%
</pre><hr />
Using the above strategy, I went through this thread and looked for posts and recalculated based off observed times. I got the following:
<font class="small">Code:[/color]<hr /><pre>POWER EPM EPS
---------------------------------------
BASE 100 1.6667
SPRINT 21 0.3500
ASSAULT 28 0.4667
CHILLING EMBRACE 20 0.3333
FLIGHT 120 2.0000
FROZEN ARMOR 20 0.3333
HOVER 14 0.2333
ICICLES 43 0.7167
INVISIBILITY 90 1.5000
LIGHTNING FIELD 52.5 0.8750
MANEUVERS 28 0.4667
STEALTH 22.5 0.3750
SUPER SPEED 34 0.5667
TOUGH 14 0.2333</pre><hr /> (copy &amp; paste to notepad to view nicely)


When I recalculated those powers with EPM, I got less than 1% difference between observed and calculated times.

edit: noticed that some powers work best in 0.5 EPM increments (e.g., stealth 22.5, lightning field). Changed round function to reflect such.

[ QUOTE ]
Looks like [CONTROLLER] hot feet is ~-.72 eps. My calculations:

1:31 to drain end running to 0: maneuvers, SS, sprint, stealth &amp; HOT FEET

-100/91 = =-1.099 eps


+2.09 base end regen (base + stamina no enhances)
-.53 SS
-.45 man
-.38 stealth
-.35 sprint
=+.38 eps

-.719 eps HOT FEET
=-1.099 eps

...(snip group fly stuff)...

Did I do the calculations right?


[/ QUOTE ]

No.
0.38 + HotFeet = -1.099
HotFeet = -1.099 - 0.38
HotFeet = -1.479
HotFeet is about -1.48 EPS.

With HotFeet running alone, I gain about 15 END a minute. With HotFeet and Sprint, I LOSE about six per minute (all eyeball figures =p). With HotFeet at -0.72, I shouldn't lose END at all, so 1.4X is much more appropriate.

BTW, it'd be more accurate to have EPS calculated by Vennom (psst...mind sharing that spreadsheet if you aren't updating Toggles?) Reason being that the END total and powers EPS used are rounded to two places; the spreadsheet would be much accurate by working from pure Drain-to-Zero times.

To illustrate, look at the END regen rate you're using (2.09).
Base is 100 per 60 seconds (100/60)
Stamina is +25% of base (25/60)
Total is 125/60, which equals 2.083333...

It's actually closer to 2.08 than 2.09, making END values calculated from 2.09 possibly skewed higher. Other rounding errors could add up to create substantial inaccuracies.

[ QUOTE ]
[ QUOTE ]

How about keeping the Area the same, but have a damage scaling depending on the number of enemies affected. For each AoE power, set an arbitrary threshold for 100% damage. When you hit a group bigger than the threshold, damage (or even accuracy) per mob is decreased. This would reflect densely packed mobs inadvertently shielding each other from taking full damage through sheer proximity.

Range Increase enhancements could be used to adjust the threshold and damage scaling for more customization options.

This would lessen farming of huge mobs. It'll make the difference between fighting 5, 10, 20+ enemies at once much greater. It could also mean Player Characters taking less AoE damage when in larger groups (imagine huge Raid level events).

[/ QUOTE ]

I have a great idea. How about when tanks get attacked they get their full resistance against the first enemy but each enemy after that does more and more damage? And when controllers hold a group they hold 1 enemy for the full hold but the time is reduced for each enemy after that? Also, when a defender buffs/debuffs the effectiveness is reduced for each additional target. That would be great!

Oh wait... no... those suggestions are ridiculous. So is yours. Put down the nerf bat and quit your complaining.

-AZ

[/ QUOTE ]

Complaining? Where?

You seem to be overreacting, and I think I know why. From your "ridiculous examples," you seem to be misconstruing what I proposed. I did not say that the first enemy is hit with full damage, then the rest will get decreasing damage. Hell, even I'd agree that'd be an over-nerf. I was proposing that damage be decreased when an arbitrary mob threshold is reach. Perhaps the Devs, with their datamining and vision could find a reasonable threshold.

By the way, how big of groups do you AoE? And what would you consider to be a reasonalbe threshold?

[ QUOTE ]
AoE max mobs hit = 4. Don't change the accuracy, just cap the # of opponents you can hit. 5 might be a better number.

AoE max damage = 4 X single target damage, if you hit more than 4 targets the damage per target starts to decrease.

I'm sure there are other ways. The second idea is in keeping with the idea that a blast only has so much power and that power gets distributed amongst the targets.

AoE is AoE, so this should affect ALL AoE, not just blaster.

[/ QUOTE ]

A cap on #hit would be bad. Too limiting for those who want to hit more. Also, you can't select more than one person, so you won't have control of who you're hitting. As missing is usually a Bad Thing, accuracy scaling should be very slight (if at all).

The damage idea with scaling is like what I proposed earlier, but with a suggested hard number (4). I'm thinking different powers could get different damage caps and scaling to differentiate them more. It makes them less of the same power with different graphics.

These ideas could be used for all AoE Damage powers. Kind of hesitant about status/control AoEs though, as they get penalties to Acc, whereas Blaster AoEs can come with bonus to Acc.

How about keeping the Area the same, but have a damage scaling depending on the number of enemies affected. For each AoE power, set an arbitrary threshold for 100% damage. When you hit a group bigger than the threshold, damage (or even accuracy) per mob is decreased. This would reflect densely packed mobs inadvertently shielding each other from taking full damage through sheer proximity.

Range Increase enhancements could be used to adjust the threshold and damage scaling for more customization options.

This would lessen farming of huge mobs. It'll make the difference between fighting 5, 10, 20+ enemies at once much greater. It could also mean Player Characters taking less AoE damage when in larger groups (imagine huge Raid level events).

Wonder if it could still be done with the fixed Smoke.