There's a design element on this level that is not documented, but is starting to be used in newer scenarios -- the ability to make a terminal trigger a tag, as you'll see in the case of dealing with the computer core. To do this, just add some code to your terminal text that looks like this:

#TAG n

where n, of course, is the tag to trigger. Note that if you put this at the end of your terminal text, it won't trigger if the player hits escape to leave the terminal before getting to that point.

You may also have noticed that, in some terminals, more than two different messages are displayed at various times. Ordinarily, a term can only display the text in the #UNFINISHED or #FINISHED block in the terminal text file. So how did I make my terms display more than that?

Easy. If you look at the map in Forge, you'll notice that the recess where some terms are placed are actually made using TWO polys. The very back of the recess has one term on it. Later I raised the floor of the back poly to be the same as the ceiling and textured the front of that poly with a different term. (You need to make the line between these two polys solid and non-transparent to keep the extra poly from showing on the automap.) Just make sure the frontmost term is light-dependant and that some condition turns that light off -- when the light is off, you'll get the text from the other term. Note that you can stack quite a few terms like this if necessary. The same trick works with switches, though whenever the front switch is inactive, you'll hear the inactive switch sound when you trigger it.

Also note that, for the purposes of light-dependant terms and switches, whether or not the light is "on" or "off" has nothing to do with its active/inactive state. The "on"/"off" state is determined by whether or not the light is above 75% intensity or not. At 75% or lower, it is considered "off". At 76% or higher, it is "on". This allows you to use tricks like the one mentioned above without changing the appearance of the frontmost term -- the difference between 75 and 76 is insignificant to the player, but VERY significant to the engine.

You may have also noticed some interesting behavior with the bay door near the beginning of this level (platform 1 in the picture above). When you hit the switch to open the bay door, you should notice that platform 2 closes first, then platform 1 opens. When you hit the switch again, to close the bay door, you'll notice platform 1 closes first, then platform 2 opens. Further, when the bay door is open, the switch opening the door at the northeast corner of the bay doesn't work. This makes sense, since the Mars atmosphere is still too thin for normal human lungs. But how was it done?

It required a complex series of platforms. The switch that sets everything in motion actually toggles platform 6 (don't look at the actual polygon number for this). When 6 activates, it deactivates the adjacent platform. When the bay door is closed, platform 5 is active and platform 7 is not. In this case, 5 deactivates and tells 2 to activate. When 2 is closed, it tells 3 to activate. When 3 activates, it does two things: tells 1 to activate, and tells 4 to activate (in this case). Platform 1 then tells 7 to activate, and the chain is complete.

When you press the switch again, 6 does its thing again, but this time 7 is active and 5 is not. Thus the activation message propagates back in the other direction, and when all is finished, all the platforms are back in the same state they were originally.

So what the heck does platform 4 do? It controls the light on the northeast door switch. When opening the bay door, 4 stops moving and deactivates the light. When closing the door, 4 starts moving and activates the light.

Note that none of this would work without use of the Doesn't Activate Parent attribute. None of these platforms are allowed to activate their parents, since doing so would keep activate messages propagating through the chain endlessly, causing the doors to pop open and closed constantly for the rest of the game.

Also note that polys 3, 4, 5, 6 and 7 are all at extremely low elevation and the lines between them and polys 1 and 2 are marked as solid and not transparent. This prevents these polys from showing up in any way, even on the automap.

Last, you may notice, if you do some exploring (contrary to Hyperion's instructions) that the water that has flooded the geothermal core is HOT! How's that possible?! Easy -- I used lava. This requires Chisel and the Media Munger plug-in, since lava is not ordinarily an available liquid in the texture set used for this level.

However, you're likely to run into trouble if you try this unprepared. Mainly, because the texture sets containing the lava surface texture and splash effects are not loaded, and thus the engine will crash when trying to draw these things.

You can fix the lava surface problem by messing with the physics model to create a monster that uses Graphic Collection 18 (see the Appearance and Sounds section in Anvil with a physics model open and an alien selected), which is Walls 2 when looking in the Shapes file. Then just stick this fellow somewhere where he'll never be seen, and those textures will load, thus allowing the lava surface to be drawn.

This still isn't enough, though. If it's at all possible for ANY projectile to hit the surface of or travel under the lava, you've got to make sure the lava splash graphics (contained in collection 23, the Scenery 2 collection) are loaded using the same technique. As you can imagine, all this gets a bit heavy on the RAM, so you'll probably need to boost the allocation to the Infinity engine.

In some cases, you can avoid the surface problem. On another level (level 14, We All Fall Down) I wasn't interested in seeing the lava surface. By carefully controlling conditions, I made sure the engine would never need to draw the surface, and thus reduced the need for a surface texture monster.

Splash effects are a bit hairier, though -- unless the lava is in another room behind "glass" (ie, a solid, transparent line), where it's visible but you can't reach it or shoot it. But if that's the case, why not just add a lava texture to the current texture set and texture the floor with it? If the player can enter the lava, you MUST take care of the splash effects. Even if the player never sees the surface, there are still weapons (if your scenario uses the standard ones) that will fire under lava, and this generates a splash -- even if it isn't visible on the screen.

This page copyright 1995-2004 by Thomas Reed.