Void Singer

if the product juke box (I'm not familiar with it) allows each user to pick their own station, then you could probably just add a station that is known to not be working, and label it as "Off"... actually this should work regardless. if you take Winters suggestion, and the radio does allow individual avatar stations as described above, then make sure to add PARCEL_MEDIA_COMMAND_AGENT and your key, so that it's only turned off for you and not everyone.

llRegionSay (broadcast), or even better (but slightly more complicated) llRegionSayTo (if you can target receivers) will cover messages for an entire region. you can use a repeater settup to pipe it accross region borders by placing a prim that listens to the region messages, changes the channel and whispers it across the border to another prim that will change the channel back and rebroadcast it. lsl HTTP servers are another method, but will always require targeting, and be a bit more complex to set up. if you need broadcast type messages (can't rely on knowing the key/address of the target) then llRegionSay with a chat bridge as noted above will probably be your best option. using lsl HTTP you could build just the bridge portion to allow yourself to connect remote regions though, or even adjacent ones, without the need to place prims near the border. please not that lsl HTTP communications will need some sort of back up method to detect address changes, as they lose their current address ever time they change regions, or the region restarts... email is one solution, external DNS style services are another.

I'm not sure glitter is the right word to describe it, although that may be down to the specifc outfit they were wearing... what was happening is that some texture layers would fully rez and then refresh as if rezzing again. It mainly seems to happen with texture that had an alpha channel (even if no alpha was apparent), or had certain other settings like shiny or bumpmaps applied... it was noticeable on most linden trees as well. it's cause was a patch that attempted to compensate for textures that weren't loading fully via HTTP Get, and only the users with the problem saw the effect. given the annoying side effects and that it's limited to users with the problem, it's probably not very useful for design, but you are welcome to try. Iknow both Phoenix and Cool VL had the code for it, although I believe Cool fixed the problem (I haven't checked recent versions that not a fix for it). to my knowledge it's still in the latest phoenix revision, if you enable HTTP GET Textures, and use high or ultra video settings.

eek, I expected it was due to a policy change, but was not expecting one so ... expansive. and I'm certainly not looking to make extra work for you, so my apologies.... I'll try to avoid those, although I regret to say that there were at least two on my early list, Blue and Babbage who both tended to be contact points on a great many things.... (although if memory serves Blue kept most of that to office hours), as well as some of the Euro office techs... If' your unable to do anything for those, I understand, and will try other channels as suggested, no reply needed. I should have a quick list by tomorrow morning lab time, but I can't speak for others (I did mention your generous offer in the Off Topic thread, and urged them to be kind). Again my thanks.

PeeWee, if I could kudo you for making me laugh, I would.

good catch... I read this earlier and wasn't sure where you pointing at, and meant to ask =X the problem seems to be that not only that the links point to different places when logged in or not, but also that the page linked when you are logged in is ONLY reachable if you are logged in... copying the address for it when logged out and pasting it into the browser pushes me through openID asking for me to log in... kinda silly for such a basic information page

I'm curious which component caused the rollback of the Main channel, and if it's related to a few reports of physics items getting duplicated? I've seen at least one user report of stuck vehicles that got duplicated multiple times on the forums, a few third hand reports inworld, and I suspect it may have been the root cause of a recent pileup of physical tram cars in the Babbage regions (which I have a spectacular picture of... it's really a sight to see, and is living proof that server performance has improved, as the regions didn't crash, and I was able to move around without much rubberbanding, so kudos on that!)

Nalates Urriah wrote: It is costing them time as they have to support the new stuff and legacy stuff (UDP Texture Get vs HTTP Texture Get). while I mostly agree with the rest of what you posted, this one thing stuck out at me as giving the entirely wrong impression. while HTTP GET is a prefereable solution from the labs side, (and the accompanying HTTP inventory) it is not without problems, even within V2 and reverting to UDP by disabling these is one of the frequently suggested (and working) fixes for issues with slow or incomplete loading in ALL viewers. The problems are bad enough that the Phoenix devs decided to disable it by default in recent updates, until more improvements to the system can be made. Some of this is down to LL, and they have made improvements, but I think some of it has to due with network issues and prioritization. Regardless, even if every v1 based viewer disappeared overnight, they'd still need to support the alternative until the worst remaining kinks in the HTTP transport are worked out. right now the biggest one seems to be incomplete and/or stalled loading. unfortunately those seem to hit inventory and avatar textures the hardest, and are arguable the most import to the end users. Maintenance of those methods remains at least until those issues are addressed, and to my knowledge all of the TPV's support the newer HTTP GET and even where disabled, can easily be changed.

thanks for the attention Blondin, this is certainly not a practice that any legit business has ever instituted in my experience, and is very worrisome coming from one contracted by LL to handle sensitive financial and personal information.

it's pretty simple really... give uses a cheap, easy and legitimate way to get what they want, and most of them will use it. that said, as far as traffic goes, there's a bit of a lie going on there... streams from netflix suck down bandwidth at an ungodly rate compared to even sharing the exact same movie as a file... a 1.5Mbit connection is about the minimum if you want to watch their content and make your eyes bleed from the poor quality. 3+ is my personal recommendation. and then you have to account for replay factor, a downloaded movie via file sharing can be viewed repeatedly without addition bandwidth used, but you multiply it if doing the same over a streaming service like Netflix, Hulu, or w/e.

you weren't the only one.... I thought that was one of the most amusing messages they had (it used to be you'd get it for 404 pages too) IMO, some of that humor is what's missing from the current "profession image".... it encouraged resident to have a bit of a light laugh when things went wrong... now there's to much CorpBorg "Error, malfunction in grid 33-5-7 rerouting in progress" (which WOULD be funny if accompanied by the appropriate picture and sounds)

