• Content Count

  • Joined

  • Last visited

Community Reputation

395 Excellent

1 Follower

About JRup

  • Rank
    Senior Member

Recent Profile Visitors

493 profile views
  1. I hope this isn't unrelated, hailing from the ancient times of, uh, January:
  2. I won't say ask "El Gabo"... But I can say that at some point the save file was "saved" on a higher version than it currently is... So it was saved in 466292 at some point and you're trying to load it in a computer with version 460672 ... (this is also seen in the bottom of your screenshot) I'm not completely familiar with all game versions but current base game version should be CS-466292... I would dare say that you need to update the game on that computer... Hope this helps.
  3. hmm, I would dare say that your play sessions are long enough to fill up the ram up to the point where loading another save is not viable/recommended. But then again you said it's only some minutes played... I also play on linux (16GB ram), it has guaranteed me mostly smooth play sessions on a 5700+ cycle base. Current save file size is about 67 MB. At this point I can't attempt to load another save after loading a session (even without playing). If I want to load another save then I have to quit to desktop and re-launch the game. I also have to relaunch the game if the memory starts to fill and the game begins to hit the swap file... (Unless I don't mind it eventually crashing... I should have made a reasonably sized swap partition, I know - but just installing everything on auto to get to the fun quicker is also a factor) So, for now, the advice stands. Re-launching the game shouldn't be that bad anyhow (I hope) and should be faster as the game doesn't need to do any special memory management mumbo-jumbo as it would have to when un-loading any current session and attempting to load a different one. These are some of my experiences and I hope they help.
  4. This kind of crash depends on many things. Like how long you've been playing and how advanced the state of the save is. (A 50-ish cycle base will definitely load faster than a 3000+ cycle base, for example.) In general it's better to re-launch the game and then load the save you need when this kind of things start to happen regardless.
  5. I'd used one of these to fill a loop in the offset copper volcano tamer I'd done a while ago. I was still on the fence about making a writeup for this specific one. But yours looks definitely better. I still need to get into making gifs That said, let's add a little bits of other applications to it. Filling loops with this is very useful as you've already said, as such, you can also make mini custom temperature sensing loops with gas that may have better precision than a thermo sensor because you can use fractions of a degree in gas pipe thermo sensors. Changing the temperature of 10 grams of any gas will be instantaneous... But how about something beyond loops? If, for example, the fill rate of the pipe before the "The 10% liquid/gas injector" (you haven't renamed it yet) is lower than the exit rate you can also integrate saturnus' inline packet stacker for great effect when you absolutely can't go lower than the valve rate: Example: your valve injects 5010 g/s but the pipe receives 4990 g/s (as seen in the bead flaker some posts prior) Packet stacker above, injector with stacker incorporated below: I hope this can also be taken into consideration.
  6. It was at OP's original post, and was removed by OP. The ping remains in our hearts now. There were also birthday celebrations in between. Welcome back, btw!
  7. Here's an example of how debug mode has a clear cut advantage: currently, pressing CTRL+F4 enables instant dig and deconstruct commands bypassing the need for duplicant interaction. (I'd appreciate having that in sandbox ) So there's that teensy-weensy detail.
  8. Pliers should be a standard part of sandbox/debug as a minimum though. I'm also for a dupe dependent functionality of pliers in regular gaming. Talking about switches, they still have a priority for dupes even though they are now usable by gamers... I guess that is an artifact of its previous design... On a different note, we haven't received the "empty pipes" (toggled by insert key) for conveyors yet, right?
  9. I don't believe it to be the same bug. When we look at the post from QuantumPion above then we see what is borked is the timing to update the sensor's data that is on top of the output from the bridge. Temperature sensors preserve last valid data and clutch because the bridge fails to provide a packet for the temperature sensor to update its own data on time. I feel I should change the title from "Do's and dont's of thermal sensors on lines" to "Do's and dont's of thermal sensors on bridge outputs" but it doesn't do justice to the fact that we shouldn't build sensors on bridge outputs for now. (I would appreciate feedback on this.) My purely speculative idealization of what's going on is that the packet that lands on the bridge output is still "in teleport limbo" and is not detected during the tick it's in that particular map compartment because the game still has to decide a route... a given route of one out four possible routes even if there is only one possible route. (Bridge outputs reliably alternate between all their facets/sides in a round robin fashion). Why I consider this to be different to the current exploit regarding water sieves: Your post relates to buildings mis-calculating an output value after the data has been input into the building. (Building = water sieve for now), My post relates to sensors not being given data in a timely fashion because the data somehow skipped the tile it was in. My hope is this distinction also helps isolate and track what's going on. So far the only commonality I'm seeing is that of data not being updated on time. This is probably unrelated, however, I believe it is still in the best interest to report that ethanol distiller outputs can also be borked; you may take this as anecdotal data but I consider it to be valid data to be checked.
  10. We might as well make the generalization that putting a sensor on the output side of a bridge can lead to unstable results. (Let's say we put forth this generalization cautiously.) I feel the need to point out that your build does not take into account something very important if the 10w overhead in powering the shutoff most of the time is something you disagree with (both versions of your build have the "vamp" but this matters not if you're already generating gobs of power): Temperature sensors do not bounce back (say to providing a red output, for example) and keep the last detected temperature in their internal memory so they will be stuck with the last known status until a new item/packet provides new data... So your shutoff will continue to consume power even after your line is empty even if the last packet was shipped. You can find an example of a limited build that addresses that in the screenshot inside the spoiler; you'll need an element sensor, to say the least: That being said, I'm happy you caught it as I see this is a food chiller you've built.
  11. Wondering if dupes just use USB instead... Anyhow, poll is doing nicely despite the fact that submitted votes are just a fraction of views' total (um, thanks?)... "But that's just how polls work"
  12. Come to think of it, now that I see this... no part of ONI says anything about stuff being AC or DC ... Love the fact that I've realized it doesn't matter in the game... (mini eye opener... bring on the tesla coils! - eh, wrong game, maybe)
  13. I think it depends on how many critters we're talking about, it's not like you're gonna have thousands of critters. Eh, oh well: I really don't know how many critters it takes to slow down a pc now. I would guess it has to do with pathing.