T3D 1.1 Beta 2 - When shooting close, effects might not aperar - RESOLVED

#41 Ok, must be my mission file, works fine on Deathball Desert! grumble

#42 Ok, just realised that the position of my own levels terrain is set to -1024 -1024 0, so changing this to something like -1024 -1024 -1024 resolved the issue. Only downside to this is everything else has to be moved! double grumble

#43 Nope, just moves the problem elsewhere. Oh well, I'm gonna give up on this for a bit, driving me a bit mad!

Edit: if you guys can try and replicate what I am seeing. Shooting down is fixed now, but if you try shooting the terrain at weapons holding height there is one place that doesn't work.

#44 Move packetsize to 400 or 900 (not 1500 it'll fail and put it back to 200 without telling you - unless you force it with localclientconnection.checkmaxrate();, and then you'll get a bad packet if you spawn 50 Ai all at once).

Or stick the code fix before the bullet gets added again ;)

#45 @Julian
When you're messing w/ packet sizes as Steve suggested you might try turning on metrics("net"); (just put that in console) to see how much data is coming in at any given time. If it's ever at or near the set packet size, you're probably losing update events, which is something none of these fixes can deal with.

If you can rig up a mission & terrain that reproduces the issue and uses mostly stock resources, that might be extremely helpful. I only found the setTransform fix b/c Steve uploaded his map, and Aaron noticed the issue was connected to the ground object's position.

@Steve
Actually I did think I noticed the lighting thing when I was toggling vis ranges, I just kind of skipped over it and assumed I was making it up b/c I was focused on this projectile issue. I just tried 100 vs 1000 and was able to get a couple screens showing a really subtle change in the lighting on an object:
ubermonkey.phpwebhosting.com/qmedia/visLight1000vs100.jpg
It's hard to see, but if you look close the backpack on the left is lighter than on the right. I probably could've gotten a better shot, but... eh I already uploaded this one. :P

To see it more clearly hit back and forth between these 2 images quickly:
ubermonkey.phpwebhosting.com/qmedia/visLight100.jpg
ubermonkey.phpwebhosting.com/qmedia/visLight1000.jpg

@Marcus
Yeah, sorry, I got distracted by all the Beta 2 stuff. I'll make a note to look at the uncrouch code today and see if I can build a simple fix. Updated: Posted what I believe is a working fix for the crouch issue to the original thread.

#46 @Henry - thanks. I'm thinking it's now something to do with my terrain file as I have created a new terrain and I cannot duplicate the problem. I've used the same terrain file since 1.01 or maybe the earlier beta's. Which is going to be a bit of a pain re-creating it all again.

#47 @Marcus
I use a variable to lock the player into a (ForcePose) pose, and then feed them it via a trigger or script.

[edit]
you did mention it @ 35


[double edit]
Yeah I know ... but I couldn't be bothered finding the correct thread! :P

#48 Wrong thread Steve? If so add a markup saying "threadmixup" at the top of your previous comment :P.

[/threadmixup]

sorry for the thread mixup everybody. Disclamer here Steve, I did start the mixup, I'm just saying this so you don't think i blame you for the mixup. we're cool right?

[edit chating]
yeah, but that was specifically for Henry + the thread i linked ):P

[rofl edit]
ahaha, rofl @ the inconvenience of hyperlinking.

#49 Logged for QA team (TQA-750)

#50 Bug confirmed.

I know Matt just loves these bugs that involve shooting at the player's feet.

#51 Not sure if this is along the same lines;
Ever since TGE I can stand at a certain distance from ANY collide-able object type and the weapon projectiles will randomly hit and not hit, decal and not decal.
- The projectiles have always started at a randomly chosen number of units in front of the fired weapon.

It's a rubbish kind of thing I have always planned to look into..

#52 OK, I *think* I've figured out why the explosions and decals are not showing up on the client.

The culprit here is the new implementation of setHidden (can you find any mention of this in the changelogs? It's a bit cryptic).

The hidden state of an object is now directly networked as part of a SceneObjects pack/unpack. Using setHidden() on an object triggers this update.

Projectile::explode used to use mHidden to determine if the explosion had already occurred, thereby preventing multiple explosions. This has changed in 1.1b2, and Projectile::explode now uses the new setHidden(). Unfortunately, this now causes the objects hidden state to be networked to the client, and this happens before the projectiles part of the network update. So, when the explode part of the update is unpacked on the client, there's a good chance that isHidden() will allready be true, and therefore explode() will return without creating the clientside explosion and decal.

Why this doesn't happen every time is not clear to me.


A quick fix:

projectile.h,
after

U32 mCollideHitType;

add

bool mExploded;

projectile.cpp
add mExploded( false ) to the constructor initialization
e.g. should now be

mFadeValue( 1.0f ),
mExploded( false )

in Projectile::explode
comment out

if ( isHidden() )
      return;

and replace with

if( mExploded )
      return;
   mExploded = true;

note -
I think that the work above investigating the visible distance, terrain position and network packet size is a bit of a red herring here, and is highlighting something else with the engine that is bustified, but not directly related to the projectile explosions.

#53 You're quite right, actually. The setHidden change is apparently what introduced this behavior in the first place. Tested your fix, and it definitely solves the missing explosion effect entirely (though the compiler didn't care for mExploded( false ) when I tried it.. had to use the "= false"). Hopefully the devs will take another pass and spot this.

Now, as far as:

Quote:Why this doesn't happen every time is not clear to me.

That's the issue I got caught up in (and apparently went a little tunnel vision on):

-In the first case, any packet rate which is not in sync with the tick rate means that some ticks simply won't be able to send update packets, forcing the ghost and initial update packets to their second tick of life, when the explosion may have already happened.

-In the second case, the new Projectile object's position in the scenegraph really isn't being set during onAdd, meaning it won't be ghosted on its first tick so long as the world origin point is out of scope to the player the Projectile is being ghosted to.

Both of these scenarios result in the initial update packet being sent on the 2nd tick of the Projectile's life. In close-range firing scenarios that means the projectile will have already exploded by the time the initial update goes out, setHidden will be called, and the client will see nothing. If you want to check when the initial update packet is being sent, you can add this bit of debug output to packUpdate:

if ( stream->writeFlag( isInitalUpdate ) )
   {
      Con::printf("Packing Initial Update, tick# %d", mCurrTick); // ADDED

Optimally the engine would always try to send the initial update in tick 0, but as you'll see either of these issues can push it to tick 1. With a server->client rate of 10 I get a lot of this:
Unpacking Initial Update, tick# 1
Unpacking Initial Update, tick# 0
Unpacking Initial Update, tick# 1
Unpacking Initial Update, tick# 2
So you can see that sometimes it even has to wait until the 3rd tick to send an initial update.

Both of these issues have existed since the TGE days, but it was the setHidden() bit that changed and introduced the symptom of the missing explosions. Why I never considered how two ancient issues suddenly produced new symptoms I can't say, but luckily you did look into it and figured it out!

(@eb: I think this part kind of covers your concerns about the particle trails appearing randomly way out ahead of the player)

That said, I do want to note that at the very least the no setTransform() during onAdd() issue is an actual bug that deserves to be fixed, as it's a case which causes a 1 tick ghosting delay 100% of the time when the player is out of scope of world origin, which is generally a common scenario. While this will no longer break explosions, it will still result in projectiles suddenly popping into existance 20 feet in front of the Player.

The packet rate issue is really just a fact of life for the engine; any non-32 packet rate can result in 1 tick late initial updates for any object type. That's more of a suggestion than a fix. I don't see any way this could be "repaired" as it's not so much broken as, well, if you only send 10 packets/second while running 32 ticks/second you have to expect some ghosting delays. This also means projectiles popping into existance at random distances from the player, but still isn't really a bug.

In a real-life multiplayer scenario, there are other cases (network overload or lost packets mostly) that will result in late ghosting, so this still really needed to be solved either way.

#54 This is fixed in 1.1 Beta 3.

#55 Great thanks Scott, this was bugging the hell out of me.

#56 Ah cool!