Welcome to the world of DromEd, Looking Glass Studio's level editor, and the tool you need to create your own Thief, Thief 2, and System Shock 2 missions. This tutorial focuses on the System Shock 2 version, ShockEd, though the basic principles can be applied to editting for Thief as well. The tutorial starts as a walkthrough, but towards the end tends to be more specific and generalised.
Please keep in mind these editting tools have been released to the public "as is", meaning that the program is unsupported by Looking Glass, or anyone else for that matter. If you run into any problems whatsoever while using these tools do not call Looking Glass, EIDOS, Electronic Arts, Ion Storm or Irrational Games for help!
Another thing to bear in mind is that we do not know everything there is to know about the editor. There was never a comprehensive guide to the editor, so much of what we know has been gathered by experimentation and may or may not be correct. We bear no responsibility for the infromation conatined within. If you do run into trouble you can probably find help at the Editting Forums at TTLG, but please remember that this a community website and we cannot gurrantee that we can help you.
Finally, remember that this is not an official tutorial and was written by fans. It is not definitive and all of it is mainly educated guess work.
When the Dark Engine was first designed DromEd was created as the level editor to carve out the world and place objects within it. Due to the versatility of the system within the engine, it could be quickly and easily adapted to other genres. The engine was tweaked slightly and used to create System Shock 2, and then Thief 2. If you have played all three games you will notice similiarties between them all.
As DromEd was the one and only level editor available originally, all further version bear the same name, including the one for System Shock 2 - it is simply called ShockEd for conveniance, but the actual program name is still DromEd. Within this tutorial the terms dromed and shocked are interchangeable to a degree. Despite the same name you still have to use the correct editor for the correct game. There is some degree of intergration between the three games - the architecture can be loaded between each - but not enough to allow you to edit all three games from one editor. The reason being that each game has different code addons which the others lack. Thief 2 has code for a scouting orb, SS2 code for cyber upgrades, etc.
The main idea with using the DromEditor is to carve out your world and then populate it. 'Architecture' refers to actually building terrain and selecting textures and lighting, and 'objects' are the do'ers in the world. AIs, doors, weapons, keys, keycards are all objects. If you want something to react or change during the level, it HAS to be an object. When you are playing the level the architecture is forgotten about, it is only used visually. In fact the levels on your game disks will not have the architectural plans within them to save space.
To create a level you use a set of geometric primitives to either create a solid object of that shape or to remove a solid of that shape. This system is know as CSG - Constructive Solid Geomerty, and if you have editted for Unreal you will be faimliar with it. These primitives can overlap, and they can be ordered about in time so there is an immense ammount of versatility in what you can create. These shapes act as the plan for your level, you have to tell the editor to build your plan in a process known as 'portalising' (more on that later). Once you have portalised the level you can actually see something while in the game. The terrain in game is independant of the plan. This is why it was safe for the plan to be absent from the levels on disk. Once the house has been built destroying the plan won't remove the house. However, unlike a house, to make an alteration you need the whole plan, so if you want to change a level you have to have the existing plan of primitives already there.
For the object side, there are a number of set object templates named 'archtypes' which are in a class based list otherwise known as the 'Object Hierachy'. What determines an objects behaviour are two areas Properties and Scripts. This is where our biggest hindrance arises, we cannot modify or add the list of properties or scripts, we can only use the ones that are already there, but that is getting into complicated editting. There are also 'Links' which connect objects together and define the relationships between them. You would link a lever to a door if you wanted it to open, but more of this later.
First ou need to own the game to use the editor. Second you need to unzip the editor to the same directory as the game is installed. If when you try to run the editor it exits warning that it cannot find a font or a similar message you probably haven't installed it to the same directory as you installed the game.
This document is intended as a starting point for learning dromed, and is more comprehensive than the tutorials we were originally given for thief. If you have any comments please send them to me, Totality, totality@ultramail.co.uk or Saam at saam@icode.com. Once the community has explored the editor for a bit hopefully people will come along and fill in the blanks in this tutorial. Eventually we hope to put up an online expandable version of this tutorial.
One piece of advice I will give is to read the entire tutorial, even if you don't follow it in dromed. It will save you a lot of problems. Due to the scope that has to be covered some key steps are not 'headed' out, though I have done my best. If you encounter problems with getting the editor to work, the golden rule is to reinstall the game, and then the editor. If you don't seem to be able to pick objects up or interface with the world, check that you have the script loaded and the player linked correctly - this will only make sense once you have read on.......
When you load up DromEd, you'll be presented with the main program interface, separated into four distinct sections:
1.) A menu bar at the top of the screen, as seen in any Windows-based program.
2.) Four separate view windows, which allow you to examine your levels from
four different perspectives. These windows, starting in the upper left-hand
corner and moving clockwise, are "3D View," "Top," "Right," and "Front." You
can use the bracket keys to cycle through the different windows, with the white
outline indicating which is currently the "active" window.
3.) Several buttons, located in the bottom left-hand section of the screen,
used for a variety of functions.
4.) A command line, located in the bottom right-hand section of the screen (in
the small box outlined in light blue), used to enter specific DromEd commands
DromEd is not a completely native Windows 95 program, and doesn't have all the usual features that you would normally expect. The most important of these are preferences. There is no 'preference' window, to make alterations you have to add or modify lines in configuration files which DromEd looks at and acts upon when it loads up. To change screen szie for example you have to add "edit_screen_size 800,600" to dromed.cfg using a text editor such as wordpad. Changes made in this way do not take effect until you restart the editor. I would recommend that you add this line immediately, and possibly choose a higher resolution if your monitor can support it. To change to another resolution simply use the other standard resolution numbers, 640x480, 1024x768 etc, following the same format of the command above. Another reason to change the resolution is that some of the larger menus are 'cut off' on the smaller resolutions and there is no way of changing them.
If you have no experience building levels for 3D games, the first thing you need to do is familiarize yourself with the term "brush." In DromEd, anything that gets created which effects the terrain is called a brush. Rooms are referred to as "room brushes," lights are called "light brushes," etc. The most common brush is the "operation brush," used to create terrain (hollowed-out "rooms" and solid objects). DromEd allows the user to create spaces using six different shapes of operation brush: cube, cylinder, pyramid, corner-apex pyramid, wedge, and dodecahedron. You can think of the default Thief level as being completely solid and stretching infinitely in all directions. In other words, before you add any brushes, the world is just an infinitely huge block of solid. You carve away from that block to create rooms, stairs, structures, and other unique architectural features. So, to create a square room, you would use a cube-shaped operation brush, filled with air, to carve away a square in the center of the existing solid block. If all of this is a bit confusing, don't worry-: everything will become clear once we start building some rooms.
As you can see by looking at the different view windows, there's already a
beginning operation brush in place (a cube) and you're standing right in the
middle of it, as indicated by the violet-colored icon. This icon represents
your camera within the world when editting, and the arm which sticks out represents
your current facing. As we haven't portalised yet (told dromEd to build our
plans) the camera window is still black. Now look down at the bottom of the
screen, to the small, funky-looking texture affectionately referred to as "Jorge."
That's the default texture for the selected brush, but we'll discuss textures
later in the tutorial. For now, look at the buttons underneath Jorge, specifically,
the one that reads "Op
Now that you've set the brush selection to "Fill Air," it's time to "portalize" the level so the change actually takes place in the game world. For the purposes of designing levels with DromEd, portalizing is the process by which your brushes, which are created on the 2D grid, are transformed into 3D space. So, go to the menu bar on the top of the screen, click "Tools," then click "Portalize." Be patient as DromEd processes the brushes. Small levels with just a few brushes usually portalize in just a couple of seconds, but when your levels get larger and more complex, portalization can take a couple of minutes or more. Look at the center of the white bar on the very bottom of the DromEd screen; when it reads "done," the level has been portalized. Whenever you alter the terrain in the level, using one of the 2D views, you will need to portalize to see new changes in the 3D View window and in the game itself. Dromed will remind you if you need to reportalise when you go ingame, with a 'Poralisation is out of Date warning' and will then ask you whether you wish to reportalise. Though this is helpful it also annoying, as if you accidentally modify the terrain you have to reportalise.
Okay, you've portalized the level. It may seem like nothing actually happened, but don't panic: that's just because the 3D View window defaults to a wireframe representation of the 3D world, and it's tough to notice any changes as the wireframe brush has not moved, it has simply been changed from a fill solid to a fill air, and the wireframe view does not show such a change. Move the mouse cursor to the 3D View window and press and hold the right mouse button. Doing so allows you to select from a list of options for the view you currently have the mouse cursor over. We'll discuss these options in more depth a bit later. For now, highlight the choice that reads "solid + selection," then release the right mouse button. This will change the 3D View representation from wireframe to solid, with a white outline indicating the currently selected brush (in this case, the only brush).
Now, if you were using the original dromed for Thief 1 nothing would have changed much, but as you are hopefully using ShockEd a very bright representation of a room plastered with the texture Jorge should be now visible on the 3d view window. This is due to an annoying bug with the Thief 2 and System Shock 2 editors, the level should be completely back but the immediate surroundings of the camera are always brightly lit, we will look at this later.
You can use the WSAD keys to nagivate, W will move the camera forward, S move it backwards and A and D will rotate the camera. Z and C will cause the camera to sidestep, Q and E will move the camera up and down, and head tilt is controlled by R and V. Use the controls now to move about the square observing that the purple icon representing the camera moves about as you do so. Also, the other three viewpoints should automaticlaly centralise on the purple icon, this is because the viewpoints are in synch with each other. You can do stop this, but it is usually more helpful to leave it on, but after zooming in or out of the viewpoints (by right clicking then using zoom in or zoom out) that window will become desynced. To resynchronise it right click and then click synch all. Experiment with the synching and zooming if you wish.
You can teleport instantly to a location using the mouse by right cliciking on the point you wish to go in the plan windows. This engages the defauly right click command - the first one in the list after show/hide grid. For the plan windows it is teleport to location but for the 3d window it is solo view. If you do switch to solo window that viewport will fill up the whole screen, to get back again choose unsolo from the menu.
|
Checklist 1. Right click on the 3dView window in the top left and select "solid
+ selection" to tell the editor you want to see the generated terrain
and the currently selected brush. |
Now, to see the light bug we have to create another 'room' to our world. Now, though we are in our opinon creating rooms, as far as dromed is concerned we are not. A 'room' in dromed terms is something different, used for sound propagation and to help AIs move about the level. The hollow square is simply a fill air brush, and shouldn't be referred to as a room for fear of confusion later on when the real rooms as far as dromed is concerned are introduced.
Let us now create another fill air brush so that we have an extension to our existing one and can observe the strange lighting. The buttons down the bottom should still by on Create, Brush, Fill Air from the last time we editted the brushes. If you have changed them,return them to these settings. Then left click on the edge of the white square that indicates the existing fill air brush and drag out the shape of the next one so that it covers a few of the grid squares. After releasing you should notice two things. First, the brush you dragged out is snapped to the gridlines and that the original room brush semmingly disspaears. The gridsnap is a handy function as it allows your levels to be streamlined. When using it you can be fairly sure that all your terrain will line up with itself, however you may be unhappy with the current snap settings - when the grid snap setting is large you cannot create fine detail. To decrease the level of the snap use the < and > buttons next to the Grid Size on the top left of the bar at the bottom of the screen. A Grid Size of 14 is sufficent enough for general detail. It is better to avoid the smaller grid size settings as after a certain point having the grid activated at that small level makes it useless. The change in colour was due to the difference between inactive or active brushes. By left clicking on either brush you make it active.
Select your new brush if it is not currently selected, and then rotate your camera using the movement keys to face your new brush. If you look in the 3d view window you will see that the brush appears behind the Jorge texture and hasn't actually carved any space out yet. This is because we haven't portalised. Reportalise now using Tools, Portlaise. After doing this your new room brush should be carved out, but you will probably be met by a black rectangle at the end of the brush. If you move forward the rectangle should disappear, but if you look behind you another one will have reappeared in the room you were originally.
If this hasn't happened and you are still left with the room you have to start with then you have probably have either placed the fill air brush so it doesn't intersect with the first one, or you are not on fill air. To rectify simply delete the brush and try again, rememembering to reportalise.
The black rectangle can be explained by lighting. Worlds in dromed are by default pitch black. If no light sources are present you won't be able to see anything. Now, the strange bug in dromed for Thief 2 and System Shock 2 is that the area immediately surrouding the camera is lit up, so as you move about the walls neareset to you will be lit up and those that are further away will be dark. Dromed for Thief 1 hasn't got this problem which is why the level would have been dark.
Now, when editting you often want to see your level clearly, dim light often clouds details, so there is a toggle command which switches between complete light for the whole level or normal lighting. To use this command, click on the command window in the bottom right corner and a purple line should appear indicating that dromed is waiting input. Type 'light_bright' into the window and then press return. If you can still see a back rectangle do not worry, the light bright command does nothing visually until you actually move, so if you move forward the entire level should be brightly lit. Typing light_bright again would deactivate the bright light but you will still have the immediate surrounding brightly lit due to the bug. Note that the light_bright modfiy is only used for editting and only effects terrain not objects.
If you created your new brush in the Top Plan window you will have noticed that the brush automatically has the same height as the original. This is a standard feature, as the windows are two dimensional you define two of the dimensions by dragging and the third is obtained from the brush that was previously selected.
When making a level it is often handy to jump into game mode and walk about your level as you would if you were playing through SS2. Unfortunately, there is once again a slight bug with the System Shock 2 editor which makes this process slightly more tiresome than. For the moment, let us save the mission. The easiest way is to save via the File, Save Mission option. Then choose a sensible filename, tutorial1 maybe. To enter the game you press ALT + G - this will put you in the game at the current camera location if the starting point does not exist, or at the starting point if it does exist.. To return to the editor press ALT + E again, NOT by pressing escape and then quitting. Once in the game you have all the normal movement controls, and as we are using an editor we have access to the full range of commands. Now, when you first go into game mode you are probably going to receive an error message box which says cannot trap the number of rects, click ignore on this mesage to carry on. Once you are in game mode you are for all intents and purposes in SS2, but at the moment the scripts which make the game SS2 haven't been loaded. Currently, you will always enter game mode whether the camera is, as we haven't assigned a starting point. We also cannot collect keys or nanites, but that is for later. but this is important to remember.
If you cannot pick items up, you have no footstep sounds, and you cannot gain attributes your have not linked up your player character correctly, and the first time you enter game mode you will get an error, click cancel it to continue.
Exploring in Game mode has another advantage in that the lighting bug is not there, so the level will either be completely dark or completely lit depending on what the light_bright toggle is set to. You can access the command window by pressing the colon key, if you are in game play should freeze and you should be able to type in commands. Light_bright should still work, but it might not toggle properly in game, and it may seem to stop working. Pressing colon when in edit mode also activates the cursor in the ingame window, and you may do this accidentally. If for some reason you cannot move about or delete an object, the game is probably in the command window, if there is a purple vertical line there press return to abort entering in a command.
Once you have finished looking about your rooms press ALT+E to return to the editor. Have a look at your level and you will notice that it has changed. There is now a smaller cuboid within your level at the precise position where you were before you returned to edit mode and the readout now displays 'Player' and then a number in brackets. This object represents the players model in the game and its presence means that the level on display has changed and is not the same level as you had before you went into game mode. Now, Thief had a backup system where returning back to edit mode reloaded the game to its orginal state unless you told it otherwise. Thief 2 also had such a system, but it has been known to goal wrong, and as far as we can tell SS2 has the controls for the system there but it does not work. This is why we saved the level before going into game mode, as to make any alterations to the level we would have to do them from the original mission. Try to get into the habit of saving before you go into game mode, the editor will inadvertantly remind you if you try to save the level after going into game mode. Try to save your level now, and a warning will pop up saying that the level has run for however much time and will need immediate surgery. Click 'No' to cancel, and then load up the save you had before you went into game mode.
|
Checklist 1. Make sure you are currently on Create, Brush, Fill
Air, and then drag out using the left mouse button on the top plan view
a cuboid which touches the existing room brush. |
So, we've created some fill air brushes…but it doesn't exactly look like an
area in a level. Your dromed window should look like the screenshot below.
Notice that the textures further away look slightly different to those that are closer, this is possibly due to the light bug or it is just the standard way of dealing with far detail, either way it won't be the same in the actual game. Edit Mode is usually a lower quality representation of the level, always check your archiecture in game mode especially shadows as the contrast between light and dark changes between modes. Also you can see the 'light_bright' command in the command window ready to toggle the light off.
The obvious thing which is ruining the illusion that this is a proper level is the Jorge texture. To make a convincing illusion we need to using convincing textures, wallpaper if you like, which we then paint on to the walls. The textures are held in texture families - the textures are split in to groups where similar textures exist together. This allows you to load a family of textures into the editor and you can be sure that they are all of a similar ambiance. To load up textures you usually use the command, 'add_family <familyname>' in the command windowx. For example, type 'add_family shared' in the command window and hit enter to execute the command. Now, let's add another texture family, but this time use a shortcut. Go to the command line again and type "a" - then hit the "Tab" key to cycle alphabetically through all recognizable commands. Use this method to select (or simply type in) the command "add_family msg " to load in the another set. To see the textures that you've loaded in, bring up the texture palette by pressing "Alt+T."
This shows all the textures that are currently loaded in thumbnail format, and from this screen you can remove specific textures that you do not want and put textures on walls. The texture in purple is the currently selected texture, either the last texture you used or the texture of the wall you have currently selected. At the end of the list of textures you will see some blank thumbnails but with text on them instead - Sky,Remove from Level, Put On Brush and Done. Make sure that one of your fill air brushes is selected, it should be white in the plan views and if not left click on one of them to select it. Choose a texture, and then click on the 'Put on Brush' button. You will see the at the texture has been instantly applied in the 3D view, if you don't, it means that your portalisation is out of date. The editor will only update the textures if the portalisation is current, if you resize the terrain brushes and forget to poralise the textures won't visibly change when you tell them to. In actual fact they do change, but you can't see the change until you have reportalised. If this happens to you reportalise as it helps to see what you are doing, applying textures blind is not to be recommened. Another thing that may happen is that the texture only gets painted to one wallIf that happens, it's because at some point you clicked on a face of the wall, thereby selecting that as the "active" face. Using the "Put on Brush" command doesn't necessarily put a texture on the entire brush - it puts it on the selected face. It just so happens that when you first start DromEd, none of the faces is selected; instead, the program starts with the brush in "default" mode. Basically, imagine the default texture as the original color of an entire room. By adding different textures to different faces of the room (walls and ceiling), you're not replacing the default texture, but "painting" over it. So, if you were to create an operation brush with a default brick texture, and then chose other textures for the walls, floor, and ceiling, the default texture would still be the brick you originally chose - it would just be hidden under the other textures. It's easy to tell which face you have selected.
If you still have the texture palette up, remove it by hitting "Alt+T" again. Now, in the 3D View window, click one of the faces of the operation brush. It will highlight in orange, indicating that it is now the selected face. You can also cycle through the different faces by repeatedly hitting the comma (",") key on the keyboard. If you cycle through completely, so that none of the faces is highlighted in orange and the brush is outlined in solid white, then you once again have the brush's default selected. To quickly see which face of the brush is selected, and which texture has been selected for that brush, look down to the bottom center of the screen, to the buttons that read "Face" and "Texture." You can also use these buttons to directly apply textures to any face of the brush, including the default. To reset the default texture of the room, cycle through the available textures using the arrows to the left and right of the "Texture" button. When you've found one you like, hit the "Reset" button, found above the "Face" and "Texture" brushes. This will reset the default texture to the one you selected, essentially allowing you to start from scratch. Now, hit "Alt+T" to bring the texture palette back up. Click a texture so that its name is highlighted in violet, and then click a face to see the selected texture applied to that face. Use this method to apply textures to the walls and floor. Then, hit the "R" key to look up at the operation brush's "ceiling." Click the "Sky" button (also found at the end of the texture palette) so that its name is highlighted in violet, and then click the ceiling to place the star texture.
Dromed with the Texture Pallete Displayed
|
Checklist 1. Press Alt + T to activate the texture palette. |
Hit "Alt+T" again to remove the texture palette, and then get ready to test the level in game mode. Save your level, and then press "Alt+G" to enter to game and take a look around. It should look as if you're standing in a weird tall-walled, open-air space station, with the starry night sky above. It's important to understand that, for level design purposes, the sky is just an illusion. It's actually just a ceiling with a modified texture, and not an actual, limitless sky. So, while it looks as if you could fly up to the heavens, you'd really smash your head against a relatively low ceiling (in this case, the room is still set to the default height - 16 feet). When you're done admiring your craftsmanship, hit "Alt+E" to enter back into DromEd and reload the level. A sky texture is probably not directly appropiate for most of the texture choices in Sytem Shock 2, but you can change what the sky texture is with a bit of fiddling and it may look better if behind a window otherwise players may be upset about the lack of atmosphere. Choose a more appropiate texture for your ceiling if you wish.
As you can see from my screenshot, one thing which seems wrong is the dimensions, the wall texture tesselates twice, and when you go into game mode the fact that you are standing in a large room is striking. Let's resize the brush so that it looks slightly more realistic. Looking at the lower left hand corner of the screen are three buttons which read "D", "W", and "H". These stand for depth, width and height repsectively and the units are approximation of feet. Looking at the windows next to them we can see that the default brush was set to 16x16x16 and the brush that you created as an add on had similar values. Let us decrease the height of the default room to start with. Select the original brush (the square one) and hold down the control key and position the cursor over one of the bottom two 2D windows and press and hold the left mouse button. Then move the mouse around to resize the brush. Up and down will change the height, and left to right will adjust the depth and width depending upon which window you clicked on. Move the brush around until the height is approximately at 8, and then release. It does not have to be precise as the grid should still be active and it should snap to that whole value. You can also see that from looking at the 2D views that the our now smaller room is half way up the other one, lets lower it so that everything has the same floor level. Control resizes brushes and Shift moves them, hold down shift and perform the same mouse operations but this time the brush should move up and down. Align it so that it has the same floor level as the other brush. The settings which correspond to the movement are on the left, X, Y and Z.
If you look in the 3d window you will see that the white rectangle indicating the brush has moved but the actual textures haven't, and they won't until we reporatlise. Do so now. After reportalising we have a new face appearing, possibly Jorge, if so paint a texture on to it. If you wish to walk around your level save the game and press Alt+G like usual to enter game mode, then Alt+E and reload.
There are other ways of changing the position and dimensions of brushes, and the orientation though we haven't met that yet. You can enter in specific numbers for the brush by clicking on the number and typing in a new one, being careful to make sure that any old zeros are not present. Changing a brush in this way doesn't test grid snap - grid snapping is only checked when you move a brush with the shift key or resize it using the control key, so you could be awkward and set a height value of 9 if you wished, but as soon as you use shift or control on it the grid snap will take effect. Another way of performing this commands is to use the < and > buttons to the side of each, these will move the number in very small increments, 0.01 to be specific. This is quite slow and is only useful when making fine alterations, usually when working with shapes which have to be very small such as a sign or when moving objects about as grid snap only applies to brushes.
To demonstrate the orientaiton boxes, the ones in the middle, let's create an iron girder. As we want to create a solid, not carve out space, we need to use the <fill solid> operation brush. Now, changing the <fill air> to <fill solid> will also change the setting of the current brush we have selected, so after we have created our fill solid we need to change the setting back again, else one of air spaces will disappear. Change the operation brush to fill solid and then left click and drag out the a rectangular shape in the top right 2d view for our girder. As the grid is probably still set to 16 it will snap to either 0, 8 or 16. We need to be able to create finer detail than that so decrease the grid snap to 14 using the < and > buttons next to the grid size number. Then resize the brush so that it is a girder shaped cuboid, its height is probably too big. Once you are satisfied, go back to the brush you were on before you created this one and change the <fill solid> to <fill air> again and then reportalise. It may be hard to spot the girder if you are looking at it face on, as dromed is smart to some degree and choose textures that blend in with the surrounding brushes. Move around your girder and you should spot it, and you can then use the Texture Palette to paint it a more appropiate texture, here is what I came up with.
If you get into a muddle you can use the above schematic to construct brushes similar in size and position to mine. We shall now rotate the girder! The rotation key is Alt, holding it down and dragging as with Shift and Control will rotate the object. Once you have rotated it you may have to move it so that it stretches from corner to corner, and you will notice that the second column of numbers by "H", "P" and "B" change (Heading, Pitch and Bank). Also, it is probably slightly too small as you are now stretching from corner to corner. Use the Ctrl key to resize the girder. A point to remember is that the reszing is always done respective to the objects initial postion in the world not its current orientation, so if you rotate the object through ninety degrees then increasing the width will seem to increase the depth from your perspective. Once you have finished rotating, moving and resizing the girder portalise and then move around in the 3d world to check that your construction makes sense.
Now, looking at either your girder or my screenshot you will hopefully notice that the texture is currently aligned with the world and not with the shape. the grid lines are still vertical and horizontal, for the next step is will be better if you assigned a grid like texture to the faces of the girder so that you can see the alteration more easily. We are going to align the texture with the shape. Click on the front face of the girder so it is hilighted in orange, the texture thumbnail should change to that texture. Then click on 'Align' if it is there, and the button should change to the texture rotation and position mapping controls. Instead of the op brush, you now have a U and V, which control the horizontal and vertical displacement of the texture, a scale, and a rotation. Clicking on 'Txt' will change back to the usual controls but we don't want to do that. If we click on the 'AlighNorm' button the texture will be aligned with the shape rather than the world. We could do this manually be setting the rotation to the correct value, but with this method the editor aligns it for you. You can also decrease the scale of the texture here, 16 is the default value. This scale doesn't directly compare to the dimension, decreasing the scale to 15 will mean that the texture tesellates twice as much so it will be more detailed. More detailed textures increase the amount of work the renderer has to do and will slow that area down, so if you have lots of complicated architecture increasing the scale will help ease matters.
I decided to decrease the scale to 15, and after doing so I noticed that the texture wasn't aligned as well as I wanted it to be. To change the alignment of a texture you use the U and V buttons. There is no shortcut key for this, but clicking on either button and dragging left or right will change the setting. This works for scaling, rotating or moving as well, you just click on the correct letter button, 'X' or 'H' for example, and hold and drag. Play about with the U and V buttons and observe how they alter the texture. I also decided to rotate the ceiling texture, as currently it isn't aligned with the room. In this case, the texture is simply made that way, the lines run diagnolly not vertically, so I have to use the rotate option rather than Align Norm, a value of 45 degrees will rotate the texture in line with the room. Using angles and changing texture alignment does mean more work, dromed sometimes will not align everthing up correctly. Here is the same location after my tweaks.
Dromed has a variety of other geomertic pyramids available, but the one you will use most often is the cuboid, you can change the shape you are using by selecting a different one from the shape menu, some of which have a variable number of sides, and the side number is set by the Shapes->Sides In Base, by default it is four, so if you create a cylinder and it still looks like a cuboid you have not specifed the number of sides. Another handy tool is the cloning, if you press insert or the click the clone button, the currently selected brush will be copied, and the copy will be pasted over the existing brush. So if you select your girder, and then press insert and then drag using shift you can easily create another girder on the other side of the room.
As you can remember, the level is currently lit using light_bright, which makes everything as bright. It is an editor command only, and if you were to play through the main game it would be pitch black. Let us put some lights around and also up the ambient light level . The ambient light level is the darkest your level will ever be, by default it is at 0, so the darkest is pitch black. Adding lights to your level will further increase the light of that point, never decrease. For Thief the general recommendation is in 15-20, but if you plan to have little dark areas in your map you could up this to 20-30. To set the ambient light level you use the command, 'ambient <intensity>' where intensity is the right number. For now, type 'ambient 17' in the command window and press enter to exectue, and then reportalise the map. Turn light_bright mode off by retyping the command, and then save your level and go in game. You should be able to just about make the scenery.
Lets, now add some proper lights. There are a couple of light types in dromed. First of all there is the brush light, this is a terrain brush which emits a light of a certain intensity, it has no visible object and you cannot control the radius. To create a brush light, choose light instead of brush off the create sub panel, and then left click and drag where you want to create it. A yellow cross should appear on your plan views, which indicates where the light is.
You can rotate and move this light as you would a brush. The intensity specifies how bright the light is, hue the colour and saturation how much this colour is visible. Once you have changed or added a light, you have to use the Tools->Light command to relight the level, you only need to portalise after you change the ambient light setting.
The advantage to using brush lights is that they do not take up valuable object space, you have a limited number of objects. The disadvantage is that they have no visible source unless you create one using fill solid/fill air brushes, which may make player suspicous, and they cannot be altered in game. Create a brush light somewhere and experiment with its controls, testing it out in game if you wish but remembering to save and reload after you are done.
The next type are 'hacklights' - a carry over term from the Thief dromed. These
have no acual object from which they are emitted, but as they are objects they
can flicker and turn on and off. We could for example create a lever which turned
a red flashing light on and off. The final set are the normal lights which are
also visible objects, like a light bulb. You can do the same things to both,
but the normal lights have an object to go with them.
Let's put some visible lights around the room.
To create any object you usually access the Object Hierachy which lists all the objects available to you. Go to the Editors menu and choose the object hierachy. It defaults to 'Archtypes' in the list box, these means the object templates that you can use. The list is expandable, and clicking on the + will expand that stage. Expand the 'Physical' option, and then the 'Lights' option. You will then see the whole list of available object lights, again some of which can be expanded. This list contains both the hacklights and normal lights, the hacklights are under the 'OmniLights' and the 'Spotlights' but everything else should have a visibe object with them. Click on the light you want to create, for the moment choose 'Wedge Wall Light' and then press create. The Create submenu should automatically default to Create Object, and now when you drag in a 2D window you will create on wall light.
Create one in the middle of a wall somewhere. Lights are yellow in the 2d window so that you can easily spot them. Now, if after creating the wedge wall light you can't see anything in the 3d window do not worry. The wedge wall light is a one sided object, and is transparent from the wrong angle. Rotate it around and place it up against a wall near the ceiling. After lighting you will notice that this light emits a cone of light down. Place some more lights about the room as you see fit. If you highlight the wedge wall light and then go to the object hierachy, it will appear at the position of the wedge wall light, which makes it easy to choose a similar type object.
Now, one thing that it is important to bear in mind is that the hierachy is just a series of templates. All objects have 'properties' which determine what they are and what behaviour they have, if you manually changed the properties you could switch a light into a zombie or a zombie into a light. The object hiearchy just speeds things up by having the properties already in place. This is extremely useful as it means you could have a chair emit light if you wished - if it is an object, you can change its properties.
Lets take a brief look at the properties, click on your wedge light. First of all you will notice that when you click on it the name 'A wedge wall light' and then a number in brackets appears above the sub menu. This text is the name of the object, and the number is its object ID. Dromed will automatically assign a name to every object you create using the name of the archtype that you created it from as a template. You can change this name to make it more recognisable, and this is useful later on when you try to remember which object is which.
Below this name there are a few more buttons which relate to the object submenu. 'Floor me' attempts to align the bottom of the object with the floor and is useful for making sure that tables and other heavy objects are indeed on the floor. 'Class' is a shortcut to the object hierachy. 'Links' opens up a window where you can specify links between objects - more on that later, and 'properties' opens up the properties dialogue box.
Click on the 'Properties' button to look at the wedge wall lights properties. A window much like the object hierachy will pop up.
The title of the dialogue box is once again the name and ID of the object, and within the dialogue box this is once again repeated. The 'cube' symbols that you can see in the hierachy indicates a start of a new object, and everything until the next cube are properties of that object. The object system works under the principle of inheritance, so any object automatically has the properties of objects further up in the hierachy. This is important to remember, as the property editor inadvertantly allows you to edit objects further up in the hierachy, if you look at the screenshot you can see that the next object after 'A Wedge Wall Light' is the 'Wedge Wall Light' itself. The latter is the object archtype, the template, and if you edit the properties of that you will change the properties of all Wedge Wall lights. Also, such edittings will only be temporary as the object hierachy is not saved unless you specifically tell the editor, so any alterations will be lost when you reload the level. A good rule to stick to is that you only edit the first object in the list, everything below it will be an archtype and should not be editted unless you know what you are doing. Another way of differentiating object archtypes with concrete objects (concrete is the term used to describe an object which is actually in your level) is the object ID that comes after it. Concrete objects all have a positive ID, while archtypes have a negative one, as you can see in the dialogue box.
The actual properties are marked by the filled in black dots, and are grouped so that similar properties exist under a relevant heading. So, anything that affects the way an object is rendered comes under the 'Renderer' category. Currently, the wedge wall light only has the Light property, but if you expand the archtype object below and that objects Renderer group you will notice that it will inherit 'Spotlight' and 'LightColor' properties too. Now, if you wanted to change the colour of that light you would not edit the LightColor property that occurs further down in the list as this is the archtype, you would instead 'Add' the property to the concrete object where it will automatically have the same values as the value below. You can then change the values in this property to alter the light without altering the archtype.
At this point you are probably confused, so we'll walk through the steps to Add a property and change it. Make sure the top object is higlighted, as in the screenshot, and then click on the 'Add' button to add a property from the list. A large menu will appear of the available properties, go down to 'Renderer' and then click on 'LightColor'. A dialogue box will pop up allowing you to change the values of that property. Type in 0.33 for the hue, and 0.5 for the saturation and then press Ok. You will notice that the 'LightColor' has appeared in the list of properties for your wedge wall light. If you wish to change the values of a property, just higlight it and click edit, which will bring the property edit box back up. The Delete button will remove the property, but be warned, it only removes the property from that object, and if the property exists further up the Archtype tree the object will then use the inherited settings instead. For example, if you deleted the LightColor property that you have just added the light will revert to the the light colour variables defined in the WedgeWall Light archtype.
The 'Refresh' button is used when the property box needs to be updated, dromed doesn't reload all the data after every operation, so you may need to use this button to make sure the information is entirely upto date but this doesn't occur that often so you can forget about using it. The Hide button hides properties, but again is not generally used.
Properties aren't neccesarily one variable and often have multiple variables that you can edit which govern the objects behaviour. LightColor allowed you to edit he hue and saturation, and editting the light property will allow you to edit the intensity of the light, the radius, and the offset from the object. Properties are the key to how an object behaves, and we do not understand completely what all the properties do. The best way to work out what a property does is either educated guess work and testing with the help of an actual example from the orignal missions or other peoples FMs. Not all properties are designed to be editted though, some are used by the game engine. 'Position' is an example of this, it will automatically be updated depending on where you put the object so changing it manually is not to be recommended. Also remember that some properties will be hidden further up the archtype tree. The property which makes the light sound like glass is hidden up in the 'Lights' archtype, and your concrete object will inherit that property and use it. If you can't work out how an object is achieving a certain effect remember to explore the archtypes for any likely properties.
Now, back to lighting. You should now know enough to experiment with creating lights and changing the lights properties so you can increase the brightness and change the light's colour, so we will return to exploring the light system. In dromed there are three modes of lighting, 'Quick Lighting', 'Raycast Lighting' and 'Object Lighting'. Quick lighting provides a rough lighting model, which will often show unrealistic shadows as it cuts corners in the lighting process to speed things up. When creating a general feel of the level quick lighting will suffice, but when you want to check the ambiance you should really try one of the other lighting models. 'Raycast Lighting' is a much better model but is also slower, there won't be any shortcuts taken in generating shadows but objects will not generate light. Most objects don't cast shadows anyway as far as the lighting model is concerned, but some do. As the lighting in Dromed is quite realistic only immobile objects will can generate shadows, and then only when you use object lighting. Object Lighting takes the longest but can give better results, though it is only slightly different from raycast lighting. To switch lighting models you select the one you want from the Tools menu, and then go to Tools->Light to relight the level using that lighting model.
Remember, the lighting model will not be updated until you tell it to.
It will take time for you to familirise yourself with the contents of the object hierachy, and what objects will suit your mission best. Hopefully you should by now know enough about it to place any object in your level, try adding some decor by using objects from the Object->Physical->Decorative section. For the moment stick to the Physical section, as that is where all the physical objects which you can place in the world exist. If you place a few objects at this juncture you may notice that the object is unlit, as I hinted at above, objects are not effected by the light_bright command. There is a separate command that deals with objects, 'lit_obj_toggle' which toggles objects between full and normal lighting.
Object placement is quite important, objects are not snapped by the grid, which means you have to do all the fine tuning yourself. It may look like your object is aligned up against a wall, but if you go in game, or zoom in, you may notice that there is a very small gap between the object and the wall. Try to always place objects completely flush with the wall, with the floor it is easy as you can use 'floor me' but with the wall the easiest method is to enter in the coordinates by hand. If you are using the grid it is just a case of rounding of the position coordinates to whole numbers, or to the nearest 0.5. If you are not using the grid then you will have to either work out the coordinates of the wall you are trying to align up against or use visual judgement. Orientation of objects is another important necessity. People will notice if an object is the wrong way around, in thief it was torches and in SS2 there is bound to be something that has to be aligned correctly.
Some objects are actually complex composites of others. This is more prevailent in Thief, where there were flames and particle effects attatched to torches, but it could occur in SS2. If you encounter such objects it is important to move the main parent object, and not the child objects. In the theoretical example of the torch you would move the torch and not the smoke. The child objects may not seem to follow the main one, but when you go into game mode they should reset themselves.
Some objects in the hierachy are not meant to be created, they are just there to hold property information for the child objects that occur beneath it and are not designed to be created by themselves, the actual object 'Decorative' has no properties at all and is there for organistational purposes. If you create one of these holder objects then you will see un ugly white wedge where you create the object, which indicates that the object has no valid model.
You will also undoubtedly resize objects in your travels, but resizing objects has another catch to it. Let's create a table to resize, some tables to choose from exist under Physical->Decorative->Furniture->Tables. Pick one and place it in the middle of a room somewhere. Now, to resize you could use the same controls as brushes and the object will resize. The catch is that dromed differentiates between the visual size of an object and the physical size as far as the game engine is concerned. In other words, if you enlarged the table you could walk through the expansion and bump into the original table. To rectify this you have to change the Dimensions property, select the table and open up its properties, and then expand the Physics->Model area, and edit the dimensions property. Make the dimensions in the property match the dimensions next to the DWH boxes. Note that if we were editting a spherical object, such as a basketball, it would likely have a radius setting in the dimensions instead. A shortcut to visual resizing is in the Shape->Scale property, and you will notice that it has some non standard values after you have resized your object. These numbers represent multipliers of the object models intial size. If you wanted to double the size of your object in all three dimensions you would change the scale value to 2,2,2 - assuming it started off as 1 that is. Also, for later on, you cannot scale AIs in this way.
You do not always have to match the dimensions up, some objects do not have a dimension property - usually objects which aren't designed to be walked into. If an object can be walked into then it has dimensions so that the engine can check whether you are walking into it, and if you resize the visual object you should resize the dimensions too. Doors are one example of objects whose dimension property must always be kept in synch with the visual size, but first, lets create a door.
Remember that with Dromed objects and architecture are separate, so creating a door does not automatically create a doorway. You have to carve out a doorway yourself else the door will exist in solid space. Create another fill air brush in your level on the other side of a wall, so that there is a gap of solid between them, and then create a smaller airbrush roughly the size of a door to connect the two. You may have to reduce the grid size to 13.. This will have to be refined later, as doorways are the same size as the doors, and until you choose a door you cannot make the doorway the correct size. For now, portalise, and then make sure that you can fly through one room, through the doorway, and into the next - checking that you can see from one room into the other. This will hopefully prevent one of the few commons stumbling blocks, not having a space for the door to exist in.
The next step is to get a door, object hierachy, Physical->Terrain->Doors. Then choose the Sci Med Door. Create the door in the middle of one of your air brushes so you can notice its size, which is probably bigger than your doorway. Now, you could either resize the doorway to match your door, or the door to match the doorway. For the moment let's do the former. First we check the rotation of the door. If it is the correct alignment that is fine, if it is not, rotate the door's heading by 90 so it is in line with the wall door - assuming that your walls are at standard rotations that is. Note down or remember the doors standard dimensions, D: 6, W: 0.63, H: 10.5. We only really need to use two of these dimensions, depth and height, as doorways are sometimes wider than the door. Hilight the airbrush for your doorway, and type in the depth and height values of the door into the airbrush for a precise fit. If you had to rotate the door, then you will have to type the width in the depth box as the two have swapped due to the ninety degree rotation. After resizing the brush you will probably have to reposition it so that the floor is in line with the other two rooms, reducing the grid size to 12 so that you can move it without 10.5 snapping back to 11. Portalise and the doorway should be the same size as the door. Move the door into the doorway, either manually or by setting the door's location to the doorway's location.
As door's block sight when closed you will have portalise again to make sure that the world is updated. Dromed will construct a black rectangle when the door is closed which will block AIs site. It is this rectangle that you will notice if you resize a door and you don't change the dimension properties, you can see it now by changing the visual height of the door to 3, if you portalise you will notice that you still cannot see through the door due to a black rectangle. If you now change the doors dimension property to 3, and then portalise the black rectangle will once again be the same size as the door. If you had the visual door larger than the physical door it would be harder to spot the problem as the black rectangle would not stick out - however it would be possible to see through the door when closed. Switch back the dimension height setting and the visual height setting to 10.5 and portalise to restore the door to its proper settings. Save and go into game mode to test out the door.
It won't work :)
Now, it won't work as the editor has not been told that you are allowed to interact with the door. Click on the door and then have a look at its properties. It has a Door->Translating property which governs how the door opens - nothing wrong there. What it is missing is its 'FrobInfo'. 'Frob' is the term in dromed for when you use something, when you click on an object you attempt to frob it. The game will check to see if that object can be frobbed by looking at the frob info. If the frob info allows the object to be frobbed it will usually activate the objects associated script. In a doors instance, there is a 'StdDoor' script which tells the engine that the object is a door and will activate the door property and open the door. The script already exists earlier down in the hierachy, under the 'Doors' object. The frobinfo does not exist. Add the property EngineFeatures->FrobInfo to the door. You will have three flag control boxes, World, Inv, and Tool. The 'world' box corresponds to Frobbing an object in the world, like a door or a chest. 'Inv' is when you frob an object in oyur inventory, like a packet of crisps, and 'tool' is when you use an object on another, a key that opens a door. For the door we only need to look at the world script as it isn't intended to be picked up. To make the door work we need to activate the script flag in the world box. Click on the 'none' next to world and toggle on the 'script' flag. This tells the game that when you frob the door in the world to trigger the script, StdDoor, which opens the door.
If you try to test it, it still won't work.
Any new level by default hasn't got the script module loaded which controls the functionality of all objects. You have to load this module every time when you create a new level. If objects and items do not work the way you intend, then the module has not been loaded. To load the module use the command, 'script_load allobjs' in the command window. In shocked there is only one module you have to load.
If you try to test it, guess what, it STILL won't work. (well it might if you are lucky). At this point experienced thief dromeders may start scratching their heads in puzzlement. The reason why the door is not working is that its 'pickbias' is at -20. Pickbias is used to deteremine the priority in which objects are highlighted, if you wanted a key to stand out in a pile of rubbish, by setting the pickbias to such a low value it makes it unlikely that you will select the door, unless you are staring straight at it. Doors are not designed to be selected by default as in SS2 they either opened automaticall or were controlled by buttons. If you add the property, Inventory->PickBias, and change it from -20 to 10, and then save and test, when you go into the level the door will highlight in the world and if you frob it, it will open.
Time for another lesson about doors, once you have tested it out you will notice that the door dissapears! Why? Because it has opened into a solid, there is no space for the door to exist in its opened state as it slides sideways. As well as carving out the doorway you have to carve a thinner space for the door to exist in when opened, the quickest way to do this is to select the fillbrush of the doorway, clone it, and then move it sideways (by default to the left of its current orientation) and then to decrease the width. It doesn't have to the same length as the door, we don't care if some of the door is hidden, we just want to be able to see that the door goes somewhere and doesn't disappear out of sight. Portalise save and test out. The door now does indeed go somewhere, but you may not be happy with the fact that it doesn't fell like a space station door. We can add aproperty which makes it automatically shut itself after a certain amount of time has lapsed, Door->Door Timer Duration. This takes a number which is the time in seconds the door will stay open before closing.
Doors in SS2 weren't normally opened directly, they either did so automatically or were activate using a button. Let us do so using a button first.To speed things up, we'll copy tall the air brushes across in one go. Select the fill air brush of the doorway and hold down shift and select the brush of where the door will go to and then finally the door itself. They should all be higlighted in yellow, with the last one you selected in white. Then press insert to copy the selection and drag the copy down to another wall so we can link to another room. When you move multiple selections the grid is not used, so you will have to make sure you move in whole number intervals much like you had to do when alignign objects. Move the slection roughly into position and then round off the location so that there are no nasty decimal points. The term for these selections are 'multibrushes', when you move them the location coordinates aren't the same as the location coords for the brushes/objects that make up the multibrush. They use some sort of relative system, so rounding off to whole numbers or halves may not always align the objects correctly, especially if the objects aren't correctly aligned to start with. As a last resort, check the objects in the multibrush individually after you have moved them. To do this, click on another object outside the multibrush, and then back on to the object in the multibrush. This will deactivate the multibrush, but it will still be in the memory. If you want to reselect the multibrush you just have to shift click once on another brush object in that group and the WHOLE group will be restored. Multibrushes are useful in other ways, you can save multibrushes to disk and load them up for use later on - much like window's clipboard. Tels has also constructed a way of automatically generating multibrushes which speed up level design if you are brave enough to use it, but more of that later.
Once you have cloned and positioned the other door, portalise and you will
have another door in a doorway. However, this time we want to create a button
that opens the door instead of being able to open the door by frobbing it. Change
the properties of one of the doors so that it has no FrobInfo and the pickbias
is back to the default, either by changing the values back to defaults or by
deleting the added properties so it uses the defaults from further up the tree.
The next step is to create the button, open up the object hierachy, and go to,
Functional->Controllers->SimpleButton->Button#1. Place it next to the
door and align it up against the wall, making sure it faces the right way. Now,
the button is automatically set up to be frobbed, but it currently hasn't been
told what happens when you frob it.
You have to add a 'link' from the button to the door, so that when you frob the button, it sends a frob signal to the door which will then open. To do this, highlight the button and click on the links button, in the window that pops up click on Add to add a link. When you add a link you have to specify the type of link, the object you are linking from and the object you are linking to. It doesn't matter what object you have currently selected, you can add alink between any object. There are many types of link, some of which we don't really use as the game adds them on the fly to help out. The most common, and the one we need to use for the button, is a 'switchlink' (in thief it is controldevice). Now, be careful as every link type is repeated twice, the first set of links have a tilde '~' in front of them. These links are reverse links. When you create a link between two objects, a reverse link is automatically generated going in the opposite direction but going in the opposite direction. To observe this, scroll down to the 'Switchlink' (not the one with the tilde) and then enter in the object ID of the button in the From field, and the object ID of the door in the To field. You can easily get the object ID of the button as it will be shown in the links window but you may need to cancel out to get the object ID of the door. You could use the name of the object instead, which is why it is a good idea to rename objects that you need to link up, but is unlikely that the name of the door is distinctive.
If you are succesfull when you click ok you should see a link with flavour switch link from the button to the door. If either the To or From field is None, then you didn't type in the ID or name correctly, try again and delete the incorrect link Once succesful, select the door you linked to and go to its links, you will see a ~switchlink going from the door to the button. This was automatically generated when you created the first link - remember that links always come in pairs. If you save and test, frobbing the button will now open the door. If the Door->Door Timer Duration is still there then it should still auto shut after the door has opened, though be careful that you could get trapped in the other room once the door has shut again.
You may have noticed that the button has two states, but doesn't shut the door. In fact the button will only ever open the door, not close it. This is curious, as most objects have two specific ways of operating. Doors shut and open, lights switch between min and max. These two operations are controlled by two types of signals, TurnOn and TurnOff, and objects generally do differnent things on both. Now, the switch should be sending both turn on and turn off signals, but if so why won't it shut the door? In thief we could use a lever, which we don't have access to one through the
Let's walk through some investigative work here, the problem could be with the button or the door, let's see if the button effects lights too. Lights can only change state if they are animated, and have the animlight property. The light property is not dynamic and will always provide the same level of light, but anim light can flickers, slide, or alternate between two states. Choose Physical->Lights->OmniLights->Anim Omni Light, to create an animated omnilight in the middle of your corridor near your button. Select the light and edit its properties, the AnimLight one to start with. First we have to set the mode, it is currently on flip between min and max which means the light will flip between min and max when activated, this is okay for our uses but perhaps a more standard light bulb that switches on and off would be better. Change the mode to 'minimum brightness' and then put in a max brightness of about 100 or so, leaving the other options the same. We are telling the light that by default it starts on zero intensity light as defined by are minimum setting. When we send a TurnOn signal through a switchlink the mode wil change to maximum brightness and it should light up. Go back to the main screen remembering the ID number of the light. Select the button that you put next to the door and go to the links screen. We can save a bit of time here, as the editor will automatically resuse the information of a highlighted link, so if we clikc on the switchlink to the door, and then click Add we don't have to enter in the link type or the from field, only the To field where we put the ID of the light. Light so the changes take effect, save the mission and test.
You should find the button turns the light on and off, but always opens the door. Now what can we conclude from that? Well, either the door always interprets the incoming signal as a TurnOn rather than a TurnOff, or the button is sending out TurnOn signals only, but the light alternates between states on every TurnOn signal. What next? Well, actually we could do two things to further our testing, we could have a look at the doors in the actual SS2 levels to look at their auto opening and shutting doors, or we could create another button which is linked in to the light. The logic behind is that if the buttons are alternating between TurnOn and TurnOff then if you turn ON switch A, turning on Switch B should still mean that the light is on.
Test it out yourself, and you should find the two switches to one light will turn the light from min to max brightness (or vice versa) on every button press. So, from this we know that the buttons aren't sending out TurnOn signals.
One of the best ways to learn about dromed is to load up someone elses work and analyse it. For the more obvious effects it is reasonably easy to work out how they were done, lets now load up one of the original SS2 levels and find out how the proximity doors worked. Making sure your level is saved, open the mission 'station.miss'. This will probably take a while as it is slightly larger than your tut level. Once it has loaded you will be confonted with a mass of red and yellow objects - there will not be any terrain brushes in the level. To save space, the terrain brushes were stripped from the level, as after you have portalised you can do that if you don't want to change the architecture any more. You can access the unstripped versions of the level, which is good for analysing how architecture was constructed and allows you to change the scenery, but for analysing how object tricks work you can use the unstripped missions.
To make it easy to navigate, turn on the 'solid+selection' in the 3d window and use the light_bright command so you can see everything. You should start in the space station right after you have chosen your carreer on earth. This level is the one where you would choose your training skills. Move around in dromed, heading for the door to Mission Postings that you would have to go through in the game, looking at the top 2d view to see if you come across any interesting objects. You should notice that the the camera goes through a large red cuboid which surrounds the door, named 'A new Tripwire (95)'. From the name tripwire, you can probably guess its functionality. This will send a signal when something crosses it. If you go to properties, you can see that confirmed. There is a propety, Trap Control Flags, which is set to 'Enter, Exit and player'. This means that a signal is sent when you Enter the tripwire, when you exit, and it applies to the player. You can also see that there is a link to a security door (156), which happens to be the door ahead of you. You may realise that I referred you to a different links screen to add links, well, for conveniance links are repeated on the links screen but be warned that if you add or edit links in this way that it is not completely stable. The best method of adding links is to use the separate links window.
So, we now have worked out that this tripwire is the device that detects our proximity and opens the door, let us go back to our tutorial and try to replicate the effect. Load up your tutorial mission again, and create a new corridor and doorway for our proximity door. Once you have the door, doorway, and the space for the door into, open up the object hiearchy and go to Physical->Traps->Tripwire->Door Tripwire. If you click edit you will see that this object has the same settings as the one we observed in station.mis, create the object at the door position and floor it. Now, you may notice that the tripwire is smaller than the one was used in station.mis. As it is we will probably walk into the door before it opens, so expand the tripwire using ctrl so it covers the length of the hallway and has plenty of time for triggering. What do we have to do next? We have modified the visual dimensions, now we have to modfiy the physical ones. Do so now, then add the switch link between the tripwire and the door, save the mission and test. The door now opens as you approach, and will shut the further you get away. It is quite noticable that the shutting is not instantaneous.
Of course, this still doesn't solve the problem of shutting doors when we want to....well, to be honest, I haven't found a simple way of doing it. There might not even be one. There is a complicated way, using sources and receptrons, but that is a complicated area for another tutorial.
You should now have some basic knowledge in how to make doors, swtiches, and how to use other mission to expand your knowledge.
You have probably noticed that you have no sound in game - the doors do not make sounds. This is where the dromed room brush comes in. For a better sound calculation model, dromed uses room brushes. Sound can only propagate where these room brushes overlap, so you can control where sounds are heard. As you need to be within a room brush to create and hear a sound, all places that the player can visit have to be in a roombrush. You can create room brushes using the drag and drop way by using create room, but as the room brushes are normally going to follow the terrain you have created there is a shortcut key. Higlight the operation brush that you want to use as a template, and then press Shift + insert. A purple cuboid indicating the room brush will appear indicating the room brush. Now, there are a few rules about room brushes. Though they can overlap, there centres never can else you will run into problems. A room brush centre can never be within another room brush. Also, room brushes are always cuboid in shape, but you can resize/move/rotate them like any other brush. Also, you room brushes can corrupt quite easily,especially if you are creating an automap.
Go through your level, adding room brushes. Once you have finished, you have to build the room database for the changes to take effect, much like you did for lighting. The option is available through the Tools menu. Sound will only propagate between connected rooms, and it may be difficult to tell whether room brushes intersect or not. There is a visual shortcut though. There are two options available when you click on a room brush, Show All and Show Sel. When you toggle them on, dromed will display lines which indicate how sound propagates between room brushes. Show All shows all room brushes, and Show Sel only shows the connections to the nearest rooms. Remember that it will only update after you recaclualte the room database. Once you are done, save the mission and test.
One way of helping to see if you room brush centres are invalid is to get dromed to do it for you. Exit out of dromed, and add the line 'check_rooms' to your dromed.cfg, like you did to change the screen size earlier on. This tells dromed to run the room check procedure when you build the room db. Restart dromed and load up your level. Hopefully your room brushes should look normal. Click on a room brush and then copy it by pressing insert, and then decrease the size of the room brush so it is within the original brush. Obviously, the centres must now overlap. Recalculate the room db, and you will notice that both room brushes change colour to a light green. This indicates that their centres overlap, and that you must fix them.
Two room brushes whose centre's overlap hilighted in green.
Unfortunately, this room check facility also checks for another type of error, though it is more of a warning. Usually you do not want sound to propagate through walls, ceilings or floors. The check room facility also checks to see that all your room brush joinings have a fill air brush between them as well, not a fill solid. Remember, that the game doesn't care about wall thickness, so if room brushes join through a solid wall it will sound as if the wall was not there. When the editor detects this error, it will unhelpfully hilight the room brushes in question in the same colour, light green, so it may be confusing as to whether your suspect room brushes are joining through a solid wall or that their centres overlap especially when have a complicated level. The centres overlapping is of more importance and must be fixed, and the editor recognises this, so it will always show overlapping centres in preference to links through solid. If you deliberately create a room within another, and then recompile you should be able to deduce whether the hilighted brushes were a warning or an error. If they go a way, and your deliberate error is the only room brush left highlighted then you can ignore the hilights if you wish to, but if they don't go away, or you have other rooms which are hilighted apart from the one you added, then you have room overlap errors which you must fix.
Rooms are also used to control the automap, change gravity settings, and to trigger events. They can act as a big tripwire which sends a SwitchOn signal to a button, or a lever, etc. The properties that you can assign are under Properties->Rooms. They are different from the way that you would assign properties to objects in there isn't really an example of a 'concrete' room in your level, at least not in the same sense as concrete objects. If you change once instance of a room, you will change all instances. So, if you want to change the properties of a room brush you have to modfiy the room archtype list. Unlike modifying other archtypes, this information is saved with your mission and does not need a new gamesys. To do this, open up the object hierachy, and in the listbox that says 'Archtypes' change to rooms. You should then be shown a different tree which shows the basic room brushes that the level starts with.
To create a different type of room brush, you follow the same procedure you would for objects. Click on the room type you want to create and then click on create. If you then drag on drop you will create a room brush, or if you then press shift and insert it when selected on a piece of terrain it will create a room brush to the same size of the type you last selected. You should notice that these new rooms instead of being called 'Default Room' have the name of the type you selected. Remember to switch back to default room afterwards.
If you already have a room brush present but want to change its type select the room brush and then click 'create' in the toolbar down the bottom. This will bring up the room hierachy and you can then select the room type you want to change to, clicking create again will switch the room brush to what you selected. Note, though it seems that you can do this with objects you cannot.
To create a new 'room' type, go to the room hierachy and select the room type you want to inherit from. This will usually be default room, but try to arrange your tree in a sensible manner. Let's for example make a less damaging version of the rad room. Select 'Rad Room' and then click 'Add'. Type in a sensible name, LowRad, and then click 'no' to concrete room. Your new room will now appear under the Rad Room, but it will have the same properties as RadRoom as we haven't changed them yet. Click on the LowRad and select edit, hilight the LowRad object and add the property Gamesys->Radiation Level. Change the 35 to 15 and ok. We now have a new room type with a lower radiation level which we can use to create rooms in our level like normal. It is vital that you remember that when you change a rooms properties you change all instances of that room in your level, so if you want a room brush to behave differently you have to create a new one in the hierachy and use that instead.
(Note: Radrooms will not cause radiation effects unless the player is linked up correctly, this involves adding a Player Factory link from a marker to 'ThePlayer', once this is done you can pick objects up create footstep sounds and suffer from radiation. See below for more details)
EAX settings work differently, you do not need to create a new Room Archtype for every different setting, you can add these to individual brushes. To do so your room database must be up to date, and you can then select the room brush and use shortcut keys to assign the different EAX types.
The AIs in System Shock2, remain stationary when nothing's going on, they can hear your footsteps, hunt you down, and even run away when threatened. These are all behaviors that are inherent to the AIs, and you as the level designer don't need to worry about controlling them. And, while complex scripts are not available, you can modify AI behavior by assigning patrol routes. Basically, a patrol route allows an AI, let's say a protocol droid, to walk a predefined circuit, by travelling from one marker (similar to a waypoint in a flight sim) to another, to another, and so on.
To define a patrol route, you need place a circuit of markers to indicate that route. In the object hierarchy, go to \Marker\Patrol Path. Place four Patrol Path markers in a square pattern around the room; these are the markers the protocol droid will follow on his route. Now, it's important to know that an AI will start a patrol by heading to the Patrol Path marker that is closest to him in 3D space. How do we make sure the AI starts the patrol at a particular marker? Simple: we create the first marker (or move it, if it was created somewhere else) directly inside of the selected AI. When placing markers, it's important that they always exist inside in the game world (meaning, inside an air brush), close to the floor (up to around 4 feet) where the AI will walk.
Now that the markers have been created, we need to link them together. Click on all the markers and make a note of their object numbers. Then, click on the first one - it should be inside the protocol droid - and bring up its "Links" box (we're basically going to do something very similar to linking the default weapons to the Starting Point). Click the "Add" button to bring up the smaller dialog box. In the "Flavor" field, use the drop-down menu to select "AIPatrol." [Note: Do not use "~AIPatrol." Names with the tilde (~) in front of them are "return" links, and we'll discuss them in just a bit.] In the "From" field, put the number of the currently selected marker. In the "To" field, put the number of the next marker you want the protocol droid to travel to. We placed the markers in a square pattern around the room, so we want the protocol droid to follow a square patrol route. So, in the "To" field, put the number of the next marker in the square patrol route. Use this method to link all the markers together. Remember that we want the protocol droid to walk in a continuous loop, so, when you get to the last marker, link from it back to the first marker. That way, when the protocol droid gets to the last marker, he'll head back to the first marker and start his patrol all over again.
There's one more thing we need to before the protocol droid will follow the markers, however. When you first place an AI, it will remain stationary because that's its default position. Although you've placed the Patrol Pointmarkers, you haven't told the AI to follow them. To change this, select the protocol droid, and then bring up his "Properties" box. Click the "Add" button, and then select "AI," "Ability Settings," and "Patrol: Does patrol." This will bring up a small dialog box containing a small, white, unchecked selection box. Click on the selection box to place a check mark there, and then click the "OK" button to close out the dialog box. Then, click the "Done" button on the "Properties" box to return to the main DromEd screen. By checking the box, you have enabled that AI's ability to go on patrol.
You can also enable an AI's "random patrol," command, so that instead of following the Patrol Point markers in order, the AI chooses a path at random. To do this for the protocol droid, follow the same steps you used for enabling "Patrol: Does patrol," but select "Patrol: Random sequence." This will enable the protocol droid's ability to patrol at random. [Note: "Patrol: Random sequence" is found on the list directly underneath "Patrol: Does patrol."] It's important to note that if you do decide to activate the "Patrol: Random sequence" ability, you still need to activate the "Patrol: Does patrol" ability so the protocol droid knows he's supposed to patrol in the first place.
You may notice that when you open up a marker's "Links" box and go to link from that marker to the next, there's already another link there. It looks similar to the one you're about to create, but there's a tilde (~) at the beginning of the "Flavor" name, and the "From" and "To" links are different. The links with the tilde are called "return" links. Basically, you as the level designer create a link from one marker to the next marker. But DromEd recognizes that one marker also links to a previous marker. While you may create three markers, numbered 23, 24, and 25, and link from one to the next, DromEd goes one step further by linking them backward as well. So, let's say you create a link from marker 23 to 24. Then, you create a link from marker 24 to 25. You have specified that marker 24 links to 25…but DromEd has already linked marker 24 back to 23.
Now that you fully understand the concepts of linking, enter into game mode and watch as the protocol droid patrols around the room. [Important Note: If you enabled the "Patrol: Random sequence" ability, you may notice that at some point the protocol droid walks into the column, and just continues walking into it, instead of trying to go around. That's because you need to update the pathfinding database, as mentioned earlier in the tutorial.]
First let us describe the problem compared to Thief. Like Thief, SS2 is split up into separate levels. Unlike Thief, these levels are not designed to be independant of each other, you can walk between the separate levels from medsci1 to medsci2. This presents a problem to the FM as you can consider SS2 to be basically one big level so slotting in your FM is slightly difficult, it is not impossible.
Here is how the System Shock 2 level progession starts out. The first level that is always loaded is 'earth.mis'. This is where the player can go through the tutorials if he wants to, and then choose his career. After choosing his career the game loads up 'station.mis', where the player will choose his three training missions. At the end of which 'medsci1' is loaded up, and the main game starts up properly.
Now, the level transitions after the very first one work as follows. There are a group of exit objects which have scripts on them that trigger loading up another level. These objects have two properties on them, the first is the name of the level you want to load, the second a 'tag number' which corresponds to where you want to appear in that level. The destination level will have starting points, which is where the player(s) would appear, and these have the 'tag number' which the exit objects must match. The tag number allows you to appear in different places depending upon where you came from.
As you may be able to guess, it doesn't matter what level the destination level is, as long as it has that filename and a starting point with that tag number. So, to replace an original level with your own you would simple make sure you have an object with the a start tag referenced from the previous level and call it the correct name, reasonably simple.
The problem arises in WHEN you insert your level. There are a couple of choice. The easiest is to insert your level at medsci1, after training. This ensures that the player has chosen his class and has trained. Unfortunately it means that the player will have to run through the training missions again, and will be forced to have the same 'background'. Another choice is to insert immediately, at earth.miss. This means you have total control over background but you have to get the player to choose his class, and go through stat increases...First we shall deal with the actual mechanics of level switching.
In shocked, load up 'earth.miss'. You will start at the starting point, which is simply a maker with a 'Player Factory' link to the player arctype, aptly named ThePlayer. Also, there is a property of Shape->ModelName->PlayerBox. Navigate through the level until you get to the point where you choose your career. You should notice that on the top plan view the level change process in this instance is triggered by tripwires. When you go down one of the three corridors there is a tripwire linked to a marker. These three markers have the property Multilevel->Dest level: station, and MultiLevel->DestLoc:2501. The former tells dromed the filenmae to load, and the latter the location where the player will appear. The three markers also have a script on them, (remember that scripts give functionality to objects), 'ChooseService'. Not only does this script trigger the level swap, it also assigns the Player->Service property to the player. The Player->Service property is the only thing that changes between the markers, one for Marine, Navy and OSA.
Now, load up 'station.miss'. You should appear at the starting point for the level, again with a PlayerFactory link to the player, and the playbox property. This is a box the same size as the player, named 'Starting_location'. If you examine its properties you will notice that it has the property MultiLevel->StartLoc:2501 which matched the destination loc from the previous level. These two have to match, else the game will crash, the mapping has to be many->one too, you can have multiple points in one level going to the same location, i.e. multiple instances of DestLock:2501, but you can have multiple instances of StartLoc:2501 as the game will not know which one you are talking about when it tries to jump to it. If you navigate to the end of training you will find a similar set up as the end of station. Tripwires connecting to makers with the MultiLevel->Dest Level: MedSci1 and MultiLevel->Dest Loc->2502. Unfortunately the way in which 'training' works is complicated, so you may have to ignore what goes on in between for now.
Load up 'medsci1' - you may be slightly confused. You will now see four player start markers, none of which seem to have the startloc property. This is due to SS2 multiplayer capabilites, when you reach medsci1 all players join together, so there has to be four separate starting points. The actual marker which has the StartLoc property is (280), and is just left to where the camera starts. It has StartLoc:2502, and 'LandingPoint' links to the four markers which then have player factory links to The Player. These links all have something in their 'data' fields - some link types can have additional data with them, and in this case the data is a number from 1-4 indicating which player number the marker loads. This information is for multiplayer only, for single player levels you can just use a marker with a PlayerFactoy link and the correct StartLoc properties. As SS2 is designed for multiplayer, all start locations from medsci2 on will follow this format - a central marker with the StartLoc property which links in to four makers that load up the players.
We now know enough to be able to transfer between missions. Load up your tutorial level again. (you will probably appear in a blank area. As you have no starting point yet shocked doesn't know where to put the camera so it leaves it where it last was, type the command 'cc 1' to teleport to your level). Open up the object hierachy, Marker->Level Start Marker. Create it where you want the player to first appear in your level. Open up the links and add a Player Factory link, from the marker to '-384' which is the ID of the player archtype. When you now enter the game you will do so from this marker rather than the camera position, and you will have the default stats of the player archtype. You can now collect nanites and keys, the player has footsteps,and the error message should no longer come up. A side effect is that when you enter your mission you will not start with the cybernetic interface enabled, you will just have an empty screen.
Well, actually that is a slight lie. Your cybernetic interface will only be enabled in shocked, if you attempt to run from the main game you will loose it. By defaut the player doesn't have a cybernetic interface and you have to tell the game to display it. This is done by sending a Switch On via a switchink to a marker with the script 'ChangeInterface' on it. A turn off signal will disable it again. To make it so the player starts the level with an interface you could add the property Process->script->0,1,2 on it to the marker. This activates the script on all difficulty levels.
Now, save the mission under the same name, and then save the mission as 'earth'. This will overwrite the existing earth.mis, so you may want to back the original up first, or change its name. Once you have done this, run system shock 2, and start a new game. After the intro you will be in your tutorial level, but you can't access the edit mode.
That is the simplest way of inserting your level into the sequence, quit out of system shock 2 and go back to shocked. Let's now experiement with level changing. Create a new tripwire, but this time a 'TripWireLevel' which has the 'TrapTripLevel' script on it so that it triggers a level change, preferably in an obvious place down a corridor. Add the properties, Mutilevel->DestLevel: MedSci1 and MultiLevel->DestLoc: 2502 to the tripwire. Save, and test. When you load go over the tripwire you should appear at the start of MedSci1. If we had wanted to go to another level we would have specify a different DestLevel and DestLoc.
Load up your tutorial level again. This time instead of going to an offical level we will go to one that we made. Delete a few rooms in your level to make it visibly different from what it was, but keep the corridor going tot he level change tripwire the same. Higlight the starting point and go to its properties, and add MultiLevel->StartLoc: 1000, then save the level as a different filename, tutorial2 for example. reload the the original tut level, and go to the level change tripwire. Change the DestLevel to the name of your modified tutorial level, tutorial2 if you are using that, and the DestLoc to 1000, then save that level. Your two level should now be interlinked, and when you go to the level change point in the first you will appear in the second.
Let us make the link two way, load up the first level and highlight the starting point and add StartLoc:2000 save level and load up the second, change the level change tripwire so it points to the first level, DestLoc: 2000. Save and test. You should now be able to run between the two levels.
As you can probably guess, if we want to insert the user level at medsci1 we would have to call our level medsci1 and have a starting point with the StartLoc tag of 2502. Inserting after this point would be more complicated, as from then on the levels have multiple linkages between them.
So to summarise, either name your mission earth.miss and have a normal starting point, or choose the same filename as station or medsci1, and have the correct StartLoc tag on the starting point (2501 and 2502 respectively).
We have observed that the career choice is governed by the script 'ChooseService' on a marker activated by a SwitchLink. When it receives the switchon signal through the link it assigns the class selected by the property Player->Service. The script also activates the cutscene of the shuttle flying upwards, and changes level if the multilevel property is present. If the multilevel property isn't present it will return the player to precisely the same spot they were in. This presents a problem if you are using a tripwire - as they are in the same spot the tripwire could easily retrigger. You could experiment with teleport traps which teleport the player to another location at the same time the ChooseService script activate, or simply use the level change to load up another level. Other solutions would be to destroy all the markers when one triggers, or to have the level choice triggered by the player pressing a button.
It is up to you what workaround you come up with, possibly even involving including your own small AVIs to replace the ones in SS2.
It is also possible to transplant the scripts used in training into your own mission, this works but you will still have the problem of the cutscenes playing. Another way of going about it would be to ignore the training scripts but to give the player cyber modules to spend instead at the upgrade consoles. You don't even have to offer the player an option to change service if you want - another property of creating a character at the starting point seems to be that they inherit any 'stats' information present on the marker, so you can make it so the player starts off with various skill points.
As another excercise in learning about the editor by dissecting another level, I'll talk you through looking at 'station.mis' and how it implements training. As this is a fairly involved process I cannot really describe what everything does, but I will try to give insight into the vital parts.
After you have loaded the level, and turned the 3d window on, you should be able to move about successfully. The idea is to follow the actions of the player in dromed, thinking about what objects will trigger and what happens next. If we get too confused, we can enter in game and then exit back to the editor to see what actually changed. Apart from the starting point, you will see a smaller invisble marker, which is an ambient sound. From its name, and experience, you can probably guess that this plays the starting sound. It has the 'Ambient Hacked' property on it, the radius is how far you have to be from the marker to hear the sound, and the flags dictate special options. In this case the 'envirionmental' flag is selected, which means that the sound will continue to play at the same volume until another enivronmental sound kicks in. Think of it like background music. Without this flag the sound would appear to emanate from the markers location and when you are too far away you would hear nothing.
There are a few blinking lights around the starting point, but nothing really interesting. When we approach the door we encounter our first trigger. We have the tripwire that opens the door, but we also have some other objects. A trigger-delay, another tripwire, and some more ambient sounds. One of the ambient sounds changes the background music, as it has the environmental tag on it, the other doesn't so it is a point sound. To find out what sound is playing you can tell dromed to play the 'schema'. In dromed, the sound wavs are not played directly. They are instead routed through a schema, which basically contains header information about that sound scheme. A schema can have multiple sound files attached to it so that you don't always hear the same soundfile. You can change the schemas to include your own sounds, but that is another matter. Copy or remember the sound schema name that you want to play from the ambient hacked property, and then type the command 'play_schema <schemaname>', using the name in question. For 'amb shuttle rm(327)' it is 'sta_start' so we would type 'play_schema sta_start'. If the sound schema is looped then it will probably get annoying eventually, the easiest way to turn it off is the command 'halt_schemas'. There is a 'halt_schema' but that halts a specific sound, the other command is quicker.
The other tripwire is interesting, as it is linked to quite a few things. Its object ID is 766, and to quickly find it use the command 'find_obj 766'. This will hilight the object you specify, and it can cope with either the ID or the name of the object. If you click on links you will notice that quite a few processes are triggered when you enter this wire - a droid, a trigdelay, an inverter, and 'SetupInitDebrief'. Now, it would be a good idea to scrawl these obj IDs somewhere so that we can check them all out without having to return to the tripwire. There is also a command which provides a visual representation of what objects are linked together - 'link_draw_on <linktype>'. As the links are switchlinks we need the command 'link_draw_on switchlink'. If you are succesfull then you should see some white lines connecting objects with an arrow midway indicating the link direction. If you zoom out a bit you will see that there are quite a few of these links.
The easiest one to spot is the one to the trigger delay, heading north on your map from the tripwire. If you look at its properties you will see 'Delay Time:20', probably counting in seconds, but there is no indication of what happens next..curious eh? I would suspect that it would normally wait the delay time on receiving an incoming switchon signal and then send that signal down all outgoing switchlinks, but there aren't any outgoing switchlinks for it to be sent down.
Following the other links is quite hard as they tend to run along the same lines, but we know the rough location of where the objects are so we can find them easily. Hopefully you have noted down the ID of the droid, inverter, and SetupInitDebrief. Use the find_obj command to select that droid. Teleport the map around to the NW, until you can see the object selected in white. The switchlink's are now probably getting annoying so we can turn them off with 'link_draw_off switchlink'.
The first thing you should notice is that the droid appears in a room which is badly textured, full of other objects, has no lighting and is completely inaccessible from the main part of the level. This is what is known as a 'blue room' and is where the level designers put objects which the player is never supposed to see, at least until the level designer wants them to. The droid is also doing a good job of being invisible, lets look at its properties.
If you have a look around you will notice one reoccuring feature - this is a low functionality droid. It has 'vnull' for voice, which really means that it doesn't HAVE a voice, it has an Silent Metaproperty down below (metaproperty is a group of metaproperties which can be added to objects to speed up level design, and also can be added/removed during gametime to change object functionality). It doesn't show hitpoints, has an 'alertness cap' of zero, meaning not that much will phase the robot, and it also has not got any references (renderer->Has Refs: false). This 'Has refs' is what makes the object invisible. These all properties exist to speed up the game, this droid will never be seen, never be heard, so there is no point in trying to render it, or for it to speak.
What is it there for then? Well, it has some interesting actions under 'Signal Response'. In dromed, you can tell AIs to perform a specifc series of actions when they receive a signal. This can either be given via a switchlink, as with this droid or you could send the signal yourself from another AI. This signal response is to 'SwitchOn' which means it will trigger when it receives the signal from the tripwire. The priority of absolute means the actions should always be carried out, even if the AI has been killed. If this was a more mundane response, like running to a certian point, absolute would be a bad idea as otherwise if you killed the droid it would perform those actions, and then die. What actions does the droid peform? Well the first is an Mprint, a rather strange command. All it does is actually print a message to the mono log. The mono log is either another monitor connected into your computer (unlikely) or a text file. When the game finds an error it will report it to the mono log if it is minor, if it is major it will probably crash. This mprint command is to help the level designer debug the level. As when the droid starts these actions the mlog will have that text in it. The next command is possibly more understandable, it adds a link between two objects. The type is specified by the first argument, PhysAttach, and the To is the 2nd, and the From is a 3rd. So, it is making object ID 11 be linked to object ID 2. As a note, using these object IDs directly is a bad idea, as it is possible that they are changed, it is much better to use names, and using names also helps readability. The next two steps are blank, and then the droid waits for 4000 milliseconds, so 4 seconds, and then he frobs BUTTON-10.
The next step is, yes, you have guessed it, try to work out what these steps do. First lets find out what that physattatch link does, if you try to 'find_obj 2' or 'find_obj 11' you will discover that these are textures. We know that scenery is static and can't move, so what is going on here? Probably the said object ID scrambling has occurred, and those object ID's have moved. Next is BUTTON-10. Try the command 'find_obj BUTTON-0', if you are having the same luck as I am you can't find it. What is occurring here? Well, the find_obj is not fool proof, especially if objects have changed names or are similariliy named. Let's get a full object list and see if it is on that. To do this we need to tell the editor to put the mono log to disk. Type the command 'mlog statobjlist.txt'. From now own all monolog messages will be sent to that file. Then type the command 'list_obj 1' to get the editor to dump the entire object list to the mono log, and finally, 'mlog close' to close the file so we can access it. If you load up the textfile in wordpad you will notice that there isn't a BUTTON-10. So, it seems that this droids only purpose is to print that message. Chances are that this droid was originally there for the 'launching' of the shuttle. if you have a look around in dromed you will notice a series of T-Paths leading out into space, with no shuttle. The addlink probably added a particle effect to the shuttle, and the button caused it to take off. Obviously this feature was removed. :(
Back to the tripwire links. Next is the inverter. Inverters default behaviour is to turn a switchON signal into a switchOFF one, and viceversa. The inverter links into a wedge wall light. The switch signal to the inverter is going to be on when you enter the tripwire, and the link from the inverter to the wedgewall light will therefore be a switchOff signal, which will probably turn the wall light off. Now, if we look at the properties of the tripwire we will see that it only sends a signal on 'Enter', and only 'once', so that is the only signal the light will get. Now, if we look at the wedge wall lights properties that the inverter links to, we will se that it starts on maximum brightness and is also apparently inactive. This implies that the signal could either turn the light on, or turn it off, depending on what it changes. More experimentation would be required to find out what it does - for our purposes it does not really matter.
Next on the tripwire list is the 'SetupInitDebrief', if we find that it appears to be a marker with the 'SetupInitialDebrief' script on it. As yet, we don't know enough to speculate what this script does. Now, we have exhuasted all the switchlinks so we continue throught he level. The next bunch of objects are decorative ones, they have no real interesting funcitonality. The next juicy bit is hidden in the room with the protocol droid, just before the mission postings. There is a large tripwire, named DEBRIEF1-START, which links into DEBRIEF1-DROID, which just so happens to be the droid in front of you, and to DEBRIEFTrap1. This droid is operating like the one in the blue room, but is visible this time. On the SwitchOn response he frobs DEBRIEF1-BUTTON, and adds a switchlink between a tripwire and a door. The door in question transpires to be the door leading to the mission selection - so the tripwire won't open the door until you have walked into the first one, which you have to do to get to the tripwire anyway.
DEBRIEF1-BUTTON connects to another wedgelight, and another droid, aptly named DEBRIEF1-DROID2. The wedge wall light is the one above the door, and seems to be connected to a bunch of other inverters. Best guess for its function is again some sort of debug tool - to indicate what state the mission choice is in. The other droid appears to be hiddden in the corner rather amusingly. When you at that droids signal response you can see some rather intriging code. It removes a link between the tripwire at the start, and the first droid, then it waits 35 seconds, and then it puts the link back again. Curious.
Last step of call is the DebriefTrap1. This seems to be a sound trap, but it hasn't been told to play a sound, as the object sound property is balnk...Even more curious. Now, it is hardly likely that all this logic does absolutely nothing. Chances are that something happens midgame which assigns a proper property to this object, and yes, checking back you should rember that we had a script, SetupInitDebrief that we couldn't work out who's purpose. Let's test out this theory. Go into gamemode, no need to save, and walk through the door. You sould notice that a massive 'Year 1' appears, obviously triggered by the script. Go back to edit mode and lets see what has changed. If you analyse the properites of the debrieftrap1 now you will see it has a sound, init_1. So that is that mystery solved, though unsure why the droid does the waiting bussiness before reestablishing the link, perhaps the message was meant to reninitilise after the first time....
Onward, without reloading, the next thing we come to that actually does something are the tripwires in front of the mission posting doors. You will also notice that the correct 'boards' have been set up as well for your class. This is also handled by that first script. We did pass a restart marker, and another ambient sound, but that is obviously where the player respawns after choosing a mission. The tripwires in front of the mission do two things. They all link to a BriefTrap, which has the correct object sound property assigned by the DebriefTrap1 script, and they link into inverters. The inverters link into the other two BriefTraps, and will send an Off signal to them. Basically this is so that when you walk on a tripwire, it stops the other two sounds playing if they were playing, and starts the one you walked near, and also displays the correct quick text describing the benefits.
Exploring down the end of the three tunnels we find in each a tripwire linked into a maker. Each of the three markers has similar properties, they all have Multilevel links into medsci1, they have the 'ChooseMission' script, and they have a player CharGenRoom: #. The marker on the far right having 0, the one in the middle 1, the one at the end 2. This properties tell the script which mission the player chose, but how does teh game know what year the player is on?
Well, if you carry on with the level in game and choose a mission, and then look at the properties of the check the 'Player' model you will notice a Player->Char Gen Year, which climbs as you carry on choosing missions. When this reaches the final year, instead of sending you back to choose again, the game loads up the next level. This last bit is perhaps the most important for creating your own training process. The ChooseMission combined with the chargenroom and player year is the actual 'doings', the signs shifting around is really icing on the cake and you don't need to transplant those parts at all, as you could reproduce it yourself without resorting to the custom scripts. If you DID want to transplant the whole thing, the point to remember is that the names of the vital objects have to be the same else the script won't work as expected.
You can quite easily place the chargen corridors in your level using a tripwire connected to a marker with the ChooseMission script and chargen room on, and hopefully you should have a better idea of how to dissect a feature that you want to reproduce.
Depending on how you view it, the way in which ShockEd handles quests and objectives is either a blessing or curse. Unlike Thief Dromed, there is no separate scripting commands for adding quests. In Thief Dromed, you would create a specific quest type which could be viewed on your objectives screen, Get The Bafford Scepeter for example. ShockEd doesn't use this victory checking system, instead goals are handled via the object system. Certain markers have scripts on them which allow custom variable flags to be set. These flags are accessible through the entire game, irrespecitive of what actual 'level' the player is on. There also exists triggers on these custom variables. The general idea is that you have a trigger waiting to do something when a variable is set. For example, turn elevator on when ElevatorON is 1. You then would have a set trap that sets ElevatorON to 1 when the player did whatever was necessary to turn the elevator on. This system is more versatile than convict, but is perhaps harder to learn.
The actual goal notes displayed on screen has to be done separately. If you did set up a system that disable the elevator like this, then there wouldn't be a corresponding note - you would have to create it yourself and toggle it complete the same time as the elevator started working.
The collection of objects which perform these checks are known as 'QuestBits' in the hierachy, and exist under Traps. There are five of them, QB Trigger, QB Filter, QB Set, Anti-QB Trigger and Simple-QB Trigger. Like all other Traps they work on SwitchLink signals, and they all make use of the properties Script->QBVal and Scripts->QBName
A QB Set is the one you would use when a quest would be complete. On an incoming SwitchON signal through a switchlink they set the variable defined in QB Name, to the number in QB Val.
QB Filter's act like an AND gate. They only allow SwitchON signals from the incoming SwitchLink to pass if the variable named in QB Name satifies the value in QB Val. Useful when you want a device to only work when an objective has been completed. Remember that it doesn't actually produce a switchon signal, it only allows one to pass.
An Anti-QB Filter allows the switchon signal to pass when the condition is not satisfied, keep spawining monsters until you click a switch for example. Remember that it doesn't actually produce a switchon signal, it only allows one to pass.
A QB Simple Trigger seems to send a switch on signal when the variable changes. We are guessing this as the examples that we have looked at in game do not have a QB Val setting.
A QB Trigger is different from a simple trigger. It takes an incoming Switch Signal and executes any relevant property on the marker if the variable named under QB Val is satisifed, ie, displays a message such as "Computer Online". It does this by using the UseMessage: MessageName property, which displays the corresponding message from usemsg.str in the strings.crf file.
An Anti QB Trigger is the same as a QB Trigger but activates the message when the variable is not set
When the player has completed all his tasks, you will proably want the game to end. It might get disorientating if the player finishes off and stays in the game. System Shock 2 only ends once, unlike Thief where every mission has to end at some point. There is no victory check script in system shock 2 - in other words the game doesn't really care if your objectives have been completed or not, you could end the game at any point whether the player has finished his task or not. The closest process you have to finishing the game is the 'dieshodandie' script -this is just added to a maker and is triggered on a switch on signal through a switchlink. Upon receiving the signal it activates the last cutscene, cs3 and you will not return back to game mode. Of course, you have to send the SwitchOn signal in some way, and any method that sends a signal will do - buttons, creature death, QB triggers, etc. The idea behind the link to the marker is that the signal only gets sent when the player has completed his objectives, either by sending the signal from a QB trigger when the last objective is complete, or by having the trigger in an area which is inaccessible until you have compelted all other objectives.
Failing the mission is a bit more difficult. Again there was no real way in SS2 of failing, apart from dying, so there is no script that we have found that triggers a 'fail' sequence. If you could find some way of irrevocably killing the player and reducing his nanite total you could possibly force an end sequence, or you could try to use one of the other cutscenes and include your own cutscene AVI.
Of course, the AVI files that are played will be the ones that came with the main game, unless you replace them with your own AVIs using a video editor of some sort. As there is really only one ending script you could just forget about the end AVI and just send the player an email, saying either mission succesful or mission failed, and then trigger the dieshodandie script which then shows a blank AVI.
There are plenty of scripts in SS2 which can be customised for your own purposes, and not all are on objects in the hierachy. Apart from the ending 'dieshodandie' script, there's 'ChangeInterface' which activates the interface on a turnon signal and turns it off again on a turnoff signal. Most of these can be found by going through the official levels looking for makers which have a script property on them. Unfortunately, their purpose may not always be immediately discernible - experiment with the objects involved and remember that object names are often critical.
You will undoubtedly want to include your own emails and logs throughout your level. This involves creating your own resource files, by modifying the orignal collections that came with the game. The resource files are stored in the 'crf' files, which either are in your installation directory, but if you cannot find them there they will be on the SS2 cdrom in the shock directory. Despite the strange extension, they are just zip files and can be opened up in winzip.
Here's a list of what the crf's are called and what they do, the more useful ones to start with are in bold.
bitmap.crf - Contains bitmaps for particle effects and explosions, not really
editted that much.
books.crf - Contains the pcs files which adorn emails and logs - logos,
peoples faces,etc.
editor.crf - Small crf containing the font that dromed uses and a mouse pointer.
No real use for level editting.
fam.crf - Contains the texture families, follow the same format of the
directories to create your own textures, or replace existing ones.
fonts.crf - The different fonts used in the game.
iface.crf - more fonts and pcx files for the interface.
intrface.crf - pcx files for interface, but also contains the map files
and string file settings which dictate text such as difficulty level.
mesh.crf - contains the models for AIs and skins. Models are created
using maya, but skins can be adjusted using any graphics program.
motions.crf - contains the motions that AIs play.
obj.crf - contains the nonAI objects, created using 3dstudio and can
be created using free model editors. Skins as well.
objicon.crf - contains the icons that appear in the inventory for all
objects.
pal.crf - contains the palettes to help create objects and textures.
snd.crf - contains the ambient and creature sounds.
snd2.crf - contains the voice overs for briefing, logs, and email traps.
song.crf - list of schemas to play for songs, not really that well known yet.
strings.crf - String files containing object name, email text, logs,
etc.
Now, you could edit any of the files in these crfs, and then put it back into the crf and the game would work fine. Unforunately, you would have to distribute the whole crf to get your level to work - a nasty prospect. Luckily, the game engine looks for specific local copies first, and uses them if it finds them instead. To enable this special mode you have to optimise your installation, something familiar for Thief Gold users.
Make a new dir in your /sshock2 dir called RES, then move all files ending with .crf into this folder. Then edit your "install.cfg" to read: resname_base C:\Sshock2\res.
Once you have done that, to create a new local file just create a directory of the same name as the .crf file, and place your new file in that directory, making sure the directory structure is the same as it was in the .crf. For example, lets say you want to include a new 'level01.str' file which appears in strings.crf, after optmising your installation you would create a golder called 'strings' in your ss2 directory, and you would then place the level01.str in that folder. If the file had been in the \levels directory in the .crf file, you would have put it in the SS2\strings\levels directory. If you do not optimise your installation, your FM may not pick up your new file.
Logs and emails are sorted by what deck they appear on. Shocked has nine different decks to choose from, and by default are named as per the main game. They are sent using Data Traps, which are markers with a script on which activate when they receive a TurnOn signal. For the main types of information relay traps, MediaTrap, EmailTrap and LogTrap, you add the property Logs->Deck#. You then choose a flag in the correct box corresponding to the number you want to create. This information is used to display the correct text, and to play the correct soundfile.
The text is contained and the strings.crf, in the level##.str files, where the number corresponds to the deck number property you added. If you open up the file in the crf you will see a specifc format to the file, here's the first log out of level01.str
EmailName10:"POLITO 12.JUL.14\nre: Reset the core\n"
EmailPortrait10:"Polito"
EmailIcon10:"OpsIcon"
EmailText10:"You're now on the engineering deck. Find the engine core and reset it. This will restore power to the elevators. I'm getting some kind of strange readings from down there, so keep your eyes open.\n"
As you can see from the numbering this is actually log 10, but it appears at the top of the file. As the rest of the file is not alphabetically ordered we can conclude that these text logs can appear in any order. The '\n' indicates a new line. Remember to put this in when you create logs, as SS2 does not peform any clipping when pasting. You can quite easily get a log going over the edge of the email MFD into the main game screen. The portrait and icon appear in the books.crf and you can probably easily include your own. So, when the EmailTrap which has the Logs->Deck1->Email 10 property on it receives a TurnOn signal the player will receive that email in his text window. At the same time the corresponding email schema is played. The schemas are found in the Schema->Speech_Sch section of the hierachy, and the email section follows the format of emDDNN, where DD indicates the deck number and NN the email number. The schema corresponding to that email is em0110.
Luckily, that actual sound file that coresponds to that schema is called the same thing, but remember it doesn't have to be. The schema is what dromed plays and that redirects the game to the correct file, unfortunately we do not have the schemas. For a complete experience you should techincally include your own sound files, but you may not have the resources to do that. If this is so remember to either choose email and log numbers which don't already have a sound file attatched else the sound from teh game will play. You can get around this by either inserting a blank dummy file into the snd\vmemails\english folder (remember to reproduce the directory path in the .crf) or by deleting the schema entry itself in the hierachy, though if you do delete it you will have to use a custom gamesys.
The file that contains the objective entries is notes.str in the strings.crf. If you created a notes.str file inside your new local override 'ss2\strings' directory with the following in
Note_2_1:"Open the door with the key card"
NoteOrder_2_1:"201"
Note_2_2:"Kill the hybrid somehow"
NoteOrder_2_2:"203"
Note_2_3:"Go to the next level"
NoteOrder_2_3:"202"
would eventually display the following, assuming that they were all visible
Open the door with the key card
Goto the next level
Kill the hybrid somehow
The actual number after the 'Note' text is just used for our reference, and doesn't order the notes in the display. It is the actual 'Note_Order' parameter which defines the order. This allows you to change the order easily from within the notes file without changing the names of all the qbsets and notes names. Also, you can add objectives in between others at a later stage allowing plot twists. The format in case you haven't spotted it, is:-
Note_deck_objectivesNo# : "Text for that objective" is the syntax you should use, for the text, and for the cycle order use: NoteOrder_deck_objectiveNo# :"DeckNo#OrderNo#"
Remember to include the inverted commas around BOTH variables
To trigger these notes you have to use qb sets, as was mentioned above. Each
note is controlled by a Note_X_Y variable.
There are 3 possible states for all objectives to be in:
0 = You have not yet been given this objective so it does not appear on yout
list.
1 = You have received the objective, but not completed it, this will display
as an uncheck box
2 = the objective is complete, this displays as a filled in white box.
To reiterate how to set these variables, link a Trigger to a qbset trap, and add the property 'QB name: Note_X_Y' and 'QB Val: 0/1/2' depending on what you wanted to happen. You can also set qb variables at the same times as an email trap or log trap kicks in, just add the properties to the trap and it will set when the TurnOn signal is sent. The X and Y corresponds to the DeckNo and the OrderNo respectively. Remember that 2 is the default starting deck.
Example:-
The objective "Water the plant"
Make a Tall plant from physicalàdecorativeàflora click on it and then on properties,
click "add" then go to S->scripts and type in ObjConsumeButton in the space
provided. Then add the property S->script->Consume Type: soda can. This
is telling the plant that it will use objects up, of the soda can type. Then
add the property Obj->hoodselectable?:TRUE and Engine Features->FrobInfo:
World:Script so you can interact with it. Make a soda can under physical->decorative->items
Then add the property s->scripts: ToolConsumable then add Engine Features->FrobInfo:World:move
Inv:Script Tool:script to specify that the can can be used up in the plant.
From now on, dragging this cola can onto the plant will make the plant send
a TURN ON message along any SwitchLinks from the plant. So we make a QB set
and link FROM the plant TO the QB set with a Switch link flavour link. Then
add the property Script->QB name: note_2_1 script->QB val:2 and the objective
will be marked as complete when you drag the cola can onto the plant.... IE
when you water it.
Keycards work much the same way as keys in thief. Each key card has an ID field which marks what key it is, and each locked keypad has an area mask which indicates which cards open it. When the two match you can unlock the keypad. To set the region ID you choose a flag from the list in Engine Features->KeyDst. The names of the regions are hardcoded to the types in the main game, but the actual displayed names can be changed by editting misc.str. The keycards are in a section and the object hierachy, and just have the Engine Features->Key Src property which defines the region they use. The original game only used the region, not the ID field, as one card opened many doors.
To get a keycard to control a door you would lock the door and create a switch link from the card slot opens it. The card slot has Engine features-->locked:TRUE and it also has engine features-->keyDST corresponding to the key card you must use. When you use the correct card a signal is sent to the door, opening it.. To make the red light be on to show it is locked you also have to change the Tweq->modelstate to on, reverse as well.
A metaproperty is simply a collection of properites. They exist in a sub heading in the object hiearchy. They are added to objects, and the object will assume those properties unless they already exist further down the tree. They do not neccesarily have to be a bunch of properties, some only have one. They really have a couple of uses. One is to speed up editting. If you have a few objects, usually AIs, who you want to assign a specific behaviour you can add one metaproperty which then alters a handful of properties. Also, as the object has the metaproperty on it, changing the metaproperty will change all instances of that metaproperty. If you change your mind as to what properties have you only have to alter one thing rather than several. You could also say that metaproperties make your level more understandable, as you can name them anything you like, as opposed to properties which have a specific unchangeable name.
The most common use of metaproperties is that they can be added and removed in game to alter objects behaviour. If an android has the metaproperty M-GoodGuy he is on the good side and will not attack a player. Using a conversational style effect you can remove this metaproperty and the droid will once again become hostile. The only restriction on adding or removing metaproperties in this way is that some properties always sit on top, usually ones whos states change midgame. If a patrolling AI reaches the end of his patrol route his AI Does Patrol? is set to false, as he techinically has no where else to go. If you added a new current patrol link between the AI and another patrol sequence he would have somewhere to go, but his AI Does Patrol? tells him to stay still, and even if you add the metaproperty M-DoesPatrol, he will continue to remain stationary as the property on the object supersedes the one on the metaproperty. To actually solve this you would need to use S&Rs or a dedicated script to set the property to true.
One of the side effects of making your own metaproperties is that it involves gamesys editting, which isn't exactly bad, but it is something else to learn
In certain circumstances, it is advisable to modify the object hierachy to save effort or implement new functionality. Perhaps you want to make your own custom metaproperties, or a new object archytpe, or you are playing around with S&Rs. This is quite esaily done, and it is often accidentally done, but the gamesys is not saved unless you specifically tell the editor to do so.
There are two options available when saving the gamesys, the first is File Save Cow. A .cow file is your .miss and .gam file saved together in one. In cannot really be distributed, and is just a handy format to save both you level and your gamesys file wihtout having to remember whether you need to save both or not.
The other option is the one you will need to do for release. File Save Gamesys will save your gamesys file by itself. By default, shocked uses shock2.gam as its gamesys file. It is extremely inadvisable to change this file at all. When you make a gamesys save, save it to a new file name. Your level will still think its supposed to use shock2.gam, we have to tell it otherwise. The command, set_gamesys <gamesysname>, will set your level to use a certain gamesys. Once you have done this command the shock2.gam at the bottom of your screen should change to the name of the gamesys you specified. In some cases, your alterations to the gamesys might not take effect until you save your mission and reload. When saving your mission directly after saving the gamesys be warned, it will default to your gamesys name, if you simply click yes without looking you will overwrite your gamesys with your mission file, which will break the level when you next load up. I personally find the command 'save_gamesys <gamesysname>' to be easier as it doesn't update the last saved filename so there is no danger of accidentally overwriting files. Remember that you will have to save the gamesys every time you alter it if you are not saving in cow format.
You may be scared of editting the gamesys, as it is used for a lot of objects, but one thing to remember is to make use of dromed's inheritance structure. If you wish to alter a cyborg's properties, create a new object type under the existing cyborg. It will still inherit all the cyborg's properties and your gamesys should still be completely compatible with the orginal game. You generally add to the gamesys, not change. Despite this, bear in mind that you can't really trust what someone else has done to the gamesys, so it is advisable to use your own where possible.
These effects are available through a number of triggers - conversations, responses and AIWatchObj links.
Conversations you can think of as scripted scenes - in fact the name for them in shocked is Cutscenes. You use them by creating a cutscene trap. You add the properties AI->Conversations->Save Conversation: yes, and AI->Conversations->Conversation. The former's use is not confirmed but probably is to do with saving conversation state if you save or load, the latter is where you specify what actually happens in the conversation. You then link up the marker to the AIs who will act out the conversation, using AI Conversation Actor links. For each link you have to set an actor ID which is used to reference the actor, you can set this by double clicking on the link or hilighting it and clickign data. Then, in the conversations->conversation property you set which actor is going to perform the action in the actor listbox, and then the actual action to peform in the Conversation Action box. When you first go to the Converstaion property you will be asked to specify the step number, this is like the page number of a book. Some cutscenes are rather involved, and have more steps than you can fit on screen. The steps outlined in 00 will be processed first, then 01, 02, etc. The arguements take different variables depending upon the action in question. The actual conversation is triggered by a switchON signal through a switchlink to the cutscenetrap. Remember that unless you specify otherwise the conversation is repeatable.
Responses you have already seen if you followed the dissection of station.miss. They peform the specified series actions when they receive the trigger which is to do with the response type. The possible responses are found under AI->Responses. Unlike conversations, only the AI who has that property will peform the action, though the effects you can choose are the same
AIWatchObj links is fairly obvious in functionality. You connect a link between an AI and the object to be watched, and you can then specify whether it is triggered on self entry or player intrusion. The former means that when the object gets within the radius and height specified, the actions are triggered, the latter only when the player gets within the radius irrespecitve of where the AI is. You can also specify whether the actions are repeatable or only happen once. Again the AI who has the watch link performs the action.
Always test conversations thoroughly as they are prone to errors, and do not depend on them functioning all the time. AIs who are conversation actors generally have to be calm to peform a conversation else they will simply abort playing it through. The timing of AIWatchObj links is not always precise, so they may not always trigger at the same time. Remember also that converstion style effects do not have to peform a cutscene. You can use them to add/remove metaproperties from objects, and to peform timing tricks with wait commands.
The list of commands can be obtained by 'dump_cmds <filename>' which dumps the commands to a file. A brief explanation of what the command does is attatched, but this is not always helpful. Eventually we hope to be able to describe what all the commands do.
Eventually, we hope to be able to furnish ShockEdders with a complete list of what a property does an examples of where it is used. To do this we need your help. Please document your discoveries and post about them at the TTLG forums.
As time goes on, we hope to expand this web based tutorial into a more defnitive guide. Dromed is however an extremely big and versatile editor, so this will takes some time. If you wish to contribute do not hesitate to email us. In the meantime you can probably find help at the editors forum. Also, the Thief dromedders have been active for a long time and a lot of information can be gleaned from that information base. Though a few details are different, quite a bit of the tutorials and tips still stand. You can find more at www.thief-thecircle.com. One of the most important tools for learning more are the other peoples levels. Not only the orignals, but other peoples efforts. Analysing how they work will teach much, and by experimenting with the objects and properties available you can work out nearly everthing. If you are pessimistic look at the thief community!
Okay, first of all, what are sources and receptrons. Well, they are like a series of customisable if statements in a way, they deal heavily with cause and effect. An example of such a statement would be 'if bolt of high energy hits a creature, then that creature is hurt'. If you have a look around the game you will see this is how damage is dealt, weapons have a source on of a specific type and intensity. Creatures have receptrons on which do different things depending upon the intensity of the source and its type. As this is all split up into different intensities and types you can make creatures more susceptible to one type of damage, or immune to another, depending upon how you set up the receptrons, take a look at the properties of all the projectiles under the object hierachy for more examples, and the creatures, perhaps the 'Human Vulnerability Metaproperty' for how these sources relate into damage.
In the game, sources and receptrons are mainly used for damage style effects, but they can do a lot more. If you have a look at the possible 'Effects' available for receptrons you will see a long list of possible actions you can take when the object receives a stimulus, these include teleporting objects, damaging objects, stimulating objects with another stimulus, and perhaps most importantly setting properties. This last effect is especiallly useful as it allows you to alter the properties of an object actually ingame, you could feasibly give the player a whole new set of characterstics using this effect, or you could make a droid see better, etc.
Another advantage with S&Rs is that they don't have to deal with definite target objects. With links, and conversations, you have to specifically name the object you want to apply the effect to. Due to the cause and effect nature of S&Rs you do not have to. The effect will apply when any stimulus strikes that object - a player is always hurt when hit by a shotgun shell no matter what shell hit him. This may not seem useful, but within the receptron effects you can specify whether to target the source of an object, or the object that has the receptron itself. This allows you to change the player's attributes midgame, something you cannot easily do as the player model does not exist until game mode has been started. S&Rs are very usefuly for creating complicated effects.
Unfortunately S&Rs seem to be rather difficult to learn, not many people make use of them despite their potential. This is fair enough, as there is often more than one way to acheive a specific effect, but some effects can only be achieved with S&Rs.
Tweqing is the term used to define animations. If you want an object to rotate, or move you would use tweqing. You can also use tweqing to send switch on signals at a set rate, unfortunately it is a complicated area and hopefully someone will expand it at a later date.
Spawning is a complicated area, which unforunately we ran out of time to concentrate with fully, for the moment here are my rough notes on spawn related items.
Ecology
This seems to handle spawnng. I am guessing that it can have lots of SL links
to different spawn points. It also has the two properties Script->EcoType and
Script->Ecology. The former seems to be an integer tag which exists on the spawn
point as well (and possible the objects that are spawned?), and the latter the
settings for the spawning
Spawn
Spawn point for items & AIs. Two properties. Script->Spawn, and Script->EcoType. The spawn seems to refer to what is to be spawned, and EcoType is that tag again. More investigation is need to determine what the properties do and whether the value of EcoType actually changes something. I think that the way the ecology and spawn points work is that you can specify the minimum number to be in the level at once, and the EcoType value is used to keep track off how many you have. So if you drop to below 3 occurrances of EcoType 3 you spawn another one.
black
chroma
Eng_1
Eng_2
Eng_3
Ert_1
ert_2
ert_3
flt_1
flt_2
flt_3
hyd_tech
hydro_1
hydro_2
medsci_1
medsci_2
msg
msgtest
ops_1
ops_2
opsnew
opstest
ovrmnd_1
res_1
res_2
res_3
res_mar2
res_mark
Ricken
Ricken_2
Ricken_3
rtech
scs
sec_1
shared
shodan
sky
skyhw
st_tech
tech
waterhw
waterhwbkp
Eventually a thumbnail browser of textures will be created.
Unforunately, due to LGS going down, we did not have enough time to get all the files that would be useful. For instance, we do not have the schemas which determine which sound files are played and how, nor do we have the motion schemas which would allow us to have a better understanding of movements. Also, we do not have any of the original multibrush sets. These are used in the Complex part of the hierachy, they are basically objects which come with terrain - the lift, replicators, etc. As we do not have the multibrush files trying to use these objects will crash dromed. It is theoretically possible to get the multibrush from the existing levels by comparing what is the same every time, but we only managed to do this for one multibrush, replicator.vbr, which is included with this tutorial.
Finally, and perhaps most importantly, we haven't really managed to get dromed to work in multiplayer. This doesn't mean that you cannot make multiplayer levels, it just means that the testers couldn't get a multiplayer game to work through dromed. This could quite possibly be an impossiblility, but it kept on crashing for us. This either means that the dromed that we have is the version before the multiplayer patch, or we are doing something wrong. In either case it does NOT mean that you cannot make multiplayer levels. The properties that control multiplayer functionality have always been in there - multiplayer is too big a task to add on at the end- but there were bugs with the code that had to be ironed out with the patch. So, if you reproduce the scripts, properties, and links, that are to do with multiplayer games then you will be able to play your multiplayer level through the main System Shock 2 patched exectuable, just as you would normally. I would recommend that you learn single player first though.....
Distributing your level so that others can play is quite simple. You have to zip up all the files that are needed for your FM, the mission files, the custom.gam if you created one, and any resource files you created. Remember to keep the directory structure intact - you essentially want to be able to unzip your mission directly to the ss2 game directory so that everything is in the correct place.
At the moment there is not a dedicated loader program that copes with FM management, but there is for thief and it is an easy matter to convert them so they work on SS2 FMs. The loader program keeps track of which files are where so you can easily remove a FM installation that you no longer want.
Remember to follow the license agreement provided in the zip, and it is also good form to include a readme file which relates details about your mission. This will probably be based along the same lines as the thief submission rules which can be found at http://www.thief-thecircle.com/teg/submissions/
These are the orignal tips provided in the Thief dromed tuts. Most still apply, just replace the word Thief with System Shock 2 in your mind.
I hope that you have found this brief tutorial helpful. There is lots more to learn - if you discover anything please, please post on the forums and tell us about it. Especially if you find out what is wrong with the game mode backup or what causes that error when you first enter game mode! I hope that we will see some great System Shock 2 fan mission soon, and that you have lots of fun with this editor. Thanks go to the NDA team, d0om and G'len for their help with the tut, all the folks at the forums and especially TTLG admin. Without Saam and Digi's efforts we would probably not have any editting facilities for either game. Who else? Oh yes, better mention Looking Glass Studios and Irrational Games for creating such a great game!!!!
Enjoy.
Totality, TTLG Moderator.
totality@ultramail.co.uk
20/08/00