llForceOfFriction(float U, float Fn);

First off, I would like to say my understanding of the mechanics of friction is limited. None the less, I would like to submit for review, a peice which calculates the force of friction on prims. This script does not allow for variable coefficients of friction , it baselines it at 0.5. This functionality will be added later if the script proves to handle other circumstances well enough. It was an attempt of mine to use rotation force in the calculation to add a bit more realism and accuracy. All improvments, optimizations and questions are welcome.

// llForceOfFriction(float U, float Fn) Script
// Created by: Cid Jacobs 
// Original by: Cid Jacobs
// Last Updated: 11-04-06
// Notes: Speak with Cid Jacobs about any concerns.
//
//
//--------------------Globals
//Normal Force
float Fn;
//Force of Friction
float FoF;
//Coefficient of Friction (needs to be remodeled for accuracy)
float U = 0.5;
//
//
//--------------------User Defined Function
//Calculate Normal Force
float llForceNormal(float x, rotation y, float z)
{
    //Normal Force is Equal to Mass * Rotational Force * Gravity
    Fn = -x * llTan(llAngleBetween(y,ZERO_ROTATION)) * z;
    //Rational Normal Force Check
    if(Fn < 0.0)
    {
        //Equalize if Offset by Rotational Force
        Fn = -Fn;
    }
    //No Rotational Force Check
    if(Fn == 0.0)
    {
        //Normal Force Equation, Excluding Rotational Force
        Fn = -x * z;
    }
    return Fn;
}
//Calculate Force of Friction
float llForceOfFriction(float U,float Fn)
{
    //Force of Friction is Equal to Coefficient of Friction * Normal Force
    FoF = U * Fn;
    //Return Force of Friction
    return FoF;
}
//
//
//--------------------States
//Mandatory Default State
default
{
    //Triggered By The Start Of Agent Clicking
    touch_start(integer num_detected)
    {
        //Enter Normal Force Calculation Function
        llForceNormal(llGetMass(),llGetRot(), -9.8);
        //Enter Force of Friction Calculation Function
        llForceOfFriction(U,Fn);
        //Output on Open Channel
        llSay(0,(string)FoF);
    }
}

I do this with all of my weather functions and my physics functions, its wishful thinking.

Although, I guess it should be llGetForceOfFriction, but that really isn't important. Any questions about the code itself?

or perhaps cjGetForceOfFriction? Maybe I'll start using nnGetSomeValue to denote functions I have written but anyhoo, onto the script.

If I'm not mistaken the physics of friction between two objects (ignoring fluid mechanics for now) is dependent on a cooefficient of friction which varies for each object-object interface, the area of contact, force of contact (as I see you've worked out normal force). One thing to note is that the coefficient of friction is different for static objects and objects in motion, i.e. once you start something moving it requires slightly less force to counteract friction and keep it moving. Just some ideas for you to look into =).

You are correct about FoF being dependent on a variable coefficient, I made it a static amount at this time to focus on making sure the rest of the code itself works. I am guessing that an approximation will have to be made for U down the road, probably with llGetPrimitiveParams( [PRIM_MATERIAL]); and some predetermined variable scale. Are you saying that you do agree that the Fn equation is correct? The part I really find myself questioning is the rotational force value.

I thought the basic Coulomb friction force approximation equation was Force_sub_friction = mu * force_sub_normal, which is irrespective of contact surface area...?

I believe it is respective of the contact surface and only applies to static friction. It is an incomplete approximation of friction.

Hmm, I think Kage is correct...

but, mu depends on several things, including surface materials and area, and there are different values for static and moving mu as well the way I was taught it.

Of course my mechanics was a long time ago and included other things such as infinite plane surfaces and objects acting as if point masses and things like that.

Not to be a pain (in the), but any half decent compiler is going to throw a warning or an error on that because of local & global variables sharing the same names.

It compiled fine in world for me.

Because llMaim(key id,integer how_badly); is funny, damnit!

Well, this is LSL compiler we talk about, so it accepts it without issue. A _possible_ issue is, with this sort of naming scheme the value of global variable with shared name is ignored while local variable with the same name is in scope. Which, since you get no warning from compiler about the shared names, can be lot of fun and time wasted on debugging... not that it'd ever happen to me, no sire... >>;