Re: [opensource-dev] Client-side scripting in Snowglobe

[Rob Nelson]

B-B-But what about Lua, which has already been implemented in FlexLife
(http://flexlife.nexisonline.net)? :(

Fred Rookstown
Lead Developer

On Thu, 2010-02-18 at 12:42 +, Morgaine wrote:
> I referred recently to Linden's internal project "Firefly" to add
> client-side scripting to SL viewers.  This has been the topic of open
> discussion at several Office Hours with Lindens in SL, but that
> openness has not extended to many design details --- the Firefly
> design process is not open to the community.  The only technical
> details that are being disclosed about Firefly appear to be:
> 
>   * "Scripts" are actually Mono assemblies, so that only languages
> that compile to Mono will be allowed.
>   * The programs run in a sandbox, which means that most platform
> resources are not accessible to them.
> 
> Please note that I quite like C# as a language, but the following
> remarks are about Mono use in the SL viewer, only, where its tradeoffs
> are poor.
> 
> The first known detail about Firefly (mandatory Mono) is problematic
> on several fronts:
>  1. Only a tiny fraction of the world's applications, libraries
> and languages work on Mono, so client-side scripting will be
> unable to benefit from the huge mountain of resources
> available on the Internet.  This is an extremely severe
> limitation, and an unnecessary restriction in the context of
> client-side viewer scripting.  If I want to use a
> locally-installed package X from within my client-side script,
> I should be able to.  What runs client-side should always be
> our individual choice, not someone else's.
>  2. Programmers want to write client-side scripts in the language
> that they know best, because that always yields the fastest
> progress and highest quality results.  There was a good
> technical reason for forcing everyone to use LSL server-side,
> but there is no technical reason to impose this requirement on
> all client-side scripting.  It is counter-productive to force
> CLR compatibility on client-side script developers when there
> is a simple alternative:  define a socket-based viewer API for
> client-side scripts instead, hence usable from any language.
>  3. Mono runs poorly on Linux, so from being rock-solid on Linux
> now, the LL-derived viewers will become second-rate on this
> platform.
>  4. The viewer is already extremely bloated and a memory hog.
>  Adding a Mono dependency will compound that horribly.
>  5. There is only one effective supplier of Mono:  Novell.  That
> is a very bad situation to encourage and to support in the
> viewer.
>  6. Some parties identify other reasons for avoiding Mono in
> general.  Without getting into that subject at all, 
> 
> The second known detail about Firefly (mandatory sandbox) is
> problematic on two related fronts:
>  1. Sandboxes by design do not allow most platform resources to be
> accessed, as a security measure.  This is fine and important
> when scripts are being downloaded from unknown places (like
> Javascript in web pages), but that same protection also means
> that client-side scripts would be powerless to do useful
> things for us in concert with local applications, files,
> devices, etc.  Sandboxing client-side scripts effectively
> hardwires in script weakness for no reason discussed as a
> requirement.
>  2. Sandboxed applications cannot be linked with user-chosen
> native libraries since allowing native code breaks sandbox
> protection.  This means no accelerators, no extensions, and no
> interop with other systems since sockets are inaccessible from
> any strong sandbox.  This also means no evolution or progress
> outside of what the sandbox designers permit.
> 
> This mailing list is concerned with development of open source
> viewers, in particular Snowglobe.  This is heralded as a community
> viewer, embodying community requirements much more directly than the
> LL mainstream viewer.  Client-side scripting will impact on every
> single aspect of Snowglobe bar none, yet the community is being
> excluded from the design of its most powerful infrastructure element.
>  This is entirely wrong, far beyond the normal observation
> that secrecy in design has no place in open source.
> 
> It is hard to assess things technically when the design requirements
> are formulated in secret.  The Snowglobe community has design
> requirements too.  Those deserve to be examined here openly, not
> limiting Snowglobe to a design that stems from Linden requirements
> alone.
> 
> 
> Morgaine.
> 
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Plea

Re: [opensource-dev] Client-side scripting in Snowglobe

[Rob Nelson]

agree on would be the
> > set of messages that cross the socket interface, and the set
> > of functions and callbacks that the messages would engage in
> > the viewer.  That's the kind of productive technical
> > discussion we could be having with Lindens, if their design
> > process for client-side scripting were open.  It needs to
> > be.
> > 
> > 
> > Morgaine.
> > 
> > 
> > 
> > 
> > 
> > === 
> > 
> > 
> > On Fri, Feb 19, 2010 at 5:24 AM, Rob Nelson
> >  wrote:
> > B-B-But what about Lua, which has already been
> > implemented in FlexLife
> > (http://flexlife.nexisonline.net)? :(
> > 
> > Fred Rookstown
> > Lead Developer
> > 
> > On Thu, 2010-02-18 at 12:42 +, Morgaine wrote:
> > > I referred recently to Linden's internal project
> > "Firefly" to add
> > > client-side scripting to SL viewers.  This has
> > been the topic of open
> > > discussion at several Office Hours with Lindens in
> > SL, but that
> > > openness has not extended to many design details
> > --- the Firefly
> > > design process is not open to the community.  The
> > only technical
> > > details that are being disclosed about Firefly
> > appear to be:
> > >
> > >   * "Scripts" are actually Mono assemblies, so
> > that only languages
> > > that compile to Mono will be allowed.
> > >   * The programs run in a sandbox, which means
> > that most platform
> > > resources are not accessible to them.
> > >
> > > Please note that I quite like C# as a language,
> > but the following
> > > remarks are about Mono use in the SL viewer, only,
> > where its tradeoffs
> > > are poor.
> > >
> > > The first known detail about Firefly (mandatory
> > Mono) is problematic
> > > on several fronts:
> > 
> > >  1. Only a tiny fraction of the world's
> > applications, libraries
> > > and languages work on Mono, so client-side
> > scripting will be
> > > unable to benefit from the huge mountain
> > of resources
> > > available on the Internet.  This is an
> > extremely severe
> > > limitation, and an unnecessary restriction
> > in the context of
> > > client-side viewer scripting.  If I want
> > to use a
> > > locally-installed package X from within my
> > client-side script,
> > > I should be able to.  What runs
> > client-side should always be
> > > our individual choice, not someone else's.
> > 
> > >  2. Programmers want to write client-side
> > scripts in the language
> > > that they know best, because that always
> > yields the fastest
> > > progress and highest quality results.
> >  There was a good
> > > technical reason for forcing everyone to
> > use LSL server-side,
> > > but there is no technical reason to impose
> > this requirement on
> > > all client-side scripting.  It is
> > counter-productive to force
> > > CLR compatibility on client-side script
> > developers when there
> > > is a simple alternative:  define a
> > socket-based viewer API for
> &

Re: [opensource-dev] Third party viewer policy

[Rob Nelson]

Thanks LL, you killed my viewer that I have developed alone for two
years and was probably a week away from releasing, due to one stupid
copyright enfarcement rule: No "Life" in the name.  Do you realize how
much documentation, sourcecode, licensing, subdomains, bug trackers,
wiki, images, logos, google code/SVN repo, etc that I, a one-man
development team with other things on his mind have to change?  Did you
even consider all of this prior to releasing this policy?

If I do resume development, AGNI will not be a grid my users will be
able to connect to. I hope others with the same problem will also
boycott your grid because of this.

All I wanted to do was develop some software that would maybe be helpful
to people, or perhaps improve the user experience.  Now no one can use
it.  Thanks a lot.


I've tried hard over the last year to 
On Tue, 2010-02-23 at 15:16 -0500, Gigs wrote:
> http://secondlife.com/corporate/tpv.php
> 
> You all realize this is massively incompatible with the GPL, right?
> 
> 
> ___
> Policies 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] So what happens if....

[Rob Nelson]

>From my reading, you get banned in all four cases, since you
automatically take responsibility for the users' activities (Section 7
3PVP).

On Wed, 2010-02-24 at 07:08 +0200, Imaze Rhiano wrote:
> First I want to thank LL from efforts to create ethical guidelines for 
> respectable viewers. Unfortunately I don't think that these rules are 
> going to work in reality where we are living.(And as others have already 
> pointed out - there might be incompatible with GPL and other licenses.)
> 
> Let's imagine one moment that instead of being ebil bitch I would be 
> respectable software developer and create my own viewer that fully 
> confirms policy. I would register my viewer to your viewer directory. 
> Now - one of following scenarios would happen - what I should do - and 
> what would be LL's reaction:
> 
> 1) My viewer is open sourced. Some evil person(s) take source code and 
> add functionality that breaks policy. They don't bother to change 
> viewer's id or other identification data.
> 
> 2) My viewer have plugin framework that allows 3rd party developers to 
> create their own plugins. One evil person then writes plugin that is 
> breaking rules of viewer policy.
> 
> 3) Evil persons will develop proxy or software hook that will steal data 
> directly from data stream between client and LL servers - or - 
> communications between viewer's host module and DLLs. Proxy / hook is 
> completely transparent - neither client or server can detect it.
> 
> 4) I will develop closed source viewer and evil persons will develop 
> their own evil viewer. Then they decide to fake my viewer's 
> identification data so that server thinks that their evil viewer is 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


___
Policies 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] Third party viewer policy

[Rob Nelson]

My estate's prototype land management/group invite bot was banned last
night ("Second Life cannot be accessed from this computer, please email
us at our non-working support email so we can laugh at you") but it
works this morning.  Looks like they got too many support emails and had
to reverse that ban.

On Thu, 2010-02-25 at 12:31 -0600, Matrice64 wrote:
> well put k\o\w :-) 
> 
> On Thu, Feb 25, 2010 at 11:37 AM, Maggie Leber (sl: Maggie Darwin)
>  wrote:
> On Thu, Feb 25, 2010 at 11:45 AM, Gigs 
> wrote:
> > Henri Beauchamp wrote:
> >> Thank you for contacting us regarding your issue.
> >> I am sorry but we can only offer support on issues with the
> official
> >> SL viewer.
> > This sort of response is completely unacceptable.  You
> weren't asking
> > for support for your viewer, you were asking for support
> related to the
> > server's behavior.
> 
> 
> I've been blown off with that excuse too.
> 
> Read http://jira.secondlife.com/browse/SVC-5357 for my
> trail-of-tears
> support experience.
> 
> Sure glad I went premium, I got this nifty free house...
> 
> ___
> Policies 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] Third party viewer policy

[Rob Nelson]

I (obviously) agree.

I highly doubt that trying to claim copyright on "Life" or "Second" in
court would make the judge take the case seriously.  What's next,
claiming copyright on "primitive", "avatar", "lab", and "simulator"?
Sending C&Ds to people who write viewers called Slick or Slanderous?
Sending C&Ds to people who write programs that have nothing to do with
Linden Lab whatsoever?

Also, can anyone confirm/deny whether "Living" is also a forbidden term?
RLV's developer blog has posted that "Living" was also rejected by
Linden staff, but I'd like to hear it from the horse's mouth.  If so, I
might as well move my viewer over to OpenSim exclusively, and not have
to bother with overbearing regulations and rabid lawyers at all.

When you spend so much time harassing legitimate viewers, and so little
time going after the people who are actually damaging you, you need to
re-check your priorities.  People who write Copybots and NeilLife-like
viewers are your enemies (they're certainly not going to spend much
money), so go after them instead of having everyone else jump through
hoops that the copybotters are going to ignore anyway.  All you're doing
is making it harder for legitimate people to create content and
applications for your grid.

Also, are we going to see enforcement of this, or is it going to quietly
disappear after about a week like all of the other Copybot/Content
theft-related promises we've heard on the blog?  

Rob Nelson
Lead Developer
Luna Viewer (http://luna-viewer.googlecode.com)

On Thu, 2010-02-25 at 22:01 -0800, Bryon Ruxton wrote:
> A name suggestion for viewers: "A viewer that connect to a virtual world
> that can't be name for risks of being objected to by a company with
> aggressive lawyers who like to come up with unconscionable terms of
> services, or who make illegitimate attempts of one's right to forbid the
> usage of words they do not have trademark rights over"
> 
> > "Unfortunately they maintain that we put our trademark at risk without
> consistent enforcement. They can't budge."
> Soft, they ought to consider that abusive overreach on their part could on
> the other end, put LL at risk of being liable once again of lawsuits being
> translated in court to unconscionable terms of services. Sounds familiar?
> 
> As far I recall LL has the trademark over "SL" and "Second Life".
> So perhaps your lawyers could suck the "Life" out of their jurisdictions?
> 
> I get the fact that they had to go an extra unusual mile with brand name
> protection due the nature of the company's name. But there was also an
> attempt to trademark the word "grid" alone, in the past. That speaks a lot!
> 
> I don't see a need for concessions here, but for your lawyers to re-evaluate
> their legitimate rights to such claim to begin with. I just don't see it.
> 
> If I was your marketing department. I would be equally concerned as to the
> repercussions of such restrictions for impeding the ability for Linden
> Research to promote its Second Life name and market itself as a grid.
> 
> "Stop shooting yourself in the foot. It could impede your ability to walk."
> 
> 
> On 2/24/10 11:16 AM, "Soft Linden"  wrote:
> 
> > On Wed, Feb 24, 2010 at 1:50 AM, Marine Kelley  
> > wrote:
> >> You gotta be kiddin me !! I call that a stab in the back. You guys disgust
> >> me.
> >> 
> >> Your Third-Party Viewer name must not be confusingly similar to or use any
> >> part of a Linden Lab trademark, including ³Second,² ³Life,² ³SL,² or
> >> ³Linden.² For example:
> >> 
> >> You must not have a Third-Party Viewer name that is ³ Life² where
> >> ³² is a term or series of terms
> > 
> > I talked to legal to ask if there were any concessions they could make
> > - I know there are hundreds of items that use your name, which makes
> > this really disruptive. Unfortunately they maintain that we put our
> > trademark at risk without consistent enforcement. They can't budge.
> > However, they were willing to offer some extra time for transitioning
> > to a new name, as well as help in making sure people can still find
> > your viewer based on the old name.
> > 
> > First, you wouldn't need to change the name right away. They were okay
> > with giving three months to make a change, in hopes that that's enough
> > time to do so without a rush or an extra release.
> > 
> > Second, if you're able to do that, you can still be listed in the
> > viewer registry right away. You'd

Re: [opensource-dev] FAQ posted for Third Party Viewer Policy

[Rob Nelson]

Two months to make changes?  I was told we had 3 months.

On Fri, 2010-02-26 at 21:14 -0600, Soft Linden wrote:
> There's now a FAQ for the Linden Lab Policy on Third Party Viewers:
> http://bit.ly/caedse
> 
> This addresses many of the questions and concerns made in
> opensource-dev and elsewhere. An updated version of the TPV doc itself
> is also coming, but expect this within a couple weeks. Go visit the
> FAQ, or read on for the TPV doc update details...
> 
> I know that the member of the legal team who owns the policy doc is
> still working over the final version. Linden Lab has approached
> outside legal experts with your feedback, and one of these experts is
> a lawyer who specializes in open source license compliance issues.
> Based on these experts' feedback and further internal review, our
> legal department will incorporate any required changes.
> 
> In the meantime, while it helps to start making changes now, parts of
> the policy are not yet in effect. See the tail of the FAQ for dates
> and the portions affected.
> ___
> Policies 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] Third party viewer policy

[Rob Nelson]

A sidenote:  What do we do to have our existing viewer groups renamed
from one viewer name to another?  File a support ticket or yell at a
specific Linden?  I already have a bunch of people in my FlexLife group,
but I need to rename it to Luna, and I'm not going to go waste L$100 and
another load of advertising to draw the same people back when I'm not
even sure if LL isn't going to force us to rebrand everything again in
the future for an even more obscure reason.

