Owner and .setting restrictions removed by rlv objects

[PonySorrowsong]

What version of OpenCollar are you using? 8.2.1

What behavior did you expect? I expected to have my owner restrictions restored when I used muffin milkers. But it imposed many of the same restrictions until the daily quota is made, then removes them. But since they were the same as my owner's restrictions, it removed his as well.

What behavior did you see instead? This is what the message is when Quota is achieved:

[04:48] MM - Milker Stall v.1.46 whispers: Quota Reached. Unlocking.... [04:48] PLM Open Collar 8.2.1: @unsit=y [04:48] PLM Open Collar 8.2.1: @clear=tplocal [04:48] PLM Open Collar 8.2.1: @clear=tplm [04:48] PLM Open Collar 8.2.1: @clear=tploc [04:48] PLM Open Collar 8.2.1: @clear=tplure_sec [04:48] PLM Open Collar 8.2.1: @clear=showworldmap [04:48] PLM Open Collar 8.2.1: @clear=showminimap

What steps does someone need to take to reproduce the problem? There are several solutions I can see. 1) Store a list of of who imposed a restriction. if the restriction was created by an owner or trusted person, then a scripted object not owned by an owner should not over-wright the owners permission or be able to remove it when the object removes it. there should be an orderings of restriction, where the owners or other persons restrictions would have a higher priority when a lower priority object exerts temporary restrictions that are removed. 2) if that is too complicated, put a single line in an oc script someplace that basically says, " if (un-sit | stand) Load owner commands stored in some list, or from the .settings notecard if they are active and unchanged by an owner who changed .settings using them menu.

[mistressohm]

Keep in mind that the collar is not what is setting the restrictions here. It is only reporting on what its relay is being told to do.

The MM Milking Stall is imposing all restrictions, if (!) the owner of that stall is trusted by the collar's relay. To complicate matters, if you wear the full version of the MuffinOS HUD, it has its own relay in it, pre-set to work ONLY with milking stalls.

Neither the stalls nor the HUD query for any exceptions stored on any collar, OC or otherwise. Since Muffin does not work with OC to keep things 'compatible' (and is not expected to), from an OC standpoint the only solution here is to not trust the landowner that put the stalls in place.

On Tue, Mar 15, 2022 at 6:00 PM PonySorrowsong @.***> wrote:

What version of OpenCollar are you using? 8.2.1

What behavior did you expect? I expected to have my owner restrictions restored when I used muffin milkers. But it imposed many of the same restrictions until the daily quota is made, then removes them. But since they were the same as my owner's restrictions, it removed his as well.

What behavior did you see instead? This is what the message is when Quota is achieved:

[04:48] MM - Milker Stall v.1.46 whispers: Quota Reached. Unlocking.... [04:48] PLM Open Collar 8.2.1: @UNSIT https://github.com/UNSIT=y [04:48] PLM Open Collar 8.2.1: @clear https://github.com/clear=tplocal [04:48] PLM Open Collar 8.2.1: @clear https://github.com/clear=tplm [04:48] PLM Open Collar 8.2.1: @clear https://github.com/clear=tploc [04:48] PLM Open Collar 8.2.1: @clear https://github.com/clear =tplure_sec [04:48] PLM Open Collar 8.2.1: @clear https://github.com/clear =showworldmap [04:48] PLM Open Collar 8.2.1: @clear https://github.com/clear =showminimap

What steps does someone need to take to reproduce the problem? There are several solutions I can see. 1) Store a list of of who imposed a restriction. if the restriction was created by an owner or trusted person, then a scripted object not owned by an owner should not over-wright the owners permission or be able to remove it when the object removes it. there should be an orderings of restriction, where the owners or other persons restrictions would have a higher priority when a lower priority object exerts temporary restrictions that are removed. 2) if that is too complicated, put a single line in an oc script someplace that basically says, " if (un-sit | stand) Load owner commands stored in some list, or from the .settings notecard if they are active and unchanged by an owner who changed .settings using them menu.

— Reply to this email directly, view it on GitHub https://github.com/OpenCollarTeam/OpenCollar/issues/753, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALSHY5GU4NAPTIADZ5O4VBTVAEJBVANCNFSM5Q2FK7FA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

