Friday Facts #182 - Optimizations, always more optimizations
Re: Friday Facts #182 - Optimizations, always more optimizations
I like Minecraft. Bought it back in beta. And if it didn't take more resources than freaking fallout 4, I would happily play it to this day
And Drury: I did say there was a reason I'd been putting off the upgrade
And Drury: I did say there was a reason I'd been putting off the upgrade
-
- Manual Inserter
- Posts: 3
- Joined: Wed Mar 22, 2017 1:40 am
- Contact:
Re: Friday Facts #182 - Optimizations, always more optimizations
Don't want to say too much but I spent so much longer in Minecraft than Factorio before losing my creative streak, although with a significant number of automation related mods may I add...Kane wrote:You telling me you rather have Minecraft then Factorio...? There would not be both it would been one or the other.
But if the Factorio devs made Minecraft then it'd have been made to their specifications, all the cool stuff, the trains and things would be in Minecraft by default, would work and would be in 3D... Why would you not want 3D, working, super cool Factorio with big ass trains towering over you as they speed past delivering tonnes of rock to huge factories! Basically a wet dream!
Although i'd seriously pity Mr Potato 'Puter...
- StoneLegion
- Filter Inserter
- Posts: 687
- Joined: Fri Sep 05, 2014 7:34 pm
- Contact:
Re: Friday Facts #182 - Optimizations, always more optimizations
Why would of there be trains or factorio. Since their visions came from things like modded Minecraft, etc. Without Minecraft the chances are they would been more Vanilla Minecraft. You have to see the actual true impact.Bigbigcheese wrote:Don't want to say too much but I spent so much longer in Minecraft than Factorio before losing my creative streak, although with a significant number of automation related mods may I add...Kane wrote:You telling me you rather have Minecraft then Factorio...? There would not be both it would been one or the other.
But if the Factorio devs made Minecraft then it'd have been made to their specifications, all the cool stuff, the trains and things would be in Minecraft by default, would work and would be in 3D... Why would you not want 3D, working, super cool Factorio with big ass trains towering over you as they speed past delivering tonnes of rock to huge factories! Basically a wet dream!
Although i'd seriously pity Mr Potato 'Puter...
Re: Friday Facts #182 - Optimizations, always more optimizations
I had this terrible idea of new vehicles for 0.16, like Truck-Trailers (or Tractor-Trailers, or maybe just trailers for your car) as an earlier alternative to trains (I've built car loading/unloading ports before, mainly for barreled oil, and solar stuff to take out and transfer to logistics storage and then build), perhaps a "road" item similar to "train tracks" so you can set up routes and stations as well as routes you can set up.
Both messages have been sponsored by the Department of Redundancy Department, thank you!I still have some additional ideas to improve the performance of this GUI but it's at least manageable now for 0.15 it's manageable.
Doctor, doctor, I have a condition, it's TRUE!
Re: Friday Facts #182 - Optimizations, always more optimizations
Guys. I'd like to report a bug where the versioning number has an incorrect decimal placement. The decimal should be moved one spot to the right.
- aRatNamedSammy
- Fast Inserter
- Posts: 216
- Joined: Tue Jul 08, 2014 4:26 pm
- Contact:
Re: Friday Facts #182 - Optimizations, always more optimizations
that is what many games doesnt have... optimization! quality!
I still continue to wait patiently for your piece of pure gold!
WUBE ROCKS
I still continue to wait patiently for your piece of pure gold!
WUBE ROCKS
Teeth for Two (so sorry my bad english)
-
- Long Handed Inserter
- Posts: 62
- Joined: Tue Jun 21, 2016 9:59 am
- Contact:
Re: Friday Facts #182 - Optimizations, always more optimizations
I'll be on vacation next week.
So... please release 0.15 tomorrow.
Sincerely, MaexxDesign
So... please release 0.15 tomorrow.
Sincerely, MaexxDesign
Re: Friday Facts #182 - Optimizations, always more optimizations
I've always thought it'd be cool to have a sort of earlygame logistics robots that don't fly. Some sort of self-driving trucks that drive between truck stops.jackd23 wrote:I had this terrible idea of new vehicles for 0.16, like Truck-Trailers (or Tractor-Trailers, or maybe just trailers for your car) as an earlier alternative to trains (I've built car loading/unloading ports before, mainly for barreled oil, and solar stuff to take out and transfer to logistics storage and then build), perhaps a "road" item similar to "train tracks" so you can set up routes and stations as well as routes you can set up.
Having to build roads for them would make them a bit too much like trains I think. The benefit would be not having to build much infrastructure for them, just letting them drive across vast distances. Useful for quick outposts with a small resource output.
Re: Friday Facts #182 - Optimizations, always more optimizations
I would rather have a FactorioCraft. The best of both worlds combined.Kane wrote:You telling me you rather have Minecraft then Factorio...? There would not be both it would been one or the other.
Re: Friday Facts #182 - Optimizations, always more optimizations
2 dimensionality is an essential part of Factorio's logistic challenge. If there was possibility to lay inserters and transport belts in 3 dimensions, the logistics would be trivial and boring. Much like bot logistics, which I do not like. They could make recipes more complex but then planning would become too difficult and laborious. In real world planning of even small factory takes huge number of professional engineer's work hours. I think that balancing of 3D factory would be a very difficult task and results would probably not be very entertaining. Especially for casual players.Bigbigcheese wrote:But if the Factorio devs made Minecraft then it'd have been made to their specifications, all the cool stuff, the trains and things would be in Minecraft by default, would work and would be in 3D... Why would you not want 3D, working, super cool Factorio with big ass trains towering over you as they speed past delivering tonnes of rock to huge factories! Basically a wet dream!
Computing power would be another problem. If there were interesting animated entities instead of boring minecraft style cubes, polygon number would explode to insanity and no consumer computer or graphics card could handle even medium sized factory with couple of thousands of entities. Programming would also need special skills which are rare in game development teams, like effective use of multithreading capabilities.
But yes, 3d Factorio able to run huge factories and somewhat realistic train traffic between them and ability to fly with a helicopter and see the whole main base with thousands of assemblers and inserters and kilometers of 3D belt spaghetti would be wet dream for me too.
Re: Friday Facts #182 - Optimizations, always more optimizations
Will the GUI tweaks include things such as the modular armor grid and logistics chests?
Maybe you won't notice it in single player, but in large multiplayer mega-factories where my cpu seems to struggle (despite saving the same map and having zero problems with the mega-factory locally), when I open the grid for my mk2 armor, my UPS drops and struggles to come back until I'm out of that interface. The same happens when hovering over logistics chests.
Maybe you won't notice it in single player, but in large multiplayer mega-factories where my cpu seems to struggle (despite saving the same map and having zero problems with the mega-factory locally), when I open the grid for my mk2 armor, my UPS drops and struggles to come back until I'm out of that interface. The same happens when hovering over logistics chests.
Re: Friday Facts #182 - Optimizations, always more optimizations
Perf suggestion:
When constructing or deconstructing tracks, batch the actual placement/removal of the track entities to only occur once per x (~30) frames.
This should limit the super-costly large train network recalculations to appear far less hitchy.
(Alternatively wait until all scheduled construction bots targeting tracks have arrived to batch them up; though this may or may not make sense depending on how bot scheduling is managed.)
When constructing or deconstructing tracks, batch the actual placement/removal of the track entities to only occur once per x (~30) frames.
This should limit the super-costly large train network recalculations to appear far less hitchy.
(Alternatively wait until all scheduled construction bots targeting tracks have arrived to batch them up; though this may or may not make sense depending on how bot scheduling is managed.)
Re: Friday Facts #182 - Optimizations, always more optimizations
Constructing or deconstructing tracks should not need any train network recalculations except for a few cases:alingis wrote:Perf suggestion:
When constructing or deconstructing tracks, batch the actual placement/removal of the track entities to only occur once per x (~30) frames.
This should limit the super-costly large train network recalculations to appear far less hitchy.
(Alternatively wait until all scheduled construction bots targeting tracks have arrived to batch them up; though this may or may not make sense depending on how bot scheduling is managed.)
1. trains or cars get placed or removed (if it's the first/last train/car in a block)
2. 2 blocks are joined by placing a new track or removing a signal
3. a block is split in two by removing a track or placing a signal
Re: Friday Facts #182 - Optimizations, always more optimizations
If you store a map of depot -> distance on each exit from a block, pathfinding trough a graph becomes both guaranteed optimal and O(1) (with almost-free fixed cost), at the cost of having to broadcast trough the entire train network block by block when depots are added or removed, and parts of it when the logical structure changes. If you want to check the entire route, O(1) becomes O(average distance to next depot on train schedule).bulldog98 wrote:They use the A* algorithm which is normally algoritmically fast, but only gives approximate optimal results, since pathfinding is NP hard. And solving NP hard problems exact can take exponential time.PacifyerGrey wrote:If you have a loop at every intersection it should multiply available paths exponentially based on the number of intersections you will meet on the way.Rseding91 wrote:Single sided, double sided, a big train, a small one, loop-based or no loops makes no difference in the games performance. They're all the same.
I have no idea where people get these ideas from but they're all false.
I am not sure how the pathfinding in factorio works but generally in many-to-many lists the search tree works mostly the same. Loop-free design prevents the search tree from growing and should perform better.
Correct me if I am wrong.
But maybe the process of path finding is so fast anyways that it will not impact game performance at all as it actually runs pretty rarely.
Re: Friday Facts #182 - Optimizations, always more optimizations
The issue is that the developers want a load balanced rail network where the trains take into account congestion. Add into that the ability to have stops with the same name, alternate paths like the ones you get in rail stackers, etc and you quickly find that a preprocessed graph does not work.Karamel wrote:If you store a map of depot -> distance on each exit from a block, pathfinding trough a graph becomes both guaranteed optimal and O(1) (with almost-free fixed cost), at the cost of having to broadcast trough the entire train network block by block when depots are added or removed, and parts of it when the logical structure changes. If you want to check the entire route, O(1) becomes O(average distance to next depot on train schedule).bulldog98 wrote:They use the A* algorithm which is normally algoritmically fast, but only gives approximate optimal results, since pathfinding is NP hard. And solving NP hard problems exact can take exponential time.PacifyerGrey wrote:If you have a loop at every intersection it should multiply available paths exponentially based on the number of intersections you will meet on the way.Rseding91 wrote:Single sided, double sided, a big train, a small one, loop-based or no loops makes no difference in the games performance. They're all the same.
I have no idea where people get these ideas from but they're all false.
I am not sure how the pathfinding in factorio works but generally in many-to-many lists the search tree works mostly the same. Loop-free design prevents the search tree from growing and should perform better.
Correct me if I am wrong.
But maybe the process of path finding is so fast anyways that it will not impact game performance at all as it actually runs pretty rarely.
The issue isn't with A*, but our computers: They are becoming less and less general purpose machines.