NikkiLacrima
commented
1 month ago Confirmed that as long as the user stays in the rlvextension menu system they can force sit the wearer but ... wearer can stop this by opening the forcesit menu and hitting [BACK].
Since rlvextension have the buggy noninitalized g_iMenuStride it is be enough for the wearer to simply open and close any menu from rlvextension. This will invalidate the other users menu, forcing them to reopen and thus reauth the menu. This is because when g_iMenuStride is uninitialized, and therfore 0, closing any menu removes all from from the g_lMenuIDs so the return from the other users menuselection is dropped and menu is not resprung.
Seriously, its better to start getting the LSD framework set up, perhaps for only global_auth at first in 8.4. I dont think we have to rewrite all settings to LSD before implementing some of it.
UPDATE Another way is to handle it in oc_dialog in a manner similar to how changes to "auth_owner" is checked to invalidate menus for owners that are removed. So when "auth_public" is set to False or removed, all current dialogs are invalidated. This needs change in on place/script and handles all such situations.
Medea-Destiny
To reproduce: Have public access on someone's collar. Go to RLV>force sit, get list of objects wearer can be sat on Wearer switches off public access Select an item to sit them on. Sit will be successful, even though public access is now off. Wait for menu to reappear, and repeat ad nauseum.
The quick fix: change line 878 (OC 8.3) of oc_rlvextension to
llMessageLinked(LINK_THIS,0,"sit",(key)llList2String(to,1));-- this will re-auth the user before generating a new force sit menu, rather than using the "current" auth.The bigger issue: This is a by-product of remenuing using the auth value originally assigned. We have no way of indicating that auth has changed. Most of the time this isn't going to matter, but in remenuing within a script, we're generally just feeding the current auth back in to the system. The force sit menu is only one more obvious place where this is happening, but similar things are happening all over the place. This could have been addressed with an AUTH_STALE flag that would be sent on any change to auths, which would tell scripts to ignore any "saved" auth level (part of my proposal for OC4, but that's ancient history...) but this requires a lot of work throughout the collar.
Going forwards, we're going to use linkset Data for auth levels. This will allow every script to check the current auth without having to route back through linked messages, and will mean that the current auth level is always respected. While we might want to drop this fix in for force sit in the short term (8.4?), ultimately LSD will fix all these types of problems.