Friday Facts #201 - 0.15 Stable, but not really

Regular reports on Factorio development.
dinodod
Long Handed Inserter
Long Handed Inserter
Posts: 84
Joined: Tue Mar 10, 2015 10:42 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by dinodod »

Again, no news for optimization of slow networks / desyncs / UDP floods causing routers to drop internet. Guys, come on, these desyncs are killing the game, had over 20 back to back today on one server (not just me, everyone).

Also, why does factorio kill the router's internet when downloading large maps and how can this be avoided?

Setup a 5MB internet and see if it happens for you. If not, then your code is conflicting with some routers even though UDP Flood protection is off AND the server is in the DMZ.

Please get your netcode polished.

jjcf89
Manual Inserter
Manual Inserter
Posts: 4
Joined: Thu Jul 21, 2016 1:06 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by jjcf89 »

eX_ploit wrote:
On this new computer with normal graphics quality Factorio takes 9.84 seconds to reach the main menu. I think that's pretty good for a game these days
Actually it's not good. Seems like you are loading all of the assets before showing main menu, while only a small minority of those assets are needed in main menu. You can just load those assets and then load everything else in background while player chooses what he's gonna play.
This comes off a bit harsh. I think a 10 second startup is pretty good, though it could be better. Your suggestion is a good one it just didn't need the first sentence.

Bomaz
Burner Inserter
Burner Inserter
Posts: 15
Joined: Sun Jul 24, 2016 10:02 am
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by Bomaz »

The rail segment is really cool and useful however how about making the line segments arrows as it is possible to have a missing signal on only one side of the rail

Twinsen
Factorio Staff
Factorio Staff
Posts: 1329
Joined: Tue Sep 23, 2014 7:10 am
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by Twinsen »

dinodod wrote:Guys, come on, these desyncs are killing the game, had over 20 back to back today on one server (not just me, everyone)
We are barely getting any desync reports reported on the forum. If you have a desync you need to report it in the bug reports section for it to get fixed.

Rocksen
Burner Inserter
Burner Inserter
Posts: 10
Joined: Tue Jun 23, 2015 5:22 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by Rocksen »

84 million calls? seems like someone is going to have to rewrite the whole save system at some point xD. maybe combine "objects" so that the function does not need to write then stop write then stop, instead if you combine some objects it could write write write stop, which for a HHD makes a huge difference. then again, saying to rewrite that system is me saying to rewrite the whole game so just ignore me =). it is amazing how fast it saves honestly.

honestly i bet you, that most of those save calls are from the base tile background that has no function other then displaying a sprite, in which case should ONLY be saved if it has been changed by the player/s. although without really looking at the code i'm just guessing so oh well xD.

Omeganoconfictos
Manual Inserter
Manual Inserter
Posts: 1
Joined: Fri Jul 28, 2017 9:38 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by Omeganoconfictos »

Bomaz wrote:The rail segment is really cool and useful however how about making the line segments arrows as it is possible to have a missing signal on only one side of the rail
This. It would be really beneficial to those of us trying to make rather complex train systems. I can do track, but I'll be @#$%ed if I didn't have 45 minutes of head-to-desk frustration over missing one side of a signal when even the show rail block debug option didn't help...

evildogbot100
Fast Inserter
Fast Inserter
Posts: 152
Joined: Sun Dec 18, 2016 3:02 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by evildogbot100 »

The rail coloration might have some problem if only using 3 colour. Even 4 colour is hard to do algorithmically (4 colour theorem). I think it needs at least 5 colour for a constructive algorithm.

Rseding91
Factorio Staff
Factorio Staff
Posts: 13175
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by Rseding91 »

Rocksen wrote:84 million calls? seems like someone is going to have to rewrite the whole save system at some point xD. maybe combine "objects" so that the function does not need to write then stop write then stop, instead if you combine some objects it could write write write stop, which for a HHD makes a huge difference. then again, saying to rewrite that system is me saying to rewrite the whole game so just ignore me =). it is amazing how fast it saves honestly.

honestly i bet you, that most of those save calls are from the base tile background that has no function other then displaying a sprite, in which case should ONLY be saved if it has been changed by the player/s. although without really looking at the code i'm just guessing so oh well xD.
I think you need to re-read the FF :) it's not 84 million calls to write-to-disk. it's 84 million calls to write to the serializer which copies the memory to a buffer which is flushed to disk in 1 MB chunks in a different thread while the serialization happens.
If you want to get ahold of me I'm almost always on Discord.

IronCartographer
Filter Inserter
Filter Inserter
Posts: 454
Joined: Tue Jun 28, 2016 2:07 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by IronCartographer »

Please make sure that the rail coloring overlay is optional / configurable, as the FFF example/coloration is somehow causing a visceral reaction I can't quite explain other than feeling ill. :? :(
Twinsen wrote:
dinodod wrote:Guys, come on, these desyncs are killing the game, had over 20 back to back today on one server (not just me, everyone)
We are barely getting any desync reports reported on the forum. If you have a desync you need to report it in the bug reports section for it to get fixed.
To me it sounds like dinodod is misusing the 'desync' term as if it had anything to do with networking. People think it has to do with timing (latency), despite it being a game-state validity issue. Renaming it to "Mismatch!" instead of "Desync!" might prevent that, but it's a bit late to change terms as such.

