Factorio - HanziQ
  • Changes
    • Server started with --start-server-load-scenario will now save to saves/<scenario name> upon exit.
    • Multiplayer usernames can only consist of letters, numbers and -_. characters.

  • Bugfixes
    • Possible fix for a server not responding error.

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.
Factorio - HanziQ
  • Changes
    • Server started with --start-server-load-scenario will now save to saves/<scenario name> upon exit.
    • Multiplayer usernames can only consist of letters, numbers and -_. characters.

  • Bugfixes
    • Possible fix for a server not responding error.

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.
Factorio - HanziQ
  • Changes
    • Disabled multiplayer support in the 32 bit version of the game.
    • Multiplayer map downloading GUI shows average over the last 2 seconds instead of 20 seconds.

  • Bugfixes
    • Potential fix of the crash after desync.
    • Fixed desync related to electric network statistics of accumulators.
    • Fixed assertion fail in tightspot level-05 more
    • Removed 2 redundant research prerequisites. more
    • Fixed non even selection boxes of locomotive versus cargo wagon. more
    • Fixed that Factorio would crash when unable to delete a mod. more
    • Fixed that the chart would display user's names from other surfaces. more
    • Fixed blueprint tiles alignment inside preview/editor. more
    • Fixed player limit disallowing connection attempt in public server list. more
    • Fixed mod browser filters and ordering being lost. more
    • Fixed freshly installed mods not being marked in the mod browser. more
    • Fixed signals sometimes not finding their child signals properly. more
    • Fixed up/down keys in schedule gui were not selecting properly. more
    • Additional keys ignored when the console is opened. more
    • Fixed that aliens would ignore very narrow paths they could barely fit through. more
    • Fixed that numbers were sometimes rounded differently on 32 bit systems in lua.
    • Fixed that the game would freeze when game.speed was set to a value less than 0.2. more
    • Fixed cargo wagon air resistance being smaller than that of the locomotive.
    • Fixed of loading "require_user_verification" from server-settings (It was called verify_user_identity at one place and require_user_verification at other).
    • Fixed underground belt fast replace when replacing the same belt multiple times. more
    • Fixed rendering of turret range when construction network area overlay is also being drawn. more
    • Temporary decrease of decorative entities counts.
    • Fixed server max upload speed.
    • Fixed that Factorio wouldn't give an error when --start-server-load-scenario was combined with --start-server or --start-server-load-latest. more
    • Fixed beam would apply one extra damage tick. more

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.
Factorio - HanziQ
  • Changes
    • Disabled multiplayer support in the 32 bit version of the game.
    • Multiplayer map downloading GUI shows average over the last 2 seconds instead of 20 seconds.

  • Bugfixes
    • Potential fix of the crash after desync.
    • Fixed desync related to electric network statistics of accumulators.
    • Fixed assertion fail in tightspot level-05 more
    • Removed 2 redundant research prerequisites. more
    • Fixed non even selection boxes of locomotive versus cargo wagon. more
    • Fixed that Factorio would crash when unable to delete a mod. more
    • Fixed that the chart would display user's names from other surfaces. more
    • Fixed blueprint tiles alignment inside preview/editor. more
    • Fixed player limit disallowing connection attempt in public server list. more
    • Fixed mod browser filters and ordering being lost. more
    • Fixed freshly installed mods not being marked in the mod browser. more
    • Fixed signals sometimes not finding their child signals properly. more
    • Fixed up/down keys in schedule gui were not selecting properly. more
    • Additional keys ignored when the console is opened. more
    • Fixed that aliens would ignore very narrow paths they could barely fit through. more
    • Fixed that numbers were sometimes rounded differently on 32 bit systems in lua.
    • Fixed that the game would freeze when game.speed was set to a value less than 0.2. more
    • Fixed cargo wagon air resistance being smaller than that of the locomotive.
    • Fixed of loading "require_user_verification" from server-settings (It was called verify_user_identity at one place and require_user_verification at other).
    • Fixed underground belt fast replace when replacing the same belt multiple times. more
    • Fixed rendering of turret range when construction network area overlay is also being drawn. more
    • Temporary decrease of decorative entities counts.
    • Fixed server max upload speed.
    • Fixed that Factorio wouldn't give an error when --start-server-load-scenario was combined with --start-server or --start-server-load-latest. more
    • Fixed beam would apply one extra damage tick. more

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.
Factorio - Klonan
Hello,
we have written a lot about multiplayer in the past weeks, it started by the reports at the beginning of the rewrite, and now it finishes with our reports of mega games being played. But as most of our time still goes to bug hunting to achieve 0.14 stable as soon as possible, I just can't help myself:

You don't want me to bother you with multiplayer, but I will do it anyway
As we watched the stream of big multiplayer we mentioned in the last fff, we decided to participate and help organize another big multiplayer event. Even though the server provider we rented from for the event was DDoS'd at that time, it was still a success. During the event, we did profiling as the game was running, and we learned a lot of valuable information.



