Last updated:    2018-11-05

Release version: 1.8.0

we WILL flame you!

bug tracking system at https://github.com/OpenTTD/OpenTTD/issues

Also check the closed bugs when searching for your bug in this system as we

might have fixed the bug in the mean time.

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: 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

        "AI / Game Scripts 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 directly in the "AI / Game Scripts Settings" dialogue via the

        "Check Online Content" button.

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-bit 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 (partially) 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 GNOME's

        and KDE's. With the XFCE's and LXDE's window managers the resize

        event is sent when the user releases the mouse.

window resizing with SDL on macOS [FS#3447]:

        Video handling with (lib)SDL under macOS is known to fail on some

        versions of macOS 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 macOS.

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]:

        macOS'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 macOS 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 macOS.

OpenTTD hangs when started on 32-bit 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.

Entry- 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

        convenient 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.

        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

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.

        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.

        With rotated airports, specifically hangars, you will see that the

        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

        at the back of the hangar, however then with transparency turned on

        the aircraft would be shown partially which would be even weirder.

        As such the current behaviour is deemed the least bad.

        The same applies to overly long ships and their depots.

        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.

        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

        settings might contain invalid values, or the settings have not even

        been loaded yet. This would cause invalid or totally wrong settings

        to be written to the configuration file.

        A solution to that would be saving the settings whenever one changes,

        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

        is finished. On some file system implementations this causes the

        flush of all 'write-dirty' caches, which can be a significant amount

        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

        spun up first. This means that many seconds may pass before the

        configuration file is actually written, and all that time OpenTTD

        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

        vulnerable to corrupt configuration files.

        Finally, crashes should not be happening. If they happen they should

        be reported and fixed, so essentially fixing this is fixing the wrong

        thing. If you really need the configuration changes to be saved,

        and you need to run a version that crashes regularly, then you can

        use the 'saveconfig' command in the console to save the settings.

        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, it is possible that content is not found. A more thorough

        explanation and solutions are described in section 4.4 of README.md.

        Under certain circumstances SDL does not notify OpenTTD of changes with

        respect to the mouse pointer, specifically whether the mouse pointer

        is within the bounds of OpenTTD or not. For example, if you "Alt-Tab"

        to another application the mouse cursor will still be shown in OpenTTD,

        and when you move the mouse outside of the OpenTTD window so the cursor

        gets hidden, open/move another application on top of the OpenTTD window

        and then Alt-tab back into OpenTTD the cursor will not be shown.

        We cannot fix this problem as SDL simply does not provide the required

        information in these corner cases. This is a bug in SDL and as such

        there is little that we can do about it.

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

        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 is caused by the fact that the train is considered to already

        have stopped if it's beyond its assigned stopping location. We can't

        let the train stop just anywhere in the station because then it would

        never leave the station if you have the same station in the order

        list multiple times in a row or if there is only one station

        in theorder list (see FS#5684).

        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 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 (completely) separate the ground from the building.

        This is a bug of the original graphics, and unfortunately cannot be

        fixed with OpenGFX for the sake of maintaining compatibility with

        the original graphics.

        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

        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

        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

        such a route.