ConsoleObject & seperating the terrain/interior from scenelighti
by Sander Van Rossen · in Torque Game Engine · 12/05/2003 (1:15 am) · 5 replies
I'm currently seperating the terrain/interior lighting code from scenelighting as part of an to untangle the interior and terrain code in the torque engine.
Right now, part of my solution is to make PersistChunk a child of ConsoleObject so
instead of having rather static enums that identify each chunk (MissionChunkType, InteriorChunkType, TerrainChunkType) i can use the name of the class.
That way, when i load the chunk, i check the name, and i can create the chunk by name.
I've already implemented this, and it works like a charm.
The thing i'm wondering about is this..
I'm not too familiar with ConsoleObject, and i'm afraid that making those chunks ConsoleObjects will have all kinds of side-effects that i don't want
(Like being able to make an InteriorChunk in cs script ;)
So can someone tell me if it's okay to use the ConsoleObject system for this?
I'm going to submit this as a patch when done.
Right now, part of my solution is to make PersistChunk a child of ConsoleObject so
instead of having rather static enums that identify each chunk (MissionChunkType, InteriorChunkType, TerrainChunkType) i can use the name of the class.
That way, when i load the chunk, i check the name, and i can create the chunk by name.
I've already implemented this, and it works like a charm.
The thing i'm wondering about is this..
I'm not too familiar with ConsoleObject, and i'm afraid that making those chunks ConsoleObjects will have all kinds of side-effects that i don't want
(Like being able to make an InteriorChunk in cs script ;)
So can someone tell me if it's okay to use the ConsoleObject system for this?
I'm going to submit this as a patch when done.
#2
the reason why i use ConsoleObject is that i can simply create the proxy by name when i load in the persistent data, and simply save the name of the proxy when saving them.
The lighting code wouldn't need to know anything about the proxies, i wouldn't even have to load in the header file containing the class..
I don't know any other way of doing this, unless i build another consoleobject like factory thing especially for this..
Why would you use ids instead of strings?
using the class ids, like you mentioned, would be a much more imperfect solution because, like you said, it would break the files everytime a new class would be added to the engine..
In fact, it would be rather hard to determine if the files are invalidated because of that.
I've already removed all dependencies on terrain and interiors in the scenelighting.cc file (except the interior lightmap manager), and removed all interdependencies between interior and terrain..
12/05/2003 (5:19 am)
Damn, i was afraid of that..the reason why i use ConsoleObject is that i can simply create the proxy by name when i load in the persistent data, and simply save the name of the proxy when saving them.
The lighting code wouldn't need to know anything about the proxies, i wouldn't even have to load in the header file containing the class..
I don't know any other way of doing this, unless i build another consoleobject like factory thing especially for this..
Why would you use ids instead of strings?
using the class ids, like you mentioned, would be a much more imperfect solution because, like you said, it would break the files everytime a new class would be added to the engine..
In fact, it would be rather hard to determine if the files are invalidated because of that.
I've already removed all dependencies on terrain and interiors in the scenelighting.cc file (except the interior lightmap manager), and removed all interdependencies between interior and terrain..
#3
I think if I was feeling clever I'd emit a bit of a header in the output files that said what class id corresponded to what class name, then use the class ids in the file proper instead of strings. But if I wasn't feeling like doing extra work I'd do what you've done. Or just write a minifactory. ConsoleObject has a lot of crud in it for working with fields and doing inheritance and stuff, which is great, but I'm not sure you care. A simple factory implementation wouldn't be much work, I wouldn't think.
12/05/2003 (9:03 am)
Well, there's no reason why you can't let script create classes it can't do anything with. I mean, they don't expose any fields or methods and they don't register themselves, so the script code would just be doing something useless and harmless.I think if I was feeling clever I'd emit a bit of a header in the output files that said what class id corresponded to what class name, then use the class ids in the file proper instead of strings. But if I wasn't feeling like doing extra work I'd do what you've done. Or just write a minifactory. ConsoleObject has a lot of crud in it for working with fields and doing inheritance and stuff, which is great, but I'm not sure you care. A simple factory implementation wouldn't be much work, I wouldn't think.
#4
I've submitted all this as a patch
12/08/2003 (2:08 am)
Alright, i made a minifactory and everything works like a charm.I've submitted all this as a patch
#5
12/08/2003 (8:50 am)
Awesome! 
Associate Kyle Carter
Are you just trying to get away from the static enums? If so, ConsoleObject is probably overkill, and yes... making them inherit from ConsoleObject will make the chunks scriptable.