Maths trigonometry problems scripting RezObject()

[Profaitchikenz Haiku]

So to summarise what was found inworld:

Puff was able to find the mesh terrain and plants and rezz an object, proving the script works in a sympathetic build  (There were differences in the reported region rotations of the two emitters being compared, so where the dragon was casting it's ray wasn't where Puff was casting his).

However, the main stumbling block is that due to the size of the dragon (to which Puff is but a gnat to a horse), the distance from the emitter to the target found by ray-casting is more than the limiting distance of llRezObject. Puff didn't rezz once the range exceeded 12 and a bit metres.

The solution to this stumbling block is actually the solution to the other problem, of knowing where the ray from the child prim is actually pointing:

Rezz the object just outside the emitter and make it glide along a vector which starts at the emitter and ends at the farthest ray-cast position, then not only will you actually see where your ray is being cast to, but you're almost there with the rezzing the fireball regardless of how far away the incineration point is.

I'll try beefing up Puff to have a mightier weapon than his diminutive size would suggest.

 

 

[Profaitchikenz Haiku]

One thing I have spotted is VirtualKitten trying to do things from the root prim, which is actually a good idea as it means there's one less script, so I revised Puff to show how the root prim can know exactly where the child prim is in the region and what it's region rotation is:

using llGetLinkPrimitiveParams(emitter, [PRIM_POSITION, PRIM_ROTATION]); we get the right two values so we can do everything from inside the root prim in the one script.

The next problem I spotted was that it is hard to visualise where exactly the emitter prim is casting the ray, so here's a simple technique:

build a cube, make it 0.2 metres along X, 0.2 metres along Y, 20.0 metres along Z, and then set Slice Begin to 0.5

The resulting indicator prim is pointing up and down the Z-axis which is where (in this instance) the particles are coming from.

Inside it put a script to make it go to a region position and a rotation when touched.

// set a prim to a region pos and rot

key owner;

// <14.90247, 113.65760, 502.84370> rot <-0.54953, 0.54953, 0.44500, 0.44500>
vector setPos = ZERO_VECTOR;
rotation setRot = ZERO_ROTATION;

default
{
    state_entry()
    {
        owner = llGetOwner();
    }

    touch_start(integer number)
    {
        if( setPos != ZERO_VECTOR)
        {
            llSetRegionPos(setPos);
            llSetRot(setRot);

        }
    }
}

In the root prim, put the following function

findLocations()
{
    list params;

    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);
}

Now put those two numbers into the script in the indicator prim to replace ZERO_VECTOR and ZERO_ROTATION, and touch it.

The indicator prim will now adopt the orientation of the emitter prim along the Z-axis, which is the particle emitter direction, and also the direction along which we are going to ray-cast. Any targets that would be picked up by a cast ray should be touched by the indicator if they are inside the range at which llRezObject can be expected to actually work and not silently fail.

I noticed during the tests inworld that the rotation value returned from VirtualKitten's dragon emitter was at ninety degrees to the direction of Puff's vector, and I suspect this is a build issue that will need to be resolved.

(I am suspicious that although I saw particles coming out of the emitter along what I took to be the Z+ axis, the rotation value chatted out by VK's script was suggesting that the emitter ray cast direction was at 90 degrees to the particle direction, so I'm betting on confusion in the build, unless some knowledgeable person can step in and say that in animesh, the particle direction is also not as in prims or normal mesh).

Edited May 16, 2021 by Profaitchikenz Haiku

[VirtualKitten]

Well i saw the wiki page:

 

Maximum rez distance

• After tests on server 1.38, these figures were measured - (on some earlier server versions the same further-than-10-meter rezzes have been possible).
• The distance measured is between the center of the rezzing prim and the center of the prim that is rezzed.
  • The tests did not include rezzing from or the rezzing of link_set objects.
  • A 10.0 meter cube could rez a 0.5 meter cube just beyond 18.6 meters away.
  • A 0.01 cube could rez a 0.5 meter cube just beyond 10.0 meters away.

Which is limitation on rezzing this gets a whole lot more complicated as i have a start and end point from ll Cast Ray evenn though we do not know why it only worked at 12m not 32m and need each prim to cascade rez the next one less than 9.5 metres apart then lldie before the last distance creating fire . Does that make sense or can a velocity given to the rezed item achieve the same result  before flaming on at destination.

http://wiki.secondlife.com/wiki/LlGodLikeRezObject

I found this but it made no sense . I am guessing with start and end and 9.5m distance a velocity could be used to take it rest of the way if not could we not rez daughter and then daughter from that in a cascade to reach target ?

[Quistess Alpha]

FWIW you can only rez withing the 10meter limit, but you can llSLPPF an object to any distance, so you can rez a helper object, tell it where to go, give it the inventory (or have it pre-installed) then have it rez the thing in question.

[Profaitchikenz Haiku]

1 hour ago, Quistessa said:

FWIW you can only rez withing the 10meter limit, but you can llSLPPF an object to any distance,

Yes, the issue here really is the direction in which it has to go. That is a function of the region rotation of the emitter prim, which I have just learned is not a linked SL prim but a mesh link, and that the particles might not actually be emitted precisely along the Z-axis but at some angle from it.

My cunning plan, which has yet again foundered on the reefs of reality, was to use an indicator prim aligned with the emitter's Z-axis to see where that alignment was in relation to the intended direction and thus create an adjusted rotation fr the direction in which the ray should be cast, because currently it looks to be coming out of one nostril instead of the mouth.

Tomorrow may bring better luck.

"Today is the same as tomorrow except that it's happened before"

Edited May 16, 2021 by Profaitchikenz Haiku

[VirtualKitten]

Hi Prof I sent you in world [14:27] Second Life: Inventory item 'fire trajectory2 as per image' offered As requested . I textured the dragon at 100% to make it invisible 

 

 

 

Edited May 16, 2021 by VirtualKitten

[Profaitchikenz Haiku]

It would help if the picture also had a red-green-blue axis of the emitter prim to illustrate the difference in rotations between the structure you have rezzed along the path of the particles and the alignment of the emitter Z-axis. This difference is what I wanted to establish using the indicator prim method.

Instead of llCastRay(llGetPos(), llGetPos + <0.0, 0.0, 12.0>*emitterRot, you create a new rotation which is emitterRot rotated to the line the particles follow, then use the new rotation to transform the range vector. llCastRay(llGetPos(), llGetPos + <0.0, 0.0, 12.0)* (emitterRot * correctionRot) );

The pragmatic way to work out this correction angle is to use llRotBetween after getting two positions from the indicator.

1) Set up the indicator prim so it is aligned along the emitter prim Z-axis. Work out where the far end of it is in region coordinates, - pos1 (*)

2) Turn the indicator prim until it is pointing where you want the ray to go. Work out where the far end of it is now - pos2.

3) Use llRotBetween(pos1 , pos2) to get a correction rotation.

4) Your new rotation for the calculations then becomes  emitterRot * correctionRot.

(*) The simplest way to get the end point is to link a tiny prim to the end of the indicator and get it to tell you it's llGetPos()

 

Edited May 16, 2021 by Profaitchikenz Haiku

[VirtualKitten]

Um prof 

11 hours ago, Profaitchikenz Haiku said:

 

Instead of llCastRay(llGetPos(), llGetPos + <0.0, 0.0, 12.0>*emitterRot, you create a new rotation which is emitterRot rotated to the line the particles follow, then use the new rotation to transform the range vector. llCastRay(llGetPos(), llGetPos + <0.0, 0.0, 12.0)* (emitterRot * correctionRot) );

 

 

I said the thing i sent you said it was 70 degrees the particle is as you say horizontal at rest the same as the part i sent you  and pictured

[Profaitchikenz Haiku]

Are you sure about this? The picture shows a 70 degree angle from the vertical. Is the emitter prim aligned so that it's Z-axis is pointing straight down into the ground?

A few points here, you are making it very difficult to try and understand what is going on

1) The pictures, and the whole build area, are too dark and too busy to see clearly what is going on. Try going to the ground and setting environment to midday

2) The pictures aren't showing enough information. In addition to the triangle showing the line of the particles with respect to the ground, you need to show a blue/red/green set of lines showing the axes of the emitter prim as well.

Edited May 17, 2021 by Profaitchikenz Haiku

[Profaitchikenz Haiku]

Here is an example of what I mean by showing the right information

 

There is nothing in the picture not relevant to the explanation.It is light enough to see clearly.The chosen view shows the perspective of all axes.

I have created a dooHickey, three cones linked, aligned and coloured in accordance with the three axes.

The one on the ground has zero rotation.

The one at Puff's tail has been rotated to exactly the same rotation as Puff's rotation.

The one in the emitter has been rotated to the same rotation as the emitter when editing linked parts and looking at the rotation floater. It is showing that the emitter has been rotated about the X-axis (258 degrees) to point the blue axis forwards in line with the head, and also that the Z axis has been rotated by 90 degrees because the green point is not straight ahead and the red point is going downwards.

Since Puff fires dead ahead on the Z axis there is no need to correct any rotations, a range vector of <0.0, 0.0, range> * emitterWorldRotation will get the correct end point for cast Ray so long as I stick to the Z-direction.

The triangle you created can't answer the vital question - which way is the emitter rotated with respect to the particle stream?

Edited May 17, 2021 by Profaitchikenz Haiku

[Quistess Alpha]

44 minutes ago, Profaitchikenz Haiku said:

which way is the emitter rotated with respect to the particle stream?

It just occurred to me that (this probably isn't the problem you're having but I'll point it out in case it is) I think I read/heard somewhere that if you don't reset your particle stream llParticleSytem([]); then the PSYS_SRC_OMEGA from a previous call can affect the particle alignment (such that the particles no longer flow from the z axis) .

[Profaitchikenz Haiku]

30 minutes ago, Quistessa said:

this probably isn't the problem you're having but I'll point it out in case it is)

That and a host of other problems - what I'm trying to do here is not write a full script for VK but show how to investigate the unknown from first principles. There might be other ray-casting problems people want to solve where the prim in question has odd rotations on it for any number of reasons. The way to tackle this sort of problem is to try and turn the invisible into the visible and then all of a sudden it becomes clear as day what is going wrong.

A post with pictures will be along shortly.

[VirtualKitten]

so in fact rotation correction = llEuler2Rot(<0.0,70.0,0.0>* DEG_TO_RAD);  should work ?

 

Raycast got 941cf7c5-099a-739a-6f7e-4d2969002c72,<213.996500, 38.753790, 3496.037000>,1
[07:12] Fire Emitter: Found Skye Land Forms Simple Bumpy Square (<226.17260, 28.34417, 3496.03300>)  at <213.99650, 38.75379, 3496.03700>

But nothing was still rezed 

Am working on new fireball with the following but still thinking about how to degin around without initial say and listen 

 on_rez(integer startup_param)
    {
        
        flame=1;
        //llSetObjectDesc("NEW PRIM DESCRIPTION");
        //Perhaps link and drop item or listen 
        // for llSay to set  decription.
        
        vector pos = (vector)llGetObjectDesc();
        target_arival_id =  llTarget(pos, 50.0);
        llMoveToTarget(pos, 5.0);
       
    }

at_target(integer tnum, vector targetpos, vector ourpos) {

          target_arival_id= __llTargetRemove(target_arival_id);
          flames(); 
           llSetTimerEvent(20);
   
   }

 

and 

Edited May 17, 2021 by VirtualKitten

[Profaitchikenz Haiku]

"Yes! This is what I'm talking about!" (Sebastian Vettel before Kharma reared it's head)

I have lifted Puff up in the air so that the 10-metre position along the normal firing line is still some way up above the ground,

[06:00]  Puff the dragon (root-driven): Emitter Region pos is <145.06500, 90.65607, 28.94051> rot <-0.54953, 0.54953, 0.44500, 0.44500>
[06:00]  Puff the dragon (root-driven): Raycast got 0
[06:00]  Puff the dragon (root-driven): Hits 0
[06:00]  Puff the dragon (root-driven): Nothing in range

So I prepare an indicating beam to try and see what is going wrong. It is a prim 20 metres tall profile-cut to b = 0.5 so it can pivot around the centre and is therefore visibly the length (10 metres) of the valid rezzing range. It has with a sphere stuck on the end. The sphere is the child prim used to work out the region coordinates of the far end of the beam. Inside the beam is a script into which I enter the Region Ps and rot figures that Puff muttered above. Then I touch it.

So I use the indicator beam to see where the 10-metre point is along the line of fire. I touch it and it lines up along the beam and I can see immediately that the beam is not going to find the ground.

[06:41]  Indicator: End point 1 is <145.06610, 95.54512, 27.89333>
[06:41]  Indicator: Rotate me and then touch again

I turn the beam downwards until the end just touches the ground and touch it.

[06:42]  Indicator: End point 2 is <145.06610, 94.93783, 26.35867>
[06:42]  Indicator: The correction rotation between the from and to points is <-0.16505, 0.00003, -0.00002, 0.98629> or in Radians <-0.33161, 0.00007, -0.00002> or in degrees <-18.99997, 0.00423, -0.00108>
I then alter Puff's script to multiply the emitter rotation by the correction rotation before then calculation the end point for the cast ray and try again

[06:45]  Puff the dragon (root-driven): Emitter Region pos is <145.06500, 90.65607, 28.94051> rot <-0.54953, 0.54953, 0.44500, 0.44500>
[06:45]  Puff the dragon (root-driven): Raycast got 00000000-0000-0000-0000-000000000000,<145.065100, 94.920090, 26.378400>,1
[06:45]  Puff the dragon (root-driven): Hits 1
[06:45]  Puff the dragon (root-driven): Found a target at <145.06510, 94.92009, 26.37840>

There we are!

The indicator beam script

// set a prim to a region pos and rot

key owner;

vector fromPos =  ZERO_VECTOR; // won't change 
rotation fromRot =  ZERO_ROTATION; // will change
rotation toRot = ZERO_ROTATION; // to this

vector fromEnd = ZERO_VECTOR; // at start
vector toEnd = ZERO_VECTOR; // after rotating

rotation correctBy = ZERO_ROTATION;
vector correctByAngle = ZERO_VECTOR;

integer endPointNum = -1;   // if there aren't two prims in the link set it will fail

default
{
    state_entry()
    {
        owner = llGetOwner();
        endPointNum = llGetNumberOfPrims();
    }

    touch_start(integer number)
    {

        if( fromPos != ZERO_VECTOR && fromEnd == ZERO_VECTOR )  // we've only just begun
        {
            llSetRegionPos(fromPos);
            llSetRot(fromRot);
            fromEnd = llList2Vector(llGetLinkPrimitiveParams(endPointNum, [PRIM_POSITION]), 0);
            llOwnerSay("End point 1 is " + (string) fromEnd);
            llOwnerSay("Rotate me and then touch again");
        }
        else if( fromEnd != ZERO_VECTOR)    // we've done the initial, now see what has changed
        {
            toEnd = llList2Vector(llGetLinkPrimitiveParams(endPointNum, [PRIM_POSITION]), 0);
            llOwnerSay("End point 2 is " + (string) toEnd);
            toRot = llGetRot();
            correctBy = llRotBetween(fromEnd - fromPos, toEnd - fromPos);
            correctByAngle = llRot2Euler(correctBy);
            llOwnerSay("The correction rotation between the from and to points is " + (string) correctBy +
                " or in Radians " + (string) correctByAngle +
                    " or in degrees " + (string) (correctByAngle*RAD_TO_DEG) );
        }
        else llOwnerSay("I need at least the from position and rotation to work with");
    }
}

The amended ray cast func

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, ",") );

    integer iiMax = llGetListLength(targets) - 1;
    integer hits = llList2Integer(targets, iiMax);
    llOwnerSay("Hits " + (string) hits);
    iiMax -= 1; // move back from the result count to the last returned pair
    integer ii;
    vector rezAt;

    if( hits > 0)
    {
        for( ii = 0; ii < iiMax; ii+=2)
        {
            rezAt = llList2Vector(targets, ii+1);
            llOwnerSay("Found a target at " + (string) rezAt );
        }
    }
    else llOwnerSay("Nothing in range");
}

