[Opensim-users] Proposal for a new OSSL function
Dahlia Trimble
dahliatrimble at gmail.com
Mon Mar 16 18:23:44 UTC 2015
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 <mewtwo0641 at gmail.com> 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 <mewtwo0641 at gmail.com> 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
>>> Opensim-users at opensimulator.org
>>> 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
>> Opensim-users at opensimulator.org
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>>
>
>
>
> _______________________________________________
> Opensim-users mailing listOpensim-users at opensimulator.orghttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
>
>
>
> _______________________________________________
> Opensim-users mailing listOpensim-users at opensimulator.orghttp://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
> Opensim-users at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-users/attachments/20150316/bf9f18f6/attachment-0001.html>
More information about the Opensim-users
mailing list