Hi gang!

The Eden editor is by far one of my favorite features in Arma 3. Not only because it allows you to create (and play with..) your own stuff, it's also because you can actually give your missions the same look and feel as any other official missions (or rather: scenarios).

Every scenario relies on so called briefings: an overview which tells you about the mission and its optional background story, it gives you a quick recap of the things ahead and tells you which steps you need to take ("execute") in order to successfully complete the mission. Here's the official briefing of the 'Drones' showcase scenario, which is one of my personal favorites:



Now compare the picture above to this one:



This is the briefing of my custom scenario. Sure, it's a lot smaller because there's less you have to do, but the presentation itself is completely the same. Several tasks, some tasks clearly show you the location where you need to go and of course the map has several markers to make it easier to find every important location.


In my previous guide I made this very simple mission where you and a guardsman were located in Camp Maxwell (on Stratis) and during your visit you get attacked by a squad coming in from the south.

Because 8 against 2 isn't exactly a fair fight I also provided Zeus support so that you can dynamically call for reinforcements to experiment a bit and see what happens in different situations.

Well, today we're going to fix all that unfairness. Not only are we going to even the odds a bit but also make the whole thing look and behave more official by adding a briefing, several tasks for the player to complete and of course a nice(r?) ending.


Although the pictures in this guide will clearly show you what I'm doing (or have done) you may spot some inconsistencies here and there. For example you may see some icons (tasks and triggers and such) even before I mentioned them and explained how (and why) to add these.

What can I say... When I work with Eden my imagination usually gets the better of me, especially when I'm in a creative mood, and then I often can't stop building. Worse yet I sometimes even forgot that I was actually working on a tutorial so I also forget to snap pictures ;)

Therefor some of these screenshots were taken afterwards. Probably not really noticeable but I figured I'd warn you guys anyway because with Arma 3 details matter.

In case you didn't read my previous guide (yet?) here's a quick recap of what I did...

• I placed a commanding unit (who's actually a Major) on a building, this is the player character.
  
• Provided a weapons crate and also added the Zeus gamemaster module (so that you can dynamically control the mission).
  
• Added a rifleman ("guardsman") on the ground and set up a (looping) set of waypoints so that he's constantly patrolling the area.
  
• Added an OPFOR (= hostile) APC and placed it near the road.
  
• Added a (well armored) OPFOR attack squad and directed them into the camp using waypoints.
  
• Set up a trigger which checks for the disappearance of the APC; if satisfied it completes the mission.

Simple and very straightforward, right?

See, the intention wasn't so much to build an appealing scenario; the idea was merely to make a simple mission which we could use to provide a bit of a challenge and it would allow us to experiment with the AI behavior with the help of Zeus.

But no more! Now it's time to make things a little bit more realistic.

So before I continued working on this I first cleaned up the mission by removing the end game trigger (you can also see this in the map above; the blue circle?). In the new setup we're going to use other methods to determine if the mission got completed or not.

The next problem is the fact that the game is highly unbalanced; 2 against 8.



Every military figure which you add in Eden will form it's own squad, this is also why you can see that the allied forces consisted of 2 squads in my game: the player character and the guardsman. Or why the APC which I added formed a squad on its own: that happened because of the troops inside.

Fortunately it's very easy to further customize these squads if you want to. First there's the 'Entities' menu on the left: this gives you an overview of everything you added to your missions, including all the different squads. So if you want to get rid of a squad member then you can simply select them in the menu (or on the map itself) and press delete, or you right click and select the 'Edit -> Delete' option.

Adding squad members is also very easy: just add a figure as you normally would but when placing it on the map make sure to stay close to the squad leader. This will automatically add that figure to the squad.

So as you can see above I first started to re-enforce my guardsman squad by adding three other members: a grenadier, a heavy gunner and a marksman. This should even the odds just a bit better.



Next I also upgraded the "command squad" and gave myself 2 extra team members: an officer and a crewman (somebody has got to get us some coffee ;)). As you can see I marked these two playable to keep the possibility of multiplayer in mind.


