Easy way to iterate through the objects in a scene?
by Gene Foxwell · in Torque 2D Beginner · 02/18/2013 (8:25 am) · 5 replies
Hi,
I am wondering if there is an easy way to iterate though all the objects in a particular scene (what would be better is if I could filter them)?
I am wondering if there is an easy way to iterate though all the objects in a particular scene (what would be better is if I could filter them)?
#2
Providing an engine-defined filter would be a little weird, don't you think? How do I know how you want to filter things? What if you're filtering by the contents of a dynamic field, or the object name (oops, not all objects have names), or perhaps the position or size? However, you can get the scene list and extract what you want from it....
02/18/2013 (4:06 pm)
Try calling getClassName() on your objects and filtering that way for a start.Providing an engine-defined filter would be a little weird, don't you think? How do I know how you want to filter things? What if you're filtering by the contents of a dynamic field, or the object name (oops, not all objects have names), or perhaps the position or size? However, you can get the scene list and extract what you want from it....
#3
With the exception of the dynamic fields ( as I am not entirely certain how they are being implemented yet ) the rest of the fields that are likely to be queried are members of the SceneObject class - so in the simplest case where a user might want to filter by only one field most of the problems could be solved with a ConsoleMethod and some supporting code that say exposed:
getSceneObjectListFilter( fieldName, fieldValue );
And routes them to the to the appropriate support functions on the Scene class based on the fieldName being filtered by. Edge cases like looking for an object names on objects that don't have them would need to dealt with sanely of course but unless there is something seriously weird going on - I imagine the user of the filter looking for object named foo isn't looking for an object with no name and so it could be skipped by the filter.
More complicated filter schemes could be implemented by expanding on the above. (Although there are probably better ways to perform the task when filtering for more than one value).
As for why - I'll admit that part is personal preference. I'd personally rather keep the logic in the TorqueScript as clean as possible. In the case where I am calling getSceneObjectList I am really using as a data store and filtering it afterwards - which doesn't jive well with me if it can avoided. I'd rather treat the "datastore" as I would any other such object normally, query it, get only results I need and work with those.
02/18/2013 (4:53 pm)
I don't think it would "weird" to provide a filter. Difficult to create yes, but not "weird". With the exception of the dynamic fields ( as I am not entirely certain how they are being implemented yet ) the rest of the fields that are likely to be queried are members of the SceneObject class - so in the simplest case where a user might want to filter by only one field most of the problems could be solved with a ConsoleMethod and some supporting code that say exposed:
getSceneObjectListFilter( fieldName, fieldValue );
And routes them to the to the appropriate support functions on the Scene class based on the fieldName being filtered by. Edge cases like looking for an object names on objects that don't have them would need to dealt with sanely of course but unless there is something seriously weird going on - I imagine the user of the filter looking for object named foo isn't looking for an object with no name and so it could be skipped by the filter.
More complicated filter schemes could be implemented by expanding on the above. (Although there are probably better ways to perform the task when filtering for more than one value).
As for why - I'll admit that part is personal preference. I'd personally rather keep the logic in the TorqueScript as clean as possible. In the case where I am calling getSceneObjectList I am really using as a data store and filtering it afterwards - which doesn't jive well with me if it can avoided. I'd rather treat the "datastore" as I would any other such object normally, query it, get only results I need and work with those.
#4
Also, for simple scenes, this wouldn't be so bad but iterating the whole scene a lot can get expensive.
There was so many things I wanted to do with T2D that just wasn't possible in the last year but now things are a little different. Organization of the Scene, to me, is the next important step. Whether that be some form of grouping/tagging and/or a Scene hierarchy.
Anyway, go ahead and create something, test it and create a pull request. Try to make sure it's generically useful. That's how features get in.
02/19/2013 (2:55 am)
I don't see any problem with doing something like that apart from the fact that because Torque uses strings for all fields, the formatting of the contents of a numeric field could easily cause a bad match. For text fields then it's obviously easier, especially if case-insensitivity is the default.Also, for simple scenes, this wouldn't be so bad but iterating the whole scene a lot can get expensive.
There was so many things I wanted to do with T2D that just wasn't possible in the last year but now things are a little different. Organization of the Scene, to me, is the next important step. Whether that be some form of grouping/tagging and/or a Scene hierarchy.
Anyway, go ahead and create something, test it and create a pull request. Try to make sure it's generically useful. That's how features get in.
#5
02/19/2013 (5:25 pm)
I wouldn't iterate the whole scene often - I'd get my list and maintain it separately to achieve this in TorqueScript. But that's probably just because I've dealt with this problem in this engine frequently using the tools as they currently exist. It's easy enough to create simsets of objects and work with them as needed, avoiding the need to sort through the entire scene set. 
Gene Foxwell