aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/BVJ.html14
-rw-r--r--docs/ClientHamr/README.BVJ20
-rw-r--r--docs/LuaSL-New-scripting-engine.html119
-rw-r--r--docs/Nails.html4
-rw-r--r--docs/SledjHamr/README.LuaSL121
-rw-r--r--docs/SledjHamr/README.nails14
-rw-r--r--docs/index.html25
7 files changed, 147 insertions, 170 deletions
diff --git a/docs/BVJ.html b/docs/BVJ.html
index ab1499c..ce1a24e 100644
--- a/docs/BVJ.html
+++ b/docs/BVJ.html
@@ -3,6 +3,10 @@
3<head> 3<head>
4</head> 4</head>
5<body bgcolor="black" text="white" alink="red" link="blue" vlink="purple"> 5<body bgcolor="black" text="white" alink="red" link="blue" vlink="purple">
6<p>BVJ is extensions to the BVH animation format used by SL technology.
7It's in the ClientHamr section coz on the server side, they are just
8dealt with as blobs to be sent to the viewers. This may change if we
9implement animating link sets, and interaction with the sim physics.</p>
6<h2> Syntax </h2> 10<h2> Syntax </h2>
7<p>This example BVH is 20 lines 505 characters, and defines a pointless animation on a trivial skeleton.</p> 11<p>This example BVH is 20 lines 505 characters, and defines a pointless animation on a trivial skeleton.</p>
8<pre> HIERARCHY 12<pre> HIERARCHY
@@ -157,5 +161,15 @@
157<p>Fang Said: See the very last paragraph of <a href="SledjHamr.html">SledjHamr</a>, the "random notes from my old Web 3.0 document " section at the bottom, to see one suggested method of moving your hand.</p> 161<p>Fang Said: See the very last paragraph of <a href="SledjHamr.html">SledjHamr</a>, the "random notes from my old Web 3.0 document " section at the bottom, to see one suggested method of moving your hand.</p>
158<p>Alice Replied: Looks cool, but requires Inverse Kinematics (if you mean the touch commands), or some puppeteer protocol that I know nothing about.</p> 162<p>Alice Replied: Looks cool, but requires Inverse Kinematics (if you mean the touch commands), or some puppeteer protocol that I know nothing about.</p>
159<p>What I imagine right now is <a href="InworldAnimationEditor.html">InworldAnimationEditor</a></p> 163<p>What I imagine right now is <a href="InworldAnimationEditor.html">InworldAnimationEditor</a></p>
164<h2>links</h2>
165<p>Some useful links for actually writing animation code -</p>
166<a href="https://en.wikipedia.org/wiki/Portal:Computer_graphics">Portal:Computer_graphics</a>
167<a href="https://en.wikipedia.org/wiki/3D_computer_graphics">3D_computer_graphics</a>
168<a href="https://en.wikipedia.org/wiki/Skeletal_animation">Skeletal_animation</a>
169<a href="https://en.wikipedia.org/wiki/Morph_target_animation">Morph_target_animation</a>
170<a href="https://en.wikipedia.org/wiki/Inverse_kinematics">Inverse_kinematics</a>
171<p>&nbsp;</p>
172<a href="http://bvhacker.com/">bvhacker.com</a>
173<a href="http://www.character-studio.net/bvh_file_specification.htm">bvh_file_specification</a>
160</body> 174</body>
161</html> 175</html>
diff --git a/docs/ClientHamr/README.BVJ b/docs/ClientHamr/README.BVJ
deleted file mode 100644
index a232320..0000000
--- a/docs/ClientHamr/README.BVJ
+++ /dev/null
@@ -1,20 +0,0 @@
1Refer to - docs/BVJ.html
2
3BVJ is extensions to the BVH animation format used by SL technology.
4It's in the ClientHamr section coz on the server side, they are just
5dealt with as blobs to be sent to the viewers. This may change if we
6implement animating link sets, and interaction with the sim physics.
7
8Also -
9======
10
11Some useful links for actually writing animation code -
12
13https://en.wikipedia.org/wiki/Portal:Computer_graphics
14https://en.wikipedia.org/wiki/3D_computer_graphics
15https://en.wikipedia.org/wiki/Skeletal_animation
16https://en.wikipedia.org/wiki/Morph_target_animation
17https://en.wikipedia.org/wiki/Inverse_kinematics
18
19http://bvhacker.com/
20http://www.character-studio.net/bvh_file_specification.htm
diff --git a/docs/LuaSL-New-scripting-engine.html b/docs/LuaSL-New-scripting-engine.html
index b6f9cfa..b8c730f 100644
--- a/docs/LuaSL-New-scripting-engine.html
+++ b/docs/LuaSL-New-scripting-engine.html
@@ -3,6 +3,14 @@
3<head> 3<head>
4</head> 4</head>
5<body bgcolor="black" text="white" alink="red" link="blue" vlink="purple"> 5<body bgcolor="black" text="white" alink="red" link="blue" vlink="purple">
6<p>LuaSL is a Lua based LSL scripting engine that will aim for LSL
7compatibility first, then adding Lua extensions. It aims to replace the
8woeful XEngine from OpenSim, and at a later stage, be the basis for a
9client side scripting engine.</p>
10<p>To compile this, you will need Enlightenment Foundation Libraries (EFL)
11installed in either /opt/e17 or /usr. These are typical places it get's
12installed in. You will also need flex. The rest of the dependencies
13are in the ../libraries directory.</p>
6<h1> write our own </h1> 14<h1> write our own </h1>
7<p>I had considered in the <a href="SledjHamr.html">SledjHamr</a> document writing a new script engine from scratch in Lua. This is what I wrote -</p> 15<p>I had considered in the <a href="SledjHamr.html">SledjHamr</a> document writing a new script engine from scratch in Lua. This is what I wrote -</p>
8<p>"I'd love to write a Lua implementation of LSL, I'm sure Alice would want to write a Scheme one."</p> 16<p>"I'd love to write a Lua implementation of LSL, I'm sure Alice would want to write a Scheme one."</p>
@@ -36,11 +44,120 @@
36<h2> Design </h2> 44<h2> Design </h2>
37<p>There are a number of ways we can go about this. Do we write the entire scripting engine in Lua, and only interface with C# for those things we really need to in order to get OpenSim to do in world stuff? Do we write a LSL to Lua translation layer that then compiles the Lua? The OpenSim engine I understand does that, translates LSL to C# then compiles that to .NET. Could we start with a higher level of Lua that interfaces with the existing LSL support functions in OpenSim? Can we even rely on those LSL support functions being a stable API? Should we start by experimenting with Lua's meta language features, see how close we can get it to look like LSL syntax? Perhaps concentrate on those parts of the job that don't require interfacing to OpenSim, and hope that SledjHamr can meet it half way to avoid the entire .NET thing?</p> 45<p>There are a number of ways we can go about this. Do we write the entire scripting engine in Lua, and only interface with C# for those things we really need to in order to get OpenSim to do in world stuff? Do we write a LSL to Lua translation layer that then compiles the Lua? The OpenSim engine I understand does that, translates LSL to C# then compiles that to .NET. Could we start with a higher level of Lua that interfaces with the existing LSL support functions in OpenSim? Can we even rely on those LSL support functions being a stable API? Should we start by experimenting with Lua's meta language features, see how close we can get it to look like LSL syntax? Perhaps concentrate on those parts of the job that don't require interfacing to OpenSim, and hope that SledjHamr can meet it half way to avoid the entire .NET thing?</p>
38<p>I choose to do those last two things - see how far I can get Lua to look like LSL, and concentrate on the parts that don't require interfacing to OpenSim, hoping that I can avoid the entire .NET thing.</p> 46<p>I choose to do those last two things - see how far I can get Lua to look like LSL, and concentrate on the parts that don't require interfacing to OpenSim, hoping that I can avoid the entire .NET thing.</p>
47
48<p>The basic design will be made up as I go along, but so far I have this -</p>
49
50<p>A parser parses an LSL script, validating it and reporting errors.</p>
51
52<p>A translator takes the result of the parse, and converts it into Lua
53source. Each LSL script becomes a Lua state. LSL states are handled as
54Lua tables, with each LSL state function being a table function in a
55common metatable. LL and OS functions are likely to be C or Lua
56functions. Careful testing should be done with LuaJIT FFI, sandboxing,
57and performance testing.</p>
58
59<p>The Lua source is compiled by the Lua compiler.</p>
60
61<p>LuaJIT is used as the Lua compiler, library, and runtime.</p>
62
63<p>Luaproc is used to start up operating system threads and hand Lua states
64between them. Luaproc messaging is also being used, but might need to
65change to edje messaging. Note - luaproc has been extensively rewritten
66for this project, mostly converting it to use EFL. That rewrite
67substantially shrunk the source code. Then it was all rewritten again
68to use EFL threads, and cooperative multitasking.</p>
69
70<p>THIS IS WHERE WE ARE RIGHT NOW.</p>
71
72<p>Should implement embedded Lua somehow. Probably the best thing to do is
73to have comments like -</p>
74
75<p>//Lua: local t = {1, 3, 42, x='something', 'something else}</p>
76/*Lua: print(t.x) */</p>
77
78<p>The LSL parser picks these up and stores them in the AST as Lua
79snippets, then the compiler output functions just inserts them in the
80Lua code it is generating. Obviously these Lua snippets can access the
81rest of the generated Lua code. They should also be able to access
82skang and thus do proper GUI stuff on viewers that support skang.</p>
83
84<p>Nails will be used to pump commands in and out of the LuaSL system.
85Incoming commands invoke LSL events via the LuaSL state metatable. LL
86and OS functions that impact the world will be converted to nails
87commands sent to the command pump.</p>
88
89<p>Initially, since this is the first thing being written, a nails command
90pump client needs to be installed into OpenSim's C# stuff. Though it
91might be possible to talk directly to ROBUST instead. Think I'll try
92the ROBUST route, see how far I can get. That's the general principle
93applying in all of this - try to avoid C# and see how for we can get.
94lol</p>
95
96<p>On the other hand, might be better to leverage the existing C#
97implementations of LSL functions, just to get things up and running
98quickly. To that end, a protocol involving exchanging snippets of Lua
99over a network socket has been developed, and the next step is to write
100the C# side. sigh</p>
101
102<p>A watchdog thread should be used to make sure no LuaSL script spends
103forever processing any event.</p>
104
105<p>Some form of serialization will need to be created for saving script
106state during shutdowns, passing script state to other threads /
107processes / computers. Apparently Lua is good at this.</p>
108
109<p>There will have to be a MySQL (and maybe SQLite) client in the system,
110so we can talk directly to the local sim database. Esskyuehl may be
111suitable, though it's still in the prototype stage.</p>
112
113<p>Email, HTTP, and XML-RPC might need to be dealt with by us. A ROBUST
114client will be needed to. Azy might be suitable, but it's also in
115prototype.</p>
116
117<p>An object is a file system directory, full of LSL scripts as text files,
118notecards as text files, animations as BVH (or later BVJ) files, etc.
119There will be some sort of metadata in place. This could be created by
120our own OpenSim compatible cache module.</p>
121
122
123<p>Test harness.</p>
124-------------</p>
125
126<p>I'll build a test harness. It will be based on EFL Edje Lua, with
127buttons for triggering LSL events, SL style dialogs, and other goodies.</p>
128
129<p>The initial goal will be to run standard MLP scripts. They have minimal
130interface to the world, and exercise quite a bit of the rest of LSL.
131They are also quite common, and sometimes responsible for a lot of the
132script running load.</p>
133
134<p>Later I should add stock standard OpenCollar scripts from SL. They are
135a bitch to get working under OpenSim, so would be good compatability
136tests.</p>
137
138<p>Various eina logging domains might be used to handle whisper, say, shout,
139etc.</p>
140
141<p>Performance testing will have to be done on 5000 scripts, to see how
142that compares against XEngine.</p>
143
144<p>The test harness became the love world server.</p>
145
146
147<p>TODO</p>
148<p>----</p>
149
150<p>Useful for limiting the amount of time scripts use -
151<p>https://groups.google.com/forum/#!topic/lua-alchemy-dev/3bDPk2aQ8FE</p>
152<p>http://stackoverflow.com/questions/862256/how-can-i-end-a-lua-thread-cleanly</p>
153
154
155
39<p>&nbsp;</p> 156<p>&nbsp;</p>
40<h1> onefangs implementation ideas </h1> 157<h1> onefangs implementation ideas </h1>
41<p>I'm gonna write an LSL script engine in Lua and C. At least initially, I'll pretend I can use SledjHamr instead of OpenSim, and see how far I get. The source is at <a href="https://github.com/onefang/SledjHamr">https://github.com/onefang/SledjHamr</a> on the experimental branch.</p> 158<p>I'm gonna write an LSL script engine in Lua and C. At least initially, I'll pretend I can use SledjHamr instead of OpenSim, and see how far I get. The source is at <a href="https://github.com/onefang/SledjHamr">https://github.com/onefang/SledjHamr</a> on the experimental branch.</p>
42<p>&nbsp;</p> 159<p>&nbsp;</p>
43<h2> You’re in a maze of twisty little quirks, all different. </h2> 160<h2> You're in a maze of twisty little quirks, all different. </h2>
44<p>LSL is known for being more quirks than features. Some of the quirks are just limitations that we can get rid of. Some we will have to replicate just to be compatible. OpenSim adds it's own quirks on top of those, but one of the points of doing this is to avoid that particular set of quirks. I'll create two variations, using the first line comment hack OpenSim invented to choose between them. The default is to use the quirky one, where an effort is made to replicate the full quirkiness of LSL. The other choice has no quirks at all, and even lets Lua features be mixed in. This Lua flavoured LSL will be the first one to work on, as it will be a lot easier.</p> 161<p>LSL is known for being more quirks than features. Some of the quirks are just limitations that we can get rid of. Some we will have to replicate just to be compatible. OpenSim adds it's own quirks on top of those, but one of the points of doing this is to avoid that particular set of quirks. I'll create two variations, using the first line comment hack OpenSim invented to choose between them. The default is to use the quirky one, where an effort is made to replicate the full quirkiness of LSL. The other choice has no quirks at all, and even lets Lua features be mixed in. This Lua flavoured LSL will be the first one to work on, as it will be a lot easier.</p>
45<p>&nbsp;</p> 162<p>&nbsp;</p>
46<h2> Making Lua look like LSL </h2> 163<h2> Making Lua look like LSL </h2>
diff --git a/docs/Nails.html b/docs/Nails.html
index 2885faf..1f99f4d 100644
--- a/docs/Nails.html
+++ b/docs/Nails.html
@@ -2510,6 +2510,10 @@
2510</tr> 2510</tr>
2511</tbody> 2511</tbody>
2512</table> 2512</table>
2513<p>Not sure where else to put this, but nails I think is the bit that drives the network traffic the most -</p>
2514<a href="http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/">low-latency-requires-smart-queuing-traditional-aqm-is-not-enough</a>
2515<p>Another article that deals with network issues in a 3D networked game -</p>
2516<a href="http://www.gamasutra.com/view/feature/131781/the_internet_sucks_or_what_i_.php?print=1">the_internet_sucks_or_what_i_</a>
2513<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> 2517<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>
2514</body> 2518</body>
2515</html> 2519</html>
diff --git a/docs/SledjHamr/README.LuaSL b/docs/SledjHamr/README.LuaSL
deleted file mode 100644
index 7556bf7..0000000
--- a/docs/SledjHamr/README.LuaSL
+++ /dev/null
@@ -1,121 +0,0 @@
1Refer to - LuaSL_New_scripting_engine.html
2
3LuaSL is a Lua based LSL scripting engine that will aim for LSL
4compatibility first, then adding Lua extensions. It aims to replace the
5woeful XEngine from OpenSim, and at a later stage, be the basis for a
6client side scripting engine.
7
8To compile this, you will need Enlightenment Foundation Libraries (EFL)
9installed in either /opt/e17 or /usr. These are typical places it get's
10installed in. You will also need flex. The rest of the dependencies
11are in the ../libraries directory.
12
13
14Design.
15-------
16
17The basic design will be made up as I go along, but so far I have this -
18
19A parser parses an LSL script, validating it and reporting errors.
20
21A translator takes the result of the parse, and converts it into Lua
22source. Each LSL script becomes a Lua state. LSL states are handled as
23Lua tables, with each LSL state function being a table function in a
24common metatable. LL and OS functions are likely to be C or Lua
25functions. Careful testing should be done with LuaJIT FFI, sandboxing,
26and performance testing.
27
28The Lua source is compiled by the Lua compiler.
29
30LuaJIT is used as the Lua compiler, library, and runtime.
31
32Luaproc is used to start up operating system threads and hand Lua states
33between them. Luaproc messaging is also being used, but might need to
34change to edje messaging. Note - luaproc has been extensively rewritten
35for this project, mostly converting it to use EFL. That rewrite
36substantially shrunk the source code. Then it was all rewritten again
37to use EFL threads, and cooperative multitasking.
38
39THIS IS WHERE WE ARE RIGHT NOW.
40
41Should implement embedded Lua somehow. Probably the best thing to do is
42to have comments like -
43
44//Lua: local t = {1, 3, 42, x='something', 'something else}
45/*Lua: print(t.x) */
46
47The LSL parser picks these up and stores them in the AST as Lua
48snippets, then the compiler output functions just inserts them in the
49Lua code it is generating. Obviously these Lua snippets can access the
50rest of the generated Lua code. They should also be able to access
51skang and thus do proper GUI stuff on viewers that support skang.
52
53Nails will be used to pump commands in and out of the LuaSL system.
54Incoming commands invoke LSL events via the LuaSL state metatable. LL
55and OS functions that impact the world will be converted to nails
56commands sent to the command pump.
57
58Initially, since this is the first thing being written, a nails command
59pump client needs to be installed into OpenSim's C# stuff. Though it
60might be possible to talk directly to ROBUST instead. Think I'll try
61the ROBUST route, see how far I can get. That's the general principle
62applying in all of this - try to avoid C# and see how for we can get.
63lol
64
65On the other hand, might be better to leverage the existing C#
66implementations of LSL functions, just to get things up and running
67quickly. To that end, a protocol involving exchanging snippets of Lua
68over a network socket has been developed, and the next step is to write
69the C# side. sigh
70
71A watchdog thread should be used to make sure no LuaSL script spends
72forever processing any event.
73
74Some form of serialization will need to be created for saving script
75state during shutdowns, passing script state to other threads /
76processes / computers. Apparently Lua is good at this.
77
78There will have to be a MySQL (and maybe SQLite) client in the system,
79so we can talk directly to the local sim database. Esskyuehl may be
80suitable, though it's still in the prototype stage.
81
82Email, HTTP, and XML-RPC might need to be dealt with by us. A ROBUST
83client will be needed to. Azy might be suitable, but it's also in
84prototype.
85
86An object is a file system directory, full of LSL scripts as text files,
87notecards as text files, animations as BVH (or later BVJ) files, etc.
88There will be some sort of metadata in place. This could be created by
89our own OpenSim compatible cache module.
90
91
92Test harness.
93-------------
94
95I'll build a test harness. It will be based on EFL Edje Lua, with
96buttons for triggering LSL events, SL style dialogs, and other goodies.
97
98The initial goal will be to run standard MLP scripts. They have minimal
99interface to the world, and exercise quite a bit of the rest of LSL.
100They are also quite common, and sometimes responsible for a lot of the
101script running load.
102
103Later I should add stock standard OpenCollar scripts from SL. They are
104a bitch to get working under OpenSim, so would be good compatability
105tests.
106
107Various eina logging domains might be used to handle whisper, say, shout,
108etc.
109
110Performance testing will have to be done on 5000 scripts, to see how
111that compares against XEngine.
112
113The test harness became the love world server.
114
115
116TODO
117----
118
119Useful for limiting the amount of time scripts use -
120https://groups.google.com/forum/#!topic/lua-alchemy-dev/3bDPk2aQ8FE
121http://stackoverflow.com/questions/862256/how-can-i-end-a-lua-thread-cleanly
diff --git a/docs/SledjHamr/README.nails b/docs/SledjHamr/README.nails
deleted file mode 100644
index 7512944..0000000
--- a/docs/SledjHamr/README.nails
+++ /dev/null
@@ -1,14 +0,0 @@
1Refer to - Nails.html
2
3Nails bangs it all together, mostly via the command pump.
4
5
6Not sure where else to put this, but nails I think is the bit that
7drives the network traffic the most -
8
9http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/
10
11
12Another article that deals with network issues in a 3D networked game -
13
14http://www.gamasutra.com/view/feature/131781/the_internet_sucks_or_what_i_.php?print=1
diff --git a/docs/index.html b/docs/index.html
index f4f90ac..83827b5 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -15,40 +15,37 @@ Welcome to the home of SledjHamr!
15<li><a href="SledjHamr.html">SledjHamr</a> Tearing down the garden walls.</li> 15<li><a href="SledjHamr.html">SledjHamr</a> Tearing down the garden walls.</li>
16<li>Server side -</li> 16<li>Server side -</li>
17<ul> 17<ul>
18<li><a href="SledjHamr/privacy.txt">privacy</a> We take privacy seriously.</li> 18<li>We take <a href="SledjHamr/privacy.txt">privacy</a> seriously.</li>
19<li><a href="SledjHamr/portals.txt">portals</a> Killer feature!</li> 19<li><a href="SledjHamr/portals.txt">portals</a> Killer feature!</li>
20<li><a href="OMG-WTF-BBQ.html">OMG WTF BBQ</a> A means of making UUIDs location-agnostic. This is where we deal with systems to keep track of where in the web assets are, and to cache them.</li> 20<li><a href="OMG-WTF-BBQ.html">OMG WTF BBQ</a> A means of making UUIDs location-agnostic. This is where we deal with systems to keep track of where in the web assets are, and to cache them.</li>
21<li><a href="SledjHamr/no_accounts.txt">no accounts</a> We don need no stinkin' accounts.</li> 21<li><a href="SledjHamr/no_accounts.txt">no accounts</a> We don need no stinkin' accounts.</li>
22<li><a href="NGIW.html">NGIW</a> REST is probably good to apply to the web server part. Alice wants JSON to, but see nails.</li> 22<li><a href="NGIW.html">NGIW</a> REST is probably good to apply to the web server part. Alice wants JSON to, but see nails.</li>
23<ul><li><a href="NGIW.Commands.html">NGIW.Commands</a> In the NGIW/REST world, how do I touch an object, or send it some other kind of message?</li></ul> 23<ul><li><a href="NGIW.Commands.html">NGIW.Commands</a> In the NGIW/REST world, how do I touch an object, or send it some other kind of message?</li></ul>
24<li><a href="SledjHamr/The_Naminator.txt">The Naminator</a> The Naminator eliminates human readable names, to make way for computer names from SkyNet. Or something.</li> 24<li><a href="SledjHamr/The_Naminator.txt">The Naminator</a> eliminates human readable names, to make way for computer names from SkyNet. Or something.</li>
25<li><a href="SledjHamr/README.LuaSL">LuaSL</a> LuaSL a new scripting engine.</li> 25<li><a href="LuaSL-New-scripting-engine.html">LuaSL</a> a new scripting engine, with extra speeeeeed!</li>
26<ul> 26<ul>
27<li><a href="LuaSL-New-scripting-engine.html">LuaSL, a new scripting engine</a> Speeeeeed!</li>
28<li><a href="LSL-functions-implemented.html">LSL functions implemented</a></li> 27<li><a href="LSL-functions-implemented.html">LSL functions implemented</a></li>
29</ul> 28</ul>
30<li><a href="SledjHamr/README.Lspace">Lspace</a> Sim contents server.</li> 29<li><a href="SledjHamr/README.Lspace">Lspace</a> Sim contents server.</li>
31<li><a href="SledjHamr/love.txt">love</a> Love makes the world go around.</li> 30<li><a href="SledjHamr/love.txt">love</a> makes the world go around.</li>
32<li> HamrSpace inventory server, a pocket universe where cartoon characters keep their giant hammers.</li> 31<li>HamrSpace inventory server, a pocket universe where cartoon characters keep their giant hammers.</li>
33<li><a href="Grid-data-flow.html">Grid data flow</a> Documenting the flow of data through an OpenSim system, so we can replace it.</li> 32<li>Documenting the <a href="Grid-data-flow.html">flow of data</a> through an OpenSim system, so we can replace it.</li>
34</ul> 33</ul>
35<li><a href="Nails.html">Nails</a> How to put it all together.</li> 34<li><a href="Nails.html">Nails</a> bangs it all together, mostly via the command pump.</li>
36<li><a href="SledjHamr/README.nails">nails</a> Nails bangs it all together.</li>
37<li><a href="ClientHamr/README.mumble">mumble</a> Voice integration.</li> 35<li><a href="ClientHamr/README.mumble">mumble</a> Voice integration.</li>
38<li><a href="SledjHamr/README.libraries">libraries</a> The various libraries used.</li> 36<li>The various <a href="SledjHamr/README.libraries">libraries</a> used.</li>
39<li><a href="Croquet-integration.html">Croquet integration</a> Just an idea, but we should support other virtual world tech if we can.</li> 37<li><a href="Croquet-integration.html">Croquet integration</a> Just an idea, but we should support other virtual world tech if we can.</li>
40<li><a href="ClientHamr.html">ClientHamr</a> How to rip code out of the client and make it better.</li> 38<li><a href="ClientHamr.html">ClientHamr</a> How to rip code out of the client and make it better.</li>
41<ul> 39<ul>
42<li><a href="ClientHamr/README.woMan">woMan</a> Virtual world account and viewer manager.</li> 40<li><a href="ClientHamr/README.woMan">woMan</a> Virtual world account and viewer manager.</li>
43<li><a href="ClientHamr/WebBrowsers.txt">web browsers</a> How to deal with sucky web browsers.</li> 41<li>How to deal with sucky <a href="ClientHamr/WebBrowsers.txt">web browsers</a>.</li>
44<li><a href="ClientHamr/TellinBone.txt">TellinBone</a> A virtual Android "phone".</li> 42<li><a href="ClientHamr/TellinBone.txt">TellinBone</a> A virtual Android "phone".</li>
45<li><a href="ClientHamr/ScriptEditor.txt">script editor</a> Blue sky editor idea, will the stars align?</li> 43<li>Blue sky <a href="ClientHamr/ScriptEditor.txt">script editor</a> idea, will the stars align?</li>
46<li><a href="ClientHamr/README.purkle">purkle</a> Jabber / XMPP integration.</li> 44<li><a href="ClientHamr/README.purkle">purkle</a> Jabber / XMPP integration.</li>
47<li><a href="InworldAnimationEditor.html">InworldAnimationEditor</a> I dream of mixing qavimator into the client.</li> 45<li><a href="InworldAnimationEditor.html">InworldAnimationEditor</a> I dream of mixing qavimator into the client.</li>
48<li><a href="ClientHamr/README.GuiLua">GuiLua</a> Skang for SledjHamr.</li> 46<li><a href="ClientHamr/README.GuiLua">GuiLua</a> Skang for SledjHamr.</li>
49<li><a href="ClientHamr/README.extantz">extantz</a> The viewer.</li> 47<li><a href="ClientHamr/README.extantz">extantz</a> The viewer.</li>
50<li><a href="ClientHamr/README.BVJ">BVJ</a> Animations.</li> 48<li><a href="BVJ.html">BVJ</a> New and improved animations, with extra attachment points included.</li>
51<ul><li><a href="BVJ.html">BVJ</a> New and improved animations, with extra attachment points included.</li></ul>
52<li><a href="BlackListAssetServersTracker.html">BlackListAssetServersTracker</a> Might be cool if you could accept/reject asset servers. For copyright control or to avoid seeing yucky stuff.</li> 49<li><a href="BlackListAssetServersTracker.html">BlackListAssetServersTracker</a> Might be cool if you could accept/reject asset servers. For copyright control or to avoid seeing yucky stuff.</li>
53<li><a href="ClientHamr/README.bGod">bGod</a> Admin / manager tools.</li> 50<li><a href="ClientHamr/README.bGod">bGod</a> Admin / manager tools.</li>
54</ul> 51</ul>