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

Infantry Linking

From ModEnc
Revision as of 12:43, 30 March 2008 by Gordon-creAtive (talk | contribs) (rw)
Jump to navigation Jump to search
Warning
This technique is generally discouraged because it requires complex work-arounds for the problems it causes and also invites Internal Errors. Only use this technique if you fully and entirely understood it. And if you fully and entirely understood it, there is no reason to annoy innocent forums with questions about it after you destroyed everything - after all, you fully and entirely understood what you were doing, right?


Infantry Linking is a technique used to fake that multiple independent InfantryTypes are in fact the same type of unit, meaning if one of these InfantryTypes is selected and the "Select all of Type" button is pressed, all of the linked infantries are selected, even though they're different units in code.

The most obvious and common usage of this is to link together the four dog types and the three engineers, since it is rather annoying if you have 30 Engineers on screen, and "Select all of Type" only selects 10.

Background

The secret lies in the deploy/undeploy modifications done for the Slave Miner in Yuri's Revenge: Even before YR, one could have a VehicleType deploy into a BuildingType by putting Template:TTL on it, and a BuildingType into a VehicleType by using Template:TTL. This was mainly used on the Construction Yard, and on the Nod Artillery in Tiberian Sun.

Now, for some reason only known to Electronic Arts (possibly related to Refinery code, since they are buildings), the coders of YR decided to use the same construct for the Slave Miner. The problem with this is obvious: Code-wise, the vehicle Slave Miner now turns into a building Slave Miner on deploy - but story-wise, that doesn't happen. It's just a vehicle.

So, as usual for our beloved programmers, they hacked it: They modified the deploy/undeploy code to treat the targets of each flag as the same unit as the one carrying the flag, making both vehicle Slave Miner and building Slave Miner be treated as the same object.

We wouldn't be modders if we didn't find a way to abuse this.

Usage

InfantryTypes cannot deploy/undeploy into other units. Nevertheless, if you put DeploysInto or UndeploysInto on a soldier, the "Select all of Type" hack is still applied. Thus, all we need to do is put deploy/undeploy flags on the soldiers we would like to treat as one kind, and we're set:

[ADOG]
DeploysInto=DOG
UndeploysInto=YADOG

[DOG]
DeploysInto=ADOG
UndeploysInto=YDOG

[YADOG]
DeploysInto=YDOG
UndeploysInto=ADOG

[YDOG]
DeploysInto=YADOG
UndeploysInto=DOG

[ENGINEER]
DeploysInto=SENGINEER
UndeploysInto=YENGINEER

[SENGINEER]
DeploysInto=ENGINEER
UndeploysInto=YENGINEER

[YENGINEER]
DeploysInto=ENGINEER
UndeploysInto=SENGINEER

The code above is the (already mentioned) most common application of this technique, taken straight from (older versions of) the UMP: It links together all three engineer types, and all four dog types. Were any of them selected ingame and you pressed "Select all of Type", all Engineers or all Dogs would be selected, no matter if they're originally Allied, Soviet, or Yuri.

This example also demonstrates how to link more than two InfantryTypes: "Circle deploying". Look at the engineers - each of them deploys into one other, and undeploys into the third one. Mind how problems might arise with the dogs - if ADOG is selected and "Select all of Type" is pressed - does YDOG get selected?

Also note that the hack works one-directional: ENGINEER is treated as the same type as SENGINEER due to DeploysInto=SENGINEER; SENGINEER is treated as the same type as ENGINEER due to DeploysInto=ENGINEER. Would either side be missing the link, then it would only work from the linking side, not from the not-linking, e.g. if SENGINEER was missing the hack, and ENGINEER was selected, then you could select both ENGINEER and SENGINEER through "Select all of Type" - but if SENGINEER was selected, "Select all of Type" would only select other SENGINEERs. All participating units must be linked to all other participating units for this to work.

Useful Applications

  • Make all Engineers be treated as the same unit type
    • When a Construction Yard is destroyed, the emerging Engineer is always an Allied one - even if you're Soviet or Yuri.
    • Yuri has mind control - he frequently "acquires" other sides' Engineers.
  • Make all Dogs be treated as the same unit type
    • In modes like Land Rush or Unholy Alliance, the player has access to all technologies, including up to four different types of dogs. Who ever takes the care to only build dogs of one kind in the middle of an infantry rush?
  • Create your own side-specific version of a unit
    • If you want to give the U.S. the advertised "best G.I.s in the world", for example, they'd technically be independent units, to be operated independently from the normal G.I.s; through Infantry Linking, all of your G.I.s would be selectable at the same time - no matter how special they are.

Problems and Limitations

  • You can only link up to three infantry units all to each other by using DeploysInto and UndeploysInto together.
  • The logic causes the game to think there are extra structures/vehicles in the game, with the IDs of the units you specify
  • You're sitting on a ticking time bomb:
If any of the linked InfantryTypes is modified by an overriding entity, like a map file or game mode INI, an Internal Error will occur when a human player positions their battlefield view over an AI-controlled War Factory.
Example 1:
rulesmd.iniENGINEERDeploysInto=something
mpmwmd.iniENGINEERTechLevel=-1
→ Internal Error will occur in Mega Wealth mode.
Example 2:
rulesmd.iniENGINEERDeploysInto=something
mymap.yrmENGINEERStrength=200
→ Internal Error will occur when playing on <mymap.yrm>.
Example 3:
mpbattlemd.iniENGINEERDeploysInto=something
somemap.mprENGINEERSpeed=2
→ Internal Error will occur when playing Battle mode on <somemap.mpr>.


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, which is why usage of this technique is strongly discouraged these days, and which is also the reason why the UMP does not include the Engineer and Dog "fixes" in its current versions anymore.

Safe Usage

The only safe way to use this technique is to only link InfantryTypes of which you can be sure they are never ever modified in a map, e.g. custom units from your mod with extremely uncommon, possibly random unit identifiers.

Tutorial on safe Usage by Marshall

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 Template:TTL to your GI clone.
    I don't think the flags Template:TTL and Template:TTL are even parsed, but if they are then they might need to be changed.
  4. Set Template:TTL 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 its Developer's Pack).

You should not attempt to make use of Infantry Linking unless you clearly understand every facet of this technique.

See also