[opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
As a sim owner I have to have script counter so we can keep our scripts low in the sim because of the excessive us of resizing scripts. Several times a day we have an exercise in our sim where we make an estate announcement to count your scripts and your neighbors to reduce the load on the servers. Even though we do this several times a day there is always someone who forgot their scripts in something, you can easily find a good 5-10 people with 400+ scripts on them. I am completely sold on the 2.0 code and can live without some of the other features in Phoenix/Emerald, but this one is an absolute deal breaker for me. I combed through the code to try and see if this was something handled in xml commands and its not, its in the Phoenix/Emerald code. Can we please get this option, also the option of avatar announcement upon entering the sim helps combat scripts. I have it announcing when an avatar enters and announcing region script count change so i know as soon as they enter and their script count if I am paying attention. TY Miss ___ 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
I added it to the Jira : https://jira.secondlife.com/browse/VWR-23200 If it is a duplicate, I apologize, I did search and didn't find anything. TY Miss From: miss c To: opensource-dev@lists.secondlife.com Sent: Mon, September 27, 2010 9:21:39 AM Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request As a sim owner I have to have script counter so we can keep our scripts low in the sim because of the excessive us of resizing scripts. Several times a day we have an exercise in our sim where we make an estate announcement to count your scripts and your neighbors to reduce the load on the servers. Even though we do this several times a day there is always someone who forgot their scripts in something, you can easily find a good 5-10 people with 400+ scripts on them. I am completely sold on the 2.0 code and can live without some of the other features in Phoenix/Emerald, but this one is an absolute deal breaker for me. I combed through the code to try and see if this was something handled in xml commands and its not, its in the Phoenix/Emerald code. Can we please get this option, also the option of avatar announcement upon entering the sim helps combat scripts. I have it announcing when an avatar enters and announcing region script count change so i know as soon as they enter and their script count if I am paying attention. TY Miss ___ 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
For some reason I can't access the Jira. I'm not sure what you are asking for. If you are asking for a script counter, there is the top scripts counter in the estate panel. -Frans On Mon, Sep 27, 2010 at 4:47 PM, miss c wrote: > > I added it to the Jira : https://jira.secondlife.com/browse/VWR-23200 > > If it is a duplicate, I apologize, I did search and didn't find anything. > > TY > > Miss > -- > *From:* miss c > *To:* opensource-dev@lists.secondlife.com > *Sent:* Mon, September 27, 2010 9:21:39 AM > *Subject:* [opensource-dev] 2.0 Absolute Dealbreaker - script count > feature request > > As a sim owner I have to have script counter so we can keep our scripts low > in the sim because of the excessive us of resizing scripts. Several times a > day we have an exercise in our sim where we make an estate announcement to > count your scripts and your neighbors to reduce the load on the servers. > Even though we do this several times a day there is always someone who > forgot their scripts in something, you can easily find a good 5-10 people > with 400+ scripts on them. I am completely sold on the 2.0 code and can > live without some of the other features in Phoenix/Emerald, but this one is > an absolute deal breaker for me. I combed through the code to try and see > if this was something handled in xml commands and its not, its in the > Phoenix/Emerald code. Can we please get this option, also the option of > avatar announcement upon entering the sim helps combat scripts. I have it > announcing when an avatar enters and announcing region script count change > so i know as soon as they enter and their script count if I am paying > attention. > > TY > > Miss > > > > ___ > 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
t;other is in script change region announcements under phoenix misc in >preferences. You see here his script count is higher than what his body >count >is because the body count does not include HUD attachments. So this means he >has 60 on his HUD I cant see or count, I just know there was a region change >when he entered the sim. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.secondlife.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From: Frans To: miss c Cc: opensource-dev@lists.secondlife.com Sent: Mon, September 27, 2010 4:18:41 PM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request For some reason I can't access the Jira. I'm not sure what you are asking for. If you are asking for a script counter, there is the top scripts counter in the estate panel. -Frans On Mon, Sep 27, 2010 at 4:47 PM, miss c wrote: > >I added it to the Jira : https://jira.secondlife.com/browse/VWR-23200 > >If it is a duplicate, I apologize, I did search and didn't find anything. > >TY > >Miss > > From: miss c >To: opensource-dev@lists.secondlife.com >Sent: Mon, September 27, 2010 9:21:39 AM >Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature >request > > > >As a sim owner I have to have script counter so we can keep our scripts low in >the sim because of the excessive us of resizing scripts. Several times a day >we >have an exercise in our sim where we make an estate announcement to count your >scripts and your neighbors to reduce the load on the servers. Even though we >do >this several times a day there is always someone who forgot their scripts in >something, you can easily find a good 5-10 people with 400+ scripts on them. >I >am completely sold on the 2.0 code and can live without some of the other >features in Phoenix/Emerald, but this one is an absolute deal breaker for me. >I >combed through the code to try and see if this was something handled in xml >commands and its not, its in the Phoenix/Emerald code. Can we please get >this >option, also the option of avatar announcement upon entering the sim helps >combat scripts. I have it announcing when an avatar enters and announcing >region script count change so i know as soon as they enter and their script >count if I am paying attention. > > >TY > >Miss > > > >___ >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
t;other is in script change region announcements under phoenix misc in >preferences. You see here his script count is higher than what his body >count >is because the body count does not include HUD attachments. So this means he >has 60 on his HUD I cant see or count, I just know there was a region change >when he entered the sim. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.secondlife.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira From: Frans To: miss c Cc: opensource-dev@lists.secondlife.com Sent: Mon, September 27, 2010 4:18:41 PM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request For some reason I can't access the Jira. I'm not sure what you are asking for. If you are asking for a script counter, there is the top scripts counter in the estate panel. -Frans On Mon, Sep 27, 2010 at 4:47 PM, miss c wrote: > >I added it to the Jira : https://jira.secondlife.com/browse/VWR-23200 > >If it is a duplicate, I apologize, I did search and didn't find anything. > >TY > >Miss > > From: miss c >To: opensource-dev@lists.secondlife.com >Sent: Mon, September 27, 2010 9:21:39 AM >Subject: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature >request > > > >As a sim owner I have to have script counter so we can keep our scripts low in >the sim because of the excessive us of resizing scripts. Several times a day >we >have an exercise in our sim where we make an estate announcement to count your >scripts and your neighbors to reduce the load on the servers. Even though we >do >this several times a day there is always someone who forgot their scripts in >something, you can easily find a good 5-10 people with 400+ scripts on them. >I >am completely sold on the 2.0 code and can live without some of the other >features in Phoenix/Emerald, but this one is an absolute deal breaker for me. >I >combed through the code to try and see if this was something handled in xml >commands and its not, its in the Phoenix/Emerald code. Can we please get >this >option, also the option of avatar announcement upon entering the sim helps >combat scripts. I have it announcing when an avatar enters and announcing >region script count change so i know as soon as they enter and their script >count if I am paying attention. > > >TY > >Miss > > > >___ >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
ipts. Please wait. > > [10:36] Counted scripts from 14 attachments on amethys Inglewood: 540 > (this is someone that volunteered for this test) > > Looking through the Phoenix, Wasabi, Emergance, & Emerald XML I find that > all self object, attachment pie menus point to a function called > "Object.VisibleScriptCount" > > The code is found in the menuviewer.xml > > label="Count Scripts in Selection" left="0" mouse_opaque="true" name="Count > Scripts in Selection" width="250"> > > > > > > > > I have attached the appropriate files that are in all these viewers > > Also this is the other feature I am referring to > > [10:34] amethys Inglewood has entered the sim. > > [10:34] Total scripts jumped from 3357 to 3957 (600) > > These are in separate functions in those viewers, one is in the radar, > the other is in script change region announcements under phoenix misc in > preferences. You see here his script count is higher than what his body > count is because the body count does not include HUD attachments. So this > means he has 60 on his HUD I cant see or count, I just know there was a > region change when he entered the sim. > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > https://jira.secondlife.com/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > > > > -- > *From:* Frans > *To:* miss c > *Cc:* opensource-dev@lists.secondlife.com > *Sent:* Mon, September 27, 2010 4:18:41 PM > *Subject:* Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count > feature request > > For some reason I can't access the Jira. I'm not sure what you are asking > for. If you are asking for a script counter, there is the top scripts > counter in the estate panel. > > -Frans > > > On Mon, Sep 27, 2010 at 4:47 PM, miss c wrote: > >> >> I added it to the Jira : https://jira.secondlife.com/browse/VWR-23200 >> >> If it is a duplicate, I apologize, I did search and didn't find anything. >> >> TY >> >> Miss >> -- >> *From:* miss c >> *To:* opensource-dev@lists.secondlife.com >> *Sent:* Mon, September 27, 2010 9:21:39 AM >> *Subject:* [opensource-dev] 2.0 Absolute Dealbreaker - script count >> feature request >> >> As a sim owner I have to have script counter so we can keep our scripts >> low in the sim because of the excessive us of resizing scripts. Several >> times a day we have an exercise in our sim where we make an estate >> announcement to count your scripts and your neighbors to reduce the load on >> the servers. Even though we do this several times a day there is always >> someone who forgot their scripts in something, you can easily find a good >> 5-10 people with 400+ scripts on them. I am completely sold on the 2.0 code >> and can live without some of the other features in Phoenix/Emerald, but this >> one is an absolute deal breaker for me. I combed through the code to try >> and see if this was something handled in xml commands and its not, its in >> the Phoenix/Emerald code. Can we please get this option, also the option of >> avatar announcement upon entering the sim helps combat scripts. I have it >> announcing when an avatar enters and announcing region script count change >> so i know as soon as they enter and their script count if I am paying >> attention. >> >> TY >> >> Miss >> >> >> >> ___ >> 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
andled in xml commands and its not, its in >> the Phoenix/Emerald code. Can we please get this option. >> > Also the option of avatar announcement and script fluctuation upon >> entering the sim helps combat scripts, this would be helpful in 2.0 but I >> wouldn't call it a deal breaker. I have it announcing when an avatar enters >> and announcing region script count change so i know as soon as they enter >> and their script count if I am paying attention. >> > TY >> > Miss >> > UPDATE: MORE INFO: If you are using a viewer based on the Emerald code >> base such as Emergance or Phoenix you can rightclick any object including >> avatars and it will count how many scripts are attached to the avatar or are >> inside the object. See referencing picture.You then receive this message... >> > [10:36] Counting scripts. Please wait. >> > [10:36] Counted scripts from 14 attachments on amethys Inglewood: 540 >> (this is someone that volunteered for this test) >> > Looking through the Phoenix, Wasabi, Emergance, & Emerald XML I find >> that all self object, attachment pie menus point to a function called >> "Object.VisibleScriptCount" >> > The code is found in the menuviewer.xml >> > > label="Count Scripts in Selection" left="0" mouse_opaque="true" name="Count >> Scripts in Selection" width="250"> >> > >> > >> > >> > I have attached the appropriate files that are in all these viewers >> > Also this is the other feature I am referring to >> > [10:34] amethys Inglewood has entered the sim. >> > [10:34] Total scripts jumped from 3357 to 3957 (600) >> > These are in separate functions in those viewers, one is in the radar, >> the other is in script change region announcements under phoenix misc in >> preferences. You see here his script count is higher than what his body >> count is because the body count does not include HUD attachments. So this >> means he has 60 on his HUD I cant see or count, I just know there was a >> region change when he entered the sim. >> >> -- >> This message is automatically generated by JIRA. >> - >> If you think it was sent incorrectly contact one of the administrators: >> https://jira.secondlife.com/secure/Administrators.jspa >> - >> For more information on JIRA, see: http://www.atlassian.com/software/jira >> >> >> >> >> >> -- >> *From:* Frans >> *To:* miss c >> *Cc:* opensource-dev@lists.secondlife.com >> *Sent:* Mon, September 27, 2010 4:18:41 PM >> *Subject:* Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count >> feature request >> >> For some reason I can't access the Jira. I'm not sure what you are asking >> for. If you are asking for a script counter, there is the top scripts >> counter in the estate panel. >> >> -Frans >> >> >> On Mon, Sep 27, 2010 at 4:47 PM, miss c wrote: >> >>> >>> I added it to the Jira : https://jira.secondlife.com/browse/VWR-23200 >>> >>> If it is a duplicate, I apologize, I did search and didn't find anything. >>> >>> TY >>> >>> Miss >>> -- >>> *From:* miss c >>> *To:* opensource-dev@lists.secondlife.com >>> *Sent:* Mon, September 27, 2010 9:21:39 AM >>> *Subject:* [opensource-dev] 2.0 Absolute Dealbreaker - script count >>> feature request >>> >>> As a sim owner I have to have script counter so we can keep our scripts >>> low in the sim because of the excessive us of resizing scripts. Several >>> times a day we have an exercise in our sim where we make an estate >>> announcement to count your scripts and your neighbors to reduce the load on >>> the servers. Even though we do this several times a day there is always >>> someone who forgot their scripts in something, you can easily find a good >>> 5-10 people with 400+ scripts on them. I am completely sold on the 2.0 code >>> and can live without some of the other features in Phoenix/Emerald, but this >>> one is an absolute deal breaker for me. I combed through the code to try >>> and see if this was something handled in xml commands and its not, its in >>> the Phoenix/Emerald code. Can we please get this option, also the option of >>> avatar announcement upon entering the s
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
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 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 either. Below are the details I added, worked real hard on getting all >information needed, all the referencing files uploaded, had 50 something >votes, >now gone, I hope it is taken seriously. >> >> >>Miss >> >> [ >>https://jira.secondlife.com/browse/VWR-23200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> ] >> >>Esbee Linden updated VWR-23200: >>--- >> >>Summary: Script count feature request (was: Script Count - 2.0 Absolute >>Dealbreaker - script count feature request) >> >>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. >> >>> Script count feature request >>> - >>> >>> Key: VWR-23200 >>> URL: https://jira.secondlife.com/browse/VWR-23200 >>> Project: 1. Second Life Viewer - VWR >>> Issue Type: New Feature >>> Components: Avatar/Character, Building (in-world), Performance, >>>Scripting, Source Code, User Interface >>> Environment: Second Life 2.2.1 (210525) Sep 25 2010 08:22:37 >>> (Second >>>Life Development) >>> Release Notes >>> CPU: Intel(R) Core(TM)2 Quad CPUQ8300 @ 2.50GHz (2493.73 MHz) >>> Memory: 6078 MB >>> OS Version: Microsoft Windows Vista 64-bit Service Pack 1 (Build 6001) >>> Graphics Card Vendor: ATI Technologies Inc. >>> Graphics Card: ATI Radeon HD 4600 Series >>> Windows Graphics Driver Version: 8.17.0010.1041 >>> OpenGL Version: 3.3.10151 Compatibility Profile Context >>> libcurl Version: libcurl/7.20.1 OpenSSL/0.9.8j zlib/1.2.3 >>> J2C Decoder Version: KDU >>> Audio Driver Version: FMOD version 3.74 >>> Qt Webkit Version: 4.6 (version number hard-coded) >>> Voice Server Version: Not Connected >>> Built with MSVC version 1400 >>>Reporter: Miss Wright >>>Priority: Severe >>> Attachments: CMakeLists.txt, floateravatarlist.cpp, >>> llstartup.cpp, >>>llviewermenu.cpp, menu_pie_attachment.xml, menu_pie_avatar.xml, >>>menu_pie_object.xml, menu_pie_self.xml, message.xml, scriptcounter.cpp, >>>scriptcounter.h, scriptcountsample.jpg >>> >>> >&
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
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 either. Below are the details I added, worked real hard on >>> getting all information needed, all the referencing files uploaded, had 50 >>> something votes, now gone, I hope it is taken seriously. >>> >>> Miss >>> >>> [ >>> https://jira.secondlife.com/browse/VWR-23200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] >>> >>> Esbee Linden updated VWR-23200: >>> --- >>> >>> Summary: Script count feature request (was: Script Count - 2.0 >>> Absolute Dealbreaker - script count feature request) >>> >>> 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. >>> >>> > Script count feature request >>> > - >>> > >>> >Key: VWR-23200 >>> >URL: https://jira.secondlife.com/browse/VWR-23200 >>> >Project: 1. Second Life Viewer - VWR >>> > Issue Type: New Feature >>> > Components: Avatar/Character, Building (in-world), >>> Performance, Scripting, Source Code, User Interface >>> >Environment: Second Life 2.2.1 (210525) Sep 25 2010 08:22:37 >>> (Second Life Development) >>> > Release Notes >>> > CPU: Intel(R) Core(TM)2 Quad CPUQ8300 @ 2.50GHz (2493.73 MHz) >>> > Memory: 6078 MB >>> > OS Version: Microsoft Windows Vista 64-bit Service Pack 1 (Build 6001) >>> > Graphics Card Vendor: ATI Technologies Inc. >>> > Graphics Card: ATI Radeon HD 4600 Series >>> > Windows Graphics Driver Version: 8.17.0010.1041 >>> > OpenGL Version: 3.3.10151 Compatibility Profile Conte
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
I think that Esbee is right, this feature really does need a server assist to work properly. Most significantly, the client-only attempts skip HUD 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
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, >>>
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
To your p.s i think the code she submitted was more of a example of how its done not a patch as she is not a coder nor submitted the code as a official patch. Also you should note that most people are ignorant of LLs need to be able to push code back into a closed source and assume that GPL / opensource means LL can use it. Which actually would be a valid thought if ll's source was gpl on its own versions. I on the other have have a CLA signed. Hence why i said i would willingly re implement not port or copy. A version of my own doing and optimization. I think the major issue boils down to the feature is a major thing for sim owners. I think the disconnection between the populace and LL is apparent in this request as the residents see it as a critical feature and ll sees it in a different view. But this list is not one to argue philosophy nor semantics. The code in question on the approach to how its done is not a bad one IMHO. Yes server side could probably implement it better but none of the non LL on this list have access to such things and must make do with what we are given. From continued use its not apparent to be laggy actually but I could be mistaken. I strongly suggest this data (the end result) be includes as its value to your residents is quite critical. Dim. On Tue, Sep 28, 2010 at 12:55 AM, 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. 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 >>
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
The issue is all these crappy old obsolete resizers and texture changers. How about a different approach? Step one is complete. Some of us have worked and posted for free various versions of the fast resizers in one script. So there is no excuse for anyone to continue building new content using the obsolete versions. Step 2 would be to do the same for texture changers which is a different animal. Step 3 would be an official public awareness campaign to get creators on board. Step 4 might be some sort of program to get people to trade in their old script abusing shoes and hair on new versions that are not abusive. Step 5 might be to just kill the old abusive scripts when detected. Then LL can begin working on the other popular items notorious for infringing on others rights to a stable sim they are paying tier in. All this time an effort is going into mesh to get people to be aware of vertice counts. How about a similar effort around script resource abuse? Then you don't have to sandbag regions to get to a tool for estate owners to eject what they feel are script abusers. From: Kelly Linden To: Brandon Husbands Cc: opensource-dev@lists.secondlife.com Sent: Tue, September 28, 2010 1:55:57 AM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request 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 Ab
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
SNIP~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. SNIP~kelly linden commented on VWR-23200: It would be helpful to get more specifics on exactly what information is desired. I have not used many TPVs so it isn't immediately apparent what feature set you are requesting. Am I correct to guess that you are asking for a list of avatars and how many scripts each avatar has on them? I was trying to give you the examples you specifically asked for. You already have this code as it is in your agreement to be TPVD approve you must give the code over and have it opensourced. I have been very excited over the viewer code base and all the improvements that you guys have made, because of the lack of sim tools this is a very needed function. Sending my Jira to the Land team almost seems like certain death because they haven't added any useful tools in the 4 years I have been here in SL. I have to have this feature and that's why I pushed it, I want to migrate over to 2.0 completely, but it looks like I cant now. I would rather deal with unrezzed textures, lack of media, lack of all the new fun features, than not be able to manage my sim and this is MY number one tool to do it with. The resizing scripts kill SL, we are talking thousands upon thousands, upon thousands, just think how it is with 50 people in a sim. I spend so much time chasing these scripts, several times a day, these scripts bring my sim to its knees. The script counter is my only weapon against it. Guess no mesh or streaming media for me, back to Phoenix. Anne: Ever so often I too send out pleas for designers to stop using these, they wont, they say its the customers responsibility to remove them, not their problem. From: Ann Otoole To: opensource-dev@lists.secondlife.com Sent: Tue, September 28, 2010 1:52:53 AM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request The issue is all these crappy old obsolete resizers and texture changers. How about a different approach? Step one is complete. Some of us have worked and posted for free various versions of the fast resizers in one script. So there is no excuse for anyone to continue building new content using the obsolete versions. Step 2 would be to do the same for texture changers which is a different animal. Step 3 would be an official public awareness campaign to get creators on board. Step 4 might be some sort of program to get people to trade in their old script abusing shoes and hair on new versions that are not abusive. Step 5 might be to just kill the old abusive scripts when detected. Then LL can begin working on the other popular items notorious for infringing on others rights to a stable sim they are paying tier in. All this time an effort is going into mesh to get people to be aware of vertice counts. How about a similar effort around script resource abuse? Then you don't have to sandbag regions to get to a tool for estate owners to eject what they feel are script abusers. From: Kelly Linden To: Brandon Husbands Cc: opensource-dev@lists.secondlife.com Sent: Tue, September 28, 2010 1:55:57 AM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request 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 eva
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
I'm probably gonna get roasted here, but I actually agree with the decision to move it to the land team, even with the understanding that these tools might not be as fast to be complimented as they would be with a purely viewer approach. here's my reasons: 1) If changing the server code means it can be done with less stress on the sim, that means sim resources can be better allocated for a smoother functioning sim. 2) by making it a combination of viewer AND simulator code, they open up the possibility of adding in additional tools that are based of these or work in conjunction with these with less work later on. 3) This opens up the possibility of script monitoring and replacement later on to do exactly what Ann is talking about with objects which are no modify and whose creators no longer support their products, no longer have the old versions to base new versions off of, have left SL, or have died. 4) Might inspire additional tools that we haven't thought of. I honestly think kicking this to the land team would be a good idea as long as they understand that they need to put some priority on this. That said, it might be wise to clone the issue back to vwr simply so a public one is available to access and where progress can be tracked by the community. Date: Mon, 27 Sep 2010 23:52:53 -0700 From: missannoto...@yahoo.com To: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request The issue is all these crappy old obsolete resizers and texture changers. How about a different approach? Step one is complete. Some of us have worked and posted for free various versions of the fast resizers in one script. So there is no excuse for anyone to continue building new content using the obsolete versions. Step 2 would be to do the same for texture changers which is a different animal. Step 3 would be an official public awareness campaign to get creators on board. Step 4 might be some sort of program to get people to trade in their old script abusing shoes and hair on new versions that are not abusive. Step 5 might be to just kill the old abusive scripts when detected. Then LL can begin working on the other popular items notorious for infringing on others rights to a stable sim they are paying tier in. All this time an effort is going into mesh to get people to be aware of vertice counts. How about a similar effort around script resource abuse? Then you don't have to sandbag regions to get to a tool for estate owners to eject what they feel are script abusers. From: Kelly Linden To: Brandon Husbands Cc: opensource-dev@lists.secondlife.com Sent: Tue, September 28, 2010 1:55:57 AM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request 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 atta
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
I give you an image of what thousands of people are wearing and dozens more buy daily for less than L$200: http://annotoole.com/images/nuclearshoes.png (not my product btw) 11456kb each shoe? seriously? So 20 avatars in a club with these uses 458MB of region memory? Yes. A public awareness campaign is sorely needed. From: Ann Otoole To: opensource-dev@lists.secondlife.com Sent: Tue, September 28, 2010 2:52:53 AM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request The issue is all these crappy old obsolete resizers and texture changers. How about a different approach? Step one is complete. Some of us have worked and posted for free various versions of the fast resizers in one script. So there is no excuse for anyone to continue building new content using the obsolete versions. Step 2 would be to do the same for texture changers which is a different animal. Step 3 would be an official public awareness campaign to get creators on board. Step 4 might be some sort of program to get people to trade in their old script abusing shoes and hair on new versions that are not abusive. Step 5 might be to just kill the old abusive scripts when detected. Then LL can begin working on the other popular items notorious for infringing on others rights to a stable sim they are paying tier in. All this time an effort is going into mesh to get people to be aware of vertice counts. How about a similar effort around script resource abuse? Then you don't have to sandbag regions to get to a tool for estate owners to eject what they feel are script abusers. From: Kelly Linden To: Brandon Husbands Cc: opensource-dev@lists.secondlife.com Sent: Tue, September 28, 2010 1:55:57 AM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request 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 >
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
On 27 September 2010 23:22, Brandon Husbands wrote: > > I think the major issue boils down to the feature is a major thing for sim > owners. I think the disconnection between the populace and LL is apparent in > this request as the residents see it as a critical feature and ll sees it in > a different view. But this list is not one to argue philosophy nor > semantics. > This thread is all of 17 hours old. It's premature to say that somehow we're already going against the wishes of our resident base when we haven't even had time to explore the many options here, let alone prioritise them. > The code in question on the approach to how its done is not a bad one IMHO. > Yes server side could probably implement it better but none of the non LL on > this list have access to such things and must make do with what we are > given. From continued use its not apparent to be laggy actually but I could > be mistaken. > 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 ___ 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
Am Dienstag, 28. September 2010, 10:09:07 schrieb Ann Otoole: > I give you an image of what thousands of people are wearing and dozens more > buy daily for less than L$200: > http://annotoole.com/images/nuclearshoes.png (not my product btw) > > 11456kb each shoe? seriously? So 20 avatars in a club with these uses 458MB > of region memory? > > > Yes. A public awareness campaign is sorely needed. for that it needs to be known what shoe that is, who makes it, and the link to the SLU and blogorums post that makes the public actually aware... i mean, checking with the script floater AFTER you bought the shoes isn't going to make that creator aware of what shit he/she sells by reducing their sales. therefor: name shame and blame please. ___ 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
this isn't the place for that and LL needs to weigh in on things like this. It isn't the only one and one person LL openly promotes also sells over scripted shoes. If we are going after one we have to go after the ones LL promotes as well. Better for LL to step up first. From: Lance Corrimal To: opensource-dev@lists.secondlife.com Sent: Tue, September 28, 2010 5:06:06 AM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request Am Dienstag, 28. September 2010, 10:09:07 schrieb Ann Otoole: > I give you an image of what thousands of people are wearing and dozens more > buy daily for less than L$200: > http://annotoole.com/images/nuclearshoes.png (not my product btw) > > 11456kb each shoe? seriously? So 20 avatars in a club with these uses 458MB > of region memory? > > > Yes. A public awareness campaign is sorely needed. for that it needs to be known what shoe that is, who makes it, and the link to the SLU and blogorums post that makes the public actually aware... i mean, checking with the script floater AFTER you bought the shoes isn't going to make that creator aware of what shit he/she sells by reducing their sales. therefor: name shame and blame please. ___ 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
On 28 September 2010 11:20, Ann Otoole wrote: > this isn't the place for that and LL needs to weigh in on things like this. > > It isn't the only one and one person LL openly promotes also sells over > scripted shoes. > If we are going after one we have to go after the ones LL promotes as well. > > Better for LL to step up first. > > I think I know who you are talking about, Ann. I remember having sent a very detailed notecard with script time, snapshots and explanations, proving that the lag came from their shoes and that they really should do something to lighten the load on the sims. One resizer and texturer script per prim on a 250-prim shoe (and you got two feet), some of the prims never even showing because you have to actually buy an option to see them, is unacceptable. No response from them whatsoever, and no change in their products. My message totally fell in deaf ears. So I gave up on them and went to the competition, who does listen to their customers. And I made a point in telling everyone I know to do the same. End of story. I just wish everyone was aware of how much resources they take, and that means having the right tools for it. The upcoming script limits project were aimed at doing that, but I guess it is suspended for the moment. ___ 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
Sorry for top quoting... There Are already a lot if monoscript based on a single script for whole item, but lazyness of creator is high and is more easy say "is a LL fault the lag", But this is about OT here. ;) -- Sent by iPhone Il giorno 28/set/2010, alle ore 11:27, Marine Kelley ha scritto: On 28 September 2010 11:20, Ann Otoole wrote: > this isn't the place for that and LL needs to weigh in on things like this. > > It isn't the only one and one person LL openly promotes also sells over > scripted shoes. > If we are going after one we have to go after the ones LL promotes as well. > > Better for LL to step up first. > > I think I know who you are talking about, Ann. I remember having sent a very detailed notecard with script time, snapshots and explanations, proving that the lag came from their shoes and that they really should do something to lighten the load on the sims. One resizer and texturer script per prim on a 250-prim shoe (and you got two feet), some of the prims never even showing because you have to actually buy an option to see them, is unacceptable. No response from them whatsoever, and no change in their products. My message totally fell in deaf ears. So I gave up on them and went to the competition, who does listen to their customers. And I made a point in telling everyone I know to do the same. End of story. I just wish everyone was aware of how much resources they take, and that means having the right tools for it. The upcoming script limits project were aimed at doing that, but I guess it is suspended for the moment. ___ 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
Am Dienstag, 28. September 2010, 11:27:22 schrieb Marine Kelley: > On 28 September 2010 11:20, Ann Otoole wrote: > > this isn't the place for that and LL needs to weigh in on things like > > this. > > > > It isn't the only one and one person LL openly promotes also sells over > > scripted shoes. > > If we are going after one we have to go after the ones LL promotes as > > well. > > > > Better for LL to step up first. > > I think I know who you are talking about, Ann. I remember having sent a > very detailed notecard with script time, snapshots and explanations, > proving that the lag came from their shoes and that they really should do > something to lighten the load on the sims. One resizer and texturer script > per prim on a 250-prim shoe (and you got two feet), some of the prims > never even showing because you have to actually buy an option to see them, > is unacceptable. > > No response from them whatsoever, and no change in their products. My > message totally fell in deaf ears. So I gave up on them and went to the > competition, who does listen to their customers. And I made a point in > telling everyone I know to do the same. End of story. could that by any chance be one of the reasons why that shop strictly refuses to make demo versions available... so that people could check the script load on those shoes before they buy? bye, LC ___ 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
Could be... I have not set foot there for almost a year now. lol On 28 September 2010 12:44, Lance Corrimal wrote: > Am Dienstag, 28. September 2010, 11:27:22 schrieb Marine Kelley: > > On 28 September 2010 11:20, Ann Otoole wrote: > > > this isn't the place for that and LL needs to weigh in on things like > > > this. > > > > > > It isn't the only one and one person LL openly promotes also sells over > > > scripted shoes. > > > If we are going after one we have to go after the ones LL promotes as > > > well. > > > > > > Better for LL to step up first. > > > > I think I know who you are talking about, Ann. I remember having sent a > > very detailed notecard with script time, snapshots and explanations, > > proving that the lag came from their shoes and that they really should do > > something to lighten the load on the sims. One resizer and texturer > script > > per prim on a 250-prim shoe (and you got two feet), some of the prims > > never even showing because you have to actually buy an option to see > them, > > is unacceptable. > > > > No response from them whatsoever, and no change in their products. My > > message totally fell in deaf ears. So I gave up on them and went to the > > competition, who does listen to their customers. And I made a point in > > telling everyone I know to do the same. End of story. > > > could that by any chance be one of the reasons why that shop strictly > refuses > to make demo versions available... so that people could check the script > load > on those shoes before they buy? > > > bye, > LC > > ___ > 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
Agreed, Yoz, it's definitely worth doing right and while it may be possible to get some stats with a viewer-based solution it makes sense that this should fall to the land team. Trilo On Sep 28, 2010, at 1:57 AM, Yoz Grahame wrote: > > > On 27 September 2010 23:22, Brandon Husbands wrote: > > I think the major issue boils down to the feature is a major thing for sim > owners. I think the disconnection between the populace and LL is apparent in > this request as the residents see it as a critical feature and ll sees it in > a different view. But this list is not one to argue philosophy nor semantics. > > This thread is all of 17 hours old. It's premature to say that somehow we're > already going against the wishes of our resident base when we haven't even > had time to explore the many options here, let alone prioritise them. > > The code in question on the approach to how its done is not a bad one IMHO. > Yes server side could probably implement it better but none of the non LL on > this list have access to such things and must make do with what we are given. > From continued use its not apparent to be laggy actually but I could be > mistaken. > > 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 > > ___ > 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
The point is this, that this option is already readily available. I use this option everyday and see no problem with it. Thousands of people all over Second Life use this option. It is harder on the servers to have a million scripts than to have this tool to reduce them, I know because I can see the difference. I know ideally it would be both a server and viewer function, but I can't wait another 6 months hoping the feature shows up. I realize the script Limits were suppose to help fix this but the problem is avatars, and oddly avatars were left out of the script limit tools, rendering them useless. I have paid out well over 20 grand in tier over the past several of years, and that's not an exaggeration, I have yearned for more sim tools as many others have for years. Creating something from scratch I can understand is a long hard process, but this is something that is there and works. I have to have this option cause I have no other real tools, therefore I can't use your viewer. That's my point, I can't enjoy these new wonderful features only available in your viewer because my responsibilities and priorities as an Estate Owner come first. So the argument that it would be better to do it server side still doesn't change the fact that not having this option is an absolute deal breaker for me, I am not trying to be stubborn, this is a REAL need. TY Miss From: Lance Corrimal To: opensource-dev@lists.secondlife.com Sent: Tue, September 28, 2010 5:44:08 AM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request Am Dienstag, 28. September 2010, 11:27:22 schrieb Marine Kelley: > On 28 September 2010 11:20, Ann Otoole wrote: > > this isn't the place for that and LL needs to weigh in on things like > > this. > > > > It isn't the only one and one person LL openly promotes also sells over > > scripted shoes. > > If we are going after one we have to go after the ones LL promotes as > > well. > > > > Better for LL to step up first. > > I think I know who you are talking about, Ann. I remember having sent a > very detailed notecard with script time, snapshots and explanations, > proving that the lag came from their shoes and that they really should do > something to lighten the load on the sims. One resizer and texturer script > per prim on a 250-prim shoe (and you got two feet), some of the prims > never even showing because you have to actually buy an option to see them, > is unacceptable. > > No response from them whatsoever, and no change in their products. My > message totally fell in deaf ears. So I gave up on them and went to the > competition, who does listen to their customers. And I made a point in > telling everyone I know to do the same. End of story. could that by any chance be one of the reasons why that shop strictly refuses to make demo versions available... so that people could check the script load on those shoes before they buy? bye, LC ___ 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
Hey People! Please excuse me while i say something for all the n00bs in the world, whether their "inexperience" is their fault or not, and without judging anyone's learning speed, patience, or whatever else those with criticize the others who are without for lacking. Maybe i'm just "challenged" myself, but i haven't found anything, anywhere that comes even close to being a "one stop" resource for builders, scripters, land owners, etc. Even the user guide stuff could use better organization and a "more engaging" presentation. It's not like a bunch of us don't have the skills needed to put together a totally killer instruction manual for SecondLife like the one you don't get (but really ought to) for FL (First Life). It's the time, charter, & all the other stuff you have to have to eat & pay tier for in all your lives that gets in the way of doing what i guess too many people don't value enough to hire someone to do a good job of. It's pretty sad, too, because i think there's easily enough active SL premium residents that 10 cents a month from each of them would fund an awesome project, maybe even with some revenue opportunities for LL. What i mean is sometthing like a book that's a website (best with continually updated information) that does the A to Z thing for all the builder & scripter tasks with regular resident & landowner sections to go with it. Not just recipes, but recipes with explanations. A lot of the material needed to start a project like that has already been written, it just needs to be all put all together and organized better. The next step could be to get together a list of all the things people build and script for a comprehensive set of tutorials that covered everything from t-shirts and shoes to complete avatars, vehicles, weapons, shopping malls, and applications for all those advanced features that curious people screw everyone else up with while they experiment. The finished product would have to include a complete set of sample textures, scripts, animations, etc., along with usage tips for at least all the common RL tools, like Photoshop, Blender, Qavimator, and so on. Links to other websites like Adobe,Cinemacchiato Machinima and all that are great for support, but something that has a unified Look & Feel has to happen first. If people already aren't using the material & functionality available, that says the stuff hasn't been made attractive enough, or easy enough to understand, or obviously useful enough for them to be unable to stop themselves from taking advantage of the help & instruction. The point is, if we want people to behave and do things right, it's not all that productive to just expect them to figure it all out for themselves, especially when there's so much bad info going around - some of it produced by people with social adjustment issues and plain malicious intent. And, it's kinda rude to tell someone to take their whatever and go hang out in another sim without trying to help them learn how to do better. Not having enough understanding just creates resentment and more unhelpful behavior. Sorry about the long message. - AK On 28 September 2010 11:20, Ann Otoole ___ 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
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
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
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
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
-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
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
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
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
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
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
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
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
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
> 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
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
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
* 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
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
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
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
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
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 >u
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
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
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
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
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
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 <mailto:miss_c...@yahoo.com>> 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
<mailto: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 ab
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
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
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] 2.0 Absolute Dealbreaker - script count feature request
On 09/29/2010 07: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. Don't overcomplicate things. Just count mono scripts as 16k as well. The average size of them is less than 16k, so it's still a conservative number. We don't need perfection. The person with 255 scripts in each shoe will still show up as using a lot. Splitting hairs over kilobyte perfect accuracy is pointless. -Jason ___ 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
On Oct 1, 2010, at 12:50 PM, Gigs wrote: > On 09/29/2010 07: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. > > > Don't overcomplicate things. Just count mono scripts as 16k as well. > The average size of them is less than 16k, so it's still a conservative > number. > > We don't need perfection. The person with 255 scripts in each shoe will > still show up as using a lot. Splitting hairs over kilobyte perfect > accuracy is pointless. > I don't actually have an opinion about the right answer, but I will note that if this is going to be used for things like banning people, then we can't ever change it to be something accurate later. The pattern we see is: * We build something that has a numeric limit * Someone builds something that pushes right to the limit * We change something, and the thing that used to work no longer works * People scream that we broke content So if we create a call that returns approximate results now, it *always* has to return the same results. This is one reason we are reluctant to add new measurements; people come to depend on them even when they shouldn't. Q ___ 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
On Fri, Oct 1, 2010 at 12:50 PM, Gigs wrote: > > > Don't overcomplicate things. Just count mono scripts as 16k as well. > The average size of them is less than 16k, so it's still a conservative > number. > > We don't need perfection. The person with 255 scripts in each shoe will > still show up as using a lot. Splitting hairs over kilobyte perfect > accuracy is pointless. > > Good point. So, maybe a simple interface would be to provide number of mono scripts and number of non-mono scripts. User could make his own memory per script estimates and multiply to get memory estimate, if needed. ___ 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
On Fri, Oct 1, 2010 at 1:07 PM, Kent Quirk (Q Linden) wrote: > > > > I don't actually have an opinion about the right answer, but I will note > that if this is going to be used for things like banning people, then we > can't ever change it to be something accurate later. The pattern we see is: > > * We build something that has a numeric limit > * Someone builds something that pushes right to the limit > * We change something, and the thing that used to work no longer works > * People scream that we broke content > > So if we create a call that returns approximate results now, it *always* > has to return the same results. > > At some point (sooner better than later) SL has to start obsoleting old ways of doing things. To my way of thinking, it is better to obsolete a little bit overy so often rather than keep backwad compatibility until you have to break a lot at once. ___ 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
> * We change something, and the thing that used to work no longer works > * People scream that we broke content > So if we create a call that returns approximate results now, it *always* has > to return the same results. Q, in this case, I disagree. Changing the SCRIPT_MEMORY reports later will not technically break content, it would just requires to slightly alter the interpretation of it. Modifying the cap variables for event(s) to lower numbers, is the only things at stake here. If you put the information out on the wiki right away, as to what to expect of the function in the future. I would see no valid reason for anyone to whine about such a change later on if informed prior. The change can also be planned ahead in our code and work seamlessly with no issues along the way, if you are certain as to what the changes will be. (e.g. if the number is not longer a strict multiple of 16, then apply different rules...done!) As long as it is planned carefully and followed through to the end goal, that seems fine to me on the short to medium term. > This is one reason we are reluctant to add new measurements; people come to > depend on them even when they shouldn't. Understandable view on your side... but the facts that some people don't have the proper judgment or skills to rely or analyze statistics accurately, shouldn't be a reason to deprive those who can use it properly as well as ethically, with valid and useful reasons for doing so. On 10/1/10 10:07 AM, "Kent Quirk (Q Linden)" wrote: > I don't actually have an opinion about the right answer, but I will note that > if this is going to be used for things like banning people, then we can't ever > change it to be something accurate later. The pattern we see is: > > * We build something that has a numeric limit > * Someone builds something that pushes right to the limit > * We change something, and the thing that used to work no longer works > * People scream that we broke content ___ 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
I hate to break in like this, but we're discussing how inaccurate it is for Mono scripts to contribute a different multiple than LSL scripts, but in the end aren't we just counting scripts? Would it be more accurate to report a script count and let the user do whatever multiple they want, and then later when there's a better number out there for memory usage release that as a new number? If any assumptions are made by the scriptor at that point they know where the accuracy lies... ___ 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
Am Samstag 02 Oktober 2010 03:19:13 schrieb Bryon Ruxton: > Q, in this case, I disagree. Changing the SCRIPT_MEMORY reports later will > not technically break content, it would just requires to slightly alter the > interpretation of it. Modifying the cap variables for event(s) to lower You never worked in customer support, did you? :P > Understandable view on your side... but the facts that some people don't > have the proper judgment or skills to rely or analyze statistics > accurately, shouldn't be a reason to deprive those who can use it properly > as well as ethically, with valid and useful reasons for doing so. Even people who know what they are doing can't do anything with the numbers reported. You don't know how much memory a Mono script uses, so it's of no use to you how many scripts there are inside an object. The avatar with 200 scripts on them might actually use less memory and CPU time than another avatar with 20 scripts on them. Unless we get *proper* metrics on cpu time and memory consumption, all this talk about script conut and memory is utterly useless and will only confuse people and lead to drama. 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
On Sat, Oct 2, 2010 at 4:43 AM, Zi Ree wrote: > Am Samstag 02 Oktober 2010 03:19:13 schrieb Bryon Ruxton: > > Unless we get *proper* metrics on cpu time and memory consumption, all this > talk about script conut and memory is utterly useless and will only confuse > people and lead to drama. > > There is "right", and there is "soon". A function that returns the number of scripts is not *wrong*, and it sounds like it should be easy. The right functions will take longer. Adding better functions later does not break any content. Don't let the perfect drive out the good. lee ___ 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
Am Samstag 02 Oktober 2010 schrieb Ponzu: > On Sat, Oct 2, 2010 at 4:43 AM, Zi Ree wrote: > > Am Samstag 02 Oktober 2010 03:19:13 schrieb Bryon Ruxton: > > > > Unless we get *proper* metrics on cpu time and memory > > consumption, all this talk about script conut and memory is > > utterly useless and will only confuse people and lead to drama. > > There is "right", and there is "soon". A function that returns the > number of scripts is not *wrong*, and it sounds like it should be > easy. The right functions will take longer. Adding better > functions later does not break any content. > > Don't let the perfect drive out the good. > > lee phoenix already does that, in its radar you can define a warning that tells you when the script count in the sim changes by more than a threshold that you define... so there already _is_ a way to count all scripts in a sim. bye, LC ___ 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
THANK YOU, what he said. Why lie and make up some weird inaccurate number to leave people guessing, just give us a script counter, LOL. From: Erik Anderson To: Bryon Ruxton Cc: opensource-dev@lists.secondlife.com Sent: Fri, October 1, 2010 9:05:41 PM Subject: Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request I hate to break in like this, but we're discussing how inaccurate it is for Mono scripts to contribute a different multiple than LSL scripts, but in the end aren't we just counting scripts? Would it be more accurate to report a script count and let the user do whatever multiple they want, and then later when there's a better number out there for memory usage release that as a new number? If any assumptions are made by the scriptor at that point they know where the accuracy lies... ___ 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
On Sat, Oct 2, 2010 at 12:34 PM, miss c wrote: > THANK YOU, what he said. Why lie and make up some weird inaccurate number > to leave people guessing, just give us a script counter, LOL. > what i would suggest is 1 have a way to see TOTAL scripts LSL scripts and Mono scripts 2 if any ARC type number is used then guess LOW 3 figure out ways that can be found to make scripts obsolete (skirt sitter and resize scripts are the Low Hanging Fruit on this one) -- Robert L Martin btw could somebody please set the Reply To: flag correctly??? ___ 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
On Sat, 2010-10-02 at 10:43 +0200, Zi Ree wrote: > Unless we get *proper* metrics on cpu time and memory consumption, all this > talk about script conut and memory is utterly useless and will only confuse > people and lead to drama. One approach is to use a cost-per-LSLcall function to generate a "CPU Cost", in a notionally similar way to how avatar rendering cost is calculated for geometry. The Cost table could even be 1+delay where delay is the number of seconds of delay already imposed on the call. Cost Per Script Scan the tokens present in the compiled script against a weighted list of cost-per-LSLfunction for "estimated load". Track actual min, max, and average CPU and memory resources consumed over time. Cost Per Object Add the resource costs for all the scripts present in all prims of an object for a total cost for that object. Track and update the min, max and average for the object. Cost Per Avatar Add all the costs of scripted objects, attachments and huds to generate a total cost per avatar on the simulator. Total all resources used, and update min, max and average by avatar. Cost Per Region I would also suggest a total CPU and Memory cost by avatar in a region in addition to the existing Top Scripts and Top Colliders reports. In the Estate/Region Debug menu, would benefit from a "Total Cost by Object Owner" report - Show the total costs and memory consumed by the avatar in the region along WITH all of their objects separately and together. This way, a lightweight avatar with 1000 objects can be truly measured by "total load" against a heavyweight avatar (tons of attachments) with few objects. Give people the tools to see weighted CPU costs, Memory costs and rudimentary profiling of those metrics over time rather than just the point in time snapshots. -- Robert "Exile In Paradise" Murphey Remember, there's a big difference between kneeling down and bending over. - Frank Zappa ___ 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
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. ___ 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
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
On 2010-10-02, at 20:47, Kelly Linden wrote: > On Sat, Oct 2, 2010 at 4:40 PM, Argent Stonecutter > wrote: >> 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. I know they do. That's why I was asking if that could be changed. Have a script size box in the script editor, when you compile you can select 1k, 2k, 4k... up to 16k. That could potentially save a lot of memory... megabytes for locations with lots of scripted furniture. ___ 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
Am Samstag 02 Oktober 2010 16:49:48 schrieb Lance Corrimal: > phoenix already does that, in its radar you can define a warning that > tells you when the script count in the sim changes by more than a > threshold that you define... so there already _is_ a way to count all > scripts in a sim. Counting scripts on the sim is part of the sim stats (ctrl shift 1), we're talking about per object or per avatar. 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
Am Sonntag 03 Oktober 2010 schrieb Zi Ree: > Am Samstag 02 Oktober 2010 16:49:48 schrieb Lance Corrimal: > > phoenix already does that, in its radar you can define a warning > > that tells you when the script count in the sim changes by more > > than a threshold that you define... so there already _is_ a way > > to count all scripts in a sim. > > Counting scripts on the sim is part of the sim stats (ctrl shift > 1), we're talking about per object or per avatar. Ah... didn't see that part. ___ 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 !!!!!!!
This is why we need it [12:52] Counted scripts from 19 attachments on Sxt Cxxx: 1102 ___ 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 !!!!!!!
On Sun, Oct 3, 2010 at 3:59 PM, miss c wrote: > This is why we need it > > [12:52] Counted scripts from 19 attachments on Sxt Cxxx: 1102 > > > I suggest a different approach. Enable health/damage in your sim, and then *kill* 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
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. ___ 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
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