[PonySorrowsong]

The 8.2.1 version has a built-in relay now. When I am on the MM milkers and check RLVa, it indicates the restrictions are coming from the collar, none say the milkers. So the milkers must be using the collar relay now. I do not have the MM OS Hud.

That means that the relay on the collar can be changed to fix this problem. I personally do not have the knowledge of how do do that. But it does not seem that difficult to me to strategically to insert some code someplace that would deal with all non-attached items that you sit on and get off of, something like this: A list is made for all active RLV commands and who sent each active command and the priority of each command, owners = 1, trusted =2, objects = 3. Listen for commands and identify any RLV commands being applied or removed. Find out if the same RLV is already active. If the RLV command is not active, then it can be added and removed by the object with no problem the same as is now done. If the RLV command is active, then the script will compare the originator of the new command with the originator of the old command with priority parameters such that: If new RLV command has priority 1, it will be applied, or removed, and the priority on the list changed to or kept at 1, if applied, and the whole line removed from the list if removed. If the new RLV command has priority greater than 1 (i.e. 2 or 3) and has = priority to the current command (2 or 3) it will not be applied or removed, so the command is just ignored. If the new RLV command has priority = 2 and priority number for the current Restriction = 3 then the new command is applied and and the priority on the table for that command changed from 3 to 2.

So would something like this be all that difficult to do?

[mistressohm]

Correct, your collar relay will report all restrictions.

The example above would work, but keep in mind that LSL does not allow writing to a notecard, and so all "state" tables or other lists of data have to be kept in memory, which could considerably increase script load. I propose a simpler method:

1) The collar imposes restrictions or exceptions based on owner settings, trusted persons settings, and wearer settings (if applicable).

2) The relay imposes restrictions based on external items/environment.

In the above case, restrictions from the relay should never supersede or contradict restrictions/exceptions from the collar. This is an argument against an integrated collar relay, because RLVa keeps track of what imposes each restriction. By combining/linking the two, RLVa can no longer distinguish which "component" set a restriction. If there's a method to determine which linked object in a linkset is responsible for a restriction, using that method might solve the problem. Otherwise, disabling the collar relay and wearing an external one may clear this up.

On Wed, Mar 16, 2022 at 10:36 AM PonySorrowsong @.***> wrote:

The 8.2.1 version has a built-in relay now. When I am on the MM milkers and check RLVa, it indicates the restrictions are coming from the collar, none say the milkers. So the milkers must be using the collar relay now. I do not have the MM OS Hud.

That means that the relay on the collar can be changed to fix this problem. I personally do not have the knowledge of how do do that. But it does not seem that difficult to me to strategically to insert some code someplace that would deal with all non-attached items that you sit on and get off of, something like this: A list is made for all active RLV commands and who sent each active command and the priority of each command, owners = 1, trusted =2, objects = 3. Listen for commands and identify any RLV commands being applied or removed. Find out if the same RLV is already active. If the RLV command is not active, then it can be added and removed by the object with no problem the same as is now done. If the RLV command is active, then the script will compare the originator of the new command with the originator of the old command with priority parameters such that: If new RLV command has priority 1, it will be applied, or removed, and the priority on the list changed to or kept at 1, if applied, and the whole line removed from the list if removed. If the new RLV command has priority greater than 1 (i.e. 2 or 3) and has = priority to the current command (2 or 3) it will not be applied or removed, so the command is just ignored. If the new RLV command has priority = 2 and priority number for the current Restriction = 3 then the new command is applied and and the priority on the table for that command changed from 3 to 2.

So would something like this be all that difficult to do?

— Reply to this email directly, view it on GitHub https://github.com/OpenCollarTeam/OpenCollar/issues/753#issuecomment-1069266180, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALSHY5FR4SDP2GHINGJ56JTVAH5YZANCNFSM5Q2FK7FA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[PonySorrowsong]

There would be very little added memory required. The required list is already being made in oc_relay. (2021-07-09 18:07:53 lsl2 script) on Line 22: list Restrictions;

Just 4 things need to be done: 1) Create an Integer at line 24: integer priority = 0; // 1 = owner, 2 = Trusted, 3 = objects or everyone. 2) At the listen beginning at Line 591, determine the source and assign the priority number. 3) In the Process script beginning at line 244, change line 274 from Restrictions += [behav]; to Restrictions += [behav] + [priority]; 4) At the Release script on Line 26 use LlList2ListStrided to find the priority and apply the comparisons I listed above.

To me, this does not look like it would be difficult for a skilled scripter or take up any new significant memory.

[PonySorrowsong]

Actually, as I think about it, some of the comparisons will need to be made in step 3 before the priority is added to the table. 3a) It will need to check if there is a priority already set and if the new priority is 1 or greater than the current priority, change the priority number to the new priority number, then do 3b) Restrictions += [behav] + [priority];

[mistressohm]

This is why I'm thinking it should be 'collar restrictions' which are inherent (and likely permanent), vs 'relay restrictions' which are external and by nature temporary.

You would only need two "source" values in a single binary flag in your table: 0 = relay, 1 = collar. At that point you can use boolean logic (OR, AND, NOT, etc) to determine if the restriction can be lifted (relay), or should remain in effect (collar).

On Thu, Mar 17, 2022 at 3:54 PM PonySorrowsong @.***> wrote:

Actually, as I think about it, some of the comparisons will need to be made in step 3 before the priority is added to the table. 3a) It will need to check if there is a priority already set and if the new priority is 1 or greater than the current priority, change the priority number to the new priority number, then do 3b) Restrictions += [behav] + [priority];

— Reply to this email directly, view it on GitHub https://github.com/OpenCollarTeam/OpenCollar/issues/753#issuecomment-1071458054, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALSHY5AKPIIOQY6F7YRLZ2LVAOLZJANCNFSM5Q2FK7FA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[PonySorrowsong]

Yes, that is simpler and I like it! Now, who can we get to impliment mistressohm's idea! :)

[KristenMynx]

There are several open issues created regarding clearing of exceptions and restrictions, in some cases under unknown circumstances. A change like this may go a long way to fixing those issues. I'll take on the scripting task here.

[KristenMynx]

After some research and testing I believe I have found the root of this problem.

oc_rlvsys is designed well and handles rlv restrictions from multiple sources (sources could be other scripts or addons using the RLV_CMD link messages where a source name is passed with the link message) It maintains the list via g_lRestrictions (restrictions by source) and g_lBaked (currently applied restrictions)

oc_relay is designed to directly send rlv commands to the viewer (llOwnerSay), as relayed from a RLV enabled device. When a device issues a !release, the restrictions are removed by directly as well. oc_relay attempts to tell other rlv scripts to refresh their restrictions via DO_RLV_REFRESH link message (oc_rlvsys turns around and does a RLV_REFRESH which actually is the instruction to scripts to do their restriction re-instatement.

One of the things oc_rlvsys does upon receiving a DO_RLV_REFRESH is to call for an LM_SETTING_REQUEST/ALL. This would have the side effect of reinstating all the settings including any rlv restrictions (LM_SETTING_REQUEST converts rlv settings to RLV_CMD messages)

One of the good things about oc_rlvsys, is that it optimizes rlv commands to the viewer by not keeping track of what it has currently set in the viewer, via g_lRestrictions and g_lBaked.

Since 1) oc_relay has not informed oc_rlvsys of the restrictions it has imposed nor cleared, and 2) nothing has cleared oc_rlvsys g_lRestrictions and g_lBaked, it means that oc_rlvsys won't reinstate the restrictions since it believes they are still in effect.

There are two paths to fixing this:

1) In oc_relay, remove all llOwnerSay("@..."), and replace them with MessageLinked(LINK_THIS,RLV_CMD.......) This will allow oc_rlvsys to be aware, and properly manage the viewer restriction state.

2) in oc_rlvsys, clear g_lRestrictions and g_lBaked, on a DO_RLV_REFRESH command, so the restrictions will be properly applied.

Either method may have 'breaking' side effects. 1) seems to me to the proper path.

[KristenMynx]

