ZeroG_NA

Great guide, TopDoc!

I was wondering if the inconsistent speeds you saw with jumping are due to a steady loss in forward momentum after the jump's apex. For instance if you jump from a high place to a low place you will be travelling almost straight downward at the end despite holding down w the entire time. I have always wondered if this was purely due to downward acceleration or a combination of that and forward deceleration.

Did you try testing with only low jumps, where you always briefly release the space bar shortly after the jump begins so that the apex is never very far from the ground?

I've done this as well. It allows a blaster to have scrapper like defenses while mass slaughtering an area. You can even herd farm portal corp missions with a blaster due to the handy contact at the entrance to portal corp. It does feel like a super cheap tactic because 50 inf per insp is truly meaningless compared to the inf per kill as you get higher level.

I hate street grinding but it is amazing how fast you can rack up the kills when hunting around a contact in an area with mobs higher level than you would otherwise be fighting. I like 2 green, 2 blue and the rest luck. That way you have no downtime between batches of mobs and can periodically restock from the contact.

It gets old quick.

Shuyun, since I'm measuring recovery and not drain any "overage" would actually mean even greater recovery rate!

In order to insure I was starting from as close to zero as possible I only timed instances where all toggles dropped. If some dropped and some didn't I figured I wasn't at zero and turned the toggles back on.

There was also no doubt about reaching 105 vs 104, 103. You should never be guessing about that. Right-click your end bar and leave the cursor hovering over the bar. This will give you a digital readout of your end. In every run the pattern ended with 98/105 then 105/105. The last tick gained 7 end.

I didn't write out the full pattern but did observe that every tick from 0 to 105 was either 6 or 7. There was never an increase of 8 end.

Shortly after I logged on to test the message came across that the server was going down in 5 minutes so I only ran a few runs--getting 45 seconds in Issue3 as well.

Sorry for the delay in responding; I usually don't read the forums when not at work.

Almost all of my runs with the Atlas Medallion were less than 45.7 seconds but within half a second of 45.7.

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

(100 + 25 + 5) * 1.05 = 136.5

[/ QUOTE ]
In the case that end regen (base and stamina) are percentages of max end then base regen goes up to 105 EPM (100% of 105) and Stamina goes up to 26.25 (25% of 105) for a total of 131.25 EPM. This is one of the scenarios I considered likely. In this case time to go from 0 to 105 with the Medallion should be the same as going from 0 to 100 without it. Which is not totally suprising since hit point regen is relative to max hit points, rather than absolute.

This would yield an expected time of 48 seconds for Stamina with the Atlas Medallion, the same time as without the Medallion. I was very surprised to see end go from 0 to 105 just over 45 seconds. I supposed that the Atlas Medallion may increase total recovery rate by 5% in addition to increasing max end. This does compound the effect since recovery rate has already increased because it is based on max end.

It is a supposition. It matches the observed recovery time. There may be another explanation for the excess recovery rate. I could only time with Stamina. I don't have a character with the Medallion and Quick Recovery or one without Stamina.

If endurance recovery (base, Stamina, Quick Recovery) works as percentages of max endurance (100% per minute, 25%/min, 33%/min) and the Atlas Medallion increases total recovery by 5% (which is not in its description) then the end result is 125EPM x 1.05 x 1.05 (because this char has stamina) which is 137.8125 (a total increase of 10.25% over a character with Stamina but no Atlas Medallion).

It's not what I expected. At the time I believe test and live were running the same build. I'll run some more tests on test (since it is definitely running a different build now) and see if I get the same results.

[Leaving work early today, no time to proof read, please forgive any typos]

[ QUOTE ]
EDIT2: I just realized that the calculation method that I'm using and ZeroG used is different. Going from 0 to 100 end is 60 seconds without any regen power. With the atlas medallion, going from 0 to 105 end should still be 60 seconds. Increasing EPS regen decreases the time between ticks not the amount. What the atlas medallion is doing is increasing your max end value. I'm thinking the actual tick amount increases where as regen powers and enhancements decrease the time per tick. Of course we'll need a few test to verify it.

[/ QUOTE ]
Please re-read my post. The time to go from 0 to 105 with the Atlas Medallion was less than the time to go from 0 to 100 without it.

I have finished testing Stamina and Quick Recovery.

Unenhanced Stamina recovers endurance in 48 seconds which is 125EPM, 25EPM over base. Converted to EPS it is .41667 which agrees with Vennom's .42EPS.

Unenhanced QR recovers end in 45 seconds which is 133.3EPM, 33.3EPM over base. Converted to EPS it is .55556EPS which also agrees with Vennom's .56EPS.

I also did a quick acid test with a character that has both Stamina and QR which gave the expected +58.3EPM over base.

It would appear Vennom's regen values are correct. =)

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.

I don't have a character with the Atlas Medallion and without stamina but I would expect to see a 110.25EPM recovery rate in that case. This makes the Atlas Medallion more powerful than I originally thought (and I already thought it was cool ).

Test was down when I went to logon. So I played my emp defender to 32 instead ;P. Just now I ran base regen and confirmed 100EPM. Tommorrow night I will test Stamina and QR.