tion

 

 

 

 

 

[Profaitchikenz Haiku]

My work here is done...

[VirtualKitten]

That said Prof I found no 12m limits on wiki llCastRay website idk , infact example here give 25m in fact today i have it with 100m working  :http://wiki.secondlife.com/wiki/LlCastRay

 

[07:34] Fire Emitter: Raycast got 941cf7c5-099a-739a-6f7e-4d2969002c72,<213.996500, 38.753780, 3496.037000>,1
[07:34] Fire Emitter: Found Skye Land Forms Simple Bumpy Square (<226.17260, 28.34417, 3496.03300>)  at  rezAt<213.99650, 38.75378, 3496.03700>

So there is til much to work out 

Mine is 8.25572m away so why is it not rezing ?

Edited May 17, 2021 by VirtualKitten

[VirtualKitten]

Also I wrote the code to move and it moved wrong place showing it was on target changing your code

                    llRezObject("Fireball II MoveTo(llDie)", emitPos, emitPos, emitRot, 0);
                    llSay(-6,"Dracarys|" +(string)rezAt);

 

default
{
    on_rez(integer startup_param)
    {
        
        flame=1;
        target = 1;
        integer glistener = llListen(_ch,"",llGetOwner(),"");
        
        //llSetObjectDesc("NEW PRIM DESCRIPTION");
        //Perhaps link and drop item or listen 
        // for llSay to set  decription.
        

       
     }
     timer()
     {
         if(flame == 1) {smoke();flame = 0; llSetTimerEvent(5);}
         else llDie();
     }
     not_at_target () {
     }
     at_target(integer tnum, vector targetpos, vector ourpos) {
          target_arival_id= __llTargetRemove(target_arival_id);
          flames(); 
           llSetTimerEvent(20);
   
     }
     listen(integer ch, string name, key id, string data) 
     {
        list p = llParseString2List(data,["|"],[]);
        if(llList2String(p,0) == "Dracarys" &&  ch = _ch) {
            vector pos = (vector)llList2Vector(p,1);
            target_arival_id =  llTarget(pos, 50.0);
            llMoveToTarget(pos, 5.0);
        }
     } 
     
}

 

and changing fire ball  in the fire emitter . This had a peculiar result Prof  fire tracked to an odd location any ideas:

 

[08:08] Fire Emitter: Raycast got 941cf7c5-099a-739a-6f7e-4d2969002c72,<213.996500, 38.753780, 3496.037000>,1
[08:08] Fire Emitter: Found Skye Land Forms Simple Bumpy Square (<226.17260, 28.34417, 3496.03300>)  at  rezAt<213.99650, 38.75378, 3496.03700>

 

 

Edited May 17, 2021 by VirtualKitten

[VirtualKitten]

I can post another angle it looks like axis are transposed and the height of floor is missing he fact that id flaming of to the right the same distance that should be in Y is helpful however  the important floor element is missing Do I have to write a axis changer  that will change axis in accordance with front facing . I vaguely remember this in the past 

 

if its not XYZ is it YZX and then ZYX? for the different options  assuming calculation is forward facing X  i would need to transform it YZX to be correct for a model Y facing.

