Version 0.18.32

[V453000]

This update absolutely broke my over 300 hour train based Pyanodon run. I took advantage of the fact that fluids couldn't be mixed by having train stops that accepted up to 3 different fluids and since they couldn't mix, the correct pumps always emptied the tanks. Now I have probably 50 trains with mixed fluids and I have no idea how many of the stations are ruined, but it's a lot. Can't fluid pumps go back to preventing fluid mixing? I don't have space to make a station for each fluid.

This really sucks.

Sorry to hear that. Did you consider controlling the pumps by circuit network? Aka, you read which station the train arrived to (or which cargo it carries if it's a single station), and only activate the correct pumps?

[Blokus]

This update absolutely broke my over 300 hour train based Pyanodon run. I took advantage of the fact that fluids couldn't be mixed by having train stops that accepted up to 3 different fluids and since they couldn't mix, the correct pumps always emptied the tanks. Now I have probably 50 trains with mixed fluids and I have no idea how many of the stations are ruined, but it's a lot. Can't fluid pumps go back to preventing fluid mixing? I don't have space to make a station for each fluid.

This really sucks.

Sorry to hear that. Did you consider controlling the pumps by circuit network? Aka, you read which station the train arrived to (or which cargo it carries if it's a single station), and only activate the correct pumps?

I'm pretty sure I used to do the same thing in my old Py base. Thus this is the "which cargo" case. In that case, you can try filtering pumps by train contents, but if you do it in the naive way it will not behave properly all the time, because the train contents can very rarely wind up being less than 1 unit of fluid, which the circuit network will view as 0. Then the train unloading stops, and the train either sits there forever or leaves with fluid in it; either way it's bad. There are fixes but they get fussy quickly: you can delay the train contents signal by a tick with an identity combinator (each *1 output each or similar), or you can use a memory cell (enable pumps based on the state of the train contents on the tick when the train arrived).

In any case trying to do this in a live base that was taking advantage of the old system is absolutely impossible; you'd have to entirely shut the base down to deploy the fix, and unless you caught it immediately, you'd spend hours doing manual cleanup as well. Py has a lot of fluids.

Just in general I have never understood why the circuit network rounds fractional fluids down instead of up. It seems like rounding up would perform how you want much more of the time.

[th0]

This beta for me is not available on Steam. Even though "Latest 0.18 Experimental" is selected, it only offers 0.18.31. Do I need to update manually?

[valneq]

This beta for me is not available on Steam. Even though "Latest 0.18 Experimental" is selected, it only offers 0.18.31. Do I need to update manually?

For me, Steam does offer 0.18.32 and it automatically updated yesterday. Cannot tell why your Steam does not.

[th0]

Thanks for the feedback. I will go and poke it with a stick.
Anyway, this update probably will create a huge mess in my base because of the new fluid system so I might opt out anyway :/

[Pleykorn]

I like the new beacon but you forgot to change the icon of the beacon technology which still depicts an old beacon!

[valneq]

I like the new beacon but you forgot to change the icon of the beacon technology which still depicts an old beacon!

A lot of the technology icons need to be updated. Not only the beacon.

[Pridesfall]

This update absolutely broke my over 300 hour train based Pyanodon run. I took advantage of the fact that fluids couldn't be mixed by having train stops that accepted up to 3 different fluids and since they couldn't mix, the correct pumps always emptied the tanks. Now I have probably 50 trains with mixed fluids and I have no idea how many of the stations are ruined, but it's a lot. Can't fluid pumps go back to preventing fluid mixing? I don't have space to make a station for each fluid.

This really sucks.

Sorry to hear that. Did you consider controlling the pumps by circuit network? Aka, you read which station the train arrived to (or which cargo it carries if it's a single station), and only activate the correct pumps?

I'm pretty sure I used to do the same thing in my old Py base. Thus this is the "which cargo" case. In that case, you can try filtering pumps by train contents, but if you do it in the naive way it will not behave properly all the time, because the train contents can very rarely wind up being less than 1 unit of fluid, which the circuit network will view as 0. Then the train unloading stops, and the train either sits there forever or leaves with fluid in it; either way it's bad. There are fixes but they get fussy quickly: you can delay the train contents signal by a tick with an identity combinator (each *1 output each or similar), or you can use a memory cell (enable pumps based on the state of the train contents on the tick when the train arrived).

In any case trying to do this in a live base that was taking advantage of the old system is absolutely impossible; you'd have to entirely shut the base down to deploy the fix, and unless you caught it immediately, you'd spend hours doing manual cleanup as well. Py has a lot of fluids.

Just in general I have never understood why the circuit network rounds fractional fluids down instead of up. It seems like rounding up would perform how you want much more of the time.

I added circuits to each pump and they work correctly but I'm having that exact problem. Why is the circuit condition x > 0 actually performing as x > or = 1. I don't really know what to do now. I spent about 4 hours fixing to this point but I'm still screwed.

[Blokus]

This update absolutely broke my over 300 hour train based Pyanodon run. I took advantage of the fact that fluids couldn't be mixed by having train stops that accepted up to 3 different fluids and since they couldn't mix, the correct pumps always emptied the tanks. Now I have probably 50 trains with mixed fluids and I have no idea how many of the stations are ruined, but it's a lot. Can't fluid pumps go back to preventing fluid mixing? I don't have space to make a station for each fluid.

This really sucks.

Sorry to hear that. Did you consider controlling the pumps by circuit network? Aka, you read which station the train arrived to (or which cargo it carries if it's a single station), and only activate the correct pumps?

I'm pretty sure I used to do the same thing in my old Py base. Thus this is the "which cargo" case. In that case, you can try filtering pumps by train contents, but if you do it in the naive way it will not behave properly all the time, because the train contents can very rarely wind up being less than 1 unit of fluid, which the circuit network will view as 0. Then the train unloading stops, and the train either sits there forever or leaves with fluid in it; either way it's bad. There are fixes but they get fussy quickly: you can delay the train contents signal by a tick with an identity combinator (each *1 output each or similar), or you can use a memory cell (enable pumps based on the state of the train contents on the tick when the train arrived).

In any case trying to do this in a live base that was taking advantage of the old system is absolutely impossible; you'd have to entirely shut the base down to deploy the fix, and unless you caught it immediately, you'd spend hours doing manual cleanup as well. Py has a lot of fluids.

Just in general I have never understood why the circuit network rounds fractional fluids down instead of up. It seems like rounding up would perform how you want much more of the time.

I added circuits to each pump and they work correctly but I'm having that exact problem. Why is the circuit condition x > 0 actually performing as x > or = 1. I don't really know what to do now. I spent about 4 hours fixing to this point but I'm still screwed.

The actual value of the signal being sent when a fluid inventory is, say, 0.5, is exactly 0. It not being 0.5 is because the circuit network operates on integers...but they could've made it round up instead of down. I don't know what the rationale for doing it this way was.

But as I said in the previous comment, there are some fiddly corrections you can do. The easiest one: where you control requester pumps, send the data about the train contents through a "each * 1 output each" arithmetic combinator first, before handing it off to the pumps. This will cause the pumps to see a snapshot of what the circuit network thinks was in the train 1 tick ago, which will cause the pump to turn on 1 tick later and also turn off 1 tick later. Unless you are extremely short on power, that one extra tick will give enough time to empty out the train.

[ColonelSandersLite]

It not being 0.5 is because the circuit network operates on integers...but they could've made it round up instead of down. I don't know what the rationale for doing it this way was.

You're mistaken in saying that circuits round down. As an experiment, divide -7 by 3. Since the game truncates, the game will give an answer of -2. If the game rounded down, the answer would be -3.

The reason the circuit network works with integers and truncates instead of rounding down is almost certainly performance. Rounding is just more CPU expensive than just simple truncation.

[5thHorseman]

It not being 0.5 is because the circuit network operates on integers...but they could've made it round up instead of down. I don't know what the rationale for doing it this way was.

You're mistaken in saying that circuits round down. As an experiment, divide -7 by 3. Since the game truncates, the game will give an answer of -2. If the game rounded down, the answer would be -3.

The reason the circuit network works with integers and truncates instead of rounding down is almost certainly performance. Rounding is just more CPU expensive than just simple truncation.

Can you then take the reading from the tank and multiply it by -1? Or will it just be 0*-1 and not 0.1*-1?

I ask because I don't want to try it. I don't want to try it because I kind of agree with the developers on this one. But I'm still kind of rooting for the small guy.

[Blokus]

It not being 0.5 is because the circuit network operates on integers...but they could've made it round up instead of down. I don't know what the rationale for doing it this way was.

You're mistaken in saying that circuits round down. As an experiment, divide -7 by 3. Since the game truncates, the game will give an answer of -2. If the game rounded down, the answer would be -3.

The reason the circuit network works with integers and truncates instead of rounding down is almost certainly performance. Rounding is just more CPU expensive than just simple truncation.

Technically what I said is equivalent, because I was actually talking about specifically "read contents" devices which are always emitting positive values (or nothing). But yes, in general the circuit network rounds towards zero, not down.

As for your performance point, I am not talking here about rounding to the nearest integer, I am talking about always rounding away from zero (e.g. 0.1 -> 1), which as far as I know is about as expensive as truncation. In any case I would be shocked if this change would slow down the circuit network step by more than 1%.

It not being 0.5 is because the circuit network operates on integers...but they could've made it round up instead of down. I don't know what the rationale for doing it this way was.

You're mistaken in saying that circuits round down. As an experiment, divide -7 by 3. Since the game truncates, the game will give an answer of -2. If the game rounded down, the answer would be -3.

The reason the circuit network works with integers and truncates instead of rounding down is almost certainly performance. Rounding is just more CPU expensive than just simple truncation.

Can you then take the reading from the tank and multiply it by -1? Or will it just be 0*-1 and not 0.1*-1?

I ask because I don't want to try it. I don't want to try it because I kind of agree with the developers on this one. But I'm still kind of rooting for the small guy.

No, because the rounding has already happened in the signal as it is being emitted from the tank itself.

[Omnifarious]

It not being 0.5 is because the circuit network operates on integers...but they could've made it round up instead of down. I don't know what the rationale for doing it this way was.

You're mistaken in saying that circuits round down. As an experiment, divide -7 by 3. Since the game truncates, the game will give an answer of -2. If the game rounded down, the answer would be -3.

The reason the circuit network works with integers and truncates instead of rounding down is almost certainly performance. Rounding is just more CPU expensive than just simple truncation.

Can you then take the reading from the tank and multiply it by -1? Or will it just be 0*-1 and not 0.1*-1?

It will just be 0*-1, unfortunately. The rounding happens when the tank value is put onto the network in the first place, not when it hits a comparitor.

If this were to be fixed in Factorio, I think the fix would have to be very careful and minimal to avoid breaking existing circuit networks. I think that one way to do this might be to round the way it does unless the value it's reading would be 0. Then it could round away from 0. Basically treat 0 as a special value that it will only output if the source value is really 0.

[Shoooter13]

After the last patches, I noticed that some of the windows look pretty crooked, before it wasn’t.
https://imgur.com/a/7ABdgeZ

[Koub]

Must be because of the Comic Sans font
Just joking. Seems normal to me (with the regular font)

[factoriouzr]

Show only unlocked items in filter selection (inventory and quickbar) and logistic/trash requests. Other selections like signal selection/upgrade selection are not affected. New interface settings (off by default) bypasses this and allows the player to see all items as before.

This is a step backwards. I like being able to set entities not yet researched and it's extremely useful in many situations. At the very least add an option to toggle this back on in options.

[DanGio]

Show only unlocked items in filter selection (inventory and quickbar) and logistic/trash requests. Other selections like signal selection/upgrade selection are not affected. New interface settings (off by default) bypasses this and allows the player to see all items as before.

This is a step backwards. I like being able to set entities not yet researched and it's extremely useful in many situations. At the very least add an option to toggle this back on in options.

There actually IS an option, as mentioned in the text you quoted.

(New interface settings (off by default) bypasses this and allows the player to see all items as before.)