ModEnc² - User contributions [en]

Movies

2006-11-05T13:20:18Z

80.177.214.142: note on parsing last entry.

{{WrongTitle|[Movies]}}

This section comprises a 0-based list of all movies in the game. This list is used to play radar/fullscreen videos in the singleplayer campaign. Due to a problem in the RA2/YR parser, the last item on this list will not be recognised by the game and so you will need to place a dummy entry last to ensure you can use all the actual movies.



[[category:Art(md).ini Sections]]

Dropship Loadout

2006-08-16T22:46:47Z

80.177.214.142:

==What is the Dropship Loadout==
The dropship loadout is a feature that was cut from Tiberian Sun late in its development and presists in a somewhat buggy form in RA2 and YR. In TS, the feature was to present the player with a screen where he could purchase units that would be delivered to him as a scripted reinforcement during the mission that followed. The feature could be made to work almost perfectly for single player missions with the exception that the mouse cursor didn't show up, making it difficult to select units. The screen also didn't make it clear that to progress from it, the player needed to press the space key. In RA2, the screen still lacks a visible mouse cursor, but also uses the wrong chracter set for describing the units before purchase. The box draw around icons when they are highlighted is also the wrong size, due to changes in the icon size used by RA2. Apart from these issues, the only other problem is the art work for the screen whch does not fit RA2.

==Using The Loadout Screen==
To access the loadout screen prior to a mission, the map file must contain the line StartingDropships= in the "Basic" section. The value for the flag must be either 1, 2 or 3 and specifies how many dropships the player will be able to specify the contents of. To actually recieve the reinforcements, there must be a reinforcement trigger that creates a team with only a Dropship unit in the taskforce. The logic should fill the transport with the units ordered. <br>
The player can be limited in several ways as to what they can buy. First of all, they are limited to being able to select units that have the player country set in the units Owner= entry. In RA2, the loadout ignores RequiredHouses= ForbiddenHouses= and RequiresStolenXTech=. There are controls available that can adjust what the player can and cannot purchase as a reinforcement however, as well as how many of each unit. Both of these controls are specified in a maps "Basic" section as well. AllowableUnits= specifies what units are available to purchase using a comma seperated list and is based on the unit section names from rules.ini. AllowableUnitMaximums= is another comma seperated list that has the same number of entries as the Allowable units and sets the number of each unit that is allowed to be purchased (-1 gives unlimited). The TechLevel of the player house/country is also believe to limit what can be purchased but this has not been confirmed. The amount of credit available to buy units is the amount set to be available for the player house, if no credit is available it seems to give an IE when you exit the screen (in RA2 at least).

Legacy RockPatch Wishlist

2006-08-16T20:38:40Z

80.177.214.142:

__NOTOC__[[Category:RockPatch]]{{RockPatch}}

{| align="center" width="98%" class="table_parted"
!colspan="2"|Introduction
|-
|width="50%"|<div align="center">'''What this List is'''</div>You're looking at the community-editable wishlist for [[User:pd|pd]]'s [[RockPatch:Main|RockPatch]].

If you would like to see a specific feature added to RockPatch, add it at an appropriate place on this list. ''Do not contact pd in any other way.'' It just doesn't work that way. If the entire community started IM sessions and bugged pd about features the moment he signed on, he'd soon quit making the patch at all.<br>
As such, all wishes ''not'' made through the wishlist will be ignored. (And, most likely, pd will remember you in a way not helping other wishes you have.)

Also note [[RockPatch:Votelist|the Votelist]].
|width="50%"|<div align="center">'''What this List is not'''</div>
*This is '''not''' a list of ''demands''.
*These are '''not''' features that ''are'' already implemented.
*This list does '''not''' guarantee the feature ''will'' be implemented.
|-
|width="100%" colspan="2"|<div align="center">'''Where to put your Wish'''</div>
*There are several topical lists, choose the one that fits best.
*Newer wishes are added to the bottom.
*The list was spread over several pages for a reason. ''Keep it that way.'' (Look at the history to see why.)

'''Example:''' You wish to request a warhead-feature. That would, of course, be a Totally New Feature. However, ''Weapons related'' fits even better for something about warheads. Weapons related is on Page 5. So your wish belongs to Page 5, Weapons related, at the bottom of the list.
|}

