WhiteStar Magic

I use an EVGA NVidia GTX-550-Ti-FBP with 1GB DDR5 attached to a 47" LG LED Screen @ 1920x1080. Works a treat once the contrast & brightness was adjusted (Custom menus on the screen for Game Mode adjusts all that). Compared to my 27" i-inc LCD Monitor @ 1920x1200 it's not quite as sharp but not significant. One thing to note: Don't try to use a Large Screen TV as a monitor by setting it on your desk, you do need to have it a minimum of 60cm from you if not a full metre (yard is close enough). Your eyes will tire and you will get a headache from it, especially if there is a lot of bright colours & white on teh screen.

The only V3 Based viewer I know of (and I fiddle with most of them as I update features & functions related to scripting in them) is Henri Beauchamps Cool VL Viewer which uses a V1 UI (handles Mesh too) but it's under pinnings are V3. V1 codebase is the Edsel of viewer code, dead and never to return, or rather the 1960 Picture Tube TV instead of the 21st centuries LED TV's (sorry digital receiver only). V3 Viewer UI can be moded to be more friendly and yes, Torley needs to seriously do a good series on customizing the UI. It in fact uses less screen real estate that V1 UI and there are certain performance tweaks that Linden Labs has not implemented by default. Like any decent gaming system / platform (and yes, SL is a gaming platform & uses gaming tech to deliver the world to you) decent graphics cards and system are required. Just look at any other good game out there, be it virtual world, WoW or FIFA 2012.

One fine example of a menu system that manipulates prim's with sizing and changing shape etc is "Pipemaker". It's a Freebie, opensource & full perm which you should be able to locate with a quick search in-world. PipeMaker made by Lex Neva who has/had a store in Eldora. Hopefully that will give you a good example template to see how it's done.

I saw this posting earlier today and for curiosity sake have been playing with different viewers on SL & OpenSim and monitoring the ram usage with the various viewers. V1 based viewers are behaving as expected, V3 viewers up to 3.2 codebase seems to be better behaved while V3.3x base is getting nasty. Without a doubt, something is clearly wrong in the V3 codebase as there is one nasty memory leak that is causing this ram use ballooning. It is not really affected by how much or how little inventory you have but it is impacted in so far as how fast it balloons out. 32Bit viewer can only access a maximum of 2GB ram unless it's been made LargeAddressAware which would allow up to 3GB on a 32bit OS (yes it would swap out which is not good). If the viewer is 64Bit on a 64Bit Operating System, it can access all available ram.

Within that Jira I offered a solutionm which hopefully LL will consider... I know... don't say it. LOL but I'll post it here for others to see as well. Hopefully this will stimulate discussion as to viable & workable solutions. My Suggestion Why not simply correct the ONLINE response so that it honours the users choice of "show online status (true/false)" setting. So if a user has elected not to show their online status, OFFLINE is returned, if they elect to show their online status then return the Actual Status. Often the KISS principle being applied is the wisest, simplest & most efficient solution. BENEFITS: It would not break existing content. Does not require the Script Owner / Script Creator validation check. It would not be in violation of Privacy, as a user independently selects whether or not they wish their online status available. (almost all forums software, social sites systems, group-ware system use exactly this process and is a globally accepted practise) Would reduce the Tylenol Consumption required by LL Staff to deal with the fallout & resulting breakages/issues/complaints. CAVEAT ! - The only caveat would be vendors / updater's which check a users status prior to delivering an item. These system owners would need to inform the end user that "if" they have their Online Status Display set not show, they would have to manually get updates or whatever arrangement is devised. This is "inconvenient" but not an outright breakage. EDIT: A mention was made about the overhead of validating online-status-show. Well... one check is less overhead than checking Script-Owner & Script-Creator & Online-Status if passes previous 2 tests. As I have been programming core systems since the ... well too many decades... maybe I just use the "old math" and not the "new-math" when looking at systems. Seriously, KISS the issue and get back to Keeping It Simple S*.

This is in Refrerence to an older JIRA which has come back to life due to TPV Policy Change and the use of "DATA_ONLINE" with regards to avatar privacy. To respect the wishes of Oz Linden this post is started here. From that Jira https://jira.secondlife.com/browse/SVC-4823 QUOTE "Oz Linden added a comment - 29/Feb/12 8:52 PM Ideally, we would like to adjust things so that it's possible for scripted object deliveries to be reliable even when the recipient is off line, removing the need for this check altogether. However, it's too soon for us to be talking about possible approaches; watch the Forum (and let's not use this issue as one)." END-QUOTE

