Adding TileLayer References to SimGroups Crashes App
by Rodney Rindels - Torqued · in Torque Game Builder · 07/15/2006 (10:59 pm) · 2 replies
*I know one probably shouldn't do this, but they can so I wanted to bring it up.
If you create a SimGroup, and then add a tileLayer to the SimGroup. During object removal the SimObject::onRemove() gets called on the tile layer during removal of the SimGroup.
This causes SimObject::deleteObject() to have an invalid mflags.test(Added) assert throw during the actual TileLayer object removal.
I'm really not sure a good approach to how you fix something like this, warn during addition to SimGroup, that its not a valid object type to add to a SimGroup or dont allow addition of it programatically, or if it was planned to be able to allow it, fix how it removes it as to not clear the mflags(Added) during removal of the SimGroup, so it has a valid test during deleteObject.
If you create a SimGroup, and then add a tileLayer to the SimGroup. During object removal the SimObject::onRemove() gets called on the tile layer during removal of the SimGroup.
This causes SimObject::deleteObject() to have an invalid mflags.test(Added) assert throw during the actual TileLayer object removal.
I'm really not sure a good approach to how you fix something like this, warn during addition to SimGroup, that its not a valid object type to add to a SimGroup or dont allow addition of it programatically, or if it was planned to be able to allow it, fix how it removes it as to not clear the mflags(Added) during removal of the SimGroup, so it has a valid test during deleteObject.
#2
But for my simulation purposes, btw Adding them to a SimSet fixed the problem, since a childObject doesn't seem to be clobbered during onRemove in the same way, maybe because in a SimGroup it can only be a member of one Set.
The before mentioned problem was during a "quit" so the SimGroup would get removed before the TileMap I believe which is maybe why it got destroyed , I wasn't explicitly destroying the child object, I went ahead and added a deleteAllLayers to my game endlevel cleanups to be more prudent anyway.
Thanks Melv that reasoning makes perfect sense.
07/16/2006 (8:26 am)
I had Coffee and rewrote this response, It didn't make any sense.But for my simulation purposes, btw Adding them to a SimSet fixed the problem, since a childObject doesn't seem to be clobbered during onRemove in the same way, maybe because in a SimGroup it can only be a member of one Set.
The before mentioned problem was during a "quit" so the SimGroup would get removed before the TileMap I believe which is maybe why it got destroyed , I wasn't explicitly destroying the child object, I went ahead and added a deleteAllLayers to my game endlevel cleanups to be more prudent anyway.
Thanks Melv that reasoning makes perfect sense.
Associate Melv May
Any object that returns true with "getIsChild()" shouldn't be destroyed either explictily or implicitly using SimGroups etc.
The trouble here is that there are two distinct layers to the engine, TGE and TGB. To stop this kind of thing happening would require 'polluting' the TGE layer with specific cross-application checks.
You are essentially correct in your post in that it should be made as difficult as possible to crash from the scripts but there are many ways of doing so, even before you get to the TGB layer.
For this issue, I'd change it so that you can destroy tile-layers and the tile-map "just deals with it".
- Melv.