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

[Ann Otoole]

Oddly it is pretty much a fact that when over 10 avatars enter my region and 
script time goes up far enough for spare time to remain at zero the sim starts 
lagging. Lagging as in rubber banding, getting pending downloads rising, etc. 
Not sure what sort of sims you guys are looking at but it is rather obvious to 
us that actually use Second Life and have to monitor this daily and then have 
to restart the region daily or so to get the sim under control seem to have a 
totally different experience than what you describe.

Once upon a time we could get 100 avatars in a sim. Sure there would be lag. 
Lag like you now get with more than 20 in a sim.

I do see the stats in the viewer go nuts from time to time. Perhaps that is 
related to some other sim on the same host causing the swap problem? Because it 
happens from time to time even when there are only a couple of avatars in the 
sim.

Personally I think the observations made over more than a year that prove the 
sim lags when script time consumes so much time there is no spare time left in 
a frame is rather accurate. Because the lag happens every time the saturation 
occurs.

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. 
Sorry but it doesn't appear to me like you guys are monitoring islands with 
even low to medium traffic too much. 

Oh and are you running 8 private islands to a host now? Or is the service that 
tries to let you know who all is on the same region simply incorrect? Thanks 
for clearing that question up if possible.




From: Kelly Linden 
To: Joel Foner 
Cc: opensource-dev@lists.secondlife.com
Sent: Tue, March 9, 2010 3:57:13 PM
Subject: Re: [opensource-dev] Script memory limit vs server CPU utilization as 
a key metric

Hi Joel.

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

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

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

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

 - Kelly

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


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

Many apologies if this has been discussed at length in a place that I've 
missed...
>
>
>I'm a bit baffled by the continuing strong focus on memory utilization of 
>scripts rather than CPU load on the host servers. If (maybe I'm missing an 
>important issue here) the issue is to avoid a resident or scripted item from 
>causing performance problems on a region, wouldn't the relative CPU load 
>imposed by that script be a critical item? 
>
>
>I understand that if the total active memory size for a server goes above it's 
>physical available RAM, then paging would increase and potentially create 
>issues. Is there some objective analysis of servers with the Second Life 
>simulator code on to show that they go into continuous swap mode in this case, 
>or is it occasional "blips" of performance degradation on a slower interval? 
>It seems to me that having continuing excessive CP

Re: [opensource-dev] Backport of Tattoo and Alpha support to v1.23 ?

[Lance Corrimal]

Hmm...


this won't help...
I managed to adapt that patch for snowglobe 1.4, and editing an alpha layer 
corrupts skin and system hair, instead of skin and eyes.


bye,
LC


Am Montag, 8. März 2010 22:23:32 schrieb Henri Beauchamp:
> Greetings,
> 
> I was wondering if Linden Lab was going to provide an updated v1.23
> viewer with tattoo and alpha wearables support ?...
> After all, and from LL's own admission, the v1.23 viewer is going to
> be officially supported for quite a few more months even after v2.0
> goes into production (a good thing, because patching v2.0 to make it
> *acceptable* by power users and old timers will take a long while...),
> and I think such a feature will be required pretty fast (I can see how
> prim-shoes or prim-avatar makers could benefit of it)...
> 
> I did some backport work on my side, based on the Snowglobe v2.0
> sources: basically, things work (tattoo support is ok, alpha wearing
> and rendering is ok), but I still got a problem with alpha editing (as
> soon as I change a texture for the alpha in the customize appearance
> floater, it corrupts the textures of the skin and eyes wearables).
> 
> I'm attaching here the patch I came up so far for v1.23.5, but
> I could use the help of one of the Lindens who coded this feature,
> and/or of someone with a "new eye" on my patch in order to help me
> spot what I missed or overlooked in v2.0 sources (the changes are
> many, and it's kind of hard to spot all the related and required
> changes among 24Mb of diff, not to mention the guess work around the
> texture layering and baking algorithms in each v1.23 and v2.0)...
> 
> Henri.
> 
> PS: to use the patch, first apply
> slviewer-0-v12350-AlphaAndTattooSupport_v0.patch
> with 'patch -p1' from inside the linden/ source tree, then
> unzip slviewer-0-v12350-AlphaAndTattooSupport-patch.zip

___
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

[Argent Stonecutter]

On 2010-03-10, at 05:51, Ann Otoole wrote:
> Oddly it is pretty much a fact that when over 10 avatars enter my  
> region and script time goes up far enough for spare time to remain  
> at zero the sim starts lagging. Lagging as in rubber banding,  
> getting pending downloads rising, etc.

Which is caused by script memory getting so high that the sim starts  
swapping. Yes, that may show as high script time because the time  
needed to swap in the scripts again will get charged against the script.

Whether the scripts are disabled or not is irrelevant, if they're  
still loaded.

___
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

[Ann Otoole]

Please do not answer my query directed to Kelly Linden unless you are Kelly 
Linden. 






From: Argent Stonecutter 
To: opensource-dev@lists.secondlife.com
Sent: Wed, March 10, 2010 7:37:18 AM
Subject: Re: [opensource-dev] Script memory limit vs server CPU utilization as 
a key metric

On 2010-03-10, at 05:51, Ann Otoole wrote:
> Oddly it is pretty much a fact that when over 10 avatars enter my  
> region and script time goes up far enough for spare time to remain  
> at zero the sim starts lagging. Lagging as in rubber banding,  
> getting pending downloads rising, etc.

Which is caused by script memory getting so high that the sim starts  
swapping. Yes, that may show as high script time because the time  
needed to swap in the scripts again will get charged against the script.

Whether the scripts are disabled or not is irrelevant, if they're  
still loaded.

___
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] Backport of Tattoo and Alpha support to v1.23 ?

[Glen Canaday]

On the bright side - anyone making tattoos and understanding the alpha 
mask isn't wearing system hair... 

--GC

On 03/10/2010 06:59 AM, Lance Corrimal wrote:
> Hmm...
>
>
> this won't help...
> I managed to adapt that patch for snowglobe 1.4, and editing an alpha layer
> corrupts skin and system hair, instead of skin and eyes.
>
>
> bye,
> LC
>
>
> Am Montag, 8. März 2010 22:23:32 schrieb Henri Beauchamp:
>
>> Greetings,
>>
>> I was wondering if Linden Lab was going to provide an updated v1.23
>> viewer with tattoo and alpha wearables support ?...
>> After all, and from LL's own admission, the v1.23 viewer is going to
>> be officially supported for quite a few more months even after v2.0
>> goes into production (a good thing, because patching v2.0 to make it
>> *acceptable* by power users and old timers will take a long while...),
>> and I think such a feature will be required pretty fast (I can see how
>> prim-shoes or prim-avatar makers could benefit of it)...
>>
>> I did some backport work on my side, based on the Snowglobe v2.0
>> sources: basically, things work (tattoo support is ok, alpha wearing
>> and rendering is ok), but I still got a problem with alpha editing (as
>> soon as I change a texture for the alpha in the customize appearance
>> floater, it corrupts the textures of the skin and eyes wearables).
>>
>> I'm attaching here the patch I came up so far for v1.23.5, but
>> I could use the help of one of the Lindens who coded this feature,
>> and/or of someone with a "new eye" on my patch in order to help me
>> spot what I missed or overlooked in v2.0 sources (the changes are
>> many, and it's kind of hard to spot all the related and required
>> changes among 24Mb of diff, not to mention the guess work around the
>> texture layering and baking algorithms in each v1.23 and v2.0)...
>>
>> Henri.
>>
>> PS: to use the patch, first apply
>>  slviewer-0-v12350-AlphaAndTattooSupport_v0.patch
>>  with 'patch -p1' from inside the linden/ source tree, then
>>  unzip slviewer-0-v12350-AlphaAndTattooSupport-patch.zip
>>  
> ___
> 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

[Maggie Leber (sl: Maggie Darwin)]

I'd be more interested in the answer to Ann's "are you running 8
private islands to a host now?" question.

I'd heard the claim that that was happening on mainland; that it might
be happening to estate owners too (with no notice) is new to me.

It's certainly germane to discussion of the cross-region impact of
server sharing. Especially given that we're told memory and swapdisk
activity is much more important than CPU.

I'd also like to know how many regions are running per NIC, especially
in light of  SVC-5357 and  VWR-15781. Are there known multi-home
network queueing problems in the OS? How much real memory per region
would be interesting too.

All highly "proprietary", I'm sure.  But when you start making server
performance a customer problem and solving it on our backs, we deserve
some facts, or we're left continuing to buy a pig in a poke.

Will we get the newly-standard Linden "I can't comment on that, you
should ask to Devnull Linden whose office hours are every February
29th at 4am EST" response?

Or none at all?
___
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

[Marine Kelley]

Devnull Linden. Haha. That's a good one :D

(Note : this message holds no value added and presents a mild time- 
wasting factor. Read at your own risks)


On 10 mars 2010, at 15:30, "Maggie Leber (sl: Maggie Darwin) " 
 wrote:

> I'd be more interested in the answer to Ann's "are you running 8
> private islands to a host now?" question.
>
> I'd heard the claim that that was happening on mainland; that it might
> be happening to estate owners too (with no notice) is new to me.
>
> It's certainly germane to discussion of the cross-region impact of
> server sharing. Especially given that we're told memory and swapdisk
> activity is much more important than CPU.
>
> I'd also like to know how many regions are running per NIC, especially
> in light of  SVC-5357 and  VWR-15781. Are there known multi-home
> network queueing problems in the OS? How much real memory per region
> would be interesting too.
>
> All highly "proprietary", I'm sure.  But when you start making server
> performance a customer problem and solving it on our backs, we deserve
> some facts, or we're left continuing to buy a pig in a poke.
>
> Will we get the newly-standard Linden "I can't comment on that, you
> should ask to Devnull Linden whose office hours are every February
> 29th at 4am EST" response?
>
> Or none at all?
> ___
> 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] Backport of Tattoo and Alpha support to v1.23 ?

[Lance Corrimal]

Am Mittwoch, 10. März 2010 15:29:01 schrieb Glen Canaday:
> On the bright side - anyone making tattoos and understanding the alpha
> mask isn't wearing system hair... 

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

[Argent Stonecutter]

If you don't want people to respond to public messages, don't post  
them publicly.

On 2010-03-10, at 08:13, Ann Otoole wrote:
> Please do not answer my query directed to Kelly Linden unless you  
> are Kelly Linden.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Opensource Obscure]

Yesterday Jopsy Pendragon submitted this feature request
to the public JIRA:

llSetAgentEnvironment( key agent, [ param list ] );
http://jira.secondlife.com/browse/SVC-5520

I'd like to hear your comments.

I'm not competent enough to say if the request is
feasible as it's proposed, but the proposed LSL 
implementation would be fine for me.

This complements other old PJIRA issues, like

Estate / Sim Windlight preset / day cycle options
http://jira.secondlife.com/browse/VWR-7677
(450 votes)

and many others - see meta-issue
http://jira.secondlife.com/browse/SVC-2736

Please provide feedback and vote as you feel appropriate.

New, powerful Light/Shadows features are going to
appear into the official SL viewer;
the number of users with hardware capable of 
running advanced lighting features grows;
so SL land owners need control over this, and IMHO 
they will need it even more in the future. 


