Nalates Urriah

In many cases it is not the viewer or plugin that triggers that error. The video or media you are trying to watch or hear may be the problem, in which case you can't fix it. The one that made the media must fix it. There is a lot of old media in SL that just doesn't work now that we have moved on to CEF. If you have the error with ALL media... it may be a viewer problem. Typically when you ask a tech question we need the info from HELP->ABOUT... and a good description of the problem, what you did to pop the error message, the text of the message, in your case where the media is, and what it is.

Rolig is telling you a bit about etiquette in SL. In general we ask if we may 'friend' a person before sending a friend request. Also, there are levels of friendship. In the first level they can tell when you are online by default. You can however retain the friend and turn off the 'now online notification'. You can enable MAP (off by default), which means they can click your name in the Friends List and find you on the World Map. You can share your stuff with them (also off by default)... they can Edit, Delete, or Take items you own... like being married or in SL partners. To change the friend's permissions used to be easy. Now you must open their Profile, select SETTINGS, select PERMISSIONS and then grant or deny the permissions. Way too many clicks. Firestorm Viewer has the old style method with permissions in columns in the People/Contacts panel. One only need open the panel, find the name, and then click the permissions to enable or disable. Much easier. So, you can see there are more aspects to offering friendship in SL. We give friending much more consideration than we do on Facebook, Twitter, FLickr, etc...

Are you for real? What religion has believers that think a character in a computer can take their soul? Troll...

Support will get you fixed up. A new interesting feature of ADITI is inventory sync. Your main grid (AGNI) inventory gets copied to ADITI and then each morning after a login it gets sync'd, adding main grid inventory changes. I now use folders starting with ADITI for everything I add while in the Aditi grid. Makes it easier for me to clean out old AGNI stuff... as what I delete in AGNI does not seem to delete in ADITI.

Check the size of your main viewer cache. Larger is better. Firestorm and Linden have a default cache size of 512MB. I use a 4GB ram drive to house my Linden cache, it is full. Scene render is fast once an area as rendered an been cached. But, I do get some cache thrashing. With FS I use a larger SSD drive and a cache size of 9GB which currently has 7GB in it. As it isn't full, it is almost as responsive as the ram drive. If you have not increased your cache size... give that a try.

Annika, Rolig is right about connection issues often being the problem... even the primary cause. But, connection issues are not the only cause. So, make sure your connection to the SL servers is good. Having a good Internet connection does not mean you have a good connection to the SL servers. Having a good connection to one SL server does not mean you have the same quality connection to all SL servers. Generally if you are good to one you are good to all so, don't over test until you are REALLY desperate. When you next TP leave the viewer stats panel open. Watch your Packet Loss numbers. Another cause of TP problems is the number of scripts and attachments you are wearing. Scripts are the usual problem. If you have a lot of scripts using a lot of memory you likely will have TP problems. Firestorm has a built in script counter and you can get free ones in the marketplace. Most consider 3MB the limit not to exceed. Less is better. High ACI can be a problem, but it has to be REALLY REALLY high. Like >900k but, depending on your computer and connection possibly lower. So, what you are wearing can be a problem but, it is more likely the scripts in what you are wearing. If you have changed your ACI to UNLMTED (Jelly Dolls) change that. If you crash in only some places, there may be some item too complex for your video card. Griefers like to scatter those things around to crash users.

I suspect both of those HUD's are pretty well made, at least texture-wise. I do find that my Slink body and hands HUD's add a lot of scripts. So, I tend to remove them until I need them. So, I have links to them in an easy to access folder.

In 2016 Android held 86.2 percent of the market, iPhone 12.9 percent. (per Gartner Research) Best reason is economics. I think the second reason is the Android world is seriously into VR and 3D rendering. Apple has stuck to 2D gaming and generally provides weaker 3D game rendering across all their devices at a high cost. That translates to better Android support for developers.

When you ask a technical question, click the viewer's HELP->ABOUT... and copy that information to paste in with your question. You'll get better answers. You may notice some refer to RLV and others to RLVa. These are slightly different versions of the same thing. It rarely makes a difference which you use. A number of viewers support RLV, but as pointed out, not the Linden made viewer which you get by default. Some of those viewer brands have RLV enabled by default, some have it disabled by default. So, you have to find the setting and check. As Lindal points out, you also will need a "RELAY". This is a device that catches script commands and passes them to the viewer. A relay can be in a HUD or in an attachment you wear on the avatar, most often a collar. There are plenty of free, good relays. Some of the retail versions have more features or are more fashionable. But, the basic, free relay has everything you need. But, relays do have to be turned on. RLV can be complex. There is an advanced level. To learn more see: RLV Tutorials. Setting up RLV and mesh bodies can be complicated... You may want to use a classic body avatar while you learn.

Yours is similar to the problem discussed here: In your case the textures have been completely discarded and the reload is taking so long the video card has to skip rendering the texture until it can be loaded. So, you see gray. The solution is the same as dissed there.

What you are seeing is called "Texture Thrashing". Whirly is pointing out it is video memory related. Thrashing is caused by your viewer needing to render more textures than your video card/memory can hold. So, it discards rendered textures to load textures it has yet to render. When the viewer renders the next frame the discarded textures have to be reloaded. Textures first load at low-resolution then progress to higher-rez. So, you see blurry, then nice and crisp, then blurry, crisp, blurry, crisp... That load, discard sequence is the thrash. A couple of things can eat up video memory, large textures (as Whirly said), lots of textures, limited video memory (HD Graphics infamous), and having a lot of groups open while using the tiny profile pictures... if that is the cause, a relog will stop the thrashing. Eventually it starts up again and another relog will fix it for a time. The relog empties video memory. Some HUD's will trigger the problem because they use a number of large textures. Take off your HUD's and see if it makes a difference. You may find one HUD that pushes you over the edge and starts thrashing. If you are on a newer operating system, Win 7, 8, 10... you likely are 64-bit. If you have a video card (not HD Graphics) a change to the 64-bit viewer will likely eliminate thrashing. With HD Graphics adding more system memory can reduce the problem. In desktops upgrading the video card can reduce the problem. I have a GTX 1060 with 6GB of dedicated VRAM and there are places where I'll see it start thrashing. In a world where people make stuff without understanding the tech we will probably never eliminate the problem. But, you can manage it.

There is a huge array of equipment between you and the SL servers. The problem may be there. You can use the information here to decide: http://blog.nalates.net/2011/10/26/troubleshoot-your-sl-connection/ Consider whether your computer is slowing down, all Internet related tasks, or just SL. Malware in the computer may slow down Internet related tasks. Restart the computer, you probably have, and restart your router/gateway. If you are running wireless, try a wire. Any changes within the area a wireless router servers can make a difference. New LED or Fluorescent lights can make a difference. Moved furniture can change a white less connection too. the 5MHz wireless signals are very sensitive things in the line-of-sight path between the computer and router. That is what the COX commercial about 'Panoramic' wi-fi is about. (Buy this new thing that has problems with walls and furniture... that is a feature...) Neighbors can buy new devices that use the same wi-fi channel. New appliances may use a wi-fi channel. DSL is usually consistent. Cable not so much. Both can change if the provider has worked on things. Cable will change depending on the time of day and what neighbors are doing. You'll have to do some testing to figure out what is slowing you down.

Well... in Second Life we have more options...

I dug through Firestorm this morning. There is no RESTART. You say you often RESTART the scripts by clicking RESTART... All the buttons you can click that I find are reSET. So, I am left wondering if you are running Firestorm in English or another language and that is where we are having a miscommunication. Whatever the buttons are labeled, the code behind them does the same thing: RESET. (http://wiki.secondlife.com/wiki/LlResetScript) To protect textures from theft, Slink saves the UUID in script memory. HUD's and various other scripts use similar tricks. Those that do will be killed by a reset. The script has NOT stopped working, it just cannot accomplish what it is supposed to and appears to do nothing. A script telling an object to switch to the NULL texture is not an error, so no error notice. The object can't switch to a NULL texture so it quietly does nothing. We have tens of thousands of people using Firestorm, the same AO's, the same HUD's, the same whatever... and not having this problem. So, the problem must be in your computer or your actions. If the rest of your computer is working normally, that pretty well eliminates it. That leaves your behavior/actions. Lag contributes to people thinking something is wrong and taking action to correct a non-existent problem, which then creates a problem. Lag may initially cause you to think you have a non-responsive HUD. Clicking RESET does nothing to remedy lag. What may happen is you click a HUD control. The viewer sends that instruction to the SL servers. Commands and status information for SL is transmitted via UDP, a quick simple protocol that has no error correction or resend features. The command can get lost and never get there. Most likely it is slow getting there. The server may be lagging to add to the problem or not. The status update that changes the render in your viewer may get lost coming back to you or more likely just be slow. By, slow I mean seconds. SL will struggle to maintain a connection and may do so even when lag is intermittently reaching 10 seconds. If you have clicked reSET before the update gets to you, the result is unpredictable. Your render may change and appear related to the reset-click only because they happen at the same time on your viewer. But, they are unrelated because of the lag. The render update is triggered by a click happening seconds before and you clicked just as it arrived. So, it appears the later click did the trick... and you mentally connect them for a rational reason. I suggest you change your thinking. It would be extremely unlikely that you are the only one experiencing a slow moving contagion of HUD deaths. Get a working HUD, AO, whatever. Assume it will remain working and something else is getting in its way. Leave the HUD or AO alone. Or may be change regions and attach and detach the HUD/AO. Bur do NOT reSET the HUD or AO. I suggest you contact the one that made the device and talk to them to see if the device can be reset without killing it. Other wise, just don't. With Firestorm I have noticed the built in AO coming on randomly and messing up my worn AO. I doubt the FS AO is turning itself on. A bad set of key presses or a missed click is the more likely cause. But, I didn't notice what I did to turn it on, so the FS AO appears to be self starting. If you have AO conflicts, your AO will often appear to have stopped working. FS has RLV. I have no idea how many times I have had to log off FS and relog with a Linden or other viewer to fix something. RLV often blocks a HUD's actions. For that reason a number of RLV players I know buy and wear clothes that do NOT require alpha layers. Once they are captured HUD's may not work and having parts of a mesh body alpha'd-out is a mood killer. To get things cleaned up after an RLV session can be a pain. Check your viewer's RLV setting. Taking off a RLV Relay won't clear the blocks it has put in place. You may have to remove it and relog. All this stuff, HUD's, AO's, etc., works. But, there are a ton of gotchas. You just have to find which one is biting you.

You get a Calling Card when you friend someone or they give you one. So, they can generally be said to only show people you have met.

I'll point out, it is not likely to ever work. A VPN (virtual private network) is typically used to go from one secure location to another. Setup is required on both ends. As an SL user you can only control one end of the network. AFAIK, the Lab does not offer a VPN connection.

You say "restarting", but there isn't a "restart" option. You can set a script to NOT RUNNING or RUNNING. Getting to those controls on a no-mod script is VERY tricky. If you recompiled or reset, you likely broke the script. So, avoid doing those. You will need a new HUD. I know Slink provides a 're-delivery' terminal so people can get new copies of what they have purchased. I suspect most others do the same. Because of the way Appliers work, a RESET or RECOMPILE generally kills them. Some HUD's are similar. What they are doing is holding a bit of information in memory. You can detach a script and it will retain its memory. Doing anything that clears that hidden bit of information from memory permanently breaks the Applier/HUD. There is no way to repair it. Get a new one. This is why copies are important. If a HUD does not work, it often is the region you are in. If you log into a place where you cannot run scripts, a number of HUD's will never start even after TP/region change. A relog or remove and attach sequence in a place where you can run scripts is needed to wake them up. I generally log into my 'home' to avoid that problem. Rolig is right on with the removing scripts point. I keep a 'master' copy of my mesh body and use a 'working' copy of the body to wear. The same with the HUD. I can always make a new copy from the master and try it to see if my everyday copy is broken. But, I have seen nothing that kills HUD's or Appliers... other than users. Well, upgrades. Using the wrong HUD with the a different version body is a problem. So... while you may be convinced the HUD is dead, if you haven't RESET it, the problem is likely elsewhere.

Many people think disabling Pathfinding turns it off. It doesn't. It is very much like setting a region to No-Rez. No one can rez new prims. But, all existing prims still render. Nothing the server does changed. User 'permissions' changed. Pathfinding scripts in objects will not run. Otherwise, all the server side Pathfinding is still in place.

Contact the maker of the hoodie. There are usually note cards with these items that tell you how to modify things. It sounds like it is no-mod... Drag the item from inventory to the ground. Right-click and edit it. Look on the General tab to see what your permissions are. To return it to inventory, right-click and select TAKE.

How many different items have you tried to open?

Inventory is a duel system, in that your viewer maintains a list of your inventory items. The Lab maintains the primary list of your inventory items. At logon your viewer downloads the list from the SL servers. Through the rest of the session that downloaded list is used by the viewer. If a connection issue interrupts the download you have an incomplete list. You can sometimes get the download to restart by using inventory search. The old process for fixing inventory was to type 'a' in inventory search. Once that search completes type 'b'... and so on until you have your inventory reloaded. Logging into a busy server can cause problems with the list download. Try a logging into a deserted (no people) region. Teleporting shortly after login can interrupt the download. Having a large number of items in a single folder can cause problems. The inventory list downloads as a series of folder downloads. If a single folder takes too long, the download process can fail and possibly block login. - A large number of items is about 5,000 items in a single folder. But, the number depends on computer and connection speed. Also, the inventory list is kept in a file on your computer. A viewer crash can create problems. The file can become corrupted in such a case and some parts of the viewer may not close. A computer reboot may correct the problem. If the file actually is corrupted, you can delete it. The viewer will start and rebuild the list with a clean download. THIS IS NOT a CACHE CLEAR. Clearing the cache doesn't necessarily delete the list file. In Windows the inventory file is in: C:\Users\[Win_Login_ID]\AppData\Local\SecondLife\ unless you have moved your cache. The files making up the list are named with avatar UUID and end in .inv.gz. Good luck.

Firestorm 5.0.1 is Bento capable. The current Linden viewer has some minor features that Firestorm does not. Everything needed by Ivy is in FS. As Ivy is using 5.0.1 and it isn't working. It works for others. So, the problem is likely the video card or driver. With AMD the latest driver is not always the best for SL. So, it is common practice to roll back the video driver to one that worked. People search this form for their video model and see what the latest is from those using it.

Just now (early 2017) we are in a bit of a transition in clothes making, at least tutorial-wise. The basic avatar, known as Classic, was the primary avatar targeted for clothes and accessories. Sculpties (unique to SL) were the only means of making somewhat fitted clothes that attached to the avatar. Prior to that everything was ‘System’ clothes, those made by opening the Appearance panel in the viewer and creating a new skin, shirt, pants, etc. At that time clothes making was a matter of making a texture based on the ‘clothing templates’ (Chip Midnight & Robin Woods templates) to add to the new shirt or whatever. There are years of tutorials on making ‘System’ or ‘Classic’ clothes. Any tutorial before 2013 is generally about making Classic clothes. From 2013 to 2014+ mesh clothes were possible. This is when a ‘mesh primitive’ type was added to SL. The idea was ‘things’ not clothes would be made from the new mesh prims. But, users made mostly clothes from mesh prims. All prims (e.g., cube, sphere, etc.) except mesh prims are built into the viewer. We build mesh prims in Blender or 3D Max or Maya then import them into SL. This was a significant change. Look at pre-2013 images of SL and compare them to now. Users figured out work-around methods for making mesh clothes work with the Classic avatar. The methods were less than satisfactory as the clothes would not fit well. You mostly had to adjust the shape of your avatar to fit the clothes rather than buying clothes that fir your shape. The Lab finally helped out when users went from simple rigged mesh clothes to Liquid mesh clothes. The avatar was changed so that clothes could use shape information to adapt to the avatar’s shape. New bones were added to the Classic Avatar. After this change designers and users started using more mesh, actually replacing the Classic avatar with Fitted Mesh bodies. The new bodies cover the Classic avatar. We usually add an alpha mask to the Classic body to completely hide it. I use a Classic head and a Mesh body. Starting in early 2014 Fitted Mesh was officially released. Tutorials for making fitted mesh are on YouTube and Vimeo. These clothes change size as you adjust body shape. In late 2016 Project Bento was released. The project did not change clothes making. But, the tutorials and tools used to make clothing are changing. There are not many tutorials post Bento release as the Blender tool, AvaStar RC6, is quickly changing. Plus, Blender changes too. So, most Fitted Mesh tutorials are for older versions, which are a pain for those watching them to adapt to the new User Interface (UI). But, I expect we will see many of them updated this year. So, where do you start? I suggest you make a Classic T-shirt just to easily get that process and the basics behind you. The information learned is pretty much what you need for making Applier clothes. In Classic Clothes making we open Appearance and make a shirt and add a texture (Diffuse Layer) in the new shirt dialog panel. When worn, the shirt appears on the Classic Avatar Body. To place a shirt on the Fitted Mesh bodies we use an APPLIER in place of a built-in viewer panel. An Applier is a HUD we make using the body-maker’s-scripts and a texture we make. Applier clothes are usually tattoos, skins, underwear, and stockings. These are the Fitted Mesh counterpart of Classic/System clothes. There are scripts from each mesh body maker and the Omega system that tries to work with all the different brands. See: Second Life: Stockings – Classic & Slink Attached clothes are now modeled in third-party modeling programs like Blender. These are made for SL just as they are for any other game. We do have to specifically model for the bones used in the System/Classic SL avatar. This means generic tutorials for making clothes are useable in a basic way. The specific information for rigging the clothes to the SL avatar are unique to SL. However, the tutorials since say mid 2014 while out of date UI-wise are correct as to which bones to rig to and how. Mesh body makers provide Developer Kits for their products. You can get those from the makers. They are usually free. For more information see: http://blog.nalates.net/tag/mesh-tutorial/ I'll be updating most of my tutorials for the new Bento tools.

There is an intermittent bug that causes friends online not to show up. As best I remember it is caused by a combination of slow or noisy connection and busy region server. A relog may resolve it. The problem has been around forever. In the last year work has been done to resolve it. But, it still happens from time to time. (Google)

Rolig and Karen both provided good information. For performance there are 3 key criteria that make the most difference. CPU speed is more important than the number of cores. The 6th generation i5 has been a better buy on performance per dollar than the i7. WARNING: be sure to check the CPU model. Vendors sell new machines with 3rd and 4th generation CPU's. The i5-6600 is a 6th gen CPU and that is denoted by the red 6. A 5th gen i5-5600, 4th gen i5-4600 ... etc. Memory speed is important. DDR4 memory is marginally faster than the same speed DDR3. But, DDR4 is made in much faster sets than DDR3. Labels like DDR4 2800 (PC4 19200) to DDR4 3400 (PC4 27200) denote slow to fast memory. The smart move is to find the motherboard brand and see what the max memory speed is for the board. You can install faster memory than the board is rated for and it will work, but it is like buying a Ferrari and driving it 30mph all the time. Video chip in a laptop and card in desktops. Starting with the NVIDIA 1000 series VR, or fast dual image processing, was added. The ability makes a huge difference in most games. HD Graphics has no video memory. It uses part of your system memory. A machine with 16GB and HD Graphics may dedicate 4GB to graphics and leave 12 for the system. Video cards have dedicated VRAM. Hard disk speed is important for the initial scene render. SSD is expensive but fast. However, getting the most out of SSD is a complex thing. Venders often sell a system with SSD just to say it has it. But, the motherboard doesn't fully support it, so it ends up being no faster than a fast mechanical disk. RAM Drives live in computer system memory and for now are the fastest possible drives. You can look up the comparisons and tech details here: http://blog.nalates.net/category/hardware/