• strict warning: Non-static method view::load() should not be called statically in /home/ordinal/ordinalmalaprop.com/engine/sites/all/modules/views/views.module on line 906.
  • strict warning: Declaration of views_handler_field_comment::init() should be compatible with views_handler_field::init(&$view, $options) in /home/ordinal/ordinalmalaprop.com/engine/sites/all/modules/views/modules/comment/views_handler_field_comment.inc on line 49.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /home/ordinal/ordinalmalaprop.com/engine/sites/all/modules/views/handlers/views_handler_filter.inc on line 607.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /home/ordinal/ordinalmalaprop.com/engine/sites/all/modules/views/handlers/views_handler_filter.inc on line 607.
  • strict warning: Declaration of views_handler_filter_node_status::operator_form() should be compatible with views_handler_filter::operator_form(&$form, &$form_state) in /home/ordinal/ordinalmalaprop.com/engine/sites/all/modules/views/modules/node/views_handler_filter_node_status.inc on line 13.
  • strict warning: Declaration of views_plugin_row::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/ordinal/ordinalmalaprop.com/engine/sites/all/modules/views/plugins/views_plugin_row.inc on line 134.
  • strict warning: Declaration of views_plugin_row::options_submit() should be compatible with views_plugin::options_submit(&$form, &$form_state) in /home/ordinal/ordinalmalaprop.com/engine/sites/all/modules/views/plugins/views_plugin_row.inc on line 134.
  • strict warning: Non-static method view::load() should not be called statically in /home/ordinal/ordinalmalaprop.com/engine/sites/all/modules/views/views.module on line 906.
  • strict warning: Declaration of views_handler_argument::init() should be compatible with views_handler::init(&$view, $options) in /home/ordinal/ordinalmalaprop.com/engine/sites/all/modules/views/handlers/views_handler_argument.inc on line 744.
  • strict warning: Declaration of views_handler_filter_boolean_operator::value_validate() should be compatible with views_handler_filter::value_validate($form, &$form_state) in /home/ordinal/ordinalmalaprop.com/engine/sites/all/modules/views/handlers/views_handler_filter_boolean_operator.inc on line 159.
  • strict warning: Non-static method view::load() should not be called statically in /home/ordinal/ordinalmalaprop.com/engine/sites/all/modules/views/views.module on line 906.

Kindly Do Not Carry On Camping

I wrote the following a while back in relation to Forthcoming Restrictions on Traffic-Related Perversions, regarding matter unaddressed in that specific Laboratory Announcement:

Camping, for instance: offering camping chairs, which are then occupied by bots belonging to somebody else, is a symbiotic relationship between landowner and bot operator. In fact, if said chairs are occupied by residents, said residents are effectively becoming trafficbot subcontractors - "crowdsourcing traffic distortion" if you will. Whether or not bots are being used is fairly unimportant, and a campsite owner could certainly claim that they were not using bots, in the knowledge that by putting out large numbers of chairs and paying money to those sitting on them, some bot operator would shortly be along.

The LindenFolk, who despite my occasional disagreements with some of their decisions are none of them Fools, quite the opposite, are clearly aware of the relation too; thus we read the following penned by Mr Jack Linden:

The policy we announced is about Traffic, how that relates to Search, and how a deliberate attempt to falsely drive up the traffic score will no longer be allowed. We know from your comments that you want Search to be fair and relevant, and we want that too. Whether a landowner uses Bots or Camping Chairs, or Camping Chairs with Bots in them, the effect is the same - the traffic score for that parcel is inflated unfairly.

Are there other uses for so called Camping Chairs other than for Traffic? If you know of some please let us know in the comments below! However, the feedback and data tells us that by far the main reason for large numbers of Camping Chairs at a location is to unfairly gain a Search advantage.

So the policy statement is that where we see a Resident unfairly increasing their Search ranking, regardless of how that is achieved, it will be considered as 'gaming'. We will give a first warning to begin with and direct people to the policy. However continued gaming can result in suspension or removal from Search listings altogether.

The part that I have Bolded is absolutely the sort of attitude that should be taken and I applaud it (though it seems peculiar that a rule based on Preventing an Activity - unfairly increasing Search ranking - should need to have it explained that yes, it does mean "whenever this is done" rather than "in a small number of circumstances that one might avoid yet carry on the same activities". I suppose this is the world within which we live, where many expect that everything must have exact criteria at the outset, rather than this sort of open-ended definition relating to intent - cornerstones of all working Systems of Justice, of course, without which there would be little point to Judge or Jury.)

If one wishes to experience a brief moment of amusement followed by increasing waves of nausea and the eventual desire to kill, I would advise reading the Comments that have been left on the linked Article, wherein many attempt to answer Cpt. Jack's request "Are there other uses for so called Camping Chairs other than for Traffic? If you know of some please let us know in the comments below!" Reading these one might be led to believe that Camping Chairs were the major contributor to the fortunes of New Residents and that Campsite Operators were Dedicated Philanthropes, donating fortunes every day to the New and Poorly-Skinned with only the minor return of distorting search results as reward.

This is Utter Bunk of course; for one thing the rates themselves are pitiful. I do recall a time when some Return could be made from sitting on the Damnable Chairs, but the rewards have declined to practically nothing with the advent of Traffic- and Camp-Bots. Ms Tateru Nino says "The most common camping rates I'm seeing at the moment are L$1/80 minutes" which conforms to the results of my amateur investigations; perhaps one might buy two frocks per month of non-stop camping with that.

And quite apart from the rewards, paying people to perform an unethical activity does not make that activity any more ethical. I have attempted to argue this very point with my brother Cardinal, in reference to his Kitten Factory, which is not, I must shamefully say, a place which constructs kittens at all; more, items involving kittens in their manufacture; kittens as Input rather than Output.

"Silly girl," he routinely replies, "my Factory provides gainful employment to literally dozens of people. Would you deny them the four shillings and sixpence (a very competitive wage in the current climate I might add) that they receive? I thought you Socialist sorts were concerned for the Workers! This is the Failure of the Left, you know, that they care more about kittens than people." And then he laughs in that annoying way that he has. However I do not consider his argument at all valid, and neither do I consider that the arguments for Camping Chairs pass muster.

A Warning regarding Alpha and Release Candidates

I was most Helpfully Informed by a Perspicacious Resident recently that the Galvanic Swordstick appeared to be behaving in a somewhat unusual manner when viewed with the latest "Release Candidate" - in that parts of it were not Appearing and Disappearing as would otherwise be expected, so that upon drawing and sheathing and such, one appeared to be holding two Swordsticks at once.

On closer examination this is indeed the case - and what is more, the same issue will undoubtedly affect, well, to be quite frank pretty much every Item that I Sell, as most of them have parts which do Appear and Disappear according to the item's current Use.

I make this Entry as a warning to those who choose to view the Grid with the Release Candidate "1.23.1", as there is nothing that I can or am inclined to do about the situation. It seems that this Candidate is not appropriately Updating as to the current Alpha State Of Things. There are JIRA issues on the subject (for example, VWR-13097), the Linden Types are Aware of it and no doubt making all efforts to Do Something About It before this Candidate is Anointed as the next Official Viewer. Clearly it cannot be released in such a state! I am sure that a fix will be forthcoming post-haste and mean no LindenCriticism here - it is a Release Candidate after all.

I am however aware that some folk are using the Release Candidate on a Day To Day basis, for reasons best known to themselves, and those bold explorers should be notified of the situation, and perhaps it might be suggested that they Vote for the issue as being one of importance. Such a thing can never hurt.

Self-Examination; or, Not Protest But Preservation

A Thing has recently occurred to me - well, in fact, the Thing is not in itself that new, but more a confluence of Two Other Observations which I had thought Independent.


The first is that I have not been Upon The Grid an awful lot recently. This is something that does come to the Elderly - reduced Mobility - and I had thought it mostly a symptom of one of those periods of general Ennui that is known to afflict us all, and attempted to treat it with assorted Creative Linctuses. (Lincti? Lincta? Oh, Latin was never my strongest subject.) I have forced myself into Harsh Regimens of Strict Notebooking and a diet of Ink and Pencils, and Providence, or future Biographers, or more likely Puzzled Public Servants tasked with disposing of my Affairs, will be able to attest that my personal Notebooks are really quite full of all sorts of ideas; my Project List is bulging, my Tasks overflow.

Yet despite a million interesting things to do I have not actually done them. In contrast, in matters not related to Second Life I have found that I have had no issue. For instance, I have a toy project building what could be termed a "browser MMO". With this, I have had no motivational or practical issues at all, despite it being considerably less pretty and considerably shallower than many of my Second Life plans.


The second is that I despise Chat Lag. I have been through the usual phases here - firstly, Amusement:

Ha ha, my words are out of order and my sentences appear minutes after I have said them, making it impossible to communicate! Let me see if I can exploit this for Comic Effect, ho ho!

then Acceptance:

Oh well, my words are out of order and my sentences appear minutes after I have said them, making it impossible to communicate. I suppose that it is Friday*.