The Factorio internals always have to be programmed with knowledge of quantities. Transport belts need to be optimised a lot, as there are tons of those on the map and they eat a lot of the CPU time. On the other hand, the time to simulate the players was never really a problem, since there were always at most a few players on the map at the same time. This paradigm was changed a lot when we profiled a replay with 300 players and found out that big part of the CPU time is spent on things like searching for gates to be opened or searching for items to be looted etc. These things are not hard to optimise, but we just didn't know we should do it until now, so it is work in progress.

Several other needs emerged, like changing the server settings (password/max upload rate/max players) on the fly as the game is played. Postponement of the map saving for incoming players, so the server saves once in a while for more people at the same time, instead of saving every 3 seconds when someone wants to join a crowded game. The admin options also had to be improved etc. etc.
Then it comes to further and further optimisations of the network traffic so more and more people can play at the same time. The problem with this is, that we could do it forever, we wanted 20 or at most 50 players to be able to play in the new multiplayer, but we reached 350 and now we are optimising it so more than 400 could join, and if we achieved that, we would go for 1000. But are we still doing something that improves the gameplay, or just trying to win the race with ourselves at this point? We need to realize that our goal is not to make some MMO, but to have a good single player game, that also have a decent multiplayer. So the conclusion is, that if the game supports 200 players with a good connection it is more than enough. It can go higher but we won't aim to increase it much anymore.
After hour or two, the main bottleneck is not the players or the network traffic. The factory grows at a cosmic speed in these megagames, so the CPU time needed to simulate it becomes the problem. By changing our focus to general factory simulation optimisations, we not only make it possible to play massive multiplayer games better, but we also allow to build much bigger bases in singleplayer as well. The belts optimisations and multithreading are worked on, but far from being finished.

Everything is more complicated than expected, even the pump
As we have been asked many times, I probably need to answer again: Yes, we will add the liquid wagons in 0.15, but it won't be that simple. As we want to have the pump and wagon connection to be organic, we need the pump to connect to the wagon. But as the geometry of our trains is wicked the connection points on the wagon won't be regular in vertical directions. We are making a 2d game so we have to prepare 6 different animations for every relative position of the pump. Albert had doubts if it is worth it as we always have to try to keep our video memory bill reasonable, but I believe it will add a nice touch to the game.




The problem with decoratives
One of the 0.13 changes was change of the map generation. As part of it, it happened that the game is suddenly generating a lot of more of the decorative entities. It often looks like this:

It looks nicer, but the problem is that there could be tens of millions of these on big maps, which can multiply the size of the save and ram required to hold it.There is even a mod that removes them completely to solve the issue. We were discussing solutions of this, and we will probably just change decoratives so they are not regular entities anymore. They would be a special type of an object that is not saved in the map, but generated on the fly when the player walks around. They would be saved per chunk in a very compressed format so it only takes 3 bytes of memory per decorative instead of approximately 300 bytes when it exists as an entity. This will also improve performance, as when some code is checking entities in some perimeter, it wouldn't have to iterate through tons of these decoratives uselessly. As these changes are too big to be added into the 0.14, we will probably just reduce decorative generation in 0.14 and do this change for 0.15.

As always, if you have any comments or otherwise, please let us know on our forums.
Factorio - Klonan
Hello,
we have written a lot about multiplayer in the past weeks, it started by the reports at the beginning of the rewrite, and now it finishes with our reports of mega games being played. But as most of our time still goes to bug hunting to achieve 0.14 stable as soon as possible, I just can't help myself:

You don't want me to bother you with multiplayer, but I will do it anyway
As we watched the stream of big multiplayer we mentioned in the last fff, we decided to participate and help organize another big multiplayer event. Even though the server provider we rented from for the event was DDoS'd at that time, it was still a success. During the event, we did profiling as the game was running, and we learned a lot of valuable information.



The Factorio internals always have to be programmed with knowledge of quantities. Transport belts need to be optimised a lot, as there are tons of those on the map and they eat a lot of the CPU time. On the other hand, the time to simulate the players was never really a problem, since there were always at most a few players on the map at the same time. This paradigm was changed a lot when we profiled a replay with 300 players and found out that big part of the CPU time is spent on things like searching for gates to be opened or searching for items to be looted etc. These things are not hard to optimise, but we just didn't know we should do it until now, so it is work in progress.

Several other needs emerged, like changing the server settings (password/max upload rate/max players) on the fly as the game is played. Postponement of the map saving for incoming players, so the server saves once in a while for more people at the same time, instead of saving every 3 seconds when someone wants to join a crowded game. The admin options also had to be improved etc. etc.
Then it comes to further and further optimisations of the network traffic so more and more people can play at the same time. The problem with this is, that we could do it forever, we wanted 20 or at most 50 players to be able to play in the new multiplayer, but we reached 350 and now we are optimising it so more than 400 could join, and if we achieved that, we would go for 1000. But are we still doing something that improves the gameplay, or just trying to win the race with ourselves at this point? We need to realize that our goal is not to make some MMO, but to have a good single player game, that also have a decent multiplayer. So the conclusion is, that if the game supports 200 players with a good connection it is more than enough. It can go higher but we won't aim to increase it much anymore.
After hour or two, the main bottleneck is not the players or the network traffic. The factory grows at a cosmic speed in these megagames, so the CPU time needed to simulate it becomes the problem. By changing our focus to general factory simulation optimisations, we not only make it possible to play massive multiplayer games better, but we also allow to build much bigger bases in singleplayer as well. The belts optimisations and multithreading are worked on, but far from being finished.

