Nalates Urriah

Your problems are typical of a problem connection. Run through the article Troubleshoot Your #SL Connection to elminate your connection as a problem. Simple speed tests and pings may not reveal a problem.

nVidia does most of their benchmarking for DirectX games. OpenGL can run as well as DirectX and according to some benchmarks and tests even faster in some cases. HOWEVER, SL does not take advantage of all the neat OpenGL tricks and runs at a rather low FPS. The nVidia card will give the precent of increase they claim in DirectX games. It won't in SL. The next biggest performance improvement you can make is to put in the fastest memory chips your system can use. My GTX560 Ti blasts some benchmarks along at 1,000 FPS but only runs the SL Release viewer at 25-35 FPS on High.

I disagree with Echo. Your bandwidth will have some affect on your FPS but not much. Anything over 1mb/sec and your going to have all the FPS that you can get from connection performance. Once the area's textures are cached and your system is no longer decompressing textures you should see your pure render speed. Slow internet connections generally appear as sluggish mouse and arrow-key response (high PING). Poor Internet connections with lost packets create problems that can slow down the FPS as CPU is diverted to handle error corretions and repeated attemps to decompress corrupted textures. If you are going to test your connection see: Troubleshoot Your #SL Connection

Looking at the snap of the computer performance screen, the computer is not that bad. Generally 5.8. However the graphics card sucks and is what holds the machine to a performance rating of 3.4. Get a new graphics card off eBay and you should see a big improvment. If it is a laptop, you are probably screwed. The Core2 CPU you have is gettnig old. But you could probably put a Core2 Quad 3.2ghz CPU in the board. Tha too would help. You'll have to look up the specs on your mother board to find out for sure. Use the free program CPU-Z to get the motherboard information. If you decide to go with a new computer be sure to 4gb or more of memory and the fastest memory the motherboard will handle. For Second Life you can get by with a moderate graphics card, preferably nVidia as nVidia works better with SL. nVidia 400's are cheap in eBay and 500's are coming down now that the 600's are out. The new i3 and i5 Intel CPU's are OK but the i3 is more for video than games. The i7 is the best for games. The i5 is in between. Other games are more dependent on the graphics card than SL is. A big step up in graphics card doesn't give you a big step in SL performance. The memory, CPU, and graphics card combnation ALL affects SL's preformance. They all need to upgrade to really help performance.

Dilbert has given you a good idea for troubleshooting. I suggest you run the SL Viewer then check the log to be sure the latest crash log is in the location he gave you. Check that your computer meets the System Requirements | Second Life. Try this site to see if you can run SL. This is not perfect, but it should give you and idea. Can I Run Second Life? Before logging in, open Preferences and set the Graphics to LOW. If that allows you to login, the viewer may be failing to correctly recognize your computer and graphics setup. If you are on a laptop, make sure the unit is actually enabling the graphics card for the SL Viewer. Many laptops do not recognize SL as a graphics intense program and turn off the on board graphics to save power, You can change your graphics settings on a per-program-basis. Set the SL Viewer use the Perfromance settings.

Technically it is possible. However, the Lab is not going to allow it. Since they control access to the servers providing backend services, it is unlikely that control can be circumvented. One of the main problems with allowing third party servers is protection of IP rights. That problem makes it very hard in the OpenSim worlds to protect IP rights. All items move through the region servers and can be ripped off by the one controlling the server. One of the big lag producers is the amount of cross communication between regions and users. Moving a server out of the main data centers would greatly increase packet travel time region to region. The Lab recently arranged adjacent regions to run in physically adjacent servers. That probably only changed packet travel time by a few milliseconds. But, it was enough to provide a significant performance improvement. Packet travel time in the data center is likely less than 10ms and probably 1 to 3 ms. Moving to an outside server would increase that time to 30 to 100 ms, which would be a huge hit.

Ask? Sorry, couldn't resist. -- There are animations for both avatars. You will find them in sex HUD's (which you wear), beds, rugs, chairs, and other items. The items like sex beds produce a menu when clicked. There are usually groups of ...activities. Male/Female, Male/Male, 3-way MMF/FFM, etc. Within those groups positions; missionary, cowgirl, etc. When one is selected two balls appear, pink and blue for girl and guy. Depending on how they were made right-clicking them will give you a menu offering a SIT option. The option may be re-lableled to whatever the maker wanted; love, use, animate, etc. Whatever label is used it will appear in the position where SIT usually appears. Select the option. Once your avatar SIT's you will get a menu asking for permission to animate your avatar. Grant permission. These steps get the avatars animated. There are addon genitals for the avatars. There is a large selection from free to expensive. The complexity ranges from simple to way complex. Some simply control the gentials and adjust appearance. Others interact with your partners controls. Some allow detection of others wearing similar sex HUD's or genitals. Good luck.

Getting things to rotate once is not a problem. If the function is to keep the rotated object looking in the set direction, then it makes sense. I'll experiement with manually moving things and see if they come back. EDIT:--------- Making something physical and then moving it around, the function keeps it facing the direction supplied. I was not able to rotate the object without editing it. The object would come back to the LookAt direction once I left Edit mode. Turning off llRotLookAt with a SoptLookAt I could rotate the object by kicking it. Otherwise kicking it just slides the object and never lets it rotate. Thanks for the tip.

I've been reading and changing the Wiki's description of this function. Right now I am having a problem sorting out when the function actually causes an object to continue watching an object... I can't see that it does... or even could. Use of StopLookAt seems to be a pointless reference in the description. Am I missing something?

Ayesha, you give every impression of being one that feels they are entitled to have Linden programmers explaining things to your idea of acceptable communication. I tend to think a reasonable person would have figured out the programmers are busy programming and will only ever give communication a secondary priority. Whether you live in a nanny state or not is moot. Your continuing critique of what the Lab should do seems to reveal a desire to have the Lindens take care of you to the standards you want... nannies take care of people. So, I see that as a desire for a nanny state of being on your part. I seldom get any special information from the Lab. The information I report is available to anyone. The Lab has NOT made it easy to find, but a huge majority just don't care. So, the effort at communication is probably in balance with the interest of users. This update thread on Deploys is handy. But, one can know what has happened and what is likely to happen next week by attending Friday's Server/Scripting meeting. That takes an hour a week. Or one can read my blog. But, you get the news when I get around to writing it up. I've been running a network monitor the last few days and preparing to see if SVC-8124 in Magnum makes a difference. While several people I trust to avoid Chicken-Little-reactions tell me it is a significant problem, I had to go looking for it. I live near the SW corner of a region. I haven't seen the HUGE problem in the regions I've explored except in the Viewer Statistics. My monitor shows only about 12% of what the stats panel is showing. Searching I have found a couple of places where the Viewer Stats show bandwidth spiking but the monitor shows a much smaller increase. Checking in regions in the Magnum area is hard to do. Figuring out where they are, other than the sandboxes, is tedious. Later today I'll be crusing through those again later today and tomorrow.

You may notice (later obviously) that the Build Panel maintains relative position with the top and left edges of the viewer's window. The right and bottom edges seem to adjust the position of the panel to a percentage of screen location. But, once the Build Panel goes behind a window edge, the panel seems to stick to the edge. Changing the screen into Edit Mode by editing a HUD does not affect the position of the Build Panel. Since the viewer remembers the last location of a panel and reopens it in the same position, that information has to be saved somewhere. Since it doesn't make sense to save panel position data that is never shared on the SL servers, it is not going to be in the cache. So, don't be clearning your cache unless you know you have something in the cache that is corrupted, which is almost never, if you use the LL and Firestorm viewers. Other viewers that use the open source JPRG2000 library, depending on version, may corrupt a small number of texture files. A quick search of the main program's folder shows nothing is being updated there. You can use 'date: >7/26/2012' in Windows search to check. Use your latest install date in place of: 7/26/2012. Or just sort on Date Modified. I find that window positions are saved in the settings_per_account.xml file in C:\Users\[win_login_id]\AppData\Roaming\SecondLife\[avatar_name]\ You can delete the file and the viewer will rebuild it... using all the default settings. That will save you a reinstall. Or... you can edit the XML file, if you are comfortable with that. XML is text and not TOO HARD to figure out. You'll be looking for: <key>floater_pos_build_x</key> and <key>floater_pos_build_y</key>. The values are in percent of screen, I think.

Any significant change goes through QA. Late last week a couple of Lindens said they thought they had found the problem. With luck the fix will come out on Magnum. We'll know tomorrow.

You should probably look through Inara Pey's and my blogs and catch up on what has been happening.

nVidia will eventually get CUDA optimized for the 600 series. For now it seems the 500 series is a better choice for Blender. Thanks for your input and measurements.

One of the residents, Nala Spires, did a bunch of benchmarks to see what hardware was having the most impact on performance. The biggest impact is fast memory chips on the motherboard. The limit on memory chip speed is the motherboard. So, one can only go so far with that upgrade before one is into serious upgrade. You can read my summary of the tests here: Viewer Performance

Everyone playing SL made an agreement with the Lab. If you want to change that agreement both sides have to be willing to make a change and negotiate a new agreement. That is the free market, which is already over regulated and not so free. In a free market it is the job of government to prevent extortion, monopolies, false advertising, and other misrepresentations and things society considers criminal. In socialist governments and controlled markets the governments force people and business to do things. Neither side gets to negotiate. It becomes a matter of how many people can influence the politician... or even worse what the politician's person belief is that gets imposed on everyone. The result is less freedom, innovation, prosperity and more government control and poverty. The Lab is not falsely advertising in this case because the high bandwidth is a mistake and in law this problem is treated mostly as an accident. The Liability of a car maker is not comparable because the laws governing the manufacture of cars and the maker's liability have been defined differently and can result in the loss of life. Whatever the case the losses in regard to this problem are so small no one can afford to pursue the matter. So the legal side essentially moot. Those people that did not pay attention to their bandwidth use are going to be stuck paying for their negligence and having agreed to the SL ToS. That people want some third party, like the government, to come in and regulate for their benefit so they can remain negligent after they made an agreement is partially what the nanny state is about. It seems some think the government or regulation could somehow prevent mistakes. Several people here would prefer someone make the Lab do something. The Lab will live up to their agreement. At least they won't be in the forum crying about having to live up to their side of the areement. Several seem to think this screw up is a deliberate act of the Lab to increase bandwidth use. But, as pointed out in one post, this mistake is costing the Lab too. So, the idea it is deliberate I’ll attribute to clueless people being frustrated. I think the thread has made it very clear which people want to place all responsibility on the Lab and lack any empathy for mistakes. I find it interesting how many people see no responsibility to live up to the agreements they have made and want changes forced on others for their personal benefit.

The Lindens are speaking. I've been in two meetings where they were talking about the issue and when they thought they would have it fixed.

The announcement by the Lab is here: Materials System Oz has created a JIRA for the development process and bug reporting. Discussion should occur in the forum, preferably here in the Building and Texturing section. JIRA: Add support for Normal & Specular Maps - STORM-1905 Feature requests should be entered as separate JIRA items in the VWR (Viewer) Project. Oz has recommended you add feature requests in the forum before making a JIRA request. Some threads on normal maps have started in the Mesh section. Those may get moved to here, I suppose it depends on how busy the forum mods are. Oz advises that this first pass is not likely to see many feature requests picked up. They will more likely be additions and fixes in the second pass. So, patience... Information is from the 8/20 Open Source meeting.

They think they have found the problem. The fix is likely to go into one of the release channels next Wednesday (8/22). If things go well it will roll to the main grid 8/29. Responsibility... well read the ToS... When you sign up for a capped service it is up to you to monitor your usage. That you haven't and have gotten comfortable your usage was within acceptable parameters and would remain so does not shift responsibility or liability. There is no doubt the Lab will have to fix the problem. Nor any doubt they created problem and it surprised you. But, you are still the one in the end that is going to have to pay the bill and/or suffer reduced service. The ToS protects the Lab. They would only have to pay if you can prove they were negligant or willfully and knowingly caused the problem. That they made a mistake does not negate the ToS. While Cincia uses the word 'blame' and upsets you, Cincia is technically right. I suspect if a court were deciding the issue you would be much more at risk of being found negligent than the Lab. The Lab made a mistake. You weren't paying attention. What you do next determines if you are part of the entitlement generation, that needs nanny state or someone to take of them, or have accepted responsibility for yourself and actions... or lack of them.

One of my friends made a chat for Second Life Viewers. See: https://sites.google.com/site/lakebottomlab/home/httpsdocsgooglecomspreadsheetpubhlen_ushlen_uskey0aqlm_uw5nfqidgxmu3z5tjdkwhp6cmfnz0zoml8wyleoutputhtml I think it is more work than he expected. So, it is getting out of date. The viewers have over 3,000 controls and probably a 1,000 features. A viewer comparision matrix would be enormous. If your intersted in the history of viewers, visit my blog (link at bottom) and click VIEWERS in the menu. Once up on a time we got new features and significant bug fixes in Third Party Viewers. The Lab lagged advancing the viewer. There was debacle with the Lab's Viewer 2.0. The Lab assigned a new team and way of doing things after that. Since then the Lab's viewer leads in most new code. The last couple of years viewer developers have been catching up with the Linden viewer. It is just now reaching the point that TPV Dev's can get ahead of the Lab.

Thanks for making the measurements. I find that type of testing too tedious, so I very much appreciate your effort. You have been blogged: Viewer Performance

Doh! Thanks

Is this function working for anyone? I have a script running using: llPatrolPoints(patPoints, [ ]); If I add the PATROL_PAUSE_AT_WAYPOINTS option to use: llPatrolPoints(patPoints, [ PATROL_PAUSE_AT_WAYPOINTS]); I get an error: Error at option 0( list element 1): Expected 1 parameters but found none. I only see a JIRA for the feature request. Is it me or the function? Thx

Echo's consolidated cube is named a coalesced object in SL. You can read about them in the Knowledge Base. Separate unlinked objects can be selected and taken into inventory. The go in as a coalesced object. The can be rezzed by dragging them to the ground. Coalesced objects are named whatever the last object selected is named. So, it is common to select a group things to save then shift-left-click to deselect a named object and thenonce more to reslect it so it is the last item selected. That gives the group the name of the last object. Coalesced objects gets builders around the link limits.

A single prim can be as large as 64x64x64 meters and as small as 0.01x0.1,0.1m, with ways to make them appear even smaller, nano-prims. A prim texture can be tiled or stretched so an image does not repeat, appearing only once. The settings for those features are on the Texture tab in the build panel. GIMP is a free image editing tool that is a good no cost substitute for Photoshop. Paint.net is another good free tool. You can build a single 1024x1024 image for use on a large prim. Anything larger gets resized on upload. If you want the image to be sharp use a PING or TARGA format for the image. A JPG image is compressed when saved out of the editing program. It is again compressed on upload, futher degrading it. All images are compressed to JPEG2000 format. Image sizes other than power of 2 sizes like; 64x64, 128x128, 256x256, and 1024x1024 are resized to power of 2 sizes. I think a 128x1024 avoids being resized... Doing anything else results in images of lower quality.