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

Difference between revisions of "MakeInfantry"

From ModEnc
Jump to: navigation, search
m (I don't think See Also is necessary in that case, but right now I don't see any links to Mutation in body, so leaving that one. As for RP, how about creating a template-section like Bugs ?)
(Adding info on spawn failure bug, might need rewording, adjusted heading levels, do we need a categ for lag-inducing phenomenons ?)
Line 20: Line 20:
 
If this [[animation]] was invoked by an [[InfDeath]] other than 9, and the [[animation]] has {{TTL|AltPalette|yes}} set, then any remappable colours will be remapped to a seemingly random player colour.
 
If this [[animation]] was invoked by an [[InfDeath]] other than 9, and the [[animation]] has {{TTL|AltPalette|yes}} set, then any remappable colours will be remapped to a seemingly random player colour.
  
=Using MakeInfantry Logic (tutorial by Marshall)=
+
==Using MakeInfantry Logic (tutorial by Marshall)==
 
If you've been reading up on MakeInfantry (mutation) logic elsewhere and haven't really understood much then that's okay - this tutorial is probably more easily understood if you haven't read any other MakeInfantry information before.
 
If you've been reading up on MakeInfantry (mutation) logic elsewhere and haven't really understood much then that's okay - this tutorial is probably more easily understood if you haven't read any other MakeInfantry information before.
  
Line 58: Line 58:
 
*Do not use an area-effect mutation weapon if [[paradrops|paratroopers]] are not immune to it - an [[Internal Error]] will occur if a falling paratrooper is killed by an area-effect mutation weapon (point based mutation deaths seem to be okay and just result in the paratrooper exploding, and the Genetic Mutator super weapon appears to have been designed to prevent it killing such infantry).  
 
*Do not use an area-effect mutation weapon if [[paradrops|paratroopers]] are not immune to it - an [[Internal Error]] will occur if a falling paratrooper is killed by an area-effect mutation weapon (point based mutation deaths seem to be okay and just result in the paratrooper exploding, and the Genetic Mutator super weapon appears to have been designed to prevent it killing such infantry).  
 
*The animation associated with {{TTL|InfDeath}} 9 '''must''' have a {{TTL|MakeInfantry}} flag and it must be set to a valid {{TTL|AnimToInfantry}} list index. If it doesn't, then the animation will not play at all. <small>[Actually, it doesn't have to have the {{TTL|MakeInfantry}} flag ''if'' it has instead a {{TTL|Next}} flag so that the last animation of a sequence of animations invoked by InfDeath 9 ''does'' have a {{TTL|MakeInfantry}} flag.]</small>
 
*The animation associated with {{TTL|InfDeath}} 9 '''must''' have a {{TTL|MakeInfantry}} flag and it must be set to a valid {{TTL|AnimToInfantry}} list index. If it doesn't, then the animation will not play at all. <small>[Actually, it doesn't have to have the {{TTL|MakeInfantry}} flag ''if'' it has instead a {{TTL|Next}} flag so that the last animation of a sequence of animations invoked by InfDeath 9 ''does'' have a {{TTL|MakeInfantry}} flag.]</small>
 +
*When an animation that has this flag set is playing and the cell is obstructed so the infantry cannot be spawned (e.g., a vehicle is parked in that cell), the game will stubbornly keep trying to place it, and cause increasing lag, as well as an ever-growing memory leak, for the remainder of the game session. The only way to prevent accumulating lag is to make sure the cell in question is clear. Note that this also happens when the cell is occupied by invincible objects such as impassable terrain tiles (cliffs, water) or [[TerrainTypes]] such as ore mines. In this case, there is no fix for the ever growing lag and memory leakage, short of aborting the current game session. <!-- It's 5 AM, do you know where your garbage collector is? blargh. -->
  
=See also=
+
==See also==
 
*[[Mutation]]
 
*[[Mutation]]
  
 
[[Category:RA2/YR Tutorials]]
 
[[Category:RA2/YR Tutorials]]

Revision as of 07:51, 23 May 2008

Tiberian Dawn The Covert Operations Red Alert Counterstrike Aftermath Tiberian Sun Firestorm HyperPatch Red Alert 2 Yuri's Revenge Ares Generals Zero Hour Tiberium Wars Kane's Wrath
Flag: MakeInfantry
File(s): art(md).ini
Values: Signed integers: All whole numbers from -2147483648 to 2147483647; in rare cases, only from -32768 to 32767.
Special Values:  -1 (do not use MakeInfantry logic)
Default:  -1
Applicable to: Animations


Specifies the list index of rulesmd.ini→[[[:Template:TTL]]]→Template:TTL to refer to to determine which InfantryType should be created when this animation finishes.

If this animation was invoked by InfDeath 8 or 9 then the resulting InfantryType will be given to the owner of the killing unit.

