• warning: Creating default object from empty value in /home/ordinal/ordinalmalaprop.com/engine/modules/taxonomy/taxonomy.pages.inc on line 34.
  • 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.

Things by me

Regarding Ordinal Enterprises' Current Stock For SL To RL Export

My Potential Customer seems eager to purchase exported Ordinal Enterprises products, and it occurs to me that it might be a Service to Other Potential Customers to provide the following information, as should anyone else make similar enquiries I would likely send the same information. Thus I quote it herein. (Please see attached PDF for the appropriate prices.)

Hello - sorry for the delay.

Please find a PDF of the current Ordinal Enterprises stock list available for export attached to this email.

It is very important that the following notes are read with relation to this stock list, as Ordinal Enterprises will not be able to legally complete the order without the supply of proper licences.

Notes on individual items

  1. Purchase of the Beehive Launcher requires either proof of a Class IV Apiary Licence (Foreign And Hazardous Species) or equivalent experience. A bulk order will significantly reduce the export cost, which mostly results from the necessity for specific bee-breeding, construction of hives and antivenom - for items after the first, reduce export cost per item to £2000.

  2. The Transitory Umbrella is legally only available for sale to those with an GBMP525 pilot's licence (before the 1982 change to the law, this was known as the "Van Dyke"). This must be less than five (5) years old.

  3. Storage of the Multicoloured Snuffbox can only be legally carried out by licenced pharmacists aged eighteen (18) or over.

  4. A Health & Safety Executive explosives permit is required to receive Festive Humbugs. Bulk orders are available at half export cost past the first. Export cost may be affected by current sugar and aluminium prices on the international market.

  5. A valid UK Airship Private or Commercial Pilots Licence is required before receiving any Gun Balloon. This should be a CPL Airship Licence covering Gas Filled Balloons. Delivery costs include hire of delivery pilot, fuel and insurance against border crossings. Please note that the rotary cannon in all civilian Gun Balloons has been PERMANENTLY DISABLED, though the motor is still operational. Attempted use of blank shells may cause significant damage to the Balloon's mechanism and likely injury or death to the pilot. Please consult the operational manual for more details.

  6. These items require a UK handgun licence with additional permission to handle virtual firearms (this can be quickly added to an existing licence at your local police station).

  7. As well as a handgun licence, purchase of one (1) or more Flare Pistols requires proof of membership of a professional nautical body, or an advanced sailing certificate. Some customers have asked whether a gold swimming certificate is sufficient - unfortunately by law it is not.

Export procedure

A deposit of 50% of the total export cost is required to cover expenses for SL to RL export. Success is not guaranteed; the deposit will only be returned in case of failure. Export usually takes from between two weeks and six years. Exported products are no-copy/trans/mod items and other permissions are not available. Performance of RL products may differ from that of SL products due to underlying script incompatibilities and differing physics engines - while Ordinal Enterprises takes every care to make sure that performance is as similar as possible, no refunds will be provided should behaviour differ, or existing functionality be broken due to any forthcoming RL upgrade.

General notes

  • VAT can be removed on submission of appropriate VAT registration details.

  • None of the above items will be able to be marked as "gifts" for customs purposes, including the Festive Humbugs.

  • Payment should be in UK Pounds Sterling and not Scottish Drachmas.

On 2 May 2011, at 09:38, Mark Joe wrote:

Hello, thanks for the mail i will like you to get back to me with the current price list so that i can place my order.



(You may see any further developments by looking at the "SL to RL Export" tag in this Journal.)

A Valentine's Day Promotion

The Ordinal Stiletto (a product from some time ago, I admit) is available at Half Price from the MarketplaceThing for the remainder of the Fourteenth of February - this means, for your information, that it costs L$100.

As well as that, should you care to actually enter the Grid, you can purchase it for a mere L$75 at Ordinal's Series Of Planks Over A Hole In The Ground!

Stiletto (close)

The Blissetesque Revolver: a Shameless Commercial Advertisement

The above revolver is now available at my Caledon... well, it isn't really a "shop" any more. It is a large hole in the ground, filled with water. But it is here, and as an extra reward for being bothered to enter the Grid at all these days and potentially looking around other parts of Caledon, the Inworld Price is a mere L$300 for today.

Addendum: The price has now risen, and the revolver can be found for purchase here, though I think you should still buy it inworld, because that is more proper.

A Request for Suggestions Regarding Adult Content

It is my Rezday today, and given that, I decided to make myself a Present of 512 Square Metres of land. (Tier for which I will not be paying due to my Premium Status - a term which always makes me feel like some sort of ham. Premium Ordinal Meat, L$100 per pound!)

In any case: I have bought a small plot at Raindown (137,57). My intention there is to make an actual Adult Library; things which actual adults might be interested in, as opposed to the ridiculous fantasies of adolescents pretending to be older than they are, or older folk pretending to be younger than they are.

I would welcome suggestions as to the sort of Adult Content which might be included here. Mortgages? The obtaining of a Pension? How to deal with a particularly persistent Paramour whom one half-desires and is likely to be weak towards, yet whose actions are clearly harmful? (Cease all communication no matter of what sort!) And so on.

A script in haiku

which, itself, says a haiku.

For no easily identifiable reason.

[geshifilter-code]// LSL Haiku, first attempt // Ordinal Malaprop // Sat Aug 22 15:20:04 BST 2009 // RULES: // Each function must be a haiku including the declaration, // though only identifiable words and numbers need be included, not // punctuation. // Events must contain a haiku i.e. be three lines, 5/7/5. // "0" can be pronounced zero or "oh" to make things slightly easier. string say(string toSay) { llSay(0, toSay); return toSay + " said."; } string theFirstLinePlease() { string firstLine = "This is the first"; return firstLine + " line."; } string theSecondLine() { string lineTwo = "the second line."; return "This, " + lineTwo; } string andTheThirdLine() { string thirdLine = "it really the"; return thirdLine + " last?"; } default { state_entry() { say(theFirstLinePlease()); say(theSecondLine() + " Or is,"); say(andTheThirdLine()); } }[/geshifilter-code]

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.

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.

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.

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.

Syndicate content