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 <mewtwo0...@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 <mewtwo0...@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@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@opensimulator.org >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users >> > > > > _______________________________________________ > Opensim-users mailing > listOpensim-users@opensimulator.orghttp://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users > > > > > _______________________________________________ > Opensim-users mailing > listOpensim-users@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@opensimulator.org > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users > >
_______________________________________________ Opensim-users mailing list Opensim-users@opensimulator.org http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users