… 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.

Tags: .NET, C#, LSL, Second Life