Bug: ShapeReplicator issues
by Steve Acaster · in Torque 3D Professional · 05/03/2009 (1:59 pm) · 9 replies
1. When inserting a shapeReplicator you have to save and reload the mission for it's objects to become visible, realtime editing works fine after that.
2. The Placement Area boundary does not display.
3. With a high number of replications there are a few "phantom collisions", collisions for player and projectiles occur where there is no visible object. This is the same problem as in TGEA. so if this is the first you've heard about it my apologies for not reporting that
Just to point out that for Beta3 issues 1 and 2 are fixed but issue 3, the "phantom collisions" are still prevelant.
2. The Placement Area boundary does not display.
3. With a high number of replications there are a few "phantom collisions", collisions for player and projectiles occur where there is no visible object. This is the same problem as in TGEA. so if this is the first you've heard about it my apologies for not reporting that
Just to point out that for Beta3 issues 1 and 2 are fixed but issue 3, the "phantom collisions" are still prevelant.
About the author
One Bloke ... In His Bedroom ... Making Indie Games ...
#2
05/04/2009 (3:38 pm)
Logged for further investigation.
#4
05/25/2009 (2:12 pm)
I get the same result as Steve with the Shape Replicators. :) I also noted that align to terrain sometimes causes the objects to align to themselves ... i.e. Trees mounted on each other at weird angles ... I will see if I can get you a screen shot.
#5
But yeah, the shape replicators do seem to have a few issues as mentioned.
05/25/2009 (2:52 pm)
I've seen trees that were "mounted" to each other in real-life ;)But yeah, the shape replicators do seem to have a few issues as mentioned.
#6
The reason of the bug is that replication is not marked as started. That only happens when a) the mission is loaded and b) we are editing a mission and are on the client side.
It seems like gEditingMission is never true, that's why case b never triggers. The reason is that EditManager::onWake() and EditManager::onSleep() in gui/missionEditor/editor.cpp never get called.
To work around that, we can set gEditingMission in editTSCtrl.cpp instead - we also need to add an onSleep handler:
Don't forget to declare onSleep in editTSCtrl.h right after onWake:
I'm not entirely sure that this is how it's supposed to be fixed, but this works at least.
2. The above solves this one as well.
I imagine that this may have caused other issues, since there are quite a few things that are still using gEditingMission.
05/25/2009 (3:07 pm)
1. Problem & Fix:The reason of the bug is that replication is not marked as started. That only happens when a) the mission is loaded and b) we are editing a mission and are on the client side.
It seems like gEditingMission is never true, that's why case b never triggers. The reason is that EditManager::onWake() and EditManager::onSleep() in gui/missionEditor/editor.cpp never get called.
To work around that, we can set gEditingMission in editTSCtrl.cpp instead - we also need to add an onSleep handler:
bool EditTSCtrl::onWake()
{
if ( !Parent::onWake() )
return false;
gEditingMission = true;
return true;
}
void EditTSCtrl::onSleep()
{
gEditingMission = false;
Parent::onSleep();
}Don't forget to declare onSleep in editTSCtrl.h right after onWake:
virtual void onSleep();
I'm not entirely sure that this is how it's supposed to be fixed, but this works at least.
2. The above solves this one as well.
I imagine that this may have caused other issues, since there are quite a few things that are still using gEditingMission.
#7
Player falls thru polysoup (TGEA)
05/29/2009 (9:15 am)
Some additional testing results related to the polysoup collision bug:Player falls thru polysoup (TGEA)
#8
I don't remember exactly where in the code you need to fix, but the problem was due to the replicated ghosts being created in the opposite order the server replications were created. This caused some replications to fail being placed for some reason and got a new random position on the client. So the phantom collisions are the server objects that got placed elsewhere in the client.
06/09/2009 (7:55 am)
I remember having phantom replicator collisions in TGE 1.3, years ago. I can't believe this is still in. I don't remember exactly where in the code you need to fix, but the problem was due to the replicated ghosts being created in the opposite order the server replications were created. This caused some replications to fail being placed for some reason and got a new random position on the client. So the phantom collisions are the server objects that got placed elsewhere in the client.
#9
edit
pants ... I should have just edited the original post
07/06/2009 (9:45 am)
Just to point out that for Beta3 issues 1 and 2 are fixed but issue 3, the "phantom collisions" are still prevelant.edit
pants ... I should have just edited the original post
Associate Logan Foster
perPixel Studios