KathrynLisbeth

Rigged Shoes, Pants, Shirt, Hair, etc. - All attaching to the right hand. Too much work to assign it to something other than default. So ... Do you think it would actually work to 'make a thing' that would require an item creator to fill out more 'forms and paperwork'? Correctly? So that it lands in your Sub-Sub-Sub folder?

The 'workaround' for no mod names. While imperfect helps with the confusing / garbled / special character / misspelled / other language names. In the folder with the item make a notecard. Name the notecard with enough of the Item in question's name to make it unique. Use // as a separator. Add your own personal searchable descriptors. To copypaste a no mod items name: Right click > Properties, to grab the name. -- Sure now the final end user can add w/o upload fee an inventory only viewable image to a no mod item, but seems the ability to add inventory only searchable text was .... Um?

Since no subfolders... mumbles .. Steal a version of the Dewey Decimal System. Numbers force the Sort Order! | Category Number. Item Number --> 740.110 Steal the Numbering Trick from the Old days of C64 Basic, When starting... leave the last number in a part as zero, so can go back and add more. Of course I forget what they mean sometimes, so the trick is brevity for the first part of a outfit name. Leaves room for the descriptors, makes so not have to expand the window side to side as much. Also it helps to separate the Descriptors with a / Of course still have to scroll up and down and up and down. Shame that is not a 'jump to' button. Down on the blank area at the bottom. Between Number of Outfits and Complexity of current outfit.

To Really, Really, Really..... Really. Hide the system hair. On a worn object, on one of the faces of the object... Set the object face transparent (not the texture on the face) & Set the Face to Grab the Hair Channel. This is How those system avatar hider objects work. This is just like how a mesh body part grabs the textures. Doing it this way negates the hair base from showing up, including potential alpha halo effects. Image shows exaggerated system hair as example, includes alpha blended 'background' to delineate the alpha halo. -- Would be simpler and easier if mesh head, eye, and body makers took advantage of this application of BOM and included relevant faces as needed.

Attachment Points? Default v/s Hair on head & shoes on feet!

That is the 'GOOD' use case for a time limit. Testing What & How a thing works v/s How will it look with dozens of other items. Unlike some click counter that can result in the need to 'really start altering the mechanics'. This use case allows to add the 'is a demo 'thing'' w/o messing about with other 'real workings'

FBF -- Full Bright Forever FLF - Face Light Fans SSC - Society for Script Counter Use (Complete with a TLA for the 4 letter phrase) !Q-CUSS - !quit Chat User Support Society

In the case of Payment Info v/s non payment info on file, Payment info on file was the initial default case for everyone. So even if it did not say Payment Info on File, Payment info was on File. While Non Payment Info on File users can walk away w/o giving additional information. Continuing the use of that then just goes back to some Hypothetical level of user accountability. As to 'regular' Premium / Premium plus, I didn't see that directly on the profile. Only thing I see for that is llgetobjectdetails (Object_account_level). As to the why, dunno?

Again. Done to imply that LL can, in theory, discern between users accountable to a actual human v/s just a machine at some location. As to others use cases, I won't speculate. As to my own use case, I wouldn't want to purchase anything like full perm items with an intent to resell / redistribute from a user that is Not Payment Information on File. Even if the link between Payment info on file and actual accountability is exceptionally tenuous. As to revealing if a user is Premium v/s just Payment info on File, why they would include that? Don't know. Just that I can see the rationale behind it being 'Well it can be found the long way around' ie the outside of the ability of 99.999999999% of Residents

I think the distinction here is this. After completing the transaction, and with no indication that this would occur, the 'How' the service is paid for is revealed to other users.

While Premium Member status is accessible via script, it is also just inferable by 'Does X account own mainland? Thus open info. Back in the 'Long ago times', apparently all accounts were payment info on file. Thus the default state. Basic Account: Second Life Fandom Wiki "The first basic account on a credit card is free, all other basic accounts put on that card are $9.95 (one time fee). Additional accounts also have a free 7-day trial during which the account can be cancelled" So No Payment Info on File was added later, when free accounts became a thing. Done to imply that LL can, in theory, discern between users accountable to a actual human v/s just a machine at some location, if needed.

Well.... Was Lifetime Premium, etc presented as an Extension of existing Business Relationships. --> Yes, Premium & Premium Plus Were Profile indicators or LSL queries which divulge the specific nature of that Relationship indicated in the information Provided with that Plan ie, Lifetime Premium, etc, at the time of purchase? --> No Is there somewhere a part that says "At anytime we (the company) reserve the right to release details of your Business Relationship to any 3rd party including other customers of the service"? --> Too lazy to reread the TOS, again. So... Is Divulging this information without the consent of Both Parties a good idea? ------- And Lifetime Accounts are 220 (or less customers). LL can use a whitelisted access control for that information. Available only to Employees (or Contractors)

