[opensource-dev] Does writing to llerrs make the viewer crash ?

[Marine Kelley]

Hello all,

I have just filed a JIRA (VWR-23459) about a random crash that would
occur in the rendering pipeline, when suddenly it struck me : I
remember that years ago the viewer would crash when writing to llerrs,
and that it was voluntary (don't ask me why).

Is it still the case ? In this JIRA, the fix I provide merely removes
the write to llerrs, and returns without going any further into the
method. I did not have time to give it more attention, it was more of
a dirty hack to be able to keep from crashing every 15 minutes while
my friends were waiting for me.

Thanks and happy new year to all of you !
Marine
___
Policies 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] Does writing to llerrs make the viewer crash ?

[Marine Kelley]

Ah yes that's what I remembered. I didn't think it was still the case
in v2. Thanks.

On 31/12/2010, Zabb65  wrote:
> Yes, llerrs purposefully dereferences a null pointer to cause a crash,
> and if that fails it infinitely loops. This is so "errors" get fixed
> instead of being ignored.
>
> On Fri, Dec 31, 2010 at 05:42, Marine Kelley  wrote:
>> Hello all,
>>
>> I have just filed a JIRA (VWR-23459) about a random crash that would
>> occur in the rendering pipeline, when suddenly it struck me : I
>> remember that years ago the viewer would crash when writing to llerrs,
>> and that it was voluntary (don't ask me why).
>>
>> Is it still the case ? In this JIRA, the fix I provide merely removes
>> the write to llerrs, and returns without going any further into the
>> method. I did not have time to give it more attention, it was more of
>> a dirty hack to be able to keep from crashing every 15 minutes while
>> my friends were waiting for me.
>>
>> Thanks and happy new year to all of you !
>> Marine
>> ___
>> Policies 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] Does writing to llerrs make the viewer crash ?

[Marine Kelley]

Hehe well there were two ways of writing the name of the JIRA entry :
the right way, and the Marine way. Guess which one I chose.

Thanks Sheet :)


On 31/12/2010, Sheet Spotter  wrote:
> The random crash reported by Marine was VWR-24359.
>   https://jira.secondlife.com/browse/VWR-24359
>
> (There was a typo in the original post; two digits were transposed.)
>
>
> Sheet Spotter
>
> -Original Message-
> From: opensource-dev-boun...@lists.secondlife.com
> [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Marine
> Kelley
> Sent: December 31, 2010 4:43 AM
> To: opensource-dev@lists.secondlife.com
> Subject: [opensource-dev] Does writing to llerrs make the viewer crash ?
>
> [...]
>
> I have just filed a JIRA (VWR-23459) about a random crash that would
> occur in the rendering pipeline [...]
>
>
>
___
Policies 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] A weird bug when moving the avatar

[Marine Kelley]

I have observed this behavior with the rev 14120 of viewer-development :

https://jira.secondlife.com/browse/VWR-24361 (name checked this time)

In short, when you press a movement key or use the move panel (going
forward, backward etc, but not turning left or right), the FPS
decrease dramatically (from 90 down to 15 FPS). It can be very
annoying during races or fights.

Has anybody observed this too ? I don't remember having seen this
happen in older viewers, but I recently changed my video card so maybe
the change in FPS was not noticeable to me before.

And more importantly, has any work been done recently (less than two
months ago) on the way the avatar movement is handled, that could
trigger this bug ? I don't really know where to look so if anybody has
pointers, please feel free to share !

Thanks,
Marine
___
Policies 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] VWR-8208 Searchable "Debug Settings"

[Marine Kelley]

What I do is open my settings.xml file and search what I want with a
text editor, it works.

On 02/01/2011, Ricky  wrote:
> I was just about to create a JIRA entry for the idea of making things
> easier to find in the Debug Settings menu, when I found an existant
> JIRA on the subject.  VWR-8208 "find instead of auto-complete for
> Debug Settings" https://jira.secondlife.com/browse/VWR-8208
> It would be great to have some attention paid to this concept, as it
> should be fairly trivial to implement, and would make working with
> those entries a lot easier.
>
> Just making some noise about one of my annoyances...
> Ricky
> Cron Stardust
> ___
> Policies 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] VWR-8208 Searchable "Debug Settings"

[Marine Kelley]

Yes that would be great, because the debug settings are not in any
particular order in settings.xml, while they are in alphabetical order
in the viewer. Sometimes it can be confusing (especially when you
browse all the Render* debug settings, they are all over the place).

On 02/01/2011, Ricky  wrote:
> Thank you Jonathan and Marine.  These workarounds are good, and I will
> tap into them.  Hopefully an in-client solution isn't too far into the
> future! :)
>
> Ricky
>
> On Sun, Jan 2, 2011 at 1:52 PM, Marine Kelley 
> wrote:
>> What I do is open my settings.xml file and search what I want with a
>> text editor, it works.
>>
>> On 02/01/2011, Ricky  wrote:
>>> I was just about to create a JIRA entry for the idea of making things
>>> easier to find in the Debug Settings menu, when I found an existant
>>> JIRA on the subject.  VWR-8208 "find instead of auto-complete for
>>> Debug Settings" https://jira.secondlife.com/browse/VWR-8208
>>> It would be great to have some attention paid to this concept, as it
>>> should be fairly trivial to implement, and would make working with
>>> those entries a lot easier.
>>>
>>> Just making some noise about one of my annoyances...
>>> Ricky
>>> Cron Stardust
>>> ___
>>> Policies 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] autobuild with VS2005

[Marine Kelley]

Hello all,

This is probably a silly question, but is it possible to use autobuild
with VS2005 ? What used to work very well for me with
VS2005+develop.py now fails miserably on VCExpress2010+autobuild. Does
this question even make sense ? Or am I condemned to switch to VS2010
that I really disliked ?

Here is what I have spent my Sunday on :

- Tried to run autobuild as "autobuild build -c Release", only to get
an error saying that it does not find VS2010 (of course, it is not
installed). I also had to tell it to not download all the proprietary
libraries.
- Replaced all occurrences of "Visual Studio 10" in autobuild.xml by
"Visual Studio 8 2005" and ran autobuild again, it worked.
- Built the solution under VS2005, and it failed miserably because it
wanted some Microsoft library v1.45 that my system had only v1.30 of
(I don't remember the full name right now but I remember that putting
v1.30 would result in a ton of unresolved externals). The build itself
took 15 minutes as it always does.
- Tried to find these libraries everywhere and failed.
- Downloaded VSExpress 2010, knowing very well that its use is limited in time.
- Downloaded the source code again
- Ran autobuild, failed (no generator named "Visual Studio 10")
- Upgraded the whole libraries and tools according to the wiki because
I didn't notice that no, Cmake 2.6 was definitely not acknowledging
VS2010. Cmake 2.8 was the right tool to use instead.
- Ran autobuild, and it worked when using "autobuild build -c
VCExpressRelWithDebInfo" (that's from memory).
- Built the solution under VS2010... it took an hour before telling me
that it couldn't find a "specified file" that it never bothered to
tell me the name of.
- Gave up and went to bed. I just remember now that secondlife-bin.exe
had been generated, but I didn't think of trying it. Maybe the error
can be ignored, I don't know.

For me, VCExpress2010 is slower, bigger, limited in time and in
features, and in any case is not suitable to do a task that VS2005 had
no problem doing. All it managed to do so far was to waste my time.
Now of course, VS2010 might be more powerful, and I am not arguing
against it, it is just that for now I can't go anywhere with it
anyway.

Could a good soul show me how to make autobuild work with VS2005 please ?

Thank you,
Marine
___
Policies 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] autobuild with VS2005

[Marine Kelley]

Thank you all for the pointers.

So if I get this right, VS2005 is to be left behind... not really kind
to people who are used to it, and who find 2010 to be an unbearable
bloatware that runs 4x slower than the old IDE. Not mentioning that
with 2005, at least I could do something else while compiling. With
this one, I can do something else... as long as it's away from my
computer.

And if I also get this right, "VCexpressRelWithDebInfo" is the only
configuration that I should use, isn't it ? I am told to always use
the "OpenSource" ones, except if I am on Windows (which is the case).
Doesn't matter, I'll try both.

Marine


On 18/04/2011, WolfPup Lowenhar  wrote:
> 1. yes anyone doing builds in an OpenSource environment should be using the
> ones pre-fixed with OpenSource.
> 2. there are specific setting for windows that are current workarounds till
> the autobuild.xml is up dated and they are:
>   a. VCexpressRelWithDebInfo
>   b. VC10msbuildRelWithDebInfo
>   c. VC10msbuildRelease
>
> these setting are going to be merged into the normal OpenSource settings
> along with some name changes for 'cleaning up' both the xml file and the
> command line as there are also the addition of a few more default switches.
>
>> -Original Message-
>> From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-
>> boun...@lists.secondlife.com] On Behalf Of Boroondas Gupte
>> Sent: Monday, April 18, 2011 11:09 AM
>> To: opensource-dev@lists.secondlife.com
>> Subject: Re: [opensource-dev] autobuild with VS2005
>>
>> Linux-based dev here, so be aware my answer is based on hear-say, not
>> own experience.
>>
>> On 04/18/2011 02:05 PM, Marine Kelley wrote:
>> > - Tried to run autobuild as "autobuild build -c Release", only to get
>> > an error saying that it does not find VS2010 (of course, it is not
>> > installed). I also had to tell it to not download all the proprietary
>> > libraries.
>> AFAIK, you should use OpenSourceRelease, OpenSourceRelWithDebInfo or
>> OpenSourceDebug as the configuration rather than Release, RelWithDebInfo
>> or Debug. The configurations without the "OpenSource" prefix in the name
>> are meant for LL's internal use and might require availability of 3rd
>> party libraries that LL isn't allowed to re-distribute.
>>
>> > [...]
>> > - Ran autobuild, and it worked when using "autobuild build -c
>> > VCExpressRelWithDebInfo" (that's from memory).
>> [Question to anyone who might know:] Does that configuration still serve
>> any purpose? I thought the VCExpress issue(s) was/were solved in a way
>> that'd also work for non-Express VS10 and thus was merged into the
>> normal OpenSource* configurations for Windows? Or was that just planned
>> but didn't get executed (yet)?
>>
>> Cheers,
>> 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
>> -
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 10.0.1321 / Virus Database: 1500/3581 - Release Date: 04/18/11
>
> ___
> Policies 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] autobuild with VS2005

[Marine Kelley]

Thanks... this convinces me to go with VCE2010 (getting over the
initial gripe I have about it, since it is the only sensible option I
have to go ahead anyway).

Right now it builds to the end, but it fails at the very last step
with this error :

60>  Looking for existing VisualStudio instance...
60>Didn't find open solution, starting new background VisualStudio
instance...
60>Reading .sln file version...
60>Using version: VC100...
60>  Value cannot be null.
60>  Parameter : type

Seems to be vstool complaining that it cannot find the instance of VS
when calling GetDTEAndSolution() in main.cs... although VCE is open.
Autobuild does that too on the command line. What can I do to make it
find VCE and modify the solution ? I'm thinking some path is missing
from my PATH env variable but I can't figure out which.

Thanks again


On 18/04/2011, Ima Mechanique  wrote:
>> Thank you all for the pointers.
>>
>> So if I get this right, VS2005 is to be left behind... not really kind
>> to people who are used to it, and who find 2010 to be an unbearable
>> bloatware that runs 4x slower than the old IDE. Not mentioning that
>> with 2005, at least I could do something else while compiling. With
>> this one, I can do something else... as long as it's away from my
>> computer.
>
> Not so much that 2005 is being left behind, but that LL is moving
> forward. They cannot stay with the same environment when the Operating
> Systems are moving forward; for many reasons.
> How fast VC10 runs depends a LOT on your system and configuration. When
> I first used autobuild with it, it took the same time to build the
> viewer as 2005 had (approximately) However this turned out to be because
> I was not using some of the optimisations possible that 2005 had been
> using. With these enabled, it is now 35 minutes faster than 2005.  Yes,
> it is a resource hog, but that's how it gets to be faster, you can
> change default values to prevent that if you want to, I make a cup of
> coffee and do something else ;-) Also, autobuild is designed to use the
> command line, not the IDE which is a great part of the resource eating.
> Intellisense is a pain in the ... RAM, disc I/O, etc. for example.
>
> As has been said already, autobuild started on the 2005 build, if you
> want to continue using it you will need to collect all the 2005 build
> versions of the libraries and create a configuration file that uses them
> instead of the default one which uses 2010 builds.
>
> If you are using the Express version of 2005 you will probably have to
> do more to get it to work. The initial version of autobuild was not
> express friendly. This is caused by many differences in how the
> full/express versions work.
>
> Start with the repo at https://bitbucket.org/oz_linden/viewer-autobuild/
>
> That is the one started for 2005 builds, so should contain some if not
> all the library links  I have no idea if those files are still available
> from the amazon servers though.Be aware it is considerably out of date
> with the main code base now, so you will have to import from
> viewer-development, being careful not to over write the autobuild.xml,
> best to rename it.
>
>> And if I also get this right, "VCexpressRelWithDebInfo" is the only
>> configuration that I should use, isn't it ? I am told to always use
>> the "OpenSource" ones, except if I am on Windows (which is the case).
>> Doesn't matter, I'll try both.
>
> IIRC the OpenSource* configurations are for full versions of VC only.
> They may work with a full version of 2005.
> VCexpressRelWithDebInfo is for VC10 Express versions. It uses commands
> not available on 2005, so probably will not work at all for you.
>
> --
> Ima Mechanique
> ima.mechanique(at)blueyonder.co.uk
>
> ___
> Policies 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] autobuild with VS2005

[Marine Kelley]

Aha ! Thanks much Ima, I'll play a little with a clone of your
repository tomorrow, maybe it will lead me to a full working build
this time :)

On 18/04/2011, Ima Mechanique  wrote:
>> Thanks... this convinces me to go with VCE2010 (getting over the
>> initial gripe I have about it, since it is the only sensible option I
>> have to go ahead anyway).
>>
>> Right now it builds to the end, but it fails at the very last step
>> with this error :
>>
>> 60>  Looking for existing VisualStudio instance...
>> 60>Didn't find open solution, starting new background VisualStudio
>> instance...
>> 60>Reading .sln file version...
>> 60>Using version: VC100...
>> 60>  Value cannot be null.
>> 60>  Parameter : type
>>
>> Seems to be vstool complaining that it cannot find the instance of VS
>> when calling GetDTEAndSolution() in main.cs... although VCE is open.
>> Autobuild does that too on the command line. What can I do to make it
>> find VCE and modify the solution ? I'm thinking some path is missing
>> from my PATH env variable but I can't figure out which.
>
> I can't swear to it (I don't use the 'official' autobuild.xml), but as I
> recall, that is a known problem for express, that should be fixed with
> the OPEN-50 stuff that's coming soon ;-) VCE can't modify the solution
> this way, it doesn't have the API required for it. This is one of the
> many differences between Express and full versions.
>
>
>> Thanks again
>>
>>
>> On 18/04/2011, Ima Mechanique  wrote:
>> >> Thank you all for the pointers.
>> >>
>> >> So if I get this right, VS2005 is to be left behind... not really kind
>> >> to people who are used to it, and who find 2010 to be an unbearable
>> >> bloatware that runs 4x slower than the old IDE. Not mentioning that
>> >> with 2005, at least I could do something else while compiling. With
>> >> this one, I can do something else... as long as it's away from my
>> >> computer.
>> >
>> > Not so much that 2005 is being left behind, but that LL is moving
>> > forward. They cannot stay with the same environment when the Operating
>> > Systems are moving forward; for many reasons.
>> > How fast VC10 runs depends a LOT on your system and configuration. When
>> > I first used autobuild with it, it took the same time to build the
>> > viewer as 2005 had (approximately) However this turned out to be because
>> > I was not using some of the optimisations possible that 2005 had been
>> > using. With these enabled, it is now 35 minutes faster than 2005.  Yes,
>> > it is a resource hog, but that's how it gets to be faster, you can
>> > change default values to prevent that if you want to, I make a cup of
>> > coffee and do something else ;-) Also, autobuild is designed to use the
>> > command line, not the IDE which is a great part of the resource eating.
>> > Intellisense is a pain in the ... RAM, disc I/O, etc. for example.
>> >
>> > As has been said already, autobuild started on the 2005 build, if you
>> > want to continue using it you will need to collect all the 2005 build
>> > versions of the libraries and create a configuration file that uses them
>> > instead of the default one which uses 2010 builds.
>> >
>> > If you are using the Express version of 2005 you will probably have to
>> > do more to get it to work. The initial version of autobuild was not
>> > express friendly. This is caused by many differences in how the
>> > full/express versions work.
>> >
>> > Start with the repo at https://bitbucket.org/oz_linden/viewer-autobuild/
>> >
>> > That is the one started for 2005 builds, so should contain some if not
>> > all the library links  I have no idea if those files are still available
>> > from the amazon servers though.Be aware it is considerably out of date
>> > with the main code base now, so you will have to import from
>> > viewer-development, being careful not to over write the autobuild.xml,
>> > best to rename it.
>> >
>> >> And if I also get this right, "VCexpressRelWithDebInfo" is the only
>> >> configuration that I should use, isn't it ? I am told to always use
>> >> the "OpenSource" ones, except if I am on Windows (which is the case).
>> >> Doesn't matter, I'll try both.
>> >
>> > IIRC the OpenSource* configurations are for full versions of VC only.
>> > They may work with a full version of 2005.
>> > VCexpressRelWithDebInfo is for VC10 Express versions. It uses commands
>> > not available on 2005, so probably will not work at all for you.
>> >
>> > --
>> > Ima Mechanique
>> > ima.mechanique(at)blueyonder.co.uk
>> >
>> > ___
>> > Policies and (un)subscribe information available here:
>> > http://wiki.secondlife.com/wiki/OpenSource-Dev
>> > Please read the policies before posting to keep unmoderated posting
>> > privileges
>> >
>
> --
> Ima Mechanique
> ima.mechanique(at)blueyonder.co.uk
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev

Re: [opensource-dev] autobuild with VS2005

[Marine Kelley]

That did the trick ! I could run autobuild without a problem now,
using your vstool.exe, it configured the solution and now I am making
it build the viewer on VCE. I can't stay around to watch though,
especially if it is going to take an hour. Going to bed now, and I'll
keep you posted with my progress.

Thanks again all of you, I was really stuck on this one !

Marine

On 18/04/2011, Nicky Perian  wrote:
> -DUNATTENDED:BOOL=ON  I think this on the configure command line will solve
> the
> vstool.exe issue. If it doesn't make an empty project with the output of
> vstool.exe and replace the existiing one. Or, you can use the one I have
> here:
> http://dl.dropbox.com/u/7833186/VSTool.exe
>
> Nicky
>
>
> ____
> From: Marine Kelley 
> To: Ima Mechanique 
> Cc: opensource-dev@lists.secondlife.com
> Sent: Mon, April 18, 2011 2:59:27 PM
> Subject: Re: [opensource-dev] autobuild with VS2005
>
> Aha ! Thanks much Ima, I'll play a little with a clone of your
> repository tomorrow, maybe it will lead me to a full working build
> this time :)
>
> On 18/04/2011, Ima Mechanique  wrote:
>>> Thanks... this convinces me to go with VCE2010 (getting over the
>>> initial gripe I have about it, since it is the only sensible option I
>>> have to go ahead anyway).
>>>
>>> Right now it builds to the end, but it fails at the very last step
>>> with this error :
>>>
>>> 60>  Looking for existing VisualStudio instance...
>>> 60>Didn't find open solution, starting new background VisualStudio
>>> instance...
>>> 60>Reading .sln file version...
>>> 60>Using version: VC100...
>>> 60>  Value cannot be null.
>>> 60>  Parameter : type
>>>
>>> Seems to be vstool complaining that it cannot find the instance of VS
>>> when calling GetDTEAndSolution() in main.cs... although VCE is open.
>>> Autobuild does that too on the command line. What can I do to make it
>>> find VCE and modify the solution ? I'm thinking some path is missing
>>> from my PATH env variable but I can't figure out which.
>>
>> I can't swear to it (I don't use the 'official' autobuild.xml), but as I
>> recall, that is a known problem for express, that should be fixed with
>> the OPEN-50 stuff that's coming soon ;-) VCE can't modify the solution
>> this way, it doesn't have the API required for it. This is one of the
>> many differences between Express and full versions.
>>
>>
>>> Thanks again
>>>
>>>
>>> On 18/04/2011, Ima Mechanique  wrote:
>>> >> Thank you all for the pointers.
>>> >>
>>> >> So if I get this right, VS2005 is to be left behind... not really kind
>>> >> to people who are used to it, and who find 2010 to be an unbearable
>>> >> bloatware that runs 4x slower than the old IDE. Not mentioning that
>>> >> with 2005, at least I could do something else while compiling. With
>>> >> this one, I can do something else... as long as it's away from my
>>> >> computer.
>>> >
>>> > Not so much that 2005 is being left behind, but that LL is moving
>>> > forward. They cannot stay with the same environment when the Operating
>>> > Systems are moving forward; for many reasons.
>>> > How fast VC10 runs depends a LOT on your system and configuration. When
>>> > I first used autobuild with it, it took the same time to build the
>>> > viewer as 2005 had (approximately) However this turned out to be
>>> > because
>>> > I was not using some of the optimisations possible that 2005 had been
>>> > using. With these enabled, it is now 35 minutes faster than 2005.  Yes,
>>> > it is a resource hog, but that's how it gets to be faster, you can
>>> > change default values to prevent that if you want to, I make a cup of
>>> > coffee and do something else ;-) Also, autobuild is designed to use the
>>> > command line, not the IDE which is a great part of the resource eating.
>>> > Intellisense is a pain in the ... RAM, disc I/O, etc. for example.
>>> >
>>> > As has been said already, autobuild started on the 2005 build, if you
>>> > want to continue using it you will need to collect all the 2005 build
>>> > versions of the libraries and create a configuration file that uses
>>> > them
>>> > instead of the default one which uses 2010 builds.
>>

