Campaign Description.ext: Difference between revisions

From Bohemia Interactive Community
Jump to navigation Jump to search
(work in progress)
 
m (Some wiki formatting)
(35 intermediate revisions by 6 users not shown)
Line 1: Line 1:
==Caveat==
{{TOC|side}}


Two types of description.ext file exist in the flashpoint world
A campaign's '''Description.ext''' is the entry point to load a campaign's information; the campaign title, author and overview picture, the missions tree, everything displayed from the Campaigns screen is defined in it.


#Mission Descriptions.
It must be well written to ensure a good campaign experience, as the flow of missions is defined in this file (a.k.a which mission should be played on which ending).
#Campaign Descriptions.
This config file can be accessed through [[campaignConfigFile]].


'''They have nothing in common with each other'''
A campaign file (''myCampaign.pbo'') should need no other file to work!


If you are looking for the nitty gritty of description.ext in ''missions'', you are in the wrong place.
{{Feature|important|A wrongly formatted campaign's Description.ext can crash your game!}}


==Intro==
{{Feature|Informative|This page is about a campaign's Description.ext. For the mission version, please go to [[Description.ext]].}}


Compared to the effort of creating any single mission, the effort to house them in a campaign is trivial. This document is intensely detailed. Most of it you dont need to successfully write excellent campaigns. Here's what you need to know:


MyGreatCampaign/ '''folder''' contains <u>everything</u> to do with your campaign.
== Campaign directory structure ==
MyGreatCampaign/ lives inside the ~/Campaigns directory of ofp. (or one of it's mods)
There are no other gotcha's, no other 'places' where you have to modify ofp to play MyGreatCampaign.
.
  The <u>sequence</u> of missions is defined in the '''description.ext''' file in '''this''' folder.
.
  A Mission'''S'''/ folder, within MyGreatCampaign/ folder contains all the mission folders.
.
  <u>All</u> of of your individual missions go into this Mission'''S'''/ folder.
  There are no files in this Mission'''S'''/ folder, only individual mission folders.
  Each 'mission' is in it's own, <u>arbitrarily</u> named directory, within this Mission'''S'''/ directory
.
    The content of <u>any</u> mission folder is an <u>exact</u> copy of what they were, played as single missions.
    No changes
    No alterations
    No additions


A campaign structure is the following:
myCampaignDirectory
myCampaignDirectory\'''description.ext'''
myCampaignDirectory\mission'''s'''
myCampaignDirectory\mission'''s'''\mission01.VR
myCampaignDirectory\mission'''s'''\mission02.VR
(…)


Other files may appear at the root of myCampaignDirectory for sharing resources between missions, or storing the campaign overview image for example.
No files should appear in myCampaignDirectory\mission'''s''', only mission directories. Mission names do not matter nor impact the missions flow. ''Zmission.VR'' will not load after ''Amission.VR'' for example. The order is, again, defined in the '''description.ext''' file.


MyGreatCampaign/ directory contains only a few ( but identical in intent) files that single mission folders have:
{{Feature | Informative | You may have to manually create the '''''arma3rootDir''\Campaigns''' directory.}}


Overview (html and jpeg)
description.ext


''As a convenience'', other files ''might'' exist in this folder. Their purpose is to provide a global radio, global sounds, global language definitions. They are no different in content or purpose than those in any mission folder and are not covered here. If you put them in, it's because you want to refer to a common set of radio messages for many missions. A common way of saying "get down", in six languages.
== Missions flow ==


A campaign folder does '''not''' contain a mission.sqm. There is no 'mission'., there are Missions/
Missions flow structure is defined as follows:
===The Glue===
* The parent class is Campaign, nothing else.
* Campaign is filled with chapters
* Chapters are filled with missions and defined endings
* Missions are filled with endings.


Description.ext in the MyGreatCampaign/ directory is the glue that sequences which mission to play next. It does contain other niceties such as rewards and faces, but sequencing is it's essential purpose.
{{Feature|important|Campaign class cannot contain mission classes directly!}}


