-
Posts
178 -
Joined
-
Last visited
Content Type
Profiles
Downloads
Forums
Store
Support
DOWNLOADS EXTRA
Services
Everything posted by BlackLightning
-
Possible conflict with SkillTree plugin.
BlackLightning replied to Hawkhill's Support Request in Support
Changed Status from Work in Progress to Closed -
Possible conflict with SkillTree plugin.
BlackLightning replied to Hawkhill's Support Request in Support
I'll be taking a look at gather mode soon to make several improvements. For example, don't gather anything while you are looting a bag, don't gather any item that is transferred between inventory containers (though can't really help the split-drag case at this time), and a "Gather: Existing" mode to only gather items that are already in the bag. -
Possible conflict with SkillTree plugin.
BlackLightning replied to Hawkhill's Support Request in Support
Thanks for the kind words. Once you've had some more time to work the plugin, please consider writing a review. Regarding the ability to upgrade bag limits independently for different bag categories, while I don't see a clear path forward at this time, you've definitely given me something to think about for future updates. Regarding your idea of placing bags inside the Skill Tree pouch (if I understood correctly), the pouch's implementation is pretty basic, especially compared to the Backpacks plugin, so you'll likely find some issues or limitations. For example, while Bag of Holding was being beta tested around 6 months ago, there was an issue where you could not open bags while they were inside the pouch, because as soon as you stopped looting the pouch itself, the Skill Tree plugin would save the pouch items and delete the pouch, therefore invalidating the bag item that you are attempting to open. That meant you could store bags inside the pouch, and even drop items onto the bags while in the pouch, but you could not open the bags without first removing them from the pouch. I don't know if that issue has been resolved, but there will definitely be other issues, though many of them may be minor or go unnoticed for a long time. I strongly suggest using the Backpacks plugin over the Skill Tree pouch for that use case because it is more sophisticated and has better compatibility with Bag of Holding. Furthermore, with the introduction of the permission perk feature, you should be able to provide an upgradable Backpack via the Skill Tree (as a replacement for the pouch). With Backpacks v3.10, you can even implement Gather and Retrieve mode as additional Skill Tree perks which I could definitely see players wanting to use. If you want to expand on using the pouch, another limitation is that there isn't a way to configure bag limits for the pouch specifically, like there is for Backpacks. I actually implemented a feature for that, but it's disabled at the moment because bags in the pouch were not fully functioning during the beta. You can in fact enable that feature by uncommenting the FEATURE_EXTRA_POCKETS_CONFIG compile time flag near the top of the plugin file. Upon enabling that feature, a section called "Extra Pockets bag limits" will be added to the config. Without that feature, bag limits inside the pouch will be determined according to "Container bag limits". If you do end up using that feature, please let me know so I can consider enabling it for all (if the issue where you can't open bags in the pouch is fixed, then I probably will enable that feature). -
Possible conflict with SkillTree plugin.
BlackLightning replied to Hawkhill's Support Request in Support
You can basically make bags require permission by setting bag limits. For example, set the player limits to 0 by default, then raise it for players with permission. This may not be as flexible as you want, though, because you cannot upgrade bag limits in separate linear paths like you can with upgrade permissions. When I was originally envisioning how Bag of Holding would be integrated with Skill Tree, I was only thinking of bag limits, particularly the total bag limit. For example, you could add a node that allows one bag, then upgrades to two, three, four, five, etc. You could have separate nodes for backpack limits and container limits since those are upgradeable independently. -
Possible conflict with SkillTree plugin.
BlackLightning replied to Hawkhill's Support Request in Support
The permissions are incorrect. Missing the bagofholding prefix. For example: "7": { "perms_list": { "bagofholding.upgrade.generic.xxsmall": "12 Slot Backpack", "bagofholding.upgrade.generic.xsmall": "18 Slot Backpack", "bagofholding.upgrade.generic.small": "24 Slot Backpack", "bagofholding.upgrade.generic.medium": "30 Slot Backpack", "bagofholding.upgrade.generic.large": "36 Slot Backpack", "bagofholding.upgrade.generic.xlarge": "42 Slot Backpack", "bagofholding.upgrade.generic.xxlarge": "48 Slot Backpack" } } There is also an issue in your "3" section where the small permission has an extra space before the end quote. I will suggest that Skill Tree be updated to trim such extra spaces automatically. -
Possible conflict with SkillTree plugin.
BlackLightning replied to Hawkhill's Support Request in Support
I don't know of any reason that they would conflict in this regard. The permissions in Bag of Holding are registered the same way as other plugins, and there is no logic in Bag of Holding which prevents granting specific permissions. Are you sure you have designated the correct permissions in the Skill Tree config? Can you attach your config? I also just purchased Skill Tree to see if I can recreate this issue. -
Possible conflict with SkillTree plugin.
BlackLightning replied to Hawkhill's Support Request in Support
Changed Status from Pending to Work in Progress -
Changed Status from Work in Progress to Closed
-
The container bag limits by permission feature has just been released in v1.1.0.
-
Looking at the example config, I don't think that's what I meant. If I understood correctly, you wanted for example, to allow non-VIPs to hold 6 bags inside their Bag of Holding, and to allow VIPs to hold 12 bags inside their Bag of Holding. The steps I described would create a new type of bag called VIP Bag of Holding with the following characteristics. Only VIPs can carry it It can hold 12 inner bags instead of 6 It can be created by upgrading the normal Bag of Holding #1: Create a new Content Ruleset In this example, the vipbagofholding Content Ruleset differs from the original bagofholding Content Ruleset only in the number of bags it can hold. This will later be assigned to the new VIP Bag of Holding Bag Profile to allow that type of bag to hold 12 bags instead of 6. "Bag content rulesets": [ { "Name": "bagofholding", "Allowed item categories": [ "All" ], "Disallowed item categories": [], "Allowed item short names": [], "Disallowed item short names": [], "Allowed skin IDs": [], "Disallowed skin IDs": [], "Bag limits": { "Max total bags": 6, "Max bags by category name": { "bagofholding": 0, "vipbagofholding": 0 } } }, { "Name": "vipbagofholding", "Allowed item categories": [ "All" ], "Disallowed item categories": [], "Allowed item short names": [], "Disallowed item short names": [], "Allowed skin IDs": [], "Disallowed skin IDs": [], "Bag limits": { "Max total bags": 12, "Max bags by category name": { "bagofholding": 0, "vipbagofholding": 0 } } }, ] #2: Create a new Bag Profile In this example, the vipbagofholding Bag Profile differs from the bagofholding Bag Profile in the following ways. Different name Different display name Different category name Different contents ruleset In addition, bagofholding is now upgradable to vipbagofholding. "Bag profiles": [ { "Name": "bagofholding", "Skin ID": 2824136143, "Capacity": 48, "Display name": "Bag of Holding", "Category name": "bagofholding", "Contents ruleset": "bagofholding", "Upgrade": { "To": "vipbagofholding", "Cost": { "Item short name": "scrap", "Item skin ID": 0, "Amount": 0, "Use Economics": false, "Use Server Rewards": false } }, "Recyclable": { "Enabled": false, "Ingredients": [ { "Item short name": "scrap", "Item skin ID": 0, "Amount": 1500, "Item display name": "" } ] } }, { "Name": "vipbagofholding", "Skin ID": 2824136143, "Capacity": 48, "Display name": "VIP Bag of Holding", "Category name": "vipbagofholding", "Contents ruleset": "vipbagofholding", "Recyclable": { "Enabled": false, "Ingredients": [ { "Item short name": "scrap", "Item skin ID": 0, "Amount": 1500, "Item display name": "" } ] } } ] #3: Create a new Bag Limit Permission In this example, default players will be able to hold 3 total bags in their inventory, 0 of which may be a vipbagofholding (this refers to the bag category, not the bag name). Players with the bagofholding.limit.player.vip permission may hold 3 total bags in their inventory, all of which may be a vipbagofholding. "Player bag limits": { "Default limits": { "Max total bags": 3, "Max bags by category name": { "vipbagofholding": 0 } }, "Bag limits by permission": [ { "Permission suffix": "vip", "Max total bags": 3, "Max bags by category name": {} }, { "Permission suffix": "unlimited", "Max total bags": -1, "Max bags by category name": {} } ] },
-
Changed Status from Pending to Work in Progress Changed Fixed In to Next Version
-
I'll describe how to implement the VIP bag approach. Create a new content ruleset. Just copy/paste the bagofholding ruleset, change its name to bagofholdingvip, and configure its bag limits how you want. Create a new bag profile. Just copy/paste the bagofholding profile, change its name to bagofholdingvip, change its content ruleset to bagofholdingvip (or whatever you named it in step 1), and change its display name to "VIP Bag of Holding" so players can tell the difference. You could also change the skin ID if you want to change its appearance. Create a new bag limit permission. Just copy/paste one of the other ones and configure its permission suffix and limits how you want. Make sure to configure this to allow at least 1 VIP Bag of Holding. Then grant that permission to your VIP group. Update the original Bag of Holding profile upgrade target to be the VIP Bag of Holding, with no cost. This will allow players to upgrade from the Bag of Holding to the VIP Bag of Holding if they have permission. Then grant the bagofholding.upgrade.bagofholding permission to your VIPs so they can upgrade from the normal Bag of Holding to the VIP Bag of Holding. You could technically grant this permission to normal players, but the plugin won't allow them to purchase the upgrade while the bag is in their inventory because it would cause them to go beyond their bag limit (limit of 0 VIP bags). If you want to create multiple tiers of VIP bags, you can simply repeat this process for each type of bag. You can also chain the upgrades: vip > elite > legend.
-
Thanks for clarifying. I'm hesitant to implement bag-in-bag limits by anything other than the direct parent bag, primarily because bags can be moved between players and containers, creating potential scenarios for abuse. For example, I could have my friend who is a VIP organize my bags and give them back to me in a state that I could not have possibly created by myself. There are multiple ways to mitigate such abuse, but each solution creates more problems that need to be identified and solved. For example, the plugin could prevent me from picking up a bag that has more inner bags than I am allowed, but then the plugin also needs to communicate to me precisely why it isn't allowed and how to resolve the issue. That may already be a bit of a problem today, but the problem increases as the number and complexity of pickup rejection reasons increases. Alternatively, the plugin could allow me to pick up the bag, but items could be automatically ejected from the bag in the process, but that isn't an ideal experience. Another alternative is to allow the bag to be picked up, and then partially disable bags over the limit, only allowing items to be removed but not added, but this could still be abused to some extent. Perhaps a time limit could be imposed where I am issued a warning that items will be ejected if I do not reconcile the limit within a period of time, which would allow me to help my VIP friend reorganize the loot in their base without disruption, though this would also have to be carefully done so the player cannot simply drop and pick up the bag again to reset the timer. It's also worth noting that there are already approximate solutions available. For example, you could let your players have Backpacks, then configure the Backpack bag limits according to permission. You could also create alternate bag profiles, such as VIP Bag of Holding, which only a VIP can hold, which has different limits defined.
-
I will look into adding this in the next feature update. I will have to think about how this will work with container-prefab specific limits, which is a hidden config option that I assume nobody is using (unless they looked at the code and found it). If I decide to keep that feature, or decide to add it back later if someone asks for it, l will probably implement support for permissions under each container prefab definition. For instance, priority would be Specific Container Permission > Specific Container Default > Generic Container Permission > Generic Container Default. As for your second suggestion, can you clarify? I didn't follow the wording.
-
Version 1.6.1
221 downloads
Features Allows players to deploy ziplines from a distance using a crossbow Allows bidirectional ziplines Allows adjusting zipline movement speed, optionally based on incline Optionally requires cable to deploy ziplines Extensive configuration options to restrict zipline deployment Integrates with Economics and Server Rewards to allow buying the Zipline Tool Integrates with No Escape to prevent deploying ziplines while Raid blocked or Combat blocked Integrates with Remover Tool to provide an alternate way to pick up ziplines How it works To deploy a zipline, a player must first obtain a Zipline Tool and some Zipline Cable. By default, the Zipline Tool is a crossbow with a custom skin, and Zipline Cable is rope with a custom skin. Once acquired, the player must shoot the crossbow where they want to start the zipline, then shoot again where they want to end the zipline (no arrows needed). Once the zipline has been deployed, players can ride it just like the vanilla ziplines, by looking up at the top of the start point and interacting with the "Use Zipline" prompt. Since both the Zipline Tool and Zipline Cable are items, there are many ways you can provide them to players, including via kits, vending machines, and loot tables. The plugin also allows players to purchase them directly with chat commands. 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>. Admin permissions deployablezipline.protect -- Allows the player to run the zipline protect command to toggle protection for any ziplines they deploy. Protected ziplines do not decay, and can only be picked up by players with this permission. Purchase permissions deployablezipline.buy.tool - Allows buying the Zipline Tool with the zipline buy command. deployablezipline.buy.cable - Allows buying Zipline Cable with the zipline buycable <amount> command. Tool usage permissions Depending on how you have configured the plugin, there will be additional permissions like deployablezipline.profile.<suffix>, one for each profile. The plugin comes with the following profiles by default. Note: Players must have permission to a profile in order to use the Zipline Tool. deployablezipline.profile.balanced 4 ziplines max 100m max zipline length 10 uses per Zipline Tool, but can be repaired Allows up to 45° decline and 15° incline Disallows monuments deployablezipline.profile.fun 6 ziplines max 200m max zipline length Unlimited uses per Zipline Tool Allows up to 45° decline and 45° incline Allows monuments deployablezipline.profile.unrestricted Unlimited ziplines 10000m max zipline length Unlimited uses per Zipline Tool No angle or location restrictions Speed permissions The speed that players move along a deployed zipline can be configured according to the permissions of the player riding the zipline (not the player who deployed it). Each speed profile will have a permission like deployablezipline.speed.<suffix>. You can make as many speed profiles as you want in the configuration. The plugin comes with the following speed profiles by default. deployablezipline.speed.slow 0.25x min uphill speed 0.5x max horizontal speed 0.75x max downhill speed deployablezipline.speed.balanced 0.5x min uphill speed 1x max horizontal speed 1.5x max downhill speed deployablezipline.speed.fast 0.75x min uphill speed 1.5x max horizontal speed 2.25x max downhill speed deployablezipline.speed.ridiculous 5x max speed deployablezipline.speed.ludicrous 10x max speed Commands This plugin provides both chat and console commands using the same syntax. When using a command in chat, prefix it with a forward slash: /. zipline buy -- Purchases a Zipline Tool. Requires the deployablezipline.buy.tool permission. By default, it costs 100 scrap. zipline buycable <amount> -- Purchases Zipline Cable. Requires the deployablezipline.buy.cable permission. By default, it costs 1 scrap. zipline toggle -- Enables or disables bidirectional mode for ziplines you deploy after running this command. Alternatively, you can press MMB (middle mouse button) while wielding a Zipline Tool. To use this command, you must have permission to a Zipline Tool profile that allows bidirectional ziplines. zipline protect -- Enables or disables protection of ziplines you deploy after running this command. Requires the deployablezipline.protect permission. A protected zipline does not decay, and can only be picked up by players who have the deployablezipline.protect permission. Configuration The settings and options can be configured in the DeployableZipline file under the config directory. The use of an editor and validator is recommended to avoid formatting issues and syntax errors. Zipline tool Zipline Tool -- Determines which item is considered the Zipline Tool. This item can also be used to pick up ziplines when Pickup restrictions > Require hammer or zipline tool to pick up zipline is set to true. Players may purchase this tool with the zipline buy command if they have the deployablezipline.buy.tool permission. Item short name -- The short name of the Zipline Tool item. Must be an equippable item. Default: "crossbow". Item skin ID -- The skin ID of the Zipline Tool item. Default: 2793006815. Purchase info Cost -- Determines the cost to purchase the Zipline Tool. Item short name -- The short name of the currency item. Default: "scrap". Item skin ID -- The skin ID of the currency item. Set to 0 to require an unskinned currency item. Default: 0. Amount -- The amount of currency required to purchase the Zipline Tool. Default: 100. Use Economics (true or false) -- Set to true to require Economics currency instead of item currency. Default: false. Use Server Rewards (true or false) -- Set to true to require Server Rewards currency instead of item currency. Default: false. Attachment item short names -- Determines which attachments will be added to the Zipline Tool when purchased. Only applies to weapons that can have attachments. Default: ["weapon.mod.holosight", "weapon.mod.lasersight"]. Zipline cable Zipline Cable -- Determines which item is considered Zipline Cable. Note: You can independently configure the condition loss of the Zipline Tool if you want to consume the tool itself. Item short name -- The short name of the item. Default: "rope". Item skin ID -- The skin ID of the cable item. Default: 2793158547. Cost -- Determines the cost to purchase Zipline Cable. Item short name -- The short name of the currency item. Default: "scrap". Item skin ID -- The skin ID of the currency item. Set to 0 to require an unskinned currency item. Default: 0. Amount -- The amount of currency required to purchase Zipline Cable. Default: 1. Use Economics (true or false) -- Set to true to require Economics currency instead of item currency. Default: false. Use Server Rewards (true or false) -- Set to true to require Server Rewards currency instead of item currency. Default: false. Pickup restrictions Pickup restrictions -- Determines under which circumstances players may pick up ziplines. Require hammer or zipline tool to pick up zipline (true or false) -- Set to true to require the player to be holding a hammer or the Zipline Tool to pick up a zipline. This only applies to ends of the zipline that use the spear item, since the Tesla Coil end already requires a hammer to pick up. Default: true. Allow pickup while building blocked at other end (true or false) -- Set to true to allow players to pick up a zipline from one end, while they are building blocked at the other end of the zipline. Default: true. Note: Regardless of this option, players may not pick up a zipline from an end where they are building blocked. Effects Effects -- Determines the effects that are played when using the Zipline Tool, or when trying to pick up a zipline. Tool impact (player only) -- Plays when the player hits a surface with the Zipline Tool. Only the Zipline Tool wielder will witness the effect. This provides feedback to the player so they can see where they hit. Tool failed (player only) -- Plays when the player tries to use the Zipline Tool but experiences an error. Only the Zipline Tool wielder will witness the effect. The wielder may experience an error for many reasons, such as being Building Blocked, or due to having insufficient Zipline Cable. Tool used -- Plays when the player successfully places either end of zipline using the Zipline Tool. Other players will witness the effect. Deploy succeeded -- Plays when the player successfully deploys a zipline using the Zipline Tool. Plays on both ends of the zipline. Other players will witness the effect. Pickup failed (player only) -- Plays when the player fails to pick up a zipline due to being Building Blocked. Only the Zipline Tool wielder will witness the effect. Zipline Tool permission profiles Zipline Tool permission profiles - Zipline Tool profiles allow you to define complex rulesets depending on a user's Oxide permissions. You may define unlimited profiles, but at most one will be assigned to each player. Profiles toward the end of the list have highest priority. Permission suffix -- Determines the permission that you must grant to assign the profile to a player or group. For example, set this to "fun" to produce the permission deployablezipline.profile.fun. Allow tool while building blocked (true or false) -- Determines whether the player may use the Zipline Tool while they are standing in a location where they are Building Blocked. Allow bidirectional ziplines (true or false) -- Determines whether the player is allowed to place bidirectional ziplines. A bidirectional zipline can be mounted from either end. The player can press MMB (Mouse3) to enable/disable bidirectional mode. Zipline min length -- Determines the minimum zipline length that the player can deploy. Zipline max length -- Determines the maximum zipline length that the player can deploy. Zipline max decline angle -- Determines the maximum downward angle of ziplines that the player can deploy. Set to 90.0 to allow the player to deploy ziplines that go straight downward. Set to 0 to only allow ziplines to go across or upward. Zipline max incline angle -- Determines the maximum upward angle of ziplines that the player can deploy. Set to 90.0 to allow the player to deploy ziplines that go straight upward. Set to 0 to only allow ziplines to go across or downward. Zipline max elevation increase -- Determines the maximum delta between the zipline start position and end position. Set to 0 to only allow ziplines to go across or downward. Tool condition loss percent per zipline deployed -- Determines how much condition the Zipline Tool will lose when the player deploys a zipline. Set to 0 to allow unlimited uses. Set to 100 to allow only one use per Zipline Tool. The Zipline Tool will be destroyed when reaching 0 condition. Tool cooldown seconds -- Determines how long the player must wait after deploying a zipline with the Zipline Tool before they can deploy another one. Max ziplines at once -- Determines the maximum number of ziplines that the player may have in the map at once. Cable cost -- Determines how much Zipline Cable will be consumed when deploying a zipline. Cost per meter -- Determines how much Zipline Cable is required per meter. Set to 0 to not require any Zipline Cable. Set to a fraction such as 0.5 to allow each unit of Cable to cover multiple meters. Refund amount per meter on pickup -- Determines how much Zipline Cable is refunded when the player's ziplines are picked up. Set this to the same value as Cost per meter to allow players to recover all their Zipline Cable when picking up a zipline. Set to less than Cost per meter to effectively impose a penalty by refunding less than what was spent. Start point ruleset -- Determines the locations at which the player can place a zipline start point. Allow while building blocked (true or false) -- Determines whether the player can remotely place this end of the zipline at a location where they are Building Blocked, regardless of whether they are standing in a Building Blocked location. Min height above terrain -- Determines how close to terrain the player can deploy this end of the zipline. Set to 0 to allow placing a zipline at terrain level. Max deploy distance -- Determines the maximum distance away from the player that they can place this end of the zipline. Allowed layers -- (Advanced) Determines the Rust object layers to which the player can attach this end of the zipline. The player will not be able to attach a zipline to objects on other layers. Allowed values: Default, TransparentFX, Ignore_Raycast, Reserved1, Water, UI, Reserved2, Reserved3, Deployed, Ragdoll, Invisible, AI, Player_Movement, Vehicle_Detailed, Game_Trace, Vehicle_World, World, Player_Server, Trigger, Player_Model_Rendering, Physics_Projectile, Construction, Construction_Socket, Terrain, Transparent, Clutter, Debris, Vehicle_Large, Prevent_Movement, Prevent_Building, Tree, Unused2. Disallowed topology -- (Advanced) Determines the types of Terrain Topology to which the player cannot attach this end of the zipline. Set to [] to allow all types of Terrain Topology. Allowed values: Field, Cliff, Summit, Beachside, Beach, Forest, Forestside, Ocean, Oceanside, Decor, Monument, Road, Roadside, Swamp, River, Riverside, Lake, Lakeside, Offshore, Rail, Railside, Building, Cliffside, Mountain, Clutter, Alt, Tier0, Tier1, Tier2, Mainland, Hilltop. End point ruleset -- Determines the locations at which the player can place the zipline end point. Same options as Start point ruleset. Zipline decay settings -- Determines how quickly deployed ziplines decay while outside of Tool Cupboard range. Note: Only one end of the zipline must be within Tool Cupboard range to protect it from decay. Also, instead of taking damage, the zipline will simply disappear when the decay time has elapsed. Enabled (true or false) -- Determines whether decay is enabled. Default: true. Decay minutes -- Determines how long a zipline is protected from decay after being deployed, or after nearby Tool Cupboards are removed. Default: 60. No Escape integration -- Determines whether the player can use the Zipline Tool while Raid Blocked or Combat Blocked, as determined by the No Escape plugin. Allow tool while raid blocked (true or false) -- Set to false to prevent the player from using the Zipline Tool while they are Raid Blocked. Allow tool while combat blocked (true or false) -- Set to false to prevent the player from using the Zipline Tool while they are Combat Blocked. Speed permission profiles Speed permission profiles -- Speed profiles allow you to configure how quickly players move along ziplines, depending on the Oxide permissions of the player riding it. You may define unlimited speed profiles, but at most one will be assigned to each player. Speed profiles toward the end of the list have highest priority. Permission suffix -- Determines the permission that you must grant to assign the speed profile to a player or group. For example, set this to "balanced" to produce the permission deployablezipline.speed.balanced. Move speed -- Determines the max speed that applies when the player is not holding the forward key. Bonus move speed -- Determines the additional max speed that applies when the player is holding the forward key. This value is added on top of Move speed to determine the total max speed. Acceleration time (seconds) -- Determines how many seconds it will take the player to reach max speed after mounting the zipline. Downhill speed bonus -- Determines how much to increase speed while going downhill. Percent increase per angle degree -- Example: While this is set to 1.0, going downhill at a 45° angle will increase max speed to 145%. Max speed percent -- Example: while Percent increase per angle degree is set to 1.0, and while this is set to 130.0, going downhill at a 45° angle would increase speed to only 130% instead of to 145%. Uphill speed penalty -- Determines how much to decrease speed while going uphill. Percent decrease per angle degree -- Example: While this is set to 1.0, going uphill at a 45° angle will decrease max speed to 55%. Min speed percent -- Example: While Percent decrease per angle degree is set to 1.0, and while this is set to 70.0, going uphill at a 45° angle would decrease speed to only 70% instead of 55%. Localization The default messages are in the DeployableZipline file under the lang/en directory. To add support for another language, create a new language folder (e.g. de for German) if not already created, copy the default language file to the new folder and then customize the messages.$9.99 -
Gather Mode turns off after short amount of time
BlackLightning replied to The Large Car Trucker's Support Request in Support
Changed Status from Pending to Not a Bug -
Gather Mode turns off after short amount of time
BlackLightning replied to The Large Car Trucker's Support Request in Support
Are you using the Backpacks config option "Only Save Backpacks on Server-Save (true/false)": true? If so, try setting that to false. When that config option is true, it causes Backpacks to basically unload each player's backpack from memory every time the server saves. After a Backpack has been unloaded from memory, when the backpack is opened, the plugin has to recreate the container and items. That affects gather mode because Backpacks doesn't currently remember item flags (which gather mode uses), so it recreates the bags with gather mode disabled. An upcoming update to Backpacks will resolve this compatibility issue. -
Gather Mode turns off after short amount of time
BlackLightning replied to The Large Car Trucker's Support Request in Support
Hi, sorry for the delay. For some reason I did not receive any notifications when this support ticket was created. When gather mode shuts off: Does the UI button still indicate that gather mode is on? (Gather: On) Does anything happen before gather mode turns off? For example, does it turn off only after you die? If you are using the Restore Upon Death plugin, there is a known issue where that plugin will recreate the bag with gather mode disabled when you respawn. A patch has been submitted to that plugin to fix that issue, but its maintainer has been unresponsive. -
That's the first I've heard of bags unexpectedly changing category. I'm not aware of any reason that could happen. My guess is that another plugin caused it somehow. If that issue repeats, I can take a look at your config and plugin list to see if I have any ideas. When multiple bags are in gather mode, the priority order is the same as the bag order itself. This allows players full control of the priority by simply rearranging the bags. I could make the plugin designate a different order, but given that the bags are so configurable, as the developer I can't easily decide for you which bags should take priority over others (I can only provide a default order according to the default configuration), so if that were implemented, the order would have to be made configurable by the server owner. I caution against this because using an explicit priority order at the server level would mean individual players no longer have the ability to determine the priority order by rearranging the bags.
-
That appears to happen because Bank is attempting to add items to the bag's inventory, before the bag's inventory has been created. If Bank is updated to create the bag with its skin, rather than set the skin after creating the bag item, this issue will probably resolve. There are bound to be other issues with Bank. I suggest using Backpacks instead, since it has both keep-on-death and keep-on-wipe functionality that should be more than sufficient for whatever use case for which you are using Bank.
-
Lightning Icon since Oct 6th Game Update
BlackLightning replied to Zoreeno's Support Request in Support
Changed Status from Pending to Not a Bug -
Lightning Icon since Oct 6th Game Update
BlackLightning replied to Zoreeno's Support Request in Support
Unfortunately, this is not fixable. The way this used to work is that setting the Cooking flag on an item would display the lightning bolt, and setting the OnFire flag on an item would display fire icon. As of the recent furnace changes, both flags now display the same icon, meaning there is no longer a way to influence the game to draw the lightning bolt on an item. The bag selector UI is still able to draw the lightning bolt because it's a custom UI so it can instruct the client to display arbitrary assets (the cooking icon asset is still in the game). I spent a lot of time experimenting with various item/container flags to see if the client could be influenced to draw other item indicators, but it seems the only possible options now are the locked indicator and the burning indicator, both of which the plugin already uses. The only workaround I can think of would be to allow multiple skins. One skin to represent an empty bag, and another to represent a non-empty bag. I suppose we could also allow a skin to represent gather mode. The plugin internals would need to be redesigned a significant amount to accommodate this feature, but we could do it. Designing and creating all the icons would also be a significant amount of work for our team since we have hundreds of icons, but if I remember correctly, you created your own icon set, so it is probably more feasible for you to update your icon set. If you are open to creating alternate bag icons for your server to represent non-empty bags, I can plan to implement the logic probably by end of this month. -
Ah, I misunderstood what was happening. It was the act of clicking the open button (using the OnItemAction hook) that was triggering the reward, not the act of technically opening/looting the bag container. Thanks @Zoreeno for helping out. If @Steenamaroo wants to provide better out-of-the-box compatibility in the Rust Rewards plugin, my suggestion is to ignore the loot bag item if it has a skin. This approach will also work for several other plugins that use skinned halloween loot bags and presents for special purposes (such as to run arbitrary commands when opened).
-
Bag of Holding has many API methods and hooks, but the documentation I originally wrote for them becomes stripped of all formatting when I try to paste it into this website's editor, and I haven't had the time to manually reformat it all (it's a lot). Steenamaroo has my permission to download the plugin from this website to browse the API/hooks in code, as well as my permission to test the integration on a test server. There are multiple ways to identify whether a player is looting a bag. The best way depends on the context and which information is available to the other plugin. I'm guessing the issue is happening in the OnEntityLootEnd hook which I see in the Rust Rewards code, but I'm surprised this is an issue in the first place. I imagine that plugins which rewards players for looting should only do so for containers which are clearly loot containers (as identified by the LootContainer class or by prefab). Bag of Holding does not use loot containers, so I'm not sure why this would be an issue in the first place, unless you are also seeing this issue for player deployed containers. I wonder if the Rust Rewards plugin has been incorrectly configured on your server, or if there is a broader issue with that plugin which has gone unreported. Rather than making other plugins specifically detect bags from this plugin, I suggest they instead detect when the player is looting an item (a container that resides inside an item). This approach can be done only while the player's loot container list (basePlayer.inventory.loot.containers) is populated (i.e., one frame after OnLootEntity is called, and before the player stops looting). If that container list has only one container, and that container has a parentItem, then that means the player is looting an item's container. This approach allows other plugins to be sufficiently generic so as to not rely on specific plugin APIs. Any time plugins can rely on generic approaches rather than plugin APIs, it generally increases compatibility and allows plugins to be swapped out (e.g., you could replace Bag of Holding with another plugin that works similar, or install multiple plugins that work like Bag of Holding).