Friday Facts #201 - 0.15 Stable, but not really

Regular reports on Factorio development.
Koub
Global Moderator
Global Moderator
Posts: 7175
Joined: Fri May 30, 2014 8:54 am
Contact:

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

Post by Koub »

SilverAura wrote: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.
You're just off one thing : it's planned for 0.16 :mrgreen:
Koub - Please consider English is not my native language.

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 »

Ah, that would explain it.

Well on the plus side, I did find out how to enable the old debug mode version so I can just use that until 0.16. I am determined to learn how to make train networks work out. They might not be necessary but man do I love seeing the intricate train networks people make. It's taking me back to my childhood with Railroad Tycoon, except it's my own factory I'm shipping stuff around in.

Be that as it may, I've been playing Factorio on and off for over a year now and I absolutely LOVE the progress the folks have made here. I saw a quote somewhere, can't remember where, but it encompasses the game so well. "Factorio creates an itch only it can scratch." And it does so... phenomenally well.

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 »

malventano wrote:
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).
Seconding this question. Could it work? Creating a separate blueprint library for *every* set of mods seems like a rather clumsy and messy solution.

That said, it would be nice to have another level of organization for blueprints->books->...?
Last edited by IronCartographer on Sat Jul 29, 2017 9:25 am, edited 1 time in total.

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 »

Rseding91 wrote: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.
Ah, I see. I figured there'd be some reason(s) for it that I wasn't seeing.
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.
I think your explanation above covered the issues anyways but what I meant was that it would load the game and just wouldn't display graphics that haven't yet loaded/not play sounds that haven't been loaded until those resources have been loaded in. To get the basic idea if that's not clear: It'd be kinda like chunk loading in Minecraft where when you load into the world it loads each chunk in while you're playing which can result in chunks that you can't actually see because they're not yet loaded, just with the graphics and sounds instead of map data.
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.
Oh yeah, no complaints there. A lot of newer games load much more slowly. My biggest complaint is just stuff like changing mods and having to reload everything but that's really unavoidable as far as I can tell.

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 »

Rseding91 wrote: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.
I disagree. A progress bar at the bottom of the screen while the main menu was (mostly) functional would still be an optimization from a user's perspective. They could use the time to find a specific save (especially when switching modpacks), or browse for a server to connect to (which might force a restart anyway, if automatic mod management is added at some point). The main issues would be Mod/graphics settings and Save previews being disabled until everything finished loading. You've done more for less, I bet. ;)

It could be jarring if an error occurs during that time, but as long as the progress bar was prominent enough, it should be quite clear why the interruption occurred.

danyg
Burner Inserter
Burner Inserter
Posts: 12
Joined: Thu Nov 10, 2016 10:38 pm
Contact:

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

Post by danyg »

Guys as regards: Rail block visualisation finished

