Kristy Aurelia

Hmm... I do have quite a pouty expression and large eyes, though they're supposed to be leaning towards anime style contacts rather than 'childlike wonder'. I wonder... what about in very adult setting: https://iili.io/JGJwIcB.png

My avatar got quite a few confused faces. I think it is mostly due to my 'kawaii lolita' style and long pink hair.

So if you think the avatar looks like: a child (17 or younger) then react with a like, for an adult (18 and over) use thanks, and use confused if you can't tell based on physical appearance alone. Please don't respond to individual posts with written comments just use the reaction icons.

Also, I think I caught up with main points of the thread now. Composition vs Build Kit is an interesting one, I personally would prefer building kits. Also I don't mind paying extra for mod. That might be different to other people. I guess this would depend on your business model, but I can see the same argument from Singles vs Fat Packs be applicable here - you could set 2-3-4 however many cheaper prefab no-mod homes, but also sell a kit that is mod, more expensive, but also designed to be used as a kit. So if I want to move a sofa to the other side of the room, it doesn't leave an ugly baked shadow on a wall. Also, I have quite a few items that are 3-4 years old, a lot of them I can DIY PBR myself, it would be a lot of work for the creators to go through their entire catalogue and update all their creations. Mod is what enables me to do it myself. From a creators point of view - I have only released one item, and nearing towards completion of my second one. I am completely talentless when it comes to making textures, so I've UV mapped the meshes in such a way that it looks decent with a tiled texture and I can use a CC0 licensed texture, which I am also including in the package, and if people want to change it - they can. In terms of creative vision, I have seen some people fail at resizing it... So I've facepalmed... and I will be adding a resizer script in an update. I also gave them some tips on how to resize it properly. But yes, it did annoy me a bit that they made it look worse, but if they're happy with it, I'm happy too. I've also seen someone remove a few parts completely to achieve a different look which made me think "Huh, that works I guess, I didn't think of that". Also, in the circles I hang around, quite a few items we use have show/hide parts based on states. Old scripts do not support PBR, so me and my friends who wanted to PBR-ify those items, couldn't.... except... I made a helper script, that does make legacy and PBR alpha synchronize, which works okay for now, until LL do implement a proper fix. And we can just stick that script into any mod item we want, and mod PBR to our wishes, with old scripts functioning as intended.

This actually raises the point against people stealing textures, if someone acquires a UUID for a texture that only works on a specific mesh, they still need to buy the mesh. One of my main use cases is removing textures with ugly baked reflections and highlights as PBR now provides actual real reflections (where people setup probes that is, we really need more sim owners to update their sims, but that's for a completely different topic.). (I really hate baked reflections/highlights, but that's also a different topic) I'm hoping this is not too NSFW... but here's an example of how I updated one of my outfits with PBR: Before, with baked in white blob specular reflection: After just plain PBR material: Also especially with PBR, I wish creators provided normal maps as well, so I could DIY PBR stuff properly. Since it is the normal map that holds most of the detail. This is one of the reasons I've mention metals specifically in the google doc, as most metals tend to be smooth and do not require a normal map. Also quite a lot of objects work really well with tiled textures like buildings, or any objects that have large enough details define by vertexes rather than specific normal - a flat floor in a house is really easy to swap from tiled tile texture to tiled wood texture and so on. I have also updated my doc to mention what no-mod does to PBR materials, since I originally wrote it before PBR was released. And I've also added that I believe, and based on my friend circle: vast majority of yes-mod supporters are concerned about mod clothes, furniture, houses. And we understand that there are things like vendor systems, various game related HUDs and so on, do need to be no-mod.

I've made a google doc a while back listing all the reasons why stuff should be mod (at least all the ones I could think of, I'm sure there's more): https://docs.google.com/document/d/1Kosnx9oPTZMrMixtH35zvKUhDC2XlVt2HKZ-uH7csOM Since I've only noticed this thread now, I'll have to go through it later and add a few more points about stuff I noticed while skimming through it. Edit: Also worth noting, I only buy mod stuff, with very very rare exceptions, such as a body, or something that does need tampering prevention - like a board game or a gift card. And my own creations are mod-mesh, no-mod scripts and the scripts are even designed to not use specific link IDs, to allow people to do whatever they like with them.

Just FIY, sensors now scan up to 32 items: https://releasenotes.secondlife.com/simulator/2024-03-18.8333615376.html

I just used glitter as an example of what PBR would work great with, there are plenty of other use cases, 'better colour accuracy' doesn't sound as fun. Though, I guess metallic sci-fi parts would be a good example too.

Any mention of PBR materials/Appliers? Metallic glitter and such would look amazing with PBR.

Interesting bug in LSL PBR handling https://feedback.secondlife.com/scripting-bugs/p/pbr-colour-data-is-lost-when-setting-pbr-overrides So the colour/alpha seem to share the same override, so if you rely on making things visible/invisible, you might lose colour data. In that specific scenario, the prim starts with no overrides, and it cannot retrieve colour value from the material, but, changing alpha causes colour to initialise to white, and populate the override material with a colour that did not match the original material.

Yup, that is really annoying... with brands that do mod items, at least we can fix it ourselves... but... when you consider, it takes me a few minutes to fix my item... it takes the creator the same amount of time + a little bit more to repackage it in a box and setup a redelivery... so... let's use some fake numbers, if it takes me 5 mins to fix my mod item, and it takes the creator 10mins to fix and update vendors etc. Having 3 customers for that specific item, gives a net gain of 5 minutes fixing time saved... 100 customers? That's nearly 500 minutes of fixing time saved...

Anyone else finding Dimples of Venus agressively deep? Especially if you compare a with a RL picture from Wikipedia

'stateless scripts' - uhm, not really what I meant, I mean a script is like an exe, it uses no memory on the heap/stack until it runs. If the script code and stack/heap was separated. those could be move around separately. If you save the exe and memory separately, you could move exe around as you please, and then load in and let it work with a chunk of memory. Effectivery what hybernation does. But at the moment, the same memory budget is used by the entire script, including code, stack, event queue. global varaibles. And the code could be separated from that as it is static. Having separately controlled budgets for all of them would give the system the most flexibility. On a different topic: 32bit sim does sound stupid, you could go on a 30k prim sim, rezz 30k boxes and fill in ~3.7GB of LinkSetData. Edit: especially when you consider dropping 32bit viewer... which is used by large group of people on video variety of machines... while a sim is in a closed and controlled environment... Why wasn't the server updated to 64bit way before the viewer? Surely it is easier when there are no customers with outdated PCs to worry about.

Is that, on a mod object, with no-mod material preapplied? I hope not... otherwise, that will mean shopping for stuff will require not only items be mod but also materials to be mod as well... though that would be a topic for another thread.

Okay... so then... how many layers of overrides are there? Base PBR material (Step 1) <- overriden by User Changes to the material (Step 2) <- overriden by LSL changes to the material? Edit: "told me that LSL can see the texture uuid"... hold on, does that mean that the list gets populated with a UUID, which gets redacted for functions like llOwnerSay() or llList2String()? Does that also apply for legacy materials too?

Okay... so even though overrides help getting around some cases... my main point is still valid, of scripts not being able to change colour/alpha/etc when PBR is in use, when they can do that on legacy materials.

does 'someone' include... applying a full material from a material object in the inventory, and then manually editing a face, to have different base colour texture? For example: Object has PBR material with Texture A as base colour applied by item creator. A user who bouth that object applies Texture B to the base colour texture to override it. They add my script to the object and my script wants to make the item transparent... my script will receive "" as texture UUID, and setting transparency will set the override to "" meaning the texture applied in Step 2 is lost? I've not tested it fully on PBR sims because I don't have objects with restricted permissions made by other people, and if I make objects myself... I have full perms, so in those cases I do get the UUIDS...

Wait... what... just how many layers are there then... Base legacy materials <- Get Overriden by PBR materials (assuming capable PBR viewer) <- Get Overriden by LSL material? Edit: also that wiki page says: "upcoming PBR Terrain project.", but that's a separate later update, right?

If you do that, you'll pass empty texture to the function, which will in turn clear the texture, in addition to applying the colour changes. The point is - you've lost the texture now. If you want to make an object transparent, when you make it visible again, you want it to be visible with the texture it had.

With PBR being just around the corner, it seems that LSL side is lacking a lof of functionalit that legacy materials have. PBR does not have LSL equivalents for things like llGetColor, llSetColour, llGetAlpha, llSetAlpha, llSetLinkColor, llSetLinkAlpha, llGetTextureOffset and other similar functions. Which means, a lot of older scripted items that change alpha and such cannot be updated to use PBR materials. The new PBR llSetLinkPrimitiveParamsFast functionality all takes texture UUID as parameter, but you cannot get texture existing texture UUIDs due to permissions. Meaning, that you either need to have a texture UUID, or you cannot change alpha or tint colour or any other parameters without reseting the texture to blank. In practice what this means is if you have an item, which has multiple linked parts, which change hide/show one of them based on scripted state, you cannot apply PBR materials to them, because the show/hide will not affect PBR materials properly. Or if you have something that changes tint colour over time, that change will not be visible if PBR material is applied. I have raised a Jira for it ( https://jira.secondlife.com/browse/BUG-234689 ), but I think it is worth to spread the word as well, as from LSL point of view this is a step backwards as we effectively lose existing functionality or are stuck being unable to update existing items to use PBR, which is not good for overall PBR adoption.

This is probably the best long-term solution. Splitting code from memory would allow optimizations such as: when an avatar object comes close to a region crossing, the neighbouring sim could preload script code data over multiple seconds ahead of the avatar crossing the border, and on border crossing, it would only need to load in the actual memory part. If the avatar moves away, it could discard the code data at a convenient time. It would also help with silly things like global variable and function names eating up script memory. And it would give more flexibility for extensions in the future, such as increasing code memory, but not heap, or heap memory but not code etc. Code being separate also has an advantage that it would only change if a script is saved.

seems to be stabilising now.

I've been seeing a 50% packet loss over last 20 mins or so ... also took few attempts to login.

For anyone seeing *.gin.ntt.net in their tracert routes, I have received an update from them: Keep in mind that if you tracert doesn't go through those severs then you might be experiencing a different issue.

I've ran it with 50 hop limit, everything past hop 13 times out. I had someone from Germany run it, their path took around 26 hops before timeout and it was still under 190ms, similar with someone from France 19 hops and under 170ms. Someone from Ireland said that their connection was normal and their ping was around 200ms. So it seems around 200ms is normal between Europe and US. Which seems that my theory of being routed through gin.ntt.net is the issue is reasonably correct. Also, after google searching it seems some FF14 players are seeing a similar issue when their packets go through gin.nett.net and it seems it is not the first time they've had this issue.