Rob Nelson
Luna Viewer (http://luna-viewer.googlecode.com)

___
Policies 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] Eclipse Guru's

[Rob Nelson]

Well, now that I've managed to (finally) find most of the UI drawing
stuff,  it's highly possible that I'll have a working plugin framework
for editing LSL (and Lua) scripts from within the viewer within the next
year (after I refactor the Lua modules and get GL running).

Unfortunately, it looks like many people have already gone with the
binary socket addon model that snowglobe's using.

On Thu, 2010-03-04 at 12:28 -0800, Ambroff Linden wrote:
> On Wed, Mar 3, 2010 at 7:03 AM, Jonathan Irvin 
> wrote:
> I do often hear complaints and wishes for new build tools,
> what about us LSL devs?  Some things I would like are:
>  1. Better IDE in SL Viewer
>  2. API for compiling in LSL using various IDEs already
> available
>  3. Going along with #1, as suggested, integrating Eclipse
> or equivalent in SL.
>  4. LSL Wiki built into the editor
>  5. Detachable script editing window (To develop on one
> monitor & test in the other)
>  6. Entity relationship diagram system in SL viewer for
> visual coding.
> I'm not sure that spending whole lot of time adding fancy features to
> the built in LSL editor is  that productive (we aren't trying to build
> an IDE, and there are a ton of really good extensible IDEs out there
> already), but I really like your idea of putting together an API.
> Someone could hack a service into the viewer that lets another process
> (like Eclipse or Monodevelop) perform limited operations on the
> inventory of the currently selected object.
> 
> 
> We already have D-Bus integration in the GNU/Linux Viewer for SLurl
> support, so it shouldn't be too hard to expose something like an
> ObjectEditorProxy. It could allow an extension for your favorite IDE
> to enumerate the scripts that are editable in the currently selected
> object's inventory, fetch their contents, compile(), and add new
> scripts to the object's inventory. The IDE could also subscribe to
> events emitted by the viewer, such as ScriptAdded, ScriptDeleted, etc.
> 
> 
> What might improve the situation quite a bit is if the server
> supported a capability that allowed the viewer to fetch all symbols
> exported by the simulator (all LSL functions and constants). That
> metadata could then be exposed to the IDE through the
> ObjectEditorProxy for intellisense support.
> 
> 
> In the long run I don't know if this is a good solution, but it would
> certainly be an interesting experiment!
> 
> 
> -Ambroff
> ___
> Policies 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

[opensource-dev] Client-side Permissions Management

[Rob Nelson]

While working on my viewer's object handling stuff, I happened across a
rather fundamental flaw in the SL viewer's architecture.

When one considers filesystem permissions or even database permissions,
you notice that permissions are generally attached to the object that a
user attempts to access, or the permissions are obtainable from a
central source that has a simple way to grab the permissions.

>From my casual glance at the viewer code, I noticed that the latter is
the case in the LL viewer.  However, there's a rather large problem for
those of us who are writing client-side scripting APIs.  

Consider a user in a sandbox who wants to clean up his mess.  If he were
using a viewer based on LibOMV, all the viewer would have to do is loop
through the region's object dictionary and return/delete objects that he
owns.  In the LL viewer (correct me if I'm wrong), LLSelectMgr actually
returns the permissions (*and owner/creator info*) , so the viewer would
have to select each and every object within the sim to grab its
permissions, which seems rather wasteful of bandwidth, and troublesome
in general.  This works fine for situations where the object is selected
anyway (when building or right-clicking), but it's horribly inefficient
for scripting.

I haven't dug deep enough yet to fully grasp what is going on in
LLSelectMgr, but it seems to me that it would be a lot more efficient to
simply attach the permissions with each object's properties when they
are sent to the client by the server, eliminating the need for scripts
(and bots) to have to spam the server requesting permissions.

Fred Rookstown
Luna 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] Client Plugin System Design

[Rob Nelson]

On Sun, 2010-03-07 at 18:19 -0800, Ricky wrote:
> So far, barring any LL concepts, we have (as far as I know so far!)
> two designs of plugin system:
> 1: Socket-based plugins - as suggested by Morgaine.
> 2: D-Bus or similar existing IPC tool.
> 3: C++ Dynamically Shared Objects - my suggestion.

You forgot interpreted scripts, such as Lua.  Already implemented and
working in the Luna viewer.  A lot easier to develop for, as well, since
users don't need to have an API to use it. All they need to know is how
to make it work and where to dump their files.  

The largest issue is sandboxing and threading, actually.  I still have
to make an override for the io.* functions that will not access
materials outside of lua/data or the plugin's folder, and creating a
working event queue is becoming a major pain in the neck.

Fred Rookstown
Luna Viewer (http://luna-viewer.googlecode.com)

___
Policies 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] Potential inventory problem?

[Rob Nelson]

Hahaha, I remember back when Open Grid Services was written in PHP;  I
still have it on my webserver somewhere.  I think I submitted a patch to
you guys several years ago (regarding a SQL injection exploit) where I
accidentally left in a bunch of cursing and racial slurs.

If I contribute again, I think I'll be a little more careful.

Also, I'll take a peek into what's causing that problem;  I'm having to
redo the UI in Lua anyway, so I may as well figure out what is causing
your issues.

Fred Rookstown

On Mon, 2010-03-08 at 11:17 -0800, John Hurliman wrote:
> Yes, I'm trying to push out the first release of a set of PHP grid
> services for OpenSim and the texture picker freeze bug is a
> showstopper. It obviously doesn't happen on SLGrid and it wasn't
> happening in the past with OpenSim. A packet trace didn't show
> anything interesting (doesn't appear to be triggered by a specific
> packet at all). My current guess is that the client is making a bad
> assumption about information the server sent earlier on. It might have
> to do with the library since I am not sending a library skeleton at
> the moment.
> 
> Any other clues on the freezing issue would be much appreciated. The
> warning is more of a curiosity but it could uncover another hidden
> expectation the open source server software is not meeting.
> 
> John
> 
> On Mon, Mar 8, 2010 at 9:21 AM, Nexii Malthus 
> wrote:
> Happens just as well on any grid. I'm just as confused as
> anyone here what this error message means, but this was
> brought up before and I vaguely remember a linden saying that
> wasn't the source of the lag problems related to inventory.
> 
> 
> Are you trying to track down the texture picker freezing bug?
> 
> 
> - Nexii
> 
> 
> On Mon, Mar 8, 2010 at 12:45 AM, John Hurliman
>  wrote:
> 
> 
> When logging into OpenSim with Snowglobe I see a lot
> (dozens) of these messages in the log file:
> 
> 2010-03-08T00:33:18Z WARNING:
> LLInventoryPanel::modelChanged:
> d24c5c7b-4d64-45eb-9286-91fb0f307b24 is in model and
> in view, but STRUCTURE flag not set
> 
> What does this message mean? Am I sending inventory
> items in the wrong order, or with missing data? I'm
> trying to track down a client freezing bug in
> Snowglobe and the official viewer that might be
> related to inventory, and found this.
> 
> John
> 
> 
> ___
> Policies 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] 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] Fwd: Request for comments about llSetAgentEnvironment / SVC-5520

[Rob Nelson]

I agree;  In fact, people have been trying to communicate with Lindens
in some meaningful way (as is required in Open Source projects) since
the beginning of the open-sourcing of the viewer, but it seems that
Linden Lab seems more inclined to dictate what changes WILL be done
rather than gathering a consensus with OSS developers. See: hidden
SVN/HG servers, unreleased SL 2.0 beta source code, overall poor bug
turnover and triage in PJIRA (SVC-1509, anyone?), office hours vanishing
into thin air...  

Quite frankly, the idea of forking the entirety of SL (OpenSim and
viewers), as suggested by Morgaine, is looking quite attractive.  At
least then the community can actually contribute without being shot
down, blocked by a wall of red tape, or chased off by rabid TPV
policies.  We can then also contribute to the server-side of things
rather than waiting for the server goons to get around to adding or
fixing features.

Fred Rookstown

On Fri, 2010-03-12 at 21:26 -0500, Maggie Leber (sl: Maggie Darwin)
wrote:
> -- Forwarded message --
> From: Maggie Leber (sl: Maggie Darwin) 
> Date: Fri, Mar 12, 2010 at 9:24 PM
> Subject: Re: [opensource-dev] Request for comments about
> llSetAgentEnvironment / SVC-5520
> To: Soft Linden 
> 
> 
> On Fri, Mar 12, 2010 at 2:31 PM, Soft Linden  wrote:
> 
> > A totally healthy open source project usually can be developed
> > completely in the open, and in a way that's aligned with everybody's
> > interests. But that takes an active commitment on all sides...
> 
> True enough. But I think there's widespread perception that the Second
> Life Viewer is already  not a "totally healthy open-source project",
> and I don't think that perception can't be laid at the door of
> "obstructionism". 


___
Policies 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] oh give me a break

[Rob Nelson]

You're very, very delusional.

Fred Rookstown

On Sun, 2010-03-14 at 21:01 -0600, New Hax wrote:
> On 3/14/10, Carlo Wood  wrote:
> >
> > Imho, SL would have have had better products if everything
> > had been free and open (no permission system). Then one could
> > learn from others and improve things, build upon the experience
> > and work of others, and nobody would make money of it or have
> > to be afraid that others would.
> >
> 
> We can still make it that way. Copyclients still work for now. And
> lots of them cant be detected by Linden Labs.  So if we get out there
> and free a lot of content before Linden Labs closes up the viewer then
> Linden Labs will have no choice but to embrace a FREE and OPEN grid.
> 
> Nobody should be making money in SL. Think, it could be a hacker or
> experimenter or THINKERS paradise instead of a capitalist platform.
> 
> > The fact that scripts can't be copied is lucky for those
> > that are making real money in SL, it is their only and last
> > protection against losing their income.
> >
> 
> And their time will come and their locked up proprietary stuff will be
> freed, also. There are lots of coders working on that.
> 
> > That brings me to the fact that LL is currently working
> > in secret and without discussion on the implementation
> > of client-side scripting, and from the tiny bit of information
> > that leaked out, they are apparently trying hard to make
> > also THOSE scripts hard to copy / inspect / improve upon.
> >
> 
> I say they should go for it with client side scripting. Then we will
> be able to open it up and share everyones scripts. Right now scripts
> are locked away on the server and is the last link that we as hackers
> and coders cant open.
> 
> Everyone who believes in a real OPEN grid should get out there and
> copy and FREE (do not charge for it) as much proprietary content as
> you can. Teach content makers and Linden Labs by force (we have
> control) that the only future is FREE.
> 
> 
> Join us now and share the software;
> You'll be free, hackers, you'll be free
> 
> Hoarders can get piles of money,
> That is true, hackers, that is true.
> But they cannot help their neighbors;
> That's not good, hackers, that's not good.
> 
> When we have enough free software
> At our call, hackers, at our call,
> We'll kick out those dirty licenses
> Ever more, hackers, ever more.
> 
> Join us now and share the software;
> You'll be free, hackers, you'll be free.
> 
> Song PUBLIC DOMAIN by Richard M. Stallman!!!
> 
> I'm OUT!
> ___
> Policies 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] oh give me a break

[Rob Nelson]

And what about value of goods, something we learned in highschool
civics?  The more stuff that is available, the less it's valued.  If I
were to somehow make a system IRL that cloned pure gold by the
truckload, and set up enough plants to produce gold, would gold be worth
as much as it was before I started making more gold available?  This can
be applied to no-copy furniture makers.

Fred Rookstown

On Mon, 2010-03-15 at 23:57 +0100, Carlo Wood wrote:
> On Mon, Mar 15, 2010 at 04:22:58PM -0600, Maya Remblai wrote:
> > Not true. See the following example that actually happened to me:
> > 
> > Person A rips a large number of products, including mine. He boxes them 
> > and gives them away, for free, claiming he has my permission (which he 
> > doesn't). Now, the total value of my products involved was $150 USD. If 
> > he only gave the box to 10 people (it was actually more than that) I'm 
> > now out $1500 USD. Person A has done a huge amount of monetary damage to 
> > me by taking away sales.
> 
> Not entirely true, first of all, he didn't steal any money from
> you, nor any goods; unless you suddenly saw a significant drop
> in revenue then nothing really happened, financially spoken.
> 
> It certainly isn't true that if he did NOT give that box to
> those ten people that all ten would have come to you and spend
> L$ 40,000 in your shop.
> 
> In fact, most people spend a fixed amount of money in SL. If
> they get anything for free on top of that, it doesn't cause
> them to spend less real money.
> 
> So, surely, you didn't get any MORE money because of this..
> but you didn't *lose* $1500 either, not even a fraction of that.
> 


___
Policies 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] oh give me a break

[Rob Nelson]

On Tue, 2010-03-16 at 09:48 +0100, Anders Arnholm wrote:
> 
> There been a nice illustration floating arounf the internet, showing the 
> problems with DRM protections today, mostly on video media.
> 
> http://www.techxav.com/wp-content/uploads/2010/02/piratelegal.jpg

I love the subtle :trollface: in the background.  I don't know why it's
there, but it's still great.

___
Policies 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] Client Plugin System Design

[Rob Nelson]

As stated before, sockets add unnecessary bulk to any plugin
architecture, ESPECIALLY HTTP.  The SL viewer currently takes up 100%
CPU even with scripting turned off;  The last thing we need is more
memory or processor load.  

There are ways to signal the viewer when an event has occurred without
using sockets, and without running a separate process. A simple
std::queue of events being passed to the Lua engine is what I currently
use.  I therefore suggest C++ Dynamic Shared Objects, each providing a
language option (Lua, Python, Mono), but with a shared interface that:

 * Provides public start/restart/kill methods (for a scripting console)
 * Is in its own thread (to prevent blocking)
 * provides a way to pass in events with variable arguments (Luna uses a
string stream with serialized objects)
 * Provides the scripting engine some basic "environmental
variables" (Viewer name/channel/version, settings THAT ARE NOT
PASSWORDS, some other global vars like gAgent)
 * Automatically starts (if configured to do so) only AFTER login to
prevent receiving login details
 * Does not provide a way to create raw messages or send money.

There's probably a bunch of other requirements, too.  

If firefly is truly using Mono, then I do sincerely hope it fails.  Mono
is way too slow to run plugins efficiently, and as seeing that the
viewer is already chock-full of slowness, I don't want any more overhead
added.

Rob Nelson
Luna Viewer 
http://luna-viewer.googlecode.com/

On Wed, 2010-03-17 at 10:50 -0500, Argent Stonecutter wrote:
> On 2010-03-17, at 10:21, Dzonatas Sol wrote:
> > Ricky wrote:
> >> So far, barring any LL concepts, we have (as far as I know so far!)
> >> two designs of plugin system:
> >> 1: Socket-based plugins - as�suggested�by Morgaine.
> >> 2: D-Bus or similar existing IPC tool.
> >> 3: C++ Dynamically Shared Objects - my suggestion.
> >
> > 4. REST/HTTP
> 
> That's just a specific design for category 1.
> 
> ___
> Policies 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] Third party viewer policy: commencement date

[Rob Nelson]

Because of these ongoing problems, I have disabled the Luna Viewer's
ability to log into Second Life's grids (ADITI and AGNI), and encourage
other Open Source viewers to do the same.  

As an opensource developer, I feel betrayed.  Many of us have tried to
help your company with bug reports, patches, security fixes, and even
protocol guidance, all to be kicked to the curb with the TPV.

I'm personally done with Linden Lab's false promises of an open
development environment.  Any further contributions will be done to the
benefit of OpenSim only.  If Linden Lab wants open-source developers to
help them, they're going to have to prove it.

Adios.

Fred Rookstown 

On Sun, 2010-03-21 at 16:02 -0400, Jesse Barnett wrote:
> Jeez I fail to understand why in the heck LL can not understand this
> simple concept.
> 
> Linden devs have introduced bugs before that have allowed content to
> be stolen, no mod scripts to be readable, and inventories worth
> several hundred dollars to vanish overnight. Yet, none of you, under
> the terms of your employment, are legally liable for this nor do you
> have to compensate for the losses out of your pocket.
> 
> Would any Linden here sign a document stating that you are personally
> liable for your code??
> 
> Would you sign a document stating that if you introduced another bug
> that makes inventories vanish that you have to pay all the affected
> parties back
> 
> Would you sign a document that is worded so poorly that you then have
> to create a FAQ for that same document but the FAQ is in itself
> non-binding, only the original, poorly worded contract?
> 
> Please take off the rose colored glasses and read it again as if YOU
> had to sign it, then you will begin to understand the considerable
> amount of unease that the community is experiencing at the moment.
> 
> Jesse Barnett
> ___
> Policies 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] Third party viewer policy: commencement date

[Rob Nelson]

Boy's right, too.

 * FAQs are not legally binding. 
 * Comments on a mailing list are not legally binding.  
 * Policies attached to a Terms of Service agreement ARE legally binding
once we agree to them.

I am not going to do any further development of any type of software for
Second Life until I am absolutely certain that:

 * I am not going to be held accountable for any of my user's actions
 * I will not violate my software's licensing agreement by agreeing to
the TPV
 * I am not going to be forced to place my personal information in a
publically viewed area in order to advertise my viewer.

Since Linden Lab has already told Massively that they do not plan to
update the TPV
,
 I do not plan to do any further work on any SL-based OSS.  I advise other 
viewer devs to also suspend their projects until a fixed TPV comes out, as 
there are very serious consequences to continuing SL OSS development with the 
current state of the TPV.

It would be nice if LL actually listened to us and fixed the TPV as we
asked instead of merely clarifying the statements they've made, but
knowing LL's previous track record, I'm not holding my breath.   Their
statements about "getting a lawyer" before commenting on this very
serious issue is also very troubling, as it doesn't take a lawyer to see
that there's something very, very wrong with the TPV.


On Wed, 2010-03-24 at 01:24 +, Morgaine wrote:
> [CC Philip]
> 
> Boy Lane's article is the clearest summary of the whole sorry
> situation so far.
> 
> I hope that his very accurate analysis is handed to someone at high
> level in LL, because it is clear that no Lindens on this list are able
> or willing to engage in the matter.  The lawyers behind the scenes at
> LL appear to be truly out of control, and uncaring of the mammoth GPL
> non-compliance of what they have written.
> 
> I have CC'd this post to Philip Linden, because being at arm's length
> from the Lab nowadays, perhaps he can see more clearly than some how
> far the situation has deteriorated from the original vision of an open
> client and an ecosystem of GPL developers.
> 
> Boy Lane's article is enclosed.
> 
> 
> Morgaine.
> 
> 
> 
> 
> 
> 
> =
> 
> On Tue, Mar 23, 2010 at 12:34 PM, Boy Lane  wrote:
> I've put my summary about TVP on my blog
> 
> http://my.opera.com/boylane/blog/linden-labs-final-3rd-party-viewer-policy-tpv
>  
>  
> Linden Lab's final 3rd Party Viewer Policy (TPV)
> TUESDAY, 23. MARCH 2010, 19:15:03
> 
> A lot of things are changing, I've voiced my opinion several
> times, and I want to summarize here what I think about Linden
> Lab's 3rd Party Viewer Policy (TVP) that can be found
> here: Policy on Third-Party Viewers | Second Life 
> 
> Under assumption of common sense LL produced guidelines that
> should regulate and control the way people can connect to
> their service, that is the SecondLife grid. Guidelines which
> would be correct under the aspect of common sense and I
> believe LL came from that perspective by initially creating
> that guidelines in form of the 3rd Party Viewer Policy. 
> 
> What went wrong? They gave it in the hands of JohnDoe Linden
> lawyers who obviously missed the subject completley and
> overstepped ridiculously. But let's get down to the roots. 
> 
> Basically there are 2 core things very wrong with it.
> Initially LL requires everyone to comply to the GPL licensing.
> Which is fine as that sets the context. The GPL clearly states
> a developer has no warranty or liability for the code
> whatsover, even if that means ones viewer starts a nuclear war
> against former Soviet Russia or China or both. That clause is
> included in every single file of sourcecode (not the part
> about the Russians or Chinese ). LL explicitely disclaims any
> liability themselves for the resulting world war but then puts
> exactly that liability back on the shoulders of anyone
> developing a viewer. 
> 
> Not only that, by complying to their TPV a developer would
> also accept universal responsibility for all and everything
> "viewer". To be exact, as a developer "You assume all risks,
> expenses, and defects of any Third-Party Viewers that you use,
> develop, or distribute." A viewer does not even need to be
> able or connect to SL for that. 
> 
> In this regard it does not matter if a JohnDoe Linden comments
> on a mailing list or if a legally not binding FAQ tells us
> that this would be only for usage by connecting to
> the SL grid. It is not. TPV in it's current form says "I'm
>

Re: [opensource-dev] Client 2.0 - sidebar (was: Re: Open Development project: extending avatarwearables)

[Rob Nelson]

As an epileptic, let me do say that the viewer has caused "auras"  (sort
of a buzzing in my head that warns me of an impending seizure) and has
caused migraines, particularly due to the GL rendering area getting
"squashed" by the sidebar.  It's also very disorienting to people.


On Wed, 2010-03-24 at 05:55 -0500, Argent Stonecutter wrote:
> Not to disagree with the entirety of your rant, but this bit seems  
> completely off the wall.
> 
> On 2010-03-23, at 21:39, Jonathan Irvin wrote:
> > Not to be rude, but if people are getting vertigo, epilepsy, etc.  
> > from SL...viewer 2.0 isn't going to make a difference.  Viewer 1.23  
> > would have the same effect.  Maybe not in your coveted sidebar, but  
> > it SL in general.  You know it, I know it, everyone knows it.  This  
> > is common knowledge.
> 
> It is? I'd never heard of it before. I don't get vertigo from SL. I do  
> get it from some games, like Descent, and I was getting it from the  
> sudden uncontrolled slewing of the viewport in the 2.0 viewer. But not  
> SL.
> 
> >   LCD monitors nowadays will cause those effects *regardless* of the  
> > application running, so please don't make someone else's illness as  
> > your point in voicing your opinions.
> 
> Um, what? Cite please.
> 
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges


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

Re: [opensource-dev] A note on preserving "NO WARRANTY" for SL TPV developers

[Rob Nelson]

As a person with computer forensics skills:  We aren't supposed to
interpret the law and try and give legal advice, we're only supposed to
secure a crime scene after first responders have arrived, establish a
chain of evidence, and gather, index, and preserve evidence (both
exculpatory and incriminating) related to the original case.  

We're not lawyers, only lab rats to be called into court to be
questioned about the evidence we have provided to both the prosecutor
and the defendant's attourney.

Robert Nelson

On Wed, 2010-03-31 at 17:08 +0100, Morgaine wrote:
> Tayra, your entire post is nothing but a personal statement, with not
> a shred of factual justification even attempted.   Not even once have
> you bothered to quote the actual words written in the TPV and use them
> in your analysis.
> 
> It's great to hear that you're doing forensics.  Now try and apply
> that professional skill here.
> 
> 
> Morgaine.
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, Mar 31, 2010 at 4:29 PM, Tayra Dagostino
>  wrote:
> Maybe is better read what TPV say, not what do you think LL
> mean with TPV (read and apply forensic laws on informatic is
> my job... maybe I can understand better some terms, but isn't
> anyway a reason to this poor victimistic show)
> 
>  
> 
> GPL rights for developers aren't touched, GPL header is in
> each file, you as developer can mod, distribute and do all you
> want under GPL terms. This work for all uses you wantto do
> with the viewer code (limited by GPL), in the moment you say
> your viewer is for Second Life grid of Linden Labs Research
> the relationship isn't anymore from you and your software but
> from you and LL.
> 
>  
> 
> You can write patch and mod the viewer with copybot features
> or other, and connect to JohnSmith Research LtD SuperLife
> grid, nobody say else, but if you want your viewer is listed
> in viewer Ll directory and allowed to connect to Second Life
> grid GPL is out of field, the "rules" are TPV (as for resident
> the rules are CS and TOS). All warranty listed in TPV are
> binded to developer modification, is obvious if a bug is
> pre-existent is out of developer range (a developer have
> responsibility only about what he/she write, is more than easy
> ask compensation if a developer is charged for a bug
> previously written by LL initial source code)
> 
>  
> 
> Developer right are protected by GPL itself, nobody, neither
> LL, can touch it, TPV is a suite of rules between YOU and
> Linden. LL itself cannotmodify GPL license, TPV is only binded
> in relationship from LL and developers than distribute or
> patch or mod something called "viewer for LL second life
> grid" (no software neither GPL involvement).
> 
>  
> 
> You can blame about TPV only if you are going to mod the code
> with bad features
> 
>  
> 
> Is better for all stop this victim roleplay, if you think
> something isn't so clear you can ask to clarify, but TPV is
> totally stranger from GPL, merge with perosnal fantasy what
> not understanded isn't good for nobody.
> 
>  
> 
> Sorry for typo but iPhone keypad isn’t easy to use for long
> email ;)
> 
> 
> -- 
> Sent by iPhone 
> 
> Il giorno 31/mar/2010, alle ore 16.46, Morgaine
>  ha scritto:
> 
> 
> 
> 
> > Tayra, I don't think you understand how law works.
> > 
> > TPV developers cannot appear in a court of law and tell the
> > judge, "Judge, I'm not liable to this plaintiff, because
> > Tayra Dagostino's interpretation of the TPV says that it
> > doesn't apply to me."
> > 
> > That's not how law works.
> > 
> > Instead, law operates by examining THE ACTUAL WORDS THAT ARE
> > WRITTEN in a license or agreement.  And the words that are
> > written in the TPV are the unconscionable and out-of-control
> > mess that has been detailed here extensively, as opposed to
> > the blissful mirage of your wishful thinking.
> > 
> > 
> > Morgaine.
> > 
> > 
> > 
> > 
> > 
> > =
> > 
> > On Tue, Mar 30, 2010 at 4:52 PM, Tayra Dagostino
> >  wrote:
> > TPV is a license to login LL grid with a 3rd party
> > viewer, not about
> > code itself
> > 
> > --
> > Sent by iPhone
> >  

Re: [opensource-dev] A note on preserving "NO WARRANTY" for SL TPV developers

[Rob Nelson]

I really don't care whether Linden Lab has written their TPV trainwreck
in good faith or not.

 * I'm not going to develop a free, opensource viewer if I'm going to be
held liable for it.  I don't have the money to hire a copyright lawyer
to tell a judge/jury that the TPV is complete BS.

 * Linden Lab has no right, written or otherwise, to tell me what I
should add to or remove from my viewer.  If they want to call the shots,
they can give me a job.

 * I'm CERTAINLY not going to interpret their recent lawyering-up and
silence on the matter as good faith, especially when they pushed it out
to us a month early.  

I don't even know why people are still arguing over this.  The TPV goes
against my software's licensing, so users will not use it on SL, period.
Others should realize this too: LL wants a walled garden.  It's time to
move on, develop our own viewers, and break compatibility with a company
that seems hellbent on destroying the very open-source project they have
created.  

I'm working on making voxel-based terrain anyway, both to break
compatibility with SL and just to improve OpenSim instead of arguing
about it on some mailing list forever while LL steamrolls ahead.  Don't
be one of the people they run over.

Rob Nelson ("Fred Rookstown")
Luna Viewer
http://luna.nexisonline.net

On Wed, 2010-03-31 at 23:40 +0200, Dirk Moerenhout wrote:
> I clearly quoted the TPVP and showed what is literally there including
> how cross-references support the interpretation. Your retort which
> doesn't address this in any way clearly shows you are not interested
> in really debating what is written there. Whatever they write in the
> TPVP you'll assume they do it out of bad faith. With such prejudice
> you'll always find something to rant about.
> 
> Funny enough you apparently think the TPVP changes LL's legal position
> and I can assure you it does not. It rather simplifies than mystifies
> as this is about connecting to LL's grid which has been closed and
> theirs all along. If their grid is abused for example for copyright
> violations then they are free to assist in suing you as they please
> with or without the TPVP. I think your analogy of Novell vs SCO is far
> fetched. You're better off comparing this to The Pirate Bay or the
> recent Newzbin ruling.
> 
> I don't ask people to rely on "good faith", I want them to see past
> the paranoia and use common sense. If LL is out to get TPV developers
> then creating the TPVP is a serious waste of time as there are far
> easier ways to do so.
> 
> Dirk
> 
> 
> On 31 March 2010 22:14, Ryan McDougall  wrote:
> > You're out of your mind if you recommend people spend their spare time
> > working on something under no more protection than "good faith". LL
> > has lawyered themselves up nicely; who's legal advice are you taking?
> >
> > SCO was unable to destroy linux because Novell got their rights
> > written down quite clearly and unambiguously. Even then, with the
> > weight of evidence so *clearly* in Novell's favor, the fight itself
> > has cost Novell millions and literally destroyed SCO.
> >
> > And that's the sort of liability you want individuals to bear? Get
> > bent. Seriously. I look forward to you establishing a legal defense
> > fund for TPV developers. Until then...
> >
> ___
> Policies 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] Can you legally agree to incomprehensible conditions?

[Rob Nelson]

How many times must it be said?

The problem isn't that there's people interpreting it.  The problem is
that there's NO ROOM FOR INTERPRETATION.

Section 7a:

> If you are a Developer, you are responsible for all features,
functionality, code, and content of Third-Party Viewers that you develop
or distribute.

I honestly am not going to believe a Linden who's handwaving what is an
OBVIOUS and CLEAR statement simply because we're not lawyers.  I mean,
honestly.  What is a lawyer going to say?  "Oh, by that, they actually
mean you are NOT responsible"?  I HIGHLY doubt that.


On Thu, 2010-04-01 at 09:42 +0100, Morgaine wrote:
> On 21st March, Q Linden explained to us that legalese is not a
> language amenable to "common sense" interpretation, and more
> specifically, that programmers like ourselves should not expect to
> understand this Linden TPV policy document using our normal logic and
> our normal dictionary.  I'll repeat his words here for clarity:
> 
> 
> Kent Quirk (Q Linden) q at lindenlab.com 
> Sun Mar 21 10:24:13 PDT 2010
> 
>   * I'm emphatically not a lawyer and I don't speak for our legal
> team. But:
>   * Legalese is a specialized language. It's not strictly English,
> and it's not always amenable to "common sense" interpretation.
> Think of lawyers as people who write code in an underspecified
> language for a buggy compiler, and you begin to understand why
> legalese is the way it is. There's a lot of law that isn't
> stated, but is actually implied by the context of the existing
> settled law. What that means is that if you're not a lawyer,
> you probably shouldn't be attempting to interpret legal
> documents -- especially not for other people. Similarly, if
> you're not a programmer, attempting to interpret program
> source code is a risky business. Programmers are especially
> susceptible to trying to interpret legal documents using a
> normal dictionary because they're logical thinkers. That
> doesn't always work. If you have legal questions about the
> implication of documents, you should ask a lawyer, not a
> mailing list.
>   * Similarly, any comment by one of Linden's lawyers in this
> forum or any other could possibly be treated as legally
> binding. That also goes for Linden employees, especially those
> with any seniority. So you're unlikely to get further remarks
> or "clarifications", except general statements that don't
> address specific questions. The policy was revised based on
> comments on this list and elsewhere. That's probably a pretty
> good indication that Linden Lab's lawyers now think it's clear
> enough to state its intent and to stand up in court if they
> need it to.
>   * Q
> 
> 
> I've been thinking about this extraordinary post and its relationship
> to our ongoing saga about the TPV, and I fail to see how any rational
> person could agree to something unknown, except under duress.  Is it
> even legal to be required to agree to the incomprehensible?  Does
> anyone know how the law works in this area?
> 
> The GPL license was written by FSF lawyers specifically to be
> understood by programmers, so it's no surprise that the large majority
> of people here understand it. Given that Lindens claim that they are
> issuing a valid GPL license, perhaps one might accept that at face
> value, and assume that GPLv2 clauses 6, 7, 11 and 12 remain intact and
> valid.  Therefore there are no "further restrictions" imposed on SL
> TPV developers (clause 6), and the "NO WARRANTY" clause (11-12)
> continues to protect developers from downstream liability, and no
> "conditions are imposed on you that contradict the conditions of this
> License" thus making the license valid (clause 7).
> 
> Given the forgoing, the officially incomprehensible TPV document then
> no longer matters to SL TPV developers, because their rights and
> freedoms and lack of liability are determined entirely by the GPL.
> (It could be no other way anyway, since we are told that we cannot
> understand the TPV.)
> 
> That leaves only the matter of users of TPVs behaving responsibly when
> they use TPV clients in SL, with which I'm sure every person on this
> list is happy to agree.  (Note that developers become users when they
> connect to SL, and are bound by the same requirements as users.)  When
> users do something bad with a TPV client, or indeed with a Linden
> client, then naturally they are personally responsible for their
> actions.
> 
> In the absence of a TPV document that we can comprehend, perhaps this
> is the best that TPV developers can do, since agreeing to
> incomprehensible conditions is not something that any sensible person
> should consider.
> 
> 
> Morgaine.
> 
> 
> ___
> Policies and (un)subscribe information 

Re: [opensource-dev] Can you legally agree to incomprehensible conditions

[Rob Nelson]

Okay, I'm going to try this one last time.

When users sign into SL for the first time, they are asked to read and
agree to the Terms of Service agreement.  Included in the ToS is the
Community Standards and now the TPV.  *ALL OF THESE DOCUMENTS ARE
SUPPOSED TO BE READ AND AGREED TO BY THE END USER.*  

Saying something like "Well, you're not a lawyer, so how are you
supposed to know what it REALLY means?" is disregarding the fact that
users, NOT LAWYERS, are supposed to understand these documents.  _IF WE
CANNOT UNDERSTAND YOUR DOCUMENTS, WE CANNOT AGREE TO THEM._  No one is
going to be rich enough enough to be able hire a lawyer to translate a
document prior to playing a bloody MMORPG, especially a lawyer who
specializes in copyright law.

Someone commented earlier that the GPL was written in a way that
programmers could understand.  Guess why?  BECAUSE PROGRAMMERS READ THE
GPL AS IT'S AT THE TOP OF EVERY SOURCE-CODE FILE AND IS USUALLY
DISPLAYED ON PROGRAM STARTUP.  End-users typically do not NEED to read
the GPL unless they're interested in distributing or modifying the
sourcecode.

Since the TPV DOES apply to programmers, distributors, and end-users, IT
MUST BE WRITTEN IN A WAY THAT THEY CAN UNDERSTAND.  If I were to make a
ToS written in Chinese and present it to English-speaking users, how are
the users expected to agree to it? 

tl;dr the ToS, TPV, and CS are all rules to be read, understood, and
followed by the end user.  You cannot expect us to go out and hire a
lawyer every time we want to play a new game or develop for an
open-source project.

___
Policies 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] Can you legally agree to incomprehensible conditions

[Rob Nelson]

I have one for working on Voxel terrain (which will also completely
break compatibility with SL).

Lol, losing power.

On Fri, 2010-04-02 at 10:38 -0500, Argent Stonecutter wrote:
> Sounds like an "impure opensim" fork is needed.
> 
> On 2010-04-02, at 08:19, Gareth Nelson wrote:
> 
> > If these people also work on the viewer, they're banned from
> > contributing patches to opensim
> >
> > On Fri, Apr 2, 2010 at 1:40 PM, Carlo Wood  wrote:
> >> What is the reason that those fixes aren't incorporated in "pure"  
> >> opensim?
> 
> ___
> Policies 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] So you don't like the new TOS and wanna move to the OS grid?

[Rob Nelson]

Ha.  

Speaking of colorful, I remember my very first patch ever was a SQL
injection fix for OpenSim's grid services (back when OSG when run from
PHP scripts) that contained a bunch of cursewords I accidentally left in
the comments.

On Sun, 2010-04-04 at 22:46 +0100, Gareth Nelson wrote:
> Probably, but there may again be the whole paranoia over "tainting",
> and some of the instability may be normal developmental issues - stuff
> that crops up in ongoing development of new features. Note that in my
> experience, even a description (without an actual patch or any actual
> code) of how to fix bugs is not accepted - though I have a "colourful"
> history with opensim.
> 
> I'm not up to date on how opensim does QA/testing these days (due
> probably in part to the above mentioned "colourful history"), but i'd
> imagine that in any project a decent set of tests will catch most
> issues, if not all.
> 
> On Sun, Apr 4, 2010 at 10:29 PM, Joel Foner  wrote:
> > This could be a not so bright question, but shouldn't all those patches to
> > fix up OpenSim bugs be ending up back in the trunk and end up with the
> > default downloads working better?
> > Joel
> > On Sun, Apr 4, 2010 at 4:56 PM, Gareth Nelson 
> > wrote:
> >>
> >> The thing with OSGrid is that it was meant from the start to be a
> >> public grid where anyone can link up - and so regions there could be
> >> hosted on a 486 with 64mb of RAM (and loads of swap space on
> >> disk..) connected through a VPN over dialup to a satellite
> >> connection in a stormy climate for all you know.
> >>
> >> For anything serious, it's wise to stick to the core regions which
> >> have professional hosting arrangements (hi cari.net - remember me?) or
> >> one of the many commercial grids cropping up. I'd ask around to find
> >> who's hottest right now, but advise you find one with a server
> >> development team that does their own patching of opensim, as out of
> >> the box it can be very very buggy.
> >>
> >> On Sun, Apr 4, 2010 at 6:55 PM, Glen Canaday  wrote:
> >> > Mmm. There are many grids, all running different server versions. All of
> >> > the web-related stuff like the concurrency, etc., is all client-side and
> >> > has nothing at all to do with OpenSim. It's web data and your client
> >> > wasn't configured to look at any other web page with that data.
> >> >
> >> > In short, it looks like what you saw was something akin to a very, very
> >> > bad wireless connection. I used to have the same things in SL (ping
> >> > times near 20 sec) before I replaced my wireless card. Physics engines
> >> > don't work when you can't participate in the server frames! The
> >> > particular grid you were on could have been served from crap hardware
> >> > and connection. The upshot is that they could serve it at all, and that
> >> > you could connect... but people (like me) often tend to bite off more
> >> > than they can chew at times. You need a good machine and good
> >> > connectivity in order to serve regions - which LL has invested *oodles*
> >> > into.
> >> >
> >> > --GC
> >> >
> >> > On 04/04/2010 02:49 AM, Dale Mahalko wrote:
> >> >> I just tried using the SL 1.x client with OS grid for the first time
> >> >> this weekend. Overall the experience was plain awful, on a 10 megabit
> >> >> internet connection and GTX 285 1024meg
> >> >>
> >> >>
> >> >> Oddly, when giving the SL client the OSgrid URL from the command line,
> >> >> the client login page tells me that the Second Life grid is up, and
> >> >> the number of concurrent users in SL, etc. Why is the client not
> >> >> telling me the status of the OSgrid instead?
> >> >>
> >> >> On first login, the sim textures took forever to load. Like, after 5
> >> >> minutes I'm still standing in a sea of gray boxes.
> >> >>
> >> >> Simple physics only with the ground. All objects are phantom. I'd
> >> >> think the OSGrid default login would want to showcase the
> >> >> collision-resolving capabilities of the more advanced open physics
> >> >> engines, but oh well.
> >> >>
> >> >> When I search for sandboxes to try building stuff... odd, the search
> >> >> window shows me stuff from Second Life, not the OSGrid. Most teleports
> >> >> fail because it appears I'm getting links to SL sims that don't accept
> >> >> connections from OSGrid. Yep, I can find the Cordova Sandbox from the
> >> >> search page within OSGrid. (I don't think search should list sims that
> >> >> don't accept connections.)
> >> >>
> >> >> Searching for "osgrid" in the search window oddly turns up nothing.
> >> >> How am I to find sandbox sims in OSGrid? "Oh, just open the map and
> >> >> pick that way" someone tells me. Yeah that works well. the map shows
> >> >> about a 10x10 grid of sims nearby, but the rest of the map doesn't
> >> >> want to load. Timeout.
> >> >>
> >> >> I did actually manage to find another OSgrid sim to connect to, but on
> >> >> join it turned out to have a ping of 6000. (It would be useful for the
> >> >> search page to show a gra

Re: [opensource-dev] Viewers in the directory are being impersonated already

[Rob Nelson]

Certain griefer viewers already bypass this form of profiling.  I won't
detail how.

Fred Rookstown

On Mon, 2010-04-12 at 16:03 -0700, Erik Anderson wrote:
> Yah, but it might start looking a bit suspicious if it looks like
> you're using computers as one-time pads, always using a different
> system for each connection for a certain account?  Might not be as
> easily detectable for the short-term accounts that get banned within
> minutes, but anything with history would stick out fairly obviously.
> 
> On Mon, Apr 12, 2010 at 2:07 PM, Dale Glass 
> wrote:
> В сообщении от Вторник 13 апреля 2010 00:52:48 вы написали:
> > There's still other facets.  For example, the approved
> viewers get some
> > publicity and reputation by being on the approved viewers
> page, and it
> >  makes people think that much harder about using sketchy
> viewers to do
> >  sketchy things.  (And yeah, they have to do one extra
> sketchy thing, as
> >  Thomas mentions.)
> 
> I don't think it makes a big difference.
> 
> I'm talking about a group with a "FOR THE LULZ!" motto. I
> don't think they
> care much about keeping any account of theirs for very long.
> 
> >
> > (As an aside, connecting from the same account and/or same
> IP with random
> > MACs seems pretty obviously strange and detectable.  There's
> a few more
> > hoops left to jump through there.)
> 
> That will take some work though. At my house there are 5
> computers that could
> run a SL client, that's 5 MACs, all behind the same NATed IP
> address. Schools,
> workplaces, cafes, etc could have hundreds of legitimate ones.
> 
> 
> ___
> Policies 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] Requesting Linden Response: Please move TPVP Topics to a different mailing list

[Rob Nelson]

It's already reached a point where LL has told us, to our faces, that
they are not going to change the policy, meaning our opinion doesn't
mean diddly to them.  There's no use continuing to discussion, just as
there's no use continuing TPV development.


On Wed, 2010-04-14 at 07:52 -0500, Jonathan Irvin wrote:
> To Whom It May Concern:
> 
> I'm requesting Linden Lab's response to this inquiry due to the recent
> influx of new topic related...or should I say unrelated to the
> development of the SnowGlobe viewer.  Lately, when I open my email, I
> get 5-10 different topics and responses daily to the recent changes
> for the Third Party Viewer policy and I feel that this is not related
> to SnowGlobe or related development at all.
> 
> To "clear the pipes", can we please move these discussions to a
> different forum or list so valid OpenSource development questions are
> not lost in the flames, complaints, and discussions related to this
> specific topic?
> 
> I do not feel it is valid in this forum to talk about which
> Third-Party Viewers in the directory were already impersonated or
> which part of the third party viewer policy they do not like.
> 
> Linden Labs, if you can please isolate this to another forum, I bet
> those who are truly interested in the opensource development of the
> Second Life viewer would be more in tuned to staying here rather than
> wake up to read yet another unproductive "I hate LL and the TPVP lets
> get together and share our misery post".
> 
> Respectfully & Best Regards,
> 
> Jonathan Irvin
> SL Resident of 5 Years.
> ___
> Policies 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] Requesting Linden Response: Please move TPVP Topics to a different mailing list

[Rob Nelson]

Yes, I begin sleep at 6:00AM and frequently sleep until 2:30PM.

On Wed, 2010-04-14 at 09:27 -0700, Joe Linden wrote:
> Rob,
> 
> I take it you weren't at the meeting yesterday?
> 
> -- Joe
> 
> On Wed, Apr 14, 2010 at 9:02 AM, Rob Nelson
>  wrote:
> It's already reached a point where LL has told us, to our
> faces, that
> they are not going to change the policy, meaning our opinion
> doesn't
> mean diddly to them.  There's no use continuing to discussion,
> just as
> there's no use continuing TPV development.
> 
> 
> 
> On Wed, 2010-04-14 at 07:52 -0500, Jonathan Irvin wrote:
> > To Whom It May Concern:
> >
> > I'm requesting Linden Lab's response to this inquiry due to
> the recent
> > influx of new topic related...or should I say unrelated to
> the
> > development of the SnowGlobe viewer.  Lately, when I open my
> email, I
> > get 5-10 different topics and responses daily to the recent
> changes
> > for the Third Party Viewer policy and I feel that this is
> not related
> > to SnowGlobe or related development at all.
> >
> > To "clear the pipes", can we please move these discussions
> to a
> > different forum or list so valid OpenSource development
> questions are
> > not lost in the flames, complaints, and discussions related
> to this
> > specific topic?
> >
> > I do not feel it is valid in this forum to talk about which
> > Third-Party Viewers in the directory were already
> impersonated or
> > which part of the third party viewer policy they do not
> like.
> >
> > Linden Labs, if you can please isolate this to another
> forum, I bet
> > those who are truly interested in the opensource development
> of the
> > Second Life viewer would be more in tuned to staying here
> rather than
> > wake up to read yet another unproductive "I hate LL and the
> TPVP lets
> > get together and share our misery post".
> >
> > Respectfully & Best Regards,
> >
> > Jonathan Irvin
> > SL Resident of 5 Years.
> 
> 
> > ___
> > Policies 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] Requesting Linden Response: Please move TPVP Topics to a different mailing list

[Rob Nelson]

I decided to read the transcript and it did not address any of my
concerns.  

[12:21][Voice Transcript] Joe Linden: we've ha a lot of internal debate
around cost/benefit of OS

^ That was all I needed to hear.  Debate's effectively over.

On Wed, 2010-04-14 at 09:27 -0700, Joe Linden wrote:
> Rob,
> 
> I take it you weren't at the meeting yesterday?
> 
> -- Joe
> 
> On Wed, Apr 14, 2010 at 9:02 AM, Rob Nelson
>  wrote:
> It's already reached a point where LL has told us, to our
> faces, that
> they are not going to change the policy, meaning our opinion
> doesn't
> mean diddly to them.  There's no use continuing to discussion,
> just as
> there's no use continuing TPV development.
> 
> 
> 
> On Wed, 2010-04-14 at 07:52 -0500, Jonathan Irvin wrote:
> > To Whom It May Concern:
> >
> > I'm requesting Linden Lab's response to this inquiry due to
> the recent
> > influx of new topic related...or should I say unrelated to
> the
> > development of the SnowGlobe viewer.  Lately, when I open my
> email, I
> > get 5-10 different topics and responses daily to the recent
> changes
> > for the Third Party Viewer policy and I feel that this is
> not related
> > to SnowGlobe or related development at all.
> >
> > To "clear the pipes", can we please move these discussions
> to a
> > different forum or list so valid OpenSource development
> questions are
> > not lost in the flames, complaints, and discussions related
> to this
> > specific topic?
> >
> > I do not feel it is valid in this forum to talk about which
> > Third-Party Viewers in the directory were already
> impersonated or
> > which part of the third party viewer policy they do not
> like.
> >
> > Linden Labs, if you can please isolate this to another
> forum, I bet
> > those who are truly interested in the opensource development
> of the
> > Second Life viewer would be more in tuned to staying here
> rather than
> > wake up to read yet another unproductive "I hate LL and the
> TPVP lets
> > get together and share our misery post".
> >
> > Respectfully & Best Regards,
> >
> > Jonathan Irvin
> > SL Resident of 5 Years.
> 
> 
> > ___
> > Policies 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] Requesting Linden Response: Please move TPVP Topics to a different mailing list

[Rob Nelson]

And yet, it does restrict GPL distribution rights.  We've been over this
already.  And I'd like to see where the FSF OKed it, the only thing I
can turn up on Google is Richard Stallman not being too happy about it.

I already changed the viewer I used to be working on to Luna, but both
the GPL incompatabilities and this rather infuriating "cost/benefit"
comment by Joe have resulted in me deciding that LL does not deserve any
further OSS development work from me.


On Wed, 2010-04-14 at 14:11 -0400, Ron Festa wrote:
> Honestly I tried looking through my inbox to find out what your
> concerns were and why no one else addressed them so forgive me if I
> couldn't find them. The only problems I saw you had was compatibility
> with the GPLv2 and the use of "Life" in your viewer name. 
> 
> 
> The issues with Section 7 were in fact addressed and took up most of
> the meeting. Someone claimed they went as far as bringing the TPVP
> before the FSF to verify if its GPLv2 compliant and sadly according to
> them it is as its restricting a service not the code. Never the less
> concerns were brought up and productive changes were suggested.
> 
> 
> As for the branding this should be no argument. If in a court of law
> they can make Lindows change their name to Linspire because Microsoft
> owns *indows then LL can do the same with all the TPV's as stupid as
> that is.
> 
> 
> If these aren't your only concerns please share them so some of us can
> deliver them by proxy for you since the time zone difference seems to
> be the biggest problem for you.
> 
> 
> Ron Festa
> Virtual Worlds Admin
> Division of Continuing Studies at Rutgers University
> PGP key: http://bit.ly/b1ZyhY
> Phone: 732-474-8583
> 
> 
> On Wed, Apr 14, 2010 at 1:23 PM, Rob Nelson
>  wrote:
> I decided to read the transcript and it did not address any of
> my
> concerns.
> 
> [12:21][Voice Transcript] Joe Linden: we've ha a lot of
> internal debate
> around cost/benefit of OS
> 
> ^ That was all I needed to hear.  Debate's effectively over.
> 
> On Wed, 2010-04-14 at 09:27 -0700, Joe Linden wrote:
> 
> 
> > Rob,
> >
> > I take it you weren't at the meeting yesterday?
> >
> > -- Joe
> >
> > On Wed, Apr 14, 2010 at 9:02 AM, Rob Nelson
> >  wrote:
> > It's already reached a point where LL has told us,
> to our
> > faces, that
> > they are not going to change the policy, meaning our
> opinion
> > doesn't
> > mean diddly to them.  There's no use continuing to
> discussion,
> > just as
> > there's no use continuing TPV development.
> >
> >
> >
> > On Wed, 2010-04-14 at 07:52 -0500, Jonathan Irvin
> wrote:
> > > To Whom It May Concern:
> > >
> > > I'm requesting Linden Lab's response to this
> inquiry due to
> > the recent
> > > influx of new topic related...or should I say
> unrelated to
> > the
> > > development of the SnowGlobe viewer.  Lately, when
> I open my
> > email, I
> > > get 5-10 different topics and responses daily to
> the recent
> > changes
> > > for the Third Party Viewer policy and I feel that
> this is
> > not related
> > > to SnowGlobe or related development at all.
> > >
> > > To "clear the pipes", can we please move these
> discussions
> > to a
> > > different forum or list so valid OpenSource
> development
> > questions are
> > > not lost in the flames, complaints, and
> discussions related
> > to this
> > > specific topic?
> > >
> > > I do not feel it is valid in this forum to talk
> about which
> > > Third-Party Viewers in the directory were already
> > impersonated or
> > > which part of the third party viewer policy they

Re: [opensource-dev] Requesting Linden Response: Please move TPVPTopics to a different mailing list

[Rob Nelson]

The TPV has no differentiation between source code and binary.  The GPL
requires sourcecode distribution anyway.  He's in the wrong and I
suspect he knows it.

Also, to be quite frank, contracts that are designed to be displayed
whenever the user logs into a service should be written so it is clear
to the *user* what their responsibilities and restrictions are.  If you
want to have a "legalese" version, it should be attached as a "more
detailed" link for the lawyers to look at.  No one is going to hire a
lawyer just to look at an e-document every damn time they sign into a
bloody game.  

Fred Rookstown

On Thu, 2010-04-15 at 18:12 -0400, Michael Daniel wrote:
> VR Hacks wrote:
> >> I mean you can't legally be held liable for users who refuse to follow a 
> >> contract they made with you, can you?
> >> 
> >
> > Sure you can. After all, if you write malicious code, you know you're doing 
> > it. 
> I stand corrected, then.  I wasn't really talking about malicious code, 
> though.  I was just talking about protection from the worst-case 
> scenario where a client has an unintended bug in it that causes rolling 
> restarts, then LL comes after the 3rd party dev for damages.  I meant to 
> talk about incompetent coders, not malicious coders (I know that none of 
> the coders on this mailing list fit either description, but it's still 
> something to think about).  Even LL sidesteps liability for damages done 
> by the official viewer, so why shouldn't 3rd party devs try to do the 
> same thing?
> 
> On a different subject:  Is Fractured Crystal correct in the following 
> video when he says that he is not breaking TOS with the Onyx viewer 
> because he only distributes the source code and not the binaries of it?
> 
> http://www.youtube.com/watch?v=SRbV9SIbdCA&feature=player_embedded 
> 
> 
> Thanks,
> ~Bubblesort Triskaidekaphobia
> 
> ___
> Policies 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] Interested in Terrain Advancement

[Rob Nelson]

I'm personally working on Voxel terrain, got most of the opensim
framework down, trying to find a place to upload to the code to though.

Using Minecraft's generation algorithms, with the author's permission.

Fred Rookstown.

On Fri, 2010-04-23 at 13:26 -0700, Dzonatas Sol wrote:
> There does seem to be a collective feel that the terrain needs to 
> upgraded somehow. Even a Linden suggested maybe a way to override it if 
> the builder choses, like with sim sized mega prims.
> 
> My first concern is LOD. The constant changes of LOD on the terrain make 
> the appearance the terrain unnatural and unstable. There are times where 
> we spend lots of time to get the terrain to look just perfectly aligned 
> with other objects nearby. When one decides to walk away 20m, 40m, 60m, 
> however, the perfect alignment becomes a prefect fashion statement for a 
> drunk bulldozer. The hard work undertaken to detail the alignment of the 
> terrain seems like a complete loss.
> 
> As I've used other renders, lets pick on Call of Duty, the terrain is 
> pretty stable even at a distance. It has to be. The mere jump of LOD in 
> the terrain could mean a way to cheat in Deathmatch sniper rounds. You 
> know how snipers love to crawl around the terrain. That kind of 
> stableness doesn't happen when the drunk bulldozer decides to 
> rearrangement the landscape every frame you move. Call of Duty uses the 
> Source Engine, yet this isn't a 'lets all switch over to the Source 
> Engine' rant. It is a use-case that shows that even on old steampunk 
> video cards there still have the coal to burn up the pixels and display 
> a stable landscape. The use-case means, bottomline, it is possible.
> 
> Maybe a baby-step solution is just to have an option to turn-off the LOD 
> for the current sim, and maybe nearby sims. The problem here, maybe, is 
> that the changes to add vertex limits would be affected by this. It 
> might not be all that simple like it was in the past without the vertex 
> limits. Therefore, there would need to be separate vertex limits: one 
> for the terrain and the rest for objects.
> 
> Here is another use-case with a collada file: Lets say I have a collada 
> file that contains a very detailed structure of a volcano (terrain 
> only).  The volcano is 1km wide. That crosses several 256m sims. There 
> are lava tunnels that lead inside.
> 
> The suggested solution was to use a sim sized mega-prim. To do that with 
> scuplties would be hard for more than just looks. Sculpties need to 
> calculate all the phsyics, yet the collada file could have that already 
> detailed and compiled with the file.
> 
> How do we do this with the stock viewer even if we used sculpties? The 
> stock viewer doesn't include a "sit on this object here like one sits on 
> land now anywhere" option. If we used a mega-prim, it would disabled the 
> ability to sit anywhere on the terrain.
> 
> The other idea is to import a terrain, which is an available feature. 
> That doesn't allow us to have multiple height maps, like lava tubes. If 
> a lava tube crossed a sim to another, there would be a hole in the 
> terrain in one sim. There current terrain engine doesn't allow holes. 
> Multiple height maps would allow us to have holes in the terrain. The 
> physics detail of a scupltie bent to make that hole doesn't preform (and 
> I don't mean just frame optimization.. I mean like how a skirt clearly 
> either looks good or not when you sit down kind of 'preform'.)
> 
> So, maybe the solution include that baby step.. to allow multiple height 
> map layers. A Lava tube could be done with three layers. One for the 
> bottom of the tunnel. One for the top. And one for the side of the 
> volcano above the tunnel. There would be needed an extra feature with 
> the height map to allow empty spaces, to allow where the tunnel opens 
> into the side of the volcano.
> 
> So, before we even digress into the advantages of collada refineries, it 
> seems the first two baby steps would be to fix LOD and allow an 
> arbitrary number of terrain layers.
> 
> I would like to see what others think about this.
> 
> ___
> Policies 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] Where to report selling of "Ripper" Viewers?

[Rob Nelson]

Unfortunately, don't expect much luck with this.  I reported an inworld
store for a copybot (it even had the gall to say the developers ran it
past the LL legal team) and it's still there after more than 3 weeks.
Even if LL took down the inworld store, there's still a website, where
LL doesn't really have jurisdiction.

Fred

On Mon, 2010-04-26 at 07:45 -0700, David Simmons wrote:
> Use the inworld abuse report. If you do not know the sl name of the
> person selling the viewer use one of your favorite lindens name as the
> abuser (blue linden used to love getting his name listed) and put all
> the details into the comment section.
> 
> On 4/26/10, Lance Corrimal  wrote:
> > Am Montag, 26. April 2010 16:08:11 schrieb Daniel:
> >> I came across a site selling SL viewers designed to steal content, and I
> >> want to report it to the right Linden Research staff to deal with, but I
> >> am not sure who that would be.  Pointers would be helpful.
> >> ___
> >> Policies and (un)subscribe information available here:
> >> http://wiki.secondlife.com/wiki/OpenSource-Dev
> >> Please read the policies before posting to keep unmoderated posting
> >> privileges
> >
> > I believe an email to LL legal department would be in order.
> >
> >
> > bye,
> > LC
> > ___
> > Policies and (un)subscribe information available here:
> > http://wiki.secondlife.com/wiki/OpenSource-Dev
> > Please read the policies before posting to keep unmoderated posting
> > privileges
> >
> 
> 


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

Re: [opensource-dev] Viewer blacklist to replace the TPV directory ?

[Rob Nelson]

This is a bad idea, as the TPV violators would merely migrate to a
non-blacklisted viewer.

On Thu, 2010-04-29 at 12:01 +0200, Henri Beauchamp wrote:
> On Thu, 29 Apr 2010 09:10:33 +, Opensource Obscure wrote:
> 
> > On Thu, 29 Apr 2010 10:56:58 +0200, Henri Beauchamp  wrote:
> > 
> > > Instead of a white list for which Linden Lab actually guarantees
> > > nothing and to which some developers won't be able to register anyway
> > > because of privacy and local Law concerns, why not making a black
> > > list ?
> > > 
> > > The black list would contain the viewer names of right out illegal
> > > viewers or not yet TPV-policy compliant viewers
> > 
> > this doesn't looks like a practical solution to me, as nobody 
> > could ever mantain such a list up-to-date.
> 
> Of course yes... What kind of list do you thing Linden Lab will maintain
> to block access to SL after the 30th ?... It's in fact just about making
> their black list public.
> 
> 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


___
Policies 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] Oh, the drama. (was: Viewer blacklist...)

[Rob Nelson]

As a person who is trying to patch (a now rather old version) of OpenSim
to handle voxel terrain, there's MANY, MANY flaws to the messaging
subsystem of both the viewer and the server.  

For one, I wanted to tack on an additional UDP/TCP message to handle
voxelmap transmissions and modification.  Unfortunately, it appears that
even a tiny change to the messaging template would completely destroy
compatibility with SL, and even adding one packet handler in OpenSim
would involve changing LibOMV, 3 packet handling packages, and an
extremely long PacketType enum.  This is NOT a flexible protocol that
we're using.  

In order to retain compatibility with "legacy" viewers that only support
heightmap terrains, I'm having to add in additional capabilities to
OpenSim and the viewer, which I don't like, as HTTP transports are going
to be godawfully slow, particularly when adding, removing or modifying
voxels.

On Fri, 2010-04-30 at 21:00 +1000, Tateru Nino wrote:
> The most obvious solution - from where I'm sitting - is to abstract it,
> and provide different access methods underneath. The higher levels of
> the viewer application should neither know nor care just where the map
> tiles are coming from, beyond making an API call to fetch one. Later,
> one can look at a method by which a grid service might make certain
> representations as to where and how those tiles are located and to be
> fetched, but compartmentalizing the hard-wired knowledge (at this stage)
> seems to be the best option, presently.
> 
> On 30/04/2010 8:20 PM, Lance Corrimal wrote:
> > "patching opensim"...
> >
> > ...how do you "patch" the people who provide a service for free, to make 
> > them 
> > rent an expensive distributed storage provider for their map tiles?
> > are you going to rent S3 yourself, for your own little local grid?
> >
> >
> >
> > bye,
> > LC
> >
> > Am Freitag, 30. April 2010 11:23:59 schrieb Brandon Husbands:
> >   
> >> Perhaps patching open sim to use the new way? probably the best route to go
> >> as it needs to keep up with com changes in the main viewer.
> >>
> >> On Fri, Apr 30, 2010 at 4:04 AM, Lance Corrimal
> >>
> >> wrote:
> >> 
> >>> Am Freitag, 30. April 2010 10:47:27 schrieb Brandon Husbands:
> >>>   
>  I agree. Thats what i have been trying to say... sighs... Can we get
>  back to discussing code now?
>  
> >>> with pleasure.
> >>>
> >>>
> >>> any ideas about making SG 1.4 fully opensim-compatible by adding the
> >>> "old" way
> >>> to fetch map tiles?
> >>>
> >>>
> >>> bye,
> >>> LC
> >>>
> >>>   
>  On Fri, Apr 30, 2010 at 3:46 AM, Lance Corrimal
> 
>  wrote:
>  
> > for crying out loud, could you guys PLEASE move the remainder of that
> > "discussion" to a more suited medium, the "Under the bridge" forum on
> > second
> > citizen comes to mind.
> > ... where the trolls are.
> > http://www.secondcitizen.net/Forum/forumdisplay.php?f=18
> > ___
> > Policies 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
> >
> >   
> 


___
Policies 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] Banning by client

[Rob Nelson]

The only way to reliably detect a client is if the client sends an MD5
hash of the executable to the login server, and that function was
removed ages ago from the login process due to ease of spoofing.

Requiring a unique login channel requires manual intervention to change
the login channel from the official LL channel to the unique one
required by the TPV, so malicious developers don't even have to lift a
finger in order to bypass detection.  

The entire system is flawed, and I'm sure LL knows this.

On Sun, 2010-05-02 at 20:56 +0200, Carlo Wood wrote:
> On Sat, May 01, 2010 at 06:53:49PM -0400, Glen Canaday wrote:
> > Though WHY anyone wouldn't want to come HERE to talk about client 
> > detection is far beyond my grasp. That's like AVG not wanting to talk to 
> > Microsoft.
> 
> Probably because it's a moronic asshole, who is only 
> interested in making money with the product and doesn't
> care if 1% are false positives.  Not until LL comes
> knocking on their door anyway.
> 
> I guess that the only reasonable response (unless LL
> wants to get involved) is to find out how the detection
> works and write a patch that makes SURE it won't be
> detected (which then can be used by everyone, but malicious
> viewers will do this anyway, whether or not we do or not).
> 
> So, how does this thing "detect" the mentioned "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] [POLICY] Configurable HTTP user-agent string

[Rob Nelson]

On Tue, 2010-05-04 at 20:48 -0300, Tigro Spottystripes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Is the internal browser considered the viewer itself or can it have it's
> own identifier?
>From what I remember, it uses something like Second Life Viewer/VERSION
(Mozilla 4.0...)

>  And is the user agent string of the internal browser
> *the* unique viewer identifier mentioned in the TPVp?
No, the TPV speaks of the viewer login channel.  By default, it uses
Second Life Development.  Emerald uses Emerald Viewer, Luna uses Luna
Viewer (I think, it's been a while since I dug around in the code).  The
login channel was originally intended to keep OSS viewers from receiving
official viewer updates.

>  Are we gonna have
> to hire a lawyer to get these questions answered?
If past history of trying to get similar questions answered counts, then yes.  

> On 4/5/2010 20:41, Boroondas Gupte wrote:
> > On 05/04/2010 10:57 PM, Ricky wrote:
> >> [...] we could easily add some functions into our various viewers to 
> >> change the string into
> >> whatever we choose it to be. Again, just like browser useragents.
> >>   
> > Would that be allowed under TPVp section 2.
> > c.ii?
> > 
> > "You must not spoof the viewer identifier or the identity of a
> > Third-Party Viewer connecting to Second Life. Each version of a
> > Third-Party Viewer must have a unique viewer identifier and must not
> > use the same viewer identifier as a Linden Lab viewer or another
> > Third-Party Viewer."
> > 
> > Boroondas
> > 
> > 
> > 
> > ___
> > Policies 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.14 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEAREKAAYFAkvgslkACgkQ8ZFfSrFHsmWX1QCcDVH2V6fdAWj+cGFXhxCvqOSx
> 8c0An2/dWHyCSSGH/s/ouq5FtSueM6dq
> =6mbF
> -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] Migrating open development focus to 2.x

[Rob Nelson]

I think the multitude of polls on the subject makes it clear that many,
many people just hate the UI but would be perfectly fine back-porting
some of the features (web-on-a-prim, tattoos, etc) to 1.x.  

In fact, when I last used 2.0, I got what we epileptics call an "aura",
which is a warning sign that a seizure is coming.  I had to close the
app and take an extra dose of my medication to avoid the seizure.
Therefore, it's just not a possibility for me to use.  

I realize LL has been working on 2.0's UI, removing the "squish" effect
of the sidebar that may have caused many epileptics to report auras or
seizures, but I think it would be safer for me to just stay away from
2.0.  I would, after all, like to be able to use my driver's license
this summer. :|

Fred Rookstown

On Thu, 2010-05-27 at 17:50 -0400, Oz Linden (Scott Lawrence) wrote:
> I opened this in the 27 May IW open source meeting, and would like to 
> invite wider and more specific feedback.
> 
> It's fairly clear that Linden Lab doesn't have the resources to devote 
> to active work on both Snowglobe 1.x and 2.x, and it's not efficient for 
> the community as a whole to be splitting effort.
> 
> I'd like to fairly quickly get to the point where all our new work is 
> happening on the 2.x branch.  That said, I understand that might leave 
> behind things that the Snowglobe user/dev base wants and that some 
> people are not happy with some elements of 2.x.  What I'd like to know 
> is... what needs to happen to make that choice that most people can be 
> happy with?
> 
> One of my goals is to increase the rate and volume at which Linden Lab 
> can (and _does_) take changes from the open source base into the 
> internal code, but unless we can keep everyone on the same branch, that 
> will be much more difficult.
> 
> Please respond to this thread with your favorite reasons not to move 
> development to 2.x.   We will review the list at the 6 June open source 
> meeting with the goal of setting some priorities.
> 
> 
> 
> To be clear... I don't object to anyone else working on 1.x at all; I'd 
> just like to know why so that we can tempt them to join us on 2.x
> 
> ___
> Policies 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

[opensource-dev] Mesh rendering: What does indicesp provide?

[Rob Nelson]

I am almost to the point of going crazy.  I was going to write a
notecard to a Linden, but I've been knocked out of SL for reasons
unknown, so I'll have to ask here.

In my infinite lack of wisdom, I decided to start working on a project
where I replace the heightmap terrain in Second Life with one based on
voxels.  To get to the core of the reasoning behind this switch so I
don't spend too much time on it:

 * Voxel-based land allows creation of overhangs/caves/floating chunks
of land (not possible with heightmaps)
 * Also adds the ability to handle up to 255 terrain materials
(textures, eventually detail shaders) instead of 4, and the materials
are placed where desired instead of at fractional heights.

I am working on the rendering code in the SL viewer at the moment,
having completed the server-side code and some of the client-side
packet-handling classes.  However, I have zero familiarity with OpenGL,
so bear with me.

My viewer needs to construct a terrain surface (a mesh) for display.  I
have completed an LLViewerObject to this end, except for:

::getGeometry(LLStrider &verticesp,
LLStrider &normalsp,
LLStrider &colorsp,
LLStrider &texCoords0p,
LLStrider &texCoords1p,
LLStrider &indicesp)

What is confusing me is indicesp.  I think it has something to do with
connecting vertices, but I'm not sure how.  The example code I am
working with uses a mess of lookup tables in the following loop for each
voxel:

//Draw the triangles that were found.  There can be up to five per cube
for(iTriangle = 0; iTriangle < 5; iTriangle++)
{
if(a2iTriangleConnectionTable[iFlagIndex][3*iTriangle] < 0)
break;

for(iCorner = 0; iCorner < 3; iCorner++)
{
iVertex =
a2iTriangleConnectionTable[iFlagIndex][3*iTriangle+iCorner];

vGetColor(sColor, asEdgeVertex[iVertex],
asEdgeNorm[iVertex]);
glColor4f(sColor.fX, sColor.fY, sColor.fZ, 0.6);
glNormal3f(asEdgeNorm[iVertex].fX,
asEdgeNorm[iVertex].fY,   asEdgeNorm[iVertex].fZ);
glVertex3f(asEdgeVertex[iVertex].fX,
asEdgeVertex[iVertex].fY, asEdgeVertex[iVertex].fZ);
}
}

Can anyone give me any pointers on getting this converted?  

Thanks.

Rob

___
Policies 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] Mesh rendering: What does indicesp provide?

[Rob Nelson]

Thanks, I've successfully converted the code.  I appreciate the
perspective.  

Thanks again,

Rob

On Thu, 2010-06-03 at 07:53 -0400, Zabb65 wrote:
> >From what I remember...
> 
> Indicesp is a pointer to an array of U16s that are offsets to vertexes
> in the vertex buffer. Read it as the vertexes normals and all this
> other stuff being in static arrays. It then runs through the indice
> list and runs the associated glVertex3f commands or whatever on the
> vertex at the specified index on the array. This is done for all data
> types.
> 
> vector verts;
> vector colors;
> vector normals;
> U16 indices[3] = {0, 1, 2, 1};
> 
> for(U16 i = 0; i < 3; ++i)
> {
> U16 x = indices[i];
> 
> glColor4f(colors[x].mV[0],colors[x].mV[1],colors[x].mV[2],colors[x].mV[3]);
> 
> glNormal3f(normals[x].mV[0],normals[x].mV[1],normals[x].mV[2]);
> glVertex3f(verts[x].mV[0],verts[x].mV[1],verts[x].mV[2]);
> }
> 
> Is the most simple example I can think of that would demonstrate how
> it works internally.
> 
> In the code example you have, the vertexes are drawn one by one in
> immediate mode, which is both slow, and undesired. You will have to do
> some research into using proper vertex buffers to properly convert the
> code.
> 
> On Wed, Jun 2, 2010 at 19:35, Rob Nelson
>  wrote:
> I am almost to the point of going crazy.  I was going to write
> a
> notecard to a Linden, but I've been knocked out of SL for
> reasons
> unknown, so I'll have to ask here.
> 
> In my infinite lack of wisdom, I decided to start working on a
> project
> where I replace the heightmap terrain in Second Life with one
> based on
> voxels.  To get to the core of the reasoning behind this
> switch so I
> don't spend too much time on it:
> 
>  * Voxel-based land allows creation of
> overhangs/caves/floating chunks
> of land (not possible with heightmaps)
>  * Also adds the ability to handle up to 255 terrain materials
> (textures, eventually detail shaders) instead of 4, and the
> materials
> are placed where desired instead of at fractional heights.
> 
> I am working on the rendering code in the SL viewer at the
> moment,
> having completed the server-side code and some of the
> client-side
> packet-handling classes.  However, I have zero familiarity
> with OpenGL,
> so bear with me.
> 
> My viewer needs to construct a terrain surface (a mesh) for
> display.  I
> have completed an LLViewerObject to this end, except for:
> 
> ::getGeometry(LLStrider &verticesp,
>LLStrider &normalsp,
>LLStrider &colorsp,
>LLStrider &texCoords0p,
>LLStrider &texCoords1p,
>LLStrider &indicesp)
> 
> What is confusing me is indicesp.  I think it has something to
> do with
> connecting vertices, but I'm not sure how.  The example code I
> am
> working with uses a mess of lookup tables in the following
> loop for each
> voxel:
> 
>//Draw the triangles that were found.  There can be up
> to five per cube
>for(iTriangle = 0; iTriangle < 5; iTriangle++)
>{
> 
>  if(a2iTriangleConnectionTable[iFlagIndex][3*iTriangle] < 0)
> break;
> 
>for(iCorner = 0; iCorner < 3; iCorner++)
>{
>iVertex =
> a2iTriangleConnectionTable[iFlagIndex][3*iTriangle+iCorner];
> 
>vGetColor(sColor, asEdgeVertex[iVertex],
> asEdgeNorm[iVertex]);
>glColor4f(sColor.fX, sColor.fY, sColor.fZ,
> 0.6);
>glNormal3f(asEdgeNorm[iVertex].fX,
> asEdgeNorm[iVertex].fY,   asEdgeNorm[iVertex].fZ);
>glVertex3f(asEdgeVertex[iVertex].fX,
> asEdgeVertex[iVertex].fY, asEdgeVertex[iVertex].fZ);
>}
>}
> 
> Can anyone give me any pointers on getting this converted?
> 
> Thanks.
> 
> Rob
> 
> ___
> Policies 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] Mesh rendering: What does indicesp provide?

[Rob Nelson]

It may be quite fast, but I don't think it's GPL, so I can't really use
it.  I'll have to come up with my own MacGyver'd implementation of LOD
and stitching after I finish the initial implementation.

Rob
On Thu, 2010-06-03 at 11:42 -0500, Jonathan Goodman wrote:
> It may be a bit late for this, but I would actually like to point out
> a paper that was recently released that details the construction of
> terrain from voxels in the C4 Game Engine (1.5.9, and the LOD
> algorithms introduced in C4 2.0 that was released a few days ago).
>  The implementation in place in C4 is quite fast, to the point it's
> quite suitable for realtime deformations of terrain.  It details the
> construction, Level of Detail, material handling for per-pixel
> lighting, and to some extent the editing tools available in C4 for
> voxel terrain editing.
> http://www.terathon.com/lengyel/Lengyel-VoxelTerrain.pdf
> ___
> Policies 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] the last press release...

[Rob Nelson]

Babbage was apparently let go as well. Goodbye to C# scripting.

Rob

On Thu, 2010-06-10 at 11:16 -0400, Gigs wrote:
> Apparently Zero has been fired as well?  I guess that means interop and 
> all the standards stuff is dead.
> ___
> Policies 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] Malicious payloads in third-party viewers: is the policy worth anything?

[Rob Nelson]

  (Replied offlist by accident.)

  Funny how you allow Phox and crew to continue operating after they
purposefully leak info and attack a website, and then you ban me for
running a freakin' rental company to help pay a friend's bills.

Get your priorities straight and either enforce ALL of your rules for
EVERYONE, or don't enforce them at all.

Rob
The guy who used to develop Luna before he got banned and started making
crap for Minecraft instead.

On 8/21/2010 8:34 AM, Brian McGroarty wrote:
>  On Sat, Aug 21, 2010 at 8:24 AM, Discrete Dreamscape
> wrote:
>>  Actually, I prefer to remember him as:
>>
>>  1) The guy who hacked Emerald's servers before discovering the data
>>  storage issue and
>>
>>  2) The active developer of a malicious viewer under the lolguise of
>>  promoting exploit/bugfixing.
>>
>>  But hey, they keep antagonizing him, so of course this kind of thing 
>> continues.
>  Yeah, he's no saint from these or a hundred other things said about
>  him. Ditto the Emerald leadership. For us though, the problem begins
>  if a pissing match extends to SL or resis' use of SL.
>

___
Policies 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] Malicious payloads in third-party viewers: is the policy worth anything?

[Rob Nelson]

  They used a custom build of the KDU JPEG compression library to embed 
information in baked textures, such as the installation directory and 
the title of the window.  The outrage around this is that Emerald 
developers:

1. Disclosed private information without informing users about the 
disclosure in their privacy policy (installation folder can contain the 
username, usually on Linux, though).
2.  Obfuscated this system by hiding it within a closed-source library
3. Continued to lie about the purpose of this system.
4. LINDEN LAB CONTINUES TO IGNORE THE TPV VIOLATIONS. If I had pulled 
this crap with my tiny viewer, I'd have been banned back into the stone 
age.  The double standard Linden Lab uses infuriates many who were 
forced to do many difficult changes to comply with the TPV, only to find 
out that Linden Lab has no intention of enforcing it.
5. Reportedly, Emerald merely changed the encryption method used when it 
was discovered.  I don't even know if they changed their KDU library to 
comply yet, or if they're covering their bums still by making a storm of 
apologetic blog posts while continuing the same old crap.

Rob Nelson

On 8/24/2010 1:50 PM, Harold Brown wrote:
> What I find interesting is that people are neglecting to realize that
> ANY viewer, even a LL viewer could have been used to do the same thing
> by changing the WEBPAGE the login screen pointed to.  Or for that
> matter distributing a object using the new Media functions to load a
> webpage with the exact same iframe set.
>
>
>
> On Mon, Aug 23, 2010 at 8:03 AM, David M Chess  wrote:
>> Could we move all this stuff to a new "emeraldgate" list, or something?
>>
>> That I could then carefully not subscribe to?
>>
>> __
>> ___
>> Policies 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] This is how Linden Lab treats it's customers...

[Rob Nelson]

  And what venues can we use?  The forums are almost as heavily 
moderated as the mailing list, half of the time the blogs don't even 
allow you to comment.  I'd like to see a site moderated by a third party 
that won't delete your account or add a moderation flag to your account 
just for talking negatively about Linden Lab.

On 8/28/2010 1:02 PM, Altair Sythos Memo wrote:
> On Sat, 28 Aug 2010 12:56:56 -0700
> Dahlia Trimble  wrote:
>
>> After reading this thread, somehow all my past bad memories from
>> being a mainland resident no longer seem quite so bad.
> if you don't pay your fee mainland too your account will be
> suspended anyway, and deleted ripping away the land if not fixed
> balance :)
>
> can we talk again about code and 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
>

___
Policies 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] The Plan for Snowglobe

[Rob Nelson]

 Understand that since the Emerald fiasco, many viewer developers who 
have since "retired" are coming back either via user pressure or to take 
advantage of the power vacuum.  I personally just finished fixing up 
Luna for messing about in InWorldz.  Their developers seemed interested 
in my Lua engine, and I'm out of my "coder's block".


Rob Nelson

On 9/10/2010 4:27 PM, dilly dobbs wrote:
I would like to know 2  things, as an observer.  You continue to make 
statements like 'TPV developers' as if you speak for them all.


Secondly, I distinctly remember you saying goodbye to us all, Is this 
your Hi im back statement?


This isn't meant to be offensive im just trying to understand where 
your coming from.



I love deadlines. I like the whooshing sound they make as they fly by

Douglas Adams


On Fri, Sep 10, 2010 at 5:30 PM, Henri Beauchamp <mailto:sl...@free.fr>> wrote:


On Fri, 10 Sep 2010 12:22:25 -0400, Oz Linden (Scott Lawrence) wrote:

>   On 2010-09-09 7:15, Aidan Thornton wrote:
> > On 9/8/10, Oz Linden (Scott Lawrence)mailto:o...@lindenlab.com>>  wrote:
> >>  * Take down the Snowglobe subversion repository
> > That's going to be kinda obnoxious, because it means
non-Linden Labs
> > developers won't be able to look back at what was changed in
> > Snowglobe, when and why. There will still be mainstream 1.23-based
> > viewers by then unless Linden Labs does something incredibly
brilliant
> > or something incredibly stupid, and they'll still have a use
for the
> > Snowglobe version control history.
>
> Viewer developers should be thinking now about how to migrate to
the new
> code base so that you can support your features and interfaces
with the
> new underlying capabilities (and there are more coming)

Viewer developers will not consider migrating to the viewer 2 code
base
for many months, because it's simply easier for them to port the few
interesting new features of viewer 2 to viewer 1, than to redo the
whole
UI of viewer 2 to match their user base expectations and needs.

I already ported the Tattoo and Alpha wearables months ago to the Cool
VL Viewer (and most TPVs now reuse my patch), and the inventory item
links support a few weeks ago. I'll work next on multiple attachments
per point.

With Snowglobe v1.5 as the code base and the above cited backports,
you already have a better viewer than viewer 2, with a better
stability
and higher frame rates...

> and superior stability that the new code base has.

ROFLOL 

You are kidding, aren't you ?... If not, then please try using a good
TPV and see how many times it crashes in a week... 0 for the Cool VL
Viewer (and I'm using it every day). Fact is that TPVs got fixes that
v1.23.5 doesn't have and that makes them MUCH stabler than 1.23.5, and
v2 (which is even worst, stability-wise, than v1.23.5 !). The reason
is simple: should I crash, I trace the crash down and fix the code.
Crash gone !

> Eventually (and there is _no_ plan for when this will be - certainly
> longer than 3 months), it will no longer be possible for us to
continue
> to support viewers based on the 1.x code base (including our
own), and
> we'll stop.

By then, all the required changes will be ported to the v1 codebase
and migrating to v2 will still be unnecessary... This could go like
that for at least one or even two years before the backports become
too cumbersome to be worth staying with v1. I know it first hand,
since I did just that with the Cool VL Viewer v1.19.

> Well before this happens, we'll have a public discussion
> about it, and about what must be supported to remain compatible.
 If you
> have moved to and stayed reasonably current with the 2.x code
base, then
> it will be a non-event for you.

Again, TPV developers are not going to bother with v2 unless YOU,
Linden
Lab, change your stance on the UI and do accept reversals to the
v1 way,
where needed.

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



___
Policies 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] where is the source

[Rob Nelson]

 As I recall, all that lscript stuff was to compile the LSL bytecode 
and give it to the server.  It shouldn't be needed anymore since the 
server compiles everything itself...


Rob

On 9/13/2010 4:32 PM, Kelly Linden wrote:
I'd love to see that syntax highlighting and hover tip code replaced, 
we really shouldn't need anything in lscript in the viewer. If the 
syntax highlighting / hover tips could be read from an LLSD we could 
provide a capability 'lsl-syntax' which could be queried for a version 
or the whole map. Then you could get accurate syntax highlighting for 
the sim you are on independent of the viewer.


 - Kelly

On Mon, Sep 13, 2010 at 4:16 PM, CG Linden > wrote:


I believe that that code is used for the syntax highlighting - 
and indeed, " llGetLinkPrimitiveParams()" doesn't highlight in the

viewer...
--
cg


On Mon, Sep 13, 2010 at 11:44 AM, Altair Sythos mailto:syt...@gmail.com>> wrote:

On Mon, 13 Sep 2010 16:47:28 +0200
"Garmin Kawaguichi" mailto:garmin.kawagui...@magalaxie.com>> wrote:

> Is it the last last source code?
>
> I say that after reading :
>

https://bitbucket.org/lindenlab/viewer-development/src/tip/indra/lscript/lscript_library/lscript_library.cpp
> where llClearPrimMedia is the last function. Where are :
> llSetLinkPrimitiveParamsFast, llGetLinkPrimitiveParams,
> llLinkParticleSystem, llSetLinkTextureAnim,
llGetLinkNumberOfSides

mono script are server side compiled, i think all these are inside
internal LL branch
___
Policies 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


___
Policies 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] Compiling Snowglobe

[Rob Nelson]

  So I've got a recent-ish snowglobe source tree on Windows 7.  It 
compiles fine on Linux.  However, on Windows it's a hellish nightmare, 
and the wiki might as well be talking about compiling 1.23.  I've asked 
3 separate IRC channels with few positive results.

My current problem is with the libraries.  VC80 screams about missing 
VC80 boost libraries.  I looked in the libraries folder and found that 
it had VC90 boost libraries (according to the filenames, anyway), so I 
spent an hour installing and configuring VC90 only to find that it is 
almost as broken as VC2010, flooding me with "unresolved external" 
errors when linking with any non-boost lib.

So, is there anywhere I can find VC80 boost binaries compatible with 
SnowGlobe? (The prebuilt tarballs that LL provides only come with VC90 
libs.)  If not, how do I get this thing to build?  Which voodoo god must 
I sacrifice my firstborn to?

Rob
___
Policies 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] off the wall idea of the day

[Rob Nelson]

 You could always have a cheesy minigame where you play a breakout 
clone to get your avatar past a firewall to get to one of the servers.


Which then explodes.

On 9/23/2010 6:41 PM, Ponzu wrote:
Remember when at the keynote Philip said that Second Life should be 
"fun" like the iPhone is fun?  I had an idea tonight that is more 
along those lines then the usual suggestions for the Viewer.  if there 
is some sort of Linden Art Department, maybe they can do something 
with this idea.


"Logging in" is so *boring*.  You log in to the mainframe, or your 
prison cell.  When a user connects to Second Life, we need a better 
metaphor and a more "fun" experience.


I am thinking of something like ENTER THE METAVERSE  or UPLOAD 
YOURSELF NOW.  Then, instead of the boring progress bar, how about 
swirling lights or a visual whirl pool or something, like a music 
visualization plug in from iTunes.  Of course, it would have to be 
cool, and not cheesy, and that might be hard.  It might need cool 
sound effects to go with it.  It might need an entire control panel so 
that each user can customize to what he or she  (or any of those other 
possibilities) prefers. maybe audio to go with the video... Maybe each 
region in Second Life would have its own custom ENTRY video and audio. 
 Fairy dust and tinkly celeste for one place, Dark Explosions and 
subsonic booms for another.


or, just hire me to consult for the user experience group.  I've got 
more ideas, and I am hirable and cheap.   8-)


Ponzu


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


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

Re: [opensource-dev] Third Party Plug-ins?

[Rob Nelson]

 Lua's been implemented in a TPV successfully, meaning client-side 
scripting is definitely possible.  The only problem is that the viewer 
was never intended to have a scripting engine built-in, so lots of 
hacking on the backend to expose useful methods to the scripting engine 
is required.  The threading is also a mess right now.


Another consideration is what restrictions LL will want on these 
plugins.  I've already gone ahead and assumed that LL doesn't want 
scripts to have raw access to the messaging system, to avoid having 
malicious plugins sending disruptive or dangerous packets to the 
network.  I've also placed a policy on viewer development where access 
to economic functions must be approved by the user (via a warning dialog 
or a settings checkbox), and TPV policies (such as checking for creator 
permissions before accessing an object) have also been implemented.


Rob Nelson
Luna Viewer

On 9/24/2010 5:43 PM, Brandon Husbands wrote:
Yikes... I misread your post. LOL There are plenty on this list that 
try to close threads with links to past discussions. LOL my bad.. Ty 
for the links.


On Fri, Sep 24, 2010 at 5:54 PM, Ricky <mailto:kf6...@gmail.com>> wrote:


Please read these threads for the discussions we had on the types and
limits of various plugin schemes:
* "Client-side scripting in Snowglobe" -

https://lists.secondlife.com/pipermail/opensource-dev/2010-February/88.html
* "Consensus? was: Client-side scripting in Snowglobe" -

https://lists.secondlife.com/pipermail/opensource-dev/2010-February/000167.html
* "Client Plugin System Design" -
https://lists.secondlife.com/pipermail/opensource-dev/2010-March/000624.html

There are many useful ideas and documented pitfalls to avoid.  With
due consideration of these conversations many of the expected
issues/fears can be "headed off at the pass" you might say.

Ricky
Cron Stardust

On Fri, Sep 24, 2010 at 3:14 PM, Brandon Husbands
mailto:xot...@gmail.com>> wrote:
> I have already started work on a plugin system with embeded
mono. Which you
> expose methods to the api.. This allows anyone to use any CLI
language to
> create plugins.
>
> I can post more info on this later. A tad bit busy at the moment.
>
> On Fri, Sep 24, 2010 at 4:20 PM, malachi mailto:mala...@tamzap.com>> wrote:
>>
>> i for one particularly love this idea. i think there should be
a way for
>> the default LL issued viewer to be a plain jane for every user
client. but
>> allow third party devs to create plugins that do whatever they
want. the
>> idea of the radar and ao are amazing. but dont stop there.
there are tons
>> of things that average users DO NOT use in the client already.
LL could
>> simply remove those items and offer them as plugins. i am for
this idea of
>> modularity 100%. my only question is where do we start?
>>
>> On Fri, 24 Sep 2010 13:57:16 -0400, miss c mailto:miss_c...@yahoo.com>> wrote:
>>
>> > Would it be a plausible feature in the future to have the
code accept
>> > third
>> > party plug-ins instead of creating whole new viewers?  Then
have a Third
>> > party
>> > directory approved plug-in list.  As I mentioned before, my
husband is
>> > making an
>> > external installer for people that may have difficulty
installing skins
>> > into the
>> > new viewer, this will be a directory that all skin designers
can add
>> > their skins
>> > to.  Wouldn't it be better to have a RLV plug in or an AO
plug in, or a
>> > radar
>> > plugin that displays distance, then have to add all that to each
>> > viewer?  I do
>> > realize that there may be some things that Linden Lab might
not want to
>> > add to
>> > their code but if its switched to a plug in system, people
can pick and
>> > choose
>> > which additional features they prefer without having whats
considered
>> > competing
>> > iewers.
>> >
>> > TY
>> >
>> > Miss
>> >
>> >
>> >
>>
>>
>> --
>> Using Opera's revolutionary e-mail client:
http://www.opera.com/mail/
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Plea

[opensource-dev] Debugging SLPlugin(s)

[Rob Nelson]

  Here's another probable stupid question for you all.

During viewer startup in Snowglobe 1.5, I get spammed with "plugin_* has 
crashed etc etc, please restart etc etc".  I'd like to figure out why 
this is happening.  Unfortunately, all I'm getting from the 
SecondLife.log is that the APR connection was suddenly closed, and I'm 
not even sure it has anything to do with the plugin host.  However, I'd 
like to get to the bottom of this before I go nuts.

Rob
___
Policies 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] How is the XUI part of the interface designed?

[Rob Nelson]

 There's a GUI editor, but last I checked, only LL employees and a 
select few really know how to use it;  The manual is still in some LL 
wiki somewhere.


Rob

On 10/6/2010 3:56 PM, SuezanneC Baskerville wrote:
There's a bunch of xml files in the Second Life program folder, for 
one example, floater_tools.xml, which is for the build editor.


I know that we can modify these by editing the text files and 
restarting SL to see the changes we have made.


Are they designed by creating text files from scratch or is there any 
kind of GUI design editor involved, or any other kind of aid or 
assistance that increases designer efficiency about repeated 
edit-text-restart-SL cycles?


If so what it the GUI designer or design helper called?

There used to be an "Edit UI" mode in 1.x viewers, that showed pixel 
offsets and I think allowed you to move interface elements  while 
running SL.  Is this mode still available in 2.x viewers?


I wanting to see if the build editor can be made into a compact, long 
thin bar instead of big rectangle that is always in the way.




--
v i r t u a l   w o r l d   e n t h u s i a s t
-- http://www.google.com/profiles/s u e z a n n e --


___
Policies 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] Where oh where has my rendering gone?

[Rob Nelson]

 By the way, what happened to the rest of windlight that was supposed 
to be implemented?  The volumetric clouds, server-side settings sharing, 
etc?


Is it possible for a dev to get approval to release the viewer-side 
half-implemented versions of those so the community can finish them up?


Rob

On 10/7/2010 2:00 PM, Brad Kittenbrink (Brad Linden) wrote:



On Wed, Oct 6, 2010 at 8:57 AM, Joshua Bell > wrote:


On Tue, Oct 5, 2010 at 7:29 PM, Kent Quirk (Q Linden)
mailto:q...@lindenlab.com>> wrote:

Well, it's not quite like that. To pull this off, you'd have
to take everywhere we set a color, and set it instead to its
equivalent black and white value (there's a formula that's
traditionally used, although there's no "correct" way to do
it:  Y = 0.3*R + 0.59*G + 0.11*B). You *might* be able to get
away with modifying the LLColor4 constructor to do this, but
it's probably going to have some surprising results when you
assign a value and don't get the same value back.


How about post-processing every frame before the final swapBuffers
call? That seems like it could be done with a shader and only
touching a small amount of code. This would affect the UI as well
as the world viewport, however, without some significant
refactoring, but given that we already have some post-processing
effects (glow, etc) perhaps there's already a good spot to slot
this in?

(Don't trust me too much, though, as I've never written a
non-trivial shader and have never touched the viewer's render
pipeline!)

