 |
bouncetest.pk7 (2,081,836 bytes) |
|
|
By the way, the actor in question is FragGrenadeX. |
|
|
Haven't been able to reproduce it yet. |
|
|
Striker, please record a lmp demo with the problem and attach the compressed zip here. |
|
|
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. |
|
|
Either way, here's a demo, use the PK7 and GZDoom 2.3.2 x64. bouncebug.lmp (2,160 bytes) |
|
|
Is this perhaps similar to the issue that I reported not too long ago on the forums? |
|
|
Don't know, got a link to the thread? (BTW, I posted the demo above) |
|
|
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. |
|
|
No idea. I'll have to debug the demo to say. |
|
|
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. |
|
|
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: |
|
|
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. |
|
|
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: Also, in P_BounceActor: 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: 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. |
|
|
No guarantee that changing that part is going to work without unwanted side effects, the entire bouncing code is a total clusterfuck beyond repair. |
|
|
https://github.com/coelckers/gzdoom/commit/1eb2c753288a8baf61535aed4c5d25f39013de7e#commitcomment-20642353 Just a suggestion to make things cleaner. |
- Anonymous
