area/no_monsters/Entered(mob/M) //is a mob entering?
if(istype(M,/mob/monsters)) //is it of that category?
return //...then dont enter!
Problem description: /mob/monsters can still walk PAST that barrier...
ID:264024
 May 11 2008, 5:05 am
|
|
Code:
Problem description: /mob/monsters can still walk PAST that barrier... | |
Entered() is called when something successfully enters the area. Enter() is when something tries to. You can't keep them from entering if they already have.
| |
It's worth to mention that this quickie method will won't work with certain cases like turf/Enter(), and isn't as robust as it can get. For this case though, it does indeed get the job done.
| |
It's not a robust method, and it should be remembered that it won't work properly for turfs; I've seen it used with them around the forums before.
| |
Enter() for turf works the same as Enter() for area. There's no reason it wouldn't work. To add to this, what that code does does exactly what he wants, and it won't cause an error unless istype() throws out an error for non-object tests, which should never occur anyways as Enter() should never be soft-called. I fail to see why it neither robust nor proper-working for turfs.
| |
Popisfizzy wrote:
Enter() for turf works the same as Enter() for area. No, it doesn't. turf/Enter() handles (by default) density implementation as in not allowing more than 1 dense object in a single tile. area/Enter(), I believe, does nothing by default (just returns 1). Therefore if you override turf/Enter() (for more robustness you would do it with all Enter()s, really) you should return the default/parent value instead of returning 1 straight, which for our example in turf/Enter() will bypass the default movement rules and partly break the movement system. There's no reason it wouldn't work. To add to this, what that code does does exactly what he wants, I explicitly said that, too. I fail to see why it neither robust nor proper-working for turfs. That get-it-done-quickly-all-in-1-line method does not call the parent/default procedure, which causes both (for turfs, read above). | |
Ah, yes, I did forget about that. A single-line proc would still work for turfs, though. For a simple check like this, it's not really difficult.
turf/noentry4monster/Enter(mob/monster/m) return !istype(m) && ..()
| |
I would like to point out at this point that at no point do you score points for writing compact code. The point of making posts here is to help people, and it's pointedly difficult for people new to the language to point at something like that and say what it does.
Honestly, I think you're just missing the point. | |
I didn't think of that earlier in this thread, but I definitely agree with you here, that's an important point to make. Not that you should keep the newbies entirely away from the faster, slightly harder to understand methods; but you should definitely comment the code and explain it detailedly (as needed) under it. Ideally, and what I prefer doing because it's also easier to understand to the newbie and explain to him, is first teaching the 'basic/"normal' "roundabout" way of doing it, then mentioning under it the fact you can shorten it by using a certain "trick" and explaining it (for this case, the 'normal method' would be-)
area/no_monster/Enter(mob/M) //override the default Enter() proc for this area | |
area/no_monster/Enter(mob/monsters/m) return !istype(m)