Friday Facts #182 - Optimizations, always more optimizations

Regular reports on Factorio development.
Amuxix
Inserter
Inserter
Posts: 26
Joined: Sat Nov 26, 2016 2:21 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by Amuxix » Fri Mar 17, 2017 6:08 pm

Any chance we can have ores listed in the resources being produced? As in show ores being mined by drills in the production graphs, that way we can know if we can maintain the current consumption.

User avatar
y.petremann
Filter Inserter
Filter Inserter
Posts: 393
Joined: Mon Mar 17, 2014 4:24 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by y.petremann » Fri Mar 17, 2017 6:19 pm

The fact about the buggy cargo wagon is not something players do, but as the game is multiplayer, some peoples want to annoy others and see some server crashing. Having trains that can't be moved, removed or destroyed in some important place for the players can be really anoying.

Imagine you have a waterless world else than in the spawn point, somebody could spam the spawn point with bugged cargo wagon so you can't relly on steam engines for power.

A similar scenario is that the grieffer would connect next to his bugged cargo wagon and destroying it to crash the server and doing it again and again.

Jürgen Erhard
Filter Inserter
Filter Inserter
Posts: 266
Joined: Sun Jun 12, 2016 11:29 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by Jürgen Erhard » Fri Mar 17, 2017 6:28 pm

Wonder which parts won't get optimization love. Pessimist? As someone who unorthodoxly does all his factories (so far, I've tried to "wean" myself, but it's hopeless) with bots, hordes of bots, I like seeing these optimizations but I note not seeing anything bot-related usually.

Oh, and the very next map is already to be non-train: belts and pipes for everything (and, as is most often the case, enemy bases size to None). No train network slowdown.

userasd
Inserter
Inserter
Posts: 26
Joined: Tue Feb 07, 2017 12:48 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by userasd » Fri Mar 17, 2017 6:37 pm

After about an hour of debugging (and fixing an unrelated different bug) I fixed the problem by adding an "else" and 1 line of code that runs when building cargo wagons.
You lucky bastard! Factorio source code seems to be well written. I have spent days debugging a legacy source code to only find the bug was caused by an unsorted table.

Kane
Filter Inserter
Filter Inserter
Posts: 654
Joined: Fri Sep 05, 2014 7:34 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by Kane » Fri Mar 17, 2017 6:37 pm

Ubertwink wrote:Maybe put up unstable 0.15 releases? Just make them non-obtainable with the "latest experimental" option, only by explicit version selection.
You can easily get 15. Just wait till it's released and boom. The developers are flying people outside in to help finalize the release. Their not going to just get sloppy now because people have no patience.

aklesey1
Smart Inserter
Smart Inserter
Posts: 1642
Joined: Sun May 18, 2014 3:45 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by aklesey1 » Fri Mar 17, 2017 7:02 pm

Can we load big count of mods - i have more than 50 - in 0.15 with new optimizations?

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

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by Rseding91 » Fri Mar 17, 2017 7:57 pm

aklesey1 wrote:Can we load big count of mods - i have more than 50 - in 0.15 with new optimizations?
Mod count doesn't matter. You can have 500 if you wanted - it won't slow the game down.

Having poorly written mods is what slows the game down.
If you want to get ahold of me I'm almost always on Discord.

illmaren
Long Handed Inserter
Long Handed Inserter
Posts: 77
Joined: Mon Jun 27, 2016 3:25 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by illmaren » Fri Mar 17, 2017 8:17 pm

can´t visit the website....get a network timeout

User avatar
spicycheddar
Manual Inserter
Manual Inserter
Posts: 1
Joined: Fri Mar 17, 2017 8:17 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by spicycheddar » Fri Mar 17, 2017 8:26 pm

gacekssj4 wrote:
After about a hour of debugging
Should be "an hour"
well by god if thats the worst thing they do I'm totally cool with it

daniel34
Global Moderator
Global Moderator
Posts: 2757
Joined: Thu Dec 25, 2014 7:30 am
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by daniel34 » Fri Mar 17, 2017 9:05 pm

Ubertwink wrote:Maybe put up unstable 0.15 releases? Just make them non-obtainable with the "latest experimental" option, only by explicit version selection.
The experimental version is already unstable, that's why we also get a stable version. I think experimental version were once created by the devs to provide the newest unstable version to a small group of people who volunteered to test it and report bugs before the stable release. Nowadays new versions are so hyped that the question "when will 0.xx be released" is always met with the experimental date, without even mentioning that it's on the experimental branch. I bet that most Factorio players will start using the experimental 0.15.0 as soon as it's out instead of staying with the stable 0.14.22, except maybe those that extensively use mods. I just hope that these players will see it for what it is - an experimental version.

Adding a new unstable release cycle will just shift this problem. If Wube released an unstable now players would still want to play it and consider it an "experimental" experimental version, although in truth it might be just a nightly build that hasn't really been gone through quality control, contains lots of issues and generates useless bug reports since the bug would probably be found and fixed for experimental anyway. It takes time and resources to manage an additional release cycle which would increase the time to release the proper experimental version.

