ID:1859129
 
(See the best response by Lummox JR.)
Code:
mob/verb
Open()
if(usr.x==5)
if(usr.y==18)
if(usr.z==1)
usr<<"You may enter the first door."
usr.x=30
usr.y=30
usr.z=2


Problem description:
Hi, I'm trying to understand that when I do this, for some reason the Open() verb will only work in a (5.5,18,1) to (6.5,19,1) square rather than a (5,18,1) to (6,19,1). Is there something that I'm doing wrong?
Best response
First I would suggest actually making this a turf verb, and only working on that specific turf. Then you wouldn't need the location check. (But for future reference, it's easier to just use the && operator to join all three of those comparising.) Also it's easier to set the new location with usr.loc=locate(30,30,2).

I'm not sure what you mean about the fractional x and y coordinates, though. If this is a situation where pixel movement is involved, remember that the coordinates are based on southwest corner of the icon.
Well the thing is that I was planning on having it one tile under the door, which has a sidewalk tile. To the right of that sidewalk tile is a bush. For some reason, the right half of the sidewalk tile and the left half of the bush is the only area that the Open() verb is working, and this happens in three other places on the map as well. In regard to the ampersand, I tried that and for some odd reason it didn't work. I'll try it again later and see if I get the same error, but first I would like to understand this problem.
I tried using the ampersand again, and went along with
mob/verb
Open()
if(usr.loc==locate(5,18,1))
usr.loc=locate(30,30,2)
And it did work this time around. However the problem is that apparently now instead of shifting the active turf half a tile to the right, it shift the active tile about 9/10 to the right. Now ideally it would make sense to subtract one from the x coord, but I don't think that's the active turf should be anywhere other than where I coded it to be.
The question at hand is: where is the actual southwest corner of your icon? If your character is standing in the middle of the icon space and there's a lot of blank space around them, then the x,y,z coords are wherever the corner of the icon itself falls--not the drawn parts.

Actually if bounds are set correctly, then you can replace if(usr.loc==locate(5,18,1)) with if(usr in locate(5,18,1)). It's a subtle difference, but in pixel movement a mob can be in the contents of more than one turf.

Also, are you certain those turfs are where you think they are? Maybe your numbers are off. You can confirm by adding a Click() proc to the generic turf type and having it output coordinates for you.

turf/Click()
usr << "I am at [x],[y],[z]."
Ah, I never thought about checking it that way. Thanks for the idea! I shall try it later tonight! If it was the icon fault, is there some way to change that? Just rambling off ideas, something similar to text warp or what not? Maybe even change the location of the pixel from the south west to the pixel(s) that the feet are at?
In response to Ash Abe Add
You can use the bound_* variables to control your bounding boxes. Say you had a 16x16 icon centered on a 32x32 canvas:

bound_x = 8
bound_y = 8
bound_width = 16
bound_height = 16


And an easier way of setting the bounds:

bounds = "x1,y1, to x2,y2"


The latter is pretty handy. I only ever use the former when I don't care about accuracy that much.
Ah, but what about doing that bound for the icon instead of the turf?
In response to Ash Abe Add
You can't change the bounds on a turf (it defaults to world.icon_size), only on movable atoms. I think what you want to do is modify the bounds on your mob to fit its actual size.
I would figured that there's something that making it default to have the icon's Southwest position being what mark the unit's location, right? From a good amount of computer science classes, it would make sense that anything with a default has the possibility of changing the code if I use the right keyword. Do you know what keyword I'm looking for? To change the southwest position to being in the center of an unit?
In response to Ash Abe Add
Yeah, I'm pretty sure you want the bound_* variables.