Summoned Pets Turn to Ghosts

[Breea]

I know its been chatted up, but it needs to be addressed. There is an issue when the owner of a pet zones out, it leaves a shadow copy of itself in the old zone, even with persistent zones turned off if there is people in that zone afking or boxing the pets can be item duped by placing tons of items on the pets, zoning back and forward till someone has enough plat and items and then kill each pet for those items. The shadow version of the pet is placed in the npc_types table as SumEarthR001 or SumFireR001 etc, so as I'm trying to track this down it seems that there is a problem or something overlooked when someone leaves the zone there doesn't seem to be a kill or depop command for the pet. I've tried writing and applying quest scripts to run sub EVENT_SPAWN { quest::depop(); } but that does not work naturally being the mob isn't a spawn from the DB itself.

Can we, the community please get to work on this code. I'd be willing to start in but I'm only 70ish % through trying to learn the code myself. Any coding I can apply or conjure I will but this bug is definitely taking the mages out of the game or at least ruining a lot of server's economies =(.

[Breea]

Here we go...

	if(tmp->GetOwnerID() != GetID()) {
		SetPetID(0);
		// WE NEED TO KILL THE PET HERE!!!!!
		return(NULL);
	}

I'm assuming adding a kill code here in pets.cpp will get the job done?

Would this work for instance?

	if(tmp->GetOwnerID() != GetID()) {
		SetPetID(0);
        // Attempting to remove shadow pet.
		depop();
		return(NULL);
	}

Not sure that depop() is registered in any global functions or not =S

[Breea]

Also if we can get the pets working adding the same to the mounts would be an easy fix.

[Breea]

I tried strait up Depop(); that crashed the zone server... should it be pet->Depop(); ??

[KLS]

How exactly can I reproduce this 100% of the time? Or does this only happen sometimes?

[Breea]

Originally Posted by KLS

How exactly can I reproduce this 100% of the time? Or does this only happen sometimes?

It happens 100% of the time on a source build (last 5 releases) on a linux (fedora 6) quad-core box.

It is also adding these as npcs in the npc_types table.. Basically this could become a stability comprimise if a mage or pet class decides to just zone back and forth a few thousand times.

[KLS]

Hm well it doesn't happen here as described.

Player1 in zone with pet, player2 in same zone. Player1 zones out and pet disappears.

I'm not sure how or why it's getting added to your npc_types table. The only code that does that from stock emu code is command related...

Not sure what's going on but that doesn't sound good.

[KLS]

I'm still unable to replicate this, BUT.. if you're looking for a solution you could add something inside the npc::process tic_timer.check().

if(!IsCorpse() && GetPetType() != petCharmed)
{
     if(!GetOwner())
          Depop();
}

I'm not sure if it would work but it's worth a shot?

If we can figure out what causes this it'd be nice too.

[Lalolyen]

I'll be implementing that code asap. Also Breea should have sent you a PM there. Basically if you want to help us find out whats causing it, you have that open invitation.

[Lalolyen]

That did not work. Even adding opening and closing brackets to the if statement there.

It compiled fine but ghost pets are still there.

[Lalolyen]

More of a spectrum on whats going on.

It seems that when you zone, the pets.cpp or the npc.cpp is not removing the pet from the database ***OR*** after you zone the scripts forget your old pet after pulling him back up, assigning the new pet a new pet id in the database, and thus zoning leaves an unclaimed pet named SumXXXX or SkelXXXX where xxx is the pet type.

I've tried everything I know, no compile errors but also not doing what I want it to.

Ok, so the question I'm asking now, how is it possible to keep the pets id consistant throughout all the zones, not just:

Step 1: Pull pet from database.
Step 2: Assign a new pet id and forget old pet.


But add a step three: Check old pet, /kill or depop him and remove him from the database. *currently we have about 200+ shadow pet ids in our database and we cleaned them all up 3 days ago*.

Also note that this is a problem for those whom are using the persistent zone states to preserve spawn tables when the zone is inactive. Most people without persistent zone states do not see this as bad as when they come in the zone is in a repop state, clearing out these mobs. However for the people wanting to exploit, they can easily box another player in to hold the zone open while they zone back and fourth on the other toon to duplicate the pets and the items on them.

Also KLS you are welcome to login to our server "Divine Reapers" and check this out yourself. See your PM's for instructions for privileged access while we work on this.

[Lalolyen]

Also another tidbit he he sorry about that..

When APlayer zones from zone A to zone B with a pet, the pet's shadow remains in zone A we know, however if he dismisses his pet while in zone B, the shadow in zone A disappears or depops. BUT if APlayer zones to zone C, and dismisses the pet, the shadow pet in zone B disappears but the one in Zone A remains.

That is why I'm concluding that the script is not cleaning the database entry or either it is placing a new pet id in the database on each zone forgetting the previous pet.

[John Adams]

I was not aware that summoning a pet generated an entirely new NPC ID... If it is, I do not think that is right. NPC IDs < 1000 are pet-class pets, at least what I understood.

[KLS]

It doesn't, I'm not sure what's going on there, the only code that modifies the npc_types table that I can recall off hand are specific commands.

If my code did not work then I think there's something more wrong than merely we're not cleaning up the pets when a client leaves the zone, that means an entirely new npc is made when the client leaves and the normal pet depops with the client.. which lol I dunno I'd be kinda stumped on without being able to duplicate it locally.

[Furrygamer]

Could a factor such as the type of Linux being used or the type of compiler effect these factors? What additional information would you require to speculate further a fix?