# tofof

5

## Community Reputation

30 Excellent

• Rank
Junior Member
...

## Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Enable
1. ## "Dying off" germs aren't dying off fast enough.

Game version: LU-366134 Confirmed, seeing exact same behavior in gas. Dying in gas is -29% and is much faster than 'dying off' which seems to be a fixed -3/s rather than the -367% it is supposed to be. video has been increased to 20x speed A decay rate of 367% per cycle, as worked before, naturally means that you reach 100% dead in less than a cycle. The most obvious interpretation is that it means you hit all dead at 600/3.67 = 163s, about a quarter cycle. That half-life, then, is approximately 6 seconds or 0.01 cycles. When a half-life is being used, or equivalently a percentage dying per unit of time, the number of deaths per second is an exponentially decaying curve. This is reflected in the e^-t (or 0.5^t/thalf) term in the half life equations. In contrast, a fixed death rate is linear: a graph of population vs time is simply a straight line, with a negative slope equal to the death rate (i.e. 3 deaths/second is simply a slope of -3). This change has other weird effects - you can take 2000 kg of gas in a single tile, with say 18000 germs and 10 cycles to die off at -3/s --- and let it expand into a 10x10 room, and now your die-off rate is, in aggregate, -300/s and you're germ-free in a tenth of a cycle. In fact, spreading a gas or liquid into a bunch of very low-volume tiles is about the only way to get them clean of germs now that this absurdly slow rate is introduced. Of course, for food, that's not even an option. I'm certain this change was unintentional and you should restore the -367%/cycle rate for 'dying off'. ---- If, however, this change was intentional: Then you still have a bug. In that case, it is wrong to report any half-life whatsoever once the 'dying off' state is reached, since the state is governed by linear, i.e. not exponential, decay. When quantities decrease following a half-life, the half-life itself remains constant, while the decay rate itself changes in proportion to the remaining population. Instead, you're now holding the decay rate constant at -3, which means the time to cut the population in half constantly changes, which means there is no actual half-life value to report. And indeed, I have a square of gas with 18,000 germs with a fixed death rate of 3 per second -- that's 1800 per cycle, or 10 cycles to complete death or 5 to reach 9000 germs remaining. The game is unsurprisingly reporting an incorrect 'half-life' time of 7.8 cycles at this instant, though it is constantly decreasing. Critically, it would still be incorrect if the game was reporting a "5 cycle half-life" -- because after a single half life, the time for the population to be halved again would then be only 2.5 cycles, and then 1.25, etc. The fact that the calculated half-life constantly decreases is simply further evidence of why it's wrong. If the time to halve the population constantly changes, then you don't have half-lifes at all. That's the meaning of the term, and is why the answer to "what's the half-life of plutonium 241" is "14.4 years," not "it depends on what the population* is right now." *number of atoms in your hunk of metal
2. ## Fish Feeder consumes 20 kg algae per 10 kg actually ingested by fish

To replicate: Put 200kg algae into the feeder. It immediately dispenses a single 10 kg serving. The feeder will show Storing: 190 Kg / x in the Status section of the Status tab. In the contents section of the same tab, it will show two item stacks: Algae: 190 Kg and Algae: 10 Kg. 190+10=200, good. A pacu will come and eat from the feeder now. The intended behavior appears to be that the fish removes 10 kg of food from the 10 kg item stack. However, my guess is that he actually takes 10 kg from both of the item stacks. The instant the fish eats, the feeder will dispense another 10 kg pellet. However, the feeder will now be Storing: 170 Kg / x and will have contents Algae: 170 Kg and Algae: 10 Kg. 170+10=180, bad. In other words, 20 kg of algae has been removed. The fish gains 7 calories and will eventually poop 5 kg polluted dirt, the same as if it had consumed 10 kg of dropped algae in the world. In other words, it's not simply a display bug; 10 kg of algae is now completely unaccounted for. The feeder works as expected when only 10kg (or less) is loaded in total. Put 10kg into the feeder. It dispenses 10kg and is now empty. Pacu eats 10kg algae, for 7 calories and later 5kg polluted dirt. To verify, repeat this process 10 times in succession, for a total of 10 meals. He will gain approximately 70 calories and shortly thereafter emit 50 kg polluted dirt. Works incorrectly once there's more than 10kg in the feeder: Put 20kg into the feeder. It dispenses 10kg and is now empty. Pacu eats 10kg algae, for 7 calories and later 5kg polluted dirt. To verify, fill the feeder initially with 200kg. Observe the fish will only receive 10 meals, again gaining 70 calories and emitting 50 kg polluted dirt. Note that if you set the feeder to 10 kg without a fish immediately present, you will get the 2nd set of behavior. This is becasue the feeder immediately dispenses 10 kg into the secondary item stack slot, freeing up its primary inventory to be reloaded with a second 10 kg. In other words, a feeder set to hold x kg will actually hold a total of x + max(x,10) kg when 'at rest'. (Yes, you can break my formula by e.g. setting it to hold 5kg, getting a 5kg pellet loaded into the 'second slot', and then increasing the maximum to some other number, like 200, getting the feeder filled with a total of 205 instead of 210). All of this is effectively just a second symptom of the same bug - the presence of 2 inventories instead of a single one causes all of these behaviors.