bye
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] Request for comments about llSetAgentEnvironment / SVC-5520

[Maggie Leber (sl: Maggie Darwin)]

On Wed, Mar 10, 2010 at 11:05 AM, Opensource Obscure  wrote:
> Yesterday Jopsy Pendragon submitted this feature request
> to the public JIRA:
>
> llSetAgentEnvironment( key agent, [ param list ] );
> http://jira.secondlife.com/browse/SVC-5520

As long as I'm *asked for permission* before somebody I don't know
jams a reconfiguration into my viewer...
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Management Algorithm

[Lear Cale]

Most scripts allocate space (add items to lists) based on events.  How
would the number of events be estimated?
Seriously, this requires more than an oracle.  It requires
clairvoyance.  Unless the coder specically codes a limit on the number
of list elements added, there is no way to predict.

Lear

On Tue, Mar 9, 2010 at 5:57 PM, Michael Schlenker
 wrote:
>
> Am 09.03.2010 um 02:54 schrieb Lear Cale:
>
>> huh?  Can you point to existing technology for this analyzer?  Seems
>> to me like it would require an oracle.
>
> It might require an oracle to reach 100%, but if you go for the easy part, 
> its not that hard (assuming a sane GC). LSL is a pretty simple language 
> without many of the problems you have with C like pointers and memory 
> aliasing and stuff like that. Not sure if one could reuse parts of the LLVM 
> analyzers/optimizers for Mono to do this (Mono 2.6 can compile for a LLVM 
> backend).
>
> 1. All scripts that only handle integer, float, vector, key and rotation 
> variables without recursive calls can be handled easily.
> --> The memory size for those types is fixed.
> --> One could probably compute a complete callgraph and add up the maximum 
> number of used locals too.
>
> 2. If the script uses recursion, it depends. If the compiler can figure out 
> the maximum depth, works as 1, if it can eliminate tailcalls, it can do 1. 
> too. If it cannot, its a lost cause and it must assume the worst aka 64kB.
>
> 3. If the script uses strings, it depends what operations are used on those 
> strings. The only critical operation is appending strings to other strings, 
> comparing, getting substrings etc. could all be done in constant memory. As 
> all functions that can provide strings to a script have an upper bound on 
> parameter size one could calculate a 'worst case' scenario in many cases. 
> Just assume any LSL function or event that returns/provides a string provides 
> a unique string of maximum size. Sum up and you have a worst case limit.
>
> 4. If the script uses lists of other data types use similar techniques as for 
> strings. As LSL does not have any reference types and you cannot nest lists 
> this is not too hard to do because list are essentially flat like strings.
>
> This of course assumes some small glitches are allowed like the overhead of 
> copying a string/list, because the gc can free that memory at once if needed.
>
> For simple scripts, e.g. the ugly 100s of 'resizer' scripts you find in 
> hairs, shoes etc. this could work pretty well, as those are usually just one 
> link_message handler with trivial code and one or two functions that call 
> llSetPrimitiveParams(). You might overestimate by one or two kB, because you 
> don't know how big the link_message string and key parameters are, but other 
> than that it should work pretty well.
>
> Michael
>
>>
>> On Mon, Mar 8, 2010 at 2:03 PM, Michael Schlenker
>>  wrote:
>>>
>>> Am 08.03.2010 um 18:46 schrieb Kelly Linden:
>>>
 We are not out to write a new malloc for mono.  What we have is a system 
 that throws an exception when the memory used by the script hits a certain 
 threshold (64k currently).  This exception is caught so we can "crash" the 
 script.  The future small scripts and big scripts projects will add new 
 functions to set and get this threshold value, allowing scripters to 
 effectively control how much memory is reserved for their script.  We will 
 continue to use mono's default memory management within the reserved 
 memory thresholds.  It is a much simpler problem to solve.

>>> While your at it, how about a static analyzer for mono/LSL that determines 
>>> guaranteed lowest memory consumption for a script and sets the threshold 
>>> there.
>>>
>>> That would have the benefit of easing scripters work by providing useful 
>>> defaults for all the easy cases without them having to do anything at all.
>>>
>>> The scheme should only break down if the mono GC behaves weird. In that 
>>> case scripters have a huge problem anyway as they cannot set any threshold 
>>> without being crashed at random by a lazy GC.
>>>
>>> Michael
>>> ___
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>>> Please read the policies before posting to keep unmoderated posting 
>>> privileges
>>>
>>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

parcel and sim owners shouldn't need to ask for permission, nor objects
you own (it should not permanently change the settings, at the moment
the cause is not in range anymore (you move to a different sim, log off
or the object is derezzed) the WL settings revert to what you manually set)

On 10/3/2010 13:30, Maggie Leber (sl: Maggie Darwin) wrote:
> On Wed, Mar 10, 2010 at 11:05 AM, Opensource Obscure  
> wrote:
>> Yesterday Jopsy Pendragon submitted this feature request
>> to the public JIRA:
>>
>> llSetAgentEnvironment( key agent, [ param list ] );
>> http://jira.secondlife.com/browse/SVC-5520
> 
> As long as I'm *asked for permission* before somebody I don't know
> jams a reconfiguration into my viewer...
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuXyoUACgkQ8ZFfSrFHsmVSrQCfacucku1cnEFyGXiOjISgTznJ
u8wAnRzUvBk0B9Fa/JKiJbUWu2bTba1Q
=6zzk
-END PGP SIGNATURE-
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] [server-beta] Script Memory ManagementAlgorithm

[Lear Cale]

There's a semantic issue here that we need to clear up.

When we say how much memory a script is "actually using", that means
the amount of memory the script is making semantic usage of.  However,
the script is *allocated* a larger amount.  This larger amount is the
amount that matters to the system: it's the *cost* of the script, and
what needs to be controlled.  If someone is wearing scripts that are
allocated 1MB of space, it doesn't lower the impact on the sim that
the scripts happen to be making effective use of only a small
fraction.  That memory is still reserved for the script and can't be
used by anything else, and contributes to thrashing when
overallocated.

The metrics need to show the *burden* the scripts are placing on the
system.  It doesn't help to see that they're using that burden
inefficiently and give the wearer a break on that basis.

In other words, It's the cost that counts, not the benefit.

Lear

On Tue, Mar 9, 2010 at 1:29 PM, Kitty  wrote:
>> It might be possible to add display of memory currently used
>> as well, but what's the use case for it?
>
> It would allow residents to independently review the imposed script limits.
>
> Another use case would be because people *are* going to start banning
> residents based on what the script limits UI says (just like people are
> ejected/banned over ARC). If some random resident hasn't spent hours and
> hours trying to see if everything they've bought in the past few years
> doesn't have an update for it that uses the upcoming "llReserveMemory" they
> will end up banned from random places for wearing the wrong item.
>
> Simply reporting "actually in use" for *other* residents even though the
> individual limit is against a "hypothetical maximum limit" would do a whole
> lot to help with that. A Mono script would still count as 64Kb against that
> avie's personal limit, but anyone else trying to look for information would
> be seeing say 8Kb because that's how much it's actually using and actual
> usage is really the only thing parcel and sim owners are (or should) care
> about when it comes to other people's attachments.
>
>> Likewise, it would be useful for verifying sellers' signs'
>> claims immediately after purchase, should a scripted object
>> be displayed as a static, unscripted object. The ability to
>> see the number of prims in a linked set helps similarly for
>> advertised prim counts.
>
> It likely won't take very long for the sellers of scripted gadgets to
> include "script usage" information, but it will be many months before
> someone selling - for example - earrings with a texture change script is
> going to do the same or before they even find out that there is such a thing
> as script limits.
>
> The examples of "troublesome" cases that require script limits in the first
> place never seem to be the highly technical kind, but rather the every day
> "mundane" things like hair, shoes, jewelry, prim skirts, etc. So the people
> who are least likely to include that information, or even know that
> something like script limits exists.
>
> I already have literally hundreds of "script-in-every prim" things I've
> bought - where I can't even delete the scripts because of a change to "no
> modify" some time back - that might just be good for relocating to the trash
> 6 months from now. Moving forward, noone should find out *after* purchase
> whether or not what they just bought is something they'll be able to wear,
> or whether they'll see the dreaded "Not enough script resources available to
> attach object!" and know that they just threw money out the window.
>
> When someone picks "Buy", the script limit/usage for each individual object
> inside of the prim should really just be right there alongside the
> permissions the item will have.
> Use of green/yellow/red from ARC would make things even simpler still for
> the average resident: anything using less than 1/38th of the per-avatar
> limit (limit divded by # possible attachments) shows green, several
> multiples is yellow and anything more is red.
>
> Kitty
>
> ___
> 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] [server-beta] Script Memory ManagementAlgorithm

[Maggie Leber (sl: Maggie Darwin)]

On Wed, Mar 10, 2010 at 11:43 AM, Lear Cale  wrote:

> When we say how much memory a script is "actually using", that means
> the amount of memory the script is making semantic usage of.  However,
> the script is *allocated* a larger amount.  This larger amount is the
> amount that matters to the system: it's the *cost* of the script, and
> what needs to be controlled.

It might be more accurate to say it's the *price*, not the *cost*,
since it is what you will be charged for regardless of how much you
actually *use*.
___
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

[Maggie Leber (sl: Maggie Darwin)]

On Wed, Mar 10, 2010 at 11:36 AM, Tigro Spottystripes
 wrote:

> parcel and sim owners shouldn't need to ask for permission...

Nonsense.

If you want to reconfigure my viewer, you need my permission. Every time.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Cloud-Based Sim Hosting, Dynamic Sim Scaling, & Storage

[Jonathan Irvin]

*This one is for the Lindens*

Ok, I've heard some rumors that Linden Labs is going to move to a more
cloud-based storage system for asset management (which excites me greatly)
to reduce asset-related errors, allow easier rollback, and greater
redundancy.

What I'm interested in knowing is that if LL is going to also persue this in
terms of dynamic sim scaling, perhaps even to a point of charging per
simulator hour versus a flat rate that you have to adjust as the technology
progresses (potentially this could be a Class 6 server).  The benefits of
Cloud-based operations are intense.  I would love to see LL utilise this as
an option to have either a cheap sim, the lowest echelon of the cloud server
structure, or even scale up to larger setups if you need it for more prim
allotment or user concurrency within that region.

Do we have any plans for stuff like this?

Thanks LL!
___
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

[Lear Cale]

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?

Lear

On Tue, Mar 9, 2010 at 8:26 AM, Carlo Wood  wrote:
> This is exactly the kind of reaction that drives me away from here.
>
> I propose a simple way get FOUR times the memory for all the scripts, at
> no other cost than adding some malloc code to your mono engine.
>
> And you simply say, "This is what we ARE doing, we're not going to change 
> that".
>
> Why this immovable stubbornness about internal development decisions?
>
> In case with the below you mean to say "allowing people to set ammount
> of memory at which their scripts crash, up front, is as good," then
> read the past posts on this list again.
>
> People say that it is NOT, by FAR not, as good. Scripters shouldn't
> have to manually figure out the maximum ammount of memory their scripts
> can possibly use and use that as the fixed ammount of memory that
> their script reserves. That was last done 10 years ago. Just have the
> server take care of this: give a script a minimum, and when it needs
> more, give it more. No hassle for the users.
>
> On Mon, Mar 08, 2010 at 09:46:44AM -0800, Kelly Linden wrote:
>> We are not out to write a new malloc for mono.  What we have is a system that
>> throws an exception when the memory used by the script hits a certain 
>> threshold
>> (64k currently).  This exception is caught so we can "crash" the script.  The
>> future small scripts and big scripts projects will add new functions to set 
>> and
>> get this threshold value, allowing scripters to effectively control how much
>> memory is reserved for their script.  We will continue to use mono's default
>> memory management within the reserved memory thresholds.  It is a much 
>> simpler
>> problem to solve.
>>
>>  - Kelly
>>
>> On Sun, Mar 7, 2010 at 5:50 AM, Carlo Wood  wrote:
>>
>>     Lets assume that the *average* script uses
>>     8 to 16 kB of real memory. LL's design allocates
>>     64 kB regardless, leading to an overhead of
>>     400 to 800% (meaning they need to buy 5 to
>>     9 times the memory that is theoretically needed).
>>
>>     In that light, I gave it some more thought, and
>>     think something as complex as my rmalloc's algorithm,
>>     with it's 19% overhead, isn't needed (note that
>>     it's both faster than gmalloc as well as three
>>     times more efficient; so complexity is not always
>>     a bad thing ;).
>>
>>     Nevertheless, in this case, since the scripts
>>     use a maximum of 64 kB, you can use the
>>     following design:
>>
>>     Let each allocated block be a power of 2
>>     kilobytes, with a maximum of 64 kB (and a
>>     minimum of 1 KB, or 4 if even the tiniest
>>     script needs that).
>>
>>     It is easy to see that this would lead
>>     to an overhead of 25% on average per
>>     allocated block.
>>
>>     We'd still have to deal with "holes" of a
>>     full 64 kB where blocks became totally
>>     unused, but normally scripts in objects are
>>     started all at once when a sim reboots, and
>>     only seldom stopped. The scripts that will
>>     most likely attribute to random starting
>>     and stopping of scripts will be the scripts
>>     in attachments. A worst case scenario would
>>     be one where there are 50 avies in a sim
>>     (during a meeting), then a new avie enters
>>     with some scripts which need to be allocated
>>     at the top of the heap; then the previous
>>     50 avies leave. That would create a hole
>>     in the heap of the size of all the scripts
>>     of those 50 avies. If script memory would
>>     be relocatable, then this problem doesn't
>>     exist of course. I can't simply estimate
>>     the average overhead caused by this, but
>>     because the algorithm described here is
>>     basically the one used by gmalloc (which
>>     in my test used 62% overhead) I'm pretty
>>     sure that it will be less than -say- 100%
>>     overhead; still 4 to 8 times more efficient
>>     than the current design on the table.
>>
>>     The API for this design would be something
>>     like the following:
>>
>>     namespace script_memory_management {
>>
>>     void* ll_sbrk(ptrdiff_t);       // Increment the size of the heap
>>     int   ll_brk(void*);            // Set the size of the heap explicitely
>>
>>     void* ll_malloc64(void);        // Get a new 64 kB block.
>>     void  ll_free64(void*);         // Free such a block.
>>
>>     void* ll_

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

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

sim owners can already control the Sun position in your client, the rest
of the WL parameters is just an extensions of that

there should be a way to set your client to ifnore sim settings if you
want to though

On 10/3/2010 13:47, Maggie Leber (sl: Maggie Darwin) wrote:
> On Wed, Mar 10, 2010 at 11:36 AM, Tigro Spottystripes
>  wrote:
> 
>> parcel and sim owners shouldn't need to ask for permission...
> 
> Nonsense.
> 
> If you want to reconfigure my viewer, you need my permission. Every time.
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuX0M0ACgkQ8ZFfSrFHsmVSNQCeMRS9L146LU0c73u58mmiv1ag
sV4An0Kc5Jda7OU7tL3/1mn2FprHXZOO
=x1Xa
-END PGP SIGNATURE-
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Cloud-Based Sim Hosting, Dynamic Sim Scaling, & Storage

[Soft Linden]

Hey, Jonathan. This list is for open source discussions. This list
would be more appropriate for simulator questions:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/server-beta

On Wed, Mar 10, 2010 at 8:54 AM, Jonathan Irvin  wrote:
> This one is for the Lindens
>
> Ok, I've heard some rumors that Linden Labs is going to move to a more
> cloud-based storage system for asset management (which excites me greatly)
...
___
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 ManagementAlgorithm

[Lear Cale]

Which is what we mean by "cost".  Price is what you are asked to pay.
Cost is what you actually pay.  Thus the phrase "cost/benefit
analysis" -- not "price/benefit analysis".

On Wed, Mar 10, 2010 at 11:46 AM, Maggie Leber (sl: Maggie Darwin)
 wrote:
> On Wed, Mar 10, 2010 at 11:43 AM, Lear Cale  wrote:
>
>> When we say how much memory a script is "actually using", that means
>> the amount of memory the script is making semantic usage of.  However,
>> the script is *allocated* a larger amount.  This larger amount is the
>> amount that matters to the system: it's the *cost* of the script, and
>> what needs to be controlled.
>
> It might be more accurate to say it's the *price*, not the *cost*,
> since it is what you will be charged for regardless of how much you
> actually *use*.
>
___
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

[Marine Kelley]

The RLV does just that, force your viewer Windlight settings with an object
that you own.


On 10 March 2010 18:03, Tigro Spottystripes wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> sim owners can already control the Sun position in your client, the rest
> of the WL parameters is just an extensions of that
>
> there should be a way to set your client to ifnore sim settings if you
> want to though
>
> On 10/3/2010 13:47, Maggie Leber (sl: Maggie Darwin) wrote:
> > On Wed, Mar 10, 2010 at 11:36 AM, Tigro Spottystripes
> >  wrote:
> >
> >> parcel and sim owners shouldn't need to ask for permission...
> >
> > Nonsense.
> >
> > If you want to reconfigure my viewer, you need my permission. Every time.
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.12 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuX0M0ACgkQ8ZFfSrFHsmVSNQCeMRS9L146LU0c73u58mmiv1ag
> sV4An0Kc5Jda7OU7tL3/1mn2FprHXZOO
> =x1Xa
> -END PGP SIGNATURE-
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Maggie Leber (sl: Maggie Darwin)]

On Wed, Mar 10, 2010 at 12:03 PM, Tigro Spottystripes
 wrote:
> sim owners can already control the Sun position in your client, the rest
> of the WL parameters is just an extensions of that

That's a pretty feeble application of a slippery slope argument.

> there should be a way to set your client to ifnore sim settings if you
> want to though

There is: it's called declining to grant permission for you to shove
your settings down the throat of my viewer.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Maggie Leber (sl: Maggie Darwin)]

On Wed, Mar 10, 2010 at 12:14 PM, Marine Kelley  wrote:
> The RLV does just that, force your viewer Windlight settings with an object
> that you own.

And that's consensual. What Tigro's talking about isn't. He wants you
to have to opt-out of his mandatory viewer configuration.
___
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

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

i know, but i think that it would be better if the client itself worked
like what i described, without the need of third party additions

On 10/3/2010 14:14, Marine Kelley wrote:
> The RLV does just that, force your viewer Windlight settings with an
> object that you own.
> 
> 
> On 10 March 2010 18:03, Tigro Spottystripes
> mailto:tigrospottystri...@gmail.com>> wrote:
> 
> sim owners can already control the Sun position in your client, the rest
> of the WL parameters is just an extensions of that
> 
> there should be a way to set your client to ifnore sim settings if you
> want to though
> 
> On 10/3/2010 13:47, Maggie Leber (sl: Maggie Darwin) wrote:
>> On Wed, Mar 10, 2010 at 11:36 AM, Tigro Spottystripes
>>  > wrote:
> 
>>> parcel and sim owners shouldn't need to ask for permission...
> 
>> Nonsense.
> 
>> If you want to reconfigure my viewer, you need my permission.
> Every time.
> 
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting
privileges

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuX1OkACgkQ8ZFfSrFHsmUKfACgjQhcK2MZeG9WB1PqhTM/Yf87
EiEAn0KYIgEscYulkhxaC6ULT6N+3Pzy
=fnuz
-END PGP SIGNATURE-
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

it would only be opt-out if the setting to accept sim/parcel environment
is enabled by default, otherwise it would be optin

On 10/3/2010 14:19, Maggie Leber (sl: Maggie Darwin) wrote:
> On Wed, Mar 10, 2010 at 12:14 PM, Marine Kelley  
> wrote:
>> The RLV does just that, force your viewer Windlight settings with an object
>> that you own.
> 
> And that's consensual. What Tigro's talking about isn't. He wants you
> to have to opt-out of his mandatory viewer configuration.
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuX1UsACgkQ8ZFfSrFHsmWO6gCfU8Sv0KlZXT00cI/zd/7TzB+w
DAoAn1lBsZ9V2o0vM7z6WYSfLAQl+LXF
=l5Ub
-END PGP SIGNATURE-
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Maggie Leber (sl: Maggie Darwin)]

On Wed, Mar 10, 2010 at 12:20 PM, Tigro Spottystripes
 wrote:
> i know, but i think that it would be better if the client itself worked
> like what i described, without the need of third party additions

I think it would be better if you'd leave my viewer the heck alone
unless you've been given permission to monkey with it.
___
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

[Latif Khalifa]

On Wed, Mar 10, 2010 at 6:18 PM, Maggie Leber (sl: Maggie Darwin)
 wrote:
> On Wed, Mar 10, 2010 at 12:03 PM, Tigro Spottystripes
>  wrote:
>> sim owners can already control the Sun position in your client, the rest
>> of the WL parameters is just an extensions of that
>
> That's a pretty feeble application of a slippery slope argument.
>
>> there should be a way to set your client to ifnore sim settings if you
>> want to though
>
> There is: it's called declining to grant permission for you to shove
> your settings down the throat of my viewer.

You can already override environmental settings. Option to set to
region default should do just that, apply region default settings.
Nobody is showing anything down your throat lol.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Kelly Linden]

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

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

 - Kelly

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

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

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

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

[Maggie Leber (sl: Maggie Darwin)]

On Wed, Mar 10, 2010 at 12:23 PM, Latif Khalifa  wrote:

> You can already override environmental settings. Option to set to
> region default should do just that, apply region default settings.
> Nobody is showing anything down your throat lol.

So it wouldn't take effect if I'm not running the Windlight "default" set?

That's not currently a "region default", by the way. Notice that
"Revert to region default" applies only to sun position.
___
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

[Maggie Leber (sl: Maggie Darwin)]

On Wed, Mar 10, 2010 at 12:29 PM, Kelly Linden  wrote:
> Windlight settings should be a part of the build and not something
> you have to opt into or be bugged with a dialog to see.*

Well, then how about automatic applications of animations to your
avatar, because a "content creator" thought it would be arty or cool?
Or malicious Windlight settings that blind you, because it's
"artistic" and "part of the shared experience"?

The enhancement request as it stands calls for a permissions opt-in
for having your viewer settings changed, and I support it in that
form.
___
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

[Latif Khalifa]

On Wed, Mar 10, 2010 at 6:30 PM, Maggie Leber (sl: Maggie Darwin)
 wrote:
> On Wed, Mar 10, 2010 at 12:23 PM, Latif Khalifa  
> wrote:
>
>> You can already override environmental settings. Option to set to
>> region default should do just that, apply region default settings.
>> Nobody is showing anything down your throat lol.
>
> So it wouldn't take effect if I'm not running the Windlight "default" set?
>
> That's not currently a "region default", by the way. Notice that
> "Revert to region default" applies only to sun position.

I'm talking about implementation of
http://jira.secondlife.com/browse/VWR-7677 not the LSL script setting
environment. Yes, the region setting would be shown by default,
because otherwise it wouldn't make any sense. Asking for permissions
for stuff like setting light and sky settings makes as much sense as
asking for permission to show a house in your viewer once you have
entered a region.
___
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

[Erik Anderson]

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

> On Wed, Mar 10, 2010 at 12:29 PM, Kelly Linden 
> wrote:
> > Windlight settings should be a part of the build and not something
> > you have to opt into or be bugged with a dialog to see.*
>
> Well, then how about automatic applications of animations to your
> avatar, because a "content creator" thought it would be arty or cool?
> Or malicious Windlight settings that blind you, because it's
> "artistic" and "part of the shared experience"?
>
> The enhancement request as it stands calls for a permissions opt-in
> for having your viewer settings changed, and I support it in that
> form.
>

A little scared to jump into this rather heated discussion, but...

The environmental settings are only there to affect what the client sees (as
far as I know), not affect how anyone else sees the avatar.  So this is a
little different than "opt-out animations".  A closer analogy would be
whether the user would be required to opt into seeing particle effects by
one object or another.  This can and has been done maliciously - tons of
particle bombs are out there that pretty much prevent you from seeing
anything on the screen while they have an effect.  Requiring opt-in would
render bling pretty much useless though...

However, you can leave the area, and (if you know where the switch is) you
can turn them off.  I'm hoping that these scripted environmental effects
would be a little easier to turn off than particle effects however...
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Kelly Linden]

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

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

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


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

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

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

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

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

Re: [opensource-dev] Backport of Tattoo and Alpha support to v1.23 ?

[Lillian Yiyuan]

Also most bald hair bases use an alpha texture.

On Wed, Mar 10, 2010 at 6:54 AM, Lance Corrimal
 wrote:
> Am Mittwoch, 10. März 2010 15:29:01 schrieb Glen Canaday:
>> On the bright side - anyone making tattoos and understanding the alpha
>> mask isn't wearing system hair... 
>
> 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.
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Latif Khalifa]

On Wed, Mar 10, 2010 at 6:42 PM, Kelly Linden  wrote:
> I do believe the
> environment should be promoted to being part of the content and not part of
> the viewer, I think we get more amazing in world experiences that way.

I fully agree. One of the often heard remarks that I hear from users
is how despite how big Second Life is, it's pretty uniform in the way
it looks all over the place. I think implementing region windlight
setting would give us much more varied experience and some truly
awesome builds no doubt. The sad part is that when windlight was
introduced, all the hard work was done in the viewer, and region
setting were said to be coming soon. Compared to what had to be done
to introduce windlight, adding the ability to store it persistently in
regions settings should be trivial.
___
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

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

IMO the 2.0 interface looks way more like a "developer's interface" than
1.*'s

On 10/3/2010 14:42, Kelly Linden wrote:
> On Wed, Mar 10, 2010 at 9:34 AM, Maggie Leber (sl: Maggie Darwin) <
> mag...@matrisync.com> wrote:
> 
>> On Wed, Mar 10, 2010 at 12:29 PM, Kelly Linden 
>> wrote:
>>> Windlight settings should be a part of the build and not something
>>> you have to opt into or be bugged with a dialog to see.*
>>
>> Well, then how about automatic applications of animations to your
>> avatar, because a "content creator" thought it would be arty or cool?
>>
> 
> Welcome to the other nightmare I'm dealing with for server 1.38.  Ultimately
> there is a difference between affecting the personification of *you* by
> animating you or taking your controls or your camera hostage and changing
> how the world you are in looks.
> 
> 
>> Or malicious Windlight settings that blind you, because it's
>> "artistic" and "part of the shared experience"?
>>
> 
> I've been banned from viewer UI design, for good reason.  I end up with
> developer UI, and with 2.0 they managed to scrub the last remnants of my UI
> from SL.  That aside, I could see 'reset the damn sky' as a top level action
> similar to 'stand' - a button on screen above the bottom bar maybe.  And a
> good keyboard shortcut.  Yes, it should be possible for a blinding sky to be
> part of an artistic shared experience, and it should be easy to get out of.
>  And yeah, some advanced option for 'don't let my windlight settings change'
> seems like a good idea also.  But the default should be for the windlight
> environment to be part of the content you are visiting.
> 
>>
>> The enhancement request as it stands calls for a permissions opt-in
>> for having your viewer settings changed, and I support it in that
>> form.
>>
> 
> I admit I only briefly skimmed the jira.  I was mostly reacting to the panic
> I saw here.  I don't think it needs a permission request in the case of
> parcel  owners, but that is just my personal opinion. I do believe the
> environment should be promoted to being part of the content and not part of
> the viewer, I think we get more amazing in world experiences that way.
> 
>  - Kelly
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuX22sACgkQ8ZFfSrFHsmXs/ACghovGVkFbLcJARpFywLiBD9m2
aecAn2OGHi9LiqaoqGPClI+YGS9Xq0R8
=ARH9
-END PGP SIGNATURE-
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Maggie Leber (sl: Maggie Darwin)]

> That aside, I could see 'reset the damn sky' as a top level action

It's more than "sky and water". It's also the optical properties of
the air around you, among other things.

If everybody was on Emerald, where Windlight settings and draw
distance are easy to tweak with a control that pops out of the button
bar, I'd be less concerned. (Why I need to ride herd on the draw
distance to get acceptable rendering performance is another
discussion, if you're itching to automate something. )

But in Viewer 2 they're just as buried as they are on 1.23. Under a
World menu called "Sun", of all things.

*How many users know how to change
them NOW?*

If it was easier to do, would you even be lobbying to make them
automatic under the control of the parcel owner?

> 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.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Kelly Linden]

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

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

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

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

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

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

[Maggie Leber (sl: Maggie Darwin)]

On Wed, Mar 10, 2010 at 12:57 PM, Kelly Linden  wrote:

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

Well, none of the "official" viewers do that, so we can wait until they do.

I'm sure the Emerald folks would be delighted to see you implement
their changes in this area. I know I would.
___
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

[Maggie Leber (sl: Maggie Darwin)]

On Wed, Mar 10, 2010 at 12:57 PM, Kelly Linden  wrote:

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

Well, get over it; software design on this scale should not be done
breathlessly.

I can just imagine a new use for all those tiny little ex-adfarm
parcels along mainland roads: noob traps that force a blinding
Windlight set on the unwary.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Standalone indra.y and indra.l

[Brandon Husbands]

Does anyone have a standalone version of the lexer and parser?
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] New topic: Snowglobe 2.0 way forward?

[Argent Stonecutter]

On 2010-03-10, at 11:48, Tigro Spottystripes wrote:
> IMO the 2.0 interface looks way more like a "developer's interface"  
> than 1.*'s

Which brings this thread back onto topic for this list. :)

I agree. The browser has become a familiar interface, but it was  
largely developed by developers for developers, and for an application  
things like the address bar and bookmarks and sidebars are distracting  
and divert attention from the content (the page you're viewing, or the  
world your avatar is in). Which is why web applications are allowed to  
remove those decorations when creating a new window.

The 2.0 interface looks like something a web developer would like to  
use, not something someone IN SL needs. The address bar, toolbar, side  
panel, and all the new highly decorated chat boxes and message boxes  
should at the very least be made optional.

Where is Snowglobe 2.0 going with this? Where SHOUDL it go? Should it  
simplify the interface (or allow it to be simplified), restoring the  
sim name and location to the title bar, cleaning up the chat and  
message boxes, and so on?
___
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

[Latif Khalifa]

On Wed, Mar 10, 2010 at 7:05 PM, Maggie Leber (sl: Maggie Darwin)
 wrote:
> I can just imagine a new use for all those tiny little ex-adfarm
> parcels along mainland roads: noob traps that force a blinding
> Windlight set on the unwary.

Don't let what the actual "Estate / Sim Windlight preset / day cycle
options" VWR-7677 proposal says stay in way of you inventing fictional
problems.
___
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] New topic: Snowglobe 2.0 way forward?

[Mike Monkowski]

Except for Merov's contributions, I don't think Snowglobe ever had a 
planned direction.  The direction was just the sum of the contributions 
people made to it.  And I expect it will continue that way.  If someone 
thinks that chat needs to be fixed and they have the time to fix it, 
then they probably will.  The real question is whether such a 
contribution would be accepted.  I happen to think it would be dangerous 
to reject such a contribution.

Mike

Argent Stonecutter wrote:
> Where is Snowglobe 2.0 going with this? Where SHOUDL it go? Should it  
> simplify the interface (or allow it to be simplified), restoring the  
> sim name and location to the title bar, cleaning up the chat and  
> message boxes, and so on?
___
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] New topic: Snowglobe 2.0 way forward?

[lufpleh]

Would like to know what's the status of the translation feature in
Snowglobe.
Was that project completed, is it going to be imported to the main viewer?
Would it be possible to extend it to translate IM or was that idea rejected?

On 10 March 2010 18:20, Mike Monkowski  wrote:

> Except for Merov's contributions, I don't think Snowglobe ever had a
> planned direction.  The direction was just the sum of the contributions
> people made to it.  And I expect it will continue that way.  If someone
> thinks that chat needs to be fixed and they have the time to fix it,
> then they probably will.  The real question is whether such a
> contribution would be accepted.  I happen to think it would be dangerous
> to reject such a contribution.
>
> Mike
>
> Argent Stonecutter wrote:
> > Where is Snowglobe 2.0 going with this? Where SHOUDL it go? Should it
> > simplify the interface (or allow it to be simplified), restoring the
> > sim name and location to the title bar, cleaning up the chat and
> > message boxes, and so on?
> ___
> 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] New topic: Snowglobe 2.0 way forward?

[Ron Festa]

I agree, the new UI needs a LOT of work before I consider it mainstream
worthy. As was said the old UI was pretty much tailored by developers for
developers. This new UI seems to be tailored in the opposite direction
making the viewer barely usable for those of us accustomed to the old UI and
content developers. The tweaks found at
http://wiki.secondlife.com/wiki/Viewer_2_Tweaks definitely improve things,
but we really need a middle ground for end users and developers instead of a
UI tailored for either extreme.

Ron Festa
Virtual Worlds Admin
Division of Continuing Studies at Rutgers University
PGP key: http://bit.ly/b1ZyhY
Phone: 732-474-8583


On Wed, Mar 10, 2010 at 1:20 PM, Mike Monkowski
wrote:

> Except for Merov's contributions, I don't think Snowglobe ever had a
> planned direction.  The direction was just the sum of the contributions
> people made to it.  And I expect it will continue that way.  If someone
> thinks that chat needs to be fixed and they have the time to fix it,
> then they probably will.  The real question is whether such a
> contribution would be accepted.  I happen to think it would be dangerous
> to reject such a contribution.
>
> Mike
>
> Argent Stonecutter wrote:
> > Where is Snowglobe 2.0 going with this? Where SHOUDL it go? Should it
> > simplify the interface (or allow it to be simplified), restoring the
> > sim name and location to the title bar, cleaning up the chat and
> > message boxes, and so on?
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Maggie Leber (sl: Maggie Darwin)]

On Wed, Mar 10, 2010 at 1:17 PM, Latif Khalifa  wrote:

> Don't let what the actual "Estate / Sim Windlight preset / day cycle
> options" VWR-7677 proposal says stay in way of you inventing fictional
> problems.

The *actual* discussion was about SVC-5520.

If you'd really like to hijack it, I suppose you could always close it
as a dupe, that would be fun.
___
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] New topic: Snowglobe 2.0 way forward?

[Tori C.]

On Wed, Mar 10, 2010 at 1:26 PM, lufpleh  wrote:
> Would like to know what's the status of the translation feature in
> Snowglobe.
> Was that project completed, is it going to be imported to the main viewer?
> Would it be possible to extend it to translate IM or was that idea rejected?

It could use a little more polish. Translations need a different color
or something to distinguish them from the original chat, parens aren't
doing the job. That one just caused some confusion on the scripters
list. Error reporting could possibly be a little clearer, the "(?)"
dummy translation in there now is a little mysterious for the end
user. It wouldn't hurt to have a small cache, even a few lines, to
avoid repetitive lookups in spammy situations. One last thing I
noticed is that chat often gets "JRandom Avatar: lol (lol)" - maybe
the translation could be dropped if the same text comes out the other
end?
___
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 ManagementAlgorithm

[Maggie Leber (sl: Maggie Darwin)]

On Wed, Mar 10, 2010 at 12:06 PM, Lear Cale  wrote:
> Which is what we mean by "cost".  Price is what you are asked to pay.
> Cost is what you actually pay.

When discussing performance, "cost" would refer to what actually
impacts performance, as in "an expensive calculation".

Here the script memory quota is what you will be charged for (price)
in exchange the right to potentially cause a real performance cost to
the server  (and thus to Linden Research).

Since Linden Research is unable to predetermine the actual cost of
running your scripts, you are charged for what you might possibly do,
because stopping you when you "do too much" would be insanely
disruptive.

More so than what's proposed, anyway.

The price of the "all you can eat" meal when "all you CAN eat" is
based on your land ownership...I see a future in which hordes of bot
avatars are created to use their (free) script memory quotas to run
LSL servers, something like getting "free" prims by using a temp
rezzer.
___
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] New topic: Snowglobe 2.0 way forward?

[Brandon Husbands]

I have been polishing it up quite a bit with the toxicviewer...
Reverting things like the camera floater etc... Next is making the things in
the side bat detachable.

On Wed, Mar 10, 2010 at 12:50 PM, Tori C.  wrote:

> On Wed, Mar 10, 2010 at 1:26 PM, lufpleh  wrote:
> > Would like to know what's the status of the translation feature in
> > Snowglobe.
> > Was that project completed, is it going to be imported to the main
> viewer?
> > Would it be possible to extend it to translate IM or was that idea
> rejected?
>
> It could use a little more polish. Translations need a different color
> or something to distinguish them from the original chat, parens aren't
> doing the job. That one just caused some confusion on the scripters
> list. Error reporting could possibly be a little clearer, the "(?)"
> dummy translation in there now is a little mysterious for the end
> user. It wouldn't hurt to have a small cache, even a few lines, to
> avoid repetitive lookups in spammy situations. One last thing I
> noticed is that chat often gets "JRandom Avatar: lol (lol)" - maybe
> the translation could be dropped if the same text comes out the other
> end?
> ___
> 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
>



-- 
---
This email is a private and confidential communication. Any use of email may
be subject to the laws and regulations of the United States. You may not
Repost, Distribute nor reproduce any content of this message.
---
---
___
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] New topic: Snowglobe 2.0 way forward?

[Argent Stonecutter]

On 2010-03-10, at 12:28, Ron Festa wrote:
> I agree, the new UI needs a LOT of work before I consider it  
> mainstream worthy. As was said the old UI was pretty much tailored  
> by developers for developers.

That's not quite what I said... I said that the web browser was  
tailored by developers for developers, and the *new* UI was styled  
after it.

The old UI was designed to promote the content of the world... second  
life itself. The new UI is designed to frame the content of the world  
with something like a browser. It's designed to make web developers  
comfortable.
___
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

[Opensource Obscure]

On Wed, 10 Mar 2010 12:53:26 -0500, "Maggie Leber (sl: Maggie Darwin) "
 wrote:
> in Viewer 2 they're just as buried as they are on 1.23. Under a
> World menu called "Sun", of all things.
> 
> *How many users know how to change
> them NOW?*
> 
> If it was easier to do, would you even be lobbying to make them
> automatic under the control of the parcel owner?

I agree that their current location is an issue. (1)

At the same time, if parcel owners got more control, I'd need
to use sky settings controls much less. Finding a decent / good
lighting setting for any place would be easier and quicker;
and better, because good content builders would also choose
the appropriate light settings.

So I see two separate issues here: 
1. the UI one is about usability - it looks like an easy fix, that 
may be solved the same way as 'Gestures', 'Camera' controls 
got implented in the bottom bar (e.g., you can hide them);
2. the parcel/estate owner controls, that I see as a needed
sort of 'content experience' improvement.

(1) 
as a workaround, here's an easy XML patch for those who 
often tweak sky settings - as said, it's a workaround, 
not a solution.
https://wiki.secondlife.com/wiki/User:Opensource_Obscure/Panel_Navigation_Bar

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] New topic: Snowglobe 2.0 way forward?

[Nexii Malthus]

I do web developing and disagee, strongly.

- Nexii

On Wed, Mar 10, 2010 at 7:07 PM, Argent Stonecutter  wrote:

> On 2010-03-10, at 12:28, Ron Festa wrote:
> > I agree, the new UI needs a LOT of work before I consider it
> > mainstream worthy. As was said the old UI was pretty much tailored
> > by developers for developers.
>
> That's not quite what I said... I said that the web browser was
> tailored by developers for developers, and the *new* UI was styled
> after it.
>
> The old UI was designed to promote the content of the world... second
> life itself. The new UI is designed to frame the content of the world
> with something like a browser. It's designed to make web developers
> comfortable.
> ___
> 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] New topic: Snowglobe 2.0 way forward?

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The new interface breaks immersion, it places the world as just another
small area of the screen with a bunch of other things outside of it.

On 10/3/2010 15:13, Argent Stonecutter wrote:
> On 2010-03-10, at 11:48, Tigro Spottystripes wrote:
>> IMO the 2.0 interface looks way more like a "developer's interface"
>> than 1.*'s
> 
> Which brings this thread back onto topic for this list. :)
> 
> I agree. The browser has become a familiar interface, but it was largely
> developed by developers for developers, and for an application things
> like the address bar and bookmarks and sidebars are distracting and
> divert attention from the content (the page you're viewing, or the world
> your avatar is in). Which is why web applications are allowed to remove
> those decorations when creating a new window.
> 
> The 2.0 interface looks like something a web developer would like to
> use, not something someone IN SL needs. The address bar, toolbar, side
> panel, and all the new highly decorated chat boxes and message boxes
> should at the very least be made optional.
> 
> Where is Snowglobe 2.0 going with this? Where SHOUDL it go? Should it
> simplify the interface (or allow it to be simplified), restoring the sim
> name and location to the title bar, cleaning up the chat and message
> boxes, and so on?
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuX/boACgkQ8ZFfSrFHsmWBbACeMaJR0Sd3PSQxvr+PFsSIuws5
19UAn2a5d5wIXJpdkQC0+wVHYz9V00Gi
=aMlN
-END PGP SIGNATURE-
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Backport of Tattoo and Alpha support to v1.23 ?

[Glen Canaday]

The scripter's list has no sense of humor, either.

On 03/10/2010 09:54 AM, Lance Corrimal wrote:
> Am Mittwoch, 10. März 2010 15:29:01 schrieb Glen Canaday:
>
>> On the bright side - anyone making tattoos and understanding the alpha
>> mask isn't wearing system hair...
>>  
> 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.
> ___
> 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] Backport of Tattoo and Alpha support to v1.23 ?

[Maya Remblai]

> Also most bald hair bases use an alpha texture.
>   
Not really relevant here, but true.
>>> On the bright side - anyone making tattoos and understanding the alpha
>>> mask isn't wearing system hair... 
Or system eyes in most cases. :P

>>> 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.
>>>   
This is true, but easily dealt with, if I'm understanding things 
correctly (I haven't had time to try the patch myself): Just make a 
throwaway set of hair/eyes/skin/whatever's getting corrupted, and switch 
to something else when you're done editing. Of course that's assuming 
that the cloud-ruthing isn't permanent.

Regardless, I'm excited to see effort being put into this. I can't use 
2.0 in its current state, and even with all the tweaks in place its new, 
longer methods of doing things is detrimental to my work. So I'm glad 
someone's working on backporting, and I know many other content creators 
that will be similarly pleased. :)

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

[opensource-dev] Fwd: New topic: Snowglobe 2.0 way forward?

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

(just bouncing back to the list)

-  Original Message 
Subject: Re: [opensource-dev] New topic: Snowglobe 2.0 way forward?
Date: Wed, 10 Mar 2010 15:37:58 -0500
From: Robert Martin 
To: Tigro Spottystripes 

On thing that needs to be done is the different tabs from the sidebar
need to be converted to normal floaters and some way to disable the
sidebar needs to be developed.

Does anybody not already "invested" in the sidebar not think that it
is only useful when you have a video wall screen (like from the CSI:NY
episode "down the rabbit hole").
- -- 
Robert L Martin

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuYB0AACgkQ8ZFfSrFHsmXufgCfW6V4o+dSfoWh0UeYTvsI1+qD
2PAAnjc2Npp0FziuUNJR4nALIW3vuoCX
=Roso
-END PGP SIGNATURE-
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New topic: Snowglobe 2.0 way forward?

[Glen Canaday]

That's exactly the problem, really.

In order to more properly determine what has to be done, there first has 
to be a way of *defining* what helps immersion and what doesn't.

Popping out a sidebar that covers and shifts the world over definitely 
breaks it. In what ways will it be possible to keep the concept, since 
some in LL are obviously absolutely glued to it (Q that's you) while 
still removiing its detrimental effect on the user experience?

The chat bar's focus is also terrible. Only those who use wasdf to move 
can use it as it is... generally if my mouse focus in inworld, I want 
the keyboard focus (minus arrow keys) to be on the chat bar, as it has 
always been.

--GC

On 03/10/2010 03:14 PM, Tigro Spottystripes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> The new interface breaks immersion, it places the world as just another
> small area of the screen with a bunch of other things outside of it.
>
> On 10/3/2010 15:13, Argent Stonecutter wrote:
>
>> On 2010-03-10, at 11:48, Tigro Spottystripes wrote:
>>  
>>> IMO the 2.0 interface looks way more like a "developer's interface"
>>> than 1.*'s
>>>
>> Which brings this thread back onto topic for this list. :)
>>
>> I agree. The browser has become a familiar interface, but it was largely
>> developed by developers for developers, and for an application things
>> like the address bar and bookmarks and sidebars are distracting and
>> divert attention from the content (the page you're viewing, or the world
>> your avatar is in). Which is why web applications are allowed to remove
>> those decorations when creating a new window.
>>
>> The 2.0 interface looks like something a web developer would like to
>> use, not something someone IN SL needs. The address bar, toolbar, side
>> panel, and all the new highly decorated chat boxes and message boxes
>> should at the very least be made optional.
>>
>> Where is Snowglobe 2.0 going with this? Where SHOUDL it go? Should it
>> simplify the interface (or allow it to be simplified), restoring the sim
>> name and location to the title bar, cleaning up the chat and message
>> boxes, and so on?
>>
>>  
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.12 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuX/boACgkQ8ZFfSrFHsmWBbACeMaJR0Sd3PSQxvr+PFsSIuws5
> 19UAn2a5d5wIXJpdkQC0+wVHYz9V00Gi
> =aMlN
> -END PGP SIGNATURE-
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>

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

Re: [opensource-dev] New topic: Snowglobe 2.0 way forward?

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

IMO, windows that are on top of the view like a Heads Up Display feel
more like they're part of the world, like they are in the same place as
i am, while a bar that makes the world view smaller makes it feel like
the world view is just a screen showing images on a panel with a bunch
of controls in it.

On 10/3/2010 18:00, Glen Canaday wrote:
> 
> That's exactly the problem, really.
> 
> In order to more properly determine what has to be done, there first has 
> to be a way of *defining* what helps immersion and what doesn't.
> 
> Popping out a sidebar that covers and shifts the world over definitely 
> breaks it. In what ways will it be possible to keep the concept, since 
> some in LL are obviously absolutely glued to it (Q that's you) while 
> still removiing its detrimental effect on the user experience?
> 
> The chat bar's focus is also terrible. Only those who use wasdf to move 
> can use it as it is... generally if my mouse focus in inworld, I want 
> the keyboard focus (minus arrow keys) to be on the chat bar, as it has 
> always been.
> 
> --GC
> 
> On 03/10/2010 03:14 PM, Tigro Spottystripes wrote:
> The new interface breaks immersion, it places the world as just another
> small area of the screen with a bunch of other things outside of it.
> 
> On 10/3/2010 15:13, Argent Stonecutter wrote:
>
 On 2010-03-10, at 11:48, Tigro Spottystripes wrote:
  
> IMO the 2.0 interface looks way more like a "developer's interface"
> than 1.*'s
>
 Which brings this thread back onto topic for this list. :)

 I agree. The browser has become a familiar interface, but it was largely
 developed by developers for developers, and for an application things
 like the address bar and bookmarks and sidebars are distracting and
 divert attention from the content (the page you're viewing, or the world
 your avatar is in). Which is why web applications are allowed to remove
 those decorations when creating a new window.

 The 2.0 interface looks like something a web developer would like to
 use, not something someone IN SL needs. The address bar, toolbar, side
 panel, and all the new highly decorated chat boxes and message boxes
 should at the very least be made optional.

 Where is Snowglobe 2.0 going with this? Where SHOUDL it go? Should it
 simplify the interface (or allow it to be simplified), restoring the sim
 name and location to the title bar, cleaning up the chat and message
 boxes, and so on?

  
___
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

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuYEKIACgkQ8ZFfSrFHsmW5fACfdGINbmfxPapVyZQpTTpwwXQ8
DUAAn0Q3V5pEb8T8xDeX1s2zk2CrHPny
=tS6D
-END PGP SIGNATURE-
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Standalone indra.y and indra.l

[Gareth Nelson]

Contact Enki Hax inworld and ask him about the LSL compiler he worked
on for litesim, if he's still got a copy of it then point him to this
email and say he's clear to release it

On Wed, Mar 10, 2010 at 6:08 PM, Brandon Husbands  wrote:
> Does anyone have a standalone version of the lexer and parser?
>
> ___
> 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
>



-- 
“Lanie, I’m going to print more printers. Lots more printers. One for
everyone. That’s worth going to jail for. That’s worth anything.” -
Printcrime by Cory Doctrow

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
___
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] New topic: Snowglobe 2.0 way forward?

[Martin Spernau]

Am 10.03.2010 um 22:35 schrieb Tigro Spottystripes:
> IMO, windows that are on top of the view like a Heads Up Display feel
> more like they're part of the world, like they are in the same place  
> as
> i am, while a bar that makes the world view smaller makes it feel like
> the world view is just a screen showing images on a panel with a bunch
> of controls in it.

It's interesting then that many of the alternate metaverse viewers try  
to fully decouple the UI (chat boxes, imventory etc) completly from  
the world view window to the point where they are separate windows  
(while the Sl viewer still has it 'all in one wndow').
Seen with this view of 'immersion' that seem like not so good an idea...
Thanks for bringing this up, it got me thinking about a few concepts I  
had.

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

Re: [opensource-dev] New topic: Snowglobe 2.0 way forward?

[Ron Festa]

To be honest the MonoVida does it right. If you're gonna detach the UI from
the world it should be completely detached not just over lapping the world.

Ron Festa
Virtual Worlds Admin
Division of Continuing Studies at Rutgers University
PGP key: http://bit.ly/b1ZyhY
Phone: 732-474-8583


On Wed, Mar 10, 2010 at 4:47 PM, Martin Spernau  wrote:

> Am 10.03.2010 um 22:35 schrieb Tigro Spottystripes:
> > IMO, windows that are on top of the view like a Heads Up Display feel
> > more like they're part of the world, like they are in the same place
> > as
> > i am, while a bar that makes the world view smaller makes it feel like
> > the world view is just a screen showing images on a panel with a bunch
> > of controls in it.
>
> It's interesting then that many of the alternate metaverse viewers try
> to fully decouple the UI (chat boxes, imventory etc) completly from
> the world view window to the point where they are separate windows
> (while the Sl viewer still has it 'all in one wndow').
> Seen with this view of 'immersion' that seem like not so good an idea...
> Thanks for bringing this up, it got me thinking about a few concepts I
> had.
>
> -Martin
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Rob Nelson]

Sigh.  

I've tackled this in my viewer with a plugin, and yet no one seems
interested in the plugin system I'm using;  Everyone's hellbent on
binary plugins.  Feel free to use the code, I haven't added the GPL2
headers yet.

http://code.google.com/p/luna-viewer/source/browse/trunk/indra/newview/lua/Hooks/Windlight/_init_.lua

Fred Rookstown

On Wed, 2010-03-10 at 16:05 +, Opensource Obscure wrote:
> Yesterday Jopsy Pendragon submitted this feature request
> to the public JIRA:
> 
> llSetAgentEnvironment( key agent, [ param list ] );
> http://jira.secondlife.com/browse/SVC-5520
> 
> I'd like to hear your comments.
> 
> I'm not competent enough to say if the request is
> feasible as it's proposed, but the proposed LSL 
> implementation would be fine for me.
> 
> This complements other old PJIRA issues, like
> 
> Estate / Sim Windlight preset / day cycle options
> http://jira.secondlife.com/browse/VWR-7677
> (450 votes)
> 
> and many others - see meta-issue
> http://jira.secondlife.com/browse/SVC-2736
> 
> Please provide feedback and vote as you feel appropriate.
> 
> New, powerful Light/Shadows features are going to
> appear into the official SL viewer;
> the number of users with hardware capable of 
> running advanced lighting features grows;
> so SL land owners need control over this, and IMHO 
> they will need it even more in the future. 
> 
> 
> bye
> 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


___
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

[Thomas Grimshaw]

It's also been implemented completely and is live on the Meta7 grid.

~T

Rob Nelson wrote:
> Sigh.  
>
> I've tackled this in my viewer with a plugin, and yet no one seems
> interested in the plugin system I'm using;  Everyone's hellbent on
> binary plugins.  Feel free to use the code, I haven't added the GPL2
> headers yet.
>
> http://code.google.com/p/luna-viewer/source/browse/trunk/indra/newview/lua/Hooks/Windlight/_init_.lua
>
> Fred Rookstown
>
> On Wed, 2010-03-10 at 16:05 +, Opensource Obscure wrote:
>   
>> Yesterday Jopsy Pendragon submitted this feature request
>> to the public JIRA:
>>
>> llSetAgentEnvironment( key agent, [ param list ] );
>> http://jira.secondlife.com/browse/SVC-5520
>>
>> I'd like to hear your comments.
>>
>> I'm not competent enough to say if the request is
>> feasible as it's proposed, but the proposed LSL 
>> implementation would be fine for me.
>>
>> This complements other old PJIRA issues, like
>>
>> Estate / Sim Windlight preset / day cycle options
>> http://jira.secondlife.com/browse/VWR-7677
>> (450 votes)
>>
>> and many others - see meta-issue
>> http://jira.secondlife.com/browse/SVC-2736
>>
>> Please provide feedback and vote as you feel appropriate.
>>
>> New, powerful Light/Shadows features are going to
>> appear into the official SL viewer;
>> the number of users with hardware capable of 
>> running advanced lighting features grows;
>> so SL land owners need control over this, and IMHO 
>> they will need it even more in the future. 
>>
>>
>> bye
>> 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
>> 
>
>
> ___
> 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] New topic: Snowglobe 2.0 way forward?

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

having GUI elements as completly separated windows from the world
rendering is much different form squeezing the world view in order to
show more GUI elements, it's actually kinda like having windows on top
of the world view, except that you can also move them from out of it.

That approach actually may allow for both styles (over the world view
and fighting for space with it), while also allowing the third style for
people with multiple monitors, where the world view uses the whole
screen space, while communications and other elements are still
displayed without reducing the visibility of the world at all.


I'm not completly sure about how i feel in relation to the immersion of
the third style, i think i would interpret the external windows as
additional senses to vision, i think it's a nice mix of all sorts of
possibilities, it's flexible enough to satisfy all tastes, or at least
the most common ones.




On 10/3/2010 18:47, Martin Spernau wrote:
> Am 10.03.2010 um 22:35 schrieb Tigro Spottystripes:
>> IMO, windows that are on top of the view like a Heads Up Display feel
>> more like they're part of the world, like they are in the same place  
>> as
>> i am, while a bar that makes the world view smaller makes it feel like
>> the world view is just a screen showing images on a panel with a bunch
>> of controls in it.
> 
> It's interesting then that many of the alternate metaverse viewers try  
> to fully decouple the UI (chat boxes, imventory etc) completly from  
> the world view window to the point where they are separate windows  
> (while the Sl viewer still has it 'all in one wndow').
> Seen with this view of 'immersion' that seem like not so good an idea...
> Thanks for bringing this up, it got me thinking about a few concepts I  
> had.
> 
> -Martin
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuYGYQACgkQ8ZFfSrFHsmUKwACdHmg1bPhwKONBOOc9o8atFCuD
6oYAn0aNvVIJCUJdDvdAXlAJ9Qkk/3cP
=rmm3
-END PGP SIGNATURE-
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Backport of Tattoo and Alpha support to v1.23 ?

[Henri Beauchamp]

