BlackLightning
-
Posts
186 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Warranty Claims
Downloads
Forums
Store
Support
DOWNLOADS EXTRA
Services
Everything posted by BlackLightning
-
I could potentially implement it, but it adds some complexity because a backpack can change hands, so the rules for a given backpack need to change as the backpack moves around. It creates some nuanced situations for users, like if the backpack is on the ground and has a lot of bags in it, one player (with permission) can pick it up, but another player (without permission) cannot, and the plugin needs to explain to the user what the issue is. There's a similar problem with limiting bags inside of other bags (because the parent bag can change hands), which is why there aren't permissions for those limits. It is probably easier to address for backpacks as they can only hold items while equipped or on the ground, so I can look more into it if it's important to you. -
There is probably an issue with how you have configured it. First of all, ensure you are configuring the correct section. "Backpack bag limits" defines how many bags players can use inside of Backpacks (the container managed by the uMod plugin of the same name). That section doesn't determine how many bags can be used inside the player inventory. There is a separate section for that called "Player bag limits". If you do intend to set the limit for the Backpacks plugin integration, keep in mind that if the Backpack has multiple pages, bags on all of those pages count toward the limit, so the player may have forgotten about bags on other pages. Within a given permission profile, you can also configure bag limits by category, which may have a stricter limit for a specific type of bag. If so, the player may have reached the limit for a particular bag type. If you have multiple permission profiles defined for a given section of the config, ensure the player has permission to only one of those profiles, or re-order them for proper prioritization, as only one can apply to each player. For instance, a player can have a permission override for "Player bag limits" and a permission override for "Backpack bag limits", but if the player is granted 2 from "Player bag limits", the plugin has to choose which one should apply.
-
Most likely, you placed it in the wrong place, prabably in the content ruleset rather than the bag profile, as the reference option I mentioned will definitely be there (you will see it if you search for it). Try backing up your config and deleting it to regenerate a new one (ideally on your test server). Then you will see the correct place it needs to go, and you can then modify your original config accordingly. Ideally the plugin would automatically update your config file in order to avoid any confusion, but the current logic that determines whether the file needs to be updated has limitations so it did not detect this case.
-
This is supported by the latest version. Set "Enable food spoiling" to false in the bag profile configuration (must be set per bag profile). This option may not automatically appear in the config for existing plugin installations, but you can add it (next to where you see "Allow player item input").
-
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?
-
What issue are you experiencing? -
Support tickets do not get deleted. I don't even have the ability to delete them. There may have been a bug on the website, perhaps you typed up the ticket but did not submit it, or perhaps you submitted it on another file or as a general website support ticket. I can't investigate the issue without more information from you. I don't know what you mean when you say the bags turn into loot bags and I can't reproduce that issue. You may be experiencing a plugin conflict, which initially you will have to troubleshoot as your combination of plugins is unique to your server.
-
Under what circumstances are you seeing bags stack inside of each other? If you mean that you are dragging and dropping a bag onto another of the same type, you expect the bags to stack, but instead the bag goes inside the other, that can be helped by enabling stack improvements in the config. Additionally, make sure you don't have the destination bag currently open at the time, or else the moved bag will go inside anyway.
-
If you are experiencing an issue with the plugin, please use the support tab to create a support request. Please also provide as much information as possible so that I can understand the symptoms and try to reproduce the issue.
-
Upgrade requiring scrap instead of economics
BlackLightning replied to steampunkvalley's Support Request in Support
Changed Status from Pending to Fixed Changed Fixed In to 1.9.6 -
Upgrade requiring scrap instead of economics
BlackLightning replied to steampunkvalley's Support Request in Support
Ok, I see what happened. I just released the fix. Thanks for reporting the issue! -
Upgrade requiring scrap instead of economics
BlackLightning replied to steampunkvalley's Support Request in Support
The latest update shouldn't have affected this. The config looks correct. Can you confirm that the Economics plugin is loaded? If it's not loaded for any reason, the plugin will fall back to which ever item is in the config (in this case, Scrap). -
Changed Status from Pending to Fixed Changed Fixed In to 1.9.5
-
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.
-
I was able to place a bag in a stash without issue. Do you have any plugins that restrict which items can be placed inside stashes?
-
I just tested and it seems to still be compatible. I can view another player's inventory, then open a bag in their inventory, and even return to the player's inventory from the bag using the back button.
-
Changed Status from Pending to No Response
-
When dynamic is disabled, whether the decorative inner tube is displayed is determined by the Enabled property. Have you see that to false as well?
-
@sykosmurf Yes, that looks correct.
-
Technically all bags are "off" by default, meaning they won't appear anywhere on your server unless you explicitly make them available somehow such as via loot tables, shops, kits, etc. The only built-in way that bags can be made available to players is via the "Loot spawns" feature which is disabled by default. If you have enabled loot spawns, simply reduce the spawn chance of bags that you don't want to 0 under "Bag spawn chance percent by prefab".
-
Bags within Bag of Holding - random spillage/disappearing
BlackLightning replied to Somescrub's Support Request in Support
Changed Status from Pending to Closed -
Bags within Bag of Holding - random spillage/disappearing
BlackLightning replied to Somescrub's Support Request in Support
I'll go ahead and close this out since it seems like there isn't anything for Bag of Holding to do differently.
