-
Posts
178 -
Joined
-
Last visited
Content Type
Profiles
Downloads
Forums
Store
Support
DOWNLOADS EXTRA
Services
Everything posted by BlackLightning
-
I will look into this in a few hours.
-
- 36 comments
-
- 1
-
-
- #helicopter
- #minicopter
-
(and 7 more)
Tagged with:
-
- 36 comments
-
- #helicopter
- #minicopter
-
(and 7 more)
Tagged with:
-
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.
- 36 comments
-
- 1
-
-
- #helicopter
- #minicopter
-
(and 7 more)
Tagged with:
-
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.
-
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?
- 36 comments
-
- #helicopter
- #minicopter
-
(and 7 more)
Tagged with:
-
Changed Status from Pending to Closed
-
Ok, since you got it working, I'll go ahead and close this out. Feel free to reply here if you need further assistance or once you figure out which plugin is conflicting.
-
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.
-
- 36 comments
-
- #helicopter
- #minicopter
-
(and 7 more)
Tagged with:
-
Version 1.0.0
1,237 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- 11 comments
-
- 2
-
-
Changed Status from Pending to Closed Changed Fixed In to 1.5.0
-
I added the /zipline toggle command in the v1.5.0 update.
-
It could easily be changed to the "Use" or "Reload" keys. To do that, search the code file for FIRE_THIRD and replace with USE or RELOAD. The "Use" key is not ideal because it's used for things like mounting and picking up the zipline (not to mention many other interactions). The "Reload" key will cause the crossbow to load an arrow if you have one. While I can block the crossbow actually loading an arrow on the server side, I can't block the client-side animation from occurring if you have an arrow. I could make it use the "Light Toggle" or "Change Vehicle Seat" keys, but that will require adding a hook to detect when players run those commands. I could add a command to toggle it, such as "/zipline toggle".
-
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,
- 36 comments
-
- 1
-
-
- #helicopter
- #minicopter
-
(and 7 more)
Tagged with:
-
- 36 comments
-
- #helicopter
- #minicopter
-
(and 7 more)
Tagged with:
-
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.
- 36 comments
-
- #helicopter
- #minicopter
-
(and 7 more)
Tagged with:
-
- 36 comments
-
- #helicopter
- #minicopter
-
(and 7 more)
Tagged with:
-
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).
- 36 comments
-
- 1
-
-
- #helicopter
- #minicopter
-
(and 7 more)
Tagged with:
-
Version 1.3.3
739 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. Note: Helicopters do not have ownership in vanilla Rust. If you enable this option, you must install and configure another plugin which grants vehicle ownership. 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- 36 comments
- 3 reviews
-
- 3
-
-
-
- #helicopter
- #minicopter
-
(and 7 more)
Tagged with:
-
Possible conflict with SkillTree plugin.
BlackLightning replied to Hawkhill's Support Request in Support
I would just stick to something simple that the plugins can do today. One linear progression for player inventory bag limit: 1, 2, 3, 4, 5, 6 bags. Simple and easy to understand for players. You could expand on this, to only unlock being able to carry certain bags, such as the Generic bag or Bag of Holding bag, in later stages. One linear progression for player container bag limits: 1, 2, 3, 4, 5, 6 bags. Only if you want to allow players to store non-empty bags in storage containers. One progression for backpack size: 1, 2, 3, 4, 5, 6, 7, 8 rows. You could go further since Backpacks v3.9 now supports multiple pages. One node for Backpacks keep on death. One node for Backpacks gather mode, in v3.10 beta. One node for Backpacks retrieve mode, from Backpacks v3.10 beta. One linear progression for Backpacks bag limits: 1, 2, 3, 4, 5, 6 bags. By upgrading this, if the player has the keep on death node, this allows players to keep more bags on death, as long as they keep those bags in the backpack. The standalone Backpacks nodes could optionally be added to the other linear progressions, or could become a separate linear progression. -
Possible conflict with SkillTree plugin.
BlackLightning replied to Hawkhill's Support Request in Support
I don't think blocking opening is the way to go as it's too punishing if the bags already have content. I suppose upgrade permissions and bag kits are probably not the best things to use for player-resettable progression. If you stick to bag limits for progression, exploits will be mitigated when players die for instance, since they won't be able to pick back up the bags without emptying them. If their backpack has too many bags, excess should be ejected after some time. One technique you could explore would be to define new categories of bags that can be upgraded to, then create limits around those. For more details, see another recent support thread where I showed how to make a "VIP Bag of Holding" bag. Limits would probably start to get a bit messy though. -
Possible conflict with SkillTree plugin.
BlackLightning replied to Hawkhill's Support Request in Support
Ah, that is a problem I recently surmised could eventually happen. Loading the default config when the config syntax is invalid is standard behavior for many plugins, but in some cases it does not make sense, like for this plugin. When developing the plugin, I was mostly concerned about what happens if the plugin is temporarily unloaded, which is handled by persisting code in the game so that bags still have basic functionality like open and close. I will consider changing the behavior in an upcoming version, to make the plugin just do nothing when the config fails to load. That will allow the existing code from the previous load of the plugin to work somewhat until you resolve the config issue. When changing skins after you have existing bags, I recommend the commands because they will find and update the skins of all bags currently in the game world, though there are some limitations, like they can't find bags that are hidden away by other plugins such as kits, skill tree pouches, and backpacks of disconnected players. -
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?