JCav wrote: ↑

Wed Jan 29, 2020 7:38 pm

As a follow-up to my previous response to the fluid system *still* not being fixed, and the news that it isn't even planned for 1.0 (which generally means never), I have removed my positive review on Steam, as well as removing it as my favorite game on my profile.

The developers know that the fluid system is wrong, illogical, and fundamentally broken compared to the rest of the game. Ignoring this issue is unacceptable, and my opinion of Wube has greatly diminished.

Which generally are you talking about? Generally Wube or generally game devs because I think there is a big distinction there

As a follow-up to my previous response to the fluid system *still* not being fixed, and the news that it isn't even planned for 1.0 (which generally means never), I have removed my positive review on Steam, as well as removing it as my favorite game on my profile.

The developers know that the fluid system is wrong, illogical, and fundamentally broken compared to the rest of the game. Ignoring this issue is unacceptable, and my opinion of Wube has greatly diminished.

Freddie Chopin wrote: ↑

Wed Jan 29, 2020 3:47 pm

Also things like "we'll maybe do it if we have spare time" in programmer-speak means just "never", so - you know... (;

Yes I already know but in that case the "we'll maybe do it if we have spare time" was said about it being done for 1.0 wich make a tone of difference.

And the reason why I believe they will work on the fluid system post 1.0 if they don't do it before is because of how much time they have put on polishing the game and wouldn't let that kind of liquid behavior slideand the reason why it isn't included in 1.0 is because of unforseen event after the deadline was set for the launch.

Yes I do trust them a lot but In 5 years I have followed the develpment of this game they never failed it.

Freddie Chopin wrote: ↑

Wed Jan 29, 2020 3:47 pm

You just can't expect software *in general* to never break when changed, this even happens in critical software when people die as a result and all the imaginable steps are taken to prevent stuff from breaking...

You're mixing things. Software breaking because of an unintended bug is not the same thing as "breaking on purpose", right? (;

Olacken wrote: ↑

Wed Jan 29, 2020 3:20 pm

[...] some people will just respond to you "yes but I wan't to play with my old and new toys" and with those people it's hard to discuss afterward because you made it sounds like forcing them to choose was a valid argument.

And I want my cake and eat it too.
"new toys" imply change. Which might (or might not) break "old toys". The risk is particularly high in simulation-heavy software like Factorio, where things affect other things, and consequences propagate far and wide.

Freddie Chopin wrote: ↑

Wed Jan 29, 2020 3:47 pm

[...]some other person playing his modded angel-bob-krastorio-rampant-ribbon-pyanodons-ir-ltn-railworld-deathworld-marathon-with-expensive-recipes may don't care about that at all. And he will complain, that his save is ruined. It is a valid complaint... Is fixing the fluid system "the lesser evil" in that case? (;

No, it's not a valid complaint, because he modded his game, and furthermore, modded it heavily. (Which I do for most of my games.)
Any change to vanilla, even one from a minor version, could potentially completely break a heavily modded game that relied on a now removed functionality/quirk/bug. (Modders just *love* to push the game to its limits !)
Example : Rail Bridges. (Note : still during the first 0.17 experimental.)
Though hopefully, these kinds of changes will only happen in major versions after 1.0 ?

Again, I would ask those people if it was their first game experience.
My own experience involves :
- Devs that decided to flat-out remotely delete old saves when declaring the (post-release, post-1.0 !) game as stable, because it would "save on tech support with people that would try to continue games on different versions". (They would have benefited *a lot* from Early Access if it existed already...)
- Devs that upon reaching stable first hid the old saves, then have shown them as "unloadable", then, after pestering from players, and some days/weeks, published a fix that would allow old saves to be loaded (and no promises about stuff potentially breaking).
(And both of these are for games with save lengths in the same order of magnitude as Factorio ! And anyone using mods and complaining would be just "laughed out of the room".)

Freddie Chopin wrote: ↑

Wed Jan 29, 2020 3:47 pm

[...]Also things like "we'll maybe do it if we have spare time" in programmer-speak means just "never", so - you know... (;

Well, IIRC, Wube has a pretty good track record in eventually implementing "spare time" stuff ?

BlueTemplar wrote: ↑

Wed Jan 29, 2020 2:51 pm

Ah, interesting, what *I* did, was to build the pipes *first* and *only* then turn the pump power on.
This showed issues in 0.16.51, but not in 0.17.79 nor 0.18.2.

But it indeed seems like other build order issues remain. (I get the same issues as you in 0.18.2)

Yes, the whole thing is a bit chaotic and hard to reason about - seemingly unimportant changes can have drastic effects, that's why I think it is really broken [;

I'm sorry, but imagining that devs will stop even balancing the game after 1.0 is ridiculous.
People will complain anyway, whether it's actually warranted or not,

Balancing is a minor change. Fixing fluid system is altering the core mechanics of the game. On the other hand this probably boils down to what exactly will such hypothetical "fix" change. I can imagine that it can range from introducing something completely new, with different characteristics, or just fixing all the issues in the current one.

and I fail to see how your example of people upgrading and downgrading is relevant when not only the game is alpha, but that would also require the player to mess with Steam settings to get access to the "beta".
(And downgrading is not supported, though it might not be clear enough ?)
(And Steams' backup system might be dangerous to use.)
(And they should have properly backed up their files if they cared about them.)
Is this those people's first game ??

It's relevant because - as you noted yourself - such complains are just ridiculous (; Yet they appeared even though all of what you wrote is true. Imagine complains which would appear when the user does something "normal" (just upgrade) and finds that a change done _on_ _purpose_ (fixing the fluid system) breaks his precious save he/she has been working on for months. For me fixing it would be very nice. But some other person playing his modded angel-bob-krastorio-rampant-ribbon-pyanodons-ir-ltn-railworld-deathworld-marathon-with-expensive-recipes may don't care about that at all. And he will complain, that his save is ruined. It is a valid complaint... Is fixing the fluid system "the lesser evil" in that case? (;

You just can't expect software *in general* to never break when changed, this even happens in critical software when people die as a result and all the imaginable steps are taken to prevent stuff from breaking...

You're mixing things. Software breaking because of an unintended bug is not the same thing as "breaking on purpose", right? (;

Which one of us will be right is hard to tell now - we will either see the fluid system change sometime in the future or never. The devs don't seem to be interested in these discussions, so all we are left with is wild guessing. Whether the concerns I have (that changing this after 1.0 is much less likely than before) are exaggerated, I hope you cannot deny that they are valid influences on one's decision making. Maybe smaller, maybe bigger, but they are there. Also things like "we'll maybe do it if we have spare time" in programmer-speak means just "never", so - you know... (;

Freddie Chopin wrote: ↑

Wed Jan 29, 2020 7:34 am

[...] PROOFS [...]

Ah, interesting, what *I* did, was to build the pipes *first* and *only* then turn the pump power on.
This showed issues in 0.16.51, but not in 0.17.79 nor 0.18.2.

But it indeed seems like other build order issues remain. (I get the same issues as you in 0.18.2)

Freddie Chopin wrote: ↑

Wed Jan 29, 2020 7:34 am

Water_test_0.18_02.zip

Or my own 0.17 and 0.18 tests :
Water_0.17_test_01.zip
Water_test_0.18.zip

Cannot open any of these, as none of them has the "level.dat" file in the zip and Factorio complains.

Oops, my bad, should have explicitly stated that those are scenarios, not saves. (And you have to unzip them first.)

Freddie Chopin wrote: ↑

Wed Jan 29, 2020 7:34 am

Freddie Chopin wrote: ↑

Tue Jan 28, 2020 8:17 am

Also a clear indicator of flow through a pipe would be more than welcome, as now debugging the whole thing is just blind guessing.

How else would you show it instead than what the current debug option does ?

As a tooltip when hovering the mouse above a pipe segment. You see the flow for pumps, just exactly the same info for pipes. Just like what was shown in FFF 274 - there was a screenshot with flow info for pipes.

Right, not sure why it isn't in yet... since it's a more basic version of what you already see in the pipe graphics and the debug mode ?

Freddie Chopin wrote: ↑

Wed Jan 29, 2020 7:34 am

They would not stop development, but - at least in my understanding - fixing of fluid system would alter the basic mechanics that currently exist. Can you imagine the devs introducing changes of belt speed and inserter capacity _AFTER_ 1.0 is released? I cannot. And I think that fixing fluid mechanics would be quite similar to a change like modifying belt speed or inserter capacity... People complain on the forums (and in the reviews about everything) - for example someone upgraded to the new experimental, then downgraded back to 0.17 and after that all the blueprints are gone. All of that with the added comment "super mad"... Imagine forum threads like "I had my 1234k SPM base working perfectly, was building the thing for 4321 hours during the last 3 years and now - after the upgrade - it doesn't work! SUPER MAD!". Really bad publicity...

I'm sorry, but imagining that devs will stop even balancing the game after 1.0 is ridiculous.
People will complain anyway, whether it's actually warranted or not,

and I fail to see how your example of people upgrading and downgrading is relevant when not only the game is alpha, but that would also require the player to mess with Steam settings to get access to the "beta".
(And downgrading is not supported, though it might not be clear enough ?)
(And Steams' backup system might be dangerous to use.)
(And they should have properly backed up their files if they cared about them.)
Is this those people's first game ??

You just can't expect software *in general* to never break when changed, this even happens in critical software when people die as a result and all the imaginable steps are taken to prevent stuff from breaking...

Also, if you're particularly paranoid that your base is going to break with an update, you should just put it in a separate install and disable auto-updates.

Olacken wrote: ↑

Wed Jan 29, 2020 10:31 am

And I know I know that "just don't update then" is not really a valid argument

Why not ?

Freddie Chopin wrote: ↑

Wed Jan 29, 2020 11:01 am

I remember reading somewhere, that the new fluid system (as planned a year ago) would make underground pipes behave just as normal pipes of equivalent length. Therefore 2 undergrounds spanning for 10 tiles would count as 10 pipe segments, not 2 (as they do now). Such change alone has a potential of breaking everything you've done previously, especially nuclear power. I'm obviously assuming that this new fluid system would still reduce throughput for longer pipelines, but maybe it wouldn't - in that case it would indeed be hard to imagine it breaking something. Hard to tell, we are all speculating about something that may as well never happen /;

That would have been Dominik's "New fluid system (1)".
Parts of which might or might not have been scrapped for TheYeast & Dominik's "New fluid system 2", which improved the "Old fluid system" by instead pretty much keeping the old physics model (?), but fixing the algorithm for the update order issues (by using several passes, as AFAIK is usually done for these simulations), which should have fixed the asymmetry issues. (No idea about build order issues, but hopefully, too.)
And they might have then still "merged in" Dominik's "New fluid system 1" later ?
However, it would seem that correcting the asymmetry might have caused new issues with oscillations ? Not sure why the dampening wasn't enough, what if it was the updated wave speed & viscosity parameters that were the issue ? (As bob found out when modding these values in 0.16-...)

Freddie Chopin wrote: ↑

Wed Jan 29, 2020 11:01 am

I remember reading somewhere, that the new fluid system (as planned a year ago) would make underground ...

True I explained myself poorly and wasn't really making the right point.

As of today I don't recall the devs scrape an idea because it wouldn't increase new player income and that would benefit more experienced player (for the reason of not increasing the new player income) or at least for the idea that were scrapped that we know of .

And yes it could change with the fact that the game is released.

They have polished the game so much over those past 3 year that I don't think they would let such a glaring issue stay and if you look at recent update and fff's you can see it.

Also be mindfull of the wording

Right now it isn't included in our plans for 1.0.

It's precised that it isn't planed for 1.0 which let think it isn't out of question just not for 1.0

Things in this regard could change, especially if things go smoothly and one of the team has some spare time.

It further the point that it's planed or at least is in a todo list as a medium to high priority

I think the main reason why they don't plan to release a new fluid system before launch is because they had one started it wasn't working as they wanted so they scrapped it but they still have a deadline to meet to lauch the game the 25th of september and a new fluid system is something really chuncky so since they already have stuff planned they can't make promisses they know they will hardly be able to fit it in the 1.0 release.

Olacken wrote: ↑

Wed Jan 29, 2020 10:31 am

Unless you did something very very specific a better fluid system wouldn't break any base or it wouldn't be a better fluid system because...

I remember reading somewhere, that the new fluid system (as planned a year ago) would make underground pipes behave just as normal pipes of equivalent length. Therefore 2 undergrounds spanning for 10 tiles would count as 10 pipe segments, not 2 (as they do now). Such change alone has a potential of breaking everything you've done previously, especially nuclear power. I'm obviously assuming that this new fluid system would still reduce throughput for longer pipelines, but maybe it wouldn't - in that case it would indeed be hard to imagine it breaking something. Hard to tell, we are all speculating about something that may as well never happen /;

However please note that you don't need to convince me about the benefits of the potential new system (; I'm all in favor of changing the current (broken) one, even if it breaks some existing designs. However it's just my point of view and I'm very afraid that the devs (or their managers) may have a completely opposite stance, which will be even harder once 1.0 is released. It's just how software is developed - some people put a lot of effort in maintaining backward compatibility, even if this means that you are stuck with a broken feature, and there is almost nothing that can convince them to change their mind, with the only exception of >=51% of people considering to buy the game. It may sound hard, but you and I - we already bought the game, Wube most likely will _NOT_ earn any more cash from us (not that they do a bad job or something - I already bought this game, don't need another copy...). If the feature has low potential of attracting _NEW_ buyers, it has low potential of being implemented /;

Generally the biggest obstacle in the way of implementing new fluid system is that the current one "just works" for the "basic game" - as long as you don't build something big (beaconed & moduled refineries) or 10 nuclear reactors or something heavily optimized (with no significant overproduction), then you will most likely not notice the problem /;

Unless you did something very very specific a better fluid system wouldn't break any base or it wouldn't be a better fluid system because :
a - The adding of some kind of pressure or network-like flow would only increase throughput
b - The removing of build order preference would affect build who took it in consideration and unless you build big you don't really need to get into those considiration and if you do build big in most case you don't bother to build manually to favor one side over the other( a side that need to be favored).
And if you do take it into consideration and do build manually in most case you still would be happy with a new fluid system that as better throughput at longer distance and have a repartition more "predictable"/less dependent on build order and the amount of toothpaste you used the third day of the second week you changed your rail system to use 2-52 train instead of 1-8

and also if you are playing factorio isn't fixing thing that doesn't work the reason why you play?

And to finish even if it would break a lot of save and you don't like to fix your factory they wouldn't patch it silently and it wouldn't be in a small patch it would be a minor update and if you want to keep your factory that only work with the old fluid sytem you would just need to not update.

And I know I know that "just don't update then" is not really a valid argument but the positive of a new better fluid system way outweigh the negative it could have (or at least in my opinion) so I highly doubt the dev would not do it because it can possibly break the saves of some peoples

BlueTemplar wrote: ↑

Wed Jan 29, 2020 1:11 am

I'm unable to reproduce this - at least the way you describe it. Building the "left pipes" first still results in the the same scenario of "right tank" being filled first.

Initial state (3 "horizontal pipes missing):

Now put the pipes - first the right one, then the middle one, then the left one. After a while:

(left tank - 4.9k, right tank - 16k, left pump speed - 423, right pump speed - 1289).
Clear it now - delete the pipes, then the tanks, add the tanks again:
(image the same as the first one [; )
Now put the left pipe first, then the middle one, then the right one. After a while:

(left tank - 18k, right tank - 5.6k, left pump speed - 1289, right pump speed - 423).


Actually you don't need the pumps to show this behavior. Replace all of them with pipes and the same thing happens, only the differences are smaller (I've build the horizontal pipes left-to-right):

(left tank - 12k, right tank - 9.5k)

Water_test_0.18_02.zip

Or my own 0.17 and 0.18 tests :
Water_0.17_test_01.zip
Water_test_0.18.zip

Cannot open any of these, as none of them has the "level.dat" file in the zip and Factorio complains.

Anyway, are you certain that what you are describing below is still happening in the latest 0.17 or 0.18 ?

This is the latest stable 0.17 that is there. Check for yourself - here's the save of what I've shown above:

Of course, the assymetry issue is still there, and annoying, but at least it's not as bad as the build order issue

Trust me that the build order still matters... Unless you have a better explanation for what I've shown above.

Freddie Chopin wrote: ↑

Tue Jan 28, 2020 8:17 am

Also a clear indicator of flow through a pipe would be more than welcome, as now debugging the whole thing is just blind guessing.

How else would you show it instead than what the current debug option does ?

As a tooltip when hovering the mouse above a pipe segment. You see the flow for pumps, just exactly the same info for pipes. Just like what was shown in FFF 274 - there was a screenshot with flow info for pipes.

Why ?
"quietly" ??
Why would they almost completely stop development for the fear of breaking working bases ?

They would not stop development, but - at least in my understanding - fixing of fluid system would alter the basic mechanics that currently exist. Can you imagine the devs introducing changes of belt speed and inserter capacity _AFTER_ 1.0 is released? I cannot. And I think that fixing fluid mechanics would be quite similar to a change like modifying belt speed or inserter capacity... People complain on the forums (and in the reviews about everything) - for example someone upgraded to the new experimental, then downgraded back to 0.17 and after that all the blueprints are gone. All of that with the added comment "super mad"... Imagine forum threads like "I had my 1234k SPM base working perfectly, was building the thing for 4321 hours during the last 3 years and now - after the upgrade - it doesn't work! SUPER MAD!". Really bad publicity...

Freddie Chopin wrote: ↑

Tue Jan 28, 2020 8:17 am

Writing here what I also wrote on reddit (minor rephrasing).

This is the most simple demonstration of what I think is wrong with current fluid system. I'm not educated in the field of fluid physics, but I really think that a perfectly symmetric system should behave - well - symmetrically. Or at least "almost symmetrically".



The whole system was build completely when everything was empty, then I added the infinity pipe. Yet after a while the right bottom tank has 4x more water than the left bottom one... And why is that? Only because I've physically built the "right pipes" of the split earlier than the "left pipes"...

[...]

I'm unable to reproduce this - at least the way you describe it. Building the "left pipes" first still results in the the same scenario of "right tank" being filled first. Or my own 0.17 and 0.18 tests : However, I can now confirm that there was an issue with the order in which pipes were built... in 0.16 !

(The top fluid, which was built left-to-right doesn't end by catching up... up until the tanks are filled of course.
But I would have expected the bottom line - built right-to-left to have this issue instead ?!?)
(Save too big )

But I guess it was fixed in 0.17.0 ? (Or maybe in 0.17.34.)

So, a part of the "New Fluid System 2" might have already been implemented by 0.17 ? Or was this just a consequence of the new multi-threading ? It would seem that only empty pipes have been fully multithreaded by 0.17.0 ?)

Anyway, are you certain that what you are describing below is still happening in the latest 0.17 or 0.18 ?

Freddie Chopin wrote: ↑

Tue Jan 28, 2020 8:17 am

[...]

With such behavior, a perfectly working setup that you build once (say a big setup of beaconed refineries and chem-plants) may not work again when copy-pasted, even though it is a perfect copy! It would be just because your construction bots decided to put pipes in some other order than you did yourself previously... I could "overproduce" to compensate for it, but you don't need to workaround anything with overproduction when using - for example - belts and splitters. Why should I produce 20000 petroleum gas per minute, when my calculations say that 10000 is enough? This is not a theoretical concern - when designing my modest refining setup (6 refineries with 12 beacons each) I really faced this problem. I build it one way - it works fine. Then I change something - it doesn't work anymore. So I go back to the working setup from a while ago and now it's not working anymore. The only thing you can say then is just "wtf"...

Of course, the assymetry issue is still there, and annoying, but at least it's not as bad as the build order issue !

Freddie Chopin wrote: ↑

Tue Jan 28, 2020 8:17 am

Also a clear indicator of flow through a pipe would be more than welcome, as now debugging the whole thing is just blind guessing.

How else would you show it instead than what the current debug option does ?

Freddie Chopin wrote: ↑

Tue Jan 28, 2020 8:17 am

[...]
On the other hand I'm more than certain that once you release 1.0 you will never consider fixing the fluid system, because such change has a potential for quietly modifying behavior of currently existing and working bases (especially if this would be a complete rework with different mechanics, such as described in FFF 274).
[...]

Why ?
"quietly" ??
Why would they almost completely stop development for the fear of breaking working bases ?

Freddie Chopin wrote: ↑

Tue Jan 28, 2020 8:17 am

Writing here what I also wrote on reddit (minor rephrasing).

Deja vu... Last spring I posted something similar. Why polishing so minor things for years, while here is major issue in core mechanics?
Simmetry and reproducibility. Copy-pasted network must work identically. Multiple pumps connected to one source must split fluid evenly.
Such things are much more important even than throughput.

I know surrounding every pipe junction with pipes, placing buffer tanks everywhere, and controlling all of it with circuit network usually will work, but it's ridiculous. Circuit network is an optimization tool for enthusiasts. Such basic thing as pipe network must be simple and self-sufficient just like conveyors.

EDIT. IMHO, since there is no more fluid mixing, we can refuse per-tile fluid simulation, and work with "pipe blocks", separated with pumps.

Writing here what I also wrote on reddit (minor rephrasing).

This is the most simple demonstration of what I think is wrong with current fluid system. I'm not educated in the field of fluid physics, but I really think that a perfectly symmetric system should behave - well - symmetrically. Or at least "almost symmetrically".



The whole system was build completely when everything was empty, then I added the infinity pipe. Yet after a while the right bottom tank has 4x more water than the left bottom one... And why is that? Only because I've physically built the "right pipes" of the split earlier than the "left pipes"...

With such behavior, a perfectly working setup that you build once (say a big setup of beaconed refineries and chem-plants) may not work again when copy-pasted, even though it is a perfect copy! It would be just because your construction bots decided to put pipes in some other order than you did yourself previously... I could "overproduce" to compensate for it, but you don't need to workaround anything with overproduction when using - for example - belts and splitters. Why should I produce 20000 petroleum gas per minute, when my calculations say that 10000 is enough? This is not a theoretical concern - when designing my modest refining setup (6 refineries with 12 beacons each) I really faced this problem. I build it one way - it works fine. Then I change something - it doesn't work anymore. So I go back to the working setup from a while ago and now it's not working anymore. The only thing you can say then is just "wtf"...

Also a clear indicator of flow through a pipe would be more than welcome, as now debugging the whole thing is just blind guessing.

I know that GUIs and stuff like that are more visible to the users, so fixing, improving, changing, fixing, improving-again, polishing, re-polishing, ... this over and over again may be more appealing, but... You can get used to the GUIs in the game. They may not be perfect from the point of view of today's UX/UI knowledge, but for me they are more than adequate (maybe with the minor exception of the LMB/RMB madness in the blueprint GUI). Maybe train pathing has some minor issues in some strange corner cases, when the train chooses a sub-optimal path even when a better alternative exists. Maybe the train pathing could still work 5% faster and use less CPU/RAM. Maybe this, maybe that. However the fuild system is not just "lacking" or "could work a bit faster" or something like that. It's just broken. To repeat myself - you can change GUI or visuals well after 1.0 is released and it will be perfectly fine, as it's hard to imagine this as a breaking-change (or at least breaking something severely). You can improve game performance after 1.0 and everyone will be more than happy. You can continue fixing non-critical bugs (like train pathing) after the final stable version is released. On the other hand I'm more than certain that once you release 1.0 you will never consider fixing the fluid system, because such change has a potential for quietly modifying behavior of currently existing and working bases (especially if this would be a complete rework with different mechanics, such as described in FFF 274).

I'm afraid that everyone in your dev team considers "fluid system" as something like a "hot potato". You all know that it could be improved, but just no one want's to admit it and face the challenge... So you just say "it works, so don't touch it" and ignore it, explaining lack of love in this aspect with a zillion of required GUI/GFX/sound/performance/... changes that have to be done... I know Dominik - who was working on it - is now gone, but supposedly you had the prototype working and it cannot be that Dominik is the only guy in your office who could deal with fluids. or that he took this code away with him, other people can surely deal with that when given enough time (a week or two to get up-to-speed with current implementation, current problems and the workings of the prototype).

Please reconsider... Even if you won't be able to implement some other things, which are less "core" than the "fluid system"...

JCav wrote: ↑

Tue Jan 28, 2020 2:03 am

I am not at all pleased that fluid improvements have been pushed back again.

Factorio doesn't have very many 'bad' aspects to it, but the fluid system is absolutely one of them.

Dominik said in FFF #274: "This time it is pretty much finished so I can tell you facts instead of just speculations. You will find how the new algorithm will work and some new handy usability features."

Here we are over a year later and still no implementation, while being told it's not even on the table for 1.0. Not cool.

So we are back to fluids like the power network ingame?

I am not at all pleased that fluid improvements have been pushed back again.

Factorio doesn't have very many 'bad' aspects to it, but the fluid system is absolutely one of them.

Dominik said in FFF #274: "This time it is pretty much finished so I can tell you facts instead of just speculations. You will find how the new algorithm will work and some new handy usability features."

Here we are over a year later and still no implementation, while being told it's not even on the table for 1.0. Not cool.

Could we have a clarification on the fluids mechanics in a further FFF? A lot of things were announced if previous FFF, and it seems that almost everything is cancelled. What is going to happens to fluids now that Dominik, the author of FFF#260 - New fluid system has left the team?

About the Campaigns: A bit sad that both the new and the old campaigns are discarded. But I think that it's the right decision, I never felt the freedom/tech expansion of Factorio in those restricted play areas.

But there is still a problem with engaging new players into the game, and motivating them to get more, always more. I suggest to emphasize the filling of progression and rewards. If they are motivated enough, they will progress fast and learn the basics by themselves, in freeplay. Having an expanded set of achievements or quests (produce 100 iron plates, then produce 50 copper plates, with a reward for each quests) could help with it. There would be a displayed progress bar that pushes the player to fill it again and again, faster and faster. Those quests would be active by default, and could reward the player with items/ammo/skins/game modes/bonus productivity/trophies to place and display in the base/Unique limited legendary modules/potions of HP or strength/free stack of 50 concrete/Experience points with capped level=10/

OrchidAlloy wrote: ↑

Fri Jan 24, 2020 10:05 pm

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.

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.

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 personally dont see anything wrong with the current character gui

best wishes to dominik in his future endeavours

I would hope that the fluid optimizations would make 1.0, i know it will be tough and time consuming, but i know you have the people with the skill to do it.

boskid you have worked on alot of bug fixing and these train optimizations are quite the work up. your work is thorough and attentive to the fine details of the train changes, im sure if there are any side issues that pop up (hopefully there wont be any) that you will be able to solve them. thank you for your contributions. i know you worked with some of the fluid issues previously, perhaps you can take a crack at, if you aren't too busy, at the problem with fluids being such a cpu hog, at least they are supposed to now eat spare cpu cores instead of hogging all of the main thread, perhaps even delayed by a tick or two, or at least thats the way i understand it to be?

campaign canceled?? i know you want to get more polish into the game and will consider adding a campaign after 1.0, so i look forward to revisiting it at that time, imo instead of saying campaign canceled, i suggest wording it a little different, campaign placed on hold until after 1.0 release, to be revisited at a later date. either way i look forward to playing with whatever you come up with and giving you my feedback at that time. until then there are mods that add a campaign like feel with a story of their own.