ball

[Sowy Atlas]

im trying to make a golfball or snookerball

this is the only code i could find which comes close to what i wanna do.

 

using lldetectedgrab

i want to adjust the angle/power

display the power level in floating text, either as bars ||||| or numbers 1-10

then shoot off based on the infomation above when you release the mouse button

 

please help, i think it should be simple yet im incapable

 

it would probally be easier if the power level was based on the amount of time you hold your mouse down the same way basketballs tend to work, but i dont wanna do it that way

 

default
{

    touch(integer total_number)
    {
        vector grabVec = llDetectedGrab(0);
        integer incVal = llRound(grabVec.x * 10); 

vector curEul = llRot2Euler(llGetLocalRot()) * RAD_TO_DEG;
        // Increment or dectrement the z axis value
       vector newEul = curEul + <0, 0, incVal>;
        // Convert it to an integer for display/use
        integer curVal = llRound(newEul.z);
        if (curVal < 0)
        {
            curVal = 0;
            newEul.z = 0;
        }
        if (curVal >= 360)
        {
            curVal = 360;
            newEul.z = 359.9;
        }
        llSetText((string)curVal,<0,1,0>,1);        
    }
}

 

[Rolig Loon]

You don't need most of that, as you probably know.  All you need to do is get the offset vector, scale it, and then apply it (with a negative sign) as an impulse.  The rest is cosmetic, so that you can see what the scaled magnitude of your applied impulse is.  Here's a test sample script.  I'm paranoid about losing physical objects, so I have included a timer to make the ball stop moving after a couple of seconds and to have it tell me where it ended up.

