Jump to content

Nalates Urriah

Advisor
  • Posts

    8,841
  • Joined

  • Last visited

Everything posted by Nalates Urriah

  1. You have gotten some good answers. Orwar's is accurate. I'll sort of repeat it using different words to explain. System or default avatars were first. They used system skin, tats, clothes, etc. All the things that have a unique icon in inventory. At the time each layer, i.e., skin, tat, underwear, shirt, jacket..., was a separate texture. So just on the upper body there could be 5 textures (1024x1024 multi-megabyte images). Then there was the face and lower body. People were having to download megabytes of data to render all the textures. The Lab devised Server Side Baking (SSB) to composite all these textures into just three, head, upper, and lower body. It was a big performance boost. Then we got mesh bodies. But mesh bodies are a type of prim and only ONE texture can be applied. There were no layers. To work around that limit designers made bodies that were like Russian dolls, a body with over laid copies of the body each slight larger. These faked layers; skin, tat, underwear, etc. required their own texture, which are applied by Appliers. Now we were right back where we were pre-SSB. The Lab devised Bakes on Mesh (BoM), a system that took the SSB engine and modified it to bake the system layers into a texture and apply it to a mesh. For designers it is simple to implement. They set a flag so the system knows which mesh gets the resulting baked texture. All the user has to do is decide to use the body's, or whatever part uses BOM - not limited to clothes or bodies, BOM feature by enabling it. Rather than require we continue to use alpha layers to hide the classic body, or aka system body, the system was designed to simply not render the classic body when the BOM feature is used. No alpha needed. This allows us to use custom alpha layers to easily hide parts of a mesh body. Neat. For those of us that learned to dress using the original classic avatar and followed the developments over time BOM is a simple next step. For those that came into SL somewhere in the middle it gets confusing. The mix of old information and current information can be misleading and very confusing. As I suspect you have found. Unfortunately, there is no easy solution for explaining the system to the new people.
  2. This. Unless mind reading evolves, I don't think AI will ever conquer this. A better question might be will we be able to detect AI deception.
  3. There are tools for travelers. Sailors use USB HUD Pro or aka Ultimate Sailor's Buddy. It is used for racing and group sailing. It can be used for any navigation task. Shergood Aviation has a nav computer for planes. It has interesting real time features and they have a web site that tracks security orbs so you can avoid them when planning a route. Both Shergood's and USB use way-points you or someone creates. There is also a Ban Line HUD that forewarns of ban lines on a parcel level. Great for driving. Not so much for flying. It also forewarns of ban lines in adjoining regions. Very handy. Also, the Firestorm Viewer's mini-map (aka radar) indicates ban lines and offline regions. I think there are more such tools. But these are the ones I know of and use.
  4. I agree with most of the above... I'll add that packet loss and latency combine to additively worsen your connection. The greater the latency the less packet loss can be tolerated. This is connection thing is a common problem for SL users. And many have the same reaction you had, my connection to the Internet is good. Well, yeah probably. But did you check your connection to the SL servers? Probably not. The Internet changes millisecond by millisecond. Several entities providing your connection are constantly load balancing and rerouting traffic. When an outage like AT&T's happens massive changes are made to try and cover the problem. In 2011 I wrote Troubleshoot your #SL Connection. I updated it a couple of times. April 2023 is the last update. I suggest you work through it. You should get a better idea of whether the problem is on your side, the ISP's, or the Lab's. Then you know who to call for help. Remember. Your ISP is likely to point fingers at everyone else... and deny ANY responsibility. The testing should help you convince them when it is their problem. Also, your viewer and computer will give you different packet loss data. The viewer is working INSIDE the SL system. It includes all the network issues your computer will report AND... the viewer and SL server issues. So you can have a perfect network connection and an overloaded SL region server will still drop packets. This mean when testing your connection to SL you have more to consider and test for. So, the easy testing requiring less technical knowledge is done in the viewer. Ctrl-Shift-1 opens the viewer stats panel. This gives you the data to know what is happening with your viewer and the SL backend/servers. The Basic, Simulator, and TIME sections are what you'll be interested in. When all else is failing and when you and those helping have no clue, look in the viewer’s log files. The viewer has various log files you can read to get an idea of what has gone wrong. Look at the log immediately after you crash or exit the viewer. Logs are replaced the next time a viewer starts. You’ll find the logs in: Windows: C:\Users\[Win_login_ID]\AppData\Roaming\SecondLife\logs\ Mac: /Users/<username>/Library/Application Support/SecondLife/logs You will change folder and file names based on which viewer is used... But all viewers are similar. crashreport.log – This log is generated when the viewer crashes, the previous version of the file is overwritten. Rename this file if you plan to restart the viewer before examining the file. Otherwise, just read it with a text viewer (Notepad is good). debug_info.log – This file is internally formatted as an XML file. I never find it of much use. It is mostly the specs of your machine. SecondLife.log – This is the main log file. I find it the most useful. Start from the end of the file and work toward the beginning. Search for ‘WARNING’ and ‘ERROR’. With any luck, the messages there will give you an idea of the problem. Recent changes have added a section heading to parts of the file that can identify the general nature of the problem. There are lots of performance stats included. At the end of a session with no crashes the end of the log file will contain secession stats; Run Time, Average Packet Size, Dropped Packets, Resent Packets, etc. The file is replaced and recreated for each viewer secession. SecondLife.error_marker – I don’t know what information is inside. I don’t have a copy to examine as I write this. The presence of the file indicates where, when, and what error happened. I think this is a disaster backup file for crash reporting in which information about the crash is retained in the event the crash handlers are destroyed before they can create the other more complete crash files. SecondLife.start_marker – There is no information inside. The presence of the file indicates how far into the start process the viewer has gotten. Whether the file exists or not is the pertinent information. SecondLifeCrashReport.log – This is another file internally formatted to XML. It is created when the viewer crashes. I think this is the new version of the crash log. It is mostly text. stats.log – This is a short file containing network statistics. Similar information is in other log files. It is an easy-to-read set of stats that show how many packets were dropped and resent in a secession. I find the SecondLife.log is the most useful file for tuning and troubleshooting the viewer. It is verbose and reasonably easy to understand. There is a Debug Setting that allows you to increase or decrease the level of reporting. Most of these files are erased when the viewer starts. If you plan to send the files in with a trouble ticket or bug report, place copies in another folder immediately after a crash and before starting the viewer again. Marker files are temporary and may or may not exist at any given time. Entries in the files associated with errors and warnings are labeled as such. That makes them easy to find by searching. Search and read through them starting at the end of the file and working backward. Warning entries are common and do NOT necessarily mean there is a problem. Some warnings are a part of normal operation. Some errors are trivial and do not indicate a ‘noticeable’ problem in the viewer’s operation.
  5. I think you mean the setting to enable/disable ALM is gone. ALM is permanently ON.
  6. Password phrases are great in several ways. Being easy to remember is an excellent reason for using them. I can't find a maximum length for a password in SL. With the coming of an SL Mobile app long passwords are likely to be a bit of a problem, if you go that direction. While 2FA is a great addition to security it adds a lot of moving parts. If we manage to start a new world war or even just piss off one of the big world players, that 2FA complication is likely to be a BIG problem. If you were an AT&T customer and using 2FA for SL then you would likely have been locked out of SL during AT&T's outage (ref). There are lots of theories as to what actually happened with AT&T. Many of us are highly skeptical of anything big corporations and governments claim, especially in an election year. Think: Leaving the World Behind. With all the accounts I have and all the accounts I manage on clients behalf the 'remember' and/or 'write it down' plans weren't working. I use a commercial password manager that syncs across all my devices. It is so nice and quick. By default it creates 16 character randomized passwords using upper (26) and lower case (26) letters, numbers (10), and punctuation & Symbols (30)... with gives us... 26+26+10+30=92 for 9216 or 26,339,361,174,458,854,765,907,679,379,456 or 26.3 nonillion possible passwords. if a supercomputer could check a billion (1,000,000,000) passwords per second, it would take about 8.2 x 1022 years to check 26 nonillion permutations. The estimated time for a quantum-computer to crack such a password is something like 5.1 quadrillion years… or about 364,000 times the age of the universe. A big improvement, but no prize. With the rapidly upcoming AI and all the data Google collects, it will likely be able to predict (guess) any password you make up. HOWEVER… a good scam or phishing attack can also come up with your password in less than an hour. So... while long passwords, and even randomized passwords are strong... real security is a matter of how smart you are and your level of gullibility. 🤔
  7. Without knowing how much you want to get into the fun part of the RP of impregnation... it is difficult to recommend which genitals to buy. I suggest you try demos to assure the one you pick works with Mama Alpa. Also, there are still some items in the Marketplace made by people that have left SL. Xcite! is one such seller. And Aeros, if I remember correctly. There are fun ones like Birth's and Physics (aka P). And many cheaper ones. Once you are some what decided on one, ask about it here in the forum and get people's opinions.
  8. That is the problem with having a working brain and a curious mind.
  9. I didn't look at ownership. Sorry. I use the Destination Guide and the World Map search to find sandboxes. But I seldom use sandboxes these days as I use the Preview/Beta grid (aka Aditi) for most of my building. Way less griefing over there. But, it is a bit of a PITA to get access. See: https://wiki.secondlife.com/wiki/Preview_Grid
  10. The Sandbox Bellisseria is rated 'M'. There are many of these in SL. There are a few Adult sandboxes in Agni, SL. The Destination Guide shows 11. There are some sandboxes for premium customers only. These are the best. There are a few for server rollout testing. RC BlueSteel is one. Access is for only those that have participated in SL development, which mostly means being involved in the Linden user groups.
  11. DOF is important when making machinima as there is no easy alternative. (That I know of) For snapshots capture two images, one using the viewer's color setting and a second using depth. Both in the camera/snapshot panel. Then use a blur tool in your image editor that allows the use of a depth map. This later gives the most control. However, the viewer's DOF and settings will give great results with only a little less control. So depending on personal preference and what you want to accomplish... the viewer does a more than adequate job.
  12. So.... eleven years plus of getting around to... 🤭
  13. When you find your avatar gliding you have an AO conflict or an animation is not loading. The Firestorm AO works well UNTIL... you have a second AO attached, its on/off state makes no difference, or some other attachment that adds animation. When troubleshooting you need to know if only you see the avatar glide or is everyone see the avatar glide.
  14. @kenzie1770 Having a new computer and the same issue tells us a lot but not enough to pin it down. Pheeby's recommendation to create an Alt-account is the easiest next step. Try it. Also, when you have a tech problem like this include the viewer's HELP->About... with your post. I have a mouse, keyboard, SpaceNavigator, and WACOM tablet attached to my computer. I occasionally get strange things happening. I forget and leave the pen is on the WACOM or something is touching the SpaceNavigator... odd things happen.
  15. When people blow the dust out of their computers some of it gets blown into and settles in SL... and THAT is where SL sand comes from...
  16. I don't remember there being a PLAY option for gestures in inventory. But with my memory of such things avoid giving that mush credibility. Ctrl-G pops up the Gestures panel which is where I typically see the Play button. From inventory open the gesture to get it in the Gesture Editor where there is a play button.
  17. Using the world map... just search on sandbox... sandboxes won't work
  18. @Benson Gravois All the published limits in SL are on a Wiki page: Limits. What you are looking for is here. These are for the SL System and Linden made default viewer. Some third party viewers can do things a bit different as there are viewer side enforced limits and server side enforced limits. Only the viewer side limits can vary.
  19. Well.... it used to be simple... then things got better... sort of and obviously the simplicity or better is WAY debatable. There is not an easy way to implement an UNDO button. The tech is too complex to go into here. But there is a simple work around. We can save an avatar setup as an Outfit. I have a basic nude avatar outfit which I use as a starting point for outfits. These base outfits are made for the various bodies, heads, skins, and tats that I use. I also have one body/outfit that I use for experimenting. So when I find I suddenly can't find where something went, I can revert to the starting point body/outfit. There are basic components of the avatar that cannot be removed, only replaced. Consider. If the skin were removed what would the avatar look like? Basically it would be an invisible avatar. Then people would be complaining about losing their avatar. So as a logical step the Lindens made it so an avatar has to be equipped with the basic parts needed to render the avatar. You misunderstand what 'save' means in this instance. In SL a different paradigm is in use. In SL people "CREATE". There is no imposed limit on what can be created and users have often surprised the Linden engineers with what they come up with. This makes it ridiculously difficult to create save slots similar to what you likely have used before. So a different paradigm is used. Once the SL Paradigm clicks you'll find things much easier.
  20. You've run into a BOM thing. Items in inventory with pants and shirts icons are System Clothes, which are from the pre-mesh-days of SL. These items are sort of painted on the classic avatar body, aka the system or default body built into the viewer. Our mesh bodies fit over the system body. BOM (Bakes On Mesh) transfers... relays... projects... whatever... the system layers (skin, shirts, pants, etc) onto the mesh body. If you wear a system item and it doesn't show then you likely do not have BOM active on the body. The history of SL is one of steady progress and change. Initially all avatars were System Avatars and there were no mesh bodies. Clothes were either System Clothes - simply textures painted on over the skin texture, or prim or sculpty clothes. When mesh was added we got about 3 styles of mesh clothes. First were standard size clothes made for the system avatar. We adjusted the shape of the avatar to fir the clothes. That sucked. Then we got mesh bodies and mesh clothes for those bodies. But we have Appliers that were used to place system-like clothes and skin on the mesh bodies. For appliers to work mesh bodies had to have numerous layers (onion skin over lays). This solution created very high ACI/ARC (Avatar Render Cost). BOB was developed to reduce ARC. BOM allows us to move back toward the simpler System Clothes concepts. It gets tough for the new people to sort through.
  21. I have used both an XBox controller and a SpaceNavigator with Firestorm. The SN is much nicer to use. You can see it in action in this video: https://youtu.be/5SLN2eMtngg?si=q1uvxf9S11tGQaX7&t=345
×
×
  • Create New...