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

Difference between revisions of "Internal Error"

From ModEnc
Jump to: navigation, search
(added 006F3481)
(Grammar/spelling corrections, improved consistency and readibility.)
Line 3: Line 3:
 
[[Image:Yr_ie.png|thumb|150px|right|Yuri Revenge's Internal Error]]
 
[[Image:Yr_ie.png|thumb|150px|right|Yuri Revenge's Internal Error]]
 
[[Image:Rp_ie.png|thumb|150px|right|RockPatch's Internal Error]]
 
[[Image:Rp_ie.png|thumb|150px|right|RockPatch's Internal Error]]
The '''Internal Error''' (commonly known as '''IE''') is a general error returned by the [[Tiberian Sun]] [[engine]] and its derivates. The message itself is rather ambiguous, giving no information what went wrong, and leaving it to the modder to know what could have caused the error and to find this cause in his code.  
+
The '''Internal Error''' (often just written short-hand as '''IE''') is a general error returned by the [[Tiberian Sun]] [[engine]] and its derivates. The message itself gives no information about what the error actually was or what went wrong, thus leaving it to the modder to know what could have caused the error and to find the cause in their mod's changes.
  
If you experience an Internal Error, the best course of action is to think whether a distinctive event immediately preceeded the crash (e.g. a unit being built, a weapon being fired...), or, if this is not the case (or not the cause), to tripple-check your latest code modification(s) - at best with the help of a diff between the current rules set and a previous, working one (for this reason, and in case you mess up your code beyond repair, you should always keep recent backups of working code).
+
If you experience an Internal Error, you should:<br>
 
+
1. Think about whether a distinctive event immediately preceeded the error (e.g. a unit being built, a weapon being fired, etc.). If this was the case then take a look at the changes you applied for that unit/weapon/whatever and see if there are any mistakes.<br>
Note that, the more code you add at the same time, the more likely it is to introduce multiple bugs and causes for crashes. Just because you found ''one'' mistake in your code, doesn't mean there can't be ''another one'', also causing an IE (or being the one that caused the IE in the first place).
+
2. Carefully check your latest modifications, with the help of a diff between the current rules set and the previous, working rules if possible (for this reason, and in case you mess up your code beyond repair, you should always keep recent backups of working code).
 +
Remember that the more code you add at the same time, the more likely it is to introduce multiple bugs and IE causes (and just because you found one mistake in your code, that doesn't mean there can't be another).<br>
 +
3. Check the list of known IE casues on this page (see below).<br>
 +
4. Check the list of known EIPs - see if the EIP reported in your except.txt file matches an EIP for which the IE cause is known (see below).
  
 
==Except.txt==
 
==Except.txt==
If your game crashes through an IE, a file called except.txt is generated in your game folder. This file is a dump of certain runtime-data from the game at the point of crash, and could potentially tell you exactly what went wrong - ''if'' you knew the engine code. <br>
+
If your game crashes because of an Internal Error, a file named except.txt is generated in your game folder. This file is a dump of certain runtime-data from the game at the moment the error occurred and could potentially tell you exactly what went wrong ''if'' you knew the engine code. <br>
pd has, every once in a while, found a pattern he recognized, and could, for example, tell when an except referenced the voxel loading routines, thereby pinpointing the IE to a voxel issue.
+
Due to his research into the game's binary and his efforts to develop the RockPatch, pd has occasionally been able to indicate the area of the engine where the error occurred (for example, an error occurring in the voxel-loading routines may indicate a problem with a custom voxel).
 
+
However, pd has other commitments and should not be treated as the go-to guy for any IEs you may have. Further more, pd may not neccessarily be able to help - without the source code or a comprehensive understanding of the game's binary the file is of little use. (cp. [[SYNCx.txt]])
However, more often than not even pd can't help - without the source code or in-depth knowledge of the game code, the file is rather useless to one. (cp. [[SYNCx.txt]])
 
  
 
According to an early version of [[Except.txt]] (which now redirects here), this file includes the full structure and a stack dump of a [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/context_str.asp CONTEXT] element.
 
According to an early version of [[Except.txt]] (which now redirects here), this file includes the full structure and a stack dump of a [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/context_str.asp CONTEXT] element.
  
 
== List of known Causes of Internal Errors (please expand) ==
 
== List of known Causes of Internal Errors (please expand) ==
Since "Internal Error" is the game's response to almost any fatal error, its causes are diverse. Most common are causes related to weapons and warheads, with a missing warhead probably being the all-time no. 1 cause of Internal Errors.
+
Since "Internal Error" is the game's response to almost any fatal error, its causes are diverse. Most common are causes related to weapons and warheads, with a missing warhead probably being the most commonly reported cause.
  
 
===Weapons-related Causes===
 
===Weapons-related Causes===
*Pointing to a weapon that does not exist (possibly caused by a simple misspelling of the correct weapon's name)
+
*Pointing to a weapon that does not exist, possibly caused by a simple misspelling of the correct weapon's name. (See 'Broken-reference Causes, below.)
*Making the game use a weapon that hasn't been parsed. Example 1: shrapnel weapons that aren't attached to a dummy unit. Example 2: giving a weapon to a unit in a game mode override file when the weapon hasn't been attached to a dummy unit in the main rules.
+
*Making the game use a weapon that hasn't been parsed. Example 1: shrapnel weapons that aren't attached to a [dummy] unit. Example 2: giving a weapon to a unit in a game mode override file when that weapon hasn't been attached to a [dummy] unit in the main rules.
*Attempting to use a weapon without a projectile.
+
*Firing a weapon that has no projectile.
*When a unit is able to occupy buildings and it has a chrono weapon, a IE appears when firing that weapon on a target
+
*When a unit is able to occupy buildings and it has a chrono weapon, an IE occurs when that weapon is fired.
 
{{NeedTesting}}
 
{{NeedTesting}}
*Not sure about the details of this one, needs clarification: A unit whose Primary weapon had Suicide=yes and Secondary had multiple mind-control. Selecting the unit and hovering the cursor over an enemy caused an internal error. EIP was 00471CA4. Swapping Primary and Secondary prevented the IE. Later, after tweaking the unit to try and determine the precise cause, got the same 00471CA4 IE the instant it was built.
+
*Not sure about the details of this one, needs clarification: A unit whose Primary weapon had Suicide=yes and Secondary had multiple mind-control. Selecting the unit and hovering the cursor over an enemy caused an IE. EIP was 00471CA4. Swapping Primary and Secondary prevented the IE. Later, after tweaking the unit to try and determine the precise cause, got the same 00471CA4 IE the instant it was built.
  
 
===Warhead-related Causes===
 
===Warhead-related Causes===
*Having a weapon's {{tt|Warhead}} tag point to a warhead that doesn't exist (e.g. through a typo), or having no warhead-tag at all
+
*Having a weapon's {{tt|Warhead}} tag point to a warhead that doesn't exist (e.g. through a typo), or having no warhead-tag at all. (See 'Broken-reference Causes, below.)
 
*[[CellSpread]] must not be bigger than 11{{fnl|1}}
 
*[[CellSpread]] must not be bigger than 11{{fnl|1}}
*Setting off a warhead with a [[CellSpread]] that is also {{TTL|Temporal|yes}}
+
*Setting off a warhead with a [[CellSpread]] that also has {{TTL|Temporal|yes}} set.
*Sometimes, warheads that are not listed under {{tt|[[Warheads|[Warheads]]]}} can cause an IE
+
*Warheads that are not listed under {{tt|[[Warheads|[Warheads]]]}} can cause an IE, although some modders have found that this isn't always a problem.
  
===Broken-reference related Causes===
+
===Broken-reference Causes===
*Most of the flags pointing to an object type do not verify the object type exists and try to invoke it anyway. This includes pointers to weapons, warheads, particles, particle systems, infantry/unit/aircraft/building types, among other things.
+
*Most of the flags that point to an object type do not verify that the object type exists and will try to invoke it anyway. This includes pointers to weapons, projectiles, warheads, particles, particle systems and infantry/unit/aircraft/building types, among other things.
  
 
===Other Causes===
 
===Other Causes===
*An MCV turns neutral: If a player's MCV was mind-controlled by an enemy, that player is killed, and the MCV is then released from mind-control, an Internal Error will be caused by the fact that the MCV tries to return to its original owner, but said owner is not a legal faction of the game anymore. One '''workaround''' is to make MCVs unable to be mind-controlled, this is the way it is done in the [[YR 1.002 UMP]]. Neutral [[Building:Construction Yard|Construction Yards]] do not seem to be a problem.
+
*An MCV turns neutral: If a player's MCV was mind-controlled by an enemy, that player is killed, and the MCV is then released from mind-control, an IE will occur. The cause is probably due to the Civilian house not being designed to handle MCVs. The only workaround is to make MCVs immune to mind-control (this is done in the [[YR 1.002 UMP]]). Neutral [[Building:Construction Yard|Construction Yards]] do not seem to cause a problem.
*If a falling paratrooper (who has nearly reached the ground) is killed by an area-effect mutation weapon, an IE will be triggered. Point based mutations seem to be okay and the [[Super weapon:Genetic Mutator|Genetic Mutator]] seems incapable of killing falling paratroopers. If you have an area-effect mutation weapon, you should ensure that all paratroopers are immune to it.
+
*If a falling paratrooper (who has nearly reached the ground) is killed by an area-effect mutation weapon. Point based mutations seem to be okay (the falling paratrooper explodes) and the [[Super weapon:Genetic Mutator|Genetic Mutator]] seems incapable of killing falling paratroopers. If you have an area-effect mutation weapon, you should ensure that all paratroopers are immune to it (this also means that you can't have a buildable paradrop plane and an area-effect mutation weapon in the same mod).
*{{TTL|HoverPad|yes}}. If the AI uses a Weather Storm or Nuclear Missile superweapon and a building with {{tt|HoverPad&#61;yes}} exists, the game will suffer an IE. '''This IE can''', however, '''be prevented''' by uncommenting the flag {{TTL|AIIonCannonHelipadValue|20,20,20}} (change the values if you like).
+
*{{TTL|HoverPad|yes}}. If the AI uses a Weather Storm or Nuclear Missile superweapon and a building with {{tt|HoverPad&#61;yes}} exists. '''This IE can''', however, '''be prevented''' by uncommenting the flag {{TTL|AIIonCannonHelipadValue|20,20,20}} (the values can be changed).
*Omitting {{TTL|MakeInfantry|X}} on [[InfDeath]] 9's animation ({{TTL|InfantryMutate|GENDEATH}}) can sometimes cause an internal error. See [[MakeInfantry]] for more information.
+
*Omitting {{TTL|MakeInfantry|X}} on [[InfDeath]] 9's animation ({{TTL|InfantryMutate|GENDEATH}}) can sometimes cause an IE. See [[MakeInfantry]] for more information.
*Using the 'sell unit' super weapon on a tank-bunkered unit breaks the Tank Bunker. Attempting to sell or destroy the broken Tank Bunker causes an Internal Error. The only possible fix is to make sure a player never ever has access to both the "Sell Unit" Super weapon and the Tank Bunker at the same time - in reality, this means you can only have either of them...not both.
+
*Using the 'Sell Unit' super weapon on a tank-bunkered unit breaks the Tank Bunker. Attempting to sell or destroy the broken Tank Bunker causes an IE. The only way to prevent this is to make sure a player never has access to both the Sell Unit Super weapon and the Tank Bunker at the same time (so unless both buildings are country specials, that means removing MCVs from crates and making Construction Yards uncapturable and immune to mind-control).
*Adding a new harvester for a 4th side/faction and not making an AI Trigger for it will cause an IE
+
*Adding a new harvester for a 4th side/faction and not making an AI Trigger for it.
*The modding concept known as "[[Infantry Linking]]" can result in an IE, occuring when the linked infantry was modified in a subsequent game mode override file or a map ''and'' a human player scrolls to a place on the map where coordinates on which an AI-owned [[Building:War Factory|War Factory]] is located are visible on his screen. Once again, the only solution is not to do it.
+
*The modding concept known as "[[Infantry Linking]]" can result in an IE, occuring when the linked infantry was modified in a subsequent game mode override file or a map ''and'' a human player scrolls their battlefield view to a place on the map where an AI-owned [[Building:War Factory|War Factory]] is located. Don't do Infantry Linking.
*If you have a buildable Construction Yard, start its construction, and then cancel it, an IE will occur. Same solution as above.
+
*If you have a buildable Construction Yard, start its construction, and then cancel it, an IE will occur. Construction Yards should not be buildable - they should only be deployed from vehicles.
*Calling for an animation that is not listed under {{tt|[[Animations|[Animations]]]}} might trigger an Internal Error
+
*Calling for an animation that is not listed under {{tt|[[Animations|[Animations]]]}} might trigger an IE.
*If you build a unit ingame whose voxel or shp you put into an original game mix instead of a proper expansion mix, you'll have a Close Encounter of the Erroneous Kind
+
*Building a unit in-game whose VXL/SHP was inserted in an original game MIX instead of an expansion MIX.
*Not having at least one valid [[InfantryTypes|InfantryType]] with {{TTL|AllowedToStartInMultiplayer|yes}} (default) for each house will lead to an IE on load
+
*Not having at least one valid [[InfantryTypes|InfantryType]] with {{TTL|AllowedToStartInMultiplayer|yes}} (default) for each house.
*Setting {{TTL|CarryOverCap|0}} will cause an IE. (Default value is -1, positive values do not cause an IE.)
+
*Setting {{TTL|CarryOverCap|0}}. Default value is -1, positive values do not cause an IE.
*A certain side's Construction Yard not having {{TTL|AIBuildThis|yes}} set leads to that side's AI causing an IE.
+
*A Construction Yard not having {{TTL|AIBuildThis|yes}} set when the owning side's AI is present in a game.
*Removing a building from the PrerequisitePower= list, while it exists in one of the (GDI/NODRegular/Third)PowerPlant= lists will cause IE the moment any of your Power buildings gets destroyed or sold as long as you own a Construction Yard. (For example, YR mods that remove Yuri's Army from the game, should never remove YAPOWR from PrerequisitePower=).
+
*Removing a building from the PrerequisitePower= list, while it exists in one of the (GDI/NODRegular/Third)PowerPlant= lists will cause an IE the moment any of your Power buildings get destroyed or sold as long as you own a Construction Yard. YR mods that remove Yuri's side from the game, should not remove YAPOWR from PrerequisitePower=.
 
*If an overlay type with {{TTL|Explodes|yes}} is destroyed and the {{TTL|BarrelParticle}} tag is blank or missing.
 
*If an overlay type with {{TTL|Explodes|yes}} is destroyed and the {{TTL|BarrelParticle}} tag is blank or missing.
*Placing two buildings on a map so that they overlap, and then attempting to destroy or garrison one of them causes an Internal Error. Use [[FinalAlert]]'s {{tt|Options}} {{arr|r}} {{tt|{{y}}Show Building Outline}} feature to see the actual areas taken up by buildings, since there are a lot of buildings whose foundation is different from their visual size.
+
*Placing two buildings on a map so that they overlap (in the map editor), and then destroying or garrisoning one of them (in-game). Use [[FinalAlert]]'s {{tt|Options}} {{arr|r}} {{tt|{{y}}Show Building Outline}} feature to see the actual areas taken up by buildings, since there are a lot of buildings whose foundation is different from their visual size.
*Using a [[TrailerAnim]] on an [[animation]] but not setting a [[TrailerSeperation]] (default TrailerSeperation is zero, and that's divided by.)
+
*Using a [[TrailerAnim]] on an [[animation]] but not setting a [[TrailerSeperation]]. This is because the default TrailerSeperation is zero, and that number is used as a divisor.
*Having a repairable BuildingType with Strength = zero or less than [{{TTL|General}}]{{arr|r}}{{TTL|RepairStep}}.
+
*Having a repairable BuildingType with {{TTL|Strength|0}} or Strength less than [{{TTL|General}}]{{arr|r}}{{TTL|RepairStep}}.
*Having an animation with {{TTL|SpawnsParticle}} which does not point to a valid ParticleSystem.
+
*Having an animation with {{TTL|SpawnsParticle}} which does not point to a valid ParticleSystem. (See 'Broken-reference Causes, above.)
  
 
===Footnotes===
 
===Footnotes===
{{fn|1|In certain versions, [[RockPatch]] does allow a higher value.}}
+
{{fn|1|The [[RockPatch]] does allow higher values (depending on version).}}
  
 
===Figuring out your IE from Except.txt===
 
===Figuring out your IE from Except.txt===
  
Since all IEs caused by one and the same reason share the same EIP: value in except.txt, knowing that value might help you pinpoint your IE. The following is a small and incomplete list of EIPs and their corresponding IE reasons. <!-- It really begs for a redesign of the list above, but I will let someone else do that. -->
+
IEs that share the same cause also share the same EIP: value in except.txt, so knowing that value might help you determine the cause of your IE. The following is a small and incomplete list of EIPs and their corresponding IE reasons. <!-- It really begs for a redesign of the list above, but I will let someone else do that. -->
 
{| cellpadding="4" border="1" class="table_descrow"
 
{| cellpadding="4" border="1" class="table_descrow"
 
! EIP
 
! EIP

Revision as of 00:53, 5 March 2008

Tiberian Sun's Internal Error
Red Alert 2's Internal Error
Yuri Revenge's Internal Error
RockPatch's Internal Error

The Internal Error (often just written short-hand as IE) is a general error returned by the Tiberian Sun engine and its derivates. The message itself gives no information about what the error actually was or what went wrong, thus leaving it to the modder to know what could have caused the error and to find the cause in their mod's changes.

If you experience an Internal Error, you should:
1. Think about whether a distinctive event immediately preceeded the error (e.g. a unit being built, a weapon being fired, etc.). If this was the case then take a look at the changes you applied for that unit/weapon/whatever and see if there are any mistakes.
2. Carefully check your latest modifications, with the help of a diff between the current rules set and the previous, working rules if possible (for this reason, and in case you mess up your code beyond repair, you should always keep recent backups of working code). Remember that the more code you add at the same time, the more likely it is to introduce multiple bugs and IE causes (and just because you found one mistake in your code, that doesn't mean there can't be another).
3. Check the list of known IE casues on this page (see below).
4. Check the list of known EIPs - see if the EIP reported in your except.txt file matches an EIP for which the IE cause is known (see below).

Except.txt

If your game crashes because of an Internal Error, a file named except.txt is generated in your game folder. This file is a dump of certain runtime-data from the game at the moment the error occurred and could potentially tell you exactly what went wrong if you knew the engine code.
Due to his research into the game's binary and his efforts to develop the RockPatch, pd has occasionally been able to indicate the area of the engine where the error occurred (for example, an error occurring in the voxel-loading routines may indicate a problem with a custom voxel). However, pd has other commitments and should not be treated as the go-to guy for any IEs you may have. Further more, pd may not neccessarily be able to help - without the source code or a comprehensive understanding of the game's binary the file is of little use. (cp. SYNCx.txt)

According to an early version of Except.txt (which now redirects here), this file includes the full structure and a stack dump of a CONTEXT element.

List of known Causes of Internal Errors (please expand)

Since "Internal Error" is the game's response to almost any fatal error, its causes are diverse. Most common are causes related to weapons and warheads, with a missing warhead probably being the most commonly reported cause.

Weapons-related Causes

  • Pointing to a weapon that does not exist, possibly caused by a simple misspelling of the correct weapon's name. (See 'Broken-reference Causes, below.)
  • Making the game use a weapon that hasn't been parsed. Example 1: shrapnel weapons that aren't attached to a [dummy] unit. Example 2: giving a weapon to a unit in a game mode override file when that weapon hasn't been attached to a [dummy] unit in the main rules.
  • Firing a weapon that has no projectile.
  • When a unit is able to occupy buildings and it has a chrono weapon, an IE occurs when that weapon is fired.

Template:NeedTesting

  • Not sure about the details of this one, needs clarification: A unit whose Primary weapon had Suicide=yes and Secondary had multiple mind-control. Selecting the unit and hovering the cursor over an enemy caused an IE. EIP was 00471CA4. Swapping Primary and Secondary prevented the IE. Later, after tweaking the unit to try and determine the precise cause, got the same 00471CA4 IE the instant it was built.

Warhead-related Causes

  • Having a weapon's Warhead tag point to a warhead that doesn't exist (e.g. through a typo), or having no warhead-tag at all. (See 'Broken-reference Causes, below.)
  • CellSpread must not be bigger than 111
  • Setting off a warhead with a CellSpread that also has Template:TTL set.
  • Warheads that are not listed under [Warheads] can cause an IE, although some modders have found that this isn't always a problem.

Broken-reference Causes

  • Most of the flags that point to an object type do not verify that the object type exists and will try to invoke it anyway. This includes pointers to weapons, projectiles, warheads, particles, particle systems and infantry/unit/aircraft/building types, among other things.

Other Causes

  • An MCV turns neutral: If a player's MCV was mind-controlled by an enemy, that player is killed, and the MCV is then released from mind-control, an IE will occur. The cause is probably due to the Civilian house not being designed to handle MCVs. The only workaround is to make MCVs immune to mind-control (this is done in the YR 1.002 UMP). Neutral Construction Yards do not seem to cause a problem.
  • If a falling paratrooper (who has nearly reached the ground) is killed by an area-effect mutation weapon. Point based mutations seem to be okay (the falling paratrooper explodes) and the Genetic Mutator seems incapable of killing falling paratroopers. If you have an area-effect mutation weapon, you should ensure that all paratroopers are immune to it (this also means that you can't have a buildable paradrop plane and an area-effect mutation weapon in the same mod).
  • Template:TTL. If the AI uses a Weather Storm or Nuclear Missile superweapon and a building with HoverPad=yes exists. This IE can, however, be prevented by uncommenting the flag Template:TTL (the values can be changed).
  • Omitting Template:TTL on InfDeath 9's animation (Template:TTL) can sometimes cause an IE. See MakeInfantry for more information.
  • Using the 'Sell Unit' super weapon on a tank-bunkered unit breaks the Tank Bunker. Attempting to sell or destroy the broken Tank Bunker causes an IE. The only way to prevent this is to make sure a player never has access to both the Sell Unit Super weapon and the Tank Bunker at the same time (so unless both buildings are country specials, that means removing MCVs from crates and making Construction Yards uncapturable and immune to mind-control).
  • Adding a new harvester for a 4th side/faction and not making an AI Trigger for it.
  • The modding concept known as "Infantry Linking" can result in an IE, occuring when the linked infantry was modified in a subsequent game mode override file or a map and a human player scrolls their battlefield view to a place on the map where an AI-owned War Factory is located. Don't do Infantry Linking.
  • If you have a buildable Construction Yard, start its construction, and then cancel it, an IE will occur. Construction Yards should not be buildable - they should only be deployed from vehicles.
  • Calling for an animation that is not listed under [Animations] might trigger an IE.
  • Building a unit in-game whose VXL/SHP was inserted in an original game MIX instead of an expansion MIX.
  • Not having at least one valid InfantryType with Template:TTL (default) for each house.
  • Setting Template:TTL. Default value is -1, positive values do not cause an IE.
  • A Construction Yard not having Template:TTL set when the owning side's AI is present in a game.
  • Removing a building from the PrerequisitePower= list, while it exists in one of the (GDI/NODRegular/Third)PowerPlant= lists will cause an IE the moment any of your Power buildings get destroyed or sold as long as you own a Construction Yard. YR mods that remove Yuri's side from the game, should not remove YAPOWR from PrerequisitePower=.
  • If an overlay type with Template:TTL is destroyed and the Template:TTL tag is blank or missing.
  • Placing two buildings on a map so that they overlap (in the map editor), and then destroying or garrisoning one of them (in-game). Use FinalAlert's OptionsCc apply.pngShow Building Outline feature to see the actual areas taken up by buildings, since there are a lot of buildings whose foundation is different from their visual size.
  • Using a TrailerAnim on an animation but not setting a TrailerSeperation. This is because the default TrailerSeperation is zero, and that number is used as a divisor.
  • Having a repairable BuildingType with Template:TTL or Strength less than [[[:Template:TTL]]]→Template:TTL.
  • Having an animation with Template:TTL which does not point to a valid ParticleSystem. (See 'Broken-reference Causes, above.)

Footnotes

1 The RockPatch does allow higher values (depending on version).

Figuring out your IE from Except.txt

IEs that share the same cause also share the same EIP: value in except.txt, so knowing that value might help you determine the cause of your IE. The following is a small and incomplete list of EIPs and their corresponding IE reasons.

EIP Cause
Yuri's Revenge 1.001
004145BD You have tried to give infantry a spawn weapon (Such as ASWLauncher)
004242DB An animation has Template:TTL or lacks this flag entirely, and has a Template:TTL specified.
0042E7AF An AI player deployed a conyard which has Template:TTL set.
00441C28 You have set ShakeScreen to zero. Do not do this.
0046650D You have a shrapnel weapon which isn't assigned to a dummy object.
004895C7 You have a warhead whose Template:TTL exceeds 11.
004F8CCD You've listed less than 3 BuildingTypes at BuildConst= in [AI] Section and lost or sold your last listed Construction Yard while on low power. If you've already lost it, the IE will trigger when you run out of power after that.
0050CE14 You have a BuildingType with Template:TTL, but you need to restore the [[[:Template:TTL]]] → Template:TTL line.
0050CE5C You have a BuildingType with Template:TTL, but you need to restore the [[[:Template:TTL]]] → Template:TTL line.
005D7387 You need at least one InfantryType with Template:TTL
0062B662 Some animation has a Template:TTL pointing to a non-existant ParticleSystem.
006AEBB8 Your ra2md.ini file lists a combination of mpmode/map which the game cannot satisfy.
006F3481 The (elite) secondary weapon (or its warhead) of object you had just selected could not be found.
006F40A2 You have an object referencing a WarheadType that isn't defined.
007120F7 You have a BuildingType (which is click-repairable) with Strength which is below [[[:Template:TTL]]]→Template:TTL or zero.
0071AF4D You have a shrapnel weapon with a Template:TTL warhead.
0073B0C9 Infantry Linking.
00772A98 Some weapon has a missing Template:TTL.
Tiberian Sun 2.03
00415698 You used a TrailerAnim on an animation but forgot to set a TrailerSeperation.
006717CB WaveClass laser exception. No certain fix for this as we know, it is a possible error with the games code.
0067159B WaveClass Sonic exception. Not sure if this is code related, could be end user.
006703D4 WaveClass Sonic exception, normally triggered by a unit with a weapon that has IsSonic=yes set, firing to the south of the screen and the user scrolling up. No certain fix for this as we know, it is a possible error with the games code.
004C6428 AI does not have any buildings available for it to build. Check Template:TTL=, Template:TTL= etc.
Common
90900004 Generic exception, for example, raised when you are missing the snowmd.ini median fix.

Software used to find Internal Errors

  • INI Checker (can check your rules, art and sound files for syntactic errors like typos and missing references)
  • ExceptChecker (primarily for RockPatch-related IEs, it analyzes except.txt, tries to find references to code added by the patch or known routines, and might then be able give a direction)
  • Debugger (if you know assembler)

See also