Kitely Forums

The key for the default white blank white texture seems to have changed, so if one uses it for the specular texture on an object, the KMP rejects the item, as we went through this a few years ago about the same blank white texture. The new key is 4a1ae7c6-f889-d7c1-ab8f-97831aa4f277. Please add this to KMPs white list to recognize this as a full perms default texture.

Hi Mike,

We haven't changed any OpenSim code for a while now. Where was the default blank white texture UUID changed? Can you please link to your source for this information?

The good old 5748decc-f629-461c-9a36-a35a221fe21f UUID works well for me. 4a1ae7c6-f889-d7c1-ab8f-97831aa4f277 works fine too and probably a few thousand other UUIDs. God only knows how many times that bloated monocgrome 512x512 has been uploaded to opensim.

Ilan Tochner wrote: ↑

Thu Jan 12, 2023 4:57 am

Hi Mike,

We haven't changed any OpenSim code for a while now. Where was the default blank white texture UUID changed? Can you please link to your source for this information?

Ilan, don't you recall me whining to you about adding my Victorian Pot Belly Stove mesh to the marketplace? This was the UUID it didn't like. You claimed it was something in the file I uploaded, but it wasn't, I had to remove all textures from the object, down to default plywood, and none of the textures I used had that UUID. But when I reapplied the exact same textures I was using, the bug disappeared.

Same thing happened with my latest product, the Multi-Die Random Roller here: https://www.kitely.com/market/product/6 ... dom-Roller which had the same bug your system claimed the UUID was on the object. There was no such texture on the object in either diffuse, normal, or specular slots, so again, I had to strip it down to plywood and reapply all textures. I made a cube and used an llSetTexture() function in a script to apply that UUID and it appeared as a blank white texture. This is not a texture I used in Blender, to export the mesh. It is either your system doing it, or the viewers uploader is introducing it on upload.

I dont care where it is from, but it needs to be ignored by your system. Its just a blank white texture so theres no IP violation in having it in a mesh even if it is not actually on any of the mesh's materials. your system calls it a "default texture", so it seems to be aware that its not a user created texture.

Hi Mike,

I'm sorry but I handle dozens to hundreds of emails, IMs and PMs each day so I don't recall the details of them all. I don't doubt your story but there is a difference between a random UUID that is added to an object and doesn't exist in other grids and one that is pre-defined in OpenSim or the viewer. The first we can't ignore because it will cause rendering issues when the corresponding asset is missing from the listing. The second we can ignore because the asset will be available to the viewer even if it isn't provided by the product itself.

If there is an updated list of built-in UUIDs for the viewer and/or OpenSim then we want to know about it and update our system accordingly. But if this is a case of a random UUID being added to your build without you realizing how it happened then we can't really add the UUID you requested to the marketplace UUID ignore list.

Ilan Tochner wrote: ↑

Thu Jan 12, 2023 9:12 pm

Hi Mike,

I'm sorry but I handle dozens to hundreds of emails, IMs and PMs each day so I don't recall the details of them all. I don't doubt your story but there is a difference between a random UUID that is added to an object and doesn't exist in other grids and one that is pre-defined in OpenSim or the viewer. The first we can't ignore because it will cause rendering issues when it's missing from the listing. The second we can ignore because the asset will be available to the viewer even if it isn't provided by the product itself.

If there is an updated list of built-in UUIDs for the viewer and/or OpenSim then we want to know about it and update our system accordingly. But if this is a case of a random UUID being added to your build without you realizing how it happened then we can't really add the UUID you requested to the marketplace UUID ignore list.

Please re-read my response. The KMP stated this UUID was a "default texture". It didn't exist in the blender model. It wasn't one of the diffuse, normal, or specular textures that were actually ON the mesh, So it either got added somewhere into the file by the viewer or by the asset server. Again IT DID NOT EXIST ON THE MESH. In this case there was only one material on the mesh, so it wasn't hard to determine that this texture did not exist on the actual mesh. There were no other materials for the mesh in blender. So please stop blaming this on me, this is the behavior you have that is so annoying..

I want to remind you of your previous problems relating to missing assets: viewtopic.php?p=21684#p21684

The fact that you're not aware of how an asset was added to your build doesn't mean that it wasn't added due to an action you've taken. OpenSim doesn't add assets randomly, it does so when certain changes are made to the object. Sometimes it's dynamic textures applied using a script, sometimes its temporary assets created for a particle system, etc. I don't know the specifics for your particular example but if our marketplace says there is an asset missing from your listing then it's missing. The only time we can whitelist it is when the asset is one of a list of pre-defined assets that OpenSim or the viewer use for per-defined purposes. Ignoring other random UUIDs would mean that (a) it wouldn't solve your problem with other models that would just get a different random UUID and (b) it may cause broken deliveries when a whitelisted UUID is actually required for proper rendering.

Ilan Tochner wrote: ↑

Thu Jan 12, 2023 9:34 pm

I want to remind you of your previous problems relating to missing assets: viewtopic.php?p=21684#p21684

The fact that you're not aware of how an asset was added to your build doesn't mean that it wasn't added due to an action you've taken. OpenSim doesn't add assets randomly, it does so when certain changes are made to the object. Sometimes it's dynamic textures applied using a script, sometimes its temporary assets created for a particle system, etc. I don't know the specifics for your particular example but if our marketplace says there is an asset missing from your listing then it's missing. The only time we can whitelist it is when the asset is one of a list of pre-defined assets that OpenSim or the viewer use for per-defined purposes. Ignoring other random UUIDs would mean that (a) it wouldn't solve your problem with other models that would just get a different random UUID and (b) it may cause broken deliveries when a whitelisted UUID is actually required for proper rendering.

a) no dynamic textures involved or generated in any way
b) no particle systems involved in any way.

As i said, the bug on KMP disappeared when I stripped the ONE material of the mesh down to plywood, and readded the actual textures that were previously on it, nothing more, nothing less. None of those textures have that key. So, once again, you are blaming the victim here for something they have ALREADY explained to you multiple times which you conveniently ignored. It is annoying that you keep making excuses that were previously disposed of in an effort to blame someone else rather than actually fixing the problem.
As for "ignoring" textures, since your system identified this UUID as a "default texture", how about you code your KMP to simply accept ALL UUIDs that identify as "default textures"??? That shouldn't be hard to implement.

As was the case in the example in the link I gave you, the act of removing and reapplying the material also caused the removal of the referenced asset that was missing from your object from its object data. The asset UUID existed in that object data before you did so, while the asset itself was missing, which is what the marketplace warned you about when you tried to list the item.

If you think that is broken then you're welcome to look at the OpenSim code, find all the places where it can add an asset reference to an object and try to debug that behavior so it will delete all the references for missing assets when those references are no longer required for whatever process OpenSim placed them in the object data in the first place. That code isn't Kitely specific it's the standard OpenSim code from OpenSim 0.9.1.1.

Alternatively, you can do what I and several Kitely Market merchants have suggested you do and, using the viewer, retexture any object that is giving you these listing errors in the same manner you did in this case to cause the broken asset references to be removed from your build.

Ilan Tochner wrote: ↑

Thu Jan 12, 2023 10:29 pm

As was the case in the example in the link I gave you, the act of removing and reapplying the material also caused the removal of the referenced asset that was missing from your object from its object data. The asset UUID existed in that object data before you did so, while the asset itself was missing, which is what the marketplace warned you about when you tried to list the item.

If you think that is broken then you're welcome to look at the OpenSim code, find all the places where it can add an asset reference to an object and try to debug that behavior so it will delete all the references for missing assets when those references are no longer required for whatever process OpenSim placed them in the object data in the first place. That code isn't Kitely specific it's the standard OpenSim code from OpenSim 0.9.1.1.

Alternatively, you can do what I and several Kitely Market merchants have suggested you do and, using the viewer, retexture any object that is giving you these listing errors in the same manner you did in this case to cause the broken asset references to be removed from your build.

The thing you seem to be ignoring, blatantly, is that this asset was NOT in the blender file, and NOT in the collada file. So its not being generated by me. It isn't present on the object in any of its texture slots, theres no particles or dynamic textures involved.

Conveniently, I cannot add a product on another grid to the KMP to disprove your claim that its common to OS to add phantom textures that don't exist in the source material to a mesh that KMP calls a "default texture". I've fixed the problem on my product, I was reporting this in the thin, microscopic chance that you might actually have some miniscule amount of interest in fixing actual bugs to your system. But apparently you are still stuck in the mode of blaming your customers for your systems problems.