Because we're eventually going to take on an APC I figured I'd also add some extra weapon crates so that the player can exchange their weapon(s) when needed. And because this should be an open world approach I simply added several weapon types so that the player can chose their strategy for neutralizing the APC, so I added a grenade box, a launcher box and an explosives box.

The idea is to make sure that we're not somehow guiding the player by telling them what to do or which weapon(s) to use. I'm hoping that some players might even make some mistakes which could then eventually lead up to...



Here I decided to use a Titan MPRL to take out the APC. Although the range of 200m should be easy enough for the weapon to reach I forgot about the fact that I was on a hill and that the elevation difference would cause a problem. So I fired a rocket anyway, completely missed the (now alerted) target who then immediately opened fire on me and my squad.

And I had nothing else to blame but my own flawed strategy, auch! ;)

So now that we have our defensive forces on full strength it's now time to focus on the gameplay. We're going to add some tasks to guide the player towards the guard tower and alert them of the imminent attack. But first...




Well, just what the name implies; thing(s) which the player needs to do in order to successfully complete the scenario. You can think of tasks as individual missions which, when linked or grouped together, make up for the whole scenario.

So the first thing you want to do with a new scenario is to try and split it up in easier to manage steps where the amount you want to use obviously depends on the type of mission. In my example I decided that he player needs to go through three main tasks...

1) Climb the guard tower

The moment when you start playing the mission is also the time when the enemy troops begin to make their way towards the camp. Sooner or later they will reach it and when they do they'll shoot anyone there. So I want to start by alerting the player to this, but only after he's in the right position to spot the enemy. Which is at the southern guard tower.

As such task number one: climb the tower.

2) Defend the camp!

When he is at the tower then HQ will inform him that they spotted hostile targets coming in from the south end and that his new mission is to defend the camp at all costs!

3) Neutralize remaining forces

The enemy forces consist of 2 squads: first there's the group of infantry that's invading the camp but there's also an APC parked on the south road which the player also needs to take care off.


In my scenario we have a specific sequence of tasks which the player needs to carry out in order to complete the mission, as seen above. Easily doable, but do keep in mind that this isn't the only way you can work with tasks!

See, tasks have specific 'states' to them; when you create a task then it's just that: 'created' which means that it becomes available to the player. If a player accepts a certain task (this is often automatically done for them) then the task gets a new state: it becomes assigned. An assigned task means that it's specifically applied to one (or more) players who will then need to carry out that task.

But always keep in mind that Arma 3 can be played in more ways, this is an open world game after all. And there's also multiplayer to consider.. Meaning? Easy: why assume that tasks always need to be performed in sequence? You could also set up a scenario in which the player gets several tasks to complete and its up to them to assign one and then try to complete it in any order they want.

Or what about a multiplayer scenario where a commanding officer decides which team member(s) will be performing which task(s)? The officer could then tell the member to assign themselves with that task and by doing so they will get all the required information to complete it (do note that I have no hands on experience with multiplayer just yet, but I could well imagine this to work).

Failing and succeeding

There are three more states we need to know about other than 'Assigned': when a task is successfully completed it can be marked as such by setting it to the 'Succeeded' state. The player (usually) gets a notification that they successfully completed the task and they will also be able to see this in their task log. And of course if a player wasn't able to complete a task it can be set to 'Failed'. Roughly the same happens as above: the player gets warned about this and it will be logged. Note that you don't necessarily have to die in order to fail a task.

And finally there's also the 'Cancelled' state. This roughly behaves the same as the 'Failed' state but uses a different icon. I could imagine using this if you want to give the player a choice between several tasks and once he picks one then the others get automatically cancelled.