[opensource-dev] Fmod with Autobuild ?

[Marine Kelley]

Hello all,

Yes, this is probably another stupid question... I have a working
viewer 2.6.6 with all my patches installed, everything is working
right. But since I had to run autobuild with the DINSTALL_PROPRIETARY
flag set to FALSE (it wouldn't work otherwise), there is no Fmod,
hence no sound.

Is it possible for me to add a prebuilt Fmod library from another
(maybe older) viewer to this one to get the sound back ? Or do I have
to make autobuild download Fmod somehow in order to build the viewer
with sound ? I cannot really release a viewer without sound...

Thanks in advance,
Marine
___
Policies 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] Fmod with Autobuild ?

[Marine Kelley]

Thank you WolfPup, it took me a while to actually understand where
this JIRA was coming from, and where it was going... lots of info in
there.

I managed to finally compile with fmod, and to make the viewer run.
For the people who still have issues with the whole process, here is
what I did :

- Downloaded fmodapi375win.zip from the fmod website. I actually did
this 3 years ago but this zip is still up to date, and I'm glad it is
:)
- Zipped the contents of the fmodapi375win folder into
fmodapi375win.tar.bz2 (7z can do that)
- Placed fmodapi375win.tar.bz2 somewhere easily reachable (mine was in D:\SL)
- Modified autobuild.xml :
fmod > windows > url  = file:///SL/fmodapi375win.tar.bz2
fmod > windows > hash = (the hash of this file that I calculated
after zipping it)
made sure that -DFMOD is set to TRUE
- Ran autobuild, fmod was extracted correctly
- Copied fmodapi375win.tar.bz2 into D:\SL\linden\ and extracted it
there. I did this because otherwise fmod.h and fmod_errors.h wouldn't
be found when trying to build llaudio (adding the path to fmod.h into
the llaudio include paths works as well, but for some reason it still
fails at the end of the build, so actually extracting to
fmodapi375win/ is better and easier)
- Built the viewer, had a failure with VivoxAUP.txt (never heard of
this one, anybody ran into this ?) but secondlife-bin.exe was built
- Copied app_settings/, character/, fonts/, skins/ and gpu_table.txt
into the release/ folder as usual, tried to run the viewer but had a
0xc07b failure... it took some time to find out that some dlls had
not been copied. So I copied libeay32.dll, ssleay32.dll, winmm.dll,
zlib1.dll and maybe a couple more into release/, and miracle, it
works. And I haz sound !

Marine

On 29/04/2011, WolfPup Lowenhar  wrote:
> Actually STORM-1023 helped to solve this issue for OS Devs. Also my comment
> here
> https://jira.secondlife.com/browse/STORM-1023?focusedCommentId=246855&page=c
> om.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-2468
> 55 explains exactly what I had to do to make a 'local' package to use in the
> autobuild system. And then using a file:/// url pointing to the new package
> in the autobuild.xml along with the new hash that is generated I build the
> development viewer every day and also have sonde using fmod in a windows
> environment.
>
>> -Original Message-
>> From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-
>> boun...@lists.secondlife.com] On Behalf Of Marine Kelley
>> Sent: Thursday, April 28, 2011 6:11 PM
>> To: opensource-dev@lists.secondlife.com
>> Subject: [opensource-dev] Fmod with Autobuild ?
>>
>> Hello all,
>>
>> Yes, this is probably another stupid question... I have a working
>> viewer 2.6.6 with all my patches installed, everything is working
>> right. But since I had to run autobuild with the DINSTALL_PROPRIETARY
>> flag set to FALSE (it wouldn't work otherwise), there is no Fmod,
>> hence no sound.
>>
>> Is it possible for me to add a prebuilt Fmod library from another
>> (maybe older) viewer to this one to get the sound back ? Or do I have
>> to make autobuild download Fmod somehow in order to build the viewer
>> with sound ? I cannot really release a viewer without sound...
>>
>> Thanks in advance,
>> Marine
>> ___
>> Policies 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.1325 / Virus Database: 1500/3603 - Release Date: 04/28/11
>
> ___
> Policies 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] Debug console changes -- feedback sought

[Marine Kelley]

Whoops once again I replied to Jonathan only instead of the whole
list. Sorry about that. Here is what I tried to answer :

It should be copiable and pastable ! The debug console is nigh useless
without these two features.



On 11/06/2011, Jonathan Welch  wrote:
> If you use the debug console (Ctrl+Shift+4) I would like your feedback
> on some changes I would like to make to it:
> 1) Widen the lines from 50% of the screen width to 75%
> 2) Reduce the spacing between lines from 8px to 1px
> 3) Swap the foreground and background colors (I am not sure how
> effective this change would be, maybe it would be better to leave the
> colors as-is).
>
> Please take a look at https://jira.secondlife.com/browse/VWR-25987 and
> comment.
>
> Thank you,
>
> -Jonathan
> ___
> Policies 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] Debug console changes -- feedback sought

[Marine Kelley]

Guess we learn everyday. Thanks for that :)

On 11/06/2011, Jonathan Welch  wrote:
> The debug setting showconsoleWindow gives you a free-standing window
> with the same information scrolling by in it.
>
> In Windows I get a dos-type window, so copying and pasting is not as
> easy as it should be.
>> It should be copiable and pastable ! The debug console is nigh useless
>> without these two features.
> ___
> Policies 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] ER-480 fix brought a showstopper

[Marine Kelley]

Hi all,

Has anybody noticed this already ? Basically the current viewer in v-d
has a malformed notifications.xml file, breaking it completely as soon
as you raise the camera controls floater.

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

If it hits viewer-release, this will become a showstopper right away.
Suggest immediate fixin'.

Marine
___
Policies 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] More proposals for draw distance slider icon (Mike Chase)

[Marine Kelley]

How about a pair of round glasses in orthographic view, seen from a
quarter profile ?

Something like this (forgive the lack of alignment on non-fixed fonts) :

/ /
O-O

This icon is not used anywhere and has no special meaning, if you put
them on you see better that if you remove them (if you're
short-sighted that is), it would not be confused with search (as a
magnifying glass or a pair of binoculars would) or the world map (as a
globe would), and would be easy to draw in 16x16 because there is no
filling to do, just thin strokes.

Just my L$5

Marine

On 15/06/2011, Opensource Obscure  wrote:
> On Wed, Jun 15, 2011 at 02:38, Carlo Wood  wrote:
>> On Tue, 14 Jun 2011 13:49:30 -0500
>> Daniel  wrote:
>>
>>> For the icon, label it "DD" for draw distance.  That will fit in
>>> 16x16 pixels, and not conflict with other symbols.
>>
>> I like this idea. Made an icon for it:
>
> unclear.
>
> Opensource Obscure
> --
> http://twitter.com/oobscure - http://opensourceobscure.com/lol
> discuss Second Life Viewer 2: http://j.mp/slv2group
> ___
> Policies 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] Question about DD philosophy.

[Marine Kelley]

I think (correct me if I'm wrong) that everytime you increase your
draw distance, your viewer requests all the prims to rez from the
sim... Which means a lot more network traffic if it changes all the
time (which would be the case if it were automatic).

Besides I like to keep control over my draw distance. I vote for
keeping it manual.

Marine

On 16/06/2011, Lee ponzu  wrote:
> I have sometimes wondered why this is not more automagic, or maybe why the
> magic approach doesn't work well enough.
>
> Suppose my DD is set to 256.  Upon detecting a poor FPS, the viewer could
> remember the DD, and then reduce it temporarily to 32.  As FPS becomes
> acceptable, it increases it little by little until it is 256 again.  Is
> there not code sort of like that already in there?  (I know, I could go
> look, but I have fallen way behind on the source code and the builds, so all
> I do now is kvetch from the outside).
>
> A similar approach would be to slowly adjust the DD to keep FPS acceptable.
>
> It seems like these DD slider changes are exactly giving the user a manual
> way to do this. Why not just have the viewer do it?
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Viewer development 2.8.1 and a few new bugs

[Marine Kelley]

Hi all,

I was trying to adapt the RLV to the latest revision of
viewer-development, and was quite satisfied with the results :

- Far fewer crashes as opposed to 2.7.2 when the deferred renderer is activated
- The "/me" issue in chat when the chat history is hidden is resolved too

However, I am running into a few new issues, and I wonder if anyone
spotted them too :

- Invisiprims don't render well, they are completely black UNLESS they
are set to fullbright (no matter whether deferred shading is on or
off)
- Alpha doesn't render well either, once again unless fullbright is
on. Full strands of hair disappear, it's really ugly
- The viewer slows down to a crawl when attaching or detaching objects
(this is not a RLV bug, I've tested and observed this into the vanilla
viewer too). Worse, if a second inventory window is visible but
minimized, often it will bring it up !
- And the "/me" bug has now migrated to the chat history itself. It
works on the chat floater, but if I say "/me smiles", I'll see "Marine
KelleyMarine Kelley smiles" on the history. This is NOT due to the
"Loading" bug though, this one is completely different and new.

Is any of these new bugs in a JIRA already ? I don't even know what or
where to search... Any pointer is appreciated.

Thanks,
Marine
___
Policies 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 development 2.8.1 and a few new bugs

[Marine Kelley]

Thanks... That's not what I observe though, only the invisiprim goes
black, obscuring the prims inside or behind it, but not the entire
linkset

On 12/07/2011, Ardy Lay  wrote:
> Shining SH-2048 Invisiprims that are members of an attached linkset are
> making the entire linkset invisible.
> https://jira.secondlife.com/browse/SH-2048
>
>
>
___
Policies 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] llconvexdecomposition on private servers

[Marine Kelley]

Hi all,

When trying to build rev 20010 (0fd2a1181a96) of viewer-development, I
stumbled across a problem with llconvexdecomposition : autobuild.xml
links it to http://s3-proxy.lindenlab.com/private-builds-secondlife-com
(which is unreachable for anyone outside LL), refusing to download it
and leaving me with an old and non source-controlled
llconvexdecomposition.h in packages/include/.

As a result, llmeshrepository.cpp fails to compile because :

- LLConvexDecomposition::getInstance()->setMeshData() should now take
2 arguments whereas the old class only declared one in its pure
virtual method (ok that one is trivial to fix)

- LLConvexDecomposition::getInstance()->buildSingleHull() is not
declared or defined anywhere

- Same for LLConvexDecomposition::getInstance()->getSingleHull(), not
declared or defined anywhere

I assume the latter two fail because these methods are neither
declared in llconvexdecomposition.h nor defined in the lib I have,
whereas they must be in the new ones.

Is there a way to get the updated package please ? I will try to walk
around the problem but sooner or later it will come back and bite me.

FYI, this comes from the merge at rev 19901 (73b94c4e3f81)

Thanks,
Marine
___
Policies 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] llconvexdecomposition on private servers

[Marine Kelley]

Thanks. That doesn't solve my problem though... I am always using
ReleaseOS, and I already had my FMOD package ready with its hash (all
included in my autobuild.xml file long ago), all was ready there. My
only problem is with the llconvexdecomposition package. What I did in
order to build my RLV was this :

- Add the missing bool in the method declaration

- Turn "#if 1" into "#if 0" in llmeshrepository.cpp

Still, that deactivates things that I don't think should be deactivated.

On a side note, while testing this viewer I have noticed that the
"Ruler" drop-down combo list has moved from the Build window into the
Options floater of said window. One more click is now needed and even
more screen real estate is now required in order to do something that
was easier before, with no positive counterpart for this change.
Seriously... I can foresee that this is going to piss off a lot of
people...

On 06/08/2011, WolfPup Lowenhar  wrote:
> That will happen when you are using the build configurations that do not end
> in OS as the llconvexdecomposition lib is a private lib using Havok source
> code.
>
> The following configurations will build in an Open Source Evnironment:
>
> DebugOS
> RelWithDebInfoOS
> ReleaseOS
>
> If you are on Windows there s one 3p lib that you will have to build
> yourself so that you have sound and that is for Fmod and then you can edit
> the autobuild.xml to use a file:/// url pointing to the package you just
> built also do not forget to change the hash to match the one for the new
> file.
>
>> -Original Message-
>> From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-
>> boun...@lists.secondlife.com] On Behalf Of Marine Kelley
>> Sent: Saturday, August 06, 2011 5:04 AM
>> To: opensource-dev@lists.secondlife.com
>> Subject: [opensource-dev] llconvexdecomposition on private servers
>>
>> Hi all,
>>
>> When trying to build rev 20010 (0fd2a1181a96) of viewer-development, I
>> stumbled across a problem with llconvexdecomposition : autobuild.xml
>> links it to http://s3-proxy.lindenlab.com/private-builds-secondlife-com
>> (which is unreachable for anyone outside LL), refusing to download it
>> and leaving me with an old and non source-controlled
>> llconvexdecomposition.h in packages/include/.
>>
>> As a result, llmeshrepository.cpp fails to compile because :
>>
>> - LLConvexDecomposition::getInstance()->setMeshData() should now take
>> 2 arguments whereas the old class only declared one in its pure
>> virtual method (ok that one is trivial to fix)
>>
>> - LLConvexDecomposition::getInstance()->buildSingleHull() is not
>> declared or defined anywhere
>>
>> - Same for LLConvexDecomposition::getInstance()->getSingleHull(), not
>> declared or defined anywhere
>>
>> I assume the latter two fail because these methods are neither
>> declared in llconvexdecomposition.h nor defined in the lib I have,
>> whereas they must be in the new ones.
>>
>> Is there a way to get the updated package please ? I will try to walk
>> around the problem but sooner or later it will come back and bite me.
>>
>> FYI, this comes from the merge at rev 19901 (73b94c4e3f81)
>>
>> Thanks,
>> Marine
>> ___
>> Policies 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.1391 / Virus Database: 1518/3814 - Release Date: 08/05/11
>
> ___
> Policies 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] llconvexdecomposition on private servers

[Marine Kelley]

Thank you for that. I will try when I get the time.

On 06/08/2011, WolfPup Lowenhar  wrote:
> Then try building this lib:
>
> https://bitbucket.org/WolfpupL/llconvexdecompositionos
>
> and use the file method like you do with Fmod to point to the new
> llconvexdecompositionos lib and see if that helps with the build as there is
> a couple of missing functions in the stub. Now the lib is not functional but
> it does have the missing functions.
>
>> -----Original Message-
>> From: Marine Kelley [mailto:marinekel...@gmail.com]
>> Sent: Saturday, August 06, 2011 7:41 AM
>> To: WolfPup Lowenhar
>> Cc: OpenSource Mailing List
>> Subject: Re: [opensource-dev] llconvexdecomposition on private servers
>>
>> Thanks. That doesn't solve my problem though... I am always using
>> ReleaseOS, and I already had my FMOD package ready with its hash (all
>> included in my autobuild.xml file long ago), all was ready there. My
>> only problem is with the llconvexdecomposition package. What I did in
>> order to build my RLV was this :
>>
>> - Add the missing bool in the method declaration
>>
>> - Turn "#if 1" into "#if 0" in llmeshrepository.cpp
>>
>> Still, that deactivates things that I don't think should be deactivated.
>>
>> On a side note, while testing this viewer I have noticed that the
>> "Ruler" drop-down combo list has moved from the Build window into the
>> Options floater of said window. One more click is now needed and even
>> more screen real estate is now required in order to do something that
>> was easier before, with no positive counterpart for this change.
>> Seriously... I can foresee that this is going to piss off a lot of
>> people...
>>
>> On 06/08/2011, WolfPup Lowenhar  wrote:
>> > That will happen when you are using the build configurations that do not
> end
>> > in OS as the llconvexdecomposition lib is a private lib using Havok
> source
>> > code.
>> >
>> > The following configurations will build in an Open Source Evnironment:
>> >
>> > DebugOS
>> > RelWithDebInfoOS
>> > ReleaseOS
>> >
>> > If you are on Windows there s one 3p lib that you will have to build
>> > yourself so that you have sound and that is for Fmod and then you can
> edit
>> > the autobuild.xml to use a file:/// url pointing to the package you just
>> > built also do not forget to change the hash to match the one for the new
>> > file.
>> >
>> >> -Original Message-
>> >> From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-
>> dev-
>> >> boun...@lists.secondlife.com] On Behalf Of Marine Kelley
>> >> Sent: Saturday, August 06, 2011 5:04 AM
>> >> To: opensource-dev@lists.secondlife.com
>> >> Subject: [opensource-dev] llconvexdecomposition on private servers
>> >>
>> >> Hi all,
>> >>
>> >> When trying to build rev 20010 (0fd2a1181a96) of viewer-development, I
>> >> stumbled across a problem with llconvexdecomposition : autobuild.xml
>> >> links it to http://s3-proxy.lindenlab.com/private-builds-secondlife-com
>> >> (which is unreachable for anyone outside LL), refusing to download it
>> >> and leaving me with an old and non source-controlled
>> >> llconvexdecomposition.h in packages/include/.
>> >>
>> >> As a result, llmeshrepository.cpp fails to compile because :
>> >>
>> >> - LLConvexDecomposition::getInstance()->setMeshData() should now take
>> >> 2 arguments whereas the old class only declared one in its pure
>> >> virtual method (ok that one is trivial to fix)
>> >>
>> >> - LLConvexDecomposition::getInstance()->buildSingleHull() is not
>> >> declared or defined anywhere
>> >>
>> >> - Same for LLConvexDecomposition::getInstance()->getSingleHull(), not
>> >> declared or defined anywhere
>> >>
>> >> I assume the latter two fail because these methods are neither
>> >> declared in llconvexdecomposition.h nor defined in the lib I have,
>> >> whereas they must be in the new ones.
>> >>
>> >> Is there a way to get the updated package please ? I will try to walk
>> >> around the problem but sooner or later it will come back and bite me.
>> >>
>> >> FYI, this comes from the merge at rev 19901 (73b94c4e3f81)
>> >>
>> >>

Re: [opensource-dev] Concerned about frequent crashes

[Marine Kelley]

I crash a lot on 2.8.0, at least twice a day. It is usually a sudden
crash to desktop, and from the log it looks like the viewer goes short
on memory. It happens more often with deferred rendering on, but it is
always random, I could never link it to any particular action I take.
My computer has 4GB memory, and is running Win 7 that takes 1.5GB all
by itself. But I would believe that 2GB should be enough for the SL
viewer... It keeps eating more and more memory though. Seems there is
a huge memory leak in the deferred renderer.

On 07/08/2011, Lee ponzu  wrote:
> I am concerned that the latest viewers have been crashing a lot for the last
> week or two.  I crash as often as 3 times per hour.  I attach one crash
> report below.  Is this problem known and being worked on, or is it just me?
>  I am sort of a canary in the coal mine because this is an older iMac and I
> use Satellite internet, so maybe I expose problems that don't crash other
> people.
>
> Question:  When OS X pops up a Problem Report for a crashed app, and says
> the report is being sent to Apple, do those actually go anywhere?  Is there
> any maybe automated analysis and statistics done?  If not, would it be
> useful?  Maybe I could help there.
>
> ponzu
>
> Process: Second Life [908]
> Path:/Applications/Viewers/Project Viewer -
> Mesh.app/Contents/MacOS/Second Life
> Identifier:  com.secondlife.indra.viewer
> Version: Second Life version 2.8.2.237321 (2.8.2.237321)
> Code Type:   X86 (Native)
> Parent Process:  launchd [631]
>
> Date/Time:   2011-08-07 13:26:05.591 -0400
> OS Version:  Mac OS X 10.6.8 (10K549)
> Report Version:  6
>
> Interval Since Last Report:  228428 sec
> Crashes Since Last Report:   4
> Per-App Interval Since Last Report:  29574 sec
> Per-App Crashes Since Last Report:   3
> Anonymous UUID:  18404959-AFD8-476A-807F-8B2EE7A368F6
>
> Exception Type:  EXC_CRASH (SIGQUIT)
> Exception Codes: 0x, 0x
> Crashed Thread:  1  Dispatch queue: com.apple.libdispatch-manager
>
> Thread 0:  Dispatch queue: com.apple.main-thread
> 0   libSystem.B.dylib 0x91b75c5a __kill + 10
> 1   libSystem.B.dylib 0x91b75c4c kill$UNIX2003 + 32
> 2   libSystem.B.dylib 0x91c085a5 raise + 26
> 3   libllcommon.dylib 0x04965480
> default_unix_signal_handler(int, __siginfo*, void*) + 432
> 4   libSystem.B.dylib 0x91b7b05b _sigtramp + 43
> 5   libSystem.B.dylib 0x91b40f56 wait4 + 10
> 6   libSystem.B.dylib 0x91ba25e5 pclose + 215
> 7   libllcommon.dylib 0x04a333de LLMemoryInfo::loadStatsMap() +
> 3598
> 8   libllcommon.dylib 0x04a34763 LLMemoryInfo::refresh() + 35
> 9   libllcommon.dylib 0x04a401ee FrameWatcher::tick(LLSD const&)
> + 606
> 10  libllcommon.dylib 0x04a356d2
> boost::detail::function::function_obj_invoker1 boost::_mfi::mf1,
> boost::_bi::list2, boost::arg<1> > >, bool,
> LLSD const&>::invoke(boost::detail::function::function_buffer&, LLSD const&)
> + 82
> 11  com.secondlife.indra.viewer   0x0175e689
> boost::signals2::detail::signal1_impl float, std::less, boost::function,
> boost::function,
> boost::signals2::mutex>::slot_invoker::m_invoke(boost::shared_ptr boost::optional >, boost::signals2::slot1 boost::function >, boost::signals2::mutex> > const&,
> ...) const + 57
> 12  com.secondlife.indra.viewer   0x0175e94d
> boost::signals2::detail::signal1_impl float, std::less, boost::function,
> boost::function,
> boost::signals2::mutex>::operator()(LLSD const&) + 525
> 13  libllcommon.dylib 0x049a71df LLEventStream::post(LLSD
> const&) + 63
> 14  com.secondlife.indra.viewer   0x000de32d LLAppViewer::mainLoop() + 1453
> 15  com.secondlife.indra.viewer   0x01350918 main + 568
> 16  com.secondlife.indra.viewer   0x9ad6 start + 54
>
> Thread 1 Crashed:  Dispatch queue: com.apple.libdispatch-manager
> 0   libSystem.B.dylib 0x91b3b382 kevent + 10
> 1   libSystem.B.dylib 0x91b3ba9c _dispatch_mgr_invoke + 215
> 2   libSystem.B.dylib 0x91b3af59 _dispatch_queue_invoke + 163
> 3   libSystem.B.dylib 0x91b3acfe _dispatch_worker_thread2 + 240
> 4   libSystem.B.dylib 0x91b3a781 _pthread_wqthread + 390
> 5   libSystem.B.dylib 0x91b3a5c6 start_wqthread + 30
>
> Thread 2:
> 0   libSystem.B.dylib 0x91b14afa mach_msg_trap + 10
> 1   libSystem.B.dylib 0x91b15267 mach_msg + 68
> 2   libexception_handler.dylib 0x04d27bcd
> google_breakpad::ExceptionHandler::WaitForMessage(void*) + 125
> 3   libSystem.B.dylib 0x91b42259 _pthread_start + 345
> 4   libSystem.B.dylib 0x91b420de thread_start + 34
>
>
>
>
>
> Second Life 2.8.2 (237321) Jul 29 2011 17:51:01 (Project Viewer - Mesh)
> Release Notes
>
> CPU: Intel(R) Core(TM)2 Duo CPU T7700  @ 2.40GHz (2400 MHz)
> Memory: 3072 MB
> OS Version: Mac O

Re: [opensource-dev] Unjust Banning of residents?

[Marine Kelley]

Careful, it could be a phishing attempt. Do NOT click on any of the
links inside this email (unless you're certain it comes from Linden
Lab, but then again emails can be spoofed).

On 16/08/2011, mala...@tamzap.com  wrote:
> exactly which is why this message is so disturbing. accounts have been
> terminated from second life for using a viewer not listed in the
> directory.
>
>
> "This email is notification that Linden Lab has terminated
> your access to the Second Life virtual world due to severe
> or repeated violations of the Second Life Terms of Service
> or Community Standards. Your (account name 'xx') and
> alternate Second Life accounts have been
> made permanently inaccessible."
>
>
> On Tue, 16 Aug 2011 13:33:39 -0400, Erin Mallory wrote:
>> Last I checked there is no requirement to use an approved tvp. even
>> on the tvp listing page. Looking at the policy and the directory
>> pages, no where does it say that the viewer must be listed in the
>> tvp...
>> http://secondlife.com/corporate/tpv.php
>> http://wiki.secondlife.com/wiki/Third_Party_Viewer_Directory
>>
>> "You may connect to Second Life using software released by a
>> third-party developer. Linden Lab provides a Policy on Third-Party
>> Viewers [1] to promote a positive and predictable experience for all
>> Second Life Residents."
>>
>>> Date: Tue, 16 Aug 2011 10:23:21 -0700
>>> From: mala...@tamzap.com
>>> To: opensource-dev@lists.secondlife.com
>>> Subject: [opensource-dev] Unjust Banning of residents?
>>>
>>> Violation: Third Party Viewer Usage
>>> You are connecting to the grid with a viewer that is not in the
>> third
>>> party viewer directory.
>>>
>>>
>>> However...
>>>
>>> A viewer does not need to be on the Third Party Viewer Directory in
>>> order for development or usage of it to be compliant with the Third
>>
>>> Party Viewer Policy (see Policy on Third-Party Viewers | Second
>> Life)
>>> and the Terms of Service. While I am sure you are well aware of
>> this, it
>>> can also be deduced through common sense that the open source
>> program
>>> (Snowstorm, Snowglobe, etc) would not be able to exist in an
>> environment
>>> where every personal compile had to be listed on the TPVD before it
>>
>>> could even begin to undergo any form of live quality assurance
>>> processes.
>>>
>>> Long story short, unless there have been recent changes to the
>> Terms of
>>> Service that I am unaware of, or if there are relevant sections
>> that I
>>> have missed that indicate that a viewer that complies with the
>> Third
>>> Party Viewer Policy still must be in the Directory to be
>> legitimately
>>> used, I would request that you provide me with them.
>>>
>>> What this means is every single BETA tester for every client on the
>>
>>> TPVD is at risk of losing their accounts because that compiled
>> version
>>> of that client is not listed on the TPVD. Each and every Developer
>> who
>>> has worked so hard to help Linden Lab build their Client into what
>> it is
>>> is at risk of losing their accounts because each time they
>> recompile the
>>> source it isn't listed in the TPVD and is now considered a
>> Violation of
>>> some hidden TOS clause.
>>>
>>>
>>> I am posting this to this forum because I wanted to get feed back
>> from
>>> the community. As I myself and a developer who has contributed
>> patches
>>> to various TPVD Clients and am now finding myself cautious to even
>> use
>>> these clients source codes to help them. I would like clarification
>> from
>>> Linden Lab as well as other Developers on this new banning policy
>> that
>>> is requiring every compiled client that connects to second life to
>> be
>>> listed in the TPVD.
>>> ___
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>>
>> Links:
>> --
>> [1] http://secondlife.com/corporate/tpv.php
>
> ___
> Policies 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] How to upload a mesh on v-d rev 20205 ?

[Marine Kelley]

Hi all,

So I have tried to upload a mesh on a viewer built from v-d rev 20205
(the latest I could find, with the llconvexdecomposition fix).

I click on Build > Upload > Model..., I get the dialog to select a
.dae file, when I select it I get the model upload window, so far so
good.

But when I press on the "calculate weights & fee" button, I get some
kind of overlay debug message saying "Mesh Uploads: 0" (on a side note
that message stacks on others and I don't know how to clear it without
reloading, I see in the code that it's a "temporary hack", but it has
made its way into the official viewer v3.0.3 as well), and nothing
happens. The upload fee stays "TBD", as well as "download", "physics"
and "server", and the Upload button never becomes available. I guess
my viewer never receives the response from the sim.

I have made the exact same manipulation on the official v3.0.3 with
the same mesh and succeeded, the price came right through and I got a
"Mesh Uploads: 1" message.

Is there something I need to do in my viewer for it to work ? Is it a
matter of channel ? Am I missing something there ?

Thanks in advance,
Marine
___
Policies 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 to upload a mesh on v-d rev 20205 ?

[Marine Kelley]

Thanks... I wouldn't have guessed that all by myself. lol.

I see on that JIRA entry that I'm not the only one who is confused one
about this issue. I'll give a try to the open source version when
able, it seems promising.

Marine

On 24/08/2011, Oz Linden (Scott Lawrence)  wrote:
> On 2011-08-24 14:47, Marine Kelley wrote:
>> So I have tried to upload a mesh on a viewer built from v-d rev 20205
>> (the latest I could find, with the llconvexdecomposition fix).
>> [...]
>> Is there something I need to do in my viewer for it to work ? Is it a
>> matter of channel ? Am I missing something there ?
>
> Yes... you're missing the (commercial) Havok library that we use to
> create the convex decomposition of the model.
>
> The short version is that unless you license Havok, you can't build a
> viewer today that does model uploads.
>
> A few people have been working on an open source solution - watch OPEN-105.
>
>
>
> ___
> Policies 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] Current status of Mesh??

[Marine Kelley]

On 31/08/2011, Robert Martin  wrote:

> 2 are there any simple tools to make models (Blender does not qualify).

Why doesn't Blender qualify ?
___
Policies 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] Current status of Mesh??

[Marine Kelley]

On 01/09/2011, Lance Corrimal  wrote:
> Am Donnerstag, 1. September 2011 schrieb Marine Kelley:
>> On 31/08/2011, Robert Martin  wrote:
>> > 2 are there any simple tools to make models (Blender does not
>> > qualify).
>>
>> Why doesn't Blender qualify ?
>
> try it, then look at the word "simple" again :)

Heh, I've been using it steadily for two years now, and two of my
best-selling items have been created with it... It's not simple
indeed, its learning curve is almost flat ("steep" would mean exactly
the opposite : it takes a long time to learn something on Blender so
the curve is flat rather than steep), but it is extremely consistent
and actually you can become very productive when you get used to its
bizarre UI. But unlike Maya, it is made by developers with a developer
mindset, which suits me better since I am no 3D artist. Maya is more
powerful, 3D artists are more productive with it, but it is also
infinitely more expensive than Blender :p

So for a tourist like me, Blender is the tool of choice.
___
Policies 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 to read minidumps

[Marine Kelley]

The Shadok is strong in this one...

On 04/10/2011, Henri Beauchamp  wrote:
> On Tue, 4 Oct 2011 12:23:51 +0200, Thickbrick Sleaford wrote:
>
>> On Tuesday 04 October 2011 09:31:00 Lance Corrimal wrote:
>> > hi,
>> >
>> > I'm pretty sure noone at LL is interested in the minidumps from my
>> > TPV, so I'll have to read them myself... how do i do that?
>>
>> At least on the Linux side, breakpad provides minidump_stackwalk,
>> which takes a minidump file and a symbols file and produces a stack
>> trace. That executable is not provided with the linden-packaged
>> breakpad though. You will also need to make sure the symbols file
>> you are using is from the same build that produced the minidump.
>
> We've got a saying for this kind of silliness, in France:
> "Pourquoi faire simple quand on peut faire compliqué ?"
> ("Why doing it the simple way when you can find a complex way to
> do it ?")
>
> I guess the stack_trace.log file what just too simple in LL's view...
> * rolls eyes and shakes head, sighing deeply *
>
> 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

[opensource-dev] Need help about EXT-1285

[Marine Kelley]

Hi all ! I need help !

I'm working on adapting my RLV to version 3.2.0 of the viewer, and
hitting a wall here. Let me explain the problem :

In V1.x, script dialog boxes (the blue menus) were located on the
upper right corner of the screen, with a fixed size text area in which
the script could write what it wanted (up to 512 chars), with a
scrollbar when needed. Then there were the buttons below that area.
This had a nice side effect though, the buttons were always at the
same place on the screen, so for repetitive tasks with dialogs you
knew well, you didn't have to actually read before clicking.

The scrollbar wasn't very practical, so LL decided to move the dialogs
down to the lower right corner of the screen in v2.x, in exchange of
making the dialogs variable in size. Best of both worlds, the dialogs
were showing all the info at first glance without the need for a
scrollbar, and the buttons were always at the same spot (although the
sidebar was complicating things a little, but it was still workable).

Now in v3 the dialogs are back to the upper right corner of the screen
as part of EXT-1285 (coded and released by Seth Productengine). Ok,
but no scrollbar means the buttons are NOT always at the same place
anymore and that... is unacceptable to me. I absolutely need to change
this, this is not practicable as it is.

So I have two options. Either leave the dialogs where they are now and
move the buttons of the dialog window BEFORE the text, or move the
dialogs back to the lower right corner of the screen.

Option 1 is good for v1 users, but a little confusing since the
dialogs would not look like they always did. However I have spent some
time looking for a way to do this, and never found HOW to move these
buttons up before the text. I know the dialog is roughly defined in
notifications.xml under the name "ScriptDialog", but I don't see where
the list of buttons is constructed. The point of this email is partly
to ask how to do this.

Option 2 is good for v2 users, however it has a nasty side-effect :
notification boxes ("are you sure you want to quit" and such) are
linked to the tool bar or something. I haven't found where to change
that and this is also the point of this email.

I prefer option 1 personally, but I fear moving the buttons would look
like a lame hack. Can anybody give me pointers about how to implement
either option please ? Or better, both options !

Thank you in advance,
Marine
___
Policies 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] Need help about EXT-1285

[Marine Kelley]

Thanks WolfPup. With this change and a couple other tweaks, I could
finally get an inverted dialog box, which achieves exactly what I
wanted with my option 1.

Kudos !
Marine

On 31/10/2011, WolfPup Lowenhar  wrote:
> The position of the buttons can be easily move by changing line 87 of
> panel_notification.xml.
> Orginal : follows="left|right|bottom"
> Top placement : follows="left|right|top"  <- this should move the buttons to
> the top of the layout but also might have to move lines 85-99 to the top of
> the xml file as well plus modify the other sections accordingly.
>
>> -Original Message-
>> From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-
>> boun...@lists.secondlife.com] On Behalf Of Marine Kelley
>> Sent: Monday, October 31, 2011 11:54 AM
>> To: opensource-dev@lists.secondlife.com
>> Subject: [opensource-dev] Need help about EXT-1285
>>
>> Hi all ! I need help !
>>
>> I'm working on adapting my RLV to version 3.2.0 of the viewer, and
>> hitting a wall here. Let me explain the problem :
>>
>> In V1.x, script dialog boxes (the blue menus) were located on the
>> upper right corner of the screen, with a fixed size text area in which
>> the script could write what it wanted (up to 512 chars), with a
>> scrollbar when needed. Then there were the buttons below that area.
>> This had a nice side effect though, the buttons were always at the
>> same place on the screen, so for repetitive tasks with dialogs you
>> knew well, you didn't have to actually read before clicking.
>>
>> The scrollbar wasn't very practical, so LL decided to move the dialogs
>> down to the lower right corner of the screen in v2.x, in exchange of
>> making the dialogs variable in size. Best of both worlds, the dialogs
>> were showing all the info at first glance without the need for a
>> scrollbar, and the buttons were always at the same spot (although the
>> sidebar was complicating things a little, but it was still workable).
>>
>> Now in v3 the dialogs are back to the upper right corner of the screen
>> as part of EXT-1285 (coded and released by Seth Productengine). Ok,
>> but no scrollbar means the buttons are NOT always at the same place
>> anymore and that... is unacceptable to me. I absolutely need to change
>> this, this is not practicable as it is.
>>
>> So I have two options. Either leave the dialogs where they are now and
>> move the buttons of the dialog window BEFORE the text, or move the
>> dialogs back to the lower right corner of the screen.
>>
>> Option 1 is good for v1 users, but a little confusing since the
>> dialogs would not look like they always did. However I have spent some
>> time looking for a way to do this, and never found HOW to move these
>> buttons up before the text. I know the dialog is roughly defined in
>> notifications.xml under the name "ScriptDialog", but I don't see where
>> the list of buttons is constructed. The point of this email is partly
>> to ask how to do this.
>>
>> Option 2 is good for v2 users, however it has a nasty side-effect :
>> notification boxes ("are you sure you want to quit" and such) are
>> linked to the tool bar or something. I haven't found where to change
>> that and this is also the point of this email.
>>
>> I prefer option 1 personally, but I fear moving the buttons would look
>> like a lame hack. Can anybody give me pointers about how to implement
>> either option please ? Or better, both options !
>>
>> Thank you in advance,
>> Marine
>> ___
>> Policies 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: 2012.0.1834 / Virus Database: 2092/4586 - Release Date: 10/31/11
>
> ___
> Policies 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] Latest commits break the deferred engine and alpha textures ?

[Marine Kelley]

Hello all,

I have just pulled the latest commits (up to "22037 (1343609b39cf)
merge changes for vmrg-193") and built it, and here is what I observe
when I try it out :

- I can't activate the deferred renderer anymore, even if Lighting &
Shadows is checked in the preferences, with Sun/Moon/Projectors,
ambient occlusion and all.

- Alpha textures are black where they should be transparent

- A lot of textures are missing, simply grey or white, all of them are
supposed to be fully alpha (no visible pixels), like the sides of prim
hair for example

Anybody else sees that ? Or is it just me ?

Thanks,
Marine
___
Policies 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] Help on invisiprims being broken with deferred rendering

[Marine Kelley]

Hi all, and Merry Christmas and Happy New Year (in advance) !

I am working on my RLV and am hitting a wall here. Invisiprims (the
prims that hide a part of your body when you wear shoes or other
pieces of clothing) are completely useless on the latest v-d viewer,
when deferred rendering is active. I know that alpha clothing is
supposed to do the same, but it is not possible to use it in every
case, so I have been trying to fix it myself, to no avail.

A couple months ago, simply backing out the fix to SH-2181 did the
trick, but now the viewer uses OpenGL 3.0 so this solution is
obsolete, since some of the functions it uses are now deprecated.

I have filed a JIRA on this : https://jira.secondlife.com/browse/VWR-27981

I don't have much hope that this will be a high priority for LL, but
it is very important for me that invisiprims work.

Could someone point me into the right direction please ? I have been
looking into the shaders but I don't understand much about them so I'm
at a loss here.

Thanks in advance,
Marine
___
Policies 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 Policy Changes

[Marine Kelley]

I was wondering the same thing.

On 25/02/2012, Skye Menjou  wrote:
> What I am worrying about is that this will also go against RLV, which is in
> wide use, even outside the Adult community.(We use it for some of our
> combat systems).
> LL, are you really trying to force people to use your client and piss off
> most of SL userbase? I haven't seen such a terrible move since M Linden was
> in charge.
>
> On Sat, Feb 25, 2012 at 1:08 PM, Tillie Ariantho  wrote:
>
>> Hello Oskar,
>>
>> > 2.k You must not provide any feature that alters the shared experience
>> of the virtual world in
>> > any way not provided by or accessible to users of the latest released
>> Linden Lab viewer.
>>
>> Ah hm...
>>
>> - What about text based viewers?
>> - What about viewers on mobile devices?
>> - What about special viewers for disabled people, that may have quite some
>> different representation of everything?
>>
>> Or someone's just trying to connect a C64 virtual machine based viewer to
>> SL, with its own, quite unique representation. What about that?
>>
>> The "shared experience" of all those is quite different from the LL
>> viewer.
>>
>> And more:
>>
>> - What about the shared experience of very old LL viewers? Not allowed to
>> copy/clone if its not in the "latest released Linden Lab viewer"?
>> - What about LL viewers in DEV or BETA status? Have TPV devs to wait till
>> a feature is officially out?
>>
>> Is there any grace period till the new policy is enforced? What about
>> grace periods on client changes later, LL client removes something,
>> do TPV devs have to remove it instantly, too (dont say now there is
>> nothing being removed, I remember Avatar Ratings, for example).
>>
>> Tillie
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
>
> --
> Have a nice day,
> Skye Menjou
>
___
Policies 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] Fix for SH-2941 breaks HACD-k ?

[Marine Kelley]

Hello all,

Having pulled the latest changesets from v-d to my viewer lately, I
observed that the resulting build would not be able to upload mesh
anymore, ending up with a MAV_BLOCK_MISSING message every time (no
matter what I do, even following the several options depicted in
https://jira.secondlife.com/browse/MAINT-872).

After some search, it appears that the change 23045 (eab0b05bf0bc)
("SH-2941 Fix for crash on shutdown due to race condition between
LLCurl and LLMesh") is the cause of the error. Reverting
llmeshrepository.cpp (the only file in this changeset) to its previous
version fixes the problem, but negates Dave's fix.

I am aware that HACD-k is not under the responsibility of LL, it is an
open source work, but would someone like to look into this ? I am not
qualified at all, having no clue about how mesh upload works.

Thanks,
Marine
___
Policies 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] Fix for SH-2941 breaks HACD-k ?

[Marine Kelley]

Thanks for the precisions. I am using v178, ported on to Dolphin and
then to my RLV by Lance... I don't know how it works at all,
personally. All I know is that the changeset I pointed is the culprit
for all the errors I get (well, I got only MAV_BLOCK_MISSING so far).
It's deterministic : with the changeset it occurs everytime, without
the changeset it never occurs.

The changeset adds mutexes all over llmeshrepository so maybe it is
related (it makes the upload time out or something). The changes are
many across that file, so I didn't look in detail (I don't have time).

On 14/05/2012, Nicky Perian  wrote:
> Using OpenMP based library.
>
> https://bitbucket.org/NickyP/viewer-development-os-mesh-upload/downloads/Second_Life_3-3-3-db7e740f3883-d84e0f52d036_LindenDeveloper_Setup.exe
>
___
Policies 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] ok this may sound dumb but what is the llphysicsextention package

[Marine Kelley]

Seconded !!

On 08/08/2012, Henri Beauchamp  wrote:
> On Tue, 07 Aug 2012 16:45:03 -0700, Oz Linden (Scott Lawrence) wrote:
>
>> On 2012-08-07 16:09 , Angel Dreams wrote:
>> > its something i saw i never seen that package before is it new or
>> > something?
>>
>> It is the wrapper around the Havok functionality in the viewer.  It
>> replaces (and incorporates) llconvexdecomposition.
>^^
> Which is unfortunate... because Open Source viewers all use HACD to
> replace the closed source llconvexdecomposition.
>
> I'd suggest that the HAVOC stub is kept separate from the
> llconvexdecomposition stub.
>
> 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

[opensource-dev] Camming inside an object makes the camera jump again

[Marine Kelley]

Hi all,

For a month now, any viewer built from the v-d repository has that odd
bug back :

When you focus your camera inside a hollowed-out prim and you move the
camera itself inside it as well, it makes you zoom in instead, making
it very difficult to focus on anything. This bug had been fixed a few
months ago to my great joy, and now it surfaces again.

Does anybody know where to find this "feature" in the code so I can
fix it please ? Any pointer is appreciated.

Thanks,
Marine
___
Policies 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] I just filed two jiras against the current viewer-development source that are kind of bad.

[Marine Kelley]

Confirmed, voted and watched for both. That would explain the strange
behaviors I have been observing on the latest build the last few days.
Thanks for creating these tickets.

On 18/08/2012, Lance Corrimal  wrote:
> https://jira.secondlife.com/browse/VWR-29531
> https://jira.secondlife.com/browse/VWR-29532
>
>
> those two together make 3.4.1 as it is just now pretty much unusable...
>
>
> 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] Serious regression in SSB-enabled regions

[Marine Kelley]

What Henri said. Avatar height offset is a variable that currently
changes OFTEN, that's even the reason why it was added as a RLV
command, so that it could be changed automatically without annoying
the user too much.

If this is now a shape slider, and viewer devs like me have to deal
with accordingly, this means this RLV command will trigger a shape
rebake every time it is issued, which would happen, like I said,
OFTEN. And like Lance mentioned, I'm not even sure this would work on
no-mod shapes anyway.

I'm not saying the old parameter was ideal. In fact it was a just
acceptable solution since it didn't actually modify the altitude of
the avatar but its height, its bounding box. It would have been better
if it were an offset, and we could modify it in X, Y and Z
independently, and beyond [ -0.5, +0.5 ].

I'm saying that this new parameter will make it even less ideal. The
formula for calculating the correct value to send to the viewer via
the RLV command is not trivial, the extrema of this new slider are [
-2.0, +2.0 ] if I'm not mistaken, and we will have to issue the
command in two different ways according to whether we are in a
SSB-enabled region or not. That's a lot of work and development time
for us. Perhaps it is easy for you to add a slider, but this solution
is far, far from ideal for us.

It is currently a debug setting (which name varies from viewer to
viewer). Can't we have a solution that involves a debug setting
instead of a shape slider, so we don't have to rewrite everything ?
Please ?

Marine

On 02/03/2013, Henri Beauchamp  wrote:
> On Fri, 1 Mar 2013 16:20:10 -0500, Nyx Linden wrote:
>
>> https://bitbucket.org/lindenlab/sunshine-external/commits/108ae1ed56ea38426df239ef3247f57fb63d0806
>>
>> Added a new parameter to shapes to replace the viewer-side height offset.
>> Since it is stored in a wearable, the new back end can read and use the
>> value. Will send an email to third party devs later today to let them
>> know
>> to pick up the patch.
>
> ARRRG !
>
> Adding a new parameter to the shape is NOT a suitable way to achieve
> equivalent results as what we could get so far in non-SSB sims: each
> time a new (sit, lay, kneel, crouch, crawl...) animation is played,
> you need to adjust the Z-offset: this can't obviously be achieved by
> each time changing a shape parameter, saving the new shape, and then
> asking for a (full !) rebake: the Z-offset (and more exactly the avatar
> height as requested by the viewer depending on the currently worn shape
> and the Z-offset) needs to be accounted for in real time (like what
> LLAgent::sendAgentSetAppearance() allowed to do), indenpendently of the
> other visual parameters; the shape wearable itself should be left
> untouched when the height is adjusted via the Z offset.
>
>> Marking SUN-38 as resolved.
>
> Nope, I'm sorry, but it's far from resolved 
>
> 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] Not all Open Source developers are honest...

[Marine Kelley]

Henri has been putting a considerable number of hours over several
years into fixing bugs and making improvements, including into other
people's viewers !

If what he says is true (and I have no doubt that it is since it is
easy to verify), this kind of thing is totally unacceptable. TPV
developers ought to behave exemplarily because users put their data
into their hands and trust them not to mess around with it. When one
dev misbehaves, it drops a shade of doubt on every other dev in the
community. I sincerely hope this was a misstep.

On 01/06/2013, Henri Beauchamp  wrote:
> On Sat, 1 Jun 2013 18:57:31 +0200, Martin Fürholz wrote:
>
>> Ah! I misread the “joined” date on that forum page as the “posted” date,
>> this happens all the time :D
>> I’m sorry, last time that I’ve heard anything about Kirstenlee’s viewer
>> was
>> a couple of years ago, and S19 is also a couple of years old, as far as I
>> can tell (and I’m pretty sure about that). See
>> http://virtyou.com/viewer_track/ as a proof (Kirstenlee’s viewer “S20” was
>>
>> built in 2010).
>
> S20 is a v2 viewer, so it's obviously a different branch.
> It is quite possible that Kirsten used the Cool VL Viewer sources and the
> incremental patches I publish with every release to follow my progresses on
> it, but it's obviously the very same viewer with just a couple of patches
> added (a 600Kb diff is NOTHING, especially when you see what the changes
> are about in this diff... a i++ instead of a ++i is not significant a
> change !).
>
> In fact, I don't care if Kirsten forks my viewer, what I care about is that
> he obviously pretends being the person behind the 3000+ hours of coding *I*
> spent on this code over the 6+ years of continuous development !
>
> If anyone got more to say about this matter, please let's move it to the
> Cool VL Viewer forum: I don't want to polute this list more than I already
> did (but I thought it was important to bring up such an issue).
>
> 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

[opensource-dev] Question about the rendering and how to hide textures selectively

[Marine Kelley]

Hi all,

I've been looking and doing trial-and-error for hours, and still haven't
found out how to do this :

I'd like to add a way to the RLV to actually not render the diffuse
textures in world (but still render them on the avatars and their
attachments, and render normal and specular maps in-world as well), both in
deferred and forward rendering. Basically I want the world to look as if no
texture was rezzed, except for the avatars and all their attachments. As a
bonus, I want partly (not totally) transparent surfaces in world to be
opaque and untextured as well.

Anyone among you knows how to do that without butchering the rendering
pipeline ? It shouldn't be hard, but I've been searching for hours for the
spot where the viewer retrieves a texture by its UUID in the fetched
textures, to apply it to a face, but no way to find that.

Thanks for any pointer you could give me,
Marine
___
Policies 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] Question about the rendering and how to hide textures selectively

[Marine Kelley]

Yes I have been looking into them already, but they at best display even
more geometry on top of what's already rendered. I would like not to add
more strain on the rendering than there already is. As for the reason, it
is to go with the new features I'm adding to the RLV v2.9 (see my blog for
details : realrestraint.blogspot.com). In short, it is meant for the avatar
to be "blindfolded" in a more interesting way than just to have a big prim
hogging the screen and blocking the view. I want the immediate vicinity to
be visible but things a little farther to be hidden from view. With all the
camera restrictions that come with it. All that is already done and working
well, but I want the textures to be hidden (save for the bump & shine),
because the color of a surface is not supposed to be visible, only the
"touch feeling" of it. On a side note, this won't be appropriate only for
blindfolds, but also for mazes and multiplayer games where the camera is
supposed to be restricted to be close to the avatar.


On 12 June 2014 15:28, Ambrosia  wrote:

> Why not look at parts of the code that get used for fancy displays already?
>
> For example the development -> render metadata -> physics(?) dipslay. It
> removes all in-world textures and shows physics as colors on the objects.
>
> I am sure you can find something interesting in that code.
>
> --Chalice Yao
>
>
> On Thu, Jun 12, 2014 at 2:33 PM, Marine Kelley 
> wrote:
>
>> Hi all,
>>
>> I've been looking and doing trial-and-error for hours, and still haven't
>> found out how to do this :
>>
>> I'd like to add a way to the RLV to actually not render the diffuse
>> textures in world (but still render them on the avatars and their
>> attachments, and render normal and specular maps in-world as well), both in
>> deferred and forward rendering. Basically I want the world to look as if no
>> texture was rezzed, except for the avatars and all their attachments. As a
>> bonus, I want partly (not totally) transparent surfaces in world to be
>> opaque and untextured as well.
>>
>> Anyone among you knows how to do that without butchering the rendering
>> pipeline ? It shouldn't be hard, but I've been searching for hours for the
>> spot where the viewer retrieves a texture by its UUID in the fetched
>> textures, to apply it to a face, but no way to find that.
>>
>> Thanks for any pointer you could give me,
>> Marine
>>
>> ___
>> Policies 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] Question about the rendering and how to hide textures selectively

[Marine Kelley]

Oh, right, I didn't think of looking into the "Highlight Transparent"
feature, thanks !


On 12 June 2014 16:11, Marine Kelley  wrote:

> Yes I have been looking into them already, but they at best display even
> more geometry on top of what's already rendered. I would like not to add
> more strain on the rendering than there already is. As for the reason, it
> is to go with the new features I'm adding to the RLV v2.9 (see my blog for
> details : realrestraint.blogspot.com). In short, it is meant for the
> avatar to be "blindfolded" in a more interesting way than just to have a
> big prim hogging the screen and blocking the view. I want the immediate
> vicinity to be visible but things a little farther to be hidden from view.
> With all the camera restrictions that come with it. All that is already
> done and working well, but I want the textures to be hidden (save for the
> bump & shine), because the color of a surface is not supposed to be
> visible, only the "touch feeling" of it. On a side note, this won't be
> appropriate only for blindfolds, but also for mazes and multiplayer games
> where the camera is supposed to be restricted to be close to the avatar.
>
>
> On 12 June 2014 15:28, Ambrosia  wrote:
>
>> Why not look at parts of the code that get used for fancy displays
>> already?
>>
>> For example the development -> render metadata -> physics(?) dipslay. It
>> removes all in-world textures and shows physics as colors on the objects.
>>
>> I am sure you can find something interesting in that code.
>>
>> --Chalice Yao
>>
>>
>> On Thu, Jun 12, 2014 at 2:33 PM, Marine Kelley 
>> wrote:
>>
>>> Hi all,
>>>
>>> I've been looking and doing trial-and-error for hours, and still haven't
>>> found out how to do this :
>>>
>>> I'd like to add a way to the RLV to actually not render the diffuse
>>> textures in world (but still render them on the avatars and their
>>> attachments, and render normal and specular maps in-world as well), both in
>>> deferred and forward rendering. Basically I want the world to look as if no
>>> texture was rezzed, except for the avatars and all their attachments. As a
>>> bonus, I want partly (not totally) transparent surfaces in world to be
>>> opaque and untextured as well.
>>>
>>> Anyone among you knows how to do that without butchering the rendering
>>> pipeline ? It shouldn't be hard, but I've been searching for hours for the
>>> spot where the viewer retrieves a texture by its UUID in the fetched
>>> textures, to apply it to a face, but no way to find that.
>>>
>>> Thanks for any pointer you could give me,
>>> Marine
>>>
>>> ___
>>> Policies 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] Question about the rendering and how to hide textures selectively

[Marine Kelley]

That did the trick ! I replaced "tex" in that method by
LLViewerFetchedTexture::sDefaultImagep, and the whole world is untextured
(although colored, which I will fix too). Now I "just" have to find out how
to differentiate between world surfaces and attachment surfaces, and it
will work perfectly.

Thank you Nicky and all !


On 12 June 2014 17:09, Nicky D.  wrote:

>
>> Anyone among you knows how to do that without butchering the rendering
>> pipeline ? It shouldn't be hard, but I've been searching for hours for the
>> spot where the viewer retrieves a texture by its UUID in the fetched
>> textures, to apply it to a face, but no way to find that.
>>
>>
> I'd start by looking at  LLVolumeGeometryManager::registerFace and swap
> out the various textures that go into LLDrawInfo.
>
> Nicky
>
___
Policies 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] Near clip plane for impostors

[Marine Kelley]

Hello all,

Does anyone know how I can control the value of the near clip plane for the
rendering of impostors please ? I've noticed that the camera will clip them
from 1m away, leaving holes in it, but sometimes the camera is restricted
to even closer than that, so I need to be able to render them fully even
from up close.

Thanks,
Marine
___
Policies 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

[Marine Kelley]

Thank you Kitty, I appreciate it :)


On 20 February 2010 15:36, Kitty  wrote:

>  >RLVa is a very notable user-defined API that has far transcended its
> original purpose,
> >and is now in extensive use wherever enhancements for accessibility are
> required.
> >It really highlights how user-defined functionality should have been in
> the viewer from the beginning.
>
> Slight little correction here: RLVa is solely an (alternate) implementation
> of the RLV API. While I am responsible for coding RLVa, Marine is
> responsible for her original RLV implementation and more fitting for this
> topic she's responsible for the actual RLV API/specification.
>
> Since it's used here to refer to the actual API it would be the "RLV API"
> rather than "RLVa API".
>
> Silly for most anyone I'd imagine, but little things like that tend to
> obscure the origin and credit should go where the credit is due so I just
> wanted to clear that up :) .
>
> Kitty
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Marine Kelley]

Exactly my thinking too, the problem us not clear whether the players  
are cooperative or in competition. It totally changes the result.

But I guess that the real goal of this challenge is to call you  
"stupid" and to gauge your reaction. If you yell or punch the  
recruiter, you're dismissed. If you say "my bad, you're right", you're  
dismissed. But if you argue and explain your theory clearly, calmly  
and with the objective of solving the problem instead of just  
defending yourself, you prove that you're someone who can integrate a  
team that works on a system that is both technical and social.



On 23 févr. 2010, at 06:55, Colin Kern  wrote:

> On Mon, Feb 22, 2010 at 6:51 PM, Carlo Wood  wrote:
>> On Sun, Feb 21, 2010 at 04:57:18PM -0800, Dzonatas Sol wrote:
>>> When LL said "here is a sphere the size of a quarter in diameter...
>>> 1 2 3 4 5 6" as one points top, bottom, left, right,  back, front.
>>> And says "Stupid" with a superiority look.
>>>
>>> Obviously the person that was challenged, the one to be hired,  
>>> said "Odd."
>>>
>>> If you know if it is "even" or "odd" then you know who gets the last
>>> move, and wins.
>>
>> This is clearly a way to measure someones spatial insight.
>>
>> Now note that if it's a game, and coins are not allowed to be moved
>> around once they are placed, then it's very unlikely that you will
>> be able to place 6 coins on the surface of that sphere (with diameter
>> equal to the coin), because the one who'd put down the fifth coin
>> would not put it such that you can put down the sixth coin, but
>> somewhere in the middle of the left-over surface, leaving no spot
>> for the sixth coin. Calling people stupid over this game surprises
>> me however (because I happen to have a extremely large spatial
>> insight, officially measured mind you (although, they couldn't
>> actually graph it in their graph because I scored not just out of
>> the graph but even off the paper that the graph outline was printed
>> on)), because I'm having a hardtime to quickly guess if you CAN put
>> five coins on the sphere... It seems not unlikely that only four
>> coins will make it... which would mean that the one that begins
>> will try to leave open as much space as possible when putting
>> down the third coin. The person to move second would try to use
>> as much space as possible. So, first goes on top say, second on
>> grounds of symmetry probably on the bottom, then again forced to
>> play without any strategy, the third coin just goes on the side,
>> and the fourth coin, wanting to be last, takes the exact
>> opposite of that, leaving two places free: Oh hell... that
>> way you STILL end up with six coins being placed, even though
>> both tried to screw the other with strategy. The only freedom
>> that still exists would be the one placing the second coin: by
>> not placing it exactly on the opposite side, you'll likely end
>> up with only five coins. However, since putting it on the exact
>> opposite side caused this player to win, he has little reason
>> to play it elsewhere. Hence, due to perfect symmetry, the first
>> player has no real choice, ever. And the second one, who wins,
>> can control the game completely; hence 6 coins.
>>
>> Not THAT simple however.
>>
>
> There's really no way to figure it out without information about
> either of the player's strategies.  It seems like what the interview
> was really asking is what the maximum number of coins that could be
> fit on that surface was, or he should have specified that these two
> players were perfect and playing optimally.
>
> Colin
> ___
> Policies 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

[Marine Kelley]

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

[Marine Kelley]

Laugh, while I work at finding a name that will not infringe LL's new  
policy, update countless pages of documentation, download websites and  
blogs, update all my scripts and manuals, and explain to scripters why  
they have to update theirs.




On 24 févr. 2010, at 09:48, Dahlia Trimble   
wrote:



C'est la vie



On Wed, Feb 24, 2010 at 12:43 AM, Lawson English   
wrote:

Marine Kelley wrote:
> You gotta be kiddin me !! I call that a stab in the back. You guys
> disgust me.
>
>1. 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:
>  1. You must not have a Third-Party Viewer name that is
> “ Life” where “” is a term or  
series of terms

>

I wonder if 二回♀will violate this


Lawson




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

[Marine Kelley]

Thank you Soft, I knew you wouldn't let me down. Three months is okay, I can
cope with that without rushing I think. The real plus is that they offer to
help in making sure people can still find the RLV under its new name (which
would still be "RLV" anyway, just not "Restrained Life Viewer" anymore) by
typing "Restrained Life", since most scripts in-world will not change to
reflect the name change. Without this bridge from the old name to the new
name, new people would arrive in SL, be interested in that "RLV stuff this
object is using", fail at finding it, and give up. Eventually that would be
the death of the RLV itself.

But what I am concerned about is the viewer directory. I see that I need to
provide my RL info to list my viewer there, and that this RL info would then
be visible to all for liability. I can't do that. My overall work in SL
(viewer and business alike) shows strongly my personal fetishes, and I
simply cannot afford to disclose any info that could link my avatar to my RL
identity. I could lose my job otherwise. Or worse. People in the US are
pretty cool about fetishes, but not Europeans. We are still very old school
on this side of the pond.

Besides I don't see why on Earth any RL info should be disclosed to everyone
in the open, it is nobody's business except LL's who is making and
publishing third party viewers to connect to their grid. To me the average
developer of a third party viewer should be allowed to remain anonymous,
since the real griefers are never going to publish their data anyway. And
since a viewer developer cannot be held responsible for the use of their
viewer (despite what the policy implies), this is a moot point.

Thanks though,
Marine


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 need to select a new name for the
> viewer, but "(formerly Restrained Life)" will be shown underneath the
> name so there's no question as to which viewer people would download
> if they came in search of your own.
>
> If there's anyone else with an established viewer name that conflicts
> with the viewer policy, and who wants to be included in the registry,
> the same offer is open to you as well.
>
___
Policies 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

[Marine Kelley]

Usually development and publishing companies have an anonymous contact  
page on their website, and no easy way of getting to know the identity  
of any of their employees (besides the executives). And this is for  
privacy and competition reasons. It should not be any different for  
hobbyist developers who cannot afford to throw their name in the open.  
Anyway there should be no question of that since you have signed up  
for an account or more to LL in agreement to their privacy policies in  
the first place.

Besides, you can't find the full name of a Linden Lab employee unless  
they disclose it themselves (I think, maybe there is a public register  
somewhere or something). I don't see why we, the developers who work  
partly for LL at improving their platform for free, would have less  
rights to privacy than the people who are paid by them and who are  
protected.

This is a non-issue anyway, most people will not agree to expose their  
RL identity on LL's website just to list a piece of work of theirs,  
unless said piece of work is required to be listed in order to be  
accepted on their grid. And I have not read anything anywhere that was  
even remotely implying such a thing. If this was required, expect most  
viewers to be stopped dead in their tracks.



On 25 févr. 2010, at 11:10, Darren Gansberg  wrote:

> Henri Beauchamp wrote:
>>
>> Because you can actually know who are *all* the real persons behind  
>> *any*
>> Open Source project ?... You know, people do use pseudonyms a lot, on
>> Internet... Anyway, no where in the GPL will you find that a  
>> developper
>> *must* disclose their true identity
> No of course you can't. Additionally the developer shouldn't be forced
> to disclose their identity. What i was taking exception with was the
> view that the identity of the developer is no one's business. As i  
> said
> it's the users business. But the appropriate solution to the user not
> knowing the identity of the person responsible for writing a piece of
> code is for the user not to install and use that program on their  
> system
> if they arent comfortable of knowing its source. That said i don't  
> think
> it's necessarily a great attitude to take that your not prepared to  
> put
> your identity to your own doings. And i adopt that view to all  
> manner of
> things software development aside.
>
> Darren
> ___
> Policies 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] FAQ posted for Third Party Viewer Policy

[Marine Kelley]

I don't know much about it, but what about the data that most of us already
entered when signing up to SL ? LL should have these data stored somewhere,
why do we have to enter them all again ? If the data to be entered to sign
in to the viewer directory is not linked to it, what gives LL the certainty
that they are accurate, where are they stored, and what is the privacy
policy ? The TPV says "may be published", but there is no way to be sure...
And moreso, the FAQ says that listing in the directory might become
mandatory. With such vague terms it is impossible to comply to these
requirements, which are way too intrusive for a hobbyist.

Sorry about this, it seems that publishing a Frequently Asked Questions page
brings even more questions ! It is always like this. lol.


On 27 February 2010 10:32, Henri Beauchamp  wrote:

> On Fri, 26 Feb 2010 21:14:52 -0600, Soft Linden wrote:
>
> > There's now a FAQ for the Linden Lab Policy on Third Party Viewers:
> > http://bit.ly/caedse
>
> Very good job, Soft, thank you ! :-)
>
> However, there are a couple of points that I think should be addressed
> or precised in this FAQ:
>
> 1. The trademarking rules as presented in the TPV are in contradiction
>   with Linden Lab's own trademark policy. In particular:
>  5.b.i You must not have a Third-Party Viewer name that is
>   “ Life” where “” is a term or series
> of terms.
>   Is in contracdiction with:
>   http://secondlife.com/corporate/brand/trademark/unauthorized.php
>   in which we see that "[anything] Life" is not forbidden as long
>   as [anything] does not contain "Second".
>   I would call such a trademarking a "domain trademarking" (like
>   a domain name for an Internet site address"), but I doubt very much
>   such a rule would be legal, even in USA...
>
> 2. in the FAQ, to the question "I do not want a publicly available
>   listing in the Viewer Directory to disclose my own name or contact
>   information.  Is it possible for the public listing page to show
>   just the brand name of my third-party viewer?", the answer states
>   that name and contact info must be provided to Linden Lab, however
>   the type of "contact information" is not precised. An email from
>   an ISP account (not an anonymous Yahoo/Hotmail/Google/whatnot
>   account, of course) *is* a contact information that is sufficient
>   to legally identify the developper in case of any action against
>   them. But right now, the full snail mail address is required,
>   which is in violation with some international laws protecting user
>   privacy (notably the French law "Informatique et Liberté").
>
> I hope to see these two points addressed.
>
> Many thanks in advance !
>
> 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] FAQ posted for Third Party Viewer Policy

[Marine Kelley]

I had understood the same, but still am not reassured. To put it simply :

- Publishing my RL name and address is out of question. Ever.
- Listing the RLV in the Viewer Directory requires me to give my RL info to
LL, with the hopes it will stay private. Dare I say, the people maintaining
this list are NOT the people I trusted when I signed up to SL in the first
place. And dare I add, I had to sign up twice : once to go Premium, and
again to verify to Aristotle. Big issue number one here.
- The Viewer Directory "may" (which in my book means "eventually will")
require to publish the RL info of all participants on the page or be
dropped. Big issue number two here.
- Being listed in the Viewer Directory "may" (once again, same meaning to
me) become mandatory in order to connect to the Second Life grid. What makes
LL sure that a rogue viewer will not spoof the ID of a listed viewer in
order to be accepted upon connection ? Big issue number three here.

So, does that all mean that eventually the RLV will not be able to connect
to the Second Life grid at some point, unless it becomes a rogue viewer that
spoofs the identity of another listed one ? Or do I need to stop it all now
to avoid losing sleep ? Or do I need to pass the project on to someone who
accepts to have their data published ?

Besides, this Viewer Directory is meaningless. It does not stand for a list
of viewers that have been technically approved by LL, nor can it ever be.
Nothing keeps a viewer dev to go totally rogue and start stealing L$,
passwords and other info, and LL would have zilch to retaliate because the
RL data entered would have probably been false in the first place. And no,
LL does not have legally the right to officially verify someone's RL address
in some countries, for instance in France, where only legal institutions
have the right to do that, as Henri pointed out.

Sorry, but this Viewer Directory and all its implications have me greatly
worried. And the lack of assurance that it won't switch from "informational"
to "whitelist" at some point, with all the requirements going along with it,
is enough to make me want to drop it.

I vote for not using the Viewer Directory at all. It is useless because it
doesn't guarantee that its listed viewers are safe, and dangerous for the
future of Second Life because it is potentially going to breach privacy.

I'd like to remind people of my proposed solution, back when LL asked
everyone about how to set their third party viewer policy, a few months ago.
I had proposed to make it so that only viewers built on a LL-owned dedicated
machine would be accepted. Such binaries would be the result of the build of
committed sources, with the addition of a small code (unknown to the devs of
the viewer) that would transfer a hash to the grid upon connecting (and
possibly regularly afterward while online). The binaries would be hosted on
LL's website, along with the sources, and everyone would have been able to
consult the sources while being sure there would not be any difference
between these sources and the resulting binaries (with the exception of the
code I mentioned). Granted, this is an expensive solution, and potentially
difficult while testing (there has to be some temporary code for that
purpose, for instance a code that allows only 4 or 5 viewers using it at the
same time), but the only solution that formally guarantees that Build =
Source, and that the source can be reviewed, instead of testing every
viewer, which takes much longer.

No listing and no requirement is ever going to replace that.

Marine


On 28 February 2010 02:58, Soft Linden  wrote:

> On Sat, Feb 27, 2010 at 5:27 AM, Marine Kelley 
> wrote:
> > I don't know much about it, but what about the data that most of us
> already
> > entered when signing up to SL ? LL should have these data stored
> somewhere,
> > why do we have to enter them all again ? If the data to be entered to
> sign
> > in to the viewer directory is not linked to it, what gives LL the
> certainty
> > that they are accurate, where are they stored, and what is the privacy
> > policy ? The TPV says "may be published", but there is no way to be
> sure...
> > And moreso, the FAQ says that listing in the directory might become
> > mandatory. With such vague terms it is impossible to comply to these
> > requirements, which are way too intrusive for a hobbyist.
> >
> > Sorry about this, it seems that publishing a Frequently Asked Questions
> page
> > brings even more questions ! It is always like this. lol.
>
> I'll ask to be certain, but I expect that if the viewer changed from
> opt-in identity disclosure to mandatory identity disclosure, every
> participant would be given the option to be listed or be dropped.
> Without a response, we would drop the listing. It 

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

[Marine Kelley]

Some people have no problem with showing their private fetishes to the
world, other people like me do. I have a family, a job, and friends. I have
plenty things to hide, my private life is nobody's business, and anybody who
attempts to pry it open will only meet hostility.


On 28 February 2010 11:49, Gareth Nelson  wrote:

> For myself, I'd happily give my real name and an email address - but
> not a postal address for public access. Anyone who would consider
> doing that is lucky to never have had a stalker (trust me, it's not
> pleasant).
>
> If the reason for requiring this information is "in case we need to
> sue you" then it's in no developer's interests to give it. An email
> address is fine for contact info, and a real name is unneeded, but
> shouldn't be a massive concern - personally I only use a secret alias
> online if i'm trying to hide.
>
> People have mentioned "kinky stuff" in SL as being a reason to hide -
> well, i'm perfectly happy to show everyone videos and screenshots of
> myself in a sex club just to prove i'm serious about "nothing to
> hide". Hopefully that means you can also trust me not to put nasty
> trojans in my code. Of course whether you'll ever use my code is
> dependent on contacting me directly these days - no way am I signing
> the contributor agreement to get patches into the main viewer.
>
> On Sun, Feb 28, 2010 at 9:06 AM, Lance Corrimal
>  wrote:
> > Am Sonntag 28 Februar 2010 schrieb Henri Beauchamp:
> >
> >> > I know the identity requirement will remain, and I expect there
> >> > will be a form that's more explicit about what information is
> >> > required, if there isn't already.
> >>
> >> For now, email and full snail mail address are required in addition
> >>  to the real name.
> >>
> >> > If you know of any law that makes it illegal to require email as
> >> > a condition of being listed in an optional directory, it would be
> >> > helpful to tell me where to find it so I can pass it on to legal.
> >>
> >> Real name and (ISP hosted) email address are both OK and adequate
> >> (they provide both a mean of communication and a mean of
> >>  identification, the latter in the case a legal action would be
> >>  taken by Linden Lab), the only thing which is not OK as the form
> >>  is right now (beside the mention that private info may be
> >>  published) is the snail mail address requirement (unneeded at all,
> >>  thus it shall not be a required info).
> >
> >
> > Right now I'm working on porting henri's cool patches to snowglobe.
> > As it stands now, I'm not going to put it into the viewer directory,
> > unless the requirements for any other data than my SL name and a
> > valid, working email address are taken down. Real name is only
> > acceptable if not publicly shown anywhere.
> >
> > 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
> >
>
>
>
> --
> “Lanie, I’m going to print more printers. Lots more printers. One for
> everyone. That’s worth going to jail for. That’s worth anything.” -
> Printcrime by Cory Doctrow
>
> Please avoid sending me Word or PowerPoint attachments.
> See http://www.gnu.org/philosophy/no-word-attachments.html
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies 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] FAQ posted for Third Party Viewer Policy

[Marine Kelley]

>
> If LL makes the agent ID's public, people will soon ban
> *ALL* minor TPV's (being all of them, except maybe emerald,
> because that has already a pretty large userbase) "just in case".
>
Ahem ! Define "minor" TPV 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

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

[Marine Kelley]

Bzzt. It has changed name recently. But thanks. lol

That's because we don't frequent the same people I guess... Fret not  
though, your Emerald includes RLV actually. Smile, you've been  
assimilated ! *winks*



On 1 mars 2010, at 14:18, Carlo Wood  wrote:

> On Mon, Mar 01, 2010 at 02:15:16PM +0100, Marine Kelley wrote:
>>
>>>
>>> If LL makes the agent ID's public, people will soon ban
>>> *ALL* minor TPV's (being all of them, except maybe emerald,
>>> because that has already a pretty large userbase) "just in case".
>>>
>> Ahem ! Define "minor" TPV please.
>
> *and* Restrained Life, of course ;) (sorry, it's just that I never
> hear about your viewer while in-world, while lots of people
> talk about using emerald). But that probably has to do more
> with me than anything else :p
>
> Not making a joke about liking to be banned in the first place,
> Carlo Wood 
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Limits UI

[Marine Kelley]

Does that mean we have to modify ALL our scripts to add function calls to
tailor the memory right, most of the time not even knowing how much is
needed ? I thought the memory taken by Mono scripts was variable, to a
maximum of 64k, as opposed to LSL which takes 16k no matter what...

If that's the case, if we have to modify all our scripts, after switching to
Mono (which in itself was a tremendous work because it implied merging
scripts and updating everything to our customers), then I am sorry to say
the interest of using Mono over LSL has suddenly gone through the floor.



On 6 March 2010 17:39, Garmin Kawaguichi wrote:

>  Oh! And read the Kelly's comments in
> https://blogs.secondlife.com/community/technology/blog/2010/03/05/server-138-beta-now-open
>  :
>
> "Right now there is no way to change how much memory a mono script uses,
> and it is true that at any given point it probably uses less than 64k, by
> some amount.  However, before we enforce script limits, which again is still
> a ways off, we will enable the ability to set a lower max memory size for
> mono scripts.  If your script really only uses 4k, congrats you can set it
> to that and it will only count as 4k, and you won't be able to use more
> until you change it.  *This will be implemented before we enforce limits*
> ."
>
> GCI
>
>
> - Original Message -
> From: "Matt White" 
> To: 
> Sent: Saturday, March 06, 2010 5:21 PM
> Subject: [opensource-dev] Script Memory Limits UI
>
> 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] Script Memory Limits UI

[Marine Kelley]

This is exactly how I had interpreted it, and this means that a script has
to explicitely request less memory than the default 64k if the scripter
wants to use less memory. And I don't think there will be any other way to
do that than by calling a LSL function to request memory. Which means
modifying existing scripts. This is unacceptable for all well established
business owners who made many different script that are now spread across
SL. To me, a script should take as many bytes as it needs, not more, and
that amount of memory should vary with time. Otherwise it is not
practicable, and will break content once the limits are in place.



On 6 March 2010 21:41, Michael Schlenker  wrote:

>
> Am 06.03.2010 um 21:25 schrieb Marine Kelley:
>
> > Does that mean we have to modify ALL our scripts to add function calls to
> tailor the memory right, most of the time not even knowing how much is
> needed ? I thought the memory taken by Mono scripts was variable, to a
> maximum of 64k, as opposed to LSL which takes 16k no matter what...
> >
> > If that's the case, if we have to modify all our scripts, after switching
> to Mono (which in itself was a tremendous work because it implied merging
> scripts and updating everything to our customers), then I am sorry to say
> the interest of using Mono over LSL has suddenly gone through the floor.
> >
>
> The comment from Kelly Linden on the blog didn't sound like it, it was more
> like:
> - The default allowed memory footprint of a mono script is 64 kB
> - In the future a mono script will be allowed to request more OR less
> maximum memory for itself
> - IF you know that your script only needs a tiny amount of memory, you can
> set its limit lower to ease the pressure on the sim
>  (which makes it an option for example to use 16 scripts with 4 kB and
> trivial functions instead of one 64 kB script that needs to multiplex
> things)
> - We don't want to break content. Most of the time we cannot guarantee or
> measure the maximum memory usage of a script and to prevent bad effects like
> prims that only work when the phase of the moon is right (aka the garbage
> collector timing) we simply assume a static maximum of 64kB.
>
> I agree on the issue of a horrible UI for the 2.0er memory usage though. It
> should simply sum the number of scripts and show how many LSL and how many
> Mono scripts are involved. The 16kB/64kB details are misleading and useless.
>
> Michael
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Limits UI

[Marine Kelley]

Well we have two mutually exclusive solutions here.

Either Mono scripts are given a hard memory limit that we (the scripters)
can change within the scripts, with all the overhead work that it implies
(i.e. modifying hundreds of scripts before issuing an update, and having to
know upfront how much memory will be taken exactly), which means that in
regards to the scripts memory usage UI, the script will use exactly as much
as the limit it has requested, no matter whether it really uses it or not.
This gives wasted memory and false information.

Or, Mono scripts are given a hard memory limit that we cannot change, and
they report exactly as many bytes as they use at any time. But we shouldn't
be able to change the limit ourselves, because it wouldn't make sense to do
so, it would only be restraining ourselves if we set less than 64k, and
wasting memory space if we set more than 64k.

In both cases, the question of whether the script crashes when reaching the
limit or not is not related.

I seriously, and I mean seriously, think that choosing the first option is
going to hurt the established scripters very badly, and therefore the grid
as a whole. To me scripts should report exactly as much memory as they use,
not more, and should not require the scripters to modify them to report
something that could be computed by the sims more accurately anyway.

Of course it is tempting to tell the scripters "you can now decide how much
memory to allow, and that way you are certain it will report the amount you
have set", as much as it is tempting to shift the workload of allocating
script memory onto the scripters since LL can't seem do it.

Remember, we are now going to have limits on a service that didn't have them
before. For the same price. All in the sake of stabilizing the grid. Ok for
me. This will already hurt scripters who will have to adapt bad scripts. But
now we are told we are going to also adapt good scripts as well ! I repeat,
this is unacceptable.

Marine


On 7 March 2010 03:02, Frans  wrote:

> As for the dynamic vs fixed memory usage. Of course it would make sense to
> have dynamic memory usage, but I haven't seen a response yet on how to solve
> the problem that Kelly described, about scripts suddenly running out of
> available memory to use, when they fill up lists with info, etc. And break
> because of it. Or is this considered not to be a big problem?
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Script Memory Limits UI

[Marine Kelley]

As far as I understand it a script (the item you manipulate in-world) is a
bytecode (a compiled version of your code without the comments, the spaces
and the returns) loaded into the sim, plus its simple, constant-size
variables (integer, floats), all of which forming the stack. Then you have
all the varying-size variables, namely strings, keys and lists, which all
form the heap.

The 64k limit concerns the sum of the bytecode, the stack and the heap. The
size of the two former is fixed and determined at compile time, while the
size of the latter is variable.

Someone please correct me if I'm wrong, this is experience talking, I do not
have access to the server-side code of the script handling.


On 7 March 2010 13:11, Tony Dodd  wrote:

>  May I ask a probably dumb question here? It's probably been answered but
> I can't find the answer now.
>
> Presumably a script uses two resources, the byte code in its assembly and a
> slab of memory allocated for its stack/heap. And am I right that the former
> can be shared between multiple copies of a script whereas the latter would
> have to be allocated separately to each script?
>
> OK, the question is, does the 64K limit refer to both of these together or
> just to the stack/heap? If I have a mono script that is quite large but
> doesn't allocate any lists, will each instance of that that runs be using up
> 64K of memory?
>
> If there's an obvious place I should look I apologise but without knowing
> this I find it hard to assess how much impact memory limits will have on my
> own scripts.
>
> Maldoror Bowman
>
>
>
>
>
> ___
> Policies 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] Question regarding llSetLinkPimitiveParamsFast()function in 1.38.0

[Marine Kelley]

Code is proprietary unless stated otherwise by the maker. Abandoned code
does not mean public domain code, this would be a violation of copyright to
release protected source code to the public without the agreement of the
owner first. Whether they are still active in SL or not does not matter.



On 7 March 2010 17:09, JB Hancroft  wrote:

> About that:  "Creator out of SL; no source code"
>
> But we know the "source" is still bound to the prims, a la SL.
> Has LL ever done anything about helping recover abandoned code, in some
> way?
>
> - JB
>
>
> On Sun, Mar 7, 2010 at 10:45 AM, Garmin Kawaguichi <
> garmin.kawagui...@magalaxie.com> wrote:
>
>> I suppose that's just because the LSO code has changed and there are
>> thousands objects no modify having the creator out of SL : not possible to
>> compile the script(s)
>>
>> GCI
>>
>>
>> - Original Message -
>> From: "Obsidian Kindragon" 
>> To: 
>> Sent: Sunday, March 07, 2010 3:39 PM
>> Subject: [opensource-dev] Question regarding
>> llSetLinkPimitiveParamsFast()function in 1.38.0
>>
>>
>> > Hi all,
>> >
>> > I've a quick question regarding the new llSetLinkPimitiveParamsFast()
>> > function in 1.38.0. Why did LL opt for a new function instead of just
>> > removing the delay from the current llSetLinkPrimitiveParams() function?
>> > I can't conceive any case where removing the delay from the current
>> > function would break any existing content.
>> >
>> > - Obsidian Kindragon (AKA Obsidian Stormwind)
>> > ___
>> > Policies 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] Script Memory Limits UI

[Marine Kelley]

Change requires work. Unnecessary, unwanted, and uncalled for in this  
instance. We have to adapt to handle a part of the task that LL was  
supposed to do themselves. Oh of course this is a hard job, allocating  
memory dynamically in an environment like this. Perhaps it is  
impossible. I have yet to hear a Linden say, in all honesty, "sorry  
guys, we can't do it as initially planned, we have to ask you to  
participate by tailoring your scripts, because we can't do it from our  
side". What I have heard so far is "you will be provided tools to  
adapt to the change that is taking place". The two mean exactly the  
same thing, but a little honesty does not hurt. This additional  
workload was not planned, is a shift of work that we were not supposed  
to take in charge in the first place, with no compensation, so I'd  
have liked a little explanation at least.

I am not against the limits. Of course scripts need limits, and they  
actually always had some, only they were hidden, unmanaged and had to  
be discovered through trial and error. As I said, "I am ok with that".  
What I am not ok with, is the fact that I have to review every single  
script of mine to try to find out how much memory they need in the  
worst case. Finding said worst case is already a challenge in itself.  
I have thousands of scripts in-world, not even counting the ones in my  
products that I will have to issue an update for. Because wait a  
little and you'll see merchants start to advertize how little the  
memory footprint of their scripts is compared to the next competitor,  
regardless of how crappy said scripts are.

Anyway this is a moot point now. As far as I understand it, LL has  
decided that their implementation would require us to adapt our  
scripts ourselves, exactly like I described.



On 9 mars 2010, at 02:40, Lear Cale  wrote:

> It would be nice if everything were free, too.
>
> The issue is memory *allocation*.  If a script only uses 16K but is
> allocated 64K, that 64K counts against the server's actual memory
> allocation limit.
>
> So, cool, wouldn't it be nice to only allocate what is actually
> requested?  Well that implies rewriting a lot of code to use memory
> differently, and requires frequent reallocation of memory (as the
> needs grow or shrink).  There is a real cost to this, in terms of
> programming effort and in terms of runtime costs.
>
> Until now, script memory has seemed to be a free lunch.  Well, the
> free lunch is over, and we'll have to deal with it.  I won't believe
> that it's feasible to simply "report the actual memory used" until
> someone who really understands Mono memory allocation and our
> scripting language's arrays (the main memory users) says that there
> actually is a feasible solution along these lines.
>
> Change causes upset.  This will be an issue.  IMHO, though, failing to
> address the problem would be worse.
>
> Regards
> Jeff
>
> On Sun, Mar 7, 2010 at 6:20 AM, Marine Kelley  
>  wrote:
>> Well we have two mutually exclusive solutions here.
>>
>> Either Mono scripts are given a hard memory limit that we (the  
>> scripters)
>> can change within the scripts, with all the overhead work that it  
>> implies
>> (i.e. modifying hundreds of scripts before issuing an update, and  
>> having to
>> know upfront how much memory will be taken exactly), which means  
>> that in
>> regards to the scripts memory usage UI, the script will use exactly  
>> as much
>> as the limit it has requested, no matter whether it really uses it  
>> or not.
>> This gives wasted memory and false information.
>>
>> Or, Mono scripts are given a hard memory limit that we cannot  
>> change, and
>> they report exactly as many bytes as they use at any time. But we  
>> shouldn't
>> be able to change the limit ourselves, because it wouldn't make  
>> sense to do
>> so, it would only be restraining ourselves if we set less than 64k,  
>> and
>> wasting memory space if we set more than 64k.
>>
>> In both cases, the question of whether the script crashes when  
>> reaching the
>> limit or not is not related.
>>
>> I seriously, and I mean seriously, think that choosing the first  
>> option is
>> going to hurt the established scripters very badly, and therefore  
>> the grid
>> as a whole. To me scripts should report exactly as much memory as  
>> they use,
>> not more, and should not require the scripters to modify them to  
>> report
>> something that could be computed by the sims more accurately anyway.
>>
>> Of course it is tempting to tell the scripters "you can now 

Re: [opensource-dev] Script Memory Management Algorithm

[Marine Kelley]

I'm naive here, I don't know the server side of it. But how can a sim  
know when a script hits a threshold, and not be able to report the  
actual memory used ? Since it can check it against a threshold...




On 8 mars 2010, at 18:46, Kelly Linden  wrote:

We are not out to write a new malloc for mono.  What we have is a  
system that throws an exception when the memory used by the script  
hits a certain threshold (64k currently).  This exception is caught  
so we can "crash" the script.  The future small scripts and big  
scripts projects will add new functions to set and get this  
threshold value, allowing scripters to effectively control how much  
memory is reserved for their script.  We will continue to use mono's  
default memory management within the reserved memory thresholds.  It  
is a much simpler problem to solve.


 - Kelly

On Sun, Mar 7, 2010 at 5:50 AM, Carlo Wood  wrote:
Lets assume that the *average* script uses
8 to 16 kB of real memory. LL's design allocates
64 kB regardless, leading to an overhead of
400 to 800% (meaning they need to buy 5 to
9 times the memory that is theoretically needed).

