After talking to John on IRC last night I decided to start planning out a POSSIBLE revamp for our combat system. Our current implementaion of combat seems to have many bugs, there is the issue noted here as well as ones I noticed last night after turning logging on, such as combatants being removed and readded in the middle of a fight, and the encounter lock being reset a dozen or so times during a fight (both of wich may cause our loot bug). I was originally going to make a plan and post it but figured making a post and developing a plan with other devs and the community will be better.

I propose we do away with the combat class altogether and let the combatants control there own actions, in other words the majority of the combat code would be moved to the Entity class. The first thing we would need is a timer with a callback function (not sure if we have that or not). When an entity starts an attack the timer would be set to the current weapons delay and the callback set to the attack function.

The attack function should do all the offensive calculations for the entity, would probably be best to create a struct to hold all the attack data. This attack function should also do all the checks and manage the timer, in the case of the target being out of range (or to close in the case of ranged attacks) the timer should be set to call this function again in half a second or less, in the case of a spell currently being cast a flag should probably be set and the timer stopped, the spell proccess can then check to see if this flag is set when the spell is finished casting and call the attack function again (this would simulate how live works). Once every thing is done and calculated this function should call a take damage function from its target, passing it the attack data struct as its only parameter.

The take damage function should do all the defencive calculations and apply the damage. It should also be the function to control the encounter lock flags and adding attackers to the list of allowed looters.

AttackAllowed should function how it currently does (return true if you can attack) but the funtion itself should be rewritten, for starters the only place a return true should be is at the end of the function so every thing has to be checked for this function to return true.

The attack data struct should hold every thing we would need to know about the attack such as the attacker, the victim, dmg, dmg type, was it a crit, did the weapon proc, and so on.

That is all I got for right now, this first post can be updated as the plan evolves so it is easy to find the current info.

Thank you for taking a look into this, Jabantiz. Lots of areas of our code are either broken *now*, or were rushed together in the early days while we were learning. As you and I discussed, it's not necessarily about wrong way as it is current knowledge of the current development team.

I'm good with any change that makes the server more stable and progressive.

Sorry for my interjection, but here I'm speaking just as a coder in general, if you are indeed going to revamp it, then I may be stating the obvious here, but make sure you comment as much of it as you can, the worst thing for a coder is to come in energetic, then get an uppercut to the face from the code when nothing is commented and the coder can't figure out wth is going on. Just something to keep in mind as I have seen a lot of the code un-commented for the most part, and realistically, with people coming and going, having it un-commented creates a big issue.

There is not one thing stopping anyone else from taking our code and commenting it as they learn it. So far, no one has volunteered for that effort. I have begged for years for help documenting. I have even offered very very entry-level simple coding projects (LogWrite) to help people learn C++ and still, zero interest. Very few have stepped forward and 90% of the Wiki is written by me.

Jab, Scatman is still without internet at home and this site is blocked at work, so he wants to go over this with us via IRC some night. I told him we pop on more frequently than before, so let's try and at least lurk waiting for him to have a moment to hop on.

Generally, he says your ideas sound good, he just has some questions and additional thoughts to offer. And posting to this site from a phone is a pain in the ASS

This is probably just personal prefrence, I was taught (years ago) that if you want a class to do something then it should do it itself, not be controlled by another class. In this case an entity is attacking it should do its attack stuff not be told that it did (I also may be taking this to literally).

If we want to keep combat seprate like it currently is then I think we should scrap what we have and all active devs should redesign it from the ground up making heavy use of the rules system. I suggest this as that way we will know how the system works, or is suppose to work, wich will make it easier for us to fix bugs, I have tried to fix bugs with the current system but it comes down to I am not 100% sure how the system was intended to work so not sure if what is happening in some situations is intended or not.

As far as code comments go, I know I am horrible at commenting my own work but I am trying to do better at that since I started commenting the code. Either way if we do a revamp I would like to see lots of comments in the code, not just the xml documentation comments I have been adding into headers.

EDIT: John ninja posted on me
I am trying to be on IRC every night now and would welcome any input from scat.

Jabantiz wrote:all active devs should redesign it from the ground up making heavy use of the rules system.

Regarding Rules system, I've been sneaking in Rules whenever I touch code. I stole the idea from EQEmu, and want to mimic their usages (and beyond) for EQ2Emu. Calculation Values and Ratios, Offsets, Timers, whatever we need. That was always the plan. Let's do it.

Jabantiz wrote:Either way if we do a revamp I would like to see lots of comments in the code, not just the xml documentation comments I have been adding into headers.

I usually comment everything I touch, too (JA). It was always my plan to comment everything thoroughly, but here we are in year 5 and still not enough time to even play a game anymore

DOL (DAoC EMU) uses a rule system as well for a lot of stuff, as a server admin it makes tweaking your server easy, in there case they had a rules for (if IO remember correctly) bonus dmg, bonus xp, bonus rp (pvp xp), bonus bp (pvp currency), regen amount, and many many more. I would like to see this emu with this many options some day.

John Adams wrote:There is not one thing stopping anyone else from taking our code and commenting it as they learn it. So far, no one has volunteered for that effort. I have begged for years for help documenting. I have even offered very very entry-level simple coding projects (LogWrite) to help people learn C++ and still, zero interest. Very few have stepped forward and 90% of the Wiki is written by me.

Of course I understand completely, I may have spoken too generally, do not interpret my words as an irked tone. Point me in the right direction of whatever you want focused on and I'll try to document it to the best of my ability. *End off topic*

Jabantiz wrote:I would like to see this emu with this many options some day.

That's what I meant, Jab. I asked Scat to implement Rules specifically for these purposes. Almost anything that is hardcoded (something * 5) or (something / 3) the numbers would be rules values. Many, many of these are related to combat and buffs, as well as the different XP's. Have you seen the list of Rules we have already implemented? I started converting `variables` table values to Rules a while ago. Some have to be kept in `variables` (like Lotto) because they need to be persistent through server outages.

Not at all what I talked about in the first post but went into combat tonight and ripped out the MutexList<Entity*> fighters, Zoneserver now calls Combat::Process(spawn) for every spawn in the zone(was doing this anyway even with the list), the downside is the way I Implemented that combat no longer runs on its own thread. That being said the removal of that list seems to have improved zone stability. I tested with 3 clients and John logged on my server with 2 more clients and the lag was nothing at all like it was from last night, looting was allowed more often than not, and leaving DoV clients afk and unattended in graystone and queens colony they never crashed (were crashing a lot last night).

This still needs to be looked over for any possible problems from doing it this way, and probably find a way to put it back on its own thread, but it looks promising. The code has been commited to dev svn.

Putting this code on EQ2TC tonight. We should all hop on there (with my DB) and ensure the performance/stability benefits, so we can rule out Data.

Nice work, as usual Jabantiz. I'd like Scatman to review the changes to see if there's anything we're not thinking about. But as you said, all things appeared to work well, better than "normal". I will be very happy if our emulator stabilizes and becomes the thing-of-beauty it once was, before everything went to hell.

Already have a fix for the new code, something I overlooked was preventing zones from fully shutting down, just commited the fix.

Here's some basic stats from EQ2TC during Jabantiz' test of the new combat changes. As you can see, the VM really spikes in certain areas, where he was reporting random lag in-game.
I'd like to understand if this is caused by the combat living on the already-busy zoneserver thread, or if this has always been this way? Could very well be something wrong with this VM. It is old (Win2003x86).

It could be. But it could also be a number of things. Any patterns during the spikes?