Nalates Urriah

Things are changing. Probably this year a feature called Bakes On Mesh (BoM) will go live. This will allow us to hande mesh bodies very much like we handle classic bodies. So, you do not need to feel pressured to learn mesh modeling. What you know from the Sims will probably suffice. We have jargon... and you are new, so... Classic is the avatar you see when you take off everything that can be taken off. We say a mesh body, etc. when we mean a body like Kemono. Making skin and mesh clothes is a bit complicated. However, BoM is hoped to simplify that and lets us work with mesh bodies as we do with Classic bodies and clothes. So, learning how to make classic or aka 'system' clothes is a good first step. Basically making textures and adding them to system shirts, pants, whatever. No modeling required. Also, to avoid 3D modeling you can buy full perm mesh kits. These let you upload, say a mesh skirt, included in the kit with textures you made from the included UVMap/template. Once you understand these creative processes, you can decide if you want to learn more. Kemono is up to you. I will warn that some region owners ban avatars wearing Kemono on sight. They tend to be small avatars and have a childish yet sexual appearance. So, the fear of violating ToS comes up. There are some whines in the forum here from people getting region-banned. Seems the bans are blind bureaucratic reactions to the brand not the actual avatar. There is not a flood of such complaints. But, there are a few complainers here and it seems to be a known issue. There is no way to actually quantify the problem. So, salt the advice or ask around.

There are a bunch of known problems with vehicles. Especially when crossing a region boundary. There is no technical difference between water and land in SL. Everything is a mathematical representation within a computer model. The process of rendering the boat and land are not interdependent. However, the physics engine does consider whether the boat and land have collided. When vehicles are jumping around it is a usually matter of the viewer and server disagreeing on where the vehicle is and which way it is traveling and at what speed. The jumping is the result of their trying to get back in sync and adjust for the stream of change-info coming from the viewer, turn, stop, faster... etc. Network lag can make a mess of the process. Crossing region boundaries is hampered by a large number of scrips in the vehicle and on the avatar. The Lindens are working to improve crossings. But, they remain a problem.

When deleting accounts you do not get banned. But, if you try to do something with that deleted account, you can get odd error messages that aren't as accurate or informative as they might be. It can be confusing.

If the collar is OpenCollar, there is a manual that explains setting up outfits. If you have done those things and it isn't working... you need to give us more information on your collar and setup. Others like Marine Kelley have made tutorials on setting up outfits. I even wrote one... RLV, Mesh, and Folders. I still have problems getting these to work well. I find someone usually needs to help you test your outfits. The STRIP down to nude you need to get right first. Then most everything else falls into place... uummm... let's say then you can figure out how to make the rest work... The thing is most RLV scripts are old and made with the classic avatar in mind. With a classic avatar there are things you can't take off. Like the body (meaning head, hands, feet...), skin, eyes... These classic body parts are not attachments. The scripts use this information to save effort. That means those scripts that do depend on the classic avatar anatomy will destroy a mesh body avatar. You have to take special steps to anticipate the old and/or poorly written scripts. With the addition of mesh body, hands, head, and feet it got more complicated. Now the entire avatar may be attachments. There is no way for the scripts to know what can be removed to leave a nude person. So, one has to set up folders and mark things no-strip. Maintaining these folders as mesh attachments update gets tedious. My Slink Physique has updated 3 times. With over 300 outfits and several RLV outfits it can be a chore. However, there is an easy way and of course, several difficult ways. The easy way is use links for outfits and RLV folders rather than copies of items. The release of Bento gave us some help. Rigged, fitted, and Bento mesh items can be attached to any bone. So, if you don't wear a tail or wings you can use those attachment points to out smart some of the old scripts as they don't know about Bento bones. But, then there is a problem when the script needs to completely replace the avatar body. The coming Bakes On Mesh (BoM) feature may help with RLV and old scripts... probably not much. Until the old scripts go away and people write new ones that are aware of mesh bodies and Bento... it will be a tedious problem. So, the collar-folders do work but not perfectly. Hang in there until you figure it out.

