ID:1180748
 
Keywords: pixelmovement
Not a bug
BYOND Version:498
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Firefox 19.0
Applies to:DM Language
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:

Say for instance, you have defined pixel movement variables under mob/Player as such:

mob/Player
step_size = 8
bound_x = 8
bound_y = 0
bound_width = 16
bound_height = 25


The second this mob joins or loads into the game, all /mobs in the world will have their gliding disabled and replaced with this ugly jumpy movement, even if their settings/Move() function is untouched.

It goes even further. In my example I'm saving the whole mob in one go, and upon changing the above code (or simply removing it / commenting it out), then load in, the values for my mob will have changed and I will move like I normally would without pixel movement. HOWEVER, all the other mobs in the world will still be affected. Deleting my personal save and rebooting the world, then creating a new character (with the same values as the deleted one) will work fine for the other mobs.

Numbered Steps to Reproduce Problem:

1) Create a mob/Player with pixel movement
2) Look how every mob in the world, including those other than mob/Player get affected with the pixel movement system
3) Save the mob
4) Enter the world without loading the mob, look how everything is moving fine
5) Load the Player, watch how movement starts spazzing out

Now for the changed values still activating pixel movement:

1) Still using the same Player mob, shut down the world and delete / comment out the pixel movement variables in the code
2) Enter the world without loading the mob, observe how everything is going fine
2) Load the mob again, notice how its movement is back to tile-movement
3) Observe how the other mobs are, again, going spastic

Code Snippet to Reproduce Problem:

The above snippet is what I used for the pixel movement, loading/saving of the client mob goes
F["mob"] << mob


NPCs or mobs other than client mobs do NOT get saved anywhere.

Expected Results: Player uses pixel movement, mobs don't

Actual Results: Everyone uses pixel movement.

Setting the mob/Enemy's vars to
mob/Enemy
step_size = 32
bound_width = 32
bound_height = 32
bound_x = 0
bound_y = 0
glide_size = 0


Does not help nor change anything regarding Enemy movement.
This is not a bug. BYOND is either entirely pixel movement or none at all. The moment you create anything using the pixel movement variables you toggle a flag that tells the system you're using the new movement system.

It's a limitation that ended up being required due to how the system had to work. Your best bet is setting the variables for everything properly or not using them at all.
Nadrew resolved issue (Not a bug)
The limitation in question wasn't strictly necessary, but was a design decision based on the fact that we were getting bug reports about pixel-movement mobs messing up other mobs when they moved, by accidentally imparting pixel offsets. We decided the whole thing was simpler to handle on an all-or-nothing basis.

There is a way to avoid the problem of loading a mob with pixel coords. That is to read the savefile and remove any references to step_size, step_x, step_y, and bounds, before loading the whole mob.
Yeah, saw your post about that when searching about this. The snippet didn't work 100% (savefile/F, F.Remove() doesn't work, F.dir.Remove() does works but throws invalid argument exception. Weird)

The real issue at hand here, the one that would fix everything for me personally, is getting the Enemy's to move at a step_size of 32 (which happens), BUT still have the glide effect instead of the "jumpy" effect. Any way to do that?