Campaign Description.ext: Difference between revisions

From Bohemia Interactive Community
Jump to navigation Jump to search
m (Page rewriting. TODO: add more info and more parameters)
Line 1: Line 1:
[[category:Operation Flashpoint: Editing]]
{{note|this page is about '''Campaign Description.ext'''. For the mission version, please go to [[Description.ext]].}}


==Caveat==
== Description ==
A campaign description.ext is the entry point to load campaign informations. It must '''not''' be confused with mission [[Description.ext]].
The campaign title, author and overview picture, the missions tree, everything displayed from the Campaigns screen will be loaded from it.


Two types of description.ext file exist in the flashpoint world
It is important to be well written to ensure a good campaign experience.
The flow of missions is defined in this file (aka which mission should be played on which ending).


#Mission Descriptions.
A campaign file (''myCampaign.pbo'') should need no other file to work (beside base game files and required mods)!
#Campaign Descriptions.


'''They have nothing in common with each other'''
{{Important|A wrongly formatted Campaign Description.ext can crash your game!}}


If you are looking for the nitty gritty of description.ext in ''missions'', you should go [[Description.ext|here]].


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


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:
Other files may appear at the root of myCampaignMainDirectory for sharing resources between missions, or storing the campaign overview image for example.
No files should appear in myCampaignMainDirectory\mission'''s''' , only mission directories
Missions name doesn't matter nor impact the missions flow. ''Zmission.VR'' will '''not''' load after ''Amission.VR'' – the order is, again, defined in description.ext.


MyGreatCampaign/ '''folder''' contains <u>everything</u> to do with your campaign.
{{note|You may have to manually create '''''arma3rootDir''\Campaigns'''}}
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


MyGreatCampaign/ directory contains only a few ( but identical in intent) files that single mission folders have:
== Missions flow ==
Missions flow structure is defined as follows:
# Campaign, filled with chapters
# Chapters, filled with missions
# Missions, filled with endings.


Overview (html and jpeg)
{{Important|Campaign cannot contain missions directly!}}
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.
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.


A campaign folder does '''not''' contain a mission.sqm. There is no 'mission'., there are Missions/
==The Glue==


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.
=== Campaign ===
 
This is the main class for missions flow definition. It is defined as follows:
Like mission.sqm, like config.cpp, description.ext is a ''TokenClass'' file.
class Campaign {{codecomment|// this is a reference class and the name '''cannot''' be customised}}
 
The organisation of a description.ext is as follows;
 
campaign
  {
  {
  chapter1    {missions...};
'''firstBattle = Chapter1;''' {{codecomment|// which chapter should be loaded first. '''MUST''' be declared!}}
  chapter2    {missions...};
  chapterlast {missions...};
name = "my great campaign"; {{codecomment|// before Arma 3}}
briefingName = "my Arma 3 campaign"; {{codecomment|// Arma 3 - if undefined, an error popup will appear}}
author = "Username"; {{codecomment|// Arma 3 - if undefined, "by unknown community author" will replace author's name}}
''weaponPool = 1;'' {{codecomment|// since OFP:R v1.75: allows weapon pool to be used in mission briefing}}
(…)
  };
  };


Only one campaign class exists. The name of this class is fixed as 'campaign'
At least one chapter exists. '''Most campaigns only have one chapter.'''
Many missions might exist (in each chapter)
All missions from all chapters are in the unitary Missions/ directory.
The order of chapters and missions are unimportant!
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.
The names given to the chapters and missions are '''arbitrary''', but generally reflect the name of the associated mission folders
==Campaign Class Fundamentals==
===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, at close to top of file, you will see something like this:
=== Chapters ===
 
A chapter is defined inside [[#Campaign|Campaign]] block.
class NoEndings
Multiple chapters can exist inside Campaign block. A chapter is defined as follows:
{
  class Chapter1 {{codecomment|// name can be customised here - it will be used as reference, in firstBattle for example}}
  lost = ;
  end1 = ;
  end2 = ;
  end3 = ;
  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.
 
Typically, in single player campaigns, you aint gonna die forever. You will live to fight the mission again. Thus
 
  class MissionDefault : NoEndings
{  
  lives = -1;
};
 
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
  {
  {
// some body text
'''firstMission = Mission1;''' {{codecomment|// which mission should be loaded first. '''MUST''' be declared!}}
name = "My first chapter"; {{codecomment|// chapter name. Has no in-game impact}}
cutscene = Chapter1Cutscene.VR; {{codecomment|// '''missions''' sub-directory. A cutscene is of course optional but the parameter '''MUST''' be declared ''(cutscene <nowiki>=</nowiki> ;)''}}
end1 = ;
(…)
  };
  };


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.
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.
class Campaign
{
 
the campaign class is a containing class. It 'contains' all of the chapters making up the campaign!.


this class (which must be called 'Campaign') declares the title of this campaign and which chapter to Start.
  name = "My Great Campaign";
  firstBattle = Chapter1;
  class chapter1 {.....};
  class chapter2 {.....};
      and so on...
};


  class ChapterN
=== Missions ===
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 Chapter is defined as follows:
  class myMission1 {{codecomment|// name, such as chapter one, can be customised}}
  {
  {
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.
end1 = myMission2;
 
end2 = myMission3a;
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.
end3 = myMission3b;
The name of any chapter class is arbitrary one such example would be NogovaChapter
end4 = myMission2;
 
end5 = ;
name = "Chapter I - Battles For Spaghetti Island";
end6 = ;
  cutscene = MyGreatCutscene.Noe; // a cutscene is optinal
lost = myMission1;
class mission1{....};
   
class mission2{...};
template = myMissionDirectory.VR; {{codecomment|// '''missions''' sub-directory}}
  and so on...
  };
  };


Note that a cutscene is no different to any other 'mission'. It is a mission folder like any other, except there is no <u>Mission</u> class associated with it because it aint, a mission!
{{note|Mission directories that are not declared anywhere in description.ext (as mission or cutscene) are simply ignored.}}
 
class MissionX
{
 
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.
 
Mission folders that are not declared anywhere in description.ext have no ill effect, they are simply ignored.
 


==The campaign class==


Declare a MissionDefault class as above
== Full example ==
 
{{codecomment|/*
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.
'''MissionDefault''', '''NoEndings''' etc. are arbitrary. '''MissionDefault''' is an accepted de-facto standard name for missions to inherit.
==The Chapter Class==
Left to itself, simply inheriting the mission default means you will exit the game at the end of mission/chapter.
 
Indeed the last chapter (if any) last mission does exactly this.
#There is at least one chapter in any campaign.
But, almost all classes that inherit '''MissionDefault''' will modify some or most of those mission defaults.
#There is often only one chapter in a campaign.
The intent is to stop tedious typing for every mission. '''An end that is used but not defined (e.g "end6") will crash the game.'''}}
#Chapters contain missions. Campaigns do not.
*/
 
  class NoEndings
  class Chapter1 : NoEndings
  {
  {
    name =        "Chapter I - Nogova Island";  // a fade in to the player of where they're at.
end1 = ;
    cutscene =    Chapter1Cutscene.Noe;        // an optional cutscene.
end2 = ;
    firstMission = Mission1;                    // note the liberal use of semi colons, or crash
end3 = ;
    end1 = Chapter2;
end4 = ;
    end2 = Chapter2;
end5 = ;
    end3 = Chapter2;
end6 = ;
    end4 = Chapter2;
lost = ;
    end5 = Chapter2;
    end6 = Chapter2;
    lost = ;                // end the campaign if a mission wants you to
    class Mission1 {...}; // whatever
    class Mission2 {...}; // see missions for the body text
    ...
    class LastMission{...};
  };
  };
 
chapters establish an (optional) cutscene and organise missions into some semblance of sanity. Eg, as author, you might put all your Nogova missions within a chapter, all your Malden missions in another.
class MissionDefault : NoEndings
 
  {
The name of chapter classes are arbitrary. For legibility here they are named "chapter1 chapter2 and etc solely to show a program flow. It does not follow that simply because chapter2 is written next (if it's written next), chapter 1 will fall thru to it. You must specifically state it.
lives = -1; {{codecomment|// 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; {{codecomment|// TBD}}
Cutscene is optional. For no cutscene intro
cutscene = ; {{codecomment|// mandatory definition}}
 
cutscene = ; // note the semicolon
 
firstMission = declares which, of all the missions contained in this chapter, starts it. It does not necessarily follow that the first mission declared in the chapter is the first one to play. Like missions, everything has to be declared, there is no default fall thru. The class names for missions declared in this chapter can have the same names as missions in other chapters. The engine will not get confused (but you might).
 
class missionX {...} is shorthand for the body text of a mission. You do not write it this way, you write the full body text as explained in missions
 
It should be apparent if you study the body text of a mission, that you could, program "mission10" of chapter one to play the same mission as "mission 99" of chapter 3. The ending triggers for each mission class define what to do next. Ie, you could revisit a mission much more heavily armed.
 
===endings===
For a full description of what endings are, see mission endings
 
Like missions there is no automatic fall thru from 'chapter1' to 'chapter 2'. Everything needed, must be declared. It does not follow that chapter1 'falls thru' to chapter 2. You must program it that way.
 
In the case of chapters, the ending trigger has occurred for the entire chapter. At least one of the missions, most likely the 'last'
mission has defaulted with no endX= declarations of it's own. for a specific, if not all, endings. This, is normal behaviour.
 
The chapter can either continue on to the 'next' chapter, or, end the entire campaign, or move to a different chapter for a specific ending.
 
In the example above, I have provided an unconventional end to the campaign in that at least one mission has decided that if you lost=  that mission (die) you lose the entire campaign. You are the author of your campaign.
 
===No endings===
You can alternatively declare an ending to do nothing, or default to the NoEndings class.
 
Where a specific ending is not declared,  the NoEndings class takes over. This inevitably is a full list of all possible endings, all of which, do nothing. The result of that, is to exit the campaign. This is normal behaviour for the 'last' chapter. The 'last' chapter is the only chapter, in a single chapter mission.
 
The NoEndings class, or alternatively a full definition of all endings doing nothing, must be declared because the chapter (as opposed to a mission) has no way of knowing end6 is or isn't used. If it is used and not defined, the campaign crashes.
 
NoEndings, like MissionDefaults is a class to do 'default behaviour' There is nothing stopping you inheriting something other than a NoEndings class to do something other than 'default behaviour' for several chapters (it makes no sense to write one for a single chapter). You might for instance write a special chapter for end4 so that any mission that successfully captures Abrahms tanks, gets to use an entire 'chapter' of heavy metal.
 
===The last, or only chapter===
 
class LastChapter : NoEndings
  {
    name = "Chapter I - Nogova Island";    // a fade in to the player of where they're at.
    cutscene = Chapter1Cutscene.Noe;       // an optional cutscene.
    firstMission = Mission1;        // note the liberal use of semi colons, or crash
    class Mission1 {...}; // whatever
    class Mission2 {...}; // see missions for the body text
    ...
    class LastMission{...};
  };
  };
 
The above is the most common form of campaign creation. Most, if not all user made campaigns are constructed this way. If you prefer to be specific (rather than rely on the NoEndings class, you could alternatively insert
 
    end1 = ;
    end2 = ;
    end3 = ;
    end4 = ;
    end5 = ;
    end6 = ;
    lost = ; 
 
===Single Chapter Campaign===
A single chapter campaign looks as follows
 
  class Campaign
  class Campaign
  {
  {
    name = "My Great Campaign";
  name = "My Great Campaign"; {{codecomment|// < Arma 3}}
    firstBattle = Chapter1;   // might be the only chapter
  briefingName = "My Great Campaign"; {{codecomment|// Arma 3}}
    class Chapter1 : NoEndings
firstBattle = Chapter1;
    {
      name = "Chapter1 Fighting for Everon";
class Chapter1 : NoEndings
      cutscene = AGreatCutscene.Eden;   // if any
{
      firstMission = FirstMission;
firstMission = Chapter1_Mission1;
      class FirstMission: MissionDefault
end1 = Chapter2; {{codecomment|// other endings are defined by inheritance from NoEndings}}
      {
        // ending commands
class Chapter1_Mission1 : MissionDefault
      };
{
      class MissionN: MissionDefault
end1 = Chapter1_Mission2; {{codecomment|// other endings are defined by inheritance from MissionDefault, inheriting from NoEndings}}
      {
end2 = ; {{codecomment|// end2 will end Chapter 1, therefore going to Chapter 2}}
        // ending commands
template = C1M1.VR;
      };
};
      class LastMission: MissionDefault
class Chapter1_Mission2 : MissionDefault
      {
{
        // NO ending commands
end1 = ; {{codecomment|// not defining the ending will use the Chapter ending corresponding to end1: ''Chapter2'' here}}
      };
    }; // end of this chapter
template = C1M2.VR;
};    // end of this campaign
};
 
};
when chapter1 ends, the game ends via : NoEndings
 
class Chapter2 : NoEndings
There are no over-rides provided for endings in chapter one, hence when the chapter ends, the campaign ends.
{
 
firstMission = Chapter2_Mission1;
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.
end1 = LastChapter;
 
===MultiChapter Campaign===
{{codecomment|// this mission is named Chapter2_Mission1 for clarity purpose,
A multi chapter campaign looks as follows
// 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 Campaign
class Chapter2_Mission1 : MissionDefault
{
{
    name = "My Great Campaign";
end1 = ; {{codecomment|// not defining the ending will use the Chapter ending corresponding to end1: ''LastChapter'' here}}
    firstBattle = Chapter1;   
    class Chapter1 : NoEndings
template = C2M1.VR;
    {
};
        end1 = NextChapter;
};
        end2 = NextChapter;
   
        end3 = NextChapter;
class LastChapter : NoEndings
        end4 = NextChapter;
{
        end5 = NextChapter;
firstMission = Chapter3_Mission1;
        end6 = NextChapter;
{{codecomment|// no endings provided: because of NoEndings inheritence this is the same as writing
        loose= NextChapter;
// end1 <nowiki>=</nowiki> ;
        ... missions etc
// end2 <nowiki>=</nowiki> ;
    };
// end3 <nowiki>=</nowiki> ;
    class NextChapter : NoEndings
// end4 <nowiki>=</nowiki> ;
    {
// end5 <nowiki>=</nowiki> ;
        end1 = LastChapter ;
// end6 <nowiki>=</nowiki> ;
        ...... missions etc
// lost <nowiki>=</nowiki> ;}}
    };
class Chapter3_Mission1
    class LastChapter : NoEndings
{
    {
{{codecomment|// not defining the ending will use the Chapter ending corresponding to end1: '''NOTHING''' here, closing the campaign}}
        // no endings provided
template = C3M1.VR;
        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.
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.
Nor is the name of the chapter class important, other than
endX= MustGotoASpcificallyNamedChapterClassName;
It is, as simple as that.
==Mission Class==
class Mission1  :  MissionDefault
{
  noAward=true;
  end1 = Mission2;            // which mission to play on a successful ending
  end2 = Mission2;            // which mission to play on a slightly less successful outcome
  end3 = Mission2;            // etc
  end4 = Mission2;
  end5 = Mission2;
  end6 = Mission2;            //
  lost = Mission1;            // which mission to replay if you die. this one.
  template = Mission1.Noe;    // The folder in the Missions/ directory containing the mission
};
"Mission1" and "Mission2" are arbitrary names.. There is, but need not be, a close association between the name used for the class and the name of the folder containing the mission itself. Using identical names is a good idea (tm).
The template= is the mission folder to play. It always has an island extension associated with it. In this case, Nogova. There is nothing in this, nor any other script that declares what island the mission is 'on', other than the filename extension itself.
It should be instantly apparent that mission folders cannot have whitespace in their names.
Endings 1 to 6, are the result of 'triggers'. They are the result of conditions established by the mission author being activated.  It is rare to use more than 2, but, up to six different ending slots are available for use by the author. By convention end1 is the total success ending, but need not be. If there is no end6 condition it matters nothing that it is declared above to 'do something'.
Conversely If it's not declared, and is used, it matters a great deal. Often resulting in a crash.
Moving to "Mission2" is standard behaviour for all of the possible endings. The flow of campaign design is that mission1 -> mission2 -> mission3 and so on. It need not be. End4 might be a trigger that if you capture the scud launcher. you get to use it in a separate 'adventure'. It is after all, your campaign. Just bare in mind that there is NO automatic fall thru, you must declare everything required.
Conventionally lost= (which means dead) restarts the same mission. It need not be. It's your campaign,
===Where you dont declare an ending.===
The MissionDefault class takes over for that ending. The name "MissionDefault" is arbitrary, but, by convention this is what that class is named. The MissionDefault class is written to end  (not exit, end) the chapter class within which this mission is contained. It is then the chapter which must decide what to do and etc.
MissionDefault contains other parameters which are not normally over-ridden by the mission itself. Notably lives=-1. Therefore even though you declare all endings in all missions, you still 'inherit' MissionDefault for each mission.
It should be apparent that as the author, you could write a number of missions, perhaps all in the same chapter, all of which have default endings different to the standard. For example end4 always results in the same cutscene, regardless of mission. You would change the : MissionDefault inheritance to MyEnd4Default and not bother declaring end4 in the body text of the mission class (for any missions you want this behaviour to happen in).
When it comes to making several of the ending triggers all behave a similar way, it is easier to use an inheritance than tediously write endings for each one that's default. To be a little more specific, MyEnd4Default would also, undoubtedly, inherit MissionDefault in its own right to include standard mission parameters (lives = -1) and endings it does not handle.
If all of the above is currently a little too deep for you, using the above class as a template will work for most of what you want to do.
===THE LAST MISSION===
class MissionLast  :  MissionDefault
{
lost = MissionLast;           
template = MissionLast.Noe;   
};
The name "MissionLast" is arbitrary, the name is whichever mission you decide to be the last one.
The difference between this, and any other mission is that no endings are declared, therefore default behaviour happens.
Either to be specific, or where MissionDefault does not end the chapter (because you wrote it some other way) you can declare the endings as follows


end1 = ;
== Recommendations ==
end2 = ;
If you don't know for sure what you are doing, follow these advices:
end3 = ;
* try and make all the missions work stand-alone, then place them all in the '''Missions''' directory
end4 = ;
* 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.
end5 = ;
* you can test your campaign structure by allowing file patching (in Arma 3 launcher, or ''arma3.exe -filePatching'') and placing your campaign in the ''campaign'''s''''' directory
end6 = ;


The chapter class will take over and use it's endings instead.
[[Category:Operation Flashpoint: Editing]]
[[Category:ArmA: Mission Editing]]
[[Category:ArmA 2: Editing]]
[[Category:Arma 3: Editing]]
[[Category:Mission Editor]]

Revision as of 02:23, 7 March 2018

Template:note

Description

A campaign description.ext is the entry point to load campaign informations. It must not be confused with mission Description.ext. The campaign title, author and overview picture, the missions tree, everything displayed from the Campaigns screen will be loaded from it.

It is important to be well written to ensure a good campaign experience. The flow of missions is defined in this file (aka which mission should be played on which ending).

A campaign file (myCampaign.pbo) should need no other file to work (beside base game files and required mods)!

A wrongly formatted Campaign Description.ext can crash your game!


Directory structure

A campaign structure is the following:

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

Other files may appear at the root of myCampaignMainDirectory for sharing resources between missions, or storing the campaign overview image for example. No files should appear in myCampaignMainDirectory\missions , only mission directories Missions name doesn't matter nor impact the missions flow. Zmission.VR will not load after Amission.VR – the order is, again, defined in description.ext.

Template:note

Missions flow

Missions flow structure is defined as follows:

  1. Campaign, filled with chapters
  2. Chapters, filled with missions
  3. Missions, filled with endings.
Campaign cannot contain missions 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 and 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";	// Arma 3 - if undefined, an error popup will appear
	author		= "Username";		// Arma 3 - if undefined, "by unknown community author" will replace author's name
	weaponPool	= 1;			// since OFP:R v1.75: allows weapon pool to be used in mission briefing
	(…)
};


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 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;	// 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 Chapter is defined as follows:

class myMission1 // name, such as chapter one, can be customised
{
	end1 = myMission2;
	end2 = myMission3a;
	end3 = myMission3b;
	end4 = myMission2;
	end5 = ;
	end6 = ;
	lost = myMission1;

	template = myMissionDirectory.VR; // missions sub-directory
};

Template:note


Full example

/*
	MissionDefault, NoEndings etc. 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 the 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. An end that is used but not defined (e.g "end6") will crash the game.
*/
class NoEndings
{
	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
};

class Campaign
{
 	name		= "My Great Campaign"; // < Arma 3
 	briefingName	= "My Great Campaign"; // Arma 3
	firstBattle	= Chapter1;

	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 inheritence this is the same as writing
		// end1 = ;
		// end2 = ;
		// end3 = ;
		// end4 = ;
		// end5 = ;
		// end6 = ;
		// lost = ;
		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