I can actually put NAMES to most of the phrases... mostly better known one, but still.

I hate to be the one to say this, but default 1.23 has missed other security patches as well. And this is perfectly inline with LL's policy regarding it... "unsupported, use at your own risk" (garnered not from the official pages but various office hours). I suppose if enough people say get rid of it, they will, since it's only there as part of a promise they made to keep it for PPC users, but I'd think that would have to come from those users. to my knowledge none of the publicly available TPV's use it for a diff base (Cool I think was the last one, and dropped it months ago). but I could be wrong.

I don't know of any better methods for continuous updating from a touch like that, althou you may conside llMinEventDelay instead of a sleep. my standard for such things has always been to update the local hud color continuously, but not to send the data until the touch end. it doesn't give as pretty a flow on the target item, but it prevents the object from spamming mesages.

MOAP uses duplicate caching, so it won't refresh the exact same address as it already is using. instead, appending a search string with some random or sequential data will beat this limitation on a per user basis, or as suggested you can use the media function to force a redisplay for all users, but it has an additional delay of 1 sec. if you use LSL HTTP-in to server any of that content, a cheap way to do it is to insert the request key as part of the timeout URL search string that's served with the page, which should make it unique every time (and has in my own experiments)

I would think what you are seeing isn't black, but the alternating fullbringt and glow ... as for the color not appearing in order... you used a random number generator in there... so that's pretty normal.

ok just had to share.... a several dozen or so physical tram cars, backed up across 2 regions, some wandering around vacant lots.... Just proof that that machine revolution had it's roots in the age of steam! (but hey the region is still usable, so the servers are getting better)

I double dog dare you! lmao (Nice to see that sense of humor sneak out) =) =) =)

llRegionSayTo("10e457cf-c631-cc69-2cb8-cd384541aca4",-524,"Rotate"); llListen(-524,"Switch","fac317ac-dc0f-c394-ad48-1b9a0644e9c4","rotate"); new game... spot the bug.... if you specify text in the listen, it has to match EXACTLY =) ps you don't need to lowercase or check it if you do specify the text though, because it will only fire for an exact match pps you may not want to use exact keys unless you have a way to discover them, because they change each time the object is rezzed (but just for rezzes, not for things like region restarts)

