Jump to content

Norton Burns

Resident
 View Profile  See their activity

  • Posts

    79

  • Joined

  • Last visited

 Content Type 

Posts posted by Norton Burns

    Deploys for the week of 2013-06-17 (Updated @ 2013-06-18 16:18PDT)

    in Second Life Server

    Posted

    Whther the prems are strictly 'released' or not was not really the issue I'm debating - I'm aware of SVC-1006 though I have been using this method since long before that was ever posted, probably since 07.

    Everybody seems to call this a hack, but if you replace the last line with llOwnerSay("perms=" + (string)llGetPermissions()); you still get the same result, alternating between 20 & 0, unless you're on an RC sim, when you get no response for 0, as it doesn't go through runtime.

    Changing the script to

    integer switch;

    default {

        touch_start(integer total_number) {

            if (switch = !switch) {

                llRequestPermissions(llGetOwner(),20);

                llOwnerSay("aquire perms=" + (string)llGetPermissions());

            }

            else {

                llRequestPermissions(llGetOwner(),0); 

                llOwnerSay("drop perms=" + (string)llGetPermissions());

            }

        }

        run_time_permissions(integer perm){

            llOwnerSay("perms=" + (string)llGetPermissions());

        }

    }

     

    actually reveals more - that the perms themselves are not dropped at all on RC

    perms should alternate between aquire=20 & drop=0, whether or not runtime is called. On RC, that does not happen, the result is always 20.

    PS - I just realised Maestro's test script in SVC-1006 relies on runtime to report the results ;-)

    Deploys for the week of 2013-06-17 (Updated @ 2013-06-18 16:18PDT)

    in Second Life Server

    Posted

    Simple test script for this - drop it into an attachment, doesn't work on the ground.
    Click it on/off, perms integer is reported in chat. Should alternate between 20 (animation perms) & 0 (none)

    integer switch;

    default {
        touch_start(integer total_number) {
            if (switch = !switch) llRequestPermissions(llGetOwner(),20);
            else llRequestPermissions(llGetOwner(),0); }
        run_time_permissions(integer perm){
            llOwnerSay("perms=" + (string)perm);
        }
    }

    Deploys for the week of 2013-06-17 (Updated @ 2013-06-18 16:18PDT)

    in Second Life Server

    Posted

    Filed as https://jira.secondlife.com/browse/BUG-2931

    Transcript below, for those who can't see BUGs

    I've marked this as showstopper, because for me this is a disaster… I have thousands of users, dozens of 3rd party makers using my scripts, who would all have to update their entire product lines to workaround this…

    llRequestPermissions(ownerID,non-zero-integer);
    calls run_time_permissions

    llRequestPermissions(ownerID,0);
    has stopped calling run_time_permissions

    I was always taught never to guess, rely on runtime to know when perms are ready or not - so I use perms drop to trigger actions as well as perms acquire.

    roughly …
    run_time_permissions(integer permission) {
    if (permission & various masks) {do appropriate setup, depending on mask;}
    else if (!permission) {shut things down tidily;}
    }

    On all 3 RC servers this week, runtime is no longer called by llRequestPermissions(ownerID,0);

    Deploys for the week of 2013-06-17 (Updated @ 2013-06-18 16:18PDT)

    in Second Life Server

    Posted

    my apologies, it's late Friday night & I don't have time to properly investigate, but I'm seeing major issues with my weapons scripting system in RCs, both sandboxes & 'user' regions. The only thing I can possibly imagine is it could be the perms changes, but I'm guessing. The 'broad' version is if I go to RC, the weapons will draw, once, then won't sheath, subsequent attempts fail, alphas don't change, but some draw/sheath anims [hard to tell quite which] do appear to trigger - but swapping between weapons, the HUD sends messages, the weapons don't repond correctly. The HUD itself appears to behave, sending messages, but the weapons no longer respond. [HUD needs no perms, weapons do - hence my first thought as to cause] - but end result; broken.

    Script reset gives short-lived functionality, possibly same as at first entry to RC - i've been trying to accurately diagnose, but too much info, too late in the day.

    Soon as I TP anywhere off RC, functionality is restored, no script reset required. The scripts themselves in normal use never reset, other than at owner change.

    It might not be rocket science, but this is a very well routined, error-trapped script set, in use by some thousands of users.

    Freebies available to anyone whose name begins with 'L' ;-)

    I need to Jira, but... tomorrow... yawn... sorry.

    Name2Key - vwrsearch workaround

    in LSL Library

    Posted

    Seems Jiras are being updated now, just got notification. 
    Have to say thank you Martin for providing the alternative... though I'm glad I didn't do a massive round of product updates that I now might have to revert, only changed a few of my own tools, simpler revert.

    Deploys for the week of 2013-05-06

    in Second Life Server

    Posted

    not certain whether it's directly related to the server deploy, but several users have been reporting the old 'face East after TP' behaviour has changed.

    The direction faced now appears to be random overall, but sim-specific. TPing back & forth between several sims repeatedly seems to give the same direction for each specific sim, yet different to the other sims in the 'set' no matter what order you visit them.

    I tested with 2 avies - they don't face the same way as each other at the same landing points.

    https://jira.secondlife.com/browse/BUG-2538

    vwrsearch.secondlife.com is down

    in Second Life Server

    Posted

    You really seem to be missing the point here.
    If your required avi is nearby when you grab their details, then it's your choice whether you store name &/or key, as both are readily available to you with zero uncertainty.
    If you need, for instance, a user to fill in an admin list in a NC, then you have no alternative but to rely on some form of search. 

    I shall simply avoid the issue as much as I can in future - I shall only check names against keys at the point of interaction, when I can also be certain of my data being accurate. For some scripters, this isn't a viable alternative.

    3.4.4 - textures stuck in reloading cycle on OSX

    in Second Life Viewer

    Posted

    It's based on the maximum 'guesstimated' figure that SL will actually feed you at, allowing for the auto-throttle to work correctly. Setting it much higher will break the auto-throttle, or so I'm fairly reliably informed.

    If you use HTTP textures & inventory, this throttle is largely ignored for those, as are all streaming, media & voice services, which run 'outside' SL - but if that slider setting is eating all your available bandidth already, then those other services may struggle as a side-effect.

    3.4.4 - textures stuck in reloading cycle on OSX

    in Second Life Viewer

    Posted

    Just a note - changing HTTP settings requires a relog.

    While you're doing that, power-cycling your router wouldn't hurt either. [switch it off, wait 2 mins, switch it on again]

    And while everything's all freshed-up, run a speedtest to Dallas http://softdallas.speedtest.net

    Hit Preferred, not Recommended - it doesn't matter how fast your line is to near you, it's how fast it is to where SL is.

    Multiply your resulting download speed by 800 to get your ideal bandwidth setting, BUT maximum 1500 whatever speed you get. For wi-fi connections, reduce that to 500.

×
×
  • Create New...