turf/tournament
Grass
icon = 'Tounament.dmi'
icon_state = "b"
density = 0
Bump
usr.loc = locate(2,2,1)
Problem description:
Tournament.dm:16:error:usr.loc:undefined var
ID:144232
Feb 15 2007, 2:04 am
|
|
Code:
turf/tournament Problem description: Tournament.dm:16:error:usr.loc:undefined var |
Feb 15 2007, 2:05 am
|
|
And yes i did read the DM guide but i don't get it
|
In response to Shomone
|
|
Bump()
|
In response to A.T.H.K
|
|
turf/tournament Tournament.dm:15:error:Bump :undefined proc |
In response to Shomone
|
|
turf/tournament This may work I suggest using Enter() rather than Bump() with turfs. - Miran94 |
In response to Shomone
|
|
Whoa! You REALLY need to read it again. And not skim it, mind you. Also read threw the DM Reference.
|
Shomone wrote:
Code: > turf/tournament Problem description: Ok, there are quite a few things wrong with that. First off, you can't bump an object that is not dense (density=0). Secondly, processes have () following there name. In this case, those parenthesis would contain the object that was bumped into. Which brings us to the third item: Bump() is called by the object doing the bumping, not the object that was bumped into. This is the cause of your later "undefined proc" error, as, since turfs cannot move, they do not have a Bump() process to begin with. Miran94 wrote: > turf/tournament This may work I suggest using Enter() rather than Bump() This was much closer, but there is still one major flaw in it: any type of moving object can call Enter(), which could result in a bunch of monsters running around the arena. Also, to save time, you could switch "O" with "atom/movable/O", allowing you to change their location without defining another variable. Here's an example: turf/tournament Also, to the original poster, make sure you switch "/mob/player" with whatever type you want to allow in. |
In response to DarkCampainger
|
|
And, such things absolutely belong in Entered(), not Enter(), which needs to just deteremine whether movements are allowed or not, and so may also be manually called for such checking.
|
In response to Kaioken
|
|
Yea, I though about that, but then changed my mind. If you use Entered(), then the best way to stop things from blocking the entrance would be to set their location to the old location. Otherwise someone could push a barrel into it or a monster might stand there and block it (You know how step_rand() tends to make AI's do evil things...) Enter() takes care of it more easily. Although I'm almost tempted to just set Enter() to allow players in, and then move the actual changing location part under Entered().
I guess it all depends on how the rest of his game works. If there's only one of these at the end of a narrow corridor, then he's going to want to prevent blocking. But if he lines a bunch of them up to make a huge door, then he could do whatever he wanted. |
In response to DarkCampainger
|
|
Correct; however you're possibly missing a bit. Thats why you use both: for instance, Enter() to only allow /mob/player's, and Entered() to re-locate them, which IS the safest and most correct and you've err, weirdly enough, already stated it in you post.
Again, it's simple: Enter(),Exit() -- only calculate whether entrance/exitrance (:D) should be allowed and correspondingly return either 0,1 or the parent/default action (return ..()) Entered(),Exited() -- HERE do actions that should be triggered when entering/exiting the location. |