Physics

Some time ago, I made some concerted enquiries regarding the two major systems that are used for “Role Playing” upon the Grid, with the intention of writing a piece in my Journal on the subject, with special attention to the interests of Gunsmiths. As is typical, it has turned out that I have entirely failed to do the latter, and in fact, others have written pieces far before me - see, for instance, Mr Onder Skall’s excellent piece in New World Notes.

Regardless, the time has come to put my effort to some purpose, even if it is not terribly informative. Herein are contained certain Notes of interest to those wishing to produce Weapons for use within areas which use either the DCS2 or CCS systems.

There are two distinct classes of weapon: ranged and melee. For those wishing to damage people at range, the firing of a physical projectile will achieve this. Said projectile must be travelling at over 17.5m/s at impact, which quite frankly most bullets are. This causes a standard flat amount of damage.

Close combat weapons, to be used in a melee, are detected by means of control inputs. The attachment that each participant wears detects the appropriate controls and launches an attack based on that, so all that a manufacturer of weapons really needs to do is have a weapon which animates and activates when the mouse button is held, and a movement control is pressed (excluding up and down). It really doesn’t matter, as far as I know, exactly which control is pressed - my latest weapons, the wrench, stiletto and so on, have different animations depending on the direction but they should all have the same effect.

There is an API available for developers for the CCS system which allows the use of such things as poison, direct changes to various statistics and so on - there is I believe no open equivalent to this for DCS2, and one must become some sort of “accredited developer”.

Do note that in both cases, certain weapons, whilst technically effective, may well be banned. Scripting being what it is, it is very simple to create a weapon which abuses the existing situation most abhorrently, or, perhaps worse, creates unbearable lag. Consulting the “GM” of whichever sim a weapon is to be used within is a good idea. In some of them, for instance, automatic weapons, or those with a magazine capacity beyond a certain level, are prohibited.

~ Ordinal would like to note at this point that she would be extremely happy to compile a general list of RP systems and their restrictions for general information, and if anyone would care to provide more specific details, she would love to make them available to the public. ~

The reason that I have been driven to make this post now is that I have been informed of a most unusual situation as regards DCS2 weaponry. Apparently, from consultation with a “GM” of Toxian City, weapons which fire temp-on-rez physical bullets are banned there, and I am told in a number of other DCS2 sims as well.

This may not mean an awful lot to the casual browser, but, to explain quickly: “temp-on-rez” is a property of a prim which means that it does not persist in a sim for a long time and vanishes after a minute or two, but does not count against the prim limits. “Physical”, I would hope you were aware of, but it basically means “subject to the laws of physics” - has a velocity, is affected by gravity and collisions and so on.

I would wager that 99% of the firearms available within Second Life fire bullets which are temp-on-rez and physical, for the obvious reasons that bullets need to move and should not be affected by the current prim count in that parcel. However: I have been told that there is an indication that large numbers of physical temp-on-rez prims in an area cause a risk to sim stability, and that this has been taken up by GMs of many DCS2 environments as a rule.

This is by no means something that I have experienced or heard of through my various Scripting Chums, but really, there is little that I could do to change the opinion of sim owners in any case. Thus I am issuing a warning to those who are making firearms that might be used in DCS2 environments - make sure that your bullets are not temp-on-rez, and that they also have a time limit on their existence (a timer going off after a few seconds which makes the bullet llDie) and furthermore that they also llDie on collision with anything at all.

I myself will be making some alternate versions of firearms which correspond to this as soon as I have the opportunity. Not, mind you, that it is really feasible for anyone to tell.

~ Herein, one may find a few notes dashed off in a hasty hand whilst standing in a damp Caledon drizzle, repeatedly poking a riveted cube. ~

In case any reader had not yet heard, Caledon approaches war with sundry treacherous sausage-eaters:

I have been working on a small flying vehicle, which uses Jillian Callahan’s “Callahan Combat Control” system. Amazingly enough, it was possible to hold fair-sized “dogfights” involving half a dozen people without any part of Caledon falling into the sea, which I was expecting. Said Runabout (a fast and maneuverable little thing using the patented Levitation Coil Engine, though somewhat vulnerable) will be available shortly in a finalish version, and all proceeds from it will be directed towards Relay For Life, at while it is still (ho ho) running.

I plan to have a few other Purely Defensive Vehicles becoming available as well, as soon as I organise my time correctly and stop being quite so scatterbrained, which could be a little while coming.

I confess to having spent most of the latest Sunday investigating and construction engines relating to the I Ching, the final versions of which I am rather proud, though not being the most spiritually competent person in the universe I have at some point doubtless made some appalling error which will require hasty correction. I shall post more about this at some future point when I am not quite so ridiculously distracted by Things.

Oh yes. The Twitterbox. Ahem, yes, I am myself currently using version Zero Point Four, which actually has some quite handy extra features, but I haven’t put that out either. In futile defence of my organisational skills, I did post the Control Script for 0.3 eventually, and also edited the page generally somewhat to make a few things clearer.

One solution to the various issues that face the Engineer of Items of Transport upon the Grid - though these issues I believe to be slowly but surely disappearing, hopefully to be banished into the annals of history, only to be brought out again to scare the newest of new residents, “the Sim Crossing Monster will eat you up and spit you out at 0,0,0 with your shoes in your rear end!” - is of course to design vehicles which are purely attachments.

These are sturdy, reliable things, and much can be done with them. Attention to custom animations is required, as well as careful attention to the current state of the wearer to instruct the device to behave as appropriate (see llGetAgentInfo and quite possibly llTakeControls; the former should be polled regularly on a timer, and appropriate link messages sent out for changes in status). Acceleration of the wearer, driver or pilot can be achieved with the use of llApplyImpulse or llSetForce.

I recently released photographs of my old compatriot Professor Gould’s Hovering Chair Device Thingy, and last night was reminded of this particular form of movement by the approach of Per Lagerkvist in a rattly Motorised Wheeled Chair. On the ground it moves back and forward with spinning wheels, chugging away, and when one takes to the air, Rotary Wings are extruded to allow powered flight. The little flag upon the mast can even be changed to different designs! I was most impressed.

More can be found at the Lagerkvist Inc HQ, Jeju (250, 170, 84).

Above: Lindens move the asset database to a new server

Yesterday it was certainly the case that sim crossings and the simple and time-honoured practice of “moving about” were causing much consternation. I spent some time trying to fix multiple occurrences of trams in Caledon, so as not to overly offend a distinguished visitor.

‘Once upon a time there were three little sisters,’ the Dormouse began in a great hurry; ‘and their names were Elsie, Lacie, and Tillie; and they lived at the bottom of a well–’

‘What did they live on?’ said Alice, who always took a great interest in questions of eating and drinking.

‘They lived on treacle,’ said the Dormouse, after thinking a minute or two.

‘They couldn’t have done that, you know,’ Alice gently remarked; ‘they’d have been ill.’

‘So they were,’ said the Dormouse; ‘VERY ill.’

I must warn all users and purchasers of devices such as the .45 Shansi that there is an issue currently with llParticleSystem, that it does not reliably turn on and off. The muzzle flash in automatic fire for the Shansi, for instance, will not turn off when the trigger is released. I am sorry for this. It was not predictable and will certainly be fine very soon, I am sure. For that matter, even simple particle-turning-on scripts do not appear to work properly, though I am told that the First Look client is not so vulnerable.

Alice did not quite know what to say to this: so she helped herself to some tea and bread-and-butter, and then turned to the Dormouse, and repeated her question. ‘Why did they live at the bottom of a well?’

The Dormouse again took a minute or two to think about it, and then said, ‘It was a treacle-well.’

I dare say that, given that my last attempt resulted in my actually being kicked out of the world, I will not be conducting lengthy experiments, but patience, as always, will no doubt serve one well.

‘At any rate I’ll never go THERE again!’ said Alice as she picked her way through the wood. ‘It’s the stupidest tea-party I ever was at in all my life!’

“How to use HTTP Basic Authentication via LSL” will have to wait, I am afraid.

…that I am not the World’s greatest Complainer. God forbid.

I am sorely dissatisfied with the current state of the Universe, though. I have been absent for a little while due to OtherWorldly pressures, and I see that, on my return, everything is appalling.

Perhaps if all that one does is walk about in a small area and maybe teleport occasionally or trigger off the odd poseball or two, things are all right. I, myself, am hardly the habitual traveller. However, it takes very little to terminally disturb anyone using a vehicle. I am sitting here composing this piece on my Automated Dirigible, which takes a tour around Caledon, and every movement that it makes is jerky and awkward. Even though it is a regular physics-powered vehicle moving fairly slowly, it bumps forward at a rate of once per second, like a child’s cart kicked by the child’s friends.

This is not what I became an inventrix in Second Life to explore. When the Master of Balloon-Related Transport on the Grid, Cubey Terra (and all scripters and designers should acknowledge their debt to he and Apotheus Silverman - thank you Illyria for the correction) declares that he is grounding all of his automatic vehicles, things have gone seriously wrong.

I will be keeping up my automatic vehicles, but, you know… I grow tired. I grow tired of having to chivvy landowners to spare a few prims for the passage of the tram, gawdblessya, I won’t spend it on drink, honest to goodness. In previous ages, this was not an issue; nothing has been proposed to return this functionality, regardless of how many times I have mentioned it.

I grow tired of having my Instant Message box filled with nonsense reports from my automatic vehicles telling me how they are unable to enter a certain parcel. I grow tired of not knowing that even the simplest movement script will continue to work after I have left it.

I grow tired. And sooner or later I will fall asleep completely. I am sure that nobody will notice.

Oh, I just want to share one extra detail. Yesterday, whilst I was searching for land, I was also testing an improved model of my Blitter (a non-physical personal movement device). This appears as a sort of back-mounted device, and has much smoother movement, though it can have issues with sim crossings, which is something I need to take a closer look at.

