I am working on an LSL (Linden Scripting Language) Script to be included in Radios and TVs to be distributed in-world to users within our specific community. The Radios & TVs will 'tune' the users land audio or media to a selected station via a menu. The URL's of the stations change regularly, especially during our 'special events', up-to once per hour at the top of the hour (for DJ handovers). To make the Radios and TVs work grid-wide, the URLs for the station streams will be updated to a cloud database every time they change. The Radios and TVs will query the database to check if the stream URL has changed every hour, but to prevent the database being flooded with queries at the same time, I want to create a random element, so the Scripts query the database for a changed URL at a random timeframe between a window of 2 minutes and 5 minutes past every hour. I have the database storage and retrieval syntax, but can anyone help with the LSL Script syntax to achieve the random time window trigger for the database query between the window of 2 mins and 5 mins past every hour?
2 Answers
I would suggest to pull in location data from the rezzed objects, for example the x-, y- and z-position within the region to build a semi-random element. Another (or additional) approach would be to turn the UUID of the owner into a semi-random number, but that only works if each object is owned individually, and not many objects owned by few people. If that is the case, combine my two methods.
Turn the result into a float and use llSleep() for the delay.
- 1
- 1
You don't clearly explain it, but I assume that the cloud database is running on a (virtual?) server you've got access to?
(It's possible to do an in-world 'database', thus my question)
An alternative to @peter-stindberg's answer (I know it's been half a year since the OP asked the question) would be to let each object register its own HTTP-in handler (with llHTTPRequest), and, instead of being the object triggering the change every hour, it would be the database server to communicate with the many Radios/TVs in-world, and tell them to change their stream URL.
That way, you have precise control over the communication: you could simply grab the list of registered objects, and, sequentially — one by one — tell each to change their stream's URL. Assuming that it's the same streaming URL for all, that would be just one database query for the URL, plus one database query to get the current list of in-world Radios/TVs, and you can just fire a HTTP-in request every second or so (or space them out further if you are afraid of flooding SL with incoming calls!). In any case, you get a lot more control that way — specifically, you will only inform the Radios/TVs when the URL actually changes. Assuming that this only happens rarely, the Radios/TVs will mostly be 'sleeping', awaiting an incoming request, and that's it.
Of course, you'll need to do some further processing on the database's side to handle the Radio/TV registration. Another assumption: if you're familiar with PHP, you're welcome to take a look at my 'Online Status inSL' WordPress plugin. Even if you're not familiar with WordPress, the registration logic should be obvious (also, the WP plugin requires in-world objects to work, and a script is provided, which the user is expected to drop on their in-world object). There are a few 'useful' options, such as the ability to send a 'ping' command (just to make sure the in-world object is 'alive', i.e. it hasn't been deleted, or its scripts turned off, or moved to a non-scripting area), as well as commands to self-destruct the prim where the script is located, etc. Such features might also be useful from the perspective of whatever backoffice you've got to deal with things on the server side (where the database is running).
A further advantage is that, on the server side, you will know exactly who is using your system and where they have placed their Radio/TV (useful if they forget where it is!). When a user leaves the community, you can easily remove their ability to continue to use the Radio/TV, simply by refusing that particular object to connect. You can even do something like the following: when the object rezzes, in theory, it'll launch llHTTPRequest to get its own URL, and attempts to contact the remote database server. If it's on the 'deny service' list, the server may just send it a command to delete itself (via llDie). Now, obviously, the resident may have lots of copies of the Radios/TVs (just in case something goes wrong), but every time they'll try to rezz one of the copies, it will auto-delete itself... so it'll be pointless to try (of course, the resident can rezz the Radio/TV on a no-script zone, and that means it won't get the self-destruct command, but... it won't get a valid streaming URL either).
I'm just giving you these 'extreme' examples because, in the past — the very, very distant past! — I used to have a few items that worked that way: I wanted to limit the number of times they could be used (say, in your case, imagine that the first 20 URL changes are free, but the next will be charged at L$1 each — to offset the costs of running the database server). You can do it with LSL, to a degree (because LSL scripts keep track of their state, even when given to others), but sometimes scripts can get reset, either by their owners, by a permission bug, or a region that gets rebooted... and then you lose that information. Storing the number of times the object has actually been used on the remote server is the safest way of making sure that nobody can tamper with it from inside SL.
Plenty of crazy things can be accomplished that way :-)
P.S.: In case you're wondering, communications between SL and external servers are very fast — much faster than any other form of communication inside SL, except for link messages (which are the fastest communication form possible — but they're limited to the distance you can link prims together!). Even a full round trip — contacting a remote server, waiting for it to answer, requesting some information, waiting for the request to complete... — is much, much faster than any other in-world alternative. It used even to be possible to track things like bullets being fired and colliding with avatars, in 'quasi-real time', by using offworld communications. Linden Lab, however, put a lot of throttles in the system to avoid all possible kinds of abuse; but, in your case, if properly done, you won't have any issue with those throttling limits.
- 796
- 1
- 11
- 27