Currently synced custom paremeters consume either 1 or 8 bits out of the 128 bit total available for each avatar. If I store my selectors as Ints, I feel like I have enough ideas per avatar to easily exceed this limit.

But some selectors don't necessarily require 8 bits of storage. For example, if I have 8 facial expressions, I could encode that information in only 3 bits. That means my Int parameter is wasting 5 bits, which could easily contain another selector or maybe a bunch of toggles. If I have at least 2 low count selectors in my avatar, I can kind of do this by having a single "Command" or "Macro" Int parameter for the menu to set, where each position represents an unrelated command, then encode everything else using Bools and drive the Bools with parameter drivers. But that's an unnecessarily cumbersome method and also breaks my ability to use Toggle controls in the menu (or, in other words, to display state).

The easiest solution for this problem would be for the SDK to provide shorter integers as synced parameter types for storage. At least 2 and 4 bit integers, although due to the size of radial menus I feel like 3 bits would be extremely useful too. In the playable layers, all of these would be translated into regular "ints", but truncated if their value exceeds their capacity when being synced or stored.

The idea in https://feedback.vrchat.com/avatar-30/p/feedback-control-the-not-sync-parameters-from-expressions-menu also mitigates this problem (though it's worse), since it would allow local variables in the menus to display state and integrate features in a more human-friendly manner. It would still require encoding into Bool parameters to be performed with parameter drivers, though.

Another great way to solve insufficient storage woes would be to give VRC+ users the ability to store 256 bits per avatar (as the uploader). Seems like the sort of thing people would actually pay for.

I very much would like to see the option for an 4-bit non-signed Integer (Values 0-15) called a Short/ShortInt (or maybe a Nibble, but I think that's less intuitive) to save on memory space for use cases that don't need such a large range.

There are many reasons why someone would prefer to use an Int:

(Compared to an array of bools)

But for many common situations an 8-bit Int is way too overkill, taking up unnecessary space in the memory bandwidth.

For example it's very common for an Int to be used for exclusive toggles in the Menu (meaning toggles where only one option can be active at a time), but rarely do those toggles exceed the size of a submenu, meaning 8 options (9 if you're counting 0).

Another less frequent, but important, use case is the use as an Enum (An Integer encoding different States of a certain thing). And again there are many situations where, at least I personally, didn't need the full 256 range of an Int. A good example here is the GesturesLeft and GestureRight Ints, both of them being an Enum with 8 defined states. (I know that those two don't count to the memory limit, I use it as an example)

The only problem I would see with a ShortInt is how intuitive it is for a non-programming user. Currently there is a 1-to-1 correlation between the data types used in the Parameters Object and the data types used in the Animator. Now if there is a new option, like the short, in the Parameters Object, I could see that there would be some users confused on what that correlates with in the Animator. It obviously would be stated in the documentation that it's a type of Int, but I think that there should also be an additional Info-Box on the Parameters Object that pops-up once you select a ShortInt that says something like:

"A ShortInt is an Integer limited to the values of 0-15, therefore only taking up 4 Bits of memory. It is identical to a normal Int in every other way. A ShortInt has to be defined as an Int in the Animator"

128 bits is plenty but ints can be wasteful, and it's complicated to set up bitwise logic with bools.

A good compromise is letting us specify how many bits our integer parameters can use; 2 to 8 (perhaps longer?)

This would let toggles use a lower amount of bits and make it easier to squeeze more parameters into the 128 syched bits available.

It would be up to the user to make sure they stay within the range they specified.