SPLINTER CELL CHaos Theory
Destroyable/Damageable Objects
The Splinter Cell: Chaos Theory editor is based on Unreal technology, and those familiar with unreal map editing will be at ease with it.
There are many links and documents about how to build your first level, so we will not explain this once again here.
If Unreal map editing is a new world for you, we encourage you to have a look at what already exists on the Web.
You can find a good tutorial at PlanetUnreal.
https://www.planetunreal.com/architectonic/first_level.html
The important point is: you don't have to mess around with weapons, pick ups, and AI, as Splinter Cell: Chaos Theory is a totally different game and doesn't use any of them.
How to turn your basic map into an entertaining Splinter Cell: Chaos Theory playground.
So you've read everything about building a map in Unreal Editor and you now want to enjoy your work and play the game with friends?
Here is a quick guide to how to set up the objectives or the cool alarms you saw in the original levels.
For those already using the Splinter Cell: Pandora Tomorrow editor, you'll be at ease here, with many things working like they did in Splinter Cell: Pandora Tomorrow.
Please refer to another doc Editor_FromPandora_To_ChaosTheory if you wish to convert one of your Pandora's tomorrow map.
As we are building a Multiplayer map, we'll need more than one PlayerStart.
In fact, to be sure you won't have any problems, you have to create at least 3 "Merc Playerstarts", and 3 "Spy Playerstarts".
To define what side the PlayerStart is for, you'll have to change the TeamNumber field to
Spy
Merc
You can also use spawn points that can be triggered On or Off on demand by using STriggerPlayerStart instead of PlayerStart.
There are 3 different game modes you can use in Splinter Cell: Chaos Theory:
Story : Capture objectives (Neutralization, Data Extraction, Sabotage)
Disk Hunt : Pick up enough data disks to win.
Deathmatch : The name says it all. Kill or be killed.
Story mode allows you to use any of the previous Splinter Cell: Pandora Tomorrow game modes the way you want in your level.
This means you can still have Neutralization, Extraction or Sabotage, but you can also mix all of them to add more depth to your creation and adapt to your level better.
In the following example we'll set up a game with 3 different possibilities: Hacking, Extraction and Bombing/Sabotage.
This is the old Neutralization mode from Splinter Cell: Pandora Tomorrow and, once again, if you were familiar with the previous editor you'll feel at ease here.
When you have spotted the perfect place for your Computer, open the "Actor Classes" browser and look for the Actor/SGameplayObject/SObjectiveTrigger/ScomputerObjectiveTrigger actor.
Add it to your map by selecting the actor in the browser and using the "Add ScomputerObjectiveTrigger here" from the right-click pop-up menu.
Be careful where you position it, as the computer must be slightly ahead of any collision or else the player will not be able to capture it. (The height should be 78cm from the ground.)
Now edit the properties either by using F4 or by calling it up from the pop-up menu (right-click on the ND133).
Two fields
are important for now:
DominationCaptureTime >>
Time needed for spies to capture the objective.
TriggerName >> Name of the objective, displayed on the HUD.
Now that you've placed your console, you nee 434o1418e d to add an SObjective actor (invisible in the game) close to it.
Link the SComputerObjectiveTrigger you've just put in your level (the computer) to the SObjective. This is done by opening the SObjective Properties (select and press F4) and finding the Objective section.
You now need to add a field in the Triggers list by pressing the "Add" button and typing the exact name of the SComputerObjectiveTrigger actor in it. (The selected objects are visible in the upper left corner of your working window.)
You can trigger/untrigger an event once the objective is captured.
There's one more field you can set up right now:
ObjectiveName >> This name is the one displayed in the game HUD when the objective is being hacked in to, secured or taken.
As you can see, it's possible to add more than one field in the Trigger list.
This is because you can have more than one computer linked to an objective.
The way it works is that each objective capture time progress is independent (you can have one of the objectives hacked into up to 90% while another is still untouched), but capturing any of the SComputerObjectiveTriggers is considered as equivalent to capturing the whole objective, thereby disabling all the linked SComputerObjectiveTriggers.
You have probably also noticed that a new "TriggersERVisibilityZOnes" field has been added since Splinter Cell: Pandora Tomorrow.
By default, when you are in a different zone than the one your SObjective is in, HUD shows you the SObjective location (1 single icon), and when you enter the same zone your SObjective is in, HUD shows the exact location of any Triggers linked to this Sobjective (there can be more than one).
This is very useful when you are working with many triggers and don't want your HUD to look like a Christmas tree. ;)
This new field allows you to define zones in which the exact location will be displayed.
We'll pay more attention to it when working on a Bombing zone.
Do this for every hacking console you want in the map, each time using an SObjective to reference the ScomputerObjectiveTriggers.
Now we'll look at the Extraction mode where you have to grab an HDD from a computer and take it to a safety case.
SFlagDropZone
SFlagDropZones is an actor that is used to tell the game where the player has to take his HDD to capture the objective.
It looks like a small case and the only thing you need to adjust is its position because - like the computer - the case must be slightly ahead of any collision for it to work.
SFlag
SFlag
works for Extraction mode as ScomputerObjectiveTrigger does for
Neutralization.
It's the Trigger you'll need to reference in the SObjective.
Once again, you'll have to be careful where you position it, putting it slightly ahead of any collision.
DropZone >> Add the name of your Drop Zone (SFlagDropZone actor) to the list.
You need at least 1 Drop Zone and can use up to 5 of them.
Several SFlags can share the same Drop Zones.
ResetTime >> Time before a dropped tube returns to its normal location.
Don't forget to add a name in the SObjectiveTrigger section of the actor, and you are done with this one. ;)
In this game mode, spies need to plant a bomb in pre-designated spot and protect it until the countdown is finished and the bomb explodes.
SBombTargetObjectiveTrigger
This actor represents the places where spies can put bombs.
You'll probably want to use several of them so that the mercenaries have to search a bit before finding the bomb.
Don't forget to put an AbsentSkin on your trigger (this will be the texture shown until a bomb is planted), and be sure the center (pivot) of the object isn't behind any collision, or the bomb won't damage anyone when it blows.
CaptureTime >> Countdown before explosion.
TriggerName >> Name of the objective.
This is a kind of manager for the whole SObjective and ScomputerObjectiveTrigger team.
It's an invisible actor and you can drop it anywhere in your map (its position has no importance at all).
Open the actor's properties and find the Objective section.
Don't forget to uncheck the bChained field as it'll tell the game whether all objectives are simultaneously active or if they are linked up one by one in order (capture the 1st one to activate the 2nd, capture the 2nd to activate the 3rd, etc.).
The second very important thing is to tell the game what the game mode is.
We want Story mode, so find the GameMode field and set it to GM_Multi.
Now we also have to tell the game how many objectives the spies need to capture. This is done by setting up the MinimumObjectives field.
We want the spies to take 3 objectives out of 5 to win, so let's set it to 3.
Last but not least, you need to link all the Sobjectives to your SMission actor.
This is done by adding fields (use the Add button) to the Objectives list and typing the exact name of each SObjective.
You can trigger special events at the beginning of any Story Mode game with the AtResetEvent field in the Events section (this event will only be sent once, when the level is initialized after loading).
The last thing we need to do is set up the game time, number of lives and available game modes in your map from the selection menu.
To do this, set your view window to wire frame mode and right-click anywhere there's nothing to select.
Down the pop-up menu, you'll be able to select "Map Settings" and open the "SMapSettings Properties" window.
MapName >> This is the name the engine will display for your level.
You now need to add a Section in Modes (you can also add one in the Strings section, for texts).
GameModeId >> Set this to GM_Multi (as you did for the SMission).
RespawnTime >> Self-explanatory. How long in seconds before the dead come back into the game.
SentriesLives >> well.the number of lives for sentries.
SpiesLives >> Same for spies.
TimeLimit >> Game round duration.
Don't forget to save.
SMapSettings are saved in a special file named xxxxx-i.utx where xxxxx is the name of your level (the level is saved with a .SDS extension).
This file is saved in the Texture folder >> don't forget it! ;)
That's it! You should have everything ready to run your first Story game mode!
In this game mode, disks are randomly dispatched everywhere in the level, and spies need to pick up a certain number of them to win.
You need to place SDisks in the level if you want spies to pick some up. ;)
You need at least as many disks placed as the number spies need to grab, but - to add some randomness - you'll need to instance more disks than those finally displayed during game.
We usually have 30 SDisks in a level, and only 20 of them present in the game.
When instancing SDisks, you'll need to:
There are only 2 parameters for SDisks.
Group >> You can define groups for your disks. This allows you to alter the randomness a bit, as the engine will pick up random disks from group 1, then group 2, then group 3, etc, starting back with group 1 when there's no more group, and group 2, etc.
ResetTime >> Time in seconds before a dropped disk is spawned back at its original location.
No SObjective is used in this game mode.
This is an invisible actor, and you can drop it anywhere in your map (its position has no importance at all).
Open the actor's properties and find the Objective section.
Don't forget to uncheck the bChained field as it'll tell the game whether all objectives are simultaneously active or if they are linked one by one, in order (capture the 1st one to activate the 2nd, capture the 2nd to activate the 3rd, etc.).
Set the GameMode field to GM_DiskHunt and add as many Triggers field as you have SDisks in your level before referencing all of them individually.
You can trigger special events at the beginning of any Story Mode game with the AtResetEvent field in the Events section (this event will only be sent once, when the level is initialized after loading).
The last thing we need to do is set up the game time, number of lives and available game modes in your map from the selection menu.
To do this, set your view window to wire frame mode and right-click anywhere there's nothing to select.
Down the pop-up menu, you'll be able to select "Map Settings" and open the "SMapSettings Properties" window.
MapName >> This is the name the engine will display for your level.
You now need to add a Section in Modes (you can also add one in the Strings section, for texts).
GameModeId >> Set this to GM_DiskHunt (as you did for the SMission).
Handicap >> Number of disks spawned, visible to players in the game
NumDisksMax >> Number of SDisks present in your level (referenced in the SMission).
RespawnTime >> How long in seconds before the dead come back into the game.
ScoreLimit >> Number of disks spies need to pick up to win.
SentriesLives >> Well.the number of lives for sentries, of course!
SpiesLives >> Same for spies.
TimeLimit >> Game round duration.
Don't forget to save.
SMapSettings are saved in a special file named xxxxx-i.utx where xxxxx is the name of your level (the level is saved with a .SDS extension).
This file is saved in the Texture folder >> don't forget it! ;)
Your Disk Hunt mode is now ready for action!!!
As there's no rule or objective in Deathmatch mode, you'll only need to instance an SMission to tell the engine this game mode is present.
This is an invisible actor and you can drop it anywhere in your map (its position has no importance at all).
Open the actor's properties and find the Objective section.
Set the GameMode field to GM_DeathMatch and.that's all! ;)
You can trigger special events at the beginning of any Story Mode game with the AtResetEvent field in the Events section (this event will only be sent once, when the level is initialized after loading).
You'll need to change the map settings a bit as well, at least to tell the engine the game mode is present and what the default settings are for it (game time, number of lives and available game mode).
To do this, set your view window to wire frame mode and right-click anywhere there's nothing to select.
Down the pop-up menu, you'll be able to select "Map Settings" and open the "SMapSettings Properties" window.
MapName >> This is the name the engine will display for your level.
You now need to add a Section in Modes (you can also add one in the Strings section, for texts).
GameModeId >> Set this to GM_DeathMatch (as you did for the SMission).
RespawnTime >> How long in seconds before the dead come back into the game.
SentriesLives >> Well.the number of lives for sentries, of course!
SpiesLives >> Same for spies.
TimeLimit >> Game round duration.
Don't forget to save.
SMapSettings are saved in a special file named xxxxx-i.utx where xxxxx is the name of your level (the level is saved with a .SDS extension).
This file is saved in the Texture folder >> don't forget it! ;)
Get ready for Deathmatch!!!
Events are used to trigger things in the map, from switching a light on or off to raising an alarm, opening a door or disabling a camera network.
Almost everything that needs to be triggered uses events and they represent a powerful way to manage interactive or scripted items in your map.
The first VERY IMPORTANT thing you need to remember for ANY actor is:
The event field is used to send an event (to trigger another actor).
The tag field is used to receive events that others send (triggered by another actor).
Event >> Outgoing event
Tag >> Incoming event
Any word can be used as an event, so try to give logical names to your events: this will be of great help in building your level and debugging it.
The second important concept is the idea of Trigger/Untrigger.
It is as if you had 2 switches to control a machine:
One only turning it on >> Trigger
One only turning it off >> Untrigger
You can have actors sending only Trigger Events (TriggerToggle), some sending only Untrigger Events (UntriggerOnly) and some switching from one to the other, toggling between Trigger / Untrigger (TriggerControl). The same is true for those actors waiting for events to be triggered (Tag field): depending on what they are, some work only with Trigger events, others use both Trigger and Untrigger events, while others only react to Untrigger events.
Let's say we'd like to use one or more switches to turn a machine On or Off: there are several ways of doing this, depending on what is required.
Solution 1
SWITCH
TriggerToggle mode
Sends only Trigger Event
Trigger
MACHINE
TriggerToggle mode
Switches from one state to another
every time it receives a trigger event
Easy! Every time you press the
button, the machine changes state!
You can have more than one switch in TriggerToggle mode and this would not present a problem >> Any new Trigger Event sent/received would make the machine change its state.
Solution 2
SWITCH
TriggerControl mode
Sends Trigger
and Untrigger Events alternately.
Trigger Untrigger
MACHINE
TriggerControl mode
Waits for a Trigger event to turn on and
for an Untrigger Event to switch off.
This will work fine with 1 switch but if you want 2 or more switches to control the machine you may experience problems, depending on the state of each switch (if a switch sends a Trigger event to a machine that is already "ON", or an Untrigger event to a machine that is already "OFF", nothing will happen).
The value of this is that it allows you to synchronize several actors, knowing that none will be on when the other is off: if you send a Trigger event, the Machine will always be ON.
Solution 3
SWITCH SWITCH
TriggerToggle mode UntriggerOnly mode
Only sends Trigger Events. Only sends Untrigger events.
Trigger Untrigger
MACHINE
TriggerControl mode
Waits for a Trigger event to turn on and
for an Untrigger Event to switch off.
In this situation, one button will always turn the machine on (or leave it on) and the other will always turn it off (or leave it off).
This solution can be very useful in certain situations.
Let's say you want a "reset button" to turn the machine OFF whatever its state: just set the "reset switch" to UntriggerOnly, and you can be sure that, whatever the state of your machine, this switch will turn it off.
This might sound a little tricky at first, but play with it a bit and you'll soon realize it's not so complicated - and there are many things you can do with these simple combinations.
If you have spent some time building levels and playing around with events in Splinter Cell: Pandora Tomorrow, you'll know how often you can face problems with events, finding yourself unable to do things you'd thought easy because of editor and engine limitations.
SMagicEvent actor is there to make your life easier and allow you to create more complicated scripted events.
The idea behind it is simple: from one event received as input you can send as many different events you want, choosing whether they Trigger, Untrigger, are delayed or act as a toggle (Trigger/Untrigger, Untrigger/Trigger) or a defined state.
To do this, create at least one EventGroup in the Groups section by pressing the Add Button and one or more event property list.
Delay >> Time between the reception of an event by the SMagicEvent actor, and the moment the event is sent.
Event >> Name of the Event you want to send (every SMagicEvent can send several different triggers).
Type >> Type of event that will be sent (Trigger, Untrigger, or Switch between Trigger/Untrigger, beginning with one or the other).
ValidOn >> Should this event be sent when the SMagicEvent receives a Trigger or an Untrigger?
Setting up an alarm requires 2 kinds of actor:
Alarm : Invisible actors.
Detectors : Lasers, Volumetric Sensor, camera.
This is an invisible actor.
It's the one that displays messages and locks objectives or doors when an alarm is raised.
It's waiting to be triggered by lasers, a Volumetric sensor, a camera or any other actors that send Trigger Events.
This is a very powerful control center that you can also use to set up timed behavior or trigger several events at once.
AlarmDescription >> Name displayed when alarm is on.
Duration >> Duration of Alarm (in seconds).
Events >> A list of events you want to be Triggered when the alarm is raised.
These events will be Untriggered when the alarm stops.
MessagePriority >> 5 = Alarm mode.3=No Timer 0 = "control center" mode.
If set to 0, the AlarmDescription field will be displayed in green for mercs, and the AlarmDescriptionSpy will be displayed in green for spies when triggered, or else the engine will display a standard pre-recorded message.
MoversToLock >> movers in this list will be locked for the duration of the alarm.
ObjectiveTriggersToLock >> SComputerObjectiveTriggers
in this list will be temporarily
disabled for the duration of the alarm.
These are the eyes and ears of your alarm system.
They trigger an alarm by sending an event (the SAlarm must have the same
event in its Tag field).
You put this on a wall or a ceiling, and it projects a laser beam straight ahead.
Whenever a spy cuts the beam, it triggers the event (usually linked to an SAlarm).
It can be chaffed or sticky-shocked by spies (the timer can be tuned in the SGameplayObject section, in the StickyNeutralizationTime field) and it can also be disabled if a received event matches its Tag field.
BHideLaserInNormalVision >> Set it to True if you want to see the laser beam in normal vision.
DetectedClass >> The default is Spy (SPawnAttaque) but you can change it to Mercenary (SPawnDefense).
LaserLength >> The laser beam must be set to an appropriate length, otherwise it will not reach the opposite side or will go through walls and doors.
The unit used is centimeters.
SpawnPerCent >> This is how you set up random lasers and the number is percentage based.
50 means you have half a chance of the laser spawning at map initialization.
100 means that the laser will always be present.
SCamera Cameras detect presence by checking for actors in a cone of vision and the actor must be seen in order to trigger the camera (it will not be able to see a player who is hidden behind something).
Like the SLaserTrigger, it can be chaffed or sticky-shocked by spies (the timer can be tuned in the SGameplayObject section, in the StickyNeutralizationTime field) and it can also be disabled if a received event matches its Tag field.
There are a few things you can tune in the SCamera section, but they are pretty self-explanatory and do not require further explanation here.
The volumetric sensor detects presence in a collision volume.
Like the SLaserTrigger, it can be chaffed or sticky-shocked by spies.
As mentioned above, the SvolumetricSensor uses volume to detect the player. You will therefore need to create at least one volume to make it work.
Move the Unreal Editor's red brush (the one you used to create rooms and other BSP volumes) where you want your detection volume to be, adjust the size, and left-click on the little blue translucent cube labeled "Volume" to the left of the Editor.
Choose "Volume". This will create an invisible volume the same size, and in the same location, as your red building brush (you can toggle the "Hidden/Displayed" status of volumes by pressing the O key in the Editor).
Select the volume you just created and add its name to the Volumes list of your SVolumetricSensor.
You can have more than 1 volume for each SVolumetricSensor (to fit the exact size of a room for example).
Detection will only occur when the player enters the zones.
One of the coolest features in Splinter Cell: Pandora Tomorrow is probably the special dynamic lighting that casts realistic shadows.
I'm sure you'll want to add some to your level! We'll explain how it works in a little while, but first let's have a look at the different ways of lighting a map.
Static Light is the main tool you'll be using to bring light and shadow to your level.
Why? Because Static Lights look good, give you firm control over shadow casting and, as they are pre-calculated and static, they don't cost much on frame-rate.
We won't explain the detailed technical stuff behind every light, but you might like to know that they are based on Lightmap techniques for BSP and Vertex Color for static meshes.
To add a light to your level, simply right-click and select "add light here".
You'll notice the S in the light icon, telling you it's a Static Light.
IMPORTANT:
If you want the Static Lights to light actors as well, you'll need to set "bApplyToInGameLighting" to "True".
You'll mostly want to use omni-directional lights (LightEffect=LE_None), projector lights (LightEffect=LE_Spotlight) and sunlight (LightEffect= LE_Sunlight).
With regard to sunlight, don't forget that this is a directional parallel light cast from FakeBackdrop material (it won't work at all if there's no FakeBackdrop material in your zone).
The drawback is: Static Lights can't be turned on or off, and any change in the level won't affect lighting and shadows.
Dynamic Lights aren't as precise as Static Lights.
They take up their fair share of frame-rate, and unfortunately do not cast any shadows. They also go through walls and floors to the distance that the lightradius has been set to (to bypass this problem, set the light to "bAffectOwnZoneOnly" and cut space in zones according to where you want the light to work or not).
Dynamic Lights are usually used in conjunction with STriggerLight actors so they can be switched On/Off at will.
What makes a light "Dynamic" is that the "bDynamicLight" field is set to "True".
These are the spectacular dynamic lights that cast nice shadows in Splinter Cell games.
They look awesome, but cost a lot in terms of frame-rate.
To set up an Echelon Light, change your LightEffect to "LE_ESpotShadow".
Echelon lights are directional (like spotlights) and use special parameters.
The easiest way to orient your light the way you want is to use the "lock to selected actor" option and select your light in 3D view.
When you do this, your current view will be the actor's position and view: if you move the camera or rotate it, it'll move and rotate the light the same way. (Don't forget to turn off the option as soon as you are done. ;) )
EchelonBias >> This is used to fix artifact problems on lights by adjusting a Z bias.
No rule here, just trial and error.
EchelonNormalInfluence
>> How important is orientation of normals for light? With a value of 1, normal orientation is very important; with 0.5, most surfaces will be well lit whatever their orientation (0.9 is usually a good setting).
EchelonRange >> How far does the light work? Be careful, as the further it goes, the heavier it will be on frame-rate.
NearPlaneRation >> Ratio between light source and projection area. A ratio of 1 would make a source area as big as the place it's lighting (good for sunlight through windows) and a ratio of 0.05 is usually good for projectors with a small light source.
ShadowZBufferHeightType >> How precise will your lighting and shadow be? The bigger it is, the better the definition, but the heavier it is on frame-rate and memory. (Note: whatever the settings, the shadows displayed in the Editor are locked to 512x512).
ShadowZBufferWidthType >> same as above, for width.
SpotHeight >> Height of the lit area (in centimeters).
SpotWidth >> Width of the lit area (in centimeters).
One important "detail" about echelon lights is that they won't affect any object that uses an Alpha channel texture.
Now, you're probably wondering about those nice lightbeam effects you've noticed in the game.
They can be done easily, but I'm afraid they're a frame-rate killer! You've been warned! ;)
Lightbeams only work with Echelon lights.
LightBeamFalloffScale >> fade off percentage. 0.5 means the lightbeam will disappear at 50% of the EchelonRange defined for the light.
LightBeamInitialAlpha >> To set transparency of the lightbeam. 1is the minimum.
LightBeamMesh >> Points to the static mesh that will be used to build the lightbeam effect. This is compulsory and you can find one in StaticMesh\TestMapStaticM\Accessories\LightBeam.
UsesLightBeam >> Set it to "True" if you want to use a lightbeam with your light.
As mentioned earlier, Echelon Light and Lightbeams consume a lot of power, and a few words about how to optimize them might come in useful.
This actor is a key feature for interactivity in your map.
It can be used to control Dynamic Light or to change the visual appearance of objects, either by triggering it or depending on the amount of damage received.
We won't explain how it works in full detail but a little information and a few examples will help you understand how it works.
For example, one of the cool things you can do with an SGameplayObject is to create interactive lighting.
Whenever the SGameplayObject is triggered (Tag field of the event section) it'll switch to the TriggeredSkin as new material ID0 and turn the light On/Off.
The first thing you need is a light, but - for an interactive light - you'll need to use an STriggerLight actor instead of the usual Light one.
Put it where you want, adjust the intensity, color and radius, and decide whether you want it to be initially On or Off in the bInitiallyOn field of the StriggerLight section.
Now that you have a light, you'll need a visual light source for it, but this time, instead of using a Static Mesh, add an SGameplayObject actor to your map.
Ok, it has the visual of a little camel head, but you can easily make it look the way you want by going to the Display section of your SGameplayObject and setting the StaticMesh field to your static mesh and changing DrawType from DT_Sprite to DT_StaticMesh.
You should now have an StriggerLight and an SGameplayObject with your light source static mesh visual.
ObjectLights >> Add a field and use the name of your StriggerLight.
StickyNeutralizationTime >> Time the light will be switched when chaffed or shocked.
TriggeredMesh >> What mesh will replace the usual Static Mesh once triggered.
TriggeredSkin >> Texture replacing the usual one on current static mesh (the material changed is always the one with ID 0).
In this example we'll create an explosive barrel like the one you can find in the Factory.
The barrel can be destroyed either by taking damage or if triggered by another event (in this case, the big explosion in the Machine Room).
We'll mostly talk about the SGPODamages section, but be sure you have the BDamageable field checked in the SGamePlayObject section before starting.
BCanDamageActor >> Set it to "True" if you want this actor to damage other actors.
DamageActorPoints >> Damage inflicted at pivot position. Damage is only inflicted if there's no obstruction between SGameplayObject and the damaged actor.
DamageActorRange >> Damage will be inflicted up to range, with a linear decrease from pivot to range limit.
DamageActorType >> Different effects for different types of damage.
DamagedMeshes >> You can use several different visuals based on different amounts of damage received by the actor.
BDisableCollision >> Remove collision from the object.
Event >> Event that can be sent when the Percent (see below) condition is reached.
EventType >> Type of event to send.
Percent >> The amount of damage received before this mesh is displayed (50% = half, 100% = object destroyed).
Skin >> Which texture should replace the original one (remember that only material ID0 is changed).
StaticMesh >> Which Static Mesh should replace the original one.
DestroyOnEventFrom >> If you want a logical event to trigger the destruction of the object (as opposed to receiving damage through game collision), you MUST reference the actor that will trigger the destruction. If you only let the Event/Tag mechanism do the trick, nothing will happen.
HitPoints >> Self-explanatory. J
OnResetEvent >> Event to be sent when actor and damage are reset.
OnResetEventType >> Type of event to send on reset.
PercentDamageRefillable >> On reset, the quantity of hit points (in %) that should be given back to the actor.
ResetDamageTime >> Time in seconds before the actor is reset.
ShakeRange >> Range inside which the camera will be shaken when the actor is destroyed.
SpawnableObjects >> You can spawn particles or effects, but you need to know that particles from the same emitter will be shared amongst all the actors using it. Therefore it's better to simply trigger an instanced emitter.
TakeDamageTypes >> The type of damage an actor is vulnerable to. You can add as many sections as needed, SDTBase being regular weapon shots from mercs.
Movers are special actors, using a static mesh as visual and able to move.
They have great gameplay potential, but we'll focus here on their main role: as doors.
The Door To create a mover, you first need a static mesh that will be used as a visual for it.
Select the static mesh you want and create a mover by using the appropriate tool.
Don't forget that the mover will be added at the place your red building brush is standing.
Now you should have your purple/pink mover in the level and we can start editing its properties.
The first thing you might want to do is edit the InitialState field in the Object section (down the properties list) as it defines the way your mover will react to received events.
Most of the time, you'll probably want to use:
TriggerControl >> Trigger Open, Untrigger Close).
TriggerToggle >> Trigger swaps state between Open and Close.
TriggerOpenTimed >> Door remains Open for some time and then Closes when triggered.
TriggerCloseTimed >> Door remains Closed for some time and then Opens when triggered.
For a door, we'll use TriggerOpenTimed, so that the door opens when the players comes near, returning to the closed state after a certain period of time.
Movers works with key positions, moving from one key to another.
The default key is 0, and if you want your door to open, you need to make a number 1 key that will be your open position.
When your closed door is in the right place, change the KeyNum field to 1 and move the mover so that it is where you want it to be in its opened state.
You should now have:
KeyNum 0 >> Door Closed
KeyNum 1 >> Door Open
You can have up to 7 different keys, but to make it work, you'll need to increase the NumKey field to 7.
Be careful, as KeyNum (defined position at one key) isn't the same as NumKey (how many keys in the sequence).
Don't forget to set KeyNum back to 0 before we go on.
Note: if you want to move a mover, be sure it's on KeyNum 0, otherwise you'll only change the position of the mover at the defined key instead of moving the mover's global position. ;)
MoverEncroachType
>> This is used to defined how the mover will react when bumping into an actor while moving.
We could build a "killer door" that crushes anyone trying to prevent it from moving (ME_CrushWhenEncroch) but we are kind people (aren't you? ;)) so we'll set it to behave more appropriately!
ME_WaitAndRetryWhenEncroach
MoveTime >> Time in seconds to move from one key to another.
StayOpenTime >> How long the door remains open (in seconds).
BTriggerOnceOnly >> If set to "True", the mover will only move once.
This is a very convenient invisible actor, sending an event when someone from the defined class (Spy or Merc) enters its zone.
It is very useful to trigger doors and make them open when players are getting close.
The only things you need to define are:
>> Collision radius and height in the Collision section for the size of the detection zone.
>> Whether it sends a trigger event (bUntrigger to False) or an untrigger event (bUntrigger to True).
>> Whether it should detect Spies (SpawnAttaque), Mercenaries (SPawnDefense) or both (SBasePawn).
This is a way to make movers react differently, depending on what actor triggered them.
There's nothing special about it - just a few fields you can set to react in specific ways when the mover is triggered by a defined actor.
EventFromActor >> If the mover has been triggered by this actor, then it'll use the specific SpecialBehavior fields instead of the normal one.
Movers can send events when reaching a particular state.
Closing is for moving towards key number 0.
Opening is for moving from key 0 to key number x.
The difference between Closed and Closing is the moment the event is sent.
SLift can be found in Mover / SLift and it's a new actor based on a mover that was specially designed to create elevators.
With it, you can easily synchronize doors and activate the right switch depending on the floor the elevator is.
If you are planning to have an elevator in your level, I strongly suggest you use this actor.
As always, the first thing to do is to go to the Display section and change the visual and replace the camel face with your favorite elevator static mesh.
The SLift itself should be your elevator, the one players will walk on.
In the Mover section, define the key position for the different floors, just as you would do with a standard mover, change MoveTime if needed and move on to the SLift section
If you now open the SLift section you can see 2 sections: one called DoorsAndSwitches and the other called LiftDoors.
In the DoorsAndSwtiches section, add 1
subsection per floor (
For each floor, you'll need to indicate the opened external door of the elevator and the active switches.
Doors are standard movers with 2 keys:
Key 0 >> Open Door
Key 1 >> Closed Door
Change KeyNum in the mover section of the door corresponding to the floor the elevator is on at init.
Switches are standard SInterupteur triggering the Slift to make it change floor.
SInterupteur TriggerMethode (in the Interaction section) should be in TriggerToggle mode
Don't forget to make them initially usable or not depending on their position at init.
The LiftDoors section uses a special SLiftDoor actor (in the mover actor subsection).
Those doors are the inner door of the elevator, the one moving with the elevator when it changes floor.
As with external doors, you need to define 2 positions for them.
Key 0 >> Open Door
Key 1 >> Closed Door
They are linked to the Slift movement, and this one won't move until SLiftDoors are closed.
This way, you'll have nicely synchronized and bug-free elevators! J
|
