[PBR LSL funtionality is lacking existing legacy material features]

Just now, Kplh said:

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:

1. Object has PBR material with Texture A as base colour applied by item creator.
2. A user who bouth that object applies texture B to the base colour texture to override it.
3. They add my script to the object and my script want 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...

Try testing with an alt.   You should find the texture applied in step 2 is preserved.   I've been experimenting with objects using materials made by a friend.   The objects are full perms to me, but I don't have copies of the materials in my inventory, and the examples I posted above preserve my friend's textures (i.e. they don't set them to "").

Dave P (Runitai Linden) told me that LSL can see the texture uuid, and use it, even though it won't tell you what it is unless you have the correct perms.   

Try it.

[PBR LSL funtionality is lacking existing legacy material features]

1 minute ago, Kplh said:

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?

Blinn-Phong (traditional LSL) layers and GLTF layers are different.   Changes to the Blinn-Phong layers don't affect GLTF and changes to GLTF don't affect Blinn Phong.    So if you want to use PBR but want the object to look as expected for people using non-PBR capable viewers, you need to set both the Blinn-Phong and GLTF characteristics.

[PBR LSL funtionality is lacking existing legacy material features]

9 minutes ago, Kplh said:

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.

Yes, I know.  However, the examples I posted retain the existing texture.  Try them with an object of your choice.

[PBR LSL funtionality is lacking existing legacy material features]

You don't need the texture uuid, though, to work with the new PRIM_GLTF_* flags.  See https://wiki.secondlife.com/wiki/LlSetPrimitiveParams for more details.

The following examples use llGet/SetPrimitiveParams for the sake of simplicity but you can, of course, use llGet/SetLinkPP too.

Let's take a look at PRIM_GLTF_BASE_COLOR, which has the following arguments

 [PRIM_GLTF_BASE_COLOR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector linear_color, float alpha, integer gltf_alpha_mode, float alpha_mask_cutoff, integer double_sided ]

In effect it combines PRIM_TEXTURE (string texture, vector repeats, vector offsets, float rotation_in_radians),  PRIM_COLOR (vector linear_color, float alpha) and PRIM_ALPHA_MODE (integer gltf_alpha_mode, float alpha_mask_cutoff).   The final argument, integer double_sided, specifies whether the face is visible from both sides or only one.

Something like

default
{
	state_entry()
	{
		llOwnerSay(llList2CSV(llGetPrimitiveParams([PRIM_GLTF_BASE_COLOR,0])));
	}
}

may return something like 

, <1.000000, 1.000000, 0.000000>, <0.000000, 0.000000, 0.000000>, 0.000000, , , , ,

because LSL won't return the texture uuid.    It's also returning empty fields for the colour vector, alpha value of the colour, alpha mode and cutoff, and double_sided because, in this case, the creator of the material didn't set values for them.   

However, even though you can't read the texture uuid, you can still use it:

integer iFaceToChange = 0 ;//change this to the number of the face to change, 0 in this example
integer iGLTF = 48; //value of the flag PRIM_GLTF_BASE_COLOR, but easier to type
list lTemp;
vector vColourToUse = <1.0,0.0,0.0>; // change this to the vector value of the color to use (x, y and z values between 0.0 and 1.0);

default
{
    state_entry()
    {
        lTemp = llGetPrimitiveParams([iGLTF,iFaceToChange]);//read the current gltf_base_color values of the face you want to change
        //this returns a list [ string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, float alpha, integer gltf_alpha_mode, float alpha_mask_cutoff, integer double_sided ]
        lTemp = llListReplaceList(lTemp,[vColourToUse,1.0],4,5);//change the value of items 4 and 5 in the list (lsl starts counting at 0), "vector color", to that of vColorToUse and 1.0 is the alpha value (fully opaque
        llSetPrimitiveParams([iGLTF,iFaceToChange]+lTemp);//and apply the new values
        llRemoveInventory(llGetScriptName());//delete the script after it's finished
    }
}

This will turn face 0 of the item red.

If you want to make it less than fully opaque, you'll need to need to specify the alpha mode and alpha mask cutoff, too

lTemp = llListReplaceList(lTemp,[vColourToUse,0.5,PRIM_GLTF_ALPHA_MODE_BLEND],4,6);

would set the alpha to 0.5.     

If you want to make things fully invisible, though, it's recommended that you use PRIM_GLTF_ALPHA_MODE_MASK.

To toggle the visibility on and off, try this

integer iFaceToChange = 0 ;//change this to the number of the face to change, 0 in this example
integer iGLTF = 48; //value of the flag PRIM_GLTF_BASE_COLOR, but easier to type
list lTemp;
vector vColourToUse = <1.0,1.0,1.0>; // change this to the vector value of the color to use (x, y and z values between 0.0 and 1.0);
integer iVisible = TRUE;
default
{
    state_entry()
    {
        lTemp = llGetPrimitiveParams([iGLTF,iFaceToChange]);//read the current gltf_base_color values of the face you want to change
        lTemp = llListReplaceList(lTemp,[vColourToUse,(float) iVisible,PRIM_GLTF_ALPHA_MODE_MASK,1.0],4,7);
        //
        llSetPrimitiveParams([iGLTF,iFaceToChange]+lTemp);//and apply the new values
    }

    touch_end(integer num_detected)
    {
        iVisible =!iVisible;
        lTemp = llListReplaceList(lTemp,[vColourToUse,(float) iVisible,PRIM_GLTF_ALPHA_MODE_MASK,1.0],4,7);
        llSetPrimitiveParams([iGLTF,iFaceToChange]+lTemp);//and apply the new values
    }
}

You can alter the texture offsets, repeats and rotations in a similar way by updating the values of 

vector repeats, vector offsets, float rotation_in_radians

You can also use PRIM_GLTF_EMISSIVE as a substitute for fullbright.    This uses the arguments

 [ string texture, vector repeats, vector offsets, float rotation_in_radians, vector emissive_tint ]

Using <0.0,0.0,0.0> as the emissive_tint is the equivalent of setting PRIM_FULLBRIGHT to FALSE.  So you could do something like this:

integer iToggle;
list lTemp;
list lColours =[<0.5,0.5,0.5>,<0.0,0.0,0.0>];
vector vTint;
default
{
    state_entry()
    {
        lTemp = llGetPrimitiveParams([PRIM_GLTF_EMISSIVE,0]);
        vTint = llList2Vector(lColours,iToggle);
        lTemp = llListReplaceList(lTemp, [vTint],-1,-1);
        llSetPrimitiveParams([PRIM_GLTF_EMISSIVE,0]+lTemp);
    }

    touch_end(integer num_detected)
    {
        iToggle = !iToggle;
        vTint = llList2Vector(lColours,iToggle);
        lTemp = llListReplaceList(lTemp, [vTint],-1,-1);
        llSetPrimitiveParams([PRIM_GLTF_EMISSIVE,0]+lTemp);
    }
}

 

 

[llGetObjectDetails(id,[OBJECT_CREATION_TIME]) issue]

22 minutes ago, Wulfie Reanimator said:

Yes, I understand. With the exception of that one caveat, what I said holds true.

It was that one caveat that tripped me up earlier, though, which is why I wanted to clarify the point.

[llGetObjectDetails(id,[OBJECT_CREATION_TIME]) issue]

1 minute ago, Wulfie Reanimator said:

Is there a difference?

When you rez a new object with build-tools, that's when that object is originally created. When you upload a mesh file, that's when that object is originally created. (Whether it uses the current date or the source file's date doesn't matter much.)

Either way, OBJECT_CREATION_TIME returns the same date for all copies of whatever the original asset had as its creation date.

No, if you upload the same mesh file on two separate occassions, it looks as if the second one you upload with have the same creation time as the first.  

If you want them to have different creation times, you need to export the mesh twice, saving it with different names (?) and upload each of them.    

[llGetObjectDetails(id,[OBJECT_CREATION_TIME]) issue]

4 minutes ago, Love Zhaoying said:

I am curious whether this returns the actual "object creation date/time in-world" for non-mesh items and/or items that were not "imported" into Second Life in some way. 

Whether this means "when the ORIGINAL" object was created by the creator, or "when the object instance was rezzed"..

..?

 

The wiki accurately says it's when the original prim was rezzed, not when the object was rezzed from inventory. 

So I suppose an alternative solution would have been to rez two separate boxes, one a second or so after the first, shink them and make them invisible, and then link them to two instances of the same mesh as the root prim.

 

[llGetObjectDetails(id,[OBJECT_CREATION_TIME]) issue]

4 minutes ago, Wulfie Reanimator said:

This may be a side-effect of how uploading identical assets works.

For example, if you upload a texture... and then upload the same texture again, you'll get the same texture UUID both times. Basically, LL will check if the asset already exists, and then give you that copy instead of creating a brand new one. I hadn't tried it with mesh, but it seems very likely that they handle all assets the same way.

So the safe plan would seem to be to re-export the mesh with a new name, or something like that, before re-uploading it.

[llGetObjectDetails(id,[OBJECT_CREATION_TIME]) issue]

The Wiki seems to be mistaken, or at least misleading, when it says that this flag

Quote

Gets the object's creation time. This time is established with raw material rezzing through the build menu and with mesh uploads. This time is NOT established with inventory rezzes, scripted rezzes, object modifying, copying or transferring. If id is an avatar, an empty string is returned.

Today a friend and I noticed that 

 llOwnerSay(llList2String(llGetObjectDetails(llGetKey(),[OBJECT_CREATION_TIME]),0));

returned the same time for two instances of the same mesh that she had uploaded at different times.      

Further experiments suggest that the time returned is, in fact, the time the mesh was exported from Blender, not the time it was uploaded to SL.

Could someone please verify this and, if they have edit permissions for the Wiki, clarify the entry?   

I wanted to use OBJECT_CREATION_TIME to distinguish between two otherwise similar objects belonging to two competing teams in a game -- I don't like using object names/descriptions for this kind of thing, because they're subject to change, while OBJECT_CREATION_TIME isn't.   

But it would seem that, to use it this way, you have to export the mesh from the 3D creation programme twice and upload the results and not, as we had thought, just upload the same mesh twice.

[Oh my Gawd! - Totally unOfficial Pet Peeve Thread.]

7 minutes ago, Arielle Popstar said:

I use the newest Adblocker and not seen any issues yet in Chrome at least. Firefox is a different story.

I use Vivaldi, and haven't had any problems either. Though since Vivaldi uses Chrome extensions, I suppose that's hardly surprising. 

[Oh my Gawd! - Totally unOfficial Pet Peeve Thread.]

36 minutes ago, Marigold Devin said:

Ah but Silent is not here in the UK with us, where the customer service had certainly gone downhill over the years (yet they dare to send out text messages and emails asking "How did we do?"!). 

My internet service provider and fuel company has this "hilarious" paragraph in their monthly bumph that advises me there are other ISPs and fuel companies and I might want to compare prices/offers.

It seems they don't want or need my (our) business!

Silent, though, says, 

Quote

 You do have to ask. All I had to do was explain my needs and limits after I told them I would have to find another bank if they couldn't accommodate my needs. 

That's a bit different from simply closing your account and move it elsewhere (to take advantage of the new bank's offer of a cash bonus for moving accounts?).   Silent was asking the bank if they wanted to keep her business rather than presenting them with a fait accompli.  

[Oh my Gawd! - Totally unOfficial Pet Peeve Thread.]

13 minutes ago, Scylla Rhiadra said:

Looking it up, there's quite a tradition apparently! Anne Boleyn too! (We'll try to overlook the fact that women who had milk baths in history often seem to have ended up violently dead.)

Catherine Parr, not Anne Boleyn, at least according to Wikipedia.   And Elizabeth I, too.

 

[Second Life is already running error]

Stupid question, but have you tried applying this setting?  (Screenshot from the Official Viewer -- dunno where it is in Firestorm).   You can access it without being being logged in, though you may need to restart the viewer after turning it on.

 

Alternatively, if that doesn't work, try rebooting your router.   That fixes a multitude of issues, at least in my experience.

[Using sensor to populate dialog box of nearby avatars]

This is from an example I made ages ago.   I used llGetAgentList because I didn't want to worry about llSensor's limits, but that's not material.

Anyway, instead of using stridied lists, I built two lists when I called llGetAgentList

      key k = llList2Key(lTemp,iMax);
      lNames +=[llGetDisplayName(k)];
      lUUIDs +=[k];

I used the example that Rolig posted above to generate number buttons corresponding to a list of names in the llDialog caption, and then, in the listen event, when user chose a number, I looked up the corresponding name and key thus

        integer n = (integer)message -1;
        llRegionSayTo(kToucher, 0, "You chose: " + strChoice = llList2String(lNames,n)+", uuid "+(string)(kChosenUUID = llList2Key(lUUIDs, n)));

 

[Need Help With Linden pay. Getting ConflictingInfo]

As I understand it, the real question is "Is my prepaid Visa card one that will automatically approve the transaction when Tilia asks for payment or does it need to refer it back to the card issuer for approval?"   If it's one that approves the transaction automatically, you can use it to buy L$.   Otherwise, you can't.   

It seems that most prepaid cards do require authorisation from the issuing bank, which is why usually you can't use them, but some will issue the payment without needing authorisation.  Unfortunately, you can only find out which type your card is by trial and error.    That, I think, is why you're getting confliction information.

["People that play Near You" search option In Second life]

"People that play...."   Second Life is not a game.   That is all.

[Oh my Gawd! - Totally unOfficial Pet Peeve Thread.]

38 minutes ago, Bagnu said:

LOL, I'm sure pics of my computer room would make a "Matrix" fan salivate, but I think anyone who doesn't fall into that category would go "Ewww". It ain't pretty. Which is exactly how I like it.

At a business meeting I recently attended on Google Meet, someone asked one of the participants, when he asked for questions after his presentation, "Are you really calling in from the command deck of the USS Enterprise?"

[Oh my Gawd! - Totally unOfficial Pet Peeve Thread.]

55 minutes ago, Love Zhaoying said:

Peeve: Assuming "knowing what someone's computer room looks like" is code for "we spoke on webcam".

Ewww..TMI!

(Why "Ewwww"? If all you did was "speak" on webcam, then there's no need for a euphemism such as "know what my computer room looks like".)

Or you know what virtual background they're using on Zoom.

 

 

[Invisible prim not showing up in wireframe ... help!]

Could the original piece of furniture be ghosted?  That would explain what you're describing, including the invisible object's not showing up in wireframe or area search.

I'd suggest restarting the region if you can (or asking an estate manager or LL to restart it for you if you can't) to see if that fixes it.  

 

[How would you feel if Second Life had a like/dislike rating for residents?]

I think we should have an "infamy" rating.

 

 

[Best SL names you spotted...]

I am told there is, or was once (I can't find him in search), a Hoosier Daddy.

["Fun Ideas" for SL-Related Support Groups!]

Self-Publicists Anonymous probably wouldn't work too well.

[Self-Care September Promotion & SL Groups]

On 9/11/2023 at 1:12 PM, Lyric Demina said:

Exactly.

I'm surprised -- but actually relieved and delighted too -- that nobody thinks of chemotherapy and cancer patients immediately when the idea of "support groups" comes up, especially given the prevalence of RFL in Second Life.  When a person takes chemo, or radiation, or is treated for the sundry cancers generally, in my country one of the first things a doctor will recommend is to join a support group of other people going through it too.  It doesn't (necessarily) require psychotherapy; but it does require support.  "We're going through it too, you can come talk with us."   And the support groups I have found most helpful have been in fact the ones that were virtual; the ones that were type-chat, or message-board chat, or Second Life chat. 

It seems like a no-brainer for me to cheer for virtual support groups but perhaps (and I really hope) that's indicative of the general good health of the rest of this thread, which is fantastic

When I was undergoing chemo- and radiotherapy for throat cancer ten years ago I found the online help and support offered by the Macmillan Online Community invaluable.   

But that's run by the UK's leading cancer support charity, staffed and moderated by trained healthcare professionals.

I also found invaluable the help and support offered by those close and trusted friends in SL with whom i chose to share my medical problems, but the two forms of help and support were very different.   

And I have to say that I often found my patience sorely tried by some of the pseudo-medical dietary and spiritual advice offered by some well-meaning friends in both First and Second Life.   However, I could not really be too annoyed with them because I knew they were only trying to be helpful, so I suppressed the urge to tell them what to do with their crystals and nutritional supplements.

[Self-Care September Promotion & SL Groups]

I'm of an age (and background, perhaps) to have been taught never to set anything down in writing that I wouldn't be prepared to see published on the front page of a newspaper or hear read out in court.

I can't say I've always followed that advice but I certainly do, at least most of the time and always unless I completely trust the possible recipient, online, whether in SL or elsewhere.

That is all.

[TIL - Today I Learned .. share something you learned for the first time]

Not today, but only recently did I learn that in Windows 10 and 11 holding down the Windows key + V opens up your clipboard history and allows you to paste items from it.   Very useful.