KathrynLisbeth

Yup. That is the 'very hard part'. Even if you get the options arranged right in the viewer. Then it is avatar assembly. Sorting thru Google's detritus to figure out what a thing means. And so on ......

Well with SL, I think is two things going on Making a loose analogy here, but some kids can make a fun game out of shiny rocks and neat looking sticks. Some kids like the option to not have to build the thing on the front of the Lego box. Other kids just sit there unless you hand them a <insert sport here> ball. So SL is for the big kids that can just being their own sense of play to 'their' entertainment time. Some people just don't operate like that, period. More so.. Making something that is like that & non-opt out. Liable to run off the ones that do like the 'bring / configure your own play' to 'their time' As to the growth of Premium Memberships with Linden homes. I don't think that Linden homes are 'the' facsimilie of basic / foundational needs. They do make it easier for someone to choose to spend money on SL. Here is a stipend and here is a House. A house without buying (the option to Lease land). Land where on next login your new neighbors are an AFK sex club and/or Breedables Farm. I think the basic needs part of SL is figuring out the viewer well enough to 'feel you' have accomplished enough to not just say '<redacted> on this !!!' Of course I have encountered a few that rent a whole region with a get rich quick scheme in mind, while being unable to figure out how to put their hair back on when it falls off... but there are always a few. Since the basic need is to figure out how to pilot your avatar.... well. --- What Katherine Heartsong said above re: the UX / UI -- An example is in order I suppose, of course they seem minor compared to some, but death of 1000 cuts, and I am too lazy to list others. As a default in LL viewer, empty system folders are hidden. New people are New. Inworld view is dynamic and confusing enough. Show them a screenshot of the folders and it not match what is on their screen. *sighs* But LL did fix one thing. The Chat Toolbar button, after years, does have an actual chat bubble on it. Of course in the CHUI itself the nearby / local chat (minimized) is still that icon that looked like either a sunburst or the north end of a southbound cat. But once they know that, then I have actually gotten more than a few to interact in local. ( Local. 5 letters. 2 of them the same. Easier when you have not yet become a fast typist. Yes I know, only applies to English.. Yadda Yadda) Anyway... there are things that can be done to make the learning curve a little more straightforward. Most of that is just defining terms and explaining the underlying concepts in a concise fashion as an addendum to the answering of 'how to do a thing'. Since is SL and is impossible to answer all the specifics for every possible individual items behaviour. But that is another story. It is just keeping them inworld long enough to see the potential. Of course it did help me that I am a persistent / obstinate <Redacted>, that is gonna work to figure it out, period.

How much of it is anti-social (or Distracted but social in IM's, Discord. and/or Slack) v/s Chat using SL is a Pain 'for them', b/c of All the Mesh and some Extra Mesh with a Non-Optimal Graphics Setting? What made me think of that was comments from the other day while at the Motown Opening and users having single digit FPS. While the me that was there had 50 something FPS.

Is part of relics from an old Premium User Game called Magellan’s Grid Scavenger Hunt. circa 2013-14. Since is unsupported some of the parts like the hidden doors no longer work, but you can cam to sit targets in the cave as a work around. Also check out the hidden mines and overlook in Blendard and temple caves in Threesun.

The No RLV option. Won't work if RLV is on and a thing is locked on to a HUD point. Won't actually remove the HUDs, just hides them. Show HUD attachments - ALT+SHIFT+H on firestorm top menu / avatar But Yup to the RLV method. Is very useful if you have other locks to override the mass detach. Can segment the HUD's based on function. So can do stuff like leave the body, head, some animation player HUD's on, while batch removing assorted texture huds. Locker System // HUD removal function

Replace / Wear -- It seems a minor detail, but the word order emphasizes the Replace component of function, include Wear to contrast with Add. But the Part that Makes it a Screwed up mess is two-fold though, and indirectly related to it's use. 1) Rigged shoes or Rigged Hair. From nice looking shop inworld. On it's own Region, even! Alas, too much effort for that 'creator' to assign the item to a 'more relevant attachment point than right hand. So Sad. All the Sad. (( I was Typing and Y'all mentioned that )) 2) Lack of Granulation in Layers. Inability for final end users to assign them a Subtype. Analogous to selecting an attachment point, but for layers. Something akin to a forcing a relative sort order. Like How System shirts always landed between system undershirt and system jacket. Then things can be a little more apparent as an add/remove &/or replace a 'Module' Function. The module being the relevant objects and layers, like the right hairbase for the right hair without removing the face skin and makeup. Improve the Speed and simplicity of changing a Subset of the Components of one total saved appearance. Is the simplified version of how some of the fancy inventory setup things with all that #RLV folder stuff work, but not need all the 'extra built in RLV dependant workarounds'

Slide the texture 'side to side'. Use llSetLinkPrimitiveParamsFast() to adjust the offset showing only part of the whole texture at one time. Is 'a prefetching the new image' trick. Couple it with a proximity sensor for more fun, too.

