Ive noticed that there are lots of posts in this forum about how to do certain things like having a helicopter appear to be landed or how to have text float over an object, so to make it easier for everyone to find answers to these and similar questions I will be posting these techniques and tricks in this thread. Feel free to post any techniques or tricks you've found in the editor here and I'll add them in.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TABLE OF CONTENTS
I.General Scenario Design Techniques - Eye candy, unit/building manipulation, terrain sculpting, etc.
a) How to save all of the triggers, conditions, effects, objects, and areas of a scenario into a text file
b) Opening the grid reference
c) Using the duplicate feature effectively
d) Having text appear as your cursor moves over an object
e) Messages that don't have a trigger
f) Having a submarine float at the surface of water
g) Having a helicopter appear to be landed
h) Changing an airplane's flight with triggers and a little terrain altering
i) Having plane(s) that fly and are still in your control even with 0 flight time
j) The quick sand trick
k) How to sculpt a pyramid
l) Having dead units remain on the ground where they died
m) Making units/buildings purple or black
n) Making units/buildings invisible
o) Underwater units/buildings
p) Units/buildings in space
q) Stretched buildings
r) Airport Tricks - Underground buildings, floating buildings, and other cool effects.
s) Ghosts
t) Teleporting units
u) Making units that the scenario editor can't place at anytime on demand
v) Red cliffs
w) Having multiple conditions all rolled into a single condition in a trigger (reduces lag)
x) Having rain fall on the entire map and having rain fall continuously
y) Detecting cheating using triggers in multi player scenarios
z) How triggers, conditions, effects, and objects can affect CPU performance in your scenarios
II.Bugs within the Scenario Editor
a) Things that cause the scenario editor to crash
b) Little problems within the scenario editor
c) Special rules that you should follow to prevent problems in your scenarios
III.Example Triggers/Trigger Systems
a) Give all units of a (specific class) a (resource type) when produced
b) Graphically enlarge/shrink units of a (specific class) when created
c) Limit the amount of a (specific class) unit/building a player can make
d) Displaying player kills in an object or as a resource
e) Giving units the appearance of having to reload their clip of ammunition
f) Unit name change trigger
g) Creating an object when another object reaches an area
h) Spawning units
i) Infinite resources
IV.Cinematics Made Easy by VEMON_OZ_RICK
V.Cinematic Techniques
a) Having your camera circle an object
VI.What Causes EE to Crash During a Scenario
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I. GENERAL SCENARIO DESIGN TECHNIQUES
a)How to save all of the triggers, conditions, effects, objects, and areas of a scenario into a text file.
To do this, you have to hit one of the following key combinations using your keyboard while in the trigger section of the editor:
Try Ctrl-L or Ctrl-S
They will be saved somewhere in your Empire Earth directory (C:/Sierra/Empire Earth). This will create two files:
"Scenario Triggers.txt" and a "Scenario Triggers.scn"
This is useful for trigger debugging. You can print this .txt file so that while you're playing your scenario, you can read through your triggers to see what the problems might be.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
b)Opening the grid reference:
Press T. To turn the grid reference off, press T 15 times. This is useful for distinguishing one map tile from another more easily.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
c)Using the duplicate feature effectively:
The Duplicate feature is a lifesaver when it comes to cutting down on the time it takes to make a scenario. To optimize the effectiveness of this feature when using the editor, you always want to start with AREAS. What I mean by this is, always make the areas you want to use for your objects and effects first, before you make anything else. Once you’ve got your areas, make your OBJECTS. Then make your EFFECTS, then CONDITIONS, and so on. The order is simply right to left in the trigger area of your scenario editor. Now in case you don’t understand what I’m talking about I’ll give you a step by step walk through on how to use the duplicate feature effectively.
Step 1. Make six objects (usually in a multi player scenario you will have six objects for a specific class of object, 1 for each player, and have these objects be the targets of class name and class attribute effects).
Step 2. Make a single effect and target the first object.
Step 3. Duplicate the first effect and left-click the target object field and hit the down arrow once.
Step 4. Duplicate the second effect and do the same thing.
Step 5. Continue to Duplicate and scroll down the object until you have six effects that each target one of the objects.
Step 6. Typically you will use some kind of object as your condition in triggers, so we will assume that you are using the six objects as your conditions here. Create a trigger and make the first object its condition and the first effect its effect. You’ve got a trigger that says that when the first object exists the first effect will be fired.
Step 7. Duplicate the first trigger and then left-click the first condition field and press the down arrow. Then left-click the first effect field and press the down arrow. You’ve got your second trigger! Repeat until you’ve got six triggers that use the six objects and effects.
Now that you know how to use the Duplicate feature effectively, you can produce your scenarios in a lot less time.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
d)Having text appear as your cursor moves over an object:
Use the class name effect to change the name of the object and put a space before the new name.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
e)Messages that don't have a trigger:
1. Delay this trigger---effect>send dialogue
2. Save the game on the second that the dialogue should be sent-[but the dialog must not have been sent]
3. Load the save
4. Delete the trigger
-Thanks to chikoroll for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
f)Having a submarine float at the surface of water:
Place a submarine in water, then double click it and move it somewhere else in the water. Now it will be above the surface of the water.
-Thanks to LXPeng for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
g)Having a helicopter appear to be landed:
There are several ways to accomplish this.
1. Place a helicopter somewhere on the map and then raise the elevation of the land under the helicopter until the helicopter appears to be resting on the ground, then bring the elevation back to zero.
2. Place a helicopter somewhere on the map and then place an AA gun underneath of it. Now remove the AA gun.
3. Using the "snap rotate" effect you can have a helicopter snap to the ground. This technique is used while a scenario is running.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
h)Changing an airplane's flight with triggers and a little terrain altering:
You place an airport under water, then the plane will actually stay on the surface (they won't dive down). They disappear when they are vertically above the hangar. This is best used in cinematic mode for maybe a plane that is about to crash, or just to have it moving close to the surface and then rising again. You remove the airport and it will rise up to normal altitude again, and maybe then go to another nearby underwater airport if you want to repeat the animation. You can also hide the airports if needed by making it invisible.
-Thanks to The Richard for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
i)Having plane(s) that fly and are still in your control even with 0 flight time:
1. Place plane(s) on map
2. Task object plane to area (not off map) (delay = 0 seconds)
3. Set unit attribute (flight time) of object plane to exactly 5 (delay = 0 seconds)
4. Time warp object plane (delay = 2 seconds)
5. Change owner of object plane to same player (delay = 88 seconds)*
* Note that the time between the time warp effect on the object and the change owner effect on the object must be 86 seconds exactly, because this is the time that a time warp effect takes.
-Thanks to chikoroll for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
j)The quick sand trick:
You place some mechanic unit (it works better this way) on the ground. You transform the grass into sand. You place a cliff with the border on the place where the units are. You click and they'll look like they're getting buried by sand.
-Thanks to Lusitan Warrior for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
k)How to sculpt a pyramid:
Pyramids are the perfect eye candy for desert maps and they usually impress reviewers.
1. Create a plateau with the desired height, make sure the plateau's size is at least 5x5 tiles.
2. Choose the size of the summit at the center of the plateau (1x1, 2x2,...) and mark this area with impassible tiles.
3. Place lines of minarets on each side of the marked area (same number of minarets on each side), so you get a cross like shape with the summit of the pyramid in the center, the shorter your lines of minarets are, the steeper the slope of the pyramid will be.
4. Change the ground level to 0 around the perimeter of the cross, mark this perimeter with impassible tiles, now make a square with ground level 0 around the cross: you have now sculped the basic shape of a pyramid.
5. Remove the minarets and any hills that are left surrounding the pyramid.
6. Add the finishing touch by changing the pyramids surface (I prefer light colored marble tiles.
You may also want to add a layer of sand that is different from that of the rest of the map around the perimeter of the pyramid.
-Thanks to Rameses for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
l)Having dead units remain on the ground where they died:
To have a dead unit remain on the ground forever, simply use the class attribute effect to give the unit a resource before it dies (food, wood, stone, gold, or iron will work). Once the unit dies, its corpse will remain on the ground until a citizen harvests the resources from it.
This can add some realism to a scenario as bodies do take a long time to decompose. Also, you could have citizens appear to be looting the corpses of fallen soldiers.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
m)Making units/buildings purple or black:
Change ownership of a unit 1 second after it is teleported (use teleport graphic effect) to be black, 2 seconds after to be purple.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
n)Making units/buildings invisible:
Reduce the graphic scale of the units/buildings you want to be invisible by 100%.
-Thanks to The Richard for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
o)Underwater units/buildings:
Place units/buildings on above water terrain, then lower the elevation under the units/buildings until they are under water.
-Thanks to chikoroll for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
p)Units/buildings in space:
Place units/buildings on normal land then change terrain to space under them.
-Thanks to chikoroll for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
q)Stretched buildings:
1. Make cit for human, 2. player page change to the epoch of building you want
2. Test
3. Place the foundation for the building and build it a bit
4. Save
5. Load
6. Change owner of object -stretcho building, to whoever you want to own it
7. Test
8. Save
9. Load
10. Unit attribute object el stretcho building, hit points increase by 100%
11. Test
12. Save when the building is tall enough to your likings, if you make it too big just the foundations will be seen, and you cant click on it- good for making building sites
13. Load the save
* To make the building thinner, add the trigger, graphic scale reduce by x% (40% is usually a good amount)
-Thanks to chikoroll for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
r)Airport Tricks - Underground buildings, floating buildings, and other cool effects:
By placing airports on the map (in a certain way) using triggers, you can raise/lower elevation of the 2x6 tile area that the runway of the airport takes up.
Here's how you do it:
Create an area for the airport that is 2x2 tiles, that are the exact same elevation, and are either above or below the surronding tiles. The airport hanger section is what is created in the 2x2 area, the 2x6 runway section is the area that is either raised or lowered. As long as the 2x2 area is not below 0(zero) elevation, or next to the edge of a cliff, it will create the airport.
However, for the time being, the DIRECTION of the airport created by triggers, cannot be controlled. Except if it is created on top of the runway of another airport(then I believe it creates the same direction as the existing airport it is created on. Airport runways create underneath just about every object that can be placed on a map, so i dont know what else yet that can control the direction in which it made.
You will probably want to have the airports be invisible when created. To do this simply add this to the objects of the airports you create for this technique:
Has attribute... graphic scale min=0, max=0
Some good uses:
- Impassible water can be removed, on command, without revealing the presence of the airport, to say, for example, make a magical bridge
- The effect causes a sharp cliff-less terrain/wall face that is passable to units.
- The entire runway of an airport can be created underneath other buildings and objects such as perhaps trees (haven't tested it on anything other than buildings). This can make planes appear to go through buildings or land in trees or what not.
- When saved during play the "cliff-less" wall faces have cliff faces upon replaying(this can be used to let triggers know if a game has been saved or is being played from the beginning, or at a certain point in the game).
- Cliff-less walls can be made over most or all of a building, then saved in play. When that same game is opened in the map editor, the building will appear to be built inside a cliff.
- Units might be put inside cliffs and attack or use their power from inside the cliff (*needs confirmation).
-Thanks to _o0XxX0o_ for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
s)Ghosts:
1. Object graphic scale 0%
2. Object graphic effect fireball
-Thanks to chikoroll for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
t)Teleporting units:
1. Task object in area Y to off map
2. Task object off map to area X
This way you do not lose your team.
-Thanks to chikoroll for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
u)Making units that the scenario editor can't place at anytime on demand:
1. Make the object... say a nuke (place missile base an give the resources~~ make it a target and fire
2. Save the game
3. Load the save
4. Object>select on map
5. Object>object specification> use object ^the one selected
6. Say how many you want of it in area or[not] in area off map
7. Create object ~the specification one
there ya go units on demand that cant be made in the scen editor
You could use this for projectiles, missiles, etc. (anything you cant make by normal methods in the scenario editor). This is also used for calamities you don't want to see the effect of (volcano with only the flames-no mountain).
-Thanks to chikoroll for this one
Here's another way to do this:
1. Create a trigger that loops and uses an area effect calamity (time warp) that uses a certain area on the map. Set the condition of this trigger to be always true.
2. Have a nuclear sub or missile silo launch missiles that will travel across the area affected by the effect calamity. Missiles or any other projectiles will warp out while passing through the area, and appear lying on the ground later (and stay there).
A scenario can be setup so the projectiles are laid in position first, then saved, then used at the beginning of the scenario for eye candy.
-Thanks to _o0XxX0o_ for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
v)Red cliffs:
Using the following random map script, you can access red cliffs in the scenario editor:
http://ee.heavengames.com/downloads/showfile.php?fileid=236
Using a winter map you can access gray cliffs. The different color cliffs are not a mod to EE. The Sahara script simply unlocks the red cliffs in a scenario, and then the cliff type is saved as part of the scenario.
The red cliffs would be really good for a scenario on Mars for example, or any other time where they suit the scenario more than the normal cliffs.
-Thanks to rwilde for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
w)Having multiple conditions all rolled into a single condition in a trigger:
The idea behind this is to cut down on lag.
1. Object - Unit has attribute A
2. Object - "Use object" (the above unit) and has attribute B
3. Object - "Use object" (the above unit) and has attribute C
4. Object - "Use object" (the above unit) and has attribute D
5. Object - "Use object" (the above unit) and has attribute E
6. Condition = Object from step 5 exists.
For effects (if for that unit) - use object from step 1.
-Thanks to chikoroll for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
x)Having rain fall on the entire map and having rain fall continuously:
1. Make area (select continent tile) - 1 tile should be the indicator for this type of area
2. Effect > Game > Graphic effect > Rain
3. Make a trigger that has condition of always true and uses the effect you just created.
Copy this trigger multiple times to make it rain harder.
To have it rain continuously, you need to make two triggers exactly the same as the one above. One of these will fire only once (so it will NOT have the looping box checked) and will have a second effect. This second effect will be a trigger effect that turns the second trigger ON. The second trigger will have starting state of OFF and will have the looping box checked. Lastly, the second trigger will have conditions true for about 2 minutes and 4 seconds (124 seconds).
To have it rain harder and rain continuously, you will need to make multiple sets of both of these triggers.
Please note that rain does cause lag if not every player in the scenario has a high performance CPU. I personally recommend adding triggers that let the player(s) playing your scenario turn the rain causing triggers on and off using chat commands. Of course, players with low system specifications can disable the rain in just their game by lowering their graphic level in the options menu. Having the option to turn off the rain causing triggers allows the host of a scenario (if multi player scenario) the option to reduce lag. Not everyone is familiar with the graphic options in EE.
-Thanks to chikoroll for the entire map part
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
y)Detecting cheating using triggers in multi player scenarios:
I realize that cheating isn't that common these days in multi player scenarios, but just to be on the safe side you can use the following techniques to prevent cheaters from ruining one of your games. Cheaters use programs called trainers to access the cheats in EE (the two primary cheats they use are "Asus Drivers" and "my name is methos").
Asus drivers reveals the entire map and my name is methos reveals the map and gives 100,000 of each resource.
Since the "chat contains text" condition does not work in multi player scenarios, some other ways are needed.
Both of these cheats involve revealing the entire map to the player who uses them.... Which is a difficult thing to detect... Since object condition "visible by player x" only applies to units near that object(not seen by the player).
The solution.... missile silos...
As far as I know, missile silos tasked to an object are the only thing that will attack another object automatically once that object becomes visible via "visibility on", without being in its own line-of-sight.
So...to detect if someone has used asus drivers or my name is methos...
1. Place a missile silos somewhere on the map (one per human player).
2. Reduce the LOS (class attribute) for all of the human players' missile silos to 0.
3. Reduce graphic scale for the missile silos to invisible (0% graphic scale makes them invisible).
4. Reduce attack for the missile silos to 1 (missile silos won't fire if their attack is 0).
5. Loop a trigger that has condition always true, and effect task missile silo to a world object that is attackable (a statue for example). I suggest making one trigger per human player in the scenario (so that you can turn off the trigger corresponding to their missile silo in the event that they are kicked out of the scenario for cheating).
6. Make a trigger for each human players' missile silo with the condition being an object... select on map the missile silo, does NOT have state "idle"... and with effect defeat player x (the cheater), and object effect... remove missile silo for player x, and trigger effect turn off looping trigger that you made in step 5 for player x.
This means that if player x uses asus drivers, player x's missile silo will start to attack the statue that player x's missile silo is tasked to by the trigger from step 5, and that missile silo will no longer be idle. Therefore meeting condition "missile silo NOT idle exists", firing the trigger for player x you made in step 6.
You may want to include a media effect in the triggers in step 6 that sends a chat message to everyone explaining that player x tried to cheat.
-Thanks to _o0XxX0o_ for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
z)How triggers, conditions, effects, and objects can affect CPU performance in your scenarios:
You're correct in assuming that triggers in and of themselves don't affect performance. I've yet to notice any significant performance changes from having 5, 50, or 500 Triggers.
For taking up CPU time, there is no difference between a looping and non-looping trigger. They both have to be checked every second to see if they should fire. The difference comes after they fire- the non-looping trigger will get turned "Off", so the game will stop checking it. A performance problem that does result from loops is in loops which come out as "True" every second, meaning that the game is constantly performing your effects. If these effects deal with large amounts of units, you'll get some slowdown.
You will also get a noticeable lag if you have conditions and effects that deal with large numbers of units. For example, a condition such as "Player 1 Unit HP = 50 Exists" will be much more performance friendly if player 1 only has 5 units, than it will be if they have 500. Also, quantities matter. A condition (or effect) looking for 50 units with 50 HPs will run slower than one that only needs to find 1. To see an example of this, play the ultimate scenario in the Russian campaign (Change of Heart). After the cinematic sequence where Molotov defects to the US, I basically have a "Give All Player 1 Units to Player 2" trigger and a "Give All Player 2 Units to Player 1" trigger. The slowdown while these execute is very noticeable on my 750MHz, so much so that I moved the last bits of dialog to happen after the cinematic was over, to distract the player from watching the game chug. So, my tips on trigger optimizing are as follows:
Make sure that conditions which involve checking large amount of units are evaluated only when needed. In other words, the trigger dealing with the 500 man Prussian army should not be "On" if the Prussians aren't going to be needed yet.
Make sure that any condition or effect has objects which can be quickly checked. In these cases, "select on map" objects are much better than "object specification" ones, since the game already knows what to look at. In most cases you may not be able to find a way to simplify your specified objects, but it's something to check out.
Don't allow loops to execute every second if they deal with creating, removing, killing, or converting large numbers of units, or if they have conditions that involve large amounts of units.
Reduce the amount of units on the map. This may be the only way to improve performance if you're sure your triggers are to blame, but by the same token large numbers of units will create lag for other reasons, so it's always best to use as little as you can get away with.
My last piece of advice, though, is to not worry about it at all, unless you're sure you are noticing some lag. If it ain't broke, don't fix it.
-Thanks to SSSI_Eggman for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
II. BUGS WITHIN THE SCENARIO EDITOR
a)The following is a list of all the things that cause the scenario editor to crash:
1. Hitting the up arrow in the trigger state effect when you’ve already got ON selected (Art of Conquest only)
2. Sometimes when "painting" the map with terrain the game will crash. Make sure you save often when making map modifications. Usually happens when painting with a large brush.
3. Sometimes when you've had EE:AoC open for a long time and switch from the effects portion to the objects portion in the trigger area of the scenario editor, the program will crash to your desktop. This has occurred when I have been editing my scenarios that have a lot of objects and effects (over 2000 effects and 2000 objects). This probably has to do with RAM usage, but I'm not entirely sure (I have just under 800mb of RAM).
b)The following is a list of annoying, little problems within the scenario editor:
1. If you’ve got cliffs in your map and you try to use the "paint hills" tool, the cliffs will be severely distorted if you accidentally try to paint the hills near them. If you mess up your cliffs in this manner, you will most likely have to open up a previous version of the scenario you’re working on to "undo" the mistake. Saving often will lesson the time it takes to make terrain detailing with painting hills near cliffs.
2. In EE:AoC and EE, you cannot use an object that has one moveable object near/in LOS of/in range of another movable object as a condition in a trigger or as the target of an object effect, unless one of the movable objects is in an area.
3. When tasking (attack-move) a movable object to an object that is not attackable (a tree for example), the object you're tasking becomes stuck on the non attackable object.
4. If there are too many words in a dialog box, during the game, it will not go away until you press ESC.
c)The following is a list of special rules that you must follow so that you don't encounter difficulties with your scenarios:
1. Unit attributes and class attributes cannot be "fired" at the same time within the same trigger.
2. Whenever you use sound in the editor, you need to realize that Empire Earth is not capable of keeping track of every sound file you’ve got playing at one time. This means that once you play a sound file, it will continue playing until it either finishes or is interrupted and stopped by beginning cinematic mode. You cannot resume a music track from where you stopped it using the start cinematic mode effect.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
III. EXAMPLE TRIGGERS/TRIGGER SYSTEMS
a)Give all units of a (specific class) a (resource type) when produced:
DESCRIPTION:
This trigger gives/takes away a certain amount of a resource to/from a unit after the unit is spawned somewhere on the map or created by the player at a building. For example, you would use this type of trigger set up if you wanted every long swordsman player 1 makes to have 30 gold.
TRIGGER EXPLAINED:
You use this trigger set up when you want to give/take away a certain amount of a resource to/from a bunch of individual units. You use the unit attribute variable to allow you to isolate a single unit so that you can give/take away a certain amount of a resource to/from it without getting it jumbled up with other units on the map. The extra stuff in this trigger prevents some units from getting too much of the resource and others not getting any.
VARIABLE DEFINITIONS:
x = the amount of the specific resource to give/take from the unit(s) effected
y = the number of the player who owns/controls the unit(s)
(object 0) player y; class = (specified unit); min. = 1; max. = 1; has attribute unit variable 1 equal to min. = 0, max. = 0
(object 1) player y; class = (specified unit); min. = 1; max.=1; has attribute unit variable 1 equal to min.=1, max.=1
(effect 0) unit attribute; (object 0); increase (unit variable 1) by 1
(effect 1) unit attribute; (object 1); increase/decrease (resource type) by x
(effect 2) unit attribute; (object 1); increase (unit variable 1) by 1
(trigger 0)
starting state = ON
conditions true for = 3
looping? = yes
CONDITIONS = (object 0) exists
EFFECTS = (effect 0) with delay = 0; (effect 1) with delay = 1; (effect 2) with delay = 2
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
b)Graphically enlarge/shrink units of a (specific class) when created:
* This is the most efficient way to do this. Much better than looping a single trigger that continuously sets the graphic scale to an exact # for all units on the map within the parameters of the object affected.
DESCRIPTION:
This trigger graphically enlarges or shrinks a unit once it is spawned somewhere on the map or created by the player at a building. For example, you would use this trigger if you wanted all of the units that player 1 produces to be graphically enlarged or shrunk.
TRIGGER EXPLAINED:
You use this trigger set up when you want to increase/decrease the graphic scale of a bunch of individual units. You use the unit attribute variable to allow you to isolate a single unit so that you can increase/decrease its graphic scale without getting it jumbled up with other units on the map.
VARIABLE DEFINITIONS:
x = the percentage amount you wish to increase/decrease the graphic scale of the unit(s) effected
y = the number of the player who owns/controls the unit(s)
(object 0) player y; class = (specified unit); min.=1; max.=1; has attribute unit variable 1 equal to min.=0, max.=0
(object 1) player y; class = (specified unit); min.=1; max.=1; has attribute unit variable 1 equal to min.=1, max.=1
(effect 0) unit attribute; (object 0); increase (unit variable 1) by 1
(effect 1) unit attribute; (object 1); increase/decrease (graphic scale) by x %
(effect 2) unit attribute; (object 1); increase (unit variable 1) by 1
(trigger 0)
starting state = ON
conditions true for = 3
looping? = yes
CONDITIONS = (object 0) exists
EFFECTS = (effect 0) with delay = 0; (effect 1) with delay = 1; (effect 2) with delay = 2
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
c)Limit the amount of a (specific class) unit/building a player can make:
DESCRIPTION:
If the specified player meets the maximum # of a unit/building you want to allow them to have, that unit/building is removed from their tech tree and they cannot build that unit/building until the # of the unit/building they own/control drops below the maximum # allowed.
VARIABLES DEFINITIONS:
y = the number of the player who owns/controls the unit(s)
x = the minimum number of the (specific class) of unit(s)/building(s) you want player y to have before they can no longer produce that (specific class) of unit(s)/building(s)
TRIGGER SYSTEM EXPLAINED:
When player y has reached the maximum number of the specific unit/building you want them to have, that unit/building is removed from their tech tree. Once player y no longer has the maximum number of the specific unit/building you want them to have, the unit/building is added to their tech tree again.
(object 0) player y; class = (specified unit/building); min. = x; max. = 99999;
(effect 0) modify technology tree of player y; remove (specific unit/building)
(effect 1) modify technology tree of player y; add (specific unit/building)
(effect 2) turn (trigger 0) ON
(effect 3) turn (trigger 1) ON
(trigger 0)
starting state = ON
conditions true for = NOT USED
looping? = no
CONDITIONS = (object 0) exists
EFFECTS = (effect 0) with delay = 0; (effect 3) with delay = 0
(trigger 1)
starting state = OFF
conditions true for = NOT USED
looping? = no
CONDITIONS = (object 0) does NOT exist
EFFECTS = (effect 1) with delay = 0; (effect 2) with delay = 0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
d)Displaying player kills in an object or as a resource:
DESCRIPTION:
This trigger system will display a player's kill total either as a resource on their resource bar (food, wood, stone, gold or iron) or as a resource in a building of theirs (any of the resources previously mentioned). This trigger system not only causes the resource being displayed to increase in either the resource bar or on the object you want, but it also decreasing the amount of this resource if a player tries to tribute to another player.
NOTE: When using this trigger system to display kills along with another trigger system for giving upgrades to units (if a player reaches a certain # of kills, then they get better units or stronger units) be sure to make the condition for determining how many kills each player has be player variable x that is used in this trigger system, NOT the resource. Players playing the scenarios cannot tamper with player variables.
VARIABLES DEFINITIONS:
x = the player variable you want to use
y = the player # that this trigger system is for (in multi player you will have this trigger system for each player - if you had six players in your scenario, you would have players y, z, a, b, c, d)
TRIGGER SYSTEM EXPLAINED:
First trigger:
When player y's (kills) is greater than player y's (player variable x), increase player y's (player variable x) by 1 *and increase (object 0)'s (resource type) by 1.
* only use the second effect described here if you are displaying player y's kills as a resource on one of their units.
Second trigger:
When player y's (resource type) is less than player y's (player variable x), increase player y's (resource type) by 1.
Third trigger:
When player y's (resource type) is greater than player y's (player variable x), decrease player y's (resource type) by 1.
(object 0) select the building you wish to display player y's kills on the map OR; player y; class = (specific building); min. = 1, max. = 1; *use area = (area 0)
*if there is more than 1 building with this class owned by player y on the map, you will have to specify the area in which the building you want affected to exist.
(condition 0) player y's kills is greater than player y's variable x
*(condition 1) player y's (resource type) is less than player y's player variable x
*(condition 2) player y's (resource type) is greater than player y's player variable x
*if using an object to display player y's kills, you do not need (condition 1) or (condition 2)
(effect 0) set attribute; player y; increase (player variable x) by 1
(effect 1) set attribute; player y; increase (resource type) by 1
*(effect 2) set attribute; player y; decrease (resource type) by 1
*(effect 3) class attribute; (object 0); increase (resource type) by 1
*if using an object to display player y's kills, you do not need to have (effect 2) and you must use (effect 3)
(trigger 0)
starting state = ON
conditions true for = NOT USED
looping? = yes
CONDITIONS = (condition 0)
EFFECTS = (effect 0) with delay = 0; *(effect 3) with delay = 0
*only add (effect 3) if you are using one of player y's objects to display player y's kills
(trigger 1) * use this trigger only if you are displaying player y's kills as one of player y's resources in their resource bar
starting state = ON
conditions true for = NOT USED
looping? = yes
CONDITIONS = (condition 1)
EFFECTS = (effect 1) with delay = 0
(trigger 2) * use this trigger only if you are displaying player y's kills as one of player y's resources in their resource bar
starting state = ON
conditions true for = NOT USED
looping? = yes
CONDITIONS = (condition 2)
EFFECTS = (effect 2) with delay = 0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
e)Giving units the appearance of having to reload their clip of ammunition:
You would use this trigger system to give units (like a marine for example) the appearance of having to reload their guns with a new clip of ammo.
I will be adding this as soon as I have time to make it (it is pretty complicated).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
f)Unit name change trigger:
<Object>
New object
Select object To be used in trigger (you can either select an object that already exists on the map or one that will exist when you want this trigger to be fired - you will want to use the has state/attribute/area options to better define what units/buildings you will want this object to refer to)
* Defining your objects well and understanding what this means is vital when you start having tons of units and buildings on the battlefield.
<effect>
New effect
Type Of Effect: Object
Action: Class Name
Object: the object you just created
Name: what you change name to
<trigger>
Create new trigger
If condition 0 is always true then <Class-Name <x> exists
-Thanks to pope4U for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
g)Creating an object when another object reaches an area:
<Area>
New area: <area 0>
Place a rectangular area on the map where you want the first object to go to create the new object (make sure the square area of the rectangle is large enough to allow all of the units created to exist)
* Note that when units are created using the create object effect, each unit created will take up an entire "tile" of land. If you don't give enough room for each unit you intend to create, then only the units that will fit will be created.
<Object>
New object: <object 0>
Select object that will move to area to create the new object. Check box that says "In Area" and select <area 0>.
New object: <object 1>
Specify the type of unit that is to be created in <area 0>.
<Effect>
New effect
Effect Type: Object
Create Object <object 1>
<Trigger>
New trigger
If <object 0> Exists Then Create <object 1>
-Thanks to pope4U for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
h)Spawning units:
Units spawn at a given area until a certain population is reached, when a certain number of the units has been destroyed new units will spawn creating an endless stream of reinforcements without lagging.
1. Create a spawning area ("area x").
2. Set the specs for the unit (for example: player x, marine, min 1, max 1, in "area x").
3. Create the conditions (for example player x's current pop>50, this will be "condition A" and another one with players 2's current pop<40, this will be "condition B").
Note: instead of current pop you can also use a "unit exists condition, you'll have to create an object with for example specs player x, marine, min 40, max 50 this is useful if you only have one type of reinforcements and don't want the number of other types of units to affect the spawning.
DO NOT use the "Army Size" condition, I think it's broken.
4. Create a "create object" effect use the unit you created in step 2.
5. Create a trigger using "always true" as condition and the "create object" effect and tackle looping, this will be "trigger A".
6. Create "trigger effect A" with trigger A off as effect.
7. Create "trigger effect B" with trigger A on as effect.
8. Create a trigger with "condition A" and
"trigger effect A" and tackle looping.
9. Create a trigger with "condition B" and
"trigger effect B" and tackle looping.
Now Marines will keep spawning until player x's population reaches 50, new marines will spawn when player x's population is back to less than 40.
-Thanks to Rameses for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
i)Infinite resources:
Let's say you want to give a player an infinite amount of wood. Here's how you do it.
1. Set player x's wood to 500000.
2. Create a condition with the following specs: player x's wood<10000, this will be "condition A".
3. Create an effect with the following specs: set player x's wood to EXACTLY 500000, this will be "effect A".
4. Create a trigger with "condition A" and "effect A" and set it and tackle "looping".
Now player x's wood stockpile will be filled everytime player x has less than 10000 wood.
Note: You can repeat this process for all resources or choose: any resource<10000 for "condition A" and set: all resources to EXACTLY 10000 for "effect A"
* I revised this trigger system to be more computer efficient (this way the triggers won't have to fire as often, and will be 100% lag free).
-Thanks to Rameses for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IV. CINEMATICS MADE EASYby VENOM_OZ_RICK
Start Cinematic/EndCinematic
Now when a cinematic starts the screen is shrunk to a letterbox format (it kinda looks like you're watching a DVD in widescreen format). When it's in cinematic mode you have no control over the game, but you can get out of cinematic mode by just presing "Esc". You can choose how fast you want the cinematic to play. There is a 1.6 at the right side of the Start Cinematic effect (that is the speed). This is the default speed you can take that down for the cinematic to run slower, or take it up for the cinematic to run faster. If you don't know where the "Start Cinematic" trigger is, then on the tigger screen go to Effects then should be a drop down menu that has "Object" on it go to that and select "Game" There you should find both the start cinematic and end cinematic effects. The End Cinematic effect just ends the cinematic when you want it to stop. There that's how to start the cinematic. Let's move on to the next step.
Placing Camera Markers
You can find these camera markers in the objects section (NOT in the trigger section). They are a world object and are under buildings. Placing camera markers is one way to plan out your shots. A camera marker defines a place for the camera to move to during the cinematic. Camera markers are what give you those great angles in cinematics. There is a ` button on your keyboard, that button is the rotate button; hold that and move the mouse (play with that for a while to see what you can do with it). Once you've got the hang of that, start placing your cameras. Move the camera until you are looking at the part of the map at the camera angle you want then Left click to place the camera marker anywhere on the map. What you see on the map is exactly what the camera will see when it moves to that marker (though you can alter the zoom level when you create the effect). The marker is placed in 3D space (if you zoom out a little, you can see the marker). Camera markers are only visible when you are in the scenario editor. You can use the camera marker in your object definitions like any other unit you place. Then, those objects can be used when you create a Script Camera Effect – see the Player section of Effects.
Script Camera
Now this is the brain of the cinematic, Using the Script Camera effect, you can create your own in-game movies. Specify the player(s) for whom the movie will play. Then set the following controls as you wish:
Move Camera - Select Use Area or Use Object and select any area or object that you have already defined. The camera moves to the specified object or area (for large areas, it moves to the center of the area). To “turn off” Move Camera for a given effect, choose Off Map for the area or Empty Object for the object. Do this to make the camera rotate in place instead of move.
Face Camera - Select Use Area or Use Object and select any area or object that you have already defined. The camera rotates to face the area or object specified. (Again, for large areas, the center of the area is the focal point.) To “turn off” Face Camera for a given effect, choose Off Map for the area or Empty Object for the object.
Follow - Check this box to have the camera follow the object specified under Move Camera. If the camera is both moving with an object and facing an area, you might want to check this box to ensure the camera can stay pointed towards the area while it is moving around with the object.
Track - If Track is checked, the camera continues to face the object specified under Face Camera even if the object moves.
Scroll Speed - Set the speed of the camera’s movement: Snap (i.e., the camera cuts immediately) or choose a number from 1 to 99. 99 is the slowest.
Zoom Level - Set the level of the zoom from -50 to 50, or choose “Current” to use whatever the current zoom level is for the player. 50 is a wide shot of the ground from high in the air, 0 is a ground-level close-up, and -50 looks up towards the sky from ground level. This is the same way the zoom (mouse wheel) functions when you are in the Scenario Editor.
TIP: Place Camera Markers in your scenario to set an exact view with the camera. A camera marker marks the view shown on your screen at the moment you place the marker. This allows you to set up a camera shot without using a defined object (e.g., a tree or building) or area as a reference point. See Placing Camera Markers in the Unit Placement Screen section, earlier in this chapter, for more information.
Media
I've seen alot of people having trouble with these so here is how you use them:
Play sound
Causes the specified sound file to play. The sound file must be in MP3 or .wav format and be saved in the ..\data\sounds directory under the Empire Earth root directory. Be sure to enter the extension of the file in addition to the file name. This effect could be used, for example, to give vocal directions or special audio cues.
Change Text
Changes the text entered on the Story/Instructions Screen (see the Story/Instructions Screen section earlier in this chapter). You can change the Hints, Instructions, and set the Loss and Victory text. You may either use Add Line to add your new text to the end of the old text, or select Clear to delete any specified text. Adding a line will automatically insert a carriage return for you, so the next line of text will appear on its own line.
Send Dialog
Lets you send a dialog message to the specified player(s). A dialog message appears in the top-center of the screen, as opposed to a chat message, which appears at the left just like in a regular game.
Object - Specify a defined object. The dialogue message will seem to come from the object. The portrait of the unit appears next to the message and the camera moves to look at it.
Player - Specify the player(s) to whom this dialog message is being sent.
File Name - You can specify an MP3 or a .wav file to play along with the dialog message. This could be a voice over of the message, for example.
Message - Type the dialog message in this field.
Camera Scroll Speed - Set the speed that the camera moves to the specified object. The camera automatically zooms in on the specified object, and follows the object if it moves. You can set the scroll speed to Off (the camera does not move to the object), Snap (the camera cuts to directly face the object), or a speed from 1 to 10, 10 being the fastest.
Duration in Seconds - This controls how long the message stays on the screen. If an audio file is specified, the dialog will stay on the screen for the time it takes to play the audio file plus the time specified here. If no file is given, the message remains on screen for the amount of time specified here. When any dialog completes, any sounds currently playing may be cut off.
Send Chat Message
Sends a chat message you provide to the specified players. The message appears in the chat area of the screen as opposed to the dialog area (the chat area is in the upper left area of the screen - right below the options icon).
Player – Specify the player(s) to whom this chat message is being sent.
Duration in Seconds – This controls how long the message stays on the screen.
Message – Type the chat message in this field.
That's it for Media. Moving on to the other parts of cinematics.
Fade In/Out
When a cinematic has this in it and also in the right places it makes it look a lot better. These two Player Effects allow you to fade in the screen from black or fade out to black for the specified players. They each last for about 3 seconds and function only in Cinematic Mode. To find these effects go to Effects then in the drop down menu select Player. Search through the list of Player Effects and you'll find them.
Visibility On/Off
These two effects allow you to turn on or off full map visibility for the specified player. This does not effect any “visible by” object states. You will find them where the Fade in/out effects are.
Include in Cinematic
Check this box if you want the trigger to be evaluated during Cinematic Mode. This is set OFF by default, meaning the trigger is evaluated only while the scenario is in progress and no cinematic is playing. See Start and End Cinematic Mode in the Effects section for more information.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
V. CINEMATIC TECHNIQUES
a)Having your camera circle an object:
This can give the feel of being in a plane flying around an object or area on the map. Nightstar (a forumer) used this technique to have the camera circle a wonder that was under construction.
The camera does not move in a curve between two camera markers, but in a straight line. So, to give the appearance that the camera is moving in a circle, you will have to place many camera markers around the object you want to circle. To make the transition from camera marker to camera marker as smooth as possible, you will need to check the spacing between the object being circled and the camera markers themselves (the distance between each camera marker and the object should be equal, or as equal as possible).
-Thanks to SSSI_Eggman for this one
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
VI. WHAT CAUSES EE TO CRASH DURING A SCENARIO
a)Spawning a transport unit with a resource on it. For example, if you try to spawn a helicopter transport on the map with 1 or more stone on it the game will crash. I am fairly certain that this is the case with ALL transport units (cargo trucks, helicopter transports, transport ships, etc).
b)Sending a dialog box with absolutely nothing in it (or just spaces) will cause the target player(s) computer(s) to freeze up.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TABLE OF CONTENTS
I.
a) How to save all of the triggers, conditions, effects, objects, and areas of a scenario into a text file
b) Opening the grid reference
c) Using the duplicate feature effectively
d) Having text appear as your cursor moves over an object
e) Messages that don't have a trigger
f) Having a submarine float at the surface of water
g) Having a helicopter appear to be landed
h) Changing an airplane's flight with triggers and a little terrain altering
i) Having plane(s) that fly and are still in your control even with 0 flight time
j) The quick sand trick
k) How to sculpt a pyramid
l) Having dead units remain on the ground where they died
m) Making units/buildings purple or black
n) Making units/buildings invisible
o) Underwater units/buildings
p) Units/buildings in space
q) Stretched buildings
r) Airport Tricks - Underground buildings, floating buildings, and other cool effects.
s) Ghosts
t) Teleporting units
u) Making units that the scenario editor can't place at anytime on demand
v) Red cliffs
w) Having multiple conditions all rolled into a single condition in a trigger (reduces lag)
x) Having rain fall on the entire map and having rain fall continuously
y) Detecting cheating using triggers in multi player scenarios
z) How triggers, conditions, effects, and objects can affect CPU performance in your scenarios
II.
a) Things that cause the scenario editor to crash
b) Little problems within the scenario editor
c) Special rules that you should follow to prevent problems in your scenarios
III.
a) Give all units of a (specific class) a (resource type) when produced
b) Graphically enlarge/shrink units of a (specific class) when created
c) Limit the amount of a (specific class) unit/building a player can make
d) Displaying player kills in an object or as a resource
e) Giving units the appearance of having to reload their clip of ammunition
f) Unit name change trigger
g) Creating an object when another object reaches an area
h) Spawning units
i) Infinite resources
IV.
V.
a) Having your camera circle an object
VI.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I. GENERAL SCENARIO DESIGN TECHNIQUES
a)
To do this, you have to hit one of the following key combinations using your keyboard while in the trigger section of the editor:
Try Ctrl-L or Ctrl-S
They will be saved somewhere in your Empire Earth directory (C:/Sierra/Empire Earth). This will create two files:
"Scenario Triggers.txt" and a "Scenario Triggers.scn"
This is useful for trigger debugging. You can print this .txt file so that while you're playing your scenario, you can read through your triggers to see what the problems might be.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
b)
Press T. To turn the grid reference off, press T 15 times. This is useful for distinguishing one map tile from another more easily.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
c)
The Duplicate feature is a lifesaver when it comes to cutting down on the time it takes to make a scenario. To optimize the effectiveness of this feature when using the editor, you always want to start with AREAS. What I mean by this is, always make the areas you want to use for your objects and effects first, before you make anything else. Once you’ve got your areas, make your OBJECTS. Then make your EFFECTS, then CONDITIONS, and so on. The order is simply right to left in the trigger area of your scenario editor. Now in case you don’t understand what I’m talking about I’ll give you a step by step walk through on how to use the duplicate feature effectively.
Step 1. Make six objects (usually in a multi player scenario you will have six objects for a specific class of object, 1 for each player, and have these objects be the targets of class name and class attribute effects).
Step 2. Make a single effect and target the first object.
Step 3. Duplicate the first effect and left-click the target object field and hit the down arrow once.
Step 4. Duplicate the second effect and do the same thing.
Step 5. Continue to Duplicate and scroll down the object until you have six effects that each target one of the objects.
Step 6. Typically you will use some kind of object as your condition in triggers, so we will assume that you are using the six objects as your conditions here. Create a trigger and make the first object its condition and the first effect its effect. You’ve got a trigger that says that when the first object exists the first effect will be fired.
Step 7. Duplicate the first trigger and then left-click the first condition field and press the down arrow. Then left-click the first effect field and press the down arrow. You’ve got your second trigger! Repeat until you’ve got six triggers that use the six objects and effects.
Now that you know how to use the Duplicate feature effectively, you can produce your scenarios in a lot less time.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
d)
Use the class name effect to change the name of the object and put a space before the new name.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
e)
1. Delay this trigger---effect>
2. Save the game on the second that the dialogue should be sent-
3. Load the save
4. Delete the trigger
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
f)
Place a submarine in water, then double click it and move it somewhere else in the water. Now it will be above the surface of the water.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
g)
There are several ways to accomplish this.
1. Place a helicopter somewhere on the map and then raise the elevation of the land under the helicopter until the helicopter appears to be resting on the ground, then bring the elevation back to zero.
2. Place a helicopter somewhere on the map and then place an AA gun underneath of it. Now remove the AA gun.
3. Using the "snap rotate" effect you can have a helicopter snap to the ground. This technique is used while a scenario is running.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
h)
You place an airport under water, then the plane will actually stay on the surface (they won't dive down). They disappear when they are vertically above the hangar. This is best used in cinematic mode for maybe a plane that is about to crash, or just to have it moving close to the surface and then rising again. You remove the airport and it will rise up to normal altitude again, and maybe then go to another nearby underwater airport if you want to repeat the animation. You can also hide the airports if needed by making it invisible.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
i)
1. Place plane(s) on map
2. Task object plane to area (not off map) (delay = 0 seconds)
3. Set unit attribute (flight time) of object plane to exactly 5 (delay = 0 seconds)
4. Time warp object plane (delay = 2 seconds)
5. Change owner of object plane to same player (delay = 88 seconds)*
* Note that the time between the time warp effect on the object and the change owner effect on the object must be 86 seconds exactly, because this is the time that a time warp effect takes.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
j)
You place some mechanic unit (it works better this way) on the ground. You transform the grass into sand. You place a cliff with the border on the place where the units are. You click and they'll look like they're getting buried by sand.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
k)
Pyramids are the perfect eye candy for desert maps and they usually impress reviewers.
1. Create a plateau with the desired height, make sure the plateau's size is at least 5x5 tiles.
2. Choose the size of the summit at the center of the plateau (1x1, 2x2,...) and mark this area with impassible tiles.
3. Place lines of minarets on each side of the marked area (same number of minarets on each side), so you get a cross like shape with the summit of the pyramid in the center, the shorter your lines of minarets are, the steeper the slope of the pyramid will be.
4. Change the ground level to 0 around the perimeter of the cross, mark this perimeter with impassible tiles, now make a square with ground level 0 around the cross: you have now sculped the basic shape of a pyramid.
5. Remove the minarets and any hills that are left surrounding the pyramid.
6. Add the finishing touch by changing the pyramids surface (I prefer light colored marble tiles.
You may also want to add a layer of sand that is different from that of the rest of the map around the perimeter of the pyramid.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
l)
To have a dead unit remain on the ground forever, simply use the class attribute effect to give the unit a resource before it dies (food, wood, stone, gold, or iron will work). Once the unit dies, its corpse will remain on the ground until a citizen harvests the resources from it.
This can add some realism to a scenario as bodies do take a long time to decompose. Also, you could have citizens appear to be looting the corpses of fallen soldiers.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
m)
Change ownership of a unit 1 second after it is teleported (use teleport graphic effect) to be black, 2 seconds after to be purple.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
n)
Reduce the graphic scale of the units/buildings you want to be invisible by 100%.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
o)
Place units/buildings on above water terrain, then lower the elevation under the units/buildings until they are under water.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
p)
Place units/buildings on normal land then change terrain to space under them.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
q)
1. Make cit for human, 2. player page change to the epoch of building you want
2. Test
3. Place the foundation for the building and build it a bit
4. Save
5. Load
6. Change owner of object -stretcho building, to whoever you want to own it
7. Test
8. Save
9. Load
10. Unit attribute object el stretcho building, hit points increase by 100%
11. Test
12. Save when the building is tall enough to your likings, if you make it too big just the foundations will be seen, and you cant click on it- good for making building sites
13. Load the save
* To make the building thinner, add the trigger, graphic scale reduce by x% (40% is usually a good amount)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
r)
By placing airports on the map (in a certain way) using triggers, you can raise/lower elevation of the 2x6 tile area that the runway of the airport takes up.
Here's how you do it:
Create an area for the airport that is 2x2 tiles, that are the exact same elevation, and are either above or below the surronding tiles. The airport hanger section is what is created in the 2x2 area, the 2x6 runway section is the area that is either raised or lowered. As long as the 2x2 area is not below 0(zero) elevation, or next to the edge of a cliff, it will create the airport.
However, for the time being, the DIRECTION of the airport created by triggers, cannot be controlled. Except if it is created on top of the runway of another airport(then I believe it creates the same direction as the existing airport it is created on. Airport runways create underneath just about every object that can be placed on a map, so i dont know what else yet that can control the direction in which it made.
You will probably want to have the airports be invisible when created. To do this simply add this to the objects of the airports you create for this technique:
Has attribute... graphic scale min=0, max=0
Some good uses:
- Impassible water can be removed, on command, without revealing the presence of the airport, to say, for example, make a magical bridge
- The effect causes a sharp cliff-less terrain/wall face that is passable to units.
- The entire runway of an airport can be created underneath other buildings and objects such as perhaps trees (haven't tested it on anything other than buildings). This can make planes appear to go through buildings or land in trees or what not.
- When saved during play the "cliff-less" wall faces have cliff faces upon replaying(this can be used to let triggers know if a game has been saved or is being played from the beginning, or at a certain point in the game).
- Cliff-less walls can be made over most or all of a building, then saved in play. When that same game is opened in the map editor, the building will appear to be built inside a cliff.
- Units might be put inside cliffs and attack or use their power from inside the cliff (*needs confirmation).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
s)
1. Object graphic scale 0%
2. Object graphic effect fireball
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
t)
1. Task object in area Y to off map
2. Task object off map to area X
This way you do not lose your team.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
u)
1. Make the object... say a nuke (place missile base an give the resources~~ make it a target and fire
2. Save the game
3. Load the save
4. Object>
5. Object>
6. Say how many you want of it in area or
7. Create object ~the specification one
there ya go units on demand that cant be made in the scen editor
You could use this for projectiles, missiles, etc. (anything you cant make by normal methods in the scenario editor). This is also used for calamities you don't want to see the effect of (volcano with only the flames-no mountain).
Here's another way to do this:
1. Create a trigger that loops and uses an area effect calamity (time warp) that uses a certain area on the map. Set the condition of this trigger to be always true.
2. Have a nuclear sub or missile silo launch missiles that will travel across the area affected by the effect calamity. Missiles or any other projectiles will warp out while passing through the area, and appear lying on the ground later (and stay there).
A scenario can be setup so the projectiles are laid in position first, then saved, then used at the beginning of the scenario for eye candy.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
v)
Using the following random map script, you can access red cliffs in the scenario editor:
Using a winter map you can access gray cliffs. The different color cliffs are not a mod to EE. The Sahara script simply unlocks the red cliffs in a scenario, and then the cliff type is saved as part of the scenario.
The red cliffs would be really good for a scenario on Mars for example, or any other time where they suit the scenario more than the normal cliffs.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
w)
The idea behind this is to cut down on lag.
1. Object - Unit has attribute A
2. Object - "Use object" (the above unit) and has attribute B
3. Object - "Use object" (the above unit) and has attribute C
4. Object - "Use object" (the above unit) and has attribute D
5. Object - "Use object" (the above unit) and has attribute E
6. Condition = Object from step 5 exists.
For effects (if for that unit) - use object from step 1.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
x)
1. Make area (select continent tile) - 1 tile should be the indicator for this type of area
2. Effect >
3. Make a trigger that has condition of always true and uses the effect you just created.
Copy this trigger multiple times to make it rain harder.
To have it rain continuously, you need to make two triggers exactly the same as the one above. One of these will fire only once (so it will NOT have the looping box checked) and will have a second effect. This second effect will be a trigger effect that turns the second trigger ON. The second trigger will have starting state of OFF and will have the looping box checked. Lastly, the second trigger will have conditions true for about 2 minutes and 4 seconds (124 seconds).
To have it rain harder and rain continuously, you will need to make multiple sets of both of these triggers.
Please note that rain does cause lag if not every player in the scenario has a high performance CPU. I personally recommend adding triggers that let the player(s) playing your scenario turn the rain causing triggers on and off using chat commands. Of course, players with low system specifications can disable the rain in just their game by lowering their graphic level in the options menu. Having the option to turn off the rain causing triggers allows the host of a scenario (if multi player scenario) the option to reduce lag. Not everyone is familiar with the graphic options in EE.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
y)
I realize that cheating isn't that common these days in multi player scenarios, but just to be on the safe side you can use the following techniques to prevent cheaters from ruining one of your games. Cheaters use programs called trainers to access the cheats in EE (the two primary cheats they use are "Asus Drivers" and "my name is methos").
Asus drivers reveals the entire map and my name is methos reveals the map and gives 100,000 of each resource.
Since the "chat contains text" condition does not work in multi player scenarios, some other ways are needed.
Both of these cheats involve revealing the entire map to the player who uses them.... Which is a difficult thing to detect... Since object condition "visible by player x" only applies to units near that object(not seen by the player).
The solution.... missile silos...
As far as I know, missile silos tasked to an object are the only thing that will attack another object automatically once that object becomes visible via "visibility on", without being in its own line-of-sight.
So...to detect if someone has used asus drivers or my name is methos...
1. Place a missile silos somewhere on the map (one per human player).
2. Reduce the LOS (class attribute) for all of the human players' missile silos to 0.
3. Reduce graphic scale for the missile silos to invisible (0% graphic scale makes them invisible).
4. Reduce attack for the missile silos to 1 (missile silos won't fire if their attack is 0).
5. Loop a trigger that has condition always true, and effect task missile silo to a world object that is attackable (a statue for example). I suggest making one trigger per human player in the scenario (so that you can turn off the trigger corresponding to their missile silo in the event that they are kicked out of the scenario for cheating).
6. Make a trigger for each human players' missile silo with the condition being an object... select on map the missile silo, does NOT have state "idle"... and with effect defeat player x (the cheater), and object effect... remove missile silo for player x, and trigger effect turn off looping trigger that you made in step 5 for player x.
This means that if player x uses asus drivers, player x's missile silo will start to attack the statue that player x's missile silo is tasked to by the trigger from step 5, and that missile silo will no longer be idle. Therefore meeting condition "missile silo NOT idle exists", firing the trigger for player x you made in step 6.
You may want to include a media effect in the triggers in step 6 that sends a chat message to everyone explaining that player x tried to cheat.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
z)
You're correct in assuming that triggers in and of themselves don't affect performance. I've yet to notice any significant performance changes from having 5, 50, or 500 Triggers.
For taking up CPU time, there is no difference between a looping and non-looping trigger. They both have to be checked every second to see if they should fire. The difference comes after they fire- the non-looping trigger will get turned "Off", so the game will stop checking it. A performance problem that does result from loops is in loops which come out as "True" every second, meaning that the game is constantly performing your effects. If these effects deal with large amounts of units, you'll get some slowdown.
You will also get a noticeable lag if you have conditions and effects that deal with large numbers of units. For example, a condition such as "Player 1 Unit HP = 50 Exists" will be much more performance friendly if player 1 only has 5 units, than it will be if they have 500. Also, quantities matter. A condition (or effect) looking for 50 units with 50 HPs will run slower than one that only needs to find 1. To see an example of this, play the ultimate scenario in the Russian campaign (Change of Heart). After the cinematic sequence where Molotov defects to the US, I basically have a "Give All Player 1 Units to Player 2" trigger and a "Give All Player 2 Units to Player 1" trigger. The slowdown while these execute is very noticeable on my 750MHz, so much so that I moved the last bits of dialog to happen after the cinematic was over, to distract the player from watching the game chug. So, my tips on trigger optimizing are as follows:
Make sure that conditions which involve checking large amount of units are evaluated only when needed. In other words, the trigger dealing with the 500 man Prussian army should not be "On" if the Prussians aren't going to be needed yet.
Make sure that any condition or effect has objects which can be quickly checked. In these cases, "select on map" objects are much better than "object specification" ones, since the game already knows what to look at. In most cases you may not be able to find a way to simplify your specified objects, but it's something to check out.
Don't allow loops to execute every second if they deal with creating, removing, killing, or converting large numbers of units, or if they have conditions that involve large amounts of units.
Reduce the amount of units on the map. This may be the only way to improve performance if you're sure your triggers are to blame, but by the same token large numbers of units will create lag for other reasons, so it's always best to use as little as you can get away with.
My last piece of advice, though, is to not worry about it at all, unless you're sure you are noticing some lag. If it ain't broke, don't fix it.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
II. BUGS WITHIN THE SCENARIO EDITOR
a)
1. Hitting the up arrow in the trigger state effect when you’ve already got ON selected (Art of Conquest only)
2. Sometimes when "painting" the map with terrain the game will crash. Make sure you save often when making map modifications. Usually happens when painting with a large brush.
3. Sometimes when you've had EE:AoC open for a long time and switch from the effects portion to the objects portion in the trigger area of the scenario editor, the program will crash to your desktop. This has occurred when I have been editing my scenarios that have a lot of objects and effects (over 2000 effects and 2000 objects). This probably has to do with RAM usage, but I'm not entirely sure (I have just under 800mb of RAM).
b)
1. If you’ve got cliffs in your map and you try to use the "paint hills" tool, the cliffs will be severely distorted if you accidentally try to paint the hills near them. If you mess up your cliffs in this manner, you will most likely have to open up a previous version of the scenario you’re working on to "undo" the mistake. Saving often will lesson the time it takes to make terrain detailing with painting hills near cliffs.
2. In EE:AoC and EE, you cannot use an object that has one moveable object near/in LOS of/in range of another movable object as a condition in a trigger or as the target of an object effect, unless one of the movable objects is in an area.
3. When tasking (attack-move) a movable object to an object that is not attackable (a tree for example), the object you're tasking becomes stuck on the non attackable object.
4. If there are too many words in a dialog box, during the game, it will not go away until you press ESC.
c)
1. Unit attributes and class attributes cannot be "fired" at the same time within the same trigger.
2. Whenever you use sound in the editor, you need to realize that Empire Earth is not capable of keeping track of every sound file you’ve got playing at one time. This means that once you play a sound file, it will continue playing until it either finishes or is interrupted and stopped by beginning cinematic mode. You cannot resume a music track from where you stopped it using the start cinematic mode effect.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
III. EXAMPLE TRIGGERS/TRIGGER SYSTEMS
a)
DESCRIPTION:
This trigger gives/takes away a certain amount of a resource to/from a unit after the unit is spawned somewhere on the map or created by the player at a building. For example, you would use this type of trigger set up if you wanted every long swordsman player 1 makes to have 30 gold.
TRIGGER EXPLAINED:
You use this trigger set up when you want to give/take away a certain amount of a resource to/from a bunch of individual units. You use the unit attribute variable to allow you to isolate a single unit so that you can give/take away a certain amount of a resource to/from it without getting it jumbled up with other units on the map. The extra stuff in this trigger prevents some units from getting too much of the resource and others not getting any.
VARIABLE DEFINITIONS:
x = the amount of the specific resource to give/take from the unit(s) effected
y = the number of the player who owns/controls the unit(s)
(object 0) player y; class = (specified unit); min. = 1; max. = 1; has attribute unit variable 1 equal to min. = 0, max. = 0
(object 1) player y; class = (specified unit); min. = 1; max.=1; has attribute unit variable 1 equal to min.=1, max.=1
(effect 0) unit attribute; (object 0); increase (unit variable 1) by 1
(effect 1) unit attribute; (object 1); increase/decrease (resource type) by x
(effect 2) unit attribute; (object 1); increase (unit variable 1) by 1
(trigger 0)
starting state = ON
conditions true for = 3
looping? = yes
CONDITIONS = (object 0) exists
EFFECTS = (effect 0) with delay = 0; (effect 1) with delay = 1; (effect 2) with delay = 2
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
b)
* This is the most efficient way to do this. Much better than looping a single trigger that continuously sets the graphic scale to an exact # for all units on the map within the parameters of the object affected.
DESCRIPTION:
This trigger graphically enlarges or shrinks a unit once it is spawned somewhere on the map or created by the player at a building. For example, you would use this trigger if you wanted all of the units that player 1 produces to be graphically enlarged or shrunk.
TRIGGER EXPLAINED:
You use this trigger set up when you want to increase/decrease the graphic scale of a bunch of individual units. You use the unit attribute variable to allow you to isolate a single unit so that you can increase/decrease its graphic scale without getting it jumbled up with other units on the map.
VARIABLE DEFINITIONS:
x = the percentage amount you wish to increase/decrease the graphic scale of the unit(s) effected
y = the number of the player who owns/controls the unit(s)
(object 0) player y; class = (specified unit); min.=1; max.=1; has attribute unit variable 1 equal to min.=0, max.=0
(object 1) player y; class = (specified unit); min.=1; max.=1; has attribute unit variable 1 equal to min.=1, max.=1
(effect 0) unit attribute; (object 0); increase (unit variable 1) by 1
(effect 1) unit attribute; (object 1); increase/decrease (graphic scale) by x %
(effect 2) unit attribute; (object 1); increase (unit variable 1) by 1
(trigger 0)
starting state = ON
conditions true for = 3
looping? = yes
CONDITIONS = (object 0) exists
EFFECTS = (effect 0) with delay = 0; (effect 1) with delay = 1; (effect 2) with delay = 2
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
c)
DESCRIPTION:
If the specified player meets the maximum # of a unit/building you want to allow them to have, that unit/building is removed from their tech tree and they cannot build that unit/building until the # of the unit/building they own/control drops below the maximum # allowed.
VARIABLES DEFINITIONS:
y = the number of the player who owns/controls the unit(s)
x = the minimum number of the (specific class) of unit(s)/building(s) you want player y to have before they can no longer produce that (specific class) of unit(s)/building(s)
TRIGGER SYSTEM EXPLAINED:
When player y has reached the maximum number of the specific unit/building you want them to have, that unit/building is removed from their tech tree. Once player y no longer has the maximum number of the specific unit/building you want them to have, the unit/building is added to their tech tree again.
(object 0) player y; class = (specified unit/building); min. = x; max. = 99999;
(effect 0) modify technology tree of player y; remove (specific unit/building)
(effect 1) modify technology tree of player y; add (specific unit/building)
(effect 2) turn (trigger 0) ON
(effect 3) turn (trigger 1) ON
(trigger 0)
starting state = ON
conditions true for = NOT USED
looping? = no
CONDITIONS = (object 0) exists
EFFECTS = (effect 0) with delay = 0; (effect 3) with delay = 0
(trigger 1)
starting state = OFF
conditions true for = NOT USED
looping? = no
CONDITIONS = (object 0) does NOT exist
EFFECTS = (effect 1) with delay = 0; (effect 2) with delay = 0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
d)
DESCRIPTION:
This trigger system will display a player's kill total either as a resource on their resource bar (food, wood, stone, gold or iron) or as a resource in a building of theirs (any of the resources previously mentioned). This trigger system not only causes the resource being displayed to increase in either the resource bar or on the object you want, but it also decreasing the amount of this resource if a player tries to tribute to another player.
NOTE: When using this trigger system to display kills along with another trigger system for giving upgrades to units (if a player reaches a certain # of kills, then they get better units or stronger units) be sure to make the condition for determining how many kills each player has be player variable x that is used in this trigger system, NOT the resource. Players playing the scenarios cannot tamper with player variables.
VARIABLES DEFINITIONS:
x = the player variable you want to use
y = the player # that this trigger system is for (in multi player you will have this trigger system for each player - if you had six players in your scenario, you would have players y, z, a, b, c, d)
TRIGGER SYSTEM EXPLAINED:
First trigger:
When player y's (kills) is greater than player y's (player variable x), increase player y's (player variable x) by 1 *and increase (object 0)'s (resource type) by 1.
* only use the second effect described here if you are displaying player y's kills as a resource on one of their units.
Second trigger:
When player y's (resource type) is less than player y's (player variable x), increase player y's (resource type) by 1.
Third trigger:
When player y's (resource type) is greater than player y's (player variable x), decrease player y's (resource type) by 1.
(object 0) select the building you wish to display player y's kills on the map OR; player y; class = (specific building); min. = 1, max. = 1; *use area = (area 0)
*if there is more than 1 building with this class owned by player y on the map, you will have to specify the area in which the building you want affected to exist.
(condition 0) player y's kills is greater than player y's variable x
*(condition 1) player y's (resource type) is less than player y's player variable x
*(condition 2) player y's (resource type) is greater than player y's player variable x
*if using an object to display player y's kills, you do not need (condition 1) or (condition 2)
(effect 0) set attribute; player y; increase (player variable x) by 1
(effect 1) set attribute; player y; increase (resource type) by 1
*(effect 2) set attribute; player y; decrease (resource type) by 1
*(effect 3) class attribute; (object 0); increase (resource type) by 1
*if using an object to display player y's kills, you do not need to have (effect 2) and you must use (effect 3)
(trigger 0)
starting state = ON
conditions true for = NOT USED
looping? = yes
CONDITIONS = (condition 0)
EFFECTS = (effect 0) with delay = 0; *(effect 3) with delay = 0
*only add (effect 3) if you are using one of player y's objects to display player y's kills
(trigger 1) * use this trigger only if you are displaying player y's kills as one of player y's resources in their resource bar
starting state = ON
conditions true for = NOT USED
looping? = yes
CONDITIONS = (condition 1)
EFFECTS = (effect 1) with delay = 0
(trigger 2) * use this trigger only if you are displaying player y's kills as one of player y's resources in their resource bar
starting state = ON
conditions true for = NOT USED
looping? = yes
CONDITIONS = (condition 2)
EFFECTS = (effect 2) with delay = 0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
e)
You would use this trigger system to give units (like a marine for example) the appearance of having to reload their guns with a new clip of ammo.
I will be adding this as soon as I have time to make it (it is pretty complicated).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
f)
<
New object
Select object To be used in trigger (you can either select an object that already exists on the map or one that will exist when you want this trigger to be fired - you will want to use the has state/attribute/area options to better define what units/buildings you will want this object to refer to)
* Defining your objects well and understanding what this means is vital when you start having tons of units and buildings on the battlefield.
<
New effect
Type Of Effect: Object
Action: Class Name
Object: the object you just created
Name: what you change name to
<
Create new trigger
If condition 0 is always true then <
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
g)
<
New area: <
Place a rectangular area on the map where you want the first object to go to create the new object (make sure the square area of the rectangle is large enough to allow all of the units created to exist)
* Note that when units are created using the create object effect, each unit created will take up an entire "tile" of land. If you don't give enough room for each unit you intend to create, then only the units that will fit will be created.
<
New object: <
Select object that will move to area to create the new object. Check box that says "In Area" and select <
New object: <
Specify the type of unit that is to be created in <
<
New effect
Effect Type: Object
Create Object <
<
New trigger
If <
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
h)
Units spawn at a given area until a certain population is reached, when a certain number of the units has been destroyed new units will spawn creating an endless stream of reinforcements without lagging.
1. Create a spawning area ("area x").
2. Set the specs for the unit (for example: player x, marine, min 1, max 1, in "area x").
3. Create the conditions (for example player x's current pop>
Note: instead of current pop you can also use a "unit exists condition, you'll have to create an object with for example specs player x, marine, min 40, max 50 this is useful if you only have one type of reinforcements and don't want the number of other types of units to affect the spawning.
DO NOT use the "Army Size" condition, I think it's broken.
4. Create a "create object" effect use the unit you created in step 2.
5. Create a trigger using "always true" as condition and the "create object" effect and tackle looping, this will be "trigger A".
6. Create "trigger effect A" with trigger A off as effect.
7. Create "trigger effect B" with trigger A on as effect.
8. Create a trigger with "condition A" and
"trigger effect A" and tackle looping.
9. Create a trigger with "condition B" and
"trigger effect B" and tackle looping.
Now Marines will keep spawning until player x's population reaches 50, new marines will spawn when player x's population is back to less than 40.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
i)
Let's say you want to give a player an infinite amount of wood. Here's how you do it.
1. Set player x's wood to 500000.
2. Create a condition with the following specs: player x's wood<
3. Create an effect with the following specs: set player x's wood to EXACTLY 500000, this will be "effect A".
4. Create a trigger with "condition A" and "effect A" and set it and tackle "looping".
Now player x's wood stockpile will be filled everytime player x has less than 10000 wood.
Note: You can repeat this process for all resources or choose: any resource<
* I revised this trigger system to be more computer efficient (this way the triggers won't have to fire as often, and will be 100% lag free).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IV. CINEMATICS MADE EASY
Now when a cinematic starts the screen is shrunk to a letterbox format (it kinda looks like you're watching a DVD in widescreen format). When it's in cinematic mode you have no control over the game, but you can get out of cinematic mode by just presing "Esc". You can choose how fast you want the cinematic to play. There is a 1.6 at the right side of the Start Cinematic effect (that is the speed). This is the default speed you can take that down for the cinematic to run slower, or take it up for the cinematic to run faster. If you don't know where the "Start Cinematic" trigger is, then on the tigger screen go to Effects then should be a drop down menu that has "Object" on it go to that and select "Game" There you should find both the start cinematic and end cinematic effects. The End Cinematic effect just ends the cinematic when you want it to stop. There that's how to start the cinematic. Let's move on to the next step.
You can find these camera markers in the objects section (
Now this is the brain of the cinematic, Using the Script Camera effect, you can create your own in-game movies. Specify the player(s) for whom the movie will play. Then set the following controls as you wish:
TIP: Place Camera Markers in your scenario to set an exact view with the camera. A camera marker marks the view shown on your screen at the moment you place the marker. This allows you to set up a camera shot without using a defined object (e.g., a tree or building) or area as a reference point. See Placing Camera Markers in the Unit Placement Screen section, earlier in this chapter, for more information.
I've seen alot of people having trouble with these so here is how you use them:
Causes the specified sound file to play. The sound file must be in MP3 or .wav format and be saved in the ..\data\sounds directory under the Empire Earth root directory. Be sure to enter the extension of the file in addition to the file name. This effect could be used, for example, to give vocal directions or special audio cues.
Changes the text entered on the Story/Instructions Screen (see the Story/Instructions Screen section earlier in this chapter). You can change the Hints, Instructions, and set the Loss and Victory text. You may either use Add Line to add your new text to the end of the old text, or select Clear to delete any specified text. Adding a line will automatically insert a carriage return for you, so the next line of text will appear on its own line.
Lets you send a dialog message to the specified player(s). A dialog message appears in the top-center of the screen, as opposed to a chat message, which appears at the left just like in a regular game.
Sends a chat message you provide to the specified players. The message appears in the chat area of the screen as opposed to the dialog area (the chat area is in the upper left area of the screen - right below the options icon).
That's it for Media. Moving on to the other parts of cinematics.
When a cinematic has this in it and also in the right places it makes it look a lot better. These two Player Effects allow you to fade in the screen from black or fade out to black for the specified players. They each last for about 3 seconds and function only in Cinematic Mode. To find these effects go to Effects then in the drop down menu select Player. Search through the list of Player Effects and you'll find them.
These two effects allow you to turn on or off full map visibility for the specified player. This does not effect any “visible by” object states. You will find them where the Fade in/out effects are.
Check this box if you want the trigger to be evaluated during Cinematic Mode. This is set OFF by default, meaning the trigger is evaluated only while the scenario is in progress and no cinematic is playing. See Start and End Cinematic Mode in the Effects section for more information.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
V. CINEMATIC TECHNIQUES
a)
This can give the feel of being in a plane flying around an object or area on the map. Nightstar (a forumer) used this technique to have the camera circle a wonder that was under construction.
The camera does not move in a curve between two camera markers, but in a straight line. So, to give the appearance that the camera is moving in a circle, you will have to place many camera markers around the object you want to circle. To make the transition from camera marker to camera marker as smooth as possible, you will need to check the spacing between the object being circled and the camera markers themselves (the distance between each camera marker and the object should be equal, or as equal as possible).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
VI. WHAT CAUSES EE TO CRASH DURING A SCENARIO
a)
b)
[This message has been edited by penguini_1 (edited 12-31-2007 @ 03:25 PM).]