Posted by: Join2
« on: 08. December 2013, 01:20:38 »Bah, Gamesys editing is exactly what I thought it was, that is simply changing properties. I may mod Shock yet. thanks for the write-up Zygo.
Posted by: Kolya
« on: 07. September 2013, 23:36:36 »Thank you Zygo. I added a link to the unstripped missions.
Posted by: Zygo
« on: 07. September 2013, 23:29:11 »Currently draft version, no pictures though it wouldn't have many anyway.
Part III: Bringing Your Mission to Life
The Player
By default ShockEd levels lack a proper player object in game mode and you move around as, essentially, a walking camera only. When moving in this manner there are several functions that simply will not work- eg in the game you usually have footsteps, not so in ShockEd without a properly set up player. To set the player up:
1) Open up the object hierarchy (F5 or editors menu)
2) Create a Marker-> Level Start Marker where you want the player to start
3) Create a Player Factory link from the concrete level start marker to '-384', which is the ID of the player archetype.
If you go into game mode you should now hear footsteps (so long as the area you are in is room brushed) and everything should function more or less as in the main game. You will always appear in game mode at the starting location by default, fortunately you can choose to go into game mode where the editor camera is instead using the command 'persistent_player_pos'. This is a toggle command, so typing it again will turn it off, and remember that you can use the tab autocomplete as well.
Important Note: If you enter game mode in ShockEd you will have the cyber interface enabled by default- in the main game though you would not as on the Earth level, and it has to be turned on. Turning it on is done by triggering the script 'ChangeInterface' via a switchlink- this is described in detail a little later.
AI
The AIs in System Shock2 exhibit various behaviours, they remain stationary when nothing's going on, they can hear your footsteps, hunt you down, and even run away when threatened. These are all behaviours that are inherent to the AIs, and you as the level designer don't need to worry about controlling them. You can modify AI behaviour somewhat using their object properties and links- make them deaf or silent, move quickly or go on patrols; or do specific actions when ordered to like chase and shoot at another scripted AI. AIs will not move or behave properly until the Pathfinding Database has been built (Tools-> Build Pathinding Database; also automatically builds rooms as part of the process) and the level roombrushed, but in general an AI will function fine without any other input from you.
For our test level we will make an AI patrol. This is a fairly basic way to bring the world to life, and has many, many examples in the original levels of SS2. To do so:
1) Create a large (32x32 or larger) room accessible from the player start location as a place to get your AI patrolling in.
2) Create an OG-pipe from physical-> Monsters-> Hybrids-> Once Grunts in this room
3) Create several (three or more) points to patrol from Markers-> Patrol Path. Note their object IDs
4) Create a patrol route by linking each Patrol Path in sequence (1st to 2nd, 2nd to 3rd etc) via 'AIPatrol' links
5) Make it loop by AIPatrol linking the last marker to the first. Each marker should then have one AIPatrol and one ~AIPatrol link
The hybrid will appear in a cruciform pose. Be warned: if the pathfindingDB and player are set up properly the hybrid will attack you if you go into game mode, and it can kill you! This behaviour is often annoying so if you simply want to observe and not get involved in any action you can use the handy console command 'aiawareofplayer' which turns off AI's player recognition functions. This is a toggle command, so typing it again would turn awareness back on. If you go into game mode now the hybrid should not attack you, but equally will not patrol but stand more or less still, fidgeting and mumbling to itself. We need to tell the bybrid to patrol...
1) Open the hybrid's object properties
2) 'Add' the AI-> Ability Settings-> Patrol: Does Patrol property and tick the checkbox
3) There is also a setting for random patrols where the sequence of markers is ignored, AI-> Ability Settings-> Patrol: Random Sequence
The hybrid will now patrol along your patrol route. Note: by default AI cannot open doors controlled via a button or (in SS2) via frobbing so will not be able to complete a route that goes through them.
Items
Most of the loot items found in SS2 are found in the Physical-> Goodies menu, including nanites, cyber modules, ammo, hypos and implants. Weapons are under weapons. By and large the defaults are fine for these items and they need little changing unless you fancy tinkering. You will probably want to alter the Engine Features-> Stack Count property of nanites and cyber modules at some points to specify amounts other than the default- setting a stack count of 32 nanites means that 32 nanites would be picked up. Be aware, many items will not behave properly if the player is not yet set up properly as above.
You can put items into containers using the 'contains' link. This link goes from the container to the object which is contained. Objects need to be set up in the gamesys to be functionably containable- they need an object item, dimensions, and to be told that they can be moved into and out of inventory. The items which can be picked up in the main game are all already set up properly, if you want to set up new items to be picked up have a look at a similar example there, something like a plant#2 (decorative-> flora) is the simplest case as it has no real function apart from being able to be picked up. If you put something into a container that is not set up properly it will not be able to be used or moved, and may not appear in the container at all.
Functional Objects
We've already tried some functional objects, a button controlling a door. There's also keypads, cardslots and other controller items under the Functional-> Controller hierarchy. Cardslots require specific keys which they are paired to. There is a set list of available keys under the 'Keys' hierarchy, with Engine Features-> KeySrc governing which key is which. A locked object requires both the 'KeyDst' and 'Locked: True' Engine Feature properties to be set. Once the key is found and the slot unlocked it will function as a button and activate any switchlinks from it.
Keypads are slightly different. You need to give them a code via the property Script-> Keypad code. It should be 5 digits long, shorter will require zeroes to be added before the code for it to work. A keypad is hackable by default, with its difficulty controlled by the Gamesys-> HackDiff property. If you want to make a keypad unhackable you need to add the 'KeypadUnhackable' script to it via the S-> Script property. Note that the script property has the "Don't Inherit" checkbox ticked by default, this is important and useful as it makes sure that the default (hackable) 'Keypad' script will not be inherited from its archetype.
Doors can also be controlled by tripwires- in essence sensors that detect the presence of an AI or the player. They are accessible from the Traps-> Tripwire archetype entry. A 'Once Tripwire' is useful for something which should only fire once- a taunt from SHODAN, maybe- but not so much for doors unless you want them to open once and only once, either a 'door tripwire' or 'new tripwire' (no practical difference between the two) is best for doors. Simply create the tripwire close to the door you want to open then create a switchlink from the tripwire to the door. So long as scripts are loaded and the player is set up the door should automatically open when you hit the tripwire.
Note: tripwires are particularly prone to the problem where the object's physical dimensions and its collision dimensions do not match. If you resize a tripwire's dimensions make sure to change its physical dimensions to match!
Quest Information
In SS2 we have various quests- finding Dr Watts or meeting Dr Polito as examples. These processes, and the notes you get in your MFD are controlled by 'questbits' which are used for scripting and controlling the flow of the game. So if you have not met Dr Polito yet you cannot explore Rec or Ops- but once you have met her you can, for example.
The collection of objects which perform these checks are under Traps-> QuestBits in the hierarchy. There are five of them, QB Trigger, QB Filter, QB Set, Anti-QB Trigger and Simple-QB Trigger, but there actually are more usable scripts that can be added manually. Like all other Traps they work on SwitchLink signals, and they all make use of the properties Script->QBVal and Scripts->QBName. QBs are very useful because they transfer across levels, so you can meet Polito on Ops1 and have Ops2 'know' that you have. A QBVal defaults to zero if unset.
A 'QB Set' is used to, unsurprisingly, set the value of a QB. It may be used as a 'note' for marking a quest in your MFD as current or finished, and also to tell the game that you have finished a quest. In may even be used to reset a QB to not done, if desired.
QB Filter's act like a gate. They only allow signals from the incoming SwitchLink to pass and an outgoing switchlink to fire 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, for example if you want a door to open from a tripwire once the radiation has been flushed from engineering you can place a QBFilter between the tripwire and the door. This is a pure filter- it has to have a signal sent to it, the signal is checked, and fires any outgoing links if its conditions are satisfied
An Anti-QB Trigger allows the switchon signal to pass when the condition is NOT satisfied. For example Polito will chide you if you go to Rec deck prior to meeting her on Ops, but this message will not be sent if you have met Polito and go to the same place. Despite its name this a filter like the QB Filter (its used script is QBNegFilter), and has the same restriction. It requires a signal to be sent to it and then will fire any outgoing links if the QB set up is not met. See also the section on quest notes for an example of how QBs are used.
Adding Objectives
The file that contains the objective entries is notes.str in strings.crf. If you created a notes.str file inside a new override (see below) \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"
it would potentially display the following:
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 'Note_Order' parameter which defines the order they appear in, plus whether they are visible at all. This allows you to change the order without changing the names of all the qbsets and note names in level. Also, you can add objectives in between others at a later stage allowing plot twists and better story editing. The format in case you haven't spotted it, is:-
Note_deck#_objective#:"Text displayed for objective" and for the order info NoteOrder_deck#_objective# :"Deck#Order#"
Remember to include the inverted commas around BOTH variables
To trigger these notes you have to use qb sets, as mentioned above. Each note is controlled by a Note_X_Y QB.
There are 3 possible states for all objectives to be in, equivalent to a QBVal:
0 = You have not yet been given this objective, it does not appear on yout list.
1 = You have received the objective but not completed it, this will display as a hollow box
2 = the objective is complete, this displays as a filled in white box.
To set these variables link a trigger (button/ tripwire etc) to a qbset trap, and add the property 'QB name' and 'QB Val' to the QBSet. If you wanted to make the objective "Kill the hybrid" from above appear you would enter QB Name as "Note_2_2" and set QBVal to "1". Once the Hybrid is dead you would link to another QBSet, with the same QB Name property, but QBVal set to "2" and the mission would be marked complete. If you wanted to make the pipe hybrid in your test level give a mission success when killed you can do so to test it. You will need to add the appropriate file (notes.str) to your strings override folder- be aware that ShockEd will only see changes there once it has been reloaded, so you may need to save your mission and restart ShockEd for it to work. You can add the quest as active anywhere you like using a button or tripwire and you should be able to see the quest as active in your MFD. If you add the script "triggerdestroy" to the OG-Pipe, create a QBSet trap with QB Name "Note_2_2" and QBVal "2" and link from the hybrid to the trap your MFD should then mark the quest as complete when the hybrid dies. You could even give yourself some cybermodules for succeeding by linking from the hybrid to an Experience Trap (with Gamesys-> Exp set, so you actually get some CMs).
The End
When the player has completed all his tasks, you will proably want the game to end. System Shock 2 only ends once, unlike Thief where every mission has to end at some point. The game is completed using the 'dieshodandie' script- this is added to a marker and triggered via 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 when the last objective is complete, or by having the trigger in an area which is inaccessible until you have completed all other objectives.
Failing the mission is a bit more difficult. There was no real way in SS2 of failing, apart from dying. If you want a failure ending- similar to using the laser to destroy earth in SS1, perhaps- you will need to use custom scripts (eg NVEndTrap from NVScript) to do so.
Setting up your Mission as a Fan Mission
New Dark has a default manager for FMs which make editing FMs easier. To turn on the default manager open cam_mod.ini in notepad and remove the semicolon from in front of the line ";fm". This will make the manager turn on each time you start ShockEd or SS2. If you want to run the manager for ShockEd only you can also create a shortcut for it with the switch "-fm" (without the inverted commas) added. Create a folder called FMs in your SS2 folder, then a folder called whatever you want to name your FM in that folder. You should save (or move) your mission files (.mis) from the main SS2 folder to here as well as any other required custom files such as a gamesys. This is also where you should place any override or new files for sounds, objects, automaps etc you need for your mission, in appropriately named folders (see below). You can set various variables for your FM as well using a FM.cfg file, see the new dark documentation (in the \doc folder) for more info.
One other thing you will need to do in order to have a functional mission that will work in the main SS2 executable is to make sure that the cyber interface is turned on, else the whole game will be like the Earth (outside the training subareas) or Station levels and you will not be able to access inventory and the like. The easiest way to do this is to place a Once Tripwire directly under your start marker, so it triggers immediately. SwitchLink this tripwire to a generic marker object which can be placed anywhere. Put the Script 'ChangeInterface' on the marker. If you go into game mode in ShockEd you should have the interface open automatically
The Resource Files (.CRF)
You may 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 resources are stored in 'crf' files which are just renamed zip files and can be opened up in winzip or similar.
Here's a brief list of what the crf's are called and what they do.
bitmap.crf - Contains bitmaps for particle effects and explosions.
books.crf - Contains the image files for emails and logs - logos, people's faces,etc.
editor.crf - Small crf containing the font that dromed uses and a mouse pointer. No real use for level editting.
fam.crf - texture families.
fonts.crf - The different fonts used in the game.
iface.crf - more fonts and pcx (an image file type) 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 processed models for AIs and skins.
motions.crf - contains the motions that AIs use.
obj.crf - contains the non AI objects and their textures.
objicon.crf - contains the icons that appear in the inventory.
pal.crf - contains the palettes to help create objects and textures. Largely irrelevant in new dark.
snd.crf - contains the ambient, object and creature sounds.
snd2.crf - contains the voice overs for briefing, logs, and email traps.
song.crf - list of schemas to play for songs.
strings.crf - String files containing object name, email text, logs, etc.
Note: you do not have to use pcx files for graphics and in new dark you can also use 24/32 bit colour instead of the old palettised 8 bit. See the new dark documentation for details.
While you can edit or add files into the crfs themselves you will not want to as you'd then have to distribute the whole modified crf to everyone using your mission. It is generally better to use 'override' files and folders, when placed in a folder with higher load priority than the crf these files are loaded in preference to the original ones. If you have used pretty much any mod, or played any SS2 FM then you have- perhaps unwittingly- used these override files. You can also have a look at some of these to see how the override folders work.
If you want to add new files it is simply a case of creating an appropriately named folder within your FM folder, eg 'obj' for an object, and putting the files there. Subfolders may be required, any textures for a new object must go into a 'obj\txt16' folder for example. If you wish to replace files- the default desk with a higher poly one for example- then you need to make sure that the names match, eg if you want to replace 'desk01.bin' which has 'desk01.pcx' as its texture you would need to put a replacement 'desk01.bin' into the \obj folder and the replacement 'desk01.pcx' into the \obj\txt16 folder. Be aware though, the size of the desk may not match up and any physical dimensions will need to altered as well...
It is, however, more likely at first that you will want to change some story specific files, such as sounds, log text or quest notes (see above).
Adding your own Logs and Sounds
Note: At first you should limit any new sounds to being replacements of existing ones. The Dark Engine has sound schema which tell the engine which sounds to play and how to play them, new ones can be added but is a bit beyond the scope of this tutorial. For example, log0101 placed in the appropriate override folder will play as a replacement for log 1 from Engineering. However, log0131 will not play because there is no schema defining it so the engine doesn't 'know' what sound to play- unless you built a new schema for it. On the other hand, any text defined for log0131 will display.
Logs and emails are sorted by what deck they appear on. ShockEd has nine different decks to choose from. They are sent using Data Traps, which are markers with a script which activates when they receive a TurnOn signal, and logs can of course be found as physical objects. You add the property Logs-> Deck# and then choose a number in the 'log' or 'email' box corresponding to the number you want to create- don't use notes or video though, as they are non functional. This information is used to display the appropriate text from strings.crf, and to play the correct soundfile from snd2.crf.
The text is contained in strings.crf, in the level##.str files (simply renamed text files, can be opened in notepad), where the number corresponds to the deck number. We'll use as an example the first entry from 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 email 10, as the order of the entries is irrelevant The '\n' switch forces a new line. This text is displayed if you have the Log property set to Log-> Deck 1: Email 10, the email name as displayed in the MFD is at top, the icons or portraits displayed (from book.crf) are the next two lines and the email body text is the last section. If you changed the entry you could change the icon or portrait to a new or different existing one in book.crf or book override folder, and change the text that is shown too. You need to save any changes made as .str files (not .str.txt files, as notepad will try to do) and place them in a \strings override folder for them to work.
Emails also have a sound associated with them. For Level 1, email 10 this file is em0110.wav, found in \vEmails\English in snd2.crf. If you want to have a new sound file associated with the log you also need to override the old sound file so you don't have Polito talking over your new text. If you want to have no sound for the email you can choose a email number which does not have a sound associated with it, or override with a short, silent wav.
For general sounds there are two types. For a looping sound- such as a pump, or hissing from steam, or persistent computer beeps- the A-> Ambient Hacked property is best. There are two main subtypes of ambient sounds, local ones and environmental ones. Environmental sounds are things like an engine rumble, present as background noise throughout more or less the entire level and have the 'Environmental' flag set. Those without that flag set are local sounds whose sound attenuates with the radius distance from the object, so a pump's noise gets quieter the further you are from it.
For triggered sounds you will generally want to use a Sound Trap. This will play a sound schema defined in Sound-> Object Sound.
If you want to check a sound and what schema is which sound you can use the 'Play Schema' edit menu item to play the sound in the editor. The 'Halt (all) Schema' item will stop them.
Gamesys Editing
In certain circumstances you may wish to modify the object hierarchy. You may wish to set up a new object, create a new type of monster or make alterations to an existing object that you want applied to all objects of that type. To do this you need to edit, then save, the gamesys.
Editing the gamesys is easy, and you may have done it inadvertently in this tutorial, though changes would not have been saved. You can make changes to an archetype entry- an object with a negative id#- similarly to how you would make changes to a concrete object with a positive id#. To use an example from Part I of the tutorial, if you wanted to make all Wedge Wall Lights have a red colour you could alter the LightColor property on their archetype (-978) to be 0, 0.75 and you would have wedge wall lights that project red light; though the light object itself will still look like it should emit white light- unless you change its default model as well...
There are two options available when saving the gamesys, the first is File: Save Cow. A .cow file is your .mis and .gam file saved together in one file. In cannot really be distributed as the main executable will not play it, it is just a convenience as it saves both mission and gamesys at once and into one file.
The other option is the one you will need to do for a release. File: Save Gamesys will save your gamesys file by itself. By default, ShockEd uses shock2.gam as its gamesys file, the gamesys that is being used is shown at bottom near left of the main DromEd window. It is strongly advised that you do NOT alter the Shock2.gam in your root SS2 folder. Shock2.gam is used by all the original levels, so if you edit it and break something critical you will potentially break the game! If you want to use a new gamesys name for your FM- generally you should, if using a custom gamesys- the command, 'set_gamesys [gamesysname].gam' will set your level to use the named 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, and gamesys changes may not be applied retroactively to concrete objects if their properties override the archetype's. Remember that you will have to save the gamesys every time you alter it, if you quit the program before saving changes will be lost!
Note: I'd strongly advise not using the 'open' dialogue to load a gamesys, and not using the default shock2.gam name unless you're making a gamesys mod for the original missions. Instead, load your mission file, if it has the gamesys set it will automatically load the correct gamesys along with the level.
You may be worried about editing the gamesys, as it is quite intimidating with the number of objects and properties available and you can break things unintentionally. For most simple tasks it is not necessary to alter the gamesys at all, and if you do ShockEd does generate an automatic backup for you in case of accidents. You can experiment on concrete objects to make sure that you get what you intend then make changes to the archetype if you wish, and you can also generate a new archetype based on changes you make to an object. In general, you should not delete objects from the hierarchy, but add new ones as that maximises compatibility and minimises unintentional mistakes. If you want to be really safe apply any changes you want to make to a new descendant of an existing hierarchy entry, eg if you want an OG-Pipe with extra HP you can make a new archetype called OG-PipeNasty or whatever, and add the new hitpoint property there.
Gamesys Parameters and the RPG System
If you wish to alter the RPG systems and things like the cost of upgrading skills this can be done using the Gamesys Parameters entry under the 'Editors' menu. These entries deal with the effects your various skills have as well as their costs in CM. Hopefully most of these will be fairly self explanatory.
Metaproperties
A metaproperty (MP) is simply a collection of properties. They exist in their own sub heading in the object hierarchy drop down menu. They are added to objects, and the object will have those properties applied unless they already exist further down the tree. They are particularly useful if you want to assign a group of properties to a set of objects which cannot have a common archetype, as you only have to change or add to the MetaProperty rather than add the properties to each individual archetype, eg Robots and some mechanical decorations have the same vulnerabilities to weapons but are in different places in the hierarchy- and because MPs can be added or removed on the fly by scripts or conversation style events. If an android has the metaproperty M-GoodGuy he is on the good side and will not attack a player, if you wanted to make all 'GoodGuy's faster you could add a time warp property to the MP and it would be automatically applied. If you wanted to make him swap sides and become an enemy you could remove the MP, and he would become an enemy again- and slow down, if you had added a time warp.
By their nature altering or creating MPs (but not using ones already existing) requires a custom gamesys. For convenience, any object archetype with an MP applied is listed under the relevant MP's hierarchy entry, so if you looked at the Mechanical Vulnerability entry under Vulnerabilities you would see all the objects with it applied, such as robots and junction boxes.
Sources and Receptrons
Many of the more advanced effects- and most visibly damage effects- is achieved through Sources and Receptrons, also known as Act/ React and Stimulus/ Response. In simple terms a stimulus or source is placed on an object and fires under certain circumstances of elapsed time or collision. A fired bullet has a stimulus of a certain intensity on it which is applied when it collides with something, for example, while an explosion has a stimulus that effects anything within its blast radius. There are various types of stimuli, for a bullet there may be a standard impact, an armour piercing impact or an anti personnel impact; while for an explosion there may be incendiary, radiation or standard impact stimuli. Stimuli are found in their own entry in the archetypes drop down menu. Each entry has no direct properties though, their effects are defined by their paired receptron, and how they fire by the Act/ React-> Stimulus property of the object they are on. eg a 'HE Explosion' has a intensity 10 Standard Impact stimulus which fires once to a radius of 10, as defined on its archetype entry; anything within that radius that has a standard impact receptron, such as the Player object, is effected by the stimulus. In the Player's case this means taking, by default, 10 damage, or less if you are wearing armour.
The actual effect of a stimulus is governed by its interaction with an object's receptrons. This is how and why a rumbler will die very quickly to anti personnel bullets but not to armour piercing, while the reverse is true for a Security Bot. Generally the damage receptrons are grouped into convenient Metaproperties by vulnerability types, so there is a Metaproperty for Robots and one for hybrids with all the things that can damage them on it. If you have a look at the mechanical vulnerability, as above, and 'edit' the receptron property you will see all the things that can damage or cause certain other effects such as stasis to a robot in a dialogue window resembling that used for links. If you edit the 'Armor Piercing' entry another dialogue will pop up, if you look at the centre you will see that the Armor Piercing stim will 'damage object' and has 'Use stimulus as type' set to true- which applies all the RPG type damage bonuses from weapon skills etc to the damage automatically- and Multiply by 4, which means that damage from an AP source is quadrupled. That is why a robot dies quickly to armour piercing bullets.
There are many other types of receptrons effects available and they are a very powerful tool, but further discussion is a bit beyond the scope of this tutorial.
Scripted Encounters
Ever wondered how the Rumbler on Command 'knows' to chase Rebecca and Tommy, or how the shotgun hybrid near the beginning of medsci1 chases and shoots the fleeing crew woman? Conversation style effects is how.
For those familiar with Thief there is no native TrapConverse in Shock's allobjs.osm so no 'proper' conversations, though the dialogues are all there and Conversations can be added with custom scripts. Similar, if less flexible effects can be achieved with either AI->Responses->Signal Response or AIWatchObj links, though these can only have one defined actor.
Responses perform a specified series of actions when they receive their trigger. The possible responses are found under AI->Responses. Only the AI who has the property will perform the action, though the effects you can choose are the same. The response can be Signalled from an AISignalTrap or direct from a button or similar via Switchlink. An example of a signal response is in station.mis, after completing your first assignment there is a woman (obj# 799) typing in one of the areas. This behaviour is achieved using a looped signal response where the typing motion cs116 is played repetitively. I will not go into any more detail of how to use these signal responses here.
AIWatchObj links is basically what it says- an AI watches the linked object and responds when the player, or itself, gets close to it. 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. You can also specify whether the actions are repeatable or only happen once. Again the AI who has the watch link performs the action, so the shotgun hybrid (obj 613) shooting the woman (obj 312) on medsci1 requires each to have a separate AIWatchobj set.
Always test conversations thoroughly as they are prone to errors, and do not depend on them functioning all the time unless you set their priority to absolute and even then they could, for example, have the AI be killed by an over eager player!
The Command list & Object Property lists
A full 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 attached, but this is not always helpful. The command 'list_props' will also dump a list of all properties to MONO, which can be copied out if desired. For new dark there is also a lot of documentation in the 'docs' folder.
A Note on the Original Levels
One of the best things you can do when learning how to do stuff is to check the original levels to see how it was done there. If you want to use a power cell to open a door, set up a replicator properly or have one AI chase another you can always check how it was done in the original game levels. Some stuff will be opaque because it requires specific scripts (the training in station.mis, for example) but a lot will have easy to access properties that define how something is done. The default levels supplied with the game are 'stripped', they have had the architectural and other brushes removed to save space so only have red objects and yellow light objects visible. However, the unstripped versions of most levels were made available prior to LGS going out of business and may be downloaded if you wish to see the architectural information. You can also make multibrushes in these unstripped original levels and copy them over using Multibrush-> Save Group then Multibrush-> Load Group in the destination mission.
And that is pretty much the end of the tutorial. In many ways it only scratches the surface of what can be done but hopefully it gives enough background information. If you have any problems or want to know how to do anything not mentioned here check for tutorials and forum posts in places like systemshock.org or TTLG (many Thief solutions will work for SS2!) and ask, chances are that someone will know either how to do something or whether it's possible.
Acknowledgement: This tutorial is based on the original ShockEd tutorial written by Totality and the rest of the release team
Part III: Bringing Your Mission to Life
- The Player
- AI
- Items
- Functional Objects
- Quest Information
- Adding Objectives
- The End
- FM Set Up
- Resource Files
- Logs and Sounds
- Gamesys Editing
- RPG Systems
- Metaproperties
- Sources and Receptrons
- Scripted Encounters
- Useful Lists
- A Note on the Original Levels
The Player
By default ShockEd levels lack a proper player object in game mode and you move around as, essentially, a walking camera only. When moving in this manner there are several functions that simply will not work- eg in the game you usually have footsteps, not so in ShockEd without a properly set up player. To set the player up:
1) Open up the object hierarchy (F5 or editors menu)
2) Create a Marker-> Level Start Marker where you want the player to start
3) Create a Player Factory link from the concrete level start marker to '-384', which is the ID of the player archetype.
If you go into game mode you should now hear footsteps (so long as the area you are in is room brushed) and everything should function more or less as in the main game. You will always appear in game mode at the starting location by default, fortunately you can choose to go into game mode where the editor camera is instead using the command 'persistent_player_pos'. This is a toggle command, so typing it again will turn it off, and remember that you can use the tab autocomplete as well.
Important Note: If you enter game mode in ShockEd you will have the cyber interface enabled by default- in the main game though you would not as on the Earth level, and it has to be turned on. Turning it on is done by triggering the script 'ChangeInterface' via a switchlink- this is described in detail a little later.
AI
The AIs in System Shock2 exhibit various behaviours, they remain stationary when nothing's going on, they can hear your footsteps, hunt you down, and even run away when threatened. These are all behaviours that are inherent to the AIs, and you as the level designer don't need to worry about controlling them. You can modify AI behaviour somewhat using their object properties and links- make them deaf or silent, move quickly or go on patrols; or do specific actions when ordered to like chase and shoot at another scripted AI. AIs will not move or behave properly until the Pathfinding Database has been built (Tools-> Build Pathinding Database; also automatically builds rooms as part of the process) and the level roombrushed, but in general an AI will function fine without any other input from you.
For our test level we will make an AI patrol. This is a fairly basic way to bring the world to life, and has many, many examples in the original levels of SS2. To do so:
1) Create a large (32x32 or larger) room accessible from the player start location as a place to get your AI patrolling in.
2) Create an OG-pipe from physical-> Monsters-> Hybrids-> Once Grunts in this room
3) Create several (three or more) points to patrol from Markers-> Patrol Path. Note their object IDs
4) Create a patrol route by linking each Patrol Path in sequence (1st to 2nd, 2nd to 3rd etc) via 'AIPatrol' links
5) Make it loop by AIPatrol linking the last marker to the first. Each marker should then have one AIPatrol and one ~AIPatrol link
The hybrid will appear in a cruciform pose. Be warned: if the pathfindingDB and player are set up properly the hybrid will attack you if you go into game mode, and it can kill you! This behaviour is often annoying so if you simply want to observe and not get involved in any action you can use the handy console command 'aiawareofplayer' which turns off AI's player recognition functions. This is a toggle command, so typing it again would turn awareness back on. If you go into game mode now the hybrid should not attack you, but equally will not patrol but stand more or less still, fidgeting and mumbling to itself. We need to tell the bybrid to patrol...
1) Open the hybrid's object properties
2) 'Add' the AI-> Ability Settings-> Patrol: Does Patrol property and tick the checkbox
3) There is also a setting for random patrols where the sequence of markers is ignored, AI-> Ability Settings-> Patrol: Random Sequence
The hybrid will now patrol along your patrol route. Note: by default AI cannot open doors controlled via a button or (in SS2) via frobbing so will not be able to complete a route that goes through them.
Items
Most of the loot items found in SS2 are found in the Physical-> Goodies menu, including nanites, cyber modules, ammo, hypos and implants. Weapons are under weapons. By and large the defaults are fine for these items and they need little changing unless you fancy tinkering. You will probably want to alter the Engine Features-> Stack Count property of nanites and cyber modules at some points to specify amounts other than the default- setting a stack count of 32 nanites means that 32 nanites would be picked up. Be aware, many items will not behave properly if the player is not yet set up properly as above.
You can put items into containers using the 'contains' link. This link goes from the container to the object which is contained. Objects need to be set up in the gamesys to be functionably containable- they need an object item, dimensions, and to be told that they can be moved into and out of inventory. The items which can be picked up in the main game are all already set up properly, if you want to set up new items to be picked up have a look at a similar example there, something like a plant#2 (decorative-> flora) is the simplest case as it has no real function apart from being able to be picked up. If you put something into a container that is not set up properly it will not be able to be used or moved, and may not appear in the container at all.
Functional Objects
We've already tried some functional objects, a button controlling a door. There's also keypads, cardslots and other controller items under the Functional-> Controller hierarchy. Cardslots require specific keys which they are paired to. There is a set list of available keys under the 'Keys' hierarchy, with Engine Features-> KeySrc governing which key is which. A locked object requires both the 'KeyDst' and 'Locked: True' Engine Feature properties to be set. Once the key is found and the slot unlocked it will function as a button and activate any switchlinks from it.
Keypads are slightly different. You need to give them a code via the property Script-> Keypad code. It should be 5 digits long, shorter will require zeroes to be added before the code for it to work. A keypad is hackable by default, with its difficulty controlled by the Gamesys-> HackDiff property. If you want to make a keypad unhackable you need to add the 'KeypadUnhackable' script to it via the S-> Script property. Note that the script property has the "Don't Inherit" checkbox ticked by default, this is important and useful as it makes sure that the default (hackable) 'Keypad' script will not be inherited from its archetype.
Doors can also be controlled by tripwires- in essence sensors that detect the presence of an AI or the player. They are accessible from the Traps-> Tripwire archetype entry. A 'Once Tripwire' is useful for something which should only fire once- a taunt from SHODAN, maybe- but not so much for doors unless you want them to open once and only once, either a 'door tripwire' or 'new tripwire' (no practical difference between the two) is best for doors. Simply create the tripwire close to the door you want to open then create a switchlink from the tripwire to the door. So long as scripts are loaded and the player is set up the door should automatically open when you hit the tripwire.
Note: tripwires are particularly prone to the problem where the object's physical dimensions and its collision dimensions do not match. If you resize a tripwire's dimensions make sure to change its physical dimensions to match!
Quest Information
In SS2 we have various quests- finding Dr Watts or meeting Dr Polito as examples. These processes, and the notes you get in your MFD are controlled by 'questbits' which are used for scripting and controlling the flow of the game. So if you have not met Dr Polito yet you cannot explore Rec or Ops- but once you have met her you can, for example.
The collection of objects which perform these checks are under Traps-> QuestBits in the hierarchy. There are five of them, QB Trigger, QB Filter, QB Set, Anti-QB Trigger and Simple-QB Trigger, but there actually are more usable scripts that can be added manually. Like all other Traps they work on SwitchLink signals, and they all make use of the properties Script->QBVal and Scripts->QBName. QBs are very useful because they transfer across levels, so you can meet Polito on Ops1 and have Ops2 'know' that you have. A QBVal defaults to zero if unset.
A 'QB Set' is used to, unsurprisingly, set the value of a QB. It may be used as a 'note' for marking a quest in your MFD as current or finished, and also to tell the game that you have finished a quest. In may even be used to reset a QB to not done, if desired.
QB Filter's act like a gate. They only allow signals from the incoming SwitchLink to pass and an outgoing switchlink to fire 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, for example if you want a door to open from a tripwire once the radiation has been flushed from engineering you can place a QBFilter between the tripwire and the door. This is a pure filter- it has to have a signal sent to it, the signal is checked, and fires any outgoing links if its conditions are satisfied
An Anti-QB Trigger allows the switchon signal to pass when the condition is NOT satisfied. For example Polito will chide you if you go to Rec deck prior to meeting her on Ops, but this message will not be sent if you have met Polito and go to the same place. Despite its name this a filter like the QB Filter (its used script is QBNegFilter), and has the same restriction. It requires a signal to be sent to it and then will fire any outgoing links if the QB set up is not met. See also the section on quest notes for an example of how QBs are used.
Adding Objectives
The file that contains the objective entries is notes.str in strings.crf. If you created a notes.str file inside a new override (see below) \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"
it would potentially display the following:
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 'Note_Order' parameter which defines the order they appear in, plus whether they are visible at all. This allows you to change the order without changing the names of all the qbsets and note names in level. Also, you can add objectives in between others at a later stage allowing plot twists and better story editing. The format in case you haven't spotted it, is:-
Note_deck#_objective#:"Text displayed for objective" and for the order info NoteOrder_deck#_objective# :"Deck#Order#"
Remember to include the inverted commas around BOTH variables
To trigger these notes you have to use qb sets, as mentioned above. Each note is controlled by a Note_X_Y QB.
There are 3 possible states for all objectives to be in, equivalent to a QBVal:
0 = You have not yet been given this objective, it does not appear on yout list.
1 = You have received the objective but not completed it, this will display as a hollow box
2 = the objective is complete, this displays as a filled in white box.
To set these variables link a trigger (button/ tripwire etc) to a qbset trap, and add the property 'QB name' and 'QB Val' to the QBSet. If you wanted to make the objective "Kill the hybrid" from above appear you would enter QB Name as "Note_2_2" and set QBVal to "1". Once the Hybrid is dead you would link to another QBSet, with the same QB Name property, but QBVal set to "2" and the mission would be marked complete. If you wanted to make the pipe hybrid in your test level give a mission success when killed you can do so to test it. You will need to add the appropriate file (notes.str) to your strings override folder- be aware that ShockEd will only see changes there once it has been reloaded, so you may need to save your mission and restart ShockEd for it to work. You can add the quest as active anywhere you like using a button or tripwire and you should be able to see the quest as active in your MFD. If you add the script "triggerdestroy" to the OG-Pipe, create a QBSet trap with QB Name "Note_2_2" and QBVal "2" and link from the hybrid to the trap your MFD should then mark the quest as complete when the hybrid dies. You could even give yourself some cybermodules for succeeding by linking from the hybrid to an Experience Trap (with Gamesys-> Exp set, so you actually get some CMs).
The End
When the player has completed all his tasks, you will proably want the game to end. System Shock 2 only ends once, unlike Thief where every mission has to end at some point. The game is completed using the 'dieshodandie' script- this is added to a marker and triggered via 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 when the last objective is complete, or by having the trigger in an area which is inaccessible until you have completed all other objectives.
Failing the mission is a bit more difficult. There was no real way in SS2 of failing, apart from dying. If you want a failure ending- similar to using the laser to destroy earth in SS1, perhaps- you will need to use custom scripts (eg NVEndTrap from NVScript) to do so.
Setting up your Mission as a Fan Mission
New Dark has a default manager for FMs which make editing FMs easier. To turn on the default manager open cam_mod.ini in notepad and remove the semicolon from in front of the line ";fm". This will make the manager turn on each time you start ShockEd or SS2. If you want to run the manager for ShockEd only you can also create a shortcut for it with the switch "-fm" (without the inverted commas) added. Create a folder called FMs in your SS2 folder, then a folder called whatever you want to name your FM in that folder. You should save (or move) your mission files (.mis) from the main SS2 folder to here as well as any other required custom files such as a gamesys. This is also where you should place any override or new files for sounds, objects, automaps etc you need for your mission, in appropriately named folders (see below). You can set various variables for your FM as well using a FM.cfg file, see the new dark documentation (in the \doc folder) for more info.
One other thing you will need to do in order to have a functional mission that will work in the main SS2 executable is to make sure that the cyber interface is turned on, else the whole game will be like the Earth (outside the training subareas) or Station levels and you will not be able to access inventory and the like. The easiest way to do this is to place a Once Tripwire directly under your start marker, so it triggers immediately. SwitchLink this tripwire to a generic marker object which can be placed anywhere. Put the Script 'ChangeInterface' on the marker. If you go into game mode in ShockEd you should have the interface open automatically
The Resource Files (.CRF)
You may 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 resources are stored in 'crf' files which are just renamed zip files and can be opened up in winzip or similar.
Here's a brief list of what the crf's are called and what they do.
bitmap.crf - Contains bitmaps for particle effects and explosions.
books.crf - Contains the image files for emails and logs - logos, people's faces,etc.
editor.crf - Small crf containing the font that dromed uses and a mouse pointer. No real use for level editting.
fam.crf - texture families.
fonts.crf - The different fonts used in the game.
iface.crf - more fonts and pcx (an image file type) 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 processed models for AIs and skins.
motions.crf - contains the motions that AIs use.
obj.crf - contains the non AI objects and their textures.
objicon.crf - contains the icons that appear in the inventory.
pal.crf - contains the palettes to help create objects and textures. Largely irrelevant in new dark.
snd.crf - contains the ambient, object and creature sounds.
snd2.crf - contains the voice overs for briefing, logs, and email traps.
song.crf - list of schemas to play for songs.
strings.crf - String files containing object name, email text, logs, etc.
Note: you do not have to use pcx files for graphics and in new dark you can also use 24/32 bit colour instead of the old palettised 8 bit. See the new dark documentation for details.
While you can edit or add files into the crfs themselves you will not want to as you'd then have to distribute the whole modified crf to everyone using your mission. It is generally better to use 'override' files and folders, when placed in a folder with higher load priority than the crf these files are loaded in preference to the original ones. If you have used pretty much any mod, or played any SS2 FM then you have- perhaps unwittingly- used these override files. You can also have a look at some of these to see how the override folders work.
If you want to add new files it is simply a case of creating an appropriately named folder within your FM folder, eg 'obj' for an object, and putting the files there. Subfolders may be required, any textures for a new object must go into a 'obj\txt16' folder for example. If you wish to replace files- the default desk with a higher poly one for example- then you need to make sure that the names match, eg if you want to replace 'desk01.bin' which has 'desk01.pcx' as its texture you would need to put a replacement 'desk01.bin' into the \obj folder and the replacement 'desk01.pcx' into the \obj\txt16 folder. Be aware though, the size of the desk may not match up and any physical dimensions will need to altered as well...
It is, however, more likely at first that you will want to change some story specific files, such as sounds, log text or quest notes (see above).
Adding your own Logs and Sounds
Note: At first you should limit any new sounds to being replacements of existing ones. The Dark Engine has sound schema which tell the engine which sounds to play and how to play them, new ones can be added but is a bit beyond the scope of this tutorial. For example, log0101 placed in the appropriate override folder will play as a replacement for log 1 from Engineering. However, log0131 will not play because there is no schema defining it so the engine doesn't 'know' what sound to play- unless you built a new schema for it. On the other hand, any text defined for log0131 will display.
Logs and emails are sorted by what deck they appear on. ShockEd has nine different decks to choose from. They are sent using Data Traps, which are markers with a script which activates when they receive a TurnOn signal, and logs can of course be found as physical objects. You add the property Logs-> Deck# and then choose a number in the 'log' or 'email' box corresponding to the number you want to create- don't use notes or video though, as they are non functional. This information is used to display the appropriate text from strings.crf, and to play the correct soundfile from snd2.crf.
The text is contained in strings.crf, in the level##.str files (simply renamed text files, can be opened in notepad), where the number corresponds to the deck number. We'll use as an example the first entry from 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 email 10, as the order of the entries is irrelevant The '\n' switch forces a new line. This text is displayed if you have the Log property set to Log-> Deck 1: Email 10, the email name as displayed in the MFD is at top, the icons or portraits displayed (from book.crf) are the next two lines and the email body text is the last section. If you changed the entry you could change the icon or portrait to a new or different existing one in book.crf or book override folder, and change the text that is shown too. You need to save any changes made as .str files (not .str.txt files, as notepad will try to do) and place them in a \strings override folder for them to work.
Emails also have a sound associated with them. For Level 1, email 10 this file is em0110.wav, found in \vEmails\English in snd2.crf. If you want to have a new sound file associated with the log you also need to override the old sound file so you don't have Polito talking over your new text. If you want to have no sound for the email you can choose a email number which does not have a sound associated with it, or override with a short, silent wav.
For general sounds there are two types. For a looping sound- such as a pump, or hissing from steam, or persistent computer beeps- the A-> Ambient Hacked property is best. There are two main subtypes of ambient sounds, local ones and environmental ones. Environmental sounds are things like an engine rumble, present as background noise throughout more or less the entire level and have the 'Environmental' flag set. Those without that flag set are local sounds whose sound attenuates with the radius distance from the object, so a pump's noise gets quieter the further you are from it.
For triggered sounds you will generally want to use a Sound Trap. This will play a sound schema defined in Sound-> Object Sound.
If you want to check a sound and what schema is which sound you can use the 'Play Schema' edit menu item to play the sound in the editor. The 'Halt (all) Schema' item will stop them.
Gamesys Editing
In certain circumstances you may wish to modify the object hierarchy. You may wish to set up a new object, create a new type of monster or make alterations to an existing object that you want applied to all objects of that type. To do this you need to edit, then save, the gamesys.
Editing the gamesys is easy, and you may have done it inadvertently in this tutorial, though changes would not have been saved. You can make changes to an archetype entry- an object with a negative id#- similarly to how you would make changes to a concrete object with a positive id#. To use an example from Part I of the tutorial, if you wanted to make all Wedge Wall Lights have a red colour you could alter the LightColor property on their archetype (-978) to be 0, 0.75 and you would have wedge wall lights that project red light; though the light object itself will still look like it should emit white light- unless you change its default model as well...
There are two options available when saving the gamesys, the first is File: Save Cow. A .cow file is your .mis and .gam file saved together in one file. In cannot really be distributed as the main executable will not play it, it is just a convenience as it saves both mission and gamesys at once and into one file.
The other option is the one you will need to do for a release. File: Save Gamesys will save your gamesys file by itself. By default, ShockEd uses shock2.gam as its gamesys file, the gamesys that is being used is shown at bottom near left of the main DromEd window. It is strongly advised that you do NOT alter the Shock2.gam in your root SS2 folder. Shock2.gam is used by all the original levels, so if you edit it and break something critical you will potentially break the game! If you want to use a new gamesys name for your FM- generally you should, if using a custom gamesys- the command, 'set_gamesys [gamesysname].gam' will set your level to use the named 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, and gamesys changes may not be applied retroactively to concrete objects if their properties override the archetype's. Remember that you will have to save the gamesys every time you alter it, if you quit the program before saving changes will be lost!
Note: I'd strongly advise not using the 'open' dialogue to load a gamesys, and not using the default shock2.gam name unless you're making a gamesys mod for the original missions. Instead, load your mission file, if it has the gamesys set it will automatically load the correct gamesys along with the level.
You may be worried about editing the gamesys, as it is quite intimidating with the number of objects and properties available and you can break things unintentionally. For most simple tasks it is not necessary to alter the gamesys at all, and if you do ShockEd does generate an automatic backup for you in case of accidents. You can experiment on concrete objects to make sure that you get what you intend then make changes to the archetype if you wish, and you can also generate a new archetype based on changes you make to an object. In general, you should not delete objects from the hierarchy, but add new ones as that maximises compatibility and minimises unintentional mistakes. If you want to be really safe apply any changes you want to make to a new descendant of an existing hierarchy entry, eg if you want an OG-Pipe with extra HP you can make a new archetype called OG-PipeNasty or whatever, and add the new hitpoint property there.
Gamesys Parameters and the RPG System
If you wish to alter the RPG systems and things like the cost of upgrading skills this can be done using the Gamesys Parameters entry under the 'Editors' menu. These entries deal with the effects your various skills have as well as their costs in CM. Hopefully most of these will be fairly self explanatory.
Metaproperties
A metaproperty (MP) is simply a collection of properties. They exist in their own sub heading in the object hierarchy drop down menu. They are added to objects, and the object will have those properties applied unless they already exist further down the tree. They are particularly useful if you want to assign a group of properties to a set of objects which cannot have a common archetype, as you only have to change or add to the MetaProperty rather than add the properties to each individual archetype, eg Robots and some mechanical decorations have the same vulnerabilities to weapons but are in different places in the hierarchy- and because MPs can be added or removed on the fly by scripts or conversation style events. If an android has the metaproperty M-GoodGuy he is on the good side and will not attack a player, if you wanted to make all 'GoodGuy's faster you could add a time warp property to the MP and it would be automatically applied. If you wanted to make him swap sides and become an enemy you could remove the MP, and he would become an enemy again- and slow down, if you had added a time warp.
By their nature altering or creating MPs (but not using ones already existing) requires a custom gamesys. For convenience, any object archetype with an MP applied is listed under the relevant MP's hierarchy entry, so if you looked at the Mechanical Vulnerability entry under Vulnerabilities you would see all the objects with it applied, such as robots and junction boxes.
Sources and Receptrons
Many of the more advanced effects- and most visibly damage effects- is achieved through Sources and Receptrons, also known as Act/ React and Stimulus/ Response. In simple terms a stimulus or source is placed on an object and fires under certain circumstances of elapsed time or collision. A fired bullet has a stimulus of a certain intensity on it which is applied when it collides with something, for example, while an explosion has a stimulus that effects anything within its blast radius. There are various types of stimuli, for a bullet there may be a standard impact, an armour piercing impact or an anti personnel impact; while for an explosion there may be incendiary, radiation or standard impact stimuli. Stimuli are found in their own entry in the archetypes drop down menu. Each entry has no direct properties though, their effects are defined by their paired receptron, and how they fire by the Act/ React-> Stimulus property of the object they are on. eg a 'HE Explosion' has a intensity 10 Standard Impact stimulus which fires once to a radius of 10, as defined on its archetype entry; anything within that radius that has a standard impact receptron, such as the Player object, is effected by the stimulus. In the Player's case this means taking, by default, 10 damage, or less if you are wearing armour.
The actual effect of a stimulus is governed by its interaction with an object's receptrons. This is how and why a rumbler will die very quickly to anti personnel bullets but not to armour piercing, while the reverse is true for a Security Bot. Generally the damage receptrons are grouped into convenient Metaproperties by vulnerability types, so there is a Metaproperty for Robots and one for hybrids with all the things that can damage them on it. If you have a look at the mechanical vulnerability, as above, and 'edit' the receptron property you will see all the things that can damage or cause certain other effects such as stasis to a robot in a dialogue window resembling that used for links. If you edit the 'Armor Piercing' entry another dialogue will pop up, if you look at the centre you will see that the Armor Piercing stim will 'damage object' and has 'Use stimulus as type' set to true- which applies all the RPG type damage bonuses from weapon skills etc to the damage automatically- and Multiply by 4, which means that damage from an AP source is quadrupled. That is why a robot dies quickly to armour piercing bullets.
There are many other types of receptrons effects available and they are a very powerful tool, but further discussion is a bit beyond the scope of this tutorial.
Scripted Encounters
Ever wondered how the Rumbler on Command 'knows' to chase Rebecca and Tommy, or how the shotgun hybrid near the beginning of medsci1 chases and shoots the fleeing crew woman? Conversation style effects is how.
For those familiar with Thief there is no native TrapConverse in Shock's allobjs.osm so no 'proper' conversations, though the dialogues are all there and Conversations can be added with custom scripts. Similar, if less flexible effects can be achieved with either AI->Responses->Signal Response or AIWatchObj links, though these can only have one defined actor.
Responses perform a specified series of actions when they receive their trigger. The possible responses are found under AI->Responses. Only the AI who has the property will perform the action, though the effects you can choose are the same. The response can be Signalled from an AISignalTrap or direct from a button or similar via Switchlink. An example of a signal response is in station.mis, after completing your first assignment there is a woman (obj# 799) typing in one of the areas. This behaviour is achieved using a looped signal response where the typing motion cs116 is played repetitively. I will not go into any more detail of how to use these signal responses here.
AIWatchObj links is basically what it says- an AI watches the linked object and responds when the player, or itself, gets close to it. 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. You can also specify whether the actions are repeatable or only happen once. Again the AI who has the watch link performs the action, so the shotgun hybrid (obj 613) shooting the woman (obj 312) on medsci1 requires each to have a separate AIWatchobj set.
Always test conversations thoroughly as they are prone to errors, and do not depend on them functioning all the time unless you set their priority to absolute and even then they could, for example, have the AI be killed by an over eager player!
The Command list & Object Property lists
A full 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 attached, but this is not always helpful. The command 'list_props' will also dump a list of all properties to MONO, which can be copied out if desired. For new dark there is also a lot of documentation in the 'docs' folder.
A Note on the Original Levels
One of the best things you can do when learning how to do stuff is to check the original levels to see how it was done there. If you want to use a power cell to open a door, set up a replicator properly or have one AI chase another you can always check how it was done in the original game levels. Some stuff will be opaque because it requires specific scripts (the training in station.mis, for example) but a lot will have easy to access properties that define how something is done. The default levels supplied with the game are 'stripped', they have had the architectural and other brushes removed to save space so only have red objects and yellow light objects visible. However, the unstripped versions of most levels were made available prior to LGS going out of business and may be downloaded if you wish to see the architectural information. You can also make multibrushes in these unstripped original levels and copy them over using Multibrush-> Save Group then Multibrush-> Load Group in the destination mission.
And that is pretty much the end of the tutorial. In many ways it only scratches the surface of what can be done but hopefully it gives enough background information. If you have any problems or want to know how to do anything not mentioned here check for tutorials and forum posts in places like systemshock.org or TTLG (many Thief solutions will work for SS2!) and ask, chances are that someone will know either how to do something or whether it's possible.
Acknowledgement: This tutorial is based on the original ShockEd tutorial written by Totality and the rest of the release team
Loading...