[Opensim-users] Bypassing the 10 m rezzing limit for llRezObject

[Mister Blue]

If you have access to the region, in OpenSim.ini, you can set
[XEngine]ScriptDistanceLimitFactor which changes the enforced rez distance.
It is normally 1.0 which is 10. Making it 25 would make the rez distance
250.
--mb

On Fri, Sep 14, 2012 at 6:25 PM, Dr Ramesh Ramloll <r.ramloll at gmail.com>wrote:

> Well said Edmund, you said what I was expecting to happen.
> ' so it ended
> up being easier just to rez them where we were and tell them to move
> to where we wanted them. '
>
> and
> ' , it doesn't
>
> always seem to be in a position to listen for and handle messages. I
> think the issue is that it takes a bit of time after an object rezzes
> for it to start running its scripts and start listening for messages. '
>
> So unfortunately, I will have to do dirty coding again to make it happen.
> Unless there is a compelling reason,
> does implementing an opensim function RezObjectAtRegionCoordinates() going
> to lead to problems?
> I understand that 10 m limit might have been implemented to avoid griefing
> initially,
> for the same reason that llSetRegionPos is being implemented ... I think
> there is a need for something similar for Rezzing.
>
> How else could we do 'parametric building' and procedural based building
> sim wide? This is quite important I think.
> There are lots of viz applications that would require the 10 m rez limit
> to be bypassed.
>
> If dirty coding in LSL ... (also implying waste of tons of computing
> resources ...listening to this and that message etc...) could allow it, I
> think there is a need for a sim wide rez function.
>
> Hope the opensim gods will answer my prayers.
>
> On Fri, Sep 14, 2012 at 9:04 PM, Edmund Edgar <ed at avatarclassroom.com>wrote:
>
>> On 15 September 2012 08:16, Dr Ramesh Ramloll <r.ramloll at gmail.com>
>> wrote:
>> > Thanks for the reply Daniel, I am trying to rez region wide ...
>> objects. how
>> > would this relay object work?
>>
>> I made a rezzer for sloodle once like this although we ended up not
>> using it. The objects were rezzed by a little UFO thingy (I called it
>> the "mothership") that would move to where you wanted to rez the
>> object and rez it there, then move back. There are a few ways to do
>> this:
>> a) The user controls the mothership directly - it flies to where it
>> should rez things, then flies back.
>> b) The user interacts with a stationary controller object which sends
>> instructions to the mothership.
>> c) Every time you want to rez something, the stationary controller
>> object rezzes a mothership and tells it where to go and what to rez,
>> and the mothership flies off, rezzes that object and derezzes itself
>> when it's done.
>>
>> The advantage of this approach is that you don't have to put a script
>> in the object you want to rez. But since there's no
>> llDeRezOtherObject(), we ended up needing to put a script in the
>> objects in any case for when we wanted to get rid of them, so it ended
>> up being easier just to rez them where we were and tell them to move
>> to where we wanted them.
>>
>> BTW, one thing to watch out for if you end up telling objects where to
>> move to - at least in SL, probably OpenSim too - is that right after
>> you rez an object (ie when the object_rez event fires), it doesn't
>> always seem to be in a position to listen for and handle messages. I
>> think the issue is that it takes a bit of time after an object rezzes
>> for it to start running its scripts and start listening for messages.
>> So if you need this to work reliably, you probably need some logic to
>> make the rezzer resend the message if the rezzed object hasn't got it
>> yet. (It may be enough just make your rezzer llSleep() for a bit after
>> object_rez fires and hope for the best...)
>>
>> --
>> Edmund Edgar
>> Avatar Classroom
>> Your classroom, on the web, in a virtual world.
>>
>> ed at avatarclassroom.com
>> +81 090 3912 3380
>> Skype: edmundedgar
>> Second Life: Edmund Earp
>> Linked In: edmundedgar
>> Twitter: @edmundedgar
>> http://www.avatarclassroom.com
>> _______________________________________________
>> Opensim-users mailing list
>> Opensim-users at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-users
>>
>
>
>
> --
> 'Consider how the lilies grow. They do not labor or spin.'
> *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate *Research
> Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel:
> 208-240-0040
> Blog <http://deepsemaphore.posterous.com/>, LinkedIn<http://www.linkedin.com/in/rameshramloll>
> , DeepSemaphore LLC <http://www.deepsemaphore.com>, Google+ profile<https://plus.google.com/103652369558830540272/about>
>
>
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-users/attachments/20120915/fac47029/attachment.html>