If this animation was invoked by any InfDeath other than 8 or 9 then the resulting InfantryType will be given to neutral.

If this animation was invoked by InfDeath 9 then the animation will be hard-coded to use the unit palette instead of the animation palette, and any remappable colours will be remapped to the player colour of the owner of the killing unit.

If this animation was invoked by an InfDeath other than 9, and the animation has Template:TTL set, then any remappable colours will be remapped to a seemingly random player colour.

Using MakeInfantry Logic (tutorial by Marshall)

If you've been reading up on MakeInfantry (mutation) logic elsewhere and haven't really understood much then that's okay - this tutorial is probably more easily understood if you haven't read any other MakeInfantry information before.

I'm going to start with a "lie to children".
There can be only one player-owned InfantryType that is created from MakeInfantry logic.
Please bear that in mind when reading the following steps.

1. You need to list all the InfantryTypes that you would like to spawn using MakeInfantry logic. You do this in a comma separated list on the following flag:
rulesmd.ini[General]Template:TTL
For example, Template:TTL
Later on we will refer to these InfantryTypes by their list index. In the above example, BRUTE would have an index of zero, NEWUNIT would have an index of 1 and GHOST would have an index of 2.

2. In order to spawn an InfantryType from the Template:TTL list then an animation must be played - the InfantryType will be spawned once the animation finishes.
To make the spawned InfantryType player-owned, another infantry unit in-game must be killed by a weapon that was fired by a player-owned unit. Further more, the weapon's Template:TTL must have Template:TTL set.
Note that Template:TTL and Template:TTL are only used by the Genetic Mutator super weapon and have no bearing on this logic. You can change the animation referenced by InfDeath 9 if you want (see InfDeaths).

3. In artmd.ini, find or create the animation section for the animation that you want to spawn an InfantryType (see [GENDEATH] as an example).
You need to set Template:TTL on your animation, where X is the list index number of the InfantryType you wish to spawn, taken from the Template:TTL flag discussed in the first step.

Applications

Neutral infantry

You can create neutral infantry oppponents by not using an Template:TTL weapon (this includes using an animation that is not caused by a weapon such as crate pickups or a building anim). For example, setting rulesmd.ini[E1]Template:TTL and artmd.ini[NEWANIM]Template:TTL would cause the GI to turn into a neutral Brute when the GI dies.

Player-owned infantry

You can create multiple weapons that result in a player-owned InfantryType being created as long as they all have Template:TTL set on their warheads. However the limitation is that they will all spawn the same InfantryType.
You could, of course, change the InfantryType that the Genetic Mutator spawns, or you could convert the Genetic Mutator into a non-mutation weapon if you wanted to.

Game modes

You can override the main rules in a game mode so that the InfantryTypes that are created by the MakeInfantry logic, the animations that cause the InfantryTypes to be spawned and the way those animations are played are different to other game modes - this will allow you to have different player-owned mutations in your mod, however you can still only have one player-owned mutation per game mode.

Actually, you can have two player-owned mutations

I lied above so that you could more easily understand the MakeInfantry logic first. In truth, by using Template:TTL, you can spawn a second InfantryType that will be player-owned. However, in order to make use of Template:TTL 8 for MakeInfantry purposes you will have to sacrifice the unique Virus InfDeath animation (or re-order the other InfDeath animations, but you will have to sacrifice one of them). There is also a limitation of InfDeath 8 in that the animation cannot remap the player colours correctly (see the description of the Template:TTL flag at the top of this page).
But that really is it though, the other InfDeaths won't work for this.

Cc alert.png Bugs/Side-Effects/Unexpected Limitations

  • Do not use an area-effect mutation weapon if paratroopers are not immune to it - an Internal Error will occur if a falling paratrooper is killed by an area-effect mutation weapon (point based mutation deaths seem to be okay and just result in the paratrooper exploding, and the Genetic Mutator super weapon appears to have been designed to prevent it killing such infantry).
  • The animation associated with Template:TTL 9 must have a Template:TTL flag and it must be set to a valid Template:TTL list index. If it doesn't, then the animation will not play at all. [Actually, it doesn't have to have the Template:TTL flag if it has instead a Template:TTL flag so that the last animation of a sequence of animations invoked by InfDeath 9 does have a Template:TTL flag.]
  • When an animation that has this flag set is playing and the cell is obstructed so the infantry cannot be spawned (e.g., a vehicle is parked in that cell), the game will stubbornly keep trying to place it, and cause increasing lag, as well as an ever-growing memory leak, for the remainder of the game session. The only way to prevent accumulating lag is to make sure the cell in question is clear. Note that this also happens when the cell is occupied by invincible objects such as impassable terrain tiles (cliffs, water) or TerrainTypes such as ore mines. In this case, there is no fix for the ever growing lag and memory leakage, short of aborting the current game session.

See also