Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008517opensim[REGION] Script Functionspublic2019-04-12 09:202019-05-14 12:37
ReporterZauberParacelsus 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusnewResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0008517: Blank texture entries in PRIM_TEXTURE instruction not working anymore
DescriptionIn 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.
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineubODE
Environment.NET / Windows64
Mono VersionNone
Viewer
Attached Files

- Relationships
related to 0008527new PRIM_TEXTURE cannot change rotation without a valid texture under YEngine 

-  Notes
(0035140)
UbitUmarov (administrator)
2019-04-17 05:28

ill try to take a look on this asap.
(0035145)
UbitUmarov (administrator)
2019-04-17 06:35

at SL, "", NULL_KEY or unknown UUID just destroy the face setting it grey
(0035147)
UbitUmarov (administrator)
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 (reporter)
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 (administrator)
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 (administrator)
2019-04-18 06:03

changed again now "" and NULL_KEY will not change the texture ID on PRIM_TEXTURE
(0035157)
ZauberParacelsus (reporter)
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 (reporter)
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 (administrator)
2019-05-14 00:51

now if texture id/name is not found, "" or null_key the prim texture is the current one.

- Issue History
Date Modified Username Field Change
2019-04-12 09:20 ZauberParacelsus New Issue
2019-04-17 05:28 UbitUmarov Note Added: 0035140
2019-04-17 06:35 UbitUmarov Note Added: 0035145
2019-04-17 06:49 UbitUmarov Note Added: 0035147
2019-04-17 19:50 ZauberParacelsus Note Added: 0035149
2019-04-18 05:20 UbitUmarov Note Added: 0035153
2019-04-18 06:03 UbitUmarov Note Added: 0035156
2019-04-18 09:00 ZauberParacelsus Note Added: 0035157
2019-05-13 18:28 Kayaker Magic Note Added: 0035202
2019-05-14 00:51 UbitUmarov Note Added: 0035204
2019-05-14 12:37 Kayaker Magic Relationship added related to 0008527


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker