llSetLinkGLTFOverrides
tracked
Wulfie Reanimator
At the time of writing, this function is still in development.
My understanding is that this new function is intended to reduce the complexity of llSetPrimitiveParams while being extensible enough for future overrides. If that's the case, I'm sincerely asking for the implementation to be re-evaluated from multiple angles.
- GLTF overrides are primitive parameters and shouldn't be excluded from llSetPrimitiveParams.
I'm hoping this point is self-explanatory. Splitting some params off to a different function is not very ergonomic from a scripter's perspective, especially when llSetPrimitiveParams can already set GLTF overrides.
- The proposed function has problems that are solved by llSetPrimitiveParams.
Most importantly, llSPP provides PRIM_LINK_TARGET so scripts can assign parameters to separate parts of the linkset in one go. This is
very important
for visual cohesion. If you change params via multiple calls, the changes can be individually observed as the linkset checker-boards into the new configuration. It's poor practice and looks ugly.Left: what scripters avoid. Right: what llSPP achieves.
If (eg.) OVERRIDE_LINK_TARGET was added to llSetLinkGLTFOverrides, it naturally follows that scripters would need a way to change which face is being affected. Being able to change only the same face number across multiple links is not very useful, so scripters would need OVERRIDE_FACE_TARGET as well.
Hopefully by this point I've illustrated why the new function should just be merged into llSetPrimitiveParams, the function is already designed to be extensible and GLTF overrides are in its domain. The new parameters
are needed
and would reduce
the complexity of the current "omnibus" parameters like PRIM_GLTF_BASE_COLOR. It's just that separating the overrides to a new function complicates things with problems that have already been solved.Please, take a moment to review the conversations that has followed the llSetLinkGLTFOverrides proposal on Discord, in the Scripting channel.
Log In
Spidey Linden
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.
Journey Bunny
I'll add that the link chaining ability is of some serious significance. It's not just code compactness or imagined "speediness" through getting it all in one call; it permits the ability to dynamically, programmatically define what needs to change. This is an essential piece for building scripted tools that can be configured by other users, and has a variety of gametic implications too (simply, being able to use game conditions to select from a subset of parameters to change, rather than being locked into a specific logic loop of paramater changes)