Oh I know! It is that an Onion Shell is Required when using the common configuration of off the shelf system layers.

Haven't played with the Legacy body, so i don't know the details. If the Arm Mesh objects grabs the left channel bake, then that requires that there be a Universal layer providing the skin texture, too. So first a Skin texture containing layer is worn Then Universals containing Scars or Tattoo texture would be worn next (and so on). The one I am most familiar with is Maitreya, that body and others actually have a mesh object 'onion shell'. Is either an optional add-on object or part of the body's linkset. The terminology used can get jumbled. Though the Mechanism behind those the same. It is using a Scripted applier to place a texture in an additional 3-d object 'layer' that is over the layer that grabs the 'baked skin'. If Given a Template UV map for the mesh, make texture. Then Do 'stuff' to program a scripted applier (an object) to pass that Texture UUID to the mesh. Like how an Omega or a Body or Head specific applier works Is Funny, b/c part of the reason for Bakes-on-Mesh was to reduce the dependency for onion skin 'shells'. But looks like they forgot that bilateral asymmetry is a VERY valid use case. A Ink design on just one arm. As well as not needing 'alpha cuts' to wear a robot arm or a pirate peg leg only on one side.

Pretty much you Can't. Is a 2 part thing that you won't have any control over. Is a tl;dr reply, but is because It would not be 'that hard' to have a REAL FIX. What you Really asking for is: 1) The relevant 3-d object faces to 'Grab' from left arm and left leg channel --> controlled by the Mesh Body Creator, thus locked down permissions 2) System Layer having the needed textures to make the skin appear on those object faces --> controlled by Skin Maker, so no direct access to the actual texture Now in a Hypothetical Setting this would totally work. Example case is some add-on design (a tattoo picture) on the Left upper arm only. * Mesh body -> On left side of upper body object, and left side of lower body object, Set it (fixed or toggle) to grab left side channels * System Layer -> 'skin creator' duplicates the upper body skin texture (the one that is put in the upper body channel) into upper body left channel. Repeated for Lower Body. --> Then can just add additional System layer on top of that. One containing the add-on design ---> The Current Setup of SL itself is really the main limiting factor <--. Think of System Skin Layer as Base layer. Then think of the System Clothing (including Universal, Tattoo, and Alpha) as Add-on Modifier Layers. But due to the availability (or lack) of channels in all System Layer types, and the forced immutable ordering of the System Clothing Layer subtypes. It Gets muddled, messy, and awkward to use, and a Pain to try to explain it . People don't have slots in the skin layer to add duplicates into left side channels. For a skin maker It's a pain to do more work / separate universal layers that hold those texture. But if they did that... Since you are then limited to the universal layer subtype, It is then awkward for end user to have to reshuffle and resave the layer order on every saved outfit. Is like how if you replace links your mesh head skin on a tattoo layer with a new one. Now your tattoo layer makeup, scars, skin ink, etc is underneath. So since all that is muddled and messy, Mesh body makers just have the entire upper body set to Grab the Upper Body Bake channel. Of course part setup is to 'ensure backward compatibility with older skins that won't have a left side textures (duplicates of the right / main). It is not like mesh bodies all have 'their own body skins' to correct for minor UV alignment issues, so is newer skins anyway. But on a mesh body, setting object face to grab a different bake channel is really is just a toggle switch.

That Belongs in a Museum!

That other portal under the floor. It's been there.. Um?... 2 years or 3 years, now? I don't actually remember if it is in all seasonal portal park copies anymore though? So might look new!

And you hit enter while I was still typing. 😁

I totally get what you are saying with using a mechanism like this. First though you Really Don't want a whole bunch of 'Interlocking visible / invisible clothes' because of the Real rendering performance. The Avatar Complexity metric is inaccurate. While you can set up test cases that is composed of wearing a whole bunch of mesh clothes to see what the Avatar complexity says, the actual impact is higher. So end result is like wearing a mesh body with extra Onion Layers, not just a Maitreya with the tattoo layer, underwear, and clothing layer. More like wearing 5 or 10 of each one of those layers. You can somewhat infer this type of performance hit when comparing the load time of a complex strippable outfit item (multiple meshes that toggle their invisibility) with just a single item. If you were able to get people to have a standard to reduce clipping, one with a more minimal impact on performance could be a set of standard waist heights. Example would be a high cut waist v/s mid cut v/s low cut. Thus can partner a high cut top with high cut bottom, making it look like shirt is tucked in. However in some limited uses, your system does work. I implemented a set of scripts that I use to turn on / off some jewelry and sections of jewelry, things like piercings or part of a necklace. It is analogous to how the Maitreya cuts system works, so is a remote toggle (inside mod item, or a microprim on the same attachment point as a no mod item) But the reason is that I keep it limited like that is combination of render cost and need for wearing it (example invisible jewelry that has additional scripted function).

The name tag move/hide animation works when the client that is Viewing the playing animation has legacy nametag position enabled. So even if you are running the animation, if others are using the default, then nope.

Some were Live. I remember the Meet the Moles Event. I was there, too. The one with Mr. Oberwager was a pre-recorded Parcel Media Thing.

Was the same last year, too. But ... Your Version is more fun! YAY!

I get to make all sorts of pretty sparkly explodey things! And.... and... unlike in RL! The Police! They don't even care! Oh! I get to fly too!

NEST THOSE FOLDERS! Flat inventories are a BAD THING! Causes Borkages and support tickets. Number your category folders to force the search sort order. Start with 10, 20, 30, and so on, then can go back and insert 21, 22, 23. When numbering to force sort order, consider having worn things that are NOT part of a saved appearance outfit come first. So you can get to your Coffee, Cookies, and Rocket Launcher faster, and leave the actual getting dressed to the saved appearance window. Keep things that are attachment type toys separate from things that function rezzed to ground. Separate your using copy of clothing (and other things) separate from the original packaging. If alternating between multiple mesh body types, consider separating wardrobe based on body type, then clothing type (generally this applies to attachment clothing more that layer/BoM clothing). Is less important with rigged clothing and accessories, but very useful with edited to fit unrigged things. But follows the approach of "I done decided what body and head to use, now I gotta find the clothes that fit!" For things that have more complex configurations: Mesh body, Mesh head, Adult bits. Configure it and keep a ready to go configured backup in a thing specific backup folder. For System / BoM Layers that are used to do Body Texturing: Build your folder tree & number those folders, to allow you to go down the list in a consistent fashion in regards to wearing the layers. Thus makes sure that skin texture/tattoo layer is actually under the eyeshadow texture/tattoo layer, and so on. Winds up being a bit more useful because you are winding up managing two lists of layers, too. Tattoo and Universal because the diffusion of function across the multiple bake channels. An example List function types is Body Skin, Head Skin, Skin modifiers to 'fix' a skin, Scars, Ink, Body &/or Face Hair, Makeup, More Makeup, then Hairbase/Scalp Hair. I find adding the Hairbase/Scalp hair tattoo last to be the most useful, due to alternating hairstyles. Remember, while the replace link tool is useful, the new replacement is on top of the stack of layers. So replacing a headskin tattoo means now that it is on top of all the other head based (makeup, scar, ink, beard) layers in said appearance. So having a generally consistent mechanism in place to add the layers based on the actual function is in the longer term, easier. Since is less time fiddling with the edit appearance function to reorder layers and resave outfits. Workaround that can help when using the replace link tool for Layers: Break replace links into 2 steps: so can mass replace and eventually get the relative position order. An example of this: After replacing a face skin tattoo... 1) Since you can't replace an item with itself, Replace each layer of with a 'nota makeup' layer of same type. So you would replace lipstick tattoo, with a nota lipstick tattoo, etc. Keep the same sequence. This then places 'a thing' at 'the number' in the stack, in the order you want. 2) Then Redo that. This time replace the nota tattoo with the 'real tattoo. Again Keeping the Sequence. Results in the 'Old things' now getting back into proper 'relative' order.

So the delay to show until the very last moment thing is a result of the Servers not passing that info until the very last moment? Which I assume is tied to the 'How they decided to fix showing banlines in the inworld view' thing?

Ability to show parcel boundaries on the Mini Map is already present in some TPV's. (Of course that is not present in the Default viewer.) So... If can show the parcel boundaries? Why is HIGHLIGHT A BANNED PARCEL not on the mini-map? Ya know? Color the parcel Bright red? (and/or Bright Green if is using the payment info restriction) Then.. would be a definitive signal reported to individual viewers that a parcel is restricted. Thus bypassing the need to see banlines on the inworld view from a great distance, or play the 'Well now you found a Security Orb (sensor scan)' game. --------------- Aya!!! Instead of Providing a wider than the road right of way, lets just get the Customers to fight each other! YAY! THUNDERDOME!

*mumble mumble* "... makes the Landmarks (Landmarks UI Sub-window) behave like Chrome..." *mumble mumble, facepalms*

Well that is rather exclusionary. Has anyone even considered the ones that like vertical activity? Inverted Vertical? How about an angled to the side activity? Is Virtual, so can safely do a rather gymnastic sort of spinning twisting screw type activity, like a propeller?

Make things Invisible = The Alpha Layer actually working, and making part of the 'Picture Painted on the System Body' (in this case the avatar's skin) be clear/transparent/invisible. I get the same issue with Mesh Bodies and Alpha Layers. The 'Make This Part be Invisible' just never happens.

Baking the alpha layer (Adding the alpha layer and having it show up and make things invisible). That has just been intermittently screwed up lately. So far only consistent fix that I have found it to add it. Logout. Cross fingers. Relog to a different region. Reloging into a different region, instead of the region that you were in, is basically giving the server an extra solid smack that says 'Rebuild/Repaint me'