vector gGrabVec;default{    state_entry()    {        llSetStatus(STATUS_PHYSICS,FALSE);  // Start non-physical    }    touch(integer num)    {        gGrabVec = llDetectedGrab(0);  // Get the current offset vector        float Mag = llVecMag(gGrabVec);     // and its magnitude        llSetText("Power = " + (string)((integer)(10*Mag)),<0,1,0>,1.0);            }        touch_end(integer num)    {        llSetStatus(STATUS_PHYSICS,TRUE);   // Make the object physical        llSetTimerEvent(2.0);               // Turn the safety on        llApplyImpulse(-5*gGrabVec, FALSE); // Scale the offset vector and apply it * -1    }        timer()    {        llSetTimerEvent(0.0);        llOwnerSay((string)llGetPos());    // Where am I?        llSetStatus(STATUS_PHYSICS,FALSE); // Stop rolling        llSetText("",<0,1,0>,1.0);    }}

 

[steph Arnott]

Any physical object such as a ball should have an auto die script in the object in case it becomes lost. Physics objects have a nasty habit of suddenly flying off into who knows were.

[Rolig Loon]

That's certainly a smart option, Steph.  Especially when I am trying to develop and debug an object I have scripted, though, I'd rather not have it die prematurely.  In this case,  I chose to put a timed "dead stop" and "Here I am" feature into the script.  Other times, I have used STATUS_SANDBOX or STATUS_RETURN_AT_EDGE to keep a physical object from running away or catch it if it runs off world. Until I am confident that I know how my scripted object is going to behave, I also usually paint it a garish color and give it a super glow so that it's easy to find.  Regardless of the method, you're quite right.  Physical objects have a mind of their own, so it's good to keep them on a leash.

[Madelaine McMasters]

Someday I'll investigate STATUS_SANDBOX and STATUS_RETURN_AT_EDGE. Back in my building days, I avoided the problem Steph mentions (or I think I did) by putting a listener in things I made physical. I had a "killer" prim that, on touch, issued a self destruct command across the region.

I realize this doesn't work if I lose a physical object into a neighboring sim, but I lived on an isolated one during those building days.

[Sowy Atlas]

thanks, i got a bunch of questions now

 

when the x,y,z size of the ball is all 0.500, the ball works perfect,

but when i make it smaller it goes insane when used,

why is that what can i do about it... i need it to be a tiny golf ball.

 

i also added a particle effect to show the trajectory while your holding the mousedown,

once again works fine, PSYS_PART_MAX_AGE seems to represent the size

so i set it to (float)  gMag

that way if i increase/decrease the power level - the size of the particle LINE/BEAM should do the same

 

only problem i got now is the beam aint facing the right ANGLE

 

so i tried to do something like this

PSYS_SRC_ANGLE_BEGIN, (float) -5*gGrabVec * PI,   PSYS_SRC_ANGLE_END, (float) -5*gGrabVec * PI

 

that didnt compile but ive tried all sorts like llVecMag(gGrabVec)

i dont understand it im just trying to make it work the way i want by fiddling with it

 

long story short i want the particle effect angle to change to the correct angle when i move my mouse position.

 

also when you collide with a object is it possible to get the name of the prim if its apart of a linkset,

i think i got no choice but to leave the golf hole unlinked from the course.

 

last question

at the moment everytime the ball collides with the hole we consider it potted,

thats not realy how the game should work tho? thats not how flash web games work

 

if you smash the ball super hard it usually rolls over the hole hits the back wall and rebounds elsewhere

 

what im trying to say is

 

how do i determine the velocity of the ball, if below a certain number then i guess its rolling slowly so yes we can consider it potted otherwise it was probally hit to hard and shouldnt be counted

 

also is it impossible to change a persons camera view unless they sitting? cant it be done by touch.. ive tried but no success

 

 

[Rolig Loon]

---

Sowy Atlas wrote:

thanks, i got a bunch of questions now

 

when the x,y,z size of the ball is all 0.500, the ball works perfect,

but when i make it smaller it goes insane when used,

why is that what can i do about it... i need it to be a tiny golf ball.

---

 Apply a smaller force and put a limit on it.

---

i also added a particle effect to show the trajectory while your holding the mousedown,

 

once again works fine, PSYS_PART_MAX_AGE seems to represent the size

so i set it to (float)  gMag

that way if i increase/decrease the power level - the size of the particle LINE/BEAM should do the same

 

only problem i got now is the beam aint facing the right ANGLE

 

so i tried to do something like this

PSYS_SRC_ANGLE_BEGIN, (float) -5*gGrabVec * PI,   PSYS_SRC_ANGLE_END, (float) -5*gGrabVec * PI

 

that didnt compile but ive tried all sorts like llVecMag(gGrabVec)

i dont understand it im just trying to make it work the way i want by fiddling with it

 

long story short i want the particle effect angle to change to the correct angle when i move my mouse position.

---

 Particles are always emitted from the geometric center of the emitting prim and they always flow out of the prim's +Z end.  You have a physical ball, so it will roll in flight and the particles will be emitted in random directions, depending on which way the ball is pointing at the moment.  You might be able to use the new parameter PSYS_PART_RIBBON_MASK to leave a trail behind your moving ball, though.  I haven't used it myself yet, and I'm not sure that it's available in all TPVs, but maybe you can experiment.

You can't vary PSYS_SRC_ANGLE_BEGIN and PSYS_SRC_ANGLE_END to do what you want, so that's a dead end.  For the future, though, I suspect that you can't get your code to compile because you are trying to put those statements into a block of global stuff at the head of your script.  You can't do that.  If you want to include calculated values, you'll have to do that in an event or user-defined function.

---

also when you collide with a object is it possible to get the name of the prim if its apart of a linkset,

i think i got no choice but to leave the golf hole unlinked from the course.

---

string Cup = llGetLinkName(llDetectedLinkNumber(0))

---

last question

at the moment everytime the ball collides with the hole we consider it potted,

thats not realy how the game should work tho? thats not how flash web games work

 

if you smash the ball super hard it usually rolls over the hole hits the back wall and rebounds elsewhere

 

what im trying to say is

 

how do i determine the velocity of the ball, if below a certain number then i guess its rolling slowly so yes we can consider it potted otherwise it was probally hit to hard and shouldnt be counted

---

 You can determine the ball's velocity at any time with llGetVel.  I'd suggest triggering it when you collide with the cup.  Then do your calculation to see if it is rolling slowly enough to be called "potted".

---

also is it impossible to change a persons camera view unless they sitting? cant it be done by touch.. ive tried but no success.

 

---

No.

 

[Sowy Atlas]

heres the full code

 

so i applied a smaller force

not sure what you meant by including a limit but i made sure it doesnt go over 10 otherwise it flies off sometimes

 

the particles wont emit in different directions in my script because its not enabled when the balls physically moving,

so if i could get the ANGLE part to work should look great

 

you mention particles always flow out of the prims +Z end
, so when the objects touched... the object Zs position can be rotated to face the opposite direction of the lldetectedgrab before the particles are turned on????

im guessing its probally impossible to accomplish what i want to achieve o well back to the drawing board

 

the code could probally be better, for instance

where i comment "// WHAT IF BALL ALREADY STOPPED ROLLING B4 THE TIMER ENDED ?"

maybe if i had a loop like  on this page to check if its stopped moving

http://wiki.secondlife.com/wiki/LlGetVel

but waiting a few seconds before a person can touch again wont kill anybody

 

what did i realy wanna ask hmmm

 

 if (llDetectedName(0) == "Golf Hole" && llVecMag(llGetVel()) < .001)

^ whats a good number to represent a fastball?

 

i tried to check llgetvel of a moving ball to findout myself but it was always blank 000000

 

also i dunno what to do abt this line because at the moment if  a persons power level goes above 10

the floating text might be adjusted correctly but i havent sorted the impulse

 

        if ((integer)(10*gMag) > 10)
        {
        llApplyImpulse(-0.5*gGrabVec, FALSE); // HOW DO I SET THIS TO MATCH

 

[Rolig Loon]

Some of your good questions are matters of taste, or at least your creative design.  I wouldn't dream of spoiling your fun by telling you how I would do them. How fast is a fastball?  As fast as you want it to be.  What if a ball stops before the timer ends?  I don't know.  You must have some plan in mind.

The rest of your questions are things you'll need to sort out for yourself too.  They can be done, but you'll learn more by figuring out how to do them than you will by getting a recipe.  The best way to decide how big an applied impulse should be is to experiment.  Same with deciding how to fine tune your particles.

A few observations:

You can rotate a prim to face in any direction you like by using llLookAt and llRotBetween. Remember that your gGrabVec is pointing exactly the opposite direction from your ball's initial flight vector.

The number that's displayed in hover text doesn't have to mean anything.  It's proportional to your applied impulse, but the number itself is arbitrary --- something for the user to make meaning of.  Therefore, you can  make the limiting value of your impulse whatever you like, and then decide that number will represent that in hover text.  You don't set the impulse to 10, in other words.  You set 10 to the impulse.

Velocity is a vector.  If you want to report its value in chat, you have to write (string)llGetVel().  If you want to track the velocity of the ball while it's moving, you'll need to trigger your chat report with a fast timer so that it tells you the velocity each time it fires.

Edit: Clarified rotation comment

[Sowy Atlas]

i have just opened my eyes and realised i dont need to change the angle since im rotating the prim so i dont need to mess with the particle settings atall

at the moment im just using

       llLookAt( llGetPos() + gGrabVec, 3.0, 1.0 );

 

so its almost perfect... but as you said i need it in the opposite direction,

i guess thats what i need llRotBetween for but ive been trying for hours and i cant get it work or compile for that matter

 

im probally not doing it right to begin with but heres what im trying

rotation lRotation = llRotBetween( llGetPos(), gGrabVec );
llLookAt(lRotation, 3.0, 1.0 );

 

function call mismatches type or number of arguments with that last llLookAt line

 

 

[LepreKhaun]

Function: llLookAt( vector target, float strength, float damping );

 

(type emphasized)

[Rolig Loon]

Yup.  And that's my fault.  I should have said llRotLookAt.  :smileyembarrassed:

[Rolig Loon]

You're close.  You want to rotate your ball's Z axis (<0,0,1>) to point in the direction opposite to gGrabVec.

I apologize for having suggested llLookAt instead of llRotLookAt.  Yopu could use either one, depending on how you set up the problem, but llRotLookAt is the more logical one, once you have llRotBetween.

[Sowy Atlas]

this orange line seemed to have done the trick keeps the particles in the correct direction atleast

but now its very hard to control,

i think its because this code is in the touchevent, therefore its constantly setting the z axis back to the start but i dont see when else to do it, tried putting it in state entry and when the timer ends etc

llSetRot(llEuler2Rot(<0,0,1>));                                                                                                                                                                rotation lRotation = llRotBetween( llGetPos(), gGrabVec );
llRotLookAt(lRotation, 3.0, 1.0 );

 

 i thought that is the angle between em, but if i calc and use llrotlookat, the particles still behind the ball instead of infront

rotation lRotation = llRotBetween( <0,0,pos.z>, gGrabVec );

 

[Rolig Loon]

That's because you're calculating IRotation and then changing the ball's rotation before applying llRotLookAt.  You simply want the angle between your ball's Z axis and gGrabVec.

[steph Arnott]

Sorry dumb question, why does it have to be physical all the time?

[Rolig Loon]

It's only physical while it's moving, Steph.  :smileywink:

And it has to be physical while it's moving, or it won't roll like a ball.