Current Project: HUD7

Note ID# 1525:

User:	Lulu	Submitted:	24/11/2019
	Updated status to In Progress from New.

Note ID# 1528:

User:	Miriam Himanez	Submitted:	24/11/2019
	Something went wrong. After Dom triggering a random pose for the first time the HUD reacts as follows: Dom tries to stop the pose. ---> Sub receives the message: "You try but fail to overwrite your Owner's pose" Dom tries to change the pose. ---> Dom receives the message. Good thing is, if sub tries to stop or change, the HUD reacts, as it should. In summary a pose once triggered can't be stopped or changed by both. Doing a restart revokes the blockade. The pose is still active afterwards but can be stopped again.

Note ID# 1537:

User:	Lulu	Submitted:	29/11/2019
	Originally, the uHUD posing mechanism was just a simple one and not designed to allow the Owner to 'lock' the pose. However, since you raised #345, I thought it'd be a good idea to implement it. Now the problem is, this implementation is worse than the implementation in #344 – meaning it's more flimsy. As it is now it can't even surivive a restart. The reasons are structural, due to where different code sits in different scripts as a result of SL scripts' limitations. So if we were to simplify #344 by removing the 'lock' feature (i.e. sub can't force-sit or unsit), I'm in favour of simplifying #345 too. But I'm not sure how to. Any ideas?

Note ID# 1538:

User:	Miriam Himanez	Submitted:	29/11/2019
	Generally I view it like this: A sub forced into a pose by Dom using her uHUD gets overwhelmed by his authority within the current situation. In other words, it's just important as a short term-aspect to me. Anything more persistent could be done either by using chains (that are not uHUD-related) or furniture etc. sub might have been force-sat onto (Issue #344). For this reason I don't view the "weak implementation" of the uHUD posing feature as a matter at all. Currently sub is already disabled from using her uHUD as long as Dom is operating it. In the case of her working it when Dom decides to take control, he always has the possibility to hijack it's menu as well, which brings me to my idea: What about just disabling the "pose..."- and "stop pose"-buttons for sub as soon as Dom forced her into a random pose? They would stay inactive until he revoked it by "stop pose" again. (If "stop pose" would be moved into the pose-menu, just "pose..." itself needed to get blocked of course.) What about to even scratch a popup/chat-message in this case as well? I'm just imagining sub notices Dom has given up control of the menu. She might want to tease by changing the pose and pushes the button. Click!...Click?...click, click, click...and really nothing happens at all. To me this could feel a bit like as if I'd want to move but actually am just feeling way too weak to do anything as long as he bans me to the ground just by looking down on me...or something similar. When this state gets lost by relogging or restarting the uHUD, Dom just would need to renew the pose or choose another one, easily to be done within a short moment...as if he'd get distracted just for a second which would allow sub a short stir in between but nothing more.

Note ID# 1541:

User:	Lulu	Submitted:	29/11/2019
	So if I understand you correctly, you don't mind that after a restart or relog, sub is able to use the "pose..." menu again?

Note ID# 1542:

User:	Miriam Himanez	Submitted:	30/11/2019
	Yes that's correct, because Dom is able to hijack her control over the uHUD at any time again afterwards. I'd just like to see her being closed out from the ability to change/stop a pose as long as Dom has set one, even if he grants her access to the uHUD again by closing the menu himself. I'm repeating myself; to me this needn't survive a relog or an uHUD-restart. Possibly this solution could be a bit too soft for some tastes, which lets me spontanuously have another idea. I'd like to change and expand an old-feature request, I've posted in the past: Please let's do a short visit to Issue #236. I'm going to add Note #1543 to it.

Note ID# 1555:

User:	Lulu	Submitted:	14/12/2019
	Sent you beta.6 with this implementation as discussed/suggested: (1) if Dom (or self if self-owned) sets a pose on sub, when sub "stop pose" or try to change pose they will get a messag that they cannot overwrite Dom's pose. (2) Unfortunately with restart sub will reset everything. See whether that works for you?

Note ID# 1556:

User:	Miriam Himanez	Submitted:	15/12/2019
	Unfortunately preventing sub from changing/stopping a pose, Dom has set before, doesn't seem to work at all. Actually beta.6 exactly behaves like the previous version. (I did trials at two different places.) Maybe something has gone wrong within the update-process itself? Partially I disagree with point (1): I don't believe, that it would be a good idea to prevent a self-owned sub from changing/stopping a pose. Why should she get stuck in a pose she chose by herself?

Note ID# 1558:

User:	Anonymous	Submitted:	16/12/2019
	Dropped you beta.8 that should fix the previous issue. Sorry about that. Btw I've also restarted the sim. Also I think I explained it wrong. Self-owned sub will always be able to change or stop pose. -- Comment edited. 16/12/2019 06:17:16 PST

Note ID# 1559:

User:	Miriam Himanez	Submitted:	16/12/2019
	The sim-issue has gone and preventing sub from changing/stopping a pose, Dom has set before, is working now. Alas beta.8 still has the following problem: As soon as sub did the first trial to overwrite Dom's pose, it isn't able to differ between Dom's and sub's actions anymore. Since then Dom's attempts to change/stop a pose fail too and just trigger the message in sub's chat (as if they would be sub's attempts).

Note ID# 1560:

User:	Lulu	Submitted:	17/12/2019
	Strange, it passed my earlier tests, and now I'm trying it again and can't reproduce this. I've tried: 1. Dom puts sub in a pose. 2. Sub presses 'stop pose' and gets a override message. 3. Sub also presses another pose and gets an override message. 4. Dom opens menu and presses 'stop pose'. Pose stops immediately. Tried this 2x and works. Is there anything different you're doing?

Note ID# 1562:

User:	Miriam Himanez	Submitted:	17/12/2019
	Today I repeated all 4 steps exactly like you did. I did it 3 times altogether. The result was always the same: Step (4) brought up the chat-message for sub and Dom wasn't able to get her out of the pose. What about adding a logging-routine? I would repeat the tests then and give you the exact timestamps, so you could see what's happening inside my uHUD when I'm running the trials.

Note ID# 1563:

User:	Lulu	Submitted:	17/12/2019
	Hi Miriam, You can try beta.7 ... it's essentially the same as beta.8 but with some debug messages left on. Look out for "localOwnerCmdBit" value 1 or 0. If Dom started a pose, the value should be 1. When Dom stops it then it returns to 0. You should see the values at different times when you're pressing pose buttons, whether by sub or Dom, so you can tell whether at the time of pressing, the value is correct or wrong.

Note ID# 1565:

User:	Miriam Himanez	Submitted:	18/12/2019
	Hi Lulu, I did some other trials (using beta.7 and beta.8). It turned out, that it is a bit worse than I thought, it would be, two days ago. Actually the first pose, Dom chooses (no matter if sub tries to do something or not), blocks Dom and sub from changing/stopping a pose afterwards. "localOwnerCmdBit = 1" doesn't prevent just sub from using the feature; it prevents Dom from using it too. Only ways to get it back to "0" are restarting the uHUD or relogging.

Note ID# 1566:

User:	Lulu	Submitted:	19/12/2019
	Thank you for your last test, it really helped me find the perplexing reason why it worked for you and not for me. Fixed in beta.9 🙂

Note ID# 1567:

User:	Miriam Himanez	Submitted:	19/12/2019
	You're welcome. Confirmed. Everything works as it should now. 🙂

Note ID# 1568:

User:	Lulu	Submitted:	20/12/2019
	Fantastic, thanks for testing Miriam 🙂

Note ID# 1569:

User:	Lulu	Submitted:	20/12/2019
	Updated status to Completed from In Progress.