Rez smart, save space, be lazy: Modularization
Big things. Second Life hates them.
So it falls upon us, the LSL life-givers of the grid, to make it easier to deploy, move, and rotate our multi-segmented structures.
Thomas Conover built this Platform Rezzer tool, which demonstrates the same principle of simple modular deployment.
But this is half of the lesson plan. I also want to make moving and rotating these giant builds easier.
Fun fact: the content of this post and the scripts within have been completely overhauled and rewritten three times to date. >=/
But it’s done, I can’t complain.
SO, you are now faced with another script pair for this lesson, and we’re going to have to be able to distinguish between them while explaining the logical flow.
We have >modular.core, and >modular.segment.
Development Stage 1: Co-ordinating our efforts
First off, let’s take a look at the global vars we will use:
This build will operate via chat commands by the owner through channel cmdchannel. Commands such as ‘compile’ and ‘deploy’.
Line 1, datachannel is the line of communication between the core and all other segments.
While segmentlist will contain the names of all segments to be affected.
Here, we have 2 vectors, whereibelong and howiamsupposedtobe, which will represent this segment object’s position and rotation (in Euler values) in relation to the core object.
Line 2, corename is important, for we use a sensor which locates the core to do our operations.
And you already know about datachan.
With these, we have the basis of coordinating one core and many segments together.
The following lines explain the process.
It all begins when the Owner says “compile“.
Remember that the core name is important.
Speaking “compile” forwards the command to the segments, who do most of the work.
It is here that the corename is recorded for the following sensor search:
In this search, we figure out the core‘s position and rotation (again, in Euler), from which we subtract the segment object’s position and rotation. This will give us the difference, which will ensure that however the core is oriented, the segments will align again properly.
Now, if all this 3D mathmaticing intimidates you, there’s a great reading (albeit pretty long) on rotations in Second Life, and the difficulties and solutions.
>http://eowyn.bigpondhosting.com/SecondLife/SecondLife_WindMill_1.html
Long, long, long, long story short in a few pointers:
-Rotation +/- another rotation must be done with two rotations converted to Euler (http://wiki.secondlife.com/wiki/LlRot2Euler)
And when you convert to Euler, don’t forget to use RAD_TO_DEG.
ex: (euler)Rot1 + (euler)Rot2 = (euler)RotNew
-When calculating a position in relation an object, we must not forget to multiply that pos vector by the rotation (not as a Euler val, but as rotation) of the core object, in order to align its placement correctly. *This is will appear in the next stage when we deal with placement
ex: CorePos – (MyPosOffset * CoreRot)
This actually concludes the first piece of logic. The core merely issues commands to the multiple segments involved, which all retain their own personal positions and rotations relative to the core object. The core also stores the names of these segments, for when after compiling has been completed, you may Take Copies of each segment and place them inside the core for quick deployment and positioning (what I like to call Build Blooming).
Development Stage 2: Places, everyone!!
This is the fun part; watching everything reposition itself when the core is moved or rotated.
We begin with 2 possible initiators of the “reorient” command. Unfortunately, there’s no way in LSL (perhaps only of which I know) to merge handlers for an object having been moved and/or rotated into one, so we’ll have to make due (though it is a little unsightly).
The timer event weighs the last recorded changed rotation, lastrot which is declared globally, and the current rotation, to see if there was a change. And if there was, go ahead and reorient.
The moving_end event is a straightforward LSL event triggered by, you guessed it, moving the object.
A line in the listener sends the script into state orientmode when the proper command is heard.
Once again, the sensor is key to working with wherever the core has been moved. Again, we detect its pos and rot, and apply the offsets saved; whereibelong and howiamsupposedtobe to get our new placements.
This is where NewPos = CorePos – (MyPosOffset * CoreRot) comes into play.
Development Stage 3: Destroy & Deploy
When you’re sure all segments have been injected with the seg scripts, that compilation works flawlessly, and everything is where it needs to be, you are free to Take or Take Copy of each segment and place it into the core for Rezzing.
Scripting this part is easy peasy by now. Just a looped llRezObject sequence through our list of names stored in core.
Command: “deploy” in the cmdchannel
For each name in our segment list, poop it out. Wait half a second, then order everyone into position.
Huzzah!!
Now I’m modularizing freaking everything.
