Norton Burns

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 ;-)

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); } }

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);

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.

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.

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

They're all BUG Jiras, not visible to most users

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.

The essential aspect of this is... "by script" If the search result doesn't follow a very repeatable pattern, or if you can't access it without a proxy, life gets difficult.

"but clearing cache from time to time is still a good thing." Why, oh why, oh why, do people still maintain this? Cache is like soap... self-cleaning. Leave it alone unless you have good reason to clear it. It's not like an engine, it doesn't need an oil change every 10,000 rezzes. Read http://wiki.phoenixviewer.com/cache for a good idea of when to & when not to blame cache for issues.

This is hugely unscientific & merely based on hearsay & poke-it-and-see... ... but flicking alpha masks off & on draws everything in straight away when faced with this situation, in my experience.

Thank you for stating the obvious - without the faintest idea as to what the subject was & why the previous comment was smug, wrong & not at all helpful.

Well, as a) the 4 Jiras on it appear to be being actively investigated & b) vwrsearch is not 'old search' I'll wait til I can find out from someone with a real idea.

A lot of scripted content uses it - lots of things are currently broken because it's down

vwrsearch.secondlife.com is down - does anybody know if this is just a glitch, or part of some larger plan?

Glad you got it sorted

if you're happy tinkering in the Registry, you can also remove the icon overlays, as described here - http://wiki.phoenixviewer.com/cloud_storage Don't try the tcmalloc fix unless you're actually on Firestorm. I have no idea how it would behave if you changed it on any other viewer.

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.

Check whether it's only RC sims, maybe?

the only vaguely relevant debug I know is TextureDiscardLevel which has a range of 0 - 5 & should always be set at 0

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.

the Find Widgets bug should be fixed in recent FS versions [since 4.1.1 afaik]

It would probably be more effort to pull the SSB code out of the OSGrid version than leave it in. SSB viewers will still have fallback to the old system; so there should be no problem.

Are you running any kind of cloud storage software? MS SkyDrive [part of MS Essentials & may have been installed without your knowledge] is the worst culprit for this.

My guess is you have an ATI graphics card with the Catalyst 12.10 drivers Check the Help menu in the viewer... help/about 'viewername' viewer... Windows Graphics Driver Version: 8.17.0010.1151 is 12.10 You could try the lastest, v13.1 or rollback to either v12.6 [for new 7-series cards] or 12.1 [not to be confused with 12.10] for any other ATI card. See http://support.amd.com/us/Pages/AMDSupportHub.aspx