Innula Zenovka

So if I'm flying at 75 or 100 metres above the ground, are you saying that I won't know whether or not I'm allowed to fly over the parcel unless a security orb tells me to go away (or kicks me out)?

I have a question. According to the wiki, If you're flying, and encounter a parcel that's not set to public access, at what altitude do the ban lines cease to be visible? Or is that determned by your draw distance?

You can increase the maximum length of body to receive in the http_response event by setting, in the llHTTPRequest call, HTTP_BODY_MAXLENGTH,16384

You may have missed Henri's post earlier in the thread

I know it's very easy, or said to be, to create PBR materials with Substance Painter, but are there any tutorials about how to it with free tools like Gimp and/or Blender that you can recommend?

I want to post data to a google sheet and later retrieve it using shared media. To access the data and read it, I'm going to need to set up credentials for my inworld app. ChatGPT provides the following advice: I've got as far as the third step of Step 4: Create Credentials. My LSL will be calling llRequestURL. What URI should I enter, given that (I assume) it needs to be persistent?

Are you saying that Firestorm want to provide some sort of on/off switch for ALM, and have a way of doing this, but Linden Lab are somehow preventing them from implementing it? But somehow Henri's viewer gets away with it? Any Firestorm devs reading this who could maybe assist? @Whirly Fizzle?

You can, I think, tell Chat GPT to answer in as much or as little detail as you want, of course.

So I asked ChatGPT "What can you tell me about using a free Lelutka head in Second Life?" I followed it up with "How would I go about customising my free lelutka head?" and then I asked "Are there any blogs or youtube videos about customising Lelutka heads for Second Life that you'd recommend?" The final one includes links to the various blogs and videos but they haven't copied over for some reason.

On the basis that it must be easier for LL and the Moles to change/add to the houses available within a theme than it would be to change the theme (or the region landscaping) altogether, what variations on and additions to the Chalet Houses might make the theme more attractive?

My understanding was that, since OpenGL is no longer being developed, and is being supported by fewer and fewer game engines, LL had little alternative but to adopt PBR, the widely-used replacement for OpenGL, sooner or later. Apple no longer support OpenGL, I believe.

Who else do you know who lives in a hut with hen's legs?

I'd like to see this as an addition to the Fantasy homes

I really would suggest checking out the Winter Wonderland regions with the latest Official Viewer and World>Environment>Use Local Lighting enabled, to get an idea of what you can do with PBR.

Thanks, both. The snowball "guns" are firing single snowballs, which rez 0,25 metres in front of the avatar. The snowballs should normally travel comparatively slowly for about 12 or 13 metres before falling to the ground, unless they hit something first, at which point they lose their physics, stop, turn invisible and trigger some particles and sound effects before vanishing When they exhibit this problematic behaviour they generally travel about 3.5 metres or so, and then stop in mid air, where they think they've hit something. I can't understand it. It's not a big problem, and I've simply told the script to ignore collisions with NULL_KEY, but it's very puzzling.

I'm firing llVolumeDetect snowballs at people, and I need to know when they hit something so they can stop flying, turn invisible, trigger a particle effect and a sound, and then delete themselves. What would cause, in the collision_start event, llOwnerSay("collided with "+(string)llDectectedKey(0)) to say "collided with 00000000-0000-0000-0000-000000000000)" (i.e. null key)? It's not entirely clear what, if anything, the snowball thinks it's hitting, since quite often it seems to be something in mid air about 3 or 4 metres from where they rezzed, that's not actually there. or at least it isn't immediatly obvious with wireframe, bounding boxes or physics shapes visible. I've tried it on different regions, with similar results. It's an intermittent but frequent issue.

That's certainly what it means with GLTF. Not sure about legacy materials. I'll have to experiment.

This is me changing by script a full perms object to which a materials object has been applied that I don't have in my inventory https://gyazo.com/c4a67338ddfe58b09e727dc19f6825de The colour changes and the texture remains unchanged.

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.

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.

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

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); } }

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

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.

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.