T3D 1.1 Preview - Projectiles disappearing instead of exploding - RESOLVED

#21 This is on the "1.1 known bugs list".

#22 Hey Steve,

I'm aware it's a known bug. I just didn't see a different thread for this. I figured I'd toss up what I'd found info-wise, try and help narrow down the issue if at all possible.
If there's a newer thread for this, I'll post there instead.

#23 As I've said already in an earlier post: re-institute the delay before deletion and everything will work fine.

#24

Quote:
As I've said already in an earlier post: re-institute the delay before deletion and everything will work fine.

@Daniel : Any suggestion about this ? I tried many things with no success.
Could you be more precise ?

Quote:
We had some thoughts that it might be collision related

@Eric : I don't think so. Same angle, positions, etc... Sometimes projectiles explode, sometines no.

I Bet either on a "sim revamp bug" or a "network bug".
If someone have any idea, it would be great.

#25 More precise than my initial response to this thread? =)

#26 Ah pants I just uninstalled all my old Torques!
(500m/s seems a tad overkill)

#27 You guys ready for a hopeful fix?

This is a really difficult bug to reproduce, which explains why it may have taken so long to get resolved. This solved the problems I was having with projectiles, hopefully it should for you too.

in .../Engine/source/T3D/projectile.h

Add this variable here...

LightInfo *mLight;
   LightState mLightState;   

   bool             mHasExploded;   ///< Prevent rendering, lighting, and duplicate explosions. <-- VARIABLE ADDED
   F32              mFadeValue;     ///< set in processTick, interpolation between fadeDelay and lifetime
                                    ///< in data block

As for .../Engine/source/T3D/projectile.cpp

in Projectile::Projectile() (Projectile's constructor) make the following addition...

mActivateThread( NULL ),
   mMaintainThread( NULL ),
   mHasExploded( false ), //<-- LINE ADDED
   mFadeValue( 1.0f )

Also replace all instances of "isHidden()" with "mHasExploded", and all instances of "setHidden( bool );" with "mHasExploded = bool" Using SetHidden stops the object from being ghosted, which causes the client projectile to get deleted before actually exploding. We don't want it hide/remove the projectile from the scene at this point, just stop it from rendering and processing simulations. Using a member variable to control this should stop the two from getting out of sync.

Please try this change out and let me know if there are any problems with it. Hopefully this fixes some of the projectile issues, it has for me.

#28 looks an almost identical fix to the one on this page that I suggested for the same issue back in Beta2!

#29 By "setHidden( bool );" with "mHasExploded = bool" you mean the single line of setHidden ( true); to be replaced with mHasExploded = true; I take it ...

Anyhow, nothing bad detected after change ...

[edit]Yeah, you tell 'em Guy! lolz

#30 You know, I just call 'em duds and move on - today's weapons manufacturers and tomorrow's will probably be similar, and they produce weapons that don't work all the time. Faulty blasting cap, faulty detonator, faulty arming mechanism... could be any number of things. If you're killed in combat you can't come back and complain, so who cares?

Dick's Heavy Weapons - you want 'em dead, shoot 'em with Dick's!

#31 Haha, nice Guy! This issue was never assigned to me, so I didn't know there was a suggested fix out there for it! Looks like great minds do think alike ; )

@Steve - Yes, that's exactly what I meant. Couldn't remember off the top of my head if there was a single instance or multiple, so I kept it safe by using the word bool ; )

#32 So I've spent the last 10 minutes shooting grenades everywhere, and none of them disappeared... So thanks for the fix, I'll mark it as resolved now.

#33 Nope - projectiles are still being eaten. I really think this is somehow related to network latency. If you catch one not exploding, check your range and try again, then move closer and farther from the target and continue to fire at it. You'll find there is a range band within which you get no hits. This band varies slightly from moment to moment, most noticeably at the edges of the range band, and it is different across LAN (and probably internet) connections, thus giving a more random appearance.

72.193.82.104/IMG_0812.MOV shows this with a rigidShape object, though aiming at different spots on the object was used to get a more distant face. Movie is about 13 megs.

<edit> Explosions always seem to fire when a hit is registered now though.

<edit again> Sorry - I said "being eaten" when I meant "failing to collide". The emerge from the back of the ball and strike the far wall. I guess I really didn't read the initial post very thoroughly....

