… and the prototype system is complete.

The XML-RPC Receiver

With the completion of the LSL script which is resident in the object shown above, our prototype XML-RPC communication system is complete. It has served as a proof of concept system, but is not fully developed to serve the needs of the artificial life ecosystem we are planning. However, the code used is easily adaptable to our subsequent uses, or uses you may have for that matter. With that in mind, let’s examine the code. The LSL script is displayed on our website.

The state_entry() event handler in the default state calls the LSL function llOpenRemoteDataChannel(). The server will respond by calling the event handler function remote_data() right below it. This is the same event handler which the server will call later when XML-RPC messages are received by the Linden Server from our offline application., The event handler determines which type of call using a conditional on the value of the integer argument type. When the value of this argument is REMOTE_DATA_CHANNEL, the assigned channel ID is stored, and also transmitted to our website using LSL’s HTTP capability. There the channel ID is stored in a table in our database by the ASP page which is addressed. The offline application accesses that table when it runs to get the channel ID for its message formation.

Note that the state_entry() event handler in the default state is called every time the script is reset, which of course is every time a script is edited and saved when editing with the Second Life viewer. Also, note that in the default state there is an on_rez() event handler. It will be called each time the object is rezzed out of the inventory and it will cause the script to be reset as well.

Once the channel is assigned by the Linden server, and it is receiving XML-RPC messages, it will parse the XML received. It then will call the remote_data() event handler, passing the string parameter and the integer parameter transmitted by our offline application. The LSL script is thus relieved of the requirement of parsing the XML data, leaving that up to the Linden server. As a purely diagnostic check, and to satisfy the requirement that a scripted object must make an XML-RPC reply, the parameters received are simply echoed back. As you recall, the integer parameter is not used in the prototype system, but it must be included in the initial message and the response to satisfy the message format requirements.

Once the parameters are received, they are stored in global variables, and a function is called to distribute the parameters to the AI objects. The two currently identified floating point parameters are still in the CSV string, and would be sorted out by the receiving AI life. Should additional parameters be identified later, they would simply added to the CSV string. This seems simpler, allowing the XML-RPC receiver code to be independent of the eventual number of parameters to be passed,

Note that the parameter values are distributed using the llSay() function. This requires that any receiving AI objects be within 20 meters of the receiver. Considering the size of our ecopod, some sort of secondary distribution system of objects would actually be required to distribute parameter messages to all AI objects so contained.

This completes our series on XML-RPC with .NET and LSL. There is still much to do to develop the AI objects in the ecopod, although that will not be the principal topic in this blog. Instead, we will continue to concentrate on enhancing LSL by adding capability from offline machines using .NET.

We’re Almost Done.

The Prototype Offline Application

The offline C# application shown in the screen shot above is complete and working. The top button causes an access to our database on ZenovkaTek.com which will return the desired parameters for our AI plant scripted object. Clicking the second button will similarly access the ZenovkaTek.com database, this time returning the channel ID. The channel ID is requested by the scripted object on Second Life and transmitted to a page on ZenovkaTek.com which posts it in the database. Of course, we could also just type those values into the text boxes. The real story is what happens when the third button, labeled “Transmit” is clicked. The code for the event handler for the “Transmit” button is posted on our website.

The posted code begins by using the RequestMessage class previously described. An instance is created and fed the channel ID, the two parameter values as a comma delineated string, plus a randomly generated integer value. The latter value is only there because the XML format of the message requires there to be a single integer parameter. The resulting XML message, stripped of all newlines and tabs, is returned by the GetMessageString() method of the RequestMessage class.

The code which follows sets values for the HTTP headers, declaring the method to be POST and the mime type to be application/x-www-urlencoded. Finally, the URL of the Linden server which will receive the message, xmlrpc.secondlife.com/cgi-bin/xmlrpc.cgi, is used in the argument of the WebRequest.Create() method to create an instance of HttpWebRequest. That will initiate the HTTP request. Once the XML-RPC message is written into the HttpWebRequest object’s request stream, and the request stream is closed, the HTTP request can be initiated.

The HTTP request is initiated by calling the HttpWebRequest object’s GetResponse() method. Note that it is called in a try/catch block. You can see in the catch part of the block that there are clearly a lot of things that could go wrong, and the switch statement is there to see which, if any, of these errors would have caused the problem. The cause of an exception, should one be thrown, would be printed out on the status printout.

The Linden server handled the parsing of the incoming XML, extracting the parameters and sending them to the scripted object. As you will see in our next post, the scripted object simply returns any parameters to the Linden server, and the Linden server will formulate the return XML message and send it to the requesting offline application. Our application will then have to handle the parsing and parameter extraction after the response is received. Currently, the scripted object is simply echoing the values it received. You can see in the status readout in the screen shot of the application that what was sent out was correctly echoed back and received.

The XML parsing uses the so-called LINQ to XML axis methods of the XElement class. The return XML looks exactly like the XML which was sent out, except for the name of the root element. Our application sent an XML message with a root element <methodCall> and the return XML has a root element <methodResponse>. Recall from a previous post that the three values transmitted, hence the three values echoed back are (1) the channel ID; (2) the Growth Rate and Average Life Span values concatenated in a comma delineated string; and (3) an integer value thrown in to fill out the Linden defined XML message. Each are contained within a <member> </member> tag pair. Within that tag pair the message is further partitioned into a name and a value as shown in the message exceprt below:

                    <member>
                        <name>Channel</name>
                        <value><string>6df57cf4-68b7-b958-5b6c-10cb9f2fa391</string></value>
                    </member>
                    <member>
                        <name>StringValue</name>
                        <value><string>6.35,1.58</string></value>
                    </member>
                    <member>
                        <name>IntValue</name>
                        <value><int>1413957003</int></value>
                    </member>

Parsing is additionally complicated by the fact that each member value is further encapsulated in a tag pair which declares the data type of the value. Additionally, our code must separate out the Growth Rate and Average Life Span values which must be returned as a comma delineated string. Once that is done, the result is printed on the status readout as you can see in the screen shot at the beginning of the post.

The LSL script is complete to the extent that it requests a channel ID, receives the parameters passed to it by the Linden server, and correctly echoes them back to our offline application. We have a few more things to do with the script, and the scripted object in which it resides, and will post that information next time.

Our next post will complete the prototype phase of the project, and illustrate the various techniques necessary to use XML-RPC with LSL scripted objects on Second Life. There will still be quite a bit to do with the AI objects, as we will show you in subsequent posts.

… and the problem is solved!

The page posted on our website has been corrected. There were actually two problems. The first was that the XML message was not well formed. Notice that each of the parameters in the message should be bracketed with tags indicating the data type. The original LINQ to XML code in C# failed to add those tags, so not surprisingly, the Linden server’s parser rejected it.

The second problem was that the XML string returned by the XElement class ToString() method neatly adds tabs and newlines so that the XML looks good when printed out. Unfortunately the Linden server’s XML parser chokes on the resulting string. Adding a couple of lines of code removing the tabs and newlines results in one long string, but makes everything work just fine.

The class as you now see it is working in a prototype C# application which is correctly transmitting XML-RPC to a scripted object and is receiving an echo of the parameter values being returned by the scripted object from SL. We will show you the LINQ to XML code which parses the return message and the completed LSL script probably during or before the weekend.

Opps!

Further testing has determined that there is an error in the code we provided for the class which creates the XML-RPC message to send to the scripted object. It will get fixed as soon as possible, and the correct code will be posted.

Using LINQ to XML

Our next installment describing the implementation XML-RPC shows how to create the XML-RPC request message using LINQ to XML. The WordPress text editor is a bit unsuited for proper display of code, or XML for that matter, so we have posted the page on our website . We show the XML format of the request message together with the C# class which produces it. Coming next will be the C# code which will perform the HTTP to get the request message to the scripted.

Once we have the message on its way to the scripted object, the focus switches to LSL as we show how the message is handled. The Linden server will parse the XML and simply return the arguments to the script. The script will provide a return message which the Linden server will format into an XML reply message. To complete our work, we will show how LINQ to XML will parse the message and get the data which is returned.

… And, We’re Back.

The problem we experienced with our online database at 1and1.com seems to have vanished, at least for now, meaning that our search for a more reliable provider of web space can be done at a more leisurely pace. Now the intent is not to let this blog degenerate into a tirade about the unreliable service 1and1.com can provide. There are, however, a couple of closing notes.

Some earlier posts mentioned 1and1.com in a more or less favorable light. Now that their motto is, “When tech support seems to be needed, seem to provide it”, we don’t want to be thought to be promoting 1and1.com in any way, or giving the impression that we are satisfied with their service.

Finally, a bit of irony. The problem encountered was that the 1and1.com page where one administers the database would never load. This morning, 1and1.com sent an email inviting us to take a survey on how well tech support helped. The email provided a link to a 1and1.com page where the survey could be taken. Unfortunately, that page would never finish loading.

There Will Be A Slight Delay

The series of pages on LINQ will have to be put aside for a few days.  We were using LINQ in conjunction with a project on Second Life in which some AI scripted objects were being created on our parcel.  Several aspects of that project required the use of our online database at 1and1.com.  Unfortunately, we have suddenly become unable to access the database, and the clueless support folks at 1and1.com have absolutely no idea how to fix the problem.  Until we can get a new webspace provider, we will have to put that project on hold.  We will be shopping for web space during the next few days and hope to get moved to where databases work by the middle of next week.

We do have a working C# class which uses LINQ to XML to create the XML-RPC request to send parameter values to our AI objects, and will be publishing that code some time during the coming week.

The First XML-RPC Installment Is Posted

As promised, we now have up the first page in the series of using .NET and XML-RPC to talk to LSL scripted objects.  XML-RPC is not universally favored among LSL scripters.  It tends to be slow, and you have to be careful not to overrun your posts.  Our experiments indicate that you should allow 2-3 minutes between transmissions to insure that you don’t overwrite a previous one which has not been fully processed yet.  We will look some better methods later when we start working with the libsecondlife .NET assembly.

Getting Ambitious: Talking to Scripted Objects using XML and LINQ

We’re starting our first major project, and it will comprise activities in our two major areas of effort. We’ll take some of the latest .NET Framework technology, and use it to augment our SL experience. The work is a continuation of some things we were involved in in the Second Nature 3 sim, in which various scripted objects were created as artificial life in an inter-related ecosystem. There, a series of AI creatures fed on each other, and on some AI plants. In our new Ecopod, we are only going to have a single plant type, and it will be fed upon by a single type of bug. We will start with the plant.

The XorLabs Research Ecopod

The plants, and eventually the bugs, will be deployed in the Ecopod. To maintain an ecological balance, the parameters of the bugs and the plants must be at a proper set of values, and that will ultimately be determined by trial and error. An offline .NET application will transmit adjusted values as the number of plants and bugs begin to grow and the balance is observed over the course of time.

As parameter values are adjusted, the latest set will be inserted in a SQL Server database instance running on the same computer as the offline application. The offline application will access the database using LINK to SQL. Then, it will create the corresponding XML-RPC command using LINK to XML, and send it to the plants and bugs within the Ecopod. That’s the general overview, now lets look at some specifics.

A Few Words About LINQ

LINQ is short for “Language Integrated Queries”. It is implemented in the versions of C# and Visual Basic which ship with Visual Studio 2008. Several language extensions have been added to make LINQ work. We’ll be using C# for this. Having bought Visual Studio 2005 just last year, there is little inclination to buy VS2008 this soon. No problem though, since Visual Studio 2008 Express has everything we’ll need, and since it is free, you can’t be the price.

Using LINQ, you can just drop SQL like query strings right in the middle of the C# code. In the pages to come, we won’t try to give a full tutorial on LINQ, but there should be enough code shown to get your curiosity and ambition aroused so that you will go out and learn it for yourself. Of course, any code posted is free for you to use or modify as you like.

Using XML-RPC With Linden Scripting Language

The LSL Wikki has some detailed documentation on how to implement XML-RPC in a scripted object. As you will see, the LSL script must first contact the Linden server to get a channel assignment. Once the channel number is returned, it must be transmitted it to the offline application. Once the offline application has the channel number it can construct the XML command and send it via HTTP to the scripted object. The scripted object can reply using HTTP to send a response to the offline object.

Rather than try to get each and every bug connected to an XML-RPC channel, we’ll have a single object that receives the transmissions from the offline application. The scripts in the plants and bugs will listen on a non-zero chat channel to get the parameter values relayed to their respective scripted objects.

We’re going to introduce what some may consider an unnecessary complication to get the channel number to the offline application. We’d like the offline application to automatically get the channel number without having to have the scripted object acquire it and email it. Then we won’t have to get it from email, and enter it in a text box. Rather, we’ll have the scripted object which performs the SL side of XML-RPC acquire the channel in its on_rez() event handler, then use HTTP to send it to an ASP page on ZenovkaTek.com, with the ASP page inserting it into the SQL Server instance there. Then, the first thing the offline application will do when it starts will be to access the ZenovkaTex.com database with HTTP to get the channel number. This way it’s all automatic and requires no additional action to get the communication link enabled. More on this, and the rest of the XML-RPC part in due course.

The Project In Three Phases

The first phase, and the subject of the first page on the project, will consider the various parameters which will be needed, how they are stored in the SQL Server instance on our offline computer, and how LINQ will access them. Phase II will be involved with using LINQ to XML to create the XML-RPC command and insert the data acquired from the database. In the final phase, we’ll show how to send the XML-RPC command to the scripted object in the XorLabs parcel in SL. Look for the first page in about a week.

What Never Was, What Is, And What Is To Come

First, briefly, What Never Was

If you Google XorLabs you will find a reference to this blog, plus plenty of stuff in Italian refering to some other Xorlabs. Even with my modicum of Spanish we Texans tend to acquire, I still can’t make head nor tail of it. The short answer is, “It aint us!”

Now, for What Is

We have two technical papers posted now. The most recent deals with LSL scripted objects sending data to remote databases. A subsequent paper will describe getting data back.

But mostly, What Is To Come

We’ve gotten a little crazy and acquired a lot of land in the Green Goblin sim, and building is going to start in the coming week. There are plans for three wings to the building. One will eventually house some office space and a conference hall. The other two will house some planned research projects.

One of the two additional wings will be devoted to robotic research. Our new android will be controlled remotely with a .NET framework application with the libsecondlife library assembly at its core. The newest addition to the XorLabs Research group, AndroidXLR1 will be learning how to get around the research facility and do wondrous things.

The other of the two wings will house our EcoSystem, which will be a small version of the one found in the Second Nature 3 sim. Lots of AI plants and animals will be vying for their respective places in the food chain. LSL will be handling the bulk of that, but some of the work will be offloaded to a remote website, and statistics will be kept in the SQL Server instance there. The remote website will be posting statistical reports on how the ecosystem and its inhabitants are faring. Once everything gets going, you’ll be able to go inside and see the bugs and plants close up, but you will have to teleport in and out. As we found on Second Nature 3, the bugs tend to get out and infest neighboring sims.

So, stay tuned …

As soon as there is stuff to see, we’ll post it here.