-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
runaway problems #1001
Comments
Hey @NikkiLacrima, checking in on this... runaway_confirmed seems like a solid idea, are you working on this currently? |
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 : Do some minor cleanup like removing the g_lMenuIDs list as is done on core by Yosty |
Sounds solid to me Nikki! |
I have files being tested in world before making a PR, can be distributed if ask me "Nikki Lacrima" |
@NikkiLacrima can you put those changed files up in a PR with the "do not merge yet" tag please? |
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"
The text was updated successfully, but these errors were encountered: