0008402: [SCRIPT] OS llCastRay returns values in a different order than SL

(0033463)
BillBlight (developer)
2018-11-10 14:00
edited on: 2018-11-10 14:04

according to the SL wiki for llCastRay ..

Each stride consists of two mandatory values {key uuid, vector position} and possibly some optional values {integer link_number, vector normal}

We are returning what they say they return and in the order they seem to imply ..

If they have changed it, and not told anyone, then hard to keep up with it ..

Changing this order from the previously implied order that has been used, could break an enormous number of scripts in OS.

(0033464)
djphil (reporter)
2018-11-10 14:26

Well if SL has changed (probably there is a good reason) it has also had to break a lot of existing scripts ... and yet they still changed, it does not seem to have been a problem ... But if OS does one way and SL another way, so we have a compatibility problem ...

(0033465)
BillBlight (developer)
2018-11-10 14:33

If this does get "fixed" is it ok to send everyone that has the broken script to you to get it fixed? :P

(0033466)
mewtwo0641 (reporter)
2018-11-11 03:51

On one hand this is an LL function and I would say that it should work on OS as it does on SL... On the other hand I reaaaaaaaally hate having to fix the aftermath of the result of fixing a function that breaks a ton of scripts because they depended on the "wrongness" of the result and accommodated for it.

That said, I did write a little function that translates the wrong result order into the SL correct version that can be used in place of llCastRay in scripts that depend on the correct order (i.e. Scripts ported over from SL).

list llCastRayFixed(vector start, vector end, list params)
{
    list result = llCastRay(start, end, params);

    integer length = llGetListLength(result);

    if(length > 0)
    {
        integer i = 0;
        list temp = [];

        for(i = 0; i < length; i = i + 4)
        {
            temp +=
            [
                llList2Key(result, i),
                llList2Integer(result, i + 2),
                (vector)llList2String(result, i + 1),
                llList2Integer(result, i + 3)
            ];
        }

        return temp;
    }

    else
        return [];
}

I couldn't actually remember if llCastRay is capable of returning more than one hit result at a time... So I made this version too that only returns the first result.

list llCastRayFixed(vector start, vector end, list params)
{
    list result = llCastRay(start, end, params);

    if(llGetListLength(result) > 0)
    {
        return
        [
            llList2Key(result, 0),
            llList2Integer(result, 2),
            (vector)llList2String(result, 1),
            llList2Integer(result, 3)
        ];
    }

    else
        return [];
}

(0033467)
UbitUmarov (administrator)
2018-11-11 06:50

llCastray can return more hits with option RC_MAX_HITS, default is 1.

I Can't tell if SL changed on not, sure all that did work on this function did testing back in the day, so my guess is that it did. And this is not only case now.

So I am stuck on that dilemma mewtwo0641 stated.
(and no, more config options are not a answer)

(0033468)
tampa (reporter)
2018-11-11 07:00

From a scripting perspective of someone referencing the SL lsl wiki it would make sense to change in accordance with it. Relegate the old way to ossl, that would be the easiest to change for those using old scripts, after all it's a simple find-replace for the function name. Beyond that, like Ubit says, just adding a "use old or new way" as config line is just going to cause more trouble.

Issue History
Date Modified	Username	Field	Change
2018-11-04 10:48	djphil	New Issue
2018-11-04 15:52	djphil	Additional Information Updated	View Revisions
2018-11-10 13:43	UbitUmarov	Note Added: 0033462
2018-11-10 13:52	UbitUmarov	Note Deleted: 0033462
2018-11-10 14:00	BillBlight	Note Added: 0033463
2018-11-10 14:01	BillBlight	Note Edited: 0033463	View Revisions
2018-11-10 14:02	BillBlight	Note Edited: 0033463	View Revisions
2018-11-10 14:04	BillBlight	Note Edited: 0033463	View Revisions
2018-11-10 14:26	djphil	Note Added: 0033464
2018-11-10 14:33	BillBlight	Note Added: 0033465
2018-11-11 03:51	mewtwo0641	Note Added: 0033466
2018-11-11 06:50	UbitUmarov	Note Added: 0033467
2018-11-11 07:00	tampa	Note Added: 0033468

Notes
(0033463) BillBlight (developer) 2018-11-10 14:00 edited on: 2018-11-10 14:04	according to the SL wiki for llCastRay .. Each stride consists of two mandatory values {key uuid, vector position} and possibly some optional values {integer link_number, vector normal} We are returning what they say they return and in the order they seem to imply .. If they have changed it, and not told anyone, then hard to keep up with it .. Changing this order from the previously implied order that has been used, could break an enormous number of scripts in OS.

(0033464) djphil (reporter) 2018-11-10 14:26	Well if SL has changed (probably there is a good reason) it has also had to break a lot of existing scripts ... and yet they still changed, it does not seem to have been a problem ... But if OS does one way and SL another way, so we have a compatibility problem ...

(0033465) BillBlight (developer) 2018-11-10 14:33	If this does get "fixed" is it ok to send everyone that has the broken script to you to get it fixed? :P

(0033466) mewtwo0641 (reporter) 2018-11-11 03:51	On one hand this is an LL function and I would say that it should work on OS as it does on SL... On the other hand I reaaaaaaaally hate having to fix the aftermath of the result of fixing a function that breaks a ton of scripts because they depended on the "wrongness" of the result and accommodated for it. That said, I did write a little function that translates the wrong result order into the SL correct version that can be used in place of llCastRay in scripts that depend on the correct order (i.e. Scripts ported over from SL). list llCastRayFixed(vector start, vector end, list params) { list result = llCastRay(start, end, params); integer length = llGetListLength(result); if(length > 0) { integer i = 0; list temp = []; for(i = 0; i < length; i = i + 4) { temp += [ llList2Key(result, i), llList2Integer(result, i + 2), (vector)llList2String(result, i + 1), llList2Integer(result, i + 3) ]; } return temp; } else return []; } I couldn't actually remember if llCastRay is capable of returning more than one hit result at a time... So I made this version too that only returns the first result. list llCastRayFixed(vector start, vector end, list params) { list result = llCastRay(start, end, params); if(llGetListLength(result) > 0) { return [ llList2Key(result, 0), llList2Integer(result, 2), (vector)llList2String(result, 1), llList2Integer(result, 3) ]; } else return []; }

(0033467) UbitUmarov (administrator) 2018-11-11 06:50	llCastray can return more hits with option RC_MAX_HITS, default is 1. I Can't tell if SL changed on not, sure all that did work on this function did testing back in the day, so my guess is that it did. And this is not only case now. So I am stuck on that dilemma mewtwo0641 stated. (and no, more config options are not a answer)

(0033468) tampa (reporter) 2018-11-11 07:00	From a scripting perspective of someone referencing the SL lsl wiki it would make sense to change in accordance with it. Relegate the old way to ossl, that would be the easiest to change for those using old scripts, after all it's a simple find-replace for the function name. Beyond that, like Ubit says, just adding a "use old or new way" as config line is just going to cause more trouble.

Relationships