FxShapeReplicator Problem.
by Michael-Paul Jakovlevski · in Torque Game Engine · 09/28/2004 (6:12 am) · 28 replies
I have noticed on some missions when i used the shape rep with the tree model found in torque I kept on finding invisible trees.After much musing I figured that the client is placing trees in different locations than the server.
I modified the code to print out the coordinates of the trees and whether it passed or failed. and after comparing the results from the server the the client and I found that there where identical up to a certain point. At one coord in the list the server passes it and the client rejects it. My guess is that there is some inconsistancy between the client and the server. But I can't figure out what. I have not been able the duplicate this problem. I noticed though that in both cases the problem started when I added a waterblock within the area of the rep. but this could be coincedence.
It was in the 1.2.x versions so it might have been fixed. i dunno.
I modified the code to print out the coordinates of the trees and whether it passed or failed. and after comparing the results from the server the the client and I found that there where identical up to a certain point. At one coord in the list the server passes it and the client rejects it. My guess is that there is some inconsistancy between the client and the server. But I can't figure out what. I have not been able the duplicate this problem. I noticed though that in both cases the problem started when I added a waterblock within the area of the rep. but this could be coincedence.
It was in the 1.2.x versions so it might have been fixed. i dunno.
#2
12/02/2004 (12:28 pm)
I have been having this exact same issue. Again, with me it seems to occur when I either use the fxReplicatorBlocker or WaterBlocks. Since the fxShapeReplicator code looks good, I am guessing that there must be a problem with the gClientContainer/gServerContainer (different objects within each container?) or with mask bits or with the raycasts themselves... 
#3
12/02/2004 (12:31 pm)
Maybe the seed ain't sent from the server to the client? Or something.
#4
12/02/2004 (12:59 pm)
Stefan: I'll look into that!
#5
I just did some debugging and the client is detecting collisions (between possible tree placement locations and fxReplicatorBlockers) about 5x more than the server... It seems as though the client thinks its colliding with a whole bunch more stuff than the server... I'm at a loss... the fxShapeReplicator code looks solid, so its gotta be something with the gServerContainer and gClientContainer being out of synch...
12/02/2004 (1:15 pm)
Just checked it and the seed is sent over fine.I just did some debugging and the client is detecting collisions (between possible tree placement locations and fxReplicatorBlockers) about 5x more than the server... It seems as though the client thinks its colliding with a whole bunch more stuff than the server... I'm at a loss... the fxShapeReplicator code looks solid, so its gotta be something with the gServerContainer and gClientContainer being out of synch...
#6
Anyone have any recommendations on how to ensure that all the fxReplicatorBlocks (and presumably the waterblocks as well...) have been created before starting the fxShapeReplicator?? I know that the fxReplicatorBlocker is started before the fxShapeReplicator in script, but obviously that's not enough... Any suggestions at all?
12/02/2004 (1:36 pm)
Okay, new develpment... I was just doing some more debugging and found that on the server only 2 of the 20 or so fxReplicatorBlockers that I am creating are created before the fxShapeReplicator is created. The rest of the fxReplicatorBlockers are then created after the fxShapeReplicator has finished... While on the client, all the fxReplicatorBlockers are sent over before the fxShapeReplicator is created... This is causing a discontinuity between the server and the client...Anyone have any recommendations on how to ensure that all the fxReplicatorBlocks (and presumably the waterblocks as well...) have been created before starting the fxShapeReplicator?? I know that the fxReplicatorBlocker is started before the fxShapeReplicator in script, but obviously that's not enough... Any suggestions at all?
#7
12/02/2004 (1:44 pm)
Okay! I'm an idiot (sort of). You just need to make sure that your fxShapeReplicator is defined after any other objects (in your mission file) that may interfere with it (ie. WaterBlocks, fxReplicatorBlockers, etc.). The mission file is loaded in order and executed in order, so the fxShapeReplicator will be executed after everything else has been placed, ensuring that you won't get an funky invisible trees... unless you want funky invisible trees :)
#9
So, long story short... make sure your fxShapeReplicator (and any other replicators) are defined last in your mission file.
12/03/2004 (12:34 am)
Yep! You just need to make your fxShapeReplicator the last object in your mission file. Otherwise, when the server goes to create all the shapes for your replicator, it has no idea about all of the objects that are defined afterwards in the mission file, so it creates trees wherever it likes. The client however, gets sent all of the mission objects before it creates shapes for the replicator. The client therefore cannot place trees in the same place because they collide with all of the other objects. Collision is done on the server, but rendering is done from the client, so you collide with the server created trees, but can't see them because they don't exist on the client!So, long story short... make sure your fxShapeReplicator (and any other replicators) are defined last in your mission file.
#10
Glad you go it working okay but I just thought I'd point something out that'll hopefully clarify the situation.
First, I've not looked at the fxReplicatorBlocker code so I won't comment on that but to address the issue or mission-file-order-dependence; I came across this problem when I was originally developing the replicator. I thought that having to ensure that the replicator was after certain other objects and therefore have dependencies in the mission file was a bad idea. I got around this by putting a client-side script-call that tells all the replicators to start e.g. calculate where to replicate based upon the passed seed. This script-call is "StartClientReplication" or "StartFoliageReplication" (for the foliage replicator).
It is called in "clientCmdMissionStartPhase3" (ghosting complete) so that the replicator(s) know that all the ghosts are downloaded to the client before replication begins. As far as I've seen, this has been working perfectly and removes any order-dependencies although I've only tested this for the previous objects I was check collisions on which were the terrain, water, shapes and interiors but I don't see why the fxReplicatorBlockers would be any different.
To cut a long story short, you don't have to ensure any ordering or at least shouldn't. Ignoring the blockers, place one before the terrain, water, interior or shapes to prove this is the case. If it's not working for the blockers then that code will need looking at perhaps.
Hope this helps a little.
- Melv.
12/03/2004 (2:05 am)
Stephane,Glad you go it working okay but I just thought I'd point something out that'll hopefully clarify the situation.
First, I've not looked at the fxReplicatorBlocker code so I won't comment on that but to address the issue or mission-file-order-dependence; I came across this problem when I was originally developing the replicator. I thought that having to ensure that the replicator was after certain other objects and therefore have dependencies in the mission file was a bad idea. I got around this by putting a client-side script-call that tells all the replicators to start e.g. calculate where to replicate based upon the passed seed. This script-call is "StartClientReplication" or "StartFoliageReplication" (for the foliage replicator).
It is called in "clientCmdMissionStartPhase3" (ghosting complete) so that the replicator(s) know that all the ghosts are downloaded to the client before replication begins. As far as I've seen, this has been working perfectly and removes any order-dependencies although I've only tested this for the previous objects I was check collisions on which were the terrain, water, shapes and interiors but I don't see why the fxReplicatorBlockers would be any different.
To cut a long story short, you don't have to ensure any ordering or at least shouldn't. Ignoring the blockers, place one before the terrain, water, interior or shapes to prove this is the case. If it's not working for the blockers then that code will need looking at perhaps.
Hope this helps a little.
- Melv.
#11
12/03/2004 (2:57 am)
Great to see other people are also experiencing some problems with this! At first I tought it was a terrain bug, becuase i kept on crashing into invisible walls. But now I think of it, that's always in the same area as shape replicators, so is it possible I'm crashing into invisible shapes?
#12
Thanks for the lengthy reply to our issues. The problem was actually occuring on the server, and not on the client. RayCasts are done on both the server and the client to create the shapes in the correct locations. The server was loading objects in-order from the mission file, while the client was (as you correctly stated in your post) waiting for all ghosts to be downloaded before starting replication. This is why the shapes were invisible... the server was creating them (hence the colliding) while the client was not (hence the lack of visibility).
If anyone has any suggestions for making the server wait on replication until all other objects are loaded, then I'm all ears!
Cheers,
Stephane
12/04/2004 (5:21 pm)
Melv May,Thanks for the lengthy reply to our issues. The problem was actually occuring on the server, and not on the client. RayCasts are done on both the server and the client to create the shapes in the correct locations. The server was loading objects in-order from the mission file, while the client was (as you correctly stated in your post) waiting for all ghosts to be downloaded before starting replication. This is why the shapes were invisible... the server was creating them (hence the colliding) while the client was not (hence the lack of visibility).
If anyone has any suggestions for making the server wait on replication until all other objects are loaded, then I'm all ears!
Cheers,
Stephane
#13
That is certainly my bad. I seem to have had a fixation on the problem I was having client-side only. Of course you'll have the same problem on the server!!
This is not difficult to remedy although I'm not going to fix it in the next few days, way too busy.
Only relatively minor changes are required such as stopping the server-replicator startup in its "onAdd" and deferring that to a seperate function similar to the "startClientReplication". This function could then be called post mission load on the server. This would fix the problem.
- Melv.
12/05/2004 (1:26 am)
Doh! Nice catch!That is certainly my bad. I seem to have had a fixation on the problem I was having client-side only. Of course you'll have the same problem on the server!!
This is not difficult to remedy although I'm not going to fix it in the next few days, way too busy.
Only relatively minor changes are required such as stopping the server-replicator startup in its "onAdd" and deferring that to a seperate function similar to the "startClientReplication". This function could then be called post mission load on the server. This would fix the problem.
- Melv.
#15
Can you show us the changes you made to the code to get it working.
Thomas
12/17/2004 (8:53 am)
Hi Michael.Can you show us the changes you made to the code to get it working.
Thomas
#16
Can you show us the changes you made to the code to get it working.
Thomas
12/17/2004 (9:02 am)
Hi Michael.Can you show us the changes you made to the code to get it working.
Thomas
#17
12/31/2004 (10:15 am)
I post it as a resource. I was going to do this a while ago but my fix suddenly stopped working and the Server & Client where out of sync again. After pouring over my code for a while I finally realised that it had nothing to do with the changes i made but was due to the fact that mFixShapeAspect was not being sent to the client via un/packupdate.
#18
Michael, if or when you post a resource, could you please come back and post the link to the resource in this thread? That way, people later on who read this thread will have all the info they need to fix the problem.
I don't see myself getting to this problem soon, as I'm also pretty busy with other stuff, but when I get back to it if there's no solution posted yet I'll go ahead and post what I've got.
Thanks!
12/31/2004 (11:21 am)
I am having the same problem, glad I found this thread! I hadn't had much of a chance to look into this problem yet.Michael, if or when you post a resource, could you please come back and post the link to the resource in this thread? That way, people later on who read this thread will have all the info they need to fix the problem.
I don't see myself getting to this problem soon, as I'm also pretty busy with other stuff, but when I get back to it if there's no solution posted yet I'll go ahead and post what I've got.
Thanks!
#19
sorry got distracted for a while *cough*Half-Life 2 *cough*
01/05/2005 (12:22 pm)
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=6947sorry got distracted for a while *cough*Half-Life 2 *cough*
Torque 3D Owner Billy L
but when i reload the mission i get some invisibles .
I never figure out why , maybe Melv has a solution !?