Maris

I hope the devs will consider introducing such an update. And if it's a DLC, the player will even have a choice. In any case, they can add a checkbox in the options to disable this physics feature, for those concerned about the CPU load.

Sorry for the off-topic, but I think it's relevant here. Critters cause lag due to unoptimized A* pathfinding, and this could be improved. A virtual layer for path tracking could be created, where the game marks whether a room has been calculated or not. The algorithm for each critter would be: Check if the room for the critter's current cell has been calculated. If not, run A*, calculate the room volume, and write the result (the volume value) to every cell of that room on the virtual (invisible) layer. If yes, just take the volume value and use it for critter happiness. If a tile was built or a block was destroyed, clear the virtual layer at the end of the tick. Otherwise it's a reusable layer that should persist for a long time without recalculation. Even if room volumes are recalculated every tick, each cell would only be used in A* once. So 1000 Shine Bugs in a 2x2 room wouldn't cause any lag at all. Sure, there are nuances for Pacus, but those can be solved by adding another virtual layer for "liquid rooms". As for liquids, this also seems fixable. Say there are three cells stacked vertically (C1 top, C2 middle, C3 bottom). If high pressure has built up in the bottom cell, the game could check not just the cell above, but two cells above. And if C1 = C2 by liquid type, merge them (C2 flows into C1), and C3 spreads across 2 cells accordingly. Yes, this slightly increases the load, but only barely, because it's just basic if-then-else. That is: IF a cell contains liquid AND pressure is too high AND the cell above contains a different liquid type, THEN ... This condition would almost never trigger.

The fonts in the game have changed, but the bug that affects all localizations (including English) remains. Hm...

Yes, and there already exist Flydo and flying creatures, so wind could affect them too. Come to think of it, this could be a broader concept - WIND. It affects both things floating in liquid and things flying through gas. Similar to other buildings, a wind-generating structure could have a defined area of effect where the wind occurs. And similar to other areas of effect (like an Auto-Sweeper), this zone wouldn't pass through obstacles. Anyway, there's a lot to think about here. Could turn out really cool! Just imagine, wind affects flying creatures. They shall not pass! How many new designs will this create?

Maybe there could be some buildings for WIND. Some existing ones: And by default there is no wind, so no horizontal movement until something happens like an item or liquid dropping onto the surface.

Right, ONI physics has its quirks. But buoyancy should logically be based on element density, not MaxMass per tile. Those are different things. And if some edge cases don't work out, Klei can always hardcode exceptions. It's not like every interaction needs to be perfectly realistic, it just needs to be consistent and useful enough. Wow, great idea! I imagine floating buildings, maybe boats or something similar. Maybe floating ice tiles, like icebergs. I don't believe ALL of this will make it into the game, but I hope so. Either way, it's not up to me to write a GDD, Klei will do it their way.

Here are a few use cases that come to my mind: 1) Passive item transport - debris floating on the surface could be carried by liquid flow, both vertically (bottom to top) and horizontally. A new way to move resources without conveyors. 2) Density-based filtering! Heavy items sink in a given liquid while light ones float. You could separate mixed debris by choosing the right liquid. 3) If floating debris could get caught inside a Mesh Tile from below, it would enable automatic resource harvesting from liquid surfaces. I want to emphasize, I'm not suggesting making the game EASIER. I'm suggesting making it more INTERESTING. This means new problems and minor inconveniences that players would need to figure out how to deal with. Thanks, that's a good example! I think there are two possible game design approaches here: 1) Make sublimating resources never float (prioritizing backward compatibility). 2) Require the player to choose the right liquid (prioritizing interesting gameplay!) - not oil, but water or something even less dense. Either way, the player gets to choose whether to enable a new DLC or not. And you can't enable it on an existing save anyway.

That's a fair concern. However, most existing designs don't rely on debris staying at the bottom of a liquid pool as a core mechanic. It's usually just an unintended nuisance. That said, if breaking existing setups is a real concern, this could be introduced as part of a DLC rather than a base game change, that way it remains opt-in and doesn't affect anyone's current playthroughs. Could you give a couple of examples of designs that would break?

I have a great idea! Although it's not new, there was even a mod for this (Floatation), but that mod hasn't been updated since 2022 and no longer works. The idea is to give items buoyancy! For example, Wood should float in Water; solid Igneous Rock should float in Molten Gold; Ice should float in Water (just like in real life), etc. This would be an amazing addition to the game within the familiar PHYSICS framework. The game already simulates density-based layering for liquids - lighter liquids rise above heavier ones. Extending this principle to solid debris feels like a natural next step. You could design schemes for "transporting" items from bottom to top or side to side. I think this would be a great addition to the game! Motivational picture:

Russian localization from Klei: I guess the length is counted by bytes, not by visible characters. (Russian UTF8 letter are counted as 2 bytes) ALSO any tags like <sub> or <sup> are counted as 5 bytes each. I think the proper way is to count line width, not bytes and not even letters. Again, localization from Klei:

Note that there are full category names, but truncated element names. This is a bug for sure.

That's the bug! It says that it needs just "decor item" even if it's non-functional, and it doesn't make a lot of sense. The fix could be to change the requirement from "decor item" to "decor>0", or to change the concept of "decor item" itself to account for its own decor. Let's say it could require +1 decor compared to +20 for "fancy decor item".