Re: [opensource-dev] Current status of Mesh??

[Kelly Linden]

On Wed, Aug 31, 2011 at 10:16 AM, Robert Martin wrote:

> Does anybody know of some sort of documentation on the ins and outs of
> mesh??
> And before you say the SL wiki everything there is one or more of 1
> Outdated 2 FICTIONAL 3 without any actual details
> (unless of course its been massively updated in the last week or so)
>
> Questions i have
>
> 1 what is the conversion of Vertexes to Prims?? (how many vertexes do
> you get for a "prim")
>

Yes, it is much more complicated.
http://community.secondlife.com/t5/English-Knowledge-Base/Calculating-prim-equivalent-weight/ta-p/974163


> 2 are there any simple tools to make models (Blender does not qualify).
>

https://wiki.secondlife.com/wiki/Mesh/Creating_a_mesh

I've heard good things about Wings3D. There are several tool-specific wiki
pages on the category page (https://wiki.secondlife.com/wiki/Category:Mesh)
with names along the lines of "Mesh/Exporting a mesh from" that might give
some hints on the level of support and complexity of the tool.


> 3 are non-biped avatars supported in mesh?? (quads are the biggest concern)
>

While Kadah is correct, for a 'quad' I would bet you could use the arms with
custom animations.. This page has a list of the joints:
https://wiki.secondlife.com/wiki/Mesh/Troubleshooting

Hope that helps!
 - Kelly
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Management Algorithm

[Kelly Linden]

We are not out to write a new malloc for mono.  What we have is a system
that throws an exception when the memory used by the script hits a certain
threshold (64k currently).  This exception is caught so we can "crash" the
script.  The future small scripts and big scripts projects will add new
functions to set and get this threshold value, allowing scripters to
effectively control how much memory is reserved for their script.  We will
continue to use mono's default memory management within the reserved memory
thresholds.  It is a much simpler problem to solve.

 - Kelly

On Sun, Mar 7, 2010 at 5:50 AM, Carlo Wood  wrote:

> Lets assume that the *average* script uses
> 8 to 16 kB of real memory. LL's design allocates
> 64 kB regardless, leading to an overhead of
> 400 to 800% (meaning they need to buy 5 to
> 9 times the memory that is theoretically needed).
>
> In that light, I gave it some more thought, and
> think something as complex as my rmalloc's algorithm,
> with it's 19% overhead, isn't needed (note that
> it's both faster than gmalloc as well as three
> times more efficient; so complexity is not always
> a bad thing ;).
>
> Nevertheless, in this case, since the scripts
> use a maximum of 64 kB, you can use the
> following design:
>
> Let each allocated block be a power of 2
> kilobytes, with a maximum of 64 kB (and a
> minimum of 1 KB, or 4 if even the tiniest
> script needs that).
>
> It is easy to see that this would lead
> to an overhead of 25% on average per
> allocated block.
>
> We'd still have to deal with "holes" of a
> full 64 kB where blocks became totally
> unused, but normally scripts in objects are
> started all at once when a sim reboots, and
> only seldom stopped. The scripts that will
> most likely attribute to random starting
> and stopping of scripts will be the scripts
> in attachments. A worst case scenario would
> be one where there are 50 avies in a sim
> (during a meeting), then a new avie enters
> with some scripts which need to be allocated
> at the top of the heap; then the previous
> 50 avies leave. That would create a hole
> in the heap of the size of all the scripts
> of those 50 avies. If script memory would
> be relocatable, then this problem doesn't
> exist of course. I can't simply estimate
> the average overhead caused by this, but
> because the algorithm described here is
> basically the one used by gmalloc (which
> in my test used 62% overhead) I'm pretty
> sure that it will be less than -say- 100%
> overhead; still 4 to 8 times more efficient
> than the current design on the table.
>
> The API for this design would be something
> like the following:
>
> namespace script_memory_management {
>
> void* ll_sbrk(ptrdiff_t);   // Increment the size of the heap
> int   ll_brk(void*);// Set the size of the heap explicitely
>
> void* ll_malloc64(void);// Get a new 64 kB block.
> void  ll_free64(void*); // Free such a block.
>
> void* ll_malloc(size_t s);  // Allocate s bytes of memory for a script.
> void  ll_free(void*);   // Free it again.
>
> ...
>
> Assuming here that scripts cannot deal with
> relocation, otherwise one should also have:
>
> void* ll_realloc(size_t s); // Allocate a different size of memory.
>
>
> ll_malloc then will round the number of requested bytes up
> to the nearest power of 2 (kBs) and retrieve a block from one
> of the free lists (maintained for 32, 16, 8, 4, 2 and 1 kB)
> (note that if scripts only seldom use 1 or 2 kB it might
> be more efficient to use a minimum of 2 or 4 kB instead of 1).
>
> Each 64 kB block would contain either one 64 kB allocation,
> or two 32 kB block allocations, or four 16 kB block allocations,
> etc, but never allocations of mixed sizes, thus making it
> easy to find a free block of such size.
>
> A free list is usually maintained by adding pointers inside
> the (unused) memory blocks, linking them together to a linked
> list of free memory blocks of a given size. That causes allocating
> to be instant, but freeing memory requires to traverse this
> list in order to update it's pointers. With the number of
> scripts that normally run in a sim this will not be a problem.
>
> --
> Carlo Wood 
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script memory limit vs server CPU utilization as a key metric

[Kelly Linden]

Hi Joel.

This is an interesting issue.  You would think CPU would be the big issue,
but really it isn't.

* We actually do a decent job of time slicing scripts.  You add a lot of
scripts and in general just the scripts run slower, sim performance isn't
that impacted.
* WAIT! Before you yell at me for that statement read this one: most of the
script sources of lag are *specific* and actually caused by LSL triggered
non-LSL events. For example temp-rezzers can kill sim performance.  It isn't
the script that kills it though, it is the rezzing of the object, and the
derezzing.  Yes the script causes that, but it isn't script CPU type that is
hindering the performance. (BTW we are working on reducing the impact of
rezzing! ssshhh)
* ALL RIGHT! Yes there are other exceptions, scripts with high script time
that effect the sim. But these are generally exceptions.  The summary is
though, that script CPU time is relatively well handled, though I admit it
could be better.
* Yes better allocating script CPU time so that one user can't impact the
scripts of everyone else is also a great goal - it just isn't as high a
priority as script memory right now.

moving on
* Sim's going in to swap is one of the biggest issues with sim peformance we
have right now.  It is significantly more of a problem than script CPU
time.  And when it happens all stats tank.
* The fact that script memory is unbounded, that you can have a single prim
object with thousands of scripts (technically unlimited, but the viewer
behaves weird after a while) is a real problem.  Someone built a
GoogleFS-like system in SL that could in theory hold many gigabytes of
data.  They thankfully never deployed the full system.
* When sims use too much memory they don't just affect themselves they
affect their neighbors - the other regions running on the same host.

So yeah, it is kind of weird, but memory is the bigger performance issue so
we have chosen to address it first.

 - Kelly

PS - nice to chat with you again, feel free to contact me directly if you
wanna chat more. Hope things are going well.

On Tue, Mar 9, 2010 at 10:49 AM, Joel Foner  wrote:

> Many apologies if this has been discussed at length in a place that I've
> missed...
>
> I'm a bit baffled by the continuing strong focus on memory utilization of
> scripts rather than CPU load on the host servers. If (maybe I'm missing an
> important issue here) the issue is to avoid a resident or scripted item from
> causing performance problems on a region, wouldn't the relative CPU load
> imposed by that script be a critical item?
>
> I understand that if the total active memory size for a server goes above
> it's physical available RAM, then paging would increase and potentially
> create issues. Is there some objective analysis of servers with the Second
> Life simulator code on to show that they go into continuous swap mode in
> this case, or is it occasional "blips" of performance degradation on a
> slower interval? It seems to me that having continuing excessive CPU load
> would generate an on-going low simulator frame rate, which would be more
> frustrating than occasional hits from swapping.
>
> This line of thinking makes me wonder if a better metric for managing the
> user's perception of performance would be script CPU load rather than memory
> size.
>
> Thanks in advance, and again if this has already been addressed please feel
> free to point me at the thread so that I can read up.
>
> Best regards,
>
> Joel
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Request for comments about llSetAgentEnvironment / SVC-5520

[Kelly Linden]

Honestly allowing content creators to set the theme of a place seems like a
pretty awesome idea.  It isn't shoving settings down your throat any more
than the textures an estate owner chooses for the ground or a content
creator for the walls of their house.  Just like you can choose to force it
to noon/sunrise/sunset/whatever an easy way to revert the environment to
normal (or your desired preset) would be required, of course.  But you can
also leave if you don't like the mood of the place, or the psychodelic sky.
 Right now the biggest benefits of windlight past the default settings is
pretty much limited to machinima and screenshots - there is no easy way to
share that environment with others.  As a content creator there is no way
set the mood of the sky to go with your build - you always get blue skys
with a smattering of clouds, or a starry night.

Claiming this is forcing settings down your throat is over reacting and fear
mongering.  It really is no different than setting the water level, the
ground textures, the time of day, and even the content that is built in
world.  Windlight settings should be a part of the build and not something
you have to opt into or be bugged with a dialog to see.*

 - Kelly

* None of this is a statement of intent to implement any of these
suggestions or non-suggestions.  I am only addressing the fear of people
setting the sky texture and variables.

On Wed, Mar 10, 2010 at 9:20 AM, Tigro Spottystripes <
tigrospottystri...@gmail.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> i know, but i think that it would be better if the client itself worked
> like what i described, without the need of third party additions
>
> On 10/3/2010 14:14, Marine Kelley wrote:
> > The RLV does just that, force your viewer Windlight settings with an
> > object that you own.
> >
> >
> > On 10 March 2010 18:03, Tigro Spottystripes
> > mailto:tigrospottystri...@gmail.com>>
> wrote:
> >
> > sim owners can already control the Sun position in your client, the rest
> > of the WL parameters is just an extensions of that
> >
> > there should be a way to set your client to ifnore sim settings if you
> > want to though
> >
> > On 10/3/2010 13:47, Maggie Leber (sl: Maggie Darwin) wrote:
> >> On Wed, Mar 10, 2010 at 11:36 AM, Tigro Spottystripes
> >>  > > wrote:
> >
> >>> parcel and sim owners shouldn't need to ask for permission...
> >
> >> Nonsense.
> >
> >> If you want to reconfigure my viewer, you need my permission.
> > Every time.
> >
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.12 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuX1OkACgkQ8ZFfSrFHsmUKfACgjQhcK2MZeG9WB1PqhTM/Yf87
> EiEAn0KYIgEscYulkhxaC6ULT6N+3Pzy
> =fnuz
> -END PGP SIGNATURE-
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Request for comments about llSetAgentEnvironment / SVC-5520

[Kelly Linden]

On Wed, Mar 10, 2010 at 9:34 AM, Maggie Leber (sl: Maggie Darwin) <
mag...@matrisync.com> wrote:

> On Wed, Mar 10, 2010 at 12:29 PM, Kelly Linden 
> wrote:
> > Windlight settings should be a part of the build and not something
> > you have to opt into or be bugged with a dialog to see.*
>
> Well, then how about automatic applications of animations to your
> avatar, because a "content creator" thought it would be arty or cool?
>

Welcome to the other nightmare I'm dealing with for server 1.38.  Ultimately
there is a difference between affecting the personification of *you* by
animating you or taking your controls or your camera hostage and changing
how the world you are in looks.


> Or malicious Windlight settings that blind you, because it's
> "artistic" and "part of the shared experience"?
>

I've been banned from viewer UI design, for good reason.  I end up with
developer UI, and with 2.0 they managed to scrub the last remnants of my UI
from SL.  That aside, I could see 'reset the damn sky' as a top level action
similar to 'stand' - a button on screen above the bottom bar maybe.  And a
good keyboard shortcut.  Yes, it should be possible for a blinding sky to be
part of an artistic shared experience, and it should be easy to get out of.
 And yeah, some advanced option for 'don't let my windlight settings change'
seems like a good idea also.  But the default should be for the windlight
environment to be part of the content you are visiting.

>
> The enhancement request as it stands calls for a permissions opt-in
> for having your viewer settings changed, and I support it in that
> form.
>

I admit I only briefly skimmed the jira.  I was mostly reacting to the panic
I saw here.  I don't think it needs a permission request in the case of
parcel  owners, but that is just my personal opinion. I do believe the
environment should be promoted to being part of the content and not part of
the viewer, I think we get more amazing in world experiences that way.

 - Kelly
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Request for comments about llSetAgentEnvironment / SVC-5520

[Kelly Linden]

On Wed, Mar 10, 2010 at 9:53 AM, Maggie Leber (sl: Maggie Darwin) <
mag...@matrisync.com> wrote:
>
>
> If it was easier to do, would you even be lobbying to make them
> automatic under the control of the parcel owner?
>

Absolutely. In fact, being easy to change / fix / revert would be a pre-req
in my mind.

>
> > I think we get more amazing in world experiences that way.
>
> If I'm going to have "amazing experiences", I'd like to to be
> voluntary, thanks. And if you're going to accuse me of
> "fear-mongering" and "panic", do kindly read the JIRAs first.
>

They should be voluntary in the sense that any content or place in SL is
voluntary.  The very sky around you should be part of the content, part of
the place. I can't get over how awesome I think that would be.

 - Kelly
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Where has "Spare time" gone in 2.0 ?

[Kelly Linden]

I updated that page yesterday because it was wrong. "Full" regions are 1 per
core and always have been. There are no plans I am aware of to change that.

- Kelly
(sent from my phone)

On Apr 26, 2010 6:33 AM, "Tayra Dagostino" 
wrote:

On Mon, 26 Apr 2010 09:09:55 -0400
Gigs  wrote:

> Tayra Dagostino wrote:
> >...
not yesterday, take a look on history change page...

___
Policies and (un)subscribe information available her...
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] kindof OT but .. Teens on the Main grid (linden response only please)

[Kelly Linden]

The linden response is nothing that others couldn't tell you:
* This is not the list for it.
*
http://wiki.secondlife.com/wiki/Linden_Lab_Official:How_to_report_an_underage_Resident_in_Second_Life

 - Kelly

On Mon, Apr 26, 2010 at 12:48 PM, Robert Martin wrote:

> If i have run into a person that is on the main grid but is underage
> not including doing an AR is there a "nicer" way to have the account
> ported to the teen grid? Bonus if there is a Linden that exists on
> both grids that can handle it.
>
> --
> Robert L Martin
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[Kelly Linden]

You will be Andromeda Quonset across all viewers and all scripts. All
existing scripts and new scripts using the existing functions will continue
to get Andromeda Quonset. You will *never* be Andromeda Resident (unless you
make another account after the change takes effect). Andromeda Resident
would be a completely separate account from Andromeda Quonset, just as
Andromeda Omega would be today. 'Resident' is just the final last name, and
is treated specially on new viewers to be hidden from view when displayed.

Your account will NOT change to Andromeda Resident. It will NOT change to
Andromeda.Quonset Resident. Resident will not be tacked onto the end of any
existing avatar's name.

All existing script library calls will forever more continue to return the
'full name'. Existing lists of avatars will continue to match their list of
avatars. There will be some potential confusion for new residents who will
identify as "John12345" or "John Smith" but not "John12345 Resident".

There will be entirely new LSL function calls to handle display names.

 - Kelly

On Tue, Aug 17, 2010 at 3:51 PM, Andromeda Quonset <
andromedaquon...@gmail.com> wrote:

>  Indeed.  Wasn't there an issue in recent weeks/month with regard to the
> forum software and the case of the first letter of a name?
>
>
> At 04:23 PM 8/17/2010, you wrote:
>
> The fact that people have lower case first names isn't always a typo, in
> many cases it is intended.  Please do not force capitalization on names.
>
>
>
> On Tue, Aug 17, 2010 at 6:13 PM, Bryon Ruxton  wrote:
>  As you are implementing this, you may to consider forcing capitalization
> via
> JavaScript or else on the first name (from the official actual username)
> e.g. "first Linden" look bad as if there is a typo in there and such proper
> nouns are normally capitalized.
>
> I have always found it annoying to see lowercase first names. It is
> probably
> mostly a result of omissions, but also tends to happen more frequently with
> younger users. And as we "officially" will get 16 and 17 years old it is
> much more likely to happen.
>
> It happens a lot in shopping carts or any web user database if you don't
> automatically capitalize first and last names or addresses by code, which I
> now tend to do to prevent such inconsistence in postage labels, etc...
> It would make for a more consistent database too.
>
> On 8/17/10 2:41 PM, "Brian McGroarty"  wrote:
>
> > On Tue, Aug 17, 2010 at 2:34 PM, Lance Corrimal
> > < lance.corri...@eregion.de> wrote:
> >> ...
> >> http://blogs.secondlife.com/community/features/blog/2010/08/17/display-
> >> names-bringing-greater-self-expression-to-second-life
> >>
> >> ... I guess that means the end for logging in with 1.x based viewers,
> >> does it?
> >
> > Old viewers will continue to work. Old accounts would continue to log
> > in as they do today. New accounts log in with their username as their
> > first name and "Resident" as the last name. (For the difference
> > between username and Display Name, see the FAQ linked at the end of
> > the blog post).
> >
> > Under the hood, for all legacy viewers and scripts, the only real
> > change is that new accounts created after some point will only ever
> > have "Resident" as a last name. The new Display Names won't replace
> > usernames in any location within an old viewer.
>
>
> ___
> Policies and (un)subscribe information available here:
>  http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
>
> ___
> Policies and (un)subscribe information available here:
>  http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[Kelly Linden]

* Scripts will work the same across all viewer versions. Scripts are server
side. It does not matter which viewer you use.

* You will never be Andromeda DisplayName.

* You will never be Andromeda Resident

* You will never be Andromeda.Quonset Resident

* You will always be Andromeda Quonset to all existing scripts and all
scripts that do not use new DisplayName functions.

* If you never use a new viewer and do not set a display name you will
always be Andromeda Quonset to everyone else, no matter what viewer they
use. New llGetDisplayName function will still return Andromeda Quonset. New
llGetUserName function may return  Andromeda.Quonset.

* IF (and only IF) you use a new viewer AND set a display name (lets say to
"Andromeda") then other people may see you as Andromeda. Any scripts that do
llGetDisplayName will get Andromeda. If they do llKey2Name they will get
Andromeda Quonset. If they do llGetUserName they will get Andromeda.Quanset.

* For a new user that registers as Joe1234 and sets their display name to
Joe:
llKey2Name will return Joe1234 Resident
llGetUserName will return Joe1234
llGetDisplayName will return Joe

There is a big caveat here: It is possible the LSL functions available that
I see are not the final versions or what will be released. But they should
be very close.

 - Kelly

On Tue, Aug 17, 2010 at 4:13 PM, Andromeda Quonset <
andromedaquon...@gmail.com> wrote:

> Sighs.  I see you misunderstood.  Perhaps I have, too, in usage of
> the word "Resident".
>
> In my post, where I referenced "Andromeda Resident", change that to
> "Andromeda DisplayName"
>
> In a script that has been compiled to use a new function, presumably
> compiled under a 2.X viewer, when an AV that is logged-in under a 1.X
> viewer, and activates the script compiled under 2.X, will need to
> have results returned to him based on a 1.X compilation, and not a
> 2.X compilation in order to not cause a runtime error.
>
> I doubt I will be doing any scripting anytime soon in a Client 2
> environment, given the major issues I have with viewer, like the
> entire world being a 4 x 4 inch area to work from in the middle of my
> 22" widescreen with great big blacked-out edges to fill-in around
> that 4 x 4 inch area.  And there is the issue of the script editor
> being seriously broken.  Can't edit scripts without a script
> editor.  And there is the issue of doing an uninstall of the 2.X
> client, and having it delete 5 years of chat dialog as it tidies up
> after itself.
>
> Best thing as I see it is to not implement it.  Maybe in 2012 we can
> look revisit it.
>
> At 04:54 PM 8/17/2010, you wrote:
> >This is correct. Andromeda Quonset will be Andromeda Quonset forever.
> >At some point, new residents won't be able to choose a last name -
> >only these will be "Resident"
> >
> >No existing script function will return different results than it does
> >today. New script functions are added for fetching/referencing Display
> >Names.
> >
> >On Tue, Aug 17, 2010 at 3:47 PM, Erik Anderson
> > wrote:
> > > My interpretation of what was said is that the script using a 2.X
> viewer
> > > would NOT say "Andromeda Resident", SL is just stating that users in
> the
> > > future will not be asked for a last name when they sign up, all new
> users
> > > after that point would have a last name of "Resident", which the
> > 2.X viewers
> > > would likely hide.
> > >
> > > On Tue, Aug 17, 2010 at 3:45 PM, Andromeda Quonset
> > >  wrote:
> > >>
> > >> It appears to me that if I create a script using viewer 1.X, it will
> > >> show as being created by Andromeda Quonset.  It also appears to me
> > >> that if I create the same script using a 2.X viewer, that it will say
> > >> it was created by Andromeda Resident.
> > >
> > >
> > > ___
> > > Policies and (un)subscribe information available here:
> > > http://wiki.secondlife.com/wiki/OpenSource-Dev
> > > Please read the policies before posting to keep unmoderated posting
> > > privileges
> > >
> >
> >
> >
> >--
> >Brian McGroarty | Linden Lab
> >Sent from my Newton MP2100 via acoustic coupler
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[Kelly Linden]

(lets move this to the scripters list?)

I need to refresh myself on this. There should be 3 names:
user name: latif.khalifa
full name: Latif Khalifa
display name: The Awesome Latif

Most (all?) the existing LSL functions will return the 'full name'. I also
find it confusing to use Kelly DifferentLastName as an example display name.
This isn't about picking a new last name. It is about being just 'Kelly' or
'Teh Kellz'. Sorry, it was just part of what was confusing me about the
previous examples.

A new user is:
user name: john1234
full name: john1234 Resident
display name: john

The full name is pretty much only relevant for LSL for legacy purposes. We
spent quite a bit of time trying to find the right way to handle LSL to
cause the least amount of breakage. Scripts that parse for a space to get a
first name should still work, scripts that require a unique name should
still work, scripts that require names to match those stored in a notecard
or otherwise stored should still work. These seemed the most common cases.
Scripts that ask the user to enter their name and then check that against a
sensor event may "break" because what people think of when you ask them for
their name will change, especially for new users. These scripts will need to
be updated.

This is probably a good topic for my OH next week, at least the LSL specific
portion.

 - Kelly

On Tue, Aug 17, 2010 at 7:21 PM, Latif Khalifa wrote:

> The big source of confusion regarding scripts is the following line
> from the FAQ:
>
> "Your username will automatically be formed from your existing avatar
> name in the form of your current Second Life firstname.lastname."
>
> Since existing functions will return username, does that mean they
> will return "latif.khalifa". Which is my username, "Latif Khalifa" or
> "latif.khalifa"?
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[Kelly Linden]

I wanted to amend this that I also think 'Full Name' is what is shown in old
viewers as well as for legacy LSL. But I need to triple verify that.

 - Kelly

On Tue, Aug 17, 2010 at 7:55 PM, Kelly Linden  wrote:

> (lets move this to the scripters list?)
>
> I need to refresh myself on this. There should be 3 names:
> user name: latif.khalifa
> full name: Latif Khalifa
> display name: The Awesome Latif
>
> Most (all?) the existing LSL functions will return the 'full name'. I also
> find it confusing to use Kelly DifferentLastName as an example display name.
> This isn't about picking a new last name. It is about being just 'Kelly' or
> 'Teh Kellz'. Sorry, it was just part of what was confusing me about the
> previous examples.
>
> A new user is:
> user name: john1234
> full name: john1234 Resident
> display name: john
>
> The full name is pretty much only relevant for LSL for legacy purposes. We
> spent quite a bit of time trying to find the right way to handle LSL to
> cause the least amount of breakage. Scripts that parse for a space to get a
> first name should still work, scripts that require a unique name should
> still work, scripts that require names to match those stored in a notecard
> or otherwise stored should still work. These seemed the most common cases.
> Scripts that ask the user to enter their name and then check that against a
> sensor event may "break" because what people think of when you ask them for
> their name will change, especially for new users. These scripts will need to
> be updated.
>
> This is probably a good topic for my OH next week, at least the LSL
> specific portion.
>
>  - Kelly
>
>
> On Tue, Aug 17, 2010 at 7:21 PM, Latif Khalifa wrote:
>
>> The big source of confusion regarding scripts is the following line
>> from the FAQ:
>>
>> "Your username will automatically be formed from your existing avatar
>> name in the form of your current Second Life firstname.lastname."
>>
>> Since existing functions will return username, does that mean they
>> will return "latif.khalifa". Which is my username, "Latif Khalifa" or
>> "latif.khalifa"?
>>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[Kelly Linden]

On Thu, Aug 19, 2010 at 4:18 AM, Jesse Barnett  wrote:

> baloo198731.residentPlenty of names available.
>

I just wanted to point out that this theoretical new user's username would
be baloo198731, it would not be baloo198731.resident. The 'Resident' isn't
really a part of a new user's identity. It is only shown to viewers that do
not support display names and legacy LSL script calls - in other words that
last name is only there when required for backwards compatibility.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[Kelly Linden]

No. Account names must be unique. No new user can create ann.otoole OR
annotoole as a username, that name is taken by you.

 - Kelly

On Thu, Aug 19, 2010 at 9:42 AM, Ann Otoole  wrote:

> Do I understand you correctly that new accounts can make their name
> anything including existing account names?
>
> --
> *From:* Kelly Linden 
> *To:* Jesse Barnett 
> *Cc:* opensource-dev@lists.secondlife.com; Baloo Uriza <
> ba...@ursamundi.org>
> *Sent:* Thu, August 19, 2010 11:27:21 AM
>
> *Subject:* Re: [opensource-dev] display names = the end of 1.x viewers?
>
> On Thu, Aug 19, 2010 at 4:18 AM, Jesse Barnett  wrote:
>
>> baloo198731.residentPlenty of names available.
>>
>
> I just wanted to point out that this theoretical new user's username would
> be baloo198731, it would not be baloo198731.resident. The 'Resident' isn't
> really a part of a new user's identity. It is only shown to viewers that do
> not support display names and legacy LSL script calls - in other words that
> last name is only there when required for backwards compatibility.
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[Kelly Linden]

On Thu, Aug 19, 2010 at 9:43 AM, Aidan Thornton  wrote:

> On 8/19/10, Kelly Linden  wrote:
> > I just wanted to point out that this theoretical new user's username
> would
> > be baloo198731, it would not be baloo198731.resident. The 'Resident'
> isn't
> > really a part of a new user's identity. It is only shown to viewers that
> do
> > not support display names and legacy LSL script calls - in other words
> that
> > last name is only there when required for backwards compatibility.
> >
>
> Which has the interesting side-effect that you can't trivially convert
> from a username to a legacy full name since there are two different
> possible conversions and no way of telling which is correct without
> accessing the login database, right?
>
>
There is no such thing as a legacy full name for non-legacy accounts.  We
tack on a 'Resident' last name when required for compatibility with viewers
that do not understand display names and legacy LSL calls, but it is not a
part of their name. But in essence you are correct. You can go from a 'full
name' to a 'username' but not as easily the other way - though parsing for a
'.' is likely to get you pretty good results. If you have the UUID (which
you should in both viewer code and LSL) you can get whichever name you want
- username, full name or display name.

 - Kelly
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] display names = the end of 1.x viewers?

[Kelly Linden]

On Thu, Aug 19, 2010 at 10:03 AM, Kelly Linden  wrote:

>
>
> On Thu, Aug 19, 2010 at 9:43 AM, Aidan Thornton wrote:
>
>> On 8/19/10, Kelly Linden  wrote:
>> > I just wanted to point out that this theoretical new user's username
>> would
>> > be baloo198731, it would not be baloo198731.resident. The 'Resident'
>> isn't
>> > really a part of a new user's identity. It is only shown to viewers that
>> do
>> > not support display names and legacy LSL script calls - in other words
>> that
>> > last name is only there when required for backwards compatibility.
>> >
>>
>> Which has the interesting side-effect that you can't trivially convert
>> from a username to a legacy full name since there are two different
>> possible conversions and no way of telling which is correct without
>> accessing the login database, right?
>>
>>
> There is no such thing as a legacy full name for non-legacy accounts.  We
> tack on a 'Resident' last name when required for compatibility with viewers
> that do not understand display names and legacy LSL calls, but it is not a
> part of their name. But in essence you are correct. You can go from a 'full
> name' to a 'username' but not as easily the other way - though parsing for a
> '.' is likely to get you pretty good results. If you have the UUID (which
> you should in both viewer code and LSL) you can get whichever name you want
> - username, full name or display name.
>
>  - Kelly
>
>
I have been corrected. Only 'legacy' names will have a '.'. I was not aware
when I responded above that the period is not valid in new user names. So
yes, you can parse for a '.' to know if it is a 'legacy' name or a new name.
Sorry for the confusion.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] where is the source

