MantisBT - opensim
View Issue Details
0008517opensim[REGION] Script Functionspublic2019-04-12 09:202019-05-14 12:37
ZauberParacelsus 
 
normalmajoralways
newopen 
 
 
Grid (Multiple Regions per Sim)
ubODE
.NET / Windows64
None
0008517: Blank texture entries in PRIM_TEXTURE instruction not working anymore
In Second Life, if you specify an empty string or the NULL_KEY constant as the texture in the PRIM_TEXTURE instruction for llSetPrimitiveParams and co, what the system is supposed to do is just apply the other parameters (offsets, repeats, rotation) without changing the texture itself. Because of this, scripts I've made that previously relied upon this behavior are now broken.

This is now broken in the current development builds of opensimulator. Though, I will note that opensim only supported specifying an empty texture. It does not correctly support NULL_KEY, and I do not think it ever did.
No tags attached.
related to 0008527new  PRIM_TEXTURE cannot change rotation without a valid texture under YEngine 
Issue History
2019-04-12 09:20ZauberParacelsusNew Issue
2019-04-17 05:28UbitUmarovNote Added: 0035140
2019-04-17 06:35UbitUmarovNote Added: 0035145
2019-04-17 06:49UbitUmarovNote Added: 0035147
2019-04-17 19:50ZauberParacelsusNote Added: 0035149
2019-04-18 05:20UbitUmarovNote Added: 0035153
2019-04-18 06:03UbitUmarovNote Added: 0035156
2019-04-18 09:00ZauberParacelsusNote Added: 0035157
2019-05-13 18:28Kayaker MagicNote Added: 0035202
2019-05-14 00:51UbitUmarovNote Added: 0035204
2019-05-14 12:37Kayaker MagicRelationship addedrelated to 0008527

Notes
(0035140)
UbitUmarov   
2019-04-17 05:28   
ill try to take a look on this asap.
(0035145)
UbitUmarov   
2019-04-17 06:35   
at SL, "", NULL_KEY or unknown UUID just destroy the face setting it grey
(0035147)
UbitUmarov   
2019-04-17 06:49   
looking to old code, it does seem we ever supported "" either

I think I do prefer our current code, ie does nothing ??
(0035149)
ZauberParacelsus   
2019-04-17 19:50   
I have products which rely on the old behavior. Additionally, the old behavior is useful for modifying the repeats/offsets/rotation of a texture surface without changing the texture and without having to obtain and extract the texture UUID via llGetPrimitiveParams(), etc. This helps to reduce code complexity.
(0035153)
UbitUmarov   
2019-04-18 05:20   
Ok change so "" will not change the texture.
but on PRIM_NORM and PRIM_SPECULAR it will be as NULL_KEY, removing the material

in future we may make this coherent

This is not as SPEC, and neither this or SPEC is what happen at SL
(0035156)
UbitUmarov   
2019-04-18 06:03   
changed again now "" and NULL_KEY will not change the texture ID on PRIM_TEXTURE
(0035157)
ZauberParacelsus   
2019-04-18 09:00   
Excellent, thank you.

And yeah, it may not be to spec, but sticking to spec isn't always a good thing, especially when deviating buys you more capabilities.
(0035202)
Kayaker Magic   
2019-05-13 18:28   
I'm pasting this note from mantis 8527 to make sure that ZauberParcelsus sees it:
I am now getting a result that is different than older versions of OpenSim (before the 8517 fix on April 18) and different from SL.

In PRIM_TEXTURE calls in older versions of OpenSim:
NULL_KEY replaced the texture with a dark gray
“” left the texture alone but allowed other parameters to work
“dummy” left the texture alone but allowed other parameters to work

In OpenSim after April 18:
NULL_KEY leaves the texture alone but allows other parameters to work
“” leaves the texture alone but allows other parameters to work
“dummy” causes PRIM_TEXTURE to abort and fail to execute the rest of the parameters

So the NULL_KEY behavior is a nice addition, but aborting on missing textures breaks a feature of OpenSim that I have used in many scripts. I had assumed there was no difference between “” and “dummy” and used “dummy” as documentation in my code to show that I didn't want to change the texture.

I went to SL and performed all the experiments again with this result:
NULL_KEY replaced the texture with dark gray
“” replaced the texture with dark gray
“dummy” replaced the texture with dark gray

The SL Wiki has this caveat to say about the texture argument:
“If texture is missing from the prim's inventory and it is not a UUID or it is not a texture then an error is shouted on DEBUG_CHANNEL.”
I saw no errors but may have missed them. I just saw dark gray textures result.

The Wiki goes on to say:
“The following constants can (optionally) be used for the texture value: TEXTURE_BLANK, TEXTURE_DEFAULT, TEXTURE_MEDIA, TEXTURE_PLYWOOD and TEXTURE_TRANSPARENT. ”
NULL_KEY is not mentioned in the Wiki (I'm looking at page http://wiki.secondlife.com/wiki/PRIM_TEXTURE [^])

I have never seen the behavior in SL or OpenSim of NULL_KEY leaving the texture alone, although I would welcome that as an addition. I have never seen SL do this behavior described by ZauberParcelsus in mantis 8517. I think the nice behavior on missing textures is a feature that was added (perhaps inadvertently) to OpenSim. I would welcome the addition of NULL_KEY but please don't break the behavior on missing textures.
(0035204)
UbitUmarov   
2019-05-14 00:51   
now if texture id/name is not found, "" or null_key the prim texture is the current one.