[Purchasing lindens with a Basic Membership]

I tried your directions but it failed with this error message :
 

Quote

 

To use your PayPal account with Second Life, it must be verified with a bank account. Click here for more information.

There was a problem with your PayPal account. Please contact PayPal to resolve the issue, then try again.

 

 

[Purchasing lindens with a Basic Membership]

I want to purchase Lindens via paypal. I want this to be a one-time purchase through a Basic Membership account.

Is this possible? Or do I require a Premium Membership?

[residual effects of llTargetOmega()]

Giving the door a little kick works like a charm. Everything is great now. Thanks for the help. :matte-motes-sunglasses-1:

[residual effects of llTargetOmega()]

---

Rolig Loon wrote:

So, when you stop

llTargetOmega

, you object should just snap back to the visual position that the servers knew it had all along.

---

This is just not working for me.  Could you show me a quick line of code that officially stops llTargetOmega and causes this "snap back"? 

I am currently using

llTargetOmega(<0.0,0.0,1.0>, 0.0, 0.0);// Pause two seconds.llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_ROT_LOCAL, original_rot]);

 This does not correct the child prim's location. I see no snap back.

[residual effects of llTargetOmega()]

I need to remove the "residual effects" of calling llTargetOmega() on a child prim after it has rotated but then later stopped.  I need to put the child prim,  back where it was,  as if  llTargetOmega() were never called.

 

What follows is a detailed description:

I am using  llTargetOmega()  within a script that is located within a child prim of a larger linked object.  The child prim correctly rotates 360 degrees back to its original orientation, and stops. This stoppage is created by re-calling  llTargetOmega() within a timer() event.     Due to slight lags between script events, the previously rotated child prim is not precisely where it originally was oriented. Editing the object in "Edit Linked Parts"  does indeed show slight alterations to the Child's rotation parameters. (Usually off by tiny fractions of a rotation). 

HOWEVER,  all known existing scripting functions cannot detect these slight offsets in rotation. Nor can they correct them. I refer to  llGetRot,  llSetRot,   llGetLocalRot,  llSetLocalRot,   llGetLinkedPrimitiveParams(LINK_THIS,etc)  and  llSetLinkedPrimitiveParams(LINK_THIS, etc)    And both of those functions using PRIM_ROT and PRIM_LOC_ROT in the parameters.  

All I need is some tricky trick to erase these residual rotations in the child prim, as if llTargetOmega() were never called.   None of the above functions can do this.  They all think it is back where it began.  Although clearly the child prim is visually skewed, and editing the linked parts shows a residual skew in the parameters.