locs causing choppy movement

ID:1865653
 
Jun 4 2015, 4:37 pm
BYOND Version:507
Operating System:Windows XP Home
Web Browser:Chrome 42.0.2311.152
Applies to:Dream Maker
Status: Open
Issue hasn't been assigned a status value.
I'm not really sure what to make of this one.

After a loong time of debugging, I figured out something strange.

I haven't programmed in BYOND in a while, so I'm assuming the atom.locs variable is relatively new.

I updated my game_del proc to accommodate for this variable:

game_del(atom/a)
        if(!a)
            return

        var/list/built_in = list("type","parent_type","gender","verbs","vars","group","locs")
        for(var/v in a.vars)
            if(!(v in built_in))
                a.vars[v] = null
        del a


When I do this, all my mob's movements JUMP rather than SLIDE.

I tried compiling with different BYOND versions, ripped out all my Move() definitions to get everything stock.

When I remove "locs" from the built_in list, my movement reverts back to SLIDE.

Live debug when I have choppy movement:
FPS = 10
Tick lag = 1
glide_size = 8
animate_movement = 1

I can try to give more information, I figured I'd post this here and maybe somebody else might find this useful. It freaked me out for a good chunk of my day.
Jun 4 2015, 9:03 pm (Edited on Jun 4 2015, 9:14 pm)
On a unrelated note to this, perhaps you want to put that "del a" into a spawn of 4 ticks because if I'm not mistaken you are trying to let this object garbage collect which can take up to that amount of time before it activates.

I don't see in particular how a del proc would break this, but perhaps try also putting animate_movement in your exclusion list.
Jun 4 2015, 9:34 pm
There are some variables which, if you write non-default values to, will force the game into pixel movement mode and disable tile-based gliding.

I don't think locs is the real problem. If you leave it out of the list, the code throws a runtime because locs is readonly, and then bails before it gets to the actual variables causing it. The real problem is that you're setting "bound_width" and "bound_height" to null. Add those to the built_in list and it won't cause the game to switch to pixel movement mode. I would recommend adding all of the new pixel-movement vars to the list:
"locs", "step_x", "step_y", "step_size", "bounds", "bound_x", "bound_y", "bound_width", "bound_height"

That said, manually null-ing out each variable is wasteful if you're going to call del() on the atom anyway. del() will take care of clearing all references to the atom, and do it faster than your softcode. Even if you remove del() and switch to relying on the garbage collector, ideally you could be more careful with references and just clear specific variables instead of plowing through all of them.
Jun 4 2015, 9:38 pm
You shouldn't be using this code snippet. Setting all variables to null is meaningless if you are going to delete the object manually.

You shouldn't even be deleting objects manually.

http://www.byond.com/forum/?post=1549601

^See this thread where I demonstrate that manual deletion should never be done in any scenario. You should be maintaining your references deliberately. You actually get better performance if you let your game leak than if you try to clean it up with manual deletion.

Lastly, this isn't a bug. You are changing bound_width/height to not be a full tile size, thus kicking the world into pixel movement mode.
Jun 4 2015, 9:44 pm
Thanks for clearing that up! I use this snippet mostly because calling del [src] returns my scope and leaves me screwed. The manual null-ing of references is just me and my paranoia.
Jun 4 2015, 9:57 pm
Thanks for clearing that up! I use this snippet mostly because calling del [src] returns my scope and leaves me screwed. The manual null-ing of references is just me and my paranoia.

Seriously, read the thread where I demonstrated that manual deletion of 1 million objects can take hours, while dereferencing and letting 1 million objects be garbage collected takes 3.4 seconds.