bugWarmux - Bugs: bug #15034, Dropped box get stuck and is never...

 
 
Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #15034: Dropped box get stuck and is never able to complete it's fall.

Submitted by:  Florian Köberle <iflo>
Submitted on:  Fri 01 Jan 2010 10:03:15 PM UTC  
 
Category: PhysicsSeverity: 3 - Normal
Priority: 1 - LaterStatus: None
Assigned to: NoneOpen/Closed: Open
Release: 

Thu 14 Jan 2010 11:12:09 PM UTC, SVN revision 7276:

Remove wind_factor of boxes as workaround for bug #15034.

(Browse SVN revision 7276)

Florian Köberle <iflo>
Project Administrator
Thu 14 Jan 2010 10:04:19 PM UTC, comment #3:

To me it looks like the main problem is that FootsInVacuum() doesn't detect in advance that the box will collide.

With the new bullet branch we will not have such a problem.

If we don't switch to bullet I have the following suggestion of how we could try to fix the bug:

We introduce a new flag with the meaning "colliding with ground". That flag gets set to true at the first collision with the ground and gets set to false at the next physics frame without a ground collision. This flag would replace FootsInVacuum in it's function.

Of course this is a huge change and we might don't need to fix it anyway when we switch to bullet. That's why I suggest to let this bug open until we know for sure if we switch to bullet or not.

As the bug is really annoying when it occur I will commit a patch which will remove the wind factor from boxes. This way they will always collide from top with the ground and not from the side. At least for the initial drop. This doesn't fix the bug completely as the box can get still accelerated by explosions. Additionally this bug might affect other objects and characters as well.

Florian Köberle <iflo>
Project Administrator
Thu 14 Jan 2010 09:38:53 PM UTC, comment #2:

The bug occurred again for me. This time it was a medkit falling down and the wind was blowing strongly to the right.

The following happens in a loop:
------------------------------------------
1.) MainLoop call:
PhysicalObj::UpdatePosition of the medkit gets called:
GetPosition() = {x = 2602, y = 1300}

IsMoving() == false
FootsInVacuum() == true -> It gets checked that there is no pixel in the green area of the attached image.
StartMoving() gets called

RunPhysicalEngine gets called:
m_last_move is 20 ms larger then m_last_physical_engine_run
m_last_physical_engine_run gets set to m_last_move;
delta_t is 0 and the loop gets skipped.

2.) MainLoop call:
PhysicalObj::UpdatePosition of the medkit gets called:
PhysicalObj::UpdatePosition
GetPosition() = {x = 2602, y = 1300}
IsMoving() == true
FootsInVacuum() == true

RunPhysicalEngine gets called:
m_last_physical_engine_run and m_last_move have the same value
delta_t = 0.02;

first and only iteration:
oldPos = {x = 65.06247822318764, y = 32.4962054927636}
newPos = {x = 65.062699223187636, y = 32.510605492763602}
at NotifyMove call is the position already {x = 2603, y = 1300} !

after the multiplication with PIXEL_PER_METER:
oldPos = {x = 2602.4991289275058, y = 1299.8482197105441}
newPos = {x = 2602.5079689275053, y = 1300.4242197105441}

lg = 0.57606783072830625
offset = {x = 0.015345415119488372, y = 0.99988225218513127}
tmpPos = {x = 2603, y = 1301} -> one pixel down and right!
IsInVacuumXY(tmpPos, false) returns false. See red area in the attached image.

collision = COLLISION_ON_GROUND;

SetXY(2602.4991289275058, 1299.8482197105441);

GetPosition() returns {x = 2602, y = 1300}

speed_before_collision = {x = 0.011050000000000001, y = 0.71999999999999997}
------------------------------------------

Finally I ran the following gdb command
print SetXY(pos)
right after the execution of "SetXY(Point2d(pos.x - offset.x, pos.y - offset.y));".

This broke the loop and the game continued until it's end.

(file #7677)

Florian Köberle <iflo>
Project Administrator
Sat 02 Jan 2010 02:33:09 PM UTC, comment #1:

After about 15 minutes I were able to reproduce the bug:
It got triggered when I threw a 1s footbomb near a stack of boxes.

One medkit was constantly calling the method CloseParachute() which made the sound. It got the speed from constant collisions with a bonus_box. The bonus_box got it's speed from gravity and wind. The medikit was at {x = 2766, y = 1120} and the bonus_box at {x = 2773, y = 1121}! In other words: The medikit was above the bonus_box and wasn't falling while the bonus box under it was falling.

(file #7591)

Florian Köberle <iflo>
Project Administrator
Fri 01 Jan 2010 10:03:15 PM UTC, original submission:

A box dropped and get then somehow stuck in the terrain. The collision sound was playing then in an infinite loop and the turn did not end.

I observed this bug twice. It happens very seldom. I tried to make a map where I hoped that the bug would occur more often: A map with a lot single pixels or lines floating in the air. Even with a a forced drop rate of 1 box per turn I could not reproduce the bug.

To get the higher drop rate I started the game with -d box.

Florian Köberle <iflo>
Project Administrator

 

Attached Files
file #7677:  box_bug.png added by iflo (394B - image/png - Zoom in for details 1px in the image is one pixel of the map.)
file #7591:  other_objects_movement.txt added by iflo (5kB - text/plain - How the bonus box's position, speed and acceleration change over time(y only).)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by iflo (Submitted the item)
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 14 Jan 2010 09:38:53 PM UTCifloAttached File-=>Added box_bug.png, #7677
    Sat 02 Jan 2010 02:33:09 PM UTCifloAttached File-=>Added other_objects_movement.txt, #7591
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup