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.