Handin plugin confusion...

[Theeper]

%itemcount = (59954 => 1, 86010 => 2, 13068 => 1);

This will work fine on the emu. It won't fail if you handin all 4 items seperately.

There may be quests on Live that allow stacked handins, I don't remember ever doing one, but I probably did. I couldn't find one that did accept stacks on Zek last night. I will check the ones you mentioned though.

[Theeper]

The proper syntax to use the plugin is like this though.

if (plugin::check_handin(\%itemcount,59954 => 1, 86010 => 2, 13068 => 1))

[Kagehi]

Originally Posted by Theeper

The proper syntax to use the plugin is like this though.

if (plugin::check_handin(\%itemcount,59954 => 1, 86010 => 2, 13068 => 1))

Umm... That is what I used. The issue here is that while the **server** correctly deals with the '86010 => 2' part, the handin doesn't. The code in the handin, if you turn in, lets say this:

$item1 = (59954 => 1);
$item2 = (86010 => 1);
$item3 = (86010 => 1);
$item4 = (13068 => 1);

will do this:

Is '86010 => 2' found in $hashref? Well, no, its *not* found in there, since the hash only contains '86010 => 1'. Now, if you pass it the same as above, but you pass a stack for $item2, which is '86010 => 2', then handin says, "Yep, that exact key+value combination is in there.", but then the server code says, "No way! Stacks are not allowed."

Hmm. Actually, I think I need to revise things a bit in what I was thinking. If the server is handling the turn in correct, then all I need to do is check if enough has been turned in, the server itself will figure out what is left in the items it needs to return, right? So, a flag in configuration some place can determine if the server's hand in function accepts the stacks, or rejects them. The code in check_handin needs to be less complex than I was thinking. It still needs and adjustment though, since my tests imply that your, "This is the correct syntax.", just does not work at all for the function as its written.

[Kagehi]

Ok. This **seems** to work, after a lot of hair pulling and confusion as to what the frack was going on. Obviously, it should be tested more rigorously than I have. lol

sub check_handin {
  my $hashref = shift;
  my $copy_hash = $hashref;
  my %required = @_;
  foreach my $req (keys %required) {
        do {
	  if (defined $hashref->{$req}) {
	    if ($hashref->{$req} <= $required{$req}) {
	      $required{$req} = $required{$req} - $hashref->{$req};
              delete $hashref->{$req};
	      if ($required{$req} == 0) {delete $required{$req};}
	    }
	    elsif ($hashref->{$req} > $required{$req}){
                $hashref->{$req} = $hashref->{$req} - $required{$req};
	        delete $required{$req};
	    } else {
	      $hashref = $copy_hash;
              return(0);
	    }
	  }
	  else {
	    $hashref = $copy_hash;
	    return(0);
	  }
	} until !defined $required{$req};
  }

Again, if the server where set up with a configuration option is turn off stacks, then this will pass, but the turn in won't work. What happens in that case... Another test might need to be added to this, to make sure that stacks are turned on, before even bothering to do any more checking.

Time to go bounce around the rubber room a bit, and recover from trying to figure this code out in a language that looks, to me, like someone threw cartoon curse words at the screen. !%$%@!^%& = "open a gate to the Pegasus Galaxy", right? lol

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