OpenTTD/known-bugs.txt

OpenTTD's known bugs
Last updated:    2011-12-05
Release version: 1.1.4
------------------------------------------------------------------------


Table of contents
-----------------
1.0) About
2.0) Known bugs in this release
 * 2.1) Known bugs that will not be solved


1.0) 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.0) Known bugs in this release
---- --------------------------
The following bugs are known to exist in this 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.

- 4744  [OSX] Crash when switching to full screen with OS X Lion
- 4689  [OSX] Crash when hiding window after coming from full screen
- 4594  [Windows] Minimizing the windows when a modal error message is
        shown makes it difficult to exit the game
- 4420  [OSX] OS' mouse pointer still shows
- 2484  [OSX] Cannot enter CJK characters

2.1) 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.

Incorrect colours, crashes upon exit, debug warnings and smears upon
window resizing with SDL on Mac OS X [FS#3447]
	Video handling with (lib)SDL under Mac OS X is known to fail on some
	versions of Mac OS X with some hardware configurations. Some of the
	problems happen only under some circumstances whereas others are
	always present.
	We suggest that the SDL video/sound backend is not used for OpenTTD
	in combinations with Mac OS X.

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 still use the "win32" music driver as default are
	described in the "Long delay between switching music/song" section
	of this document.

Pre- and exit signals are not dragged [FS#4378]
	Unlike all other signal types, the entry- and exit signals are not
	dragged but instead normal signals are placed on subsequent track
	sections. This is done on purpose as this is the usually more con-
	venient solution. There are little to no occasions where more 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
	purpose or another.

Station build date is incorrect [FS#4415]
	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
	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
	was completely destroyed/rebuilt later on.
	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
	deemed too specific and long for that window.

Can't change volume inside OpenTTD [FS#4416]
	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
	libraries/the operating system we can't handle the volume control
	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
	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]:
	On Windows it can happen that you temporarily see wrong colours
	when switching to full screen OpenTTD, either by starting
	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
	fact that OpenTTD, by default, uses 8bpp paletted output. The
	wrong colours you are seeing is a temporary effect of the video
	driver switching to 8bpp palette mode.

	This issue can be worked around in two ways:
		a) Setting fullscreen_bpp to 32
		b) Setting up the 32bpp-anim or 32bpp-optimized blitter

Train does not crash with itself [FS#4635]:
	When a train drives in a circle the front engine passes through
	wagons of the same train without crashing. This is intentional.
	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
	circle it might drive on. Also the path a train might take is not
	necessarily known when passing a signal.
	Checking all circumstances would take a lot of additional computational
	power for signals, which is not considered worth the effort, as
	it does not add anything to gameplay.
	Nevertheless trains shall not crash in normal operation, so making
	a train not crash with itself is the best solution for everyone.

Vehicles not keeping their "maximum" speed [FS#4815]:
	Vehicles that have not enough power to reach and maintain their
	advertised maximum speed might be constantly jumping between two
	speeds. This is due to the fact that speed and its calculations
	are done with integral numbers instead of floating point numbers.
	As a result of this a vehicle will never reach its equilibrium
	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
	just at the other side of the equilibrium.

	Not speeding up when near the equilibrium will cause the vehicle
	to never come in the neighbourhood of the equilibrium and not
	slowing down when near the equilibrium will cause the vehicle
	to never slow down towards the equilibrium once it has come down
	a hill.

	It is possible to calculate whether the equilibrium will be
	passed, but then all acceleration calculations need to be done
	twice.