runaway problems

[NikkiLacrima]

What version of OpenCollar are you using? 8.2.3

What behavior did you expect? Runaway to be executed only when enabled and confirmed by wearer

What behavior did you see instead? Using chat "prefix runaway" any owner and/or wearer can unleash and clear the owners, trusted and blocked lists even when disabled and not confirmed by wearer.

The root cause of this is that the llMessageLinked(LINK_SET, CMD_OWNER, "runaway", g_kWearer) message is used both to try and intialize a runaway and then used, from oc_api, to signal that the runaway is enabled and confirmed by the wearer.
In oc_api the g_iRunawayMode variable is used to distinguish between these two cases, but that is not visible outside oc_api.

I propose that we use llMessageLinked(LINK_SET, CMD_OWNER, "runaway_confirmed", g_kWearer) for the latter case.
The changes for this should be quite minor. And also make the g_iRunawayMode handling unnecessary.

Consequently other scripts should listen not for “runaway” but for “runaway_confirmed”.

The uses of the "runaway" message seems to be in the following places (needs another careful checking of the codebase:

oc_core:220
Deletes the settings auth_owner, auth_trust and auth_block. This can be removed since its already done in oc_api, and it is a bug that allows any owner to effect auth_ removal without runaway enabled or confirmed

oc_spy: 232
Dead code that is never run due to the check that text commands start with “menu” or g_sSubMenu, so spy settings are never cleared on runaway (bug)

oc_relay : 139
Dead code that is never run due to the check that text commands start with “menu” or g_sSubMenu

oc_camera: 333

oc_themes, oc_anim, oc_relay, oc_titler
Boilerplate code that resets owner, trust and blocked lists, but these lists are never set or used so can be removed

oc_leash:491
This is an actual bug that releases the leash even if runaway is not confirmed

unwelder and unwelder hud
Simply returns

oc_OwnerOnlineCheck:84
Simply returns, this code lacks handling of owner removal, se #634

Edit: It looks like listening for runaway, except in oc_api, can be replaced by checking LM_SETTING for empty owner list. This will also take care of instances when the owner(s) has been removed in some other manner than runaway.

Edit 2:
oc_spy runaway issues fixed with PR #1004, checking for empty owner list instead of link message "runaway"

[Medea-Destiny]

Hey @NikkiLacrima, checking in on this... runaway_confirmed seems like a solid idea, are you working on this currently?

[NikkiLacrima]

Yes I am working on it and current plan is :

Move the all of actual runaway execution, that is the clearing of auth lists, down to the RunAwayMenu "Yes" handler where there already is code that sends runaway link messages. This makes the g_iRunawayMode superflous.

Rearrange the RunAway menu a bit to make permission handling for confirmation Yea/No and enable/disable clear.

Clean up what link messages are sent, at the moment the code generates CMD_RELAY_SAFEWORD three times making the rlv code sleep for 3x30 seconds and print lots of messages :
llMessageLinked(LINK_SET, CMD_OWNER, "clear", g_kWearer); can be removed since it generates a call to SafeWord() function in oc_rlvsys, but SafeWord() is already inwoked as a result of llMessageLinked(LINK_SET, CMD_SAFEWORD, "safeword", "");
There is also the mapping of CMD_SAFEWORD to CMD_RELAY_SAFEWORD in oc_relay that is also done in oc_rlvsys as a result of the call to SafeWord(),

Do some minor cleanup like removing the g_lMenuIDs list as is done on core by Yosty

[Medea-Destiny]

Sounds solid to me Nikki!

[NikkiLacrima]

I have files being tested in world before making a PR, can be distributed if ask me "Nikki Lacrima"

[Medea-Destiny]

@NikkiLacrima can you put those changed files up in a PR with the "do not merge yet" tag please?