On Wed, 10 Mar 2010 14:53:09 -0600, Maya Remblai 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.
>
> This is true, but easily dealt with, if I'm understanding things 
> correctly (I haven't had time to try the patch myself): Just make a 
> throwaway set of hair/eyes/skin/whatever's getting corrupted, and switch 
> to something else when you're done editing. Of course that's assuming 
> that the cloud-ruthing isn't permanent.
> 
> Regardless, I'm excited to see effort being put into this. I can't use 
> 2.0 in its current state, and even with all the tweaks in place its new, 
> longer methods of doing things is detrimental to my work. So I'm glad 
> someone's working on backporting, and I know many other content creators 
> that will be similarly pleased. :)

I found what was wrong in my patch. The new code now works properly, but
for a cosmetic glitch (avatar not being rebaked while in customize
appearance mode when changing an Alpha wearable) which I'm trying to
address.

You can expect the next release of the Cool SL Viewer (http://sldev.free.fr/)
to include full Tattoo and Alpha wearables support... ;-)

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 ?

[JB Hancroft]

Of course we have no sense.
We are SL scripters.
We have had our "rational assumptions" pummeled out of us ;)

On Wed, Mar 10, 2010 at 3:45 PM, Glen Canaday  wrote:

> The scripter's list has no sense of humor, either.
>
> On 03/10/2010 09:54 AM, Lance Corrimal wrote:
> > Am Mittwoch, 10. März 2010 15:29:01 schrieb Glen Canaday:
> >
> >> On the bright side - anyone making tattoos and understanding the alpha
> >> mask isn't wearing system hair...
> >>
> > 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.
> > ___
> > Policies and (un)subscribe information available here:
> > http://wiki.secondlife.com/wiki/OpenSource-Dev
> > Please read the policies before posting to keep unmoderated posting
> privileges
> >
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New topic: Snowglobe 2.0 way forward?

[Martin Spernau]

Ok, this is my very personal impression from my use:
* anything that requires me to switch focus will break my immersion
That is true for having to switch from keyboard to moise (like if I  
need to CLICK to focus on the IM text entry, instead of being able to  
use a keyboard shortcut)

In that thought... I'd think that having to switch windows - or even  
monitors to read the chat/IM or select things in the inv... would  
break my immersion.
Note that this does not apply lilewise for activities like scripting  
or building. These are not so much about immersion, but more about  
effcient workflow and 'having it all organized' - sp here being able  
to put the script editor etc on a window outside the world view seems  
very much a want-to-have

My current concept was this:
* I was thinking of reducing the clutter of UI widget on the world  
view by taking the sidebar conceot to it's max... putting all UI (or  
most) panels into this sidebar. Important here would be a good set of  
keyboard shortcuts to quickly switch between tabs etc
That might slo have the added benefir of being able to quickly blend  
out all UI or bring it back - sliding the sidebar as it does. (ok, you  
can do that with mouselook)

Anyway, my feeling is that immersion is less a matter of where things  
are on screen... but how naturally I can access them.

-Martin

Am 10.03.2010 um 23:13 schrieb Tigro Spottystripes:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> having GUI elements as completly separated windows from the world
> rendering is much different form squeezing the world view in order to
> show more GUI elements, it's actually kinda like having windows on top
> of the world view, except that you can also move them from out of it.
>
> That approach actually may allow for both styles (over the world view
> and fighting for space with it), while also allowing the third style  
> for
> people with multiple monitors, where the world view uses the whole
> screen space, while communications and other elements are still
> displayed without reducing the visibility of the world at all.
>
>
> I'm not completly sure about how i feel in relation to the immersion  
> of
> the third style, i think i would interpret the external windows as
> additional senses to vision, i think it's a nice mix of all sorts of
> possibilities, it's flexible enough to satisfy all tastes, or at least
> the most common ones.
>
>
>
>
> On 10/3/2010 18:47, Martin Spernau wrote:
>> Am 10.03.2010 um 22:35 schrieb Tigro Spottystripes:
>>> IMO, windows that are on top of the view like a Heads Up Display  
>>> feel
>>> more like they're part of the world, like they are in the same place
>>> as
>>> i am, while a bar that makes the world view smaller makes it feel  
>>> like
>>> the world view is just a screen showing images on a panel with a  
>>> bunch
>>> of controls in it.
>>
>> It's interesting then that many of the alternate metaverse viewers  
>> try
>> to fully decouple the UI (chat boxes, imventory etc) completly from
>> the world view window to the point where they are separate windows
>> (while the Sl viewer still has it 'all in one wndow').
>> Seen with this view of 'immersion' that seem like not so good an  
>> idea...
>> Thanks for bringing this up, it got me thinking about a few  
>> concepts I
>> had.
>>
>> -Martin
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting  
>> privileges
>>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.12 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuYGYQACgkQ8ZFfSrFHsmUKwACdHmg1bPhwKONBOOc9o8atFCuD
> 6oYAn0aNvVIJCUJdDvdAXlAJ9Qkk/3cP
> =rmm3
> -END PGP SIGNATURE-
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting  
> privileges

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

Re: [opensource-dev] Backport of Tattoo and Alpha support to v1.23 ?

[Maya Remblai]

Henri Beauchamp wrote:
> I found what was wrong in my patch. The new code now works properly, but
> for a cosmetic glitch (avatar not being rebaked while in customize
> appearance mode when changing an Alpha wearable) which I'm trying to
> address.
>
> You can expect the next release of the Cool SL Viewer (http://sldev.free.fr/)
> to include full Tattoo and Alpha wearables support... ;-)
>
> Henri.
>   
Did you hear that? It was the sound of the dozen or so people using 2.0 
dropping it like a hot potato. ;)

Will you be making the patch available by itself? I imagine all the 
third party devs will want it. If I had it, I'd run it through an 
Emerald build myself just for fun, that being the viewer I'm currently 
comfortable working with. (Though I will be trying Cool Viewer since 
it's been brought to my attention again)

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 ?

[Latif Khalifa]

On Wed, Mar 10, 2010 at 11:35 PM, Henri Beauchamp  wrote:
> I found what was wrong in my patch. The new code now works properly, but
> for a cosmetic glitch (avatar not being rebaked while in customize
> appearance mode when changing an Alpha wearable) which I'm trying to
> address.
>
> You can expect the next release of the Cool SL Viewer (http://sldev.free.fr/)
> to include full Tattoo and Alpha wearables support... ;-)

This is awesome news indeed 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 ?

[Henri Beauchamp]

On Wed, 10 Mar 2010 16:48:40 -0600, Maya Remblai wrote:

> Henri Beauchamp wrote:
> > I found what was wrong in my patch. The new code now works properly, but
> > for a cosmetic glitch (avatar not being rebaked while in customize
> > appearance mode when changing an Alpha wearable) which I'm trying to
> > address.
> >
> > You can expect the next release of the Cool SL Viewer 
> > (http://sldev.free.fr/)
> > to include full Tattoo and Alpha wearables support... ;-)
> >
> > Henri.
>
> Did you hear that? It was the sound of the dozen or so people using 2.0 
> dropping it like a hot potato. ;)

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

> Will you be making the patch available by itself?

Yes. Unlike most other third parties viewers, I provide individual patches
for each feature/fix/improvement implemented in the Cool SL Viewer, and
this both for the v1.23 and v1.19 branches (yes, I also intend to try and
backport Tattoo and Alpha support into v1.19, for the benefit of people with
"old" computers).

In fact, most third parties viewers already use part of the Cool SL Viewer
patches... No wonder since it has been around for almost two years and a
half now.

Oh, and that's it: I fixed the last quirk... Patch ready for v1.23. Will
try and backport it to v1.19 tomorrow...

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] New topic: Snowglobe 2.0 way forward?

[Henri Beauchamp]

On Wed, 10 Mar 2010 12:13:23 -0600, Argent Stonecutter wrote:

> On 2010-03-10, at 11:48, Tigro Spottystripes wrote:
> > IMO the 2.0 interface looks way more like a "developer's interface"  
> > than 1.*'s
> 
> Which brings this thread back onto topic for this list. :)
> 
> I agree. The browser has become a familiar interface, but it was  
> largely developed by developers for developers, and for an application  
> things like the address bar and bookmarks and sidebars are distracting  
> and divert attention from the content (the page you're viewing, or the  
> world your avatar is in). Which is why web applications are allowed to  
> remove those decorations when creating a new window.
> 
> The 2.0 interface looks like something a web developer would like to  
> use, not something someone IN SL needs. The address bar, toolbar, side  
> panel, and all the new highly decorated chat boxes and message boxes  
> should at the very least be made optional.

Here is my take on v2.0. It is an extract of a message I wrote in reply
to Nyx Linden yesterday, but since there's nothing secret or private in
it, here you go:

NL> Any specific feedback on how we can tweak the 2.0 viewer to get it
NL> to an acceptable state for power users would be appreciated!

I already took the survey. Basically, the whole new UI is a nightmare
for the old timer, the power user, and the role-player (and since I
"play" in the three categories, it's the worst kind of nightmare as
far as I am concerned: to be frank, I *refuse* to use v2.0 as it is
and should I be forced to use it, I'd quit SL immediately !).

Old timers have to relearn everything and waste their time adapting
their "muscle memory" to the new UI (when at all possible, see below
about the pie menu), while if you provided them with an old-style
skin/UI it would make it so much simpler for them to migrate to v2.0...

Power users miss the ability to freely open and move floaters around,
arranging their layout and size as *they* want it to be.
In this respect, the side bar is *catastrophic* as it imposes a single
layout, eats up an enormous amount of screen space when open and is not
resizable at all (forcing you to close it to actually enjoy the view,
while, for example, a friends floater could be left open all the time
on v1.xx without impairing the 3D world view), and can only display
the equivalent of *one* floater (and even half a floater given how much
fewer info is available at a glance without having to click again to get
the info which was presented in v1.23 floater: the friends list is
*horrible* in this repect: can't see or change the rights without
clicking three more times, and this for each friend !).

Role-players *scream* at the ridiculously small chat input line, at
the enormous, non-transparent chat console, at the needless, impossible
to hide voice button (role-players don't use voice !) and at the real
life tab forced under their nose when they look at an *avatar* profile
(everything that is linked/related to Real Life is a HUGE turn off for
true role-players who want FANTASY and do not care the least for who is
the real person behind the character (avatar) they role-play with).

Everyone who knew v1.23 or former viewers will deeply long for:
- the old skin, with small, space-saving borders and title bars (and
  why the Hell did you make the mini-map, movement and camera controls
  into full floater ?... To eat up more screen space ???... and the two
  controls floaters are now so huge !... Can't let them open all the time
  anymore, and not of the right side anyway, because of that stupid side
  bar that expands *under* them !?!),
- the well contrasted and pretty fonts (white on dark grey, instead
  of grey on grey !... and what's that UGLY font used for avatar names
  and group tags ???...).
- the handy pie menu (I can open a profile or a new IM tab in less
  than a 1/10 of a second in v1.23 and without even having to look at
  the pie menu: I will never be able to do that in v2.0, because the
  context menu entries are arranged in a list and you must read the
  items and carefully move the mouse to click on the right one, when the
  pie menu simply needed a coarse positioning of the mouse pointer to
  get on the right item, with an easy to train "muscle memory" as a
  result)
- the toolbar and all the handy buttons which put all the useful
  features a click away from the mouse (IM, friends, groups, mini-map,
  map, build, fly, etc...)

I could go on like this for hours and pages long...

If you really care about what I (and many residents in your *stable*
user base) consider a good UI, just check for the Cool SL Viewer
(http://sldev.free.fr/)...

So, if you *really* want to keep the v2.0 UI as it is for newbies,
at the very least, please provide the others with a legacy skin/UI
and let people choose... It reminds me of the first days of Windlight
and its "Silver" skin which so many hated and screamed about that it
forced LL to keep the legacy skin as the 

Re: [opensource-dev] Backport of Tattoo and Alpha support to v1.23 ?

[Maya Remblai]

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. Granted, the type of people I 
generally interact with in-world is limited to certain types of people. 
But, those people are content creators, a few role-players, and a lot of 
my own customers. Most of them dislike 2.0 in general, the rest dislike 
it but could tolerate it if some major changes were made. They'd rather 
stick with what they know and can use though. I only know *one* person 
who likes 2.0.
>   
> Yes. Unlike most other third parties viewers, I provide individual patches
> for each feature/fix/improvement implemented in the Cool SL Viewer, and
> this both for the v1.23 and v1.19 branches (yes, I also intend to try and
> backport Tattoo and Alpha support into v1.19, for the benefit of people with
> "old" computers).
>
> In fact, most third parties viewers already use part of the Cool SL Viewer
> patches... No wonder since it has been around for almost two years and a
> half now.
>
> Oh, and that's it: I fixed the last quirk... Patch ready for v1.23. Will
> try and backport it to v1.19 tomorrow...
>
> Henri.
>   
Thank you, thank you, THANK YOU. I knew you were behind many of the 
patches common to several third party viewers, but I haven't looked at 
your site in quite a while and didn't realize you keep a repository of 
patch files. That's a great idea, and very helpful to the community.

Also, I played around with Cool Viewer earlier, and it's my new 
animation uploader. :) I use different viewers for different aspect of 
content creation at times, but lacked one that was really handy with 
animation uploads. Emerald has the preview in-world function, but it 
tends to glitch and freeze the head and eye movements after closing the 
window. Cool Viewer doesn't do that, which I'm very glad of. Good job. 
:D I'll probably use it for other things too, once I get to use it some 
more.

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] New topic: Snowglobe 2.0 way forward?

[Tateru Nino]

Building and scripting are generally high-immersion activities (that is,
they work best with plenty of focus and few distractions).

On 11/03/2010 9:41 AM, Martin Spernau wrote:
> Ok, this is my very personal impression from my use:
> * anything that requires me to switch focus will break my immersion
> That is true for having to switch from keyboard to moise (like if I 
> need to CLICK to focus on the IM text entry, instead of being able to 
> use a keyboard shortcut)
>
> In that thought... I'd think that having to switch windows - or even 
> monitors to read the chat/IM or select things in the inv... would 
> break my immersion.
> Note that this does not apply lilewise for activities like scripting 
> or building. These are not so much about immersion, but more about 
> effcient workflow and 'having it all organized' - sp here being able 
> to put the script editor etc on a window outside the world view seems 
> very much a want-to-have
>
> My current concept was this:
> * I was thinking of reducing the clutter of UI widget on the world 
> view by taking the sidebar conceot to it's max... putting all UI (or 
> most) panels into this sidebar. Important here would be a good set of 
> keyboard shortcuts to quickly switch between tabs etc
> That might slo have the added benefir of being able to quickly blend 
> out all UI or bring it back - sliding the sidebar as it does. (ok, you 
> can do that with mouselook)
>
> Anyway, my feeling is that immersion is less a matter of where things 
> are on screen... but how naturally I can access them.
>
> -Martin
>
> Am 10.03.2010 um 23:13 schrieb Tigro Spottystripes:
>
> having GUI elements as completly separated windows from the world
> rendering is much different form squeezing the world view in order to
> show more GUI elements, it's actually kinda like having windows on top
> of the world view, except that you can also move them from out of it.
>
> That approach actually may allow for both styles (over the world view
> and fighting for space with it), while also allowing the third style  
> for
> people with multiple monitors, where the world view uses the whole
> screen space, while communications and other elements are still
> displayed without reducing the visibility of the world at all.
>
>
> I'm not completly sure about how i feel in relation to the immersion  
> of
> the third style, i think i would interpret the external windows as
> additional senses to vision, i think it's a nice mix of all sorts of
> possibilities, it's flexible enough to satisfy all tastes, or at least
> the most common ones.
>
>
>
>
> On 10/3/2010 18:47, Martin Spernau wrote:
> >>> Am 10.03.2010 um 22:35 schrieb Tigro Spottystripes:
>  IMO, windows that are on top of the view like a Heads Up Display  
>  feel
>  more like they're part of the world, like they are in the same place
>  as
>  i am, while a bar that makes the world view smaller makes it feel  
>  like
>  the world view is just a screen showing images on a panel with a  
>  bunch
>  of controls in it.
> >>>
> >>> It's interesting then that many of the alternate metaverse viewers  
> >>> try
> >>> to fully decouple the UI (chat boxes, imventory etc) completly from
> >>> the world view window to the point where they are separate windows
> >>> (while the Sl viewer still has it 'all in one wndow').
> >>> Seen with this view of 'immersion' that seem like not so good an  
> >>> idea...
> >>> Thanks for bringing this up, it got me thinking about a few  
> >>> concepts I
> >>> had.
> >>>
> >>> -Martin
> >>> ___
> >>> Policies and (un)subscribe information available here:
> >>> http://wiki.secondlife.com/wiki/OpenSource-Dev
> >>> Please read the policies before posting to keep unmoderated posting  
> >>> privileges
> >>>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting 
privileges

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


-- 
Tateru Nino
Contributing Editor http://massively.com/

-- 
Tateru Nino
http://dwellonit.taterunino.net/


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

[Johnnie Carling]

On 03/10/10 5:35:53 pm, Henri Beauchamp wrote:
> I found what was wrong in my patch. The new code now works properly, but
> for a cosmetic glitch (avatar not being rebaked while in customize
> appearance mode when changing an Alpha wearable) which I'm trying to
> address.
> 
> You can expect the next release of the Cool SL Viewer
> (http://sldev.free.fr/) to include full Tattoo and Alpha wearables
> support... ;-)

Henri, any chance you could add a color/tint setting to the tattoo layer? And 
would that even be visible if I gave/sold someone a tinted tattoo and they 
used viewer 2.0

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

[Andromeda Quonset]

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.

At 08:40 PM 3/10/2010, you wrote:
>On 03/10/10 5:35:53 pm, Henri Beauchamp wrote:
> > I found what was wrong in my patch. The new code now works properly, but
> > for a cosmetic glitch (avatar not being rebaked while in customize
> > appearance mode when changing an Alpha wearable) which I'm trying to
> > address.
> >
> > You can expect the next release of the Cool SL Viewer
> > (http://sldev.free.fr/) to include full Tattoo and Alpha wearables
> > support... ;-)

___
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] New topic: Snowglobe 2.0 way forward?

[Ricky]

On the subject, I WANT the silver theme BACK.  I'm severely annoyed that we
had to take a step backward into only having a single theme without
selection.  With the silver theme I could actually read the text on my
screen, and was one of the first things I changed when getting a new viewer.
 Themes need to be selectable, and the current theme is even darker than the
old dark and dull theme!

Now, on a more reasonable tone, I am actually in favor of the sidebar's
"squishing" of the screen.  Although I would like to be able to _optionally_
dock floaters in and out, ala VWR-17013.  The "squishing" is a lot better
than sliding over the screen cutting off the right 3 inches of my render
area, hiding HUDs, etc.  And power users know how to use the Debug Settings
to deactivate features they don't want to see: Like the silly walk and
camera mouse controls.  Why do I need a 4th way to move my character? (1:
AWSD, 2: Arrow Keys, 3: Click-and-drag on the avvie, 4: floater controls)

I've been scripting since my 2nd day in SL, over 3 years ago.  Not as long
as many on this list, and only a month younger than you, Henri, although I
don't yet have the skill you have in reworking the client.  I'm just saying
that not all of us of this SL age are against all the changes.  Some of them
need serious refinement, and for those who don't like the way LL is guiding
the mainline viewer, that why we have good coders like you capable of create
TPVs for those who want something different.

Ricky
Cron Stardust

On Wed, Mar 10, 2010 at 4:49 PM, Henri Beauchamp  wrote:

> On Wed, 10 Mar 2010 12:13:23 -0600, Argent Stonecutter wrote:
>
> > On 2010-03-10, at 11:48, Tigro Spottystripes wrote:
> > > IMO the 2.0 interface looks way more like a "developer's interface"
> > > than 1.*'s
> >
> > Which brings this thread back onto topic for this list. :)
> >
> > I agree. The browser has become a familiar interface, but it was
> > largely developed by developers for developers, and for an application
> > things like the address bar and bookmarks and sidebars are distracting
> > and divert attention from the content (the page you're viewing, or the
> > world your avatar is in). Which is why web applications are allowed to
> > remove those decorations when creating a new window.
> >
> > The 2.0 interface looks like something a web developer would like to
> > use, not something someone IN SL needs. The address bar, toolbar, side
> > panel, and all the new highly decorated chat boxes and message boxes
> > should at the very least be made optional.
>
> Here is my take on v2.0. It is an extract of a message I wrote in reply
> to Nyx Linden yesterday, but since there's nothing secret or private in
> it, here you go:
>
> NL> Any specific feedback on how we can tweak the 2.0 viewer to get it
> NL> to an acceptable state for power users would be appreciated!
>
> I already took the survey. Basically, the whole new UI is a nightmare
> for the old timer, the power user, and the role-player (and since I
> "play" in the three categories, it's the worst kind of nightmare as
> far as I am concerned: to be frank, I *refuse* to use v2.0 as it is
> and should I be forced to use it, I'd quit SL immediately !).
>
> Old timers have to relearn everything and waste their time adapting
> their "muscle memory" to the new UI (when at all possible, see below
> about the pie menu), while if you provided them with an old-style
> skin/UI it would make it so much simpler for them to migrate to v2.0...
>
> Power users miss the ability to freely open and move floaters around,
> arranging their layout and size as *they* want it to be.
> In this respect, the side bar is *catastrophic* as it imposes a single
> layout, eats up an enormous amount of screen space when open and is not
> resizable at all (forcing you to close it to actually enjoy the view,
> while, for example, a friends floater could be left open all the time
> on v1.xx without impairing the 3D world view), and can only display
> the equivalent of *one* floater (and even half a floater given how much
> fewer info is available at a glance without having to click again to get
> the info which was presented in v1.23 floater: the friends list is
> *horrible* in this repect: can't see or change the rights without
> clicking three more times, and this for each friend !).
>
> Role-players *scream* at the ridiculously small chat input line, at
> the enormous, non-transparent chat console, at the needless, impossible
> to hide voice button (role-players don't use voice !) and at the real
> life tab forced under their nose when they look at an *avatar* profile
> (everything that is linked/related to Real Life is a HUGE turn off for
> true role-players who want FANTASY and do not care the least for who is
> the real person behind the character (avatar) they role-play with).
>
> Everyone who knew v1.23 or former viewers will deeply long for:
> - the old skin, with small, space-saving borders and title bars (and
>  why the Hell did 

Re: [opensource-dev] Backport of Tattoo and Alpha support to v1.23 ?

[Maya Remblai]

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