2 Last updated: 2012-06-01
4 ------------------------------------------------------------------------
10 2.0) Known bugs in this release
11 * 2.1) Known bugs that will not be solved
16 All bugs listed below are marked as known. Please do not submit any bugs
17 that are the same as these. If you do, do not act surprised, because
20 Of course if you have more knowledge about any of these bugs, have more
21 specifics, we welcome you to report them. React to the given bug indicated
22 by the number below on http://bugs.openttd.org.
25 2.0) Known bugs in this release
26 ---- --------------------------
27 The following bugs are known to exist in this release and we intend to
28 fix them. Some bugs are known but are not fixable or fixing them would
29 cause further problems. Those bugs can be found in the "Known bugs that
30 will not be solved" section.
32 The bugs in this section all refer to a ticket in our bug tracking system
33 that you can find at: http://bugs.openttd.org
34 If the bugs are closed but still listed here it means that the bug is fixed
35 and that the nightlies and next major release will not have that bug.
37 Issues prefixed with [OSX] are required to be fixed before we consider
38 officially supporting Mac OS X again. For now it remains unsupported and
39 we only apply bug fixes provided by the community but we are unable to fix
42 - 4857 [OSX] No support for detecting mono space font
43 - 4847 [OSX] No support for bootstrap downloading of base graphics
44 - 4744 [OSX] Crash when switching to full screen with OS X Lion
45 - 4689 [OSX] Crash when hiding window after coming from full screen
46 - 4420 [OSX] OS' mouse pointer still shows
47 - 2484 [OSX] Cannot enter CJK characters
49 2.1) Known bugs that will not be solved
50 ---- ----------------------------------
51 This section lists all known bugs that we do not intend to fix and the
52 reasons why we think that fixing them is infeasible. We might make some
53 minor improvements that reduce the scope of these bugs, but we will not
54 be able to completely fix them.
56 No suitable AI can be found
57 If you have no AIs and an AI is started the so-called 'dummy' AI will
58 be loaded. This AI does nothing but writing a message on the AI debug
59 window and showing a red warning. There are basically two solutions
60 for this problem: you must change the settings so no AI is started,
61 this is done in the difficulty settings window. The other solution is
62 acquiring (downloading) some AI. The easiest way to do this is via
63 the "Check Online Content" button in the main (intro) menu or via
64 "AI Settings" -> "Select AI" -> "Check Online Content" which is also
65 accessed via the main menu.
67 After a while of playing, colours get corrupted
68 In Windows 7 the background slideshow corrupts the colour mapping of
69 OpenTTD's 8bpp screen modes. Workarounds for this are:
70 a) Switching to windowed mode, instead of fullscreen
71 b) Switching off background slideshow
72 c) Setting up the 32bpp-anim or 32bpp-optimized blitter
74 Long delay between switching songs/music
75 On Windows there is a delay of a (few) second(s) between switching of
76 songs for the "win32" driver. This delay is caused by the fact that
77 opening a MIDI file via MCI is extremely slow.
79 DirectMusic, known as "dmusic" in OpenTTD, has a much shorter delay.
80 However, under some circumstances DirectMusic does not reset its
81 state properly causing wrongly pitched/bad sounding songs. This
82 problem is in DirectMusic as it is reproducable with Microsoft's
83 DirectMusic Producer. DirectMusic has been deprecated since 2004
84 and as such has no support for 64 bits OpenTTD.
86 As a delay is favourable over bad sounding music the "win32" driver
87 is the default driver for OpenTTD. You can change this default by
88 setting the "musicdriver" in your openttd.cfg to "dmusic".
90 Custom vehicle type name is incorrectly aligned
91 Some NewGRFs use sprites that are bigger than normal in the "buy
92 vehicle" window. Due to this they have to encode an offset for the
93 vehicle type name. Upon renaming the vehicle type this encoded offset
94 is stripped from the name because the "edit box" cannot show this
95 encoding. As a result the custom vehicle type names will get the
96 default alignment. The only way to (partly) fix this is by adding
97 spaces to the custom name.
99 Clipping problems [FS#119]
100 In some cases sprites are not drawn as one would expect. Examples of
101 this are aircraft that might be hidden below the runway or trees that
102 in some cases are rendered over vehicles.
103 The primary cause of this problem is that OpenTTD does not have enough
104 data (like a 3D model) to properly determine what needs to be drawn in
105 front of what. OpenTTD has bounding boxes but in lots of cases they
106 are either too big or too small and then cause problems with what
107 needs to be drawn in front of what. Also some visual tricks are used.
108 For example trains at 8 pixels high, the catenary needs to be drawn
109 above that. When you want to draw bridges on top of that, which are
110 only one height level (= 8 pixels) higher, you are getting into some
112 We can not change the height levels; it would require us to either
113 redraw all vehicle or all landscape graphics. Doing so would mean we
114 leave the Transport Tycoon graphics, which in effect means OpenTTD
115 will not be a Transport Tycoon clone anymore.
117 Mouse scrolling not possible at the edges of the screen [FS#383] [FS#3966]
118 Scrolling the viewport with the mouse cursor at the edges of the screen
119 in the same direction of the edge will fail. If the cursor is near the
120 edge the scrolling will be very slow.
121 OpenTTD only receives cursor position updates when the cursor is inside
122 OpenTTD's window. It is not told how far you have moved the cursor
123 outside of OpenTTD's window.
125 Lost trains ignore (block) exit signals [FS#1473]
126 If trains are lost they ignore block exit signals, blocking junctions
127 with presignals. This is caused because the path finders cannot tell
128 where the train needs to go. As such a random direction is chosen at
129 each junction. This causes the trains to occasionally to make choices
130 that are unwanted from a player's point of view.
131 This will not be fixed because lost trains are in almost all cases a
132 network problem, e.g. a train can never reach a specific place. This
133 makes the impact of fixing the bug enormously small against the
134 amount of work needed to write a system that prevents the lost trains
135 from taking the wrong direction.
137 Vehicle owner of last transfer leg gets paid for all [FS#2427]
138 When you make a transfer system that switches vehicle owners. This
139 is only possible with 'industry stations', e.g. the oil rig station
140 the owner of the vehicle that does the final delivery gets paid for
141 the whole trip. It is not shared amongst the different vehicle
142 owners that have participated in transporting the cargo.
143 This sharing is not done because it would enormously increase the
144 memory and CPU usage in big games for something that is happening
145 in only one corner case. We think it is not worth the effort until
146 sharing of stations is an official feature.
148 Forbid 90 degree turns does not work for crossing PBS paths [FS#2737]
149 When you run a train through itself on a X junction with PBS turned on
150 the train will not obey the 'forbid 90 degree turns' setting. This is
151 due to the fact that we can not be sure that the setting was turned
152 off when the track was reserved, which means that we assume it was
153 turned on and that the setting does not hold at the time. We made it
154 this way to allow one to change the setting in-game, but it breaks
155 slightly when you are running your train through itself. Running a
156 train through means that your network is broken and is thus a user
157 error which OpenTTD tries to graciously handle.
158 Fixing this bug means that we need to record whether this particular
159 setting was turned on or off at the time the reservation was made. This
160 means adding quite a bit of data to the savegame for solving an issue
161 that is basically an user error. We think it is not worth the effort.
163 Duplicate (station) names after renaming [FS#3204]
164 After renaming stations one can create duplicate station names. This
165 is done giving a station the same custom name as another station with
166 an automatically generated name.
167 The major part of this problem is that station names are translatable.
168 Meaning that a station is called e.g. '<TOWN> Central' in English and
169 '<TOWN> Centraal' in Dutch. This means that in network games the
170 renaming of a town could cause the rename to succeed on some clients
171 and fail at others. This creates an inconsistent game state that will
172 be seen as a 'desync'. Secondly the custom names are intended to fall
173 completely outside of the '<TOWN> <name>' naming of stations, so when
174 you rename a town all station names are updated accordingly.
175 As a result the decision has been made that all custom names are only
176 compared to the other custom names in the same class and not compared
177 to the automatically generated names.
179 Extreme CPU usage/hangs when using SDL and PulseAudio [FS#3294]
180 OpenTTD hangs/freezes when closing, OpenTTD is slow, OpenTTD uses a lot of CPU
181 OpenTTD can be extremely slow/use a lot of CPU when the sound is
182 played via SDL and then through PulseAudio's ALSA wrapper. Under the
183 same configuration OpenTTD, or rather SDL, might hang when exiting
184 the game. This problem is seen most in Ubuntu 9.04 and higher.
186 This is because recent versions of the PulseAudio sound server are
187 configured to use timer-based audio scheduling rather than
188 interrupt-based audio scheduling. Configuring PulseAudio to force
189 use of interrupt-based scheduling may resolve sound problems for
190 some users. Under recent versions of Ubuntu Linux (9.04 and higher)
191 this can be accomplished by changing the following line in the
192 /etc/pulse/default.pa file:
193 load-module module-udev-detect
195 load-module module-udev-detect tsched=0
196 Note that PulseAudio must be restarted for changes to take effect.
197 Older versions of PulseAudio may use the module-hal-detect module
198 instead. Adding tsched=0 to the end of that line will have a similar
201 Another possible solution is selecting the "pulse" backend of SDL
202 by either using "SDL_AUDIODRIVER=pulse openttd" at the command
203 prompt or installing the 'libsdl1.2debian-pulseaudio' package from
204 Ubuntu's Universe repository. For other distributions a similar
205 package needs to be installed.
207 OpenTTD not properly resizing with SDL on X [FS#3305]
208 Under some X window managers OpenTTD's window does not properly
209 resize. You will either end up with a black bar at the right/bottom
210 side of the window or you cannot see the right/bottom of the window,
211 e.g you cannot see the status bar. The problem is that OpenTTD does
212 not always receive a resize event from SDL making it impossible for
213 OpenTTD to know that the window was resized; sometimes moving the
214 window will solve the problem.
215 Window managers that are known to exhibit this behaviour are KDE's
216 and GNOME's. With the XFCE's and LXDE's window managers the resize
217 event is sent when the user releases the mouse.
219 Incorrect colours, crashes upon exit, debug warnings and smears upon
220 window resizing with SDL on Mac OS X [FS#3447]
221 Video handling with (lib)SDL under Mac OS X is known to fail on some
222 versions of Mac OS X with some hardware configurations. Some of the
223 problems happen only under some circumstances whereas others are
225 We suggest that the SDL video/sound backend is not used for OpenTTD
226 in combinations with Mac OS X.
228 Train crashes entering same junction from block and path signals [FS#3928]
229 When a train has reserved a path from a path signal to a two way
230 block signal and the reservation passes a path signal through the
231 back another train can enter the reserved path (only) via that same
232 two way block signal.
233 The reason for this has to do with optimisation; to fix this issue
234 the signal update has to pass all path signals until it finds either
235 a train or a backwards facing signal. This is a very expensive task.
236 The (signal) setups that allow these crashes can furthermore be
237 considered incorrectly signalled; one extra safe waiting point for
238 the train entering from path signal just after the backwards facing
239 signal (from the path signal train) resolves the issue.
241 Crashes when playing music [FS#3941]
242 Mac OS X's QuickTime (default music driver) and Windows' MCI (win32
243 music driver) crash on some songs from OpenMSX. OpenTTD cannot do
244 anything about this. Please report these crashes to the authors of
245 OpenMSX so the crash causing songs can be removed or fixed.
247 Crashes when run in a VM using Parallels Desktop [FS#4003]
248 When the Windows version of OpenTTD is executed in a VM under
249 Parallels Desktop a privileged instruction exception may be thrown.
250 As OpenTTD works natively on OSX as well as natively on Windows and
251 these native builds both don't exhibit this behaviour this crash is
252 most likely due to a bug in the virtual machine, something out of
253 the scope of OpenTTD. Most likely this is due to Parallels Desktop
254 lacking support for RDTSC calls. The problem can be avoided by using
255 other VM-software, Wine, or running natively on OSX.
257 OpenTTD hangs when started on 32 bits Windows [FS#4083]
258 Under some circumstances OpenTTD might hang for hours on the
259 initialisation of the music driver. The exact circumstances are
260 unknown except that it is the "dmusic" music driver that has the
261 problem and that the "win32" music driver does not.
262 As a result using the "win32" music driver will work around this
265 As the exact circumstances are unknown, and the obvious
266 configuration settings related to the music driver are at their
267 default we are not able to detect this failure, except when Windows'
268 music initialisation function returns after several hours and then
269 there is no point in switching the music driver anymore.
270 The reason we still use the "win32" music driver as default are
271 described in the "Long delay between switching music/song" section
274 Pre- and exit signals are not dragged [FS#4378]
275 Unlike all other signal types, the entry- and exit signals are not
276 dragged but instead normal signals are placed on subsequent track
277 sections. This is done on purpose as this is the usually more con-
278 venient solution. There are little to no occasions where more than
279 one entry or exit signal in a row are useful. This is different
280 for all other signal types where several in a row can serve one
283 Station build date is incorrect [FS#4415]
284 The tile query tool will show the date of the last (re)construction
285 at the station and not the date of the first construction. This is
286 due to compatability reasons with NewGRFs and the fact that it is
287 wrong to say that the station is built in a particular year when it
288 was completely destroyed/rebuilt later on.
289 The tile query tool can be fixed by changing the "Build date" text
290 to "Date at which the last (re)construction took place" but this is
291 deemed too specific and long for that window.
293 Can't change volume inside OpenTTD [FS#4416]
294 Some backends do not provide a means to change the volume of sound
295 effects or music. The mixing of music and sound is left to external
296 libraries/the operating system we can't handle the volume control
297 in OpenTTD. As a result you can't change the volume inside OpenTTD
298 for backends such as SDL; just use the volume control provided by
299 your operating system.
301 Can't run OpenTTD with the -d option from a MSYS console [FS#4587]
302 The MSYS console does not allow OpenTTD to open an extra console for
303 debugging output. Compiling OpenTTD with the --enable-console
304 configure option prevents this issue and allows the -d option to use
305 the MSYS console for its output.
307 Unreadable characters for non-latin locales [FS#4607]
308 OpenTTD does not ship a non-latin font in its graphics files. As a
309 result OpenTTD needs to acquire the font from somewhere else. What
310 OpenTTD does is ask the operating system, or a system library, for
311 the best font for a given language if the currently loaded font
312 does not provide all characters of the chosen translation. This
313 means that OpenTTD has no influence over the quality of the chosen
314 font; it just does the best it can do.
316 If the text is unreadable there are several steps that you can take
317 to improve this. The first step is finding a good font and configure
318 this in the configuration file. See section 9.0 of readme.txt for
319 more information. You can also increase the font size to make the
320 characters bigger and possible better readable.
322 If the problem is with the clarity of the font you might want to
323 enable anti-aliasing by setting the small_aa/medium_aa/large_aa
324 settings to "true". However, anti-aliasing only works when a 32 bits
325 blitter has been selected, e.g. blitter = "32bpp-anim", as with the
326 8 bits blitter there are not enough colours to properly perform the
329 (Temporary) wrong colours when switching to full screen [FS#4511]:
330 On Windows it can happen that you temporarily see wrong colours
331 when switching to full screen OpenTTD, either by starting
332 OpenTTD in full screen mode, changing to full screen mode or by
333 ALT-TAB-ing into a full screen OpenTTD. This is caused by the
334 fact that OpenTTD, by default, uses 8bpp paletted output. The
335 wrong colours you are seeing is a temporary effect of the video
336 driver switching to 8bpp palette mode.
338 This issue can be worked around in two ways:
339 a) Setting fullscreen_bpp to 32
340 b) Setting up the 32bpp-anim or 32bpp-optimized blitter
342 Train does not crash with itself [FS#4635]:
343 When a train drives in a circle the front engine passes through
344 wagons of the same train without crashing. This is intentional.
345 Signals are only aware of tracks, they do not consider the train
346 length and whether there would be enough room for a train in some
347 circle it might drive on. Also the path a train might take is not
348 necessarily known when passing a signal.
349 Checking all circumstances would take a lot of additional computational
350 power for signals, which is not considered worth the effort, as
351 it does not add anything to gameplay.
352 Nevertheless trains shall not crash in normal operation, so making
353 a train not crash with itself is the best solution for everyone.
355 Aircraft coming through wall in rotated airports [FS#4705]:
356 With rotated airports, specifically hangars, you will see that the
357 aircraft will show a part through the back wall of the hangar.
358 This can be solved by only drawing a part of the plane when being
359 at the back of the hangar, however then with transparency turned on
360 the aircraft would be shown partially which would be even weirder.
361 As such the current behaviour is deemed the least bad.
362 The same applies to overly long ships and their depots.
364 Vehicles not keeping their "maximum" speed [FS#4815]:
365 Vehicles that have not enough power to reach and maintain their
366 advertised maximum speed might be constantly jumping between two
367 speeds. This is due to the fact that speed and its calculations
368 are done with integral numbers instead of floating point numbers.
369 As a result of this a vehicle will never reach its equilibrium
370 between the drag/friction and propulsion. So in effect it will be
371 in a vicious circle of speeding up and slowing down due to being
372 just at the other side of the equilibrium.
374 Not speeding up when near the equilibrium will cause the vehicle
375 to never come in the neighbourhood of the equilibrium and not
376 slowing down when near the equilibrium will cause the vehicle
377 to never slow down towards the equilibrium once it has come down
380 It is possible to calculate whether the equilibrium will be
381 passed, but then all acceleration calculations need to be done
384 Settings not saved when OpenTTD crashes [FS#4846]:
385 The settings are not saved when OpenTTD crashes for several reasons.
386 The most important is that the game state is broken and as such the
387 settings might contain invalid values, or the settings have not even
388 been loaded yet. This would cause invalid or totally wrong settings
389 to be written to the configuration file.
391 A solution to that would be saving the settings whenever one changes,
392 however due to the way the configuration file is saved this requires
393 a flush of the file to the disk and OpenTTD needs to wait till that
394 is finished. On some file system implementations this causes the
395 flush of all 'write-dirty' caches, which can be a significant amount
396 of data to be written. This can further be aggravated by spinning
397 down disks to conserve power, in which case this disk needs to be
398 spun up first. This means that many seconds may pass before the
399 configuration file is actually written, and all that time OpenTTD
400 will not be able to show any progress. Changing the way the
401 configuration file is saved is not an option as that leaves us more
402 vulnerable to corrupt configuration files.
404 Finally, crashes should not be happening. If they happen they should
405 be reported and fixed, so essentially fixing this is fixing the
406 wrong thing. If you really need the configuration changes to be
407 saved, and you need to run a version that crashes regularly, then
408 you can use the 'saveconfig' command in the console to save the
411 Not all NewGRFs, AIs, game scripts are found [FS#4887]:
412 Under certain situations, where the path for the content within a
413 tar file is the same as other content on the file system or in another
414 tar file, it is possible that content is not found. A more thorough
415 explanation and solutions are described in section 4.4 of readme.txt.
417 Mouse cursor going missing with SDL [FS#4997]:
418 Under certain circumstances SDL does not notify OpenTTD of changes
419 with respect to the mouse pointer, specifically whether the mouse
420 pointer is within the bounds of OpenTTD or not. For example, if you
421 Alt-tab to another application the mouse cursor will still be shown
422 in OpenTTD, and when you move the mouse outside of the OpenTTD
423 window so the cursor gets hidden, open/move another application on
424 top of the OpenTTD window and then Alt-tab back into OpenTTD the
425 cursor will not be shown.
427 We cannot fix this problem as SDL simply does not provide the
428 required information in these corner cases. This is a bug in SDL
429 and as such there is little that we can do about it.