'Prims' without Faces/TextureID cause Null Reference

[zangetsu-oe]

We have observed that some data packets arrive in the client code where the ObjectManager.ObjectUpdateCompressedHandler can receive block data where the TextureEntry is not included. This causes int textureEntryLength to have a zero in it. The subsequent call to texture entry constructor calls the FromBytes method which sets the default texture to null and returns when the length is less than 16. Understandably, without the UUID in data, the specific texture can not be setup, but by setting the Default texture to null, the result that later calls to GetFace returns a null, causing null reference exceptions in other parts of the code.

Where the data block may not have the texture UUID; https://github.com/zangetsu-oe/libremetaverse-crystal-frost/blob/72c16209ae5c6fab31fb6e69a7c6e6b8b82ad4b1/LibreMetaverse/ObjectManager.cs#L2583-L2585

It seems to make more sense to not set this to null, but then to skip further initialization of the TextureEntry. There are other places in the code that fall back to return DefaultTexture to avoid returning a null.

The following change cleared up the problem for us, letting the code fall back the the default blank texture when GetFace is called later. https://github.com/zangetsu-oe/libremetaverse-crystal-frost/commit/cacae064071bfa72766a0d4aa13ec5b796242693

I'm not 100% sure what block data it is that doesn't have the texture, but I think its something to do with Linden Grass on the mainland, which sorta makes sense that these would not have faces or a user set Texture.

I would be inclined to submit the above change to not let DefaultTexture ever be null as pull request.

[cinderblocks]

Falling back to DefaultTexture sounds reasonable to me. I look forward to your pull request.