Further searching and review of the code base, I see no other use of DO_RLV_REFRESH. It only appears in oc_rlvsys and oc_relay It appears to me as if this link message was added specifically when oc_relay was coded.

I had coded a change following method 1 outlined in the prior comment. I was foiled by the code in oc_rlvsys when it responds to DO_RLV_REFRESH. I really don't think the function it performs is relevant when oc_relay uses RLV_CMD link messages instead of direct llOwnerSay.

Also, only 1 other script in the collar uses direct llOwnerSay(@...). It has to do with exceptions, and sometimes uses RLV_CMD and sometimes llOwnerSay, but seems to be coded appropriately depending on what it intends to do. With this in mind, I don't think may scripts should have a reason to use llOwnerSay(@..).

Does anyone have any information on the history of this?

[mistressohm]

Sorry to clarify, the stalls don't query for existing restrictions (or exceptions). So if there's a restriction put in place, that is the same as one already imposed, it will happily clear it.

This would also happen with any other RLV furniture/traps that impose restrictions. If, for example, someone enters my dungeon, which has an RLV 'restriction field' active, it will impose those restrictions when in range and lift them when the avatar leaves. It doesn't check to ensure that a restriction is already active and maintain it when the avatar leaves.

The idea of checking the .settings notecard is a good one, but keep in mind that loading .settings takes time. What this appears to be is a conflict between the collar itself, and the collar relay (which acts on external RLV commands rather than ones from something worn).

On Tue, Mar 15, 2022 at 6:15 PM Beatrice McAllister @.***> wrote:

Keep in mind that the collar is not what is setting the restrictions here. It is only reporting on what its relay is being told to do.

The MM Milking Stall is imposing all restrictions, if (!) the owner of that stall is trusted by the collar's relay. To complicate matters, if you wear the full version of the MuffinOS HUD, it has its own relay in it, pre-set to work ONLY with milking stalls.

Neither the stalls nor the HUD query for any exceptions stored on any collar, OC or otherwise. Since Muffin does not work with OC to keep things 'compatible' (and is not expected to), from an OC standpoint the only solution here is to not trust the landowner that put the stalls in place.

On Tue, Mar 15, 2022 at 6:00 PM PonySorrowsong @.***> wrote:

What version of OpenCollar are you using? 8.2.1

What behavior did you expect? I expected to have my owner restrictions restored when I used muffin milkers. But it imposed many of the same restrictions until the daily quota is made, then removes them. But since they were the same as my owner's restrictions, it removed his as well.

What behavior did you see instead? This is what the message is when Quota is achieved:

[04:48] MM - Milker Stall v.1.46 whispers: Quota Reached. Unlocking.... [04:48] PLM Open Collar 8.2.1: @UNSIT https://github.com/UNSIT=y [04:48] PLM Open Collar 8.2.1: @clear https://github.com/clear=tplocal [04:48] PLM Open Collar 8.2.1: @clear https://github.com/clear=tplm [04:48] PLM Open Collar 8.2.1: @clear https://github.com/clear=tploc [04:48] PLM Open Collar 8.2.1: @clear https://github.com/clear =tplure_sec [04:48] PLM Open Collar 8.2.1: @clear https://github.com/clear =showworldmap [04:48] PLM Open Collar 8.2.1: @clear https://github.com/clear =showminimap

What steps does someone need to take to reproduce the problem? There are several solutions I can see. 1) Store a list of of who imposed a restriction. if the restriction was created by an owner or trusted person, then a scripted object not owned by an owner should not over-wright the owners permission or be able to remove it when the object removes it. there should be an orderings of restriction, where the owners or other persons restrictions would have a higher priority when a lower priority object exerts temporary restrictions that are removed. 2) if that is too complicated, put a single line in an oc script someplace that basically says, " if (un-sit | stand) Load owner commands stored in some list, or from the .settings notecard if they are active and unchanged by an owner who changed .settings using them menu.

— Reply to this email directly, view it on GitHub https://github.com/OpenCollarTeam/OpenCollar/issues/753, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALSHY5GU4NAPTIADZ5O4VBTVAEJBVANCNFSM5Q2FK7FA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>