Error editing notecards or scripts after the RC BlueSteel 13.05.20.276216 upgrade

[JohnQ Ballyhoo]

Anyone else getting errors when trying to open full perm notecards or edit their own scripts after the RC BlueSteel 13.05.20.276216 upgrade?  I can still do both on sims running 13.05.20.276191 just fine.

JohnQ Ballyhoo

[JohnQ Ballyhoo]

Update:

Found I can edit my scripts if I rez a box and drop the script in. 

Also found I am not able to accept objects from other people when either dropping on my chat window or directly on my avatar.  No blue accept popup is shown and nothing appears in my inventory.  Works just fine on 13.05.20.276191 sims.

Can someone please comment on what might be causing this?
This is effectively shutting down my scripting business. 

Thanks...

 

 

 

[Theresa Tennyson]

When did you notice this? 276216 has been on BlueSteel sims since last Wednesday. In any event that code isn't being promoted this week and there will be a different project on BlueSteel that will be loaded on Thursday.

[JohnQ Ballyhoo]

Can't say exactly when, but I first noticed it about two days ago.  I've been editing scripts out of a rezzed object since I know Sunday which were working fine, but just started noticing the error when trying to edit scripts out of inventory today.

And just a while ago I had my partner try dropping an item on me and found that wasnt working either.  Moving to a 276191 sim worked.

[Theresa Tennyson]

I just successfully edited both old and new scripts from inventory on a BlueSteel sim running 276216. It may be a problem with a specific sim.

[Whirly Fizzle]

There was an issue reported on last weeks LeTigre RC (that had the interest list changes) which caused them not to be able to load large scripts. Those changes have been rolled out to all the RC's today.

What is your maximum bandwidth setting in the viewer?

The advice from Andrew Linden was to test if you can still reproduce the problem when you lower the maximum bandwidth setting in the viewer to ~200kbps.

[Andrew Linden]

Yes, the problem only affects people with certain internet connections.  In particular connections that suffer UDP packet loss at relatively low bandwidth settings.  Doing a normal HTTP download speed test on such a connection may indicate a higher bandwidth than is supported for UDP traffic -- TCP traffic may be treated differently than UDP.

The workaround is to lower you SL viewer bandwidth settings in the preferences.  The one resident who tried this was able to make the scripts load at 350kbps or lower.  This will not necessarily degrade your SL experience as much as you might expect.  The bandwidth setting only applies to UDP traffic -- HTTP traffic (which includes texture downloads) automatically adjusts itself to shat your connection can handle and is not regulated by the setting.

I've got a theoretical fix for the problem but am having trouble reproducing a UDP restricted environment to test it.  I've temporarily deployed the experimental server to the Gibson region on the beta grid.  If anyone would like to test it there I will help by getting your account imported to the beta grid.

[Andrew Linden]

Turns out my theoretical fix did not work, but I did get some clues today that I hope will help me figure it out.

[Andrew Linden]

I have a fix for this but it didn't make it in time for this week's update (for unrelated technical problems).  It is currently deployed to the DRTSIM-208 channel on the beta grid (aditi) which includes the region "Gibson" if anyone wants to check it out.  Antony Fairport, who first reported this problem in a jira issue, has tested it and has verified that it works.