One of the thing is still being not so straight forward is to know the direction from where the trains came in a specific rail. As per the image shown, I couldn't know, I would expect to see an arrow in
those coloured lines. Either that or change a bit the signals sprite to be more meaningful to were is heading, like putting them in a post heading to the train, (although I suppose that wouldn't be ok to vertical rails pointing to north direction :( )

I thing the shown state of the block visualisation is great for bi-directional rails thought.

I know that this might sound weird to some people, but the trains doesn't being drive in the same way in all the countries in the world, in my country the trains got driven in the left side whereas the cars in the right but where I live now the trains also are driven in right side (that makes a mess in my head) and sometimes I struggle in my factories to know which arrangement I've have chosen, needing to mouseover the signals to be sure where the trains should came from...

Cheers

Jap2.0
Smart Inserter
Smart Inserter
Posts: 2339
Joined: Tue Jun 20, 2017 12:02 am
Contact:

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

Post by Jap2.0 »

They're for 0.16 :).
There are 10 types of people: those who get this joke and those who don't.

gibbelblonk
Manual Inserter
Manual Inserter
Posts: 4
Joined: Wed Jul 05, 2017 6:58 pm
Contact:

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

Post by gibbelblonk »

Next you could look into some biter optimizations. On poorer machines the game slows down considerably when the biters and spitters do something other than stay still.

User avatar
Sigma1
Fast Inserter
Fast Inserter
Posts: 231
Joined: Mon Nov 21, 2016 5:25 pm
Contact:

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

Post by Sigma1 »

Am I the only one who is very annoyed by that intersection being asymmetric? Anyway, I really like the new visualisations.
she/they

meganothing
Fast Inserter
Fast Inserter
Posts: 238
Joined: Thu Sep 15, 2016 3:04 pm
Contact:

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

Post by meganothing »

Alice3173 wrote: I think your explanation above covered the issues anyways but what I meant was that it would load the game and just wouldn't display graphics that haven't yet loaded/not play sounds that haven't been loaded until those resources have been loaded in. To get the basic idea if that's not clear: It'd be kinda like chunk loading in Minecraft where when you load into the world it loads each chunk in while you're playing which can result in chunks that you can't actually see because they're not yet loaded, just with the graphics and sounds instead of map data.
That is possible to do but has a disadvantage: Every graphics and sound bit would need a short bit of code executed all the time to find out if it has been loaded already. So you might save 5 seconds on startup but that short bit of code executed millions of times per second would probably amount to a small but measurable slowdown playing the game. There is no question which part of the game is more important to be fast.

meganothing
Fast Inserter
Fast Inserter
Posts: 238
Joined: Thu Sep 15, 2016 3:04 pm
Contact:

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

Post by meganothing »

How does 0.16 visualize bidirectional lines? I.e. if there are signals on both sides?

The easy to do but somewhat misleading solution would be to cut up the segments at any signal independent of direction. The not so easy but correct solution would paint two parallel lines, one for each direction.

zebediah49
Fast Inserter
Fast Inserter
Posts: 119
Joined: Fri Jun 17, 2016 8:17 pm
Contact:

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

Post by zebediah49 »

meganothing wrote: The easy to do but somewhat misleading solution would be to cut up the segments at any signal independent of direction. The not so easy but correct solution would paint two parallel lines, one for each direction.
Cutting segments at any signal is how the block system works, anyway, so it wouldn't be misleading (and is how the system works).

Since a train will never pass a single signal on its left (that is, it will pass a single signal on the right, or a double signal on both sides), you can never have a case where the lines would be different. If there's a signal on one side, it's a one-way track; if there is a signal on both sides, it's a two way track.

Thus, all we would really need/want there would be a directional indicator: showing if the section is one- or two-directional. The most complicated situation would be that of a two-to-one Y, where the top sides are one-directional and the bottom is two-directional.

IMO the cleanest would be subtle arrows pointing along the direction of travel (for one-way), or no arrows (for two-way).

bbgun06
Long Handed Inserter
Long Handed Inserter
Posts: 60
Joined: Fri Mar 27, 2015 4:09 pm
Contact:

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

Post by bbgun06 »

Thanks for the hard work improving the game loading process. I've noticed that trying to alt-tab while loading the game behaves very badly. Either alt-tab doesn't do anything or it is very slow and unresponsive. Also the sound sometimes gets choppy while the game is loading in the background.

Also I've noticed that doing certain combinations of toggling, updating and installing mods can cause the game to quit and restart up to three times. That's very annoying, especially on older systems that can take minutes to load the game.

Also, apostrophes as thousands separators?

wlfbck
Inserter
Inserter
Posts: 45
Joined: Wed Nov 30, 2016 7:04 pm
Contact:

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

Post by wlfbck »

Omeganoconfictos wrote:
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...
Just want to second this. Arrows would be incredibly helpful on intersections.

Tony88
Manual Inserter
Manual Inserter
Posts: 4
Joined: Fri Jun 09, 2017 1:41 am

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

Post by Tony88 »

All this talk about optimizing startup brings this back to mind: Why not check for and install updates BEFORE spending time loading all that stuff, since it will all need to be loaded again after installing an update??? This reloading makes updating seem slower than it really is.

User avatar
cpy
Filter Inserter
Filter Inserter
Posts: 839
Joined: Thu Jul 31, 2014 5:34 am
Contact:

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

Post by cpy »

Optimizations? If we get belts optimizations and update threading, then factorio could run on an unseen levels.
Or if we could run factorissimo threaded? That would be nice too! Imagine all those tiny factories running in their own threads preparing stuff to be transfered. Just one small update to final updater about what needs to be transfered. But all the calculations can be done inside :)

