Curious Thespian
This peculiar issue came about when I linked an extractor fan to mesh wall, the wall has an opening. Initially all seems well, however if you shift-copy the object the opening is now solid. If you right click, without even going in to edit it becomes open again.
This behaviour also shows if you take the object in to the inventory and re-rez, plus I suspect it may explain why the build became mysteriously solid after the weekly rolling-restarts, again correct by merely right clicking.
This issue occurs on both the latest release viewer and Firestorm beta viewer.
The reason I suspect it's a server side issue is I believe that collisions occur server-side and, of course, llTargetOmega for a child prim
should
be a client-side viewer effect only.
I have tested this with...
Mesh>rotating mesh child object <<< occurs
Mesh>rotating prim child object <<< occurs
Cut prim>rotating prim child object <<< does not occur
There is a temporary fix which I can apply to
this
build but not to others.
If you perform a simple analyse, with default options, the behaviour goes away. Unfortunately I cannot do this with a significant amount of my other work as analyse produces an object that is unusable in its intended form and, of course, analyse is "optional"
In all tests I have used an LOD3 mesh with a matching PHYS model.
The code in the script was simply:
default
{
state_entry()
{
llTargetOmega(llRot2Up(llGetLocalRot()), PI, 4.0);
}
}
Incidentally, I also tested by putting in a 10 second timer, when the time event is triggered it fires the llTargetOmega and immediately the building becomes solid.
And for one final test, I reversed this, I started with the child prim rotating and after 10 seconds stopped it and it was solid whilst rotating and walkable the instant it stopped:
default
{
state_entry()
{
llTargetOmega(llRot2Up(llGetLocalRot()), PI, 4.0);
llSetTimerEvent(10.0);
}
timer()
{
llTargetOmega(<0.0,0.0,1.0>, 0.0, 0.0);
llSetTimerEvent(0.0);
}
}