So to add a task you first press F5 to bring up the 'systems' section in the Assets menu which is shown on the right side of the editor. Expand the 'Intel' folder and you'll find an entry called "Create task", you can recognize it by its + icon. Also see the screenshot above.

Select it and then click somewhere on the map to add it. Next open its attributes by either double clicking on it or use right click and then select the 'Attributes' option.

There are several settings you always need to check when working with tasks. First of all the owner; this will determine who gets to see the task. By default the owner will be set to 'Groups of synchronized objects', so if you just add a task then your player(s) won't be able to see it unless you synced them to it. This can be useful in multiplayer where you might want to assign different tasks to different players. But in a single player map, and especially with the first task, you'll want to set the owner to 'All playable units'.

Next is the 'Destination' setting. If you want a player to head to a certain position then you can show a marker on the map to make it easier for them to find their way. By default this will be set to 'Module location', which is also why my task module is located on the tower itself (as seen in the screenshot above).

But what to do if a player needs to kill a specific NPC which is on the move?

In that case you could sync the NPC to the task and set this setting to 'synced objects'. Now the player will see a marker which shows them the NPC's position. Seek & Destroy! And finally you can also disable this setting if you don't want the player to see any markers, or if a marker simply isn't applicable (I'll show some examples soon enough).

The 'State' setting is also important because this will determine how the task needs to be handled, I already covered the details above. For the first task you'll want to set this to 'Assigned' so that the player immediately starts out with something to do.

And finally the task type determines what kind of icon the player gets to see on the map:

Here you can see the marker on the guard tower, this is the task I showed above...

So now that we have given our player a task to do ('Climb the guard tower'), how do we check if they've done that? And more importantly: how do we tell them that they completed the task?

Well, remember triggers? If not: a trigger is an object which can constantly check if a specific condition is met. Either globally throughout the entire map or within a specific area. If you look at the editor screenshot again (below the 'Task one' header shown above) you'll notice a blue square around the guard tower. You may also notice a small blue flag icon next to the task I added: that's the trigger module. In this case I limited it's size to only cover the guard tower.

In the trigger attributes I set the Activation setting to 'Any player' and the Activation type to 'Present'. In other words: if any player enters the area of the trigger (so: enters the guard tower) then it will meet its requirements and the trigger will be activated. Time for the next step...

You can control a task by using some specific modules which can also be found in the 'Intel' folder:

• Set Task Description: This can set (or change) the description of a task.
  
• Set Task Destination: Same as above but this time the destination property is changed.
  
• Set Task State: With this module you can set the task to another state like 'Assigned' or 'Succeeded'. This is the module we're looking for.

So first add a new "Set Task State" module to the map. Double click to open its attributes and then select the new state for your task. In my example the task needs to be set to 'Succeeded', so select that option here.

Now we need to connect the different modules so that they can interact with each other. Right click on the trigger icon (the blue flag) and select "Connect -> Sync To", once you selected the option click on the "Set Task State" module you just added. When done you should see a blue line between the two modules. Then do the same for the "Set Task" module and connect that to the task module.

This will instruct the trigger to activate the "Set Task" module which in its turn will change the task module and set it to the Succeeded state:




In my example the player has to complete a specific sequence of tasks. So the next task will only become available ("Assigned") once the current task is completed. How to set that up? It's much easier as you might think:



Here you see the next task which is "Defend the camp". After placing it I made sure to leave its state to 'Created'. So now it's time to do the same thing as before: I added a "Set task" module and told it to change the tasks state to 'Assigned'. I then connected it to the task and then synced it to the same trigger which I used to complete the previous task (player entering the guard tower).

So our previous trigger not only completes the current task of entering the tower, it also assigns the next task to the player. In my example "Defend the camp". Easy right?

And in case you're wondering about the other trigger in the middle of the screenshot above: that is the trigger which completes this second task. It checks for the presence (or rather: disappearance) of any OPFOR (= hostile) troops and once that condition is met it triggers a "Set task" module which in its turn sets the connected task to 'Succeeded'.