[Kelly Linden]

I'd love to see that syntax highlighting and hover tip code replaced, we
really shouldn't need anything in lscript in the viewer. If the syntax
highlighting / hover tips could be read from an LLSD we could provide a
capability 'lsl-syntax' which could be queried for a version or the whole
map. Then you could get accurate syntax highlighting for the sim you are on
independent of the viewer.

 - Kelly

On Mon, Sep 13, 2010 at 4:16 PM, CG Linden  wrote:

> I believe that that code is used for the syntax highlighting -  and indeed,
> " llGetLinkPrimitiveParams()" doesn't highlight in the viewer...
> --
> cg
>
>
> On Mon, Sep 13, 2010 at 11:44 AM, Altair Sythos  wrote:
>
>> On Mon, 13 Sep 2010 16:47:28 +0200
>> "Garmin Kawaguichi"  wrote:
>>
>> > Is it the last last source code?
>> >
>> > I say that after reading :
>> >
>> https://bitbucket.org/lindenlab/viewer-development/src/tip/indra/lscript/lscript_library/lscript_library.cpp
>> > where llClearPrimMedia is the last function. Where are :
>> > llSetLinkPrimitiveParamsFast, llGetLinkPrimitiveParams,
>> > llLinkParticleSystem, llSetLinkTextureAnim, llGetLinkNumberOfSides
>>
>> mono script are server side compiled, i think all these are inside
>> internal LL branch
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] User Story: Improved Cache

[Kelly Linden]

Strictly speaking I think you have the stories and tasks reversed here.

As a user I'd like to be able to use a greater portion of my available disk
to improve the SL experience.
* Task: Improve the cache system to allow larger caches

As a user I'd like the places I visit most often, like my 'home' and
favorites, to load more quickly
* Task: Improve the cache system to not discard data for my home (at least
not for a while)
* Task: Improve the cache system to not discard data for my 'favorites'
places (at least not for a while)

As a user I'd like to never have to clear the cache to fix a bug
* Task: Implement a quick and efficient inventory verification to find
inventory cache discrepancies.
* Task: (Are there other common bugs that require a cache clear to fix?)

Improving the cache system is a task (actually multiple tasks) used to
accomplish the three experience stories you have. Stories should generally
be about the end experience, not the underlying system or how the
experiences will be fixed. Yes, that is a rough guide, especially for many
stories where the actor is 'a developer', but it helps still. :)

That said these are great ideas, and should definitely be on a backlog
somewhere if they aren't. I know we have discussed all of them at one point
or another.

 - Kelly

On Thu, Sep 16, 2010 at 9:44 AM, Daniel  wrote:

>  As a user I would like to see an improved cache in order to have a
> better Second Life experience.  The types
> of improvements that would lead to a better experience include:
>
> * A higher cache size limit.  This would let me save more data and speed
> up rez times, and also put less
> load on the server side, since it would not have to refresh discarded
> data as often.  Modern hard drives
> are much much larger than the current 1 GB limit, and I should be able
> to allocate more storage to
> my Second Life data if it improves performance.
>
> * Ability to set certain locations as "home" or "favorites", and to
> never discard or preferentially keep those
> locations in cache.  Places I know I will visit often should not be
> discarded just because I happen to visit
> several other locations in the course of a session.
>
> * More reliability in cache storage, leading to less often need to
> delete cache to fix a problem caused by
> cache corruption.  A low level inventory verification (meaning it does
> not take a large percentage of viewer
> resources) to ensure it matches the asset database is an example, but
> technical implementation I will leave
> to programmers.  The desired result is less frequent issues like
> apparent inventory loss, which upsets users
> and leads to support tickets.
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] User Story: Improved Cache

[Kelly Linden]

On Sun, Sep 19, 2010 at 12:53 PM, Tateru Nino  wrote:

>
>
> On 20/09/2010 3:49 AM, Oz Linden (Scott Lawrence) wrote:
> >On 2010-09-19 10:21, Tateru Nino wrote:
> >> I believe he was referring to the fact that a UUID does not always refer
> >> to the same inworld object. There are instances where an object UUID
> >> will be used more than once.
> >
> > Those would be bugs, by definition.
> Well, it pretty much happens when a sim is down. When that happens,
> objects being instantiated in other sims may be given the same UUIDs as
> objects that are in another sim that is not presently online on the
> grid. When the sim comes back up, the clash in UUIDs is noted, and new
> UUIDs are chosen for any conflicts in that sim. It's been around for
> quite some time, and is a particular pest for someone who wants to refer
> to a server-object by UUID in - for example - an inworld or outworld
> script. Common workarounds involve using an external server for the
> object to register its current UUID to.
>
> That's been the case since 2005, but being a server-side issue is
> probably out-of-scope here.
>
> As far as textures go, I believe the way they are handled as assets is
> different to instantiated objects, and that they do not suffer from the
> same issue. Of course, if log in to more than one grid, there's no
> guarantees that a texture with a given UUID in your cache is the same
> texture that you're supposed to be getting. While the space for texture
> UUIDs is very large, they're only unique to a specific grid and clashes
> will inevitably occur over time.
>
> --
> Tateru Nino
> http://dwellonit.taterunino.net/
>
>
I'm not sure how what you describe could happen. There is no system in place
to detect UUID clashes, especially between different regions/sims, and
nothing that notes them and then replaces them. The way you describe it
makes it sound like there is a central service that hands out UUIDs as
needed and when a region that has been down comes back up it may have UUIDs
that have been given out that need to be corrected. That isn't how UUIDs
work - each process generates its own UUIDs as needed from an algorithm that
attempts to minimize the already slim chance of a collision.

* Rezed objects are given a new UUID (though they will still reference the
'original asset id' for some internal tracking server side)
* An object that is out in the world could be modified and will retain its
same UUID (and local ID) even though the object changes. So it is true that
an object cache based purely on UUID could show stale data - this is a
unique case for inworld objects only. Not inventory, textures, sounds,
gestures, notecards, scripts or even landmarks. All of those will have a
unique ID that never changes.
* The only way I can think of right now to force a UUID 'collision' is to
bring up a duplicate of a region so that the same region is brought up in
two places at the same time, including copying all the content. This is
something that shouldn't happen, and even if we have to we do have a system
to generate new IDs for parcels and content.

* If you have more details about UUID collisions happening, let us know. It
would definitely be a bug and we would want to look into it.

 - Kelly
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] User Story: Improved Cache

[Kelly Linden]

On Sun, Sep 19, 2010 at 3:27 PM, Altair Sythos  wrote:

> On Sun, 19 Sep 2010 13:16:25 -0700
> Kelly Linden  wrote:
>
>
> > * Rezed objects are given a new UUID (though they will still
> > reference the 'original asset id' for some internal tracking server
> > side)
>
> yes but cache was hinted for etxtures, what happen to same textures
> copied or shared to others?
>
> I have a tex, have its UUID, i give a copy to another, both rezz
> something and use this textures
>
> textures is the same, but 2 UUID...
>
> in this way a cache is less usefull (topic started from cache idea)
>

Texture Asset UUIDs do not change even when you give the texture to someone
else. You will each have an inventory item, each with its own inventory
UUID, that points to the same texture Asset UUID.

 - Kelly
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] User Story: Improved Cache

[Kelly Linden]

On Sun, Sep 19, 2010 at 3:13 PM, Aidan Thornton  wrote:

> On 9/19/10, Argent Stonecutter  wrote:
> > Perhaps Tateru was referring to the prim data changing (eg, geometry)
> while
> > the prim UUID stays the same. I don't think the viewer makes any
> assumptions
> > about prims being unchanged from session to session, so that's not
> something
> > that would need to be verified in the cache.
>
> Actually, I'm pretty sure it does, at least in viewer versions where
> caching hasn't accidentally been rendered totally ineffective by a Linden
> Labs
> typo. In fact, there's a fairly elaborate system for caching prim data
> to disk. As I recall, it detects changed prims using the CRC field,
> which is completely misnamed and is really a generation counter that
> records the number of changes to the prim. Then there's the CacheID,
> which invalidates the whole sim's cached data where necessary (e.g. if
> the sim moves or crashes, or perhaps even if it just restarts at all -
> would have to ask one of the Lab folks).
>
>
This is pretty accurate. I think the CacheID only changes if the format of
the cache changes, and so should be pretty rare. I'm not 100% sure on that
though.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request

[Kelly Linden]

There are multiple issues at play here:
What I understand is that the viewer is flogging our servers to brute force
build the data being requested.  Yes, you get the results, yes it can take a
bit of time for complex avatars or objects - and a lot more work is being
done than is necessary both by the viewer and the server. When we look at
implementing a feature request it is not in our best interest to just look
at the quickest, dirtiest way to get the job done. We want to implement a
feature that will work smoothly and be something we can support into the
future. Our access to and responsibility for the server side as well as the
viewer gives us both a better opportunity as well as increased
responsibility.

Just to be clear, the work done by other viewer teams is very good work and
they have done a great job with the tools they have. I only wish we could
have been quicker to expose better tools to them.

Secondly, while some of our teams may have a primary focus on either the
viewer or the server, other teams - such as the Land team - are built to
focus on products as a whole. Estate, region and parcel tools are features
we feel deserve to be looked at and evaluated as a product from end to end.
These features almost always benefit from both viewer and server
development. It is also beneficial to keep the backlogs of related
functionality together so we can better prioritize the features and bugs
that effect the Land product against each other.

So, *yes* it is quite possible to implement this check in the viewer alone,
and kudos to the team(s) that have done it. However, we feel obligated to do
a more thorough solution by fixing the server and viewer together, and to
prioritize this feature request against the many other feature requests for
the Land product.

 - Kelly

P.S. I am also not sure on the legal issues involved around the software
licenses here. As far as I'm aware we still require a contributors agreement
and it is not clear that the code added to the jira was actually written by
the person who attached it to jira, whether that person has a contributors
agreement or what license was attached to that code. At the very least I am
guessing it is extremely bad form to submit code you don't own and didn't
create into the jira.

On Mon, Sep 27, 2010 at 10:24 PM, Brandon Husbands  wrote:

> Just to iterate that it does work.
>
> [22:22]  Counting scripts. Please wait.
> [22:22]  Counted scripts on object SL Exchange Magic Box white: 5
>
> Works for any object.
> The code even allows you if you have permissions to remove all scripts
> which is a desperately needed function with all the poorly scripted re-sizer
> scripts in object.
>
>
> On Tue, Sep 28, 2010 at 12:18 AM, miss c  wrote:
>
>> It isn't a server feature, this works right now in all the OTHER viewers.
>> I attached like 10 files from the source code of all those viewers, the same
>> exact files in each viewer that does this NOW.  Did you even read my Jira??
>> I worked so hard to supply every bit of information.  Unless you have
>> allowed all these other viewers access to the server code, I think there has
>> been a mistake, could you please reread my Jira.
>>
>> TY
>>
>> Miss
>>
>> --
>> *From:* Brandon Husbands 
>> *To:* Sarah (Esbee) Hutchinson 
>> *Cc:* miss c ; opensource-dev@lists.secondlife.com
>> *Sent:* Tue, September 28, 2010 12:12:33 AM
>>
>> *Subject:* Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count
>> feature request
>>
>> Actually no its a viewer feature...
>>
>>
>> http://hg.phoenixviewer.com/phoenix-sg/file/cc7894faa410/indra/newview/scriptcounter.h
>> and
>>
>> http://hg.phoenixviewer.com/phoenix-sg/file/cc7894faa410/indra/newview/scriptcounter.cpp
>>
>> Just plugin and create a menu etc...
>>
>> If you want a non phoenix one re written for viewer 2.x i can easily do
>> that and comply with lgpl as it wont be a port but a re implementation.
>>
>> Dim.
>>
>>
>> On Mon, Sep 27, 2010 at 11:16 PM, Sarah (Esbee) Hutchinson <
>> es...@lindenlab.com> wrote:
>>
>>> Hi Miss C,
>>>
>>> The script count feature you requested is something that the Snowstorm
>>> Team wouldn't work on as its not really a Viewer feature - requiring mostly
>>> work on the server-side.
>>>
>>> I've moved the issue to our Land team so they can evaluate and prioritize
>>> the request. Unfortunately, the Land Team's tasks are not publicly visible
>>> in the new Jira set up. The ticket was moved intact with all the supporting
>>> data and will be given proper consideration.
>>>
>>> Best,
>>> Esbee
>>>
>>>
>>>
>>> This is really a request for a new script function to report # of scripts
>>> on an avatar; it's not a viewer feature (or even possible to do
>>> correctly/reliably with current grid protocols). Kicking to the Land team
>>> for evaluation/prioritization.
>>>
>>> On Mon, Sep 27, 2010 at 6:19 PM, miss c  wrote:
>>>
 Apparently it was moved, leaped the the land group, but I cant access
 where it went eit

Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request

