Can you please tell me one more thing , how do you make a turf that npcs cannot walk on ?

Well, Enter() should be Entered(), Death. Enter() is just a proc that returns 1 or 0 if entering is possible. Enterred() is called when the player enters the turf.

I never knew that, thanks.

Two approaches:

1) If all the clients are under one type path, let only one type on to the turf



2) Give the Player's a certain enterable variable.



I prefer approach two because I feel I have more control over what's going on.

[EDIT] No actually I prefer Hell Ramen's method over mine, go for his.

Wizkidd0123 wrote:

I still see no point of the key part... wouldn't checking for a client be better then checking for a key?

np :). The same rule applies when using Exit(), and Exited(), BTW.

As YMI pointed out, our examples don't allow objs to enter either. So

So, let's look at this step-by-step to see how I arrived on this piece of code.

First, we need a turf name, so, why not No_NPCs_Allowed?

Well, that was simple.

Now, we need to prevent something from Entering the turf, so we'd better use Enter().

Just for comprehension:


Enter(atom/movable/X): A proc that returns 1 if X can enter and 0 if not. This automatically takes in the argument of density all by itself.

Entered(atom/movable/X): Something that is automatically called when X enters the turf. This is yours to define.

Now, to understand Enter() and Entered(), one must know that atom/movable is a type consisting of both mobs, and objects, but not turfs. So, mob is derived from atom/movable/mob, and obj is derived from atom/movable/obj. Also, FYI, Exit() and Exited() follow the same rule as Enter() and Entered().

In the above line, we said "Enter(mob/M)". You must be wondering, why the mob/M? (Or, you probably aren't but it's a topic most beginning programmers are confused by). Well, we're using mob/M because we're checking for a variable, mob/client. Since client is a variable belonging to a mob, we need to have access to mob variables, so we're going to include "mob/M" in enter. This is called type-casting.

What's important to realize, however, is that inputting "mob/M" does NOT guarantee that M is a mob. All it guarantees is that "M" represents the atom/movable that is trying to Enter() the turf. Since atom/movable encompasses both mobs AND objects, mob/M could still be an object. Since we don't mind if clientless objects enter, of course, and client isn't an object variable anyway, we come to the next line:



If this if() check returns true, then M is an NPC. Let me explain:

To determine an NPC, we need to check 2 things. We need to make sure that M isn't just an object; that it is truly a mob, and once that is certain, we need to make sure, that of course, M isn't a player character, or a PC. Therefore, we need to check for ismob(M) and if M.client is null.

Now, you'll notice a couple things. You'll notice the use of "&&", and you'll probably notice the eclamation point operator in "!M.client". First, the "!". ! is an operator which basically means "NOT". It is much safer than doing something like if(M.client==0),l because what if M.client is equal to say, null, instead? That's right: 0 and null are to seperate things. So, we could do, , but what a waste of time! Especially when we have an oerator to address this problem, the exclamation point! Instead, we simply type,


Now, unto the"&&" operator. Basically, it means "AND". Let's use the following example:

In the above example, the only way that "You've won!!" will be outputted, is if both A AND B return true. Therefore, if both are false, nothing will happen. If A is true, but B is false, nothing will happen. If B is true, but A is false, then again, nothing will happen. However, if both expressions, A and B, are true, then it will output "You've won!!".

Now, in our coding, the ORDER of the variables is actually important. Why? Because, as with the || operator which we've learned about last time, && uses a method called "short circuiting". That means that && will stop checking at the first bull value it reaches. So, in the above example, if A is false, then it won't even bother to check B's truth value, since either way, the output is the same: nothing.

Our NPC-less turf depends on this "short circuiting" process. To find out why, let's take a look:

Now, why would the order of this matter? Well, it's very simple: if "!M.client" came first, it would output a runtime when an object, not a mob, tried entering our turf. This is because obj/client is non-existant. And if a non-existant variable is looked at, it will output a runtime. Therefore, it's important that ismob(M) comes first, because due to short circuiting, if ismob(M) returns null, client won't be checked.

The rest is pretty straight-forward:

If Enter() returns 0, M won't be allowed to enter. That's simple enough.


This means, that if M is NOT an NPC (It could be an object or a PC), then the default Enter() proc will be called, and it will check for density and everything. We don't want dense mobs allowed into dense npc-less turfs just because they're player characters, do we?

..() is a proc which prevents built-in procs from being over-rided. You should ALWAYS use this unless you specifically want to COMPLETELY override a built-in proc. In turf/No_NPCs_Allowed, we wanted to override it, but only for NPCs. Therefore, on the condition that M is not an NPC, we opted not to override Enter(). As a side note, "..()" should be used in most any built-in proc, including mob/Login(), client/New(), etc...

I hope this helped :)