Texture copying itself into inventory? What?

[Artorius Constantine]

Never seen this before. Not even sure where to look for help but I figured I'd start here.

There are no scripts in the FP mesh item.

Everytime I put a texture on it, in any way, on any of it's faces, it copies itself into the contents inventory!

Sometimes it even reverts to the original texture that came with, sticks that in it's own inventory it and that is a no trans texture. (on an FP item lol)

Any suggestions? It's not a lag issue.

[Qie Niangao]

This is the standard (if stupid) way no-transfer textures work. Are you saying you're seeing the same thing with full-perm textures, too?

[Artorius Constantine]

Yeah, I uploaded a texture I made (with the supplied ao map). I did a quick test from local and it looked good so I uploaded it. I put it on and poof! there was now a no copy texture stuck in the inventory. Trying to make this a vendor board so it's pissing me off. It keeps changing perms because the texture just appears in the inventory with bad perms.

My texture, full perm that I uploaded was gone and it was suddenly back to the original no copy texture and in the inventory.

I finally got one to clear by using a scrubber script, I had to put in a new script so it would read, texturing it all with the default wood, taking a copy then the new rezzed copy seems to be OK.

I'm thinking the builder used a script to call the texture by UUID and that the script properties are sticking. Like Hover text does.

 

[Artorius Constantine]

Well I thought I had it figured out.

I logged in to find all 3 of them had reverted back to the no copy/ no transfer original texture with a copy in inventory.

I friggin deleted those so it has to be a script function sticking calling them back.

Gonna take one to the test grid and see if I can fix it. I

I wish the builder had included untextured versions instead of just these with no perms. FP should be FP.

[Qie Niangao]

---

Artorius Constantine wrote:

 

... it has to be a script function sticking calling them back.

---

Except there really isn't anything like a sticky script function that would cause the texture reversion you're describing. These embedded texture assets are not persistent properties set by script as are particle systems, looping sound, omega rotation, texture animation, etc. -- they simply aren't the sort of thing "scrubber" scripts fix, even if it seemed so.

If an object reverts to a previous state, the first thing to consider is whether the sim may have been rolled-back to a previous state. Or even simpler: the change made during edit never actually applied in the sim, but only in the viewer (not uncommon when there's asset service lag or especially network problems).

For a texture to get into an object's inventory by script, I'm pretty sure at least one of the following would need to happen:

1. Another script inside the object (perhaps another element of the linkset) could apply it, or
2. Another script inside another object with the same owner could push the texture asset into the object (using llGiveInventory) but this alone would not apply the texture to a surface of the object, and/or
3. Another script inside another same-owner object that shared a secret remote script-loading PIN could push a script into the object, and once inside, that script could apply the texture.