Error in oc_rlvsuit restriction numbering and macros

[NikkiLacrima]

Here comes another, code is wrong in two places and therefore it works.

Looking at a macro with restrictions numbered over 30 in g_RLVList, making the second integer in the macro nonzero, for instance: "Dress", 0, 30

The corresponding restrictions can be found from 30 = 16 + 8 + 4 + 2, that is bit position (numbered from 1) 2,3,4 and 5. Looking this up in g_RLVList gives us: "Rem Attach" "Add Cloth" "Rem Cloth" "Notecard" obviously not correct.

So what is the problem ? The bitmasks that stores restriction uses 31 bits and their function is seen in g_RLVList, and this list has stride 3. That means that the second bitmask uses entries that are 3x31 = 93 larger than the corresponding position in the first bitmask. But ApplyAll only adds 3x30 = 90 when moving from the first bitmask to the second. So we are one stride of 3 off. To compensate this the Macro values for the second bitmask has been doubled, corresponding to a bitshift of 1.

ListRestrictions also uses the incorrect value of 90 when moving from first to second bitmask.

This obviously should be fixed, but at the moment its not affecting the users. So I propose a patch as soon as 8.3 is out.

At the same time all restriction values shuld be converted to hexadecimal 0x format making it possible to iinterpret their values.

UPDATE
Making your own preset with camdistmax:0 will expose this bug and not work,
and the same error is in the calculation of iMenuIndex2 in ApplyCommand.

And in MenuCategory:
Flag2 = llRound(llPow(2, (i/3)-30));
should be
Flag2 = llRound(llPow(2, (i/3)-31));

UPDATE 2
The value in bitmask2 for "Stray" is wrong when using Restrictions ~Restore

[SilkieSabra]

Assume this was corrected in pr #1113, now merged in 8.3