Online Status inSL

Sorry about that. The code was completely rewritten and now uses HTTP-in instead of XML-RPC, retrieves a bit more data from in-world (to be used on future versions), and stores information on the blog itself instead of external files on the upload directory (and even has some caching).

These were simply too many changes, and it was next-to-impossible to make the plugin backwards-compatible with 0.9.X. You will need to go back to your scripted object and drop the new script inside.

Updating to 1.2 will probably get a profile picture by default; change your widget and save again.

1.0-1.2.1 scripts might still work with 1.3.X widgets, but it’s a safer bet to use the new LSL script.

1.3.X scripts should still work with 1.4.X widgets, but you will not get the ability to reset or delete the objects remotely. Pings should work.

This happens when the dataserver in Second Life is slow in responding; there is a limit to the number of successive queries that it replies to. Usually, after the next refresh (every minute or so), it should retrieve the correct status (online/offline) and start working again. Since the in-world object caches entries, this might mean waiting for about one minute for the error to disappear.

Go in-world and touch the in-world object. It should re-register and everything should work fine again. If not, create a new LSL script — using the provided pre-generated one — and replace the old one. The idea is that the API hasn’t changed much, to make sure that old scripts will still work (see the first question in this FAQ), but, alas, I’m merely human and prone to err.

This might happen if you have a very unusual WordPress installation. You’ll have to change the line in the LSL script saying http://_your-domain-name_/wp-content/plugins/online-status-insl/save-channel.php to whatever is appropriate for your blog.

Make sure you really, really have copied it correctly… in some cases, quotes might be changed into typographical quotes; ampersands into \&amp\; or something like that. If all failed, contact me in-world, I’ll give you a copy of the script (you’ll have to change the appropriate URL for your blog though)

Email me at gwyneth.llewelyn@gwynethllewelyn.net, I’ll try to do my best to help, but take into account that some of your configurations might be very tough to debug and I might not be able to help you.

I need more people like you to help debug me this! I have a rather standard configuration at my own server and this works well with my blogs there. But I can imagine that stranger configurations will be harder to debug! Please try to figure out what version of WordPress you’re using, what version of PHP is installed on your host, and if you have writing permissions to the uploads directory under wp-content

This is mostly for security reasons and to prevent users to make serious mistakes. You can use CSS to style your Online Status inSL widget instead; see the section on CSS.

If you deactivate the plugin and activate it again, all internal data with the online status is lost. You will need to go back in-world and touch the objects (or reset them) to send the information back to your blog. Note that the widgets will still be at the same places and keep the overall configuration except for the avatar name they’re bound to.

This should have been fixed now. Just go back in-world and touch your objects to re-activate them on WordPress.

From 1.4.0 onwards, you have more options to delete the status indicators (either just on WordPress, just in-world, or both). Keeping them in sync across plugin versions is a formidable task! Be patient…

This will definitely happen if you have been using this plugin for a long, long time, and have several different versions. To make matters worse, the way the list of tracked objects is stored in WordPress has changed for 1.4.0, so many of your objects might become undeletable. In this case, all you can do is de-install and re-install the plugin, go in-world, and reset all your objects by touching on them.

My apologies. New users have a “fake” last name, “Resident”, which is however never used on profile pictures. 1.3.5 should fix this.

Starting with 1.3.5, you can. A default English (US) .pot file is supplied, so you can tweak it to your own language using POEdit. I’ve added Portuguese and British English as examples. More translations are most welcome!

Note: WordPress multilingual support is currently being done differently (no need to directly tweak .po files), but it requires the WordPress ‘translation team’ to approve them (this is not under my control). See also the developer notes for tags 1.5.0 and 1.6.1.

Essentially, yes. Basically, you can certainly track if an avatar is online/offline on any grid (the tracking code is grid-independent). However, each OpenSimulator grid operator stores avatar profiles differently. This means that you won’t get any fancy pictures, links to profiles, or to location — these are hard-coded to work with the Second Life grid.

If you just wish to have a text message saying “my avatar is online on grid X”, then this plugin will certainly work.

In future versions, the options to extract profile data from OpenSimulator grids might have some extra settings, but it still won’t work with every grid (however, getting the profile picture may be possible). Each grid really does this differently!

NPCs (Non-Player Characters) or ‘bots (automated avatars, controlled by software) are perfectly ‘normal’ avatars from the perspective of the Second Life Grid; they have no more and no less features than human-controlled avatars and are created exactly in the same way. The sole difference is that, instead of a human behind a Second Life Viewer (released by Linden Lab or by a third party, such as the Firestorm Viewer), there is just software ‘speaking’ the network protocol developed by Linden Lab for the communication between the Grid and the Viewers; from the perspective of the Grid, therefore, it has no way of distinguishing if there is a human behind a viewer or merely software ‘talking’ exactly the same protocol, using a popular software development kit such as LibreMetaverse.

