Combat Thread issues (Split)

[John Adams]

Split from original thread:

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.

[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.

[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?

[John Adams]

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.

[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

[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.

[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.

[Scatman]

Just got in from Florida, (friggin' 4 hour delay). So I'll take a look at this tomorrow after work.

[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

[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.

[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?

[Scatman]

So the offending function seems to be

Code: Select all

ZoneServer::CheckNPCAttacks

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.

[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.

[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()?

[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.