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)