In that light, I gave it some more thought, and
think something as complex as my rmalloc's algorithm,
with it's 19% overhead, isn't needed (note that
it's both faster than gmalloc as well as three
times more efficient; so complexity is not always
a bad thing ;).

Nevertheless, in this case, since the scripts
use a maximum of 64 kB, you can use the
following design:

Let each allocated block be a power of 2
kilobytes, with a maximum of 64 kB (and a
minimum of 1 KB, or 4 if even the tiniest
script needs that).

It is easy to see that this would lead
to an overhead of 25% on average per
allocated block.

We'd still have to deal with "holes" of a
full 64 kB where blocks became totally
unused, but normally scripts in objects are
started all at once when a sim reboots, and
only seldom stopped. The scripts that will
most likely attribute to random starting
and stopping of scripts will be the scripts
in attachments. A worst case scenario would
be one where there are 50 avies in a sim
(during a meeting), then a new avie enters
with some scripts which need to be allocated
at the top of the heap; then the previous
50 avies leave. That would create a hole
in the heap of the size of all the scripts
of those 50 avies. If script memory would
be relocatable, then this problem doesn't
exist of course. I can't simply estimate
the average overhead caused by this, but
because the algorithm described here is
basically the one used by gmalloc (which
in my test used 62% overhead) I'm pretty
sure that it will be less than -say- 100%
overhead; still 4 to 8 times more efficient
than the current design on the table.

The API for this design would be something
like the following:

namespace script_memory_management {

void* ll_sbrk(ptrdiff_t);   // Increment the size of the heap
int   ll_brk(void*);// Set the size of the heap  
explicitely


void* ll_malloc64(void);// Get a new 64 kB block.
void  ll_free64(void*); // Free such a block.

void* ll_malloc(size_t s);  // Allocate s bytes of memory for a  
script.

void  ll_free(void*);   // Free it again.

...

Assuming here that scripts cannot deal with
relocation, otherwise one should also have:

void* ll_realloc(size_t s); // Allocate a different size of  
memory.



ll_malloc then will round the number of requested bytes up
to the nearest power of 2 (kBs) and retrieve a block from one
of the free lists (maintained for 32, 16, 8, 4, 2 and 1 kB)
(note that if scripts only seldom use 1 or 2 kB it might
be more efficient to use a minimum of 2 or 4 kB instead of 1).

Each 64 kB block would contain either one 64 kB allocation,
or two 32 kB block allocations, or four 16 kB block allocations,
etc, but never allocations of mixed sizes, thus making it
easy to find a free block of such size.

A free list is usually maintained by adding pointers inside
the (unused) memory blocks, linking them together to a linked
list of free memory blocks of a given size. That causes allocating
to be instant, but freeing memory requires to traverse this
list in order to update it's pointers. With the number of
scripts that normally run in a sim this will not be a problem.

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

Re: [opensource-dev] Script Memory Limits UI

[Marine Kelley]

That's right. Computer programs are constantly managing two  
contradictory resources, space and time. In theory we need control  
over script time as much (no more no less) as we need control over  
script memory. But let's not ask for even more additional workload  
than we already have.



On 9 mars 2010, at 10:05, Ambrosia  wrote:

>> So, cool, wouldn't it be nice to only allocate what is actually
>> requested?
>
> That -is- in the works, with the Small Scripts and Big Scripts
> projects. it will allows you to reserve just as much memory as you
> need for mono scripts, less than the 64k..or even more. But alas, yes,
> time will have to be invested into rewriting things.
> Why the process simply doesn't allow you to slip a new
> llMaxMemory(amounthere); into the state_entry of a script, and lets
> the sim runtime dynamically allocate new memory as the script grows up
> to the max..I don't know. it'd be much simpler.
>
> What I personally want is not only a script memory display, but also
> script -time-. People need to see how much script time is used up by
> the things they wear, the things they create, the things they have on
> their mainland parcels uses up. It's ridiculous that one needs to be
> friends with a full-fledged Estate Manager to check those things, as
> script time affects sim performance just as much as script memory
> does.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Marine Kelley]

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

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


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

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

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

[Marine Kelley]

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


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

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

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

[Marine Kelley]

Err... Content theft has always been a problem, will always be a problem,
and LL better be on the same page with developers, content makers and
customers here. Content theft is not to be tolerated and must be fought. But
some critical parts of the whole system have been put on the client side at
a time when there was no question of the client to be open-sourced. Then LL
decided to open-source it, and had to face many vulnerabilities that were
suddenly exposed, and to plug them one by one.

But let's face it, it has nothing to do with the fact that the viewer is
open-source or not. People were stealing content way before the word
"open-source" was ever written on the SL blog, through abuses of the
protocol itself. It is true, open-sourcing the client has facilitated the
life of content thieves. And also the life of all the honest users, which to
me is a significantly bigger user base. By dozens of thousands I would say.

I don't see LL closing the viewer. It would be very bad for their PR,
especially since they want big companies to set foot in SL (they will
inevitably make their own version of the SL viewer first), and now that the
code is in the wild, it would be very hard for them technically to close it
all down again anyway. And it wouldn't serve their interests either.
Open-source brings developers (hobbyists, enthusiasts, helpers or even
abusers), some being very bright, and LL can benefit from the work they
bring. Either directly by using patches, or indirectly by seeing how such
feature impacts the communities. It is a remarkable field of experimentation
for them. It is not totally free for LL though, they do have to integrate
and validate our work into theirs when they feel the need, and that is not
cheap.

Now, are we code monkeys (I say "we" but I don't personally contribute
patches to the regular viewer) ? Are we being exploited, used as unpaid
developers until LL decides they have gained enough and close it down ? I
don't think so. It is possible, LL has the power to do close it all down,
but it would give a tremendous boost to... their competitors. It would be
like saying one day "from now on, Residents will not be able to compile
scripts anymore, only Lindens will be able to do it". Imagine the reaction,
and where SL would go in the long run. We have the power to modify the
viewer, and to test features on the field that LL would take months to QA.
It serves both sides. What LL dislikes is to have their weapon turned
against them by having content stolen, and the whole mess with the TPV is
about just that.

However it is true that LL has delivered a bad message recently, by
publishing the TPV and the closed-source SL 2.0 the SAME day. The TPV
burdens us developers while freeing LL's hands, and the viewer 2.0 is going
to be adopted by newcomers, so it will eventually get a broader audience
than the rest. It could very easily be seen as competition. It looks very
close to some "fire-and-motion" technique. They suppress open-source
development by laying unbelievably heavy requirements upon the devs, while
moving forward and releasing their own viewer which is not subject to said
requirements. I do hope I'm wrong and this is not the message that LL wanted
to send to us. But one can understand why so many teeth are gritting now.




On 14 March 2010 18:56, New Hax  wrote:

> Soft Linden said:
>
> "Content theft, griefing and resource abuse have been
> long-term problems."
>
> I've been a lurker here but are you KIDDING ME? When Linden Labs open
> sourced Second Life, they were right along side us saying to
> proprietary content developers YOU CANNOT PROTECT YOUR CONTENT.
>
> Has that changed now and Linden labs is protecting people who make
> their binary blobs and think they should be protected???
>
> Linden Labs says if we don't cooperate then o noes we'll get
> throttled.  If Linden Labs closes the source your going to have a lot
> of angry coders on your hands and just to show it content "theft" and
> "griefing" will skyrocket!
>
> Lindens should be staying with their promises, Open Source has
> contributed more to Second Life than people who make shoes that they
> want to keep proprietary and not share. I'll say it again you canot
> protect content. Ever. DRM goes against the spirit of Open Source and
> if content creators cant get with that then they should find a new
> business and it shouldnt be on the INTERNET.
>
> I never get "griefed" in secondlife anymore.
>
> anyways if Linden Labs wants to fight against the Open Source
> community they can TRY but they wont win. We can fork and we can make
> a place where open freedoms are respected.
> ___
> Policies 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.

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

[Marine Kelley]

I'm sorry Kent, I didn't want to upset you. Yes you are getting a lot of
flak, and you are not alone in this case. This TPV does add heavy
requirements upon us developers, and I'm not even talking about the Viewer
Directory which requires us to publish our RL names out to the open. Which
is not going to happen for most like me, which will still be seen as dodgy
devs who "explicitly declined the agreement".

The TPV and the closed-source beta 2.0 have been out the same day. That is a
fact. Viewer 2.0 is closed-source for now, and since I don't read the
future, I have no grounds to say whether it is going to stay closed-source
or not. Seems, by reading what you say, that it is going to be released as
open-source. This is good news. Having the source of SG 2.0 released the
same day was a partial relief, even if I wasn't sure about the differences
between SG 2.0 and Viewer 2.0. Merov did an awesome work I'm sure.

I think I can sense that the TPV didn't really serve the techies at LL, by
getting out the same day as Beta. In fact it kinda played against you. I
don't know anything, but I'm not really sure why the TPV had to be published
the same day in the first place. It could have waited, or it could have been
published before, I don't know. To me if the two are separate, then they
should have been published separately, with some time in between.

I am not questioning LL's plans here. I am merely observing facts and making
my own interpretation over how every one of the moves at LL impacts me and
the people I work with/for.

Marine


On 14 March 2010 20:09, Kent Quirk (Q Linden)  wrote:

>
> On Mar 14, 2010, at 2:41 PM, Marine Kelley wrote:
>
> > However it is true that LL has delivered a bad message recently, by
> publishing the TPV and the closed-source SL 2.0 the SAME day. The TPV
> burdens us developers while freeing LL's hands, and the viewer 2.0 is going
> to be adopted by newcomers, so it will eventually get a broader audience
> than the rest. It could very easily be seen as competition. It looks very
> close to some "fire-and-motion" technique. They suppress open-source
> development by laying unbelievably heavy requirements upon the devs, while
> moving forward and releasing their own viewer which is not subject to said
> requirements. I do hope I'm wrong and this is not the message that LL wanted
> to send to us. But one can understand why so many teeth are gritting now.
> >
>
> What's frustrating about this for many of the Lindens is that we as an
> organization pushed hard -- and Merov in particular worked nights and
> weekends -- to get the Snowglobe source out on the same day that beta was
> released, rather than waiting for our usual export process to work itself
> out while we figure out how to make a new source control system (mercurial)
> work for export.
>
> We actually believed we were doing something the community would really
> appreciate -- getting the source out there the same day as beta. And yet
> somehow that became something bad. People keep repeating that "it's closed
> source".
>
> Despite the negative reaction, we're still working on the export process,
> as Soft indicated, so that we can publish without the snowglobe patches
> added. I'll also soon be posting our branching strategy we've been working
> out for some weeks now. Sorry if it's not fast enough for some, but we've
> kind of been focused on getting viewer 2 out.
>
> The TPV, as has been repeatedly stated, is about protecting our servers and
> establishing the framework within which we can protect user content. I
> simply don't see what the "heavy" requirements are. We ask viewer developers
> for little more than good citizenship. That doesn't seem particularly
> burdensome.
>
> So yes, I think you're wrong about our motivations and intent. If we wanted
> to kill our open source market we'd simply stop publishing it, rather than
> creating a TPV that allows us to promote it. And considering the amount of
> flak we've been getting, it would be easier. And yet, we're still here.
>
>Q
>
>
___
Policies 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

[Marine Kelley]

You are kidding here, right ?

On 14 March 2010 23:27, New Hax  wrote:

> there shouldn't be. if SL is to be open, and really open source, then
> the scripts on it should be GPL as well. But it's different because
> scripts CAN be protected FOR NOW but blobs of binary and graphics ,
> textures, and blobs of prims cannot.
>
> If i take a sphere prim and put a happy face texture on it, do i
> suddenly own all sphere prims with happy face textures on them?
>
> I think that yea scripts should be open too it'd be in the spirit of
> real opensource dev. But if you want to lock them up you ccan since
> they run on the server.
>
> but this will change with interop. you wont be able to protect scripts
> either when you go to someone else's sim, they can take your code
> then. so I say dont bother.
>
> eventually once everything is opened people will get over the idea of
> 'intellectual property' like a sickness.
>
> On 3/14/10, Lawson English  wrote:
> > New Hax wrote:
> >> then what are you doing on an opensource list if you want your content
> >> wrapped in DRM.
> >>
> >> sl will die if its not open. and you can't compare rl doors to the
> >> internet. if you dont lock your rl door I can come in and take
> >> something of yours that isnt replaceable.
> >>
> >> but on the internet as a content maker you can make INFINITE products
> >> so you arent losing anything if i copy it and make no money off of it.
> >>
> >>
> >
> > So lets open up all scripting sources too. I mean no need for content
> > protection there, either, right?
> >
> >
> > Lawson
> >
>
___
Policies 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

[Marine Kelley]

Simply the facts that my scripts are NOT to be ported to other grids unless
I am certain the source code, which would be uploaded by me only, is
protected. Any other way of porting my scripts to other grids and to use it
there is theft.


On 14 March 2010 23:29, New Hax  wrote:

> No im not kidding, whats going to stop people from taking your
> scripts, when you can hop from one grid to another? Interoperability?
> The sim owner can take your scripts.  For now scripts are protected
> because Linden Labs owns the code.
>
> On 3/14/10, Marine Kelley  wrote:
> > You are kidding here, right ?
> >
> > On 14 March 2010 23:27, New Hax  wrote:
> >
> >> there shouldn't be. if SL is to be open, and really open source, then
> >> the scripts on it should be GPL as well. But it's different because
> >> scripts CAN be protected FOR NOW but blobs of binary and graphics ,
> >> textures, and blobs of prims cannot.
> >>
> >> If i take a sphere prim and put a happy face texture on it, do i
> >> suddenly own all sphere prims with happy face textures on them?
> >>
> >> I think that yea scripts should be open too it'd be in the spirit of
> >> real opensource dev. But if you want to lock them up you ccan since
> >> they run on the server.
> >>
> >> but this will change with interop. you wont be able to protect scripts
> >> either when you go to someone else's sim, they can take your code
> >> then. so I say dont bother.
> >>
> >> eventually once everything is opened people will get over the idea of
> >> 'intellectual property' like a sickness.
> >>
> >> On 3/14/10, Lawson English  wrote:
> >> > New Hax wrote:
> >> >> then what are you doing on an opensource list if you want your
> content
> >> >> wrapped in DRM.
> >> >>
> >> >> sl will die if its not open. and you can't compare rl doors to the
> >> >> internet. if you dont lock your rl door I can come in and take
> >> >> something of yours that isnt replaceable.
> >> >>
> >> >> but on the internet as a content maker you can make INFINITE products
> >> >> so you arent losing anything if i copy it and make no money off of
> it.
> >> >>
> >> >>
> >> >
> >> > So lets open up all scripting sources too. I mean no need for content
> >> > protection there, either, right?
> >> >
> >> >
> >> > Lawson
> >> >
> >>
> >
>
___
Policies 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

[Marine Kelley]

That's what I do for a living. And I earn my living well with it. You should
try it.


On 14 March 2010 23:32, New Hax  wrote:

> I know better than to try to get rich off of selling ones and zeroes.
>
> On 3/14/10, Glen Canaday  wrote:
> > Then what are you doing in SL? Not making a living, I can assure you.
> >
> > Nor are you putting food on the table RL except perhaps by manual labor,
> > which cannot be copied. Ex: Ditches need to be dug. The ditch-digger can
> > be changed out, but that doesn't change the fact that even if you get a
> > new digger, you still have a ditch when you're done.
> >
> > OSS/Free Software and Proprietary software are the diggers; they're not
> > the ditch itself.
> >
> > On 03/14/2010 06:18 PM, New Hax wrote:
> >> then what are you doing on an opensource list if you want your content
> >> wrapped in DRM.
> >>
> >> sl will die if its not open. and you can't compare rl doors to the
> >> internet. if you dont lock your rl door I can come in and take
> >> something of yours that isnt replaceable.
> >>
> >> but on the internet as a content maker you can make INFINITE products
> >> so you arent losing anything if i copy it and make no money off of it.
> >>
> >>
> >> On 3/14/10, Marine Kelley  wrote:
> >>
> >>> well I am a content creator, content theft is a problem to me, it is
> tied
> >>> to
> >>> IP rights which are a legal issue. And I am not one of those who say
> >>> "content theft is inevitable, let's not do anything about it". Doors
> can
> >>> be
> >>> lock picked, that's not a reason for me to leave my door wide open.
> >>>
> >>>
> >>> On 14 March 2010 23:04, New Hax  wrote:
> >>>
> >>>
> >>>> On 3/14/10, Marine Kelley  wrote:
> >>>>
> >>>>> Err... Content theft has always been a problem, will always be a
> >>>>> problem,
> >>>>> and LL better be on the same page with developers, content makers and
> >>>>> customers here.
> >>>>>
> >>>> content theft isn't a problem, never has been a problem, and is the
> >>>> nature of the internet and digital things.  if content makers are
> >>>> worried about content "theft" then they shouldn't be on SL. because
> >>>> its inevitable and cant be stopped.
> >>>>
> >>>>
> >>>
> >> ___
> >> Policies 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] oh give me a break

[Marine Kelley]

Don't forget to reply to all, everyone is getting only part of the
conversation when you reply to me only.

We're not talking about the same thing at all anyway. We were talking about
content theft issues, which has nothing to do with the viewer. It has
nothing to do with this mailing list even. They concern scripts, textures,
builds, shapes, sounds, all the assets that are built by individuals
in-world and that are copyright protected. You cannot hope for a grid where
all these assets would be free for all without asking to be able to steal
this content.


On 14 March 2010 23:39, New Hax  wrote:

> agree to disagree yea but then your days are numbered in SL. If the
> project forks then there will be a VW without all these restrictions
> and lindens threatening people for asking them to keep their promises?
>
> On 3/14/10, New Hax  wrote:
> > I want a grid where people can have the freedom to develop what they
> > want and do what they want, without being told whats allowed, and
> > without being watched because you might move the wrong bits from one
> > place to another. and without lindens threatening if we dont "play
> > nice" with draconinan DRM. That was what i hoped the spirit of Open
> > source SL would be. but i guess im wrong.
> >
> >
> > On 3/14/10, Glen Canaday  wrote:
> >> Then what are you doing here?
> >>
> >> On 03/14/2010 06:32 PM, New Hax wrote:
> >>> I know better than to try to get rich off of selling ones and zeroes.
> >>>
> >>> On 3/14/10, Glen Canaday  wrote:
> >>>
> >>>> Then what are you doing in SL? Not making a living, I can assure you.
> >>>>
> >>>> Nor are you putting food on the table RL except perhaps by manual
> >>>> labor,
> >>>> which cannot be copied. Ex: Ditches need to be dug. The ditch-digger
> >>>> can
> >>>> be changed out, but that doesn't change the fact that even if you get
> a
> >>>> new digger, you still have a ditch when you're done.
> >>>>
> >>>> OSS/Free Software and Proprietary software are the diggers; they're
> not
> >>>> the ditch itself.
> >>>>
> >>>> On 03/14/2010 06:18 PM, New Hax wrote:
> >>>>
> >>>>> then what are you doing on an opensource list if you want your
> content
> >>>>> wrapped in DRM.
> >>>>>
> >>>>> sl will die if its not open. and you can't compare rl doors to the
> >>>>> internet. if you dont lock your rl door I can come in and take
> >>>>> something of yours that isnt replaceable.
> >>>>>
> >>>>> but on the internet as a content maker you can make INFINITE products
> >>>>> so you arent losing anything if i copy it and make no money off of
> it.
> >>>>>
> >>>>>
> >>>>> On 3/14/10, Marine Kelley   wrote:
> >>>>>
> >>>>>
> >>>>>> well I am a content creator, content theft is a problem to me, it is
> >>>>>> tied
> >>>>>> to
> >>>>>> IP rights which are a legal issue. And I am not one of those who say
> >>>>>> "content theft is inevitable, let's not do anything about it". Doors
> >>>>>> can
> >>>>>> be
> >>>>>> lock picked, that's not a reason for me to leave my door wide open.
> >>>>>>
> >>>>>>
> >>>>>> On 14 March 2010 23:04, New Hax   wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On 3/14/10, Marine Kelley   wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Err... Content theft has always been a problem, will always be a
> >>>>>>>> problem,
> >>>>>>>> and LL better be on the same page with developers, content makers
> >>>>>>>> and
> >>>>>>>> customers here.
> >>>>>>>>
> >>>>>>>>
> >>>>>>> content theft isn't a problem, never has been a problem, and is the
> >>>>>>> nature of the internet and digital things.  if content makers are
> >>>>>>> worried about content "theft" then they shouldn't be on SL. because
> >>>>>>> its ine

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

[Marine Kelley]

Are you outright saying on the sldev mailing list, in the face of LL,  
that you are wanting to work at stealing enough content to "force"  
them to open the whole system ?

And you still wonder why your ideas are met with hostility ?

You should stop leeching other people's stuff and start your own  
project, preferably making some money with it. We'll see if you keep  
the same speech.


On 15 mars 2010, at 04:01, 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] Third party viewer policy: commencement date

[Marine Kelley]

Well it seems that we can choose not to publish our RL identity to the open.
I too wonder why LL can't link our RL data with our avatars themselves,
since most (if not all) of us are Premium members or have been in the past.
There is certainly a very good internal reason that they cannot disclose,
and it's ok.

What scares me is that the FAQ (and the TPV itself) states that LL "may"
publish these data in the future. They don't say whether "if", or rather
"when" they choose to do so, people who have given their RL data to have
their work published on the viewer directory will be given the choice to
opt-out or not. They can opt-out now, they should be certain they will still
be able to opt-out at any time, prior to pushing the switch. KirstenLee and
Legolas have had their RL info disclosed for a few days already. Maybe they
didn't care, but fact is that they were published then, and are hidden now.
Something must have happened. And if this was a mistake, I would dare to say
it was a very serious one, serious enough to actually sue LL for disclosing
private information without prior consent.

But I digress. The viewer directory is only informative, and is in no way a
certification for the published viewers. A malicious viewer could very well
be published there for a few days or months before the author turns
something on that lays havoc on the grid or on the user data. Like those
virii that activate themselves only on a certain date. There is still no way
of being certain that what you download is safe, viewer directory or not.
That's why I think risking our RL identities on something that holds so
little value is not worth it.



On 20 March 2010 22:14, Patrick N.  wrote:

>  I tend to agree with Jesse, just list their avatar name and LL know
> already all their details anyways.. I have never seen so far any open source
> project where they had a requirement about declining their real identity
> with their address as well..
>
> Its not like they are complete unknown they are your customer already 
>
>
>  *From:* Jesse Barnett 
> *Sent:* Saturday, March 20, 2010 1:30 PM
> *To:* Joe Linden 
> *Cc:* Boy Lane  ; opensource-dev@lists.secondlife.com
> *Subject:* Re: [opensource-dev] Third party viewer policy: commencement
> date
>
> GRRR!
>
> So you left in the requirements that you may publish the real life name and
> address of the developers in the 3rd party Viewer Directory?
>
> This is absolutely nuts and extremely dangerous and whoever thought it was
> a good idea needs to publish thier own name and address in reply here. Would
> you like to start Joe? Or what about just publishing the address of the
> lawyer/lawyers who thought this was a good idea?
>
> I have been using the internet since the time of 2400 modems and have seen
> enough incidents. There is no way in hell I would endanger the life of my
> daughter by ever having my address listed.
>
> major fail,
> 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
>
___
Policies 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

[Marine Kelley]

Thank you for the heads up Morgaine. Correct me if I'm wrong, but if  
the "no warranty" clause vanishes from the source code, then does that  
mean that LL guarantees that the code of the original viewer is bug- 
free ? We can't guarantee it as open source programmers if the  
original devs don't in the first place, and they can't expect us to  
remove it ourselves afterwards, so who is liable for the original  
defects if a law suit was started because of an exploit ?
___
Policies 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

[Marine Kelley]

I agree, there is no question of distributing a binary + it's code  
with a warranty, but to do so LL must remove the "no warranty" clause  
from the original code or else our own code, if based on theirs, must  
mention it as well, voiding our own liability. It cannot be one  
without the other.

It wouldn't stand in court anyway, to expect second hand code to be  
liable when first hand code is not.


On 30 mars 2010, at 10:00, Gareth Nelson   
wrote:

> It would be wise to stay on the side of caution and presume anyone who
> distributes the viewer is liable, even if they are not the ones who
> introduced the original defects.
> Even with that being said though, personally I would never dream of
> giving away software free of charge if it includes a warranty - that's
> basically infinite liability with something GPLed, as every single
> person who obtains the software could in theory sue you.
>
> On Tue, Mar 30, 2010 at 6:58 AM, Marine Kelley  
>  wrote:
>> Thank you for the heads up Morgaine. Correct me if I'm wrong, but if
>> the "no warranty" clause vanishes from the source code, then does  
>> that
>> mean that LL guarantees that the code of the original viewer is bug-
>> free ? We can't guarantee it as open source programmers if the
>> original devs don't in the first place, and they can't expect us to
>> remove it ourselves afterwards, so who is liable for the original
>> defects if a law suit was started because of an exploit ?
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting  
>> privileges
>>
>
>
>
> -- 
> “Lanie, I’m going to print more printers. Lots more printers. One  
> for
> everyone. That’s worth going to jail for. That’s worth  
> anything.” -
> Printcrime by Cory Doctrow
>
> Please avoid sending me Word or PowerPoint attachments.
> See http://www.gnu.org/philosophy/no-word-attachments.html
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Marine Kelley]

Well sure, if I stated that I agree to be responsible for whatever  
defect, past present and future, the SL viewer may introduce, but I'm  
not crazy, and I doubt anybody else would be either. This is called an  
abusive clause and that does not stand in court. Therefore, I do not  
see the "no warranty" clause go away, nor us be expected to remove it  
ourselves. And therefore I do not see us being sued by users for  
whatever bug they may encounter.

But I might be over-optimistic, as usual.

On 30 mars 2010, at 10:17, Gareth Nelson   
wrote:

>> It wouldn't stand in court anyway, to expect second hand code to be  
>> liable
>> when first hand code is not.
>
> Any precedent on that? Surely it's better to have the policy rewritten
> rather than rely on it not standing up in court
___
Policies 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

[Marine Kelley]

Well LL cannot possibly write a clause that shifts the liability onto the
users for their own bugs, this would be an abusive clause, and I really
don't think that is what they tried to achieve. As I said, an abusive clause
does not stand in court anyway, so this point is rather moot. What they want
to do is to protect themselves in case of an exploit used through a TPV,
because they cannot possibly plug all the future security holes, by shifting
the responsibility of any malicious code onto its developers, and it's okay.

If suddenly my viewer began crashing sims or stealing money and assets on
purpose, then yes of course I must be stopped. But if someone takes my code
and adds some malicious code to it to crash sims, then it would be easy to
prove that the defect neither comes from me, nor from LL. I think that's
what the TPV policy is trying to achieve. Joe Linden tried to say exactly
that, but since he is not a lawyer, his words weight exactly as much as
ours. We need a LL-side lawyer to be made sure.

Now, I know, "What the TPV policy says is different from what it means". And
also "We shouldn't gamble our rights on an assumption". But really that
volatile and outrageous liability would not stand in court, because it is
abusive in its words, and can be abused in the facts.

And lastly, as long as your name does not appear anywhere, nobody can sue
you directly at will, only LL can, and this is very unlikely that they will
before making absolutely sure that your code is malicious. If a big company
attacks a single individual on blurry charges and an abusive contract, and
then loses, it gives them a very, very bad press. The TPV policy is extreme,
and would only work in extreme cases. I think we honest devs are safe.
That's my opinion and that's why, so far, I am not quitting yet despite all
the fuss around the policy (that was for Jesse *winks*).


On 30 March 2010 12:10, Morgaine  wrote:

> Marine, you raise a good question, but it's hard to give a reasonable
> answer to a "what if" question about a totally unreasonable TPV policy.  :-)
>
> The fact that the TPV document places the burden of liability for LL's own
> bugs (and many other things) on TPV developers' shoulders despite the
> extremely clear "NO WARRANTY" clauses of GPLv2, combined with Linden's
> refusal to discuss it further, just shows how totally beyond the bounds of
> reason this whole thing has become.
>
> The safest approach for TPV developers is probably to find a way to avoid
> falling under TPV liability at all.  This is achieved by any of the 3
> alternatives that I listed, all of which employ the simple strategy of
> relying on licenses that LL cannot overturn.  Unfortunately it also means
> not using any new code released by LL after 30th April (not 1st April as I
> incorrectly stated).
>
> Developers can of course look at LL's post-April code, as the GPL always
> allows that, but copying their code would be very dangerous since that would
> bring their post-TPV rules on liability into effect, and the safety of the
> "NO WARRANTY" clauses then becomes a matter for debate.  A genuine
> independent re-implementation of any new Linden code would be required to
> retain the "NO WARRANTY" granted by a pre-TPV GPL license, the more
> different the better.  On the positive side, that's an opportunity for
> making TPV code better than LL's. :-)
>
> Note that none of this addresses how TPV developers can continue to exist
> in SL though, since LL could ban you for not agreeing to be bound by the
> TPV.  The only thing that this strategy provides is a reasonable chance to
> be protected by the "NO WARRANTY" clauses of open licenses.
>
> Just in case some TPV developers here haven't heard, Imprudence developers
> have made an official 
> announcement<http://imprudenceviewer.org/2010/03/26/an-important-announcement-regarding-the-third-party-viewer-policy/>listing
>  in detail the reasons why they have to reject the TPV policy in
> order to be able to continue developing the viewer.  It is very well
> reasoned, and is required reading for TPV developers.  It needed the
> personal sacrifice of not developing for SL but for Opensim grids instead
> (thus escaping the "TPV" definition), and personally using only the Linden
> viewers when in SL.  In exchange for this, the Imprudence developers are not
> subject to the TPV's outrageous conditions, particularly on personal
> liability.  Any use of Imprudence in SL is then at the user's own risk and
> without placing liability on the developers.
>
> It's very sad that Linden Lab forces open source teams to these lengths.
> It's not in the spirit of open source at all.  Indeed, the terms of t

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

[Marine Kelley]

Naturally but do they apply to the developer ? They should void only  
for the original dev who implemented the feature intentionally, if  
any. Keeping in mind that the servers are as responsible to protect  
the data add the viewers are responsible to not attack them. To me  
developers (paid by LL as well as open source therefore unpaid) should  
be innocent until proven guilty. That's the only way to keep a sane  
relationship.


On 30 mars 2010, at 14:52, Simon Disk  wrote:

> I think I have read a different TPV policy than most people here. I  
> do not see how clauses 11 and 12 are being overridden. Both clauses  
> stipulate that the GPL cannot be used to violate the law. So when  
> you use a TPV and connect to the SL grid and then steal content that  
> you did not create or disrupt Linden Lab's service, those clauses no  
> longer apply to 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] TPV - Nope

[Marine Kelley]

This is a sad day. I remember the times when you were indeed the most
prolific contributor, when your own third-party viewer was the toast of SL,
and the SL viewer has benefited greatly from your work. I think everyone can
thank you for that (and everyone has !).

And I'd like to thank you for helping me get started on my project back in
the days.

Best of luck for whatever next project you will work on,
Marine


On 3 April 2010 15:51, Nicholaz Beresford  wrote:

>
> Hi All!
>
> Since the TPV and new TOS seems to be in effect now, I'd like to finally
> comment on it too.
>
> For those of you who don't know me, I'm the person who started the first
> thrird party viewer (in fact I made the original Wiki page
> http://wiki.secondlife.com/w/index.php?title=Alternate_viewers&redirect=no
> )
> and as it appears I'm still the person with the most accepted patches to
> the viewer (except maybe SnowGlobe commits, I'm not sure if or how they
> are counted) and the winner of the year 2007 Linden OpenSource Award.
>
> I have not made viewers in quite some time and have basically resigned
> over gripes about how the Lindens handle open source and the OS
> community in general, so I'm not sure if my words still have any weight
> (not that any resident's words have any weight with the Lindens, except
> Stroker Serpentine's maybe, when they are voiced through a lawyer or
> court).  So just take my words as coming from the elder statesman armchair.
>
> However, I still had my account and a couple of alts, but this new
> TOS/TPV, now that's it's out of the box about to be in effect soon, puts
> the final nail into the coffin.
>
> I'm not going to try to dissect what's written there or what the
> practical legal impact is.  Living in Germany with strong customer
> protection laws, legal impact in fact is most likely zilch, but what the
> TOS and the TPV does, is to show the Linden's view of their relationship
> beween themselves and their residents and OS developers.
>
> While it's not a secret that I have been less than thrilled by their
> views and actions in the past, I find the TPV taking it to a new level.
>
> It is their servers, their assets, their business.  But trying to use
> their power in a way like this, dictating the terms, making far reaching
> demands and lightly brushing off concerns is unacceptable.
>
> Of course a viewer maker needs comply with the law, no TOS is needed for
> that.  But making demands like the branding (as if the word "Life" was
> their invention) or demanding disclosure like section 8d which goes far
> beyond any legal obligations is just way over the top for me.
>
> I took their sources based on GPL once and at that time alternate
> viewers seemed to be welcome and later I even jumped through a few hoops
> to meet their new whims (e.g. complying with their trademark policies).
>  In the recent past, I have still used SL on occasion as a regular user
> and now, trying to use SL as a user, I'm finding myself being presented
> with new demands because my past viewers are still out there for download.
>
> Am I going to agree to that?  No frigging way.  I certainly do not want
> to have any relationship with a company who is trying to use their
> position of power in a way like that, no matter if it's legally valid or
> not.  The new TOS/TPV defines who LL thinks they are and who they think
> their users are and what kinds of demands and claims LL thinks they can
> make or what they think is acceptable and fair.
>
> I can only recommend to every viewer maker and contributor to have a
> look at this broader picture and evaluate if their contributions in time
> and efforts are worthwhile.   Mine where fun when LL was a different
> company, but there I no way I would have made contributions under the
> current terms.  In fact I won't even log in again under the new terms
> and have canceled my accounts today.
>
>
> Nicholaz.
>
>
> ___
> Policies 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] Brown-bag meeting to continue dialog on TVPV next Tuesday (4/13)

[Marine Kelley]

Thank you Joe

I'd like to chime in and bring my own concerns since I won't make it to the
meeting. My primary concern is about the Viewer Directory and here are my
questions :

- Will registering a TPV to the Viewer Directory become mandatory one day ?
If so, how can we be absolutely certain that our RL names and info won't
suddenly appear in clear on the webpage without our prior consent, even
after registering ?

- Why the need for RL info at all since LL already knows how to join us in
case of a problem ? Why do we have to enter these data again ?

- There is no privacy policy on this particular webpage, it is just said
that LL "may" make them available. I'd like to point out that this is
strictly illegal in most countries (especially in Europe), LL needs our
explicit written agreement prior to publishing our data. Registering to a
webpage with a "may" or "may not" is not a written agreement.

Thank you,
Marine


On 8 April 2010 22:24, Joe Linden  wrote:

> Hello, all.  I've been reading the ongoing commentary here, on various
> blogs, irc, and in-world groups about the recently introduced Third Party
> Viewer Policy and Directory and I'd like to host an "office hour" or
> informal brown bag to make the conversation a little more synchronous for
> those who are interested.  I plan to hold three of these over the next
> couple of weeks, at times that might be friendlier for some than others, but
> the first one will happen next Tuesday, 4/13 at noon PDT.  I'd like to
> address questions about the intent of the policy, how we will be using the
> Directory going forward, and see if I can gather the specific concerns that
> have been raised by the community over the past several weeks.  It'll be an
> informal Q&A session, held in voice, at this location:
>
> http://maps.secondlife.com/secondlife/Linden%20Estate%20Services/229/230/29
>
> No RSVP needed, and feel free to rebroadcast the invite to others you think
> would benefit from open dialog around the subject.
>
> I hope to see many of you there next week.
>
> -- Joe
>
> ___
> Policies 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] Where has "Spare time" gone in 2.0 ?

[Marine Kelley]

Hello all,

As I was testing the RLV on viewer 2.0, I realized that the "Spare time"
entry in the sim console was gone, it used to be right under "Script time"
and indicated how healthy the sim was, and now there is no easy way to know
anymore. Has it been removed intentionally, or by mistake ? Is it at another
place now ? This piece of information is really critical to sim owners or
even visitors who want to assess the health of the sim in real time.

Besides this entry is not even sent by the sim, it is calculated by the
viewer as (22.5 - net - physics - sim - agent - images - script), unless I'm
mistaken. It would be rather easy to put it in again.

Thanks,
Marine
___
Policies 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 has "Spare time" gone in 2.0 ?

[Marine Kelley]

Thanks for opening this JIRA, Stickman. Voted.


On 27 April 2010 03:04, Stickman  wrote:

> > My guess is that this is a simple oversight when porting over to
> > viewer 2.0 ui infrastructure.
>
> If I had more time, I'd make it my crusade to document and request the
> re-addition of every feature missing in 2.0. There's a fair list of
> things you can't do anymore. Most of them are ancillary, like this,
> but having them missing is a little annoying.
>
> Anyway, here's the Jira for the missing Spare Time:
> http://jira.secondlife.com/browse/VWR-19210
>
> Samuel Linden, a UI Linden said if a Jira is made a missing feature,
> they'll see it. He also said that missing features are something they
> do want to bring back. I don't know how they define "feature" but I
> hope it's the same as mine. (Source: Samuel Linden's office hours.)
>
> Stickman
>
___
Policies 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] Thank you for updating the Viewer Directory requirements

[Marine Kelley]

Hi, I'd like to thank whoever changed the application page on the Viewer
Directory, the RL info fields used to be "publishable" (they had a little
cross next to the little star indicating that they were mandatory), and
that's what was holding me from registering the RLV there. Today I just
noticed that these fields (RL name, address etc) are not "publishable"
anymore, which mostly addresses the concerns I had before, namely having my
RL info published without my agreement. Therefore I have applied to register
the RLV on the Viewer Directory today, we'll see how it goes.

So, thank you whoever did this change !

Marine

PS : Of course I might just be silly and had not noticed a change that
occurred days or weeks ago, or even misread in the first place, in which
case disregard this message completely and let me hide under a rock *g*
___
Policies 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] Thank you for updating the Viewer Directory requirements

[Marine Kelley]

This is not a choice I made lightly, but many people simply did not
understand why the RLV was not in the directory, and despite the number of
times I said it was compliant, people just can't get their heads around the
fact that TPV policy compliance and Viewer Directory listing are two totally
different things. So I yielded.

Yes in some countries, requiring private RL data is illegal for a company
that is not a public administration. However these info are already known by
LL, they didn't require anything more than they already have. I gave mine
(again) because nothing said that these data were possibly going to be
published without my consent, at any time (LL has a privacy policy which is
not rewritten on the directory, so I assume the regular one applies). And if
my RL data became published one day without my consent, I'd have grounds to
sue LL for that and I'd win. Not that this is my intent in any way, but I'm
just saying that it would cause damage on both parts if such a thing
happened. So I am confident.


On 28 April 2010 20:40, Henri Beauchamp  wrote:

> On Wed, 28 Apr 2010 18:02:24 +0200, Marine Kelley wrote:
>
> > Hi, I'd like to thank whoever changed the application page on the Viewer
> > Directory, the RL info fields used to be "publishable" (they had a little
> > cross next to the little star indicating that they were mandatory), and
> > that's what was holding me from registering the RLV there. Today I just
> > noticed that these fields (RL name, address etc) are not "publishable"
> > anymore, which mostly addresses the concerns I had before, namely having
> my
> > RL info published without my agreement. Therefore I have applied to
> register
> > the RLV on the Viewer Directory today, we'll see how it goes.
>
> This is still *way* beyond what I am ready to provide to LL: it is
> *illegal*
> in France to require private data that is not strictly necessary to provide
> a service. Reference: Law Informatique et Liberté, Article 6, paragraph 3
> (http://www.cnil.fr/fileadmin/documents/en/Act78-17VA.pdf), citation:
> "The collected data [...] shall be adequate, relevant, and not excessive
> in relation to the purpose for which their are obtained and their further
> processing."
>
> Being published in the directory should not be made conditional to the
> divulgation of my real name and address. All what Linden Lab needs to
> have is my avatar name and an ISP based email (which they both already
> got): even in case of a legal issue, this info is sufficient for the
> police or the justice to identify me.
>
> Beside, given LL clearly states that they can modify the TPV policy at any
> time, how could you be sure that they won't suddenly decide to reveal your
> private data publicly ?... Another concern is about the security of your
> data. Linden Lab has already an history with data theft (see:
> http://www.bit-tech.net/news/gaming/2006/09/12/Second_Life_servers_hacked/1
> )
> and this may happen again, particularly with secondary and weakly protected
> databases such as the TPV directory.
>
> Sorry, but I will not endanger my real life by risking to get my real name
> publicly associated with my SL avatar name.
> As a French citizen, I will go by the French law which allows me to stay
> anonymous and preserve my private data.
>
> I already raised this concern, but apparently Linden Lab is ignoring it...
>
> For this reason and although fully TPV policy compliant, the Cool VL Viewer
> will not be registered in LL's TPV directory.
>
> 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

[opensource-dev] Cannot wear two different bodyparts at the same time

[Marine Kelley]

Hello all,

I have just filed a JIRA under Viewer 2.0.1 (although it shows for 2.0.0 as
well) at https://jira.secondlife.com/browse/VWR-19425

In short, when you wear a new skin and a new hair at the same time (by
selecting both and pressing Wear), one of them is worn then removed, leaving
you with the default version and an error message. I have discovered this
when testing RLV 2.0 (and pulling my hair for days over it) which uses
outfits very extensively and that ability is crippled. But since it is also
present in the vanilla SL viewer 2.0, I don't see what I can do.

Have anyone encountered this problem ?

Marine
___
Policies 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] Problem compiling llcommon on viewer 2.1 beta

[Marine Kelley]

Hello,

I am having the following link error when trying to compile the llcommon
project on Viewer 2.1 beta extracted from viewer-external :

1>-- Build started: Project: llcommon, Configuration: Release Win32
--
1>Linking...
1>   Creating library
D:\SL\linden\indra\build-vc80\llcommon\Release\llcommon.lib and object
D:\SL\linden\indra\build-vc80\llcommon\Release\llcommon.exp
1>exception_handler.lib(exception_handler.obj) : error LNK2019: unresolved
external symbol "__declspec(dllimport) void __cdecl std::_Throw(class
stdext::exception const &)" (__imp_?_th...@std@@yaxabvexcept...@stdext@@@Z)
referenced in function "public: void __thiscall
stdext::exception::_Raise(void)const " (?_ra...@exception@stdext@@QBEXXZ)
1>exception_handler.lib(exception_handler.obj) : error LNK2001: unresolved
external symbol "__declspec(dllimport) void (__cdecl*
std::_Raise_handler)(class stdext::exception const &)"
(__imp_?_raise_hand...@std@@3p6axabvexcept...@stdext@@@ZA)
1>D:\SL\linden\indra\build-vc80\sharedlibs\Release\llcommon.dll : fatal
error LNK1120: 2 unresolved externals
1>Build log was saved at
"file://d:\SL\linden\indra\build-vc80\llcommon\llcommon.dir\Release\BuildLog.htm"
1>llcommon - 3 error(s), 0 warning(s)
== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==


I have copied the libraries from libraries/i686-win32/lib/debug/ to
libraries/i686-win32/lib/release/ but it didn't help. Does anyone know what
to do please ? It seems to come from the new google_breakpad library but I
don't know anything about it. I just know it was not there before.

Thanks for any piece of help,
Marine
___
Policies 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] Problem compiling llcommon on viewer 2.1 beta

[Marine Kelley]

Hi Merov, thank you for looking into this !

I'm on Windows 7, trying to compile viewer-external as I always do :

- I unzip the artwork from version 2.0.0 (knowing that I will have to
complete it with some of the icons from the official 2.1, like the icons for
the system folders)
- I unzip a very old library zip file of mine (it is more than 2 years old
and contains ares, fmod and all, but is still operational at least until
2.0.1)
- I run VC 2005, select the "Release" configuration, go to Configuration
Manager, uncheck all the "tests" and "integration" projects (plus "package")
- I open the Properties window on secondlife-bin and remove the /Zm1000
option from the command line
- I build the whole thing

But even just building llcommon will give me the error I mentioned, no need
to build the whole solution. This is the first time I get this error, and
since I noticed that google_breakpad was not part of the viewer before, and
surprisingly it uses an exception_handler.lib that does not provide the
correct functions...

That's all I can think of but I'm sure there is more.

Thanks again,
Marine



On 25 June 2010 22:39, Philippe (Merov) Bossut  wrote:

> Hi Marine,
>
> I just built the tip of viewer-external on my Windows XP machine with no
> problem. Could you tell us a bit more on how you get things together? Do you
> use develop.py? Do you do a standalone build? Which Solution Configuration
> are you building?
>
> Cheers,
> - Merov
>
> On Thu, Jun 24, 2010 at 1:30 PM, Marine Kelley wrote:
>
>> Hello,
>>
>> I am having the following link error when trying to compile the llcommon
>> project on Viewer 2.1 beta extracted from viewer-external :
>>
>> 1>-- Build started: Project: llcommon, Configuration: Release Win32
>> --
>> 1>Linking...
>> 1>   Creating library
>> D:\SL\linden\indra\build-vc80\llcommon\Release\llcommon.lib and object
>> D:\SL\linden\indra\build-vc80\llcommon\Release\llcommon.exp
>> 1>exception_handler.lib(exception_handler.obj) : error LNK2019: unresolved
>> external symbol "__declspec(dllimport) void __cdecl std::_Throw(class
>> stdext::exception const &)" (__imp_?_th...@std@@yaxabvexcept...@stdext@@@Z)
>> referenced in function "public: void __thiscall
>> stdext::exception::_Raise(void)const " (?_ra...@exception@stdext@@QBEXXZ)
>> 1>exception_handler.lib(exception_handler.obj) : error LNK2001: unresolved
>> external symbol "__declspec(dllimport) void (__cdecl*
>> std::_Raise_handler)(class stdext::exception const &)"
>> (__imp_?_raise_hand...@std@@3p6axabvexcept...@stdext@@@ZA)
>> 1>D:\SL\linden\indra\build-vc80\sharedlibs\Release\llcommon.dll : fatal
>> error LNK1120: 2 unresolved externals
>> 1>Build log was saved at
>> "file://d:\SL\linden\indra\build-vc80\llcommon\llcommon.dir\Release\BuildLog.htm"
>> 1>llcommon - 3 error(s), 0 warning(s)
>> == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped
>> ==
>>
>>
>> I have copied the libraries from libraries/i686-win32/lib/debug/ to
>> libraries/i686-win32/lib/release/ but it didn't help. Does anyone know what
>> to do please ? It seems to come from the new google_breakpad library but I
>> don't know anything about it. I just know it was not there before.
>>
>> Thanks for any piece of help,
>> Marine
>>
>> ___
>> Policies 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] Problem compiling llcommon on viewer 2.1 beta

[Marine Kelley]

I have fixed the problem !

It was due to my VS2005 not being upgraded to SP1. It just so happens that
Microsoft has moved some classes from std to stdext, and "exception" is one
of them, hence the linking issue.

Thank you for trying to help, and I hope this will help anyone who stumbled
upon this problem... unless I am the only one on Earth not to have upgraded
her VS2005 to the latest service pack. lol

Take care,
Marine


On 26 June 2010 08:25, Lance Corrimal  wrote:

> I think someone of you guys who successfully build 2.1 should put
> detailed steps on the wiki...
>
>
>
> Am Samstag 26 Juni 2010 schrieb Nicky Perian:
> > I built viewer-external on 6/19. Used Vista 32 and VC++Express
> > 2005. Took 5 builds. Logs and steps taken are here. This was all
> > the way to a setup.exe.
> >
> >
> >
> >
> >
> > 
> > From: Marine Kelley 
> > To: Philippe (Merov) Bossut 
> > Cc: opensource-dev@lists.secondlife.com
> > Sent: Fri, June 25, 2010 4:30:53 PM
> > Subject: Re: [opensource-dev] Problem compiling llcommon on viewer
> > 2.1 beta
> >
> > Hi Merov, thank you for looking into this !
> >
> > I'm on Windows 7, trying to compile viewer-external as I always do
> > :
> >
> > - I unzip the artwork from version 2.0.0 (knowing that I will have
> > to complete it with some of the icons from the official 2.1, like
> > the icons for the system folders) - I unzip a very old library zip
> > file of mine (it is more than 2 years old and contains ares, fmod
> > and all, but is still operational at least until 2.0.1) - I run VC
> > 2005, select the "Release" configuration, go to Configuration
> > Manager, uncheck all the "tests" and "integration" projects (plus
> > "package") - I open the Properties window on secondlife-bin and
> > remove the /Zm1000 option from the command line - I build the
> > whole thing
> >
> > But even just building llcommon will give me the error I mentioned,
> > no need to build the whole solution. This is the first time I get
> > this error, and since I noticed that google_breakpad was not part
> > of the viewer before, and surprisingly it uses an
> > exception_handler.lib that does not provide the correct
> > functions...
> >
> > That's all I can think of but I'm sure there is more.
> >
> > Thanks again,
> > Marine
> >
> >
> >
> >
> > On 25 June 2010 22:39, Philippe (Merov) Bossut
> >  wrote:
> >
> > Hi Marine,
> >
> > >I just built the tip of viewer-external on my Windows XP machine
> > >with no problem. Could you tell us a bit more on how you get
> > >things together? Do you use develop.py? Do you do a standalone
> > >build? Which Solution Configuration are you building?
> > >
> > >Cheers,
> > >- Merov
> > >
> > >On Thu, Jun 24, 2010 at 1:30 PM, Marine Kelley
>  wrote:
> > >>Hello,
> > >>
> > >>I am having the following link error when trying to compile the
> > >>llcommon project on Viewer 2.1 beta extracted from
> > >>viewer-external :
> > >>
> > >>1>-- Build started: Project: llcommon, Configuration: Release
> > >>Win32 --
> > >>
> > >>
> > >>
> > >>1>Linking...
> > >>1>   Creating library
> > >>D:\SL\linden\indra\build-vc80\llcommon\Release\llcommon.lib and
> > >>object
> > >>D:\SL\linden\indra\build-vc80\llcommon\Release\llcommon.exp
> > >>1>exception_handler.lib(exception_handler.obj) : error LNK2019:
> > >>unresolved external symbol "__declspec(dllimport) void __cdecl
> > >>std::_Throw(class stdext::exception const &)"
> > >>(__imp_?_th...@std@@yaxabvexcept...@stdext@@@Z) referenced in
> > >>function "public: void __thiscall
> > >>stdext::exception::_Raise(void)const "
> > >>(?_ra...@exception@stdext@@QBEXXZ)
> > >>
> > >>
> > >>
> > >>1>exception_handler.lib(exception_handler.obj) : error LNK2001:
> > >>unresolved external symbol "__declspec(dllimport) void (__cdecl*
> > >>std::_Raise_handler)(class stdext::exception const &)"
> > >>(__imp_?_raise_hand...@std@@3p6axabvexcept...@stdext@@@ZA)
> > >>
> > >>
> > >>
> > >>1>D:\SL\linden\indra\build-vc80\sharedlibs\Release\llcommon.dll :
> > >>fatal error 

[opensource-dev] Using the open source exe into the regular SL folder for 2.1

[Marine Kelley]

Hi all,

As some of you now, my usual method of releasing a RLV is to only release
the exe and its settings.xml file, and to instruct the user to copy them
both into the SL folder and into its app_settings folder respectively. This
allows for light downloads and uploads (it would take me hours to upload a
full viewer), and to benefit from the libraries of the SL viewer.

But since 2.1 I cannot do that because no version I find on svn ever works
with the current official SL viewer 2.1. It used to be an issue with the XUI
XML files, now I'm getting an error message about the entry for
"format_to_utf" not being found in llcommon.dll with revision 3587. In any
case the source I find in viewer-external never seems to match the viewer
downloaded from the SL download page. And the "sources download" wiki page
has been updated the last time for 2.0... on Feb 23.

Does any of you know when/if the source code will be in synch with the
official viewer ?

Thanks,
Marine
___
Policies 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 avatar name on the login screen in Viewer 2.

[Marine Kelley]

Hi Suezanne, you may want to look at the method LLPanelLogin::setFields() in
newview/llpanellogin.cpp

Marine

On 3 August 2010 06:31, SuezanneC Baskerville  wrote:

> Where is the remembered username stored, where is read and written in the
> source code, and how do you make it not appear on your login screen?
>
> By "remembered username"  I mean the username that appears pre-filled on
> the login screen in Viewer 2.
>
> Someone asked  in the forums how you make the username be blank when you
> launch Viewer 2.  That drove me to looking at the source code to find where
> the name is fetched from and I haven't been able to find it so far.
>
> I'm asking here because I don't know any better place to find people that
> are familiar with SL source code.
>
> Thanks,
>
> Sue Baskerville
>
>
>
>
> ___
> Policies 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] Fixing the Assets

[Marine Kelley]

lol I knew it ! This text IS actually a Markov chain !

That or it is aimed at a subset of the members of this list who actually
know the encryption key to extract the hidden message. But to the rest of
us, this is just nonsense.



On 7 August 2010 17:34, Dzonatas Sol  wrote:

> Oz Linden (Scott Lawrence) wrote:
> >   On 2010-08-06 17:28, Dzonatas Sol wrote:
> >
> >> Here is the proposal, as a routine. The written logical explanation in
> >> English with normalized words defeats the purpose of the routine for
> >> every reason that supports it.
> >>
> > Clarity is never wasted.
> >
> > You have not given any hint at all as to what problem you are trying to
> > solve - without at least that, there is no way to even start thinking
> > about what you've written.
> >
>
> Thanks!
>
> Sometimes the concept is never understood when the meaning to the word
> concept is not understood. If the content is money, it means nothing, to
> We, who appreciate the honey.
>
> We use use the spoon to eat the honey.
>
> Bend the spoon?
>
> Easy.
>
> --
> --- https://twitter.com/Dzonatas_Sol ---
> Web Development, Software Engineering, Virtual Reality, Consultant
>
> ___
> Policies 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] V2.X & V1.X support on the same machine

[Marine Kelley]

I check out the code of the viewer from svn and not hg... Does that make me
a kid now ?


On 7 August 2010 22:42, Dzonatas Sol  wrote:

> Dzonatas Sol wrote:
> > They've had an adult grid that is suppose to be fast, easy,... and fun.
> >
> > They've had an teen grid that is suppose to be ... easy... fast... clean?
> >
> > Sincerely,
> >
> > ___  Life
> >
>
> I believe I found a solution.
>
> The svn code should be for only "kids"... even people who decide to make
> their avatars like "kids"... so a split code base "right there" where
> the more known "adult" possibility can be found in the hg repository.
>
> I think that provides several options to get LL out of its corner.
>
> We know there is confusion between "shared" code base and "split" code
> base... yet we understand this.
>
> It's the same feel... they need to earn it to grow up... but its got to
> be their choice to know what they lost. Some have already taken that
> choice...
>
> .. they just haven't quite... you know.
>
> -- "."  [Fixt.]
>
>
>
>
>
> --
> --- https://twitter.com/Dzonatas_Sol ---
> Web Development, Software Engineering, Virtual Reality, Consultant
>
> ___
> Policies 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] food for thought: multiple attachment support versus server-side lag

[Marine Kelley]

I think that's precisely why LL wanted to keep control of this feature
server side by deciding how many objects can be worn (possibly according to
the script memory limits to come), instead of going the avatar_lad.txt fake
attachments route.



On 16 August 2010 15:58, Lance Corrimal  wrote:

>  Hi,
>
>
> I just had this thought...
>
> In recent versions there's support for multiple attachments per
> attachment slot.
>
> In recent SERVER versions, there's a nasty bug that freezes whole sims
> when an avatar who wears lots of scripted attachments enters or leaves
> the sim... (SVC4196)
>
> Now, with multiple attachments per slot, how likely is it that john the
> mindless noobie will end up wearing lots of invisible, scripted
> attachments that are not that obvious, but contain a LOT of scripts...?
>
> Isn't there an obvious conflict of interests here?
>
>
> 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] food for thought: multiple attachment support versus server-side lag

[Marine Kelley]

Oh you cannot decide on which slot you want to wear a piece of clothing
(say, a shirt), you can only "Add" it to what you are wearing and it will go
on top. But you can reorder it later by going to the My Outfit tab, and
click on the tools button to edit your appearance. Then you will see up and
down arrows next to the name of each piece of clothing if you are wearing
more than one layer of the same type. For example, you can move a shirt over
or below a t-shirt that way.

(PS : sorry for the double mail Lance, I only replied to you the first time)


On 16 August 2010 16:19, Lance Corrimal  wrote:

> hi,
>
>
> that's a bit better.
>
> more thought about multiwearables:
>
> let's say i have a tattoo, and a tank top, both on undershirt... with
> viewer
> 2.1 i can wear them both.
> How do i define what goes on top?
>
> by which order i put them on? and what about when i relog?
>
>
> bye,
> LC
>
>
> On Monday 16 August 2010 16:13:49 Marine Kelley wrote:
> > I think that's precisely why LL wanted to keep control of this feature
> > server side by deciding how many objects can be worn (possibly according
> to
> > the script memory limits to come), instead of going the avatar_lad.txt
> fake
> > attachments route.
> >
> > On 16 August 2010 15:58, Lance Corrimal 
> wrote:
> > >  Hi,
> > >
> > > I just had this thought...
> > >
> > > In recent versions there's support for multiple attachments per
> > > attachment slot.
> > >
> > > In recent SERVER versions, there's a nasty bug that freezes whole sims
> > > when an avatar who wears lots of scripted attachments enters or leaves
> > > the sim... (SVC4196)
> > >
> > > Now, with multiple attachments per slot, how likely is it that john the
> > > mindless noobie will end up wearing lots of invisible, scripted
> > > attachments that are not that obvious, but contain a LOT of scripts...?
> > >
> > > Isn't there an obvious conflict of interests here?
> > >
> > >
> > > 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
>
___
Policies 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] Open Viewer Development Announcement

[Marine Kelley]

> Suggestions:
> - make notifications (inventory offers, group notices) stay on screen like
> they used to be
>

I'm sure there is a debug setting or an XML option to do that, I'll look
when I have time. But they would pile up pretty quickly, unlike 1.x the
notification do not hide each other (which is good) but stack up to the top
of the screen, cluttering it rather quickly when you're in group chat.

My own biggest gripe about the notification system is silly but very
annoying : when you receive an object or a notecard you  get a
"Keep/Discard/Block" window, then once you click "Keep" you get another
notification telling you you've accepted the offer. Not only this
notification is rather useless (I know I have accepted the offer or joined
the group or whatnot, I've just done it), but the "OK" button to get rid of
this confirmation is exactly where the "Discard" button of the next
notification will be ! More than once I have hit "Discard" by mistake on the
second notification of, say, my mailbox that sends me the notecards of my
customers. And since it comes from an object, "Discard" will simply destroy
the transferred item, not put it in trash. Because of this, one more
customer believes I do not respond when someone buys something from a vendor
of mine and my server does not deliver.


> - put chat and IM back into a non-modal tabbed floater, with the option of
> chat being detached into its own "chat history" floater
>

Chat is not part of the IM window anymore but you can make it tabbed by
checking Preferences > Chat > Show IMs in > Tabs, and relogging.


> - get rid of all unnecessary spacing in chat and IM
>

Agreed. But you can do it yourself by checking Preferences > Chat > Enable
plain text IM and chat history


> - IM's don't need a whole third of the window wasted for showing the other
> person's profile. Just put a "profile" button there. That profile FLOATER
> then
> can have all the other buttons that the old one has: "pay", "add friend",
> "teleport", and so on. If you really think those buttons should be right in
> the IM floater, put them in a toolbar along the top.
>

Well these buttons are hidden with the arrow button, but there is a lot of
wasted space on the top of the window indeed.


>
>
> Overall suggestions:
> all non-modal floaters should turn partially transparent as soon as the
> user
> clicks outside of them.
>
>
I believe that's what 2.1 does.
___
Policies 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] [IDEA] Access to Object content without rezzing. (was: Open Viewer Development Announcement)

[Marine Kelley]

Eep ! I hope it won't bring its own share of permission defects ! This is
VERY sensitive matter that is being fiddled with here !


On 17 August 2010 16:31, Boroondas Gupte  wrote:

>  [I'm cross posting this to several mailing lists to solicit feedback. To
> avoid clutter, please *do not reply to all of them* when answering, unless
> there's a valid reason to do so. To avoid scattering the discussion, please
> *do reply to 
> sl...@lists.secondlife.com
> * when answering. Thanks!]
>
> On 08/17/2010 01:52 PM, mysticaldem...@xrgrid.com 
> wrote:
>
>
> [...] V1.23 as well, makes designing take much
> longer than it should.  Like having to rezz objects to edit their contents.
> Ever have to rezz hundreds of boxes to update something? Or correct the
> permissions.  Have to rezz a box to get to its contents I think is one of
> the most difficult things for new people.  Having to rezz objects to get to
> stuff, then copy to inventory, then find it in inventory, etc.
>
>  I have made a suggestion on how to solve this UI-wise at VWR-2427 Allow
> objects containing other items to be expanded within the 
> Inventory.
> I'd like to hear about other approaches, too!
>
> The main problem when coming up with complete solution for these use cases
> is, though, that they'll probably require some fundamental changes on the
> (non-opensource) server side:
>
> As far as I know, currently, Object Inventory is served by the Region, and
> the Region only knows about rezzed Objects. So either a way would have to be
> added for the Region to proxy non-rezzed Objects to the client or clients
> would have to be granted direct (or other indirect) access to the asset
> storage system.
>
> I think the same goes for the Object assets themselves, so these
> restrictions not only apply to manipulating an Object's content, but also to
> editing the Object itself without rezzing it (e.g. changing it's size, shape
> or color).
>
> I don't know if the AD 
> /RDseparation
>  of OGP/AWG/VWRAP will help here, thus CCing their mailing list.
> Maybe someone from there can shed some light on this.
>
> cheers
> 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
>
___
Policies 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] Open Viewer Development Announcement

[Marine Kelley]

That would be awesome. I know there are reasons behind the removal of the
pie menu and its replacement by a well known list menu, but PLEASE I am so
much more productive and less frustrated with the old pie menu ! Muscle
memory and size of the clickable areas and all that. Simply put with the
list menu I have to look where I'm clicking, with the pie menu I don't. It
is a huge gain of time.


On 19 August 2010 19:24, Kadah  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 8/19/2010 10:16 AM, Henri Beauchamp wrote:
> > A smarter approach would be to automatically move the cursor itself to
> > the center of the pie menu (without moving the latter to avoid an
> > annoying "drifting" effect) when you click on a sub-menu.
> >
> > However, I never found the fact that the pie menu was not centered on
> > the cursor after a click on a sub-menu item to be an hinderance, since
> > the whole idea about pie menus is that you quickly get your "muscle
> > memory" trained and don't even have to look at the menu any more after
> > you are trained. For example, my "muscles know" that to delete an
> > in-world object I must right click on it, then move south, left click
> > (for "More >"), and move north east and left click again (for Delete).
> > With the new method, I'd simply have to replace "north east" with
> > "east" in my muscle memory (which would make me miss quite a number
> > of clicks at first, since this memory has been trained and used for
> > almost 4 years now, so if you reimplement pie-menus in this new way,
> > I'd appreciate a debug option to prevent the auto-recentering of the
> > cursor)...
>
> Same here. I would impliment pie menus as 2 debug settings,
> UseLegacyPieMenus and LegacyPieMenusDisableAutoCenter.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJMbWjDAAoJEIdLfPRu7qE2mucIAIViouN+zGtQJRqsZGdVqK7Z
> 6j3tIhepm0TTcVaMuBrqijuw0CFifMJwxV8T0uy0U8xEYbPzIyRqJCDsvHGhOUQw
> WN8PmGhnDKyOOQYSHEKGYEmTFvVlwqQ40SfH5hM3jMNF2zj/w/qPxl2pV2SMON9e
> 0sl8ew1Hu+DBM1u/+DJDe2dM1Jz3x1EnpjAJUFwLQ7MgZL4JuT4vD96y/Sl6s2eL
> LZeJieUi6fxW2dXDWABfBcIqyFpRx0Vh78XqC+ZyOn66RcGr3D9Yra8w+rCqLMc0
> 6owg9RHkzBZXsIpsG1DtZI+ytH0awLuXVv5zz4sGXIi9scQD64UCXxFf2xjdT08=
> =Iy9d
> -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