T3D 1.1 B3 - Dedicated Server problem on death (resolved) - RESOLVED
by Jules · in Torque 3D Professional · 03/16/2011 (7:12 am) · 16 replies
Torque 1.1 B3 - Dedicated Server Problem on death when logging score/kills/deaths and sending a messageAll.
Using: Stock FPS example
Platform: Windows Vista (dedicated server + 1st player client) and Windows XP (2nd player client)
Lets use this as an example, so you can see the problem:
Two players in the server each named:-
player1 and player2
In the message hud you will see that player 1 gets nailed by player2. But every so often you will see
player1 gets nailed by !
As I have been logging scores to a web server I have been getting blank entries and it appears that it does not populate %client.score, %client.kills, %client.deaths and %client.playerName
Using: Stock FPS example
Platform: Windows Vista (dedicated server + 1st player client) and Windows XP (2nd player client)
Lets use this as an example, so you can see the problem:
Two players in the server each named:-
player1 and player2
In the message hud you will see that player 1 gets nailed by player2. But every so often you will see
player1 gets nailed by !
As I have been logging scores to a web server I have been getting blank entries and it appears that it does not populate %client.score, %client.kills, %client.deaths and %client.playerName
#3
03/16/2011 (8:04 am)
If you, or anyone can come up with a fix before 1.1 final here that would be great! If I find a solution before then I'll post it here. 
#4
I don't have sources at hands, Julian, can you check if that fixes the issue?
03/16/2011 (8:20 am)
Hmm.. looks like the line should be:%sourceClient = %sourceObject.client ? %sourceObject.client : 0;We assign client only if we have one.
I don't have sources at hands, Julian, can you check if that fixes the issue?
#5
03/16/2011 (8:41 am)
Hi Bank. No didn't work I'm afraid.
#6
03/16/2011 (8:48 am)
The original line%sourceClient = %sourceObject ? %sourceObject.client : 0;Works 95% of the time. So it must be something deeper than that and losing its ID every so often. This is a stock build I'm working on, and I remember seeing this in early betas/alphas but only just noticed what it was doing once I started logging the scores to a database.
#7
edit: I then changed the default rocket launcher weapon direct damage to 25 and this then happend when the players health was at 40. So maybe its going over the limit before recording a death.
03/17/2011 (12:42 am)
Ok I've done further testing on this, it records a blank score only when the players health is at 10 and then is killed with a final shot, when I killed a player with 40 health it didn't happen. Something maybe to do with checking to see if the player is dead or not, or a health related issue? Not certain - will leave it up to you guys.edit: I then changed the default rocket launcher weapon direct damage to 25 and this then happend when the players health was at 40. So maybe its going over the limit before recording a death.
#8
Shooting a player close up and killing them records the score/death and you get player1 was nailed by player2
Shooting a player from a fair distance and killing them doesn't and you then get the player1 was nailed by !
Solution/Fix? not sure. But a major showstopper!!
03/17/2011 (1:45 am)
scrap that #7, I've figured it out!!Shooting a player close up and killing them records the score/death and you get player1 was nailed by player2
Shooting a player from a fair distance and killing them doesn't and you then get the player1 was nailed by !
Solution/Fix? not sure. But a major showstopper!!
#9
The "sourceObject" on Projectile is cleared after some time (some ticks).
If I remember correctly it's inside Projectile::processTick().
So, when you shoot, after some time engine clears the sourceObject field, so it doesn't "belong" to anyone anymore. You can change this behavior by removing the code that clears mSourceObject... or increase the timeout.
03/17/2011 (1:54 am)
oh. I know what is a problem..The "sourceObject" on Projectile is cleared after some time (some ticks).
If I remember correctly it's inside Projectile::processTick().
So, when you shoot, after some time engine clears the sourceObject field, so it doesn't "belong" to anyone anymore. You can change this behavior by removing the code that clears mSourceObject... or increase the timeout.
#10
Not a bug then, but a feature that needs addressing a bit in FPS Example.
03/17/2011 (2:42 am)
Excellent! Thanks Bank. I'll give it a go :)Not a bug then, but a feature that needs addressing a bit in FPS Example.
#11
In projectile.h
Under
class Projectile : public GameBase, public ISceneLight
change:
SourceIdTimeoutTicks = 7,
to a higher value (around 70 before the player becomes out of sight on a flat terrain). Perhaps base your timing on the visibility of a player target. Ideally this should be based on a timeout destroying the projectile and also if it has hit a player before timing out the ownership, as there could be rogue projectiles or radius damage hitting a player.
03/17/2011 (3:24 am)
yep, that did the trick Bank, thanks for your help on that one.In projectile.h
Under
class Projectile : public GameBase, public ISceneLight
change:
SourceIdTimeoutTicks = 7,
to a higher value (around 70 before the player becomes out of sight on a flat terrain). Perhaps base your timing on the visibility of a player target. Ideally this should be based on a timeout destroying the projectile and also if it has hit a player before timing out the ownership, as there could be rogue projectiles or radius damage hitting a player.
#12
The proper fix is for Projectiles to always remember their source object, but only disable collision against it for a short while. It's been a while since I looked at projectile, but I remember thinking it would be a pretty easy fix.
03/17/2011 (6:37 pm)
Ideally, you don't want to ever clear the sourceObject. At the moment, the engine and scripts use the member in two different ways: the engine uses it to disable collision against the firer, as a hacky sort of fix for small weapons that are wholly enclosed by a Player's bounding box. However, scripts assume it is a persistent value that records the ID of the firer.The proper fix is for Projectiles to always remember their source object, but only disable collision against it for a short while. It's been a while since I looked at projectile, but I remember thinking it would be a pretty easy fix.
#13
03/18/2011 (6:10 am)
Thanks Daniel. Do you know if this modification, or even the one I posted above yours is exposed to TorqueScript datablocks for weapons without having to make an engine change? I couldn't see anything obvious, although I'm only really starting to look at the weapons and projectiles side of Torque more in-depth now. 
#14
More If for any reason GG decide to change this Part you won t be impacted.
03/18/2011 (11:41 am)
In fact in my game we decided to create a new variable to maintain the firer. By doing that you keep the current hack for collision and when you will move to 1.1 it Will ease the merge. More If for any reason GG decide to change this Part you won t be impacted.
#15
03/18/2011 (1:30 pm)
yeah, my main game handles things a bit differently. This is more aimed at the Game Ranking System i've been working on to support binary users in addition to a quick game only taking a month so I didn't want to make any engine changes unless I really had to. 
#16
10/27/2011 (9:43 am)
Fixed in 1.2. 
Torque Owner Jules
Something2Play
if I comment out line:
//%sourceClient = %sourceObject ? %sourceObject.client : 0;
I then get the missing blank entry all the time. So something related to %sourceObject....
Not sure on a fix though, anyone?