The only code I'm affecting the local copy on my server; it isn't as if I'm going to break break the central repo back to 2006. Hell, I don't even have commit. And FWIW, last I hear adding log statements to code is a valid tried and true debugging method.
On Thu, Apr 10, 2014 at 10:23 AM, Melanie <[email protected]> wrote: > I'm not even being defensive. I just don't like the idea of poking > code with a sharp stick instead of debugging it properly. > > - Melanie > > On 10/04/2014 17:20, James Stallings II wrote: > > "Maybe a good starting point is to see what you would like that doesnt' > > work before you go and fix things that..." > > > > Actually, that *is* where I began. > > > > My user reports various failures, which are repeatable on the running > > regions. No amount of reconfiguration predictably affects the experience > on > > the regions. > > > > We do have a couple of regions that seem to work perfectly, including > that > > which I'm working with; it started working after I completely replaced > the > > OpenSim.ini with one that was identical excepting the http_listener > > specifcation. Unfortunately, repeating this process with the same > > OpenSim.ini on a different region that doesn't work did not produce a > > region that does. > > > > To say that it works intermittently is a bit of an understatement; though > > it does seem that once it begins working it continues to do so. > > > > > > Try not to be so defensive Mel; I'm not attacking you or your work, I'm > > just attempting to figure out what's happening on these regions. I have > > eliminated everything I can find but the code, which I am told by others > is > > not to be trusted as fully functional; and I am not afraid to get in and > > get my hands dirty. > > > > > > Cheers > > James > > > > > > > > On Thu, Apr 10, 2014 at 10:10 AM, Melanie <[email protected]> wrote: > > > >> The code for parcel access works, as far as I'm aware. It was > >> originally fixed in Avination and that should have been donated to > >> OpenSim a long time ago. Maybe a good starting point is to see what > >> you would like that doesnt' work before you go and fix things that > >> aren't broken. > >> > >> Melanie > >> > >> > >> On 10/04/2014 17:05, James Stallings II wrote: > >> > Subsequent work (instrumentation to Scene) shows that the permissions > >> > checking code is also being called twice there. > >> > > >> > Cheers > >> > James > >> > > >> > > >> > > >> > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II < > >> > [email protected]> wrote: > >> > > >> >> After some further exploration, I have seen where the method calls > >> taking > >> >> precedence from out of Scene are handling ViaLogin; but they are also > >> doing > >> >> some of the same lifting performed in the Land Management module. > This > >> >> seems to be duplication of effort, if not duplication of code; and is > >> >> certainly less elegant than I would hope to find in our codebase (in > an > >> >> ideal world ;) > >> >> > >> >> This is likely the result of the ad-hoc nature of the development > life > >> of > >> >> the project over the years; I can see the scene code being a good > deal > >> >> older than the Land Management module. > >> >> > >> >> I'll be working with this throughout the day, hoping to improve the > code > >> >> as I'm able; your thoughts, advice and commentary are solicited and > >> >> appreciated. > >> >> > >> >> Cheers > >> >> James > >> >> > >> >> > >> >> > >> >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II < > >> >> [email protected]> wrote: > >> >> > >> >>> Greetings Devs :) > >> >>> > >> >>> I have a use case that requires the unlikely and less than popular > >> parcel > >> >>> permissions access control featureset. > >> >>> > >> >>> Historically speaking, this has not been an area of development that > >> has > >> >>> seen much love, and understandably so; none of us are particularly > >> >>> interested in fully duplicating the operational envelope of the > Second > >> Life > >> >>> experience. That coupled with the ability to deploy regions at whim, > >> it is > >> >>> no wonder no one wants to involve themselves particularly deeply > with > >> >>> making this work properly. > >> >>> > >> >>> That being said, I have a need at present, and there is also the > simple > >> >>> fact that we have a dearth of UI components in the viewer we may > well > >> never > >> >>> get shut of, and a lot of of unfinished and/or unpolished code in > the > >> repo > >> >>> that touches on this functionality. > >> >>> > >> >>> The short story is, it may be above the waterline, but there is a > hole > >> in > >> >>> the boat, and one of my users is driving it headlong into the surf. > >> >>> > >> >>> So much for metaphors. > >> >>> > >> >>> I have heard a variety of conflicting reports about the state of > this > >> >>> part of the codebase; some say it works well; others say it should > not > >> be > >> >>> counted on to work at all. The commit logs tell the tale that some > have > >> >>> taken an interest and are working diligently to eliminate certain > bugs; > >> >>> unfortunately, the work in progress has not yet brought the > >> functionality > >> >>> into a state where it is yet useful, at least according to my > testing. > >> >>> > >> >>> I'm not unwilling to undertake the work needed to bring this > situation > >> >>> into a more satisfactory light; indeed, I've already begun, and I > need > >> only > >> >>> a little guidance today. > >> >>> > >> >>> I have thoroughly instrumented the method "public void > >> >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int > >> >>> localLandID, UUID regionID)" > >> >>> in the land management module, and was immediately confronted with a > >> >>> couple of surprises: > >> >>> First, when the code is called at all, it is called twice; and as > far > >> as > >> >>> I can tell, it is called only after a successful login has been > >> completed. > >> >>> Neither does it seem to be called when an avatar teleports into the > >> region. > >> >>> > >> >>> Instead, the method "public bool TestLandRestrictions(UUID agentID, > out > >> >>> string reason, ref float posX, ref float posY)" is called from > >> >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and > >> >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates > >> (rather > >> >>> less than consistently) whether the avatar is allowed into the > parcel > >> on > >> >>> the region. > >> >>> > >> >>> Being aware that there are several ways for an avatar to enter a > >> parcel, > >> >>> which I will leave off enumerating at present, I would suggest that > >> perhaps > >> >>> I have some misapprehensions as to the proper stages of > authentication > >> at > >> >>> login-time. > >> >>> > >> >>> So my question is this: should both of these functions come into > play > >> as > >> >>> an avatar enters a region (and consequently, a parcel)? or should > >> there be > >> >>> a single methoid conducting these presence permission checks? > >> >>> > >> >>> Please advise at your convenience :) > >> >>> > >> >>> Many thanks and cheers > >> >>> James/Hiro > >> >>> > >> >>> > >> >>> -- > >> >>> =================================== > >> >>> http://osgrid.org/ > >> >>> http://simhost.com > >> >>> http://twitter.com/jstallings2 > >> >>> > >> >>> > >> >> > >> >> > >> >> -- > >> >> =================================== > >> >> http://osgrid.org/ > >> >> http://simhost.com > >> >> http://twitter.com/jstallings2 > >> >> > >> >> > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Opensim-dev mailing list > >> > [email protected] > >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >> _______________________________________________ > >> Opensim-dev mailing list > >> [email protected] > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > > > > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- =================================== http://osgrid.org/ http://simhost.com http://twitter.com/jstallings2
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
