mirror of
https://github.com/JGRennison/OpenTTD-patches.git
synced 2024-11-17 21:25:40 +00:00
273 lines
14 KiB
Plaintext
273 lines
14 KiB
Plaintext
OpenTTD's known bugs
|
|
Last updated: 2010-09-14
|
|
Release version: 1.0.4
|
|
------------------------------------------------------------------------
|
|
|
|
|
|
Table of Contents:
|
|
------------------
|
|
1) About
|
|
2) Known bugs in the this stable release
|
|
3) Known bugs that will not be solved
|
|
|
|
|
|
1) About:
|
|
-- ------
|
|
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
|
|
we WILL flame you!!
|
|
|
|
Of course if you have more knowledge about any of these bugs, have more
|
|
specifics, we welcome you to report them. React to the given bug indicated
|
|
by the number below on http://bugs.openttd.org.
|
|
|
|
|
|
2) Known bugs in the this stable release:
|
|
-- --------------------------------------
|
|
The following bugs are known to exist in this stable release and
|
|
we intend to fix them. Some bugs are known but are not fixable or
|
|
fixing them would cause further problems. Those bugs can be found
|
|
in the "Known bugs that will not be solved" section.
|
|
|
|
The bugs in this section all refer to a ticket in our bug tracking system
|
|
that you can find at: http://bugs.openttd.org
|
|
If the bugs are closed but still listed here it means that the bug is fixed
|
|
and that the nightlies and next major release will not have that bug.
|
|
|
|
Issues prefixed with [OSX] are required to be fixed before we consider
|
|
officially supporting Mac OS X again. For now it remains unsupported and
|
|
we only apply bug fixes provided by the community but we are unable to fix
|
|
these bugs ourselves.
|
|
|
|
- 4003 [OSX] Running OpenTTD Parallels causes privileged instructions
|
|
- 4001 [OSX] SETX[Y] not ignored in SetFallbackFont
|
|
- 3952 Console command rescan_ai does not remove AIs
|
|
- 3935 Under some circumstances two road vehicles can leave road stop simultaniously
|
|
- 3746 Console output with right-to-left texts in left-to-right texts is not correct
|
|
- 3714 Some corrupted savegames can cause crashes
|
|
- 3651 [OSX] Crash when selecting full screen
|
|
- 3648 [OSX] Crash when selecting music
|
|
- 3637 Second highest competing station gets penalised twice
|
|
- 3546 Ignoring signals might crash trains
|
|
- 3447 [OSX] SDL port is unuseable
|
|
- 2782 [OSX] Port hopelessly outdated
|
|
- 2585 [OSX] OS' mouse pointer showing
|
|
- 2484 [OSX] Cannot enter CJK characters
|
|
|
|
|
|
3) Known bugs that will not be solved:
|
|
-- -----------------------------------
|
|
This section lists all known bugs that we do not intend to fix and the
|
|
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
|
|
be able to completely fix them.
|
|
|
|
No suitable AI can be found
|
|
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
|
|
window and showing a red warning. There are basically two solutions
|
|
for this problem: you must change the settings so no AI is started,
|
|
this is done in the difficulty settings window. 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) menu or via
|
|
"AI Settings" -> "Select AI" -> "Check Online Content" which is also
|
|
accessed via the main menu.
|
|
|
|
After a while of playing, colours get corrupted
|
|
In Windows 7 the background slideshow corrupts the colour mapping of
|
|
OpenTTD's 8bpp screen modes. Workarounds for this are:
|
|
a) Switching to windowed mode, instead of fullscreen
|
|
b) Switching off background slideshow
|
|
c) Setting up the 32bpp-anim or 32bpp-optimized blitter
|
|
|
|
Long delay between switching songs/music
|
|
On Windows there is a delay of a (few) second(s) between switching of
|
|
songs for the "win32" driver. This delay is caused by the fact that
|
|
opening a MIDI file via MCI is extremely slow.
|
|
|
|
DirectMusic, known as "dmusic" in OpenTTD, has a much shorter delay.
|
|
However, under some circumstances DirectMusic does not reset its
|
|
state properly causing wrongly pitched/bad sounding songs. This
|
|
problem is in DirectMusic as it is reproducable with Microsoft's
|
|
DirectMusic Producer. DirectMusic has been deprecated since 2004
|
|
and as such has no support for 64 bits OpenTTD.
|
|
|
|
As a delay is favourable over bad sounding music the "win32" driver
|
|
is the default driver for OpenTTD. You can change this default by
|
|
setting the "musicdriver" in your openttd.cfg to "dmusic".
|
|
|
|
Custom vehicle type name is incorrectly aligned
|
|
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 type name. Upon renaming the vehicle type this encoded offset
|
|
is stripped from the name because the "edit box" cannot show this
|
|
encoding. As a result the custom vehicle type names will get the
|
|
default alignment. The only way to (partly) fix this is by adding
|
|
spaces to the custom name.
|
|
|
|
Clipping problems [FS#119]
|
|
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
|
|
in some cases are rendered over vehicles.
|
|
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
|
|
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
|
|
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
|
|
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
|
|
big problems.
|
|
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
|
|
leave the Transport Tycoon graphics, which in effect means OpenTTD
|
|
will not be a Transport Tycoon clone anymore.
|
|
|
|
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
|
|
in the same direction of the edge will fail. If the cursor is near the
|
|
edge the scrolling will be very slow.
|
|
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
|
|
outside of OpenTTD's window.
|
|
|
|
Lost trains ignore (block) exit signals [FS#1473]
|
|
If trains are lost they ignore block exit signals, blocking junctions
|
|
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
|
|
each junction. This causes the trains to occasionally to make choices
|
|
that are unwanted from a player's point of view.
|
|
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
|
|
makes the impact of fixing the bug enormously small against the
|
|
amount of work needed to write a system that prevents the lost trains
|
|
from taking the wrong direction.
|
|
|
|
Vehicle owner of last transfer leg gets paid for all [FS#2427]
|
|
When you make a transfer system that switches vehicle owners. This
|
|
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 whole trip. It is not shared amongst the different vehicle
|
|
owners that have participated in transporting the cargo.
|
|
This sharing is not done because it would enormously increase the
|
|
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
|
|
sharing of stations is an official feature.
|
|
|
|
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
|
|
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
|
|
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
|
|
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
|
|
train through means that your network is broken and is thus a user
|
|
error which OpenTTD tries to graciously handle.
|
|
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
|
|
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.
|
|
|
|
Duplicate (station) names after renaming [FS#3204]
|
|
After renaming stations one can create duplicate station names. This
|
|
is done giving a station the same custom name as another station with
|
|
an automatically generated name.
|
|
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
|
|
'<TOWN> Centraal' in Dutch. This means that in network games the
|
|
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
|
|
be seen as a 'desync'. Secondly the custom names are intended to fall
|
|
completely outside of the '<TOWN> <name>' naming of stations, so when
|
|
you rename a town all station names are updated accordingly.
|
|
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
|
|
to the automatically generated names.
|
|
|
|
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 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
|
|
same configuration OpenTTD, or rather SDL, might hang when exiting
|
|
the game. This problem is seen most in Ubuntu 9.04 and higher.
|
|
|
|
This is because recent versions of the PulseAudio sound server are
|
|
configured to use timer-based audio scheduling rather than
|
|
interrupt-based audio scheduling. Configuring PulseAudio to force
|
|
use of interrupt-based scheduling may resolve sound problems for
|
|
some users. Under recent versions of Ubuntu Linux (9.04 and higher)
|
|
this can be accomplished by changing the following line in the
|
|
/etc/pulse/default.pa file:
|
|
load-module module-udev-detect
|
|
to
|
|
load-module module-udev-detect tsched=0
|
|
Note that PulseAudio must be restarted for changes to take effect.
|
|
Older versions of PulseAudio may use the module-hal-detect module
|
|
instead. Adding tsched=0 to the end of that line will have a similar
|
|
effect.
|
|
|
|
Another possible solution is selecting the "pulse" backend of SDL
|
|
by either using "SDL_AUDIODRIVER=pulse openttd" at the command
|
|
prompt or installing the 'libsdl1.2debian-pulseaudio' package from
|
|
Ubuntu's Universe repository. For other distributions a similar
|
|
package needs to be installed.
|
|
|
|
OpenTTD not properly resizing with SDL on X [FS#3305]
|
|
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
|
|
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
|
|
not always receive a resize event from SDL making it impossible for
|
|
OpenTTD to know that the window was resized; sometimes moving the
|
|
window will solve the problem.
|
|
Window managers that are known to exhibit this behaviour are KDE's
|
|
and GNOME's. With the XFCE's and LXDE's window managers the resize
|
|
event is sent when the user releases the mouse.
|
|
|
|
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
|
|
block signal and the reservation passes a path signal through the
|
|
back another train can enter the reserved path (only) via that same
|
|
two way block signal.
|
|
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
|
|
a train or a backwards facing signal. This is a very expensive task.
|
|
The (signal) setups that allow these crashes can furthermore be
|
|
considered incorrectly signalled; one extra safe waiting point for
|
|
the train entering from path signal just after the backwards facing
|
|
signal (from the path signal train) resolves the issue.
|
|
|
|
Crashes when playing music [FS#3941]
|
|
Mac OS X's QuickTime (default music driver) and Windows' MCI (win32
|
|
music driver) crash on some songs from OpenMSX. OpenTTD cannot do
|
|
anything about this. Please report these crashes to the authors of
|
|
OpenMSX so the crash causing songs can be removed or fixed.
|
|
|
|
Crashes when run in a VM using Parallels Desktop [FS#4003]
|
|
When the Windows version of OpenTTD is executed in a VM under
|
|
Parallels Desktop a privileged instruction exception may be thrown.
|
|
As OpenTTD works natively on OSX as well as natively on Windows and
|
|
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
|
|
the scope of OpenTTD. Most likely this is due to Parallels Desktop
|
|
lacking support for RDTSC calls. The problem can be avoided by using
|
|
other VM-software, Wine, or running natively on OSX.
|
|
|
|
OpenTTD hangs when started on 32 bits Windows [FS#4083]
|
|
Under some circumstances OpenTTD might hang for hours on the
|
|
initialisation of the music driver. The exact circumstances are
|
|
unknown except that it is the "dmusic" music driver that has the
|
|
problem and that the "win32" music driver does not.
|
|
As a result using the "win32" music driver will work around this
|
|
issue.
|
|
|
|
As the exact circumstances are unknown, and the obvious
|
|
configuration settings related to the music driver are at their
|
|
default we are not able to detect this failure, except when Windows'
|
|
music initialisation function returns after several hours and then
|
|
there is no point in switching the music driver anymore.
|
|
The reason we do not use the "win32" music driver as default are
|
|
described in the "Long delay between switching music/song" section
|
|
of this document.
|