Wulfie Reanimator

Case 1, all unlinked prims: Rez 3 prims named A, B, C. Select C, B, A. Link them. Server-side link numbers: A, B, C. Viewer-side link numbers: A, C, B. (The viewer forgot the order each prim was selected. More prims show there's no logical order. The correct order could be easily predicted. The server-side link order is always the reverse of what you selected.) Case 2, linking a prim to an existing linkset: Rez 1 prim named D. Select D, then the previous linkset. Link them. Server-side link numbers: A, D, B, C. (D became first child.) Viewer-side link numbers: A, B, C, D. (Viewer simply appended the link. This used to be correct behavior. Server-side changes broke this prediction.) Case 3, linking linkset to another linkset: Create two linksets, first with A, B, C and second with D, E. Select second linkset, then the first. Link them. Server-side link numbers: A, D, E, B, C. (Second linkset was inserted as first child while maintaining its sequence.) Viewer-side link numbers: A, B, C, D, E. (Viewer simply appended the linksets. This used to be correct behavior. Server-side changes broke this prediction.) I never understood what the reasoning for the server-side change could've been. It seems like it could've even been a bug / unintentional change. I can't think of any benefit to changing the link logic from "new links go to the end of the linkset (very safe)" to "new links go to the beginning (changes ALL link numbers)"

While Animats is correct in what he's saying (link number info isn't sent to viewers unless it's a full update), viewers did show correct numbers in the past after adding links to a linkset. The viewer does also have enough client-side information to figure out what the new numbers should/will be. Link numbering is very predictable and consistent server-side. Figuring out why that's not the case now is pretty hard because the link update seems to be handled in LLViewerObject::processUpdateMessage which is about ~1400 lines long function. 😋

This has been an issue in viewers for years. The numbers will be wrong after linking. Re-rez the object and the link numbers will be correct.

PrimPossible is an ANCIENT brand that specializes in sculpties, and it's exactly how the "unlimited decor" works. It's been on Marketplace since 2013. Mesh used to be swappable by UUID too, but that was disabled. The reasons are documented on the wiki: https://wiki.secondlife.com/wiki/Why_UUID_Flipping_is_Bad

Ohh, I see. It's not really possible to create a perfectly smooth gradient like that by painting on the UV map by hand, because the UV map is not straight or continuous. When making textures for complex surfaces (especially when crossing seams), the best way is to do that is with Blender or Substance Painter or any 3D app instead of Photoshop/image editor. The 3D apps let you draw directly on the model and calculate where on the UV map the colors should go. Someone else will have to give detailed steps.

Looks like your body just has a specular map (material) on it. You should be able to remove it from your body HUD.

It supports 100 in a region, 50 in ad-hoc calls. This isn't really relevant for us because the IP would only be exposed to LL. (Unless you're worried about an attack coming from LL, but that's a whole other discussion.) Concerts happening through voice seems unlikely.

In the past, the answer would've been a simple "that's normal, SL doesn't render things the same way. We deal with it." But these days we have to ask: Which viewer are you using? LL has recently made updates to rendering. We have nicer reflections and even PBR materials. The LL viewer can render things just like Substance, especially if you export PBR instead of specular.

Said the painter to the digital painter.

Firestorm also shows the priority in the "attach to..." menu, it's the number at the end.

I know this, been here long before mesh. Do you want to go back? How do you propose we do that? I don't have any good ideas, there is too much flexibility in how the current system is used.

I play a bunch of different games, the clothing systems in them are not similarly confusing because they're much more strict systems. This includes IMVU as shown above, which I used to play before Second Life. You generally don't get to wear everything in one slot, clothes and accessories have well defined "this is where this goes" rules in games. Second Life doesn't have rules like this, you can wear your pants on your head and it'll look just fine because the attachment system is "object agnostic." There's no physical difference between pants and a hat. If SL was to totally remake the attachment system and create hard categories for mesh clothes (you can wear one thing classified as "pants" and that's it), the replacement feature would make a lot more sense as with other games. Those are the two ways to go about it, but I think making "add" the default action is much more practical.

You can put multiple items in the Marketplace product folder. You should probably read these knowledge base articles: https://community.secondlife.com/knowledgebase/english/selling-in-the-marketplace-r88/ https://community.secondlife.com/knowledgebase/english/managing-your-marketplace-store-r87/

Oh don't worry, I'm not making real updates to any viewers. The example I mentioned was just a personal change / concept to make a point about how simple the change could be. My personal opinion is that the vast majority of people are more confused than helped by the 'replace' feature, even if it could be made to work with lots of manual organizing of attachment points. (We can't rely on merchants to come to a consensus on which "standard attachment point" to use for bra/shirt/jacket or any number of accessories.)

When searching for "RazzaNova," the old items seem to show up earlier because they have that search term in the keywords (while the BOM products don't). That makes the old products more relevant with that term. The same won't happen while searching for more generic terms. The results will probably be very different and (mostly) easily explainable.

It would be very simple to present one option - "wear" - which either adds objects/layers or replaces the few special things. It's just a UI thing which doesn't even require any changes to the code of the viewer, and then nobody would have to even think about the difference. (I've posted an example of me making that change some years ago.) Heck, we should almost certainly at least make "double click add" a default, since it's an adjustable setting anyway.

Why not use the snapshot tool in the image picker? (Second button from the left.) It would skip a couple steps in your process.

Inventory previews are limited to 256x256 resolution, but you can use any size texture (upload from computer, choose from inventory) to create a preview. They just get resized down to the correct resolution.

Never mind, I might be confusing some things. I'll get back to you when I have more time to figure it out. 😋 I was able to add an image to the product folder in the viewer's "Marketplace Listings" window, and it was redelivered from Marketplace just fine.

Oh yeah, I don't think llGiveInventoryList has any way to include an image. BUT folders will also show first texture in the folder, if it contains one. Marketplace listings can give out folders with images though... I'm 99% sure. Can't test right now.

Just tested it with an alt: Sending a folder to someone with an image attached to it will transfer the image as well. That's how I would've expected it to work too, so that's good!

To be fair, the inventory preview feature is still very fresh, it always takes time for knowledge to spread and people to adapt. I don't think 98% of people realize that everything - inventory items and folders can have images attached to them. And probably 80% of that knowledgeable 2% might not have realized that you can add your own picture even to no-modify items.

Of course avatar complexity should be limited, but you were responding to (and arguing for) the most useless metric we currently have, while misinterpreting Beq and pretending you know what you're talking about. You're just moving the goal post now.

Beq did not do that. She said the opposite during the TPV meeting on March 15th. When she's talking about limiting avatar complexity, she's not talking about "Complexity." She even reiterates (multiple times) that she's talking about something entirely different.

Yeah, but I'm 80% sure it gets resized to 256x256, just like how you can choose 2K or even 8K files when uploading textures (which get resized to 1024x1024).