ModEnc is currently in Maintenance Mode: Changes could occur at any given moment, without advance warning.

VariableNames: Difference between revisions

From ModEnc
Jump to navigation Jump to search
No edit summary
 
Crimsonum (talk | contribs)
Better looking tables
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{DeeZireInclusion}}<br />
{{WrongTitle|[VariableNames]}}
This section is used to determine the global variable names used throughout the single player campaigns. These must be constant throughout all scenarios based on these rules. These are numbered starting from zero. Do not change the number values or else all pre-existing triggers using them will break. There should be no need to amend, edit or change these - they are best left alone. If you need to set your own variables you can do so through individual map files with the use of Local variables (see the Map Editing Guide). You can however define new Globals here and in conjunction with the relevant map file Action= this could provide a crude means of ensuring that your map(s) can only be used with your mod.<br />
 
This section specifies the various general behaviour characteristics of the missions that objects can be assigned. Each of the game objects must be in a mission at all times. The mission behaviour is generally hard coded, but there are some behaviour characteristics that can be overridden. Don't modify these or bad crashiness (and at best unpredictable/undesired effects) will result. Each mission to which an object can be assigned can have its own section defined here which will over-write the default values. Red Alert 2 allows the following missions for objects;-<br />
{{MappingBar}}
<br />
 
  [Sleep] object sits around and plays dead, will not acquire targets<br />
This section exists in both {{Ini|Rules}} and maps and is used for similar purposes in both cases: it contains a list of [[Help:Values#Boolean_values|boolean]] variables in this map that map triggers can change and be activated by (e.g., if you performed a bonus objective, you can expect less resistance from one enemy party, or, when playing the singleplayer campaigns, even get an extra mission after completing the current one). The difference between the two sections is explained below.
  [Attack] special attack mission used by AI team type logic<br />
 
[Move] simply moving to destination<br />
__TOC__
[QMove] special move to destination after other queued moves occur<br />
 
[Retreat] object runs away (may even leave the map)<br />
== {{td}}, {{ra}}/{{cs}}/{{am}} ==
[Guard] object sits around and will engage an enemy that falls within its weapon range<br />
 
[Sticky] just like guard mode, except the object will engage enemies but not pursue them<br />
Section does not exist.
[Enter] enter building or transport<br />
 
  [Capture] engineer entry logic<br />
== {{ts}}/{{fs}}/{{ra2}}/{{yr}} ==
  [Eaten] when object is being repaired (applies only to structures)<br />
 
[Harvest] the loop controlling harvesting of Ore and dumping at a Refinery<br />
=== In rules(md).ini ===
[Area Guard] guard the general area where the object starts at<br />
This section comprises a list of all Global Variables available in the game. Global Variables are [[ModEnc:Values|boolean]] variables, their state is preserved between missions, but not saved in savegames.  
[Return] return to co-ordinating object (e.g. spawned object returns to the spawner)<br />
 
[Stop] stop moving or firing at the first available opportunity<br />
The [{{Tt|VariableNames}}] section takes the following format:
[Ambush] unused, its effects are unknown<br />
 
[Hunt] scan for and attack enemies wherever they may be on the map<br />
  [VariableNames]
[Unload] while dropping off cargo (e.g. Landing Craft unloading passengers)<br />
  Index=VARIABLE_NAME
[Sabotage] unit runs to place C4 on a building or Ivan goes to place bomb on object<br />
 
[Construction] structures use this when building up after initial placement<br />
{| style="width: 80%" class="table_descrowdesccol wikitable"
[Selling] structures use this for deconstruction after being sold<br />
|+ Meanings of each string
[Repair] used when repairing an object (e.g. Service Depot)<br />
! style="width: 13em; " | String
[Rescue] special team over-ride mission<br />
! Meaning
[Missile] Nuke Silo special launch missile mission<br />
|-
[Harmless] object doesn't fire and is not considered in any threat scan<br />
! {{Anchor|Index|ts_g}}
[Open] while opening or closing a gate to allow passage<br />
| This is a variable's index. Unlike indexes in lists like [InfantryTypes], it actually matters - the game allocates space for 50 global variables, and uses the Index to decide which of them this line is about.
[Patrol] patrol a series of waypoints<br />
|-
[Paradrop Approach] object is approaching the paradrop site<br />
! {{Anchor|VARIABLE_NAME|ts_g}}
[Paradrop Overfly] object is flying over the paradrop site (i.e. dropping the paratroopers)<br />
| The Variable's name. It is limited to 40 characters in length when reading but not used ingame.
[Wait] paused and awaiting next mission<br />
|}
(YR) [Spyplane Approach]object is flying towards target<br />
 
(YR) [Spyplane Overfly] object is flying over the target
=== In Maps ===
This section comprises a list of all Local Variables available in this map. Local Variables are [[ModEnc:Values|boolean]] variables, their state is saved in savegames, but not carried over between missions.
 
The [{{Tt|VariableNames}}] section takes the following format:
 
  [VariableNames]
  Index=VARIABLE_NAME,INITIAL_VALUE
 
{| style="width: 80%" class="table_descrowdesccol wikitable"
|+ Meanings of each string
! style="width: 13em; " | String
! Meaning
|-
! {{Anchor|Index|ts_l}}
| This is a variable's index. Unlike indexes in lists like [InfantryTypes], it actually matters - the game allocates space for 50 (100 in YR) local variables, and uses the Index to decide which of them this line is about.
|-
! {{Anchor|VARIABLE_NAME|ts_l}}
| The Variable's name. It should not exceed 40 characters in length and shouldn't contain commas even though it is not used ingame.
|-
! {{Anchor|INITIAL_VALUE|ts_l}}
| The Variable's value at map start. Can be set to either {{Tt|0}} ('false') or any other numeric value ('true').
|}
 
=== Hardcoded Globals ===
 
A few of the global variable IDs (indexes) have hardcoded properties:
* If variable 0 is set, then the next [[scenario]] will use an alternate starting position as defined by its {{sl|Basic|AltHomeCell}}.
* If variable 1 is set, then the campaign will proceed to an alternate scenario as defined by {{sl|Basic|AltNextScenario}} in the ''current'' scenario.
 
== Best of Both Worlds (Blade's post) ==
 
It is (theoretically) possible to carry an event (say capture a battle lab) through to having an effect on some later level (say allowing you to build a certain unit you normally cannot), but it is frustrated by the auto save feature that saves at the start of a level.
 
During a level, have some event you want to carry forward set a 'Local'. These are known to be carried by saves games as a nessesity. When the win condition is met, actually have two win triggers that have the 'Local' set or clear as one of the conditions. The clear one just triggers the win, while the set one sets a 'global' as well triggering the win. This will carry over to the next level and the player cannot save in the mean time to wipe it out (only the auto save can...maybe). In the next level, have a trigger that sets a new 'Local' to carry the 'global' during the level if the 'global' is set at the start of the mission. Just repeat this over as many levels as needed in order to carry the value to the level where it will have its effect. I've never really tested this and it remains just a theory of mine and I don't really know if autosave would save before or after the 'global variable' has had chance to convert to a 'local variable' so it remains a potential spanner in the works.
 
[[Category:Rules(md).ini Sections]]

Latest revision as of 19:35, 16 May 2024

This page should correctly be named "[VariableNames]"; it is wrong due to technical restrictions.



This section exists in both Rules(md).ini and maps and is used for similar purposes in both cases: it contains a list of boolean variables in this map that map triggers can change and be activated by (e.g., if you performed a bonus objective, you can expect less resistance from one enemy party, or, when playing the singleplayer campaigns, even get an extra mission after completing the current one). The difference between the two sections is explained below.

Tiberian Dawn, Red Alert/Counterstrike/Aftermath

Section does not exist.

Tiberian Sun/Firestorm/Red Alert 2/Yuri's Revenge

In rules(md).ini

This section comprises a list of all Global Variables available in the game. Global Variables are boolean variables, their state is preserved between missions, but not saved in savegames.

The [VariableNames] section takes the following format:

[VariableNames]
Index=VARIABLE_NAME
Meanings of each string
String Meaning
Index This is a variable's index. Unlike indexes in lists like [InfantryTypes], it actually matters - the game allocates space for 50 global variables, and uses the Index to decide which of them this line is about.
VARIABLE_NAME The Variable's name. It is limited to 40 characters in length when reading but not used ingame.

In Maps

This section comprises a list of all Local Variables available in this map. Local Variables are boolean variables, their state is saved in savegames, but not carried over between missions.

The [VariableNames] section takes the following format:

[VariableNames]
Index=VARIABLE_NAME,INITIAL_VALUE
Meanings of each string
String Meaning
Index This is a variable's index. Unlike indexes in lists like [InfantryTypes], it actually matters - the game allocates space for 50 (100 in YR) local variables, and uses the Index to decide which of them this line is about.
VARIABLE_NAME The Variable's name. It should not exceed 40 characters in length and shouldn't contain commas even though it is not used ingame.
INITIAL_VALUE The Variable's value at map start. Can be set to either 0 ('false') or any other numeric value ('true').

Hardcoded Globals

A few of the global variable IDs (indexes) have hardcoded properties:

  • If variable 0 is set, then the next scenario will use an alternate starting position as defined by its [Basic]AltHomeCell=.
  • If variable 1 is set, then the campaign will proceed to an alternate scenario as defined by [Basic]AltNextScenario= in the current scenario.

Best of Both Worlds (Blade's post)

It is (theoretically) possible to carry an event (say capture a battle lab) through to having an effect on some later level (say allowing you to build a certain unit you normally cannot), but it is frustrated by the auto save feature that saves at the start of a level.

During a level, have some event you want to carry forward set a 'Local'. These are known to be carried by saves games as a nessesity. When the win condition is met, actually have two win triggers that have the 'Local' set or clear as one of the conditions. The clear one just triggers the win, while the set one sets a 'global' as well triggering the win. This will carry over to the next level and the player cannot save in the mean time to wipe it out (only the auto save can...maybe). In the next level, have a trigger that sets a new 'Local' to carry the 'global' during the level if the 'global' is set at the start of the mission. Just repeat this over as many levels as needed in order to carry the value to the level where it will have its effect. I've never really tested this and it remains just a theory of mine and I don't really know if autosave would save before or after the 'global variable' has had chance to convert to a 'local variable' so it remains a potential spanner in the works.