Like mission.sqm, like config.cpp, description.ext is a ''TokenClass'' file.
* A campaign contains one to many chapters, and '''must''' define a parameter named '''firstBattle''' pointing to its first chapter.
* A chapter contains one to many missions, and '''must''' define a parameter named '''firstMission''' pointing to its first mission.
* A mission must define its endings. A mission with an empty defined ending will follow its chapter ending.


The organisation of a description.ext is as follows;
=== Campaign ===


campaign
This is the main class for missions flow definition. It is defined as follows:
{
<syntaxhighlight lang="cpp">
  chapter1    {missions...};
class Campaign // this is a reference class, the name cannot be customised
  chapter2    {missions...};
{
  chapterlast {missions...};
firstBattle = Chapter1; // which chapter should be loaded first. MUST be declared!
};


Only one campaign class exists. The name of this class is fixed as 'campaign'
name = "my great campaign"; // before Arma 3
briefingName = "my Arma 3 campaign"; // since Arma 3 - if undefined, an error popup will appear
author = "Username"; // since Arma 3 - if undefined, "by unknown community author" will replace author's name
overviewPicture = "overview.paa";
overviewText = "$STR_A3_StageAOverview";
disableMP = 1; // since Arma 2 - if set to 1, forces the campaign as SinglePlayer
enableHub = 1; // TBD - has to do with coming back to a "base"
(…)
};
</syntaxhighlight>


At least one chapter exists. '''Most campaigns only have one chapter.'''
=== Chapters ===


