Re: [opensource-dev] Snowstorm changes

[Opensource Obscure]

I'm very sad about this news, that also affects my confidence in the
Snowstorm project itself. 
As Zai put it,
> Aimee & Tofu: Despite my better judgement, I still hoped you'd survive the
> impending UK lay-offs somehow. Sad to see you go.
> I'll gladly jump in in the collective praise: You did a great job.

THANKS

Opensource Obscure
___
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

[Opensource Obscure]

On Mon, 27 Sep 2010 22:55:57 -0700, Kelly Linden 
wrote:
> 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

And doesn't this violate the TPV policy, 1.a ?

Opensource Obscure
___
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

[Obsidian Kindragon]

  On 9/29/2010 7:34 AM, Opensource Obscure wrote:
> On Mon, 27 Sep 2010 22:55:57 -0700, Kelly Linden
> wrote:
>> 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
> And doesn't this violate the TPV policy, 1.a ?
>
> Opensource Obscure
>
I think because it's not an intentional "attack" on LL's servers they're 
willing to let it slide for the time being until a better method on the 
server side can be developed.

Personally, I think something better than script "count" should be used 
to determine whether you let an avatar wear it. Script "time" (total for 
an av is available to Estate Managers), script "memory" (parsed per 
attachment is available to individuals), and certain functions (certain 
functions may put a larger strain on the region than others) are all 
more important to know about than simply how many scripts are in the 
attachments, in my opinion.

- Obsidian Stormwind
___
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

[Ambrosia]

On Wed, Sep 29, 2010 at 15:51, Obsidian Kindragon  wrote:
>  On 9/29/2010 7:34 AM, Opensource Obscure wrote:
>> On Mon, 27 Sep 2010 22:55:57 -0700, Kelly Linden
>> wrote:
>>> 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
>> And doesn't this violate the TPV policy, 1.a ?
>>
>> Opensource Obscure
>>
> I think because it's not an intentional "attack" on LL's servers they're
> willing to let it slide for the time being until a better method on the
> server side can be developed.

Hi guys. I wrote the script counter for Emerald (And now derivatives
andwhoever else is using it).

Basically what the code does is request the inventory of every prim of
the selected object(s). However, 'brute forcing' probably sounds a
little wrong here, as the requests the code does already -are- indeed
throtteled.

If you send uncapped floods of requests to the sim, the sim just stops
responding to those requests as an internal protection that is already
in place to prevent this. So, no need to worry that this is somehow
overloading it.

And yeah, requesting the inventory of all the prims was the only way
to implement it, alas. A sim-side, faster method would be muchas
awesome.

--Chalice Yao
___
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

[Gigs]

On 09/29/2010 10:17 AM, Ambrosia wrote:
> Basically what the code does is request the inventory of every prim of
> the selected object(s). However, 'brute forcing' probably sounds a
> little wrong here, as the requests the code does already -are- indeed
> throtteled.

I can confirm this.  I've written very similar code in the past for my 
own use, and it really doesn't impact the sim very much at all.  The 
sims seem very good about not letting those kind of requests overload them.
___
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

[Kadah]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sadly what sim and land owners really need most right now is support.
Anyone that's contacted live support, concierge, or filed a ticket in
the last few months knows what I'm taking about.

Getting support back on track should be priority.

v.v


On 9/28/2010 1:57 AM, Yoz Grahame wrote:
> In which case, we should consider that before we rush to an
> implementation which may end up worsening the problem that land owners
> need fixed.
> 
> It's in everyone's interest to provide something like this. Reducing lag
> is a key part of the "Fast, Easy, Fun" initiative. Giving land owners
> better tools to deal with sim load is a great way to divide-and-conquer
> on the many causes of lag, not to mention making our highest-paying
> customers happier. But if it's worth doing then it's worth doing right,
> and the Land team needs time to design and prioritise it properly.
> 
> -- Yoz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMo4FiAAoJEIdLfPRu7qE2V0YH+wQsQ3kSsB8qFXLDTZcNuBjB
3UZGr0LREG9PbwMiGSDTcxZ3XTORz1Kjv7OowphRfgwv+Djh0I1mj2FZyIVL6Itt
c+yg/D1RQjmWygsbDS6j2e7LwIInCNforoqKtWlTzOg9azA04EMwaMO5zDLl2oae
Uu0wWuBkwIovSsKfphrgGEAIUFhaR/VH+5QA1f5l6pMCwGryUB5CGA9Oz1cNmSoV
AXHd+9DkUkJt/E9I11XO9us6xFTZNWexNtEKF+OK0wxQ0XfUphrmCPY50zN/isNI
aBh2g11nf4ZqWHvKKErrsje2SqLDdSxPwyDD6zDkMoGTIvmlXsvsHR5FBBP0uhE=
=gUJb
-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

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

