EQEmulator Forums

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)
-   Support::General Support (https://www.eqemulator.org/forums/forumdisplay.php?f=598)
-   -   Odd looting issue... (https://www.eqemulator.org/forums/showthread.php?t=42423)

t0neg0d 04-28-2019 02:42 AM

Odd looting issue...
 
Custom quest using snpool.

Custom quest item added that needs to be looted...

If the item is added to an npc in the zone stated above (via $npc->AddItem, quest::addloot or '#npcloot add id), it becomes unlootable. If I bounce over to say... commons, it works fine.

Is there something I am missing?

The message you receive in game is the same you would see if loot was locked. (i.e. You may not loot that item from this corpse. You are not allowed to loot item: XXXX)

t0neg0d 04-28-2019 12:59 PM

This also happens using loottables to add the item(s).

Happens with existing items in the dB as well.

Item flags don't seem to effect it either way (i.e. notrade, norent, questitemflag, races/classes set to all/all or none/none)

While working on the quest, I made a new version of the zone and made it a globally accessible instance.

Not sure if this would effect things or not... however while implementing some DoDH content (longshadow missions), adding the zonewide random drops worked fine. drachnidhive was instanced using a different version of that zone... and no issues.

t0neg0d 04-28-2019 02:49 PM

This problem only occurs with global instances.

No clue why still, but ... there it is.

Huppy 04-28-2019 05:45 PM

Quote:

Originally Posted by t0neg0d (Post 262311)
This problem only occurs with global instances.

No clue why still, but ... there it is.

This is kind of odd. I've run simple scripted instances before with custom loot and never had a problem,(long time ago), but I have never went full out like you are. I will do a little testing and see what happens.

Huppy 04-28-2019 09:22 PM

Ok so far, for testing, I created a "version 1" the of nexus zone, as well as a few versions of the regular spawns in there, since some actually have regular loot items on them. (I used Percy_Clutches to test). I put a script on an npc in the pok, simply using "plugin::SendToInstance" and after I killed Percy, I was able to loot the robe and staff, no problem.

After that, I created another version of snpool, but with a custom NPC and fully custom item on it. Again, I used an npc script to enter the instance with:
Code:

plugin::SendToInstance("solo", "snpool", 1, 137, -5, -19, "EXP", 360);
I was able to loot the custom item without issues, but I am not sure just exactly what your setup involves at all, maybe something a little deeper ? (I used "solo", rather than group or public, just for testing)

Edit - Forgot to add, I used a quest::addloot under a simple EVENT_SPAWN script in the snpool instance with the custom item and I was still able to loot it no problem.

t0neg0d 05-03-2019 01:03 AM

Quote:

Originally Posted by Huppy (Post 262316)
Ok so far, for testing, I created a "version 1" the of nexus zone, as well as a few versions of the regular spawns in there, since some actually have regular loot items on them. (I used Percy_Clutches to test). I put a script on an npc in the pok, simply using "plugin::SendToInstance" and after I killed Percy, I was able to loot the robe and staff, no problem.

After that, I created another version of snpool, but with a custom NPC and fully custom item on it. Again, I used an npc script to enter the instance with:
Code:

plugin::SendToInstance("solo", "snpool", 1, 137, -5, -19, "EXP", 360);
I was able to loot the custom item without issues, but I am not sure just exactly what your setup involves at all, maybe something a little deeper ? (I used "solo", rather than group or public, just for testing)

Edit - Forgot to add, I used a quest::addloot under a simple EVENT_SPAWN script in the snpool instance with the custom item and I was still able to loot it no problem.

It only happens when the instance is set up as global with no expiration. Just add the zone to the instance_list and flag it as is_global & never_expires. Only reason I had it set up this way was to work on the quest script... once created via perl... it worked fine. Thought it was at least worth mentioning, in case I was doing something wrong... or there was an actual issue.

Uleat 05-03-2019 10:59 AM

Post your full script for adding items, please.

t0neg0d 05-03-2019 03:21 PM

Quote:

Originally Posted by Uleat (Post 262381)
Post your full script for adding items, please.

Code:


sub EVENT_SPAWN {
        $npc->AddItem(10507, 1);
}

Tried all of the above stated as well. Once again... this ONLY happens when it is a global instance.... and at one point I did see an error concerning loot lock... if that helps any.

Huppy 05-03-2019 03:47 PM

Did you try this ?
Code:

sub EVENT_SPAWN{

                plugin::AddLoot(1, 1, 13005); #(amount,chance,itemID) (1 for chance makes it 100%)
}

I could be wrong, but I thought that SendToInstance plugin created a global, when it creates the instance ? I'd have to look at the plugin script.

t0neg0d 05-03-2019 05:06 PM

Quote:

Originally Posted by Huppy (Post 262391)
Did you try this ?
Code:

sub EVENT_SPAWN{

                plugin::AddLoot(1, 1, 13005); #(amount,chance,itemID) (1 for chance makes it 100%)
}

I could be wrong, but I thought that SendToInstance plugin created a global, when it creates the instance ? I'd have to look at the plugin script.

$npc->AddItem
'#npcloot add id
quest::AddLoot

All of them result with unlootable items (in a global instance)

It may be how I was send the client to the instance, however... when I checked instance_list_player... there was an entry for the client.

Uleat 05-03-2019 06:45 PM

If you can grab that error message, it might help as well.

Uleat 05-03-2019 07:00 PM

By chance...

Did the account that you were using have less than 100 status and you had your GM flag on?


Code:

void Corpse::MakeLootRequestPackets(Client* client, const EQApplicationPacket* app) {
...
        // all loot session disqualifiers should occur before this point as not to interfere with any current looter
        loot_request_type = LootRequestType::Forbidden;

        // loot_request_type is scoped to class Corpse and reset on a per-loot session basis
        if (client->GetGM()) {
                if (client->Admin() >= 100)
                        loot_request_type = LootRequestType::GMAllowed;
                else
                        loot_request_type = LootRequestType::GMPeek;
        }
        else {
                if (IsPlayerCorpse()) {
                        if (char_id == client->CharacterID()) {
                                loot_request_type = LootRequestType::Self;
                        }
...

and

Code:

void Corpse::LootItem(Client *client, const EQApplicationPacket *app) {
...
        if (loot_request_type < LootRequestType::GMAllowed) { // LootRequestType::Forbidden and LootRequestType::GMPeek
                client->QueuePacket(app);
                SendEndLootErrorPacket(client);
                // unlock corpse for others
                if (IsBeingLootedBy(client))
                        ResetLooter();
                return;
        }
...

If you have your GM flag on, that takes precedence over an actual player-level loot action.

And, if you're status isn't high enough, then you can only 'open' the corpse and not actually remove (loot) anything.

This is so that guides can see..but, not touch a corpse's contents.

Huppy 05-03-2019 10:37 PM

Quote:

Originally Posted by Uleat (Post 262398)

If you have your GM flag on, that takes precedence over an actual player-level loot action.

And, if you're status isn't high enough, then you can only 'open' the corpse and not actually remove (loot) anything.

This is so that guides can see..but, not touch a corpse's contents.

Uleat, I put my toon in the scenario you referred to, as well as replicating the instance that he is using. (instance list, qglobal, no expire). I set my status to 80 with #gm on and I was not able to loot the corpse. I turned #gm off (while I was still in the instance) and I was able to loot the corpse. Most of the time, when I am testing something, I use a non-gm account, so that's why I was not able to see what he was getting.

t0neg0d 05-04-2019 11:59 AM

Quote:

Originally Posted by Uleat (Post 262398)
By chance...

Did the account that you were using have less than 100 status and you had your GM flag on?


Code:

void Corpse::MakeLootRequestPackets(Client* client, const EQApplicationPacket* app) {
...
        // all loot session disqualifiers should occur before this point as not to interfere with any current looter
        loot_request_type = LootRequestType::Forbidden;

        // loot_request_type is scoped to class Corpse and reset on a per-loot session basis
        if (client->GetGM()) {
                if (client->Admin() >= 100)
                        loot_request_type = LootRequestType::GMAllowed;
                else
                        loot_request_type = LootRequestType::GMPeek;
        }
        else {
                if (IsPlayerCorpse()) {
                        if (char_id == client->CharacterID()) {
                                loot_request_type = LootRequestType::Self;
                        }
...

and

Code:

void Corpse::LootItem(Client *client, const EQApplicationPacket *app) {
...
        if (loot_request_type < LootRequestType::GMAllowed) { // LootRequestType::Forbidden and LootRequestType::GMPeek
                client->QueuePacket(app);
                SendEndLootErrorPacket(client);
                // unlock corpse for others
                if (IsBeingLootedBy(client))
                        ResetLooter();
                return;
        }
...

If you have your GM flag on, that takes precedence over an actual player-level loot action.

And, if you're status isn't high enough, then you can only 'open' the corpse and not actually remove (loot) anything.

This is so that guides can see..but, not touch a corpse's contents.

GM flag was on, but status = 255


All times are GMT -4. The time now is 07:10 AM.

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