Void Singer

every large scale change in SL has had people claiming it will be the end of SL... and every such change in the future will hear the same claims until the end of time if need be. assuming that some other disaster doesn't overtake the world first, eventually one of them might even be right.... but lacking an actual reason, they (and you) still have it wrong.... saying the "signs are there" about the same bs that was claimed the last time isn't really a sign of anything, much to Doomsayers dismay, but it sounds good (after all the world was supposed to end last Saturday... yet here we still are chatting away)

height measument for av's relative to the the SL meter is just bugged because the function only counts up the to top of the av neck... phoenix does a little futzing behind the scenes to get head size to add to it, making it accurate... V2 doesn't and just relies on the buggy numbers from the region. scripted functions have the same problem. ETA: the answer to the original question was C: design flaws leading to competing conceptual standards. PS option A and B are the same thing. PPS Officially a meter is a meter is a meter, real virtual, or imagined.

you can try either of the following, if those functions aren't satisfactory.... apply the texture by UUID in the script, you can get the texture uuid from your inventory in the right click menu, drop a copy of the texture in the objects contents This is strictly a permissions based problem, and i'm unsure if it is due to a change or not, but could be... there was a permissions exploit that would allow capturing the uuid of permissions limited textures a while back, so we could be seeing fallout from a fix for that. NVM darkie has it... it's the longstanding permissions idiocy caused mostly by the chaining of all texture attributes in the prim params functions

ya know, I actually missed this reply that came after 4 days... and all I can say is that Cerise was much kinder than I would have been after reading it. for reflection, you might want to consider the following... top ways to get free help: Find the people that know and are willing to help, and be courteous provide a detailed explanation of your trouble respond to any failed examples with the results. top ways to NOT get free help: Be rude or accusatory give vague descriptions of your problem Ask people to do it for you

see my notes on using llScaleTexture, and llOffsetTexture... this prevents you from needing the uuid of the texture, and any permission related problems form the texture itself or the object it's in.

@thread, but vaguely related to Innula's request for clarification of V2 troubles I make no bones about my dislike for v2, whether it be the mutiple bugs breaking long standing functionality (--login, --noprobe,full screen, UI scale, etc ad nausem), poor layout choices (sidebar that resizes the world and breaks huds, over sized panels and headers, wasted top bar space), or poor ui choices (grey on black with eye burning green links, inability to customize and or retain customizations, to dark elements blotting out the world, etc)...... things have improved slowly.... much too slowly IMO... but still improved. I think though, that the problems can all be exemplified in one change.... the loss of the pie menu. From a user perspective, Pie was new to most, and I won't argue that it suffered from some problems in regards to consistency.... there were times when clicking one thing put an option in one place, and clicking on a different item had it in another... that was bad. What was good about it was that all of your click targets were large, while not obscuring what was behind them, and keeping all options in close proximity. like any menu you did have to learn where all the options were, but once you did, navigating it could done almost blindly, right click, twitch, click, click, twitch, click. it's a paradigm very suited for fast navigation, especially considering the large screen spaces of modern monitors.... in contrast, the change back to linear menus is a step backwards, menus obscure the world, the click targets are tiny in an attempt to minimize that, requiring extra precision to navigate, the windows that they open are usually in completely unrelated default areas, and in many cases either cannot be set to new defaults, or spontaneously revert to previous defaults. leading into another pet peeve of mine that window position and stickiness (presence after relog) are completely random, varying from completely unstuck, to cannot get rid of it or resize it in a meaningful way (evidence the worst offenders, torn off sidebar tabs that don't stay minimized, spontaneously revert to the sidebar, cant be removed (evidence: "home") and the worst, the huge My Profile that's utterly useless no matter where it is since the adoption of the painfully slow and frequently broken web profiles. and mind you this is in a viewer that supposed to give you a "more browser-like experience"... except the part where browsers have been increasing UI configurable since before SL was open to the public. that's not to say that V1 interface was a model of efficiency... the sheer wall of options thrown at you from the begining was and still is daunting to new users.... it's the equivalent of going from driving a car, to a modern aircraft cockpit with buttons and gauges everywhere, although to it's credit it did a pretty good job of not overly obscuring the world, which, after all, is the whole point of logging in. and therein lies the key difference, and the thing that V2 development needs to learn from V1 interface... V2 encourages passive observation through it's dramatically different interface compared to the world and it's relegation of the world view to a pretty background picture to looks at by excessively intrusive and focus required design elements... compared to the world focused and interactive design of the V1 interface... the more you draw the user out of the world, the less attachment to it they'll have... and no attachment is developed if they aren't allowed to immerse themselves.... The actual content needs to be the focus, and only obscured when you just can't help it... every successful interactive environment follows that basic precept, whether it's video games and their minimal information displays, or cars in RL with unobstructed views of the surroundings, everything must be secondary to the environment, and only intruded upon at the time and location of the users need.

hmmm, that's the first duplication report I've seen for a non-physics item... two questions for you... do you use a wireless connection, and what is the server version channel running on that region (help --> about)

I didn't mean to suggest that the viewer was requesting specific regions of memory, only that it might be starting threads beyond what it can address, being unable to address them, and so re requesting them (the abandoned space being effecitevely leaked before it can even be used) the OS should prevent this, unless the viewer is misreporting, or there's some combination of calls exposing an OS flaw. PS PAE is also auto enabled of winXPPro starting at sp2 or 3 I think, if more than 2gb? of physical memory is detected, but as I said, PAE shouldn't cause that, because like you said, it using paging to limit what an app has access to. I think your guess at plugins is a much more likely explanation, possibly moreso if the use plugin read thread option is turned on... from what I've seen the viewer opens SLplugin separately for each media instance, and doesn't ever seem to close them, sometimes despite not actually needing them (I've had at least 4 going with media disabled =/)

the texture permissions need to be set to full perms in your inventory for next owner, then reapplied if you are going to get the texture name by script... or include the texture in inventory. alternatively, you can avoid all that none sense by using llScaleTexture, and llOffsetTexture to set those attributes without having to muck about with getting the texture uuid. PS the third parameter in the vectors for texture offset and scale are unused, so zero is preferred for clarity (otherwise people might look at an think that it does something, and never be able to figure out what. PPS always use complete float values and not integers in code that expects floats, otherwise the compiler will automatically add a float cast which is another 2 bytes and an additional instruction, your code below has an extra 26 bytes, and 13 instructions after being compiled that you don't see. not horrible but it adds up fast and slows down your code.

refresh rate isn't going to make a difference to LCD tech, because a pixel lit, stays lit, unlike in a CRT. the difference is simple and can be seen in most digital clocks... each part of a number stays lit in between changes... it never gets turned off unless it needs to be off. a CRT works by flashing really fast on the same pixel, with the same value. CRT with a refresh below 85hz give me a headache, and I can actually see the flashing as high as 78hz if I look for it. 60hz on a CRT limits me to an hour tops. The same 60hz on an LCD is undetectable, because the pixels stay lit, and it's only changes that occur at that rate. and even those are less detectable since the pixel still tays lit and only the color changes (in general). Knowing the refresh requirements I had for CRT's I freaked out a little when I first started shopping for LCD's because nothing was above 60hz (and generally still isn't), but then as I got to looking at them in use I noticed none of the old problems, no flicker, no eyestrain, no headaches. the only thing that one might be able to detect as a difference between 60 and 120hz on an LCD (slightly better chance on plasma of TFT) is a little less motion blur on highspeed movement, which incidentally the human eye adds back in to some degree... an effect used to great extent on earlier racing games to trick the eye into thinking you were going faster than the game could render by using blurry low rez scen elements for stationary objects, and even in some cases compressing their length.

that's more than a bit of a stretch... it's much more relevant to say, "Things in off topic are likely to become out of control or embarrassing to LL, so they don't want it exposed to the outside web even by inference" (you know, like huge post counts that don't seem to have huge amounts of posts)

Peggy has the right of it... it's just a comedy of errors. poor placement of camera angles and od proportioning of element of the avatar skeleton lead to large avs, large avs lead to content being built to fit... objects get bigger, land space and ranges stay they same so are smaller in comparison. then you get to the social side where the common avs which rival greek gods and goddesses in stature and their relaisticly measured cousins are at odd's, throw in some accusatory backlash with the help of stupid policy definitions from LL about age play, and McCarthy-esque encouragement to spy on and report your neighbor for any perceived offense. sprinkle with counter backlash against people trying to twist even harmless forms of RP into something sinister, and top with the technical minds pointing out the ridiculous waste, both of physical and inworld resources, as well as pointless drama.... serve to masses of SL users, and observe that it's more entertaining than daytime tv.

::had thought after a day with no replies Roligs suggestion had solved this... if not Cerise's should

then you have most likely run into the "immortal" prim bug.... those items will only likely be able to be removed by either moving them offworld, or from an estate mangers console (if it's an estate region)... otherwise you'll have to wait for a region restart and then they should be removable again

about the only solution is to have box in content that contain different combinations of the separate items to send, then the script choose which combo box to send and sends that to the avatar.... this can get huge fast, especially if multiples of a single item are allowed

do you have the item locked (edit window, object tab)? or set to or deed to the group?

if you get anything below 24in (cross corner) I recommend a 16:10 aspect ration (sometimes listed as 1.6) with a native resolution of 1680x1050, LCD especially if you are moving up from an old 4:3 CRT. the extra width is easier to adjust to, converts HD video seamlessly, and doesn't feel squished top to bottom... they are also much cheaper than many of the other options at that size. you probably won't be able to find the same ratio in larger models... they are almost exclusively 16:9 cinematic (1920x1080, great for movies, not much else IMHO) and can tend to feel kind flat if you are changing up from an old 4:3 CRT. regardless, most of the web is still built for 4:3, and you'll notice a lot more wasted space at the sides, or conversely, REALLY long lines of text, and really short paragraphs. 16:9 is the worst for it. other things to take note of.... most monitors you'll find have a refresh rate of 60hz.... don't bother with anything above that... seriously. and unless you are a rabid high speed gamer (SL does NOT count) then 5ms response time is plenty fast enough (that's 200 times per second)... 2ms monitors are hardcore speed gamers. the things you will care about are contrast ratio and brightness... unfortunately the newer "dynamic" backlit models report ridiculous numbers for these based on maximum an minimum, but can't actually get those values when both are on screen at the same time.. so always look for "effective range" values, or eyeball them yourself. viewing angle is a minor concern, as long as the monitor can be made to face you directly flat from its center you should be fine. ETA: Skip the speakers if you can... they are almost universally tinny crap, even compared to the $20 bargain speakers with a sub-woofer you can get at places like walmart. ETA: I recommend that it have HDMI *and* VGA (sometimes called D-Sub) inputs at a minimum... DVI is dying, almost everything comes with HDMI now (get the cheap cables), and VGA makes it compatible with older computers forever... as an option, check for one that aulse have component video (sometimes listed as RCA) for compatibility with pretty much everything else that was ever made

Thanks for that, it must be redirecting based on IP address or account type or something.

Ciaran, that's not good... previously that had been the only reliable method =/

you forgot a couple, one is really stupid, but withing the realm of possibility.... viewer requests additional memory for threads, beyond what it can address (without checking it's own address space first), the OS grants it, but the viewer is unable to address it, and requests it again... wash rinse repeat. the other is some sort of memory managment being done by the OS transparently, but is unlikely since I don't think there are any of that nature shipped by default, and it's seems insane that it would be enabled for programs that don't understand it. even PAE is smart enough not to option memory extension for a single program beyond the 2Gb limit on 32bit windows

Gadget Portal wrote: Anyone else think LL was aware of this (that technically, SL avatars are not allowed on Facebook), and that it was their way to trying to force a connection between your real Facebook identity (assuming you have one) and your SL avatar? Particularly, for revenue generating, privacy infringing type things? were they aware of it? yes were they tring to connect RL infor to your SL account? not per se... but I'm sure that's how they sold it to FB marketing for putting those stupid buttons on our profiles. what were they really after? Exposure... FB has a huge user base of people with obviously too uch time on their hands... get enough exposure there and you get people showing up here... no rocket science, just a plain attempt at social media marketing. @Ciaran Thanks for the clarification... I avoid FB like the plague it is, so I'm not up on the nuances.... I'm guessing though that means you need an account for a live person to create such a page, thereby linking the two together?

you get an actualy page for that link? because I don't.... the https coulpled with the SL domain automatically shuffles you off to openid, but then it just sits there because there's no such page for it to go to... at least that's what I get. and mind there's no telling if that was the actual link in the e-mail, or just the cover text which the forums autotranslated into a live link

and assuming none of those suggestions help, there is a bug currently with some objects remaining after deletion/take/return... they've been nicknamed "immortal" prims. removing them properly can still be done from the estate manages console (for private estates) or after the region restarts. a few people have had luck moving them offworld, or attaching them (but the latter makes them bugged in inventory, so don't do it to things you care about)

::nods:: that pretty much screams memory leak dunnit

assuming you have access to or wrote the script that goes into the other pesons attachment then as Darkie said... if you don't or can't, then it's up to the person who does or did.... in general commercial scripts are limited to responding to the owner, or if you are lucky the owners objects... although there are some notable exceptions (evil titlers, RLV objects, etc). for commercial items, in general, it's unlikely.