You can submit bugs to the Bugtracker. But please first have a look if this bug is already mentioned somewhere. If it's already on the list, add your bug message as a comment.
Useful bug reports
When you report a bug please provide us with the following information, because otherwise it's often impossible to quickly check what is going on.
- Where did you download the version of the game and what version(-number) is it. Please be as verbose as possible here.
- What operating system do you run UFO:AI on?
- What computer and graphics card do you have? (graphic driver version if you know)
- What architecture does your system use (e.g. like i386, x86_64)
This is especially useful for everything from graphics bugs, setup problems, performance issues, os dependent errors, etc...
What happened before the bug occurred? Is the bug reproducible?
The bug itself is often just a symptom of things that happened right before (or often even a long time ago).
Some things to check:
- The first thing we ask you is to check if you can reproduce the bug. The simpler the reproduction-steps are, the better.
- Does the bug also happen when starting a new game or only after loading a saved game (most likely a bug in the load/save system)
- Please attach the output console file ufoconsole.log. If possible when running the game with ufo +set developer 1 (see cvar for more). See FAQ to get the path were this file is stored on your harddisk.
- Windows users: The common path is something like
<DRIVE>:\Documents & Settings\<username>\Application Data\UFOAI\.ufoai\base\ufoconsole.log
or general base/ufoconsole.log. The precise path is %APPDATA%\UFOAI\<version number>\base\ufoconsole.log.
- Linux users: The common path is
(or just paste the console-output into a file).
If you encounter bugs in a map - like unreachable places, not working stairs or soldiers inside of objects, please create a screenshot (F12) and open a bugtracker item with a name like
[map] <mapname> <shortdescription>
Make sure to read additional information regarding map testing and reporting on that.
- Make a screenshot of the problem (F12 key; see game console) to see where it is saved)
- Game logs (see above)
- Appending files: You have to be a registered sourceforge.net user to append more than one screenshot to a bug tracker item.
- Whenever possible, attach relevant files to the report.
When communicating over IRC, it might be necessary to quickly exchange larger amounts of information. You can use the following services for various types of data:
If you have no SourceForge.net account
- Please include your email address (or forum id). We usually need feedback to be able to track down and fix the problems.
Please check back your bug report often to answer questions the developers may have.
The priority settings we use for the SF-bugtracker are described here. Please note that this system is rather new, so by far not all tracker items have their priority set correctly.
||the application is completely unusable
- application can't be compiled
- application doesn't even start
||A vital feature doesn't work
||the application is partially usable (for testing), but it doesn't make sense
- can't start battlescape
- can't build a required base building
- no loot at the end of battle (thus no way to advance campaign)
||An important feature doesn't work
||the application is usable, but its not enough fun
- can't build a certain base building
- frag grenades don't work
||A minor feature doesn't work
||the application is usable, but it's less fun
- soldiers don't gain experience at all
- flashbangs don't work
||The default priority when the item is created.
||Any other minor misbehaviour the user might notice
||the application is fully usable
- soldiers don't gain experience at the speed defined in the specs/docs
- a wooden texture on a concrete wall
||Any other minor misbehaviour only a dev can notice
||the application is fully usable
- strange results for some extreme testcases
- some code wastes some resources
The above applies to bugs that happen reproducibly (on a dev's machine !) on all platforms and have no workaround.
If one or more of these criteria are missing, priority suffers a penalty of 0.6 for each, rounded.
So a bug in a vital feature (Prio 8) that only occurs on Macs and is not reproducible (1.2) will have Prio 7.
If there is even a workaround (1.8) it will be Prio 6.
Or, if you don't like to calculate: if one or two of the criteria are present, it's priority minus 1. If all the three are present, it's minus 2.
In a professional environment, priorities are closely connected to a certain behaviour of the devs eg. working overtime.
In an OSS environment, a prio 9 or 8 bug still means "all hands on deck".
For priorities < 8, devs are 'supposed' or 'asked' to fix them according to priority.
They are of course still allowed to fix even the least important bug if they are in the mood to do so.
See our debugging site for more information on how to handle segfaults and crash bugs.
Bug-links inside the wiki
You can use the code
to link to an existing bug in the tracker. The above example will produce "#1234567" (bogus number)
For request use the code
(#1502802 as result)