Talk:LlSetPrimMediaParams
ALL_SIDES does not actually work for this function (and would be catastrophic for performance if it did). This is a special case, and due to the complexity of the templates used to created this article, I am currently unable to update it with the correct information. Jeremy Linden 18:44, 30 November 2009 (UTC)
- I changed the responsible Template:LSL Function/face to make this possible. Also changed llGetPrimMediaParams and llClearPrimMedia accordingly, as I guess they're intended to behave the same way. --
(talk|contribs) 19:54, 30 November 2009 (UTC)
- I am surprised that it would be such a bad thing, I would have assumed you would just render the generated texture on multiple faces. I would have thought it would cost nothing to do this. -- Strife (talk|contribs) 05:29, 3 December 2009 (UTC)
- Unfortunately, I don't think I'm allowed (yet) to go very much into the details around what exactly is being rendered on the face, but suffice to say it's more resource-intensive than a normal texture. This really isn't something that would be a good idea with ALL_SIDES :-) Jeremy Linden 22:47, 3 December 2009 (UTC)
- *nods nods* sounds like a multi-pass rendering with the added abuse of shaders... *grin* glowing media ^_^ -- Strife (talk|contribs) 19:21, 4 December 2009 (UTC)
Anyone seen any sign of a llSetLinkPrimMediaParams?
I just tried to incorporate this into an exsiting item, when I realised the prim I wanted was a child...and with the advent of all the llLink stuff in 1.38 ....seems an obvious addition. Hippyjim Starbrook 01:50, 10 March 2010 (UTC)
PRIM_MEDIA_CURRENT_URL - 1024 or 255 bytes?
Testing in SL Viewer 3.2.9 (248932), I set, via scripting, a prim's face to an URL over 255 bytes and it didn't display on the Build float. However, there was no error setting the URL: in fact, the face seems to display the page properly. It looks like it's only the Build float that has no support for URLs over 255.
Gwyneth Llewelyn 17:14, 12 February 2012 (PST)
Whitelist question/request for clarification...
How does the whitelist matching actually work? In other words, will
https://mysite.tld/
also match
https://mysite.tld/onepage.html https://mysite.tld/a-different-page.html https://mysite.tld/yet-another-page.html
as well as
https://mysite.tld/folder/herebedragons.html
and even
https://www.mysite.tld/blog/2022/10/01/why-i-created-my-site.html https://anotherblog.mysite.tld/pages/?node=1273536
?
Probably the answer is 'no' for many of the above examples.
Ok, what about shortened URLs? These are great to save space, but will they be expanded at all before applying the whitelist? I guess not, but... shouldn't they? After all, so many companies (Google, YouTube, WordPress...) have their own shortening mechanisms — besides using the ever-ubiquitous https://bit.ly, of course.
These are also questions related to page redirections, as URLs change over time, but some friendly webmasters will remember to place redirects to the new pages... how will those be dealt with?
I know, I'm overthinking all of this 🧐 but a bit more clarification on how the whitelists work would be nice! 😅
— Gwyneth Llewelyn (talk) 12:39, 1 October 2022 (PDT)