[opensource-dev] What happened to Joe Linden?

[k\o\w]

I just noticed that Joe Miller was stealthily removed from the Linden 
Management page within the last week.

Anyone know what happened to Joe? Who is the new/interim VP of 
Technology & Platform development?

If Joe has indeed left the lab, he'll be greatly missed! He was one of 
the few managers at Linden who really understood the technology and 
would reignite my confidence in the company when he participated in the 
sl dev discussions.
___
Policies 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] step by step guide to compiling snowglobe

[k\o\w]

On Windows it's as easy as double clicking develop.py. Sounds like maybe 
you're not ready for Linux, and should try to a more user friendly OS/IDE.


Snowglobe should work out of the box with VS2005. Emerald and Imprudence 
are easier options if you're using VS2008. I believe the only issue with 
VS2008 + snowglobe is boost, and the libs from Emerald or Imprudence can 
be dropped in to fix that.



On 2/17/2010 2:08 PM, james ross wrote:
I am not sure if i tried the path listed there specifically. I have 
tried many different paths. I hope this one works. A shortcut or 
something that is easy is not really required but would definately be 
nice. I would be extremely thrilled if anything would work :-).


Thanks,
James


> Date: Wed, 17 Feb 2010 10:30:41 -0500
> From: monko...@fishkill.ibm.com
> To: dragnier1...@hotmail.com
> CC: opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] step by step guide to compiling snowglobe
>
> Seems like you're looking for a shortcut. The main Snowglobe page says
> > The Get source and compile page gives general information about 
how to compile the source. For a quick step-by-step instruction for 
building on Linux, see Compiling and Patching Snowglobe (Linux).

>
> Did you look at http://wiki.secondlife.com/wiki/Get_source_and_compile
>
>
> james ross wrote:
> > Well I am at least glad to see others have the same issue. A new 
viewer

> > coming out isnt going to change the fact that there is not one
> > step-by-step tutorial out there. Without the community here making it
> > easier for people to get involved any viewer will be under 
utilized (if
> > at all). Heh and also, I've never met a programmer that didnt look 
for

> > an example before trying to code it themselves :-).
>


Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up 
now. 



___
Policies 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] Client-side scripting in Snowglobe

[k\o\w]

I for one agree with Q. The biggest complaints come from the most 
insignificant people. If LL prioritized development based on the 
complaints in this mailing list, they would be rewriting SL for Linux 
using GTK and maintaining a dozen branches for ever popular flavour of 
unix. But then we'd just be playing a thinly veiled OpenCroquet.

Instead of making accusations and generating pages upon pages of 
arguments based on hearsay, why not ask a well thought out question that 
a developer can answer with a simple yes or no? I'd much rather Q and 
his coworkers spent time developing cool things than entertaining your 
pointless nerd rage about Mono.


On 2/18/2010 12:28 PM, Maggie Leber (sl: Maggie Darwin) wrote:
> On Thu, Feb 18, 2010 at 10:57 AM, Kent Quirk (Q Linden)  
> wrote:
>
>> This makes me sad.
>>  
> There's lots to be sad about.
>
> I think current Linden Research policies regarding viewer design and
> development has severely damaged the trust relationship that should
> exist within an open-source developer community.
>
> That's a much bigger impact on productivity than any personal
> complaints about "tone".
> ___
> Policies 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] Client-side scripting in Snowglobe

[k\o\w]

RLVa, supports something like this, and can be found in most 3rd party 
viewers:

http://rlva.catznip.com/blog/
http://wiki.secondlife.com/wiki/RestrainedLifeAPI

On 2/19/2010 10:38 AM, Morgaine wrote:
Not forgetting Erlang, Ruby, LISP, Javascript, and Bourne shell of 
course. :-)


But here's the fun one, for some value of "fun" ...  Someone would 
undoubtedly write an LSL binding to the socket-based API too.  And 
however much we screw up our noses at LSL, I have no doubt that a 
large number of SL users who know no other language would be very 
happy to see it. :-)


Providing a socket-based interface to the viewer would be a hugely 
all-embracing approach to client-side scripting, supporting everyone's 
needs.  I think it deserves consideration.



Morgaine.




===

On Fri, Feb 19, 2010 at 3:23 PM, Morgaine 
> wrote:


Indeed Rob!

Lua is a brilliant language for adding scripting to existing
applications --- it's designed expressly for embedding and
extending, it has a clean syntax, it is linguistically very
powerful, it is very tiny (the whole thing can add under 100KB to
your application), it can run sandboxed or not as desired, and it
is one of the fastest pure scripting languages currently
available, a lot faster than say Python.

It is no surprise then that game developers worldwide flocked to
it in droves, and now it's one of the most common scripting
languages found embedded in games.  WoW fans use it daily as an
intrinsic part of their WoW client, and a huge community has grown
up around Lua-powered interfaces for that game.

So yes, I'm with you on the importance of Lua for client-side
scripting of the viewer.

However, advocating Lua as the sole means of scripting viewers
would be just as bad a mistake as advocating C# or CLR-targetted
languages only.  It would support only one part of the scripting
community directly, while discriminating against everyone else. 
This is not necessary.


Instead, defining a socket-based API interface would allow
effectively any language to be used for scripting the viewer,
since virtually all languages today have socket capabilities. 
That would certainly include Lua and C# and Python and Perl and

Java and Clojure and C/C++ and ObjectiveC and Smalltalk, to name a
few languages that this community uses regularly.

The only thing that we would have to 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
mailto:nexisentertainm...@gmail.com>> 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
  

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

[k\o\w]

According to the latest Emerald change log they've removed LUA altogether.

Regardless of where the scripts are executed, I think it's safe to 
assume that LL will deliver a robust, well protected system that 
provides very limited (but very useful) access to the viewer and thus 
minimizes exploit vectors. Look at LSL, prims, avatars, sculpts, the 
coming mesh models, etc. Everything in SL is the textbook definition of 
proprietary, and for very good reason. Without these constraints we 
would have a lot of  broken and laggy content, and exploits much worse 
than what is being abused currently.

There is no reason to think that Linden would provide something that 
could pose a real security risk to your system. It is guaranteed that 
their implementation will be an invaluable addition to SL, will allow 
you to plaster penises all over the viewer, and will be abused for years 
to come by griffers.


On 2/19/2010 7:51 PM, Rob Nelson wrote:
> My main problem with Socket-based thing is that it opens up all kinds of
> problems, ranging from outside apps screwing with the socket and doing
> stuff that the user has not authorized, to simple security concerns (I'm
> sure as hell going to trust a readable
> Lua/LSL/shell/anything-other-than-LISP script more than a binary
> executable or shared library), to platform issues (opening local
> listeners may piss off certain software firewall implementations), not
> to mention the sheer amount of data that must be converted to and from
> UDP/TCP and transferred over a connection, which could cause latency.
>
> Having an embedded scripting engine is simply easier for script-writers,
> too.  All a user needs to know is what functions to use and where to put
> the sourcecode, whereas a socket-based solution means that a networking
> API must be present, and the user must maintain a constant connection to
> SL's process, requiring them to either have a provided API that supports
> their language (consider the sheer amount of maintenance this would
> require), or have TCP/IP experience and functions.
>
> I'm all for having a way to dynamically load a scripting engine
> DLL/SO/DYLIB, but I'm not very comfortable forcing users to use sockets
> in order to interface with their client.  There are other ways that
> aren't as risky, complex, and laggy, and trust me, I'm having enough
> trouble integrating Lua with SL.  The huge level of maintenance and
> dependency-juggling that just two language APIs would present could
> overwhelm even the Emerald dev team.
>
> On Fri, 2010-02-19 at 10:47 -0500, k\o\w wrote:
>
>> RLVa, supports something like this, and can be found in most 3rd party
>> viewers:
>> http://rlva.catznip.com/blog/
>> http://wiki.secondlife.com/wiki/RestrainedLifeAPI
>>
>> On 2/19/2010 10:38 AM, Morgaine wrote:
>>  
>>> Not forgetting Erlang, Ruby, LISP, Javascript, and Bourne shell of
>>> course. :-)
>>>
>>> But here's the fun one, for some value of "fun" ...  Someone would
>>> undoubtedly write an LSL binding to the socket-based API too.  And
>>> however much we screw up our noses at LSL, I have no doubt that a
>>> large number of SL users who know no other language would be very
>>> happy to see it. :-)
>>>
>>> Providing a socket-based interface to the viewer would be a hugely
>>> all-embracing approach to client-side scripting, supporting
>>> everyone's needs.  I think it deserves consideration.
>>>
>>>
>>> Morgaine.
>>>
>>>
>>>
>>>
>>> ===
>>>
>>> On Fri, Feb 19, 2010 at 3:23 PM, Morgaine
>>>   wrote:
>>>  Indeed Rob!
>>>
>>>  Lua is a brilliant language for adding scripting to existing
>>>  applications --- it's designed expressly for embedding and
>>>  extending, it has a clean syntax, it is linguistically very
>>>  powerful, it is very tiny (the whole thing can add under
>>>  100KB to your application), it can run sandboxed or not as
>>>  desired, and it is one of the fastest pure scripting
>>>  languages currently available, a lot faster than say Python.
>>>
>>>  It is no surprise then that game developers worldwide
>>>  flocked to it in droves, and now it's one of the most common
>>>  scripting languages found embedded in games.  WoW fans use
>>>  it daily as an intrinsic part of their WoW client, and a
>>>  huge community has grown up around Lua-powered interfaces
>>>  f

Re: [opensource-dev] Build problems with Snowglobe 2 source

[k\o\w]

1>Project : error PRJ0019: A tool returned an error code from "Generating
RelWithDebInfo/touched.bat"

go to build ->  configuration manager and uncheck package (or invoke develop.py 
with -DPACKAGE:BOOL=OFF) to get rid of the above error.



On 2/25/2010 11:58 PM, Sheet Spotter wrote:
> After commenting out the entire "if (LL_TESTS)" section at the bottom of
> "indra/newview/CMakeLists.txt" the linker still had unresolved symbols.
>
> It's my guess that "llcapabilitylistener.cpp" should be added to the
> "CMakeLists.txt" section that starts with "set(viewer_SOURCE_FILES".
>
> Manually adding the "llcapabilitylistener.cpp" source file to the VS2005
> project allowed me to compile and run again, but there are still some build
> issues. The "package" project produces the following output:
>
> 1>Processing ../win_crash_logger/RelWithDebInfo/windows-crash-logger.exe =>
> win_crash_logger.exe ... 1 files
> 1>Processing ../win_updater/RelWithDebInfo/windows-updater.exe =>
> updater.exe ... 1 files
> 1>Traceback (most recent call last):
> 1>   File "C:/SLSource/SnowglobeV2/indra/newview/viewer_manifest.py", line
> 999, in
> 1> main()
> 1>   File
> "C:/SLSource/SnowglobeV2/indra/newview\../lib/python/indra/util\llmanifest.p
> y", line 237, in main
> 1> wm.do(*args['actions'])
> 1>   File
> "C:/SLSource/SnowglobeV2/indra/newview\../lib/python/indra/util\llmanifest.p
> y", line 664, in do
> 1> method()
> 1>   File "C:/SLSource/SnowglobeV2/indra/newview/viewer_manifest.py", line
> 563, in package_finish
> 1> self.run_command('"' + proper_windows_path(NSIS_path) + '" ' +
> self.dst_path_of(tempfile))
> 1>TypeError: cannot concatenate 'str' and 'NoneType' objects
> 1>Project : error PRJ0019: A tool returned an error code from "Generating
> RelWithDebInfo/touched.bat"
>
> I guess it's possible this build problem is self inflicted by the edits I
> made to "CMakeLists.txt".
>
>
> Sheet Spotter
>
>
> -Original Message-
> From: opensource-dev-boun...@lists.secondlife.com
> [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Matrice64
> Sent: February 24, 2010 9:49 AM
> To: Argent Stonecutter
> Cc: opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] Snowglobe 2 update
>
> Yeah I commented out everything in the  if (test)   part of the
> CMakeLists.txt towards the bottom and it worked out for me
>
> On Wed, Feb 24, 2010 at 6:11 AM, Argent Stonecutter
>   wrote:
>
>> On 2010-02-24, at 02:26, Thomas Shikami wrote:
>>  
>>> SOCKS5 is usually used by griefers to mask the IP address.
>>>
>> SOCKS5 is the only way to connect if you are behind a reasonably
>> secure corporate firewall.
>>
>> SL is completely out of the question for business use without SOCKS5
>> support, even for the kind of "3d corporate website" model that LL is
>> pushing.
>>
>> ___
>> Policies 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] Snowglobe 2.0^H^H^H1.3 way forward?

[k\o\w]

Check out the LSL preprocessor in Emerald Viewer
http://www.modularsystems.sl/wiki/wikka.php?wakka=lslPreprocessor

On 3/12/2010 3:40 PM, Jonathan Irvin wrote:
Keep in mind, this is still in beta.  If you have an issue in the main 
viewer, use snowglobe.  If you have an issue with snowglobe, code it 
yourself.  If you can't code it yourself, then there's no need to 
blame Linden Labs for it.
Being in SL for 5 years has enlightened me to the fact that some 
people enjoy being miserable and broadcasting their misery to others.
SL gets the job done for what it is.  If you don't think so, uninstall 
the client and go about your life.  You don't need to throw your woes 
at others the same way monkeys fling feces.
I think M Linden is exactly what LL needs.  Don't get me wrong, I'm a 
HUGE fan of what Philip brought to the table with his visions.  M 
Linden is good in the sense that he is focused on making SL a better 
place for new and old users alike.
LL has made great strides with what they have had to work with in the 
past 2 years.  And they are taking it one step at a time.  I'm ok with 
that.  Viewer 2 is awesome, I suspect it will be even more awesome in 
the coming year.  The new stuff they are implementing in the server 
code is awesome as well.  ***Keep giving us more functions in LSL***
I would also like LSL to be more OO-centric.  OOP in LSL would be 
awesome.  Also, I would love a llInclude(), llRequireOnce(), etc 
functions so we can implement libraries and classes into our objects.


On Fri, Mar 12, 2010 at 14:00, Argent Stonecutter 
mailto:secret.arg...@gmail.com>> wrote:


On 2010-03-12, at 11:57, Morgaine wrote:
> The answer to all of these UI issues is simply client-side
scripting.

That's AN answer. It's not the RIGHT answer (at least not to THIS
question, it's the right answer to a bunch of other questions, just
not this one), but it's certainly AN answer.

___
Policies 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] Fwd: Request for comments about llSetAgentEnvironment / SVC-5520

[k\o\w]

I have to agree, the state of both SL and OpenSim is a royal mess. SL 
has already been forked, dozens of times. At SLCC '08 we spoke with Rob 
Lanphier about our announcement and presentation of the Meerkat viewer 
and were met with quite a bit of hostility. Linden simply did not want a 
competing viewer project at that time, and I believe that still holds 
true and is the reason Snowglobe was created.

The most popular 3rd party viewer used in SL, Emerald Viewer, is 
unfortunately run by people so proud and protective of their open source 
code that they refuse to have a public SVN, let alone allow any 
collaboration. The entire OpenSim community is so afraid of being sued 
by Linden that they won't allow their developers to look at the SL code 
for an entire 6 months before they can continue working on OpenSim. Even 
though the GPL explicitly allows a developer to study the entire SL code 
base and develop non-GPL code using knowledge gathered from the GPL 
project. The RealXtend developers fell right into that trap, and wasted 
a lot of time and money running concurrent development teams that 
couldn't look at each others code. And when the frustrations of their 
isolated development became too annoying,  RealXtend started their own 
BSD viewer.

Going forward, I think the best solution is to fork the viewer and 
OpenSim using distributed version control, while maintaining full 
compatibility with Lindens protocol, features, and servers. If we want 
the metaverse to progress and develop faster, we need to cater to the 
biggest metaverse communities out there, and develop clever ways to fill 
the voids that Linden refuses to. The Emerald Viewer team has shown was 
is possible when a large community adopts slightly ghetto hacked-in 
features like Client ID or chat encryption. We have the ability to store 
a lot of custom information on the SL grid in the form of textures 
(sculpts!) and notecards (client side AO!), so lets continue doing cool 
things with that ability. One thing that is certain is that the 
community is very willing to adopt these enhancements once they're made.

I think it has become very clear that Linden don't want a community run 
viewer project, but a viewer project that they are in full control of 
that only works in their vision of SL. Patches for content import/export 
and grid hopping have been deleted from the Linden JIRA, further 
crippling our abilities to do cool things like being able to develop SL 
content entirely within 3ds max or offline in a local OpenSim server.

The biggest hurdle will still be assembling a community of willing and 
able developers. Over the course of the two years that I ran the Meerkat 
Viewer project, we saw maybe 5 people step up and offer their time to 
the project, and of those only about 2 submitted something. It seems 
every developer has their own vision for the metaverse and is hellbent 
on running their own viewer project. We gave up with Meerkat and 
consolidated our work into another viewer project because we understood 
that developing the same things concurrently is a huge waste of time. I 
think that even now, the developers of other viewer projects waste half 
their time merging and patching in features from other clients! The end 
result is a handful of clients with more or less the exact same features.

My hellbent vision of the metaverse is the Emerald Viewer team putting 
their code into Mercurial or Git and letting us have a go at it. The SL 
userbase has spoken, and Emerald is the most widely used community run 
project. Unfortunately the open source devs have had many years and 
opportunities to work together, and I don't see ours, or Lindens 
stubbornness magically changing any time soon. What is is going to take?



On 3/14/2010 6:31 AM, Rob Nelson wrote:
> 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
>> Subj

Re: [opensource-dev] oh give me a break

[k\o\w]

I think the majority of viewer and server developers are on Lindens side 
with this. OpenSim will never be a replacement for what the Linden grid 
provides, and is a wonderful tool that I hope a lot of client devs are 
using to enhance their development process. The fact still remains that 
the bulk of the work required to implement a new feature in SL is on the 
client side, and as with the products within SL, it's up to the 
developer to create something that users want and use.

Whether Linden implements a new feature or not really depends on their 
users showing an interest in those features. I would bet money that 
Linden is keeping a close eye on the more influential third party 
viewers and are figuring out what features could be profitable to port 
to their viewers. I wouldn't be surprised if features like mesh import 
were considered more seriously after we got them in OpenSim grids.

I think the real problem here is the large amount of people who have 
decided to make it Lindens responsibility to maintain and release all 
the code coming from the community in their viewers. These folks need to 
stop posting here and start submitting patches to one of the many 3rd 
party viewer projects out there.

I urge those of you complaining about not getting any attention from 
Linden to submit your patches to viewers such as Imprudence 
(http://imprudenceviewer.org/) or Emerald 
(http://www.modularsystems.sl/). Let the thousands of residents 
testing/using third party viewers decide if your code is worth porting 
around.



On 3/14/2010 7:03 PM, Soft Linden wrote:
> On Sun, Mar 14, 2010 at 3:47 PM, Kevin Woolley  wrote:
>
>> I own three Sims in SL, that's ~$600 a month or so to the Lindens, and
>> that's supported off DRM'ed content creation that I sell. If my income was
>> to vanish because of widespread content theft then I'd be out of SL.
>>
>> I find Hax's attitude extremely concerning.
>>  
> It's a good thing he's neither a contributor, nor - to the best of my
> knowledge - representative of anyone with code in our project. He's
> just a guy showing up with an opinion.
>
>
>
>> In fact I think we should now recognise that Open Sourcing the viewer has
>> been a mistake, and the Lindens should close it off again, possibly
>> replacing it with controlled licensed development.
>>  
> copybot and copying proxies existed before the viewer was made open
> source, and would continue to exist without the viewer being open
> source. Abandoning source publication wouldn't stop the problem. There
> are literally dozens of tools that don't use one line of our code.
>
> Keep in mind that open source projects also include clients and tools
> that help identify copy botters, added clothing layer protection even
> before Viewer 2, add automatic recognition of some copied content, and
> more. It's also meant some better building and scripting tools, free
> clothing texture upload previews and other things that help in
> creating content.
>
> On the balance, the open source viewer has improved the situation for
> content creators.
> ___
> Policies 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] crazy land idea

[k\o\w]

  I've been thinking about ways to implement subtractive objects for a 
while now:
We would flag the object as subtractive and flip its normals.
During the rendering phase, we would apply a simple clipping algorithm 
to each object to slice off the intersecting geometry.
The subtractive object would be merged into the original object to 
create the hollowed section.

The math involved is very similar to the math already used in SL's 
occlusion culling, and if used properly should reduce render time vs. 
trying the create the same effect with many more prims.

A quick demo of an algorithm for openGL clipping can be found here: 
http://www.docstoc.com/docs/272548/Computer-Graphics-clipping-opengl

Similar code would be required for the physics, lighting, and shadow 
implementations.

Subtractive geometry has been a basic feature of many game engines for 
quite a while, and if used right improves performance.


I like the idea of using prims to define area effects like the presence 
of rain or snow! This is exactly how these kinds of things are done in 
other game engines. Content creators already do this with volume 
detection but it could be supported better by the client and a new prim 
type.

On 9/26/2010 12:10 PM, Carlo Wood wrote:
> Hmmm, yes. There is more use to detecting "being inside a prim"
> and toggling certain render types as a result it seems.
>
> Now, an easy way would be to detect if the CAM is inside a prim,
> and then turn off -say- water fog, or whatever causes one to
> appear being under water; or turn off rain/snow if that is turned
> on.
>
> However, if then you look out the window, it stopped raining
> outside too.. so that isn't good enough.
>
> On Sun, Sep 26, 2010 at 09:46:09AM -0400, Tammy Nowotny wrote:
>> This is purely anecdotal (though maybe someone knows more than my anecdote): 
>> I
>> have heard that the SL game engine is not good at determining which points 
>> are
>> under/above/inside an enclosure such as a building.  Moreoever, legend has it
>> that there is a whole weather system in the engine which was never activated
>> because there was no way to stop rain, snow etc. from going through roofs,
>> walls, etc.
___
Policies 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] Files deleted by uninstaller don't appear in Recycle Bin

[k\o\w]

I'm having trouble reproducing this issue, when I uninstall Viewer 2 my 
logs and settings, even my local asset cache remain (using Win7 x64).


What operating system are you folks experiencing the problem with? I 
suspect this might be related to using XP, which doesn't allocate 
separate folders for local and roaming application data like Vista/7 do. 
A quick peek at the installer template reveals that on XP the 
Application Data/Second Life folder is removed, while on Vista/7 only 
AppData/*local*/Second Life is removed, while the logs/settings in 
/AppData/*roaming*/Second Life should remain untouched. This pretty much 
defines best practice in terms of handling application data.


If that is the case, then Linden should go ahead and ignore the bug as 
it's caused by the nature of a ~10 year old operating system. I'd rather 
see effort being put into supporting new Windows SDK features than 
working around old ones.


Log file location is one of the few things you can change directly from 
preferences, and probably exactly for this reason. If you care so much 
backup your data more often or learn to use system/file restore.


As for overwriting your old logs, you did that yourself when you 
installed over recently freed up HD space. Not a software bug.



On 10/29/2010 2:36 AM, Erin Mallory wrote:
I lost 3 years on one computer and 4 on another because of 
uninstalling all v2 versions at the request of support (which i later 
learned was unneeded).  I was assured i didn't need to back up my logs 
before hand.  I tried to retrieve them using some of the data recovery 
programs we have at work, but the installer overwrote them when it 
erased them.  WTF???
There are three failures here.  The failure to provide at least the 
option to keep the logs, the failure of LL to have support people that 
know what the fuck they are doing, and using an installer that scrubs 
the deleted files so they can't be recoverable.
All I can say is THANK GOD it was my personal computers and not my 
work ones.
But even so, the loss of some of those logs really hurt and caused 
some real tears...   especially the ones from users that are now 
deceased or missing irl.  I can never recover those, and it angers me 
to no end that the inability of someone to actually think through a 
decision means that I cannot go back and reread the conversations we 
had anymore  and yes now before i uninstall anything i back up the 
files.  and i would have before uninstalling all the versions of v2 i 
had had at the time, except i was assured by live support that the 
installers would NOT touch those files.


Just one more in a heap load of instances where someone at LL or their 
contractors decided that because they wanted something done a certain 
way all users would.  so if some of the lindens wonder why i am so 
passionate and stubborn and why when you pull that "we're doing it 
this way and there's no discussion" crap, its cause that mentality 
leads to things like this happening




Date: Thu, 28 Oct 2010 18:35:07 -0500
From: sueza...@gmail.com
To: thomas.shik...@online.de
CC: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] Files deleted by uninstaller don't 
appear in Recycle Bin


6 years and 9 months of chat logs is not "bread crumbs".

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