An to identify the facing front direction how do i do that by script please ? can i do it from size  where largest size is the axis forward? so

ie

                     if ((l.x > l.y &&  l.x > l.z ) && !(l.y > l.x &&  l.y > l.z ) ) axis ="X";
                    else  if(l.y > l.x &&  l.y > l.z ) axis = "Y"; 
                    else axis ="Z" ;

 

but its working but PRIM_Size is bringing back [09:52] Fire Emitter: Axis <13.11945, 6.13505, 3.44208>

Edited May 17, 2021 by VirtualKitten

[VirtualKitten]

@Profaitchikenz Haiku It seems the PRIM_SIZE doesn't change its axis depending on the rotation of the item huh hats no help then and a bit strange  to be honest . Also prof try rotating your creation puff it doesn't work in different directions try rotating it 180 degrees it wont find a ray 

Edited May 17, 2021 by VirtualKitten

[Profaitchikenz Haiku]

 

You're clutching at straws.

 

(I touched the emitter prim for the zero instead of Puff itself, hence the different name speaking)

[10:30]  emitter: My pos = <145.04550, 91.53010, 28.72358> my rot = <-0.54953, 0.54953, 0.44500, 0.44500>
[10:30]  emitter: Raycast got 00000000-0000-0000-0000-000000000000,<145.045500, 102.588100, 26.373130>,1
[10:30]  emitter: Hits 1
[10:30]  emitter: Found a target at <145.04550, 102.58810, 26.37313>
[10:30]  emitter: Out of range 11.305060

[10:31]  Profaitchikenz Haiku: rotated 90 degrees
[10:31]  Puff the dragon (root-driven): Emitter Region pos is <143.36630, 89.71832, 28.30530> rot <-0.84016, -0.12638, 0.52471, 0.05330>
[10:31]  Puff the dragon (root-driven): Raycast got 00000000-0000-0000-0000-000000000000,<139.121100, 88.840350, 26.382580>,1
[10:31]  Puff the dragon (root-driven): Hits 1
[10:31]  Puff the dragon (root-driven): Found a target at <139.12110, 88.84035, 26.38258>

[10:31]  Profaitchikenz Haiku: rotated 180 degrees
[10:32]  Puff the dragon (root-driven): Emitter Region pos is <144.95450, 88.32092, 27.98268> rot <0.63554, 0.63554, -0.30998, 0.30998>
[10:32]  Puff the dragon (root-driven): Raycast got 00000000-0000-0000-0000-000000000000,<144.954200, 83.684140, 26.386130>,1
[10:32]  Puff the dragon (root-driven): Hits 1
[10:32]  Puff the dragon (root-driven): Found a target at <144.95420, 83.68414, 26.38613>

[10:32]  Profaitchikenz Haiku: 270 degrees
[10:32]  Puff the dragon (root-driven): Emitter Region pos is <146.64680, 89.88114, 28.34289> rot <0.06082, 0.83797, 0.09547, 0.53385>
[10:32]  Puff the dragon (root-driven): Raycast got 00000000-0000-0000-0000-000000000000,<150.874500, 89.674860, 26.382010>,1
[10:32]  Puff the dragon (root-driven): Hits 1
[10:32]  Puff the dragon (root-driven): Found a target at <150.87450, 89.67486, 26.38201>

I suspect the ground wasn't level so the 0 degrees raycast was just out of range. Don't forget that the range dependant on the distances involved from all three axes.

Edited May 17, 2021 by Profaitchikenz Haiku

[VirtualKitten]

Nope your not taking in all changes and factors

[VirtualKitten]

were is the line i gave you earlier multiplying the angle it will be on wrong axis on x positive or z positive idk

[Profaitchikenz Haiku]

You're on your own for the time being, good luck.

[Profaitchikenz Haiku]

2 hours ago, VirtualKitten said:

@Profaitchikenz Haiku It seems the PRIM_SIZE doesn't change its axis depending on the rotation of the item huh hats no help then and a bit strange  to be honest .

