![Razz :P](./images/smilies/icon_razz.gif)
And Drury: I did say there was a reason I'd been putting off the upgrade
![Razz :P](./images/smilies/icon_razz.gif)
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.
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...
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.
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.
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.
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!
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.)
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 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.