Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008402opensim[REGION] Scripting Enginepublic2018-11-04 10:482018-11-11 07:00
Assigned To 
PlatformPCOperating SystemWindowsOperating System Version10
Product Version0.9.0.1 
Target VersionFixed in Version 
Summary0008402: [SCRIPT] OS llCastRay returns values in a different order than SL
DescriptionThat cause script compatibility problem ...

    touch_start(integer n)
        list data = llCastRay(llGetPos(),
            llGetPos() + ((<0.0, 0.0, 5.0>) * llGetRot()),
        llOwnerSay("llGetListLength " + (string)llGetListLength(data));
        llOwnerSay("llList2CSV " + llList2CSV(data));

[23:21] Object: llGetListLength 4
[23:21] Object: llList2CSV f4c55d98-079b-4140-bc69-dca1f92f9a64, 0, <132.6429, 44.04966, 21.87577>, 1

[23:24] Object: llGetListLength 4
[23:24] Object: llList2CSV f4c55d98-079b-4140-bc69-dca1f92f9a64, <132.6429, 44.04966, 21.87577>, 0, 1
Additional InformationSame result with UseLlCastRayV3 = false or true
Tested with XEngine only ...
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineubODE
Script Engine
Environment.NET / Windows64
Mono VersionNone
Attached Files

- Relationships

-  Notes
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.

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 ...
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
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;
        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)
            llList2Key(result, 0),
            llList2Integer(result, 2),
            (vector)llList2String(result, 1),
            llList2Integer(result, 3)
        return [];
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)
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

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker