• Announcements

    • JoeW
    • JanH

      Rhymes with Play 149 - Oxygen Not Included (Update Preview Stream)   07/26/2017

      On this week's Rhymes with Play episode, our team will be playing and discussing content that we are currently developing for the upcoming Oxygen Not Included update. As always the live stream will be going live on Thursday (July 27) at 3:30 PM Pacific / 10:30 PM UTC only on the Rhymes with Play Dev Cast on Twitch. NOTE: As Oxygen Not Included is still in active development, content shown on Rhymes with Play streams may change before going live on Steam Early Access. Where is it?
      On our official Twitch Channel: https://www.twitch.tv/kleientertainment When is it?
      Twitch Stream Date: July 27, 2017 10:30 PM UTC (Coordinated Universal Time)
      6:30 PM ET (East)
      5:30 PM CT (Central)
      4:30 PM MT (Mountain) Here is a handy tool you can use to figure out what time that means for you. Check out the stream announce thread for discussions!


Registered Users
  • Content count

  • Joined

  • Last visited

Everything posted by rezecib

  1. Hmm, well technically the hatch consumption rate is affected by their animations, so it's a bit hard to get exact. But they could produce up to 1000 g/s, and each fertilizer maker makes 120 g/s. So at max capacity you would need 8.33 fertilizer makers per hatch. If you can keep a natural gas complex's temperature below 70C (should be quite feasible, probably don't need to do anything actually), then two hatches could eat all the fertilizer, giving about 1.92 kg/s of coal, which if taken to (two) coal generators would give almost 1.2 kW of power. Removing the coal would be somewhat annoying and uncomfortable to the dupes, though, so you might want to have a hydraulic timer system (Klei add real timers pls <3) to periodically unpower a door so that the access controls get disabled and dupes can enter to sweep up the coal.
  2. Because succulent_picked is missing an entry in STRINGS.NAMES, when recipepopup looks for STRINGS.NAMES.SUCCULENT_PICKED, it finds nil. This results in the ingredient tile for it having no tooltip. If a STRINGS.NAMES entry were added, then this line could also be removed from prefabs/succulent_plant.lua: inst.name = STRINGS.NAMES.SUCCULENT_PLANT
  3. I don't think so actually. Hmm perhaps. Since it's an item, it's probably using the Sublimates component, which means mechanically it would function more like slime in terms of production of polluted oxygen. It doesn't seem like it would be that hard to mass-produce bottles, you'd just need a row of wash basins and have duplicants walk by frequently. But... I'm not sure it would really be worth the time, because the animation for the wash basin is a bit long, and basins require water to be delivered as well. Although it takes a lot of space to evaporate polluted water, it is extremely easy to scale up and is pretty much entirely maintenance-free once it is scaled.
  4. Summary: Farming: New harvest system: plants have a requirement for air pressure, *body temperature* (not air temperature as before), illumination, atmosphere (set of allowed gases), and presence of liquid. If any of these are not met, plants won't grow. Seeds are produced with a % chance on each harvest. Farming research has been split into 3-- Basic Farming (Tier 1) as before, Meal Prep (T2, Cooking Station, Refrigerator, Farm Tile), and Agriculture (T3, Fertilizer Maker, Hydroponic Farm, ?Seed Splicer?). It looks like Aquatic Farm Tiles are gone. Mushrooms are now called Dusk Caps and look pretty and purple. Swamp Lilies are now called Balm Lilies and show up in the Caustic/purple biome. They produce flowers with "medicinal properties". Liquids: We saw the Liquid Bottler before, which is built over a liquid and allows dupes to bottle the liquid. We also have a Bottle Emptier now, to which dupes can deliver bottles to release the liquid. You can set which liquid the Emptier accepts. It empties bottles at a certain rate (seems to be somewhere in 1-10 kg/s) Bottled polluted water will evaporate, making polluted oxygen. Mopping makes bottled liquids. Diseases: As before we saw the overlay, with germs being shown on cells, dupes, and having sources like outhouses. Current diseases: Food Poisoning, Trench Stench, The Spores, and Slimelung (seems to be in the Caustic/purple and Swamp/green biomes). Things like hypothermia that aren't germ-based are separate and still exist, may get called "Ailments". Duplicants have an "immunity meter" that can be monitored in the vitals panel, and contact with germs depletes immunity. When it hits zero, they get the disease. They appear to innately replenish 10 per cycle. The Immunity stat gives them extra immunity meter. Germs die faster when the area is heated up. New Wash Basin building. Duplicants use it if they walk by it (in a particular configurable direction), allowing you to control when they use it by controlling duplicant pathing. Water is delivered to wash basins, and when used they produce bottles of polluted water (with the germs in the bottle). The hand sanitizer uses the same walk-by system, but destroys the germs instead of moving them. Polluted Water and Oxygen aren't sources of disease anymore, but they allow germs to spread very quickly. Slimelung seems to reduce breath capacity and causes them to produce slime. Miscellaneous: New Trait, Caregiver, appears to increase Medicine New negative traits, Squeamish and Trypophobia. Presumably affect stress generation in some way. Storage Compactors now have a slider for how much you want to store in them (can request less than the full 20 tons). Plumbing and Ventilation now have separate building tabs. Priority overlay has been removed from the overlay strip, but using the priority tool still shows it. New creature, Shine Bug, emits light and has +10 Decor like other creatures. Daily report now breaks down travel time, and time spent doing different tasks. Helps figure out what duplicants are spending time on (like delivering)
  5. Exact numbers depend on the pressure that the wheezewort output reaches, since that determines the backflow along the wheezewort staircase. I don't think anyone has a model for how gas flow over pressure gradients actually works in the game right now. If we get one then you should be able to get a theoretical calculation of its efficiency. Perhaps a good experiment for someone to try :P. I would do it but I will be out running around in the sweltering heat today
  6. CO2 is also a good choice because dupes entering and leaving won't leave little pockets of CO2 messing up the pressure. What's your setup? The way Kasuha has it, it has to pass the input of the thermo regulator to get to the overflow bridge. Packets always enter an input if they can, so they should always enter the thermo regulator unless it is stopped. Although perhaps if you are a bit over-capacity then some may bypass it because the output of the thermo regulator may be blocked.
  7. I ran mine for over 100 cycles without needing to do anything about the heat (granted, mine wasn't 100% thermodynamically sealed-- I had some doors). If you want, you can try dripping the 40C polluted water coming out of the scrubbers to cool the rest, but for the most part the fixed-temperature outputs of the fertilizer makers do a lot to keep the temperature stable. As long as you build everything out of gold amalgam it should be fine, and stabilize around 60-80C.
  8. @natemiddleman Yup, I've built it before. I put up the math and a guide on the wiki. Edit: Also, fun fact I calculated last night was that polluted water on its own is worth a net of up to 3.72 J per gram, using a triple system (scrubber + fertilizer maker + natural gas generator) like this. Edit 2: Also, it uses less water. Only 1919 g/s-- the only water input required is for the scrubbers, and two scrubbers can only use 2 kg/s total.
  9. When a circuit overloads, the bridges are targeted first. However, CircuitManager assigns wire bridges to the circuit they cross over, rather than the circuit they are linked to. This means that wire bridges don't overload if there's no circuit under them, and overload at the wrong time. I've attached a save demonstrating this. It consists of a heavi-watt circuit and a normal circuit, each with more than 1 kW power drain. The wire bridge on the left should be part of the heavi-watt circuit, but overloads when the normal circuit is powered. If it's removed, the two wire bridges on the right do not overload, but a wire does instead. I believe this is due to the following part of CircuitManager.Rebuild: HashSet<UtilityNetworkLink>.Enumerator enumerator3 = this.bridges.GetEnumerator(); while (enumerator3.MoveNext()) { UtilityNetworkLink current3 = enumerator3.Current; int cell = Grid.PosToCell(current3.transform.position); ushort circuitID3 = this.GetCircuitID(cell); if (circuitID3 != 65535) { this.circuitInfo[(int)circuitID3].bridges.Add(current3); } } It uses the center cell of the wire bridge to determine which circuit it's attached to. Instead it could use UtilityNetworkLink.GetCells() to get the cells the bridge is actually linked to, and use one/both of those to determine the circuit. WireBridgeBug.sav
  10. This looks to be intended. Looking at the code, that seems to be the case. In CircuitManager.Rebuild, this is what I see for the part about bridges: HashSet<UtilityNetworkLink>.Enumerator enumerator3 = this.bridges.GetEnumerator(); while (enumerator3.MoveNext()) { UtilityNetworkLink current3 = enumerator3.Current; int cell = Grid.PosToCell(current3.transform.position); ushort circuitID3 = this.GetCircuitID(cell); if (circuitID3 != 65535) { this.circuitInfo[(int)circuitID3].bridges.Add(current3); } } So it's deciding which circuit it's a part of based on the cell it's in. But which cell is it actually in? WireBridgeConfig lists the connection points at offsets from the main position: utilityNetworkLink.link1 = new CellOffset(-1, 0); utilityNetworkLink.link2 = new CellOffset(1, 0); So we know that the actual position (offset 0,0) is the center of the bridge. (this isn't the case for all world objects) I also looked into how GetCircuitID works, and it was a long path but seems to all work as expected.
  11. I just responded to your post on Reddit, but might as well repeat here. The issue seems to be that the report doesn't count Power Usage: Removed correctly. It only counts towards that when power is removed directly from a generator/transformer, and ignores batteries. So the reason you see it doubling is probably because the generators are not doing their short bursts at the same time, so you're seeing twice as much power being removed directly from them without a battery as an intermediary. I submitted a bug report on this with a save file demonstrating it and a suggested code fix. Edit: To do the math on it, you produced 282 kg of oxygen. This means consuming 317 kg of water. 31.7 s of uptime for the water pump (pumping 317 kg at 10 kg/s) 634 s of combined uptime for the gas pumps (pumping 317 kg of gas at 0.5 kg/s) 317 s of combined uptime for the electrolyzers (using 317 kg of water at 1 kg/s) Of course, the pumps might actually run at slightly lower efficiency, but if they were perfect, then this would be about 198 kJ of power removed. So it's definitely under-reporting, and when you connected the two you got it to under-report slightly less by reducing how much it was drawing from the batteries.
  12. The Power Usage report adds to the Added count when a generator generates power, but it only adds to the Removed count when power is removed directly from the generator (by a consumer). This means that any power that's removed from batteries isn't counted; so you can have batteries draining with non-negative Net Power Usage. I've attached a save showing batteries draining with zero Power Usage: Added, Power Usage: Removed, and Power Usage: Net. I believe this could be fixed by adding to the report in CircuitManager.PowerFromBatteries: private float PowerFromBatteries(float joules_needed, IList<Battery> batteries) { int num; float batteryJoulesAvailable = this.GetBatteryJoulesAvailable(batteries, out num); float a = batteryJoulesAvailable * (float)num; float num2 = Mathf.Min(a, joules_needed); // begin added code ReportManager.Instance.ReportValue(ReportManager.ReportType.EnergyCreated, -num2, null); // end added code joules_needed -= num2; float joules = num2 / (float)num; for (int i = batteries.Count - num; i < batteries.Count; i++) { Battery battery = batteries[i]; battery.ConsumeEnergy(joules); } return joules_needed; } PowerUsageRemovedBug.sav
  13. It looks like you based everything on a single-player mod. You'll run into fewer hiccups if you look at the DST code and mods as a reference instead. For example, in the modinfo you have an API version of 6, but DST uses 10. But I think your main problem is that you never add networking to sooty. Look at a simple prefab like the spear as a reference.
  14. Yes, painting requires you to unpause briefly before it takes effect.
  15. Not in the list. Looking at the code for it (DebugPaintElementScreen), it seems that all loaded elements should be there (there is a flag for excluding from the list but nothing seems to set it), but... it's not. I was able to edit the IL code to substitute the manually-specified CO2 for SlimeMold, and that let me paint it, though.
  16. It's actually shorthand for mole :P. It's basically a specific number of atoms (Avogadro's number), the number chosen so that the total mass is the about the same number of grams as there are particles in the atomic nuclei. So a mole of water is 18 grams, because each of the two hydrogens has just one proton, and the oxygen has 8 protons and 8 neutrons, for a total of 18. (the numbers actually end up being very slightly different because it's averaging over the frequency of different isotopes, which can have extra/fewer neutrons-- in the case of oxygen it sometimes has one or two extra neutrons, but ~99.8% of the time it just has 8) But yeah, I'm definitely having a blast with the math in this game
  17. The best way to absorb the heat is probably polluted water. Drop polluted water down there, let it turn into steam, find a zone where the temperature gets low enough to pump, and pump it into a void.
  18. A bit of a necro, but thanks to Risu's help here, I learned where the code was controlling this. However, it does pass the values into Sim so I had to do an experiment to really narrow it down. The relevant code is: debugProperties.contaminatedOxygenEmitProbability = 0.001f; debugProperties.contaminatedOxygenConversionPercent = 0.001f; So each time it bubbles, it converts 0.1% of the mass to polluted oxygen, as The Flying Fox found. The probability requires an experiment, because although it's also set to 0.1%, we don't know how often it rolls. Changing the probability to 1, I did an experiment with a pool of polluted water. It decreased from 499 kg to 478.4 kg over 10.36 seconds. This is an average loss of 1.988 kg/s. Using the average of the start and end mass to calculate a theoretical loss rate (based on the code), we estimate 0.489 kg per emission. This is off by a factor of 4, so it seems that the probability is rolled 4 times a second. I also tested briefly to see if it was just using the surface cell's mass or the whole column, and it just uses the surface cell. So the exact amount of polluted water matters a lot; near 800 kg on the surface it will be maximized, and with just a thin layer it will produce almost nothing. So to turn this into practical knowledge, we can now find the expected conversion rate of polluted water: it's (4 rolls/second)*(0.001 emissions/roll)*(600 seconds/cycle)*(0.001 /emission)* = 0.0024 /cycle, or 0.24% converted per cycle. So in the best case, if you keep a surface cell at 800 kg of polluted water, you can get 1.92 kg/cycle of polluted oxygen. Realistically it will be a bit lower than that, because at 800 kg you are exactly at the threshold for spilling over, which would create a very shallow layer in the next cell up, with extremely low production.
  19. I'd been using dnSpy to look at the code. Against your judgement, I gave recompiling it with changes a try (looks like dnSpy doesn't support injection so I'll have to get something else for that). After one false start, I got it to work as you observed, with polluted bubbles everywhere. But perhaps this approach will fail for anything more complicated.
  20. @Risu Hmm, that is concerning. I have no experience with injection, do you have any pointers on where to get started? 0.02 would match up with the reported value of 2 g/s, given that consumption is 100 g/s. I guess that would mean that mouthbreathers emit 4 g/s? As a side note, I've been trying to find the code for polluted water emitting polluted oxygen, again without success. I don't suppose you know anything about that?
  21. Hmm, well we can get a rough estimate of the energy output of sleet wheat. They're made of genetic ooze, starting at 20C, and the ideal temp range is -40C to -35C. So let's say you're keeping the air at -40C; the temperature difference is 60C, and the thermal conductivity of the atmosphere will limit the transfer (best case, chlorine, but CO2 may be more practical, so we'll use 0.0146 W/mK. Surface area and thickness are also part of the calculation. I'm not sure exactly what those values should be, but based on some digging in the code it looks like it's using the default values in the SimTemperatureTransfer component, which are 0.01m for thickness and a surface area of 10 m^2. So, the heat transfer rate should initially be (0.0146 W/mK)*(10 m^2 / 0.01 m)*(60K) = 876W. At maximum capacity, a thermo regulator cooling 1kg packets of hydrogen can do (2.4 J/gK)*(1000 g/s)*(14K) = 33,600W. So a single thermo regulator, assuming you can adequately cool it, should be able to handle up to 38 plants. However, there is likely to be significant heat leakage into the system, and that's harder to quantify without experimentation. As a side, I was curious how quickly the plant itself would cool under these conditions... (3.47 J/gK)*(400000g)/(876 W) = 1584 s/K, or about 2.6 cycles per K. So.... the plant mass cooling should probably be ignored.
  22. I think your factor of 200 is right, it's just that the kW to W conversion wasn't as straightforward as I expected. It displays kW * 5 as W, which is off by a factor of 200. But I was wrong about the building mass being part of that factor of 200, which is why for a ceiling lamp (with no exhaust to account for), it comes out as off by 1000 if you calculate with the in-game values (producing 200x the heat, being absorbed by 1/5 the mass, for 200*5).
  23. @Masterpintsman @Xadhoom The issue with building heat is more in that the UI is lying to us than that the game isn't being realistic. Buildings actually have 1/5 the mass they say they have, and the watts are actually kilowatts * 5. Accounting for both (1000/5 * 5), you can multiply the reported heat output by 1000 and get correct calculations for how much the building heats up. Fixing the display to show kilowatts is easy, but I'm not sure how you'd go about communicating that the building has 20% of the mass. You could have it list 20% of the mass, but when you build it and deconstruct it, you get the full mass back out, which would be weird-- although I still think that's preferable to the current situation. Edit: @Kasuha Re-thinking this, W->kW and 0.2x kg should result in a factor of 5000 instead of 200 (1000x the heat actually produced, and 1/5 the mass to absorb it, so it will raise 5x as much)? Doing a test with a ceiling lamp, my calculated temperature difference was off by 1000x rather than 200x. Delving into the code, it lists the kW as 0.5, and using this for the calculations along with the 50kg -> 10kg matches observed temperature changes. I see that the code for converting this 0.5 kW to 2.5 W at the front end multiplies the kW by 1000*0.005 = 5 (and then lists it with W instead of kW). Maybe this was changed since you did your experiment?
  24. Perhaps a flat arrangement with a separate line of piping going up each farm tile? If you use a power-of-2 number of farm tiles (16, 32, 64), then you can do an even splitting just by pipe branching. Otherwise you can use valves, but it may be annoying to tune each one to match. That way cooling will at least be pretty even. You could also use ceiling lamps over each plant for fine-tuned heating, controlled by a thermo switch.
  25. @chemie I haven't tried cooling sleet wheat farms, but given that the plants start out with 400 kg of genetic ooze at 20C, it might take a lot of cooling. But for waste processing (freezing CO2 and Chlorine, liquifying oxygen), I was running hydrogen at around -200C.