[Opensim-users] Proposal for a new OSSL function
Chris
mewtwo0641 at gmail.com
Mon Mar 23 15:20:42 UTC 2015
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 <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
>>>
>>>
>>
>>
>> _______________________________________________
>> Opensim-users mailing list
>> Opensim-users at opensimulator.org
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at opensimulator.org
> 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)
More information about the Opensim-users
mailing list