Re: [opensource-dev] Backport of Tattoo and Alpha support t o v1.23 ?
On Wed, 10 Mar 2010 19:22:38 -0600, Maya Remblai wrote: > Henri Beauchamp wrote: >> My guess is that very few old timers, power users and role-players will >> bother with 2.0 once third parties viewers implementing the v1 UI will >> have all the main features of v2.0 backported... >> > I'd say that's a very accurate guess. I add my pointless and unuseful point of view to the other ones, and I say I think the opposite will happen - old interface use will fade out for most users, even for power users, even when new features got backported. Poke me in 12 months to check it out. opensource obscure ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Backport of Tattoo and Alpha support to v1.23 ?
At 10:42 PM 3/10/2010, you wrote: >Andromeda Quonset wrote: > > I'd like to see the entire alpha wearables support and feature > > removed in it's entirety. Ever since it was introduced, AV's are > > generally invisible unless I am within 5 meters of them. I'm more > > than a little tired of attending meetings that are nothing more than > > me, and a bunch of floating nametags that never rez. > > >That's a problem with your system, I'd imagine. I haven't heard that >complaint from anyone, and it's highly unlikely that all those people >were using 2.0 (and thus able to wear alpha masks) anyway. Though it IS >possible, if they were indeed using 2.0, that they were intentionally >wearing total alpha masks, which would make them invisible. But I'm >betting on graphics card issues on your end. Open a JIRA with your exact >specs, and hopefully someone can track it down. :) > >And if you don't like the idea of alpha masks, you've probably never >worn a non-human avatar, or shoes. ;) > >Maya Thanks for responding, Maya! I don't think that the AV's I wasn't seeing were running 2.0, or were necessarily using an alpha mask. I started seeing this with sim 1.34. I have tried several viewers, and it seems to be present in the viewer I prefer using: The Windows Cool Viewer from Boy Lane that is based on the 1.22 viewer code. I haven't seen the issue when I use Emerald, or viewers which are based on 1.23, 1.21, or 1.19 code. So, I am looking forward to the backporting of the 2.0 code to see if resolves the problem. Otherwise, I don't really care one way or the other about alpha masks / didn't care until it started effecting me. I have been known to wear shoes, and I have never been known to wear a non-human avatar, but it seems to me that alpha textures would be more of a hindrance than a help with non-human avatars. Andro ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Backport of Tattoo and Alpha support to v1.23 ?
> Thanks for responding, Maya! > > I don't think that the AV's I wasn't seeing were running 2.0, or were > necessarily using an alpha mask. I started seeing this with sim > 1.34. I have tried several viewers, and it seems to be present in > the viewer I prefer using: The Windows Cool Viewer from Boy Lane > that is based on the 1.22 viewer code. I haven't seen the issue when > I use Emerald, or viewers which are based on 1.23, 1.21, or 1.19 > code. So, I am looking forward to the backporting of the 2.0 code to > see if resolves the problem. > Very strange. I wouldn't expect a server update to affect rendering, but I've seen stranger things happen. All I can think of is to open a JIRA and see if anyone else is having the same problem. Sorry I can't be of more help. > Otherwise, I don't really care one way or the other about alpha masks > / didn't care until it started effecting me. I have been known to > wear shoes, and I have never been known to wear a non-human avatar, > but it seems to me that alpha textures would be more of a hindrance > than a help with non-human avatars. > > Andro > > It's the opposite, actually (about non-human avatars). When you want to be a horse, you want to be just a horse, not a horse with a human head sticking out of its neck. If you want to be extremely small, you want to have only your tiny creature body showing, not a mess of squished mesh. Being able to make part or all of the base mesh invisible is very important. That's why invisiprims have been in use for so long, and LL got in so much trouble when they tried to "fix" them without alpha masks available. I can show you how important it is in-world sometime. I have a couple of micro avatars (smaller than "tinies") that don't work at all unless the avatar mesh is hidden, such as with an alpha mask. They also don't work with invisiprims. Maya ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Backport of Tattoo and Alpha support to v1.23 ?
On Wed, 10 Mar 2010 22:40:14 -0500, Johnnie Carling wrote: > Henri, any chance you could add a color/tint setting to the tattoo layer? Very little chances... After the next Cool SL Viewer release, I'll concentrate on branding it in a way that is compatible with the TPV (and this branding stuff will take much work for the v1.19 branch, since its source provides no built-in way for an easy branding :-/ ). > And would that even be visible if I gave/sold someone a tinted tattoo > and they used viewer 2.0 No. Anyone would be able to see your colored tattoo if you are using a colored tattoo compatible viewer, since what they see is actually the backed texture your viewer uploaded, but to bake it properly, your viewer must be aware of the color support for tattoos... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Backport of Tattoo and Alpha support to v1.23 ?
On Wed, 10 Mar 2010 21:00:16 -0700, Andromeda Quonset wrote: > I'd like to see the entire alpha wearables support and feature > removed in it's entirety. Ever since it was introduced, AV's are > generally invisible unless I am within 5 meters of them. I'm more > than a little tired of attending meetings that are nothing more than > me, and a bunch of floating nametags that never rez. This bug (having to cam-in on an avatar to get it shown on screen) was fixed ages ago in the Cool SL Viewer... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Script Memory Management Algorithm
It makes little sense to me to put time into convincing a random non-Linden. And since LL is going to ignore the whole discussion/idea anyway, I have better things to do. Sorry. On Wed, Mar 10, 2010 at 11:56:36AM -0500, Lear Cale wrote: > If it were a simple change, I'm sure it would be considered. What > you're suggesting sounds like would require a massive rewrite. I > agree that a dynamic system would be much better, easier to code and > less wasted memory. But without detailed knowledge of how the system > is currently implemented, it's not possible to assess how difficult it > would be to change from a fixed allocation scheme to a dynamic one. > > It's easy to ask for changes without regard to the cost. LL needs to > consider the cost, in terms of effort and risk. Can you do a > cost/benefit analysis on your suggestion? Or are you just being > immovably stubborn? There would be a one-time cost to write it. I doubt that needed four to eight times the amount of physical RAM weight up against any (possible) maintenance cost (which I estimate to be neglectable in the first place). > Lear -- Carlo Wood ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Backport of Tattoo and Alpha support to v1.23 ?
On Wed, Mar 10, 2010 at 03:54:44PM +0100, Lance Corrimal wrote: > plain wrong, since you can't NOT wear system hair. > you can wear system hair of length 0, otherwise known as a "bald hair base". > the one you're wearing while creating an alpha layer in a viewer with this > unfinished patch becomes broken, and turns you into a cloud. The patch is broken :p -- Carlo Wood ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Script memory limit vs server CPU utilization as a key metric
On Wed, Mar 10, 2010 at 03:51:31AM -0800, Ann Otoole wrote: > If you guys want to really help then give us the ability to disable scripts by > attachment creator name. There are certain products that cause problems. Made > by people LL props up as shining examples of how creators should be BTW lmao. This is the kind of witch-hunt that I hope won't happen. It's better to find out what is happening, understand it, and then fix it; then to start shooting uninformed around and try to get some kind of improvement by trial&error. -- Carlo Wood ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] [server-beta] Script Memory Management Algorithm
Truth be told, we're all humans. Give a monkey enough rope to hang himself and he probably will. A dynamic system makes sense because the people who only need a small slice can live happily and the people who need more resources have the flexibility they need... Of course, those are ideal conditions. What can happen (which, may not happen all the time) is you have some asshat who decides to script an endless loop and ends up crashing the sim. I'm all for this 100%, but as long as LL does something to cover their assets and prevent any one person from overloading the system, that would be cool. Maybe we can handle scripts like Linux handles memory. Use up an allotted space based on requirements and if it exceeds that (among other scripts using the same shared environment) it can begin to swap in it's own little cluster. Maybe in the future, SL scripts can have their own dedicated memory. For example, similar to our asset servers, we can have the scripts use memory on a massive cluster of servers allowing the sims to handle stuff like rezzing, etc. Separating the scripts from the rest of the sims would be cool in theory because it would prevent isolated sim crashing as all the load would be distributed between a ton of machines. And LL already has grey goo prevention. So rez freaks can't take over. People can disable particles as well and that will cover particle spam. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] [server-beta] Script Memory Management Algorithm
On 2010-03-11, at 06:21, Jonathan Irvin wrote: > Maybe we can handle scripts like Linux handles memory. Use up an > allotted space based on requirements and if it exceeds that (among > other scripts using the same shared environment) it can begin to > swap in it's own little cluster. It doesn't matter whether the swapping is done by the OS or by the server process, it's the disk I/O bottleneck that swapping causes that's the real problem. And making scripts run on a separate server would just make all scripts many times slower and increase server network overhead. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Request for comments about llSetAgentEnvironment / SVC-5520
What would be wrong with a dialog that informs the visitor they can have an enhanced experience by accepting the environment settings that are optimal. Of course some of us would want those settings to become an available option anywhere so it is a matter of the owner providing the settings and the server sending the xml down to the client and installing them in the appropriate directories (sky, water, etc.) An example would be the Bryn Oh Immersiva region. It takes quite a bit of time to adjust the touchy and near impossible to fine tune sky settings to meet the settings that are made available by touching a kiosk. So not only do we need these settings to come down on demand automatically the windlight settings need to have value input boxes for exact settings instead of the sliders that are difficult to get to a specific setting. As for the concerns of malicious intent well there is an abuse reporting system for that. In addition glow needs to be restricted to 0 to 1. Anything over 1 can damage a video card so it should not even be allowed to overdrive like that. I learned the hard way when i literally burned up a dual SLI system experimenting with modulating glow. The ozone stench was significant. From: Kelly Linden To: Maggie Leber (sl: Maggie Darwin) Cc: opensource-dev@lists.secondlife.com Sent: Wed, March 10, 2010 12:57:50 PM Subject: Re: [opensource-dev] Request for comments about llSetAgentEnvironment / SVC-5520 On Wed, Mar 10, 2010 at 9:53 AM, Maggie Leber (sl: Maggie Darwin) wrote: > >>If it was easier to do, would you even be lobbying to make them >>automatic under the control of the parcel owner? > Absolutely. In fact, being easy to change / fix / revert would be a pre-req in my mind. > > >>> I think we get more amazing in world experiences that way. > >If I'm going to have "amazing experiences", I'd like to to be >>voluntary, thanks. And if you're going to accuse me of >>"fear-mongering" and "panic", do kindly read the JIRAs first. > They should be voluntary in the sense that any content or place in SL is voluntary. The very sky around you should be part of the content, part of the place. I can't get over how awesome I think that would be. - Kelly ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Script memory limit vs server CPU utilization as a key metric
On Thu, Mar 11, 2010 at 7:18 AM, Carlo Wood wrote: > On Wed, Mar 10, 2010 at 03:51:31AM -0800, Ann Otoole wrote: >> If you guys want to really help then give us the ability to disable scripts >> by >> attachment creator name. There are certain products that cause problems. Made >> by people LL props up as shining examples of how creators should be BTW lmao. This would be a really bad idea, because there are plenty of full-perm freebies from reputable, sensible content creators that anyone could easily turn into a resource hogs, sullying those creators' names. This would be an easy way to torpedo a competitor. I vote a resounding "no". Instead, we need the ability to delete scripts from objects even if they're no-mod, as we used to have. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] [server-beta] Script Memory Management Algorithm
I disagree, Argent. If the server process does explicit swapping for script memory, it would have a dramatically lower impact on the server process as a whole, and no impact on the other server processes sharing the same machine. > It doesn't matter whether the swapping is done by the OS or by the > server process, it's the disk I/O bottleneck that swapping causes > that's the real problem. If the complexity is manageable, this would be a good solution. However, it's nearly impossible for those of us who don't know the internals of Mono or it's SL adaptation to assess the complexity that this would require. We all know that in practice, even when we understand a system quite thoroughly, making an underlying change that seems easily uncoupled turns out to be surprisingly trickier than we'd thought. Reminds me of a famous statement often made by gurus: "Sure, try it, it should just work!" Sometimes, they're right! Lear On Thu, Mar 11, 2010 at 7:33 AM, Argent Stonecutter wrote: > On 2010-03-11, at 06:21, Jonathan Irvin wrote: >> Maybe we can handle scripts like Linux handles memory. Use up an >> allotted space based on requirements and if it exceeds that (among >> other scripts using the same shared environment) it can begin to >> swap in it's own little cluster. > > It doesn't matter whether the swapping is done by the OS or by the > server process, it's the disk I/O bottleneck that swapping causes > that's the real problem. > > And making scripts run on a separate server would just make all > scripts many times slower and increase server network overhead. > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Script Memory Management Algorithm
Fine, don't waste your time responding. Go do better things. On Thu, Mar 11, 2010 at 6:39 AM, Carlo Wood wrote: > It makes little sense to me to put time into convincing a random non-Linden. > And since LL is going to ignore the whole discussion/idea anyway, I have > better things to do. Sorry. > > On Wed, Mar 10, 2010 at 11:56:36AM -0500, Lear Cale wrote: >> If it were a simple change, I'm sure it would be considered. What >> you're suggesting sounds like would require a massive rewrite. I >> agree that a dynamic system would be much better, easier to code and >> less wasted memory. But without detailed knowledge of how the system >> is currently implemented, it's not possible to assess how difficult it >> would be to change from a fixed allocation scheme to a dynamic one. >> >> It's easy to ask for changes without regard to the cost. LL needs to >> consider the cost, in terms of effort and risk. Can you do a >> cost/benefit analysis on your suggestion? Or are you just being >> immovably stubborn? > > There would be a one-time cost to write it. I doubt that needed > four to eight times the amount of physical RAM weight up against > any (possible) maintenance cost (which I estimate to be neglectable > in the first place). > >> Lear > > -- > Carlo Wood > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] [server-beta] Script Memory Management Algorithm
On 2010-03-11, at 07:48, Lear Cale wrote: > I disagree, Argent. If the server process does explicit swapping for > script memory, it would have a dramatically lower impact on the server > process as a whole, and no impact on the other server processes > sharing the same machine. Decades of experience with the results of programs trying to beat the performance of demand paged virtual memory with manual ad-hoc paging systems makes me remarkably skeptical of this claim. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] [server-beta] Script Memory Management Algorithm
The intent isn't to try to exceed or even come close to hardware-based virtual memory. The intent is to isolate the effects of memory overuse of one part of the system, to keep this from affecting other parts. However, I'd wager that you're right that it would involve a noteworthy performance penalty, even when no paging is required. Lear On Thu, Mar 11, 2010 at 8:56 AM, Argent Stonecutter wrote: > On 2010-03-11, at 07:48, Lear Cale wrote: >> I disagree, Argent. If the server process does explicit swapping for >> script memory, it would have a dramatically lower impact on the server >> process as a whole, and no impact on the other server processes >> sharing the same machine. > > Decades of experience with the results of programs trying to beat the > performance of demand paged virtual memory with manual ad-hoc paging > systems makes me remarkably skeptical of this claim. > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Script memory limit vs server CPU utilization as a key metric
Or at least the ability to disable them if the object is no-mod. On Thu, Mar 11, 2010 at 5:41 AM, Lear Cale wrote: > On Thu, Mar 11, 2010 at 7:18 AM, Carlo Wood wrote: > > On Wed, Mar 10, 2010 at 03:51:31AM -0800, Ann Otoole wrote: > >> If you guys want to really help then give us the ability to disable > scripts by > >> attachment creator name. There are certain products that cause problems. > Made > >> by people LL props up as shining examples of how creators should be BTW > lmao. > > This would be a really bad idea, because there are plenty of full-perm > freebies from reputable, sensible content creators that anyone could > easily turn into a resource hogs, sullying those creators' names. > This would be an easy way to torpedo a competitor. I vote a > resounding "no". > > Instead, we need the ability to delete scripts from objects even if > they're no-mod, as we used to have. > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