m44v
Fast Inserter
Fast Inserter
Posts: 122
Joined: Sun May 15, 2016 8:55 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by m44v »

Trepidati0n wrote:I think the game right now in terms of launching a single rocket is "spot on" with any of the presets. Nothing about the the baseline is clunky. However, you did add "infinite research" drives "bigger and bigger bases" without adding in features to make "bigger and bigger bases" possible. I can see why you didn't (few % of players do this scale).

For example, it takes around 5-6GW er 1kSPM (full productivity). I removed the reactors system from my base and replaced it with a cheaty source and got back 2 ms of my 14.3 ms usage. That seems odds to me 14% of my CPU time is for the power plant. I really do understand the desire for how fluid/heatpipes work but I do not think a) it is in anyway obvious to the player how they limit out and b) use a large amount of processing resources.

This thread alone (viewtopic.php?t=19851) make me feel that this problem is made to complicated for the vast majority of players. Why not just make it simple...sum up the total pipe segments for a line and say "I can move X fluid per second and the pipe can hold Y units of fluid". This would then reduce the computation significantly (since all pipes connected together in that group would be done once). Same for heat pipes. Treat them as simple resistor regardless of series/parallel combination. Thus if you have 10 vs 20 your can move 2x vs 1x power and put this on a tool tip.

My argument from a gameplay view though might be more simple of "Is this so overly complicated that a users first reaction to it is go read the wiki"?
You're basically advocating for making heat and fluid networks to behave like the electric network, so what happens in one end of the piping is felt instantaneously in the other, even if they are separated by long distances. For electric networks it makes sense, since time constants of electric processes are near instantaneous, but is not the case of fluids and heat, hence the game has a flow simulation in place.

I disagree that is complicated, in what sense? anyone can setup a working refinery or nuke, flow mechanics aren't going to prevent that. Is simple enough for anyone to use, yet anyone interested can dig deeper, investigate was is under the hood and tinker with it, just like XKnight did in the thread you linked. Your proposal takes that away, and I will add that I don't like the idea for making the game shallower just for the sake of more UPS and the 1% of players that build megabases, in the end they will just build bigger, hit a new celling then argue for something else to be optimized out of the game.

Portman
Manual Inserter
Manual Inserter
Posts: 4
Joined: Fri Jul 07, 2017 1:10 am
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by Portman »

Hopefully this doesn't sound dense but can anyone point out the missing signal from that example? I've only worked with single train systems so far with one rail so I might be missing it due to inexperience but as far as I can tell those signals would work. Guess I need to go through the tutorial and play around some more in sandbox mode! :lol:

IronCartographer
Filter Inserter
Filter Inserter
Posts: 454
Joined: Tue Jun 28, 2016 2:07 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by IronCartographer »

Portman wrote:Hopefully this doesn't sound dense but can anyone point out the missing signal from that example? I've only worked with single train systems so far with one rail so I might be missing it due to inexperience but as far as I can tell those signals would work. Guess I need to go through the tutorial and play around some more in sandbox mode! :lol:
https://www.reddit.com/r/factorio/comme ... y/dkuh5yq/
:arrow:
Image

It would "work" without the signal, but trains would have to wait for each other in situations where that missing signal could prevent it.

User avatar
distortions864
Fast Inserter
Fast Inserter
Posts: 108
Joined: Thu Apr 20, 2017 12:56 am
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by distortions864 »

"optimizations" typo in there.

malventano
Filter Inserter
Filter Inserter
Posts: 340
Joined: Thu Apr 27, 2017 4:31 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by malventano »

after quick a discussion we decided to solve it by having blueprint library separated for every mod configuration and by allowing players to transfer library contents from different mod configurations to the current one on demand.
Why not simply always retain the blueprint as created but strip out the modded content as the blueprint is pulled from the library and into a game object? This way modded blueprints can be traded by players even when running on a multiplayer map without those mods running. It will also prevent players running multiple different maps / mods from having to manually sync some of their modded/unmodded blueprints across sessions (which would be extremely tedious and annoying).
Last edited by malventano on Sat Jul 29, 2017 2:52 am, edited 1 time in total.
Allyn Malventano
---
Want to improve fluid flow between pumps / across longer distances? Try my Manifolds mod.

malventano
Filter Inserter
Filter Inserter
Posts: 340
Joined: Thu Apr 27, 2017 4:31 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by malventano »

