Infantry Linking: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
This is a copy of the Infantry Linking document included with the [http://marshall.cannis.net/ump YR 1.002 Mini-Path (UMP) Developer's Pack] | This is a copy of the Infantry Linking document by Marshall included with the [http://marshall.cannis.net/ump YR 1.002 Mini-Path (UMP) Developer's Pack] | ||
== Infantry Linking using DeploysInto/UndeploysInto (Engineers, Attack Dogs, etc)... and why you shouldn't do it == | == Infantry Linking using DeploysInto/UndeploysInto (Engineers, Attack Dogs, etc)... and why you shouldn't do it == |
Revision as of 09:52, 1 October 2006
This is a copy of the Infantry Linking document by Marshall included with the YR 1.002 Mini-Path (UMP) Developer's Pack
Infantry Linking using DeploysInto/UndeploysInto (Engineers, Attack Dogs, etc)... and why you shouldn't do it
Infantry Linking is generally discouraged because it requires complex work-arounds for the problems it causes and also invites Internal Errors.
What is infantry linking?
When you press the 'select-all-of-type' button, all units of the same type as the one(s) you have currently selected will be selected as well. Infantry linking allows you to treat multiple infantry units as the same type, as far as select-all-of-type is concerned. Normally, if you have a GI selected and you press the select-all-of-type button, all GIs on the screen that you own will be selected as well. With infantry linking, you could end up having all GIs and all Navy SEALs selected too (and vice versa).
How does it work?
The Slave Miner is made up of two units; the vehicle form and the structure form. The vehicle form has the flag DeploysInto=YAREFN, and the structure form has the flag UndeploysInto=SMIN to allow the unit to change from one thing to the other. Part of the DeploysInto/UndeploysInto logic makes both unit types be treated as the same type by the select-all-of-type function.
Infantry cannot deploy (or undeploy) into another unit. But when you use the DeploysInto/UndeploysInto flags on an infantry, the select-all-of-type logic is still effected. From the above example: [E1] DeploysInto=GHOST
Would mean that Navy SEALs (GHOST) would be selected as well as GIs (E1) with a GI originally selected. However, it does not automatically work the other way around...
[GHOST] DeploysInto=E1
...would be needed for that.
You can link up to three infantry units all to each other by using DeploysInto and UndeploysInto together.
However you must bear in mind that the logic also makes the game think that there are extra structures/vehicles in the game, with the IDs of the units you specify. This causes the problems that we will discuss shortly.
Why is it needed?
Each side has it's own Engineer. But when an Engineer emerges from a destroyed Construction Yard, it is always an Allied Engineer. This means that when a Soviet player selects-all-of-type on an Engineer, they may not get all of their Engineers selected. Further more, Yuri can mind-control Engineers and so Yuri players could potentially gain access to all three Engineer units.
Similarly, there are 4 Attack Dogs in the game. In Land Rush mode especially, the linking problem occurs when a player gains access to multiple Attack Dog types.
Finally, you might add side-specific versions of a new unit type - they are not normally all selected at the same time either.
Infantry linking can be quite useful to avoid this problem (and sometimes eliminate it entirely).
Why shouldn't we use it?
Because it can cause Internal Errors if not used 110% properly.
An Internal Error can be caused by setting DeploysInto/UndeploysInto on an infantry unit, and then modifying that infantry unit's entry in a subsequent override rules-set. Thusly:
Example1:
rulesmd.ini > ENGINEER.DeploysInto=something
mpmwmd.ini > ENGINEER.TechLevel=-1
Internal Error will occur in Mega Wealth mode.
Example2:
rulesmd.ini > ENGINEER.DeploysInto=something
mymap.yrm > ENGINEER.Strength=200
Internal Error will occur when playing on <mymap.yrm>.
Example3:
mpbattlemd.ini > ENGINEER.DeploysInto=something
somemap.mpr > ENGINEER.Speed=2
Internal Error will occur when playing Battle mode on <somemap.mpr>.
The Internal Error occurs when a human player positions their battlefield view over an AI-controlled War Factory.
Note that the error may be caused by modifying the 'to' unit of a link, rather than modifying the 'from' unit. The exact details of the cause of the error are not yet established.
Because you have no control over what modifications any custom maps might include, it is very difficult (and even impossible on certain game modes/map filters) to guarantee that your mod will not be the cause of Internal Errors.
The disadvantages of missing infantry links are insignificant when compared to the huge disadvantage of an Internal Error occuring.
Previous versions of the UMP included infantry linking on the Engineers and Attack Dogs as part of the core fixes, however such 'fixes' have since been repealed.
There must be some way we can use this?
Well, yes there is. A common example of two units that you may wish to link are two types of GI: A buildable one and a paradropped one.
1. Make a clone of [E1] and give it an ID that is 99% likely to be unique. Some sort of alphanumeric serial number that is truly random would be good. (Ideally, you want all of your custom units to have an ID that nobody else could possibly use in a map.) All elements of a linked-infantry group should have totally unique IDs.
2. The original GI ([E1]) should be made unbuildable by human players. The only way I know of doing this is to give it a Prerequisite of a building that could never possibly exist on a custom map. This dummy building should be properly defined in your code and have a unique ID. AI players ignore prerequisites and so will still be able to build the original GI.
3. Set AlliedCrew= to your GI clone. I don't think the flags Pilot= and PParatrooper= are even parsed, but if they are then they might need to be changed.
4. Set AllowedToStartInMultiplayer=no on the original GI (and 'yes' on your GI clone).
Obviously the AI scripts can be left alone as the AI is unaffected.
It's quite a bit of work but it will allow you to use infantry linking 99% safely.
Two problems still remain though: 1. You can mind-control a unit from a computer-controlled player that will not be covered by the appropriate infantry links. (Presumably you could replace all occurrences of a unit with its clone, in <aimd.ini>, in order to avoid this problem.) 2. Any changes to the GI that are introduced by a mod-map will only apply to AI-built GIs, not to human-built GIs. (Again, if you made the appropriate modifications to <aimd.ini>, at least mod-map changes would not apply at all.)
If your mod supports the original single player campaigns then you will have another problem because some of the maps may modify the units that you are trying to link in this manner (for example, the Engineers). To overcome this, either you will have to NOT link the units in the campaigns (by only making the modifications in the appropriate game modes) or you will have to include a modified copy of the maps in question (in which case don't forget that all of the single player maps have already been bug-fixed by the UMP and are included in this Developer's Pack).
You should not attempt to make use of infantry linking unless you clearly understand every facet of this document.