good news and bad news good news first, Rand has offered to restore some pages by request, as per this notice. bad news, you'll have to make an educated guess as to whether a page had content that needs archived/reviewed, I do NOT suggest sending him the whole linked list as I doubt he'd find it very funny, and he has made efforts to relocate information to pages that are current (so if you see a page that might have important info, check by searching to see if it was already inserted into another page) the possibly worse news... there are several pages marked "(Obsolete or disallowed information re: LL)" in the deletion log, and unless I miss my guess requests for those pages (mostly Linden staff user pages) will be ignored... My guess is that this is due to a privacy policy change for Linden staff, or may be related to former staffers inability to have those pages removed (since their Linden accounts would have been deactivated)

will test as soon as I login, however my understanding that face behind it with non transparency is the one the ends up generating the payment click, I'll see if I can work up a good demo for that =)

I'll try to review tonight or tomorrow afternoon, and my gratitude for pointing me in the right direction.... my main concerns were mostly information sacked away in user and talk pages for several of the tech and policy lindens, although I was concerned about the Gteam pages in particular, as there may be some policy explanations/expansions that may still be relevant, and I did note some information lost in regards to region type technical limitations that I used point others toward to help them detect region type by behavior but never copied over myself, things like advertising limitations that show up in region flags and what not. I heartily agree that there is a good deal of content that needed folding into official documents, or no longer relevant clutter (if I had the time to devote to it I'd work on the LSL HTTP Server and related Shared Media pages myself because they're a scattered mess) so I just want to say that the efforts you are going to are still much appreciated, and unenviable =) I know nothing about the translation projects, so can't really comment other than to agree that what you said sound perfectly reasonable. ETA: took a quick peek and, oh my... ‎ "(Obsolete or disallowed information re: LL)"... am I right to assume that requests for any of those pages are unlikely to get a response?

glad that's cleared up, now on to the pointing and laughing..... ...because that's an positively absurd statement that has absolutely nothing to do with mesh deployment. LL develoment has always worked on the "build it and they will come" model, and never on the "wait for everyone to show up before we show it off" model.... ocassionally there is a "we have to make this because users were threatening use with pitch forks and torchs" item, but that's pretty rare, and usually only happens when they remove something (like the ability to move seated avs, jumpPos to beat the tiny limits imposed by sitting, etc) they've released plenty that wasn't accessible to other viewers before, and I have no doubt they will continue to, including every new feature in V2, and in fact even sculpts back in the day weren't forced upon us until a security patch for an unrelated exploit required it (and even then we had TPV's although they weren't called that). the things you mention have ZERO impact on release, and only limited impact on users generating content.... it's been shown repeatedly that new content drives adoption, not the other way around. If the code were already stabilized and available you'd see it in TPV's already (llTextbox anyone?). In point of fact LL has consistently marketed new features of the official version to bolster their stats since the TPV policies went into place. Your reasoning on this is contrary to both LL's track record, all the technical facts we have access to, and even history in general.... it's about the same as saying that cars can't be made unless we first kill off all the horses. it's beyond ludicrous. The one does not rely on the other. @Anna: You might also try Cool VL. it uses a v1.5 codebase, and is kept very clean with current bugfixes, and includes backports of all the major features, and is often the first one to include them. it has what is probably the lowest system requirements of any viewer outside of the official v1 download, and runs more smoothly in my experience.

Jenni Darkwatch wrote: I'd imagine there's already a mechanism to exclude offline users, there almost has to be. Might be possible to expand on that pre-existing code. Without knowing the server code tho... dunno. one can hope (heavens know I do), but if there isn't it might explain a few things =X

is it sad that I can hear that list spoken with the proper growling haughty inflection full of disdain and bravado? #5 is definitely my favorite, to sound of Worf's brothers voice ...your feigned sarcasm brings honor to your house.