Combat Fixes

[James76]

I am resolved to fix combat, I hope everyone can accept these changes. I started by making the code more readable, by simply adding extra lines here and there so that the curly braces weren't compacting the code so much. Then I fixed all the signed/unsigned comparison warnings, then all the type conversions (int to float comparisons) using static_cast where applicable. Now there are no compile warnings. I replaced any "x++" with "++x" for example, because its actually faster and you only need the post-increment on something like "myarray[x++]" which increments x after reading from the array, or "myarray[++x]" which increments x before reading from the array. Its faster because the post-increment has to push the value to return on the stack before incrementing.

Also, I found some bugs in bonus damage where it essentially gets trimmed because of type conversions, as well as a huge bug in bonus damage (for example, monks get +20% damage output) but it wasn't applying correctly.. essentially because of faulty math. These things jump out at me, and had to be addressed. There was a problem with item damageshields not applying to combat unless you also had a spell damageshield on, which is now fixed. I am still working at getting the ripostes working per attack gracefully, I fixed it a few different ways but I'm not happy, I want proper messaging too. Also I'm going to get monk FD working properly since its in the same file, I had a look at it and it seems proper but obviously its not working.

This list of fixes will have to replace the entire ./zone/attack.cpp file, I've made too many adjustments to list as it is.

Expect future posts shortly... I'll eventually provide a link to the new file, with which you can do a diff or use whatever comb you like. I won't post it until I've tested it to my satisfaction, and I'm sure you'll all be happy with my testing.

[AndMetal]

First of all, I want to say that it's awesome that you're taking on this large of a task. Imo, the attack code is nowhere near Live, but I personally think a lot of this has to do with random number generation. Live is random, but like you would think it should be. Emu seems to get randomly generated numbers close to each other, but still in waves (damn computers...) The best example I can show, which may just be a general issue in the code, is when lower level stuff can hit you, if it does hit you, they will hit near max damage almost every time, where on Live, if it does hit you, it will be for crap.

In any case, good luck working out the kinks

[James76]

Err, correction, FD isn't in attack.cpp, but I'll fix it anyway.

[trevius]

Sounds great, James76! I am excited to test some of this out. And I am sure the monks will be happy to hear FD is fixed!

[James76]

OK, I set FD so that it works all the time, temporarily, and the guy I tested it with is 65 vs poi common mobs.. It does work; the mob, if you let it get far enough away from you, will forget about you.. Seems to be at 60% chance, plus another variable, could be if there are 35 or more levels between you and it... Going to have to dig a little deeper... then I thought I would try a weapon that would be common for a 50-65 monk, a tarnished driveshaft... and he couldn't use it! So... for PEQ cavedude...

update items set classes=classes | 64 where id=24791;

Now he can use it. What a stab at an item he couldnt use... I am absolutely positive monks can use that, I remember with clarity way back in the day in Karnor's a guildy showing off his driveshaft... Ignore the pun...

OK, omw..

[James76]

OK I'm drunk, and so is the code apparently... I had disabled the level check if the mob is 35+, and the chance NOT to have it add to Feign Memory.. Which is when the mob should still remember you. But it forgets. Maybe its backwards, which doesn't make sense. Once I had a ton of mobs without changing code and it did work, in poi (my choice zone for testing because of quick access to mobs).. But only once. Now it works all the time but they should be remembering you all the time. I'm gonna work on this before I post again..

So I set it so it always adds you to feign memory, and it always remembers, I guess that makes sense. 60% chance of remembering you, you could FD 10 times and it will still remember you. But it does work. I read that it should be 70% chance of forgetting, not 60% chance of remembering... Changing to 30% chance of remembering and testing...

Looks like its working. That mob forgot about me, twice. I would recommend changing ./zone/entity.cpp line 2715ish, <=60 to <=30. Maybe somebody wants this pushed to server rules? But it works, I only changed the % chance of remembering.

OK on to riposte.. and final post with link to attack.cpp....

[trevius]

All items are pulled directly from what 13th floor gathers from collects. According to Allas, the item you are talking about isn't monk usable:

http://everquest.allakhazam.com/db/item.html?item=16999

[paaco]

I think he may be correct about it being Monk useable at some point though. Seems like I remember a monk that had one on my server also. I haven't played live in w very long time though so...

[Itchybottom]

Originally Posted by paaco

I think he may be correct about it being Monk useable at some point though. Seems like I remember a monk that had one on my server also. I haven't played live in w very long time though so...

False

[ChaosSlayer]

I remember this item back from my times in PoI.

I do not recall if it ever monk useable and then nerfed or otherwise
but, Looking at its stats, the item does not strike me as soemthing that was "too uber" so monks would had to be removed from list of useable classes (even back them) to prevent disbalance

Logic sugests it prabobly was never monk useable

also note that it only has casters and priest as useable classes: no palys or warriors, or bst or sk - clearly was never ment to be a melee item

[steve]

Originally Posted by James76

There was a problem with item damageshields not applying to combat unless you also had a spell damageshield on, which is now fixed.

I have items on live with a damage shield mod and they do not apply unless you have an actual DS on you. If you do, then the item mod DS stacks on top of the spell. Maybe it was done that way on purpose to emulate Live more accurately?

[James76]

It was in 2001 or 2002 on Tunare. If it was, it was probably before the "Initial Entry" that is listed on LUCY. It was a long time before frogloks were available. It was within the first month of the release of PoP. Maybe now its unusable, but he did have it equipped and I remember we did drool a little.

[James76]

Originally Posted by steve

I have items on live with a damage shield mod and they do not apply unless you have an actual DS on you. If you do, then the item mod DS stacks on top of the spell. Maybe it was done that way on purpose to emulate Live more accurately?

Seems you are correct, I found a post on allakhazam that describes that its a Damage Shield Modifier, intended to augment a spell DS. But this was in 2004.. It just seems like a bug since the item is described as having a damage shield.

No worries, this was a one-liner in the code, the whole file is still getting replaced.

[bleh9]

Originally Posted by James76

I replaced any "x++" with "++x" for example, because its actually faster and you only need the post-increment on something like "myarray[x++]" which increments x after reading from the array, or "myarray[++x]" which increments x before reading from the array. Its faster because the post-increment has to push the value to return on the stack before incrementing.

Maybe I'm missing something, but myarray[x++] isn't the same as myarray[++x]. Also, ++x and x++ often optimized the same.

[James76]

Originally Posted by bleh9

Maybe I'm missing something, but myarray[x++] isn't the same as myarray[++x]. Also, ++x and x++ often compile to the same thing.

I said that you don't need x++ UNLESS you're using it on a line such as "myarray[...]" where it actually matters, where more than one segment is processed before the rest of the statement. I even defined what post-increment and pre-increment means. Why am I defending myself?

And assuming it will compile to the same thing is incorrect, it will only do so if the specific optimization flag is set on the gcc execution. Assuming anything is poor code, its always better to implement as intended.