Beginning a piece of writing by apologising for not having written previously is most appallingly gauche, and you will not, dear reader, find me doing such a thing. I would like instead to add a few observations regarding the latest Scripting Abilities sent our way by the beloved Laboratory, in particular those dealing with Parcels.
It has always been a source of much irritation to me when constructing Automatic Vehicles that they were unable to check before entering a particular area whether they were likely to vanish into the Mists of the Asset Server, roaming around and mournfully ringing their little bells until finding their way back into my Lost And Found compartment, to join their fellows. In fact, so many trams have entered my Lost And Found that they have actually created their own system of government, which pretends to be a parliamentary democracy but is in fact a poorly-disguised and oppressive oligarchy that keeps plywood cubes as a de facto slave class. I really must go in there at some point and unlink a few of the most prominent, pour encourager les autres.
Nowadays, however, one is able to head off any attempts at self-organisation by the contents of one's inventory by careful use of the functions
llGetParcelPrimCount. By checking the path ahead at regular intervals to see whether the entrance of the vehicle into a parcel ahead will push said parcel's prim count over its allotted limit, one can see when a course would lead to disappearance, and make alternative arrangements. The precise nature of the arrangements are of course a slight problem, but I would think that such things as moving ahead using "WarpPos" or perhaps returning home would work. A proper automaton would look for an alternative route, but public transport is meant to be predictable - one cannot have trams deciding that they prefer taking shortcuts, or would rather take a turn around the lake to feed the ducks, leaving potential passengers abandoned, confused and cross. I have not actually yet implemented this but plan to do so when I am able.
Whilst on the subject, it also means that the "re-rezzers" (which recreate trams and balloons which meet a sticky end) can now check that the parcel that they are on is actually capable of supporting the vehicle to be rezzed at all. Currently they cannot, as I have previously mentioned, and must attempt to do so and then check whether they have been successful, which is wasteful and annoying.
One function with which I have been actively playing is
llGetParcelDetails, which enables one at last to actually see what parcel one is on. It is not of course perfect. The owner and group functions return a key rather than a name, and as others of the scripting persuasion will know it is a pain, and a slow pain, to get the names of agents from keys - and, I believe, impossible to get the names of groups from their keys, though doubtless some young thing will come along and show me to be an ignoramus on that score.
In most of Caledon, the parcels are deeded to groups, and as I test most of these gadgets in Caledon I was mostly unable to get any owner names at all. Some of the most recent areas such as Caledon Victoria City use the "covenant" system which does mean that the tenant is listed as the owner - all well and good but still a pain.
That aside, I made myself a device which can be used to create a map of the parcels in a particular sim, something which is not at the moment accessible from the world map, which, while much prettier than anything I can do, just shows construction and terrain rather than boundaries. If you would care to visit the following:
you will perhaps see what I mean, though I do warn those of a delicate disposition that the colours are not perhaps the most aesthetic.
At this point you may wish to skip to the end of this piece... there are two sides to this, as usual: the sim mapping device within SL, and the sim mapping server upon my Aethernet Box. The former divides the map up into four metre chunks and retrieves the details from the middle of each spot in sequence - so, it starts at (2,2,0), then (4,2,0) and so on, until it gets to (254,254,0).
It goes by rows - the data for a row are transmitted as a series of records of where a parcel starts and what its name and description are. So, if Parcel A starts at the bottom left corner (2,2,0) and continue on to (62,2,0), with Parcel B starting at (66,2,0) and continuing for the rest of that Y-position, it will send to the map server the information
The numbers here refer to the particular 4m square rather than the exact X or Y position of its centre. If a row is actually the same as the last one, the scanner sends nothing at all, which cuts down on the amount of data to be sent.
This information is stored in a temporary file once received, and once the entire sim has been scanned it puts it all together to create a (very messy and inefficient) page displaying the map. There is obviously more to the technical side than this but I am starting to bore even myself and will thus cut this a little short; suffice to say that any half-competent apprentice in the field of PHP could do such a thing, it is really just opening and writing to files and creating arrays and all that malarkey.
One thing that does interest me is that the system stores every map rather than overwriting the existing one for a sim each time, which would enable a historically- or research-minded person to see how the occupancy and usage of a sim has changed over time. (There are no archive pages or such at the moment, I only made it yesterday, but it is part of the plan to put them in.) I was considering setting up the scanner to, say, do a scan of Caledon every week - the scanner itself could be made to move about between sims, it does have to be in the same sim as that which it is scanning.
Originators and propagators of Urban Myths upon the Grid will be most disappointed to hear that there is still no function which enables the creation of "land scanners" which allow automatic purchasing of land set for sale at L$1, since there is still no way to tell what the purchase price is or if the thing is for sale at all, let alone buy it automatically.
The practice of Land Swooping is as far as I can see a purely human-powered endeavour, with some odious weasel sitting there clicking "Search" again and again, like an urchin waiting on the street, watching for passers-by who unwisely reveal their Purses, Wallets or Mobile Telegraphic Equipment, whereupon the little beast will swoop in and relieve them of their valuables. In the Other World of course the thief does not usually hang around to taunt the victim and tell them they deserved it, since such practices are illegal there and invite Attention from the Constabulary or even Immediate Retribution by the Injured Party.