[Kelly Linden]

So I was playing with the following LSL function in a sandbox yesterday and
I like it, but I'm gonna guess not everyone will.
integer llGetScriptMemoryTotal(key id) returns the total script memory used
by all scripts in the object or for agents the total script memory used by
all attachments combined. Only works for objects and avatars in the same
region.

Potential problems with it:
* Dyslexic naming weird it is.
* No permissions checks, anyone can view the sum for anyone / any object.
Since this is the case for the viewer feature it seems like adding any
restrictions will just leave people still wanting the viewer hack version.
* No detail information. I think this is best when used on anyone not
yourself for privacy reasons. And we do have the UI for finding
per-attachment details on yourself. So maybe not an issue.
* Reports 'reserved' script memory. A mono-script will report 64k while an
LSL script will report 16k, when really the mono script may be using less
(mono scripts average 8-10k last I checked, in actual usage). Being able to
report lower results for mono scripts is gated on other development work not
currently in progress.
* It doesn't seem like a very complete API.

On Wed, Sep 29, 2010 at 12:47 PM, miss c  wrote:

> Still need a script counter *hides*
>
> What I am probably going to do is get my husband to build me a personal
> version of 2.2 with mesh and the script counter.  That doesn't help everyone
> else though.
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request

[Kelly Linden]

* In the end the number of scripts shouldn't be important. I have lofty
desires to remove the arbitrary limit on script size so that we can stop the
silly games of splitting scripts apart because you need 10k more memory than
the default. On the other side being able to declare that your script really
only needs 4k would be hugely beneficial. At that point reporting the
reserved memory is more meaningful than the number of scripts.

* Script memory *is* very important, but it isn't counted in ms.

* Script ms is a wonky stat and I'm loath to perpetuate it. It only has a
rough correlation to actually harmful scripts. When scripts are behaving we
do a really great job of only giving each one a small slice of time, not
effecting the simulator, and giving everything a chance to run. When we run
into problems is when specific functions are called, which is something you
allude to. A great example is object rez. These function calls need to be
fixed on a case by case basis so that they aren't a problem. Object rez is a
great example here too - there are actually quite a few improvements in the
pipe to make it suck much less.

Script ms will show these horrible offenders because we do count that time
against the script. However the script ms time is really only good at
identifying outliers. It isn't good at demonstrating which of two well
behaving scripts is worse or better.

* In my mind the biggest issue is that mono scripts will appear 4x worse
than LSL scripts. This is really the reason I am hesitant to push a function
like this through before we have the ability for mono scripts to better
reflect how much memory they may use. We need more development time for any
solution on that front. Right now because a mono script could use 64k, that
is the only number we have available to count. Maybe it would be nice to
have an API to access number of scripts, number of LSL vs. Mono scripts,
amount of memory used and script time used. However we rapidly get away from
my desired philosophy of minimal interfaces.


 - Kelly


On Wed, Sep 29, 2010 at 2:51 PM, miss c  wrote:

> This again isn't that useful because you cant accurately guess how many
> scripts the person is wearing because of the memory difference.  Secondly
> the laggiest script with every lsl call in the world would still only
> register at 16k.  I think that what would make my body melt into a pool of
> happiness is a script usage per avatar, the calls coming from an avatar that
> put strain on the server because some LSL functions are more evil than
> others.  I don't know how complex something like this would be to do.  At
> least with the script counter I know accurately that Mr. Cybernetic has 1534
> scripts in his suit and each script takes up .02 ms of memory if there isnt
> strain on the sim.  Did you know there are some resizing scripts that have
> chat listeners, OMG, someone go shoot those designers.  :p
>
> But I want to thank you so much with everything in my soul that your
> attempting to find a solution to this problem, just for your attempt I
> completely adore you, please don't stop!
>
> :p
>
> Miss
>
> --
> *From:* Bryon Ruxton 
> *To:* Kelly Linden ; miss c 
> *Cc:* opensource-dev@lists.secondlife.com
> *Sent:* Wed, September 29, 2010 4:33:30 PM
>
> *Subject:* Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count
> feature request
>
> Sounds good to begin with! The caveats you mentioned are not really
> problems to be concerned too much about.
> I would just suggest llGetObjectMemory(key id) for the function name.
> Perhaps a list params with SCRIPT_COUNT and SCRIPT_MEMORY then SCRIPT_USAGE
> with the lower results for mono scripts later on...
>
> On 9/29/10 2:00 PM, "Kelly Linden"  wrote:
>
> So I was playing with the following LSL function in a sandbox yesterday and
> I like it, but I'm gonna guess not everyone will.
> integer llGetScriptMemoryTotal(key id) returns the total script memory used
> by all scripts in the object or for agents the total script memory used by
> all attachments combined. Only works for objects and avatars in the same
> region.
>
> Potential problems with it:
> * Dyslexic naming weird it is.
> * No permissions checks, anyone can view the sum for anyone / any object.
> Since this is the case for the viewer feature it seems like adding any
> restrictions will just leave people still wanting the viewer hack version.
> * No detail information. I think this is best when used on anyone not
> yourself for privacy reasons. And we do have the UI for finding
> per-attachment details on yourself. So maybe not an issue.
> * Reports 'reserved' script memory. A mono-script will report 64k while an
> LSL script will report 16k, when really the mono script may 

Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request

[Kelly Linden]

On Wed, Sep 29, 2010 at 4:47 PM, Brian McGroarty  wrote:

> On Wed, Sep 29, 2010 at 4:06 PM, Kelly Linden  wrote:
>
>>
>> * In my mind the biggest issue is that mono scripts will appear 4x worse
>> than LSL scripts. This is really the reason I am hesitant to push a function
>> like this through before we have the ability for mono scripts to better
>> reflect how much memory they may use. We need more development time for any
>> solution on that front. Right now because a mono script could use 64k, that
>> is the only number we have available to count. Maybe it would be nice to
>> have an API to access number of scripts, number of LSL vs. Mono scripts,
>> amount of memory used and script time used. However we rapidly get away from
>> my desired philosophy of minimal interfaces.
>
>
> The vast majority of scripts are tiny utility things, and are only compiled
> as mono because that became the default a year or so back. In reality, the
> typical script is probably using much less than 16k.
>
> What about using 16k for both LSL and Mono until real Mono values and
> controls can be added later? This is probably closer to real memory use than
> the sum of maximums would be.
>
> --
> Brian McGroarty | Linden Lab
> Sent from my Newton MP2100 via acoustic coupler
>

Straying away from reporting as "real" of numbers as we can is a slippery
slope I am a bit wary of, yet all options at this point stray from reality
in some manner.

* 64k for Mono doesn't reflect what the script is actually using or what its
peak was, but does report the highest potential usage.
* Current Used doesn't reflect that the script could use much more and you
may have just caught it in a lull.
* Max Used still doesn't reflect what it is currently using or what it could
potentially use.
* 16k seems practically random and unrelated to the script in question at
all.
* 10k means that in aggregate over hundreds or thousands of scripts it is
probably pretty accurate. However it doesn't tell you anything about the
particular script in question.

Now, if we allowed mono scripts to set their own memory cap then I think we
have the best compromise of currently used / max used / potential used. If
that is the best future, I think it probably makes the most sense to stick
with reporting the cap now, even if it isn't configurable yet and isn't the
most ideal number at this time. Then things will continue to "just work" as
we move forward.

 - Kelly
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request

[Kelly Linden]

On Sat, Oct 2, 2010 at 4:40 PM, Argent Stonecutter
wrote:

> On 2010-09-29, at 18:06, Kelly Linden wrote:
> > * In the end the number of scripts shouldn't be important. I have lofty
> desires to remove the arbitrary limit on script size so that we can stop the
> silly games of splitting scripts apart because you need 10k more memory than
> the default. On the other side being able to declare that your script really
> only needs 4k would be hugely beneficial. At that point reporting the
> reserved memory is more meaningful than the number of scripts.
>
> Could this be applied to LSL scripts as well, since they could be made
> potentially MUCH smaller? A kilobyte might be enough for a poseball, for
> example, and even less for a titler or particle script.
>
> Unfortunately no. LSL scripts take up 16k of memory no matter how much they
actually use.

 - Kelly
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request

[Kelly Linden]

On Mon, Oct 4, 2010 at 1:05 PM, Aidan Thornton  wrote:

> On Sun, Oct 3, 2010 at 2:47 AM, Kelly Linden  wrote:
> > Unfortunately no. LSL scripts take up 16k of memory no matter how much
> they
> > actually use.
>
> Is there any technical reason why this can't be made adjustable,
> though? I know that changing the amount of script memory available for
> LSL scripts would require a recompile, since it's fixed at compilation
> time, but I suspect it could be done.
>

LSL is crufty and hacky. It would be a serious engineering and QA effort to
implement such a feature. The language is pretty specific and hard coded to
16k. Even if we had a patch ready it would be a lot of QA to be sure it
worked as expected. Right now if we are doing anything of this level of work
we should be working on implementing a better language and not duct taping
LSL.

 - Kelly
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Missing capabilities.

[Kelly Linden]

I'm confused on this. While the term 'capability' is a bit vague, in SL
development / programming it is very specific. It is not a flag that
indicates the availability of a feature - it is an access point to access
features. It has the great side benefit of being able to indicate the
availability of those features by the presence of the capability. However
not all features are new capabilities.

What I'm getting at is that we shouldn't add dummy capabilities to indicate
the presence of a features that doesn't use a capability. It sounds like we
need some ability to indicate the availability of specific features - either
some feature map or versioning on specific capabilities. If we extended the
ability of an existing capability, perhaps we should have included a version
in some way when we did so. If the feature did not use capabilities (the
inventory is still a mix of legacy, event poll and capabilities isn't it?) -
then perhaps there is another way to determine if the feature is supported.

Or did I misunderstand the problem?

 - Kelly

On Tue, Oct 12, 2010 at 8:25 AM, Henri Beauchamp  wrote:

> Hello,
>
> There are, in my opinion, missing capabilities for the new viewer 2
> features, namely the capabilities dealing with inventory item links
> support, multiple attachments per point support, and multiple clothing
> layers support.
>
> Without the correpsonding capabilities, it is impossible for the viewer
> to adapt its sets of tools to the servers in OpenSim grids. Of course,
> I could just make the assumption that these features are only available
> in SL and then disable them for OpenSim, but I'm pretty sure they will
> appear in the latter, sooner or later...
>
> So, either LL implements the corresponding new capabilities in their
> server (and future viewer versions), or we would need OpenSim server
> developpers to "reserve" the capabilities (so that the viewer developpers
> may simply test for either the SL grids or the presence of the
> capabilities to decide whether the corresponding features should be
> enabled or not after login).
>
> It's also a bit worrying to see that LL doesn't seem to care much any
> more about backward compatibility (and therefore about OpenSim
> compatibility)...
>
> Any thought on this ?
>
> Henri.
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Broken Rubber Bands

[Kelly Linden]

If anyone is interested his code is here:
http://bitbucket.org/simon_linden/viewer-dev

cc'ing the opensource-dev list as this seems appropriate for that list at
this point.

 - Kelly

On Tue, Oct 12, 2010 at 8:27 AM, Kelly Linden  wrote:

> Actually one of my coworkers has been working on some features along these
> lines. The two parts I'm aware of prevent flying into the horizon if there
> is no neighbor sim and some attenuation of movement if it has been too long
> since getting an update from the sim. He was also working on some region
> crossing specific bits to try and improve the prediction logic and reduce
> rubber banding, however he was getting mixed results on that front.
>
> I've forwarded him your email just so he has another data point, and I'll
> see if I can't find his repo to share should anyone want to give his patches
> a try.
>
>  - Kelly
>
> On Tue, Oct 12, 2010 at 7:35 AM, annma...@slfbi.com wrote:
>
>>  Border crossing rubber-banding, especially when riding a vehicle, can
>> vary from zero to annoying to purgatory to re-boot depending on the
>> severity.
>> My current SLURL is sim Sunell, <60902, 26106???, -136289?> which
>> puts me at least 13 billion meters below ground on my way to SL hell.
>> It will require a re-log to recover.
>>
>> DUH.  The client side viewer would not have to be very smart to figure
>> out something was wrong and discontinue stretching a rubber band that is
>> obviously broken.
>>
>> Why cannot the viewer and server have a simple uplink command that says
>> "I'm totally lost, please put me back at the last known vector"?  It
>> could even have a popup to explain you have been restored to an earlier
>> valid location.
>>
>> ___
>> Click here to unsubscribe or manage your list subscription:
>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Broken Rubber Bands

[Kelly Linden]

It is true - the server could use improvements and they could both do with
working better together. And this is something we want to do, eventually.

However these specific changes are about addressing some of the worst
offenders - the blatently horrible cases where you fly off into the sunset
because the sim or network hiccups or maybe even prevent you from spiraling
into the ground when you drive across a border.

Lets avoid designing or re-designing full-on client side physics and
movement prediction here, for now. :)

 - Kelly

On Tue, Oct 12, 2010 at 4:46 PM, Nexii Malthus  wrote:

> Yeah, that is true. It should be able to detect the very source that causes
> most movements. There might be issues on scripts that influence an avatars
> movements via control events though, while that could be avoided by checking
> if control events have been taken, it might misidentify scripts that take
> controls but don't act on physics, such as AOs.
>
> I think the simulator could have a much better prediction system itself as
> well, it shouldn't all fall on the client.
>
> For example if an avatar presses forward, the simulator should "jump" the
> avatar forwards as if the avatar had pressed forwards back in time by their
> average ping time. This would make it appear as if the sim is more
> responsive. The client could also then simulate the forwards movement
> instantenously.
>
> Modern FPS games have even smarter methods for synchronizing and predicting
> physics accurately, such as tracking the recent positions of all players and
> then 'correcting' recent collisions based on the players' connections in
> realtime.
>
> - Nexii
>
>
> On Wed, Oct 13, 2010 at 12:29 AM, Dahlia Trimble 
> wrote:
>
>> Could checking to see if a user is still pressing a movement key fit into
>> the algorithm? It seems it could be a useful input to help determine if the
>> user really wants to continue along a dead-reckoning path.
>>
>>
>> On Tue, Oct 12, 2010 at 2:51 PM, Dale Innis wrote:
>>
>>> On Tue, Oct 12, 2010 at 5:38 PM, Simon Linden 
>>> wrote:
>>>
>>> > Some of my changes should help, however.  The viewer will check the
>>> edge of
>>> > the region, and if there is no neighbor region, stops the object
>>> motion.
>>>
>>> >  Predicted object motion is also pinned to the
>>> > allowable underground distance and top of the region.
>>>
>>> These will be major, and very welcome, changes to the SL experience!
>>>
>>> (Not to mention giving us oldbies one more class of "In my day..."
>>> stories to tell...)
>>> ___
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>>> Please read the policies before posting to keep unmoderated posting
>>> privileges
>>>
>>
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Again About Scripting Issues specifically KELLY LINDEN

[Kelly Linden]

Currently we use Mono 1.2.6.

Moving to Mono 2.6.7 is in testing right now. It requires a two stage
process to deploy so there will be a 'mono2 aware' version that has to be
deployed before we get all the new version stuff. We are currently working
on tracking down hopefully one of the last issues, a
"System.InvalidCastException" that we sometimes get when loading scripts.
Unfortunately it is a bit difficult to repro, and is a bit more subtle than
the name would make it seem relating to loading scripts.

I regularly give updates on this project and any other scripting work I am
aware of at my office hours:
http://wiki.secondlife.com/wiki/User:Kelly_Linden#Office_Hours . The only
other relevant list is probably secondlifescript...@lists.secondlife.com.

 - Kelly

