Koopak

If the devs could find a way to implement these changes in a timely fashion for testing, even in a hacky way, id be happy to dive into the the test server and really try to see how it works, my biggest concern currently though is definitely the development time, we have to consider the best places to use limited resources, even more so than a studio would have to.

My 2 cents are largly added now, the main point just being how messing with global parameters can have significant shifts, because again this was a very controled environment, its hard to predict what else this would effect, such as the minimum dps needed to defeat certain AVs. To everyone else replying. I get that is is a touchy discussion and one that often veers toward the combative in nature, but please, if you have something to add make it constructive, atleast propose a reason for your views.

I believe i didn't make my point clear so to use your example (thank you for providing in game data, i don't have access to currently) at base 35.8 health divided by 9.42 damage is 3.8 casts, however you cant cast .8 of an aquad bolt, so we must round up to 4 Aqua bolt, as you said does 9.42 damage to this enemy, it has a recharge time of 3 seconds and a cast time of 1 second. We can thus express it in the following way. Cast time x number of hits needed + recharge time x number of hits needed minus 1 (1 x 4) + (3 x 3) = 13 seconds Now with your proposed changes, 39hp divided by 9.42 damage is 4.14 casts but again we must round up, thus 5 attacks. Your new recharge time is 2.58 seconds thus we get. (1 x 5) + (2.58 x 4) = 15.31 seconds quick comparison shows that's a 15% increase in the TTK time Obviously much less than my example where i pulled numbers out of thin air, but still significant

I'm currently not able to go through all the replies here, so I apologies if I'm echoing someone who said it first. I agree that hasten is to common, worse yet is how hard you have to stretch many builds to even come close to justifying dropping it, however these solutions are problematic. There is a reason why fitness was made inherent. I can get behind your second option, basically making hasten less powerful but double stackable to achieve the same effect as now while allow for lower investment versions for other build, but your current 3rd option suffers from several issues. First is time to implement, while the changes you suggest are minor, the implementation of them would be time consuming, while i don't have a firm knowledge of the game's underlying structure I suspect that many values are not simply available in a database you could run a script on, thus in at least some, if not most cases, these small tweaks to enemy health and player ability recharge rates would need to be done by hand, given the number of powers and enemy values in the game, this would be a tedious task at best, and a monumental one at worst. This isn't including the time spent ironing out mistakes and bugs this could implement. Second, while I appreciate your mathematical breakdown of your changes it doesn't cover a wide list of cases where this change would be very disruptive. Your focus on TTK/TTD is unfortunately to reductive. Firstly there is how regeneration works in relation to health, regeneration would need to be tweaked as well in this change because a 9% increase in health is also a 9% increase in regeneration rate as regen is a % of max per second. This becomes especially bad at lvl 35+ as your proposed 30% would drastically improve the durability of many AVs and make many builds unable to solo them when previously they could, even without hasten. This is so drastic a shift that even EBs may become to hard to kill for lower damage classes. This is a problem as a core design tennate of CoH it to make it solo friendly. Another place this health boost becomes an issue is in the TTK itself. While taking your targets health and dividing it by your DPS to them is a quick and dirty method, a more accurate method is to take their health, divide it by the number of attacks you have to use, then add up those attacks cast and recharge times. (this is omitting the additional factor of how much they will regen over the course of the fight) Damage comes in waves, and if previously 5 attacks would kill a mob but only just, a 9% health increase will make it 6 attacks, that is not a 9% increase in time, its a 20% increase. So lets try a hypothetical power with a 1 second cast time and a 5 second recharge time, we will stay at say level 4ish and this is your only attack because admittedly more attacks will smooth this out. The attack does 10 damage and your enemy had 50 health. Normally this would take 5 casts, so ( 1 + 5 + 1 + 5 + 1 + 5 + 1 = 19 second TTK ) Under your changes the values become (roughly since i dont have the recharge formula at hand) 4.3 recharge and health of 54.5 (tenths place HP is tracked) This results in 6 casts so ( 1 + 4.3 + 1 + 4.3 + 1 + 4.3 + 1 + 4.3 + 1 + 4.3 + 1 = 27.5 second TTK ) This is a 31% increase in actual TTK, at low levels this could easily cost a blaster or other squishy AT their life. Obviously im cherry picking a situation here, but the point is to show how changes to global values like this can have huge ramifications, this is why it has to be approached very carefully since any cure the the woes i just outlined while keeping your proposed changes will require exponentially more work and effort in rebalancing the game.

If you recall we worked on that in help chat together and it unfortunately did not work for me despite working just fine for you. The $$ the chat bubble tags to not be added to the chat box and to not be processed so while the bind behaves correctly up until i submit the message, the bubble ends up being defaulted. /showbind does show the full command bound correctly, so I can only assume this is another bug in the command processing.

Ran into this issue myself and with the help of my SG mate and a helpful person in help chat i managed to determine some more details about it. The issue is caused by the "<>" characters specifically used in chat bubble color commands like "<bgcolor red>" The behavior is that the bind works as normal, for instance the bind (/bind enter "beginchat <bgcolor red>") will result in <bgcolor red> appearing in the chat box, but here is where it derails. The chat text field remains highlighted as per normal when composing a message, however the cursor is missing and any text entered is buffered but ignored. After clicking into the text field or pressing the arrow keys the cursor will appear and begin to traverse the field normally, when you start to type any text how ever, and text buffered in the previous step will be immediately spat into the text field at the cursor location. Again we narrowed down the offending component to the html tags "<>" as any other beginchat bind or macro works fine. And the issues immediatly flare up when one of them is introduced. I have also confirmed 3 separate people with the same issue, and 3 separate people who do not experience it. I partly ruled out OS issues as im on win 7 and one of the other having the issue is on win 10 I've attempted a re-verification and resetting all settings and binds to default, and may try a reinstall later. If you need ANY assistance in gaining more debug info feel free to contact me in game, or on my Discord handle Koopak #4153 Edit: For clarity, thanks PaxArcana