Friday Facts #331 - 0.18.0 release & Train pathfinder changes

[bobingabout]

It is a massive hassle for the mod developers to manually update the mods from 0.18 -> 0.19 -> 0.20
Rather than just a few mod developers have a fix a few things from say 0.18.10 -> 0.18.11

However note how strange will that be if a mod claims to be 0.18-compatible, yet doesn't work with the most recent 0.18.x release, because it is - in fact - compatible only with 0.18.(x-1) and earlier (;

This is why breaking changes (if any) are intended to happen only before first 0.18 stable

(btw, PL?)

Yes, we had 2 or 3 of those in 0.17 run. As long as they're small, and the release notes document the changes (And I would include changes in recipe here, even simply saying that the recipe was changed), then your current scheme is good enough for me.

My opinion is that you're all doing a good job overall.

[nafira]

@boskid : it's quite a huge change you made. Even I'm not able to say it's for the worst or the best (internally I'm thinking it's not binary), it's still a huge change. Many megabases or servers will break or thrive due to this changes.

Have you warned modders in advance, because it's quite not expected at this stage ?
It's very unexpected even for a simple player as me.

[boskid]

@boskid : it's quite a huge change you made. Even I'm not able to say it's for the worst or the best (internally I'm thinking it's not binary), it's still a huge change. Many megabases or servers will break or thrive due to this changes.

Have you warned modders in advance, because it's quite not expected at this stage ?
It's very unexpected even for a simple player as me.

From what i tested, primary thing that breaks some existing maps is fix for opposite station in last segment if maps are fragile to penalty changes and use train stops on both ends of single segment. Other fixes can also break existing saves but i do not care since they were inconsistent with written rules for penalty system. Fixes were required because without them heuristic would not be consistent - heuristic could say "this node is at least 30 units of penalty from goal" but last segment would not be added so heuristic would overestimate and pathfinder could choose other path that would be different when searching without heuristic.

And this changes were not that huge.
Doing some small fixes on existing map is cost i can take if pathfinder performance increases a lot.

[Drury]

So it's essentially just down to graphical improvements from now on. Those have been quite hit and miss lately, to be completely honest.

The campaign could have been potentially interesting, potentially redundant, we won't get to see now I suppose. What I foremostly had high hopes for though, was the improved fluid physics, but with that out of the window too... See you all in September.

[Locane]

I love Factorio, I love Wube and your FFs but I find it not appropriate to describe Dominik's departure in the way you did it. I trust your decisions, we all sometimes have to make hard choices but revealing too much detail is not always good.

I love the transparency Klonan, but have to agree; there had to be a better way to communicate it. Now I don't know who was right; maybe Dominik's work was brilliant and you're a tyrant. Maybe he was a loose cannon and his work was awful. None of us will ever know for sure, but now we're wondering more than we normally would. At least, I am.

I also want to voice my disappointment in the campaign cancellation - I would really like to see something story-wise come to life after 1.0.

Primarily I think factorio has a somber and almost disappointed tone to it that is unique and feels right (and good) somehow. I'd love to see that woven in to a narrative of survival of the fittest, with more than just basic bugs robotically throwing themselves at defenses:

A human crash lands on a hostile alien planet and has to exploit its resources to survive and escape - they're not happy about destroying everything, but it's that or die; so self-preservation it is.

There's a lot of potential there.

In any case, thank you for taking the helm and doing more frequent updates, I've been excited about the things talked about in FFF for months!

[Locane]

Addendum: personally, I think you're spending too much time on trains. Could be my play style, but I couldn't care less if they're very slightly more efficient; if I had been running things I'd have scrapped most of the train functionality for a more simplistic approach to work on other more important things.

One thing I definitely think could use efficiency improvement is logistics and construction bots priority - when you're in a near-endgame base it can take them minutes to bring you items up through a roboport chain, or to replace / repair a broken a turret or wall, or to build a blueprint you've set down.

It's never clear whether your personal construction bots are going to do a task, or whether some other far-off bot in a roboport thousands of units away will "claim" it and make you wait.

[DaveMcW]

Addendum: personally, I think you're spending too much time on trains. Could be my play style, but I couldn't care less if they're very slightly more efficient; if I had been running things I'd have scrapped most of the train functionality for a more simplistic approach to work on other more important things.

