Go Back   EQEmulator Home > EQEmulator Forums > Development > Development::Development

Development::Development Forum for development topics and for those interested in EQEMu development. (Not a support forum)

Reply
 
Thread Tools Display Modes
  #1  
Old 09-08-2007, 05:39 PM
Breea
Banned
 
Join Date: Aug 2007
Posts: 28
Default Summoned Pets Turn to Ghosts

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 =(.
Reply With Quote
  #2  
Old 09-08-2007, 06:02 PM
Breea
Banned
 
Join Date: Aug 2007
Posts: 28
Default

Here we go...

Code:
	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?

Code:
	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

Last edited by Breea; 09-09-2007 at 02:07 AM..
Reply With Quote
  #3  
Old 09-08-2007, 06:13 PM
Breea
Banned
 
Join Date: Aug 2007
Posts: 28
Default

Also if we can get the pets working adding the same to the mounts would be an easy fix.
Reply With Quote
  #4  
Old 09-08-2007, 07:39 PM
Breea
Banned
 
Join Date: Aug 2007
Posts: 28
Default

I tried strait up Depop(); that crashed the zone server... should it be pet->Depop(); ??
Reply With Quote
  #5  
Old 09-08-2007, 07:58 PM
KLS
Administrator
 
Join Date: Sep 2006
Posts: 1,348
Default

How exactly can I reproduce this 100% of the time? Or does this only happen sometimes?
Reply With Quote
  #6  
Old 09-08-2007, 08:50 PM
Breea
Banned
 
Join Date: Aug 2007
Posts: 28
Default

Quote:
Originally Posted by KLS View Post
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.

Last edited by Breea; 09-09-2007 at 04:52 AM..
Reply With Quote
  #7  
Old 09-09-2007, 06:14 AM
KLS
Administrator
 
Join Date: Sep 2006
Posts: 1,348
Default

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.
Reply With Quote
  #8  
Old 09-10-2007, 05:45 PM
KLS
Administrator
 
Join Date: Sep 2006
Posts: 1,348
Default

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().

Code:
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.
Reply With Quote
  #9  
Old 09-10-2007, 07:41 PM
Lalolyen
Banned
 
Join Date: Aug 2007
Location: Sneeking up behind a admin IRL
Posts: 169
Default

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.
Reply With Quote
  #10  
Old 09-10-2007, 08:59 PM
Lalolyen
Banned
 
Join Date: Aug 2007
Location: Sneeking up behind a admin IRL
Posts: 169
Default

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

It compiled fine but ghost pets are still there.
Reply With Quote
  #11  
Old 09-10-2007, 10:10 PM
Lalolyen
Banned
 
Join Date: Aug 2007
Location: Sneeking up behind a admin IRL
Posts: 169
Default

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.

Last edited by Lalolyen; 09-11-2007 at 06:15 AM..
Reply With Quote
  #12  
Old 09-10-2007, 10:20 PM
Lalolyen
Banned
 
Join Date: Aug 2007
Location: Sneeking up behind a admin IRL
Posts: 169
Default

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.
Reply With Quote
  #13  
Old 09-11-2007, 01:54 AM
John Adams
Demi-God
 
Join Date: Jul 2006
Posts: 1,552
Default

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.
Reply With Quote
  #14  
Old 09-11-2007, 09:04 AM
KLS
Administrator
 
Join Date: Sep 2006
Posts: 1,348
Default

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.
Reply With Quote
  #15  
Old 09-11-2007, 03:43 PM
Furrygamer
Banned
 
Join Date: Jul 2007
Posts: 11
Default

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?
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

   

All times are GMT -4. The time now is 12:05 PM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3