Current Project: HUD7
Issue ID# 344 | Sub is able to undo "force sit" executed by Dom before. | |
Status: Completed | Version: 7.5.2 | Priority: 3 |
Assigned to: | Submitted by: Miriam Himanez | Attached file: Owner_only-Popup.png |
Type: Bug |
Submitted: 21/11/2019 21:18:45 PST |
Last Update: 10/12/2019 17:32:15 PST |
Description: 1. Open the menu of your sub's uHUD. 2. Go to "...rlv". 3. Push "force sit". 4. Proceed by force-sitting her onto a random suitable object in reach. 5. Now tell her to go to "...rlv" herself. 6. Let her push "unsit". What should happen: She should receive a message similar to the one she'd receive when trying to alter the settings of her RLV-relay, that you had set before. (Please view attached file.) What actually happens: She just stands up instead. |
Note ID# 1524:
User: | Lulu | Submitted: | 24/11/2019 | ||
Updated status to In Progress from New. |
Note ID# 1526:
User: | Lulu | Submitted: | 24/11/2019 | ||
I've sent 2.4-beta.2 your way for both this and #345. Let me know if it works for you 🙂 |
Note ID# 1527:
User: | Miriam Himanez | Submitted: | 24/11/2019 | ||
I did many trials and a few times in a row everything worked as it should. Unluckily the very most ones failed and despite my best effords I wasn't able to detect a scheme behind this that could tell me a reason how a few trials passed but all the other ones failed. |
Note ID# 1529:
User: | Lulu | Submitted: | 26/11/2019 | ||
I've fixed a few more things in 2.4-beta.3. See how that goes for this bug only? |
Note ID# 1530:
User: | Miriam Himanez | Submitted: | 26/11/2019 | ||
The first trial went well. Dom pinned sub down successfully. Sub's attempt to unsit failed and triggered the owner only-message. The second trial went as follows: Sub pinned herself down and Dom unsat her. When being made to stand up, the uHUD crashed: [17:15] LULU Utility HUD [2.4-beta.3]: LULU Utility HUD [2.4-beta.3] [script:LULU.HUD.utility.controller.1.lsl] Script run-time error [17:15] LULU Utility HUD [2.4-beta.3]: Stack-Heap Collision Afterwards the uHUD didn't react anymore until sub tped to another sim. Since then all following trials failed. (Sub was able to undo any force sit executed by Dom again.) Neither restarting the uHUD nor relogging was able to change that. |
Note ID# 1531:
User: | Anonymous | Submitted: | 27/11/2019 | ||
Thanks Miriam for the findings. I've optimized the code a bit more which should hopefully reduce the stack-heap collision. Sent 2.4-beta.4 your way. The script utility.controller.1.lsl is needed for everything to work correctly. The stack-heap collision means it was knocked out. It can actually be restarted again manually by you by right-clicking the uHUD and resetting all scripts. But that's not a very friendly solution so we'll see. -- Author changed. 27/11/2019 05:41:41 PST -- Comment edited. 27/11/2019 05:41:41 PST |
Note ID# 1532:
User: | Miriam Himanez | Submitted: | 27/11/2019 | ||
I did a dozen trials. Good news is, that there was no crash. The bad one, that still many of them failed. I'm going to list them below: 1.) Dom did force-sit but didn't receive the related chat-message. Sub did unsit. ---> Test failed 2.) Sub did force sit but didn't receive the related chat-message. Dom failed unsitting her. ---> Test failed 3.) Dom did force-sit and received the related chat-message. Sub failed to unsit and received the related popup. ---> Test passed 4.) Repeated 3 ---> Test passed 5.) Sub did force-sit and received the related chat-message. Sub did unsit. ---> Test passed 6.) Dom did force-sit, received no chat message, Dom did unsit. ---> Test passed (but message missing) 7.) Sub did force-sit and received the related chat-message. Dom did unsit. ---> Test passed 8.) Repeated 7 ---> Test passed 9.) Repeated 7 ---> Test passed 10.) Dom did force-sit but didn't receive the related chat-message. Sub did unsit. ---> Test failed 11.) Repeated 10 ---> Test failed *** uHUD restarted *** 12.) Repeated 10 ---> Test failed |
Note ID# 1533:
User: | Lulu | Submitted: | 28/11/2019 | ||
Good to hear the crash didn't happen. I'm quite puzzled why it fails intermittently. I'll need more time to investigate this as it's going to be hard. |
Note ID# 1534:
User: | Miriam Himanez | Submitted: | 28/11/2019 | ||
Yes of course. In this coherence I'd like to tell you about a general question and a thought, which have come to my mind, while playing around with the force-sit feature: Does it really make sense for sub to use it on herself? Practically I can't see any advantage against just sitting the normal way. No matter the way sub has sat down, she always could be unsat by Dom and herself at any time. In the face of this thought and the difficulties to fix the bug, I'm imagining a simple solution as alternative: What about making force-sit/unsit available for Dom exclusively? For sub the related buttons would be just blank, without any function and the script wouldn't need to find out who did force-sit and who did unsit anymore. |
Note ID# 1535:
User: | Lulu | Submitted: | 29/11/2019 | ||
Your idea is very good. Implementing it though produces a side-effect to #345 though. So I'll continue the discussion there and see what you think. |
Note ID# 1544:
User: | Lulu | Submitted: | 02/12/2019 | ||
Just one question though, what if sub is self-owned? |
Note ID# 1545:
User: | Miriam Himanez | Submitted: | 02/12/2019 | ||
A sub owned by Dom using force-sit on herself is able to unsit herself again. The same applies to a self-owned sub. So practically it doesn't make any difference for both of them, wether to use force-sit on themselves or just sitting the normal way. For this reason neither the self-owned one, nor the one owned by Dom needs to have access to force-sit/unsit. |
Note ID# 1546:
User: | Lulu | Submitted: | 04/12/2019 | ||
Hi Miriam, Just sent beta.5 your way. There's a slight change: The buttons are still there, but will only work if pressed by Owner, even if sub is self-owned. If not self-owned, sub will get a message that the button is for Owner-only. I did it this way because (1) it was easier to code (using existing code) and (2) this allows sub to debug by themselves if the button is not working correctly, since they can set self to be self-owned. Let me know what you think. |
Note ID# 1547:
User: | Lulu | Submitted: | 04/12/2019 | ||
Hi Miriam, Just sent beta.5 your way. There's a slight change: The buttons are still there, but will only work if pressed by Owner, even if sub is self-owned. If not self-owned, sub will get a message that the button is for Owner-only. I did it this way because (1) it was easier to code (using existing code) and (2) this allows sub to debug by themselves if the button is not working correctly, since they can set self to be self-owned. Let me know what you think. |
Note ID# 1548:
User: | Miriam Himanez | Submitted: | 04/12/2019 | ||
Hi Lulu, blocking sub from using force-sit/unsit worked well for me. The popup came up anytime when I tried. I like this solution. I wasn't able to check this from the perspective of a self-owned sub, because booting all Owners isn't an option for me. Unfortunately I noticed a strong tendency to malfunction, when using the feature as Dom. I'm listing the unwanted results below: 1.) Force-sit fails on all targets except the one chosen within the first trial. 2.) Unsit fails completely causing sub to get stuck onto the current target. 3.) Force-sit doesn't survive a relog. 4.) The related chat-message for Dom doesn't come up within the most trials. The possibility for malfunctions gets increased, if Dom plays foul of course. This would be: 1.) Force-sitting sub who's already sitting somewhere onto another target without unsitting her before. 2.) Trying to force-sit her onto an object that hasn't got space to sit on. 3.) Possibly playing around with unsit if sub isn't sitting currently. (I'm not sure in this case.) Restarting the uHUD can solve these problems but also might be the beginning of the next series of malfunctions in case of (2) of the first list because then Dom begins with (3) of the second list. (A restart doesn't unsit her, although the script might have forgotten, that she's still pinned down currently.) |
Note ID# 1549:
User: | Lulu | Submitted: | 08/12/2019 | ||
Hi Miriam, I've tested the force-sit and unsit about 8-10 times, and I can't reproduce some of the issues. 1) All force-sit and subsequent unsits work when the target is a suitable object. 2) All force-sits would quietly fail when target is not a suitable object. Because the RLV "force-sit" issues a "no-unsit" command, this also means that sub is unable to stand up if they subsequently sit down on anything. However to solve this involves a lot of code and is outside the scope of the uHUD. 3) After force-sitting the sub, Dom is unable to force-sit sub on another object. Probably because of the no unsit RLV vommand. 4) Sub relogging - I tried a 3 times, 2 times sub stayed on the object, one time it was lost. I suspect it's one of those sync things which can be quite complicated to diagnose and fix. If you feel this is important, maybe open another bug report and we'll see. 5) In all cases, sub is unable to either force-sit or unsit herself. It appears to me that the main issue of this bug has been fixed? That is, that sub is able to unsit herself after being force-sat? |
Note ID# 1551:
User: | Miriam Himanez | Submitted: | 09/12/2019 | ||
Hi Lulu, the main issue of this bug is definitely fixed, so point (5) is cleared. 🙂 I'd like to drop points (2) and (4) because they don't look important enough to me to justify massive efforts. If Dom does proper work (always unsitting before force sitting again), point (3) becomes irrelevant. Point (1) is about the functionality of the force sit/unsit-feature itself, so I'd like to focus on this one. Today I did trials on 3 different sims. One of them was CITY NOIR and all of them seemed to me without noticable lag. Unfortunately the results of my tests clearly differ from yours. Please view Issue #346. |
Note ID# 1552:
User: | Lulu | Submitted: | 10/12/2019 | ||
Ok thanks Miriam for the additional feedback. I’ll close this now and look at #346 separately. |
Note ID# 1553:
User: | Lulu | Submitted: | 10/12/2019 | ||
Updated status to Completed from In Progress. |