Alternative Communications
There are many alternatives to the traditional (XML/Email/Chat/Link Message) way of communicating between two scripts. This page was created to facilitate the discussion of these alternatives.
Parcel URLs
By setting a land's music or video stream URL (via
llSetParcelMusicURL and
llParcelMediaCommandList) it is possible to communicate information to out-of-world servers. By setting the URL to something like
http://myserver.com/test.php?foo="bar", when a user's avatar passes over the land in question, his or her client will invoke the URL and send the data "bar" in a variable "foo" to test.php. This can be used as an alternative to email for transmitting XML-RPC channel keys, for example.
PHP example:
Needs an URL like
http://myserver.com/test.php?command=Hello
<?php
if ( isset($_GET['command']) {
$fh = fopen('log.txt','a');
fwrite($fh,$_GET['command']);
fclose($fh);
}
?>
ASP example:
Needs an URL like
http://myserver.com/test.asp?command=Hello
<html>
<head>
</head>
<body>
Command: <b><%=request.querystring("command")%></b>
<br>
<% if request.querystring("command")= "Hello" then %>
Hello World
<% else %>
Nothing..
<% end if %>
</body>
</html>
Disadvantages:
- An avatar must be on the parcel for the data to be transferred.
- Cannot be used to communicate directly from object to object in-world.
llKey2Name
llKey2Name and
llSetObjectName can be used as a way of communicating 255-character
strings between multiple objects within the same
simulator. Each "listening" object knows the "broadcasting" object's key, and repeately calls llKey2Name, noting any changes in the broadcaster's name. When the broadcaster wants to send a message, it simply changes its name to the message it wants to send.
Don't use this, email is much more reliable.
This can be used to feed data into an infinite loop in a touch event to enable llMapDestination, a sick way around a stupid restriction -- BW
In the past I used this for a score board with a FPS, the game tracker on the avatar would keep track of user status, and would dump that to a prim name; then the score board would just poll that key whenever it wanted to update. Very efficiant, very secure, very fast. -- BW
Disadvantages:
- Requires listeners to use a timer event or infinite loop to receive messages. (CPU-intensive)
- Complex to ensure reliable communications - listeners may miss a message if the broadcaster changes its name too quickly.
- The name field of the broadcaster object cannot be used descriptively. If your broadcaster is a blender, for example, it cannot be named "Blender" - the listeners would interpret "Blender" as a broadcasted message. (Dont ask how I came up with blender. :-))
llRemoteLoadScriptPin
llRemoteLoadScriptPin can be used to communicate between objects in the same simulator. A script rigged to call
llMessageLinked in
state_entry can be transferred to a properly set up object (see
llSetRemoteScriptAccessPin). The newly transferred script will trigger the
link_message event in the receiving object's scripts. This allows objects to transfer information without using a timer or external servers.
Disadvantages:
- Significant script delay triggered when calling llRemoteLoadScriptPin.
- Message cannot be dynamically generated - it must be hardcoded in the transfer script. (I think)
- Objects cannot broadcast using this method - the sending object must know the receiving object's pin and both objects must be modifyable by the owner of the sender.
- If the receiving object's pin is found by a malicious scripter, they can do Very Bad Things.
Notecards & llGiveInventory
Like the above,
llGiveInventory can be used to transfer data without using a timer. The inventory transfer triggers the
changed event in the receiving object. To obtain the information on the new notecard the receiver can call
llGetNotecardLine.
Disadvantages:
- Like the above, the message cannot be dynamically generated - it has to be written in the notecard beforehand.
- There are several difficulties when broadcasting:
- The significant delay incurred by calling llGiveInventory.
- Each receiving object's key must be known by the broadcaster.
- Each receiver, if not owned by the broadcasting object's owner, must call llAllowInventoryDrop(TRUE).
- The changed event does not report the dropper/sender of the inventory, therefore malicious persons can drop inventory in the receiver (if llAllowInventoryDrop is enabled).
Communications