Fair enough, tyvm :)
On Thu, Apr 10, 2014 at 11:48 AM, Melanie <mela...@t-data.com> wrote: > 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 > -- =================================== 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