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]

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?

[Irreverent]

No, had similar issues in Windows code.

[Furrygamer]

So what did you do to fix it? yes i know linux and window are different! might be able to translate it though. ^.^

[Lalolyen]

It looks like one actually made it so that pets are lost before they zone to fix their problem. Not sure about anyone else.

So this is not a platform problem?

[KLS]

Hm, was thinking perhaps the pet isn't being freed correctly by SetPet(0) for whatever reason;

Could try adding:

Mob *mypet = GetPet();
if(mypet)
mypet->Depop();

directly above:

//let the stream factory know were done with this stream
eqs->Close();
eqs->ReleaseFromUse();

in Client::~Client() ln241 in client.cpp and see if it has any impact on at least the pets no longer appearing in the zones as regular npcs.

[Irreverent]

I would say its not dependant of what type of system you're on. Its just a general code issue.

[Lalolyen]

Ok just recompiled and...

No joy...

Keep in mind with presistant zones turned off, there is not a problem (but spawns reset each time the zone idles/sleeps. However turning it back on to test this out, yeah pets still have shadows =(.

[Lalolyen]

KLS what file is it that controls the spawn conditions? I'm just wondering if we can have that code do a depop on any mob named "Sum*" and "Skel_Pet" etc upon a zone becomming active again.

[KLS]

Wouldn't happen to be using PersistentZoneState variable when this is happening would you?

Also if not, can you please tell me any variables you do have set or anything else you think I should know about how your server is setup.

[Lalolyen]

Oh yeah presist is on when this happens. Not enabling it will mess up spawns when a zone goes idle.

[KLS]

Ah yeah I've been told to steer clear of it in the past cause it does not work very well atm. I looked at it briefly and it doesn't differentiate between pc pets and reg npcs when it traverses the spawn list.

[Lalolyen]

Where is it storing the spawn list? Not in the sharemem is it?

If there is some temp file and I can get ahold of the source thats creating that code I'll get to work on to see what I can do to have it not stick any pets in it =).

Actually... What source file does the save?

[KLS]

ZoneDatabase:: DumpZoneState() in zone.cpp is what handles saving the zone state if you wanna take a look at it. Just looking at it I don't see a simple elegant solution. Might take some work.

[Lalolyen]

Now who said us devs are elegant? =P he he.

I've always heard something like, "If it doesn't crash, explode, whirl, or tick, do it again because you did something wrong" he he.

[gernblan]

This can be a tough one to solve I think, because of course sometimes pets can follow their owners from zone to zone.

I guess finding the way that they are somehow taking on more than one instance across zones and simply preventing more than one (similar to a spawnlimit of 1 I guess but global) would be the way out of this, because persistent pets would not be affected, but pets somehow turning into "ghost spawns" might be avoided.

I'm trying to brush up and catch up on my C++ after I finish absolutely mastering Perl (no small feat as anyone who codes in Perl knows... it's the easiest language to pick up and probably the most difficult language to master out there--a testament of it's power)... and wish I could help track down these bugs more.

I also need to continue studying the eqemu code and learning it in more detail--enough detail to know what's been done already and where everything is.

My participation on that front IS coming though. Once up to speed I'm not a bad programmer, it's just been awhile in terms of certain languages.

For now, I can only play cheerleader to those such as KLS and remind them how grateful I am that they are around.

[jenco420]

Has this been fixed yet, still a problem on my server =(