I'm also very excited to get my hands on 0.15 and test all the new features and tweaks, but I have faith in the devs that they will deliver an amazing update when it's ready, even if the first few experimental versions have some bugs. I'm realistic enough to see that they probably won't make the announced optimistic end of March date, if it's released a few weeks later I won't complain because I know that the devs worked hard on it and I'm sure it paid off.

Kane
Filter Inserter
Filter Inserter
Posts: 654
Joined: Fri Sep 05, 2014 7:34 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by Kane » Fri Mar 17, 2017 9:37 pm

Rseding91 wrote:
aklesey1 wrote:Can we load big count of mods - i have more than 50 - in 0.15 with new optimizations?
Mod count doesn't matter. You can have 500 if you wanted - it won't slow the game down.

Having poorly written mods is what slows the game down.
Thanks for this. I thought loading 100000000000000000000000000 spites would slow it down thanks for confirmation :P

Mercury044
Burner Inserter
Burner Inserter
Posts: 16
Joined: Tue Aug 04, 2015 8:21 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by Mercury044 » Fri Mar 17, 2017 9:46 pm

the train menu has killed a few worlds on me thanks for fixing it!

NonBritGit
Burner Inserter
Burner Inserter
Posts: 8
Joined: Tue Apr 07, 2015 6:12 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by NonBritGit » Fri Mar 17, 2017 9:50 pm

Ha, adding an 'else' statement reminds me of my solution to all errors: "on error, resume next" haha.

mOoEyThEcOw
Inserter
Inserter
Posts: 21
Joined: Fri Mar 17, 2017 11:27 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by mOoEyThEcOw » Fri Mar 17, 2017 11:43 pm

cpy wrote:They should've made minecraft. You'd have nearly infinite worlds with high UPS even with demanding mods.
They are very different models. Both games cheat in different ways to give the perception of a world by putting different constraints on it. I would argue that the factorio devs were simply more careful in choosing how to constrain their game. And in doing so were able to allow a very fun set of features that have good theoretical limits on their performance.

For example compare the mess of an update system that minecraft has, which enables cool things like turing complete computers, but because of how it is tied into their simulation is a major limitation on the performance it can achieve; by comparison factorio's circuit system could be compiled to native machine code because it's well designed (not relying on 3d arrays for custom rolled implementations of operators is a huge help I would bet) and nicely orthogonal to everything else. Which is a higher theoretical performance for factorio. And because things get harder the closer you get to theoretical limits, it will be easier for factorio devs to approach good performance (I would argue they basically already have), than for minecraft devs to approach their theoretical limitations (even after reaching, which I think they basically have, will still be poor performance); that is to say the factorio devs will get more for less work because they chose the design with the easier problem.

