PMC Editing Wiki

User Tools

Site Tools

Trace:
ofp:missions:camp_description.ext

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
ofp:missions:camp_description.ext [2007/07/09 02:09] – snakemanofp:missions:camp_description.ext [2024/07/31 13:06] (current) – links added. snakeman
Line 1: Line 1:
-====== Campaign Description.ext ======+====== OFP Campaign Description.ext ====== 
 + 
 +[[https://www.pmctactical.org/forum/viewforum.php?f=43|OFP Forum]], [[:ofp|OFP Home]], [[ofp:file_formats|OFP File Formats]], [[ofp:tools|OFP Tools]], [[ofp:missions|OFP Missions]], [[ofp:modeling|OFP 3D Modeling]], [[ofp:terrain|OFP Terrain]] 
 + 
 +**Operation Flashpoint (OFP)** aka ArmA: Cold War Assault (CWA)
  
  
Line 30: Line 34:
    Each 'mission' is in it's own, arbitrarily> named directory, within this MissionS/ directory    Each 'mission' is in it's own, arbitrarily> named directory, within this MissionS/ directory
  .  .
-    The content of any mission folder is an exact copy of what they were, played as single missions. +    The content of any mission folder is an exact copy of what they were, played as single missions.
     No changes     No changes
     No alterations     No alterations
Line 87: Line 91:
  
 <code> <code>
-class NoEndings  +class NoEndings 
-{  +{ 
- lost = ;  + lost = ; 
- end1 = ;  + end1 = ; 
- end2 = ;  + end2 = ; 
- end3 = ;  + end3 = ; 
- end4 = ;  + end4 = ; 
- end5 = ;  + end5 = ; 
- end6 = ; + end6 = ;
 }; };
 </code> </code>
Line 105: Line 109:
 <code> <code>
 class MissionDefault : NoEndings class MissionDefault : NoEndings
-{  +{ 
- lives = -1; + lives = -1;
 }; };
 </code> </code>
Line 142: Line 146:
 </code> </code>
  
-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. +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.
  
 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. 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.
Line 192: Line 196:
  end6 = Chapter2;  end6 = Chapter2;
  lost = ;                // end the campaign if a mission wants you to  lost = ;                // end the campaign if a mission wants you to
- class Mission1 {...}; // whatever + class Mission1 {...}; // whatever
  class Mission2 {...}; // see missions for the body text  class Mission2 {...}; // see missions for the body text
  ...  ...
Line 203: Line 207:
 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. 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.
  
-Cutscene is optional. For no cutscene intro +Cutscene is optional. For no cutscene intro
  
 <code> <code>
Line 221: Line 225:
 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. 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' +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. mission has defaulted with no endX= declarations of it's own. for a specific, if not all, endings. This, is normal behaviour.
  
Line 246: Line 250:
  cutscene = Chapter1Cutscene.Noe;        // an optional cutscene.  cutscene = Chapter1Cutscene.Noe;        // an optional cutscene.
  firstMission = Mission1;        // note the liberal use of semi colons, or crash  firstMission = Mission1;        // note the liberal use of semi colons, or crash
- class Mission1 {...}; // whatever + class Mission1 {...}; // whatever
  class Mission2 {...}; // see missions for the body text  class Mission2 {...}; // see missions for the body text
  ...  ...
Line 309: Line 313:
 { {
  name = "My Great Campaign";  name = "My Great Campaign";
- firstBattle = Chapter1;    + firstBattle = Chapter1;
  class Chapter1 : NoEndings  class Chapter1 : NoEndings
  {  {
Line 368: Line 372:
 It should be instantly apparent that mission folders cannot have whitespace in their names. 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'. +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. +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. 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.
Line 382: Line 386:
 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. 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). +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. 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.
ofp/missions/camp_description.ext.1183946953.txt.gz · Last modified: 2007/07/10 09:52 (external edit)
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki

All PMC web site download services are temporarily suspended until web site yearly fees have been recovered, want to download addons/mods? Then Support PMC.

If you are grateful for all the work PMC has done in the past 25 years, use Support PMC page.