Proposal for a new OSSL function

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal for a new OSSL function

Chris M
Hello all,

I have a proposal for a new OSSL function that could possibly prove
useful: osGetObjectNameDetails()

I would have sent this to the opensim-dev mailing list but I'm unsure
now of where this is located and how to sign up for that list since the
old mailing list locations are now gone. Can someone please point me in
the right direction? :)

This proposal has also been posted at
http://opensimulator.org/wiki/OSSL_Proposals

Thank you in advance for the consideration!

----------
Function:
----------

list osGetObjectNameDetails(list names, list params);
list osGetObjectNameDetails(list names, float range, list params);

-------------
Description:
-------------

Would work similarly to llGetObjectDetails() but has the advantage of
specifying for an object's name (or list of names) instead of by key. If
more than one name match is found then the return list will have those
matches (or groups of matches if more than one parameter is supplied)
sorted in order from nearest to furthest from the prim calling
osGetObjectNameDetails. By default this would scan the entire region but
optionally a range can be specified to only search within a certain
radius similar to llSensor().

This has potential, for most single item situations at least, eliminate
the need for an llSensor() call and also eliminate the need for a sensor
event thus reducing code complexity and make for very easy and very
quick data collection to be further processed upon.

---------
Example:
---------

list objDetails;

default
{
     state_entry()
     {
         //Example 1:
         //For this example assume this prim is located at <128, 125,
30> and we have two objects named 'Chair'.
         //'Chair' #1 is located at <128, 128, 30> and owned by avatar
UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
         //'Chair' #2 is located at <128, 130, 30> and owned by avatar
UUID 1c612fb2-748c-4a1a-ad57-27f488210c06

         objDetails = osGetObjectNameDetails(["Chair"], OBJECT_NAME |
OBJECT_POS | OBJECT_OWNER);

         llOwnerSay(llDumpList2String(objDetails, ", "));

         //llOwnerSay() output should be: Chair, <128, 128, 30>,
5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair, <128, 130, 30>,
1c612fb2-748c-4a1a-ad57-27f488210c06

//------------------------------------------------------------------------------------------------------------------------------------------------------------------

         //Example 2:
         //For this example assume everything stays the same as in
Example 1 except that we're specifying a range.

         objDetails = osGetObjectNameDetails(["Chair"], 5.0, OBJECT_NAME
| OBJECT_POS | OBJECT_OWNER);

         llOwnerSay(llDumpList2String(objDetails, ", "));

         //llOwnerSay() output should be: Chair, <128, 128, 30>,
5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a

//------------------------------------------------------------------------------------------------------------------------------------------------------------------

         //Example 3:
         //For this example assume this prim is located at <128, 125,
30> and we have two objects: 'Chair 1' and 'Chair 2'.
         //'Chair 1' is located at <128, 128, 30> and owned by avatar
UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
         //'Chair 2' is located at <128, 130, 30> and owned by avatar
UUID 1c612fb2-748c-4a1a-ad57-27f488210c06

         objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"],
OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

         llOwnerSay(llDumpList2String(objDetails, ", "));

         //llOwnerSay() output should be: Chair 1, <128, 128, 30>,
5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair 2, <128, 130, 30>,
1c612fb2-748c-4a1a-ad57-27f488210c06

//------------------------------------------------------------------------------------------------------------------------------------------------------------------

         //Example 4:
         //For this example assume everything stays the same as in
Example 3 except that we're specifying a range.

         objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"],
5.0, OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

         llOwnerSay(llDumpList2String(objDetails, ", "));

         //llOwnerSay() output should be: Chair 1, <128, 128, 30>,
5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
     }
}

--
OpenSim: 10 Region Standalone on 0.8.1 Dev
Physics: Open Dynamics Engine
OS: Windows 7 (x64)
CPU: AMD FX 8320 8-Core 3.5 GHz
Memory: 16 GB DDR3
Database: MySQL 5.1.63 (x64)

_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for a new OSSL function

R.Gunther
One thing that llGetObject detail is missing is to get the prim size. so
if this command get add. i hope the add the object size too.


On 2015-03-13 20:00, Chris wrote:

> Hello all,
>
> I have a proposal for a new OSSL function that could possibly prove
> useful: osGetObjectNameDetails()
>
> I would have sent this to the opensim-dev mailing list but I'm unsure
> now of where this is located and how to sign up for that list since
> the old mailing list locations are now gone. Can someone please point
> me in the right direction? :)
>
> This proposal has also been posted at
> http://opensimulator.org/wiki/OSSL_Proposals
>
> Thank you in advance for the consideration!
>
> ----------
> Function:
> ----------
>
> list osGetObjectNameDetails(list names, list params);
> list osGetObjectNameDetails(list names, float range, list params);
>
> -------------
> Description:
> -------------
>
> Would work similarly to llGetObjectDetails() but has the advantage of
> specifying for an object's name (or list of names) instead of by key.
> If more than one name match is found then the return list will have
> those matches (or groups of matches if more than one parameter is
> supplied) sorted in order from nearest to furthest from the prim
> calling osGetObjectNameDetails. By default this would scan the entire
> region but optionally a range can be specified to only search within a
> certain radius similar to llSensor().
>
> This has potential, for most single item situations at least,
> eliminate the need for an llSensor() call and also eliminate the need
> for a sensor event thus reducing code complexity and make for very
> easy and very quick data collection to be further processed upon.
>
> ---------
> Example:
> ---------
>
> list objDetails;
>
> default
> {
>     state_entry()
>     {
>         //Example 1:
>         //For this example assume this prim is located at <128, 125,
> 30> and we have two objects named 'Chair'.
>         //'Chair' #1 is located at <128, 128, 30> and owned by avatar
> UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
>         //'Chair' #2 is located at <128, 130, 30> and owned by avatar
> UUID 1c612fb2-748c-4a1a-ad57-27f488210c06
>
>         objDetails = osGetObjectNameDetails(["Chair"], OBJECT_NAME |
> OBJECT_POS | OBJECT_OWNER);
>
>         llOwnerSay(llDumpList2String(objDetails, ", "));
>
>         //llOwnerSay() output should be: Chair, <128, 128, 30>,
> 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair, <128, 130, 30>,
> 1c612fb2-748c-4a1a-ad57-27f488210c06
>
> //------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>
>         //Example 2:
>         //For this example assume everything stays the same as in
> Example 1 except that we're specifying a range.
>
>         objDetails = osGetObjectNameDetails(["Chair"], 5.0,
> OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);
>
>         llOwnerSay(llDumpList2String(objDetails, ", "));
>
>         //llOwnerSay() output should be: Chair, <128, 128, 30>,
> 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
>
> //------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>
>         //Example 3:
>         //For this example assume this prim is located at <128, 125,
> 30> and we have two objects: 'Chair 1' and 'Chair 2'.
>         //'Chair 1' is located at <128, 128, 30> and owned by avatar
> UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
>         //'Chair 2' is located at <128, 130, 30> and owned by avatar
> UUID 1c612fb2-748c-4a1a-ad57-27f488210c06
>
>         objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"],
> OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);
>
>         llOwnerSay(llDumpList2String(objDetails, ", "));
>
>         //llOwnerSay() output should be: Chair 1, <128, 128, 30>,
> 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair 2, <128, 130, 30>,
> 1c612fb2-748c-4a1a-ad57-27f488210c06
>
> //------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>
>         //Example 4:
>         //For this example assume everything stays the same as in
> Example 3 except that we're specifying a range.
>
>         objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"],
> 5.0, OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);
>
>         llOwnerSay(llDumpList2String(objDetails, ", "));
>
>         //llOwnerSay() output should be: Chair 1, <128, 128, 30>,
> 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
>     }
> }
>

_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for a new OSSL function

Chris M
Getting an object's size would be a really nice addition; but going by
how llGetScale() functions I believe it would be limited to getting just
the root prim's size rather than overall size if I'm thinking about this
correctly.

On 3/13/2015 2:03 PM, R.Gunther wrote:

> One thing that llGetObject detail is missing is to get the prim size.
> so if this command get add. i hope the add the object size too.
>
>
> On 2015-03-13 20:00, Chris wrote:
>> Hello all,
>>
>> I have a proposal for a new OSSL function that could possibly prove
>> useful: osGetObjectNameDetails()
>>
>> I would have sent this to the opensim-dev mailing list but I'm unsure
>> now of where this is located and how to sign up for that list since
>> the old mailing list locations are now gone. Can someone please point
>> me in the right direction? :)
>>
>> This proposal has also been posted at
>> http://opensimulator.org/wiki/OSSL_Proposals
>>
>> Thank you in advance for the consideration!
>>
>> ----------
>> Function:
>> ----------
>>
>> list osGetObjectNameDetails(list names, list params);
>> list osGetObjectNameDetails(list names, float range, list params);
>>
>> -------------
>> Description:
>> -------------
>>
>> Would work similarly to llGetObjectDetails() but has the advantage of
>> specifying for an object's name (or list of names) instead of by key.
>> If more than one name match is found then the return list will have
>> those matches (or groups of matches if more than one parameter is
>> supplied) sorted in order from nearest to furthest from the prim
>> calling osGetObjectNameDetails. By default this would scan the entire
>> region but optionally a range can be specified to only search within
>> a certain radius similar to llSensor().
>>
>> This has potential, for most single item situations at least,
>> eliminate the need for an llSensor() call and also eliminate the need
>> for a sensor event thus reducing code complexity and make for very
>> easy and very quick data collection to be further processed upon.
>>
>> ---------
>> Example:
>> ---------
>>
>> list objDetails;
>>
>> default
>> {
>>     state_entry()
>>     {
>>         //Example 1:
>>         //For this example assume this prim is located at <128, 125,
>> 30> and we have two objects named 'Chair'.
>>         //'Chair' #1 is located at <128, 128, 30> and owned by avatar
>> UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
>>         //'Chair' #2 is located at <128, 130, 30> and owned by avatar
>> UUID 1c612fb2-748c-4a1a-ad57-27f488210c06
>>
>>         objDetails = osGetObjectNameDetails(["Chair"], OBJECT_NAME |
>> OBJECT_POS | OBJECT_OWNER);
>>
>>         llOwnerSay(llDumpList2String(objDetails, ", "));
>>
>>         //llOwnerSay() output should be: Chair, <128, 128, 30>,
>> 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair, <128, 130, 30>,
>> 1c612fb2-748c-4a1a-ad57-27f488210c06
>>
>> //------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>>         //Example 2:
>>         //For this example assume everything stays the same as in
>> Example 1 except that we're specifying a range.
>>
>>         objDetails = osGetObjectNameDetails(["Chair"], 5.0,
>> OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);
>>
>>         llOwnerSay(llDumpList2String(objDetails, ", "));
>>
>>         //llOwnerSay() output should be: Chair, <128, 128, 30>,
>> 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
>>
>> //------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>>         //Example 3:
>>         //For this example assume this prim is located at <128, 125,
>> 30> and we have two objects: 'Chair 1' and 'Chair 2'.
>>         //'Chair 1' is located at <128, 128, 30> and owned by avatar
>> UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
>>         //'Chair 2' is located at <128, 130, 30> and owned by avatar
>> UUID 1c612fb2-748c-4a1a-ad57-27f488210c06
>>
>>         objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"],
>> OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);
>>
>>         llOwnerSay(llDumpList2String(objDetails, ", "));
>>
>>         //llOwnerSay() output should be: Chair 1, <128, 128, 30>,
>> 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair 2, <128, 130, 30>,
>> 1c612fb2-748c-4a1a-ad57-27f488210c06
>>
>> //------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>>         //Example 4:
>>         //For this example assume everything stays the same as in
>> Example 3 except that we're specifying a range.
>>
>>         objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"],
>> 5.0, OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);
>>
>>         llOwnerSay(llDumpList2String(objDetails, ", "));
>>
>>         //llOwnerSay() output should be: Chair 1, <128, 128, 30>,
>> 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
>>     }
>> }
>>
>
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users


--
OpenSim: 10 Region Standalone on 0.7.6 Dev
Physics: Open Dynamics Engine
OS: Windows 7 (x64)
CPU: AMD FX 8320 8-Core 3.5 GHz
Memory: 16 GB DDR3
Database: MySQL 5.1.63 (x64)

_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for a new OSSL function

Dahlia Trimble
Some initial thoughts

Why not a function that returns a uuid for a name? Actually this could be done with a sensor now. No need to duplicate llGetObjectDetails functionality, just call it once you get the uuid.

Such a function would need to scan every object in the region for a name match, similar to how a sensor would do it. This can put a lot of load on the simulator and could tie up internal data structures until the scan completes, possibly preventing other more critical code from executing. If such functionality was added, it would likely need to be throttled to prevent abuse and/or use events to return results similar to sensors now. Perhaps another approach might be to get rid of the sensor distance limit, or relax it in favor of some other penalty such as a script delay if a further distance is requested. This would, however, deviate from the SL API documented behavior and as such would probably need to go into a os* function.

Sorry, I don't accept the argument that it reduces code complexity, it only moves the complexity into the simulator code. Script event patterns are quite common and well understood by the community and have the advantage that, when used properly in place of other patterns (loops, etc), help the simulator run better.

On Fri, Mar 13, 2015 at 12:10 PM, Chris <[hidden email]> wrote:
Getting an object's size would be a really nice addition; but going by how llGetScale() functions I believe it would be limited to getting just the root prim's size rather than overall size if I'm thinking about this correctly.


On 3/13/2015 2:03 PM, R.Gunther wrote:
One thing that llGetObject detail is missing is to get the prim size. so if this command get add. i hope the add the object size too.


On 2015-03-13 20:00, Chris wrote:
Hello all,

I have a proposal for a new OSSL function that could possibly prove useful: osGetObjectNameDetails()

I would have sent this to the opensim-dev mailing list but I'm unsure now of where this is located and how to sign up for that list since the old mailing list locations are now gone. Can someone please point me in the right direction? :)

This proposal has also been posted at http://opensimulator.org/wiki/OSSL_Proposals

Thank you in advance for the consideration!

----------
Function:
----------

list osGetObjectNameDetails(list names, list params);
list osGetObjectNameDetails(list names, float range, list params);

-------------
Description:
-------------

Would work similarly to llGetObjectDetails() but has the advantage of specifying for an object's name (or list of names) instead of by key. If more than one name match is found then the return list will have those matches (or groups of matches if more than one parameter is supplied) sorted in order from nearest to furthest from the prim calling osGetObjectNameDetails. By default this would scan the entire region but optionally a range can be specified to only search within a certain radius similar to llSensor().

This has potential, for most single item situations at least, eliminate the need for an llSensor() call and also eliminate the need for a sensor event thus reducing code complexity and make for very easy and very quick data collection to be further processed upon.

---------
Example:
---------

list objDetails;