On Sun, Oct 17, 2010 at 1:01 PM, Rob Nelson wrote:

>  There is no "we".  The servers are proprietary; LL does this on their own
> dime and time.  From what I gather, there's a little bit of work going
> towards that direction, but the mesh changes have their attention for now,
> like car keys dangled in front of a toddler.
>
> Rob
>
>
> On 10/17/2010 12:40 PM, miss c wrote:
>
>  Running more and more tests about the lag in regions it seems more and
> more to point towards this issue more than anything else.
>
> https://jira.secondlife.com/browse/SVC-3895 with over 900 votes
> "Rezzing Mono scripted object cripples sim 
> FPS"
>
> Now Kelly mentioned on this post it had something to do with the mono
> secuirty.dll.
>
> When I did a search for Security.dll and mono in google it pulled up
> mailing lists and posts where this is actually a mono bug coming from their
> software.  The portion I gather is it was fixed or improved in newer
> versions.  I looked all over the wiki but I could not find what version of
> mono we are using.  Does anyone know?
>
> I know this is more of a server function, but we have discussed at length
> for adding more tools to the viewer to monitor lag, but this would really
> make a huge difference if we just needed to update the mono version on the
> servers.
>
> If there is a server mailing list, please point me in that direction.
>
> Thanks
>
> Miss
> Fighting the lag every hour on the hour
>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] fix System.InvalidCastException (was again about scripting issues)

[Kelly Linden]

Thank you for looking into it Miss C. We are indeed aware of mono's
bugzilla, and even this specific bug report. Unfortunately, unlike the
reporter, there is no clear enumeration of a dictionary happening where we
see the crash. This is also a bug we saw well before the reporter saw it -
while he reports a build on June 24th as introducing the bug for him, ours
appears to be a re-occurrence of a bug we saw when we first attempted to
address the mono stall bug back with SL Server 1.38 at the beginning of the
year.

Our error probably is at least tangentially related - a Dictionary or other
container is the most likely source of the bug. Hopefully we can track it
down this week. :)

 - kelly

On Sun, Oct 17, 2010 at 5:52 PM, Carlo Wood  wrote:

> Wow, very good miss!
>
> I think that last url is one that Linden Lab should study
> very closely. I too think that this will the solution
> for their problem.
>
> On Sun, Oct 17, 2010 at 02:43:29PM -0700, miss c wrote:
> >
> https://bugzilla.novell.com/buglist.cgi?quicksearch=System.InvalidCastException
> >
> > .The bug is listed 5 times...
> >
> >
> >  on one of these someone fixed the issue
> > https://bugzilla.novell.com/show_bug.cgi?id=619929
>
> --
> Carlo Wood 
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Again About Scripting Issues specifically KELLY LINDEN

[Kelly Linden]

There are lots of ways to get an InvalidCastException, many of them quite
valid. http://stackoverflow.com has a fair number of questions on the topic,
and here is a good summary of what that error actually means:
http://dotnetperls.com/invalidcastexception . Apparently there is also some
more fun to be had if you are dealing with multiple domains -
http://blogs.msdn.com/b/suzcook/archive/2004/06/02/debugging-an-invalidcastexception.aspx.
We actually do move scripts across domains as a way to manage garbage
collection on scripts, and that is something that has "been touched" during
this project. I'm leaning towards this being closer to the issue, but I'm
certainly open to other possibilities.

 - Kelly

On Sun, Oct 17, 2010 at 2:00 PM, miss c  wrote:

> That bug is listed here with 2.6.7
>
> https://bugzilla.novell.com/show_bug.cgi?id=581679
>
> Quote "I have tested this in Mono 2.6.7 and it is still occurring. it
> occurs when a second input field in added to a form (via the forms "+"
> button and happens at save."
>
> In version 2.8 it looks like they redid how mono works so it doesn't look
> like this is a bug that's going to be fixed.
>
> http://www.mono-project.com/Release_Notes_Mono_2.6.7
> http://www.mono-project.com/Release_Notes_Mono_2.8
>
> If this isn't fixable you may have to go to 2.8, but with as much as it
> looks like they changes, wow, a whole lot of work.  But thank you for
> answering, can't wait to see it deployed.
>
> Miss
>
>
>
> --
> *From:* Kelly Linden 
> *To:* Rob Nelson 
> *Cc:* opensource-dev@lists.secondlife.com
> *Sent:* Sun, October 17, 2010 3:17:40 PM
>
> *Subject:* Re: [opensource-dev] Again About Scripting Issues specifically
> KELLY LINDEN
>
> Currently we use Mono 1.2.6.
>
> Moving to Mono 2.6.7 is in testing right now. It requires a two stage
> process to deploy so there will be a 'mono2 aware' version that has to be
> deployed before we get all the new version stuff. We are currently working
> on tracking down hopefully one of the last issues, a
> "System.InvalidCastException" that we sometimes get when loading scripts.
> Unfortunately it is a bit difficult to repro, and is a bit more subtle than
> the name would make it seem relating to loading scripts.
>
> I regularly give updates on this project and any other scripting work I am
> aware of at my office hours:
> http://wiki.secondlife.com/wiki/User:Kelly_Linden#Office_Hours . The only
> other relevant list is probably secondlifescript...@lists.secondlife.com.
>
>  - Kelly
>
> On Sun, Oct 17, 2010 at 1:01 PM, Rob Nelson 
> wrote:
>
>>  There is no "we".  The servers are proprietary; LL does this on their own
>> dime and time.  From what I gather, there's a little bit of work going
>> towards that direction, but the mesh changes have their attention for now,
>> like car keys dangled in front of a toddler.
>>
>> Rob
>>
>>
>> On 10/17/2010 12:40 PM, miss c wrote:
>>
>>  Running more and more tests about the lag in regions it seems more and
>> more to point towards this issue more than anything else.
>>
>> https://jira.secondlife.com/browse/SVC-3895 with over 900 votes
>> "Rezzing Mono scripted object cripples sim 
>> FPS"<https://jira.secondlife.com/browse/SVC-3895>
>>
>> Now Kelly mentioned on this post it had something to do with the mono
>> secuirty.dll.
>>
>> When I did a search for Security.dll and mono in google it pulled up
>> mailing lists and posts where this is actually a mono bug coming from their
>> software.  The portion I gather is it was fixed or improved in newer
>> versions.  I looked all over the wiki but I could not find what version of
>> mono we are using.  Does anyone know?
>>
>> I know this is more of a server function, but we have discussed at length
>> for adding more tools to the viewer to monitor lag, but this would really
>> make a huge difference if we just needed to update the mono version on the
>> servers.
>>
>> If there is a server mailing list, please point me in that direction.
>>
>> Thanks
>>
>> Miss
>> Fighting the lag every hour on the hour
>>
>>
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting 
>> privileges
>>
>>
>>
>> ___
>> Policies and (un)subscribe information available h

Re: [opensource-dev] Stuff I'd like to see in the coming sprint

[Kelly Linden]

On Tue, Oct 19, 2010 at 5:07 PM, Dave Booth  wrote:

> On 10/19/2010 13:58, malachi wrote:
> > I would also like to see (since there are so many new changes to the
> > server.)
> >
> > issues like
> >
> > VWR-11683
> >
> >
> > or any other new scripting functions that will reduce lag and speed up
> > efficiency for developers. i dont think focusing only on functions and
> > features that are going to ADD to lag should be going on here. i think as
> > a community we should be working on ways to reduce the lag as well.
> >
> > any chance that someone will drop the few lines of code into the new
> > server version and spit out the keys to scripts or do we all have to keep
> > using tpv clients and 65535^3 prims to scan regions?
>
> I love that idea but since its a scripting enhancement then apart from
> the script editor floaters syntax highlighting thats purely a
> server-side change. It's not something the snowstorm team or any of us
> can work on since its not in the opensource code. Sad to say that jira
> is likely going to end up closed as misfiled, because if its a scripting
> thing it aint a VWR project issue. You can count on my voice adding to
> you advocating for it as a server enhancement, but in its current jira
> location its likely gonna sink without trace.
>
>
I've moved it to SVC, no need for it to be closed or to sink without a
trace. But yes, it is a service and not a viewer issue. I have even
commented on it already.

 - Kelly
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges