2 Last updated: 2021-01-22
3 Release version: 1.11.0-beta1
4 ------------------------------------------------------------------------
15 All bugs listed below are marked as known. Please do not submit any bugs
16 that are the same as these. If you do, do not act surprised, because
19 The current list of known bugs that we intend to fix can be found in our
20 bug tracking system at https://github.com/OpenTTD/OpenTTD/issues
21 Also check the closed bugs when searching for your bug in this system as we
22 might have fixed the bug in the mean time.
26 ---- ----------------------------------
27 This section lists all known bugs that we do not intend to fix and the
28 reasons why we think that fixing them is infeasible. We might make some
29 minor improvements that reduce the scope of these bugs, but we will not
30 be able to completely fix them.
32 No suitable AI can be found:
33 If you have no AIs and an AI is started the so-called 'dummy' AI will
34 be loaded. This AI does nothing but writing a message on the AI debug
35 window and showing a red warning. There are basically two solutions
36 for this problem: Either you set the number of AI players to 0 so that
37 no AI is started. You find that setting at the top of the window in the
38 "AI / Game Scripts Settings" window.
39 The other solution is acquiring (downloading) some AI. The easiest way
40 to do this is via the "Check Online Content" button in the main (intro)
41 menu or directly in the "AI / Game Scripts Settings" dialogue via the
42 "Check Online Content" button.
44 After a while of playing, colours get corrupted:
45 In Windows 7 the background slideshow corrupts the colour mapping
46 of OpenTTD's 8bpp screen modes. Workarounds for this are:
47 a) Switching to windowed mode, instead of fullscreen
48 b) Switching off background slideshow
49 c) Setting up the 32bpp-anim or 32bpp-optimized blitter
51 Custom vehicle type name is incorrectly aligned:
52 Some NewGRFs use sprites that are bigger than normal in the "buy
53 vehicle" window. Due to this they have to encode an offset for
54 the vehicle type name. Upon renaming the vehicle type this encoded
55 offset is stripped from the name because the "edit box" cannot show
56 this encoding. As a result the custom vehicle type names will get
57 the default alignment. The only way to (partially) fix this is by
58 adding spaces to the custom name.
60 Clipping problems [#119]:
61 In some cases sprites are not drawn as one would expect. Examples of
62 this are aircraft that might be hidden below the runway or trees that
63 in some cases are rendered over vehicles.
64 The primary cause of this problem is that OpenTTD does not have enough
65 data (like a 3D model) to properly determine what needs to be drawn in
66 front of what. OpenTTD has bounding boxes but in lots of cases they
67 are either too big or too small and then cause problems with what
68 needs to be drawn in front of what. Also some visual tricks are used.
69 For example trains at 8 pixels high, the catenary needs to be drawn
70 above that. When you want to draw bridges on top of that, which are
71 only one height level (= 8 pixels) higher, you are getting into some
73 We can not change the height levels; it would require us to either
74 redraw all vehicle or all landscape graphics. Doing so would mean we
75 leave the Transport Tycoon graphics, which in effect means OpenTTD
76 will not be a Transport Tycoon clone anymore.
78 Mouse scrolling not possible at the edges of the screen [#383] [#3966]:
79 Scrolling the viewport with the mouse cursor at the edges of the screen
80 in the same direction of the edge will fail. If the cursor is near the
81 edge the scrolling will be very slow.
82 OpenTTD only receives cursor position updates when the cursor is inside
83 OpenTTD's window. It is not told how far you have moved the cursor
84 outside of OpenTTD's window.
86 Lost trains ignore (block) exit signals [#1473]:
87 If trains are lost they ignore block exit signals, blocking junctions
88 with presignals. This is caused because the path finders cannot tell
89 where the train needs to go. As such a random direction is chosen at
90 each junction. This causes the trains to occasionally to make choices
91 that are unwanted from a player's point of view.
92 This will not be fixed because lost trains are in almost all cases a
93 network problem, e.g. a train can never reach a specific place. This
94 makes the impact of fixing the bug enormously small against the amount
95 of work needed to write a system that prevents the lost trains from
96 taking the wrong direction.
98 Vehicle owner of last transfer leg gets paid for all [#2427]:
99 When you make a transfer system that switches vehicle owners. This
100 is only possible with 'industry stations', e.g. the oil rig station
101 the owner of the vehicle that does the final delivery gets paid for
102 the whole trip. It is not shared amongst the different vehicle
103 owners that have participated in transporting the cargo.
104 This sharing is not done because it would enormously increase the
105 memory and CPU usage in big games for something that is happening
106 in only one corner case. We think it is not worth the effort until
107 sharing of stations is an official feature.
109 Forbid 90 degree turns does not work for crossing PBS paths [#2737]:
110 When you run a train through itself on a X junction with PBS turned on
111 the train will not obey the 'forbid 90 degree turns' setting. This is
112 due to the fact that we can not be sure that the setting was turned
113 off when the track was reserved, which means that we assume it was
114 turned on and that the setting does not hold at the time. We made it
115 this way to allow one to change the setting in-game, but it breaks
116 slightly when you are running your train through itself. Running a
117 train through means that your network is broken and is thus a user
118 error which OpenTTD tries to graciously handle.
119 Fixing this bug means that we need to record whether this particular
120 setting was turned on or off at the time the reservation was made. This
121 means adding quite a bit of data to the savegame for solving an issue
122 that is basically an user error. We think it is not worth the effort.
124 Duplicate (station) names after renaming [#3204]:
125 After renaming stations one can create duplicate station names. This
126 is done giving a station the same custom name as another station with
127 an automatically generated name.
128 The major part of this problem is that station names are translatable.
129 Meaning that a station is called e.g. '<TOWN> Central' in English and
130 '<TOWN> Centraal' in Dutch. This means that in network games the
131 renaming of a town could cause the rename to succeed on some clients
132 and fail at others. This creates an inconsistent game state that will
133 be seen as a 'desync'. Secondly the custom names are intended to fall
134 completely outside of the '<TOWN> <name>' naming of stations, so when
135 you rename a town all station names are updated accordingly.
136 As a result the decision has been made that all custom names are only
137 compared to the other custom names in the same class and not compared
138 to the automatically generated names.
140 Extreme CPU usage/hangs when using SDL and PulseAudio [#3294],
141 OpenTTD hangs/freezes when closing, OpenTTD is slow, OpenTTD uses a lot of CPU:
142 OpenTTD can be extremely slow/use a lot of CPU when the sound is
143 played via SDL and then through PulseAudio's ALSA wrapper. Under the
144 same configuration OpenTTD, or rather SDL, might hang when exiting
145 the game. This problem is seen most in Ubuntu 9.04 and higher.
147 This is because recent versions of the PulseAudio sound server
148 are configured to use timer-based audio scheduling rather than
149 interrupt-based audio scheduling. Configuring PulseAudio to force
150 use of interrupt-based scheduling may resolve sound problems for
151 some users. Under recent versions of Ubuntu Linux (9.04 and higher)
152 this can be accomplished by changing the following line in the
153 /etc/pulse/default.pa file:
154 load-module module-udev-detect
156 load-module module-udev-detect tsched=0
157 Note that PulseAudio must be restarted for changes to take effect. Older
158 versions of PulseAudio may use the module-hal-detect module instead.
159 Adding tsched=0 to the end of that line will have a similar effect.
161 Another possible solution is selecting the "pulse" backend of SDL
162 by either using "SDL_AUDIODRIVER=pulse openttd" at the command
163 prompt or installing the 'libsdl1.2debian-pulseaudio' package from
164 Ubuntu's Universe repository. For other distributions a similar
165 package needs to be installed.
167 OpenTTD not properly resizing with SDL on X [#3305]:
168 Under some X window managers OpenTTD's window does not properly
169 resize. You will either end up with a black bar at the right/bottom
170 side of the window or you cannot see the right/bottom of the window,
171 e.g. you cannot see the status bar. The problem is that OpenTTD does
172 not always receive a resize event from SDL making it impossible for
173 OpenTTD to know that the window was resized; sometimes moving the
174 window will solve the problem.
175 Window managers that are known to exhibit this behaviour are GNOME's
176 and KDE's. With the XFCE's and LXDE's window managers the resize
177 event is sent when the user releases the mouse.
179 Incorrect colours, crashes upon exit, debug warnings and smears upon
180 window resizing with SDL on macOS [#3447]:
181 Video handling with (lib)SDL under macOS is known to fail on some
182 versions of macOS with some hardware configurations. Some of
183 the problems happen only under some circumstances whereas others
185 We suggest that the SDL video/sound backend is not used for OpenTTD
186 in combinations with macOS.
188 Train crashes entering same junction from block and path signals [#3928]:
189 When a train has reserved a path from a path signal to a two way
190 block signal and the reservation passes a path signal through the
191 back another train can enter the reserved path (only) via that
192 same two way block signal.
193 The reason for this has to do with optimisation; to fix this issue
194 the signal update has to pass all path signals until it finds either
195 a train or a backwards facing signal. This is a very expensive task.
196 The (signal) setups that allow these crashes can furthermore be
197 considered incorrectly signalled; one extra safe waiting point for
198 the train entering from path signal just after the backwards facing
199 signal (from the path signal train) resolves the issue.
201 Crashes when run in a VM using Parallels Desktop [#4003]:
202 When the Windows version of OpenTTD is executed in a VM under
203 Parallels Desktop a privileged instruction exception may be thrown.
204 As OpenTTD works natively on macOS as well as natively on Windows and
205 these native builds both don't exhibit this behaviour this crash is
206 most likely due to a bug in the virtual machine, something out of
207 the scope of OpenTTD. Most likely this is due to Parallels Desktop
208 lacking support for RDTSC calls. The problem can be avoided by using
209 other VM-software, Wine, or running natively on macOS.
211 Entry- and exit signals are not dragged [#4378]:
212 Unlike all other signal types, the entry- and exit signals are not
213 dragged but instead normal signals are placed on subsequent track
214 sections. This is done on purpose as this is the usually more
215 convenient solution. There are little to no occasions where more
216 than one entry or exit signal in a row are useful. This is different
217 for all other signal types where several in a row can serve one
220 Station build date is incorrect [#4415]:
221 The tile query tool will show the date of the last (re)construction
222 at the station and not the date of the first construction. This is
223 due to compatibility reasons with NewGRFs and the fact that it is
224 wrong to say that the station is built in a particular year when it
225 was completely destroyed/rebuilt later on.
226 The tile query tool can be fixed by changing the "Build date" text
227 to "Date at which the last (re)construction took place" but this is
228 deemed too specific and long for that window.
230 (Temporary) wrong colours when switching to full screen [#4511]:
231 On Windows it can happen that you temporarily see wrong colours
232 when switching to full screen OpenTTD, either by starting
233 OpenTTD in full screen mode, changing to full screen mode or by
234 ALT-TAB-ing into a full screen OpenTTD. This is caused by the
235 fact that OpenTTD, by default, uses 8bpp paletted output. The
236 wrong colours you are seeing is a temporary effect of the video
237 driver switching to 8bpp palette mode.
239 This issue can be worked around in two ways:
240 a) Setting fullscreen_bpp to 32
241 b) Setting up the 32bpp-anim or 32bpp-optimized blitter
243 Can't run OpenTTD with the -d option from a MSYS console [#4587]:
244 The MSYS console does not allow OpenTTD to open an extra console for
245 debugging output. Compiling OpenTTD with the --enable-console
246 configure option prevents this issue and allows the -d option to use
247 the MSYS console for its output.
249 Unreadable characters for non-latin locales [#4607]:
250 OpenTTD does not ship a non-latin font in its graphics files. As a
251 result OpenTTD needs to acquire the font from somewhere else. What
252 OpenTTD does is ask the operating system, or a system library, for
253 the best font for a given language if the currently loaded font
254 does not provide all characters of the chosen translation. This
255 means that OpenTTD has no influence over the quality of the chosen
256 font; it just does the best it can do.
258 If the text is unreadable there are several steps that you can take
259 to improve this. The first step is finding a good font and configure
260 this in the configuration file. See section 9.0 of README.md for
261 more information. You can also increase the font size to make the
262 characters bigger and possible better readable.
264 If the problem is with the clarity of the font you might want to
265 enable anti-aliasing by setting the small_aa/medium_aa/large_aa
266 settings to "true". However, anti-aliasing only works when a 32-bit
267 blitter has been selected, e.g. blitter = "32bpp-anim", as with the
268 8 bits blitter there are not enough colours to properly perform the
271 Train does not crash with itself [#4635]:
272 When a train drives in a circle the front engine passes through
273 wagons of the same train without crashing. This is intentional.
274 Signals are only aware of tracks, they do not consider the train
275 length and whether there would be enough room for a train in some
276 circle it might drive on. Also the path a train might take is not
277 necessarily known when passing a signal.
278 Checking all circumstances would take a lot of additional
279 computational power for signals, which is not considered worth
280 the effort, as it does not add anything to gameplay.
281 Nevertheless trains shall not crash in normal operation, so making
282 a train not crash with itself is the best solution for everyone.
284 Aircraft coming through wall in rotated airports [#4705]:
285 With rotated airports, specifically hangars, you will see that the
286 aircraft will show a part through the back wall of the hangar.
287 This can be solved by only drawing a part of the plane when being
288 at the back of the hangar, however then with transparency turned on
289 the aircraft would be shown partially which would be even weirder.
290 As such the current behaviour is deemed the least bad.
291 The same applies to overly long ships and their depots.
293 Vehicles not keeping their "maximum" speed [#4815]:
294 Vehicles that have not enough power to reach and maintain their
295 advertised maximum speed might be constantly jumping between two
296 speeds. This is due to the fact that speed and its calculations
297 are done with integral numbers instead of floating point numbers.
298 As a result of this a vehicle will never reach its equilibrium
299 between the drag/friction and propulsion. So in effect it will be
300 in a vicious circle of speeding up and slowing down due to being
301 just at the other side of the equilibrium.
303 Not speeding up when near the equilibrium will cause the vehicle to
304 never come in the neighbourhood of the equilibrium and not slowing
305 down when near the equilibrium will cause the vehicle to never slow
306 down towards the equilibrium once it has come down a hill.
308 It is possible to calculate whether the equilibrium will be passed,
309 but then all acceleration calculations need to be done twice.
311 Settings not saved when OpenTTD crashes [#4846]:
312 The settings are not saved when OpenTTD crashes for several reasons.
313 The most important is that the game state is broken and as such the
314 settings might contain invalid values, or the settings have not even
315 been loaded yet. This would cause invalid or totally wrong settings
316 to be written to the configuration file.
318 A solution to that would be saving the settings whenever one changes,
319 however due to the way the configuration file is saved this requires
320 a flush of the file to the disk and OpenTTD needs to wait till that
321 is finished. On some file system implementations this causes the
322 flush of all 'write-dirty' caches, which can be a significant amount
323 of data to be written. This can further be aggravated by spinning
324 down disks to conserve power, in which case this disk needs to be
325 spun up first. This means that many seconds may pass before the
326 configuration file is actually written, and all that time OpenTTD
327 will not be able to show any progress. Changing the way the
328 configuration file is saved is not an option as that leaves us more
329 vulnerable to corrupt configuration files.
331 Finally, crashes should not be happening. If they happen they should
332 be reported and fixed, so essentially fixing this is fixing the wrong
333 thing. If you really need the configuration changes to be saved,
334 and you need to run a version that crashes regularly, then you can
335 use the 'saveconfig' command in the console to save the settings.
337 Not all NewGRFs, AIs, game scripts are found [#4887]:
338 Under certain situations, where the path for the content within a
339 tar file is the same as other content on the file system or in another
340 tar file, it is possible that content is not found. A more thorough
341 explanation and solutions are described in section 4.4 of README.md.
343 Mouse cursor going missing with SDL [#4997]:
344 Under certain circumstances SDL does not notify OpenTTD of changes with
345 respect to the mouse pointer, specifically whether the mouse pointer
346 is within the bounds of OpenTTD or not. For example, if you "Alt-Tab"
347 to another application the mouse cursor will still be shown in OpenTTD,
348 and when you move the mouse outside of the OpenTTD window so the cursor
349 gets hidden, open/move another application on top of the OpenTTD window
350 and then Alt-tab back into OpenTTD the cursor will not be shown.
352 We cannot fix this problem as SDL simply does not provide the required
353 information in these corner cases. This is a bug in SDL and as such
354 there is little that we can do about it.
356 Trains might not stop at platforms that are currently being changed [#5553]:
357 If you add tiles to or remove tiles from a platform while a train is
358 approaching to stop at the same platform, that train can miss the place
359 where it's supposed to stop and pass the station without stopping.
360 This is caused by the fact that the train is considered to already
361 have stopped if it's beyond its assigned stopping location. We can't
362 let the train stop just anywhere in the station because then it would
363 never leave the station if you have the same station in the order
364 list multiple times in a row or if there is only one station
365 in theorder list (see #5684).
367 Some houses and industries are not affected by transparency [#5817]:
368 Some of the default houses and industries (f.e. the iron ore mine) are
369 not affected by the transparency options. This is because the graphics
370 do not (completely) separate the ground from the building.
371 This is a bug of the original graphics, and unfortunately cannot be
372 fixed with OpenGFX for the sake of maintaining compatibility with
373 the original graphics.
375 Involuntary cargo exchange with cargodist via neutral station [#6114]:
376 When two players serve a neutral station at an industry, a cross-company
377 chain for cargo flow can and will be established which can only be
378 interrupted if one of the players stops competing for the resources of
379 that industry. There is an easy fix for this: If you are loading at the
380 shared station make the order "no unload" and if you're unloading make
381 it "no load". Cargodist will then figure out that it should not create
384 Incorrect ending year displayed in end of game newspaper [#8625]
385 The ending year of the game is configurable, but the date displayed in
386 the newspaper at the end of the game is part of the graphics, not text.
387 So to fix this would involve fixing the graphics in every baseset,
388 including the original. Additionally, basesets are free to put this
389 text in different positions (which they do), making a proper solution
390 to this infinitely more complex for a part of the game that fewer than
391 1% of players ever see.