Jump to content

BlackLightning

Creator
 View Profile  See their activity

  • Posts

    207

  • Joined

  • Last visited

  • Days Won

    3

 Content Type 

Support Replies posted by BlackLightning

    Posted

    Here are some troubleshooting suggestions.

    1. Start with the plugin's default configuration.
    2. Obtain the Zipline Tool by running the chat command "/zipline buy". Confirm that the crossbow you were given has the skin from the config ("Zipline Tool" section). It should look something like the image on this workshop page: https://steamcommunity.com/sharedfiles/filedetails/?id=2793006815
    3. Equip the Zipline Tool. Verify that when you equip it, you don't see "You don't have permission to use the Zipline Tool" in that chat. If you do see that message, you need to grant at least one ruleset permission. Instead of that message, you should see something like "[Zipline Tool]: Attack to set start point".

    If you don't see any message printed in chat when you equip the Zipline Tool, then the plugin is probably not recognizing that item as a Zipline Tool for some reason, though I'm not aware of any reason that would happen if you obtained it via the "/zipline buy" command. You might want to check for any plugin which tries to automatically skin items, which could be altering the crossbow's skin when you receive it.

    Posted

    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.

    Posted · Edited by BlackLightning

    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.

    Posted · Edited by BlackLightning

    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.

    Posted

    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.

    Posted

    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.

    1. Reboot the server
    2. Recreate the cookable items somehow, such as by splitting each one into two stacks and then placing the original stack onto the new stack
    3. 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

    Posted

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

    Posted · Edited by BlackLightning

    Thanks for reporting this issue. This is an issue with the plugin, not an issue with configuration. This use case is something I documented on the plugin page, but seems I didn't adequately test it before.

    I was able to reproduce the first case, where 2 other bags are consumed. That actually makes sense and matches what the UI says, but it's not how it was intended to work.

    I couldn't reproduce the second case. Instead, I saw that I was not allowed to perform the upgrade. However, when I loaded the Item Retriever plugin, then I saw an issue where both bags were consumed and the new bag disappeared. This is an incompatibility where the Item Retriever plugin doesn't know how to ignore an item, whereas the internal item searching logic in Bag of Holding does understand that concept.

    I will send you an update over DM to test, along with a patched version of Item Retriever (if you are using that). If that works, I'll release the Bag of Holding update, and coordinate with Item Retriever dev for an update to that as well.

    Edit: Actually, it works if you set the required amount to 1. Since the plugin would ignore the bag being upgraded, it displays and functions correctly, only counting other bags as valid ingredients. This is probably what I was doing when originally testing this idea during the early plugin development. However, this would have been broken in the Item Retriever case (which came later) if the bag was empty, as the bag would then consume itself.

    Posted · Edited by BlackLightning

    If you get any pushback from the developer, simply emphasize that the user experience is wrong. Moving an item with right-click or hover-loot should not empty its contents. Items should also not be emptied when added to a container by a plugin (i.e., when the virtual backpack is initialized). This is not a plugin compatibility issue, it is a stacking plugin issue, which happens to present a worse experience for plugins that allow players to store large quantities of items inside other items.

    The developer may "blame" this issue on there not being a proper hook for their use case, but that should cause them to not try to implement that feature in the first place, rather than degrade user experience by implementing it the wrong way.

    The developer has previously insisted that other plugins, such as Bag of Holding, should not use the CanStackItem hook while Stack Modifier is loaded, as SM should handle it correctly. If the developer wants to make that claim, they need to also implement it correctly. If they want to back down from that claim, they can expose a way for other plugins to dictate the behavior of that hook instead, since if BoH tries to use that hook now it will result in a non-deterministic conflict.

    Posted · Edited by BlackLightning

    I parsed through both descriptions, and something occurs to me, especially regarding the second case where trying to take the bag spilled out the contents.

    Are you using Stack Modifier? Around the time that Bag of Holding was in beta, an issue was discovered with Stack Modifier where it could empty the contents of any item, including these bags, in order to allow the item to be stacked with another. The way we solved it was by updating Stack Modifier to only apply that behavior to items that appear to have a container in vanilla. However, the Facepunch Backpacks update required some changes to be made in Bag of Holding, which unfortunately have resulted in that logic in Stack Modifier no longer working, so it looks like that issue should have returned.

    To reproduce the issue, you can probably do something like the above screenshot. Basically, make two bags with the same skin/capacity, place items into one and place that one in another container, then right-click or hover-loot that bag into your inventory. I'm guessing this will cause it to spill out and possibly stack with the other bag in your inventory.

    To mitigate this issue, you should be able to disable stacking of large halloween loot bags, as that will prevent Stack Modifier from trying to stack them.

    Note that even if you are not using Stack Modifier, this issue could exist with other stacking plugins.

    The proper solution should be for the Stack Modifier maintainer to simply remove this "auto-unpack" logic from the plugin. This is suggested because the developer implemented that logic under the incorrect assumption that any time the CanStackItem hook is called, that the player must be intentionally moving one item onto another, which is not true because the game will automatically test various similar-looking items for stack eligibility when right-clicking/hover-looting, which is inadvertently causing this issue. I suspect this is the same root cause as the issue happening in the Virtual Backpack. In a previous discussion with the Stack Modifier developer, he was hesitant to remove this logic because he believed "people expected it", and "it wasn't causing issues since it hadn't been reported" even though it was made clear to him at the time that the logic was wrong.

    Posted · Edited by BlackLightning

    Can you paste the exact wording used by the all reports of this issue? Sometimes the player's description of the issue includes nuances that can help with the investigation.

    When you say custom bags, do you mean bag profiles that you defined in the config, in addition to the ones provided by default? Note that there is no functional difference between custom bags and the ones provided by default, they all simply operate according to how they are configured, so any correlation here is probably coincidence.

    As for items spewing on the ground, that sounds like a capability of the Backpacks plugin, where opening the backpack can spew overflowing items if the backpack capacity has reduced since it was filled. Bag of Holding doesn't do anything like this, so that sounds like something is happening on the Backpacks side. Did players see the contents of the bag spewed out or was the bag itself simply spewed out of the backpack with other items from the backpack? If items spewed out of the bag itself, I don't know what would cause that.

    Items being unusable is a known phenomenon in the Rust modding world which happens when the HeldEntity of an item was killed. This doesn't happen in vanilla Rust, but can happen in some modding situations which should be avoidable/fixable.

    • Servers using item cleaner plugins such as Broken Items Cleaner will probably see this often because that plugin aggressively kills HeldEntity instances if it isn't aware of the item that created the HeldEntity,. That plugin isn't coded to find items inside of other items recursively, so it may break items inside of bags.
    • There was a brief issues after a Rust update quite a few months ago where placing a bag on the ground and picking it up would kill any HeldEntity instances associated with items inside the bag. This happened because Rust by default tries to parent the HeldEntity instances to the bag world model entity, so when the world model entity is killed, Rust automatically kills the child entities. This was resolved  in a previous update by preventing the HeldEntity instances from being parented to the dropped bag.

    Posted

    This error means the plugin failed to display the player's Economics balance on the bag upgrade screen because it was too large for a 32-bit integer to hold. I can fix this, but it wouldn't be the cause of their balance being so high.

    When a number jumps really high, one possibility is that it under flowed and wrapped around to the max value. I suggest you check any config that subtracts Economics balance to see if you might be withdrawing a negative amount somewhere.

    Posted · Edited by BlackLightning

    I'm not aware of any reason that the default profiles would behave differently than custom ones in regard to gather mode. Can you share your config? I can try to reproduce the issue on my side using your custom bag profiles. Would be great if you could test the default profiles on your end as well to see if those work.

    Posted

    It sounds like a bug. At least, the expected behavior is for the fish to go into the bag.

    I just tested and wasn't able to reproduce this issue. I tested using the preset Food & Medical bags (shouldn't matter what type of bag it is, as long as it accepts the item), spawned in some fish, dropped them and then simply picked them up. The fish went into the empty Food & Medical bag that I was wearing in the backpack slot. I also tried wearing the bag in a non-backpack slot, having the bag in the belt, and having it in the main inventory. I also tested by actually fishing. I also tried disabling "Player wearable bag limits" feature in case that was related. Same result in all cases, the fish always went into the bag.

    In your case, since having a fish in the bag seemed to resolve the problem, it sounds like maybe the plugin thought the bag was in Gather Existing mode rather than Gather All mode, but I've never heard of that issue happening before.

    Posted · Edited by BlackLightning

    Which version are you using? People were experiencing similar issues which should hopefully have been addressed in v1.8.2 and newer. According to the download history on CF, you haven't downloaded the plugin since I released v1.8.2 so I presume you are still running an older version.

    Posted

    I just tested and did not find any issues with the attack helicopter. I had no other plugins loaded, only Buoyant Helicopters, then I spawned a new attack helicopter, I landed it on the water's surface, dismounted to allow the engine to shut off, mounted again, started the engine and flew away. Are you using any other plugins that affect the attack helicopter?

    Posted

    I am currently away on holiday. I will be back tomorrow and can investigate then to see if I can reproduce the issue. It's possible that I overlooked this issue before (if it's a shortcoming with this plugin) because I may have been testing with another plugin installed at the time that covered up the issue such as Underwater Vehicles.

    Posted · Edited by BlackLightning

    Showing inner tubes only some of the time is currently better for client performance but worse for server performance, but only marginally worse because hiding and showing is fast.

    I should add a disclaimer that this is subject to change. I could make the logic "lazy" by only creating the inner tubes on the server side the first time the heli touches water. That is a good idea. If I do that, dynamic inner tubes would be better for server performance in many cases (though not all, as it depends on a few things).

    My advice is to keep them dynamic, purely for player experience, since people probably don't want to see inner tubes on their helis all the time, though I could be wrong about that.

    Posted · Edited by BlackLightning

    Setting them to dynamic actually requires that the plugin do some work to toggle them on and off when entering/leaving water.

    Here is a more detailed explanation of the performance consequences.

    When the decorative inner tubes are enabled, regardless of whether they are dynamic, they are always spawned and networked to clients. That means there's a greater networking cost when a heli is started or stopped since that is when helis enter/exit global broadcast mode. For example, if someone starts a heli engine across the map, if it was outside network distance, it gets networked to me at that time, requiring that the inner tubes also be networked (i.e., network packets are sent to my client for each inner tube entity). There is a small cost to networking entities to clients (on create, update, and destroy) but Rust normally sends an enormous quantity of network messages per second on populated servers, so I estimate the true impact of the inner tubes to be negligible.

    When then inner tubes are set to dynamic, even though they are still networked to clients, they are invisible because of a flag. When the plugin wants to show or hide the inner tubes, it simply sends a flag update to clients, which is a relatively small network message, much smaller than a full entity message. The plugin was designed this way in order to minimize the time spent hiding and showing the inner tubes.

    Overall, the decoration aspect of this plugin, or even the plugin as a whole isn't a performance bottleneck that I'm aware of. Do you have any data or anecdotes suggesting this plugin is causing significant performance loss?

    Posted · Edited by BlackLightning

    I don't recall if I've tested this, but it should be possible if the vending machine interface allows selling the large halloween loot bag. To my recollection, not all items are sellable, but most are. If the player wants to sell multiple bag variants, they'll need separate vending machines to get the skin to display correctly.

    Posted

    When you say you cannot put anything in them, do you mean that they have the checkered appearance? If so, that means wherever you placed them (in your inventory, in a container, etc.) has a limit of 0 for that bag category. Bag limits can be changed in the config. By default, players can place items in up to 3 bags in their inventory at once, but cannot place items inside bags that are inside of storage containers.

    Posted

    If you want bags to automatically appear in loot containers, you can enable it in the config. It's not enabled by default. The instructions are in the documentation. If you are using another loot plugin, you may need to enable the option that adds the bags with a delay.

    Posted · Edited by BlackLightning

    I tested but was unable to reproduce this issue. This issue was introduced last month with the water update but was subsequently fixed. Can you confirm you are using v1.2.3?

    According to the download history, you last downloaded this plugin on 4/29, so you cannot possibly be on v1.2.3. Simply update to v1.2.3 and the issue will be resolved.

    Posted

    The tool and cable configuration cost is the same for all players. What makes you think the tool or cable should be free? Did you configure it to cost 0? This is not to be confused with cable cost per meter, which is how much of the cable in your inventory is consumed when deploying a zipline.

    The Zipline Tool does not shoot any projectile, but a small impact effect is played where it hits to show you what was hit. Help messages are also printed in chat telling you what is happening and what to do next. The Zipline Cable is automatically consumed when you complete the zipline, so there is no need to tell the Tool to use the Cable, as it's automatic. Since you are using the Unrestricted profile, no Cable will be required and no Cable will be consumed.

Customers

Everything buyers need to manage purchases, support, and discover services.

Providers

Quick access to the tools creators use to manage files, support, and earnings.

Resources

Docs, support resources, and tools to help users and creators move faster.

About Us

Codefling is the largest marketplace for plugins, maps, tools, and more, making it easy for customers to discover new content and for creators to monetize their work.

Downloads
2.4m
Total downloads
Customers
10.8k
Customers served
Files Sold
155.4k
Marketplace sales
Payments
3.3m
Processed total
Customer Reviews 139 verified reviews 4.0
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.