MakeInfantry: Difference between revisions
Adding info on spawn failure bug, might need rewording, adjusted heading levels, do we need a categ for lag-inducing phenomenons ? |
mNo edit summary |
||
(3 intermediate revisions by 3 users not shown) | |||
Line 10: | Line 10: | ||
}} | }} | ||
Specifies the list index of {{tt|rulesmd.ini}}{{arr|r}}[{{ | Specifies the list index of {{tt|rulesmd.ini}}{{arr|r}}[{{f|General|link}}]{{arr|r}}{{f|AnimToInfantry|link}} 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 [[InfDeath]] 8 or 9 then the resulting [[InfantryType]] will be given to the owner of the killing unit. | ||
Line 18: | Line 18: | ||
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 [[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 {{ | If this [[animation]] was invoked by an [[InfDeath]] other than 9, and the [[animation]] has {{f|AltPalette|yes|link}} 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)== | ||
Line 28: | Line 28: | ||
<br> | <br> | ||
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:<br> | 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:<br> | ||
{{tt|[[rules|rulesmd.ini]]}}{{arr|r}}[[General|[General]]]{{arr|r}}{{ | {{tt|[[rules|rulesmd.ini]]}}{{arr|r}}[[General|[General]]]{{arr|r}}{{f|AnimToInfantry|link}}<br> | ||
For example, {{ | For example, {{f|AnimToInfantry|BRUTE,NEWUNIT,GHOST|link}}<br> | ||
Later on we will refer to these [[InfantryTypes]] by their list index. In the above example, {{tt|BRUTE}} would have an index of zero, {{tt|NEWUNIT}} would have an index of 1 and {{tt|GHOST}} would have an index of 2.<br> | Later on we will refer to these [[InfantryTypes]] by their list index. In the above example, {{tt|BRUTE}} would have an index of zero, {{tt|NEWUNIT}} would have an index of 1 and {{tt|GHOST}} would have an index of 2.<br> | ||
<br> | <br> | ||
2. In order to spawn an [[InfantryType]] from the {{ | 2. In order to spawn an [[InfantryType]] from the {{f|AnimToInfantry|link}} list then an animation must be played - the [[InfantryType]] will be spawned once the animation finishes. <br> | ||
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 {{ | 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 {{f|Warhead|link}} '''must''' have {{f|InfDeath|9|link}} set.<br> | ||
Note that {{ | Note that {{f|MutateWarhead|link}} and {{f|MutateExplosionWarhead|link}} 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 [[InfDeath|InfDeaths]]).<br> | You can change the animation referenced by [[InfDeath]] 9 if you want (see [[InfDeath|InfDeaths]]).<br> | ||
<br> | <br> | ||
3. In {{Tt|[[art|artmd.ini]]}}, find or create the [[animation]] section for the animation that you want to spawn an [[InfantryType]] (see {{tt|[GENDEATH]}} as an example).<br> | 3. In {{Tt|[[art|artmd.ini]]}}, find or create the [[animation]] section for the animation that you want to spawn an [[InfantryType]] (see {{tt|[GENDEATH]}} as an example).<br> | ||
You need to set {{ | You need to set {{f|MakeInfantry|X|link}} on your animation, where X is the list index number of the [[InfantryType]] you wish to spawn, taken from the {{f|AnimToInfantry|link}} flag discussed in the first step. | ||
==Applications== | ==Applications== | ||
===Neutral infantry=== | ===Neutral infantry=== | ||
You can create [[neutral]] infantry oppponents by not using an {{ | You can create [[neutral]] infantry oppponents by not using an {{f|InfDeath|9|link}} weapon (this includes using an animation that is not caused by a weapon such as crate pickups or a building anim). For example, setting {{tt|[[rules|rulesmd.ini]]}}{{arr|r}}{{tt|[E1]}}{{arr|r}}{{f|DeathAnims|NEWANIM|link}} and {{tt|[[art|artmd.ini]]}}{{arr|r}}{{tt|[NEWANIM]}}{{arr|r}}{{f|MakeInfantry|0|link}} would cause the GI to turn into a neutral Brute when the GI dies. | ||
===Player-owned infantry=== | ===Player-owned infantry=== | ||
You can create multiple weapons that result in a player-owned [[InfantryType]] being created as long as they all have {{ | You can create multiple weapons that result in a player-owned [[InfantryType]] being created as long as they all have {{f|InfDeath|9|link}} set on their {{tt|[[Warhead|warheads]]}}. However the limitation is that they will all spawn the same [[InfantryType]].<br> | ||
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. | 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. | ||
Line 52: | Line 52: | ||
==Actually, you can have two player-owned mutations== | ==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 {{ | I lied above so that you could more easily understand the MakeInfantry logic first. In truth, by using {{f|InfDeath|8|link}}, you can spawn a second [[InfantryType]] that will be player-owned. However, in order to make use of {{f|InfDeath|link}} 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 {{f|MakeInfantry|link}} flag at the top of this page).<br> | ||
But that really is it though, the other [[InfDeath|InfDeaths]] won't work for this. | But that really is it though, the other [[InfDeath|InfDeaths]] won't work for this. | ||
{{Bugs}} | {{Bugs}} | ||
*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 {{ | *The animation associated with {{f|InfDeath|link}} 9 '''must''' have a {{f|MakeInfantry|link}} flag and it must be set to a valid {{f|AnimToInfantry|link}} list index. If it doesn't, then the animation will not play at all. <small>[Actually, it doesn't have to have the {{f|MakeInfantry|link}} flag ''if'' it has instead a {{f|Next|link}} flag so that the last animation of a sequence of animations invoked by InfDeath 9 ''does'' have a {{f|MakeInfantry|link}} 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. --> | *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]] | ||
*[[InfDeath]] | |||
*[[DeathAnims]] | |||
*[[MakeInfantryOwner]] | |||
[[Category:RA2/YR Tutorials]] | [[Category:RA2/YR Tutorials]] |
Latest revision as of 09:26, 17 August 2024
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.