Some thoughts on MissionCleanup
by Tom Bampton · in Torque Game Engine · 11/02/2005 (7:20 am) · 15 replies
So, today I was testing some code I wrote for a contract gig, and discovered a somewhat annoying bug ...
To cut a long story short, I had a callback object that had to persist a little way beyond mission end. The reasons why this is the case are irrelevant. This callback object was used for UI stuff on a lobby screen that was shown just after the first part of mission load, but before the mission had actually been loaded on the client. The upshot of this is that when going back to the main menu and thus disconnecting from the server, the callback object magically got deleted and my console spammed with invalid object errors.
So, after a couple hours of debugging, I finally discovered the cause. And was surprised.
When a mission is loaded, $instantGroup is set to MissionCleanup. This causes the interpreter to add any object created with the Script new operator to that group instead of RootGroup when its created.
This means that after a mission has loaded, everything you create with new is added to MissionCleanup automatically.
So, why the hell is calls to MissionCleanup.add() in the stock starter kits ? Why does "everyone" religiously add their new objects to MissionCleanup, thinking they're avoiding memory leaks ? It seems to me that this is a waste of time, since they'll already be in MissionCleanup.
Thoughts ?
T.
Edit: On a second look, it doesnt look like MissionCleanup.add() is only used on the server, so perhaps I was reading something wrong.
To cut a long story short, I had a callback object that had to persist a little way beyond mission end. The reasons why this is the case are irrelevant. This callback object was used for UI stuff on a lobby screen that was shown just after the first part of mission load, but before the mission had actually been loaded on the client. The upshot of this is that when going back to the main menu and thus disconnecting from the server, the callback object magically got deleted and my console spammed with invalid object errors.
So, after a couple hours of debugging, I finally discovered the cause. And was surprised.
When a mission is loaded, $instantGroup is set to MissionCleanup. This causes the interpreter to add any object created with the Script new operator to that group instead of RootGroup when its created.
This means that after a mission has loaded, everything you create with new is added to MissionCleanup automatically.
So, why the hell is calls to MissionCleanup.add() in the stock starter kits ? Why does "everyone" religiously add their new objects to MissionCleanup, thinking they're avoiding memory leaks ? It seems to me that this is a waste of time, since they'll already be in MissionCleanup.
Thoughts ?
T.
Edit: On a second look, it doesnt look like MissionCleanup.add() is only used on the server, so perhaps I was reading something wrong.
#2
I'm assuming that maybe this is an extra step to ensure that everything gets cleaned up if what you think is correct is.
11/02/2005 (9:43 am)
Here is a quote from Stephen Zepp Quote:To answer the last question about memory leaking--that's the exact reason why MissionCleanup exists in the first place--a safe and easy way to guarantee that at the end of the mission, anything in this group will be removed from memory.
I'm assuming that maybe this is an extra step to ensure that everything gets cleaned up if what you think is correct is.
#3
T.
11/02/2005 (9:44 am)
Yes, I know thats why MissionCleanup exists. The point I was getting at was that since everything is added to it automatically, what's the point in adding to it by hand?T.
#4
Keep in mind (I know you know Tom!) that if an object is currently in a SimGroup, and then is (later) added to a different (or even the same) SimGroup, it is first silently removed from the initial group.
So at most, all you are getting is the overhead of adding to the $MissionGroup--no net change.
11/02/2005 (9:52 am)
@Tom: simply protection. Someone may decide to change $InstantGroup to a different group for whatever reason, and then BHAM! no more automatic adding to $MissionGroup.Keep in mind (I know you know Tom!) that if an object is currently in a SimGroup, and then is (later) added to a different (or even the same) SimGroup, it is first silently removed from the initial group.
So at most, all you are getting is the overhead of adding to the $MissionGroup--no net change.
#5
Good point, of course. Hadnt thought of that. I guess I subconciously assumed that since hardly anybody seems to know of its existence, nobody would change it :)
It seems that an interesting use of the code would be something like ...
new SimGroup(PersistGroup);
$instantGroup = PersistGroup;
then just save it when the mission dies and reload it when it starts, and you have an instant "persistant" world for free ;-)
BTW, spill any coffee lately ? >:)
T.
11/02/2005 (9:58 am)
@Steve,Good point, of course. Hadnt thought of that. I guess I subconciously assumed that since hardly anybody seems to know of its existence, nobody would change it :)
It seems that an interesting use of the code would be something like ...
new SimGroup(PersistGroup);
$instantGroup = PersistGroup;
then just save it when the mission dies and reload it when it starts, and you have an instant "persistant" world for free ;-)
BTW, spill any coffee lately ? >:)
T.
#6
And no, haven't spilled any coffee lately, although I still haven't gotten the coffee smell out of my car :(
11/02/2005 (10:06 am)
@Tom: assuming that your objects serialization all work correctly, that should do some nifty things!And no, haven't spilled any coffee lately, although I still haven't gotten the coffee smell out of my car :(
#7
11/02/2005 (10:09 am)
Hahah, you'll have to get the thing steam cleaned if you havent tried that already ;-)
#8
I only use missionCleanup when i add something after the mission is loaded.
When using the tree function not many things are added to the missioncleanup group from start, except the players and camera and some of my special things.
I have seen people use MissionCleanup.add() before the mission is loaded but nothing really is added in that group what i understand.
11/02/2005 (10:26 am)
Ye really interesting .I only use missionCleanup when i add something after the mission is loaded.
When using the tree function not many things are added to the missioncleanup group from start, except the players and camera and some of my special things.
I have seen people use MissionCleanup.add() before the mission is loaded but nothing really is added in that group what i understand.
#9
Missioncleanup only holds things that are NOT part of the loaded mission. So projectiles, players, cameras are about it in the example. Everything else is tracked & loaded seperately since it comes from the mission file.
11/02/2005 (10:42 am)
Several things change the $instantGroup, the editors foremost among them. So making sure that stuff is in the right place is a very good idea. Setting $instantGroup to point to MissionCleanup is mostly a safety net for forgotten objects (since $instantGroup could be changed at any time to point most anywhere).Missioncleanup only holds things that are NOT part of the loaded mission. So projectiles, players, cameras are about it in the example. Everything else is tracked & loaded seperately since it comes from the mission file.
#10
All you did here is just changed the name from MissionCleanup to PersistGroup right? Or am I missing something?
11/04/2005 (5:36 am)
Tom,Quote:It seems that an interesting use of the code would be something like ...
new SimGroup(PersistGroup);
$instantGroup = PersistGroup;
then just save it when the mission dies and reload it when it starts, and you have an instant "persistant" world for free ;-)
All you did here is just changed the name from MissionCleanup to PersistGroup right? Or am I missing something?
#11
Sure. The important part was in:
Of course, you could also do it with MissionCleanup and not create a new group, but that seems "wrong." In any case, it was just an example of something interesting that could be done with $instantGroup using as few words as possible to explain.
T.
11/04/2005 (6:27 am)
Nick,Quote:All you did here is just changed the name from MissionCleanup to PersistGroup right?
Sure. The important part was in:
Quote:then just save it when the mission dies and reload it when it starts, and you have an instant "persistant" world for free ;-)
Of course, you could also do it with MissionCleanup and not create a new group, but that seems "wrong." In any case, it was just an example of something interesting that could be done with $instantGroup using as few words as possible to explain.
T.
#13
exec("./PersistGroup.cs");
buildLoadInfo("./PersistGroup.cs");
...then those objects show in the mission instantly. Is that enough or do I have to worry about other stuff like clearLoadInfo, dumpLoadInfo, sendLoadInfoToClient?
Nick
12/28/2005 (6:29 am)
Sorry to bring this up again but simply exec-ing the PersistGroup file isnt' enough to make the objects within it actually show in the mission. I figured that if I write this:exec("./PersistGroup.cs");
buildLoadInfo("./PersistGroup.cs");
...then those objects show in the mission instantly. Is that enough or do I have to worry about other stuff like clearLoadInfo, dumpLoadInfo, sendLoadInfoToClient?
Nick
#14
12/31/2005 (2:55 pm)
When you exec it, the objects are created. I have no idea what buildLoadInfo does. Make sure you're not exec'ing it before the scripts clear out data from any previous missions.
#15
Nick
12/31/2005 (5:05 pm)
Yes, the objects are created but they're not visible in the mission. I guess a setTransform() on them would be enough?Nick
Torque 3D Owner Michael Cozzolino
Big Monk Games