Of course, once you have monochrome output, you could tweak the
shader and get sepia-toned rendering. Old-timey SL, anyone?

-- Josh


This is definitely the approach I'd recommend.

To do this you'll want to reenable the old postprocessing filters 
which were part of a pre-release version of windlight but got disabled.


llrender/llpostprocess.{h,cpp}
newview/llfloaterpostprocess.{h,cpp}
newview/app_settings/shader/class{1,2}/effects/*.glsl

Most of this legacy code is probably horribly incompatible with the 
current renderer (particularly since deferred rendering has redesigned 
the way the renderer is organized), but at least it's a place to start 
looking...


-Brad


___
Policies 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] O.O Display name code DROP!

[Rob Nelson]

 So basically, LL decided to go from simply changing the formatting of 
their logs to (if what I am hearing is correct), of all things, LLSD XML 
notation, possibly the worst formatting of log possible?


Has ANYONE over there at LL looked at the sheer amount of overhead LLSD 
produces? We'll have log folders that are larger in size than our cache 
folders.


"[{TIME}] {DISPLAY NAME} ({REAL.NAME}) says: {STUFF}" would have been 
MORE than sufficient for logging purposes.


Rob

On 10/14/2010 9:57 PM, WolfPup Lowenhar wrote:


Actualy the file extension change is only to chat and IM logs. And I 
have already found a bug in the code!


https://jira.secondlife.com/browse/VWR-23437

the above jira is the bug and it is not being cause be my file name 
modification as the mod is working fine for group IM's.


*From:* opensource-dev-boun...@lists.secondlife.com 
[mailto:opensource-dev-boun...@lists.secondlife.com] *On Behalf Of 
*Jamey Fletcher

*Sent:* Friday, October 15, 2010 12:31 AM
*To:* opensource-dev@lists.secondlife.com
*Subject:* Re: [opensource-dev] O.O Display name code DROP!

WolfPup Lowenhar wrote:
> Well folks my night is going to be interesting as now I have to hard
> merge my logging code to the new code as there are changes to the way
> logs are EVEN saved .llsd instead of .txt which is going to make things
> interesting for me as now I have to change my history look up code for
> the new file extension and maybe even the name formatting itself!

Is that the crash & console logs, or the chat logs too?
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting 
privileges




No virus found in this message.
Checked by AVG - www.avg.com 
Version: 10.0.1136 / Virus Database: 422/3196 - Release Date: 10/14/10


___
Policies 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] O.O Display name code DROP!

[Rob Nelson]

  On 10/15/2010 2:04 AM, Lance Corrimal wrote:
> Am Freitag, 15. Oktober 2010, 10:00:44 schrieb Rob Nelson:
>>So basically, LL decided to go from simply changing the formatting of
>> their logs to (if what I am hearing is correct), of all things, LLSD XML
>> notation, possibly the worst formatting of log possible?
>>
>> Has ANYONE over there at LL looked at the sheer amount of overhead LLSD
>> produces? We'll have log folders that are larger in size than our cache
>> folders.
>>
>> "[{TIME}] {DISPLAY NAME} ({REAL.NAME}) says: {STUFF}" would have been
>> MORE than sufficient for logging purposes.
>
> what about sticking to the old format (i.e. without the "says" unless its a
> shout or a whisper)?
>
> [{TIME}] {DISPLAYNAME} ({LOGINNAME}): {STUFF}
>
> as it used to be..?
>
>
> bye,
> LC
Well, yeah.

Also, Marine, I stuck that ({REAL.NAME}) in there because I figured that 
their display name would have changed between now and when that log was 
written.  However, context may be lost if the display name is omitted, 
so I couldn't exactly dump that, either.
___
Policies 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] O.O Display name code DROP!

[Rob Nelson]

 I CONTRIBUTED SOMETHING ;_;

Rob

On 10/15/2010 4:23 PM, Leyla Linden wrote:

The only difference is that
they'll include both display names and usernames, much like Rob
Nelson suggested.

- Leyla


___
Policies 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] O.O Display name code DROP!

[Rob Nelson]

  This.  Say Joe Everyguy wants to look for a rather hot conversation he 
had with what he assumes was a very attractive-looking female 
yesterday.  With a text logfile, he just has to open the log in notepad 
and CTRL+F for "VerySexy Lady".  Since that was her display name at the 
time, it's included along with her real name (trucker.bob) and is 
therefore searchable. (Since the realname is included as well, it is 
also searchable.)

With what I've seen of the LLSD log, he'd open it up, be presented with 
what he thinks is gibberish, and then close it.  If he tried to search 
for "VerySexy Lady", he wouldn't find anything because only the UUID is 
included.

If the desire is to come up with a more easily parsed format for OH 
records, add an option to log to a non-LLSD XML file that is more easily 
transformed using XSL.  Something like:


STUFF
What was said
What was said
What was said


Rob

On 10/17/2010 1:34 AM, Lance Corrimal wrote:
> Am Sonntag 17 Oktober 2010 schrieb Ricky:
>> I agree, the XML notation is far from perfect (see some of my posts
>> last year about the subject,) however I consider it better than
>> either text or this almost-JSON notation for a variety of reasons,
>> all laid out in https://jira.secondlife.com/browse/VWR-23451 for
>> ease of reference.
>>
>> Assuming that the order of fields is fixed, a fair assumption as
>> LLSD requires it I believe, then the XSLT isn't so bad, and a
>> prototype has already been made.
>>
>> On the subject of using other standard tools, such as
>> grep/sed/awk/etc., I fully agree.  This is why I'd fight against
>> any binary or compressed format.  However, no such proposal has
>> been made.
> Guys, keep one thing in mind:
>
> the average user has no inclination of "processing" the logfiles with
> anything.
>
> The average user, at best, will open the logfiles in notepad to look
> at them, and to find stuff like "what was the name of that place that
> i heard about at that or that date".
>
> The average user runs windows, where tools such as grep/awk/sed are
> not exactly common, either.
>
>
> bye,
> LC
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>

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

Re: [opensource-dev] Again About Scripting Issues specifically KELLY LINDEN

[Rob Nelson]

 There is no "we".  The servers are proprietary; LL does this on their 
own dime and time.  From what I gather, there's a little bit of work 
going towards that direction, but the mesh changes have their attention 
for now, like car keys dangled in front of a toddler.


Rob

On 10/17/2010 12:40 PM, miss c wrote:
Running more and more tests about the lag in regions it seems more and 
more to point towards this issue more than anything else.


https://jira.secondlife.com/browse/SVC-3895 with over 900 votes
"Rezzing Mono scripted object cripples sim FPS" 



Now Kelly mentioned on this post it had something to do with the mono 
secuirty.dll.


When I did a search for Security.dll and mono in google it pulled up 
mailing lists and posts where this is actually a mono bug coming from 
their software.  The portion I gather is it was fixed or improved in 
newer versions.  I looked all over the wiki but I could not find what 
version of mono we are using.  Does anyone know?


I know this is more of a server function, but we have discussed at 
length for adding more tools to the viewer to monitor lag, but this 
would really make a huge difference if we just needed to update the 
mono version on the servers.


If there is a server mailing list, please point me in that direction.

Thanks

Miss
Fighting the lag every hour on the hour



___
Policies 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] Fermi Viewer

[Rob Nelson]

  Just spit out what you want, some of us are bored enough to add it to 
our viewers.

Rob

On 10/18/2010 4:08 AM, Arthur Fermi wrote:
> I am liking that idea :) the catch for us, is we have zero skills in house
> for a viewer.  We can build datacenters, large database projects, program in
> Perl, PHP, VB, LSL and probably a few more, but no C programmers of any
> type.  Go figure :)
>
> -Original Message-
> From: Marc Adored [mailto:m...@inworlddesigns.com]
> Sent: Monday, October 18, 2010 2:01 AM
> To: Francesco Rabbi
> Cc: Arthur Fermi; opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] Fermi Viewer
>
> Yes that could be awesome like The Fermi Builders Mod for Phoenix or
> better yet Kirstens :D
>
>
> On Mon, Oct 18, 2010 at 1:54 AM, Francesco Rabbi  wrote:
>> I think Carlo mean something else... In place to create another viewer
>> join an existing team and contribute code for building and SIM
>> managements
>>
>> --
>> Sent by iPhone
>>
>> Il giorno 18/ott/2010, alle ore 03:02, "Arthur Fermi"
>>   ha scritto:
>>
>>> Well LLs base is a decent start point.  We have looked at the other
> viewers
>>> and think we have some good ideas.  I find that most of the other viewers
>>> are not focused on building or sim management.
>>>
>>> -Original Message-
>>> From: Carlo Wood [mailto:ca...@alinoe.com]
>>> Sent: Sunday, October 17, 2010 7:59 PM
>>> To: Arthur Fermi
>>> Cc: opensource-dev@lists.secondlife.com
>>> Subject: Re: [opensource-dev] Fermi Viewer
>>>
>>> Imho, it is not a good idea to start yet-another-viewer.
>>> The number of open source coders are limited, they should
>>> be working on one viewer - not twenty.
>>>
>>> We already have more than 10 different viewers based
>>> on LL's code. How is it possible we need another?
>>>
>>> On Sun, Oct 17, 2010 at 06:09:49PM -0500, Arthur Fermi wrote:
 Fermi Sandbox is looking to put together a team to develop the Fermi
>>> Viewer.
 Please send inquires to arthur_fe...@fermisandbox.org or in world.



 Mission

 The Fermi Viewer projects goals are to create the best viewers for
> Second
>>> Life
 that works with all OS Grids.  The Fermi Viewer will be open for all to
>>> review
 and look at, and all in house code will be generated and provided to the
 community.



 Project Overview

 The Fermi Viewer project will generate 2 separate viewers, one will be a
>>> full
 featured viewer along the lines of emerald, this will be a general
> viewer
>>> with
 a focus on building and sim management.  The second view will be as
> light
 weight and fast as can be made, it will have building and sim management
>>> as its
 only focus with as many non-essential items moved out.

 Viewers will initial be based on the 1.x Snowglobe code from Linden
> Labs.
>>> A
 Version 2 viewer will come later in the project when time and resources
>>> are
 available to dedicate to a redesign of the interface.



 Open Source

 All work coming from the Fermi Viewer project will be returned to the
 community, this is a 100% open source project.



 Code Review

 All code other than the Linden Labs provide source code will be reviewed
>>> by a
 peer review committee to ensure that it complies with privacy standards.
>>> Once
 code is has been reviewed it will not need further review unless it has
 changed.



 Viewer Privacy Policy

 The Fermi Viewer will contain no code that will gather any information
>>> other
 than is required for interoperation with the grid it is connected to.
>   No
 information will be stored off the client computer, no anonymous
> tracking
>>> data
 will be collected.   Any violation of this policy will result in the
>>> instant
 removal from the project.



 Arthur Fermi



 ___
 Policies and (un)subscribe information available here:
 http://wiki.secondlife.com/wiki/OpenSource-Dev
 Please read the policies before posting to keep unmoderated posting
>>> privileges
>>>
>>>
>>> --
>>> Carlo Wood
>>>
>>>
>>> ___
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>>> Please read the policies before posting to keep unmoderated posting
> privileges
>> ___
>> Policies 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] Stuff I'd like to see in the coming sprint

[Rob Nelson]

 As an epileptic, I agree.  Thank God for Keppra (and the ability to 
still go back to Snowglobe 1.x).


Rob

On 10/19/2010 7:24 AM, Erin Mallory wrote:
I'd also like to see some of the siezure causing issues addressed 
(like disabling toasts).


___
Policies 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] display name userstory

[Rob Nelson]

How about "username (Loading...)", in order to queue people in as to why 
their display names aren't showing up.  Should relieve pressure on 
support staff.


Rob

On 10/29/2010 8:47 PM, Erin Mallory wrote:
as a user, if there are network issues in SL I would like display name 
enabled clients to NOT report avatars as ???-??? but rather default to 
user name or ??? - username



___
Policies 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] texture preview pane

[Rob Nelson]

Uh, try increasing your resolution?  I can't see how anyone can 
realistically use the UI when it's crunched down to that size.

On 11/1/2010 1:54 PM, Erin Mallory wrote:
okay, not sure exactly when or how this broke, but I only noticed this 
today and this makes texture previewing and sorting very difficult.  
Notice you cant read the titles or easily see what you're navigating 
to. see https://jira.secondlife.com/browse/VWR-23667



___
Policies 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] constant crashes

[Rob Nelson]

Too late for that.  Your username doesn't look to be too damaging 
anyway, and the password to your account isn't uploaded with the log.  
If you don't feel like exposing your account, just create an account 
along the lines of JIRATest with some random last name.  Or, even 
better, hook up an OpenSim and log in with the name Phillip Linden. :P


Rob

On 11/2/2010 6:10 PM, Erin Mallory wrote:
I am getting CONSTANT crashes on the new development build that look 
like the log following this.  What is causing them, how do i stop them?



[snip]
2010-11-03T01:06:56Z INFO: windows_post_minidump_callback: generated 
minidump: (pathway deleted for privacy) 
SecondLife\logs\83ea59e2-2ca0-49b2-82be-f816fc1af143.dmp

[...]
2010-11-03T01:06:56Z INFO: LLAppViewer::handleViewerCrash: Creating 
crash marker file C:\Documents and Settings\Elvendreams\Application 
Data\SecondLife\logs\SecondLife.error_marker
2010-11-03T01:06:56Z INFO: LLAppViewer::handleViewerCrash: Created 
crash marker file C:\Documents and Settings\Elvendreams\Application 
Data\SecondLife\logs\SecondLife.error_marker
2010-11-03T01:06:56Z INFO: LLAppViewer::handleViewerCrash: Handle 
viewer crash generating stats log.
2010-11-03T01:06:56Z INFO: LLAppViewer::writeDebugInfo: Opening debug 
file C:\Documents and Settings\Elvendreams\Application 
Data\SecondLife\logs\debug_info.log



___
Policies 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] Today's new Beta Viewer

[Rob Nelson]

Most of the stuff included are probably minor UI fixes (low resolution 
screws up layout, for example) and crash fixes.  I haven't read the 
changelog yet, though, so I don't really know.


Rob

On 11/4/2010 3:55 AM, Hitomi Tiponi wrote:
Is there a reason why 213435 seems identical to last week's 212977?  
Or am I missing something?



___
Policies 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] Dynamic shadows and ATI

[Rob Nelson]

You're better off getting a new card, since the card doesn't support 
dynamic shadows, not the other way around.

Rob

On 11/13/2010 3:35 AM, Laurent Bechir wrote:
> Hello,
>
> Anyone can tell me when Dynamic shadows will support ATI card, please ?
> I'm actually wondering what is the best if I want to use them, change my
> ATI for a Nvidia or wait it's supported.
>
> Thank you
> ___
> Policies 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] Upcoming depth-of-field feature

[Rob Nelson]

Oh good, let's add more features instead of either optimizing things or 
fixing things.

Rob

On 11/25/2010 8:56 AM, Opensource Obscure wrote:
>   Thanks to BlakOpal today I saw these very cool images:
>   http://twitpic.com/3a0vag/full
>   
> http://picasaweb.google.com/Runitai/DeferredRendering#slideshow/5542853119016406770
>   
> http://picasaweb.google.com/Runitai/DeferredRendering#slideshow/5543062518728480114
>
>   Where can I find more information about this depth-of-field
>   feature? (wiki pages, blog/forums, JIRA...)
>
>   It really looks good. I'm going to download a test build now.
>
>
>   Thanks in advance
>   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