Also as to their key differences, minecraft simulates everything around a player, their performance is then per player. Factorio simulates the entire factory regardless. These are very different models, you couldn't make factorio's gameplay (constantly running factories) in minecraft's model, and in the reverse, you couldn't make minecraft's gameplay (exploring and building) in factorio's model (because the more you explore, the more simulation is required, because minecraft's gameplay relies on simulation for a lot of their environments). By choosing this route, adding more players to factorio is about getting updates to everyone, a simple networking bandwidth improvment, where as minecraft requires more memory, cpu, *and* networking bandwidth for each player because each player will be causing different parts of the world to update. On the other hand, it's possible for minecraft devs to shard their server design across many machines (different update regions run on different machines, with the existing file system sync system) more easily than it is for the factorio devs (they would have to build a system for different servers to communicate at the boundaries of their constantly updating world, a problem minecraft doesn't have).

Kane
Filter Inserter
Filter Inserter
Posts: 654
Joined: Fri Sep 05, 2014 7:34 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by Kane » Sat Mar 18, 2017 12:02 am

mOoEyThEcOw wrote:
cpy wrote:They should've made minecraft. You'd have nearly infinite worlds with high UPS even with demanding mods.
They are very different models. Both games cheat in different ways to give the perception of a world by putting different constraints on it. I would argue that the factorio devs were simply more careful in choosing how to constrain their game. And in doing so were able to allow a very fun set of features that have good theoretical limits on their performance.

For example compare the mess of an update system that minecraft has, which enables cool things like turing complete computers, but because of how it is tied into their simulation is a major limitation on the performance it can achieve; by comparison factorio's circuit system could be compiled to native machine code because it's well designed (not relying on 3d arrays for custom rolled implementations of operators) and nicely orthogonal to everything else. Which is a higher theoretical performance for factorio. And because things get harder the closer you get to theoretical limits, it will be easier for factorio devs to approach good performance (I would argue they basically already have), than for minecraft devs to approach their theoretical limitations; that is to say the factorio devs will get more for less work.

Also as to their key differences, minecraft simulates everything around a player, their performance is then per player. Factorio simulates the entire factory regardless. These are very different models, you couldn't make factorio's gameplay in minecraft's model (and vice-versa). By choosing this route, adding more players to factorio is about getting updates to everyone, a simple networking bandwidth improvment, where as minecraft requires more memory and cpu for each player because each player will be causing different parts of the world to update. On the other hand, it's possible for minecraft devs to shard their server design across many machines much more easily than it is for the factorio devs.
I know if the Devs here did Minecraft would been a lot better tbh. FortressCraft Evolved is actually quite optimized I think you can have about 250,000 or so tileentities without too many issues. That is done not only in Unity3D but a single programmer. Different techniques can make a massive diffrence. The biggest issue with Minecraft is the way it's written from the core up. There is no real easy way to replace the core.

Minecraft C++ Version also has proven INSANE amount of performance enhancements and speeds of that of its java version.

New World:
http://i.imgur.com/TPxwgI0.gifv

Also 255 Chunk Render Distance:
https://gfycat.com/FirstFrankKoodoo

mOoEyThEcOw
Inserter
Inserter
Posts: 21
Joined: Fri Mar 17, 2017 11:27 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by mOoEyThEcOw » Sat Mar 18, 2017 12:14 am

Kane wrote:
Different techniques can make a massive diffrence. The biggest issue with Minecraft is the way it's written from the core up. There is no real easy way to replace the core.

Minecraft C++ Version also has proven INSANE amount of performance enhancements and speeds of that of its java version.
Not sure what your point is. Of course techniques matter. But what decides the maximum possible is the constraints you place on the system with the design decisions you choose. The design of minecraft's core is poorly chosen, even when they push it to the maxium possible - with the best techniques - they are going to hit the consequences of those constraints at some point. Yea, rewriting minecraft in a natively compiled programming language, removing mod support, and not supporting problematic features is going to make it faster... but they have not just used better techniques, but also modified some of the constraints by changing the design.

DutchJer
Long Handed Inserter
Long Handed Inserter
Posts: 65
Joined: Sat Feb 13, 2016 8:43 am

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by DutchJer » Sat Mar 18, 2017 12:46 am

Well done rseding. Finding the places where there is room for improvement is hard. I know. Im a developer working with electric cars and our internal dashboard has some crappy programming in some places. Changing the queries improves a lot on our loading times. From 60 seconds to 2 seconds. Keep up the good work! I will continue streaming when 0.15 hits!

boksiora
Long Handed Inserter
Long Handed Inserter
Posts: 90
Joined: Thu Mar 10, 2016 7:45 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by boksiora » Sat Mar 18, 2017 1:43 am

Maybe look how Factorisiimo mod works

Even on a mega base this mod supports a lot of buildings and does not recude fps

I see the mod makes every factorsimo building a different "surface" which i assume is not rendered and thats why it keeps the FPS from falling down

aober93
Filter Inserter
Filter Inserter
Posts: 445
Joined: Tue Aug 30, 2016 9:07 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by aober93 » Sat Mar 18, 2017 3:11 am

That bug reconstruction isnt so far fetched as some here think. As it coincidentally happened today i was able to manually place 2 trains inside each other by mysterious ways. And then still added cargo waggons. The way you described the bug, the end result was just the same albeit my waggons strangly jittered around. Anyway this and yours didnt crash my game.

User avatar
Drury
Filter Inserter
Filter Inserter
Posts: 679
Joined: Tue Mar 25, 2014 8:01 pm
Contact:

Re: Friday Facts #182 - Optimizations, always more optimizations

Post by Drury » Sat Mar 18, 2017 5:53 am

torham wrote:
cpy wrote:They should've made minecraft. You'd have nearly infinite worlds with high UPS even with demanding mods.
This.

I think Factorio is the best optimized game on my HDD right now. Its a whole different category compared to some garbage that gets published these days.One example would be Rise to ruin. Its pixel retro style that in the 1994 would easily run on my 486 with 512 KB RAM, and it runs around 30 FPS on my current gaming rig.
Yeah, it breaks my heart too. It's not even hard - as a code illiterate Unity scrub, all of my shitty rushed jam games run on my integrated graphics laptop without hiccups, and I didn't use any amazing tricks to achieve that. You just uncheck a few useless boxes - I mean you're not gonna need any sort of lighting pipeline running for a pixel game! That and just avoiding doing dumb things like destroying and creating the same objects rather than reusing them (not completely off-topic now since Rsending talks about this exact thing in the blogpost as well). What's sad is that this isn't true not only for my competitors in those fast game jams, but also actual games that you pay money for.

They're amateur indies but still... I'd be ashamed to ask money for a pixel game that a modern PC can't run, even if it doesn't have dedicated gfx. Didn't their moms teach them to tidy up their code after they're done playing with it?
Image

Post Reply

Return to “News”

Who is online

Users browsing this forum: bobucles