Rezzing objects of varying rotations

Always read other people posting about this, and always thought, phew, at least that's not my headache today.

Well, guess what, hehe, the day arrived.

A rezzer, rezzing a collection of objects. Objects may have been made by various people on various obscure rotations. Drag them from your invy and and rez them on the ground, they look fine. Rez them from a rezzer, and all of a sudden that bed is on its side.

Examining the objects that rez fine, they have 0,0,0 rot.

Examining the ones that rez all skew-whiffy, they have varying rotations, as though some of the makers stood on their heads to do them :}

Spent a few hours searching these forums (okay, fora.)

Does the attached, 0 rot prim mentioned in the URL below still sound like the best way to cope of rezzing a collection of objects with different rotations?

/54/40/140589/1.html

I recently setup a vendor for a festival, my first one... using a freebie vendor. I was having the same problem as you said. I had it set up as two different items, one for sale and one for display. The swords that I put on display had rotation scripts in them to rotate, and one of them was having this problem.

So, I added into the swords rotation script an on_rez event that used llSetRot to rotate the object to the right alignment. Fiddling with the script got me to line it up, and I was quite happy with the way it was. I took the item and placed it into the vendor with a grin. Luckily, I like to double check things and cycled through the items till I got to the culprit. There it was again! Rotated wrong!

.. maybe this is going on too long.. and I was almost about to burst into tears until I figured it out... resetting the script before setting the rotation worked wonders ^_^

I pretty much added something like this

on_rez
{
     llResetScript();
     llSetRot(<x,x,x>);
}

Hmm, and for the x's in

llSetRot(<x,x,x>;

no doubt having to supply diffenent x's for each different sword...

Actually, that command would not work that way.

llSetRot demands a rotation variable, not a vector.

llSetRot(<0,0,0,1> or llSetRot(ZERO_ROTATION) both represent the vector display in the client tools of <0,0,0>

The Rotation variable uses what is known as radians, which are calculated off of PI, and therefore aren't very intuitive for those used to use the vector degree route.

http://rpgstats.com/wiki/index.php?title=LlEuler2Rot

If you look at that command, it gives you an easy snippet of code to convert Degrees to Radians.

Nothing after llResetScript() is supposed to execute. If you want the llSetRot() to actually do anything, you should put it before the reset, and possibly add "llSleep(0.5)" for good measure.

It may have fixed your problem, but it's not doing what you think. If you delete the llSetRot(), it should behave the same way.

A rezzer should have a way to set the rotation for each object. You see, the rezzer HAS to specify the object's rotation -- there's no way for it NOT to. So, it either uses the same rotation for all, or it needs to be configured somehow (e.g., notecard).

Alternatively, put a script in the object to set rotation on rez -- ideally, only when rezzed by the vendor (based on "rez argument". If you're selling the item, you can have this script delete itself on "change owner", so it won't interfere with normal use.

To find out the value to use for the rotation, drop this script into the object after you've set it up how you want it:

default
{
    state_entry() {
        llSay(0, (string) llGetRootRotation());
        llRemoveInventory(llGetScriptName());
    }
}

I didn't try this script yet; it might have typos.

Be aware of which direction you're facing when you set up the object and drop this in. Sorry, I don't know the ideal direction to face, but I suspect it's North (towards the top of the map).

Also, note that the vendor might rotate the object relative to the vendor's own rotation. (IMHO, it should). So, you might have to compensate for that, e.g., by turning the vendor until it looks right, or by facing a different direction when you set up your object to find its rotation.

Ah the mysteries of picking the proper root prim for a linkset....

Ideally, root prims of objects should always have ZERO_ROTATION to prevent such oddities from happening. But not every builder thinks of this. Especially as they most likely do not expect you to rez their objects from a rezzer.

My tip of the day.

If you only want to rez display items and are able to change the root prim:
Set the item up so it looks right, any angle will do,
Make a transparent box or make a box transparent, check to make sure it is at zero rot and link it as root.
Now there is no need to work out rotations, just rez @ height.If you make the invisible prim taller the object will appear higher off the ground.

(Only added cause Ive done it this way with houses in several pieces.)

Well, yes and no. When someone is building a shop, they should be able to rez the same vendor in different locations, and rotate it so that the displayed prims point the correct direction.

Of course, without notecard (or locate & click to set) rotation configuration per item, you're likely to have problems anyway. My simple rezzer script (that you drop in a displayed item) makes it spin on the z axis, which works nicely for many products. No patent on that idea, feel free to implement it in your rezzer!

Edit -- oops, I think I misread your post. Sure, that helps, but just isn't feasible for lots of items. Consider ones where the root prim has to be a horizontal cylinder. Many of us select root prim based on script issues rather than physics issues. Ah, the list of considerations is endless!

This works for me, to rez an object triggered by a chat command, and have the object rezz in its original orientation.

 if(msg=="rez_object")
                {
                llRezObject("object", llGetPos() + <1, 0, 0>, ZERO_VECTOR, ZERO_ROTATION, 0);
                }

The <1, 0, 0> determines the <x,y.z> distances that the object resolves at relative to the object that is rezzing it.

Ah yes, but there's the rub isn't it, the "original orientation." What if the original orientation is skew-whiffy?

Okay, example, there's a linden-made freebie bed around. Probably everyone has see it. Cherry frame i think, green bed spread for sure. Nice bed. Used it myself at one point in time. When i went to rez it out of a holo rezzer (no, not to try to sell a freebie - rather, to use a freebie to test on rather than the 40k sex gen bed, lol.) , well, it came out on its side! Turns out original actual orientation on it is <0,90,0> [I think, not in world right now -- something like that.]

I'm guessing that when you rez something in world, and correct its orientation using arrows and rotate edit stuff, and then take it back into invy, and then either re-rez it or give it away -- it remembers its manually corrected orientation. But when you rez it, because with linden script you have to specify a rezzing rotation -- you override that. I can see what's happening, just not sure I can find the best words to describe it.

Right, Chaz.

BTW, you probably won't want to use a temp rezzer for a sex bed, because it'll get deleted and re-rezzed every minute. Which will leave you & yours popping out every minute ...