ID:179714
 
I know how to make things move between maps, but i have a small problem here.
Here's one of my teleport code:

turf/town
bluedoor
icon = 'town.dmi'
icon_state = "bluedoor"
Enter(mob/M)
..()
M.Move(locate(/area/house))

Now let's say i have a lot of these "bluedoors" in town, how do i change the location of the teleport without changing the icon state?

Cravens wrote:
I know how to make things move between maps, but i have a small problem here.
Here's one of my teleport code:

turf/town
door
icon = 'town.dmi'
icon_state = "door"
Enter(mob/M)
..()
usr.Move(locate(/area/house))

Now let's say i have a lot of these "doors" in town, how
do i change the location of the teleport without changing
the icon state?


Change the name of the icon and have a tag for each location :)

Lee
Cravens wrote:
I know how to make things move between maps, but i have a small problem here.
Here's one of my teleport code:

turf/town
door
icon = 'town.dmi'
icon_state = "door"
Enter(mob/M)
..()
usr.Move(locate(/area/house))


There's a small problem with this code you're not actually warping anything. You should try changing usr.Move to M.Move.
In response to Mellifluous
Sorry, i don't understand.
Do i have to change the icon's name or the icon_state's name ?
Also, do i have to change the tags on the turf's instance on
the map ?

What i want is to have the same type of door on all houses but they each teleport to a different area, not the same.

THX.
In response to Nadrew
Actually, usr and M are almost 100% certainly the same thing... M.Move is just a teeny bit more precise.
What does the icon_state have to do with anything???
Cravens wrote:
I know how to make things move between maps, but i have a small problem here.
Here's one of my teleport code:

turf/town
door
icon = 'town.dmi'
icon_state = "door"
Enter(mob/M)
..()
usr.Move(locate(/area/house))

Now let's say i have a lot of these "doors" in town, how
do i change the location of the teleport without changing
the icon state?

Lexy's answer is the correct one: Teleporting shouldn't affect icon_state in any way unless you want it to. If you mean how do you tell where each door should lead, that's a little different.
I suggest something a little different:
turf/town/door
icon = 'town.dmi'
icon_state = "door"
var/atom/destination=null
var/destination_tag=null

New()
if(destination_tag)
destination=locate(destination_tag)

Entered(atom/M,oldloc)
..()
if(destination && oldloc!=destination) // prevent loops
M.Move(destination)

Enter() should still be overridden to check whether or not you can enter a turf, like if someone is standing on the other side of the door. I didn't do that in case you want to make another doorway a valid destination (in which case, Enter() would end up in an infinite loop). If doorways only ever teleport to non-doorways, it should be feasible to add this code:
  Enter(atom/M)
if(!..()) return 0
// never let destination be another doorway, or you have an infinite loop!
if(destination) return destination.Enter(M)
return 1

Without that, M.Move() will fail if the destination is blocked, but you'll still be able to step on the doorway--nothing will happen. Another potential caveat: If you have the destinations set up so one doorway teleports to another one, and someone is blocking your path when you get to the other side so you can't leave the doorway, you're stuck. Because of this, you may want to override movement routines in general so that if you're in a doorway, any unblocked turf from either end (but preferably your current end) is a valid destination. However, an easier workaround is to make the destination just beyond the doorway, not the doorway itself.

Lummox JR
In response to LexyBitch
Not so! If a mob verb causes another mob to move (say a Shove() verb), usr will be quite different from M once Enter() gets called.

To extend my example to this case, if you shoved someone into a bluedoor, you'd get teleported instead of the shovee.

-AbyssDragon
In response to AbyssDragon
What are the odds that this guy has coded a Shove() verb? I'm betting that he has nothing but default movement and this half-working teleport code... I'm not saying he shouldn't use M.Move, but Nadrew is wrong in saying that "nothing" will warp.
In response to Lummox JR
woah.. I read it a couple of times and still don't
understand. That's why im still a n00b here though.
Anyways, i tried putting the code in and there's seems to be a Bad proc with M.Move().
Any idea ?
In response to Cravens
Cravens wrote:
woah.. I read it a couple of times and still don't
understand. That's why im still a n00b here though.
Anyways, i tried putting the code in and there's seems to be a Bad proc with M.Move().
Any idea ?

Ah. Change atom/M to atom/movable/M.

Lummox JR
In response to Lummox JR
Ok, the proc works now, but what i need is an example
with this code. This is still a bit complex for me.
I want to know what to change to make all this work.

What i want is to have the same type of door (let's say a turf called town/bluedoor) for all the houses but they all lead to different AREAs (each door leads to a different room).
I can do this by making a lot of areas, but i want to avoid that. If there's an easier way to code this, for example with the turf's instance, i would like to know.

THX.
In response to Cravens
I dont know exactly how you would but i just thought up a pretty good way..

Most people do

turf
door
Entered()
usr.x = bleh
usr.y = bleh
usr.z = bleh


BUT (call me crazy) i just thought of a way..

try somethin like this:


mob/proc
Enterdoor()
if(istype(src, /turf/door1))
usr.Move(locate(1,2,3))
if(istype(src, /turf/door2))
usr.Move(locate(3,2,1))
turf
door1
src:Enterdoor()
turf
door2
src:Enterdoor()


hehe.. i know im crazy. play with it though..
REMEMBER: I just thought this up as i was typing :D


hope i helped..


-Rcet

In response to Cravens
Well... I'm not sure if there's any real "easy" way to do it... But I think that a possible solution would be to define multiple turfs that use the same icon(s)...

Something like the following:

turf
bluedoor1
icon = 'bluedoor.dmi'
Enter()
//stuff to move them to whatever area this
//particular turf will lead to

bluedoor2
icon = 'bluedoor.dmi'
Enter()
//See above

Etc...

Then all you have to do is keep them all straight and place the right turf on the map at the right point...lol

Another possible way (depending on how your maps are set up) would be to just have the movement defined in terms of their current x,y,z coordinates...

Like so:

turf
bluedoor
icon = 'bluedoor.dmi'
Enter()
src.loc = locate(x,y,z+1)

That way...depending on where the original turf was...they will be whisked away to that same x,y coordinate on the next z level... You've just got to make your maps coincide with each other...

Hope I've been of some help...
In response to SuperSaiyanGokuX
I do mine like this:

turf
bluedoor1
icon = 'bluedoor.dmi'
icon_state = "bluedoor"
Enter()
usr.x = 1
usr.y = 1
usr.z = 1
bluedoor2
icon = 'bluedoor.dmi'
icon_state = "bluedoor"
Enter()
usr.x = 2
usr.y = 2
usr.z = 2
bluedoor3
icon = 'bluedoor.dmi'
icon_state = "bluedoor"
Enter()
usr.x = 3
usr.y = 3
usr.z = 3


That should do it for you, also, look on how it is constructed, rather simple to people who use it alot, but to newbies (which I still am) can be rather difficult to get a grip of.

I hope you get to know how this works from just looking at it.

Lee
In response to Cravens
Cravens wrote:
Ok, the proc works now, but what i need is an example
with this code. This is still a bit complex for me.
I want to know what to change to make all this work.

What i want is to have the same type of door (let's say a turf called town/bluedoor) for all the houses but they all lead to different AREAs (each door leads to a different room).
I can do this by making a lot of areas, but i want to avoid that. If there's an easier way to code this, for example with the turf's instance, i would like to know.

The way to use the code I provided would be to set a tag for the destination turf, then set the door's destination_tag to that same value. You'd do this in the map editor.

Lummox JR
In response to Mellifluous
I got it working, and it was easier than i thought...
I tried those ideas before and it didn't work.
Now it does. :P

THX.
In response to Cravens
Cravens wrote:
I got it working, and it was easier than i thought...
I tried those ideas before and it didn't work.
Now it does. :P

THX.

Your welcome :)

Lee
In response to Cravens
Cravens wrote:
I got it working, and it was easier than i thought...
I tried those ideas before and it didn't work.
Now it does. :P

THX.

Congrats!

That's the difference between trying to implement code before and after you are able to understand it. Once you start grasping the basic concepts, the rest is easy.