Page 1 of 1
Combat Thread issues (Split)
Posted: Wed May 02, 2012 9:33 am
by John Adams
Split from original thread:
Jabantiz wrote:On a side note, from what I understand from studying this class is that entities are added to a list as they engage in combat, when I close my server down it looks as if every single entity in the zone is in the list. Wich means combat checks are done for all these entities almost non stop. Am I misunderstanding how this works or are the entities really being added to the list incorrectly and not removed properly?
That will be a Scatman question, since I have almost no understanding of these lists and how Emu tracks things, yet.
But, let me clarify. Are you seeing that, in a zone with zero combat, no entities get on the Combat list at all? Then when you shut down the server, they are all still on the list anyway? If so, yes that doesn't seem right.
What also wouldn't seem right is if the list is empty, until 1 NPC enters combat. Then if they end combat (kill or die) they are STILL on the list? That too seems wrong.
However, if when a zone starts, every NPC is added and *checked* constantly, that does seem alright to me, because NPCs can engage in combat with nearly anything the server admin configures (faction and proximity). Without constant checks (probably actually done in a spawn loop somewhere) the NPCs would never engage... but I don't think this last scenario is what you are asking about.
Re: Code comments...
Posted: Wed May 02, 2012 2:30 pm
by Jabantiz
I noticed this in Darklight woods with the db you had released. As far as I know there is no scripted combat in tha zone. When I shut down the server I notice that the npc "a miner" is being removed from combat, the only place they are is in hate's envy. They were never in combat and no way they could have been, my server was up for 30 sec in this case while I tested something, yet it seems like there was an entry for every miner in hates envy. I am not sure if every spawn in the zone is added but it sure seems like it as in that brief up time the console was flooded with a lot of removing so and so from combat.
Re: Code comments...
Posted: Thu May 03, 2012 7:56 am
by Scatman
If thats happening it shouldnt be. Although there is no scripted combat, if they are apart of a faction and near a spawn with a hostile faction, the server will make them duke it out. I dont remember seeing this happen in Queens Colony with the crabs or Outpost with the deer. Did you go to the miners and watch them fight or not fight?
Re: Code comments...
Posted: Thu May 03, 2012 10:03 am
by John Adams
Jabantiz wrote:They were never in combat and no way they could have been, my server was up for 30 sec in this case while I tested something, yet it seems like there was an entry for every miner in hates envy.
This makes me think no combat but entered into the combat list anyway (?) - or, maybe Jabantiz is looking at the functionality of this list incorrectly (no offense, but he did say he wasn't sure heh). We should verify the purpose of this list or loop.
After checking the TessEQ2 DB (release), I see no "miner" spawns with a
spawn.faction_id set at all.
Re: Code comments...
Posted: Thu May 03, 2012 1:39 pm
by Jabantiz
The name is "a miner" they are in hate's envy. As for when I did the test and noticed this I was in hate's envy and was watching them walk around, they never left hate's envy and they never engaged in combat. Just checked again last night to verify and ran all around hate's envy not a single one was engaged in combat but when shutting down the sever there was a list of them (didn't count but looked like all of them) in the logs saying they are being removed from combat.
It is very possible I misunderstand the use of this list, this is what I assume the list does after quickly going over the code in combat.h/.cpp
Re: Code comments...
Posted: Fri May 04, 2012 7:24 am
by John Adams
Jab, there is one other possibility. Since I'm likely the one who added that logwrite() you are seeing, it's possible I mistook what's going on when that thread is shutting down. I thought you were looking at a list in C++/Debug or something, but the logwrites. Next time you get a chance, you want to check if my logger is just incorrect?
Although, it is in the Combat code, so you still may be asking the right question. When Scatman returns from vacation, I'll see if I can sit with him and go through this just to be sure.
Re: Code comments...
Posted: Fri May 04, 2012 5:16 pm
by Jabantiz
This is the code with the LogWrite
Code: Select all
void Combat::RemoveFighter(Entity* fighter, bool remove_hate){
if(!fighter) {
return;
}
LogWrite(COMBAT__DETAIL, "Combat", "Combat Removing fighter '%s'", fighter->GetName());
fighters.Remove(fighter);
if(remove_hate)
npc_ai.RemoveSpawnHate(fighter);
}
And this is the code that is triggering the spam when the server is shut down
Code: Select all
void Combat::ClearCombat(){
MutexList<Entity*>::iterator itr = fighters.begin();
while(itr.Next()){
RemoveFighter(itr->value);
}
}
So the LogWrite is accurate and only prints out the name of the entity being removed from the list. I have gone over it again briefly and am convinced only spawns in combat should be in this list and removed from it once combat has ended for them.
In Combat::Process it will cycle throught this list and call the actual combat functions.
Code: Select all
bool Combat::Process()
{
/* JA --
Any LogWrite()'s done inside a "Process()" function should be DETAILS only,
and possibly wrapped in #if EQDEBUG >= 5 or more to avoid spamming the hell
out of the console/logs
*/
if(shutdown)
return false;
Entity* fighter = 0;
float distance = 0;
MutexList<Entity*>::iterator itr = fighters.begin();
while(itr.Next())
{
It just seems like a lot of unnecessary checks are made for spawns not even in combat.
And this combat discussion should probably be broken off into its own thread now so it is easier to identify imo.
Re: Combat Thread issues (Split)
Posted: Mon May 07, 2012 12:26 am
by Scatman
Just got in from Florida, (friggin' 4 hour delay). So I'll take a look at this tomorrow after work.
Re: Combat Thread issues (Split)
Posted: Mon May 07, 2012 7:11 am
by John Adams
Scat, I'd like to hang with you (on IRC?) to walk through some of this if you don't mind. I need to start figuring some of this stuff out
Re: Combat Thread issues (Split)
Posted: Mon May 07, 2012 11:48 pm
by Jabantiz
When I was trying to help with the /reload spawn issue some one was having I noticed that the spawn I was creating was being added to combat, in an empty zone, with me spamming the /reload command so the spawn was up for no more then 30 sec (probably a lot less then that too). Based off of this my guess is that the spawn is always added in the proximity check as I can not think of anything else that would trigger being added to combat in this case. This is just a hunch and I haven't had time to check it yet.
Re: Combat Thread issues (Split)
Posted: Tue May 08, 2012 7:41 am
by John Adams
If that's the case, I wonder if the spawn should only be added *if* it has a script attached, or a proximity function assigned?
Re: Combat Thread issues (Split)
Posted: Mon May 14, 2012 2:22 pm
by Scatman
So the offending function seems to be
I've looked at it briefly but the code inside of the
else starting at line 569 doesn't seem correct to me. It should only be adding npc vs npc in combat IF they are aggro'able to each other AND they are in their aggro range. With that said, the
if above that goes with
that else has a check for AttackAllowed(). The third parameter should be true so that the distance of their aggro radius is taken into account before adding them to combat.
There may be other places too. That entire function should be closely evaluated.
Re: Combat Thread issues (Split)
Posted: Mon May 14, 2012 2:30 pm
by Jabantiz
If I remember right AttackAllowed() doesn't return false if the distance check fails and that is why almost every thing that needs a distance check does the calculations again itself. It would be a simple fix, just setting the default return to false but this is all based off memory from when I did the comments, will have to double check it later today when I get the time.
Re: Combat Thread issues (Split)
Posted: Sat Jul 21, 2012 10:41 pm
by Jabantiz
I was looking at combat again today and noticed that the only way for a spawn to be added to the list is by calling Combat::AddFighter() wich has its own LogWrite
Code: Select all
void Combat::AddFighter(Entity* fighter, Entity* victim){
if(!fighter) {
return;
}
LogWrite(COMBAT__DETAIL, "Combat", "Combat Adding fighter '%s'", fighter->GetName());
//fighter->InCombat(true);
if(fighter->IsNPC() && victim)
AddHate((NPC*)fighter, victim, 50);
fighters.Add(fighter);
}
However I never get spammed with the Adding fighter message. Looking at RemoveFighter() and ClearCombat() (both posted above) only spawns in the list should be removed on shutdown, and there is where I am getting the spam, so how are all these spawns getting into the list without triggering the LogWrite() in AddFighter()?
Re: Combat Thread issues (Split)
Posted: Sun Jul 22, 2012 2:04 pm
by Jabantiz
I added a LogWrite() just before the iteration of fighters in ClearCombat to print out the size of the list, used both fighters.size() and fighters.size(true) (include pending entries) and both times it returns 0, so if the size of the list is 0 then how does RemoveFighter (the source of the LogWrite spam) even get called?
Tried replacing the MutexList with a simple vector but it has the same results.