Jump to content

BlackLightning

Creator
  • Posts

    207
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by BlackLightning

  1. That issue hasn't been reported yet, but now that you mention it, I think that could be an issue when you have configured the wearable bag limits separately (latest feature released hours ago) since it splits container supervisors which gather mode uses to know which containers to monitor. I'll take a look and figure out a solution in the next few days.
  2. Thanks for the report! I've released the v1.6.2 update to resolve this.
  3. Yes, those things are all possible with this plugin. Here's an example of the highlighted parts of the config that you would need to change. ... "Player bag limits": { "Default limits": { "Max total bags": 0, "Max bags by category name": {} } }, ... "Backpack bag limits": { "Default limits": { "Max total bags": 0, "Max bags by category name": {} } }, ... "Default container bag limits": { "Default limits": { "Max total bags": 3, "Max bags by category name": { "generic": 1, "armor_clothing": 1, "food_medical": 1, "items_construction": 1, "resources_components": 1, "weapons_tools": 1 } }, "Bag limits by permission": [ { "Permission suffix": "vip", "Max total bags": 6, "Max bags by category name": { "generic": 1, "armor_clothing": 1, "food_medical": 1, "items_construction": 1, "resources_components": 1, "weapons_tools": 1 } } ] }, This example will allow all storage containers to store up to 3 total bags, but at most one bag of each category (regardless of size). Containers placed by players with the bagofholding.limit.container.vip permission will be able to hold up to 6 bags, but still at most one of each category. Note there are currently some limitations which might be applicable to your use case. You cannot limit bags by bag type, only by bag category. For example, the Small Generic Bag and Medium Generic Bag are different bag types but in the same category called "generic", so if the "generic" bag limit is set to 1 in a given container, it can't store both those bags at once, even if the total bag limit for the container is higher. If you want a precise limit of 1 Small Generic Bag and 1 Medium Generic bag, there is no way to define that precise combination. I could potentially extend the plugin in the future to allow limiting specific bag types, if there is sufficient justification. Bag limits inside other bags is not subject to permission. You can control how many bags can be stored in a container, with different limits according to permission, but you cannot control what happens inside those bags according to permission (you can control it, but it's a global setting for that bag type).
  4. There must be something wrong on your side. I can't reproduce that problem.
  5. Nobody has reported any problems.
  6. That error was caused by the Rust update. The plugin was updated. Install the latest version.
  7. I'm not able to reproduce that issue. I just tested with the minicopter. Both the pilot permission and owner permissions worked as expected. Perhaps you are using the owner permission and the plugin you were using to grant ownership is having a problem.
  8. I'm planning to add support for this in the next few days.
  9. Not really. That feature was considered during initial development of this plugin, because the Backpacks plugin on uMod has a similar feature, but ultimately it was deemed too complex and not a good fit for this type of plugin. The biggest capability difference between this plugin and Backpacks is that players must "earn" the capacity by acquiring the bags. If a player loses their bags for any reason, not only are the contents of those bags lost, but the capacity is also lost. If you want to allow players to keep the bags and their contents on death, that would be in scope for the Restore Upon Death plugin to solve. At this time, that plugin doesn't discriminate about which items are retained, but it could be updated to allow the server owner to configure which types of items are kept vs lost, in order to keep Bag of Holding bags (and their contents) on death. Another way to achieve this would be to use the Backpacks plugin with keep-on-death enabled, and only allow backpacks to hold Bag of Holding bags. As a result, players could place Bag of Holding bags inside their Backpack to protect them (and their contents) from dropping on death. If you want to allow players to keep only the bags themselves on death (not the contents of the bags), there is no solution at this time. One reason we didn't try to solve that problem is that it's not clear where the bag contents would go. Depending on how many items were inside the bags, the player's corpse may not have sufficient inventory space to hold all the items. We considered the possibility of creating a "corpse" bag, which is basically read-only bag that would replace the original bag on the player corpse, allowing the player to retrieve the bag contents, but the player would not be permitted to move the corpse bag or add items to it to prevent abuse or bag duplication. We could possibly revisit that idea in the future.
  10. Yes, using this plugin to increase the transfer amount will result in fewer item moves which will put less strain on the server.
  11. Thanks for reporting this! Fixed in v1.2.3.
  12. Thank you for reporting that issue. Fixed in v1.2.1.
  13. Thanks for the feedback. I released v1.2.0 with pilot-based permissions. I chose not to pursue passenger-based permissions for now because it doesn't seem very straight forward for this plugin. Pilot-based permissions can result in the scenario you described, which unfortunately may be somewhat likely for minicopters given how easily I find myself mounting the wrong seat by accident. In the event that the wrong pilot does mount the heli and cause it to sink, the correct pilot would unfortunately have to dive down and mount the pilot seat briefly in order to trigger it to rise, which is a risky endeavor without the right equipment, partially defeating the purpose of this plugin. However, even if they drown in the process of recovering the heli, I think their corpse loot will float, so overall it's a minimal setback. For now, let's wait and see what feedback players provide.
  14. Do you have the Item Retriever plugin installed? It is a requirement to be able to pull ammo from bags. Without it, I'm aware of an issue where the game client will indicate to the player that they have the ammo, allowing the reload attempt to start, but the server doesn't know where to find the ammo so nothing happens. That isn't technically caused by the plugin, it's due to a mismatch between vanilla client and server side logic.
  15. One issue with this is that if the player dismounts the heli, the plugin has to remember who was last piloting it, in order to remain buoyant, in case the heli is above or in water when the player dismounts. Tracking that is relatively easy for the plugin to do in-memory, but I also have to account for plugin reloads and server reboots. I see two possibilities at the moment. 1. The plugin could use a data file to remember which helis are buoyant. Whenever a player mounts a heli, the buoyancy of the heli will be determined by that player's permission, and the plugin would remember that state until another player mounted it. 2. The plugin could automatically assign ownership to helis when a player mounts them. This approach will likely need more definition, though, because it could cause problems for other plugins if ownership changes, especially for vehicles spawned by other plugins. One way would be to auto claim only unowned vehicles (only assign ownership the first time a heli is mounted), but that would mean one player could mount a heli just once as a way to make it buoyant for another player, as a sort of gift or trade. Let me know if you have a preference or concerns about either experience. Another question would be, do you want to require that the pilot have the permission? What about passengers? Passengers are a bit different in behavior because let's say the pilot doesn't have permission, the passenger mounts and the heli becomes buoyant, then the passenger dismounts, and the heli becomes not buoyant because the remaining player (the pilot) doesn't have permission. Also regarding passenger permissions, would you want to count players in the back of the scrap heli, or just players sitting in chairs?
  16. You could try mentioning it in the server description, info panel, info/help commands, recurring chat announcements, etc.
  17. I have corrected the mistake in the documentation. Please try buoyanthelicopters.owner.minicopter. In the future, you can use a permissions manager plugin to discover all permissions registered by a plugin, in case the docs have a mistake.
  18. Version 1.0.0

    1,756 downloads

    Allows changing the max stack amount that industrial conveyors can transfer at once. How it works In vanilla Rust, let's say you have a stack of 500 scrap in a box. A connected industrial conveyor will transfer out at most 60 scrap from that stack at a time. This plugin allows you to change that 60 number to whatever you want, and allows you to set different numbers for different players using permissions. This plugin is especially useful for servers that have high loot content and high stack sizes. Note: Even when using this plugin, the transfer max stack amount cannot exceed the item's max stack size. For best results, adjust max stack sizes as well. Related ConVars If you are having issues with conveyor transfer speeds, consider changing the following ConVars as well. server.conveyormovefrequency -- How often industrial conveyors attempt to move items. Setting to 0 will disable all movement. Default: 5. server.maxitemstacksmovedpertickindustrial -- How many stacks a single conveyor can move in a single tick. Default: 12. As an alternative to this plugin, you can try simply increasing the server.conveyormovefrequency ConVar, but that may affect server performance, and will not help that much for servers with very high stack sizes. Another alternative is for players to simply spread out the items in the source container, since that will utilize the conveyor feature to move multiple stacks at once (which is a ConVar-controlled number), but that is more work for players. Permissions This plugin uses the permission system. To assign a permission, use oxide.grant <user or group> <name or steam id> <permission>. To remove a permission, use oxide.revoke <user or group> <name or steam id> <permission>. By default, the plugin provides the following permissions. Each one grants the corresponding max transfer amount to all industrial conveyors deployed by the player. conveyorstacks.amount.100 conveyorstacks.amount.1000 conveyorstacks.amount.10000 conveyorstacks.amount.100000 Notes These permissions are generated automatically when the plugin loads and reads the config. You can change these values and even add more by editing the config and reloading the plugin. If a player has multiple of these permissions assigned, the highest will apply. If you grant one of these permissions, then change that number in the config, the old permission will no longer exist, so you will have to grant permission again for the new value. For a seamless installation, make your intended config edits before granting any permissions to avoid any confusion. Configuration The settings and options can be configured in the ConveyorStacks file under the config directory. The use of an editor and validator is recommended to avoid formatting issues and syntax errors. Default transfer max stack amount (Default: 60) -- Determines the max stack amount that industrial conveyors can transfer at once. Can be overriden by granting permissions. This default value of 60 matches vanilla Rust as of this writing (March 2023). Transfer max stack amounts requiring permission -- Defines additional max stack amounts that will be used to generate permissions like conveyorstacks.amount.<amount>. Developer Hooks object OnConveyorMaxStackAmountChange(IndustrialConveyor conveyor) Return false to prevent the plugin from affecting the conveyor.
    Free
  19. It's stated in the documentation that vehicles do not implement ownership in vanilla Rust, so another plugin must be installed (and correctly configured) to assign ownership. If you are buying the minicopter from Airwolf vendor at Bandit camp, install the Vehicle Vendor Options plugin, assign the vehiclevendoroptions.ownership.minicopter permission, then purchase another minicopter. For vehicles spawned by Vehicle Airdrops, they will already have ownership if dropped by a player-thrown supply signal. Random vehicle airdrops will not have ownership. I'm talking about the plugin by Nikedemos, I don't know about the competitors. For other unowned vehicles (or as an alternative to Vehicle Vendor Options), set the following config options (especially the first option) in the Vehicle Deployed Locks config, then remove and redeploy the lock. "Auto claim unowned vehicles when deploying locks": true, "Auto replace vehicle ownership when deploying locks": true,
  20. The plugin already has a feature to require owner permission to make helis buoyant. You just need to enable it in the config, and grant the corresponding permission. It's all in the documentation. Are you asking for something else?
  21. Thank you for reporting this! This was a regression introduced in v1.1.1 due to logic which sets the helicopter to vanilla drag when the plugin adds buoyancy to it (when the heli spawns, or when the plugin loads), which was done as a retroactive mitigation for people who had helis that were permanently slow, which could happen in rare cases when reloading the plugin while helis were currently in water. At the time of that change, I did not anticipate that other plugins would alter heli drag. Edit: This has been fixed in v1.1.2 which uses a different design for ensuring that helis are reset to the correct drag when leaving water. I also fixed a compatibility issue where Vehicle AirDrop helis that land initially in water would be permanently slow after leaving the water.
  22. A dynamic inner tube feature has been added in v1.1.0. It will be enabled by default for new installations.
  23. When the inner tubes are enabled, they are always displayed. I'll think about making it dynamic so they only appear when you touch water. Plugins that spawn helis should be compatible. Furthermore, if you want to restrict buoyancy to permissions, then that should also work with vehicle spawners, as long as they assign vehicle ownership on spawn (they usually do).
  24. Version 1.3.5

    976 downloads

    Allows helicopters to float in water. Features Allows Minicopters, Scrap Transport Helicopters, and Attack Helicopters to float in water Optionally requires vehicle owner or pilot permission for vehicles to be buoyant Configurable number, position and rotation of optional decorative inner tubes Configurable number, position, size and force of buoyancy points Configurable underwater drag for when crashing through the water's surface API and hooks allow for more powerful integrations How it works By default, all Minicopters, Scrap Transport Helicopters, and Attack Helicopters will be buoyant, with decorative inner tubes. The inner tubes are indestructible and cannot be picked up. When flying at low to moderate velocity, you can simply land on water and dismount. When flying at high velocity, you may crash through the water's surface, causing the engine to shut off. The vehicle will then slowly rise to the water's surface. You may run out of oxygen if you choose to stay in the vehicle while waiting for it to surface. While piloting a helicopter on the water's surface, you cannot drive it like on ground, but you can turn it in place by holding the down key and pressing left or right. While the decorative inner tubes are configured to be dynamic, they will appear shortly after touching water, and they will disappear a few seconds after leaving water. Permissions This plugin uses the permission system. To assign a permission, use oxide.grant <user or group> <name or steam id> <permission>. To remove a permission, use oxide.revoke <user or group> <name or steam id> <permission>. Optionally, you may require that either the vehicle owner or most recent pilot have permission, in order for the vehicle to be buoyant. To do so, set "Require permission": true for the corresponding vehicle type in the configuration. buoyanthelicopters.owner.minicopter -- Minicopters will be buoyant if owned by a player with this permission. buoyanthelicopters.pilot.minicopter -- Minicopters will be buoyant if the current (or most recent pilot, if no current pilot) has this permission. buoyanthelicopters.owner.scraptransport -- Scrap Transport Helicopters will be buoyant if owned by a player with this permission. buoyanthelicopters.pilot.scraptransport -- Scrap Transport Helicopters will be buoyant if the current (or most recent pilot, if no current pilot) has this permission. buoyanthelicopters.owner.attackhelicopter -- Attack Helicopters will be buoyant if owned by a player with this permission. buoyanthelicopters.pilot.attackhelicopter -- Attack Helicopters will be buoyant if the current (or most recent pilot, if no current pilot) has this permission. Note: If you want to use ownership-based permission, you must be aware that helicopters do not have ownership in vanilla Rust, so for it to work, you must install a plugin which grants vehicle ownership. For example, Vehicle Vendor Options, Claim Vehicle, Vehicle Deployed Locks, Spawn Mini, and Vehicle License all have features which relate to vehicle ownership. If you don't want to deal with vehicle ownership, you can use the pilot-based permissions instead. Configuration The settings and options can be configured in the BuoyantHelicopters file under the config directory. The use of an editor and validator is recommended to avoid formatting issues and syntax errors. Admin debug (true or false) -- Determines whether debug info is shown to nearby admins when a helicopter becomes buoyant. This helps with configuring the buoyancy points. Default: false. The Minicopter, Scrap Transport Helicopter, and Attack Helicopter sections have the following options. Enabled (true or false) -- Determines whether the vehicle type supports buoyancy. Default: true. Require permission (true or false) -- Determines whether the vehicle type requires the vehicle owner or most recent pilot to have permission in order for the vehicle to be buoyant. Default: false. Underwater drag -- Determines how much drag buoyant vehicles have while underwater. Raising this will reduce the speed at which vehicles sink and rise. If you change this value, you will probably also need to adjust the force of each buoyancy point. Default: 2. Buoyancy points -- List of buoyancy points. Position -- Determines the position of the buoyancy point, relative to the vehicle origin. Size -- Determines the size of the buoyancy point. Default: 2. Force -- Determines how much force is applied at the buoyancy point. Decoration Enabled (true or false) -- Determines whether the buoyancy point has a decorative inner tube. Dynamic (true or false) -- Determines whether the decorative inner tube will be displayed only when touching water (and a short time after touching water). Position -- Determines the position of the decorative inner tube, relative to the vehicle origin. Prefab -- Determines the prefab of the decorative inner tube. Default: assets/prefabs/misc/summer_dlc/inner_tube/innertube.deployed.prefab. Rotation angles -- Determines the rotation of the decorative inner tube. Developer API API_IsBuoyant bool API_IsBuoyant(BaseEntity heli) Returns true if the helicopter is buoyant, else returns false. API_AddBuoyancy void API_AddBuoyancy(BaseEntity heli) Makes the helicopter buoyant if it's not already. API_RemoveBuoyancy void API_RemoveBuoyancy(BaseEntity heli) Makes the helicopter not buoyant. Developer Hooks OnVehicleBuoyancyAdd object OnVehicleBuoyancyAdd(BaseEntity heli) Called when buoyancy is about to be added to a helicopter. Return false to cancel. OnVehicleBuoyancyAdded void OnVehicleBuoyancyAdded(BaseEntity heli) Called after buoyancy has been added to a helicopter. OnVehicleBuoyancyRemoved void OnVehicleBuoyancyRemoved(BaseEntity heli) Called after buoyancy has been removed from a helicopter.
    $7.50
  25. I just tested with Kits v4.4.0 from uMod and didn't have any problems. I added 4 distinct category bags to my inventory, created a kit from them, dropped the bags, redeemed the kit, and opened the bags successfully. If the bags are functioning like halloween loot bags, that means Bag of Holding doesn't recognize them for some reason. For example, if the skins currently configured in the plugin do not match the skins of the bags. Is it possible that you changed the bag skin theme after creating the kit? That could certainly cause this. Similarly, if you are using the tactical or leather bags, then made a syntax error in the config, the plugin will load using the default config which corresponds to the fantasy skins, which could also cause this issue. Have you verified that the bags work when added to your inventory before creating the kit? If so, do the bags only function like halloween loot bags after redeeming the kit?

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.3m
Total downloads
Customers
10.7k
Customers served
Files Sold
154.8k
Marketplace sales
Payments
3.3m
Processed total
×
×
  • 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.