• Content Count

  • Joined

  • Last visited

Community Reputation

5 Neutral

About 644232_1452791058

  • Rank
    Junior Member

Recent Profile Visitors

194 profile views
  1. The critter sensor is easy to misunderstand. It only activates if the critter count is above the set number. Set it to 5 and you will see it will also be active. It's not active when you set it to 6, because there are 6 critters in the room (4 + 2 eggs) and it would only activate at 7 critters in that case. TL;DR Set the critter counter to 1 number lower than the number you actually want.
  2. The maximum for nature reserves is 120 tiles... where are you getting a minimum of 128 from?
  3. If I have an automatic dispenser set to sweep only and then select an item to be swept with the highest priority (!!), dupes will not react in any way. Normally a !! task will cause dupes to drop everything to complete it ASAP. The only way to get dupes to immediately complete the sweep task is to set the automatic dispenser itself to !! priority. Even if the automatic dispenser is set to priority 9, dupes will still do other tasks first. This is very annoying and doesn't fall in line with other !! priority behaviour. In cases like slime, where fast sweeping is very important, you can't simply !! sweep an area - you have to sweep it AND then set the automatic dispenser to !! priority. One would think a !! sweep would be enough... A very inefficient solution would be to have the ore dropper always on !! priority, but then you constantly have alarms and a yellow border. P.S. it doesn't matter if dupes are on standard priorities or have ++ priority for tidying and storing - they will still choose to do other tasks first before completing a !! sweep...
  4. Minor bug, but I just noticed the priority calculations are not showing correctly for "sweep" tasks. Lindsay has the same priority for operating and tidying, so logically she will complete the priority 9 sweep task before running the priority 5 generator. However, in the tooltip it shows her current job as a store job, AND it is being shown as having a lower priority than that of the operate job (39 vs 45). This could confuse newer players, who do not realise that sweep belongs to the "tidying" category. A lot of people would think it belongs to the "storing" category due to this false tooltip and also due to the nature of the job (I mean... she is storing items!) Even I was confused for several minutes why she wouldn't run the generator and I've already had this confusion a couple times in the past! Expected: tooltip shows current job as sweep and with correct priorities Actual: tooltip shows current job as store and with incorrect priorities
  5. Okay cool, good to know! I was a bit irritated, because the solid conveyors weren't behaving as expected, but now I know why! I'll have a look at some 'complex' liquid/gas piping and see if I notice any strange behaviour. Right off the bat, I already have another couple questions after doing some testing. See below: (A) One pump connected to two vents: 50-50 split of packets (as expected). (B) Two pumps connected to two vents (no bridges): middle output splits 50-50, right output sends all packets (every 2nd packet because of incoming packets from the left) to the right input. (C) Three pumps connected to two vents. Only the pump all the way on the left splits 50-50, the one in the middle sends a packet every 4th packet (only to the right), the one on the right sends a packet every 2nd packet (also only to the right), regardless of which order the pipes are connected. Why do packets from the left have 'right of way'? It doesn't matter which pipe I connect first, an output on the 'left' will always override any other outputs joining the line. It will be the dominant 50-50 split, while all other outputs will divert to the right. Is this behaviour prevalent across all systems and is there a reason for this? Or are there also cases where packets from the right have 'right of way'? Also, last observation for today (gotta sleep at some point): Each time you lay piping, packets 'reset'. If you do this every second - or more accurately, before the packets completely move to their next position - they will jump back and move forward again. This results in interesting behaviour at junctions, because each time a packet 'jumps' back, it will always opt to go left upon reaching a junction, regardless if the previous packet was already sent left. In the above picture, I repeatedly 'placed' a pipe to achieve the following picture. I say 'placed', because I didn't even lay new piping, I simply selected pipe and clicked on a tile where existing pipe was present - i.e. I didn't 'build' any new pipe, I just executed the action of placing pipe. So instead of a 50-50 split, all packets were sent to the left. I assume this is not intended behaviour? Cheers, Vasco
  6. Hi Chris P, Thanks for your reply. Unfortunately, I still have a couple of concerns with the new algorithms. Could you perhaps elaborate on the following cases on what is happening with the flow here and why the algorithm refuses to acknowledge a what seems to me to be a legitimate build? I set up a basic sweeper-loader-split layout. The left lane goes straight to a chute, the right lane goes also straight to a vent, but with several merging lanes from other loaders who would also like to dump to the right chute. Tested in all cases with 8 shine bug eggs. Experiment (A) As far as I can see, both ends have a output, and yet, the first packet that enters the system tries to go right. It then bounces endlessly between the right chute and the T-junction. Meanwhile all other 7 packets will be forced to go left. After the last packet turns left, the original first packet will also cross from the right to the left and all 8 eggs end up going left, instead of splitting evenly as would be expected. Merging the additional loaders on the left with bridges clearly wouldn't work, since that would be the same case as in my original post. Variants in the system (B) other loaders directly connect to chute, (C) other loaders connect after the chute: result is the exact same situation as in (A) - I would have thought that with the chute being at the centre/before the other loaders, that packets would flow there unheeded. Not the case. (D) I add a bridge to the right lane, and now the packets split evenly along both lanes. My concerns are, why is it so difficult to deal with merging and splitting? I feel like this is counterintuitive to a lot of systems that players use to move gasses/liquids/items around and adds an unnecessary step (in this case, a redundant bridge) and complicates builds which are in some cases space-restricted. The moment one side of a split has a "merging" output (including the 'output' end of bridges), it seems packets will try to avoid that route, even if there are viable outputs that are closer or on the way (e.g. C). The fact that the first packet in (A)-(C) actively chooses to go right, only to uselessly bounce back and forth, blocking the route, seems like a bug as well, rather than a feature. Could you perhaps elaborate on what makes a packet choose to go in a certain direction at a junction? What causes it to bounce back and forth? Is it merely the presence of an output on one side that makes them avoid it, or is it more complex, and they check/compare how many inputs/outputs per side and decide to go where there are more net inputs? Is the distance between junctions/merging/input/output important? EDIT: I noticed that (A)-(C) would work if I placed the right chute further away from the merging loaders (at least 1 tile gap between merging junction and chute). Still won't work if I join any of the additional loaders with a bridge. The packets will always go: 1 packet right - it will bounce between bridge output and T-junction - 2 packets go left (1st by logical split, 2nd because right route blocked by bouncing packet) - bouncing packet then passes the point where the bridge merges and exits chute. Process starts again with the next packet (repeats every 3 packets). Hope to understand more and optimise my layouts. Cheers! Vasco
  7. Since the latest LU update, I've been having problems with bridges of all sorts (gas, liquid, conveyor). Simple set-ups don't work anymore. Simple T-junctions don't even split 50% anymore, if at any point along either lane, a bridge is present. Packets bounce back and forth between junctions, even if the direction is indicated with a bridge. Merging with bridges will make all packets avoid that line in some cases. Splitting at a bridge also causes wacky packet behaviour (they refuse to merge sometimes). Below I have two screenshots in sandbox showing part of this odd behaviour. First picture is a normal T-junction. Packets split 50% between the two outputs. Second picture is a T-junction, with a merging bridge on the right lane. The bridge is empty, the merging pipe is empty (deconstructed several times to be sure) and yet all the packets ignore that lane and go left instead??? I also have a conveyor system with a simple T-junction so that eggs go 50% to kitchen, 50% to drown room, and yet I observed 10 eggs and 7 ended up in the drown room and 3 in the kitchen. The route to the kitchen had a bridge to merge with the main line - the line was completely empty and yet the packets would 'bounce' off the bridge and flow in the wrong direction for a second, causing other fresh packets to ignore that route as a possibility - i.e. more went the route without the bridge (to the drown room) because the flow was constant. I would do more testing, but I'm already sleep deprived from trying so long to get my intricate pipe systems working... no luck.