Suggestions for GUI button and keep-on-wipeSolved

If it is possible to add different GUI pictures for different resolutions. For example, those who have a backpack with 24 cells, those players see a small backpack or with the inscription 24, who have a size.72 resolution with 72 cells, those players see another picture with a large backpack or the inscription 72. 
There is also a proposal to add permission to several "non-erasable" cells, items from which will not disappear after the wipe.

Regarding the suggestion to display multiple GUI images, would you want to resize the whole button, or just change the image? Reducing the button size could affect usability because it would become harder to click. If you only want to change the image, then the plugin could possibly expose a config option for alternate images according to capacity (or perhaps according to permission).

Regarding the suggestion to display the backpack capacity, do you mean to simply display the total capacity of the backpack? I'm not really seeing what value that adds, since the player can just open their backpack to see how large it is. The capacity shouldn't change very often, so constantly seeing the capacity doesn't seem useful. However, if it showed how many slots are in use or remaining, that might be more useful and has been suggested before in some forms such and displaying the current usage plus the total capacity like "15 / 48". This is already under consideration for v3.10.

Regarding the suggestion to allow only N slots to be persisted across wipes, I saw a similar post where somebody was trying to persist only two rows across wipes, but the way it was being done, where they would reduce capacity 2 days before wipe, allowed players to avoid opening their backpack during those 2 days in order to bring more rows to the next wipe. Given this is a recurring suggestion, I'll think about accommodating this for v3.10.

just displaying another picture. I myself will draw the numbers on the backpack or insert pictures of backpacks in different colors or completely different pictures.

I've implemented the feature to selectively persist items across wipes using permissions. You can download it for testing, as well as read the docs, on the edge branch of my fork. I will aim to release this in v3.10.

This allows configuring the max number of item slots to be kept, as well as restricting the types of items that can be kept. This functions very similar to the v3.9 system for restricting which items can go into backpacks. There is a default ruleset that applies to all players, as well as permission based rulesets so that select players can keep different types of items and different quantities of items.

The below example config would generate the following permissions.

  • backpacks.keeponwipe.all -- Keeps all items
  • backpacks.keeponwipe.1row -- Keeps the first 6 non-empty slots (not necessarily the first 1 row, as empty slots and restricted items will be skipped)
  • backpacks.keeponwipe.2rows -- Keeps the first 12 non-empty slots
  • backpacks.keeponwipe.onlywood -- Keeps all wood, with no limit
"Clear on wipe": {
  "Enabled": true,
  "Default ruleset": {
    "Max slots to keep": 0,
    "Allowed item categories": [],
    "Disallowed item categories": [],
    "Allowed item short names": [],
    "Disallowed item short names": [],
    "Allowed skin IDs": [],
    "Disallowed skin IDs": []
  },
  "Rulesets by permission": [
    {
      "Name": "all",
      "Max slots to keep": -1,
      "Allowed item categories": [
        "All"
      ],
      "Disallowed item categories": [],
      "Allowed item short names": [],
      "Disallowed item short names": [],
      "Allowed skin IDs": [],
      "Disallowed skin IDs": []
    },
    {
      "Name": "1row",
      "Max slots to keep": 6,
      "Allowed item categories": [
        "All"
      ],
      "Disallowed item categories": [],
      "Allowed item short names": [],
      "Disallowed item short names": [],
      "Allowed skin IDs": [],
      "Disallowed skin IDs": []
    },
    {
      "Name": "2rows",
      "Max slots to keep": 12,
      "Allowed item categories": [
        "All"
      ],
      "Disallowed item categories": [],
      "Allowed item short names": [],
      "Disallowed item short names": [],
      "Allowed skin IDs": [],
      "Disallowed skin IDs": []
    },
    {
      "Name": "onlywood",
      "Max slots to keep": -1,
      "Allowed item categories": [],
      "Disallowed item categories": [],
      "Allowed item short names": [
        "wood"
      ],
      "Disallowed item short names": [],
      "Allowed skin IDs": [],
      "Disallowed skin IDs": []
    }
  ]
},

In the future (v3.11+), we could potentially expand this functionality to allow limiting the total number of slots for specific items, or the total amount of specific items. For example, 5 slots of wood and 1 slot of stones, or 5000 wood and 1000 stones. Currently, you can only limit the total number of slots that are kept, not the number of slots of specific items, nor the total quantity of specific items.

When this ships, some people may request a similar feature set for when backpacks drop on death, which could possibly be added in v3.11+.

Merged post

The wipe configuration feature is now available in the v3.10 beta.

https://umod.org/community/backpacks/46426-backpacks-beta-3100

I haven't decided what to do about the alternate GUI icons. The are multipe feature requests surrounding it.

  • Show total/occupied slots
  • Show alternate images according to total/occupied slots
  • Show color overlay according to total/occupied slots
  • Change total/occupied slots text color according to total/occupied slots
  • Show gather/retrieve indicators
  • Allow players to set their button location preference, with alternate images based on the location
This is a great example of feature creep, all resulting from adding the GUI button in the first place. It's not feasible for me to constantly revisit this plugin to address such feature requests. My time is better spent elsewhere. In such cases, I don't want to relegate users to forking the plugin, since somebody has to update those forks every time the original plugin is updated, which is unnecessary maintenance work. Instead, I prefer to add extension points to allow addon plugins to be created to accommodate certain needs with unbound scope. Addon plugins wouldn't need to be updated when the core plugin is updated, allowing specific purpose and general purpose addons to be built one-and-done. At this point, I am probably going to go this route, but another developer will need to develop the addon plugin(s). If you have a specific developer in mind, send them my way and I will work closely with them to create the right extension points.
Locked automatically