Friday Facts #242 - Offensive programming

[Admiralkio]

I don't deal with anything nearly as complicated as Factorio, but i feel this fits.

[Avezo]

So I downgraded to stable version... My blueprints are now gone...

[Aardwolf]

> The reason for this is, that the walls connect to each other, and since there would be 2 walls at the same place, in multiplayer it could happen that the neighbour wall piece could connect to different walls for different players

Would a different solution be to make that deterministic? Always connect same wall for all players. Based on its id in the map, or direction or other thing that should be same for everyone. Now it sounds as if a random generator is used for connecting walls if so: use same seed for everyone.

[kovarex]

> The reason for this is, that the walls connect to each other, and since there would be 2 walls at the same place, in multiplayer it could happen that the neighbour wall piece could connect to different walls for different players

Would a different solution be to make that deterministic? Always connect same wall for all players. Based on its id in the map, or direction or other thing that should be same for everyone. Now it sounds as if a random generator is used for connecting walls if so: use same seed for everyone.

This is a good point, I didn't want to go into too big details in the fff, but I can explain it here.

If you load the same save file by two players, the walls will always connect the same way even if they are two walls on the same spot, <b>this is deterministic</b>. The reason is, that the entities are registered on the map in the same order, so they will be found in the same order.

The problem is, when you start a multiplayer game with one wall on the place, then while playing, you add another on the same spot the new wall will not reconnect as the neighbour is already connected.
After that, second player joins the game and suddenly, the wall can connect to the newly build instead of to the one that was there when the host loaded the game.

I'm aware, that this could be also solved by having different invariant that would say: "Walls are always connected to the first registered neighbour on the tile." But keeping this invariant would mean, that adding a wall somewhere or removing a wall, or moving a wall, would require to check, whether the neighbours shouldn't reconnect to something with higher priority. I'm not saying it is impossible, it would be just a different approach.

[AlastarFrost]

I don't know if this is helpful, but to me this sounds like a problem you could elegantly solve with layers.

Imagine the entities in the game belonging to a layer.
You start from a conflict-free state where there is only one layer that holds all the entities.

If I now add a blueprint, it would add a new layer on top of the existing one, and this layer would exist until all the conflicts are resolved and the layer can be merged down.
You could have a rock blocking the blueprint entity and you could solve that by either removing parts of the blueprint or deconstruct the rock. As long as both are queued actions the layers stay separate.
This means the whole large blueprint would stay as a separate layer until the last obstructing rock or old piece of equipment is removed. Connections would only be made inside the layer, so it would not connect to the rest of the factory until it is completely built. You could even abort the placement of the blueprint at any point until it is complete and roll it back, as you still have all components of the blueprint in one layer waiting for the merge.

This approach is like a transaction, where the construction of the blueprint is treated as one atomic action that ends in the start-up at the end of construction. This is pretty much how you would finish a planned factory before powering up parts of it. You could still optimize this to allow a partial startup if you detect that a part of the blueprint is complete, but that would be the sugar-coating(this would mostly be useful for solar arrays and accumulators, other partially finished blueprints tend to not do anything useful until they are complete anyways).

I think many of the problems you face stem from the fact that you break down the big picture of something like a blueprint into separate components too early in the process. You would know what is meant to connect if you kept the blueprint around a little longer. At least it seems like that to me, not knowing the details of your code. Even if you just did that in the background, it would help your cleanup algorithms by giving them some context how this mess was created. And finally, you could look at those stacked layers when debugging and it could help you figure out the order of operations that led to an invalid state. In a system like that, a inconsistent state would always mean that there is a merge conflict between layers.

[Philip017]

regarding the consistency check, i have noticed that there are times my game loads the save bar to full, but then takes forever to actually load into the game, with no indication as to what is happening, my guess here is that the game is doing a consistency check, it would be really nice if i knew that was happening, perhaps a loading/progress bar that would give me an idea of how much longer i have to wait for it to finish, and some text to let me know it's checking this. i believe that in most cases the consistency check is not needed, and perhaps it could be checked optionally should a save file fail to load. with it checking each version transition, as each time a mod is updated, or changed while being developed, another consistency check is done with the agonizingly long loading time. my two cents as a long time player. thanks again for creating this wonderful game.

If people could give me saves that reproduce that long wait time I can look into adding a progress bar to the logic.

I don't want to just add progress bars in without first knowing what part is taking the time up as every additional thing adds complexity and possible bugs

Take any decent sized save that uses some mods, and disable one of the mods that would result in entity removal from the map. Then load the save. You should see a considerably longer (order of magnitude in my experience) wait during the load.

this is a great example, but it also happens when you change something(s) in a mod, for example i am not happy with a change in one of the mods that recently updated, i roll back to the previous version and essentially doubling+ the load times while the second load time is after the loading bar is full and all i can do is wait wondering if the bar got broken?

for a popular example, i downloaded the lillyrose map from https://www.reddit.com/r/factorio/comme ... lockbased/ (the youtube page has a limited time downloading the map, i downloaded the 100 rockets map, for which i drew some inspiration on my next creation) download the map, dont have any mods installed, (as the map file has text plates mod installed) tested on 16.42 and the loading bar gets stuck each time i load the map, if i save the map with no mods, the next load time will Sometimes, load fast other times get stuck, if this is a thing worthy of a bug report i will happily put one in.

[thereaverofdarkness]

I don't know if this is helpful, but to me this sounds like a problem you could elegantly solve with layers.

I feel like the end user could solve it by not stacking walls on top of each other. As long as the base game disallows it in such a way that no properly functioning mod will let it happen, we can just consider all cases of wall stacking to be bugs, yes?

But if you want to fix this even better, Kovarex, then you're God status programmer.

[bobingabout]

I don't deal with anything nearly as complicated as Factorio, but i feel this fits.

I believe both Startrek DS9 and Voyager had an episode involving that.

[dasiro]

WHERE'S FFF243 did you guys missed it for the first time?

[Proxy]

welp the devs have died, building burn down or something else.

it is 00:55 on saturday and no FFF

[thereaverofdarkness]

Fun Friday Facts is up just in time!
https://www.factorio.com/blog/post/fff-243

[cmdrsweeper]

Weeeelll I got a new one for you.
When I type the command I get a nice error that would be pointing to the fact that the consistency check command.... DOESN'T EXIST!
Any way we can toggle an override for these crashes and just force it to run? It has been running fine for the past few versions before this enforced weirdness, or will I have to look for an older version of the game before you broke it to just keep on playing?