{{quote|pd|I just want to underline that this is not a demand list but only a collection of ideas because I'm the only person who has the possibility to change anything at the moment... teaching others how to do this would be a solution but it would mean much learning to them (I think).<br>
I will choose the easiest for me and the most useful for the community things first.<br>
So don't be angry if you're wish doesn't get "fulfilled".}}

=General Bugfixes/Corrections=
{{Wishlist/TOC}}
*Fixing the 74-unit-bug, aka whiteboy bug
*Fixing of the "Tank Bunker only allows ground locomotor units" issue (it should allow hover locomotor too).
*Fixing of the "TIBMINExx is hardcoded to spawn xx entry from {{tt|[Tiberiums]}}" issue, preferably changing xx to an INI-controlled value
*Fixing of the "{{tt|AttachedParticleSystem=}} nullifies {{tt|Burst=}}" issue
*Fix various hardcoded YR bugs. See {{tt|[http://marshall.cannis.net/ump/index.htm#bugs]}} for list.
*Fix Carryall Logic for Hind.
*Fix Debris Logic/Improve it
*Rumor has it that {{tt|NonVehicle=yes}} does not actually block Vehicle Hijackers, it just gives a no entry cursor and still lets them hijack...this needs fixing.
*{{tt|NonVehicle=yes}} also needs to prevent the Tote action (carryall logic) from grabbing the unit too.
*{{tt|UseOwnName=true}} cannot be used on a VehicleType (only InfantryTypes). Any vehicle placed inside an IFV will cause the IFV to have a name of "Rocket IFV" (or Repair/Machine Gun if IFV mode 1/2/3).
*Any way to optimize cloaking code or speed it up
*Fix VehicleThief and Thief logic (currently, you need both to get hijackers to work but the infantry can then enter refineries to no effect)
*Fix the PrismSupportModifier bug (if a {{tt|[General]}} section is declared on a map and a value is not defined there, the value is set to infinite or something)
*The use of {{tt|HoverPad=yes}} causes an Internal Error if the AI uses a Nuke or Weather Storm. This is a pain because the {{tt|HoverPad=yes}} can be used to make hover units land on service depots and, better yet, allows an airpad to come with a free aircraft - but we can't use it because of the damned IE!<br>Not so much of a problem, see discussion.
*having 2 PKT files makes some maps get listed ingame twice. can you fix this?
*Fix adding new {{tt|[BuildingTypes]}} breaking single player campains. See this link for a better description: [http://www.cannis.net/tutorials/ra2yr_nobreak_yrmissions1/]}}
*Fix code so you can build all units of a BuildLimit >1 in a row<br>(right now, if you have {{tt|BuildLimit=10}}, for example, you can only build 9, something else, and then the last one)
*The 'sell unit' function can be resurrected using a super weapon. However, you can sell any docked unit, including Tank-Bunkered units. Selling a Tank-Bunkered unit leaves the Tank Bunker walls up, rendering it useless. Selling the Tank Bunker then causes an Internal Error. Now, we don't want 'sell unit' forcibly resurrected, however it would be nice if either A) Tank-Bunkered units couldn't be sold (preferred choice), or B) Tank-Bunkers' walls retracted and the Bunker continued to work normally (second choice), or C) selling a 'broken' Tank Bunker did not cause an Internal Error.
*HarvestersPerRefinery - Make this usable
*A rules option so that units will consider in their threat scan neutral player-owned units that have a weapon or non-zero threat rating. It's so annoying if your mod has something that generates neutral infantry opponents that your units and, more importantly, the AI completely ignores.
*fix the "AI doesn't deploy MCVs with new locomotors set on them" bug(IE hover, jumpjet, subter...)
*Fix the Droppod Locomoter
*Force refresh when returning from game-mode menu to apply changes to the menu made by a game mode, such as money range, or starting units range.
*Tote action (carryall logic) and Heal action (negative damage weapon given to an infantry) need to point to sequences in mouse.sha rather than to the same single frame.
*If an AnimToInfantry call occurs for an animation that is positioned in a place where no infantry can land then the call will be suspended (potentially for the remainder of the game). This is believed by some to cause a general game slow down. Either way, it doesn't look nice. Perhaps the call could be cancelled if there is no space...
*{{tt|WeaponXTurretLocked=true}} "bug" when unit turns 180 the turret may spin in the opposed direction instead of following with voxle nit’s direction.
*{{tt|AccelerationFactor=0.01}}; This has a problem with voxel scales.
*{{tt|IsTrain=yes}}, {{tt|MovementRestrictedTo=Railroad}} one of these has the control for the train movement and the turn is 135 or 90 but the train should only turn 45 to prevent jumping tracks.
*in RA2 you can place a PKT with a map/maps in a mix, and rename it to an MMX and the map will work, like a map pack, however, the YR equevalant YRO(as documented by deezire) files don't actually work. my idea is to try and make them work!
*Improve the havester logic so it (the harvester) cannot go to an enemy base (and then get killed) when there is an Ore on it (enemy base)
*Factory Plant Settings reduce Solyent values to prevent income generation explotation. (If implemented, this should definitely be optional - I myself reduce soylents manually so I don't want them reduced further by owning an Industrial Plant.) By default vehicle refund should be 50%. Basically if you make a vehicle 25% cheaper, you should only get 50% of its value back
*Code the {{tt|Hospital=yes}} and Machine Shop tag so that owning multiple buildings does generate an undocumented cumulative effect.
*The game reads langmd.mix > missionsmd.pkt and uses it to determine which gamemodes the stock maps are available in. Editing this file and dropping it in the directory causes random bugs and duplicate entries in the map list. If possible, add a rules tag pointing to a filename to read ''instead'' of missionsmd.pkt (de-hardcode the reference, like the {{tt|IsIFV=}} and similar new tags do). Like {{tt|[General]}}-->{{tt|PKTFile=}} .
*A fix for the ridiculous slowdown caused by having an extra CD drive or too-good hardware. In my case, my P4 3.0GHz and GeForce 5900 are (my the sound of it) the two pieces of hardware that stop me running YR...
*Fix the currently unworking {{tt|CloakStop=}} tag
*Fix it so that your computer doesn't have to be in 16-bit colour for the windowed mode (from adding -WIN to a shortcut) to work, i.e. it supports 32-bit colour too.
*Make Fighters/Aircraft Cloakable with their own cloaking unit and can dogfight, ATA without {{tt|Jumpjet=}} or altering the height-fongsaunder
*Allow aircrafts/copters to transport vehicles correctly, not by setting a ridiculous ammount of transportable units. (ex: you'd have to set the Hind and the NightHawk to have alot of pips, about ten, just so one tank could fit in it)
*Allow rotors to work with Aircraft units (not just copters) correctly without any bug.
*Fix the error when having a gate that slides down (TS style) instead of opening sideways which made the gate appear OVER a unit passing on the downed gate.
*Fix it so that when you add a superweapon upgrade to a building that has a superweapon, it overwrites the previous superweapon, instead of just adding it as a new superweapon (perhaps make it an optional tag)
*Make {{tt|PrismType=}} support more than one
*Bring back mine layer codes
*Fix voxel size units that is bigger than a tank. Eg.: Like if you have a mech or walker unit that is bigger than a 1x1 square.Wish voxel size can be user define like {{tt|VoxelSize=2x2}},like what you can do for buildings.
*Enable the Robotic Centre to accept more than 1 robotic units and if it is destroyed and rebuilt,the robotic units that are more than the first one can be shaken out from their shut down mode. This should also fix a problem with mods that have Vehicle Hijackers and more than 1 type of Robot Tank.
*Enable a Psi-Warning animation for the intended target of any superweapon, not just the nuke and its clones.
*Make a unit ELITE with the armory should coast money, like EliteInfantryCoast=3000, armory is to cheaty right now
*Make so a [vehicletype] can spawn an othe [vehicletype]
*Fix the issues with the 'Dropship load screen' and alter its logic so it is possible to specify the units to use as the 'DropShip', preferably any type of unit, not just aircraft.
*<s>Make so a unit only can built by a specefic warfactory, like BuildOnly=HTNK(on the new warfactory) This is good so big tanks can spawn on a big factory</s> (see the [[RockPatch_talk:Wishlist#Re:_BuildOnly|talk page]])
*Make weapon that, when you fire a unit, you get extra hp, like ih Damage is 100, thats mean you take 100hp from them and add 100hp to you
*BUG: Flipping other tanks... If a tank is to heavy and cant be flipped, the heavy tank get permanetly emp and the tank with flipper weapon cant flipp other unit the heavy tank is dead(not rp bug)
*Fix so AI dont build more unit than the buildlimit
*make the tunnel system works(like generals that GLA uses)
*In game,when you press esc, there should be a OPTIONS button there
*Make a magnetic push weapon yhat pushes other vehicles away
*Subterrainean units that have occupants that can fire out of the unit like the Battle Fortress can fire at targets even when traveling underground.
*Repair bugs with DropShip load out screen and change cameo highlight to size of RA2 icons.

==Done==
*Breaking of the 100-unit-limit

CnC Timeline

2006-07-05T22:22:28Z

80.177.214.142:

== The CNC Timeline ==

For a far more detailed timeline, visit http://www.planetcnc.com/features/encyclopedia/

Some info is also available at http://en.wikipedia.org/wiki/Command_%26_Conquer

The CNC Timeline is most frequently considered to go like this:

GDI Wins GDI Wins - Ending #1
Allies Win - Ending #0 / \ /
Red Alert 1 < Tiberian Sun FireStorm
Soviets Win / \ \
\ GDI Wins Nod Wins Nod Wins - Ending #2
\ / \
Tiberian Dawn Ending #3
\
Nod Wins - Ending #4

Soviets Win - Ending #5
Red Alert 2 <
Allies Win
\
\ Allies Win - Ending #6
Yuri's Revenge <
Soviets Win - Ending #7

=== Ending 0 ===
Stalin is dead, Europe is free, all is well.

=== Ending 1 ===
CABAL destroyed, Nod in the hiding, Tacitus decoded, the world is safe once again.

=== Ending 2 ===
CABAL presumed destroyed, GDI scattered, Kane stil alive in a cloning vat, to be continued...

=== Ending 3 ===
The world is pwned by Nod's tiberium missile. Nasty.

=== Ending 4 ===
World does NOT get NUKED. Kane and his hackers infilitrate gdi satellite command and allow player to ion cannon famous momuments in London, Paris, Berlin or Washington DC but basically bad :p

=== Ending 5 ===
The Allies conquered, the player is in supreme control, Yuri presumed dead under the rubble of Kremlin.

=== Ending 6 ===
Yuri imprisoned, soviets have signed the treaty, everything under control.

=== Ending 7 ===
Yuri in Jurassic Era (gets eaten by T-Rex), Allies surrendered, Romanov in control. USSR builds space station and owns Moon.

=== Dates of Events ===

Red Alert 1: 1948 - 1952

Red Alert 2: 60's - 70's

Yuri's Revenge: starts one day after the ending of Red Alert 2

Tiberian Dawn: 1995

Tiberian Sun: 2030 - 2031

Firestorm: 2032

=== Cross-pollination of Red Alert and Tiberian series' ===
In an interview with Frank Hsu (Yuri's Revenge producer) it was pointed out that
"The Tiberian series is an eniterly different game and universe"
and so the two series do not really belong on the same timeline. It should be noted however that this appears to be an attempt at 'retconning' the obvious ealier decision by WestWood that the games are linked by both the inclusion of Kane and mention of the formation of GDI in RA1.

Legacy RockPatch Wishlist/Page 2

2006-06-29T20:15:43Z

80.177.214.142: /* Enhancements */

{{RockPatch}}
=Enhancements=
{{Wishlist/TOC}}
*True Air-to-Air combat
*More "special" mouse-cursors, like C4 or the SW-cursors (if possible, this should be implemented via tags, pointing to exact mouse.shp frames to use, like [Weapon]AttackCursor=start_frame,end_frame; [Unit]Move/Deploy/EnterCursor= )
*More IFV-modes (and more IFVs, as the turret-changing code is now locked to the FV unit)
*Another IFV turret flag. At the moment we can have 18 IFV Modes but only the first 17 of those modes can have a turret.
*An adjustment of several AI shortcomings (such as inability to "attack enemy vehicle called ' ''XXXX'' ' ")
*Allowing "PoweredUnit/PowersUpBuilding" to have a set of values, not just one
*Allowing paradrops to consist of units as well as infantry
*Allow buildings to cloak without being a CloakGenerator or a veteran/elite building.
*Add new colors to the Skirmish menu color lists [pd]
*an INI file to allow custom terrains mods to customize the random map generator [pd] [djbreit]
*Allow Crewed= to work with non infantry types.
*Air units with turrets
*Temporal particles?
*Another promotion level
*Cloaking aircraft (possible by adding CLOAK on Veteran,Elite Abilities=)
*Infantry to vehicle repair (also Infantry to building and so on)
*Allowing carryalls to pick up enemy vehicles, acting possibly in the same way as the 'advanced carryall' in Emperor: Battle for dune (Lands on enemy vehicle and has a delay before being able to move the unit). Preferably added using a seperate tag to allow use of the original carryall funtions.
*Enabling SpySat= or any building fuctions for Upgrade system in buildings
*Making a new type of Ore.
*Enable VehicleTypes to deploy into VehicleTypes in addition to default BuildingTypes. Or enable deploying vehicles (such as Seige Chopper) to adopt traits other than just the "Image=" from the rulesmd entry for the UnloadingClass "dummy" object.
*Infantry that can be powered
*Modify Spawn Logic to allow for the spawning of VehicleTypes not just AircraftTypes.
*Increased flexibility of slave logic: expanded range of units can have slaves (eg. ambulance with medics etc.) - Also SlaveBehaviour= tag which uses SlaveMiner or such when omitted for compatibility
*Increased flexibility in powered logic: control centre handles more than just robot tanks.
*Get the Ammo system to work with infantry and buildings. Presently, it only works with vehicles and aircraft.
*MigAttackCursor=yes works only for buildings, would be good to work with other units types as well.
*more ressource types (e.g. Iron, Gold/Diamants and Oil)
*Enable the optional use of a seperate pallete for the radar in the GUI, as would be prefered for new GUIs.
*Program more Foundation sizes for buildings, including non-rectangle shapes.
*Making it so the trains can go in revers and couple & uncouple
*UnDeploy cursor on deployed objects
*NeedsDriver= to make a vehicle only usable if an infantry unit is sent in it
*NegativePrerequisite= that could be set for objects too, disables building/training of the caller if the object on the list exists (allowing for choice of tech trees, one type of hero etc.
*Allow Prerequisite=, PrerequisiteOverride=, Prerequisite groups and any new Prerequisite tags (e.g. NegativePrerequisite=) to allow VehicleTypes, InfantryTypes and AircraftTypes. (PrerequisiteProcAlternate= is the only one that presently accepts VehicleTypes.)
*PrerequisiteAlternate1=, PrerequisiteAlternate2= that allow an alternative prerequisite option. Example: Prerequisite=GAWEAP,GATECH ++ PrerequisiteAlternate1=NAWEAP,NATECH would mean that with both an Allied or Soviet War Factory and Battle Lab you could build the object in question (but not Yuri).
*Un-hardcode the dock location on refinaries to allow smaller refinaries and refinaries with multiple dock locations.
*If a unit collects a crate type that it is not allowed to (e.g. untrainable unit collects a promotion crate) then you get a money crate - BUT there are two types of money crate - the money crate that is defined in Powerups that you can modify is not the crate type you get in the scenario descibed above. In the scenario descibed above you get a random amount of cash. What we need is a way of controlling this other money crate (so that it's random credits can be defined as between two specified values (which could both be the same to stop the amount being random). Sorry for the long description.
*Make units able to survive if they are in a transport of a different MovementType (e.g. tanks in amphib transports)
*Create "ForceFire=" tag to allow the moder to choose what weapon should be fired when force firing on terrain/trees/bridges etc. moders use primary against inf only and secondary for everything else in a lot of instances, but when force firing, the primary is always used, meaning that unit could never destroy trees/bridges. force fire could be set to secondary weapon(3rd/4th ect if more are added) or a seperate weapon.
*adding more overlays to the game
*UseINI= in maps to use a centralized file for modmaps rather than modifying each on it's own
*Countries can have VeteranInfantry=, VeteranUnits=. How about adding VeteranBuildings= and VeteranAircraft=, as well as any country-specific properties that don't currently apply to BuildingTypes?
*Find hardcoded items (e.g. animations, units, buildings, infantry and such) and make them un-hardcoded
*make the NukeSiren to use NukeSound instead of DigSound so you don't hear the nuke siren when you use units with "Dig locomotor" (this can be done with unpacthed game by disabling the DigSound and attaching the NukeSiren directly to nuke animation, but this way it sucks) [C001DuDe]
*A tag for warheads called DamageEnemy=yes/no. Propoganda style, area effect discriminate healing weapons.
*Make more building features work when added by a structure upgrade.
*Make aircrafts do "normal landing" not just vtol (veteran take off and landing) all the time on airforce command centers. Make them land diagonally and make them seem to use landing gears by allowing them to skid a little when landing.
*Get rid of the IE that happens when you try to cancel a building construction yard, if you make them buildable [Nighthawk200]
*Multiple entries in Factory= tag, so that you can build both infantry and vehicles or vehicles and buildings etc. from the one building. [Nighthawk200]
*Builings can have more than two SWs -Nighthawk200 ''[edited -pd]
*Allowing more than just alternate Arctic art, e.g. alternate desert art, for desert camo, or (if you wanted to be really bizarre - Alternate Lunar Art) Another idea would be to let these tags be used on units as well as infantry (so you could get snow camoed tanks) -Nighthawk200
*Allow units inside structures to target things individually so they dont all attack the same thing all at once but rather spread their fire on attacking units.
*Allow a new type of air combat, like in Act of War Direct Action, the aircrafts can be built and called in to airstrike a unit, building, aircraft, two or all 3 of the mentionned before. A destroyed aircraft would have to be rebuilt. You could still keep the limit of 4 aircrafts per air control tower/whatever the "devil" you wanna call it. (Alex05)
*Add a tag "GateTwoDirections" which automatically sets the direction of a gate to either right or left when putting it on a wall, this would allow for only 1 build icon for gates instead of 2. (Alex05)
*Allow any superweapon to be specified as a crate pickup instead of just the Nuke/whatever is top of the superweapon list.
'''Rejected:'''
*abillity to change taunt files
:''Comment: you can always edit, replace or do whatever with them... what's the deal with this? [- pd]
*"Symlinks", i.e. declaring new names for existing tags
:''no comment... [- pd]

Legacy RockPatch Wishlist

2006-06-29T20:13:34Z

80.177.214.142: /* General Bugfixes/Corrections */

__NOTOC__[[Category:RockPatch]]{{RockPatch}}

{| align="center" width="98%" style="border: 1px solid #aaaaaa; background:#e5e5e5; border-spacing: 5px;"
! colspan="2"|Introduction
|-
|width="50%" style="border: 1px solid #aaaaaa; background:#F0F0F0; padding: 5px; vertical-align: top;"|<div align="center">'''What this List is'''</div>You're looking at the community-editable wishlist for [[User:pd|pd]]'s [[RockPatch:Main|RockPatch]].

If you would like to see a specific feature added to RockPatch, add it at an appropriate place on this list. ''Do not contact pd in any other way.'' It just doesn't work that way. If the entire community started IM sessions and bugged pd about features the moment he signed on, he'd soon quit making the patch at all.<br>
As such, all wishes ''not'' made through the wishlist will be ignored. (And, most likely, pd will remember you in a way not helping other wishes you have.)

Also note [[RockPatch:Votelist|the Votelist]].
|width="50%" style="border: 1px solid #aaaaaa; background:#F0F0F0; padding: 5px; vertical-align: top;"|<div align="center">'''What this List is not'''</div>
*This is '''not''' a list of ''demands''.
*These are '''not''' features that ''are'' already implemented.
*This list does '''not''' guarantee the feature ''will'' be implemented.
|-
|width="100%" style="border: 1px solid #aaaaaa; background:#F0F0F0; padding: 5px; vertical-align: top;" colspan="2"|<div align="center">'''Where to put your Wish'''</div>
*There are several topical lists, choose the one that fits best.
*Newer wishes are added to the bottom.
*The list was spread over several pages for a reason. ''Keep it that way.'' (Look at the history to see why.)

'''Example:''' You wish to request a warhead-feature. That would, of course, be a Totally New Feature. However, ''Weapons related'' fits even better for something about warheads. Weapons related is on Page 5. So your wish belongs to Page 5, Weapons related, at the bottom of the list.
|}

{{quote|pd|I just want to underline that this is not a demand list but only a collection of ideas because I'm the only person who has the possibility to change anything at the moment... teaching others how to do this would be a solution but it would mean much learning to them (I think).<br>
I will choose the easiest for me and the most useful for the community things first.<br>
So don't be angry if you're wish doesn't get "fulfilled".}}

=General Bugfixes/Corrections=
{{Wishlist/TOC}}
*Breaking of the 100-unit-limit
*Fixing the 74-unit-bug, aka whiteboy bug
*Fixing of the "Tank Bunker only allows ground locomotor units" issue (it should allow hover locomotor too).
*Fixing of the "TIBMINExx is hardcoded to spawn xx entry from {{tt|[Tiberiums]}}" issue, preferably changing xx to an INI-controlled value
*Fixing of the "{{tt|AttachedParticleSystem=}} nullifies {{tt|Burst=}}" issue
*Fix various hardcoded YR bugs. See {{tt|[http://marshall.cannis.net/ump/index.htm#bugs]}} for list.
*Fix Carryall Logic for Hind.
*Fix Debris Logic/Improve it
*Rumor has it that {{tt|NonVehicle=yes}} does not actually block Vehicle Hijackers, it just gives a no entry cursor and still lets them hijack...this needs fixing.
*{{tt|NonVehicle=yes}} also needs to prevent the Tote action (carryall logic) from grabbing the unit too.
*{{tt|UseOwnName=true}} cannot be used on a VehicleType (only InfantryTypes). Any vehicle placed inside an IFV will cause the IFV to have a name of "Rocket IFV" (or Repair/Machine Gun if IFV mode 1/2/3).
*Any way to optimize cloaking code or speed it up
*Fix VehicleThief and Thief logic (currently, you need both to get hijackers to work but the infantry can then enter refineries to no effect)
*Fix the PrismSupportModifier bug (if a {{tt|[General]}} section is declared on a map and a value is not defined there, the value is set to infinite or something)
*The use of {{tt|HoverPad=yes}} causes an Internal Error if the AI uses a Nuke or Weather Storm. This is a pain because the {{tt|HoverPad=yes}} can be used to make hover units land on service depots and, better yet, allows an airpad to come with a free aircraft - but we can't use it because of the damned IE!<br>Not so much of a problem, see discussion.
*having 2 PKT files makes some maps get listed ingame twice. can you fix this?
*Fix adding new {{tt|[BuildingTypes]}} breaking single player campains. See this link for a better description: [http://www.cannis.net/tutorials/ra2yr_nobreak_yrmissions1/]}}
*Fix code so you can build all units of a BuildLimit >1 in a row<br>(right now, if you have {{tt|BuildLimit=10}}, for example, you can only build 9, something else, and then the last one)
*The 'sell unit' function can be resurrected using a super weapon. However, you can sell any docked unit, including Tank-Bunkered units. Selling a Tank-Bunkered unit leaves the Tank Bunker walls up, rendering it useless. Selling the Tank Bunker then causes an Internal Error. Now, we don't want 'sell unit' forcibly resurrected, however it would be nice if either A) Tank-Bunkered units couldn't be sold (preferred choice), or B) Tank-Bunkers' walls retracted and the Bunker continued to work normally (second choice), or C) selling a 'broken' Tank Bunker did not cause an Internal Error.
*HarvestersPerRefinery - Make this usable
*A rules option so that units will consider in their threat scan neutral player-owned units that have a weapon or non-zero threat rating. It's so annoying if your mod has something that generates neutral infantry opponents that your units and, more importantly, the AI completely ignores.
*fix the "AI doesn't deploy MCVs with new locomotors set on them" bug(IE hover, jumpjet, subter...)
*Fix the Droppod Locomoter
*Force refresh when returning from game-mode menu to apply changes to the menu made by a game mode, such as money range, or starting units range.
*Tote action (carryall logic) and Heal action (negative damage weapon given to an infantry) need to point to sequences in mouse.sha rather than to the same single frame.
*If an AnimToInfantry call occurs for an animation that is positioned in a place where no infantry can land then the call will be suspended (potentially for the remainder of the game). This is believed by some to cause a general game slow down. Either way, it doesn't look nice. Perhaps the call could be cancelled if there is no space...
*{{tt|WeaponXTurretLocked=true}} "bug" when unit turns 180 the turret may spin in the opposed direction instead of following with voxle nit’s direction.
*{{tt|AccelerationFactor=0.01}}; This has a problem with voxel scales.
*{{tt|IsTrain=yes}}, {{tt|MovementRestrictedTo=Railroad}} one of these has the control for the train movement and the turn is 135 or 90 but the train should only turn 45 to prevent jumping tracks.
*in RA2 you can place a PKT with a map/maps in a mix, and rename it to an MMX and the map will work, like a map pack, however, the YR equevalant YRO(as documented by deezire) files don't actually work. my idea is to try and make them work!
*Improve the havester logic so it (the harvester) cannot go to an enemy base (and then get killed) when there is an Ore on it (enemy base)
*Factory Plant Settings reduce Solyent values to prevent income generation explotation. (If implemented, this should definitely be optional - I myself reduce soylents manually so I don't want them reduced further by owning an Industrial Plant.) By default vehicle refund should be 50%. Basically if you make a vehicle 25% cheaper, you should only get 50% of its value back
*Code the {{tt|Hospital=yes}} and Machine Shop tag so that owning multiple buildings does generate an undocumented cumulative effect.
*The game reads langmd.mix > missionsmd.pkt and uses it to determine which gamemodes the stock maps are available in. Editing this file and dropping it in the directory causes random bugs and duplicate entries in the map list. If possible, add a rules tag pointing to a filename to read ''instead'' of missionsmd.pkt (de-hardcode the reference, like the {{tt|IsIFV=}} and similar new tags do). Like {{tt|[General]}}-->{{tt|PKTFile=}} .
*A fix for the ridiculous slowdown caused by having an extra CD drive or too-good hardware. In my case, my P4 3.0GHz and GeForce 5900 are (my the sound of it) the two pieces of hardware that stop me running YR...
*Fix the currently unworking {{tt|CloakStop=}} tag
*Fix it so that your computer doesn't have to be in 16-bit colour for the windowed mode (from adding -WIN to a shortcut) to work, i.e. it supports 32-bit colour too.
*Make Fighters/Aircraft Cloakable with their own cloaking unit and can dogfight, ATA without {{tt|Jumpjet=}} or altering the height-fongsaunder
*Allow aircrafts/copters to transport vehicles correctly, not by setting a ridiculous ammount of transportable units. (ex: you'd have to set the Hind and the NightHawk to have alot of pips, about ten, just so one tank could fit in it)
*Allow rotors to work with Aircraft units (not just copters) correctly without any bug.
*Fix the error when having a gate that slides down (TS style) instead of opening sideways which made the gate appear OVER a unit passing on the downed gate.
*Fix it so that when you add a superweapon upgrade to a building that has a superweapon, it overwrites the previous superweapon, instead of just adding it as a new superweapon (perhaps make it an optional tag)
*Make {{tt|PrismType=}} support more than one
*Bring back mine layer codes
*Fix voxel size units that is bigger than a tank. Eg.: Like if you have a mech or walker unit that is bigger than a 1x1 square.Wish voxel size can be user define like {{tt|VoxelSize=2x2}},like what you can do for buildings.
*Enable the Robotic Centre to accept more than 1 robotic units and if it is destroyed and rebuilt,the robotic units that are more than the first one can be shaken out from their shut down mode. This should also fix a problem with mods that have Vehicle Hijackers and more than 1 type of Robot Tank.
*Enable a Psi-Warning animation for the intended target of any superweapon, not just the nuke and its clones.

Campaign Progression

2006-06-17T10:52:49Z

80.177.214.142: More notes about stopping IE's on Yuri campaigns.

This is an explaination of how the campaigns work in RA2 and YR. The same control files are used in TS and FS, but there are many things that are different and cannot be applied equally between the two.
The files you need to be concerned with are battle(md).ini, mission(md).ini and mapsel(md).ini and I will go through the structure of them in turn.

=Battle.ini=

This is a fairly simple file and has only 2 main sections to it, a list of possible campaigns and a few definitions of how those campaigns are set up to start.

[Battles]

This section takes the form of a list starting from 1= and lists all possible campaigns. In RA2 and YR it is pointless adding anything to this list (and infact only the first 3 can ever be used anyway). The 3 listed should be TUT1, ALL1 and SOV1. ALL1 and SOV1 are accessed from the side buttons on the campaign selection screen of either RA2 or YR while TUT1 is the tutorial campaign in unmodified RA2 only (As of [[RockPatch:Status|Rock Patch v1.06]] TUT1 is a customisable 3rd campaign button in YR as well).

[XXX1]

These sections are named after the campaigns listed in the [Battles] list. The game is hard coded to access only the 3 named above (this was not the case in TS as it presented a list of campaigns to choose from). It has the following parameters:

CD= This is the CD that must be present to play the campaign. In RA2 it could be 0 (allied disc) or 1 (soviet disc). In YR it is always 2 (yuri disc).

Scenario= This is the map filename for the beginning of the campaign. After this map, mission(md).ini and mapsel(md).ini are consulted for what to do next.

FinalMovie= appears not to be used in RA2 or YR, but would play on completing a mission with EndOfGame=yes set in its [Basic] section.

Description= this is the string from the ra2(md).csf file that names the campaign. However it is never displayed in game and is left over from TS where campaigns were listed in a dialog for selection by name.

=mission.ini=

This file consists of parameters set for each mission map file that are not set in the map itself and consists of sections for each map:

[MAPNAME.MAP]

Briefing= .csf string to display when you go to the briefing screen after already entering the mission.

UIName= the name of the string that gives the name of this mission. I am unsure as to when this gets used, though this entry suffixed with 'sav' in the string file is used by the auto save feature to name the save entry.

LSLoadMessage= the name of the string that is used on the load screen to give the mission name

LSLoadBriefing= name of the string used to give the objectives on the load screen for the mission.

LS640BriefLocX=
LS640BriefLocY=
LS800BriefLocX=
LS800BriefLocY= These entries define the top left corner of the region where the briefing objectives are given on the loadscreen they give the X distance (from left edge) and y distance (from top edge) that this corner is placed at and are all set to 20 by convention. They are for the 640x480 and 800x600 loadscreen resolutions respectively. Only the 800 settings are used in YR as the screen resolution is fixed for this screen.

LS640BkgdName=
LS800BkgdName= These entries give the name of the .shp file to use for the load screen background (the ones with the maps, side symbol and the unit icons that will feature in the mission). They are again for the different possible screen resolutions but again only the 800x600 is used in YR.

LS800BkgPal= the name of the pallet file used to display the background .shp at the 800x600 resolution. This is only needed in YR where the pallet used is not hardcoded.

=MapSel.ini=

This is the most important file for making a custom campaign work correctly, particularly for a Yuri side since by default there are no progression settings for that side set up at all, while soviet and allied sides have campaigns ready defined that you can just overwrite by using the same file names. There are several sections defined that don't actually work in this file and are left over from TS, but that the game might get upset about if you removed. In addition, the game seems to require a side to have a sidenc##.mix file with the old TS assets for the mission select screen. There have been reports that if you get internal errors if you don't have sidenc03.mix and try to make a yuri mission progression. To fix this, copy sidenc02.mix from ra2.mix to the RA2 directory and rename it sidenc03.mix.

[GDI] This section defines mission progression for missions where the player is a house that belongs to the GDI side (allies).

Anims= this gives the name of another section (normally [Anims]) that defines animations that are used in the mission selection screen but does not exist in RA2 or YR.

Sounds= this gives the name of another section (normally [GDISFX]) that defines sounds played on the obsolete mission selection screen.

1=
2=
3= etc.

These list in order of progression the sections that define each mission map and its place in the order of the campaign for GDI they start with [ALL01]

[Nod] This section defines mission progression for missions where the player is a house that belongs to the Nod side (soviets). It contains the same sections as the [GDI] entry and starts its progression at Sov01

[ThirdSide] This section defines mission progression for missions where the player is a house that belongs to the ThirdSide side (yuri) in YR. It does not actually exist in the default mapselmd.ini file, but must be created if you want to make a Yuri campaign work. Without this section, missions that have the player house using ThirdSide will be unable to find the next scenario when they are completed although the first mission can be played from the entries in battlemd.ini. It needs to contain the same sections as the [GDI] and [Nod] entries. Its progression does not have a convention for its mission sections, but I recommend starting with Yur01 (you will need to define [Yur01] further into the file). Duplicate the entries from [Nod] for Anims= and Sounds=.

[XXX##] This is the convention for naming the sections that define what missions fall where in the progression. They are named after the entries in the side progression lists explained above. If you make a [ThirdSide] progression you need to make entries for these yourself.

Scenario= This is the name of the map file this mission will use. It should also have an entry in mission(md).ini to define its load screen and briefings.

Description= Obsolete from TS, refers to an entry from another .ini file? It is recommended to ommit this line for new entries in YR as it is not needed and may cause internal errors when using ThirdSide missions.

VoiceOver= obsolete from TS. Used an AUD file to play a voice over describing the mission on the map select screen.

MapVQ= obsolete, listed a movie file that played an intro to the map selection screen (usually a flyover of the map to the point where the battle was).

Overlay= .shp files overlayed onto the obsolete map screen from TS.

Targets= obsolete...location of where mission selection points appeared on the map

ClickMap= colour map that gave click points based on index colour of area on image. Never seen in game. Entry is obsolete from TS.

#= Name of a scenario section. The number indicates the pallet index on the click map that leads to this scenario when selected in TS. In RA2/YR it appears to be used to indicate the number of the next scenario in the progression and what scenario section that is.

Campaign Progression

2006-06-14T14:44:22Z

80.177.214.142: added recommendation for use of descriptions line in YR

This is an explaination of how the campaigns work in RA2 and YR. The same control files are used in TS and FS, but there are many things that are different and cannot be applied equally between the two.
The files you need to be concerned with are battle(md).ini, mission(md).ini and mapsel(md).ini and I will go through the structure of them in turn.

=Battle.ini=

This is a fairly simple file and has only 2 main sections to it, a list of possible campaigns and a few definitions of how those campaigns are set up to start.

[Battles]

This section takes the form of a list starting from 1= and lists all possible campaigns. In RA2 and YR it is pointless adding anything to this list (and infact only the first 3 can ever be used anyway). The 3 listed should be TUT1, ALL1 and SOV1. ALL1 and SOV1 are accessed from the side buttons on the campaign selection screen of either RA2 or YR while TUT1 is the tutorial campaign in unmodified RA2 only (As of [[RockPatch:Status|Rock Patch v1.06]] TUT1 is a customisable 3rd campaign button in YR as well).

[XXX1]

These sections are named after the campaigns listed in the [Battles] list. The game is hard coded to access only the 3 named above (this was not the case in TS as it presented a list of campaigns to choose from). It has the following parameters:

CD= This is the CD that must be present to play the campaign. In RA2 it could be 0 (allied disc) or 1 (soviet disc). In YR it is always 2 (yuri disc).

Scenario= This is the map filename for the beginning of the campaign. After this map, mission(md).ini and mapsel(md).ini are consulted for what to do next.

FinalMovie= appears not to be used in RA2 or YR, but would play on completing a mission with EndOfGame=yes set in its [Basic] section.

Description= this is the string from the ra2(md).csf file that names the campaign. However it is never displayed in game and is left over from TS where campaigns were listed in a dialog for selection by name.

=mission.ini=

This file consists of parameters set for each mission map file that are not set in the map itself and consists of sections for each map:

[MAPNAME.MAP]

Briefing= .csf string to display when you go to the briefing screen after already entering the mission.

UIName= the name of the string that gives the name of this mission. I am unsure as to when this gets used, though this entry suffixed with 'sav' in the string file is used by the auto save feature to name the save entry.

LSLoadMessage= the name of the string that is used on the load screen to give the mission name

LSLoadBriefing= name of the string used to give the objectives on the load screen for the mission.

LS640BriefLocX=
LS640BriefLocY=
LS800BriefLocX=
LS800BriefLocY= These entries define the top left corner of the region where the briefing objectives are given on the loadscreen they give the X distance (from left edge) and y distance (from top edge) that this corner is placed at and are all set to 20 by convention. They are for the 640x480 and 800x600 loadscreen resolutions respectively. Only the 800 settings are used in YR as the screen resolution is fixed for this screen.

LS640BkgdName=
LS800BkgdName= These entries give the name of the .shp file to use for the load screen background (the ones with the maps, side symbol and the unit icons that will feature in the mission). They are again for the different possible screen resolutions but again only the 800x600 is used in YR.

LS800BkgPal= the name of the pallet file used to display the background .shp at the 800x600 resolution. This is only needed in YR where the pallet used is not hardcoded.

=MapSel.ini=

This is the most important file for making a custom campaign work correctly, particularly for a Yuri side since by default there are no progression settings for that side set up at all, while soviet and allied sides have campaigns ready defined that you can just overwrite by using the same file names. There are several sections defined that don't actually work in this file and are left over from TS, but that the game might get upset about if you removed.

[GDI] This section defines mission progression for missions where the player is a house that belongs to the GDI side (allies).

Anims= this gives the name of another section (normally [Anims]) that defines animations that are used in the mission selection screen but does not exist in RA2 or YR.

Sounds= this gives the name of another section (normally [GDISFX]) that defines sounds played on the obsolete mission selection screen.

1=
2=
3= etc.

These list in order of progression the sections that define each mission map and its place in the order of the campaign for GDI they start with [ALL01]

[Nod] This section defines mission progression for missions where the player is a house that belongs to the Nod side (soviets). It contains the same sections as the [GDI] entry and starts its progression at Sov01

[ThirdSide] This section defines mission progression for missions where the player is a house that belongs to the ThirdSide side (yuri) in YR. It does not actually exist in the default mapselmd.ini file, but must be created if you want to make a Yuri campaign work. Without this section, missions that have the player house using ThirdSide will be unable to find the next scenario when they are completed although the first mission can be played from the entries in battlemd.ini. It needs to contain the same sections as the [GDI] and [Nod] entries. Its progression does not have a convention for its mission sections, but I recommend starting with Yur01 (you will need to define [Yur01] further into the file). Duplicate the entries from [Nod] for Anims= and Sounds=.

[XXX##] This is the convention for naming the sections that define what missions fall where in the progression. They are named after the entries in the side progression lists explained above. If you make a [ThirdSide] progression you need to make entries for these yourself.

Scenario= This is the name of the map file this mission will use. It should also have an entry in mission(md).ini to define its load screen and briefings.

Description= Obsolete from TS, refers to an entry from another .ini file? It is recommended to ommit this line for new entries in YR as it is not needed and may cause internal errors when using ThirdSide missions.

VoiceOver= obsolete from TS. Used an AUD file to play a voice over describing the mission on the map select screen.

MapVQ= obsolete, listed a movie file that played an intro to the map selection screen (usually a flyover of the map to the point where the battle was).

Overlay= .shp files overlayed onto the obsolete map screen from TS.

Targets= obsolete...location of where mission selection points appeared on the map

ClickMap= colour map that gave click points based on index colour of area on image. Never seen in game. Entry is obsolete from TS.

#= Name of a scenario section. The number indicates the pallet index on the click map that leads to this scenario when selected in TS. In RA2/YR it appears to be used to indicate the number of the next scenario in the progression and what scenario section that is.

Reserved Mix Files

2005-04-25T22:11:50Z

80.177.214.142:

A mix file is said to be reserved when it is used by the editing community to provide some cross mod addon that any modder can utilise. These may range from patches and bug fixes to asset packs that enhance the user experience. If you are a modder who is close to releasing their mod to the world and are considering how to package it, you need to be aware of this list so you avoid conflicting with any community addon that may be used by the end user. Most reserved mix files at the moment are for Yuri's Revenge.

== expandmd01.mix ==
This is the only additional mix file provided by EA and is provided as part of the official v1.001 patch. It contains several art assets to change the Yuri Multi-Player score screen and a selection confirm dialog box, updates to the new urban oil derrick, altered versions of several maps and updated rulesmd.ini and soundmd.ini files.

== expandmd02.mix ==
This mix file is reserved for the mooted unofficial v1.002 patch project. It would contain art assets correcting known flaws or inconsistencies for game artwork and updated .ini files correcting other known graphical flaws and game bugs.

== expandmd06.mix ==
This is reserved for the Terrain Expansion and contains the updated theatre.ini files that control the tiles used to construct maps. It also contains the vast number of additional tiles provided to support a wide range of additional terrain features in most of Yuri's Revenge theatres.

== expandmd98.mix ==
This is a special case that any mods packaged by xccmc will use as their main mix file. It is not nessesary to avoid using it, but it will be removed by any xccml launched mods.

Additional mix files may well be added to this list at a later date as community projects are developed or suitable existing projects become classified as community projects. Where your mod uses expandmd##.mix files, it is recommended that you avoid using the 01-10 range to future proof compatibility of your mod with future community projects and updates.

Reserved Mix Files

2005-04-25T22:06:25Z

80.177.214.142:

Game Modes System

2005-01-17T22:24:00Z

80.177.214.142: Added an editor note regarding the MP mode headings.

== Multiplayer Mode INI Tutorial (by Marshall) ==

This is a tutorial on creating and editing MP mode ini files, and some of the problems you may encounter.

Contents:

1. Getting Started

2. Rules Of Engagement

3. The Multiplayer Mode Definition File (mpmodesmd.ini)

4. MP mode-related Bugs (VERY IMPORTANT!)

------------------------------------------------------------

1. Getting Started

This tutorial assumes you already have a reasonable understanding of modifying the <rulesmd.ini> file.

First of all, update Yuri's Revenge to the latest version [1.001]. Make sure your ini files are based on the 1.001 ini files.
Then make sure you have checked out the YR Unofficial 1.002 Mini-Patch, which demonstrates a multitude of ini file fixes.
Once your base ini file set is up to date you can begin modifying the RA2/YR "Rules Of Engagement"

------------------------------------------------------------

2. Rules Of Engagement

You know how to modify <rulesmd.ini>. The 'Rules Of Engagement' refers to the ini file settings stored in <rulesmd.ini> and also the MP mode ini files.

Treat an MP mode ini file like a miniature rules ini file.
When you play a specific game mode in Yuri's Revenge, the game will load the main rules file and then it will load a specific MP mode ini file which contains ini settings that will OVERRIDE or add to those settings already present in the main rules file.

For example, in a mode file you may have just a single entry:

[E1]

Strength=200

In this case, the difference between a normal game and your new game mode is that the GI has 75 extra strength.

If you look at the MP mode ini files that come with Yuri's Revenge you will see how the various game modes are defined. For example, <mpmwmd.ini> (Megawealth) contains the ini override settings necessary to disable the Refineries and Ore Miners, and change the prerequisites of the other structures in the game (which normally require a Refinery before they can be built).

Finally, it seems that all MP game modes must have the following entry:

[MultiplayerDialogSettings]

AlliesAllowed=yes (or AlliesAllowed=no if it is a Free For All mode)

Beyond that, any override settings are up to you.
Just make sure you follow the normal procedures for rules entries.
It is a good idea to base your mode file(s) on similar mode files already present.

NB: You cannot define a weapon in the main rules and then give it to a unit in a mode file. Doing so will cause an Internal Error in-game. All weapons must be parsed by a unit in the main rules file.
To do this, create a dummy, non-buildable unit in the main rules first and give the weapon to that unit.
There may be other situations like this that you will have to look out for.

------------------------------------------------------------

3. The Multiplayer Mode Definition File (mpmodesmd.ini)

This file defines all the multiplayer game modes that are present in the game.

There are 5 multiplayer mode sections in <mpmodesmd.ini>.

[Battle] This is a standard battle mode.

[ManBattle] These modes may only be played in network and internet games. AI players are not allowed.

[FreeForAll] Players may not ally with each other.

[Unholy] The Unholy Alliance mode is in this section.

[Cooperative] The Cooperative mode is in this section.

It is not known if all modes have to be defined in their appropriate section. For example, 'players may not ally with one another' is a setting defined in the Free For All MP mode ini file so the Free For All mode may not have to be defined in the [FreeForAll] section for it to work. However, there is no reason not to define each mode in its appropriate section anyway.*

*I believe the different headings invoke certain logic specific to certain game mode types. For free for all it makes the AI attack other AI's as well as the player and UnholyAlliance make the game give all available base units. You might want to re-write this section with that in mind - Blade

Let's take a look at the 'Free For All' mode.
2=GUI:FreeForAll, STT:ModeFreeForAll, MPFreeForAllMD.ini, standard, true

It is a free for all mode and hence it is defined in the
[FreeForAll] section.

The first item defined in this mode is its slot position in the list of available modes when you choose the mode and map you are going to play on. The 'Free For All' mode is the second one in the list because its index number is '2'. Look at the other modes defined in <mpmodesmd.ini>. Notice
how the mode whose index number is '3' is the third one in the list of modes in game.
Never leave out an index number. If you define a mode with index '15' you must have first defined a mode with index '14'.

The second item defined is the name of the multiplayer mode. In the string table <ra2md.csf>, the entry 'GUI:FreeForAll' (in the GUI section) will have a value of 'Free For All'.
This is the title that is displayed in the graphical user interface (GUI) of Yuri's Revenge.

The third item defined is the description of the multiplayer mode. This description appears in the bar at the bottom of the screen when selecting a multiplayer mode. In the string table <ra2md.csf>, the entry 'STT:ModeFreeForAll' (in the STT section) will contain the description of the 'Free For All' mode.

The fourth item defined is the name of the MP mode ini file . <MPFreeForAllMD.ini> contains the Free For All rules 'addendums'.

The fifth item defined is the type of map that this mode may be used with. Map types include 'standard', 'teamgame', 'megawealth', 'duel', 'meatgrind', 'navalwar' and 'cooperative'. The type(s) of a map is set in the map editor and a map may be more than one type.
'Free For All' may be used with any 'standard' map.

The final item defined is whether or not maps created by the random map generator are allowed. 'true' means they are allowed, 'false' means they are not allowed.

------------------------------------------------------------

4. MP mode-related Bugs

There is a strange bug with MP mode ini files that can cause some undesireable rules overrides.

There are 2 known cases:

----------
1. Pip= & OccupyPip=

Let's take the GI as an example. We are going to edit the GI as follows:

[E1]

Strength=200

When we play in-game we will find that both the colour and shape of the GI's pip (when inside a transport or occupying a building) have been changed or 'messed up'.

The same applies to any infantry unit you modify.
To fix this problem, you must do the following:

[E1]

Strenth=200

Pip=white

OccupyPip=PersonBlue

You must restate these pip settings for every infantry unit you mention in the MP mode ini file.

----------

2. PrismSupportModifier=

When you modify the [General] entry, the PrismSupportModifier= flag gets changed. It causes a supported Prism Tower to do instant-kill damage to its target.
To fix this problem, all you have to do is restate the flag:

[General]

SecretInfantry=SNIPE,DESO,TERROR,YURI,MYNEWUNIT

PrismSupportModifier=150%

----------

This is a rather worrying problem as it poses the question: "What other flags get buggered by MP mode ini files?"
If you discover any more, please post them above.

In light of the above bug, it is a good idea to avoid using mode files wherever possible, and keep as little code in them as possible. When modifying an entry, try to restate the entire entry's code, just to avoid this bug making an appearance.

TargetLaser

2004-08-15T16:34:24Z

80.177.214.142: Fixed link to page for TargetLaser tag

The Targeting Laser was a feature found in TS where a unit would produce a very thin red line to its target just prior to it firing its weapon. It was only used on the Titan and apart form that is unused. The original effect [[TargetLaser]] appears to only work with [[VehicleTypes]] but there are other ways to create a similar effect.

== Target Laser Tutorials ==

Here you will find a selection of tutorials relating creating a targeting laser effect.

=== Improved Targeting Lasers (by [[Tratos]]) ===

This will show you how to make very effective target lasers for your units.

This tutorial is very very easy but has good results. Firstly you need to find the unit you want to give a target laser too. For the purpose of this tutorial i will be reffering to the [GGI].

Secondly, ensure that your chosen unit does not have the tag
[[TargetLaser]]=
and if it does ensure that the value is no. This tag gives a 'laser' that is essentially just a red line drawn between the unit and its target and looks rubbish.

Next, choose the weapon you want to apply the target laser to, in the case of the GGI i chose the [MissileLauncher] weapon to give the GGI laser guided missiles. Find the chosen weapon in [[rules]].ini and add the following code to the end of its stats:

LaserInnerColor=*,*,*
LaserDuration=**
IsLaser=true

Change the *'s to the values you desire. For the colours these will be in RGB (Red, Green, Blue) format (a good red colour is 255,10,10). For the laser duration the value determines the time the laser effect is visible for, a good value is 15-20.

This will draw a laser between the unit and the target when the weapon is fired. The good thing is that the normal [[projectile]] (in this case the missile) is also still drawn and the damage only happens when that projectile hits. This gives the effect of a small laser aiming at the target before the missile is fired giving the impression of laser guided missiles. This works best for weapons with a viewable [[projectile]]. For weapons with invisible [[projectiles]] (or [[projectiles]] with a speed of 100) it will just look like the unit is firing a laser.

You can also add the tags:

LaserOuterColor =*,*,*
LaserOuterSpread=*,*,*

And these will add a slight glow to the laser, personally i prefer it without these tags but you may not. The values are done in the same way as the InnerColor (RGB format).

This effect is great for elite weapons to add a visual identifier that the unit is Elite apart from the [[chevron]]s and to mark the weapon apart from regular versions.

TargetLaser

2004-08-15T16:32:05Z

80.177.214.142:

The Targeting Laser was a feature found in TS where a unit would produce a very thin red line to its target just prior to it firing its weapon. It was only used on the Titan and apart form that is unused. The original effect [[TargetLaser]] appears to only work with [[VehicleTypes]] but there are other ways to create a similar effect.

== Target Laser Tutorials ==

Here you will find a selection of tutorials relating creating a targeting laser effect.

=== Improved Targeting Lasers (by [[Tratos]]) ===

This will show you how to make very effective target lasers for your units.

This tutorial is very very easy but has good results. Firstly you need to find the unit you want to give a target laser too. For the purpose of this tutorial i will be reffering to the [GGI].

Secondly, ensure that your chosen unit does not have the tag
[[TargetLaser]]
and if it does ensure that the value is no. This tag gives a 'laser' that is essentially just a red line drawn between the unit and its target and looks rubbish.

Next, choose the weapon you want to apply the target laser to, in the case of the GGI i chose the [MissileLauncher] weapon to give the GGI laser guided missiles. Find the chosen weapon in [[rules]].ini and add the following code to the end of its stats:

LaserInnerColor=*,*,*
LaserDuration=**
IsLaser=true

Change the *'s to the values you desire. For the colours these will be in RGB (Red, Green, Blue) format (a good red colour is 255,10,10). For the laser duration the value determines the time the laser effect is visible for, a good value is 15-20.

This will draw a laser between the unit and the target when the weapon is fired. The good thing is that the normal [[projectile]] (in this case the missile) is also still drawn and the damage only happens when that projectile hits. This gives the effect of a small laser aiming at the target before the missile is fired giving the impression of laser guided missiles. This works best for weapons with a viewable [[projectile]]. For weapons with invisible [[projectiles]] (or [[projectiles]] with a speed of 100) it will just look like the unit is firing a laser.

You can also add the tags:

LaserOuterColor =*,*,*
LaserOuterSpread=*,*,*

And these will add a slight glow to the laser, personally i prefer it without these tags but you may not. The values are done in the same way as the InnerColor (RGB format).

This effect is great for elite weapons to add a visual identifier that the unit is Elite apart from the [[chevron]]s and to mark the weapon apart from regular versions.

Engine

2004-08-15T16:22:34Z

80.177.214.142:

In terms of modding, the engine refers to the core program and rules that the game obeys. Rules such as the method by which the display is rendered to the display, how ingame physics are modeled and the code for handling art assets. All the low level stuff is handled by the game engine.