Friday Facts #242 - Offensive programming

Regular reports on Factorio development.

Re: Friday Facts #242 - Offensive programming

Postby Admiralkio » Sat May 12, 2018 5:48 pm

Image

I don't deal with anything nearly as complicated as Factorio, but i feel this fits.
Admiralkio
Burner Inserter
Burner Inserter
 
Posts: 5
Joined: Sun Aug 03, 2014 4:30 am

Re: Friday Facts #242 - Offensive programming

Postby Avezo » Sat May 12, 2018 6:16 pm

So I downgraded to stable version... My blueprints are now gone...
Image
Avezo
Filter Inserter
Filter Inserter
 
Posts: 313
Joined: Fri Apr 01, 2016 3:53 pm

Re: Friday Facts #242 - Offensive programming

Postby Aardwolf » Sun May 13, 2018 8:28 am

> 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.
Aardwolf
Long Handed Inserter
Long Handed Inserter
 
Posts: 61
Joined: Tue Feb 03, 2015 2:05 pm

Re: Friday Facts #242 - Offensive programming

Postby kovarex » Sun May 13, 2018 9:55 am

Aardwolf wrote:> 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.
kovarex
Factorio Staff
Factorio Staff
 
Posts: 6657
Joined: Wed Feb 06, 2013 12:00 am
Location: Prague

Re: Friday Facts #242 - Offensive programming

Postby AlastarFrost » Sun May 13, 2018 11:04 am

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.
AlastarFrost
Burner Inserter
Burner Inserter
 
Posts: 10
Joined: Sun Jun 12, 2016 3:12 pm

Re: Friday Facts #242 - Offensive programming

Postby Philip017 » Sun May 13, 2018 11:56 am

malventano wrote:
Rseding91 wrote:
Philip017 wrote: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.
User avatar
Philip017
Fast Inserter
Fast Inserter
 
Posts: 191
Joined: Thu Sep 01, 2016 11:21 pm

Re: Friday Facts #242 - Offensive programming

Postby thereaverofdarkness » Mon May 14, 2018 5:15 pm

AlastarFrost wrote: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.
User avatar
thereaverofdarkness
Filter Inserter
Filter Inserter
 
Posts: 501
Joined: Wed Jun 01, 2016 5:07 am

Re: Friday Facts #242 - Offensive programming

Postby bobingabout » Tue May 15, 2018 7:50 am

Admiralkio wrote:Image

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.
No matter what you do, you can't please everyone.
User avatar
bobingabout
Smart Inserter
Smart Inserter
 
Posts: 5688
Joined: Fri May 09, 2014 1:01 pm
Location: England

Re: Friday Facts #242 - Offensive programming

Postby dasiro » Fri May 18, 2018 10:13 pm

WHERE'S FFF243 :o did you guys missed it for the first time? :(
dasiro
Long Handed Inserter
Long Handed Inserter
 
Posts: 85
Joined: Fri Jun 03, 2016 5:55 pm

Re: Friday Facts #242 - Offensive programming

Postby Proxy » Fri May 18, 2018 10:53 pm

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

it is 00:55 on saturday and no FFF
Let's just wait til the Age of Iron Stars
User avatar
Proxy
Fast Inserter
Fast Inserter
 
Posts: 157
Joined: Mon Mar 30, 2015 11:10 am
Location: Germany

Re: Friday Facts #242 - Offensive programming

Postby thereaverofdarkness » Fri May 18, 2018 11:56 pm

Fun Friday Facts is up just in time!
https://www.factorio.com/blog/post/fff-243
User avatar
thereaverofdarkness
Filter Inserter
Filter Inserter
 
Posts: 501
Joined: Wed Jun 01, 2016 5:07 am

Re: Friday Facts #242 - Offensive programming

Postby cmdrsweeper » Sat May 19, 2018 12:33 am

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?
cmdrsweeper
Manual Inserter
Manual Inserter
 
Posts: 2
Joined: Sat May 19, 2018 12:28 am

Previous

Return to News

Who is online

Users browsing this forum: TQelektronik and 12 guests