Release Notes

Every version, newest first. Downloads are on the releases page. MPFever updates itself; every player needs the same version.

0.5.9

A public list of dedicated servers, builds that show at once at every speed (experimental), and fixes for the dedicated server's window.

Fixes

• Dedicated server: the window of a stopped server showed an empty card, without the « Start with display » and « Start without display » buttons and the automatic start box (0.5.8). Only the console's start could start it. The card now shows them.
• Dedicated server: with « Start the server when MPFever opens » ticked, « stop » started the server again at once. After a stop, the window now waits for a new start.
• Nothing could be built after MPFever was disabled in the game's mod list while a lobby was open, then a savegame loaded. Builds are no longer held forever when MPFever's script is not running.
• One company per player: two players changing the same place within about two seconds led to a reload. The build made second is now left out on every game, and the chat tells its player to make it again.
• Dedicated server without display: the world's savegame picture was black. The picture of before is kept.
• A false « slight drift (buildIds) » at 2x and 4x when two builds came a few steps apart.

New

• Public server list. Dedicated servers now appear in the new Public servers tab of the multiplayer page, with their players, world, company mode, password and message of the day; players join them in one click. A server is listed by default: public=false in its mpfever_server.properties keeps it out.
• Responsive builds now at every speed (host setting, experimental, off at first): your builds show at once on your game instead of waiting for the other games, so you can attach the next piece right away. It was limited to 1x since 0.3.12 because towns drifted at 2x and 4x; that came from a cause fixed in 0.5.3. Checked: streets through towns at 4x and 2x, in sync, with the same entities on every game.

Checked

• Dedicated server without display, 2 h 53 at 4x with a player: 171 checks identical, one drift of towns and vehicles (no build involved) repaired by itself in 23 s, 17 autosaves of about 4 s, no error. The server's game used half the graphics card of the player's game.
• A player joining a server without display from the Public servers tab: in sync.
• A host game without display: builds, paused actions in turns, a player cut every 30 s, a resynchronisation: all in sync.

Known issues

• With two or more players, the games still stop for about a second at every build of another player. Responsive builds remove the wait for the builder only.

0.5.8

The dedicated server can run without display, and it starts with a button. Nothing changes for the players' games.

New

• Start with display or without display. The server's window now opens with the server stopped and two buttons:
  • Start with display: the game's window shows the world, as before.
  • Start without display: the game runs hidden. It simulates the world and hosts the players exactly the same way, but its window is never shown, the world is not drawn and it makes no sound: far less work for the graphics card and the processor. A graphics card able to run the game is still needed.
  • Both run the same world and the same saves: stop the server and start it the other way at any time.
  • The console has start and start headless too.
• Start by itself, if you want. The box Start the server when MPFever opens (off at first) starts the server as soon as MPFever.exe opens, the way it was started last.
• Stop without closing. Stop (the button or the console) saves the world and stops the server; the window waits for a new start. Closing the window, or exit, stops everything as before.
• The server's archive is easier to tell apart. Its folder is now called MPFever-Server (the players' one stays MPFever), and its MPFever.exe opens the server's window by itself, like start-server.bat.
• A stopped server updates at once; a server updated while it ran starts again the way it was running.

For servers already set up

• A server that updates itself from 0.5.7 keeps running with display, as before. To use the new way, stop it and click Start without display.
• A folder already in place keeps its name: only new downloads get MPFever-Server.

0.5.7

Fewer reloads: signals and tracks are now rebuilt exactly as their builder made them, and two players building at the same place no longer split the games.

Fixes

• Signals changed from their window, then a reload.
  • A signal keeps its own settings (one way or not, the year it was built). The other games rebuilt it without them, so it became another signal there.
  • In a test session, 20 signals switched to one way made the track network of the other game differ in 2063 places. The trains then went apart, and the games reloaded after the next track build.
  • Every replayed signal and stop now gets its builder's settings.
• Streets and tracks without their noise and pollution.
  • A street or track built by a player had its noise and pollution on that player's game only. Every other game rebuilt it without them, and the towns around it could slowly drift apart.
  • In the same session, 25 segments were concerned.
  • Every rebuilt segment now gets its builder's noise and pollution.
  • With these two fixes, that whole session, replayed from its savegame, gives the builder's world entity for entity. The track build that went apart gets exactly the builder's numbers.
• Signals on ordinary tracks are now rebuilt from the signal tool's own build, as signals on bridges and in tunnels already were.
• Two players changing the same place within about two seconds, the known issue of 0.5.6.
  • Before, a build was computed when the player clicked, then waited about two seconds for its turn. If another player built there in the meantime, the builder applied its old computation while every other game computed it again on the new ground, and the games reloaded.
  • Now the builder's game notices it: the build is sent to the others and rebuilt on every game the same way, at the same moment. If it no longer fits the place, it is left out on every game alike: just make it again.
  • Builds of two players landing at the very same moment are now applied in the same order on every game. Before, each game applied its own first.
  • Checked with two players upgrading the two streets of one crossing at the same time: before, the games went apart (9 differences found, a reload); now they stay in sync with the same numbers, three times in a row, and also in a pause.
  • Not yet with one company per player, where this can still lead to a reload.

Checked

• The session where the signals went apart, replayed from its savegame on two games on one PC. It now gives the builder's world entity for entity: tracks, signals, network, vehicles, persons, buildings. The track build that split the games now gets the builder's numbers.
• Two players changing one crossing at once, running and in a pause: in sync, the same numbers on both games.
• Earlier checks, run again and all in sync:
  • actions in a pause, in turns;
  • the free numbers of new entities;
  • a stalled engine on a big map;
  • two passages of a 2-hour session where reloads had happened.

Known issues

• Two players changing the same place within about two seconds, with one company per player, can still lead to a reload. MPFever notices it and reloads the games.
• A new crossing has no noise of its own on the other games (the game does not let a mod give it one). This is a very small difference.
• Disabling MPFever while still in a lobby, then loading a savegame, still blocks building: leave the lobby first.

Thanks

• Thanks to kingplay98, theop and Eagle for their sessions, logs and savegames: the two-players-at-the-same-place problem could be found and fixed thanks to them.
• Thanks to ArtemQa8, Gwemox and qLimAx1991 for their reports.
• Thanks to everyone who takes the time to send a problem report: each one helps make MPFever better for everybody.

0.5.6

Fewer reloads: every player's actions in a pause now happen in the same order on every game, and builds no longer land late when the game stalls on a big map.

Fixes

• Vehicles going apart after a building session in a pause, then a reload. In a pause, each player's builds already took turns, so that every game built them in the same order. Other actions did not: editing a line, buying a vehicle, renaming. Each game applied its own at once and the other players' when they arrived. In one of our testers' sessions, a line edited on the host went just before a bus stop of the other player there, and just after it on that player's game. The stop then took other free ids on each game, every vehicle bought afterwards got another number (72528 on one game, 62302 on the other), and the games reloaded 3 minutes later. Every action made in a pause now takes its turn with the builds, and every game applies them all in one order. (0.5.5 listed this as a problem of the bus stop replay: it was the order.)
• Builds landing late after the game stalled. On a big map, some builds (a lane modifier, industry extensions) make the simulation stand still for 10 to 13 seconds. A game waiting for another player's build took that silence for a lost request and asked for its steps again, then ran 15 steps instead of 3: the build landed 4 to 8 steps late, the towns went apart and the games reloaded. This caused 2 reloads in one evening of our testers. The request is now asked again only when the game is proven idle.
• Reloads during long building sessions in a pause. A check taken in a pause could compare a game that had already built the last stop with a game that had not yet. A player building on and on kept that difference check after check, until a reload. Games that are not at the same point of the pause are no longer compared, and the host's money taken at another point no longer "corrects" anyone.
• A replayed build landing one step late on one game, without any warning. A game could send another player's build to its engine while the engine was still finishing a step: the build then landed one step later there than everywhere else, and the games slowly drifted apart. In a replay of our testers' session, 34 builds out of 147 were sent that way (most of them still landed on time, by luck). A build now waits until the engine is seen standing still.
• A crash when selling several vehicles at once. If one of the vehicles sold did not exist as a vehicle on another player's game, that game crashed. Such a command is now skipped on that game and reported, like a missing vehicle already was.

Checked

• The order of actions in a pause: two games on one PC, the host buying vehicles while the client places bus stops, all in one pause. Without the fix, the same vehicle got number 33554 on one game and 34110 on the other. With it, every vehicle has the same number on both games, three runs in a row, in sync.
• A stalled game: the simulation made to stand still 12 seconds in the middle of a build, three times. With the fix, every build lands at its exact time, in sync. Without it, builds land up to 28 steps late and the games go out of sync.
• Our testers' whole evening replayed: the actions of their 2-hour session (about 600) replayed on two games on one PC, from their savegame (with their 14 mods): in sync from start to end, 37 checks identical, including at the very moments of their 5 reloads. In their pause of 22:08, the vehicles bought got exactly the numbers the host had got that evening.

