mirror of https://github.com/OpenTTD/OpenTTD.git
Doc: Changed several things in known-bugs file
Converted "tabs" to "spaces", changed the order based on the numbering of bugs, made that lines end closer to the 80th character column, changed "Mac OS X" to "macOS", and several other less important changes.
This commit is contained in:
parent
eab3aa16aa
commit
59e4913a0f
769
known-bugs.txt
769
known-bugs.txt
|
@ -1,6 +1,6 @@
|
||||||
OpenTTD's known bugs
|
OpenTTD's known bugs
|
||||||
Last updated: 2016-07-01
|
Last updated: 2018-11-05
|
||||||
Release version: 1.6.1
|
Release version: 1.8.0
|
||||||
------------------------------------------------------------------------
|
------------------------------------------------------------------------
|
||||||
|
|
||||||
|
|
||||||
|
@ -14,12 +14,12 @@ Table of contents
|
||||||
---- -----
|
---- -----
|
||||||
All bugs listed below are marked as known. Please do not submit any bugs
|
All bugs listed below are marked as known. Please do not submit any bugs
|
||||||
that are the same as these. If you do, do not act surprised, because
|
that are the same as these. If you do, do not act surprised, because
|
||||||
we WILL flame you!!
|
we WILL flame you!
|
||||||
|
|
||||||
The current list of known bugs that we intend to fix can be found in our
|
The current list of known bugs that we intend to fix can be found in our
|
||||||
bug tracking system at: https://github.com/OpenTTD/OpenTTD/issues
|
bug tracking system at https://github.com/OpenTTD/OpenTTD/issues
|
||||||
Also check the closed bugs when searching for your bug in this system as
|
Also check the closed bugs when searching for your bug in this system as we
|
||||||
we might have fixed the bug in the mean time.
|
might have fixed the bug in the mean time.
|
||||||
|
|
||||||
|
|
||||||
2.0) Known bugs
|
2.0) Known bugs
|
||||||
|
@ -29,436 +29,429 @@ reasons why we think that fixing them is infeasible. We might make some
|
||||||
minor improvements that reduce the scope of these bugs, but we will not
|
minor improvements that reduce the scope of these bugs, but we will not
|
||||||
be able to completely fix them.
|
be able to completely fix them.
|
||||||
|
|
||||||
No suitable AI can be found
|
No suitable AI can be found:
|
||||||
If you have no AIs and an AI is started the so-called 'dummy' AI will
|
If you have no AIs and an AI is started the so-called 'dummy' AI will
|
||||||
be loaded. This AI does nothing but writing a message on the AI debug
|
be loaded. This AI does nothing but writing a message on the AI debug
|
||||||
window and showing a red warning. There are basically two solutions
|
window and showing a red warning. There are basically two solutions
|
||||||
for this problem: Either you set the number of AI players to 0 so that
|
for this problem: Either you set the number of AI players to 0 so that
|
||||||
no AI is started. You find that setting at the top of the window in the
|
no AI is started. You find that setting at the top of the window in the
|
||||||
"AI / Game Scripts Settings" window.
|
"AI / Game Scripts Settings" window.
|
||||||
The other solution is acquiring (downloading) some AI. The easiest way
|
The other solution is acquiring (downloading) some AI. The easiest way
|
||||||
to do this is via the "Check Online Content" button in the main (intro)
|
to do this is via the "Check Online Content" button in the main (intro)
|
||||||
menu or directly in the "AI / Game Scripts Settings" dialogue via the
|
menu or directly in the "AI / Game Scripts Settings" dialogue via the
|
||||||
"Check Online Content" button.
|
"Check Online Content" button.
|
||||||
|
|
||||||
After a while of playing, colours get corrupted
|
After a while of playing, colours get corrupted:
|
||||||
In Windows 7 the background slideshow corrupts the colour mapping of
|
In Windows 7 the background slideshow corrupts the colour mapping
|
||||||
OpenTTD's 8bpp screen modes. Workarounds for this are:
|
of OpenTTD's 8bpp screen modes. Workarounds for this are:
|
||||||
a) Switching to windowed mode, instead of fullscreen
|
a) Switching to windowed mode, instead of fullscreen
|
||||||
b) Switching off background slideshow
|
b) Switching off background slideshow
|
||||||
c) Setting up the 32bpp-anim or 32bpp-optimized blitter
|
c) Setting up the 32bpp-anim or 32bpp-optimized blitter
|
||||||
|
|
||||||
Long delay between switching songs/music
|
Long delay between switching songs/music:
|
||||||
On Windows there is a delay of a (few) second(s) between switching of
|
On Windows there is a delay of a (few) second(s) between switching
|
||||||
songs for the "win32" driver. This delay is caused by the fact that
|
of songs for the "Win32" driver. This delay is caused by the fact
|
||||||
opening a MIDI file via MCI is extremely slow.
|
that opening a MIDI file via MCI is extremely slow.
|
||||||
|
|
||||||
DirectMusic, known as "dmusic" in OpenTTD, has a much shorter delay.
|
DirectMusic, known as "dmusic" in OpenTTD, has a much shorter delay.
|
||||||
However, under some circumstances DirectMusic does not reset its
|
However, under some circumstances DirectMusic does not reset its state
|
||||||
state properly causing wrongly pitched/bad sounding songs. This
|
properly causing wrongly pitched/bad sounding songs. This problem is in
|
||||||
problem is in DirectMusic as it is reproducable with Microsoft's
|
DirectMusic as it is reproducable with Microsoft's DirectMusic Producer.
|
||||||
DirectMusic Producer. DirectMusic has been deprecated since 2004
|
DirectMusic has been deprecated since 2004 and as such has no support
|
||||||
and as such has no support for 64 bits OpenTTD.
|
for 64-bit OpenTTD.
|
||||||
|
|
||||||
As a delay is favourable over bad sounding music the "win32" driver
|
As a delay is favourable over bad sounding music the "Win32" driver
|
||||||
is the default driver for OpenTTD. You can change this default by
|
is the default driver for OpenTTD. You can change this default by
|
||||||
setting the "musicdriver" in your openttd.cfg to "dmusic".
|
setting the "musicdriver" in your openttd.cfg to "dmusic".
|
||||||
|
|
||||||
Custom vehicle type name is incorrectly aligned
|
Custom vehicle type name is incorrectly aligned:
|
||||||
Some NewGRFs use sprites that are bigger than normal in the "buy
|
Some NewGRFs use sprites that are bigger than normal in the "buy
|
||||||
vehicle" window. Due to this they have to encode an offset for the
|
vehicle" window. Due to this they have to encode an offset for
|
||||||
vehicle type name. Upon renaming the vehicle type this encoded offset
|
the vehicle type name. Upon renaming the vehicle type this encoded
|
||||||
is stripped from the name because the "edit box" cannot show this
|
offset is stripped from the name because the "edit box" cannot show
|
||||||
encoding. As a result the custom vehicle type names will get the
|
this encoding. As a result the custom vehicle type names will get
|
||||||
default alignment. The only way to (partly) fix this is by adding
|
the default alignment. The only way to (partially) fix this is by
|
||||||
spaces to the custom name.
|
adding spaces to the custom name.
|
||||||
|
|
||||||
Clipping problems [FS#119]
|
Clipping problems [FS#119]:
|
||||||
In some cases sprites are not drawn as one would expect. Examples of
|
In some cases sprites are not drawn as one would expect. Examples of
|
||||||
this are aircraft that might be hidden below the runway or trees that
|
this are aircraft that might be hidden below the runway or trees that
|
||||||
in some cases are rendered over vehicles.
|
in some cases are rendered over vehicles.
|
||||||
The primary cause of this problem is that OpenTTD does not have enough
|
The primary cause of this problem is that OpenTTD does not have enough
|
||||||
data (like a 3D model) to properly determine what needs to be drawn in
|
data (like a 3D model) to properly determine what needs to be drawn in
|
||||||
front of what. OpenTTD has bounding boxes but in lots of cases they
|
front of what. OpenTTD has bounding boxes but in lots of cases they
|
||||||
are either too big or too small and then cause problems with what
|
are either too big or too small and then cause problems with what
|
||||||
needs to be drawn in front of what. Also some visual tricks are used.
|
needs to be drawn in front of what. Also some visual tricks are used.
|
||||||
For example trains at 8 pixels high, the catenary needs to be drawn
|
For example trains at 8 pixels high, the catenary needs to be drawn
|
||||||
above that. When you want to draw bridges on top of that, which are
|
above that. When you want to draw bridges on top of that, which are
|
||||||
only one height level (= 8 pixels) higher, you are getting into some
|
only one height level (= 8 pixels) higher, you are getting into some
|
||||||
big problems.
|
big problems.
|
||||||
We can not change the height levels; it would require us to either
|
We can not change the height levels; it would require us to either
|
||||||
redraw all vehicle or all landscape graphics. Doing so would mean we
|
redraw all vehicle or all landscape graphics. Doing so would mean we
|
||||||
leave the Transport Tycoon graphics, which in effect means OpenTTD
|
leave the Transport Tycoon graphics, which in effect means OpenTTD
|
||||||
will not be a Transport Tycoon clone anymore.
|
will not be a Transport Tycoon clone anymore.
|
||||||
|
|
||||||
Mouse scrolling not possible at the edges of the screen [FS#383] [FS#3966]
|
Mouse scrolling not possible at the edges of the screen [FS#383] [FS#3966]:
|
||||||
Scrolling the viewport with the mouse cursor at the edges of the screen
|
Scrolling the viewport with the mouse cursor at the edges of the screen
|
||||||
in the same direction of the edge will fail. If the cursor is near the
|
in the same direction of the edge will fail. If the cursor is near the
|
||||||
edge the scrolling will be very slow.
|
edge the scrolling will be very slow.
|
||||||
OpenTTD only receives cursor position updates when the cursor is inside
|
OpenTTD only receives cursor position updates when the cursor is inside
|
||||||
OpenTTD's window. It is not told how far you have moved the cursor
|
OpenTTD's window. It is not told how far you have moved the cursor
|
||||||
outside of OpenTTD's window.
|
outside of OpenTTD's window.
|
||||||
|
|
||||||
Lost trains ignore (block) exit signals [FS#1473]
|
Lost trains ignore (block) exit signals [FS#1473]:
|
||||||
If trains are lost they ignore block exit signals, blocking junctions
|
If trains are lost they ignore block exit signals, blocking junctions
|
||||||
with presignals. This is caused because the path finders cannot tell
|
with presignals. This is caused because the path finders cannot tell
|
||||||
where the train needs to go. As such a random direction is chosen at
|
where the train needs to go. As such a random direction is chosen at
|
||||||
each junction. This causes the trains to occasionally to make choices
|
each junction. This causes the trains to occasionally to make choices
|
||||||
that are unwanted from a player's point of view.
|
that are unwanted from a player's point of view.
|
||||||
This will not be fixed because lost trains are in almost all cases a
|
This will not be fixed because lost trains are in almost all cases a
|
||||||
network problem, e.g. a train can never reach a specific place. This
|
network problem, e.g. a train can never reach a specific place. This
|
||||||
makes the impact of fixing the bug enormously small against the
|
makes the impact of fixing the bug enormously small against the amount
|
||||||
amount of work needed to write a system that prevents the lost trains
|
of work needed to write a system that prevents the lost trains from
|
||||||
from taking the wrong direction.
|
taking the wrong direction.
|
||||||
|
|
||||||
Vehicle owner of last transfer leg gets paid for all [FS#2427]
|
Vehicle owner of last transfer leg gets paid for all [FS#2427]:
|
||||||
When you make a transfer system that switches vehicle owners. This
|
When you make a transfer system that switches vehicle owners. This
|
||||||
is only possible with 'industry stations', e.g. the oil rig station
|
is only possible with 'industry stations', e.g. the oil rig station
|
||||||
the owner of the vehicle that does the final delivery gets paid for
|
the owner of the vehicle that does the final delivery gets paid for
|
||||||
the whole trip. It is not shared amongst the different vehicle
|
the whole trip. It is not shared amongst the different vehicle
|
||||||
owners that have participated in transporting the cargo.
|
owners that have participated in transporting the cargo.
|
||||||
This sharing is not done because it would enormously increase the
|
This sharing is not done because it would enormously increase the
|
||||||
memory and CPU usage in big games for something that is happening
|
memory and CPU usage in big games for something that is happening
|
||||||
in only one corner case. We think it is not worth the effort until
|
in only one corner case. We think it is not worth the effort until
|
||||||
sharing of stations is an official feature.
|
sharing of stations is an official feature.
|
||||||
|
|
||||||
Forbid 90 degree turns does not work for crossing PBS paths [FS#2737]
|
Forbid 90 degree turns does not work for crossing PBS paths [FS#2737]:
|
||||||
When you run a train through itself on a X junction with PBS turned on
|
When you run a train through itself on a X junction with PBS turned on
|
||||||
the train will not obey the 'forbid 90 degree turns' setting. This is
|
the train will not obey the 'forbid 90 degree turns' setting. This is
|
||||||
due to the fact that we can not be sure that the setting was turned
|
due to the fact that we can not be sure that the setting was turned
|
||||||
off when the track was reserved, which means that we assume it was
|
off when the track was reserved, which means that we assume it was
|
||||||
turned on and that the setting does not hold at the time. We made it
|
turned on and that the setting does not hold at the time. We made it
|
||||||
this way to allow one to change the setting in-game, but it breaks
|
this way to allow one to change the setting in-game, but it breaks
|
||||||
slightly when you are running your train through itself. Running a
|
slightly when you are running your train through itself. Running a
|
||||||
train through means that your network is broken and is thus a user
|
train through means that your network is broken and is thus a user
|
||||||
error which OpenTTD tries to graciously handle.
|
error which OpenTTD tries to graciously handle.
|
||||||
Fixing this bug means that we need to record whether this particular
|
Fixing this bug means that we need to record whether this particular
|
||||||
setting was turned on or off at the time the reservation was made. This
|
setting was turned on or off at the time the reservation was made. This
|
||||||
means adding quite a bit of data to the savegame for solving an issue
|
means adding quite a bit of data to the savegame for solving an issue
|
||||||
that is basically an user error. We think it is not worth the effort.
|
that is basically an user error. We think it is not worth the effort.
|
||||||
|
|
||||||
Duplicate (station) names after renaming [FS#3204]
|
Duplicate (station) names after renaming [FS#3204]:
|
||||||
After renaming stations one can create duplicate station names. This
|
After renaming stations one can create duplicate station names. This
|
||||||
is done giving a station the same custom name as another station with
|
is done giving a station the same custom name as another station with
|
||||||
an automatically generated name.
|
an automatically generated name.
|
||||||
The major part of this problem is that station names are translatable.
|
The major part of this problem is that station names are translatable.
|
||||||
Meaning that a station is called e.g. '<TOWN> Central' in English and
|
Meaning that a station is called e.g. '<TOWN> Central' in English and
|
||||||
'<TOWN> Centraal' in Dutch. This means that in network games the
|
'<TOWN> Centraal' in Dutch. This means that in network games the
|
||||||
renaming of a town could cause the rename to succeed on some clients
|
renaming of a town could cause the rename to succeed on some clients
|
||||||
and fail at others. This creates an inconsistent game state that will
|
and fail at others. This creates an inconsistent game state that will
|
||||||
be seen as a 'desync'. Secondly the custom names are intended to fall
|
be seen as a 'desync'. Secondly the custom names are intended to fall
|
||||||
completely outside of the '<TOWN> <name>' naming of stations, so when
|
completely outside of the '<TOWN> <name>' naming of stations, so when
|
||||||
you rename a town all station names are updated accordingly.
|
you rename a town all station names are updated accordingly.
|
||||||
As a result the decision has been made that all custom names are only
|
As a result the decision has been made that all custom names are only
|
||||||
compared to the other custom names in the same class and not compared
|
compared to the other custom names in the same class and not compared
|
||||||
to the automatically generated names.
|
to the automatically generated names.
|
||||||
|
|
||||||
Extreme CPU usage/hangs when using SDL and PulseAudio [FS#3294]
|
Extreme CPU usage/hangs when using SDL and PulseAudio [FS#3294],
|
||||||
OpenTTD hangs/freezes when closing, OpenTTD is slow, OpenTTD uses a lot of CPU
|
OpenTTD hangs/freezes when closing, OpenTTD is slow, OpenTTD uses a lot of CPU:
|
||||||
OpenTTD can be extremely slow/use a lot of CPU when the sound is
|
OpenTTD can be extremely slow/use a lot of CPU when the sound is
|
||||||
played via SDL and then through PulseAudio's ALSA wrapper. Under the
|
played via SDL and then through PulseAudio's ALSA wrapper. Under the
|
||||||
same configuration OpenTTD, or rather SDL, might hang when exiting
|
same configuration OpenTTD, or rather SDL, might hang when exiting
|
||||||
the game. This problem is seen most in Ubuntu 9.04 and higher.
|
the game. This problem is seen most in Ubuntu 9.04 and higher.
|
||||||
|
|
||||||
This is because recent versions of the PulseAudio sound server are
|
This is because recent versions of the PulseAudio sound server
|
||||||
configured to use timer-based audio scheduling rather than
|
are configured to use timer-based audio scheduling rather than
|
||||||
interrupt-based audio scheduling. Configuring PulseAudio to force
|
interrupt-based audio scheduling. Configuring PulseAudio to force
|
||||||
use of interrupt-based scheduling may resolve sound problems for
|
use of interrupt-based scheduling may resolve sound problems for
|
||||||
some users. Under recent versions of Ubuntu Linux (9.04 and higher)
|
some users. Under recent versions of Ubuntu Linux (9.04 and higher)
|
||||||
this can be accomplished by changing the following line in the
|
this can be accomplished by changing the following line in the
|
||||||
/etc/pulse/default.pa file:
|
/etc/pulse/default.pa file:
|
||||||
load-module module-udev-detect
|
load-module module-udev-detect
|
||||||
to
|
to
|
||||||
load-module module-udev-detect tsched=0
|
load-module module-udev-detect tsched=0
|
||||||
Note that PulseAudio must be restarted for changes to take effect.
|
Note that PulseAudio must be restarted for changes to take effect. Older
|
||||||
Older versions of PulseAudio may use the module-hal-detect module
|
versions of PulseAudio may use the module-hal-detect module instead.
|
||||||
instead. Adding tsched=0 to the end of that line will have a similar
|
Adding tsched=0 to the end of that line will have a similar effect.
|
||||||
effect.
|
|
||||||
|
|
||||||
Another possible solution is selecting the "pulse" backend of SDL
|
Another possible solution is selecting the "pulse" backend of SDL
|
||||||
by either using "SDL_AUDIODRIVER=pulse openttd" at the command
|
by either using "SDL_AUDIODRIVER=pulse openttd" at the command
|
||||||
prompt or installing the 'libsdl1.2debian-pulseaudio' package from
|
prompt or installing the 'libsdl1.2debian-pulseaudio' package from
|
||||||
Ubuntu's Universe repository. For other distributions a similar
|
Ubuntu's Universe repository. For other distributions a similar
|
||||||
package needs to be installed.
|
package needs to be installed.
|
||||||
|
|
||||||
OpenTTD not properly resizing with SDL on X [FS#3305]
|
OpenTTD not properly resizing with SDL on X [FS#3305]:
|
||||||
Under some X window managers OpenTTD's window does not properly
|
Under some X window managers OpenTTD's window does not properly
|
||||||
resize. You will either end up with a black bar at the right/bottom
|
resize. You will either end up with a black bar at the right/bottom
|
||||||
side of the window or you cannot see the right/bottom of the window,
|
side of the window or you cannot see the right/bottom of the window,
|
||||||
e.g you cannot see the status bar. The problem is that OpenTTD does
|
e.g. you cannot see the status bar. The problem is that OpenTTD does
|
||||||
not always receive a resize event from SDL making it impossible for
|
not always receive a resize event from SDL making it impossible for
|
||||||
OpenTTD to know that the window was resized; sometimes moving the
|
OpenTTD to know that the window was resized; sometimes moving the
|
||||||
window will solve the problem.
|
window will solve the problem.
|
||||||
Window managers that are known to exhibit this behaviour are KDE's
|
Window managers that are known to exhibit this behaviour are GNOME's
|
||||||
and GNOME's. With the XFCE's and LXDE's window managers the resize
|
and KDE's. With the XFCE's and LXDE's window managers the resize
|
||||||
event is sent when the user releases the mouse.
|
event is sent when the user releases the mouse.
|
||||||
|
|
||||||
Incorrect colours, crashes upon exit, debug warnings and smears upon
|
Incorrect colours, crashes upon exit, debug warnings and smears upon
|
||||||
window resizing with SDL on Mac OS X [FS#3447]
|
window resizing with SDL on macOS [FS#3447]:
|
||||||
Video handling with (lib)SDL under Mac OS X is known to fail on some
|
Video handling with (lib)SDL under macOS is known to fail on some
|
||||||
versions of Mac OS X with some hardware configurations. Some of the
|
versions of macOS with some hardware configurations. Some of
|
||||||
problems happen only under some circumstances whereas others are
|
the problems happen only under some circumstances whereas others
|
||||||
always present.
|
are always present.
|
||||||
We suggest that the SDL video/sound backend is not used for OpenTTD
|
We suggest that the SDL video/sound backend is not used for OpenTTD
|
||||||
in combinations with Mac OS X.
|
in combinations with macOS.
|
||||||
|
|
||||||
Train crashes entering same junction from block and path signals [FS#3928]
|
Train crashes entering same junction from block and path signals [FS#3928]:
|
||||||
When a train has reserved a path from a path signal to a two way
|
When a train has reserved a path from a path signal to a two way
|
||||||
block signal and the reservation passes a path signal through the
|
block signal and the reservation passes a path signal through the
|
||||||
back another train can enter the reserved path (only) via that same
|
back another train can enter the reserved path (only) via that
|
||||||
two way block signal.
|
same two way block signal.
|
||||||
The reason for this has to do with optimisation; to fix this issue
|
The reason for this has to do with optimisation; to fix this issue
|
||||||
the signal update has to pass all path signals until it finds either
|
the signal update has to pass all path signals until it finds either
|
||||||
a train or a backwards facing signal. This is a very expensive task.
|
a train or a backwards facing signal. This is a very expensive task.
|
||||||
The (signal) setups that allow these crashes can furthermore be
|
The (signal) setups that allow these crashes can furthermore be
|
||||||
considered incorrectly signalled; one extra safe waiting point for
|
considered incorrectly signalled; one extra safe waiting point for
|
||||||
the train entering from path signal just after the backwards facing
|
the train entering from path signal just after the backwards facing
|
||||||
signal (from the path signal train) resolves the issue.
|
signal (from the path signal train) resolves the issue.
|
||||||
|
|
||||||
Crashes when playing music [FS#3941]
|
Crashes when playing music [FS#3941]:
|
||||||
Mac OS X's QuickTime (default music driver) and Windows' MCI (win32
|
macOS's QuickTime (default music driver) and Windows' MCI ("Win32"
|
||||||
music driver) crash on some songs from OpenMSX. OpenTTD cannot do
|
music driver) crash on some songs from OpenMSX. OpenTTD cannot do
|
||||||
anything about this. Please report these crashes to the authors of
|
anything about this. Please report these crashes to the authors
|
||||||
OpenMSX so the crash causing songs can be removed or fixed.
|
of OpenMSX so the crash causing songs can be removed or fixed.
|
||||||
|
|
||||||
Crashes when run in a VM using Parallels Desktop [FS#4003]
|
Crashes when run in a VM using Parallels Desktop [FS#4003]:
|
||||||
When the Windows version of OpenTTD is executed in a VM under
|
When the Windows version of OpenTTD is executed in a VM under
|
||||||
Parallels Desktop a privileged instruction exception may be thrown.
|
Parallels Desktop a privileged instruction exception may be thrown.
|
||||||
As OpenTTD works natively on OSX as well as natively on Windows and
|
As OpenTTD works natively on macOS as well as natively on Windows and
|
||||||
these native builds both don't exhibit this behaviour this crash is
|
these native builds both don't exhibit this behaviour this crash is
|
||||||
most likely due to a bug in the virtual machine, something out of
|
most likely due to a bug in the virtual machine, something out of
|
||||||
the scope of OpenTTD. Most likely this is due to Parallels Desktop
|
the scope of OpenTTD. Most likely this is due to Parallels Desktop
|
||||||
lacking support for RDTSC calls. The problem can be avoided by using
|
lacking support for RDTSC calls. The problem can be avoided by using
|
||||||
other VM-software, Wine, or running natively on OSX.
|
other VM-software, Wine, or running natively on macOS.
|
||||||
|
|
||||||
OpenTTD hangs when started on 32 bits Windows [FS#4083]
|
OpenTTD hangs when started on 32-bit Windows [FS#4083]:
|
||||||
Under some circumstances OpenTTD might hang for hours on the
|
Under some circumstances OpenTTD might hang for hours on the
|
||||||
initialisation of the music driver. The exact circumstances are
|
initialisation of the music driver. The exact circumstances are
|
||||||
unknown except that it is the "dmusic" music driver that has the
|
unknown except that it is the "dmusic" music driver that has the
|
||||||
problem and that the "win32" music driver does not.
|
problem and that the "Win32" music driver does not. As a result
|
||||||
As a result using the "win32" music driver will work around this
|
using the "Win32" music driver will work around this issue.
|
||||||
issue.
|
|
||||||
|
|
||||||
As the exact circumstances are unknown, and the obvious
|
As the exact circumstances are unknown, and the obvious
|
||||||
configuration settings related to the music driver are at their
|
configuration settings related to the music driver are at their
|
||||||
default we are not able to detect this failure, except when Windows'
|
default we are not able to detect this failure, except when Windows'
|
||||||
music initialisation function returns after several hours and then
|
music initialisation function returns after several hours and then
|
||||||
there is no point in switching the music driver anymore.
|
there is no point in switching the music driver anymore.
|
||||||
The reason we still use the "win32" music driver as default are
|
The reason we still use the "Win32" music driver as default are
|
||||||
described in the "Long delay between switching music/song" section
|
described in the "Long delay between switching music/song" section
|
||||||
of this document.
|
of this document.
|
||||||
|
|
||||||
Pre- and exit signals are not dragged [FS#4378]
|
Entry- and exit signals are not dragged [FS#4378]:
|
||||||
Unlike all other signal types, the entry- and exit signals are not
|
Unlike all other signal types, the entry- and exit signals are not
|
||||||
dragged but instead normal signals are placed on subsequent track
|
dragged but instead normal signals are placed on subsequent track
|
||||||
sections. This is done on purpose as this is the usually more con-
|
sections. This is done on purpose as this is the usually more
|
||||||
venient solution. There are little to no occasions where more than
|
convenient solution. There are little to no occasions where more
|
||||||
one entry or exit signal in a row are useful. This is different
|
than one entry or exit signal in a row are useful. This is different
|
||||||
for all other signal types where several in a row can serve one
|
for all other signal types where several in a row can serve one
|
||||||
purpose or another.
|
purpose or another.
|
||||||
|
|
||||||
Station build date is incorrect [FS#4415]
|
Station build date is incorrect [FS#4415]:
|
||||||
The tile query tool will show the date of the last (re)construction
|
The tile query tool will show the date of the last (re)construction
|
||||||
at the station and not the date of the first construction. This is
|
at the station and not the date of the first construction. This is
|
||||||
due to compatability reasons with NewGRFs and the fact that it is
|
due to compatability reasons with NewGRFs and the fact that it is
|
||||||
wrong to say that the station is built in a particular year when it
|
wrong to say that the station is built in a particular year when it
|
||||||
was completely destroyed/rebuilt later on.
|
was completely destroyed/rebuilt later on.
|
||||||
The tile query tool can be fixed by changing the "Build date" text
|
The tile query tool can be fixed by changing the "Build date" text
|
||||||
to "Date at which the last (re)construction took place" but this is
|
to "Date at which the last (re)construction took place" but this is
|
||||||
deemed too specific and long for that window.
|
deemed too specific and long for that window.
|
||||||
|
|
||||||
Can't change volume inside OpenTTD [FS#4416]
|
Can't change volume inside OpenTTD [FS#4416]:
|
||||||
Some backends do not provide a means to change the volume of sound
|
Some backends do not provide a means to change the volume of sound
|
||||||
effects or music. The mixing of music and sound is left to external
|
effects or music. The mixing of music and sound is left to external
|
||||||
libraries/the operating system we can't handle the volume control
|
libraries/the operating system we can't handle the volume control
|
||||||
in OpenTTD. As a result you can't change the volume inside OpenTTD
|
in OpenTTD. As a result you can't change the volume inside OpenTTD
|
||||||
for backends such as SDL; just use the volume control provided by
|
for backends such as SDL; just use the volume control provided by
|
||||||
your operating system.
|
your operating system.
|
||||||
|
|
||||||
Can't run OpenTTD with the -d option from a MSYS console [FS#4587]
|
|
||||||
The MSYS console does not allow OpenTTD to open an extra console for
|
|
||||||
debugging output. Compiling OpenTTD with the --enable-console
|
|
||||||
configure option prevents this issue and allows the -d option to use
|
|
||||||
the MSYS console for its output.
|
|
||||||
|
|
||||||
Unreadable characters for non-latin locales [FS#4607]
|
|
||||||
OpenTTD does not ship a non-latin font in its graphics files. As a
|
|
||||||
result OpenTTD needs to acquire the font from somewhere else. What
|
|
||||||
OpenTTD does is ask the operating system, or a system library, for
|
|
||||||
the best font for a given language if the currently loaded font
|
|
||||||
does not provide all characters of the chosen translation. This
|
|
||||||
means that OpenTTD has no influence over the quality of the chosen
|
|
||||||
font; it just does the best it can do.
|
|
||||||
|
|
||||||
If the text is unreadable there are several steps that you can take
|
|
||||||
to improve this. The first step is finding a good font and configure
|
|
||||||
this in the configuration file. See section 9.0 of readme.txt for
|
|
||||||
more information. You can also increase the font size to make the
|
|
||||||
characters bigger and possible better readable.
|
|
||||||
|
|
||||||
If the problem is with the clarity of the font you might want to
|
|
||||||
enable anti-aliasing by setting the small_aa/medium_aa/large_aa
|
|
||||||
settings to "true". However, anti-aliasing only works when a 32 bits
|
|
||||||
blitter has been selected, e.g. blitter = "32bpp-anim", as with the
|
|
||||||
8 bits blitter there are not enough colours to properly perform the
|
|
||||||
anti-aliasing.
|
|
||||||
|
|
||||||
(Temporary) wrong colours when switching to full screen [FS#4511]:
|
(Temporary) wrong colours when switching to full screen [FS#4511]:
|
||||||
On Windows it can happen that you temporarily see wrong colours
|
On Windows it can happen that you temporarily see wrong colours
|
||||||
when switching to full screen OpenTTD, either by starting
|
when switching to full screen OpenTTD, either by starting
|
||||||
OpenTTD in full screen mode, changing to full screen mode or by
|
OpenTTD in full screen mode, changing to full screen mode or by
|
||||||
ALT-TAB-ing into a full screen OpenTTD. This is caused by the
|
ALT-TAB-ing into a full screen OpenTTD. This is caused by the
|
||||||
fact that OpenTTD, by default, uses 8bpp paletted output. The
|
fact that OpenTTD, by default, uses 8bpp paletted output. The
|
||||||
wrong colours you are seeing is a temporary effect of the video
|
wrong colours you are seeing is a temporary effect of the video
|
||||||
driver switching to 8bpp palette mode.
|
driver switching to 8bpp palette mode.
|
||||||
|
|
||||||
This issue can be worked around in two ways:
|
This issue can be worked around in two ways:
|
||||||
a) Setting fullscreen_bpp to 32
|
a) Setting fullscreen_bpp to 32
|
||||||
b) Setting up the 32bpp-anim or 32bpp-optimized blitter
|
b) Setting up the 32bpp-anim or 32bpp-optimized blitter
|
||||||
|
|
||||||
|
Can't run OpenTTD with the -d option from a MSYS console [FS#4587]:
|
||||||
|
The MSYS console does not allow OpenTTD to open an extra console for
|
||||||
|
debugging output. Compiling OpenTTD with the --enable-console
|
||||||
|
configure option prevents this issue and allows the -d option to use
|
||||||
|
the MSYS console for its output.
|
||||||
|
|
||||||
|
Unreadable characters for non-latin locales [FS#4607]:
|
||||||
|
OpenTTD does not ship a non-latin font in its graphics files. As a
|
||||||
|
result OpenTTD needs to acquire the font from somewhere else. What
|
||||||
|
OpenTTD does is ask the operating system, or a system library, for
|
||||||
|
the best font for a given language if the currently loaded font
|
||||||
|
does not provide all characters of the chosen translation. This
|
||||||
|
means that OpenTTD has no influence over the quality of the chosen
|
||||||
|
font; it just does the best it can do.
|
||||||
|
|
||||||
|
If the text is unreadable there are several steps that you can take
|
||||||
|
to improve this. The first step is finding a good font and configure
|
||||||
|
this in the configuration file. See section 9.0 of README.md for
|
||||||
|
more information. You can also increase the font size to make the
|
||||||
|
characters bigger and possible better readable.
|
||||||
|
|
||||||
|
If the problem is with the clarity of the font you might want to
|
||||||
|
enable anti-aliasing by setting the small_aa/medium_aa/large_aa
|
||||||
|
settings to "true". However, anti-aliasing only works when a 32-bit
|
||||||
|
blitter has been selected, e.g. blitter = "32bpp-anim", as with the
|
||||||
|
8 bits blitter there are not enough colours to properly perform the
|
||||||
|
anti-aliasing.
|
||||||
|
|
||||||
Train does not crash with itself [FS#4635]:
|
Train does not crash with itself [FS#4635]:
|
||||||
When a train drives in a circle the front engine passes through
|
When a train drives in a circle the front engine passes through
|
||||||
wagons of the same train without crashing. This is intentional.
|
wagons of the same train without crashing. This is intentional.
|
||||||
Signals are only aware of tracks, they do not consider the train
|
Signals are only aware of tracks, they do not consider the train
|
||||||
length and whether there would be enough room for a train in some
|
length and whether there would be enough room for a train in some
|
||||||
circle it might drive on. Also the path a train might take is not
|
circle it might drive on. Also the path a train might take is not
|
||||||
necessarily known when passing a signal.
|
necessarily known when passing a signal.
|
||||||
Checking all circumstances would take a lot of additional computational
|
Checking all circumstances would take a lot of additional
|
||||||
power for signals, which is not considered worth the effort, as
|
computational power for signals, which is not considered worth
|
||||||
it does not add anything to gameplay.
|
the effort, as it does not add anything to gameplay.
|
||||||
Nevertheless trains shall not crash in normal operation, so making
|
Nevertheless trains shall not crash in normal operation, so making
|
||||||
a train not crash with itself is the best solution for everyone.
|
a train not crash with itself is the best solution for everyone.
|
||||||
|
|
||||||
Aircraft coming through wall in rotated airports [FS#4705]:
|
Aircraft coming through wall in rotated airports [FS#4705]:
|
||||||
With rotated airports, specifically hangars, you will see that the
|
With rotated airports, specifically hangars, you will see that the
|
||||||
aircraft will show a part through the back wall of the hangar.
|
aircraft will show a part through the back wall of the hangar.
|
||||||
This can be solved by only drawing a part of the plane when being
|
This can be solved by only drawing a part of the plane when being
|
||||||
at the back of the hangar, however then with transparency turned on
|
at the back of the hangar, however then with transparency turned on
|
||||||
the aircraft would be shown partially which would be even weirder.
|
the aircraft would be shown partially which would be even weirder.
|
||||||
As such the current behaviour is deemed the least bad.
|
As such the current behaviour is deemed the least bad.
|
||||||
The same applies to overly long ships and their depots.
|
The same applies to overly long ships and their depots.
|
||||||
|
|
||||||
Vehicles not keeping their "maximum" speed [FS#4815]:
|
Vehicles not keeping their "maximum" speed [FS#4815]:
|
||||||
Vehicles that have not enough power to reach and maintain their
|
Vehicles that have not enough power to reach and maintain their
|
||||||
advertised maximum speed might be constantly jumping between two
|
advertised maximum speed might be constantly jumping between two
|
||||||
speeds. This is due to the fact that speed and its calculations
|
speeds. This is due to the fact that speed and its calculations
|
||||||
are done with integral numbers instead of floating point numbers.
|
are done with integral numbers instead of floating point numbers.
|
||||||
As a result of this a vehicle will never reach its equilibrium
|
As a result of this a vehicle will never reach its equilibrium
|
||||||
between the drag/friction and propulsion. So in effect it will be
|
between the drag/friction and propulsion. So in effect it will be
|
||||||
in a vicious circle of speeding up and slowing down due to being
|
in a vicious circle of speeding up and slowing down due to being
|
||||||
just at the other side of the equilibrium.
|
just at the other side of the equilibrium.
|
||||||
|
|
||||||
Not speeding up when near the equilibrium will cause the vehicle
|
Not speeding up when near the equilibrium will cause the vehicle to
|
||||||
to never come in the neighbourhood of the equilibrium and not
|
never come in the neighbourhood of the equilibrium and not slowing
|
||||||
slowing down when near the equilibrium will cause the vehicle
|
down when near the equilibrium will cause the vehicle to never slow
|
||||||
to never slow down towards the equilibrium once it has come down
|
down towards the equilibrium once it has come down a hill.
|
||||||
a hill.
|
|
||||||
|
|
||||||
It is possible to calculate whether the equilibrium will be
|
It is possible to calculate whether the equilibrium will be passed,
|
||||||
passed, but then all acceleration calculations need to be done
|
but then all acceleration calculations need to be done twice.
|
||||||
twice.
|
|
||||||
|
|
||||||
Settings not saved when OpenTTD crashes [FS#4846]:
|
Settings not saved when OpenTTD crashes [FS#4846]:
|
||||||
The settings are not saved when OpenTTD crashes for several reasons.
|
The settings are not saved when OpenTTD crashes for several reasons.
|
||||||
The most important is that the game state is broken and as such the
|
The most important is that the game state is broken and as such the
|
||||||
settings might contain invalid values, or the settings have not even
|
settings might contain invalid values, or the settings have not even
|
||||||
been loaded yet. This would cause invalid or totally wrong settings
|
been loaded yet. This would cause invalid or totally wrong settings
|
||||||
to be written to the configuration file.
|
to be written to the configuration file.
|
||||||
|
|
||||||
A solution to that would be saving the settings whenever one changes,
|
A solution to that would be saving the settings whenever one changes,
|
||||||
however due to the way the configuration file is saved this requires
|
however due to the way the configuration file is saved this requires
|
||||||
a flush of the file to the disk and OpenTTD needs to wait till that
|
a flush of the file to the disk and OpenTTD needs to wait till that
|
||||||
is finished. On some file system implementations this causes the
|
is finished. On some file system implementations this causes the
|
||||||
flush of all 'write-dirty' caches, which can be a significant amount
|
flush of all 'write-dirty' caches, which can be a significant amount
|
||||||
of data to be written. This can further be aggravated by spinning
|
of data to be written. This can further be aggravated by spinning
|
||||||
down disks to conserve power, in which case this disk needs to be
|
down disks to conserve power, in which case this disk needs to be
|
||||||
spun up first. This means that many seconds may pass before the
|
spun up first. This means that many seconds may pass before the
|
||||||
configuration file is actually written, and all that time OpenTTD
|
configuration file is actually written, and all that time OpenTTD
|
||||||
will not be able to show any progress. Changing the way the
|
will not be able to show any progress. Changing the way the
|
||||||
configuration file is saved is not an option as that leaves us more
|
configuration file is saved is not an option as that leaves us more
|
||||||
vulnerable to corrupt configuration files.
|
vulnerable to corrupt configuration files.
|
||||||
|
|
||||||
Finally, crashes should not be happening. If they happen they should
|
Finally, crashes should not be happening. If they happen they should
|
||||||
be reported and fixed, so essentially fixing this is fixing the
|
be reported and fixed, so essentially fixing this is fixing the wrong
|
||||||
wrong thing. If you really need the configuration changes to be
|
thing. If you really need the configuration changes to be saved,
|
||||||
saved, and you need to run a version that crashes regularly, then
|
and you need to run a version that crashes regularly, then you can
|
||||||
you can use the 'saveconfig' command in the console to save the
|
use the 'saveconfig' command in the console to save the settings.
|
||||||
settings.
|
|
||||||
|
|
||||||
Not all NewGRFs, AIs, game scripts are found [FS#4887]:
|
Not all NewGRFs, AIs, game scripts are found [FS#4887]:
|
||||||
Under certain situations, where the path for the content within a
|
Under certain situations, where the path for the content within a
|
||||||
tar file is the same as other content on the file system or in another
|
tar file is the same as other content on the file system or in another
|
||||||
tar file, it is possible that content is not found. A more thorough
|
tar file, it is possible that content is not found. A more thorough
|
||||||
explanation and solutions are described in section 4.4 of readme.txt.
|
explanation and solutions are described in section 4.4 of README.md.
|
||||||
|
|
||||||
Mouse cursor going missing with SDL [FS#4997]:
|
Mouse cursor going missing with SDL [FS#4997]:
|
||||||
Under certain circumstances SDL does not notify OpenTTD of changes
|
Under certain circumstances SDL does not notify OpenTTD of changes with
|
||||||
with respect to the mouse pointer, specifically whether the mouse
|
respect to the mouse pointer, specifically whether the mouse pointer
|
||||||
pointer is within the bounds of OpenTTD or not. For example, if you
|
is within the bounds of OpenTTD or not. For example, if you "Alt-Tab"
|
||||||
Alt-tab to another application the mouse cursor will still be shown
|
to another application the mouse cursor will still be shown in OpenTTD,
|
||||||
in OpenTTD, and when you move the mouse outside of the OpenTTD
|
and when you move the mouse outside of the OpenTTD window so the cursor
|
||||||
window so the cursor gets hidden, open/move another application on
|
gets hidden, open/move another application on top of the OpenTTD window
|
||||||
top of the OpenTTD window and then Alt-tab back into OpenTTD the
|
and then Alt-tab back into OpenTTD the cursor will not be shown.
|
||||||
cursor will not be shown.
|
|
||||||
|
|
||||||
We cannot fix this problem as SDL simply does not provide the
|
We cannot fix this problem as SDL simply does not provide the required
|
||||||
required information in these corner cases. This is a bug in SDL
|
information in these corner cases. This is a bug in SDL and as such
|
||||||
and as such there is little that we can do about it.
|
there is little that we can do about it.
|
||||||
|
|
||||||
Inconsistent catchment areas [FS#5661]:
|
|
||||||
Due to performance decisions the catchment area for cargo accepted
|
|
||||||
by a station for delivery to houses or industries differs from the
|
|
||||||
catchment area for cargo that is delivered to stations from houses
|
|
||||||
or industries.
|
|
||||||
|
|
||||||
Conceptually they work the same, but the effect in game differs.
|
|
||||||
They work by finding the closest destination "around" the source
|
|
||||||
which is within a certain distance. This distance depends on the
|
|
||||||
type of station, e.g. road stops have a smaller catchment area than
|
|
||||||
large airports. In both cases the bounding box, the smallest
|
|
||||||
rectangle that contains all tiles of something, is searched for the
|
|
||||||
target of the cargo, and then spiraling outwards finding the closest
|
|
||||||
tile of the target.
|
|
||||||
|
|
||||||
In the case of a station with two tiles spread far apart with a house
|
|
||||||
that is within the station's bounding box, it would be possible that
|
|
||||||
the spiraling search from the house does not reach one of the station
|
|
||||||
tiles before the search ends, i.e. all tiles within that distance
|
|
||||||
are searched. So the house does not deliver cargo to the station. On
|
|
||||||
the other hand, the station will deliver cargo because the house
|
|
||||||
falls within the bounding box, and thus search area.
|
|
||||||
|
|
||||||
It is possible to make these consistent, but then cargo from a house
|
|
||||||
to a station needs to search up to 32 tiles around itself, i.e. 64
|
|
||||||
by 64 tiles, to find all possible stations it could deliver to
|
|
||||||
instead of 10 by 10 tiles (40 times more tiles). Alternatively the
|
|
||||||
search from a station could be changed to use the actual tiles, but
|
|
||||||
that would require considering checking 10 by 10 tiles for each of
|
|
||||||
the tiles of a station, instead of just once.
|
|
||||||
|
|
||||||
Trains might not stop at platforms that are currently being changed [FS#5553]:
|
Trains might not stop at platforms that are currently being changed [FS#5553]:
|
||||||
If you add tiles to or remove tiles from a platform while a train is
|
If you add tiles to or remove tiles from a platform while a train is
|
||||||
approaching to stop at the same platform, that train can miss the place
|
approaching to stop at the same platform, that train can miss the place
|
||||||
where it's supposed to stop and pass the station without stopping. This
|
where it's supposed to stop and pass the station without stopping.
|
||||||
is caused by the fact that the train is considered to already have stopped
|
This is caused by the fact that the train is considered to already
|
||||||
if it's beyond its assigned stopping location. We can't let the train stop
|
have stopped if it's beyond its assigned stopping location. We can't
|
||||||
just anywhere in the station because then it would never leave the station
|
let the train stop just anywhere in the station because then it would
|
||||||
if you have the same station in the order list multiple times in a row or
|
never leave the station if you have the same station in the order
|
||||||
if there is only one station in the order list (see FS#5684).
|
list multiple times in a row or if there is only one station
|
||||||
|
in theorder list (see FS#5684).
|
||||||
|
|
||||||
|
Inconsistent catchment areas [FS#5661]:
|
||||||
|
Due to performance decisions the catchment area for cargo accepted by a
|
||||||
|
station for delivery to houses or industries differs from the catchment
|
||||||
|
area for cargo that is delivered to stations from houses or industries.
|
||||||
|
|
||||||
|
Conceptually they work the same, but the effect in game differs. They
|
||||||
|
work by finding the closest destination "around" the source which is
|
||||||
|
within a certain distance. This distance depends on the type of station,
|
||||||
|
e.g. road stops have a smaller catchment area than large airports.
|
||||||
|
In both cases the bounding box, the smallest rectangle that contains
|
||||||
|
all tiles of something, is searched for the target of the cargo,
|
||||||
|
and then spiraling outwards finding the closest tile of the target.
|
||||||
|
|
||||||
|
In the case of a station with two tiles spread far apart with a house
|
||||||
|
that is within the station's bounding box, it would be possible that
|
||||||
|
the spiraling search from the house does not reach one of the station
|
||||||
|
tiles before the search ends, i.e. all tiles within that distance
|
||||||
|
are searched. So the house does not deliver cargo to the station.
|
||||||
|
On the other hand, the station will deliver cargo because the house
|
||||||
|
falls within the bounding box, and thus search area.
|
||||||
|
|
||||||
|
It is possible to make these consistent, but then cargo from a house
|
||||||
|
to a station needs to search up to 32 tiles around itself, i.e. 64
|
||||||
|
by 64 tiles, to find all possible stations it could deliver to
|
||||||
|
instead of 10 by 10 tiles (40 times more tiles). Alternatively the
|
||||||
|
search from a station could be changed to use the actual tiles, but
|
||||||
|
that would require considering checking 10 by 10 tiles for each of
|
||||||
|
the tiles of a station, instead of just once.
|
||||||
|
|
||||||
Some houses and industries are not affected by transparency [FS#5817]:
|
Some houses and industries are not affected by transparency [FS#5817]:
|
||||||
Some of the default houses and industries (f.e. the iron ore mine) are
|
Some of the default houses and industries (f.e. the iron ore mine) are
|
||||||
not affected by the transparency options. This is because the graphics do
|
not affected by the transparency options. This is because the graphics
|
||||||
not (completely) separate the ground from the building.
|
do not (completely) separate the ground from the building.
|
||||||
This is a bug of the original graphics, and unfortunately cannot be
|
This is a bug of the original graphics, and unfortunately cannot be
|
||||||
fixed with OpenGFX for the sake of maintaining compatibility with the
|
fixed with OpenGFX for the sake of maintaining compatibility with
|
||||||
original graphics.
|
the original graphics.
|
||||||
|
|
||||||
Involuntary cargo exchange with cargodist via neutral station [FS#6114]:
|
Involuntary cargo exchange with cargodist via neutral station [FS#6114]:
|
||||||
When two players serve a neutral station at an industry, a cross-company
|
When two players serve a neutral station at an industry, a cross-company
|
||||||
chain for cargo flow can and will be established which can only be
|
chain for cargo flow can and will be established which can only be
|
||||||
interrupted if one of the players stops competing for the ressources of
|
interrupted if one of the players stops competing for the ressources of
|
||||||
that industry. There is an easy fix for this: If you are loading at the
|
that industry. There is an easy fix for this: If you are loading at the
|
||||||
shared station make the order "no unload" and if you're unloading make
|
shared station make the order "no unload" and if you're unloading make
|
||||||
it "no load". Cargodist will then figure out that it should not create
|
it "no load". Cargodist will then figure out that it should not create
|
||||||
such a route.
|
such a route.
|
||||||
|
|
Loading…
Reference in New Issue