llSetPrimitiveParams: allow skipping over params to keep current values
tracked
Thunder Rahja
In order to change the value of one parameter using
llSetPrimitiveParams
, the script must specify values for all
of the parameters for the given flag. With the addition of PBR, which can be changed in child links only
with this function, this has never been more cumbersome.I propose a new constant be added to preserve the existing value for the position it is placed in. A "NO_CHANGE" or "KEEP" constant could replace known or unknown values in order to preserve them while changing other values following a flag. Take this for example:
llSetLinkPrimitiveParamsFast(2, [PRIM_TEXTURE, 0, "12345678-1234-1234-1234-123456789012", <1,1,0>, <0,0,0>, 0]);
If we don't know the texture on face 0 of link 2, then we would need to add a second script in that link to change any of the above individual parameters, or we could have something like this:
llSetLinkPrimitiveParamsFast(2, [PRIM_TEXTURE, 0, NO_CHANGE, <1,1,0>, <0,0,0>, 0]);
Because some parameters require other parameters to be defined when changed,
llSetPrimitiveParams
should assume defaults (or revert to previously used values, if available) when not provided or currently in use, such as mask_cutoff
when PRIM_ALPHA_MODE_MASK is used.This feature would provide a significant quality of life improvement to scripters working with objects that they don't have all of the source items for.
Log In
SL Feedback
Hello, and thank you for your feature request regarding the
llSetPrimitiveParams
function. This particular suggestion has been brought up in the past and is currently tracked. We understand the significant quality of life improvement this feature would provide to scripters, especially with the addition of PBR and the need to change parameters in child links. While we have no estimate on when it may be implemented, please keep an eye on future updates. Your input is valuable, and we appreciate your continued commitment to improving Second Life.SL Feedback
tracked
Journey Bunny
I'd suggested--and it had been accepted--back in the Jira days, a "CURRENT_TEXTURE" parameter as an attempt. It would be really nice to have a catch-all "skip this and use what's there" parameter but it is likely to run into many issues with expected data types and compatibility with existing objects.
Eg, if the "skip_this" parameter compiled to an integer, scripts expecting a string would break. If it compiled a string, but not a valid one (for example, "none" when a UUID is expected) debug error messages are likely. If it compiles to NaN, LSO breaks
and
there's problems with functions that expected a UUID and got something else. And sadly, NULL_KEY already has other uses and can't stand in for "use same" (especially since it can be used for "remove current" and that's quite the opposite.How exactly it would be implemented would be harder than just a symbol meaning "skip this" but I think limiting the scope to the specific intended type of parameter should help, as decisions about "what does this parameter compile to mean" could have a bit of logic hooked to them if the context was clear.
For example, CURRENT_TEXTURE could compile to an inline reference to the return of a "figure out what texture to use" function. Such a function, knowing the context of the call and that a texture is required, could swap in the right information at run-time. And similar "compile to inline fetch calls" solutions could exist for whichever other kinds of parameters we need.
Up to LL ofc, whether this strategy is how they want to go about it, but some kind of way is needed, and at least one (CURRENT_TEXTURE) passed approval in the before-times so...would love to see it happen sooner than later.
dantia Gothly
how about instead we actually get proper transform functions for each of the options rather than having to supply all of them with one or two marked as null. when I want to just change an alpha value or just change an offset or change a rotation etc. If you want an no_op addition sure. but I would rather have the individual transform options over that as there own methods.
Ember Ember
+1 Yes, please!
Janet Rossini
Handy. And yes, use NO_CHANGE == NULL. It'd be nice. I wouldn't give it super high value among all the ideas one might have.
nya Resident
this'd be real handy
Lucia Nightfire
I want null params for placeholders to act as "no change" flags as well as PRIM_EXPECTED_TYPE type behavior for everything that follows so the server can auto-cast CSV2List data from notecard instead of the user/creator having to explicitly cast every value to expected type, wasting bytecode.
Bleuhazenfurfle Resident
This has been bounced around a few times so far, even acknowledged by the Lindens already. There are some suggestions, like an empty string for texture uuid/name, but questions on what value should be used for integers or vectors, the text to float text, etc.
I suggested a while back that we use NaN, because
nothing
accepts a NaN (where an empty string, 0's, etc., those weird JSON values, are all valid values for some fields), there's even been a few crashy bugs around them. (Could also just accept any off-type value as "no change", too, but all those errors vanishing is probably more of a problem.)llSLPP and friends can pre-scan the parameters for NaNs, and omit those fields — an interim implementation can simply substitute in the current value.
Thunder Rahja
Bleuhazenfurfle Resident: I didn't suggest "" or NaN because empty strings are used by some flags to clear a parameter (such as GLTF materials), and NaN is not a valid float value in LSO. I think it's better to be consistent by using the same value or constant across any parameters deliberately omitted.
In the absence of a true null value in LSL, any character outside of the printable character set (like
JSON_NULL
) or a unique character sequence (like EOF
) would do fine.Bleuhazenfurfle Resident
Thunder Rahja: Didn't I just literally address every part of that, except NaN's in LSO…? Or was that just a weird way to mostly agree with me? Anyhoo…
The LSO-no-NaNs thing is an issue that
had
slipped my mind, it's been so very long since I used LSO… But who cares. Existing scripts will still work, and it shouldn't actually clash with LSO in any way, they just won't get to use this new feature. Personally, I'm not too bothered by leaving LSO behind such optional functionality like this, if it gives us a nice clean consistent option.But yes, I do agree it is sub-optimal, and my OCD hates that too (so I'm more than open to any good generally applicable alternatives). However, LL were wanting to at least freeze LSO, so while they may not have been able to put the freeze on it, I don't see why adding new stuff to LSO shouldn't be on a best-effort basis, especially when not supporting LSO takes essentially zero additional effort. (And it's not like there aren't existing differences already.)
I'd also say non-printable isn't enough; PRIM_TEXT makes good use of \n's (so EOF is out right off). Among other things, non-printable characters are often used by compression (I've used that technique for numbers and UUID's especially) and I'm pretty certain there's at least a few properties that will store just about anything — which will break someone using those prim properties to squirrel away compressed values. That wipes out JSON_NULL, and also the otherwise rather nice new NAK, plus of course, the empty string…
NaN is literally the
only
value I can think of, that next to nothing
has any legitimate use for, so it would seem to be an excellent sentinel (LSO not withstanding).That said, a prior time I brought up using NaNs, however, I also suggested the alternative of having two different typed sentinels, and allowing them both to be used in any situation, except where one may be confused with an otherwise valid value (even if only technically). If they're unusual values, that would at least hugely reduce the possibility of hiding accidental errors that off-type alone incurs.
Jeremy Duport
Bleuhazenfurfle Resident
No need to get funny with repurposing existing signals at least in string space, unicode specifies plenty of freely meaningful codepoints through PUAs. https://en.wikipedia.org/wiki/Private_Use_Areas
Bleuhazenfurfle Resident
Jeremy Duport: What "existing signal" did I suggest re-purposing? I can't think of any primitive param for which a NaN makes sense (and over the couple years I've been suggesting this so far, no one has reminded me of any), and knocking them out of the running entirely would actually solve a couple bugs (if they haven't been solved already). So putting NaNs to use doesn't feel like "reusing" anything.
There is no integer that isn't a valid value somewhere, same for strings, regular float values (are the infinities used anywhere?). Vectors and rotations are both the same as float for this purpose, and lists aren't an option. Short of creating a NULL type, NaN seems to be the
only
general choice.Also, even those PUA codepoints are still valid for some fields — PRIM_TEXT, and some of the media fields, are popular for storing data and the likes. See my remarks about value "compression" using the UTF-16 space.