Which leaves us with one final thing to do....

In case you had forgotten there's still an APC to deal with.. ;)

So to make sure that the APC wasn't going to interfere with our previous trigger (which size I set to 500m) I moved it out of the way and a little bit further down the road, as you can see above. As before I used the same trigger to both complete the previous task ("Defend the camp") and assign this next task ("Neutralize remaining forces"). To make it a little more difficult for the player I disabled the waypoint in hopes that some players might charge down the mountain, only to get gunned down by the APC. ("Oops, so there weren't only infantry units in this mission, now what?").

And then I ran into a bit of a problem... Although it is possible to "nest" triggers (so using one trigger within the area of another) it can also create some issues sometimes. At first I tried to use the same kind of trigger I originally had: one which surrounded the APC and would check for the disappearance of that APC. But for some reason this didn't work: it would always trigger as if the APC wasn't there anymore, while in fact it was.

Now what?


Well, in those cases there's a very important detail which newer players to Arma 3 (such as myself) need to keep in mind... Although it may look as if we're simply stringing modules together and are using a "visual programming environment" the reality is much different:


What's this you ask? It's the mission file (a small part of it anyway) which got created using the Eden editor. I turned off the "Binarize" option and then loaded it into my favorite text editor; the result can be seen above. So by adding those modules into the editor all we're basically doing is adding code snippets into our mission file. And that is a very important detail to keep in mind when we're working with the editor!

Not only because realizing this feat will open up a whole new load of possibilities to us, it can also explain why some things may not work as you'd expected. But first the features...

When I realized that my 3rd trigger to check for the APC wasn't working I quickly came up with another solution. Instead of defining an area in which the APC should be present I simply added a scripted condition to check for this.

So: I added a trigger (as can be seen above, the one that is connected to those other modules) and then I didn't define a size, type of activation but only set a condition:


After that I made sure to assign variable names to both the Marid APC and its crew (= the gunner and driver). So now this trigger checks if the APC ("marid"), its driver ("maridD") and its gunner ("maridG") are dead (the exclamation mark in front of 'alive' means that it should negate the outcome). The && sign basically means "the next condition also needs to be satisfied", resulting in this trigger to check for 3 conditions at once: the demise of the APC and both of its crew members.

Because this is also the last task which the player needs to complete I set the trigger to play some victory sounds as well, gives a nice atmosphere ;)

The only thing left to do is check when the entire scenario should be successfully completed. That is handled by the second trigger module (the one without any connections). This uses the following condition:


Also simple reasoning I hope: there are two triggers which check for the defeat of the enemy troops. The first one ("trigDefeatBX") is that 500m radius trigger which checks for the presence ("disappearance") of any OPFOR troops within its range. The second trigger ("trigDefeatAX") is the one I just explained above: the one which checked for the demise of the APC and its crew.

So once both those triggers have been activated then this last trigger gets activated as well and it will end the whole scenario, but only after a short countdown has been completed so that we can savior our moment of defeating the APC and its crew.


A good way to give the player a bit more information about the mission (and an optional back story) are briefings. This is a screen in which you usually present the player with a few specific sections:

• Situation: This tells the background story of whatever it is the player is getting themselves into.
  
• Mission: A brief description of the actual thing(s) which the player needs to do.
  
• Execution: All the individual steps ('tasks') which have to be completed in order to successfully end the mission. Usually has links which the player can click on after which the location will be highlighted on the map.
  
• Signal: A list of callsigns for everyone involved in this mission; whether it's directly or indirectly (so: this can also include squads which only exist in storyline).

Adding this information is actually not that much different from adding tasks to your scenario. You press F5 to open the Systems section, expand the 'Intel' folder and there you'll find the "Create Diary Record" module.

If you open its attributes you'll see that some even correspond with those of the tasks. Just as before you need to make sure to use a correct entry for the 'Owner' setting, otherwise the briefing may not even show up for your players. In a singleplayer mission you'll want to set this to "All playable units".

