Spawn Interiors?
by J. Alan Atherton · in Torque Game Engine · 11/03/2003 (12:29 am) · 15 replies
Is there currently a way to spawn a building from script? I'm positive there is, because the mission editor does it, but even looking through the C++ code is very confusing, and searches left me with nothing. How can I load an interior from the console/script?
Thanks...
Thanks...
#2
function createInteriorShape( %shapeName )
{
// create the obj and add to the instant group
%obj = eval( "createInterior(\"" @ %shapeName @ "\");" );
if(%obj == -1 || %obj == 0)
return;
// %this.currentObj = %obj;
$InstantGroup.add(%obj);
// drop it from the editor - only SceneObjects can be selected...
EWorldEditor.clearSelection();
EWorldEditor.selectObject(%obj);
EWorldEditor.dropSelection();
}
11/03/2003 (1:12 am)
This function can create a building.function createInteriorShape( %shapeName )
{
// create the obj and add to the instant group
%obj = eval( "createInterior(\"" @ %shapeName @ "\");" );
if(%obj == -1 || %obj == 0)
return;
// %this.currentObj = %obj;
$InstantGroup.add(%obj);
// drop it from the editor - only SceneObjects can be selected...
EWorldEditor.clearSelection();
EWorldEditor.selectObject(%obj);
EWorldEditor.dropSelection();
}
#3
Of course, Torque isn't geared towards dynamic interiors, so you won't be able to do as much as you might like without some C++ work.
11/03/2003 (5:13 am)
You can spawn an interior from script (see the createInterior() function, not the createInteriorShape function). In fact, a .mis file _is_ a script file, so all you need to do is look there to see how it's done. You just need to create a code block that properly instantiates the interior.Of course, Torque isn't geared towards dynamic interiors, so you won't be able to do as much as you might like without some C++ work.
#4
Ben, what exactly do you mean I won't get it to do as much as I like without C++? All I need is for the interior to appear at a variable location and orientation, say after I push a GUI button. The lighting isn't terribly important, and they definitely do not need to be moving interiors. What else is not supported that one might need in dynamically spawning interiors?
Thanks again.
11/03/2003 (11:31 am)
Perfect, thanks. It's good to know that the .mis files are just scripts. I understand the lighting stuff, which is not really a problem, since I don't need shadows on the terrain, and I can put lights around the outside of the interior (confused?) inside Quark so they don't appear black. I may fuss around with the terrain lightmaps to improve the feel of the game, but it's not necessary. Ben, what exactly do you mean I won't get it to do as much as I like without C++? All I need is for the interior to appear at a variable location and orientation, say after I push a GUI button. The lighting isn't terribly important, and they definitely do not need to be moving interiors. What else is not supported that one might need in dynamically spawning interiors?
Thanks again.
#5
11/03/2003 (12:39 pm)
Ah, if that's your feature set, you're golden. :)
#6
11/03/2003 (2:20 pm)
Great. Slightly off-topic, where do I look at the createInterior function? Is there some sort of reference or documentation for scripting?
#7
11/03/2003 (2:44 pm)
I tried the code that Heron posted (plus a few modifications) and it says, "cannot find function createInterior" I placed this in game.cs, does it need to be placed somewhere else? Sorry for these basic questions, but I do not know of any good scripting documentation.
#8
11/03/2003 (3:26 pm)
That's because you dont have the function createInterior, as Ben said you need to look at createInterior not createInteriorShape. My guess is that this function is in the editor scripts in common/editor/
#9
11/03/2003 (6:43 pm)
And the editor stuff is only loaded if you're running the editor, which might be why you got an error. You want to see what createInterior does and adapt it to your needs.
#10
11/03/2003 (9:05 pm)
Excellent... thanks for your help, gentlemen. Now I know which direction I'm walking in (or at least I'm trying to make it look like I do).
#11
Here's a trick. Place the interior in the mission via teh editor and put it underground. Now all you have to do is run a function to move it into teh desired position when you want it to appear. Reverse it to the old position when you want it gone. This way it is allready lit, your just moving it in and out of view.
11/05/2003 (3:52 pm)
You can't do it via script. What will happen is even if you can drop the building in without the game crashing, it will be black. Forcing scene lighting on clients to fix it is nasty and not the way to go.Here's a trick. Place the interior in the mission via teh editor and put it underground. Now all you have to do is run a function to move it into teh desired position when you want it to appear. Reverse it to the old position when you want it gone. This way it is allready lit, your just moving it in and out of view.
#12
I have got the building spawning just fine... it appears in the editor group listing. The only problem is when I turn to actually look at the building (i.e. when it renders it) There are two problems that I've seen, and only one that I think is valid: a message window titled "Fatal: ... interior.cc @ 2078. The contents of the window say "Bad texture handle in rebuildVertexColors" I'm still poking at it, since it seems the textures aren't being loaded correctly. When the editor is running, my code works perfectly. When off, the texture problem comes up. If anyone happens to know why interior texture loading seems to not work so well when the editor is not running, I'd appreciate the help. If anyone wants to further check this out, I can post the scripts I came up with (very rudimentary, just to get it working).
Here are those lines of code:
Edit: code cleanup (terrible formatting!)
11/05/2003 (8:48 pm)
Ralph, that won't work for my game, and the interior will not necessarily be black. See, most people only put lights on the inside of their buildings in Quark. Apparently a little-known fact is that you can also put lights _outside_ the building, and it will be effected just the same (I've tried it, it works). If I just put enough lights around the building to light it up, it will be fine. I'm not copying someone else's game idea here making a run-of-the-mill FPS, I'm doing something more original... the buildings will have to be spawned at run-time, since I don't know how many they're going to spawn (Part of the game resembles RTS). Thanks for the suggestion, though.I have got the building spawning just fine... it appears in the editor group listing. The only problem is when I turn to actually look at the building (i.e. when it renders it) There are two problems that I've seen, and only one that I think is valid: a message window titled "Fatal: ... interior.cc @ 2078. The contents of the window say "Bad texture handle in rebuildVertexColors" I'm still poking at it, since it seems the textures aren't being loaded correctly. When the editor is running, my code works perfectly. When off, the texture problem comes up. If anyone happens to know why interior texture loading seems to not work so well when the editor is not running, I'd appreciate the help. If anyone wants to further check this out, I can post the scripts I came up with (very rudimentary, just to get it working).
Here are those lines of code:
TextureHandle* normalLMapHandle = InteriorLMManager.getHandle(getLMHandle(), instanceHandle, mNormalLMapIndices[i]); AssertFatal(normalLMapHandle != NULL, "Bad texture handle in rebuildVertexColors"); const GBitmap* pNormalLMap = normalLMapHandle->getBitmap(); Fails here! AssertFatal(pNormalLMap != NULL, "Bad texture handle in rebuildVertexColors");
Edit: code cleanup (terrible formatting!)
#13
Now I'm concerned if what I've done will cause a problem. What exactly do the functions inside the if-statement do? Will that double-allocate textures in GL? Am I wasting memory? Or is this just a time-saving feature designed to cut down level loading time? I suppose I could just add a new variable that is set when the mission loads, and check against that as well (probably the safest route).
edit: code cleanup
11/05/2003 (11:23 pm)
Ok, after some sleuthing and the VC debugger, I found a section inside InteriorInstance::onAdd that has this code:Interior* pInterior = mInteriorRes->getDetailLevel(i);
// Force the lightmap manager to download textures if we are
// running the mission editor. Normally they are only
// downloaded after the whole scene is lit.
gInteriorLMManager.addInstance(pInterior->getLMHandle(), mLMHandle, this);
// Atherton
// if (gEditingMission) {
gInteriorLMManager.useBaseTextures(pInterior->getLMHandle(), mLMHandle);
gInteriorLMManager.downloadGLTextures(pInterior->getLMHandle());
// }Under where it says "//Atherton", I commented out the if-statement (which explains why it worked when the editor was running). Now it runs perfectly. No hitches as far as I can tell. The interior loads, and its lights from Quark show up nicely, and it's an interior that's not even loaded when the mission loads. If it has already been loaded, then it uses the lightmap of another instance, so the lighting looks normal based on the sun direction and such (which would change if the building rotated). Now I'm concerned if what I've done will cause a problem. What exactly do the functions inside the if-statement do? Will that double-allocate textures in GL? Am I wasting memory? Or is this just a time-saving feature designed to cut down level loading time? I suppose I could just add a new variable that is set when the mission loads, and check against that as well (probably the safest route).
edit: code cleanup
#14
11/06/2003 (11:22 am)
I do not think this will affect the clients, only the server machine. You will have to test this thoroughly. As for what negative effects it would have, I do not know. I suggest posing the question in the SDK forums as I do not have access to the SDK, I am a scriptor :)
#15
- delete the .ML file associated with the mission
- launch the mission (which recreates the ml file)
- dynamically insert a new interior (which isn't lighted correctly, but that's another problem alltogether)
- quit the mission
- launch it again
- this time all the interiors are messed up in colour (have combination of different colours). it's very weird. I also noticed that the ML file is modified for some reason (even though I didn't save the mission after i inserted the new interior).
I believe it has something to do with CRC of the ml file, but i could be wrong. Can someone give me some insight as to what is going wrong here?
thanks
08/18/2005 (10:36 am)
I'm trying to do exactly what J. Alan is doing. I have it not crashing with the lines of gEditingMission commented out. And then I do the following- delete the .ML file associated with the mission
- launch the mission (which recreates the ml file)
- dynamically insert a new interior (which isn't lighted correctly, but that's another problem alltogether)
- quit the mission
- launch it again
- this time all the interiors are messed up in colour (have combination of different colours). it's very weird. I also noticed that the ML file is modified for some reason (even though I didn't save the mission after i inserted the new interior).
I believe it has something to do with CRC of the ml file, but i could be wrong. Can someone give me some insight as to what is going wrong here?
thanks
Torque 3D Owner Marco Meier
Slickware Games