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?Pridesfall wrote: βWed Jun 17, 2020 7:23 amThis 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.
Version 0.18.32
Re: Version 0.18.32
Re: Version 0.18.32
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).V453000 wrote: βWed Jun 17, 2020 8:09 amSorry 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?Pridesfall wrote: βWed Jun 17, 2020 7:23 amThis 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.
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.
Re: Version 0.18.32
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?
Re: Version 0.18.32
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 :/
Anyway, this update probably will create a huge mess in my base because of the new fluid system so I might opt out anyway :/
Re: Version 0.18.32
I like the new beacon but you forgot to change the icon of the beacon technology which still depicts an old beacon! ![Uber Geek :ugeek:](./images/smilies/icon_e_ugeek.gif)
![Uber Geek :ugeek:](./images/smilies/icon_e_ugeek.gif)
- Pridesfall
- Fast Inserter
- Posts: 133
- Joined: Thu Dec 18, 2014 7:18 pm
- Contact:
Re: Version 0.18.32
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 wrote: βWed Jun 17, 2020 2:03 pmI'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).V453000 wrote: βWed Jun 17, 2020 8:09 amSorry 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?Pridesfall wrote: βWed Jun 17, 2020 7:23 amThis 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.
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.
Re: Version 0.18.32
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.Pridesfall wrote: βThu Jun 18, 2020 4:46 amI 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 wrote: βWed Jun 17, 2020 2:03 pmI'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).V453000 wrote: βWed Jun 17, 2020 8:09 amSorry 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?Pridesfall wrote: βWed Jun 17, 2020 7:23 amThis 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.
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.
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.
-
- Fast Inserter
- Posts: 208
- Joined: Tue Apr 24, 2018 5:42 am
- Contact:
Re: Version 0.18.32
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
- Smart Inserter
- Posts: 1193
- Joined: Fri Jun 10, 2016 11:21 pm
- Contact:
Re: Version 0.18.32
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?ColonelSandersLite wrote: βFri Jun 19, 2020 8:53 amYou'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.
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.
Re: Version 0.18.32
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.ColonelSandersLite wrote: βFri Jun 19, 2020 8:53 amYou'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.
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%.
No, because the rounding has already happened in the signal as it is being emitted from the tank itself.5thHorseman wrote: βFri Jun 19, 2020 10:38 amCan 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?ColonelSandersLite wrote: βFri Jun 19, 2020 8:53 amYou'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.
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.
Last edited by Blokus on Sun Jun 21, 2020 4:26 am, edited 1 time in total.
- Omnifarious
- Filter Inserter
- Posts: 269
- Joined: Wed Jul 26, 2017 3:24 pm
- Contact:
Re: Version 0.18.32
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.5thHorseman wrote: βFri Jun 19, 2020 10:38 amCan 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?ColonelSandersLite wrote: βFri Jun 19, 2020 8:53 amYou'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.
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.
-
- Burner Inserter
- Posts: 15
- Joined: Sat Dec 23, 2017 3:07 am
- Contact:
Re: Version 0.18.32
After the last patches, I noticed that some of the windows look pretty crooked, before it wasnβt.
https://imgur.com/a/7ABdgeZ
![Image](https://imgur.com/a/7ABdgeZ)
https://imgur.com/a/7ABdgeZ
Re: Version 0.18.32
Must be because of the Comic Sans font
Just joking. Seems normal to me (with the regular font)
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
Just joking. Seems normal to me (with the regular font)
Koub - Please consider English is not my native language.
-
- Filter Inserter
- Posts: 660
- Joined: Sat Jun 06, 2015 2:23 am
- Contact:
Re: Version 0.18.32
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.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.
Re: Version 0.18.32
There actually IS an option, as mentioned in the text you quoted.factoriouzr wrote: βThu Jun 25, 2020 12:00 pmThis 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.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.
![Smile :)](./images/smilies/icon_e_smile.gif)
(New interface settings (off by default) bypasses this and allows the player to see all items as before.)