Handin plugin confusion...

[Theeper]

If you run the current plugin inside the emu you'll see the it works perfectly as it is. If you tell it to check for 2 items of the same item ID, by doing 1234 => 2, it will match if you handin the two items unstacked.

I assume the embedded parser increments the value of the handin hash by key before returning it back to the script although I haven't checked.

[Kagehi]

Theeper...

The problem is right here: ($hashref->{$req} != $required{$req})

I don't care what you run your script in, that says, return 0 **if** the number in the hash is not an exact match to the one in required.

There is nothing in that code, and no way it can "increment" anything. And, just to be clear, the client I have been doing the test in can't run Perl without ActivePerl being installed. So why, never mind how, Perl in it should behave differently in it than on the server, is entirely beyond me. Are you sure your not trying it with something that **isn't** using the plugin? There are a huge number of npcs that don't use it, to the detriment to anyone unfortunate enough to hand it the wrong things.

I would love to be wrong, somehow, but I just don't see any possible way I could be, not short of the parser developing artificial intelligence, the server code doesn't something entirely strange, which should be impossible, since it would involve knowing what you where trying to do in this case, or someone having changed the code in your copy of the plugin, so its not behaving the way the version under discussion does. There is no way around it. If you test the value contained in the hash item against the value contained in the requirements, such that if they are != (not equal), it fails...

[Kagehi]

Thanks AndMetal. Unfortunately, without knowing what the structure is, its still not clear what is going on. There are only two possible answers. 1) its eating items, if stacked, or 2) its not storing them the same way as Perl does. I.e., Perl would see them like this:

$hash = (1224 => 2, 1234 => 1)
--internally: hash = table(2,2), where table(0,0) = 1224, table(0,1) = 2, etc.

If the server is doing this:

$item1 = 1224 => 2 --convert--> array(2), where array(0) = 1224, array(1) = 1224, etc.

Then.. It still shouldn't work, since your still checking the "value" of your key, which will be 1 from the server, while its 2, in your handing request. The only way it works at all is if the server is intercepting the call, converting the requests into a list that is *all* 1:1, then testing both against each other. But, this isn't a server call, its a call within Perl itself, which means the server only sees the original items you give the npc, not the requirements list.

I still don't see how Theeper can be right, and the code written as it is. It just shouldn't work with requests for more than one item, "period", no matter what context the Perl engine is running in.

Another reason I suspect he is wrong is simply because, while I have not made a comprehensive check of ever case, I haven't seen a single instance of check_handin used with a "I need more than one of these" check. I'll take a look again, and see if there is though.

[Kagehi]

Ok... Someone please explain to me *why* it works... I did find at least one case where, yes, it does use a multi-item check, but the code, as it stands, doesn't appear to allow it at all.

For example:

cabeast's Master_Raska.pl does use it.

akanon's Sanfyrd_Featherhead.pl however uses the test for the second hand in, with single items, but uses the older method with the first one. Why? If both actually work, then why not change both of them to use the check?

At this point, can anyone confirm for certain what is bloody going on here, and why, if it is working? Not that I don't trust Threeper's word on it, but I can't figure why the same parser, even under two different clients, should produce such drastically different results, with the same code...

[Theeper]

Because you're ignoring what the embedded parser does to the hash.

[cavedude]

Originally Posted by Kagehi

akanon's Sanfyrd_Featherhead.pl however uses the test for the second hand in, with single items, but uses the older method with the first one. Why? If both actually work, then why not change both of them to use the check?

Because many quests were written/pulled before check_handin.pl was even thought of. We try to convert them as we come across them but there are a lot of quests, and sometimes if somebody is just trying to get their work done, they ignore whatever is already in the file and just add their stuff. Either that, or they may not want to break anything, which ultimately, is a good thing.

Because you're ignoring what the embedded parser does to the hash.

That's exactly right. I said it over at PEQ but check_handin.pl does nothing but returns items to the player the NPC doesn't need. Any parsing the plug-in does is simply to return items, not to check if quest objectives are met. The actual parsing of the items is done by the embedded perl parser in the EQEmu code. That's also why stacks don't work. If you try, you get a message saying that you can't trade stacks to a NPC. That isn't the plugin, but rather the Emu code.

To be short, when dealing with single items the plug-in combined with the internal parser works, even when dealing with multiple items with varying amounts. Stacks of course don't work, but that's because the NPC won't even allow you to hand them a stack.

[Kagehi]

Seems to be a misunderstanding on my part by what you mean "internal parser". However, thinking it over, I came to the conclusion that there is one possible thing that could be happening that I didn't think about. Basically, if you dropped the code for the check_handin into one of the npcs, then called it direct, it would fail *exactly* how I described. However, I wasn't thinking in terms of the fact that you are calling it via 'plugins::'. I presume that what is actually happening, since no one seems inclined to explain what the internal parser actual does to it, that if you hand it '1234 => 4', some place **in between** the call in the npc file, and when the call is made to the function in plugins.pl, the server unstacks them. I.e., '1234 => 4' in when in the "look for this" part becomes '1234 => 1, 1234 => 1, 1234 => 1, 1234 => 1"? Meanwhile, the code for actually receiving items sees something like '1234 => 5', and just refuses to even accept them and call item_event in the script?

If this is what is going on, then I really am sorry for arguing my case as I did. I am used to environments where the Perl code is either handing variant types across boundaries without the C++ code touching its contents, or loading the code directly into the existing engine space, so that direct calls are being made, without the scripts host needing to handle it at all.

I wasn't so much ignoring what the parser did, as completely unaware of it, and AndMetal was the only one that came close to providing me with a clue as to what the heck might have actually been going on. And even he didn't know what it *actually* did to the stuff being handed in, or the stuff being checked against.

[cavedude]

I'm trying to find code examples but have been unsuccessful so far (I did find a couple of other gems I needed solutions for, heh) I'll keep looking, though.

I am used to environments where the Perl code is either handing variant types across boundaries without the C++ code touching its contents, or loading the code directly into the existing engine space, so that direct calls are being made, without the scripts host needing to handle it at all.

All of the perl "functions" we use are really just wrappers for the C++ functions. Once the C++ function is written, we then create the wrapper in zone/perlparser.cpp so the .pl scripts have access to it. In the end, it's C++ that is doing all of the work. This may not be the fastest method, but it is very effective for our needs. This situation affords us a powerful scripting language we can use to write quests, without requiring quest writers to know C++ or really, even Perl. I recommend browsing through the EQEmu source, specifically the zone/perl* files to truly understand how the system works.