Known issues

• Two players changing the same place within about two seconds can still lead to a reload. A player's build is computed when they click, then waits about two seconds for its turn. If another player's build changes the ground right there in the meantime, the first build no longer fits the ground the others see. MPFever notices it and reloads the games. It happened twice in our testers' 2-hour session, both times during a burst of 19 industry extensions next to a railway being demolished.
• Disabling MPFever while still in a lobby, then loading a savegame, still blocks building: leave the lobby first.

0.5.5

Fewer reloads: after a replayed build, every game gives new vehicles and buildings the same ids. Train stations no longer slow the game down without a lobby.

Fixes

• Towns and vehicles drifting apart after a build, then a reload. This was the most frequent cause of reloads in our testers' sessions of 2026-10-25 (4 reloads out of 6). Every new vehicle, building or road piece takes its id from a queue of free ids kept by the game. Replaying another player's build, for example a bus stop or a bus terminal, could leave that queue in another order on one game only. From then on, every new entity got another id there: in one session, the next vehicle bought was number 350772 on one game and 353349 on the other. Towns and vehicles then slowly went apart until the games reloaded. MPFever now keeps that queue in order, so every game gives the same ids. Measured at x4 with two games on one PC: no speed cost (x3.93 against x3.96).
• Reloads for nothing. The check added in 0.5.3 that compares the ids of each build could read them at a different moment on each game when the game ran faster than x1. One session reloaded although both games were the same. That check is now only written to the log, and never triggers a reload.
• The frame rate fell with every module added to a train station (issue #82), when the game ran without a lobby (MPFever.exe, then a savegame loaded from the game's own menu). MPFever kept a full copy of every build to send it to the other players, and without a lobby nobody took it. The game copies that data several times per frame. Measured on a train station of 31 modules edited 6 times: the frame rate went from 78 to 43 fps. Without a lobby, MPFever now keeps nothing. In a lobby, 0.5.3 already dropped the copies once sent: the frame rate stayed between 84 and 88 fps.
• Building stopped working after a session (issue #82): back in the main menu, then a savegame loaded from the game's menu, a new build could stay waiting forever. MPFever no longer holds builds once the session is over.

Diagnostics

• Two builds of another player were built two steps after their time on one game, which led to a reload. MPFever now writes in its log how the game stands when it replays a build, to find the cause if it happens again. In a later 50-minute session, all 100 replayed builds were built at their exact time.

Checked

• Desyncs: two games on one PC with BUILDLEAD on. Each player places bus stops on town streets, builds new roads and buys vehicles, then the game runs 3 minutes at x4: in sync, and both games gave every build and every vehicle the same ids.
• A real session of 50 minutes with the new id queue (our testers, 2 PCs): no crash, the queue was kept in order 470,000 times without a single failure.
• Train station: the frame rate measurements above.
• Joining through Steam between two Steam accounts on two PCs (new in 0.5.3, not tested at the time) works in real sessions: the host's game (23 to 29 MB of differences at each reload) was sent over 4 Steam connections in 3 to 18 s.

Known issues

• Many bus stops placed or removed in a pause, then vehicles bought: the games can still give the new vehicles different ids, and reload a few minutes later. Replaying a bus stop does not always create exactly what the stop tool created. This is the next fix we are working on.
• Disabling MPFever while still in a lobby, then loading a savegame, still blocks building: leave the lobby first.

0.5.3

Towns stay in sync, games run much faster, join through Steam without opening a port, and a short connection drop no longer reloads everybody.

New

• Join through Steam, with no port to open. The host's game now listens on Steam (Steam's own peer-to-peer connections and its relays). An invitation, or « Join game » in the Steam friends list, gives the host's Steam account first and its addresses as before. MPFever tries both at once and keeps a direct connection when there is one. Through Steam, the host's game is sent over several Steam connections at once: about 6 MB/s in our test on one PC (a 35 MB game in 5 s, over 4 Steam connections). Through Steam's relays, expect less: about 1 MB/s per connection, so about 4 MB/s.
• A short connection drop no longer reloads the game. When a player's connection drops for a moment (Wi-Fi, a router), the host waits for them up to 60 s: every game stops where that player stopped, and the others see « lost the connection: the game waits for them ». Back in time, the player gets everything they missed and the game goes on, with no reload. A player who leaves on purpose is not waited for.

Fixes

• Towns no longer drift apart next to the streets and tracks players build. This was the main cause of « script:towns » differences and of the reloads that followed. Every street and track segment carries an age that the towns compare when they place houses. The street tool used to set it differently on the builder's game and on the others. In two savegames of the same session, taken during the same pause, 275 segments out of 1380 had another age. Every segment now gets the same age on every game, and the checks compare these ages, so any difference shows right at the build.
• A build that made one more object on one game is caught at once. The checks now compare the ids every build gives its new streets and nodes. In a session on 2026-10-25, one game made one more object at a build, and it showed only 4 minutes later, in the vehicles. Now the games are reloaded right away, before towns and vehicles go apart.
• Towns' street building: a small difference between two games no longer becomes a lasting one (the towns' street field is computed exactly for each point).
• Saving no longer changes the world of the game that saves. The games of a session save at different moments (autosaves, a player saving by hand).
• Signals on track bridges and in tunnels (issue #85) are replayed exactly as the signal tool built them. This removes the « TOWN STATS DIFFER » message and the reload after each one.
• The Mod Hub broken, or the game closing when it opened, on some PCs (issue #83), even after MPFever was removed. MPFever's winhttp.dll passed on only the network functions the game itself uses. Windows uses the same file to check HTTPS certificates, and those checks failed. Every network function is now passed on (reproduced and checked).

Faster

• The simulation ran slower and slower during a session. It kept the last 50 builds in full in its state (about 4.6 MB after two hours, and every game inherited it at a reload), and it read that state several times per step. Measured on the savegame of a 2-hour session, at x4 with two games on one PC: the simulation went from x1.4 to x3.7, and the frame rate from 31 to 65 fps for the player.
• The files MPFever and the game exchange several times a second stay open. Each open of a file another program had just written waited about 9 ms for the antivirus.

Checked

• Desyncs: new roads and upgrades built by both games, while the game ran and while it was paused, all in sync. The segments' ages were identical on both games (1184 of 1184).
• A real session replayed: a real session from the host's own autosave, with its 36 actions, then 6 minutes at x4: in sync. Another session from its start, with 218 of its actions replayed at x4: in sync, both games alike. A host saving alone, three times, for 9 minutes at x4: in sync.
• Connection drops: roads, upgrades and 5 minutes at x4, with the player's connection cut every 30 s. 8 returns, no reload, in sync.
• Steam, without a real friend: a player joining through Steam's own connections on one PC, builds, then the host's whole game sent through them: in sync. A real Steam peer-to-peer connection of the game to its own account: 64 MB sent and received intact.

Not tested yet: joining through Steam between two different Steam accounts on two PCs. If you try it, please report what you see.

0.5.2

A fix for savegames that crashed the game at every load.

Fix

• A savegame that crashed at every load (issue #84). A savegame made during a session could keep a player's action that was never applied before the save. MPFever applied it as the world loaded, and a vehicle it sold crashed the game (« it != components.end() »), on every player's game, at every load. Such old actions are now dropped when a savegame loads, the same way on every game. The savegame of issue #84 loads and plays normally again, without anything else to do.

For developers

• build.bat runs every test that needs no game before it makes the archives, and GitHub runs them for every push and pull request. A compiler warning stops the build.

Checked

• The savegame of issue #84 on two games: with 0.5.1, both games crash at the load (the same entity as in the report); with 0.5.2, both drop the old action, and the world plays in sync.

Thanks to torwi91-lab (Kex) for the report and the savegame!

0.5.1

A new MPFever window, companies grow up, savegames travel light, and a big round of desync fixes. MPFever has an icon in the game's bottom bar and a window with tabs, several players can share a company, companies can go bankrupt and be auctioned, tracks, stations and depots are open to the others by default (or private, or tolled), and a resynchronisation now sends only what changed in the savegame. This version also fixes the problems found in the long sessions of kingplay98 and theop.

Full notes

0.4.5

Town streets that stay in sync, speed x2 and x3 back, faster joins. This version fixes the resyncs that came after upgrading streets in towns and placing bus stops, found thanks to your reports and savegames.

Full notes

0.4.4

« One company per player » is no longer experimental. Every company now has its own Company window, colour, money gifts and a place in the ranking.

Full notes

0.4.3

Roads that replace existing road segments are now rebuilt exactly the same on every game.

Full notes

0.4.1

Support for game build 40423. On that build, MPFever 0.4.0 lost its synchronisation fixes and the games kept drifting apart.

Full notes

Older versions

See the releases page and the full CHANGELOG.