Current Project: HUD7

Leaderboard

Report Issue List Issues

Issue ID# 218	Let Owner-commands override restrictions set by objects.
Status: New	Version: 7.2.12	Priority: 3
Assigned to:	Submitted by: Miriam Himanez	Attached file:
Type: Feature Request	Submitted: 29/06/2016 21:03:34 PDT	Last Update:
Description: 1. Make sure sub's RLV-relay is switched to auto. 2. a) Let her enter a cell/cage/RLV-zone having at least the tp-restrictions active. b) Let her sit on an RLV-furniture having at least a no unsit-restriction active. 3. a) Leave the place and try to summon her by the leashring. b) Try to unsit her by the HUD. What should happen: It would be great, if Dom had the power to free sub this ways, so to say by just snipping with fingers. What actually happens: Both attempts fail, because of the restrictions set by the trap. If Dom hasn't got access to it's menu, there either would be left the possibility to switch off the RLV-relay by Dom (who couldn't do this if not present. Some mazes deny entry for people not wearing an active RLV-relay for example.) or safewording by sub. What about adding a routine able to detect RLV-restrictions set by external devices conflicting with an Owner-command? So if a command is chosen and the routine detects a conflict, it automatically switches off the RLV-relay temporarily (just long enough to clear all restrictions set by the external device). The command gets executed successfully and the relay switches on again - finished. It's just theory of course. I've got no clue, if it's possible to realize. If not, I have a "light version" of my idea too: An additional "emergency-summon"-button in the leashring-menu. If chosen, RLV is switched off for a moment and sub teleported/yanked to Dom, restrictions get cleared, RLV switched on again...so Dom just needs to take out the leashring to save sub out of any hopeless situation. 🙂

Note ID# 948:

User:	Miriam Himanez	Submitted:	29/06/2016
	I have the urgent need to add, that I want all aspects of this feature to be available to Owners explicitely and NOT! to self-owned subs.

Note ID# 1042:

User:	Idris Georgia	Submitted:	27/09/2016
	If a sit is set by an object, only that object can unsit the subject. Similar to using the sit in a collar to put them on something and trying to use the unsit in the arm menus (I know not Lulu but just an example). TP block may or may not be overrideable, depending in part on whether the cage is using strict or permissive rules. If strict rules apply, only those ids registered as an exception with the cage will be able to override a TP block. If the cage is permissive, any exception from any source can override. Hope this helps.

Note ID# 1043:

User:	Idris Georgia	Submitted:	27/09/2016
	Sorry, my sit explanation is a bit wonky. If a subject is sat on or by an object and unsit blocked by that object then only that object can unsit the subject later. Anything else that tries to unsit the subject will fail due the the block. There is one set of exceptions to that. Some items have a [Stop] anumation button, which removes the sit target, this will mean the subject gets released when that button is pressed. However, if the sit lock was applied by a restraint the subject is wearing they are still under that lock, so will be unable to stand if they sit on anything else. Similarly, some devices run a specific process and end. When they end, the eject the sitter. Regardless of how they were sat or locked, they will be standing in that instance. Hope this helps more.

Note ID# 1048:

User:	Miriam Himanez	Submitted:	28/09/2016
	Of course you're right. Simplified one could formulate a basic rule in handling RLV: "Better not try to undo something, you've set inside one device, by an action using another device." For this reason I suggested a temporarily switch-off of the RLV-relay itself (similar as if sub would have used "Safeword"). I'm reposting my core statement: "...if a command is chosen and the routine detects a conflict, it automatically switches off the RLV-relay temporarily (just long enough to clear all restrictions set by the external device). The command gets executed successfully and the relay switches on again..."

Note ID# 1050:

User:	Idris Georgia	Submitted:	29/09/2016
	Switching off the relay could have unintended consequences. If the sub is under more than one device control as in a zone of control, or perhaps a remote control, you disrupt those as well. I'm not saying don't do it, but consider all the ramifications.

Note ID# 1053:

User:	Miriam Himanez	Submitted:	29/09/2016
	Yes, naturally this feature shouldn't be used lighthearted and I can imagine, that it might not be possible to clear the restrictions set by one specific object and keep the ones set by other devices anyhow, which brings me to the "light version" of my idea, I mentioned at the end of this feature request: "...An additional "emergency-summon"-button in the leashring-menu. If chosen, RLV is switched off for a moment and sub teleported/yanked to Dom, restrictions get cleared, RLV switched on again...so Dom just needs to take out the leashring to save sub out of any hopeless situation." Technically it would be the same thing than safewording, followed by a teleport to Dom and and an automatic switch-back to the previous state of the RLV-relay (without any restrictions of external devices left of course) as soon as possible. The advancement would be the fact, that Dom wouldn't need to be present at the same place than sub to free her out of trouble. (A maze forbidding entry for people not wearing an active RLV-relay could be a place where Dom can't reach her directly, for example.) Surely Dom should be warned before actually be able to perform this action, similar to the warning coming up before safewording. Handled in a responsible way, this feature could be a possibility to intensify the experience of Dom's power for both, I believe.

log in