From 7666177682592afe8bbccc722e803aec69dd152b Mon Sep 17 00:00:00 2001 From: David Walter Seikel Date: Wed, 28 May 2014 16:15:21 +1000 Subject: Run the docs through a spell checker. I usually use an editor that doesn't have one. --- docs/ClientHamr/README.GuiLua | 6 +++--- docs/ClientHamr/README.woMan | 2 +- docs/ClientHamr/ScriptEditor.txt | 2 +- docs/README.Bookie | 2 +- docs/README.LuaSL | 6 +++--- docs/README.REST | 2 +- docs/The_Naminator.txt | 2 +- docs/love.txt | 4 ++-- docs/portals.txt | 8 ++++---- 9 files changed, 17 insertions(+), 17 deletions(-) (limited to 'docs') diff --git a/docs/ClientHamr/README.GuiLua b/docs/ClientHamr/README.GuiLua index f60d7b2..72f13f3 100644 --- a/docs/ClientHamr/README.GuiLua +++ b/docs/ClientHamr/README.GuiLua @@ -97,7 +97,7 @@ something else), then unmarshal the result before sending it back to Lua. The second alternative, which the host app must REALLY request, is for -the host app to say "I'm REALLY going out of my way to be threadsafe, +the host app to say "I'm REALLY going out of my way to be thread safe, just call me direct". No edje wrapper function, BUT the host app still has to use edje to register this function. @@ -568,8 +568,8 @@ Windows with widgets relative to each other. Manual association of widgets to methods. Can include tool tip string, enabled, visible, hover cursor, bounding rectangle?, mouse opaque?, tab groups, font (name, size, style, and alignment). More stuff, typically hidden in the OO somewhere. sigh -Generally uses fixed image and colour names, which skins overide. -Skins can also overide the XML files. +Generally uses fixed image and colour names, which skins override. +Skins can also override the XML files. Translations provide override XML files that need only override the text bits. diff --git a/docs/ClientHamr/README.woMan b/docs/ClientHamr/README.woMan index 1b3bbe0..990f9c5 100644 --- a/docs/ClientHamr/README.woMan +++ b/docs/ClientHamr/README.woMan @@ -25,7 +25,7 @@ viewer is not TPVP (Third Party Viewer Policy, an LL thing) compliant, and LL are just more anal than the rest of the universe. NOTE: since I started this, LL in their *cough* infinite wisdom *cough*, -decided that support of OpenSIm was a Really Bad Thing, so their viewers +decided that support of OpenSim was a Really Bad Thing, so their viewers are no longer capable of dealing with other grids. LL have even gone as far as try to get other viewers to not support other grids. As far as woMan is concerned, this just means that LL viewers, and viewers that diff --git a/docs/ClientHamr/ScriptEditor.txt b/docs/ClientHamr/ScriptEditor.txt index 357793a..28cb6a3 100644 --- a/docs/ClientHamr/ScriptEditor.txt +++ b/docs/ClientHamr/ScriptEditor.txt @@ -22,5 +22,5 @@ the command finishes. Naturally that command could be "vi script.lsl", Toybox and terminology works under cygwin and Mac OS X. -Rob pulls his finger out and starts putting my editting stuff in toybox +Rob pulls his finger out and starts putting my editing stuff in toybox so I can progress with this. diff --git a/docs/README.Bookie b/docs/README.Bookie index 1a49f27..bec4b19 100644 --- a/docs/README.Bookie +++ b/docs/README.Bookie @@ -28,6 +28,6 @@ versions of the libraries needed in that. If not found, it could invoke an OS specific method of installing a suitable library. If that fails, it can download a SledjHamr specific version into the SledjHamr installed directory. So it tries to do the right thing first, and -gradually fallsback to doing the wrong thing like LL does. +gradually falls back to doing the wrong thing like LL does. That's the theory, in practice, gonna be a pain. diff --git a/docs/README.LuaSL b/docs/README.LuaSL index 69bb45c..ed2ffdd 100644 --- a/docs/README.LuaSL +++ b/docs/README.LuaSL @@ -1,7 +1,7 @@ Refer to - http://www.infinitegrid.org/drupal/content/LuaSL_New_scripting_engine LuaSL is a Lua based LSL scripting engine that will aim for LSL -compatability first, then adding Lua extensions. It aims to replace the +compatibility first, then adding Lua extensions. It aims to replace the woeful XEngine from OpenSim, and at a later stage, be the basis for a client side scripting engine. @@ -38,7 +38,7 @@ future. THIS IS WHERE WE ARE RIGHT NOW. -Should implement embedded Lua somehow. Probaly the best thing to do is +Should implement embedded Lua somehow. Probably the best thing to do is to have comments like - //Lua: local t = {1, 3, 42, x='something', 'something else} @@ -55,7 +55,7 @@ Incoming commands invoke LSL events via the LuaSL state metatable. LL and OS functions that impact the world will be converted to nails commands sent to the command pump. -Initialy, since this is the first thing being written, a nails command +Initially, since this is the first thing being written, a nails command pump client needs to be installed into OpenSim's C# stuff. Though it might be possible to talk directly to ROBUST instead. Think I'll try the ROBUST route, see how far I can get. That's the general principle diff --git a/docs/README.REST b/docs/README.REST index 2981827..0d773f8 100644 --- a/docs/README.REST +++ b/docs/README.REST @@ -1,2 +1,2 @@ -REST is probaly good to apply to the web server part. Alice wants JSON +REST is probably good to apply to the web server part. Alice wants JSON to, but see nails. diff --git a/docs/The_Naminator.txt b/docs/The_Naminator.txt index 3465d44..8a6a25e 100644 --- a/docs/The_Naminator.txt +++ b/docs/The_Naminator.txt @@ -6,7 +6,7 @@ and URLs, so the names have to be munged accordingly. A further issue is that different in world objects can have the same name. Lots of copies of the same thing, or two different things that happen to be called the same thing. No one is gonna individually name each tree in a -forest, or every lampost in the city. File names and URLs have to be +forest, or every lamppost in the city. File names and URLs have to be unique. The Naminator deals with munging names to deal with these issues. It should generate names that are compatible with a variety of operating and file systems, as well as being URL compatible. This is diff --git a/docs/love.txt b/docs/love.txt index e21b18b..d95dc30 100644 --- a/docs/love.txt +++ b/docs/love.txt @@ -57,7 +57,7 @@ the major amounts of web infrastructure that already exists and already solves most of the problems that currently plague virtual worlds based on SL tech. -The down side of separated is that changes might be slower propogating +The down side of separated is that changes might be slower propagating to the web server, and there might be two copies of any given set of assets in memory at once. @@ -127,7 +127,7 @@ inspired by git using SHA-1 hashes for content addressable assets. SHA-1 hashes are 40 character hex codes representing 160 bit numbers that are calculated based on the content. So the same content will give the same SHA-1 hash. Git has proved that you only need the first digits -of the SHA-1 hash to ensure uniqueness, so it's feasable to use only the +of the SHA-1 hash to ensure uniqueness, so it's feasible to use only the first 128 bits of SHA-1 hashes to squeeze it into a UUID for the purposes of uniquely identifying assets. Precisely what git does. This means it could be backwards compatible with LL's use of UUIDs. diff --git a/docs/portals.txt b/docs/portals.txt index c2ba0a1..d54c235 100644 --- a/docs/portals.txt +++ b/docs/portals.txt @@ -3,7 +3,7 @@ SledjHamrs killer feature, or one of them. A major reason for SledjHamr is to break down the garden walls. We do this by allowing free travel between peoples virtual worlds. In OpenSim this is done by HyperGrid, which is clunky and hard to use. Second Life -deliberatly has no such system. Even worse, it's hard convincing people +deliberately has no such system. Even worse, it's hard convincing people in SL to visit your grid, coz it's all very hard, again due to 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, @@ -31,7 +31,7 @@ using OpenSim and its HyperGrid system. Later it would be SledjHamr style worlds as well. A portal would be like Cobalt style portals, you can see the destination -in real time, and step through it to go there. They can be permenant, +in real time, and step through it to go there. They can be permanent, or temporary. You can carry them in your inventory, they could just be normal scripted in world objects. @@ -46,7 +46,7 @@ rez it anywhere. Or you could rez this portal object in the world you are in. Either way, once the portal is in a world, it connects to your home world, showing a view of your front gate, maybe including your lovely garden in your front yard. The portal connects to the "front -gate" of your homeworld. +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 @@ -59,7 +59,7 @@ Portals rezzed in world could be temporary, and vanish after who ever you invited to come stepped through it. Or time out several minutes later so as not to clutter the universe with left over portals. Or deleted by the owner / managers of the world you left them, or deleted -yourself from your own world. Portals could be permenant. Say you +yourself from your own world. Portals could be permanent. Say you found a larger world that you and the owner decide you wish to be a part of. Portals could be left on both worlds linking them. The "portal" could just be reconfiguring each world to locate the other world near -- cgit v1.1