Friday Facts #182 - Optimizations, always more optimizations

[Amuxix]

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.

[y.petremann]

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]

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]

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.

[StoneLegion]

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]

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

[Rseding91]

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.

[illmaren]

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

[spicycheddar]

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]

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.

[StoneLegion]

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

[Mercury044]

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

[NonBritGit]

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

[mOoEyThEcOw]

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

[StoneLegion]

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]

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]

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]

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]

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.

[Drury]

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?