BlackLightning

Changed Status from Work in Progress to Fixed Changed Fixed In to 1.3.4

Does v1.10.1 compile successfully on your server? If so, keep using that for now. There were at least 5 Rust hot fixes. I believe 1.10.2 corresponds to the 5th hot fix.

Changed Status from Pending to Not a Bug

Tha latest version of the plugin is for the latest Rust hot fix. If you have not updated Rust yet, continue using the previous version of the plugin for now.

Changed Status from Work in Progress to Fixed Changed Fixed In to 1.10.1

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.

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.

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.

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 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.

Changed Status from Pending to Work in Progress

I've taken a look and I suspect that is an artifact of the original issue. Basically the original issue caused the item movement to be interrupted with an error, leaving your player inventory in a bad state where it has a stale record of the cookable item, so when you later try to add that cookable to your inventory again, there is a conflict because that item is already known. If this is the cause, there are multiple ways to resolve it, including the following. Reboot the server Recreate the cookable items somehow, such as by splitting each one into two stacks and then placing the original stack onto the new stack Kill your player, then disconnect from the server while dead. When you reconnect and then respawn, you will have a new fresh inventory object clear of the bad state

Thanks for reporting this issue. I was able to reproduce it with cookable items when my inventory was mostly empty. I just released a patch in v1.10.1. Please test it and report back if you experience any further issues.

Changed Status from Pending to Work in Progress

Changed Status from Pending to Can't Reproduce

Have you gotten any update from Raul or others on the Carbon team? At this point, there's not much value in keeping the ticket open as this issue isn't with this plugin.

Looking at the line of code in the stacktrace, I get the sense this isn't really a Carbon compatibility issue, but rather a Carbon framework issue, or some bad plugin that is calling hooks incorrectly. I've seen a recurring theme with Carbon servers where hooks are called with null arguments, which doesn't happen in Oxide. While it's possible for developers to add null checks in such cases, whatever is the source of the problem, it's creating unnecessary work for many developers to handle, so the problem should be handled at the source rather than in plugins that have correctly defined hooks. private void OnLootSpawn(LootContainer lootContainer) { if (lootContainer.OwnerID != 0 || lootContainer.skinID != 0) // <----- This line return; if (!_config.LootConfig.SpawnChanceByPrefabId.TryGetValue(lootContainer.prefabID, out var spawnChanceByProfile)) return; ScheduleLootSpawn(lootContainer, spawnChanceByProfile); } Here is the decompiled Oxide code for reference, which demonstrates that OnLootSpawn cannot be called with null ("this" can never be null). public virtual void SpawnLoot() { if (base.inventory == null) { Debug.Log("CONTACT DEVELOPERS! LootContainer::PopulateLoot has null inventory!!!"); return; } base.inventory.Clear(); ItemManager.DoRemoves(); if (Interface.CallHook("OnLootSpawn", this) == null) { PopulateLoot(); if (shouldRefreshContents) { Invoke(SpawnLoot, UnityEngine.Random.Range(minSecondsBetweenRefresh, maxSecondsBetweenRefresh)); } } } I can't imagine how the logic would be different in Carbon to result in this issue, so another possibility is that you have some bad plugin installed which is calling "OnLootSpawn" with null or unspecified arguments. You could try searching all your plugin files for "OnLootSpawn" to narrow it down. If you see anything like CallHook("OnLootSpawn") or CallHook(nameof(OnLootSpawn)) exactly, then that's obviously incorrect code which needs to be fixed by that plugin's maintainer. To get a directional indicator of whether this is a Carbon framework issue vs something caused by another plugin, you could also try unloading all other plugins (on a test server) and triggering loot spawns, either by directly spawning individual loot containers, or via the "spawn.fill_groups" server command (which may spawn many loot containers).

Are you seeing any specific issues on Carbon?