Friday Facts #415 - Fix, Improve, Optimize

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

[mrudat]

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]

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]

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]

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.

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]

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.

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

[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]

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]

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]

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?

[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]

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?

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

[mmmPI]

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]

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]

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

[Blaster]

Excellent!

Now do pipes!

[Svip]

This reminds me of this analysis of how Serious Sam managed seamless massive hordes of enemies on 56k modems. Great stuff.

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