eX_ploit wrote:
On this new computer with normal graphics quality Factorio takes 9.84 seconds to reach the main menu. I think that's pretty good for a game these days
Actually it's not good. Seems like you are loading all of the assets before showing main menu, while only a small minority of those assets are needed in main menu. You can just load those assets and then load everything else in background while player chooses what he's gonna play.
100x this. Get to the menu GUI as fast as possible and load the rest while the player interacts with that GUI (with a background loading bar somewhere, say bottom right). Prevent user from doing any actions that need all content loaded (loading a game, etc) until the background load is complete. Feedback there can be the loading bar flashes or changes color when the user attempts those actions. Or perhaps allow the action but then wait until the background operation is complete before continuing.
Last edited by malventano on Sat Jul 29, 2017 2:53 am, edited 1 time in total.
Allyn Malventano
---
Want to improve fluid flow between pumps / across longer distances? Try my Manifolds mod.

malventano
Filter Inserter
Filter Inserter
Posts: 340
Joined: Thu Apr 27, 2017 4:31 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by malventano »

IronCartographer wrote:Please make sure that the rail coloring overlay is optional / configurable, as the FFF example/coloration is somehow causing a visceral reaction I can't quite explain other than feeling ill. :? :(
I believe it is the mixing of RGB and CMY colors. I get that is an easy way to get 6 distinct colors, but it's not a way that is easy on the eyes. RGB should be the first three, and something other than CMY should be the rest (or shift cyan to #6).
Allyn Malventano
---
Want to improve fluid flow between pumps / across longer distances? Try my Manifolds mod.

Conventia
Burner Inserter
Burner Inserter
Posts: 10
Joined: Sun Jun 04, 2017 9:45 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by Conventia »

For the modded blueprints bug, wouldn't this solution be better (this is a logical version, optimizations are ignored):

1. Add an optional vector to hold the serialized version of a blueprint to a blueprint's in memory representation.
2. On blueprint load, the serialized content is stored to that location, such that items from mods which aren't enabled are still present. Obviously, using the blueprint doesn't result in those items being placed, but that's ok.
3. When a blueprint is successfully edited by the player, the serialized content is removed. (A warning could be added if it's detected that items will be lost.)
4. When saving, the serialized content is stored if it's available and the regular process is used if it is not.

That would allow for having a single library and no need for transfers between libraries. Conceptual, blueprints are immutable, there's no reason that reading them and using them should change them. And having multiple libraries split based on mods would be really frustrating, especially when many popular mods either don't have items. And it also makes the creative mode mod way less useful, because most of the blueprints created when that mod is enabled are destined for a save which doesn't use that mod.

User avatar
Alice3173
Fast Inserter
Fast Inserter
Posts: 118
Joined: Sun Apr 24, 2016 11:35 pm
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by Alice3173 »

Would it be possible and feasible to do a sort of lazy loading at game initialization rather than loading everything? Ie: Only load the stuff that the game absolutely can't run without then load stuff such as graphics and audio in a background thread according to importance. (Player graphics being very important, for example.) From my understanding it should be doable but I'm not sure what the exact downsides would be. I'm not familiar with sprite atlases or whatever the proper name is for the way you handle graphics but since that's meant to help make graphics render easier I'd think that having to append newly loaded graphics to that would probably impact performance for awhile when stuff is still loading in.

Rseding91
Factorio Staff
Factorio Staff
Posts: 13175
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by Rseding91 »

Alice3173 wrote:Would it be possible and feasible to do a sort of lazy loading at game initialization rather than loading everything? Ie: Only load the stuff that the game absolutely can't run without then load stuff such as graphics and audio in a background thread according to importance. (Player graphics being very important, for example.) From my understanding it should be doable but I'm not sure what the exact downsides would be. I'm not familiar with sprite atlases or whatever the proper name is for the way you handle graphics but since that's meant to help make graphics render easier I'd think that having to append newly loaded graphics to that would probably impact performance for awhile when stuff is still loading in.
As it is now we verify every sound and sprite that the game needs to use is valid according to the definition provided for it at startup. Additionally the game builds all sprites into atlases and converts those using the graphics settings you have enabled.

If the game had to split all of that up you would end up with situations where you're on the game screen clicking through menus and then it crashes back to an error dialog stating files are missing/sprites are invalid/you ran out of VRAM. Also, because we load all sprites into atlases at once at startup the game runs faster because there are less atlases to deal with when rendering happens. The final reason: it wouldn't make it any faster. You launch the game and within 2 seconds of reaching the main menu have told it to load a save file which it then still would have to wait for graphics to finish loading.

It's common and accepted that launching a game takes some time to load - almost everyone understands what's happening when it works that way and it works well for both runtime performance and validation of all data before the game starts running any map.

Not to say it will never happen - who knows. Maybe we'll find answers to those problems at some point.
If you want to get ahold of me I'm almost always on Discord.

SilverAura
Manual Inserter
Manual Inserter
Posts: 2
Joined: Sat Jul 29, 2017 7:58 am
Contact:

Re: Friday Facts #201 - 0.15 Stable, but not really

Post by SilverAura »

I must be incredibly dense because I can't for the life of me seem to figure out how to get the new rail block visualizations to show up. I've looking in the settings, I've tried holding a signal, a rail piece, even clicked on the train and nothing is making it show. I also can't seem to find any information on it. It's like I'm missing something really, really stupid here.

Post Reply

Return to “News”