Descriptive Problem Summary:
Ok so I don't know too much about WHY this happens or how to EXACTLY trigger it, but when I recently learned that I can use bounding boxes larger than 32x32 in my game as long as they were multiples of world.icon_size without breaking gliding, I upgraded my game to use larger bounding boxes for certain things. For example large space ships, which have a 96x96 bounding box.
Everything works fine at first, gliding works. But when a player moves near a space ship and begins colliding with it, seemingly at random gliding will break for every player in the game. I think they have to move around the ship in a certain way, and possibly it requires more than 1 player doing it on the same ship, maybe the ship has to be moving also, I'm not entirely sure because it is hard to replicate.
The game can go hours before gliding will break. I even made a verb that lets me check if any variables related to pixel movement and gliding have changed from their compile time values, and none have.
The space ships have bound_width=96, bound_height=96, bound_x=0, bound_y=0, and they use pixel_x and pixel_y to align their icon with their bounding box, instead of using bound_x/y.
Of course if I set the ship's bound_height/width to 32 at compile time, this bug never occurs.
Any suggestions? Thanks.
Numbered Steps to Reproduce Problem:
With gliding movement on, create an object with a bound_height and bound_width of 64, run your mob around it randomly, possibly while the large object is also moving, and hope this glitch happens, but it seems hard to replicate.
Expected Results:
Gliding should not be broken if all atoms in the game have bounding boxes in multiples of world.icon_size, and none of the variables related to pixel movement or gliding have been changed since run time.
Actual Results:
For seemingly no reason gliding will break despite no pixel movement variables being altered from their compile time values.
Does the problem occur:
Every time? Or how often? At random, sometimes it takes 5 minutes after startup, sometimes 24+ hours.
In other games? I don't know
In other user accounts? Yes
On other computers? Yes
When does the problem NOT occur?
When every atom has a bounding box of 32x32 with no other pixel movement variables altered from their default values.
Workarounds:
None
ID:1564393
 May 2 2014, 10:02 am
|
|||||||||||||
| |||||||||||||
Question: Are you using bounding boxes that do not start at 0,0? I recently made a change to bounding boxes that made tile-based offsets allowed without turning off gliding, but it occurs to me that the normalization routines we're calling may not be equipped to deal with negative bound_x/y. It's possible that step_x/y are being set to a full tile-width value rather than 0,0, and that will still trigger the gliding change.
| |
Ok
It can't be anything to do with loading from save files, or it'd happen at world startup, which is the only time all the player made ships are loaded from any file. Yep I made a verb that would have told me if any step_x/step_y variables had become non-zero. They didn't. I'll make some code that will take 2 ships and run them into each other repeatedly from random angles and see if anything happens. | |
Lummox JR wrote:
Question: Are you using bounding boxes that do not start at 0,0? I recently made a change to bounding boxes that made tile-based offsets allowed without turning off gliding, but it occurs to me that the normalization routines we're calling may not be equipped to deal with negative bound_x/y. It's possible that step_x/y are being set to a full tile-width value rather than 0,0, and that will still trigger the gliding change. No, the code I mentioned earlier would've told me if any atom's bound_x/bound_y became non-zero. They didn't. The only variables that have anything to do with pixel movement and became anything other than their default value are bound_width and bound_height. Which are at 96 each for ships. If I get any results from colliding ships with each other I'll post them. And if I remember right, when I tried to use bound_x and bound_y to center a ship's bounding box with its icon (using multiples of world.icon_size only), it DID break gliding, as you seem to have hinted. So that is why I instead began using pixel_x/pixel_y to just center the icon with the bounding box. | |
Okay, so it looks like I should look into the negative bound_x/y thing regardless, but if you can find any case that reliably breaks gliding, please let me know.
| |
Eu tenho o mesmo problema quando uso bound x ou y
o movimento dos mobs bugam I have the same problem when I use bound_x or y the movement of mobs bugam | |
However, with bounding boxes set at tile multiples I can't think of a specific way for this problem to happen. For gliding to break, that should only come up if step_x/y were set to something other than 0.
Please let me know if you can discover any specific way to reproduce this.