[Ponzu]

On Wed, Sep 29, 2010 at 2:11 PM, Kadah  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Sadly what sim and land owners really need most right now is support.
> Anyone that's contacted live support, concierge, or filed a ticket in
> the last few months knows what I'm taking about.
>
> Getting support back on track should be priority.
>
> Every time I have ever called support, they have been very helpful, and my
issue has been resolved quickly.

Ponzu
___
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

[miss c]

Support has been fantastic for me, its the live chat that is a problem.  I have 
changed my methods of using live chat to filing an actual ticket and I get a 
response almost immediately.

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.





From: Kadah 
To: opensource-dev@lists.secondlife.com
Sent: Wed, September 29, 2010 1:11:46 PM
Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature 
request

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sadly what sim and land owners really need most right now is support.
Anyone that's contacted live support, concierge, or filed a ticket in
the last few months knows what I'm taking about.

Getting support back on track should be priority.

v.v


On 9/28/2010 1:57 AM, Yoz Grahame wrote:
> In which case, we should consider that before we rush to an
> implementation which may end up worsening the problem that land owners
> need fixed.
> 
> It's in everyone's interest to provide something like this. Reducing lag
> is a key part of the "Fast, Easy, Fun" initiative. Giving land owners
> better tools to deal with sim load is a great way to divide-and-conquer
> on the many causes of lag, not to mention making our highest-paying
> customers happier. But if it's worth doing then it's worth doing right,
> and the Land team needs time to design and prioritise it properly.
> 
> -- Yoz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMo4FiAAoJEIdLfPRu7qE2V0YH+wQsQ3kSsB8qFXLDTZcNuBjB
3UZGr0LREG9PbwMiGSDTcxZ3XTORz1Kjv7OowphRfgwv+Djh0I1mj2FZyIVL6Itt
c+yg/D1RQjmWygsbDS6j2e7LwIInCNforoqKtWlTzOg9azA04EMwaMO5zDLl2oae
Uu0wWuBkwIovSsKfphrgGEAIUFhaR/VH+5QA1f5l6pMCwGryUB5CGA9Oz1cNmSoV
AXHd+9DkUkJt/E9I11XO9us6xFTZNWexNtEKF+OK0wxQ0XfUphrmCPY50zN/isNI
aBh2g11nf4ZqWHvKKErrsje2SqLDdSxPwyDD6zDkMoGTIvmlXsvsHR5FBBP0uhE=
=gUJb
-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] 2.0 Absolute Dealbreaker - script count feature request

[aklo]

Me too!  Every time i've dealt with support they've been terrific!  i
haven't always gotten what i wanted, but support's been real good about
what i needed - and really good about helping me understand why what i
didn't get was because it was unreasonable.

But it's been at least 3 months since i had anything to do with support,
and weren't they all in the UK?  Could the quality of support have changed
with the "restructuring?"

- AK

On Wed, Sep 29, 2010 at 2:11 PM, Kadah  wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sadly what sim and land owners really need most right now is support.
Anyone that's contacted live support, concierge, or filed a ticket in
the last few months knows what I'm taking about.

Getting support back on track should be priority.

Every time I have ever called support, they have been very helpful, and my
issue has been resolved quickly.

Ponzu



___
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] 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

[Bryon Ruxton]

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

___
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

[Zi Ree]

Am Mittwoch 29 September 2010 23:33:30 schrieb Bryon Ruxton:

> Sounds good to begin with! The caveats you mentioned are not really
>  problems to be concerned too much about.

As long as it doesn't return the true memory usage, people will start banning 
mono scripted objects, because they don't know better and won't listen to 
explanations.

Zi
___
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

[miss c]

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

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



  ___
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

[Bryon Ruxton]

It is useful enough to me. You can¹t have it all now (Kelly explained why)
and while it¹s not ideal,
it¹s valuable information as far as I am concerned to identify problems,
should they arise.

And Zee I don¹t care about what stupid people do on their land... It the
least of my worries
Whether is it true memory usage or not, people can ban. It¹s a fact.
The legitimacy in doing so is another question... And stupid people will
remain stupid...

