Friday facts #157 - We are able to eat paper, but we don't do it

Regular reports on Factorio development.
chris13524
Fast Inserter
Fast Inserter
Posts: 193
Joined: Thu Jun 04, 2015 12:20 am
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by chris13524 » Sat Sep 24, 2016 12:50 pm

Zeblote wrote:When the pump is connected to a train, shouldn't this part be removed?

Image
I think it will be blocked off in this case. Like an oil refinery on basic with only one pipe connected.

devilwarriors
Filter Inserter
Filter Inserter
Posts: 307
Joined: Sat Jan 09, 2016 1:11 am
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by devilwarriors » Sat Sep 24, 2016 3:12 pm

aubergine18 wrote:
chris13524 wrote:I would store the decorations, if they changed every time they were loaded, it would confuse me "I don't remember that being there". You recognize the patterns of decorations to be different parts of your base, it could be a little confusing.
I agree, it would look weird if all the decorations kept randomly changing.
Agree too.. not all of us are playing a mega base or a multiplayer game with 100+ players..

I really don't care that the save take 40 mb more, it's nothing on my hard-drives. It could take 10 times more for all I care.

And that screenshot in the FFF that's suppose to demonstrate that the game generate too much decoration look absolutely gorgeous to me. There is just the right amount of them.

Maybe make that an option instead. So people who want boring flat terrain to save some mb could do it without a mod.

Generating that randomly would probably look weird when you load an existing save.

Albert
Factorio Staff
Factorio Staff
Posts: 55
Joined: Tue Apr 09, 2013 5:35 pm
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by Albert » Sat Sep 24, 2016 3:29 pm

Zeblote wrote:When the pump is connected to a train, shouldn't this part be removed?

Image
Yes, it will be removed with a mask and patched with a different ending.
This demo is using the original design of the pump, its aim is to preview the connector, not the patch, yet.

Jeffman12
Burner Inserter
Burner Inserter
Posts: 7
Joined: Fri Mar 04, 2016 1:15 am
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by Jeffman12 » Sat Sep 24, 2016 4:56 pm

devilwarriors wrote:
aubergine18 wrote:
chris13524 wrote:I would store the decorations, if they changed every time they were loaded, it would confuse me "I don't remember that being there". You recognize the patterns of decorations to be different parts of your base, it could be a little confusing.
I agree, it would look weird if all the decorations kept randomly changing.
Agree too.. not all of us are playing a mega base or a multiplayer game with 100+ players..

I really don't care that the save take 40 mb more, it's nothing on my hard-drives. It could take 10 times more for all I care.

And that screenshot in the FFF that's suppose to demonstrate that the game generate too much decoration look absolutely gorgeous to me. There is just the right amount of them.

Maybe make that an option instead. So people who want boring flat terrain to save some mb could do it without a mod.

Generating that randomly would probably look weird when you load an existing save.
Sure, it could be an option, or we could be allowed to choose the location of the save directory. I don't like that it has to be on my C drive. My C drive has limited capacity for maintenance reasons, and it's annoying that every other game out there wants to cram its misc data into my appdata folder. The whole reason I set my computer up this way was so that I could periodically format my C drive and still have all my data on the multiple terabyte drives I've accumulated. If it was in my documents, that wouldn't be an issue as Windows allows you to redirect that to any drive of your choice, but not appdata.

Jarin
Long Handed Inserter
Long Handed Inserter
Posts: 70
Joined: Thu Aug 28, 2014 8:01 pm
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by Jarin » Sat Sep 24, 2016 6:05 pm

Guys, I'm pretty sure the terrain decorations aren't going to be randomly changing. They said they're changing how it's saved, not "not saving it at all".

Neemys
Filter Inserter
Filter Inserter
Posts: 457
Joined: Sat Apr 09, 2016 6:16 pm
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by Neemys » Sat Sep 24, 2016 6:34 pm

Jeffman12 wrote:
Sure, it could be an option, or we could be allowed to choose the location of the save directory. I don't like that it has to be on my C drive. My C drive has limited capacity for maintenance reasons, and it's annoying that every other game out there wants to cram its misc data into my appdata folder. The whole reason I set my computer up this way was so that I could periodically format my C drive and still have all my data on the multiple terabyte drives I've accumulated. If it was in my documents, that wouldn't be an issue as Windows allows you to redirect that to any drive of your choice, but not appdata.
Even if microsoft state that moving appdata is unstable for the system you can move it by changing system policy to have the user directory somewhere else. As long as the new folder have proper read/write permission and the drive is NTFS. As long a you do not try to upgrade windows (like going from 7 to 8 or 8 to 10) you shouldn't have problem. Normal update works properly. Another solution, I have a friend that symlink the appdata folder and he have no problem. Windows sill think the folder is in C but in fact it's in another drive. The main problem with appdata on another drive is if this drive can't keep up, program will respond more slowly or sometime not respond. If the drive get disconnected or stop working the system will likely BSOD.

My document is for Your documents, not application's one. Game that put save in Documents are wrong. It's microsoft guidelines. Saves, config and whatever an application use and the user shouldn't interact with them directly belong to appdata.

Yet having to choose where the save is located in factorio could be a good thing.
Want more space restriction ? Or maybe you want to be forced to use train for other thing than ore and oil ? Try Building Platform Mod !

Mengmoshu
Long Handed Inserter
Long Handed Inserter
Posts: 52
Joined: Tue May 26, 2015 11:24 pm
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by Mengmoshu » Sat Sep 24, 2016 7:19 pm

I think it's OK for games to put their saves in My Documents. But! They shouldn't be creating a folder directly in My Documents! There's been a My Games or Games folder for ages, and even if there wasn't making a Games folder is less obtrusive than 20+ games with sometimes cryptic folder names cluttering My Documents.

Save files, and mods are something a user might commonly interact with. Lots of people backup their saves, and even with the Mod Portal I end up in my Mods folder pretty often. If there are configuration files that are meant to be directly edited instead of using an options menu in the game or external launcher those belong in Userspace instead of Appdata. Things that aren't supposed to be identical to all Windows User Accounts belong in My Docs or the user specific versions of Appdata.

Big, or potentially big files like Factorio save games should be in a selectable folder, because multiple drives is a thing. I don't think Factorio should have a folder select as part of the save process, but a command line option (like the one for the mods folder) or a tweakable line in a human readable configuration file somewhere would be nice. For example extend the config-path.cfg mechanisms a bit.

Zeblote
Filter Inserter
Filter Inserter
Posts: 972
Joined: Fri Oct 31, 2014 11:55 am
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by Zeblote » Sat Sep 24, 2016 8:50 pm

Jeffman12 wrote:Sure, it could be an option, or we could be allowed to choose the location of the save directory. I don't like that it has to be on my C drive.
You can move the folder from appdata to somewhere else. Just have to edit the settings in config-path.cfg (in the steam factorio folder) and config/config.ini (in the appdata factorio folder) to point at the new location, then move the folder itself.

The default value contains a macro (__PATH__system-write-data__) that basically means AppData/Factorio/

FalcoGer
Long Handed Inserter
Long Handed Inserter
Posts: 78
Joined: Fri Sep 05, 2014 3:11 pm
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by FalcoGer » Sat Sep 24, 2016 10:04 pm

Regarding the decoration:
Why don't you save the map seed and use the same seed for the same chunk to generate the plant stuffs and then check if it should be displayed, given the current condition of the chunk. That way you can generate things on the fly, don't need to save all those bushes individually and of course they'd be the same whenever you come by them.
Also what's wrong with the title? It's just weird.

DukeAl
Inserter
Inserter
Posts: 47
Joined: Mon Feb 09, 2015 3:55 pm
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by DukeAl » Sun Sep 25, 2016 12:21 am

If you use the zipped version everything is stored in the Factorio folder which can be moved wherever you like.

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

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by Rseding91 » Sun Sep 25, 2016 12:30 am

FalcoGer wrote:Regarding the decoration:
Why don't you save the map seed and use the same seed for the same chunk to generate the plant stuffs and then check if it should be displayed, given the current condition of the chunk. That way you can generate things on the fly, don't need to save all those bushes individually and of course they'd be the same whenever you come by them.
Also what's wrong with the title? It's just weird.
Because chunk generation (entity generation) is incredibly expensive and time consuming to do. Re-doing it every time you re-load a map isn't feasible.
If you want to get ahold of me I'm almost always on Discord.

Neemys
Filter Inserter
Filter Inserter
Posts: 457
Joined: Sat Apr 09, 2016 6:16 pm
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by Neemys » Sun Sep 25, 2016 12:54 am

FalcoGer wrote:Regarding the decoration:
Why don't you save the map seed and use the same seed for the same chunk to generate the plant stuffs and then check if it should be displayed, given the current condition of the chunk. That way you can generate things on the fly, don't need to save all those bushes individually and of course they'd be the same whenever you come by them.
Also what's wrong with the title? It's just weird.
see the following :
Rseding91 wrote:
trad_emark wrote:decorations:
as long as they have no actual impact on the gameplay (or do they?), why store them at all?
they can be regenerated every time a player can see the chunk, or when (or preferably after) the game loads a map.
i can see only a limited number of special cases, eg, when the player changes land to water (or vice versa), right?
and they can be completely ignored on server, too.
For the same reason we don't regenerate chunks: it takes a lot of CPU time to generate terrain/chunks/entities. Regenerating them just isn't feasible.
Mengmoshu wrote:I think it's OK for games to put their saves in My Documents. But! They shouldn't be creating a folder directly in My Documents! There's been a My Games or Games folder for ages, and even if there wasn't making a Games folder is less obtrusive than 20+ games with sometimes cryptic folder names cluttering My Documents.
Some people like to have save in Document so they don't search it everywhere, some people don't, some other tolerate when it's in My Games folder. As no solution will satisfy everyone, As a developper I will follow guideline to do as the OS maker tell it should be done. OS user will look where the os tell it should be... I don't say that guideline are perfect, they may need some change but it's how they are now. That's why save tend to end up in appdata. The problem is user don't look in appdata when looking for application related file
Mengmoshu wrote:Save files, and mods are something a user might commonly interact with. Lots of people backup their saves, and even with the Mod Portal I end up in my Mods folder pretty often. If there are configuration files that are meant to be directly edited instead of using an options menu in the game or external launcher those belong in Userspace instead of Appdata. Things that aren't supposed to be identical to all Windows User Accounts belong in My Docs or the user specific versions of Appdata.

Appdata is user-bound as My documents (both located in the user folder). I have used an incorrect wording when talking about My Document. The guideline say that no application should put anything in My documents unless the user wanted to (folder configuration, Save as, ...). So even if it is intended to be edited they should be in appdata. If this folder wasn't hidden and more game used it, people would be used to check inside when they need to edit config or whatever as they look inside Download folder when they download a file with their browser.

Why any application have the right to do anything inside my personnal file folder ? Even deleting my own file. There should be a dialog box when an application try to do something inside My documents, sadly there is not one.
Mengmoshu wrote: Big, or potentially big files like Factorio save games should be in a selectable folder, because multiple drives is a thing. I don't think Factorio should have a folder select as part of the save process, but a command line option (like the one for the mods folder) or a tweakable line in a human readable configuration file somewhere would be nice. For example extend the config-path.cfg mechanisms a bit.
I totally agree, even why not in options menu ? Not everyone know how to add a command line option.
Want more space restriction ? Or maybe you want to be forced to use train for other thing than ore and oil ? Try Building Platform Mod !

poma
Burner Inserter
Burner Inserter
Posts: 12
Joined: Sun Sep 25, 2016 1:06 am
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by poma » Sun Sep 25, 2016 1:12 am

Maybe just generate decoratives randomly from the same random seed? This way they will be the same each time when player loads the game. With this approach you need to only save which entities were destroyed to hide them when they are generated again. With a small cache this should be fast and require very little memory. Probably will require lots of development time though.

User avatar
aubergine18
Smart Inserter
Smart Inserter
Posts: 1264
Joined: Fri Jul 22, 2016 8:51 pm
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by aubergine18 » Sun Sep 25, 2016 2:24 am

poma wrote:Maybe just generate decoratives randomly from the same random seed?
That's still essentially chunk generation. See viewtopic.php?p=209782#p209782
Better forum search for modders: Enclose your search term in quotes, eg. "font_color" or "custom-input" - it prevents the forum search from splitting on hypens and underscores, resulting in much more accurate results.

