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