Improving Instructions

Information About Open Source Uru & CyanWorlds.com Engine
User avatar
JWPlatt
Member
Posts: 1137
Joined: Sun Dec 07, 2008 7:32 pm
Location: Everywhere, all at once

Re: Improving Instructions

Post by JWPlatt »

That all sounds good.

We have discussed something like weekly sessions in MOULa to just talk with people about whatever they wanted to talk about or provide Q&A just like you're suggesting. So yeah, great idea. We just don't have the time to do it all. You seem to. ;) Let's arrange something in a little bit, probably for the OpenUru.org hood on MOULa.

If you haven't planned to attend and speak at the AGM tomorrow (Saturday), you should, to announce your shard and take Q&A.
Perfect speed is being there.
User avatar
Lyrositor
Member
Posts: 156
Joined: Sun Feb 05, 2012 10:58 pm
Contact:

Re: Improving Instructions

Post by Lyrositor »

JWPlatt wrote:If you haven't planned to attend and speak at the AGM tomorrow (Saturday), you should, to announce your shard and take Q&A.
Alas, it's a few hours too late for me. :( I won't be available after 10:00 KI time, I think (if my KI conversions). I'll be reading the chatlogs, though, and I'll try to hang around a few hours earlier, just in case anybody comes.

Also, these are my holidays. Afterwards, I'll probably be a lot less available, so I'm cramming as much effort as possible into the next few days.
Lyrositor
Explorer #16601888
To D'ni, or not to D'ni. There is no question.
Image
User avatar
Lyrositor
Member
Posts: 156
Joined: Sun Feb 05, 2012 10:58 pm
Contact:

Re: Improving Instructions

Post by Lyrositor »

I managed to attend a good part of it after all.
Anyway, here's version 1.0 of my MOSS FAQ. I've also included a few things which pertain more to running a shard than running MOSS, but they seemed to go together so well that I included them anyway, to be removed or changed at will.

Wiki code:
Spoiler
Should you have any questions concerning [[MOSS]], don't feel alone! Others have struggled where you have struggled. Here are the most frequently asked questions about MOSS and deploying a Shard running it.

== General ==

General questions about MOSS and related subjects.

=== What is MOSS? ===

