Jump to content

BlackLightning

Creator
  • Posts

    218
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by BlackLightning

  1. 1. Not exactly. Players can carry as many empty bags as they want, but they can only place items in as many bags as you allow through the configuration. 2. Yes, following the instructions for "realistic backpacks" will achieve this.
  2. That is possible, but is out of scope for this plugin.
  3. Changed Status from Pending to Can't Reproduce
  4. 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.
  5. Have you made any progress troubleshooting this issue on your end?
  6. I just tested and did not find any issues with the attack helicopter. I had no other plugins loaded, only Buoyant Helicopters, then I spawned a new attack helicopter, I landed it on the water's surface, dismounted to allow the engine to shut off, mounted again, started the engine and flew away. Are you using any other plugins that affect the attack helicopter?
  7. I am currently away on holiday. I will be back tomorrow and can investigate then to see if I can reproduce the issue. It's possible that I overlooked this issue before (if it's a shortcoming with this plugin) because I may have been testing with another plugin installed at the time that covered up the issue such as Underwater Vehicles.
  8. Thanks for the report! I've released the v1.6.2 update to resolve this.
  9. 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).
  10. There must be something wrong on your side. I can't reproduce that problem.
  11. Changed Status from Pending to Closed
  12. Showing inner tubes only some of the time is currently better for client performance but worse for server performance, but only marginally worse because hiding and showing is fast. I should add a disclaimer that this is subject to change. I could make the logic "lazy" by only creating the inner tubes on the server side the first time the heli touches water. That is a good idea. If I do that, dynamic inner tubes would be better for server performance in many cases (though not all, as it depends on a few things). My advice is to keep them dynamic, purely for player experience, since people probably don't want to see inner tubes on their helis all the time, though I could be wrong about that.
  13. Setting them to dynamic actually requires that the plugin do some work to toggle them on and off when entering/leaving water. Here is a more detailed explanation of the performance consequences. When the decorative inner tubes are enabled, regardless of whether they are dynamic, they are always spawned and networked to clients. That means there's a greater networking cost when a heli is started or stopped since that is when helis enter/exit global broadcast mode. For example, if someone starts a heli engine across the map, if it was outside network distance, it gets networked to me at that time, requiring that the inner tubes also be networked (i.e., network packets are sent to my client for each inner tube entity). There is a small cost to networking entities to clients (on create, update, and destroy) but Rust normally sends an enormous quantity of network messages per second on populated servers, so I estimate the true impact of the inner tubes to be negligible. When then inner tubes are set to dynamic, even though they are still networked to clients, they are invisible because of a flag. When the plugin wants to show or hide the inner tubes, it simply sends a flag update to clients, which is a relatively small network message, much smaller than a full entity message. The plugin was designed this way in order to minimize the time spent hiding and showing the inner tubes. Overall, the decoration aspect of this plugin, or even the plugin as a whole isn't a performance bottleneck that I'm aware of. Do you have any data or anecdotes suggesting this plugin is causing significant performance loss?
  14. If you want to maximize perfomance, disable the floating tires by setting Enabled to false under the Decoration part of the config.
  15. Nobody has reported any problems.
  16. Changed Status from Pending to Closed
  17. While the player is viewing the vending machine in-person, the skin will be shown if the item is in stock, so players will just need to be careful about buying bags via drone marketplaces since the skin won't be shown in that UI.
  18. The small halloween loot bag is a different item. I will test later to see if this can be done. If it can't, I will look into the feasibility of using the small halloween loot bag for the plugin as an option.
  19. I don't recall if I've tested this, but it should be possible if the vending machine interface allows selling the large halloween loot bag. To my recollection, not all items are sellable, but most are. If the player wants to sell multiple bag variants, they'll need separate vending machines to get the skin to display correctly.
  20. That error was caused by the Rust update. The plugin was updated. Install the latest version.
  21. 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.
  22. I'm planning to add support for this in the next few days.
  23. Changed Status from Pending to Closed
  24. Ok, thanks for confirming.
  25. I couldn't reproduce this issue with only this plugin loaded. Are you sure this is caused by Buoyant Helicopters?

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.9m
Total downloads
Customers
11.9k
Customers served
Files Sold
168.8k
Total sales
Payments
3.7m
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.