Strange step() bug

ID:1993402
 
Dec 5 2015, 6:18 pm
BYOND Version:509
Operating System:Windows 10 Enterprise 64-bit
Web Browser:Chrome 46.0.2490.86
Applies to:Dream Maker
Status: Open
Issue hasn't been assigned a status value.
Forgive me for the lack of information, this will have to be more of a query-response kind of report, because I can't reliably re-create this issue outside of my project, but within my project, it happens 100% of the time.

If I don't define step_size, sometimes step(src,dir,1) will instead step you world.icon_size, instead of 1 pixel.

    fireBall
        icon_state = "fireball"
        //step_size = 1
        
        var
            list
                takenDam = new/list()

        New()
            ..()
            dir = owner.dir
            var/turf/T = loc
            if(T.density)duration = 0
            doDam()

        Move()
            .=..()
            var/list/oboundslist = obounds(src,-2)
            for(var/turf/T in oboundslist)
                if(T.density)
                    duration = 0

        update()
            ..()
            step(src,dir,1)
            doDam()


See here, step(src,dir,1), if the object spawns without any associated pixel movement vars assigned that aren't default (ex, if step_x = 0, step_y = 0, and step_size = world.icon_size), even within my pixel-movement enabled environment, it will step world.icon_size pixels. If I uncomment that step_size line, it doesn't do it.

I don't really know what to say.

I want off Mr. BYOND's wild ride.
Dec 5 2015, 9:35 pm
If the step_size is world.icon_size and the object hasn't been setup for pixel movement, walking procs would recognize the object as a non-pixel mover and treat it accordingly. So that makes sense. The parameter used for the walk step size used to be a delay in older BYOND versions, and the behavior still falls back on that for non-pixel worlds.

All that said, it probably makes way more sense to ignore the is-pixel-mover check when the world's gliding has been turned off, and assume all movable atoms are pixel movers.
Dec 6 2015, 9:21 am
Right but the bug here is that I was using step(src,dir,1) which says it should move 1 pixel, whilst in an environment that was fully pixel movement, however it was still defaulting for that individual datum. Surely that can't be intentional.