The 'Preset title' setting is used to define what briefing section you want to create; all the fields I mentioned above are also available here.

So far, so good... all you have to do is add a module, define the text you want to use, and you're done. Right? Well... Remember what I mentioned earlier about how Eden basically creates a script which essentially controls your mission? Because of that there are some limitations to what Eden can actually do for us when it comes to using modules. And unfortunately we're hitting one of those limits right here.

You see... If you add the briefing sections in order, so you start by adding your 'Situation', then the 'Mission' and finally the 'Execution' you may end up surprised if you try this out. Because chances are high that the end result is that all your entries are being shown in a reverse order. So instead of seeing 'Situation', 'Mission' and 'Execution' you may end up with: 'Mission', 'Execution' and 'Situation'. Pretty annoying indeed!

Fortunately there is a good way to solve this: cut and paste. So control-x and control-v. This allows you to actually remove and re-add the module to you mission and that will allow you to change the sequence. Basically if you see a reverse sequence in your entity browser then it's likely that you'll get the right sequence in your mission.

In case you didn't realize: pressing Enter in the Eden editor will quickly start your mission but pressing shift-Enter will start it with the briefing. The perfect way to check.


Another issue I'd like to address is the fact that tasks are always visible to players, despite the fact that the help screen claims that tasks are hidden from a player until they're actually assigned. I'm still not sure if this is a bug in the editor or, what I suspect, another issue of "visual building" clashing with the underlying scripting.

However, I did manage to come up with a solution but I have no idea if I'm doing the right thing or merely abusing the system.

A trick which worked for me was to synchronize a trigger with the upcoming task:



Here I select the "trigTower" trigger; as I explained earlier this trigger checks if the player has entered the guard tower and if so it changes the state of the next task from "Created" to "Assigned". You can see this in the screenshot: the trigger is synced to the 'Set Task State' module
(the carrot sign icon). That module is then synced to the actual task (the icon with the + sign). However, the trigger is also synced with the task itself.

I'll be honest: I have no idea why this works, but the result of this setup is that the task remains hidden until the trigger is activated and the task gets assigned to the player. My theory is that by syncing the task with the trigger you're actually setting up a (temporarily) different owner for that task. Once the trigger gets executed the task gets assigned and because the attributes set the owner to 'All playable units' it now behaves as usual: the player will see the assigned task.

Please note: this is pure speculation on my end and actually a bit of a work in progress for me. I found ancient articles and posts (dated 2012 to 2014) which confirm that this setup works, but unfortunately I found nothing which actually (tries to) explain(s) the reason why this is working at all. In the end I'm convinced that the reason for these hiccups is the fact that we're actually building a script when using the Eden editor.

So some things are better performed by actually coding instead of adding visual modules, at least that's my theory. However, since I'm not looking forward to dive into yet another programming / scripting language I'm only focussing on the Eden editor for now.




If you check the 'Attributes' menu and then select the 'General' option you'll get an overview of some of the scenario properties. Here you can set up specific attributes such as the mission overview, the screenshot above shows you an example of how this can look like.

Unfortunately I ran into even more inconsistent behavior here and I have yet to find out how to solve that.

You see... although the attributes screen shows you entries which allow you to provide general information for the scenario as well as define the entry for the loading screen, the end result that I'm getting is that the loading screen shows up just fine (as shown above) but when I export my mission as a single player scenario the system suddenly can't find any information about my scenario. It can't even figure out who made the mission, despite the fact that the loading screen clearly shows my name.

Alas, those hiccups don't take anything away from the current end result: changing a rather mediocre mission into a more official scenario by adding tasks, setting optional waypoints for the player and of course creating a better looking loading screen with a customized logo.


A showcase of some of the things I've been working with recently, I hope you enjoyed and maybe even learned a new trick or two.

Thanks for reading!