Make PRIM_PROJECTOR readable
tracked
Oggy Fink
I'm posting this here since my original post as a bug was closed with an "expected behavior"-type reply.
As referred to by the discussion mentioned in the LSL portal documentation for llGetLinkPrimitiveParams() ( https://community.secondlife.com/forums/topic/486118-only-set-ambiance-on-prim_projector/?_gl=11wd89ez_ga_T7G7P6DCEC*MTcwNjU2MzkwNS4xLjEuMTcwNjU2MzkwNy41OC4wLjA.#comment-2446570 ) the call with PRIM_PROJECTOR currently triggers shouting on the DEBUG_CHANNEL about an unsupported parameter.
I understand that PRIM_PROJECTOR is considered, for now, as write only, but I see no valid reason why it could not be readable at all.
The current situation is inconsistent in my opinion. While I understand the potential problem with texture rights, I believe the behavior of this parameter should be consistent with that of PRIM_TEXTURE: if the texture is in the prim's inventory, return its name, else if the owner has full permissions over the object return its UUID. Otherwise return NULL_KEY.
This is important to be able to "copy" a user-set parameter from one object to another for example, I want to read the parameters and send them to another object.
Please make PRIM_PROJECTOR behave just like PRIM_TEXTURE in this regard, as described in the discussion. Thanks!
Log In
Phil Metalhead
Suggestions on this were made back in 2022; Rider Linden was involved in this thread, then
vanished
when people clarified (the same day Rider posted!) that this should work the same as the PRIM_TEXTURE call, where it only works if the texture is in the prim's inventory.ST33LDI9ITAL Resident
Yea, this should be fixed tbh. Kinda ridiculous it isn't. It's broken functionality. Has been for years now. Was only supposed to be temporary, here we are years later and still broke. C'mon. Either fix it or give us a new function and params with actual working functionality and deprecate the old.
Allegory Malaprop
This was such a weirdly broken on release function, I don't understand why it didn't just use the rules that every other function that uses a texture UUID uses. It's all already there for texture, material, everything- why make special rules just for it?
I think it may be slightly more functional now than it was on release, when you couldn't even use UUIDs on write if you didn't also have that particular texture in your inventory full perm, so thank you for at least making UUIDs on write function as expected finally. I had to strip it out and completely redo an item (and I was so excited to be able to use it as a scriptable function finally! but I didn't want to include all the full perm textures in inventory all over the place...and I was also using it with llSetLink which made that even MORE complicated) as it was entirely broken to anyone but me after I found that nasty surprise the first time.
Daemonika Nightfire
I also cannot understand the prohibition of reading the projector UUID. Blocking makes sense if the object is missing a permission, but with fullperm objects this is absolutely pointless and only makes the work of scripters unnecessarily difficult.
The Lindens and the Firestorm team in particular should know very well that any texture UUID is not safe.
LG
Dae
Signal Linden
tracked