Maths trigonometry problems scripting RezObject()

[Profaitchikenz Haiku]

54 minutes ago, VirtualKitten said:

I hope you can see Prof something is still needing work on your code .

The code you have posted is not my code. 

54 minutes ago, VirtualKitten said:

list l = llGetLinkPrimitiveParams(link,[PRIM_POS_LOCAL,PRIM_ROT_LOCAL]);  

findLocations()
{
    list params;
    vector range = <0.0, 0.0, 12.0>;
    rotation correctBy = <-0.16505, 0.00003, -0.00002, 0.98629>;

    params = llGetLinkPrimitiveParams(emitter, [PRIM_POSITION, PRIM_ROTATION]);

    vector emitterRegionPos = llList2Vector(params,0);
    rotation emitterRegionRot = llList2Rot(params,1);

    llOwnerSay("Emitter Region pos is " + (string) emitterRegionPos + " rot " + (string) emitterRegionRot);

    list targets = llCastRay(emitterRegionPos, emitterRegionPos + range * (emitterRegionRot * correctBy), [RC_DETECT_PHANTOM, TRUE]);
    llOwnerSay("Raycast got " + llDumpList2String(targets, ",") );

That's my code.

It's from one page  back at the end of the three-pictures post. I use PRIM_POSITION and PRIM_ROTATION because you have to have region coordinates for where the emitter prim is and where it is aligned to. 

You are using PRIM_POS_LOCAL and PRIM_ROT_LOCAL and then multiplying them by llGetPos and llGetRot. Have you checked to see if those give the same values as PRIM_POSITION and PRIM_ROTATION ?

The parts you say are missing are there, except that where you have a Euler rotation I have a quaternion.

 

Edited May 17, 2021 by Profaitchikenz Haiku

[Profaitchikenz Haiku]

15 hours ago, VirtualKitten said:

list l = llGetLinkPrimitiveParams(link,[PRIM_POS_LOCAL,PRIM_ROT_LOCAL]);  
    rotation correction = llEuler2Rot(<0.0,70.0,0.0>* DEG_TO_RAD); // Part you are missing [1]
    rotation emitRot = (rotation) llList2String(l,1)*llGetRot();  
    vector emitPos = llList2Vector(l,0)+llGetPos();
    
    list targets = llCastRay(emitPos, emitPos + <0.0, 0.0, 12.0> * (emitRot * correction),  // // Part you are missing [2]

OK, so after a good night's sleep the problem is obvious.

You get local rot and multiply it by the root rot. This is OK, it will give the same value as (emitter, [PRIM_ROTATION... that I recommended

You get local pos and add it to root pos. This is not adjusting for rotation and will always give the same position regardless of how the root has been rotated. It will not give the changing values that I recommend you get via PRIM_POSITION

To demonstrate this I used the following script in Puff rotating him through the four quadrants and chatting out my figures and then your figures. (emitter is not defined in the function but is the link number of the child prim)

findLocations()
{
    list params;

    params = llGetLinkPrimitiveParams(emitter, [PRIM_POSITION, PRIM_ROTATION]);

    vector emitterRegionPos = llList2Vector(params,0);
    rotation emitterRegionRot = llList2Rot(params,1);

    params = llGetLinkPrimitiveParams(emitter, [PRIM_POS_LOCAL, PRIM_ROT_LOCAL]);
    vector emitterLocalPos = llList2Vector(params, 0);
    rotation emitterLocalRot = llList2Rot(params, 1);

    rotation emitRot = emitterLocalRot * llGetRot();
    vector emitPos = emitterLocalPos + llGetPos();

    llOwnerSay("Emitter Region pos = " + (string) emitterRegionPos + " Emitter Region rot = " + (string) emitterRegionRot);
    llOwnerSay("VK method Pos = " + (string) emitPos + " VK method rot = " + (string) emitRot);
}

 

Giving the following output.

0 degrees
 Emitter Region pos = <124.40740, 78.44512, 27.52179> Emitter Region rot = <-0.54562, 0.54562, 0.44978, 0.44978>
 VK method Pos = <124.40740, 78.57415, 27.13323> VK method rot = <-0.54562, 0.54562, 0.44978, 0.44978>
90 degrees
Emitter Region pos = <122.71510, 76.89143, 27.13441> Emitter Region rot = <-0.83711, -0.06548, 0.53329, 0.10278>
 VK method Pos = <124.40740, 78.57415, 27.13323> VK method rot = <-0.83711, -0.06548, 0.53329, 0.10278>
180 degrees
 Emitter Region pos = <124.31630, 75.24936, 26.72500> Emitter Region rot = <0.63822, 0.63822, -0.30442, 0.30442>
 VK method Pos = <124.40740, 78.57415, 27.13323> VK method rot = <0.63822, 0.63822, -0.30442, 0.30442>
 270 degrees
 [Emitter Region pos = <126.00870, 76.80306, 27.11238> Emitter Region rot = <0.06548, 0.83711, 0.10278, 0.53329>
 VK method Pos = <124.40740, 78.57415, 27.13323> VK method rot = <0.06548, 0.83711, 0.10278, 0.53329>
 

Notice that although your method gets the rotation right, your method always gets the same region positions regardless of where the root has been turned to. Not only that, it's Y and Z-figures aren't the same as my 0-degree figures because Puff has a slight rotation around the X-axis of 14 degrees. You must correct for rotation to get the correct position.

Now, you say that my code still needs some work, but looking though your code I see two comments that I think aren't yours but have been added by somebody else.

// Part you are missing [1]

and again 

// // Part you are missing [2]

 

So behind the scenes, away from the forum where their suggestions can't be scrutinised, somebody is suggesting you do things in the code. I'm sure they're well-meaning, and one can sympathise with a person who doesn't want to open themselves up to criticism.

Because they are comfortably anonymous they can't be challenged, which is fair enough, but you have then decided to say "I hope you can see Prof something is still needing work on your code ."

Except, (I hope you can see), it's not my code once you and Another start changing it. It's your code now

I'm sure you'll get there in the end, just don't lose heart.

 

Edited May 18, 2021 by Profaitchikenz Haiku

[VirtualKitten]

Hi Prof I ran it and had these results I had to add in integer emitter with link  number to get it to compile. No I am always grateful of help . Its a lot to comprehend  kisses

[02:09] Fire Emitter: Emitter Region pos = <204.54550, 42.19197, 3499.22000> Emitter Region rot = <-0.82161, -0.02047, -0.02956, 0.56892>
[02:09] Fire Emitter: VK method Pos = <210.91180, 42.26188, 3499.57500> VK method rot = <-0.58705, 0.12782, -0.71923, -0.34891>
[02:09] Fire Emitter: Raycast got 941cf7c5-099a-739a-6f7e-4d2969002c72,<213.903500, 38.844600, 3496.037000>,1
[02:09] Fire Emitter: Found Skye Land Forms Simple Bumpy Square (<226.17260, 28.34417, 3496.03300>)  at  rezAt<213.90350, 38.84460, 3496.03700>
[02:09] Fire Emitter: Axis <-6.609726, -3.117524, -1.771039><6.609726, 3.117524, 1.771039>

Edited May 19, 2021 by VirtualKitten

[VirtualKitten]

I changed my rezz to  llRezObject("Fireball II MoveTo(llDie)", llGetPos(),ZERO_VECTOR, ZERO_ROTATION, 0);     it now rezzes at place but doesnt seem to get move command

[VirtualKitten]

I changed my positions to Gobals and got no hits at all 

    list l = llGetLinkPrimitiveParams(link,[PRIM_POSITION,PRIM_ROTATION]);  
    rotation correction = llEuler2Rot(<0.0,70.0,0.0>* DEG_TO_RAD); //  [1]  Causing it to stop using llCastRay
    rotation emitRot = (rotation) llList2String(l,1);  
    vector emitPos = llList2Vector(l,0);
    
    list targets = llCastRay(emitPos, emitPos + <0.0, 0.0, 12.0> * (emitRot * correction), [RC_DETECT_PHANTOM, TRUE]);
 

 

[03:47] Fire Emitter: Emitter Region pos = <204.59780, 42.19997, 3499.28400> Emitter Region rot = <-0.83674, -0.03068, -0.04713, 0.54470>
[03:47] Fire Emitter: VK method Pos = <210.97770, 42.22906, 3499.63100> VK method rot = <-0.56183, 0.11590, -0.73342, -0.36470>
[03:47] Fire Emitter: Raycast got 0

Edited May 19, 2021 by VirtualKitten

[Profaitchikenz Haiku]

BUT - this is significant

2 hours ago, VirtualKitten said:

[02:09] Fire Emitter: Emitter Region pos = <204.54550, 42.19197, 3499.22000> Emitter Region rot = <-0.82161, -0.02047, -0.02956, 0.56892>
[02:09] Fire Emitter: VK method Pos = <210.91180, 42.26188, 3499.57500> VK method rot = <-0.58705, 0.12782, -0.71923, -0.34891>

your rotation method is now not getting the same as my rotation method, see the differences?

And then in the second try, look at the positions and rotations, they are not the same, you have changed the dragon root position or changed the child emitter position since the first try.

39 minutes ago, VirtualKitten said:

[03:47] Fire Emitter: Emitter Region pos = <204.59780, 42.19997, 3499.28400> Emitter Region rot = <-0.83674, -0.03068, -0.04713, 0.54470>
[03:47] Fire Emitter: VK method Pos = <210.97770, 42.22906, 3499.63100> VK method rot = <-0.56183, 0.11590, -0.73342, -0.36470>
[03:47] Fire Emitter: Raycast got 0

It is possible now that because the rotations are different the range of 12 metres is no longer enough to find a target.

In an earlier post I showed you how to make and use an indicator prim. I suggest you go back and follow the steps in that post,

1) make the indicator prim, change it to be twice the range along the Z-axis so that the profile cut B 0,5 makes it visible exactly the range

2) give it the position and rotation figures, and see where it is at and pointing to using first of all the emit region pos and rotations,

3) then, in a script, multiply that rotation by your correction rotation and see where the actual ray is going. The length of the indicator will show you the maximum extent of the ray and it will be obvious firstly if it is finding any targets in range, and secondly, if your correction rotation is the right one to be using.

In the bit of code below, the value (emitRot * correction) is exactly the rotation of the ray, so chat out the result of (emitRot * correction) and feed it to the indicator.

45 minutes ago, VirtualKitten said:

emitPos, emitPos + <0.0, 0.0, 12.0> * (emitRot * correction)

 

4) in that same post I show you how to use the indicator beam to work out the proper correction rotation. Try that if you find the indicator beam is not pointing where it should be.

[VirtualKitten]

well its that line in [1] that doesnt want to work with cast ray 

On 5/18/2021 at 5:29 AM, Profaitchikenz Haiku said:

rotation correction = llEuler2Rot(<0.0,70.0,0.0>* DEG_TO_RAD); // Part you are missing [1]

here

2 hours ago, VirtualKitten said:

list targets = llCastRay(emitPos, emitPos + <0.0, 0.0, 12.0> * (emitRot * correction), [RC_DETECT_PHANTOM, TRUE]);

 

[VirtualKitten]

ok changed it to z axis even though model is Y now get 
[06:25] Fire Emitter: Emitter Region pos = <204.59780, 42.19997, 3499.28400> Emitter Region rot = <-0.83674, -0.03068, -0.04713, 0.54470>
[06:25] Fire Emitter: VK method Pos = <210.97770, 42.22906, 3499.63100> VK method rot = <-0.56183, 0.11590, -0.73342, -0.36470>
[06:25] Fire Emitter: Raycast got 459c4a1b-b491-bde1-a136-f1bd309d87e9,<197.786700, 45.069440, 3496.038000>,1
[06:25] Fire Emitter: Found *alirium* nanohana (<198.54100, 40.09956, 3495.57500>)  at  rezAt<197.78670, 45.06944, 3496.03800>
[06:25] Fire Emitter: Axis <-6.609726, -3.117524, -1.771039><6.609726, 3.117524, 1.771039>
[06:25] Fire Emitter: foward facing is  axis
[06:26] Fireball II MoveTo(llDie): Dracarys<197.78670, 45.06944, 3496.03800><-0.83674, -0.03068, -0.04713, 0.54470>
[06:26] Fireball II MoveTo(llDie): Moving..<197.78670, 45.06944, 3496.03800>

 

But the ball doesn't get the correct target but gets to target not moving idk

 

Edited May 19, 2021 by VirtualKitten

[Profaitchikenz Haiku]

There re several reasons, the one to check first is hat correction angle, your figure might not be correct. My suggestion for using the indicator beam is to first of all double-check that.

I believe you got this figure from the triangle you made up to find the line of the particles, but as it is only in one of the three axes I have a suspicion there is further rotation in the emitter that needs to be countered.

[Profaitchikenz Haiku]

If the positions and rotations you are chatting out make sense to you then carry on, but I would stress that changing axes on a whim is a poor substitute for measuring exactly where things are pointing towards.

[VirtualKitten]

Please see gif i uploaded Prof above

 

I don't think cast ray is doing its job I am a bit stuck im in world please if you have time

Edited May 19, 2021 by VirtualKitten

[VirtualKitten]

53 minutes ago, VirtualKitten said:

ok changed it to z axis even though model is Y now get 
[06:25] Fire Emitter: Emitter Region pos = <204.59780, 42.19997, 3499.28400> Emitter Region rot = <-0.83674, -0.03068, -0.04713, 0.54470>
[06:25] Fire Emitter: VK method Pos = <210.97770, 42.22906, 3499.63100> VK method rot = <-0.56183, 0.11590, -0.73342, -0.36470>
[06:25] Fire Emitter: Raycast got 459c4a1b-b491-bde1-a136-f1bd309d87e9,<197.786700, 45.069440, 3496.038000>,1
[06:25] Fire Emitter: Found *alirium* nanohana (<198.54100, 40.09956, 3495.57500>)  at  rezAt<197.78670, 45.06944, 3496.03800>
[06:25] Fire Emitter: Axis <-6.609726, -3.117524, -1.771039><6.609726, 3.117524, 1.771039>
[06:25] Fire Emitter: foward facing is  axis
[06:26] Fireball II MoveTo(llDie): Dracarys<197.78670, 45.06944, 3496.03800><-0.83674, -0.03068, -0.04713, 0.54470>
[06:26] Fireball II MoveTo(llDie): Moving..<197.78670, 45.06944, 3496.03800>

 

But the ball doesn't get the correct target but gets to target not moving idk

 

 

Edited May 19, 2021 by VirtualKitten

[VirtualKitten]

Hi Prof I think either the end of the castray is calculated wrong or the rezAt is wrong . The routines are essentially same as you have in puff .

Code to create flame and rez fire.

    integer link = check_for_prim("Fire Emitter");
    //llOwnerSay("link:"+(string)link);
    findLocations();
    list l = llGetLinkPrimitiveParams(link,[PRIM_POSITION,PRIM_ROTATION]);  

    rotation emitRot = (rotation) llList2String(l,1);  
    vector emitPos = llList2Vector(l,0);
    rotation correction = llEuler2Rot(<0.0,0.0,70.0>* DEG_TO_RAD); 
    
    list targets = llCastRay(emitPos, emitPos + <0.0, 0.0, 12.0> * (correction * emitRot ), [RC_DETECT_PHANTOM, TRUE]);
    if( _debug) llOwnerSay("Raycast got " + llDumpList2String(targets, ",") );
    
    
         integer iiMax = llGetListLength(targets);
         integer hits = llList2Integer(targets, iiMax-1);
    if(hits > 0 ) {
         iiMax -=1; // move back from the result count to the last returned pair
         integer ii;
         list targetDetails;
         if( hits > 0)
         {
              for( ii = 0; ii < iiMax; ii+=2)
              {
                    targetDetails = llGetObjectDetails(llList2Key(targets, ii), [OBJECT_NAME, OBJECT_POS]);
                    string targetName = llList2String(targetDetails, 0);
                    vector targetPos = llList2Vector(targetDetails, 1);
                    vector rezAt = llList2Vector(targets, ii+1);    // See the caveat regarding silently failing at too great a distance

                    if(_debug) llOwnerSay("Found " + targetName + " (" + (string) targetPos + ") " + " at  rezAt" + (string) rezAt );
                    
                    vector size = llList2Vector(llGetLinkPrimitiveParams(1,[PRIM_SIZE]),0);
                    list box = llGetBoundingBox( llGetKey());
                    vector c = (llList2Vector(box, 0) + llList2Vector(box, 1)) * 0.5;
                    
                    string axis="";
                    llOwnerSay("Axis "+(string)box);
                   
                    llOwnerSay("foward facing is "+ axis + " axis");
                    llRezObject("Fireball II MoveTo(llDie)", llGetPos(),ZERO_VECTOR, ZERO_ROTATION, 0);                 
                   // llRezObject("Fireball(llDie)", rezAt, emitPos, emitRot, 0  );
                    llSleep(2); llSay(-6,"D|" +(string)(rezAt)+"|"+(string)emitRot);
                 
                    
               }
         }
    } 
    

 

Edited May 19, 2021 by VirtualKitten

[Profaitchikenz Haiku]

21 minutes ago, VirtualKitten said:

don't think cast ray is doing its job I am a bit stuck im in world please if you have time

I don't have time at the moment. I'm smashing up pallets for firewood.

In as few words as possible, can you explain why you won't make the indicator beam and double-check your correction angle as I have suggested?

[VirtualKitten]

Looking at your code Prof RezAt is only set to the resultant  vector of target ii+1 no other addition is given . Is this why it has no forward position idk  or is the ray completely wrong and you are relying on that which doesn't work. idk

 

I am unsure what you mean about the indicator beam i have a particle. How can i tell where the Ray is pointing as its results just show it must be pointing down  not at 70 degrees out  from emitter.

 

Denise X

Edited May 19, 2021 by VirtualKitten

[Profaitchikenz Haiku]

21 minutes ago, VirtualKitten said:

How can i tell where the Ray is pointing as its results just show it must be pointing down  not at 70 degrees out  from emitter.

You can tell by making up an indicator beam and giving it the figures for the emitter region position and the  ray cast rotation.

But going back a step earlier, you can work out the proper correction angle for the emitter region rotation. You do that by editing the script in the indicator to put this figures in, then touching it. It will point to where the emitter sphere is pointing. You then edit the indicator and turn it using the rotation fields in the edit flyer until it is now aligned exactly with the particle stream. You then touch it again, and it will work out for you and tell your exactly what the correction rotation is to make the ray go along the same path as the particles.

All this is described in this topic, page 4, the post beginning "Yes! That's what I'm talking about!", and it even includes pictures showing how to do it and the scripts to make it work.

Edited May 19, 2021 by Profaitchikenz Haiku

[VirtualKitten]

@Profaitchikenz Haiku I already did these steps  ion my own its 70 degrees inline with the parts i sent you in respect to the emitter  I dint know how to add these in as nothing i have tried has worked so far  and in fact as discussed it seems to be drilling straight own and not going out at 70 degrees same as beam I am unsure why you don't understand what I am saying  As have already said this and am now repeating myself  as you didn't listen first time  I even showed you images from properties of the bar showing you the beam was 70 degrees  idk what more to say I knw you are trying your best to help  and I appreciate it  too but if you don't know what's happening  and listen to what i tell and show you as a result of what you asked me to provide. Its very frustrating  I still think i was better with trig at least those routines i wrote put the ball on the spot even if it was not at any other rotation. This cant even do that  much .

here it is again 

Hugs

D.

Edited May 19, 2021 by VirtualKitten

[Profaitchikenz Haiku]

21 minutes ago, VirtualKitten said:

it seems to be drilling straight own and not going out at 70 degrees

The beam you showed had a single rotation of 70 degrees, but the emitter will have additional rotation in some of the other axes. In order to point down from  the Z axis by an extra 70 degrees you will actually be rotating around one or both of the X and Y axes. You can see this from the figures being chatted out for the PRIM_ROTATION: in addition to a rotation around the Z axis due to the direction the dragon is facing, there are additional rotations around the X and Y axes. All of these rotations need to be taken into account when working out the extra rotation to get the ray going along the same line as the particles.

The items you have been ending me inworld are not really useful for several reasons: they are no-copy no-mod mostly, but on their own they are useless, they would only make sense when placed together with the dragon. 

I would rather you follow my suggestions of making indicators to let you see in world exactly where things are pointing. You won't learn without making this effort.

The method I show on page 4 of this topic demonstrates a universal method for working out what the additional rotation is that will be needed to align a ray directly along the particles beam. Your triangle you rez in -world is not enough information to go on, you need to know also the emitter position and rotation.

Making the indicator beam that I suggest will allow you to do several things: see which way the Z-axis of the emitter sphere is pointing, with a little work, see which way the ray-cast is going, but most importantly, it will help you work out what the extra rotation is.

More than that, it can be used again for other projects where there might be other tricky rotations to be handled.

[VirtualKitten]

Prof i had a friend over Solace Tiger Paw who helped sort out cast ray and was super fun  we worked out CastRay was firing of in totally wrong direction  and this is what we ended up with :

 list targets = llCastRay(emitPos, emitPos + (12*llRot2Up(emitRot)), [RC_DETECT_PHANTOM, TRUE]); 

Now it was what it should have been now the  llMoveToTarget(pos, 5.0); might be a problem as it only works with physical prims i forgot this and why its not moving . this all needs thinking through as firing physical items might not be desirable and the alternative is KeyFrameMotion. I really need to think about this and the prospects of collision as am not sure its a good or bad thing?

Edited May 19, 2021 by VirtualKitten

[VirtualKitten]

Here it is , I think it might be better to sleep the time and do it in 0.2

Edited May 20, 2021 by VirtualKitten

[VirtualKitten]

On 4/27/2021 at 8:00 AM, Profaitchikenz Haiku said:

Thanks for the link, that looks interesting.

 

Prof thanks so much for standing your ground and sticking with llCastray , when I threw so many other methods that seemed to work . I am amazed it can do this and saves so much extra handling You certainly set me on the right path   I have procedure now am now using and have made it a little better yesterday .

v_final *v_final  = v_init *v_init   + accel * time to can calculate the time that the particle runs for so it meets this target  we had a maths lesson online yesterday teacher got an apple. The PSYS_SRC_BURST_SPEED_MIN, and PSYS_SRC_BURST_SPEED_MAX, was used in velocity and acceleration to calculate time to allow the particle to run full time to destination . I changed the fire ball to disable the listen loop after first execution and use this timer instead of at target. I added an not_at_target to destroy the prim  in case something goes wrong. It seems to  be working