Combat Feedback for Update 5.

[Pfold]

Well, they've 'fixed' the lag a few times before and I'm sure plenty of times before I started playing yet it is still here.

I can't understand how other games can run seamlessly (no lag) with just as many things going on if not more and turbine seemingly can't figure it out. Is it a mystery of the universe that I'll only understand when I die? Probably lol

I'll be the first to admit that I'm no programmer but I'm no automotive engineer either and I know when car is tuned and working properly.

Someone made mention of the fact that software > hardware. Why multiple instances of the marketplace etc? Is the script that botched that it's the only way their servers can handle the load? I'm not being facetious, I'm asking seriously. If that's the case then it seems the whole game needs retooling not just the combat system or twf.

[Cetus]

Well...supposedly there are tooo many TWF'ers.....I personally love playing my Greataxe fighter as much as my Dual rapier ranger....so I really don't know what the deal is.

I know a lot of flavor of the month tempest/monk splashes will need to change more than 3 levels of class to probably be viable after the nerf....but I won't go there......I just got back some of the rep I lost

And that makes my point, THF'ers are not complaining that their dps is so low in the eyes of TWF, quite the contrary in some cases. I feel that this feature should be a PURELY lag based effect, and the DPS should be UNTOUCHED in both departments.

I'd rather have the developers surprise us with a wider weapon choice in terms of future epic-ifications for TWF'ers to seek after something as THF'ers do for the ESOS. That, I believe would be a funner and less aggressive approach to work on any existing dps gaps between the two styles.

[vVAnjilaVv]

And that makes my point, THF'ers are not complaining that their dps is so low in the eyes of TWF, quite the contrary in some cases. I feel that this feature should be a PURELY lag based effect, and the DPS should be UNTOUCHED in both departments.

I'd rather have the developers surprise us with a wider weapon choice in terms of future epic-ifications for TWF'ers to seek after something as THF'ers do for the ESOS. That, I believe would be a funner and less aggressive approach to work on any existing dps gaps between the two styles.

IDK...I won't go too far into another tinfoil hat theory...but part of this reeks to me of WB wanting a more streamlined version to get more mainstream MMO players in the game.

As much as this game has been "dumbed down", it is still more complex than a lot of people can handle, they may want to remodel into something people can grasp in a matter of weeks or a couple months instead of years.

I've been playing this game for 3+ years and there are still times when I find out something new or I didn't realize before and just think to myself...."what a noob".....while some people may find this good, I am sure it frustrates many and scares off a lot of potential customers.

One of the biggest complexities in this game is building a character properly, if they can make Pure Classes more appealing to play it will be less complicated as well, this nerf goes a long way to persuade people to not multi-class anymore

[Cetus]

IDK...I won't go too far into another tinfoil hat theory...but part of this reeks to me of WB wanting a more streamlined version to get more mainstream MMO players in the game.

As much as this game has been "dumbed down", it is still more complex than a lot of people can handle, they may want to remodel into something people can grasp in a matter of weeks or a couple months instead of years.

And I'm afraid this remodeling era will take place at the expense of veterans who are denting their keyboards in trying to make their voice heard on behalf of these changes.

I just think its too aggressive and creating a huge "holy sh*t factor" amongst the devoted playerbase. Mainstream MMO players don't give a squat about the mechanics behind most aspects of this game like we do. Becomes a quality vs quantity war (when money is involved, quality is given two squirts a pop).

[FluffyCalico]

this nerf goes a long way to persuade people to not multi-class anymore

How does nerfing the Capstone for Kensai help persuade them to not multiclass?

If fact it encourages them to multi-class.

[Pfold]

We could make it easy on them. We could just connect via dialup so that their hardware could keep up. =)

[Meetch1972]

One of the traditional methods for speeding up random number generation is pre-generation.

Say mapping 5 x 1d6 to 5d6 pre-generated random number.

Let's expand this one step further for the DPS lag issue. Considering how much memory it takes to store these things it may prove to be an option?? It's an old concept, one I resorted to once on a system that only needed ballpark accuracy, but needed to do some interesting trigonometric calculations and didn't have decimal point arithmetic available to it. Doing the full math was beyond question due to limited CPU cycles available. In the case of applying it to random number generation I don't see how it would alter the end result.

If the internal random number generator is really doing random(6) + random(6) + random(6) for 3d6, you could possibly use... *drum roll* a bunch of lookup tables! If you want a statistically equivalent method to simulate Xd6 (up to 5x or 6x, this will work) Simple mechanism: 1d6 is straightforward. 2d6 would use a lookup table with 36 combination (2,3,3,4,4,4,5,5,5,5,6,6,6,6,6,7,7,7,7,7,7,8,8,8,8 ,8,9,9,9,9,10,10,10,10,11,11,12) (or 1+1,1+2,2+1,1+3,2+2,3+1 etc).

Then access that lookup table with a single random(36) index on it - this time I "rolled a 3", which causes a lookup on the third element in the array, or that second three. Would it be faster? That's up to the developers and the pre-existing behind-the-scenes code. The array would grow to 216 elements for 3d6, over 1296 for 4d6, an array of a whole 7776 bytes for 5d6 and so on. But as I understand a single random lookup of arbitrary size indexing a static array could be far more efficient than 2 or more random(6) operations. You'll get the statistical equivalence with a single random() call. Of course you'll need to allow for all the major combos, but if you limited to 5d6 then statistically adding a pair of 5d6 lookups would do the trick and give statistically equivalent results. Does this make sense? Plus some d4, d8, d10, d12, and maybe even d20 multiples as appropriate could all take the load off the random number generator.

Of course, I don't even know what platforms DDO runs on (but I don't have to care, do I!) Can I have a gold star for nerdiness now please?

[Meetch1972]

If the internal random number generator is really doing random(6) + random(6) + random(6) for 3d6, you could possibly use... *drum roll* a bunch of lookup tables! If you want a statistically equivalent method to simulate Xd6 (up to 5x or 6x, this will work) Simple mechanism: 1d6 is straightforward. 2d6 would use a lookup table with 36 combination (2,3,3,4,4,4,5,5,5,5,6,6,6,6,6,7,7,7,7,7,7,8,8,8,8 ,8,9,9,9,9,10,10,10,10,11,11,12) (or 1+1,1+2,2+1,1+3,2+2,3+1 etc).

Then access that lookup table with a single random(36) index on it - this time I "rolled a 3", which causes a lookup on the third element in the array, or that second three. Would it be faster? That's up to the developers and the pre-existing behind-the-scenes code. The array would grow to 216 elements for 3d6, over 1296 for 4d6, an array of a whole 7776 bytes for 5d6 and so on. But as I understand a single random lookup of arbitrary size indexing a static array could be far more efficient than 2 or more random(6) operations. You'll get the statistical equivalence with a single random() call. Of course you'll need to allow for all the major combos, but if you limited to 5d6 then statistically adding a pair of 5d6 lookups would do the trick and give statistically equivalent results. Does this make sense? Plus some d4, d8, d10, d12, and maybe even d20 multiples as appropriate could all take the load off the random number generator.

Yes I know, quoting myself here - it's a sin etc, but I got to thinking how this could be expanded to rolling to-hit for both the primary and off-hand. Simple: "roll" a d20*20 - or a d400. Then work with mod(20) for the primary hand and /20 for the off-hand or such. Display both numbers, with 1 calculation. Statistically equivalent, with half the randomised function calls.

Again, apologies for being myself!

[FluffyCalico]

Simple: "roll" a d20*20 - or a d400. ... Statistically equivalent, with half the randomised function calls.

Again, apologies for being myself!

20d20 is NOT 1d400 not even close. 2d6 is not 1d12. In fact 2d6 is what 1d12 upgrades to in some cases!

IE 20d20 average roll is 210. 1d400 average roll is 200.5 Please explain how an average of 210 and average of 200.5 are statistically the same?

[Razcar]

