Run the docs through a spell checker.

19 files changed, 65 insertions, 65 deletions

diff --git a/BUILD.txt b/BUILD.txt
index 67fc58c..3cac347 100644
--- a/BUILD.txt
+++ b/BUILD.txt
@@ -24,7 +24,7 @@ http://git.enlightenment.org/core/
 
 It should all work under X window managers other than Enlightenment,
 though this has not been tested.  The same applies to Linux distros
-other than Ubuntu 12.04, that's the only one that hes been tested by me. 
+other than Ubuntu 12.04, that's the only one that has been tested by me. 
 This is all still experimental, but I intend to get it to work under Mac
 OS X and Windows as well.
 
diff --git a/README b/README
index f04c431..66f6c16 100644
--- a/README
+++ b/README
@@ -259,7 +259,7 @@ audits, and less places for things to go wrong, or escape attention.
 Commonly used security and privacy protocols also tend to be built in
 modular ways, so we can make use of these things ourselves.
 
-Pretty and skinable.
+Pretty and skinnable.
 --------------------
 
 The Enlightenment Foundation Libraries (EFL) where written to support
@@ -553,7 +553,7 @@ IM client
 web browser
     We may have to deal with external web proggies, which may in the end be the best way.
     Except for MOAP.  lol
-    Maybe later we can have a HTML to GuiLua translater module?  Muahahaha
+    Maybe later we can have a HTML to GuiLua translator module?  Muahahaha
 
 IAR & OAR file reader / writer
     loads up the file, sending it as nails commands
diff --git a/STANDARDS.txt b/STANDARDS.txt
index c20a258..ad0f4b5 100644
--- a/STANDARDS.txt
+++ b/STANDARDS.txt
@@ -36,15 +36,15 @@ On the other hand, we do want full functionality to be available to high
 level scripting languages.  While Lua is the chosen language, there's
 been some success translating to and from Lua which may help us be more
 agnostic here.  There's others working on translating things to Lua,
-based on the theory that since it's the fastest scripting lagnuage, that
+based on the theory that since it's the fastest scripting language, that
 might help speed up other scripting languages.
 
 In particular, translating LSL into Lua has so for been working well.  
-The parts that can be benchmarked soo far are very fast indeed, making
+The parts that can be benchmarked so far are very fast indeed, making
 SL and OS look like the crippled snails that they are.  Also, there's
 some evidence that we might be able to translate Lua into ECMAScript to
 run in web browsers, or run a Lua VM inside the ECMAScript VM.  
-Alledgedly, while the scripts run slower than LuaJIT can run them, they
+Allegedly, while the scripts run slower than LuaJIT can run them, they
 are still quite fast compared to ECMAScript.  We need this to support
 legacy web browsers, which decided long ago to standardise on
 ECMAScript.  Alice loves her some JavaScript and node.js.
@@ -64,7 +64,7 @@ wanted to use a different markup syntax.  lol
 
 I solved this by installing a few markup systems, but the majority of it
 got written as what Drupal refers to as "simple formatting", which
-basically allows the use of certain HTML tags, plus a few nicities.
+basically allows the use of certain HTML tags, plus a few niceties.
 
 Eventually code started to get written by me, I put it on GitHub.  At
 around the same time, I was busy transferring the Team Purple website
@@ -91,7 +91,7 @@ that's not our main thrust for UI stuff.
 Sooooo, to avoid a lot of work, how about we just make the documentation
 static HTML web pages, and be done with it?  Markup systems are just a
 way to make HTML more palatable to ordinary users, but ordinary users
-are not writing the design documentiation and such.  They all get
+are not writing the design documentation and such.  They all get
 translated to HTML, so let's just write raw HTML ourselves.  Keep it
 simple, no fancy CSS or Javascript shit.  So we avoid markup, we avoid
 having to translate from markup to markup, and we avoid the rendering
diff --git a/TODO b/TODO
index 4b23cb8..e340799 100644
--- a/TODO
+++ b/TODO
@@ -32,7 +32,7 @@ Runnr.c
     Starts or resumes the script running.  If there's a message, push it as an argument.
     Expects the script to eventually call Runnr.receive().
   Runnr.receive()
-    Does a Lua yeild, which will return once there is a message for this script.
+    Does a Lua yield, which will return once there is a message for this script.
   Runnr.send()
     Either send2script(SID, message), or send2server(message)
 
@@ -201,7 +201,7 @@ More generic event system?
 
   There are other events flying around.
     BASIC event         Just send it to LuaSL, it loops through all scripts, sending the event to them all if they have an event function in their current state.
-    REGISTER event      Script has to register for these events with love.  Can have filter.  love loops through all regisitered "scripts", applies filters, sends events.
+    REGISTER event      Script has to register for these events with love.  Can have filter.  love loops through all registered "scripts", applies filters, sends events.
     REQUEST event       Script has to request an event from love.  Can have a filter.  Love sends event straight back to the script.  Once.
                           This covers the "wait for return value" case as well.  events.return()?
   touch_start goes from extantz to LuaSL, via love.  Most of the rest go from love to LuaSL I think.  state_entry, state_exit are internal to LuaSL, timer should be.
@@ -217,7 +217,7 @@ More generic event system?
     Sensor and no_sensor might be common, but you request those, your silly fault, they have filters though.
       llSensor(string name, string id, integer type, float range, float arc)
       llSensorRepeat(string name, string id, integer type, float range, float arc, float rate)
-  Event types can have filters?  Events can be types?  In otherwords, generic filter system, attach say filters to say type events, etc.
+  Event types can have filters?  Events can be types?  In other words, generic filter system, attach say filters to say type events, etc.
     Figure this all out as we go along.
 
 parseStream() / send2() both -
@@ -530,7 +530,7 @@ I can use the llDialog() or purkle widgets, especially when you can rip
 them out of the main window to be their own windows.
 
 Once the files widget morphs into a proper inventory widget, I can use
-it in meta-impy for inventory AND an asyncronous file requestor.
+it in meta-impy for inventory AND an asynchronous file requester.
 
 Finally (I think) I could rip the meta-impy graphics pipeline a new one.
 
diff --git a/VISION.txt b/VISION.txt
index aef5719..7c353e6 100644
--- a/VISION.txt
+++ b/VISION.txt
@@ -2,7 +2,7 @@ I don't usually bother with even reading vision statements, and I'm a
 compulsive speed reader.  Before I know I should not be reading
 something, it's too late, already read it.  lol
 
-SledjHamr is my lifes passion though, I've been interested in this sort
+SledjHamr is my life's passion though, I've been interested in this sort
 of thing since the '80s and '90s.  I've been thinking about how best to
 describe it, and it's turning into a sort of vision statement.  So here
 it is.  I'll try to avoid being too hand wavy and wanky.
@@ -103,6 +103,6 @@ corporate computer.
 
 Other virtual world protocols will be supported, the SL / OS ones will be
 just a wrapper around the SledjHamr protocol.  For direct SledjHamr to
-SledjHamr things should be noticably faster and smoother.  Obviously any
+SledjHamr things should be noticeably faster and smoother.  Obviously any
 particular protocol will be limited by that protocols own limits.
 
diff --git a/docs/BVJ.html b/docs/BVJ.html
index ce1a24e..a539705 100644
--- a/docs/BVJ.html
+++ b/docs/BVJ.html
@@ -66,7 +66,7 @@ implement animating link sets, and interaction with the sim physics.</p>
 <h2> Semantics </h2>
 <p>The semantics are that the "Hips" and the "RightUpLeg" of something are animated. The mapping from the BVJ file's "NAME" fields to the avatar skeleton is straightforward, the names in the BVJ are matched against the names of the skeleton components. Then the appropriate rotations and translations are applied frame by frame.</p>
 <p>The point of the hierarchy is so that when a joint moves or rotates, it's children get carried along for the ride. When you turn the hips left in the sample BVJ, the whole body turns left.</p>
-<p>Note that the "offset" value isn't actually used when animating avatars. The position of the hips and the angles are all used, but no attempt is made to match the skeleton bone lengths to the BVH segment lengths. So I propose that we can eliminate them or make them optional to reducing lag and file size. The offsets are useful in other tools because they define a skeleton that can be visualized.</p>
+<p>Note that the "offset" value isn't actually used when animating avatars. The position of the hips and the angles are all used, but no attempt is made to match the skeleton bone lengths to the BVH segment lengths. So I propose that we can eliminate them or make them optional to reducing lag and file size. The offsets are useful in other tools because they define a skeleton that can be visualised.</p>
 <p>&nbsp;</p>
 <h2> Attachment points </h2>
 <p>The hierarchy portion of a BVJ is a fine place to express attachment points.</p>
@@ -101,13 +101,13 @@ implement animating link sets, and interaction with the sim physics.</p>
 <h2> Animating Prims </h2>
 <p>BVH was defined with skeletons in mind. But, at first glance it seems that if there were some two (or more) prim object with a root prim named "Hips" and another prim named "RightUpLeg" we should be able to animate that link set using this same BVH/BVJ file.</p>
 <p>The one issue is that segments in the BVH model are like vectors, they have a near end, a far end, a length, and they rotate about their near end. In particular bones have no width or depth, only length.</p>
-<p>So I propose adding "PIVOT":[x,y,z] to define about what part of a prim the prim rotates when being animated. When omitted the center of the prim is used, and is equivalent to "PIVOT":[0,0,0]. The pivot ranges from -1 to 1 on each axis with -1 meaning the small end and 1 the large end. For example consider a cylinder, "PIVOT":[0,0,0.5] would rotate about the point midway between the center of the cylinder and the +Z face of the cylinder, i.e. half way up to the top. "PIVOT":[0,0,1] would make the cylinder act like a normal bone making up a skeleton.</p>
+<p>So I propose adding "PIVOT":[x,y,z] to define about what part of a prim the prim rotates when being animated. When omitted the centre of the prim is used, and is equivalent to "PIVOT":[0,0,0]. The pivot ranges from -1 to 1 on each axis with -1 meaning the small end and 1 the large end. For example consider a cylinder, "PIVOT":[0,0,0.5] would rotate about the point midway between the centre of the cylinder and the +Z face of the cylinder, i.e. half way up to the top. "PIVOT":[0,0,1] would make the cylinder act like a normal bone making up a skeleton.</p>
 <p>&nbsp;</p>
 <h2> Animating Attached Prims </h2>
 <p>Things are interesting when I want to define an animation of my avy and an attachment to my avy. Suppose when applying an animation from a BVH or BVJ that I get to a joint named "tail" with a defined attachment point 103. If my avatar is wearing something at point 103, then search that object for a prim named "tail". If I find a prim named "tail" in the attachment then this joint's animation applies to that prim. And all the children of the "tail" joint in the animation are sought in the link set of the attachment.</p>
 <p>&nbsp;</p>
 <h3> Yet More Attachment Points </h3>
-<p>Why yes, that *does* mean attachments can have attachments, glad you asked. Suppose my tail has three bones, and the attachment point defined for the last bone is 104. I could attach the tail to point 103, and a pretty bow to point 104. The data model would be avy attachment point 103 has "thin neko tail with pink tip" attached, and avy attachment point 104 has "pretty bow" attached. But because point 104 is defined on a child joint of the joint with atachment point 103, the object "Pretty Bow" would move with a part of the tail, not with some random part of the avy.</p>
+<p>Why yes, that *does* mean attachments can have attachments, glad you asked. Suppose my tail has three bones, and the attachment point defined for the last bone is 104. I could attach the tail to point 103, and a pretty bow to point 104. The data model would be avy attachment point 103 has "thin neko tail with pink tip" attached, and avy attachment point 104 has "pretty bow" attached. But because point 104 is defined on a child joint of the joint with attachment point 103, the object "Pretty Bow" would move with a part of the tail, not with some random part of the avy.</p>
 <p>&nbsp;</p>
 <h2> Sampling and Keyframing </h2>
 <p>The BVH file format was originally created for motion capture. So it defines animations by means of sampling. The same way a motion picture film samples the world 24 times a second making still photographs, the BVH captures the values on all the channels at regular points in time. But not all animations are created by motion capture, perhaps most are made with a keyframing animation system.</p>
@@ -148,10 +148,10 @@ implement animating link sets, and interaction with the sim physics.</p>
 <p>&nbsp;</p>
 <p>&nbsp;</p>
 <h2> At This Time </h2>
-<p>The last enhancement I want to make is to add absolute time references. Consider using the BVJ file to define the animations of the hands on a analog clock. I would like to be able to express "At noon, all hands are pointing up." What this means is when invoking an animation we need to map from the Unix time to the animation's time. This is a linear mapping so two numbers are required, one expresses how many animation seconds elapse for each Unix second, the second specifies at what Unix time at which the animation time 0 occurs. There is a third number implied by looping animations. How long the animation is. Note a looping animation often begins to loop at some point <strong>after</strong> animation time 0 and ends <strong>before</strong> the largest animation time in the file. This is due to the types of interpolation used when keyframing. Linear interpolation requires two keyframes before a position can be known, quadratic 3, and cubic 4.</p>
+<p>The last enhancement I want to make is to add absolute time references. Consider using the BVJ file to define the animations of the hands on a analogue clock. I would like to be able to express "At noon, all hands are pointing up." What this means is when invoking an animation we need to map from the Unix time to the animation's time. This is a linear mapping so two numbers are required, one expresses how many animation seconds elapse for each Unix second, the second specifies at what Unix time at which the animation time 0 occurs. There is a third number implied by looping animations. How long the animation is. Note a looping animation often begins to loop at some point <strong>after</strong> animation time 0 and ends <strong>before</strong> the largest animation time in the file. This is due to the types of interpolation used when keyframing. Linear interpolation requires two keyframes before a position can be known, quadratic 3, and cubic 4.</p>
 <p>&nbsp;</p>
 <h2> Tools to Make BVJ Files </h2>
-<p>Currently there are none, but see <a href="InworldAnimationEditor.html">InworldAnimationEditor</a> for my ideas. It should be obvious how to transform a BVH into a BVJ file that uses sampling. By looking at the rates of change of channels it is possible to discover inflection points and use them to synthesize a keyframe representation that is a close match to a set of samples.</p>
+<p>Currently there are none, but see <a href="InworldAnimationEditor.html">InworldAnimationEditor</a> for my ideas. It should be obvious how to transform a BVH into a BVJ file that uses sampling. By looking at the rates of change of channels it is possible to discover inflection points and use them to synthesise a keyframe representation that is a close match to a set of samples.</p>
 <p>And, of course, I want to make this file format editable in-world using nice GUI and 3D editing tools. Basically a clone of QAvimator in the client.</p>
 <p>&nbsp;</p>
 <h2> Client to Client </h2>
diff --git a/docs/ClientHamr/README.GuiLua b/docs/ClientHamr/README.GuiLua
index ba0bf7d..8b62860 100644
--- a/docs/ClientHamr/README.GuiLua
+++ b/docs/ClientHamr/README.GuiLua
@@ -443,9 +443,9 @@ object = eo_add(EVAS_OBJ_LINE_CLASS, canvas);
     Eo.h                -> EO_DEFINE_CLASS is a macro that basically wraps eo_class_new(), and returns it's result.
 
 So Eo_Class is the type of a class, but it's A) opaque, B) deprecated! 
-It includes a pointor to the Eo_Class_Description, which includes the
+It includes a pointer to the Eo_Class_Description, which includes the
 actual name.  I'm not seeing anywhere the names of the get/set
-paramaters being passed into the system, or any way to look up a class
+parameters being passed into the system, or any way to look up a class
 based on name.  Not even a way to get to the public Eo_Class_Description
 from the opaque Eo_Class.
 
diff --git a/docs/Croquet-integration.html b/docs/Croquet-integration.html
index 1b4d072..b94ab09 100644
--- a/docs/Croquet-integration.html
+++ b/docs/Croquet-integration.html
@@ -62,7 +62,7 @@ plugin that leverages all of Squeak/Croquet's functionality to enhance
 some other viewer shouldn't be sneered at. Right now, the SL viewer (for
 example) barely provides access to raw mouse coordinates for UV tracking
 on a texture (the current media plugin scenario), but there's no reason
-why any arbitrary event or internet packet couldn't be intercepted and
+why any arbitrary event or Internet packet couldn't be intercepted and
 shunted off to squeak for pre/post processing.
 
 http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Proposed_Extension_to_Media_Plugin
@@ -87,7 +87,7 @@ http://www.metanomics.net/
 Start interacting with internal viewer events, and you can leverage
 physics/graphics creation/etc from the Squeak/Croquet side, and merge it
 directly into a local SL instance for custom puppeteering with the
-possiblilty of doing a P2P collaboration mechanima where individual
+possibility of doing a P2P collaboration mechanima where individual
 avatars can be controlled by a single machine using a script and/or
 timeline control interface. The resulting avatar activity can be
 "filmed" for mechanima, or could be uploaded to a central server for
@@ -97,8 +97,8 @@ http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Puppeteeri
 
 
 Instead of using 2D projections, you could also leverage the 3D portal
-system of Croquet to inject 3D cenes from Croquet into a given virtual
-world viewer, and either maintain a backk-end P2P connection between
+system of Croquet to inject 3D scenes from Croquet into a given virtual
+world viewer, and either maintain a back-end P2P connection between
 participants, or shoot the composite scene to a central server in some
 fashion using the existing virtual world protocols.
 
diff --git a/docs/Grid-data-flow.html b/docs/Grid-data-flow.html
index 5341ce9..1f3ff93 100644
--- a/docs/Grid-data-flow.html
+++ b/docs/Grid-data-flow.html
@@ -126,7 +126,7 @@
 <ul>
 <li>Looks for it's ROBUST URL.</li>
 <li>Registers the "dump asset" console command.</li>
-<li>Has a bunch of methods that just wrap ROBUST URL/asssets GET, DELETE, and POST requests.
+<li>Has a bunch of methods that just wrap ROBUST URL/assets GET, DELETE, and POST requests.
 <ul>
 <li>They check the cache first, do the request, and keep the cache up to date.</li>
 <li>Some make a handler() call. Not sure what that is.</li>
diff --git a/docs/InworldAnimationEditor.html b/docs/InworldAnimationEditor.html
index 755859a..82da594 100644
--- a/docs/InworldAnimationEditor.html
+++ b/docs/InworldAnimationEditor.html
@@ -6,13 +6,13 @@
 IAE is an idea to put an animation editor in world, much like the link set editor.
 <h2> Normal Editing </h2>
 <p>Step 1: right click avy &gt; edit pose &gt; a list of currently playing animations displays and you can choose one. Or right click avy &gt; new pose</p>
-<p>Step 2a: big edit style arrows sprout from the current joint (last edited, or hips by default). You can interact with it in all the standard ways users already know about with the build window. Move? Drag an arrow. Rotate? Drag a ring or the gray ball.</p>
+<p>Step 2a: big edit style arrows sprout from the current joint (last edited, or hips by default). You can interact with it in all the standard ways users already know about with the build window. Move? Drag an arrow. Rotate? Drag a ring or the grey ball.</p>
 <p>Step 2b: The edit window opens to the animation tab, or perhaps a whole new GUI. As a first approximation, imagine grabbing all the stuff from qavimator, squishing it into one or two 'floaters' windows inside the client.</p>
 <ul>
 <li>It has a help button</li>
 </ul>
 <ul>
-<li>It has a first use dialog</li>
+<li>It has a first use dialogue</li>
 </ul>
 <ul>
 <li>It includes a numbers area
@@ -99,13 +99,13 @@ IAE is an idea to put an animation editor in world, much like the link set edito
 </ul>
 <p>&nbsp;</p>
 <h2> Edit Multiple Animations </h2>
-<p>To take advantage of the 'absolute time' feature, you need to edit multiple animations at one time to make them interact well. Each animation could sprout a new line in the time line window. Would need some indicator which is the current animation and way to switch so the numbers boxes and meta info displays make sense. Time between the many animations is synchronized, so stepping a frame forward, steps all animations forward.</p>
+<p>To take advantage of the 'absolute time' feature, you need to edit multiple animations at one time to make them interact well. Each animation could sprout a new line in the time line window. Would need some indicator which is the current animation and way to switch so the numbers boxes and meta info displays make sense. Time between the many animations is synchronised, so stepping a frame forward, steps all animations forward.</p>
 <p>Most importantly, if you are granted permission, you should be able to right click on another avy, and choose edit pose.</p>
 <p>&nbsp;</p>
 <h2> Animate other stuff </h2>
-<p>Now, I described all this as if <a href="BVJ.html">BVJ</a>'s only applied to avatars. They don't. But the commands and behaviors are the same when editing animations for a door, an avatar, or an attachment (to an attachment to...) to an avatar.</p>
+<p>Now, I described all this as if <a href="BVJ.html">BVJ</a>'s only applied to avatars. They don't. But the commands and behaviours are the same when editing animations for a door, an avatar, or an attachment (to an attachment to...) to an avatar.</p>
 <p>&nbsp;</p>
 <h2> Possibilities </h2>
-<p>If you edit your pose, and the animations of 3 small balls, you could make a juggle animation with balls and hands synchronized. You can make "play catch" animations for two people and a ball. Be a multi-legged creature: add bones, attach prims, animate, enjoy.</p>
+<p>If you edit your pose, and the animations of 3 small balls, you could make a juggle animation with balls and hands synchronised. You can make "play catch" animations for two people and a ball. Be a multi-legged creature: add bones, attach prims, animate, enjoy.</p>
 </body>
 </html>
diff --git a/docs/LSL-functions-implemented.html b/docs/LSL-functions-implemented.html
index 73d05ea..7126a49 100644
--- a/docs/LSL-functions-implemented.html
+++ b/docs/LSL-functions-implemented.html
@@ -74,7 +74,7 @@
 </tr>
 <tr>
 <td>d</td>
-<td>Obsolete function that has been depecated.</td>
+<td>Obsolete function that has been deprecated.</td>
 </tr>
 <tr>
 <td>b</td>
diff --git a/docs/LuaSL-New-scripting-engine.html b/docs/LuaSL-New-scripting-engine.html
index 28049a2..cae5300 100644
--- a/docs/LuaSL-New-scripting-engine.html
+++ b/docs/LuaSL-New-scripting-engine.html
@@ -102,7 +102,7 @@ the C# side.  sigh</p>
 <p>A watchdog thread should be used to make sure no LuaSL script spends
 forever processing any event.</p>
 
-<p>Some form of serialization will need to be created for saving script
+<p>Some form of serialisation will need to be created for saving script
 state during shutdowns, passing script state to other threads /
 processes / computers.  Apparently Lua is good at this.</p>
 
@@ -124,7 +124,7 @@ our own OpenSim compatible cache module.</p>
 -------------</p>
 
 <p>I'll build a test harness.  It will be based on EFL Edje Lua, with
-buttons for triggering LSL events, SL style dialogs, and other goodies.</p>
+buttons for triggering LSL events, SL style dialogues, and other goodies.</p>
 
 <p>The initial goal will be to run standard MLP scripts.  They have minimal
 interface to the world, and exercise quite a bit of the rest of LSL. 
@@ -132,7 +132,7 @@ They are also quite common, and sometimes responsible for a lot of the
 script running load.</p>
 
 <p>Later I should add stock standard OpenCollar scripts from SL.  They are
-a bitch to get working under OpenSim, so would be good compatability
+a bitch to get working under OpenSim, so would be good compatibility
 tests.</p>
 
 <p>Various eina logging domains might be used to handle whisper, say, shout,
@@ -163,7 +163,7 @@ that compares against XEngine.</p>
 <h2> Making Lua look like LSL </h2>
 <p>There are syntactic differences between LSL and Lua. Although Lua is good as a metalanguage, those syntax differences wont go away by themselves. I think some sort of preprocessor would be needed to massage LSL into Lua as a first step in compiling.</p>
 <p>The preprocessor would have to start by parsing the LSL code into some sort of useful structure. Since the whole point of this exercise as that the OpenSim Xengine sucks, and it's written in C# anyway, don't want to use that. The Aurora script engine likely sucks less, but is still C#. The standard viewer source code includes an LSL parser written using flex and bison. It looks like C code, with C++ wrappers to wedge it nicely into the rest of the viewer code, but it generates C++ code full of LL classes.</p>
-<p>A test harness could be constructed using EFL Edje Lua to provide some push buttons that can trigger LSL events, provide dialogs, and display various state info. I think a good start is to put the MLP scripts and their notecards / animations into a directory, call that directory an Object, perhaps even implement some of the rest of SledjHamr with some object meta data (MLP will need access to the objects description). MLP is a good test subject, it tends to soak up a lot of sim resources, it's interface to the world is minimal, and it would exercise a lot of the non world interfacing stuff.</p>
+<p>A test harness could be constructed using EFL Edje Lua to provide some push buttons that can trigger LSL events, provide dialogues, and display various state info. I think a good start is to put the MLP scripts and their notecards / animations into a directory, call that directory an Object, perhaps even implement some of the rest of SledjHamr with some object meta data (MLP will need access to the objects description). MLP is a good test subject, it tends to soak up a lot of sim resources, it's interface to the world is minimal, and it would exercise a lot of the non world interfacing stuff.</p>
 <p>For reference, here is <a href="http://www.lua.org/manual">Lua reference manual</a>, <a href="http://www.lua.org/pil/">Lua PIL (for Lua 5.0)</a>, <a href="http://luajit.org/index.html">LuaJIT</a>, <a href="http://lslwiki.net/lslwiki/wakka.php?wakka=HomePage">LSL Wiki</a>, and <a href="http://wiki.secondlife.com/wiki/LSL_Portal">SL LSL portal</a>.</p>
 <p>&nbsp;</p>
 <h3> comments and line endings </h3>
@@ -190,7 +190,7 @@ that compares against XEngine.</p>
 </tr>
 <tr>
 <td>vector</td>
-<td>Three floats in the form &lt; x , y , z &gt;. Usually a position, color, or Euler rotation.</td>
+<td>Three floats in the form &lt; x , y , z &gt;. Usually a position, colour, or Euler rotation.</td>
 <td>&nbsp;</td>
 <td>Use a table and metatable, or a userdata.</td>
 </tr>
@@ -202,7 +202,7 @@ that compares against XEngine.</p>
 </tr>
 <tr>
 <td>key</td>
-<td>A UUID, specialized string in the same format as UUIDs everywhere.</td>
+<td>A UUID, specialised string in the same format as UUIDs everywhere.</td>
 <td>&nbsp;</td>
 <td>Can use a string, though perhaps a metatable or userdata would help? While it is true that it's just a string representation of a 32 bit integer, Lua has no way of faithfully representing 32 bit integers.</td>
 </tr>
@@ -237,7 +237,7 @@ that compares against XEngine.</p>
 <tbody>
 <tr>
 <td>()</td>
-<td>Expression re-odering.</td>
+<td>Expression re-ordering.</td>
 <td>()</td>
 <td>Exact match.</td>
 </tr>
@@ -301,7 +301,7 @@ until condition
 <tbody>
 <tr>
 <td>
-<pre>for (initialization; condition; update)
+<pre>for (initialisation; condition; update)
 {
   statements;
 }
@@ -333,7 +333,7 @@ end
 </pre>
 <p>Neither is a good match against LSL. To make things worse, the for variables in Lua are all local to the for loop, and it's not safe to change them in the loop. So we can't use Lua for loops to implement LSL for loops.</p>
 <p>A LSL for loop could be rewritten as -</p>
-<pre>initialization
+<pre>initialisation
 while (condition)
 {
         statements;
@@ -435,9 +435,9 @@ end
 <p>&nbsp;</p>
 <h2> Efficiently running thousands of scripts </h2>
 <p>(As a data point, Anarchadia has 3315 scripts running.)</p>
-<p>LSL scripts seem to be a good match for Lua states. Each script/state is independent, with no global data shared between them except for what is explicitly sent via communications calls, or calls to the system it's embedded in (the world interfacing). Lua scripts can be run in separate OS threads, which lets us make use of multi core CPUs. It's theoretically not too hard to serialize Lua, so running Lua states can be stopped, sent to some other computer, then restarted (good for attachment scripts when TPing).</p>
-<p>"luaproc is a concurrent programming library for Lua. It implements an approach, geared torwards massive concurrency support, which uses multiple indepedent lua_States as lightweight user threads ("Lua processes") and kernel threads as workers." Sounds like a good match, except it seems to be more an experiment for an academic paper than something useful. It is on github, with recent changes, well, recently added. <a href="https://github.com/askyrme/luaproc">https://github.com/askyrme/luaproc</a></p>
-<p>Lua has cooperative multitasking, but not preemptive. LSL is event driven, and no event processing should take forever. However, we would still need to deal with badly written scripts with infinite loops in them.</p>
+<p>LSL scripts seem to be a good match for Lua states. Each script/state is independent, with no global data shared between them except for what is explicitly sent via communications calls, or calls to the system it's embedded in (the world interfacing). Lua scripts can be run in separate OS threads, which lets us make use of multi core CPUs. It's theoretically not too hard to serialise Lua, so running Lua states can be stopped, sent to some other computer, then restarted (good for attachment scripts when TPing).</p>
+<p>"luaproc is a concurrent programming library for Lua. It implements an approach, geared towards massive concurrency support, which uses multiple independent lua_States as lightweight user threads ("Lua processes") and kernel threads as workers." Sounds like a good match, except it seems to be more an experiment for an academic paper than something useful. It is on github, with recent changes, well, recently added. <a href="https://github.com/askyrme/luaproc">https://github.com/askyrme/luaproc</a></p>
+<p>Lua has cooperative multitasking, but not pre-emptive. LSL is event driven, and no event processing should take forever. However, we would still need to deal with badly written scripts with infinite loops in them.</p>
 <ul>
 <li>Just let them run, continuing to keep that thread busy.</li>
 <li>Use a watchdog thread.
@@ -454,7 +454,7 @@ end
 </ul>
 </li>
 </ul>
-<p>I just had a thought. It might be worthwhile doing some typical compiler optimizations. Should see if doing that to the LSL helps. The Lua compiler might do that for us anyway, but certainly worth investigating. On the other hand, LuaJIT probably does most of that for us anyway. Might not be worthwhile.</p>
+<p>I just had a thought. It might be worthwhile doing some typical compiler optimisations. Should see if doing that to the LSL helps. The Lua compiler might do that for us anyway, but certainly worth investigating. On the other hand, LuaJIT probably does most of that for us anyway. Might not be worthwhile.</p>
 <p>&nbsp;</p>
 <h2> hacking up Lua source </h2>
 <p>I was hoping to avoid it, but I think we may have to hack up Lua source and not use any system supplied Lua library. The main reason is integers. LSL scripters expect integers to behave like 32 bit signed integers, not like 32 bit floats. So that's gonna cause no end of problems unless we have a a native 32 bit signed integer type in Lua. We can't just compile Lua to use 32 bit signed integers for it's number type, as then LSL floats get broken.</p>
@@ -495,7 +495,7 @@ end
 <p>Looks like LuaJIT gets us part of the way there, and it's supposed to be the fastest scripting language around, not much slower than C. Some of the above hacking wont be needed. It's a drop in replacement for Lua 5.1, but it has extras as well, some from 5.2, some already mentioned above in the hacks we night need to do. It has FFI, which also speeds up linking to C code, but that's very dangerous low level code. Should see if we can use it, THEN sandbox it away. See this link about sandboxing - <a href="http://osdir.com/ml/general/2011-02/msg23395.html">http://osdir.com/ml/general/2011-02/msg23395.html</a></p>
 <p>&nbsp;</p>
 <h2> Hooking it up to OpenSim </h2>
-<p>OpenSim has a mechanism for each script to choose the script engine it will run under, and even the language used. The first line of the script is interpreted by OpenSim if it's a comment. If it's not proper, OpenSim bitches about not being able to load a non existant script engine. Some examples of existing supported first lines -</p>
+<p>OpenSim has a mechanism for each script to choose the script engine it will run under, and even the language used. The first line of the script is interpreted by OpenSim if it's a comment. If it's not proper, OpenSim bitches about not being able to load a non existent script engine. Some examples of existing supported first lines -</p>
 <ul>
 <li>//XEngine:</li>
 <li>//XEngine:lsl</li>
@@ -709,7 +709,7 @@ SID.events.touch_start(2)
 <tr>
 <td>&nbsp;</td>
 <td>&nbsp;</td>
-<td>Pauses (yeilds) the script</td>
+<td>Pauses (yields) the script</td>
 </tr>
 </tbody>
 <caption>&nbsp;</caption>
@@ -738,7 +738,7 @@ SID.events.touch_start(2)
 <p>This script engine is only gonna be source code compatible, as we are not using Mono like every one else, so no such thing as binary compatibility can be provided. Source code is how scripts travel between grids anyway.</p>
 <p>There are many scripts from the millions of SL users, going back almost a decade of SL life. This means there are lots of scripts that originated from SL floating around the OpenSim community. Some are open source, some people brought scripts with them from SL that they wrote themselves, some are being used outside of SL with the permission of the scripts authors. It's theoretically impossible to steal script source code from SL, but it can probably be done through social engineering or some such. So I expect there are some illegal copies of SL scripts out there to. The point is, there's LOTS of scripts from SL. This is why SL compatibility is important. There is a huge pool of available scripts from SL.</p>
 <p>OpenSim added some extensions to LSL, and they are available on all the OpenSim grids, though some might be disabled. There is a smaller pool of scripts available from OpenSim. Scripters in OpenSim expect the those extensions to exist. Being compatible with those extensions would be important, and would help other OpenSim grids adopt this script engine if it turns out to be any good.</p>
-<p>Meta 7 was much smaller, not around for so long, and most scripts there either came from the SL pool of available scripts, the OpenSim pool of available scripts, or where written in Meta 7 by LSL scripters. I don't think the Meta 7 specific pool of scripts is anything other than small, the pool of scripts that need XMRE extensions is probably miniscule. OpenSim scripters don't expect those extensions to be available. So I don't think that being strictly compatible with XMRE is needed. Those small number of scripts written to use XMRE extensions can probably be converted to what I'm about to propose.</p>
+<p>Meta 7 was much smaller, not around for so long, and most scripts there either came from the SL pool of available scripts, the OpenSim pool of available scripts, or where written in Meta 7 by LSL scripters. I don't think the Meta 7 specific pool of scripts is anything other than small, the pool of scripts that need XMRE extensions is probably minuscule. OpenSim scripters don't expect those extensions to be available. So I don't think that being strictly compatible with XMRE is needed. Those small number of scripts written to use XMRE extensions can probably be converted to what I'm about to propose.</p>
 <p>I was lucky that kelly managed to save the reference pages from Meta 7 that covered their extensions in detail. I was able to go over them and figure out what to do. The summary is this - we should be able to provide similar functionality as XMRE, but not an exact clone. Lua already has powerful table stuff that is better than the XMRE array stuff, with a similar syntax for those parts that they share. No need to reinvent that wheel. Switch, continue, and exception handling could be treated as just adding things from other C like languages to the LSL C like language. On the other hand, it's gonna be simpler to just let people use Lua style stuff for these things. Writing an LSL scripting engine is already a huge job, the functionality is there in Lua, we could skip implementing the exact C like syntax and get more important things done. We can add in the C style syntax later if there is much call for it. The event stuff I would already be one third of the way there based on my current design. The other two thirds we could get just by designing the rest of that subsystem to suit. After all, not much difference if we store those structures in C or Lua, since it all has to go to Lua anyway. Might as well do it in Lua, and give the scripters access.</p>
 <p>This XMRE type stuff would be using the //LuaSL:LuaSL engine. Pure //LuaSL:LSL would not have it, and pure //LuaSL:Lua would not need it. So by writing the LuaSL variation first, we get some parts of XMRE like extensions for free, mostly the Lua table stuff that is similar to XMRE arrays, only better.</p>
 <p>&nbsp;</p>
@@ -766,12 +766,12 @@ myOtherList.myFunc(x, y);  // Same as the last one.
 
 </pre>
 <p>That last one uses a Lua syntactic sugar short cut. It works for table indexes that are strings with no spaces in them. This sort of thing essentially comes for free, since my script engine converts to Lua before compiling that. People that know Lua already know all those fun things you can do with Lua tables, they are quite powerful.</p>
-<p>Lua table initialization is a little different, but the LSL parser can handle that -</p>
+<p>Lua table initialisation is a little different, but the LSL parser can handle that -</p>
 <pre>a = {[f(1)] = g; "x", "y"; x = 1, f(x), [30] = 23; 45}
 
 </pre>
 <p>I'll leave it as an exercise for the reader to look up the Lua manual (which that example is taken from) to see what that line does. lol</p>
-<p>OK, commas and semi colons in that line are interchangeable, they just separate array elements. [30] = 23 means that the table element with the index of 30 is assigned the value 23. x = 1 is shorthand for ["x"] = 1, the table element with the string index of "x" is assigned the value 1. [f(1)] = g means that what ever value that the function call f(1) returns is used as an index, it's value is assigned the value of the variable g (no matter what type it is). The rest don't include any index, so are assigned to sequentially numbered indexes starting from 1. Apart from being more powerful, the only real difference with LSL is the use of {} instead of [] to contain the list initializers.</p>
+<p>OK, commas and semi colons in that line are interchangeable, they just separate array elements. [30] = 23 means that the table element with the index of 30 is assigned the value 23. x = 1 is shorthand for ["x"] = 1, the table element with the string index of "x" is assigned the value 1. [f(1)] = g means that what ever value that the function call f(1) returns is used as an index, it's value is assigned the value of the variable g (no matter what type it is). The rest don't include any index, so are assigned to sequentially numbered indexes starting from 1. Apart from being more powerful, the only real difference with LSL is the use of {} instead of [] to contain the list initialisers.</p>
 <p>&nbsp;</p>
 <h3> exception handling </h3>
 <p>The XMRE exception handling I could not do a clone of anyway, the system exceptions are not specified, except for the divide by zero, and even then I'm not so sure.</p>
diff --git a/docs/NGIW.Commands.html b/docs/NGIW.Commands.html
index 171df7a..c058a6f 100644
--- a/docs/NGIW.Commands.html
+++ b/docs/NGIW.Commands.html
@@ -10,7 +10,7 @@
 <ul>
 <li>PUT /obj/<strong>oid</strong>/eq -- adds a new event to the queue (at the end)</li>
 <li>PUT /obj/<strong>oid</strong>/eq/0 -- adds a new event to the queue at the <strong>beginning</strong></li>
-<li>PUT /obj/<strong>oid</strong>/eq/9 -- same behavior as PUT /obj/<strong>oid</strong>/eq</li>
+<li>PUT /obj/<strong>oid</strong>/eq/9 -- same behaviour as PUT /obj/<strong>oid</strong>/eq</li>
 <li>GET /obj/<strong>oid</strong>/eq -- returns the full event queue</li>
 <li>PUT /obj/<strong>oid</strong>/eq/<strong>eventid</strong> -- changes the event (or adds one) with id <strong>eventid</strong></li>
 <li>GET /obj/<strong>oid</strong>/eq/<strong>eventid</strong> -- returns the event with id <strong>eventid</strong> or an error</li>
@@ -34,7 +34,7 @@
    
    {"touch_start":{"force":13,"avy":"uuid","time":1311663233}}
 </pre>
-<p>So you can see it is fairly heavy weight compared to a tuned command language. I will investigate what subsequent requests look like when using the http 1.1 persistent connection features. At the worst the http overhead can be amortized across many commands by using the last two forms of request. The last would look like:</p>
+<p>So you can see it is fairly heavy weight compared to a tuned command language. I will investigate what subsequent requests look like when using the http 1.1 persistent connection features. At the worst the http overhead can be amortised across many commands by using the last two forms of request. The last would look like:</p>
 <pre>   PUT /eq HTTP/1.1
    Host: sim.ulat.or
    Content-Type: application/json
diff --git a/docs/NGIW.html b/docs/NGIW.html
index fab1f53..9d5c039 100644
--- a/docs/NGIW.html
+++ b/docs/NGIW.html
@@ -17,7 +17,7 @@
        "s":[0.5,0.5,0.5],
        "t":"/sim01/texture/t104" }
 </pre>
-<p>This is a really important data structure, it is the representation that forms part of the REST acronym. Since we are talking about a simulator, it isn't really complete to say an object has a certain position. In a simulator all properties of objects are dependant on time. The "at" field encodes some time representation. Probably something like Unix time * 1000, aka the number of miliseconds since 1970 UTC. The "id" field is the name of the object. The "p" field is the position encoded as a JSON array of 3 numbers, the "r" the rotation (quaternion) encoded as a JSON array of 4 numbers, the "s" the size encoded as a JSON array of 3 numbers, and "t" is the texture.</p>
+<p>This is a really important data structure, it is the representation that forms part of the REST acronym. Since we are talking about a simulator, it isn't really complete to say an object has a certain position. In a simulator all properties of objects are dependant on time. The "at" field encodes some time representation. Probably something like Unix time * 1000, aka the number of milliseconds since 1970 UTC. The "id" field is the name of the object. The "p" field is the position encoded as a JSON array of 3 numbers, the "r" the rotation (quaternion) encoded as a JSON array of 4 numbers, the "s" the size encoded as a JSON array of 3 numbers, and "t" is the texture.</p>
 <p>Since we are talking to a web server, and since we want to sometimes reference textures from other places than the simulator, the value of the texture is a URL. In this case a relative URL that leaves out the server, thus meaning the full URL to the texture is "<a href="http://simulat.or/sim01/texture/t104">http://simulat.or/sim01/texture/t104</a>". If the client needs the texture it can do a GET of "<a href="http://simulat.or/sim01/texture/t104">http://simulat.or/sim01/texture/t104</a>". There are ways to further compress this information, but let's not fix what isn't broken.</p>
 <p>Supose the user moved the box up 1 meter by some manipulation of the client. The client would "PUT /sim01/object/b104" with the data</p>
 <pre>   {   "at":1001,
@@ -27,7 +27,7 @@
        "s":[0.5,0.5,0.5],
        "t":"/sim01/texture/t104" }
 </pre>
-<p>Always transfering the full representation of an object could be wastefull and error prone so I slightly bend REST. I will use POST to an object to transmit only the changed fields. So "POST /sim01/object/b104" with the data</p>
+<p>Always transfering the full representation of an object could be wasteful and error prone so I slightly bend REST. I will use POST to an object to transmit only the changed fields. So "POST /sim01/object/b104" with the data</p>
 <pre>   {   "at":1001,
        "id":"b104",
        "p":[1,1,2]  }
@@ -42,9 +42,9 @@
 <p>in the first chunk, and more</p>
 <pre>   {"at":1000,...}, {"at":1001,...}, ...
 </pre>
-<p>in the second chunk. And so forth. Again, sending all the fields of all the objects, even for just the changed objects is wastefull. I see a few ways to go.</p>
+<p>in the second chunk. And so forth. Again, sending all the fields of all the objects, even for just the changed objects is wasteful. I see a few ways to go.</p>
 <p>If the server knows it has sent a full description of an object to a client, then future updates would, like the POST, only include the changed parts of the object.</p>
-<p>Alternatively, lowering the load on the server, the client closes the "GET /sim01/object" connection at some point, and does "GET /sim01/object?delta". At that point only updates are ever sent. If the client sees a change to some object it doesn't recognize, is opens a second connection and requests "GET /sim01/object/b999" for example to get the full description.</p>
+<p>Alternatively, lowering the load on the server, the client closes the "GET /sim01/object" connection at some point, and does "GET /sim01/object?delta". At that point only updates are ever sent. If the client sees a change to some object it doesn't recognise, is opens a second connection and requests "GET /sim01/object/b999" for example to get the full description.</p>
 <p>The third alternative is that all the server ever sends in response to "GET /sim01/object" is a stream of changes. If the client doesn't have enough information to render an object, it can query the individual object as in the first example.</p>
 </body>
 </html>
diff --git a/docs/Nails.html b/docs/Nails.html
index 1f99f4d..4eca750 100644
--- a/docs/Nails.html
+++ b/docs/Nails.html
@@ -17,7 +17,7 @@
 <p>It's entirely up to the web server how it actually stores the objects. I would recommend just storing the commands that define an object, but there will be things like IARs with XML files, exports from other viewers, and such around. Storing just the commands means that they can just be dumped direct to the command pump. XML would have to be translated first. On the other hand, inventories store non object assets, like textures, sound samples, scripts, etc. These could be stored in their native formats.</p>
 <p>&nbsp;</p>
 <h2> sim data store </h2>