Looking at it another way... Since no one can know when the group was founded, you can pick whatever date you like....

To get the 'Pending' notice cleared up, file a trouble Ticket with support...

If you had said 42, I would have thought you were making it up... In 2017 SL users took between US$60 RL and $70 million out of the game. Other online MMO's have a similar number of peak concurrent users as SL. Plus or minus 10k or so users. No other game (?) has paid out that much. Where SL is far behind is the number of paying subscribers. That is changing as the benefits of being a paying Premium Member increase.

Isn't that a style these days?

I think can... but the question is will they. I know mesh body makers already working on BoM versions of their bodies. We can't know how fast they will release or be adopted. While onion skin Bento heads have been rapidly adopted I think that is because the advantages are visible. 'Hey, I look better...' Lower ACI is certainly influencing sales of stuff. But, there is a harder one to measure. So, will lower ACI non-onion-skin bodies that look the same has onion-skin bodies sell? I doubt anyone knows or has any data to definitively say. Opinion seems to be they will because other lower ACI stuff sells. Probably a bigger selling point is the reduction in scripts and HUD's. Some HUD's do make things nice and easy. So, dropping them may be a negative. But, I would love a smaller script load and would spend money to get it. Once BoM is in place and designers are releasing products it will be interesting to come back here and see who had it figured out.

See if this helps... https://www.youtube.com/watch?v=1ZmoMEt9GbM Have you checked to see how well or poorly SL does the AO in-world?

Rolig mentioned the reattach and another region... If you login to a No-Script region or put on a HUD in a No-Script region they often won't work. In such cases they won't open of close. They really don't work. HUD's depend on the region to run the scripts. If there is a problem with the region, HUD can stop working. When teleporting or crossing a region boundary HUD's can stop working. THe region you are leaving has to package up all the script information and send it to the region you are entering. If anything goes wrong with the transfer, the HUD can stop working. Usually a detach and re-attach will get it going. If you are flying, sailing, driving across region boundaries there are known bugs that can kill a HUD, as in break... works no more (period). The only fix is to get a new copy. So, hopefully you have the original box or a backup copy. Otherwise, it's a trip to the redelivery terminal. You can press Ctrl-Alt-T to see transparent layers that may be covering your HUD. You can also edit your HUD while it is attached, right-click->EDIT. Roll your scroll wheel to zoom out. You'll see a frame that represents you screen area scaling with the mouse wheel. You should be able to see HUD's outside the visible screen area. Another easy troubleshooting step is to try another viewer. I suggest the Linden or one without RLV. You should have at least two viewers installed for quick troubleshooting. Both Firestorm peeps and Linden support have you test-troubleshoot with the Linden viewer. Always the thing to do before going nuts and ripping out the viewer and cache. ...and often it is easier to go get a new one rather than troubleshoot the problem.

I've been playing with my GA.EG Jennifer head. The makeup is fun The eyes still need work. I've maxed out the smile, mouth corners up... still not enough.

According to Vir Linden BoM is not going to deal with Spec and Norm maps for now. But, they aren't going to block their use on mesh using BoM. So, for a time appliers will have a use.

You are asking a technical question. So, it should go in that sections of Answers. But, we aren't the posting police. We just want you to know how to get the quickest answers. When you do include your computer's tech info. You did good including that you use the 'latest' Firestorm viewer. So, Lindal knew just which help article to send you to. But, include the version number. In a month or two the 'latest' version will be a different version. So, future readers will be confused. Ideally, click HELP->About... and copy paste that info with your question.

