wearing an already-locked collar while wearing a locked collar gets VERY spammy

[eksynn]

What version of OpenCollar are you using? 8.2.3 (both)

What behavior did you expect? a small delay between the second collar starting and it trying to detach

What behavior did you see instead? i got spammed. it took a LOT of trying to get it unlocked JUST at the right microsecond by using the unlock command before it was able to get itself removed. i understand it's by design, but please un-desing this. it's stupid and spammy. if the collar fails to detach ONCE, STOP TRYING. let ME deal with my own attachments. additionally, or alternatively, if it MUST keep spamming me, maybe add a 5~10 second delay between the startup and the attempted detachment? (or you know, make it fail just once. that's preferable actually.)

What steps does someone need to take to reproduce the problem? attach an already-locked collar while wearing a locked collar beforehand

[eksynn]

and don't tell me to contact the creator (I was the creator for both), or to "not wear a second collar". that's not realistic. accidents happen. in this case, I didn't remember I even had the first collar on (which was a brain chip). i THOUGHT I had it removed before, but obviously I didn't.

[mistressohm]

Sounds as if the "Highlander" code ("There can be only one!") is attempting to force a detach, without asserting an "unlock" first. When the detach fails due to the collar being locked, it tries again... and again... and again... and gets stuck in a loop.

As you pointed out, having it fail once and then stay attached is preferable (even though you now have two collars which could possibly conflict). Another possible fix would be to simply not lock the collar during startup if a second collar is detected and the Highlander setting is active.

This IS a bit of an edge case, as most collars purchased are in an unlocked state, no owners, et cetera. But for anything that's given to a sub by a dom directly, there could be presets, so the assumption that "a new collar will not be locked" might not always be valid.

On Thu, Feb 23, 2023 at 8:49 AM Fuyu @.***> wrote:

and don't tell me to contact the creator (I was the creator for both), or to "not wear a second collar". that's not realistic. accidents happen. in this case, I didn't remember I even had the first collar on (which was a brain chip). i THOUGHT I had it removed before, but obviously I didn't.

— Reply to this email directly, view it on GitHub https://github.com/OpenCollarTeam/OpenCollar/issues/938#issuecomment-1441920475, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALSHY5APZ75FUNNTKK3XBDLWY52IDANCNFSM6AAAAAAVFXJJYY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[tayaphidoux]

might be able to solve this by storing an worn time and the collar with the lowest number gets kicked the cases of both collars being worn at the same time is low enough.

[tayaphidoux]

could even be date locked so which ever one was locked first, but that could overide a new collar with an older one.

[tayaphidoux]

however the imedate solution i am sure you have already done this is to turn off rlv and detach one of them.

[mistressohm]

So... here's a possible solution.

Change up the Highlander code so that on attach, IF another OC device is detected, the collar does three things, rather than the auto-detach that's currently implemented.

1) Assert an Unlock. Highlander will not allow the collar to lock when another OC device is present. 2) Turn RLV support OFF for itself. No restrictions will be imposed from a Highlander collar while another OC device is present. 3) Post a dialog that states the conflict, naming the other device, and giving the wearer and the registered owner (if any) the full sitrep on what's going on. They can detach the new device, or leave it attached, unlocked and with RLV off as a decorative collar.

At that point it's up to the wearer, and their owner, to figure out which OC device they wish to use.

On Mon, Mar 20, 2023 at 2:39 PM tayaphidoux @.***> wrote:

however the imedate solution i am sure you have already done this is to turn off rlv and detach one of them.

— Reply to this email directly, view it on GitHub https://github.com/OpenCollarTeam/OpenCollar/issues/938#issuecomment-1476828975, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALSHY5ALAZABJ3GPTMBP5BTW5CW6ZANCNFSM6AAAAAAVFXJJYY . You are receiving this because you commented.Message ID: @.***>

[Medea-Destiny]

To clarify the process, when a collar is attached it will chat "OpenCollar=Yes" on the interface channel. If a collar hears this message from another collar it replies "There can be only one!", and if a collar hears that message, it will attempt to detach. Thus: Collar 1 worn, chats "OpenCollar=Yes". Collar 2 worn, chats "OpenCollar=Yes" Collar 1 hears the above and chats "There can be only one!" Collar 2 attempts detach.

There's no need for keeping track of timings or anything, the second collar will be kicked off.

The process of detaching is to request attach permission, issue an "@detach=y" and then detach. This will cancel out the collar's lock, while not actually triggering the unlock process or switching off RLV (so it will still be locked and able to assert restrictions next time it's attached).

So why isn't the collar being detached? @eksynn More info needed. Is there some other restriction being applied here? A folder lock impacting the folder the collar is placed in, for example? We could have the script issue an "@clear" instead of the detach, but we can't do anything if a restriction is in place from another object. What spam is being sent? There shouldn't be any repetition going on; if the detach fails it should fail silently, there's no mechanism for trying again.

[eksynn]

To clarify the process, when a collar is attached it will chat "OpenCollar=Yes" on the interface channel. If a collar hears this message from another collar it replies "There can be only one!", and if a collar hears that message, it will attempt to detach. Thus: Collar 1 worn, chats "OpenCollar=Yes". Collar 2 worn, chats "OpenCollar=Yes" Collar 1 hears the above and chats "There can be only one!" Collar 2 attempts detach.

There's no need for keeping track of timings or anything, the second collar will be kicked off.

The process of detaching is to request attach permission, issue an "@detach=y" and then detach. This will cancel out the collar's lock, while not actually triggering the unlock process or switching off RLV (so it will still be locked and able to assert restrictions next time it's attached).

So why isn't the collar being detached? @eksynn More info needed. Is there some other restriction being applied here? A folder lock impacting the folder the collar is placed in, for example? We could have the script issue an "@clear" instead of the detach, but we can't do anything if a restriction is in place from another object. What spam is being sent? There shouldn't be any repetition going on; if the detach fails it should fail silently, there's no mechanism for trying again.

i apologise, i only just saw this - and i also just noticed you sent this last week lol i haven't tested it, but what steps should i do to test what you need to know? i don't think i had any other locks at the time edit: that is, except for the two already-locked collars

edit 2: to reiterate, the spamming happens if BOTH collars are locked. the first one is locked when the second, which was previously removed while locked, or locked without being born, is added while the first (already-locked) collar is already being born

[mistressohm]

Rez a new collar inworld. Set it to lock-on-attach (.settings would probably be easiest).

Wear an existing collar with Highlander turned on, and lock it.

Take the new collar into inventory, and Add it.

On Thu, Jul 27, 2023 at 1:44 PM Fuyu @.***> wrote:

To clarify the process, when a collar is attached it will chat "OpenCollar=Yes" on the interface channel. If a collar hears this message from another collar it replies "There can be only one!", and if a collar hears that message, it will attempt to detach. Thus: Collar 1 worn, chats "OpenCollar=Yes". Collar 2 worn, chats "OpenCollar=Yes" Collar 1 hears the above and chats "There can be only one!" Collar 2 attempts detach.

There's no need for keeping track of timings or anything, the second collar will be kicked off.

The process of detaching is to request attach permission, issue an @.***=y" and then detach. This will cancel out the collar's lock, while not actually triggering the unlock process or switching off RLV (so it will still be locked and able to assert restrictions next time it's attached).

So why isn't the collar being detached? @eksynn https://github.com/eksynn More info needed. Is there some other restriction being applied here? A folder lock impacting the folder the collar is placed in, for example? We could have the script issue an @.***" instead of the detach, but we can't do anything if a restriction is in place from another object. What spam is being sent? There shouldn't be any repetition going on; if the detach fails it should fail silently, there's no mechanism for trying again.

i apologise, i only just saw this - and i also just noticed you sent this last week lol i haven't tested it, but what steps should i do to test what you need to know? i don't think i had any other locks at the time

— Reply to this email directly, view it on GitHub https://github.com/OpenCollarTeam/OpenCollar/issues/938#issuecomment-1654229255, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALSHY5AHE3FUZEK4B3EGDKTXSKZIZANCNFSM6AAAAAAVFXJJYY . You are receiving this because you commented.Message ID: @.***>