On Nov 12, 2008, at 10:20 PM, Jani Pirkola wrote: > reX authentication works by xmlrpc calls that are completely outside > libsl/libomv. As far as I understood, reX has only ever changed libsl > due to a few (deprecated) binary packets (media urls & sky box info)
also there was a small change in the login procedure (the response from server was modified about a year ago to overcome a NAT issue) but right, the authentication is separate. so the question is how it and starting a session with a rex sim is tied together when using libomv. i'll be at the Admino office tomorrow and will go through this with someone who knows, to understand whether it could result in a sensible patch to libomv. am thinking that if the rex auth stuff is implemented in some kind of a module, it /might/ be nice that libomv could use that for authentication when logging into Rex, so it would be transparent for some basic bot or other client that uses libomv whether it's logging into SL / vanilla OpenSim or Rex. if there is e.g. a parameters file for such an application with the address of the target system and login credentials, it could support a syntax that differentiated the authentication mode, based on which the library could select the appropriate procedure. i guess the other option is that libomv apps that want to support Rex would first use the authentication system directly themselves, and then pass the information from there to libomv. so the question is whether that is seen as good enough, or would hiding the differing procedure under the hood of libomv be better. i expect to learn that tomorrow :) > Jani ~Toni > 2008/11/11 Hurliman, John <[EMAIL PROTECTED]> >> >> We've been running into this a lot recently (supporting protocol >> modifications), and it's mostly dependent on how much additional code >> has to be supported to achieve compatibility. If the new code path is >> a relatively small change, or can be cleanly isolated for the most >> part into a new code file it makes things much easier. Either way if >> you submit it to the libomv JIRA we can try and get it applied to >> trunk. >> >> John >> >> -----Original Message----- >> From: realxtend@googlegroups.com [mailto:[EMAIL PROTECTED] >> On Behalf Of Toni Alatalo >> Sent: Monday, November 10, 2008 11:36 AM >> To: realxtend@googlegroups.com >> Subject: [REX] Re: Bots/NPCs >> >> >> Hurliman, John kirjoitti: >> > Is support for the rex authentication system incompatible with >> support for the LL auth? I'm wondering why this was kept as a fork >> instead of a patch for libomv. >> > >> >> depends what you mean with 'incompatible' - the process is quite >> different, as Rex is using separate user/agent servers for >> authentication so that it first gets a token from the user server and >> then passes it on to the sim, unlike the classic LL way where the >> client >> just sends the login request directly to the server. >> >> i guess it could be special cased in libsl/libomv, meaning it would >> be a >> mode / option and the login procedure would be selected based on >> whether >> LL or Rex is used. the reason for not sending such a patch upstream >> was >> i think just that we did not think there would have been interest >> for it >> back then, dunno what would be the case now. >> >> in any case i think, and did promote the idea back then too, that >> having >> a libsl/libomv like library for making clients, 'librex' you could >> say, >> is a nice asset to have. if it could be merged as an option in the >> main >> tree upstream, all the better. >> >> > John >> > >> >> ~Toni >> >> > -----Original Message----- >> > From: realxtend@googlegroups.com >> [mailto:[EMAIL PROTECTED] On Behalf Of Toni Alatalo >> > Sent: Monday, November 10, 2008 4:50 AM >> > To: realxtend@googlegroups.com >> > Subject: [REX] Re: Bots/NPCs >> > >> > >> > Ryan McDougall kirjoitti: >> > >> >> I dont believe there is any headless client currently, but I >> myself >> >> see a LOT of potential use cases for one, so I am working hard to >> get >> >> something like that available with Rex. >> >> >> >> >> > >> > just for the record, there is/was such a headless client system >> > specifically tailored for running bot scripts, called the 'avatar >> > process server' (apc). it uses/d a modified version of libsl to >> work >> > with the rex authentication system, and used ironpython hosting to >> run >> > several such bot clients, managed via a simple gui. i worked on it >> last >> > year and Matti ported it to the (then) new avatar/authentication >> system >> > in last February, but I don't know about the current status. >> > >> > anyway for making your own worlds, for games or machinima or some >> > application, it makes a lot more sense to use server side >> scripting like >> > the new rexbot now does. not only does it reduce networking and >> server >> > overhead, but i believe it also enables much more straightforward >> > programming of coordinated / group behaviours etc. as the different >> > agents can easily share info, know everything about the scene etc. >> > >> > the 'apc' is/was targeted for a different use case, where you'd >> want to >> > visit any worlds but be able to enable own automated behaviours, >> > especially ones integrated to to your own systems at the bot >> client end >> > (a proof of concept of this was a receptionist bot, that would sit >> on >> > any server, and relay chat messages forward using e.g. a corporate >> sms >> > gateway to which the bot server could be connected to, but to >> which not >> > any random region server out there in the world could not talk to). >> > >> > ~Toni >> > >> >> Cheers, >> >> >> >> On Fri, Nov 7, 2008 at 1:22 PM, [EMAIL PROTECTED] >> >> <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >>> Hi, >> >>> >> >>> Bots/NPCs can be a powerful way to make your virtual world come >> alive >> >>> without any users, as well as a good way to do machinima without >> >>> needing to be an extreme multitasker or use other people's time. >> >>> >> >>> I was wondering whether there was a no-visuals client to run >> these, or >> >>> if something like that would be easy to generate. Ideally, it >> would >> >>> allow bots to be scripted (sit somewhere, walk from >> a->b->c->b->a- >> >>> >> >>> >> >>>> etc) or perhaps even link them up to an external chatbot. >> >>>> >> >>>> >> >>> Thanks, >> >>> Doeko >> >>> >> >>> >> >>> >> >>> >> > >> > >> > >> > >> > > >> >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/realxtend -~----------~----~----~----~------~----~------~--~---