sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-10T16:35:27Z
Showing axis
Closed sl-service-account closed 7 months ago
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-10T16:35:27Z
Showing axis
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-10T16:43:42Z
Just to add it doesn't seem to want to detect the nearer wooden box at all, its bewildering and seems to be to do with adding a width to the beam , with a width of 0 the item is found however. Does this indicate a bug in the CastRay() or is there something not quite right in my bounding box calculation for ray? I would be grateful of any assistance if this is not a bug to help resolve this. Thank you.
I would note the wiki page http://wiki.secondlife.com/wiki/LlCastRayis not clear on these start and end parameters and could do with some improvement do describe lindens perception of them. This would be helpful too.
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-10T17:08:10Z
I have marked the area of he expected beam to search
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-10T17:11:11Z
A better view of search area as CastRay() sent out from green box. exepected was two items in area of search minimum up to 5
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-10T17:33:13Z
I am happy to give further details of any of these items i have used. It is interesting that the single beam works but the wide beam doesn't this either leads me to believe the wide beam doesn't work or the linden wiki page requires updated explanation of its use.
I am unsure what is wrong but have tried to be as concise as possible
Denise x
sl-service-account
commented
6 years ago Lucia Nightfire commented at 2018-08-10T23:06:54Z
You cannot control the width of the beam, only the start and end points which are global(region) positions.
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-11T08:06:52Z
Yes Lucia, thank you for quick you reply, If you look at my code in first section, it should be seen to be setting the START and END points correctly and returning up to 5 RC_MAX_HITS in the list returned:
i.e ray = llCastRay(llGetPos()+<0.0,-(width/2),0.0>, llGetPos() + <-50.0, (width/2), 0.0>,[RC_MAX_HITS, 5]);
If I, set width to 6.0 I believe should set the BB as in the picture with the red beam under the two boxes colored faint red as a prim. it locates nothing and returns 0 in ray. I am presuming llGetPos() returns global positions which from I am applying offsets. If width is set to 0 it returns items correctly as detailed in wiki page. However with a wider Bounding Box it CastRay() doesn't seem to function correctly to locate collisions in Bounding Box.
To replicate create two linked prims copy the code in section 1 to the non root on the floor make other higher so as to not interfere with the ray. Create the boxes as I have done surrounding these two linked boxes on + x side and restart the script to get the position. The code only looks at x + axis as this is were identified a problem. You will get response in chat.
Thanks
Denise
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-11T15:30:40Z
Hi Lucia, I reversed the positive and negative on the width positions
ray = llCastRay(llGetPos()+<0.0,(width/2),0.0>, llGetPos() + <50.0,-(width/2), 0.0>,[RC_MAX_HITS, 5]);
There was only one ray list entry returned: 0ce7345-3132-24d8-d473-4986c2bf0d35<60.041910, 133.121900, 1941.344000>1 raytype = x
I still would have expected three to be returned here if i set width to 0 with this command :
ray = llCastRay(llGetPos()+<0.0,(width/2),0.0>, llGetPos() + <50.0,-(width/2), 0.0>,[RC_MAX_HITS, 5]);
You will see it returns two as expected : b0ce7345-3132-24d8-d473-4986c2bf0d35<57.549330, 130.590000, 1941.344000>62b13237-a387-9f64-1ca2-61360a6c3843<63.161100, 130.590000, 1941.344000>2 raytype = x
From this there is some difference as to the orientation of the bounding box which in one form does not return anything. In the form I have showed here you it will only identify one instead of three which is expected. I note there was an extra' - ' in my code when i typed it here on this page.
Thanks
Denise
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-11T15:36:51Z, updated at 2018-08-11T15:41:07Z
As you can see from my post today and this clearer image: https://jira.secondlife.com/secure/attachment/102823/Snapshot%20linen_007.png there is three items in the ray and only two are located.
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-11T18:03:39Z, updated at 2018-08-11T18:04:12Z
from the image https://jira.secondlife.com/secure/attachment/102824/Snapshot%20linen_008.png Moving the green upright prim .5 x.5 x 3 makes no entry of this object coming into the ray. I am unsure why this is not detected and only two objects are detected: b0ce7345-3132-24d8-d473-4986c2bf0d35<57.549330, 130.590000, 1941.344000> 62b13237- a387-9f64-1ca2-61360a6c3843<63.161100, 130.590000, 1941.344000>2 raytype = x
sl-service-account
commented
6 years ago Lucia Nightfire commented at 2018-08-11T23:40:50Z
Your setup is specific and uses many unnecessary components that make diagnosing the problem more difficult.
Could you please make a bare bones setup with a castray emitter that ownersays the all castray inputs used, as well as the position, rotation, phantom state and size of a cube that does not return castray hits.
This would be the easiest way for anyone to attempt to replicate the conditions.
Lastly, the code you posted is not copy and paste friendly and seems to have been modified while in the description field as the commenting used prevents compiling in a script editor. In the future, please use code tags when posting code and verify what you post can be correctly copy & pasted in a script editor and saved.
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-12T07:58:44Z, updated at 2018-08-12T08:46:42Z
Lucia, Thanks for your help to summarize the faults I am detecting:
i)Bounding Box co-ordinates reversal needs a debug channel output to record the correct parameters have not been passed in bounding box conforming to secondlife grid co-ordinates.
ii) The CastRay() code needs modifying to allow all objects near or far or size to be detected. The green item in my image https://jira.secondlife.com/secure/attachment/102823/Snapshot%20linen_007.png of .5x.5x3 is never detected in the light pink field neither is light pink area as its phantom.
iii) wiki page needs to elaborate on bounding box examples to encompass and example which can be replicate that detects all near and far objects in bounding box. So as to make it clear this functionality exists as part of this code.
In regard to my code: I am unable to use codetags in this reply so have pastebin my code for better readability and syntax checking I hope this helps: https://pastebin.com/0UT6zCPq
As you can see from my pictures this is bare bones setup with just prims am happy to provide you with in world! The routines use a loop to detect and return the nearest item. The only other information provided is collision detection which does not afford an answer that works either as the item detection is not from the root.
(******************I can provide you all the objects compete in world to help you test, upon request******************************)
Clearly with this not functioning as it should it renders any collision detection from a linked prim using collision_start(integer num)undetectable as neither collision_start(integer num) or llVolumeDetect(TRUE); seem to work as a collision detector with these items part of a linked prim and not the root prim.
Thank you Denise X
sl-service-account
commented
6 years ago Whirly Fizzle commented at 2018-08-12T10:52:01Z
Lastly, the code you posted is not copy and paste friendly and seems to have been modified while in the description field as the commenting used prevents compiling in a script editor. In the future, please use code tags when posting code and verify what you post can be correctly copy & pasted in a script editor and saved.
I edited to add code tags.
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-12T16:48:39Z
Hi whirly, Thanks for the reply. You will find the code on pastebin which is quite exceptable as it has a linden checker did you miss this in my response to Lucia
my code for better readability and syntax checking I hope this helps: "https://pastebin.com/0UT6zCPq"
I would point out that paste bin is uniformly acceptable by most coding parties. However I have sent both you and lucia this build test project in world apologies Lucia the first couple i sent was not full perm. I have also attached code here
//(c)2018 Denise. Virtual Kitten
// if you use this code please leave it unchanged do not sell or make any product relying on this code.
float GetBoundaryUsingCastRay(string raytype, float width){
list ray=[];
if(raytype=="-y") { ray = llCastRay(llGetPos()+<-(width/2),0.0,0.0>,llGetPos() + <width/2, -50.0, 0.0>,[RC_MAX_HITS, 5]);
} else if(raytype=="-x") { ray = llCastRay(llGetPos()+<0.0,-(width/2),0.0>, llGetPos() + <-50.0, (width/2), 0.0>,[RC_MAX_HITS, 5]);
} else if(raytype=="x") { ray = llCastRay(llGetPos()+<0.0,-(width/2),0.0>, llGetPos() + <50.0,(width/2), 0.0>,[RC_MAX_HITS, 5]);
} else if(raytype=="y") { ray = llCastRay(llGetPos()+<-(width/2),0.0,0.0>, llGetPos() + <(width/2), 50.0, 0.0>,[RC_MAX_HITS, 5]);
} else return -1;
// We have a Ray
llOwnerSay((string)ray + " raytype = " + raytype);
vector mypos = llGetPos();
integer i=0;
float pos =566666;
integer position;
mypos = llGetPos();
do {
key lkID = llList2Key(ray, i);
vector pos = llList2Vector(ray,i+1);
// llOwnerSay("position " + (string)pos+ " i = " +(string)(i+1));
if(llSubStringIndex(raytype, "x")!=-1) {
if((integer)pos.x != (integer)mypos.x ) {
// llOwnerSay(">>position " + (string)pos+ " i = " +(string)(i+1));
position= i+1;
i = llGetListLength(ray) - 1;
};
} else if(llSubStringIndex(raytype, "y")!=-1) {
if((integer)pos.y != (integer)mypos.y ) {
// llOwnerSay(">>position " + (string)pos+ " i = " +(string)(i+1));
position= i+1;
i = llGetListLength(ray) - 1;
};
}
i+=2;
} while(i<=llGetListLength(ray) - 1);
vector collision_pos = llList2Vector(ray,position);
// llOwnerSay("Position on x" + (string)collision_pos.x);
if(llSubStringIndex(raytype, "-y")!=-1 ){ return (integer)llFabs((mypos.y - collision_pos.y));
} else if(llSubStringIndex(raytype, "-x")!=-1) { return (integer)llFabs((mypos.x-collision_pos.x));
} else if(llSubStringIndex(raytype, "x")!=-1) {return (integer)llFabs((collision_pos.x-mypos.x ));
} else if(llSubStringIndex(raytype, "y")!=-1) { return (integer)llFabs((collision_pos.y -mypos.y));
} else return -1;
}
default
{
state_entry()
{
llVolumeDetect(TRUE);
// get boundaries
float boundaryonposy = 0;//GetBoundaryUsingCastRay("y", 0);
float boundaryonnegy = 0;//GetBoundaryUsingCastRay("-y",0);
float boundaryonposx = GetBoundaryUsingCastRay("x",0); // ******** Only detect on x acess for a collision
float boundaryonnegx = 0;//GetBoundaryUsingCastRay("-x",0);
llOwnerSay(
"Boundary marker on +x is: "+(string)boundaryonposx +
" Boundary marker on -x is: "+(string)boundaryonnegx +
" \nBoundary marker on y is: "+(string)boundaryonposy +
" Boundary marker on -y is: "+(string)boundaryonnegy);
}
collision_start(integer num) // depends on state_entry llVolumeDetect(TRUE);
{
key p_collision =llDetectedKey(0);
llOwnerSay("Collided");
integer vBitType = llDetectedType(0);
if (!(vBitType & AGENT || vBitType & AGENT_BY_LEGACY_NAME)) {
integer l = llDetectedLinkNumber(0);
vector vAviPos = llDetectedPos(0);
vector vAviVel = llDetectedVel(0);
vector vObjPos = llList2Vector(llGetLinkPrimitiveParams(l,[PRIM_POSITION]),0);
vector vAviToObj = vObjPos - vAviPos;
vector vAviToObjNorm = llVecNorm(<vAviToObj.x, vAviToObj.y, 0.0>);
// Rotation vRotAxis = vAviToObjNorm *llEuler2Rot(<0, 0, PI_BY_TWO>);
}
}
touch_start(integer total_number)
{
llSay(0, "Touched.");
}
}VirtualKitten commented at 2018-08-12T17:42:33Z
I have sent you both this project to look at, It is quite simple and full perm
Thanks Denise
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-12T19:07:07Z
I forgot to say just reset the script on the green box to run it . Its got no frills to runny it . Let me know that you received it OK
Thanks Denise
sl-service-account
commented
6 years ago Mazidox Linden commented at 2018-08-16T18:05:17Z
Hi there VirtualKitten,
Could you please provide us with a minimal reproduction script contained in an object, along with other objects which the llCastRay() should hit (and at least one that it should but does not) as a coalesced object. To get a coalesced object, select all the relevant prims, right click the object, and Take it. Once you have done this, please send a copy of the object to Mazidox Linden.
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-18T10:23:15Z
Hi Mazidox, I have provided this to the other two people here and am happy to do same . I will need to find you in world which I have now achieved. I have sent you a full prim version for you to test in world . I hope this is ok and you received it I would be grateful you kindly have a look as love cast ray and its a brilliant addition to secondlife. It is called 'Full prim CastRay tester'
Thanks Denise x
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-20T17:19:20Z
Hi there also in addition something which is not documented on wiki llCastRay() returns 00000000-0000-0000-0000-000000000000 entries am I to assume this is Linden ground without a key as I thought everything had a UUID.
Hugs Denise
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-26T08:09:26Z
Can you tell me if you all got the same results as me ? Thank you
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-29T13:08:14Z
I would be grateful of an update on this bug. I have provided this linkset with code to Mazidox , Whirly Fizzle and Lucia Nightfire. Not one of these avatars have come back to me to inform me that this is an error in code and as such believe it now whole kindheartedly to be a bug. It is currently preventing me moving forward with my scripts which I have been writing and is starting to affect my income.
I understand that you are supposed to provide an answer by tomorrow. This matter has not been resolved and no work around has been given or no information in relation to the Linden Code being made to work properly to solve this fault.
Can you please provide an update and not just close this case?
sl-service-account
commented
6 years ago Beq Janus commented at 2018-08-30T18:19:57Z
Hi VirtualKitten
I asked Whirly to pass this to me.
As noted above a minimal script would greatly assist us in diagnosing what it is that you are seeing. As far as I can determine the llCastRay is working entirely as designed.
I extracted the inline calculation of start and end in to two vectors. This allowed me to then print those out at the end and position beacons to confirm the ray path for debugging.
In my photos I have placed two poles at the start and end and placed a "beam" between them.
The resulting output was
[10:35:39] Calculate distance to other items in sim: Ray from <18.84777, 99.31145, 3206.62800> to <68.84777, 99.31145, 3206.62800> [10:35:39] Calculate distance to other items in sim: result:019e405f-993a-644d-6c7d-37b4f12f9e40<20.255920, 99.311450, 3206.628000>54670738-e312-2e23-d1e7-cfdfbad52a6b<25.867690, 99.311450, 3206.628000>2 raytype = x
This is showing us that there were two collsions.
The first was with key 019e405f-993a-644d-6c7d-37b4f12f9e40 @ <20.255920, 99.311450, 3206.628000>
The second with key 54670738-e312-2e23-d1e7-cfdfbad52a6b @ <25.867690, 99.311450, 3206.628000>
The first block is at <21.81675, 100.28252, 3206.19507> and has size along X of 3.12168 we would expect the collision to occur at the X centre minus half the width.
21.81675-(3.12168/2) = 20.2559 which is as expected.
The same works for the second block <27.42853, 99.28506, 3206.19507>
27.42853-(3.12168/2) = 25.86769
Hope this helps.
Regards
Beq
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-31T16:37:38Z, updated at 2018-08-31T16:46:41Z
Hi Beq,
Well am unsure exactly what you tested I think you probably just tested as it is on the wiki page with works fine and i am in agreement with the fact that a beam in one of the co-ordinates works . The problem is that the ray can be widened to do a wider search area and then this fails . As shown in my documented information i am happy to send this to you in worked with full perms . The problem is it should have detected the green prim too ( three collisions) when widened and does not detect it in my tests it only detected two like your own test: (The ray is the light pink area)
It uses
float GetBoundaryUsingCastRay(string raytype, float width){ ** in my code this is done by placing a item in width field.
And called here with a width of six:
float boundaryonposx = GetBoundaryUsingCastRay("x",6);
As you can see from the blocks the pink see through area is the size of the ray from the first green block and is shown for illustration
Kindest regards
Denise
sl-service-account
commented
6 years ago VirtualKitten commented at 2018-08-31T17:54:02Z, updated at 2018-09-01T06:56:51Z
I am determining from your response which you kindly provided Beq. That you used my blocks and script given to you by Whirly . Thats great that it was passed to you . As you have already only detected two items in the ray
The first was with key 019e405f-993a-644d-6c7d-37b4f12f9e40 @ <20.255920, 99.311450, 3206.628000>
The second with key 54670738-e312-2e23-d1e7-cfdfbad52a6b @ <25.867690, 99.311450, 3206.628000>
Then you had exactly the same result as me as I expected three two red blocks and keys detected However the expected green block in the ray field was not detected on the sides of the ray. The pink being phantom would not be detected. Linden please shed a light on why these collisions with wide beams are not working please? I want to thank you all for your help :)
Kind Regards Denise
sl-service-account
commented
6 years ago Bugsly Linden commented at 2018-09-05T20:39:06Z, updated at 2018-09-05T20:40:50Z
Hey Virtual Kitten,
I dug into this and here is what I found. I used this simple script to diagnose to make sure there isn't a bug on our end and I'm not finding any errors with detection.
Script taken from http://wiki.secondlife.com/wiki/LlCastRay
integer filter;// default is 0
default
{
state_entry()
{
string ownerName = llKey2Name(llGetOwner());
llOwnerSay("Hello, " + ownerName + "!");
}
touch_start(integer total_number)
{
vector start = llGetPos();
vector end = start - <0.0, -200.0, 0.0>;
if ( filter > 8 )
filter = 0;
llOwnerSay("Filter " + (string)filter);
list results = llCastRay(start, end, [RC_REJECT_TYPES, filter, RC_MAX_HITS, 50] );
integer hitNum = 0;
// Handle error conditions here by checking llList2Integer(results, -1) >= 0
while (hitNum < llList2Integer(results, -1))
{
// Stride is 2 because we didn't request normals or link numbers
key uuid = llList2Key(results, 2*hitNum);
string name = "Land"; // if (uuid == NULL_KEY)
if (uuid != NULL_KEY)
name = llKey2Name(uuid);
llOwnerSay("Hit " + name + ".");
++hitNum;
}
++filter;
}
}
So I lined up 20 boxes the last two boxes are also a linked set. Detection is valid for all boxes. Also I tested this in each direction and also tested land detection. I took a screen shot of what I'm seeing and attached it, See below.
sl-service-account
commented
6 years ago Bugsly Linden commented at 2018-09-05T20:47:06Z
Also for your phantom issue not detecting take a look at this option:
| [ RC_DETECT_PHANTOM ] | 1 | [ integer detect_phantom ] | [ FALSE ] | Set to TRUE (or nonzero) to detect phantom AND volume detect objects. It is not possible to detect only phantom objects or only volume detect objects. If set to TRUE, phantom and volume detect objects will always be detected, even if RC_REJECT_NONPHYSICAL and RC_REJECT_PHYSICAL are set in RC_REJECT_TYPES. |
|---|
sl-service-account
commented
6 years ago Beq Janus commented at 2018-09-07T20:06:05Z
Hi Denise (@virtualkitten)
I am unclear where this assertion that you can widen the beam comes from, I can find no documentation or evidence that llCastRay has ever had any such capability. Below is the wiki page and there is no concept of beam width discussed there. I think that that is the root of the problem here, you are expecting a behaviour that is unsupported. If you can identify where this information came from that would be really useful.
If you look at your code against the documented behaviour:
ray = llCastRay(llGetPos()+<0.0,-(width/2),0.0>, llGetPos() + <-50.0, (width/2), 0.0>,[RC_MAX_HITS, 5]);
you are setting the first vector (start) to be the prim location, with the Y coord offset by minus half the "width" parameter that you send.
you are setting the second vector (end) to be the prim location + 50m along X, and offset to plus half of the "width"
What that will do, is project a beam diagonally from the bottom right to the top left (when viewed from above) it would not, therefore, collide with objects that were not on this specific diagonal path).
This is illustrated by the following image. The yellow highlight is where the beam would be cast assuming that width was set to correspond with the pink/red semi-transparent box.
Regards
Beq
sl-service-account
commented
5 years ago Whirly Fizzle commented at 2018-10-14T13:06:05Z
@VirtualKitten I reopened this issue & set it to "Needs more info" so you can reply to Beq.
sl-service-account
commented
5 years ago VirtualKitten commented at 2018-10-15T16:40:19Z, updated at 2018-10-15T17:23:15Z
Thanks very much Whirly :)
Firstly in reply to Beq the two vectors acted together as a bounding box or could do but I have been informed by NCI Scripters a fabulous group for scripting that it is for diagonal beams like a laser and the WIKI page has been edited by a member of this group to remove the confusion from the page stating it was a box . You can review this edit on history of wiki page.
This is now much clearer I am unsure why my group which I am a member of had to do this and not Linden?
Beq I have already explained that using multiple beams to search for a collision in a link set item is redundancy as if this was not a wide beam which it would cause more script code to obtain the same result as a bounding box could do in one hit instead of multiple CastRay requests. If it accommodated both ways of operation this would be brilliant A default could be the same as it did before to remove possible rewrite for existing code.
Further more, I am now finding CastRay() returns 0 information sometimes at a higher height ray pointing down I provide an image of this below
// code placeholder
list ray = llCastRay(llGetPos(), llGetPos() + <5, 0, -100.0>,[RC_MAX_HITS|RC_GET_ROOT_KEY, 5]);//
if(debug) llOwnerSay(llDumpList2String(ray,"|"));
if(llList2Integer(ray, -1) < 0) {llOwnerSay("Ray Cast failed."); return;}
The output from this from my code debugger is as follows:
[09:06] Strobe: Switched on. [09:06] Floor Worx: 0 [09:06] Floor Worx: lkID calculation1 Got into Ground<0.00000, 0.00000, 0.00000>Key <0.00000, 0.00000, 0.00000> [09:06] Floor Worx: Ground:<0.00000, 0.00000, 0.00000>, Floor:<0.00000, 0.00000, 0.00000> [09:06] Floor Worx: Ground:<0.00000, 0.00000, 0.00000> [09:06] Floor Worx: h: 24.959710, Angle : 142.765400, Cos0.448074, Sin 0.893997, tan 1.995200 [09:06] Floor Worx: floor thickness 0.000000, x: 37.234650, y:52.765350, y2: 90.000000, Ground:<0.00000, 0.00000, 0.00000> [09:06] Floor Worx: Dist: -49.817930, extra 0.448074 [09:06] Floor Worx: Before Addition, localpos<-216.60470, -162.83200, -24.94971> My pos <216.60470, 162.83200, 24.94971>onfloor 0Floor: <0.00000, 0.00000, 0.00000> [09:06] Floor Worx: localpos<49.81793, -24.04971, 0.00000> My pos <216.60470, 162.83200, 24.94971>onfloor 0Has object above ground: 1 [09:06] Floor Worx: localPos: <49.81793, -24.04971, 0.00000> [09:06] Floor Worx: localRot: <0.50000, 0.50000, 0.50000, 0.50000>
As you can see this has the result of stalling my calculations as no ray is detected I am finding this happens at 24.94971 m high from ground at http://maps.secondlife.com/secondlife/Alethia%20Island/218/161/22
I am not aware why this error in CastRay occurs as everything seems to work correctly at a lower height and no error is returned from the code as a fault .
The debug report should be as follows, with the ray detecting a hit which it does at a lower height.
The current other solution for this BUG-225634 doesn't allow for the item to be dropped to floor and renders the whole object to fall to ground with no separation from root to just drop the linked prim the script the item is in.
llSetStatus(STATUS_BLOCK_GRAB_OBJECT, TRUE); llSetStatus(STATUS_PHYSICS, TRUE); llSetStatus( STATUS_ROTATE_X | STATUS_ROTATE_Y , TRUE); llSleep(1.); llSetStatus(STATUS_PHYSICS, FALSE); llSetStatus( STATUS_BLOCK_GRAB_OBJECT, FALSE);
This is creating a massive amount of trig for me in 3d which is getting very complicated. As although I have the unit dropping item to floor it doesn't work when its rotated due to the lack of processing for orientation which needs to be detected as an offset in x and y or in this case y and z as there is no re-orientation system on mesh import to correct rogue orientation imports, which seem to rearrange the axis randomly on import which confuses every object in LSL.
I really hope you can correct this CastRay as is a great addition so is the new status commands and we all really need good working commands in LSL to write fantastic items. As i have expressed on a forum I wish you would look at all of my requests as they are all there to try to improve LSL.
I have had much support from NCI Scripters who are fantastic helpful and provide good support to scriptwriters of all aptitudes:) They should be commended.
Kind Regards
Denise
sl-service-account
commented
5 years ago VirtualKitten commented at 2018-10-27T08:25:28Z
I note that in another thread this llSetStatus( STATUS_BLOCK_GRAB_OBJECT, FALSE); and true is only intended the way to work as it does and Linden say its not expected to be change . This puts us back to the functionalist of CastRay
sl-service-account
commented
5 years ago VirtualKitten commented at 2018-12-08T15:50:50Z, updated at 2018-12-08T16:36:15Z
I am noticing llCastRay( whiles used as
list ray = llCastRay(llGetPos(), llGetPos() + <5, 0, -100.0>,[RC_MAX_HITS|RC_GET_ROOT_KEY, 10]);// if(debug) llOwnerSay(llDumpList2String(ray,"|"));
Is not filling in a complete Ray list instead returns 0
The location in world is at http://maps.secondlife.com/secondlife/Frumos/207/216/23
As you can see there is a floor here which is not detected at all . Can you please explain why it is not possible to Cast a Ray here
The setting is in Dream Night Club by PhoenixDeMarco Delvalle (phoenixdemarco.delvalle) I[3839df43-691d-40c0-93f3-5502de7a36a2] MESH! It has a floor SHX-XDF-001 by Saii Hallard w[9461d333-7c39-4c02-aeaf-9f44943b125e] which it fails to detect which is MESH!
Thanks
Denise X
I COULD NOT REPLY TO BEQ AS SOME IDIOT CLOSED THIS CASE BUT THE BOUNDING BOX IS CLEAR IN THE COMMAND SHE WAS USING LLCASTRAY()
I DON'T KNOW WHY LINDEN CLOSES CASES WHICH ARE NOT ANSWERED OR FINISHED ITS A WASTE OF TIME USING THIS AS YOU CANT EVER REPLY
What just happened?
I was only using float boundaryonposx = GetBoundaryUsingCastRay("x",1); to enable x axis and the 1 should have incereased the width of beam from the om5 size to -.5 +.5 from llGetPos() and 50 meters in front. The code returned one hit in its target area: 62b13237-a387-9f64-1ca2-61360a6c3843<127.494900, 151.134100, 1941.344000>1 raytype = x I expected two to be found
When i used I was only using float boundaryonposx = GetBoundaryUsingCastRay("x",6); to enable x axis and the 6 should have increased the width of beam from the om5 size to -3 +3 from llGetPos() and 50 meters in front. The code returned no hits in its target area returning no item in list with no key or error
expected two to be found.
What were you doing when it happened?
I wrote code to check collision with prims . The Green prim is linked to red prim and attempts to identify wooden prims. The Code I used was limited to test on x axis for testing when i noticed this fault that the ray was not returning hits when there was a double item. Now this is not happening all the time as my code else where is functional without setting a wide bounding box
What were you expecting to happen instead?
I expected CastRay( to provide all collisions There should have been two
Other information
Attachments
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-225253 | | Summary | llCastRay() does not seem able to always identify all collision | | Type | Bug | | Priority | Unset | | Status | Closed | | Resolution | Expected Behavior | | Reporter | VirtualKitten (virtualkitten) | | Created at | 2018-08-10T16:10:47Z | | Updated at | 2018-12-11T22:11:51Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2018-08-10T18:06:54.351-0500', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Simulator', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'I wrote code to check collision with prims . The Green prim is linked to red prim and attempts to identify wooden prims. The Code I used was limited to test on x axis for testing when i noticed this fault that the ray was not returning hits when there was a double item. Now this is not happening all the time as my code else where is functional without setting a wide bounding box\r\n\r\nfloat GetBoundaryUsingCastRay(string raytype, float width){\r\n list ray=[];\r\n if(raytype=="-y") { ray = llCastRay(llGetPos()+<-(width/2),0.0,0.0>,llGetPos() +