It's not strange, it's normal, the PRIM_SIZE is the size of the prim and only changes when you edit it or use llSetLinkPrimitiveParams(linknum, [PRIM_SIZE, newsize]);

I have no idea why you're looking at PRIM_SIZE, it's PRIM_POSITION that will change as you rotate the emitter around.

I have to devote most of my time now to catching up with some projects for other people that I have put on hold, so I can't devote as much time to this anymore.

You have more than enough code snippets I've posted to make this work. Please try and stick to the following for the time being:

If you must use trig functions, be sure to give them RADIANS as input.

If you're going to rotate around and try to work out where something is, use PRIM_POSITION not PRIM_SIZE

If you're going to post images to illustrate a point, try to make them clear and uncluttered.

If you're going to post code snippets, trim them down to the concise minimum to show what's happening, but also include all the information needed for somebody else to replicate the code inworld to see what is going on. 

Tackle one problem at a time, don't jump to the fireball rezzing problem until you've learned how to aim the weapon first of all. Use the indicator trick to see where exactly it's casting the ray and what exactly the ray is encountering.

Edited May 17, 2021 by Profaitchikenz Haiku

[VirtualKitten]

Quote

 

Using

From RezBall and your llCastRay

 

 

[14:40] Fire Emitter: Raycast got 941cf7c5-099a-739a-6f7e-4d2969002c72,<213.903500, 38.844600, 3496.037000>,1
[14:40] Fire Emitter: Found Skye Land Forms Simple Bumpy Square (<226.17260, 28.34417, 3496.03300>)  at  rezAt<213.90350, 38.84460, 3496.03700>

 

  integer link = check_for_prim("Fire Emitter");
   
   
    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]

[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)", emitPos, emitPos, emitRot, 0);
                    llSay(-6"D|" +(string)rezAt+"|"+(string)emitRot); // Destination to send ball [3]
                    //llRezObject("Fireball(llDie)", rezAt, emitPos, emitRot, 0);
                    
               }
         }
    } 

 

This is what happens to the Fire ball after its rezed at same location of emitter and the moved by      at_target(integer tnum, vector targetpos, vector ourpos) {
          target_arival_id= __llTargetRemove(target_arival_id);
          flames(); 
           llSetTimerEvent(20);
   
     }
     listen(integer ch, string name, key id, string data) 
     {
        list p = llParseString2List(data,["|"],[]);
        if(llList2String(p,0) == "D" &&  ch = _ch) {
            vector pos = (vector)llList2Vector(p,1);
            target_arival_id =  llTarget(pos*llList2Rot(p,2), 50.0);
            llMoveToTarget(pos*llList2Rot(p,2), 5.0);
        }
     } 

     
}

 

As you can see the rezzed ball  does not move to the correct position on Y axis end of the flames:

 

Now looking at point [1] I need a code  or coding that calculates front of creature to calculate displacement of 70 degrees to correct axis depending on rotation . Clearly your calculate llCastray are or must be emitting in wrong direction  I wondered if i could use llRot2Fwd () some how or bounding box to find front Idk, the problems with 100m ray destination still seem to need to be found as worked this afternoon and failed later in day resulting them back to 12m. i wonder if this was why rotating 180 degrees failed to create ray.

This all said i duplicated my gate 90 degrees and you can see ball does not end up at target idk as it does not catch fire. I am unsure why It was before I added a rotation in of the emitter to it . However it did not have the result I expected to put the ball on the Y axis again i thing i need code to work out front and reverse axis for when the emitter rotates 180 or in a circle  as currently it is placing it on X axis not Y . Also note it ends up slightly higher than emitter very odd . I expected it to be on the floor and move diagonally down to end target position.

The other ball under emitter is nothing important its my editable version to copy to the emitter

I hope you can see Prof something is still needing work on your code . Sorry but there it is  x

Denise

 

Edited May 17, 2021 by VirtualKitten