Kristy Aurelia

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.

Sound similar to what I'm seeing, 400ms ping pretty much everywhere... started about 2 days ago... tracert shows gin.ntt.net network a culprit: Tracing route to simhost-0bcc34323c1ea6cea.agni.secondlife.io [54.184.44.5] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms <REDACTED> 2 1 ms <1 ms <1 ms <REDACTED> 3 * * * Request timed out. 4 8 ms 7 ms 8 ms <REDACTED> 5 8 ms 8 ms 8 ms <REDACTED> 6 8 ms 8 ms 8 ms core5-hu0-0-0-35.faraday.ukcore.bt.net [62.6.201.244] 7 8 ms 8 ms 7 ms 166-49-209-132.gia.bt.net [166.49.209.132] 8 8 ms 8 ms 8 ms 212.119.4.140 9 16 ms 23 ms 10 ms ae-7.r20.londen12.uk.bb.gin.ntt.net [129.250.4.140] 10 357 ms 352 ms 365 ms ae-7.r20.nwrknj03.us.bb.gin.ntt.net [129.250.6.147] 11 340 ms 372 ms 412 ms ae-4.r24.sttlwa01.us.bb.gin.ntt.net [129.250.6.177] 12 462 ms 428 ms 375 ms ae-0.a03.sttlwa01.us.bb.gin.ntt.net [129.250.2.99] 13 382 ms 400 ms 417 ms ae-0.amazon.sttlwa01.us.bb.gin.ntt.net [129.250.193.10] 14 * * * Request timed out.

Releasing a new body is pretty much the most difficult thing to do in SL anyway - there is no winning scenario: 1. If you do nothing, based on my experience, I have been seeing more and more Legacy/Reborn exclusives in events (or maybe just the type of clothes I like are swapping over... I might be biased). If creators continue swapping over to different body, the users will do so as well eventually, and the body will be abandoned. 2. If you release a completely brand-new body, you have to compete with existing bodies, all existing content for that body and try to attract creators willing to put extra effort for a body that might not become popular to be worth it. Also, bodies tend to be expensive, so users won't want to risk jumping onto a new body if it does not have any ground breaking features. 2.1 If you release a new body after Scenario #1 has happened, you don't have to compete with your old body, but, by that point, the other bodies will have become a lot more established. 3. If you do a minor update that is fully backwards compatible, you can't really change anything significant to address any of the issues. And that may lead you to Scenario #1 So, what is there left to do? To me it seems like the current case of releasing a free update that contains a second body is a compromise - it gives a chance to fix issues creators are having, which might lure them back in and avoid Scenario #1. By not making a completely breaking change, you encourage people to try it out, as at least some part of their current wardrobe will still work. By giving it out for free, you don't ask current user base to gamble their money on a body that may or may not become popular. Also, creators know that there is a large userbase that do have that body, so they might be more willing to try it out and make some clothes for it. If this scenario doesn't work out, people will continue using their current stuff and nothing will change. Sure, there will be wasted effort on making that body, and for some creators that do make stuff for it. Just like with any new body release. If it does work out, it will be the same result as if any other brand released a brand-new body that people liked, they will migrate over and abandon their old collection of clothes, maybe not all of it, depending on how different the rigging actually ends up being. I imagine there will be some creators who will be making a Lara and Lara X versions, just like they do with Lara & Petite versions. Anyway, I remain cautiously optimistic.

I do know very well what it entails, and they do exist, you just need to go to the special sandbox regions on the main grid, or to the test grid where it has been available for a very long time. So you can have perfectly working scripts all ready to go. And for all we know, the Lara X release date might be after PBR goes live when all of this is actually avaialble grid wide.

Updating 5.3 might be for PBR support?

But, isn't that's what they did? The update will contain the existing Lara 5.3 and Lara X and it is a free update.

Sure, but if you want hidden ears, just make a second copy of the head with hidden ears, equipping a different head is easier than looking for the option in the HUD - you can save different versions to different outfits. I've done it with some of my hairstyles, where I combined the main hair and bangs together, removed scripts etc. If I want a different colour, I can unbox a new copy and use that, and if I want, I also have an option to modify a second copy in the same way. To elaborate more on the custom alpha script: I wouldn't except 'the certain 3 letter brand' to be able to script it properly, but you could throw in an extra script in your body, and enable RLV items show/hide arms and such. Obviously, it would be nicer if the alpha script API was public, but that does actually require more effort from the body creator compared to just ticking a checkbox (unless they just make all the script mod too, but... that would allow stolen meshes to reuse original scripts, and also intercept applier texture UUIDs. In that regard, making scripts mod, does actually have downsides, unlike meshes). Also, if a HUD is scripted not to rely on link numbers, but on names/descriptions, it would still work. As you said, people who don't care won't touch it anyway, but they are not losing anything either, and those who do touch it, know the risks and how to work around side effects. Creativity should be encouraged on a platform like SL, an encouraging items being mod, and people learning how to take avantage of mod items is great. This is way off-topic, but Senra bodies not being full perm and the license agreement being more complicated than just "I agree not to use this for antyhing ouside of SL" is not helping either. To put it simply: making any mesh item mod only has additional benefits for those who know how to take advantage of it, and has no downsides to the creators or the ones who don't want to mod it anyway. Yes, I agree, it is important to know how much the shape will change and if existing items will fit the body, but it doesn't affect mod/no-mod what so ever, just because something is more important, doesn't mean that less important features should be ignored, especially when the less important features take no effort to add. Think of it this way - if you wanted to buy a black car, and they only made pink cars - and you ask the salesman, "Hey can I have a black one?" and they said "The car drives, and it has great fuel efficiency", yes, indeed - the car actually working is the most important part, but that does not invalidate request for different colours.