Mobs miss more than they should

[James76]

Yes UseIntervalValue is already set to true. This is happening with all mobs in pop. Going to try some luclin and norrath....

Ok went to ssratemple, still wearing NO GEAR, the mob would only hit once in 4-10 attacks.

So you are suggesting most or all mobs in the database have a low attack rating or accuracy? Lets have a look at the database values. Looks like all the mobs I've looked at have ATK and Accuracy equal to 0. Aggregating the database, every single mob has an ATK and Accuracy of 0. Looks like this is a PEQ problem. Anybody want to try this query on their database?

SELECT zone, max(ATK), max(Accuracy)
FROM npc_types AS nt
INNER JOIN spawnentry as se ON se.npcid=nt.id
INNER JOIN spawn2 AS s2 ON s2.spawngroupid=se.spawngroupid
GROUP BY zone;

I am going to try making changes globally to see if the server actually uses that data.

[James76]

ok I changed all of them to 1000,100 (ATK and Accuracy, respectively)... no effect.

Trying 2000,2000... marginal gain, maybe 50% miss rate with no gear..

Trying 5000,5000... starting to look like a real fight.. But with gear, its back to miss miss miss miss miss hit...

So it does appear to change with database modification. Looking through the code, only Accuracy appears to modify whether or not the npc hits.

I'll post the issue with peq.

There is still the riposte problem, which is part of the AvoidDamage section of combat. Riposte should be part of Attack method, and occur before we know whether or not it MAY hit, or even before you know how much damage may hit.. At this point, only if damage is above zero, THEN only if it hits, is there the chance of the riposte.. And if the chance is 10000%, as in the case of discipline, it should be riposting on every attack. Maybe AvoidDamage should happen before the GetWeaponDamage call.

Gonna analyze the code and think about the bigger picture for a while..

[trevius]

The combat system has gone through alot of changes in the past year. The accuracy and attack rating fields are both pretty new to the emulator, so PEQ didn't have them added. I think there is a default value that is set if they are set to 0 and 0. So, but setting them to something like 10 and 10 would actually make them hit less often and for less damage. These can be tuned, but I find that I have to do them on a zone by zone basis and test out how hard I want them to be for each zone I do. For raid mobs, I might use 2500AR and 300 Accuracy or so. Keep in mind that you will be missed due to parry and dodge even naked. So, your skill values play a part in this as well.

I do think that the database needs a big overhaul on these stats, but I don't think it is an easy job. I also imagine that it shouldn't be done until the combat system is considered to be very complete. Otherwise, changes would have to be made to the entire database everytime some new setting was changed or created.

[ChaosSlayer]

umm Trev, why does setting ATK and AR to 10 (which greater than 0) would cause mobs to have WORSE dps?

is that cuase it uses 10 ISNTEAD of default calculated value, rather than +10 to default value?

[trevius]

Yes, just like setting min/max damage from 0 to 10 on a level 70 mob will make them hit for much less. Certain fields use either averages in the database, or preset defaults for their level in the source. Something like that anyway.

[cavedude]

Yep, when KLS implemented Atk and Accuracy, I asked if leaving them set to 0 would effect DPS, and the answer was no. Both are calculated by the attack code already, you just couldn't edit them in the DB. Log parsing confirmed this. With that in mind, it's completely possible that setting a low value for each will lower the output, and not add a bonus to it. (You would be overwriting the value calculated by the server, not adding to it)

It does bother me that both fields are 0, but I haven't updated them for two main reasons. One, as mentioned above, I'd like to see the combat code stabilize first (in that I'm told, OK I'm done tweaking go ahead and update the DB) Also, based on feedback from the players on TGC and logs I've parsed, I'm not convinced it's a huge issue. The DPS for the most part is in line with the DPS at this era in EQ's history (PoP/LoY)

[ChaosSlayer]

well guys there is a TINY problem with this.
since an average DB user has NO IDEA what is default ATK and AR of any given npc is, using those fields in DB as substitute is esentily shooting in the dark.
Esentialy if i want to alter any npc atk or ar i have to sit down and first calculate these default values for any npc to be altered, to figure out what to put into those fields to ahcive my goal - which is kidn of counter productive.

Can we ask KLS to re-code this implementation so values placed into ATk and AR fields are ADDED to the npc DEFAULT values calculated based on his level/class/stats? This would be much more reasonable, cuase basing on npc default performace we can then tune him up or down (+ or -) wihout actualy needing to figure what his defaull values are

Otherwise I can spend whole day seting NPC to 10,100, 500, 750, and not seeing any improvement cuase his default performance is apparently 27k or something...

would not you agree its a better way to implement this feature?

[James76]

I executed a

 UPDATE npc_types SET ATK=level*100, Accuracy=level*150

and it seems to be much more true to the game. Some mobs like Bertoxxulous still seem easy but at least they are hitting more often.. And the game isn't nearly so soloable anymore. Finally they can hit a naked me. And if I were dodging or whatever, it would say that in combat. It wouldn't say MISS MISS MISS MISS MISS MISS MISS....

As for the combat code, I looked through it to find an easy solution for the riposte problem (ripostes should happen on the attack, not on the hit) and I noticed reused variables, some genius thought it was smart to use the damage variable as a way to control combat, by setting it to specific values to indicate no hit, or a riposte, etc. This is the mark of the amateur developer. Also the redundancy between Client combat and Mob combat, considering inheritance should simplify things (Client inherits from Mob). Maybe they had a problem finding a way to call the parents method.. the easiet way is, for example from within Client::AvoidDamage() is to outright call Mob::AvoidDamage() and then anything specific to the Client can be handled. Or call it at the end. If its written in a way that prevents that from working, then it isn't following OOP rules and is poorly written.