Trains get featured in FFFs because it's easy to make pretty pictures of them. 0.18 improved efficiency in many places, but it's hard to understand what changed unless you know computer programming.

[conn11]

Just to note. I did run into performance issues shortly prior 0.18. With my aging i7 4930k, some crappy DDR3 RAM and a GTX 780 (wich I replaced in the meantime) and a base (rather train &belt heavy, <10 mods, nuclear powered) doing science and therefore triggering frequenter biter attacks, UPS/FPS dropped even below 30.
In 0.18 I‘m at a stable 40ish UPS only dropping in the 30-region after extensively playing around with the updated MIRV mod.
Well done!

[PSS]

Old campagin was good (3 demo missions + 5 or so "normal" missions). My factorio experience started with this missions. And it didn't affect my style of playing Freeplay. Lerning Factorio by scripted missions is fun. You should add it back.

[R3vo]

The new main menu looks and feels awesome. Way more intuitive than before. Good job!

One thing I definitely think could use efficiency improvement is logistics and construction bots priority - when you're in a near-endgame base it can take them minutes to bring you items up through a roboport chain, or to replace / repair a broken a turret or wall, or to build a blueprint you've set down.

I totally agree. Would be nice if once I requested some items via personal logistics it would show an ETA.

[Lubricus]

I'm quite concerned that the new fluid mechanics won't be making it into 1.0 (or even at all?). Currently, fluids are definitely the most under-developed part of the game. They're quite unwieldy, hard to read and plan about, hard to use, hard to debug, and just unpleasant overall. Transporting the water for any size of nuclear reactor that works at full capacity is such a chore that the only courses of action are either to spam pumps or build it in the middle of a lake to begin with. As they stand, the current fluid mechanics personally don't feel worthy of a 1.0 release.

This Friday Facts is the bleakest I've ever read. All plans for a Campaign completely scratched, features being delayed, and a team member suddenly quitting. And it really really sounds like Dominik left on bad terms. It sounds like you're blaming him for the character GUI not working out, and that he quit out of frustration. You said that's not what you meant, and that he left on good terms, but that's the complete opposite of how the original statement reads.

All in all, I hope 1.0 will turn out okay despite all complications, and that Dominik is happy on his future projects. This game is incredible and so are its developers, and I've always felt that they could have branded the game as 1.0 months or years ago. But I trust their vision. Good luck, and I hope my comment is considered.

I think it's good (gameplay) that big nuclear plants only is viable close to water. And real nuclear plants is built at the coastlines so they can be cooled.
Said that I also think fluids should be reworked. It's not that important, fluid works fine in reasonable sized vanilla factories it's when you push the limit of pipe throughput when the not so good properties comes up.
I use as many underground as possible. Undergrounds get better UPS and throughput and I can walk over them, then I have almost no windows on the pipes and the visibility on what's going on is almost zero.
So a simple fix to make pipes better for new players just launching a rocket could be as easy to make it possible to walk over them so windowed pipes is more viable.
For a big rework I think they have to change the flow to something similar to a closed pipe flow instead of the current algoritm that is more similar to an open channel flow. That could both be more realistic and possible to implement in a more efficient way.

[Pompeij]

Nice!

I didn't even notice, that Steam switched factorio to none beta

I didn't see mod loading changes on the to do list, wasn't there the idea of loading mods on map load instead of game load? That would be great, as I play on multiple Servers with different mods.

Greetings Pompeij

[exi2163]

From what I understand it was a perfectly amicable decision, he was happy and relieved, optimistic about new projects for him to work on, and that mostly he feels bad about leaving us at the last minute, but that he decided it was the best for everyone

Wow, okay, that paints an entirely different picture than the post. Not even sure there is a possible interpretation from the FFF that matches your comment. The FFF basically says:

- We delayed .18 twice already
- After reviewing the work done so far, we had to throw most of it out
- Then we kicked the developer off of that project and just started over with another one
- After replacing him and throwing away his code, he quit his job (implying this was all against his will)

And after he was kicked out for doing a bad job you also wanted to tell the world about it, or so it sounds like.

..