* please change day as appropriate

then Fruitless Anger:

Gah! My words are out of order and my sentences appear minutes after I have said them, making it impossible to communicate! This is driving me absolutely potty! It must be addressed immediately!

but really, these days it is more:

Oh. My words are out of order blah blah. So either I don't speak or I am unpredictably frustrated when I speak. (logs out)

Because of course

  • it is not funny;
  • waiting does not make it better; and
  • complaining does not make it better (though does not make it worse either); and
  • the only thing to do is react as appropriate.

Slight Return; thoughts on a Lightweight Interface to Drupal

I wrote previously that I had done some reasonably considerable work integrating Drupal with Second Life, which of course means integrating the Drupal System with the Linden Scripting Language.

LSL has the llHTTPRequest function, of course, by which one can send information to Drupal (or indeed any other system on the Wider Aethernet). The main issues that I have encountered, though, are:

  • The sum of data to be sent and received. A typical Drupal page is really quite enormous and unsuitable for the standard LSL limit of 4096 characters. Furthermore, many existing interfaces to web services, involving the XML or JSON formats, are unsuitable for use with LSL, which really takes an age to do any sort of String Processing. Both request and response need to be of very short formats.

  • The problem of authenticating who, indeed, the person sending the request is. Sending the registered Drupal username and password hash is quite a simple thing to do, but in most cases, this is unsuitable for use with LSL. People do not wish to have to enter usernames and passwords into scripts or notecards unless they absolutely cannot help it.

    In the past, with Rezzable's "Avatar Linking" system, I solved this by giving the resident concerned the ability to create a Drupal user account for themselves if they did not already have one, automatically from the grid, with the entry of a few details such as their Email Address; the name and key of the resident was passed along with this, and stored in Drupal. Other Scripted Gadgets which they might use in future then authenticate themselves with some sort of Master Password, and pass the key of the operating avatar along with other data. The Drupal system looks the appropriate user account up by matching the key to stored and confirmed ones, and carries out operations for that user - for instance, leaving comments on the node for a particular Artwork.

Both of these are common issues across all sorts of Systems for which one would wish to use Drupal, and it occurs to me that a Common Framework would be useful in this instance. I am moved to create such a framework for my personal and professional use, and also the use of anyone else who might be interested.

The most important features of this framework (which I have been calling "Slight" - SecondLife Lightweight) as I seem them are

  1. that it can receive data easily, pass them on to other modules for use, receive responses from those modules, and return the responses to an LSL script in a format that can be quickly processed and understood;

  2. that it has the ability to authenticate users and pass the details of the authenticated user on to sundry other Drupal systems. This authentication could be performed by the main module itself as well as other, optional ones which folk might choose to write.

Those familiar with the Drupal Beast will be aware of the concept of a "hook". Invoking a hook allows other modules which are aware of it to perform actions on data passed along with that hook. I am thinking along the lines of having two hook invocations here - firstly, one for authentication, which passes along the data sent and allows other modules to modify a user object. Then, one for the action to be performed, which allows modules to perform actions on the basis of those data and the authenticated user, and add responses, which will be passed back to the LSL script to be delivered to the resident.

Perhaps an example might be of use here. Say one wishes to have a system which allows the creation of "blog" entries via LSL. The LSL script would take the key of the avatar (this is unforgeable) and combine it with a hardcoded password to produce a hash. It would send this to the Slight interface - which possesses a specific URL, say http://ordinalmalaprop.com/engine/interface/slight/ - along with the avatar's key in plain text, and the actual text of the blog entry. Our Drupal administrator here has three relevant modules installed - the Slight framework module, a Slight Second Life authentication module, and a Slight blog entry module.

Slight would initially believe this entry to be unauthenticated, as there would be no information as to the Drupal username and password. It would, however, invoke a hook for authentication with a missing user object, giving other modules the opportunity to authenticate whoever it was. "Aha!" the Slight Second Life authentication module says, "this person has sent a hash of key and master password which I recognise - I will modify the user object to correspond to the user whose avatar has this key". And it proceeds to do so.

Upon receiving the results of the invocation of the authentication hook, Slight then sends out another, "action" hook, with the user object that has resulted from the authentication process. The Slight blog entry module at this point says "aha! I see that there is an authenticated user here" (this user having been provided by the Slight Second Life authentication module) "and that the command is to add a blog entry. I will do such a thing, and, if it works, send them back a message saying that it has been posted, and giving them the URL of the new entry".

