turf click teleport / flash step ( bleach)

ID:159141
 
May 3 2009, 11:08 am
k so u click the screen then u teleport where ever u click.
how do i do that?
May 3 2009, 1:39 pm
Simple.

client
    DblClick(O as obj)//Name of the proc, DblClick stands for double click. Wherever you double click, you are teleported to. You can change it to "Click" if you only want to click once to teleport to the area.
        usr.z = O:z//Teleports you to the clicked area's Z coordinate.
        usr.x = O:x//Teleports you to the clicked area's X coordinate.
        usr.y = O:y//Teleports you to the clicked area's Y coordinate.


May 3 2009, 1:44 pm
In response to Forerunnerz
*cough*
turf/Click()
   ..()
   usr.loc=src
May 3 2009, 1:50 pm
In response to Kaiochao
Kaiochao wrote:
*cough*
> turf/Click()
>    ..()
>    usr.loc=src

There's a neater code and takes up less space. Don't use mine. I just changed it in my project. Thanks Kaiochao.
May 4 2009, 10:20 am
In response to Forerunnerz
To be honest, setting loc directly shouldn't be done (on its own), either, for common purposes. You should always use Move() (or another proc that calls Move()) or a custom proc that is similar to Move()* so that the movement system is alerted to the movement taking place, and the hooks are called. Not doing is un-robust and can break a game's functionality (that relies on BYOND's default movement system).
For (one) example, if you've restricted entering an area via that area's Enter() proc, the above Click() override will ignore it (as it just moves the obj and doesn't check anything) and will immediately relocate the obj to that area.

*: This should be done f.ex. when you don't want it to be possible for the movement to fail; such a proc will ignore Enter() and Exit(), but will properly call old_loc.Exited() and new_loc.Entered() (most often twice each; once for the newloc and and one for its area).
May 7 2009, 5:39 pm
In response to Kaioken
Kaioken wrote:
To be honest, setting loc directly shouldn't be done (on its own), either, for common purposes. You should always use Move() (or another proc that calls Move()) or a custom proc that is similar to Move()* so that the movement system is alerted to the movement taking place, and the hooks are called. Not doing is un-robust and can break a game's functionality (that relies on BYOND's default movement system).
For (one) example, if you've restricted entering an area via that area's Enter() proc, the above Click() override will ignore it (as it just moves the obj and doesn't check anything) and will immediately relocate the obj to that area.

*: This should be done f.ex. when you don't want it to be possible for the movement to fail; such a proc will ignore Enter() and Exit(), but will properly call old_loc.Exited() and new_loc.Entered() (most often twice each; once for the newloc and and one for its area).

What?? lol
May 7 2009, 6:43 pm
In response to Ceo4eva
Let me try and put it in words you can understand...

Let's say there is a castle with a huge gate in front of you.

Using Move() is like you walking towards the gate and entering.

Changing the src/usr.loc manually, is like being teleported directly inside the castle, without walking towards the gate.

^That might sound like changing loc is better than using Move().. but, let's say you gain 10000000000000 exp points when you pass under the gate. Changing the loc manually won't give you the boost because you didn't enter the gate, you teleported, and the wizard that was gonna give you the boost didn't see you, so you just lost a lot of levels.

Understand? :D
May 8 2009, 12:42 am
In response to Ruben7
I understand, but can move() be used as flash step?
May 8 2009, 5:22 am
In response to Ceo4eva
Yes. Move() just gets through all the procs and checks and whatnot, whereas locate() will just instantly spawn the mob wherever.
May 8 2009, 6:10 am
In response to Ruben7
Ruben7 wrote:
Using Move() is like you walking towards the gate and entering.

I'm not sure if you did understand that or not, but Move() doesn't really do any walking. It's just for moving an object, once. It's used for a single, discrete movement, so it's the same as setting loc in that regard, effectively a teleport.
If you don't want a teleport-kind-of movement (which admittedly, is more suited for something like a teleportation spell, and not suited to something which isn't teleporting but is just fast movement, like a flash-step) you shouldn't call a direct, single Move() to the final destination, as that will just teleport the object there. Even if it all happens in a single tick with no delay, you should attempt to gradually move the object tile-by-tile until he gets to the destination (of course, using Move() for each step) - the walking functions (like walk_to()) do this; this is like walking and not teleporting, so someone wouldn't be able to go inside a totally-sealed-off area if he was moved with this method.

A better example may be this: 
turf/castle
   Click()
      usr.loc = src
   Entered(mob/M)
      M << "You get 1,000 exp for entering the castle!"

The castle turf is programmed to give exp (well, a message) to whoever enters it. When you click on the castle, you're automatically teleported to it. However, because loc is set directly, when this causes you to be relocated to the castle it won't actually call Entered(), and so you won't get any message. It will only be called if you use a proc like Move() there, instead of setting loc: 
turf/castle
   Click()
      usr.Move(src)
   Entered(mob/M)
      M << "You get 1,000 exp for entering the castle!"

This properly gives the player the exp message directly after he clicks the castle and is moved to it.
May 8 2009, 6:13 am (Edited on May 8 2009, 7:10 am)
In response to Mysame
Mysame wrote:
whereas locate() will just instantly spawn the mob wherever.

Eh - you mean setting the loc will just put the mob wherever, while not going through any extra procs. ;P [locate() is unrelated here]
Also, of course, to the eyes Move() is just as 'instant'; there's no delay in the movement (unless you implement one). The thing is it that it may fail however due to a dense destination (and mob) or due to your own Enter() and Exit() rules.

EDIT: Changed phrasing for clarity.
May 8 2009, 7:03 am
In response to Kaioken
I know the player doesn't actually walk, it's all instant. I just meant the action in general.. thing. :s I suck at explaining, sorry.