HELP - need orbit of object inside Snow Globe

First of all, I am not a scripter at all. I'd love to be, but alas, you all talk a whole different language! Anyway, I built a snow globe with a little village in it and a moon orbiting above, all contained within the globe. I orbit the moon by linking it to an invisible prim in the center and placing a rotation script in it.

The problem is, of course, all this cannot be linked to the globe, so moving the globe or selling it is difficult. Of course, I can pick it up by selecting everything and taking it, etc. But, is there a way to be able to package this or move it, etc. as one object and yet still have the moon orbiting inside?

Many thanks in advance.

Don't make the rotating prim the root.

I sure hope someone helps you out with this because I have the exact same problem and have no idea how to solve it!

You're not very precise about what "orbit" means so...

(Script goes into the root prim.)

vector Center = <somewhere>; // Offset from root: Center of the orbit
float Radius = something; // Radius of the orbit
integer MoonLink = 0;
float Angle;

default
{
on_rez(integer param) { llResetScript(); }

state_entry()
{
integer num = llGetNumberOfPrims();
for (; num > 1; --num)
{
if (llGetLinkName(num) == "Moon" // Name of your moon
{
MoonLink = num;
}
}
if (MoonLink)
{
Angle = 0.0;
llSetTimerEvent(0.25); // Needs some tuning
}
}

timer()
{
llSetLinkPrimitiveParams(MoonLink, [PRIM_POSITION, Center + <Radius, 0.0, 0.0> * llEuler2Rot(<0.0, 0.0, Angle>]);
Angle += 0.01; // Needs some tuning
// More or less, that 0.01 describes the speed of the moon on the orbit
if (Angle >= TWO_PI) { Angle -= TWO_PI; }
}
}

No idea how it will look in world. Probably jerky. A few sub-scripts is the best solution here.

More important: llEuler2Rot(<0.0, 0.0, Angle> describes an orbit around the Z axis of the root. You can choose another axis with llEuler2Rot(<0.0, Angle, 0.0> (Y axis) or llEuler2Rot(<Angle, 0.0, 0.0> (X axis)... or else, you can rotate the root.


Correct the typos, test and come back for more questions...

Thank you very much. I'll try it out and let you know what happens. This sure is appreciated!

May I suggest you simply don't link the spinny bits to the globe? Instead work around this by having the spinny bits rez on touch or even "on rez".

I think you will find a few lines of "rezzer" code much simpler than learning all the SL rotation ins and outs.

That also sounds like a good solution. I wondered if that was an option. I've seen doors done that way so that they rez in place when the object rezzes. Some follow too so that if the object is moved the door moves with it. Just don't know the code for it.

Hi Clock

another solution is to path cut your orbiting prim to manipulate its center of rotation.
then it can rotate using a simple llTargetOmega function with a few lines of script code.
your snow globe would be completly linked and your moon would orbit.

greetings =)

=) Making it rez the globe insides on rez or on touch would be simple enough. Making it follow the object, would be a bit more complicated, though completely possible.

Depending on how your build works, temp rezzing may be an option too. This would help if the object is moved, as one globe insides delete/die, a new one will rez.

Or you could use a sensor to check if the insides are there and rez if needed.... but all these seem overly complicated.

Personally i would rez the insides "on rez" , just to keep things simple.

Will drop a script on you in world with some comments. =)

That's a great point. If you can find a way to only need to spin one prim, then this gets much simpler.
With the llTargetOmega script in the moon/spinning prim simply make it the Last prim in the linkset(opposite of the root).

generalised free object rotating around a fixed offset point (same side always faces the fixed point)

vector gPosOffset = <1, 0, 0>;
vector gDegArc = <0, 0, 6>;
rotation gRotArc;

default{
  state_entry(){
    gRotArc = llEuler2Rot( gDegArc * DEG_TO_RAD );
    llSetTimerEvent( .1 );
  }

  timer(){
    llSetPrimitiveParams( [PRIM_POSITION, llGetPos() + (gPosOffset - gPosOffset * gRotArc) * llGetRot(),
                           PRIM_ROTATION, gRotArc * llGetRot()] );
  }
}

you could replace the ofset point hard coded variable with detection of the center of your unconnected globe

examples copied essentially from
http://wiki.secondlife.com/wiki/Rotation#Rotating_Vectors

Could you perhaps get a workable result using a particle for a moon?

Wow, getting a lot of good advice and interesting solutions. I'm hoping to come in world today or this evening (CST) and try out the suggestions to let you and the others know how they work.

Question: how would path-cutting and changing center allow me to link? My problem is that linking results in the entire build rotating instead of just the moon within the build. Obviously something I'm missing.

Oh, had I read further with more understanding I might not have just posted my last question. lol! I think I get it. If the moon is last linked and it is a simple rotation (offset from center because of the path cut) then it will rotate even if linked? The rotation will be orbital rather than simply rotational because of the offset center?

Not sure the orbit would be big enough but I'm going to try it to see... Thanks for the suggestion and I'll post the results.

This one I'm very eager to try... thanks very much. I was sure this issue had been addressed and was in the wiki or elsewhere but knew so little about scripting that I didn't even know how to construct my search to find it. I have MUCH to learn.

Thanks very much! I want to try your solution with the rezzing of the moon on unpacking / moving. This, I think, may result in the smoothest rotation of the moon. I'm eagerly awaiting my return to in-world to pick up the scripts and see what happens! Thanks so very much!

I'm not sure, hadn't thought of that. Probably would work just fine if it were a 3-D representation of the moon and not flat. Particles! Whew, a whole 'nother dimension of ignorance on my part, lol!! But I'm very willing to listen. Thanks!

Sounds like your on target.

You could even avoid the offset bit if you rotated a prim with an offset moon texture. By this I mean a mostly alpha texture with a small moon in one corner.

Best of luck, catch me inworld if I can help.

Wow, I have much to try out after all the kind and helpful replies. This is one of the many things I love about SL -- the many kind, quality people who enjoy helping others, and in return my opportunity to help those I can with what meager knowledge or skills I possess. I'll be giving updates to all the suggestions asap.

Thanks again to all!!

Alisha, you are very kind. I will be looking you up inworld. This suggestion also sounds very workable, however I'm guessing it would result in a 2D moon. I really like your rezzing idea and am eager to try that out.

See you inworld soon I hope.

Again, many, many thanks! I'm excited! lol!

Always very happy to help.=)

Your right that idea will result in a 2D moon. Lots of other options.
I'll be stuck in "that boring place" till this afternoon, but will be bouncing around inworld soon after.=)

Hello all. Ok... well, proving once again that SL is filled with genuine, good people, one of you who answered me here met me inworld and worked with me on this challenge until we accomplished a very workable, very smooth solution. Not only that but I met another good friend.

Solution: the moon consists of 3 spheres equidistant from each other oriented in a line along one of the horizontal axes. One outer sphere is textured, the center and other sheres are transparent. Simple rotation (llTargetOmega) in the center prim. This is rezzed by timer from the Globe every 2 minutes. The root prim of the moon contains a timed llDie command also on 2 minutes. Simple, low lag, and does the trick. We've talked of fancy-ing it up with on-rez creation of the moon, or sensors, etc. But this item is one not moved about but rather set out for display for the most part, so this is a very simple and workable solution.

The reason we went this route was because the timing of the deletion and re-creation of the moon in this manner is highly controllable where temp rezzing is haphazard.

Best of all, I've learned some very basic but very important scripting skills and met a terrific person to boot! Thanks very much for all the help!! Thank you Alisha!!!

Merry Christmas!

PS: All of the help offered here was very appreciated and I will continue to experiment with the suggestions given. There are several interesting approaches discussed that might also lend help to other projects as well as this Globe.

I'll keep all posted... Many thanks again to all!