Sort of like thread safe zones. Could be easy right? You just build some big factory building that runs in own thread and only contributes to main update thread as a belt/liquid/power connection.
Some monitoring crap can also run in threads, like yet another resource monitor or others.

Besides i think worse UPS killers are AAI mod with AI vehicles, i mean either it shows how much update time AI uses or how AAI is unoptimized. Shame really because AAI adds so much RTS to the game that it feels like it should be part of base game in late game.

User avatar
bobingabout
Smart Inserter
Smart Inserter
Posts: 7351
Joined: Fri May 09, 2014 1:01 pm
Contact:

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

Post by bobingabout »

Although it is possible to construct rail system that results in our algorithm putting two of the same colors next to each other, it is not really a problem, as it doesn't break anything, and in a normal game, the chance of it happening is close to 0.
https://us2.factorio.com/assets/img/blo ... colors.jpg
You have a yellow, overlapping a yellow, overlapping a yellow.... that's not "near 0".
Creator of Bob's mods. Expanding your gameplay since version 0.9.8.
I also have a Patreon.

User avatar
Klonan
Factorio Staff
Factorio Staff
Posts: 5148
Joined: Sun Jan 11, 2015 2:09 pm
Contact:

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

Post by Klonan »

bobingabout wrote:
Although it is possible to construct rail system that results in our algorithm putting two of the same colors next to each other, it is not really a problem, as it doesn't break anything, and in a normal game, the chance of it happening is close to 0.
https://us2.factorio.com/assets/img/blo ... colors.jpg
You have a yellow, overlapping a yellow, overlapping a yellow.... that's not "near 0".
They are in the same block, so it is intended they are the same color

mrvn
Smart Inserter
Smart Inserter
Posts: 5682
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Save in the background

Post by mrvn »

I'm always annoyed when trying to do something and the saving dialog pops up. And the more you play the larger the problem becomes because saving takes longer on larger factories.

Why not save in the background in a separate thread and let the game keep running?

"All" this would need to do is to make a snapshot of the game state and then save that while the game continues on the main data. Under Linux at least this is simple since you can

Code: Select all

fork()
to get a snapshot of the processes memory. This will affect performance and memory footprint somewhat during save but not stop the game. So UPS might drop while saving but the game won't stop dead.

User avatar
fechnert
Inserter
Inserter
Posts: 32
Joined: Fri Jun 30, 2017 12:48 pm
Contact:

Re: Save in the background

Post by fechnert »

mrvn wrote:I'm always annoyed when trying to do something and the saving dialog pops up. And the more you play the larger the problem becomes because saving takes longer on larger factories.

Why not save in the background in a separate thread and let the game keep running?

"All" this would need to do is to make a snapshot of the game state and then save that while the game continues on the main data. Under Linux at least this is simple since you can

Code: Select all

fork()
to get a snapshot of the processes memory. This will affect performance and memory footprint somewhat during save but not stop the game. So UPS might drop while saving but the game won't stop dead.
To not talk about the implementation, but the idea about a quicksave that won't interrupt the game while playing would be very nice
Image[url=steam://friends/add/'.76561198066150999.']Image[/url]

Post Reply

Return to “News”