The setting is still there. It is defaulted to true and the code to set it from files has been removed and is dead. So bans should be forceful.
- 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.stalli...@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 <mela...@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.stalli...@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 <mela...@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. < >>> rk...@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: rk...@pobox.com >>> >>> >> Home Page: http://www.pobox.com/~rknop/ >>> >>> >> Blog: http://www.galacticinteractions.org/ >>> >>> >> >>> >>> >> _______________________________________________ >>> >>> >> Opensim-dev mailing list >>> >>> >> Opensim-dev@lists.berlios.de >>> >>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >> >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Opensim-dev mailing list >>> >>> > Opensim-dev@lists.berlios.de >>> >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> _______________________________________________ >>> >>> Opensim-dev mailing list >>> >>> Opensim-dev@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@lists.berlios.de >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev@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@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev