MakeInfantry
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 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→[General]→AnimToInfantry 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 AltPalette=yes 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]→AnimToInfantry
For example, AnimToInfantry=BRUTE,NEWUNIT,GHOST
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 AnimToInfantry 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 Warhead must have InfDeath=9 set.
Note that MutateWarhead and MutateExplosionWarhead 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 MakeInfantry=X on your animation, where X is the list index number of the InfantryType you wish to spawn, taken from the AnimToInfantry flag discussed in the first step.
Applications
Neutral infantry
You can create neutral infantry oppponents by not using an InfDeath=9 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]→DeathAnims=NEWANIM and artmd.ini→[NEWANIM]→MakeInfantry=0 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 InfDeath=9 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 InfDeath=8, you can spawn a second InfantryType that will be player-owned. However, in order to make use of InfDeath 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 MakeInfantry flag at the top of this page).
But that really is it though, the other InfDeaths won't work for this.
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 InfDeath 9 must have a MakeInfantry flag and it must be set to a valid AnimToInfantry list index. If it doesn't, then the animation will not play at all. [Actually, it doesn't have to have the MakeInfantry flag if it has instead a Next flag so that the last animation of a sequence of animations invoked by InfDeath 9 does have a MakeInfantry 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.