EQEmulator Forums

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)
-   Quests::Q&A (https://www.eqemulator.org/forums/forumdisplay.php?f=599)
-   -   default.pl (https://www.eqemulator.org/forums/showthread.php?t=30793)

Lillu 03-13-2010 01:39 PM

default.pl
 
We put a default.pl in the root quest directory to handle item turn in events. but strangle it seems like it does effect player's pets too, not just npcs.
putting default.pl to a specific zone folder or templates folder wont work at all.

the code is simple:
Code:

sub EVENT_ITEM {
quest::emote(" looks at you strangely.");   
plugin::return_items(\%itemcount);
}

what do we miss? any help would be appreciated.

Taurinus 03-13-2010 03:17 PM

Quote:

We put a default.pl in the root quest directory to handle item turn in events. but strangle it seems like it does effect player's pets too, not just npcs.
I find it strange that you find it strange. Pets are NPCs. Default.pl belongs in the plugins folder and only there AFAIK.

Lillu 03-13-2010 06:46 PM

fyi, default.pl doesn't belong to the plugins folder. it belongs to and works in the root quest directory.

besides I can do sub EVENT_ITEM per individual npcs, any help would be appreciated for a global solution.

Taurinus 03-13-2010 09:16 PM

oh yea, you're totally right about the placement of default.pl. I had moved it into the plugin folder on this end, to disable it (but keep it) and totally forgot where it originally went.

Could you not filter the pets out by their IDs (and by range if you wanted) if you don't want them reacting with the default behavior?

Pseudo:

Enter default behavior sub
reject pets
do your thing...

That's the only way I can think of doing it since pets are indeed npcs.

ChaosSlayerZ 03-13-2010 10:36 PM

well if someone could actually write such filtering code- would be much appreciated.

However, would nice, of our dev could include few more option in code:

-default.pl - affects npcs and pets
-default-npc.pl - affects only mobs
-default-pet.pl - affects only pets

Taurinus 03-13-2010 11:48 PM

I'm no script jockie, so keep that in mind BUT:

I did read through the wiki again real quick and came up with a working filter method for rejecting (or selecting, your choice) pets based on npc id.

Code:

sub EVENT_SAY
{
        my $mob = plugin::var('$mob');
        my $npcid = $mob->GetNPCTypeID();
        if($npcid < 1000)
{
        quest::say("I am a pet!");
}
  plugin::defaultSay();
}

With this, only pets (based on peq db distro) will respond.

trevius 03-14-2010 12:38 AM

If you want to have all NPCs automatically return no drop items, you could update to rev1144 or later so you can use the rule NPC:ReturnNonQuestNoDropItems that I added. It basically causes all NPCs that don't have an EVENT_ITEM to return all No Drop items handed to them. It also includes pets, but it still allows tradeable items to be handed to all NPCs and pets, so giving pets weapons still works fine. I added this to prevent players from turning in quest items to their pets or to non-quest NPCs by mistake. Seems to help a lot so far lol.

I do agree that it would be nice to have more default type script options. If you want to exclude pets from default.pl for now, the only way I know of is to make a script for every pet and put it in your templates folder. You just name them something like cleric_hammer_67_.pl or BLpet47.pl and so on. Just all of the ones in your pets table should do it. It is a bit of an annoying way to deal with it, but should work ok I think.

ChaosSlayerZ 03-14-2010 01:54 AM

ah this awesome Trev. I am pretty sure we are running revision past that one. We will check on it. Thank you for help!

Lillu 03-14-2010 06:12 AM

Thank you :)

joligario 06-23-2010 03:58 PM

Anyone been able to get zonewide default.pl to work lately? Seems broken. The same file works fine as a worldwide default.pl. Trying to use an EVENT_ITEM sub.

joligario 06-26-2010 11:46 AM

Ok, did a little research and testing on this and I see what is going on. When the zone is initialized, the default npc quest file is chosen because npc and zone have not yet been passed:

Code:

        string filename= "quests/", packagename = GetPkgPrefix(npcid);
        //each package name is of the form qstxxxx where xxxx = npcid (since numbers alone are not valid package names)
        questMode curmode = questDefault;
        FILE *tmpf;
//LogFile->write(EQEMuLog::Debug, "LoadScript(%d, %s):\n", npcid, zone);
        if(!npcid || !zone)
        {
//LogFile->write(EQEMuLog::Debug, "        default 1");
                filename += DEFAULT_QUEST_PREFIX;
                filename += ".pl";
                curmode = questDefault;
        }

So the system will always load quests/default.pl as the default. I can't see a way to pass the zone to attempt quests/zone/default.pl before finally settling on quests/default.pl

Akkadius 09-21-2010 10:57 PM

Quote:

Originally Posted by joligario (Post 189162)
Ok, did a little research and testing on this and I see what is going on. When the zone is initialized, the default npc quest file is chosen because npc and zone have not yet been passed:

Code:

        string filename= "quests/", packagename = GetPkgPrefix(npcid);
        //each package name is of the form qstxxxx where xxxx = npcid (since numbers alone are not valid package names)
        questMode curmode = questDefault;
        FILE *tmpf;
//LogFile->write(EQEMuLog::Debug, "LoadScript(%d, %s):\n", npcid, zone);
        if(!npcid || !zone)
        {
//LogFile->write(EQEMuLog::Debug, "        default 1");
                filename += DEFAULT_QUEST_PREFIX;
                filename += ".pl";
                curmode = questDefault;
        }

So the system will always load quests/default.pl as the default. I can't see a way to pass the zone to attempt quests/zone/default.pl before finally settling on quests/default.pl

So Joligario, did you get zone default.pl to load right again?

joligario 09-22-2010 06:43 AM

Actually, no. I haven't had a chance to work on that much. I will look at this again soon.

Akkadius 09-22-2010 09:01 AM

Quote:

Originally Posted by joligario (Post 192374)
Actually, no. I haven't had a chance to work on that much. I will look at this again soon.

Awesome, that would make zone specific events much easier to execute rather than 40 different scripts for similar functions.

joligario 10-16-2010 07:52 PM

Trevius worked this issue and it should be fixed as of r1705.

Akkadius 10-16-2010 08:12 PM

Quote:

Originally Posted by joligario (Post 193179)
Trevius worked this issue and it should be fixed as of r1705.

Aye I saw that, pretty awesome!

trevius 10-18-2010 08:13 AM

Yeah, it seems to work well for me so far, but let me know if anyone sees issues with it.

thepoetwarrior 10-22-2010 12:29 PM

Thank You Very Much Trevius!!!! Awsome Update!

thepoetwarrior 10-28-2011 01:08 PM

Weird issue with default.pl for pets/npcs.

The quest/zonename/default.pl overwrites any other default.pl is is GOOD.

The quest/default.pl only works if there is some dummy default.pl in quest/templates/default.pl

Hope makes sense. Don't know why. Found out through trial and error. If there is no default.pl in the quest/templates/ then the one in quest/ wont work.

Noticed this when swapping out default.pl (for pets) with the Halloween Event default.pl that I have for this year. Weird how I got it to work.

Any ideas?

trevius 10-28-2011 01:42 PM

I am not exactly sure what you are saying is an issue. I would recommend against using default.pl for pets, because of how default.pl works.

As you mentioned, default.pl loads from the current zone folder before it tries loading from templates. I am not sure how you had one that worked in quests/ directly. Nothing should be loaded directly from quests/. If you want a globally used default.pl (or any other) file, it should be in quests/templates/.

I don't run a default.pl in templates, because it is much better to be used from zone folders. I also don't use default.pl for pets, because it is MUCH better to just make individual scripts for each pet and keep those in the templates folder. Basically, you look at the spell and find the name that the spell uses to load that pet, and make a file named for that. Some examples are skel_pet_72_.pl or SumAirR17.pl and so on. It does make it a bit of a pain to manage if you want a lot of pets to use scripts, but it still works better than using default.pl for it.

I use the default.pl for scripts of trash NPCs and anything that might be used by multiple NPCs. To prevent any unscripted pets or temp pets from using the default.pl for the zone, I add the following at the top of every event in the default.pl:

Code:

        # Prevent pets or charmed NPCs from loading the default.pl
        if (!$npc || $npc->GetOwnerID() || $npc->GetSwarmOwner())
        {
                return;
        }


thepoetwarrior 10-28-2011 11:44 PM

We use the default.pl so players can hail any pet in any zone to use their own pet as a buff bot, and manage giving pet items, etc. Works pretty well, with npc < 1000 in the file etc.

For our Halloween Event we used default.pl and within it have if $zonesn eq "name" for killing random trash in certain zones to spawn Halloween Bosses, etc.

I did this way back when I had less exp. I'd probably do it different today. Yes, having a pet_name.pl file for each of the many pets would be a pain, but probably more efficient.

I still don't understand if the default.pl goes in /quest/ or /quest/templates/ or both? How is it handled? Seems to work the way I have it. Going to try to put the same script in both locations now. Thanks for help as Always Trevius.

trevius 10-29-2011 12:03 AM

Nothing that I am aware of will load directly from /quests/, you would want to use /quests/templates/ for any globally loaded scripts. If you put a script only in quests, it shouldn't work. If you put one only in templates, it should.

thepoetwarrior 10-29-2011 01:02 PM

I have confirmed the global default.pl works in /quest/ not /quest/templates/

Can you test this on your server maybe? I hate to argue, but its working opposite of what I'm being told.


All times are GMT -4. The time now is 01:08 AM.

Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.