▶
Friday Facts #299 - Everything is more complex than expected
The rail signal logic for automated trains is quite straightforward: As a train moves forward, it tries to reserve signals in front of it. If it can reserve a signal, the whole block guarded by the signal gets reserved for the train. If the train can't reserve the signal, as the block is reserved or occupied by different train(s), it stops in front of the signal and waits. Once the train passes a signal and enters a new block, it removes the reservation on the signal and block it had reserved. Once it exits the block, the block can be reserved and entered by other trains. This looks nice and simple, nothing fundamentally wrong could happen with this logic right? Especially since we have it there for almost five years and it all just works right? If the answer to this was "Yes", it would be quite a stupid buildup, so the answer is "No" :).
So in this example, the train is approaching from the right. The problem is, that it reserves the block number 2 twice since there is a special rule, that a train can enter a reserved or occupied block as long as it is reserved by itself.
Since the train reserved the block 2 twice but removed both of the block reservations by entering it, the second reservation, which the train still counts on, isn't applied on the block 2, and the block is basically open for any other train to enter. This can lead to collisions and surprisingly also desyncs since we don't save block reservations, but deduce them from signal reservations while the game is being loaded.
Once the problem was identified, the solution was quite straightforward. I added support for block to be reserved multiple times, removing the reservation decreases the counter, and the block is freed only if all the reservations are removed. But the real bugs and problems started after, because we now need to be extra sure that the block is reserved exactly the same amount of times as it is unreserved. The logic around this was far from rigid before as it just wasn't needed. Quite a few strict checks were added all over the place, to make sure that an internally incompatible state doesn't appear, since we don't really want to have to fix these "this block is closed forever" bugs where it would be close to impossible figure out how the game got into that state. P.S. Since we can now use train stops as waypoints, not only blocks, but rail signals can be reserved more than once as well, as a train can plan path in a circle and reserve the same signal twice along the path.
You can see how the internal changes of rails bumped our crash report counts, but it will hopefully go back to normal soon.
Well, you can't make an omelette without breaking some eggs... but overall the trend continues toward stability. As always, let us know what you think on our forum.
[ 2019-06-14 14:09:10 CET ] [ Original post ]
You might have noticed that a lot of rail related stuff was broken during these past releases, and now it is working more or less fine again. The story behind is is not so trivial.
Rail signal logic
The rail signal logic for automated trains is quite straightforward: As a train moves forward, it tries to reserve signals in front of it. If it can reserve a signal, the whole block guarded by the signal gets reserved for the train. If the train can't reserve the signal, as the block is reserved or occupied by different train(s), it stops in front of the signal and waits. Once the train passes a signal and enters a new block, it removes the reservation on the signal and block it had reserved. Once it exits the block, the block can be reserved and entered by other trains. This looks nice and simple, nothing fundamentally wrong could happen with this logic right? Especially since we have it there for almost five years and it all just works right? If the answer to this was "Yes", it would be quite a stupid buildup, so the answer is "No" :).
The counter example
So in this example, the train is approaching from the right. The problem is, that it reserves the block number 2 twice since there is a special rule, that a train can enter a reserved or occupied block as long as it is reserved by itself.
Since the train reserved the block 2 twice but removed both of the block reservations by entering it, the second reservation, which the train still counts on, isn't applied on the block 2, and the block is basically open for any other train to enter. This can lead to collisions and surprisingly also desyncs since we don't save block reservations, but deduce them from signal reservations while the game is being loaded.
The solution
Once the problem was identified, the solution was quite straightforward. I added support for block to be reserved multiple times, removing the reservation decreases the counter, and the block is freed only if all the reservations are removed. But the real bugs and problems started after, because we now need to be extra sure that the block is reserved exactly the same amount of times as it is unreserved. The logic around this was far from rigid before as it just wasn't needed. Quite a few strict checks were added all over the place, to make sure that an internally incompatible state doesn't appear, since we don't really want to have to fix these "this block is closed forever" bugs where it would be close to impossible figure out how the game got into that state. P.S. Since we can now use train stops as waypoints, not only blocks, but rail signals can be reserved more than once as well, as a train can plan path in a circle and reserve the same signal twice along the path.
The effect
You can see how the internal changes of rails bumped our crash report counts, but it will hopefully go back to normal soon.
Well, you can't make an omelette without breaking some eggs... but overall the trend continues toward stability. As always, let us know what you think on our forum.
[ 2019-06-14 14:09:10 CET ] [ Original post ]
Factorio
Wube Software LTD.
Developer
Wube Software LTD.
Publisher
2020-08-14
Release
Game News Posts:
506
🎹🖱️Keyboard + Mouse
Overwhelmingly Positive
(164072 reviews)
The Game includes VR Support
Public Linux Depots:
- Factorio Linux64 [306.86 M]
- Factorio Linux32 [300.1 M]
Available DLCs:
- Factorio: Space Age
Factorio is a game in which you build and maintain factories. You will be mining resources, researching technologies, building infrastructure, automating production and fighting enemies. In the beginning you will find yourself chopping trees, mining ores and crafting mechanical arms and transport belts by hand, but in short time you can become an industrial powerhouse, with huge solar fields, oil refining and cracking, manufacture and deployment of construction and logistic robots, all for your resource needs. However this heavy exploitation of the planet's resources does not sit nicely with the locals, so you will have to be prepared to defend yourself and your machine empire.
Join forces with other players in cooperative Multiplayer, create huge factories, collaborate and delegate tasks between you and your friends. Add mods to increase your enjoyment, from small tweak and helper mods to complete game overhauls, Factorio's ground-up Modding support has allowed content creators from around the world to design interesting and innovative features. While the core gameplay is in the form of the freeplay scenario, there are a range of interesting challenges in the form of the Scenario pack, available as free DLC. If you don't find any maps or scenarios you enjoy, you can create your own with the in-game Map Editor, place down entities, enemies, and terrain in any way you like, and even add your own custom script to make for interesting gameplay.
Discount Disclaimer: We don't have any plans to take part in a sale or to reduce the price for the foreseeable future.
Join forces with other players in cooperative Multiplayer, create huge factories, collaborate and delegate tasks between you and your friends. Add mods to increase your enjoyment, from small tweak and helper mods to complete game overhauls, Factorio's ground-up Modding support has allowed content creators from around the world to design interesting and innovative features. While the core gameplay is in the form of the freeplay scenario, there are a range of interesting challenges in the form of the Scenario pack, available as free DLC. If you don't find any maps or scenarios you enjoy, you can create your own with the in-game Map Editor, place down entities, enemies, and terrain in any way you like, and even add your own custom script to make for interesting gameplay.
Discount Disclaimer: We don't have any plans to take part in a sale or to reduce the price for the foreseeable future.
What people say about Factorio
- No other game in the history of gaming handles the logistics side of management simulator so perfectly. - Reddit
- I see conveyor belts when I close my eyes. I may have been binging Factorio lately. - Notch, Mojang
- Factorio is a super duper awesome game where we use conveyor belts to shoot aliens. - Zisteau, Youtube
MINIMAL SETUP
- OS: Linux (tarball installation)
- Processor: Dual core 3Ghz+Memory: 4 GB RAM
- Memory: 4 GB RAM
- Graphics: OpenGL 3.3 core. DirectX 10.1 capable GPU with 512 MB VRAM - GeForce GTX 260. Radeon HD 4850 or Intel HD Graphics 5500
- Storage: 3 GB available space
- OS: Linux (tarball installation)
- Processor: Quad core 3GHz+Memory: 8 GB RAM
- Memory: 8 GB RAM
- Graphics: OpenGL 4.3 core. DirectX 11 capable GPU with 2 GB VRAM - GeForce GTX 750 Ti. Radeon R7 360
- Storage: 3 GB available space
GAMEBILLET
[ 6102 ]
GAMERSGATE
[ 764 ]
FANATICAL BUNDLES
HUMBLE BUNDLES
by buying games/dlcs from affiliate links you are supporting tuxDB