I don't know all details, and I may forget something, so contributions are very welcome!
When we have enough information, it should be put into the wiki as well.
This thread is not about:
- Crashes or other problems that are caused when a technical limit (set on purpose, or caused by the maximum/minimum values of a data type) is deliberately exceeded when creating game content. See this thread about such limits.
- Limitations related to the design of algorithms or routines, such as:
- General poor behavior of units, such as helicopters, which is not caused by a specific programming flaw
- General multiplayer issues such as flying/gliding units or invisible units, unless there is a specific programming flaw that causes such behavior.
- Game glitches caused by "unexpected" acts of the player, such as the "F6 jump gun trick" or the ability to control multiple vehicles at once. These are now included in this thread.
- Most compatibility problems related to modern systems. See this wiki article about compatibility problems.
- Bugs and problems that only occur with UA Source. These should be reported and discussed in the UA Source thread.
The helicopter bug
Helicopters do not obey orders and are unable to move in directions other than up. This is a very well known problem. It's caused by a threshold check in the code that handles helicopter movement. On modern computers, the game runs fast and the threshold condition is never fulfilled, resulting in incorrect behavior.
This was conclusively confirmed and fixed by Zidane. See this thread:
See this wiki article too:
Units get added into wrong squad
Sometimes, when you create a squad of new units, the first unit forms a new squad, but the rest are added into another squad. This bug usually (always?) starts to occur after reloading a saved game. After occurring once, it repeats itself. It can be resolved by destroying your existing units.
Weapon hit detection fails at sector borders
When a projectile passes through a sector border, it may fail to hit a vehicle which is positioned very close to the border but on the other side of it. This is quite noticeable when sniping host stations with Rhino rockets, for example.
See this thread:
Some investigation by Zidane:
Gun turret aiming
Gun turrets aim into wrong direction if the target vehicle is located directly north or south of them. See this:
This bug has been fixed in UA Source.
Weapon radius is partially ignored
The radius_<type> parameters of weapons, such as radius_tank = ..., are used to determine how the AI uses them against different units but they do not affect the size of the weapon's hitbox. This was investigated and confirmed to be a bug by Zidane. See this:
This bug has been fixed in UA Source but the fix must be manually enabled.
Tanks get stuck to each other after creation
Sometimes when you create several tanks in rapid succession, some of them may get stuck to each other and stay floating in the air. This happens quite often. It can usually be resolved by jumping into one of the tanks, creating a new unit next to them or destroying one of them. Keeping enough space between the tanks during creation can also help to prevent this issue from occurring.
Vehicles end up underground or inside structures after creation
Newly created vehicles sometimes end up underground. This may happen when you create them close to the ground. Tanks usually start falling downwards and will be teleported back to the surface after falling below a certain level. Aircraft can be manually flown back to the surface, and it's also be possible to fly them underground for an extended period of time.
Vehicles may also end up inside buildings. This may happen after creation as well as after constructing a building to a sector that already has vehicles on it. If this happens, they can usually be driven out manually.
Tanks start shaking
Sometimes when you're piloting a tank manually, the viewport starts shaking and the screen gets blurry. This is most likely caused by a loss of precision in the rotation handling routines. A related bug in UA Source was investigated by Zidane, see this post.
Game clock runs too fast
The game time counter has been observed to run faster than real-time. This can be seen by measuring the playing time using a stopwatch - the mission debriefing should show longer playing time. This bug also affects Stoudson bomb countdown. The cause of this bug is unknown but it seems to occur in both hardware and software rendering mode.
Example from Dark Valley:
Mission debriefing shows: 00:07:04
Stopwatch shows: 00:06:35.6
In this case, the difference was about 7%, but differences between 3% and 7% have been observed. It's currently not known which factors affect this difference but rendering mode might be one of them. If you can test this, please post your results and the game settings you used, as well as your hardware specifications.
Game time counting is inconsistent when re-entering a completed level
If you re-enter a finished level, then exit via the beam gate, the overall playing time counter will be increased by the total time spent on that level. For example:
Exiting a level for the first time:
Playing time this mission: 00:10:29
Playing time overall: 00:50:32
Re-entering the same level immediately and exiting it again:
Playing time this mission: 00:12:08
Playing time overall: 01:02:40
Re-entering the level again and exiting it for the 3rd time:
Playing time this mission: 00:12:55
Playing time overall: 01:15:35
This means that if you re-enter a level, which took a long time to complete, multiple times, the final game time statistics will be garbage. This might be of particular concern to speedrunners.
Also see this thread:
Kill statistics are not shown after re-entering a finished level
If you re-enter a level after exiting it via a beam gate and exit it again, the kill statistics are not shown even if you destroyed enemy units. Whether this is a bug or a "feature" is a matter of debate, but this is detrimental to the game experience anyway.
Score counting seems to work but there are other inconsistencies related to it.
Investstigated in this thread:
Score and kill counting do not work properly if your faction is not 1
If you are playing as a faction other than 1 (Resistance), score counting does not work properly. It will always count the score of faction 1 which means that it will show the score of your enemy if you are playing against faction 1. If faction 1 is not present on the level, it will show 0.
Similarly, player kill counting does not work if your faction is not 1, but this only applies to the original game executable (UA.exe). Kill counting works properly with the Metropolis Dawn executable (UA_xp.exe).
Destroying your own units increases score and kill statistics
Pretty self-explaining - destroying your own units increases both the kill counter and score.
It's currently not known for certain if using kamikaze units does the same, but it probably does.
Last two tips missing from level selection screen
The last two of the tips that are shown in the level selection screen are never shown by the game. The tips are:
This bug has been fixed in UA Source. A patch for original UA is also presented by CharlotteLabyrinth in a message below.Tip: Press the Backspace key to jump back into the last vehicle you occupied.
Press F8 to jump into the vehicle that last sent you a message (denoted by a blinking 'i').
Tip: When joining your squads in battle, try to jump into units just before they enter
battle rather than after it has begun. This will give you the best field orientation and edge in any battle.
Tech upgrade multiplication
Certain types of tech upgrades can be applied multiple times by completing and reloading the level where they are located.
See this thread:
leftylink wrote:How to reproduce this bug:
- Find a level with at least one technology upgrade that is either "increase damage", "increase shield", or "double shot".
- Defeat all enemies in this level, and open the beam gate.
- Enter the beam gate, and leave the level.
- Click "Last Saved" and it will ask "Do you want to load the saved game and discard your current progress?" Choose "OK".
- Quit the level (Do not enter the beam gate).
- Click on any level in the world map.
- You KEEP your upgrades from the level you just quit...
- BUT you can play the level you just quit AGAIN, and gain the benefits of the technology upgrade again!
- In addition, your beam gate capacity is saved, but you can kill the enemies again to gain more beam gate capacity.
Energy absorption rate is not preserved after saving and reloading
When you save a mission for the first time and reload it afterwards, you may notice that your energy absorption rate has decreased slightly. This only occurs after the first save. If you save and reload again, it does not occur. Also, this may not occur if your energy absorption rate is 100% when you save the game, but this has not been confirmed. The exact cause of this bug is not yet known.
Ownership of enemy sectors is not automatically changed after destroying all host stations
Sometimes when you destroy all host stations of a faction, you do not automatically acquire the sectors owned by that faction. This happens every now and then but the exact cause is not known. It's rumored that this may happen more likely when the last enemy host station gets destroyed by energy drain caused by a foreign power station.
This bug has been reported to occur when two enemy host stations are occupying the same sector and they are destroyed in quick succession. If the second station is destroyed before the energy residue of the first one has disappeared, the sector ownership is not changed.
See this thread:
Enemy flaks remain on the battlefield after all host stations are destroyed
This bug occurs very rarely. Sometimes a flak station may survive the destruction of all host stations of the faction that owns it. This may happen when an enemy host station starts constructing a new flak station but gets destroyed before the building operation is completed. However, it's not known if this may occur in other circumstances. The bugged flak station usually stays inactive and won't shoot at you.
See this thread:
[Content] Default save has modified unit stats
The default save, SDU7, which is provided with the game, has modified properties for Jaguar. It does more damage (200) and has longer reload time (550 ms) between the two shots.
If you create a new save, you will have a Jaguar with its default properties (120 damage, 200 ms between the two shots).
Additionally, the default save contains enabling for level 27 which does not exist in the game. This does not have any effect on the game.
This does not apply to the demo version.
Sourced from Discord, also see this thread:
[Content] Enemy units can't hit the player version of Skorpio in Metropolis Dawn
If the player is controlling one of the turrets of the player version of Skorpio in the Metropolis Dawn Ghorkov campaign, attacking units cannot hit the Skorpio. The AI units choose the particular turret as their target because they prioritize the unit which is occupied by the player. The problem occurs because the turrets are placed outside Skorpio's hitbox and their own hitbox is very small.
See this thread:
[Content] Unconquerable sectors
There are two sectors in set 5 that cannot be conquered by using weapons. These sectors are 27 (hex: 1B) and 53 (hex: 35) and both of them are large rocks. This is due to how these sectors are defined in the SET.sdf files. It's not known with certainty if this is an intended feature, but it can be confusing to players.
See this thread:
[Content] Malformed destruction effects in a building of set 3
This is a minor bug which does not have a significant effect on the gameplay. The game does not crash or produce any error messages, and nothing special happens when the bug occurs.
In set 3, the building with the "insane in the membrane" sign has a malformed destruction effect definition. Technically, it's sub-sector model 32 which belongs to sub-sector 12 which is used on multiple sectors. The bug can be fixed by removing the second number from the destruction effects definitions (see this wiki article); the number is 5. After fixing, the building seems to produce more fragments during the final destruction step but this is not very easy to notice.
See this thread:
[Modding] Stoudson bomb countdown setting seems inaccurate
The correct conversion factor for the Stoudson bomb countdown, which is set in the level file, is 1024, not 1000. So if you want to set the countdown to 1 minute, the countdown setting should be 60 x 1024 = 61440. This is apparently an intentional choice made by the developers.
Compatibility problems between UA.exe and UA_xp.exe
- Reloading a mission that was saved using UA_xp.exe does not work in UA.exe. The is_user_robo parameter is not recognized by UA.exe. This also applies to finished missions.