OOC Regen Enable/Disable

[Congdar]

Yes, i'm finding that there is lots of code that works in the eqemulator.net source tree that doesn't work in the svn source tree. I'm working to update the bot source for svn as fast as I can.

[trevius]

Does anyone know how to do a check to see if a player has aggro on any NPC? The closest thing I can find is IsOnHateList(), but that looks to only work if you check it for a particular NPC. Basically, I just want to know if a player has any aggro at all, similar to the NPC IsEngaged() check. Or, would it be possible to make an IsEngaged() check for clients or maybe expand the command to work for either? It would also have to be able to know if they are in PVP combat or not. Maybe if they have PVP on, the OOC regen would be disabled or something.

Once this part gets figured out, I can finish the code, test it and add it to the SVN.

Here is the post with the current code I have for the OOC Regen for players:
http://www.eqemulator.net/forums/sho...98&postcount=8

Note that I also made it so that it only does HP/Mana updates if the HPs/Mana are less than max HPs/Mana. I did test that and I don't see any weird issues with not sending them every tick if they are full. If anyone knows a reason why it should always send them, let me know. This is just another attempt to help reduce unneeded bandwidth utilization. It seems like there are many things being sent and overlapping that shouldn't be and they are generating much more traffic than we actually need to use to do everything flawlessly.

[steve]

The way OOC regen works on Live, that is, when a character is not in combat, their hp/mana goes into super-regen mode.

After a character has finished combat, has no NPCs agro on them, and has no detrimental effects casted on them, they enter the 30 second 'wait time'. As long as the character does not re-engage an NPC, their hp/mana will regen completely, from 0% to 100% in 3 minutes. This scales with their hp/mana pool, so it does not matter if they have 5k mana or 15k mana. After 3 minutes, they will be completely full.

OOC regen does exist in raid zones, but I do not recall the 'wait time' before it kicks in. I think it may be 15 minutes, but might be as high as 30 minutes.

[trevius]

Ok, I added in a wait time setting so you can set a rule to define how many ticks you want it to wait before OOC Regen starts working after the character leaves combat. So, if you wanted it to wait 30 seconds before starting OOC Regen, you should be able to set this to 4. The first 6 seconds is automatically added by the timer between ticks after you leave combat. I think it will work properly.

Here is the edited post with the current code:
http://www.eqemulator.net/forums/sho...98&postcount=8

Still just need the in combat check for clients to finalize this code.

[trevius]

Added another rule to the code to allow admins to chose if they want player casting to stop OOC Regen or not. This will stop OOC regen if a player is casting buffs or a nuke or anything else.

Once the engaged check is working, this system should be pretty robust lol.

[ChaosSlayer]

so what was wrong with using Feign Death like approach? or does FD simply erased hate lists?

[trevius]

That FD check was in the Bots code and it has since been removed and replaced. It was actually checking if they were FD or if they were engaged before it would allow a bot to be summoned. Apparently the IsEngaged check has been changed so that it doesn't work for players anymore. I am not sure why.

[AndMetal]

For some reason I thought something was changed with the client hate list, but I may have misread something (discussion), because I can't find it being mentioned specifically (or in the changelogs, etc).

Looking through the code, Mob::IsEngaged checks to see if the hate_list, tucked in the protected portion of the Mob class in zone/mob.h, IsEmpty() (defined in hate_list.cpp). At that point, it basically iterates through the hate list to see if there are any hate values > -1.

There is a function, Mob::PrintHateListToClient (which basically points to HateList::PrintToClient) that's used by the #hatelist command that we might be able to use to debug it. I'm still running the base version of 1129, and I'm able to see my (client) hate list fine.

On a somewhat related note, the current SVN source doesn't wipe the client's hate list after you have successfully feigned and then waited the 2 min for the aggro to clear, at least as far as I can tell. As a result, you could still be considered Engaged if a mob you were killing is still alive, you feigned, & its hate list is wiped, so it no longer knows about you. You should be able to do this:
in zone/client_process.cpp, around line 626, add

	// EverHood Feign Death 2 minutes and zone forgets you
	if (forget_timer.Check()) {
		forget_timer.Disable();
		entity_list.ClearZoneFeignAggro(this);
		WhipeHateList(); //wipe the client's hate list
		Message(0,"Your enemies have forgotten you!");
	}

I'm pretty sure WhipeHateList (sic) should be able to inherit from the Mob class, although if not, we may need to rework it a little.

In any case, if anyone has a chance to check the client/bot hate lists to see what's going on, maybe we can get to the bottom of this.

[So_1337]

I'm still running the base version of 1129, and I'm able to see my (client) hate list fine.

The change came in Revision 38:

==10/03/2008
KLS: Hate list will no longer work for non ai controlloed player characters.

The problem had been that the client was maintaining a hate list that would never be wiped unless the mob on it was killed or the player camped/zoned. This was what was causing feign death to pull zone-wide trains. Since removing the hatelist from players, it's been corrected, though it has had other issues (such as breaking the mob fleeing code; they originally checked the client hatelist to see if there were other mobs with them).

My guess is that that may be what IsEngaged was calling on, and it's no longer there.

[Congdar]

attack.cpp Mob::AddToHateList

	if(IsClient() && !IsAIControlled())
		return;

This is where the hate_list is used for the client... only if the client is charmed and aicontrolled.

[trevius]

I think we can set IsEngaged() back to the way it was before and simply add in the whipehatelist code that AndMetal posted to fix the FD issue. The IsEngaged() check being available for clients is just too useful to remove it to fix FD. I am pretty sure that the fix AndMetal posted above will correct it. I will try it out tonight along with my OOC Regen code using the old IsEngaged() check by removing the check that Congdar posted. I think that will resolve some of the issues we are having right now with other code.

[trevius]

Finally, by reverting IsEngaged() back to allowing it to work on clients, I was able to get OOC Regen working almost perfectly. The only thing that isn't currently working 100% as intended is the wait timer. And by adding the WhipeHateList() to the FD forget timer, it should fix the issues with FD as well even with IsEngaged() being reverted back. Much thanks for AndMetal, So_1337 and Congdar for figuring that stuff out

zone/attack.cpp in Mob::AddToHateList remove:

	if(IsClient() && !IsAIControlled())
		return;

zone/client_process.cpp, around line 626, add the RED line

	// EverHood Feign Death 2 minutes and zone forgets you
	if (forget_timer.Check()) {
		forget_timer.Disable();
		entity_list.ClearZoneFeignAggro(this);
		WhipeHateList(); //wipe the client's hate list
		Message(0,"Your enemies have forgotten you!");
	}

zone/client_process.cpp remove:

void Client::DoHPRegen() {
	sint32 normal_regen = LevelRegen();
	sint32 item_regen = itembonuses.HPRegen;
	sint32 spell_regen = spellbonuses.HPRegen;
	sint32 total_regen = normal_regen + item_regen + spell_regen;
	total_regen = (total_regen * RuleI(Character, HPRegenMultiplier)) / 100;
	SetHP(GetHP() + total_regen);
	SendHPUpdate();
}

void Client::DoManaRegen() {
	if (GetMana() >= max_mana)
		return;
	int32 level=GetLevel();
	int32 regen = 0;
	if (IsSitting() ||(GetHorseId() != 0)) {		//this should be changed so we dont med while camping, etc...
		if(HasSkill(MEDITATE)) {
			medding = true;
			regen = (((GetSkill(MEDITATE)/10)+(level-(level/4)))/4)+4;
			regen += spellbonuses.ManaRegen + itembonuses.ManaRegen;
			CheckIncreaseSkill(MEDITATE, -10);
		}
		else
			regen = 2+spellbonuses.ManaRegen+itembonuses.ManaRegen+(level/5);
	}
	else {
		medding = false;
		regen = 2+spellbonuses.ManaRegen+itembonuses.ManaRegen+(level/5);
	}
	regen += GetAA(aaMentalClarity);
	regen += GetAA(aaBodyAndMindRejuvenation);
	regen = (regen * RuleI(Character, ManaRegenMultiplier)) / 100;
	
	SetMana(GetMana() + regen);
	SendManaUpdatePacket();
}

And replace it with this:

void Client::DoHPRegen() {
	if(GetHP() < GetMaxHP()) {  //Don't do HP regen if HPs are full
		int32 level=GetLevel();
		int32 oochpregen = 0;
		int8 oocwaittime = oocwaittime++;
		sint32 normal_regen = LevelRegen();
		sint32 item_regen = itembonuses.HPRegen;
		sint32 spell_regen = spellbonuses.HPRegen;
		sint32 total_regen = normal_regen + item_regen + spell_regen;
		if(IsEngaged()) {
			oochpregen = 0;
			oocwaittime = 0;
		} else {
			if(IsCasting() && RuleB(Character, OOCRegenCastCheck)) {
				oochpregen = 0;
				oocwaittime = 0;
			} else {
				if(oocwaittime >= RuleI(Character, OOCRegenWaitTicks)) {
					oochpregen += GetMaxHP() * RuleI(Character, OOCHPRegen) / 100;
					oochpregen -= level / RuleI(Character, MaxLevel) * oochpregen * RuleI(Character, OOCRegenLevelScale) / 100;
					oocwaittime = RuleI(Character, OOCRegenWaitTicks);
				}	
			}
		}
		total_regen = ((total_regen * RuleI(Character, HPRegenMultiplier)) / 100) + oochpregen;
		SetHP(GetHP() + total_regen);
		SendHPUpdate();
	}
}

void Client::DoManaRegen() {
	if(GetMana() < GetMaxMana()) { //Don't do mana regen if mana is full
		int32 level=GetLevel();
		int32 regen = 0;
		int8 oocwaittime = oocwaittime++;
		int32 oocmanaregen = 0;
		if(IsEngaged()) {
			oocmanaregen = 0;
			oocwaittime = 0;
		} else {
			if(IsCasting() && RuleB(Character, OOCRegenCastCheck)) {
				oocmanaregen = 0;
				oocwaittime = 0;
			} else {
				if(oocwaittime >= RuleI(Character, OOCRegenWaitTicks)) {
					oocmanaregen += GetMaxMana() * RuleI(Character, OOCManaRegen) / 100;
					oocmanaregen -= level / RuleI(Character, MaxLevel) * oocmanaregen * RuleI(Character, OOCRegenLevelScale) / 100;
					oocwaittime = RuleI(Character, OOCRegenWaitTicks);
				}
			}
		}
		if (IsSitting() ||(GetHorseId() != 0)) {		//this should be changed so we dont med while camping, etc...
			if(HasSkill(MEDITATE)) {
				medding = true;
				regen = (((GetSkill(MEDITATE)/10)+(level-(level/4)))/4)+4;
				regen += spellbonuses.ManaRegen + itembonuses.ManaRegen;
				CheckIncreaseSkill(MEDITATE, -10);
			}
			else
				regen = 2+spellbonuses.ManaRegen+itembonuses.ManaRegen+(level/5);
		}
		else {
			medding = false;
			regen = 2+spellbonuses.ManaRegen+itembonuses.ManaRegen+(level/5);
		}

		//AAs
		regen += GetAA(aaMentalClarity) 
			+ GetAA(aaBodyAndMindRejuvenation) 
			+ GetAA(aaExpansiveMind);

		regen = ((regen * RuleI(Character, ManaRegenMultiplier)) / 100) + oocmanaregen;
		
		SetMana(GetMana() + regen);
		SendManaUpdatePacket();
	}
}

I have tested this and once I get the wait timer working, I will add it to the SVN so anyone can enable it with the new rules or just leave it disabled as it is by default. It could actually get added as-is, but I don't think the wait timer will be that hard to fix. I am just not sure why the code I have set for it isn't working. It seems that no matter what I set the wait timer rule to, it always starts regen on the first tick after a fight is over.

If anyone knows of a reason why this shouldn't be added, please let me know!

Moved this thread to Development:evelopment since it is nearly final and not really a request anymore.

[Derision]

I looked at reverting the change in Mob::AddToHateList when I was looking at fixing the Flee code. I added code to Feign Death, Rogue Escape and Bard Fading Memories to wipe the clients hate list, but I found a problem, so I backed that out.

Depending on timing, you can have a situation where a mob starts to cast an offensive spell on the player, a Rogue hits 'Escape', clears it's hatelist and then the spell still lands on the player and the mob is added back to the player's hate list, even though the mob no longer hates the player.

As I say, it purely depends on the timing of a mob casting and the player hitting Escape, or Fading Memories and probably won't happen often, but it is something to be aware of.

[trevius]

It worked that way on Live too though

I played a rogue on live and using escape while something was casting on you would break hide/sneak and also add you back to their hate list. So unless something has changed since I played, I think that would be perfectly acceptable and intended. I am not sure even with changing how IsEngaged works that a spell being cast on you won't cause aggro after you escape or fade. It should at the very least break your hide/sneak.

Maybe you can put those changes back in unless someone else thinks it should work any differently.

[Congdar]

on Live it is like that, but is it like that here? if the spell lands after fd or fm it should break fd and fm and add to both mob and client hate lists... i think here it may only add to the clients hate list and not actually break fd and fm.