-
Posts
10,781 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Innula Zenovka
-
-
24 minutes ago, Kplh said:
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?
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.
-
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:
- 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 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.
- 1
-
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.
-
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.
-
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); } }
- 2
-
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.
- 1
-
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.
-
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.
- 1
-
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.
- 2
-
The Wiki seems to be mistaken, or at least misleading, when it says that this flag
QuoteGets 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.
-
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.
-
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,
QuoteYou 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.
- 2
- 1
-
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.
- 4
-
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.
- 1
-
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)));
- 1
-
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.
- 1
- 1
-
"People that play...." Second Life is not a game. That is all.
- 5
- 3
- 1
-
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?"
- 1
- 7
-
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.
- 3
- 1
- 2
-
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.
- 2
-
I think we should have an "infamy" rating.
- 1
- 1
- 5
-
I am told there is, or was once (I can't find him in search), a Hoosier Daddy.
- 3
- 1
- 2
-
Self-Publicists Anonymous probably wouldn't work too well.
- 4
- 1
- 2
Collision Start weirdness
in LSL Scripting
Posted · Edited by Innula Zenovka
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.