hoho
Filter Inserter
Filter Inserter
Posts: 673
Joined: Sat Jan 18, 2014 11:23 am
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by hoho » Sun Sep 25, 2016 7:09 am

Rseding91 wrote:Because chunk generation (entity generation) is incredibly expensive and time consuming to do. Re-doing it every time you re-load a map isn't feasible.
Yes, generating entire chunk is expensive but how much of chunk generation time is taken specifically for generating the decorations?

How feasible would it be to generate decorations on-the-fly only when player gets near enough to the chunks that they can enter their viewing area? For some added caching, store a number per chunk how often it's viewed by the local player.

Alternatively, generate decorations when they get viewed by player. I'm fairly certain that in big maps, people have more areas discovered by radars and they never get close enough to them to actually view them themselves.

Switched
Inserter
Inserter
Posts: 21
Joined: Wed Apr 27, 2016 4:50 am
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by Switched » Sun Sep 25, 2016 7:29 am

finding lag issues on 55MB map, i like to explore the infinity but... lagses
Add Me on Steam for factorio co ops, http://steamcommunity.com/id/samueldt

kinnom
Filter Inserter
Filter Inserter
Posts: 691
Joined: Fri Dec 26, 2014 4:20 pm
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by kinnom » Sun Sep 25, 2016 7:34 am

Switched wrote:finding lag issues on 55MB map, i like to explore the infinity but... lagses
use undecorator and/or upgrade your computer
no yes yes no yes no yes yes

Neemys
Filter Inserter
Filter Inserter
Posts: 457
Joined: Sat Apr 09, 2016 6:16 pm
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by Neemys » Sun Sep 25, 2016 11:51 am

hoho wrote:
Rseding91 wrote:Because chunk generation (entity generation) is incredibly expensive and time consuming to do. Re-doing it every time you re-load a map isn't feasible.
Yes, generating entire chunk is expensive but how much of chunk generation time is taken specifically for generating the decorations?

How feasible would it be to generate decorations on-the-fly only when player gets near enough to the chunks that they can enter their viewing area? For some added caching, store a number per chunk how often it's viewed by the local player.

Alternatively, generate decorations when they get viewed by player. I'm fairly certain that in big maps, people have more areas discovered by radars and they never get close enough to them to actually view them themselves.

Every CPU time used by decoration generation will be less CPU time for other thing, think about megabase, maybe a quarter second is nothing for a little base, but for those megabase where CPU is already a bottleneck, it's not wise to add more generation.

The generation of decoration on the fly would be too slow when teleporting you will see decoration appearing around you chunck by chunk, when running rapidly through the map, you will ask to generate more and more decoration that the game will not be able to keep up and slow a bit while it generate all chunk you asked for.
Want more space restriction ? Or maybe you want to be forced to use train for other thing than ore and oil ? Try Building Platform Mod !

Jeffman12
Burner Inserter
Burner Inserter
Posts: 7
Joined: Fri Mar 04, 2016 1:15 am
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by Jeffman12 » Sun Sep 25, 2016 2:31 pm

Zeblote wrote:
Jeffman12 wrote:Sure, it could be an option, or we could be allowed to choose the location of the save directory. I don't like that it has to be on my C drive.
You can move the folder from appdata to somewhere else. Just have to edit the settings in config-path.cfg (in the steam factorio folder) and config/config.ini (in the appdata factorio folder) to point at the new location, then move the folder itself.

The default value contains a macro (__PATH__system-write-data__) that basically means AppData/Factorio/
Cheers.

hoho
Filter Inserter
Filter Inserter
Posts: 673
Joined: Sat Jan 18, 2014 11:23 am
Contact:

Re: Friday facts #157 - We are able to eat paper, but we don't do it

Post by hoho » Sun Sep 25, 2016 4:34 pm

Neemys wrote:Every CPU time used by decoration generation will be less CPU time for other thing, think about megabase, maybe a quarter second is nothing for a little base, but for those megabase where CPU is already a bottleneck, it's not wise to add more generation.
True. It's the good-old question of CPU vs memory.

I wonder if adding the option to completely remove decorations from map (both generation and rendering) would be considered as a too radical feature.

Post Reply

Return to “News”

Who is online

Users browsing this forum: No registered users