Mini flies super slow when floaties are out

it's been happening since the new update

Same here, please fix @BlackLightning 

Changed Status from Pending to Work in Progress

I haven't been able to reproduce this issue. Do you have any other plugins which could be affect helicopters or buoyancy? Could you try without other plugins installed? For example, after ensuring this is the only plugin loaded, spawn a new helicopter, verify it flies normally, then make it touch water, then make it leave water and check if it's still flying normally.

Are you using the official version of the plugin from this website, or a custom and/or pre-release version? There is a pre-release version going around so I wanted to rule that out.

I'm using this version. I will try to check locally disabling other plugins

the only other mini plugin i have is minicopteroptions

Here's what AI said 

Quote

Naval update (Feb 5, 2026) rewrote buoyancy code and improved water physics.

Floaties visible (submergedFraction > 0) activates underwaterDrag=2 on Buoyancy component, slowing flight.

Fix: Raise minicopter buoyancy points' Y from -0.1f in config.

Can you help clarify what is the original problem? The support request title and opening comment don't provide much detail, so I want to make sure I understand the symptoms and how to reproduce it. As I said, I cannot reproduce it, which could mean I just don't know what to look for from lack of issue detail.

When originally reading the support request, I got the sense that the helis were not returning to normal flight after taking off from the water, for an extended period of time, which of course would be a very big problem if true. That is what I tried and failed to reproduce.

For some context, the plugin achieves buoyancy for helicopters by reusing a Rust-defined UnityEngine.Component called Buoyancy, which automatically detects water and applies increased drag when touching water or underwater. The plugin subscribes to the Buoyancy.SubmergedChanged callback to find out when water contact begins and ends in order to determine when to show the floaties. When the helicopter is very close to the water, it's possible for the submerged state to rapidly change, so to prevent the floaties from flickering, the plugin delays hiding them for a few seconds after the last contact with water, but this has no bearing on the drag itself. This means that once you take off from water, the drag should quickly/instantly return to normal even though the floaties may stay visible for a few seconds.

why not just disable the underwater drag?

That's certainly an option, but the experience isn't ideal as the heli sinks and rises too fast. You can disable it for your server by setting the "Underwater Drag" option to 0 in the config.

That also won't fix the issue (which some users are reported, though you didn't mention) where the floaties are staying visible indefinitely. It seems to stem from the game thinking the helis are still underwater for some reason. My best guess is that the buoyancy system is malfunctioning.

1 hour ago, BlackLightning said:

That's certainly an option, but the experience isn't ideal as the heli sinks and rises too fast. You can disable it for your server by setting the "Underwater Drag" option to 0 in the config.

That also won't fix the issue (which some users are reported, though you didn't mention) where the floaties are staying visible indefinitely. It seems to stem from the game thinking the helis are still underwater for some reason. My best guess is that the buoyancy system is malfunctioning.

Oh yeah, I also have the issue of floaties staying visible while out of water

I have been testing some more. I still can't reproduce the issue on the mainland, but I am seeing some similar behavior in the Deep Sea region. Sometimes the floaties don't even appear, in which case the heli flies like normal, and other times the floaties stay on indefinitely, in which case the heli flies slowly.

When I disable batching via the convar buoyancy.use_batching false, then the issue goes away, but I don't necessarily advise that as it could worsen performance. Batching is part of the buoyancy system overhaul so it makes sense that something in there could be going wrong.

Doing some debugging, I found that when the heli is in the deep sea, the SubmergedChanged callback gets spammed with the same value (either true or false) over and over, which shouldn't happen unless the actual submerged state is changing. Looking into the Rust code, I found what looks like a coding mistake in the logic that evaluates whether the submerged state has changed for a given Buoyancy object. When it compares the current and previously cached submerged states, the bug allows comparing the current state to the cached state of a completely different buoyancy object. This definitely explains all of the symptoms we are seeing.

At this time, it's not clear how to mitigate this issue in the plugin, but I will try to contact Facepunch to fix the issue.

It's fixed for me with lastest FP patches.