Ask yourselves the question:
Do you want an incomplete yet helpful solution doable now, to be
improved/completed later on,
or do you prefer to wait another 6-12+ month with nothing at all?


On 9/29/10 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
> 
> 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 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
> 
>  
> 
> ___
> 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] 2.0 Absolute Dealbreaker - script count feature request

[Zi Ree]

> Do you want an incomplete yet helpful solution doable now, to be
> improved/completed later on,
> or do you prefer to wait another 6-12+ month with nothing at all?

Since improvised and incomplete solutions tend to become the final one after a 
while, and since I have no issues with script memory whatsoever, I rather wait 
for a fully functional, complete implementation than seeing a temporary and 
useless "solution" in place.

Zi
___
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

[WolfPup Lowenhar]

This sounds good. Another function could be:

. list llGetScriptTotal(key_id)

Where it would return the following list of items:

·Total number of scrpts

·Total script memory used

·Total script time

·Number of mono scripts

·Number of non-mono scripts

 

That information would be more use full to both content creators and land/sim 
owners.

 

From: opensource-dev-boun...@lists.secondlife.com 
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Kelly Linden
Sent: Wednesday, September 29, 2010 5:01 PM
To: miss c
Cc: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature 
request

 

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.

 

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.856 / Virus Database: 271.1.1/3166 - Release Date: 09/29/10 
01:37:00

___
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

[miss c]

This is a tough one because it does leave a lot of guess work, but still could 
be added to my list of tools I use to guess with.  I will totally take it if 
it's being offered, I just pray this inst the foundation the future tools will 
be built off of.  And about the whole banning, my regions private, just open to 
the public, if I want to ban anyone coming in my sim wearing pink, I can.  I 
hope thats not why tools are being kept from us, is because the Linden's are 
afraid we will make unintelligent bans.  I pay a lot of money out I should be 
able to do what I want with it within the ToS, I should be given the tools to 
at 
least keep random newbs from secretly crashing my sim.  






From: Zi Ree 
To: opensource-dev@lists.secondlife.com
Sent: Wed, September 29, 2010 5:28:07 PM
Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature 
request

> Do you want an incomplete yet helpful solution doable now, to be
> improved/completed later on,
> or do you prefer to wait another 6-12+ month with nothing at all?

Since improvised and incomplete solutions tend to become the final one after a 
while, and since I have no issues with script memory whatsoever, I rather wait 
for a fully functional, complete implementation than seeing a temporary and 
useless "solution" in place.

Zi
___
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] 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 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

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

[miss c]

Let me reword that last part.  I should be able to locate a person using 
excessive amounts of resources on my sim.  I also should be able to stop random 
people on alts setting out to grief secretly with the overuse of scripts.





From: miss c 
To: Zi Ree ; opensource-dev@lists.secondlife.com
Sent: Wed, September 29, 2010 5:45:25 PM
Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature 
request


This is a tough one because it does leave a lot of guess work, but still could 
be added to my list of tools I use to guess with.  I will totally take it if 
it's being offered, I just pray this inst the foundation the future tools will 
be built off of.  And about the whole banning, my regions private, just open to 
the public, if I want to ban anyone coming in my sim wearing pink, I can.  I 
hope thats not why tools are being kept from us, is because the Linden's are 
afraid we will make unintelligent bans.  I pay a lot of money out I should be 
able to do what I want with it within the ToS, I should be given the tools to 
at 
least keep random newbs from secretly crashing my sim.  






From: Zi Ree 
To: opensource-dev@lists.secondlife.com
Sent: Wed, September 29, 2010 5:28:07 PM
Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature 
request

> Do you want an incomplete yet helpful solution doable now, to be
> improved/completed later on,
> or do you prefer to wait another 6-12+ month with nothing at all?

Since improvised and incomplete solutions tend to become the final one after a 
while, and since I have no issues with script memory whatsoever, I rather wait 
for a fully functional, complete implementation than seeing a temporary and 
useless "solution" in place.

Zi
___
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] 2.0 Absolute Dealbreaker - script count feature request

[Joshua Bell]

Taking a stab at a user story:

As a land owner, I want to ensure that sim performance is not negatively
impacted by particular avatars with lots of scripts, so that all users of
the sim have a good experience.

That abstracts away the mechanism... which suggests to me that approaches
like dynamic per-avatar caps on script cycles might be a better approach to
pursue than specific functions that enable monitoring. But I'm probably
over-abstracting the desire and it would encode the policy in the sim,
rather than letting land owners self-manage. Can we craft a better user
story to capture the true need?

On Wed, Sep 29, 2010 at 4:09 PM, miss c  wrote:

> Let me reword that last part.  I should be able to locate a person using
> excessive amounts of resources on my sim.  I also should be able to stop
> random people on alts setting out to grief secretly with the overuse of
> scripts.
>
> --
> *From:* miss c 
> *To:* Zi Ree ; opensource-dev@lists.secondlife.com
> *Sent:* Wed, September 29, 2010 5:45:25 PM
>
> *Subject:* Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count
> feature request
>
> This is a tough one because it does leave a lot of guess work, but still
> could be added to my list of tools I use to guess with.  I will totally take
> it if it's being offered, I just pray this inst the foundation the future
> tools will be built off of.  And about the whole banning, my regions
> private, just open to the public, if I want to ban anyone coming in my sim
> wearing pink, I can.  I hope thats not why tools are being kept from us, is
> because the Linden's are afraid we will make unintelligent bans.  I pay a
> lot of money out I should be able to do what I want with it within the ToS,
> I should be given the tools to at least keep random newbs from secretly
> crashing my sim.
>
> --
> *From:* Zi Ree 
> *To:* opensource-dev@lists.secondlife.com
> *Sent:* Wed, September 29, 2010 5:28:07 PM
> *Subject:* Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count
> feature request
>
> > Do you want an incomplete yet helpful solution doable now, to be
> > improved/completed later on,
> > or do you prefer to wait another 6-12+ month with nothing at all?
>
> Since improvised and incomplete solutions tend to become the final one
> after a
> while, and since I have no issues with script memory whatsoever, I rather
> wait
> for a fully functional, complete implementation than seeing a temporary and
>
> useless "solution" in place.
>
> Zi
> ___
> 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] 2.0 Absolute Dealbreaker - script count feature request

[Brian McGroarty]

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
___
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 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

[miss c]

We all know about the amount of lag on avatars, some are from resizing scripts 
some are from excessive calls, sensors, some are from chat listeners that have 
to filter out ever single bit of chat in a region.  Most avatars do not even 
realize they have purchased something causing issues.  


I think "scanning" an avatar before it goes to a teleport destination to see if 
that amount of script usage is allowed on that region isn't fixing a problem, 
and leaves someone that doesnt know any better at a loss.  I also believe that 
limiting the amount of scripts in one object is a little more doable, but some 
functions are at idle in scripts.  


I think the best method that goes with Linden Labs philosophy of be and do what 
you want to do, would just be to give better monitoring tools to Estate owners, 
they pay those server bills they should have some better tools.  Whether its a 
script count, usage, calls to the server, or just be able to open up a server 
window to see what is going WITH a must have uuid and location its coming from. 
 
I would be happy with a debug server window that does this.  This isn't an 
unreasonable request to give me more tools, I am not hard to please, what is 
unreasonable is that I pay out the wazoo and anyone can come crash my region if 
they wanted to.  They can lag it up galore just for giggles and I cant do 
anything about it, they can do this daily , everyday several times a day, and I 
have to be the victim of it.  


As I said before, most don't even know they are doing this because it's in an 
item they purchased, so this is where the ***SCRIPT COUNTER*** comes in handy.  
We make the announcement for everyone to script count yourself and your 
neighbors , everyone does using the forks off of Emerald, and the region gets 
better.  It isn't the solution for everything, but it helps when excessive 
scripts is the cause.  I am not going to give you a full on user story because 
I 
feel like that gives you reason to place this in a faraway request.  This works 
now in other viewers, it can work in yours too :-)  







From: Joshua Bell 
To: miss c 
Cc: opensource-dev@lists.secondlife.com
Sent: Wed, September 29, 2010 6:45:50 PM
Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature 
request

Taking a stab at a user story:

As a land owner, I want to ensure that sim performance is not negatively 
impacted by particular avatars with lots of scripts, so that all users of the 
sim have a good experience.

That abstracts away the mechanism... which suggests to me that approaches like 
dynamic per-avatar caps on script cycles might be a better approach to pursue 
than specific functions that enable monitoring. But I'm probably 
over-abstracting the desire and it would encode the policy in the sim, rather 
than letting land owners self-manage. Can we craft a better user story to 
capture the true need?


On Wed, Sep 29, 2010 at 4:09 PM, miss c  wrote:

Let me reword that last part.  I should be able to locate a person using 
excessive amounts of resources on my sim.  I also should be able to stop random 
people on alts setting out to grief secretly with the overuse of scripts.
>
>
>
>

From: miss c 
>To: Zi Ree ; opensource-dev@lists.secondlife.com
>Sent: Wed, September 29, 2010 5:45:25 PM
>
>Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature 
>request
>
>
>
>This is a tough one because it does leave a lot of guess work, but still could 
>be added to my list of tools I use to guess with.  I will totally take it if 
>it's being offered, I just pray this inst the foundation the future tools will 
>be built off of.  And about the whole banning, my regions private, just open 
>to 
>the public, if I want to ban anyone coming in my sim wearing pink, I can.  I 
>hope thats not why tools are being kept from us, is because the Linden's are 
>afraid we will make unintelligent bans.  I pay a lot of money out I should be 
>able to do what I want with it within the ToS, I should be given the tools to 
>at 
>least keep random newbs from secretly crashing my sim.  
>
>
>
>
>

From: Zi Ree 
>To: opensource-dev@lists.secondlife.com
>Sent: Wed, September 29, 2010 5:28:07 PM
>Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature 
>request
>
>> Do you want an incomplete yet helpful solution doable now, to be
>> improved/completed later on,
>> or do you prefer to wait another 6-12+ month with nothing at all?
>
>Since improvised and incomplete solutions tend to become the final one after a 
>while, and since I have no issues with script memory whatsoever, I rather wait 
>for a fully functional, complete implementation than seeing a temporary and 
>useless "solution" in place.
>
>Zi
>___
>Policies and (un)subscribe information available here:
>http://wiki.secondlife.com/wiki/OpenSource-

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

[Bryon Ruxton]

That was in part my justification behind the need of script counts in the
function, to assess numbers of scripts vs memory count in a slightly more
meaningful manner, for lack of true memory usage.

e.g. 4 scripts with 64k memory usage can be evaluated as 64k accurately,
while a 64k memory without a number of scripts attached, give you indeed
nothing to assess.

i.e. The number of LSL vs. Mono scripts can be easily figured out with quite
simple math
if we have the script count under the initial conditions of 16k and 64k
caps.

As you pointed out, true memory usage isn¹t a given... Memory fluctuates
over time or conditions and even snapshots of it would not reflect true
usage... As you suggest, if you allowed mono scripts to set their own memory
cap, I guess you could report the memory cap based on that, perhaps rounded
to chunks/multiples of 4k...

So I¹ll stick to list llGetObjectMemory( key id, list params ) with
SCRIPT_COUNT and SCRIPT_MEMORY flags as the most viable initial solution I¹d
be happy with. Then once you add mono memory caps, either add a flag or
change what is reported as SCRIPT_MEMORY...
OR possibly add those flags in LlGetObjectDetails?? But I don¹t know the
technicals there..

Anyway that was my suggestion of the day,
Back to RL work!


On 9/29/10 4:06 PM, "Kelly Linden"  wrote:

> * In my mind the biggest issue is that mono scripts will appear 4x worse than
> LSL scripts.

___
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

[miss c]

That sounds awesome, I just don't want to ask for too much and not get anything 
at all cause its put on the shelf.  I need a solution or replacement to my 
Estate tools that I lose by moving to the official viewer, or I can't possibly 
move.  As I said , my priorities and responsibilities as an estate owner come 
first.





From: Bryon Ruxton 
To: Kelly Linden ; miss c 
Cc: opensource-dev@lists.secondlife.com
Sent: Wed, September 29, 2010 7:37:44 PM
Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature 
request

Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request 
That was in part my justification behind the need of script counts in the 
function, to assess numbers of scripts vs memory count in a slightly more 
meaningful manner, for lack of true memory usage.

e.g. 4 scripts with 64k memory usage can be evaluated as 64k accurately,
while a 64k memory without a number of scripts attached, give you indeed 
nothing 
to assess.

i.e. The number of LSL vs. Mono scripts can be easily figured out with quite 
simple math
if we have the script count under the initial conditions of 16k and 64k caps.

As you pointed out, true memory usage isn’t a given... Memory fluctuates over 
time or conditions and even snapshots of it would not reflect true usage... As 
you suggest, if you allowed mono scripts to set their own memory cap, I guess 
you could report the memory cap based on that, perhaps rounded to 
chunks/multiples of 4k...

