Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Thu Jan 16, 2020 5:58 pm Post subject:
Aerial Deployment of JumpJet Infantry by ParaDrop [Ares]
When JumpJet infantry is deployed by a ParaDrop, it will parachute to the ground like any other infantry and will only take flight again once ordered to move. It might be desired to rather deploy flying JumpJet infantry.
When infantry is created via MakeInfantry above ground-level, then such infantry will stay at the altitude at which they are created, until ordered to move, in which case they will instantly appear on the ground and move from there. This is, however, not true of JumpJet infantry: JumpJet infantry will remain at the height at which it was created until given a reason to move, and then visibly ascend or descend to its JumpJetHeight, if they were created at a different height, and fly around at this level. In this way, it is possible to use MakeInfantry for aerially deploying JumpJet infantry. It is possible to simply deploy an attack aircraft firing an instant-denotation projectile carrying a warhead with an animation that makes JumpJet infantry, and projectile Cluster settings may be used to modify the number of infantry so created. However, the following method is designed to allow the deployment of JumpJet infantry via ParaDrop-type SW, giving the placement pattern, and with the ParaDropNum customizability and mixable Types, of other ParaDrop-type SWs. It can potentially be used to deploy other hovering things, provided they are coded as InfantryTypes, such as aerial mines, flares or point-defense drones.
All IDs are interchangable, so long as they are replaced consistently.
1) Create an entity that is to be para-dropped, add it to the "InfantryTypes" list, and the "ParaDrop.Types" of a Paradrop SW that you intend to deploy JumpJet infantry.
;------------------------------------------------------------------------------
[Dummy_878E6E48A534A]
UIName = Name:Dragoon
Name = Dragoon
Image = NULL
Insignificant = yes
Strength = 1
Size = 1
Selectable = no
PixelSelectionBracketDelta = 9999
TechLevel = -1
RadarVisible = no
RadarInvisible = yes
Armor = special_4328CCBE94DE8
ImmuneToPsionics = yes
Parachute.Anim = NULL
DeathAnims = DragoonMake
AttachEffect.Animation = InvisibleHurt_C5E36
AttachEffect.Duration = -1
DontScore = yes
Points = 0
Bombable = no
LegalTarget = no
AllowedToStartInMultiplayer= no
Trainable = no
2) Add the animations to the "Animations" list, and add the ID of the JumpJet infantry you want the SW to deploy to the "AnimToInfantry" list. As usual, subtract 1 from the numerical position on this list, and memorize the resulting number.
3) Add the dummy's ArmorType to the ArmorTypes list. I think it is not a prerequisite that the dummy cannot be harmed by anything other than its pre-programmed self-destruction, but just to fend off possible issues, it seems safe.
4) Add the warhead to be used for the AttachEffect. It seems safer to add it to the Warheads list as well. Again, I am not sure whether it is necessary that the warhead is incapable of damaging only the dummy, especially since there are other situations where a self-damaging animation may be needed, but, again, it seems safer.
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Mon Jan 20, 2020 4:42 pm Post subject:
On a second thought, this can also be used to create JumpJet survivors from aircraft.
Quote:
That's cool. But what's the point of using incomprehensible hex numbers
These are a way to avoid the hassle of keeping track of unused numbers in the *Types lists when using #include. When simply using increasing numbers, one runs the risk of re-using an already assigned number, unless checking the lists every time. When using a randomized string, the risk of re-using an already assigned string is minimized while circumventing the need to re-check the lists. Since *Types lists can be appended in INI files listed in #include, the need to look at the *Types lists in rulesmd.ini does not arise anyway, making this a handy method of saving micromanagement. Furthermore, using randomized strings, entries are in all probability directly integratable in another person's INI files, should someone want to simply copy my code. Any low, serially-derived number would run the risk of already being in use in the paster's own INI files, which means that they would have to go through the effort of changing them. Using randomized string, probability for this occuring is low, reducing workload to simple copy-paste. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
This adds them to the end of the list in order of [#include]. Also just don't be lazy and look at the lists instead of making your rules incomprehensible to anyone else. _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
This adds them to the end of the list in order of [#include].
I had no idea that this feature existed. It's not documented. This is a great improvement at least for left-hand list entries. Thanks!
Quote:
Also just don't be lazy and look at the lists instead of making your rules incomprehensible to anyone else.
This, on the other hand, is not a good reason; I do not think this is incomprehensible. All that is required is to copy and paste. Semantic understanding is irrelevant. I think I prefer efficiency to conforming to not being lazy. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum