[opensource-dev] UI produces just grey boxes
Dear Developers, Since November last I have been unable to build a a version of the viewer that does not cause the UI to suffer from what I might call severe grey fatigue syndrome. Please see the attached screen shots to understand what I mean. I am building using Xcode Version 3.2.3. I have pulled fresh sources from mercurial, but to avail. Always I am left with this unusable situation. I am certain it must be something quite simple, but I am at a loss for what it might be. Has anyone else seen this before, or even better, might some kind sole know how I can rid myself of this problem and finally switch to a newer viewer? For those who would like to suggest I simply download a prebuilt binary, this will simply not do. I have my own custom modifications to how the viewer handles scripts (I am a scripter, after all, and then some) for which I cannot be without. And to anticipate the question, yes, I have attempted to build from pristine source. I have also moved out of the way /Applications/Second Life.app on the off chance that there was something from there that was being picked up. I have also dispatched every file located in ~/Library that I could find associated with Second Life. Clearly none of this helped as I am still sending this message. Thank you to all who read my plight and thank you and kiss to those who might provide me the solution, Hugs, Glimmering <><>___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] UI produces just grey boxes
Thank you, I will try from a freshly made account. The hint that it is possibly the artwork bundle will hopefully help much. Hugs, Glimmering On Tue, Apr 5, 2011 at 6:34 AM, Boroondas Gupte wrote: > On 04/05/2011 07:46 AM, Glimmering Sands wrote: > > Please see the attached screen shots to > understand what I mean. > > These look like your build is failing to load the images included in the > viewer's Artwork from disk. I guess images received from the network or > retrieved from the cache work (There's an IM session icon visible in the > second screenshot.), so it's probably not an issue with decoding images in > general. > > As the artwork is now included in the source repository, it can't be that > you forgot to unpack it. (That was a common cause of this symptom with 1.x > Viewers.) So probably it's either a image file type specific problem (I > think most of the viewer artwork is PNG while textures received from the > asset system are JPEG2000) or your build is for some reason looking for the > artwork at the wrong place. > > Things you can try to narrow down the cause: > > Try another build (e.g. official download) on your machine and see whether > it suffers from the same problem. > Create a new operating system user account on your system and try your build > with that. > Create a new SL user account and try your build with that. > Try your build on another computer. > > Lastly, see whether the build instructions have been updated since you last > read them. Maybe something needs to be done differently than before to get a > fully working build. > > Cheers & good luck, > 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
[opensource-dev] s3-proxy.lindenlab.com points to a private IP address?
Sorry to bother you kind folks again. I am attempting to follow the suggestion of building from scratch from a new account. Given that the instructions for how to install fmod are now missing from the wiki I decided I should just follow the autobuild instructions. Maybe they will work better? But alas, fate would have it that this has a failure for me as well: downloading fmod archive from http://s3-proxy.lindenlab.com/private-builds-secondlife-com/hg/repo/3p-fmod-private/rev/221852/arch/Darwin/installer/fmod-3.75-darwin-20110222.tar.bz2 unable to download file: So why does this download timeout? $ nslookup s3-proxy.lindenlab.com Non-authoritative answer: s3-proxy.lindenlab.com canonical name = int.excod.lindenlab.com. Name: int.excod.lindenlab.com Address: 10.6.3.104 No, even in the fantastical world I might live in, I am quite certain I am not able to reach linden lab's private servers, nor do I think setting up my own 10.6/16 network would be of any assistance. Perhaps this is an error by the DNS administrators at Linden Labs? Kind Regards, Glimmering ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] s3-proxy.lindenlab.com points to a private IP address?
Well, I have discovered, through the wonders of Mr. Google, that there is an older copy autobuild.xml out there at: https://bitbucket.org/merov_linden/viewer-autobuild2010/src/44f214103cff/autobuild.xml and I was able to simply use the http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/... lines for both fmod and kdu (would it be considered a bug that Linden Labs is distributing an autobuild.xml that uses internal only paths rather than using the external paths (that I guessed the used to have?) One can also wonder why you would let internal DNS records be allowed to external sites as well... Sometime later I will discover if this solves my grey goo box problem or not :-) Hugs, Glimmering On Tue, Apr 5, 2011 at 8:14 PM, Glimmering Sands wrote: > Sorry to bother you kind folks again. I am attempting to follow the > suggestion of building from scratch from a new account. Given that > the instructions for how to install fmod are now missing from the wiki > I decided I should just follow the autobuild instructions. Maybe they > will work better? But alas, fate would have it that this has a > failure for me as well: > > > downloading fmod archive from > http://s3-proxy.lindenlab.com/private-builds-secondlife-com/hg/repo/3p-fmod-private/rev/221852/arch/Darwin/installer/fmod-3.75-darwin-20110222.tar.bz2 > unable to download file: > > So why does this download timeout? > > $ nslookup s3-proxy.lindenlab.com > Non-authoritative answer: > s3-proxy.lindenlab.com canonical name = int.excod.lindenlab.com. > Name: int.excod.lindenlab.com > Address: 10.6.3.104 > > No, even in the fantastical world I might live in, I am quite certain > I am not able to reach linden lab's private servers, nor do I think > setting up my own 10.6/16 network would be of any assistance. Perhaps > this is an error by the DNS administrators at Linden Labs? > > Kind Regards, > > Glimmering > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] s3-proxy.lindenlab.com points to a private IP address?
Curious assertions you make, WolfPup Lowenhar. So, I wonder, what would be a more up to date repository than the one retrieved from by: hg clone http://hg.secondlife.com/viewer-development Which is precisely where I retrieved the repository that I used just a few days previous. I also followed the instructions on the public wiki for how to use autobuild. Perhaps it is naive to assume that as it is documented, published, and available, that it might actually be of use (in particular since it appears the older documentation of how to work with fmod is gone). The autobuild reveals three problems. The first is that it attempts to retrieve files from s3-proxy.lindenlab.com which resolves to a non-routable IP address. The second is that linden labs would allow internal IP addresses to leak to the outside. The third is that the documentation on how to build the viewer gives no indication of what do do about the situation. Perhaps you misunderstood that I repaired the two lines of the autobuild.xml file such that the autobuild will work. I did so with the help of Mr. Google who pointed out an older autobuild.xml that referenced an alternate location of the two particular files in question using a globally routable address. If you are concerned that this solution resulted in out dated copies of said files, please do not be stressed as they appear to be the same ones referenced by the new "broken for everyone but lindens" autobuild.xml file as the checksums match. So, contrary to your assertion, you do have access to the said files if you care to repair your autobuild.xml, the issue presented that linden labs should not have placed said files there not withstanding. My task was a simple one, to simply build a current viewer without grey goo by using the publicly available instructions. Of course, building the SL viewer is never that easy. Fortunately this time the task was accomplished with only having to modify two lines in one file. Hugs, Glimmering On Thu, Apr 7, 2011 at 4:45 AM, WolfPup Lowenhar wrote: > Ok I see two things here Glimmering Sands: > > 1. You are using an old repository the current one is actually viewer > development as autobuild has been merged in. > > 2. FMOD and KDU are actually somewhere in http://s3-proxy.lindenlab.com > of which we as Open Source Developers have NO access to and are NOT allowed > to have access to. > > > > Ima Mecanique, > > The FMOD and KDU libs are not distributed externally if you look at a > current copy of the autobuild.xml you will find that the address is a > private one for them and a few others LL cannot freely distribute. Now LL > has ‘provided’ a way for those that have FMOD already to ‘re-pacakage’ this > one for use in the autobuild. LL dose not actually modify any of the FMOD > files but actually creates a ‘wraper’ in the form of llaudio to interface > with fmod.dll so that those that are on Windows will have working sound. > > > > From: opensource-dev-boun...@lists.secondlife.com > [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Ima > Mechanique > Sent: Thursday, April 07, 2011 7:03 AM > To: opensource-dev@lists.secondlife.com > Subject: Re: [opensource-dev] s3-proxy.lindenlab.com points to a private IP > address? > > > >> Linden Lab should not be distributing either of these libraries, as >> they do not have a license that permits them to do so(from what I have >> heard from them in other dialogs). So this violates and possibly voids >> their license for Kakadu, as well as all of their careful planning to >> keep it out of every developers hands except for their own. >> >> I hope that they will take these down, and it is not an error that you >> should NOT be able to download them. The error here is that they are >> trying to be downloaded at all. > > This is something of a grey area. > For KDU, this is not distributing per se, as it is only the headers and > lib file to link against, not the final library being made available. > I'm not privy to the license details so have no idea if this would be a > breach of terms.. > > For FMOD, things are clearer. > > "The contents of the FMOD distribution archive may not be redistributed, > reproduced, modified, transmitted, broadcast, published or adapted in any > way, shape or form, without the prior written consent of the owner, > Firelight Technologies, be it by tangible or non tangible media. > > The fmod.dll file may be redistributed without the authors prior permission, > and must remain unmodified." > > LL have both modified the archive (by creating a new one) and are > redistributing that modified version, so I hope they have obtained > written permission from Firelight Technologies I'd hope that FT would > be
Re: [opensource-dev] UI produces just grey boxes
Thank you, Boroondas. First, the grand news, once autobuild.xml was repaired I was able to build a functioning viewer! Hurray! I actually have been using Mercurial to retrieve the source tree for some long time, however, when I pulled news sources several months previous it led to the aforementioned situation. The major change, aside from using an alternate account, was to use autobuild to produce the Xcode project from whence I conducted my final build. Perhaps time will be found in which I can examine the differences between the old and the new to determine where things run afoul, but for the moment it is happiness to simply have a method to banish the grey goo from my display :-) Hugs, Glimmering On Wed, Apr 6, 2011 at 12:31 AM, Boroondas Gupte wrote: > On 04/06/2011 04:57 AM, Glimmering Sands wrote: >> Thank you, I will try from a freshly made account. The hint that it >> is possibly the artwork bundle will hopefully help much. > Note that since the move to mercurial, the artwork is included in the > source tree (most of it in indra/newview/skins/*/textures/) so there > isn't any artwork bundle anymore. > > 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
Re: [opensource-dev] Any possibility of playing animation b y uuid?
Yes, this would remove a lot of complication from a HUD. No longer putting it on the ground for no-copy animation, no more need to rez an object to have it accept a copy animation and put it in your HUD for you. And no longer be limited to the animations you own! You could easily import any animation that anyone is playing into your HUD! Just walk by your favorite animation store and simply import any animation that anyone is currently using (or just stand on the demo to play-n-import them all). It is trivial to get the UUID of any animation that is playing in the region, be it no-copy or not. This does not require a hacked client, it can be done with a simple script. I do think the suggestion of being able to play animations that are in a different prim of the same object would be nice and would not be insecure. At least then you could leave the main prim to only have the customers animations and possibly notecards. I also wish it were possible to transfer a no-copy animation (inventory object) from one object to another. -Glimmering On Mon, Apr 18, 2011 at 10:54 AM, Brandon Husbands wrote: > exactly. Now if you have a hud or something everytime you wanna dynamically > update animations you have to push out a new version. But with textures and > sounds you can have the data there by uuid. Its a pain to have to produce > every animation in every object. This way even more secures the animation > where the customer does not even have the ani and it can be in the sim. or > what ever. > Giving them a copy only ani poses more risk than having it just coded by > asset id. > > On Sun, Apr 17, 2011 at 8:29 PM, Thomas Shikami > wrote: >> >> Am 17.04.2011 21:02, schrieb Brian McGroarty: >> > If reference by asset ID is important enough that you'd want to work >> > on it, lay out a proposal detailing what permissions could be baked >> > into an asset at upload time, and how the permissions could be honored >> > by all viewers. This would need to be done without the simulator >> > process having to parse the asset. Eventually we'll want static assets >> > served up on a CDN independently of the sim hosts, so it would be a >> > liability if the simulator process needed to download animation >> > assets. >> I'd like to have this neat feature implemented, which would ease >> programming of multipose furniture and group animation tools. >> If a script is in a task accompanied by animations, it should be able to >> call an LSL function like this: >> key local_anim_key = llGetLocalAnimationKey(string inventory); >> >> Once it has that key, it can pass it around to other scripts in the same >> simulator, either to poseballs or group animation client HUDs, which >> could then use the local_animation_keys like this: >> llStartAnimationByKey(key local_anim_key); >> llStopAnimation(string local_anim_key); >> >> those local_anim_keys would be only valid as long as the task in the >> simulator exists. All local_anim_keys would be invalidated, when the sim >> is rebooted. >> >> The permissions to animations would be the same like this, instead of >> requesting permissions from the agent to animate the avatar, the >> semantics would be permissions by proxy then, allowing an object, which >> can request permissions instead which would be automatically granted, >> either sitting or wearing. >> >> A way to keep the local_anim_key consistent for the same asset would be >> preferable if possible. That way animations could be banned reliably. >> ___ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > > -- > --- > This email is a private and confidential communication. Any use of email may > be subject to the laws and regulations of the United States. You may not > Repost, Distribute nor reproduce any content of this message. > --- > --- > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