So I’ll stick to list llGetObjectMemory( key id, list params ) with 
SCRIPT_COUNT 
and SCRIPT_MEMORY flags as the most viable initial solution I’d be happy with. 
Then once you add mono memory caps, either add a flag or change what is 
reported 
as SCRIPT_MEMORY...
OR possibly add those flags in LlGetObjectDetails?? But I don’t know the 
technicals there..

Anyway that was my suggestion of the day,
Back to RL work!


On 9/29/10 4:06 PM, "Kelly Linden"  wrote:


* In my mind the biggest issue is that mono scripts will appear 4x worse than 
LSL scripts.
>


  ___
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

[Brian McGroarty]

On Wed, Sep 29, 2010 at 4:59 PM, Kelly Linden  wrote:

> 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.
>>
>
> 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.
>

Using a value other than 16k before configurable limits are in place will
create pressure to adopt or abandon Mono, depending on the value chosen.
It's not random - it's the only value that defers encouraging change until
it can be done with meaningful data. Whether that's the right goal, I don't
know.

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

[opensource-dev] Shadow Controls

[Reed Steamroller]

Basically, I got this idea from all of the controls you've got over shadows
in Maya ( a program I'm partial to ).

In particular, I'm thinking the ability to designate which objects both cast
and recieve shadows should be included in the viewer.

As well, it would be nice to specify a color for shadows cast on a per
object basis.

All of this I think could fit in the features tab in the edit window.  A
color swatch for the shadow color and some check boxes for "Cast Shadow" and
"Receive Shadow".

Maybe even a slider for shadow-edge-fuzziness?

What do you all think?

I posted a short JIRA on this subject, if you'ed like to check it out and
vote.

https://jira.secondlife.com/browse/VWR-23238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=214068

-- 
William Reed Seal Foss (Reed Steamroller)
Chief Creative Officer
Sand Castle Studios LLC | Second Life

http://www.ChangingWorldsBuildingDreams.com
r...@changingworldsbuildingdreams.com
http://www.Twitter.com/ReedSteamroller
___
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

[Jamey Fletcher]

Zi Ree wrote:

>> Do you want an incomplete yet helpful solution doable now, to be
>> improved/completed later on,
>> or do you prefer to wait another 6-12+ month with nothing at all?

> Since improvised and incomplete solutions tend to become the final one after a
> while, and since I have no issues with script memory whatsoever, I rather wait
> for a fully functional, complete implementation than seeing a temporary and
> useless "solution" in place.

I gotta agree here.  Sculpties were a quick hack, and we were supposed 
to get support for in-world editing, but they wanted to get it on out 
there so people could get started using it - and guess what - 3 years 
later, no in-world sculptie editing support yet.  Just a bunch of 
hacked-together prim tools.

Windlight was supposed to be this awesome way to be able to share 
wonderful and amazing environmental settings, allowing the creation of 
regions with alien atmospheres and odd psychological effects.  Oh, well, 
let's hope the Lindens decide to adopt the Lightshare system already 
implemented by the OpenSIM people.
___
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

[Obsidian Kindragon]

 The problem with using script count, is that one script can be as 
laggy as 10 or even 100 scripts. It may be more likely that 100 scripts 
in an object is laggier, but one script could potentially be as laggy or 
more so.


I think this would be my user story:

As a user and a region owner / estate manager I would like the ability 
throttle residents' scripted attachments and unattached scripted objects 
when they are within my region. Currently we only have the ability to 
turn off scripts, but throttle scripted objects so as to limit the 
amount of "time" a scripted object can act within a given cycle.


One potential issue I see to being allowed to set a script limit to 
unattached objects is that some designers may then try to build multiple 
objects that communicate together in order to try and work around the 
region's set script limits.


- Obsidian Stormwind

On 9/29/2010 6:27 PM, miss c wrote:
We all know about the amount of lag on avatars, some are from resizing 
scripts some are from excessive calls, sensors, some are from chat 
listeners that have to filter out ever single bit of chat in a 
region.  Most avatars do not even realize they have purchased 
something causing issues.


I think "scanning" an avatar before it goes to a teleport destination 
to see if that amount of script usage is allowed on that region isn't 
fixing a problem, and leaves someone that doesnt know any better at a 
loss.  I also believe that limiting the amount of scripts in one 
object is a little more doable, but some functions are at idle in 
scripts.


I think the best method that goes with Linden Labs philosophy of be 
and do what you want to do, would just be to give better monitoring 
tools to Estate owners, they pay those server bills they should have 
some better tools.  Whether its a script count, usage, calls to the 
server, or just be able to open up a server window to see what is 
going WITH a must have uuid and location its coming from.  I would be 
happy with a debug server window that does this.  This isn't an 
unreasonable request to give me more tools, I am not hard to please, 
what is unreasonable is that I pay out the wazoo and anyone can come 
crash my region if they wanted to.  They can lag it up galore just for 
giggles and I cant do anything about it, they can do this daily , 
everyday several times a day, and I have to be the victim of it.


As I said before, most don't even know they are doing this because 
it's in an item they purchased, so this is where the ***SCRIPT 
COUNTER*** comes in handy.  We make the announcement for everyone to 
script count yourself and your neighbors , everyone does using the 
forks off of Emerald, and the region gets better.  It isn't the 
solution for everything, but it helps when excessive scripts is the 
cause.  I am not going to give you a full on user story because I feel 
like that gives you reason to place this in a faraway request.  This 
works now in other viewers, it can work in yours too :-)




*From:* Joshua Bell 
*To:* miss c 
*Cc:* opensource-dev@lists.secondlife.com
*Sent:* Wed, September 29, 2010 6:45:50 PM
*Subject:* Re: [opensource-dev] 2.0 Absolute Dealbreaker - script 
count feature request


Taking a stab at a user story:

As a land owner, I want to ensure that sim performance is not 
negatively impacted by particular avatars with lots of scripts, so 
that all users of the sim have a good experience.


That abstracts away the mechanism... which suggests to me that 
approaches like dynamic per-avatar caps on script cycles might be a 
better approach to pursue than specific functions that enable 
monitoring. But I'm probably over-abstracting the desire and it would 
encode the policy in the sim, rather than letting land owners 
self-manage. Can we craft a better user story to capture the true need?


On Wed, Sep 29, 2010 at 4:09 PM, miss c > wrote:


Let me reword that last part.  I should be able to locate a person
using excessive amounts of resources on my sim.  I also should be
able to stop random people on alts setting out to grief secretly
with the overuse of scripts.


*From:* miss c mailto:miss_c...@yahoo.com>>
*To:* Zi Ree mailto:tinacl...@gmx.de>>;
opensource-dev@lists.secondlife.com

*Sent:* Wed, September 29, 2010 5:45:25 PM

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

This is a tough one because it does leave a lot of guess work, but
still could be added to my list of tools I use to guess with.  I
will totally take it if it's being offered, I just pray this inst
the foundation the future tools will be built off of.  And about
the whole banning, my regions private, just open to the public, if
I want to ban 

Re: [opensource-dev] Shadow Controls

[Trilo Byte]

This is great, but I'd like to see the shadows implementation actually working 
on all platforms first.

TriloByte Zanzibar

On Sep 29, 2010, at 6:14 PM, Reed Steamroller wrote:

> Basically, I got this idea from all of the controls you've got over shadows 
> in Maya ( a program I'm partial to ).  
> 
> In particular, I'm thinking the ability to designate which objects both cast 
> and recieve shadows should be included in the viewer. 
> 
> As well, it would be nice to specify a color for shadows cast on a per object 
> basis.  
> 
> All of this I think could fit in the features tab in the edit window.  A 
> color swatch for the shadow color and some check boxes for "Cast Shadow" and 
> "Receive Shadow".  
> 
> Maybe even a slider for shadow-edge-fuzziness?  
> 
> What do you all think?
> 
> I posted a short JIRA on this subject, if you'ed like to check it out and 
> vote.
> 
> https://jira.secondlife.com/browse/VWR-23238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=214068
> 
> -- 
> William Reed Seal Foss (Reed Steamroller)
> Chief Creative Officer
> Sand Castle Studios LLC | Second Life
> 
> http://www.ChangingWorldsBuildingDreams.com
> r...@changingworldsbuildingdreams.com
> http://www.Twitter.com/ReedSteamroller
> ___
> 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] Shadow Controls

[Nexii Malthus]

Of interesting note. Prims did indeed have a flag for setting whether they
should cast shadows or not.

http://wiki.secondlife.com/wiki/PRIM_CAST_SHADOWS

- Nexii

On Thu, Sep 30, 2010 at 4:28 AM, Trilo Byte  wrote:

> This is great, but I'd like to see the shadows implementation actually
> working on all platforms first.
>
> TriloByte Zanzibar
>
> On Sep 29, 2010, at 6:14 PM, Reed Steamroller wrote:
>
> Basically, I got this idea from all of the controls you've got over shadows
> in Maya ( a program I'm partial to ).
>
> In particular, I'm thinking the ability to designate which objects both
> cast and recieve shadows should be included in the viewer.
>
> As well, it would be nice to specify a color for shadows cast on a per
> object basis.
>
> All of this I think could fit in the features tab in the edit window.  A
> color swatch for the shadow color and some check boxes for "Cast Shadow" and
> "Receive Shadow".
>
> Maybe even a slider for shadow-edge-fuzziness?
>
> What do you all think?
>
> I posted a short JIRA on this subject, if you'ed like to check it out and
> vote.
>
>
> https://jira.secondlife.com/browse/VWR-23238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=214068
>
> --
> William Reed Seal Foss (Reed Steamroller)
> Chief Creative Officer
> Sand Castle Studios LLC | Second Life
>
> http://www.ChangingWorldsBuildingDreams.com
> r...@changingworldsbuildingdreams.com
> http://www.Twitter.com/ReedSteamroller
>  ___
> 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] 2.0 Absolute Dealbreaker - script count feature request

[Ambrosia]

On Thu, Sep 30, 2010 at 01:06, Kelly Linden  wrote:
> * In the end the number of scripts shouldn't be important

It is currently important hover, because due to a lack of script
memory limits per avatar/parcel, you can see lots of people wearing an
excess of over 200 scripts per avatar. Easily. All it takes is a badly
written hud, old resizer clothes, etc. I don't seldomly see people
entering/leaving a sim with 400+ scripts.

Now, each script takes around 0.0015 - 0.002 ms when idle. With 60
scripts you already get an overhead of 0.1 ms of script time on the
sim. Take 5 avatars with a total of ~1k scripts and you get around
15ms of overhead. Plus -at least- 16mb of memory used if all those
scripts are mono, which is unlikely.

And as I said, that amount of scripts in a sim due to avatars happens,
and it doesn't happen in rare cases.


Bryon Ruxton:

>As long as it doesn't return the true memory usage, people will start banning
>mono scripted objects, because they don't know better and won't listen to
>explanations.

The issue is that Mono scripts currently reserve 64kb to themselves,
even if they use less. the 64kb of memory, of resources are lost. So
that display isn't too inaccurate, until we can actually define how
much memory a script should reserve. One of the main sim performance
killers is when a sim runs out of script memory and starts swapping to
disk.


TL;DR: We need the Script Limits, Small Scripts and Big Scripts
projects out of the mothball.

--Chalice Yao
___
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

[Ambrosia]

On Thu, Sep 30, 2010 at 08:03, Ambrosia  wrote:
> On Thu, Sep 30, 2010 at 01:06, Kelly Linden  wrote:
>> * In the end the number of scripts shouldn't be important
>
> 15ms of overhead. Plus -at least- 16mb of memory used if all those
> scripts are mono, which is unlikely.

That should have been 'are LSL', of course ;P
___
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] Shadow Controls

[Marine Kelley]

All platforms, and all video cards especially ATI. Oh the joy it would be !

On a side note, I really like how shininess+brightness bump looks when
shadows are activated. You can really make a prim look wet with this one !


On 30 September 2010 05:28, Trilo Byte  wrote:

> This is great, but I'd like to see the shadows implementation actually
> working on all platforms first.
>
> TriloByte Zanzibar
>
> On Sep 29, 2010, at 6:14 PM, Reed Steamroller wrote:
>
> Basically, I got this idea from all of the controls you've got over shadows
> in Maya ( a program I'm partial to ).
>
> In particular, I'm thinking the ability to designate which objects both
> cast and recieve shadows should be included in the viewer.
>
> As well, it would be nice to specify a color for shadows cast on a per
> object basis.
>
> All of this I think could fit in the features tab in the edit window.  A
> color swatch for the shadow color and some check boxes for "Cast Shadow" and
> "Receive Shadow".
>
> Maybe even a slider for shadow-edge-fuzziness?
>
> What do you all think?
>
> I posted a short JIRA on this subject, if you'ed like to check it out and
> vote.
>
>
> https://jira.secondlife.com/browse/VWR-23238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=214068
>
> --
> William Reed Seal Foss (Reed Steamroller)
> Chief Creative Officer
> Sand Castle Studios LLC | Second Life
>
> http://www.ChangingWorldsBuildingDreams.com
> r...@changingworldsbuildingdreams.com
> http://www.Twitter.com/ReedSteamroller
>  ___
> 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