because presumably Eladrin has thought that twf has been out of balance (as evidenced by the large number of twf builds in the game - remember eSoS is an anomaly so cannot be used as evidence that thf doesn't need a relative buff), and Eladrin thought that if he's going to go to the effort to recode the off hand combat mechanics to reduce lag, he might as well also examine the power of two weapon fighting and try to rebalance to match the information he presumably has available to him (more than we do).

Thatr's cool. If he will "examine" the gains of TWF, he should of course examine the costs as well.

After this nerf I expect that for every one-handed GS weapon you craft, you get another for free. Make TWF have the same ability pre-requisite as THF = none. Make kopesh a martial weapon. And make TWF give no minus to hit. Since he wants them to have the same DPS, they should have the same costs. Then it will only be cosmetic.

Or how about this, make THF much cheaper than TWF but grant higher DPS against multiple opponents and lower against a single target. Oh, that is how it is working now. My bad.

[Natashaelle]

Let's expand this one step further for the DPS lag issue. Considering how much memory it takes to store these things it may prove to be an option?? It's an old concept, one I resorted to once on a system that only needed ballpark accuracy, but needed to do some interesting trigonometric calculations and didn't have decimal point arithmetic available to it. Doing the full math was beyond question due to limited CPU cycles available. In the case of applying it to random number generation I don't see how it would alter the end result.

If the internal random number generator is really doing random(6) + random(6) + random(6) for 3d6, you could possibly use... *drum roll* a bunch of lookup tables! If you want a statistically equivalent method to simulate Xd6 (up to 5x or 6x, this will work) Simple mechanism: 1d6 is straightforward. 2d6 would use a lookup table with 36 combination (2,3,3,4,4,4,5,5,5,5,6,6,6,6,6,7,7,7,7,7,7,8,8,8,8 ,8,9,9,9,9,10,10,10,10,11,11,12) (or 1+1,1+2,2+1,1+3,2+2,3+1 etc).

The DPS lag is not, as far as I can see, being caused by arithmetics functions misbehaving (these are extremely simple operations btw), but by internet networking issues where all the computers involved in managing a game instance find themselves unable to despatch all the data quickly enough to all of the rigs in the network.

[Razcar]

But just because the power of rogues is being reduced now because of this change doesn't mean that they might not be buffed in the future. Of course if the form of that buff is through epic traps of some kind, not every player will like that kind of gameplay.

I'm sorry, but that is complete hogwash. Rogues should take getting this nerf hitting them the worst of all classes with a smile and a "hope we can get something down the road"? We should not be playing our rogues for a couple of years until the devs get around to throwing us a bone, that's what you are saying. What a complete and utter lack of empathy. Are you not aware of how long time game changes in DDO takes? We still have less than half of the PrE's for crying out loud.

[Amberyll]

Forget about PnP when it comes to attack sequence in DDO. We don't have rounds here. You do four attacks in a cycle before you start the animation again. When you use TWF, you add off-hand "hooks" that are not visible in the animation.

With GTWF you add a total of four hooks to the four animated attacks in the chain. With Tempest III you add a total of five hooks. So in an animation sequence on your character you would do four visible animations, but nine actual attacks.

I was not following the animations, I was following any hit or miss text, for several minutes. I did not see 9, but did see 7 per cycle.

[Razcar]

I was not following the animations, I was following any hit or miss text, for several minutes. I did not see 9, but did see 7 per cycle.

Go to Ataraxia's Haven, find a Scrag (blue trolls). Take it down to 0 HP with a weapon without fire or acid. Do something non-attacky like cast a barkskin, so you get a start point in your combat log. Then you can hit the Scrag four times and count the attacks in your combat log. The Scrag won't die.

How I described it in my first answer to you is how it works. Or worked up to Update 5 to be exact.

[argentstar]

This feels like Dungeon Alert all over again.

Why is it that dps lag seems to be worse on some days than others? Could it be that server load is as much an issue as is the number of attacks?

Maybe invest in hardware rather than butcher the combat system?

At the very least address one issue at a time. Do not couple performance adjustments with balancing TWF.

Bravo! Well said.

From my experience, it has always been the load on the servers that causes lag. Why not increase the number of servers? Yes, this would mean a fairly large financial investment, but so will the man power to implement this change (and the other inevitable changes that will have to be implemented to correct the original implementation problems ... yes, those problems always show up ... always) and it has always been and always will be a fact that, over the long run, capitol investment is always cheaper than human resources costs. From a purely business standpoint, this idea makes much more sense.

[Meetch1972]

20d20 is NOT 1d400 not even close. 2d6 is not 1d12. In fact 2d6 is what 1d12 upgrades to in some cases!

IE 20d20 average roll is 210. 1d400 average roll is 200.5 Please explain how an average of 210 and average of 200.5 are statistically the same?

I never said it was a d400 or a 20d20, I said using a single random(400) call you could get 2 independent d20 rolls.

Divide the result by 20 to get the first d20 roll, and perform a modulus 20 to get the second result. Please read wot I said carefully. Heck, you could cache a bunch of d20 rolls by performing a series of 20^n random calls and effectively get n d20 rolls through proper application of modulus and recursed division calls. Don't want to go above 2-byte integer? You can go as high as 32 million -> 20^5 = 3.2 million, which is nothing for an integer - 20^6 is too high (maybe). Then you get 5 d20 results:
1. Get mod(20) of the number - and you'll need to add 1 because the mod will return 0-19 -> there's your first d20.
2. Divide the number by 20, truncating any remainder.
3. Repeat up to 4 more times before fetching another random(3.2 million).

The "miracle" of 5 d20 rolls in a row is still 1 in 3.2 million, as is the absolute failure of 5 1's in a row.

If that random(3.2 million) was 0, you'd get 1, 1, 1, 1, 1 - if it was 1-19, you'd get 2-20, 1, 1, 1, 1 - if it was 20 you'd get 1, 2, 1, 1, 1 and so on.

If I wanted to perform a 20d20, I'd perform four 5d20 "fetches" - which could use the above, or a bigger lookup version of the table I described previously and below.

It just requires a caching mechanism. Not all that hard for an experienced coder to manage.

On the flip-side, if you translate a random(36) to a lookup table with appropriately weighted values as I originally outlined (remember, 2,3,3,4,4,4,5,5,5,5 etc?), you will get the same statistical result (the average is 7, there is a 1 in 36 chance of getting a 2 or a 12 out of it, etc). There are 36 combinations, and the array that random call would refer to would contain the same distribution of all the end results. It's a simple concept when you think about it... or again you could fetch a random(6^n). Populating a set of arrays to suit that is generally a trifling matter: for index1 in 1..20 { for index2 in 1..20 { for index3 in 1..20 ... array[n++]=index1+index2*20+index3*400 }}} . That'll populate yer 8000 element array.

Ciao!

[Meetch1972]

Bravo! Well said.

From my experience, it has always been the load on the servers that causes lag. Why not increase the number of servers? Yes, this would mean a fairly large financial investment, but so will the man power to implement this change (and the other inevitable changes that will have to be implemented to correct the original implementation problems ... yes, those problems always show up ... always) and it has always been and always will be a fact that, over the long run, capitol investment is always cheaper than human resources costs. From a purely business standpoint, this idea makes much more sense.

This is my main concern - the hardware resources should not have to suffer from the complexity of the system, but if at all possible the system should not have to change because of a hardware resource issue. The balance as it stands has long been accepted by many, and cutting one to make the other happy is something I would expect to be avoided at all costs. Only the devs will know how many avenues have been explored, but I can't help but feel that something's been overlooked despite best efforts? Can devices like Cisco's WAAS help? (There are others, but I know them not). For unencrypted traffic they can offer significant amounts of time-saving, wire-speed, on-the-wire compression to farther out points, but then the infrastructure must be out there a bit closer to the clients. Again, I have no idea what's already being used, but I know that network "de-duplication" technologies do work against congestion problems to a point. More boxen would probably help too, of course.

[Brannigan]

its not an excuse, the change is a fix to lag and a nerf
tolero even said that they find twf overpowered and need to balance it

He also said ESOS is overpowered, but there not doing anything about that, also this nerf puts THF infront of TWF on dps not to mention the number of feats you dont need to sacrifice for THF or stat dump in Dex, someone in Turbine loves thier THF barb if you ask me, it's a nerf and not even a balanced attempt to level it with THF in either feats needed or dps.

On top of that they would have to introduce STWF (which without really hampers TWF and it's not certain it's coming), and even then it will cost an extra feat to be able to get 100 /100 (main and off hand) and the extra stat dump into Dex.

One thing for certain is it srews rogues totally and alot of other builds, more than any previous nerf, which means more people will be respeccing / re grinding, purchasing more Greater and True hearts oh and probably the alignment items that are coming to move away from certain builds.

That is exactly what Turbine want players doing as it brings in more revenue on a rotation, and dont tell me they haven't considered that $ side of the impact this nerf will have.

And as for us poor EU players that dont even have the shop it's a re-grind again, made worse by the low population for grouping and unless your with an established group or guild being able to Epic quest grind.

This is a nerf that still wont balance combat and imo is aimed to hit the largest group of character builds squarely in the pocket and force them to spend more money in the shop.

Poor move Turbine for the players, but good for your bank account.

[vVAnjilaVv]

How does nerfing the Capstone for Kensai help persuade them to not multiclass?

If fact it encourages them to multi-class.

Actually I was more referring to the hit many multi-class TWF builds are going to take.

[Therilith]

What would be the problem with implementing the doublestrike feature for TWF'ers exclusively and adding extra perks or percentages to bring the dps back up to an unchanged level. That way the dps is unchanged, the physical detection is as if they were a two hander, and THF'ers remain untouched.

The fact that it wouldn't nerf TWFers, which is sort of the point of this change?

Noone ever complained about TWF being overpowered

Eladrin did.
It's in the OP, which I assume you've read.