Friday facts #157 - We are able to eat paper, but we don't do it
Re: Friday facts #157 - We are able to eat paper, but we don't do it
three years of FFF already!
no yes yes no yes no yes yes
Re: Friday facts #157 - We are able to eat paper, but we don't do it
You can never optimize too much. If 1000 people can play at once with high frame rate, then one player can build 1000x larger (not really, but you get the point)
Re: Friday facts #157 - We are able to eat paper, but we don't do it
MFW multithreading:
and it's only been 3 years since then.kovarex wrote:How fast exactly? What fps do you have? (When you hit F5, it should be in the top right corner)Beichtvater wrote:I just wanted to say that the game goes too fast, like the old DOS/win95-98 games that you want to run on the new powerful computers.
About two or three times faster than it should be.
I will be honest, the game speed is determined by the refresh rate of display (yes lame, but this is temporary solution), until we do multithreading.
Multithreading will not only let us set the game speed more properly, it will also allow having MUCH larger factories without lag.
Beichtvater wrote: Only after 40 hours of play, having created huge (for a week of days of traveling) a railway system, being in the middle of the huge city, speed is normalized. But once you depart a little, and everything is again accelerated.
This is a joke, I don't mean to criticise kovarex and the amazing thing he and now also the team are creating, I love the game.
Re: Friday facts #157 - We are able to eat paper, but we don't do it
WOW liquid wagon and pump looks AWESOME!
I am glad you are changing the decorations. The mod to remove them was made as a response to my not a bug report "Save file size increased ~5 times"] because the save file size was ridiculous on bigger maps.
I am glad you are changing the decorations. The mod to remove them was made as a response to my not a bug report "Save file size increased ~5 times"] because the save file size was ridiculous on bigger maps.
Last edited by madpav3l on Fri Sep 23, 2016 6:14 pm, edited 1 time in total.
- aubergine18
- 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
Decorations:
For the map decorations in 0.15, when they've been changed to a much more basic form, will there still be some way for mod script to determine what decoration exists on a certain tile, even if just a list of decoration names (without position, as the tile x,y is already known when calling the method to list them)?
I'm making a mod that allows foraging of decorations for food and other items, and it would be a shame if there's no way to identify them via the Lua API in future :/
Rail tank filling:
It looks awesome, although it makes me instantly want the option to fill each third of the tanker with different fluid, which obviously it can't do.
Would a better approach be to have some sort of movable frame, like a cargo frame, that has single fluid connection and can move along the tanker carriage stopping at each fill point to fill it? In particular, there would be far, far fewer sprites required, because essentially you'd just be moving one mostly-static sprite along an axis, maybe with reversible animation (as separate sprite) of pipe going down to meet tanker fill hole when it reasches one.
For the map decorations in 0.15, when they've been changed to a much more basic form, will there still be some way for mod script to determine what decoration exists on a certain tile, even if just a list of decoration names (without position, as the tile x,y is already known when calling the method to list them)?
I'm making a mod that allows foraging of decorations for food and other items, and it would be a shame if there's no way to identify them via the Lua API in future :/
Rail tank filling:
It looks awesome, although it makes me instantly want the option to fill each third of the tanker with different fluid, which obviously it can't do.
Would a better approach be to have some sort of movable frame, like a cargo frame, that has single fluid connection and can move along the tanker carriage stopping at each fill point to fill it? In particular, there would be far, far fewer sprites required, because essentially you'd just be moving one mostly-static sprite along an axis, maybe with reversible animation (as separate sprite) of pipe going down to meet tanker fill hole when it reasches one.
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.
Re: Friday facts #157 - We are able to eat paper, but we don't do it
IMO aim for tops around 100 players optimization. That way 50 players (which I think is still a lot) should have an excellent experience.
Is more than 100 really a way people will play the game other than for a fun experiment?
Is more than 100 really a way people will play the game other than for a fun experiment?
Re: Friday facts #157 - We are able to eat paper, but we don't do it
When I first heard about MP support I imagined having half a dozen people would be a lot in a game like this.
Seeing 350 people in a game is just insane. Are there *any* real time non-MMO games that support that many players without imploding? IIRC FPS'es top out at around 64. Minecraft with a few dozen people needs a server farm to run.
Hats off.
Factorio has been THE most impressive gaming experience I've had in my 31y life and I've spent more time playing than I'd like to admit.
I've watched most of the megagame streams and seeing devs listen to the community and communicate back has been pure awesomeness. I can't think of *any* other game where devs would have anywhere near as good relationship with their community.
Seeing 350 people in a game is just insane. Are there *any* real time non-MMO games that support that many players without imploding? IIRC FPS'es top out at around 64. Minecraft with a few dozen people needs a server farm to run.
Hats off.
Factorio has been THE most impressive gaming experience I've had in my 31y life and I've spent more time playing than I'd like to admit.
I've watched most of the megagame streams and seeing devs listen to the community and communicate back has been pure awesomeness. I can't think of *any* other game where devs would have anywhere near as good relationship with their community.
Re: Friday facts #157 - We are able to eat paper, but we don't do it
I think you should optimize, but in the right areas. If more than say 50 people were playing a game it would go by really fast. The factory would get so massive it would lag and it wouldn't be a fun experience IMO. So i think that 300+ people in Factorio is just stupid and maybe a fun experiment. Focus on other areas of the game. I think you did a good job at MP optimization and are making a great game overall. Keep up the good work.
Blazku
Blazku
Re: Friday facts #157 - We are able to eat paper, but we don't do it
Thanks for mentioning the undecorator mod. Our 88MB map drops to 29MB when I use it. Seeing as we're going to concrete over most of it anyway, I think we'll take the loss of the decorations.
Re: Friday facts #157 - We are able to eat paper, but we don't do it
You weren't kidding about decarative entities! I installed the mod you linked, and our save went from 80MB to 39.
-
- Inserter
- Posts: 43
- Joined: Mon Jul 25, 2016 11:12 pm
- Contact:
Re: Friday facts #157 - We are able to eat paper, but we don't do it
Ratzap, that's a good question. Are concrete tiles entities or decorations?
If they're entities, maybe Factorio could use the same "not a full entity" optimization for brick/concrete in 0.15 to reduce map size and speed up computation when you've concreted vast swatches of paved space.
If they're entities, maybe Factorio could use the same "not a full entity" optimization for brick/concrete in 0.15 to reduce map size and speed up computation when you've concreted vast swatches of paved space.
-
- Burner Inserter
- Posts: 7
- Joined: Sat Sep 17, 2016 8:24 am
- Contact:
Re: Friday facts #157 - We are able to eat paper, but we don't do it
When I hear about the trains problems I laught every time those are the kind of little decisions that makes my programs very much complicated than they should.
About the multiplayer, it is indeed good as it is, maybe in a far future could be improved even more but...there's actually no ush i believe.
About the multiplayer, it is indeed good as it is, maybe in a far future could be improved even more but...there's actually no ush i believe.
Re: Friday facts #157 - We are able to eat paper, but we don't do it
They're neither. They're tiles.Radioactive Pretzels wrote:Ratzap, that's a good question. Are concrete tiles entities or decorations?
If they're entities, maybe Factorio could use the same "not a full entity" optimization for brick/concrete in 0.15 to reduce map size and speed up computation when you've concreted vast swatches of paved space.
If you want to get ahold of me I'm almost always on Discord.
Re: Friday facts #157 - We are able to eat paper, but we don't do it
please please please do the pump as a new entity and keep the old one
- trad_emark
- Inserter
- Posts: 34
- Joined: Fri Sep 23, 2016 8:54 pm
- Contact:
Re: Friday facts #157 - We are able to eat paper, but we don't do it
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.
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.
-
- Fast Inserter
- Posts: 207
- 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
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.
Unless maybe they were regenerated according to the seed every time? They are indestructible afaik, so that shouldn't be an issue.
Unless maybe they were regenerated according to the seed every time? They are indestructible afaik, so that shouldn't be an issue.
-
- Fast Inserter
- Posts: 121
- Joined: Tue Jul 14, 2015 10:57 pm
- Contact:
Re: Friday facts #157 - We are able to eat paper, but we don't do it
I suspect that's exactly what they're doing. 3 tanks so you need 3 pumps to fill them. Maybe ship all 3 types from an oil refinery in one tank.aubergine18 wrote:It looks awesome, although it makes me instantly want the option to fill each third of the tanker with different fluid, which obviously it can't do.
Besides being less interesting in general, it wouldn't look right if the tanks really are separate and the gantry only moved over one of them. It would actually be static.aubergine18 wrote:Would a better approach be to have some sort of movable frame, like a cargo frame, that has single fluid connection and can move along the tanker carriage stopping at each fill point to fill it? In particular, there would be far, far fewer sprites required, because essentially you'd just be moving one mostly-static sprite along an axis, maybe with reversible animation (as separate sprite) of pipe going down to meet tanker fill hole when it reasches one.
-
- Fast Inserter
- Posts: 121
- Joined: Tue Jul 14, 2015 10:57 pm
- Contact:
Re: Friday facts #157 - We are able to eat paper, but we don't do it
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.
Decorates are removed when you place belts (and probably other things), so they do need to be tracked.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.
Unless maybe they were regenerated according to the seed every time? They are indestructible afaik, so that shouldn't be an issue.
- aubergine18
- 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
Maybe, but the gantry could also be used for loading/unloading cargo containers without too much effort (essentially replace the up/down pipe on the gantry with "grabbers" that clasp the container). It would be very fast (and not much animation effort I presume) to move a container off train and put another one in its place. Containers could feasibly be moved, eg. put them on belts, to a location where they are unloaded/loaded, and then moved back to station to be put on next train, etc.Rhamphoryncus wrote:Besides being less interesting in general, it wouldn't look right if the tanks really are separate and the gantry only moved over one of them. It would actually be static.
I agree, it would look weird if all the decorations kept randomly changing.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.
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.