I'm sorry but i did not read that from the FFF. If you are the sole maintainer of a specific codebranch it kinda becomes your "precious". A vote of no confidence because all the hard work you did was perhaps a bit in the wrong direction and does not went towards the goal of the mission is devastating. Beeing asked to do something else is a good way even if you dont like it as a developer because you tend to get blind for doing the same thing for a long time. However, seeing all your work beeing send to the shredder is a good reason to quit. You might say it has to do with rage but it doesn't. After all you worked hard for the result but for example developing a sportscar if your company needs a truck is something that might happen if the requirements have changed. There is nothing wrong with the sportscar you made. Just letting it beeing shoved into the trash could mean you dont value your own work (which you do). Also you might think that in your new position you cannot give the company your best and therefore look for new horizons.
Management wise its the only good way. You stop the project you dont need and reassign the workforce to keep the talent in your company and put them to best use.
Noone did anything wrong but it stil might not work out for both partys.
It might not be easy understandable for people who never coded for projects involving many people. It is REALLY hard to let your work go into the bin even if it brings the project forward or just by seeing it changed by somebody. If you dont believe me have a look at the mods licenses. A lot of them forbid derivative works and this is one of the reasons (which is no problem as long as the mod is not abandoned, Angels and Bobs are very good examples of beeing run by caring maintainers).

On the rails stuff: Yes. I like be pictures

For the campaign... when i play RTS games i really loved missions that expanded on the original battlefield. It puts some strain on the devs to make sure you dont end up in unwinnable situations but if you really fucked up you just might have to reload a save.
How about using both? Some levels that expand on certain things and other that just start fresh. You could also start the player in a working factory to fix a few things so you can leave in the rocket.... just to crash onto a planet again a few seconds later (because you forgot to start the satellite for navigational data streaming). This would present the player the goal of the game and then shows him how to get there himself. Unfortunatly compilatrons database was damaged during the crash so all structural component data memory has been lost (eg: all research).
So you start fresh, build a starter base, the map expands, you find a derelict oil post and bring it back to life...
At some point you could get to the conclusion that a certain material is not available (or not enough of it) in the near vicinity, hack together a vehicle and drive to the next level. An expanded level might bring the biters in so you have to make a strategic retreat to build a fortified base and defend against attacks.

[NelsonSKA]