default
{
    state_entry()
    {
        //Example 1:
        //For this example assume this prim is located at <128, 125, 30> and we have two objects named 'Chair'.
        //'Chair' #1 is located at <128, 128, 30> and owned by avatar UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
        //'Chair' #2 is located at <128, 130, 30> and owned by avatar UUID 1c612fb2-748c-4a1a-ad57-27f488210c06

        objDetails = osGetObjectNameDetails(["Chair"], OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

        llOwnerSay(llDumpList2String(objDetails, ", "));

        //llOwnerSay() output should be: Chair, <128, 128, 30>, 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair, <128, 130, 30>, 1c612fb2-748c-4a1a-ad57-27f488210c06

//------------------------------------------------------------------------------------------------------------------------------------------------------------------

        //Example 2:
        //For this example assume everything stays the same as in Example 1 except that we're specifying a range.

        objDetails = osGetObjectNameDetails(["Chair"], 5.0, OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

        llOwnerSay(llDumpList2String(objDetails, ", "));

        //llOwnerSay() output should be: Chair, <128, 128, 30>, 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a

//------------------------------------------------------------------------------------------------------------------------------------------------------------------

        //Example 3:
        //For this example assume this prim is located at <128, 125, 30> and we have two objects: 'Chair 1' and 'Chair 2'.
        //'Chair 1' is located at <128, 128, 30> and owned by avatar UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
        //'Chair 2' is located at <128, 130, 30> and owned by avatar UUID 1c612fb2-748c-4a1a-ad57-27f488210c06

        objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"], OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

        llOwnerSay(llDumpList2String(objDetails, ", "));

        //llOwnerSay() output should be: Chair 1, <128, 128, 30>, 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair 2, <128, 130, 30>, 1c612fb2-748c-4a1a-ad57-27f488210c06

//------------------------------------------------------------------------------------------------------------------------------------------------------------------

        //Example 4:
        //For this example assume everything stays the same as in Example 3 except that we're specifying a range.

        objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"], 5.0, OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

        llOwnerSay(llDumpList2String(objDetails, ", "));

        //llOwnerSay() output should be: Chair 1, <128, 128, 30>, 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
    }
}


_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users


--
OpenSim: 10 Region Standalone on 0.7.6 Dev

Physics: Open Dynamics Engine
OS: Windows 7 (x64)
CPU: AMD FX 8320 8-Core 3.5 GHz
Memory: 16 GB DDR3
Database: MySQL 5.1.63 (x64)

_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users


_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for a new OSSL function

R.Gunther
I expected the OSSL works also with UUID you get from sensor. llGetObject details works very good for me, except am misisng the object size.
I have a workaround for that. But a command that need to scan the whole sim to get something. I agree with dahlia, bad idea.

On 2015-03-13 21:12, Dahlia Trimble wrote:
Some initial thoughts

Why not a function that returns a uuid for a name? Actually this could be done with a sensor now. No need to duplicate llGetObjectDetails functionality, just call it once you get the uuid.

Such a function would need to scan every object in the region for a name match, similar to how a sensor would do it. This can put a lot of load on the simulator and could tie up internal data structures until the scan completes, possibly preventing other more critical code from executing. If such functionality was added, it would likely need to be throttled to prevent abuse and/or use events to return results similar to sensors now. Perhaps another approach might be to get rid of the sensor distance limit, or relax it in favor of some other penalty such as a script delay if a further distance is requested. This would, however, deviate from the SL API documented behavior and as such would probably need to go into a os* function.

Sorry, I don't accept the argument that it reduces code complexity, it only moves the complexity into the simulator code. Script event patterns are quite common and well understood by the community and have the advantage that, when used properly in place of other patterns (loops, etc), help the simulator run better.

On Fri, Mar 13, 2015 at 12:10 PM, Chris <[hidden email]> wrote:
Getting an object's size would be a really nice addition; but going by how llGetScale() functions I believe it would be limited to getting just the root prim's size rather than overall size if I'm thinking about this correctly.


On 3/13/2015 2:03 PM, R.Gunther wrote:
One thing that llGetObject detail is missing is to get the prim size. so if this command get add. i hope the add the object size too.


On 2015-03-13 20:00, Chris wrote:
Hello all,

I have a proposal for a new OSSL function that could possibly prove useful: osGetObjectNameDetails()

I would have sent this to the opensim-dev mailing list but I'm unsure now of where this is located and how to sign up for that list since the old mailing list locations are now gone. Can someone please point me in the right direction? :)

This proposal has also been posted at http://opensimulator.org/wiki/OSSL_Proposals

Thank you in advance for the consideration!

----------
Function:
----------

list osGetObjectNameDetails(list names, list params);
list osGetObjectNameDetails(list names, float range, list params);

-------------
Description:
-------------

Would work similarly to llGetObjectDetails() but has the advantage of specifying for an object's name (or list of names) instead of by key. If more than one name match is found then the return list will have those matches (or groups of matches if more than one parameter is supplied) sorted in order from nearest to furthest from the prim calling osGetObjectNameDetails. By default this would scan the entire region but optionally a range can be specified to only search within a certain radius similar to llSensor().

This has potential, for most single item situations at least, eliminate the need for an llSensor() call and also eliminate the need for a sensor event thus reducing code complexity and make for very easy and very quick data collection to be further processed upon.

---------
Example:
---------

list objDetails;

default
{
    state_entry()
    {
        //Example 1:
        //For this example assume this prim is located at <128, 125, 30> and we have two objects named 'Chair'.
        //'Chair' #1 is located at <128, 128, 30> and owned by avatar UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
        //'Chair' #2 is located at <128, 130, 30> and owned by avatar UUID 1c612fb2-748c-4a1a-ad57-27f488210c06

        objDetails = osGetObjectNameDetails(["Chair"], OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

        llOwnerSay(llDumpList2String(objDetails, ", "));

        //llOwnerSay() output should be: Chair, <128, 128, 30>, 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair, <128, 130, 30>, 1c612fb2-748c-4a1a-ad57-27f488210c06

//------------------------------------------------------------------------------------------------------------------------------------------------------------------

        //Example 2:
        //For this example assume everything stays the same as in Example 1 except that we're specifying a range.

        objDetails = osGetObjectNameDetails(["Chair"], 5.0, OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

        llOwnerSay(llDumpList2String(objDetails, ", "));

        //llOwnerSay() output should be: Chair, <128, 128, 30>, 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a

//------------------------------------------------------------------------------------------------------------------------------------------------------------------

        //Example 3:
        //For this example assume this prim is located at <128, 125, 30> and we have two objects: 'Chair 1' and 'Chair 2'.
        //'Chair 1' is located at <128, 128, 30> and owned by avatar UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
        //'Chair 2' is located at <128, 130, 30> and owned by avatar UUID 1c612fb2-748c-4a1a-ad57-27f488210c06

        objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"], OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

        llOwnerSay(llDumpList2String(objDetails, ", "));

        //llOwnerSay() output should be: Chair 1, <128, 128, 30>, 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair 2, <128, 130, 30>, 1c612fb2-748c-4a1a-ad57-27f488210c06

//------------------------------------------------------------------------------------------------------------------------------------------------------------------

        //Example 4:
        //For this example assume everything stays the same as in Example 3 except that we're specifying a range.

        objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"], 5.0, OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

        llOwnerSay(llDumpList2String(objDetails, ", "));

        //llOwnerSay() output should be: Chair 1, <128, 128, 30>, 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
    }
}


_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users


--
OpenSim: 10 Region Standalone on 0.7.6 Dev

Physics: Open Dynamics Engine
OS: Windows 7 (x64)
CPU: AMD FX 8320 8-Core 3.5 GHz
Memory: 16 GB DDR3
Database: MySQL 5.1.63 (x64)

_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users



_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users


_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for a new OSSL function

Chris M
My idea was to make it easier to get this information (from an LSL standpoint) directly where it's called. So you could have something like this:

list objDetails = osGetObjectNameDetails(["Chair"], OBJECT_NAME | OBJECT_POS);
string objName = llList2String(objDetails, 0);
vector objPos = llList2Vector(objDetails, 1);

or perhaps iterate through the list if more than one set of data is returned.

Code complexity (Understood that it would not be reduced server side) is reduced on the script side of things.

I do agree that scanning an entire region by default would put a lot of load on the simulator which is why I also provided the option of limiting the scan distance. Perhaps it would be better to remove the list osGetObjectNameDetails(list names, list params) and just have list osGetObjectNameDetails(list names, float range, list params) so it would force the user of the function to think about the distance needed to acquire this information; maybe even make a max distance for this function configurable in OpenSim.ini so that it can't scan further than that from that configured point of origin?

Potential for abuse is always a concern; I would think this function would fit in a Threat level of possibly at least High but probably at least VeryHigh. Then there's always the Allow_* configuration to disable this completely if an operator doesn't want this used at all or to only allow it for certain users.

I do understand that event usage is commonplace but we still have os* functions such as the notecard functions that skip their related events entirely, which in my opinion, is very useful as it makes it very easy to gather and manipulate data "on the spot" in a relatively short amount of scripting. In the case of osGetNotecardLine() for instance it's very simple to read a line in a notecard in just one line of code. With llGetNotecardLine() a dataserver event would need to be set up as well as its respective scripting in that event to handle the data, increment the line count, etc. osGetNotecardLine() in combination with osGetNumberOfNotecardLines() with a loop of some kind results in initially a much shorter much easier to implement notecard reader.

While I understand completely about the concerns of simulator load on a region scan; I'm not quite understanding (if hypothetically this function was implemented) the concern of having an "event-less" data return?

On 3/13/2015 3:25 PM, R.Gunther wrote:
I expected the OSSL works also with UUID you get from sensor. llGetObject details works very good for me, except am misisng the object size.
I have a workaround for that. But a command that need to scan the whole sim to get something. I agree with dahlia, bad idea.

On 2015-03-13 21:12, Dahlia Trimble wrote:
Some initial thoughts

Why not a function that returns a uuid for a name? Actually this could be done with a sensor now. No need to duplicate llGetObjectDetails functionality, just call it once you get the uuid.

Such a function would need to scan every object in the region for a name match, similar to how a sensor would do it. This can put a lot of load on the simulator and could tie up internal data structures until the scan completes, possibly preventing other more critical code from executing. If such functionality was added, it would likely need to be throttled to prevent abuse and/or use events to return results similar to sensors now. Perhaps another approach might be to get rid of the sensor distance limit, or relax it in favor of some other penalty such as a script delay if a further distance is requested. This would, however, deviate from the SL API documented behavior and as such would probably need to go into a os* function.

Sorry, I don't accept the argument that it reduces code complexity, it only moves the complexity into the simulator code. Script event patterns are quite common and well understood by the community and have the advantage that, when used properly in place of other patterns (loops, etc), help the simulator run better.

On Fri, Mar 13, 2015 at 12:10 PM, Chris <[hidden email]> wrote:
Getting an object's size would be a really nice addition; but going by how llGetScale() functions I believe it would be limited to getting just the root prim's size rather than overall size if I'm thinking about this correctly.


On 3/13/2015 2:03 PM, R.Gunther wrote:
One thing that llGetObject detail is missing is to get the prim size. so if this command get add. i hope the add the object size too.


On 2015-03-13 20:00, Chris wrote:
Hello all,

I have a proposal for a new OSSL function that could possibly prove useful: osGetObjectNameDetails()

I would have sent this to the opensim-dev mailing list but I'm unsure now of where this is located and how to sign up for that list since the old mailing list locations are now gone. Can someone please point me in the right direction? :)

This proposal has also been posted at http://opensimulator.org/wiki/OSSL_Proposals

Thank you in advance for the consideration!

----------
Function:
----------

list osGetObjectNameDetails(list names, list params);
list osGetObjectNameDetails(list names, float range, list params);

-------------
Description:
-------------

Would work similarly to llGetObjectDetails() but has the advantage of specifying for an object's name (or list of names) instead of by key. If more than one name match is found then the return list will have those matches (or groups of matches if more than one parameter is supplied) sorted in order from nearest to furthest from the prim calling osGetObjectNameDetails. By default this would scan the entire region but optionally a range can be specified to only search within a certain radius similar to llSensor().

This has potential, for most single item situations at least, eliminate the need for an llSensor() call and also eliminate the need for a sensor event thus reducing code complexity and make for very easy and very quick data collection to be further processed upon.

---------
Example:
---------

list objDetails;

default
{
    state_entry()
    {
        //Example 1:
        //For this example assume this prim is located at <128, 125, 30> and we have two objects named 'Chair'.
        //'Chair' #1 is located at <128, 128, 30> and owned by avatar UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
        //'Chair' #2 is located at <128, 130, 30> and owned by avatar UUID 1c612fb2-748c-4a1a-ad57-27f488210c06

        objDetails = osGetObjectNameDetails(["Chair"], OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

        llOwnerSay(llDumpList2String(objDetails, ", "));

        //llOwnerSay() output should be: Chair, <128, 128, 30>, 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair, <128, 130, 30>, 1c612fb2-748c-4a1a-ad57-27f488210c06

//------------------------------------------------------------------------------------------------------------------------------------------------------------------

        //Example 2:
        //For this example assume everything stays the same as in Example 1 except that we're specifying a range.

        objDetails = osGetObjectNameDetails(["Chair"], 5.0, OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

        llOwnerSay(llDumpList2String(objDetails, ", "));

        //llOwnerSay() output should be: Chair, <128, 128, 30>, 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a

//------------------------------------------------------------------------------------------------------------------------------------------------------------------

        //Example 3:
        //For this example assume this prim is located at <128, 125, 30> and we have two objects: 'Chair 1' and 'Chair 2'.
        //'Chair 1' is located at <128, 128, 30> and owned by avatar UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
        //'Chair 2' is located at <128, 130, 30> and owned by avatar UUID 1c612fb2-748c-4a1a-ad57-27f488210c06

        objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"], OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

        llOwnerSay(llDumpList2String(objDetails, ", "));

        //llOwnerSay() output should be: Chair 1, <128, 128, 30>, 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair 2, <128, 130, 30>, 1c612fb2-748c-4a1a-ad57-27f488210c06

//------------------------------------------------------------------------------------------------------------------------------------------------------------------

        //Example 4:
        //For this example assume everything stays the same as in Example 3 except that we're specifying a range.

        objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"], 5.0, OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

        llOwnerSay(llDumpList2String(objDetails, ", "));

        //llOwnerSay() output should be: Chair 1, <128, 128, 30>, 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
    }
}


_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users


--
OpenSim: 10 Region Standalone on 0.7.6 Dev

Physics: Open Dynamics Engine
OS: Windows 7 (x64)
CPU: AMD FX 8320 8-Core 3.5 GHz
Memory: 16 GB DDR3
Database: MySQL 5.1.63 (x64)

_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users



_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users



_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users


-- 
OpenSim: 10 Region Standalone on 0.7.6 Dev
Physics: Open Dynamics Engine
OS: Windows 7 (x64)
CPU: AMD FX 8320 8-Core 3.5 GHz
Memory: 16 GB DDR3
Database: MySQL 5.1.63 (x64)

_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for a new OSSL function

Dahlia Trimble
It *always* would need to scan the entire region contents because OpenSimulator lacks the ability to do spatial queries in any way other than a linear search.

Sorry but I don't see the benefit of having the sim developers need to maintain extra complexity so your script can have a few less lines of code.

On Mon, Mar 16, 2015 at 5:34 AM, Chris <[hidden email]> wrote:
My idea was to make it easier to get this information (from an LSL standpoint) directly where it's called. So you could have something like this:

list objDetails = osGetObjectNameDetails(["Chair"], OBJECT_NAME | OBJECT_POS);
string objName = llList2String(objDetails, 0);
vector objPos = llList2Vector(objDetails, 1);

or perhaps iterate through the list if more than one set of data is returned.

Code complexity (Understood that it would not be reduced server side) is reduced on the script side of things.

I do agree that scanning an entire region by default would put a lot of load on the simulator which is why I also provided the option of limiting the scan distance. Perhaps it would be better to remove the list osGetObjectNameDetails(list names, list params) and just have list osGetObjectNameDetails(list names, float range, list params) so it would force the user of the function to think about the distance needed to acquire this information; maybe even make a max distance for this function configurable in OpenSim.ini so that it can't scan further than that from that configured point of origin?

Potential for abuse is always a concern; I would think this function would fit in a Threat level of possibly at least High but probably at least VeryHigh. Then there's always the Allow_* configuration to disable this completely if an operator doesn't want this used at all or to only allow it for certain users.

I do understand that event usage is commonplace but we still have os* functions such as the notecard functions that skip their related events entirely, which in my opinion, is very useful as it makes it very easy to gather and manipulate data "on the spot" in a relatively short amount of scripting. In the case of osGetNotecardLine() for instance it's very simple to read a line in a notecard in just one line of code. With llGetNotecardLine() a dataserver event would need to be set up as well as its respective scripting in that event to handle the data, increment the line count, etc. osGetNotecardLine() in combination with osGetNumberOfNotecardLines() with a loop of some kind results in initially a much shorter much easier to implement notecard reader.

While I understand completely about the concerns of simulator load on a region scan; I'm not quite understanding (if hypothetically this function was implemented) the concern of having an "event-less" data return?


On 3/13/2015 3:25 PM, R.Gunther wrote:
I expected the OSSL works also with UUID you get from sensor. llGetObject details works very good for me, except am misisng the object size.
I have a workaround for that. But a command that need to scan the whole sim to get something. I agree with dahlia, bad idea.

On 2015-03-13 21:12, Dahlia Trimble wrote:
Some initial thoughts

Why not a function that returns a uuid for a name? Actually this could be done with a sensor now. No need to duplicate llGetObjectDetails functionality, just call it once you get the uuid.

Such a function would need to scan every object in the region for a name match, similar to how a sensor would do it. This can put a lot of load on the simulator and could tie up internal data structures until the scan completes, possibly preventing other more critical code from executing. If such functionality was added, it would likely need to be throttled to prevent abuse and/or use events to return results similar to sensors now. Perhaps another approach might be to get rid of the sensor distance limit, or relax it in favor of some other penalty such as a script delay if a further distance is requested. This would, however, deviate from the SL API documented behavior and as such would probably need to go into a os* function.

Sorry, I don't accept the argument that it reduces code complexity, it only moves the complexity into the simulator code. Script event patterns are quite common and well understood by the community and have the advantage that, when used properly in place of other patterns (loops, etc), help the simulator run better.

On Fri, Mar 13, 2015 at 12:10 PM, Chris <[hidden email]> wrote:
Getting an object's size would be a really nice addition; but going by how llGetScale() functions I believe it would be limited to getting just the root prim's size rather than overall size if I'm thinking about this correctly.


On 3/13/2015 2:03 PM, R.Gunther wrote:
One thing that llGetObject detail is missing is to get the prim size. so if this command get add. i hope the add the object size too.


On 2015-03-13 20:00, Chris wrote:
Hello all,

I have a proposal for a new OSSL function that could possibly prove useful: osGetObjectNameDetails()

I would have sent this to the opensim-dev mailing list but I'm unsure now of where this is located and how to sign up for that list since the old mailing list locations are now gone. Can someone please point me in the right direction? :)

This proposal has also been posted at http://opensimulator.org/wiki/OSSL_Proposals

Thank you in advance for the consideration!

----------
Function:
----------

list osGetObjectNameDetails(list names, list params);
list osGetObjectNameDetails(list names, float range, list params);

-------------
Description:
-------------

Would work similarly to llGetObjectDetails() but has the advantage of specifying for an object's name (or list of names) instead of by key. If more than one name match is found then the return list will have those matches (or groups of matches if more than one parameter is supplied) sorted in order from nearest to furthest from the prim calling osGetObjectNameDetails. By default this would scan the entire region but optionally a range can be specified to only search within a certain radius similar to llSensor().

This has potential, for most single item situations at least, eliminate the need for an llSensor() call and also eliminate the need for a sensor event thus reducing code complexity and make for very easy and very quick data collection to be further processed upon.

---------
Example:
---------

list objDetails;

default
{
    state_entry()
    {
        //Example 1:
        //For this example assume this prim is located at <128, 125, 30> and we have two objects named 'Chair'.
        //'Chair' #1 is located at <128, 128, 30> and owned by avatar UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
        //'Chair' #2 is located at <128, 130, 30> and owned by avatar UUID 1c612fb2-748c-4a1a-ad57-27f488210c06

        objDetails = osGetObjectNameDetails(["Chair"], OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

        llOwnerSay(llDumpList2String(objDetails, ", "));

        //llOwnerSay() output should be: Chair, <128, 128, 30>, 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair, <128, 130, 30>, 1c612fb2-748c-4a1a-ad57-27f488210c06

//------------------------------------------------------------------------------------------------------------------------------------------------------------------

        //Example 2:
        //For this example assume everything stays the same as in Example 1 except that we're specifying a range.

        objDetails = osGetObjectNameDetails(["Chair"], 5.0, OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

        llOwnerSay(llDumpList2String(objDetails, ", "));

        //llOwnerSay() output should be: Chair, <128, 128, 30>, 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a

//------------------------------------------------------------------------------------------------------------------------------------------------------------------

        //Example 3:
        //For this example assume this prim is located at <128, 125, 30> and we have two objects: 'Chair 1' and 'Chair 2'.
        //'Chair 1' is located at <128, 128, 30> and owned by avatar UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
        //'Chair 2' is located at <128, 130, 30> and owned by avatar UUID 1c612fb2-748c-4a1a-ad57-27f488210c06

        objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"], OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

        llOwnerSay(llDumpList2String(objDetails, ", "));

        //llOwnerSay() output should be: Chair 1, <128, 128, 30>, 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair 2, <128, 130, 30>, 1c612fb2-748c-4a1a-ad57-27f488210c06

//------------------------------------------------------------------------------------------------------------------------------------------------------------------

        //Example 4:
        //For this example assume everything stays the same as in Example 3 except that we're specifying a range.

        objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"], 5.0, OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);

        llOwnerSay(llDumpList2String(objDetails, ", "));

        //llOwnerSay() output should be: Chair 1, <128, 128, 30>, 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
    }
}


_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users


--
OpenSim: 10 Region Standalone on 0.7.6 Dev

Physics: Open Dynamics Engine
OS: Windows 7 (x64)
CPU: AMD FX 8320 8-Core 3.5 GHz
Memory: 16 GB DDR3
Database: MySQL 5.1.63 (x64)

_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users



_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users



_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users


-- 
OpenSim: 10 Region Standalone on 0.7.6 Dev
Physics: Open Dynamics Engine
OS: Windows 7 (x64)
CPU: AMD FX 8320 8-Core 3.5 GHz
Memory: 16 GB DDR3
Database: MySQL 5.1.63 (x64)

_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users



_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for a new OSSL function

Melanie
There are tools in SL that are able to gather this information,
through a combination of llGetObjectDetails and llSensor and some
others. This includes the rotation and scaling as well as the kind
of object, etc. Builder's tools do this regularly to place "red dot"
prim spheres at the corners of the blocks to be worked on.
I was very surprised to see this working in SL a few years ago, but
after a bit of thought, it was quite clear how they do it even in
the limited environment of LSL in SL.

Scanning for prims by name is worse than useless, imagine the load
it would cause to search for "Primitive" or "Object", respectively.
Scanning for prims by position is a loop over all objects in the
sim, each time, because OpenSim doesn't use octrees fir spatal
organization, as Dahlia already stated.

I don't see where that function is in the interest of OpenSim and
it's users.

I suggest that you may be able to write a private region module to
this effect, giving you this function but not tasking core with
maintaining it for you.

- Melanie

On 16/03/2015 19:23, Dahlia Trimble wrote:

> It *always* would need to scan the entire region contents because
> OpenSimulator lacks the ability to do spatial queries in any way other than
> a linear search.
>
> Sorry but I don't see the benefit of having the sim developers need to
> maintain extra complexity so your script can have a few less lines of code.
>
> On Mon, Mar 16, 2015 at 5:34 AM, Chris <[hidden email]> wrote:
>
>>  My idea was to make it easier to get this information (from an LSL
>> standpoint) directly where it's called. So you could have something like
>> this:
>>
>> list objDetails = osGetObjectNameDetails(["Chair"], OBJECT_NAME |
>> OBJECT_POS);
>> string objName = llList2String(objDetails, 0);
>> vector objPos = llList2Vector(objDetails, 1);
>>
>> or perhaps iterate through the list if more than one set of data is
>> returned.
>>
>> Code complexity (Understood that it would not be reduced server side) is
>> reduced on the script side of things.
>>
>> I do agree that scanning an entire region by default would put a lot of
>> load on the simulator which is why I also provided the option of limiting
>> the scan distance. Perhaps it would be better to remove the list
>> osGetObjectNameDetails(list names, list params) and just have list
>> osGetObjectNameDetails(list names, float range, list params) so it would
>> force the user of the function to think about the distance needed to
>> acquire this information; maybe even make a max distance for this function
>> configurable in OpenSim.ini so that it can't scan further than that from
>> that configured point of origin?
>>
>> Potential for abuse is always a concern; I would think this function would
>> fit in a Threat level of possibly at least High but probably at least
>> VeryHigh. Then there's always the Allow_* configuration to disable this
>> completely if an operator doesn't want this used at all or to only allow it
>> for certain users.
>>
>> I do understand that event usage is commonplace but we still have os*
>> functions such as the notecard functions that skip their related events
>> entirely, which in my opinion, is very useful as it makes it very easy to
>> gather and manipulate data "on the spot" in a relatively short amount of
>> scripting. In the case of osGetNotecardLine() for instance it's very simple
>> to read a line in a notecard in just one line of code. With
>> llGetNotecardLine() a dataserver event would need to be set up as well as
>> its respective scripting in that event to handle the data, increment the
>> line count, etc. osGetNotecardLine() in combination with
>> osGetNumberOfNotecardLines() with a loop of some kind results in initially
>> a much shorter much easier to implement notecard reader.
>>
>> While I understand completely about the concerns of simulator load on a
>> region scan; I'm not quite understanding (if hypothetically this function
>> was implemented) the concern of having an "event-less" data return?
>>
>>
>> On 3/13/2015 3:25 PM, R.Gunther wrote:
>>
>> I expected the OSSL works also with UUID you get from sensor. llGetObject
>> details works very good for me, except am misisng the object size.
>> I have a workaround for that. But a command that need to scan the whole
>> sim to get something. I agree with dahlia, bad idea.
>>
>> On 2015-03-13 21:12, Dahlia Trimble wrote:
>>
>>   Some initial thoughts
>>
>>  Why not a function that returns a uuid for a name? Actually this could be
>> done with a sensor now. No need to duplicate llGetObjectDetails
>> functionality, just call it once you get the uuid.
>>
>>  Such a function would need to scan every object in the region for a name
>> match, similar to how a sensor would do it. This can put a lot of load on
>> the simulator and could tie up internal data structures until the scan
>> completes, possibly preventing other more critical code from executing. If
>> such functionality was added, it would likely need to be throttled to
>> prevent abuse and/or use events to return results similar to sensors now.
>> Perhaps another approach might be to get rid of the sensor distance limit,
>> or relax it in favor of some other penalty such as a script delay if a
>> further distance is requested. This would, however, deviate from the SL API
>> documented behavior and as such would probably need to go into a os*
>> function.
>>
>>  Sorry, I don't accept the argument that it reduces code complexity, it
>> only moves the complexity into the simulator code. Script event patterns
>> are quite common and well understood by the community and have the
>> advantage that, when used properly in place of other patterns (loops, etc),
>> help the simulator run better.
>>
>> On Fri, Mar 13, 2015 at 12:10 PM, Chris <[hidden email]> wrote:
>>
>>> Getting an object's size would be a really nice addition; but going by
>>> how llGetScale() functions I believe it would be limited to getting just
>>> the root prim's size rather than overall size if I'm thinking about this
>>> correctly.
>>>
>>>
>>> On 3/13/2015 2:03 PM, R.Gunther wrote:
>>>
>>>> One thing that llGetObject detail is missing is to get the prim size. so
>>>> if this command get add. i hope the add the object size too.
>>>>
>>>>
>>>> On 2015-03-13 20:00, Chris wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> I have a proposal for a new OSSL function that could possibly prove
>>>>> useful: osGetObjectNameDetails()
>>>>>
>>>>> I would have sent this to the opensim-dev mailing list but I'm unsure
>>>>> now of where this is located and how to sign up for that list since the old
>>>>> mailing list locations are now gone. Can someone please point me in the
>>>>> right direction? :)
>>>>>
>>>>> This proposal has also been posted at
>>>>> http://opensimulator.org/wiki/OSSL_Proposals
>>>>>
>>>>> Thank you in advance for the consideration!
>>>>>
>>>>> ----------
>>>>> Function:
>>>>> ----------
>>>>>
>>>>> list osGetObjectNameDetails(list names, list params);
>>>>> list osGetObjectNameDetails(list names, float range, list params);
>>>>>
>>>>> -------------
>>>>> Description:
>>>>> -------------
>>>>>
>>>>> Would work similarly to llGetObjectDetails() but has the advantage of
>>>>> specifying for an object's name (or list of names) instead of by key. If
>>>>> more than one name match is found then the return list will have those
>>>>> matches (or groups of matches if more than one parameter is supplied)
>>>>> sorted in order from nearest to furthest from the prim calling
>>>>> osGetObjectNameDetails. By default this would scan the entire region but
>>>>> optionally a range can be specified to only search within a certain radius
>>>>> similar to llSensor().
>>>>>
>>>>> This has potential, for most single item situations at least, eliminate
>>>>> the need for an llSensor() call and also eliminate the need for a sensor
>>>>> event thus reducing code complexity and make for very easy and very quick
>>>>> data collection to be further processed upon.
>>>>>
>>>>> ---------
>>>>> Example:
>>>>> ---------
>>>>>
>>>>> list objDetails;
>>>>>
>>>>> default
>>>>> {
>>>>>     state_entry()
>>>>>     {
>>>>>         //Example 1:
>>>>>         //For this example assume this prim is located at <128, 125,
>>>>> 30> and we have two objects named 'Chair'.
>>>>>         //'Chair' #1 is located at <128, 128, 30> and owned by avatar
>>>>> UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
>>>>>         //'Chair' #2 is located at <128, 130, 30> and owned by avatar
>>>>> UUID 1c612fb2-748c-4a1a-ad57-27f488210c06
>>>>>
>>>>>         objDetails = osGetObjectNameDetails(["Chair"], OBJECT_NAME |
>>>>> OBJECT_POS | OBJECT_OWNER);
>>>>>
>>>>>         llOwnerSay(llDumpList2String(objDetails, ", "));
>>>>>
>>>>>         //llOwnerSay() output should be: Chair, <128, 128, 30>,
>>>>> 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair, <128, 130, 30>,
>>>>> 1c612fb2-748c-4a1a-ad57-27f488210c06
>>>>>
>>>>> //------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>         //Example 2:
>>>>>         //For this example assume everything stays the same as in
>>>>> Example 1 except that we're specifying a range.
>>>>>
>>>>>         objDetails = osGetObjectNameDetails(["Chair"], 5.0, OBJECT_NAME
>>>>> | OBJECT_POS | OBJECT_OWNER);
>>>>>
>>>>>         llOwnerSay(llDumpList2String(objDetails, ", "));
>>>>>
>>>>>         //llOwnerSay() output should be: Chair, <128, 128, 30>,
>>>>> 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
>>>>>
>>>>> //------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>         //Example 3:
>>>>>         //For this example assume this prim is located at <128, 125,
>>>>> 30> and we have two objects: 'Chair 1' and 'Chair 2'.
>>>>>         //'Chair 1' is located at <128, 128, 30> and owned by avatar
>>>>> UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
>>>>>         //'Chair 2' is located at <128, 130, 30> and owned by avatar
>>>>> UUID 1c612fb2-748c-4a1a-ad57-27f488210c06
>>>>>
>>>>>         objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"],
>>>>> OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);
>>>>>
>>>>>         llOwnerSay(llDumpList2String(objDetails, ", "));
>>>>>
>>>>>         //llOwnerSay() output should be: Chair 1, <128, 128, 30>,
>>>>> 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair 2, <128, 130, 30>,
>>>>> 1c612fb2-748c-4a1a-ad57-27f488210c06
>>>>>
>>>>> //------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>         //Example 4:
>>>>>         //For this example assume everything stays the same as in
>>>>> Example 3 except that we're specifying a range.
>>>>>
>>>>>         objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"],
>>>>> 5.0, OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);
>>>>>
>>>>>         llOwnerSay(llDumpList2String(objDetails, ", "));
>>>>>
>>>>>         //llOwnerSay() output should be: Chair 1, <128, 128, 30>,
>>>>> 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
>>>>>     }
>>>>> }
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Opensim-users mailing list
>>>> [hidden email]
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>>>
>>>
>>>
>>>   --
>>> OpenSim: 10 Region Standalone on 0.7.6 Dev
>>> Physics: Open Dynamics Engine
>>> OS: Windows 7 (x64)
>>> CPU: AMD FX 8320 8-Core 3.5 GHz
>>> Memory: 16 GB DDR3
>>> Database: MySQL 5.1.63 (x64)
>>>
>>>   _______________________________________________
>>> Opensim-users mailing list
>>> [hidden email]
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>>
>>
>>
>>
>> _______________________________________________
>> Opensim-users mailing [hidden email]://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>
>>
>>
>>
>> _______________________________________________
>> Opensim-users mailing [hidden email]://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>
>>
>>
>> --
>> OpenSim: 10 Region Standalone on 0.7.6 Dev
>> Physics: Open Dynamics Engine
>> OS: Windows 7 (x64)
>> CPU: AMD FX 8320 8-Core 3.5 GHz
>> Memory: 16 GB DDR3
>> Database: MySQL 5.1.63 (x64)
>>
>>
>> _______________________________________________
>> Opensim-users mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>
>>
>
>
>
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for a new OSSL function

Chris M
Alright, I will look into some other ways to accomplish what I'm trying
to do using the suggestions both of you have provided. I will go ahead
and remove the proposal from the wiki since it's not a very good idea to
implement.

Thank you very much for the consideration though! :)

On 3/16/2015 1:33 PM, Melanie wrote:

> There are tools in SL that are able to gather this information,
> through a combination of llGetObjectDetails and llSensor and some
> others. This includes the rotation and scaling as well as the kind
> of object, etc. Builder's tools do this regularly to place "red dot"
> prim spheres at the corners of the blocks to be worked on.
> I was very surprised to see this working in SL a few years ago, but
> after a bit of thought, it was quite clear how they do it even in
> the limited environment of LSL in SL.
>
> Scanning for prims by name is worse than useless, imagine the load
> it would cause to search for "Primitive" or "Object", respectively.
> Scanning for prims by position is a loop over all objects in the
> sim, each time, because OpenSim doesn't use octrees fir spatal
> organization, as Dahlia already stated.
>
> I don't see where that function is in the interest of OpenSim and
> it's users.
>
> I suggest that you may be able to write a private region module to
> this effect, giving you this function but not tasking core with
> maintaining it for you.
>
> - Melanie
>
> On 16/03/2015 19:23, Dahlia Trimble wrote:
>> It *always* would need to scan the entire region contents because
>> OpenSimulator lacks the ability to do spatial queries in any way other than
>> a linear search.
>>
>> Sorry but I don't see the benefit of having the sim developers need to
>> maintain extra complexity so your script can have a few less lines of code.
>>
>> On Mon, Mar 16, 2015 at 5:34 AM, Chris <[hidden email]> wrote:
>>
>>>   My idea was to make it easier to get this information (from an LSL
>>> standpoint) directly where it's called. So you could have something like
>>> this:
>>>
>>> list objDetails = osGetObjectNameDetails(["Chair"], OBJECT_NAME |
>>> OBJECT_POS);
>>> string objName = llList2String(objDetails, 0);
>>> vector objPos = llList2Vector(objDetails, 1);
>>>
>>> or perhaps iterate through the list if more than one set of data is
>>> returned.
>>>
>>> Code complexity (Understood that it would not be reduced server side) is
>>> reduced on the script side of things.
>>>
>>> I do agree that scanning an entire region by default would put a lot of
>>> load on the simulator which is why I also provided the option of limiting
>>> the scan distance. Perhaps it would be better to remove the list
>>> osGetObjectNameDetails(list names, list params) and just have list
>>> osGetObjectNameDetails(list names, float range, list params) so it would
>>> force the user of the function to think about the distance needed to
>>> acquire this information; maybe even make a max distance for this function
>>> configurable in OpenSim.ini so that it can't scan further than that from
>>> that configured point of origin?
>>>
>>> Potential for abuse is always a concern; I would think this function would
>>> fit in a Threat level of possibly at least High but probably at least
>>> VeryHigh. Then there's always the Allow_* configuration to disable this
>>> completely if an operator doesn't want this used at all or to only allow it
>>> for certain users.
>>>
>>> I do understand that event usage is commonplace but we still have os*
>>> functions such as the notecard functions that skip their related events
>>> entirely, which in my opinion, is very useful as it makes it very easy to
>>> gather and manipulate data "on the spot" in a relatively short amount of
>>> scripting. In the case of osGetNotecardLine() for instance it's very simple
>>> to read a line in a notecard in just one line of code. With
>>> llGetNotecardLine() a dataserver event would need to be set up as well as
>>> its respective scripting in that event to handle the data, increment the
>>> line count, etc. osGetNotecardLine() in combination with
>>> osGetNumberOfNotecardLines() with a loop of some kind results in initially
>>> a much shorter much easier to implement notecard reader.
>>>
>>> While I understand completely about the concerns of simulator load on a
>>> region scan; I'm not quite understanding (if hypothetically this function
>>> was implemented) the concern of having an "event-less" data return?
>>>
>>>
>>> On 3/13/2015 3:25 PM, R.Gunther wrote:
>>>
>>> I expected the OSSL works also with UUID you get from sensor. llGetObject
>>> details works very good for me, except am misisng the object size.
>>> I have a workaround for that. But a command that need to scan the whole
>>> sim to get something. I agree with dahlia, bad idea.
>>>
>>> On 2015-03-13 21:12, Dahlia Trimble wrote:
>>>
>>>    Some initial thoughts
>>>
>>>   Why not a function that returns a uuid for a name? Actually this could be
>>> done with a sensor now. No need to duplicate llGetObjectDetails
>>> functionality, just call it once you get the uuid.
>>>
>>>   Such a function would need to scan every object in the region for a name
>>> match, similar to how a sensor would do it. This can put a lot of load on
>>> the simulator and could tie up internal data structures until the scan
>>> completes, possibly preventing other more critical code from executing. If
>>> such functionality was added, it would likely need to be throttled to
>>> prevent abuse and/or use events to return results similar to sensors now.
>>> Perhaps another approach might be to get rid of the sensor distance limit,
>>> or relax it in favor of some other penalty such as a script delay if a
>>> further distance is requested. This would, however, deviate from the SL API
>>> documented behavior and as such would probably need to go into a os*
>>> function.
>>>
>>>   Sorry, I don't accept the argument that it reduces code complexity, it
>>> only moves the complexity into the simulator code. Script event patterns
>>> are quite common and well understood by the community and have the
>>> advantage that, when used properly in place of other patterns (loops, etc),
>>> help the simulator run better.
>>>
>>> On Fri, Mar 13, 2015 at 12:10 PM, Chris <[hidden email]> wrote:
>>>
>>>> Getting an object's size would be a really nice addition; but going by
>>>> how llGetScale() functions I believe it would be limited to getting just
>>>> the root prim's size rather than overall size if I'm thinking about this
>>>> correctly.
>>>>
>>>>
>>>> On 3/13/2015 2:03 PM, R.Gunther wrote:
>>>>
>>>>> One thing that llGetObject detail is missing is to get the prim size. so
>>>>> if this command get add. i hope the add the object size too.
>>>>>
>>>>>
>>>>> On 2015-03-13 20:00, Chris wrote:
>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> I have a proposal for a new OSSL function that could possibly prove
>>>>>> useful: osGetObjectNameDetails()
>>>>>>
>>>>>> I would have sent this to the opensim-dev mailing list but I'm unsure
>>>>>> now of where this is located and how to sign up for that list since the old
>>>>>> mailing list locations are now gone. Can someone please point me in the
>>>>>> right direction? :)
>>>>>>
>>>>>> This proposal has also been posted at
>>>>>> http://opensimulator.org/wiki/OSSL_Proposals
>>>>>>
>>>>>> Thank you in advance for the consideration!
>>>>>>
>>>>>> ----------
>>>>>> Function:
>>>>>> ----------
>>>>>>
>>>>>> list osGetObjectNameDetails(list names, list params);
>>>>>> list osGetObjectNameDetails(list names, float range, list params);
>>>>>>
>>>>>> -------------
>>>>>> Description:
>>>>>> -------------
>>>>>>
>>>>>> Would work similarly to llGetObjectDetails() but has the advantage of
>>>>>> specifying for an object's name (or list of names) instead of by key. If
>>>>>> more than one name match is found then the return list will have those
>>>>>> matches (or groups of matches if more than one parameter is supplied)
>>>>>> sorted in order from nearest to furthest from the prim calling
>>>>>> osGetObjectNameDetails. By default this would scan the entire region but
>>>>>> optionally a range can be specified to only search within a certain radius
>>>>>> similar to llSensor().
>>>>>>
>>>>>> This has potential, for most single item situations at least, eliminate
>>>>>> the need for an llSensor() call and also eliminate the need for a sensor
>>>>>> event thus reducing code complexity and make for very easy and very quick
>>>>>> data collection to be further processed upon.
>>>>>>
>>>>>> ---------
>>>>>> Example:
>>>>>> ---------
>>>>>>
>>>>>> list objDetails;
>>>>>>
>>>>>> default
>>>>>> {
>>>>>>      state_entry()
>>>>>>      {
>>>>>>          //Example 1:
>>>>>>          //For this example assume this prim is located at <128, 125,
>>>>>> 30> and we have two objects named 'Chair'.
>>>>>>          //'Chair' #1 is located at <128, 128, 30> and owned by avatar
>>>>>> UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
>>>>>>          //'Chair' #2 is located at <128, 130, 30> and owned by avatar
>>>>>> UUID 1c612fb2-748c-4a1a-ad57-27f488210c06
>>>>>>
>>>>>>          objDetails = osGetObjectNameDetails(["Chair"], OBJECT_NAME |
>>>>>> OBJECT_POS | OBJECT_OWNER);
>>>>>>
>>>>>>          llOwnerSay(llDumpList2String(objDetails, ", "));
>>>>>>
>>>>>>          //llOwnerSay() output should be: Chair, <128, 128, 30>,
>>>>>> 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair, <128, 130, 30>,
>>>>>> 1c612fb2-748c-4a1a-ad57-27f488210c06
>>>>>>
>>>>>> //------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>          //Example 2:
>>>>>>          //For this example assume everything stays the same as in
>>>>>> Example 1 except that we're specifying a range.
>>>>>>
>>>>>>          objDetails = osGetObjectNameDetails(["Chair"], 5.0, OBJECT_NAME
>>>>>> | OBJECT_POS | OBJECT_OWNER);
>>>>>>
>>>>>>          llOwnerSay(llDumpList2String(objDetails, ", "));
>>>>>>
>>>>>>          //llOwnerSay() output should be: Chair, <128, 128, 30>,
>>>>>> 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
>>>>>>
>>>>>> //------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>          //Example 3:
>>>>>>          //For this example assume this prim is located at <128, 125,
>>>>>> 30> and we have two objects: 'Chair 1' and 'Chair 2'.
>>>>>>          //'Chair 1' is located at <128, 128, 30> and owned by avatar
>>>>>> UUID 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
>>>>>>          //'Chair 2' is located at <128, 130, 30> and owned by avatar
>>>>>> UUID 1c612fb2-748c-4a1a-ad57-27f488210c06
>>>>>>
>>>>>>          objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"],
>>>>>> OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);
>>>>>>
>>>>>>          llOwnerSay(llDumpList2String(objDetails, ", "));
>>>>>>
>>>>>>          //llOwnerSay() output should be: Chair 1, <128, 128, 30>,
>>>>>> 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a, Chair 2, <128, 130, 30>,
>>>>>> 1c612fb2-748c-4a1a-ad57-27f488210c06
>>>>>>
>>>>>> //------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>          //Example 4:
>>>>>>          //For this example assume everything stays the same as in
>>>>>> Example 3 except that we're specifying a range.
>>>>>>
>>>>>>          objDetails = osGetObjectNameDetails(["Chair 1", "Chair 2"],
>>>>>> 5.0, OBJECT_NAME | OBJECT_POS | OBJECT_OWNER);
>>>>>>
>>>>>>          llOwnerSay(llDumpList2String(objDetails, ", "));
>>>>>>
>>>>>>          //llOwnerSay() output should be: Chair 1, <128, 128, 30>,
>>>>>> 5f9c7c6c-f2c9-4196-8d8d-07cdeb71821a
>>>>>>      }
>>>>>> }
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Opensim-users mailing list
>>>>> [hidden email]
>>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>>>>
>>>>
>>>>    --
>>>> OpenSim: 10 Region Standalone on 0.7.6 Dev
>>>> Physics: Open Dynamics Engine
>>>> OS: Windows 7 (x64)
>>>> CPU: AMD FX 8320 8-Core 3.5 GHz
>>>> Memory: 16 GB DDR3
>>>> Database: MySQL 5.1.63 (x64)
>>>>
>>>>    _______________________________________________
>>>> Opensim-users mailing list
>>>> [hidden email]
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>>>
>>>
>>>
>>> _______________________________________________
>>> Opensim-users mailing [hidden email]://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Opensim-users mailing [hidden email]://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>>
>>>
>>>
>>> --
>>> OpenSim: 10 Region Standalone on 0.7.6 Dev
>>> Physics: Open Dynamics Engine
>>> OS: Windows 7 (x64)
>>> CPU: AMD FX 8320 8-Core 3.5 GHz
>>> Memory: 16 GB DDR3
>>> Database: MySQL 5.1.63 (x64)
>>>
>>>
>>> _______________________________________________
>>> Opensim-users mailing list
>>> [hidden email]
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>>
>>>
>>
>>
>> _______________________________________________
>> Opensim-users mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users


--
OpenSim: 10 Region Standalone on 0.8.1 Dev
Physics: Open Dynamics Engine
OS: Windows 7 (x64)
CPU: AMD FX 8320 8-Core 3.5 GHz
Memory: 16 GB DDR3
Database: MySQL 5.1.63 (x64)

_______________________________________________
Opensim-users mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users