Update oc_capture.lsl

[Pingout]

A revision to PR #969
This update has most of the features of 969 without the bugs, plus an important detail:

1. Owner can now end a Capture Issue Capture has a problem #903
2. Owner and Captor are both notified of successful Capture and End of Capture
3. BLOCKED individuals can not Capture Issue I can access my Capture menu while blocked #959
4. Wearer can end Capture when Risky is off
5. When Risky is active, the Captive's only escape is using Safeword
6. Fixes a bug in the timer when Captive relogs and Captor leaves the sim Issue Capture release timer #858

[NikkiLacrima]

This fixes the second issue discussed in #858, that capture is disabled during capture, before autorelease. The other changes in this commit makes impossible to disable capture in settings before it is released. So it shouldnt be an issue anymore.

The other issue in #858, that the autorelease timer doesnt restart after a relog is still not fixed, and with wearer blocked from capture settings in risky mode it wont be restarted by a call to Commit().

The fix here, tested but not only in my test code is to add in LM_SETTING_RESPONSE handler for "capture_status" a call to llSetTimerEvent(10) about line 450

                if(llList2String(lSettings,1) == "status"){
                    integer Flag = (integer)llList2String(lSettings,2);
                    if(Flag&1)g_iEnabled=TRUE;
                    if(Flag&2)g_iRisky=TRUE;
                    if(Flag&4)g_iCaptured=TRUE;
                    if(Flag&8)g_iAutoRelease=TRUE;
                    if(g_iCaptured && g_iAutoRelease) llSetTimerEvent(10);  // #858
                    g_iFlagAtLoad=Flag;

[SilkieSabra]

@NikkiLacrima it would be great if you know the code you want to see in a pr to go ahead and make the pr, this reduces the chance for error if the code gets copied and pasted into someone else's pr. And thanks for the great contribution! Another thing, the person who makes the pr cannot also review it so Ping will now have to find yet another person to review the code he pushed based on your input.

[NikkiLacrima]

I agre Silkie, but this was pushed as pr before I considered it ready to go. The code is ok, but barely tested and there is more work to do before making a final pr.

[Pingout]

It looks like everything has tested out 100% with the latest merge of #971
Testers please comment
Thank you NikkiLacrima, Trinkitz, and Omnia for the help

[SilkieSabra]

Drop me a line inworld if you can, @NikkiLacrima

[Pingout]

I agre Silkie, but this was pushed as pr before I considered it ready to go. The code is ok, but barely tested and there is more work to do before making a final pr.

So a question comes up about the timing of a PR, and when is the right time to start a Pull Request?
My first thought is that the testing team is unable to begin testing without the PR being started.
I think the timing of a PR falls on a timeline somewhere between initial attempt at fixing an issue, and a finished script ready to be merged. I think the PR can be a vehicle to collect comments - good and bad, and possible revisions as we work our way together to a finished script ready to be merged.

[Omnia2021]

After rigorous testing of multiple scenarios the app works as designed and nothing unexpected occurred.