When I started to play, for first time, I began with the (old) tutorial.
In some way was very difficult to me, I spend a lot of hours in one of the scenarios, (i don't rememer which one but i think it was the thirth) but I hooked with the game.
Later I went to the freeplay. It was 40 hours to finish my first play. There were a lot of things that I didn't learn in the tutorial neither on my first freeplay (for example: complex signals for trains, better ratios for oil, almost all the military upgrades, artillery).

[bobucles]

The idea of mini scenarios sounds like a good option. A lot of problems with a traditional campaign disappear with that approach. For example, continuity between scenarios is no longer important. Each scenario is a standalone project, so having overlaps in objectives or similar puzzles is okay. A normal campaign kind of expects most missions to be normal, however standalone scenarios can introduce crazy things such as strange map layouts or unusual tech restrictions. Scenarios can still teach game mechanics in a way that freeplay can't, by introducing prebuilt bases and logistic/train networks to kickstart players on those topics. An entire scenario for example could just be "fix this train network", with all other parts of the base pretty functional. Stuff like that.

[Miteusz]

I very much enjoyed the pathfinding discussion and I made sure I understood every issue and solution before moving on. From a FIT (or CTU in English) uni, where we discussed Dijkstra, binary heap, Linked lists and all that stuff, it is always nice to see them used and inspires you to learn them. And they are being used by the best game developers! (Btw. what are Binominal trees and AVL trees for? I wish I cared about them and learned them for an upcoming test... Gonna Google that...)
Oh, I wish you just came to the developers of the game Astroneer and showed them the way to go, just to reduce the lag spikes. I mean they might know, but they don't prioritise it as much as you guys do! And that is very important!
I am always so excited about the performance improvements. That said, on my 400 to 600 EUR value notebook, I never had much of performance issues with Factorio when not using mods. The only exception being on truly massive multiplayer servers staring at the steam engine production. Yep, settings > steam > off was necessary.

Binomial tree is used in binomial heap. Binomial heap implements priority queue (like standard binary heap), but allows merging queues in fast way.

AVL tree is binary search tree that rebalance its structure after every insertion or removal of node from tree such that height of AVL tree is always small. AVL allows efficient implementation of data structure that holds set of elements, and allows to insert new elements, remove elements and checking if given element is in set.

[Miteusz]

I am wondering why your implementation of Dijkstra algorithm has so many corner cases. I don't know how trains work in Factorio because I didn't make so far in this game yet, but if you can model your problem as searching for shortest path in graph with non-negative weights on edges, implementation of Dijkstra should be pretty straighforward.

If I understand correctly, you need to have weights not only on edges of graph, but also on nodes of graph, which causes several strange problems. Am I right?

[boskid]

I am wondering why your implementation of Dijkstra algorithm has so many corner cases. I don't know how trains work in Factorio because I didn't make so far in this game yet, but if you can model your problem as searching for shortest path in graph with non-negative weights on edges, implementation of Dijkstra should be pretty straighforward.

If I understand correctly, you need to have weights not only on edges of graph, but also on nodes of graph, which causes several strange problems. Am I right?

Weights (penalties) are on nodes and edges. There are only a few edge cases (single segment cycle, single sided train that has to exit segment and enter it from opposite side because temporary station is behind) and they are all related to fact that pathfinder does not use rails but segments (series of rails). Problems here were not edge-cases, they were because some node penalties were ommited when should be included (like issue 1), or because some node penalties did not account train position inside segment (3) or some penalties were added on node when should be added on edge (2, 5). Issue 6 was single line missing.

[Tesse11ation]

scenario:
you have 5 iron ore mines with chests and loaders attached.

0 ore in the chests: train station outputs a request value of 0 cause it is unreasonable to send a train to a empty station

1 - amout of circuit calculated train cargo: train station outputs a request value of 1

n train cargo + 1 ore available: n+1 output signal until the number exceeds the maximum number of trains the station can keep off the main rail (waiting station with signals) (comparator ftw)

if you use signals / toggle train stations, you will send out all available trains that have this station set as next target.

to counter that, you'd have to create individualized train depot stations with separate logic to only let trains move when a circuit logic signal is present.
problem:
two trains leave.. great.
but they arrive at the same station even though two separately positioned stations are available.


additionally it would be awesome if circuit logic could tell a train to skip the next N stations with one tick so it would be possible to use multiple cargo trains for different items and balance them through circuit logic.
even better: make it so configured stations can be targeted with a circuit logic expression that was send by the current train station.

Guess what? You can do EVERYTHING HERE with circuit network logic.

You can configure any given station to turn off under specific conditions, including (but not limited to) being occupied already by a train; not having enough resources in chests to justify allowing a train in; or knowing based on remaining resources to mine (such as none left) that the remainder of resources in the chest is the only amount that the station can provide, then allowing a train in to pick up the last of the resources and permanently disable the station afterward. I know this because I've done it all before. Why add logic like this into the trains when you can create it yourself?

Side note: if any of you are particularly interested in doing this, my hint to you is that most logic is actually handled at the resource pickup area. Also, remember that trains themselves can hold logic. A friend of mine actually theorycrafted wireless transmission of data using logic and the train network, and I watched it work. It was like magic to me.

[Miteusz]

I am wondering why your implementation of Dijkstra algorithm has so many corner cases. I don't know how trains work in Factorio because I didn't make so far in this game yet, but if you can model your problem as searching for shortest path in graph with non-negative weights on edges, implementation of Dijkstra should be pretty straighforward.

If I understand correctly, you need to have weights not only on edges of graph, but also on nodes of graph, which causes several strange problems. Am I right?

Weights (penalties) are on nodes and edges. There are only a few edge cases (single segment cycle, single sided train that has to exit segment and enter it from opposite side because temporary station is behind) and they are all related to fact that pathfinder does not use rails but segments (series of rails). Problems here were not edge-cases, they were because some node penalties were ommited when should be included (like issue 1), or because some node penalties did not account train position inside segment (3) or some penalties were added on node when should be added on edge (2, 5). Issue 6 was single line missing.

I see. So, if I understand correctly, most of these cases arise from fact that train can be "in the middle" of some edge of graph on which pathfinder operates, instead of being in one of nodes of this graph.