What is the correct usage for $class
 

What is the correct usage for $class? The following are the methods I have tried so far with no luck:

The above mentioned methods have yielded one of three results on item turn in. The quest npc gave back a warrior bracer to a Monk or the quest npc said he didn’t want the item but kept it anyhow or the quest npc did nothing. Is there something I missed because I cannot think of any other ways to represent a characters class.I also tried various uses of $class in () & {} with no useful result.

I think the last time I used it to compare like that, I used something like:

Those are single quotes (like not holding SHIFT while pressing the quote key next to ENTER). I am not really sure why this wouldn't work too though:

Also, I notice that the item IDs you are using are in the 200k+ range. I am pretty sure our item loading is hard set to a max ID of 120K currently unless you manually altered the source code yourself to increase that limitation. If you didn't alter the source for that, then even just creating items with that high of an ID and restarting your server will cause items to fail to load completely.

Yes I am fully aware of the 120k max id when using an unaltered source which is why I altered mine to 500k.
I cannot imagine why using a plain if statement would make any difference as opposed to using if elsif else but I will give it a shot and see what happens.

I didn't mention anything about using an if or elsif or else, I just mentioned the syntax I have used in the past for comparing $class. I think you would just use the following syntax in your script in place of what you have been trying so far:

Though, if you are having 2 classes turn in the same item ID (219592), your script is actually flawed in your logic flow there as well now that I think about it. The problem is that as soon as plugin::check_handin() verifies that the item 219592 matches the turn in, it eats the item, so any ifs or elsifs after that will never work. You must keep in mind that if checks happen from left to right. So, if you want to make sure a certain class is turning in a certain item, then you want to check $class first, not the handin. Generally, the handin is the last thing you ever want to check.

So, your line:
Should actually be

To explain that a bit, if a Monk turned in 219592 with your code, the script that checks for warrior first would result in this:

So, obviously it would move on to the next check, but at that point, the handin plugin already ate the item, so the next one for the Monk check would result in this:

It would be false, because the item is already gone, and as soon as it gets a false, it stops any further checks, so the class check doesn't even get made (not like it would matter).

By switching the checks around as suggested, your first result would be this:

This is because it checked of $class was a Warrior and it was not, since we are using a Monk in this example.

Then, the next check would result in this:

Because the $class is Monk and the correct item was turned in, so it then results in the correct reward.

I should probably add something like this explanation to the Wiki sometime, as I think it would clear up the understanding of why certain scripts don't seem to be working as intended when they actually are. I didn't know this when I first started out, and learning it has helped quite a bit in my script writing over the years.

Good news is using this worked:
While I understand your use of logic flow in this instance it does contradict logic in a way. The point of using && is so that two conditions must check true before the entire statement is declared true. If that were the case then the first elsif should have failed causing the script to move onto the next elsif.
This functioned more like an || where if either condition checks true then the entire statement is true. If that were the case then it should have done as you suggested where the first check was true so the entire statement was declared true causing the entire script to stop.
Using logic like that means you could put two 1’s into a NAND gate and get a 1 out which would defy mechanical logic. Guess this is why mechanical logic and programming logic are very, very different.

Well, the reason it works as I explained is because if it finds a false in the first check, there is no need to go past that unless there was an || (OR) statement after the first check.

If your check resulted in the following:

Then, perl already knew it wasn't going to pass the check by the time it reached the &&, so there wasn't a reason to even bother checking the second one. This logic is good in multiple ways. One bonus is that it saves processing time, as it doesn't need to even bother checking after it reaches a false. Another nice thing about it working like that is that you can check for things that require other things without risking a null pointer zone crash. Here is an example:

So, this will only check if the NPC's target is a client IF the NPC actually has a target in the first place. If you tried to do this:

without first making sure the NPC has a target, you would be opening up a possible zone crash.

Since the example I gave checks for a target first, and then checks if that target is a client, it is safe from crashes. If Perl worked like you thought it did, that example would still be open to crash issues, as it would check both no matter what.

I always had trouble getting the script to work when stating it positively (e.g., if($class eq 'Shaman')), so I ended up stating it negatively (e.g., if($class ne 'Shaman')) in questions like this one.

If you use eq, you should use double quotes and the class must be capitalized.

I guess it doesn't really matter if the logic used is absolute or bendable as long as it can be made to do what we want. To that end, thanks for the help trevius