Re: [opensource-dev] STORM-243 - simulator version notifications
For the record: +1 for making it optional, with a debug setting default to off. The viewer has such wonderful instrumentation and debug facilities. Removing them in the name of "simplifying" is a big mistake in my opinion. On Tue, Jan 18, 2011 at 10:37 PM, Kent Quirk (Q Linden) wrote: > It's not gonna be a debug setting. The information's available to put it on a > HUD if you care. We're pulling the feature and simplifying the viewer. > > On Jan 18, 2011, at 4:35 PM, Liny Odell wrote: > >> Make that +2 for a debug setting >> >> On Tue, Jan 18, 2011 at 1:27 PM, Trilo Byte wrote: >>> +1 for making it a debug setting (to choose whether you see notifications). >>> >>> The server version info would still be available in Help -> About as well as >>> World -> Place Profile -> Region/Estate >>> On Jan 18, 2011, at 11:39 AM, Erin Mallory wrote: >>> >>> could even bury the option in the debug console... most people that would >>> need to turn it on would not likely keep flipping it I would think... >>> >>> >>> Date: Tue, 18 Jan 2011 11:32:53 -0800 >>> From: os...@lindenlab.com >>> To: opensource-dev@lists.secondlife.com >>> Subject: Re: [opensource-dev] STORM-243 - simulator version notifications >>> >>> It does have use for people testing server. I'd say make it optional, more >>> informative, and disabled by default. >>> >>> __Oskar >>> >>> On Tue, Jan 18, 2011 at 11:22 AM, Erin >>> Mallory wrote: >>> >>> to rephrase, yes I like them, thought i'd rather see them on the chat >>> history and have more detailed. but i can live without them if the majority >>> really want to see them gone altogether. for me it helps me during certain >>> testing and stuff to know when ive changed server versions but that's really >>> about it. >>> >>> >>> From: angel_of_crim...@hotmail.com >>> To: missannoto...@yahoo.com; q...@lindenlab.com; >>> opensource-dev@lists.secondlife.com >>> Date: Tue, 18 Jan 2011 12:04:09 -0500 >>> Subject: Re: [opensource-dev] STORM-243 - simulator version notifications >>> >>> I would also like to see the toast moved. it can be useful and would be >>> more useful if it had the actual version. but i would like to see it on the >>> chat history instead. in fact... it would be nice to have an option to have >>> ALL remaining system notifications be optionally shown in chat history >>> instead of as toasts. for one thing it would log better i think, for >>> another... well toasts bother a rather significant portion of sl. those >>> with some forms of epilepsy, migraines, some forms of add... to name a >>> few... >>> >>> Erin/aka Cummere >>> >>> >>> Date: Tue, 18 Jan 2011 08:35:01 -0800 >>> From: missannoto...@yahoo.com >>> To: q...@lindenlab.com; opensource-dev@lists.secondlife.com >>> Subject: Re: [opensource-dev] STORM-243 - simulator version notifications >>> >>> Doesn't it add some minor overhead to region crossings? I don't care about >>> it. The message does not say what server version you just entered so it is >>> mostly an annoyance. If I need version info I know where it is. >>> >>> What I would like to see is region rating and a single letter server version >>> code on the map without having to mouse float. >>> >>> >>> From: Kent Quirk (Q Linden) >>> >>> Hi, folks. I've just commented on STORM-243, which requests that we have Yet >>> Another Option to allow suppression of the toast that tells you the >>> simulator version changed when you changed to a new region. >>> >>> I think we should delete it entirely. Does anyone care to still get that >>> notification, now that there are usually 3 different simulator versions live >>> on the grid at any time? I don't mean "I can think of an obscure scenario >>> when someone might care." I mean does anyone really need a notification >>> about this, or can we just delete 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 >>> ___ Policies 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] STORM-243 - simulator version notifications
Making the server version notifications feature disabled by default, but keeping the option to enable it with more debug info in it accomplishes the both sides nicely. It doesn't confuse the casual user and it helps a pro make SL better. Removing stuff just for the sake of simplicity, without considering other criteria, is counter productive. You could remove "confusing" statistics panel (ctrl-shift-1) next? After all the "casual Second Life user" ¨must be mystified with it (and LSL can tell you time dilation just fine). How about all the fast timers/texture console, etc etc. Again, instrumentation of the viewer for debugging is one of its strengths. On Tue, Jan 18, 2011 at 10:58 PM, Sarah (Esbee) Kuehnle wrote: > The data is available via LSL - llGetEnv(). If you think about it, it makes > much more sense for this to be a HUD for Residents who are interested in the > information. For casual Second Life users, this information creates > additional notification pop-ups and create confusion for people who don't > know or care that the regions they enter are running different server > versions. > > This is not a feature belongs in the Viewer. If there's more data you want > out of llGetEnv(), I'd suggest filing an SVC feature request. > > --Esbee > > > On Tue, Jan 18, 2011 at 4:49 PM, Erin Mallory > wrote: >> >> I can live with that. I got much more important features /design issues to >> fight over. :) >> >> >> > From: q...@lindenlab.com >> > Date: Tue, 18 Jan 2011 16:37:34 -0500 >> > To: liny.od...@phoenixviewer.com >> > CC: opensource-dev@lists.secondlife.com >> > Subject: Re: [opensource-dev] STORM-243 - simulator version >> > notifications >> > >> > It's not gonna be a debug setting. The information's available to put it >> > on a HUD if you care. We're pulling the feature and simplifying the viewer. >> > >> > On Jan 18, 2011, at 4:35 PM, Liny Odell wrote: >> > >> > > Make that +2 for a debug setting >> > > >> > > On Tue, Jan 18, 2011 at 1:27 PM, Trilo Byte >> > > wrote: >> > >> +1 for making it a debug setting (to choose whether you see >> > >> notifications). >> > >> >> > >> The server version info would still be available in Help -> About as >> > >> well as >> > >> World -> Place Profile -> Region/Estate >> > >> On Jan 18, 2011, at 11:39 AM, Erin Mallory wrote: >> > >> >> > >> could even bury the option in the debug console... most people that >> > >> would >> > >> need to turn it on would not likely keep flipping it I would think... >> > >> >> > >> >> > >> Date: Tue, 18 Jan 2011 11:32:53 -0800 >> > >> From: os...@lindenlab.com >> > >> To: opensource-dev@lists.secondlife.com >> > >> Subject: Re: [opensource-dev] STORM-243 - simulator version >> > >> notifications >> > >> >> > >> It does have use for people testing server. I'd say make it optional, >> > >> more >> > >> informative, and disabled by default. >> > >> >> > >> __Oskar >> > >> >> > >> On Tue, Jan 18, 2011 at 11:22 AM, Erin >> > >> Mallory wrote: >> > >> >> > >> to rephrase, yes I like them, thought i'd rather see them on the chat >> > >> history and have more detailed. but i can live without them if the >> > >> majority >> > >> really want to see them gone altogether. for me it helps me during >> > >> certain >> > >> testing and stuff to know when ive changed server versions but that's >> > >> really >> > >> about it. >> > >> >> > >> >> > >> From: angel_of_crim...@hotmail.com >> > >> To: missannoto...@yahoo.com; q...@lindenlab.com; >> > >> opensource-dev@lists.secondlife.com >> > >> Date: Tue, 18 Jan 2011 12:04:09 -0500 >> > >> Subject: Re: [opensource-dev] STORM-243 - simulator version >> > >> notifications >> > >> >> > >> I would also like to see the toast moved. it can be useful and would >> > >> be >> > >> more useful if it had the actual version. but i would like to see it >> > >> on the >> > >> chat history instead. in fact... it would be nice to have an option >> > >> to have >> > >> ALL remaining system notifications be optionally shown in chat >> > >> history >> > >> instead of as toasts. for one thing it would log better i think, for >> > >> another... well toasts bother a rather significant portion of sl. >> > >> those >> > >> with some forms of epilepsy, migraines, some forms of add... to name >> > >> a >> > >> few... >> > >> >> > >> Erin/aka Cummere >> > >> >> > >> >> > >> Date: Tue, 18 Jan 2011 08:35:01 -0800 >> > >> From: missannoto...@yahoo.com >> > >> To: q...@lindenlab.com; opensource-dev@lists.secondlife.com >> > >> Subject: Re: [opensource-dev] STORM-243 - simulator version >> > >> notifications >> > >> >> > >> Doesn't it add some minor overhead to region crossings? I don't care >> > >> about >> > >> it. The message does not say what server version you just entered so >> > >> it is >> > >> mostly an annoyance. If I need version info I know where it is. >> > >> >> > >> What I would like to see is region rating and a s
Re: [opensource-dev] problems working with autobuild
The old style build didn't work in cygwin shell either. It wanted
cmake and python to be native windows versions. After deleting cygwin
versions of those, all worked. Perhaps a similar thing can help for
the autobuild?
On Tue, Feb 1, 2011 at 4:07 AM, Nicky Perian wrote:
> I can't tell but it looks like windows and you using cygwin, Is that
> correct?
> I was able to us the Visual Studio Command Prompt and all went as planned in
> documentation save one patch from Oz.
> Realize that isn't help. But, i didn't use cygwin and my Python was a
> seperate install in windows. Did not use the cygwin version of Python.
>
>
> From: Twisted Laws
> To: SLDEV
> Sent: Mon, January 31, 2011 8:43:01 PM
> Subject: [opensource-dev] problems working with autobuild
>
> So I figured I'd give the autobuild method of building a try. I've not
> made it far yet
> and wondering if someone might give me a pointer on what I've done wrong...
>
> I read: http://wiki.secondlife.com/wiki/Autobuild_Quick_Start
> and read:
> https://lists.secondlife.com/pipermail/opensource-dev/2011-January/005633.html
> v-autobuild is from: https://bitbucket.org/mani_linden/viewer-autobuild
>
> I must be missing something here but I'm not sure what. The autobuild/bin
> directory is
> in the path. Python 2.6 installed.
>
> Thanks for any hints, session log follows (note that the ./setup.py
> install fails, and i have
> to use python setup.py install)
>
> dir: /cygdrive/c/dev/hgbuilds
> $ cd autobuild
> dir: /cygdrive/c/dev/hgbuilds/autobuild
> $ ls
> autobuild bin build setup.py
> dir: /cygdrive/c/dev/hgbuilds/autobuild
> $ ./setup.py install
> ./setup.py: line 23: from: command not found
> ./setup.py: line 27: PACKAGE_NAME: command not found
> ./setup.py: line 28: LLAUTOBUILD_VERSION: command not found
> ./setup.py: line 29: LLAUTOBUILD_SOURCE: command not found
> ./setup.py: line 30: CLASSIFIERS: command not found
> ./setup.py: line 41: ext_modules: command not found
> ./setup.py: line 43: syntax error near unexpected token `newline'
> ./setup.py: line 43: `setup('
> dir: /cygdrive/c/dev/hgbuilds/autobuild
> $ python setup.py install
> running install
> running build
> running build_py
> running build_scripts
> running install_lib
> running install_scripts
> running install_egg_info
> Removing C:\Python26\Lib\site-packages\autobuild-0.0.0-py2.6.egg-info
> Writing C:\Python26\Lib\site-packages\autobuild-0.0.0-py2.6.egg-info
> dir: /cygdrive/c/dev/hgbuilds/autobuild
> $ cd ../v-autobuild
> dir: /cygdrive/c/dev/hgbuilds/v-autobuild
> $ autobuild configure -c OpenSourceRelWithDebInfo
> C:\cygwin\bin\python: can't open file
> '/cygdrive/c/dev/hgbuilds/autobuild/bin/autobuild': [Errno 2] No such file
> or directory
> dir: /cygdrive/c/dev/hgbuilds/v-autobuild
> $ ls -l /cygdrive/c/dev/hgbuilds/autobuild/bin/autobuild
> -rwxr-xr-x 1 John None 2213 Jan 31 20:37
> /cygdrive/c/dev/hgbuilds/autobuild/bin/autobuild
> dir: /cygdrive/c/dev/hgbuilds/v-autobuild
> $
>
>
> ___
> Policies 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] XMPP group chat questions
Hi, Since I plan to implement the new XMPP chat available for the clients that are not based on the official viewer, I could use some documentation about the way the new group chat system. Perhaps the best way to start would be with a few questions. Some of these have already been answered by Gez during Oz'es OH, but perhaps it would be beneficial to have them in one place. 1) To which xmpp server should we connect. I'm assuming there will be a new field in the xmlrpc login response specifying it? 2) Apart from the login reponse to find out to which xmpp server to connect to, would there be any other dependency on sims, like getting a CAP to give you authenticated username? (Similar CAP is used to obtain Vivox voice server credentials). 3) Assuming there are no additional dependencies on sims, will the same credentials (username/password) be used to authenticate to xmpp server as those to login to SL? 4) Is group chat implemented based on standard MUC (multi user chat) specification XP-0045? 5) Assuming MUC is used, how is the client supposed to construct addresses of the conferees it's supposed to join. (conference_n...@some.xmpps.host.com) 6) Will XMPP server be sending participant list that can be used in SL clients? We would need to know UUID of the participant in order to provide the functionality in the viewer, such us opening profiles, etc. (are we glad we have display names yet? :) 7) Is one of the design goals to allow pure xmpp clients to connect and participate in the group chat? 8) Proposed bridge between two group chat system for the transitional period, will it be sim <-> xmpp server or xmp server <-> legacy group chat backend Latif ___ Policies 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] XMPP group chat questions
Gez, Thank you very much for such a fast response. Just two small observations. Authentication takes it's sweet time, possible area to look into... And conference.chat.aditi.lindenlab.com doesn't currently resolve to anything (for those of us too impatient to wait for the project viewer :) Latif On Tue, Feb 1, 2011 at 8:30 PM, Gez Linden wrote: > Latif, > Thank you for summarizing your questions and jumping in on this so quickly. > My team just reviewed your questions and we have the following responses > for you: >> >> > 1) To which xmpp server should we connect. I'm assuming there will be >> > a new field in the xmlrpc login response specifying it? > > Yes. 'xmpp_host' will be on aditi soon, as its the only grid that will have > servers available initially. > >> >> > 2) Apart from the login reponse to find out to which xmpp server to >> > connect to, would there be any other dependency on sims, like getting >> > a CAP to give you authenticated username? (Similar CAP is used to >> > obtain Vivox voice server credentials). > > Nope >> >> > 3) Assuming there are no additional dependencies on sims, will the >> > same credentials (username/password) be used to authenticate to xmpp >> > server as those to login to SL? > > > The XMPP JID will be 'slid@chat.$grid.lindenlab.com', and password > same as SL password. Make sure to use SSL/TLS, as the SASL mechanism > is PLAIN. >> >> > 4) Is group chat implemented based on standard MUC (multi user chat) >> > specification XP-0045? > > Yes. >> >> > 5) Assuming MUC is used, how is the client supposed to construct >> > addresses of the conferees it's supposed to join. >> > (conference_n...@some.xmpps.host.com) > > For groups with only letters, numbers, and spaces, convert the spaces to '-' > and you are good to go (that's - (dash) not _ (underscore)) > The muc room jids will be > 'your-group-n...@conference.chat.aditi.lindenlab.com', where > your-group-name follows the munging convention. > We'll be posting the project viewer code that shows how we munge more > complex group names to build the conference names, and we'll document it on > the public wiki when we get closer to public release. >> >> > 6) Will XMPP server be sending participant list that can be used in SL >> > clients? We would need to know UUID of the participant in order to >> > provide the functionality in the viewer, such us opening profiles, >> > etc. (are we glad we have display names yet? :) > > > The XMPP server will provide a room roster, yes, but will not provide > UUIDs. For that, you'll need to connect to the People API via its sim > capabilities to look up the SLID-to-UUID mapping. We are looking into > how to provide a Display Name in the XMPP user information response, > but it's not clear yet if we'll do this and which fields will contain > that data if we do. >> >> > 7) Is one of the design goals to allow pure xmpp clients to connect >> > and participate in the group chat? > > Its a side benefit of our implementation rather than a design goal. We are > still working on the long term product plan for chat, and how we should > handle pure xmpp clients, so at the moment, its best to consider their > support experimental and subject to change. > >> >> > 8) Proposed bridge between two group chat system for the transitional >> > period, will it be sim <-> xmpp server or xmp server <-> legacy group >> > chat backend > > We have a few different ideas for how we're going to be supporting this. We > are performing a few investigative dives after we release the project viewer > to you guys, and we'll discuss transition strategy. > Thanks again for firing up this conversation. The team is excited to work > with you all on this and see us move to XMPP. > - Gez > ___ Policies 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] What is it with these Build Numbers?
Very informative page, thank you very much! On Fri, Feb 4, 2011 at 5:17 PM, CG Linden wrote: > "Everybody thinks Release Engineering is like a bikeshed, so people go on > happily slapping paint onto it, not realizing that there is a nuclear > missile silo underneath." > > Yes, this is one of those things... after all, how hard can it be to list > all the changes since the last release, or all the changes pending to go > into the current release? > > To learn more about how we use build numbers, and why the build results > occasionally had links to this "codeticket" thing, read: > http://wiki.secondlife.com/wiki/Codeticket_Service > -- > cg > > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] [server-beta] BlueSteel - Inventory loading time
I was implementing new inventory capabilities for libopenmetaverse/radegast and noticed the same slowdown compared with the old UDP method. I need to run about 8-10 concurrent http fetches in Radegast to be on par with the previous system. I don't know how taxing this is for the sim though. Latif On Mon, Apr 4, 2011 at 2:41 AM, Opensource Obscure wrote: > After reading a kind remark on the forums, I did some testing > about Inventory loading time on BlueSteel regions. I started > from BlueSteel Sandbox 1. Actually, on this region, Inventory > loads consistently very slowly. I did 4 tests in total there > over 1 hour. Region is completely empty and runs smoothly. > I tried other BlueSteel regions, and there Inventory loads > as fast as on the other releases - included the other three > sandboxes. So, in general, no apparent direct relation yet. > > > tl;dr usually 2', at least 5' on BlueSteel Sandbox 1 > > > Inventory = 18k items > > > Second Life RC BlueSteel 11.03.29.225233 > > http://maps.secondlife.com/secondlife/BlueSteel%20Sandbox%201/128/128/23 > 5' - 7' - 5'15" - 5' > > http://maps.secondlife.com/secondlife/Ambleside/161/95/30 > 2' > > http://maps.secondlife.com/secondlife/Hanley/153/167/95 > 2' > > http://maps.secondlife.com/secondlife/Oak%20Grove/182/163/13 > 1'50" > > http://maps.secondlife.com/secondlife/BlueSteel%20Sandbox%202/128/120/23 > 1'50" > > http://maps.secondlife.com/secondlife/BlueSteel%20Sandbox%203/131/123/23 > 2' > > http://maps.secondlife.com/secondlife/BlueSteel%20Sandbox%204/128/128/23 > 1'50" > > > Second Life Server 11.03.22.224783 > > http://maps.secondlife.com/secondlife/Frisch/160/70/38 > 2'40" - 2'15" > > http://maps.secondlife.com/secondlife/LOL/14/34/55 > 1'50" > > > Second Life RC Magnum 11.03.29.225234 > > http://maps.secondlife.com/secondlife/Deshima/118/130/2975 > 2'20" > > > > -- > Opensource Obscure > http://twitter.com/oobscure - http://opensourceobscure.com/lol > ___ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/server-beta > ___ Policies 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] Any possibility of playing animation b y uuid?
On Sun, Apr 17, 2011 at 6:39 PM, Brandon Husbands wrote: > We cal already play sounds, do textures why cant we play a animation by uuid > via lsl / viewer. Viewer cannot "play" anything by asset id (at least I haven't seen UI for such a feature). You probably meant LSL scripts, and that was a conscientious decision not to allow it. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Minimum draw distance
On Fri, Jun 10, 2011 at 10:49 AM, Jonathan Welch wrote: > A friend testing this found what might be considered a bug which none > of you advanced people would notice: when you click on the gear and am > sent to the preferences window you do not see the advanced section > with all the sliders for micro-adjustments unless at some point in the > past you had already expanded your graphics panel past just the > low-ultra slider. > > Is this something that should be forced? Just being sent to the > graphics page and only seeing a slider is not quite what I would > expect, though I can see both sides of this argument. I'd say keep it simple. They can open advanced on that panel they get sent to. The feature is very nice as is, I'd also like to see slider go down to 32. ___ Policies 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] Highlight Transparent Broken?
Transparency was broken for me when Fast Alpha was enabled somewhere in the debug menus. I don't know where the current location of that setting is. On Fri, Jun 24, 2011 at 6:17 AM, holydoughnuts wrote: > On 6/23/2011 5:31 AM, Jonathan Welch wrote: >> Could you also check glow (cts-644/cts-656) and windlight clouds >> (storm-1314) to see if either of those are non-functional for you? I >> have a feeling that some of these are related to each other. > Those are OK here. I have to disable them to make Ctrl-Alt-T work but > otherwise they're fine. > ___ > Policies 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] Review Request: STORM-1534: Derive Credits lists of contributors and translators from doc/ files
The about box contains a list of people who have contributed not only code changes but have participate in other aspects of SL viewer development such as QA. Are these contributions going to be deleted now? On Tue, Aug 2, 2011 at 11:38 PM, Kadah wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > The lists in app_settings/contributors.txt and > app_settings/translators.txt are not sorted or displayed alphabetically > (random order?), is this intentional? > > On 8/2/2011 10:40 AM, Oz Linden wrote: > > > > Description > > > > In the Help>About Second Life dialog, there are lists of users who have > contributed to the viewer and provided translations. Prior to this change, > those lists had to be updated manually (and had not been updated in quite > some time). > > > > Since we have a separate file (doc/contributions.txt) to track > contributions, and it is in an easily parseable format, this change modifies > the viewer build to construct a file (app_settings/contributors.txt) > containing those names, and another for the translators > (app_settings/translators.txt) from a new doc/translations.txt file (the > contents of which are not complete in this patch, but are sufficient for > review and testing purposes). > > > > I also removed the list of Lindens from the dialog, as it too had not > been updated in a long time and replaced it with a more generic statement. > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJOOG5XAAoJEIdLfPRu7qE2MNwIAIm+ueJzmaT4ht81vxZNPD/y > SLcv8v8uUn3Wju+GygNr6QpnrBYw4GcU4iOlGyDJkfhqFlEB8Sc21TLL7WAYwJG2 > x5lfxnMX/zt0jrjCbvjSNSHmxNH+KzYMtiAEC4P1NKYLG7upL0lZB7HJyO9wi6ev > 1aepcsySgMr5X+63jUyi3slx61FXoBHUCxgHUEOp06mJNQT1e7UseJwZVj1mkygo > ANroyJt41GF47kKelJBsT/rZtYfICFcz4Aasqxh0BGm57mxfqKZT9uaeRedE7bW/ > z1T6uRwKC1QYub15kpXNkAJEh3XDg5psesFiqG28T9JmFEOksoMY6d/+ljyQ25c= > =1xr7 > -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] Review Request: STORM-1534: Derive Credits lists of contributors and translators from doc/ files
I see, thanks for the clarification. On Wed, Aug 3, 2011 at 12:54 AM, Kadah wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Judging from the diff, it looks like they might have been merged in to > the doc/contributions.txt list. > > Hmmm, the random order was intended Why is that? *cross posts > question to jira* > > On 8/2/2011 3:44 PM, Latif Khalifa wrote: > > The about box contains a list of people who have contributed not only > > code changes but have participate in other aspects of SL viewer > > development such as QA. Are these contributions going to be deleted now? > > > > On Tue, Aug 2, 2011 at 11:38 PM, Kadah > <mailto:kadah.c...@gmail.com>> wrote: > > > > The lists in app_settings/contributors.txt and > > app_settings/translators.txt are not sorted or displayed alphabetically > > (random order?), is this intentional? > > > > On 8/2/2011 10:40 AM, Oz Linden wrote: > > > >> Description > > > >> In the Help>About Second Life dialog, there are lists of users who > > have contributed to the viewer and provided translations. Prior to > > this change, those lists had to be updated manually (and had not > > been updated in quite some time). > > > >> Since we have a separate file (doc/contributions.txt) to track > > contributions, and it is in an easily parseable format, this change > > modifies the viewer build to construct a file > > (app_settings/contributors.txt) containing those names, and another > > for the translators (app_settings/translators.txt) from a new > > doc/translations.txt file (the contents of which are not complete in > > this patch, but are sufficient for review and testing purposes). > > > >> I also removed the list of Lindens from the dialog, as it too had > > not been updated in a long time and replaced it with a more generic > > statement. > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJOOIAkAAoJEIdLfPRu7qE2OhAH/RD8gh5skBXWjOjUNHssTVj3 > T+JqcLh7kVjlfcz6uwWqbl7EH/g1HntFtLXp8FMk847NIgGWfDcz6QRnRXC0m1uu > lk+h7aoS2pBGEZfBPbAEZO6wbsL0LwCgdSNMdcmaw9J+P9HosM6o8aeLY32MDHeW > HVmzhg+lGlweQW8d5qJL1TCrTT6YLQk5zRJCvpWuJf4SlJOnGWXIjvKClC8iN1/z > /SnNnwD8V3VbYo/eLxuy0HJ1ByOVJY5Uyl6N+dO4qcyN2iyaq8xXKFMcLsUJAsBB > t86V2D7CkygquNDnbKTa3uyEZqb/GsNWfBLX13NbwnsijjrllTZMNGJG9rbH7NY= > =vBZT > -END PGP SIGNATURE- > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Inventory Patch you should integrate
On Tue, Jan 10, 2012 at 2:23 PM, Henri Beauchamp wrote: > On Sat, 7 Jan 2012 23:41:17 + (GMT), Hitomi Tiponi wrote: > >> Will a patch be provided for Viewer 1, > > Here is a patch that should apply to v1 viewers (you may perhaps get > rejects due to spacing changes, but they should be dead easy to work > around). Thank you very much Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Upcoming server side avatar baking
On Mon, Dec 17, 2012 at 10:18 PM, Oz Linden (Scott Lawrence) wrote: > I'm sure that there were any number of fundamental design decisions that > could have been made differently, but our purpose here is not to either > revisit those debates or to explain why we made the choices we did. The > fundamental design decisions have been made, and we're going to proceed > with the design we've got. People who don't fancy themselves to be the infallible gods of system design often find it beneficial to hear the feedback, especially in opensource projects. It might even lead to (gasp) more reliable system and better customer satisfaction. Whenever I relapse into using my time to help improve Linden Lab's products by doing testing, filing bug reports and repro cases, Oz Linden's attitude quickly convinces me that it's not worth it. (This email started as my feedback about some timing issue with network messages that could potentially cause bake fails, but then I saw all-knowing Oz dismiss any need for it) ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Upcoming server side avatar baking
On Fri, Jan 11, 2013 at 9:13 PM, Henri Beauchamp wrote: > Nevermind (though, having a propely built Linux Sunshine-viewer would > still be a good thing), I figured out the bug (race condition between > links creation in COF and rebake requests). How do you work around that? When I was implementing this in Radegast it seemed that the service would respond to link creation request and it would still sometimes fail with COF mismatch as if the baking service didn't get the message. > The of the Cool VL Viewer v1.26.7.5 (experimental branch) has been > released today with server-side baking support. Great! ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] DirectX SDK update: should we use it ?
No, Singularity is compiled with VS2010. Upgrading compiler version is PITA because it means that some (most?) prebuild libraries would need recompiling too. It's probably safe to ignore this warning as the viewer doesn't use D3D at all, and only functions used from DirectX are, as Liny pointed out, those used to get driver info. On Fri, Mar 1, 2013 at 7:30 PM, Niran wrote: > "Here, I bet the viewer won't compile under VS2012" > > Singularity is compiled with VS2012 if i remember correct > > 2013/3/1 Henri Beauchamp >> >> On Fri, 1 Mar 2013 08:54:00 -0800, Darien Caldwell wrote: >> >> > This is being offered to all Windows 7 Users, not just developers. >> > Reading >> > deeper here: >> > >> > http://msdn.microsoft.com/library/windows/apps/jj863687.aspx >> > >> > It's mostly backporting new features from Windows 8 to Windows 7. That's >> > why they say you'll need the newer SDK, to take advantage of those new >> > features. >> >> So can we safely apply this update and keep using the June 2010 DirectX >> SDK to build the viewer, and still get working builds on "all" (WinXP SP3 >> and newer) Windows versions ?... I doubt it, since they say: >> >> "If you are a Windows 7 DirectX developer who uses the June 2010 DirectX >> Software Development Kit (SDK), you will have to update your development >> environments after you install this platform update. The following >> development .dll files that are associated with the DirectX SDK are >> incompatible with this platform update: >> >> D3D10SDKLayers.dll >> D3D11SDKLayers.dll >> D3D10ref.dll >> D2D1debug.dll >> >> You can use one of the following applications or tools to update these >> .dll files: >> >> - The Windows 8 SDK: This SDK updates the current development >>environment with new headers, libs, and tools. This includes the >>previously-listed development .dll files. This update does not >>update the C or C++ compilers or the IDE, but this update does >>enable developers to integrate the new features of the platform >>update into their applications. >> " >> >> So, this solution implies that we also update the "Windows SDK for >> Windows 7 and .NET Framework 4" that is used to build the viewer with >> VS2010, with the "Windows 8 SDK": won't it break the viewer builds ?... >> Does it at all got a single chance to keep working with the VC++ 2010 >> compiler ? >> >> Second propsed solution: >> >> " >> - Microsoft Visual Studio 2012: This application includes the >>Windows 8 SDK, the Visual Studio 2012 IDE, and the new compilers. >>.../... >> " >> >> Here, I bet the viewer won't compile under VS2012, and I heard that >> anything compiled with compilers newer than VS2010 is incompatible >> with Windows XP... >> >> Third propose solution: >> >> " >> - Remote Tools for Visual Studio 2012: These tools are the minimum >> requirement in order to continue using the Direct3D debug layer. >> These tools update only the previously-listed development .dll files. >> These tools do not enable developers to integrate the new features of >> the platform update into their applications. These tools are available >> in the "Remote Tools for Visual Studio 2012" section of the Visual >> Studio Download Center, or can be downloaded from the following >> links. These packages can be safely installed on development systems: >> " >> >> Is it the right thing to do ?... I don't know. Any clue ? >> >> > Basically it's all centered around D3D11, which I really doubt LL's >> > viewer is using. .../... Of course I'm not exactly sure what parts >> > of D3D the viewer is using, I was always under the impression it used >> > OpenGL. >> >> OpenGL is used for the rendering. D3D is only used for the graphics >> card detection at startup... So if someone could find a way to use >> another detection mechanism, we could get fully rid of the D3D calls >> in the viewer code. >> >> Henri. >> ___ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Building the current development viewer with FMODEX?
You will have to build it yourself. 3p-fmodex build scripts can be found at: https://bitbucket.org/LightDrake/3p-fmodex On Sat, Apr 20, 2013 at 11:08 AM, Lance Corrimal wrote: > Hi, > > > how/where do I get a 3p-fmodex package to build the current development viewer > with? > > > cheers, > 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] Debugging purging a single folder from trash
On Mon, Oct 5, 2015 at 10:40 AM, Henri Beauchamp > I don't know what you are trying to debug, but just in case, be aware > that at least one such "derivatives", in use on OSGrid, does not obey > the purge trash messages sent by the viewer (it looks like the trash > gets emptied, but on relog, the purged items will reappear in it): > it's totally weird and IMO a pure non-sense but in OSGrid, if you want > to purge your trash, you must login into their web site and purge it > from there... > I myself lost quite some time (G !) trying to figure out why I > couldn't purge my trash (and searched pointlessly for a bug in my > viewer), till I found out this totally quirky (and unique: I didn't > encounter it on any other grid) "feature" of OSGrid. > >> and just noticed that it seems that >> there's a difference in the calls when the folder being purged has children >> and when it doesn't. Trying to confirm that there is an actual difference >> or if something else in this complex system is interacting... It's not nonsense, it's a security measure. In SL sims are trusted so they proxy all the communication from the viewer to the central services such as inventory and assets. On OSGrid anyone can attach their own sim. This sim could tell the inventory service "User XYZ just emptied the trash", which in practice means everyone with a modified sim code could empty your Trash and Lost & Found. This is why those operations were disabled on OSGrid, and work just fine on more controlled grids. ___ Policies 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] Debugging purging a single folder from trash
On Mon, Oct 5, 2015 at 4:59 PM, Henri Beauchamp > So, instead of securing the communications (simply check that the user > is actually logged into the requesting sim, or use AISv3 instead of > UDP messages), you prefer breaking a protocol (not even documenting > the change anywhere, and not warning the TPV developpers you did it)... > > Non-sense (again) ! AISv3 is new. There is no "upstream" to port from (like viewer devs do). Also this restriction is on one grid only. Join #opensim-dev on freenode if you want to ask people about current limitations of OpenSim. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
People seem to be confusing two different things: client side scripting, and client extensions or plugins. 1. Client side scripting Think web browsers. They all support execution of client side scripts in one language in sandboxed environment. So the way original post describes proposed design for client side scripting fits neatly in this scenario. Having a unified platform that scripts can depend on existing in the client (say viewer 2.3 and up support it) would allow all sort of new and innovative content to be created. 2. Plugins Think Firefox extensions/plugins. Like Flash, Java applets, etc. This is entirely different concept. In-world content cannot depend on these being present, and have to allow for situation where some users have some plugins installed, while other do not. Both of these concepts would be a welcome addition to the viewer. I would imagine that the needed internal changes to the viewer could be, at least partially, used for implementation of both. If the first step is to implement client side scripting as described above, we should be talking about it, and separate plugin discussion into a different thread. ___ Policies 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
It also means that now I need to hire a lawyer in order to continue to make and distribute my text viewer (Radegast), with special features aimed at people with disabilities. The terms mandate that I need to have an official privacy policy published, and I also need to to show SL ToS to users (and I have no idea where would I get it, and how to tell if it's updated). "Shared experience" clause doesn't even deserve spending time on it. On Tue, Feb 23, 2010 at 9:16 PM, Gigs wrote: > http://secondlife.com/corporate/tpv.php > > You all realize this is massively incompatible with the GPL, right? > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Third party viewer policy
On Thu, Feb 25, 2010 at 1:12 AM, Soft Linden wrote: > Legal doesn't intend this to be a restriction on anything but use of > our service or eligibility for inclusion in the Viewer Directory. > Context is important here. Even the maintainers of GNU telnet won't > let someone use telnet to mess up the FSF's servers. Soft, nobody is disputing the parts of the policy that are designed to prevent malicious software that causes harm to the servers it connects to, or to user data or privacy. But I fail to see how that relates to the topics that have been raised in this thread. How does calling an API and a client "Restrained Life Viewer" become a violation? Is anyone honestly going to confuse "Second Life" with "Restrained Life Viewer" or to claim that it can be seen as trademark infringement? RLV has created a whole industry which I'd argue has helped Linden Lab's business. It has also transcended it's original purpose, as it is being widely used by people with disabilities. I have been working closely with the blind users of Second Life, and have seen some really amazing in world scripted devices that help the blind users overcome poor accessibility of the official client. It's Linden Lab's treatment of open source developers like that which is causing concern, not it's efforts at preventing harmful software from disrupting the grid. ___ Policies 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
Hi Soft, I'm very pleased too see that some of our biggest concerns were taken into account. For me especially the FAQ states that provision 1.h about "shared experience" is going to be removed, as it would be impossible to bring Radegast into compliance with the policy if that clause were to stay in it. Kudos! Latif On Sat, Feb 27, 2010 at 4:14 AM, Soft Linden wrote: > There's now a FAQ for the Linden Lab Policy on Third Party Viewers: > http://bit.ly/caedse > > This addresses many of the questions and concerns made in > opensource-dev and elsewhere. An updated version of the TPV doc itself > is also coming, but expect this within a couple weeks. Go visit the > FAQ, or read on for the TPV doc update details... > > I know that the member of the legal team who owns the policy doc is > still working over the final version. Linden Lab has approached > outside legal experts with your feedback, and one of these experts is > a lawyer who specializes in open source license compliance issues. > Based on these experts' feedback and further internal review, our > legal department will incorporate any required changes. > > In the meantime, while it helps to start making changes now, parts of > the policy are not yet in effect. See the tail of the FAQ for dates > and the portions affected. > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] FAQ posted for Third Party Viewer Policy
Joe, While we're on the subject of clarifying the text of the policy, I have a question regarding 1. g). Is it really necessary to mandate a version number be presented on the login screen? Or is that wording just assuming every third party viewer is based on Linden GPLed client code? Latif ___ Policies 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 Permissions Management
On Sat, Mar 6, 2010 at 1:17 PM, Boroondas Gupte wrote: > Rob Nelson schrieb: >> Consider a user in a sandbox who wants to clean up his mess. If he were >> using a viewer based on LibOMV, all the viewer would have to do is loop >> through the region's object dictionary and return/delete objects that he >> owns. > How does LibOMV obtain/build that dictionary LibOMV keeps track of all object updates and object kills that come from the sim, and keeps the most current list of prims in a per-sim dictionary. So it's not a dictionary of all prims in a region, rather of those that sim sends (based on its interest list, settings of your "draw distance", etc). ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Media capabilities hidden to TPV?
I'm trying to implement the new MoaP capabilities in my text viewer Radegast. However the two new CAPs, ObjectMedia and ObjectMediaNavigate are not granted by the seed capability of the simulator. Is the login server disabling those capabilities based on a version string sent? Latif ___ Policies 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] Media capabilities hidden to TPV?
My apologizes, turns out the problem was entirely between my keyboard and my chair. On Sun, Mar 7, 2010 at 7:52 PM, Latif Khalifa wrote: > I'm trying to implement the new MoaP capabilities in my text viewer > Radegast. However the two new CAPs, ObjectMedia and > ObjectMediaNavigate are not granted by the seed capability of the > simulator. > > Is the login server disabling those capabilities based on a version string > sent? > > Latif > ___ Policies 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
On Wed, Mar 10, 2010 at 6:18 PM, Maggie Leber (sl: Maggie Darwin) wrote: > On Wed, Mar 10, 2010 at 12:03 PM, Tigro Spottystripes > wrote: >> sim owners can already control the Sun position in your client, the rest >> of the WL parameters is just an extensions of that > > That's a pretty feeble application of a slippery slope argument. > >> there should be a way to set your client to ifnore sim settings if you >> want to though > > There is: it's called declining to grant permission for you to shove > your settings down the throat of my viewer. You can already override environmental settings. Option to set to region default should do just that, apply region default settings. Nobody is showing anything down your throat lol. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Request for comments about llSetAgentEnvironment / SVC-5520
On Wed, Mar 10, 2010 at 6:30 PM, Maggie Leber (sl: Maggie Darwin) wrote: > On Wed, Mar 10, 2010 at 12:23 PM, Latif Khalifa > wrote: > >> You can already override environmental settings. Option to set to >> region default should do just that, apply region default settings. >> Nobody is showing anything down your throat lol. > > So it wouldn't take effect if I'm not running the Windlight "default" set? > > That's not currently a "region default", by the way. Notice that > "Revert to region default" applies only to sun position. I'm talking about implementation of http://jira.secondlife.com/browse/VWR-7677 not the LSL script setting environment. Yes, the region setting would be shown by default, because otherwise it wouldn't make any sense. Asking for permissions for stuff like setting light and sky settings makes as much sense as asking for permission to show a house in your viewer once you have entered a region. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Request for comments about llSetAgentEnvironment / SVC-5520
On Wed, Mar 10, 2010 at 6:42 PM, Kelly Linden wrote: > I do believe the > environment should be promoted to being part of the content and not part of > the viewer, I think we get more amazing in world experiences that way. I fully agree. One of the often heard remarks that I hear from users is how despite how big Second Life is, it's pretty uniform in the way it looks all over the place. I think implementing region windlight setting would give us much more varied experience and some truly awesome builds no doubt. The sad part is that when windlight was introduced, all the hard work was done in the viewer, and region setting were said to be coming soon. Compared to what had to be done to introduce windlight, adding the ability to store it persistently in regions settings should be trivial. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Request for comments about llSetAgentEnvironment / SVC-5520
On Wed, Mar 10, 2010 at 7:05 PM, Maggie Leber (sl: Maggie Darwin) wrote: > I can just imagine a new use for all those tiny little ex-adfarm > parcels along mainland roads: noob traps that force a blinding > Windlight set on the unwary. Don't let what the actual "Estate / Sim Windlight preset / day cycle options" VWR-7677 proposal says stay in way of you inventing fictional problems. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Backport of Tattoo and Alpha support to v1.23 ?
On Wed, Mar 10, 2010 at 11:35 PM, Henri Beauchamp wrote: > I found what was wrong in my patch. The new code now works properly, but > for a cosmetic glitch (avatar not being rebaked while in customize > appearance mode when changing an Alpha wearable) which I'm trying to > address. > > You can expect the next release of the Cool SL Viewer (http://sldev.free.fr/) > to include full Tattoo and Alpha wearables support... ;-) This is awesome news indeed Henri :) ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Snowglobe 2.0^H^H^H1.3 way forward?
On Fri, Mar 12, 2010 at 11:33 PM, Soft Linden wrote: > Some things will happen in the dark, but the current plan is *not* to > do another monolithic Viewer 2 quiet cycle. We want to get > intermittent code dropping regularly again - expect to hear more on > that soon. Once that's covered, I know some teams are actively > campaigning to get their source out regularly again, and that the > graphics guys are in that camp. The company might think other features > are better held. I don't know all the reasons there, but I can see > where some early announcements haven't helped anyone. AO was one good > example. Look back on the amount of damaging FUD about AO and LL, as > well as the constant harassment of Lindens before it was finalized, > and then look at its real impact on resis' daily lives...? One could > write a book on that gap. I'd bet that kind of response is going to be > raised as a counterpoint to open development* at the Lab for years. Soft, while I agree that there has been a lot of FUD and trolling recently on opensource-dev, and that we could all use more constructive attitude, I think that you picked a very bad example for a bad experiences LL had with open development model. First of all the Adult Content changes (lets called them AC not to confuse it with animation overriders) had very little to to with actual development, and everything to do with the policy. There was no FUD or harassment of Lindens based on something that was SVN synced in the public repository. And that policy change had to be pre-announced anyway to get people ready to be moved from their parcels on the mainland etc. It could not have been done from one day to the next in any case. I'll not go into the details of AC policy's impact on residents, that's a whole different discussion (for me and my friends, the impact was big). Moving forward, I can see a lot of encouraging signs. Merov doing the necessary work to get the external SVN sync working again. We can all look forward to interesting and amazing new viewer mashups, such as that Kirsten provided combining render pipeline (shadow) branch with snowglobe and others. At least that part of confusion and misunderstanding is over. What would be particularly beneficial for LL if there was some sort of mechanism for merging SG patches back to the main viewer trunk. That way you get the benefits of excellent work OS devs have put into fixing bugs in SG. Plus you encourage the OS devs to provide even more great work (I know many of them felt disappointed to see that you could crash viewer2 in many ways that were fixed in SG). I'm hoping that we get robla's replacement soon, who could facilitate such two-way and mutually beneficial flow of fixes and new 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
Re: [opensource-dev] Snowglobe Mecurial Repository
On Fri, Mar 19, 2010 at 12:58 AM, Dzonatas Sol wrote: [snip] > At the Open Source meet today, it appears we have a light at the end of > To help quicken the merges and to save the history of them, we need > volunteers on to help with the hg repository. The snowglobe-1.x branches > can migrate over the hg on bitbucket.org. I think you misunderstood what was said. The people who could eventually be helping Merov with changes are those that are already committers to snowglobe. Also the oss-viewer and snowglobe branches are in the public linden svn. ___ Policies 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] Wiki posting: Open Source Repository Strategy
On Mon, Mar 22, 2010 at 4:38 AM, Kent Quirk (Q Linden) wrote: > Hi, all. I've created a draft of our repository strategy for how we will be > handling open development branches at LL, and posted an annotated diagram on > the wiki. > > https://wiki.secondlife.com/wiki/Linden_Lab_Repository_Strategy > > Questions and constructive commentary are encouraged. Since it's policy we > intend to follow, please edit only for clarity. If it needs substantive > tweaking, please let us do it. Hello Q, It would help me better understand this process if I put some version numbers on it (as of this moment). viewer-public branch is the current 2.0 viewer, viewer-release (if it exists atm) would be 2.1 and viewer-private features that are going to be added in 2.2 and beyond. Please correct me if my understanding is correct. Also, I think that we would need more than a single viewer-external branch in the public svn. There should probably be branching of viewer-external to viewer_2_0 just before we export viewer-public to viewer-external at the point M on the diagram. Latif ___ Policies 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
While I understand the motivation behind the TPV policy, there are still issues with it that go beyond it's the stated goals. The problems range from silly micromanagement (section 1.g mandates where to put your viewer version numbers), to far more serious issues in section 7. Again, I do understand that Linden Lab does not want to be liable for the behavior of a TPV, but as any software maker in the world, the Linden ToS (see ToS section 5.5 and 5.6) disclaims liability to any damages the regular stock viewer might cause to users computer. Now contrast that to TPV policy section 7, specifically 1.a and 1.d. "If you are a Developer, you are responsible for all features, functionality, code, and content of Third-Party Viewers that you develop or distribute." I, as a developer of one such 3rd party client feel that it is unfair to be subjected to harsher conditions that Linden devs themselves. I guess a lot of sentiment in this thread stems from similar feelings. I'm still hoping that it will be possible to change section 7 of the policy to say what its intent probably was "LL shall not be held responsible if your kitten dies as a result of using TPV", and avoid overzealous language that puts legal burden squarely on the shoulders of TPV devs. ___ Policies 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
On Mon, Mar 22, 2010 at 6:47 AM, Latif Khalifa wrote: > Now contrast that to TPV policy section 7, specifically 1.a and 1.d. There is a type in that line, I meant 7.a and 7.d. ___ Policies 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 Development project: extending avatar wearables
On Mon, Mar 22, 2010 at 6:45 PM, Nyx Linden wrote: > Greetings Opensource-dev! [snip] > Some of the features we want to implement: > 1) A new panel to edit what is stored in your saved outfit without > creating a new one. > This will include both an inventory view and a view of your outfit > itself, so you can drag items from your inventory to your outfit without > having an extra floater open > 2) Editing of wearable items (body parts and/or clothing objects) in the > sidebar, selectable from the outfit editor > 3) Removal of the appearance floater > 4) Order-specific outfits with the ability to re-order wearables as desired > 5) Ability to wear multiple wearables of the same type (multiple shirts, > multiple jackets and yes, multiple alpha masks!). Awesome set of features! My suggestion would be to create a Jira (or a Wiki page) with the proposed look of the new appearance manager functions, and post pictures with interface mockups, and encourage people to come up with their own suggestions for improvements in form of interface mockups. Latif ___ Policies 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 Development project: extendingavatar wearables
On Thu, Mar 25, 2010 at 7:55 PM, Nyx Linden wrote: [snip] > As I stated previously, I'm not completely stuck on the current > structure, its just one that I know I can finish and ship in the given > timeframe. I can think of ways to re-re-architect the structure yet > again to enable this requested functionality, but I'm not convinced to > do so because: > > 1) The ultimate user interface becomes less intuitive (I'll go into more > depth on this later) > 2) We simply do not currently have the time to re-architect and test the > new structure yet again. [snip] I think getting ability to wear arbitrary number of same type clothing will solve 99% of the problems, and since it is a features that can be done in a reasonable time frame, I agree that we should focus on getting it out as the priority. You can always make superhero underwear on the pants layer after all :P Latif ___ Policies 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 Development project: extendingavatarwearables
Not to mention that some span over more than one bake, like jacket, tattoo and alpha. I don't think changing wearable type is feasible. On Thu, Mar 25, 2010 at 9:44 PM, Nyx Linden wrote: > I'd argue that's an insufficient solution. Parameters such as sleeve > length and color have fairly dramatic impacts on how a wearable appears. > Converting only the textures would result in a fairly disappointing > result, I think. > > -Nyx > > Argent Stonecutter wrote: >> >> On 2010-03-25, at 15:07, Nyx Linden wrote: >> >>> Interesting proposal, and one probably worthy of further investigation. >>> My concern with this plan is that the conversion from one wearable type >>> to another is very much non-trivial. The wearable parameters (sleeve >>> length, etc) have no relation to each other between wearables. For >>> example, "sleeve length" for undershirts is visual parameter #603, which >>> "drives" parameters 1042 and 1043. For shirts, it is parameter #800 >>> which "drives" 600, 1013, 1029, and 900. >> >> Using my idea of making a non-volatile change to wearable type... >> >> Change parameters back to default when you change wearable type? No >> weirder than changing body type male to female. >> > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Snowglobe 2.0 sync with Viewer 2.0
Hi, On windows it fails with: CMake Error at media_plugins/webkit/CMakeLists.txt:17 (include): include could not find load file: PulseAudio When I kill PulseAudio from cmake it fails with: CMake Error in newview/CMakeLists.txt: Cannot find source file "llpopupview.cpp". Tried extensions .c .C .c++ .cc -- Latif On Sat, Apr 3, 2010 at 5:26 AM, Philippe (Merov) Bossut wrote: > Hi, > > After much wrangling today and yesterday, I finally committed a massive > commit syncing the SG2.0 trunk to viewer-external which is itself synced > with Viewer 2.0: > - Trac: http://svn.secondlife.com/trac/linden/changeset/3303 > - Log: Merging of viewer-external from svn rev 3287 up to svn rev 3302 - > Synced with official Viewer 2.0 then. Built and tested on Windows only! > > The build script have been failing for reasons I haven't investigated yet. > I'll be working on that aspect first thing Monday morning. > > Cheers, > - Merov > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Requesting Linden Response: Please move TPVPTopics to a different mailing list
On Thu, Apr 15, 2010 at 9:38 PM, VR Hacks wrote: [snip] > B) Any developer who develops and/or distributes their viewer is > "responsible" (please note the operative word, responsible) for whatever > code they've implemented. In other words, it is up to them to a) debug their > own code, b) write their own EULA, and c) define & implement a user support > model. Should they choose to do none of the above, that is their choice, as > well. > > Otherwise put, responsible and smart coders will *always* include a EULA > with their binary distribution (regardless of whether or not it was designed > to connect to the grid). Why? Because it sets end user expectation. It > ensures you, as devs, will not end up in a infinite "support for free" loop, > and importantly, it provides legal protection should your code have a bug > that you did not catch. A smart coder would read the policy himself/herself, and base their decision based on their own understanding of it, not on an interpretation of some random person on a mailing list who has no stake in the matter whatsoever. Latif ___ Policies 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] --loginuri command line option disabled in viewer2 final?
Hello, I'm having problems specifying alternative login url with --loginuri command line option. It work up to "final" viewer2 release, through all the betas, but it seem to be not working in the final release, and in the later snowglobe builds. Latif ___ Policies 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] Quiet amendments of TPV (again)
I second that Gigs, very positive changes indeed. My thanks to Joe for making this happen. Latif On Tue, Apr 20, 2010 at 4:10 PM, Gigs wrote: > These look like positive changes that address some of the concerns. > > Thank you for your efforts Joe. > > Joe Linden wrote: >> Boy, >> >> There was nothing quiet, or "in the background" about it, believe me. >> This update is the topic of conversation at the noon PDT brown bag I'm >> hosting today. The changes were pushed live ahead of the meeting, so >> there would be no question they are incorporated in to the TPV and TOS, >> both of which are effective on 4/30. >> >> I'll see those of you still interested in the subject at noon here: >> http://maps.secondlife.com/secondlife/Linden%20Estate%20Services/229/230/29 >> >> -- 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
Re: [opensource-dev] Where has "Spare time" gone in 2.0 ?
My guess is that this is a simple oversight when porting over to viewer 2.0 ui infrastructure. Latif On Sun, Apr 25, 2010 at 8:38 AM, Marine Kelley wrote: > 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 > ___ Policies 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
On Wed, Apr 28, 2010 at 11:57 PM, Henri Beauchamp wrote: > In fact, it probably comes from the fact that Linden Lab uses contradictory > phrases in the TPV policy and in the TPV directory. > > Quoting the former: > > "Unlike the other sections of this Policy, participation in the Viewer > Directory is currently not a requirement for connecting to Second Life." > > And quoting the latter: > > "Beware of third-party viewers that are not in the Viewer Directory – they > have either declined to self-certify or been refused for noncompliance > with our policies." > > So, registering to the directory is clearly not a requirement to be > considered as TPV-policy compliant, but on the other hand LL suggests that > the viewers which are not in the directory are "dangerous" ones... > This is both unfair and very close to pure diffamation. I agree that this is very unfortunate wording on part of Linden Lab. I have got a lot of concerned emails and some comments on the site[1] "will I be banned if I continue to use Radegast" due to that "beware" sentence on the directory page. Some of the emails I got were almost panicky. I hope the wording can be changed in order not to cause panic and uncertainty among TPV users. Latif [1] - http://radegastclient.org/wp/2010/04/radegast-1-16-released/#comments ___ Policies 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] Making progress compiling the viewer, but still having some issues
On Sat, May 1, 2010 at 2:20 PM, Henri Beauchamp wrote: > On Sat, 1 May 2010 06:55:48 -0400, Jonathan Welch wrote: > >> I was thrilled to see the viewer to start to compile more or less a >> little while ago but have >> hit another stumbling block. >> >> I'm trying to compile SG 1.4 on Win XP using VC 2005 Express Edition / VC80 >> >> 1) Now I'm getting a lot of lines like this >> 26>apr-1.lib(time.obj) : warning LNK4099: PDB 'apr-1_ib_5.pdb' was not >> found with '..\..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or >> at >> 'E:\sg14\linden\indra\build-vc80\media_plugins\gstreamer010\RelWithDebInfo\apr-1_ib_5.pdb'; >> linking object as if no debug info >> >> python shows the apr suite is installed, so do I ignore this error or >> fix it somehow? > > This is not an error, just a warning... It should not pose problem if you > compile for "Release" (and not for "Debug" or "RelWithDebInfo"). > If you do need debug info, then you also may try to configure the project > so not to treat warnings as errors and you should get past this kind of > warnings. Windows build does ignore linker warnings, so you can safely ignore "warning LNK" messages. Latif ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Migrating open development focus to 2.x
On Thu, May 27, 2010 at 11:50 PM, Oz Linden (Scott Lawrence) wrote: > It's fairly clear that Linden Lab doesn't have the resources to devote > to active work on both Snowglobe 1.x and 2.x, and it's not efficient for > the community as a whole to be splitting effort. Snowglobe is an opensource project. Sure Linden Lab can decide not to do anything about 1.x (not that it has done much about it in the past year or so anyway), but you cannot tell the outside contributors what they want to focus on. And most of them still want to improve on SG 1.x. > I'd like to fairly quickly get to the point where all our new work is > happening on the 2.x branch. That said, I understand that might leave > behind things that the Snowglobe user/dev base wants and that some > people are not happy with some elements of 2.x. What I'd like to know > is... what needs to happen to make that choice that most people can be > happy with? I'm afraid this is not going to be very easy Oz. It's not likely that a lot of new development is going to go to 2.0 since a lot of people find the UI much more difficult to use. And Linden Lab has in the past few months since the introduction of the new UI only be willing to do minor tweaks to it, nothing of substance. See the JIRA's and mailing list threads about chat bar focus where the response from the head of the viewer team was basically "no can do", complain all you want but that's not changing. With attitude like that from LL the response is not surprising, OK, no we cannot move to 2.0 with such an inflexible approach to fixing most glaring UI issues. > One of my goals is to increase the rate and volume at which Linden Lab > can (and _does_) take changes from the open source base into the > internal code, but unless we can keep everyone on the same branch, that > will be much more difficult. This would be good indeed. It was very sad to see that almost none of bugs that were fixed in SG 1.x tree were taken upstream. Viewer 2.0 was released choke full of bugs (including crashers that could lead to potential exploits) that were fixed moths and months before in the public SG repository. > Please respond to this thread with your favorite reasons not to move > development to 2.x. We will review the list at the 6 June open source > meeting with the goal of setting some priorities. It's UI, the UI and more of UI. While the 2.0 at the first glance looks nice and modern compared to 1.x it's usability is far worse. 1.x UI could be skinned to look much more modern and many TPV already do this. >From what I have seen building from viewer-external branch so far, 2.1 is going to bring only tiny cosmetic changes without addressing the real problems of the UI's usability. SL is a 3d virtual world. 2.0 UI with it's non transparent floaters, inability to dock local chat history with other ongoing conversations, obscures much of the world, making it into a facebook page with a glimpse of something 3d behind it. Local chat changes from 1.x to 2.x also show this facebook fixation of 2.0 design, moved from functional, usable display to something resembling facebook or twitter updates. Try an experiment for yourself, go to a busy club with a lot of chat in 1.x and 2.0 and see the difference. If you get a couple of IM conversation goings + busy local chat, there is hardly any world left to see. Local chat input field is too small even for facebook or twitter style updates. 2.1 makes this even worse by trying to jam more buttons on the same line, so you get chat input, buttons, IM conversation items and notification counts all on one line. Chat is a clear loser there, but guess what, a lot of people come to SL to socialize and talk to each other, so de-emphasizing chat like that isn't going to improve the user experience. At the same time, we have this huge and mostly empty address bar, so the message seem to be, let's make it look like a web browser and heck with usability. Also. the changes of focus handling for local chat between the the two versions show that the designers of 2.0 have never actually used SL for socializing, otherwise they would notice that people start jumping around and doing other weird things because they thought input focus was on the chat line. Inability to open more than one user profile, or to look at a user and group profile at the same time is also very limiting, and makes some common tasks much more difficult. Just compare the list of user groups and the task of opening them and discovering what they're about between the two versions. This is how people discover things about Second Life, open people's profiles, look at their groups, their picks, and go visit those locations. The modal nature of 2.0 interface makes this painful.-> Compare how to do common things, "how do i upload picture of my cat" and share it with friends. In 1.0, it's file -> upload -> image. In 2.0 you have to figure out how to open inventory and that there is a menu in there that allows you to uplo
Re: [opensource-dev] viewer-external update
Hi Merov, Thanks for the heads up. I think having both viewer-public and viewer-release available externally is the right way to go, good call. We'll probably want to have hotfix branches too. I imagine 2.1.0 2.1.1 etc will be coming out of a viewer-2.1-hotfix or some such. Latif On Sat, Jun 12, 2010 at 2:42 AM, Philippe (Merov) Bossut wrote: > Hi, > > If you're following @sldev-commit, you've seen a huge commit today being a > 2.0.2 update. There's a new one coming marked 2.1 with more code (parabuild > in progress before export). The whole code should be available shortly. > > However, there are issues with that branch: viewer-public contains code > newer than viewer-release and the resulting executable is, today, very > unstable. I've been crashing on Mac as soon as I login. I would not > recommend using that code base for your casual build/test. Pull that code > *only* if you're curious about the code of the new features (voice morphing > for instance). > > viewer-public will certainly be beaten back into shape in the new few days > by the viewer team (most of them working in viewer-public) and > viewer-external will follow suit at the next daily sync, as always. > > This suboptimal state of affair underlines a problem that we need to solve: > there is enough new development happening in viewer-public that this branch > can be at time unreliable. Similar unstabilities were was the reason why we > decided for instance to pause syncing Snowglobe 2.0 with viewer-external, > waiting for a complete Snowglobe 2.0 to be released. > > For new releases though (like 2.1 beta 0), this is really annoying as it > sorts of create a blur between releases and workable FLOSS code. > > As a consequence, we decided to create a clean export of that branch in a > separate svn repo. We will in the future do a similar export for all viewer > releases. > > I've been working on this today and hope to get something cleanly exported > within the next few days. > > Cheers, > - Merov > > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] viewer-external update
Hi, It builds fine on windows but it does not run. I get ""Could not start address resolution system" dialog on startup. After clicking OK, the viewer exits. Thank to Kirsten Lee the workaround of switching back to ares 1.6 makes it work again on windows. Latif On Wed, Jun 16, 2010 at 7:19 AM, Philippe (Merov) Bossut wrote: > Hi, > > I'm glad to report that export to viewer-external is fixed. Svn rev 3417 > contains all the 2.1 code and newest viewer-public development. The Mac > build at least works without crashing so it seems safe again to svn update > and check. > > Sorry for the disruption and thanks for your patience. > > Cheers, > - Merov > > > On Mon, Jun 14, 2010 at 10:01 PM, Philippe (Merov) Bossut > wrote: >> >> Hi, >> >> Update on viewer-external: the last 2 "hg pull" from viewer-public keep >> failing when building on all platforms and, therefore, do not get to the >> export stage (we export only if builds pass). >> >> I think I identified the culprit: a bunch of new files and dependencies >> added for crash tracking. >> >> I'll be working with Lindens to determine what to do with those files and >> dependencies with respect to FLOSS. >> >> Thanks for your patience. >> >> Cheers, >> - Merov > > > ___ > Policies 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
I just tried building viewer-external on my windows 7 - 64, had no linking issues that you reported. (I also have pretty old library for stuff like fmod, but those are not changed anyway). Latif On Fri, Jun 25, 2010 at 11:30 PM, Marine Kelley wrote: > 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 > ___ Policies 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
On Tue, Aug 17, 2010 at 4:27 AM, Yoz Grahame wrote: > > The Snowstorm project is aimed at dramatically increasing community > involvement in Viewer development and improving communications around it. Very nice words indeed. But not new. Shall we look into what happens when user experience clashes with, in my view, a very short sighted decision by one of the "product owners". Is it "our JIRA, you lose", or does improving user experience really matters. https://jira.secondlife.com/browse/WEB-1819 Patch is attached and tested. Latif ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] display names = the end of 1.x viewers?
The big source of confusion regarding scripts is the following line from the FAQ: "Your username will automatically be formed from your existing avatar name in the form of your current Second Life firstname.lastname." Since existing functions will return username, does that mean they will return "latif.khalifa". Which is my username, "Latif Khalifa" or "latif.khalifa"? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?
On Sun, Aug 22, 2010 at 1:48 AM, Phox wrote: > I feel I need to take a moment here to address some of this: > > First of all, the issue with the login screen was NOT an attempt at > DDOS, Fractured was looking at traffic graphs for the website in > question and thought it would be funny to mess with them by making the > traffic go from ~150 hits a day to several hundred thousand. He was > simply messing with page views on the site, it was a stupid thing to do > no doubt, but it was not a DDOS attack. > > The website in question suffered no ill effects, and to imply that > loading a .php and a few images is an attempt at DDOS is just > ridiculous, our login page consists of a .php script a hi-res picture, > and our website doesn't go down as a result. Engineering an attack where several million requests a day were sent from all over the world to the affected web site most certainly qualified as DDoS. In some jurisdictions such attacks are considered criminal activity. The fact that attack was not successful is irrelevant. Motivation for such activity also makes no difference. What is relevant is that Emerald login page in effect turned every Emerald user into a part of a botnet. What is disturbing here are attempts to downplay the incident which does nothing to restore the confidence in the leadership of Modular Systems which is very unfortunate. ___ Policies 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] Requiring user stories for bug fix jiras?
Hi Oz, Looking through VWR-19505 I see the comment by the dev who made a fix that you have requested a user story. Do we really need user stories for bugs? There is effects setting in the main preferences floater, there is a menu that enables to turn on and off the selection beam. Why do you need a user story and justification for those sort of bug fixes? Should the devs have to write "As a user I expect that this bug is not present", or "As a user I expect effect color and 'show selection beam' menu items to do something"? Could we please get the procedure for including bug fixes clarified? Thanks! Latif ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] This is how Linden Lab treats it's customers...
It's still far safer not to have a premium account. You don't run a risk than when your premium subscription expires and your payment info is not up to date that your account will get suspended. You get locked out of you account, with a message "call 1-xxx-xxx-". This was not very helpful for a friend of mine from Croatia who is deaf and could not use a phone. My attempt to mediate and help sort out issues failed because LL told me "we do not disclose information about other people's accounts". Faced with a double wall like that, she just gave up on SL after being a premium member for over 3 years. Why LL doesn't simply downgrade accounts to basic instead of locking them out is beyond me. Because of this policy I recommend to my friends not to "upgrade" their accounts to premium, because they risk losing their accounts, and nobody would be able to help them if they themselves don't have the ability to communicate in English and over the phone. On Sun, Aug 29, 2010 at 6:08 AM, Yoz Grahame wrote: > This *was* a serious bug, but fixed over a year ago. Now a premium account > in default is merely suspended with the ability to fully restore on payment. > > On 28 August 2010 10:19, Gareth Nelson wrote: >> >> That's a serious bug in LL's business model - your account is safer as >> a basic, since a premium account that quits paying means the account >> is deleted (rather than merely downgraded). >> >> On Sat, Aug 28, 2010 at 5:35 PM, Tigro Spottystripes >> wrote: >> > -BEGIN PGP SIGNED MESSAGE- >> > Hash: SHA512 >> > >> > btw, if you're considering changing your account from premium to basic, >> > be sure to pay any money you own to LL and then downgrade your account >> > thru the site, do not just stop paying, if you stop paying them while >> > still being a premium they will wipe out all your account's data, >> > inventory L$ balance etc (i've seen some people that had the >> > misconception that to downgrade all you had to do was stop sending money >> > to LL, the ones that didn't got set straight in time lost everything) >> > >> > On 28/8/2010 13:01, mysticaldem...@xrgrid.com wrote: >> >> I don’t think anyone disagrees with. The problem is you can’t get a >> >> homestead unless you have a full sim already and so you need to rent >> >> from someone and this puts you dependent on someone else which is >> >> frustrating for people. So to log in one day and see all your hard >> >> work >> >> returned to your lost and found isn’t a pleasant experience and seems >> >> SL >> >> if they are serious about the user experience would have some better >> >> ways to handle this. >> >> >> >> >> >> >> >> I don’t know if you rent from someone else if you can do a restore of >> >> your region to the new location. But seems like there are ways to make >> >> this better if not just let people rent homesteads which to me I >> >> believe >> >> would be a huge market. >> >> >> >> >> >> >> >> Anyway this whole subject is off topic for this mailing list and >> >> probably should be on the SL forums. >> >> >> >> >> >> >> >> M. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *From:* opensource-dev-boun...@lists.secondlife.com >> >> [mailto:opensource-dev-boun...@lists.secondlife.com] *On Behalf Of >> >> *Joel >> >> Foner >> >> *Sent:* Saturday, August 28, 2010 11:49 AM >> >> *To:* Aleric Inglewood >> >> *Cc:* opensource-dev >> >> *Subject:* Re: [opensource-dev] This is how Linden Lab treats it's >> >> customers... >> >> >> >> >> >> >> >> >> >> After being a paying customer for more than a year, renting a >> >> homestead, >> >> and thus paying Linden Lab ~ USD$ 1000 or so ... they just take the >> >> sim >> >> offline, with no opening to even discuss the matter. >> >> >> >> Why? Because of something I did? No. The reason is that Linden >> >> Lab isn't interested in the "little people". Unless you have a FULL >> >> sim of USD$ 300 per month, you don't count. >> >> >> >> >> >> >> >> There is a simple answer for this. You are the customer of your >> >> landlord >> >> in this case, not Linden Lab. Yes, you have a Second Life account, but >> >> you are not renting your land from Linden Lab. You are renting your >> >> land >> >> from another avatar in Second Life. Linden Lab is not a party to your >> >> decision to rent... so why are they accountable if some other avatar >> >> bails out and decides to "level their city block"? If the landlord >> >> decided to stop renting, boot everyone off and re-terraform the region >> >> for some completely different use, would you think Linden Lab would >> >> have >> >> any responsibility for stopping that or somehow compensating you? It's >> >> the landlord's land, and they can do anything with it they choose to, >> >> including shut it down, leave, take it over from the renters, or shut >> >> it >> >> down and let no one else in at all. >> >> >> >> >> >> >> >> Joel >> >> >> >> >> >
Re: [opensource-dev] This is how Linden Lab treats it's customers...
On Sun, Aug 29, 2010 at 11:24 AM, Marine Kelley wrote: > The only issue is that the user is ALSO locked out of their SL webpage. To > me that makes no sense at all, because that's how they could access tickets > and get some help, or downgrade to basic, or change credit card info (what > if the original credit card has been stolen and the user blocked it ? That's > not valid grounds to lock them out of SL and yet they can't change their > credit card info through the SL webpage anymore). Locking them out of the SL > website simply discourages them from even trying to sort things out, and LL > loses money in the process. Yes, you are right. Having the web site accessible would solve the problem. In case of my fiend it was particularly cruel because she was asked to make a phone call which she was incapable of doing because of her disability (and even if she was able to speak, she doesn't understand any English). And I was told that I cannot call in her behalf, she'd have to call herself. ___ Policies 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] jira? avatar_lad.xml
Seems to be a regression in 2.1.2. On Thu, Sep 2, 2010 at 5:48 AM, Stickman wrote: >> just checked... ALL attachments are visible in mouselook, shoes rings >> and belt too > > There's an option in preferences: "show avatar in mouselook." It moved > in 2.x, but it's still there. Unless they took it out in 2.1. Turning > it off should make your attachments not visible in mouselook. > > Or are you saying they're visible regardless of the option? I think > I'd get more complaints about it from customers if you were. I haven't > gotten any in a while. > > 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 > ___ Policies 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] Sprint 3 : request for testing
Tested: SNOW-681 / VWR-1852 SNOW-683 / VWR-8726 SNOW-680 / VWR-10854 >From the test build posted, and they all work as expected. \o/ Latif On Wed, Sep 1, 2010 at 7:31 AM, Philippe (Merov) Bossut wrote: > Hi, > > I merged 4 Snowglobe 2.x fixes to merov_linden/viewer-development-import and > would like some tests from folks knowledgeable in the features before > pulling that in lindenlab/viewer-development. > > Binaries are available at : > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/208842/index.html > > The 4 fixes are: > - SNOW-681 / VWR-1852 : Local ruler mode aligned incorrectly for linked > objects > - SNOW-684 / VWR-4232 : Some particles don't disappear when UI is hidden > - SNOW-683 / VWR-8726 : Turn off swirling lights for scripted objects > - SNOW-680 / VWR-10854 : Honour share with group and allow anyone to copy > for snapshots > > Tests and comments welcome. > > Cheers, > - Merov > > ___ > Policies 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] Which build should I try?
Hi, Probably the best would be to test these: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/latest.html And report bugs (remember to select 2.1.2 as the affected version). Latif On Sun, Sep 5, 2010 at 4:14 PM, Ponzu wrote: > I am just a noob here on opensource-dev, and I feel a little confused. > Which build should I be testing? DEV? BETA? OTHER? V2? > I tried 209029_DEV, and all I can report there is that it starts and then > freezes up on my iMac. Should I create a Jira or send my logs somewhere? > Or is that totally expected behavior. > i also have one unexpected behavior in 207030. I get these weird yellow > bars that flash for only a second or two. Haven't been able to capture a > snapshot yet, because they don't last long and I cannot reproduce them. > They only seem to occur when I am using alt-zoom. Same questions, is this > worth a Jira or is anyone here intereted in logs or such? > Anyway, keep up the GREAT work everyone, some of us love you even if we yell > at you once in awhile. > > ___ > Policies 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] Getting JIRA data from scripts
In case some of you wrote JIRA helper objects that got broken with the JIRA updates recently here is a few hints: Appending ?os_authType=guest to the end of the request will bypass the OpenID check and allow you script to get the code directly, for example http://jira.secondlife.com/browse/WEB-2771?os_authType=guest If you find XML easier to parse you can get all the data about a JIRA issue in XML format by using the following type of URL: http://jira.secondlife.com/si/jira.issueviews:issue-xml/WEB-2771/WEB-2771.xml?os_authType=guest (Thanks to Sue Linden for providing the information :) Latif ___ Policies 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] STORM-106 : Chat Translation
Yey! On Sat, Sep 11, 2010 at 2:04 AM, Philippe (Merov) Bossut wrote: > Hi, > > Just to mention that this feature has been pulled in > lindenlab/viewer-development. > > Cheers, > - Merov > > ___ > Policies 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] Bug report or feature request?
I found this behavior to be very irritating as well. The only way to keep the notice from disappearing is to keep mouse pointer over it. It needs to be fixed in any case, but I don't know what would be the proper way to suggest a change. On Tue, Sep 14, 2010 at 11:30 PM, Dave Booth wrote: > In pretty much all v2 viewers, including development, I've noticed a > weird behavior with group notices... When they arrive you get a little > notification in the bottom right of the screen and that persists for a > short time and then goes away exactly as one would expect... However if > you subsequently go to the icon in the bottom bar and pull up the > notification history then click on one of the notifications for a group > notice because you want to read it, the floater that comes up to display > the notice ALSO fades out after a few seconds, even when its focused and > you're half way through reading the notice. Intended behavior or not? > Either way I need to file a Jira, but if its intended behavior I'll be > making it a feature request to allow me to stop this rather than a bug > report. Seems to me that when a notice has been explicitly pulled up to > read it then it shouldnt go away until explicitly dismissed. > > Or am I just missing something in the settings somewhere? > > Dave > ___ > Policies 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] For the benefit of TPV developers.
This is great, thank you Heri! I only wish other independent viewer devs would provide patch repository like this. On Sat, Sep 18, 2010 at 8:35 PM, Henri Beauchamp wrote: > Multiple attachment and inventory items links backport for viewer v1.23.5 > and Snowglobe v1.5 is available now as a standalone patch (in fact two, > one for each viewer branch) from my website. > > See the announces for details: > http://sldev.free.fr/forum/viewtopic.php?f=5&t=321&p=1319#p1319 > (multiple attachments) > > http://sldev.free.fr/forum/viewtopic.php?f=5&t=299 > (inventory item links) > > http://sldev.free.fr/forum/viewtopic.php?f=3&t=2&p=1322#p1322 > (Cool VL Viewer v1.23.5.29 and v1.25.0.6 implementing the > above). > > Enjoy ! > ___ > Policies 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] Snowstorm changes
Thank you Aimee and Tofu. Your departure is a great loss for LL and Second Life as a whole. Latif On Tue, Sep 28, 2010 at 8:33 PM, Kent Quirk (Q Linden) wrote: > Hello, everyone. > > We've had a good first few weeks of the Snowstorm team. It took a little > longer than we'd hoped, but we have launched the Viewer 2 Beta for version > 2.2.0, and we're continuing to move forward (new beta very soon). > > Much of our success in this period can be attributed to the unstinting > efforts of Tofu and Aimee, who have really done amazing work in the last few > weeks. > > We at Linden Lab made a corporate decision back in the spring to close down > our entire presence in the UK; all UK-based Lindens were affected, with > varying timing. This means that Tofu and Aimee will be no longer be Lindens > after Thursday. > > Both of them have worked on my team for a long time now, and I consider them > both friends as well as colleagues. Please join me in thanking them and > wishing them the best in the future. They will be missed. > > Cheers to both, > > 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 > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] So long!
Best of luck to you Tofu! Your great contribution and understanding of SL is appreciated and will be missed. Latif On Thu, Sep 30, 2010 at 5:42 PM, Tofu Linden wrote: > It's been great working with you folks, some of you for years now! > > SL is an amazing place, made amazing by its residents. Thank you > all. Please keep on making peoples first and second lives better! > > You can always contact me as Tofu Buzzard on SL. > > Be well! > --Adam M. > ___ > Policies 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] Uses of the Lookat target Crosshairs
You are reading too much into these "targets". Those are just viewer effects that help your viewer position head and the direction of eyes of the avatar to the desired location. They have no other use. Latif On Mon, Oct 4, 2010 at 3:37 AM, dz wrote: > Folks, > > Apologies if this is NOT the place to post this...but I really don't know > who else to ask. > > Yesterday I encountered an avatar who exhibited a very strange behavior. > Whenever someone in the club spoke in local chat, a Look At target would > attach to them. I understand there is a toggle to have your look at swap to > the the most recent to chat, but this look at target was white... which > is not a standard cross hair color. > > The other incredibly odd thing was that the look at target stayed locked > once there.. Because I was using the phoenix browser, which puts names on > the targets, I could see that there were as many as 30 of these targets > active at once. > > Does anyone know of a way to determine what the white target denotes, how > it gets attached to multiple targets at once? > > When i asked the avatar I got a very rude response... When I carried my > concern to the club owner, I got more rudeness and denials.. but it seemed > clear that there was some intent behind the crosshairs, as they were removed > shortly after I expressed my concerns. > > D > > ___ > Policies 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] STORM-406: Conditional use of FMOD is not correct, breaks open source build (was: Latest build broken on Mac)
Tested with https://bitbucket.org/merov_linden/viewer-development-storm-137 which produces working viewer, with FMOD support. Make sure to follow the updated instructions on the wiki that are mentioned in STORM-406, Latif On Thu, Oct 21, 2010 at 1:37 AM, Ponzu wrote: > Boroondas, my guru! > > On Wed, Oct 20, 2010 at 6:55 PM, Boroondas Gupte > wrote: >> >> On 10/21/2010 12:43 AM, Ponzu wrote: >> >> ...or maybe it is just me. I used hg bisect to find the " last good >> build", (see bottom of this email) Maybe I need to download new FMOD or >> something. >> ./develop.py dies like this... >> >> [...] >> RuntimeError: Cannot fetch: >> install-packages.lindenlab.com:/local/www/install-packages/doc/fmod-3.75-darwin-20080818.tar.bz2 >> >> That'd be STORM-406. >> >> 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 > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
