Setup GitHub

Create a GitHub account

If you don't already have a GitHub account, you can create one for free at github.com.

Link your GitHub account to your Discord account

You will need to ask a Staff member to invite you to the Synixe Contractors GitHub organization.

You will receive an invite to the email address associated with your GitHub account, or you can visit the GitHub Organization. Accept the invite to join the Synixe Contractors GitHub organization.

After you have accepted the invite, you will need to request access from a staff member to the Mission Making team. This is separate from the #mission-making channel in Discord.

Install GitHub Desktop

GitHub Desktop is a graphical user interface for GitHub. It allows you to easily clone repositories, create branches, commit changes, and push changes to GitHub.

You can download GitHub Desktop for free at desktop.github.com.

Clone the repository

Once you have GitHub Desktop installed and open, you can clone the repository by clicking the "Clone a repository from the Internet..." button.

1. Click the "Clone a repository from the Internet..." button.
2. Enter "SynixeContractors/Missions" into "Filter your repositories" and select the repository.
3. Click "Choose" under "Local path".
4. Select your Arma 3 mpmissions folder. The default location is C:\Users\{username}\Documents\Arma 3 - Other Profiles\{profile}\mpmissions.
5. Click "Clone".

Mission Making

This guide will cover all the basics of creating a mission for Synixe Contractors, as well as provide some tips and tricks for more advanced mission makers.

Mission Types

There are several different types of missions that can be created for Synixe Contractors. Each mission type has its own unique requirements.

Contracts (CO)

Our main mission type. Contracts are the bread and butter of Synixe Contractors. They are the most common mission type, and what you will be making most of the time.

Sub-Contracts (SCO)

Sub-Contracts are smaller missions that are played outside of the regularly scheduled contracts.

Campaign-Contracts (CCO)

Campaign-Contracts are contracts that are part of a larger campaign. Creating a campaign is a very involved process, and requires additional information and explicit approval from Staff before it can be created.

Training (TRA)

Training missions are specially designed training missions that teach a specific skill or set of skills. We have our main training mission that is always running on the training server. It is unlikely that you will be making training missions. It is preferred that you use the main training mission, and if you need to make a training mission, you should contact Staff first.

Special (SPC)

Special missions are missions that are not part of our Synixe Contractors "lore". They do not use our persistent systems, and can be any faction doing anything. These are the least common mission type, and are usually used for special events.

A New Mission

Update your local repository

The first step before starting a new mission is to make sure your local repository is up to date.

1. Open GitHub Desktop.
2. Select the Missions repository.
3. Select the main branch.
4. Click the "Fetch origin" button if it is available.
5. Click the "Pull origin" button if it is available.

Create a new branch

Each mission must have its own branch. This allows you to work on multiple missions at the same time without having to worry about conflicts.

Each branch is named after the mission. See Mission Typess for more information on mission types.

{Type}{Players}_{Author}_{Name}

CO30_Brett_ThroughThePassage
SCO30_Felix_WhisperingWinds
TRA30_Arsey_ParajumpScenario
SPC12_Matias_6v6CTF

1. Open GitHub Desktop.
2. Select the Missions repository.
3. Select the main branch.
4. Ensure there are 0 changes.
5. Click the "Current branch" button.
6. Click "New branch".
7. Enter a name for your branch.
8. Click "Create branch".

Editor

Open the Arma 3 editor on your map of choice. The first thing you should do is save the mission. The name of the mission should match the name of the branch.

Save the mission under the correct folder, depending on the mission type.

Always uncheck "Binarize the Scenario File" when saving the mission.

1. Open the Arma 3 editor.
2. Select the map you want to use.
3. Click "OK".
4. Click "Save As".
5. Select the correct folder.
6. Enter the name of the mission.
7. Uncheck "Binarize the Scenario File".
8. Click "Save".

Mission Template

The mission template is a starting point for all missions. It contains everything needed to create a Synixe Contractors mission.

It can be downloaded from GitHub.

1. Click "Scenario > Open Scenario Folder".
2. Find the mission template.
3. Copy the template folder into the mission folder.
4. Reopen the mission.

Creating the FOB

Every mission needs a FOB. This is where players will spawn, and where they will return to after completing objectives. The FOB is also where players will access the shop, and where vehicles will be spawned.

Pick a location

A FOB must be within a reasonable distance from the AO, but far enough away that the enemies will not be alerted to the FOB's presence.

A good FOB location:

• Is a reasonably flat area
• Is at least 2km from the AO
• Is not too close to any civilian areas
• Has access to a road

Place the Contractors

Place the contractors in the FOB. These are the units that players will control. They should be placed without colliding with any other objects.

1. Place the player group, found in Compositions > Independent > Synixe Contractors > Base Components > Players
2. Highlight all units in the group.
3. Right click on one of the units, select Attributes
4. Change Callsign to Synixe
5. Navigate down to the Object: Control section
6. Check Playable
7. Set the Role Description to Contractor