-<p>Stores objects and their data that are in the sim. Again, it's a web server, but completely public. Though just like ordinary web servers, parts could be private to members only. Most of what was said about inventory data stores applies. There is a change of emphasis though, these would be public in general, with privacy an option, where inventory is private in general, with public being an option. Note that objects and other assets that are contents of a sim object should not be public by default, perhaps they could be handled by inventory data stores. Inventory data stores could be very simple data stores, with authorization, so would be perfect to be used as data stores for objects contents. Lets us reuse code and protocols, and can share code on the same server.</p>
+<p>Stores objects and their data that are in the sim. Again, it's a web server, but completely public. Though just like ordinary web servers, parts could be private to members only. Most of what was said about inventory data stores applies. There is a change of emphasis though, these would be public in general, with privacy an option, where inventory is private in general, with public being an option. Note that objects and other assets that are contents of a sim object should not be public by default, perhaps they could be handled by inventory data stores. Inventory data stores could be very simple data stores, with authorisation, so would be perfect to be used as data stores for objects contents. Lets us reuse code and protocols, and can share code on the same server.</p>
 <p>A sim data store could be a web proxy in front of any user in that sim. This is for any inventory data store an the users own computer, so that they can hide behind that sims proxy. Perhaps this could be another module? Not sure how to handle inventory transfers to offline users, especially those without some other web server to have an inventory data store on. Likely users will be a member of at least one web site somewhere that offers inventory data stores.</p>
 <p>&nbsp;</p>
 <h2> physics engine </h2>
@@ -38,7 +38,7 @@
 <p>So basically, it manages FIFO queues of commands, one per client. Filtering out any command type the client requests, filtering for objects of interest, or filtering object data on a frame rate basis per object. Every now and then, it has to sync the sim data store as well, so that the sim state is persistent across restarts, and clients can just download complete objects from the store when they first need them. Phew.</p>
 <p>A good optimisation would be for the sim data store and command pump to be the same module. The pump has to keep the current state of objects in memory anyway, and knows how to pump the command data out, all it needs is a persistent backing store to write to and read at start up.</p>
 <p>As an optional wrapper around the command pump, could be translators for those that want REST, JSON, XMLRPC, or other bloat. With commands to switch to and from these and the native binary protocol. Native binary protocol must always be supported, and always be the default until requested otherwise. 99.9999% of Internet traffic does not NEED to be human readable on the wire, human readable is not so easy for computers to read, they need to translate it. Why slow everyone down? I will insist that these protocol translators operate outside the command pump, don't want to slow that down to satisfy peoples longing for bloat. They should be separate processes, preferably operating on separate cores, or even entirely different computers. They will naturally talk the tight binary protocol to the command pump, just like every one else.</p>
-<p>There are three basic internet protocols we could use as the basis for the wire traffic. TCP, UDP, and SCTP. SCTP would be a great candidate, except for the lack of MacOS support. I think we should try SCTP, with TCP as backup, SCTP support might come to Mac sooner or later.</p>
+<p>There are three basic Internet protocols we could use as the basis for the wire traffic. TCP, UDP, and SCTP. SCTP would be a great candidate, except for the lack of MacOS support. I think we should try SCTP, with TCP as backup, SCTP support might come to Mac sooner or later.</p>
 <p>&nbsp;</p>
 <h2> command channels and language </h2>
 <p>In other parts of this document, a command channel is mentioned. Most of the data flowing through this command channel would be for setting or changing prim parameters. I propose a binary format based on llSetLinkPrimitiveParams() <a href="http://lslwiki.net/lslwiki/wakka.php?wakka=llSetLinkPrimitiveParams&amp;show_comments=1#comments">http://lslwiki.net/lslwiki/wakka.php?wakka=llSetLinkPrimitiveParams&amp;show_comments=1#comments</a></p>
@@ -176,7 +176,7 @@
 <h2> Windlight commands. </h2>
 <p>&nbsp;</p>
 <h2> Avatar commands. </h2>
-<p>Some of this could be dealt with by treating the avatar as a prim. In fact, Alices proposed animation system deals with animating avatars and prims the same way.</p>
+<p>Some of this could be dealt with by treating the avatar as a prim. In fact, Alice's proposed animation system deals with animating avatars and prims the same way.</p>
 <p>&nbsp;</p>
 <h2> Animation commands. </h2>
 <p>Alice is working on that over at the <a href="BVJ.html">BVJ</a> page.</p>
diff --git a/docs/OMG-WTF-BBQ.html b/docs/OMG-WTF-BBQ.html
index 4058bc4..5e48a14 100644
--- a/docs/OMG-WTF-BBQ.html
+++ b/docs/OMG-WTF-BBQ.html
@@ -4,7 +4,7 @@
 </head>
 <body bgcolor="black" text="white" alink="red" link="blue" vlink="purple">
 <p>The rationale</p>
-<p>Scripts, and sometimes objects, can invoke a file purely by its UUID. It had been suggested we might replace the existing UUID system with something where the file is invoked via some sort of machine address, pointing to the internet address of the grid or world -- actually, call it an OMG Node -- the file originated from. The problem with this sort of approach is that, a given VR world could go away, making that direct addressing fail, a given world could change its name and location, causing the direct addressing to break. What we need is a system where the UUID of a file is location-agnostic. That is to say, it shouldn't matter where the file originally came from, it should only matter that there is still a way to bring it in when you need it.</p>
+<p>Scripts, and sometimes objects, can invoke a file purely by its UUID. It had been suggested we might replace the existing UUID system with something where the file is invoked via some sort of machine address, pointing to the Internet address of the grid or world -- actually, call it an OMG Node -- the file originated from. The problem with this sort of approach is that, a given VR world could go away, making that direct addressing fail, a given world could change its name and location, causing the direct addressing to break. What we need is a system where the UUID of a file is location-agnostic. That is to say, it shouldn't matter where the file originally came from, it should only matter that there is still a way to bring it in when you need it.</p>
 <p>At that, while it might be possible to go into a script and change the machine-address for the file if it breaks, that makes the assumption one would be able to edit the script, or know what the new pseudo-UUID for that file would be in order to replace it. For one thing, a lot of scripts are going to be no-mod, so even if you did know what that new pseudo-UUID to replace in there was, you wouldn't be able to fix it anyway.</p>
 <p>What needs to exist is some means of identifying what world a given set of files came from by some kind of UUID subset. That is, each file made on a particular, distinct part of the OMG needs a unique identifier that starts out all UUIDs made there, and that the rest of the UUID would be appended to that would uniquely identify a file that was created there. This unique identifier for an OMG Node also needs to exist in a form that doesn't change when the name or location of the OMG Node changes.</p>
 <p>OMG Node</p>
diff --git a/docs/SledjHamr.html b/docs/SledjHamr.html
index a138287..b2371f1 100644
--- a/docs/SledjHamr.html
+++ b/docs/SledjHamr.html
@@ -30,7 +30,7 @@
 <h3> in world asset server </h3>
 <p>Unpack an OAR into a web server. An OAR file is supposed to be a complete copy of everything in the sim, including meta data like access lists. In reality, they do seem to miss prim description and prim sit position data at least. We can always add what is missing. Existing OpenSim versions can create these OAR files from the console. My experience with meta 7 is that A) OAR file creation can be automated. B) OAR file creation is not a noticeable load on a busy server. I say these things since I had written a simple script to make OAR file backups of every meta 7 sim four times a day. No one noticed any extra lag.</p>
 <p>The contents of an OAR file are basically a bunch of XML files to describe the objects in the sim, and the actual assets used to make up those objects. The example OAR files I looked at followed the 80/20 rule fairly well, the assets being 80% of the data, the descriptions being 20%. There are also a few tiny XML files containing the other sim meta data, and one file containing raw terrain data. The assets are just ordinary files, jpeg200, ogg, bvh, lsl, etc. Though the notecard files have some extra header info at the beginning for some odd reason. One thing that is absent is a central description of what goes where. Each objects XML description includes it's position info though.</p>
-<p>When a user arrives at a sim, they could start by downloading those object description XML files, and the terrain file. Those XML files could compress well 20:1 if all done at once as a tarball. The terrain file is more 2:1 if compressed. This is gz compression, which is supported by typical web servers and web browsers on the fly. Once the user has downloaded the description XML files, they can start to rez things within their draw distance, requesting the textures from the assets part of the unpacked OAR file as needed. Rezzing terrain would be - download the terrain raw data (giving the terrain shape), download the sims settings XML file (giving the texture UUIDs and parameters for the terrain textures), dowload the four terrain textures, then generate the terrain randomly as usual. Note that on first arrival, generally only texture assets would be downloaded. Things like sounds and animations would only need to be downloaded when the sims scripts say they are needed. Notecards and scripts embedded in objects would only need to be downloaded when an authorised user opens them for editing.</p>
+<p>When a user arrives at a sim, they could start by downloading those object description XML files, and the terrain file. Those XML files could compress well 20:1 if all done at once as a tarball. The terrain file is more 2:1 if compressed. This is gz compression, which is supported by typical web servers and web browsers on the fly. Once the user has downloaded the description XML files, they can start to rez things within their draw distance, requesting the textures from the assets part of the unpacked OAR file as needed. Rezzing terrain would be - download the terrain raw data (giving the terrain shape), download the sims settings XML file (giving the texture UUIDs and parameters for the terrain textures), download the four terrain textures, then generate the terrain randomly as usual. Note that on first arrival, generally only texture assets would be downloaded. Things like sounds and animations would only need to be downloaded when the sims scripts say they are needed. Notecards and scripts embedded in objects would only need to be downloaded when an authorised user opens them for editing.</p>
 <p>The alternative that I mentioned above, would be to start with some central description of the sim. Basically the equivalent of a web page, index.omg maybe. This would be a text (or binary) file that only includes the list of object names, their X,Y,Z location, and rotation. Perhaps some small amount of meta data to, like the terrain meta data mentioned above. Then the user would only have to download the object description XML (or binary command list) files for those objects within their draw distance. This is a good idea I think. It maps well to the web that everyone is familiar with, and allows a lot of flexibility. For example, this file and all other data could be generated on the fly by PHP code. Typical CMS systems could be used to manage this content just like all the other web content they manage. This means we just supply protocol and data structures, plus a simple implementation, then step out of the way and let people implement their own variations using tools they are long familiar with. An IETF RFC could be in the works.</p>
 <p>All of this leaves out the LL inspired DRM system. Our objective to smash the garden walls means that such a system is of no value, there is no central server to control that. On the other hand, we replace it with the mature and well understood web site content protection systems already in existence. In particular, the only real way on the web to protect IP is to keep it on the server, once the client has it, they can copy things no matter what you do. This already applies to all web content. The only thing you can protect from copying is the web back end code, coz you never transmit that to clients. The same level of protection is thus now given to LSL code. Unless it's being edited, it's never sent across the 'net, only executed by servers. When unpacking the OARs, we can leave out the LSL files.</p>
 <p>To get there from here, we can start simple. Server side really is just a matter of creating OARs and unpacking them into a web server. The web server can be very simple (I've written a suitable one in one page of Java many years ago). At this stage just dealing with static data, with a last modified header support, would be a great start for experimentation. Client code can be modified to check the web server first, then fall back to the usual methods. Simple things we can do to start with, adding the more interesting stuff later. To start with, OpenSim would still be dealing with this stuff, the first step is to run side by side, so we have a small first step, and can use OpenSim as a crutch. The next step might be to generate this central description index.omg file from the existing data in the OAR, then the client can check for that file first. Meshes are new to the old systems, and I already am working on code for those, they will likely be the first things served via an index.omg file.</p>
@@ -129,7 +129,7 @@
 <p>People can run their own copy of a site, and invite others, to take the load off the server. Still talking to the server for server resident objects. These can be private, similar to layers and dimensions in other virtual worlds.</p>
 <p>There is a way for some 3D tools to send updates in real time to other tools, we should definitely support that.</p>
 <p>People could have a little movable sim of their own running from their computer. Like the insides of a car or boat, moving around other peoples sims.</p>
-<p>Touch mode - click on something to touch it, left button for touching with left hand, right button for right hand, dail up the strength of the touch with the mouse wheel. A mouse drag will naturally drag, push, or pull something, with force set by the mouse wheel, and at the speed that the user drags the mouse. Extend this so that any input device can be used to control any limb, digit, or other joint. Professional puppeteers may have open protocols for this sort of thing.</p>
+<p>Touch mode - click on something to touch it, left button for touching with left hand, right button for right hand, dial up the strength of the touch with the mouse wheel. A mouse drag will naturally drag, push, or pull something, with force set by the mouse wheel, and at the speed that the user drags the mouse. Extend this so that any input device can be used to control any limb, digit, or other joint. Professional puppeteers may have open protocols for this sort of thing.</p>
 <p><br /> This work is licensed under a <a href="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons Attribution-ShareAlike 3.0 Unported License</a>.</p>
 </body>
 </html>
diff --git a/docs/SledjHamr/portals.txt b/docs/SledjHamr/portals.txt
index 591460b..28498c2 100644
--- a/docs/SledjHamr/portals.txt
+++ b/docs/SledjHamr/portals.txt
@@ -9,7 +9,7 @@ deliberate policy decisions by LL.  LL knows their content is the key to
 their business, even though almost all of it was created by the users,
 LL locks it up tight.  So people visiting OpenSim grids from SL have to
 create a new avatar from scratch, which is such a major pain that most
-people balk at that and don't bother.  And they can't bring their
+people baulk at that and don't bother.  And they can't bring their
 inventory with them, inventory they paid for and spent years collecting.
 
 In SledjHamr, as well as allowing completely unrestricted and easy
@@ -50,7 +50,7 @@ gate" of your home world.
 
 Any one on your home worlds access list can step through this portal to
 get to your home world.  Simple to use, no figuring out HyperGate URLs
-and copy pasting them, no manual messing with hard to use acces systems. 
+and copy pasting them, no manual messing with hard to use access systems. 
 Though it would still be possible to create URLs to in world places, to
 store as landmarks, to email to someone, or to copy'n'paste into
 farcebook.
diff --git a/killem.sh b/killem.sh
index 262d5d2..7b4d3a2 100755
--- a/killem.sh
+++ b/killem.sh
@@ -1,6 +1,6 @@
 #!/bin/bash
 
-# TODO - Deal with the valgrind left overs, by scanning the output of the following lines, pciking out the PIDs, then "kill -KILL pid"
+# TODO - Deal with the valgrind left overs, by scanning the output of the following lines, picking out the PIDs, then "kill -KILL pid"
 ps aux | grep love
 ps aux | grep LuaSL