T3D 1.1 Beta 2 - When shooting close, effects might not aperar - RESOLVED
by Marcus L · in Torque 3D Professional · 08/05/2010 (1:59 pm) · 56 replies
Build: 1.1 Beta 2
Platform: Windows 7 64x
Target: In-game
Issues: If you shoot at a sloped collision shape (for example a terrain slope) that is close to the player, no explosion effect will appear. This does also happens if you shoot a TSStatic at a specific distance.
Steps to Repeat:
1. Launch the game - DeathBall Desert
2. Pick up the RocketLauncher
3. Move to a slope in the terrain
4. Aim down
5. Shoot
Suggested Fix: I have no solution, but i did experience this in 1.1a & 1.1b2 and i fixed it by delaying the projectile by one tick. Not a real fix tho. EDIT: Current fix at comment #27. Does also require increased $pref::Net::PacketRateToClient, suggested size is "32".
EDIT2: There was also an additional bug introduced here due to the introduction of setHidden, fix is at comment #52.
Thanks,
Marcus L.
Platform: Windows 7 64x
Target: In-game
Issues: If you shoot at a sloped collision shape (for example a terrain slope) that is close to the player, no explosion effect will appear. This does also happens if you shoot a TSStatic at a specific distance.
Steps to Repeat:
1. Launch the game - DeathBall Desert
2. Pick up the RocketLauncher
3. Move to a slope in the terrain
4. Aim down
5. Shoot
Suggested Fix: I have no solution, but i did experience this in 1.1a & 1.1b2 and i fixed it by delaying the projectile by one tick. Not a real fix tho. EDIT: Current fix at comment #27. Does also require increased $pref::Net::PacketRateToClient, suggested size is "32".
EDIT2: There was also an additional bug introduced here due to the introduction of setHidden, fix is at comment #52.
Thanks,
Marcus L.
#2
08/05/2010 (3:12 pm)
I had this issue, but it was resolved after updating my graphics card driver. There were polygons close together which allowed me to shoot through the terrain. 
#3
08/05/2010 (3:15 pm)
I'm seeing it on meshes which are sealed ... but not on every map ... hence the oddness ... latest drivers alround.
#4
Ummm, my drivers are already up to date so i doubt that has much to say. Are you saying you are unable to reproduce this after updating your drivers? Event following the given steps?
08/05/2010 (3:32 pm)
@ JulianUmmm, my drivers are already up to date so i doubt that has much to say. Are you saying you are unable to reproduce this after updating your drivers? Event following the given steps?
#5
08/05/2010 (4:05 pm)
I'm seeing this also... infrequent level loads though and not consistent.
#6
08/05/2010 (5:30 pm)
@Marcus - at first I couldn't replicate this issue, but after several attempts at level loading, I can now see this. I've also placed a camera under the terrain whilst firing, but cannot see the projectile pass through, unless it's too quick. So it's just dissapearing? 
#7
Assuming we're talking about the same issue... if I grab the rocket launcher from the FPS Example and fire it near my feet on terrain, about half the time the explosion will not play on the client, however the server effects will trigger. Impulse will throw the player, and damage will be taken. I always assumed this was a ghosting issue; the rocket launcher has a fairly high projectile velocity, so my assumption was that the projectile is being destroyed before it gets properly ghosted to the client. I don't believe a failure to register collision is involved.
All projectiles seem to display this issue, sometimes ghosting on the first tick and other times not appearing until they've sim'd a tick. In theory the absolute best case fix would be to have projectiles "predict" themselves into existence on the client and be synced up with the server as soon as the initialupdate packet comes through, but that doesn't seem especially realistic. At the very least, the explosion event should always be sent to the client even if the projectile wasn't ghosted yet.
If ghosting isn't the issue, my next theory would be a scoping issue. Do projectiles and explosions scope out if the client thinks they're outside the viewport? Is it possible this is being a bit too aggressive in regard to explosions near the Player's feet? :P
*edit: Just to be clear, you may sometimes also see an explosion but not get impulse/damage on the server end, but that's an unrelated & known issue w/ the radiusDamage script I believe.
08/05/2010 (6:20 pm)
I have been able to reproduce this in every version of T3D as far as I can recall.Assuming we're talking about the same issue... if I grab the rocket launcher from the FPS Example and fire it near my feet on terrain, about half the time the explosion will not play on the client, however the server effects will trigger. Impulse will throw the player, and damage will be taken. I always assumed this was a ghosting issue; the rocket launcher has a fairly high projectile velocity, so my assumption was that the projectile is being destroyed before it gets properly ghosted to the client. I don't believe a failure to register collision is involved.
All projectiles seem to display this issue, sometimes ghosting on the first tick and other times not appearing until they've sim'd a tick. In theory the absolute best case fix would be to have projectiles "predict" themselves into existence on the client and be synced up with the server as soon as the initialupdate packet comes through, but that doesn't seem especially realistic. At the very least, the explosion event should always be sent to the client even if the projectile wasn't ghosted yet.
If ghosting isn't the issue, my next theory would be a scoping issue. Do projectiles and explosions scope out if the client thinks they're outside the viewport? Is it possible this is being a bit too aggressive in regard to explosions near the Player's feet? :P
*edit: Just to be clear, you may sometimes also see an explosion but not get impulse/damage on the server end, but that's an unrelated & known issue w/ the radiusDamage script I believe.
#8
08/05/2010 (6:58 pm)
Quote:Maybe... but you'd think this problem would show itself long before now, especially since the rocket is the same speed of the old crossbow bolt from TGE -- I've also used much higher projectile velocities without problem before now.
I always assumed this was a ghosting issue; the rocket launcher has a fairly high projectile velocity, so my assumption was that the projectile is being destroyed before it gets properly ghosted to the client.
#9
08/05/2010 (7:06 pm)
Bullets still fly and do damage though cos I just headshot an Ai as a test, but there are no visble effects or visible projectile.
#10
I'd need to go test a copy of TGE 1.5 to be certain, but I still think I used to run into this constantly. I believe I eventually started using higher packet sizes and packet rates, and that more or less "fixed" the issue. At least it decreased the frequency. I can also use higher velocity projectiles without issue in theory, but the closer they hit to the point of fire, the less likely it is I ever see the explosion.
@Steve
Yeah, I can pretty much duplicate that. I can stand immediately next to a bot, shoot him at point blank, and do damage without seeing projectile or explosion effects.
Yesterday I finished porting over most of my code to B2, and the first thing I actually noticed was how much more often the projectiles were not appearing when firing at my feet (for some reason I always start by testing rocket jumping). It then occurred to me that my Player class has a lot of debugging server->client bloat I leave in for my own testing. I'm going to try some higher rates and then I'll update this reply.
Update:
Okay, I'm going to suggest you guys both try this and see if it works. Seems to have solved the problem for me at least. In scripts/client/prefs.cs set your server->client packet rate to 32, like so:
$pref::Net::PacketRateToClient = "32";
Entering this in the console won't change the rate unless you restart first.
I tried 20 (10 by default), which didn't help. I also tried increasing the packet size and leaving this at 20, still didn't help. Then I smacked myself in the face and went "durr, how can we always ghost a projectile on its initial tick if we don't send a packet every tick." In other words, only 32 (which is also the tick rate, isn't it?) results in a packet being sent every tick. Any other packet rate results in an out of sync packet send rate, where some ticks get packets and others don't. That's why the client->server rate has always defaulted to 32 I'd guess, so we never skip Move ticks to the server.
I've only tested this in singleplayer.. later I might try the lag simulator and see what happens. My guess is that it will work, just with lag. The server may delete the projectile before you get the first packet, but that packet will already be on its way. Your client will get it and create the effects. By the time the packet comes in to tell you you've been damaged, the explosion will have rendered. All of this is making me highly aware of how badly Torque needs client-side prediction for everything projectile and damage related, but I'm getting off topic.
08/05/2010 (7:48 pm)
@MichaelI'd need to go test a copy of TGE 1.5 to be certain, but I still think I used to run into this constantly. I believe I eventually started using higher packet sizes and packet rates, and that more or less "fixed" the issue. At least it decreased the frequency. I can also use higher velocity projectiles without issue in theory, but the closer they hit to the point of fire, the less likely it is I ever see the explosion.
@Steve
Yeah, I can pretty much duplicate that. I can stand immediately next to a bot, shoot him at point blank, and do damage without seeing projectile or explosion effects.
Yesterday I finished porting over most of my code to B2, and the first thing I actually noticed was how much more often the projectiles were not appearing when firing at my feet (for some reason I always start by testing rocket jumping). It then occurred to me that my Player class has a lot of debugging server->client bloat I leave in for my own testing. I'm going to try some higher rates and then I'll update this reply.
Update:
Okay, I'm going to suggest you guys both try this and see if it works. Seems to have solved the problem for me at least. In scripts/client/prefs.cs set your server->client packet rate to 32, like so:
$pref::Net::PacketRateToClient = "32";
Entering this in the console won't change the rate unless you restart first.
I tried 20 (10 by default), which didn't help. I also tried increasing the packet size and leaving this at 20, still didn't help. Then I smacked myself in the face and went "durr, how can we always ghost a projectile on its initial tick if we don't send a packet every tick." In other words, only 32 (which is also the tick rate, isn't it?) results in a packet being sent every tick. Any other packet rate results in an out of sync packet send rate, where some ticks get packets and others don't. That's why the client->server rate has always defaulted to 32 I'd guess, so we never skip Move ticks to the server.
I've only tested this in singleplayer.. later I might try the lag simulator and see what happens. My guess is that it will work, just with lag. The server may delete the projectile before you get the first packet, but that packet will already be on its way. Your client will get it and create the effects. By the time the packet comes in to tell you you've been damaged, the explosion will have rendered. All of this is making me highly aware of how badly Torque needs client-side prediction for everything projectile and damage related, but I'm getting off topic.
#11
I noticed this issue this morning while testing a terrain. The change of PacketRateToClient to 32 fixed it for me. I am curious as to the impact this will have on server performance in a multiplayer situation.
08/05/2010 (8:24 pm)
@Henry I noticed this issue this morning while testing a terrain. The change of PacketRateToClient to 32 fixed it for me. I am curious as to the impact this will have on server performance in a multiplayer situation.
#12
If you kept the 200 byte packet size (honestly that seems pretty low to me, I generally increase it) you're still only talking about 6400 bytes (6.25kB)/sec/player. That's pretty low for a modern FPS game; I expect to be pulling down that as an absolute minimum in a Source Engine game.
OTOH, if your game is slower-paced with higher player counts (say, an MMO) running at an update rate of 32 is probably not a great idea, nor is it really required. The only way MMOs keep things stable is by massively cutting back on the number of updates to and from clients. It never really presents an issue because these games are always never designed around twitch gameplay.
We'd need to hear form someone more aware of the Torque networking internals to confirm this, but I *assume* the packet size (ie 200 bytes) is a maximum packet size before data gets split and put into the next packet. I can't think of any way it makes sense that the server would be sending all 200 bytes if there weren't 200 bytes worth of updates ready to go. So in theory you could set the packet size to 1000 and still only be getting say 3 kB/sec worth of updates if you're on an empty server. The issue is that when things heat up you're now allowing up to ~32kB/sec/player of data to flow because the server is allowed to pack an entire kB into 1 packet if it can. Still, for serious modern FPS's that's not an unreasonable rate. You just then need to determine what your server can handle; 20 players at 32kB/sec would use 640 kB/sec of upstream, which most people don't have on home or small-scale business broadband. At this point you're talking about using a dedicated hosting box on some backbone (FYI this is what most servers for games like CS:S, Battlefield[whatever], etc. run off of).
08/05/2010 (8:50 pm)
Well, a packet rate of 32 both ways is pretty much standard for action FPS games. Even in the days of something like the original Counter-Strike, most players would set their update rates to 32. With everyone on broadband these days, I'd say it's probably not a serious concern. If you kept the 200 byte packet size (honestly that seems pretty low to me, I generally increase it) you're still only talking about 6400 bytes (6.25kB)/sec/player. That's pretty low for a modern FPS game; I expect to be pulling down that as an absolute minimum in a Source Engine game.
OTOH, if your game is slower-paced with higher player counts (say, an MMO) running at an update rate of 32 is probably not a great idea, nor is it really required. The only way MMOs keep things stable is by massively cutting back on the number of updates to and from clients. It never really presents an issue because these games are always never designed around twitch gameplay.
We'd need to hear form someone more aware of the Torque networking internals to confirm this, but I *assume* the packet size (ie 200 bytes) is a maximum packet size before data gets split and put into the next packet. I can't think of any way it makes sense that the server would be sending all 200 bytes if there weren't 200 bytes worth of updates ready to go. So in theory you could set the packet size to 1000 and still only be getting say 3 kB/sec worth of updates if you're on an empty server. The issue is that when things heat up you're now allowing up to ~32kB/sec/player of data to flow because the server is allowed to pack an entire kB into 1 packet if it can. Still, for serious modern FPS's that's not an unreasonable rate. You just then need to determine what your server can handle; 20 players at 32kB/sec would use 640 kB/sec of upstream, which most people don't have on home or small-scale business broadband. At this point you're talking about using a dedicated hosting box on some backbone (FYI this is what most servers for games like CS:S, Battlefield[whatever], etc. run off of).
#13
I always have my packetrate at 32 and size at 900 (there was issues with 1500 in 1.1b1).
So I'm getting it on some maps only ...
08/05/2010 (8:55 pm)
@HenryI always have my packetrate at 32 and size at 900 (there was issues with 1500 in 1.1b1).
So I'm getting it on some maps only ...
#14
Any chance these maps are populated enough that you're actually using all 900 bytes each tick? IE, do they have a lot of bots running around, vehicles spawned, other stuff that might be doing frequent updates?
If the initial update of the projectile falls off the end of the update priority for an overloaded packet, this is going to happen no matter how many are sent per second unfortunately. That's why I keep dropping back into a rant about client-side projectile prediction. :P
I'd try gradually increasing the packet size to see if you can find a zone where it works before you run into issues with oversized packets.
Edit: I feel like an idiot but... what ever happened to the netgraph? N is still bound to it, but there's nothing there. I just tried running the debug build to see if it was in there, but no luck. Netgraph was extremely helpful for this kind of stuff in TGE. :P
08/05/2010 (9:16 pm)
@SteveAny chance these maps are populated enough that you're actually using all 900 bytes each tick? IE, do they have a lot of bots running around, vehicles spawned, other stuff that might be doing frequent updates?
If the initial update of the projectile falls off the end of the update priority for an overloaded packet, this is going to happen no matter how many are sent per second unfortunately. That's why I keep dropping back into a rant about client-side projectile prediction. :P
I'd try gradually increasing the packet size to see if you can find a zone where it works before you run into issues with oversized packets.
Edit: I feel like an idiot but... what ever happened to the netgraph? N is still bound to it, but there's nothing there. I just tried running the debug build to see if it was in there, but no luck. Netgraph was extremely helpful for this kind of stuff in TGE. :P
#15
08/05/2010 (10:10 pm)
Nah, the map with a gizzilion bots shoots fine everytime! But one with only a single object is the one where this happens all the time! lolz ... Also, didn't have this on 1.1beta1 ... and don't remember seeing it before ... maybe that was just lucky ...
#16
Now I'm just plain confused. Just for fun you should maybe do an echo($pref::Net::PacketRateToClient); when that map is running to make sure it's not uh.. somehow changing the packet rate... o_O
Any way you could upload this map & terrain? Assuming it doesn't rely on a bunch of your game-specific content, anyway. This is why I'd like to get access to the old netgraph.... could check if there's some strange object using network traffic that shouldn't be.
08/05/2010 (11:24 pm)
You were probably always setting the packet rate up in each version.. I usually do that too, but forgot about it for the last couple releases.Now I'm just plain confused. Just for fun you should maybe do an echo($pref::Net::PacketRateToClient); when that map is running to make sure it's not uh.. somehow changing the packet rate... o_O
Any way you could upload this map & terrain? Assuming it doesn't rely on a bunch of your game-specific content, anyway. This is why I'd like to get access to the old netgraph.... could check if there's some strange object using network traffic that shouldn't be.
#17
Thanks to eb for the hosting
08/06/2010 (12:21 am)
still 32 ... or at least ... that's what it says ...Thanks to eb for the hosting
#18
I dropped your level into a new 'full' template and tried tweaking the packet rate and size to fix the issue and was unable to. I even added a new 256 sized terrain and deleted your level object with no success.
I locked up T3D several times when I fired a close range projectile into gideons corpse from a previous death :( I thought that wasn't an issue now?
Edit:
In the same 'full' template package I opened the 'Empty Terrain' level and added Steves mesh and it works perfectly fine. Even after deleting the terrain it still operates fine.
Edit2:
I went ahead and moved the locations of your mesh and spawn point to 0 0 0 and 0 0 20 respectively and it immediately fixed the issue!!!
After trying different locations I narrowed it down somewhat: Locations of 640,640,0 work but 700,700,0 won't on about half the mesh; and higher moves us away from the area it will show. Obviously we are seeing a sharp line where the decals and impulses stop showing.
No idea what this means but it should narrow things down.
08/06/2010 (8:01 am)
O.oI dropped your level into a new 'full' template and tried tweaking the packet rate and size to fix the issue and was unable to. I even added a new 256 sized terrain and deleted your level object with no success.
I locked up T3D several times when I fired a close range projectile into gideons corpse from a previous death :( I thought that wasn't an issue now?
Edit:
In the same 'full' template package I opened the 'Empty Terrain' level and added Steves mesh and it works perfectly fine. Even after deleting the terrain it still operates fine.
Edit2:
I went ahead and moved the locations of your mesh and spawn point to 0 0 0 and 0 0 20 respectively and it immediately fixed the issue!!!
After trying different locations I narrowed it down somewhat: Locations of 640,640,0 work but 700,700,0 won't on about half the mesh; and higher moves us away from the area it will show. Obviously we are seeing a sharp line where the decals and impulses stop showing.
No idea what this means but it should narrow things down.
#19
08/06/2010 (10:17 am)
Nice testing there Aaron! 
Associate Steve Acaster
[YorkshireRifles.com]
... maybe a precision issue?