View Issue Details

IDProjectCategoryView StatusLast Update
0000074Gameplay + OpenGL[All Projects] Bugpublic2018-04-18 00:55
ReporterStrikerMan780 
Assigned ToGraf Zahl 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Summary0000074: Bugged bouncing behavior when Hexen bouncetype projectiles with +BOUNCEONACTORS & limited bouncecount hit actors.
DescriptionIt seems when shooting projectiles with the Hexen bouncetype, +BOUNCEONACTORS, and a limited bouncecount at actors... the projectile will bounce infinitely and never die. This behavior didn't always happen, seemed fine in ZDoom 2.5.0, and builds of GZDoom prior to 1.8.6.

Video demonstrating the bug. https://www.youtube.com/watch?v=wGigvuw3eok
Pardon my awkward way of speaking, was extremely sleep deprived.
Steps To ReproduceA test zip will be attached. Just launch a game, type "give all" in the console, select the frag grenade inventory item, and spam it at some enemies. It'll eventually bug out.
TagsNo tags attached.

Relationships

Activities

StrikerMan780

StrikerMan780

2017-01-19 00:21

reporter  

bouncetest.pk7 (2,081,836 bytes)
StrikerMan780

StrikerMan780

2017-01-19 13:15

reporter   ~0000137

By the way, the actor in question is FragGrenadeX.
Graf Zahl

Graf Zahl

2017-01-20 13:34

administrator   ~0000166

Haven't been able to reproduce it yet.
Edward-san

Edward-san

2017-01-20 13:42

developer   ~0000167

Striker, please record a lmp demo with the problem and attach the compressed zip here.
StrikerMan780

StrikerMan780

2017-01-20 13:48

reporter   ~0000168

Last edited: 2017-01-20 13:48

View 2 revisions

It's easy to reproduce, spam the grenades at the feet of a group of enemies. Might take a couple tries, but it'll work. Use the test PK7.

StrikerMan780

StrikerMan780

2017-01-20 13:56

reporter   ~0000169

Last edited: 2017-01-20 14:03

View 2 revisions

Either way, here's a demo, use the PK7 and GZDoom 2.3.2 x64.



bouncebug.lmp (2,160 bytes)
Major Cooke

Major Cooke

2017-01-21 10:32

reporter   ~0000187

Is this perhaps similar to the issue that I reported not too long ago on the forums?
StrikerMan780

StrikerMan780

2017-01-22 17:01

reporter   ~0000211

Last edited: 2017-01-22 17:02

View 2 revisions

Don't know, got a link to the thread?

(BTW, I posted the demo above)

StrikerMan780

StrikerMan780

2017-01-25 14:04

reporter   ~0000237

Last edited: 2017-01-25 14:07

View 2 revisions

If it was this thread, then I don't think so: https://forum.zdoom.org/viewtopic.php?f=2&t=54637

This bug has existed since GZDoom 1.8.6 at least.

Graf Zahl

Graf Zahl

2017-01-25 14:30

administrator   ~0000238

No idea. I'll have to debug the demo to say.
Graf Zahl

Graf Zahl

2017-01-27 05:30

administrator   ~0000250

The bug is actually on your side. Your grenade contains an endless loop and expects the engine to explode it eventually. But this won't happen if it comes to rest before any of the exploding conditions occurs.

Check Hexen's flechette as a proper example, it contains continuous checks to ensure that the bomb actually explodes.
StrikerMan780

StrikerMan780

2017-01-27 06:50

reporter   ~0000252

Last edited: 2017-01-27 08:00

View 13 revisions

