biopon

  • Content count

    189
  • Joined

  • Last visited

Community Reputation

104 Excellent

About biopon

  • Rank
    Member
  1. Sorry, I've been away from the forums and ONI for a while. But it seems you've figured it out... that self-contained water duplicator is very nice work!
  2. I think it's a bug, and probably happens with all/most phase changes? I have a glossy drecko -> sour gas plant, and I'm melting plastic in it to feed an 1500g/sec naphtha valve. I'm cutting back on glossy dreckos and my plastic still keeps going up, even though there's absolutely no way I'm shearing 900kg/cycle.
  3. I don't think this has a lot to do with timing. I played around with it a lot, temperature matters more than anything else to make mass doubling consistent. I have a bug report and an artificial test save here:
  4. Very cool! I can sort of tell (or at least guess) what the icons stand for, but it'd be nice to have the tooltip say the name of the ingredient instead of just "click for more". Also, I tend to think in grams/sec, i'd love to have that metric available too.
  5. I spent a bit of time testing this further. 1 scanner per rocket with the oscillator on 2/2 busted a door on the 42nd landing. (This was my originally recommended setup.) 3 scanners per rocket with the oscillator on 1/1 cleared 124 safe landings. (1/1 worked on my test map but I'm not sure about it if you have lag.) Did not test further. 3 scanners per rocket with the oscillator on 2/2 cleared 100 safe landings. Did not test further. 2 scanners per rocket with the oscillator on 2/2 cleared 100 safe landings. Did not test further. All scanners were underground so 0/0 strength. Here's the save if anyone wants to tinker with it: Rockets.sav (Also, 10 hydrogen rockets going to 10k nonstop, they generate quite a bit of heat... I only realized when the bunker doors started to overheat.)
  6. I thought about this a bit more and this is not true, unfortunately. If the event is 200 seconds out and we're pulsing for 2 seconds, our chance to catch the rocket with the first attempt is only 1%. Depending on how the rolls are made and how the resulting number is used, subsequent polls could each be as bad as 1% each, which would make this only about 33% reliable. (Admittedly that's the worst-case scenario.) The thing is though: it works. If you observe the pulsed scanner when a rocket is inbound (and network strength is 0), it will have several successful detection attempts well before the doors are due to be opened. The basic idea is still the same: take advantage of the cumulative chance for success from a number of relatively low-chance readings. I am just not quite sure what goes on in the background.
  7. Think of them as enhancements? You can limit those to the automation overlay in options. If there's any reason behind it, it's probably to make getting steam for the first rocket harder? I'm not disagreeing with you btw. I wouldn't mind if the tepidizer was less gimped. I'm just pointing out that not every creative use of a mechanic is a dirty exploit that needs to be shunned.
  8. Buffers in the oscillator are set to 2 seconds each. The memory gate's output tells you if a rocket is about to land. The power shutoff controls power to the scanner. Let me explain: The problem with detecting incoming rockets is that your network scan strength drops to 0% during meteor showers. A single scanner set to detect a rocket has a 20% chance to fail during this time. There are ways to mitigate this but none that doesn't involve repairing stuff fairly often, so I'm not going to go into it. What appears to happen when you give power to a 0% scanner (zero on both scan strength and network strength) is that it rolls a random number between 0 and EVENT_TIME, where EVENT_TIME is the number of seconds the event it's set to detect is in the future. If the event is more than 200 seconds in the future, no roll is made. This number is then kept internally, and decremented by 1 every second. When it reaches zero, the scanner goes active. This means that an always-powered 0/0 scanner will have a 80% chance to detect meteor showers or landing rockets in time. 20% of the time it will roll above 160 and the doors won't open or close in time. What can be done then? Well if you pulse the scanner on for 2 seconds then off for 2 seconds, continuously, it has a 160-second window to make 40 rolls, each of which decreases in likelihood to detect the event in time. With the event 200 seconds out, the chance to fail is 20%. (We roll 0..200, we're OK up to 160.) With the next pulse, the event is 196 seconds out and our chance to fail is 22% (We roll 0..196, we're OK up to 156). The next pulse, our chance to fail is 24%. All the way to the event being 40 seconds out when our chance to fail is 100% because we can't detect it in time anymore. Multiplying all our chances to fail between 200 seconds and 40 seconds: .2*.22*.24*.26*...*.98*1.00, we get 1.84307E-11. Subtract this from 1, we get 0.999999999.... lots of nines. This is our chance to succeed. For all practical purposes this detects incoming rockets with 100% certainty in time. In my build the memory reset leg is connected to the rocket ready signal through a 5-second buffer gate (during takeoff the ready and scanner signals should switch off at the same time - not always the case so a buffer ensures a definite clear). You can connect reset to whatever works for you; a "fuel is flowing" detector on your petroleum or hydrogen line should work just as well, or maybe even better. The need to have a reliable reset signal is why this setup won't work for meteors, only for rockets. My current game has had these scanners for over 400 cycles on 4 rockets, and I haven't seen a single busted door. It did fail every now and then with the oscillator gates set to 1/1 on my mega-laggy map, but 2/2 seems safe even there.
  9. I've stopped playing because of this and the microgram bug. I have a few sweepers that stop working every couple of cycles until I rebuild them or the receptacles.
  10. I've seen this happen on game load, very infrequently, yeah. You can nudge the system to work again by setting the controlling battery to 0/0 and then resetting it to 100/20.
  11. It has full details of every geyser.
  12. Very cool, thank you for your continued efforts! Here's an idea that'd save me (and probably others) a fair bit of spreadsheet time: - Allow the entry of all vents/geysers/etc, and show the output, storage & cooling requirements, etc, in one screen. Also show totals if there are multiple vents in a category, such as total water/s, total pwater/s, total natgas, total magma, metal, etc. - Allow the entry of a seed, and if it's present on Cairath's site, auto-populate all geyser info. Not sure how easy it is to parse her stuff but I'm sure she'd be receptive to creating an API if needed.
  13. Auto-sweeper ignoring items

    Sometimes it helps to enable/disable the sweeper, sometimes you have to rebuild the receptacle.
  14. I'm in a similar situation; have a few dupes who aren't allowed to leave the base yet. They have some low-prio tasks they can do inside, falling back on a few prio 3 manual generators that are always workable (no battery). So there's ALWAYS something to do. But from time to time... "idle" "idle(2)", "idle(3)". Then it goes away. Then "idle", "idle(2)". It is super annoying.