Respawns

By default, no respawn setup is needed. Players will respawn where their player started.

You can alternatively set up respawn points.

Default Respawn

1. Place a Respawn object, found in Objects > Props > Synixe Contractors > Helpers.

That is it! Players will now respawn at the location of the Respawn object.

If multiple Respawn objects are placed, players will respawn at a random one.

Triggered Respawn

It is possible to change the respawn points based on a trigger.

1. Place a Respawn object, found in Objects > Props > Synixe Contractors > Helpers.
2. Place a Trigger, configure it to your liking.
3. Sync the Respawn objects to the Trigger.

When the trigger is activated, any synced Respawn objects will become the only active respawn points.

Spectator Screens

Spectator screens allow players to spectate the mission if they have died or join late to watch the mission.

1. Place a Spectator Screen object, found in Objects > Props > Synixe Contractors > Electronics > Spectator Screen.

That is it! Players are now able to spectate the mission.

Shop

The shop is where players will purchase and access their equipment.

It is advised to place multiple shops around the FOB, so players are able to spread out and not crowd around a single shop.

1. Place any object that is a viable shop.
2. Right click on the object, select Attributes.
3. Navigate down to the ``Object: Crate - Persistent Gear`.
4. Check Shop.

Vehicles

Various kinds of vehicles can be spawned at the FOB.

They are:

• Land
• Heli
• Plane
• Sea
• Thing

Thing is a special category that allows for non-enterable objects, jerry cans, crates, etc.

You are required to place a Land and Thing spawn point. The other spawn points should be placed whenever possible.

1. Find the appropriate spawn point in Objects > Props > Synixe Contractors > Helpers.
2. Place the spawn point in a suitable location, ensuring no objects are colliding with it.

Multiple spawn points can be placed, when an object is spawned it will select the first available spawn point of the correct type and size.

Small vehicles can use large spawn points, but large vehicles cannot use small spawn points.

Building the Mission

Creating the contents of the mission is a nuanced process. There are many different elements that can be included in a mission, and many different ways to use them.

The Basics

Every mission should contain a clear direction for the players to move in. It does not need to be exhaustive, but the players need to be able to easily understand the premise of the mission, and what they need to do to complete it.

Examples include:

• Go to X and search for intel about Y.
• Go to X and destroy Y.
• Search the area for X and bring it back to base.
• Someone went missing around X, go find them.

The Goal of Mission Making

The goal of mission making is to create a fun and engaging experience for the players.

A mission should be challenging, engaging, and rewarding. It should never be intentionally frustrating, tedious, or punishing.

The mission should be difficult enough that the players need to work together to complete it, but not so difficult that they are unable to complete it. Mission failures should be the result of the players' actions, not the mission maker's.

Avoiding Rails

A mission should not be a linear experience. The players should be able to choose how they want to approach the mission, and the mission should be able to adapt to their choices. Triggers should be used to react to the players' actions, not to force the players to do something.

Triggers should almost never be chained together, the conditions should be set up with the minimal amount of "gatekeeping" possible.

If you find yourself using a lot of triggers to force the players to do something, you should consider reworking the mission to allow the players to make their own choices.

Dynamic AI modules are preferred over predefined routes and waypoints. They allow the AI to react to the players' actions, and can be used to create a more dynamic experience. Players should not be able to predict where the AI will be, or what they will do. Players shouldn't feel like they have "missed out" on something because they didn't do it the "right" way, as there is no "right" way to do complete a mission.

Configuring the Template

VS Code

You will need to have Visual Studio Code installed. This is a free, open source code editor that is very popular with developers.

Open Mission Folder

Use Scenario > Open in VS Code to open the mission folder in VS Code.

Editing Files

The template contains two folders, edit_me and do_not_edit. There are files in the root of the mission folder that can also be edited, but be sure to leave the top of the files unchanged, or the mission will not work.

edit_me/desctiption.ext

This file contains some variables that you can change to configure the mission. The variables are:

• OnLoadName: The name of the mission that will be displayed in the mission loading screen and in Discord.

• OnLoadMission: A single sentence description of the mission that will be displayed in the mission loading screen and in Discord.

• author: Your name.

• synixe_type: The type of mission. Check the comment for a list of valid types.

• synixe_start_time: The hour of the day that the mission will start. When the mission is loaded, the time will be set to the correct time before the the start time, so that the mission will start at the start time. The minutes are always synched to minutes in real time.

• synixe_spectator_range: The range from a spectator screen all players must be for automatic enbling of spectator mode.

edit_me/briefing

The briefing folder contains files that will be used to generate the mission briefing. The files are:

• situation.html: The situation on the ground. Provides context for the area of operations.

• mission.html: Mission description, why we are there, etc.

• objectives.html: The specific objectives of the mission, and restrictions on how they are to be accomplished.

Pushing to GitHub

GitHub Desktop

Once you are done your mission, you will need to push it to GitHub.

1. Make sure you are on the branch you intend to push, and all the files appear in the "Changes" tab.
2. Enter a summary of the changes you made in the "Summary (required)" field.
3. Click "Commit to ...".
4. Click "Publish branch" or "Push origin" to push the changes to GitHub.
5. Click "Preview Pull Request" to open the pull request on GitHub.

Github Website

You will need to create a Pull Request, so that the mission can be reviewed and merged into the main mission repository.

Brodksy will do an automated review and check your mission for common mistakes.

Once Brodsky has reviewed and approved the mission, a mission reviewer will review the mission and approve it or request changes.

Once the mission has been approved, it will be merged into the main mission repository, and will be available for play on the server.

You can delete your branch once the mission has been merged.

Action

A simple function for creating an ACE interaction menu action on an object.

Parameters

• object: Object - The object to attach the action to.
• title: String - The action name.
• action: Code - The action to perform when the action is selected.
• repeatable: Boolean - Whether the action can be repeated. Default is false.
• condition: Code - The condition for the action to be available. Default is {true}.
• icon: String - The icon to display next to the action. Default is the dot.

Action Code

The code will only run on the client that activated the action, make sure to take this into account and ask for help if you are unsure how to handle this in your code.

Inside the code, you have access to two variables:

• _player: Object - The player who activated the action.
• _target: Object - The object the action was activated on.

Example

Example Mission

In this short example, a laptop is used to trigger explosives on a fuel truck.

The player can interact with the laptop, and will play a gesture while the fuel truck is destroyed.

Because the repeatable parameter is not set, the action will disappear when it is used.

initPlayerLocal.sqf

[
    laptop,
    "Press Enter",
    {
        [_player, "PutDown"] call ace_common_fnc_doGesture;
        fueltruck setDamage 1;
    }
] call synixe_missions_fnc_action;

Computer Upload

An interaction on a laptop for the players to "hack" and upload data.

Parameters

• object: Object - The laptop object.
• textureSource: Number - The texture source for the laptop screen.
• filesize: Number - The size of the file to upload in gigabytes.
• uploadTime: Number - The time it takes to upload the file in seconds.
• onStart: Code - Code to run when the upload starts.
• onComplete: Code - Code to run when the upload completes.
• host: String - Host name to display on the laptop screen. Default: localhost.
• user: String - User name to display on the laptop screen. Default: root.

The texture source is the index of the texture in the textures array of the model. You can find this by looking at the object in the editor.

In this example, the texture source is 1.

On Start & On Complete Code

The code will only run on the server, make sure to take this into account and ask for help if you are unsure how to handle this in your code.

Inside the code, you'll have _this available, which has the following properties:

• _object: Object - The laptop object.

Example

Example Mission

In this example, the player interacts with a laptop to upload a file. After the upload, the laptop screen will go black.

init.sqf

[
    laptop,
    1,  // texture source
    50, // size in GB
    8,  // time to upload in seconds
    {
        systemChat "Server: Upload Started";
    },
    {
        systemChat "Server: Upload Finished";
        // Clear the screen after 2 seconds
        [{
            params ["_object"];
            _object setObjectTextureGlobal [1, ""];
        }, _this, 2] call CBA_fnc_waitAndExecute;
    }
] call synixe_missions_fnc_computerUpload;

Speak

A function for creating an interaction on a unit to speak with them.

Parameters

• unit: Object - The unit to attach the interaction to.
• sound: String - The sound to play when the interaction is selected.
• onStart: Code - Code to run when the unit starts speaking.
• onDone: Code - Code to run when the unit finishes speaking.
• repeatable: Boolean - Whether the interaction can be repeated. Default is true
• condition: Code - The condition for the interaction to be available. Default is {true}.
• title: String - The title of the interaction. Default is Speak.

Start & Done Code

The code will only run on the server, make sure to take this into account and ask for help if you are unsure how to handle this in your code.

Inside the code, you'll have _this available, which has the following properties:

• _unit: Object - The unit that is speaking.
• _sound: String - The sound that is playing.
• _first: Boolean - Whether this is the first time the sound is playing.
• _duration: Number - The duration of the sound in seconds.

Example

Example Mission

In this example, the player interacts with an officer to hear them speak, and get intel after the speech.

description.ext

class CfgSounds {
    class Officer {
        name = "Officer";
        titles[] = {};
        sound[] = {
            "officer.ogg",  // Path to sound file
            5,              // Volume, 5 is recommended, always test in-game
            1               // Pitch
        };
        duration = 6;       // Duration of the sound in seconds
    };
};

initPlayerLocal.sqf

[
    officer,    // variable name of the officer unit
    "Officer",  // class from CfgSounds in description.ext
    {
        systemChat "Officer: I'm talking";
    },
    {
        systemChat "Officer: I'm done";
        // The first time we interact, play an animation and give intel
        params ["_unit", "", "_first"];
        if (_first) then {
            [_unit, "PutDown"] call ace_common_fnc_doGesture;
            systemChat "Intel Received!";
        };
    }
] call synixe_missions_fnc_speak;

Empathy

When you want to make a mission that will engage players and allow them to creatively solve problems, you should generally avoid thinking linearly. The first step in order to do this is trying to get into the other faction's mind, and ask yourself: "how would I do this?"

Imagine you set up a group of OPFOR to defend a location but this location has many entrances, aside from the front door, there's gaps in the wall, there's a back entrance, maybe there's a forest nearby. These are all things that a competent enemy would think about when setting up an efficient defense for a position, unless you purposely want to depict the enemy force as incompetent.

In this case, you can add a patrol outside and around the compound. Maybe a guy or two guarding the gaps. This will account for different ways players could possibly take on this objective, instead of just one.

Try to get in the enemy faction's mind and think to yourself how would you utilise the resources you have to complete a task, whether it is an attack, an ambush, or the defense of an important strategical keypoint.

Conditioning

An interesting thing we can keep in mind is the use of conditioning. Players are often trying to put a puzzle together when playing missions based on the cause-and-effect of their playthrough, and sometimes, if we can foresee this, we can condition the way they will play, succeed, or fail, your mission.

If players are often finding IEDs in trash bags, that is going to turn into the 'implicit language' of the mission: trash bags have IEDs! If enemy garrisons always have a campfire nearby, they are going to start associating that as a mechanic within the mission: enempy encampments all have campfires! Players will go through a 'lessons learned' experience contained within your mission.

This is generally a hit or miss, depending how explicit, how often and how long your mission is, not to mention how attentive players are being, but this is a subtle resource you can use to control your mission and guide players indirectly.

Indexicality

Indexicality is the way we can communicate things indirectly to your players, albeit this relies a lot more on intuition rather than conditioning. What this means is that players won't have a "cause-and-effect" learning experience to advice what could happen.

Resorting to this will rely heavily on the players' previous baggage and outside experiences, let alone the experiences they've had previously with the game, while not being entirely contained within your mission.

To put this simply, smoke cannot exist without fire, but it is not fire. The presence of smoke lets us know, indirectly, that there is a fire nearby.

Following this same logic, if we have some knowledge of previous missions, real life events, in-game universe lore, and even our users' backgrounds, it would be possible to try and put together things we know they might expect.

If players are sent out on a mission to rescue a crashed down helicopter, smoke is a good indicator of where there is fire, indicating where there is likely a crash. If players are trying to find and locate enemies within a region, finding their vehicles or some supply caches around might indicate that they either are, or have been, nearby. A siren alarm after players raid a base or attack a location is not an enemy attack in of itself, but it indicates that it is likely for reinforcements to come and respond to the threat.

This entails taking on a lot of assumptions about your players, and the above are very explicit examples. However, with proper thought, you can find your own ways of communicating with the players entirely through your mission alone, which the players may or may not catch.

Engaging the Player

Synixe has members with varying playstyles, it is important to keep this in mind when designing a mission. The goal of this guide is to help you create a mission that is engaging for all players.

Some members like to just show up a shoot bad guys with their friends, others like to roleplay and immerse themselves in the mission. While some missions will lean more towards one playstyle than the other, it is important to take both into consideration when designing a mission.

Investigation Missions

A mission that is solely focused on investigation and roleplay may be very engaging for the Operation Lead and other members who enjoy that playstyle, but it may not be very engaging for the members who are just tagging along to shoot and aren't very involved in the investigation.

Some ways to make an investigation mission more engaging for all members:

1. Have the investigation lead to small skirmishes with the enemy, perhaps the enemy is trying to cover up the evidence.

2. Have enemies patrol the area, ambush the players, or have them respond to the players' presence. A Lamb's Hunt module can be great to have the players chased as they try to move through the operation area.

3. Have the investigation lead to a larger battle, perhaps the enemy is protecting a secret base or a cache of weapons.

4. Have a blocking force that protects the players conducting the investigation from being attacked while they are busy. Perhaps they are investigating an area but an enemy force wants to move in to disrupt and stop the investigation.

Combat Missions

One the other hand, a mission that is solely focused on combat can get boring for members who are looking for more than just a shooting gallery.

Some ways to make a combat mission more engaging for all members:

1. Have multiple objectives that the players only have the ability to complete one or some of. This will force the players to make a decision and will create a need for information gathering and decision making.

2. Have some of the locations unknown to the players, they need to gather intel on the location of the enemy base before they can attack it. A simple puzzle can also be used to create a discussion and decision making process.

3. Have non-combatants in the area, perhaps the players need to protect them or they need to be extracted. This will create objectives that are not solely focused on combat.

4. Don't make the enemy force static, have them move around and respond to the players' actions. This will create a more dynamic battlefield and will force the players to adapt to the situation. Lamb's modules can be used to create a more dynamic battlefield.

Managing Time

Time management is an important part of mission design. Considering how time will be spent in the mission is important to ensure that the mission is engaging for the players.

Travel Time

Travel time is the time it takes for the players to move from one location to another. This can be from the FOB to the AO, from one objective to another, and back to the FOB. Travel time can be a boring part of the mission, especially at the start and end of the mission.

Travel time can be managed by:

• Keeping the first objective close to the FOB
• Keeping the objectives relatively close to each other
• Keeping the last objective close to the FOB

Pacing & Recovery

It is important to consider the pacing of the mission, and how much time the players will have to recover between objectives. If the players are constantly under pressure, they will not have time to recover. This is not bad in moderation, but you should be careful not to overdo it, causing the mission to become exhausting and disorganized to the point where the players are not having fun.

You can manage the pacing of the mission by:

• Having multiple smaller QRFs that arrive at different times
• Allowing some objectives to be done in any order
• Delaying QRFs until the garrisoned units are dead, allowing for a brief pause

Varying the pacing of the mission can be a good way to keep the players engaged and on their toes. Periods of low intensity and high intensity can be used to create a dynamic battlefield.

Avoiding the Long Drive Back

At the end of the missions, the players will want to get back to the FOB, do debrief, and log off. Having a long drive back to the FOB can be a boring end to the mission, and cause a rushed debrief. Having players dead and in spectator makes this drive even more of a chore.

To avoid this, you can have the player extract from the AO when appropriate.

If you have multiple objectives you can lay them out in a way that the players are moving back towards the FOB as they complete the objectives.

| C      B |
|          |
|          |
| D      A |
|          |
|      F   |

In the example above, the players leaving from the FOB (F) will move towards objective A, then B, then C, then D, and then back to the FOB. The objectives are laid out so that the players are moving back towards the FOB as they complete the mission, and the drive back to the FOB is not as long as if the objectives progressively moved away from the FOB.

Back Up Vehicles

If the players have lost vehicles during the mission, espeically near the end, it can be a problem with getting everyone back to the FOB. Remember, the enemies have vehicles too, they needed to get there somehow! Having some vehicles at enemy locations is great for preventing this problem, and is realistic too.

Difficulty Stacking

Difficulty stacking is the process of adding multiple layers of difficulty to a mission. This is done to create a more engaging experience for the players and to create a more dynamic battlefield.

It is important to note that difficulty stacking is not the same as difficulty scaling. Difficulty scaling is the process of changing the difficulty of the mission based on the number of players. Difficulty stacking is the process of adding multiple layers of difficulty to a mission.

Stacking

Stacking the difficulty is done by picking various elements that make up the difficulty.

If a mission has a story about attacking a weak militia force, the difficulty of the mission can be too low to start with. We can add difficulty to the mission by adding more elements to the mission, but we need to be careful not to add too many elements and creating a punishing mission that will not be fun for the players.

Amplification

Some elements of difficulty amplify each other. This is usually a negative effect.

A mission involving searching for something hidden will be much more frustrating for the players if the mission is at night, or with heavy fog. The players will have a hard time finding the hidden object, and will likely get frustrated and not enjoy the mission.

A mission where they players are attacking know enemy positions are more suited for night time, adverse weather, and difficult terrain. This will add a challenge to a familiar mission type without adding unnecessary frustration.

Enemy Difficulty

Equipment

Infantry

The enemy infantry's equipment will determine how hard they are to defeat. An ememy force with body armor, helmets, and high quality weapons will be harder to defeat than an enemy force with carrier rigs, head scarfs, and low quality weapons.

Vehicles

The enemy vehicles' equipment will determine how hard they are to defeat.

Simple vehicles can be used to quickly bring in reinforcements, potentially before the players have had a chance to deal with the current encounter.

Armed vehicles can be used to create a more challenging encounter for the players. A vehicle with a 50 cal machine gun will be high priority target for the players that they will need to react quickly to.

Armored vehicles are the most difficult to defeat. They will likely require the players to use anti-tank weapons or explosives to defeat. They should be used sparingly as they can easily overwhelm the players.

Composition

The composition of the enemy force will have a large impact on the difficulty of the mission. A force that is composed of infantry will be easier to defeat than a force that has access to armored vehicles.

A group of 4 infantry on their own, or a lone .50 cal technical, will be much more easily defeated than a group of 4 infantry with a .50 cal technical supporting them. The players will need to prioritize the .50 cal technical and will need to react quickly to it.

Squad Size

The size of the enemy squads will have a impact on their ability to share informcation and move around the battlefield. Small groups of AI are more able to move around the battlefield and react to the players' actions quickly and efficiently. Larger groups of AI are less able to move around as they try to stick together, but will be able to share information more easily. Informing each other of the players' locations.

Squad Composition

Make note of the enemy squad's composition. Enemy squads with a diverse composition will be able to react to the players' actions more easily. Marksmen, automatic riflemen, and grenadiers will allow the enemy squad to be more effective in a wider variety of situations. A squad of 4 diverse AI can be more effective than a squad of 8 riflemen in some situations.

Density

The density of the enemy force will have a large impact on the difficulty of the mission. A force that is spread out will be easier to defeat than a force that is concentrated. Having 100 enemies spread out in groups of 10 at camps around the operation area will be much easier to defeat than having 100 enemies within a single base.

Tactics

The enemy force's "tactics" can be an important factor in the difficulty of the mission. These are determined by the modules, scripts, and triggers that are used in the mission. An emeny that is garriasoned in a base will be easier to defeat than an enemy that has patrols, will un-garriason the base when the players are detected, and will call in reinforcements when the players are detected.

Weather

Weather can be a big influence on the difficulty of a mission. Varying levels of adverse weather can be a good way to increase the difficulty without requiring a lot of work.

Random Weather

By default, the weather in the mission is random, but influenced by the location and date of the mission. Leaving the weather unchanged is fine for most missions, as it won't ever be too bad and increase the difficulty too much.

Setting the Weather

When you do want to make an easier or harder mission, you can set the weather to be more or less adverse. Adding rain or fog will reduce the players' ability to see and / or hear the enemy.

You can set the mission to start clear and worsen over time, or start bad and improve over time, depending on the type of mission you are making.

Keeping it Realistic and Reasonable

It is important to keep the weather realistic and reasonable. Arma does not play well when the weather is too bad. Very heavy fog is unreasonable and will make the mission for frustrating than fun. Certain mission types are also not suited for adverse weather, such as search and rescue, finding something hidden, or getting ambushed. In reality, missions would be postponed if the weather was too bad.

Terrain

Terrain choice can have a significant impact on the difficulty of a mission.

The types of buildings, foliage, and density of those objects will influence the kind of mission that can be created, and the options the players have available to them.

The affect of terrain can vary depending on the mission objectives.

Camps in the open are easier to assault than those in dense forests. But a heavily fortified base in the open is harder to assault than one in a dense forest, as the defenders have more time to see & react to the attackers.

After selecting the locations for your objectives, you should consider their surroundings and stack other elements of difficulty accordingly.

Waypoints & Triggers

Trigger Conditions

Triggers are something incredibly useful, and often intuitive to add a special colour to your mission. They are a condition that will decide whether something in the mission happens or not, based on what did or did not happen before. Below we will see some examples of what can be added as trigger conditions.

It is useful to be aware of the following expressions:

! means NOT. If we were to use !alive this means NOT alive.

&& means AND. This lets us combine two lines of code, such as: !alive variableName1 && alive variableName2.

|| means OR. This means that either condition will activate the trigger, regardless of the other: !alive variableName1 || alive variableName2.

Checking if a specific unit, object, or vehicle, is alive

If we put alive variableName in a trigger's condition field, we will check whether that item is alive or dead to activate the trigger. Once they are dead, the trigger will be activated. If we want to check for the opposite, we can use !alive variableName inside the trigger's condition field.

Checking if a specific unit, object, or vehicle, is inside the trigger

We can use variableName in thisList inside a trigger's condition field to check if a specific unit is present inside of it.

Checking if another trigger was activated beforehand

If we want to have a trigger depend on another trigger, we can use triggerActivated triggerName within another trigger's condition field to make it depend upon another trigger having been activated previously, meaning that, this trigger won't activate on it's own.

Checking for a specific in-game time

If we want something to happen at a specific in-game time, we can put the following inside the trigger's condition field:

((date select 3) >= HH) && ((date select 4) >= MM)

On Activation Code Snippets

Here are some simple things you can use in the On Activation field for your missions.

Destroying an Object

If you want a unit to die, a car to explode, a building to collapse, or a bomb to go off, giving the aforementioned objects a variableName, and then using the following code within the trigger's On Activation field should do the trick:

variableName setDammage 1;

Trigger-Activated Waypoints

As opposed to most normal waypoints, some waypoints never get completed on their own when the AI reach their position, and as such, they need something external to activate them. We will most commonly find ourselves using the HOLD and CYCLE waypoints under this premise.

Say we wanted to add a group of enemies that will wait at one position, until a trigger gets activated, to then execute an ambush or a reinforcement. For this, we'd give our group a HOLD waypoint with the characteristics we want. Then, we will right-click and in connect we select Set Waypoint Activation.

If we want to have a group patrol until a trigger is activated, we can follow this same structure, except we sync the CYCLE waypoint to a trigger.

Code Snippets

Init Fields

Here are a few simple lines of code you can safely use to add unique gimmicks to your missions without adding too much complexity onto your workload! This is a compilation list of interesting things to put in an items's init field.

Keeping units grouped and in place

When units are in a group, no matter how you place them in 3DEN, they will return to their formation. If you want to keep them grouped (so that they can relay information to each other), you will want to use the following in the init field of each unit from a group you want to stay in place:

doStop this;

ACE Carry & Drag

Do you want to add extra functionality for items you'd like players to be able to drag, carry, and load into vehicles? Try using any of the following in their init field!

If you want to make an item draggable, use:

[this, true, [0, 1, 0]] call ace_dragging_fnc_setDraggable;

If you want to make an item carryable, use:

[this, true, [0, 1, 0]] call ace_dragging_fnc_setCarryable;

If you want to make an item loadable into vehicles, use:

[this, 1] call ace_cargo_fnc_setSize;

Attaching objects to other objects

If you want to attach an object (1) to another object (2), you can use the following inside object (1)'s init field:

[variableName1, variableName2] call BIS_fnc_attachToRelative;

Automated civilian population

Enabling GRAD CIVS

GRAD CIVS is a useful addon that brings a functionality to make the ambience of a virtual world more lively by populating it with civilians.

If you would like to enable it on your mission, you can go to Settings > Addon Options > Mission and then make sure you tick on the checkbox to Enable GRAD_CIVS.

GRAD CIVS Population types

GRAD CIVS will by default populate the whole world when enabled, however, we can further fine-tune how we want it to handle our civilian population.

To do this, you'll want to place down a Trigger and choose it's size, which will define how much of an area we will affect, then, we will place either a Population zone or an Exclusion zone module from the ´GRAD CIVS´ category.

Placing a Population zone will make GRAD CIVS only spawn civilians in the areas you define, and nowhere else, as opposed to populating the whole map as needed.

Placing an Exclusion zone will prevent GRAD CIVS from spawning civilians within the areas you defined.

GRAD CIVS Transit

If you want to define a main route of transit utilizing GRAD CIVS, you will use the Transit Traffic Source and Transit Traffic Sink modules.

Transit Traffic Source will define where vehicles will spawn and start at, while Transit Traffic Sink will define where vehicles' destination will be and where they will despawn. You will have to Connect > Sync to each Source module to their corresponding Sink module.

GRAD CIVS Presets

To use these presets, go into Settings > Addon Options > Mission, and then click the dropdown menu and find GRAD CIVS.

If you want to define the pedestrians you'd like to be spawned, paste the code in the Unit classes to use for spawning civilians field.

If you want to define the vehicles you'd like the pedestrians to use, paste the code in the Vehicles that civilians may drive (class names) field.

Here are some presets we've made in the past for some of our missions, feel free to use them in yours!

Regional presets

These are presets for specific locations from the Armaverse.

C_man_polo_1_F, C_man_polo_2_F, C_man_polo_3_F, C_man_polo_4_F, C_man_polo_5_F,
C_man_polo_6_F, C_man_polo_1_F_afro, C_man_polo_5_F_afro

C_Hatchback_01_F, C_SUV_01_F, C_Van_01_transport_F, C_Van_01_box_F, C_Offroad_01_F,
C_Offroad_02_unarmed_F, C_Pickup_covered_rf, C_Pickup_rf

C_Man_casual_2_F_euro, C_Man_casual_3_F_euro, C_Man_casual_6_v2_F_euro, 
C_Man_casual_7_F_euro, C_Man_casual_8_F_euro, C_Man_formal_1_F_euro, 
C_Man_formal_4_F_euro, C_scientist_01_informal_F, C_Man_2_enoch_F,
C_Man_3_enoch_F, C_Man_1_enoch_F, C_Farmer_01_enoch_F

C_Truck_02_covered_F, C_Truck_02_fuel_F, C_Offroad_01_F, C_Offroad_01_covered_F,
C_SUV_01_F, C_Van_01_transport_F, C_Van_01_box_F, C_Van_02_vehicle_F, C_Van_02_service_F,
C_Van_02_transport_F, C_Pickup_covered_rf, C_Pickup_rf

C_Djella_01_lxWS, C_Djella_02_lxWS, C_Djella_03_lxWS, C_Djella_04_lxWS,
C_Djella_05_lxWS, C_Tak_02_A_lxWS, C_Tak_02_B_lxWS, C_Tak_02_C_lxWS,
C_Tak_03_A_lxWS, C_Tak_03_B_lxWS, C_Tak_03_C_lxWS, C_Tak_01_A_lxWS,
C_Tak_01_B_lxWS, C_Tak_01_C_lxWS

C_Van_01_transport_F, C_Van_01_box_F, C_Truck_02_flatbed_lxWS, 
C_Truck_02_cargo_lxWS, C_Offroad_01_F, C_Offroad_02_unarmed_F, C_Quadbike_01_F,
C_Offroad_01_covered_F

C_Man_casual_1_F_tanoan, C_Man_casual_2_F_tanoan, C_Man_casual_3_F_tanoan, 
C_Man_casual_4_v2_F_tanoan, C_Man_casual_5_v2_F_tanoan, C_Man_casual_6_v2_F_tanoan,
C_Man_casual_7_F_tanoan, C_Man_casual_9_F_tanoan, C_Man_casual_8_F_tanoan, 
C_man_sport_1_F_tanoan, C_man_sport_2_F_tanoan, C_man_sport_3_F_tanoan, 
C_Man_casual_4_F_tanoan, C_Man_casual_5_F_tanoan, C_Man_casual_6_F_tanoan

C_Hatchback_01_F, C_SUV_01_F, C_Van_01_transport_F, C_Van_01_box_F,
C_Offroad_01_F, C_Offroad_02_unarmed_F, C_Pickup_covered_rf, C_Pickup_rf

Service presets

These are presets for civilian service-related factions.

C_IDAP_Man_AidWorker_01_F, C_IDAP_Man_AidWorker_07_F,
C_IDAP_Man_AidWorker_08_F, C_IDAP_Man_AidWorker_09_F,
C_IDAP_Man_AidWorker_02_F, C_IDAP_Man_AidWorker_05_F,
C_IDAP_Man_AidWorker_06_F, C_IDAP_Man_AidWorker_04_F,
C_IDAP_Man_AidWorker_03_F

C_IDAP_Offroad_02_unarmed_F, C_IDAP_Truck_02_transport_F,
C_IDAP_Truck_02_F, C_IDAP_Truck_02_water_F,
C_IDAP_Offroad_01_F, C_IDAP_Van_02_vehicle_F,
C_IDAP_Van_02_transport_F, C_IDAP_Pickup_rf,
C_IDAP_Pickup_covered_rf, C_IDAP_Pickup_water_rf

Generic presets

These are generic presets to be used when unsure or to mix-and-match based on the needs of the mission.

Pedestrians

C_Man_casual_1_F_afro, C_Man_casual_2_F_afro,
C_Man_casual_3_F_afro, C_Man_casual_4_v2_F_afro,
C_Man_casual_5_v2_F_afro, C_Man_casual_6_v2_F_afro

C_man_polo_1_F_afro, C_man_polo_2_F_afro,
C_man_polo_3_F_afro, C_man_polo_4_F_afro,
C_man_polo_5_F_afro, C_man_polo_6_F_afro

C_man_polo_1_F_afro_sick, C_man_polo_2_F_afro_sick,
C_man_polo_3_F_afro_sick, C_man_polo_6_F_afro_sick

C_Man_casual_1_F_asia, C_Man_casual_2_F_asia,
C_Man_casual_3_F_asia, C_Man_casual_4_v2_F_asia,
C_Man_casual_5_v2_F_asia, C_Man_casual_6_v2_F_asia

C_man_polo_1_F_asia, C_man_polo_2_F_asia,
C_man_polo_3_F_asia, C_man_polo_4_F_asia,
C_man_polo_5_F_asia, C_man_polo_6_F_asia

C_Man_casual_1_F_euro, C_Man_casual_2_F_euro,
C_Man_casual_3_F_euro, C_Man_casual_4_v2_F_euro,
C_Man_casual_5_v2_F_euro, C_Man_casual_6_v2_F_euro

C_man_polo_1_F_euro, C_man_polo_2_F_euro,
C_man_polo_3_F_euro, C_man_polo_4_F_euro,
C_man_polo_5_F_euro, C_man_polo_6_F_euro

C_man_1_persian_F, C_Man_2_persian_F,
C_Man_3_persian_F, C_Man_4_persian_F,
C_Man_5_persian_F, C_Man_6_persian_F,
C_Man_8_persian_F, C_Man_9_persian_F

Vehicles

C_Hatchback_01_F, C_Offroad_02_unarmed_F,
C_Pickup_rf, C_Pickup_covered_rf,
C_Van_02_vehicle_F, C_Van_02_transport_F, C_SUV_01_F

C_Truck_02_transport_F, C_Truck_02_covered_F,
C_Tractor_01_F, C_Offroad_01_F, C_Van_01_transport_F,
C_Van_01_box_F, C_Quadbike_01_F

If you want to define a chance for your pedestrians to use backpacks, paste the code below in the Backpacks that civilians may wear field.

B_Messenger_Black_F, B_Messenger_Coyote_F, B_Messenger_Gray_F,
B_Messenger_Olive_F, B_CivilianBackpack_01_Everyday_Black_F,
B_CivilianBackpack_01_Sport_Blue_F, B_CivilianBackpack_01_Sport_Green_F,
B_CivilianBackpack_01_Sport_Red_F