When world.movement_mode is set to TILE_MOVEMENT_MODE, Move() fails to properly relocate movables and instead causes a single-tile movement in the direction of the specified atom you're trying to Move() the movable to. LEGACY_MOVEMENT_MODE and PIXEL_MOVEMENT_MODE both operate without an issue, as expected.
Numbered Steps to Reproduce Problem:
1. Set world.movement_mode to TILE_MOVEMENT_MODE
2. Try to use Move() on any movable
3. Movement "fails"
Code Snippet (if applicable) to Reproduce Problem:
http://a.pomf.cat/kreznh.7z
/world
fps = 20
turf = /turf/grass
/*
* When enabled, double-clicking the grass turf will move the mob in the
* direction of the click, and only a single tile
*
* When disabled, the expected Move() functionality occurs and the mob
* is placed at the location of the grass turf which was clicked
*/
movement_mode = TILE_MOVEMENT_MODE
/*
* I just wanted to test PIXEL_MOVEMENT_MODE, it doesn't appear to share this issue.
*
/world/movement_mode = PIXEL_MOVEMENT_MODE
/atom/movable/step_size=4
*/
/turf/grass
icon = 'grass.dmi'
New()
. = ..()
// Different dir states so it's easier to see where movement occurs
dir = rand(1,12)
DblClick()
usr.Move(src)
/mob/icon = 'player.dmi'
/*
* This test shows the Move() issue affects movables, not just /mob
* You can set the values add/subtracted from x/y to any amount, the test obj
* will still only move a single tile, but in the proper direction.
*/
/mob/verb/testObjRelocation()
var/obj/test = new(loc)
test.icon = 'test.dmi'
var/turf/grass = locate(x-4, y-4, z)
test.Move(grass)
Expected Results:
Move() relocates a movable to any specified atom when TILE_MOVEMENT_MODE is enabled.
Actual Results:
Move() moves a movable by a single tile in the direction of the atom when TILE_MOVEMENT_MODE is enabled.
Does the problem occur:
Every time? Or how often? Every time.
In other games? Yes, as far as I can test/tell. It happened in both my test environment and my game environment (where I discovered it after an hour of debugging.)
In other user accounts? Didn't test, but reason assumes yes.
On other computers? Didn't test, but reason assumes yes.
When does the problem NOT occur?
When not using world.movement_mode = TILE_MOVEMENT_MODE
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Tested 514.1543: not working as expected
Tested 514.1547: not working as expected
Since neither of those worked I stopped testing there, I assume it's just a fault of the feature itself not anything done after-the-fact. I also updated to 514.1557 and it's still present.
Workarounds:
Don't use world.movement_mode and instead just ensure step_x/y aren't ever used if preserving tile movement is critical.