Everything is more complicated than expected, even the pump
As we have been asked many times, I probably need to answer again: Yes, we will add the liquid wagons in 0.15, but it won't be that simple. As we want to have the pump and wagon connection to be organic, we need the pump to connect to the wagon. But as the geometry of our trains is wicked the connection points on the wagon won't be regular in vertical directions. We are making a 2d game so we have to prepare 6 different animations for every relative position of the pump. Albert had doubts if it is worth it as we always have to try to keep our video memory bill reasonable, but I believe it will add a nice touch to the game.




The problem with decoratives
One of the 0.13 changes was change of the map generation. As part of it, it happened that the game is suddenly generating a lot of more of the decorative entities. It often looks like this:

It looks nicer, but the problem is that there could be tens of millions of these on big maps, which can multiply the size of the save and ram required to hold it.There is even a mod that removes them completely to solve the issue. We were discussing solutions of this, and we will probably just change decoratives so they are not regular entities anymore. They would be a special type of an object that is not saved in the map, but generated on the fly when the player walks around. They would be saved per chunk in a very compressed format so it only takes 3 bytes of memory per decorative instead of approximately 300 bytes when it exists as an entity. This will also improve performance, as when some code is checking entities in some perimeter, it wouldn't have to iterate through tons of these decoratives uselessly. As these changes are too big to be added into the 0.14, we will probably just reduce decorative generation in 0.14 and do this change for 0.15.

As always, if you have any comments or otherwise, please let us know on our forums.
Factorio - HanziQ
  • Changes
    • Added admin field to server-settings.json, list of case-sensitive usernames that will become admins on connecting.
    • Admins are exempt from player count limit.

  • Bugfixes
    • Fixed that the server could be running even if it was supposed to be stopped.
    • Fixed Modded key bindings would fire extra times if 2 mods had the same keybinding. more
    • Fixed that parsing players by index in scripts didn't work correctly. more
    • Fixed that Factorio wouldn't release memory back to the OS after unloading a large save on Linux. more
    • Fixed crash when restarting Factorio due to mod change when executable is read-only on Linux. more
    • Game will no longer be capped at 300UPS when using high game.speed and vsync. New cap is FPS*5*game.speed. more
    • Fixed possible crashes when setting combinator parameters.
    • Fixed that clients could send a lot of useless data when recovering after connectiontion problems while playing multiplayer game.
    • Fixed that recipe overload_multiplier wasn't used for furnaces. more

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.
Factorio - HanziQ
  • Changes
    • Added admin field to server-settings.json, list of case-sensitive usernames that will become admins on connecting.
    • Admins are exempt from player count limit.

  • Bugfixes
    • Fixed that the server could be running even if it was supposed to be stopped.
    • Fixed Modded key bindings would fire extra times if 2 mods had the same keybinding. more
    • Fixed that parsing players by index in scripts didn't work correctly. more
    • Fixed that Factorio wouldn't release memory back to the OS after unloading a large save on Linux. more
    • Fixed crash when restarting Factorio due to mod change when executable is read-only on Linux. more
    • Game will no longer be capped at 300UPS when using high game.speed and vsync. New cap is FPS*5*game.speed. more
    • Fixed possible crashes when setting combinator parameters.
    • Fixed that clients could send a lot of useless data when recovering after connectiontion problems while playing multiplayer game.
    • Fixed that recipe overload_multiplier wasn't used for furnaces. more

You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.
Factorio - HanziQ
On September 22, starting at 7:00 am UTC (9:00 am CEST, 12:00 am PDT, 3:00 am EDT, http://everytimezone.com/#2016-9-21,1140,cn3), lasting approximately 30-60 minutes, we will be conducting a database maintenance, resulting in the outage of the following services:

  • Main website - factorio.com
  • Authentication services
  • Mod portal
  • Public server browser
  • Standalone game updater

The following services will not be affected:
  • Factorio Forums
  • Factorio Wiki

Thank you for understanding
Factorio - HanziQ
On September 22, starting at 7:00 am UTC (9:00 am CEST, 12:00 am PDT, 3:00 am EDT, http://everytimezone.com/#2016-9-21,1140,cn3), lasting approximately 30-60 minutes, we will be conducting a database maintenance, resulting in the outage of the following services:

  • Main website - factorio.com
  • Authentication services
  • Mod portal
  • Public server browser
  • Standalone game updater

The following services will not be affected:
  • Factorio Forums
  • Factorio Wiki

Thank you for understanding
...