Fix for RTSProjectile not rendering its DTS shape
by Geom · in RTS Starter Kit · 09/17/2008 (11:52 pm) · 12 replies
RTSProjectile has a bug where it doesn't render its DTS shape.
It renders particles ok, but not its DTS. The reason you can still see something in the RTS-SK is that you're seeing the RTSProjectile's particles. But if you look closely, you'll notice there's no DTS shape.
To fix this, open <RTS-SK>/engine/game/RTS/RTSProjectile.cc. Add two new lines to the top of RTSProjectile::RTSProjectile():
***** UPDATE 3/25/2010 *****
You also need to add one line to the top of RTSProjectile::onAdd():
Fixed!
Details on the bug and the fix are in www.garagegames.com/mg/forums/result.thread.php?qt=32282 Justin and GG staff pretty much solved the issue but didn't post an explicit fix, hence this post here. :)
In a nutshell, the problem was that RTSProjectiles were getting added to the server scene graph rather than the client scene graph. Thus the rendering problems. The two new lines ensure RTSProjectiles go into the client scene graph.
It renders particles ok, but not its DTS. The reason you can still see something in the RTS-SK is that you're seeing the RTSProjectile's particles. But if you look closely, you'll notice there's no DTS shape.
To fix this, open <RTS-SK>/engine/game/RTS/RTSProjectile.cc. Add two new lines to the top of RTSProjectile::RTSProjectile():
RTSProjectile::RTSProjectile()
{
mNetFlags.clear(Ghostable); // (add this) NOT ghostable - don't want this networked
mNetFlags.set(IsGhost); // (add this) however, it IS a client-side object
// Todo: ScopeAlways?
mTypeMask |= ProjectileObjectType;
// ... blah blah blah ...
}***** UPDATE 3/25/2010 *****
You also need to add one line to the top of RTSProjectile::onAdd():
bool RTSProjectile::onAdd()
{
onNewDataBlock(getDataBlock()); // (add this) hack needed for client-only Projectiles.
if(!Parent::onAdd())
return false;
// etc....
}***** END UPDATE 3/25/2010 *****Fixed!
Details on the bug and the fix are in www.garagegames.com/mg/forums/result.thread.php?qt=32282 Justin and GG staff pretty much solved the issue but didn't post an explicit fix, hence this post here. :)
In a nutshell, the problem was that RTSProjectiles were getting added to the server scene graph rather than the client scene graph. Thus the rendering problems. The two new lines ensure RTSProjectiles go into the client scene graph.
About the author
My email address is my GG handle, at redbrickgames.com.
#2
Argh! I'm glad you mentioned about the stock arrow being offset in the Z axis! I was wondering why arrows were firing out of my Orcs' kneecaps ???
09/18/2008 (1:06 pm)
I don't think the fix in the 1.5.2 RTS-SK yet though, I checked there.Argh! I'm glad you mentioned about the stock arrow being offset in the Z axis! I was wondering why arrows were firing out of my Orcs' kneecaps ???
#3
09/18/2008 (1:10 pm)
No you are right, its not fixed in the 1.5.2, we got to it later, on our most recent project. 
#4
I recompiled with other flags set and no crash occurs, but then the projectiles and particles still only render on the host machine and not on any client machines. In my opinion, the lack of RTSprojectile and particle rendering on client machines is a serious flaw in the RTS-SK and should be addressed by GarageGames.
03/04/2009 (2:03 pm)
The line "mNetFlags.set(IsGhost);" causes the latest version of the RTS-SK to crash as soon as you try to create an RTSprojectile. Only the IsGhost flag causes the crash. Anyone figured this out for 1.5.2 yet? I recompiled with other flags set and no crash occurs, but then the projectiles and particles still only render on the host machine and not on any client machines. In my opinion, the lack of RTSprojectile and particle rendering on client machines is a serious flaw in the RTS-SK and should be addressed by GarageGames.
#5
I'll remove it from my code for now ... not sure it requires something else to work.
Perhaps this fix is required first? Let us know Geom -
http://www.torquepowered.com/community/forums/viewthread/23223
01/19/2010 (2:21 am)
Like Robert noted ... this is breaking the latest 1.5.2 build -- when the rifleman fires a projectile.I'll remove it from my code for now ... not sure it requires something else to work.
Perhaps this fix is required first? Let us know Geom -
http://www.torquepowered.com/community/forums/viewthread/23223
#6
02/18/2010 (2:08 am)
Geom - its probably that your base is TGE 1.3 ... but thinking about this more, it seems "ScopeAlways" would make it always visible right ?
#7
wondering if ANYone have managed to get the projectiles to be VISIBLE ?
I've gone through line by line, every single RTS thread containing projectiles ... and still no solution that makes them visible properly.
03/25/2010 (12:13 pm)
ScopeAlways causes it to try to send to all clients ... which causes the crash due to invalid packets.wondering if ANYone have managed to get the projectiles to be VISIBLE ?
I've gone through line by line, every single RTS thread containing projectiles ... and still no solution that makes them visible properly.
#8
And then in the immortal words of Bill and Ted we shall be Most Triumphant.
03/25/2010 (2:56 pm)
I'll try to investigate the mNetFlags.set(IsGhost) crash this evening. I'll let you know what I find. This problem has gone on way too long. I suspect you're right, there must have been some change between 1.3 and 1.5.2 that causes 1.5.2 to crash. If that's the case (and hopefully it is), surely a fix for 1.5.2 won't be all that hard to figure out. Just need to look at a call stack of the crash, and then figure out which code changed between 1.3 and 1.5.2 that's causing it.And then in the immortal words of Bill and Ted we shall be Most Triumphant.
#9
Justin Tolchin pointed out (five years ago) that the crash is due to Projectile::mDataBlock being NULL. The reason its NULL is because of a subtle bug in GameBase::onAdd(). GameBase::onAdd() never calls onNewDataBlock() for client-only objects. Thus, the (correct) value of GameBase::mDataBlock never gets copied over the (incorrect) value in Projectile::mDataBlock.
It seems too risky to modify GameBase::onAdd(), so instead I made RTSProjectile::onAdd() manually call onNewDataBlock().
Here's proof it works!
- - -
The projectile is too low to the ground, but that's just because of the screwy arrow DTS model that comes with the RTS-SK. Just replace the RTS-SK's projectile.dts with TGE's projectile.dts, and that should fix that.
03/25/2010 (6:30 pm)
Ok...found the issue.Justin Tolchin pointed out (five years ago) that the crash is due to Projectile::mDataBlock being NULL. The reason its NULL is because of a subtle bug in GameBase::onAdd(). GameBase::onAdd() never calls onNewDataBlock() for client-only objects. Thus, the (correct) value of GameBase::mDataBlock never gets copied over the (incorrect) value in Projectile::mDataBlock.
It seems too risky to modify GameBase::onAdd(), so instead I made RTSProjectile::onAdd() manually call onNewDataBlock().
bool RTSProjectile::onAdd()
{
onNewDataBlock(getDataBlock()); // (add this) hack needed for client-only Projectiles.
if(!Parent::onAdd())
return false;
// etc...
}Here's proof it works!
- - -
The projectile is too low to the ground, but that's just because of the screwy arrow DTS model that comes with the RTS-SK. Just replace the RTS-SK's projectile.dts with TGE's projectile.dts, and that should fix that.
#10
I see what you mean about the z height being underground, thats what Novack was talking about --
Adding +4z to the position in client game.cs seems to work ok.
But whats odd is that glowing effect that is around it -- I set light=false in the datablock and it still shows up. And its at the "correct" height --
Do you think it is an "effect" created server side or such?
How might I turn it off and/or the explosion?
03/25/2010 (11:05 pm)
Thanks so much, it works great now!I see what you mean about the z height being underground, thats what Novack was talking about --
Adding +4z to the position in client game.cs seems to work ok.
But whats odd is that glowing effect that is around it -- I set light=false in the datablock and it still shows up. And its at the "correct" height --
Do you think it is an "effect" created server side or such?
How might I turn it off and/or the explosion?
#11
light=false or hasLight=false? hasLight is the field to use.
I think the explosion is just another field on the ProjectileData block. Check the regular TGE stuff, I think explosions are specified the same way in both the RTS-SK and stock TGE.
03/26/2010 (11:58 am)
Well if you ask me I would just use a different arrow model whose center lies at the origin. Otherwise I wouldn't be surprised if you ran into some other issues as well though I can't think of anything ATM.light=false or hasLight=false? hasLight is the field to use.
I think the explosion is just another field on the ProjectileData block. Check the regular TGE stuff, I think explosions are specified the same way in both the RTS-SK and stock TGE.
#12
It was actually the "particleEmitter" thats part of the datablock for the Crossbow projectile.
I tested it in game and this one generates the arrow without the glowing effect OR the impact explosion.
However, it does seem that the projectiles "get" progressively lower until they disappear into the terrain.
EDIT: Found a decent fix for the projectile elevation ... it helps that both the units and buildings come from the same base class.
So we can use
Its not perfect, but much better than before.
03/26/2010 (2:07 pm)
hasLight - yes, at least you knew what I meant :O) ... But turns out it wasn't the light what I was seeing.It was actually the "particleEmitter" thats part of the datablock for the Crossbow projectile.
// JY - my custom projectiles
datablock ProjectileData(ArrowProjectile)
{
projectileShapeName = "~/data/shapes/crossbow/projectile.dts";
directDamage = 30;
radiusDamage = 30;
damageRadius = 1.5;
// explosion = CrossbowExplosion;
// particleEmitter = CrossbowBoltEmitter;
muzzleVelocity = 100;
velInheritFactor = 0.3;
armingDelay = 0;
lifetime = 5000;
fadeDelay = 5000;
bounceElasticity = 0;
bounceFriction = 0;
isBallistic = true;
gravityMod = 0.80;
hasLight = true;
lightRadius = 4;
lightColor = "0.5 0.5 0.25";
};I tested it in game and this one generates the arrow without the glowing effect OR the impact explosion.
However, it does seem that the projectiles "get" progressively lower until they disappear into the terrain.
EDIT: Found a decent fix for the projectile elevation ... it helps that both the units and buildings come from the same base class.
So we can use
%attacker.getEyePoint();instead of
.getPositionin client game.cs file ...
Its not perfect, but much better than before.
Torque 3D Owner Novack
CyberianSoftware
Actually after fixing this some little time ago, we found an extra problem, that made us crazy for a bit: the stock arrow model is setted (and rendered) beneath the terrain level. Take that in mind! :)