Many missions might exist (in each chapter)
A chapter is defined inside [[#Campaign|Campaign]] block.
Multiple chapters can exist inside Campaign block. A chapter is defined as follows:
<syntaxhighlight lang="cpp">
class Chapter1 // name can be customised here - it will be used as reference, in Campaign's {{hl|firstBattle}} for example
{
firstMission = Mission1; // which mission should be loaded first. MUST be declared!
name = "My first chapter"; // chapter name. Has no in-game impact
cutscene = Chapter1Cutscene.VR; // in the *missions* sub-directory. A cutscene is of course optional but the parameter MUST be declared (cutscene = ;)
end1 = ;
(…)
};
</syntaxhighlight>


All missions from all chapters are in the unitary Missions/ directory.
There can be multiple chapters in a campaign, but this is optional. Campaign missions can very well be contained within a single chapter.
Chapters are used for campaign organisation as well as adding some transition cutscenes.


The order of chapters and missions are unimportant!
=== Missions ===


There is '''NO''' default behaviour where chapter 1 will "fall thru" to the next chapter. <u>Each and every chapter<u> and <u>each and every mission</u> must be specifically targeted.
A mission is defined inside [[#Chapters|a chapter]] and must target one of the '''missions''' sub-directories.
Multiple missions can be inside a chapter. A mission is defined as follows:
<syntaxhighlight lang="cpp">
class myMission1 // name can be customised too
{
end1 = myMission2; // next mission's classname
end2 = myMission3a;
end3 = myMission3b;
end4 = myMission2;
end5 = ;
end6 = ;
lost = myMission1;


The names given to the chapters and missions are '''arbitrary''', but generally reflect the name of the associated mission folders
template = myMissionDirectory.VR; // the mission directory itself, placed in the /missions/ sub-directory
};
</syntaxhighlight>


===Campaign Class Fundamentals===
{{Feature | Informative | Mission directories that are not declared anywhere in description.ext (such as mission or cutscene) are simply ignored.}}
====Campaign class basics====
The campaign class is a container. It contains chapters, which contain missions.


The chapter and mission classes within the campaign class rely on inheritance. The intent of inheritance is to provide fall thru behavior. Ie, what to do when nothing's specifically been said to do. It is specifically geared to end a chapter or a complete mission, or allow a cut scene to do it's thing (not do anything player wise). Thus, the very first class declared goes something like this
{{ArgTitle|4|cutscene|{{GVI|ofp|1.00}}}}
Define a cutscene mission directory that will be played before the mission. The cutscene won't appear in missions list in the campaign screen.


class NoEndings
{{ArgTitle|4|end1-6, lost|{{GVI|ofp|1.00}}}}
{  
These ''end%'' and ''lost'' parameters are used to define which mission is next. An empty ending (<syntaxhighlight lang="cpp" inline>end1 = ;</syntaxhighlight>) will end the current chapter.
  lost = ;
{{Feature|arma3|
  end1 = ;  
''end1-6'' and ''lost'' are '''optional''' in {{arma3}}.
  end2 = ;
Since custom ending names can be used in {{arma3}} now (<sqf inline>"myCustomEnd" call BIS_fnc_endMission;</sqf> for example)
  end3 = ;
you can use your own custom name here (e.g <syntaxhighlight lang="cpp" inline>myCustomEnd = nextMission;</syntaxhighlight>).
  end4 = ;  
}}
  end5 = ;
  end6 = ;  
};


Chapters, the overall campaign itself, some missions, have nothing further to do (other than exit completely, or exit the chapter). Chapters, missions, the campaign itself will inherit this class (when programmed to do so). This saves you specifically declaring all possible outcomes for each mission,  when only a few are needed.
{{ArgTitle|4|endDefault|{{GVI|arma3|1.00}}}}
Fallback value in case an undefined ending is used, avoiding the game to crash.
<syntaxhighlight lang="cpp">
endDefault = ; // valid
</syntaxhighlight>


Typically, in single player campaigns, you aint gonna die forever. You will live to fight the mission again. Thus
{{ArgTitle|4|repeat|{{GVI|arma3|1.00}}}}
''Allow mission to repeat?''
<syntaxhighlight lang="cpp">
repeat = 1; // 0: disabled - 1: enabled. Default: 0
</syntaxhighlight>


class MissionDefault : NoEndings
{{ArgTitle|4|isHub|{{GVI|arma3|1.00}}}}
{
Define a mission to be hub. May have to do with '''CfgHubs'''.
  lives = -1;
<syntaxhighlight lang="cpp">
};
isHub = 1; // 0: disabled - 1: enabled. Default: 0
</syntaxhighlight>


The name MissionDefault and all names for all classes are arbitrary, "MissionDefault" is an accepted de-facto standard name for missions to inherit. Left to itself, simply inheriting the mission default means you will exit the game at end of mission/chapter. Indeed the last chapter (if any) last mission, does exactly this. But, almost all classes that 'inherit' MissionDefault will modify some or most of those mission defaults. The intent is to stop tedious typing for every mission.


class Mission123 : MissionDefault
== Description.fsm ==
{
// some body text
};


What happens here is that this mission (and almost all missions do this) inherit defaults for anything not specifically over-ridden in the body text. For a clearer understanding, not only will the mission obtain lives = -1, but also grab ending defaults.
Since {{arma3}}, an [[FSM]] (compiled with "campaignFSMA3.cfg" FSM config) can be included in a chapter (here named "Missions"):
<spoiler text="Show Example">
<syntaxhighlight lang="cpp">
// East Wind's Description.ext


class Campaign
weaponPool = 1;
{


the campaign class is a containing class. It 'contains' all of the chapters making up the campaign!.
class Campaign
{
name = "$STR_A3_CampaignName";
firstBattle = Missions;
disableMP = 1;
enableHub = 1;


this class (which must be called 'Campaign') declares the title of this campaign and which chapter to Start.
briefingName = "$STR_A3_CampaignName";
author = "$STR_A3_Bohemia_Interactive";
overviewPicture = "a3\Missions_F_EPA\data\img\Campaign_overview_CA.paa";
overviewText = "$STR_A3_StageAOverview";


  name = "My Great Campaign";
class MissionDefault
  firstBattle = Chapter1;
{
  class chapter1 {.....};
lives = -1;
  class chapter2 {.....};
      and so on...
};


class ChapterN
lost = ;
end1 = ;
end2 = ;
end3 = ;
end4 = ;
end5 = ;
end6 = ;
};


Chapters are a containing class. Their intent is to compartmentalize the various missions you have into some semblance of sanity. One such example would be to put all Everon missions in one chapter, all Nogova missions in another.
class Missions
{
name = "The Beginning";
cutscene = ;
firstMission = A_in;
end1 = ;
end2 = ;
end3 = ;
end4 = ;
end5 = ;
end6 = ;
lost = ;


At least one chapter must exist in a campaign. It need be the only one, and it can contain all missions, should you wish it that way.
/*#define _DISABLE_DESCRIPTION 1*/
The name of any chapter class is arbitrary one such example would be NogovaChapter


name = "Chapter I - Battles For Spaghetti Island";
#define _CAMPAIGN 1
cutscene = MyGreatCutscene.Noe; // a cutscene is optinal
class mission1{....};
class mission2{...};
  and so on...
};


Note that a cutscene is no different to any other 'mission'. It is a mission folder like any other.
#include "description.fsm" // here is the FSM
};
};
</syntaxhighlight>
</spoiler>
{{Feature | Informative | FSM information found in description.fsm:
'''PROJECT SPLENDID'''<br>
'''CAMPAIGN FSM'''
* State names are mission classes
* Condition names can be anything (even empty)
* Condition "conditions" field can contain code which has to return true in order to make the mission available.<br><!--
-->Other missions' classes can be used as variables.<br><!--
-->Empty field returns true by default}}


class MissionX
The FSM entry point (titled "A_in1") contains the following data:
{
<syntaxhighlight lang="cpp">
endDefault = A_in2;
noWeaponPool = 1;
isIntro = 1;
</syntaxhighlight>


Most mission folders (in the missions directory) have a corresponding mission classes. The name of each mission class should closely correspond to the name of each mission folder to preserve your sanity. Those missions folders not declared as mission classes are cutscenes.
These are usual config entries that could be found in a normal config. Other possible values found:
<syntaxhighlight lang="cpp">
isHub = 1;
isHubMission = 1;
isOutro = 1;
isSkirmish = 1;
repeat = 1;
</syntaxhighlight>


Mission folders that are not declared anywhere in description.ext have no ill effect, they are simply ignored.


== Root parameters ==


The mission class
{{Feature|important|Additional root parameters must be placed '''outside''' the [[#Campaign|Campaign class]] to be effective!}}
The Chapter class
===The campaign class===


Declare a MissionDefault class as above
{{ArgTitle|4|directory|{{GVI|arma3|1.00}}}}
Define the campaign directory, used when campaign is part of an addon.
<syntaxhighlight lang="cpp">
directory = "A3\Missions_F_EPA\Campaign";
</syntaxhighlight>


Next decide to use either a single chapter, or, multiple chapters in your campaign. Multiple chapters have the 'benefit' of easier-to-handle cutscenes, a potentially nicer fade in and out between chapters, but dont matter muchly. Very few, if any, user inspired campaigns have multiple chapters.
{{ArgTitle|4|filterGroup|{{GVI|arma3|1.00}}}}
''Usage unknown.''
<syntaxhighlight lang="cpp">
filterGroup = 3;
</syntaxhighlight>


===Single Chapter Campaign===
{{ArgTitle|4|weaponPool|{{GVI|ofpr|1.75}}}}
A single chapter campaign looks as follows
A campaign automatically enables [[:Category:Command Group: Weapon Pool|weapon pool]].
This parameter allows equipment transferred from one campaign mission to the next to be available during the briefing in the gear menu.
<syntaxhighlight lang="cpp">
weaponPool = 1; // 0: disabled - 1: enabled. Default: 0
</syntaxhighlight>


class Campaign
{
    name = "My Great Campaign";
    firstBattle = Chapter1;    // might be the only chapter
    class Chapter1 : NoEndings
    {
      name = "Chapter1 Fighting for Everon";
      cutscene = AGreatCutscene.Eden;    // if any
      firstMission = FirstMission;
      class FirstMission: MissionDefault
      {
        // ending commands
      };
      class MissionN: MissionDefault
      {
        // ending commands
      };
      class LastMission: MissionDefault
      {
        // NO ending commands
      };
    }; // end of this chapter
};    // end of this campaign


when chapter1 ends, the game ends via : NoEndings
== Full example ==


There are no over-rides provided for endings in chapter one, hence when the chapter ends, the campaign ends.
<syntaxhighlight lang="cpp">
/*
"MissionDefault", "NoEndings" etc. are arbitrary class names. MissionDefault is Bohemia standard name for missions parent class.
Left to itself, simply inheriting the mission default means you will exit the game at the end of mission/chapter (and will be done on last(s) mission(s).


Throughout, unless endings 1 to 6 and loose are declared for each and every chapter and mission, when the time comes for ofp to go look for them, it will crash. This is, the primary use of inheritance.
An end that is used but not defined (e.g "end6") WILL crash the game.
*/
class NoEndings
{
// Arma 3
endDefault = ;


===MultiChapter Campaign===
// pre-Arma 3
A multi chapter campaign looks as follows
end1 = ;
end2 = ;
end3 = ;
end4 = ;
end5 = ;
end6 = ;
lost = ;
};


class Campaign
class MissionDefault : NoEndings
{
{
    name = "My Great Campaign";
lives = -1; // this sets your "lives" to none - old OFP setting where you would lose a "life" every time you retried the mission, never used
    firstBattle = Chapter1;   
noAward = 1; // TBD
    class Chapter1 : NoEndings
cutscene = ; // mandatory definition
    {
};
        end1 = NextChapter;
        end2 = NextChapter;
        end3 = NextChapter;
        end4 = NextChapter;
        end5 = NextChapter;
        end5 = NextChapter;
        loose= NextChapter;
        ... missions etc
    };
    class NextChapter : NoEndings
    {
        end1 = LastChapter ;
        ...... missions etc
    };
    class LastChapter : NoEndings
    {
        // no endings provided
        missions etc
    };
};


The difference is that each chapter (except the last) defines another chapter to go to. Like missions, over-riding all endings (1..6) make no difference if they aren't used. The inheritance therefore of : NoEndings is superfluous but hopefully makes the above clearer in content.
// additional parameters go here
weaponPool = 1;


The order of Chapters (the top to bottom definition of them) is not important. Chapter one can jump to 3 to 2 to 7 to 5.
class Campaign
{
name = "My Great Campaign"; // before Arma 3
briefingName = "My Great Campaign"; // since Arma 3
author = "John Doe";
overviewText = "You are a soldier on an island. Try killing the enemies and not dying to survive.";


Nor is the name of the chapter class important, other than
firstBattle = Chapter1;
disableMP = 0; // this campaign is multiplayer-compatible


end1= MustGotoThisChapterClassName;
class Chapter1 : NoEndings
{
firstMission = Chapter1_Mission1;
end1 = Chapter2; // other endings are defined by inheritance from NoEndings


It is, as simple as that.
class Chapter1_Mission1 : MissionDefault
{
end1 = Chapter1_Mission2; // other endings are defined by inheritance from MissionDefault, inheriting from NoEndings
end2 = ; // end2 will end Chapter 1, therefore going to Chapter 2
template = C1M1.VR;
};
class Chapter1_Mission2 : MissionDefault
{
end1 = ; // not defining the ending will use the Chapter ending corresponding to end1: Chapter2 here
template = C1M2.VR;
};
};
 
class Chapter2 : NoEndings
{
firstMission = Chapter2_Mission1;
end1 = LastChapter;
 
// this mission is named Chapter2_Mission1 for clarity purpose,
// but both Chapter1_Mission1 and Chapter2_Mission1 could have been named Mission1 as game engine respects Chapter hierarchy.
// do not, however, name two missions the same -in the same chapter-
class Chapter2_Mission1 : MissionDefault
{
end1 = ; // not defining the ending will use the Chapter ending corresponding to end1: LastChapter here
template = C2M1.VR;
};
};
 
class LastChapter : NoEndings
{
firstMission = Chapter3_Mission1;
// no endings provided: because of NoEndings inheritance this is the same as writing 'endDefault = ;'
class Chapter3_Mission1
{
// not defining the ending will use the Chapter ending corresponding to end1: NOTHING here, closing the campaign
template = C3M1.VR;
};
};
};
</syntaxhighlight>
 
 
== Recommendations ==
 
If you don't know for sure what you are doing, follow these advices:
* try and make all the missions work stand-alone, then place them all in the '''Missions''' directory
* don't force yourself to use many chapters. They are useful to organise properly a lot of missions, but if your campaign doesn't have many, don't oversplit it.
* you can test your campaign structure by allowing file patching (in [[Arma 3: Launcher|{{arma3}} launcher]], or ''arma3.exe -filePatching'') and placing your campaign in the ''campaign'''s''''' directory
 
 
[[Category:Mission Editing]]

Revision as of 22:24, 13 March 2023

A campaign's Description.ext is the entry point to load a campaign's information; the campaign title, author and overview picture, the missions tree, everything displayed from the Campaigns screen is defined in it.

It must be well written to ensure a good campaign experience, as the flow of missions is defined in this file (a.k.a which mission should be played on which ending). This config file can be accessed through campaignConfigFile.

A campaign file (myCampaign.pbo) should need no other file to work!

A wrongly formatted campaign's Description.ext can crash your game!
This page is about a campaign's Description.ext. For the mission version, please go to Description.ext.


Campaign directory structure

A campaign structure is the following:

myCampaignDirectory
myCampaignDirectory\description.ext
myCampaignDirectory\missions
myCampaignDirectory\missions\mission01.VR
myCampaignDirectory\missions\mission02.VR
(…)

Other files may appear at the root of myCampaignDirectory for sharing resources between missions, or storing the campaign overview image for example. No files should appear in myCampaignDirectory\missions, only mission directories. Mission names do not matter nor impact the missions flow. Zmission.VR will not load after Amission.VR for example. The order is, again, defined in the description.ext file.

You may have to manually create the arma3rootDir\Campaigns directory.


Missions flow

Missions flow structure is defined as follows:

  • The parent class is Campaign, nothing else.
  • Campaign is filled with chapters
  • Chapters are filled with missions and defined endings
  • Missions are filled with endings.
Campaign class cannot contain mission classes directly!
  • A campaign contains one to many chapters, and must define a parameter named firstBattle pointing to its first chapter.
  • A chapter contains one to many missions, and must define a parameter named firstMission pointing to its first mission.
  • A mission must define its endings. A mission with an empty defined ending will follow its chapter ending.

Campaign

This is the main class for missions flow definition. It is defined as follows:

class Campaign // this is a reference class, the name cannot be customised
{
	firstBattle	= Chapter1;						// which chapter should be loaded first. MUST be declared!

	name			= "my great campaign";		// before Arma 3
	briefingName	= "my Arma 3 campaign";		// since Arma 3 - if undefined, an error popup will appear
	author			= "Username";				// since Arma 3 - if undefined, "by unknown community author" will replace author's name
	overviewPicture	= "overview.paa";
	overviewText	= "$STR_A3_StageAOverview";
	disableMP		= 1;						// since Arma 2 - if set to 1, forces the campaign as SinglePlayer
	enableHub		= 1;						// TBD - has to do with coming back to a "base"
	()
};

Chapters

A chapter is defined inside Campaign block. Multiple chapters can exist inside Campaign block. A chapter is defined as follows:

class Chapter1 // name can be customised here - it will be used as reference, in Campaign's {{hl|firstBattle}} for example
{
	firstMission	= Mission1;				// which mission should be loaded first. MUST be declared!
	name			= "My first chapter";	// chapter name. Has no in-game impact
	cutscene		= Chapter1Cutscene.VR;	// in the *missions* sub-directory. A cutscene is of course optional but the parameter MUST be declared (cutscene = ;)
	end1			= ;
	()
};

There can be multiple chapters in a campaign, but this is optional. Campaign missions can very well be contained within a single chapter. Chapters are used for campaign organisation as well as adding some transition cutscenes.

Missions

A mission is defined inside a chapter and must target one of the missions sub-directories. Multiple missions can be inside a chapter. A mission is defined as follows:

class myMission1 // name can be customised too
{
	end1 = myMission2; // next mission's classname
	end2 = myMission3a;
	end3 = myMission3b;
	end4 = myMission2;
	end5 = ;
	end6 = ;
	lost = myMission1;

	template = myMissionDirectory.VR; // the mission directory itself, placed in the /missions/ sub-directory
};
Mission directories that are not declared anywhere in description.ext (such as mission or cutscene) are simply ignored.

cutscene

Define a cutscene mission directory that will be played before the mission. The cutscene won't appear in missions list in the campaign screen.

end1-6, lost

These end% and lost parameters are used to define which mission is next. An empty ending (end1 = ;) will end the current chapter.

Arma 3
end1-6 and lost are optional in Arma 3.

Since custom ending names can be used in Arma 3 now ("myCustomEnd" call BIS_fnc_endMission; for example)

you can use your own custom name here (e.g myCustomEnd = nextMission;).

endDefault

Fallback value in case an undefined ending is used, avoiding the game to crash.

endDefault = ; // valid

repeat

Allow mission to repeat?

repeat = 1; // 0: disabled - 1: enabled. Default: 0

isHub

Define a mission to be hub. May have to do with CfgHubs.

isHub = 1; // 0: disabled - 1: enabled. Default: 0


Description.fsm

Since Arma 3, an FSM (compiled with "campaignFSMA3.cfg" FSM config) can be included in a chapter (here named "Missions"):

// East Wind's Description.ext

weaponPool = 1;

class Campaign
{
	name = "$STR_A3_CampaignName";
	firstBattle = Missions;
	disableMP = 1;
	enableHub = 1;

	briefingName = "$STR_A3_CampaignName";
	author = "$STR_A3_Bohemia_Interactive";
	overviewPicture = "a3\Missions_F_EPA\data\img\Campaign_overview_CA.paa";
	overviewText = "$STR_A3_StageAOverview";

	class MissionDefault
	{
		lives = -1;

		lost = ;
		end1 = ;
		end2 = ;
		end3 = ;
		end4 = ;
		end5 = ;
		end6 = ;
	};

	class Missions
	{
		name = "The Beginning";
		cutscene = ;
		firstMission = A_in;
		end1 = ;
		end2 = ;
		end3 = ;
		end4 = ;
		end5 = ;
		end6 = ;
		lost = ;

		/*#define _DISABLE_DESCRIPTION	1*/

		#define _CAMPAIGN 1

		#include "description.fsm" // here is the FSM
	};
};
↑ Back to spoiler's top

FSM information found in description.fsm:

PROJECT SPLENDID
CAMPAIGN FSM

  • State names are mission classes
  • Condition names can be anything (even empty)
  • Condition "conditions" field can contain code which has to return true in order to make the mission available.
    Other missions' classes can be used as variables.
    Empty field returns true by default

The FSM entry point (titled "A_in1") contains the following data:

endDefault = A_in2;
noWeaponPool = 1;
isIntro = 1;

These are usual config entries that could be found in a normal config. Other possible values found:

isHub = 1;
isHubMission = 1;
isOutro = 1;
isSkirmish = 1;
repeat = 1;


Root parameters

Additional root parameters must be placed outside the Campaign class to be effective!

directory

Define the campaign directory, used when campaign is part of an addon.

directory = "A3\Missions_F_EPA\Campaign";

filterGroup

Usage unknown.

filterGroup = 3;

weaponPool

A campaign automatically enables weapon pool. This parameter allows equipment transferred from one campaign mission to the next to be available during the briefing in the gear menu.

weaponPool = 1; // 0: disabled - 1: enabled. Default: 0


Full example

/*
	"MissionDefault", "NoEndings" etc. are arbitrary class names. MissionDefault is Bohemia standard name for missions parent class.
	Left to itself, simply inheriting the mission default means you will exit the game at the end of mission/chapter (and will be done on last(s) mission(s).

	An end that is used but not defined (e.g "end6") WILL crash the game.
*/
class NoEndings
{
	// Arma 3
	endDefault = ;

	// pre-Arma 3
	end1 = ;
	end2 = ;
	end3 = ;
	end4 = ;
	end5 = ;
	end6 = ;
	lost = ;
};

class MissionDefault : NoEndings
{
	lives		= -1;	// this sets your "lives" to none - old OFP setting where you would lose a "life" every time you retried the mission, never used
	noAward		=  1;	// TBD
	cutscene	= ;		// mandatory definition
};

// additional parameters go here
weaponPool		= 1;

class Campaign
{
	name			= "My Great Campaign";	// before Arma 3
	briefingName	= "My Great Campaign";	// since Arma 3
	author			= "John Doe";
	overviewText	= "You are a soldier on an island. Try killing the enemies and not dying to survive.";

	firstBattle	= Chapter1;
	disableMP	= 0; // this campaign is multiplayer-compatible

	class Chapter1 : NoEndings
	{
		firstMission = Chapter1_Mission1;
		end1 = Chapter2; // other endings are defined by inheritance from NoEndings

		class Chapter1_Mission1 : MissionDefault
		{
			end1 = Chapter1_Mission2;	// other endings are defined by inheritance from MissionDefault, inheriting from NoEndings
			end2 = ;					// end2 will end Chapter 1, therefore going to Chapter 2
			template = C1M1.VR;
		};
		class Chapter1_Mission2 : MissionDefault
		{
			end1 = ; // not defining the ending will use the Chapter ending corresponding to end1: Chapter2 here
			template = C1M2.VR;
		};
	};

	class Chapter2 : NoEndings
	{
		firstMission = Chapter2_Mission1;
		end1 = LastChapter;

		// this mission is named Chapter2_Mission1 for clarity purpose,
		// but both Chapter1_Mission1 and Chapter2_Mission1 could have been named Mission1 as game engine respects Chapter hierarchy.
		// do not, however, name two missions the same -in the same chapter-
		class Chapter2_Mission1 : MissionDefault
		{
			end1 = ; // not defining the ending will use the Chapter ending corresponding to end1: LastChapter here
			template = C2M1.VR;
		};
	};

	class LastChapter : NoEndings
	{
		firstMission = Chapter3_Mission1;
		// no endings provided: because of NoEndings inheritance this is the same as writing 'endDefault = ;'
		class Chapter3_Mission1
		{
			// not defining the ending will use the Chapter ending corresponding to end1: NOTHING here, closing the campaign
			template = C3M1.VR;
		};
	};
};


Recommendations

If you don't know for sure what you are doing, follow these advices:

  • try and make all the missions work stand-alone, then place them all in the Missions directory
  • don't force yourself to use many chapters. They are useful to organise properly a lot of missions, but if your campaign doesn't have many, don't oversplit it.
  • you can test your campaign structure by allowing file patching (in Arma 3 launcher, or arma3.exe -filePatching) and placing your campaign in the campaigns directory