[Opensim-dev] Parcel Access Enforcement

James Stallings II james.stallings at gmail.com
Wed Apr 16 20:05:09 UTC 2014


Follow-up:

I never did get this issue resolved; indeed, it only got less predictable
in it's manifestation.

I was unable to satisfactorily lay the blame at opensim's feet though;
there were many other issues, and literally nothing we did in the config
files or with the binaries impacted opensim's operation either positively
or negatively as far as this suite of parcel-related issues was concerned.

At this point, we're shifting back to 'known good configurations' that
really don't involve opensim directly (reinstall the boxes, shift to
windows).

I'm very interested to see whether that impacts the the problem at all.

Will update again after the fact.


Cheers
James



On Thu, Apr 10, 2014 at 6:52 PM, Justin Clark-Casey <
jjustincc at googlemail.com> wrote:

> Yeah, there are definitely issues with consistent enforcement of ban lines
> on avatar movement.  I remember looking at that some time ago but
> unfortunately not a simple thing to properly fix.
>
>
> On 10/04/14 18:02, James Stallings II wrote:
>
>> I think the default parcel is definitely an edge case. I created a small
>> completely public parcel in the center of the
>> region, and banned the test avatar outside it; everything works pretty
>> much as one would hope, including the forceful
>> banlines (it even displayed banlines, ugh). But, as designed.
>>
>> There was one problem, seems the av will get stuck to the banlines if
>> s/he attempts crossing them; but a relog fixes it.
>> In all honesty, not the very worst thing I ever had happen when hitting a
>> banline. I'll see if I can figure out why, though.
>>
>> PS I was referring to those elves that left with Bilbo and Frodo for the
>> Distant Shores ;)
>>
>> Cheers
>>
>>
>>
>> On Thu, Apr 10, 2014 at 11:45 AM, Melanie <melanie at t-data.com <mailto:
>> melanie at t-data.com>> wrote:
>>
>>     Why, the elves are still around! I know a couple.
>>
>>     - Melanie
>>
>>     On 10/04/2014 18:43, James Stallings II wrote:
>>      > Mel, cant get a grep on allow_f* anywhere in the source tree,
>> looks like it
>>      > has gone the way of the elves
>>      >
>>      >
>>      > On Thu, Apr 10, 2014 at 11:37 AM, James Stallings II <
>>      > james.stallings at gmail.com <mailto:james.stallings at gmail.com>>
>> wrote:
>>      >
>>      >> I thought I recalled such a thing, been about as long since I
>> looked at it
>>      >> ;)
>>      >>
>>      >> Thanks Mel
>>      >>
>>      >>
>>      >> James
>>      >>
>>      >>
>>      >>
>>      >> On Thu, Apr 10, 2014 at 11:37 AM, Melanie <melanie at t-data.com<mailto:
>> melanie at t-data.com>> wrote:
>>      >>
>>      >>> Yes. allow_forceful_banlines, I believe. Long time since I
>> looked at it.
>>      >>>
>>      >>> - Melanie
>>      >>>
>>      >>> On 10/04/2014 18:33, James Stallings II wrote:
>>      >>> > Quick question (related) is there a configuration point I'm
>> missing that
>>      >>> > enables 'forceful bans'?
>>      >>> >
>>      >>> >
>>      >>> >
>>      >>> > On Thu, Apr 10, 2014 at 11:30 AM, James Stallings II <
>>      >>> > james.stallings at gmail.com <mailto:james.stallings at gmail.com>>
>> wrote:
>>      >>> >
>>      >>> >> I kinder suspected something to that effect. It goes without
>> saying
>>      >>> that a
>>      >>> >> lot occurs during the login process than is immediately
>> apparent when
>>      >>> one
>>      >>> >> sits and watches the consoles.
>>      >>> >>
>>      >>> >> Right now I'm leaning towards the previously-mentioned edge
>> case.
>>      >>> >>
>>      >>> >>
>>      >>> >> On Thu, Apr 10, 2014 at 11:29 AM, Melanie <melanie at t-data.com<mailto:
>> melanie at t-data.com>> wrote:
>>      >>> >>
>>      >>> >>> The QueryAccess is a pre-authorization. So the double call is
>>      >>> >>> intentional and unavoidable.
>>      >>> >>>
>>      >>> >>> - Melanie
>>      >>> >>>
>>      >>> >>> On 10/04/2014 18:14, James Stallings II wrote:
>>      >>> >>> > It would seem that the two invocations of the
>> TestLandRestrictions
>>      >>> >>> method
>>      >>> >>> > in Scene occur in each of NewUserConnection and
>>      >>> >>> > QueryAccess. EventManagerOnAvatarEnteringNewParcel is,
>> fairly
>>      >>> obviously,
>>      >>> >>> > and event callback method; at this point I don't have but
>> a guess
>>      >>> where
>>      >>> >>> > this might be called excepting from
>>      >>> >>> > within EventManagerOnSignificantClientMovement.
>>      >>> >>> >
>>      >>> >>> > I'd like to think that the two calls to
>> TestLandRestrictions in
>>      >>> Scene
>>      >>> >>> might
>>      >>> >>> > be reduced to one; but I'm not yet convinced it is the way
>> to go.
>>      >>> >>> >
>>      >>> >>> > More to follow.
>>      >>> >>> >
>>      >>> >>> > Cheers
>>      >>> >>> >
>>      >>> >>> >
>>      >>> >>> >
>>      >>> >>> > On Thu, Apr 10, 2014 at 10:59 AM, Robert A. Knop Jr. <
>>      >>> rknop at pobox.com <mailto:rknop at pobox.com>
>>
>>      >>> >>> >wrote:
>>      >>> >>> >
>>      >>> >>> >> On Thu, Apr 10, 2014 at 10:25:17AM -0500, James Stallings
>> II wrote:
>>      >>> >>> >> > And FWIW, last I hear adding log statements to code is
>> a valid
>>      >>> >>> >> > tried and true debugging method.
>>      >>> >>> >>
>>      >>> >>> >> I wish to subscribe all of my students in my programming
>> class to
>>      >>> your
>>      >>> >>> >> newsletter.
>>      >>> >>> >>
>>      >>> >>> >> (The number of times I told them to print stuff to figure
>> out
>>      >>> where the
>>      >>> >>> >> code was, and the number of times I told them to print in
>> more
>>      >>> places,
>>      >>> >>> >> was phenomenal.  They got tired of hearing me say it, but
>> somehow
>>      >>> still
>>      >>> >>> >> needed to hear it.)
>>      >>> >>> >>
>>      >>> >>> >> (They often needed similar guidance in figuring out how
>> to use
>>      >>> >>> >> breakpoints in debuggers.)
>>      >>> >>> >>
>>      >>> >>> >> -Rob
>>      >>> >>> >>
>>      >>> >>> >> --
>>      >>> >>> >> --Rob Knop
>>      >>> >>> >>   E-mail: rknop at pobox.com <mailto:rknop at pobox.com>
>>
>>      >>> >>> >>   Home Page: http://www.pobox.com/~rknop/
>>      >>> >>> >>   Blog: http://www.galacticinteractions.org/
>>      >>> >>> >>
>>      >>> >>> >> _______________________________________________
>>      >>> >>> >> Opensim-dev mailing list
>>      >>> >>> >> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.
>> berlios.de>
>>
>>      >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>      >>> >>> >>
>>      >>> >>> >
>>      >>> >>> >
>>      >>> >>> >
>>      >>> >>> >
>>      >>> >>> >
>>      >>> >>> > _______________________________________________
>>      >>> >>> > Opensim-dev mailing list
>>      >>> >>> > Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.
>> berlios.de>
>>
>>      >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>>      >>> >>> _______________________________________________
>>      >>> >>> Opensim-dev mailing list
>>      >>> >>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.
>> berlios.de>
>>
>>      >>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>      >>> >>>
>>      >>> >>
>>      >>> >>
>>      >>> >>
>>      >>> >> --
>>      >>> >> ===================================
>>      >>> >> http://osgrid.org/
>>      >>> >> http://simhost.com
>>      >>> >> http://twitter.com/jstallings2
>>      >>> >>
>>      >>> >>
>>      >>> >
>>      >>> >
>>      >>> >
>>      >>> >
>>      >>> > _______________________________________________
>>      >>> > Opensim-dev mailing list
>>      >>> > Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.
>> berlios.de>
>>
>>      >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>>      >>> _______________________________________________
>>      >>> Opensim-dev mailing list
>>      >>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.
>> berlios.de>
>>
>>      >>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>      >>>
>>      >>
>>      >>
>>      >>
>>      >> --
>>      >> ===================================
>>      >> http://osgrid.org/
>>      >> http://simhost.com
>>      >> http://twitter.com/jstallings2
>>      >>
>>      >>
>>      >
>>      >
>>      >
>>      >
>>      > _______________________________________________
>>      > Opensim-dev mailing list
>>      > Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>>
>>      > https://lists.berlios.de/mailman/listinfo/opensim-dev
>>     _______________________________________________
>>     Opensim-dev mailing list
>>     Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>>
>>     https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>>
>>
>> --
>> ===================================
>> http://osgrid.org/
>> http://simhost.com
>> http://twitter.com/jstallings2
>>
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
> --
> Justin Clark-Casey (justincc)
> OSVW Consulting
> http://justincc.org
> http://twitter.com/justincc
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>



-- 
===================================
http://osgrid.org/
http://simhost.com
http://twitter.com/jstallings2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20140416/15d5f202/attachment-0001.html>


More information about the Opensim-dev mailing list