Since I am too lazy to figure out how to easy quote from other posts in other threads.... From Coffee Pancake March 6, 2022 -- Putting parcel lines on the mini map was something we (Catznip) did, we do show parcels you can't enter in red, however .. the viewer isn't told about such restrictions till the very last moment. So what is going on is ... "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? .... tied to the 'How they decided to fix showing banlines in the inworld view' thing?" ie, AT THE LAST MOMENT So instead of actually reworking when and how the ban lines are sent to the viewer / user / customer to be displayed on screen. Lets just get the Customers to fight each other! YAY! THUNDERDOME!

It is Bakes on Mesh capable. What that 'really means' is: One or more of the object faces in the item linkset 'Grab' the lower body channel baked texture. Result: System Avatar Lower body 'paint job' is 'gone to there' / invisible / nothing from waist down on system avatar mesh is shown. Potential fix (but not advised unless are SURE is possible): If object face(s) mod, retexture to not grab the bake channel.

Well... Remember that while is is not as 'theoretically efficient' you can still use the SL UV map and have individual arms and individual feet. It is just a function of <Some object face> grabs the bake from <optional channel>. That is only an LSL switch. You don't even have to change the object mapping. It is possible if body texture maker uses the same texture on the left arm channel and left leg channel, and the mesh body maker has a BOM 1 (system skin as base), or a BOM 2 (universal layer as base) LSL switch. Is just that the system layers that we have to use are 'a bit muddled'. Universal lands on top of tattoo layer, and no alpha (expanded) layer.

Yeah. I can see the potential for visual confusion. As long as new end user sees in inventory an object icon with associated name of hair, then is more apt to grasp the connection / pattern. Interesting screenshot, though. Animation Controller? Okay. *whispers* Animation Override Controller, maybe? Experienced user: "New guy. Turn on your AO (animation override)" Reply; "Huh? What?" Experienced user: "Hey new guy. You need to turn on your AC." Reply: "But is January in Upstate New York!" It only seems Pedantic, but preexisting term is preexisting. Like Skullcap Object hair is HAIR

Too lazy to look at in Aditi.. so please clarify If the Skullcap type hair objects are named hairbase then is just 'Well here is more jumbled vocabulary and definitions'. However if are just being referred to in this thread as such, disregard. Current usage is hairbase for both the old system hair (head icon), and tattoo or universal layers with the that function as also named hairbases. Which already can make communication of how to debug a system hair poke thru to be problematic. So as an aside, if not already present in the NUX heads, It would be EXCEEDINGLY useful to have a additional object face hidden and set to alpha and set to grab away the system hair channel. This then just makes 'Poke thru' go away. But back to skullcap hair objects... They are needed if used with an avatar head that is SL UV mapped. If one attempts to just use a layer to paint a hairbase, there is a crack in the top of the head due to the SL UV map itself.

SL Hiccupped when the outfit was saved/resaved. Yup. It is supposta work, but is SL! The Hiccup is similar to when you save a new outfit and 'Ooops!' The outfit is empty. The layer order of a layer type is just 'hiding' in that saved outfit 'link'. And as said above, then you can adjust via wrench icon. Alas... if Only.... Wouldn't it be nice if the end user could predefine the relative order of a layer type. Think of it almost like how attachments work. -- Layer Slots (of a Layer type) -- Upon first addition of a layer, the final end user could select something like Universal Slot A, Universal Slot B, and so on. The layer keeps that bit of info in itself. Then later you can just add or substitute a layer or multiple layers, and then they land in the right place between other layers of the same type. Ya know like a way to sort them by the actual function of the image, and final end user can adjust if needed. Keep from having to Wrench Icon and adjust the order and resave 'every single time' you change to a new and different layer. Ya know, is really just Bookkeeping. Alas...

Correct. Your only recourse is to refer to the Wiki entry and find which sliders don't matter. Hence the include the information in the viewer so end users / new users not just think "Well that is Broken!"

Not you, the end user, put in an asterisk. Designer of the Interface panel on the screen to include an asterisk. Include the asterisk, like a footnote in a document, next to slider options that control shape elements that are irrelevant in configuring mesh bodies or heads. Irrelevant, because there is nothing to connect with the rigging.

right click in inventory > new body part > new hair. That head icon thing. The Eyebrow section affects mesh head shape.

As long as the bicycle with training wheels is actually a bicycle....

Useful UI fix: In edit shape floater & edit system hair (eyebrow shaper) floater Put in an asterisk next to the sliders that DO NOT correspond to a workable rigging adjustment https://wiki.secondlife.com/wiki/Project_Bento_Skeleton_Guide#Unsupported_controls

And with all the flippers, TURBO SPEED.

Of course they don't know how to change shoes. It is actually technical. Would need mentoring. The creator community did come up with 2 somethings: interchangeable / separate object feet or 'High end' automagic flipper feet. While the option posited by Theresa Tennyson works. One can have a foot replacement built into the shoe and use an Alpha layer to negate the existing foot. There is an erratic bug where if object face is set to Alpha Masking or None & a transparent texture (or transparent composite texture) on the face, because the 'phases of the moon' it just up and reverts to Alpha Blended and Breaks it. Is why I forgot about that mechanism earlier in the thread.