From carlo at alinoe.com Tue Dec 1 00:36:17 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 1 Dec 2009 09:36:17 +0100 Subject: [sldev] Snowglobe 1.2 RC coming soon In-Reply-To: <78f69850911302225n58186fadu72a5c172ce34239a@mail.gmail.com> References: <20091111200818.8c9d8d15.tayra.dagostino@gmail.com> <78f69850911111204p77739c60h9c5e3139db55e911@mail.gmail.com> <20091111212616.8a38944a.tayra.dagostino@gmail.com> <2f496d03e9d9329ae58cf8935c4b915d@localhost> <20091112195954.c85896c0.tayra.dagostino@gmail.com> <4AFC6007.6070506@lindenlab.com> <78f69850911302225n58186fadu72a5c172ce34239a@mail.gmail.com> Message-ID: <20091201083617.GA21202@alinoe.com> On Mon, Nov 30, 2009 at 10:25:02PM -0800, Philippe (Merov) Bossut wrote: > This is indeed a really pesky bug though not a "Snowglobe" specific one. It's > affecting Lindens as well for sure so it's not like it's not on our radar, it's > just that fixing it will require a major rewrite of the baking system. This sounds like you already know what is the problem. > If someone could identify a 100% (or even 90%...) repro path that would help > tremendously identifying a fix though. This sounds like you have no idea what is the problem. I'm assuming the latter, and therefore would like to remark that it probably does NOT require a major rewrite of the baking system. Clearly, the same video memory is being used for the desktop redraw as is being used for the baking and some race condition (wrong locking?) is causing this to sometimes happen. -- Carlo Wood From suzyque at gmail.com Tue Dec 1 04:52:27 2009 From: suzyque at gmail.com (Suzy Deffeyes) Date: Tue, 1 Dec 2009 06:52:27 -0600 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: <4B141E30.4040408@fishkill.ibm.com> References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> Message-ID: I'd also like to see: 1. Map tile URL as a cap instead of hardcoded to amazon (if the cap isn't returned, it can default to current amazon URL ) 2. Text translation URL specified as a cap instead of current hardcoded to google translate ( and same deal on defaulting to current hardcoded value if no cap is returned ) 3. OGPX- allow agent domain library using existing FetchLib viewer code (SNOW-350) 4. OGPX - create some caps infrastructure code ( I'll be providing a patch for this if I can ever get some quality time with my compiler ). As we create more caps in the viewer, we need some code to manage them. 5. Something like SNOW-129 account name saving. This is handy when popping between different alts or different grids. Would like a redoodle of the patch so it integrates well with OGPX. Suzy Deffeyes / Pixel Gausman IBM Sent from my iPhone On Nov 30, 2009, at 1:34 PM, Mike Monkowski wrote: > Continuing the discussion from the last Open Source meeting: > >> # [15:04] Merov Linden: well, I got a bunch of action items from >> this meeting and directions for 1.3 >> # [15:04] Mojito Sorbet: Merov, that works only provided that where >> you want to end up is in the same direction. >> # [15:04] Merov Linden: we should continue the discussion on sldev > > My suggestions (not necessarily in order by priority) are: > > 1. Merge the puppeteering branch in as a first step toward creating > animations in-world. > 2. Support for MS Visual Studio 2008 and 2010 beta. Yep, two > versions > behind, time to migrate. > 3. Support for 64 bit. > > Mike > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From secret.argent at gmail.com Tue Dec 1 06:29:08 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue, 1 Dec 2009 08:29:08 -0600 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> Message-ID: <6BC7EA64-287B-4CEF-8BBF-A16AD5CCE553@gmail.com> I have another suggestion... pick up some of the JIRA-ed fixes that Emerald has already picked up, like the extra attachment points and the text dialog and the multiple account support... get this stuff into a Linden-supported viewer. It's embarrassing. From secret.argent at gmail.com Tue Dec 1 06:38:23 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue, 1 Dec 2009 08:38:23 -0600 Subject: [sldev] Snowglobe 1.2 RC coming soon In-Reply-To: <20091201083617.GA21202@alinoe.com> References: <20091111200818.8c9d8d15.tayra.dagostino@gmail.com> <78f69850911111204p77739c60h9c5e3139db55e911@mail.gmail.com> <20091111212616.8a38944a.tayra.dagostino@gmail.com> <2f496d03e9d9329ae58cf8935c4b915d@localhost> <20091112195954.c85896c0.tayra.dagostino@gmail.com> <4AFC6007.6070506@lindenlab.com> <78f69850911302225n58186fadu72a5c172ce34239a@mail.gmail.com> <20091201083617.GA21202@alinoe.com> Message-ID: <115CB1A3-0BCD-4BF6-9DE2-9F184A3176ED@gmail.com> Even if you can't figure out how to fix this one... how about making "Rebake Textures" work without having to go into appearance and select a modifiable wearable first? From lenglish5 at cox.net Tue Dec 1 08:41:59 2009 From: lenglish5 at cox.net (Lawson English) Date: Tue, 01 Dec 2009 09:41:59 -0700 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: <4B141E30.4040408@fishkill.ibm.com> References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> Message-ID: <4B154757.3050903@cox.net> Mike Monkowski wrote: > Continuing the discussion from the last Open Source meeting: > > >> # [15:04] Merov Linden: well, I got a bunch of action items from this meeting and directions for 1.3 >> # [15:04] Mojito Sorbet: Merov, that works only provided that where you want to end up is in the same direction. >> # [15:04] Merov Linden: we should continue the discussion on sldev >> > > My suggestions (not necessarily in order by priority) are: > > 1. Merge the puppeteering branch in as a first step toward creating > animations in-world. > 2. Support for MS Visual Studio 2008 and 2010 beta. Yep, two versions > behind, time to migrate. > 3. Support for 64 bit. > Along with the puppeteering branch should be a way of accessing the puppeteering related events/packets/data/gui elements/whatevers from a plugin interface. http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Puppeteering_Plugin YACOMTMOH (Yet Another Case Of Me Tooting My Own Horn) Lawson (YACOMTMOH Lives! would make a great bumper sticker. Confuse all the Cthulhuists to no end) From lenglish5 at cox.net Tue Dec 1 08:48:57 2009 From: lenglish5 at cox.net (Lawson English) Date: Tue, 01 Dec 2009 09:48:57 -0700 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: <4B146FAD.6010904@gmail.com> References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> <1e01733d0911301438j27667b12ib976dee5436ac6d0@mail.gmail.com> <4B144EEF.5020601@gmail.com> <1e01733d0911301536j32f33a8axc5a310644a65e4c2@mail.gmail.com> <4B146FAD.6010904@gmail.com> Message-ID: <4B1548F9.8060609@cox.net> Dzonatas Sol wrote: > Sorry, I never intended to call your proposal bloat, as it wasn't the > proposal itself I didn't consider bloat. > > The built-in UI would need many hooks to support a plugin for such > features. If the UI is externalized into a plugin, then none of those > specific hooks would be needed to be programmed within the viewer > itself, especially if the UI used the OS's default windows system. > D.N.S., for example, already knows how to manipulate Windows. > > I meant bloat in the sense of maintenance of features in a monolithic > code base... specifically the merges/rebase. The plugin idea, as you > propose, could be a specially designed UI that works with well D.N.S. > > With the UI code moved into a plugin, this would avoid the special > #if-#then-#else cases for desired features. Instead of a recompile with > different option... load a different UI plugin. That's what I meant. > > I just took your proposal and pushed it a little further to suggest the > entire UI be put into a plugin. > > Cheers > There's at least two levels of HI interface that can be exposed: low-level mouse/keyboard/interface events and high-level user events. Most people think in terms of the low-level events. Far more interesting, to me are the high-level events based on user actions. E.G. Login (name, password [location]), TP (destination), Give Item (item) etc. Those can be made cross-viewer and allow at least some level of cross-platform scripting. Other kinds of events suitable for exposure for a plugin include any/all standard packets. No doubt others are appropriate as well such as the ability to generate GUI elements such as handles and rotation widgets on the scene-graph ala what the puppeteering controls use. (for standard GUI stuff, just go with what Zero suggested ages ago: use xhtml and a webbrowser connected either to local host or to a remote service with nifty new features). Lawson From lenglish5 at cox.net Tue Dec 1 08:50:28 2009 From: lenglish5 at cox.net (Lawson English) Date: Tue, 01 Dec 2009 09:50:28 -0700 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: <6BC7EA64-287B-4CEF-8BBF-A16AD5CCE553@gmail.com> References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> <6BC7EA64-287B-4CEF-8BBF-A16AD5CCE553@gmail.com> Message-ID: <4B154954.9010607@cox.net> Argent Stonecutter wrote: > I have another suggestion... pick up some of the JIRA-ed fixes that > Emerald has already picked up, like the extra attachment points and > the text dialog and the multiple account support... get this stuff > into a Linden-supported viewer. It's embarrassing. > Not to mention: steal shamelessly from realXtend. Lawson From nlockwoo at indiana.edu Tue Dec 1 08:57:20 2009 From: nlockwoo at indiana.edu (Lockwood, Nick) Date: Tue, 1 Dec 2009 11:57:20 -0500 Subject: [sldev] [HELP] Using message system to get object properties In-Reply-To: References: <841E8DEDB041C74293817CC4662BA05A0AE8892497@iu-mssg-mbx07.ads.iu.edu> Message-ID: <841E8DEDB041C74293817CC4662BA05A0AE88927D4@iu-mssg-mbx07.ads.iu.edu> Thanks for the response! I finally got it to work... I totally missed the callback function (obviously I didn't know much about the messaging system). You were right. All it took was adding a line to the processObjectPropertiesFamily function to capture that data. ************************************************************* The response message is ObjectProperties. Search the source for _PREHASH_ObjectProperties and you see where a callback is set using LLMessageSystem::setHandlerFuncFast. It's LLSelectMgr::processObjectProperties. You can either add a line in there to call your other function, or look into something like the patch here that would allow you to register multiple handlers: http://jira.secondlife.com/browse/VWR-2546 But, if you only want the object name, RequestObjectPropertiesFamily and its reply ObjectPropertiesFamily are cooler because you won't have to deselect the object! On Mon, Nov 30, 2009 at 10:37 AM, Lockwood, Nick > wrote: I'm writing some (fairly simple) custom code to log what object is at a particular position on the screen every x seconds. I can successfully get an object and output it's Id, number of faces, etc. But, here is my problem... I really want to log the name of the object. Looking at the code, it seems that this requires sending a message request to the server. I've been trying to utilize some of the code in the LLSelectMgr class, specifically in the selectObjectOnly() function. I can't seem to get it to work, and I don't really want to use LLSelectMgr. I want my code to be completely separate from other core aspects of the viewer. So, how would I go about using the messenger? I guess where I'm getting confused is where it runs gMessageSystem->sendReliable( regionp->getHost());.Where is the response message to that stored? Any help would be greatly appreciated. Thanks! Nick _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091201/64ff451b/attachment-0001.htm From nyx at lindenlab.com Tue Dec 1 08:59:45 2009 From: nyx at lindenlab.com (Nyx Linden) Date: Tue, 01 Dec 2009 11:59:45 -0500 Subject: [sldev] Bad avatar baked textures (was: Re: Snowglobe 1.2 RC coming soon) In-Reply-To: <115CB1A3-0BCD-4BF6-9DE2-9F184A3176ED@gmail.com> References: <20091111200818.8c9d8d15.tayra.dagostino@gmail.com> <78f69850911111204p77739c60h9c5e3139db55e911@mail.gmail.com> <20091111212616.8a38944a.tayra.dagostino@gmail.com> <2f496d03e9d9329ae58cf8935c4b915d@localhost> <20091112195954.c85896c0.tayra.dagostino@gmail.com> <4AFC6007.6070506@lindenlab.com> <78f69850911302225n58186fadu72a5c172ce34239a@mail.gmail.com> <20091201083617.GA21202@alinoe.com> <115CB1A3-0BCD-4BF6-9DE2-9F184A3176ED@gmail.com> Message-ID: <4B154B81.6000505@lindenlab.com> The bug happens when your client is trying to rebake your avatar's textures and you're doing something with the window (minimizing, switching windows, etc). Since we use the screenbuffer for our dynamic textures, its unavoidable that this would result in a bad bake. Unfortunately there isn't an easy way to detect this case either. The long-term solution is to change our dynamic texture system to use off-screen buffers for texture readbacks. While not requiring a complete re-write of the avatar baking system, this is non-trivial to do. I've already written a shorter-term solution, which is to draw a black rectangle over the relevant area of the window to prevent the UI from appearing on the bake. I can port this over to snowglobe later this week if there is interest in testing this out. "Rebake textures" should still trigger an upload of your avatar's baked textures. Is there sufficient reason to believe that we're using cached versions (whether server or client-side) of the bakes even when you manually specify "rebake textures"? -Nyx Argent Stonecutter wrote: > Even if you can't figure out how to fix this one... how about making > "Rebake Textures" work without having to go into appearance and select > a modifiable wearable first? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From kck325 at gmail.com Tue Dec 1 09:25:34 2009 From: kck325 at gmail.com (chandra kiran kuchi) Date: Tue, 1 Dec 2009 12:25:34 -0500 Subject: [sldev] [Info Request] Are there softwares that can record second life stream? Message-ID: Can I record the second life stream for a specific amount of time and play it back? -- Regards, Chandra K Kuchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091201/34d5146a/attachment.htm From monkowsk at fishkill.ibm.com Tue Dec 1 09:34:52 2009 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Tue, 01 Dec 2009 12:34:52 -0500 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: <4B154757.3050903@cox.net> References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> <4B154757.3050903@cox.net> Message-ID: <4B1553BC.6060505@fishkill.ibm.com> Lawson English wrote: > Along with the puppeteering branch should be a way of accessing the > puppeteering related events/packets/data/gui elements/whatevers from a > plugin interface. > > http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Puppeteering_Plugin Are you volunteering to build a plugin interface for it or is this just a wish for someone else to do it? If the former, then you should describe your interface in more detail so others could comment on it. If the latter, then you misunderstand the purpose of the Snowglobe branch. Snowglobe incorporates code that has already been written and tested. It is a good idea to discuss here what you intend to write, but the implication is that you do intend to implement it if there is general approval. Mike From tayra.dagostino at gmail.com Tue Dec 1 10:12:41 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Tue, 1 Dec 2009 19:12:41 +0100 Subject: [sldev] [Info Request] Are there softwares that can record second life stream? In-Reply-To: References: Message-ID: <20091201191241.ced33dea.tayra.dagostino@gmail.com> On Tue, 1 Dec 2009 12:25:34 -0500 chandra kiran kuchi wrote: > Can I record the second life stream for a specific amount of time and > play it back? yes for wich OS? From kck325 at gmail.com Tue Dec 1 10:57:38 2009 From: kck325 at gmail.com (chandra kiran kuchi) Date: Tue, 1 Dec 2009 13:57:38 -0500 Subject: [sldev] [Info Request] Are there softwares that can record second life stream? In-Reply-To: <20091201191241.ced33dea.tayra.dagostino@gmail.com> References: <20091201191241.ced33dea.tayra.dagostino@gmail.com> Message-ID: Linux (Debian) Is it glc? On Tue, Dec 1, 2009 at 1:12 PM, Tayra Dagostino wrote: > On Tue, 1 Dec 2009 12:25:34 -0500 > chandra kiran kuchi wrote: > > > Can I record the second life stream for a specific amount of time and > > play it back? > > yes > > for wich OS? > -- Regards, Chandra K Kuchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091201/6a385313/attachment.htm From kck325 at gmail.com Tue Dec 1 10:57:51 2009 From: kck325 at gmail.com (chandra kiran kuchi) Date: Tue, 1 Dec 2009 13:57:51 -0500 Subject: [sldev] [Info Request] Are there softwares that can record second life stream? In-Reply-To: <20091201191241.ced33dea.tayra.dagostino@gmail.com> References: <20091201191241.ced33dea.tayra.dagostino@gmail.com> Message-ID: Linux (Debian) Is it glc? On Tue, Dec 1, 2009 at 1:12 PM, Tayra Dagostino wrote: > On Tue, 1 Dec 2009 12:25:34 -0500 > chandra kiran kuchi wrote: > > > Can I record the second life stream for a specific amount of time and > > play it back? > > yes > > for wich OS? > -- Regards, Chandra K Kuchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091201/b55d40b0/attachment.htm From tayra.dagostino at gmail.com Tue Dec 1 11:31:03 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Tue, 1 Dec 2009 20:31:03 +0100 Subject: [sldev] [Info Request] Are there softwares that can record second life stream? In-Reply-To: References: <20091201191241.ced33dea.tayra.dagostino@gmail.com> Message-ID: <20091201203103.64b1afe4.tayra.dagostino@gmail.com> On Tue, 1 Dec 2009 13:57:38 -0500 chandra kiran kuchi wrote: > Linux (Debian) > > Is it glc? XVidCap turn off online/offline notification, payment bubble, put your AV in busy mode, resize capture area without AO or huds, move with cam control che cam (or use a 3dconnxion mouse) but a feature to record stream (without hud or UI) will be a great feature :) From lenglish5 at cox.net Tue Dec 1 12:41:27 2009 From: lenglish5 at cox.net (Lawson English) Date: Tue, 01 Dec 2009 13:41:27 -0700 Subject: [sldev] [Info Request] Are there softwares that can record second life stream? In-Reply-To: <20091201191241.ced33dea.tayra.dagostino@gmail.com> References: <20091201191241.ced33dea.tayra.dagostino@gmail.com> Message-ID: <4B157F77.9020700@cox.net> Tayra Dagostino wrote: > On Tue, 1 Dec 2009 12:25:34 -0500 > chandra kiran kuchi wrote: > > >> Can I record the second life stream for a specific amount of time and >> play it back? >> > > yes > > for wich OS? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > Really? Do you mean raw packets or video from a viewer or...? Lawson From ashea at ups.com Tue Dec 1 13:16:42 2009 From: ashea at ups.com (ashea at ups.com) Date: Tue, 1 Dec 2009 16:16:42 -0500 Subject: [sldev] Lightwave Import? Message-ID: <3394857ACC84B34AB30C98F662DAD64F2572F0E37E@njrarsvr3bef.us.ups.com> What is the best way to get a lightwave object into SL? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091201/a4913907/attachment.htm From secret.argent at gmail.com Tue Dec 1 18:37:05 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue, 1 Dec 2009 20:37:05 -0600 Subject: [sldev] Bad avatar baked textures (was: Re: Snowglobe 1.2 RC coming soon) In-Reply-To: <4B154B81.6000505@lindenlab.com> References: <20091111200818.8c9d8d15.tayra.dagostino@gmail.com> <78f69850911111204p77739c60h9c5e3139db55e911@mail.gmail.com> <20091111212616.8a38944a.tayra.dagostino@gmail.com> <2f496d03e9d9329ae58cf8935c4b915d@localhost> <20091112195954.c85896c0.tayra.dagostino@gmail.com> <4AFC6007.6070506@lindenlab.com> <78f69850911302225n58186fadu72a5c172ce34239a@mail.gmail.com> <20091201083617.GA21202@alinoe.com> <115CB1A3-0BCD-4BF6-9DE2-9F184A3176ED@gmail.com> <4B154B81.6000505@lindenlab.com> Message-ID: On 2009-12-01, at 10:59, Nyx Linden wrote: > "Rebake textures" should still trigger an upload of your avatar's > baked textures. Is there sufficient reason to believe that we're > using cached versions (whether server or client-side) of the bakes > even when you manually specify "rebake textures"? I have rarely been able to "clear" any kind of messed up avatar textures simply by doing "rebake" without mucking about in appearance. I don't know if the bakes are being cached or the in-vram copies of the textures are being trashed. The current situation is better than it has been, at one point I had to actually change some setting on a wearable to get a good rebake. It doesn't matter whether it's the stock viewer, a modified one, or snowglobe. This has been the norm for at least a couple of years. From lenglish5 at cox.net Tue Dec 1 19:48:16 2009 From: lenglish5 at cox.net (Lawson English) Date: Tue, 01 Dec 2009 20:48:16 -0700 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: <4B1553BC.6060505@fishkill.ibm.com> References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> <4B154757.3050903@cox.net> <4B1553BC.6060505@fishkill.ibm.com> Message-ID: <4B15E380.7040406@cox.net> Mike Monkowski wrote: > Lawson English wrote: >> Along with the puppeteering branch should be a way of accessing the >> puppeteering related events/packets/data/gui elements/whatevers from >> a plugin interface. >> >> http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Puppeteering_Plugin > > > Are you volunteering to build a plugin interface for it or is this > just a wish for someone else to do it? If the former, then you should > describe your interface in more detail so others could comment on it. > If the latter, then you misunderstand the purpose of the Snowglobe > branch. Snowglobe incorporates code that has already been written and > tested. It is a good idea to discuss here what you intend to write, > but the implication is that you do intend to implement it if there is > general approval. Busy learning squeak smalltalk right now (reimplementing my python presence code in squeak) http://wiki.secondlife.com/wiki/Example_protocol_code Once I get more proficient in smalltalk, its off to C# to figure out how to connect squeak to gridproxy, and then to connect squeak to the SL media plugin API (see proposed plugin extension for how it will eventually work http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion) After that, it should be a pretty kool prototyping system for testing new ideas about SL, including new APIs for plugins and the like. Lawson From merov at lindenlab.com Tue Dec 1 21:59:16 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 1 Dec 2009 21:59:16 -0800 Subject: [sldev] Bad avatar baked textures (was: Re: Snowglobe 1.2 RC coming soon) In-Reply-To: <4B154B81.6000505@lindenlab.com> References: <20091111212616.8a38944a.tayra.dagostino@gmail.com> <2f496d03e9d9329ae58cf8935c4b915d@localhost> <20091112195954.c85896c0.tayra.dagostino@gmail.com> <4AFC6007.6070506@lindenlab.com> <78f69850911302225n58186fadu72a5c172ce34239a@mail.gmail.com> <20091201083617.GA21202@alinoe.com> <115CB1A3-0BCD-4BF6-9DE2-9F184A3176ED@gmail.com> <4B154B81.6000505@lindenlab.com> Message-ID: <78f69850912012159q326c3fbei69c2d0cc7b1b303e@mail.gmail.com> Hi, Thanks Nyx for the detail write up. This is great. Getting the "black rectangle" fix would at least mitigate the privacy/embarrassment problem residents have been reporting so +1 on that. Cheers, - Merov On Tue, Dec 1, 2009 at 8:59 AM, Nyx Linden wrote: > The bug happens when your client is trying to rebake your avatar's > textures and you're doing something with the window (minimizing, > switching windows, etc). Since we use the screenbuffer for our dynamic > textures, its unavoidable that this would result in a bad bake. > Unfortunately there isn't an easy way to detect this case either. > > The long-term solution is to change our dynamic texture system to use > off-screen buffers for texture readbacks. While not requiring a complete > re-write of the avatar baking system, this is non-trivial to do. I've > already written a shorter-term solution, which is to draw a black > rectangle over the relevant area of the window to prevent the UI from > appearing on the bake. I can port this over to snowglobe later this week > if there is interest in testing this out. > > "Rebake textures" should still trigger an upload of your avatar's baked > textures. Is there sufficient reason to believe that we're using cached > versions (whether server or client-side) of the bakes even when you > manually specify "rebake textures"? > > -Nyx > > Argent Stonecutter wrote: > > Even if you can't figure out how to fix this one... how about making > > "Rebake Textures" work without having to go into appearance and select > > a modifiable wearable first? > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > privileges > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091201/d563e83a/attachment.htm From merov at lindenlab.com Tue Dec 1 22:11:21 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 1 Dec 2009 22:11:21 -0800 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: <4B141E30.4040408@fishkill.ibm.com> References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> Message-ID: <78f69850912012211p3032e2bn4bf277eb94a8e47e@mail.gmail.com> Hi Mike, Thanks for starting this thread first :) On Mon, Nov 30, 2009 at 11:34 AM, Mike Monkowski wrote: > 1. Merge the puppeteering branch in as a first step toward creating > animations in-world. > My own personal contrib to this (https://jira.secondlife.com/browse/VWR-7703in a former life...) is still up in limbo and all that code is 1.18 base. A really serious endeavor. I'm a fan of puppeteering as you know but, then again, is that what folks on that list think the priority should be? IOW, would that be the feature that would drive folks to use Snowglobe and contribute to it? > 2. Support for MS Visual Studio 2008 and 2010 beta. Yep, two versions > behind, time to migrate. > I'm wondering how much cmake work there is really. Anyone to try and post a patch? > 3. Support for 64 bit. We do support 64 bit if I'm not mistaken but we don't build and provide binaries if that's what you mean here. It's not so much the coding work that makes me shy away but the monitoring of yet another batch of builds (and fixing that requires). May be we should start with 64 bit Windows as this is the one that seems to be really in demand. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091201/d8ce3ba6/attachment.htm From merov at lindenlab.com Tue Dec 1 22:13:02 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 1 Dec 2009 22:13:02 -0800 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> Message-ID: <78f69850912012213m790c1edch40a9c3ca13a868ae@mail.gmail.com> Hi, On Mon, Nov 30, 2009 at 12:33 PM, Opensource Obscure wrote: > Ctrl-Alt-F1 Hide/Show UI Does Not Work Correctly Under Linux > https://jira.secondlife.com/browse/VWR-2085 > This is a 1-line change that would give back Linux users > a usable shortcut to hide UI and make it reappear. > A wider shortcuts redesign is supposed to be in progress, > but it's taking forever; I love to hide everything > (menus, floaters etc.) to visually enjoy Second Life, > but this bug prevents me and other Linux users to > do that, since Aug 2007 (unless you recompile sources). > > (I guess I should create a new SNOW-xxx issue for this > one to be considered in Snowglobe, right? thanks) > Yes please ! :) - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091201/143eec85/attachment.htm From merov at lindenlab.com Tue Dec 1 22:15:24 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 1 Dec 2009 22:15:24 -0800 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> Message-ID: <78f69850912012215qfb597c3k446ce04acafa4d45@mail.gmail.com> Hi, On Mon, Nov 30, 2009 at 2:41 PM, Moriz Gupte wrote: > I have a question, has then been any progress on the single port > solution for Snowglobe? I think LL put out a call for contractors a > while back to deal with the socket programming etc.. This is a make or > break deal for feds who want to use Snowglobe behind their firewall. > Yes, there has been progress on that. I'm waiting for the Linden in charge of this contract to be back (end of the week) to bring that up to the list. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091201/b6d7a0a2/attachment-0001.htm From merov at lindenlab.com Tue Dec 1 22:20:39 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 1 Dec 2009 22:20:39 -0800 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> Message-ID: <78f69850912012220i4b392ff4nb423277926c02812@mail.gmail.com> Hi Suzy / Pixel, Would you mind logging SNOW PJIRA records for those who do not have one? As for OGPX, we'll certainly take your most excellent patches :) Please, keep them coming! Cheers, - Merov On Tue, Dec 1, 2009 at 4:52 AM, Suzy Deffeyes wrote: > I'd also like to see: > 1. Map tile URL as a cap instead of hardcoded to amazon (if the cap isn't > returned, it can default to current amazon URL ) > 2. Text translation URL specified as a cap instead of current hardcoded to > google translate ( and same deal on defaulting to current hardcoded value if > no cap is returned ) > 3. OGPX- allow agent domain library using existing FetchLib viewer code > (SNOW-350) > 4. OGPX - create some caps infrastructure code ( I'll be providing a patch > for this if I can ever get some quality time with my compiler ). As we > create more caps in the viewer, we need some code to manage them. > 5. Something like SNOW-129 account name saving. This is handy when popping > between different alts or different grids. Would like a redoodle of the > patch so it integrates well with OGPX. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091201/e1156efe/attachment.htm From merov at lindenlab.com Tue Dec 1 22:34:45 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 1 Dec 2009 22:34:45 -0800 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: <6BC7EA64-287B-4CEF-8BBF-A16AD5CCE553@gmail.com> References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> <6BC7EA64-287B-4CEF-8BBF-A16AD5CCE553@gmail.com> Message-ID: <78f69850912012234s22c9c852w814d6c4dc8ce1c0@mail.gmail.com> Hi, On Tue, Dec 1, 2009 at 6:29 AM, Argent Stonecutter wrote: > I have another suggestion... pick up some of the JIRA-ed fixes that > Emerald has already picked up, like the extra attachment points and > the text dialog and the multiple account support... get this stuff > into a Linden-supported viewer. It's embarrassing. > +1 (and some!...). Yes, it is embarrassing. There are reasons why some of those patches didn't make it to the official viewer but Snowglobe seems to be a good vector for those (experimental viewer, experimented residents and builders). Snowglobe didn't start historically with "let's take all community contributed patches" mission as you may recall but, right now, that mission might well be a good thing to change. I'm wondering what other folks on this list, especially committers, do think about such a change in direction/mission. Your comment welcome! Note that it's often more than just a matter of committing patches: there's work to adapt those patches to Snowglobe (some are quite ancient) and give them some serious code review. Quite a bit of work so I do hope that people on that list interested by this motion will show up and help. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091201/b2924667/attachment.htm From trilobyte550m at gmail.com Tue Dec 1 23:48:40 2009 From: trilobyte550m at gmail.com (Trilo Byte) Date: Tue, 1 Dec 2009 23:48:40 -0800 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: <78f69850912012211p3032e2bn4bf277eb94a8e47e@mail.gmail.com> References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> <78f69850912012211p3032e2bn4bf277eb94a8e47e@mail.gmail.com> Message-ID: Believe me, there is ENORMOUS demand for 64-bit in Linux and Mac. And the general userbase on both those platforms is already in a much better place for 64-bit (since they're already on 64-bit capable OS's, if not currently running in a 64-bit mode - that's got to make it a bit less messy than having the vast majority of users still lagging behind in 32-bit, doesn't it? On Dec 1, 2009, at 10:11 PM, Philippe (Merov) Bossut wrote: > Hi Mike, > > Thanks for starting this thread first :) > > On Mon, Nov 30, 2009 at 11:34 AM, Mike Monkowski wrote: > 1. Merge the puppeteering branch in as a first step toward creating animations in-world. > > My own personal contrib to this (https://jira.secondlife.com/browse/VWR-7703 in a former life...) is still up in limbo and all that code is 1.18 base. A really serious endeavor. I'm a fan of puppeteering as you know but, then again, is that what folks on that list think the priority should be? IOW, would that be the feature that would drive folks to use Snowglobe and contribute to it? > > 2. Support for MS Visual Studio 2008 and 2010 beta. Yep, two versions behind, time to migrate. > > I'm wondering how much cmake work there is really. Anyone to try and post a patch? > > 3. Support for 64 bit. > > We do support 64 bit if I'm not mistaken but we don't build and provide binaries if that's what you mean here. It's not so much the coding work that makes me shy away but the monitoring of yet another batch of builds (and fixing that requires). May be we should start with 64 bit Windows as this is the one that seems to be really in demand. > > Cheers, > - Merov > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091201/9dd8daf5/attachment.htm From stickman at gmail.com Wed Dec 2 00:13:55 2009 From: stickman at gmail.com (Stickman) Date: Wed, 2 Dec 2009 00:13:55 -0800 Subject: [sldev] Lightwave Import? In-Reply-To: <3394857ACC84B34AB30C98F662DAD64F2572F0E37E@njrarsvr3bef.us.ups.com> References: <3394857ACC84B34AB30C98F662DAD64F2572F0E37E@njrarsvr3bef.us.ups.com> Message-ID: http://wiki.secondlife.com/wiki/Sculpted_Prims:_3d_Software_Guide#Lightwave_.28Newtek.29 will point you to http://wiki.secondlife.com/wiki/User:Patchouli_Woollahra/Lightwave_Sculptie_Rendering and http://www.robinwood.com/Catalog/Technical/LightwaveTuts/LWTutSet.html Note I didn't actually read any of those links, so I have no idea how relevant they are, or if it even solves the problem you're having. Stickman On Tue, Dec 1, 2009 at 1:16 PM, wrote: > What is the best way to get a lightwave object into SL? > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From aleric.inglewood at gmail.com Wed Dec 2 03:26:31 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Wed, 2 Dec 2009 12:26:31 +0100 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: <78f69850912012234s22c9c852w814d6c4dc8ce1c0@mail.gmail.com> References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> <6BC7EA64-287B-4CEF-8BBF-A16AD5CCE553@gmail.com> <78f69850912012234s22c9c852w814d6c4dc8ce1c0@mail.gmail.com> Message-ID: <1e01733d0912020326ne8ba58ck7d8a0be634bc0d49@mail.gmail.com> Hi Merov, what about multiple attachments per attachment point? The problem is that the correct way to implement this needs server-side patches too. That is not a reason not to continue, I just mention it to make clear that this is NOT a snowglobe thing. I regret it that we don't have a good communication link with ALL LL developers, only with the handful that is working on snowglobe, or maybe I'm just missing an overview. Is there anyone here who could say: Ok, lets change the server-client protocol? ------------ As for the implementation, what is needed is a new mask (at least 16 bit, but 32 would be nice) that is part of every attachment and which can be changed by the user EVEN on no-mod objects! I lack the knowledge of the server code to know if it's at all possible to add/have a modifiable variable on a no-mod object ... From aleric.inglewood at gmail.com Wed Dec 2 03:38:45 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Wed, 2 Dec 2009 12:38:45 +0100 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: <1e01733d0912020326ne8ba58ck7d8a0be634bc0d49@mail.gmail.com> References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> <6BC7EA64-287B-4CEF-8BBF-A16AD5CCE553@gmail.com> <78f69850912012234s22c9c852w814d6c4dc8ce1c0@mail.gmail.com> <1e01733d0912020326ne8ba58ck7d8a0be634bc0d49@mail.gmail.com> Message-ID: <1e01733d0912020338ke6ed22qb35a244f17519a1c@mail.gmail.com> Hmm, actually - this is not true. What would be needed is just that this mask is added to the messages about actual attachments, between the client and the server. The server only needs to remember the mask for each actually attached attachments per agent and does not have to communicate about that with others (it's a local thing). The change is really very minimal thus. That approach would require the viewer to remember this mask itself (locally, on disk) for every attachment (also those in the inventory); but at least we have full control over THAT. The disadvantage of this approach is that the mask would get lost when an object is transfered; but that isn't really a problem imho: it's really pretty personal configuration data, every user should just choose his/her own setting. [The mask would tell the viewer and server when to remove a given attachment when another attachment is being added: ie, if on attachment point X there is an attachment with a mask 4, and a new attachment is added with mask 3, then both will be attached. And if then another attachment is added with mask 5, then the previous two would be removed because 5 & 4 != 0 and 5 & 3 != 0]. Another disadvantage is that every client would have support seeing multiple attachments on a single attachment point, or the server would have to start doing 'translations' (make one a temporary single object of the several attachments on a single point, and "attach" that towards the rest of the world). On Wed, Dec 2, 2009 at 12:26 PM, Aleric Inglewood wrote: > Hi Merov, > > what about multiple attachments per attachment point? > > The problem is that the correct way to implement this needs > server-side patches too. > That is not a reason not to continue, I just mention it to make clear > that this is NOT > a snowglobe thing. > > I regret it that we don't have a good communication link with ALL LL developers, > only with the handful that is working on snowglobe, or maybe I'm just missing > an overview. Is there anyone here who could say: Ok, lets change the > server-client > protocol? > > ------------ > > As for the implementation, what is needed is a new mask (at least 16 bit, > but 32 would be nice) that is part of every attachment and which can > be changed by the user EVEN on no-mod objects! I lack the knowledge > of the server code to know if it's at all possible to add/have a modifiable > variable on a no-mod object ... > From snowfox102 at dragonkeepcreations.com Wed Dec 2 03:40:42 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Wed, 02 Dec 2009 05:40:42 -0600 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: <1e01733d0912020326ne8ba58ck7d8a0be634bc0d49@mail.gmail.com> References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> <6BC7EA64-287B-4CEF-8BBF-A16AD5CCE553@gmail.com> <78f69850912012234s22c9c852w814d6c4dc8ce1c0@mail.gmail.com> <1e01733d0912020326ne8ba58ck7d8a0be634bc0d49@mail.gmail.com> Message-ID: <4B16523A.9070203@dragonkeepcreations.com> Third party viewers already support multiple attachments per attachment point (and extra attachment points for bones that don't have attachment points in the LL viewers) and do it quite well. Any viewer can have this ability by replacing a particular .xml file with one from a viewer that supports it. I don't know all the particulars, but it's obviously not hard to implement. Personally, I'd like to see avatar alpha masking worked on in Snowglobe, and that stupid HUD alpha bug needed to be fixed months ago. Maya Aleric Inglewood wrote: > Hi Merov, > > what about multiple attachments per attachment point? > > The problem is that the correct way to implement this needs > server-side patches too. > That is not a reason not to continue, I just mention it to make clear > that this is NOT > a snowglobe thing. > > I regret it that we don't have a good communication link with ALL LL developers, > only with the handful that is working on snowglobe, or maybe I'm just missing > an overview. Is there anyone here who could say: Ok, lets change the > server-client > protocol? > > ------------ > > As for the implementation, what is needed is a new mask (at least 16 bit, > but 32 would be nice) that is part of every attachment and which can > be changed by the user EVEN on no-mod objects! I lack the knowledge > of the server code to know if it's at all possible to add/have a modifiable > variable on a no-mod object ... > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From secret.argent at gmail.com Wed Dec 2 04:46:27 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 2 Dec 2009 06:46:27 -0600 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: <78f69850912012211p3032e2bn4bf277eb94a8e47e@mail.gmail.com> References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> <78f69850912012211p3032e2bn4bf277eb94a8e47e@mail.gmail.com> Message-ID: On 2009-12-02, at 00:11, Philippe (Merov) Bossut wrote: > My own personal contrib to this (https://jira.secondlife.com/browse/VWR-7703 > in a former life...) is still up in limbo and all that code is 1.18 > base. A really serious endeavor. I'm a fan of puppeteering as you > know but, then again, is that what folks on that list think the > priority should be? IOW, would that be the feature that would drive > folks to use Snowglobe and contribute to it? If this includes better scripted control of animations, so you can adjust the priority and limit the scope of an animation in the call, or even force joints to prims, that would be great (especially for furniture and small vehicle builders - I spent way too much time playing with animation positions on my glider). Unless you've got some really amazing user interface breakthrough, though, puppeteering directly from the client is probably going to be too fiddly for most users. Maybe you *do* have something in mind that will knock my socks off. The demo videos seemed to show people dragging limbs around with the mouse. I can see that being great for photographers but I don't know I'd use it much. How much internal use at LL did it see? From secret.argent at gmail.com Wed Dec 2 04:50:11 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 2 Dec 2009 06:50:11 -0600 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: <4B16523A.9070203@dragonkeepcreations.com> References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> <6BC7EA64-287B-4CEF-8BBF-A16AD5CCE553@gmail.com> <78f69850912012234s22c9c852w814d6c4dc8ce1c0@mail.gmail.com> <1e01733d0912020326ne8ba58ck7d8a0be634bc0d49@mail.gmail.com> <4B16523A.9070203@dragonkeepcreations.com> Message-ID: <600B8942-DA90-49E7-BDA7-537B77B9253C@gmail.com> On 2009-12-02, at 05:40, Maya Remblai wrote: > Personally, I'd like to see avatar alpha masking worked on in > Snowglobe, > and that stupid HUD alpha bug needed to be fixed months ago. 1 User Agreed! From stickman at gmail.com Wed Dec 2 06:59:23 2009 From: stickman at gmail.com (Stickman) Date: Wed, 2 Dec 2009 06:59:23 -0800 Subject: [sldev] 64bit of sl? In-Reply-To: <20091127124728.GA30666@alinoe.com> References: <4B0F5A6F.60409@gmail.com> <7eb2650f0911270036n6e238defl83574600a3668979@mail.gmail.com> <20091127100705.GA24564@alinoe.com> <20091127124728.GA30666@alinoe.com> Message-ID: > Doubling? Now you make no sense. > > The code is exactly the same as currently, there would be some > time needed to get it rolling, but after that 64bit virtually > needs no extra maintenance time. I make no sense because I'm uneducated on the topic. You have educated me, thank you. In an ideal world, everyone on the sldev list is knowledgeable in programming. In practice, a lot of us are directed to the list for various other reasons not involving programming. And a few of us even stick around to confuse people who actually know what they're talking about. Thanks for taking the time to spell it out for me. Next time I'll try to actually ask a question instead of veiling it in a confusing statement. -Stickman From q at lindenlab.com Wed Dec 2 10:18:29 2009 From: q at lindenlab.com (Kent Quirk) Date: Wed, 2 Dec 2009 13:18:29 -0500 Subject: [sldev] 64bit of sl? In-Reply-To: References: <4B0F5A6F.60409@gmail.com> <7eb2650f0911270036n6e238defl83574600a3668979@mail.gmail.com> <20091127100705.GA24564@alinoe.com> <20091127124728.GA30666@alinoe.com> Message-ID: On Dec 2, 2009, at 9:59 AM, Stickman wrote: >> Doubling? Now you make no sense. >> >> The code is exactly the same as currently, there would be some >> time needed to get it rolling, but after that 64bit virtually >> needs no extra maintenance time. > > I make no sense because I'm uneducated on the topic. You have educated > me, thank you. > > In an ideal world, everyone on the sldev list is knowledgeable in > programming. In practice, a lot of us are directed to the list for > various other reasons not involving programming. And a few of us even > stick around to confuse people who actually know what they're talking > about. > > Thanks for taking the time to spell it out for me. Next time I'll try > to actually ask a question instead of veiling it in a confusing > statement. Except that the creation of the code is only a small fraction of the problem. For each new build we support in an "official" mainline viewer, we have to: * Set up our automated build environment to build it, which includes configuring and deploying machines to do the build (and then maintain that forever) * Acquire machines and QA expertise to be able to test it adequately * Allocate QA resources to do a regression test on every release going forward * Allocate release team resources to document and maintain the release * Add support team capabilities to handle the new release We do it from time to time, but it's a significant allocation of resources and requires coordination across the company. Snowglobe has a different set of issues, and it's a bit easier. Q From monkowsk at fishkill.ibm.com Wed Dec 2 13:24:23 2009 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Wed, 02 Dec 2009 16:24:23 -0500 Subject: [sldev] 64bit of sl? In-Reply-To: References: <4B0F5A6F.60409@gmail.com> <7eb2650f0911270036n6e238defl83574600a3668979@mail.gmail.com> <20091127100705.GA24564@alinoe.com> <20091127124728.GA30666@alinoe.com> Message-ID: <4B16DB07.5010007@fishkill.ibm.com> Kent Quirk wrote: > Except that the creation of the code is only a small fraction of the > problem. For each new build we support in an "official" mainline > viewer, we have to: ... > We do it from time to time, but it's a significant allocation of > resources and requires coordination across the company. Well 128 bit doesn't look to be very close, so you're not going to be able to avoid doing 64 bit. What are you waiting for? I'd say this is one of those "from time to time" times. Mike From monkowsk at fishkill.ibm.com Wed Dec 2 13:45:54 2009 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Wed, 02 Dec 2009 16:45:54 -0500 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: <78f69850912012211p3032e2bn4bf277eb94a8e47e@mail.gmail.com> References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> <78f69850912012211p3032e2bn4bf277eb94a8e47e@mail.gmail.com> Message-ID: <4B16E012.7060807@fishkill.ibm.com> Philippe (Merov) Bossut wrote: > My own personal contrib to this > (https://jira.secondlife.com/browse/VWR-7703 in a former life...) is > still up in limbo and all that code is 1.18 base. A really serious > endeavor. I'm a fan of puppeteering as you know but, then again, is that > what folks on that list think the priority should be? IOW, would that be > the feature that would drive folks to use Snowglobe and contribute to it? It's on my short list. 1. VWR-10924 Magical scripted HUD/UI 2. VWR-6199 Decompile avatar LLM mesh(es) back to their source format, in order to enable VWR-3432 Improve Avatar Mesh 3. Merge the puppeteering branch into the current release in order to create an animation editor. I plan to do it if it's not done by the time I get there. I've already looked at the code in SVN and it wasn't a clean branch from the trunk, since it was developed in parallel, but it doesn't span too many source files. And you know you really want to do it. :-) Mike From tigrospottystripes at gmail.com Wed Dec 2 19:23:20 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 03 Dec 2009 01:23:20 -0200 Subject: [sldev] Where is Dynamic Refelctions? Message-ID: <4B172F28.1030302@Gmail.com> Where is the code for the client that had Dynamic Reflections? If if it isn't already, can it be made avaiable under the same license as the current client code please? From merov at lindenlab.com Wed Dec 2 22:17:16 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Wed, 2 Dec 2009 22:17:16 -0800 Subject: [sldev] SNOW-301 patch review? Message-ID: <78f69850912022217n16085e3fofa0ce4801acf83d9@mail.gmail.com> Hi, I posted a patch for SNOW-301 (updating the pluginapi code) and tested on Mac tonight. I'll be checking my Windows build tomorrow first thing at the office. If one of you guys could kick the tires on Linux (making sure it builds and passes simple tests, viewing the Help for instance and the splash screen) that'd be swell :) Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091202/93261224/attachment.htm From carlo at alinoe.com Thu Dec 3 05:32:49 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 3 Dec 2009 14:32:49 +0100 Subject: [sldev] 64bit of sl? In-Reply-To: References: <4B0F5A6F.60409@gmail.com> <7eb2650f0911270036n6e238defl83574600a3668979@mail.gmail.com> <20091127100705.GA24564@alinoe.com> <20091127124728.GA30666@alinoe.com> Message-ID: <20091203133249.GA3648@alinoe.com> I never intended to attack you... in fact I read you mail wrong :p, so you can really blame me for that error, or I'd not even have formulated it the way I did (although, I'm known for saying things rather bluntly, without meaning harm). I read you post originally as "it will double the time needed for maintenance" and that is what I reacted to. On Wed, Dec 02, 2009 at 06:59:23AM -0800, Stickman wrote: > Thanks for taking the time to spell it out for me. Next time I'll try > to actually ask a question instead of veiling it in a confusing > statement. > > -Stickman -- Carlo Wood From dzonatas at gmail.com Thu Dec 3 07:02:41 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 03 Dec 2009 07:02:41 -0800 Subject: [sldev] 64bit of sl? In-Reply-To: References: <4B0F5A6F.60409@gmail.com> <7eb2650f0911270036n6e238defl83574600a3668979@mail.gmail.com> <20091127100705.GA24564@alinoe.com> <20091127124728.GA30666@alinoe.com> Message-ID: <4B17D311.30709@gmail.com> Kent Quirk wrote: > On Dec 2, 2009, at 9:59 AM, Stickman wrote: > Except that the creation of the code is only a small fraction of the > problem. For each new build we support in an "official" mainline > viewer, we have to: > > * Set up our automated build environment to build it, which includes > configuring and deploying machines to do the build (and then maintain > that forever) > * Acquire machines and QA expertise to be able to test it adequately > * Allocate QA resources to do a regression test on every release going > forward > * Allocate release team resources to document and maintain the release > * Add support team capabilities to handle the new release > > We do it from time to time, but it's a significant allocation of > resources and requires coordination across the company. > > Snowglobe has a different set of issues, and it's a bit easier. > Could we assume that any portion of the viewer that could be put into a universal binary that could be compiled once and runs on all 64bit and 32bit version of Mac, Windows, and Linuxs distribution would be a significant salvation on resources? I know LL loves python. I also know that python could be made into a universal binary when compiled with Ironpython. I've wondered why LL hasn't taken advantage of Ironpython. I've fooled around with its ability to compile in the entire standard codebase, which would mean no need to worry if python is installed as it would be all in one binary. Sure, a larger binary, but how much does it save from what you noted? From stickman at gmail.com Thu Dec 3 07:05:51 2009 From: stickman at gmail.com (Stickman) Date: Thu, 3 Dec 2009 07:05:51 -0800 Subject: [sldev] Where is Dynamic Refelctions? In-Reply-To: <4B172F28.1030302@Gmail.com> References: <4B172F28.1030302@Gmail.com> Message-ID: On Wed, Dec 2, 2009 at 7:23 PM, Tigro Spottystripes wrote: > Where is the code for the client that had Dynamic Reflections? If if it > isn't already, can it be made avaiable under the same license as the > current client code please? I remember this coming up in the list a while back, and a Linden mentioned when reflections eventually had gotten removed to make way for windlight. SVN is open to the public, which means we can hop back to the version it existed in, can't we? Lemme try to track the version down. Brad Linden said back in May 2009 https://lists.secondlife.com/pipermail/sldev/2009-May/013654.html that it was cut out to make way for Windlight. Specifically, windlight water. Windlight First Look was released in May of 2007. https://blogs.secondlife.com/community/features/blog/2007/05/29/windlight-first-look-viewer-released The release notes on the wiki say 1.19.1 is the first version with windlight. http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/1.19.1 Though 1.19.0 mentions a fix for Windlight pie menus. So 1.18 may be your best bet for finding the code. I'm searching the blog for an open source announcement, but sorting by date gives me completely random results. The year isn't even stable. Jira'd. http://jira.secondlife.com/browse/WEB-1395 Someone who's better at using SVN than me will have to look at the oldest thing we have and see if 1.18 is available. I don't remember when the viewer went open source. If it's available, it may have the reflection code, stagnant or not. If it's not there, and older versions aren't available, then it would need to be requested. Stickman From aimee.trescothick at gmail.com Thu Dec 3 11:14:36 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Thu, 3 Dec 2009 19:14:36 +0000 Subject: [sldev] 64bit of sl? (Mac) In-Reply-To: <4B17D311.30709@gmail.com> References: <4B0F5A6F.60409@gmail.com> <7eb2650f0911270036n6e238defl83574600a3668979@mail.gmail.com> <20091127100705.GA24564@alinoe.com> <20091127124728.GA30666@alinoe.com> <4B17D311.30709@gmail.com> Message-ID: Unfortunately creating a 64-bit Mac version of the viewer is not quite as simple as just recompiling it into a 32/64-bit universal binary. Right now the viewer relies on some of the Carbon APIs which are only available in 32-bit, to produce a 64-bit version will mean transitioning to using the Cocoa equivalents, mixing in a greater amount of Objective-C than the viewer contains now to do so. Not an insurmountable obstacle, but still a fair amount of work. I would imagine it is more than is reasonably justifiable from a cost vs immediate benefit point of view within the Lab, compared with other priorities right now. It is probably harder to justify the development effort than 64-bit Windows and Linux versions, as we don't tend to have the same 32/64-bit compatibility headaches on OS X. Having said that (which I know probably all makes me sound a bit of a wet blanket) it will still need to happen at some point, and open source development and Snowglobe are an excellent solution and home for the project to make it happen sooner. I have already started the ground work by committing a few fixes to make Snowglobe compile cleanly against all of the 10.4, 10.5 and 10.6 SDKs (although there is still one remaining issue SNOW-223 which requires patching APR to make it play nicely with the 10.6 SDK, as well as 10.4 and 10.5). Even with the use of universal binaries to support both 32-bit and 64-bit versions, it can be quite a headache to maintain compatibility across all of 10.4.11 (the current official minimum requirement)), 10.5 and 10.6 especially if (when!) we wish to start using some of the newer features of Leopard and Snow Leopard, which is probably where the greater benefits lie, probably much more so than 'simply' moving to 64-bit. It would interesting to know how many people are actually still using the viewer on 10.4, especially Snowglobe (don't worry people, I'm not suggesting you're insignificant and should be immediately abandoned :) Aimee. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091203/53580591/attachment.htm From secret.argent at gmail.com Thu Dec 3 18:32:17 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 3 Dec 2009 20:32:17 -0600 Subject: [sldev] Where is Dynamic Refelctions? In-Reply-To: References: <4B172F28.1030302@Gmail.com> Message-ID: <7328D858-90D1-41FC-A832-F67E22562619@gmail.com> The problem is that the only really good version of dynamic reflections was First Look 57575, well before the Open Source program. The later versions were all fuzzy and hardly worth using. From carlo at alinoe.com Fri Dec 4 02:15:18 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 4 Dec 2009 11:15:18 +0100 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> <78f69850912012211p3032e2bn4bf277eb94a8e47e@mail.gmail.com> Message-ID: <20091204101518.GA5275@alinoe.com> On Wed, Dec 02, 2009 at 06:46:27AM -0600, Argent Stonecutter wrote: > Maybe you *do* have something in mind that will knock my socks off. > The demo videos seemed to show people dragging limbs around with the > mouse. I can see that being great for photographers but I don't know > I'd use it much. How much internal use at LL did it see? If that would allow editing existing animations, by changing a single frame of an animation, then I think that would be GREAT! Too bad that most (all) animations are no-mod :(, because this would only be useful for the end-user, knowing the one shape the animation has to be applied to. The Real Problem to be cracked would be the fact that animations have to work with a large variety of shapes. The data stored in animations is not the data that is constant over that range of shapes. What is constant is the offset from given points on the shape to objects or other avatars. I'd like to see animations being stored in the form "place hand on shoulder" and give that a higher priority than "put upper arm horizontal", which would allow calculation of the correct, intended, animations on the viewer - to work as intended, for a wide variety of shapes. -- Carlo Wood From lenglish5 at cox.net Fri Dec 4 06:35:03 2009 From: lenglish5 at cox.net (Lawson English) Date: Fri, 04 Dec 2009 07:35:03 -0700 Subject: [sldev] Direction for Snowglobe 1.3 In-Reply-To: <20091204101518.GA5275@alinoe.com> References: <78f69850911251210j2a8113b0tfae9cb2ffc210e40@mail.gmail.com> <4B141E30.4040408@fishkill.ibm.com> <78f69850912012211p3032e2bn4bf277eb94a8e47e@mail.gmail.com> <20091204101518.GA5275@alinoe.com> Message-ID: <4B191E17.6080705@cox.net> Carlo Wood wrote: > On Wed, Dec 02, 2009 at 06:46:27AM -0600, Argent Stonecutter wrote: > >> Maybe you *do* have something in mind that will knock my socks off. >> The demo videos seemed to show people dragging limbs around with the >> mouse. I can see that being great for photographers but I don't know >> I'd use it much. How much internal use at LL did it see? >> > > If that would allow editing existing animations, by changing > a single frame of an animation, then I think that would be > GREAT! > > The existing puppeteering code (corrections welcome Merov) allowed one to manipulate the avatar's bvh values in realtime on the clientside via the mouse with IK providing by simple ragdoll physics on the clientside. The client would then inform the sim as to the changed avatar position and the sim would broadcast an update to all viewers of hte current avatar behavior. I assume that the orginating viewer was exempted from this update. One plausible use of this technique would be to tie the avatar bvh values to a poser-like timeline which could be scripted clientside (or to a mo-cap setup of some kind as Merov was working on). A more elaborate setup would be to allow one or more clients to update/control each other's coordinates via a p2p connection to allow for coordinated mechanima between 2 or more avatars with updates eventually sent to the viewer for broadcast to the sim-at-large. One could see a single timeline controlling some arbitrary number of avatars behind the scenes for fully automated control, OR allow 2 or more viwers to update each other's data in some kind of realtime combat/dance/interaction scenario and again only update the sim so others can watch the shared experience. All sorts of hybrid scenarios might be possible, most of which we haven't thought of yet. > Too bad that most (all) animations are no-mod :(, because > this would only be useful for the end-user, knowing the one > shape the animation has to be applied to. > > The Real Problem to be cracked would be the fact that animations > have to work with a large variety of shapes. The data stored > in animations is not the data that is constant over that range > of shapes. What is constant is the offset from given points on > the shape to objects or other avatars. > within the context of the puppeteering code, this wouldn't be much of an issue because only IK (and I assume ground collision) was allowed for. With optional full-blown client physics done p2p style ala croquet, one could do just about anything with any aspect of the world-graph, but a full SL-Croquet hybrid is a bit further out. > I'd like to see animations being stored in the form "place > hand on shoulder" and give that a higher priority than > "put upper arm horizontal", which would allow calculation > of the correct, intended, animations on the viewer - to > work as intended, for a wide variety of shapes. > > Be fun if non-humanoid avatars were supported in that scenario. There' several more robust avatar control systems out there then bvh (e.g. http://ligwww.epfl.ch/%7Eaguye/AML/AMLOverview.pdf ) but I don't know what they do, exactly. Lawson From eiffel56 at gmail.com Fri Dec 4 11:21:26 2009 From: eiffel56 at gmail.com (Lisa Denia) Date: Fri, 4 Dec 2009 20:21:26 +0100 Subject: [sldev] Snowglobe on OpenSim grids Message-ID: <200912042021.26650.eiffel56@gmail.com> Hello, Snowglobe looks like a very nice viewer to me. Though there is some work left, it compiles and runs almost flawlessy on my x86_64 Linux system(in contrast to the latest, "official", Second Life viewer). But there is one main problem: I really like to play with OpenSim. Unfortunately, the new HTTP map texture fetching does not work with OpenSim based regions/grids. OpenSim does not support that feature. And since the URL to the world textures is hardcoded, Snowglobe will always load the ones from Linden Lab's grid. So I would like to have 2 things: - A way of disabling HTTP map textures completely, so the viewer returns to it's old behaviour. - The possibility to change the HTTP map texture URL somehow I know, I could just use the latest official Second Life viewer, or one of that various third party ones. But they depend on deprecated viewer releases, apply too many patches or just don't work. Additionally, Snowglobe provides some very nice features, especially it uses Webkit instead of Gecko, which solves many many issues. So, is the old way of fetching the map textures still present in Snowglobe? I looked a bit at the sourcecode, and it seems like many things got replaced. I guess it wouldn't be that easy to implement an "Use the old way of map texture fetching" feature in this case... Thanks, Lisa Denia From merov at lindenlab.com Fri Dec 4 11:46:01 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Fri, 4 Dec 2009 11:46:01 -0800 Subject: [sldev] Snowglobe on OpenSim grids In-Reply-To: <200912042021.26650.eiffel56@gmail.com> References: <200912042021.26650.eiffel56@gmail.com> Message-ID: <78f69850912041146m1140c7a4o10ced3aada0c7ee@mail.gmail.com> Hi Lisa, Glad you like Snowglobe 1.2 and some of its newest features :) On Fri, Dec 4, 2009 at 11:21 AM, Lisa Denia wrote: > So I would like to have 2 things: > - A way of disabling HTTP map textures completely, so the viewer returns to > it's old behaviour. > - The possibility to change the HTTP map texture URL somehow > Well, I think we just need one of the 2, not both :) My vote goes to the second suggestion: allow the HTTP map texture URL to be changed somehow. Before doing this though, I'd really like to know how the old map could possibly work with OpenSim: the map tiles were taken from the asset server using a scheme just as inflexible as the one we use now with S3 hosted tiles over HTTP. So, I'm puzzled... Could you describe how the map tiles are stored and organized in OpenSim so that we can come up with a workable solution? (I bet there's a spec somewhere so a pointer to this would be very much appreciated). Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091204/23940aeb/attachment.htm From carlo at alinoe.com Fri Dec 4 12:47:20 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 4 Dec 2009 21:47:20 +0100 Subject: [sldev] Snowglobe on OpenSim grids In-Reply-To: <78f69850912041146m1140c7a4o10ced3aada0c7ee@mail.gmail.com> References: <200912042021.26650.eiffel56@gmail.com> <78f69850912041146m1140c7a4o10ced3aada0c7ee@mail.gmail.com> Message-ID: <20091204204720.GA1104@alinoe.com> On Fri, Dec 04, 2009 at 11:46:01AM -0800, Philippe (Merov) Bossut wrote: > over HTTP. So, I'm puzzled... Could you describe how the map tiles are stored > and organized in OpenSim so that we can come up with a workable solution? (I > bet there's a spec somewhere so a pointer to this would be very much > appreciated). I heard that opensim is going to change this, too. They are planning on switching to http based textures... So, some input from an opensim developer before starting to implement this is needed imho. Are/is there any on this list? -- Carlo Wood From eiffel56 at gmail.com Fri Dec 4 13:35:31 2009 From: eiffel56 at gmail.com (Lisa Denia) Date: Fri, 4 Dec 2009 22:35:31 +0100 Subject: [sldev] Snowglobe on OpenSim grids In-Reply-To: <78f69850912041146m1140c7a4o10ced3aada0c7ee@mail.gmail.com> References: <200912042021.26650.eiffel56@gmail.com> <78f69850912041146m1140c7a4o10ced3aada0c7ee@mail.gmail.com> Message-ID: <200912042235.31734.eiffel56@gmail.com> Philippe (Merov) Bossut wrote: > Before doing this though, I'd really like to know how the old map could > possibly work with OpenSim: the map tiles were taken from the asset server > using a scheme just as inflexible as the one we use now with S3 hosted > tiles over HTTP. So, I'm puzzled... Could you describe how the map tiles > are stored and organized in OpenSim so that we can come up with a workable > solution? (I bet there's a spec somewhere so a pointer to this would be > very much appreciated). OpenSim uses the "old" style: Every map tile gets stored on the respective grid's asset server. Exactly the same as with the current "official" viewer, as it has to be completely compatible. There is a way to communicate with the asset server via HTTP though(called REST, see http://opensimulator.org/wiki/REST), but that mechanism is optional and not enabled on all grids/simulators. Carlo Wood wrote: > I heard that opensim is going to change this, too. > They are planning on switching to http based textures... So, some input > from an opensim developer before starting to implement this is needed > imho. Are/is there any on this list? I'm not an OpenSim developer, but as far as I know they are not going to implement this until it gets needed in order to work with standard Second Life viewers. Snowglobe is not needed, so the "solution" is to use another viewer. I think a patch implementing HTTP textures will surely be accepted, but as there aren't that much developers, they target on other things first. I think there are 3 ways now: - Include legacy code again in Snowglobe, using the old way for fetching world tiles - Communicate via REST somehow, will not work on all grids. Also the worst solution, as we have to get the maptile's UUID using the old way. - Implement HTTP textures in OpenSim(not that easy) and allow to define an alternative HTTP texture fetch URL in Snowglobe. The last one is probably the best solution, but can't be achieved in a short time. Thanks, Lisa Denia From dahliatrimble at gmail.com Fri Dec 4 13:35:59 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri, 4 Dec 2009 13:35:59 -0800 Subject: [sldev] Snowglobe on OpenSim grids In-Reply-To: <20091204204720.GA1104@alinoe.com> References: <200912042021.26650.eiffel56@gmail.com> <78f69850912041146m1140c7a4o10ced3aada0c7ee@mail.gmail.com> <20091204204720.GA1104@alinoe.com> Message-ID: I believe in OpenSim the map and map images are proxied through the simulator via a combination of Caps and UDP messages. I haven't looked too closely at the implementation details for the map images but I believe they use the normal texture pathways (UDP ImageRequest and ImageResponse packets). As far as I know the simulator is also the proxy for all map information on the Linden grids when the standard viewer is used. I would suggest that the easiest way to get a working map for OpenSim would be to enable the older map. The current SL viewer has a functional map when used with OpenSim, as far as I'm aware Snowglobe is the only viewer where the map will not work in OpenSim. I might also suggest that Snowglobe acquire the map images URL via a capability, rather than hard coding it. I suspect if this were the case that a similar map images capability would appear in OpenSim soon after. Adding such a capability would seem beneficial to LL as well since then there would be no need to constantly maintain a URL and it could be changed as needed without requiring a new viewer download. On Fri, Dec 4, 2009 at 12:47 PM, Carlo Wood wrote: > On Fri, Dec 04, 2009 at 11:46:01AM -0800, Philippe (Merov) Bossut wrote: > > over HTTP. So, I'm puzzled... Could you describe how the map tiles are > stored > > and organized in OpenSim so that we can come up with a workable solution? > (I > > bet there's a spec somewhere so a pointer to this would be very much > > appreciated). > > I heard that opensim is going to change this, too. > They are planning on switching to http based textures... So, some input > from an opensim developer before starting to implement this is needed > imho. Are/is there any on this list? > > -- > Carlo Wood > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091204/577d0bc6/attachment.htm From carlo at alinoe.com Fri Dec 4 13:41:54 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 4 Dec 2009 22:41:54 +0100 Subject: [sldev] Snowglobe on OpenSim grids In-Reply-To: <200912042235.31734.eiffel56@gmail.com> References: <200912042021.26650.eiffel56@gmail.com> <78f69850912041146m1140c7a4o10ced3aada0c7ee@mail.gmail.com> <200912042235.31734.eiffel56@gmail.com> Message-ID: <20091204214154.GA3380@alinoe.com> On Fri, Dec 04, 2009 at 10:35:31PM +0100, Lisa Denia wrote: > - Implement HTTP textures in OpenSim(not that easy) and allow to define an > alternative HTTP texture fetch URL in Snowglobe. > > The last one is probably the best solution, but can't be achieved in a short > time. Yes, but in order to allow opensim to ever support this, snowglobe should ASAP implement a capability to get the URL. Then, since opensim will report it doesn't have that capability, we can also fall back to the old way of displaying map tiles. -- Carlo Wood From dahliatrimble at gmail.com Fri Dec 4 13:49:41 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri, 4 Dec 2009 13:49:41 -0800 Subject: [sldev] Snowglobe on OpenSim grids In-Reply-To: <20091204214154.GA3380@alinoe.com> References: <200912042021.26650.eiffel56@gmail.com> <78f69850912041146m1140c7a4o10ced3aada0c7ee@mail.gmail.com> <200912042235.31734.eiffel56@gmail.com> <20091204214154.GA3380@alinoe.com> Message-ID: that may require the capability to also exist on the SL grids. -Dahlia (OpenSim core developer) On Fri, Dec 4, 2009 at 1:41 PM, Carlo Wood wrote: > On Fri, Dec 04, 2009 at 10:35:31PM +0100, Lisa Denia wrote: > > - Implement HTTP textures in OpenSim(not that easy) and allow to define > an > > alternative HTTP texture fetch URL in Snowglobe. > > > > The last one is probably the best solution, but can't be achieved in a > short > > time. > > Yes, but in order to allow opensim to ever support this, > snowglobe should ASAP implement a capability to get the URL. > > Then, since opensim will report it doesn't have that capability, > we can also fall back to the old way of displaying map tiles. > > -- > Carlo Wood > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091204/bb571e43/attachment.htm From eiffel56 at gmail.com Fri Dec 4 14:10:19 2009 From: eiffel56 at gmail.com (Lisa Denia) Date: Fri, 4 Dec 2009 23:10:19 +0100 Subject: [sldev] Snowglobe on OpenSim grids Message-ID: <200912042310.19845.eiffel56@gmail.com> Carlo Wood wrote: > Yes, but in order to allow opensim to ever support this, > snowglobe should ASAP implement a capability to get the URL. > Then, since opensim will report it doesn't have that capability, > we can also fall back to the old way of displaying map tiles. Sounds like a very good idea to me. Dahlia wrote: > that may require the capability to also exist on the SL grids. Of course. I don't know much about Linden Lab's internal server software releasy cycles, but is that a problem? Snowglobe is still something "experimental" as far as I know. Since introducing that capability doesn't break anything for Snowglobe users(the map could load a bit slower maybe), it can safely be added at the next regular server update. Snowglobe could even force HTTP map tiles when it detects that it's connected to Linden Lab's grid(maybe a bit dirty :)). From melinda at superliminal.com Fri Dec 4 15:01:24 2009 From: melinda at superliminal.com (Melinda Green) Date: Fri, 04 Dec 2009 15:01:24 -0800 Subject: [sldev] Snowglobe on OpenSim grids In-Reply-To: References: <200912042021.26650.eiffel56@gmail.com> <78f69850912041146m1140c7a4o10ced3aada0c7ee@mail.gmail.com> <20091204204720.GA1104@alinoe.com> Message-ID: <4B1994C4.6080600@superliminal.com> Dahlia Trimble wrote: > > On Fri, Dec 4, 2009 at 12:47 PM, Carlo Wood > wrote: > > On Fri, Dec 04, 2009 at 11:46:01AM -0800, Philippe (Merov) Bossut > wrote: > > over HTTP. So, I'm puzzled... Could you describe how the map > tiles are stored > > and organized in OpenSim so that we can come up with a workable > solution? (I > > bet there's a spec somewhere so a pointer to this would be very much > > appreciated). > > I heard that opensim is going to change this, too. > They are planning on switching to http based textures... So, some > input > from an opensim developer before starting to implement this is needed > imho. Are/is there any on this list? > > > I believe in OpenSim the map and map images are proxied through the > simulator via a combination of Caps and UDP messages. I haven't looked > too closely at the implementation details for the map images but I > believe they use the normal texture pathways (UDP ImageRequest and > ImageResponse packets). As far as I know the simulator is also the > proxy for all map information on the Linden grids when the standard > viewer is used. > > > > > I would suggest that the easiest way to get a working map for OpenSim > would be to enable the older map. The current SL viewer has a > functional map when used with OpenSim, as far as I'm aware Snowglobe is > the only viewer where the map will not work in OpenSim. > > > > > I might also suggest that Snowglobe acquire the map images URL via a > capability, rather than hard coding it. I suspect if this were the case > that a similar map images capability would appear in OpenSim soon > after. Adding such a capability would seem beneficial to LL as well > since then there would be no need to constantly maintain a URL and it > could be changed as needed without requiring a new viewer download. LL must deal with this for Nebraska too, right? Snowglobe/OpenSim seems like a good place to develop this ability if it's not already under development. If it's been developed, then I encourage LL to tell us so to avoid duplicating efforts. -Melinda From adam at deepthink.com.au Fri Dec 4 15:31:37 2009 From: adam at deepthink.com.au (Frisby, Adam) Date: Fri, 4 Dec 2009 18:31:37 -0500 Subject: [sldev] Snowglobe on OpenSim grids In-Reply-To: <4B1994C4.6080600@superliminal.com> References: <200912042021.26650.eiffel56@gmail.com> <78f69850912041146m1140c7a4o10ced3aada0c7ee@mail.gmail.com> <20091204204720.GA1104@alinoe.com> <4B1994C4.6080600@superliminal.com> Message-ID: <63FAD4F222230A4EA79DE9E8BE6647354DBB28ED@winxbeus19.exchange.xchg> As another OpenSim core developer - may I make the suggestion that this is being done completely the wrong way? The map tiles are still fairly standard textures (although I know the new routine uses JPG over J2K -- but the viewer in theory supports JPG textures in the standard pipeline too) - why add the extra methods, when you could just inline this over the new HTTP textures system? I realise the reason LL switched to S3 here was probably related to CDN distribution; however that may be better served as a generalised solution on the backend - using something like a 302 redirect on the capability over to S3 on popular asset IDs (world map images & other 'common' textures). Regards, Adam > -----Original Message----- > From: sldev-bounces at lists.secondlife.com [mailto:sldev- > bounces at lists.secondlife.com] On Behalf Of Melinda Green > Sent: Friday, 4 December 2009 3:01 PM > To: Dahlia Trimble > Cc: Second Life Developer Mailing List > Subject: Re: [sldev] Snowglobe on OpenSim grids > > Dahlia Trimble wrote: > > > > On Fri, Dec 4, 2009 at 12:47 PM, Carlo Wood > > wrote: > > > > On Fri, Dec 04, 2009 at 11:46:01AM -0800, Philippe (Merov) Bossut > > wrote: > > > over HTTP. So, I'm puzzled... Could you describe how the map > > tiles are stored > > > and organized in OpenSim so that we can come up with a workable > > solution? (I > > > bet there's a spec somewhere so a pointer to this would be very > much > > > appreciated). > > > > I heard that opensim is going to change this, too. > > They are planning on switching to http based textures... So, some > > input > > from an opensim developer before starting to implement this is > needed > > imho. Are/is there any on this list? > > > > > > I believe in OpenSim the map and map images are proxied through the > > simulator via a combination of Caps and UDP messages. I haven't > looked > > too closely at the implementation details for the map images but I > > believe they use the normal texture pathways (UDP ImageRequest and > > ImageResponse packets). As far as I know the simulator is also the > > proxy for all map information on the Linden grids when the standard > > viewer is used. > > > > > > > > > > I would suggest that the easiest way to get a working map for OpenSim > > would be to enable the older map. The current SL viewer has a > > functional map when used with OpenSim, as far as I'm aware Snowglobe > is > > the only viewer where the map will not work in OpenSim. > > > > > > > > > > I might also suggest that Snowglobe acquire the map images URL via a > > capability, rather than hard coding it. I suspect if this were the > case > > that a similar map images capability would appear in OpenSim soon > > after. Adding such a capability would seem beneficial to LL as well > > since then there would be no need to constantly maintain a URL and it > > could be changed as needed without requiring a new viewer download. > > LL must deal with this for Nebraska too, right? Snowglobe/OpenSim seems > like a good place to develop this ability if it's not already under > development. If it's been developed, then I encourage LL to tell us so > to avoid duplicating efforts. > > -Melinda > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From merov at lindenlab.com Fri Dec 4 16:23:35 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Fri, 4 Dec 2009 16:23:35 -0800 Subject: [sldev] Patch review requested : SNOW-64 and SNOW-260 Message-ID: <78f69850912041623j244a41aeo22b2e0b736e980bd@mail.gmail.com> Hi, I cleaned up and reattached patch for those 2 small UI issues. I'd appreciate if a committer could take a peak and +1/-1 so I can commit early next week. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091204/bc5bf9ad/attachment.htm From merov at lindenlab.com Fri Dec 4 16:43:24 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Fri, 4 Dec 2009 16:43:24 -0800 Subject: [sldev] Snowglobe this week Message-ID: <78f69850912041643i526800bdy6f7d1f8b9e7cea23@mail.gmail.com> Hi guys, I think I'll start a new tradition today releasing a short email listing the various contributions to Snowglobe trunk as well as making sure there's a clean recent build available for all to download and test. This week (or rather, since 1.2.4 release), we got: SNOW-188 Allow panning of the mini-map : by AimeeT : now you can zoom in and shift-drag to see a little beyond the boundaries of the minimap. Try to check/uncheck the "center on camera" (in the contextual menu) to see the map recentering or not SNOW-301 Update pluginapi code so to support newest API : by Merov : pluginapi updated to the latest from the internal branch. I'm planning now to move to the other bugs concerning broken content. Please retest issues you may have had and, if not reported, please log JIRA! SLURL giving the location of the broken content as well as info on which platform you're running are essential. Thanks! SNOW-201 "DeprecationWarning: the sets module is deprecated" with Python >= 2.6 : by Borrondas Gupte Downloads: Linux: http://secondlife.com/developers/opensource/downloads/2009/trunk/3049/Snowglobe-i686-1.3.0.3049.tar.bz2 Darwin: http://secondlife.com/developers/opensource/downloads/2009/trunk/3049/Snowglobe_1_3_0_3049_SNOWGLOBETESTBUILD.dmg CYGWIN: http://secondlife.com/developers/opensource/downloads/2009/trunk/3049/Snowglobe_1-3-0-3049_Setup.exe There are a bunch of patches waiting reviews so I'm expecting more stuff to land next week. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091204/7a2f62e4/attachment.htm From aleric.inglewood at gmail.com Sat Dec 5 03:36:14 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Sat, 5 Dec 2009 12:36:14 +0100 Subject: [sldev] Snowglobe on OpenSim grids In-Reply-To: <200912042310.19845.eiffel56@gmail.com> References: <200912042310.19845.eiffel56@gmail.com> Message-ID: <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> It seems to me we have consensus on the need to add a new capability for this, except from Linden Lab? To quote myself from 2 Dec:: I regret it that we don't have a good communication link with ALL LL developers, only with the handful that is working on snowglobe, or maybe I'm just missing an overview. Is there anyone here who could say: Ok, lets change the server-client protocol? That question was never answered... Merov? On Fri, Dec 4, 2009 at 11:10 PM, Lisa Denia wrote: > Carlo Wood wrote: >> Yes, but in order to allow opensim to ever support this, >> snowglobe should ASAP implement a capability to get the URL. > >> Then, since opensim will report it doesn't have that capability, >> we can also fall back to the old way of displaying map tiles. > > Sounds like a very good idea to me. > > Dahlia wrote: >> that may require the capability to also exist on the SL grids. > > Of course. I don't know much about Linden Lab's internal server software > releasy cycles, but is that a problem? > Snowglobe is still something "experimental" as far as I know. Since > introducing that capability doesn't break anything for Snowglobe users(the map > could load a bit slower maybe), it can safely be added at the next regular > server update. Snowglobe could even force HTTP map tiles when it detects that > it's connected to Linden Lab's grid(maybe a bit dirty :)). > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From lenglish5 at cox.net Sat Dec 5 05:45:04 2009 From: lenglish5 at cox.net (Lawson English) Date: Sat, 05 Dec 2009 06:45:04 -0700 Subject: [sldev] Snowglobe on OpenSim grids In-Reply-To: <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> Message-ID: <4B1A63E0.40809@cox.net> Aleric Inglewood wrote: > It seems to me we have consensus on the need to add a new capability for this, > except from Linden Lab? To quote myself from 2 Dec:: > > I regret it that we don't have a good communication link with ALL LL developers, > only with the handful that is working on snowglobe, or maybe I'm just missing > an overview. Is there anyone here who could say: Ok, lets change the > server-client protocol? > > That question was never answered... Merov? > > There's been talk forever and a day within Groupies/AWG/OGP/MMOX/etc about defining a protocol for a client-initiated request for a new service. My suggestion is that people pretend that some OGP-ish mechanism is in place (or will be) and come to a rough consensus about what it will look like and present it formally on the OGP list while simply going ahead and implementing it, with or without LL's stamp of approval. As long as everyone understands that the protocol for actually GETTING the url might change in the future when everyone (somehow) comes to agreement about The One Best Way to do these things, a given client, GPL-licensed or otherwise, having the ability of to change the URL on the fly won't break everything internally and shouldn't cause huge problems down the line. Remember: the IETF counts working code higher than hand-waving, so if you're tired of LL's handwaving, get together with the realXtend, libomv, OpenSim, (and whomever I may have missed) and Just Do It. As they might say in the IETF: hum something up and get it working, THEN debate which is the best way (or ways) to do the thing. Doesn't mean you shouldn't argue while you're doing it, just that you're not going to get anywhere proposing something entirely new on THIS mailing list and then waiting for LL's blessing before starting. Lawson (ducks back into learning smalltalk and implementing Yet Another Proof of Concept) > On Fri, Dec 4, 2009 at 11:10 PM, Lisa Denia wrote: > >> Carlo Wood wrote: >> >>> Yes, but in order to allow opensim to ever support this, >>> snowglobe should ASAP implement a capability to get the URL. >>> >>> Then, since opensim will report it doesn't have that capability, >>> we can also fall back to the old way of displaying map tiles. >>> >> Sounds like a very good idea to me. >> >> Dahlia wrote: >> >>> that may require the capability to also exist on the SL grids. >>> >> Of course. I don't know much about Linden Lab's internal server software >> releasy cycles, but is that a problem? >> Snowglobe is still something "experimental" as far as I know. Since >> introducing that capability doesn't break anything for Snowglobe users(the map >> could load a bit slower maybe), it can safely be added at the next regular >> server update. Snowglobe could even force HTTP map tiles when it detects that >> it's connected to Linden Lab's grid(maybe a bit dirty :)). >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From suzyque at gmail.com Sat Dec 5 16:30:10 2009 From: suzyque at gmail.com (Suzy Deffeyes) Date: Sat, 5 Dec 2009 16:30:10 -0800 Subject: [sldev] Snowglobe on OpenSim grids In-Reply-To: <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> Message-ID: If the code defaults to the existing hardcoded amazon behavior if a cap to map tiles is not returned, then it doesn't require a LL protocol change. Suzy/Pixel Sent from my iPhone On Dec 5, 2009, at 3:36 AM, Aleric Inglewood wrote: > It seems to me we have consensus on the need to add a new capability > for this, > except from Linden Lab? To quote myself from 2 Dec:: > > I regret it that we don't have a good communication link with ALL LL > developers, > only with the handful that is working on snowglobe, or maybe I'm > just missing > an overview. Is there anyone here who could say: Ok, lets change the > server-client protocol? > > That question was never answered... Merov? > > On Fri, Dec 4, 2009 at 11:10 PM, Lisa Denia > wrote: >> Carlo Wood wrote: >>> Yes, but in order to allow opensim to ever support this, >>> snowglobe should ASAP implement a capability to get the URL. >> >>> Then, since opensim will report it doesn't have that capability, >>> we can also fall back to the old way of displaying map tiles. >> >> Sounds like a very good idea to me. >> >> Dahlia wrote: >>> that may require the capability to also exist on the SL grids. >> >> Of course. I don't know much about Linden Lab's internal server >> software >> releasy cycles, but is that a problem? >> Snowglobe is still something "experimental" as far as I know. Since >> introducing that capability doesn't break anything for Snowglobe >> users(the map >> could load a bit slower maybe), it can safely be added at the next >> regular >> server update. Snowglobe could even force HTTP map tiles when it >> detects that >> it's connected to Linden Lab's grid(maybe a bit dirty :)). >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From carlo at alinoe.com Sun Dec 6 16:33:50 2009 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 7 Dec 2009 01:33:50 +0100 Subject: [sldev] Snowglobe on OpenSim grids In-Reply-To: References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> Message-ID: <20091207003350.GA5500@alinoe.com> On Sat, Dec 05, 2009 at 04:30:10PM -0800, Suzy Deffeyes wrote: > If the code defaults to the existing hardcoded amazon behavior if a > cap to map tiles is not returned, then it doesn't require a LL > protocol change. There will be a time that not all OTHER implementations (ie opensim) have implemented this; in which case the cap will fail. In that case we want to fall back to the OLD way maps worked, because that is what works on opensim, at least - on opensim. Hence, this would require "detection" of on which network we are, and then adjust the "protocol" as required... I just wrote a long post about this horror (believe, it will happen again and again and again and the list of this type of things will only get LONGER and LONGER!). What we need, from the very start, is a good protocol negotiation sheme added to VWRAP (the new name for OGP). The protocol negotion sheme that I have proposed would make it clear what the base protocol is (the mandatory features so to say), as each server implementation gets it's own label (ie, LindenLab and OpenSim (as well as version numbers of course)). Then you could indeed say: Hey, opensim doesn't offer the feature "NewMap", so we use the old style map. And, hey, LindenLab doesn't offer the feature "NewMapURL", so we just use the S3 url as fall back (for the mandatory "NewMap" feature). Also, "NewMap" is really optional at the moment (the 1.23 viewers don't use it)... If the protocol negotiation had already been in place, then LL would have added an optional "NewMap" feature, with documentation, at the same time that it became available. The 1.23 viewer would not have known what it was and wouldn't use it, snowglobe would and would use it. THEN, on opensim, snowglobe would see that there isn't an optional "NewMap" feature and would NOT use the new map style. This demonstrates the power, and need, for protocol negotiation. At some later date, LL would add support for the new map also to the official viewers and make the feature mandatory (so that everyone with a client that doesn't support it has to upgrade). With the protocol negotiation that I proposed, the whole "NewMap" option would disappear from the actual negotiation (the documentation would still be there though, on the net ;), as if it had been a part of the protocol like everything else mandatory (ie, support for teleporting). -- Carlo Wood From ardylay at gmail.com Tue Dec 8 02:05:13 2009 From: ardylay at gmail.com (Ardy Lay) Date: Tue, 08 Dec 2009 04:05:13 -0600 Subject: [sldev] Where is Dynamic Refelctions? In-Reply-To: <7328D858-90D1-41FC-A832-F67E22562619@gmail.com> References: <4B172F28.1030302@Gmail.com> <7328D858-90D1-41FC-A832-F67E22562619@gmail.com> Message-ID: <4B1E24D9.2040902@gmail.com> Argent Stonecutter wrote: > The problem is that the only really good version of dynamic > reflections was First Look 57575, well before the Open Source program. > The later versions were all fuzzy and hardly worth using. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > I seem to be finding some archives here: https://wiki.secondlife.com/wiki/Obsolete_Source_downloads From suzyque at gmail.com Tue Dec 8 05:23:08 2009 From: suzyque at gmail.com (Suzy Deffeyes) Date: Tue, 8 Dec 2009 07:23:08 -0600 Subject: [sldev] Snowglobe on OpenSim grids In-Reply-To: <20091207003350.GA5500@alinoe.com> References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> <20091207003350.GA5500@alinoe.com> Message-ID: <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> I originally added the map tile cap to my Snowglobe 1.3 wishlist because currently when http texture fetches are enabled, OpenSim users get completely wrong map tiles. That's just rude for them. I wanted to fix it for existing OpenSim grids, so they could implement serving the correct map tiles via http. I wasn't thinking of it as vwrap related, although it does illustrate the interesting dance from udp to http, and some of the issues with that. Can we make a simple fix for OpenSim now that will still work with the existing Linden grid, irrespective of vwrap? Suzy/Pixel Sent from my iPhone On Dec 6, 2009, at 6:33 PM, Carlo Wood wrote: > On Sat, Dec 05, 2009 at 04:30:10PM -0800, Suzy Deffeyes wrote: >> If the code defaults to the existing hardcoded amazon behavior if a >> cap to map tiles is not returned, then it doesn't require a LL >> protocol change. > > There will be a time that not all OTHER implementations (ie opensim) > have implemented this; in which case the cap will fail. > > In that case we want to fall back to the OLD way maps worked, > because that is what works on opensim, at least - on opensim. > > Hence, this would require "detection" of on which network > we are, and then adjust the "protocol" as required... > > I just wrote a long post about this horror (believe, it will > happen again and again and again and the list of this type > of things will only get LONGER and LONGER!). > > What we need, from the very start, is a good protocol > negotiation sheme added to VWRAP (the new name for OGP). > > The protocol negotion sheme that I have proposed would > make it clear what the base protocol is (the mandatory > features so to say), as each server implementation gets > it's own label (ie, LindenLab and OpenSim (as well as > version numbers of course)). Then you could indeed say: > > Hey, opensim doesn't offer the feature "NewMap", so > we use the old style map. And, hey, LindenLab doesn't > offer the feature "NewMapURL", so we just use the S3 > url as fall back (for the mandatory "NewMap" feature). > > Also, "NewMap" is really optional at the moment (the > 1.23 viewers don't use it)... If the protocol negotiation > had already been in place, then LL would have added > an optional "NewMap" feature, with documentation, at > the same time that it became available. The 1.23 viewer > would not have known what it was and wouldn't use it, > snowglobe would and would use it. THEN, on opensim, > snowglobe would see that there isn't an optional > "NewMap" feature and would NOT use the new map style. > > This demonstrates the power, and need, for protocol > negotiation. > > At some later date, LL would add support for the new > map also to the official viewers and make the feature > mandatory (so that everyone with a client that doesn't > support it has to upgrade). With the protocol negotiation > that I proposed, the whole "NewMap" option would disappear > from the actual negotiation (the documentation would > still be there though, on the net ;), as if it had > been a part of the protocol like everything else > mandatory (ie, support for teleporting). > > -- > Carlo Wood From secret.argent at gmail.com Tue Dec 8 04:38:22 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue, 8 Dec 2009 06:38:22 -0600 Subject: [sldev] Where is Dynamic Refelctions? In-Reply-To: <4B1E24D9.2040902@gmail.com> References: <4B172F28.1030302@Gmail.com> <7328D858-90D1-41FC-A832-F67E22562619@gmail.com> <4B1E24D9.2040902@gmail.com> Message-ID: On 2009-12-08, at 04:05, Ardy Lay wrote: > Argent Stonecutter wrote: >> The problem is that the only really good version of dynamic >> reflections was First Look 57575, well before the Open Source >> program. >> The later versions were all fuzzy and hardly worth using. > I seem to be finding some archives here: > https://wiki.secondlife.com/wiki/Obsolete_Source_downloads Oh, nice, it just barely made the cut. From open at autistici.org Tue Dec 8 10:07:10 2009 From: open at autistici.org (Opensource Obscure) Date: Tue, 08 Dec 2009 18:07:10 +0000 Subject: [sldev] Compiling and Patching Snowglobe (Linux) Message-ID: <880bca89a1f906398b6ecfb56604e47a@localhost> I just created this page, meant to be a quick, easy to maintain, step-by-step guide about compiling (and patching) Snowglobe on Linux using SVN. https://wiki.secondlife.com/wiki/Compiling_and_Patching_Snowglobe_(Linux) I'm not skilled with this stuff, I wrote it as a reference for myself in the first place. Surely it includes some silly errors, I encourage to review, correct it etc. Please keep the page simple and short, as it's not meant to be the Snowglobe equivalent of https://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux) If you're not comfortable with directly editing the SL wiki, feel free to privately write me via email. Opensource Obscure -- http://twitter.com/oobscure From aimee.trescothick at gmail.com Tue Dec 8 11:53:10 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Tue, 8 Dec 2009 19:53:10 +0000 Subject: [sldev] Blowing wind References: <91E137EF-6B9B-4EEE-8C24-939C108DA7A6@ama-zing.co.uk> Message-ID: <31E66752-7593-43F0-A68D-E5EAE13CBECB@gmail.com> Can anyone explain how the below piece of the existing code from the wind noise synthesizer has ever actually worked properly, with MIXBUFFERFORMAT_T defined as S16 and stride set to 4 bytes? U8 *cursamplep = (U8*)newbuffer; ... MIXBUFFERFORMAT_T sample; ... sample = llfloor(((F32)nextSample*32768.f*(1.0f - mCurrentPanGainR))+0.5f); *(MIXBUFFERFORMAT_T*)cursamplep = llclamp(sample, (MIXBUFFERFORMAT_T)-32768, (MIXBUFFERFORMAT_T)32767); cursamplep += stride; sample = llfloor(((F32)nextSample*32768.f*mCurrentPanGainR)+0.5f); *(MIXBUFFERFORMAT_T*)cursamplep = llclamp(sample, (MIXBUFFERFORMAT_T)-32768, (MIXBUFFERFORMAT_T)32767); cursamplep += stride; On Windows and Linux MIXBUFFERFORMAT_T is defined as S16, and if the FMOD mixer mode is FSOUND_MIXER_QUALITY_FPU or FSOUND_MIXER_BLENDMODE, stride is set to 4 bytes, as these modes both use a 32-bit mix buffer. But as far as I can see, that's just going to write signed 16-bit integers into the first two bytes of the 4-byte sample, skipping over the other two bytes, leaving them at whatever they were before (zero, as wind is the first thing that goes in the buffer after it is cleared). When FMOD tries to read the 4-bytes back as either 32-bit signed integers (FSOUND_MIXER_BLENDMODE), or 32-bit float (FSOUND_MIXER_QUALITY_FPU) that's just going to go horribly wrong. MIXBUFFERFORMAT_T is only defined as S32 on the Mac, on Windows and Linux it is S16 as one of FMOD's 16-bit MMX mixers is normally used. The only time I would imagine this situation occurs is on a PC without MMX (or when LL_VALGRIND is defined on Linux for testing, which specifically forces the mixer mode to FSOUND_MIXER_QUALITY_FPU). If this has never worked anyway, it would seem to make sense to turn off the wind generator for these mixer modes to avoid making a horrible noise, drop the striding which will simplify things elsewhere, and just declare cursamplep as MIXBUFFERFORMAT_T in the first place, removing the need to typecast it ... or am I missing something? (If you followed me this far you're doing better than I am :) Aimee. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091208/3afcd927/attachment.htm From merov at lindenlab.com Tue Dec 8 21:46:47 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 8 Dec 2009 21:46:47 -0800 Subject: [sldev] Blowing wind In-Reply-To: <31E66752-7593-43F0-A68D-E5EAE13CBECB@gmail.com> References: <91E137EF-6B9B-4EEE-8C24-939C108DA7A6@ama-zing.co.uk> <31E66752-7593-43F0-A68D-E5EAE13CBECB@gmail.com> Message-ID: <78f69850912082146u504f96c6g76c15f702f088eb0@mail.gmail.com> Hi Aimee, I haven't looked in the code, just assumed you copied the relevant parts :) It seems to me that the intent of the code is to write in "newbuffer" by packets of "sizeof(MIXBUFFERFORMAT_T) == stride" bytes using "cursamplep" as a sliding pointer. That said then, having "stride == 4" when "MIXBUFFERFORMAT_T" is defined as S16 seems wrong. So the question is: why is "stride" set independently of "sizeof(MIXBUFFERFORMAT_T)"? Are there any situation where those 2 things need to be different? Looking at how "stride" is set should give you a hint. Cheers, - Merov On Tue, Dec 8, 2009 at 11:53 AM, Aimee Trescothick < aimee.trescothick at gmail.com> wrote: > Can anyone explain how the below piece of the existing code from the wind > noise synthesizer has ever actually worked properly, with > MIXBUFFERFORMAT_T defined as S16 and stride set to 4 bytes? > > U8 *cursamplep = (U8*)newbuffer; > ... > > MIXBUFFERFORMAT_T sample; > ... > > sample = llfloor(((F32)nextSample*32768.f*(1.0f - > mCurrentPanGainR))+0.5f); > *(MIXBUFFERFORMAT_T*)cursamplep = llclamp(sample, > (MIXBUFFERFORMAT_T)-32768, > > (MIXBUFFERFORMAT_T)32767); > cursamplep += stride; > > sample = llfloor(((F32)nextSample*32768.f*mCurrentPanGainR)+0.5f); > *(MIXBUFFERFORMAT_T*)cursamplep = llclamp(sample, > (MIXBUFFERFORMAT_T)-32768, > > (MIXBUFFERFORMAT_T)32767); > cursamplep += stride; > > On Windows and Linux MIXBUFFERFORMAT_T is defined as S16, and if the FMOD > mixer mode is FSOUND_MIXER_QUALITY_FPU or FSOUND_MIXER_BLENDMODE, stride is > set to 4 bytes, as these modes both use a 32-bit mix buffer. > > But as far as I can see, that's just going to write signed 16-bit integers > into the first two bytes of the 4-byte sample, skipping over the other two > bytes, leaving them at whatever they were before (zero, as wind is the first > thing that goes in the buffer after it is cleared). When FMOD tries to read > the 4-bytes back as either 32-bit signed integers (FSOUND_MIXER_BLENDMODE), or 32-bit > float (FSOUND_MIXER_QUALITY_FPU) that's just going to go horribly wrong. > > MIXBUFFERFORMAT_T is only defined as S32 on the Mac, on Windows and Linux > it is S16 as one of FMOD's 16-bit MMX mixers is normally used. The only > time I would imagine this situation occurs is on a PC without MMX (or when > LL_VALGRIND is defined on Linux for testing, which specifically forces the > mixer mode to FSOUND_MIXER_QUALITY_FPU). > > If this has never worked anyway, it would seem to make sense to turn off > the wind generator for these mixer modes to avoid making a horrible noise, > drop the striding which will simplify things elsewhere, and just declare > cursamplep as MIXBUFFERFORMAT_T in the first place, removing the need to > typecast it ... or am I missing something? > > (If you followed me this far you're doing better than I am :) > > Aimee. > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091208/19fe67be/attachment.htm From dahliatrimble at gmail.com Wed Dec 9 00:27:17 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed, 9 Dec 2009 00:27:17 -0800 Subject: [sldev] Snowglobe on OpenSim grids In-Reply-To: <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> <20091207003350.GA5500@alinoe.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> Message-ID: Along the same lines of the hard coded map URL, there's one other URL that I'm aware of that appears to be hard coded: the search pages. Could similar logic that's been discussed so far for the map be applicable for search as well? Or is there a better solution? -Dahlia On Tue, Dec 8, 2009 at 5:23 AM, Suzy Deffeyes wrote: > I originally added the map tile cap to my Snowglobe 1.3 wishlist > because currently when http texture fetches are enabled, OpenSim users > get completely wrong map tiles. That's just rude for them. I wanted > to fix it for existing OpenSim grids, so they could implement serving > the correct map tiles via http. > > I wasn't thinking of it as vwrap related, although it does illustrate > the interesting dance from udp to http, and some of the issues with > that. > > Can we make a simple fix for OpenSim now that will still work with the > existing Linden grid, irrespective of vwrap? > > Suzy/Pixel > > Sent from my iPhone > > On Dec 6, 2009, at 6:33 PM, Carlo Wood wrote: > > > On Sat, Dec 05, 2009 at 04:30:10PM -0800, Suzy Deffeyes wrote: > >> If the code defaults to the existing hardcoded amazon behavior if a > >> cap to map tiles is not returned, then it doesn't require a LL > >> protocol change. > > > > There will be a time that not all OTHER implementations (ie opensim) > > have implemented this; in which case the cap will fail. > > > > In that case we want to fall back to the OLD way maps worked, > > because that is what works on opensim, at least - on opensim. > > > > Hence, this would require "detection" of on which network > > we are, and then adjust the "protocol" as required... > > > > I just wrote a long post about this horror (believe, it will > > happen again and again and again and the list of this type > > of things will only get LONGER and LONGER!). > > > > What we need, from the very start, is a good protocol > > negotiation sheme added to VWRAP (the new name for OGP). > > > > The protocol negotion sheme that I have proposed would > > make it clear what the base protocol is (the mandatory > > features so to say), as each server implementation gets > > it's own label (ie, LindenLab and OpenSim (as well as > > version numbers of course)). Then you could indeed say: > > > > Hey, opensim doesn't offer the feature "NewMap", so > > we use the old style map. And, hey, LindenLab doesn't > > offer the feature "NewMapURL", so we just use the S3 > > url as fall back (for the mandatory "NewMap" feature). > > > > Also, "NewMap" is really optional at the moment (the > > 1.23 viewers don't use it)... If the protocol negotiation > > had already been in place, then LL would have added > > an optional "NewMap" feature, with documentation, at > > the same time that it became available. The 1.23 viewer > > would not have known what it was and wouldn't use it, > > snowglobe would and would use it. THEN, on opensim, > > snowglobe would see that there isn't an optional > > "NewMap" feature and would NOT use the new map style. > > > > This demonstrates the power, and need, for protocol > > negotiation. > > > > At some later date, LL would add support for the new > > map also to the official viewers and make the feature > > mandatory (so that everyone with a client that doesn't > > support it has to upgrade). With the protocol negotiation > > that I proposed, the whole "NewMap" option would disappear > > from the actual negotiation (the documentation would > > still be there though, on the net ;), as if it had > > been a part of the protocol like everything else > > mandatory (ie, support for teleporting). > > > > -- > > Carlo Wood > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091209/87122eab/attachment.htm From aimee.trescothick at gmail.com Wed Dec 9 05:06:01 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Wed, 9 Dec 2009 13:06:01 +0000 Subject: [sldev] Blowing wind In-Reply-To: <78f69850912082146u504f96c6g76c15f702f088eb0@mail.gmail.com> References: <91E137EF-6B9B-4EEE-8C24-939C108DA7A6@ama-zing.co.uk> <31E66752-7593-43F0-A68D-E5EAE13CBECB@gmail.com> <78f69850912082146u504f96c6g76c15f702f088eb0@mail.gmail.com> Message-ID: <3896A609-1194-4A4E-B06F-E1E719AFBBEF@gmail.com> On 9 Dec 2009, at 05:46, Philippe (Merov) Bossut wrote: > Hi Aimee, > > I haven't looked in the code, just assumed you copied the relevant parts :) > > It seems to me that the intent of the code is to write in "newbuffer" by packets of "sizeof(MIXBUFFERFORMAT_T) == stride" bytes using "cursamplep" as a sliding pointer. That said then, having "stride == 4" when "MIXBUFFERFORMAT_T" is defined as S16 seems wrong. > > So the question is: why is "stride" set independently of "sizeof(MIXBUFFERFORMAT_T)"? Are there any situation where those 2 things need to be different? Looking at how "stride" is set should give you a hint. MIXBUFFERFORMAT and stride are only set with: #if LL_DARWIN typedef S32 MIXBUFFERFORMAT; #else typedef S16 MIXBUFFERFORMAT; #endif and ... #if LL_DARWIN stride = sizeof(LLAudioEngine_FMOD::MIXBUFFERFORMAT); #else int mixertype = FSOUND_GetMixer(); if (mixertype == FSOUND_MIXER_BLENDMODE || mixertype == FSOUND_MIXER_QUALITY_FPU) { stride = 4; } else { stride = 2; } #endif So stride seems only to be used as a (broken) hack when MIXBUFFERFORMAT is S16 and one of those two 32-bit mixer formats is in use, one of which wants S32, the other which wants F32. If on my Mac I set MIXBUFFERFORMAT to S16 and stride to 4, which should be the same result as a PC using FSOUND_MIXER_BLENDMODE, the result is a really horrible noise, as I would expect. Aimee. From josh at lindenlab.com Wed Dec 9 11:17:39 2009 From: josh at lindenlab.com (Joshua Bell) Date: Wed, 9 Dec 2009 11:17:39 -0800 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> <20091207003350.GA5500@alinoe.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> Message-ID: Dropping the IETF list... Even in lieu of Linden exposing caps for map services (or search, or...), it is reasonable to prototype the implementation of such services and integrate support for those services into Snowglobe. (Disclaimer: when I write "cap" here I'm talking generally about service endpoints which may or may not be cryptographically generated and permission-based.) The typical pattern has been to take client (pseudo-)code such as this: use_hardcoded_endpoint_for_foo(); And replace it with: if (has_cap_for_foo) use_cap_for_foo(); else use_hardcoded_endpoint_for_foo(); When all service providers are generating the cap, the hardcoded client code can optionally be removed (a cause for celebration). (In practice the code structure is usually gnarlier, since we're not talking about swapping URLs but replacing a custom UDP request/response protocol that may not be clearly factored with a nicely encapsulated HTTP request/response model. But logically, it's the same.) If we determine that the cap needs to change - perhaps the prototyped design can't be adopted as-is by Linden for some reason, or the cap is rev'd in some incompatible way (even given the version skew-combating super-powers of LLSD), then the client code would be updated to be: if (has_cap_for_foo2) use_cap_for_foo2(); else if (has_cap_for_foo) use_cap_for_foo(); else use_hardcoded_endpoint_for_foo(); (And ideally the client code that embodies this logic is nicely encapsulated so that these tests aren't repeated. Regardless, this is an extremely common pattern for exactly this capability-probing situation.) Suzy asks: "Can we make a simple fix for OpenSim now that will still work with the existing Linden grid, irrespective of vwrap?" I would suggest: yes! (1) Implement the cap on the server side (2) Implement the client side code to use it (3) Share the design here/JIRA for community review (4) Push the patch to Snowglobe via JIRA (5) If the client needs to support a different cap in the future e.g. for Linden, the model above would be followed. On Wed, Dec 9, 2009 at 7:08 AM, David W Levine wrote: > > I honestly can't imagine why we wouldn't. Hard coded singletons are totally > silly in a world that's growing towards interoperability. > - David > ~ Zha > > > > *Dahlia Trimble * > Sent by: ogpx-bounces at ietf.org > > 12/09/2009 03:27 AM > To > "sldev at lists.secondlife.com" > cc > "ogpx at ietf.org" > Subject > Re: [ogpx] [sldev] Snowglobe on OpenSim grids > > > > > Along the same lines of the hard coded map URL, there's one other URL that > I'm aware of that appears to be hard coded: the search pages. Could similar > logic that's been discussed so far for the map be applicable for search as > well? Or is there a better solution? > > -Dahlia > > On Tue, Dec 8, 2009 at 5:23 AM, Suzy Deffeyes <*suzyque at gmail.com*> > wrote: > I originally added the map tile cap to my Snowglobe 1.3 wishlist > because currently when http texture fetches are enabled, OpenSim users > get completely wrong map tiles. That's just rude for them. I wanted > to fix it for existing OpenSim grids, so they could implement serving > the correct map tiles via http. > > I wasn't thinking of it as vwrap related, although it does illustrate > the interesting dance from udp to http, and some of the issues with > that. > > Can we make a simple fix for OpenSim now that will still work with the > existing Linden grid, irrespective of vwrap? > > Suzy/Pixel > > Sent from my iPhone > > On Dec 6, 2009, at 6:33 PM, Carlo Wood <*carlo at alinoe.com*> > wrote: > > > On Sat, Dec 05, 2009 at 04:30:10PM -0800, Suzy Deffeyes wrote: > >> If the code defaults to the existing hardcoded amazon behavior if a > >> cap to map tiles is not returned, then it doesn't require a LL > >> protocol change. > > > > There will be a time that not all OTHER implementations (ie opensim) > > have implemented this; in which case the cap will fail. > > > > In that case we want to fall back to the OLD way maps worked, > > because that is what works on opensim, at least - on opensim. > > > > Hence, this would require "detection" of on which network > > we are, and then adjust the "protocol" as required... > > > > I just wrote a long post about this horror (believe, it will > > happen again and again and again and the list of this type > > of things will only get LONGER and LONGER!). > > > > What we need, from the very start, is a good protocol > > negotiation sheme added to VWRAP (the new name for OGP). > > > > The protocol negotion sheme that I have proposed would > > make it clear what the base protocol is (the mandatory > > features so to say), as each server implementation gets > > it's own label (ie, LindenLab and OpenSim (as well as > > version numbers of course)). Then you could indeed say: > > > > Hey, opensim doesn't offer the feature "NewMap", so > > we use the old style map. And, hey, LindenLab doesn't > > offer the feature "NewMapURL", so we just use the S3 > > url as fall back (for the mandatory "NewMap" feature). > > > > Also, "NewMap" is really optional at the moment (the > > 1.23 viewers don't use it)... If the protocol negotiation > > had already been in place, then LL would have added > > an optional "NewMap" feature, with documentation, at > > the same time that it became available. The 1.23 viewer > > would not have known what it was and wouldn't use it, > > snowglobe would and would use it. THEN, on opensim, > > snowglobe would see that there isn't an optional > > "NewMap" feature and would NOT use the new map style. > > > > This demonstrates the power, and need, for protocol > > negotiation. > > > > At some later date, LL would add support for the new > > map also to the official viewers and make the feature > > mandatory (so that everyone with a client that doesn't > > support it has to upgrade). With the protocol negotiation > > that I proposed, the whole "NewMap" option would disappear > > from the actual negotiation (the documentation would > > still be there though, on the net ;), as if it had > > been a part of the protocol like everything else > > mandatory (ie, support for teleporting). > > > > -- > > Carlo Wood <*carlo at alinoe.com* > > _______________________________________________ > Policies and (un)subscribe information available here:* > **http://wiki.secondlife.com/wiki/SLDev* > Please read the policies before posting to keep unmoderated posting > privileges > _______________________________________________ > ogpx mailing list > ogpx at ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx at ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091209/1dfca131/attachment-0001.htm From merov at lindenlab.com Wed Dec 9 19:00:58 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Wed, 9 Dec 2009 19:00:58 -0800 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> <20091207003350.GA5500@alinoe.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> Message-ID: <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> Hi, +1 on Josh's proposal. This is certainly something we should be doing though, clearly, there's work server side as for what that cap is and returns... So, server folks, please shoot first :) In the meantime, on the client side, we can prepare this. There's only one occurrence of the guilty string (in llworldmipmap) and LLWorldMipmap seems to be the right class to introduce a getURLFromPosition(U32 grid_x, U32 grid_y, S32 level) that would implement Josh's pattern. There is already a SNOW bug mind you to cover this though it was written in the context of the aditi grid: https://jira.secondlife.com/browse/SNOW-77 More detailed proposals (and hopefully patches... :) ) should be added in that PJIRA. Cheers, - Merov On Wed, Dec 9, 2009 at 11:17 AM, Joshua Bell wrote: > Dropping the IETF list... > > Even in lieu of Linden exposing caps for map services (or search, or...), > it is reasonable to prototype the implementation of such services and > integrate support for those services into Snowglobe. > > (Disclaimer: when I write "cap" here I'm talking generally about service > endpoints which may or may not be cryptographically generated and > permission-based.) > > The typical pattern has been to take client (pseudo-)code such as this: > > use_hardcoded_endpoint_for_foo(); > > And replace it with: > > if (has_cap_for_foo) > use_cap_for_foo(); > else > use_hardcoded_endpoint_for_foo(); > > When all service providers are generating the cap, the hardcoded client > code can optionally be removed (a cause for celebration). > > (In practice the code structure is usually gnarlier, since we're not > talking about swapping URLs but replacing a custom UDP request/response > protocol that may not be clearly factored with a nicely encapsulated HTTP > request/response model. But logically, it's the same.) > > If we determine that the cap needs to change - perhaps the prototyped > design can't be adopted as-is by Linden for some reason, or the cap is rev'd > in some incompatible way (even given the version skew-combating super-powers > of LLSD), then the client code would be updated to be: > > if (has_cap_for_foo2) > use_cap_for_foo2(); > else if (has_cap_for_foo) > use_cap_for_foo(); > else > use_hardcoded_endpoint_for_foo(); > > (And ideally the client code that embodies this logic is nicely > encapsulated so that these tests aren't repeated. Regardless, this is an > extremely common pattern for exactly this capability-probing situation.) > > Suzy asks: "Can we make a simple fix for OpenSim now that will still work > with the existing Linden grid, irrespective of vwrap?" > > I would suggest: yes! > > (1) Implement the cap on the server side > (2) Implement the client side code to use it > (3) Share the design here/JIRA for community review > (4) Push the patch to Snowglobe via JIRA > (5) If the client needs to support a different cap in the future e.g. for > Linden, the model above would be followed. > > On Wed, Dec 9, 2009 at 7:08 AM, David W Levine wrote: > >> >> I honestly can't imagine why we wouldn't. Hard coded singletons are >> totally silly in a world that's growing towards interoperability. >> - David >> ~ Zha >> >> >> >> *Dahlia Trimble * >> Sent by: ogpx-bounces at ietf.org >> >> 12/09/2009 03:27 AM >> To >> "sldev at lists.secondlife.com" >> cc >> "ogpx at ietf.org" >> Subject >> Re: [ogpx] [sldev] Snowglobe on OpenSim grids >> >> >> >> >> Along the same lines of the hard coded map URL, there's one other URL that >> I'm aware of that appears to be hard coded: the search pages. Could similar >> logic that's been discussed so far for the map be applicable for search as >> well? Or is there a better solution? >> >> -Dahlia >> >> On Tue, Dec 8, 2009 at 5:23 AM, Suzy Deffeyes <*suzyque at gmail.com*> >> wrote: >> I originally added the map tile cap to my Snowglobe 1.3 wishlist >> because currently when http texture fetches are enabled, OpenSim users >> get completely wrong map tiles. That's just rude for them. I wanted >> to fix it for existing OpenSim grids, so they could implement serving >> the correct map tiles via http. >> >> I wasn't thinking of it as vwrap related, although it does illustrate >> the interesting dance from udp to http, and some of the issues with >> that. >> >> Can we make a simple fix for OpenSim now that will still work with the >> existing Linden grid, irrespective of vwrap? >> >> Suzy/Pixel >> >> Sent from my iPhone >> >> On Dec 6, 2009, at 6:33 PM, Carlo Wood <*carlo at alinoe.com*> >> wrote: >> >> > On Sat, Dec 05, 2009 at 04:30:10PM -0800, Suzy Deffeyes wrote: >> >> If the code defaults to the existing hardcoded amazon behavior if a >> >> cap to map tiles is not returned, then it doesn't require a LL >> >> protocol change. >> > >> > There will be a time that not all OTHER implementations (ie opensim) >> > have implemented this; in which case the cap will fail. >> > >> > In that case we want to fall back to the OLD way maps worked, >> > because that is what works on opensim, at least - on opensim. >> > >> > Hence, this would require "detection" of on which network >> > we are, and then adjust the "protocol" as required... >> > >> > I just wrote a long post about this horror (believe, it will >> > happen again and again and again and the list of this type >> > of things will only get LONGER and LONGER!). >> > >> > What we need, from the very start, is a good protocol >> > negotiation sheme added to VWRAP (the new name for OGP). >> > >> > The protocol negotion sheme that I have proposed would >> > make it clear what the base protocol is (the mandatory >> > features so to say), as each server implementation gets >> > it's own label (ie, LindenLab and OpenSim (as well as >> > version numbers of course)). Then you could indeed say: >> > >> > Hey, opensim doesn't offer the feature "NewMap", so >> > we use the old style map. And, hey, LindenLab doesn't >> > offer the feature "NewMapURL", so we just use the S3 >> > url as fall back (for the mandatory "NewMap" feature). >> > >> > Also, "NewMap" is really optional at the moment (the >> > 1.23 viewers don't use it)... If the protocol negotiation >> > had already been in place, then LL would have added >> > an optional "NewMap" feature, with documentation, at >> > the same time that it became available. The 1.23 viewer >> > would not have known what it was and wouldn't use it, >> > snowglobe would and would use it. THEN, on opensim, >> > snowglobe would see that there isn't an optional >> > "NewMap" feature and would NOT use the new map style. >> > >> > This demonstrates the power, and need, for protocol >> > negotiation. >> > >> > At some later date, LL would add support for the new >> > map also to the official viewers and make the feature >> > mandatory (so that everyone with a client that doesn't >> > support it has to upgrade). With the protocol negotiation >> > that I proposed, the whole "NewMap" option would disappear >> > from the actual negotiation (the documentation would >> > still be there though, on the net ;), as if it had >> > been a part of the protocol like everything else >> > mandatory (ie, support for teleporting). >> > >> > -- >> > Carlo Wood <*carlo at alinoe.com* > >> _______________________________________________ >> Policies and (un)subscribe information available here:* >> **http://wiki.secondlife.com/wiki/SLDev* >> Please read the policies before posting to keep unmoderated posting >> privileges >> _______________________________________________ >> ogpx mailing list >> ogpx at ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx at ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091209/69ceb96c/attachment.htm From merov at lindenlab.com Wed Dec 9 20:25:24 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Wed, 9 Dec 2009 20:25:24 -0800 Subject: [sldev] SNOW-238 : Add SOCKS 5 proxy support Message-ID: <78f69850912092025i78dc5eb4n740ab3e9c70302ff@mail.gmail.com> Hi, At the last Hippo meeting someone asked if anything happened there and, indeed, it has: there's now a patch, an assigned committer (Robin) and questions on the pref UI: https://jira.secondlife.com/browse/SNOW-238 Folks interested to contribute to the solution should read the PJIRA and chime in. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091209/729389c5/attachment.htm From merov at lindenlab.com Wed Dec 9 22:39:52 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Wed, 9 Dec 2009 22:39:52 -0800 Subject: [sldev] Small easy target features to consider for Snowglobe Message-ID: <78f69850912092239i44cc590u5cd5b3ce0fc02b8@mail.gmail.com> Hi, It was suggested to me that some small relatively easy to hack features would be cool addition to Snowglobe. Additionally, those are small, limited tweaks to existing functionality so they should be nice targets for would be contributors looking for first contributions. Here are those 3 features: SNOW-386 : Improve "Show look at" feature : We have this under the Advanced menu as a debug feature already but it needs some polish to look less "geeky". I added some ideas of improvements suggestions in the JIRA record. Seems like an easy target as there's code already in there that just need love. VWR-7427 : Allow custom texture for selection beam particles : This is a year old request. Got some votes, no patch. The related code looks very small and easily hackable (I checked tonight). I'm not convinced of the importance of this as a feature but it's an easy and truly cool "first contribution" target :) VWR-7604: Suggested behaviour change for "Sit here" when targeting the ground : The JIRA description makes a lot of sense and is very clear. No patch though. That one is a feature I would use for sure. I haven't looked in the code but it seems possible to expand from the existing "Sit here" behavior (at least, start to understand that before moving to expand it). Any takers? Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091209/d12aeb35/attachment.htm From merov at lindenlab.com Wed Dec 9 22:58:14 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Wed, 9 Dec 2009 22:58:14 -0800 Subject: [sldev] Snowglobe 1.3 patches waiting for your love Message-ID: <78f69850912092258y5e87138br327bc5165c7ce926@mail.gmail.com> Hi, If you look at the Snowglobe 1.3 bug/feature log ( https://jira.secondlife.com/browse/SNOW), you'll see that out of 43 records, 9 have patches attached. 9! This is nice but things are not moving much without your help (see "Snowglobe Process Development" at http://wiki.secondlife.com/wiki/HTTP_Texture_Development): - committers: you know who you are :) (it's here http://wiki.secondlife.com/wiki/Snowglobe_Committer_List for the curious...). Please review patches posted by others, especially non-committers, and comment back if changes are required. If everything is cool on a patch, you can commit to trunk (don't wait for my stamp of approval). - contributors: please answer to reviews and comments in a timely manner if you want your patch to make it to 1.3. - everybody else: if you build Snowglobe, feel free to apply patches on your machine, test and report in JIRA. All tests help contributors and committers to expedite the commit to trunk process. This is an open source communal project folks so your participation is highly valued and appreciated. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091209/b603fb0e/attachment-0001.htm From carlo at alinoe.com Thu Dec 10 05:33:19 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 10 Dec 2009 14:33:19 +0100 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> <20091207003350.GA5500@alinoe.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> Message-ID: <20091210133319.GA2419@alinoe.com> > On Wed, Dec 9, 2009 at 11:17 AM, Joshua Bell wrote: > And replace it with: > > if (has_cap_for_foo) > use_cap_for_foo(); > else > use_hardcoded_endpoint_for_foo(); This would still fail on opensim, since it would do the same as it is doing now-- which doesn't work. [...] > If we determine that the cap needs to change - perhaps the prototyped > design can't be adopted as-is by Linden for some reason, or the cap is > rev'd in some incompatible way (even given the version skew-combating > super-powers of LLSD), then the client code would be updated to be: > > if (has_cap_for_foo2) > use_cap_for_foo2(); > else if (has_cap_for_foo) > use_cap_for_foo(); > else > use_hardcoded_endpoint_for_foo(); What about using feature negotiation? We only have to agree on it, implement it once, and we'll have forever a powerful way to negotiate ANYTHING we might need in the future where the client-server protocol is a function of -basically- version numbers of each. Instead of if (has_cap_for_foo6) use_cap_for_foo6(); else if (has_cap_for_foo5) use_cap_for_foo5(); else if (has_cap_for_foo4) use_cap_for_foo4(); else if (has_cap_for_foo3) use_cap_for_foor3(); else if (has_cap_for_foo2) use_cap_for_foo2(); else if (has_cap_for_foo) use_cap_for_foo(); else use_hardcoded_endpoint_for_foo(); where each "has_cap_*" needs to be probed separately, you could just directly negotiate whatever is needed (which is so powerful, you can change the protocol to ANYthing, so there isn't really a need for examples). > (And ideally the client code that embodies this logic is nicely > encapsulated so that these tests aren't repeated. Regardless, this is an > extremely common pattern for exactly this capability-probing situation.) > > Suzy asks: "Can we make a simple fix for OpenSim now that will still work > with the existing Linden grid, irrespective of vwrap?" > > I would suggest: yes! She asked 'now'... which means with the current opensim version. > (1) Implement the cap on the server side > (2) Implement the client side code to use it > (3) Share the design here/JIRA for community review > (4) Push the patch to Snowglobe via JIRA > (5) If the client needs to support a different cap in the future e.g. for > Linden, the model above would be followed. How would that cause map the work on opensim? The only way to make it work now on opensim is, in pseudo code: if (has_cap_for_foo) use_cap_for_foo(); else if (second_life_grid) use_hardcoded_endpoint_for_foo(); else use_old_map_style(); -- Carlo Wood From tofu at lindenlab.com Thu Dec 10 07:31:42 2009 From: tofu at lindenlab.com (Tofu Linden) Date: Thu, 10 Dec 2009 07:31:42 -0800 Subject: [sldev] Blowing wind In-Reply-To: <31E66752-7593-43F0-A68D-E5EAE13CBECB@gmail.com> References: <91E137EF-6B9B-4EEE-8C24-939C108DA7A6@ama-zing.co.uk> <31E66752-7593-43F0-A68D-E5EAE13CBECB@gmail.com> Message-ID: <4B21145E.8040004@lindenlab.com> I don't have time to investigate properly, but my first guess would be that this is because our wind is stereo (interleaved MIXBUFFERFORMAT_Ts). Aimee Trescothick wrote: > Can anyone explain how the below piece of the existing code from the wind noise synthesizer has ever actually worked properly, with MIXBUFFERFORMAT_T defined as S16 and stride set to 4 bytes? > > U8 *cursamplep = (U8*)newbuffer; > ... > > MIXBUFFERFORMAT_T sample; > ... > > sample = llfloor(((F32)nextSample*32768.f*(1.0f - mCurrentPanGainR))+0.5f); > *(MIXBUFFERFORMAT_T*)cursamplep = llclamp(sample, (MIXBUFFERFORMAT_T)-32768, > (MIXBUFFERFORMAT_T)32767); > cursamplep += stride; > > sample = llfloor(((F32)nextSample*32768.f*mCurrentPanGainR)+0.5f); > *(MIXBUFFERFORMAT_T*)cursamplep = llclamp(sample, (MIXBUFFERFORMAT_T)-32768, > (MIXBUFFERFORMAT_T)32767); > cursamplep += stride; > > On Windows and Linux MIXBUFFERFORMAT_T is defined as S16, and if the FMOD mixer mode is FSOUND_MIXER_QUALITY_FPU or FSOUND_MIXER_BLENDMODE, stride is set to 4 bytes, as these modes both use a 32-bit mix buffer. > > But as far as I can see, that's just going to write signed 16-bit integers into the first two bytes of the 4-byte sample, skipping over the other two bytes, leaving them at whatever they were before (zero, as wind is the first thing that goes in the buffer after it is cleared). When FMOD tries to read the 4-bytes back as either 32-bit signed integers (FSOUND_MIXER_BLENDMODE), or 32-bit float (FSOUND_MIXER_QUALITY_FPU) that's just going to go horribly wrong. > > MIXBUFFERFORMAT_T is only defined as S32 on the Mac, on Windows and Linux it is S16 as one of FMOD's 16-bit MMX mixers is normally used. The only time I would imagine this situation occurs is on a PC without MMX (or when LL_VALGRIND is defined on Linux for testing, which specifically forces the mixer mode to FSOUND_MIXER_QUALITY_FPU). > > If this has never worked anyway, it would seem to make sense to turn off the wind generator for these mixer modes to avoid making a horrible noise, drop the striding which will simplify things elsewhere, and just declare cursamplep as MIXBUFFERFORMAT_T in the first place, removing the need to typecast it ... or am I missing something? > > (If you followed me this far you're doing better than I am :) > > Aimee. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From Sigurd.Van_Broeck at alcatel-lucent.com Thu Dec 10 08:00:07 2009 From: Sigurd.Van_Broeck at alcatel-lucent.com (VAN BROECK Sigurd) Date: Thu, 10 Dec 2009 17:00:07 +0100 Subject: [sldev] UDP Receiver: GL error: Invalid Operation Message-ID: <7A6D4815C5E8F74988784FEBD50F2F1E0460A30A@FRVELSMBS22.ad2.ad.alcatel.com> We've been using the Quicktime library of the Hippo Viewer to get media streams into SL. Since we need more control over the streams, we implemented a simple UDP receiver that's in coding identical to the llmediaimplquicktime (except for the Quicktime library calls of course) and that works just fine. The media packets are arriving over UDP and can be displayed using the OpenCV library. However, as soon as we access the GL functions from the UDP receiver thread, we get GL error 'invalid operation'. Debugging learns that we access the GL functions inbetween glBegin() and glEnd() being called probably by the existing Hippo rendering thread(s). Question is then of course how we can avoid making calls at the wrong time. We don't really see how the Quicktime library accomplishes that. Is there somewhere a synchronization mechanism that we must use? Thanks for helping out, Sigurd -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091210/f11396f5/attachment.htm From tofu at lindenlab.com Thu Dec 10 09:17:15 2009 From: tofu at lindenlab.com (Tofu Linden) Date: Thu, 10 Dec 2009 09:17:15 -0800 Subject: [sldev] UDP Receiver: GL error: Invalid Operation In-Reply-To: <7A6D4815C5E8F74988784FEBD50F2F1E0460A30A@FRVELSMBS22.ad2.ad.alcatel.com> References: <7A6D4815C5E8F74988784FEBD50F2F1E0460A30A@FRVELSMBS22.ad2.ad.alcatel.com> Message-ID: <4B212D1B.4030402@lindenlab.com> Personally I'd recommend only making GL calls from a single thread - otherwise you'll have to do a lot of locking or keep two utterly separated GL contexts. I don't totally understand what you're trying to achieve though - it's not obvious to me why your media code would have to perform actual GL calls (usually you'd hand your media buffer over to the app and the app itself does the GL rendering). I admit I'm also fuzzy on what the 'Hippo Viewer' is based upon; I'd recommend working from a recent Snowglobe tree where the media system is rather different (better - safer and more extensible, I hope) than our legacy one. VAN BROECK Sigurd wrote: > We've been using the Quicktime library of the Hippo Viewer to get media > streams into SL. Since we need more control over the streams, we > implemented a simple UDP receiver that's in coding identical to the > llmediaimplquicktime (except for the Quicktime library calls of course) > and that works just fine. The media packets are arriving over UDP and > can be displayed using the OpenCV library. However, as soon as we access > the GL functions from the UDP receiver thread, we get GL error 'invalid > operation'. > > Debugging learns that we access the GL functions inbetween glBegin() and > glEnd() being called probably by the existing Hippo rendering thread(s). > Question is then of course how we can avoid making calls at the wrong > time. We don't really see how the Quicktime library accomplishes that. > Is there somewhere a synchronization mechanism that we must use? > > Thanks for helping out, > Sigurd > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From brickrte at hughes.net Thu Dec 10 11:15:41 2009 From: brickrte at hughes.net (Laurence Brickner) Date: Thu, 10 Dec 2009 14:15:41 -0500 Subject: [sldev] Help getting started Message-ID: <92B53B24B0034C8E805E5AEB36B8FF50@LRBXPS> Thanks Merov and hi to everyone, Here are three examples of the error types I'm getting. fatal error LNK1104: cannot open file 'libboost_signals-vc90-mt-gd-1_39.lib' llworldmipmap_test error PRJ0019: A tool returned an error code from "Generating llagentaccess_test_ok.txt" llagentaccess_test_ok error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Container_base::_Container_base(void)" (__imp_??0_Container_base at std@@QAE at XZ) llqtwebkitd.lib Any help would be great. Thanks, Shorahmin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091210/004fce25/attachment.htm From robertltux at gmail.com Thu Dec 10 11:19:37 2009 From: robertltux at gmail.com (Robert Martin) Date: Thu, 10 Dec 2009 14:19:37 -0500 Subject: [sldev] Fwd: Help getting started In-Reply-To: References: <92B53B24B0034C8E805E5AEB36B8FF50@LRBXPS> Message-ID: On Thu, Dec 10, 2009 at 2:15 PM, Laurence Brickner wrote: > Thanks Merov and hi to everyone, > > > > Here are three examples of the error types I?m getting. > > > > fatal error LNK1104: cannot open file > 'libboost_signals-vc90-mt-gd-1_39.lib'???????? llworldmipmap_test > > > > error PRJ0019: A tool returned an error code from "Generating > llagentaccess_test_ok.txt"??????????? llagentaccess_test_ok > > > > error LNK2001: unresolved external symbol "__declspec(dllimport) public: > __thiscall std::_Container_base::_Container_base(void)" > (__imp_??0_Container_base at std@@QAE at XZ)??????????? llqtwebkitd.lib > > > side note to this does anybody have info as to what would be needed to make a build platform with CURRENT tools (like VS 2008) and has the Boost Hell problem been fixed?? -- Robert L Martin From josh at lindenlab.com Thu Dec 10 11:24:28 2009 From: josh at lindenlab.com (Joshua Bell) Date: Thu, 10 Dec 2009 11:24:28 -0800 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: <20091210133319.GA2419@alinoe.com> References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> <20091207003350.GA5500@alinoe.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> Message-ID: On Thu, Dec 10, 2009 at 5:33 AM, Carlo Wood wrote: > (1) Implement the cap on the server side > > (2) Implement the client side code to use it > > (3) Share the design here/JIRA for community review > > (4) Push the patch to Snowglobe via JIRA > > (5) If the client needs to support a different cap in the future e.g. > for > > Linden, the model above would be followed. > > How would that cause map the work on opensim? > > Sorry, I should have been more explicit about Step 1. By "on the server side" I meant "in OpenSim". An OpenSim developer could add the cap, then Snowglobe could use it if present. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091210/7c8c156e/attachment.htm From deltalp at gmail.com Thu Dec 10 11:39:56 2009 From: deltalp at gmail.com (amh) Date: Thu, 10 Dec 2009 14:39:56 -0500 Subject: [sldev] libsecondlife / libopenmetaverse bots problem? Message-ID: <3dd38e2d0912101139o2076779duc070e633314dd91c@mail.gmail.com> The last couple of weeks I have been having problems with rezzing bots in SL. They either do not rez at all -- stay in a "cloud stage" (95% of the cases) or take extremely long time to rez and their appearance doesn't rez. Is it something due to changes in the SL (server? client?), network overload at SL NOC? Does anybody have an idea? Thank you, Alex Heiphetz / AHG Hallard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091210/fdb4baa3/attachment.htm From brickrte at hughes.net Thu Dec 10 12:36:45 2009 From: brickrte at hughes.net (Laurence Brickner) Date: Thu, 10 Dec 2009 15:36:45 -0500 Subject: [sldev] My Trials and Tribs Message-ID: <796B1B47705B43E58C3FE4C2682F8A4E@LRBXPS> I should have told you that I'm using VS2008. Is that a show-stopper? Shor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091210/5ae1ea40/attachment.htm From robin.cornelius at gmail.com Thu Dec 10 12:42:06 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu, 10 Dec 2009 20:42:06 +0000 Subject: [sldev] My Trials and Tribs In-Reply-To: <796B1B47705B43E58C3FE4C2682F8A4E@LRBXPS> References: <796B1B47705B43E58C3FE4C2682F8A4E@LRBXPS> Message-ID: <4B215D1E.3060608@gmail.com> Laurence Brickner wrote: > I should have told you that I?m using VS2008. Is that a show-stopper? > Currently yes, 2008 is a PITA as is 2010 due to boost.The reason is that boost consists of C++ libraries which need to be compiled by the version of the compiler that you are using for the rest of the application, in this case 2005. This issue is compounded on the 1.23 code base (inc snowglobe) by the use of a shared CRT. I would advise using 2005 still, you can grab the express from microsoft still but you need the initial link/mini setup.exe as that is now hidden. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20091210/a7825d09/attachment.pgp From missannotoole at yahoo.com Thu Dec 10 12:57:22 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu, 10 Dec 2009 12:57:22 -0800 (PST) Subject: [sldev] My Trials and Tribs In-Reply-To: <4B215D1E.3060608@gmail.com> References: <796B1B47705B43E58C3FE4C2682F8A4E@LRBXPS> <4B215D1E.3060608@gmail.com> Message-ID: <441643.84524.qm@web59108.mail.re1.yahoo.com> Where do we get "the initial link/mini setup.exe as that is now hidden"? ________________________________ From: Robin Cornelius To: brickrte at odyssey.net Cc: Life DEv Second Sent: Thu, December 10, 2009 3:42:06 PM Subject: Re: [sldev] My Trials and Tribs Laurence Brickner wrote: > I should have told you that I?m using VS2008. Is that a show-stopper? > Currently yes, 2008 is a PITA as is 2010 due to boost.The reason is that boost consists of C++ libraries which need to be compiled by the version of the compiler that you are using for the rest of the application, in this case 2005. This issue is compounded on the 1.23 code base (inc snowglobe) by the use of a shared CRT. I would advise using 2005 still, you can grab the express from microsoft still but you need the initial link/mini setup.exe as that is now hidden. Robin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091210/bb2c0e97/attachment.htm From brickrte at hughes.net Thu Dec 10 13:26:52 2009 From: brickrte at hughes.net (Laurence Brickner) Date: Thu, 10 Dec 2009 16:26:52 -0500 Subject: [sldev] My Trials and Tribs In-Reply-To: <4B215D1E.3060608@gmail.com> References: <796B1B47705B43E58C3FE4C2682F8A4E@LRBXPS> <4B215D1E.3060608@gmail.com> Message-ID: <42A5979A1AF7441DBBEA38C16C7C5553@LRBXPS> Robin, Thanks. I uninstalled 2005 about 6 months ago, but somewhere in that vast pile of CDs I get from Mother Microsoft every month is an install CD for the Full 2005. Is it worth looking for or is the express version sufficient. Shor -----Original Message----- From: Robin Cornelius [mailto:robin.cornelius at gmail.com] Sent: Thursday, December 10, 2009 15:42 To: brickrte at odyssey.net Cc: Life DEv Second Subject: Re: [sldev] My Trials and Tribs Laurence Brickner wrote: > I should have told you that I'm using VS2008. Is that a show-stopper? > Currently yes, 2008 is a PITA as is 2010 due to boost.The reason is that boost consists of C++ libraries which need to be compiled by the version of the compiler that you are using for the rest of the application, in this case 2005. This issue is compounded on the 1.23 code base (inc snowglobe) by the use of a shared CRT. I would advise using 2005 still, you can grab the express from microsoft still but you need the initial link/mini setup.exe as that is now hidden. Robin From merov at lindenlab.com Thu Dec 10 13:59:25 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Thu, 10 Dec 2009 13:59:25 -0800 Subject: [sldev] Snowglobe 1.3 patches waiting for your love In-Reply-To: <1e01733d0912100803v3d76cc03u45c5c9e3a3745eb1@mail.gmail.com> References: <78f69850912092258y5e87138br327bc5165c7ce926@mail.gmail.com> <1e01733d0912100803v3d76cc03u45c5c9e3a3745eb1@mail.gmail.com> Message-ID: <78f69850912101359l794cf696s86790be04dc7cd62@mail.gmail.com> Hi Aleric, On Thu, Dec 10, 2009 at 8:03 AM, Aleric Inglewood < aleric.inglewood at gmail.com> wrote: > Seems you broke compilation Philippe: > > >svn diff -r3047:3048 indra/media_plugins/webkit/media_plugin_webkit.cpp | > grep EKeyboardModifier > (standard input):219:+ LLQtWebKit::EKeyboardModifier > decodeModifiers(std::string &modifiers) > > indra/media_plugins/webkit/media_plugin_webkit.cpp:406: error: > ?EKeyboardModifier? in class ?LLQtWebKit? does not name a type > > What is going on here? > You have something that the rest of the open source coder don't? > If so, then wouldn't it be nice to communicate that on this list? > I suppose you meant that I broke the standalone builds as the parabuild servers and my own machines do build just fine. But your point is well taken: that llqtwebkit lib should be build-able from an up-to-date repo somewhere. I have to confess I do not build it myself so that's something I'll have to dig through. > You also STILL didn't answer this question (third time I ask): > Is there anyone on this list (from LL, so I'm asking you) who can decide > to change the server code / protocol? > First, about me, I do not do server side coding and am not involved in protocol evolution. There are plenty of Lindens though lurking on sldev and quite a few of them do work on server side code. That being said, no one changes the protocol willy nilly so it's not like anyone could point you to "xyz Linden" being "the one" making protocol changes. A lot of considerations come into play wrt protocol changes: support, backward compatibility, security, deployment just to name a few. IOW, your question cannot be answered simply which is certainly why no one answered it so far. What would be more productive though is to know which improvements you think would need protocol or server side changes and bring those issues into a discussion. I'm sure that if such a discussion was to start, the relevant Linden would jump in and comment as Josh did recently for instance on server cap on the map thread. Would that work with you? Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091210/30077dac/attachment.htm From merov at lindenlab.com Thu Dec 10 16:25:44 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Thu, 10 Dec 2009 16:25:44 -0800 Subject: [sldev] Small easy target features to consider for Snowglobe In-Reply-To: References: <78f69850912092239i44cc590u5cd5b3ce0fc02b8@mail.gmail.com> <78f69850912101000w6f5415camb989f8dd529662af@mail.gmail.com> Message-ID: <78f69850912101625j27663850lb5de3c8598feafcd@mail.gmail.com> Re-directing to sldev. - Merov On Thu, Dec 10, 2009 at 3:07 PM, Laurence Brickner wrote: > Hi all, > > > > Could someone aim me at the right area file wise for SNOW-386. BTW, I?m > re-installing 2005. > > > > Shor > > > > > > > ------------------------------ > > *From:* Philippe (Merov) Bossut [mailto:merov at lindenlab.com] > *Sent:* Thursday, December 10, 2009 13:00 > *To:* brickrte at odyssey.net > *Subject:* Re: [sldev] Small easy target features to consider for > Snowglobe > > > > Hi Shorahmin, > > Great to hear you're considering building and may be contributing to > Snowglobe. The best way to get support in building and getting things set up > is to email the sldev list: lots of great folks there with experience on all > sorts of build environments. > > Welcome to Snowglobe! > > Cheers, > - Merov > > On Thu, Dec 10, 2009 at 7:51 AM, Laurence Brickner > wrote: > > Hi all, (Hope I?m doing this right) > > I?ve just started trying to set up the environment etc. Using VS2008. > Lotsa C++ experience, now retired. > > > > The Show-Look thing looks like a great way to learn the whole cmake ? VSN ? > patchy ? thingy system. So if you have the patience, I?d like to give it a > shot. > > > > BTW, where could I get some TLC on setting up? Right now I get about 11 > unresolved externals. > > > > Shorahmin > > > > > ------------------------------ > > *From:* sldev-bounces at lists.secondlife.com [mailto: > sldev-bounces at lists.secondlife.com] *On Behalf Of *Philippe (Merov) Bossut > *Sent:* Thursday, December 10, 2009 01:40 > *To:* Second Life Developer Mailing List > *Subject:* [sldev] Small easy target features to consider for Snowglobe > > > > Hi, > > It was suggested to me that some small relatively easy to hack features > would be cool addition to Snowglobe. Additionally, those are small, limited > tweaks to existing functionality so they should be nice targets for would be > contributors looking for first contributions. Here are those 3 features: > > SNOW-386 : Improve "Show look at" feature : We have this under the Advanced > menu as a debug feature already but it needs some polish to look less > "geeky". I added some ideas of improvements suggestions in the JIRA record. > Seems like an easy target as there's code already in there that just need > love. > > VWR-7427 : Allow custom texture for selection beam particles : This is a > year old request. Got some votes, no patch. The related code looks very > small and easily hackable (I checked tonight). I'm not convinced of the > importance of this as a feature but it's an easy and truly cool "first > contribution" target :) > > VWR-7604: Suggested behaviour change for "Sit here" when targeting the > ground : The JIRA description makes a lot of sense and is very clear. No > patch though. That one is a feature I would use for sure. I haven't looked > in the code but it seems possible to expand from the existing "Sit here" > behavior (at least, start to understand that before moving to expand it). > > Any takers? > > Cheers, > - Merov > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091210/e3cab732/attachment-0001.htm From adam at deepthink.com.au Thu Dec 10 22:23:24 2009 From: adam at deepthink.com.au (Frisby, Adam) Date: Fri, 11 Dec 2009 01:23:24 -0500 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> <20091207003350.GA5500@alinoe.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> Message-ID: <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> (OpenSim hat) Give us a spec, and we?ll implement it pretty quickly & easily. We already have this data in a similar format for the various webmap APIs. From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Joshua Bell Sent: Thursday, 10 December 2009 11:24 AM To: Carlo Wood Cc: sldev at lists.secondlife.com; David W Levine; Dahlia Trimble Subject: Re: [sldev] [ogpx] Snowglobe on OpenSim grids On Thu, Dec 10, 2009 at 5:33 AM, Carlo Wood > wrote: > (1) Implement the cap on the server side > (2) Implement the client side code to use it > (3) Share the design here/JIRA for community review > (4) Push the patch to Snowglobe via JIRA > (5) If the client needs to support a different cap in the future e.g. for > Linden, the model above would be followed. How would that cause map the work on opensim? Sorry, I should have been more explicit about Step 1. By "on the server side" I meant "in OpenSim". An OpenSim developer could add the cap, then Snowglobe could use it if present. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091211/5d63b398/attachment.htm From dzonatas at gmail.com Thu Dec 10 22:55:28 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 10 Dec 2009 22:55:28 -0800 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> <20091207003350.GA5500@alinoe.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> Message-ID: <4B21ECE0.2010002@gmail.com> Wouldn't it be better if the map was a LLMediaPlugin. That way each map window can be customized to a grid. That would also mean each grid would load it's own viewer plugin. This would also allow one plugin to support legacy code while the another plugin can have code specific to a grid or caps. This could evolved further where topology across grids aren't even the same, the appropriate map plugin would display the correct topology. Cheers! Frisby, Adam wrote: > > (OpenSim hat) Give us a spec, and we?ll implement it pretty quickly & > easily. We already have this data in a similar format for the various > webmap APIs. > > > > *From:* sldev-bounces at lists.secondlife.com > [mailto:sldev-bounces at lists.secondlife.com] *On Behalf Of *Joshua Bell > *Sent:* Thursday, 10 December 2009 11:24 AM > *To:* Carlo Wood > *Cc:* sldev at lists.secondlife.com; David W Levine; Dahlia Trimble > *Subject:* Re: [sldev] [ogpx] Snowglobe on OpenSim grids > > > > On Thu, Dec 10, 2009 at 5:33 AM, Carlo Wood > wrote: > > > (1) Implement the cap on the server side > > (2) Implement the client side code to use it > > (3) Share the design here/JIRA for community review > > (4) Push the patch to Snowglobe via JIRA > > (5) If the client needs to support a different cap in the future > e.g. for > > Linden, the model above would be followed. > > How would that cause map the work on opensim? > > > Sorry, I should have been more explicit about Step 1. By "on the > server side" I meant "in OpenSim". An OpenSim developer could add the > cap, then Snowglobe could use it if present. > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From vector at leafpile.com Fri Dec 11 02:00:46 2009 From: vector at leafpile.com (Vector Hastings) Date: Fri, 11 Dec 2009 02:00:46 -0800 Subject: [sldev] Enabling llPointAt In-Reply-To: <78f69850912092239i44cc590u5cd5b3ce0fc02b8@mail.gmail.com> References: <78f69850912092239i44cc590u5cd5b3ce0fc02b8@mail.gmail.com> Message-ID: <001801ca7a48$cf94a620$6ebdf260$@com> Anybody want to fix this? Seems to me (though I'm no expert) that it'd be possible via a client-side hack. take the vector passed in lscript_library.cpp for script command llPointAt and feed back to the server a change in agent orientation as if the keyboard or mouse/flycam had made the necessary input. That would effectively 're-enable' this old, deprecated script command. (we can compile scripts with it which seems promising, though I haven't confirmed that the vector stored in the script is passed through the pipeline to the client.) There are big vote for this one! You could be a personal hero to so many (including me) J http://jira.secondlife.com/browse/SVC-56 (this Jira is classed as a new feature, but the script commands are there, so there's an argument for it being a broken feature, though I suppose the official wiki says it was never enabled, which makes it 'new.') Cheers to all, Vector From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Philippe (Merov) Bossut Sent: Wednesday, December 09, 2009 10:40 PM To: Second Life Developer Mailing List Subject: [sldev] Small easy target features to consider for Snowglobe Hi, It was suggested to me that some small relatively easy to hack features would be cool addition to Snowglobe. Additionally, those are small, limited tweaks to existing functionality so they should be nice targets for would be contributors looking for first contributions. Here are those 3 features: SNOW-386 : Improve "Show look at" feature : We have this under the Advanced menu as a debug feature already but it needs some polish to look less "geeky". I added some ideas of improvements suggestions in the JIRA record. Seems like an easy target as there's code already in there that just need love. VWR-7427 : Allow custom texture for selection beam particles : This is a year old request. Got some votes, no patch. The related code looks very small and easily hackable (I checked tonight). I'm not convinced of the importance of this as a feature but it's an easy and truly cool "first contribution" target :) VWR-7604: Suggested behaviour change for "Sit here" when targeting the ground : The JIRA description makes a lot of sense and is very clear. No patch though. That one is a feature I would use for sure. I haven't looked in the code but it seems possible to expand from the existing "Sit here" behavior (at least, start to understand that before moving to expand it). Any takers? Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091211/9049de06/attachment.htm From carlo at alinoe.com Fri Dec 11 03:58:40 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 11 Dec 2009 12:58:40 +0100 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: <4B21ECE0.2010002@gmail.com> References: <20091207003350.GA5500@alinoe.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> <4B21ECE0.2010002@gmail.com> Message-ID: <20091211115840.GA29610@alinoe.com> On Thu, Dec 10, 2009 at 10:55:28PM -0800, Dzonatas Sol wrote: > Wouldn't it be better if the map was a LLMediaPlugin. That way each > map window can be customized to a grid. That would also mean each > grid would load it's own viewer plugin. In my attempt to convince people that for (future) VWRAP client-server communication it is necessary to have feature(/protocol) negotiation, some people claim that this is not necessary because "it" can be done with caps. The negotiation that I proposed basically comes down to: "abitrary label" implies "mandatory features/protocol" + "list of optional features", and then the client picks from the list (that it has internally). In other words: a negotiation of booleans with arbitrary meaning. IF that is to be replaced / covered with caps, then that means that caps will have to be USED as "boolean negotiation with arbitrary meaning". I wonder, are people really ready / willing to do that? As an example (hence my reply to Dzonatas' post), if different grid (or VW to speak with Morgaine) would like to list plugins to load; do people really think that 'caps' is an appropriate method to determine which plugins are needed? A boolean approach could be: if (caps_plugin_xyz_needed_exists) load_plugin_xyz(); Another approach could be: if (caps_need_plugins_exists) { get_plugin_names(the_cap); load_plugins(); } The latter is more of a use as caps were intended, but please consider the first one too: I'd like to know if it really feels OK with you; since for other things we will only need boolean negotiation(s). My fear is that people would rather code heuristic kludges in a viewer to determine/guess what grid they are on and what to support, than to wait for a server implementation to add a new caps... So, in order for this to work, the server implementations would have to provide boolean caps at the SAME time they provide a new feature, which isn't going to happen unless everyone says: Oh yeah, that is sooo clearly how caps are intended, of course we will do that. -- Carlo Wood From carlo at alinoe.com Fri Dec 11 04:25:57 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 11 Dec 2009 13:25:57 +0100 Subject: [sldev] libsecondlife / libopenmetaverse bots problem? In-Reply-To: <3dd38e2d0912101139o2076779duc070e633314dd91c@mail.gmail.com> References: <3dd38e2d0912101139o2076779duc070e633314dd91c@mail.gmail.com> Message-ID: <20091211122557.GB29610@alinoe.com> On Thu, Dec 10, 2009 at 02:39:56PM -0500, amh wrote: > The last couple of weeks I have been having problems with rezzing bots in SL. > They either do not rez at all -- stay in a "cloud stage" (95% of the cases) or > take extremely long time to rez and their appearance doesn't rez. Is it > something due to changes in the SL (server? client?), network overload at SL > NOC? Does anybody have an idea? It is probably because the avatar isn't "ready", which means that a part of it is missing (for complete rendering). You might be able to find out what that is by looking at the bot with another viewer, go to Advanced -> Debug Settings... and set renderunloadedavatar to TRUE -- Carlo Wood From secret.argent at gmail.com Fri Dec 11 05:04:49 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 11 Dec 2009 07:04:49 -0600 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: <4B21ECE0.2010002@gmail.com> References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> <20091207003350.GA5500@alinoe.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> <4B21ECE0.2010002@gmail.com> Message-ID: <05385612-87A0-452C-8489-A1ABC1C8A1F1@gmail.com> On 2009-12-11, at 00:55, Dzonatas Sol wrote: > Wouldn't it be better if the map was a LLMediaPlugin. Other than every other time I log in I get a message that llmedia plugins didn't load. Which I don't care about because I hardly ever use parcel media and have no interest in ever actually using anything that requires a plugin for it, but if that broke the map I'd be right crook about it. From brickrte at hughes.net Fri Dec 11 05:56:21 2009 From: brickrte at hughes.net (Laurence Brickner) Date: Fri, 11 Dec 2009 08:56:21 -0500 Subject: [sldev] Small easy target features to consider for Snowglobe In-Reply-To: <78f69850912101625j27663850lb5de3c8598feafcd@mail.gmail.com> References: <78f69850912092239i44cc590u5cd5b3ce0fc02b8@mail.gmail.com> <78f69850912101000w6f5415camb989f8dd529662af@mail.gmail.com> <78f69850912101625j27663850lb5de3c8598feafcd@mail.gmail.com> Message-ID: Errr. Never mind. Sorry for being lame. I found it in LLHUDEffectLookAt.cpp Shor _____ From: Philippe (Merov) Bossut [mailto:merov at lindenlab.com] Sent: Thursday, December 10, 2009 19:26 To: brickrte at odyssey.net; Second Life Developer Mailing List Subject: Re: [sldev] Small easy target features to consider for Snowglobe Re-directing to sldev. - Merov On Thu, Dec 10, 2009 at 3:07 PM, Laurence Brickner wrote: Hi all, Could someone aim me at the right area file wise for SNOW-386. BTW, I'm re-installing 2005. Shor _____ From: Philippe (Merov) Bossut [mailto:merov at lindenlab.com] Sent: Thursday, December 10, 2009 13:00 To: brickrte at odyssey.net Subject: Re: [sldev] Small easy target features to consider for Snowglobe Hi Shorahmin, Great to hear you're considering building and may be contributing to Snowglobe. The best way to get support in building and getting things set up is to email the sldev list: lots of great folks there with experience on all sorts of build environments. Welcome to Snowglobe! Cheers, - Merov On Thu, Dec 10, 2009 at 7:51 AM, Laurence Brickner wrote: Hi all, (Hope I'm doing this right) I've just started trying to set up the environment etc. Using VS2008. Lotsa C++ experience, now retired. The Show-Look thing looks like a great way to learn the whole cmake - VSN - patchy - thingy system. So if you have the patience, I'd like to give it a shot. BTW, where could I get some TLC on setting up? Right now I get about 11 unresolved externals. Shorahmin _____ From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Philippe (Merov) Bossut Sent: Thursday, December 10, 2009 01:40 To: Second Life Developer Mailing List Subject: [sldev] Small easy target features to consider for Snowglobe Hi, It was suggested to me that some small relatively easy to hack features would be cool addition to Snowglobe. Additionally, those are small, limited tweaks to existing functionality so they should be nice targets for would be contributors looking for first contributions. Here are those 3 features: SNOW-386 : Improve "Show look at" feature : We have this under the Advanced menu as a debug feature already but it needs some polish to look less "geeky". I added some ideas of improvements suggestions in the JIRA record. Seems like an easy target as there's code already in there that just need love. VWR-7427 : Allow custom texture for selection beam particles : This is a year old request. Got some votes, no patch. The related code looks very small and easily hackable (I checked tonight). I'm not convinced of the importance of this as a feature but it's an easy and truly cool "first contribution" target :) VWR-7604: Suggested behaviour change for "Sit here" when targeting the ground : The JIRA description makes a lot of sense and is very clear. No patch though. That one is a feature I would use for sure. I haven't looked in the code but it seems possible to expand from the existing "Sit here" behavior (at least, start to understand that before moving to expand it). Any takers? Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091211/799debce/attachment.htm From garmin.kawaguichi at magalaxie.com Fri Dec 11 07:26:32 2009 From: garmin.kawaguichi at magalaxie.com (Garmin Kawaguichi) Date: Fri, 11 Dec 2009 16:26:32 +0100 Subject: [sldev] libsecondlife / libopenmetaverse bots problem? References: <3dd38e2d0912101139o2076779duc070e633314dd91c@mail.gmail.com> Message-ID: https://blogs.secondlife.com/message/7629#7629 http://www.metabolt.net/metaforums/yaf_postst412_AVs-remaining-as-a-cloud.aspx GCI ----- Original Message ----- From: amh To: sldev at lists.secondlife.com Sent: Thursday, December 10, 2009 8:39 PM Subject: [sldev] libsecondlife / libopenmetaverse bots problem? The last couple of weeks I have been having problems with rezzing bots in SL. They either do not rez at all -- stay in a "cloud stage" (95% of the cases) or take extremely long time to rez and their appearance doesn't rez. Is it something due to changes in the SL (server? client?), network overload at SL NOC? Does anybody have an idea? Thank you, Alex Heiphetz / AHG Hallard ------------------------------------------------------------------------------ _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091211/ae645a3c/attachment-0001.htm From dzonatas at gmail.com Fri Dec 11 08:16:04 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Fri, 11 Dec 2009 08:16:04 -0800 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: <05385612-87A0-452C-8489-A1ABC1C8A1F1@gmail.com> References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> <20091207003350.GA5500@alinoe.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> <4B21ECE0.2010002@gmail.com> <05385612-87A0-452C-8489-A1ABC1C8A1F1@gmail.com> Message-ID: <4B227044.3070100@gmail.com> Argent Stonecutter wrote: > have no interest in ever actually using anything > that requires a plugin for it Not even if the plugin was something like "Advanced.Furry.Gesture.Recognition.And.Animator.dll"??? From kelly at lindenlab.com Fri Dec 11 08:44:53 2009 From: kelly at lindenlab.com (Kelly Linden) Date: Fri, 11 Dec 2009 08:44:53 -0800 Subject: [sldev] Enabling llPointAt In-Reply-To: <001801ca7a48$cf94a620$6ebdf260$@com> References: <78f69850912092239i44cc590u5cd5b3ce0fc02b8@mail.gmail.com> <001801ca7a48$cf94a620$6ebdf260$@com> Message-ID: Sorry to dash any hopes but on the server this function is currently a no-op. No data will get sent to the viewer. - Kelly On Fri, Dec 11, 2009 at 2:00 AM, Vector Hastings wrote: > Anybody want to fix this? > > > > Seems to me (though I?m no expert) that it?d be possible via a client-side > hack? take the vector passed in lscript_library.cpp for script command > llPointAt and feed back to the server a change in agent orientation as if > the keyboard or mouse/flycam had made the necessary input. That would > effectively ?re-enable? this old, deprecated script command. (we can compile > scripts with it which seems promising, though I haven?t confirmed that the > vector stored in the script is passed through the pipeline to the client.) > > > > There are big vote for this one! You could be a personal hero to so many > (including me) J http://jira.secondlife.com/browse/SVC-56 > > > > (this Jira is classed as a new feature, but the script commands are there, > so there?s an argument for it being a broken feature, though I suppose the > official wiki says it was never enabled, which makes it ?new.?) > > > > Cheers to all, > > > > Vector > > > > *From:* sldev-bounces at lists.secondlife.com [mailto: > sldev-bounces at lists.secondlife.com] *On Behalf Of *Philippe (Merov) Bossut > *Sent:* Wednesday, December 09, 2009 10:40 PM > *To:* Second Life Developer Mailing List > *Subject:* [sldev] Small easy target features to consider for Snowglobe > > > > Hi, > > It was suggested to me that some small relatively easy to hack features > would be cool addition to Snowglobe. Additionally, those are small, limited > tweaks to existing functionality so they should be nice targets for would be > contributors looking for first contributions. Here are those 3 features: > > SNOW-386 : Improve "Show look at" feature : We have this under the Advanced > menu as a debug feature already but it needs some polish to look less > "geeky". I added some ideas of improvements suggestions in the JIRA record. > Seems like an easy target as there's code already in there that just need > love. > > VWR-7427 : Allow custom texture for selection beam particles : This is a > year old request. Got some votes, no patch. The related code looks very > small and easily hackable (I checked tonight). I'm not convinced of the > importance of this as a feature but it's an easy and truly cool "first > contribution" target :) > > VWR-7604: Suggested behaviour change for "Sit here" when targeting the > ground : The JIRA description makes a lot of sense and is very clear. No > patch though. That one is a feature I would use for sure. I haven't looked > in the code but it seems possible to expand from the existing "Sit here" > behavior (at least, start to understand that before moving to expand it). > > Any takers? > > Cheers, > - Merov > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091211/9f0cac24/attachment.htm From lenglish5 at cox.net Fri Dec 11 09:09:11 2009 From: lenglish5 at cox.net (Lawson English) Date: Fri, 11 Dec 2009 10:09:11 -0700 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: <4B227044.3070100@gmail.com> References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> <20091207003350.GA5500@alinoe.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> <4B21ECE0.2010002@gmail.com> <05385612-87A0-452C-8489-A1ABC1C8A1F1@gmail.com> <4B227044.3070100@gmail.com> Message-ID: <4B227CB7.1060005@cox.net> Dzonatas Sol wrote: > Argent Stonecutter wrote: > >> have no interest in ever actually using anything >> that requires a plugin for it >> > > Not even if the plugin was something like > "Advanced.Furry.Gesture.Recognition.And.Animator.dll"??? > > > > > Or gridXYZ advanced P2P combat physics module... Or... Lawson From tigrospottystripes at gmail.com Fri Dec 11 11:59:19 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Fri, 11 Dec 2009 17:59:19 -0200 Subject: [sldev] Opnions about VWR-13942 Message-ID: <4B22A497.2020708@Gmail.com> I would like to hear what developers have to say about http://jira.secondlife.com/browse/VWR-13942 "Optimize non-dynamic content on sims" From adam at deepthink.com.au Fri Dec 11 14:05:33 2009 From: adam at deepthink.com.au (Frisby, Adam) Date: Fri, 11 Dec 2009 17:05:33 -0500 Subject: [sldev] Opnions about VWR-13942 In-Reply-To: <4B22A497.2020708@Gmail.com> References: <4B22A497.2020708@Gmail.com> Message-ID: <63FAD4F222230A4EA79DE9E8BE6647354DC55669@winxbeus19.exchange.xchg> While packaging certain information (such as serialised prim data) and firing it over HTTP might be faster - the viewer works on a progressive download prioritising via a frustrum; which means it'd probably actually increase certain load times when entering a region (or at least load times until you saw something). W.R.T Framerate optimisations/etc - it still unfortunately won't work. The Second Life viewer adds and removes too much content for you to get any serious chance at implementing something like a BSP tree - in addition that only works in entirely enclosed spaces. Adam > -----Original Message----- > From: sldev-bounces at lists.secondlife.com [mailto:sldev- > bounces at lists.secondlife.com] On Behalf Of Tigro Spottystripes > Sent: Friday, 11 December 2009 11:59 AM > To: Second Life Developer Mailing List > Subject: [sldev] Opnions about VWR-13942 > > I would like to hear what developers have to say about > http://jira.secondlife.com/browse/VWR-13942 "Optimize non-dynamic > content on sims" > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From vector at leafpile.com Fri Dec 11 16:39:36 2009 From: vector at leafpile.com (Vector Hastings) Date: Fri, 11 Dec 2009 16:39:36 -0800 Subject: [sldev] Enabling llPointAt In-Reply-To: References: <78f69850912092239i44cc590u5cd5b3ce0fc02b8@mail.gmail.com> <001801ca7a48$cf94a620$6ebdf260$@com> Message-ID: <008701ca7ac3$94d949c0$be8bdd40$@com> Ah well, Thanks Kelly for letting us know so quickly! (I knew I should?ve checked if the data was coming down first, but frankly, this was easier, so thanks again.) Vector From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Kelly Linden Sent: Friday, December 11, 2009 8:45 AM To: Vector Hastings Cc: Second Life Developer Mailing List Subject: Re: [sldev] Enabling llPointAt Sorry to dash any hopes but on the server this function is currently a no-op. No data will get sent to the viewer. - Kelly On Fri, Dec 11, 2009 at 2:00 AM, Vector Hastings wrote: Anybody want to fix this? Seems to me (though I?m no expert) that it?d be possible via a client-side hack? take the vector passed in lscript_library.cpp for script command llPointAt and feed back to the server a change in agent orientation as if the keyboard or mouse/flycam had made the necessary input. That would effectively ?re-enable? this old, deprecated script command. (we can compile scripts with it which seems promising, though I haven?t confirmed that the vector stored in the script is passed through the pipeline to the client.) There are big vote for this one! You could be a personal hero to so many (including me) J http://jira.secondlife.com/browse/SVC-56 (this Jira is classed as a new feature, but the script commands are there, so there?s an argument for it being a broken feature, though I suppose the official wiki says it was never enabled, which makes it ?new.?) Cheers to all, Vector From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Philippe (Merov) Bossut Sent: Wednesday, December 09, 2009 10:40 PM To: Second Life Developer Mailing List Subject: [sldev] Small easy target features to consider for Snowglobe Hi, It was suggested to me that some small relatively easy to hack features would be cool addition to Snowglobe. Additionally, those are small, limited tweaks to existing functionality so they should be nice targets for would be contributors looking for first contributions. Here are those 3 features: SNOW-386 : Improve "Show look at" feature : We have this under the Advanced menu as a debug feature already but it needs some polish to look less "geeky". I added some ideas of improvements suggestions in the JIRA record. Seems like an easy target as there's code already in there that just need love. VWR-7427 : Allow custom texture for selection beam particles : This is a year old request. Got some votes, no patch. The related code looks very small and easily hackable (I checked tonight). I'm not convinced of the importance of this as a feature but it's an easy and truly cool "first contribution" target :) VWR-7604: Suggested behaviour change for "Sit here" when targeting the ground : The JIRA description makes a lot of sense and is very clear. No patch though. That one is a feature I would use for sure. I haven't looked in the code but it seems possible to expand from the existing "Sit here" behavior (at least, start to understand that before moving to expand it). Any takers? Cheers, - Merov _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091211/1a1ee693/attachment.htm From merov at lindenlab.com Fri Dec 11 16:42:26 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Fri, 11 Dec 2009 16:42:26 -0800 Subject: [sldev] Weekly Snowglobe update : build 3059 Message-ID: <78f69850912111642s7496ec01x9c4ff5704af25834@mail.gmail.com> Hi, Our weekly email listing the various contributions to Snowglobe trunk. 8 bugs is a weekly best but that's a record that's screaming to be broken so, keep those patches coming! :) Also, thank you to the new folks jumping in to help with patches (Be Holder, Twisted Laws) or test (Yann Dufaux). The list: - SNOW-64: Merov : Fixed the map in French, small translation updates for French. Suppressed the now inexisting tabs in all other languages. Thanks to Yann Dufaux for the review and tests. - SNOW-208: Thickbrick : HTTP GET requests for textures check for HTTP status 203, but should check for 206 - SNOW-260: Merov : Correct small errors and consistency in LSL editor hovertips. Thanks to Thickbrick for the review. - SNOW-352: Twisted Laws : Add optional double-click teleport. Off by default, use Advanced > UI > Double click teleport to switch on. - SNOW-378: Henri Beauchamp : Checkbox needed to compile inventory scripts in Mono - SNOW-379: Be Holder : Camera View Angle slider is not reset by cancel button - SNOW-387: McCabe Maxsted : Add "Return Object" to the Tools menu - SNOW-388: Jacek Antonelli : Regression: VWR-1852 - Local ruler mode aligned incorrectly for linked objects Downloads: Linux: http://secondlife.com/developers/opensource/downloads/2009/trunk/3059/Snowglobe-i686-1.3.0.3059.tar.bz2 Darwin: http://secondlife.com/developers/opensource/downloads/2009/trunk/3059/Snowglobe_1_3_0_3059_SNOWGLOBETESTBUILD.dmg Windows: http://secondlife.com/developers/opensource/downloads/2009/trunk/3059/Snowglobe_1-3-0-3059_Setup.exe Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091211/affdd413/attachment.htm From tayra.dagostino at gmail.com Fri Dec 11 17:15:36 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Sat, 12 Dec 2009 02:15:36 +0100 Subject: [sldev] Weekly Snowglobe update : build 3059 In-Reply-To: <78f69850912111642s7496ec01x9c4ff5704af25834@mail.gmail.com> References: <78f69850912111642s7496ec01x9c4ff5704af25834@mail.gmail.com> Message-ID: <20091212021536.6f685a72.tayra.dagostino@gmail.com> On Fri, 11 Dec 2009 16:42:26 -0800 "Philippe (Merov) Bossut" wrote: > Downloads: > Linux: > http://secondlife.com/developers/opensource/downloads/2009/trunk/3059/Snowglobe-i686-1.3.0.3059.tar.bz2 I've still same problem with SLPlugin... I start snowglobe, no SLPlugin thread I start audio stream, one SLPlugin instance in memory, i stop the audio stream and SLPlugin disappear ...and this is ok I open a multimedia stream and SLPlugin forked in memory, i stop and SLPlugin killed ..ok too... I open search, SIX child of SLPlugin start, if i close search window no SLPlugin killed, all resident in memory... and after 3-4 time I open search (or profile or group-info) all cores of my Q6600 are overloaded with SLPlugin with 99% of cputime... nobody else? From tillie at xp2.de Sat Dec 12 11:20:40 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Sat, 12 Dec 2009 20:20:40 +0100 Subject: [sldev] VS2005: Build error (bison) In-Reply-To: <20091212021536.6f685a72.tayra.dagostino@gmail.com> References: <78f69850912111642s7496ec01x9c4ff5704af25834@mail.gmail.com> <20091212021536.6f685a72.tayra.dagostino@gmail.com> Message-ID: <4B23ED08.5050505@xp2.de> Hello, 1>------ Build started: Project: lscript_compile, Configuration: Release Win32 ------ 1>Generating indra.y.cpp, indra.y.hpp 1>D:/Dev/SL/client/linden/indra/lscript/lscript_compile/indra.y: conflicts: 88 reduce/reduce What's wrong? I remember having this error several months ago already, but didnt find a solution. Tillie From eiffel56 at gmail.com Sat Dec 12 11:48:43 2009 From: eiffel56 at gmail.com (Lisa Denia) Date: Sat, 12 Dec 2009 20:48:43 +0100 Subject: [sldev] Snowglobe on OpenSim grids In-Reply-To: <78f69850912041146m1140c7a4o10ced3aada0c7ee@mail.gmail.com> References: <200912042021.26650.eiffel56@gmail.com> <78f69850912041146m1140c7a4o10ced3aada0c7ee@mail.gmail.com> Message-ID: <200912122048.43241.eiffel56@gmail.com> Hey, maybe you want to have a look at https://jira.secondlife.com/browse/SNOW-77. I've attached a patch which implements a "HTTPMapURLRequest" capability. It just implements that single capability, no protocol negotiation or sort of, though I think that would be a great idea for future changes. Note that OpenSim currently has no support for that, so testing it isn't that easy. Do we have a nice way of generating the different levels of each tile btw? I wonder if theres already an open bugreport. Have fun, Lisa Denia From robin.cornelius at gmail.com Sat Dec 12 11:51:13 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat, 12 Dec 2009 19:51:13 +0000 Subject: [sldev] VS2005: Build error (bison) In-Reply-To: <4B23ED08.5050505@xp2.de> References: <78f69850912111642s7496ec01x9c4ff5704af25834@mail.gmail.com> <20091212021536.6f685a72.tayra.dagostino@gmail.com> <4B23ED08.5050505@xp2.de> Message-ID: <4B23F431.2090307@gmail.com> Tillie Ariantho wrote: > Hello, > > 1>------ Build started: Project: lscript_compile, Configuration: Release Win32 ------ > 1>Generating indra.y.cpp, indra.y.hpp > 1>D:/Dev/SL/client/linden/indra/lscript/lscript_compile/indra.y: conflicts: 88 reduce/reduce > > What's wrong? I remember having this error several months ago already, but didnt find a solution. Thats not an error that perfectly normal bison output. Well technically it is an error, bison is stating that there is an issue with the grammar parser and that there are duplicate grammar matches but there may in fact be very very good reasons for this. The viewer code base has always done this however and worked regardless. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20091212/1d458b2f/attachment.pgp From secret.argent at gmail.com Sat Dec 12 16:29:10 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 12 Dec 2009 18:29:10 -0600 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: <4B227044.3070100@gmail.com> References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> <20091207003350.GA5500@alinoe.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> <4B21ECE0.2010002@gmail.com> <05385612-87A0-452C-8489-A1ABC1C8A1F1@gmail.com> <4B227044.3070100@gmail.com> Message-ID: <72EA9ED8-9DD6-4373-A551-8962B01283C8@gmail.com> On 2009-12-11, at 10:16, Dzonatas Sol wrote: > Argent Stonecutter wrote: >> have no interest in ever actually using anything that requires a >> plugin for it > Not even if the plugin was something like > "Advanced.Furry.Gesture.Recognition.And.Animator.dll"??? No. From lenglish5 at cox.net Sat Dec 12 17:30:24 2009 From: lenglish5 at cox.net (Lawson English) Date: Sat, 12 Dec 2009 18:30:24 -0700 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: <72EA9ED8-9DD6-4373-A551-8962B01283C8@gmail.com> References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> <20091207003350.GA5500@alinoe.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> <4B21ECE0.2010002@gmail.com> <05385612-87A0-452C-8489-A1ABC1C8A1F1@gmail.com> <4B227044.3070100@gmail.com> <72EA9ED8-9DD6-4373-A551-8962B01283C8@gmail.com> Message-ID: <4B2443B0.5000800@cox.net> Argent Stonecutter wrote: > On 2009-12-11, at 10:16, Dzonatas Sol wrote: > >> Argent Stonecutter wrote: >> >>> have no interest in ever actually using anything that requires a >>> plugin for it >>> > > >> Not even if the plugin was something like >> "Advanced.Furry.Gesture.Recognition.And.Animator.dll"??? >> > > No. > _______________________________________________ > So how would you handle extensions to viewer requirements? Have a viewer for every virtual world you visit, even if there's only one or two differences between it and the VWRAP standard? Lawson From stickman at gmail.com Sat Dec 12 22:19:00 2009 From: stickman at gmail.com (Stickman) Date: Sat, 12 Dec 2009 22:19:00 -0800 Subject: [sldev] Script/Parcel/Memory Limits Message-ID: I don't know what the official name is, but it's either Parcel Limits, Script Limits, or Memory Limits. It's been a while since I've heard any official word about it. Last I did hear, LL was gathering statistics and didn't know exactly how they were going to implement it, let alone what the limits would be. Has LL made any decisions, and would they be willing to share them? More minds on the issue can spot any holes or problems that could arise, and there's still some rumbling panic among the masses that can't be confirmed or quelled since we don't know how it'll work. Many thanks, Stickman From ziggy at planetziggy.com Sat Dec 12 22:43:36 2009 From: ziggy at planetziggy.com (Ziggy Puff) Date: Sat, 12 Dec 2009 22:43:36 -0800 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: Message-ID: <4B248D18.6040100@planetziggy.com> I was about to post a question on this as well - my wife heard about that blog post (it's spreading pretty quickly among content creators, I think) and so I took a look. I found some good info in 3 or 4 of Babbage Linden's office hour chat logs. More details on the exact algorithms would be very helpful. Some questions I had after going through the material I could find: * Is each script 'charged' 16K/64K, or just what it's using? Is the check made on rez / parcel change, or periodically? Maybe this is a meaningless question, but I thought Mono scripts could scale their memory footprint up and down, in which case a script could have a small footprint when it's rezzed. * Avatar / attachment pool vs. parcel pool - if an av's pool runs out, does an attachment try to take memory from the parcel pool? * The GUI support for reporting script memory usage - will it show the footprint of individual objects, like the 'Top Scripts' window? How about individual attachments? I imagine the last object that would go over the threshold will be the one that's not allowed to rez, but that probably won't be the least efficiently scripted item the person is wearing. Ziggy Stickman wrote: > I don't know what the official name is, but it's either Parcel Limits, > Script Limits, or Memory Limits. > > It's been a while since I've heard any official word about it. Last I > did hear, LL was gathering statistics and didn't know exactly how they > were going to implement it, let alone what the limits would be. > > Has LL made any decisions, and would they be willing to share them? > More minds on the issue can spot any holes or problems that could > arise, and there's still some rumbling panic among the masses that > can't be confirmed or quelled since we don't know how it'll work. > > Many thanks, > > Stickman > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > > From tillie at xp2.de Sun Dec 13 03:01:36 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Sun, 13 Dec 2009 12:01:36 +0100 Subject: [sldev] VS2005: Build error (bison) In-Reply-To: <4B23F431.2090307@gmail.com> References: <78f69850912111642s7496ec01x9c4ff5704af25834@mail.gmail.com> <20091212021536.6f685a72.tayra.dagostino@gmail.com> <4B23ED08.5050505@xp2.de> <4B23F431.2090307@gmail.com> Message-ID: <4B24C990.2070902@xp2.de> On 12.12.2009 20:51, Robin Cornelius wrote: >> 1>------ Build started: Project: lscript_compile, Configuration: Release Win32 ------ >> 1>Generating indra.y.cpp, indra.y.hpp >> 1>D:/Dev/SL/client/linden/indra/lscript/lscript_compile/indra.y: conflicts: 88 reduce/reduce >> >> What's wrong? I remember having this error several months ago already, but didnt find a solution. > > Thats not an error that perfectly normal bison output. Well technically > it is an error, bison is stating that there is an issue with the grammar > parser and that there are duplicate grammar matches but there may in > fact be very very good reasons for this. > > The viewer code base has always done this however and worked regardless. So how do I generate indra.l.cpp? That file is not written by the build, that error prevents it, so I am stuck with 2 of about 50 files not generated. :( Tillie From tillie at xp2.de Sun Dec 13 03:18:06 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Sun, 13 Dec 2009 12:18:06 +0100 Subject: [sldev] Snowglobe 1.2 RC 4 In-Reply-To: <78f69850911181400o7c7a71a9k9ed02887683aebe4@mail.gmail.com> References: <78f69850911181400o7c7a71a9k9ed02887683aebe4@mail.gmail.com> Message-ID: <4B24CD6E.7040409@xp2.de> On 18.11.2009 23:00, Philippe (Merov) Bossut wrote: > After some build machines wrangling, we finally produced a clean set of > builds for the 3 platforms. You can download them from: > - Linux:http://secondlife.com/developers/opensource/downloads/2009/1.2/3007/Snowglobe-i686-1.2.4.3007.tar.bz2 > - Darwin:http://secondlife.com/developers/opensource/downloads/2009/1.2/3007/Snowglobe_1_2_4_3007.dmg > - CYGWIN:http://secondlife.com/developers/opensource/downloads/2009/1.2/3007/Snowglobe_1-2-4-3007_Setup.exe > > There's currently *no* bugs against 1.2 so these are true Release > Candidates. Please go ahead, download and test :) Sorry if I may correct you, there may be no "new" bugs. :P All the old borken stuff is still in, like lots bugs in Snapshots (mirrored glow on highres snapshots, 2560x1600 snapshot saves 2560x1599 pixels only, visible offset lines in water and sky when doing highres snapshots, preview showing anything but a real preview of the snapshot, freeze screen not freezing particles etc, Ctrl-` snapshot hotkey switches back on hidden UI, ...). :-> Tillie From tillie at xp2.de Sun Dec 13 03:45:25 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Sun, 13 Dec 2009 12:45:25 +0100 Subject: [sldev] VS2005: Build error (bison) In-Reply-To: <4B24C990.2070902@xp2.de> References: <78f69850912111642s7496ec01x9c4ff5704af25834@mail.gmail.com> <20091212021536.6f685a72.tayra.dagostino@gmail.com> <4B23ED08.5050505@xp2.de> <4B23F431.2090307@gmail.com> <4B24C990.2070902@xp2.de> Message-ID: <4B24D3D5.9@xp2.de> Hello, btw. Reading VS environment from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\EnvironmentDirectory I don't know which VS 2005 you are using, but the one I got yesterday via the downloading installer has NOT this EnvironmentDirectory entry. So compiling via cmake on command line doesn't work for me. I tried adding it, then VS does a bad call: Error: the command u'"C:\\Progra~2\\Micros~1\\vc\\bin\\devenv.com"' was not found There is no devenv.com anywhere in VS 2005. I have no idea how that shall work. My VS2005 version is: Microsoft Visual Studio 2005 Version 8.0.50727.42 (RTM.050727-4200) Microsoft .NET Framework Version 2.0.50727 SP2 Installed Edition: VC Express Microsoft Visual C++ 2005 76542-000-0000011-00125 Microsoft Visual C++ 2005 Tillie From tillie at xp2.de Sun Dec 13 03:54:32 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Sun, 13 Dec 2009 12:54:32 +0100 Subject: [sldev] Snowglobe Installer: two bugs In-Reply-To: <4B24CD6E.7040409@xp2.de> References: <78f69850911181400o7c7a71a9k9ed02887683aebe4@mail.gmail.com> <4B24CD6E.7040409@xp2.de> Message-ID: <4B24D5F8.9050200@xp2.de> Hello, seems there is a bug in the installer (tested on Win7): it doesn't check if 'Snowglobe' already exists on the desktop. Which results in: - "installing desktop icon" message - nothing seems to happen - I rightclick the old snowglobe icon to see if the parameters changed - explorer crashes - explorer comes back up with 2 'Snowglobe' icons - rightclicking the newly created one crashes explorer again, old one works So I have to delete the old one manually to get the new one working. And still the "Start now?" button I consider bad. Because if you had to give the installer "admin" rights for the installation, you then start Snowglobe with admin rights too. With the effect, that on this first start of SL all settings are written to your admin home, not to the home of the current users. Tillie From robin.cornelius at gmail.com Sun Dec 13 09:20:12 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun, 13 Dec 2009 17:20:12 +0000 Subject: [sldev] VS2005: Build error (bison) In-Reply-To: <4B24C990.2070902@xp2.de> References: <78f69850912111642s7496ec01x9c4ff5704af25834@mail.gmail.com> <20091212021536.6f685a72.tayra.dagostino@gmail.com> <4B23ED08.5050505@xp2.de> <4B23F431.2090307@gmail.com> <4B24C990.2070902@xp2.de> Message-ID: <4B25224C.2010005@gmail.com> Tillie Ariantho wrote: >> The viewer code base has always done this however and worked regardless. > > So how do I generate indra.l.cpp? That file is not written by the build, that error prevents it, so I am stuck with 2 of about 50 files not generated. :( > Are you sure that is the error that is preventing it from working, I see that message in a normal build? I would expect that its not actualy that warning but something else going wrong. Is this snowglobe? on windows? i do remember there was talk of making the building of indra.l.cpp optional and supplying a prebuild lexer and parser as unless you are hacking up the LSL script compiler then its pretty static and does not need to be rebuilt. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20091213/2e686fd4/attachment.pgp From robin.cornelius at gmail.com Sun Dec 13 09:24:17 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun, 13 Dec 2009 17:24:17 +0000 Subject: [sldev] VS2005: Build error (bison) In-Reply-To: <4B24D3D5.9@xp2.de> References: <78f69850912111642s7496ec01x9c4ff5704af25834@mail.gmail.com> <20091212021536.6f685a72.tayra.dagostino@gmail.com> <4B23ED08.5050505@xp2.de> <4B23F431.2090307@gmail.com> <4B24C990.2070902@xp2.de> <4B24D3D5.9@xp2.de> Message-ID: <4B252341.3070302@gmail.com> Tillie Ariantho wrote: > Hello, > > btw. > > Reading VS environment from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Setup\VS\EnvironmentDirectory > > I don't know which VS 2005 you are using, but the one I got yesterday via the downloading installer has NOT this EnvironmentDirectory entry. > > So compiling via cmake on command line doesn't work for me. I tried adding it, then VS does a bad call: > > Error: the command u'"C:\\Progra~2\\Micros~1\\vc\\bin\\devenv.com"' was not found > > There is no devenv.com anywhere in VS 2005. > > I have no idea how that shall work. You only get that in the standard and professional editions. express does not contain that tool. it is not vital anyway, all you need to do to work around is to run develop.py as develop.py -GVC80 to force it to use VC2005, then you still get the error message but all is fine, you just need to open the visual studio solution in build-vc80/ then remember to set 3 things 1) The build type to RelWithDbg or Release 2) The Active project to Secondlife or snowglobe (or i think build_all works too) 3)And also for the secondlife/snowglobe project, right click, go to properties, debugging-> Set Working directory.. now browse back to the base of your source tree and find the indra/newview folder, note by default you will be in indra/build-vc80/newview/relwithdbginfo/ ... (or something like that) Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20091213/58340646/attachment-0001.pgp From robin.cornelius at gmail.com Sun Dec 13 09:25:13 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun, 13 Dec 2009 17:25:13 +0000 Subject: [sldev] Snowglobe Installer: two bugs In-Reply-To: <4B24D5F8.9050200@xp2.de> References: <78f69850911181400o7c7a71a9k9ed02887683aebe4@mail.gmail.com> <4B24CD6E.7040409@xp2.de> <4B24D5F8.9050200@xp2.de> Message-ID: <4B252379.3000001@gmail.com> Tillie Ariantho wrote: > Hello, > > seems there is a bug in the installer (tested on Win7): it doesn't check if 'Snowglobe' already exists on the desktop. Which results in: > > - "installing desktop icon" message > - nothing seems to happen > - I rightclick the old snowglobe icon to see if the parameters changed > - explorer crashes > - explorer comes back up with 2 'Snowglobe' icons > - rightclicking the newly created one crashes explorer again, old one works > > So I have to delete the old one manually to get the new one working. > > > And still the "Start now?" button I consider bad. Because if you had to give the installer "admin" rights for the installation, you then start Snowglobe with admin rights too. > With the effect, that on this first start of SL all settings are written to your admin home, not to the home of the current users. Can you please add these to a JIRA so we don't forget about them! thanks Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20091213/2b1ff973/attachment.pgp From josh at lindenlab.com Sun Dec 13 10:53:48 2009 From: josh at lindenlab.com (Joshua Bell) Date: Sun, 13 Dec 2009 10:53:48 -0800 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: <4B21ECE0.2010002@gmail.com> References: <200912042310.19845.eiffel56@gmail.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> <4B21ECE0.2010002@gmail.com> Message-ID: On Thu, Dec 10, 2009 at 10:55 PM, Dzonatas Sol wrote: > Wouldn't it be better if the map was a LLMediaPlugin. That way each map > window can be customized to a grid. That would also mean each grid would > load it's own viewer plugin. > I would take this one step further: The map is a service provided by a grid, or region-domain in VWRAP parlance. It should have no dependency on the agent domain. It serves to consume and produce location identifiers into the grid which - should be URLs, e.g. "given a friend's SLurl, show it on the map", "generate a SLurl for a location so I can initiate a teleport to it". I would posit that this could be implemented entirely as a web page hosted via a generic web context provider in a viewer - no need for a specific plugin. The region domain would provide a standardized cap which is actually a web page a la slurl.com, which generates URLs the viewer can act on (e.g. to initiate teleport). If there does need to be agent domain/region domain interaction (E.g. "highlight my friends on the map") then there would need to be some VWRAP-ish negotiation, e.g. the agent domain(s) of your friends provide caps that you can pass on to the region domain map service. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091213/cca2a6da/attachment.htm From teravus at gmail.com Sun Dec 13 11:14:49 2009 From: teravus at gmail.com (Teravus Ovares) Date: Sun, 13 Dec 2009 14:14:49 -0500 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: References: <200912042310.19845.eiffel56@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> <4B21ECE0.2010002@gmail.com> Message-ID: <34cc66250912131114j40a654cajea5bbdac29cb090d@mail.gmail.com> The issue with this approach is SLurls are not currently multi-grid friendly either.. they assume SecondLifeGrid. Regards Teravus On Sun, Dec 13, 2009 at 1:53 PM, Joshua Bell wrote: > On Thu, Dec 10, 2009 at 10:55 PM, Dzonatas Sol wrote: >> >> Wouldn't it be better if the map was a LLMediaPlugin. That way each map >> window can be customized to a grid. That would also mean each grid would >> load it's own viewer plugin. > > I would take this one step further: > > The map is a service provided by a grid, or region-domain in VWRAP parlance. > It should have no dependency on the agent domain. It serves to consume and > produce location identifiers into the grid which - should be URLs, e.g. > "given a friend's SLurl, show it on the map", "generate a SLurl for a > location so I can initiate a teleport to it". > > I would posit that this could be implemented entirely as a web page hosted > via a generic web context provider in a viewer - no need for a specific > plugin. The region domain would provide a standardized cap which is actually > a web page a la slurl.com, which generates URLs the viewer can act on (e.g. > to initiate teleport). > > If there does need to be agent domain/region domain interaction (E.g. > "highlight my friends on the map") then there would need to be some > VWRAP-ish negotiation, e.g. the agent domain(s) of your friends provide caps > that you can pass on to the region domain map service. > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From nexisentertainment at gmail.com Sun Dec 13 14:29:46 2009 From: nexisentertainment at gmail.com (Rob Nelson) Date: Sun, 13 Dec 2009 14:29:46 -0800 Subject: [sldev] VS2005: Build error (bison) In-Reply-To: <4B25224C.2010005@gmail.com> References: <78f69850912111642s7496ec01x9c4ff5704af25834@mail.gmail.com> <20091212021536.6f685a72.tayra.dagostino@gmail.com> <4B23ED08.5050505@xp2.de> <4B23F431.2090307@gmail.com> <4B24C990.2070902@xp2.de> <4B25224C.2010005@gmail.com> Message-ID: <1260743386.13976.4.camel@RAGE> It's possible that someone enabled Warnings as Errors in the cmake directive file things (I had to disable them so I can work on just getting some features of my viewer to work...) and the compile system is interpreting the Bison warnings as errors. I can't reproduce though, since I haven't developed for VS2005 for years. Rob On Sun, 2009-12-13 at 17:20 +0000, Robin Cornelius wrote: > Tillie Ariantho wrote: > > >> The viewer code base has always done this however and worked regardless. > > > > So how do I generate indra.l.cpp? That file is not written by the build, that error prevents it, so I am stuck with 2 of about 50 files not generated. :( > > > > Are you sure that is the error that is preventing it from working, I see > that message in a normal build? I would expect that its not actualy that > warning but something else going wrong. > > Is this snowglobe? on windows? i do remember there was talk of making > the building of indra.l.cpp optional and supplying a prebuild lexer and > parser as unless you are hacking up the LSL script compiler then its > pretty static and does not need to be rebuilt. > > Robin > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From secret.argent at gmail.com Sun Dec 13 15:09:46 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 13 Dec 2009 17:09:46 -0600 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: <4B2443B0.5000800@cox.net> References: <200912042310.19845.eiffel56@gmail.com> <1e01733d0912050336p164ce214nbc2a8a22be958626@mail.gmail.com> <20091207003350.GA5500@alinoe.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> <4B21ECE0.2010002@gmail.com> <05385612-87A0-452C-8489-A1ABC1C8A1F1@gmail.com> <4B227044.3070100@gmail.com> <72EA9ED8-9DD6-4373-A551-8962B01283C8@gmail.com> <4B2443B0.5000800@cox.net> Message-ID: <5A641DB4-7113-4319-9E9E-FF2371DAA900@gmail.com> On 2009-12-12, at 19:30, Lawson English wrote: > So how would you handle extensions to viewer requirements? Like what? > Have a viewer for every virtual world you visit, even if there's > only one or two differences between it and the VWRAP standard? If the virtual world _requires_ extensions to visit it, I probably won't be visiting it. Just like I don't bother with web pages that don't work with most browsers. What this thread has been about is not something that should require extensions to the browser, it's a protocol design issue. Things like the locations of servers for in-game functionality should be negotiated at login, preferably using an arbitrary key-value list that can be extended as needed. It doesn't matter, though, whether it's done by capabilities or in HTTP header variables or in an XML file, there should not be any locations hard-coded into the client. From merov at lindenlab.com Sun Dec 13 22:25:44 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Sun, 13 Dec 2009 22:25:44 -0800 Subject: [sldev] Help getting started In-Reply-To: <92B53B24B0034C8E805E5AEB36B8FF50@LRBXPS> References: <92B53B24B0034C8E805E5AEB36B8FF50@LRBXPS> Message-ID: <78f69850912132225m39c3f972rbff22c172dbf6b07@mail.gmail.com> Hi Shorahmin, You having problems linking (llworldmipmap_test) or running (llagentaccess_test_ok) unit tests. I'm gathering from the boost lib you refered to that you're building on Windows. There isn't much more I can tell though. Could you let us know which platform you're building on, which build environment you're using, which scripts you're relying on among those we provide, and which target you're trying to build (RelWithDeb?). Cheers, - Merov On Thu, Dec 10, 2009 at 11:15 AM, Laurence Brickner wrote: > Thanks Merov and hi to everyone, > > > > Here are three examples of the error types I?m getting. > > > > fatal error LNK1104: cannot open file > 'libboost_signals-vc90-mt-gd-1_39.lib' llworldmipmap_test > > > > error PRJ0019: A tool returned an error code from "Generating > llagentaccess_test_ok.txt" llagentaccess_test_ok > > > > error LNK2001: unresolved external symbol "__declspec(dllimport) public: > __thiscall std::_Container_base::_Container_base(void)" > (__imp_??0_Container_base at std@@QAE at XZ) llqtwebkitd.lib > > > > Any help would be great. > > > > *Thanks, > > Shorahmin* > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091213/4f797211/attachment.htm From merov at lindenlab.com Sun Dec 13 23:37:02 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Sun, 13 Dec 2009 23:37:02 -0800 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: References: <200912042310.19845.eiffel56@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> <4B21ECE0.2010002@gmail.com> Message-ID: <78f69850912132337m1508fd34o49f2d07a809202f9@mail.gmail.com> Hi, On Sun, Dec 13, 2009 at 10:53 AM, Joshua Bell wrote: > On Thu, Dec 10, 2009 at 10:55 PM, Dzonatas Sol wrote: > >> Wouldn't it be better if the map was a LLMediaPlugin. That way each map >> window can be customized to a grid. That would also mean each grid would >> load it's own viewer plugin. >> > > I would take this one step further: > > The map is a service provided by a grid, or region-domain in VWRAP > parlance. It should have no dependency on the agent domain. It serves to > consume and produce location identifiers into the grid which - should be > URLs, e.g. "given a friend's SLurl, show it on the map", "generate a SLurl > for a location so I can initiate a teleport to it". > > I would posit that this could be implemented entirely as a web page hosted > via a generic web context provider in a viewer - no need for a specific > plugin. The region domain would provide a standardized cap which is actually > a web page a la slurl.com, which generates URLs the viewer can act on > (e.g. to initiate teleport). > Right, when we redesigned the map, we thought about actually using the slurl.com web page right there and render it with the internal browser. It seemed smart and all but there are data that currently cannot be accessed by the webapp, most importantly, the "green dots" (residents location) so we fell back to hacking the C++ code. Eventually though, we should think about having better webapps and use them in the viewer for this kind of features (as we do for some aspect of Search for instance). There's no reason to code 2 maps really, not to mention that getting all those rich infos browsable from a webapp would be great... Anyway, in the meantime, a "cap" to get the correct map that corresponds to the grid the resident is on seems like a good idea. That being said,about the current problem of OpenSim, the thing is that the new map is using a mipmap structure (subres tiles computed by stitching region tiles server side once a day) that allows fast zoom (like in the webapp actually, same data and similar method of mapping). Is OpenSim planning to do something similar or will it stick with the slow "one tile per region" solution? (which is very slow in zoomed out situations). Note: I think it's possible to modify the current mipmap and degrade it to use one single level of res, avoiding reimplementing the whole old map code which has been completely taken out. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091213/58539eba/attachment.htm From dahliatrimble at gmail.com Sun Dec 13 23:45:59 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sun, 13 Dec 2009 23:45:59 -0800 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: <78f69850912132337m1508fd34o49f2d07a809202f9@mail.gmail.com> References: <200912042310.19845.eiffel56@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> <4B21ECE0.2010002@gmail.com> <78f69850912132337m1508fd34o49f2d07a809202f9@mail.gmail.com> Message-ID: I was under the (possibly false) impression that the SL viewer used JPEG2000 discard levels as a means of mipmapping, at least for textures. The current OpenSim map tiles used with the traditional map feature are standard image assets, which should be encoded using JPEG2000. Is the Snowglobe map using JPEG2000 images as well? If so, what is the MIME type used for HTTP transfer? I had heard that standard Jpeg encoding and HTTP was used. Is there documentation available for the map tile protocol used with Snowglobe? On Sun, Dec 13, 2009 at 11:37 PM, Philippe (Merov) Bossut < merov at lindenlab.com> wrote: > Hi, > > On Sun, Dec 13, 2009 at 10:53 AM, Joshua Bell wrote: > >> On Thu, Dec 10, 2009 at 10:55 PM, Dzonatas Sol wrote: >> >>> Wouldn't it be better if the map was a LLMediaPlugin. That way each map >>> window can be customized to a grid. That would also mean each grid would >>> load it's own viewer plugin. >>> >> >> I would take this one step further: >> >> The map is a service provided by a grid, or region-domain in VWRAP >> parlance. It should have no dependency on the agent domain. It serves to >> consume and produce location identifiers into the grid which - should be >> URLs, e.g. "given a friend's SLurl, show it on the map", "generate a SLurl >> for a location so I can initiate a teleport to it". >> >> I would posit that this could be implemented entirely as a web page hosted >> via a generic web context provider in a viewer - no need for a specific >> plugin. The region domain would provide a standardized cap which is actually >> a web page a la slurl.com, which generates URLs the viewer can act on >> (e.g. to initiate teleport). >> > > Right, when we redesigned the map, we thought about actually using the > slurl.com web page right there and render it with the internal browser. It > seemed smart and all but there are data that currently cannot be accessed by > the webapp, most importantly, the "green dots" (residents location) so we > fell back to hacking the C++ code. Eventually though, we should think about > having better webapps and use them in the viewer for this kind of features > (as we do for some aspect of Search for instance). There's no reason to code > 2 maps really, not to mention that getting all those rich infos browsable > from a webapp would be great... > > Anyway, in the meantime, a "cap" to get the correct map that corresponds to > the grid the resident is on seems like a good idea. > > That being said,about the current problem of OpenSim, the thing is that the > new map is using a mipmap structure (subres tiles computed by stitching > region tiles server side once a day) that allows fast zoom (like in the > webapp actually, same data and similar method of mapping). Is OpenSim > planning to do something similar or will it stick with the slow "one tile > per region" solution? (which is very slow in zoomed out situations). Note: I > think it's possible to modify the current mipmap and degrade it to use one > single level of res, avoiding reimplementing the whole old map code which > has been completely taken out. > > Cheers, > - Merov > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091213/3eeda56b/attachment-0001.htm From tillie at xp2.de Mon Dec 14 00:43:02 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Mon, 14 Dec 2009 09:43:02 +0100 Subject: [sldev] Snowglobe Installer: two bugs In-Reply-To: <4B252379.3000001@gmail.com> References: <78f69850911181400o7c7a71a9k9ed02887683aebe4@mail.gmail.com> <4B24CD6E.7040409@xp2.de> <4B24D5F8.9050200@xp2.de> <4B252379.3000001@gmail.com> Message-ID: <4B25FA96.9030408@xp2.de> On 13.12.2009 18:25, Robin Cornelius wrote: >> seems there is a bug in the installer (tested on Win7): it doesn't check if 'Snowglobe' already exists on the desktop. Which results in: >> >> - "installing desktop icon" message >> - nothing seems to happen >> - I rightclick the old snowglobe icon to see if the parameters changed >> - explorer crashes >> - explorer comes back up with 2 'Snowglobe' icons >> - rightclicking the newly created one crashes explorer again, old one works >> >> So I have to delete the old one manually to get the new one working. >> >> >> And still the "Start now?" button I consider bad. Because if you had to give the installer "admin" rights for the installation, you then start Snowglobe with admin rights too. >> With the effect, that on this first start of SL all settings are written to your admin home, not to the home of the current users. > > Can you please add these to a JIRA so we don't forget about them! Did: Installation: "Start Second Life now?" starts SL with admin account/privileges http://jira.secondlife.com/browse/SNOW-335 Installation: conflict on destop icon creation http://jira.secondlife.com/browse/SNOW-394 From tillie at xp2.de Mon Dec 14 00:48:58 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Mon, 14 Dec 2009 09:48:58 +0100 Subject: [sldev] VS2005: Build error (bison) In-Reply-To: <4B25224C.2010005@gmail.com> References: <78f69850912111642s7496ec01x9c4ff5704af25834@mail.gmail.com> <20091212021536.6f685a72.tayra.dagostino@gmail.com> <4B23ED08.5050505@xp2.de> <4B23F431.2090307@gmail.com> <4B24C990.2070902@xp2.de> <4B25224C.2010005@gmail.com> Message-ID: <4B25FBFA.10801@xp2.de> On 13.12.2009 18:20, Robin Cornelius wrote: > Is this snowglobe? on windows? i do remember there was talk of making > the building of indra.l.cpp optional and supplying a prebuild lexer and > parser as unless you are hacking up the LSL script compiler then its > pretty static and does not need to be rebuilt. Can someone do this? :D And/or send me a working indra.l.cpp for 1.2.4? :p Tillie From tillie at xp2.de Mon Dec 14 01:10:01 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Mon, 14 Dec 2009 10:10:01 +0100 Subject: [sldev] VS2005: Build error (bison) In-Reply-To: <1260743386.13976.4.camel@RAGE> References: <78f69850912111642s7496ec01x9c4ff5704af25834@mail.gmail.com> <20091212021536.6f685a72.tayra.dagostino@gmail.com> <4B23ED08.5050505@xp2.de> <4B23F431.2090307@gmail.com> <4B24C990.2070902@xp2.de> <4B25224C.2010005@gmail.com> <1260743386.13976.4.camel@RAGE> Message-ID: <4B2600E9.5090902@xp2.de> On 13.12.2009 23:29, Rob Nelson wrote: > It's possible that someone enabled Warnings as Errors in the cmake > directive file things (I had to disable them so I can work on just > getting some features of my viewer to work...) and the compile system is > interpreting the Bison warnings as errors. Where do I change that? Tillie From carlo at alinoe.com Mon Dec 14 03:07:35 2009 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 14 Dec 2009 12:07:35 +0100 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: References: <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> <4B21ECE0.2010002@gmail.com> <78f69850912132337m1508fd34o49f2d07a809202f9@mail.gmail.com> Message-ID: <20091214110735.GA13200@alinoe.com> On Sun, Dec 13, 2009 at 11:45:59PM -0800, Dahlia Trimble wrote: > I was under the (possibly false) impression that the SL viewer used JPEG2000 > discard levels as a means of mipmapping, at least for textures. The current > OpenSim map tiles used with the traditional map feature are standard image > assets, which should be encoded using JPEG2000. Is the Snowglobe map using > JPEG2000 images as well? If so, what is the MIME type used for HTTP transfer? I > had heard that standard Jpeg encoding and HTTP was used. Using JPEG2000 won't work in this case. If you use one HUGE image for the whole world, then you have to download the whole image if you zoom in. If you lots of small images, then you have to download LOTS of images if you zoom out. Even if those become small when you zoom out, that would still be very inefficient (and slow) to do via HTTP. -- Carlo Wood From tillie at xp2.de Mon Dec 14 04:04:16 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Mon, 14 Dec 2009 13:04:16 +0100 Subject: [sldev] VS2005: Build error (bison) In-Reply-To: <4B2600E9.5090902@xp2.de> References: <78f69850912111642s7496ec01x9c4ff5704af25834@mail.gmail.com> <20091212021536.6f685a72.tayra.dagostino@gmail.com> <4B23ED08.5050505@xp2.de> <4B23F431.2090307@gmail.com> <4B24C990.2070902@xp2.de> <4B25224C.2010005@gmail.com> <1260743386.13976.4.camel@RAGE> <4B2600E9.5090902@xp2.de> Message-ID: <4B2629C0.6000906@xp2.de> Hello, okay, first time the build succeeded. What I did: - reinstalled Visual Studio 2005 to C:\dev\vc80, short path with no spaced - linden\indra\lscript\lscript_compile\bison.bat: commented out last line: rem %bison% -d -o %output% %input% - copied the *generated* files from linden\indra\lscript\lscript_compile to linden\indra\build-vc80\lscript\lscript_compile and removed the _generated from the name - copied fmod+quicktime libs to linden\libraries\i686-win32\lib\[release|debug] instead of linden\libraries\i686-win32\lib_[release|debug] - ran Visual Studio as 'admin', or else build will fail in the end Didn't try yet if the client is running, but at least it is building now. :-) Didn't try command line cmake compile either, only from the UI. Tillie From tillie at xp2.de Mon Dec 14 04:24:06 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Mon, 14 Dec 2009 13:24:06 +0100 Subject: [sldev] VS2005: Build error (bison) In-Reply-To: <4B2629C0.6000906@xp2.de> References: <78f69850912111642s7496ec01x9c4ff5704af25834@mail.gmail.com> <20091212021536.6f685a72.tayra.dagostino@gmail.com> <4B23ED08.5050505@xp2.de> <4B23F431.2090307@gmail.com> <4B24C990.2070902@xp2.de> <4B25224C.2010005@gmail.com> <1260743386.13976.4.camel@RAGE> <4B2600E9.5090902@xp2.de> <4B2629C0.6000906@xp2.de> Message-ID: <4B262E66.6030202@xp2.de> On 14.12.2009 13:04, Tillie Ariantho wrote: > okay, first time the build succeeded. Looks like the client is running well. But I have no sound at all. Any hints how to fix this? Probably some libs missing somewhere during build...? Tillie From aimee.trescothick at gmail.com Mon Dec 14 04:49:11 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Mon, 14 Dec 2009 12:49:11 +0000 Subject: [sldev] Blowing wind In-Reply-To: <4B21145E.8040004@lindenlab.com> References: <91E137EF-6B9B-4EEE-8C24-939C108DA7A6@ama-zing.co.uk> <31E66752-7593-43F0-A68D-E5EAE13CBECB@gmail.com> <4B21145E.8040004@lindenlab.com> Message-ID: <2AAF5DCB-BF01-4A78-A09F-208E11F67A3C@gmail.com> Nope, that's not it, the two assignments to *cursamplep in the code below are one each for left and right, so writing an interleaved pair to the buffer increments the sample pointer by stride twice, stride is half a stereo pair. I've just tried testing it by building on Windows and forcing the mixer mode to FSOUND_MIXER_BLENDMODE or FSOUND_MIXER_QUALITY_FPU. Blend mode is a non-starter as it is already marked as obsolete in FMOD 3.75 and forcing it fails, FPU mode results in no audible wind noise at all. So it really does look like the striding which is only used for these two modes is pointless. My rewritten version works with any mixer mode, so long as long as MIXBUFFERFORMAT is defined appropriately, I guess this is something that has just never worked, and the situations that would need it are so rare now no one's noticed before that it doesn't work. Aimee. On 10 Dec 2009, at 15:31, Tofu Linden wrote: > I don't have time to investigate properly, but my first guess would be > that this is because our wind is stereo (interleaved > MIXBUFFERFORMAT_Ts). > > Aimee Trescothick wrote: >> Can anyone explain how the below piece of the existing code from the wind noise synthesizer has ever actually worked properly, with MIXBUFFERFORMAT_T defined as S16 and stride set to 4 bytes? >> >> U8 *cursamplep = (U8*)newbuffer; >> ... >> >> MIXBUFFERFORMAT_T sample; >> ... >> >> sample = llfloor(((F32)nextSample*32768.f*(1.0f - mCurrentPanGainR))+0.5f); >> *(MIXBUFFERFORMAT_T*)cursamplep = llclamp(sample, (MIXBUFFERFORMAT_T)-32768, >> (MIXBUFFERFORMAT_T)32767); >> cursamplep += stride; >> >> sample = llfloor(((F32)nextSample*32768.f*mCurrentPanGainR)+0.5f); >> *(MIXBUFFERFORMAT_T*)cursamplep = llclamp(sample, (MIXBUFFERFORMAT_T)-32768, >> (MIXBUFFERFORMAT_T)32767); >> cursamplep += stride; >> >> On Windows and Linux MIXBUFFERFORMAT_T is defined as S16, and if the FMOD mixer mode is FSOUND_MIXER_QUALITY_FPU or FSOUND_MIXER_BLENDMODE, stride is set to 4 bytes, as these modes both use a 32-bit mix buffer. >> >> But as far as I can see, that's just going to write signed 16-bit integers into the first two bytes of the 4-byte sample, skipping over the other two bytes, leaving them at whatever they were before (zero, as wind is the first thing that goes in the buffer after it is cleared). When FMOD tries to read the 4-bytes back as either 32-bit signed integers (FSOUND_MIXER_BLENDMODE), or 32-bit float (FSOUND_MIXER_QUALITY_FPU) that's just going to go horribly wrong. >> >> MIXBUFFERFORMAT_T is only defined as S32 on the Mac, on Windows and Linux it is S16 as one of FMOD's 16-bit MMX mixers is normally used. The only time I would imagine this situation occurs is on a PC without MMX (or when LL_VALGRIND is defined on Linux for testing, which specifically forces the mixer mode to FSOUND_MIXER_QUALITY_FPU). >> >> If this has never worked anyway, it would seem to make sense to turn off the wind generator for these mixer modes to avoid making a horrible noise, drop the striding which will simplify things elsewhere, and just declare cursamplep as MIXBUFFERFORMAT_T in the first place, removing the need to typecast it ... or am I missing something? >> >> (If you followed me this far you're doing better than I am :) >> >> Aimee. From aimee.trescothick at gmail.com Mon Dec 14 05:08:00 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Mon, 14 Dec 2009 13:08:00 +0000 Subject: [sldev] VS2005: Build error (bison) In-Reply-To: <4B262E66.6030202@xp2.de> References: <78f69850912111642s7496ec01x9c4ff5704af25834@mail.gmail.com> <20091212021536.6f685a72.tayra.dagostino@gmail.com> <4B23ED08.5050505@xp2.de> <4B23F431.2090307@gmail.com> <4B24C990.2070902@xp2.de> <4B25224C.2010005@gmail.com> <1260743386.13976.4.camel@RAGE> <4B2600E9.5090902@xp2.de> <4B2629C0.6000906@xp2.de> <4B262E66.6030202@xp2.de> Message-ID: Did you install the both the FMOD libs and headers as per http://wiki.secondlife.com/wiki/Microsoft_Windows_Builds#Fmod before running develop.py? cmake caches it's settings in CMakeCache.txt, so if wasn't there the first time it may not have noticed it is available now. Have a look in CMakeCache.txt in the build directory for ... //Use closed source FMOD sound library. FMOD:BOOL=ON Aimee. On 14 Dec 2009, at 12:24, Tillie Ariantho wrote: > On 14.12.2009 13:04, Tillie Ariantho wrote: > >> okay, first time the build succeeded. > > Looks like the client is running well. But I have no sound at all. Any hints how to fix this? Probably some libs missing somewhere during build...? > > Tillie > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From tillie at xp2.de Mon Dec 14 05:22:59 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Mon, 14 Dec 2009 14:22:59 +0100 Subject: [sldev] VS2005: Build error (bison) In-Reply-To: References: <78f69850912111642s7496ec01x9c4ff5704af25834@mail.gmail.com> <20091212021536.6f685a72.tayra.dagostino@gmail.com> <4B23ED08.5050505@xp2.de> <4B23F431.2090307@gmail.com> <4B24C990.2070902@xp2.de> <4B25224C.2010005@gmail.com> <1260743386.13976.4.camel@RAGE> <4B2600E9.5090902@xp2.de> <4B2629C0.6000906@xp2.de> <4B262E66.6030202@xp2.de> Message-ID: <4B263C33.1020103@xp2.de> On 14.12.2009 14:08, Aimee Trescothick wrote: > Did you install the both the FMOD libs and headers as per http://wiki.secondlife.com/wiki/Microsoft_Windows_Builds#Fmod before running develop.py? > > cmake caches it's settings in CMakeCache.txt, so if wasn't there the first time it may not have noticed it is available now. Have a look in CMakeCache.txt in the build directory for ... > > //Use closed source FMOD sound library. > FMOD:BOOL=ON That may have been it: .. Building with FMOD audio support ... Wasn't in before. Tillie From brickrte at hughes.net Mon Dec 14 05:44:34 2009 From: brickrte at hughes.net (Laurence Brickner) Date: Mon, 14 Dec 2009 08:44:34 -0500 Subject: [sldev] Help getting started In-Reply-To: <78f69850912132225m39c3f972rbff22c172dbf6b07@mail.gmail.com> References: <92B53B24B0034C8E805E5AEB36B8FF50@LRBXPS> <78f69850912132225m39c3f972rbff22c172dbf6b07@mail.gmail.com> Message-ID: <20467D3CAA514975B7E946DA64470079@LRBXPS> Thanks for the reply Merov, Actually, I've made some progress. I was using VS 2008 on XP Pro. I have reinstalled VS 2005 and manually added the cygwin directories. I now reportedly get a successful rebuild. When I start debugging, the media test app launches and gives media events in the console display as I move the mouse around over the Windows part. But the viewer doesn't launch. In fact, I can't find it. LOL. So, I'm sure it's operator-error at this point. I just noticed that installing the Server SDK didn't put anything in the directories. So I have some work to do. Shor _____ From: Philippe (Merov) Bossut [mailto:merov at lindenlab.com] Sent: Monday, December 14, 2009 01:26 To: brickrte at odyssey.net Cc: Life DEv Second Subject: Re: [sldev] Help getting started Hi Shorahmin, You having problems linking (llworldmipmap_test) or running (llagentaccess_test_ok) unit tests. I'm gathering from the boost lib you refered to that you're building on Windows. There isn't much more I can tell though. Could you let us know which platform you're building on, which build environment you're using, which scripts you're relying on among those we provide, and which target you're trying to build (RelWithDeb?). Cheers, - Merov On Thu, Dec 10, 2009 at 11:15 AM, Laurence Brickner wrote: Thanks Merov and hi to everyone, Here are three examples of the error types I'm getting. fatal error LNK1104: cannot open file 'libboost_signals-vc90-mt-gd-1_39.lib' llworldmipmap_test error PRJ0019: A tool returned an error code from "Generating llagentaccess_test_ok.txt" llagentaccess_test_ok error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Container_base::_Container_base(void)" (__imp_??0_Container_base at std@@QAE at XZ) llqtwebkitd.lib Any help would be great. Thanks, Shorahmin _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091214/3285cfb7/attachment-0001.htm From dahliatrimble at gmail.com Mon Dec 14 12:01:39 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Mon, 14 Dec 2009 12:01:39 -0800 Subject: [sldev] Blowing wind In-Reply-To: <2AAF5DCB-BF01-4A78-A09F-208E11F67A3C@gmail.com> References: <91E137EF-6B9B-4EEE-8C24-939C108DA7A6@ama-zing.co.uk> <31E66752-7593-43F0-A68D-E5EAE13CBECB@gmail.com> <4B21145E.8040004@lindenlab.com> <2AAF5DCB-BF01-4A78-A09F-208E11F67A3C@gmail.com> Message-ID: I'm not familiar with the viewer code, but I have seen similar situations in code developed for multiple platforms use which use concepts like this to force word alignment of dissimilar types or when endianness could be an issue. Could that be a factor here? On Mon, Dec 14, 2009 at 4:49 AM, Aimee Trescothick < aimee.trescothick at gmail.com> wrote: > Nope, that's not it, the two assignments to *cursamplep in the code below > are one each for left and right, so writing an interleaved pair to the > buffer increments the sample pointer by stride twice, stride is half a > stereo pair. > > I've just tried testing it by building on Windows and forcing the mixer > mode to FSOUND_MIXER_BLENDMODE or FSOUND_MIXER_QUALITY_FPU. Blend mode is a > non-starter as it is already marked as obsolete in FMOD 3.75 and forcing it > fails, FPU mode results in no audible wind noise at all. > > So it really does look like the striding which is only used for these two > modes is pointless. My rewritten version works with any mixer mode, so long > as long as MIXBUFFERFORMAT is defined appropriately, I guess this is > something that has just never worked, and the situations that would need it > are so rare now no one's noticed before that it doesn't work. > > Aimee. > > On 10 Dec 2009, at 15:31, Tofu Linden wrote: > > > I don't have time to investigate properly, but my first guess would be > > that this is because our wind is stereo (interleaved > > MIXBUFFERFORMAT_Ts). > > > > Aimee Trescothick wrote: > >> Can anyone explain how the below piece of the existing code from the > wind noise synthesizer has ever actually worked properly, with > MIXBUFFERFORMAT_T defined as S16 and stride set to 4 bytes? > >> > >> U8 *cursamplep = (U8*)newbuffer; > >> ... > >> > >> MIXBUFFERFORMAT_T sample; > >> ... > >> > >> sample = llfloor(((F32)nextSample*32768.f*(1.0f - > mCurrentPanGainR))+0.5f); > >> *(MIXBUFFERFORMAT_T*)cursamplep = llclamp(sample, > (MIXBUFFERFORMAT_T)-32768, > >> > (MIXBUFFERFORMAT_T)32767); > >> cursamplep += stride; > >> > >> sample = llfloor(((F32)nextSample*32768.f*mCurrentPanGainR)+0.5f); > >> *(MIXBUFFERFORMAT_T*)cursamplep = llclamp(sample, > (MIXBUFFERFORMAT_T)-32768, > >> > (MIXBUFFERFORMAT_T)32767); > >> cursamplep += stride; > >> > >> On Windows and Linux MIXBUFFERFORMAT_T is defined as S16, and if the > FMOD mixer mode is FSOUND_MIXER_QUALITY_FPU or FSOUND_MIXER_BLENDMODE, > stride is set to 4 bytes, as these modes both use a 32-bit mix buffer. > >> > >> But as far as I can see, that's just going to write signed 16-bit > integers into the first two bytes of the 4-byte sample, skipping over the > other two bytes, leaving them at whatever they were before (zero, as wind is > the first thing that goes in the buffer after it is cleared). When FMOD > tries to read the 4-bytes back as either 32-bit signed integers > (FSOUND_MIXER_BLENDMODE), or 32-bit float (FSOUND_MIXER_QUALITY_FPU) that's > just going to go horribly wrong. > >> > >> MIXBUFFERFORMAT_T is only defined as S32 on the Mac, on Windows and > Linux it is S16 as one of FMOD's 16-bit MMX mixers is normally used. The > only time I would imagine this situation occurs is on a PC without MMX (or > when LL_VALGRIND is defined on Linux for testing, which specifically forces > the mixer mode to FSOUND_MIXER_QUALITY_FPU). > >> > >> If this has never worked anyway, it would seem to make sense to turn off > the wind generator for these mixer modes to avoid making a horrible noise, > drop the striding which will simplify things elsewhere, and just declare > cursamplep as MIXBUFFERFORMAT_T in the first place, removing the need to > typecast it ... or am I missing something? > >> > >> (If you followed me this far you're doing better than I am :) > >> > >> Aimee. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091214/3099fc92/attachment.htm From tigrospottystripes at gmail.com Mon Dec 14 12:46:31 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 14 Dec 2009 18:46:31 -0200 Subject: [sldev] Tutorial for SL shaders ("for dummies")? In-Reply-To: <4D4E868E-196E-4FC0-A33A-D32FDF9DEE0D@gmail.com> References: <4B246F76.4020502@gmail.com> <171234.6045.qm@web59107.mail.re1.yahoo.com> <4B250EE9.60908@gmail.com> <4D4E868E-196E-4FC0-A33A-D32FDF9DEE0D@gmail.com> Message-ID: <4B26A427.6040300@Gmail.com> Is there somewhere some tutorial, with examples and all, for editing and adding to the client's shaders made with people that have never done this type of thing before in mind? From open at autistici.org Mon Dec 14 13:39:50 2009 From: open at autistici.org (Opensource Obscure) Date: Mon, 14 Dec 2009 21:39:50 +0000 Subject: [sldev] =?utf-8?q?Tutorial_for_SL_shaders_=28=22for_dummies=22=29?= =?utf-8?q?=3F?= In-Reply-To: <4B26A427.6040300@Gmail.com> References: <4B246F76.4020502@gmail.com> <171234.6045.qm@web59107.mail.re1.yahoo.com> <4B250EE9.60908@gmail.com> <4D4E868E-196E-4FC0-A33A-D32FDF9DEE0D@gmail.com> <4B26A427.6040300@Gmail.com> Message-ID: <70b4859ecb79e094e6816705bb536c59@localhost> On Mon, 14 Dec 2009 18:46:31 -0200, Tigro Spottystripes wrote: > Is there somewhere some tutorial, with examples and all, for editing and > adding to the client's shaders made with people that have never done > this type of thing before in mind? not sure it's what you're looking for, but.. How to build your own SL viewer with Experimental Projected Textures http://friendfeed.com/secondlife/c3a6d17b/how-to-build-your-own-sl-viewer-with here's yet another demo video I made about that http://www.youtube.com/watch?v=FAB4o4k31es cheers, Opensource Obscure From tillie at xp2.de Mon Dec 14 14:33:23 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Mon, 14 Dec 2009 23:33:23 +0100 Subject: [sldev] settings.xml: new entry vanishing on SL exit Message-ID: <4B26BD33.6010700@xp2.de> Hello, 1. Where do I define that entries I added to the settings.xml dont get deleted when quitting the SL client? I've added the block IncludeTimestampInSnapshotName Comment Append timstamp to snapshot filename Persist 1 Type Boolean Value 0 and have added the required functions to llfloatersnapshot.cpp which including the proper gSavedSettings.setBOOL("IncludeTimestampInSnapshotName", TRUE) and gSavedSettings.getBOOL("IncludeTimestampInSnapshotName") calls. As soon as I quit the client, the block shown above is gone from the settings.xml. The code to save snapshot as Snapshot-yyyy-mm-dd_HH_MM-SS-XXX. already works. Only the vanishing setting lets the client crash on next startup + opening snapshot window. 2. And I dont know how to resize the floater window (floater_snapshot.xml) so the additional line fits in: Any ideas? Tillie From monkowsk at fishkill.ibm.com Mon Dec 14 15:21:30 2009 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Mon, 14 Dec 2009 18:21:30 -0500 Subject: [sldev] settings.xml: new entry vanishing on SL exit In-Reply-To: <4B26BD33.6010700@xp2.de> References: <4B26BD33.6010700@xp2.de> Message-ID: <4B26C87A.4070009@fishkill.ibm.com> 1. "the" settings.xml file is misleading. Each user has a user_settings/settings.xml file, but the main file is app_settings/settings.xml. That's the one you have to change. 2. Becauser someone hardcoded the height in the code. Search for "526" in llfloatersnapshot.cpp Mike Tillie Ariantho wrote: > Hello, > > 1. Where do I define that entries I added to the settings.xml dont get deleted when quitting the SL client? > > I've added the block > > IncludeTimestampInSnapshotName > > Comment > Append timstamp to snapshot filename > Persist > 1 > Type > Boolean > Value > 0 > > > and have added the required functions to llfloatersnapshot.cpp which including the proper > > gSavedSettings.setBOOL("IncludeTimestampInSnapshotName", TRUE) > and > gSavedSettings.getBOOL("IncludeTimestampInSnapshotName") > calls. > > As soon as I quit the client, the block shown above is gone from the settings.xml. > The code to save snapshot as Snapshot-yyyy-mm-dd_HH_MM-SS-XXX. already works. > Only the vanishing setting lets the client crash on next startup + opening snapshot window. > > > 2. And I dont know how to resize the floater window (floater_snapshot.xml) so the additional line fits in: > > > can_resize="false" follows="left|top" height="546" name="Snapshot" > [...] > > I increased that height from 526 to 546 but still the last (new) line is floating outside the window now. Do I have to change another value? > I added that block to the file: > > name="add_timestamp_check" /> > > > Any ideas? > > Tillie > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From tillie at xp2.de Mon Dec 14 15:46:00 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Tue, 15 Dec 2009 00:46:00 +0100 Subject: [sldev] settings.xml: new entry vanishing on SL exit In-Reply-To: <4B26C87A.4070009@fishkill.ibm.com> References: <4B26BD33.6010700@xp2.de> <4B26C87A.4070009@fishkill.ibm.com> Message-ID: <4B26CE38.3040101@xp2.de> On 15.12.2009 00:21, Mike Monkowski wrote: > 1. "the" settings.xml file is misleading. Each user has a > user_settings/settings.xml file, but the main file is > app_settings/settings.xml. That's the one you have to change. I changed both, but it seems that SL then doesn't use my test copy of the sl folder but falls back to the original folder for reading the settings.xml. Will check... > 2. Becauser someone hardcoded the height in the code. Search for "526" > in llfloatersnapshot.cpp ohmigod, it's true: S32 LLFloaterSnapshot::sUIWinHeightLong = 526 ; so what are the values in the xml files for? I need to recompile the client for each floater size change? Uhm... why arent the values from the xml files used? :-( Tillie From brickrte at hughes.net Mon Dec 14 17:55:08 2009 From: brickrte at hughes.net (Laurence Brickner) Date: Mon, 14 Dec 2009 20:55:08 -0500 Subject: [sldev] ShowLookAt Message-ID: Merov et al. I have succeeded in compiling the client. Next I made some minor changes in LLHUDEffectLookAt.cpp (colors and shapes of the marker)just to make sure I was in the right place. So presumably, I need to "Checkout the file and get assigned to SNOW-386. How do I do this? Also, could you clarify what I need to do to get the client to attempt to use a plugin. Thanks, Shor/Larry Thanks, Larry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091214/25f12173/attachment-0001.htm From merov at lindenlab.com Mon Dec 14 20:30:37 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Mon, 14 Dec 2009 20:30:37 -0800 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: References: <200912042310.19845.eiffel56@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> <4B21ECE0.2010002@gmail.com> <78f69850912132337m1508fd34o49f2d07a809202f9@mail.gmail.com> Message-ID: <78f69850912142030mf9427b5m460c7c2d22168e7c@mail.gmail.com> Hi, On Sun, Dec 13, 2009 at 11:45 PM, Dahlia Trimble wrote: > I was under the (possibly false) impression that the SL viewer used > JPEG2000 discard levels as a means of mipmapping, at least for textures. The > current OpenSim map tiles used with the traditional map feature are standard > image assets, which should be encoded using JPEG2000. Is the Snowglobe map > using JPEG2000 images as well? > No, Snowglobe is using jpeg images, the same ones that are used by the SLURL webapp. But that's a red herring anyway. The JPEG2000 multires property would not help us a bit with the map of the entire VW unless we were to create a single *huge* image of the entire universe which would be crazy when zooming in. When zooming out, accessing each region to get one single pixel for each region is very costly (even assuming JPEG2000 is helping here) and the main reason for the slowness of the old map. When I said "mipmapping" then I referred to the general "multires image rendering" aspect of the technique, not its implementation as OpenGL textures. The map in particular is a very "hollow" mipmap with vast area of "ocean" and we optimize for that, avoiding allocating memory for those tiles. > Is there documentation available for the map tile protocol used with > Snowglobe > We use the "HTTP Texture" way of fetching images. It is documented here: http://wiki.secondlife.com/wiki/HTTP_Texture Reading through it tonight, I realize this doc needs to be cleaned up of old dev stuff... Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091214/3406867e/attachment.htm From merov at lindenlab.com Mon Dec 14 21:40:12 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Mon, 14 Dec 2009 21:40:12 -0800 Subject: [sldev] ShowLookAt In-Reply-To: References: Message-ID: <78f69850912142140n5731b018je95580e59d662dc9@mail.gmail.com> Hi Larry, On Mon, Dec 14, 2009 at 5:55 PM, Laurence Brickner wrote: > Meroe succeeded in compiling the client. Next I made some minor changes > in LLHUDEffectLookAt.cpp (colors and shapes of the marker)just to make > sure I was in the right place. So presumably, I need to ?Checkout the file > and get assigned to SNOW-386. How do I do this? > If you built and tweaked the code, you apparently already have the file "checked out". We're using svn which is a concurrent source control system so there's really no need to lock a file for check out. For assignment, you're not a Snowglobe committer (yet!) so you should simply produce a patch and attach the patch file to the JIRA, with a comment about what you did. Producing a patch file with svn is easy: under cygwin, navigate to the root of the project and type: svn diff > mypatch.patch We tend to name the patches with the JIRA name so something like "SNOW-386.patch" > Also, could you clarify what I need to do to get the client to attempt to > use a plugin. > This has nothing to do with SNOW-386 right? We only have media plugins implemented in Snowglobe right now. They need to be dropped along side the other plugins and whichever mime type they render documented in mime_types.xml. There's a documentation being written right now by the media team about all this but they're still working on this. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091214/1bb95261/attachment.htm From tigrospottystripes at gmail.com Tue Dec 15 07:23:50 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Tue, 15 Dec 2009 13:23:50 -0200 Subject: [sldev] Tutorial for SL shaders ("for dummies")? In-Reply-To: <70b4859ecb79e094e6816705bb536c59@localhost> References: <4B246F76.4020502@gmail.com> <171234.6045.qm@web59107.mail.re1.yahoo.com> <4B250EE9.60908@gmail.com> <4D4E868E-196E-4FC0-A33A-D32FDF9DEE0D@gmail.com> <4B26A427.6040300@Gmail.com> <70b4859ecb79e094e6816705bb536c59@localhost> Message-ID: <4B27AA06.2080905@Gmail.com> That doesn't seem to get in any details about actually performing changes in the shader files themselves... Opensource Obscure escreveu: > On Mon, 14 Dec 2009 18:46:31 -0200, Tigro Spottystripes > wrote: > >> Is there somewhere some tutorial, with examples and all, for editing and >> adding to the client's shaders made with people that have never done >> this type of thing before in mind? >> > > not sure it's what you're looking for, but.. > > How to build your own SL viewer with Experimental Projected Textures > http://friendfeed.com/secondlife/c3a6d17b/how-to-build-your-own-sl-viewer-with > > here's yet another demo video I made about that > http://www.youtube.com/watch?v=FAB4o4k31es > > cheers, > Opensource Obscure > > From monkowsk at fishkill.ibm.com Tue Dec 15 08:38:41 2009 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Tue, 15 Dec 2009 11:38:41 -0500 Subject: [sldev] settings.xml: new entry vanishing on SL exit In-Reply-To: <4B26CE38.3040101@xp2.de> References: <4B26BD33.6010700@xp2.de> <4B26C87A.4070009@fishkill.ibm.com> <4B26CE38.3040101@xp2.de> Message-ID: <4B27BB91.1010600@fishkill.ibm.com> Tillie Ariantho wrote: > I changed both, but it seems that SL then doesn't use my test copy of the sl folder but falls back to the original folder for reading the settings.xml. Will check... It looks relative to the directory that you are running in. > so what are the values in the xml files for? I need to recompile the client for each floater size change? Uhm... why arent the values from the xml files used? :-( For the most part, the values in the xml file are used. The programmer was lazy here. Mike From monkowsk at fishkill.ibm.com Tue Dec 15 08:49:16 2009 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Tue, 15 Dec 2009 11:49:16 -0500 Subject: [sldev] Tutorial for SL shaders ("for dummies")? In-Reply-To: <4B26A427.6040300@Gmail.com> References: <4B246F76.4020502@gmail.com> <171234.6045.qm@web59107.mail.re1.yahoo.com> <4B250EE9.60908@gmail.com> <4D4E868E-196E-4FC0-A33A-D32FDF9DEE0D@gmail.com> <4B26A427.6040300@Gmail.com> Message-ID: <4B27BE0C.9020504@fishkill.ibm.com> Tigro Spottystripes wrote: > Is there somewhere some tutorial, with examples and all, for editing and > adding to the client's shaders made with people that have never done > this type of thing before in mind? Starting from where? Do you know OpenGL shader language, but not the SL use of it? Or are you writing your first computer program? Mike From tigrospottystripes at gmail.com Tue Dec 15 13:27:49 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Tue, 15 Dec 2009 19:27:49 -0200 Subject: [sldev] Tutorial for SL shaders ("for dummies")? In-Reply-To: <4B27BE0C.9020504@fishkill.ibm.com> References: <4B246F76.4020502@gmail.com> <171234.6045.qm@web59107.mail.re1.yahoo.com> <4B250EE9.60908@gmail.com> <4D4E868E-196E-4FC0-A33A-D32FDF9DEE0D@gmail.com> <4B26A427.6040300@Gmail.com> <4B27BE0C.9020504@fishkill.ibm.com> Message-ID: <4B27FF55.5070006@Gmail.com> Somewhere between the two, worse case at least somthing explaining the specifics of how SL uses it and what are the particularities for the .glsl files the client uses (including the exact structure of files and things that work and doesn't work, things that are not following the standards etc) Mike Monkowski escreveu: > Tigro Spottystripes wrote: >> Is there somewhere some tutorial, with examples and all, for editing and >> adding to the client's shaders made with people that have never done >> this type of thing before in mind? > > Starting from where? Do you know OpenGL shader language, but not the > SL use of it? Or are you writing your first computer program? > > Mike > From monkowsk at fishkill.ibm.com Tue Dec 15 14:57:54 2009 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Tue, 15 Dec 2009 17:57:54 -0500 Subject: [sldev] Tutorial for SL shaders ("for dummies")? In-Reply-To: <4B27FF55.5070006@Gmail.com> References: <4B246F76.4020502@gmail.com> <171234.6045.qm@web59107.mail.re1.yahoo.com> <4B250EE9.60908@gmail.com> <4D4E868E-196E-4FC0-A33A-D32FDF9DEE0D@gmail.com> <4B26A427.6040300@Gmail.com> <4B27BE0C.9020504@fishkill.ibm.com> <4B27FF55.5070006@Gmail.com> Message-ID: <4B281472.7040104@fishkill.ibm.com> Tigro Spottystripes wrote: > Somewhere between the two, worse case at least somthing explaining the > specifics of how SL uses it and what are the particularities for the > .glsl files the client uses (including the exact structure of files and > things that work and doesn't work, things that are not following the > standards etc) Well, the "worst case" documentation is probably app_settings/shaders/shader_hierarchy.txt then you look at llviewershadermgr.cpp I haven't done more than look at them, but the in-line comments don't look too bad. It would be nice if doxygen handeled GLSL, but I don't think it does. Mike From stickman at gmail.com Tue Dec 15 17:03:25 2009 From: stickman at gmail.com (Stickman) Date: Tue, 15 Dec 2009 17:03:25 -0800 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <4B248D18.6040100@planetziggy.com> References: <4B248D18.6040100@planetziggy.com> Message-ID: Ping. The comfort or early warning I expect is that we're going to get better tools to see behind the scenes on scripts before the limits actually show up. My fear is that it's going to be right when midterms crop up and have a two week window to rewrite every script I've ever written. Can any Lindens on this project provide any information, or point us to a magical page on the wiki that explains this? Or, at the very least, give us a rough timetable so we know about what time is appropriate to begin our panicked search for information? Thanks much! Stickman On Sat, Dec 12, 2009 at 10:43 PM, Ziggy Puff wrote: > I was about to post a question on this as well - my wife heard about that > blog post (it's spreading pretty quickly among content creators, I think) > and so I took a look. I found some good info in 3 or 4 of Babbage Linden's > office hour chat logs. More details on the exact algorithms would be very > helpful. Some questions I had after going through the material I could find: > > * Is each script 'charged' 16K/64K, or just what it's using? Is the check > made on rez / parcel change, or periodically? Maybe this is a meaningless > question, but I thought Mono scripts could scale their memory footprint up > and down, in which case a script could have a small footprint when it's > rezzed. > > * Avatar / attachment pool vs. parcel pool - if an av's pool runs out, does > an attachment try to take memory from the parcel pool? > > * The GUI support for reporting script memory usage - will it show the > footprint of individual objects, like the 'Top Scripts' window? How about > individual attachments? I imagine the last object that would go over the > threshold will be the one that's not allowed to rez, but that probably won't > be the least efficiently scripted item the person is wearing. > > Ziggy > > Stickman wrote: >> >> I don't know what the official name is, but it's either Parcel Limits, >> Script Limits, or Memory Limits. >> >> It's been a while since I've heard any official word about it. Last I >> did hear, LL was gathering statistics and didn't know exactly how they >> were going to implement it, let alone what the limits would be. >> >> Has LL made any decisions, and would they be willing to share them? >> More minds on the issue can spot any holes or problems that could >> arise, and there's still some rumbling panic among the masses that >> can't be confirmed or quelled since we don't know how it'll work. >> >> Many thanks, >> >> Stickman >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> >> > > > From tigrospottystripes at gmail.com Tue Dec 15 17:10:26 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Tue, 15 Dec 2009 23:10:26 -0200 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <4B248D18.6040100@planetziggy.com> Message-ID: <4B283382.9050009@Gmail.com> Btw, will unfit script just not run or will the objects they are in actually become unrezzable making scripts unfixable even by the creators? Stickman escreveu: > Ping. > > The comfort or early warning I expect is that we're going to get > better tools to see behind the scenes on scripts before the limits > actually show up. My fear is that it's going to be right when midterms > crop up and have a two week window to rewrite every script I've ever > written. > > Can any Lindens on this project provide any information, or point us > to a magical page on the wiki that explains this? Or, at the very > least, give us a rough timetable so we know about what time is > appropriate to begin our panicked search for information? > > Thanks much! > > Stickman > > On Sat, Dec 12, 2009 at 10:43 PM, Ziggy Puff wrote: > >> I was about to post a question on this as well - my wife heard about that >> blog post (it's spreading pretty quickly among content creators, I think) >> and so I took a look. I found some good info in 3 or 4 of Babbage Linden's >> office hour chat logs. More details on the exact algorithms would be very >> helpful. Some questions I had after going through the material I could find: >> >> * Is each script 'charged' 16K/64K, or just what it's using? Is the check >> made on rez / parcel change, or periodically? Maybe this is a meaningless >> question, but I thought Mono scripts could scale their memory footprint up >> and down, in which case a script could have a small footprint when it's >> rezzed. >> >> * Avatar / attachment pool vs. parcel pool - if an av's pool runs out, does >> an attachment try to take memory from the parcel pool? >> >> * The GUI support for reporting script memory usage - will it show the >> footprint of individual objects, like the 'Top Scripts' window? How about >> individual attachments? I imagine the last object that would go over the >> threshold will be the one that's not allowed to rez, but that probably won't >> be the least efficiently scripted item the person is wearing. >> >> Ziggy >> >> Stickman wrote: >> >>> I don't know what the official name is, but it's either Parcel Limits, >>> Script Limits, or Memory Limits. >>> >>> It's been a while since I've heard any official word about it. Last I >>> did hear, LL was gathering statistics and didn't know exactly how they >>> were going to implement it, let alone what the limits would be. >>> >>> Has LL made any decisions, and would they be willing to share them? >>> More minds on the issue can spot any holes or problems that could >>> arise, and there's still some rumbling panic among the masses that >>> can't be confirmed or quelled since we don't know how it'll work. >>> >>> Many thanks, >>> >>> Stickman >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> >>> >>> >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From robertltux at gmail.com Tue Dec 15 17:15:10 2009 From: robertltux at gmail.com (Robert Martin) Date: Tue, 15 Dec 2009 20:15:10 -0500 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <4B283382.9050009@Gmail.com> References: <4B248D18.6040100@planetziggy.com> <4B283382.9050009@Gmail.com> Message-ID: On Tue, Dec 15, 2009 at 8:10 PM, Tigro Spottystripes wrote: > Btw, will unfit script just not run or will the objects they are in > actually become unrezzable making scripts unfixable even by the creators? > what should happen is that some sort of precheck is done and the object is not rezzed (or is rezzed with all scripts stopped) since some objects will be horribly broken by some scripts not running an example would be some anthro/Quad parts -- Robert L Martin From tigrospottystripes at gmail.com Tue Dec 15 17:16:53 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Tue, 15 Dec 2009 23:16:53 -0200 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <4B248D18.6040100@planetziggy.com> <4B283382.9050009@Gmail.com> Message-ID: <4B283505.5020709@Gmail.com> Not rezzing at all would be the worse solution possible (perhaps only less worse than automaticly deleting the items in the inventory) Robert Martin escreveu: > On Tue, Dec 15, 2009 at 8:10 PM, Tigro Spottystripes > wrote: > >> Btw, will unfit script just not run or will the objects they are in >> actually become unrezzable making scripts unfixable even by the creators? >> >> > what should happen is that some sort of precheck is done and the > object is not rezzed (or is rezzed with all scripts stopped) since > some objects will be horribly broken by some scripts not running an > example would be some anthro/Quad parts > From q at lindenlab.com Tue Dec 15 17:21:55 2009 From: q at lindenlab.com (Kent Quirk) Date: Tue, 15 Dec 2009 20:21:55 -0500 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <4B248D18.6040100@planetziggy.com> Message-ID: As Babbage's blog post said ( https://blogs.secondlife.com/community/technology/blog/2009/12/15/script-limits ): "We're planning to make script memory usage along with our proposed script limits visible to all Residents for an extended period before enforcing any limits. This will give us time to gather feedback on the proposed limits and identify any situations where we're going to be imposing unreasonable restrictions and give will give you time to compare your usage against the proposed limits, give us feedback and have plenty of time to prepare." You'll also have time to give us feedback on the enforcement mechanisms. Q On Dec 15, 2009, at 8:03 PM, Stickman wrote: > Ping. > > The comfort or early warning I expect is that we're going to get > better tools to see behind the scenes on scripts before the limits > actually show up. My fear is that it's going to be right when midterms > crop up and have a two week window to rewrite every script I've ever > written. > > Can any Lindens on this project provide any information, or point us > to a magical page on the wiki that explains this? Or, at the very > least, give us a rough timetable so we know about what time is > appropriate to begin our panicked search for information? > > Thanks much! > > Stickman > > On Sat, Dec 12, 2009 at 10:43 PM, Ziggy Puff > wrote: >> I was about to post a question on this as well - my wife heard >> about that >> blog post (it's spreading pretty quickly among content creators, I >> think) >> and so I took a look. I found some good info in 3 or 4 of Babbage >> Linden's >> office hour chat logs. More details on the exact algorithms would >> be very >> helpful. Some questions I had after going through the material I >> could find: >> >> * Is each script 'charged' 16K/64K, or just what it's using? Is the >> check >> made on rez / parcel change, or periodically? Maybe this is a >> meaningless >> question, but I thought Mono scripts could scale their memory >> footprint up >> and down, in which case a script could have a small footprint when >> it's >> rezzed. >> >> * Avatar / attachment pool vs. parcel pool - if an av's pool runs >> out, does >> an attachment try to take memory from the parcel pool? >> >> * The GUI support for reporting script memory usage - will it show >> the >> footprint of individual objects, like the 'Top Scripts' window? How >> about >> individual attachments? I imagine the last object that would go >> over the >> threshold will be the one that's not allowed to rez, but that >> probably won't >> be the least efficiently scripted item the person is wearing. >> >> Ziggy >> >> Stickman wrote: >>> >>> I don't know what the official name is, but it's either Parcel >>> Limits, >>> Script Limits, or Memory Limits. >>> >>> It's been a while since I've heard any official word about it. >>> Last I >>> did hear, LL was gathering statistics and didn't know exactly how >>> they >>> were going to implement it, let alone what the limits would be. >>> >>> Has LL made any decisions, and would they be willing to share them? >>> More minds on the issue can spot any holes or problems that could >>> arise, and there's still some rumbling panic among the masses that >>> can't be confirmed or quelled since we don't know how it'll work. >>> >>> Many thanks, >>> >>> Stickman >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> >>> >> >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From tillie at xp2.de Tue Dec 15 17:58:19 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Wed, 16 Dec 2009 02:58:19 +0100 Subject: [sldev] patch: timestamped snapshots Message-ID: <4B283EBB.8090702@xp2.de> Hello, just finished my first patch and attached it in jira. http://jira.secondlife.com/browse/VWR-12917 :-) Maybe someone can have a look. It's a quite small change. Tillie From stickman at gmail.com Tue Dec 15 20:27:49 2009 From: stickman at gmail.com (Stickman) Date: Tue, 15 Dec 2009 20:27:49 -0800 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <4B248D18.6040100@planetziggy.com> Message-ID: > As Babbage's blog post said ( > https://blogs.secondlife.com/community/technology/blog/2009/12/15/script-limits?): He replied off-list. :( That's so not fair. Thanks for pointing it out, Q! That calms most of my fears on the issue. Basically: "Can't talk yet, but we will soon, and we won't make changes without user input." I'll add panicking to my agenda for a later date, then. -Stickman From tigrospottystripes at gmail.com Tue Dec 15 21:18:01 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 16 Dec 2009 03:18:01 -0200 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <4B248D18.6040100@planetziggy.com> Message-ID: <4B286D89.6030904@Gmail.com> please refresh my memory, did things come out ok in the last few times LL delayed details and promised to listen to resis? Stickman escreveu: >> As Babbage's blog post said ( >> https://blogs.secondlife.com/community/technology/blog/2009/12/15/script-limits ): >> > > He replied off-list. :( That's so not fair. > > Thanks for pointing it out, Q! > > That calms most of my fears on the issue. Basically: "Can't talk yet, > but we will soon, and we won't make changes without user input." > > I'll add panicking to my agenda for a later date, then. > > -Stickman > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From stickman at gmail.com Tue Dec 15 21:30:12 2009 From: stickman at gmail.com (Stickman) Date: Tue, 15 Dec 2009 21:30:12 -0800 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <4B286D89.6030904@Gmail.com> References: <4B248D18.6040100@planetziggy.com> <4B286D89.6030904@Gmail.com> Message-ID: On Tue, Dec 15, 2009 at 9:18 PM, Tigro Spottystripes wrote: > please refresh my memory, did things come out ok in the last few times > LL delayed details and promised to listen to resis? I'm curious, actually. Maybe we can start a new thread and list every major project that's been done in the last few years, and rate how well we think it was executed, and if user input would/did/could have helped. Welp, back to studying for finals! Have fun! -Stickman From q at lindenlab.com Tue Dec 15 21:35:27 2009 From: q at lindenlab.com (Kent Quirk) Date: Wed, 16 Dec 2009 00:35:27 -0500 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <4B286D89.6030904@Gmail.com> References: <4B248D18.6040100@planetziggy.com> <4B286D89.6030904@Gmail.com> Message-ID: <68554ED6-F580-4FEC-88FC-98B9DA83BED7@lindenlab.com> First, sarcasm isn't the best way to get a positive response. Second, we do listen -- not only this time, but many times in the past. We hear a lot, including a fair amount of contradictory advice. We listen, and then we decide based on all the evidence we have, including factors like the long-term health of our technology and our business. I can guarantee that not everyone will like all of our decisions. If everyone agreed, they'd be easy decisions. In this particular case, we are attempting to place known limits in a place where we only before had unknown limits (it was not "unlimited" -- nothing is ever "unlimited"). And we're starting by giving you -- and ourselves -- the data before we take action. I think that is both fair and reasonable. Q On Dec 16, 2009, at 12:18 AM, Tigro Spottystripes wrote: > please refresh my memory, did things come out ok in the last few times > LL delayed details and promised to listen to resis? > > > Stickman escreveu: >>> As Babbage's blog post said ( >>> https://blogs.secondlife.com/community/technology/blog/2009/12/15/script-limits >>> ): >>> >> >> He replied off-list. :( That's so not fair. >> >> Thanks for pointing it out, Q! >> >> That calms most of my fears on the issue. Basically: "Can't talk yet, >> but we will soon, and we won't make changes without user input." >> >> I'll add panicking to my agenda for a later date, then. >> >> -Stickman >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > From tigrospottystripes at gmail.com Tue Dec 15 21:41:24 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 16 Dec 2009 03:41:24 -0200 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <68554ED6-F580-4FEC-88FC-98B9DA83BED7@lindenlab.com> References: <4B248D18.6040100@planetziggy.com> <4B286D89.6030904@Gmail.com> <68554ED6-F580-4FEC-88FC-98B9DA83BED7@lindenlab.com> Message-ID: <4B287304.50508@Gmail.com> It was an honest request, i wanted the facts to base my opinion instead of having my potentially flawed memories biasing my interpretation of how comforting "can't say much now, will talk with you later" actually should be for me Kent Quirk escreveu: > First, sarcasm isn't the best way to get a positive response. > > Second, we do listen -- not only this time, but many times in the > past. We hear a lot, including a fair amount of contradictory advice. > > We listen, and then we decide based on all the evidence we have, > including factors like the long-term health of our technology and our > business. I can guarantee that not everyone will like all of our > decisions. If everyone agreed, they'd be easy decisions. > > In this particular case, we are attempting to place known limits in a > place where we only before had unknown limits (it was not "unlimited" > -- nothing is ever "unlimited"). And we're starting by giving you -- > and ourselves -- the data before we take action. I think that is both > fair and reasonable. > > Q > > On Dec 16, 2009, at 12:18 AM, Tigro Spottystripes wrote: > >> please refresh my memory, did things come out ok in the last few times >> LL delayed details and promised to listen to resis? >> >> >> Stickman escreveu: >>>> As Babbage's blog post said ( >>>> https://blogs.secondlife.com/community/technology/blog/2009/12/15/script-limits ): >>>> >>>> >>> >>> He replied off-list. :( That's so not fair. >>> >>> Thanks for pointing it out, Q! >>> >>> That calms most of my fears on the issue. Basically: "Can't talk yet, >>> but we will soon, and we won't make changes without user input." >>> >>> I'll add panicking to my agenda for a later date, then. >>> >>> -Stickman >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> >> > > From imaze.rhiano at gmail.com Tue Dec 15 23:20:39 2009 From: imaze.rhiano at gmail.com (Imaze Rhiano) Date: Wed, 16 Dec 2009 09:20:39 +0200 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: Message-ID: <4B288A47.5000204@gmail.com> Stickman kirjoitti: > I don't know what the official name is, but it's either Parcel > Limits, Script Limits, or Memory Limits. > > It's been a while since I've heard any official word about it. Last I > did hear, LL was gathering statistics and didn't know exactly how > they were going to implement it, let alone what the limits would be. > > Has LL made any decisions, and would they be willing to share them? > More minds on the issue can spot any holes or problems that could > arise, and there's still some rumbling panic among the masses that > can't be confirmed or quelled since we don't know how it'll work. > > Many thanks, > > Stickman _______________________________________________ Policies and > (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev Please read the policies before > posting to keep unmoderated posting privileges > Babbie's office hours and logs are best source of REAL information currently. I am just writing good fictional story here for you. http://wiki.secondlife.com/wiki/User:Babbage_Linden Tonight's office hour is last for this year - Babbie is going to have holiday :( Current status: - Functionality that allows monitor memory usage is ready in server. - Currently what is missing is UI for client side.Should be done early 2010 - thought most skeptics in audience agrees that this is really going to happen 2011 - just before world ends in year 2012. - Parcel and avatar memory are going to be completely separated. If your avatar don't have enough memory for attachment that you are trying to rezz, then you will get error message and rezzing will fail - even if parcel have zillion bytes memory available. There is an exception here - in sandbox sims you can still rezz any object. (OH audience suggested that sandboxes would be renamed to "crashboxes" - Babbie didn't make any promises) - You can show your OWN attachment memory usage, how much different attachments are using memory and probably other statistics. This means that you can't look your girlfriend attachments and see is she really using that XCite thingie that you bought for her - or is she cheating you and actually using that other manufacturer's thingie what was bought by her secret lover that you are not supposed to know. - You can show your OWN PARCEL memory usage, how much different objects are using memory, other statistics and there is also going to be tools that help you to locate those scripts. You can't show avatar attachments memory usage in your parcel. - You can show your OWN REGION - even if you don't own parcel in there (estate managers), memory usage, how much different objects are using memory, other statistics and there is also going to be tools that help you to locate those scripts. You can't show avatar attachments memory usage in your region. - Parcel memory limitations are calculated from parcel's area. Initially things like double primitives doesn't effect to memory limitations. Babbie was hoping that someday region owners could effect to this - like create heavily scripted regions and lightly scripted regions. - There is going to be at least half year warning period where residents can see their memory usages, but limits are not yet enforced. - It is not technically feasible to do system that would separated "old" content from "new" content created after memory limit introduction - and would allow "old" content stil run without limits. - Mono scripts are going to use memory that they are using - might be much less than 16Kb - LSL classics scripts are always using 16Kb. According Babbie, there is at least one avatar that have 7612 scripts (using about 96Mb memory). And average user have 100 scripts. Highest script count what I have seen what was about 800 scripts - and it is pretty normal that non-techie person have 200-400 scripts. This kind awful statistics has been constant motivation about secondary discussion: "Why people need so many scripts and what we can do for it so that there is no need for so many scripts?". This discussion has lead several improvements that ARE COMING to scripts early 2010 - ... err... someday... PROBLEM: "There is too many scripts, I have GREAT IDEA! Let's limit script size to 16/64Kb! That would limit script usage, RIGHT?!" - or - "Marketing person: WE NEED TO RELEASE SL NOW! Skip idea about that dynamic script memory thingie whatever, we can't market such things anyway! Instead each script should have fixed amount of memory - DO IT NOW!" RESULT: Scripters will split scripts to multiple scripts so that they can script larger scripts. CAUSES: Multiple scripts will cause overhead because of communication mechanism and other thingies to get them work. Multiple scripts are actually using much more memory than single script would use. HOW-TO-FIX: Mono scripts are going to get function that allows them to allocate more memory for them self. PROBLEM: "Whining customer: OMG COPYBOT! You can't allow scripts to get primitives parameters that would make copying them too easy! LL: Don't worry, we allow scripts only get parameters same primitives where they reside. Bear hug?" RESULT: Scripters will copy their scripts to every primitive in object (for example hair resizers). CAUSES: Have you ever heard 255 primitive hair with 255 script resizer? I have .. I have several of those. HOW-TO-FIX: llGetLinkedPrimitiveParams PROBLEM: "Our servers can't handle load made by these functions if they are called repeately in loop and they also allow griefers to grief hundreds person in second. We need to add artificial delays to these functions." RESULT: Scripters will split scripts to multiple scripts so they can avoid delays and run scripts parallel. CAUSES: Multiple scripts....Like hair resizers. HOW-TO-FIX: llSetLinkedPrimitiveParamsNoDelay, maybe also other xxxNoDelay functions and different throttling method for server that allows it to control load. PROBLEM: "0MG! 1 can writ3 script! I am l33t n0w!" RESULT: Badly scripted things like chickens. I hate chickens. Unless they come with some good wine. CAUSES: Lag HOW-TO-FIX: C# and other languages are coming, LL have already working prototype. Should be easier for creators identify good from bad scripter.... Or maybe not... PROBLEM: "OMG! I have great idea about HUD! We will built radar thingie and then will add hug thingie to it! Great? GUYS?!" RESULT: Hundreds scripts are running in server that could be running client side only. CAUSES: Lag HOW-TO-FIX: Emerald viewer, client side radar, client side animations, client side scripting... someday Babbie would really want to hear more reasons why people are using hundreds scripts. So if you have more reasons - please send them for Babbie. So that his team can form strategy to overcome reasons behind it. Anyway... you can stop whining now. Script limits are coming. There are no other options. Maybe even before world ends. You should start thinking about those limits NOW! At least what you can do is to make your hairs and other objects copyable and allow customers to remove scripts from them when they don't scripts anymore. You don't need to make your object modifiable - you just need to add option to your scripts that removes scripts from primitives by calling "llRemoveInventory(llGetScriptName());". Some resizers have already this option. Just don't be moron and disable this option because you think that your customers are too stupid. ... everything around this really leads to one real question: "If a tree falls in the forest and no one is around to hear it does it make a sound?" Or why there is script running when no one is around to see results? But that is architectural question that mortals can't comprehend. From tigrospottystripes at gmail.com Wed Dec 16 00:09:36 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 16 Dec 2009 06:09:36 -0200 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <4B288A47.5000204@gmail.com> References: <4B288A47.5000204@gmail.com> Message-ID: <4B2895C0.2000801@Gmail.com> Hm, nice reading, most of it was indeed comforting to some extent, thanx for bringing this to my inbox :) Btw, is there some sort of communication medium for a group of people that doesn't require people to communicate in real time nor actively check to see if anyone has said anything new, nor require any sort of client program that requires relatively expensive hardware to run? I mean, could Linden office hours work (except for things that need live demonstrations in-world) as separated mailing lists that run all week long perhaps? Imaze Rhiano escreveu: > Stickman kirjoitti: > >> I don't know what the official name is, but it's either Parcel >> Limits, Script Limits, or Memory Limits. >> >> It's been a while since I've heard any official word about it. Last I >> did hear, LL was gathering statistics and didn't know exactly how >> they were going to implement it, let alone what the limits would be. >> >> Has LL made any decisions, and would they be willing to share them? >> More minds on the issue can spot any holes or problems that could >> arise, and there's still some rumbling panic among the masses that >> can't be confirmed or quelled since we don't know how it'll work. >> >> Many thanks, >> >> Stickman _______________________________________________ Policies and >> (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev Please read the policies before >> posting to keep unmoderated posting privileges >> >> > > Babbie's office hours and logs are best source of REAL information > currently. I am just writing good fictional > story here for you. > > http://wiki.secondlife.com/wiki/User:Babbage_Linden > Tonight's office hour is last for this year - Babbie is going to have > holiday :( > > Current status: > - Functionality that allows monitor memory usage is ready in server. > - Currently what is missing is UI for client side.Should be done early > 2010 - thought most skeptics in audience > agrees that this is really going to happen 2011 - just before world > ends in year 2012. > - Parcel and avatar memory are going to be completely separated. If your > avatar don't have enough memory > for attachment that you are trying to rezz, then you will get error > message and rezzing will fail - even if parcel > have zillion bytes memory available. There is an exception here - in > sandbox sims you can still rezz any object. (OH > audience suggested that sandboxes would be renamed to "crashboxes" - > Babbie didn't make any promises) > - You can show your OWN attachment memory usage, how much different > attachments are using memory and > probably other statistics. This means that you can't look your > girlfriend attachments and see is she really using > that XCite thingie that you bought for her - or is she cheating you > and actually using that other manufacturer's thingie > what was bought by her secret lover that you are not supposed to know. > - You can show your OWN PARCEL memory usage, how much different objects > are using memory, other statistics > and there is also going to be tools that help you to locate those > scripts. You can't show avatar attachments memory > usage in your parcel. > - You can show your OWN REGION - even if you don't own parcel in there > (estate managers), memory usage, > how much different objects are using memory, other statistics and > there is also going to be tools that help you to locate > those scripts. You can't show avatar attachments memory usage in your > region. > - Parcel memory limitations are calculated from parcel's area. Initially > things like double primitives doesn't effect to memory > limitations. Babbie was hoping that someday region owners could > effect to this - like create heavily scripted regions and > lightly scripted regions. > - There is going to be at least half year warning period where residents > can see their memory usages, but limits are not > yet enforced. > - It is not technically feasible to do system that would separated "old" > content from "new" content created after memory > limit introduction - and would allow "old" content stil run without > limits. > - Mono scripts are going to use memory that they are using - might be > much less than 16Kb - LSL classics scripts are > always using 16Kb. > > According Babbie, there is at least one avatar that have 7612 scripts > (using about 96Mb memory). And average user have > 100 scripts. Highest script count what I have seen what was about 800 > scripts - and it is pretty normal that non-techie > person have 200-400 scripts. This kind awful statistics has been > constant motivation about secondary discussion: > "Why people need so many scripts and what we can do for it so that there > is no need for so many scripts?". This discussion > has lead several improvements that ARE COMING to scripts early 2010 - > ... err... someday... > > PROBLEM: "There is too many scripts, I have GREAT IDEA! Let's limit > script size to 16/64Kb! That would limit script usage, > RIGHT?!" > - or - > "Marketing person: WE NEED TO RELEASE SL NOW! Skip idea about that > dynamic script memory thingie > whatever, we can't market such things anyway! Instead each script should > have fixed amount of memory - DO IT NOW!" > RESULT: Scripters will split scripts to multiple scripts so that they > can script larger scripts. > CAUSES: Multiple scripts will cause overhead because of communication > mechanism and other thingies to get them work. Multiple > scripts are actually using much more memory than single script would use. > HOW-TO-FIX: Mono scripts are going to get function that allows them to > allocate more memory for them self. > > PROBLEM: "Whining customer: OMG COPYBOT! You can't allow scripts to get > primitives parameters that would make copying > them too easy! LL: Don't worry, we allow scripts only get parameters > same primitives where they reside. Bear hug?" > RESULT: Scripters will copy their scripts to every primitive in object > (for example hair resizers). > CAUSES: Have you ever heard 255 primitive hair with 255 script resizer? > I have .. I have several of those. > HOW-TO-FIX: llGetLinkedPrimitiveParams > > PROBLEM: "Our servers can't handle load made by these functions if they > are called repeately in loop and they also allow > griefers to grief hundreds person in second. We need to add artificial > delays to these functions." > RESULT: Scripters will split scripts to multiple scripts so they can > avoid delays and run scripts parallel. > CAUSES: Multiple scripts....Like hair resizers. > HOW-TO-FIX: llSetLinkedPrimitiveParamsNoDelay, maybe also other > xxxNoDelay functions and different throttling method > for server that allows it to control load. > > PROBLEM: "0MG! 1 can writ3 script! I am l33t n0w!" > RESULT: Badly scripted things like chickens. I hate chickens. Unless > they come with some good wine. > CAUSES: Lag > HOW-TO-FIX: C# and other languages are coming, LL have already working > prototype. Should be easier for creators identify > good from bad scripter.... Or maybe not... > > PROBLEM: "OMG! I have great idea about HUD! We will built radar thingie > and then will add hug thingie to it! Great? GUYS?!" > RESULT: Hundreds scripts are running in server that could be running > client side only. > CAUSES: Lag > HOW-TO-FIX: Emerald viewer, client side radar, client side animations, > client side scripting... someday > > Babbie would really want to hear more reasons why people are using > hundreds scripts. So if you have more reasons - please send them for > Babbie. So that his team can form strategy to overcome reasons behind it. > > Anyway... you can stop whining now. Script limits are coming. There are > no other options. Maybe even before world ends. You should start > thinking about those limits NOW! At least what you can do is to make > your hairs and other objects copyable and allow customers to remove > scripts from them when they don't scripts anymore. You don't need to > make your object modifiable - you just need to add option to your > scripts that removes scripts from primitives by calling > "llRemoveInventory(llGetScriptName());". Some resizers have already this > option. > Just don't be moron and disable this option because you think that your > customers are too stupid. > > ... everything around this really leads to one real question: "If a > tree falls in the forest and no one is around to hear it does it make a > sound?" > Or why there is script running when no one is around to see results? But > that is architectural question that mortals can't comprehend. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From aleric.inglewood at gmail.com Wed Dec 16 03:35:25 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Wed, 16 Dec 2009 12:35:25 +0100 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <4B248D18.6040100@planetziggy.com> Message-ID: <1e01733d0912160335u2c2e3781rfb56eacd0d7b2c20@mail.gmail.com> On Wed, Dec 16, 2009 at 2:03 AM, Stickman wrote: > The comfort or early warning I expect is that we're going to get > better tools to see behind the scenes on scripts before the limits > actually show up. My fear is that it's going to be right when midterms > crop up and have a two week window to rewrite every script I've ever > written. > > Can any Lindens on this project provide any information, or point us > to a magical page on the wiki that explains this? Or, at the very > least, give us a rough timetable so we know about what time is > appropriate to begin our panicked search for information? To save him from typing this again, here is some info about this topic from IRC. I editted it (removed other conversation): [23:53] Aleric: in general script run time isn't an issue. Scripts do run fast, and we dedicate a fairly fixed amount of time each simulator frame to running scripts. [23:54] tehKellz: If you are going to set limits on scripts, you should not do so in any way that normal scripters are affected imho. Only those that really try to abuse it. You cannot set limits per-script in order to control the server load; the only way to do that is using load balancing (NO limits for a script if there is enough resources) [23:55] Sure, I can cover some points here: [23:55] *) Correct. When we start enforcing limits most won't notice, only those extreme cases. [23:56] (everyone just always assumes they will be effected) [23:56] *) We won't be limiting CPU (for now at least) just memory [23:56] *) The limits aren't "per script" but "per region" and "per avatar". A region will get probably ~300MB for scripts. give or take. [23:57] *) The problem being solved isn't performance because of script run time. It is because when memory bloats too much it pushes sims into swap which kills the performance not only of that region but every other region on the host. [...] [00:00] In all cases, even if the memory limits we set are 1gig of mem for scripts per region, the truth is that we *do* have a tragedy of the commons problem and we need the limits. From babbage at lindenlab.com Wed Dec 16 04:44:05 2009 From: babbage at lindenlab.com (Babbage Linden) Date: Wed, 16 Dec 2009 12:44:05 +0000 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <4B288A47.5000204@gmail.com> References: <4B288A47.5000204@gmail.com> Message-ID: <1aff09e40912160444k25f42431i92ee5cf624631f40@mail.gmail.com> Very amusing and mostly correct summary of the situation (and about 6 months of office hour logs), thanks Imaze. 2009/12/16 Imaze Rhiano > ... everything around this really leads to one real question: "If a > tree falls in the forest and no one is around to hear it does it make a > sound?" > Or why there is script running when no one is around to see results? But > that is architectural question that mortals can't comprehend. > This is partially because Philip and Andrew's initial vision for SL was as an autonomous world that people would occasionally visit. Virtual creatures would run around eating and breeding and these ecosystems should run whether or not people were there to watch. Interestingly with over 1000 running scripts for every logged in avatar, that is still largely the case: you can look at Second Life as a world of scripts that humans occasionally visit. Cheers, Babbie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091216/4e7c1de6/attachment.htm From aleric.inglewood at gmail.com Wed Dec 16 04:45:28 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Wed, 16 Dec 2009 13:45:28 +0100 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <4B248D18.6040100@planetziggy.com> Message-ID: <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> On Wed, Dec 16, 2009 at 2:21 AM, Kent Quirk wrote: > "We're planning to make script memory usage along with our proposed > script limits visible to all Residents for an extended period before > enforcing any limits. This is doomed to fail, and well for the following reason: The whole implementation is wrong: you have implemented FIXED limits per parcel and avatar, while they should have been dynamic. No matter what user feedback will be received, you're not going to change this implementation; the user input will only be used to decide on these fixed limits (if they can be set lower I imagine, cause after the Ex-street disaster I don't believe that user input will ever be used to say "hey, maybe we should set the limits higher and add some more memory to the servers"). I understand where they "limit per avatar" and "limit per parcel" comes from: In case of abuse, in case of actual being out of memory, SOMEONE has to be responsible and THAT person has to be punished. That means you need to be able to see who is using too much memory which means per avatar, and per parcel (since then the parcel owner is responsible). However, in the case of homesteads we have four homesteads on one server... So, rather than punishing parcel owners you should punish the region owner... Now here is the problem: By not having dynamic limits, the limits need to be *MUCH* lower than they could have been! Assume the following variables: Max server memory: S Region memory used: R1, R2, ... Parcel memory used: P11, P12, .. P21, P22, .. Avatar memory used: A1, A2, ... If all these are FIXED limits, then no doubt you will have for homesteads: S = R1 + R2 + R3 + R4 R1 = P11 + P12 + P13 + ... + A_pool where A_pool is the avatar pool, the amount of memory reserved for avatars. If you do not want the NORMAL user to suffer (theKellz's said on IRC that only the *extreme* cases would be affected and normal users wouldn't feel a thing), then EACH of those hard limits must be set pretty high (at the high end of the normal curve of normal usage). For the sake of simplicity, lets assume that such a high limit is four times higher than the average usage (which imho is on the low side), then that means that this system will enforce an average usage of only 25% of the maximum avaiable server memory, which is FOUR times lower than what we have now. Since a lot of servers ALREADY run into the max S currently, I predict that no matter what you try with this system, LOTS AND LOTS of regions will MAJORLY suffer. Example 1: Someone owns four homesteads, all running on the same server. He doesn't really need that much prims for his dancing, he needs memory and cpu time. He also liked a few parks and sea around his dance island, so he got himself four homesteads, put almost nothing in three of them and used the memory of the server entirely to run the heavily visited disco on the fourth. This is legit usage of resources: he owns all regions on the whole server, so he owns the server. Once you put the limits into effect, he will suddenly only get 1/4 for the disco region of what he had before MINUS the parcel pool, for the scripts of the visitors that visit. In effect, almost all visitors will suddenly run into script problems. Example 2: Someone owns a full region. He does the same as above: he devided the region into several parcels: one parcel is HUGE, but empty. Other small parcels were created because that way he could set different music urls: one for each dance floor! Once you put the limits into effect, the empty parcels suddenly reserve a HUGE ammount of resources "just in case" the "owner" will need it. No ammount of user feedback can change the limits such that those parcels can still donate their resources to the dancefloor parcels... and the whole region breaks down. Example 3: As many land tycoons do... full sims are divided into many parcels, and each parcel is rented out to individuals. Those individuals are usually close friends (or they wouldn't have rented on that sim (or even voted in there). So, they often hang out in one spot. Sometimes in the house of one of them, more often on the common beach. And then they have parties. Before, it didn't matter where they went: they used maybe 30% of the server resources at all times and things worked just fine. Then Linden Lab comes with their limits... suddenly S = R1 + R2 + R3 + R4 and R1 = P11 + P12 + P13 + ... + A_pool and NO amount of user feedback is going to change that, because if you'd change that '=' to '<' then abuse would still be possible and swapping could still happen, it simply isn't possible to allow '<'. However, that means that the resources of each parcel is suddenly a fraction... with their 8 parcels and residents, they suddenly can only have parties with only 1/8 of the previous resources... and 30% being way larger... that was the end of their parties. How to stop this major disaster? ========================== In order to stop this from becoming major disaster number X, the whole limiting system HAS to be changed: There should be NO limits on memory usage whatsoever UNTIL the server resources are almost used up. If S == 1.0, and R1 == 0.8, then that is ok as long as R2 == 0.0, R3 == 0.1 and R4 == 0.05. Ok, if THEN R2 suddenly wants to use 0.2, then R1 is the one that has to be limited, BUT NOT BEFORE. In other words: the limits must be dynamic and ONLY be set once there is need to set them. I didn't give an example where memory from the avatar pool is needed for parcels or the other way around, but that is exactly the same. What you should do is make a LLMemoryResource class and derive everything that uses memory from that class. This class would enforce memory usage limits. All those instances together, their ACTUAL memory usage, added up should be less than the memory on the WHOLE server (if you REALLY want not support Example 1, so be it; in which case it should add up to the whole region). Lets say the limit of the server is S, then the limit for EVERY object is set to S. When a new LLMemoryResource is created, or an exiting one wants to increase it's memory usage, you check that the total sum is still less than S first. Once it becomes larger than S (to sum of everything) THEN you run an algorithm that sets actual limits. Whatever that algorithm is, the estate manager must be able to configure it! Ie, he must be able to say: that parcel gets 90% of the resources; or the avatar pool gets 50% of the resources (or 10%). This would then result in some scripts not being able to run anymore. They should print "Out of Memory" in the script debug console and stop running (and then free their memory usage). If one tries to set such a script to running again, it would check if that is possible due to it's limit and either start or give an error message and refuse to run. From secret.argent at gmail.com Wed Dec 16 05:43:47 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 16 Dec 2009 07:43:47 -0600 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <4B283505.5020709@Gmail.com> References: <4B248D18.6040100@planetziggy.com> <4B283382.9050009@Gmail.com> <4B283505.5020709@Gmail.com> Message-ID: <50BBBB1E-F2FE-4EE3-AE25-B9A9C7EF9E16@gmail.com> The object won't rez if the parcel you're in already has too many scripts in it. You would still be able to rez the object in a sandbox. It is unlikely that you would have a problem unless you had hundreds of scripts. From tillie at xp2.de Wed Dec 16 05:49:22 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Wed, 16 Dec 2009 14:49:22 +0100 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <50BBBB1E-F2FE-4EE3-AE25-B9A9C7EF9E16@gmail.com> References: <4B248D18.6040100@planetziggy.com> <4B283382.9050009@Gmail.com> <4B283505.5020709@Gmail.com> <50BBBB1E-F2FE-4EE3-AE25-B9A9C7EF9E16@gmail.com> Message-ID: <4B28E562.2070803@xp2.de> On 16.12.2009 14:43, Argent Stonecutter wrote: > The object won't rez if the parcel you're in already has too many > scripts in it. > > You would still be able to rez the object in a sandbox. > > It is unlikely that you would have a problem unless you had hundreds > of scripts. Scripted hair, scripted shoes ... fashion shows will be a mess. ;-) Tillie From imaze.rhiano at gmail.com Wed Dec 16 05:54:20 2009 From: imaze.rhiano at gmail.com (Imaze Rhiano) Date: Wed, 16 Dec 2009 15:54:20 +0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> References: <4B248D18.6040100@planetziggy.com> <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> Message-ID: <4B28E68C.8000503@gmail.com> Aleric Inglewood kirjoitti: > On Wed, Dec 16, 2009 at 2:21 AM, Kent Quirk wrote: > > >> "We're planning to make script memory usage along with our proposed >> script limits visible to all Residents for an extended period before >> enforcing any limits. >> > > This is doomed to fail, and well for the following reason: > > The whole implementation is wrong: you have implemented FIXED > limits per parcel and avatar, while they should have been > dynamic. No matter what user feedback will be received, you're > not going to change this implementation; the user input will > only be used to decide on these fixed limits (if they can > be set lower I imagine, cause after the Ex-street disaster > I don't believe that user input will ever be used to say > "hey, maybe we should set the limits higher and add some > more memory to the servers"). > ---- CUT & CUT --- > There is some problems what I can see in dynamic limits: 1) If avatar rezzes attachments in region that have lot's of available memory and then teleports to region that doesn't have enough memory for avatar's attachments then either teleportation fails ("Not enough memory in target region error message") or alternatively randomly some of scripted attachments don't rezz in target region? 2) If avatar rezzes attachments in region that have lot's of available memory and then logouts. What happens for her attachments when she log's back and region doesn't have enough memory for attachments anymore? Is avatar moved to some staging region or are attachment randomly removed until avatar fits to memory limits? 3) Let's imagine that you are organizing some kind event that requires you to rezz some scripted objects after participants are arrived. You test that object rezzes properly before participants arrive - everything seems to be okay. Then event starts - and there is coming much more participants than you were able to dream of. When time comes, you try to rezz scripted objects, but region is reporting back "Not enough memory". 4) You decide upgrade your parcel larger. You rent/buy empty parcel from another estate. After rezzing your house you start rezzing furnitures. Sofa to living room rezzes fine - but when you try to rezz bed to bedroom - you get error "Not enough memory". You are wondering what just happened? Everything was rezzing fine to parcel that was much more smaller. After talking with estate owner: It turns out that your neighbors are using most of regions memory already. Actually - tenant who rented first parcel in region is using 80% of regions memory to her chicken farm. Estate owner doesn't want to remove those chickens because she is biggest tier payer, she is also having lot's of fun with her in her bed and those chickens are from very valuable prize winning pedigree. 5) If I have understood correctly you can't choose homesteads that are running in same server. Also you homestead might occasionally moved to another server. Because of server maintenance or some geek in LL server farm just want to play with his god powers. I agree that there should be ways to set PARCEL memory limitations, before limitations are going to enforced. For example estate manager doesn't want to waste region's PARCEL memory to empty street parcels - she wants to allocate all available PARCEL memory to building parcels where her tenants are living and have their shops, houses and clubs. AVATAR memory limits should be fixed - so that there is no problems with border crossing, logging in or teleporting. However, estate manager should be able to set maximal amount avatars in region - thus allocating more/less PARCEL memory for scripts in parcels. But these shouldn't be dynamic - that cause nondeterministic behavior. From jessesa at gmail.com Wed Dec 16 05:56:15 2009 From: jessesa at gmail.com (Jesse Barnett) Date: Wed, 16 Dec 2009 08:56:15 -0500 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <4B28E562.2070803@xp2.de> References: <4B248D18.6040100@planetziggy.com> <4B283382.9050009@Gmail.com> <4B283505.5020709@Gmail.com> <50BBBB1E-F2FE-4EE3-AE25-B9A9C7EF9E16@gmail.com> <4B28E562.2070803@xp2.de> Message-ID: On Wed, Dec 16, 2009 at 8:49 AM, Tillie Ariantho wrote: > > Scripted hair, scripted shoes ... fashion shows will be a mess. ;-) > > Tillie > Which is kind of the point and one of the main reasons this is having to be implemented. Jesse Barnett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091216/1a37a8ea/attachment-0001.htm From carlo at alinoe.com Wed Dec 16 07:19:29 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 16 Dec 2009 16:19:29 +0100 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <4B248D18.6040100@planetziggy.com> <4B283382.9050009@Gmail.com> <4B283505.5020709@Gmail.com> <50BBBB1E-F2FE-4EE3-AE25-B9A9C7EF9E16@gmail.com> <4B28E562.2070803@xp2.de> Message-ID: <20091216151929.GA11070@alinoe.com> On Wed, Dec 16, 2009 at 08:56:15AM -0500, Jesse Barnett wrote: > Scripted hair, scripted shoes ... fashion shows will be a mess. ;-) > Tillie > > Which is kind of the point and one of the main reasons this is having to be > implemented. > > Jesse Barnett Huh? I thought the reason was to stop regions bogging down due to swapping. Now the main reason is to cripple fashion shows? The very fact that those fashion shows worked before means that there is something majorly wrong with an implementation that make that NORMAL use of scripts suddenly a worse experience. If the server HAS the resources to do something before, then it should not suddenly become impossible. -- Carlo Wood From jessesa at gmail.com Wed Dec 16 07:36:26 2009 From: jessesa at gmail.com (Jesse Barnett) Date: Wed, 16 Dec 2009 10:36:26 -0500 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <20091216151929.GA11070@alinoe.com> References: <4B248D18.6040100@planetziggy.com> <4B283382.9050009@Gmail.com> <4B283505.5020709@Gmail.com> <50BBBB1E-F2FE-4EE3-AE25-B9A9C7EF9E16@gmail.com> <4B28E562.2070803@xp2.de> <20091216151929.GA11070@alinoe.com> Message-ID: Normal use of scripts are not affected. Hair and shoes with several hundred scripts per avatar is what I am specifically referring to and should not be considered "normal use". Go back and look at Babbage's meeting minutes to see some of the outrageous script abuse going on. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091216/22b39314/attachment.htm From brickrte at hughes.net Wed Dec 16 07:47:14 2009 From: brickrte at hughes.net (Laurence Brickner) Date: Wed, 16 Dec 2009 10:47:14 -0500 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <4B248D18.6040100@planetziggy.com><4B283382.9050009@Gmail.com><4B283505.5020709@Gmail.com><50BBBB1E-F2FE-4EE3-AE25-B9A9C7EF9E16@gmail.com><4B28E562.2070803@xp2.de><20091216151929.GA11070@alinoe.com> Message-ID: Something about "Where Angels Fear to Tread" comes to mind but. As a community, we have become very tolerant of poor performance. I have often heard the sarcasm "Lag is always with us." I wondered why. The assertion that things are working right now isn't true. "Things" fall apart often and that should be unacceptable. Truth is we often find ourselves on the precipice. So I see this as an attempt to do something before "Things" turn brown. What can be wrong with that? The most likely outcome will be that we will become accustomed to a better grade of system performance. Let's not fight them. Let's help. Shorahmin/Larry _____ From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Jesse Barnett Sent: Wednesday, December 16, 2009 10:36 To: Carlo Wood Cc: sldev at lists.secondlife.com Subject: Re: [sldev] Script/Parcel/Memory Limits Normal use of scripts are not affected. Hair and shoes with several hundred scripts per avatar is what I am specifically referring to and should not be considered "normal use". Go back and look at Babbage's meeting minutes to see some of the outrageous script abuse going on. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091216/3520e940/attachment.htm From aleric.inglewood at gmail.com Wed Dec 16 07:59:14 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Wed, 16 Dec 2009 16:59:14 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B28E68C.8000503@gmail.com> References: <4B248D18.6040100@planetziggy.com> <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> <4B28E68C.8000503@gmail.com> Message-ID: <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> Those are not problems with *dynamic* limits. Dynamic here means that the limits are not enforced until REALLY necessary (and then accordingly to how the estate manager thinks is reasonable to devide the resources). Fixed limits means that each group (each parcel and each avatar only gets the memory that would be available if everything else and all others would be using their MAXIMUM resources. That will result in a limit that is a factor 4 to 8 LOWER than it can be on average, a limit that will be MUCH lower than what you can have now most of the time. So, let me rephrase your "problems" On Wed, Dec 16, 2009 at 03:54:20PM +0200, Imaze Rhiano wrote: > There is some problems what I can see in dynamic limits: > 1) If avatar rezzes attachments in region that have lot's of available > memory and then teleports to region that doesn't have enough memory for > avatar's attachments then either teleportation fails ("Not enough memory > in target region error message") or alternatively randomly some of > scripted attachments don't rezz in target region? With fixed limits: The avatar rezzes attachments in region that have lot's of available memory, but it fails nevertheless while before everything worked just fine in this region! What is worse? > 2) If avatar rezzes attachments in region that have lot's of available > memory and then logouts. What happens for her attachments when she log's > back and region doesn't have enough memory for attachments anymore? Is > avatar moved to some staging region or are attachment randomly removed > until avatar fits to memory limits? With fixed limits: The avatar rezzes attachments in region that have lot's of available memory, but it fails nevertheless while before everything worked just fine in this region! What is worse? > 3) Let's imagine that you are organizing some kind event that requires > you to rezz some scripted objects after participants are arrived. You > test that object rezzes properly before participants arrive - everything > seems to be okay. Then event starts - and there is coming much more > participants than you were able to dream of. When time comes, you try to > rezz scripted objects, but region is reporting back "Not enough memory". That wouldn't happen if those objects use their fair share. If they do NOT use their fair share, it also wouldn't work with fixed limits. What you can do in this case is test in advance how much memory your objects need in that parcel and then have the estate manager allocate that amount. In that case you have the right for those resources and what would happen if you rez the objects is that avatar scripts (and then starting with those that run most scripts) will have their scripts stopped. If a lot of the guests have 'scripted hair' then those will the first to go, and since those scripts should really have been deleted in the first place, nobody would really notice it anyway. In the event that people DO notice it, then well - then you ARE overloading the region with your event and should ask people to turn off scripts or leave, because the region IS overloaded. > 4) You decide upgrade your parcel larger. You rent/buy empty parcel from > another estate. After rezzing your house you start rezzing furnitures. > Sofa to living room rezzes fine - but when you try to rezz bed to > bedroom - you get error "Not enough memory". You are wondering what just > happened? Everything was rezzing fine to parcel that was much more > smaller. After talking with estate owner: It turns out that your > neighbors are using most of regions memory already. Actually - tenant > who rented first parcel in region is using 80% of regions memory to her > chicken farm. Estate owner doesn't want to remove those chickens because > she is biggest tier payer, she is also having lot's of fun with her in > her bed and those chickens are from very valuable prize winning pedigree. Like I said, once the region runs out of memory, THOSE parcels / avatars will be limited that use most memory of course. So, this would never happen to you. What would happen is that your neighbors chicken farm would stop working after you rez your bed. The neighbor would go to the estate manager and he'd tell her that she was lucky that the estate was empty before, but that from now on she'll have to settle with her fair share of memory. Note that she would have known in advance that this would happen, because the tools will be (should be) there to tell her that she's using too much resources (it just wouldn't be enforced as long as the resources are available). Compare this to how I run my sim: I have 500 prims "reserve", they are not allocated to parcels. Every parcel can rez prims till the region is FULL. There are no limits. People keep track of what they MAY rez (what they pay for), if they go over it for a longer period of time they are asked to delete stuff (they never do in practise by the way). However, it OFTEN happens that someone rezzes something temporarily ie - "look at this"... or whatever, we have bike contest (each bike is 100 prims!). Because of the reserve of 500, we never get "region is full" when we want to play... just as long as you clean up afterwards. This situation iS WAYYYYY better than when I'd have set a FIXED limit and had given everyone a slice of those 500 and enforced that ... ie, everyone got 100 "reserve" prims and could never rez more JUST IN CASE all the neighbors wanted to rez their 100 too. Come on! But that is exactly what LL is going to do :( > 5) If I have understood correctly you can't choose homesteads that are > running in same server. Also you homestead might occasionally moved to > another server. Because of server maintenance or some geek in LL server > farm just want to play with his god powers. Then that is something that needs fixing too. If someone wants to hire a server and run four homesteads on it then that should be possible, of course. Hell, you're paying for it no? > I agree that there should be ways to set PARCEL memory limitations, > before limitations are going to enforced. For example estate manager > doesn't want to waste region's PARCEL memory to empty street parcels - > she wants to allocate all available PARCEL memory to building parcels > where her tenants are living and have their shops, houses and clubs. Yes, but this is orthogonal to NOT enforcing limits before they are really needed (the server starts swapping). Although, if the estate manager COULD change the memory allocation, then that would be pseudo dynamic: in case of disasters (party has to be cancelled), he could CHANGE the limits so that the bloody server wouldn't start to tell people that it's out of memory while it's NOT out of memory. > AVATAR memory limits should be fixed - so that there is no problems with > border crossing, logging in or teleporting. However, estate manager > should be able to set maximal amount avatars in region - thus allocating > more/less PARCEL memory for scripts in parcels. But these shouldn't be > dynamic - that cause nondeterministic behavior. If you think that setting a fixed amount of memory PER avatar is going to help then think again: LL is a business... memory costs money. Why would they want to never USE the memory that they put into the servers? What you want is to reserve on EVERY server the amount of memory needed to serve the MAXIMUM number of avatars (configurable or not) each using their MAXIMUM amount of memory! So you can always teleport... right. Lets see... Suppose that currently the average avatar uses x Megabytes of memory. Lets also assume that if you use 10 times as much as the average, it still isn't ABUSE, because their are very good reasons in some cases to do that. So, the limit is set to 10x per avatar. Furthermore, MOST regions are empty - but they COULD theoretically host 20 to 100 avatars (haha, ok 20 -- officially it's 100 I think). So, there you are walking around with your partner in an otherwise empty sim using x MB each, and instead of having almost unlimited amount of resources, the region tries to keep 180 * x MB in reserve -- THAT IS NINETY TIMES THE AMOUNT OF MEMORY YOU ARE USING! -- JUST in case suddenly 18 others loaded with the maximum number of scripts simultaneously wanted to popup next to you! What does that mean? It means that this region effectively has MUCH MUCH less memory available, and you will MUCH MUCH sooner seen those "limits" take effect then you'd ever before. I'll take lagging due to swapping ANYTIME (I'll just tp away) over having to deal with "out of memory" non-stop in almost every region that used to work fine before! From carlo at alinoe.com Wed Dec 16 07:59:10 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 16 Dec 2009 16:59:10 +0100 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <4B248D18.6040100@planetziggy.com> <4B283382.9050009@Gmail.com> <4B283505.5020709@Gmail.com> <50BBBB1E-F2FE-4EE3-AE25-B9A9C7EF9E16@gmail.com> <4B28E562.2070803@xp2.de> <20091216151929.GA11070@alinoe.com> Message-ID: <20091216155910.GB11070@alinoe.com> On Wed, Dec 16, 2009 at 10:36:26AM -0500, Jesse Barnett wrote: > Normal use of scripts are not affected. Hair and shoes with several hundred > scripts per avatar is what I am specifically referring to and should not be > considered "normal use". Go back and look at Babbage's meeting minutes to see > some of the outrageous script abuse going on. Normal use WILL be affected, because before you see no limits until the server actually runs out of memory. Now you will be limited long long long before the server actually runs out of memory, because the server has to keep like 90% of memory "in reserve" to serve the worst case of a full load on all parcels happening and suddenly the maximum number of avatars joining. The mantra "Normal use of scripts are not affected" is a lie, and it's easy to deduce why that must be the case. The way that normal use of scripts would not be affected is when every server will have 20 times more memory than they NEED on AVERAGE. Last time I checked, LL was a business. -- Carlo Wood From latifer at streamgrid.net Wed Dec 16 08:28:52 2009 From: latifer at streamgrid.net (Latif Khalifa) Date: Wed, 16 Dec 2009 17:28:52 +0100 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <1aff09e40912160444k25f42431i92ee5cf624631f40@mail.gmail.com> References: <4B288A47.5000204@gmail.com> <1aff09e40912160444k25f42431i92ee5cf624631f40@mail.gmail.com> Message-ID: <5ebce2ec0912160828t52a9a8f7o34751c132605b4d8@mail.gmail.com> On Wed, Dec 16, 2009 at 1:44 PM, Babbage Linden wrote: > Very amusing and mostly correct summary of the situation (and about 6 months > of office hour logs), thanks Imaze. One worrying thing about the office hour transcript is that the memory limits are going to be enforced *before* you could set reserved memory. I'm just guessing here, but let say that you allow 300mb for script memory per full sim, which would make a sim hit a limit at about 4000 mono scripts irrespective of how much memory they actually use. If this is true, it's problematic on several levels. A lot of existing sims are going to have their content broken, and it will give incentive to people to recompile to LSO since that reserves 4 times less memory than mono. -- L From tigrospottystripes at gmail.com Wed Dec 16 08:56:41 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 16 Dec 2009 14:56:41 -0200 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <5ebce2ec0912160828t52a9a8f7o34751c132605b4d8@mail.gmail.com> References: <4B288A47.5000204@gmail.com> <1aff09e40912160444k25f42431i92ee5cf624631f40@mail.gmail.com> <5ebce2ec0912160828t52a9a8f7o34751c132605b4d8@mail.gmail.com> Message-ID: <4B291149.5010104@Gmail.com> If normal usage is not gonna be affected negatively, if most users aren't gonna be affected negatively, then how can this problem be so big to justify such measures at all? From tayra.dagostino at gmail.com Wed Dec 16 12:08:33 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Wed, 16 Dec 2009 21:08:33 +0100 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <4B291149.5010104@Gmail.com> References: <4B288A47.5000204@gmail.com> <1aff09e40912160444k25f42431i92ee5cf624631f40@mail.gmail.com> <5ebce2ec0912160828t52a9a8f7o34751c132605b4d8@mail.gmail.com> <4B291149.5010104@Gmail.com> Message-ID: <20091216210833.a5471be4.tayra.dagostino@gmail.com> On Wed, 16 Dec 2009 14:56:41 -0200 Tigro Spottystripes wrote: > If normal usage is not gonna be affected negatively, if most users > aren't gonna be affected negatively, then how can this problem be so > big to justify such measures at all? why, as you can read just above in this thread, a large number of script waste simulator memory and is a source or wide lag. Take mind a 200prims jewell or a 150prims hair with resizer script or a 100prims shoes all scripted with a resizer script each prim..... some good scripter put a "delete" function to let customer to "clean" the object after fitting the avatar (and some ppl don't know what happen if not cleaned), but i prefer a safe way fool-proof like prioritization of script (example: object rezzed inworld prio=1, hud prio=2, script of attachment prio=3, where 1 is executed first and 3 in spare time) so hud, and at least attachment, in this way the billion script attachment will be reduced in spare time of simulator, without involve scripted object or hud (maybe a limit per agent of hud script time may be a transitional way to educated middle-low skilled scripters and scripted items users). This appear as a killing solution, but is the safier for an overall lifeability of the grid From sldev at free.fr Wed Dec 16 13:26:34 2009 From: sldev at free.fr (Henri Beauchamp) Date: Wed, 16 Dec 2009 22:26:34 +0100 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <68554ED6-F580-4FEC-88FC-98B9DA83BED7@lindenlab.com> References: <4B248D18.6040100@planetziggy.com> <4B286D89.6030904@Gmail.com> <68554ED6-F580-4FEC-88FC-98B9DA83BED7@lindenlab.com> Message-ID: <20091216222634.53656499.sldev@free.fr> On Wed, 16 Dec 2009 00:35:27 -0500, Kent Quirk wrote: > First, sarcasm isn't the best way to get a positive response. > > Second, we do listen -- not only this time, but many times in the > past. We hear a lot, including a fair amount of contradictory advice. > .../... Not wanting to start a flame war or add more sarcasms, but I'm afraid Linben Lab did not take very wise neither profitable (for both LL and the residents) decisions in the past, thus why old-timers can only fear more hasted and illogical/harmful decisions... Examples ? Here are only a few: - The new (well, now over two years old) decentralized groups system (which used to work just fine as a centralized architecture before the v1.17 viewer and correpsonding server were issued), which has proven totally unreliable and unscalable (see the JIRA about "more than 25 groups", and all the complaints about group chat and group notices failures). Note that this was an unilateral decision from LL and that no discussion whatsoever occured prior to this change, and that LL ignored all complaints since... - The search system, which again used to work just fine and provided both relevant and, most important, *fair* results before the web-based search engine was forced down our throats, here again, without any discussion whatsoever and is now universally recognized as a distaster among all merchants and customers alike (by the day the official viewer lost its "All(old)" search tab, my incomes as a merchant droped by a whooping 50% !). Here again, LL did nothing to date to correct the problems. - The dramatic changes in sim pricing and prim support limits (and the consequences with closed and reduced number of sims). - The Adult segregation fiasco (again a drop for "Adult" merchants incomes: 30% for me so far, thank you LL !). There has been a "discussion" but it was pretty moot since LL had already decided they would create an "Adult" continent and did not change a single thing in their plan despite the vehement protests and numerous interesting and viable counter-proposals. The true solution was to make a PG continent, but of course, since LL already decided and worked on the adult continent even before they opened the "discussion" about the coming changes, it was too late... The result ?... A user base which at best stagnates and actually goes down (In now over two years, the "logged in last 60 days" figure on the login screen went from a little over 1 500 000 in November 2007 (all times record) to under 1 400 000 nowadays), and merchants who struggle to no avail and will soon leave SL "en masse" for greener pastures (the next disaster to come for merchants is the new XStreet policy about freebies which, curiously, will mostly impact non- freebies ! LL's greed is simply infinite... and will kill their own business !). Well, I guess you got the hint... Now, let's go back to the topic: scripts limits... My dear Q, since you say you do listen, and since I'm ready to believe you, here is an advice: Do not do things the wrong way around. Before imposing *any* limit on scripts, provide scripters with better functions. My own scripted products are high quality with a lot of features, and they do use a lot of scripts. Not so much because they need mega-bytes of memory to run (I started programming back in the 70s, on 6502 and 6800 processors, with 1Kb of ROM and 256 bytes of RAM, so I think I do know what optimization means), but simply because there are no other way than to use slave scripts for child prims (and often, in average you need one script per prim in the final object): with the proper functions, I could easily reduce by 70% the number of scripts, in turn lowering the load imposed on sim and asset servers when an avatar with scripted attachments enters a new region (70% less scripts to serialize in the departing sim, send to the asset server, then fetch back from the asset server and finally deserialize in the arrival sim)... Many LSL functions could (should !) be added to avoid having to use secondary scripts, such as llLinkParticleSystem(), llSetLinkText(), llGetLinkDesc(), llSetLinkDesc(), llSetLinkName(), etc (in short, it should be possible for a script in the root primitive to retrieve and change all the parameters of any of its child primitives), and also fix the broken functions (see https://jira.secondlife.com/browse/SVC-93 for example)... These new/debugged functions should be made available to scripters long (at least 6 months) before any limit is imposed to them, so to let them enough time to adapt their scripts and for merchants to update their products. Unless LL's new mission is to break existing contents and bring features below what is already possible in OpenSim, which would definitely hasten the "en masse" migration (for your info, the ONLY reason why I did not myself completely migrate to OpenSim grids is precisely because scripts are so much more reliable on SL)... Regards, Henri Beauchamp. From gigstaggart at gmail.com Wed Dec 16 13:31:11 2009 From: gigstaggart at gmail.com (Gigs) Date: Wed, 16 Dec 2009 16:31:11 -0500 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <4B291149.5010104@Gmail.com> References: <4B288A47.5000204@gmail.com> <1aff09e40912160444k25f42431i92ee5cf624631f40@mail.gmail.com> <5ebce2ec0912160828t52a9a8f7o34751c132605b4d8@mail.gmail.com> <4B291149.5010104@Gmail.com> Message-ID: <4B29519F.80704@gmail.com> Tigro Spottystripes wrote: > If normal usage is not gonna be affected negatively, if most users > aren't gonna be affected negatively, then how can this problem be so big > to justify such measures at all? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > Because, just like with any service that is not metered in a proper manner, 1% ruin it for the other 99%. -Jason From twisted_laws at hotmail.com Wed Dec 16 18:38:40 2009 From: twisted_laws at hotmail.com (Twisted Laws) Date: Wed, 16 Dec 2009 21:38:40 -0500 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <1aff09e40912160444k25f42431i92ee5cf624631f40@mail.gmail.com> References: , <4B288A47.5000204@gmail.com>, <1aff09e40912160444k25f42431i92ee5cf624631f40@mail.gmail.com> Message-ID: Add an optional command for scripts of llLoadWhenAvatarIsWithin(meters) and a lot of us would use that to control waterfalls, fountains, pets and other things :) Of course, you need an CHANGED_ACTIVED and CHANGED_DEACTIVATED events to go with it. Twisted From: babbage at lindenlab.com ..... Interestingly with over 1000 running scripts for every logged in avatar, that is still largely the case: you can look at Second Life as a world of scripts that humans occasionally visit. ... Babbie _________________________________________________________________ Hotmail: Trusted email with Microsoft?s powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141664/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091216/aaf159fc/attachment.htm From dahliatrimble at gmail.com Wed Dec 16 19:31:18 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed, 16 Dec 2009 19:31:18 -0800 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <4B288A47.5000204@gmail.com> <1aff09e40912160444k25f42431i92ee5cf624631f40@mail.gmail.com> Message-ID: I'm curious why people deem it necessary to distribute resizing systems with a slave script in each prim. Most of the resizing scripts I've seen only allow you to adjust the size and position of prims, this is at most 6 floating point numbers per prim (x, y, z offsets, x, y, z scale). These values are only needed as they are relative to the size and position of the prim in the original design. Thus, a resizing system could be designed which has a master script with memory storage for these values for each child prim, and self-deleting child prim scripts which send the original values to the master script one time (*before* leaving the designer's workshop) and then delete themselves. The deletion function could also be enforced by having the child prim scripts send their data and self delete when a CHANGED_OWNER event occurs. The master script can then modify these values and modify the child prims using the existing llSetLinkPrimitiveParams() function. If such a resizing script were commonly used, I suspect it may significantly reduce sim memory usage. Unfortunately, the designers of the resizing scripts in use today chose not to use such a method. On Wed, Dec 16, 2009 at 6:38 PM, Twisted Laws wrote: > Add an optional command for scripts of llLoadWhenAvatarIsWithin(meters) > and a lot of us would use that to control waterfalls, fountains, pets and > other things :) Of course, you > need an CHANGED_ACTIVED and CHANGED_DEACTIVATED events to go with it. > > Twisted > > From: babbage at lindenlab.com > ..... > Interestingly with over 1000 running scripts for every logged in avatar, > that is still largely the case: you can look at Second Life as a world of > scripts that humans occasionally visit. > ... > Babbie > > ------------------------------ > Hotmail: Trusted email with Microsoft?s powerful SPAM protection. Sign up > now. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091216/67e67923/attachment.htm From kelly at lindenlab.com Wed Dec 16 19:45:15 2009 From: kelly at lindenlab.com (Kelly Linden) Date: Wed, 16 Dec 2009 19:45:15 -0800 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <4B288A47.5000204@gmail.com> <1aff09e40912160444k25f42431i92ee5cf624631f40@mail.gmail.com> Message-ID: On Wed, Dec 16, 2009 at 7:31 PM, Dahlia Trimble wrote: > The master script can then modify these values and modify the child prims > using the existing llSetLinkPrimitiveParams() function. > At 0.2 seconds of script sleep per call you are currently at 1 second for every 5 prims. 100 prims is 20 seconds and 200 is 40 seconds of pure sleep, outside any time the script actually uses. While this isn't actually very horrible for something that you would in theory only do rarely why push this on your customers when it is simple to have a script in each prim and get near-instant change? By adding a version of llSetLinkPrimitiveParams that does not have a delay you will be able to get the same 'near instant' change with a single script, and that is our goal. Additionally, llGetLinkPrimitiveParams doesn't yet exist and will remove the need for even the initial round of self-deleting scripts in each prim. - Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091216/e9ebfebe/attachment.htm From ziggy at planetziggy.com Wed Dec 16 20:07:23 2009 From: ziggy at planetziggy.com (Ziggy Puff) Date: Wed, 16 Dec 2009 20:07:23 -0800 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <4B288A47.5000204@gmail.com> <1aff09e40912160444k25f42431i92ee5cf624631f40@mail.gmail.com> Message-ID: <4B29AE7B.60300@planetziggy.com> I wrote some scripts for a friend which let her sell a single object with multiple color options on subsets of prims, instead of creating a different object for each color permutation. I set it up with a pool of slave scripts in the root prim, and she tested it on a few customer with different numbers of slave scripts. Every single customer with a small slave pool complained when it took more than a few seconds to switch the textures. She was happy when I told her that pretty soon all of that can be reduced to one script. Kelly Linden wrote: > > > On Wed, Dec 16, 2009 at 7:31 PM, Dahlia Trimble > > wrote: > > The master script can then modify these values and modify the > child prims using the existing llSetLinkPrimitiveParams() function. > > > At 0.2 seconds of script sleep per call you are currently at 1 second > for every 5 prims. 100 prims is 20 seconds and 200 is 40 seconds of > pure sleep, outside any time the script actually uses. While this > isn't actually very horrible for something that you would in theory > only do rarely why push this on your customers when it is simple to > have a script in each prim and get near-instant change? > > By adding a version of llSetLinkPrimitiveParams that does not have a > delay you will be able to get the same 'near instant' change with a > single script, and that is our goal. > > Additionally, llGetLinkPrimitiveParams doesn't yet exist and will > remove the need for even the initial round of self-deleting scripts in > each prim. > > - Kelly > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From dahliatrimble at gmail.com Wed Dec 16 20:18:18 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed, 16 Dec 2009 20:18:18 -0800 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <4B288A47.5000204@gmail.com> <1aff09e40912160444k25f42431i92ee5cf624631f40@mail.gmail.com> Message-ID: Sure the delay is a factor, however there are also rather large delays when sending link messages through large link sets. I don't know how successful you would be at removing the delay, prim animation aficionados such as myself would quickly discover it and make nifty animated thingies which would radically increase network traffic with object update packets when all our friends gathered around the new animated thingie to watch. Perhaps an alternate rule may work instead: apply the 0.2 second rule to each item in the linkset that the script could address rather than the entire script? (or something to that effect). Of course prim animators use many scripts to get around the 0.2 second delay now, so yeah, maybe just getting rid of it is a good idea :) On Wed, Dec 16, 2009 at 7:45 PM, Kelly Linden wrote: > > > On Wed, Dec 16, 2009 at 7:31 PM, Dahlia Trimble wrote: > >> The master script can then modify these values and modify the child prims >> using the existing llSetLinkPrimitiveParams() function. >> > > At 0.2 seconds of script sleep per call you are currently at 1 second for > every 5 prims. 100 prims is 20 seconds and 200 is 40 seconds of pure sleep, > outside any time the script actually uses. While this isn't actually very > horrible for something that you would in theory only do rarely why push this > on your customers when it is simple to have a script in each prim and get > near-instant change? > > By adding a version of llSetLinkPrimitiveParams that does not have a delay > you will be able to get the same 'near instant' change with a single script, > and that is our goal. > > Additionally, llGetLinkPrimitiveParams doesn't yet exist and will remove > the need for even the initial round of self-deleting scripts in each prim. > > - Kelly > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091216/12fc7c1a/attachment.htm From danteferret at gmail.com Wed Dec 16 23:54:37 2009 From: danteferret at gmail.com (Peter Leonard/Dante) Date: Thu, 17 Dec 2009 02:54:37 -0500 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> References: <4B248D18.6040100@planetziggy.com> <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> <4B28E68C.8000503@gmail.com> <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> Message-ID: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> Just look at region Object Bonus. This is an example where a dynamic system is already in use and works. Object bonus allows EMs and the EO to allocate empty buffer parcels in order to give other parcels more prims. With object bonus on there is the posibility to rez more prims then the sim allows and have the sim return random objects, yet it works, and LL chose to give the estate staff the choice. Why can we not do this with script limits as well? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091217/23e8f169/attachment.htm From danteferret at gmail.com Wed Dec 16 23:58:55 2009 From: danteferret at gmail.com (Peter Leonard/Dante) Date: Thu, 17 Dec 2009 02:58:55 -0500 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> References: <4B248D18.6040100@planetziggy.com> <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> <4B28E68C.8000503@gmail.com> <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> Message-ID: <4d211a610912162358u3dca726bx3261c9a6235c30a6@mail.gmail.com> In fact. I think this is an example where Script Limits will break content. Imagine all the regions out there that use Object Bonus to pile all there stuff into a few small parcels. These regions will be destroyed even though it is legitimate use! On Thu, Dec 17, 2009 at 2:54 AM, Peter Leonard/Dante wrote: > Just look at region Object Bonus. This is an example where a dynamic system > is already in use and works. > > Object bonus allows EMs and the EO to allocate empty buffer parcels in > order to give other parcels more prims. > > With object bonus on there is the posibility to rez more prims then the sim > allows and have the sim return random objects, yet it works, and LL chose to > give the estate staff the choice. Why can we not do this with script limits > as well? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091217/0193b8cd/attachment.htm From chaosstar at gmail.com Thu Dec 17 00:01:24 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 17 Dec 2009 09:01:24 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> References: <4B248D18.6040100@planetziggy.com> <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> <4B28E68C.8000503@gmail.com> <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> Message-ID: <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> Just to make a few things clear about memory limits and how they work: * 300mb will be divided between land and avatars in each sim. Fixed size per avatar, and per square meter. * Each avatar will have their own memory pool for attachments * Each parcel will have its own memory pool depending on its size (it's basically memory per square meter) * The script memory limit per script will be removed for mono scripts * Scripts will be able to request memory with a new function. if the memory in the pool is free, it gets reserved for that script. * The first 6+ months, the limits will only be displayed, not enforced * People will get script memory/time of scripts they wear and own in the sim * Land owners will be able to get the info about all scripts on their parcel * Estate owners will get the info about all scripts in the sim * There will be an effort to add new LSL functions to make scripting with less scripts easier. The definite batch for the first round of additions: llGetPrimitiveParams/llGetLinkPrimitiveParams, llSetPrimitiveParamsNoDelay/llSetLinkPrimitiveParamsNoDelay. Also there will be a new PRIM_TEXT rule for those functions to set the hovertext of linked prims remotely. So, no, there is no danger of not being able to log in with your attachments if you were able to wear them in the first place. No, one parcel can't take away another parcel's memory. No, the limits will only be displayed but not enforced so people can adapt during the first six months. And If only 20% of those 300mb should be spread onto avatars per sim, 40 avatars would get 1.5mb of script memory each. This is already a ridiculously high amount for attachments, and the only people affected by this will be the ones who are unable to script efficiently. --Chalice Yao From secret.argent at gmail.com Thu Dec 17 03:17:28 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 17 Dec 2009 05:17:28 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> References: <4B248D18.6040100@planetziggy.com> <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> <4B28E68C.8000503@gmail.com> <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> Message-ID: <4EA8F01F-D069-4B5F-BD86-B7B2408B26F7@gmail.com> On 2009-12-17, at 02:01, Ambrosia wrote: > Just to make a few things clear about memory limits and how they work: > > * 300mb will be divided between land and avatars in each sim. Fixed > size per avatar, and per square meter. This is the bit that I think is an issue. It should permit overcommitment for small parcels, by some scaled percentage, so long as the sim as a whole is below (say) 75% of the limit. From qieniangao at gmail.com Thu Dec 17 04:17:03 2009 From: qieniangao at gmail.com (Qie Niangao) Date: Thu, 17 Dec 2009 07:17:03 -0500 Subject: [sldev] Script/Parcel/Memory Limits Message-ID: <9788aeb10912170417w263e8ddo27a7e26e9d20c246@mail.gmail.com> I sense an opportunity for some non-trivial mathematics to be applied to optimally setting these limits. The obviously, horribly wrong approach would be to set a ceiling for all script memory use in a region and apportion that to parcel and avatar allotments such that no over-allocation could ever occur. This would create much lower limits than required for sub-ceiling operations almost all the time. Rather, the total amount of script memory that the limits permit may be two or five or ten times that ceiling and still only encounter the ceiling once every millenium or century or decade--all depending on the distribution of transient demand for the capacity being limited. So a Poisson or Erlang or some such distribution is relevant here. What's interesting is that there are (at least) two identifiable distributions: scripts in avatar attachments, and in parcel-resident objects. The former is much, much more transient, of course. It all feels a bit like engineering fibre capacity to optimally handle predicted demand for different telecom applications. Ignoring that new scripting functions may systematically change these demand distributions, this seems an interesting problem for somebody with the right background (not me!). Even if solving the optimization problem is judged overkill, I wanted to at least prevent that "obviously, horribly wrong approach." From lear.cale at gmail.com Thu Dec 17 06:00:07 2009 From: lear.cale at gmail.com (Lear Cale) Date: Thu, 17 Dec 2009 09:00:07 -0500 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> References: <4B248D18.6040100@planetziggy.com> <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> <4B28E68C.8000503@gmail.com> <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> Message-ID: On Thu, Dec 17, 2009 at 3:01 AM, Ambrosia wrote: > Just to make a few things clear about memory limits and how they work: > > * 300mb will be divided between land and avatars in each sim. Fixed > size per avatar, and per square meter. > * Each avatar will have their own memory pool for attachments > * Each parcel will have its own memory pool depending on its size > (it's basically memory per square meter) > * The script memory limit per script will be removed for mono scripts > * Scripts will be able to request memory with a new function. if the > memory in the pool is free, it gets reserved for that script. > I heard that this was now off the table. I also heard that all scripts (whether mono or LSL) will be counted as taking 64K. Does anyone know the facts? Thanks Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091217/f283ec75/attachment.htm From stickman at gmail.com Thu Dec 17 06:25:17 2009 From: stickman at gmail.com (Stickman) Date: Thu, 17 Dec 2009 06:25:17 -0800 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4B248D18.6040100@planetziggy.com> <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> <4B28E68C.8000503@gmail.com> <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> Message-ID: > I heard that this was now off the table.? I also heard that all scripts > (whether mono or LSL) will be counted as > taking 64K.? Does anyone know the facts? Babbage's office hours on the 16th said they're thinking of imposing a penalty for using LSO scripts, such as giving them a memory multiplier for accounting. But as of that last meeting, they haven't decided for sure yet. The goal of such a choice would be to encourage people to move to Mono, so they could eventually stop supporting two VMs. As mentioned elsewhere, you'll be able to specify how much memory you want, like 4kb or a meg, so at least the 16k LSO footprint won't be claimable as a reason to use it. As for everything else -- it's ideas on the table. There will be adequate time for us to dispute what will and won't work, and what's the best way to do it, after they release the tools for us to see what's actually going on so we can make informed decisions. I think all the major ideas on how it could be arranged have been spoken for, and I'm not sure which one LL is preferring at this point. Since they said they'll be looking for user input after the tools are out, I'm pretty sure everything LL says is ideas and plans, but not paved walkways. I'm just looking forward to my llSetLinkPrimitiveParamsFast(). Soooooo delicious nom nom nom. Stickman From chaosstar at gmail.com Thu Dec 17 06:30:02 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 17 Dec 2009 15:30:02 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> <4B28E68C.8000503@gmail.com> <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> Message-ID: <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> The idea of this was mentioned already in an office hour from earlier this year. 64-128k was the mentioned amount there. As for the other items..Babbage is approachable, I don't think they are off the table. What I would personally suggest is to simply directly tie the memory limit multiplier to the prim multiplier, but to keep the total memory limit the same..just like the total prim limit of all parcels together in the sim stay the same for the owner of the parcels. On Thu, Dec 17, 2009 at 15:25, Stickman wrote: >> I heard that this was now off the table.? I also heard that all scripts >> (whether mono or LSL) will be counted as >> taking 64K.? Does anyone know the facts? > > Babbage's office hours on the 16th said they're thinking of imposing a > penalty for using LSO scripts, such as giving them a memory multiplier > for accounting. From chaosstar at gmail.com Thu Dec 17 06:31:19 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 17 Dec 2009 15:31:19 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> References: <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> <4B28E68C.8000503@gmail.com> <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> Message-ID: <9bb32d430912170631h392aeffauf962559cfffc2135@mail.gmail.com> P.S. no, this increased memory count was supposed to only apply to LSL scripts, as they want to ultimately fade them out. Mono scripts will have their actual memory usage counted when it comes to the limits On Thu, Dec 17, 2009 at 15:30, Ambrosia wrote: > The idea of this was mentioned already in an office hour from earlier > this year. 64-128k > was the mentioned amount there. From tigrospottystripes at gmail.com Thu Dec 17 06:37:46 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 17 Dec 2009 12:37:46 -0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> References: <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> <4B28E68C.8000503@gmail.com> <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> Message-ID: <4B2A423A.40902@Gmail.com> But the limits should only be enforced when necessary, if there is a bunch of scripts in a 4x4 parcel and nothing else int he rest of the sim those scripts can use up all the sim script memory, if an avatar comes in, then the avaiablememory is divided between the parcel and the avatar, things like that Ambrosia escreveu: > The idea of this was mentioned already in an office hour from earlier > this year. 64-128k > was the mentioned amount there. > > As for the other items..Babbage is approachable, I don't think they > are off the table. > What I would personally suggest is to simply directly tie the memory > limit multiplier > to the prim multiplier, but to keep the total memory limit the > same..just like the total > prim limit of all parcels together in the sim stay the same for the > owner of the parcels. > > On Thu, Dec 17, 2009 at 15:25, Stickman wrote: > >>> I heard that this was now off the table. I also heard that all scripts >>> (whether mono or LSL) will be counted as >>> taking 64K. Does anyone know the facts? >>> >> Babbage's office hours on the 16th said they're thinking of imposing a >> penalty for using LSO scripts, such as giving them a memory multiplier >> for accounting. >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From tateru.nino at gmail.com Thu Dec 17 06:37:51 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri, 18 Dec 2009 01:37:51 +1100 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <9788aeb10912170417w263e8ddo27a7e26e9d20c246@mail.gmail.com> References: <9788aeb10912170417w263e8ddo27a7e26e9d20c246@mail.gmail.com> Message-ID: <4B2A423F.2090007@gmail.com> Not that I think this mailing list is the best place to go over all this, but I'll make one observation: The more dynamic it is, and the less trivial the math involved, the harder it is going to be for Joan User to figure out if her scripted stuff is going to work properly or not, or determine the circumstances under which it will or won't. I'd trade some versatility for a system that is deterministic and easy to understand and predict. On 17/12/2009 11:17 PM, Qie Niangao wrote: > I sense an opportunity for some non-trivial mathematics to be applied > to optimally setting these limits. > > The obviously, horribly wrong approach would be to set a ceiling for > all script memory use in a region and apportion that to parcel and > avatar allotments such that no over-allocation could ever occur. This > would create much lower limits than required for sub-ceiling > operations almost all the time. > > Rather, the total amount of script memory that the limits permit may > be two or five or ten times that ceiling and still only encounter the > ceiling once every millenium or century or decade--all depending on > the distribution of transient demand for the capacity being limited. > So a Poisson or Erlang or some such distribution is relevant here. > > What's interesting is that there are (at least) two identifiable > distributions: scripts in avatar attachments, and in parcel-resident > objects. The former is much, much more transient, of course. It all > feels a bit like engineering fibre capacity to optimally handle > predicted demand for different telecom applications. > > Ignoring that new scripting functions may systematically change these > demand distributions, this seems an interesting problem for somebody > with the right background (not me!). > > Even if solving the optimization problem is judged overkill, I wanted > to at least prevent that "obviously, horribly wrong approach." > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -- Tateru Nino http://dwellonit.taterunino.net/ From tillie at xp2.de Thu Dec 17 06:45:35 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Thu, 17 Dec 2009 15:45:35 +0100 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <4B2A423F.2090007@gmail.com> References: <9788aeb10912170417w263e8ddo27a7e26e9d20c246@mail.gmail.com> <4B2A423F.2090007@gmail.com> Message-ID: <4B2A440F.5040607@xp2.de> On 17.12.2009 15:37, Tateru Nino wrote: > The more dynamic it is, and the less trivial the math involved, the > harder it is going to be for Joan User to figure out if her scripted > stuff is going to work properly or not, or determine the circumstances > under which it will or won't. I'd trade some versatility for a system > that is deterministic and easy to understand and predict. Yah, and whatever you do, don't make it the way that all my customers shout at me "my HUD doesnt work anymore". I'll send them all to you, LL. Tillie From chaosstar at gmail.com Thu Dec 17 06:49:39 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 17 Dec 2009 15:49:39 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2A423A.40902@Gmail.com> References: <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> <4B28E68C.8000503@gmail.com> <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> Message-ID: <9bb32d430912170649l3165191jb00924397ae8245d@mail.gmail.com> And the script instantly crashes because suddenly it holds more data than it can when the avatar enters the sim? The alternative would be for the script to keep the memory it uses..but that would defeat the purpose of script limits, as now the sim would use up more memory than the 300mb it is supposed to use as max. That's the main issue why, no, there needs to be a defined, fixed number per square meter and avatar, that scripts can rely on being fixed and usable, no matter what else is going on in the sim's parcels or avatars. On Thu, Dec 17, 2009 at 15:37, Tigro Spottystripes wrote: > But the limits should only be enforced when necessary, if there is a > bunch of scripts in a 4x4 parcel and nothing else int he rest of the sim > those scripts can use up all the sim script memory, if an avatar comes > in, then the avaiablememory is divided between the parcel and the > avatar, things like that From tigrospottystripes at gmail.com Thu Dec 17 07:10:59 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 17 Dec 2009 13:10:59 -0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <9bb32d430912170649l3165191jb00924397ae8245d@mail.gmail.com> References: <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> <4B28E68C.8000503@gmail.com> <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <9bb32d430912170649l3165191jb00924397ae8245d@mail.gmail.com> Message-ID: <4B2A4A03.5090203@Gmail.com> There should be a way for scripts to check how much memory is avaiable int he pool for the sim, and for the parcel, and also how much memory the script will be limited to under a worse case scenario, scripts that can't be allowed to crash would check if they can still perform in worse case scenario and inform the owner if not. Would work kinda like how it is when one person owns mroe than one parcel in the sim, they can redistribute the prim count, witht he difference of it not being restricted to same owner. Scripts that are using more than it's quota for the worse case scenario are beyond the safety limits, beyond whatis recomended, they can crash and stuff, kinda like an overclocked CPU. Ambrosia escreveu: > And the script instantly crashes because suddenly it holds more data > than it can when the avatar enters the sim? The alternative would be > for the script to keep the memory it uses..but that would defeat the > purpose of script limits, as now the sim would use up more memory than > the 300mb it is supposed to use as max. > > That's the main issue why, no, there needs to be a defined, fixed > number per square meter and avatar, that scripts can rely on being > fixed and usable, no matter what else is going on in the sim's parcels > or avatars. > > On Thu, Dec 17, 2009 at 15:37, Tigro Spottystripes > wrote: > >> But the limits should only be enforced when necessary, if there is a >> bunch of scripts in a 4x4 parcel and nothing else int he rest of the sim >> those scripts can use up all the sim script memory, if an avatar comes >> in, then the avaiablememory is divided between the parcel and the >> avatar, things like that >> > > From chaosstar at gmail.com Thu Dec 17 07:17:34 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 17 Dec 2009 16:17:34 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2A4A03.5090203@Gmail.com> References: <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <9bb32d430912170649l3165191jb00924397ae8245d@mail.gmail.com> <4B2A4A03.5090203@Gmail.com> Message-ID: <9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com> But in your example, the script uses the max of the sim til the avatar comes in. The script will crash, as the avatar takes his own share of memory, and the script suddenly has less than it actually uses (not what it -could- use but doesn't). Scripts -will- be able to check available memory, that much has been stated, and they reserve additional memory they need with another function, but that available memory should not depend on factors of what's going on outside the parcel or on other avatars aside of the own. Quite frankly, the only thing that makes sense for scripters and content creators are hard numbers they can work with. Fixed memory amounts. Every 512sqm parcel should always (normally) support X mb max. Every avatar should normally support Y mb max. A solid api to build scripts upon. Available memory depends on the scripts already attached to the -same- avatar or on the -same- parcel, but a parcel's or avatar's memory should -not- be dependant in any way on external factors like other avatars or parcels. It makes things unreliable, unpredictable. On Thu, Dec 17, 2009 at 16:10, Tigro Spottystripes wrote: > There should be a way for scripts to check how much memory is avaiable > int he pool for the sim, and for the parcel, and also how much memory > the script will be limited to under a worse case scenario, From danteferret at gmail.com Thu Dec 17 07:32:57 2009 From: danteferret at gmail.com (Peter Leonard/Dante) Date: Thu, 17 Dec 2009 10:32:57 -0500 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <9bb32d430912170649l3165191jb00924397ae8245d@mail.gmail.com> <4B2A4A03.5090203@Gmail.com> <9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com> Message-ID: <4d211a610912170732w6fc877e0r82a7b17ddb78b815@mail.gmail.com> It cannot be fixed per square meter. There are hundreds of sims that fill most of their land with nothing, trees and such to make it pretty. And use parcel object bonus to stick most of there content into just a small parcel in the sim. If script limits are to be implimented as they are currently designed, then the parcel object bonus feature must be removed. And this will ruin a large percentage of private sim owners. The amount of money LL will lose if that many people drop out is just crazy. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091217/d3647090/attachment-0001.htm From chaosstar at gmail.com Thu Dec 17 07:39:23 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 17 Dec 2009 16:39:23 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4d211a610912170732w6fc877e0r82a7b17ddb78b815@mail.gmail.com> References: <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <9bb32d430912170649l3165191jb00924397ae8245d@mail.gmail.com> <4B2A4A03.5090203@Gmail.com> <9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com> <4d211a610912170732w6fc877e0r82a7b17ddb78b815@mail.gmail.com> Message-ID: <9bb32d430912170739i57c153f0x627f006b175fa4c4@mail.gmail.com> Or, as I mentioned, the parcel object bonus has an influence on a script memory bonus, that would work similiar the parcel bonus does. Dependant on total land mass person X owns in the sim. The parcel can hold more objects/Memory than it normally could, but it can't go above the total objects/Memory the parcels by the person in the sim put together would allow. On Thu, Dec 17, 2009 at 16:32, Peter Leonard/Dante wrote: > It cannot be fixed per square meter. There are hundreds of sims that fill > most of their land with nothing, trees and such to make it pretty. And use > parcel object bonus to stick most of there content into just a small parcel > in the sim. > > > If script limits are to be implimented as they are currently designed, then > the parcel object bonus feature must be removed. And this will ruin a large > percentage of private sim owners. The amount of money LL will lose if that > many people drop out is just crazy. > From tigrospottystripes at gmail.com Thu Dec 17 07:47:54 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 17 Dec 2009 13:47:54 -0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com> References: <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <9bb32d430912170649l3165191jb00924397ae8245d@mail.gmail.com> <4B2A4A03.5090203@Gmail.com> <9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com> Message-ID: <4B2A52AA.7020002@Gmail.com> If the owner expects the sim to never have more than like at most 10 people in it at any given moment, use up the memory that is left after 10 use up all their quota, no crashing unless more than 10 people get in the sim at the same time Ambrosia escreveu: > But in your example, the script uses the max of the sim til the avatar > comes in. The script will crash, as the avatar takes his own share of > memory, and the script suddenly has less than it actually uses (not > what it -could- use but doesn't). > > Scripts -will- be able to check available memory, that much has been > stated, and they reserve additional memory they need with another > function, but that available memory should not depend on factors of > what's going on outside the parcel or on other avatars aside of the > own. > > Quite frankly, the only thing that makes sense for scripters and > content creators are hard numbers they can work with. Fixed memory > amounts. Every 512sqm parcel should always (normally) support X mb > max. Every avatar should normally support Y mb max. A solid api to > build scripts upon. Available memory depends on the scripts already > attached to the -same- avatar or on the -same- parcel, but a parcel's > or avatar's memory should -not- be dependant in any way on external > factors like other avatars or parcels. It makes things unreliable, > unpredictable. > > On Thu, Dec 17, 2009 at 16:10, Tigro Spottystripes > wrote: > >> There should be a way for scripts to check how much memory is avaiable >> int he pool for the sim, and for the parcel, and also how much memory >> the script will be limited to under a worse case scenario, >> > > From kelly at lindenlab.com Thu Dec 17 08:58:28 2009 From: kelly at lindenlab.com (Kelly Linden) Date: Thu, 17 Dec 2009 08:58:28 -0800 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <4B2A423F.2090007@gmail.com> References: <9788aeb10912170417w263e8ddo27a7e26e9d20c246@mail.gmail.com> <4B2A423F.2090007@gmail.com> Message-ID: On Thu, Dec 17, 2009 at 6:37 AM, Tateru Nino wrote: > Not that I think this mailing list is the best place to go over all > this, but I'll make one observation: > > The more dynamic it is, and the less trivial the math involved, the > harder it is going to be for Joan User to figure out if her scripted > stuff is going to work properly or not, or determine the circumstances > under which it will or won't. I'd trade some versatility for a system > that is deterministic and easy to understand and predict. > > This is definitely one of our top goals. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091217/0f0c8cc4/attachment.htm From kelly at lindenlab.com Thu Dec 17 09:12:56 2009 From: kelly at lindenlab.com (Kelly Linden) Date: Thu, 17 Dec 2009 09:12:56 -0800 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> References: <4B248D18.6040100@planetziggy.com> <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> <4B28E68C.8000503@gmail.com> <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> Message-ID: This is exactly the kind of tool that it makes sense to extend to script limits, and I don't think anyone has suggested it wouldn't be available, even if we haven't explicitly listed it as a feature yet. On Wed, Dec 16, 2009 at 11:54 PM, Peter Leonard/Dante wrote: > Just look at region Object Bonus. This is an example where a dynamic system > is already in use and works. > > Object bonus allows EMs and the EO to allocate empty buffer parcels in > order to give other parcels more prims. > > With object bonus on there is the posibility to rez more prims then the sim > allows and have the sim return random objects, yet it works, and LL chose to > give the estate staff the choice. Why can we not do this with script limits > as well? > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091217/35a463e8/attachment.htm From danteferret at gmail.com Thu Dec 17 10:54:39 2009 From: danteferret at gmail.com (danteferret at gmail.com) Date: Thu, 17 Dec 2009 18:54:39 +0000 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <9bb32d430912170739i57c153f0x627f006b175fa4c4@mail.gmail.com> Message-ID: <001636b2b006be3037047af12746@google.com> Unfortunately that does not work either. Typicaly the land is set up like this: Public no build land owned by a group or the EO, used as buffer space. And all the other parcels owned by various renters, who will be receiving the bonus in prims. As you can see, in typical situations the land is not owned by the same person. On Dec 17, 2009 10:39am, Ambrosia wrote: > Or, as I mentioned, the parcel object bonus has an influence on a > script memory bonus, that would work similiar the parcel bonus does. > Dependant on total land mass person X owns in the sim. The parcel can > hold more objects/Memory than it normally could, but it can't go above > the total objects/Memory the parcels by the person in the sim put > together would allow. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091217/b7687be4/attachment.htm From melinda at superliminal.com Thu Dec 17 13:17:09 2009 From: melinda at superliminal.com (Melinda Green) Date: Thu, 17 Dec 2009 13:17:09 -0800 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com> References: <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <9bb32d430912170649l3165191jb00924397ae8245d@mail.gmail.com> <4B2A4A03.5090203@Gmail.com> <9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com> Message-ID: <4B2A9FD5.3050708@superliminal.com> Perhaps a hybrid design might make for a reasonable compromise between predictability and flexibility. Something like hard lower memory limits that scripters can count on always being available, plus the ability to request and receive provisional amounts beyond that which might get yanked back at any time. If you go beyond the safe limits, you take your chances. There may even be more gentle ways to deal with these worst-case situations, for example by creating an LSL event that informs scripts when they are about to lose some or all of the provisional memory that they are using, giving them a chance to get back under a safe limit and avoid getting shut down. I suspect that Qie Niangao is right that some non-trivial optimization logic is called for here. To me the situation feels like operating system design. In many ways the simulators *are* simple operating systems. Perhaps talking with some Linux kernel developers might identify some libraries that can be used to manage script resource allocations. I don't know because OS design is not my field but I suspect that there are no simple solutions to this problem and that it would not be smart to try to reinvent its solutions. -Melinda Ambrosia wrote: > But in your example, the script uses the max of the sim til the avatar > comes in. The script will crash, as the avatar takes his own share of > memory, and the script suddenly has less than it actually uses (not > what it -could- use but doesn't). > > Scripts -will- be able to check available memory, that much has been > stated, and they reserve additional memory they need with another > function, but that available memory should not depend on factors of > what's going on outside the parcel or on other avatars aside of the > own. > > Quite frankly, the only thing that makes sense for scripters and > content creators are hard numbers they can work with. Fixed memory > amounts. Every 512sqm parcel should always (normally) support X mb > max. Every avatar should normally support Y mb max. A solid api to > build scripts upon. Available memory depends on the scripts already > attached to the -same- avatar or on the -same- parcel, but a parcel's > or avatar's memory should -not- be dependant in any way on external > factors like other avatars or parcels. It makes things unreliable, > unpredictable. > > On Thu, Dec 17, 2009 at 16:10, Tigro Spottystripes > wrote: > >> There should be a way for scripts to check how much memory is avaiable >> int he pool for the sim, and for the parcel, and also how much memory >> the script will be limited to under a worse case scenario, >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From TammyNowotny at mac.com Thu Dec 17 13:24:00 2009 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Thu, 17 Dec 2009 16:24:00 -0500 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2A52AA.7020002@Gmail.com> References: <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <9bb32d430912170649l3165191jb00924397ae8245d@mail.gmail.com> <4B2A4A03.5090203@Gmail.com> <9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com> <4B2A52AA.7020002@Gmail.com> Message-ID: <4B2AA170.1030606@mac.com> One concern I have is that script limits could be turned around into a griefers tool. You will undoubtedly have scripts designed simply to use up all the bandwidth. And there might be more subtle exploits where the griefer uses up all the capacity, and then releases some of it at just the wrong moment to enable some nasty prank can be pulled which everyone else will be powerless to counteract. From tigrospottystripes at gmail.com Thu Dec 17 13:38:40 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 17 Dec 2009 19:38:40 -0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2A9FD5.3050708@superliminal.com> References: <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <9bb32d430912170649l3165191jb00924397ae8245d@mail.gmail.com> <4B2A4A03.5090203@Gmail.com> <9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com> <4B2A9FD5.3050708@superliminal.com> Message-ID: <4B2AA4E0.1030200@Gmail.com> The problem with a fixed maximum guranteed memory per script is that it doesnt' add a limit for more than one script, so several scripts could be using the minimum guarantted and not veing capped. My idea is to haev a fixed per meter and per avatar maximum guaranteed memory, anything baove guaranteed. Scripts using more than that are out of the safe limits. We Need somthing like llGetSimFullMemory, llGetSimFreeMemoy, llGetParcelFullMemory, llGetParcelFreeMemory, llGetOwnerFullMemory and llGetOwnerFreeMemory. And i like the idea of an event to be triggered before the script either looses some of it's avaiable memory or is about to be shut down if it doesn't start using N less bytes of memory, somthing like: less_memory(float bytes_to_loose) The sun wauts tgat evebt ti ebd fir a secibd ir si abd uf ut diesb't ebd vefire tgatm ir uf after that the script still hasn't lost enough bytes in it's ram footprint the sim will shutdown the script (perhaps save the script state of not running scripts on disk and not on ram?) Melinda Green escreveu: > Perhaps a hybrid design might make for a reasonable compromise between > predictability and flexibility. Something like hard lower memory > limits that scripters can count on always being available, plus the > ability to request and receive provisional amounts beyond that which > might get yanked back at any time. If you go beyond the safe limits, > you take your chances. There may even be more gentle ways to deal with > these worst-case situations, for example by creating an LSL event that > informs scripts when they are about to lose some or all of the > provisional memory that they are using, giving them a chance to get > back under a safe limit and avoid getting shut down. > > I suspect that Qie Niangao is right that some non-trivial optimization > logic is called for here. To me the situation feels like operating > system design. In many ways the simulators *are* simple operating > systems. Perhaps talking with some Linux kernel developers might > identify some libraries that can be used to manage script resource > allocations. I don't know because OS design is not my field but I > suspect that there are no simple solutions to this problem and that it > would not be smart to try to reinvent its solutions. > > -Melinda > > Ambrosia wrote: >> But in your example, the script uses the max of the sim til the avatar >> comes in. The script will crash, as the avatar takes his own share of >> memory, and the script suddenly has less than it actually uses (not >> what it -could- use but doesn't). >> >> Scripts -will- be able to check available memory, that much has been >> stated, and they reserve additional memory they need with another >> function, but that available memory should not depend on factors of >> what's going on outside the parcel or on other avatars aside of the >> own. >> >> Quite frankly, the only thing that makes sense for scripters and >> content creators are hard numbers they can work with. Fixed memory >> amounts. Every 512sqm parcel should always (normally) support X mb >> max. Every avatar should normally support Y mb max. A solid api to >> build scripts upon. Available memory depends on the scripts already >> attached to the -same- avatar or on the -same- parcel, but a parcel's >> or avatar's memory should -not- be dependant in any way on external >> factors like other avatars or parcels. It makes things unreliable, >> unpredictable. >> >> On Thu, Dec 17, 2009 at 16:10, Tigro Spottystripes >> wrote: >> >>> There should be a way for scripts to check how much memory is avaiable >>> int he pool for the sim, and for the parcel, and also how much memory >>> the script will be limited to under a worse case scenario, >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > From joel.foner at gmail.com Thu Dec 17 14:57:28 2009 From: joel.foner at gmail.com (Joel Foner) Date: Thu, 17 Dec 2009 17:57:28 -0500 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2AA170.1030606@mac.com> References: <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <9bb32d430912170649l3165191jb00924397ae8245d@mail.gmail.com> <4B2A4A03.5090203@Gmail.com> <9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com> <4B2A52AA.7020002@Gmail.com> <4B2AA170.1030606@mac.com> Message-ID: <7c58f6610912171457l20748a24la971f7b582e3d7a7@mail.gmail.com> This exists today - except that when the resources are exhausted an entire region is slowed to a crawl or crashed. Wouldn't it be better to have the effects of an inadvertent or purposeful attempt to run the system out of resources to be contained to some degree? Joel On Thu, Dec 17, 2009 at 4:24 PM, Tammy Nowotny wrote: > > One concern I have is that script limits could be turned around into a > griefers tool. You will undoubtedly have scripts designed simply to use > up all the bandwidth. And there might be more subtle exploits where the > griefer uses up all the capacity, and then releases some of it at just > the wrong moment to enable some nasty prank can be pulled which everyone > else will be powerless to counteract. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091217/450f7563/attachment.htm From brad at lindenlab.com Thu Dec 17 17:30:08 2009 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Thu, 17 Dec 2009 17:30:08 -0800 Subject: [sldev] Tutorial for SL shaders ("for dummies")? In-Reply-To: <4B281472.7040104@fishkill.ibm.com> References: <4B246F76.4020502@gmail.com> <171234.6045.qm@web59107.mail.re1.yahoo.com> <4B250EE9.60908@gmail.com> <4D4E868E-196E-4FC0-A33A-D32FDF9DEE0D@gmail.com> <4B26A427.6040300@Gmail.com> <4B27BE0C.9020504@fishkill.ibm.com> <4B27FF55.5070006@Gmail.com> <4B281472.7040104@fishkill.ibm.com> Message-ID: <80e689370912171730i5046f8a5td3507f2adfadb144@mail.gmail.com> The place to start looking is in class1/objects/simple{F,V}.glsl Things quickly get complicated from there, however. We have a relatively complex shader system compared to most games I'm aware of, where we rely heavily on the GLSL linker to provide seams for swapping out functionality based on available hardware. You can see an example of this with how the class{1,2}/lighting/lightV.glsl files interact with class{1,2,3}/lighting/sumLightsV.glsl. This system makes it relatively easy to implement our complicated matrix of graphics preferences and compatibility featuretable masks, but it can make it very hard to trace the execution of a particular shader, as it's often unclear which exact files are being loaded and executed on a particular machine. It's often worth it to watch the log console for LLShaderMgr::loadShaderFile entries as it dumps what combinations of shader files it's linking. I think this debugging info is enabled by default, but in case it's not see http://wiki.secondlife.com/wiki/Logging_System_Overview for info about how to reenable it in logcontrol-dev.xml. I hope this is enough to get you started, let me know if you have more questions... -Brad On Tue, Dec 15, 2009 at 2:57 PM, Mike Monkowski wrote: > Tigro Spottystripes wrote: > > Somewhere between the two, worse case at least somthing explaining the > > specifics of how SL uses it and what are the particularities for the > > .glsl files the client uses (including the exact structure of files and > > things that work and doesn't work, things that are not following the > > standards etc) > > Well, the "worst case" documentation is probably > app_settings/shaders/shader_hierarchy.txt > then you look at llviewershadermgr.cpp > > I haven't done more than look at them, but the in-line comments don't > look too bad. > > It would be nice if doxygen handeled GLSL, but I don't think it does. > > Mike > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091217/4b0af3f7/attachment.htm From tigrospottystripes at gmail.com Fri Dec 18 01:21:49 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Fri, 18 Dec 2009 07:21:49 -0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2AC66D.2070205@superliminal.com> References: <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <9bb32d430912170649l3165191jb00924397ae8245d@mail.gmail.com> <4B2A4A03.5090203@Gmail.com> <9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com> <4B2A9FD5.3050708@superliminal.com> <4B2AA4E0.1030200@Gmail.com> <4B2AC66D.2070205@superliminal.com> Message-ID: <4B2B49AD.6050500@Gmail.com> wow, i usually re-read my emails before sending them and do ortographic corrections, i have no idea what happened there 0.0 sorry :/ lemme try it again The problem with a fixed maximum guaranteed memory per script is that it doesn't add a limit for more than one script, so several scripts could be using the minimum guaranteed and not being capped. My idea is to have a fixed per meter and per avatar maximum guaranteed memory, anything above guaranteed. Scripts using more than that are out of the safe limits. We Need somthing like llGetSimFullMemory, llGetSimFreeMemoy, llGetParcelFullMemory, llGetParcelFreeMemory, llGetOwnerFullMemory and llGetOwnerFreeMemory. And i like the idea of an event to be triggered before the script either looses some of it's avaiable memory or is about to be shut down if it doesn't start using N less bytes of memory, somthing like: less_memory(float bytes_to_loose) The sim waits for the event to end for a second or so and if it doesn't end in time or if after that the script still hasn't lost enough bytes in it's ram footprint the sim will shutdown the script (perhaps save the script state of not running scripts on disk and not on ram?) there, once again sorry for the messed up msg :\ Melinda Green escreveu: > That seems like the same thing that I just said except that your text > and grammar are so messed up that it is hard for me to understand > exactly what you are saying. > -Melinda > > Tigro Spottystripes wrote: >> The problem with a fixed maximum guranteed memory per script is that it >> doesnt' add a limit for more than one script, so several scripts could >> be using the minimum guarantted and not veing capped. >> >> My idea is to haev a fixed per meter and per avatar maximum guaranteed >> memory, anything baove guaranteed. Scripts using more than that are out >> of the safe limits. >> >> We Need somthing like llGetSimFullMemory, llGetSimFreeMemoy, >> llGetParcelFullMemory, llGetParcelFreeMemory, llGetOwnerFullMemory and >> llGetOwnerFreeMemory. And i like the idea of an event to be triggered >> before the script either looses some of it's avaiable memory or is about >> to be shut down if it doesn't start using N less bytes of memory, >> somthing like: >> >> less_memory(float bytes_to_loose) >> >> >> The sun wauts tgat evebt ti ebd fir a secibd ir si abd uf ut diesb't ebd >> vefire tgatm ir uf after that the script still hasn't lost enough bytes >> in it's ram footprint the sim will shutdown the script (perhaps save the >> script state of not running scripts on disk and not on ram?) >> >> >> >> >> Melinda Green escreveu: >> >>> Perhaps a hybrid design might make for a reasonable compromise between >>> predictability and flexibility. Something like hard lower memory >>> limits that scripters can count on always being available, plus the >>> ability to request and receive provisional amounts beyond that which >>> might get yanked back at any time. If you go beyond the safe limits, >>> you take your chances. There may even be more gentle ways to deal with >>> these worst-case situations, for example by creating an LSL event that >>> informs scripts when they are about to lose some or all of the >>> provisional memory that they are using, giving them a chance to get >>> back under a safe limit and avoid getting shut down. >>> >>> I suspect that Qie Niangao is right that some non-trivial optimization >>> logic is called for here. To me the situation feels like operating >>> system design. In many ways the simulators *are* simple operating >>> systems. Perhaps talking with some Linux kernel developers might >>> identify some libraries that can be used to manage script resource >>> allocations. I don't know because OS design is not my field but I >>> suspect that there are no simple solutions to this problem and that it >>> would not be smart to try to reinvent its solutions. >>> >>> -Melinda >>> >>> Ambrosia wrote: >>> >>>> But in your example, the script uses the max of the sim til the avatar >>>> comes in. The script will crash, as the avatar takes his own share of >>>> memory, and the script suddenly has less than it actually uses (not >>>> what it -could- use but doesn't). >>>> >>>> Scripts -will- be able to check available memory, that much has been >>>> stated, and they reserve additional memory they need with another >>>> function, but that available memory should not depend on factors of >>>> what's going on outside the parcel or on other avatars aside of the >>>> own. >>>> >>>> Quite frankly, the only thing that makes sense for scripters and >>>> content creators are hard numbers they can work with. Fixed memory >>>> amounts. Every 512sqm parcel should always (normally) support X mb >>>> max. Every avatar should normally support Y mb max. A solid api to >>>> build scripts upon. Available memory depends on the scripts already >>>> attached to the -same- avatar or on the -same- parcel, but a parcel's >>>> or avatar's memory should -not- be dependant in any way on external >>>> factors like other avatars or parcels. It makes things unreliable, >>>> unpredictable. >>>> >>>> On Thu, Dec 17, 2009 at 16:10, Tigro Spottystripes >>>> wrote: >>>> >>>> >>>>> There should be a way for scripts to check how much memory is >>>>> avaiable >>>>> int he pool for the sim, and for the parcel, and also how much memory >>>>> the script will be limited to under a worse case scenario, >>>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/SLDev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >>>> >>>> >> >> >> > From secret.argent at gmail.com Fri Dec 18 03:52:26 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 18 Dec 2009 05:52:26 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2A423A.40902@Gmail.com> References: <1e01733d0912160445w7c032677xf7bbfed02c25d7a5@mail.gmail.com> <4B28E68C.8000503@gmail.com> <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> Message-ID: On 2009-12-17, at 08:37, Tigro Spottystripes wrote: > But the limits should only be enforced when necessary, if there is a > bunch of scripts in a 4x4 parcel and nothing else int he rest of the > sim > those scripts can use up all the sim script memory, if an avatar comes > in, then the avaiablememory is divided between the parcel and the > avatar, things like that THe scaled overcommitment scheme I suggested over a year ago would work well for this: If the sim as a whole is over 75% of the limit, all parcels would be restricted to strict limits. Below that, scale it so that (for example) 50% of the sim could have up to 80% of the limit, 25% of the sim could have up to 60% of the limit, 12.5% could have 40%, and so on. The actual numbers would have to be tuned, but this would allow you to have a party on your 512 in an otherwise empty sim without blowing the parcel limits with the dance balls, and without allowing a DOS. You'd be able to tell if your parcel was over the soft limit, so you could keep from having your pet dog frozen if someone else pushed the sim over 75%. From secret.argent at gmail.com Fri Dec 18 03:57:11 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 18 Dec 2009 05:57:11 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com> References: <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <9bb32d430912170649l3165191jb00924397ae8245d@mail.gmail.com> <4B2A4A03.5090203@Gmail.com> <9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com> Message-ID: <4C5BE95A-421C-4B01-B3EF-2B9543850F86@gmail.com> On 2009-12-17, at 09:17, Ambrosia wrote: > Quite frankly, the only thing that makes sense for scripters and > content creators are hard numbers they can work with. Fixed memory > amounts. Nah, a soft limit applied only when the sim is below 75%, and a hard limit applied when the sim is stressed, is still pretty easy to understand and much more practical for the spotty distribution of scripts in SL. If you keep your parcel below the soft limit, you would be guaranteed resources. If you let it go over the soft limit, you would risk having scripted objects returned. Maybe even have a landowner switch to allow overcommitment on the parcel, so people running sandboxes and the like could control it. From aleric.inglewood at gmail.com Fri Dec 18 04:10:52 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Fri, 18 Dec 2009 13:10:52 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4B28E68C.8000503@gmail.com> <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> Message-ID: <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> On Fri, Dec 18, 2009 at 05:52:26AM -0600, Argent Stonecutter wrote: > If the sim as a whole is over 75% of the limit, all parcels would be > restricted to strict limits. That is instable, you shouldn't shift the limit in a way that it can start oscillating. Also, it won't solve my problem with the "chick-shoot game": Given, a region with 10 residents that are only there 1 hour per day and seldom at the same time. Each resident uses a fixed amount of scripts 24/7 but also keeps a reserve for own use, for temporary events (like shooting chickens, say). If any residents wants to start shooting chickens, they should be able to use all available memory (for as long as it is available). The "temporary use" reserve allows for -say- 100 chickens to be rezzed. Under the new system, only 10 chickens could be rezzed at any time, because it keeps a reserve reserved for each and every resident, just in case they might suddenly want to play this game all at the same time in their own parcel (nonsense thus, which is why this proposed system is so bad). Your solution doesn't work either however: In your case I would start rezzing chickens, and when I rez chicken 76, suddenly the limits would kick in full force and 66 chickens would die, only leaving 10 to run free. At that moment we'd be under the 75% again though, so my chicken rez object would start creating new chickens again, until it again rezzes the 76th chicken... > Below that, scale it so that (for example) 50% of the sim could have > up to 80% of the limit, 25% of the sim could have up to 60% of the > limit, 12.5% could have 40%, and so on. The actual numbers would have > to be tuned, but this would allow you to have a party on your 512 in > an otherwise empty sim without blowing the parcel limits with the > dance balls, and without allowing a DOS. Um, I cannot exactly follow this part ;) Nevertheless, I applaude your ideas :) THIS subject is what is the greatest fiasco with the new system. Now if only the Lindens working on this were willing to admit it. > You'd be able to tell if your parcel was over the soft limit, so you > could keep from having your pet dog frozen if someone else pushed the > sim over 75%. I'm sure that the solution isn't simple. It's much easier to just allocate a (very small) fixed amount for everyone and screw those that complain about suddenly not being able anymore to do things that were totally legal and good use of SL before. From tillie at xp2.de Fri Dec 18 04:11:49 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Fri, 18 Dec 2009 13:11:49 +0100 Subject: [sldev] My Trials and Tribs In-Reply-To: <42A5979A1AF7441DBBEA38C16C7C5553@LRBXPS> References: <796B1B47705B43E58C3FE4C2682F8A4E@LRBXPS> <4B215D1E.3060608@gmail.com> <42A5979A1AF7441DBBEA38C16C7C5553@LRBXPS> Message-ID: <4B2B7185.9060606@xp2.de> On 10.12.2009 22:26, Laurence Brickner wrote: > Thanks. I uninstalled 2005 about 6 months ago, but somewhere in that vast > pile of CDs I get from Mother Microsoft every month is an install CD for the > Full 2005. Is it worth looking for or is the express version sufficient. Hello Laurence, I got the client compiled with the 2005 Express version. Was a bit of a fight first, as I had no idea of Visual Studio at all, but now all is well. I got the source zip running and a checkout from svn, too. Compile is only working from within the UI, though, because whoever wrote develop.py didn't try with the Express version, so it chokes two times, first on a missing registry entry, that's just not available for the Express version, and then on a not existing EXE file, that is not part of Express either. Just use the UI and all is well (or go fix the develop.py and submit a patch :D). I'll check the wiki pages at some time and update them. But best would be to rewrite the "how to compile SL client" stuff from scratch, it's far too many different pages and very confusing. Maybe 1 page for each OS, only. Tillie From secret.argent at gmail.com Fri Dec 18 04:15:37 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 18 Dec 2009 06:15:37 -0600 Subject: [sldev] Another thought on soft/hard limits... In-Reply-To: <4B2B49AD.6050500@Gmail.com> References: <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <9bb32d430912170649l3165191jb00924397ae8245d@mail.gmail.com> <4B2A4A03.5090203@Gmail.com> <9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com> <4B2A9FD5.3050708@superliminal.com> <4B2AA4E0.1030200@Gmail.com> <4B2AC66D.2070205@superliminal.com> <4B2B49AD.6050500@Gmail.com> Message-ID: <7DE6A8C5-D5B0-4B31-9AB5-361DC1B3EAF6@gmail.com> Another thought on my soft/hard limit suggestion: scripts could check if the parcel they are in is over the soft limit, and release cached information like lists of avatars or information read from configuration notecards and go into dormant low-memory mode. Multi- script objects could even remove extra scripts. That could even be a selling point: "this script is memory safe... if parcel or region memory use is high, your Wunderdawg? will go to sleep using minimum memory until it's safe to play again!" From robin.cornelius at gmail.com Fri Dec 18 04:19:03 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri, 18 Dec 2009 12:19:03 +0000 Subject: [sldev] My Trials and Tribs In-Reply-To: <4B2B7185.9060606@xp2.de> References: <796B1B47705B43E58C3FE4C2682F8A4E@LRBXPS> <4B215D1E.3060608@gmail.com> <42A5979A1AF7441DBBEA38C16C7C5553@LRBXPS> <4B2B7185.9060606@xp2.de> Message-ID: On Fri, Dec 18, 2009 at 12:11 PM, Tillie Ariantho wrote: > On 10.12.2009 22:26, Laurence Brickner wrote: > Compile is only working from within the UI, though, because whoever wrote develop.py didn't try with the Express version, so it chokes two times, first on a missing registry entry, that's just not > available for the Express version, and then on a not existing EXE file, that is not part of Express either. This is a known issue, develop.py was written for linden lab, where they use visual studio 2005 professional > > Just use the UI and all is well (or go fix the develop.py and submit a patch :D). The basic issue here is not fixable, it is not possible to modify visual studio solutions in the way that are required with an express edition of visual studio. This is by design from Microsoft, the specific automation API that is missing is only available to paid customers of visual studio. Setting the statup project, selecting the build configuration and modifying the working folder are the 3 tasks we need to do but cannot as this data is within the user options file of the solution which is a binary file, with no published format that is only designed to be accessed via the API described in the previous paragraph. Its possible to *improve* develop.py so it handles the entire situation with some grace, and there is a patch of mine on jira (i forget the number) which at least detects visual studio express and then makes no attempt to run the vstool.exe program but instead prints some advice for the user on how to proceed. I guess we should revive this and get it into snowglobe to avoid people having to repeat the same problems over and over. Robin From carlo at alinoe.com Fri Dec 18 04:25:51 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 18 Dec 2009 13:25:51 +0100 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <4B288A47.5000204@gmail.com> <1aff09e40912160444k25f42431i92ee5cf624631f40@mail.gmail.com> Message-ID: <20091218122551.GA32194@alinoe.com> On Wed, Dec 16, 2009 at 08:18:18PM -0800, Dahlia Trimble wrote: > Of course prim animators use many scripts to get around the 0.2 second delay > now, so yeah, maybe just getting rid of it is a good idea :) Sorry, but the whole "sleep" punishment is a typical Linden way to "solve" things that just never will work. Whatever you try to solve that way (ie have people pay L$ 10 for freebies to 'encourage' them to not list them; or use a punisher multiplier on LSL scripts to 'encourage' people not to use them etc etc, STOP. That is NOT the way. You don't even have to think about it, it just is NOT the correct way to solve whatever problem you have. So, yes, adding any "sleep" to any of the functions should never have happened in the first place. Look again at what the problem REALLY is, and then solve the problem at the core instead of making the life of people miserable with artifacts hoping that they'll be forced (out of misery) into doing things in a different way: First: method A sucks 10. method B sucks 20. people use method A. Linden Lab wants people to use method B. The correct solution would be to make method B suck only 5. The solution that Linden Lab chooses is to make method A artificially suck 40... The end result is that SL will suck, and people will leave. -- Carlo Wood From carlo at alinoe.com Fri Dec 18 04:32:52 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 18 Dec 2009 13:32:52 +0100 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <9788aeb10912170417w263e8ddo27a7e26e9d20c246@mail.gmail.com> References: <9788aeb10912170417w263e8ddo27a7e26e9d20c246@mail.gmail.com> Message-ID: <20091218123252.GB32194@alinoe.com> On Thu, Dec 17, 2009 at 07:17:03AM -0500, Qie Niangao wrote: > I sense an opportunity for some non-trivial mathematics to be applied > to optimally setting these limits. > > The obviously, horribly wrong approach would be to set a ceiling for > all script memory use in a region and apportion that to parcel and > avatar allotments such that no over-allocation could ever occur. This > would create much lower limits than required for sub-ceiling > operations almost all the time. THANK YOU!!! Finally someone else that understands this :) I hope that you, and everyone else that understands this, will go the Babbage office hours to bring this under her attention again and again; until he understands that the easy road is not the right one, and some more difficult approach HAS to be taken. > Rather, the total amount of script memory that the limits permit may > be two or five or ten times that ceiling and still only encounter the > ceiling once every millenium or century or decade--all depending on > the distribution of transient demand for the capacity being limited. > So a Poisson or Erlang or some such distribution is relevant here. Exactly. The servers will simply only use a FRACTION of their resources on average. A huge waste of resources that we, the residents, will have to pay for, literally. > What's interesting is that there are (at least) two identifiable > distributions: scripts in avatar attachments, and in parcel-resident > objects. The former is much, much more transient, of course. It all > feels a bit like engineering fibre capacity to optimally handle > predicted demand for different telecom applications. > > Ignoring that new scripting functions may systematically change these > demand distributions, this seems an interesting problem for somebody > with the right background (not me!). > > Even if solving the optimization problem is judged overkill, I wanted > to at least prevent that "obviously, horribly wrong approach." The problem however is not technical (point out the flaw and people start working on it), it is political. Before Babbage is going to listen to this you'll need a LOT of lobbying-- no matter how utterly true it is. -- Carlo Wood From dgothly at erotobotics.com Fri Dec 18 04:54:17 2009 From: dgothly at erotobotics.com (Darrius Gothly) Date: Fri, 18 Dec 2009 07:54:17 -0500 Subject: [sldev] Another thought on soft/hard limits... References: <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <9bb32d430912170649l3165191jb00924397ae8245d@mail.gmail.com> <4B2A4A03.5090203@Gmail.com><9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com><4B2A9FD5.3050708@superliminal.com> <4B2AA4E0.1030200@Gmail.com><4B2AC66D.2070205@superliminal.com> <4B2B49AD.6050500@Gmail.com> <7DE6A8C5-D5B0-4B31-9AB5-361DC1B3EAF6@gmail.com> Message-ID: <8338B0826978456F9FFA68B5D0DC2577@jbh3000> Pardon me if I'm just restating the obvious, but I just want to be sure I understand what you're saying. It really doesn't matter how the limits are set, the real thrust of these ideas is that a Sim is not always equally loaded. Because of visiting patterns of the residents and guests, at any one time the population on the sim is concentrated .. usually in one parcel. When the other parcels are empty, that one should get to use all available SIM resources. When others come back into their own parcel, they can reclaim what's "theirs" just by entering (and using some formula yet to work out). If this is what you're saying then yes, I agree 100%. From brickrte at hughes.net Fri Dec 18 06:13:44 2009 From: brickrte at hughes.net (Laurence Brickner) Date: Fri, 18 Dec 2009 09:13:44 -0500 Subject: [sldev] My Trials and Tribs In-Reply-To: References: <796B1B47705B43E58C3FE4C2682F8A4E@LRBXPS><4B215D1E.3060608@gmail.com> <42A5979A1AF7441DBBEA38C16C7C5553@LRBXPS><4B2B7185.9060606@xp2.de> Message-ID: Many thanks to both of you. In the end, I found the (Paid for ) CDs and reinstalled VS2005 and have successfully compiled the SnowGlobe client. Although the instructions etc are still in need of clean up. As part of my "learning curve" I'm looking at SNOW 386 and making progress so I'm sort of launched. Another hurdle I'm tripping over is trying to get the media plugin API to play. There aren't any instructions for that or any idea what things like the exes are trying to do. All part of the fun. Thanks again, Larry/Shorahmin -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Robin Cornelius Sent: Friday, December 18, 2009 07:19 To: Tillie Ariantho Cc: sldev at lists.secondlife.com Subject: Re: [sldev] My Trials and Tribs On Fri, Dec 18, 2009 at 12:11 PM, Tillie Ariantho wrote: > On 10.12.2009 22:26, Laurence Brickner wrote: > Compile is only working from within the UI, though, because whoever wrote develop.py didn't try with the Express version, so it chokes two times, first on a missing registry entry, that's just not > available for the Express version, and then on a not existing EXE file, that is not part of Express either. This is a known issue, develop.py was written for linden lab, where they use visual studio 2005 professional > > Just use the UI and all is well (or go fix the develop.py and submit a patch :D). The basic issue here is not fixable, it is not possible to modify visual studio solutions in the way that are required with an express edition of visual studio. This is by design from Microsoft, the specific automation API that is missing is only available to paid customers of visual studio. Setting the statup project, selecting the build configuration and modifying the working folder are the 3 tasks we need to do but cannot as this data is within the user options file of the solution which is a binary file, with no published format that is only designed to be accessed via the API described in the previous paragraph. Its possible to *improve* develop.py so it handles the entire situation with some grace, and there is a patch of mine on jira (i forget the number) which at least detects visual studio express and then makes no attempt to run the vstool.exe program but instead prints some advice for the user on how to proceed. I guess we should revive this and get it into snowglobe to avoid people having to repeat the same problems over and over. Robin _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges From marinekelley at gmail.com Fri Dec 18 07:34:41 2009 From: marinekelley at gmail.com (Marine Kelley) Date: Fri, 18 Dec 2009 16:34:41 +0100 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <20091218123252.GB32194@alinoe.com> References: <9788aeb10912170417w263e8ddo27a7e26e9d20c246@mail.gmail.com> <20091218123252.GB32194@alinoe.com> Message-ID: Although all neat and certainly very clever, would this kind of solution still satisfy my primary need as a scripter ?I.e. being CERTAIN that my scripts will NEVER crash because of memory shortage due to reasons that are out of my control ? I could write the best script in the world that takes a constant amount of memory, it would still crash eventually if this amount suddenly became higher than the limit, if this limit moves down when the sim becomes busier. The script could freeze, slow down, we could have functions and events to stay aware of how many bytes we have left, but to me the core issue is that scripts which run out of memory simply endure an unrecoverable crash. This basic behavior is very wrong in the first place and must be revised. Yes I do know this is asking a lot. I do not even expect this to change any time soon, but in the meantime PLEASE don't add one more level of uncertainty when it comes to scripting. I want to know how many bytes I have left, and I want total control over what consumes them. Leave the limits fixed ! Marine On 18 d?c. 2009, at 13:32, Carlo Wood wrote: > On Thu, Dec 17, 2009 at 07:17:03AM -0500, Qie Niangao wrote: >> I sense an opportunity for some non-trivial mathematics to be applied >> to optimally setting these limits. >> >> The obviously, horribly wrong approach would be to set a ceiling for >> all script memory use in a region and apportion that to parcel and >> avatar allotments such that no over-allocation could ever occur. >> This >> would create much lower limits than required for sub-ceiling >> operations almost all the time. > > THANK YOU!!! > Finally someone else that understands this :) > > I hope that you, and everyone else that understands this, will go > the Babbage office hours to bring this under her attention again > and again; until he understands that the easy road is not the right > one, and some more difficult approach HAS to be taken. > >> Rather, the total amount of script memory that the limits permit may >> be two or five or ten times that ceiling and still only encounter the >> ceiling once every millenium or century or decade--all depending on >> the distribution of transient demand for the capacity being limited. >> So a Poisson or Erlang or some such distribution is relevant here. > > Exactly. The servers will simply only use a FRACTION of their > resources on average. A huge waste of resources that we, the > residents, > will have to pay for, literally. > >> What's interesting is that there are (at least) two identifiable >> distributions: scripts in avatar attachments, and in parcel-resident >> objects. The former is much, much more transient, of course. It all >> feels a bit like engineering fibre capacity to optimally handle >> predicted demand for different telecom applications. >> >> Ignoring that new scripting functions may systematically change these >> demand distributions, this seems an interesting problem for somebody >> with the right background (not me!). >> >> Even if solving the optimization problem is judged overkill, I wanted >> to at least prevent that "obviously, horribly wrong approach." > > The problem however is not technical (point out the flaw and people > start working on it), it is political. Before Babbage is going to > listen to this you'll need a LOT of lobbying-- no matter how utterly > true it is. > > -- > Carlo Wood > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From da5idkronfeld at gmail.com Fri Dec 18 09:13:10 2009 From: da5idkronfeld at gmail.com (Da5id Kronfeld) Date: Fri, 18 Dec 2009 09:13:10 -0800 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> References: <4B28E68C.8000503@gmail.com> <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> Message-ID: On 2009-12-18, at 4:10 AM, Aleric Inglewood wrote: > On Fri, Dec 18, 2009 at 05:52:26AM -0600, Argent Stonecutter wrote: >> If the sim as a whole is over 75% of the limit, all parcels would be >> restricted to strict limits. > > That is instable, you shouldn't shift the limit in a way that > it can start oscillating. Also, it won't solve my problem with > the "chick-shoot game": [cut] > Your solution doesn't work either however: In your case I would > start rezzing chickens, and when I rez chicken 76, suddenly > the limits would kick in full force and 66 chickens would die, > only leaving 10 to run free. At that moment we'd be under the > 75% again though, so my chicken rez object would start creating > new chickens again, until it again rezzes the 76th chicken... While I'm still on the fence about dynamic limits, this oscillating effect can be mitigated by damping factor that doesn't allow the sim to return to an overcommitted state immediately following a script cull. From kelly at lindenlab.com Fri Dec 18 10:13:36 2009 From: kelly at lindenlab.com (Kelly Linden) Date: Fri, 18 Dec 2009 10:13:36 -0800 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> Message-ID: I'll be honest. I just really don't like the dynamic resource limits idea. It is very neat and interesting in theory, and fun to design and discuss. However I see a lot of value in knowing all my content will continue to work and knowing what content I can use - In knowing that when I buy/rent/lease land as part of that I am buying/renting/leasing a specific amount of resources. I hate the idea of *any* of my content only sometimes working. I place a high value on simplicity. I want to trivially understand where I am, how much headroom I have, how close I am to what limits there are. I don't want to code complex solutions with multiple behaviors based on the state of the region. And yes, I know people already do this by monitoring sim stats but it would be awesome if they didn't need to. "normal" residents also need to understand these limits and be able to see where they are. These limits will effect *everyone*, even if all you do is rent a house and buy content to furnish it. You will need to know what will and won't work and buying something that will sometimes work no matter what the reasons is just going to be a nightmare. If I buy a fish tank it needs to always work and always have fish and not have fish that sleep or disappear when my neighbors decide it is chicken shooting time. That said, I also understand the usage issues here, which mirror closely the more generic web hosting problems. Resource usage patterns aren't equal or consistent over time or space, this is obvious and known and is NOT something we are ignoring. The general solution for web hosting is to over-sell, rely on some rules of averages and be able to move things around to accommodate users. Doing something similar is certainly a possibility, and one I have pushed for. It isn't as trivial as just setting higher numbers - we need to adjust and fix our infrastructure to more optimally assign regions to hosts - but it is certainly not impossible, and indeed such infrastructure changes would benefit everyone regardless. Dynamic resource limits are just complicated by nature. They are fluid in some respect, and they change based on time and usage - that is just what it means. Unfortunately it is that nature that makes it hard to plan around and hard to build content for and hard to understand. The system we use needs to be as easy as prim limits are now, where you can see the cost of an object and you can see how much you can support. - Kelly On Fri, Dec 18, 2009 at 9:13 AM, Da5id Kronfeld wrote: > > On 2009-12-18, at 4:10 AM, Aleric Inglewood wrote: > > > On Fri, Dec 18, 2009 at 05:52:26AM -0600, Argent Stonecutter wrote: > >> If the sim as a whole is over 75% of the limit, all parcels would be > >> restricted to strict limits. > > > > That is instable, you shouldn't shift the limit in a way that > > it can start oscillating. Also, it won't solve my problem with > > the "chick-shoot game": > > [cut] > > > Your solution doesn't work either however: In your case I would > > start rezzing chickens, and when I rez chicken 76, suddenly > > the limits would kick in full force and 66 chickens would die, > > only leaving 10 to run free. At that moment we'd be under the > > 75% again though, so my chicken rez object would start creating > > new chickens again, until it again rezzes the 76th chicken... > > While I'm still on the fence about dynamic limits, this oscillating effect > can be mitigated by damping factor that doesn't allow the sim to return to > an overcommitted state immediately following a script cull. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091218/6a6cc6c6/attachment.htm From da5idkronfeld at gmail.com Fri Dec 18 10:40:30 2009 From: da5idkronfeld at gmail.com (Da5id Kronfeld) Date: Fri, 18 Dec 2009 10:40:30 -0800 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> Message-ID: <73DEBF84-590B-4205-8952-CDD88487EF81@gmail.com> On 2009-12-18, at 10:13 AM, Kelly Linden wrote: > I'll be honest. I just really don't like the dynamic resource limits idea. It is very neat and interesting in theory, and fun to design and discuss. However I see a lot of value in knowing all my content will continue to work and knowing what content I can use - In knowing that when I buy/rent/lease land as part of that I am buying/renting/leasing a specific amount of resources. I hate the idea of *any* of my content only sometimes working. [ cut ] > That said, I also understand the usage issues here, which mirror closely the more generic web hosting problems. Resource usage patterns aren't equal or consistent over time or space, this is obvious and known and is NOT something we are ignoring. The general solution for web hosting is to over-sell, rely on some rules of averages and be able to move things around to accommodate users. Doing something similar is certainly a possibility, and one I have pushed for. It isn't as trivial as just setting higher numbers - we need to adjust and fix our infrastructure to more optimally assign regions to hosts - but it is certainly not impossible, and indeed such infrastructure changes would benefit everyone regardless. > > Dynamic resource limits are just complicated by nature. They are fluid in some respect, and they change based on time and usage - that is just what it means. Unfortunately it is that nature that makes it hard to plan around and hard to build content for and hard to understand. The system we use needs to be as easy as prim limits are now, where you can see the cost of an object and you can see how much you can support. > > - Kelly I tend to agree. I will also point out that aside from the complicated nature ( and unpredictable behaviour ) that dynamic limits generally imply, there is also the trend toward circumvention that has to be considered. In any system where the opportunity exists, people will find ways to "game" the system. Consider temp prims and the devices that people have devised in order to increase the effective number of prims they can use. I also agree with Kelly's desire for predictable behaviour. Creating a situation in which content may suddenly stop working because of what other content is doing is an invitation to disaster. Non-technical users will not understand ( and shouldn't have to understand ) the way in which things work. My experience is that predictable lower limits are a *much* easier sell then unpredictable higher ones, because they make sense to the masses. If LL wants to explore dynamic resource allocation, then it may be that that could be explored on a smaller scale after script limits are in place on the grid as a whole. It's worth keeping in mind that we already have a system of "(sort of) graceful failure" in that script memory overcommitment leads to paging activity that degrades the sim performance as a whole. This is (mostly) annoying. I can't imagine a situation in which running content stops working arbitrarily (in the eyes of the average user) as being perceived as anything other than a badly broken grid. From sldev at catznip.com Fri Dec 18 10:46:27 2009 From: sldev at catznip.com (Kitty) Date: Fri, 18 Dec 2009 19:46:27 +0100 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <9788aeb10912170417w263e8ddo27a7e26e9d20c246@mail.gmail.com><4B2A423F.2090007@gmail.com> Message-ID: Each time I bring this up it seems quite a few people are unaware and are trying to play memory tricks to save a few bytes here and there when Mono tends to "waste" whole Kb's at a time per script without a way to really tell or optimize for it because there isn't a way to look at the bytecode to see how big each function ends up being. As far as I can tell: - data segments are multiples of 512 bytes (ie a script using 1 global integer variable and one using 50 both use 512 bytes of memory to store them in) - each function (or event handler) is placed on a 512-byte boundary (ie a function with nothing more than llSay(0, "Hello World!"); takes up 512 bytes) It would be helpful to get some kind of (semi-)official confirmation of the above and just how Mono is compiled and how things are laid out in memory and if there are any plans to address it (some padding is always needed but why so much per function?). The data segment alignment isn't that big of a deal but the total amount of memory "wasted" by padding each function to be a multiple of 512 bytes can add up to quite a bit per script. Kitty From sheet.spotter at gmail.com Fri Dec 18 12:06:46 2009 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Fri, 18 Dec 2009 14:06:46 -0600 Subject: [sldev] Efficient use of simulator memory for scripts In-Reply-To: References: <9788aeb10912170417w263e8ddo27a7e26e9d20c246@mail.gmail.com><4B2A423F.2090007@gmail.com> Message-ID: I have two questions that relate to the efficient use of the limited physical memory within the simulator. Firstly, does the server have any existing mechanisms to identify and "unload" scripts that will never execute another line of code? Everyone has likely bought objects that include a floating text script. Many content creators are unaware that it's unnecessary to leave these scripts in the object. Some texture animation scripts and particle scripts are other examples of scripts that only set a prim attribute and then never execute another line of code. Scripts that only have logic in the on_rez or state_entry events will never execute another line of code after returning from these events. Secondly, is the statistics gathering phase of this project able to identify the percentage of scripts or memory that is currently allocated to scripts that will never execute another line of code? Identifying and removing these scripts from the simulator's runtime memory improves on the efficient use of that limited resource. It does not eliminate the need for script/memory limits. Sheet Spotter From dzonatas at gmail.com Fri Dec 18 13:43:36 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Fri, 18 Dec 2009 13:43:36 -0800 Subject: [sldev] [ogpx] Snowglobe on OpenSim grids In-Reply-To: References: <200912042310.19845.eiffel56@gmail.com> <1D2C40C5-4E7C-43B3-A8BE-6D057305BB34@gmail.com> <78f69850912091900w59cd3d86g66556dfbecbadfe4@mail.gmail.com> <20091210133319.GA2419@alinoe.com> <63FAD4F222230A4EA79DE9E8BE6647354DC55508@winxbeus19.exchange.xchg> <4B21ECE0.2010002@gmail.com> Message-ID: <4B2BF788.2070608@gmail.com> Here is the map implemented in C# : http://mono.dzonux.net/file/20091218a.png It works as a "detached window" from the Snowglobe viewer, and this is possible with SNOW-375: https://jira.secondlife.com/browse/SNOW-375 "Detached Communicator: Chat/IM/Contacts windows "thinking outside the box" in a separate process/plugin" I took that a step further than just a language agnostic API to for just chat/IM/Contacts as I also received requests for the minimap/worldmap and saw this thread. It uses HTTP to fetch the textures, so a simple change in the base-URI could support OpenSIM, too. There area REST *like* calls being made, so sim caps are easy to handle also. I say *like* because true RESTful events don't rely on session info and I used session info in order to support both HTTP and HTTPS. I'd imagine it is possible to make a XAML/Silverlight/Moonlight version of this for the web, yet I don't see in particular reason why when the C# script is self-contain and has no file access permissions given -- so it's basically a web application now that could run directly on the web or download run locally, which I think is key. Joshua Bell wrote: > On Thu, Dec 10, 2009 at 10:55 PM, Dzonatas Sol > wrote: > > Wouldn't it be better if the map was a LLMediaPlugin. That way > each map window can be customized to a grid. That would also mean > each grid would load it's own viewer plugin. > > > I would take this one step further: > > The map is a service provided by a grid, or region-domain in VWRAP > parlance. It should have no dependency on the agent domain. It serves > to consume and produce location identifiers into the grid which - > should be URLs, e.g. "given a friend's SLurl, show it on the map", > "generate a SLurl for a location so I can initiate a teleport to it". > > I would posit that this could be implemented entirely as a web page > hosted via a generic web context provider in a viewer - no need for a > specific plugin. The region domain would provide a standardized cap > which is actually a web page a la slurl.com , which > generates URLs the viewer can act on (e.g. to initiate teleport). > > If there does need to be agent domain/region domain interaction (E.g. > "highlight my friends on the map") then there would need to be some > VWRAP-ish negotiation, e.g. the agent domain(s) of your friends > provide caps that you can pass on to the region domain map service. > > From dzonatas at gmail.com Fri Dec 18 14:43:33 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Fri, 18 Dec 2009 14:43:33 -0800 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <20091218123252.GB32194@alinoe.com> References: <9788aeb10912170417w263e8ddo27a7e26e9d20c246@mail.gmail.com> <20091218123252.GB32194@alinoe.com> Message-ID: <4B2C0595.8020803@gmail.com> The way I understand it isn't the way it is and maybe not the way its going to be, yet my vision is simple: Let each avatar 'buy' server memory usage (kind like how they buy land usage now). Guarantee each avatar can have the max memory usage in any sim no matter what condition. If that means the top 50 avatars with the most memory allocation meet up in a single sim, then it should handle it. The way the sims are designed now, it won't handle it with or without those limits as Babbage expressed and how this thread evolves. The only way it could handle it if is simulator become disassociated with CPU affinity such that a single simulator may actually execute across several CPUs/machine/networks all at the same time. Obviously the main limitation here that keeps simulators tied to CPU affinity is physics -- not memory usage. Carlo Wood wrote: > On Thu, Dec 17, 2009 at 07:17:03AM -0500, Qie Niangao wrote: > >> I sense an opportunity for some non-trivial mathematics to be applied >> to optimally setting these limits. >> >> The obviously, horribly wrong approach would be to set a ceiling for >> all script memory use in a region and apportion that to parcel and >> avatar allotments such that no over-allocation could ever occur. This >> would create much lower limits than required for sub-ceiling >> operations almost all the time. >> > > THANK YOU!!! > Finally someone else that understands this :) > From merov at lindenlab.com Fri Dec 18 15:19:30 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Fri, 18 Dec 2009 15:19:30 -0800 Subject: [sldev] Weekly Snowglobe update : build 3064 Message-ID: <78f69850912181519r1e761211i6c7897283e27f7d6@mail.gmail.com> Hi, Short list this week but there are a couple of nice patches in the pipe. Please get those reviewed and get a committer to push your patch up the hill! The list: - SNOW-397: Add a "Sit Here" in pie menu when clicking avatar, always available unless flying. patch by Be Holder, reviewed by Merov. - SNOW-188 (minimap panning) followup: add pan instructions to minimap tool tip. Reviewed by AimeeT. - SNOW-376 Clean up handling of the maximum length of chat messages - SNOW-364 Realign preferences UI elements misalinged by SNOW-93 - SNOW-390 Ping Interpolate Object Position doesn\'t work. Downloads: CYGWIN: http://secondlife.com/developers/opensource/downloads/2009/trunk/3064/Snowglobe_1-3-0-3064_Setup.exe Darwin: http://secondlife.com/developers/opensource/downloads/2009/trunk/3064/Snowglobe_1_3_0_3064_SNOWGLOBETESTBUILD.dmg Linux: http://secondlife.com/developers/opensource/downloads/2009/trunk/3064/Snowglobe-i686-1.3.0.3064.tar.bz2 Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091218/8cedcaa5/attachment.htm From carlo at alinoe.com Fri Dec 18 15:55:39 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 19 Dec 2009 00:55:39 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> Message-ID: <20091218235539.GA25099@alinoe.com> On Fri, Dec 18, 2009 at 10:13:36AM -0800, Kelly Linden wrote: > I place a high value on simplicity.? I want to trivially understand where I am, > how much headroom I have, how close I am to what limits there are.? I don't The swimming pool ----------------- Once upon a time there was a swimming pool that costed $100 per day to run. Every day 100 people came to swim. Of course, they didn't come all at the same time, thank God no! Imagine that... you'd only have 1/100th of the water to swim in! No, sometimes there were a little more and sometimes there were a little less people. Not everyone stayed 24 hours per day, after all. One day, one of the customers complained to the management of the swimming pool, saying "Last Wednesday I could swim in my own lane, but today it's way too crowded to swim! I wish I could see how many people are inside before I pay the entrance fee!" and he looked really mad. Now the manager, Mr.Kelly, was a smart man and he found quickly a solution that everyone would understand, and after which everyone would have precisely the same area to swim in no matter when they would come! He said: Although there come 100 people every day, I think that at the most busy moments of the say I've ever only seen 30 at the same time. That number might be changed a bit, but lets say that's the maximum. Then we can garantee that you have the same area to swim in at every moment by giving you 1/30 of the swimming pool. From now on, even if the pool is EMPTY... or when there are only 3 people like on Sunday mornings, you are not allowed to use more than 1/30 of the swimming pool area. This way we have solved the problem of those griefer school kids too that come here with 100 kids at once, just to obstruct and annoy the other swimmers: as soon as there are really 30 people inside, we close the doors :). And so, everyone was happy-- because now they knew that whenever they came, they would have precisely 1/30 of the swimming pool... Well, except for about 90% of the customers, who were used to having MUCH more space normally, but they were quickly convinced that they only PAID for 1/30 (after all the math was such that nobody could argue here). And yeah, the entrence price remained the same too. One year later the swimming pool was broke. The End -- Carlo Wood From carlo at alinoe.com Fri Dec 18 16:09:23 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 19 Dec 2009 01:09:23 +0100 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: References: <9788aeb10912170417w263e8ddo27a7e26e9d20c246@mail.gmail.com> <20091218123252.GB32194@alinoe.com> Message-ID: <20091219000923.GB25099@alinoe.com> On Fri, Dec 18, 2009 at 04:34:41PM +0100, Marine Kelley wrote: > The script could freeze, slow down, we could have functions and > events to stay aware of how many bytes we have left, but to me the > core issue is that scripts which run out of memory simply endure an > unrecoverable crash. This basic behavior is very wrong in the first > place and must be revised. Imho, the best solution would be to, after selecting the right scripts according to some algorithm [(only from those users that use more than their share, then from those who use the most, then first those scripts that haven't really done anything in a long time and first those that are flagged as volatile (not so important), etc etc etc], and then just stop them (give them no more cpu time) and swap them out to disk. This won't delay the sim since they don't run anymore for a while. It also won't crash any scripts, because they don't get less memory, they are just temporarily stopped. If some attempts to start a NEW script, then you should not start it at all of course, otherwise a griefer could attempt to 'attack' the harddisk space ;). Once the server is less loaded again, using the same algorithm you can reverse the swapping and start scripts again. But well... let me not waste my time any longer. We all know that LL isn't going to change their plans anyway. They never do. -- Carlo Wood From kelly at lindenlab.com Fri Dec 18 16:34:56 2009 From: kelly at lindenlab.com (Kelly Linden) Date: Fri, 18 Dec 2009 16:34:56 -0800 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <20091218235539.GA25099@alinoe.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> Message-ID: Ooooh! I love the completely ridiculous analogy game! Can I play? Carlo manages an apartment complex. After renting apartments for years out to just single families he realizes that significant portions of his building are empty and not being used for significant periods of the day. He can make more money by renting to more people if he can fill up that space. Given holidays, work, school, errands, entertainment etc each family is probably only in their space for 50% of the time. Heck if you consider it on a per room basis and take into account sleeping time, there is even more unused space! So he rents each apartment out to 3 families, which should totally be fine and he continues to charge and allocate the space as if each family had their own apartment. After all there are enough rooms for everyone, for the portion of the time they are probably home. Of *course* this is ridiculous, and of *course* the swimming pool example is ridiculous and of *course* the SL resource problem doesn't directly map to either. Though I think it may be closer to the apartment case than the swimming pool example. When you rent or lease land you aren't buying entrance to a theme park or movie or swimming pool. You are buying space to live or work or whatever. You want to know that your TV will work whenever you want to use it and that your bed will be available to you. The pool owner wants to know that his electricity and pool filtering and water supply aren't tied to factors he can't control, and he wants to know that he can support 30 swimmers whether the club across the street is open or not. However as I have said before I don't think strict allocation of available resources make sense either, because SL isn't an apartment building or a swimming pool. In that very post you replied to I talked about overselling and managing the hosts regions run on to keep regions happy. This I think is a reasonable compromise that allows for a simple to understand system that is easy to work with and plan with but doesn't overly sacrifice available resources. - Kelly On Fri, Dec 18, 2009 at 3:55 PM, Carlo Wood wrote: > On Fri, Dec 18, 2009 at 10:13:36AM -0800, Kelly Linden wrote: > > I place a high value on simplicity. I want to trivially understand where > I am, > > how much headroom I have, how close I am to what limits there are. I > don't > > The swimming pool > ----------------- > > Once upon a time there was a swimming pool that costed $100 per day > to run. Every day 100 people came to swim. Of course, they didn't > come all at the same time, thank God no! Imagine that... you'd only > have 1/100th of the water to swim in! No, sometimes there were > a little more and sometimes there were a little less people. > Not everyone stayed 24 hours per day, after all. > > One day, one of the customers complained to the management of > the swimming pool, saying "Last Wednesday I could swim in my > own lane, but today it's way too crowded to swim! I wish I could > see how many people are inside before I pay the entrance fee!" > and he looked really mad. > > Now the manager, Mr.Kelly, was a smart man and he found quickly > a solution that everyone would understand, and after which everyone > would have precisely the same area to swim in no matter when they > would come! He said: Although there come 100 people every day, > I think that at the most busy moments of the say I've ever > only seen 30 at the same time. That number might be changed a bit, > but lets say that's the maximum. Then we can garantee that you > have the same area to swim in at every moment by giving you > 1/30 of the swimming pool. From now on, even if the pool is > EMPTY... or when there are only 3 people like on Sunday mornings, > you are not allowed to use more than 1/30 of the swimming pool > area. This way we have solved the problem of those griefer > school kids too that come here with 100 kids at once, just to > obstruct and annoy the other swimmers: as soon as there are > really 30 people inside, we close the doors :). > > And so, everyone was happy-- because now they knew that whenever > they came, they would have precisely 1/30 of the swimming pool... > Well, except for about 90% of the customers, who were used to > having MUCH more space normally, but they were quickly convinced > that they only PAID for 1/30 (after all the math was such that > nobody could argue here). And yeah, the entrence price remained > the same too. One year later the swimming pool was broke. > > The End > > -- > Carlo Wood > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091218/68ce1c3b/attachment-0001.htm From dgothly at erotobotics.com Fri Dec 18 16:49:29 2009 From: dgothly at erotobotics.com (Darrius Gothly) Date: Fri, 18 Dec 2009 19:49:29 -0500 Subject: [sldev] Memory Allocation Algorithms and Tools - Script Limits Message-ID: <59EE2AB0FF6B44CE93A16570D95EE2D2@jbh3000> Wandering thru the recent posts on memory and resource allocation schemes, one thing becomes quite clear. There are a ton of different ways to instrument and allocate the resources, but we won't find a good one until such time as we "Consumers" of those resources (meaning script writers) have the proper tools to accurately measure and *also* to take purposeful steps to reduce or eliminate our use of resources period. I've seen proposals that say "we need a full-blown memory management library" .. in LSL? The language that makes BASIC look cryptic? Sorry, not buying it. How about this one instead? New statement: llEnd() - This script is done, dead, finished, kaput, pushing up the daisies .. whatever. All it had is yours again dear Sim. May it rest in peace. The only way to restart it is to manually "Reset" it. As has been mentioned, many of the most common scripts start up, do something that will persist past their lifetime, then stop. But just cuz they stopped doesn't mean they let go their 16KB (or 64KB for MONO). However, if they ended with an llEnd() statement .. no guessing needed there. The infamous "hair example"? Owner selects then "Resets" hair. Every script gets reset and comes alive. Resizer runs .. owner picks proper size and clicks "Done" ... EVERY script goes "llEnd()" End of problem. You now have hair perfectly sized (until your next shape or mood change) and you're not walking around with 200 or 1000 scripts worth of memory usage. Wanna change your hair again? No sweat .. These sorts of simple extensions to the language would give even beginning scripters the ability to write memory efficient (and thus polite) scripts without having to master the art of proper memory pool and cache management. k .. nuff said ... llEnd(); From tigrospottystripes at gmail.com Fri Dec 18 16:49:58 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Fri, 18 Dec 2009 22:49:58 -0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> Message-ID: <4B2C2336.9010809@Gmail.com> Can't the sim code be made multithreaded and have scripts that are using more memory than is avaiable be moved to a sep?rated thread that runs on virtual ram only, so people can have fast memory hogs if there is enough memory left, but if other scripts need it, the memory hogs get downgraded to slower mode and don't use the physical ram, nor get in the way of other things in the sim. ? From tigrospottystripes at gmail.com Fri Dec 18 16:54:03 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Fri, 18 Dec 2009 22:54:03 -0200 Subject: [sldev] Memory Allocation Algorithms and Tools - Script Limits In-Reply-To: <59EE2AB0FF6B44CE93A16570D95EE2D2@jbh3000> References: <59EE2AB0FF6B44CE93A16570D95EE2D2@jbh3000> Message-ID: <4B2C242B.1010202@Gmail.com> just divide by zero? Darrius Gothly escreveu: > Wandering thru the recent posts on memory and resource allocation schemes, > one thing becomes quite clear. There are a ton of different ways to > instrument and allocate the resources, but we won't find a good one until > such time as we "Consumers" of those resources (meaning script writers) have > the proper tools to accurately measure and *also* to take purposeful steps > to reduce or eliminate our use of resources period. > > I've seen proposals that say "we need a full-blown memory management > library" .. in LSL? The language that makes BASIC look cryptic? Sorry, not > buying it. > > How about this one instead? > > New statement: llEnd() - This script is done, dead, finished, kaput, pushing > up the daisies .. whatever. All it had is yours again dear Sim. May it rest > in peace. > > The only way to restart it is to manually "Reset" it. As has been mentioned, > many of the most common scripts start up, do something that will persist > past their lifetime, then stop. But just cuz they stopped doesn't mean they > let go their 16KB (or 64KB for MONO). However, if they ended with an llEnd() > statement .. no guessing needed there. > > The infamous "hair example"? Owner selects then "Resets" hair. Every script > gets reset and comes alive. Resizer runs .. owner picks proper size and > clicks "Done" ... EVERY script goes "llEnd()" End of problem. You now have > hair perfectly sized (until your next shape or mood change) and you're not > walking around with 200 or 1000 scripts worth of memory usage. Wanna change > your hair again? No sweat .. > > These sorts of simple extensions to the language would give even beginning > scripters the ability to write memory efficient (and thus polite) scripts > without having to master the art of proper memory pool and cache management. > > k .. nuff said ... llEnd(); > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From dzonatas at gmail.com Fri Dec 18 17:14:28 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Fri, 18 Dec 2009 17:14:28 -0800 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2C2336.9010809@Gmail.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2C2336.9010809@Gmail.com> Message-ID: <4B2C28F4.2090704@gmail.com> Maybe some way to flag a script as "phantom" like how objects are phantom where they become independent of the phsyics engine and as such the scripts become independent of the the usual simulator loop/affinity. Phantom scripts would not have to be copied from sim to sim. The could exist entirely a server just for phantom scripts. Tigro Spottystripes wrote: > Can't the sim code be made multithreaded and have scripts that are using > more memory than is avaiable be moved to a sep?rated thread that runs on > virtual ram only, so people can have fast memory hogs if there is enough > memory left, but if other scripts need it, the memory hogs get > downgraded to slower mode and don't use the physical ram, nor get in the > way of other things in the sim. ? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From dgothly at erotobotics.com Fri Dec 18 17:16:27 2009 From: dgothly at erotobotics.com (Darrius Gothly) Date: Fri, 18 Dec 2009 20:16:27 -0500 Subject: [sldev] Memory Allocation Algorithms and Tools - Script Limits References: <59EE2AB0FF6B44CE93A16570D95EE2D2@jbh3000> <4B2C242B.1010202@Gmail.com> Message-ID: So what you're saying is .. scripts that crash get taken out of memory? Is that right? Anyone else have solid info or at least empirical data? ----- Original Message ----- From: "Tigro Spottystripes" To: "Darrius Gothly" Cc: "SLDEV" Sent: Friday, December 18, 2009 7:54 PM Subject: Re: [sldev] Memory Allocation Algorithms and Tools - Script Limits > just divide by zero? > > > Darrius Gothly escreveu: >> Wandering thru the recent posts on memory and resource allocation >> schemes, >> one thing becomes quite clear. There are a ton of different ways to >> instrument and allocate the resources, but we won't find a good one until >> such time as we "Consumers" of those resources (meaning script writers) >> have >> the proper tools to accurately measure and *also* to take purposeful >> steps >> to reduce or eliminate our use of resources period. >> >> I've seen proposals that say "we need a full-blown memory management >> library" .. in LSL? The language that makes BASIC look cryptic? Sorry, >> not >> buying it. >> >> How about this one instead? >> >> New statement: llEnd() - This script is done, dead, finished, kaput, >> pushing >> up the daisies .. whatever. All it had is yours again dear Sim. May it >> rest >> in peace. >> >> The only way to restart it is to manually "Reset" it. As has been >> mentioned, >> many of the most common scripts start up, do something that will persist >> past their lifetime, then stop. But just cuz they stopped doesn't mean >> they >> let go their 16KB (or 64KB for MONO). However, if they ended with an >> llEnd() >> statement .. no guessing needed there. >> >> The infamous "hair example"? Owner selects then "Resets" hair. Every >> script >> gets reset and comes alive. Resizer runs .. owner picks proper size and >> clicks "Done" ... EVERY script goes "llEnd()" End of problem. You now >> have >> hair perfectly sized (until your next shape or mood change) and you're >> not >> walking around with 200 or 1000 scripts worth of memory usage. Wanna >> change >> your hair again? No sweat .. >> >> These sorts of simple extensions to the language would give even >> beginning >> scripters the ability to write memory efficient (and thus polite) scripts >> without having to master the art of proper memory pool and cache >> management. >> >> k .. nuff said ... llEnd(); >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > > From missannotoole at yahoo.com Fri Dec 18 17:45:36 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Fri, 18 Dec 2009 17:45:36 -0800 (PST) Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> Message-ID: <697747.95887.qm@web59105.mail.re1.yahoo.com> We could fast forward to the future reality... Now that more people that need to be aware of the issue at hand are aware of this project then over the next year a lot of problematic scripts will be reworked (especially where the new functions are relevant). So by the time script limits are implemented they will no longer be so direly needed. However they are still needed for the edge case and intentional resource abusers. But overall the vast majority will most likely never be affected at all and many new residents acquiring the better scripts may never even know the limits exist. The double plus is that with the limits the system capacity can be better planned and scaled. That reminds me that I need to go delete that box of n number of free scripts that mostly includes junk that won't even run anymore. Elimination of bad examples to go by/learn from would go miles for improving things overall. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091218/1f26db79/attachment.htm From brickrte at hughes.net Fri Dec 18 18:26:50 2009 From: brickrte at hughes.net (Laurence Brickner) Date: Fri, 18 Dec 2009 21:26:50 -0500 Subject: [sldev] More NOOB questions Message-ID: <68311740DFEB4825BA92AAC4ACCD9241@LRBXPS> Yup, it's me again. We got a new release today. What is the normal schedule for the new source to be post on the download page? Also, what's the status of the media api update and documentation or rather where can I look that up myself? Thanks, Larry/Shorahmin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091218/5ad7c387/attachment.htm From morgaine.dinova at googlemail.com Fri Dec 18 23:11:39 2009 From: morgaine.dinova at googlemail.com (Morgaine) Date: Sat, 19 Dec 2009 07:11:39 +0000 Subject: [sldev] Static universal memory limits are operationally non-scalable Message-ID: Defining a single memory limit that applies universally regardless of the equipment on which it is running is operationally non-scalable. A single universal limit implies that the limit cannot be raised as old equipment is replaced with new, until such a moment when *ALL* the old equipment has been replaced with upgraded equipment. As the equipment population N increases and the interval between whole-population upgrades increases with it, the utilization factor of newly installed resources drops to a worst case of 1/N, and an average of N/2N = 1/2 over the upgrade cycle. What this means for the provider is that effective resource costs are double the actual resource costs because 1/2 of resource upgrades are wasted. What it means for the consumer is that available resources lag installed resources for an ever-lengthening period of time as the system grows. The above applies to all resource types that improve as technology improves, not just the memory limits that we are discussing here. Static resource allocation should almost never be used for delivery of dynamic resources, as a matter of principle, because the resulting resource utilization is so poor. Morgaine. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091219/709b398a/attachment-0001.htm From marinekelley at gmail.com Sat Dec 19 03:59:10 2009 From: marinekelley at gmail.com (Marine Kelley) Date: Sat, 19 Dec 2009 12:59:10 +0100 Subject: [sldev] Static universal memory limits are operationally non-scalable In-Reply-To: References: Message-ID: <9e52a8c10912190359h7f263744w1dff151567c0b9dc@mail.gmail.com> In that case you'll start to see scripts crash randomly as soon as they hit the hard limit (which is prone to move unpredictably, according to the number of avatars in the sim and such), scripters will lose faith in the scripting language and stop scripting at all, and eventually leave. That, or they will make sure their scripts never reach the minimum amount of memory they are sure to have at hand, making it de-facto the official fixed limit. Worst case scenario. Or, they will have to call functions to check whether they have enough memory to allocate whatever data they need at any given time, turning the scripts into unmaintainable bloatware. And adding to the bytecode size at the same time, making the scripts get dangerously closer to the memory limits without even writing one more line of useful code. Only scaffolding. Not to mention that we can allocate memory, but not deallocate. An empty string takes more memory than no string at all. Scripts die when they run out of memory, that is a fact. As long as that fact is true, a script must never enter that case, no matter what. Making the limits dynamic essentially tells the scripters "you have X MB of memory available, but not all the time, up to you to make your scripts consume less memory when able". Right. Marine PS : Sorry for the double mail Morgaine, I once again pressed the wrong button. 2009/12/19 Morgaine > Defining a single memory limit that applies universally regardless of the > equipment on which it is running is operationally non-scalable. > > A single universal limit implies that the limit cannot be raised as old > equipment is replaced with new, until such a moment when *ALL* the old > equipment has been replaced with upgraded equipment. As the equipment > population N increases and the interval between whole-population upgrades > increases with it, the utilization factor of newly installed resources drops > to a worst case of 1/N, and an average of N/2N = 1/2 over the upgrade cycle. > > What this means for the provider is that effective resource costs are > double the actual resource costs because 1/2 of resource upgrades are > wasted. What it means for the consumer is that available resources lag > installed resources for an ever-lengthening period of time as the system > grows. > > The above applies to all resource types that improve as technology > improves, not just the memory limits that we are discussing here. > > Static resource allocation should almost never be used for delivery of > dynamic resources, as a matter of principle, because the resulting resource > utilization is so poor. > > Morgaine. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091219/e96a4edd/attachment.htm From carlo at alinoe.com Sat Dec 19 04:07:01 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 19 Dec 2009 13:07:01 +0100 Subject: [sldev] Static universal memory limits are operationally non-scalable In-Reply-To: References: Message-ID: <20091219120701.GA13962@alinoe.com> This is a new argument that comes on top of the argument that in the new system only 10% of the memory resources will be used on average. Indeed, since the memory reserved for avatars is going to be fixed per avatar (so that you can teleport unless the sim is full), it will be impossible to raise that limit in the future. Morgaine puts it more technically, and she's right. It is also for this reason a very bad choice. "64 kilobytes ought to be enough for anybody" -- Bill Gates On Sat, Dec 19, 2009 at 07:11:39AM +0000, Morgaine wrote: > Defining a single memory limit that applies universally regardless of the > equipment on which it is running is operationally non-scalable. > > A single universal limit implies that the limit cannot be raised as old > equipment is replaced with new, until such a moment when ALL the old equipment > has been replaced with upgraded equipment. As the equipment population N > increases and the interval between whole-population upgrades increases with it, > the utilization factor of newly installed resources drops to a worst case of 1/ > N, and an average of N/2N = 1/2 over the upgrade cycle. > > What this means for the provider is that effective resource costs are double > the actual resource costs because 1/2 of resource upgrades are wasted. What it > means for the consumer is that available resources lag installed resources for > an ever-lengthening period of time as the system grows. > > The above applies to all resource types that improve as technology improves, > not just the memory limits that we are discussing here. > > Static resource allocation should almost never be used for delivery of dynamic > resources, as a matter of principle, because the resulting resource utilization > is so poor. > > Morgaine. -- Carlo Wood From carlo at alinoe.com Sat Dec 19 04:09:12 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 19 Dec 2009 13:09:12 +0100 Subject: [sldev] Static universal memory limits are operationally non-scalable In-Reply-To: <20091219120701.GA13962@alinoe.com> References: <20091219120701.GA13962@alinoe.com> Message-ID: <20091219120912.GB13962@alinoe.com> On Sat, Dec 19, 2009 at 01:07:01PM +0100, Carlo Wood wrote: > "64 kilobytes ought to be enough for anybody" -- Bill Gates I guess it was 640 kilobytes :p -- Carlo Wood From marinekelley at gmail.com Sat Dec 19 04:21:25 2009 From: marinekelley at gmail.com (Marine Kelley) Date: Sat, 19 Dec 2009 13:21:25 +0100 Subject: [sldev] Static universal memory limits are operationally non-scalable In-Reply-To: <20091219120912.GB13962@alinoe.com> References: <20091219120701.GA13962@alinoe.com> <20091219120912.GB13962@alinoe.com> Message-ID: <9e52a8c10912190421h66dfad8am682e6a3ffdc3ad0d@mail.gmail.com> I agree that it makes it more difficult and more expensive to scale the system, but when was the last time when LL added available memory to scripts ? When they introduced Mono. I don't see that happening very often, and the cost of introducing Mono was certainly dwarfing the cost of upgrading every server software, which they do on a weekly basis nowadays. Besides, what's the point of making the software scalable if nobody's going to use its capabilities anyway ? That's what happens when the users lose faith in their tool, they just walk away. Let me give you a little parallel with a very concrete example. Suppose you buy a tool for a very specific task. Let's say a frying pan. You are given information about the limits of that pan upfront. Don't heat beyond X degrees or it will deform. That limit is hard, and you can rely on it, your pan has been proven to take it up to X degrees, and is not guaranteed to work well over it. If you need to go beyond X degrees, you buy another, more sturdy (and heavy) frying pan, but you don't try your luck with the first one. Is that data ever going to change ? No. The first frying pan takes it up to X, and that's it. Each task requires the adapted tool. Same for the scripts. If you really need lots of memory for one script, you reserve it upfront, at the very beginning, either by choosing the type of script (LSL or Mono for the time being, but LSL will be left aside eventually), or by calling functions. You do NOT presume that your script is clever enough to restrict itself when memory runs short, it is not. And it will break like your frying pan. Marine 2009/12/19 Carlo Wood > On Sat, Dec 19, 2009 at 01:07:01PM +0100, Carlo Wood wrote: > > "64 kilobytes ought to be enough for anybody" -- Bill Gates > > I guess it was 640 kilobytes :p > > -- > Carlo Wood > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091219/5a0ef4fd/attachment.htm From imaze.rhiano at gmail.com Sat Dec 19 04:56:27 2009 From: imaze.rhiano at gmail.com (Imaze Rhiano) Date: Sat, 19 Dec 2009 14:56:27 +0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2C2336.9010809@Gmail.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2C2336.9010809@Gmail.com> Message-ID: <4B2CCD7B.7000805@gmail.com> This is basically what is happening currently when scripts in SIM are using more memory than SIM have available - it starts swapping memory to file. And because this is slow - it will lead to ebil lag monsters. Problem with "moving scripts that are using more memory available" is problematic - like how you decide what script is using too much memory? And if you can detect - how you decide what scripts from those "bad scripts" are moved to slower "lag" thread? Tigro Spottystripes kirjoitti: > Can't the sim code be made multithreaded and have scripts that are using > more memory than is avaiable be moved to a sep?rated thread that runs on > virtual ram only, so people can have fast memory hogs if there is enough > memory left, but if other scripts need it, the memory hogs get > downgraded to slower mode and don't use the physical ram, nor get in the > way of other things in the sim. ? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From schlenk at uni-oldenburg.de Sat Dec 19 05:15:57 2009 From: schlenk at uni-oldenburg.de (Michael Schlenker) Date: Sat, 19 Dec 2009 14:15:57 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> Message-ID: <1A6A7D7C-4110-425D-A4DB-E67A81F5424C@uni-oldenburg.de> Simplicity has its value, but as Einstein said: As simple as possible, but not simpler. Setting a fixed limit per avatar/parcel makes things easily analyzable and safe, but obviously wastes a huge amount of resources on reserves. It is the perfect solution if you need 100% reliability and can afford the reserve memory to back it up for 'normal' use. It would be really good if LL could provide some insight about the memory use of the servers in general, how much memory is used by scripts, how much is needed for physics, for avatar state, for textures, inventory etc. Script memory might be an easy target, because its very easy to implement a trivial control on VM memory limits, but is it the right target? Probably LL does not yet know what kind of limits would be sane, because they simply do not have any good profiling data about it yet. Takes some time to track and collect the right data. So, in fact there are a few issues here: - LL wants to cut cost and increase utilization of its hardware - Residents want to keep at least the same experience they have now, probably a better one - Scripters want a reliable and working base upon which they can build So, can we eat three cakes and keep all of them? I think LL does a good thing with providing some tools to profile script costs. Not sure if those tools will be worth using, would be nice if some Linden could provide a short description of what kind of metrics we can expect (e.g. useless aggregated data with no timeline as we see it now in the debug panel for estate owners or fine grained profiling info down to individual functions of our scripts. Or maybe a special 'trace' mode for developers which want to analyze there scripts?). If your system does a good job like e.g. DTrace on Solaris or OS X, very good, if it does less, lets see how much less... The second step, to provide more efficient script functions to do common tasks is also a great thing. Long overdue. Lets hope you kill some more warts of the language in the process. (how about some functions to override the built in animations with our own, so we do not need to have silly AOs lag the world while trying to win the race condition against your built in anims? Or how about a real timer queue instead of the simple timer event, where you simply register callback functions to be called at some time in the future (e.g. like Tcl's after command, including something like after idle to run code when the simulator isn't really too busy doing other stuff). Some persistent storage would also be quite nice, as i guess a lot of scripts that need much memory just use it to store data, like logs, messages, but do not really need to have all of it in RAM (or swapped in). But the third step, memory limits and enforcement are the part where you need to be really careful to not create just chaos. Fixed limits are good, in general. They make things really reliable and ease planning, so thats good for both scripters and LL. But the drop in available capacity in the average case for residents makes it a really ugly solution. Works, but will either annoy a lot of residents or LLs cash balance (if they invested for the needed reserves to handle peak utilization gracefully). Is there a reason why we only discuss script memory limits? How about textures, those must eat a lot of memory too? And how about memory sharing techniques? If you bitch about resizer scripts in every prim of a 100 prim hair, why not optimize memory sharing for those? If any of those would need more than about 512 Bytes real modifiable memory it would be just a case for bitching about the bad choice for the mono runtime. Maybe provide a 'const' keyword or some other way to allow more aggressive sharing of script resources and the whole case of 'excessive' amounts of identical scripts would nearly vanish with NO impact for residents or scripters. Might be a bit more complex for the people writing the server code, but well, its easier to higher some qualified people to fix the server code than it is to educated a few thousand scripters and a few million users. Michael Am 18.12.2009 um 19:13 schrieb Kelly Linden: > I'll be honest. I just really don't like the dynamic resource limits idea. It is very neat and interesting in theory, and fun to design and discuss. However I see a lot of value in knowing all my content will continue to work and knowing what content I can use - In knowing that when I buy/rent/lease land as part of that I am buying/renting/leasing a specific amount of resources. I hate the idea of *any* of my content only sometimes working. > > I place a high value on simplicity. I want to trivially understand where I am, how much headroom I have, how close I am to what limits there are. I don't want to code complex solutions with multiple behaviors based on the state of the region. And yes, I know people already do this by monitoring sim stats but it would be awesome if they didn't need to. "normal" residents also need to understand these limits and be able to see where they are. These limits will effect *everyone*, even if all you do is rent a house and buy content to furnish it. You will need to know what will and won't work and buying something that will sometimes work no matter what the reasons is just going to be a nightmare. If I buy a fish tank it needs to always work and always have fish and not have fish that sleep or disappear when my neighbors decide it is chicken shooting time. > > That said, I also understand the usage issues here, which mirror closely the more generic web hosting problems. Resource usage patterns aren't equal or consistent over time or space, this is obvious and known and is NOT something we are ignoring. The general solution for web hosting is to over-sell, rely on some rules of averages and be able to move things around to accommodate users. Doing something similar is certainly a possibility, and one I have pushed for. It isn't as trivial as just setting higher numbers - we need to adjust and fix our infrastructure to more optimally assign regions to hosts - but it is certainly not impossible, and indeed such infrastructure changes would benefit everyone regardless. > > Dynamic resource limits are just complicated by nature. They are fluid in some respect, and they change based on time and usage - that is just what it means. Unfortunately it is that nature that makes it hard to plan around and hard to build content for and hard to understand. The system we use needs to be as easy as prim limits are now, where you can see the cost of an object and you can see how much you can support. > > - Kelly From imaze.rhiano at gmail.com Sat Dec 19 05:24:19 2009 From: imaze.rhiano at gmail.com (Imaze Rhiano) Date: Sat, 19 Dec 2009 15:24:19 +0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> Message-ID: <4B2CD403.6010407@gmail.com> I fully agree with Kelly here. People are buying their parcel to get certain guaranteed amount of primitives and space from virtual world for their use. Same way people want to get certain guaranteed amount of memory for their scripts for their use. They don't want their landlord comes to say that they can use that swimming pool for their activity - but they need to share it with sexists neighbors. No - they want their own private swimming pool. Other fact is that people are stupid. Fixed memory limits would be most easily understood by average Joe and Jane. They really don't want to use their head to calculate how many scripts they can deploy to their parcel before hitting to boundaries. Keep it simple and stupid. However - same time - they should be some configuration available. Landlords should be either able to decide memory limits for each parcel - or - use similar system that allows current double primitive parcels. If this kind configuration is not available- then we will quickly see how landlord convert their current double primitive estates to normal primitive estates and remove all streets and other "community" parcels from their estates. ... and I agree with bloooo kitty that fixed memory limits are not scalable solution - however - Scripted Life (tm) architecture is not scalable anyway - so who cares? :P Kelly Linden kirjoitti: > Ooooh! I love the completely ridiculous analogy game! Can I play? > > Carlo manages an apartment complex. After renting apartments for > years out to just single families he realizes that significant > portions of his building are empty and not being used for significant > periods of the day. He can make more money by renting to more people > if he can fill up that space. Given holidays, work, school, errands, > entertainment etc each family is probably only in their space for 50% > of the time. Heck if you consider it on a per room basis and take > into account sleeping time, there is even more unused space! So he > rents each apartment out to 3 families, which should totally be fine > and he continues to charge and allocate the space as if each family > had their own apartment. After all there are enough rooms for > everyone, for the portion of the time they are probably home. > > Of *course* this is ridiculous, and of *course* the swimming pool > example is ridiculous and of *course* the SL resource problem doesn't > directly map to either. Though I think it may be closer to the > apartment case than the swimming pool example. When you rent or lease > land you aren't buying entrance to a theme park or movie or swimming > pool. You are buying space to live or work or whatever. You want to > know that your TV will work whenever you want to use it and that your > bed will be available to you. The pool owner wants to know that his > electricity and pool filtering and water supply aren't tied to factors > he can't control, and he wants to know that he can support 30 swimmers > whether the club across the street is open or not. > > However as I have said before I don't think strict allocation of > available resources make sense either, because SL isn't an apartment > building or a swimming pool. In that very post you replied to I > talked about overselling and managing the hosts regions run on to keep > regions happy. This I think is a reasonable compromise that allows > for a simple to understand system that is easy to work with and plan > with but doesn't overly sacrifice available resources. > > - Kelly > > On Fri, Dec 18, 2009 at 3:55 PM, Carlo Wood > wrote: > > On Fri, Dec 18, 2009 at 10:13:36AM -0800, Kelly Linden wrote: > > I place a high value on simplicity. I want to trivially > understand where I am, > > how much headroom I have, how close I am to what limits there > are. I don't > > The swimming pool > ----------------- > > Once upon a time there was a swimming pool that costed $100 per day > to run. Every day 100 people came to swim. Of course, they didn't > come all at the same time, thank God no! Imagine that... you'd only > have 1/100th of the water to swim in! No, sometimes there were > a little more and sometimes there were a little less people. > Not everyone stayed 24 hours per day, after all. > > One day, one of the customers complained to the management of > the swimming pool, saying "Last Wednesday I could swim in my > own lane, but today it's way too crowded to swim! I wish I could > see how many people are inside before I pay the entrance fee!" > and he looked really mad. > > Now the manager, Mr.Kelly, was a smart man and he found quickly > a solution that everyone would understand, and after which everyone > would have precisely the same area to swim in no matter when they > would come! He said: Although there come 100 people every day, > I think that at the most busy moments of the say I've ever > only seen 30 at the same time. That number might be changed a bit, > but lets say that's the maximum. Then we can garantee that you > have the same area to swim in at every moment by giving you > 1/30 of the swimming pool. From now on, even if the pool is > EMPTY... or when there are only 3 people like on Sunday mornings, > you are not allowed to use more than 1/30 of the swimming pool > area. This way we have solved the problem of those griefer > school kids too that come here with 100 kids at once, just to > obstruct and annoy the other swimmers: as soon as there are > really 30 people inside, we close the doors :). > > And so, everyone was happy-- because now they knew that whenever > they came, they would have precisely 1/30 of the swimming pool... > Well, except for about 90% of the customers, who were used to > having MUCH more space normally, but they were quickly convinced > that they only PAID for 1/30 (after all the math was such that > nobody could argue here). And yeah, the entrence price remained > the same too. One year later the swimming pool was broke. > > The End > > -- > Carlo Wood > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From charlie.pegwell at btinternet.com Sat Dec 19 06:24:56 2009 From: charlie.pegwell at btinternet.com (Charlie Pegwell) Date: Sat, 19 Dec 2009 14:24:56 +0000 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <1A6A7D7C-4110-425D-A4DB-E67A81F5424C@uni-oldenburg.de> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <1A6A7D7C-4110-425D-A4DB-E67A81F5424C@uni-oldenburg.de> Message-ID: <4B2CE238.4020805@btinternet.com> Hi Everyone, first post for me, although been reading this list for some time :) I now post as I'm obviously missing something in the plans for script limits! Firstly, the plan seems logical to me..... 1. Each parcel has a set limit, we can all see how close to limit we are - Sounds very much like prim limit to me :P 2. Each Avatar has a set limit - Hurrah, no more AV enters sim... sim lags out for some minutes until they go.... So, I fail to see the problem with this.... at least until we really can see the actual usage with the tools.... and then maybe we can argue with added knowledge.... As for dynamic allocations....... If we did that, then why not do same with prim limits ? Heh, this was probably argued before my time.... but clearly we manage ok within the prim limits set, so we can probably cope with script limits per parcel too...... I do have one question, which I may have missed answers to before..... How will a resident who has 23k left in their parcel know which of the 5 different security devices will run without issue on their parcel ? Will we be able to see the memory usage somehow before purchase ? Or will we/they have to rely on an honest vendor who is clearly stating memory use on their packaging ? Thanks for reading, and please don't shoot me down in flames unless you provide a fluffy pillow to land on :) Charlie. From robertltux at gmail.com Sat Dec 19 06:36:18 2009 From: robertltux at gmail.com (Robert Martin) Date: Sat, 19 Dec 2009 09:36:18 -0500 Subject: [sldev] Static universal memory limits are operationally non-scalable In-Reply-To: <9e52a8c10912190421h66dfad8am682e6a3ffdc3ad0d@mail.gmail.com> References: <20091219120701.GA13962@alinoe.com> <20091219120912.GB13962@alinoe.com> <9e52a8c10912190421h66dfad8am682e6a3ffdc3ad0d@mail.gmail.com> Message-ID: As a sidebar to this issue what if LL would identify scripting cases that can be replaced or minimized in memory useage/runtime and then work on doing so just in avatars you have several cases to work with 1 Tinies: have an avatar shape that is say 0.3 meters tall to 1.5 meters tall (yes this will also allow for better child avatars) 2 Quadraped/Digitgrade: have a shape that is 4 footed 3 resize scripts: this can be solved by having a [halt script/done function] 4 bling/particle emitters/type animations: these could be flagged for the first ones to be halted if the sim needs memory 5 translation huds/devices: could somebody please build this into the client an other idea to solve memory problems (and solve a griefing problem at the same time) is if the sim starts getting "tight" then script halt and derez the highest NON parcel/sim owner avatar and all objects owned by this avatar. So if somebody decides to pop in and use some of those rezzer/particle storm objects they and their objects go "poof" but somebody that wants to have a party on their own parcel is "safe". -- Robert L Martin From stickman at gmail.com Sat Dec 19 07:14:16 2009 From: stickman at gmail.com (Stickman) Date: Sat, 19 Dec 2009 07:14:16 -0800 Subject: [sldev] Static universal memory limits are operationally non-scalable In-Reply-To: References: <20091219120701.GA13962@alinoe.com> <20091219120912.GB13962@alinoe.com> <9e52a8c10912190421h66dfad8am682e6a3ffdc3ad0d@mail.gmail.com> Message-ID: On Sat, Dec 19, 2009 at 6:36 AM, Robert Martin wrote: > As a sidebar to this issue what if LL would identify scripting cases > that can be replaced > or minimized in memory useage/runtime and then work on doing so Excellent idea. This is something Babbage specifically asked for, too. > just in avatars you have several cases to work with > 1 Tinies: have an avatar shape that is say 0.3 meters tall to 1.5 > meters tall (yes this will also allow for better child avatars) > 2 Quadraped/Digitgrade: have a shape that is 4 footed The "proper" solution is custom rigging and mesh support. I would rather wait until LL gets around to doing that than receive a halfway solution. > 3 resize scripts: this can be solved by having a [halt script/done function] You can delete a script after it's finished. The new llSetLinkPrimitiveParamsFast() function, if paired with a tiny llSetScriptState() script to shut it down when not needed, would be just as effective. Though I can't really recommend llSetScriptState() unless I know it unloads the memory. I'm not sure how much of a not-running script is stored in memory. If the functions don't work as intended, and it's undesirable to change them (eg, there's a noticeable lag time in reloading the script into memory so it can execute again) then a new function like you're suggesting is assuredly a good idea. > 4 bling/particle emitters/type animations: these could be flagged for > the first ones to be halted > if the sim needs memory Particles are a prim property and are clientside. After setting the particles via script, you can delete the script and the particles will continue to function just fine. Same with texture animation, and I think llTargetOmega()? Or does omega reset on rez? llSetText() is also a prim property -- set it via script and delete the script, and it sticks with the prim. Prim properties have little to no effect on the server, so there's no reason to handle them in this case. But they are certainly a candidate for cleaning up client-side visual lag issues. We've even got a slider for number of simultaneous visible particles in our preferences. > 5 translation huds/devices: could somebody please build this into the client It's in Snowglobe. It and many other things really, really need to be pushed back into the main viewer. I don't know how that's supposed to happen, but some sort of magical process is hopefully in discussion. > is if the sim starts getting "tight" then script halt and derez the > highest NON parcel/sim owner avatar and all objects owned by this > avatar. If the choice is made to stop things, which has been argued against, then stopping and removing things in the order that prims are returned may be a compromise, though will still cause some problems, like the actual prim return does. I'm holding out on saying which method is best, because I don't consider myself very learned on the topic. Until I can see what's going on with these new script management tools we're going to get, I don't want to hedge my brain down one path. Lots of great ideas being said, with good points, and good counter-points. -Stickman From carlo at alinoe.com Sat Dec 19 07:18:11 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 19 Dec 2009 16:18:11 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2CCD7B.7000805@gmail.com> References: <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> Message-ID: <20091219151811.GA25562@alinoe.com> On Sat, Dec 19, 2009 at 02:56:27PM +0200, Imaze Rhiano wrote: > This is basically what is happening currently when scripts in SIM are > using more memory than SIM have available - it starts swapping memory to > file. And because this is slow - it will lead to ebil lag monsters. Huh? Why do you say that it is the same? Seems totally different to me. > Problem with "moving scripts that are using more memory available" is > problematic - like how you decide what script is using too much memory? > And if you can detect - how you decide what scripts from those "bad > scripts" are moved to slower "lag" thread? > > Tigro Spottystripes kirjoitti: > > Can't the sim code be made multithreaded and have scripts that are using > > more memory than is avaiable be moved to a sep?rated thread that runs on > > virtual ram only, so people can have fast memory hogs if there is enough > > memory left, but if other scripts need it, the memory hogs get > > downgraded to slower mode and don't use the physical ram, nor get in the > > way of other things in the sim. ? > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood From carlo at alinoe.com Sat Dec 19 07:34:19 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 19 Dec 2009 16:34:19 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2CD403.6010407@gmail.com> References: <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2CD403.6010407@gmail.com> Message-ID: <20091219153419.GB25562@alinoe.com> On Sat, Dec 19, 2009 at 03:24:19PM +0200, Imaze Rhiano wrote: > I fully agree with Kelly here. That's sad, cause what you're saying is that you agree to pay the same for 1/10 of what you could use before in practise. Sorry, I don't see the logic in that. Considering that the price of a sim will remain the same, this whole thing would only be fair if the amount of memory in every server is increased with a few Gigabytes (without increasing the price thus). > People are buying their parcel to get certain guaranteed amount of > primitives and space from virtual world for their use. Huh?? Why on earth do you think that? I did *NOT* rent my sim to get a "garanteed amount of memory" that is 1/10th of what I can use NOW on average. I did rent the sim for the money it costs BECAUSE it's a fact that normally the other residents are not there; I rented it BECAUSE residents are only 1 to 2 hours per day on the sim and THUS that for that money I get a FULL sim for myself (if I'm alone). I calculated that in. If anyone did not calculate that in and assumed they'd only be getting 1/10th of the server capacity AND only use it 1/10 of the day, then why the hell do they agree to pay a sum that equals renting a real, complete, rack server? No sorry, but LL is just trying to rip us off: let everyone pay for the full rack server, and once this all rolls start to over-sell it by a factor of five (ie, by running all servers virtually on 1/5th of the hardware; that is actually going to work with these new rules). And don't you think that the prices will go down. Imho, this one just another sign that LL understands it's dieing and is just trying to increase it's profits as much as possible before that actually happens. > Same way people > want to get certain guaranteed amount of memory for their scripts for > their use. They don't want their landlord comes to say that they can use > that swimming pool for their activity - but they need to share it with > sexists neighbors. No - they want their own private swimming pool. > > Other fact is that people are stupid. Fixed memory limits would be most > easily understood by average Joe and Jane. They really don't want to use > their head to calculate how many scripts they can deploy to their parcel > before hitting to boundaries. Keep it simple and stupid. Why not apply that reasoning to the physics engine and get rid of it? Nobody understands how you can write realistic vehicles for a reason: it's way to hard (and not really possible to begin with with all the usual lag). That physics engine is only using cpu time, that we have pay for, but it's useless the way it is: Joe and Jane will NEVER be able to write a script that uses it; I certainly have never seen any satisfactory working physical objects beyond a soccer ball. > However - same time - they should be some configuration available. > Landlords should be either able to decide memory limits for each parcel > - or - use similar system that allows current double primitive parcels. > If this kind configuration is not available- then we will quickly see > how landlord convert their current double primitive estates to normal > primitive estates and remove all streets and other "community" parcels > from their estates. > > ... and I agree with bloooo kitty that fixed memory limits are not > scalable solution - however - Scripted Life (tm) architecture is not > scalable anyway - so who cares? :P > > Kelly Linden kirjoitti: > > Ooooh! I love the completely ridiculous analogy game! Can I play? > > > > Carlo manages an apartment complex. After renting apartments for > > years out to just single families he realizes that significant > > portions of his building are empty and not being used for significant > > periods of the day. He can make more money by renting to more people > > if he can fill up that space. Given holidays, work, school, errands, > > entertainment etc each family is probably only in their space for 50% > > of the time. Heck if you consider it on a per room basis and take > > into account sleeping time, there is even more unused space! So he > > rents each apartment out to 3 families, which should totally be fine > > and he continues to charge and allocate the space as if each family > > had their own apartment. After all there are enough rooms for > > everyone, for the portion of the time they are probably home. > > > > Of *course* this is ridiculous, and of *course* the swimming pool > > example is ridiculous and of *course* the SL resource problem doesn't > > directly map to either. Though I think it may be closer to the > > apartment case than the swimming pool example. When you rent or lease > > land you aren't buying entrance to a theme park or movie or swimming > > pool. You are buying space to live or work or whatever. You want to > > know that your TV will work whenever you want to use it and that your > > bed will be available to you. The pool owner wants to know that his > > electricity and pool filtering and water supply aren't tied to factors > > he can't control, and he wants to know that he can support 30 swimmers > > whether the club across the street is open or not. > > > > However as I have said before I don't think strict allocation of > > available resources make sense either, because SL isn't an apartment > > building or a swimming pool. In that very post you replied to I > > talked about overselling and managing the hosts regions run on to keep > > regions happy. This I think is a reasonable compromise that allows > > for a simple to understand system that is easy to work with and plan > > with but doesn't overly sacrifice available resources. > > > > - Kelly > > > > On Fri, Dec 18, 2009 at 3:55 PM, Carlo Wood > > wrote: > > > > On Fri, Dec 18, 2009 at 10:13:36AM -0800, Kelly Linden wrote: > > > I place a high value on simplicity. I want to trivially > > understand where I am, > > > how much headroom I have, how close I am to what limits there > > are. I don't > > > > The swimming pool > > ----------------- > > > > Once upon a time there was a swimming pool that costed $100 per day > > to run. Every day 100 people came to swim. Of course, they didn't > > come all at the same time, thank God no! Imagine that... you'd only > > have 1/100th of the water to swim in! No, sometimes there were > > a little more and sometimes there were a little less people. > > Not everyone stayed 24 hours per day, after all. > > > > One day, one of the customers complained to the management of > > the swimming pool, saying "Last Wednesday I could swim in my > > own lane, but today it's way too crowded to swim! I wish I could > > see how many people are inside before I pay the entrance fee!" > > and he looked really mad. > > > > Now the manager, Mr.Kelly, was a smart man and he found quickly > > a solution that everyone would understand, and after which everyone > > would have precisely the same area to swim in no matter when they > > would come! He said: Although there come 100 people every day, > > I think that at the most busy moments of the say I've ever > > only seen 30 at the same time. That number might be changed a bit, > > but lets say that's the maximum. Then we can garantee that you > > have the same area to swim in at every moment by giving you > > 1/30 of the swimming pool. From now on, even if the pool is > > EMPTY... or when there are only 3 people like on Sunday mornings, > > you are not allowed to use more than 1/30 of the swimming pool > > area. This way we have solved the problem of those griefer > > school kids too that come here with 100 kids at once, just to > > obstruct and annoy the other swimmers: as soon as there are > > really 30 people inside, we close the doors :). > > > > And so, everyone was happy-- because now they knew that whenever > > they came, they would have precisely 1/30 of the swimming pool... > > Well, except for about 90% of the customers, who were used to > > having MUCH more space normally, but they were quickly convinced > > that they only PAID for 1/30 (after all the math was such that > > nobody could argue here). And yeah, the entrence price remained > > the same too. One year later the swimming pool was broke. > > > > The End > > > > -- > > Carlo Wood > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood From lear.cale at gmail.com Sat Dec 19 09:02:17 2009 From: lear.cale at gmail.com (Lear Cale) Date: Sat, 19 Dec 2009 12:02:17 -0500 Subject: [sldev] Static universal memory limits are operationally non-scalable In-Reply-To: References: Message-ID: For parcels, we could have a static limit whose value depends on the server class, which would allow for upscaling per-region. For avatars, the limit would have to be universal to the grid. It could be raised only when lower class servers are retired. I don't see a serious problem here. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091219/cb38deb2/attachment.htm From lear.cale at gmail.com Sat Dec 19 09:27:27 2009 From: lear.cale at gmail.com (Lear Cale) Date: Sat, 19 Dec 2009 12:27:27 -0500 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2CD403.6010407@gmail.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2CD403.6010407@gmail.com> Message-ID: > > I fully agree with Kelly here. > I agree also, if I understand correctly. Today, there's a rather high limit that, if exceeded, causes severe thrashing. Most servers are below that limit, and not thrashing. If the new limits cut in well before that thrashing limit, but also well above typical usage levels, things should be good. The problem is the swimming pool analogy, which is germane, if limited by showing only one side of the issue. However, if the limits are high enough, the hardest-hit residents will be those with the smallest parcels who are relying on very low script usage of their neighbors. Yeah, that'll be a bummer, but as I see it, any solution to this raises more problems than it solves. Another problem is that, given a fixed budget, people will tend to use up that budget. To address this, I suggest we have two levels; when going over the recommended level the parcel tools signal "yellow" but no limiting is in force. The higher limit is enforced. Sure, many will simply ignore the yellow, but many won't, and it'll be a clear signal about what is considered safe and healthy. Those with smaller parcels will be less likely to heed the color; those with larger ones are far more likely to since their impact on the whole is greater -- they're more likely to shoot themselves in the foot, so they'll be more likely to use a trigger guard. It would send a useful message. Argent argues for a bonus for smaller parcels. We should seriously consider allocating the difference between reasonable levels and critical levels to smaller parcels. This bonus could be calculated assuming all 512 parcels -- dividing the total difference by 65536/512 to calculate a per-parcel bonus, applied regardless of parcel size. It would be insignificant for full-region parcels, but substantial for 512's. The bonus might need to be reduced proportionately for parcels smaller than 512, to avoid catastrophic overcommitment in regions with lots of tiny parcels. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091219/c71420b6/attachment.htm From tigrospottystripes at gmail.com Sat Dec 19 09:46:29 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sat, 19 Dec 2009 15:46:29 -0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2CCD7B.7000805@gmail.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> Message-ID: <4B2D1175.6090601@Gmail.com> Scripts that individually are using more memory than the maximum guaranteed, and scripts that have been added after enough scripts with the minimum guaranteed have already been added tot he parcel go to the separated slow mode. Scripts in the slow mode that are using the least memory bellow the maximum guranteed have priority for being upgraded back to fast mode when enough memory for it has been released in the parcel. Imaze Rhiano escreveu: > This is basically what is happening currently when scripts in SIM are > using more memory than SIM have available - it starts swapping memory > to file. And because this is slow - it will lead to ebil lag monsters. > > Problem with "moving scripts that are using more memory available" is > problematic - like how you decide what script is using too much > memory? And if you can detect - how you decide what scripts from those > "bad scripts" are moved to slower "lag" thread? > > Tigro Spottystripes kirjoitti: >> Can't the sim code be made multithreaded and have scripts that are using >> more memory than is avaiable be moved to a sep?rated thread that runs on >> virtual ram only, so people can have fast memory hogs if there is enough >> memory left, but if other scripts need it, the memory hogs get >> downgraded to slower mode and don't use the physical ram, nor get in the >> way of other things in the sim. ? >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > From tigrospottystripes at gmail.com Sat Dec 19 10:08:03 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sat, 19 Dec 2009 16:08:03 -0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> Message-ID: <4B2D1683.7080609@Gmail.com> This would be a mostly ideal solution since no script would stop working, and scripts that currently lag everything (either due to the scripter coding it to use lots of memory, or due to people placing more scripts in the parcel than the RAM quota of the parcel) would only lag each other, and when memory is freed scripts would once again be promoted back to fast mode. Ideally scripts by parcel owner would have priority over scripts from visitors in regards to RAM usage. If the parcels in the rest of the sim aren't needing the memory, more RAM is avaiable to the parcel at the moment, and more scripts in that parcel can be using RAM, same thing with avatars. If scripts on an avatar are using more memory than is avaiable on the sim, beyond the maximum guaranteed per avatar, some of the scripts will be downgraded to slowmode, like with parcel scripts, the scripts that use more memory and the scripts that came in last after the maximum guaranteed has been used up get downgraded first. If someone wants to have all the scripts on their avatar never be downgraded, they should make sure they never get past the maximum guaranteed RAM quota per avatar. But there won't be need to worry about scripts crashing or objects de-rezzing due to lack of memory. Both scripts and users hsould be capable of checking how much memory is avvaiable int he sim, int he parcel,a nd for their own avatar, and the maximum guaranteed for parcels and sims would just be dependent on some simple value, like maximum allowed primcount, a value that would usually be static inmost places, but not fixed since in some places people can use more prims than in other places (opem space sims, parcels with prim bonus etc), the maximum per avatar would depend on sim type and the maximum number of avs in the sim. Ideally all the info woud be easy for both scritps and users to find, though even though it is less ideal, it would still be reasonably acceptable if the general guidelines to calculating the value were made avaiable instead of the actual values in each situation. Lear Cale escreveu: > While it's a good idea in theory, I doubt that's practical to > implement at this time. > > Also, it has the problem of hysteresis: you get different results > depending on the order in which things happen. That usually leads to > unpredicted issues. > > On Sat, Dec 19, 2009 at 12:46 PM, Tigro Spottystripes > > > wrote: > > Scripts that individually are using more memory than the maximum > guaranteed, and scripts that have been added after enough scripts with > the minimum guaranteed have already been added tot he parcel go to the > separated slow mode. Scripts in the slow mode that are using the least > memory bellow the maximum guranteed have priority for being upgraded > back to fast mode when enough memory for it has been released in > the parcel. > From tigrospottystripes at gmail.com Sat Dec 19 10:11:23 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sat, 19 Dec 2009 16:11:23 -0200 Subject: [sldev] Static universal memory limits are operationally non-scalable In-Reply-To: References: <20091219120701.GA13962@alinoe.com> <20091219120912.GB13962@alinoe.com> <9e52a8c10912190421h66dfad8am682e6a3ffdc3ad0d@mail.gmail.com> Message-ID: <4B2D174B.90304@Gmail.com> Digitgrade is somthing completly different from quadruped... Robert Martin escreveu: > As a sidebar to this issue what if LL would identify scripting cases > that can be replaced > or minimized in memory useage/runtime and then work on doing so > > just in avatars you have several cases to work with > 1 Tinies: have an avatar shape that is say 0.3 meters tall to 1.5 > meters tall (yes this will also allow for better child avatars) > 2 Quadraped/Digitgrade: have a shape that is 4 footed > 3 resize scripts: this can be solved by having a [halt script/done function] > 4 bling/particle emitters/type animations: these could be flagged for > the first ones to be halted > if the sim needs memory > 5 translation huds/devices: could somebody please build this into the client > > > an other idea to solve memory problems (and solve a griefing problem > at the same time) > is if the sim starts getting "tight" then script halt and derez the > highest NON parcel/sim owner avatar and all objects owned by this > avatar. > So if somebody decides to pop in and use some of those rezzer/particle > storm objects they and their objects go "poof" but somebody that wants > to have a party on their own parcel is "safe". > From carlo at alinoe.com Sat Dec 19 10:40:13 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 19 Dec 2009 19:40:13 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2CD403.6010407@gmail.com> Message-ID: <20091219184013.GA1510@alinoe.com> On Sat, Dec 19, 2009 at 12:27:27PM -0500, Lear Cale wrote: > Argent argues for a bonus for smaller parcels. We should seriously consider > allocating the difference between reasonable levels and critical levels to > smaller parcels. This bonus could be calculated assuming all 512 parcels -- > dividing the total difference by 65536/512 to calculate a per-parcel bonus, > applied regardless of parcel size. It would be insignificant for full-region > parcels, but substantial for 512's. The bonus might need to be reduced > proportionately for parcels smaller than 512, to avoid catastrophic > overcommitment in regions with lots of tiny parcels. That kind of reasoning might be relevant for mainland, but I'd have nothing of it for private sims. It should be the region owner who decides how to devide the resources. I guess that the limits will be activated at least a year before necessary tools for sim owners though... I hope that there will be some way to turn as much of the effect of limits off, by the Estate Managers, if they want to do so. Even with "tricks" (but I guess even with that LL won't be willing to help). It seems that there will be some kind of bonus system, so hopefully I can use that to give every parcel the right to use all available memory... then we'll only loose the memory of the 20 avatars with maximum attachment scripts that are never ever ever ever ever there. -- Carlo Wood From tigrospottystripes at gmail.com Sat Dec 19 10:49:53 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sat, 19 Dec 2009 16:49:53 -0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <20091219184013.GA1510@alinoe.com> References: <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2CD403.6010407@gmail.com> <20091219184013.GA1510@alinoe.com> Message-ID: <4B2D2051.5000708@Gmail.com> a perparcel bonus could be abused by spliting your parcel into a bunch of small ones.... Carlo Wood escreveu: > On Sat, Dec 19, 2009 at 12:27:27PM -0500, Lear Cale wrote: > >> Argent argues for a bonus for smaller parcels. We should seriously consider >> allocating the difference between reasonable levels and critical levels to >> smaller parcels. This bonus could be calculated assuming all 512 parcels -- >> dividing the total difference by 65536/512 to calculate a per-parcel bonus, >> applied regardless of parcel size. It would be insignificant for full-region >> parcels, but substantial for 512's. The bonus might need to be reduced >> proportionately for parcels smaller than 512, to avoid catastrophic >> overcommitment in regions with lots of tiny parcels. >> > > That kind of reasoning might be relevant for mainland, but I'd > have nothing of it for private sims. It should be the region owner > who decides how to devide the resources. > > I guess that the limits will be activated at least a year before > necessary tools for sim owners though... > > I hope that there will be some way to turn as much of the effect of > limits off, by the Estate Managers, if they want to do so. Even with > "tricks" (but I guess even with that LL won't be willing to help). > > It seems that there will be some kind of bonus system, so hopefully > I can use that to give every parcel the right to use all available > memory... then we'll only loose the memory of the 20 avatars with > maximum attachment scripts that are never ever ever ever ever there. > > From lear.cale at gmail.com Sat Dec 19 10:54:44 2009 From: lear.cale at gmail.com (Lear Cale) Date: Sat, 19 Dec 2009 13:54:44 -0500 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <20091219184013.GA1510@alinoe.com> References: <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2CD403.6010407@gmail.com> <20091219184013.GA1510@alinoe.com> Message-ID: Keep in mind that script memory is per server, not per region, so it's not up to a region owner to decide what the safe limit is for the region: they shouldn't be able to overallocate and hose the regions that share the server. However, if LL wants to give Region owners the ability to adjust the policy without going over the region's allotment, fine. On Sat, Dec 19, 2009 at 1:40 PM, Carlo Wood wrote: > On Sat, Dec 19, 2009 at 12:27:27PM -0500, Lear Cale wrote: > > Argent argues for a bonus for smaller parcels. We should seriously > consider > > allocating the difference between reasonable levels and critical levels > to > > smaller parcels. This bonus could be calculated assuming all 512 parcels > -- > > dividing the total difference by 65536/512 to calculate a per-parcel > bonus, > > applied regardless of parcel size. It would be insignificant for > full-region > > parcels, but substantial for 512's. The bonus might need to be reduced > > proportionately for parcels smaller than 512, to avoid catastrophic > > overcommitment in regions with lots of tiny parcels. > > That kind of reasoning might be relevant for mainland, but I'd > have nothing of it for private sims. It should be the region owner > who decides how to devide the resources. > > I guess that the limits will be activated at least a year before > necessary tools for sim owners though... > > I hope that there will be some way to turn as much of the effect of > limits off, by the Estate Managers, if they want to do so. Even with > "tricks" (but I guess even with that LL won't be willing to help). > > It seems that there will be some kind of bonus system, so hopefully > I can use that to give every parcel the right to use all available > memory... then we'll only loose the memory of the 20 avatars with > maximum attachment scripts that are never ever ever ever ever there. > > -- > Carlo Wood > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091219/aa04bfcd/attachment.htm From secret.argent at gmail.com Sat Dec 19 13:21:14 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 19 Dec 2009 15:21:14 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> References: <4B28E68C.8000503@gmail.com> <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> Message-ID: On 2009-12-18, at 06:10, Aleric Inglewood wrote: > Under the new system, only 10 chickens could be rezzed at any > time, because it keeps a reserve reserved for each and every > resident, just in case they might suddenly want to play this > game all at the same time in their own parcel (nonsense thus, > which is why this proposed system is so bad). > Your solution doesn't work either however: In your case I would > start rezzing chickens, and when I rez chicken 76, suddenly > the limits would kick in full force and 66 chickens would die, > only leaving 10 to run free. At that moment we'd be under the > 75% again though, so my chicken rez object would start creating > new chickens again, until it again rezzes the 76th chicken... And your customers would complain, so you'd add code to check how close the sim was to triggering the soft limit, and all would be good. From secret.argent at gmail.com Sat Dec 19 13:24:29 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 19 Dec 2009 15:24:29 -0600 Subject: [sldev] Another thought on soft/hard limits... In-Reply-To: <8338B0826978456F9FFA68B5D0DC2577@jbh3000> References: <1e01733d0912160759m70995264o78df9629ed55784@mail.gmail.com> <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <9bb32d430912170649l3165191jb00924397ae8245d@mail.gmail.com> <4B2A4A03.5090203@Gmail.com><9bb32d430912170717q7bb7b416r3ecde1ae3ebd9c02@mail.gmail.com><4B2A9FD5.3050708@superliminal.com> <4B2AA4E0.1030200@Gmail.com><4B2AC66D.2070205@superliminal.com> <4B2B49AD.6050500@Gmail.com> <7DE6A8C5-D5B0-4B31-9AB5-361DC1B3EAF6@gmail.com> <8338B0826978456F9FFA68B5D0DC2577@jbh3000> Message-ID: On 2009-12-18, at 06:54, Darrius Gothly wrote: > It really doesn't matter how the limits are set, the real thrust of > these ideas is that a Sim is not always equally loaded. Because of > visiting patterns of the residents and guests, at any one time the > population on the sim is concentrated .. usually in one parcel. When > the other parcels are empty, that one should get to use all > available SIM resources. When others come back into their own > parcel, they can reclaim what's "theirs" just by entering (and using > some formula yet to work out). > > If this is what you're saying then yes, I agree 100%. I don't know about 100%, but they should be able to use more than a strict fraction of the available resources. This shouldn't depend on who's in the parcel, or the sim, because SL is a world of scripts as well as people, and if you're not using more than your "hard limit" of resources you should be able to continue doing so, whether you're there or not. From secret.argent at gmail.com Sat Dec 19 13:39:11 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 19 Dec 2009 15:39:11 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> Message-ID: <95F0BA8B-CDD8-42C6-9CE6-BF78E6AEA774@gmail.com> On 2009-12-18, at 12:13, Kelly Linden wrote: > I'll be honest. I just really don't like the dynamic resource > limits idea. It is very neat and interesting in theory, and fun to > design and discuss. However I see a lot of value in knowing all my > content will continue to work and knowing what content I can use - > In knowing that when I buy/rent/lease land as part of that I am > buying/renting/leasing a specific amount of resources. I hate the > idea of *any* of my content only sometimes working. I understand that, but on the other hand most parcels on most sims have negligible numbers of scripts in them. If the hard and soft limits are well defined and it's easy to see if you're over the committed limit, it shouldn't be a problem. This gives you the advantages of overselling, with a fallback if you your sim really is pushing the limits. From imaze.rhiano at gmail.com Sat Dec 19 14:14:37 2009 From: imaze.rhiano at gmail.com (Imaze Rhiano) Date: Sun, 20 Dec 2009 00:14:37 +0200 Subject: [sldev] Script/Parcel/Memory Limits - Selling objects that are containing scripts in future? In-Reply-To: <4B2CE238.4020805@btinternet.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <1A6A7D7C-4110-425D-A4DB-E67A81F5424C@uni-oldenburg.de> <4B2CE238.4020805@btinternet.com> Message-ID: <4B2D504D.1010707@gmail.com> Charlie Pegwell kirjoitti: > So, I fail to see the problem with this.... at least until we really can > see the actual usage with the tools.... and then maybe we can argue with > added knowledge.... > > As for dynamic allocations....... If we did that, then why not do same > with prim limits ? Heh, this was probably argued before my time.... > but clearly we manage ok within the prim limits set, so we can probably > cope with script limits per parcel too...... > Ya! That is interesting question. I guess people have used to fixed primitive limits - but not yet used to thinking about fixed memory. > I do have one question, which I may have missed answers to before..... > How will a resident who has 23k left in their parcel know which of the 5 > different security devices will run without issue on their parcel ? > Will we be able to see the memory usage somehow before purchase ? Or > will we/they have to rely on an honest vendor who is clearly stating > memory use on their packaging ? > > And that is REALLY good question! Currently how primitive counts checking is done is that honest vendors allow us to count primitives by previewing their goods. For example in good furniture shop, furnitures are available for viewing and testing - and counting primitives is easy then. However, in proposed system it is not possible to see how many bytes of memory furniture is using in shop (or any object owned by another resident). Either we need new permission for objects "allow anyone to see memory usage" or some kind parcel setting that allows anyone to see objects memory usage. Also xstreet and other out-of-world marketplaces need to update their systems so that vendors can list their products memory usage. > Thanks for reading, and please don't shoot me down in flames unless you > provide a fluffy pillow to land on :) > > Flames? EEEK! I was prepared to poison/chemical/biological attack. I don't think that wearing latex catsuit and gasmask is good idea then... From tigrospottystripes at gmail.com Sat Dec 19 14:22:52 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sat, 19 Dec 2009 20:22:52 -0200 Subject: [sldev] Script/Parcel/Memory Limits - Selling objects that are containing scripts in future? In-Reply-To: <4B2D504D.1010707@gmail.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <1A6A7D7C-4110-425D-A4DB-E67A81F5424C@uni-oldenburg.de> <4B2CE238.4020805@btinternet.com> <4B2D504D.1010707@gmail.com> Message-ID: <4B2D523C.50107@Gmail.com> I don't see any reason memory usage would need to be private, prim count isn't. Not all vendor and webmalls list things like prim count in an specific field, do they? Sellers that want to brag about their products' memory usage (or just be honest) can simply write it in the product description in cases where there isn't an specific field for it. Though inworld venders that rez the product for browsing might not have the rezzed product fully working, specially in cases where it's just for display and not trying it out (some stores might be trying to save sim resources to all the vendors they have in place and have the products deactivated ont he vendors that do display the product live) Imaze Rhiano escreveu: > Charlie Pegwell kirjoitti: > >> So, I fail to see the problem with this.... at least until we really can >> see the actual usage with the tools.... and then maybe we can argue with >> added knowledge.... >> >> As for dynamic allocations....... If we did that, then why not do same >> with prim limits ? Heh, this was probably argued before my time.... >> but clearly we manage ok within the prim limits set, so we can probably >> cope with script limits per parcel too...... >> >> > Ya! That is interesting question. I guess people have used to fixed > primitive limits - but not yet used to thinking about fixed memory. > >> I do have one question, which I may have missed answers to before..... >> How will a resident who has 23k left in their parcel know which of the 5 >> different security devices will run without issue on their parcel ? >> Will we be able to see the memory usage somehow before purchase ? Or >> will we/they have to rely on an honest vendor who is clearly stating >> memory use on their packaging ? >> >> >> > And that is REALLY good question! Currently how primitive counts > checking is done is that honest vendors allow us to count primitives by > previewing their goods. For example in good furniture shop, furnitures > are available for viewing and testing - and counting primitives is easy > then. However, in proposed system it is not possible to see how many > bytes of memory furniture is using in shop (or any object owned by > another resident). > > Either we need new permission for objects "allow anyone to see memory > usage" or some kind parcel setting that allows anyone to see objects > memory usage. Also xstreet and other out-of-world marketplaces need to > update their systems so that vendors can list their products memory usage. > > >> Thanks for reading, and please don't shoot me down in flames unless you >> provide a fluffy pillow to land on :) >> >> >> > Flames? EEEK! I was prepared to poison/chemical/biological attack. I > don't think that wearing latex catsuit and gasmask is good idea then... > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From dgothly at erotobotics.com Sat Dec 19 16:06:57 2009 From: dgothly at erotobotics.com (Darrius Gothly) Date: Sat, 19 Dec 2009 19:06:57 -0500 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory Message-ID: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> Suggestion: A "Bidding System" for allocating memory resources on a Sim. When a script attempts to load and needs to allocate a chunk of memory, it places a "bid" for that amount of memory. If the amount it needs is freely available, the bid is filled and the script runs as expected. However, if the amount of memory is not freely available (meaning the Sim is currently at max for script memory), this forces an "Auction". All scripts currently on the Sim must place a bid for the amount of memory requested. The "price" of their bid is calculated based on their current parcel's memory usage relative to its maximum usage (expressed as a percentage such that a maxxed out parcel would return 0%, a totally unused parcel would return 100%, and an overlimit parcel would return a negative percentage) and the size of their parcel in sqm. I'm sure there's some multiplier there that would assure even small parcels that have used virtually none of their resources always bid a higher price than other parcels that are near their limit. In this system, even Avatar attachment scripts would "bid" accordingly. There could be an additional multiplier applied to the Avatar's bid price to assure they get slightly higher advantage in the auction though. After all, Sims tend to be pretty static with respect to how many scripts are running .. when you count only the scripts in objects on the Sim. When you toss in the variable of Avatars and their attachments, that's when things start varying wildly. The last issue is .. what happens to the "losers" in the auction? My best suggestion is they get "checkpointed" .. swapped out and put in stasis until such time as they can win another auction. As memory is released (like when an Avatar leaves a Sim) the memory freed up could be placed at auction, and only checkpointed scripts allowed to bid. From dgothly at erotobotics.com Sat Dec 19 16:13:06 2009 From: dgothly at erotobotics.com (Darrius Gothly) Date: Sat, 19 Dec 2009 19:13:06 -0500 Subject: [sldev] Script/Parcel/Memory Limits - Selling objects that are containing scripts in future? References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <1A6A7D7C-4110-425D-A4DB-E67A81F5424C@uni-oldenburg.de><4B2CE238.4020805@btinternet.com> <4B2D504D.1010707@gmail.com> Message-ID: Umm .. is the memory usage a "Secret Number" that you should keep hidden? I would think (hope) not. ----- Original Message ----- From: "Imaze Rhiano" > And that is REALLY good question! Currently how primitive counts > checking is done is that honest vendors allow us to count primitives by > previewing their goods. For example in good furniture shop, furnitures > are available for viewing and testing - and counting primitives is easy > then. However, in proposed system it is not possible to see how many > bytes of memory furniture is using in shop (or any object owned by > another resident). From adam at deepthink.com.au Sat Dec 19 16:15:54 2009 From: adam at deepthink.com.au (Frisby, Adam) Date: Sat, 19 Dec 2009 19:15:54 -0500 Subject: [sldev] Script/Parcel/Memory Limits - Selling objects that are containing scripts in future? In-Reply-To: References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170001q2d90bab6x9dbf408a0bc009d0@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <1A6A7D7C-4110-425D-A4DB-E67A81F5424C@uni-oldenburg.de><4B2CE238.4020805@btinternet.com> <4B2D504D.1010707@gmail.com> Message-ID: <63FAD4F222230A4EA79DE9E8BE6647354DC562B7@winxbeus19.exchange.xchg> I personally suggest you look at something akin to a "Maximum Memory Usage" property attached to the inventory item. Scripts can only request up to a maximum of that property - customers can then inspect that property to find out what the maximum use is going to be. Of course, it won't be perfect - objects rezzing other objects could use more memory; but the same goes for prim counts right now. Adam > -----Original Message----- > From: sldev-bounces at lists.secondlife.com [mailto:sldev- > bounces at lists.secondlife.com] On Behalf Of Darrius Gothly > Sent: Saturday, 19 December 2009 4:13 PM > To: Imaze Rhiano; Sldev List > Subject: Re: [sldev] Script/Parcel/Memory Limits - Selling objects that > are containing scripts in future? > > Umm .. is the memory usage a "Secret Number" that you should keep > hidden? I > would think (hope) not. > > ----- Original Message ----- > From: "Imaze Rhiano" > > > And that is REALLY good question! Currently how primitive counts > > checking is done is that honest vendors allow us to count primitives > by > > previewing their goods. For example in good furniture shop, > furnitures > > are available for viewing and testing - and counting primitives is > easy > > then. However, in proposed system it is not possible to see how many > > bytes of memory furniture is using in shop (or any object owned by > > another resident). > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From carlo at alinoe.com Sat Dec 19 16:32:37 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 20 Dec 2009 01:32:37 +0100 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory In-Reply-To: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> Message-ID: <20091220003237.GA18035@alinoe.com> There are two problems to be solved: 1) Which script to put "in stasis" (I like that expression) 2) What do with scripts that run and then have to stop. The answer to 2 being "put them in statis". Your bidding system could be solved with a simple priority queue I'd think... I don't think that "bidding" is a good word for it, but the idea to make the priorities equal to inverse of the percentage used of their "rightful" share should work indeed. On Sat, Dec 19, 2009 at 07:06:57PM -0500, Darrius Gothly wrote: > Suggestion: A "Bidding System" for allocating memory resources on a Sim. > > When a script attempts to load and needs to allocate a chunk of memory, it > places a "bid" for that amount of memory. If the amount it needs is freely > available, the bid is filled and the script runs as expected. > > However, if the amount of memory is not freely available (meaning the Sim is > currently at max for script memory), this forces an "Auction". All scripts > currently on the Sim must place a bid for the amount of memory requested. > The "price" of their bid is calculated based on their current parcel's > memory usage relative to its maximum usage (expressed as a percentage such > that a maxxed out parcel would return 0%, a totally unused parcel would > return 100%, and an overlimit parcel would return a negative percentage) and > the size of their parcel in sqm. I'm sure there's some multiplier there that > would assure even small parcels that have used virtually none of their > resources always bid a higher price than other parcels that are near their > limit. > > In this system, even Avatar attachment scripts would "bid" accordingly. > There could be an additional multiplier applied to the Avatar's bid price to > assure they get slightly higher advantage in the auction though. > > After all, Sims tend to be pretty static with respect to how many scripts > are running .. when you count only the scripts in objects on the Sim. When > you toss in the variable of Avatars and their attachments, that's when > things start varying wildly. > > The last issue is .. what happens to the "losers" in the auction? My best > suggestion is they get "checkpointed" .. swapped out and put in stasis until > such time as they can win another auction. As memory is released (like when > an Avatar leaves a Sim) the memory freed up could be placed at auction, and > only checkpointed scripts allowed to bid. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood From tigrospottystripes at gmail.com Sat Dec 19 16:43:47 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sat, 19 Dec 2009 22:43:47 -0200 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory In-Reply-To: <20091220003237.GA18035@alinoe.com> References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> <20091220003237.GA18035@alinoe.com> Message-ID: <4B2D7343.4060706@Gmail.com> Would it be too hard to instead of true stasis the scripts were just transfered into a separated thread that has less priority, runs only when the is some idle time on the processor or somthing (including using cheaper hardware and nto getting in the way of other stuff), so scripts can continue to work? (either way the event that gets triggered when a script is about to get downgraded would still be great to have) Carlo Wood escreveu: > There are two problems to be solved: > > 1) Which script to put "in stasis" (I like that expression) > 2) What do with scripts that run and then have to stop. > > The answer to 2 being "put them in statis". > > Your bidding system could be solved with a simple priority queue > I'd think... I don't think that "bidding" is a good word for it, > but the idea to make the priorities equal to inverse of the percentage > used of their "rightful" share should work indeed. > > On Sat, Dec 19, 2009 at 07:06:57PM -0500, Darrius Gothly wrote: > >> Suggestion: A "Bidding System" for allocating memory resources on a Sim. >> >> When a script attempts to load and needs to allocate a chunk of memory, it >> places a "bid" for that amount of memory. If the amount it needs is freely >> available, the bid is filled and the script runs as expected. >> >> However, if the amount of memory is not freely available (meaning the Sim is >> currently at max for script memory), this forces an "Auction". All scripts >> currently on the Sim must place a bid for the amount of memory requested. >> The "price" of their bid is calculated based on their current parcel's >> memory usage relative to its maximum usage (expressed as a percentage such >> that a maxxed out parcel would return 0%, a totally unused parcel would >> return 100%, and an overlimit parcel would return a negative percentage) and >> the size of their parcel in sqm. I'm sure there's some multiplier there that >> would assure even small parcels that have used virtually none of their >> resources always bid a higher price than other parcels that are near their >> limit. >> >> In this system, even Avatar attachment scripts would "bid" accordingly. >> There could be an additional multiplier applied to the Avatar's bid price to >> assure they get slightly higher advantage in the auction though. >> >> After all, Sims tend to be pretty static with respect to how many scripts >> are running .. when you count only the scripts in objects on the Sim. When >> you toss in the variable of Avatars and their attachments, that's when >> things start varying wildly. >> >> The last issue is .. what happens to the "losers" in the auction? My best >> suggestion is they get "checkpointed" .. swapped out and put in stasis until >> such time as they can win another auction. As memory is released (like when >> an Avatar leaves a Sim) the memory freed up could be placed at auction, and >> only checkpointed scripts allowed to bid. >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > > From ilana.debevec at gmail.com Sat Dec 19 16:54:51 2009 From: ilana.debevec at gmail.com (Ilana Debevec) Date: Sat, 19 Dec 2009 17:54:51 -0700 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <20091219000923.GB25099@alinoe.com> References: <9788aeb10912170417w263e8ddo27a7e26e9d20c246@mail.gmail.com> <20091218123252.GB32194@alinoe.com> <20091219000923.GB25099@alinoe.com> Message-ID: <690eba40912191654o6021dee8o524d471d2d734653@mail.gmail.com> I've been watching the conversation for a while and have a few thoughts on the whole thing from a non-pro view. We make .. er.. specialized furniture and because of it's 'special', they may have more scripts than some would. We've spend the last 3 month tweaking, slashing, compacting, re-writing and trying to combine/enhance/streamline our script base. Most of the comments seem to be directed toward avatar attachments, but if you limit things based on the avatar, what about, let's say a store where you have a LOT of things out on display, all scripted.. will it be necessary to have a dozen alts to 'own' the displays? How about vendors? Some have done some great work in getting their script count down, some not. Another thought, the new functions Babbage has talked about are a good start to eliminate excess scripts, but from what's been mentioned, some more REALLY would make things a bit easier. #1 llLinkParticleSystem() - this really should be a priority to add, there are lots and lots of things our there with multiple setups for particle effects. We do custom basr that hav some particle lighting effects, 1 script per prim for where they come from. Could drop 6-10 scripts right there. And for our furniture, guaranteed elimination of 4-15 scripts per piece (see: Lockmeister system). #2 llEndScript() - oh yes, please.Now let's add in the option maybe to llEndScript(string script_name) and llStartScript(string script_name) so that you can 'turn them on/off' with a single controlling script and not have to turn EVERYTHING on with a 'Reset Scripts' from the client menu (sometimes yes, you need a sledgehammer, some times you need a small gentle tap. #3 Speaking of sledgehammers vs the gentle tap, llGetLinkPrimitiveParamters() absolutely yes, but how about some 'precision functions'.. llGetLinkAlpha() for example.. let's say you're doing a window control system, you use llGetLinkPrimitiveParamters() to get the current alpha of the outside face of a window... which returns a list (not cheap in memory), then you send it back a new list (more memory) to change the alpha. or... llSetLinkAlpha(front_window, outsideface, llGetLinkAlpha(front_window,outsideface)*.20); and the outside transparency is changed to 20% of what it was. q.e.d? #4 want to get rid of a major script attachment? Integrated AO into the client.. it can be done. Just a few thoughts. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091219/b45d21c3/attachment.htm From tigrospottystripes at gmail.com Sat Dec 19 18:56:03 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sun, 20 Dec 2009 00:56:03 -0200 Subject: [sldev] [Fwd: Re: Bidding System Algorithm for Allocation Script Memory] Message-ID: <4B2D9243.4070203@Gmail.com> (just redirecting back to the list) -------------- next part -------------- An embedded message was scrubbed... From: Lear Cale Subject: Re: [sldev] Bidding System Algorithm for Allocation Script Memory Date: Sat, 19 Dec 2009 21:42:24 -0500 Size: 2700 Url: http://lists.secondlife.com/pipermail/sldev/attachments/20091220/acd0c6cc/attachment.eml From dgothly at erotobotics.com Sat Dec 19 20:05:35 2009 From: dgothly at erotobotics.com (Darrius Gothly) Date: Sat, 19 Dec 2009 23:05:35 -0500 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> <20091220003237.GA18035@alinoe.com> <4B2D7343.4060706@Gmail.com> Message-ID: Oh good heavens, no. I would expect the bidding process to be out of reach for the script code, insulated inside the Sim management code. That's an OS level function and shouldn't be exposed to LSL or any other such external process. ----- Original Message ----- From: Lear Cale To: TigroSpottystripes at gmail.com Sent: Saturday, December 19, 2009 9:42 PM Subject: Re: [sldev] Bidding System Algorithm for Allocation Script Memory Ack, hysteresis. First come wins, eh? So, scripters will write scripts that constantly bid until they get the memory the want and then squat on it until it's actually needed? From carlo at alinoe.com Sun Dec 20 04:09:00 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 20 Dec 2009 13:09:00 +0100 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory In-Reply-To: <4B2D7343.4060706@Gmail.com> References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> <20091220003237.GA18035@alinoe.com> <4B2D7343.4060706@Gmail.com> Message-ID: <20091220120900.GA15717@alinoe.com> On Sat, Dec 19, 2009 at 10:43:47PM -0200, Tigro Spottystripes wrote: > Would it be too hard to instead of true stasis the scripts were just > transfered into a separated thread that has less priority, runs only > when the is some idle time on the processor or somthing (including using > cheaper hardware and nto getting in the way of other stuff), so scripts > can continue to work? (either way the event that gets triggered when a > script is about to get downgraded would still be great to have) Well, we're assuming that the server is out of memory, so the memory those scripts use are swapped to disk. Assume a disk speed of 50 MB/s. Assume one script takes 64 kB. Assume a needed run time of at least 100 ms to make sense to swap a script out and in again. That means you can load say 5 MB every 100 ms, which are 80 scripts (at the cost of an additional 5 MB of RAM). The maximum number of swapped out scripts would be equal to the maximum number of scripts that can run on a sim (for the worst case of 1 person loading the sim fully, but only owning a fraction of the land, and then being pushed out completely by everyone else joining and running all the scripts they have a right to). So, according to LL that would 150 MB (300 MB minus the avatar pool). Hence, those swapped out scripts could run 100 ms every 150/5 * 100ms = 3 seconds. Although slow, they indeed still run then,.. so I'd definitely include a sending them a signal (maybe change their state to 'statis'? If that state doesn't exist then the default should be to do nothing; a script could take action (ie, go to sleep) and stay in statis, in which case it would not be swapped out again at all, or it could change it's state back to another state, in which case it would continue to run at the slow speed). -- Carlo Wood From carlo at alinoe.com Sun Dec 20 04:16:44 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 20 Dec 2009 13:16:44 +0100 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory In-Reply-To: References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> <20091220003237.GA18035@alinoe.com> <4B2D7343.4060706@Gmail.com> Message-ID: <20091220121644.GB15717@alinoe.com> Also, "first comes wins" is completely out of the picture here. The "bidding" is really just a priority, equal to the (additive) inverse of the percentage used (of their fair share). The result will be that in the maximum loaded case everyone gets the same percentage (100% of what they are entitled to), while at a lesser load everyone (who tries still gets the same percentage (ie, 130%), while others that don't want script memory would voluntary stay at 70%. It's a very good and honest system. Still need to build in a little hysteresis to avoid it being instable, but those are minor technical details that can be solved once the Lindens agree that this is more fair and less of a waste of resources. On Sat, Dec 19, 2009 at 11:05:35PM -0500, Darrius Gothly wrote: > Oh good heavens, no. I would expect the bidding process to be out of reach > for the script code, insulated inside the Sim management code. That's an OS > level function and shouldn't be exposed to LSL or any other such external > process. > ----- Original Message ----- > From: Lear Cale > To: TigroSpottystripes at gmail.com > Sent: Saturday, December 19, 2009 9:42 PM > Subject: Re: [sldev] Bidding System Algorithm for Allocation Script Memory > > Ack, hysteresis. First come wins, eh? So, scripters will write scripts > that constantly bid until they get the memory the want and then squat on it > until it's actually needed? -- Carlo Wood From secret.argent at gmail.com Sun Dec 20 06:12:24 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 20 Dec 2009 08:12:24 -0600 Subject: [sldev] Memory Allocation Algorithms and Tools - Script Limits In-Reply-To: <59EE2AB0FF6B44CE93A16570D95EE2D2@jbh3000> References: <59EE2AB0FF6B44CE93A16570D95EE2D2@jbh3000> Message-ID: <5A9CB5E2-8799-4E79-8124-8773442CC9CC@gmail.com> On 2009-12-18, at 18:49, Darrius Gothly wrote: > New statement: llEnd() - This script is done, dead, finished, kaput, > pushing > up the daisies .. whatever. All it had is yours again dear Sim. May > it rest > in peace. llSetScriptState(llGetScriptName(), FALSE); From dgothly at erotobotics.com Sun Dec 20 06:20:37 2009 From: dgothly at erotobotics.com (Darrius Gothly) Date: Sun, 20 Dec 2009 09:20:37 -0500 Subject: [sldev] Memory Allocation Algorithms and Tools - Script Limits References: <59EE2AB0FF6B44CE93A16570D95EE2D2@jbh3000> <5A9CB5E2-8799-4E79-8124-8773442CC9CC@gmail.com> Message-ID: Yup .. that'll stop it, but it doesn't signal "and give up all my resources cuz I am done done done." The llSetScriptState function has a different purpose, to suspend a script that isn't needed right now but might again sometime soon. The proposed llEnd function is a one-way dead-end off the cliff call that can't be undone from code. And it tosses in the handy attribute of being for one purpose and one purpose only, "take this script out of contention for resources." With llSetScriptState, any guess the VM makes about the script's resources is just that, a guess. ----- Original Message ----- From: "Argent Stonecutter" > > On 2009-12-18, at 18:49, Darrius Gothly wrote: >> New statement: llEnd() - This script is done, dead, finished, kaput, >> pushing >> up the daisies .. whatever. All it had is yours again dear Sim. May it >> rest >> in peace. > > llSetScriptState(llGetScriptName(), FALSE); > > From andsim2 at gmail.com Sun Dec 20 06:24:44 2009 From: andsim2 at gmail.com (Andrew Simpson) Date: Sun, 20 Dec 2009 09:24:44 -0500 Subject: [sldev] Cmake Message-ID: <4B2E33AC.5090400@gmail.com> hi there, what version of cmake would use? i am having trouble to build 1.23.5 on vc++ 2008 i am on 2.8.0 From secret.argent at gmail.com Sun Dec 20 06:27:02 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 20 Dec 2009 08:27:02 -0600 Subject: [sldev] Static universal memory limits are operationally non-scalable In-Reply-To: <9e52a8c10912190359h7f263744w1dff151567c0b9dc@mail.gmail.com> References: <9e52a8c10912190359h7f263744w1dff151567c0b9dc@mail.gmail.com> Message-ID: <8C602D94-CA46-45BC-B194-AB733B3BB757@gmail.com> Christ, people. Quit worrying about the per-avatar limit. The avatar limit isn't the one that's likely to cause problems, unless Kelly and Babbage set it way too low and go through with the rumored multiplier on LSL script size. The parcel limit is the one that bothers me, because parcels can be so much smaller a percentage of the total sim, and because most parcels are mostly empty and they don't fluctuate in usage that much... so there's more reason to allow overcommitment there. From secret.argent at gmail.com Sun Dec 20 06:38:20 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 20 Dec 2009 08:38:20 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2CD403.6010407@gmail.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2CD403.6010407@gmail.com> Message-ID: <4D41D59B-50EE-405C-8DF6-C2D219043157@gmail.com> On 2009-12-19, at 07:24, Imaze Rhiano wrote: > Other fact is that people are stupid. Fixed memory limits would be > most > easily understood by average Joe and Jane. They really don't want to > use > their head to calculate how many scripts they can deploy to their > parcel > before hitting to boundaries. Keep it simple and stupid. A simple two level soft limit/hard limit scheme is just as easy to understand, and reliably allows a controlled amount of overcommitment at the parcel level. If the sim is above the trigger level (75%, or whatever) you get your "dedicated" limit, which is N/65536th of the total sim resources. If you're worried about stuff getting returned for going over the limit, stay under this level, you'll never have a problem. That percentage of the sim memory is dedicated to you, no matter what. If the sim is below the trigger level, you get a larger limit, which might be a sliding scale between 512 and 32768 square meters, with less than 512 treated as 2048, and more than 32768 treated as a full sim, or could simply be 2N or 4N, whatever is easy and convenient to implement and document. In either case the resources available will be visible in "about land", and maybe the landowner gets to see a warning icon if the parcel is over the dedicated limit. Simple, easy to understand, landowners don't need to actually figure out the calculation for how much slop they have. From secret.argent at gmail.com Sun Dec 20 06:52:38 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 20 Dec 2009 08:52:38 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2D1175.6090601@Gmail.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> Message-ID: <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> On 2009-12-19, at 11:46, Tigro Spottystripes wrote: > Scripts that individually are using more memory than the maximum > guaranteed, and scripts that have been added after enough scripts with > the minimum guaranteed have already been added tot he parcel go to the > separated slow mode. There is no point to a "slow mode". A script in "slow mode" is using up just as much memory as any other script. There is no savings from this kind of scheme. The only way to have quotas actually serve a useful purpose is to actually return objects and refuse objects and avatars entry when the limit is hit. No other mechanism is meaningful. From secret.argent at gmail.com Sun Dec 20 06:53:55 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 20 Dec 2009 08:53:55 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <20091219184013.GA1510@alinoe.com> References: <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2CD403.6010407@gmail.com> <20091219184013.GA1510@alinoe.com> Message-ID: <27B8878F-2E00-4D87-9D8D-12B4A2ED3D49@gmail.com> On 2009-12-19, at 12:40, Carlo Wood wrote: > That kind of reasoning might be relevant for mainland, but I'd > have nothing of it for private sims. It should be the region owner > who decides how to devide the resources. Let the region owner adjust the limits and bonus multipliers, like they can with prim bonus now. From secret.argent at gmail.com Sun Dec 20 06:58:58 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 20 Dec 2009 08:58:58 -0600 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory In-Reply-To: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> Message-ID: <36990292-C5F7-4602-94BE-0BE780A2E961@gmail.com> On 2009-12-19, at 18:06, Darrius Gothly wrote: > Suggestion: A "Bidding System" for allocating memory resources on a > Sim. > [complex scheme goes here] Soft/hard quotas, "dedicated" or "peak" limits, are a well known, well understood, and widely used mechanism throughout the computer and telecommunications industry. You get a fairly low dedicated level of resources that you can always depend on. You get a variable, as- available level of resources when usage is low. It's like your phone service, you get 300 minutes a month of talk time during peak hours, and unlimited evening and weekend minutes. This works. There's no reason to create a more complex scheme, or worry about people not understanding it. So on your 512 square meters of land, you get N megabytes dedicated, and 4N megabytes when the rest of the sim is empty. If your dance ball is programmed to only start up scripts when it needs to, then you can have a party on your parcel tonight, and your neighbor can have one tomorrow night, and nobody has a problem. From lillie.yiyuan at gmail.com Sun Dec 20 07:25:34 2009 From: lillie.yiyuan at gmail.com (Lillian Yiyuan) Date: Sun, 20 Dec 2009 07:25:34 -0800 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory In-Reply-To: <36990292-C5F7-4602-94BE-0BE780A2E961@gmail.com> References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> <36990292-C5F7-4602-94BE-0BE780A2E961@gmail.com> Message-ID: And we all find ways around it, and al the cellphone companies offerways around it (calling circles and so on). Adopting a broken model just because it is well understood, means that you understand the model is brorked, and everyone will know it is borked from day 1. A bidding model, should the "currency" be determined, will lead to the least waste of resources, where as a dedicated limit will make life very unhappy as small parcels with people on them are lagged into the ground, while the empty mall next door eats the sim resources. On Sun, Dec 20, 2009 at 6:58 AM, Argent Stonecutter wrote: > On 2009-12-19, at 18:06, Darrius Gothly wrote: >> Suggestion: A "Bidding System" for allocating memory resources on a >> Sim. > >> [complex scheme goes here] > > > Soft/hard quotas, "dedicated" or "peak" limits, are a well known, well > understood, and widely used mechanism throughout the computer and > telecommunications industry. You get a fairly low dedicated level of > resources that you can always depend on. You get a variable, as- > available level of resources when usage is low. > > It's like your phone service, you get 300 minutes a month of talk time > during peak hours, and unlimited evening and weekend minutes. > > This works. There's no reason to create a more complex scheme, or > worry about people not understanding it. > > So on your 512 square meters of land, you get N megabytes dedicated, > and 4N megabytes when the rest of the sim is empty. If your dance ball > is programmed to only start up scripts when it needs to, then you can > have a party on your parcel tonight, and your neighbor can have one > tomorrow night, and nobody has a problem. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From lillie.yiyuan at gmail.com Sun Dec 20 07:32:26 2009 From: lillie.yiyuan at gmail.com (Lillian Yiyuan) Date: Sun, 20 Dec 2009 07:32:26 -0800 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory In-Reply-To: References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> <36990292-C5F7-4602-94BE-0BE780A2E961@gmail.com> Message-ID: Also, a square meter allocation is wrong, since meters go up in larger and larger steps with tier paid up to the size of the sim. Instead it should be in steps, not meters. For example it is 195 to rent an entire sim on mainland, but 5 dollars to rent the first 512 after your base 512. That means that if the large owner were paying at the same rate, he or she would have to pay $640 USD. Doing it by meters would make small parcel owners have to pay much more for the same resource. A very good way to drive tier holders out, is to put them, again, on the short end of a system that favors big land owners substantiall, inthis case by as much as a factor of 3, for resource allocation. On Sun, Dec 20, 2009 at 7:25 AM, Lillian Yiyuan wrote: > And we all find ways around it, and al the cellphone companies > offerways around it (calling circles and so on). Adopting a broken > model just because it is well understood, means that you understand > the model is brorked, and everyone will know it is borked from day 1. > > A bidding model, should the "currency" be determined, will lead to the > least waste of resources, where as a dedicated limit will make life > very unhappy as small parcels with people on them are lagged into the > ground, while the empty mall next door eats the sim resources. > > > > On Sun, Dec 20, 2009 at 6:58 AM, Argent Stonecutter > wrote: >> On 2009-12-19, at 18:06, Darrius Gothly wrote: >>> Suggestion: A "Bidding System" for allocating memory resources on a >>> Sim. >> >>> [complex scheme goes here] >> >> >> Soft/hard quotas, "dedicated" or "peak" limits, are a well known, well >> understood, and widely used mechanism throughout the computer and >> telecommunications industry. You get a fairly low dedicated level of >> resources that you can always depend on. You get a variable, as- >> available level of resources when usage is low. >> >> It's like your phone service, you get 300 minutes a month of talk time >> during peak hours, and unlimited evening and weekend minutes. >> >> This works. There's no reason to create a more complex scheme, or >> worry about people not understanding it. >> >> So on your 512 square meters of land, you get N megabytes dedicated, >> and 4N megabytes when the rest of the sim is empty. If your dance ball >> is programmed to only start up scripts when it needs to, then you can >> have a party on your parcel tonight, and your neighbor can have one >> tomorrow night, and nobody has a problem. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > From techiedavid at gmail.com Sun Dec 20 08:38:25 2009 From: techiedavid at gmail.com (David Simmons) Date: Sun, 20 Dec 2009 08:38:25 -0800 Subject: [sldev] Fwd: Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <3a164ef30912200836h6d18a9a2t3621b0907acba3ab@mail.gmail.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2C2336.9010809@Gmail.com> <4B2C28F4.2090704@gmail.com> <3a164ef30912200836h6d18a9a2t3621b0907acba3ab@mail.gmail.com> Message-ID: <3a164ef30912200838k21d41d85hf8fe8f06c5e8e785@mail.gmail.com> On Fri, Dec 18, 2009 at 5:14 PM, Dzonatas Sol wrote: > Maybe some way to flag a script as "phantom" like how objects are > phantom where they become independent of the phsyics engine and as such > the scripts become independent of the the usual simulator loop/affinity. > > Phantom scripts would not have to be copied from sim to sim. The could > exist entirely a server just for phantom scripts. > The only issue I see to this proposal is who will pay for the server? After all indirectly that is what the tiers pay for. Use of the server. The http and email functions already allow someone to run programs on their own server with only minimal script footprint inside SL(tm). I guess Linden Lab won't not mind selling none simulators computer time if they had surplus servers. > > Tigro Spottystripes wrote: > > Can't the sim code be made multithreaded and have scripts that are using > > more memory than is avaiable be moved to a sep?rated thread that runs on > > virtual ram only, so people can have fast memory hogs if there is enough > > memory left, but if other scripts need it, the memory hogs get > > downgraded to slower mode and don't use the physical ram, nor get in the > > way of other things in the sim. ? > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091220/fbffbfe4/attachment.htm From cinciasingh at gmail.com Sun Dec 20 08:55:09 2009 From: cinciasingh at gmail.com (Cincia Singh) Date: Sun, 20 Dec 2009 10:55:09 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration Message-ID: <9e877f170912200855k79697b62u32ded9021459473d@mail.gmail.com> Just one opinion ... not responding to anyone in particular. Over commitment of sim resources is what brought us to this conversation in the first place. Having a hard parcel limit is how SL avoids over commitment for prims and it's likely the only solution that will work for scripts; both are what we pay tier for. Just because someone leaves a 512 with no prims on it doesn't mean other parcels in the sim get to use them because the sim CAN support their use. Regardless the sim's capabilities, if someone pays tier they should expect that what they pay for stays theirs, and allocated to them, at all times. There is already a way to get more server resource allocation and that is buying more land (server resources). Coding that allows re-allocation of script resources will eventually cause lag because the elegant coding required to accomplish the re-allocation increases the likelihood someone will find a way to game the system and abuse it. Ok, now you can rationalize and think up reasons to do it anyway to your heart's content. I just had to speak my 0.02L worth. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091220/6654079b/attachment.htm From lillie.yiyuan at gmail.com Sun Dec 20 08:55:55 2009 From: lillie.yiyuan at gmail.com (Lillian Yiyuan) Date: Sun, 20 Dec 2009 08:55:55 -0800 Subject: [sldev] User needs on script limits Message-ID: This list is heavily weighted towards developers, and that means people who sell scripts. There is no way this change isn't going to have a negative impact on them at first, because previously a resource that they used for free is going to be charged for. However the people who are paying for this, the users, are not represented here, and the conversation largely has been about inflicting as much pain on the users as possible to protect other interests, namely LL and developers. The users need certain features to deal with tis change, especially for content that was written in the face of the reality that scripts were free, and the LL permissions system is a borked nightmare that cannot ever be unborked. The first thing users need is the ability to make all scripts in an object "no load." Not just stopped, which still uses resources, but no load. They need this from inventory, not from rez, since the object might not rez under most proposed systems. Why, because now that they are paying for scripts, they have a right to determine how their resources are allocated, not the creator of the object. Before when they weren't being charged there was an argument for creator's rights, now that argument is outweighed by the user's right to dispose of their property, namely script limit. Second they need the ability to change the names of items in inventory, even if the object is no modify. Why? Because for an object that is modifiable by script, what the user will want to do is rez the modifiable version, modify it through the scripts, rename it to identify the new properties (such as say brown chestnut angel hair by nefarious designs.) Set the scripts on it to no load, and put it back into inventory. This way it is modded per the scripts of the creator, but from then on, the load scrits version is what the user will wear. Some designers do this, but many do not, and the content that is not is already out there. Therefore, the capability has to be put in by the system, because before it was a designer being cooperative in the face of a commons, now it is a property situation, and the property owner (the user) has to be able to control resource usage for a new restriction being put on them post hoc. Now what about the problem of users then saying "my hair doesn't work!" For this it would be best if a new system folder were created. "Purchases" An object that goes into purchases, if copyable, not only rezzes a copy, as now, but if it attaches, the attachment is a copy. This way, when the user rezes the copyable hair, or shoes, or whatever, they get a copy rezzed. This is presently done on "make outfit" Instead it should be done from rezzing. The user can then run the modify scripts, no load them, and the master copy is still in purchases. If the user borks the copy they make, the delete it, and go back to the master copy, which won't ever actually leave inventory. So the Purchases system folder ill have the property that anything in it, if possible, attaches a copy, rather than just rezzes a copy as now. This leads to the ability to "attach a copy" as an option for attachments and HUDs. The user find a scripted version of the object, attaches a copy, plays with it, and saves that. This is useful for content in other contexts, such as working with mod content, so that the master copy stays in inventory. By default, objects received from an object should go into the purchases folder. Finally, users need the ability to see how much they are using, by object, from their limits, and what those limits are if they are dynamic (which they ought to be). So basically: set scripts to no load in selection, regardless of mod bit, attach a copy, purchases folder which by default attaches a copy. Much of the script clutter comes from the master slave model. For new content this can be fixed by offering List versions of anything that currently has a delay, and by llGetLinkedPrimitiveParams. These list versions will take a list, whose length can be limited by function call say 16 in the case of IMs or whatever, rather than a single value. This way if an instruction s to llSetLinkedPrimParamsList, the scripter passes a list of the linkset numbers to be affected by the call. The script engine parses the list and sets off the command for the prims on that list. This way there is no reason for master-slave, or at least much less of a reason for master slave, which is, after all, to send a command to a list of avatars, objects, or link sets. Right now only hard coded lists (such as the entire link set) can be affected this way, what would much of the need ofr master-slave, is to allow an arbitrarily defined list to be passed in. In a real programming language, we would overload, but in LSL we ned a different function call name. This llBlahList as a format. So LLGetLinkSetPrimitiveParams, and *List versions of anything with a delay, with that list length limited by call to prevent griefing and so on. Even if master slave is still used, it will be in multiples of the list length, not in units of one. From tateru.nino at gmail.com Sun Dec 20 09:09:17 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon, 21 Dec 2009 04:09:17 +1100 Subject: [sldev] User needs on script limits In-Reply-To: References: Message-ID: <4B2E5A3D.3020503@gmail.com> Actually, I think one of my two points earlier was that this list is weighted specifically towards those involved in viewer development or whom have a keen interest in that, and - as such - doesn't seem like an appropriate or representative forum at all for the topic. Surely, there must be some more inclusive way to have a discussion about this - if discussion it actually be. For the most part it just looks like a whole bunch of folks (and admittedly, quite nice folks in the main. I'm not singling anyone out, and especially not you, Lillian) who want to get their two-cents worth heard by Linden Lab developers, and who don't seem to have any other avenue for doing so. Heck, just doing a quick count of messages, the topic would carry its own mailing list at this rate, and free this one up for - you know - talking about the viewer again. :) If, indeed, as has been suggested, the process of analyzing the grid, use-cases, running tests and finally producing a cohesive strategy for dealing with that... if that process is going to take the predicted "months", it seems like viewer development discussion is going to get drowned out a little in the torrent. Just my own two cents, you understand :) On 21/12/2009 3:55 AM, Lillian Yiyuan wrote: > This list is heavily weighted towards developers, and that means > people who sell scripts. There is no way this change isn't going to > have a negative impact on them at first, because previously a resource > that they used for free is going to be charged for. However the people > who are paying for this, the users, are not represented here, and the > conversation largely has been about inflicting as much pain on the > users as possible to protect other interests, namely LL and > developers. The users need certain features to deal with tis change, > especially for content that was written in the face of the reality > that scripts were free, and the LL permissions system is a borked > nightmare that cannot ever be unborked. > > The first thing users need is the ability to make all scripts in an > object "no load." Not just stopped, which still uses resources, but no > load. They need this from inventory, not from rez, since the object > might not rez under most proposed systems. Why, because now that they > are paying for scripts, they have a right to determine how their > resources are allocated, not the creator of the object. Before when > they weren't being charged there was an argument for creator's rights, > now that argument is outweighed by the user's right to dispose of > their property, namely script limit. > > Second they need the ability to change the names of items in > inventory, even if the object is no modify. Why? Because for an object > that is modifiable by script, what the user will want to do is rez the > modifiable version, modify it through the scripts, rename it to > identify the new properties (such as say brown chestnut angel hair by > nefarious designs.) Set the scripts on it to no load, and put it back > into inventory. This way it is modded per the scripts of the creator, > but from then on, the load scrits version is what the user will wear. > Some designers do this, but many do not, and the content that is not > is already out there. Therefore, the capability has to be put in by > the system, because before it was a designer being cooperative in the > face of a commons, now it is a property situation, and the property > owner (the user) has to be able to control resource usage for a new > restriction being put on them post hoc. > > Now what about the problem of users then saying "my hair doesn't work!" > > For this it would be best if a new system folder were created. > "Purchases" An object that goes into purchases, if copyable, not only > rezzes a copy, as now, but if it attaches, the attachment is a copy. > This way, when the user rezes the copyable hair, or shoes, or > whatever, they get a copy rezzed. This is presently done on "make > outfit" Instead it should be done from rezzing. The user can then run > the modify scripts, no load them, and the master copy is still in > purchases. If the user borks the copy they make, the delete it, and go > back to the master copy, which won't ever actually leave inventory. So > the Purchases system folder ill have the property that anything in it, > if possible, attaches a copy, rather than just rezzes a copy as now. > > This leads to the ability to "attach a copy" as an option for > attachments and HUDs. The user find a scripted version of the object, > attaches a copy, plays with it, and saves that. This is useful for > content in other contexts, such as working with mod content, so that > the master copy stays in inventory. > > By default, objects received from an object should go into the purchases folder. > > Finally, users need the ability to see how much they are using, by > object, from their limits, and what those limits are if they are > dynamic (which they ought to be). > > So basically: set scripts to no load in selection, regardless of mod > bit, attach a copy, purchases folder which by default attaches a copy. > > Much of the script clutter comes from the master slave model. For new > content this can be fixed by offering List versions of anything that > currently has a delay, and by llGetLinkedPrimitiveParams. These list > versions will take a list, whose length can be limited by function > call say 16 in the case of IMs or whatever, rather than a single > value. This way if an instruction s to llSetLinkedPrimParamsList, the > scripter passes a list of the linkset numbers to be affected by the > call. The script engine parses the list and sets off the command for > the prims on that list. This way there is no reason for master-slave, > or at least much less of a reason for master slave, which is, after > all, to send a command to a list of avatars, objects, or link sets. > Right now only hard coded lists (such as the entire link set) can be > affected this way, what would much of the need ofr master-slave, is to > allow an arbitrarily defined list to be passed in. In a real > programming language, we would overload, but in LSL we ned a different > function call name. This llBlahList as a format. > > So LLGetLinkSetPrimitiveParams, and *List versions of anything with a > delay, with that list length limited by call to prevent griefing and > so on. Even if master slave is still used, it will be in multiples of > the list length, not in units of one. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -- Tateru Nino http://dwellonit.taterunino.net/ From andsim2 at gmail.com Sun Dec 20 09:13:24 2009 From: andsim2 at gmail.com (Andrew Simpson) Date: Sun, 20 Dec 2009 12:13:24 -0500 Subject: [sldev] [SLDev] Which cmake Message-ID: <4B2E5B34.9060003@gmail.com> hi there, what version of cmake would use? i am having trouble to build 1.23.5 on vc++ 2008 From lillie.yiyuan at gmail.com Sun Dec 20 09:34:36 2009 From: lillie.yiyuan at gmail.com (Lillian Yiyuan) Date: Sun, 20 Dec 2009 09:34:36 -0800 Subject: [sldev] User needs on script limits In-Reply-To: <4B2E5A3D.3020503@gmail.com> References: <4B2E5A3D.3020503@gmail.com> Message-ID: All of my suggestions above are in the client: lsl changes, purchased folder, and rez on attachment. Now it may well be that there should be a separate topic for the whole question, but he viewer aspect of how the users are going to interact with a script limited service cannot be ignored, or swept into some other location. There is also the reality that there is a very large overlap between people who are trying to accomplish solutions in world, an thus script, with people who want changes to the client, because those solutions in world do not lend themselves to being fixed by scripts. The intersection of fashionistas and client developers, is far smaller. On Sun, Dec 20, 2009 at 9:09 AM, Tateru Nino wrote: > Actually, I think one of my two points earlier was that this list is > weighted specifically towards those involved in viewer development or > whom have a keen interest in that, and - as such - doesn't seem like an > appropriate or representative forum at all for the topic. > > Surely, there must be some more inclusive way to have a discussion about > this - if discussion it actually be. For the most part it just looks > like a whole bunch of folks (and admittedly, quite nice folks in the > main. I'm not singling anyone out, and especially not you, Lillian) who > want to get their two-cents worth heard by Linden Lab developers, and > who don't seem to have any other avenue for doing so. > > Heck, just doing a quick count of messages, the topic would carry its > own mailing list at this rate, and free this one up for - you know - > talking about the viewer again. :) > > If, indeed, as has been suggested, the process of analyzing the grid, > use-cases, running tests and finally producing a cohesive strategy for > dealing with that... if that process is going to take the predicted > "months", it seems like viewer development discussion is going to get > drowned out a little in the torrent. > > Just my own two cents, you understand :) > > On 21/12/2009 3:55 AM, Lillian Yiyuan wrote: >> This list is heavily weighted towards developers, and that means >> people who sell scripts. There is no way this change isn't going to >> have a negative impact on them at first, because previously a resource >> that they used for free is going to be charged for. However the people >> who are paying for this, the users, are not represented here, and the >> conversation largely has been about inflicting as much pain on the >> users as possible to protect other interests, namely LL and >> developers. The users need certain features to deal with tis change, >> especially for content that was written in the face of the reality >> that scripts were free, and the LL permissions system is a borked >> nightmare that cannot ever be unborked. >> >> The first thing users need is the ability to make all scripts in an >> object "no load." Not just stopped, which still uses resources, but no >> load. They need this from inventory, not from rez, since the object >> might not rez under most proposed systems. Why, because now that they >> are paying for scripts, they have a right to determine how their >> resources are allocated, not the creator of the object. Before when >> they weren't being charged there was an argument for creator's rights, >> now that argument is outweighed by the user's right to dispose of >> their property, namely script limit. >> >> Second they need the ability to change the names of items in >> inventory, even if the object is no modify. Why? Because for an object >> that is modifiable by script, what the user will want to do is rez the >> modifiable version, modify it through the scripts, rename it to >> identify the new properties (such as say brown chestnut angel hair by >> nefarious designs.) Set the scripts on it to no load, and put it back >> into inventory. This way it is modded per the scripts of the creator, >> but from then on, the load scrits version is what the user will wear. >> Some designers do this, but many do not, and the content that is not >> is already out there. Therefore, the capability has to be put in by >> the system, because before it was a designer being cooperative in the >> face of a commons, now it is a property situation, and the property >> owner (the user) has to be able to control resource usage for a new >> restriction being put on them post hoc. >> >> Now what about the problem of users then saying "my hair doesn't work!" >> >> For this it would be best if a new system folder were created. >> "Purchases" An object that goes into purchases, if copyable, not only >> rezzes a copy, as now, but if it attaches, the attachment is a copy. >> This way, when the user rezes the copyable hair, or shoes, or >> whatever, they get a copy rezzed. This is presently done on "make >> outfit" Instead it should be done from rezzing. The user can then run >> the modify scripts, no load them, and the master copy is still in >> purchases. If the user borks the copy they make, the delete it, and go >> back to the master copy, which won't ever actually leave inventory. So >> the Purchases system folder ill have the property that anything in it, >> if possible, ?attaches a copy, rather than just rezzes a copy as now. >> >> This leads to the ability to "attach a copy" as an option for >> attachments and HUDs. The user find a scripted version of the object, >> attaches a copy, plays with it, and saves that. This is useful for >> content in other contexts, such as working with mod content, so that >> the master copy stays in inventory. >> >> By default, objects received from an object should go into the purchases folder. >> >> Finally, users need the ability to see how much they are using, by >> object, from their limits, and what those limits are if they are >> dynamic (which they ought to be). >> >> So basically: set scripts to no load in selection, regardless of mod >> bit, attach a copy, purchases folder which by default attaches a copy. >> >> Much of the script clutter comes from the master slave model. For new >> content this can be fixed by offering List versions of anything that >> currently has a delay, and by llGetLinkedPrimitiveParams. These list >> versions will take a list, whose length can be limited by function >> call say 16 in the case of IMs or whatever, rather than a single >> value. This way if an instruction s to llSetLinkedPrimParamsList, the >> scripter passes a list of the linkset numbers to be affected by the >> call. The script engine parses the list and sets off the command for >> the prims on that list. This way there is no reason for master-slave, >> or at least much less of a reason for master slave, which is, after >> all, to send a command to a list of avatars, objects, or link sets. >> Right now only hard coded lists (such as the entire link set) can be >> affected this way, what would much of the need ofr master-slave, is to >> allow an arbitrarily defined list to be passed in. In a real >> programming language, we would overload, but in LSL we ned a different >> function call name. This llBlahList as a format. >> >> So LLGetLinkSetPrimitiveParams, and *List versions of anything with a >> delay, with that list length limited by call to prevent griefing and >> so on. Even if master slave is still used, it will be in multiples of >> the list length, not in units of one. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > > -- > Tateru Nino > http://dwellonit.taterunino.net/ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From tigrospottystripes at gmail.com Sun Dec 20 09:54:07 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sun, 20 Dec 2009 15:54:07 -0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> Message-ID: <4B2E64BF.3070706@Gmail.com> They wouldn't be using the fast memory and would have less priority to run, letting stuff that has more priority run with regular speed. Argent Stonecutter escreveu: > On 2009-12-19, at 11:46, Tigro Spottystripes wrote: > >> Scripts that individually are using more memory than the maximum >> guaranteed, and scripts that have been added after enough scripts with >> the minimum guaranteed have already been added tot he parcel go to the >> separated slow mode. >> > > There is no point to a "slow mode". A script in "slow mode" is using > up just as much memory as any other script. There is no savings from > this kind of scheme. The only way to have quotas actually serve a > useful purpose is to actually return objects and refuse objects and > avatars entry when the limit is hit. No other mechanism is meaningful. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From danteferret at gmail.com Sun Dec 20 12:16:15 2009 From: danteferret at gmail.com (Peter Leonard/Dante) Date: Sun, 20 Dec 2009 15:16:15 -0500 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <9e877f170912200855k79697b62u32ded9021459473d@mail.gmail.com> References: <9e877f170912200855k79697b62u32ded9021459473d@mail.gmail.com> Message-ID: <4d211a610912201216y1fb01cccic4d2de5e3c45dc5@mail.gmail.com> Your view is entirely valid. But only on mainland. On private estates the size of parcels, and who owns them is irelivent. It still needs to be up to the estate owner and managers how to divide resources on the sim. On Sun, Dec 20, 2009 at 11:55 AM, Cincia Singh wrote: > Just one opinion ... not responding to anyone in particular. > > Over commitment of sim resources is what brought us to this conversation in > the first place. > Having a hard parcel limit is how SL avoids over commitment for prims and > it's likely > the only solution that will work for scripts; both are what we pay tier > for. Just because > someone leaves a 512 with no prims on it doesn't mean other parcels in the > sim get to > use them because the sim CAN support their use. Regardless the sim's > capabilities, > if someone pays tier they should expect that what they pay for stays > theirs, and allocated > to them, at all times. There is already a way to get more server resource > allocation and > that is buying more land (server resources). > > Coding that allows re-allocation of script resources will eventually cause > lag because > the elegant coding required to accomplish the re-allocation increases the > likelihood > someone will find a way to game the system and abuse it. > > Ok, now you can rationalize and think up reasons to do it anyway to your > heart's content. > I just had to speak my 0.02L worth. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091220/b15736c9/attachment.htm From sheet.spotter at gmail.com Sun Dec 20 13:48:33 2009 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Sun, 20 Dec 2009 15:48:33 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <9e877f170912200855k79697b62u32ded9021459473d@mail.gmail.com> References: <9e877f170912200855k79697b62u32ded9021459473d@mail.gmail.com> Message-ID: <1FC70A2725994FDA85617CD94788E7C6@kenb> Using all available prims or all available script/memory may diminish performance for everyone in the region, even when swapping is not occurring. Most modern operating systems allocate any unused memory for disk or system cache. Sims that do not use their full prim limit or the maximum script/memory limit would likely benefit from a larger cache. When Time Dilation plummets during a lag spike the Net Time, Agent Time, and Images Time in the Statistics panel seem to spike. Leaving unused memory in the cache might allow the simulator to handle the spikes in network traffic or agent updates more easily, or to retain more textures in cache. Admittedly, I'm a performance junky. I never want to use all available RAM. I always want to ensure unused RAM is available for disk and system cache. Finding a solution that can use all of the available script memory may not be the best answer. The benefits to using less than the maximum script/memory limit also need to be considered. Sheet Spotter _____ From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Cincia Singh Sent: December 20, 2009 10:55 AM To: sldev at lists.secondlife.com Subject: Re: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration Just one opinion ... not responding to anyone in particular. Over commitment of sim resources is what brought us to this conversation in the first place. Having a hard parcel limit is how SL avoids over commitment for prims and it's likely the only solution that will work for scripts; both are what we pay tier for. Just because someone leaves a 512 with no prims on it doesn't mean other parcels in the sim get to use them because the sim CAN support their use. Regardless the sim's capabilities, if someone pays tier they should expect that what they pay for stays theirs, and allocated to them, at all times. There is already a way to get more server resource allocation and that is buying more land (server resources). Coding that allows re-allocation of script resources will eventually cause lag because the elegant coding required to accomplish the re-allocation increases the likelihood someone will find a way to game the system and abuse it. Ok, now you can rationalize and think up reasons to do it anyway to your heart's content. I just had to speak my 0.02L worth. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091220/d2cc2bdb/attachment.htm From brickrte at hughes.net Sun Dec 20 14:36:32 2009 From: brickrte at hughes.net (Laurence Brickner) Date: Sun, 20 Dec 2009 17:36:32 -0500 Subject: [sldev] Cmake In-Reply-To: <4B2E33AC.5090400@gmail.com> References: <4B2E33AC.5090400@gmail.com> Message-ID: <2B6E1B019C114BCE98CBEA933B1EA0E1@LRBXPS> Andrew, Jees, I get to answer something. I'm using 2.8.0 like you. I tried VS2008 but got waved off by several people. Reinstalled 2005 along side 2008 and everything fell into place. Larry/Shorahmin -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Andrew Simpson Sent: Sunday, December 20, 2009 09:25 To: sldev at lists.secondlife.com Subject: [sldev] Cmake hi there, what version of cmake would use? i am having trouble to build 1.23.5 on vc++ 2008 i am on 2.8.0 _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges From robertltux at gmail.com Sun Dec 20 14:41:50 2009 From: robertltux at gmail.com (Robert Martin) Date: Sun, 20 Dec 2009 17:41:50 -0500 Subject: [sldev] Fwd: Cmake In-Reply-To: References: <4B2E33AC.5090400@gmail.com> <2B6E1B019C114BCE98CBEA933B1EA0E1@LRBXPS> Message-ID: ---------- Forwarded message ---------- From: Robert Martin Date: Sun, Dec 20, 2009 at 5:41 PM Subject: Re: [sldev] Cmake To: brickrte at odyssey.net On Sun, Dec 20, 2009 at 5:36 PM, Laurence Brickner wrote: > Andrew, > Jees, I get to answer something. ?I'm using 2.8.0 like you. ?I tried VS2008 > but got waved off by several people. ?Reinstalled 2005 along side 2008 and > everything fell into place. > > Larry/Shorahmin > a couple semirelated questions 1 is there a semi-legit way to download a copy of 2005 2 Why Does Secondlife still require an obsolete IDE to compile?? -- Robert L Martin -- Robert L Martin From brickrte at hughes.net Sun Dec 20 14:51:55 2009 From: brickrte at hughes.net (Laurence Brickner) Date: Sun, 20 Dec 2009 17:51:55 -0500 Subject: [sldev] Fwd: Cmake In-Reply-To: References: <4B2E33AC.5090400@gmail.com><2B6E1B019C114BCE98CBEA933B1EA0E1@LRBXPS> Message-ID: <496704D8341B462CAECBE8D628B2908D@LRBXPS> R.M. 1) Not that I know of. Some have tried to do it with 2005 express (Which is free) but had problems. But, apparently it is "doable". 2) As I understand it, the problem is in third party libraries that SL uses. Larry/Shorahmin -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Robert Martin Sent: Sunday, December 20, 2009 17:42 To: SLDev Mailing List Subject: [sldev] Fwd: Cmake ---------- Forwarded message ---------- From: Robert Martin Date: Sun, Dec 20, 2009 at 5:41 PM Subject: Re: [sldev] Cmake To: brickrte at odyssey.net On Sun, Dec 20, 2009 at 5:36 PM, Laurence Brickner wrote: > Andrew, > Jees, I get to answer something. ?I'm using 2.8.0 like you. ?I tried VS2008 > but got waved off by several people. ?Reinstalled 2005 along side 2008 and > everything fell into place. > > Larry/Shorahmin > a couple semirelated questions 1 is there a semi-legit way to download a copy of 2005 2 Why Does Secondlife still require an obsolete IDE to compile?? -- Robert L Martin -- Robert L Martin _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges From kakurady at gmail.com Sun Dec 20 15:26:26 2009 From: kakurady at gmail.com (Kakurady (Geneko Nemeth)) Date: Sun, 20 Dec 2009 18:26:26 -0500 Subject: [sldev] Fwd: Cmake In-Reply-To: <496704D8341B462CAECBE8D628B2908D@LRBXPS> References: <4B2E33AC.5090400@gmail.com><2B6E1B019C114BCE98CBEA933B1EA0E1@LRBXPS> <496704D8341B462CAECBE8D628B2908D@LRBXPS> Message-ID: <4B2EB2A2.6010605@gmail.com> 1. 2005 Express works perfectly. However, Microsoft doesn't openly advertise how to get VC++2005 Express anymore, so it's a bit hard to find. There's a download link to the English version on the Imprudence project's wiki[1]. 2. What I heard was that the 3rd-party libs LL has prebuilt is built with VC++ '05 or '03, and VC++ 2008 has changed the name mangling methods for C++ functions, so the linker doesn't know which function is which. But this doesn't explain how it used to link perfectly only to enter an infinite loop at runtime... [1] http://imprudenceviewer.org/wiki/How_to_compile#Windows* *? 2009/12/20 17:51, Laurence Brickner ??: > R.M. > 1) Not that I know of. Some have tried to do it with 2005 express (Which > is free) but had problems. But, apparently it is "doable". > > 2) As I understand it, the problem is in third party libraries that SL > uses. > > Larry/Shorahmin > > > -----Original Message----- > From: sldev-bounces at lists.secondlife.com > [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Robert Martin > Sent: Sunday, December 20, 2009 17:42 > To: SLDev Mailing List > Subject: [sldev] Fwd: Cmake > > ---------- Forwarded message ---------- > From: Robert Martin > Date: Sun, Dec 20, 2009 at 5:41 PM > Subject: Re: [sldev] Cmake > To: brickrte at odyssey.net > > > On Sun, Dec 20, 2009 at 5:36 PM, Laurence Brickner > wrote: > >> Andrew, >> Jees, I get to answer something. I'm using 2.8.0 like you. I tried >> > VS2008 > >> but got waved off by several people. Reinstalled 2005 along side 2008 and >> everything fell into place. >> >> Larry/Shorahmin >> >> > a couple semirelated questions > 1 is there a semi-legit way to download a copy of 2005 > 2 Why Does Secondlife still require an obsolete IDE to compile?? > -- > Robert L Martin > > > > -- Kakurady (Geneko) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091220/afae4cf5/attachment-0001.htm From secret.argent at gmail.com Sun Dec 20 15:37:17 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 20 Dec 2009 17:37:17 -0600 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory In-Reply-To: References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> <36990292-C5F7-4602-94BE-0BE780A2E961@gmail.com> Message-ID: <30FB9213-2180-40FE-B178-E97B1C099AA1@gmail.com> On 2009-12-20, at 09:25, Lillian Yiyuan wrote: > And we all find ways around it, and al the cellphone companies > offerways around it (calling circles and so on). Adopting a broken > model just because it is well understood, means that you understand > the model is brorked, and everyone will know it is borked from day 1. It's not a broken model, there's no need to find ways around it, and "calling circles" are not "ways around it". From secret.argent at gmail.com Sun Dec 20 15:39:29 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 20 Dec 2009 17:39:29 -0600 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory In-Reply-To: References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> <36990292-C5F7-4602-94BE-0BE780A2E961@gmail.com> Message-ID: <18AD288C-321A-4414-867D-281FB022126D@gmail.com> On 2009-12-20, at 09:32, Lillian Yiyuan wrote: > Doing it by meters would > make small parcel owners have to pay much more for the same resource. Making small land holders pay more for the same resource is the whole point of the tier system. One might want to argue against having graduated tiers at all, but it's not relevant here. From lillie.yiyuan at gmail.com Sun Dec 20 15:41:48 2009 From: lillie.yiyuan at gmail.com (Lillian Yiyuan) Date: Sun, 20 Dec 2009 18:41:48 -0500 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory In-Reply-To: <18AD288C-321A-4414-867D-281FB022126D@gmail.com> References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> <36990292-C5F7-4602-94BE-0BE780A2E961@gmail.com> <18AD288C-321A-4414-867D-281FB022126D@gmail.com> Message-ID: Presently they don't, and no one has produced a compelling reason why they should here. On Sun, Dec 20, 2009 at 6:39 PM, Argent Stonecutter wrote: > On 2009-12-20, at 09:32, Lillian Yiyuan wrote: >> >> Doing it by meters would >> make small parcel owners have to pay much more for the same resource. > > Making small land holders pay more for the same resource is the whole point > of the tier system. > > One might want to argue against having graduated tiers at all, but it's not > relevant here. > > From secret.argent at gmail.com Sun Dec 20 15:42:08 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 20 Dec 2009 17:42:08 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2E64BF.3070706@Gmail.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> Message-ID: <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> On 2009-12-20, at 11:54, Tigro Spottystripes wrote: > They wouldn't be using the fast memory There is no such thing as "fast" and "slow" memory. From tigrospottystripes at gmail.com Sun Dec 20 16:32:20 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sun, 20 Dec 2009 22:32:20 -0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> Message-ID: <4B2EC214.4000008@Gmail.com> RAM is fast and virtual memory is slow Argent Stonecutter escreveu: > On 2009-12-20, at 11:54, Tigro Spottystripes wrote: >> They wouldn't be using the fast memory > > There is no such thing as "fast" and "slow" memory. > > From tigrospottystripes at gmail.com Sun Dec 20 18:10:39 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 21 Dec 2009 00:10:39 -0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2ED404.5070306@superliminal.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <4B2ED404.5070306@superliminal.com> Message-ID: <4B2ED91F.70908@Gmail.com> are you saying virtual memory isn't on a harddrive? i know both are memory, what i'm saying is to push things that are being downgraded into a separated system, the memory of the downgraded stuff is stored on disk, and only accessed when there is time for that ps:tomorrow morning i'm going away on a trip, i'll be away for the holidays, won't be able to reply till close to new year. Melinda Green escreveu: > Virtual memory *is* RAM so long as the process doesn't go over its > "soft" limit. > -Melinda > > Tigro Spottystripes wrote: >> RAM is fast and virtual memory is slow >> >> Argent Stonecutter escreveu: >> >>> On 2009-12-20, at 11:54, Tigro Spottystripes wrote: >>> >>>> They wouldn't be using the fast memory >>>> >>> There is no such thing as "fast" and "slow" memory. >> >> > From dgothly at erotobotics.com Sun Dec 20 21:14:16 2009 From: dgothly at erotobotics.com (Darrius Gothly) Date: Mon, 21 Dec 2009 00:14:16 -0500 Subject: [sldev] Jira post notification Message-ID: <49FE6A4B776F4D2485CB8DFA57A993FD@jbh3000> A little while back I posted a JIRA regarding persistent memory for LSL. Since recently joining this list, I thought maybe some might want to see it and perhaps vote for it. http://jira.secondlife.com/browse/MISC-3706 From secret.argent at gmail.com Mon Dec 21 01:41:12 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon, 21 Dec 2009 03:41:12 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2EC214.4000008@Gmail.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <4B2A423A.40902@Gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> Message-ID: <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> On 2009-12-20, at 18:32, Tigro Spottystripes wrote: > RAM is fast and virtual memory is slow That's not how demand-paged virtual memory works. From stickman at gmail.com Mon Dec 21 01:52:23 2009 From: stickman at gmail.com (Stickman) Date: Mon, 21 Dec 2009 01:52:23 -0800 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> Message-ID: > That's not how demand-paged virtual memory works. Is it possible to make a system that does? I kinda like the idea. It's basically what we have now, except with a smart system that decides what swaps and what uses RAM. -Stickman From tillie at xp2.de Mon Dec 21 02:09:42 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Mon, 21 Dec 2009 11:09:42 +0100 Subject: [sldev] [SLDev] Which cmake In-Reply-To: <4B2E5B34.9060003@gmail.com> References: <4B2E5B34.9060003@gmail.com> Message-ID: <4B2F4966.5060506@xp2.de> On 20.12.2009 18:13, Andrew Simpson wrote: > what version of cmake would use? i am having trouble to build 1.23.5 on > vc++ 2008 2.8 is the right one. Tillie From secret.argent at gmail.com Mon Dec 21 02:11:37 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon, 21 Dec 2009 04:11:37 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> Message-ID: <7FC55AD3-C0FA-4487-8587-5AEA2A41CFBC@gmail.com> On 2009-12-21, at 03:52, Stickman wrote: >> That's not how demand-paged virtual memory works. > Is it possible to make a system that does? If you want to write a new operating system just to run Second Life. From sldev at catznip.com Mon Dec 21 03:10:26 2009 From: sldev at catznip.com (Kitty) Date: Mon, 21 Dec 2009 12:10:26 +0100 Subject: [sldev] User needs on script limits In-Reply-To: References: Message-ID: <2832F5240D634A86BB00A54724A096A0@panther> > The first thing users need is the ability to make all scripts > in an object "no load." Not just stopped, which still uses > resources, but no load. They need this from inventory, not > from rez, since the object might not rez under most proposed > systems. Why, because now that they are paying for scripts, > they have a right to determine how their resources are > allocated, not the creator of the object. Before when they > weren't being charged there was an argument for creator's > rights, now that argument is outweighed by the user's right > to dispose of their property, namely script limit. This isn't nearly gradual enough though. Someone might have a badly scripted hair that has a resizer, texture change and hair bow colour changer in it, as well as a pair of shoes that contains a resizer, texture changer, show/hide script to optionally show/hide some things and a built in "sexy walk". In general each "feature" is contained in its own script(s) so it's possible to delete one of them while keeping the rest of them functional. In the case of the hair they may find the resizer useless but like the texture changer or hair bow colour changer, with the shoes they may just want to keep the show/hide but remove all the others. The only (legitimate) way that'll work is for LL to undo the change to "no modify" that made it impossible to still remove "copy/no transfer" items from inside of a "no mod" linkset. > Second they need the ability to change the names of items in > inventory, even if the object is no modify. That feature is needed just for basic inventory organizing alone :p. From dzonatas at gmail.com Mon Dec 21 06:39:44 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Mon, 21 Dec 2009 06:39:44 -0800 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> Message-ID: <4B2F88B0.80707@gmail.com> Yes. It's called "locking" or "pinning" the memory pages. It's not used often anymore before it means pages are stuck in their position and could cause fragmentation, which could slow the system overall when it needs to defrag memory in order to find large sequential chunks. Most of that logic is not needed anymore once since the large virtual tables are now present, and that's one thing that made the 386 popular. Technically, there is "fast" and "slow" memory, but it is also known as ROM and RAM, and that being ROM is usually at least twice as fast RAM. Pre-386 machines, like Motorola based, put their system OS in ROM to boost its speed 8 times. That is how the Amiga, with its blitter hardware, did graphics manipulation way ahead of its time. Remember when Amiga used to be called a Game machine and Windows was "business" only, and now look at DX10 and the whole underlying market of ROM based video cards for Windows. You wonder where they got their ideas. *wink* Anyways, there still is some mixup in these related threads about script memory being split between avatar memory limits and parcel memory limits. When an avatar that has paid premium rates to be fashionable (hence, not a griefer at all) and the outfit require an expected XX amount of memory to runs its scripts... wanders onto a parcel that has had its memory limits choked... poo poo is gonna hit the fan. *tap* *tap* *tap* There are many people pay top dollar for their fashions in the real world, and obviously they won't go places that won't support their outfit. Do we need to actually make a case how this applies in-world? Parcel limits should not limit the avatar. (I know someone is gonna argue griefer cases, but bottom line... griefer objects are not avatar.) Stickman wrote: >> That's not how demand-paged virtual memory works. >> > > Is it possible to make a system that does? > > I kinda like the idea. It's basically what we have now, except with a > smart system that decides what swaps and what uses RAM. > > -Stickman > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From brickrte at hughes.net Mon Dec 21 06:37:58 2009 From: brickrte at hughes.net (Laurence Brickner) Date: Mon, 21 Dec 2009 09:37:58 -0500 Subject: [sldev] LNK4099 warning Message-ID: <36C12BEC188549A5A28ACF0CA5559C42@LRBXPS> Hi all, I'm getting many dozens of this type warning: 1>apr-1.lib(inet_pton.obj) : warning LNK4099: PDB 'apr-1_ib_11.pdb' was not found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\Documents and Settings\Larry\Desktop\SnowGlobe\linden\indra\media_plugins\VNCPlugin\RelWit hDebInfo\apr-1_ib_11.pdb'; linking object as if no debug info I find lots of discussion on it but no answers. Can anyone help? Thanks, Larry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091221/7244a269/attachment.htm From robin.cornelius at gmail.com Mon Dec 21 06:46:11 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon, 21 Dec 2009 14:46:11 +0000 Subject: [sldev] LNK4099 warning In-Reply-To: <36C12BEC188549A5A28ACF0CA5559C42@LRBXPS> References: <36C12BEC188549A5A28ACF0CA5559C42@LRBXPS> Message-ID: On Mon, Dec 21, 2009 at 2:37 PM, Laurence Brickner wrote: > Hi all, > > I?m getting many dozens of this type warning: > > 1>apr-1.lib(inet_pton.obj) : warning LNK4099: PDB 'apr-1_ib_11.pdb' was not > found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at > 'C:\Documents and > Settings\Larry\Desktop\SnowGlobe\linden\indra\media_plugins\VNCPlugin\RelWithDebInfo\apr-1_ib_11.pdb'; > linking object as if no debug info > The various prebuilt libs that are dependencies of the viewer do not have the debug database file with them (the .pdb file) all this means in practice is that if you are debugging you cannot step into the library file from visual studio and see nice pretty human readable things, you will only be able to see assembler from the disassembly output, when walking in to the library file. Robin From brickrte at hughes.net Mon Dec 21 08:30:55 2009 From: brickrte at hughes.net (Laurence Brickner) Date: Mon, 21 Dec 2009 11:30:55 -0500 Subject: [sldev] LNK4099 warning In-Reply-To: References: <36C12BEC188549A5A28ACF0CA5559C42@LRBXPS> Message-ID: Thanks Robin, Unfortunately, that's exactly my problem. I can't debug any of the sub-projects that this happens in. I set a breakpoint and VS sets it to unavailable when I start debugging. So not only can't I get into the APR library (As expected) but I also can't debug the entire DLL. I'm sure I have some thing set wrong but... Larry/Shorahmin -----Original Message----- From: Robin Cornelius [mailto:robin.cornelius at gmail.com] Sent: Monday, December 21, 2009 09:46 To: brickrte at odyssey.net Cc: SLDev Mailing List Subject: Re: [sldev] LNK4099 warning On Mon, Dec 21, 2009 at 2:37 PM, Laurence Brickner wrote: > Hi all, > > I'm getting many dozens of this type warning: > > 1>apr-1.lib(inet_pton.obj) : warning LNK4099: PDB 'apr-1_ib_11.pdb' was not > found with '..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at > 'C:\Documents and > Settings\Larry\Desktop\SnowGlobe\linden\indra\media_plugins\VNCPlugin\RelWit hDebInfo\apr-1_ib_11.pdb'; > linking object as if no debug info > The various prebuilt libs that are dependencies of the viewer do not have the debug database file with them (the .pdb file) all this means in practice is that if you are debugging you cannot step into the library file from visual studio and see nice pretty human readable things, you will only be able to see assembler from the disassembly output, when walking in to the library file. Robin From secret.argent at gmail.com Mon Dec 21 08:38:53 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon, 21 Dec 2009 10:38:53 -0600 Subject: [sldev] User needs on script limits In-Reply-To: <2832F5240D634A86BB00A54724A096A0@panther> References: <2832F5240D634A86BB00A54724A096A0@panther> Message-ID: On 2009-12-21, at 05:10, Kitty wrote: > The only (legitimate) way that'll work is for LL to undo the change > to "no > modify" that made it impossible to still remove "copy/no transfer" > items > from inside of a "no mod" linkset. That's a good point. Script limits are more than enough reason to do that. From secret.argent at gmail.com Mon Dec 21 08:48:18 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon, 21 Dec 2009 10:48:18 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2F88B0.80707@gmail.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> <4B2F88B0.80707@gmail.com> Message-ID: On 2009-12-21, at 08:39, Dzonatas Sol wrote: > Yes. It's called "locking" or "pinning" the memory pages. It's not > used > often anymore before it means pages are stuck in their position and > could cause fragmentation, which could slow the system overall when it > needs to defrag memory in order to find large sequential chunks. > Most of > that logic is not needed anymore once since the large virtual tables > are > now present, and that's one thing that made the 386 popular. In modern real time operating systems you only need to pin pages to specific addresses if they're being used for IPC or I/O hardware. You can still have non-swappable pages that aren't pinned to a specific address. The problem is that pages are too coarse a unit for this, when you have an interpreter that's storing all data in a common soup. You'd have to completely redo the Mono memory allocator. And even then, well, I'm pretty sure that making an application of the size and complexity of SL also handling VM decisions would lead to a massive overhead and duplicate effort. > Technically, there is "fast" and "slow" memory, but it is also known > as > ROM and RAM, and that being ROM is usually at least twice as fast RAM. That hasn't been true for twenty years. Even back in the Amiga's day it was common to copy the OS from ROM to RAM for a performance boost. The Amiga blitter had nothing to do with ROM vs RAM. The Amiga OS also didn't run out of ROM, it ran out of what was called "kickstart" memory, loaded by the kickstart ROM from the kickstart disk. Kickstart memory was RAM. From monkowsk at fishkill.ibm.com Mon Dec 21 08:59:26 2009 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Mon, 21 Dec 2009 11:59:26 -0500 Subject: [sldev] Script/Parcel/Memory Limits In-Reply-To: <690eba40912191654o6021dee8o524d471d2d734653@mail.gmail.com> References: <9788aeb10912170417w263e8ddo27a7e26e9d20c246@mail.gmail.com> <20091218123252.GB32194@alinoe.com> <20091219000923.GB25099@alinoe.com> <690eba40912191654o6021dee8o524d471d2d734653@mail.gmail.com> Message-ID: <4B2FA96E.7090402@fishkill.ibm.com> Ilana Debevec wrote: > Another thought, the new functions Babbage has talked about are a good > start to eliminate excess > scripts, but from what's been mentioned, some more REALLY would make > things a bit easier. ... This is the real discussion that should be going on in SLDev, and it's refreshing that about five out of a hundred posts to the mailing list, such as this one, are addressing the root cause of the problem. There seems to be universal agreement that AO should not require scripts. VWR-386 is in the top 10 most requested features. The only comment I heard from Linden what something to the effect, we want to make sure we do it the right way, yet I haven't seen any strawman proposals published on the list by Linden Lab, and no comment on the Emerald solution, so I can only conclude that this is just a smoke screen. The llEndScript to enable a one-time execution sounds like an interesting proposal that as far as I can tell has received no comment from Linden. SLDev is supposed to be an open source project. Let's talk. Let's design. Let's get something done. Right about now is when Rob would put an end to the policy discussions here and round up the stray cats. :-( Mike Mm Alder From monkowsk at fishkill.ibm.com Mon Dec 21 09:00:50 2009 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Mon, 21 Dec 2009 12:00:50 -0500 Subject: [sldev] Fwd: Cmake In-Reply-To: References: <4B2E33AC.5090400@gmail.com> <2B6E1B019C114BCE98CBEA933B1EA0E1@LRBXPS> Message-ID: <4B2FA9C2.6070607@fishkill.ibm.com> Robert Martin wrote: > 2 Why Does Secondlife still require an obsolete IDE to compile?? +1 Mike From dzonatas at gmail.com Mon Dec 21 10:10:48 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Mon, 21 Dec 2009 10:10:48 -0800 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> <4B2F88B0.80707@gmail.com> Message-ID: <4B2FBA28.60903@gmail.com> Argent Stonecutter wrote: > That hasn't been true for twenty years. Even back in the Amiga's day > it was common to copy the OS from ROM to RAM for a performance boost. > Only when they came out with pseudo-fast memory, which made the difference between "Fast RAM" and "Slow RAM" based on what the CPU controlled. > The Amiga blitter had nothing to do with ROM vs RAM. > The CPU & Blitter locked memory, this was known as Chip RAM, which is analogous to DMA on i386 based CPUs. Psuedo-fast was fast because the Chip-set (blitter) did not lock it. Remember that your billboard idea for avatar imposters was actually all done as hardware sprites on the Amiga. It's the same principle in modern OSs, but its done more in software than in hardware except for what video cards still do today. With newer memory cache schemes for multi-core CPUs that are headed to replace the "shared" memory architecture between CPUs and other devices on the motherboard that we have known, most of the fast and slow memory concepts can be expected to become obsolete. > The Amiga OS also didn't run out of ROM, it ran out of what was called > "kickstart" memory, loaded by the kickstart ROM from the kickstart > disk. Kickstart memory was RAM. > That was optional. As you can see many people used Kickstart ROM chips instead of diskettes. http://en.wikipedia.org/wiki/Amiga_500#Memory_map Yes, people actually bought chip upgrades to boot/start Workbench instead to avoid the undesirable routine to have to find the kickstart diskette, load it, boot, and then reload their next flavor of diskette based software. Slow RAM with battery backup power was then used to upgrade that routine beyond the ROM sets that could be bought. Anyways, the concepts of fast and slow memory is real, yet since it has become a major "no-no" to "hack the hardware" (a.k.a direct peeking/poking the hardware), like what used to be so common, the concept has faded, but not enough to criticize someone publicly on a list like it never existed. In fact, both Intel and ATI have wanted to put Havok on a chip-set much like the Amiga's Chip-set or how any video now does video. That would essentially change the way scripts memory relates to physical simulation. Scripts with physics heavy procedures could be pinned to the Havok memory area. That's just all done in software now, so the distinction is just not being made obvious. From andsim2 at gmail.com Mon Dec 21 11:37:55 2009 From: andsim2 at gmail.com (Andrew Simpson) Date: Mon, 21 Dec 2009 14:37:55 -0500 Subject: [sldev] Linkable prim over 256 Message-ID: <4B2FCE93.3030700@gmail.com> hi guys, i am trying to find the code that set the limit on 256 link on the prim in one, wher it is in the code source or iut in xml? let me know thank From soft at lindenlab.com Mon Dec 21 12:03:37 2009 From: soft at lindenlab.com (Soft Linden) Date: Mon, 21 Dec 2009 14:03:37 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <27B8878F-2E00-4D87-9D8D-12B4A2ED3D49@gmail.com> References: <9bb32d430912170630l30039852t51003af6a6eb5fec@mail.gmail.com> <1e01733d0912180410k1a2c3268yf64682c222b31ad8@mail.gmail.com> <20091218235539.GA25099@alinoe.com> <4B2CD403.6010407@gmail.com> <20091219184013.GA1510@alinoe.com> <27B8878F-2E00-4D87-9D8D-12B4A2ED3D49@gmail.com> Message-ID: On Sun, Dec 20, 2009 at 8:53 AM, Argent Stonecutter wrote: > > Let the region owner adjust the limits and bonus multipliers, like > they can with prim bonus now. Do me a favor and drop what you're thinking in a JIRA so people can debate it specifically? IMHO, this makes the most sense of any of the schemes so far. We don't want a situation on mainland where scripts' ability to run depends on what the neighbor is up to. But if EMs want to take on extra resource management, give them a knob. It would be good if any proposal included things like having the resulting error dialog point resis at the EM for support when they over-commit in a region with a multiplier set. This would reduce the support impact if some people find they can't run even one script. From secret.argent at gmail.com Mon Dec 21 15:45:40 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon, 21 Dec 2009 17:45:40 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2FBA28.60903@gmail.com> References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> <4B2F88B0.80707@gmail.com> <4B2FBA28.60903@gmail.com> Message-ID: On 2009-12-21, at 12:10, Dzonatas Sol wrote: > Only when they came out with pseudo-fast memory, which made the > difference between "Fast RAM" and "Slow RAM" based on what the CPU > controlled. Amiga "fast" memory was memory that wasn't shared with the Blitter, and copying ROM to RAM was not just on the Amiga. RAM overtook ROM in performance in the early '80s. > The CPU & Blitter locked memory, this was known as Chip RAM, which > is analogous to DMA on i386 based CPUs. Psuedo-fast was fast because > the Chip-set (blitter) did not lock it. Remember that your billboard > idea for avatar imposters was actually all done as hardware sprites > on the Amiga. But that's not why the blitter made the Amiga fast, it was an implementation detail caused by the way the 68000 took two cycles to access memory. > That was optional. As you can see many people used Kickstart ROM > chips instead of diskettes. http://en.wikipedia.org/wiki/Amiga_500#Memory_map That happened later. The kickstart was an absolute necessity in the Amiga 1000, 2000, and 3000. You're mixing up all kinds of different concepts here, none of which are meaningful in a VM environment. Do remember who said "an OS without virtual memory is an OS without virtue", and why he stopped? From dzonatas at gmail.com Mon Dec 21 17:42:32 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Mon, 21 Dec 2009 17:42:32 -0800 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4d211a610912162354s5e2c7fadrd37ba9d96490503e@mail.gmail.com> <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> <4B2F88B0.80707@gmail.com> <4B2FBA28.60903@gmail.com> Message-ID: <4B302408.2080007@gmail.com> Argent Stonecutter wrote: > > You're mixing up all kinds of different concepts here, none of which > are meaningful in a VM environment. If you want to think shader languages are not meaningful in a VM environment, then that's your opinion, but that still is no intent to mix up any concepts. > > Do remember who said "an OS without virtual memory is an OS without > virtue", and why he stopped? > > http://lmgtfy.com/?q=%22an+OS+without+virtual+memory+is+an+OS+without+virtue%22 Hmmm. I can only guess since I really have no idea what you mean by that or why you said it. I could discuss more about shader languages... and how a similar physics based shader-like language could be very useful to this thread's discussion, but the flags have been waved. Your idea taken to JIRA is the practical thing to do for now. From nexisentertainment at gmail.com Mon Dec 21 20:32:56 2009 From: nexisentertainment at gmail.com (Rob Nelson) Date: Mon, 21 Dec 2009 20:32:56 -0800 Subject: [sldev] Linkable prim over 256 In-Reply-To: <4B2FCE93.3030700@gmail.com> References: <4B2FCE93.3030700@gmail.com> Message-ID: <1261456376.9649.10.camel@RAGE> It's server-side, you can't change it unless you're running on OpenSim. On Mon, 2009-12-21 at 14:37 -0500, Andrew Simpson wrote: > hi guys, > > i am trying to find the code that set the limit on 256 link on the prim > in one, wher it is in the code source or iut in xml? let me know thank > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From teravus at gmail.com Mon Dec 21 20:45:17 2009 From: teravus at gmail.com (Teravus Ovares) Date: Mon, 21 Dec 2009 23:45:17 -0500 Subject: [sldev] Linkable prim over 256 In-Reply-To: <1261456376.9649.10.camel@RAGE> References: <4B2FCE93.3030700@gmail.com> <1261456376.9649.10.camel@RAGE> Message-ID: <34cc66250912212045p2cd8ff32n4350aa68e53c8835@mail.gmail.com> Just a clarification here. The code may also be server side.. but if you create 444 objects and try to link them all on OpenSimulator using the Standard Linden Client downloaded from the website it presents a message box that says 'Unable to link these 444 objects. You can link a maximum of 256 objects'. This means that it is also client side because there is no server side code to restrict the number of objects you can link in OpenSimulator without a 3rd party addon module. Regards Teravus On Mon, Dec 21, 2009 at 11:32 PM, Rob Nelson wrote: > It's server-side, you can't change it unless you're running on OpenSim. > > On Mon, 2009-12-21 at 14:37 -0500, Andrew Simpson wrote: >> hi guys, >> >> i am trying to find the code that set the limit on 256 link on the prim >> in one, wher it is in the code source or iut in xml? let me know thank >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From holydoughnuts at gmail.com Tue Dec 22 02:11:08 2009 From: holydoughnuts at gmail.com (Tori C.) Date: Tue, 22 Dec 2009 05:11:08 -0500 Subject: [sldev] Linkable prim over 256 In-Reply-To: <4B2FCE93.3030700@gmail.com> References: <4B2FCE93.3030700@gmail.com> Message-ID: <1e0db80e0912220211m4cd8054cy2ffcb56c9997f4f@mail.gmail.com> On Mon, Dec 21, 2009 at 2:37 PM, Andrew Simpson wrote: > i am trying to find the code that set the limit on 256 link on the prim > in one, wher it is in the code source or iut in xml? let me know thank On the viewer side of things, look for MAX_CHILDREN_PER_TASK in indra_constants.h and llviewermenu.cpp but as the others noted, LL's servers use this limit too. From carlo at alinoe.com Tue Dec 22 03:53:21 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 22 Dec 2009 12:53:21 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> Message-ID: <20091222115321.GA10705@alinoe.com> On Mon, Dec 21, 2009 at 01:52:23AM -0800, Stickman wrote: > > That's not how demand-paged virtual memory works. > > Is it possible to make a system that does? > > I kinda like the idea. It's basically what we have now, except with a > smart system that decides what swaps and what uses RAM. I already commented on this before imho... Yes it is possible to run scripts that are on harddisk; although I'm not sure you can use a part of the OS that easily to achieve it. Imho, you could let a script run for 1 ms (100 scripts at a time) every 3 seconds, only using 6.4 MB of RAM that is refreshed from disk (with 100 next scripts) every 100 ms. However... I'm not really convinced that this is worth it. The only reason to allow scripts to run that way is to let them shut down gracefully imho. One could add a new state to LSL (ie, stasis) and switch scripts to that state while they are swapped out like that. Scripts without this state would just halt till they are restored to normal memory. The talk that I see about objects being returned... I don't know where that comes from. Why would you want to return objects? That seems too annoying. Let the prim accounting take care of that. Scripts that cannot run anymore should just stop running, not cause objects to be returned of course. Of course, you could choose to add a line to the stasis state that returns the object, if you wish... -- Carlo Wood From dgothly at erotobotics.com Tue Dec 22 04:08:38 2009 From: dgothly at erotobotics.com (Darrius Gothly) Date: Tue, 22 Dec 2009 07:08:38 -0500 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration References: <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com><4B2D1175.6090601@Gmail.com><55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com><4B2E64BF.3070706@Gmail.com><840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com><4B2EC214.4000008@Gmail.com><5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> <20091222115321.GA10705@alinoe.com> Message-ID: llEndScript(integer die=FALSE); ? Or maybe a parameter with constants: ENDSCRIPT_END, ENDSCRIPT_RETURN, ENDSCRIPT_DIE The comment about "returning objects" comes from Babbage's office hours on the 9th of this month where he makes a comment about it. [3:42] Babbage Linden: that will include functionality for finding and returning scripted objects [3:42] Babbage Linden: so everyone will be able to find and clean up the scripts they don't need [3:43] Babbage Linden: before we start enforcing limits However he does add just after that ... [3:44] Babbage Linden: no one else can see or return your attachments And then goes the other way 10 minutes later ... [3:53] Babbage Linden: Jack is going to be communicating this to people [3:53] Babbage Linden: when the limits are enforced, you will end up with objects being returned [3:54] Babbage Linden: but hopefully everyone will have enough time to manage their attachments before that happens So, yeah, I can understand why people are concerned. Office hour transcript is here http://wiki.secondlife.com/wiki/User:Babbage_Linden/Office_Hours/2009_12_09 ----- Original Message ----- From: "Carlo Wood" > On Mon, Dec 21, 2009 at 01:52:23AM -0800, Stickman wrote: >> > That's not how demand-paged virtual memory works. >> >> Is it possible to make a system that does? >> >> I kinda like the idea. It's basically what we have now, except with a >> smart system that decides what swaps and what uses RAM. > > I already commented on this before imho... Yes it is possible > to run scripts that are on harddisk; although I'm not sure > you can use a part of the OS that easily to achieve it. > > Imho, you could let a script run for 1 ms (100 scripts at a time) > every 3 seconds, only using 6.4 MB of RAM that is refreshed > from disk (with 100 next scripts) every 100 ms. > > However... I'm not really convinced that this is worth it. > The only reason to allow scripts to run that way is to let > them shut down gracefully imho. One could add a new state > to LSL (ie, stasis) and switch scripts to that state while > they are swapped out like that. Scripts without this state > would just halt till they are restored to normal memory. > > The talk that I see about objects being returned... I don't > know where that comes from. Why would you want to return > objects? That seems too annoying. Let the prim accounting > take care of that. Scripts that cannot run anymore should > just stop running, not cause objects to be returned of course. > Of course, you could choose to add a line to the stasis > state that returns the object, if you wish... > > -- > Carlo Wood > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From carlo at alinoe.com Tue Dec 22 04:08:15 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 22 Dec 2009 13:08:15 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B2F88B0.80707@gmail.com> References: <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> <4B2F88B0.80707@gmail.com> Message-ID: <20091222120815.GB10705@alinoe.com> On Mon, Dec 21, 2009 at 06:39:44AM -0800, Dzonatas Sol wrote: > Anyways, there still is some mixup in these related threads about script > memory being split between avatar memory limits and parcel memory > limits. When an avatar that has paid premium rates to be fashionable > (hence, not a griefer at all) and the outfit require an expected XX > amount of memory to runs its scripts... wanders onto a parcel that has > had its memory limits choked... poo poo is gonna hit the fan. *tap* > *tap* *tap* The avatar would not be affected at all. If avatar and object memory use from the same pool too (I'd like that, the more "temporary" memory the better), then such avatar entering a sim where one person is using all avatar memory would just have some of that persons scripts to be stopped, until the first avatar leaves again. That is better than the current situation where EVERY object and avatar grinds to a halt because the server starts swapping. It is also better as the proposed fixed limits, because in that case the first person couldn't even do what he was doing BEFORE that other avatar entered. > There are many people pay top dollar for their fashions in the real > world, and obviously they won't go places that won't support their > outfit. Do we need to actually make a case how this applies in-world? > > Parcel limits should not limit the avatar. (I know someone is gonna > argue griefer cases, but bottom line... griefer objects are not avatar.) The system with fixed limits that is about to be implemented by Linden Lab will limit the number of scripts you can run in attachments up to the same point of a fully loaded server. That way you are sure that with the few scripts allowed, you can also enter a full server *cross eyed looked*. Nevertheless... I can understand this reasoning for avatars. The sad side is however that by reserving memory for the full set of avatars (35) EACH loaded with the MAXIMUM number of attachment scripts, just "in case", simply means a huge waste of resources on 99% of the sims 99.9% of the time. All of that precious memory can not be used anymore for objects, ever. So, ... clearly it would be better to DO allow objects to use that memory and only stop them temporarily if their memory is *actually* needed for 35 avatars full with scripted attachments that just entered. -- Carlo Wood From carlo at alinoe.com Tue Dec 22 04:37:08 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 22 Dec 2009 13:37:08 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> <20091222115321.GA10705@alinoe.com> Message-ID: <20091222123708.GC10705@alinoe.com> On Tue, Dec 22, 2009 at 07:08:38AM -0500, Darrius Gothly wrote: > llEndScript(integer die=FALSE); ? Or maybe a parameter with constants: > ENDSCRIPT_END, ENDSCRIPT_RETURN, ENDSCRIPT_DIE > > > The comment about "returning objects" comes from Babbage's office hours on > the 9th of this month where he makes a comment about it. Haha, if that is true - then the average IQ on this list is a lot lower than I had expected. So, Babbage says: > [3:42] Babbage Linden: that will include functionality for finding > and returning scripted objects > > [3:42] Babbage Linden: so everyone will be able to find and clean up > the scripts they don't need > > [3:43] Babbage Linden: before we start enforcing limits which means that IF they would implement a new LSL function called llEndScript that allows one to pass a parameter "ENDSCRIPT_RETURN" THEN (after adding that to all scripts) one could have a script return the object it is in (as function of detected circumstance, like not needing the script to run or exist). And then people think that if I mention "dynamic limits" that that means that if a script that is running and then can't run anymore because it's memory is needed by a script with a higher priority, then the first script is automatically returned by the server... Those those two have so little to do with eachother I don't know where to begin to draw a parallel that shows how little. So, to be clear: No those are TOTALLY different subjects. And I never said that objects had to be returned. On the contrary, that would be a poor implementation as well. The simplest implementation that is reasonable is to stop scripts that lose their memory (so they would have to be manually restarted), and refuse to start scripts that don't have memory at that moment, and probably to refuse to rez objects with scripts that wouldn't have memory. However(!) that is a rather poor implementation as well. A lot better would be to stop scripts, but swap them out to harddisk to preserve their state and automatically resume where they were once there is memory again. Even better would be to tell the scripts that they are swapped out and let them deal with that fact at a very low pace (where one could then do: state_stasis { llEndScript(ENDSCRIPT_RETURN); } in the chickens of my chicken-shoot example ;)... cause I'd have no problem with the excess chickens to disappear. Hopefully that isn't going to confuse people. > However he does add just after that ... > > [3:44] Babbage Linden: no one else can see or return your > attachments They are not asking people for input... they're just telling you what is already decided. Nevertheless, I fail to see what this has to do with our subject, unless you belong to the confused and think now that someone else would return the objects of others when they enter the sim and need memory HAHAHAHA. > And then goes the other way 10 minutes later ... > > [3:53] Babbage Linden: Jack is going to be communicating this to > people > > [3:53] Babbage Linden: when the limits are enforced, you will end up > with objects being returned Sorry, but that is not "the other way". Objects being returned by the system is not the same as objects being returned by others. Also, this refers to a one-time moment: the moment the limits are switched on, objects will be returned to force you within your limit. From that moment on you will never be able to rez the same amount of objects (with scripts) again, you will not be able to use more than your tiny share, even if the server is totally unloaded; so after that is not needed to ever return objects. > [3:54] Babbage Linden: but hopefully everyone will have enough time > to manage their attachments before that happens Semantic translation: no reason to shout that returning random objects is unfair, because then you should have decided what jewels and/or other attachments you are wearing now to delete yourself, before we enforce the limits. > So, yeah, I can understand why people are concerned. Well, you confuse the "fixed limit" approach that LL is going to force down our throats with no means to chance anything about that, which will only return most of your objects once,... with the "dynamic limit" approach that was proposed, where objects are never returned and only stop running temporarily at those moments that the sim is REALLY loaded too heavily. -- Carlo Wood From carlo at alinoe.com Tue Dec 22 04:53:50 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 22 Dec 2009 13:53:50 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <9e877f170912200855k79697b62u32ded9021459473d@mail.gmail.com> References: <9e877f170912200855k79697b62u32ded9021459473d@mail.gmail.com> Message-ID: <20091222125350.GD10705@alinoe.com> On a private estate (sorry, but I really can't care less what happens on mainland), you pay for the server. A full sim costs $295 per month. Imho, what you pay for is the server, not the land. Obviously, it should be possible to USE all resources of that server the way you want. If something is CHANGED that makes that impossible then Linden Lab breaks a contract, and they deserve the largest riot thinkable. With the current proposal it would NOT be possible anymore to use all the resources of a private sim unless you have every parcel owned by the same avatar, and even then you still will lose memory to some unused "avatar pool" to let no less than 35 losers teleport to your sim (who says I want to allow them to teleport to my sim??) that all want to use the maximum amount of ram, which THUS has to be taken from the resources that I PAY for, taken from the owner - so he can no longer use that memory for scripts in objects. No excuse me, but who is paying for the resources of that sim again? The sim owner or those 35 losers that I don't want on my sim anyway? On Sun, Dec 20, 2009 at 10:55:09AM -0600, Cincia Singh wrote: > Over commitment of sim resources is what brought us to this conversation in the > first place. > Having a hard parcel limit is how SL avoids over commitment for prims and it's > likely > the only solution that will work for scripts; both are what we pay tier for. -- Carlo Wood From dgothly at erotobotics.com Tue Dec 22 05:07:47 2009 From: dgothly at erotobotics.com (Darrius Gothly) Date: Tue, 22 Dec 2009 08:07:47 -0500 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration References: <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> <20091222115321.GA10705@alinoe.com> <20091222123708.GC10705@alinoe.com> Message-ID: Nah, I didn't confuse other people returning objects with the system returning them. But you do raise a good point, and one that I think needs "official" clarification. If, as you read it (and you make a good point too), the "Item Return" procedure is limited only to the day they switch limits on, then that's a reasonable one-time hit that people will just have to live with. On that, I totally agree. However, the whole issue of returning objects has been tossed around from so many angles that there is no clear definitive statement as to exactly what they intend to do. I also have issues with "stopping scripts" when memory limits are exceeded. I have several devices that perform a sequence of database updates depending on options chosen and other conditions. I have done as much as programmatically possible to "batch" these transactions so they cannot be interrupted mid-update, but with LSL and its external access capabilities, that isn't always possible. Some of those situations could result in massive failure, perhaps even loss of money, if the updates are only partially completed. (Yes, I'm being a bit extreme, and yes, I've made double sure my devices cannot fail that horribly, but not everyone that scripts is skilled or experienced in DB/transaction philosophy.) LL really should consider an option on an Object called "Do Not Suspend", perhaps limiting that to 1 Object per 100sqm or some such, so critical items such as remote deposit boxes, ATMs, and other money handling devices cannot be suspended at all. Maybe the presence of a money() event and the http_response()/http_request() events in a State would exclude that script from suspension eligibility, although that would open it up to abuse as folks would just put those events in every script state to prevent suspension no matter what. ----- Original Message ----- From: "Carlo Wood" > On Tue, Dec 22, 2009 at 07:08:38AM -0500, Darrius Gothly wrote: >> llEndScript(integer die=FALSE); ? Or maybe a parameter with constants: >> ENDSCRIPT_END, ENDSCRIPT_RETURN, ENDSCRIPT_DIE >> >> >> The comment about "returning objects" comes from Babbage's office hours >> on >> the 9th of this month where he makes a comment about it. > > Haha, if that is true - then the average IQ on this list > is a lot lower than I had expected. So, Babbage says: > >> [3:42] Babbage Linden: that will include functionality for >> finding >> and returning scripted objects >> >> [3:42] Babbage Linden: so everyone will be able to find and clean >> up >> the scripts they don't need >> >> [3:43] Babbage Linden: before we start enforcing limits > > which means that IF they would implement a new LSL function > called llEndScript that allows one to pass a parameter "ENDSCRIPT_RETURN" > THEN (after adding that to all scripts) one could have a script return > the object it is in (as function of detected circumstance, like not > needing the script to run or exist). > > And then people think that if I mention "dynamic limits" that that means > that if a script that is running and then can't run anymore because it's > memory is needed by a script with a higher priority, then the first > script is automatically returned by the server... > > Those those two have so little to do with eachother I don't know where > to begin to draw a parallel that shows how little. > > So, to be clear: No those are TOTALLY different subjects. And I never > said that objects had to be returned. On the contrary, that would be > a poor implementation as well. The simplest implementation that is > reasonable is to stop scripts that lose their memory (so they would > have to be manually restarted), and refuse to start scripts that don't > have memory at that moment, and probably to refuse to rez objects > with scripts that wouldn't have memory. However(!) that is a rather > poor implementation as well. A lot better would be to stop scripts, > but swap them out to harddisk to preserve their state and automatically > resume where they were once there is memory again. Even better > would be to tell the scripts that they are swapped out and let them > deal with that fact at a very low pace (where one could then do: > > state_stasis { > llEndScript(ENDSCRIPT_RETURN); > } > > in the chickens of my chicken-shoot example ;)... cause I'd have > no problem with the excess chickens to disappear. > Hopefully that isn't going to confuse people. > >> However he does add just after that ... >> >> [3:44] Babbage Linden: no one else can see or return your >> attachments > > They are not asking people for input... they're just telling you > what is already decided. Nevertheless, I fail to see what this has > to do with our subject, unless you belong to the confused and think > now that someone else would return the objects of others when > they enter the sim and need memory HAHAHAHA. > >> And then goes the other way 10 minutes later ... >> >> [3:53] Babbage Linden: Jack is going to be communicating this to >> people >> >> [3:53] Babbage Linden: when the limits are enforced, you will end >> up >> with objects being returned > > Sorry, but that is not "the other way". Objects being returned by the > system is not the same as objects being returned by others. > > Also, this refers to a one-time moment: the moment the limits are switched > on, objects will be returned to force you within your limit. From that > moment > on you will never be able to rez the same amount of objects (with scripts) > again, you will not be able to use more than your tiny share, even if the > server is totally unloaded; so after that is not needed to ever return > objects. > >> [3:54] Babbage Linden: but hopefully everyone will have enough >> time >> to manage their attachments before that happens > > Semantic translation: > > no reason to shout that returning random objects is unfair, because then > you should have decided what jewels and/or other attachments you are > wearing > now to delete yourself, before we enforce the limits. > >> So, yeah, I can understand why people are concerned. > > Well, you confuse the "fixed limit" approach that LL is going to force > down our throats with no means to chance anything about that, which will > only return most of your objects once,... with the "dynamic limit" > approach > that was proposed, where objects are never returned and only stop > running temporarily at those moments that the sim is REALLY loaded too > heavily. > > -- > Carlo Wood > From carlo at alinoe.com Tue Dec 22 05:07:40 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 22 Dec 2009 14:07:40 +0100 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory In-Reply-To: References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> <36990292-C5F7-4602-94BE-0BE780A2E961@gmail.com> Message-ID: <20091222130740.GE10705@alinoe.com> The whole "resource / payment / number of prims" as function of land area is nonsense to begin with. Virtual land area costs NOTHING whatsoever. The reason that LL lets you pay for land is because that system brings them more money than when land would be free and you have to pay only for prims. THAT would have been an honest system however: let everyone have their own private tropical island (which costs nada), and only let them pay for the actual resources (memory and cpu time) that they use. ... But no... now we're even going to pay for memory that we can't use... grrrr. On Sun, Dec 20, 2009 at 07:32:26AM -0800, Lillian Yiyuan wrote: > Also, a square meter allocation is wrong, since meters go up in larger > and larger steps with tier paid up to the size of the sim. Instead it > should be in steps, not meters. For example it is 195 to rent an > entire sim on mainland, but 5 dollars to rent the first 512 after your > base 512. That means that if the large owner were paying at the same > rate, he or she would have to pay $640 USD. Doing it by meters would > make small parcel owners have to pay much more for the same resource. > A very good way to drive tier holders out, is to put them, again, on > the short end of a system that favors big land owners substantiall, > inthis case by as much as a factor of 3, for resource allocation. -- Carlo Wood From dzonatas at gmail.com Tue Dec 22 05:44:10 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Tue, 22 Dec 2009 05:44:10 -0800 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <20091222125350.GD10705@alinoe.com> References: <9e877f170912200855k79697b62u32ded9021459473d@mail.gmail.com> <20091222125350.GD10705@alinoe.com> Message-ID: <4B30CD2A.3000407@gmail.com> Carlo Wood wrote: > On a private estate (sorry, but I really can't care less what > happens on mainland), you pay for the server. A full sim costs > $295 per month. Imho, what you pay for is the server, not the land. > Maybe people don't want land but they want an avatar with their attachments, and thus they want to pay premium in order to make sure their avatar works everywhere despite what the land owner wants. > Obviously, it should be possible to USE all resources of that > server the way you want. If something is CHANGED that makes that > impossible then Linden Lab breaks a contract, and they deserve > the largest riot thinkable. > If someone is not interested in land ownership, why should land limits affect the avatar? Of course, we know the basic reason why, yet there are scripts/attachments that don't need to be governed by land limits at all. I know you express the desire to be able to use all the resource of the server. An avatar may want to be able to "roam" at the premium rate. In order to achieve the roam-ability, there will be a need to separate land/sim based scripts from avatar only based scripts. Let's say an avatar has prim hair that consists of 50 objects. There has been a script in each object so that color change is possible. Now, with llEndScript(), a script doesn't need to stay in each object after the color change. In fact, if color change is the only thing the script does, it doesn't even need to execute on the same sim the avatar is on. The script(s) could execute on machine XXX and then update the region the avatar is in, which might be needed in order to route packets to the clients that color change was done. The route through the region could be avoided, but I assumed the worst. There would be no need to stop these scripts just because parcel YYY is has no resources allocated to it or sim ZZZ's owner wants to allocate resources in a way that would not be friendly to premium roamers. This is why I suggested a way to flag scripts as phantom. Such scripts would never have to be executed on the sim, and when they try to use a function that actually requires them to be in the sim, then they either halt, transfer/swap their state to the sim for execution, or fail. In the case of a sim owner that has paid premium to allocate all resources, the scripts would not transfer/swap execution state to that sim at all and either would halt and/or fail. This is just the very basic concept of such differences in execution areas. I just wanted to make sure that is clear and not digress further. From carlo at alinoe.com Tue Dec 22 05:42:20 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 22 Dec 2009 14:42:20 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> <20091222115321.GA10705@alinoe.com> <20091222123708.GC10705@alinoe.com> Message-ID: <20091222134220.GA15491@alinoe.com> On Tue, Dec 22, 2009 at 08:07:47AM -0500, Darrius Gothly wrote: > LL really should consider an option on an Object called "Do Not Suspend", Hey - but they're going to do what they want anyway, as always. For a short time I had the hope that this would be the exception, since in this case there are coders involved... but it turns out that everything was already set in stone anyway (well, the most important things anyway). There is not going to a dynamic limits, so you don't have to worry about suspension :/. Anyway, maybe opensim will implement dynamic limits (no doubt they will, limits are needed and the fixed limits are ridiculous). In that case I agree with you that there needs to be a method to mark objects that they may not be suspended. This is one of the cases (there are more) where users of objects should be able to set flags on no-mod objects. This is a major issue imho. There are lots of things that the owner of a no-mod should have control over, but can't because of the way no-mod is implemented (like symlinks I'd guess, or const references). At the moment you can't even *rename* an object that is no-mod, not even if that no-mod is inherited from only a part of it. That is clearly a bug. If you delink the no-mod prim, then rename the 'root' and then relink, it DOES have a different name - so why is it not possible to rename directly? :/ So... what was I saying... Allow users to set flags (also on no-mod objects) and marking them as "do not suspend". Then only allow to rez non-suspend objects till the soft-limit. -- Carlo Wood From carlo at alinoe.com Tue Dec 22 05:54:57 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 22 Dec 2009 14:54:57 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B30CD2A.3000407@gmail.com> References: <9e877f170912200855k79697b62u32ded9021459473d@mail.gmail.com> <20091222125350.GD10705@alinoe.com> <4B30CD2A.3000407@gmail.com> Message-ID: <20091222135457.GB15491@alinoe.com> On Tue, Dec 22, 2009 at 05:44:10AM -0800, Dzonatas Sol wrote: > Maybe people don't want land but they want an avatar with their > attachments, and thus they want to pay premium in order to make sure > their avatar works everywhere despite what the land owner wants. > > >Obviously, it should be possible to USE all resources of that > >server the way you want. If something is CHANGED that makes that > >impossible then Linden Lab breaks a contract, and they deserve > >the largest riot thinkable. > > If someone is not interested in land ownership, why should land > limits affect the avatar? Of course, we know the basic reason why, > yet there are scripts/attachments that don't need to be governed by > land limits at all. I know you express the desire to be able to use > all the resource of the server. An avatar may want to be able to > "roam" at the premium rate. Bottom line is: a sim owner should have FULL control of the sim resources, and before that full control has been added, the limits may not be activated. In practise I could imagine that unrelated premium avatars can enter any sim that they are allowed to enter and have a given "reserved" amount of memory for their attachments. But I want it to be possible to use that "reserved" amount for objects when that avatar is not there. If the sim owner (read: EM, manager should have the same rights as owners, or almost) then wants to use all memory for some experiment that he doesn't want to be interrupted, he could always just close the sim so that nobody can enter anymore (or only those friends that he knows don't use excessive memory). -- Carlo Wood From carlo at alinoe.com Tue Dec 22 06:08:10 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 22 Dec 2009 15:08:10 +0100 Subject: [sldev] User needs on script limits In-Reply-To: <4B2E5A3D.3020503@gmail.com> References: <4B2E5A3D.3020503@gmail.com> Message-ID: <20091222140810.GC15491@alinoe.com> On Mon, Dec 21, 2009 at 04:09:17AM +1100, Tateru Nino wrote: > Actually, I think one of my two points earlier was that this list is > weighted specifically towards those involved in viewer development or > whom have a keen interest in that, and - as such - doesn't seem like an > appropriate or representative forum at all for the topic. I agree that this list is about the viewer, and therefore the script limits discussion doesn't "belong" here: we have no say or influence on the server code or protocol. I disagree what I speak as scripter. I speak solely as private estate owner; I also am sure that most sim owners don't have the technological background to understand that they are close to being ripped off again and fight for themselves, so I feel I do not only speak for myself, but for all those "users" that are sim owners. > Surely, there must be some more inclusive way to have a discussion about > this - if discussion it actually be. For the most part it just looks > like a whole bunch of folks (and admittedly, quite nice folks in the > main. I'm not singling anyone out, and especially not you, Lillian) who > want to get their two-cents worth heard by Linden Lab developers, and > who don't seem to have any other avenue for doing so. For me, if anywhere you got the feeling I was being mad, frustrated and not being very constructive... then that is correct. I have given up the hope to actually get through to Lindens. The only thing left is powerless frustration. If the Lindens were reasonable and ACTUALLY went into a discussion, open to technical arguments and reasoning, then we could have really talked about this in a mature and professional way; and together have designed a better system. But hey, I'm just a stupid open source VIEWER coder, and they are the Server Gods... Did you note what Babbage all posted to the forum? Two posts. One "replies" to specific issues with a one-liners stating his own unbendable ideas. There is no discussion there. Same here; with the exception of Kelly who has been the only Linden that actually came with data and info and who actually has reacted in a personal way to people (also in a few posts in the forum), but who unfortunately seems to think that there is nothing wrong with fixed limits, so no help from that side :( (my respect for him though, for treating us as human beings ;). > Heck, just doing a quick count of messages, the topic would carry its > own mailing list at this rate, and free this one up for - you know - > talking about the viewer again. :) My main concern, after every change LL makes up, is how to leave SL as soon as possible... Or to think of what is necessary to make that a good alternative :( Working on the viewer gets a bit lower priority when the fun in-world is disappearing. The world is sooo much more empty than a year ago :/ -- Carlo Wood From carlo at alinoe.com Tue Dec 22 06:16:51 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 22 Dec 2009 15:16:51 +0100 Subject: [sldev] Linkable prim over 256 In-Reply-To: <1e0db80e0912220211m4cd8054cy2ffcb56c9997f4f@mail.gmail.com> References: <4B2FCE93.3030700@gmail.com> <1e0db80e0912220211m4cd8054cy2ffcb56c9997f4f@mail.gmail.com> Message-ID: <20091222141651.GD15491@alinoe.com> Yet another thing that should be negotiated upon connection. On Tue, Dec 22, 2009 at 05:11:08AM -0500, Tori C. wrote: > On Mon, Dec 21, 2009 at 2:37 PM, Andrew Simpson wrote: > > i am trying to find the code that set the limit on 256 link on the prim > > in one, wher it is in the code source or iut in xml? let me know thank > > On the viewer side of things, look for MAX_CHILDREN_PER_TASK in > indra_constants.h and llviewermenu.cpp but as the others noted, LL's > servers use this limit too. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood From dzonatas at gmail.com Tue Dec 22 07:06:56 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Tue, 22 Dec 2009 07:06:56 -0800 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <20091222135457.GB15491@alinoe.com> References: <9e877f170912200855k79697b62u32ded9021459473d@mail.gmail.com> <20091222125350.GD10705@alinoe.com> <4B30CD2A.3000407@gmail.com> <20091222135457.GB15491@alinoe.com> Message-ID: <4B30E090.4000107@gmail.com> Carlo Wood wrote: > In practise I could imagine that unrelated premium avatars > can enter any sim that they are allowed to enter and have > a given "reserved" amount of memory for their attachments. > But I want it to be possible to use that "reserved" amount > for objects when that avatar is not there. > In the short-term with the current state of resources and tech now available, I agree with you. In the long term, there should be separation so that premium avatar and premium land aren't affected by the same limits. There is too much blur between the two right now. I think the major concern brought up in this thread is how to make it not complicated to understand. How do you explain to non-geeky a fashion model that the script used to animate her outfit needs to be redone to not make such a negative impact on the fashion show? Hehe. *wink* From dzonatas at gmail.com Tue Dec 22 07:18:15 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Tue, 22 Dec 2009 07:18:15 -0800 Subject: [sldev] User needs on script limits In-Reply-To: <20091222140810.GC15491@alinoe.com> References: <4B2E5A3D.3020503@gmail.com> <20091222140810.GC15491@alinoe.com> Message-ID: <4B30E337.2080501@gmail.com> Carlo Wood wrote: > On Mon, Dec 21, 2009 at 04:09:17AM +1100, Tateru Nino wrote: > >> Actually, I think one of my two points earlier was that this list is >> weighted specifically towards those involved in viewer development or >> whom have a keen interest in that, and - as such - doesn't seem like an >> appropriate or representative forum at all for the topic. >> > > I agree that this list is about the viewer, and therefore > the script limits discussion doesn't "belong" here: we have > no say or influence on the server code or protocol. > To both of you, since when can scripts not run on the viewer? Maybe not by how the world has been seen, but I'm "thinking outside the box" about this. I've been thinking about this for quite awhile, years before I even posted this: 'Client Script & Persistent Data Object' https://jira.secondlife.com/browse/SVC-98 Now I'm just focused in this way: 'H.I.D. API: "thinking outside the box"' https://jira.secondlife.com/browse/SNOW-375 Like, for example HID panel can pop-up that changes avatar appearance, outfit, and changes color of hair, and doesn't do it with any execution on the server. From cinciasingh at gmail.com Tue Dec 22 07:20:14 2009 From: cinciasingh at gmail.com (Cincia Singh) Date: Tue, 22 Dec 2009 09:20:14 -0600 Subject: [sldev] SLDev Digest, Vol 36, Issue 59 In-Reply-To: References: Message-ID: <9e877f170912220720k5ea20b13k7f10703da05bbc42@mail.gmail.com> > > Message: 2 > Date: Tue, 22 Dec 2009 13:53:50 +0100 > From: Carlo Wood > Subject: Re: [sldev] Script/Parcel/Memory Limits - Memory Limit > Configuration > To: Cincia Singh > Cc: sldev at lists.secondlife.com > Message-ID: <20091222125350.GD10705 at alinoe.com> > Content-Type: text/plain; charset=us-ascii > > On a private estate (sorry, but I really can't care less what > happens on mainland), you pay for the server. A full sim costs > $295 per month. Imho, what you pay for is the server, not the land. > There really is no "land" ... it's all server space and resource allocation. And don't be sorry about what you do and don't care for, the feeling is mutual ;-) > > Obviously, it should be possible to USE all resources of that > server the way you want. If something is CHANGED that makes that > impossible then Linden Lab breaks a contract, and they deserve > the largest riot thinkable. > It is obvious that it should be possible to use the resources that LL makes available to a estate. Example; we all know that an estate can support more than 15k prims, but LL only makes 15k prims available. The estate manager allocates those prims to their renters as they see fit. If a parcel on an estate has a 500 prim limit and they exceed that limit the estate manager or owner has tools at their disposal to enforce their covenant/rental agreement. A script limit could work the same. The one constant in SL is that things ALWAYS change. Well, AND a sense of entitlement (I have one myself (^-^) I just hide it) > > With the current proposal it would NOT be possible anymore > to use all the resources of a private sim unless you have every > parcel owned by the same avatar > Rehash: the only one who "owns" anything on a private estate is the person who purchased the sim from LL. Everyone else is renting from that owner. Under ANY plan for limits the estate owner would be the one who controls the parameters on their estate just as they do now. If the plan ends up being hard limits for scripts, to allocate more scripts for a parcel on an estate the estate owner would simply have to hold another parcel in reserve with no scripts on it from which to allocate those resources; just as they do now with prim limits. This is an estate management issue, not an issue about the limits themselves. And it would still be possible for the estate owner to place scripts on their estate to max out the limits. If the estate owner wanted to allow their tenants to do the same, that should also be possible. > > No excuse me, but who is paying for the resources of that > sim again? The sim owner or those 35 losers that I don't > want on my sim anyway? > Losers? You mean tenants or visitor? Can we get back to civil discourse? Once again, the estate owner controls the parameters on an estate. If an estate owner doesn't want the 35 "residents" on their estate, it's a simple matter to lock it down. Perhaps you need to better explain what it is you're having issue with. Thanks Carlo, Cin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091222/78d516b7/attachment.htm From sldev at catznip.com Tue Dec 22 07:41:13 2009 From: sldev at catznip.com (Kitty) Date: Tue, 22 Dec 2009 16:41:13 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4B2C2336.9010809@Gmail.com><4B2CCD7B.7000805@gmail.com><4B2D1175.6090601@Gmail.com><55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com><4B2E64BF.3070706@Gmail.com><840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com><4B2EC214.4000008@Gmail.com><5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com><20091222115321.GA10705@alinoe.com> Message-ID: <44525793641C475E9164D9499FECA14D@panther> > [3:42] Babbage Linden: that will include functionality for > finding and returning scripted objects > > [3:42] Babbage Linden: so everyone will be able to find and > clean up the scripts they don't need > > [3:43] Babbage Linden: before we start enforcing limits > I would hope that simply refers to what you can do today with the "Top Scripts" floater (highlight a scripted object + click return). Otherwise you'll get chaos where someone checks their sim the day before the roll-out, finds that they're within the limit, goes to bed and wakes up to dozens of auto-returns because some other group member decided to rez some new script-heavy toy they just bought which pushed it over the limit. Expecting every land or group owner all over SL to turn off build for everyone for a few days is simply not realistic, particularly given the fact that only a small portion of residents reads the blog which is only in English. Given the high failure rate of return in general if sims all over the grid start auto-returning prims then a good portion of those will go *poof* and never return to anyone's inventory. That alone should be enough to not even consider auto-returning anything. Objects should simply get their scripts disabled and then the owner can decide to leave them around "script-less" or take them back into their inventory or do something else to get them working again. Similarly rezzing should never fail because of script limits because that would make it rather impossible to fix objects after the script limits are in place. Or someone will be working on something, drop in a new script, the parcel hits its script limit, the prim gets auto-returned and then can't be rerezzed. It would also be very fun for updaters: rez the updater, updater drops new scripts into the older version, which then subsequently gets auto-returned because the limit is reached and ends up broken because it's half-old and half-new. Things won't improve if the updater gets auto-returned since it's the last to have been rezzed, or if it gets its scripts disabled halfway through. From robertltux at gmail.com Tue Dec 22 07:55:11 2009 From: robertltux at gmail.com (Robert Martin) Date: Tue, 22 Dec 2009 10:55:11 -0500 Subject: [sldev] Fwd: Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4B2CCD7B.7000805@gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> <20091222115321.GA10705@alinoe.com> <20091222123708.GC10705@alinoe.com> Message-ID: ---------- Forwarded message ---------- From: Robert Martin Date: Tue, Dec 22, 2009 at 8:23 AM Subject: Re: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration To: Darrius Gothly On Tue, Dec 22, 2009 at 8:07 AM, Darrius Gothly wrote: > Nah, I didn't confuse other people returning objects with the system > LL really should consider an option on an Object called "Do Not Suspend", > perhaps limiting that to 1 Object per 100sqm or some such, so critical items > such as remote deposit boxes, ATMs, and other money handling devices cannot > be suspended at all. Maybe the presence of a money() event and the > http_response()/http_request() events in a State would exclude that script > from suspension eligibility, although that would open it up to abuse as > folks would just put those events in every script state to prevent > suspension no matter what. > semi related subjects 1 any script suspension should consider Non-Parcel owner attachments/items first then parcel owner stuff then estate owner stuff (maybe there should be a way to send a security key to "prove" the item is a DNS item with a limit of 15 keys per avatar) 2 there needs to be a better way of seeing avatar load than ARC since the number is semi fictional (it counts prims more heavily than scripts) 3 Please create a way to lock edit on an object by UUID (or even allow deletion) right now in my skybox i have an item that is unselectable (cloaking script) and i would like to remove it without doing a complete rebuild -- Robert L Martin -- Robert L Martin From dgothly at erotobotics.com Tue Dec 22 07:59:53 2009 From: dgothly at erotobotics.com (Darrius Gothly) Date: Tue, 22 Dec 2009 10:59:53 -0500 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration References: <4B2C2336.9010809@Gmail.com><4B2CCD7B.7000805@gmail.com><4B2D1175.6090601@Gmail.com><55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com><4B2E64BF.3070706@Gmail.com><840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com><4B2EC214.4000008@Gmail.com><5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com><20091222115321.GA10705@alinoe.com> <44525793641C475E9164D9499FECA14D@panther> Message-ID: <2EF6993A5EE340498E505E4CCD2C9A92@jbh3000> Another issue came to mind as I was reading this ... How does anyone know the script has been disabled? I mean, what's to indicate it's a system-imposed "malfunction" vs. one that just happened because the script hit a bug? And "screaming on the DEBUG CHANNEL" just isn't sufficient because the owner may not even be logged in when the system disables the script. There has to be something plainly evident (at least to the owner if not everyone else) indicating the object has been disabled by the Sim/System. Perhaps one of those little floating icons like is seen when there is a script error, but that stays around until the object is deleted, taken or returned ... or restarted. And of course that will require an additional attribute per Prim. ----- Original Message ----- From: "Kitty" To: "'SLDEV'" Sent: Tuesday, December 22, 2009 10:41 AM Subject: Re: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration >> [3:42] Babbage Linden: that will include functionality for >> finding and returning scripted objects >> >> [3:42] Babbage Linden: so everyone will be able to find and >> clean up the scripts they don't need >> >> [3:43] Babbage Linden: before we start enforcing limits >> > > I would hope that simply refers to what you can do today with the "Top > Scripts" floater (highlight a scripted object + click return). > > Otherwise you'll get chaos where someone checks their sim the day before > the > roll-out, finds that they're within the limit, goes to bed and wakes up to > dozens of auto-returns because some other group member decided to rez some > new script-heavy toy they just bought which pushed it over the limit. > > Expecting every land or group owner all over SL to turn off build for > everyone for a few days is simply not realistic, particularly given the > fact > that only a small portion of residents reads the blog which is only in > English. > > Given the high failure rate of return in general if sims all over the grid > start auto-returning prims then a good portion of those will go *poof* and > never return to anyone's inventory. That alone should be enough to not > even > consider auto-returning anything. > > Objects should simply get their scripts disabled and then the owner can > decide to leave them around "script-less" or take them back into their > inventory or do something else to get them working again. > > Similarly rezzing should never fail because of script limits because that > would make it rather impossible to fix objects after the script limits are > in place. Or someone will be working on something, drop in a new script, > the > parcel hits its script limit, the prim gets auto-returned and then can't > be > rerezzed. > > It would also be very fun for updaters: rez the updater, updater drops new > scripts into the older version, which then subsequently gets auto-returned > because the limit is reached and ends up broken because it's half-old and > half-new. Things won't improve if the updater gets auto-returned since > it's > the last to have been rezzed, or if it gets its scripts disabled halfway > through. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From imaze.rhiano at gmail.com Tue Dec 22 09:53:07 2009 From: imaze.rhiano at gmail.com (Imaze Rhiano) Date: Tue, 22 Dec 2009 19:53:07 +0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <2EF6993A5EE340498E505E4CCD2C9A92@jbh3000> References: <4B2C2336.9010809@Gmail.com><4B2CCD7B.7000805@gmail.com><4B2D1175.6090601@Gmail.com><55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com><4B2E64BF.3070706@Gmail.com><840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com><4B2EC214.4000008@Gmail.com><5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com><20091222115321.GA10705@alinoe.com> <44525793641C475E9164D9499FECA14D@panther> <2EF6993A5EE340498E505E4CCD2C9A92@jbh3000> Message-ID: <4B310783.8050109@gmail.com> In LL's current proposal is that you (or your object) can't rezz object to parcel, if script's in rezzing object doesn't fit to parcel's memory. In this case, you will get error message box - or - if your object is trying to rezz another object, then rezzing function fails and there is likely going to be error message in debug channel. Same is happening, if you try to attach object which scripts don't fit to your avatar memory (avatar's memory is separated from parcel's memory). Exception for this rule would be sandbox sims - they wouldn't have memory limits - so you can rezz any object there. Vehicles are special case - (I think that) they are using parcel's memory in their current location. Don't know, what happens for scripts in vehicle, if parcel where they enter doesn't have enough memory. Maybe they are not able to enter such parcels. So - in LL's proposal - scripts are not being disabled because of memory limits - it is not possible to rezz objects that are using too much memory. Darrius Gothly kirjoitti: > Another issue came to mind as I was reading this ... > > How does anyone know the script has been disabled? I mean, what's to > indicate it's a system-imposed "malfunction" vs. one that just happened > because the script hit a bug? And "screaming on the DEBUG CHANNEL" just > isn't sufficient because the owner may not even be logged in when the system > disables the script. There has to be something plainly evident (at least to > the owner if not everyone else) indicating the object has been disabled by > the Sim/System. Perhaps one of those little floating icons like is seen when > there is a script error, but that stays around until the object is deleted, > taken or returned ... or restarted. And of course that will require an > additional attribute per Prim. > > ----- Original Message ----- > From: "Kitty" > To: "'SLDEV'" > Sent: Tuesday, December 22, 2009 10:41 AM > Subject: Re: [sldev] Script/Parcel/Memory Limits - Memory Limit > Configuration > > > >>> [3:42] Babbage Linden: that will include functionality for >>> finding and returning scripted objects >>> >>> [3:42] Babbage Linden: so everyone will be able to find and >>> clean up the scripts they don't need >>> >>> [3:43] Babbage Linden: before we start enforcing limits >>> >>> >> I would hope that simply refers to what you can do today with the "Top >> Scripts" floater (highlight a scripted object + click return). >> >> Otherwise you'll get chaos where someone checks their sim the day before >> the >> roll-out, finds that they're within the limit, goes to bed and wakes up to >> dozens of auto-returns because some other group member decided to rez some >> new script-heavy toy they just bought which pushed it over the limit. >> >> Expecting every land or group owner all over SL to turn off build for >> everyone for a few days is simply not realistic, particularly given the >> fact >> that only a small portion of residents reads the blog which is only in >> English. >> >> Given the high failure rate of return in general if sims all over the grid >> start auto-returning prims then a good portion of those will go *poof* and >> never return to anyone's inventory. That alone should be enough to not >> even >> consider auto-returning anything. >> >> Objects should simply get their scripts disabled and then the owner can >> decide to leave them around "script-less" or take them back into their >> inventory or do something else to get them working again. >> >> Similarly rezzing should never fail because of script limits because that >> would make it rather impossible to fix objects after the script limits are >> in place. Or someone will be working on something, drop in a new script, >> the >> parcel hits its script limit, the prim gets auto-returned and then can't >> be >> rerezzed. >> >> It would also be very fun for updaters: rez the updater, updater drops new >> scripts into the older version, which then subsequently gets auto-returned >> because the limit is reached and ends up broken because it's half-old and >> half-new. Things won't improve if the updater gets auto-returned since >> it's >> the last to have been rezzed, or if it gets its scripts disabled halfway >> through. >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From secret.argent at gmail.com Tue Dec 22 10:41:01 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue, 22 Dec 2009 12:41:01 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <20091222115321.GA10705@alinoe.com> References: <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> <20091222115321.GA10705@alinoe.com> Message-ID: <6A9C459E-B5B2-42E4-87CE-AFF1D0AFC9DC@gmail.com> On 2009-12-22, at 05:53, Carlo Wood wrote: > I already commented on this before imho... Yes it is possible > to run scripts that are on harddisk; although I'm not sure > you can use a part of the OS that easily to achieve it. > Imho, you could let a script run for 1 ms (100 scripts at a time) > every 3 seconds, only using 6.4 MB of RAM that is refreshed > from disk (with 100 next scripts) every 100 ms. The reason that thrashing virtual memory is a problem is because disk I/O is a bottleneck. Adding more disk I/O is not the solution. > The talk that I see about objects being returned... I don't > know where that comes from. From the original announcement and in-world comments by Babbage Linden. > Why would you want to return objects? Because that's the simplest and most efficient and reliable way to remove scripts from memory without causing data loss. From secret.argent at gmail.com Tue Dec 22 10:43:27 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue, 22 Dec 2009 12:43:27 -0600 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory In-Reply-To: <20091222130740.GE10705@alinoe.com> References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> <36990292-C5F7-4602-94BE-0BE780A2E961@gmail.com> <20091222130740.GE10705@alinoe.com> Message-ID: <07136CD8-99A9-4BF6-9198-773E6F9B5288@gmail.com> On 2009-12-22, at 07:07, Carlo Wood wrote: > The whole "resource / payment / number of prims" as function of land > area is nonsense to begin with. It's no more nonsense than having virtual land at all. And it works better than the previous system where you paid for prims did. From secret.argent at gmail.com Tue Dec 22 10:46:50 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue, 22 Dec 2009 12:46:50 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B30CD2A.3000407@gmail.com> References: <9e877f170912200855k79697b62u32ded9021459473d@mail.gmail.com> <20091222125350.GD10705@alinoe.com> <4B30CD2A.3000407@gmail.com> Message-ID: <6562FA53-57F5-447A-993E-D2DF4426FDD8@gmail.com> On 2009-12-22, at 07:44, Dzonatas Sol wrote: > If someone is not interested in land ownership, why should land limits > affect the avatar? They won't. Babbage has said that each avatar will have a script quota independent of the land it's on. From techiedavid at gmail.com Tue Dec 22 10:52:01 2009 From: techiedavid at gmail.com (David Simmons) Date: Tue, 22 Dec 2009 10:52:01 -0800 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory In-Reply-To: <20091222130740.GE10705@alinoe.com> References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> <36990292-C5F7-4602-94BE-0BE780A2E961@gmail.com> <20091222130740.GE10705@alinoe.com> Message-ID: <3a164ef30912221052o325d6d8ey17774240c6bcfd85@mail.gmail.com> On Tue, Dec 22, 2009 at 5:07 AM, Carlo Wood wrote: > The whole "resource / payment / number of prims" as function of land > area is nonsense to begin with. > > Virtual land area costs NOTHING whatsoever. The reason that LL lets > you pay for land is because that system brings them more money > than when land would be free and you have to pay only for prims. > > Virtual land do have real costs!. There are electrical costs, actual servers and physical san that cost money, support cost. As far as I know, Linden do not get free network connection to the internet. An Linden employees don't work for free. > THAT would have been an honest system however: let everyone have > their own private tropical island (which costs nada), and only > let them pay for the actual resources (memory and cpu time) that > they use. > > A cloud computing fee structure would be nice, but the current OS will have to be rewritten. Right now, a sim takes alot of resources even if noones visit it for months. In SL a tree falling in a forest and no one is around does make a sound. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091222/4782db1b/attachment.htm From secret.argent at gmail.com Tue Dec 22 10:53:46 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue, 22 Dec 2009 12:53:46 -0600 Subject: [sldev] Fwd: Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4B2CCD7B.7000805@gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> <20091222115321.GA10705@alinoe.com> <20091222123708.GC10705@alinoe.com> Message-ID: People keep talking about a hypothetical "suspended" state for scripts. That will not happen. It's not in the plan as described by Babbage, and it would be very difficult to implement in a way that actually delivered on the memory savings that are needed. From kelly at lindenlab.com Tue Dec 22 11:01:13 2009 From: kelly at lindenlab.com (Kelly Linden) Date: Tue, 22 Dec 2009 11:01:13 -0800 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory In-Reply-To: <20091222130740.GE10705@alinoe.com> References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> <36990292-C5F7-4602-94BE-0BE780A2E961@gmail.com> <20091222130740.GE10705@alinoe.com> Message-ID: On Tue, Dec 22, 2009 at 5:07 AM, Carlo Wood wrote: > The whole "resource / payment / number of prims" as function of land > area is nonsense to begin with. > > Virtual land area costs NOTHING whatsoever. The reason that LL lets > you pay for land is because that system brings them more money > than when land would be free and you have to pay only for prims. > > THAT would have been an honest system however: let everyone have > their own private tropical island (which costs nada), and only > let them pay for the actual resources (memory and cpu time) that > they use. > > ... But no... now we're even going to pay for memory that we > can't use... grrrr. > I just want to point out that what you state above is essentially entirely not true. While it may be possible to design a system like that, SL is not designed like that. I don't want to debate system design, there are many trade offs between many different possible designs and SL has many shortcomings. However the way SL currently works ties a fixed area of land to system resources, and no debating virtual world designs is going to change that right now. Virtual land *does* cost nearly the same in SL whether empty or full, it runs the same code, takes the same maintenance and the same support. The differences in power and bandwidth based on content is minimal if measurable at all. Do you get furious when your neighbors don't use all their prims? Or that you can't use the prims they don't? That is essentially the same argument. We use land as a metaphor for available resources because it is easy and it makes sense to most people. If you own half the region you can use half the prims, if you own a quarter then you get a quarter. We do this for prims and not only does it make sense and is understood but it was lauded when we introduced it because it solved a lot of 'tragedy of the commons' problems similar to what we have with script resources today. What we hope to do is extend the same model with the same clarity and flexibility for estate owners to the other resources available to regions. In the end when we lease land we are leasing out a portion of the server resources directly proportional to the amount of land owned. If you bought 10% of a region but are using 90% of the resources then you are being unfair to your neighbors and getting more than you pay for. In the future it isn't that you are "going to pay for memory that you can't use" it is that you will no longer be able to use resources you aren't paying for. "Bottom line is: a sim owner should have FULL control of the sim resources, and before that full control has been added, the limits may not be activated." I agree with this, and this is our goal - as long as you account for the fact that a region/sim is not a full host server and needs to share the total hosts resources with the other regions running on that host. Estate owners should be able to do with script resources what they can currently do with prim resources. - Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091222/847a25df/attachment.htm From carlo at alinoe.com Tue Dec 22 12:02:54 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 22 Dec 2009 21:02:54 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <6562FA53-57F5-447A-993E-D2DF4426FDD8@gmail.com> References: <9e877f170912200855k79697b62u32ded9021459473d@mail.gmail.com> <20091222125350.GD10705@alinoe.com> <4B30CD2A.3000407@gmail.com> <6562FA53-57F5-447A-993E-D2DF4426FDD8@gmail.com> Message-ID: <20091222200254.GA4235@alinoe.com> On Tue, Dec 22, 2009 at 12:46:50PM -0600, Argent Stonecutter wrote: > On 2009-12-22, at 07:44, Dzonatas Sol wrote: > > If someone is not interested in land ownership, why should land limits > > affect the avatar? > > They won't. Babbage has said that each avatar will have a script quota > independent of the land it's on. Yes, and that is what we don't want. It makes no sense to reserve memory of EVERY private sim, paid for by their respective owners, for heavy avatars that are normally not there. If this is how it's going to be then those avatars should pay for the sim, and the prices for the sim owners should go down. And hell, we're ONLY talking about memory yet, not cpu time... but you all know where this is heading right? In a year you won't even be able to use your cpu that you pay for anymore, or at most a fraction of it, because "cpu time has to be reserved JUST IN CASE suddenly all kind of fashion models want to join your sim. Seems I'm the only sim owner here, or everyone is plain mad. -- Carlo Wood From carlo at alinoe.com Tue Dec 22 12:15:43 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 22 Dec 2009 21:15:43 +0100 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory In-Reply-To: References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> <36990292-C5F7-4602-94BE-0BE780A2E961@gmail.com> <20091222130740.GE10705@alinoe.com> Message-ID: <20091222201543.GB4235@alinoe.com> On Tue, Dec 22, 2009 at 11:01:13AM -0800, Kelly Linden wrote: > you are being unfair to your neighbors and getting more than you pay for.? In > the future it isn't that you are "going to pay for memory that you can't use" > it is that you will no longer be able to use resources you aren't paying for. I'd like to point out that this is not true too. If 10 residents rent together a sim, and they are hardly ever at the same time online (people really only use SL 1 or 2 hours per day, and different time zones does the rest), then that means that the sim is being used by ONE person at a time 10 to 20 hours per day. Since together they pay for the full sim and all the resources it has, then they have the right to use those 100% of those resources 24 hours per day. Given that normally there are only 1 or 2 users in-world, it is very unfair to suddenly limit the resources they can use to 1/10th -- tuned the never-occuring situation that they are there all 10 at the same time. The result is simply that the group pays for the resources of a full sim, but only (can) use 1/10th ON AVERAGE in practise, because nobody can use more, not even while they are alone, and they are always alone (in this extreme example). Sorry, but if you defend your new fixed limit system with "it's fair, because you only pay for that part" then I'm truelly, really amazed how someone like you can make such a terrible thinking error :( -- Carlo Wood From maggie at matrisync.com Tue Dec 22 13:05:28 2009 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Tue, 22 Dec 2009 16:05:28 -0500 Subject: [sldev] Script memory limits, promises, parcel bonus Message-ID: Kelly Linden wrote: > ?Estate owners should be able to do with script resources what they > can currently do with prim resources. I hope that includes overcomitting individual parcels in the way the current "parcel bonus" allows, because otherwise the management of our current sim will be nearly impossible. We manage prims per shareholder, not per parcel, as our shareholders can and do rez prims... (including vehicles, remeber SVC-22? We sure do! And it's still not fixed... Babbage says script memory for vehicles is going to be deducted from the parcel quota...joy) ... throughout the sim. The shareholders do own parcels, for the purpose of controlling access rights and media settings. I haven't heard anybody promise this facility will be available when script memory limits are implemented yet. I can just imagine how this is going to happen, we'll be ignored until the last minute, and then dismissed as an "edge case", and told to submit an enhancement JIRA. From secret.argent at gmail.com Tue Dec 22 13:06:33 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue, 22 Dec 2009 15:06:33 -0600 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <20091222200254.GA4235@alinoe.com> References: <9e877f170912200855k79697b62u32ded9021459473d@mail.gmail.com> <20091222125350.GD10705@alinoe.com> <4B30CD2A.3000407@gmail.com> <6562FA53-57F5-447A-993E-D2DF4426FDD8@gmail.com> <20091222200254.GA4235@alinoe.com> Message-ID: On 2009-12-22, at 14:02, Carlo Wood wrote: > On Tue, Dec 22, 2009 at 12:46:50PM -0600, Argent Stonecutter wrote: >> On 2009-12-22, at 07:44, Dzonatas Sol wrote: >>> If someone is not interested in land ownership, why should land >>> limits >>> affect the avatar? >> They won't. Babbage has said that each avatar will have a script >> quota >> independent of the land it's on. > Yes, and that is what we don't want. Anything else would be completely stark raving insane, so, yes, that's exactly what we do want. From jamey at beau.org Tue Dec 22 13:13:57 2009 From: jamey at beau.org (Jamey Fletcher) Date: Tue, 22 Dec 2009 15:13:57 -0600 Subject: [sldev] SLDev Digest, Vol 36, Issue 59 In-Reply-To: <9e877f170912220720k5ea20b13k7f10703da05bbc42@mail.gmail.com> References: <9e877f170912220720k5ea20b13k7f10703da05bbc42@mail.gmail.com> Message-ID: <4B313695.1060308@beau.org> Cincia Singh wrote: > It is obvious that it should be possible to use the resources that LL > makes available to a estate. Example; we all know that an estate can > support more than 15k prims, but LL only makes 15k prims available. The > estate manager allocates those prims to their renters as they see fit. > If a parcel on an estate has a 500 prim limit and they exceed that limit > the estate manager or owner has tools at their disposal to enforce their > covenant/rental agreement. A script limit could work the same. Actually, LL only makes 15,000 prims available for building with. It's obvious a SIM supports a lot more prims - it's rather common for prim hair to have 100+ prims. In point of fact, a single AV, using *JUST* the LL avatar attachment points (not counting the HUD points), can have 7640 prims attached (30 points, 255 prims per point). That's half a SIM worth of prims on *ONE* AV (and suggests a means of having your cake and eating it too in a shopping mall...) You put 40 AVs (mainland max) in a SIM, and that's 20x as many prims as are available for building with. Admitted, attachment prims don't affect the physics engine as far as I can tell - they don't change your AVs bounding box - but they still have to be accounted for, visibility tracked, etc. So I can quite understand Linden Labs not being in a hurry to increase the SIM building prim limits - people have built AVs far more than I imagine they ever expected. [I'd hate for my SIM to be on the same server as Money Island's SIM, with 100 AVs, wearing 50x as many prims as the SIM has available for building. From kelly at lindenlab.com Tue Dec 22 13:15:25 2009 From: kelly at lindenlab.com (Kelly Linden) Date: Tue, 22 Dec 2009 13:15:25 -0800 Subject: [sldev] Script memory limits, promises, parcel bonus In-Reply-To: References: Message-ID: On Tue, Dec 22, 2009 at 1:05 PM, Maggie Leber (sl: Maggie Darwin) < maggie at matrisync.com> wrote: > Kelly Linden wrote: > > Estate owners should be able to do with script resources what they > > can currently do with prim resources. > > I hope that includes overcomitting individual parcels in the way the > current "parcel bonus" allows, because otherwise the management of our > current sim will be nearly impossible. > I am sure I have said this many times but it gets lost in the flood of discussion. At the very least this is exactly what we want to support. I think the version I have right now conflates the two (a prim bonus of 2x causes a resource bonus of 2x) but that is largely because I didn't want to work on viewer UI while working on the simulator. > > We manage prims per shareholder, not per parcel, as our shareholders > can and do rez prims... > > (including vehicles, remeber SVC-22? We sure do! And it's still not > fixed... Babbage says script memory for vehicles is going to be > deducted from the parcel quota...joy) > This is true and not true. The following rules must be taken into account together: * A "vehicle" will use the resources of the first sitting agent that has enough available resources for the vehicle * In the case that no sitting agents have enough available resource we will fall back to trying to use parcel resources before failing. (In other words we try our hardest to find resources) * A "vehicle" for the above is any object that has 1 or more agents sitting on it and has crossed a parcel border. The last rule is tricky but we don't want someone to effect the resources of a vendor by sitting on it, and there are too many types of vehicles to have a rule be anything other than that it has someone sitting on it. So we do a kind of lazy promotion to vehicle. If someone is sitting on it and it moves enough to cross a parcel border then it becomes a vehicle and the resources move accordingly. Yes this is more complicated than I would have liked, but is the simplest possible that manages the requirements I think. > ... throughout the sim. The shareholders do own parcels, for the > purpose of controlling access rights and media settings. > > I haven't heard anybody promise this facility will be available when > script memory limits are implemented yet. > I have, but I've done it again in this email now. > > I can just imagine how this is going to happen, we'll be ignored until > the last minute, and then dismissed as an "edge case", and told to > submit an enhancement JIRA. > I don't know of any way to be more proactive on this issue than I have. Also, as I posted my peeve earlier - do not conflate 'ignoring' with 'not doing what I asked'. We will not and can not do everything everyone asks, it is a pure impossibility given the many different and often contradictory requests. We aren't ignoring the discussion on the topic though. - Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091222/926d857f/attachment.htm From secret.argent at gmail.com Tue Dec 22 13:19:03 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue, 22 Dec 2009 15:19:03 -0600 Subject: [sldev] Script memory limits, promises, parcel bonus In-Reply-To: References: Message-ID: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> On 2009-12-22, at 15:05, Maggie Leber (sl: Maggie Darwin) wrote: > (including vehicles, remeber SVC-22? We sure do! And it's still not > fixed... Babbage says script memory for vehicles is going to be > deducted from the parcel quota...joy) Yes, SVC-22 needs to be fixed before this is rolled out. How hard could it be to add one more chunk to the package passed from sim to sim saying "this is a vehicle being sat on by "? From maggie at matrisync.com Tue Dec 22 13:31:25 2009 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Tue, 22 Dec 2009 16:31:25 -0500 Subject: [sldev] Script memory limits, promises, parcel bonus In-Reply-To: References: Message-ID: On Tue, Dec 22, 2009 at 4:15 PM, Kelly Linden wrote: > I am sure I have said this many times but it gets lost in the flood of > discussion. ?At the very least this is exactly what we want to support. ?I > think the version I have right now conflates the two (a prim bonus of 2x > causes a resource bonus of 2x) but that is largely because I didn't want to > work on viewer UI while working on the simulator. Thanks for responding. We really need a central place for information and discussion on this. There's various office hours transcripts, blogposts here and there, and participation on at least two mailing lists. How about a wiki page as a central repository for what is planned? Or is there one already and I just don't know about it? > I don't know of any way to be more proactive on this issue than I have. > ?Also, as I posted my peeve earlier - do not conflate 'ignoring' with 'not > doing what I asked'. Your explanation sounds like it's good enough for me. I don't need exactly any solution I've proposed, because I don't really have a solution. I just need to know there's a way we're going to be able to address this new constraint without rebuilding our sim charter and policies from zero. From maggie at matrisync.com Tue Dec 22 13:48:28 2009 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Tue, 22 Dec 2009 16:48:28 -0500 Subject: [sldev] Script memory limits, promises, parcel bonus In-Reply-To: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> References: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> Message-ID: On Tue, Dec 22, 2009 at 4:19 PM, Argent Stonecutter wrote: > Yes, SVC-22 needs to be fixed before this is rolled out. > How hard could it be to add one more chunk to the package passed from sim to > sim saying "this is a vehicle being sat on by "? Hard enough that SVC-22 was reported in February of *2007* and is still unfixed. And let's not forget related issue SVC-1070, which is only two years old, instead of nearly three. Kelly asks we not conflate "ignoring" with "not doing what I ask", that being a pet peeve. I'm asking nothing more specific on these two than they be *fixed*, and if that's too specific after two and three years respectively, then folks will just have to pardon me for thinking they're actually being ignored. I guess that's *my* peeve. With these existing bugs in enforcement of resource limits having remained unaddressed this long, some of us are a little cynical about new promises made now that we're being asked to bear the brunt of a new "solution" to growing server performance issues. It took a lot of yelling and crying before we could even see the script time being consumed on avatar attachments (although heads-up if the avatar is sitting on a prim, the time will be reported twice, once for the avatar and again for the object they're sitting on....vehicle or otherwise. Good luck with two or three heavily scripted avatars on cuddle couch) I don't know how much time anybody has spent lately looking at the numbers reported by "Top Scripts" out on real sims on Agni, but they certainly lack credibility in my mind. I rather suspect scripts are being charged execution clock time while the region is swapped out running other work; it's the only explanation I can think of for some of the outlandish spikes I'm seeing reported for otherwise well-behaved scripted objects. If LL is asking us to take over managing more resources in their servers, we need *much* better tools than we currently have. From robertltux at gmail.com Tue Dec 22 13:59:03 2009 From: robertltux at gmail.com (Robert Martin) Date: Tue, 22 Dec 2009 16:59:03 -0500 Subject: [sldev] status of vwr-6199?? Message-ID: I think somebody round here has been threatening to do some work on the patch for the last couple months but is anybody actually working on this?? a couple side notes (info in in a comment in the jira) 1 Emerald as of version 1.23.5.904 has the patch more or less as is included 2 there is a program that is just about perfect for doing texture work and its free ware -- Robert L Martin yes i am also trying to get a less "loaded" convo going From dzonatas at gmail.com Tue Dec 22 14:32:09 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Tue, 22 Dec 2009 14:32:09 -0800 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <20091222200254.GA4235@alinoe.com> References: <9e877f170912200855k79697b62u32ded9021459473d@mail.gmail.com> <20091222125350.GD10705@alinoe.com> <4B30CD2A.3000407@gmail.com> <6562FA53-57F5-447A-993E-D2DF4426FDD8@gmail.com> <20091222200254.GA4235@alinoe.com> Message-ID: <4B3148E9.204@gmail.com> Carlo Wood wrote: > On Tue, Dec 22, 2009 at 12:46:50PM -0600, Argent Stonecutter wrote: > >> On 2009-12-22, at 07:44, Dzonatas Sol wrote: >> >>> If someone is not interested in land ownership, why should land limits >>> affect the avatar? >>> >> They won't. Babbage has said that each avatar will have a script quota >> independent of the land it's on. >> > > Yes, and that is what we don't want. > It makes no sense to reserve memory of EVERY private sim, paid > for by their respective owners, for heavy avatars that are normally > not there. If this is how it's going to be then those avatars > should pay for the sim, and the prices for the sim owners should > go down. > Right now avatar features are locked to a sim, but that doesn't mean avatars should suffer in the long run when they really don't have to be locked to a sim. Right now, reserve memory is needed. In the long run, there should be no extra memory needed for avatars on the physics simulator for avatar features. Right now, script quota is a solution in the short-term. In the long term it is not a solution to artificially lock avatars to sims and have them submiss to sim owners. =/ At this point, region domains and agent domains make way more sense. By then, script quotas won't be needed unless deemed as premium membership to an agent domain. Much the way you feel as a sim owner is the same as people feel as an avatar owner. From brickrte at hughes.net Tue Dec 22 14:41:53 2009 From: brickrte at hughes.net (Laurence Brickner) Date: Tue, 22 Dec 2009 17:41:53 -0500 Subject: [sldev] Quicktime SDK Message-ID: <7B41B47578DD413C987FDB4EBA019BFE@LRBXPS> Hi all, I've been trying to download the QT SDK for several weeks and continue to get an apology screen that they are having technical difficulties. I do get confirmation when I change my password so they apparently know me. Anyone else with this? And, is there any place else to get the SDK other than the ADC site? Thanks, Larry /Shor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091222/c6639c92/attachment.htm From q at lindenlab.com Tue Dec 22 14:51:52 2009 From: q at lindenlab.com (Kent Quirk) Date: Tue, 22 Dec 2009 17:51:52 -0500 Subject: [sldev] Script Limits Thread In-Reply-To: <20091222201543.GB4235@alinoe.com> References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> <36990292-C5F7-4602-94BE-0BE780A2E961@gmail.com> <20091222130740.GE10705@alinoe.com> <20091222201543.GB4235@alinoe.com> Message-ID: This thread is pretty much out of hand, and it's covered every useful point we're going to cover. It's also pretty much entirely off-topic for SLDev. Let's end it here. From suzyq at pobox.com Tue Dec 22 15:12:56 2009 From: suzyq at pobox.com (Suzy Deffeyes) Date: Tue, 22 Dec 2009 17:12:56 -0600 Subject: [sldev] Linkable prim over 256 In-Reply-To: <34cc66250912212045p2cd8ff32n4350aa68e53c8835@mail.gmail.com> References: <4B2FCE93.3030700@gmail.com> <1261456376.9649.10.camel@RAGE> <34cc66250912212045p2cd8ff32n4350aa68e53c8835@mail.gmail.com> Message-ID: <2bd5b7f10912221512ubf48d00le86a001e3d10029e@mail.gmail.com> My hazy memory seems to recall that it was somewhat protocol limited, I think the field in the packet that is the object count was an 8 bit value, which means the protocol limited you to 256, not the client or server code. I might be off on this, it was a while ago that i looked into it. I made a small change in the hippo viewer that will allow the end user to select a random number of objects to link, and they get linked into groups of 255 and squirted across in the protocol. So the way to use that to link more than 256 is to select a group of objects, and then do the link step *twice*. It's not pretty, but allows builders to link groups of objects without having to sit there and fuss with counting objects. It seemed to work on both OpenSim and the main SL grid. Suzy/Pixel On Mon, Dec 21, 2009 at 10:45 PM, Teravus Ovares wrote: > Just a clarification here. The code may also be server side.. but > if you create 444 objects and try to link them all on OpenSimulator > using the Standard Linden Client downloaded from the website it > presents a message box that says 'Unable to link these 444 objects. > You can link a maximum of 256 objects'. This means that it is > also client side because there is no server side code to restrict the > number of objects you can link in OpenSimulator without a 3rd party > addon module. > > Regards > > Teravus > > On Mon, Dec 21, 2009 at 11:32 PM, Rob Nelson > wrote: > > It's server-side, you can't change it unless you're running on OpenSim. > > > > On Mon, 2009-12-21 at 14:37 -0500, Andrew Simpson wrote: > >> hi guys, > >> > >> i am trying to find the code that set the limit on 256 link on the prim > >> in one, wher it is in the code source or iut in xml? let me know thank > >> _______________________________________________ > >> Policies and (un)subscribe information available here: > >> http://wiki.secondlife.com/wiki/SLDev > >> Please read the policies before posting to keep unmoderated posting > privileges > > > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091222/024bcc22/attachment.htm From andsim2 at gmail.com Tue Dec 22 15:50:18 2009 From: andsim2 at gmail.com (Andrew Simpson) Date: Tue, 22 Dec 2009 18:50:18 -0500 Subject: [sldev] Linkable prim over 256 In-Reply-To: <2bd5b7f10912221512ubf48d00le86a001e3d10029e@mail.gmail.com> References: <4B2FCE93.3030700@gmail.com> <1261456376.9649.10.camel@RAGE> <34cc66250912212045p2cd8ff32n4350aa68e53c8835@mail.gmail.com> <2bd5b7f10912221512ubf48d00le86a001e3d10029e@mail.gmail.com> Message-ID: <4B315B3A.40209@gmail.com> as i can tell, when i tired to link 255 prim work great, but after 255 client side wont let me allow on my opensim grid, i have rebuilt viewer to run on opensim grid and 255 linkset limition was in the way. and soon if i havent discover trhe linket my grid residents will complain. already got complain other grid owner soo that why i ask Suzy Deffeyes wrote: > My hazy memory seems to recall that it was somewhat protocol limited, > I think the field in the packet that is the object count was an 8 bit > value, which means the protocol limited you to 256, not the client or > server code. I might be off on this, it was a while ago that i looked > into it. > > I made a small change in the hippo viewer that will allow the end user > to select a random number of objects to link, and they get linked into > groups of 255 and squirted across in the protocol. So the way to use > that to link more than 256 is to select a group of objects, and then > do the link step *twice*. It's not pretty, but allows builders to link > groups of objects without having to sit there and fuss with counting > objects. It seemed to work on both OpenSim and the main SL grid. > > Suzy/Pixel > > On Mon, Dec 21, 2009 at 10:45 PM, Teravus Ovares > wrote: > > Just a clarification here. The code may also be server side.. but > if you create 444 objects and try to link them all on OpenSimulator > using the Standard Linden Client downloaded from the website it > presents a message box that says 'Unable to link these 444 objects. > You can link a maximum of 256 objects'. This means that it is > also client side because there is no server side code to restrict the > number of objects you can link in OpenSimulator without a 3rd party > addon module. > > Regards > > Teravus > > On Mon, Dec 21, 2009 at 11:32 PM, Rob Nelson > > wrote: > > It's server-side, you can't change it unless you're running on > OpenSim. > > > > On Mon, 2009-12-21 at 14:37 -0500, Andrew Simpson wrote: > >> hi guys, > >> > >> i am trying to find the code that set the limit on 256 link on > the prim > >> in one, wher it is in the code source or iut in xml? let me > know thank > >> _______________________________________________ > >> Policies and (un)subscribe information available here: > >> http://wiki.secondlife.com/wiki/SLDev > >> Please read the policies before posting to keep unmoderated > posting privileges > > > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated > posting privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From adam at deepthink.com.au Tue Dec 22 17:57:19 2009 From: adam at deepthink.com.au (Frisby, Adam) Date: Tue, 22 Dec 2009 20:57:19 -0500 Subject: [sldev] Linkable prim over 256 In-Reply-To: <2bd5b7f10912221512ubf48d00le86a001e3d10029e@mail.gmail.com> References: <4B2FCE93.3030700@gmail.com> <1261456376.9649.10.camel@RAGE> <34cc66250912212045p2cd8ff32n4350aa68e53c8835@mail.gmail.com> <2bd5b7f10912221512ubf48d00le86a001e3d10029e@mail.gmail.com> Message-ID: <63FAD4F222230A4EA79DE9E8BE6647354DD1B43A@winxbeus19.exchange.xchg> AFAIK, OpenSim has native linking of objects >= 256 prims. You can take a look in the Hippo & Meerkat viewers as both support it. Adam From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Suzy Deffeyes Sent: Tuesday, 22 December 2009 3:13 PM To: Teravus Ovares Cc: SLDEV Subject: Re: [sldev] Linkable prim over 256 My hazy memory seems to recall that it was somewhat protocol limited, I think the field in the packet that is the object count was an 8 bit value, which means the protocol limited you to 256, not the client or server code. I might be off on this, it was a while ago that i looked into it. I made a small change in the hippo viewer that will allow the end user to select a random number of objects to link, and they get linked into groups of 255 and squirted across in the protocol. So the way to use that to link more than 256 is to select a group of objects, and then do the link step *twice*. It's not pretty, but allows builders to link groups of objects without having to sit there and fuss with counting objects. It seemed to work on both OpenSim and the main SL grid. Suzy/Pixel On Mon, Dec 21, 2009 at 10:45 PM, Teravus Ovares > wrote: Just a clarification here. The code may also be server side.. but if you create 444 objects and try to link them all on OpenSimulator using the Standard Linden Client downloaded from the website it presents a message box that says 'Unable to link these 444 objects. You can link a maximum of 256 objects'. This means that it is also client side because there is no server side code to restrict the number of objects you can link in OpenSimulator without a 3rd party addon module. Regards Teravus On Mon, Dec 21, 2009 at 11:32 PM, Rob Nelson > wrote: > It's server-side, you can't change it unless you're running on OpenSim. > > On Mon, 2009-12-21 at 14:37 -0500, Andrew Simpson wrote: >> hi guys, >> >> i am trying to find the code that set the limit on 256 link on the prim >> in one, wher it is in the code source or iut in xml? let me know thank >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091222/1ce6805d/attachment.htm From lillie.yiyuan at gmail.com Tue Dec 22 21:42:01 2009 From: lillie.yiyuan at gmail.com (Lillian Yiyuan) Date: Tue, 22 Dec 2009 21:42:01 -0800 Subject: [sldev] Script memory limits, promises, parcel bonus In-Reply-To: References: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> Message-ID: More on topic for the viewer. Many of that activities currently performed by scripts should be done primarily out of viewer resources, these include, but are not limited to, AOs, radar, scripts on attachments, flight enhancement and so on. One short road to making it so that script limits are not noticed, is to take off the server the long list of activities that are server side, but do not need to be there. If most avs can wear their clothes and their AOs and a few gadgets, they will not notice scripting limits, and there will be more resources for physics, graphics and so on. Client side scripting is not easy but there have been enough implementations of it in various places to show that it is practical and not fatal to sim performance. Many of these enhancements have already been put in to open source clients, and therefore are good targets for implementation. From carlo at alinoe.com Wed Dec 23 04:12:23 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 23 Dec 2009 13:12:23 +0100 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <4B3148E9.204@gmail.com> References: <9e877f170912200855k79697b62u32ded9021459473d@mail.gmail.com> <20091222125350.GD10705@alinoe.com> <4B30CD2A.3000407@gmail.com> <6562FA53-57F5-447A-993E-D2DF4426FDD8@gmail.com> <20091222200254.GA4235@alinoe.com> <4B3148E9.204@gmail.com> Message-ID: <20091223121223.GA14573@alinoe.com> On Tue, Dec 22, 2009 at 02:32:09PM -0800, Dzonatas Sol wrote: > Right now avatar features are locked to a sim, but that doesn't mean > avatars should suffer in the long run when they really don't have to > be locked to a sim. What about shields? I thought they detect collisions and then react as function of what is colliding etc. Seems to me that has to run on the sim or it will be way too slow. The only attachments that can run in the agent domain are those that cannot be collided with ('phantom' attachments) and do not otherwise need a fast response time with regard to their environment. > Right now, reserve memory is needed. In the long run, there should > be no extra memory needed for avatars on the physics simulator for > avatar features. > > Right now, script quota is a solution in the short-term. In the long > term it is not a solution to artificially lock avatars to sims and > have them submiss to sim owners. =/ > > At this point, region domains and agent domains make way more sense. > By then, script quotas won't be needed unless deemed as premium > membership to an agent domain. > > Much the way you feel as a sim owner is the same as people feel as > an avatar owner. > -- Carlo Wood From carlo at alinoe.com Wed Dec 23 04:20:50 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 23 Dec 2009 13:20:50 +0100 Subject: [sldev] Bidding System Algorithm for Allocation Script Memory In-Reply-To: <3a164ef30912221052o325d6d8ey17774240c6bcfd85@mail.gmail.com> References: <6ED0D965A81345339AD264C4E4B4A063@jbh3000> <36990292-C5F7-4602-94BE-0BE780A2E961@gmail.com> <20091222130740.GE10705@alinoe.com> <3a164ef30912221052o325d6d8ey17774240c6bcfd85@mail.gmail.com> Message-ID: <20091223122050.GB14573@alinoe.com> On Tue, Dec 22, 2009 at 10:52:01AM -0800, David Simmons wrote: > Virtual land do have real costs!. There are electrical costs, actual servers > and physical san that cost money, support cost. As far as I know, Linden do not > get free network connection to the internet. An Linden employees don't work for > free. That is the way it is implemented. Really fair would be if everyone paid for the resources they used, being memory and cpu. With a different implementation, land area should need to cost anything (beyond storing the land-image and transfering it... maybe $1 per month per sim-area). On top of that there are less measurable costs of course, like the salary of employee's; but those kind of costs can just be added to the costs of actually usage of resources with a multiplier (ie, pay $2 per month per sim-area). But well... we'll never see this because for some reason developers always think that "the users" are so stupid that they won't understand anything else than what those developers can implement (something simple)... and a variable bill that depends on the resource usage of that month would not be understood by our users: way, way too complex. [not going to make a remark here about RL electricity and energy bills]. -- Carlo Wood From carlo at alinoe.com Wed Dec 23 04:34:06 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 23 Dec 2009 13:34:06 +0100 Subject: [sldev] Linkable prim over 256 In-Reply-To: <63FAD4F222230A4EA79DE9E8BE6647354DD1B43A@winxbeus19.exchange.xchg> References: <4B2FCE93.3030700@gmail.com> <1261456376.9649.10.camel@RAGE> <34cc66250912212045p2cd8ff32n4350aa68e53c8835@mail.gmail.com> <2bd5b7f10912221512ubf48d00le86a001e3d10029e@mail.gmail.com> <63FAD4F222230A4EA79DE9E8BE6647354DD1B43A@winxbeus19.exchange.xchg> Message-ID: <20091223123406.GD14573@alinoe.com> On Tue, Dec 22, 2009 at 08:57:19PM -0500, Frisby, Adam wrote: > AFAIK, OpenSim has native linking of objects >= 256 prims. You can take a look > in the Hippo & Meerkat viewers as both support it. Are either viewer developers of those viewers willing to share their patches, so that improvements like this can be added to snowglobe too? -- Carlo Wood From carlo at alinoe.com Wed Dec 23 04:45:58 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 23 Dec 2009 13:45:58 +0100 Subject: [sldev] SLDev Digest, Vol 36, Issue 59 In-Reply-To: <4B313695.1060308@beau.org> References: <9e877f170912220720k5ea20b13k7f10703da05bbc42@mail.gmail.com> <4B313695.1060308@beau.org> Message-ID: <20091223124558.GE14573@alinoe.com> On Tue, Dec 22, 2009 at 03:13:57PM -0600, Jamey Fletcher wrote: > [I'd hate for my SIM to be on the same server as Money Island's SIM, > with 100 AVs, wearing 50x as many prims as the SIM has available for > building. Apart from scripts in attachments, I don't see how or why attachment prims need to use server cpu time. Same holds for most normal build prims if they are phantom. It would be fair if LL changed the policy and allowed -say- 10 phantom prims OR a normal prim, simply because the first hardly uses any server resources. They still load the viewer a lot though. You can't make a building of 100,000 prims and then expect a high FPS when looking at it :/ I normally have an FPS of 50 to 60 on my sim. Last we had a Xmas party so that there 14 avatars on the sim (which seldom happens, I think it was the first time). My FPS had dropped to 6. I investigated the reason and it was solely because of the avatar rendering costs! That kinda amazes me. Seems that the viewer is doing this rendering in a pretty inefficient way. -- Carlo Wood From lear.cale at gmail.com Wed Dec 23 05:57:16 2009 From: lear.cale at gmail.com (Lear Cale) Date: Wed, 23 Dec 2009 08:57:16 -0500 Subject: [sldev] User needs on script limits In-Reply-To: <20091222140810.GC15491@alinoe.com> References: <4B2E5A3D.3020503@gmail.com> <20091222140810.GC15491@alinoe.com> Message-ID: > > If the Lindens were reasonable and ACTUALLY went into a > discussion, open to technical arguments and reasoning, then > we could have really talked about this in a mature and > professional way; They are, and they did, and this discussion began months ago. Sorry you missed most of it. This is a case where LL is being quite reasonable, and moving forward in a cautious sensible way. So far most the "better" proposals have been hopelessly complicated and with little technical merit. Technically sensible ideas have been listened to and responded to. We need to applaud them for their approach this time. Yes, it's going to drive a lot of people crazy, but the problem is significant and needs to be addressed. The biggest criticism we could level at them is that they didn't do it earlier -- but the really serious memory issues didn't appear so much with LSO (for reasons I think Argent understands, but escape me). The users' perspective is certainly not being igored -- especially the user who can't even use their home sim because it's thrashing, with frame rates below 1 FPS, because of extreme overusage of script memory. The problem here is "the tragedy of the commons". Whenever there's a communal resource that everyone can use freely, some use far more than their "fair share" and use it up for the rest. In this case, nobody even knew what a "fair share" was, before we started hitting these problems and LL started monitoring it. We're still in the learning stage, btw. But it's clear that script memory limits are necessary. You can argue against that all you want, but it will be in vain -- that decision has been made. What remains to work out are a number of details. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091223/50e311b7/attachment-0001.htm From suzyq at pobox.com Wed Dec 23 07:00:12 2009 From: suzyq at pobox.com (Suzy Deffeyes) Date: Wed, 23 Dec 2009 09:00:12 -0600 Subject: [sldev] Linkable prim over 256 In-Reply-To: <20091223123406.GD14573@alinoe.com> References: <4B2FCE93.3030700@gmail.com> <1261456376.9649.10.camel@RAGE> <34cc66250912212045p2cd8ff32n4350aa68e53c8835@mail.gmail.com> <2bd5b7f10912221512ubf48d00le86a001e3d10029e@mail.gmail.com> <63FAD4F222230A4EA79DE9E8BE6647354DD1B43A@winxbeus19.exchange.xchg> <20091223123406.GD14573@alinoe.com> Message-ID: <2bd5b7f10912230700v7446619eved6faa0e1a7e1475@mail.gmail.com> http://forge.opensimulator.org/gf/project/opensim-viewer/tracker/?action=TrackerItemEdit&tracker_item_id=141 On Wed, Dec 23, 2009 at 6:34 AM, Carlo Wood wrote: > On Tue, Dec 22, 2009 at 08:57:19PM -0500, Frisby, Adam wrote: > > AFAIK, OpenSim has native linking of objects >= 256 prims. You can take a > look > > in the Hippo & Meerkat viewers as both support it. > > Are either viewer developers of those viewers willing to share > their patches, so that improvements like this can be added > to snowglobe too? > > -- > Carlo Wood > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091223/e0c8c37d/attachment.htm From arrogant.cyberstar at gmail.com Wed Dec 23 07:36:38 2009 From: arrogant.cyberstar at gmail.com (Arrogant Cyberstar) Date: Wed, 23 Dec 2009 07:36:38 -0800 Subject: [sldev] Linkable prim over 256 Message-ID: <5cca23bc0912230736w7d9c135apbd1c68d3dd5f56e6@mail.gmail.com> I think the relevant code you're looking for is in llviewermenu.cpp. At around line 4275 you get this: S32 object_count = LLSelectMgr::getInstance()->getSelection()->getObjectCount(); if (object_count > MAX_CHILDREN_PER_TASK + 1) { LLSD args; args["COUNT"] = llformat("%d", object_count); int max = MAX_CHILDREN_PER_TASK+1; args["MAX"] = llformat("%d", max); LLNotifications::instance().add("UnableToLinkObjects", args); return true; } And isn't object linking done with the ObjectLink message? -arrogant -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091223/128519d9/attachment.htm From dzonatas at gmail.com Wed Dec 23 07:56:18 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Wed, 23 Dec 2009 07:56:18 -0800 Subject: [sldev] Client-side scripting is real (was: Script memory limits, promises, parcel bonus) In-Reply-To: References: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> Message-ID: <4B323DA2.1050403@gmail.com> We need a standard API for to this to work well. I wouldn't expect a formalized standard to happen quickly, but an API no doubt is needed at least. We can treat the network code now in the viewers as part of the Agent Domain. It probably didn't appear like that before, yet with the API it certainly does. I guess some didn't take an API seriously because they thought it disabled or prevented user interfaces already present in the viewer. This show that an API doesn't disable or prevent any user interfaces already present in the viewer: http://jira.secondlife.com/browse/SNOW-375 As the API develops into a more truer RESTful scheme, then client-side scripts could run in each of there own process without the need to be a directly plugged into one another (or compiled together). This is a very scalable approach. Here, the network code acts in the viewer acts as a hub for the Agent Domain (a subset of it until more formal). If you look at the code for the World Map, the viewer updates the script of the position, but then the map uses HTTP to fetch the textures. Even without any code being disabled/prevented in the viewer, you can expect that the viewer would not have to chew on texture fetches, which would mean more time it can spend to actually render the scene. This is more so true on multi-core machines. The AO ability is certainly possible. SNOW-9 was a stub for gesture recognition, but it could easily use this API instead. There is different ways to achieve this, and I thought simplest way would be to like wear animation/gestures much like one wears clothes, or maybe something like the interface for attachments. Probably more of interest than an AO right now is to have LSL-editors use the API. When you open a script in-world, it would actually open your client-side script/program of choice to edit. There are some good ones out there. I've said too much... (not really *wink*) Lillian Yiyuan wrote: > More on topic for the viewer. Many of that activities currently > performed by scripts should be done primarily out of viewer resources, > these include, but are not limited to, AOs, radar, scripts on > attachments, flight enhancement and so on. One short road to making it > so that script limits are not noticed, is to take off the server the > long list of activities that are server side, but do not need to be > there. If most avs can wear their clothes and their AOs and a few > gadgets, they will not notice scripting limits, and there will be more > resources for physics, graphics and so on. Client side scripting is > not easy but there have been enough implementations of it in various > places to show that it is practical and not fatal to sim performance. > > Many of these enhancements have already been put in to open source > clients, and therefore are good targets for implementation. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From monkowsk at fishkill.ibm.com Wed Dec 23 07:46:59 2009 From: monkowsk at fishkill.ibm.com (Mike Monkowski) Date: Wed, 23 Dec 2009 10:46:59 -0500 Subject: [sldev] Fwd: Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4B2CCD7B.7000805@gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> <20091222115321.GA10705@alinoe.com> <20091222123708.GC10705@alinoe.com> Message-ID: <4B323B73.7000808@fishkill.ibm.com> Argent Stonecutter wrote: > People keep talking about a hypothetical "suspended" state for scripts. > > That will not happen. It's not in the plan as described by Babbage, > and it would be very difficult to implement in a way that actually > delivered on the memory savings that are needed. So alienating residents is the better choice? Why is a suspended, or rather terminated state, not in "the plan" along with an efficient AO system? Why does Kent Quirk say we've "covered every useful point we're going to cover" when methods to reduce memory usage through efficiency have not been addressed by Linden and they are clearly on-topic for SLDev? Mike From matrice64 at gmail.com Wed Dec 23 08:22:07 2009 From: matrice64 at gmail.com (Matrice64) Date: Wed, 23 Dec 2009 10:22:07 -0600 Subject: [sldev] User needs on script limits In-Reply-To: References: <4B2E5A3D.3020503@gmail.com> <20091222140810.GC15491@alinoe.com> Message-ID: I think that was well put Lear :-) On Wed, Dec 23, 2009 at 7:57 AM, Lear Cale wrote: >> If the Lindens were reasonable and ACTUALLY went into a >> discussion, open to technical arguments and reasoning, then >> we could have really talked about this in a mature and >> professional way; > > > They are, and they did, and this discussion began months ago.? Sorry you > missed most of it. > > This is a case where LL is being quite reasonable, and moving forward in a > cautious sensible way.? So far most the "better" proposals have been > hopelessly complicated and with little technical merit. > Technically sensible ideas have been listened to and responded to. > > We need to applaud them for their approach this time.? Yes, it's going to > drive a lot of people crazy, but the problem is significant and needs to be > addressed.? The biggest criticism we could level at them is that they didn't > do it earlier -- but the really serious memory issues didn't appear so much > with LSO (for reasons I think Argent understands, but escape me). > > The users' perspective is certainly not being igored -- especially the user > who can't even use their home sim because it's thrashing, with frame rates > below 1 FPS, because of extreme overusage of script memory.? The problem > here is "the tragedy of the commons".? Whenever there's a communal resource > that everyone can use freely, some use far more than their "fair share" and > use it up for the rest.? In this case, nobody even knew what a "fair share" > was, before we started hitting these problems and LL started monitoring it. > We're still in the learning stage, btw.? But it's clear that script memory > limits are necessary.? You can argue against that all you want, but it will > be in vain -- that decision has been made.? What remains to work out are a > number of details. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From kelly at lindenlab.com Wed Dec 23 13:10:13 2009 From: kelly at lindenlab.com (Kelly Linden) Date: Wed, 23 Dec 2009 13:10:13 -0800 Subject: [sldev] Efficient Scripts meta jira Message-ID: We have created a new meta jira for the in-progress Efficient Scripts project which has gotten some discussion lately on both of these lists - SVC-5165 [1]. I've added some sub-tasks for the cases that were already on our radar, along with the "mission statement" / goal of the project. If there is further discussion or ideas this jira is the place for them. Please note that this is an independent discussion from that around Babbage's recent Script Limits blog post: sometime after the new year we plan to have a more detailed design description to put onto the wiki that will hopefully clear up some misconceptions and provide a firmer base for discussion. I definitely want to thank everyone who has participated in either discussion, we have gotten a lot out of the discussions so far and it is encouraging as always to see how passionate everyone is about Second Life. Given the holidays and vacation schedules, and the wider scope of both of these lists, we would appreciate moving the Efficient Scripts discussion to the jira and holding off discussion of Script Limits at least on these lists for the time being. Again, a big thank you to everyone involved. - Kelly [1] https://jira.secondlife.com/browse/SVC-5165 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091223/0652c182/attachment.htm From carlo at alinoe.com Wed Dec 23 13:37:04 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 23 Dec 2009 22:37:04 +0100 Subject: [sldev] Client-side scripting is real (was: Script memory limits, promises, parcel bonus) In-Reply-To: <4B323DA2.1050403@gmail.com> References: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> <4B323DA2.1050403@gmail.com> Message-ID: <20091223213704.GA14594@alinoe.com> I've thought about such an API in the past a bit, and my idea was to have an interface that takes XML "messages" (char strings thus, basically). The viewer would provide a socket (or whatever, a function call would do too if it's possible to link with it) and read incoming messages, decode them and do whatever they say. The other way around there needs to be information going from the viewer to whatever wants to interface with it. Also this should be in the form of XML messages. The reason that XML should be used is so that it is easy to extend, without breaking existing "clients": you can later add an argument or data, and not not confuse the interpreter of the XML messages. Also, you can first implement a certain set of messages, for example to control the UI, and later add another set of messages, for example to control the avatar, etc. What do you think of this basic idea behind this? Lots of details need to be worked out still of course, I think we can already decide that in the end the lowest level of comunication will be XML messages. On Wed, Dec 23, 2009 at 07:56:18AM -0800, Dzonatas Sol wrote: > We need a standard API for to this to work well. I wouldn't expect a > formalized standard to happen quickly, but an API no doubt is needed at > least. > > We can treat the network code now in the viewers as part of the Agent > Domain. It probably didn't appear like that before, yet with the API it > certainly does. > > I guess some didn't take an API seriously because they thought it > disabled or prevented user interfaces already present in the viewer. > > This show that an API doesn't disable or prevent any user interfaces > already present in the viewer: > http://jira.secondlife.com/browse/SNOW-375 > > As the API develops into a more truer RESTful scheme, then client-side > scripts could run in each of there own process without the need to be a > directly plugged into one another (or compiled together). This is a very > scalable approach. Here, the network code acts in the viewer acts as a > hub for the Agent Domain (a subset of it until more formal). > > If you look at the code for the World Map, the viewer updates the script > of the position, but then the map uses HTTP to fetch the textures. Even > without any code being disabled/prevented in the viewer, you can expect > that the viewer would not have to chew on texture fetches, which would > mean more time it can spend to actually render the scene. This is more > so true on multi-core machines. > > The AO ability is certainly possible. SNOW-9 was a stub for gesture > recognition, but it could easily use this API instead. There is > different ways to achieve this, and I thought simplest way would be to > like wear animation/gestures much like one wears clothes, or maybe > something like the interface for attachments. > > Probably more of interest than an AO right now is to have LSL-editors > use the API. When you open a script in-world, it would actually open > your client-side script/program of choice to edit. There are some good > ones out there. > > I've said too much... (not really *wink*) > > Lillian Yiyuan wrote: > > More on topic for the viewer. Many of that activities currently > > performed by scripts should be done primarily out of viewer resources, > > these include, but are not limited to, AOs, radar, scripts on > > attachments, flight enhancement and so on. One short road to making it > > so that script limits are not noticed, is to take off the server the > > long list of activities that are server side, but do not need to be > > there. If most avs can wear their clothes and their AOs and a few > > gadgets, they will not notice scripting limits, and there will be more > > resources for physics, graphics and so on. Client side scripting is > > not easy but there have been enough implementations of it in various > > places to show that it is practical and not fatal to sim performance. > > > > Many of these enhancements have already been put in to open source > > clients, and therefore are good targets for implementation. > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting privileges > > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood From carlo at alinoe.com Wed Dec 23 13:43:33 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 23 Dec 2009 22:43:33 +0100 Subject: [sldev] Efficient Scripts meta jira In-Reply-To: References: Message-ID: <20091223214333.GB14594@alinoe.com> On Wed, Dec 23, 2009 at 01:10:13PM -0800, Kelly Linden wrote: > [1]?https://jira.secondlife.com/browse/SVC-5165 Hi Kelly, can you please also create a jira for discussion of needed Estate Manager tools in regard to script limits etc? Of course I could create one myself, but that wouldn't be official enough (it would make not much sense if I was the only one adding some comments to it :p). I'd really appreciate it if you could take this topic (EM tools) seriously enough to create an official jira for it, like SVC-5165, and bring it under the attention of Babbage. Thanks, Carlo From dzonatas at gmail.com Wed Dec 23 14:40:42 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Wed, 23 Dec 2009 14:40:42 -0800 Subject: [sldev] Client-side scripting is real In-Reply-To: <20091223213704.GA14594@alinoe.com> References: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> <4B323DA2.1050403@gmail.com> <20091223213704.GA14594@alinoe.com> Message-ID: <4B329C6A.7020403@gmail.com> Yes, XML is being used in SNOW-375. The viewer sets up LLIOHTTPServer to listen on a port (default: 50140). A peer then connects to the viewer with the resource URI: http://x.y.z.w:50140/Interface/Connect Content-Type is set to: llsd+xml An XML packet then contains the request data in which the viewer uses to connect back to the peer through a TCP socket that stays open. Unsolicited events from the viewer to the peer are sent via the TCP socket, for now. These could via a HTTP listener on the peer end instead of a TCP socket, but I wanted to avoid firewall issues for now. This can be later programmed optional as specified by the XML data in the /Interface/Connect method. Each request sent over the TCP socket is LLSD+XML based with null as the delimiter. These messages should not be bigger than a UDP packet. This TCP connection can be treated just like a UDP connectionless endpoint with packet loss and/or limited buffers. A successful /Interface/Connect than establishes a cookie for the session to use in other URI resource requests. Other requests, like for avatar information, gesture data, group info, etc, are all done by URI resource nodes on the LLIOHTTPServer. All messages that can be larger than a UDP packet have to have a node. Anything that requires stateful tranfers must use a node (hence, no specialized reliable UDP support needed here). LLSD+XML is used to keep the API to a lite-weight footprint in the viewer. Carlo Wood wrote: > I've thought about such an API in the past a bit, and my idea > was to have an interface that takes XML "messages" (char strings > thus, basically). > > The viewer would provide a socket (or whatever, a function call > would do too if it's possible to link with it) and read incoming > messages, decode them and do whatever they say. > > The other way around there needs to be information going from > the viewer to whatever wants to interface with it. Also this > should be in the form of XML messages. > > The reason that XML should be used is so that it is easy to > extend, without breaking existing "clients": you can later > add an argument or data, and not not confuse the interpreter > of the XML messages. Also, you can first implement a certain > set of messages, for example to control the UI, and later > add another set of messages, for example to control the > avatar, etc. > > What do you think of this basic idea behind this? Lots of > details need to be worked out still of course, I think we > can already decide that in the end the lowest level of > comunication will be XML messages. > > On Wed, Dec 23, 2009 at 07:56:18AM -0800, Dzonatas Sol wrote: > >> We need a standard API for to this to work well. I wouldn't expect a >> formalized standard to happen quickly, but an API no doubt is needed at >> least. >> >> We can treat the network code now in the viewers as part of the Agent >> Domain. It probably didn't appear like that before, yet with the API it >> certainly does. >> >> I guess some didn't take an API seriously because they thought it >> disabled or prevented user interfaces already present in the viewer. >> >> This show that an API doesn't disable or prevent any user interfaces >> already present in the viewer: >> http://jira.secondlife.com/browse/SNOW-375 >> >> As the API develops into a more truer RESTful scheme, then client-side >> scripts could run in each of there own process without the need to be a >> directly plugged into one another (or compiled together). This is a very >> scalable approach. Here, the network code acts in the viewer acts as a >> hub for the Agent Domain (a subset of it until more formal). >> >> If you look at the code for the World Map, the viewer updates the script >> of the position, but then the map uses HTTP to fetch the textures. Even >> without any code being disabled/prevented in the viewer, you can expect >> that the viewer would not have to chew on texture fetches, which would >> mean more time it can spend to actually render the scene. This is more >> so true on multi-core machines. >> >> The AO ability is certainly possible. SNOW-9 was a stub for gesture >> recognition, but it could easily use this API instead. There is >> different ways to achieve this, and I thought simplest way would be to >> like wear animation/gestures much like one wears clothes, or maybe >> something like the interface for attachments. >> >> Probably more of interest than an AO right now is to have LSL-editors >> use the API. When you open a script in-world, it would actually open >> your client-side script/program of choice to edit. There are some good >> ones out there. >> >> I've said too much... (not really *wink*) >> >> Lillian Yiyuan wrote: >> >>> More on topic for the viewer. Many of that activities currently >>> performed by scripts should be done primarily out of viewer resources, >>> these include, but are not limited to, AOs, radar, scripts on >>> attachments, flight enhancement and so on. One short road to making it >>> so that script limits are not noticed, is to take off the server the >>> long list of activities that are server side, but do not need to be >>> there. If most avs can wear their clothes and their AOs and a few >>> gadgets, they will not notice scripting limits, and there will be more >>> resources for physics, graphics and so on. Client side scripting is >>> not easy but there have been enough implementations of it in various >>> places to show that it is practical and not fatal to sim performance. >>> >>> Many of these enhancements have already been put in to open source >>> clients, and therefore are good targets for implementation. >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting privileges >>> >>> >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > > From carlo at alinoe.com Thu Dec 24 04:19:14 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 24 Dec 2009 13:19:14 +0100 Subject: [sldev] Client-side scripting is real In-Reply-To: <4B329C6A.7020403@gmail.com> References: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> <4B323DA2.1050403@gmail.com> <20091223213704.GA14594@alinoe.com> <4B329C6A.7020403@gmail.com> Message-ID: <20091224121914.GA1855@alinoe.com> On Wed, Dec 23, 2009 at 02:40:42PM -0800, Dzonatas Sol wrote: > Yes, XML is being used in SNOW-375. This looks pretty cool, clean and maintainable. Is there some more detailed documentation on how to write a client for this, and what interface is already supported (a list of actual possible messages thus)? Ie, is it (already) possible to control my avatar through this interface with the current patch? Walking around, looking around, accepting teleports, teleporting, etc. -- Carlo Wood From aleric.inglewood at gmail.com Thu Dec 24 05:08:28 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Thu, 24 Dec 2009 14:08:28 +0100 Subject: [sldev] SNOW-129 : saved accounts drop down menu Message-ID: <1e01733d0912240508r418f7819n801ce11cba05a356@mail.gmail.com> Requesting testers / reviewer for http://jira.secondlife.com/browse/SNOW-129 This patch causes logins/accounts to be remembered, also for different grids. You can opt to have it remember the password too, so that logging in into any of your accounts on any grid is just two clicks. Originally written by Cypren and now with some extra chunk of code by me. From dzonatas at gmail.com Thu Dec 24 05:56:10 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 24 Dec 2009 05:56:10 -0800 Subject: [sldev] Client-side scripting is real In-Reply-To: <20091224121914.GA1855@alinoe.com> References: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> <4B323DA2.1050403@gmail.com> <20091223213704.GA14594@alinoe.com> <4B329C6A.7020403@gmail.com> <20091224121914.GA1855@alinoe.com> Message-ID: <4B3372FA.7080004@gmail.com> Carlo Wood wrote: > On Wed, Dec 23, 2009 at 02:40:42PM -0800, Dzonatas Sol wrote: > >> Yes, XML is being used in SNOW-375. >> > > This looks pretty cool, clean and maintainable. > =) > Is there some more detailed documentation on how to write > a client for this, and what interface is already supported > (a list of actual possible messages thus)? > > Ie, is it (already) possible to control my avatar through > this interface with the current patch? Walking around, looking > around, accepting teleports, teleporting, etc. > > I'll have to work on it to wikify API documentation. What I provided in the last message was the main step needed to enable all the API resources. There is step-by-step documentation here on how to compile the patch into Snowglobe, even if you don't use C#, Gtk, Communicator, etc: (the patch/API itself does not depend on those) http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/Communicator The UI already present is in Snowglobe has not been disabled or prevented from being used normally. Being able to do what you been doing still works. If the question is there a new API to do those, then some of those need to be programmed to expose that functionality to an API. This isn't hard to expand the API. All messages from the viewer to the peer use the same procedure, and it looks like this: Snowglobe::Interface::Packet p( "Notecard", "Open" ) ; p["Item"] = inv_item->getUUID() ; p["Title"] = title ; p.send() ; A quick search in the patch for "Packet" can reveal all those messages. All RESTful messages going from the peer to the viewer have these nodes setup by Snowglobe::Interface::init(). Here is the current list as seen in llinterface.cpp as of 0.9.9: NodeControlGroup::build( r ) ; NodeAgentGroups::build( r ) ; NodeAvatarTrackerFriends::build( r ) ; NodeAvatarTrackerFriend::build( r ) ; NodeInterfaceConnect::build( r ) ; NodeGestureManagerItems::build( r ) ; NodeGestureManagerItem::build( r ) ; These relate to the URI resources: /ControlGroup/...; /Agent/Groups; /AvatarTracker/Friends; etc. Each one may build a few related methods for GET, POST, and wildcards. As of 0.9.9., there are a couple chat messages that still use the TCP socket rather than the RESTful method, but that is planned to be changed to be like the Nodes above. From secret.argent at gmail.com Thu Dec 24 14:16:03 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 24 Dec 2009 16:16:03 -0600 Subject: [sldev] Client-side scripting is real In-Reply-To: <4B329C6A.7020403@gmail.com> References: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> <4B323DA2.1050403@gmail.com> <20091223213704.GA14594@alinoe.com> <4B329C6A.7020403@gmail.com> Message-ID: On 2009-12-23, at 16:40, Dzonatas Sol wrote: > A peer then connects to the viewer with the resource URI: > http://x.y.z.w:50140/Interface/Connect Ick, no, please, let's not start publishing viewer IP addresses willy- nilly. Given the state of the viewer protocol and security W-Hat and the PN will have a field day. From dzonatas at gmail.com Thu Dec 24 16:21:32 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 24 Dec 2009 16:21:32 -0800 Subject: [sldev] Client-side scripting is real In-Reply-To: References: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> <4B323DA2.1050403@gmail.com> <20091223213704.GA14594@alinoe.com> <4B329C6A.7020403@gmail.com> Message-ID: <4B34058C.6060102@gmail.com> Argent Stonecutter wrote: > On 2009-12-23, at 16:40, Dzonatas Sol wrote: > >> A peer then connects to the viewer with the resource URI: >> http://x.y.z.w:50140/Interface/Connect >> > > Ick, no, please, let's not start publishing viewer IP addresses willy- > nilly. Given the state of the viewer protocol and security W-Hat and > the PN will have a field day. > > Huh? Why jump to conclusions and spread disinformation? Despite that I only used x.y.z.w as an example, it does not mean you have to use an IP address. It is a URI and no IP address is needed. I could have put: http://www.somehost.com/Interface/Connect Please, review what is meant by resource URI (in REST context): http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_2 And, what is meant by just a URI: http://labs.apache.org/webarch/uri/rfc/rfc3986.html You'll notice the semantics of root nodes and identifiers are what was significant, not the IP or host name. From secret.argent at gmail.com Thu Dec 24 18:43:14 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 24 Dec 2009 20:43:14 -0600 Subject: [sldev] Client-side scripting is real In-Reply-To: <4B34058C.6060102@gmail.com> References: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> <4B323DA2.1050403@gmail.com> <20091223213704.GA14594@alinoe.com> <4B329C6A.7020403@gmail.com> <4B34058C.6060102@gmail.com> Message-ID: <5EC11D99-C44E-49BB-81F1-C1B599D80547@gmail.com> On 2009-12-24, at 18:21, Dzonatas Sol wrote: > Argent Stonecutter wrote: >> On 2009-12-23, at 16:40, Dzonatas Sol wrote: >>> A peer then connects to the viewer with the resource URI: >>> http://x.y.z.w:50140/Interface/Connect >> Ick, no, please, let's not start publishing viewer IP addresses >> willy- nilly. Given the state of the viewer protocol and security W- >> Hat and the PN will have a field day. > Huh? Why jump to conclusions and spread disinformation? What disinformation? It doesn't matter whether what you provide is 1.2.3.4 or something.example.com, it identifies the IP address of a host for the connection. If you're using the host address for something other than a connection, then why make it an address? From carlo at alinoe.com Fri Dec 25 03:09:38 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 25 Dec 2009 12:09:38 +0100 Subject: [sldev] Client-side scripting is real In-Reply-To: <5EC11D99-C44E-49BB-81F1-C1B599D80547@gmail.com> References: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> <4B323DA2.1050403@gmail.com> <20091223213704.GA14594@alinoe.com> <4B329C6A.7020403@gmail.com> <4B34058C.6060102@gmail.com> <5EC11D99-C44E-49BB-81F1-C1B599D80547@gmail.com> Message-ID: <20091225110938.GA15996@alinoe.com> On Thu, Dec 24, 2009 at 08:43:14PM -0600, Argent Stonecutter wrote: > What disinformation? > > It doesn't matter whether what you provide is 1.2.3.4 or > something.example.com, it identifies the IP address of a host for the > connection. > > If you're using the host address for something other than a > connection, then why make it an address? No, your IP address is not shared with anyone. If you write an application, then that application can connect to 127.0.0.1 or, if you decide to run it elsewhere on your LAN, it can connect with 192.168.45.10 or whatever; that is entirely different from what you state: that some protocol would publish the real IP to strangers. Nothing like that is in order whatsoever. -- Carlo Wood From secret.argent at gmail.com Fri Dec 25 06:53:07 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 25 Dec 2009 08:53:07 -0600 Subject: [sldev] Client-side scripting is real In-Reply-To: <20091225110938.GA15996@alinoe.com> References: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> <4B323DA2.1050403@gmail.com> <20091223213704.GA14594@alinoe.com> <4B329C6A.7020403@gmail.com> <4B34058C.6060102@gmail.com> <5EC11D99-C44E-49BB-81F1-C1B599D80547@gmail.com> <20091225110938.GA15996@alinoe.com> Message-ID: On 2009-12-25, at 05:09, Carlo Wood wrote: > No, your IP address is not shared with anyone. > If you write an application, then that application > can connect to 127.0.0.1 or, if you decide to run > it elsewhere on your LAN, it can connect with > 192.168.45.10 or whatever; that is entirely different > from what you state: that some protocol would publish > the real IP to strangers. Nothing like that is in > order whatsoever. How do you communicate with that application to tell it to connect to that address to get the string in the first place? That is, how is this string published to the application? If that publication process involves a network connection, why redundantly pass the address over that connection, and open up the possibility of it being further distributed? From dzonatas at gmail.com Fri Dec 25 08:04:44 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Fri, 25 Dec 2009 08:04:44 -0800 Subject: [sldev] Client-side scripting is real In-Reply-To: References: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> <4B323DA2.1050403@gmail.com> <20091223213704.GA14594@alinoe.com> <4B329C6A.7020403@gmail.com> <4B34058C.6060102@gmail.com> <5EC11D99-C44E-49BB-81F1-C1B599D80547@gmail.com> <20091225110938.GA15996@alinoe.com> Message-ID: <4B34E29C.7040204@gmail.com> Argent Stonecutter wrote: > > How do you communicate with that application to tell it to connect to > that address to get the string in the first place? That is, how is > this string published to the application? If that publication process > involves a network connection, why redundantly pass the address over > that connection, and open up the possibility of it being further > distributed? > You can read the options now available: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/Communicator#Options If there is another option you think is desirable, then please suggest it rather than flippantly stating "ick". When there are web browsers and many other applications, like SL, that do send URIs & IP addresses over the Internet, I question why in the world would you even start your security rant with SNOW-375. If you understand the steps taken in the protocol, then why not just merely suggest a different step? That is what you didn't do, and I am unable to take you seriously because of that. 1. Localhost is the default 2. Remote connections being denied is the default (i.e. no internet, no nothing going over it). 3. The API can be turned on/off completely. 4. Until HTTPS/credentials are used, a mutual HTTP/TCP-socket session is use to establish trust. 5. HTTPS/credentials is probably overkill for localhost only, but it is still desirable for its flexibility that HTTP/TCP-socket sessions lack. If something further distributes your private information from inside your firewall to somewhere on the internet, then it's your firewall that has issues, and its not related to SNOW-375 at all. From secret.argent at gmail.com Fri Dec 25 12:24:38 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 25 Dec 2009 14:24:38 -0600 Subject: [sldev] Client-side scripting is real In-Reply-To: <4B34E29C.7040204@gmail.com> References: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> <4B323DA2.1050403@gmail.com> <20091223213704.GA14594@alinoe.com> <4B329C6A.7020403@gmail.com> <4B34058C.6060102@gmail.com> <5EC11D99-C44E-49BB-81F1-C1B599D80547@gmail.com> <20091225110938.GA15996@alinoe.com> <4B34E29C.7040204@gmail.com> Message-ID: On 2009-12-25, at 10:04, Dzonatas Sol wrote: > If there is another option you think is desirable, then please > suggest it rather than flippantly stating "ick". All you need to say "it's localhost only, and entered on the command line". It wasn't clear that this was not something communicated over the network. From tigrospottystripes at gmail.com Mon Dec 28 12:52:27 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 28 Dec 2009 18:52:27 -0200 Subject: [sldev] Script memory limits, promises, parcel bonus In-Reply-To: References: <114531C1-3106-4E6C-ABF5-1D579BEF916F@gmail.com> Message-ID: <4B391A8B.1030407@Gmail.com> many of those things i believe would work better if done by the sim instead of clients, rpelacing the dfefault anims could be just another tab on the appearance editor, with it's own wearable inventory type, the server just simply reads custom animations from that inventory item instead of running the hardcoded ones, flight assist would work better as somthing like my pjira proposal for customizing the physical cosntraintsa and forces applied on the avatar under each condition ( http://jira.secondlife.com/browse/SVC-4435 ) Lillian Yiyuan escreveu: > More on topic for the viewer. Many of that activities currently > performed by scripts should be done primarily out of viewer resources, > these include, but are not limited to, AOs, radar, scripts on > attachments, flight enhancement and so on. One short road to making it > so that script limits are not noticed, is to take off the server the > long list of activities that are server side, but do not need to be > there. If most avs can wear their clothes and their AOs and a few > gadgets, they will not notice scripting limits, and there will be more > resources for physics, graphics and so on. Client side scripting is > not easy but there have been enough implementations of it in various > places to show that it is practical and not fatal to sim performance. > > Many of these enhancements have already been put in to open source > clients, and therefore are good targets for implementation. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From tigrospottystripes at gmail.com Mon Dec 28 13:14:46 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 28 Dec 2009 19:14:46 -0200 Subject: [sldev] Fwd: Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4B2CCD7B.7000805@gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> <20091222115321.GA10705@alinoe.com> <20091222123708.GC10705@alinoe.com> Message-ID: <4B391FC6.7010004@Gmail.com> ARC isn't about server load, it's about client load Robert Martin escreveu: > ---------- Forwarded message ---------- > From: Robert Martin > Date: Tue, Dec 22, 2009 at 8:23 AM > Subject: Re: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration > To: Darrius Gothly > > ... > > 2 there needs to be a better way of seeing avatar load than ARC since > the number is semi fictional (it counts prims more heavily than > scripts) > > ... > -- > Robert L Martin > > > > From tigrospottystripes at gmail.com Mon Dec 28 13:15:19 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 28 Dec 2009 19:15:19 -0200 Subject: [sldev] Fwd: Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: References: <4B2CCD7B.7000805@gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> <20091222115321.GA10705@alinoe.com> <20091222123708.GC10705@alinoe.com> Message-ID: <4B391FE7.9080807@Gmail.com> I would rather instead of suspended, just slowed down and moved out of the way of what according to the rules should run fast. Instead of suspended animation, just have the metabolism reduced. Argent Stonecutter escreveu: > People keep talking about a hypothetical "suspended" state for scripts. > > That will not happen. It's not in the plan as described by Babbage, > and it would be very difficult to implement in a way that actually > delivered on the memory savings that are needed. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From tigrospottystripes at gmail.com Mon Dec 28 13:17:48 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 28 Dec 2009 19:17:48 -0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <6A9C459E-B5B2-42E4-87CE-AFF1D0AFC9DC@gmail.com> References: <4B2C2336.9010809@Gmail.com> <4B2CCD7B.7000805@gmail.com> <4B2D1175.6090601@Gmail.com> <55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com> <4B2E64BF.3070706@Gmail.com> <840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com> <4B2EC214.4000008@Gmail.com> <5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com> <20091222115321.GA10705@alinoe.com> <6A9C459E-B5B2-42E4-87CE-AFF1D0AFC9DC@gmail.com> Message-ID: <4B39207C.3030708@Gmail.com> I know disk I/O is the bottleneck, that is why i'm proposing scripts run from disk having less priority and only continuing to run on spare cycles, including taking in consideration the time cost on the system for the planned isk I/O, using a seprated hard drive etc Argent Stonecutter escreveu: > On 2009-12-22, at 05:53, Carlo Wood wrote: > >> I already commented on this before imho... Yes it is possible >> to run scripts that are on harddisk; although I'm not sure >> you can use a part of the OS that easily to achieve it. >> > > >> Imho, you could let a script run for 1 ms (100 scripts at a time) >> every 3 seconds, only using 6.4 MB of RAM that is refreshed >> from disk (with 100 next scripts) every 100 ms. >> > > The reason that thrashing virtual memory is a problem is because disk > I/O is a bottleneck. > > Adding more disk I/O is not the solution. > > From kck325 at gmail.com Mon Dec 28 20:37:47 2009 From: kck325 at gmail.com (chandra kiran kuchi) Date: Mon, 28 Dec 2009 23:37:47 -0500 Subject: [sldev] Playing a local video in SLViewer Message-ID: Hello SLDev, I am trying to play a video which is available on local disk in to a view port inside SLViewer. What is the best way to do it? My Plan is: 1) Make an html file with embedded video player 2) Using UIFloaters display the html and then play the video. Is this the correct way? or Can I do it in a better way? -- Regards, Chandra K Kuchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091228/1b96e238/attachment.htm From tigrospottystripes at gmail.com Mon Dec 28 21:46:15 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Tue, 29 Dec 2009 03:46:15 -0200 Subject: [sldev] Script/Parcel/Memory Limits - Memory Limit Configuration In-Reply-To: <2EF6993A5EE340498E505E4CCD2C9A92@jbh3000> References: <4B2C2336.9010809@Gmail.com><4B2CCD7B.7000805@gmail.com><4B2D1175.6090601@Gmail.com><55EF9138-D716-4A16-AD44-FFE1DD57D2A7@gmail.com><4B2E64BF.3070706@Gmail.com><840B1112-8498-41B7-B0ED-CE88C4D07BE1@gmail.com><4B2EC214.4000008@Gmail.com><5CBE911B-3FA3-4972-9A84-3BE20702E960@gmail.com><20091222115321.GA10705@alinoe.com> <44525793641C475E9164D9499FECA14D@panther> <2EF6993A5EE340498E505E4CCD2C9A92@jbh3000> Message-ID: <4B3997A7.2030909@Gmail.com> how about : http://jira.secondlife.com/browse/SVC-5199 "event before somthing is done to a script that is using more memory than it should" put an llEmail or llInstantMessage or even llSetText or somthing else that changes the appearance of the prim, in the event and you will know if the script is not runing anymore/got downgraded into sporadicly running when there is iddle time on the sim or whatever happens to scripts in such situation, Darrius Gothly escreveu: > Another issue came to mind as I was reading this ... > > How does anyone know the script has been disabled? I mean, what's to > indicate it's a system-imposed "malfunction" vs. one that just happened > because the script hit a bug? And "screaming on the DEBUG CHANNEL" just > isn't sufficient because the owner may not even be logged in when the system > disables the script. There has to be something plainly evident (at least to > the owner if not everyone else) indicating the object has been disabled by > the Sim/System. Perhaps one of those little floating icons like is seen when > there is a script error, but that stays around until the object is deleted, > taken or returned ... or restarted. And of course that will require an > additional attribute per Prim. > > ----- Original Message ----- > From: "Kitty" > To: "'SLDEV'" > Sent: Tuesday, December 22, 2009 10:41 AM > Subject: Re: [sldev] Script/Parcel/Memory Limits - Memory Limit > Configuration > > > >>> [3:42] Babbage Linden: that will include functionality for >>> finding and returning scripted objects >>> >>> [3:42] Babbage Linden: so everyone will be able to find and >>> clean up the scripts they don't need >>> >>> [3:43] Babbage Linden: before we start enforcing limits >>> >>> >> I would hope that simply refers to what you can do today with the "Top >> Scripts" floater (highlight a scripted object + click return). >> >> Otherwise you'll get chaos where someone checks their sim the day before >> the >> roll-out, finds that they're within the limit, goes to bed and wakes up to >> dozens of auto-returns because some other group member decided to rez some >> new script-heavy toy they just bought which pushed it over the limit. >> >> Expecting every land or group owner all over SL to turn off build for >> everyone for a few days is simply not realistic, particularly given the >> fact >> that only a small portion of residents reads the blog which is only in >> English. >> >> Given the high failure rate of return in general if sims all over the grid >> start auto-returning prims then a good portion of those will go *poof* and >> never return to anyone's inventory. That alone should be enough to not >> even >> consider auto-returning anything. >> >> Objects should simply get their scripts disabled and then the owner can >> decide to leave them around "script-less" or take them back into their >> inventory or do something else to get them working again. >> >> Similarly rezzing should never fail because of script limits because that >> would make it rather impossible to fix objects after the script limits are >> in place. Or someone will be working on something, drop in a new script, >> the >> parcel hits its script limit, the prim gets auto-returned and then can't >> be >> rerezzed. >> >> It would also be very fun for updaters: rez the updater, updater drops new >> scripts into the older version, which then subsequently gets auto-returned >> because the limit is reached and ends up broken because it's half-old and >> half-new. Things won't improve if the updater gets auto-returned since >> it's >> the last to have been rezzed, or if it gets its scripts disabled halfway >> through. >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From me at signpostmarv.name Tue Dec 29 05:43:50 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue, 29 Dec 2009 13:43:50 +0000 Subject: [sldev] Playing a local video in SLViewer In-Reply-To: References: Message-ID: <4B3A0796.802@signpostmarv.name> If you're only wanting it to be viewable by yourself, use a file:/// URI. e.g. file:///v:/Second%20Life/2001/LindenWorldAugust2001.mov ~ Marv. On 29/12/2009 04:37, chandra kiran kuchi wrote: > Hello SLDev, > > I am trying to play a video which is available on local disk in to a > view port inside SLViewer. > > What is the best way to do it? > > My Plan is: > > 1) Make an html file with embedded video player > 2) Using UIFloaters display the html and then play the video. > > Is this the correct way? or Can I do it in a better way? > > -- > Regards, > Chandra K Kuchi > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091229/7b65be5a/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5150 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20091229/7b65be5a/attachment-0001.bin From smitzla at us.ibm.com Tue Dec 29 07:10:53 2009 From: smitzla at us.ibm.com (Sid Mitzlaff) Date: Tue, 29 Dec 2009 08:10:53 -0700 Subject: [sldev] Sid Mitzlaff is out of the office. Message-ID: I will be out of the office starting 12/28/2009 and will not return until 01/04/2010. I will respond to your message when I return. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091229/dc0b5b0d/attachment.htm From merov at lindenlab.com Tue Dec 29 17:01:21 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 29 Dec 2009 17:01:21 -0800 Subject: [sldev] SNOW-301: updated pluginapi code Message-ID: <78f69850912291701n614381ehc9aaf91780daee4@mail.gmail.com> Hi there, I've been working on this before my (short) Xmas vacation and I'm not back in the saddle with it. I posted a new patch to JIRA: http://jira.secondlife.com/browse/SNOW-301 Can someone build, test and see if things regressed for them? I tried on Mac and Windows but not Linux. Also, if one of our beloved standalone builders could give it a try, that'd be great: that patch uses a much newer llqtwebkit and should fix MOZ-39. I say should as I haven't checked all ins and outs. Well, more to do before committing but, as always, help welcome. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091229/1e56f76e/attachment.htm