OpenTTD's known bugs Last updated: 2010-02-04 Release version: 1.0.0-beta4 ------------------------------------------------------------------------ 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. - 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. 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. 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. ' Central' in English and ' 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 ' ' 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.