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

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.

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

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

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.

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.

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.

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.

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.

May do that, though my C++ is about 5,000 times worse than my Perl. lol Basically, my total exposure to C++ has been 4 weeks in a class called "current concepts", in which we barely touched on OOP, and that was... 15+ years ago. It was literally the year *prior* to them changing the curricula for Devry to have C++ and Windows as part of the main course work. Instead, it was all heavily based on COBOL, JCL, some vague DOS prompt emulation of *nix, which didn't actually go into any of how the OS did anything. The most advanced thing was the networking class, which I almost didn't pass because a) my lab partner bailed on me to do his stuff during lunch, without telling me, and b) it was using those old Coax systems, where if you fracking sneezed wrong it would fry the transceiver chip on the card... Guess what happened when I tried it, due to the stupid plug not being switched on on the work bench.

Now, VB, Java, Lua, which has a lot of the same neat stuff with arrays/tables as Perl (as of about... 72 hours ago), a smattering of some others, Pascal (from highschool), and of course COBOL 74, those I know, to various degrees, but C++ I never got into because a) it looked like spaghetti to me, and b) I hate trying to debug stuff without decent tools, and the only decent tools for C++ tend to all be expensive, especially if trying to code for Windows, where you also need all the libraries and macros (same dif...) for the APIs.

MS recently crowed about how, "No expert wants to see our code, they just want stable libraries and correct documentation of the APIs." Well, until now I wasn't too sympathetic to this, though mainly due to the fact that MS has *never* produced stable anything, or produced complete, never mind correct, documentation for it. ;) This case has given me some sympathy towards this position. Knowing how the data ends up looking *before* it gets handled by the Perl code would have prevented a long mess of errors, confusion and stubborn insistence that, "It just can't work!!" lol

Hmm. On a side note, I think I dropped this question in some place else, but it didn't get answered. Are globals automatically added to the DB when something sets them, or do they have to be defined *before*, loaded during start up, then get updated automatically some how? I would love to help fix some of the buggy stuff in some quests, especially the Shar Vahl area, including the citizen quest, but the fix requires one NPC, Bindarah, to be able to check in the client has done the quest successfully, in order to recreate the slate you receive from it (which needs to be handed in to other NPCs, who return it, for a lot of the faction quests). A lot of other things are messed up in there, like pathing, some mob spawn locations, the guards and npcs killing encroaching monsters, the fact that one at least in Shadeweaver seems to have a spawn glitch, so they are like 5 copies I have *seen* of him, when there should only be one (no idea how or why that is happening..). Well, its a disaster imho, and most of it I probably can't fix, but with the quest lines also kind of broken, and nothing checking to make sure you are not incorrectly handing in items you *must* have for later quests, its also close to unplayable.

That much, I can probably help to fix some of. The key quest though, will require the use of a global, to determine which part(s), of the main quest you have completed, so you can successfully fix yourself if you do something stupid, like throwing out your slate or cloak, or handing them to something that doesn't want them, and/or doesn't correctly return them (though, I thought there was a 'no-drop' that could be used to prevent the former).

The simple answer is yes. When you set a global variable with the quest::setglobal() command, it is added into the database. Then, when the script runs, it is available with either $global_var_name or $qglobals{global_var_name}.

There is a hard answer? lol

Thanks. Should be easy enough to correct the quest then. Was kind of a major, "Oh frack!". moment when the slate went missing and then I tried to get it back, only to find that the registrar didn't have the code to do so. Obviously, there are some issues with the others too, since they should either be a) correctly resumming items, or b) not accepting stuff they are not supposed to take. Most cases this is just annoying. Shar Vahl made it disastrous.

If the global is checked and isn't defined yet, it'll just throw up annoying errors in the logs, but it won't break the script. But yeah, no need to define them manually (in fact I believe doing so will prevent them from being read properly anyway)

I was meaning to get to the citizenship quest, but if you want to do it, by all means go ahead :)