Further SLurling and some Speculative Placeholding

I was, a little while back, alerted by Ms Torley Linden to the fact that there are residents wishing to use the SLurl as a tool when referring to places in Second Life, but finding it awkward, slow or otherwise inconvenient to do so via the web form. I have thus built a small item that should help - something I call a “slurlchatter”.

This is simply a HUD device that sits there and, when touched, will tell you a SLurl for your current location. One merely then has to cut and paste this SLurl into whichever document one is creating. It can also be commanded by speech - say “/121 Caledon,128,128,128″ and it will give one an appropriate SLurl for that specific place. It is available for free from SLExchange or SLBoutique, or, as usual, from my humble establishment in Caledon.

Another item that I have been working on, I am in something of a quandary regarding. With the removal of the “PVP Abuse Tool” within Second Life there has been some demand for alternatives; a collision sensor has been released for free by Babbage Linden, but of course one problem with collision sensors is that they only respond to actual collisions.

For those unfamiliar with the workings of push weaponry in Second Life, I proffer a short explanation. The function used to send the target flying will almost always be llPushObject, regardless of the workings of the gun in question. Some (the simpler) pushguns fire a projectile which, upon collision with a target, uses llPushObject. These projectiles are fairly simple to detect as a physical collision is required, which triggers the collision_start() event - the keys of the objects colliding can be gathered and the names of their owners found.

However, other weapons use llPushObject without a collision being required, say from a phantom object or just from the weapon itself, and the action of these cannot be directly detected. There is no on_push() event. Therefore it is currently impossible by means of scripts to tell who has used such a thing on one.

I decided that I would attempt to produce an item which took this into account and at least provided some information to help one track down the culprit. The result is a device which records collisions with scripted objects, but also monitors one’s position and the names of all avatars within ninety-six metres. Should one suddenly move fifty metres or more in one second, the device concludes that one has been maliciously pushed, and triggers, listing the names of everyone around, the owners of all scripted items that collided in the last second, and giving an option to teleport back to one’s previous position via llMapDestination. This does not actually tell you who has pushed you but if someone you have never heard of just turned up in the area, it may well have been them.

The distance threshold is useful, preventing false positives from simply walking into a tram or similar, and I think that the “teleport back” function is handy as well, allowing one to return to normal almost immediately (provided that the sim allows P2P teleportation). I do have issues with the scanning function though. Clearly scanning once per second with a 96m range is not awfully good in terms of lag, and whilst in an emptyish sim it is not too bad, in a crowded one with many people using such things it could be both environmentally hostile and useless. In a crowded club or shop, where such attacks often take place, who can tell who an assailant might be?

I am therefore thinking of removing that function before placing the device out for distribution, though perhaps I will simply have two versions, one with sensor and one without. In any case I am fairly confident of its efficacy, as long as the world is operating correctly, which it does not always. I had a devil of a time trying to test the device. First of all I was entirely unable to find anyone who would push or shoot me, and had to actually go up to people and ask them if they wouldn’t mind doing so, which is not a proper test. Even once I had located a willing collaborator, we found that collisions were being routinely ignored, scripts not updated with correct positions and in some cases bullets hitting their owner. Invulnerability can be exceptionally frustrating.