Friday Facts #415 - Fix, Improve, Optimize

Regular reports on Factorio development.
Tekky
Smart Inserter
Smart Inserter
Posts: 1040
Joined: Sun Jul 31, 2016 10:53 am
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by Tekky »

This was a very interesting read.

What makes Factorio great is not only the big things, but also the sum of all of the little things.

I am unaware of any game which is as polished as Factorio.

User avatar
mrudat
Fast Inserter
Fast Inserter
Posts: 248
Joined: Fri Feb 16, 2018 5:21 am
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by mrudat »

Zavian wrote: ↑
Fri Jun 14, 2024 6:14 pm
mrudat wrote: ↑
Fri Jun 14, 2024 1:27 pm
For huge saves, it would be nifty if the delta from the last save could be sent instead of having to download the entire save, given that we know the last time any given player was last connected; perhaps a utility that builds and maintains a set of delta files between saves allowing any player to download a set of deltas to bring their local save up-to-date hopefully using only a fraction of the required bandwidth.
The delta between 2 saves is likely to be huge, even if the player was last connected 5 minutes ago. Every working assembler will be at a different fraction of it next item completed, and have a different internal inventory of items, every inserter will be at a different point it its swing and might have different hand items. All of the items on every belt are likely to have moved. (In general, the only time the generated delta would small, is if you only send the player orders, and the client had to play catch up. That might work for the case of a client that last connected 5 minutes ago, but could take hours for a client that was last connected 8 hours ago).

Differential or delta saves work well where 90+% of the data is static data that does not change between saves, but that isn't the case with Factorio.
From what I've read about saves, the majority of a save is (relatively) static. Decorative entities, trees, tiles and relatively static entities (power poles, idle turrets, walls) outnumber active entities (assemblers, inserters, pipes, ...); removing decoratives can shrink a save significantly, for example.

I believe belts are serialised as they are represented in memory, and runs of items and gaps are updated, not the location of each item. That means a full belt moving at full speed only changes between saves where there are gaps at either end, no matter how long the belt is.

That said, I haven't checked what the actual % change between one save and the next is (yet), and it's entirely possible that, as you say, it's just not worth the effort.

I suspect it would heavily depend on what % of the factory remains idle between saves and how much active combat there is.

mikey122
Manual Inserter
Manual Inserter
Posts: 1
Joined: Fri Jun 14, 2024 7:07 pm
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by mikey122 »

For 2.0 we've added an option to "auto-pause when a player is joining" which works exactly as it says.
For me this is not the best solution. Works somewhat but it would be nice to adjust the server UPS so the game runs slower during connection but not halts entirely. Like if one player is catching up -> setUPS(30)
and the more players catching up the slower it gets. Like 10 players catching up server uses 5 UPS (or make a limit when server will pause like it is now implemented for 2.0)

For larger bases this would basically send everyone to a 2-5min break without any option to build, inspect, explore the map. And that every time someone tries to join.

Syriusz
Long Handed Inserter
Long Handed Inserter
Posts: 53
Joined: Thu May 07, 2015 12:34 pm
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by Syriusz »

meganothing wrote: ↑
Fri Jun 14, 2024 2:55 pm
Syriusz wrote: ↑
Fri Jun 14, 2024 2:35 pm
Being able to reproduce bugs locally is I guess around 90-95% of the time spent fixing reported bugs.
As fellow developer I feel this so much. I cannot even discuss it with players, and we don't get logs or saves since I work for a studio that has a person to answer on forums, but they never ask for details or files. Sometimes when I am assigned to fixing live game, I end up a day with 0 fixes or even 0 reproductions and this feels bad.
And you can't simply talk with this person that answers the forum and tell him/her what you need?
Not really, they work for publisher as far as I know. And trying to go around company relations seems unwise. And it's not like the managers are oblivious to the reproduction issue.

mcmase
Inserter
Inserter
Posts: 41
Joined: Wed Mar 29, 2017 5:57 pm
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by mcmase »

Houdini111 wrote: ↑
Fri Jun 14, 2024 1:46 pm
Mithaldu wrote: ↑
Fri Jun 14, 2024 12:09 pm
it's really frustrating to see straight-up bugfixes that sound like they would easily apply to factorio v1, being limited to v2
That's assuming it doesn't conflict with any v2 Specific changes. There's a decent chance that it does, and if it does then they'd have to make it in v1 and then port the changes to v2 (deal with merge conflicts). Which might lead to them having to write the changes twice. And that's assuming that the change would even be possible in v1. It might depend on things only added in v2.
All that to say, we don't know that they would easily apply to v1.
I don't think any of this is correct.
jjcf89 wrote: ↑
Fri Jun 14, 2024 5:35 pm
Mithaldu wrote: ↑
Fri Jun 14, 2024 12:09 pm
it's really frustrating to see straight-up bugfixes that sound like they would easily apply to factorio v1, being limited to v2
v2 is free right? It's only the expansion that will cost money, so everyone should get these improvements, if I understood correctly.
They've said multiple times that everything in the base game will be upgraded, and if you've been following along the FFF, typically in each one they are clear whether the topics covered apply to the expansion or the base game. In this FFF, referring to 2.0, that means these are base game improvements that will be released for all players who own the game, regardless of ownership of Space Age Expansion. So I do believe the above response has indeed understood correctly.

mcmase
Inserter
Inserter
Posts: 41
Joined: Wed Mar 29, 2017 5:57 pm
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by mcmase »

mikey122 wrote: ↑
Fri Jun 14, 2024 7:14 pm
For 2.0 we've added an option to "auto-pause when a player is joining" which works exactly as it says.
For me this is not the best solution. Works somewhat but it would be nice to adjust the server UPS so the game runs slower during connection but not halts entirely. Like if one player is catching up -> setUPS(30)
and the more players catching up the slower it gets. Like 10 players catching up server uses 5 UPS (or make a limit when server will pause like it is now implemented for 2.0)

For larger bases this would basically send everyone to a 2-5min break without any option to build, inspect, explore the map. And that every time someone tries to join.
It's an option, so if your server has many players, or primarily players with good PCs, then disable this option. I think it would be weird to force players to play a slo-mo version of the game, and if you're assuming a 2-5 minute pause when someone joins because that's as long as their PC plays catch-up, then running the server at 50% speed would mean you'd be playing at half-time for 4-10 minutes. Can't see how that's any less annoying.

This is probably meant more for smaller servers with players who know each other and may be playing on really old machines/bad connections. I can't imagine this being enabled for servers with multiple leaving/joining players per hour. In those cases, unfortunate, but have to let those with the poor internet wait on their own time or try another solution.

User avatar
<NO_NAME>
Filter Inserter
Filter Inserter
Posts: 293
Joined: Tue Aug 02, 2016 9:52 am
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by <NO_NAME> »

Honestly, the fact that you guys managed to make multi-threaded program of this scale deterministic is super impressive.
The fact it additionally can run it sync on multiple machines is beyond my imagination.
I am a translator. And what did you do for Factorio?
Check out my mod "Realistic Ores" and my other mods!

bobucles
Smart Inserter
Smart Inserter
Posts: 1703
Joined: Wed Jun 10, 2015 10:37 pm
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by bobucles »

Well, I have no clue how the save files or particular algorithms work. If a 500mb megabase ends up generating a daily delta like 20-50mb, then the delta solution might do the trick. Such a huge level of efficiency is hard to ignore. If the deltas are looking more like a quarter of the master size or worse, or if the methods start demanding big performance taxes, then it wouldn't make much sense. It seems like such a narrow scope solution, though. It would mostly benefit larger saves while losing most of its utility on the smaller scale.

Altaric
Inserter
Inserter
Posts: 25
Joined: Thu Mar 16, 2017 12:04 pm
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by Altaric »

Hello,

Rather than pausing when players are joining, can we get an option to slow down the game ?
On our server we have a script that reduces game speed and increases run speed so it's still playable.
I know changing prototypes isn't possible during runtime, otherwise, changing factories speed, vehicle speeds would be a plus!

Also can we have the chat available during pauses ?

Have a good day!

thermomug
Inserter
Inserter
Posts: 25
Joined: Fri Sep 08, 2023 1:51 pm
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by thermomug »

Hi,

Firstly, I wanted to say how cool I think you developers are. You're developing a game about engineering and have shown time and time again that you are outstanding software engineers yourselves.
In a way, factorio games and software development are one and the same ...

Since today's FFF once again emphasised how difficult multi-threading is, I wanted to ask if you have ever evaluated the advantages and disadvantages of rust? Of course that would be a big step, but I have the impression that you want to continue working on this project for a long time. After all, the factory has to grow :)

I'm not that deep into it, but rust seems very promising because you define more of a computational graph. Due to its proximity to hardware, it also offers numerous possibilities for optimization.

have an efficient weekend and see you next week!

ElderAxe
Fast Inserter
Fast Inserter
Posts: 135
Joined: Thu May 18, 2017 8:04 am
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by ElderAxe »

Great updates. I usually increase the ghost check per tick number from 3 to 20 on my solo games. It helps a lot when you place big blueprints.

Since you have a better way of checking ghosts now, can you also add a circuit capability to read ghosts from roboports?

User avatar
Philip017
Filter Inserter
Filter Inserter
Posts: 360
Joined: Thu Sep 01, 2016 11:21 pm
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by Philip017 »

I seem to recall that pause on player join used to be the default function in a previous version, and many of us hailing praise to not having to wait while someone connects and joins.
while those with slower computers that join a server that is faster than their computer can be problematic to stay connected even, essentially slowing everyone down if they are the slowest.

i feel like if someone joins a server and is unable to easily catch up, they probably shouldn't be trying to join the server anyway as they wont be able to keep up.

on the other hand, if an admin is present, they can pause the server manually and allow their friend to catch up, and even slow the game if necessary to keep their friend with the slow computer connected.

koscianski
Manual Inserter
Manual Inserter
Posts: 1
Joined: Fri Jun 14, 2024 10:53 pm
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by koscianski »

Hi everyone!

I’ve been following the recent discussions and wanted to suggest a potential optimization for how roboport checks are being handled during blueprint construction.
Current Approach:
Checks all roboports across the entire map, leading to unnecessary overhead, especially in large factories.
2.0 Approach:
Use the "rectangle union areas" to avoid redundant checks

Here’s an idea that might help improve the process:
Chunk and Distance Focus: We only need to check the roboports within the chunks around where the blueprint is located. Consider only those with a distance to the blueprint element less than or equal to the max distance a roboport may reach within these chunks. This will ensure only roboports that can actually reach the element are considered.

Single Network Check: Identify which logistics networks these roboports belong to. Each network only needs to be checked once. Multiple checks for the same network will yield the same result, so they can be skipped.

Example:
In the provided image where the entire map is covered by a single huge network, only one check is necessary rather than 900 (or 36k).

This approach focuses the search on relevant roboports and reduces unnecessary checks, potentially improving game performance and efficiency.

Did I miss anything?

User avatar
Ohz
Fast Inserter
Fast Inserter
Posts: 195
Joined: Tue Feb 03, 2015 11:40 am
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by Ohz »

Sorry for my stupid question but why the user was using Factorio on multiple computers? I mean if it's just a server with multiple players on different machines, there would be desync on all machines ever, no ? Im confused...
I'm not english, sorry for my mistakes

mmmPI
Smart Inserter
Smart Inserter
Posts: 3145
Joined: Mon Jun 20, 2016 6:10 pm
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by mmmPI »

Ohz wrote: ↑
Fri Jun 14, 2024 11:03 pm
Sorry for my stupid question but why the user was using Factorio on multiple computers? I mean if it's just a server with multiple players on different machines, there would be desync on all machines ever, no ? Im confused...
Not sure i'm correct, but it seemed to me that host of server could be having a "new CPU" and say 2 or 3 players too, playing fine, but then when a player having a "old CPU" would try to join, it wouldn't be allowed to, because it would be desynced at the moment of joining. Not sure it would affect all players in such case, only the one joining no ?

Loewchen
Global Moderator
Global Moderator
Posts: 8584
Joined: Wed Jan 07, 2015 5:53 pm
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by Loewchen »

Ohz wrote: ↑
Fri Jun 14, 2024 11:03 pm
I mean if it's just a server with multiple players on different machines, there would be desync on all machines ever, no ? Im confused...
Confused about what? All client machines with different thread count than the server will desync when this mod is running these instruction.

yinyang117
Manual Inserter
Manual Inserter
Posts: 2
Joined: Sat Jun 15, 2024 5:24 am
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by yinyang117 »

This is amazing! I teach software engineering, and talking about big-O notation is one of my favorite talks! what a magnitude of change!

User avatar
Blaster
Inserter
Inserter
Posts: 38
Joined: Sun Mar 27, 2016 9:16 pm
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by Blaster »

Excellent!

Now do pipes!


Coren_Albrich
Manual Inserter
Manual Inserter
Posts: 1
Joined: Tue Sep 15, 2020 1:26 am
Contact:

Re: Friday Facts #415 - Fix, Improve, Optimize

Post by Coren_Albrich »

For the change to bot job allocation and job check frequency, specifically the change to rectangle union calculations;

1) What is the correlation/relationship between these Rectangle Union Areas and the roboport coverage they represent? From the example is seems like they each represent 41 ports on average, but how are they formed and what are their limitations? Was that mentioned in a previous FFF or is it some baseline software or game development practice I'm just not aware of?
2) Are there certain roboport layouts that are better for this and would result in less areas to check, and would this result in less checks and thus less of a potential impact?
3) Is my impact concern even warranted in megabases after the new change? I have multiple worlds with over 10K ports placed, so that's the scale I'm worried about for this.

Post Reply

Return to β€œNews”