Slight takes the results of what has happened after the action hook invocation, and passes anything appropriate back to the requester. This might be highly technical data for use by a script, or it might (in this case) be a simple message to be sent to the owner via llOwnerSay or some such. Whatever it is, it sends it back. The LSL blogging widget script takes this response and, here, sends the confirmation to the resident, who no doubt proceeds directly to the page concerned to see which words they have misspelled.

This sounds like a rather involved process but in practice, the time required would be tiny fractions of a second for all.

As a note, Slight would not be simply of use for Second Life. Since it would be simply receiving GET parameters and sending a plain text response, it could be used by any system.

One significant use that I believe would be very handy is for use in Opensim, which currently (as far as I am aware) has no particular permission system set up. Upon login, the Opensim server itself could request the current role of an account linked to an avatar from a Drupal system, for use in determining whether that avatar could enter parcels or regions or change settings or whatnot. Changing an avatar's access would then be as simple as ticking a few boxes in a form that was produced by the appropriate module. This is in fact something which I hope to implement in practice, and as soon as such as thing is ready, I shall mention it on the appropriate site. (To be fair, if I have been working on things in Company Time, details of them really should appear on Company Blogs, though Slight as I envisage it will certainly be open source and so on.)

I would be interested to read any Comments or Criticisms that anyone might have regarding this Proposed Framework, so please, if you have any, by all means leave them here. I shall post here once I have the actual Code for the system in any Working State, which should not take very long to do.

Rampant Traffic Bottery to be Eliminated? Perhaps, a Little.

The figure in the foreground is a notorious and exploitative Bot, and requires Immediate Removal from Everything. Do not trust it!

Almost everyone agrees that using Bots to manipulate traffic (and therefore Search rankings) is unfair. Not only with respect to Search itself but also due to the load on Mainland Region resources and how that can impact other Residents in the area.

Therefore we are setting policy that attempting to gain an unfair Search advantage, by the use of Bots to inflate the Traffic for a parcel, will be considered a violation. This policy applies to both Mainland and Private Estates as both are represented in Search. (Conclusion to the Blog Post on Bots)

And few would argue with that. (Although the few, pretty much exclusively those selling bots and using bots, do sometimes seem to be attempting to make up for their fewness by repetition.) I would say that this was an extremely Welcome Move; I am having great difficulty in constructing credible arguments opposing my "Trafficbots Are A Bad Thing" position that I might address in the form of Dialogue. Traffic is meant to be an indication of popularity. Populating an area by artificial means makes this statistic, one of the few we have access to, meaningless.

In general I certainly approve of the attitude - previously displayed in the context of Advertisement Farms - that it is the behaviour that matters, not some breach of arbitrary technical rules. Are you attempting to distort traffic statistics by the use of automated facilities? Then you should be prevented from doing so. No, there will not (one would hope) be a series of technical Rules, the Letter of which will be obeyed and which can thus be ingeniously bypassed - Motivation is the key.

I can, though, see that this particular Announcement is not really complete. Certainly it should eliminate those dismal boxes of twenty or thirty homonculi, locked up in a cube at four thousand metres in height. However, the continued presence of Traffic as a statistic will lead to other methods of Gaming becoming more popular, if unchallenged.

Camping, for instance: offering camping chairs, which are then occupied by bots belonging to somebody else, is a symbiotic relationship between landowner and bot operator. In fact, if said chairs are occupied by residents, said residents are effectively becoming trafficbot subcontractors - "crowdsourcing traffic distortion" if you will. Whether or not bots are being used is fairly unimportant, and a campsite owner could certainly claim that they were not using bots, in the knowledge that by putting out large numbers of chairs and paying money to those sitting on them, some bot operator would shortly be along.

Still, there are other hopeful signs:

Going forward we are going to look at ways to allow you to voluntarily identify to us that an account is a Bot, so that we can remove it from Traffic completely.


We will continue to strive toward providing more statistical data to land owners, including the number of visitors they receive.

Excellent! And extremely overdue! "Yesterday" would be a good time for this to happen, I would say.

However, the way these statistics relate to Search ranking will be changing. In the next few months, we will be making both technical and policy changes to the way relevance and ranking works in Search. The "traffic" score will be only one aspect of the ranking logic, and it will be scrubbed and weighted to account for gaming vectors.

Potentially a Good Show depending on the details! Although I thought that this was supposed to already have happened.

In any case, now I believe I shall return to the company of my new-found friends Ngr, Eops and Sfdjk. There is after all the chance of winning a Linden Dollar every four minutes, you know.

A Modification to the Twitterbox, such that it Works Once More

