The Plum Gate

I realize that duplicants can tolerate a wide variety of temperatures due to the thermal conductivity of elements, but we have no baseline for understanding what the duplicant homeostasis temperature is in say, gaseous oxygen. So if this had a non zero value, could it be correlated to Oxygen? - as in temperature preference in Gaseous Oxygen. This would help further the understanding of duplicant thermal tolerance ( if we take the time to dig and do the math ). I have a gut feeling it's meant to be 293.2 K based on the temperature of debug-constructed building materials.

There's a tooltip for the "Oxygen Generation" category regarding consumption and production, consumption tooltip shows up over the main row header line for oxygen generation. Also in this tooltip, there is a logic vs math vs grammar "double negative" in that consumed is assumed to be "-" and this value is literally -[some number] reads as 'consumed' negative amounts. Maybe the primary row header should just read "Oxygen Utilization" considering that the line item covers both negative and positive use. I digress from suggestions however, the tooltip for the main line is showing up in a strange place.

The emission data from emissive solid objects, such as bottles of polluted water, polluted dirt, bleachstone, oxylite, etc, are all under-reporting their actual emission rates in the information views - this is most evident over time, as calculating emissivity based on these numbers leads to errors over long time scales. My observations strongly suggest that they under report. Although guesswork estimations based on the information presented suggest they over report - simply because I don't know how to calculate decay without resorting to extreme scripting. There's some unseen factor affecting the emission information displayed - after one cycle the sum of values presented in the information vs the actual values emitted differ. For example, ( and to reproduce this issue ). I placed a 1000kg bottle of polluted water in a vacuum chamber 4x4 tiles and observed its rate of emissivity/sublimation over the course of 1 complete cycle. Emission rates reported were noted at every shift change an an estimate was made as to how much emission volume/mass had been generated. This estimate was contradictory high, and low to the actual results by large margins - Sublimation data was collected via debug export after 1 full cycle to the best of my ability - and the mass of the chamber was analyzed by manually adding the values of each cell in the chamber. I repeated this test with a larger 6x6 cell, again with 1000kg of bottled polluted water and rand it for 2 cycles. at the end of each cycle, I took a snapshot of the masses in the chamber via export. The end result of each test; emissivity expectations very closely represented the programmed emissivity with one exception - the displayed rate of emissivity of a substance was not being displayed accurately. It varied wildly for oxylite to the point of being untestable. Polluted dirt varied between 5.9 and 6.7 g/s, bleachstone performed exactly the same way. Polluted water was by far, the most reliable under-reporter. So I deferred to higher maths and snooping to figure out what to expect from a bottle of dirty water, and came up with this python script: This calculates emissivity based on the programming model and has much higher per second average emission rate displayed for a given moment in time from the outset of the experiment until the end. The periodicity reflected here for 1 and 2 cycles of emission gave remarkably accurate results for the mass emitted and remaining vs that of the test data extracted after 1 and two cycles. The margin of variance between the calculated and measured results were small.. cycles = 1 # cycles to run, choose one or the other here. ticks_to_run = 0 # sim ticks to run, leave at zero unless you know how many ticks to run. # DirtyWater parameters, we're ignoring min amount and max emission pressure for ideal emission circumstances rate = 0.0000400000026 power = 1.0 # Other emitters # Dolluted Dirt, and Bleachstone # rate = 0.000200000009 # power = 0.5 # Oxylite # rate = 0.0100000007 # power = 0.7 # Internal veraibles submass = 0.0 mass = 1000.0 # test mass, in Kilograms spt = 5 # ticks per second spc = 600 # seconds per cycle blocks_per_cycle = 24 # NOTE: casts for modulus operator as int in case of flub. if ticks_to_run > 0: ticks = int(ticks_to_run) print("Running ticks:", ticks) else: ticks = int(spt*spc*cycles) print("Running cycles:", cycles) # Data print rate, sorry this is as verbose as I want it to be right now - and it's practically hard coded. Prints at the start of every shift block. verbosity = int(spc / blocks_per_cycle * spt) # these are all whole numbers and = 125 under default conditions. avg = 0 error = 0 cc = 0 for a in range(0, ticks): if mass <= 0: # check for personal wisdom. TODO:Also, check for min ammount at some point - polluted water stops sublimating. break # It's likely that emission rates were defined as g/s and not g/tick. This value it the grams per tick for the purposes of calculating simulation emission data. var = pow(mass, power) * rate / spt # The meat of sublimation. At this moment in sim-tick-time, this amount of mass is being sublimated. # Note: var = pow(mass, power) * rate, will give you the initial emission mass in Kg/sim second # The lovely thing about this is that each sim tick, mass is sublimated from the emission medium, and the subsequent ticks takes this into consideration, # therefore, a calculation for each sim tick must be made in order to determine the rate of decay and account for the loss of mass. if not (a % verbosity): # print resting mass and emissive mass values at the start of every shift block. Without change, this is every 25 seconds at 1x game speed. print("Currrent mass: ", mass, ", Current sublimation mass:", submass) avg += avg + var # adds the mass to the avg value. Starts at zero for init purposes. if not (a % spt): # if on some division of ticks per second where a is divisible by the ticks per second, ...thus denoting the top the next or end of a sim-second. # calculate the displayed and actual averages # eavg = avg * error # calculate the erroneous division of accumulator average. As if there are ticks per second + 1, per sim second. avg = avg / spt # calculate the actual average over the last number of ticks per second. if not (a % verbosity): # display the data at shift block intervals. print("Average actual sublimation rate g/s:", avg * 1000.0) # , " Displayed average emission rate g/s:", error * 1000.0, " @tick#: ", a) # resets accumulator values every sim second. avg = 0 # eavg = 0 # This reflects conservation of mass as observed through testing. mass -= var # subtract sublimated mass from emission body. submass += var # add sublimated mass to sublimation total if not (a % (spt*spc)): # Print cycle identifier...somewhere. print("End of cycle ", cc) print("Remaining mass: ", mass, "Sublimated Mass: ", submass, "After ", a+1, " sim tick(s).") cc = cc + 1 # cycle incrementor # Print remaining mass at end of defined calculation period. # print("DBG_run_over, ignore.") # because of 0 indexed ranges, print end result print("Remaining mass: ", mass, "Sublimated Mass: ", submass, "After ", a+1, " sim tick(s).") The emission rate averages calculated from the above math differed from what is shown in the information for the objects by a large margin. At first I thought it was a fixed number, but that varied over time as well. After much toiling and many hand written notes on the matter, I have come to the conclusion that there is indeed some UI bug at work. Included are a couple of test templates.Test_PDIRT_1T.yaml and Test_PH20_1T.yaml 6x6 walled chambers. These are the results of the contents of a 6x6 test chamber ( the template does not have walls ) - data from these two were parsed, and summed via python pyyaml library. This data was then compared to the theoretical output of the script above for the purposes of determining where the math was going wrong on my end. c1tt1.yaml after one cycle. And c2tt2.yaml after the second cycle. Data calculated is fairly accurate for perfect conditions. dirtywater.py - the script above, no dependencies - maybe latest version of python. Parameters are included for oxylite, bleachstone, and polluted dirt in the comments at the top of the script.

Index -> Buildings - > Power index list contains the atmo sensor, this isn't a power item category. It was at one point a power switch, but that changed in the automation upgrade.

Some super category links leads nowhere in description of buildings however they have valid super categories when using the search function, ie automation, power. There's a valid page regarding power in the codex as: Index -> Buildings - > Power - it shows all the buildings that deal with power generation. Perhaps the super-categories deserve their own Codex headers: for instance a power super category might have a content page explaining energy creation, power runoff and power storage ( with indices link list to buildings below this ).