Forget that there is a bouncecount? There's no reason why it shouldn't go into the death state after bouncing more than 4 times. (See the actor's code, it has a bouncecount of 4.)

It just keeps bouncing and bouncing and bouncing and bouncing in place, it never goes to rest, and even plays the bounce sound over and over but it doesn't enter the death state. It's like the bouncecount just gets ignored entirely, or the bouncecount isn't being decremented properly when it should.

Also, keep in mind, this exact actor didn't always behave like this either. I think you're way too hasty in closing this.

I'm almost tempted to say that this:

// The amount of bounces is limited
    if (bouncecount>0 && --bouncecount==0)
    {
        if (flags & MF_MISSILE)
            P_ExplodeMissile(this, NULL, NULL);
        else
            CallDie(NULL, NULL);
        return true;
}
Is going negative or 0 prematurely and never triggering, or something above it is stopping this from executing when it should.

Graf Zahl

Graf Zahl

2017-01-27 08:10

administrator   ~0000253

Last edited: 2017-01-27 08:12

View 2 revisions

It doesnt bounce and bounce and bounce. It lies still, with the only movement being the rotation from the model. And because it's lying still it won't run any more bouncing checks. It apparently stopped moving after LESS than 4 bounces, but that I cannot reliably debug. This can happen if the bouncer's movement is blocked.

There is no auto-explode built into the bouncing code if the bouncing object came to rest prematurely and you have to deal with this yourself.

StrikerMan780

StrikerMan780

2017-01-27 08:19

reporter   ~0000254

Last edited: 2017-01-27 09:17

View 24 revisions

Yes it does bounce repeatedly. I just removed the rotation and it is indeed bouncing forever, and it is still making slight vertical movement (Z velocity never reaches 0), along with doing bouncing checks (the bounce sound is still playing, over and over and over, if the bounce checks were no longer happening, this wouldn't occur). Remember, Hexen bounce projectiles never come to rest unlike the Doom bouncetype.

EDIT: Built from source and ran the debugger in Visual Studio 2015. AActor::FloorBounceMissile and PlayBounceSound are definitely being called when it's stuck in this bounce loop.

EDIT2: Also has the bounce flags still.

It's not just the model's rotation. I'll even record another video if you don't believe me. Heck, just change the MODELDEF in bouncetest.pk7 to this and run the demo:


model FragGrenadeX
{
    Path "Models/projectiles"
    Model 0 "fraggrenade.md3"
    Skin 0 "fraggrenade.png"
    Scale 2.0 2.0 2.4
    ZOffset 3.75

    FrameIndex FRAG A 0 0
    FrameIndex FRAG B 0 1
}

model FragGrenadeX
{
    Path "Models/projectiles"
    Model 0 "fraggrenade.md3"
    Skin 0 "fraggrenade.png"
    Scale 2.0 2.0 2.0
    PitchOffset 90
    ZOffset 3.75

    FrameIndex FRAG C 0 1
}


Also, in P_BounceActor:

if (mo->bouncecount > 0 && --mo->bouncecount == 0) return false;

This looks suspicious.

Seems not all calls to P_BounceActor make the actor explode if it returns false, and there's no checks to prevent it from decrementing bouncecount when inappropriate.

Like this for example, in p_mobj.cpp, line 4193:

                    if (Vel.Z != 0 && (BounceFlags & BOUNCE_Actors))
                    {
                        P_BounceActor(this, onmo, true);
                    }
                    else
                    {
                        flags2 |= MF2_ONMOBJ;
                        Vel.Z = 0;
                        Crash();
                    }



Seriously, did you even watch the video closely (or had sound turned on?) or taken a good look at what's going in the demo and not just give it a passing glance then proceeding with brushing me off? Sometimes I think you do this just to spite me.

Graf Zahl

Graf Zahl

2017-01-27 09:17

administrator   ~0000255

No guarantee that changing that part is going to work without unwanted side effects, the entire bouncing code is a total clusterfuck beyond repair.
StrikerMan780

StrikerMan780

2017-01-27 09:58

reporter   ~0000256

Last edited: 2017-01-27 10:16

View 2 revisions

https://github.com/coelckers/gzdoom/commit/1eb2c753288a8baf61535aed4c5d25f39013de7e#commitcomment-20642353

Just a suggestion to make things cleaner.

Issue History

Date Modified Username Field Change
2017-01-19 00:21 StrikerMan780 New Issue
2017-01-19 00:21 StrikerMan780 File Added: bouncetest.pk7
2017-01-19 13:15 StrikerMan780 Note Added: 0000137
2017-01-20 13:34 Graf Zahl Status new => acknowledged
2017-01-20 13:34 Graf Zahl Note Added: 0000166
2017-01-20 13:42 Edward-san Status acknowledged => feedback
2017-01-20 13:42 Edward-san Note Added: 0000167
2017-01-20 13:48 StrikerMan780 Note Added: 0000168
2017-01-20 13:48 StrikerMan780 Status feedback => new
2017-01-20 13:48 StrikerMan780 Note Edited: 0000168 View Revisions
2017-01-20 13:56 StrikerMan780 File Added: bouncebug.lmp
2017-01-20 13:56 StrikerMan780 Note Added: 0000169
2017-01-20 14:03 StrikerMan780 Note Edited: 0000169 View Revisions
2017-01-21 10:32 Major Cooke Note Added: 0000187
2017-01-21 13:18 Graf Zahl Assigned To => Graf Zahl
2017-01-21 13:18 Graf Zahl Status new => acknowledged
2017-01-22 17:01 StrikerMan780 Note Added: 0000211
2017-01-22 17:02 StrikerMan780 Note Edited: 0000211 View Revisions
2017-01-22 18:25 Graf Zahl Status acknowledged => new
2017-01-25 14:04 StrikerMan780 Note Added: 0000237
2017-01-25 14:07 StrikerMan780 Note Edited: 0000237 View Revisions
2017-01-25 14:30 Graf Zahl Note Added: 0000238
2017-01-27 05:30 Graf Zahl Note Added: 0000250
2017-01-27 05:30 Graf Zahl Status new => resolved
2017-01-27 05:30 Graf Zahl Resolution open => no change required
2017-01-27 06:50 StrikerMan780 Status resolved => feedback
2017-01-27 06:50 StrikerMan780 Resolution no change required => reopened
2017-01-27 06:50 StrikerMan780 Note Added: 0000252
2017-01-27 06:52 StrikerMan780 Note Edited: 0000252 View Revisions
2017-01-27 06:52 StrikerMan780 Note Edited: 0000252 View Revisions
2017-01-27 06:59 StrikerMan780 Note Edited: 0000252 View Revisions
2017-01-27 07:04 StrikerMan780 Note Edited: 0000252 View Revisions
2017-01-27 07:05 StrikerMan780 Note Edited: 0000252 View Revisions
2017-01-27 07:05 StrikerMan780 Note Edited: 0000252 View Revisions
2017-01-27 07:06 StrikerMan780 Note Edited: 0000252 View Revisions
2017-01-27 07:49 StrikerMan780 Note Edited: 0000252 View Revisions
2017-01-27 07:54 StrikerMan780 Note Edited: 0000252 View Revisions
2017-01-27 07:54 StrikerMan780 Note Edited: 0000252 View Revisions
2017-01-27 07:58 StrikerMan780 Note Edited: 0000252 View Revisions
2017-01-27 08:00 StrikerMan780 Note Edited: 0000252 View Revisions
2017-01-27 08:10 Graf Zahl Note Added: 0000253
2017-01-27 08:10 Graf Zahl Status feedback => closed
2017-01-27 08:10 Graf Zahl Resolution reopened => no change required
2017-01-27 08:12 Graf Zahl Note Edited: 0000253 View Revisions
2017-01-27 08:19 StrikerMan780 Status closed => feedback
2017-01-27 08:19 StrikerMan780 Resolution no change required => reopened
2017-01-27 08:19 StrikerMan780 Note Added: 0000254
2017-01-27 08:20 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:21 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:22 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:25 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:26 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:26 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:31 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:32 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:36 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:36 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:38 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:40 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:41 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:43 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:44 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:55 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:56 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 08:57 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 09:05 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 09:05 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 09:07 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 09:15 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 09:17 Graf Zahl Note Added: 0000255
2017-01-27 09:17 Graf Zahl Status feedback => resolved
2017-01-27 09:17 Graf Zahl Resolution reopened => fixed
2017-01-27 09:17 StrikerMan780 Note Edited: 0000254 View Revisions
2017-01-27 09:58 StrikerMan780 Note Added: 0000256
2017-01-27 10:16 StrikerMan780 Note Edited: 0000256 View Revisions