[trevius]

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:

elsif (false && true) {

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:

if ($npc->GetTarget() && $npc->GetTarget()->IsClient())

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:

if ($npc->GetTarget()->IsClient())

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.