Void Singer

no, it doesn't. this information was deemed a matter of privacy, so online status only shows in your friends list, and then only if they enable their friends to see it. Some TPV's use a scripted workaround to provide this infomation

/*( v7-D Height Estimator )*/float cFLT_GUESS = 1.09; //-- 1.12 seems better for smaller avs, animations can affect thisvector cCOL_RED = <1.0, 0.0, 0.0>;string uMeter2Feet( float vFltHgt ){ string vStrRtn; integer vIntInches = llRound( vFltHgt * 39.3700787 ); if (vIntInches > 11){ vStrRtn += (string)(vIntInches / 12) + "ft. "; } vIntInches %= 12; return vStrRtn + llList2String( ["even", ((string)vIntInches + "in.")], !!vIntInches );}uReset(){ vector vSizPrm = llGetScale(); llSetLinkPrimitiveParams( 3, [PRIM_TEXT, "Stand Here To Get\nYour Avatar Height", cCOL_RED, 1.0, PRIM_SIZE, <vSizPrm.x, vSizPrm.y, 0.17>] );}default{ state_entry(){ uReset(); } collision_start( integer vIntCld ){ if (llDetectedType( 0 ) & AGENT){ llSetTimerEvent( 0.0 ); vector vSizAgt = llGetAgentSize( llDetectedKey( 0 ) ) * cFLT_GUESS; vector vSizPrm = llGetScale(); llSetLinkPrimitiveParams( 3, [PRIM_SIZE, <vSizPrm.x, vSizPrm.y, (vSizAgt.z * 2)>, PRIM_TEXT, llDetectedName( 0 ) + "\n" + (string)((integer)(vSizAgt.z * 100.0)) + "cm\n" + uMeter2Feet( vSizAgt.z ), cCOL_RED, 1.0] ); llSetTimerEvent( 30.0 ); } } timer(){ uReset(); }} this is the height detector I use... it's only approximate because attachments like hair can make the results a little low, and there is a bug that only report the height to about the eyeball level, compensated by cFltGuess... so I included a part that shows the height detected visually (usually very close to normal and SL sized avatars, but reports upt to ~4inches low for child sized avatars and tinies) which you will be able to see... construction: root prim: box or cylinder color black + fullbright z-height 0.05m second prim: (sits on the root) same shape/width/length/color as root z-height: 0.12m hollow: 95.0 (this compensates for the physics engine causing the avatar to hover over prims they are standing on) third prim: (sits on top of the second) same shape/width/length as previous color: medium grey transparency: 50 slice: 0.5/1.0 z-height: 0.17m ETA: I've posted this because there are two non-obvious tricks learned from experience and testing, adding in weight whould be easy to do, and this gives a good example of how to do it (for instance providing a weight conversion function so you can use both Imperial and Metric measures)

because it's a neat application and simple, you're in luck... here's how I'd do it... /*( Simple Lock )*/string gStrLockName = "Uber-Secret Name";default{ state_entry(){ llListen( -1, "Key", "", gStrLockName ); } touch_end( integer vIntTch ){ llWhisper( 0, llDetectedName( 0 ) + " tries to open the lock..." ); string vStrTemp = llGetObjectName(); llSetObjectName( "Lock" ); llRegionSayTo( llDetectedKey( 0 ), -1, "Keys Please" ); llSetObjectName( "key" ); llSetTimerEvent( 2.0 ); } listen( integer vIntChn, string vStrNom, key vKeySrc, string vStrMsg ){ llSetTimerEvent( 0.0 ); llWhisper( 0, llKey2Name( llGetOwnerKey( vKeySrc ) ) + " has the right key!" ); //-- do whatever you need to do to open/unlock the item here } timer(){ llWhisper( 0, "... but doesn't seem to have the right key (must be worn)" ); llSetTimerEvent( 0.0 ); }} and /*( Simple Key )*/string gStrLockName = "Uber-Secret Name";default{ state_entry(){ llListen( -1, "Lock", "", "Keys Please" ); } listen( integer vIntChn, string vStrNom, key vKeySrc, string vStrMsg ){ string vStrTmp = llGetObjectName(); llSetObjectName( "Key" ); llRegionSayTo( vKeySrc, -1, gStrLockName ); llSetObjectName( vStrTmp ); }} I encluded name swapping so that the keys and locks can be named anything and still use good filters... llRegionSayTo will only be heard by the targeted prim, or the attachments of a targeted avatar (when not using channel zero, otherwise the avatar only hears it) ETA: currently will break if the avatar is sitting on something, but that little bug should be gone after tuesdays restart (already gone on at least on of the release channels. ETA2: fixed typos

vector lightcolor = (vector)llList2String( AllColors, (integer)llFrand( (float)llGetListLength( AllColors ) ) ) llFrand expects a float.... and it's result will never be the highest value you feed it (always 0 to just short of the value given) so you don't need to subtract 1 =) ETA: the third value in a color vector is Blue not black, probably a typo

Thanks Lexie =) @Pete: it's not so much about the code hilighter, but about the goofy wrapping behavior that makes code posting wrap, making it harder for inexperienced users to understand (and a little harder for experienced coders to read, but that's just mostly just an annoyance for us). the hilighter uses a workaround to stop that, but a change to the forums causes that to collapse indents and remove line breaks (something that shouldn't be happening ever)

tl;dr next time please use paragraph breaks

also check for updates to quicktime, as that's the plugin that handles media streams, and may be the source of the problem.

as a work around, estate managers should still be able to return these items from their controls, but other privileged users with return powers will usually require a region restart before they are able to when this happens....

as noted windows is the most expensive component in there, and if you already have it on your current computer, you can transfer it (if it is indeed a replacement), so you can check into dropping that, although most of the times it's bundled so you either may not be able to, or possibly won't see much of a price drop. It is something to check on with a tight budget though.

avatar ghosting is still a problem, although the weekly restarts have made it less of an issue. occasionally ghosts persist until the next login attempt, or more often until a region restart. The most frequent cause of ghosting seems to be disconnecting shortly after a teleport, when the origin region hasn't yet let go of the handle for the avatar, but the destination drops it... seems to be a 50/50 shot which region the avatar ghost remains in, but usually it's the last one if the teleport completes.

Solar Legion wrote: [...] Technical notes, Town hall meeting notes/transcripts, Linden profiles .... All of that is information that should have been mirrored elsewhere by the users and former/current Lindens. while I'm sure LL agrees with you, I find the suggestion more than a bit silly. The whole point of having a wiki is to gather related content in one searchable and central resource location, never mind that even after the serial deletions the wiki is huge, or the fact that a fair amount of it is/was marked as illegal to copy, and only allowed to link to (making any public mirror liable for any of that content), or even how quickly mirrored content becomes out of date in a live and evolving information resource like a wiki, adding large time and resources factors for mirroring. in my experience no one expects mass wiki deletions, it's just not how wiki's normally work. Further more we weren't told they were going to go through and wipe out pages, just that they were going to "clean up the information on some pages"... I expected that some pages that no longer had any relevance at all might disappear, be merged, or redirected. I certainly didn't expect the level of wholesale content gutting that occurred, or I myself would have tried to save some of it and sift through what I could for at least technical data. but even that would be a monumental task given that as a user I would have had no way of knowing in advance which articles where facing deletion until a large number disappeared before I got to them. I don't argue that it's their resource to do as they please with, I do argue, that with the mass of user donated time effort and content, some consideration for that should have been applied, and interested parties made aware so that relevent information could be preserved

actually this sounds like the bake behavior.... the texture for a simgle item of clothing rezzes in, then disappears for a second and the whole av then goes blurry and rezzes. if it's happening repetedly, that's a bug, trying to force HTTP textures to completely rezz, it happens in phoenix and a few other TPV's for some people.... turning HTTP textures off, clearing cache and restarting the viewer fixes it for most people. if you are using Phoenix and have never messed with that setting (it's buried in the phonix pref tab) then you are running an older version (the newer version defaults to off), and you should probably update as there is a bug fix in the newer version for avatar physics wearables causing v2 avatars to appear ruthed.

checkbox on the create tab (the wand)

first thing, clear your cache, it was probably corrupted in the crash. second thing, log in and go to an empty region, then type into search and wait while it flips through and downloads your inventory again... you should be good to go from there

the 8800 GTX is actually older model card, with ~25% lower reported texture fill rate, but it does have a better memory path, and may have more available memory depending on which GTX 250 card you have, although the 250 has has faster clock speed all around. ref pages: http://www.nvidia.com/page/geforce8.html http://www.nvidia.com/object/product_geforce_gts_250_us.html overall my guess would be that the 250 will beat out the older card in performance, but the older card will win out in initial speed of draw, which may be a bonus if you teleport around a lot.

it can also take a few days for it to update inworld

you also need to update the posting tool (it's a minor change from inserting the span that contains the whitspace style workaround to not inserting it) ETA: it does mean that others will see the code wrapped in the container... a poor decision on LL's or Lithiums part, I don't know which

oh I get what they were pushing there... it was just the before/after rinsing the makeup off. I'd invest in anything that could do that lol

to heck with the sushi, I wanna know what brand of makeup that is... so I can invest and retire (and look like a movie star when I'm 80!)

close other open applictaions, reduce draw distance, possibly even your graphics setting, and maybe just maybe Cool VL(jgi) will run a little better on it. but as has been said above... the graphic card probably isn't up to the task, everything else is reasonable. and if it's making a screaching noise that means the fan is about to, or has already failed, and needs replaced before it overheats and burns up

span tags are being stripped of spaces and line returns are being replaced within them...

Changes to Lithium have broken the ability to post correctly formatted code. at fault seems to be a behavior change to how "PRE" tags work... originally they were goofed to forc wrapping instead of scrolling within their box, the workaround was simple, but annoying... you aren't allowed by the software to add style attributes to the PRE tags, so one was added to a SPAN inside to prevent line wrapping, reactivating the proper scroll box behavior. now, adding an encompassing SPAN within the PRE causes the the text to lose all spacing and line returns are converted to spaces. this appears to be a behavior change to the SPAN elements. or the processing of them from the editor. whatever you guys changed, please put it back, or even better, make PRE tags behave as they are supposed to normally

1k+ items? I sense overkill. how about a single notecard with all the names in the updater and a single script that that runs off of it.... send the notecard and the script first (you'd need to use script pin) or have the script already built in... script reads notecard, deletes any names in the target object, then deletes the notecard, sends a continue message to the updater, (and deletes itself if it was sent). or like like Rolig was saying, send a message with names to delete, as long as the receiving script isn't one of those names, you are fine. can be sent from either end object, depend on if you want the new or the old to take precedence

they broke Cerise's wonderful highlighter =( they've mucked up the pre tags even worse somehow, and now they don't actually work if they contain any formatting code, and start collapsing spaces and line returns... I am very annoyed

region coodinate ARE global coordinate, unless you mean gridwide coordinates (as can be use by llMapDestination) in which case you add the region coordinates to llGetRegionCorner. yeah the language used overlaps a bit, that's why I asked