Regardless of that, in certain areas I encountered the horrific two-hundred-metre ban-lines that I have complained about before, and of course I was unable to stop in time to avoid hitting them. However, I noticed that I was actually able to move into the banned area and in some cases through it - not easily, it was slow and jerky, but I was most definitely inside them for some seconds. I wonder why this might be? The Blitter is really a fairly simple non-physical vehicle and such a thing should theoretically not be possible.

Anyone walking the paths of Caledon on Sunday might well have been greeted by, first of all, the sight of myself perched upon a fair-sized tram; second of all, the sight of said tram repeatedly and awkwardly colliding with buildings and newspaper dispensing devices and rental payment machines as it attempted to turn ridiculously tight corners; and thirdly, my cursing the damned thing and the damned layout of Caledon and the bridges and everything under the simulated sun.

The construction of a reliable, vehicle-based transport system inside an existing landscape designed for people to walk around is simply not practical. Either one knocks down a number of houses, hopefully evicting the tenants beforehand - unlikely to be popular - or one uses vehicles which are not reliant on infrastructure (*ahem*, balloons, *ahem*) or one simply does not use vehicles.

Much as I vastly prefer having moving objects in Second Life being physical, the time does come when one must accept the limitations of physical objects and particularly vehicular physics. They hate travelling between sims, for a start, and routinely behave bizarrely. They frequently stop working inexplicably when asked or forced to sleep. They are easily knocked off-course, blocked by a simple plywood cube in their path or pushed around by vandals, and yes, even Caledon has experienced a number of attempts at vandalism - Port Caledon, I am told, was attacked by hundreds of beachballs on Saturday.

Simply put, physical objects are at the mercy of almost everything, and this is not something that makes for a good, regular, transit system. I certainly cannot be there at all times to put the things back in place myself, and whilst mechanisms for self-defence and self-correction can be scripted - my touring dirigible, for instance, corrects its own course and can easily survive a few unexpected bumps - they will never be perfectly satisfactory.

In contrast, a non-physical vehicle, one that is moved and rotated by a number of tiny calls to llSetPos and llSetRot, is almost impossible to vandalise, considerably more reliable and precise, and can effectively ignore the presence of obstacles (since it moves through them). Why are such things not used more often? Well, the last point really is also a flaw - a vehicle which moves through all solid objects is just not very believable, and also not terribly useful in environments possessing “fake ground” (prims textured to appear to be ground or rocks or suchlike).

Vehicles should not move through solid objects without a very good reason, and it is not practical to have them look for objects in front of them first, since it is currently impossible to detect the size of an object with a sensor. Say, for instance, I am standing in front of a wall. If I wish to detect its presence with a sensor I must first of all have the centre of the wall inside the arc in which I am detecting. Secondly, when llDetectedPos tells me the position of the wall, it will be the position of that centre. Which is frankly not a lot of use given as I have no way of finding out the extent of that wall. It could be one metre long, ten metres long, who can tell?

Really, LSL needs a function which takes two points and tells you what, if anything, is between them. Surely this would not be too difficult. I have simulated this using, ironically, physical objects - I have a “detector gun” which shoots out a projectile in a straight line that informs the firer of what it has hit - but I suspect that using that continuously to tell a vehicle whether it is on top of something or bumping into something is not practical. (Remaining on top of an object for instance I can see as particularly problematic; how can one fire a projectile downwards when there is no room so to do?)

Dear reader, I do understand that you are probably now most tired of these complaints of mine, and thus I will conclude this piece. Rather than continue to grapple with the production of a physics vehicle tram I shall be creating what I believe is known as a “proof of concept” design, illustrating that one moved non-physically can be both graceful and reliable, and in many cases nobody would ever notice the difference, particularly if a gentle push were involved should one happen into its path.

My balloons, however, will remain physical, as they are my own personal toys rather than the backbone of a public transportation system, and encounter fewer obstacles such as litter, pedestrians etc. Ducks, occasionally.

Those who publish pieces regarding Second Life on the internet will be interested to learn of a service known as SLurl, which allows one to easily link to a location in Second Life and have the viewer taken to a map of it and given the option to visit, whether they have the Second Life client installed or not.

I consider this a most useful service to provide, and a simple SLurl is just of the form:

http://slurl.com/secondlife/Acontia/56/186/86/

which one would hope that anyone could construct. However, the building of a customised SLurl that utilises the full range of other options is somewhat time-consuming and a little daunting to the novice.

To save time in this matter, I have created what seems to me a useful web page that allows one to simply fill in the blanks on a form and produce a SLurl. It is called SLurlBuilder. Please feel free to use it as desired.

If anyone was concerned with the progress of my paper aeroplane investigations, I can announce that I did, in the end, come up with a design for the aeroplanes that seems to provide reasonable results. Rather than calculating the angle of attack each time, I simply assumed that it would always be zero given that the plane does turn to face its direction of movement anyway.

The plane now basically works with lift and drag, both proportional to the velocity. Lift applies in its local Z-axis, and drag in its local X-axis. Using llSetForce with the local flag set really does save a lot of time as far as calculating the correct co-ordinates is concerned.

The resulting item is now available at Ordinal Laboratories, but one can also scan the aeroplane code here and now should one wish (pretty colourised HTML version).