ID:1656096
 
BYOND Version:506
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Firefox 31.0
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Purely graphical, 100% reproducible client-side error.

When a Mob moves using pixel movement (as a Jump) from a Turf to a Room (an Area off of the map) and vice versa, the Dream Seeker client is never updated of the step_x and step_y change to 0. Thus, when exiting a Room, step_x and step_y will appear to be unchanged from when the Mob entered the Room, although Dream Daemon will know the true value and reset it upon moving.

Numbered Steps to Reproduce Problem:
*) Optional: Download and open the pre-packaged project file from http://www.byond.com/developer/Agorako/RoomBug
1) Move your character away from the center of the Turf, using pixel movement (changing step_x, step_y).
2) Use the "enter" verb to enter the Room.
3) Use the "leave" verb to return to the Turf at 1,1,1.

Code Snippet (if applicable) to Reproduce Problem:
mob
bound_x = 12
bound_y = 12
bound_width = 8
bound_height = 8
step_size = 2
mob/verb/enter()
usr.Move(locate(/area/room))
area/room
Entered(atom/movable/O)
O<<"You are now in the room."
Exited(atom/movable/O)
O<<"You have left the room."
verb/leave()
usr.Move(locate(1,1,1))


Expected Results:
After completing the Jump, the Mob should appear centered on their Turf.

Actual Results:
After completing the Jump, the Mob appears offset in the same way they were before entering the Room, but only client-side. Resets upon movement.

Does the problem occur:
Every time? Or how often? Every time.
In other games? Nobody uses Rooms. :(
In other user accounts? Yes.
On other computers? Yes.

When does the problem NOT occur?
When moving normally from Turf to Turf, instead of Turf to Room or Room to Turf.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
This problem only applies to pixel movement, therefore it did not exist before step_x and step_y did.

Workarounds:
The only known workaround is to override Move and intentionally offset step_x or step_y by a pixel when leaving a Room is detected. This is undesirable because it still leaves the resulting position visually offset, although far less so than the extremes it could wind up as otherwise.