Because of that, it’s perfectly possible to track NPCs/bots for their online status, exactly as if these were ‘normal’, human-driven avatars. It’s likely, however, that you’ll need to log in to the Grid as the NPC/bot to properly set up everything as required (i.e. dropping the script inside an object owned by the NPC/bot).

LibreMetaverse works not only for the Second Life Grid, but also for any OpenSimulator-based grid. As such, any NPCs/bots that are set up using a ‘normal’ avatar which gets then driven by software using LibreMetaverse will be able to be tracked for their online status, in a grid-independent way, within the limitations addressed on the above question.

However, OpenSimulator also supports ‘native’ NPCs. This is a feature that Linden Lab could have offered on their Grid as well, but decided not to. Under OpenSimulator, it’s possible to ‘create’ a NPC/bot from a script, which will look exactly like a ‘normal’, regular avatar, but which does not require external software running under LibreMetaverse — you can do it within the environment provided by OpenSimulator itself, using extended LSL functions to directly script avatar-based NPCs/bots. While these can do pretty much everything that a ‘normal’ (human) avatar can, at the database level, they are distinguished from humans by a special flag, which gets set when a NPC is ‘created’, and which will also bind that NPC to a human avatar (i.e. the human avatar running the script creating a NPC will become its ‘owner’). This a way to deal with potential security issues: OpenSimulator NPCs aren’t anonymous, in the sense that nobody knows who is behind it, but rather ‘belong’ to a specific user (and therefore can be flagged for abuse like any other object), and that link is enforced at the core level — it cannot be tampered with using LSL.

This allows, among many other things, to use LSL to ‘detect’ if an avatar is being driven by a human or just by software. It also allows parcel owners to, say, allow human avatars to run scripts on their land, but forbid NPCs to do so. NPCs may be even banned from entering land parcels, whole regions, or even full estates; and grid owners can also ban NPCs altogether (effectively turning off the ability to create and script them), just like on the Second Life Grid.

As such, these kinds of special, native OpenSimulator NPC avatars may fail to be tracked properly regarding their online status. On a fully permissible OpenSimulator grid, it might be possible to consistently get the online status, but it will be tricky — when a NPC goes offline and comes back online, in general, even though it might look the same and have the same name as before, it will have a different UUID (at least, that’s what I think that happens; there might be a way to override that procedure), and, as such, any online tracking script that is looking for a specific, valid UUID will fail — the ‘reborn’ NPC will technically be a different avatar in the database, even if it looks exactly the same. Again, I believe this is done for security considerations. It means that everything that a NPC ‘owns’ is, at best, transient — it will only be ‘owned’ as long as that NPC avatar is online. If it drops out of the grid, and comes back, whatever it has owned is now gone. Also, there is no way for a human to log in as a NPC (and vice-versa: you cannot use an existing account for a NPC; each NPC is created on the spot as a completely new entry in the avatar database), so that means it’s impossible to log in with the NPC’s account (technically, NPC avatars don’t have associated ‘accounts’, even though they certainly have inventory, a profile, worn & attached items, etc.) and write a script to be dropped by the NPC inside an object it owns. This will simply be impossible.

Nevertheless, with some clever scripting, it may be possible to achieve something similar. Because NPCs are created with an inventory — including items worn & attached — it’s conceivable that the avatar may come with a box with a copy of the online tracking script. During creation, that box will be assigned ownership to either the NPC or possibly to the NPC’s owner (depends on the scripting used): in the former case, it’s certainly plausible to admit that the NPC can be scripted to drop that box on the ground once it gets launched. Assuming that the NPC is created on land specifically designed for that purpose, with the proper permissions set (allowing NPCs from a certain group — which can also be set when the NPC is created — to drop objects and run scripts in the parcel), it is conceivable therefore that such an avatar may have an online tracker script active (and therefore its online status being actively tracked!), although it might be pointless: after all, an NPC will either be online or not exist at all (from the perspective of the database!).

In short: aye, you can track the online status of bots and NPCs, if they’re scripted using the LibreMetaverse toolkit; there will be some limitations for OpenSimulator bots (lack of a profile picture, for example); but tracking native OpenSimulator NPCs will very likely not work, or, if it does, it will be essentially pointless to do so.

I’m glad you find it useful. Sure, to make collaboration easier, the code for this plugin is also on GitHub