Factorio Forums

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

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.

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

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.

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.

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

They're for 0.16 .

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.

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

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.

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.

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

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?

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.

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.

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.

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

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

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

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