''Full details can be found on [[MOSS|MOSS' article]].''

To summarize, MOSS is an open-source Uru server created by a'moaca' and cjkelly1 through reverse-engineering of Cyan's server's inner workings by the analysis of network packets sent by the client (no disassembly was used). A '''server''' interfaces with a '''client''' to deliver data, files, and so on. When combined with a physical server (a computer), a software server becomes a machine on the Internet capable of remotely serving up a website, a repository of files or a game, to name a few uses. In this case, when MOSS is combined with a computer, it produces a "Shard", to which the [[CyanWorlds.com Engine|CWE client]] can connect. If you wish to operate a Shard, you will have to set up a server and distribute a client that explorers can use to connect to it.

=== A server? Does that mean Cyan has finally open-sourced their server code? ===

Unfortunately, no. Cyan is apparently nowhere near a release of their code. In its stead, MOSS fills the role of a server replacement for running Uru Shards. It is a full-featured server, capable of doing practically everything Cyan's server can, so until the latter is released, all your Uru needs should be filled by MOSS, barring [[http://wiki.openuru.org/index.php?title ... karounds|a few minor bugs]], not all necessarily MOSS' fault.

=== UNIX? *nix? ===

Most people today are familiar with at least two operating systems (the software that powers your computer): Windows and Mac. However, there are a variety of other OSes out there, including all the UNIX-based operating systems (also called *nix OSes). To run MOSS, you need to install a *nix OS on your server. Instructions for installation depend upon which specific system you choose; if you aren't familiar with these operating systems, you might be better off by choosing one tailored for less advanced users, such as [http://www.ubuntu.com/business/server/overview Ubuntu Server].

However, please note that for installation, a minimum of technical knowledge is required to execute instructions and input commands; it is recommended you become familiar with your server's operating system before proceeding with the setup of MOSS.

== Installation ==

Setup-related questions. For the main installation instructions, read [[MOSS/Setup]].

=== Where is MOSS installed? ===

The exact location where MOSS is installed by default will probably depend upon your operating system of choice (see above). For example, in the case of GNU/Linux, it will probably be installed under <code>/usr/local</code>, meaning you will have to start MOSS from that directory. However, if you prefer installing MOSS in a specific location, the '''--prefix''' configuration option is the answer to your problem. You might choose, for example, to install it in your home directory (<code>~/moss</code>, for instance), allowing the user which will run MOSS to have complete control over all the files involved.

=== Why would I want to "enable-fast-download"? ===

To fix a bug known as the "zero seconds remaining" bug, Cyan placed a type of cap on the amount of data sent over the Internet. MOSS doesn't have this bug, though, so you are free to remove this cap, therefore allowing your client to benefit from enhanced download speeds, theoretically (although actual performance will still most likely depend not on your client's download speed, but on the upload speed of your server).

=== Why are there three servers? I thought MOSS was already a server! ===

Since Cyan's client needs to communicate with four different subsystems to connect to the server, MOSS has to provide four processes which will handle all the appropriate communications; since they in turn serve specific parts of data, they are called servers too. Each has a different role:
* '''Auth Server''': this server handles the authentication of users, checking them against the PostgreSQL database to make sure they have entered a correct combination of username and password. It also handles which SDL and Python files will be provided to the client, depending on their "class" ("default" for most cases).
* '''File Server''': the file server keeps a list of all the files the client needs to download, with various manifests files (see below) which list them. It contains one sub-directory called <code>Client</code>, in turn containing <code>External</code>, in which all the files which the client will have to download must be provided. '''WARNING:''' you are currently NOT allowed to add Cyan content to this folder due to licensing restrictions; clients must already have downloaded the appropriate files from the official Cyan servers.
* '''Game Server''': the game server handles every operation directly pertaining to the game, including the current state of instances and the files associated with each Age.
* '''Gatekeeper Server''': lastly, the gatekeeper server tells the client where to find other servers.
There is a fifth, optional server called the '''Status Server''', which will handle the display of an HTTP status message that the client will fetch and display. It is optional since you can do the same thing with any regular web page on an HTTP server.

=== What the heck is a "manifest", and why should I care? ===

A manifest is a special binary file which provides the server with a list of all the files it currently has. There are two types of manifests: authentication manifests (with the <code>.mbam</code> file extension), telling the auth server what files it has to offer the client, and file manifests (with the <code>.mbm</code> file extension), telling the file server what files it must distribute to the client and where they are located.

You'd better care about all these <code>.mbam</code> and <code>.mbm</code> files, because if you don't have manifests, your client won't know what do since the server will be scrambling around frantically, literally mumbling to itself about non-existent manifests while trying to find all the files the client is requesting to work.

You create manifests either using <code>support/make-mbam.pl</code> (only for auth manifests) or <code>support/ManifestCreator.exe</code> (the latter requires an up-to-date client installation and Windows to operate).

=== What do I do with all these keys? ===

Open locks of course! What else?

There are two types of keys:
* '''Private keys:''' these keys should be protected in such a fashion that no outside entity can read them; it's recommended to <code>chmod 400</code> them to the user which will run MOSS. These need to be in the ''auth dir''.
* '''Public keys:''' unlike private keys, there is no risk of compromising your server (at least, no elevated risk) by distributing your public keys; your client actually needs them to access your server! These can be anywhere on your server, since MOSS doesn't look at them. I recommend putting them in one directory together for convenience.
Depending on your client's implementation of keys, you will have to follow different instructions when distributing your clients to allow them to connect to your server (see below).

=== What's all this about global_sdl_manager? ===

''The following section needs confirmation by someone with technical knowledge on the subject.''

So you've created your database. That's fine. But wouldn't you like to configure a few things? global_sdl_manager allows you to configure all the various SDL files on your server by adding a few parameters to your database. The default settings are those of MO:ULa, without the sparklies enabled (see below).

=== What needs to be "secured"? ===

All the files in the Python and SDL folders in your ''auth dir'' need to be secured for the external clients. To accomplish this task, use the <code>plPythonPack.exe</code> executable in your client build to pack all the appropriate Python files into one <code>python.pak</code> file to be placed under <code>''auth dir''/Python</code>, then run <code>plFileSecure.exe</code> on all the files in <code>''auth dir''/SDL</code> and on <code>''auth dir''/Python/python.pak</code>.

== Running ==

"The ending has not yet been written." You still have to start up your server. What follows are answers to questions that might arise while running MOSS.

=== Why no sparklies? ===

''I haven't tested the following technique yet, but it seems logical to me.''

This is because of the default configuration imposed by global_sdl_manager. To change this, create a file, copy the <code>support/set_to_moul.txt</code> file contents and uncomment (remove the <code>#</code> in front of the line) all lines similar to <code>m ercaCalendarSpark07 1</code>.

== Clients ==

For the most part, MOSS doesn't care which client is connecting to it. However, they do differ in the way they must connect to your Shard and the scripts they must use.

=== Using: OpenUru.org CWE client ===

This client, maintained by the OpenUru.org team and built using Visual Studio 2003 (a costly product), requires being built along with your keys; in this case, you'll have to copy the three <code>.cpp</code> files you obtained when creating your server's keys over into your client's sources under <code>CWE/MOULOpenSourceClientPlugin/Plasma20/Sources/Plasma/NucleusLib/pnNetBase</code>.

Scripts distributed with the Internal client or served for the External client must be acquired here: [https://foundry.openuru.org/hg/MOULSCRIPT-ou/ OpenUru.org Foundry - MOULSCRIPT-ou]

=== Using: H'uru CWE client ===

The H'uru team has gone another way, instead making use of a <code>server.ini</code> file in your client's root directory that is read not at compile-time but during run-time. Therefore you should use the [viewtopic.php?f=94&t=578#p4467 CreateINI] tool by MercAngel to convert your <code>.cpp</code> files to an appropriately formatted and unencrypted <code>server.ini</code>. Then just drop this file into your client's root directory.

Another difference (as described below under Troubleshooting) is the mechanism for requesting manifests.

Scripts distributed with the Internal client or served for the External client must be acquired here: [https://github.com/H-uru/moul-scripts GitHub - H'uru/moul-scripts]

'''Notice:''' if distributing an External client, you need to encrypt your server.ini file using <code>plFileEncrypt.exe</code>.

=== What's the difference with the Internal clients? ===

Whereas an External client should be the one distributed to users on your server, an Internal client's purpose is to allow for debugging of problems in your Shard or in your client. It gives access to a few special features, including a fly-mode and a Python console for on-the-fly modification of the world around you and the state of age files. Unlike and External client, they are capable of working solely with local data, thus allowing you to make sure your Shard works by testing only a part of the server at a time (since it doesn't interface with the file server, for example). In addition to the dat and sfx folders, they should be provided with a copy of your moul-scripts as used on your server (when running in LocalData mode).

=== What do I put in <code>''file dir''/Client/External</code>? ===

Every file that goes in this directory will be downloaded by your client when it connects to your Shard and detects out-of-date files. This includes <code>UruLauncher.exe</code> and <code>UruExplorer.exe</code>. The exact set of files will depend on the fork of the CWE client you are using. For reference, take a look at the files used by the Gehn Shard (H'uru CWE client) and by the Minkata Shard (OpenUru.org CWE client).

The files in this directory all need to be gzipped. When you use ManifestCreator to create your file manifests, so long as you point it to a working external client installation instead of the regular Uru Live folder, it automatically gzips all the client files in your installation directory (excluding game data).

== Licensing ==

Remember that you're using open-source software; as such, proper credits must be given where due. Details are available on [[MOSS/Setup#Before You Open Your Server|MOSS/Setup]]

=== How should I distribute the license for my client? ===

The best way to be sure your clients always have your license available is to include it under your <code>''install dir''/Client/External</code> as a gzipped filed to be automatically downloaded when a client connects to your Shard.

=== What needs to made available publicly? ===

Aside from the license distributed to your clients, you need to provide a link (on your Shard's website for example) to the source you used both for your client and for your scripts. If you are using unmodified sources, you need to link to the exact revision you cloned for your client.

== Troubleshooting ==

If you encounter any problems while running MOSS, this section will address some of the most frequent issues.

=== "Server tried to mumble to itself about SecurePreloader.mbm, but no one is listening." ===

This warning from MOSS means that someone is using the H'uru CWE client to connect to your server. It's safe to ignore it. It simply means that the H'uru team has implemented an alternate mechanism for requesting the manifests and that MOSS doesn't understand it, and tells so. The client doesn't mind, and then falls back on the default method of relying on the auth manifests, as described above.

[[Category:MOSS]]
Preview (BBCode):

Should you have any questions concerning MOSS, don't feel alone! Others have struggled where you have struggled. Here are the most frequently asked questions about MOSS and deploying a Shard running it.

General
General questions about MOSS and related subjects.

What is MOSS?
Full details can be found on MOSS' article.

To summarize, MOSS is an open-source Uru server created by a'moaca' and cjkelly1 through reverse-engineering of Cyan's server's inner workings by the analysis of network packets sent by the client (no disassembly was used). A server interfaces with a client to deliver data, files, and so on. When combined with a physical server (a computer), a software server becomes a machine on the Internet capable of remotely serving up a website, a repository of files or a game, to name a few uses. In this case, when MOSS is combined with a computer, it produces a "Shard", to which the CWE client can connect. If you wish to operate a Shard, you will have to set up a server and distribute a client that explorers can use to connect to it.

A server? Does that mean Cyan has finally open-sourced their server code?
Unfortunately, no. Cyan is apparently nowhere near a release of their code. In its stead, MOSS fills the role of a server replacement for running Uru Shards. It is a full-featured server, capable of doing practically everything Cyan's server can, so until the latter is released, all your Uru needs should be filled by MOSS, barring a few minor bugs, not all necessarily MOSS' fault.

UNIX? *nix?
Most people today are familiar with at least two operating systems (the software that powers your computer): Windows and Mac. However, there are a variety of other OSes out there, including all the UNIX-based operating systems (also called *nix OSes). To run MOSS, you need to install a *nix OS on your server. Instructions for installation depend upon which specific system you choose; if you aren't familiar with these operating systems, you might be better off by choosing one tailored for less advanced users, such as Ubuntu Server.

However, please note that for installation, a minimum of technical knowledge is required to execute instructions and input commands; it is recommended you become familiar with your server's operating system before proceeding with the setup of MOSS.

Installation
Setup-related questions. For the main installation instructions, read MOSS/Setup.

Where is MOSS installed?
The exact location where MOSS is installed by default will probably depend upon your operating system of choice (see above). For example, in the case of GNU/Linux, it will probably be installed under /usr/local, meaning you will have to start MOSS from that directory. However, if you prefer installing MOSS in a specific location, the --prefix configuration option is the answer to your problem. You might choose, for example, to install it in your home directory (~/moss, for instance), allowing the user which will run MOSS to have complete control over all the files involved.

Why would I want to "enable-fast-download"?
To fix a bug known as the "zero seconds remaining" bug, Cyan placed a type of cap on the amount of data sent over the Internet. MOSS doesn't have this bug, though, so you are free to remove this cap, therefore allowing your client to benefit from enhanced download speeds, theoretically (although actual performance will still most likely depend not on your client's download speed, but on the upload speed of your server).

Why are there three servers? I thought MOSS was already a server!
Since Cyan's client needs to communicate with four different subsystems to connect to the server, MOSS has to provide four processes which will handle all the appropriate communications; since they in turn serve specific parts of data, they are called servers too. Each has a different role:
  • Auth Server: this server handles the authentication of users, checking them against the PostgreSQL database to make sure they have entered a correct combination of username and password. It also handles which SDL and Python files will be provided to the client, depending on their "class" ("default" for most cases).
  • File Server: the file server keeps a list of all the files the client needs to download, with various manifests files (see below) which list them. It contains one sub-directory called Client, in turn containing External, in which all the files which the client will have to download must be provided. WARNING: you are currently NOT allowed to add Cyan content to this folder due to licensing restrictions; clients must already have downloaded the appropriate files from the official Cyan servers.
  • Game Server: the game server handles every operation directly pertaining to the game, including the current state of instances and the files associated with each Age.
  • Gatekeeper Server: lastly, the gatekeeper server tells the client where to find other servers.
There is a fifth, optional server called the Status Server, which will handle the display of an HTTP status message that the client will fetch and display. It is optional since you can do the same thing with any regular web page on an HTTP server.

What the heck is a "manifest", and why should I care?
A manifest is a special binary file which provides the server with a list of all the files it currently has. There are two types of manifests: authentication manifests (with the .mbam file extension), telling the auth server what files it has to offer the client, and file manifests (with the .mbm file extension), telling the file server what files it must distribute to the client and where they are located.

You'd better care about all these .mbam and .mbm files, because if you don't have manifests, your client won't know what do since the server will be scrambling around frantically, literally mumbling to itself about non-existent manifests while trying to find all the files the client is requesting to work.

You create manifests either using support/make-mbam.pl (only for auth manifests) or support/ManifestCreator.exe (the latter requires an up-to-date client installation and Windows to operate).

What do I do with all these keys?
Open locks of course! What else?

There are two types of keys:
  • Private keys: these keys should be protected in such a fashion that no outside entity can read them; it's recommended to chmod 400 them to the user which will run MOSS. These need to be in the ''auth dir''.
  • Public keys: unlike private keys, there is no risk of compromising your server (at least, no elevated risk) by distributing your public keys; your client actually needs them to access your server! These can be anywhere on your server, since MOSS doesn't look at them. I recommend putting them in one directory together for convenience.
Depending on your client's implementation of keys, you will have to follow different instructions when distributing your clients to allow them to connect to your server (see below).

What's all this about global_sdl_manager?
The following section needs confirmation by someone with technical knowledge on the subject.

So you've created your database. That's fine. But wouldn't you like to configure a few things? global_sdl_manager allows you to configure all the various SDL files on your server by adding a few parameters to your database. The default settings are those of MO:ULa, without the sparklies enabled (see below).

What needs to be "secured"?
All the files in the Python and SDL folders in your ''auth dir'' need to be secured for the external clients. To accomplish this task, use the plPythonPack.exe executable in your client build to pack all the appropriate Python files into one python.pak file to be placed under auth dir/Python, then run plFileSecure.exe on all the files in auth dir/SDL and on auth dir/Python/python.pak.

Running
"The ending has not yet been written." You still have to start up your server. What follows are answers to questions that might arise while running MOSS.

Why no sparklies?
I haven't tested the following technique yet, but it seems logical to me.

This is because of the default configuration imposed by global_sdl_manager. To change this, create a file, copy the support/set_to_moul.txt file contents and uncomment (remove the # in front of the line) all lines similar to m ercaCalendarSpark07 1.

Clients
For the most part, MOSS doesn't care which client is connecting to it. However, they do differ in the way they must connect to your Shard and the scripts they must use.

Using: OpenUru.org CWE client
This client, maintained by the OpenUru.org team and built using Visual Studio 2003 (a costly product), requires being built along with your keys; in this case, you'll have to copy the three .cpp files you obtained when creating your server's keys over into your client's sources under CWE/MOULOpenSourceClientPlugin/Plasma20/Sources/Plasma/NucleusLib/pnNetBase.

Scripts distributed with the Internal client or served for the External client must be acquired here: OpenUru.org Foundry - MOULSCRIPT-ou

Using: H'uru CWE client
The H'uru team has gone another way, instead making use of a server.ini file in your client's root directory that is read not at compile-time but during run-time. Therefore you should use the CreateINI tool by MercAngel to convert your .cpp files to an appropriately formatted and unencrypted server.ini. Then just drop this file into your client's root directory.

Another difference (as described below under Troubleshooting) is the mechanism for requesting manifests.

Scripts distributed with the Internal client or served for the External client must be acquired here: GitHub - H'uru/moul-scripts

Notice: if distributing an External client, you need to encrypt your server.ini file using plFileEncrypt.exe.

What's the difference with the Internal clients?
Whereas an External client should be the one distributed to users on your server, an Internal client's purpose is to allow for debugging of problems in your Shard or in your client. It gives access to a few special features, including a fly-mode and a Python console for on-the-fly modification of the world around you and the state of age files. Unlike and External client, they are capable of working solely with local data, thus allowing you to make sure your Shard works by testing only a part of the server at a time (since it doesn't interface with the file server, for example). In addition to the dat and sfx folders, they should be provided with a copy of your moul-scripts as used on your server (when running in LocalData mode).

What do I put in file dir/Client/External?
Every file that goes in this directory will be downloaded by your client when it connects to your Shard and detects out-of-date files. This includes UruLauncher.exe and UruExplorer.exe. The exact set of files will depend on the fork of the CWE client you are using. For reference, take a look at the files used by the Gehn Shard (H'uru CWE client) and by the Minkata Shard (OpenUru.org CWE client).

The files in this directory all need to be gzipped. When you use ManifestCreator to create your file manifests, so long as you point it to a working external client installation instead of the regular Uru Live folder, it automatically gzips all the client files in your installation directory (excluding game data).

Licensing
Remember that you're using open-source software; as such, proper credits must be given where due. Details are available on MOSS/Setup

How should I distribute the license for my client?
The best way to be sure your clients always have your license available is to include it under your install dir/Client/External as a gzipped filed to be automatically downloaded when a client connects to your Shard.

What needs to made available publicly?
Aside from the license distributed to your clients, you need to provide a link (on your Shard's website for example) to the source you used both for your client and for your scripts. If you are using unmodified sources, you need to link to the exact revision you cloned for your client.

Troubleshooting
If you encounter any problems while running MOSS, this section will address some of the most frequent issues.

"Server tried to mumble to itself about SecurePreloader.mbm, but no one is listening."
This warning from MOSS means that someone is using the H'uru CWE client to connect to your server. It's safe to ignore it. It simply means that the H'uru team has implemented an alternate mechanism for requesting the manifests and that MOSS doesn't understand it, and tells so. The client doesn't mind, and then falls back on the default method of relying on the auth manifests, as described above.
Last edited by Lyrositor on Mon Mar 05, 2012 12:45 pm, edited 2 times in total.
Lyrositor
Explorer #16601888
To D'ni, or not to D'ni. There is no question.
Image
cjkelly1
Member
Posts: 67
Joined: Mon Dec 29, 2008 6:08 am

Re: Improving Instructions

Post by cjkelly1 »

Lyrositor wrote: To summarize, MOSS is an open-source Uru server created by a'moaca' and cjkelly1 through reverse-engineering.
May want to clarify the "reverse-engineering" part, because it is important, in my opinion. MOSS was created by observing the network traffic between the client and Cyan's servers. We did not disassemble and reverse-engineer the client to create MOSS. The only items we obtained from the client were the message codes and typecodes (which were in plain-text in the executable) and the encryption. I believe DirtSand was written by disassembling the client itself and working from that (anyone on the DirtSand team reading this - please clarify if this is not the case. I do not want to be making inaccurate statements).

I believe the distinction is important, because it explains why the same things are named differently between MOSS and DirtSand, and why the names in MOSS (and also in the Wireshark plugin) do not necessarily match the Cyan/DirtSand names. It also explains why the same things are done in different ways in each server.

I wish to note that there are many roads to take to a working MOULa compatible server, and I am not wanting to nor intending to imply that one method is better than the other. Just that they are different and produce different (successful) results.
Last edited by cjkelly1 on Sun Mar 04, 2012 11:58 pm, edited 2 times in total.
Reason: used "decompile" instead of the correct term, which is "disassemble".
User avatar
Lyrositor
Member
Posts: 156
Joined: Sun Feb 05, 2012 10:58 pm
Contact:

Re: Improving Instructions

Post by Lyrositor »

Thanks for the correction! I've updated my post to reflect your answer. Do tell me if there's anything else that's incorrect or needs fixing.
P.S. : I tried re-using global_sdl_manager, but I don't understand how to enter the interactive mode which allows you (from what I understand of the source code) to modify the SDL nodes (I want to enable sparklies).
Lyrositor
Explorer #16601888
To D'ni, or not to D'ni. There is no question.
Image
User avatar
rarified
Member
Posts: 1061
Joined: Tue Dec 16, 2008 10:48 pm
Location: Colorado, US

Re: Improving Instructions

Post by rarified »

Interactive mode is simply global_sdl_manager reading from standard input (your controlling terminal window). There is no prompting for a command, it just waits for you to type something, and parses it as a command. So choose what you type carefully!

_R
One of the OpenUru toolsmiths... a bookbinder.
User avatar
Lyrositor
Member
Posts: 156
Joined: Sun Feb 05, 2012 10:58 pm
Contact:

Re: Improving Instructions

Post by Lyrositor »

Ah... I got it, thanks.
Lyrositor
Explorer #16601888
To D'ni, or not to D'ni. There is no question.
Image
User avatar
Lyrositor
Member
Posts: 156
Joined: Sun Feb 05, 2012 10:58 pm
Contact:

Re: Improving Instructions

Post by Lyrositor »

Anymore corrections or rectifications? Should I publish it to the wiki now with the name "MOSS/FAQ"?
Lyrositor
Explorer #16601888
To D'ni, or not to D'ni. There is no question.
Image
User avatar
rarified
Member
Posts: 1061
Joined: Tue Dec 16, 2008 10:48 pm
Location: Colorado, US

Re: Improving Instructions

Post by rarified »

Havn't had time to review, maybe tonight.
One of the OpenUru toolsmiths... a bookbinder.
User avatar
Lyrositor
Member
Posts: 156
Joined: Sun Feb 05, 2012 10:58 pm
Contact:

Re: Improving Instructions

Post by Lyrositor »

I've posted here about a Q&A: http://mystonline.com/forums/viewtopic.php?p=383292
Seems a few people are interested. I'd like to be able to post my MOSS/FAQ on the wiki so that people could have a reference. Are there any objections to my posting of it in the following days?
Lyrositor
Explorer #16601888
To D'ni, or not to D'ni. There is no question.
Image
Post Reply

Return to “Information”