#34 Since this thread is still going after all this time, I decided to have a quick look through this morning and see what was going on. As I initially surmised (some four months ago), the primary reason for this happening is that projectiles with a client-side explosion effect need a delay before they're deleted or, in certain situations, the client will never get to see the explosion. There was code in the projectile class in earlier iterations of the engine to handle this. Someone removed it without understanding what it does and what it prevents (but apparently didn't feel the need to remove the DeleteWaitTime value from the header while they were doing so -- go figure). It's seriously irritating to me to find that, even after all these years, there are people working on the engine who are not properly testing their code on a network.

The other issue that I spotted -- one that someone else's change has highlighted already -- is that using setHidden and isHidden is a problem when you involve networking (again, something that was in there previously, but which someone thought could be removed -- and didn't obviously test). The problem lies with how objects are scoped. If you set a sceneobject to hidden it is removed from the scene. If it is removed from the scene, it is not (under normal circumstances) networked to the client. Trying to save yourself a boolean per projectile (no doubt in a misguided attempt to "optimize" the class) ends up introducing networking issues.

As a five minute bodge job, the following should be a sizeable portion of what needs to be done to solve the issue... I'm not guaranteeing anything by any means but it should work.


To fix the first issue, go into projectile.cpp and find the ::explode method. Just prior to it, add:

// Scheduled deletion event.
class ProjectileDeleteEvent : public SimEvent
{
public:
   void process(SimObject *object)
   {
      object->deleteObject();
   }
};

Then, in the ::explode method itself, replace:

// Just wait till the timeout to self delete. This 
      // gives server object time to get ghosted to the client.

... with ...

// Post an event to delete the object, after the projectile deletion wait time has expired.
      Sim::postEvent(this, new ProjectileDeleteEvent, Sim::getCurrentTime() + DeleteWaitTime);

Then in the first section of the ::simulate method in that same, file change the first line or so to:

// On the server, if the projectile has reached the end of its lifespan and hasn't exploded...
   if ( isServerObject() && mCurrTick >= mDataBlock->lifetime && !mExplosionDone)

To solve the second problem, at end of the projectile class in projectile.h, after all the other explosion-related variables, add:

bool mExplosionDone;  // Flag for whether the explode method has been called.

Then, in projectile.cpp, add initialize the variable in the constructor with something like:

mExplosionDone(false)

Then find and replace isHidden() in projectile.cpp and replace each and every occurance with mExplosionDone.

Finally, in the same file, find the ::explode method and replace the call to setHidden with:

// Flag the explosion as done.
   mExplosionDone = true;

#35 My projectiles are failing to collide. When they collide they explode, usually - your fix should ensure that this is the case. The problem is, if it does not collide then this fix corrects nothing. If you were able to view the Quicktime video above you should see what I'm talking about - though I should probably do that multiplayer so you can see the projectile emerge from the back of the ball and continue on to strike and explode against the far wall.

Thanks for your fix, though - I'm going to apply it this evening and see if it helps with my issue with explosions happening invisibly (the explosion occurs server side, the object is affected by the explosion impulse, but no explosion is rendered on the client). This symptom occurs with about 3~5% of my rockets.

#36 I can't seem to load your video I'm afraid. The connection just times out.

If the projectiles are failing to collide at all -- both server and client, then odds are there's some collision-related reason. Perhaps the projectile is burrowing or whatever.

#37 Sorry about the video, but yeah, it's collision. Try this one. I fire at an object with a collision mesh (or polysoup collision - no difference) and occasionally the collision doesn't happen. I was talking "latency" but I begin to think that someone else's idea of ticks and packets being out of sync might be to blame. Perhaps sim the projectile farther on each update to ensure that we're not going to hit something in that space where we skip an update due to a packet missing its tick.

Or I could be way out in left field.

I also wonder how many of the reportedly "eaten" projectiles just didn't collide. The terrain collisions shown in the original post look like what I was experiencing, but we can't see the other side of the terrain so we can't tell if they just went through or if they failed to explode and simply vanished.

#38 Richard, is this getting proper attnetion or is this ever going to get proper attention from GG ?

..this is a bit of a GINORMOUS WTF.
thx. :D

#39 @eb
That's why Ray was posting in the thread last month. ;)

From what I've seen what's been checked in for this appears to be holding, but it hasn't gone through the full ringer yet.

#40 ok, so the projectiles no longer disappear(which is the fix and reason for the thread).
BUT;
now the remaining collision issue based upon range differences is a lurker.
That is what I was referring to, not the thread topic.
Sorry for confusion.