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

[chris13524]

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

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

[devilwarriors]

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]

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

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]

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]

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]

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.

[Mengmoshu]

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]

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]

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]

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

[Rseding91]

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.

[Neemys]

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 :

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.

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

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.

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.

[poma]

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.

[aubergine18]

Maybe just generate decoratives randomly from the same random seed?

That's still essentially chunk generation. See viewtopic.php?p=209782#p209782

[hoho]

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]

finding lag issues on 55MB map, i like to explore the infinity but... lagses

[kinnom]

finding lag issues on 55MB map, i like to explore the infinity but... lagses

use undecorator and/or upgrade your computer

[Neemys]

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.

[Jeffman12]

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]

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.