How can I reset map objects?

#1 Just an idea -

Why not copy all the objects and their values from your mission file and place them all inside a function. You could also write a bit of script to delete all the objects first then re-spawn and re-create everything back to original position, just call the function to execute. Hope that makes sense.

#2 OK I have figured out how to take care of all of the MissionGroup and MissionCleanup objects by accessing the simgroup and commanding a fade,delete and respawn. Additionally I added a position and datablock variable to the objects to be recalled later for the respawn. This works nicely.

Now my problem remains with terrain deformation. Basically I need a method to reset the terrain to its initial state. I am using this resource with fixes to the network code done by Gary Preston:

www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=7343

It still has two other bugs I need to work out that maybe someone can give me a hint or two with.

1. Player/Vehicle dust particles lose the texture and become plain black boxes from the emitter for about a second to two seconds. Very noticeable.

2. Foot print/tire tread decals remain floating until they clear if the deformation is placed in a path they just travelled.

I am including the function I have in player.cc that is called from the code during deformation to update the place collision.

void Player::terrainDeformed(void)
{
   // Remove terrain from working list
   for (CollisionWorkingList* itr = mConvex.getWorkingList().wLink.mNext; 
      itr != &mConvex.getWorkingList(); itr = itr->wLink.mNext) 
   {
      if (itr->mConvex->getType() == TerrainConvexType)
      {
         CollisionWorkingList* cl = itr;
         itr = itr->wLink.mPrev;
         cl->free();
      }
   }
   // and force an update of working set
   mWorkingQueryBox.min.x = -1e9;
   // don't update collision set immediatly, leave it for next processTick overwise
   // we end up with a jittering tank in certain terrain deformation positions
   updateWorkingCollisionSet();

}

Any help would be appreciated. I will even speak to Gary about posting an updated resource with the finishing fixes.

#3 Having a bit of experience with the terrain deformation stuff (it's old, but I worked with it very closely for quite a while!), here are some things to take into account:

--the core system is built upon the concept of the client already having the undeformed terrain (as a .ter file), and terrain deformation objects are simply modifications to be made to that underlying terrain. Clearing the application of those deformations should be (theoretically at least) as simple as deleting the deformation objects from both the server and the client (and the ghosting system may even take care of deleting them from the client once you do the server side, but I wouldn't count on it), and then re-loading in the terrain data set from disk.

--I'm honestly not sure what the issue is with your comment number 1, except that the stock deformation system suffers from "needing" a scene re-light, but re-lighting the scene is an extremely long process from the user's perspective (10-200 seconds depending on your scene itself and the lighting used), which obviously isn't appropriate. The only solution I personally have for this is involved and complex--literally pushing the entire scene lighting process into a background thread, and phasing in lighting changes over time. Not in any way trivial, at all.

--the reason you are getting issues with your decals is exactly the same as the reason why you need to update collision stuff in Player--when the decals are placed, it assumes they have no physics based changes that are going to happen (in this case, they have no attachment to the terrain itself, they are simply overlaid). You'll want to look at the code where the decal is originally positioned, and create an "updatePosition" method of some sort, and call it when appropriate (when a deformation happens underneath them).

#4 OK The decals, will be an interesting feat but that sounds like a plan.

I am going to have to find a way to detect and delete the deformations it seems. Not sure yet how, but I am all over it.

As for the particle problem, its not a lighting problem. They say a picture says a 100 words, I think a video says it all.

Particle problems

Thanks again.

#5 Did you notice that the black boxes only appear during the explosion?

#6 @Kevin - Wow you were totally correct! As it turns out this is not a problem with the Terrain Deformer. It was my explosion. Thanks.

#7 @Stephen - Well I managed to figure out how to find all of the deformations, I can delete them. but I will darned if I know how to re-load the terrain data. Any ideas?

#8 Sometimes it just takes a fresh pair of eyes to look at something and notice
that little detail that escapes you.

#9 Yeah now if I can just figure out how to just reset the terrain. I have a working method for clearing the TerrainDeformers. I just need to figure out how to get the server and client to use the data in the original terrain file.

Unfortunately, just because you delete the TerrainDeformer, doesn't mean that the Terrain isn't still modified.

Also, reloading the mission doesn't get rid of the deformations.

#10 Is there something in the TerrainDeformer that sends it's information over the network
connection to the server? Maybe you need to use that same network update method to
update the terrain on the server and the client when you remove the deformation.

#11 I am afraid thats not how it works. It computes the adjustments then eventually adjusts the height at the coordinate with the stock Terrain code which is used with the editor as well. So basically what is happening is on the same level as editing the terrain while making a map, but not saving it to file.

The engine is going to think that is the way things are until you shut it down. With that being said, I have to figure out a way to flush that and reload the original data.

#12 I just wanted to say that I did try what Stephen had said. I deleted all of the deformations server side, then deleted and created the terrain using copies of the original block information in the *.mis file.

1. It didn't fix it, frankly I don't even think the delete thing even worked.

2. It really screwwed up the lighting for the terrain.

#13 I unfortunately, or fortunately, haven't gotten that deep into the code yet.

I'm currently applying the resources from here that apply to the needs of
our game. Digging in to a little C++ code, and some scripting. I suppose
I'll be heavily into it all in a month or so.

#14 Well I completely understand what it is I have to do, unfortunately it doesn't seem that TGE even supports such a thing.

What I have to do is what is present in so many editors these days "Restore Saved File".

The part about updating the clients and such once I get that step out of the way is actually not that hard since for my purposes I respawn all of the moveable items in the map between rounds to restore their positions and states.

I also force all players into a version of spectator mode for the very short time while this takes place. Therefore when they respawn, they will be on the correct terrain and there is no need to clear any working collision sets for client side items.

#15 Well, I think I know what I have to do but I am running into a bit of a snag.

BTW the original resource for this code is www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=7343

My version just has the fixes to make all of the objects update their collision set so they recogize the deformation immediately.

So back to waht I was saying about a snag. I was thinking that perhaps I could set up an array that is adds the necessary location and width and height adjustments. This array could be added to each time a deformation is added. Problem is you have to be able to initialize the variables and clear them between rounds.

This is a feat that I am not sure how to approach. If I were to addd it directly to the Terrain Deformation code it would want to update all of the time. Additionally, if I went from the approach Alex Scarborugh did with batched decal rendering, I still wouldn't be clearing them out every round because his clears based upon time.

As far as I can tell I would have to add this to a higher level parent or such to prevent each instance from interfering. Perhaps I am wrong, I could really use a bit of help.

#16 I did it!! Basically what I have done is modified the datablock code slightly for the Terrain Deformer so I could identify it from items in the MissionCleanup simgroup. Then I created a function in code that reverses the deformation which is called from by a consoleMethod in the for statement I used to search for each deformation.

Then I simply schedule the deformation object for deletion. The process works flawlessly.

Now if I just get the decals that are in the path of the deformation to have their position updated.

Then I will start asking around for permission to release an updated resource with some script examples to do what I have managed to do.