I have been informed more than once over the past few days that my Twitterbox appears not to be operating as Desired - more specifically, that Twitterboxers were able to send updates quite satisfactorily, but not actually receive any, which was understandably frustrating for them.

On further investigation it appears that the Twitterfolk decided at some point to restrict requests to receive an Updated List of Friends' Tweets to those using the GET method. I have no idea why, but who am I to argue? In any case I have modified my own server script so that things should now Operate As Expected. For those using the script on their own Aethernet Servers, they may find the latest version here:

There should be no need for Twitterbox users inworld to do anything at all regarding this - it is mostly for Informational Purposes. No updating or such is required, as long as you are using version 0.4 or above.

A Movement Drupalwards

Not, you understand, that there is anything wrong with the popular Journalling System, "Wordpress", but I have for the time being left it alone and moved the Engine Fit For My Proceeding And Apparently Fit For Yours Since You Do Seem To Be Reading It to work using that hive of open-source Communism, "Drupal".

The reasons for this are fairly straightforward, and I shall list them briefly here.

  1. I wished to see whether I could, whilst leaving all of the links to my Previous Journalings intact, and also without interfering with the existing Appearance and Function. (Apparently I could, as far as I can tell, anyway. If something appears Wrong please do inform me as soon as possible.)

  2. I poke and tinker with the DrupalThing on a professional basis very regularly, a circumstance which results in a pleasing Symbiosis. My professional poking and tinkering experience allows me to rapidly and effectively poke and tinker with this system personally, and the more that I interfere with it on a personal basis, the greater my Skill and the greater the benefit to my Employers; thus a Smile is brought to the faces of all parties concerned, and in these trying times, heaven knows the more Smiles that exist in the world, the Better.

  3. Keen observers will have noticed that I do, on occasion, refer to Scripts and Other Code on this Journal. The WordpressWotsit is not particularly good for storing the Inner Workings of said items, being mostly designed to keep track of Posts and Pages. Previously, I have been storing Scripts upon a Wiki, which is a rather crude solution. The DrupalThing, on the other hand, has the benefit of allowing one to create arbitrary "content types" with different fields and Display Options, and also take advantage of types generously provided by the Community; to this end I have utilised the "geshinode" module to allow me to add specific "source code" entries, and I have further tinkered with bits and pieces to have these entries wider than usual and with an area that allows me to easily link them to explanatory journal entries. As well as this, the "views" module allows me to simply generate a categorised list of them, which you, dear reader, may see by visiting the "Scripts" link at the top of the page.

  4. In general, really, the DrupalThing is more easily Configurable and Extensible. Some readers may be aware that my current main Employer is the firm "Rezzable" and I have quite some history of creating various Interactions between their Drupal Site and the Second Life Grid - and, I might add, other grids, if that is not too bizarre a concept. Whilst I have no current plans to do anything along those lines here, the possibilities exist. For instance I may well begin to list my own Products here as well, store documentation for them, that sort of thing.

I could not, in all Honesty, recommend the DrupalThing for the typical Writer of Sequential Prose - in most cases Wordpress is a far better solution. It does however suit my Tinkering Instincts and thus I have engaged in this Movement. I would hope that nobody is Inconvenienced at all and, in fact, that the General Utility of my Witterings is Greatly Enhanced by this process.

An Inventory Permissions Checking Script

I was reminded recently of a script that I wrote quite some time ago and appear not to have published anywhere. I did mean to. Perhaps I did, and have simply forgotten. In any case, it can be found here:

The task that I use it to accomplish is to check the permissions of the contents of an item before sale or distribution.

The Ordinal Transitory Umbrella

Transitory Umbrella 2

The region of Caledon Perenelle has recently been discovered on the Caledon Archipelago, and I am dedicatedly perusing the assorted journals, maps, sketches, papers and various pieces of what is quite frankly Junk and Flotsam, left to me by my Great-Uncle regarding this Peculiar Area.

In Which Ordinal Belatedly Answers Questions that She Herself Actually Requested Folk To Post

An Unpredicted Event has occurred! Namely, that I have shuffled off the Chains of Idleness and Attempted to provide Answers Of Some Use to the questions which I Previously Invited regarding Scriptery. I believe that blithely promising a Weekly Session was somewhat ambitious of me, but I really should not have taken such a ridiculous length of time.

In any case, Self-Flagellation aside, here the Curious and Unjustly Delayed might find responses of some sort. Please, sir or madam, do feel free to request further detail, correct my undoubtedly innumerable errors, berate me for Flippancy, and also, ask more questions, which I shall try not to take Quite So Long To Answer in the future.

Syndicate content