A possible cause might be the "limit select distance" setting in the Advanced menu. You could try making sure that's disabled.

I get this problem pretty frequently in objects I've created and changed, and have done for years. It seems to be a perennial OpenSim problem, and I've never figured out a way to reproduce it.

The simplest workround I've found is to take a copy of the object and delete the original.

You're welcome. I had to make sure my understanding was correct, especially since one of my products (the swing system) revolves around llTargetOmega() (pun intended).

OK, I've made a simple test object and placed it on the path outside my shop (near the lake) here: https://www.kitely.com/virtual-world/Handy-Low/Handys-Tools . It's free to copy and modify. It's a two-prim object, with the root (red) base prim stationary and the child (green) tall prim rotating; th...

Yes, I'll have a look at this soon and report back.

Then the documentation is incorrect?

http://wiki.secondlife.com/wiki/LlTargetOmega wrote:If the object is not physical then the rotation is only a client side effect and it will collide as non-moving geometry.

Only in physical objects, surely?

Ilan Tochner wrote:Please make sure to only rotate phantom objects, otherwise your constantly rotating objects will create high CPU load for your sim.

How can this be, when llTargetOmega() is a client-side effect?

[EDIT: Never mind, I was thinking about animation rotation when I first wrote this post]

I think that the application of textures to land is entirely handled by the viewer, so you'd expect that a given viewer would render identically between SL and OpenSim. All the server does is store the values you see in the region properties (textures and height ranges, etc).