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