Of course it isn't fair. But, why do you have the idea anything in SL or RL is fair? Or is even 'supposed' to be. I suppose children might, but then you would have other challenges with this location. In our current society political groups use the idea of 'fair' to confuse issues, because the idea of what is fair is diverse and divisive being a poorly defined personal ideal that is more emotional than rational. Bureaucratic administration is the hallmark of large and/or overworked organizations, government or private. A primary reason many people favor small government. You have run into it with the estate or club managers not taking the time to actually consider your unique personal situation. Instead to save time and effort they quickly lump you in with other Kemono users and your get zapped. That is life. Learn to cope. It isn't that we aren't sympathetic. We've just learned a good fine whine based on fairness is useless.

Since you can play the animation correctly from inventory, that eliminates file corruption and connection issues. You have eliminated AVSitter problems. Since problems come in with sits, it would guess the animation has priority issues or other animations with issues linger. If you are replacing system animations with other animations you could run into unexpected priority conflicts. I would try getting everything back to system defaults. Then log off for the day or if you can test the animation again on ADITI. The next day or when you login next without ANY AO running, everything should be back to default. You might even login with a different viewer that uses a separate cache. Test in that known condition. I think the solution is sorting out which 'other' animation is creating the problem.

Fair is only something parents talk to their kids about to stop the fighting... You can export the Bento Skeleton out of Blender in several formats. No big learning curve for that. Plus, Google shows some Blender to Poser import/export tools. Seems you should be able to make your own. Possibly even sell the final file on the SL Marketplace.

Cathy Foil has made some videos of early use of BoM and how to use it and problems. You can see what others see... to a point. https://www.youtube.com/channel/UCLurA9Qzby5GRuYtJ_K_8FA The quick way to 'self' answer these questions is login with your Project/RC viewer and use and Alt and log them in with a viewer that does not support the feature you are testing. There are some images floating around showing the odd rainbow pattern but, I couldn't find any...

I don't think FS uses OpenJPEG. On the splash screen they advertise using Kakado's JPEG library to handle the JPEG2000 images used by the SL system, which also uses Kakado. This is a big plus for use of the Linden and Firestorm viewers. If you self compile, you would need to use pre-compiled Kakado libraries... Do they exist for general use? I doubt it. But, I don't know. Or you would need a Kakado license. I suggest you IM or or otherwise contact some of the people in the Firestorm team for information in how they handle compilation by individuals without access to Kakado.

Any texture the viewer can render can be stolen. Textures run through the bake service are composite textures, which are a long term temporary texture. They can be stolen too. But, the source textures for the composite are much harder to find. So, there is some protection in using the bake service. The applier code I've been using reads the texture ID's from a note card that is deleted automatically from the applier. The UUID's exist only in script memory, which lives on the server side. Safe so far. (But, if the applier is reset, it is dead, ID's lost.) But, when the viewer renders the applied texture the texture is pulled from server assets and stashed on your computer then used by the video card to render the scene. At that point anyone with the knowledge can take a copy of the texture from the hard drive. The entire 3d gaming industry has found no way to get the texture on your screen and prevent it being stolen. My impression of where the Lindens are on this point now is that adding complication and reducing performance in a futile attempt to prevent theft is counter productive. So, I don't expect any grand plans along that line. I suspect as the cache is redone (in progress) we may even see it get a bit easier as performance is improved. The Lindens are aware of the problem. I can't see them deliberately making it easier. But, performance is their goal in the face of impossible odds against protection ever working. Understand. If the video card can use the texture, I can take a copy of it. That is completely independent of the viewer or whatever game is sending a texture to the video card. No matter what the Lindens do or what complications, obfuscations, or protections they might build into the viewer or a game, eventually the texture has to be sent to the video card in a usable form and that can be snatched out of the video card. So, what is the point of trying to protect the unprotectable?

I'll try putting this in a bit different framework. Consider a RL house. The paint on the house is similar to the diffuse texture. We do not paint in shadows nor ambient occlusion nor bump/normal maps. The RL 3D surface, i.e., shingles, etc., provides what a bump/normal provides. The sun or moon provides the shadows. The matt or glossy paint or substance type, i.e., glass or brick, provides the shininess or lack of. In a rendered world we need to reduce polygon count. We do that and provide the 3D surface of the building with normal/bump maps. We can omit modeling individual shingles or engravings. We use the specular map to provide the shiny, matt, or glossy nature of the building's materials. We use lights, shadow simulation, and ambient light and occlusion simulators to provide the shadows and realistic lighting. This happens at render time, which in SL is real to near real time. In games where there is static lighting or a static nature to the area modeled we eliminate the simulation of shadows and occlusion to save render time. We bake in the shadows and occlusion. BUT... if we bake those in and then tell the render engine to do shadows and occlusion too, we have twice as many shadows and too much ambient occlusion. We also end up with shadows that do not move, the baked ones, and shadows that do move, the rendered ones. It looks strange. Before we had shadows and occlusion in the SL render engine we faked shadows and either made them using prims and textures or baked them in when we made the diffuse texture. With the addition of SL materials we could stop baking in shiny/reflective light spots. Look at clothes that looked like shiny latex and silk made before the time of materials. The shiny reflection spots never move. Now with SL materials we skip baking in the lighting hotspots and let the render engine provide them. We create the specular layer and let the render engine do the rest. Now Bakes On Mesh is coming. The existing Avatar Baking Service was added years ago. The classic avatar has skin, tattoo, underwear, and clothes layers. Long ago the viewer baked all those layers into the three composite images that made up what we saw. Every viewer baked all those layers. The textures could all be 1024 textures. So, 3 parts; lower, upper, and head times 4 layers each made for 12 textures that had to bake to 3. The 1024 textures could run that up to about 50MB of texture our video card had to deal with. So, as network speed increased it was smart to add the bake service and take that load off the viewer. The bake service provides 3 textures rendered at 512px. Saving about 47MB of texture load and data transfer. Plus the textures only bake once and the result of the single bake is shared with everyone. Now the bake service is being modified to Bake On Mesh... meaning our mesh bodies. The changes are the Lindens are increasing the texture size to 1024 and letting us provide a target on which to apply the shared baked composite texture. To use the existing infrastructure and methods of making clothes the classic avatar system is being used. It gets modified with an addition of a spec for where the baked texture is going. While Bakes On Mesh is a kludge and somewhat inelegant, Yet, it is a brilliant hack using existing infrastructure already in place that avoids rebuilding the entire SL system and gets us a big improvement in a small time frame. What is still up in the air is materials. The baking service does NOT handle materials. AFAIK, there is no standard or reliable way to bake specular and normal maps into composite maps. Does the designer of underwear want visible panty lines or not? And what about the one designing yoga pants? Do they have a say? And the one wearing both? Attempting to push that decision into the automated system adds considerable complication. Plus, giving users any control compounds the process and the user learning curve. So, for now... spec and norm maps will remain in the realm of Appliers and outside the baking service.

I can wear stockings and tats. But, I do have to adjust the blending/masking mode of the body layers for it to look correct. I haven't yet tried to wear three layers of alpha'd textures... Onion skin bodies do provide better appearance for clothes and underwear as they permit clothes to span toes, cleavage, and butt crack to get away from some of the painted look. I doubt a body maker is going to give up that improvement. So, it will be interesting to see how they handle the new bodies and reduce the layers of onion skinning. I can't see Appliers going away. Bakes-On-Mesh is not going to handle materials. At least not in this first pass. So, we will still need Appliers for materials.

The image you posted suggests a berserk Applier. A wrong texture got applied to a makeup layer in the head. The head's HUD should have an option to clear the layer. The redelivery will give you a new head. It should work. If the new copy does not work contact the maker. If you have some odd mask attached, you should be able to take the head off and still see the mask. Otherwise, it is part of the head.

Our perception of the nationality make up of SL will depend what time of day we are logged in...

There is often a complication with the layers. If you wear something that has a specular or normal map then wear something different that does not have a spec or norm map you'll see this happen. Your HUD should have an option to clear spec and norm layers. Try that and see if it solves it.