As a side note, Adrenaline Boost has a duration of 1:30 and a base recharge of 5:00. =)

[ 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...

A temporary workaround is to clear the history for that window. The gap at the bottom expands as the history grows larger.

Another bug I've seen with the chat is that if you type a long enough line to approach the end of the chat bar (or edge of the bug window) all the text will jump to the right putting some of the text and your cursor out of sight. Typing one more character will cause all the text to jump back to the left where it should be. When entering a bug report this makes the whole paragraph jump back and forth everytime you near the end of a line.

I discovered something very obscure that I hadn't read in the forum. I wasn't sure where to post it but this thread can always use some attention.

Binding nop or $$ to a key does not clear the bind. It is a bind of its own. I had never bound anything to shift+w but I have other shift binds. When holding shift, w would function normally, i.e. shift+w was the same as w.

While doing a quick and dirty test of something I bound shift+w. When done I bound shift+w nop. Now shift+w was a dead key combo, if I had shift held down w would no longer function at all. Same for shift+w "$$". The game remembers a nop or $$ instead of clearing the bind.

There was a momentary mental DOH before I remembered the reset binds button in options which does clear the binds. Then I just loaded up my normal binds and all was well again.

At one point during my various testing I was looking at binds using /bindlist. I noticed at the beginning of the output it said something to the effect of yada yada trickle yada off.

Is there some kind of setting that will specify whether or not key combos bound to nop or $$ allow the individual keys to function? Could be useful on occasion.

[ QUOTE ]
How about a Combat Jump/Super Jump Bind as well?

[/ QUOTE ]
You could use these binds if you like. They are based on Ahz' binds but for CJ/SJ. Sprint is always 'on demand' and tilde toggles between CJ and SJ. Shift-tilde resets the sprint binds although I find they rarely get out of sync. Extract to C:\cohbinds\ and type in game "/bind_load_file c:\cohbinds\sjinit.txt" then hit tilde to get them up and running.

http://members.gtw.net/~gamers/sprint_SJ-CJ.zip

ahzurdan, I played with your binds last night and love them! I'm really thrilled by your brilliant axis concept.

I think I found another minor error. In both followfly files take a look at the F bind. I forgot to test toggling flight while following.

I found another quirk with CoH in that ++forward and autorun 0/1 don't always interact properly. If I set autorun 1 then ++forward would not turn it off. o.O This is not a problem in your files but I use autorun 1 in my launch bind and wanted to keep it that way so I replaced all ++forward in your files with autorun 0/1 and it worked fine. I prefer to launch for travel by just looking up and hitting one button putting me into autoflyz. Thought I'd mention this for anyone else trying to mix autorun 0/1 binds in with ahzurdan's binds.

Thanks again for coming up with a solution using a manageable number of files. The set works great and is easy to modify due to the reasonable number of files.

ahzurdan, thank you very much for the bind expamples. I've incorporated the functionality into my bindset and will finally get to try them out tonight.

Wasabi_Joe, thank you for the -follow tip.

Blue_Volt, click the options button on the top of the chat box. You can set each type of message to top, bottom, or none.

Oaken_Filipino, ahzurdan included automagic support for super speed. If you don't have super speed sprint gets used instead.

Thank you for the clarifications, ahzurdan. There was another thing I forgot to ask earlier. When reading your files it seemed that they assume +forward to have an inherent autorun 0 and not +backward. I thought it was the opposite. +forward does not turn off autorun while +backward does.

For instance autorunz has s toggle autorun while w does not but in both cases you are transferred to normal run files. In my current binds I added autorun 0 to my w bind.

In gaming I've run across the idiosyncrasy that autorun does not turn off follow. This caught me twice last night. I tried adding follow 0 to my autorun bind but it did not work. Obviously I don't want an indiscriminate follow toggle in my autorun.

In your followrun R toggles autorun and loads autorunz, but follow is still on at this point. Of course hitting a or d will break follow but do you know a way of specifically setting follow to off within a bind?

Otherwise the files match my expectations; +right/+left break follow but not autorun etc..

ahzurdan, I was looking through your bind files and a couple things confused me.

In followflyyz and followrunyz if you hit R for autorun you are transferred to autorunz instead of autorunyz. But at this point aren't you holding space or lshift? So when you release space or lshift you will be transferred to autorunyz. That seems backwards. Can you explain what I'm missing?

I also noticed that in nofly when you press a movement key fly is turned on but hover does not seem to be turned off. Conversely when releasing the movement key hover is turned on but fly is not turned off. Does turning one on automatically turn the other off? I rerolled so I'm stuck without flight atm and can't check (and don't have access to CoH at work anyway ). The binds I used before turned both on/off and I never thought to check if that was necessary.

Regarding the tap jump, couldn't the binds just be altered to omit y axis in the run set? It doesn't seem like sprint would need to be explicitly turned on for jumping since if moving forward you would already be sprinting etc.. For instance in flyxyz F would transfer you to runxz. Haven't fully thought that through but perhaps it's workable.