With regards to ONLINE STATUS, LL has been offered various options but a common answer that can be seen in Jira's is similar to what I also suggested that LL could implement. There was some comment made that it would create more load to the servers but it's hard to fathom how a single field check versus 3 (what they want to do) would add additional load... but LL uses the "new math" & wrote the software so who knows.... I suggested in Jira:SVC-4823 Why not simply correct the ONLINE response so that it honours the users choice of "show online status (true/false)" setting. So if a user has elected not to show their online status, OFFLINE is returned, if they elect to show their online status then return the Actual Status. Often the KISS principle being applied is the wisest, simplest & most efficient solution. BENEFITS: It would not break existing content. Does not require the Script Owner / Script Creator validation check. It would not be in violation of Privacy, as a user independently selects whether or not they wish their online status available. (almost all forums software, social sites systems, group-ware system use exactly this process and is a globally accepted practise) Would reduce the Tylenol Consumption required by LL Staff to deal with the fallout & resulting breakages/issues/complaints. CAVEAT ! - The only caveat would be vendors / updater's which check a users status prior to delivering an item. These system owners would need to inform the end user that "if" they have their Online Status Display set not show, they would have to manually get updates or whatever arrangement is devised. This is "inconvenient" but not an outright breakage. Seriously, KISS the issue and get back to Keeping It Simple S*.

LL (Oz I believe) proffered the idea that doing a Script Creator/Owner check prior to getting agent data and so on.... so it would allow only scripts created/owned by an avatar to get the avatars online status, that would definitely add more checks on the server than to simply honour the user setting which is a single check against the field in the database. Anyways, it's been filed into JIRA SVC-4823 and hopefully LL will take the facepalm well and just fix it with the KISS principle.

Linden Labs has NOT considered teh most obvious & simplest solution to this.... Why not simply correct the ONLINE response so that it honours the users choice of "show online status (true/false)" setting. So if a user has elected not to show their online status, OFFLINE is returned, if they elect to show their online status then return the Actual Status. Often the KISS principle being applied is the wisest, simplest & most efficient solution. BENEFITS: It would not break existing content. Does not require the Script Owner / Script Creator validation check. It would not be in violation of Privacy, as a user independently selects whether or not they wish their online status available. (almost all forums software, social sites systems, group-ware system use exactly this process and is a globally accepted practise) Would reduce the Tylenol Consumption required by LL Staff to deal with the fallout & resulting breakages/issues/complaints. CAVEAT ! - The only caveat would be vendors / updater's which check a users status prior to delivering an item. These system owners would need to inform the end user that "if" they have their Online Status Display set not show, they would have to manually get updates or whatever arrangement is devised. This is "inconvenient" but not an outright breakage. Seriously, KISS the issue and get back to Keeping It Simple S*.

Marvelous hijacking of a thread... too bad I can't lock it as it's become pretty well useless for it's original intent now.... On the FIRST POST it was written " Please let's not turn this into a Drama Post, it is intended to help people locate and reference what the TPV developer's are thinking & saying." in bold so it would be noticed but I guess it doesn't apply to those who don't care.  Why not just start your own msg thread ? Too simple I suppose.

I'd like to clarify something on my part in this discussion. I have nothing against any TPV viewer, including Phoenix / Firestorm or any other for that matter. I like everyone else has certain preferred viewers but that is not the issue either. The only obvious exception are those which are modified for nefarious activities, such as copybot use. I only used the Multiple attachment points issue from the old Emerald viewer as an example which demonstrates what the policy change is partially trying to prevent.

" I think it's more likely to affect things like the Emerald-specific attachment points and other tricks that don't look right in viewers that don't implement that same hack. If I'm correct on this, then I'm thankful for that clause." Your on the right track there Baloo. It is all about not adding something to one viewer / viewer family that will affect how things are seen by other viewers without that particular "enhancement" and the attachment example is a perfect example of what is good for one but messes up another. Whether or not a viewer supports an extra function or capability that would have no negative effect on the users of another viewer, as an example, Imprudence supports the LightShare capabilities in OpenSim but supporting that capability has absolutely no impact on SL Grid or any other viewers in use on any grid. I guess one way to put that, is that is is a "neutral capability & function", meaning that it does not adversely affect any other.

This Post is for TPV Developer's to chime in for links to their forums/wiki's where they make a statement of what their take is on the new TPV Policy. Please let's not turn this into a Drama Post, it is intended to help people locate and reference what the TPV developer's are thinking & saying. For an excellent "Drama Free" clear & concise review of what the TPV Policy means to TPV Developer Henri Beauchamps of Cool VL Viewer who wrote up an excellent review. It's without postulation & theories, just simply the facts. see his take on it here: http://sldev.free.fr/forum/viewtopic.php?f=5&t=741  

Linden Labs is making the argument of going to OpenSimulator stronger & stronger as time goes on..... SecondLife is "Their World" not anything like they used to promote as "Your World". The poorly worded and potentially regressive policies need to be better thought out & presented.

I just processed it through NotePad++ and then LSLeditor (new version) and debugged it enough to get it running, wasn't going to spend a lot of time on it. All those "highlighter's" might be OK but if LL was serious, they'd just install GeSHi and the problem would be solved. I maintain the GeSHi LSL Syntax Highlighting, as well as Notepad++ and a couple of others. The link to Cerise's LSL posting tool won't open.