OpenUru - User contributions [en]

MOSS

2018-03-05T13:05:02Z

Christian Walther: /* How to Get It */ Add snapshot location on Bitbucket.

'''MOSS''' is a UNIX-based server for the Myst Online: Uru Live client. Development began after the announcement of the shutdown of MOUL. It is complete enough to play the entire game, supports multiplayer use, is licensed under GPLv3, and is not ported to Windows.

<div style="float: right; padding: 10px;">http://assets.openuru.org/logos/gpl/gplv3-127x51.png</div>
MOSS was developed by a'moaca' and cjkelly1. a'moaca' wrote all the C/C++ code, and cjkelly1 wrote most of the SQL code, including doing research to determine how to set up the vault. cjkelly1 wrote a tool to create the manifest files required by the server, and also made the invaluable contribution of a lot of testing over the years. Weldergeek helped with some of the multiplayer testing, especially Heek. a'moaca' sincerely hopes there will be more contributors now that MOSS is released.

== Why Use MOSS? ==
If you just want to host a private shard, MOSS should serve your purposes. [[MOSS/Setup#Before You Open Your Server | "Before You Open Your Server"]] has some information on what you need to do should you decide to host an Uru shard.

The server definitely works with the [[CyanWorlds.com_Engine | CWE client]]! If you are thinking of doing client development you will probably find a server that is not MOULagain to test with quite valuable. (MOSS was also tested with PlasmaClient, but it does not fully work for PlasmaClient because it does some things that a'moaca' argues are bugs from the system perspective. Development on PlasmaClient is currently suspended<ref>[http://www.nastyprisms.com/temp/cache/plasmaclient.info/ PlasmaClient archived home page]</ref>, but let's fix it if development resumes.)

The server has some features meant to help make it a little easier to test ages you are creating. The SDL files for an age are loaded each time the age is started up so you can change them without restarting MOSS. There is full support for multiple .pak files. So, run your own server, test at your own pace. Test in the CWE client and not the <abbr title="The Path of the Shell">PotS</abbr> one.

== How to Get It ==
The source code is hosted in a Mercurial repository here at OpenUru.org. You can clone (download) a copy of the repository using Mercurial, or you can use a snapshot. If you are considering making changes to the code, you will probably prefer using the version control. If you just want to compile and run a server, a snapshot should do. In addition, a compiled version is available for the ''TBD'' platform.

If you are new to Mercurial, you may want to check the [http://mercurial.selenic.com/wiki/QuickStart QuickStart guide]. There are links to more complete documentation at the bottom. The Foundry is secured via SSL throughout the site. A browser security certificate is needed. Instructions are available on the [[Foundry_Certificate_Installation | certificate installation
page]].

'''Repository address:''' https://foundry.openuru.org/hg/MOSS, https://bitbucket.org/OpenUru_org/moss

'''Snapshot location:''' https://bitbucket.org/OpenUru_org/moss/downloads/

'''Binary package:''' ''TBD''
{{tba}}

== How to Set Up a Server ==
The [http://foundry.openuru.org/fisheye/browse/MOSS/doc/setup setup] file contains a complete set of installation instructions. They do assume you are conversant with setting up software and basic management of a database. For additional setup instructions, see [[MOSS/Setup]]. Feel free to add any hints specific to your distribution [[MOSS/Distribution_Specific_Instructions | here]].

Cyan has provided a copy of the files needed for a server hosting MOUL content. The .sdl, .age, and Python source are all available at [http://assets.openuru.org/cyan/Scripts.zip http://assets.openuru.org/cyan/Scripts.zip]. If you are not interested in compiling your own Python from this source, you can also get a copy of the compiled Python from [http://assets.openuru.org/cyan/AuthFiles.zip http://assets.openuru.org/cyan/AuthFiles.zip].

There is some Q&A and other notes of possible interest to someone running a server at [[MOSS/Notes]].

== How to Contribute ==
Contributing to the wiki pages is welcome. Adding extra setup instructions, or adding documentation about how MOSS works, are two good examples. It's a wiki, please contribute anything you think others might want to read.

Almost any code contribution is welcome. What is unwelcome?
* Protocol/behavior changes without corresponding client support (obviously).
* Changes that remove security without the option of keeping it.
* Changes that introduce security holes, either in the server itself or the vault.
* Changes that break big-endian support (call it a pet peeve if you like, it's still unwelcome).
* Changes that break the build (accidents do happen, but don't break it on purpose).
Hopefully it is not difficult to see why these things are unwelcome.

If you find a bug, please report it. However, please, please, please search first to see if it has already been reported. The bug tracker is available [https://foundry.openuru.org/jira/browse/MOSS here].

If you find a bug and fix it, include the patch with the bug report! This increases the chances of it getting fixed rather a lot.

Bug fixes are very valuable. [https://foundry.openuru.org/jira/browse/MOSS Grab a bug] and fix it! Check out [[MOSS/Project_Ideas]] for more ideas.

If you want to add a feature or change something, you can file a feature request or task bug to get your change considered for the
[https://foundry.openuru.org/hg/MOSS central repository].

If you want write access to the central repository, contribute. The best choice for MOSS will probably be to use similar standards for determining who is given write access as CWE. At this time that's undecided, so the plan for MOSS is equally undecided. However, MOSS's original author is more involved than CWE's so if only a couple people show up to help then it's pretty clear a couple
people will get write access soon enough!

Code reviewers might be needed. If you are willing to be a reviewer, say so! It is a very valuable contribution.

== See Also ==
{{:MOSS/See Also}}
* [[CyanWorlds.com Engine]]
* [[Building the plPythonPack and plFileSecure projects]]

== References ==
<references />

[[Category:MOSS]]

Minkata Shard: Contributions under Test

2017-03-31T20:55:18Z

Christian Walther: /* Bump a public neighborhood to top of list when someone links to it */ works now

This is a list of changes currently accumulating on the Minkata shard for later pick-up into MOULa by Cyan, and how to test them.

== Update 2017-03-25 – Minkata.100 ==

=== Make all account types use the same password hash ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-requests/40/make-all-account-types-use-the-same CWE PR #40] by Mac_Fife

Precursor to restoring account creation. Remove conditional on email domain for password hashing. This is only a client modification needed to interface to new code being worked on to reenable Account Creation on MOULa. Verify that you can still log in.

=== Don’t crash the launcher when getting the server status message fails ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-requests/38/dont-crash-the-launcher-when-the-http CWE PR #38] by CWalther

This fixes a crash of the launcher after it has already successfully started the game. Verify that you are not getting any “UruLauncher has stopped working” messages before or after logging in.

=== Repair Descent Age ===

[http://forums.openuru.org/viewtopic.php?p=8380#p8380 Minkata bug reports] by rarified

Fixed the database corruption preventing an Avatar from successfully linking into Descent, particularly affected new Avatars. Verify that linking to Descent from Relto or Ae'gura works without getting stuck on a black screen.

== Update 2015-12-14 – Minkata.82 … Update 2015-12-19 – Minkata.88 ==

=== Fix KI chat scrolling issues ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-requests/26/add-functions-to-fix-ki-chat-scrolling CWE PR #26], [https://bitbucket.org/OpenUru_org/moulscript-ou/pull-requests/19/fix-ki-chat-scrolling-issue-when-scrolled MOULSCRIPT PR #19] ([https://github.com/H-uru/moul-scripts/pull/40 H-uru PR #40]) by Lyrositor

This fixes a common gripe with KI chat, which has a tendency to scroll down when someone else sends a chat message, even if you have scrolled up. Verify that it now scrolls down only when you are already looking at the bottom, and when scrolled up, flashes the scroll-down arrow instead.

=== Fix stuck-in-intro-cave bug ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-requests/37/fix-stuck-in-intro-cave-bug CWE PR #37] by CWalther

Verify that a new avatar is no longer stuck in the intro cave with the rotating wall before arriving on Relto. Instead the cave should just briefly fade in and out.

=== Don't crash when the HTTP request for getting the server status message fails ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-requests/31/dont-crash-when-the-http-request-for CWE PR #31] by CWalther

This fixes the crash that keeps Windows 7 (or later) users out of MOULa when support.cyanworlds.com is down.

=== Fix for forgotten logins when removable media attached ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-requests/33/fix-for-forgotten-logins-when-removable CWE PR #33] by Mac_Fife

Verify that your saved login/password no longer disappears when you have USB drives or CDs/DVDs inserted.

=== Shadowed Chat and Player List Text ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-requests/36/shadowed-chat-and-player-list-text CWE PR #36], [https://bitbucket.org/OpenUru_org/moulscript-ou/pull-requests/23/remove-unneeded-kfontshadowed-flags-in-the MOULSCRIPT PR #23] ([https://github.com/H-uru/Plasma/pull/392 H-uru PR #392]) by CWalther, Hoikas, and Luna

Verify that the text of the player list and chat has a shadow that makes it better readable on light and patterned backgrounds, but the text inside the big KI does not.

=== Bump a public neighborhood to top of list when someone links to it ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-requests/35/let-ptvaultsetagepublic-accept CWE PR #35], [https://bitbucket.org/OpenUru_org/moulscript-ou/pull-requests/22/bump-a-public-neighborhood-to-the-top-of MOULSCRIPT PR #22] ([https://github.com/H-uru/moul-scripts/pull/90 H-uru PR #90]) by CWalther

Verify that after linking to a public neighborhood, it appears at the top of the “Public Links” list in the Nexus. This ensures that public neighborhoods that are in active use stay (near the top) on the list in the Nexus, even after their owners disappear (as is the case for the numerous dedicated Delin & Tsogal hoods that have been made over time), with no manual toggling needed, and no need for pinned hoods.

''(<s>As of 2017-03-25, this is known not to work on Minkata and is being investigated.</s> As of 2017-03-31, the problem has been fixed and this feature is ready for testing.)''

=== Second confirmation dialog to make accidental avatar deletion less easy ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-requests/20/second-confirmation-dialog-to-make MOULSCRIPT PR #20] by D'Lanor

This makes it harder to lose an avatar by mistakenly hitting the “delete” button instead of the ”quit” button. [http://mystonline.com/forums/viewtopic.php?t=26127 See this discussion on the MOULa forums.]

How to test: 1. Create a test avatar. 2. Log out. 3. Select the test avatar and hit delete. 4. In the first confirmation dialog press "Yes". 5. In the second confirmation dialog press "Cancel". Your test avatar should still be there. 6. Repeat steps 3 and 4. 7. In the second confirmation dialog press "Yes". Your test avatar should be gone.

=== KI command for deleting age journal folders ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-requests/21/ki-command-for-deleting-age-journal MOULSCRIPT PR #21] by D'Lanor

The ''/deletefolder'' command allows you to delete redundant age journal folders (those holding KI notes, images and marker games) from your KI. It does not touch any other type of KI folder, nor does it remove the Incoming folder, which would be bad(tm). The command is case sensitive. Only empty folders will be deleted. To restore a folder, link to the corresponding age. Note: If you try to delete the folder of the age you are in, the KI immediately restores it.

How to test: To delete a folder named Bevin for example type <code>/deletefolder Bevin</code>

[[Category:Minkata Shard]]

Minkata Shard: Contributions under Test

2017-03-25T21:58:30Z

Christian Walther: Updated to current Minkata state. All the old content was obsolete and has alredy been moved to Minkata_Shard:_Contributions_Uplifted_by_Cyan_Worlds. Sorry Mac for stomping on your work but I started first and spent hours on getting it right, I'm not goin

This is a list of changes currently accumulating on the Minkata shard for later pick-up into MOULa by Cyan, and how to test them.

== Update 2017-03-25 – Minkata.100 ==

=== Make all account types use the same password hash ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-requests/40/make-all-account-types-use-the-same CWE PR #40] by Mac_Fife

Precursor to restoring account creation. Remove conditional on email domain for password hashing. This is only a client modification needed to interface to new code being worked on to reenable Account Creation on MOULa. Verify that you can still log in.

=== Don’t crash the launcher when getting the server status message fails ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-requests/38/dont-crash-the-launcher-when-the-http CWE PR #38] by CWalther

This fixes a crash of the launcher after it has already successfully started the game. Verify that you are not getting any “UruLauncher has stopped working” messages before or after logging in.

=== Repair Descent Age ===

[http://forums.openuru.org/viewtopic.php?p=8380#p8380 Minkata bug reports] by rarified

Fixed the database corruption preventing an Avatar from successfully linking into Descent, particularly affected new Avatars. Verify that linking to Descent from Relto or Ae'gura works without getting stuck on a black screen.

== Update 2015-12-14 – Minkata.82 … Update 2015-12-19 – Minkata.88 ==

=== Fix KI chat scrolling issues ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-requests/26/add-functions-to-fix-ki-chat-scrolling CWE PR #26], [https://bitbucket.org/OpenUru_org/moulscript-ou/pull-requests/19/fix-ki-chat-scrolling-issue-when-scrolled MOULSCRIPT PR #19] ([https://github.com/H-uru/moul-scripts/pull/40 H-uru PR #40]) by Lyrositor

This fixes a common gripe with KI chat, which has a tendency to scroll down when someone else sends a chat message, even if you have scrolled up. Verify that it now scrolls down only when you are already looking at the bottom, and when scrolled up, flashes the scroll-down arrow instead.

=== Fix stuck-in-intro-cave bug ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-requests/37/fix-stuck-in-intro-cave-bug CWE PR #37] by CWalther

Verify that a new avatar is no longer stuck in the intro cave with the rotating wall before arriving on Relto. Instead the cave should just briefly fade in and out.

=== Don't crash when the HTTP request for getting the server status message fails ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-requests/31/dont-crash-when-the-http-request-for CWE PR #31] by CWalther

This fixes the crash that keeps Windows 7 (or later) users out of MOULa when support.cyanworlds.com is down.

=== Fix for forgotten logins when removable media attached ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-requests/33/fix-for-forgotten-logins-when-removable CWE PR #33] by Mac_Fife

Verify that your saved login/password no longer disappears when you have USB drives or CDs/DVDs inserted.

=== Shadowed Chat and Player List Text ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-requests/36/shadowed-chat-and-player-list-text CWE PR #36], [https://bitbucket.org/OpenUru_org/moulscript-ou/pull-requests/23/remove-unneeded-kfontshadowed-flags-in-the MOULSCRIPT PR #23] ([https://github.com/H-uru/Plasma/pull/392 H-uru PR #392]) by CWalther, Hoikas, and Luna

Verify that the text of the player list and chat has a shadow that makes it better readable on light and patterned backgrounds, but the text inside the big KI does not.

=== Bump a public neighborhood to top of list when someone links to it ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-requests/35/let-ptvaultsetagepublic-accept CWE PR #35], [https://bitbucket.org/OpenUru_org/moulscript-ou/pull-requests/22/bump-a-public-neighborhood-to-the-top-of MOULSCRIPT PR #22] ([https://github.com/H-uru/moul-scripts/pull/90 H-uru PR #90]) by CWalther

Verify that after linking to a public neighborhood, it appears at the top of the “Public Links” list in the Nexus. This ensures that public neighborhoods that are in active use stay (near the top) on the list in the Nexus, even after their owners disappear (as is the case for the numerous dedicated Delin & Tsogal hoods that have been made over time), with no manual toggling needed, and no need for pinned hoods.

''(As of 2017-03-25, this is known not to work on Minkata and is being investigated.)''

=== Second confirmation dialog to make accidental avatar deletion less easy ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-requests/20/second-confirmation-dialog-to-make MOULSCRIPT PR #20] by D'Lanor

This makes it harder to lose an avatar by mistakenly hitting the “delete” button instead of the ”quit” button. [http://mystonline.com/forums/viewtopic.php?t=26127 See this discussion on the MOULa forums.]

How to test: 1. Create a test avatar. 2. Log out. 3. Select the test avatar and hit delete. 4. In the first confirmation dialog press "Yes". 5. In the second confirmation dialog press "Cancel". Your test avatar should still be there. 6. Repeat steps 3 and 4. 7. In the second confirmation dialog press "Yes". Your test avatar should be gone.

=== KI command for deleting age journal folders ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-requests/21/ki-command-for-deleting-age-journal MOULSCRIPT PR #21] by D'Lanor

The ''/deletefolder'' command allows you to delete redundant age journal folders (those holding KI notes, images and marker games) from your KI. It does not touch any other type of KI folder, nor does it remove the Incoming folder, which would be bad(tm). The command is case sensitive. Only empty folders will be deleted. To restore a folder, link to the corresponding age. Note: If you try to delete the folder of the age you are in, the KI immediately restores it.

How to test: To delete a folder named Bevin for example type <code>/deletefolder Bevin</code>

[[Category:Minkata Shard]]

User talk:Mac Fife

2015-10-20T21:22:44Z

Christian Walther: more suggestions

== List in Code ==
For the convenience of shard operators, below is the names list as of 17 Oct 2015
Richard "ShadowCats" Bader\nJeannie "jmb30321" Barcus\nJanet "Pehpsi" Burress\nCAGrayWolf\nJames "Aquila" Carpenter\n
Virginia "Terra" Cinova\nWillow "Wheely" Engberg\nCindy Farrar\nGandhar\nRon Hayter\nJahuti\nMaureen "Mo\'zie" Jannot\n
JDrake\nDeirdre Karris\nKatzi\nWilliam "oldmanjob" Maier\nLen "Flyboy" Mumbower\nMyst\'Aken\nPerlenstern\n
Mark "Zardoz" Plummer\nRamsine\nJim "Dust\'ei" Rhodes\nJosef Riedl\nSil-Oh-Wet\nRosette Taylor\n
Generally, when copying the above, you will need to remove any line breaks to create a string on a single line.

'''SQL code for MOSS servers'''<ref>Coding provided by Christian Walther.</ref>

A sample SQL statement to update the directly in the database is given below where <code>string_of_names</code> should be replaced by the string given above. The example is for MOSS and PostgeSQL but the syntax for other servers and databases will be similar.
<syntaxhighlight lang="sql">UPDATE textnote SET value = E'string_of_names' WHERE title = 'MemorialImager';</syntaxhighlight>

== List in Code, CW’s version ==
'''SQL code for MOSS servers'''<ref>Coding provided by Christian Walther.</ref>

A sample SQL statement to update the directly in the database is given below. The example is for MOSS and PostgreSQL but the syntax for other servers and databases will be similar.
<pre style="white-space: pre-wrap;">UPDATE textnote SET value = E'Richard "ShadowCats" Bader\nJeannie "jmb30321" Barcus\nJanet "Pehpsi" Burress\nCAGrayWolf\nJames "Aquila" Carpenter\nVirginia "Terra" Cinova\nWillow "Wheely" Engberg\nCindy Farrar\nGandhar\nRon Hayter\nJahuti\nMaureen "Mo\'zie" Jannot\nJDrake\nDeirdre Karris\nKatzi\nWilliam "oldmanjob" Maier\nLen "Flyboy" Mumbower\nMyst\'Aken\nPerlenstern\nMark "Zardoz" Plummer\nRamsine\nJim "Dust\'ei" Rhodes\nJosef Riedl\nSil-Oh-Wet\nRosette Taylor\n' WHERE title = 'MemorialImager';</pre>
<syntaxhighlight lang="sql" style="overflow: auto;">UPDATE textnote SET value = E'Richard "ShadowCats" Bader\nJeannie "jmb30321" Barcus\nJanet "Pehpsi" Burress\nCAGrayWolf\nJames "Aquila" Carpenter\nVirginia "Terra" Cinova\nWillow "Wheely" Engberg\nCindy Farrar\nGandhar\nRon Hayter\nJahuti\nMaureen "Mo\'zie" Jannot\nJDrake\nDeirdre Karris\nKatzi\nWilliam "oldmanjob" Maier\nLen "Flyboy" Mumbower\nMyst\'Aken\nPerlenstern\nMark "Zardoz" Plummer\nRamsine\nJim "Dust\'ei" Rhodes\nJosef Riedl\nSil-Oh-Wet\nRosette Taylor\n' WHERE title = 'MemorialImager';</syntaxhighlight>

Minkata Shard: Contributions Uplifted by Cyan Worlds

2013-06-05T20:54:41Z

Christian Walther: /* Correct an invalid GZGlass state */ Updated to current knowledge

This is a list of changes that have completed testing on the Minkata shard and have been uplifted by Cyan for use on <abbr title="Myst Online: Uru Live again">MOULa</abbr>.

These are expected to appear the client update scheduled for '''June 4 to 5, 2013''' (TBC).
{{draft}}

=== Fixed console documentation ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/12/fixed-console-documentation CWE PR #12] by Lyrositor, [https://github.com/H-uru/Plasma/issues/170 H-uru issue 170]

No user-visible change on external clients. On internal clients, verify that the ''Console.CreateBriefDocumentation'' command outputs correct group names (not keeping the name of the previous group) and better HTML.

=== Update for Visual Studio 2010 ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/11/update-for-visual-studio-2010 CWE PR #11] by Skoader

No user-visible change.

=== Allow clickables to function while sitting or AFK ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/14/allow-clickables-to-function-while-sitting CWE PR #14] by Hoikas, ported by Lyrositor, see also [https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/13/allow-clickables-to-function-while-sitting PR #13], [https://github.com/H-uru/Plasma/pull/176 H-uru PR 176]

Verify that clickable things can be used while sitting or AFK, verify that using them will either leave you sitting or make you stand up as appropriate, and not leave you in some inconsistent intermediate state.

Standing up to perform another avatar animation (e.g. pulling a lever) will not use the normal stand-up animation, but just warp you into the standing state, this is expected.

=== Fix various JPEG issues ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/15/fix-various-jpeg-issues CWE PR #15] by Deledrius, ported by Lyrositor

Verify that new KI pictures saved in the ''Documents/Uru Live/KIimages'' folder as well as new avatar portraits saved in the ''Documents/Uru Live/Avatars'' folder are now proper JPEG files that can be opened in any graphics program.

Existing avatar portraits will disappear from the avatar selection screen by this change, run your favorite [http://en.mystlore.com/wiki/Myst_Online:_Uru_Live_KI_image_bug#Repair KI picture fixer] on them to get them back.

=== Free the cursor ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/21/free-the-cursor CWE PR #21]by Deledrius (ported by Lyrositor) and Skoader; [https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/25/free-the-cursor-update CWE PR #25] (part of [https://github.com/H-uru/Plasma/pull/221 H-uru PR 221]) by Hoikas, ported by CWalther

Verify that when running in window mode, the mouse can be moved outside of the Uru window, transitions between inside and outside work as expected, and changing to and from other programs by mouse or keyboard works as expected. Try both launching in windowed mode and switching to windowed mode after launching in fullscreen mode. Verify that while having the left mouse button down to walk by mouse, having the right mouse button down to look around by mouse, or both, in any order, the cursor will never go outside of the window and break the continuous turning, even with very quick mouse movements.

=== Fix improperly calculated window size in initial Windowed mode ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/18/fix-improperly-calculated-window-size-in CWE PR #18] by Deledrius (ported by Lyrositor) and CWalther

Verify that in windowed mode (after launching in windowed mode, after switching from fullscreen (larger or smaller) or from a differently sized window (larger or smaller)), the content size of the window is exactly as many pixels as it should be from the resolution you’ve set. Previously, when launching in windowed mode, the size would be slightly off, which would manifest itself in a periodic grid of seams or blurriness across the window, most noticeable when moving the cursor over them. Reference picture of the seams: [http://uru.zero-factorial.com/images/bugs/resizetiling.png http://uru.zero-factorial.com/images/bugs/resizetiling.png]

=== Improved Cursors ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/10/improved-cursors CWE PR #10] by Deledrius and CWalther

Revel in the glory of good-looking mouse cursors, voice chat indicators, and loading linking book animation.

=== Remove broken share symbol from Sharper's Office linking book ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/13/remove-broken-share-symbol-from-sharpers MOULSCRIPT PR #13] by D'Lanor

Verify that the linking book in the fish tank in Sharper’s office in Teledahn, going to the city office, has no share symbol in the close-up view. (The share symbol was included by mistake, as the city office is a neighborhood-instanced age, which cannot be shared. Previously, attempts to share would not work as expected, sending sharer and sharee to different instances.)

The share symbol is still visible from a distance on the book as it lies in the fish tank, this cannot be fixed until we are allowed to change the content files.

=== Correct an invalid GZGlass state ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/14/correct-an-invalid-gzglass-state MOULSCRIPT PR #14] by Hoikas, ported by Lyrositor

No user-visible effect. The lack of randomization on MOULa was caused by a server-side misconfiguration ([https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/14/correct-an-invalid-gzglass-state#comment-11289 as suspected]) and was fixed on 2013-06-04. Verify that new neighborhoods (DRC or player-created) get a randomly selected one of the three possible Great Zero stained glass designs. Existing neighborhoods that were non-randomly displaying the glass with three orange bars may have had their glass replaced by a random one by the fix of 2013-06-04 as well. Verify that from now on, a neighborhood does not change its glass design anymore when you link to it multiple times.

=== Avatar physics update ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/20/avatar-physics-update CWE PR #20], [https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/22/fix-intermittent-spawn-bug #22], [https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/17/vogondola-changes-for-cwe-avatar-physics MOULSCRIPT PR #17] by Skoader

To test: too many areas potentially affected to list here, see [[PhysX_Update_Testing_(Minkata.71)]]. Easy ways to tell that the update is in effect: • leaves in Kadish are kickable, • avatar does not shake while riding Er'cana harvester.

=== Fix pellet points stealing ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/16/fix-pellet-points-stealing-see-https MOULSCRIPT PR #16] by D'Lanor

- Player A links to hood with empty imagers. - Player B links to same hood and uploads pellet points (right imager). - Name of player B should appear next to new score on imager. (Imager message will still say “From: A”, this is an unrelated and known issue.)

See also [https://foundry.openuru.org/jira/browse/MOULSCRIPT-6 JIRA MOULSCRIPT-6].

=== Bink removal ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/27/stub-out-plclient-bink-support CWE PR #27] by Hoikas and CWalther

Proprietary parts have been removed from the source code. As a result, the Cyan logo and Yeesha intro videos no longer play. This will likely be a temporary condition, the videos may be reintroduced in a later version after the technical work required for that is done. Verify that the Cyan logo (played at launch) and Yeesha intro (played before a new avatar appears on Relto and on request from the wrench dialog) videos behave as if they had zero length, i.e. the Cyan logo is simply skipped, and for the Yeesha intro the room appears briefly and fades out again immediately.

=== Fix remote code execution through Python.Cheat and Python.RunFile ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/24/fix-remote-code-execution-through CWE PR #24] ([https://github.com/H-uru/Plasma/pull/218 H-uru PR 218]) by boq, ported by Lyrositor

No user-visible change. Playing Uru becomes safer, as a security issue is fixed that a malicious player in the same age could exploit to do pretty much anything to your computer.

[[Category:Minkata Shard]]

Minkata Shard: Contributions Uplifted by Cyan Worlds

2013-06-01T21:40:22Z

Christian Walther: /* Bink removal */ Adjusted wording to MOULa situation

This is a list of changes that have completed testing on the Minkata shard and have been uplifted by Cyan for use on <abbr title="Myst Online: Uru Live again">MOULa</abbr>.

These are expected to appear the client update scheduled for '''June 4 to 5, 2013''' (TBC).
{{draft}}

=== Fixed console documentation ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/12/fixed-console-documentation CWE PR #12] by Lyrositor, [https://github.com/H-uru/Plasma/issues/170 H-uru issue 170]

No user-visible change on external clients. On internal clients, verify that the ''Console.CreateBriefDocumentation'' command outputs correct group names (not keeping the name of the previous group) and better HTML.

=== Update for Visual Studio 2010 ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/11/update-for-visual-studio-2010 CWE PR #11] by Skoader

No user-visible change.

=== Allow clickables to function while sitting or AFK ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/14/allow-clickables-to-function-while-sitting CWE PR #14] by Hoikas, ported by Lyrositor, see also [https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/13/allow-clickables-to-function-while-sitting PR #13], [https://github.com/H-uru/Plasma/pull/176 H-uru PR 176]

Verify that clickable things can be used while sitting or AFK, verify that using them will either leave you sitting or make you stand up as appropriate, and not leave you in some inconsistent intermediate state.

Standing up to perform another avatar animation (e.g. pulling a lever) will not use the normal stand-up animation, but just warp you into the standing state, this is expected.

=== Fix various JPEG issues ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/15/fix-various-jpeg-issues CWE PR #15] by Deledrius, ported by Lyrositor

Verify that new KI pictures saved in the ''Documents/Uru Live/KIimages'' folder as well as new avatar portraits saved in the ''Documents/Uru Live/Avatars'' folder are now proper JPEG files that can be opened in any graphics program.

Existing avatar portraits will disappear from the avatar selection screen by this change, run your favorite [http://en.mystlore.com/wiki/Myst_Online:_Uru_Live_KI_image_bug#Repair KI picture fixer] on them to get them back.

=== Free the cursor ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/21/free-the-cursor CWE PR #21]by Deledrius (ported by Lyrositor) and Skoader; [https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/25/free-the-cursor-update CWE PR #25] (part of [https://github.com/H-uru/Plasma/pull/221 H-uru PR 221]) by Hoikas, ported by CWalther

Verify that when running in window mode, the mouse can be moved outside of the Uru window, transitions between inside and outside work as expected, and changing to and from other programs by mouse or keyboard works as expected. Try both launching in windowed mode and switching to windowed mode after launching in fullscreen mode. Verify that while having the left mouse button down to walk by mouse, having the right mouse button down to look around by mouse, or both, in any order, the cursor will never go outside of the window and break the continuous turning, even with very quick mouse movements.

=== Fix improperly calculated window size in initial Windowed mode ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/18/fix-improperly-calculated-window-size-in CWE PR #18] by Deledrius (ported by Lyrositor) and CWalther

Verify that in windowed mode (after launching in windowed mode, after switching from fullscreen (larger or smaller) or from a differently sized window (larger or smaller)), the content size of the window is exactly as many pixels as it should be from the resolution you’ve set. Previously, when launching in windowed mode, the size would be slightly off, which would manifest itself in a periodic grid of seams or blurriness across the window, most noticeable when moving the cursor over them. Reference picture of the seams: [http://uru.zero-factorial.com/images/bugs/resizetiling.png http://uru.zero-factorial.com/images/bugs/resizetiling.png]

=== Improved Cursors ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/10/improved-cursors CWE PR #10] by Deledrius and CWalther

Revel in the glory of good-looking mouse cursors, voice chat indicators, and loading linking book animation.

=== Remove broken share symbol from Sharper's Office linking book ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/13/remove-broken-share-symbol-from-sharpers MOULSCRIPT PR #13] by D'Lanor

Verify that the linking book in the fish tank in Sharper’s office in Teledahn, going to the city office, has no share symbol in the close-up view. (The share symbol was included by mistake, as the city office is a neighborhood-instanced age, which cannot be shared. Previously, attempts to share would not work as expected, sending sharer and sharee to different instances.)

The share symbol is still visible from a distance on the book as it lies in the fish tank, this cannot be fixed until we are allowed to change the content files.

=== Correct an invalid GZGlass state ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/14/correct-an-invalid-gzglass-state MOULSCRIPT PR #14] by Hoikas, ported by Lyrositor

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/14/correct-an-invalid-gzglass-state#comment-11289 Conjecturedly] no user-visible effect on MOULa. On Minkata, new neighborhoods (DRC or player-created) should get a randomly selected one of the three possible Great Zero stained glass designs.

=== Avatar physics update ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/20/avatar-physics-update CWE PR #20], [https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/22/fix-intermittent-spawn-bug #22], [https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/17/vogondola-changes-for-cwe-avatar-physics MOULSCRIPT PR #17] by Skoader

To test: too many areas potentially affected to list here, see [[PhysX_Update_Testing_(Minkata.71)]]. Easy ways to tell that the update is in effect: • leaves in Kadish are kickable, • avatar does not shake while riding Er'cana harvester.

=== Fix pellet points stealing ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/16/fix-pellet-points-stealing-see-https MOULSCRIPT PR #16] by D'Lanor

- Player A links to hood with empty imagers. - Player B links to same hood and uploads pellet points (right imager). - Name of player B should appear next to new score on imager. (Imager message will still say “From: A”, this is an unrelated and known issue.)

See also [https://foundry.openuru.org/jira/browse/MOULSCRIPT-6 JIRA MOULSCRIPT-6].

=== Bink removal ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/27/stub-out-plclient-bink-support CWE PR #27] by Hoikas and CWalther

Proprietary parts have been removed from the source code. As a result, the Cyan logo and Yeesha intro videos no longer play. This will likely be a temporary condition, the videos may be reintroduced in a later version after the technical work required for that is done. Verify that the Cyan logo (played at launch) and Yeesha intro (played before a new avatar appears on Relto and on request from the wrench dialog) videos behave as if they had zero length, i.e. the Cyan logo is simply skipped, and for the Yeesha intro the room appears briefly and fades out again immediately.

=== Fix remote code execution through Python.Cheat and Python.RunFile ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/24/fix-remote-code-execution-through CWE PR #24] ([https://github.com/H-uru/Plasma/pull/218 H-uru PR 218]) by boq, ported by Lyrositor

No user-visible change. Playing Uru becomes safer, as a security issue is fixed that a malicious player in the same age could exploit to do pretty much anything to your computer.

[[Category:Minkata Shard]]

Minkata Shard: Contributions Uplifted by Cyan Worlds

2013-04-23T18:04:23Z

Christian Walther: Fuse bugfix update into its main section, remove Minkata update headings

This is a list of changes that have completed testing on the Minkata shard and have been uplifted by Cyan for use on <abbr title="Myst Online: Uru Live again">MOULa</abbr>.

These are expected to appear the client update scheduled for '''April 12, 2013''' (TBC).
{{draft}}

=== Fixed console documentation ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/12/fixed-console-documentation CWE PR #12] by Lyrositor, [https://github.com/H-uru/Plasma/issues/170 H-uru issue 170]

No user-visible change on external clients. On internal clients, verify that the ''Console.CreateBriefDocumentation'' command outputs correct group names (not keeping the name of the previous group) and better HTML.

=== Update for Visual Studio 2010 ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/11/update-for-visual-studio-2010 CWE PR #11] by Skoader

No user-visible change.

=== Allow clickables to function while sitting or AFK ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/14/allow-clickables-to-function-while-sitting CWE PR #14] by Hoikas, ported by Lyrositor, see also [https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/13/allow-clickables-to-function-while-sitting PR #13], [https://github.com/H-uru/Plasma/pull/176 H-uru PR 176]

Verify that clickable things can be used while sitting or AFK, verify that using them will either leave you sitting or make you stand up as appropriate, and not leave you in some inconsistent intermediate state.

Standing up to perform another avatar animation (e.g. pulling a lever) will not use the normal stand-up animation, but just warp you into the standing state, this is expected.

=== Fix various JPEG issues ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/15/fix-various-jpeg-issues CWE PR #15] by Deledrius, ported by Lyrositor

Verify that new KI pictures saved in the ''Documents/Uru Live/KIimages'' folder as well as new avatar portraits saved in the ''Documents/Uru Live/Avatars'' folder are now proper JPEG files that can be opened in any graphics program.

Existing avatar portraits will disappear from the avatar selection screen by this change, run your favorite [http://en.mystlore.com/wiki/Myst_Online:_Uru_Live_KI_image_bug#Repair KI picture fixer] on them to get them back.

=== Free the cursor ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/21/free-the-cursor CWE PR #21]by Deledrius (ported by Lyrositor) and Skoader; [https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/25/free-the-cursor-update CWE PR #25] (part of [https://github.com/H-uru/Plasma/pull/221 H-uru PR 221]) by Hoikas, ported by CWalther

Verify that when running in window mode, the mouse can be moved outside of the Uru window, transitions between inside and outside work as expected, and changing to and from other programs by mouse or keyboard works as expected. Try both launching in windowed mode and switching to windowed mode after launching in fullscreen mode. Verify that while having the left mouse button down to walk by mouse, having the right mouse button down to look around by mouse, or both, in any order, the cursor will never go outside of the window and break the continuous turning, even with very quick mouse movements.

=== Fix improperly calculated window size in initial Windowed mode ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/18/fix-improperly-calculated-window-size-in CWE PR #18] by Deledrius (ported by Lyrositor) and CWalther

Verify that in windowed mode (after launching in windowed mode, after switching from fullscreen (larger or smaller) or from a differently sized window (larger or smaller)), the content size of the window is exactly as many pixels as it should be from the resolution you’ve set. Previously, when launching in windowed mode, the size would be slightly off, which would manifest itself in a periodic grid of seams or blurriness across the window, most noticeable when moving the cursor over them. Reference picture of the seams: [http://uru.zero-factorial.com/images/bugs/resizetiling.png http://uru.zero-factorial.com/images/bugs/resizetiling.png]

=== Improved Cursors ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/10/improved-cursors CWE PR #10] by Deledrius and CWalther

Revel in the glory of good-looking mouse cursors, voice chat indicators, and loading linking book animation.

=== Remove broken share symbol from Sharper's Office linking book ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/13/remove-broken-share-symbol-from-sharpers MOULSCRIPT PR #13] by D'Lanor

Verify that the linking book in the fish tank in Sharper’s office in Teledahn, going to the city office, has no share symbol in the close-up view. (The share symbol was included by mistake, as the city office is a neighborhood-instanced age, which cannot be shared. Previously, attempts to share would not work as expected, sending sharer and sharee to different instances.)

The share symbol is still visible from a distance on the book as it lies in the fish tank, this cannot be fixed until we are allowed to change the content files.

=== Correct an invalid GZGlass state ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/14/correct-an-invalid-gzglass-state MOULSCRIPT PR #14] by Hoikas, ported by Lyrositor

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/14/correct-an-invalid-gzglass-state#comment-11289 Conjecturedly] no user-visible effect on MOULa. On Minkata, new neighborhoods (DRC or player-created) should get a randomly selected one of the three possible Great Zero stained glass designs.

=== Avatar physics update ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/20/avatar-physics-update CWE PR #20], [https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/22/fix-intermittent-spawn-bug #22], [https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/17/vogondola-changes-for-cwe-avatar-physics MOULSCRIPT PR #17] by Skoader

To test: too many areas potentially affected to list here, see [[PhysX_Update_Testing_(Minkata.71)]]. Easy ways to tell that the update is in effect: • leaves in Kadish are kickable, • avatar does not shake while riding Er'cana harvester.

=== Fix pellet points stealing ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/16/fix-pellet-points-stealing-see-https MOULSCRIPT PR #16] by D'Lanor

- Player A links to hood with empty imagers. - Player B links to same hood and uploads pellet points (right imager). - Name of player B should appear next to new score on imager. (Imager message will still say “From: A”, this is an unrelated and known issue.)

See also [https://foundry.openuru.org/jira/browse/MOULSCRIPT-6 JIRA MOULSCRIPT-6].

=== Bink removal ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/27/stub-out-plclient-bink-support CWE PR #27] by Hoikas and CWalther

Proprietary parts have been removed from the source code. There should be no user-visible change. Verify that the Cyan logo (played at launch) and Yeesha intro (played before a new avatar appears on Relto and on request from the wrench dialog) videos still behave as if they had zero length, i.e. the Cyan logo is simply skipped, and for the Yeesha intro the room appears briefly and fades out again immediately.

=== Fix remote code execution through Python.Cheat and Python.RunFile ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/24/fix-remote-code-execution-through CWE PR #24] ([https://github.com/H-uru/Plasma/pull/218 H-uru PR 218]) by boq, ported by Lyrositor

No user-visible change. Playing Uru becomes safer, as a security issue is fixed that a malicious player in the same age could exploit to do pretty much anything to your computer.

[[Category:Minkata Shard]]

Minkata Shard: Contributions Uplifted by Cyan Worlds

2013-04-23T17:59:15Z

Christian Walther: Update to the current state of Minkata_Shard:_Contributions_under_Test

This is a list of changes that have completed testing on the Minkata shard and have been uplifted by Cyan for use on <abbr title="Myst Online: Uru Live again">MOULa</abbr>.

These are expected to appear the client update scheduled for '''April 12, 2013''' (TBC).
{{draft}}

=== Fixed console documentation ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/12/fixed-console-documentation CWE PR #12] by Lyrositor, [https://github.com/H-uru/Plasma/issues/170 H-uru issue 170]

No user-visible change on external clients. On internal clients, verify that the ''Console.CreateBriefDocumentation'' command outputs correct group names (not keeping the name of the previous group) and better HTML.

=== Update for Visual Studio 2010 ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/11/update-for-visual-studio-2010 CWE PR #11] by Skoader

No user-visible change.

=== Allow clickables to function while sitting or AFK ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/14/allow-clickables-to-function-while-sitting CWE PR #14] by Hoikas, ported by Lyrositor, see also [https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/13/allow-clickables-to-function-while-sitting PR #13], [https://github.com/H-uru/Plasma/pull/176 H-uru PR 176]

Verify that clickable things can be used while sitting or AFK, verify that using them will either leave you sitting or make you stand up as appropriate, and not leave you in some inconsistent intermediate state.

Standing up to perform another avatar animation (e.g. pulling a lever) will not use the normal stand-up animation, but just warp you into the standing state, this is expected.

=== Fix various JPEG issues ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/15/fix-various-jpeg-issues CWE PR #15] by Deledrius, ported by Lyrositor

Verify that new KI pictures saved in the ''Documents/Uru Live/KIimages'' folder as well as new avatar portraits saved in the ''Documents/Uru Live/Avatars'' folder are now proper JPEG files that can be opened in any graphics program.

Existing avatar portraits will disappear from the avatar selection screen by this change, run your favorite [http://en.mystlore.com/wiki/Myst_Online:_Uru_Live_KI_image_bug#Repair KI picture fixer] on them to get them back.

=== Free the cursor ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/21/free-the-cursor CWE PR #21]by Deledrius (ported by Lyrositor) and Skoader

Verify that when running in window mode, the mouse can be moved outside of the Uru window, transitions between inside and outside work as expected, and changing to and from other programs by mouse or keyboard works as expected. Try both launching in windowed mode and switching to windowed mode after launching in fullscreen mode.

Earlier known issues should be fixed in the update of 2012-09-29, please re-test.

=== Fix improperly calculated window size in initial Windowed mode ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/18/fix-improperly-calculated-window-size-in CWE PR #18] by Deledrius (ported by Lyrositor) and CWalther

Verify that in windowed mode (after launching in windowed mode, after switching from fullscreen (larger or smaller) or from a differently sized window (larger or smaller)), the content size of the window is exactly as many pixels as it should be from the resolution you’ve set. Previously, when launching in windowed mode, the size would be slightly off, which would manifest itself in a periodic grid of seams or blurriness across the window, most noticeable when moving the cursor over them. Reference picture of the seams: [http://uru.zero-factorial.com/images/bugs/resizetiling.png http://uru.zero-factorial.com/images/bugs/resizetiling.png]

=== Improved Cursors ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/10/improved-cursors CWE PR #10] by Deledrius and CWalther

Revel in the glory of good-looking mouse cursors, voice chat indicators, and loading linking book animation.

=== Remove broken share symbol from Sharper's Office linking book ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/13/remove-broken-share-symbol-from-sharpers MOULSCRIPT PR #13] by D'Lanor

Verify that the linking book in the fish tank in Sharper’s office in Teledahn, going to the city office, has no share symbol in the close-up view. (The share symbol was included by mistake, as the city office is a neighborhood-instanced age, which cannot be shared. Previously, attempts to share would not work as expected, sending sharer and sharee to different instances.)

The share symbol is still visible from a distance on the book as it lies in the fish tank, this cannot be fixed until we are allowed to change the content files.

=== Correct an invalid GZGlass state ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/14/correct-an-invalid-gzglass-state MOULSCRIPT PR #14] by Hoikas, ported by Lyrositor

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/14/correct-an-invalid-gzglass-state#comment-11289 Conjecturedly] no user-visible effect on MOULa. On Minkata, new neighborhoods (DRC or player-created) should get a randomly selected one of the three possible Great Zero stained glass designs.

=== Avatar physics update ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/20/avatar-physics-update CWE PR #20], [https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/22/fix-intermittent-spawn-bug #22], [https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/17/vogondola-changes-for-cwe-avatar-physics MOULSCRIPT PR #17] by Skoader

To test: too many areas potentially affected to list here, see [[PhysX_Update_Testing_(Minkata.71)]]. Easy ways to tell that the update is in effect: • leaves in Kadish are kickable, • avatar does not shake while riding Er'cana harvester.

=== Fix pellet points stealing ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/16/fix-pellet-points-stealing-see-https MOULSCRIPT PR #16] by D'Lanor

- Player A links to hood with empty imagers. - Player B links to same hood and uploads pellet points (right imager). - Name of player B should appear next to new score on imager. (Imager message will still say “From: A”, this is an unrelated and known issue.)

See also [https://foundry.openuru.org/jira/browse/MOULSCRIPT-6 JIRA MOULSCRIPT-6].

== Update 2013-04-09 – Minkata.74 ==

=== Bink removal ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/27/stub-out-plclient-bink-support CWE PR #27] by Hoikas and CWalther

Proprietary parts have been removed from the source code. There should be no user-visible change. Verify that the Cyan logo (played at launch) and Yeesha intro (played before a new avatar appears on Relto and on request from the wrench dialog) videos still behave as if they had zero length, i.e. the Cyan logo is simply skipped, and for the Yeesha intro the room appears briefly and fades out again immediately.

== Update 2013-04-12 – Minkata.77 ==

=== Fix remote code execution through Python.Cheat and Python.RunFile ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/24/fix-remote-code-execution-through CWE PR #24] ([https://github.com/H-uru/Plasma/pull/218 H-uru PR 218]) by boq, ported by Lyrositor

No user-visible change. Playing Uru becomes safer, as a security issue is fixed that a malicious player in the same age could exploit to do pretty much anything to your computer.

=== Free the cursor, update ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/25/free-the-cursor-update CWE PR #25] (part of [https://github.com/H-uru/Plasma/pull/221 H-uru PR 221]) by Hoikas, ported by CWalther

A bugfix update for ''Free the cursor'' above. Verify that in windowed mode, while having the left mouse button down to walk by mouse, having the right mouse button down to look around by mouse, or both, in any order, the cursor will never go outside of the window and break the continuous turning, even with very quick mouse movements.

[[Category:Minkata Shard]]

Minkata Shard: Contributions under Test

2013-04-12T21:22:51Z

Christian Walther: + Minkata.77 build number

This is a list of changes currently accumulating on the Minkata shard for later pick-up into MOULa by Cyan, and how to test them.

=== Fixed console documentation ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/12/fixed-console-documentation CWE PR #12] by Lyrositor, [https://github.com/H-uru/Plasma/issues/170 H-uru issue 170]

No user-visible change on external clients. On internal clients, verify that the ''Console.CreateBriefDocumentation'' command outputs correct group names (not keeping the name of the previous group) and better HTML.

=== Update for Visual Studio 2010 ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/11/update-for-visual-studio-2010 CWE PR #11] by Skoader

No user-visible change.

=== Allow clickables to function while sitting or AFK ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/14/allow-clickables-to-function-while-sitting CWE PR #14] by Hoikas, ported by Lyrositor, see also [https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/13/allow-clickables-to-function-while-sitting PR #13], [https://github.com/H-uru/Plasma/pull/176 H-uru PR 176]

Verify that clickable things can be used while sitting or AFK, verify that using them will either leave you sitting or make you stand up as appropriate, and not leave you in some inconsistent intermediate state.

Standing up to perform another avatar animation (e.g. pulling a lever) will not use the normal stand-up animation, but just warp you into the standing state, this is expected.

=== Fix various JPEG issues ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/15/fix-various-jpeg-issues CWE PR #15] by Deledrius, ported by Lyrositor

Verify that new KI pictures saved in the ''Documents/Uru Live/KIimages'' folder as well as new avatar portraits saved in the ''Documents/Uru Live/Avatars'' folder are now proper JPEG files that can be opened in any graphics program.

Existing avatar portraits will disappear from the avatar selection screen by this change, run your favorite [http://en.mystlore.com/wiki/Myst_Online:_Uru_Live_KI_image_bug#Repair KI picture fixer] on them to get them back.

=== Free the cursor ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/21/free-the-cursor CWE PR #21]by Deledrius (ported by Lyrositor) and Skoader

Verify that when running in window mode, the mouse can be moved outside of the Uru window, transitions between inside and outside work as expected, and changing to and from other programs by mouse or keyboard works as expected. Try both launching in windowed mode and switching to windowed mode after launching in fullscreen mode.

Earlier known issues should be fixed in the update of 2012-09-29, please re-test.

=== Fix improperly calculated window size in initial Windowed mode ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/18/fix-improperly-calculated-window-size-in CWE PR #18] by Deledrius (ported by Lyrositor) and CWalther

Verify that in windowed mode (after launching in windowed mode, after switching from fullscreen (larger or smaller) or from a differently sized window (larger or smaller)), the content size of the window is exactly as many pixels as it should be from the resolution you’ve set. Previously, when launching in windowed mode, the size would be slightly off, which would manifest itself in a periodic grid of seams or blurriness across the window, most noticeable when moving the cursor over them. Reference picture of the seams: [http://uru.zero-factorial.com/images/bugs/resizetiling.png http://uru.zero-factorial.com/images/bugs/resizetiling.png]

=== Improved Cursors ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/10/improved-cursors CWE PR #10] by Deledrius and CWalther

Revel in the glory of good-looking mouse cursors, voice chat indicators, and loading linking book animation.

=== Remove broken share symbol from Sharper's Office linking book ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/13/remove-broken-share-symbol-from-sharpers MOULSCRIPT PR #13] by D'Lanor

Verify that the linking book in the fish tank in Sharper’s office in Teledahn, going to the city office, has no share symbol in the close-up view. (The share symbol was included by mistake, as the city office is a neighborhood-instanced age, which cannot be shared. Previously, attempts to share would not work as expected, sending sharer and sharee to different instances.)

The share symbol is still visible from a distance on the book as it lies in the fish tank, this cannot be fixed until we are allowed to change the content files.

=== Correct an invalid GZGlass state ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/14/correct-an-invalid-gzglass-state MOULSCRIPT PR #14] by Hoikas, ported by Lyrositor

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/14/correct-an-invalid-gzglass-state#comment-11289 Conjecturedly] no user-visible effect on MOULa. On Minkata, new neighborhoods (DRC or player-created) should get a randomly selected one of the three possible Great Zero stained glass designs.

=== Avatar physics update ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/20/avatar-physics-update CWE PR #20], [https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/22/fix-intermittent-spawn-bug #22], [https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/17/vogondola-changes-for-cwe-avatar-physics MOULSCRIPT PR #17] by Skoader

To test: too many areas potentially affected to list here, see [[PhysX_Update_Testing_(Minkata.71)]]. Easy ways to tell that the update is in effect: • leaves in Kadish are kickable, • avatar does not shake while riding Er'cana harvester.

=== Fix pellet points stealing ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/16/fix-pellet-points-stealing-see-https MOULSCRIPT PR #16] by D'Lanor

- Player A links to hood with empty imagers. - Player B links to same hood and uploads pellet points (right imager). - Name of player B should appear next to new score on imager. (Imager message will still say “From: A”, this is an unrelated and known issue.)

See also [https://foundry.openuru.org/jira/browse/MOULSCRIPT-6 JIRA MOULSCRIPT-6].

== Update 2013-04-09 – Minkata.74 ==

=== Bink removal ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/27/stub-out-plclient-bink-support CWE PR #27] by Hoikas and CWalther

Proprietary parts have been removed from the source code. There should be no user-visible change. Verify that the Cyan logo (played at launch) and Yeesha intro (played before a new avatar appears on Relto and on request from the wrench dialog) videos still behave as if they had zero length, i.e. the Cyan logo is simply skipped, and for the Yeesha intro the room appears briefly and fades out again immediately.

== Update 2013-04-12 – Minkata.77 ==

=== Fix remote code execution through Python.Cheat and Python.RunFile ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/24/fix-remote-code-execution-through CWE PR #24] ([https://github.com/H-uru/Plasma/pull/218 H-uru PR 218]) by boq, ported by Lyrositor

No user-visible change. Playing Uru becomes safer, as a security issue is fixed that a malicious player in the same age could exploit to do pretty much anything to your computer.

=== Free the cursor, update ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/25/free-the-cursor-update CWE PR #25] (part of [https://github.com/H-uru/Plasma/pull/221 H-uru PR 221]) by Hoikas, ported by CWalther

A bugfix update for ''Free the cursor'' above. Verify that in windowed mode, while having the left mouse button down to walk by mouse, having the right mouse button down to look around by mouse, or both, in any order, the cursor will never go outside of the window and break the continuous turning, even with very quick mouse movements.

[[Category:Minkata Shard]]

Minkata Shard: Contributions under Test

2013-04-12T19:38:20Z

Christian Walther: + Update 2013-04-12

This is a list of changes currently accumulating on the Minkata shard for later pick-up into MOULa by Cyan, and how to test them.

=== Fixed console documentation ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/12/fixed-console-documentation CWE PR #12] by Lyrositor, [https://github.com/H-uru/Plasma/issues/170 H-uru issue 170]

No user-visible change on external clients. On internal clients, verify that the ''Console.CreateBriefDocumentation'' command outputs correct group names (not keeping the name of the previous group) and better HTML.

=== Update for Visual Studio 2010 ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/11/update-for-visual-studio-2010 CWE PR #11] by Skoader

No user-visible change.

=== Allow clickables to function while sitting or AFK ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/14/allow-clickables-to-function-while-sitting CWE PR #14] by Hoikas, ported by Lyrositor, see also [https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/13/allow-clickables-to-function-while-sitting PR #13], [https://github.com/H-uru/Plasma/pull/176 H-uru PR 176]

Verify that clickable things can be used while sitting or AFK, verify that using them will either leave you sitting or make you stand up as appropriate, and not leave you in some inconsistent intermediate state.

Standing up to perform another avatar animation (e.g. pulling a lever) will not use the normal stand-up animation, but just warp you into the standing state, this is expected.

=== Fix various JPEG issues ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/15/fix-various-jpeg-issues CWE PR #15] by Deledrius, ported by Lyrositor

Verify that new KI pictures saved in the ''Documents/Uru Live/KIimages'' folder as well as new avatar portraits saved in the ''Documents/Uru Live/Avatars'' folder are now proper JPEG files that can be opened in any graphics program.

Existing avatar portraits will disappear from the avatar selection screen by this change, run your favorite [http://en.mystlore.com/wiki/Myst_Online:_Uru_Live_KI_image_bug#Repair KI picture fixer] on them to get them back.

=== Free the cursor ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/21/free-the-cursor CWE PR #21]by Deledrius (ported by Lyrositor) and Skoader

Verify that when running in window mode, the mouse can be moved outside of the Uru window, transitions between inside and outside work as expected, and changing to and from other programs by mouse or keyboard works as expected. Try both launching in windowed mode and switching to windowed mode after launching in fullscreen mode.

Earlier known issues should be fixed in the update of 2012-09-29, please re-test.

=== Fix improperly calculated window size in initial Windowed mode ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/18/fix-improperly-calculated-window-size-in CWE PR #18] by Deledrius (ported by Lyrositor) and CWalther

Verify that in windowed mode (after launching in windowed mode, after switching from fullscreen (larger or smaller) or from a differently sized window (larger or smaller)), the content size of the window is exactly as many pixels as it should be from the resolution you’ve set. Previously, when launching in windowed mode, the size would be slightly off, which would manifest itself in a periodic grid of seams or blurriness across the window, most noticeable when moving the cursor over them. Reference picture of the seams: [http://uru.zero-factorial.com/images/bugs/resizetiling.png http://uru.zero-factorial.com/images/bugs/resizetiling.png]

=== Improved Cursors ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/10/improved-cursors CWE PR #10] by Deledrius and CWalther

Revel in the glory of good-looking mouse cursors, voice chat indicators, and loading linking book animation.

=== Remove broken share symbol from Sharper's Office linking book ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/13/remove-broken-share-symbol-from-sharpers MOULSCRIPT PR #13] by D'Lanor

Verify that the linking book in the fish tank in Sharper’s office in Teledahn, going to the city office, has no share symbol in the close-up view. (The share symbol was included by mistake, as the city office is a neighborhood-instanced age, which cannot be shared. Previously, attempts to share would not work as expected, sending sharer and sharee to different instances.)

The share symbol is still visible from a distance on the book as it lies in the fish tank, this cannot be fixed until we are allowed to change the content files.

=== Correct an invalid GZGlass state ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/14/correct-an-invalid-gzglass-state MOULSCRIPT PR #14] by Hoikas, ported by Lyrositor

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/14/correct-an-invalid-gzglass-state#comment-11289 Conjecturedly] no user-visible effect on MOULa. On Minkata, new neighborhoods (DRC or player-created) should get a randomly selected one of the three possible Great Zero stained glass designs.

=== Avatar physics update ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/20/avatar-physics-update CWE PR #20], [https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/22/fix-intermittent-spawn-bug #22], [https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/17/vogondola-changes-for-cwe-avatar-physics MOULSCRIPT PR #17] by Skoader

To test: too many areas potentially affected to list here, see [[PhysX_Update_Testing_(Minkata.71)]]. Easy ways to tell that the update is in effect: • leaves in Kadish are kickable, • avatar does not shake while riding Er'cana harvester.

=== Fix pellet points stealing ===

[https://bitbucket.org/OpenUru_org/moulscript-ou/pull-request/16/fix-pellet-points-stealing-see-https MOULSCRIPT PR #16] by D'Lanor

- Player A links to hood with empty imagers. - Player B links to same hood and uploads pellet points (right imager). - Name of player B should appear next to new score on imager. (Imager message will still say “From: A”, this is an unrelated and known issue.)

See also [https://foundry.openuru.org/jira/browse/MOULSCRIPT-6 JIRA MOULSCRIPT-6].

== Update 2013-04-09 – Minkata.74 ==

=== Bink removal ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/27/stub-out-plclient-bink-support CWE PR #27] by Hoikas and CWalther

Proprietary parts have been removed from the source code. There should be no user-visible change. Verify that the Cyan logo (played at launch) and Yeesha intro (played before a new avatar appears on Relto and on request from the wrench dialog) videos still behave as if they had zero length, i.e. the Cyan logo is simply skipped, and for the Yeesha intro the room appears briefly and fades out again immediately.

== Update 2013-04-12 – (unreleased) ==

=== Fix remote code execution through Python.Cheat and Python.RunFile ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/24/fix-remote-code-execution-through CWE PR #24] ([https://github.com/H-uru/Plasma/pull/218 H-uru PR 218]) by boq, ported by Lyrositor

No user-visible change. Playing Uru becomes safer, as a security issue is fixed that a malicious player in the same age could exploit to do pretty much anything to your computer.

=== Free the cursor, update ===

[https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/25/free-the-cursor-update CWE PR #25] (part of [https://github.com/H-uru/Plasma/pull/221 H-uru PR 221]) by Hoikas, ported by CWalther

A bugfix update for ''Free the cursor'' above. Verify that in windowed mode, while having the left mouse button down to walk by mouse, having the right mouse button down to look around by mouse, or both, in any order, the cursor will never go outside of the window and break the continuous turning, even with very quick mouse movements.

[[Category:Minkata Shard]]

Minkata Shard: Contributions under Test

2013-04-09T18:12:01Z

Christian Walther: + Minkata.74

Minkata Shard: Contributions under Test

2013-03-26T20:29:10Z

Christian Walther: + Avatar physics update + Fix pellet points stealing

Minkata Shard: Contributions under Test

2012-09-30T08:41:06Z

Christian Walther: /* Free the cursor */ updated for build 61 (2012-09-29)

Minkata Shard: Contributions under Test

2012-09-26T13:23:43Z

Christian Walther: Created page with "This is a list of changes currently accumulating on the Minkata shard for later pick-up into MOULa by Cyan, and how to test them. === Fixed console documentation === [https://..."

Build the client with MSVC 2003

2012-07-12T20:00:47Z

Christian Walther: /* Build steps */ zlib + libpng installation instructions

{{UruDocProj}}
== Introduction ==
This document provides steps to build the CWE client with minimal changes from the initial Cyan source release. It is assumed that you have the initial Cyan source commit, the four commits made by a'moaca (add jpeg-8c library, remove EAX, replace IJL with IJG, and remove Bink), and the one made by cjkelly1 (modify the MsDevProjects and add batch files) in your source tree. Be aware that subsequent commits by other developers may invalidate these instructions.

== Items needed to compile ==
* Microsoft Visual Studio 2003 .NET
* Microsoft Platform SDK February 2003 edition (build 5.2.3790.0) (see links and note below)
* [http://www.microsoft.com/downloads/en/details.aspx?familyid=1c8dc451-2dbe-4ecc-8c57-c52eea50c20a&displaylang=en&pf=true Microsoft DirectX 9.0 SDK (October 2005)]
* [http://www.openssl.org/source/openssl-0.9.8q.tar.gz OpenSSL 0.9.8q]
* [http://downloads.xiph.org/releases/ogg/libogg-1.2.0.zip libogg-1.2.0]
* [http://downloads.xiph.org/releases/vorbis/libvorbis-1.2.0.zip libvorbis-1.2.0]
* [http://connect.creativelabs.com/openal/Downloads/OpenAL11CoreSDK.zip OpenAL v1.1 SDK]
* [http://developer.download.nvidia.com/PhysX/2.6.4/PhysX_2.6.4_SDK_Core.exe Ageia PhysX 2.6.4 Core SDK]

== Instructions to obtain the Microsoft Platform SDK February 2003 edition ==

The old MS Platform SDK is no longer available as a single package from Microsoft. You will have to either order it for $10 from MS, or download the parts and build the install yourself. To build it yourself, download the files from the below links into the same directory.

[http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.1.cab PSDK-FULL.1.cab] 
[http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.2.cab PSDK-FULL.2.cab] 
[http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.3.cab PSDK-FULL.3.cab] 
[http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.4.cab PSDK-FULL.4.cab] 
[http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.5.cab PSDK-FULL.5.cab] 
[http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.6.cab PSDK-FULL.6.cab] 
[http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.7.cab PSDK-FULL.7.cab] 
[http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.8.cab PSDK-FULL.8.cab] 
[http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.9.cab PSDK-FULL.9.cab] 
[http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.10.cab PSDK-FULL.10.cab] 
[http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.11.cab PSDK-FULL.11.cab] 
[http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.12.cab PSDK-FULL.12.cab] 
[http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.13.cab PSDK-FULL.13.cab] 
[http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/PSDK-FULL.bat PSDK-FULL.bat] 
[http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-us/3790.0/FULL/Extract.exe Extract.exe]

Run the batch file that is in the directory, and it will build the install. After doing this, you can either install the SDK directly, or burn it onto a CD so you will have it for later and install from there (I recommend burning to a CD, as this multi-part thing is a hassle).

'''Note on versions:''' I am using this older stuff because it is closest to what Cyan builds with. These instructions have only been tested with these specific versions. If you use other versions of the SDKs and such, you will have to adjust for the changes. If you do use different versions, it would be greatly appreciated if you would add a section to this document explaining what you had to do to use the newer versions, so everyone can benefit from your work.

== Build steps ==
<ol>
<li> Obtain CWE sources from the repository.</li>
<li> Install MS Platform SDK. You only need the "Core SDK" and the "Internet Development SDK". You do not need to use the setup.exe in the root of the SDK installer directory - this is merely a splash page and requires IE. Instead, go to the "setup" directory and run "CoreSDK-x86.msi" and then run "IESDK-x86.msi". Note that the "-ia64" installers are for Itanium 64 bit machines, and will not run in x64. '''Note:''' Do not copy the .msi files somewhere else and run them. They need to be run in the same directory as all the *.cab files.</li>
<li> Copy the include and lib directories from the SDK to "\CWE\MOULOpenSourceClientPlugin\StaticSDKs\Win32\PlatformSDK". '''Note:'''The directory where the SDK resides will be the one specified in the "Select An Installation Location" dialog when you ran the .msi files. This location will vary by platform. 
Directory structure in the CWE tree will look like this:
<pre>
StaticSDKs
Win32
PlatformSDK
include
lib</pre>
</li>
<li> Build libogg and libvorbis using MSVC 2003.</li>
<ol style="list-style-type:lower-latin">
<li>Create a directory and then create two subdirectories under it called "ogg" and "vorbis".</li>
<li>Unpack the sources into their respective directories. Make sure it does not do ogg\ogg-1.2.0, or some such thing. Vorbis depends on ogg, and it looks for the ogg stuff in ..\ogg.</li>
<li>Fire up MSVC 2003.</li>
<li>Do File -> Open -> Project, and select the ogg\win32\VS6\ogg_static.vcproj file. It will prompt to convert and open the project - click "Yes".</li>
<li>On the drop down box on the top of the window, change it from "debug" to "release".</li>
<li>Right-click on the "ogg_static" project and select build. Accept the "save file as" defaults in the box that pops up and just click "save".</li>
<li>ogg build is done. Under win32\VS6\Static_Release, there will be a ogg_static.lib file.</li>
<li>File -> Close Solution</li>
<li>Do File -> Open -> Project and select the vorbis\win32\vorbis_static.dsp file. It will prompt to convert and open the project - click "Yes".</li>
<li>On the drop down box on the top of the window, change it from "debug" to "release".</li>
<li>Right-click on the "vorbis_static" project and select build. Accept the "save file as" defaults in the box that pops up and just click "save".</li>
<li>vorbis build is done - under win32\Vorbis_Static_Release, there will be a vorbis_static.lib file.</li>
<li>File -> Close Solution</li>
<li>Start at step (i), and repeat the steps, choosing "vorbisfile_static.dsp" instead. You will have under vorbis\win32\VorbisFile_Static_Release a vorbisfile.static.lib file when done. </li>
</ol>

'''Note:''' Warnings in the build process are ogg/vorbis problems, and fixing an old release of ogg/vorbis is outside the scope of this document. Also, we are using the VC6 projects instead of the MSVC 2003 ones so that the file names and such will match what Cyan has in their projects. You can build the MSVC 2003 projects if you wish, but you will have to either change the output file names to match the VC6 ones, or change Cyan's projects to use the names the MSVC 2003 projects use. Building the VC6 ones required the less changing of the projects.

<li>Copy the contents of your ogg directory and then vorbis directory into "CWE\MOULOpenSourceClientPlugin\StaticSDKs\Win32\oggvorbis". It is okay to let it overwrite. Once that is done, copy the lib files you created above into "CWE\MOULOpenSourceClientPlugin\StaticSDKs\Win32\oggvorbis\lib" 
Directory structure in the CWE tree will look like this:
<pre>
StaticSDKs
win32
oggvorbis
doc
examples
include
lib
....</pre>
</li>
<li>Install the OpenAL SDK and copy it to "\CWE\MOULOpenSourceClientPlugin\StaticSDKs\Win32\OpenAL 1.1 with EFX SDK" 
Directory structure in the CWE tree will look like this:
<pre>
StaticSDKs
win32
OpenAL 1.1 with EFX SDK
docs
include
libs
....</pre>
</li>
<li>Install the DirectX 9.0c SDK and copy it to "\CWE\MOULOpenSourceClientPlugin\StaticSDKs\Win32\DX9.0c" 
Directory structure in the CWE tree will look like this:
<pre>
StaticSDKs
Win32
DX9.0c
Developer Runtime
Documentation
include
Lib
.....</pre>
</li>
<li>Install "PhysX 2.6.4 SDK Core" (or, if you have or can obtain it, 2.6.0) and copy it to "\CWE\MOULOpenSourceClientPlugin\StaticSDKs\Win32\PhysX". You must use a 2.6.x version, because the mesh cooking format was changed in 2.7.x.

You will copy subdirectories from "C:\Program Files\AGEIA Technologies\AGEIA PhysX SDK\v2.6.4\SDKs" and C:\Program Files (x86)\AGEIA Technologies\AGEIA PhysX SDK\v2.6.4\Bin" 
Directory structure in the CWE tree will look like this:
<pre>
StaticSDKs
Win32
PhysX
Bin
Cooking
Docs
Foundation
Framework
lib
.....</pre>
</li>
<li>Compile and install OpenSSL (see [[Build OpenSSL with MS Visual C++]]). As this is security software, it is best (in my opinion) to compile it yourself from source. You can choose either static or dynamic linking. '''Note:''' If you link it dynamically, it will cause the Uru client to require the OpenSSL DLLs to be present in the client directory or in the system path. Copy the installed stuff to "\CWE\MOULOpenSourceClientPlugin\StaticSDKs\Win32\OpenSSL" (created by "make install" - you do not want your development tree here). 
Directory structure in the CWE tree will look like this:
<pre>
StaticSDKs
Win32
OpenSSL
bin
include
openssl
lib</pre>
</li>
<li>Open up "Visual Studio .NET 2003 Command Prompt" and change to the "\CWE\MOULOpenSourceClientPlugin\StaticSDKs\XPlatform\jpeg-8c-rgba directory." Copy makefile.vc to makefile.nmake, and jconfig.vc to jconfig.h and then run ''nmake nodebug=1 -f makefile.nmake''. This will build the library in non-debug mode. If you use a debug library, the linker will complain when we link the client executable.</li>
<li>Install zlib and libpng 
''Interim notice:'' This step applies as soon as [https://bitbucket.org/OpenUru_org/cwe-ou/pull-request/10/improved-cursors pull request #10] is applied. Before, older versions of zlib and libpng are included in the CWE source tree. 
'''For Visual Studio 2003:'''
<ol><li>Download ''zlib127.zip'' (or a newer version) from [http://www.zlib.net/ http://www.zlib.net/], extract the ''zlib-1.2.7'' folder it contains and move/rename it to ''MOULOpenSourceClientPlugin/StaticSDKs/XPlatform/zlib''.</li>
<li>Download ''lpng1511.zip'' (or a newer version) from [http://libpng.org/pub/png/libpng.html http://libpng.org/pub/png/libpng.html], extract the ''lpng1511'' folder it contains and move/rename it to ''MOULOpenSourceClientPlugin/StaticSDKs/XPlatform/png''.</li>
<li>Open ''png/projects/visualc71/libpng.sln'' in Visual Studio 2003.</li>
<li>Right-click on the “libpng” project in the ''Solution Explorer'' and choose ''Properties''.</li>
<li>Select configuration “LIB Debug” in the popup menu at the top.</li>
<li>Select ''Configuration Properties'' > ''C/C++'' > ''Code Generation'' on the left.</li>
<li>Change the ''Runtime Library'' line to “Multi-threaded Debug DLL (/MDd)”. (This step avoids a warning in the final Plasma build. As far as I understand, leaving it out is harmless, but better do it to be sure.)</li>
<li>Choose the “LIB Release” configuration and set ''Runtime Library'' to “Multi-threaded DLL (/MD)”.</li>
<li>Repeat steps 4 to 8 for the other two projects “pngtest” and “zlib”.</li>
<li>Select “LIB Debug” from the ''Solution Configurations'' popup menu in the toolbar, then ''Build'' > ''Build Solution''.</li>
<li>Select the “LIB Release” configuration and build the solution.</li>
<li>Make a new folder ''png/lib'' and move ''png/projects/visualc71/Win32_LIB_Debug/libpngd.lib'' as well as ''png/projects/visualc71/Win32_LIB_Release/libpng.lib'' into it.</li>
<li>Make a new folder ''zlib/lib'' and move ''png/projects/visualc71/Win32_LIB_Debug/ZLib/zlibd.lib'' as well as ''png/projects/visualc71/Win32_LIB_Release/ZLib/zlib.lib'' into it.</li></ol>
'''For Visual Studio 2010:''' (if anyone ever makes a “Build with VS 2010” page, that could be moved there)
<ol><li>Download ''zlib127.zip'' (or a newer version) from [http://www.zlib.net/ http://www.zlib.net/], extract the ''zlib-1.2.7'' folder it contains and move/rename it to ''MOULOpenSourceClientPlugin/StaticSDKs/XPlatform/zlib''.</li>
<li>Download ''lpng1511.zip'' (or a newer version) from [http://libpng.org/pub/png/libpng.html http://libpng.org/pub/png/libpng.html], extract the ''lpng1511'' folder it contains and move/rename it to ''MOULOpenSourceClientPlugin/StaticSDKs/XPlatform/png''.</li>
<li>Open ''png/projects/vstudio/zlib.props'' in a text editor (Notepad or Visual Studio will do) and change the ''<ZLibSrcDir>'' element (third line from the bottom) to read
<code><ZLibSrcDir>..\..\..\..\zlib</ZLibSrcDir></code></li>
<li>Open ''png/projects/vstudio/vstudio.sln'' in Visual Studio 2010.</li>
<li>Right-click on the “zlib” project in the ''Solution Explorer'' and choose ''Properties''.</li>
<li>Select configuration “Debug Library” in the popup menu at the top.</li>
<li>Select ''Configuration Properties'' > ''C/C++'' > ''Preprocessor'' on the left.</li>
<li>Insert <code>_CRT_SECURE_NO_WARNINGS;_CRT_NONSTDC_NO_DEPRECATE;</code>
into the ''Preprocessor Definitions'' line (so that it reads <code>WIN32;_DEBUG;_WINDOWS;_CRT_SECURE_NO_WARNINGS;_CRT_NONSTDC_NO_DEPRECATE;%(PreprocessorDefinitions)</code> afterwards).</li>
<li>Select ''Configuration Properties'' > ''C/C++'' > ''Code Generation'' on the left.</li>
<li>Change the ''Runtime Library'' line to “Multi-threaded Debug DLL (/MDd)”. (This step avoids a warning in the final Plasma build. As far as I understand, leaving it out is harmless, but better do it to be sure.)</li>
<li>Choose the “Release Library” configuration and repeat step 8 (so that the line reads <code>_CRT_SECURE_NO_WARNINGS;_CRT_NONSTDC_NO_DEPRECATE</code> afterwards).</li>
<li>Set ''Runtime Library'' to “Multi-threaded DLL (/MD)” like in step 10.</li>
<li>Close the ''zlib Property Pages'' dialog.</li>
<li>Repeat the ''Runtime Library'' setting (steps 10 and 12) on projects ''libpng'', ''pngtest'', ''pngvalid''.</li>
<li>Right-click on the “zlib” project and choose ''Add'' > ''Existing Item…''.</li>
<li>Navigate to ''StaticSDKs/XPlatform/zlib'', select all ''*.c'' files there (sort the list by file type to make this easier), and click ''Add''. This should add files ''gzclose.c'', ''gzlib.c'', ''gzread.c'', ''gzwrite.c'' to the project, the rest should have been there already.</li>
<li>Select “Debug Library” from the ''Solution Configurations'' popup menu in the toolbar, then ''Build'' > ''Build Solution''.</li>
<li>Select the “Release Library” configuration and build the solution.</li>
<li>Make new folders ''png/lib'' and ''zlib/lib'' and move and rename the following files into them:
<ul><li>png/projects/vstudio/Debug Library/libpng15.lib → png/lib/libpngd.lib</li>
<li>png/projects/vstudio/Debug Library/zlib.lib → zlib/lib/zlibd.lib</li>
<li>png/projects/vstudio/Release Library/libpng15.lib → png/lib/libpng.lib</li>
<li>png/projects/vstudio/Release Library/zlib.lib → zlib/lib/zlib.lib</li></ul></li></ol>
</li>
<li>Once you have completed all the setup steps, open a "Visual Studio .NET 2003 Command Prompt" again, and change directory to the root of the CWE source. Run "build-allclient-solution.bat" and wait. If all is well, you will have a plClient.exe and UruLauncher.exe, along with the matching PhysX DLLs, in "CWE\MOULOpenSourceClientPlugin\Plasma20\test". Rename plClient.exe to UruExplorer.exe, and copy the executables and DLLs to your "Uru Live" directory. You do not need to copy in the *.pdb. *.map, or sp.dll files for a live external build. Those are only used by the internal builds.</li>
</ol>
 

== Additional notes ==

* This is built as a '''PLASMA_EXTERNAL_RELEASE''', '''BUILD_TYPE_LIVE''' build.
* Only the "Win32|Release" target will build with the changes I loaded to the repository. I did not modify any other build types, so if you wish to build those, you will have to fix them up first.

* Crypto keys are located in "CWE\MOULOpenSourceClientPlugin\Plasma20\Sources\Plasma\NucleusLib\pnNetBase". Edit the *.hpp files with a text editor to replace the Cyan keys with your own server's keys. A future action item is to move the keys to an external INI and add a dialog which will allow the user to select the keys for the server they are connecting to.
'''Important:''' Make sure to run "clean-allclient-solution.bat" and rebuild when you change crypto keys, to make sure they are updated.

* Server hostnames are located in the following files:

The status URL: 
"CWE\MOULOpenSourceClientPlugin/Plasma20/Sources/Plasma/Apps/plClient/winmain.cpp"
"CWE\MOULOpenSourceClientPlugin/Plasma20/Sources/Plasma/Apps/plUruLauncher/Main.cpp"

The auth/gatekeeper address 
"CWE\MOULOpenSourceClientPlugin/Plasma20/Sources/Plasma/NucleusLib/pnNetBase/Private/pnNbSrvs.cpp"

<big>'''IMPORTANT:'''</big> You '''*must*''' make sure your client is using the same versions of the PhysX DLLs that you built with. They
are not compatible from version to version.

[[Category:Cyan_Worlds]]

MOULa Update 2012-05-29 (Build 912)

2012-05-28T19:41:16Z

Christian Walther: /* Avatar clothing fix */ Add forgotten section

This is a list of (most of the) changes submitted to Cyan for the 2012-05-29 MOULa update and how to test them, mostly copied and pasted together from commit messages, code review, and forum posts.

=== Fix for the Er'cana bakery elevator getting stuck permanently ===

Start the elevator and immediately link to Relto. Return and start the elevator. It should still work.

=== Relto visitors should not see blank pages in the city book ===

Visit another player's Relto. The Relto owner must set the city book on page 2 or higher. Open the city book and verify that it shows you the black swirly cloud image and not a blank page. Close the book and have the Relto owner check that it is still on the same page he/she left it.

=== Make Calendar Star SDL Consistent ===

Ensure you have fireworks when you collect all 12 sparklies and the calendar island Yeesha page is on.

=== Fix inconsistent behavior of city book clasp ===

Make sure you have at least one link to the real city age (Balconies, Tokotah roof, Kadish gallery, Great tree tunnel) in your city book (this is what previously triggered the bug). Set the clasp to unlocked. Relink and verify that it is still unlocked. Open the city book and check if the animations of clasp and book correspond (book should not slide through clasp, clasp should not click open if it already shows as open).

=== Fix unclickable left-arrow in KI when destination is top of category list ===

# Select the middle set of KI functions.
# Let the left column be known as the "Category" column. Categories include Age Players, Buddies, Neighbors, Recent, Ignore List, and the Age Visitors Lists.
# Select a piece of content from one of the categories (try an explorer name in the 'Recent' folder)
# Arrows appear pointing left for acceptable destinations for the name. Buddies, Recent, and Ignore List are typically enabled, as well as the Age Visitors Lists (used for invitations).
# Use the down arrow at the bottom-right corner of the Categories until a destination you might want to use is in the topmost visible position, right under the gears symbol. The left-arrows should follow along with the categories that they are next to.
# Try clicking the left-arrow next to the top-most position.

''Expected (new) behavior:'' Item should be copied to the destination.

''Actual (previous) behavior:'' Nothin'. The top-most left-arrow is not functioning.

=== Improve Big KI player list sorting ===

In the big (open) KI:
* The age players list is now alphabetically sorted instead of distance sorted.
* Alphabetic sorting is now case insensitive for the big KI player lists.

This does NOT affect the left side lists of the mini (closed) KI.

=== Fix the fearless quabs bug ===

This fixes a specific problem that appeared on MOSS and should have no effect on Cyan’s server. Verify that quabs can still be chased by a single player. Any inability to chase quabs or other undesired behavior with multiple players is likely caused by unrelated bugs.

=== Improved video resolution code ===

* Resolution slider should allow selection of any resolution supported by your display from 800x600 or 1024x576 on upwards.
* Resolution slider should still point at the current resolution after switching from full-screen to windowed and back.

=== Allow plNotify variable events to carry integers in addition to floats & Replace bookshelf workaround by improved fix ===

* Upload a KI note (text or image) with an odd vault node id > 16777216 to any imager. Note should appear on the imager and neither the sender nor any observers should crash. (All new nodes on MOULa have such high numbers, you may need multiple attempts to get an odd one – check in the server logs or using an internal client. Lawreth Stirincha can provide suitable ones.)
* Let an avatar with an odd KI number > 16777216 use their Relto bookshelf, with visitors present. Verify that the avatar can link and that everyone sees books move as expected (pulled out/pushed in) when they are opened, closed (explicitly or after linking), and deleted.
* Check multiplayer functionality of the elevator in the Kadish pyramid and of various levers, switches and buttons throughout the ages.

=== Disable broken bahro stone share symbols ===

Verify that the following bahro stones no longer have a share symbol:
{|
|-
! Location !! Destination
|-
| Ahnonay Workshop || Lower Bahro Cave
|-
| Er'cana Pellet Dispenser || Upper Bahro Cave
|-
| Teledahn Niche || Spy Room
|-
| Tokotah Alley || Descent
|-
| Neighborhood Linking Room || Ae'gura
|-
| Gira Pool || Tokotah Rooftop
|-
| Gahreesen Conference Room || Palace Rooftop
|-
| Kadish 2nd Scope || Palace Balcony
|}

Verify that the following bahro stones still have a share symbol and sharing still takes the sharee to the sharer’s instance:
{|
|-
| Teledahn War Shroom || Gahreesen Prison Cell
|-
| Ae'gura Library || Kadish Pyramid
|-
| Ferry Terminal || Teledahn Dock
|-
| Baron’s City Office || Teledahn Stump
|-
| Kemo Statue || Hood Classroom Rooftop
|-
| Gahreesen Locker || Hood Balcony
|}

=== Avatar clothing fix ===

Switch from 1st to 3rd person view (either manually or automatically e.g. when exiting a GUI). ''Previous behavior:'' Your avatar would be drawn in white (untextured) for one frame. ''Expected new behavior:'' Avatar is drawn properly textured from the start.

=== Basic clipboard functionality ===

Adds following commands to single- (e.g. chat input) and multiline (e.g. KI mail) edit boxes: Ctrl-C – copy field contents to system clipboard, Ctrl-V – paste contents of clipboard at current cursor position.

Apart from verifying basic functionality, check that nothing happens when attempting to paste
* longer text than the field limit (500 chars for the chat input line IIRC)
* with nothing on the clipboard
* with non-text (e.g. bitmap image) on the clipboard.

=== DST Fix ===

Use your time machine to verify that KI time changes to and from daylight saving time at the same times as Mountain Time on the surface, no matter what the local time zone setting is (specifically, no matter whether the local time zone is on DST at that time).

=== Fix Landing Behaviors ===

Due to unrelated bugs, landing behaviors still do not work when you are running at the 30 FPS limit and when your frame rate is too low (~10 FPS). To be able to verify this fix, choose your graphics quality settings and your surroundings (more complex scene in view => lower frame rate) such that you get a frame rate of about 15 to 30 FPS. Rules of thumb: If you barely get off the ground when doing a standing jump, your frame rate is too high (you're running at the limit). If you get a falling animation but no landing animation when doing a standing jump, your frame rate is too low.

Verify that when landing straight down, e.g. after a standing jump, you get a knee-bending landing animation. Verify that when landing forward, e.g. after a walking or running jump on a horizontal plane, no matter which direction relative to world or subworld, you get a forward-stepping landing animation (this animation is hardly noticeable, the easiset way to recognize its presence is the sound it makes - when there is no landing animation, there also is no sound).

=== Fix an Aspect Ratio Assumption ===

This is an internal cleanup that should cause no observable change. To verify that FOV animation still works, try entering and leaving the camera region around the music player in the Relto hut, or using the Teledahn gun visor.

MOULa Update 2012-05-29 (Build 912)

2012-05-25T20:22:47Z

Christian Walther: Created page with "This is a list of (most of the) changes submitted to Cyan for the 2012-05-29 MOULa update and how to test them, mostly copied and pasted together from commit messages, code revie..."

This is a list of (most of the) changes submitted to Cyan for the 2012-05-29 MOULa update and how to test them, mostly copied and pasted together from commit messages, code review, and forum posts.

=== Fix for the Er'cana bakery elevator getting stuck permanently ===

Start the elevator and immediately link to Relto. Return and start the elevator. It should still work.

=== Relto visitors should not see blank pages in the city book ===

Visit another player's Relto. The Relto owner must set the city book on page 2 or higher. Open the city book and verify that it shows you the black swirly cloud image and not a blank page. Close the book and have the Relto owner check that it is still on the same page he/she left it.

=== Make Calendar Star SDL Consistent ===

Ensure you have fireworks when you collect all 12 sparklies and the calendar island Yeesha page is on.

=== Fix inconsistent behavior of city book clasp ===

Make sure you have at least one link to the real city age (Balconies, Tokotah roof, Kadish gallery, Great tree tunnel) in your city book (this is what previously triggered the bug). Set the clasp to unlocked. Relink and verify that it is still unlocked. Open the city book and check if the animations of clasp and book correspond (book should not slide through clasp, clasp should not click open if it already shows as open).

=== Fix unclickable left-arrow in KI when destination is top of category list ===

# Select the middle set of KI functions.
# Let the left column be known as the "Category" column. Categories include Age Players, Buddies, Neighbors, Recent, Ignore List, and the Age Visitors Lists.
# Select a piece of content from one of the categories (try an explorer name in the 'Recent' folder)
# Arrows appear pointing left for acceptable destinations for the name. Buddies, Recent, and Ignore List are typically enabled, as well as the Age Visitors Lists (used for invitations).
# Use the down arrow at the bottom-right corner of the Categories until a destination you might want to use is in the topmost visible position, right under the gears symbol. The left-arrows should follow along with the categories that they are next to.
# Try clicking the left-arrow next to the top-most position.

''Expected (new) behavior:'' Item should be copied to the destination.

''Actual (previous) behavior:'' Nothin'. The top-most left-arrow is not functioning.

=== Improve Big KI player list sorting ===

In the big (open) KI:
* The age players list is now alphabetically sorted instead of distance sorted.
* Alphabetic sorting is now case insensitive for the big KI player lists.

This does NOT affect the left side lists of the mini (closed) KI.

=== Fix the fearless quabs bug ===

This fixes a specific problem that appeared on MOSS and should have no effect on Cyan’s server. Verify that quabs can still be chased by a single player. Any inability to chase quabs or other undesired behavior with multiple players is likely caused by unrelated bugs.

=== Improved video resolution code ===

* Resolution slider should allow selection of any resolution supported by your display from 800x600 or 1024x576 on upwards.
* Resolution slider should still point at the current resolution after switching from full-screen to windowed and back.

=== Allow plNotify variable events to carry integers in addition to floats & Replace bookshelf workaround by improved fix ===

* Upload a KI note (text or image) with an odd vault node id > 16777216 to any imager. Note should appear on the imager and neither the sender nor any observers should crash. (All new nodes on MOULa have such high numbers, you may need multiple attempts to get an odd one – check in the server logs or using an internal client. Lawreth Stirincha can provide suitable ones.)
* Let an avatar with an odd KI number > 16777216 use their Relto bookshelf, with visitors present. Verify that the avatar can link and that everyone sees books move as expected (pulled out/pushed in) when they are opened, closed (explicitly or after linking), and deleted.
* Check multiplayer functionality of the elevator in the Kadish pyramid and of various levers, switches and buttons throughout the ages.

=== Disable broken bahro stone share symbols ===

Verify that the following bahro stones no longer have a share symbol:
{|
|-
! Location !! Destination
|-
| Ahnonay Workshop || Lower Bahro Cave
|-
| Er'cana Pellet Dispenser || Upper Bahro Cave
|-
| Teledahn Niche || Spy Room
|-
| Tokotah Alley || Descent
|-
| Neighborhood Linking Room || Ae'gura
|-
| Gira Pool || Tokotah Rooftop
|-
| Gahreesen Conference Room || Palace Rooftop
|-
| Kadish 2nd Scope || Palace Balcony
|}

Verify that the following bahro stones still have a share symbol and sharing still takes the sharee to the sharer’s instance:
{|
|-
| Teledahn War Shroom || Gahreesen Prison Cell
|-
| Ae'gura Library || Kadish Pyramid
|-
| Ferry Terminal || Teledahn Dock
|-
| Baron’s City Office || Teledahn Stump
|-
| Kemo Statue || Hood Classroom Rooftop
|-
| Gahreesen Locker || Hood Balcony
|}

=== Basic clipboard functionality ===

Adds following commands to single- (e.g. chat input) and multiline (e.g. KI mail) edit boxes: Ctrl-C – copy field contents to system clipboard, Ctrl-V – paste contents of clipboard at current cursor position.

Apart from verifying basic functionality, check that nothing happens when attempting to paste
* longer text than the field limit (500 chars for the chat input line IIRC)
* with nothing on the clipboard
* with non-text (e.g. bitmap image) on the clipboard.

=== DST Fix ===

Use your time machine to verify that KI time changes to and from daylight saving time at the same times as Mountain Time on the surface, no matter what the local time zone setting is (specifically, no matter whether the local time zone is on DST at that time).

=== Fix Landing Behaviors ===

Due to unrelated bugs, landing behaviors still do not work when you are running at the 30 FPS limit and when your frame rate is too low (~10 FPS). To be able to verify this fix, choose your graphics quality settings and your surroundings (more complex scene in view => lower frame rate) such that you get a frame rate of about 15 to 30 FPS. Rules of thumb: If you barely get off the ground when doing a standing jump, your frame rate is too high (you're running at the limit). If you get a falling animation but no landing animation when doing a standing jump, your frame rate is too low.

Verify that when landing straight down, e.g. after a standing jump, you get a knee-bending landing animation. Verify that when landing forward, e.g. after a walking or running jump on a horizontal plane, no matter which direction relative to world or subworld, you get a forward-stepping landing animation (this animation is hardly noticeable, the easiset way to recognize its presence is the sound it makes - when there is no landing animation, there also is no sound).

=== Fix an Aspect Ratio Assumption ===

This is an internal cleanup that should cause no observable change. To verify that FOV animation still works, try entering and leaving the camera region around the music player in the Relto hut, or using the Teledahn gun visor.

MOSS/Distribution Specific Instructions

2012-04-02T20:13:07Z

Christian Walther: /* Prerequesites */ Note on OpenSSL on Mac OS X 10.4 (in case anyone else is crazy enough to install on that old system)

This document is meant to collect any known distribution-specific instructions for installing [[MOSS]]. For general directions on installation, or if your distribution isn't listed here, you can consult [[MOSS/Setup]]. The general steps described in the main setup article are detailed for each individual OS or distribution for which documentation has been contributed. Feel free to contribute to the knowledge gathered here by adding information on the subject of your own distribution.

== Linux - Ubuntu ==
Installing MOSS on [http://www.ubuntu.com Ubuntu] is comparatively easy, and very few changes need to be made to the default instructions. In fact, what follows is mostly just applying general instructions to the specifics of this Linux distribution. Please note however that this does not provide full instructions for installation, as MOSS-Setup does a more-than-decent job of it already.

It is recommend to install MOSS only on Server LTS releases of Ubuntu for increased stability and reliability.

'''Current Ubuntu Server LTS version:''' Ubuntu 10.04.4 LTS.

=== Compile ===

==== Prerequisites ====

The programs listed on the main setup page are all conveniently available using APT. Running this command should be sufficient:
sudo apt-get install libssl-dev postgresql postgresql-server-dev-8.4 libpqxx-dev g++ autoconf automake libtool
If you also need to clone a Mercurial repository snapshot, you need to install Mercurial through the following command:
sudo apt-get install mercurial
Finally, the program unzip is recommended:
sudo apt-get install unzip

==== configure ====

By default in Ubuntu, MOSS will be installed under <code>/usr/local</code>. If you prefer another location (such as the home directory of the user who will run MOSS), be sure to specify with the '''--prefix''' option.

==== Compile ====

'''MOSS:''' MOSS should compile without any problems. If you are installing to a root-owned directory, make sure to use <code>sudo make install</code>, unless you rejoice in seeing a permission error message.

'''PostgreSQL module:''' assuming you run <code>sudo make install</code>, the PostgreSQL module should automatically be copied over to your PostgreSQL directory. Make sure to restart PostgreSQL with the following command:
sudo service postgresql-8.4 restart

=== Set Up the Database ===

The default PostgreSQL user in Ubuntu is <code>postgres</code>. If you don't change anything, only he is allowed to connect to the database, even if you have created a new role in PostgreSQL. It might therefore be to your advantage to create a new role in PostgreSQL matching the user which will run the server (e.g. moss); to do so:
sudo -u postgres createuser -l $USER
Which will automatically create a new role with the same name as your current user. You can now edit SQL tables you have access to without su-ing to the postgres user (don't forget to change all appropriate moss configuration files, as detailed below).

Now you can follow all other instructions as detailed in the main setup instructions.

=== Configuration Files ===

When setting up <code>moss_backend.cfg</code>, make sure you specify a PostgreSQL role with read and write access to your database (this can be same user as the one who will run MOSS, already authorized of access if you followed the previous recommendations).

== Mac OS X ==

=== Compile ===

==== Prerequesites ====

First, you need the Mac OS X [https://developer.apple.com/technologies/tools/ Developer Tools] installed.

Second, you need to install <code>libpqxx</code>, <code>zlib</code>, and <code>postgresql</code>. You can use [http://www.macports.org/ MacPorts] to install as follows:
sudo port install libpqxx zlib postgresql84 postgresql84-server

Some instruction guides for installing PostgreSQL (such as the README for EnterpriseDB's version) suggest editing <code>/etc/sysctl.conf</code> and increasing the shmall setting from the default (8192 under Mac OS X 10.6, exactly 1/4096th of shmmax). Whatever number you choose for shmall, it should be (a) smaller than shmmax, and (b) divisible by 4096. For example, a valid value might be:
kern.sysv.shmall=65536

MacPorts might not create the user and group accounts for postgres. For some reason, most instructions for installing PostgreSQL from MacPorts seem to gloss over this issue. You may need to manually create the postgres User and Group. This is accomplished in two phases.

First, identify the last user and group IDs already present.
sudo dscl . -list /Users UniqueID | sort -n -k 2 | tail -n 1
sudo dscl . -list /Groups PrimaryGroupID | sort -n -k 2 | tail -n 1
For each, take the number shown and add 1. These are your UniqueID and PrimaryGroupID numbers.

Second, replace the ### in the following commands as indicated to create the user and group.
sudo dscl . -create /Users/postgres UniqueID ###
sudo dscl . -create /Users/postgres PrimaryGroupID ###
sudo dscl . -create /Users/postgres HomeDirectory /opt/local/var/db/postgresql84
sudo dscl . -create /Users/postgres NFSHomeDirectory /opt/local/var/db/postgresql84
sudo dscl . -create /Users/postgres RealName "PostgreSQL Administrator"
sudo dscl . -create /Users/postgres Password \*
sudo dscl . -create /Groups/postgres PrimaryGroupID ###
sudo dscl . -create /Groups/postgres Password \*

The following instructions must be performed after installing PostgreSQL. If the <code>chown</code> step fails, then you're probably missing the user and group settings indicated above.
sudo mkdir -p /opt/local/var/db/postgresql84/defaultdb
sudo chown -R postgres:postgres /opt/local/var/db/postgresql84
sudo su postgres -c '/opt/local/lib/postgresql84/bin/initdb -D /opt/local/var/db/postgresql84/defaultdb'
sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql84-server.plist

The last line above should cause the server to start on reboot. Don't reboot yet - proceed to the database setup instructions where there are more steps you'll want to complete before starting the server.

===== Note on OpenSSL on Mac OS X 10.4 =====
If you install OpenSSL from source (this is necessary on Mac OS X 10.4, which ships with an older version (0.9.7) than required), make sure to also build shared libraries (''./config shared''). If you only build static libraries (the default choice), you will run into missing symbol errors, because the Mac OS X linker always prefers shared to static libraries and will therefore try to link to the system-provided shared library instead of the static one that the command line options point to.

==== configure ====

The bootstrap.sh file does not currently work because <code>libtoolize</code> is named <code>glibtoolize</code> under Mac OS X. A patch has been submitted. With the patched boostrap, you'll just need to <code>export LIBTOOLIZE=glibtoolize</code>.

If you installed PostgreSQL and libpqxx from MacPorts, your configure command line will need to look like this:
./configure --with-postgres=/opt/local/lib/postgresql84 --with-libpqxx=/opt/local

==== Compile ====

In the postgres subdirectory, the Makefile for the UUID generator expects pg_config to be in your PATH.
export PATH=${PATH}:/opt/local/lib/postgresql84/bin

The UUID generator Makefile may also fail because the MacPorts package doesn't automate linking to SSL. Alternate Makefile:
MODULE_big = moss_uuidgen
SHLIB_LINK += -lssl
PGXS := $(shell pg_config --pgxs)
include $(PGXS)

=== Set Up the Database ===

Copy <code>moss_uuidgen.so</code> to <code>/opt/local/lib/postgresql84/</code>. From the root of your MOSS build tree:

sudo cp postgresql/moss_uuidgen.so /opt/local/lib/postgresql84/

Now you need to start the server. The <code>&</code> backgrounds the process:
sudo su postgres -c '/opt/local/lib/postgresql84/bin/postgres -D /opt/local/var/db/postgresql84/defaultdb' &

The database user is postgres. Start <code>psql</code>, the postgreSQL command line interface, as user postgres:

sudo su -m postgres -c "/opt/local/lib/postgresql84/bin/psql postgres"

At the postgres prompt run these commands. If you are going to run MOSS as a user other than "moss", change the role name appropriately:

create database moss with encoding='UTF8' template = template0;
\c moss
create role moss with login;
\q

Then from the root of your MOSS build tree:
sudo su -m postgres -c "/opt/local/lib/postgresql84/bin/psql postgres -f postgresql/moss.sql"

==== Security Suggestion ====

For some installations of Postgres, experts recommend an additional step:
sudo dscl . -create /Users/postgres UserShell /usr/bin/false
After setting this up, you'll lose the ability to su to the postgres account to run other programs. So, this is a step you might take only after getting everything else working. To revert this step:
sudo dscl . -create /Users/postgres UserShell /bin/bash

== NetBSD ==

=== Compile ===

==== Prerequesites ====

Only PostgreSQL and the autotools are needed. You can build the packages or use the prebuilt packages with <code>pkg_add</code>.
pkg_add automake
pkg_add libtool
pkg_add libpqxx
I recommend starting with <code>libpqxx</code> because it seems to lag the postgresql-client package, and installing libpqxx will get the correct client.
pkg_add postgresqlNN-server
Where "NN" is the version number to match the client installed for pqxx.

Now follow these instructions:
copy /usr/pkg/share/examples/rc.d/pgsql to /etc/rc.d/pgsql
chmod 555 /etc/rc.d/pgsql
append pgsql=YES to /etc/rc.conf

=== Set Up the Database ===

Copy <code>moss_uuidgen.so</code> to <code>/usr/pkg/lib/postgresql/</code>

The database user is <code>pgsql</code>. It has root access to the DB by default. Connect from localhost (the default).

Create the database:
su -m pgsql -c "psql postgres"
create database moss with encoding='UTF8';
\c moss
create role moss with login;
\q
su -m pgsql -c "psql postgres -f moss.sql"

Then set "db_user = moss" in <code>moss_backend.cfg</code>.

== Solaris ==

''This section is currently a placeholder. If you have knowledge of the installation procedures, please fill in this section.''

Substantial customizations need to be applied to MOSS in order for it to be installed on Solaris. Examples of Solaris installations of MOSS include the Minkata shard.

== See Also ==
{{:MOSS/See Also}}

[[Category:MOSS]]

MOSS/Distribution Specific Instructions

2012-04-02T20:02:53Z

Christian Walther: /* Mac OS X */ Remove obsolete uncertainty declaration.

This document is meant to collect any known distribution-specific instructions for installing [[MOSS]]. For general directions on installation, or if your distribution isn't listed here, you can consult [[MOSS/Setup]]. The general steps described in the main setup article are detailed for each individual OS or distribution for which documentation has been contributed. Feel free to contribute to the knowledge gathered here by adding information on the subject of your own distribution.

== Linux - Ubuntu ==
Installing MOSS on [http://www.ubuntu.com Ubuntu] is comparatively easy, and very few changes need to be made to the default instructions. In fact, what follows is mostly just applying general instructions to the specifics of this Linux distribution. Please note however that this does not provide full instructions for installation, as MOSS-Setup does a more-than-decent job of it already.

It is recommend to install MOSS only on Server LTS releases of Ubuntu for increased stability and reliability.

'''Current Ubuntu Server LTS version:''' Ubuntu 10.04.4 LTS.

=== Compile ===

==== Prerequisites ====

The programs listed on the main setup page are all conveniently available using APT. Running this command should be sufficient:
sudo apt-get install libssl-dev postgresql postgresql-server-dev-8.4 libpqxx-dev g++ autoconf automake libtool
If you also need to clone a Mercurial repository snapshot, you need to install Mercurial through the following command:
sudo apt-get install mercurial
Finally, the program unzip is recommended:
sudo apt-get install unzip

==== configure ====

By default in Ubuntu, MOSS will be installed under <code>/usr/local</code>. If you prefer another location (such as the home directory of the user who will run MOSS), be sure to specify with the '''--prefix''' option.

==== Compile ====

'''MOSS:''' MOSS should compile without any problems. If you are installing to a root-owned directory, make sure to use <code>sudo make install</code>, unless you rejoice in seeing a permission error message.

'''PostgreSQL module:''' assuming you run <code>sudo make install</code>, the PostgreSQL module should automatically be copied over to your PostgreSQL directory. Make sure to restart PostgreSQL with the following command:
sudo service postgresql-8.4 restart

=== Set Up the Database ===

The default PostgreSQL user in Ubuntu is <code>postgres</code>. If you don't change anything, only he is allowed to connect to the database, even if you have created a new role in PostgreSQL. It might therefore be to your advantage to create a new role in PostgreSQL matching the user which will run the server (e.g. moss); to do so:
sudo -u postgres createuser -l $USER
Which will automatically create a new role with the same name as your current user. You can now edit SQL tables you have access to without su-ing to the postgres user (don't forget to change all appropriate moss configuration files, as detailed below).

Now you can follow all other instructions as detailed in the main setup instructions.

=== Configuration Files ===

When setting up <code>moss_backend.cfg</code>, make sure you specify a PostgreSQL role with read and write access to your database (this can be same user as the one who will run MOSS, already authorized of access if you followed the previous recommendations).

== Mac OS X ==

=== Compile ===

==== Prerequesites ====

First, you need the Mac OS X [https://developer.apple.com/technologies/tools/ Developer Tools] installed.

Second, you need to install <code>libpqxx</code>, <code>zlib</code>, and <code>postgresql</code>. You can use [http://www.macports.org/ MacPorts] to install as follows:
sudo port install libpqxx zlib postgresql84 postgresql84-server

Some instruction guides for installing PostgreSQL (such as the README for EnterpriseDB's version) suggest editing <code>/etc/sysctl.conf</code> and increasing the shmall setting from the default (8192 under Mac OS X 10.6, exactly 1/4096th of shmmax). Whatever number you choose for shmall, it should be (a) smaller than shmmax, and (b) divisible by 4096. For example, a valid value might be:
kern.sysv.shmall=65536

MacPorts might not create the user and group accounts for postgres. For some reason, most instructions for installing PostgreSQL from MacPorts seem to gloss over this issue. You may need to manually create the postgres User and Group. This is accomplished in two phases.

First, identify the last user and group IDs already present.
sudo dscl . -list /Users UniqueID | sort -n -k 2 | tail -n 1
sudo dscl . -list /Groups PrimaryGroupID | sort -n -k 2 | tail -n 1
For each, take the number shown and add 1. These are your UniqueID and PrimaryGroupID numbers.

Second, replace the ### in the following commands as indicated to create the user and group.
sudo dscl . -create /Users/postgres UniqueID ###
sudo dscl . -create /Users/postgres PrimaryGroupID ###
sudo dscl . -create /Users/postgres HomeDirectory /opt/local/var/db/postgresql84
sudo dscl . -create /Users/postgres NFSHomeDirectory /opt/local/var/db/postgresql84
sudo dscl . -create /Users/postgres RealName "PostgreSQL Administrator"
sudo dscl . -create /Users/postgres Password \*
sudo dscl . -create /Groups/postgres PrimaryGroupID ###
sudo dscl . -create /Groups/postgres Password \*

The following instructions must be performed after installing PostgreSQL. If the <code>chown</code> step fails, then you're probably missing the user and group settings indicated above.
sudo mkdir -p /opt/local/var/db/postgresql84/defaultdb
sudo chown -R postgres:postgres /opt/local/var/db/postgresql84
sudo su postgres -c '/opt/local/lib/postgresql84/bin/initdb -D /opt/local/var/db/postgresql84/defaultdb'
sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql84-server.plist

The last line above should cause the server to start on reboot. Don't reboot yet - proceed to the database setup instructions where there are more steps you'll want to complete before starting the server.

==== configure ====

The bootstrap.sh file does not currently work because <code>libtoolize</code> is named <code>glibtoolize</code> under Mac OS X. A patch has been submitted. With the patched boostrap, you'll just need to <code>export LIBTOOLIZE=glibtoolize</code>.

If you installed PostgreSQL and libpqxx from MacPorts, your configure command line will need to look like this:
./configure --with-postgres=/opt/local/lib/postgresql84 --with-libpqxx=/opt/local

==== Compile ====

In the postgres subdirectory, the Makefile for the UUID generator expects pg_config to be in your PATH.
export PATH=${PATH}:/opt/local/lib/postgresql84/bin

The UUID generator Makefile may also fail because the MacPorts package doesn't automate linking to SSL. Alternate Makefile:
MODULE_big = moss_uuidgen
SHLIB_LINK += -lssl
PGXS := $(shell pg_config --pgxs)
include $(PGXS)

=== Set Up the Database ===

Copy <code>moss_uuidgen.so</code> to <code>/opt/local/lib/postgresql84/</code>. From the root of your MOSS build tree:

sudo cp postgresql/moss_uuidgen.so /opt/local/lib/postgresql84/

Now you need to start the server. The <code>&</code> backgrounds the process:
sudo su postgres -c '/opt/local/lib/postgresql84/bin/postgres -D /opt/local/var/db/postgresql84/defaultdb' &

The database user is postgres. Start <code>psql</code>, the postgreSQL command line interface, as user postgres:

sudo su -m postgres -c "/opt/local/lib/postgresql84/bin/psql postgres"

At the postgres prompt run these commands. If you are going to run MOSS as a user other than "moss", change the role name appropriately:

create database moss with encoding='UTF8' template = template0;
\c moss
create role moss with login;
\q

Then from the root of your MOSS build tree:
sudo su -m postgres -c "/opt/local/lib/postgresql84/bin/psql postgres -f postgresql/moss.sql"

==== Security Suggestion ====

For some installations of Postgres, experts recommend an additional step:
sudo dscl . -create /Users/postgres UserShell /usr/bin/false
After setting this up, you'll lose the ability to su to the postgres account to run other programs. So, this is a step you might take only after getting everything else working. To revert this step:
sudo dscl . -create /Users/postgres UserShell /bin/bash

== NetBSD ==

=== Compile ===

==== Prerequesites ====

Only PostgreSQL and the autotools are needed. You can build the packages or use the prebuilt packages with <code>pkg_add</code>.
pkg_add automake
pkg_add libtool
pkg_add libpqxx
I recommend starting with <code>libpqxx</code> because it seems to lag the postgresql-client package, and installing libpqxx will get the correct client.
pkg_add postgresqlNN-server
Where "NN" is the version number to match the client installed for pqxx.

Now follow these instructions:
copy /usr/pkg/share/examples/rc.d/pgsql to /etc/rc.d/pgsql
chmod 555 /etc/rc.d/pgsql
append pgsql=YES to /etc/rc.conf

=== Set Up the Database ===

Copy <code>moss_uuidgen.so</code> to <code>/usr/pkg/lib/postgresql/</code>

The database user is <code>pgsql</code>. It has root access to the DB by default. Connect from localhost (the default).

Create the database:
su -m pgsql -c "psql postgres"
create database moss with encoding='UTF8';
\c moss
create role moss with login;
\q
su -m pgsql -c "psql postgres -f moss.sql"

Then set "db_user = moss" in <code>moss_backend.cfg</code>.

== Solaris ==

''This section is currently a placeholder. If you have knowledge of the installation procedures, please fill in this section.''

Substantial customizations need to be applied to MOSS in order for it to be installed on Solaris. Examples of Solaris installations of MOSS include the Minkata shard.

== See Also ==
{{:MOSS/See Also}}

[[Category:MOSS]]

MOSS/Notes

2012-04-02T19:59:05Z

Christian Walther: /* Questions */ Mac OS X / PowerPC additions

This page just holds various notes about running a MOSS server.

== Questions ==

I can't really call this a FAQ until the questions have been asked frequently.

; How do I add a user?
: [[MOSS/Setup#Create_Accounts]]
; How do I change the Python?
: Start with the source Cyan has generously provided us under the GPL. To compile that source you'll have to add in the glue. Maybe there is a tool to do that in the CWE source. Make your changes. After compiling and creating the .pak (another tool?), copy the .pak to the [[MOSS/Setup#Auth_Server_Data | correct server directory]] and encrypt it. Make a new .mbam file.
; How do I add a new age?
: Copy the encrypted .pak to the [[MOSS/Setup#Auth_Server_Data | correct server directory]], add the file to the Python.txt, and make a new .mbam file. Copy any SDL files to the auth SDL directory and encrypt them. Add them to SDL.txt and make a new .mbam file. Copy unencrypted SDL files to the [[MOSS/Setup#Game_Server_Data | correct server directory]]. Note if you have more than one SDL file for your age, or the file is not named the same as the age, you'll need to put the age's SDL file(s) in a directory named after the age. Copy the unencrypted .age file to the game server directory.
; Why would I use --enable-fork?
: This is primarily useful for testing. It's easier to debug a non-threaded process.
; What resource limitations are there (file descriptors, memory, etc.)?
: This is a question that's not obvious to answer. But here is what is known:
:* Currently MOSS uses about 5 file descriptors when idle. It uses about 10 per connected user. (4 are for the game server, so if the user links around a lot, it will be more, and if you have multiple users in one age it will be less.) If you are running a large shard, you may need to adjust per-process file descriptor limits (see the "ulimit" command) or even kernel (global) limits. If you adjust the global limit, pay attention to <tt>FD_SETSIZE</tt>. See the select() man page.
:* Currently MOSS uses 7 big buffers for network data per connected user. The buffer size is set by <tt>BUFSIZE</tt> in constants.h. The default is 64k, so a total of 448k per user. If you have enough users that your moss processes grow too large you can reduce the <tt>BUFSIZE</tt>.
:* There is not a lot of disk I/O, except for whatever the database has to write. If you set the log levels very low (DEBUG or worse, MSGS) then there will be a lot of I/O for log files.
; Does MOSS work on my PowerPC?
: It is supposed to! Testing of big-endian systems was done, but not a full, complete run-through of all game mechanics and multiplayer testing. Basic multiplayer exploration works. If it does not work, [[MOSS#How_to_Contribute | it's a bug]].
; Does MOSS work on Windows?
: No. There is a fair bit of porting work to do.
; Does MOSS work on OS X?
: Yes. Successful installations have been done on Mac OS X 10.6 (x86_64) and Mac OS X 10.4 (PowerPC) (although the latter takes a bit more work, as some of the prerequisite software that comes with the system is too old and newer versions must be installed from source).
; What is the "status" server type?
: MOSS will provide the status string normally fetched from a web server. You do have to make the client send the HTTP request to port 14617 or it won't do much good. This is a feature that perhaps only the author wants.

== Warnings ==

* Please note: The MOSS vault is as insecure as MOUL's. (I don't know what was done to MOULagain.) The MOSS server is almost as trusting of the client as MOUL's. (Or maybe more, in other ways; for example, there is no server-side profanity filter.) This is because a MOUL server was implemented, not some other server. Doing better is definitely possible. But to do it right is a very big project, because the entire ''system'' was designed with this trust model. You can't always change just one part of it to get where you want to be.

* Don't change the .mbm or file server files while you have clients doing File transactions. Doing so will give everything indigestion.

* I'm sure the same applies for .mbam and auth server files.

* The SDL mechanism depends on all servers in the shard having synchronized time. Use NTP if you have more than one server. (You'll also need to NFS mount the game/state directory on all the servers so the age SDL is available to all.)

== Setup Choices ==

* Disabling the client<->server encryption is NOT recommended. However, if you subscribe to the shortsighted idea that protecting your users is not important, go ahead. But be warned, there are code paths in MOSS that are completely untested when all encryption is disabled. You'll have to fix any bugs. (The [[Wireshark Plugin]] does support decrypting connections when you have the key, so you ''can'' use encrypted connections during development/testing.)

* MOSS supports using RSA for key negotiation. The client contribution to the session key is RSA-encrypted with the server public key and then sent to the server, which decrypts the message. Ironically, this actually is less crypto work, while using a non-modified standard encryption technology. And it has the same pseudo-authentication properties as the Cyan-style modified Diffie-Hellman. The assembler changes required for this are astonishingly small, but there's not much value in using RSA. Nonetheless, there's no need to remove working server support for it...

== While Running the Server ==

* You can change age SDL state server-side by modifying the state saved in files in the game/state directory. Keeping backups is advised. You may modify the files with the "sdl_reader" program (which you need to build separately using "make sdl_reader"). This is a very simple command-line program. Use the -l option to specify a saved file to read. When in the program, use the "h" command to see the help. Saving this file while a game server for that age is running is pointless; the new version won't be read and it will be overwritten when the server exits.

== Client Bug Workarounds ==

MOSS works around a few client bugs.

* MOSS "fixes" the KI light bug. It is a bug in the PRP files. MOSS has an extra check for determining whether SDL state is avatar-related, instead of relying on the flag that says whether to keep the SDL state around. That check covers the KI light, so the light SDL is tossed along with the rest of avatar SDL when a person leaves an age.

* MOSS may "fix" the footstep region bug. This bug is when you get the wrong footstep sound stuck, like that wooden bridge you left long ago clumping around while you're on stone. Everyone in the age hears the wrong footstep sounds. I believe that in normal play (that is, without things like /spawn) it is due to a race with the exclusive locking mechanism used to keep things like multiple button presses from being processed at the same time. Why footstep regions take a server-side exclusive lock is beyond me**, so MOSS grants '''all''' footstep region lock requests. This should make the problem occur less frequently, if at all (depending on how the client actually responds to receiving the lock after leaving the region). MOSS decides you are asking for a footstep region lock by looking for the word "Footstep" in the object name. ''Do not name buttons, door regions, or whatever with "Footstep" in your new ages.'' I suggest you do name footstep regions with "Footstep". The special case can be removed by removing <tt>#define GRANT_ALL_FOOTSTEPS</tt> from GameState.cc and recompiling.
:: **In fact, as a friend of mine pointed out, why are footstep sounds decided by the represented avatar's client and propagated to everyone else in the first place? It should be a purely local decision based on the location of each avatar as seen by that client. That would save on traffic and always be accurate, never mind the race with locking on the region since there would be no need to coordinate anything for a purely local decision.

* Quab game Python is not really complete. The first person to link to the age becomes the "owner" of the quab game. The Python sort of attempts to handle the situation where the game owner leaves the age while there are still quabs around, but it does not actually handle it. If the server attempts to pass ownership to someone else, that client will break. And the current MOULagain client even crashes. So MOSS works around the problem by intentionally breaking the whole game when the owner leaves the age and quabs are still present. All the quabs will remain frozen in place until the age has been cleared of all players. The age does not have to restart to revive the game, just be empty.

* The client supports two kinds of passwords, depending on the format of the username. If the username has the format x@x.x it uses algorithm 1 (a more secure one but also one with a fencepost error), and otherwise algorithm 2. Unfortunately the /changepassword command does not know about algorithm 2 and if you logged in with algorithm 2, it will try to change your password hash to the one for algorithm 1. This would result in you being unable to log in. So MOSS rejects requests to change the password if the username does not have the x@x.x format.

== Server Non-Bugs ==

These are problems with Cyan's server that MOSS does not have.

* MOSS does not have the infamous "zero seconds remaining" bug. Thus it is possible to do the auth downloads without the server waiting for acks from the client. This speeds up the download substantially as now the bandwidth can be fully utilized. (The [[MOSS/Setup#configure | --enable-fast-download]] configure option turns this on.)

* The MOUL server has a bug with quabs in Ahnonay. If you are the first person who linked into the age, the quabs are associated with your ID. When you link out of the age, the server is supposed to send a LoadClone message telling other clients to unload your clone (the avatar). The MOUL server sends the message, but it says to unload one of the quabs with your ID in it instead of the player avatar. Oddly, the client seems just fine with that. MOSS does not have this bug.

* You should see less client hitching while moving around with MOSS. The MOUL server sends a ton of node update messages for the (unchanged) city AgeInfo node. Each node update causes the client to fetch your pellet scores. The client is frozen during this (and most any) vault transaction. The MOSS server does not send all those useless updates. Interesting note: One measurement during MOUL was approximately 400 pellet score fetches an hour. That is the client freezing every 9 seconds regardless of what age you are in or how many people are in it or on your buddy list. (The pellet score fetch itself can probably be fixed in the Python but you'd still be wasting time on the city node.)

* The pellet score freeze can be further reduced by #defining <tt>PELLET_SCORE_CACHE</tt>, which does what it sounds like: it caches the client's pellet score in the Auth server to cut out the round-trip time to the DB. However, there's little value to it without the city node update problem; when you open the KI it fetches the score but it's also fetching other vault nodes. Plus you aren't trying to move at the time so the freeze is less obvious. So <tt>PELLET_SCORE_CACHE</tt> is undefined by default, and in fact it is ''untested''.

== See Also ==
{{:MOSS/See Also}}

[[Category:MOSS]]

MOSS/Setup

2012-04-02T19:47:28Z

Christian Walther: /* Prerequisites */ Add some empirical version information

'''[[MOSS]]''' currently only runs on UNIX and other *nix operating systems (such as GNU/Linux). Not Microsoft Windows. It ought to work on Mac OS/X (even PowerPC) but nobody has tried yet. The following document assists in the setup of MOSS on any of the compatible afore-mentioned operating systems. For instructions pertaining to a particular OS or Linux distribution, take a look at [[MOSS/Distribution Specific Instructions]].

Please also see the [http://foundry.openuru.org/fisheye/browse/MOSS/doc/setup main setup instructions] for an alternative set of installation instructions.

== Compile ==

=== Prerequisites ===

Before you start, assuming you already have a compatible OS, you need to ensure you have the following:
* pthreads (almost certainly installed already)
* libiconv (almost certainly installed already)
* OpenSSL (also almost certainly installed) -- you need both the libraries and the development headers if that's separate (I'm looking at you, Debian)
** ''Versions found to work:'' 1.0.1 – ''Versions found not to work:'' 0.9.7
* Zlib (also probably installed) -- both the library and the development stuff if separate
* PostgreSQL -- both the sever and client, plus any development packages
* libpqxx -- both the library and the development package
** ''Versions found to work:'' 3.1 – ''Versions found not to work:'' 4.0
* gcc, g++, whatever all you need for compiling C++

If you are compiling from a clone of a Mercurial respository and there is no "configure" script, you also need the autotools:
* autoconf
** ''Versions found to work:'' 2.68 – ''Versions found not to work:'' 2.59
* automake
** ''Versions found to work:'' 1.11.3 – ''Versions found not to work:'' 1.6.3
* libtool
** ''Versions found to work:'' 2.4.2 – ''Versions found not to work:'' 1.5

'''If you are reading this, please go over to''' [[MOSS/Distribution Specific Instructions]] '''and fill in how to install all these programs on YOUR distribution/OS. Thank you!'''

=== configure ===

''If you don't have a "configure" file, it must be generated. Run the '''<code>./bootstrap.sh</code>''' script to create it.''

Run '''<code>./configure</code>'''. The configure script takes many options. For a full listing run <code>./configure --help</code>. The default options are set up in such a way as to make your server match the way Cyan's server works. Here are the options you are probably interested in:
; --prefix
: Specifies where <code>make install</code> places the files. If you are using a non-typical location you may need to add <code>''prefix''/lib</code> to your LDFLAGS or something.
; --enable-fast-download
: During auth file downloads, Cyan's server waits for the client to acknowledge every 32k of data sent. I believe this was to fix the "zero seconds remaining" bug. MOSS does not have that bug. Use --enable-fast-download to configure the server to send data as fast as it can, thereby using all the bandwidth available.
; --disable-single-login
: If you use this, multiple different avatars on the same account can be logged in at once. Logging into the same avatar will boot the other. Without disabling "single login", logging into the same account will boot whatever avatar is logged in from that account.
Other options:
; --enable-require-secure-download
: Boot users who don't download <code>python.pak</code>.
; --enable-encryption=type
: The default is "cyan_dh". MOSS allows you to disable encryption, or (legacy) use [[MOSS/Notes#RSA | RSA]].
; --enable-fork
: The primary use for this is if you need to debug auth or file servers. It is much easier to debug single-threaded programs.
; --enable-debug
: Anyone developing MOSS or willing to run some extra bug-hunting code should use this. If the bug-hunting code finds a bad thing it will make the server dump core so you can debug it.
; --enable-old-protocol
: This makes MOSS use older protocol versions. You probably don't need this.
If you have any trouble with configure finding the locations of various libraries, you can use these:
; --with-postgres=PREFIX
; --with-libpqxx=PREFIX
; --with-openssl=PREFIX
; --with-zlib=PREFIX
; --with-iconv=PREFIX

=== Compile ===

Run '''<code>make</code>'''. Assuming that succeeds, you probably should use '''<code>make install</code>'''.

Now cd into the <code>postgresql</code> directory. Here you need to compile a custom PostgreSQL module that creates UUIDs. Follow the instructions in the README file there, but for most people this should just be running '''<code>make</code>''', followed by '''<code>make install</code>'''.

Install the PostgreSQL module in your PostgreSQL install, if it's not there already by now. Do this by copying the moss_uuidgen.so file you just compiled. You'll need to log in as root to do this (<code>sudo cp moss_uuidgen.so /path/to/postgres/modules</code> on most systems). Please check [[MOSS/Distribution_Specific_Instructions]] and fill in where to copy it for your system. Consult PostgreSQL documentation if you're not sure. After the library is installed, restart the DB server.

== Set Up the Database ==

The easiest way to set up the database is to create a "moss" user to be associated with the MOSS database. If you want to use a different username, you have to edit the <code>postgresql/moss.sql</code> file to match. The moss user needs to be able to modify tables in the MOSS DB.

Most distributions create some user that has root access to the DB when connecting from the local machine. In this example this user is "pgsql" but yours may be different. Please check [[MOSS-Distribution_Specific_Instructions]] for hints or to fill in the user for your distribution.

Start by creating the database. The default database name is "moss"; if you use any other you'll have to set it in the MOSS [[#Configuration_Files | configuration file]]. Make sure to use the "UTF8" encoding. Then create the "moss" user in the new database. Then load <code>"postgresql/moss.sql</code> into the new database.

I did the following:
su pgsql -c "psql postgres"
create database moss with encoding='UTF8';
\c moss
create role moss with login;
\q
su pgsql -c "psql moss -f moss.sql"
After this, you can connect to the database as the "moss" user:
psql -U moss

If all that works, you are done setting up the database!

== Set Up Files ==

There are quite a few files that the server needs to use. All these files are located by default in locations relative to where you will *start* the server. The location of all the files can be configured in the [[#Configuration_Files | configuration files]]; you may find it easiest to specify absolute paths (starting with <code>/</code>) there.

File hierarchy conventions used in this setup:
* No prefix: references the files found in your source download,
* <code>./</code>: references the directory from where you will start MOSS,
* <code>''prefix''</code>: references the directory where MOSS is being installed.

=== File Server Data ===

You need to start with your current Uru install (MOULagain, presumably). This procedure assumes you can run a Windows application to create the file server manifest MOSS needs. This seems a reasonable assumption when the client itself is a Windows app. So temporarily leave your *nix server alone and switch to a Windows installation with Uru installed.

Copy <code>support/ManifestCreator.exe</code> and <code>support/Manifests.zip</code> to your Windows box. Unzip <code>Manifests.zip</code>. This makes a <code>CyanStructure</code> folder. The <code>.txt</code> files in this folder are input. They describe the files which need to be in the final manifests. It is important to use <code>\</code> as the directory separator.

Start up <code>ManifestCreator.exe</code>. To generate a manifest, click "Make Manifest"; it brings up a dialog box. Navigate to the <code>CyanStructure</code> folder, and select all the <code>.txt</code> files in there. Then click OK and when it pops up with another dialog asking for the location of your Uru install, navigate to that directory, click OK and wait for a bit.

When it is done stop and consider which files you need the file server to actually give to clients. If you are making this shard for yourself it could be basically nothing, or everything. Note that we do not have a license to redistribute Cyan's data files. So '''it is recommended not to copy any files you should not distribute to your file server'''.

Back on the machine on which you are installing MOSS, create a file server directory. The default is <code>./file</code> (relative to where you will start up your MOSS server). I recommend you make it <code>''prefix''/file</code>. Copy all the <code>.mbm</code> files created in the <code>CyanStructure</code> folder on your Windows box to this directory. If you are serving up a CWE client (built from open source) you want to copy the gzipped executable and libraries. They are located in <code>CyanStructure\Client\External</code> and need to be in <code>''file dir''/Client/External</code> on your server to match. Anything you can distribute and that clients will need to download, like a new Age, should also be copied. Make sure to match the directory structures when copying them over.

''For Mac clients:'' Mac clients request the <code>macExternal</code> manifest instead of <code>External</code>. There are added files in the Mac manifest, but if you don't have them to generate a proper manifest from, just copy or symlink <code>External.mbm</code> to <code>macExternal.mbm</code>. If you do have the files, you can generate the proper manifest using ManifestCreator and the <code>support/macExternal.txt</code> file.

=== Auth Server Data ===

''A script automating all the following steps in this section (except for any user-created ages) is in the works.''

Like for the file server data, the default auth directory is <code>./auth</code> (relative to where you start it up). I recommend using <code>''prefix''/auth</code>.

This directory is required to have another subdirectory named <code>default</code>. You must keep a copy here of the encrypted Python and SDL files for clients to download. The easiest way to get a set of these files is from the Cyan-provided <code>[http://assets.openuru.org/cyan/AuthFiles.zip AuthFiles.zip]</code>. Download this file, and unzip it. Copy the entire contents of the resulting <code>AuthFiles/893</code> directory to <code>''auth dir''/default/</code>. The resulting directory structure is:
auth
default
Python
python.pak
SDL
various .sdl files
encryption.key
Now you have to make manifest files here as well. Make a <code>Python.txt</code> file which contains one line: <code>Python\python.pak</code>. Make an SDL.txt file which contains one line per file in the SDL directory, as in:
SDL\BaronCityOffice.sdl
SDL\Kveer.sdl
...
I just toss these manifest files in the <code>''auth dir''/default</code> directory but you don't have to. The server does not look at them.

If you have user-created ages with SDL files, be sure to add them to the <code>SDL</code> directory here. Encrypt them with the <code>encryption.key</code> (a tool to do this does exist in the CWE source). Similarly, if you want to add Python, you can rebuild the <code>python.pak</code> file, but if you are adding a new age, you may find it easier to add a new <code>.pak</code> file. If you do that, encrypt it and then add a new line to the <code>Python.txt</code> file for your new <code>.pak</code>. The client will download them all.

Once you have listed each SDL and Python file, you can use the Perl script <code>support/make-mbam.pl</code> to create the <code>.mbam</code> files. If you don't have Perl, <code>ManifestCreator.exe</code> can also create the files: simply select "Auth Server" in the "Manifest type" dropdown. If you use ManifestCreator, make sure it has the Python and SDL directories and their contents. Make sure to copy the resulting two <code>.mbam</code> files to your <code>''auth-dir''/default</code> directory.

=== Game Server Data ===

''A script automating all the following steps in this section (except for any user-created ages) is in the works.''

Just like for the file and auth server data, the default game directory is <code>./game</code> (relative to where you start it up). I recommend using <code>''prefix''/game</code>.

The game servers need unencrypted <code>.sdl</code> and <code>.age</code> files. The easiest way to get a set of these files is from the Cyan-provided <code>[http://assets.openuru.org/cyan/Scripts.zip Scripts.zip]</code>. Download this file and unzip it. Copy/move the <code>Scripts/SDL</code> directory to <code>''game-dir''</code>. Then create <code>''game-dir''/age</code> and copy <code>Scripts/dat/*.age</code> to it (MOSS does not use the <code>.fni</code> files).

Do not forget to copy any user-created ages' SDL and <code>.age</code> files here. This copy needs to be unencrypted.

Now there is one more step. The SDL files the game server uses need to be moved around, some into subdirectories, and some renamed because UNIX treats file names case-sensitively. Please read the details in the <code>doc/setup</code> file (linked at the top of this page).

You should have three subdirectories when you're done. User-created ages may need subdirectories too, if they have multiple <code>.sdl</code> files. If you find this way too complex, just move all the <code>.sdl</code> files into the common subdirectory. You lose some small optimizations this way and you will need to restart the server if any SDL files change.

At the end the directory structure should be:
game
age
various .age files
SDL
common
some .sdl files
Garrison
a couple of .sdl files
Teledahn
other .sdl files
more .sdl files

== Key Files ==

The modified Diffie-Hellman algorithm used in the client and MOSS by default requires the server to have private keys. '''Do not share them with anyone.''' They should not be world-readable.

You can generate keys using the <code>make_cyan_dh</code> program is installed in <code>''prefix''/bin</code>. Or, there might be a program to generate keys in the CWE source, but the chance of it outputting the private keys in the format MOSS wants is basically zero. Generate a key for each of auth, game, and gatekeeper. Run <code>make_cyan_dh -h</code> to see what generators to use if you want to match those MOULagain is using. If you're building your own client you can use whatever generator you want.

''Note:'' I see no reason not to use OpenSSL default generators such as 2, 3, or 5. In fact, unless you are a cryptographer, I do not recommend departing from these. If you are a cryptographer, you probably did not need to hear that from me!

The <code>-s</code> and <code>-c</code>/<code>-C</code> options direct the program to write the data for the server and client to files, respectively, e.g.:
make_cyan_dh -g 2 -s auth_key.der -C pnNbAuthKey.hpp
or
make_cyan_dh -g 2 -s auth_key.der -c auth_key.bin
If you're compiling a CWE client, you can use the <code>-C</code> option to output a C++ file that should be a drop-in replacement for the current key files (under <code>CWE/MOULOpenSourceClientPlugin/Plasma20/Sources/Plasma/NucleusLib/pnNetBase</code>). Make sure you have at least revision 2 of the MOSS source to use <code>-C</code> (you may need to do a clean and a rebuild if you have previously compiled CWE with a different key; the dependencies in the projects are not set up perfectly). If you're not compiling a client, you probably want the <code>-c</code> option, and it's up to you what to do with the <code>.bin</code> file.

Take the <code>.der</code> file (contains the PRIVATE key) and move it to <code>''prefix''</code>. I suggest using <code>''prefix''/etc/auth_key.der</code>. Make it readable only by the user which will be running the server:
chmod 400 ''prefix''/etc/auth_key.der
chown ''mossuser'' ''prefix''/etc/auth_key.der
Repeat this process for the game and gatekeeper keys: <code>''prefix''/etc/game_key.der</code> and <code>''prefix''/etc/gatekeeper_key.der</code>.

== Configuration Files ==

Now that you have all the other files set up, it's time to configure MOSS itself. There is a configuration file for each server process. The default location for <code>moss_backend</code> is <code>./etc/moss_backend.cfg</code> and the default location for <code>moss</code> is <code>./etc/moss.cfg</code>. I recommend copying <code>main.cfg</code> to <code>''prefix''/etc/moss.cfg</code> and <code>backend.cfg</code> to <code>''prefix''/etc/moss_backend.cfg</code>.

Now open each up in your text editor. The files contain instructions on how to set the various options.

I recommend you set the following in <code>moss.cfg</code> to the absolute paths corresponding to where you installed these files in earlier steps: <code>auth_download_dir</code>, <code>auth_key_file</code>, <code>file_download_dir</code>, <code>game_data_dir</code>, <code>game_key_file</code>, <code>gatekeeper_key_file</code>. In addition I recommend you set <code>log_dir</code> to somewhere you want log files to go. Remember the log directory has to be writable by the user that will run the server. You may also need to set <code>pid_file</code> to a location writable by that user. If you want the <code>.pid</code> file to be created. Read through all the options to make sure your setup is as you want. The only mandatory configuration directive is <code>external_address</code>.

For <code>moss_backend.cfg</code> look especially into <code>log_dir</code> and <code>pid_file</code>. In addition, depending on how your DB is
[[#Set_Up_the_Database | set up]] you likely need to specify <code>db_user</code>, <code>db_password</code> and maybe other DB parameters.

== Security Considerations ==

'''Please''' read about them at the end of [http://foundry.openuru.org/fisheye/browse/MOSS/doc/setup doc/setup]. Short version:
* '''Never''' run MOSS as root.
* <code>moss_backend.cfg</code> contains your DB user's password; do not make it world-readable (or even group-readable).
* Private key files (files finishing in <code>.der</code>) should never be made public.
* No encryption is currently available for all the backend connections.
* Should you decide to install the front-end server and the back-end server on separate machine, make sure the connection between the two is secured. Same goes for database server.

== Before You Open Your Server ==

If you plan to let anyone other than you connect to your server, you have certain obligations under the licenses of the software/data you will be distributing from the file and auth servers.
* '''Cyan content''': the MOULagain EULA still does not provide for you to modify and redistribute the files. So do not put original or modified Cyan files on your file server. You can still have them listed in the <code>.mbm</code> (manifest) files. If someone has an incomplete install they will be forced to get the files from Cyan's file server. That is as yet still the only place from which you're supposed to get those files.
* '''Python code''': you are supplying GPL'd Python code. You must provide a way to acquire that code. If you are using unmodified Python you can link to the [http://assets.openuru.org/cyan/Scripts.zip original source]. If you modify it for any reason, you must make your changes available and tell your users where to get it.
* '''CWE clients:''' if you are providing client executables from a CWE build:
** '''GPL license:''' you probably need to add the GPL license file to the client install. The license is supposed to be conveyed with the executable, and the only sure way to do that is to install it from the file server same as the executable. This means you have to add it to <code>ThinExternal.txt</code> and <code>External.txt</code> and generate the new <code>.mbm</code> files, copying the <code>.mbm files</code> and <code>LICENSE.txt.gz</code> over to the appropriate locations. You probably should also arrange for the license to be available along with <code>UruLauncher.exe</code>.
** '''Client source:''' you must provide a way to acquire the source for your client. The means is supposed to be "equivalent" to the way the executable is acquired. Links are probably sufficient. If you use an unmodified version you should be able to link to the repository (make sure you point to the actual changeset you used). If you modify files for your shard's public keys, status hostname, and/or gatekeeper/auth addresses, you have to additionally provide that source. Note: these are ''public'' keys, so don't worry, you're not giving anything away.
** '''Library credits:''' Unless someone changes the jpeg library again, you need to credit IJG for jpeglib: "This software is based in part on the work of the Independent JPEG Group." Similarly, if the client uses OpenSSL, credit should be given: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/). This product includes cryptographic software written by Eric A. Young (eay@cryptsoft.com). This product includes software written by Tim J. Hudson (tjh@cryptsoft.com)." The easiest may be to add another file doing so to the install. Or, if you are modifying Python for some reason, you could add it to the in-game credits along with all the other licenses (files: <code>xUruCreditsJournalEnglish.py</code>, <code>xUruCreditsJournalFrench.py</code>, <code>xUruCreditsJournalGerman.py</code>, <code>xUruCreditsJournalItalian.py</code>, <code>xUruCreditsJournalSpanish.py</code>). The links or whatever means you use to provide access to the source of the binaries and Python don't have to go into the client install, but they must be somewhere reasonable for your users to find, "equivalent" to installing the software for your shard. I would put links to a copy of the files on your shard's home page or something.

See also [[CyanWorlds.com_Engine/FAQ#What_are_my_open_source_license_.28GPLv3.29_responsibilities_as_a_user.2C_developer_or_server_operator_.28e.g._shard_owner.29.3F | the CWE FAQ]].

Please do not consider this advice the final or complete word on the matter. All the licenses of all the data you use expect you to follow them. So you have to do your due diligence. If you find something obviously missing from this section, please add it!

== Start It Up ==

''Hopefully someone will contribute a nice startup script.''

Now you should be set to run your server. For now, <code>cd</code> to the directory you planned from the start to start the server from (that's <code>''prefix''</code> in the earlier recommendations). Make sure you are su'd to the user you want to run as. '''NOT root!''' Start <code>moss_backend</code> first, then <code>moss</code>. E.g., if you have put the config files in <code>''prefix''/etc</code>, you can just do:
''prefix''/bin/moss_backend
''prefix''/bin/moss
You can instead specify the location of the config file with the <code>-c</code> option. If you've used absolute paths in the config files, you can thus easily run the server from any directory.

=== After Initial Startup ===

To set up AllAgeGlobalSDLNodes, use global_sdl_manager (we have no VaultManager to do it). This program is installed in <code>''prefix''/bin</code>. To aid setup, the <code>support/set_to_moul.txt</code> file can be used to set the global SDL state to a reasonable default (with no sparks) by running something like:
global_sdl_manager game/SDL < set_to_moul.txt
If you want sparks, you can turn them on yourself using this program.

''Note'': this program does NOT work unless the MOSS server has already been started at least once. You might also need to provide your database details to the program; just type <code>global_sdl_manager</code> to get a list of all the appropriate options.

== Create Accounts ==

''Hopefully someone will contribute a script to add users. A CGI script to automatically add users would be neat too.''

Don't forget to create accounts for your users, or it will be difficult to log in... Please just refer directly to [http://foundry.openuru.org/fisheye/browse/MOSS/doc/user-management doc/user-management].

Really short version:
INSERT INTO accounts (name, hash, id, class, visitor)
VALUES ('foo@example.com', '11223344...', uuid(), 'default', false);

Where '11223344' is a SHA-1 password hash.

== See Also ==
{{:MOSS/See Also}}

Please see the following for more information of interest to running a server.
* [[MOSS/Notes]]
* [http://foundry.openuru.org/fisheye/browse/MOSS/doc/running doc/running]

[[Category:MOSS]]

Cyan Content Licensing Proposals

2012-03-02T21:34:52Z

Christian Walther: /* Additional Examples */ Added Bink Video example

== Content Licensing Request ==
=== Introduction ===
Open source is succeeding as the community provides its first tested update to MOULa. We are directly experiencing the next challenge in our progress toward "Open Uru," Open Uru being what is created by code, content, creativity, and participation. The ability to work with and distribute MOULa content under license will determine what we can and cannot do for the future of the Cyan Worlds Engine and MOULa. Working with content will in large part be responsible for increasing the interest and participation of developers, artists, and players to create a broader audience.

We are not attempting a complete statement of the aspirations of the fans with respect to MOULa content licensing. This is an exemplar of specific cases representative of fan efforts to improve MOULa for the community where it is hindered by the absence of a suitable license for the adaptation and distribution of MOULa content. These examples are used as a means to explore the licensing possibilities with Cyan Worlds and to elicit feedback on its own potential difficulties so that we might collectively establish a way forward.

=== Examples ===

* Localization - Cyan Worlds, Myst, Uru, and MOULa all have an international audience. MOULa has an extensible localization system that allows content creators to provide translated text automatically. Unfortunately, many of the dialogs currently in MOULa don't take advantage of this capability and cannot be adapted properly without modifying them. [http://gulp.orangehairedboy.com/ GULP] (formerly the Uru Localization Project) has a database of community-contributed translations in a large number of languages. H'uru has done Unicode development to allow non-US keyboards.

* Derivation - We have textures and limited content (KI and avatars) but they are unlicensed. We cannot distribute work such as scrollbars for the KI for the community to enjoy. We would like to be able to create, serve, test, and contribute work that is consistent with existing MOULa ages for eventual inclusion on MOULa.

* Distribution - Shards cannot serve binary MOULa content files. This raises the barrier against non-technical users faced with manually copying MOULa content to their shard folder as part of the shard install. The technical support load is increased, creating barriers of time, effort, and cost for shard owners as well.

* Improvements - MOULa ages cannot be repaired by fans to function as designed. For example, a player who links to AhnonayCathedral always finds the automatic door closed while at the same time players who are already there see it wide open. The fix requires a change in the .prp file which currently calls the door responders directly instead of calling an intermediate Python file. We need a content license to change, test, and distribute .prp files.

=== Community Needs ===

There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:

* A permissive license to allow copying, translation, and distribution of information available in MOULa. For example, the .loc and .prp files. This would legalize, for example, the translation work already done by the community and enable its distribution and enjoyment.

* Access to 3ds Max source files for GUIs or other useful materials used in MOULa to normalize their use of the provided hooks in the code which they currently do not use, and a license to redistribute at least the compiled output with fixes applied. If that is impossible, an alternative is a license to modify and distribute existing .prp files containing fixes or new features such as translatable GUI items.

=== Questions ===

* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?

* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?

* Are there specific limitations that fans should place on their hopes for content licensing?

* Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?

=== Summary ===

We have presented collaborative concerns about the problems the community seeks to resolve regarding content licensing. We believe Cyan Worlds knows best what solutions are available to it. We hope this will be a successful collaborative path to a general solution.

The representative community members who sign below collaborated to discuss and contribute to this letter of many authors. Thank you for reading and considering this request.

This document's history on the wiki (includes additional detail and examples):

http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals

Full discussion on the OpenUru.org forums:

http://forums.openuru.org/viewtopic.php?f=91&t=635

=== Signatures, Open Source Uru Community ===
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST), Lewis Johnston, GULP, (Address TBI)

[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST), Adam Johnson, GuildOfWriters.org, H'uru, (Address TBI)

[[User:Branan|Branan]] 21:08, 2 February 2012 (MST), Branan Purvine-Riley, H'uru, (Address TBI)

[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST), Christian Walther, independent developer, (Address TBI)

[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST), (Name TBI), GuildOfMessengers.com

[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST), Ian M. McIntosh, OpenUru.org, (Address TBI)

[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST), (Name TBI), H'uru

[[User:Malfhok|Malfhok]] 05:14, 4 February 2012 (MST), (Name TBI), an explorer, (Address TBI)

[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST), Joseph Davies, H'uru, (Address TBI)

[[User:Marten|Marten]] 09:44, 5 February 2012 (MST), John Johns, The Great Tree, Guild of Messengers, Washougal, WA

[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET), (Name TBI)

[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST), Chloe Rhodes, TheDeepCity.com, (Address TBI)

[[User:JWPlatt|JWPlatt]] 10:51, 15 February 2012 (EST), Jonathan W. Platt, OpenUru.org, (Address TBI)

[[User:rarified|rarified]] 14:30, 15 February 2012 (MST), Paul Richards, OpenUru.org, (Address TBI)

== Additional Information ==

=== Technical Information on the Localization Example ===
The .loc files are XML files containing translations for all textual items in Uru. GULP (http://rel.to/gulp) already has an extensive library of translations and a system to export that database to Uru-ready .loc files. Not all of Uru uses these however, as some values are hard-coded in Python scripts or the PRPs themselves, but this can be converted as the GUI items have the ability to reference the XML paths directly. Much of this Python code references the GUI items by TagIDs, which are arbitrary unique numbers used to refer to the resource. This is messy, as it must be updated when the GUI is updated and can otherwise become out of sync; it is also problematic in the current data set as not all translatable GUI items have been assigned TagIDs, meaning they must be found (if at all) by very fragile code. There is also an embedded text field in these items, which currently contains only the English text. Fortunately, these items support a self-describing LocalizationPath which automatically informs the Plasma engine's LocalizationManager which string to use, allowing localization to be handled cleanly and consistently. All of these items are a part of the data and without a license to modify and distribute the PRPs, we cannot continue the efforts to localize Uru outside of using hacks and shims to the existing elegant but under-utilized engine.

As an additional benefit to Cyan: the changes made under the proposed 3ds Max source licensing could be relatively easy for Cyan to integrate back into their own assets without affecting current functionality. This would be impossible if only binary changes are allowed to the exported PRPs rather than the .max sources, and it allows Cyan to take advantage of the localization code changes in the engine once it reaches maturity in the community testing with very little friction.

An extra note about the alternative suggestion which only allows modification of PRPs – The reason this is inferior, aside from the obvious, is that while it would allow the immediate goal of activating the built-in localization, minor bugs are to be expected in the text flow and sizing in the UI when displaying languages other than the one for which it was designed. These will be extremely difficult to fix under the limited alternative solution and should be far simpler with access to the original 3D Studio Max source files.

=== Additional Examples ===
==== Bink Video Replacement ====
All video files (Cyan logo and Yeesha intro) are in Bink format. The Bink SDK is costly and therefore unavailable to most open source developers, so typical open-source builds are unable to play those videos. They are important to the game, though. We need a license to transcode and redistribute those videos in other, more accessible formats.

Access to high-quality source material in addition would allow us to do it in better quality than by transcoding the already compressed Bink files.

==== Collider Fixes for PhysX 2.6.4 ====
MOULa is built with the PhysX 2.6.0 SDK, which is no longer available from NVIDIA. The oldest version still available for the community to build CWE with is 2.6.4. Unfortunately, some of Cyan’s content relies on very specific behaviors of PhysX 2.6.0 and no longer works properly with 2.6.4. As long as we cannot fix these issues in the content files, we are either unable to fix them at all, or have to build inferior workarounds into the code, such as this recent commit:

[https://github.com/H-uru/Plasma/commit/529ff7982c53410616c62ffb98320e2dd2fd93f4 H-uru/Plasma@529ff79 on GitHub]
<blockquote>'''Band-aid for poorly modelled stairs''' 
Looks like the Cyan modellers didn't extend the stair ramps all the way
down in some places. To compensate, we can now take higher steps but can't
walk on slopes quite as steep as before. I think this should balance out
nicely.</blockquote>

''More details by Adam Johnson (Hoikas):''

What I can do is give you details on some content issues that I’ve run into in fixing the game to work better with newer versions of PhysX. I will provide some screenshots with the physical proxies enabled. This will show us the meshes that PhysX is using to determine kickable and collision behaviors. Colliders will appear as yellow, detector regions are blue, and kickables are red. ''Click on images for full size.''

[http://assets.openuru.org/wiki/general/stairs.jpg http://assets.openuru.org/wiki/general/stairs_tn.jpg]

This is an example of the “stairs” issue mentioned above. In MOULa, this stairwell “just works” however in open source builds with PhysX 2.6.4, it does not. You’ll note that the ramp over the stairs is a good foot above the level ground. This causes the avatar to get stuck on the 90 degree angle between the two planes—you have to actually jump over that angle before you can start running up the stairs. Stairwells that “just work” on open source builds have ramps that extend all the way down to the ground plane.

That particular stairwell is in Er’cana (that age has several that are bad). There are others in Ae’gura and one in Kirel according to my limited testing.

[http://assets.openuru.org/wiki/general/rocks.jpg http://assets.openuru.org/wiki/general/rocks_tn.jpg]

This is somewhat related in that we have box-shaped colliders creating a 90 degree angle with the ground. These are the rocks at the Ferry Terminal in Ae’gura… You can’t climb over them because they are too high. I could not justify to myself making the step fudge factor high enough to account for these colliders because as we increase the step size, we make it even harder to kick small kickables (firemarbles, objects in the Teledahn slave cave).

[http://assets.openuru.org/wiki/general/cones.jpg http://assets.openuru.org/wiki/general/cones_tn.jpg]

I have done extensive work on the kickables and fixed the bugs that caused them to shoot off into space and not move at all—to the extent that all of the random objects in Teledahn work nearly as well in PotS. Unfortunately, it seems that someone decided to mess up the cone collision mesh. As a result, the cones do some sort of possessed somersault in front of you as the avatar kicks it. Also, the sliding sounds are too loud (about 3x louder than the impact sounds), so pushing a cone makes a really annoying noise in my development branch… The other physicals sound good though.

''TL;DR: Collision meshes are broken, we must fix them!''

==== KI Coordinates in Great Zero Courtyard are Backward ====
Issue brought up recently on the MOUL forum that should be easy to fix given a content license:
http://mystonline.com/forums/viewtopic.php?t=25431

=== License Suggestions ===
We tried to come up with suggestions for licenses in order to simplify the burden on Cyan, but as the [http://forums.openuru.org/viewtopic.php?f=91&t=635 OU Content Licensing thread] proves there are many viable options and they all address different needs. Unfortunately, in order to find where that spot of compromise is we will need feedback from Cyan on this point. We ask that Cyan, should they wish to consider this request, respond with their concerns and needs first. At that point tangible suggestions can be made regarding the specifics and the proposal can move forward should they be agreeable.

For the .loc files in particular we would suggest terms which preserve Cyan’s ownership of the text (some of which, being canon from the Myst universe, has inherent value to them), while allowing edits and distribution by the community. A disclaimer stating that Cyan is only responsible for the original English text may also be desirable.

Cyan Content Licensing Proposals

2012-02-19T11:57:11Z

Christian Walther: /* Collider Fixes for PhysX 2.6.4 */ Inserted final images

== Content Licensing Request ==
=== Introduction ===
Open source is succeeding as the community provides its first tested update to MOULa. We are directly experiencing the next challenge in our progress toward "Open Uru," Open Uru being what is created by code, content, creativity, and participation. The ability to work with and distribute MOULa content under license will determine what we can and cannot do for the future of the Cyan Worlds Engine and MOULa. Working with content will in large part be responsible for increasing the interest and participation of developers, artists, and players to create a broader audience.

We are not attempting a complete statement of the aspirations of the fans with respect to MOULa content licensing. This is an exemplar of specific cases representative of fan efforts to improve MOULa for the community where it is hindered by the absence of a suitable license for the adaptation and distribution of MOULa content. These examples are used as a means to explore the licensing possibilities with Cyan Worlds and to elicit feedback on its own potential difficulties so that we might collectively establish a way forward.

=== Examples ===

* Localization - Cyan Worlds, Myst, Uru, and MOULa all have an international audience. MOULa has an extensible localization system that allows content creators to provide translated text automatically. Unfortunately, many of the dialogs currently in MOULa don't take advantage of this capability and cannot be adapted properly without modifying them. GULP (formerly the Uru Localization Project) has a database of community-contributed translations in a large number of languages. H'uru has done Unicode development to allow non-US keyboards.

* Derivation - We have textures and limited content (KI and avatars) but they are unlicensed. We cannot distribute work such as scrollbars for the KI for the community to enjoy. We would like to be able to create, serve, test, and contribute work that is consistent with existing MOULa ages for eventual inclusion on MOULa.

* Distribution - Shards cannot serve binary MOULa content files. This raises the barrier against non-technical users faced with manually copying MOULa content to their shard folder as part of the shard install. The technical support load is increased, creating barriers of time, effort, and cost for shard owners as well.

* Improvements - MOULa ages cannot be repaired by fans to function as designed. For example, a player who links to AhnonayCathedral always finds the automatic door closed while at the same time players who are already there see it wide open. The fix requires a change in the .prp file which currently calls the door responders directly instead of calling an intermediate Python file. We need a content license to change, test, and distribute .prp files.

=== Community Needs ===

There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:

* A permissive license to allow copying, translation, and distribution of information available in MOULa. For example, the .loc and .prp files. This would legalize, for example, the translation work already done by the community and enable its distribution and enjoyment.

* Access to 3ds Max source files for GUIs or other useful materials used in MOULa to normalize their use of the provided hooks in the code which they currently do not use, and a license to redistribute at least the compiled output with fixes applied. If that is impossible, an alternative is a license to modify and distribute existing .prp files containing fixes or new features such as translatable GUI items.

=== Questions ===

* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?

* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?

* Are there specific limitations that fans should place on their hopes for content licensing?

* Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?

=== Summary ===

We have presented collaborative concerns about the problems the community seeks to resolve regarding content licensing. We believe Cyan Worlds knows best what solutions are available to it. We hope this will be a successful collaborative path to a general solution.

The representative community members who sign below collaborated to discuss and contribute to this letter of many authors. Thank you for reading and considering this request.

This document's history on the wiki: http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals

Full discussion on the OpenUru.org forums: http://forums.openuru.org/viewtopic.php?f=91&t=635

=== Signatures, Open Source Uru Community ===
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST), Lewis Johnston, GULP, (Address TBI)

[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST)

[[User:Branan|Branan]] 21:08, 2 February 2012 (MST)

[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST), Christian Walther, independent developer, (Address TBI)

[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST), (Name TBI), GuildOfMessengers.com

[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST), Ian M. McIntosh, OpenUru.org, (Address TBI)

[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST)

[[User:Malfhok|Malfhok]] 05:14, 4 February 2012 (MST), (Name TBI), an explorer, (Address TBI)

[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST)

[[User:Marten|Marten]] 09:44, 5 February 2012 (MST)

[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET), (Name TBI)

[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST), Chloe Rhodes, TheDeepCity.com, (Address TBI)

[[User:JWPlatt|JWPlatt]] 10:51, 15 February 2012 (EST), Jonathan W. Platt, OpenUru.org, (Address TBI)

[[User:rarified|rarified]] 14:30, 15 February 2012 (MST), Paul Richards, OpenUru.org, (Address TBI)

== Additional Information ==

=== Technical Information on the Localization Example ===
The .loc files are XML files containing translations for all textual items in Uru. GULP (http://rel.to/gulp) already has an extensive library of translations and a system to export that database to Uru-ready .loc files. Not all of Uru uses these however, as some values are hard-coded in Python scripts or the PRPs themselves, but this can be converted as the GUI items have the ability to reference the XML paths directly. Much of this Python code references the GUI items by TagIDs, which are arbitrary unique numbers used to refer to the resource. This is messy, as it must be updated when the GUI is updated and can otherwise become out of sync; it is also problematic in the current data set as not all translatable GUI items have been assigned TagIDs, meaning they must be found (if at all) by very fragile code. There is also an embedded text field in these items, which currently contains only the English text. Fortunately, these items support a self-describing LocalizationPath which automatically informs the Plasma engine's LocalizationManager which string to use, allowing localization to be handled cleanly and consistently. All of these items are a part of the data and without a license to modify and distribute the PRPs, we cannot continue the efforts to localize Uru outside of using hacks and shims to the existing elegant but under-utilized engine.

As an additional benefit to Cyan: the changes made under the proposed 3ds Max source licensing could be relatively easy for Cyan to integrate back into their own assets without affecting current functionality. This would be impossible if only binary changes are allowed to the exported PRPs rather than the .max sources, and it allows Cyan to take advantage of the localization code changes in the engine once it reaches maturity in the community testing with very little friction.

An extra note about the alternative suggestion which only allows modification of PRPs – The reason this is inferior, aside from the obvious, is that while it would allow the immediate goal of activating the built-in localization, minor bugs are to be expected in the text flow and sizing in the UI when displaying languages other than the one for which it was designed. These will be extremely difficult to fix under the limited alternative solution and should be far simpler with access to the original 3D Studio Max source files.

=== Additional Examples ===
==== Collider Fixes for PhysX 2.6.4 ====
MOULa is built with the PhysX 2.6.0 SDK, which is no longer available from NVIDIA. The oldest version still available for the community to build CWE with is 2.6.4. Unfortunately, some of Cyan’s content relies on very specific behaviors of PhysX 2.6.0 and no longer works properly with 2.6.4. As long as we cannot fix these issues in the content files, we are either unable to fix them at all, or have to build inferior workarounds into the code, such as this recent commit:

[https://github.com/H-uru/Plasma/commit/529ff7982c53410616c62ffb98320e2dd2fd93f4 H-uru/Plasma@529ff79 on GitHub]
<blockquote>'''Band-aid for poorly modelled stairs''' 
Looks like the Cyan modellers didn't extend the stair ramps all the way
down in some places. To compensate, we can now take higher steps but can't
walk on slopes quite as steep as before. I think this should balance out
nicely.</blockquote>

''More details by Adam Johnson (Hoikas):''

What I can do is give you details on some content issues that I’ve run into in fixing the game to work better with newer versions of PhysX. I will provide some screenshots with the physical proxies enabled. This will show us the meshes that PhysX is using to determine kickable and collision behaviors. Colliders will appear as yellow, detector regions are blue, and kickables are red. ''Click on images for full size.''

[http://assets.openuru.org/wiki/general/stairs.jpg http://assets.openuru.org/wiki/general/stairs_tn.jpg]

This is an example of the “stairs” issue mentioned above. In MOULa, this stairwell “just works” however in open source builds with PhysX 2.6.4, it does not. You’ll note that the ramp over the stairs is a good foot above the level ground. This causes the avatar to get stuck on the 90 degree angle between the two planes—you have to actually jump over that angle before you can start running up the stairs. Stairwells that “just work” on open source builds have ramps that extend all the way down to the ground plane.

That particular stairwell is in Er’cana (that age has several that are bad). There are others in Ae’gura and one in Kirel according to my limited testing.

[http://assets.openuru.org/wiki/general/rocks.jpg http://assets.openuru.org/wiki/general/rocks_tn.jpg]

This is somewhat related in that we have box-shaped colliders creating a 90 degree angle with the ground. These are the rocks at the Ferry Terminal in Ae’gura… You can’t climb over them because they are too high. I could not justify to myself making the step fudge factor high enough to account for these colliders because as we increase the step size, we make it even harder to kick small kickables (firemarbles, objects in the Teledahn slave cave).

[http://assets.openuru.org/wiki/general/cones.jpg http://assets.openuru.org/wiki/general/cones_tn.jpg]

I have done extensive work on the kickables and fixed the bugs that caused them to shoot off into space and not move at all—to the extent that all of the random objects in Teledahn work nearly as well in PotS. Unfortunately, it seems that someone decided to mess up the cone collision mesh. As a result, the cones do some sort of possessed somersault in front of you as the avatar kicks it. Also, the sliding sounds are too loud (about 3x louder than the impact sounds), so pushing a cone makes a really annoying noise in my development branch… The other physicals sound good though.

''TL;DR: Collision meshes are broken, we must fix them!''

==== KI Coordinates in Great Zero Courtyard are Backward ====
Issue brought up recently on the MOUL forum that should be easy to fix given a content license:
http://mystonline.com/forums/viewtopic.php?t=25431

=== License Suggestions ===
We tried to come up with suggestions for licenses in order to simplify the burden on Cyan, but as the [http://forums.openuru.org/viewtopic.php?f=91&t=635 OU Content Licensing thread] proves there are many viable options and they all address different needs. Unfortunately, in order to find where that spot of compromise is we will need feedback from Cyan on this point. We ask that Cyan, should they wish to consider this request, respond with their concerns and needs first. At that point tangible suggestions can be made regarding the specifics and the proposal can move forward should they be agreeable.

For the .loc files in particular we would suggest terms which preserve Cyan’s ownership of the text (some of which, being canon from the Myst universe, has inherent value to them), while allowing edits and distribution by the community. A disclaimer stating that Cyan is only responsible for the original English text may also be desirable.

Cyan Content Licensing Proposals

2012-02-19T11:22:45Z

Christian Walther: /* Additional Examples */ Second additional example (to justify the plural :)) from Branan: http://forums.openuru.org/viewtopic.php?p=5624#p5624

== Content Licensing Request ==
=== Introduction ===
Open source is succeeding as the community provides its first tested update to MOULa. We are directly experiencing the next challenge in our progress toward "Open Uru," Open Uru being what is created by code, content, creativity, and participation. The ability to work with and distribute MOULa content under license will determine what we can and cannot do for the future of the Cyan Worlds Engine and MOULa. Working with content will in large part be responsible for increasing the interest and participation of developers, artists, and players to create a broader audience.

We are not attempting a complete statement of the aspirations of the fans with respect to MOULa content licensing. This is an exemplar of specific cases representative of fan efforts to improve MOULa for the community where it is hindered by the absence of a suitable license for the adaptation and distribution of MOULa content. These examples are used as a means to explore the licensing possibilities with Cyan Worlds and to elicit feedback on its own potential difficulties so that we might collectively establish a way forward.

=== Examples ===

* Localization - Cyan Worlds, Myst, Uru, and MOULa all have an international audience. MOULa has an extensible localization system that allows content creators to provide translated text automatically. Unfortunately, many of the dialogs currently in MOULa don't take advantage of this capability and cannot be adapted properly without modifying them. GULP (formerly the Uru Localization Project) has a database of community-contributed translations in a large number of languages. H'uru has done Unicode development to allow non-US keyboards.

* Derivation - We have textures and limited content (KI and avatars) but they are unlicensed. We cannot distribute work such as scrollbars for the KI for the community to enjoy. We would like to be able to create, serve, test, and contribute work that is consistent with existing MOULa ages for eventual inclusion on MOULa.

* Distribution - Shards cannot serve binary MOULa content files. This raises the barrier against non-technical users faced with manually copying MOULa content to their shard folder as part of the shard install. The technical support load is increased, creating barriers of time, effort, and cost for shard owners as well.

* Improvements - MOULa ages cannot be repaired by fans to function as designed. For example, a player who links to AhnonayCathedral always finds the automatic door closed while at the same time players who are already there see it wide open. The fix requires a change in the .prp file which currently calls the door responders directly instead of calling an intermediate Python file. We need a content license to change, test, and distribute .prp files.

=== Community Needs ===

There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:

* A permissive license to allow copying, translation, and distribution of information available in MOULa. For example, the .loc and .prp files. This would legalize, for example, the translation work already done by the community and enable its distribution and enjoyment.

* Access to 3ds Max source files for GUIs or other useful materials used in MOULa to normalize their use of the provided hooks in the code which they currently do not use, and a license to redistribute at least the compiled output with fixes applied. If that is impossible, an alternative is a license to modify and distribute existing .prp files containing fixes or new features such as translatable GUI items.

=== Questions ===

* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?

* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?

* Are there specific limitations that fans should place on their hopes for content licensing?

* Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?

=== Summary ===

We have presented collaborative concerns about the problems the community seeks to resolve regarding content licensing. We believe Cyan Worlds knows best what solutions are available to it. We hope this will be a successful collaborative path to a general solution.

The representative community members who sign below collaborated to discuss and contribute to this letter of many authors. Thank you for reading and considering this request.

This document's history on the wiki: http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals

Full discussion on the OpenUru.org forums: http://forums.openuru.org/viewtopic.php?f=91&t=635

=== Signatures, Open Source Uru Community ===
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST), Lewis Johnston, GULP, (Address TBI)

[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST)

[[User:Branan|Branan]] 21:08, 2 February 2012 (MST)

[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST), Christian Walther, independent developer, (Address TBI)

[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST), (Name TBI), GuildOfMessengers.com

[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST), Ian M. McIntosh, OpenUru.org, (Address TBI)

[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST)

[[User:Malfhok|Malfhok]] 05:14, 4 February 2012 (MST), (Name TBI), an explorer, (Address TBI)

[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST)

[[User:Marten|Marten]] 09:44, 5 February 2012 (MST)

[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET), (Name TBI)

[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST), Chloe Rhodes, TheDeepCity.com, (Address TBI)

[[User:JWPlatt|JWPlatt]] 10:51, 15 February 2012 (EST), Jonathan W. Platt, OpenUru.org, (Address TBI)

[[User:rarified|rarified]] 14:30, 15 February 2012 (MST), Paul Richards, OpenUru.org, (Address TBI)

== Additional Information ==

=== Technical Information on the Localization Example ===
The .loc files are XML files containing translations for all textual items in Uru. GULP (http://rel.to/gulp) already has an extensive library of translations and a system to export that database to Uru-ready .loc files. Not all of Uru uses these however, as some values are hard-coded in Python scripts or the PRPs themselves, but this can be converted as the GUI items have the ability to reference the XML paths directly. Much of this Python code references the GUI items by TagIDs, which are arbitrary unique numbers used to refer to the resource. This is messy, as it must be updated when the GUI is updated and can otherwise become out of sync; it is also problematic in the current data set as not all translatable GUI items have been assigned TagIDs, meaning they must be found (if at all) by very fragile code. There is also an embedded text field in these items, which currently contains only the English text. Fortunately, these items support a self-describing LocalizationPath which automatically informs the Plasma engine's LocalizationManager which string to use, allowing localization to be handled cleanly and consistently. All of these items are a part of the data and without a license to modify and distribute the PRPs, we cannot continue the efforts to localize Uru outside of using hacks and shims to the existing elegant but under-utilized engine.

As an additional benefit to Cyan: the changes made under the proposed 3ds Max source licensing could be relatively easy for Cyan to integrate back into their own assets without affecting current functionality. This would be impossible if only binary changes are allowed to the exported PRPs rather than the .max sources, and it allows Cyan to take advantage of the localization code changes in the engine once it reaches maturity in the community testing with very little friction.

An extra note about the alternative suggestion which only allows modification of PRPs – The reason this is inferior, aside from the obvious, is that while it would allow the immediate goal of activating the built-in localization, minor bugs are to be expected in the text flow and sizing in the UI when displaying languages other than the one for which it was designed. These will be extremely difficult to fix under the limited alternative solution and should be far simpler with access to the original 3D Studio Max source files.

=== Additional Examples ===
==== Collider Fixes for PhysX 2.6.4 ====
MOULa is built with the PhysX 2.6.0 SDK, which is no longer available from NVIDIA. The oldest version still available for the community to build CWE with is 2.6.4. Unfortunately, some of Cyan’s content relies on very specific behaviors of PhysX 2.6.0 and no longer works properly with 2.6.4. As long as we cannot fix these issues in the content files, we are either unable to fix them at all, or have to build inferior workarounds into the code, such as this recent commit:

[https://github.com/H-uru/Plasma/commit/529ff7982c53410616c62ffb98320e2dd2fd93f4 H-uru/Plasma@529ff79 on GitHub]
<blockquote>'''Band-aid for poorly modelled stairs''' 
Looks like the Cyan modellers didn't extend the stair ramps all the way
down in some places. To compensate, we can now take higher steps but can't
walk on slopes quite as steep as before. I think this should balance out
nicely.</blockquote>

''More details by Adam Johnson (Hoikas):''

What I can do is give you details on some content issues that I’ve run into in fixing the game to work better with newer versions of PhysX. I will provide some screenshots with the physical proxies enabled. This will show us the meshes that PhysX is using to determine kickable and collision behaviors. Colliders will appear as yellow, detector regions are blue, and kickables are red. ''Click on images for full size.''

[http://dl.dropbox.com/u/20333864/stairs.jpg http://f.cl.ly/items/0u3y0L0m403P2a2j022D/stairs.jpg]

This is an example of the “stairs” issue mentioned above. In MOULa, this stairwell “just works” however in open source builds with PhysX 2.6.4, it does not. You’ll note that the ramp over the stairs is a good foot above the level ground. This causes the avatar to get stuck on the 90 degree angle between the two planes—you have to actually jump over that angle before you can start running up the stairs. Stairwells that “just work” on open source builds have ramps that extend all the way down to the ground plane.

That particular stairwell is in Er’cana (that age has several that are bad). There are others in Ae’gura and one in Kirel according to my limited testing.

[http://dl.dropbox.com/u/20333864/rocks.png http://f.cl.ly/items/0P3J3W2Y1f302I3O2B3N/rocks.jpg]

This is somewhat related in that we have box-shaped colliders creating a 90 degree angle with the ground. These are the rocks at the Ferry Terminal in Ae’gura… You can’t climb over them because they are too high. I could not justify to myself making the step fudge factor high enough to account for these colliders because as we increase the step size, we make it even harder to kick small kickables (firemarbles, objects in the Teledahn slave cave).

[http://dl.dropbox.com/u/20333864/cones.jpg http://f.cl.ly/items/2L2k1o3g1m0I1A1b2Q3I/cones.jpg]

I have done extensive work on the kickables and fixed the bugs that caused them to shoot off into space and not move at all—to the extent that all of the random objects in Teledahn work nearly as well in PotS. Unfortunately, it seems that someone decided to mess up the cone collision mesh. As a result, the cones do some sort of possessed somersault in front of you as the avatar kicks it. Also, the sliding sounds are too loud (about 3x louder than the impact sounds), so pushing a cone makes a really annoying noise in my development branch… The other physicals sound good though.

''TL;DR: Collision meshes are broken, we must fix them!''

==== KI Coordinates in Great Zero Courtyard are Backward ====
Issue brought up recently on the MOUL forum that should be easy to fix given a content license:
http://mystonline.com/forums/viewtopic.php?t=25431

=== License Suggestions ===
We tried to come up with suggestions for licenses in order to simplify the burden on Cyan, but as the [http://forums.openuru.org/viewtopic.php?f=91&t=635 OU Content Licensing thread] proves there are many viable options and they all address different needs. Unfortunately, in order to find where that spot of compromise is we will need feedback from Cyan on this point. We ask that Cyan, should they wish to consider this request, respond with their concerns and needs first. At that point tangible suggestions can be made regarding the specifics and the proposal can move forward should they be agreeable.

For the .loc files in particular we would suggest terms which preserve Cyan’s ownership of the text (some of which, being canon from the Myst universe, has inherent value to them), while allowing edits and distribution by the community. A disclaimer stating that Cyan is only responsible for the original English text may also be desirable.

Cyan Content Licensing Proposals

2012-02-19T10:37:36Z

Christian Walther: /* Additional Information */ Add additional example by Hoikas from http://forums.openuru.org/viewtopic.php?p=5592#p5592. Images to be uploaded to assets.openuru.org.

== Content Licensing Request ==
=== Introduction ===
Open source is succeeding as the community provides its first tested update to MOULa. We are directly experiencing the next challenge in our progress toward "Open Uru," Open Uru being what is created by code, content, creativity, and participation. The ability to work with and distribute MOULa content under license will determine what we can and cannot do for the future of the Cyan Worlds Engine and MOULa. Working with content will in large part be responsible for increasing the interest and participation of developers, artists, and players to create a broader audience.

We are not attempting a complete statement of the aspirations of the fans with respect to MOULa content licensing. This is an exemplar of specific cases representative of fan efforts to improve MOULa for the community where it is hindered by the absence of a suitable license for the adaptation and distribution of MOULa content. These examples are used as a means to explore the licensing possibilities with Cyan Worlds and to elicit feedback on its own potential difficulties so that we might collectively establish a way forward.

=== Examples ===

* Localization - Cyan Worlds, Myst, Uru, and MOULa all have an international audience. MOULa has an extensible localization system that allows content creators to provide translated text automatically. Unfortunately, many of the dialogs currently in MOULa don't take advantage of this capability and cannot be adapted properly without modifying them. GULP (formerly the Uru Localization Project) has a database of community-contributed translations in a large number of languages. H'uru has done Unicode development to allow non-US keyboards.

* Derivation - We have textures and limited content (KI and avatars) but they are unlicensed. We cannot distribute work such as scrollbars for the KI for the community to enjoy. We would like to be able to create, serve, test, and contribute work that is consistent with existing MOULa ages for eventual inclusion on MOULa.

* Distribution - Shards cannot serve binary MOULa content files. This raises the barrier against non-technical users faced with manually copying MOULa content to their shard folder as part of the shard install. The technical support load is increased, creating barriers of time, effort, and cost for shard owners as well.

* Improvements - MOULa ages cannot be repaired by fans to function as designed. For example, a player who links to AhnonayCathedral always finds the automatic door closed while at the same time players who are already there see it wide open. The fix requires a change in the .prp file which currently calls the door responders directly instead of calling an intermediate Python file. We need a content license to change, test, and distribute .prp files.

=== Community Needs ===

There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:

* A permissive license to allow copying, translation, and distribution of information available in MOULa. For example, the .loc and .prp files. This would legalize, for example, the translation work already done by the community and enable its distribution and enjoyment.

* Access to 3ds Max source files for GUIs or other useful materials used in MOULa to normalize their use of the provided hooks in the code which they currently do not use, and a license to redistribute at least the compiled output with fixes applied. If that is impossible, an alternative is a license to modify and distribute existing .prp files containing fixes or new features such as translatable GUI items.

=== Questions ===

* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?

* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?

* Are there specific limitations that fans should place on their hopes for content licensing?

* Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?

=== Summary ===

We have presented collaborative concerns about the problems the community seeks to resolve regarding content licensing. We believe Cyan Worlds knows best what solutions are available to it. We hope this will be a successful collaborative path to a general solution.

The representative community members who sign below collaborated to discuss and contribute to this letter of many authors. Thank you for reading and considering this request.

This document's history on the wiki: http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals

Full discussion on the OpenUru.org forums: http://forums.openuru.org/viewtopic.php?f=91&t=635

=== Signatures, Open Source Uru Community ===
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST), Lewis Johnston, GULP, (Address TBI)

[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST)

[[User:Branan|Branan]] 21:08, 2 February 2012 (MST)

[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST), Christian Walther, independent developer, (Address TBI)

[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST), (Name TBI), GuildOfMessengers.com

[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST), Ian M. McIntosh, OpenUru.org, (Address TBI)

[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST)

[[User:Malfhok|Malfhok]] 05:14, 4 February 2012 (MST), (Name TBI), an explorer, (Address TBI)

[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST)

[[User:Marten|Marten]] 09:44, 5 February 2012 (MST)

[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET), (Name TBI)

[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST), Chloe Rhodes, TheDeepCity.com, (Address TBI)

[[User:JWPlatt|JWPlatt]] 10:51, 15 February 2012 (EST), Jonathan W. Platt, OpenUru.org, (Address TBI)

[[User:rarified|rarified]] 14:30, 15 February 2012 (MST), Paul Richards, OpenUru.org, (Address TBI)

== Additional Information ==

=== Technical Information on the Localization Example ===
The .loc files are XML files containing translations for all textual items in Uru. GULP (http://rel.to/gulp) already has an extensive library of translations and a system to export that database to Uru-ready .loc files. Not all of Uru uses these however, as some values are hard-coded in Python scripts or the PRPs themselves, but this can be converted as the GUI items have the ability to reference the XML paths directly. Much of this Python code references the GUI items by TagIDs, which are arbitrary unique numbers used to refer to the resource. This is messy, as it must be updated when the GUI is updated and can otherwise become out of sync; it is also problematic in the current data set as not all translatable GUI items have been assigned TagIDs, meaning they must be found (if at all) by very fragile code. There is also an embedded text field in these items, which currently contains only the English text. Fortunately, these items support a self-describing LocalizationPath which automatically informs the Plasma engine's LocalizationManager which string to use, allowing localization to be handled cleanly and consistently. All of these items are a part of the data and without a license to modify and distribute the PRPs, we cannot continue the efforts to localize Uru outside of using hacks and shims to the existing elegant but under-utilized engine.

As an additional benefit to Cyan: the changes made under the proposed 3ds Max source licensing could be relatively easy for Cyan to integrate back into their own assets without affecting current functionality. This would be impossible if only binary changes are allowed to the exported PRPs rather than the .max sources, and it allows Cyan to take advantage of the localization code changes in the engine once it reaches maturity in the community testing with very little friction.

An extra note about the alternative suggestion which only allows modification of PRPs – The reason this is inferior, aside from the obvious, is that while it would allow the immediate goal of activating the built-in localization, minor bugs are to be expected in the text flow and sizing in the UI when displaying languages other than the one for which it was designed. These will be extremely difficult to fix under the limited alternative solution and should be far simpler with access to the original 3D Studio Max source files.

=== Additional Examples ===
==== Collider Fixes for PhysX 2.6.4 ====
MOULa is built with the PhysX 2.6.0 SDK, which is no longer available from NVIDIA. The oldest version still available for the community to build CWE with is 2.6.4. Unfortunately, some of Cyan’s content relies on very specific behaviors of PhysX 2.6.0 and no longer works properly with 2.6.4. As long as we cannot fix these issues in the content files, we are either unable to fix them at all, or have to build inferior workarounds into the code, such as this recent commit:

[https://github.com/H-uru/Plasma/commit/529ff7982c53410616c62ffb98320e2dd2fd93f4 H-uru/Plasma@529ff79 on GitHub]
<blockquote>'''Band-aid for poorly modelled stairs''' 
Looks like the Cyan modellers didn't extend the stair ramps all the way
down in some places. To compensate, we can now take higher steps but can't
walk on slopes quite as steep as before. I think this should balance out
nicely.</blockquote>

''More details by Adam Johnson (Hoikas):''

What I can do is give you details on some content issues that I’ve run into in fixing the game to work better with newer versions of PhysX. I will provide some screenshots with the physical proxies enabled. This will show us the meshes that PhysX is using to determine kickable and collision behaviors. Colliders will appear as yellow, detector regions are blue, and kickables are red. ''Click on images for full size.''

[http://dl.dropbox.com/u/20333864/stairs.jpg http://f.cl.ly/items/0u3y0L0m403P2a2j022D/stairs.jpg]

This is an example of the “stairs” issue mentioned above. In MOULa, this stairwell “just works” however in open source builds with PhysX 2.6.4, it does not. You’ll note that the ramp over the stairs is a good foot above the level ground. This causes the avatar to get stuck on the 90 degree angle between the two planes—you have to actually jump over that angle before you can start running up the stairs. Stairwells that “just work” on open source builds have ramps that extend all the way down to the ground plane.

That particular stairwell is in Er’cana (that age has several that are bad). There are others in Ae’gura and one in Kirel according to my limited testing.

[http://dl.dropbox.com/u/20333864/rocks.png http://f.cl.ly/items/0P3J3W2Y1f302I3O2B3N/rocks.jpg]

This is somewhat related in that we have box-shaped colliders creating a 90 degree angle with the ground. These are the rocks at the Ferry Terminal in Ae’gura… You can’t climb over them because they are too high. I could not justify to myself making the step fudge factor high enough to account for these colliders because as we increase the step size, we make it even harder to kick small kickables (firemarbles, objects in the Teledahn slave cave).

[http://dl.dropbox.com/u/20333864/cones.jpg http://f.cl.ly/items/2L2k1o3g1m0I1A1b2Q3I/cones.jpg]

I have done extensive work on the kickables and fixed the bugs that caused them to shoot off into space and not move at all—to the extent that all of the random objects in Teledahn work nearly as well in PotS. Unfortunately, it seems that someone decided to mess up the cone collision mesh. As a result, the cones do some sort of possessed somersault in front of you as the avatar kicks it. Also, the sliding sounds are too loud (about 3x louder than the impact sounds), so pushing a cone makes a really annoying noise in my development branch… The other physicals sound good though.

''TL;DR: Collision meshes are broken, we must fix them!''

=== License Suggestions ===
We tried to come up with suggestions for licenses in order to simplify the burden on Cyan, but as the [http://forums.openuru.org/viewtopic.php?f=91&t=635 OU Content Licensing thread] proves there are many viable options and they all address different needs. Unfortunately, in order to find where that spot of compromise is we will need feedback from Cyan on this point. We ask that Cyan, should they wish to consider this request, respond with their concerns and needs first. At that point tangible suggestions can be made regarding the specifics and the proposal can move forward should they be agreeable.

For the .loc files in particular we would suggest terms which preserve Cyan’s ownership of the text (some of which, being canon from the Myst universe, has inherent value to them), while allowing edits and distribution by the community. A disclaimer stating that Cyan is only responsible for the original English text may also be desirable.

Cyan Content Licensing Proposals

2012-02-19T09:46:27Z

Christian Walther: /* Additional Information */ Better structure and adaptations to the current request, changed 1st person singular point of view

Cyan Content Licensing Proposals

2012-02-16T21:20:32Z

Christian Walther: /* Signatures, Open Source Uru Community */ completed my signature

Cyan Content Licensing Proposals

2012-02-03T12:28:34Z

Christian Walther: /* Signatures */ add my signature

== Localization Licensing Request ==
=== Problem Statement ===
==== Preface ====
Please note that this is not a complete statement of the aspirations of the fan developers in respect of Uru/MOUL content licensing; rather it is an exemplar of a specifc case where fan developer efforts to improve Uru/MOUL for the community are hindered by the absence of a suitable license for the adaptation and distribution of Cyan's content. This example is used a means to explore the licensing possibilities with Cyan and to elicit feedback on potential difficulties so that we might collectively establish a way forward.

==== Introduction ====
Uru has an international audience, and an extensible Localization system which allows content creators to provide translated text to be utilized automatically. Unfortunately, many of the dialogs currently in Uru don't take advantage of this capability and cannot be adapted to do so properly without modifying them.

==== What the Community Has Accomplished Thus Far ====
Thanks to the efforts of everyone at GULP (http://rel.to/gulp, formerly the Uru Localization Project), we have a database of translations in a large number of languages. Changes have been made to the code re-enabling the functions which had been disabled after Untìl Uru, as well as fixes in the input routines that now allow non-US keyboards.

==== What the Community Needs to Continue ====
There are two primary allowances we need from Cyan in order to continue our efforts to expand Uru's accessibility:
# A permissive license that would allow us to copy, translate, and distribute all textual information available in Uru, currently located in the .loc files. This would legalize translations and allow their distribution, a necessary step to put all of the community's work into use.
# Access to the 3ds Max source files for all GUIs used in Uru so that we can normalize their use of the provided hooks in the code which they currently do not use, and a license to re-distribute at least the compiled output with those fixes applied. If that is deemed impossible, an inferior solution that would allow at least this specific goal is a license to modify and distribute the existing PRPs containing translatable GUI items.

At this time, we would ask if Cyan are able to indicate what difficulties they forsee over the licensing of content; if there are particular aspects where Cyan are open to suggestions; if there are specific limitations which the fans should place on their aspirations for content licensing.

Thank you for reading and considering this request.

<hr>

Following is additional technical information.

=== Technical Information ===
The .loc files are XML files containing translations for all textual items in Uru. GULP (http://rel.to/gulp) already has an extensive library of translations and a system to export that database to Uru-ready .loc files. Not all of Uru uses these however, with some values hard-coded in Python scripts or the PRPs themselves, but this can be converted as the GUI items have the ability to reference the XML paths directly. Much of this Python code references the GUI items by TagIDs, which are arbitrary unique numbers used to refer to the resource. This is messy, as it must be updated when the GUI is updated and can otherwise become out of sync; also it is problematic in the current data set as not all translatable GUI items have been assigned TagIDs, meaning they must be found (if at all) by very fragile code. There is also an embedded text field in these items, which currently contains only the English text. Fortunately, these items support a self-describing LocalizationPath which automatically informs the Plasma engine's LocalizationManager which string to use, allowing localization to be handled cleanly and consistently. All of these items are a part of the data and without a license to modify and distribute the PRPs, we cannot continue with the efforts to localize Uru outside of hacks and shims to the existing elegant but under-utilized engine.

As an additional benefit to Cyan: the changes made under the proposed licensing could be relatively easy for Cyan to integrate back into their own assets without affecting current functionality. This would be impossible if only binary changes are allowed to the exported PRPs rather than the .max sources, and it allows Cyan to take advantage of the localization code changes in the engine once it reaches maturity in the community testing with very little friction.

An extra note about the inferiority of the secondary suggestion in (2) which only allows modification of PRPs -- The reason I mention this is inferior, aside from the obvious, is that while it would allow the immediate goal of activating the built-in localization, I anticipate minor bugs such as text flow and sizing in the UI when languages other than the one for which they were designed are used. These will be extremely difficult to fix under the limited solution mentioned and should be far simpler under the ideal of having access to the original 3D Studio Max source files.

=== License Suggestions ===
I was going to wrap up by suggesting licenses in order to lighten the load on Cyan, but as the OU Content Licensing thread proves there are many viable options and they all address different needs. Unfortunately, in order to find where that spot of compromise is we'll need feedback from Cyan on this point. I implore Cyan, should they wish to consider this proposal, to respond with their concerns and needs first. At that point tangible suggestions can be made regarding the specifics and the proposal can move forward should they be agreeable.

At any rate, for the .loc files I'd suggest terms which preserves Cyan's ownership of the text (some of which, being canon from the Myst universe, has inherent value to them), while allowing edits and distribution by the community. A disclaimer stating that Cyan is only responsible for the original English text may also be desirable.

=== Links ===
Forum link: [http://forums.openuru.org/viewtopic.php?f=91&t=635 Content Licensing]

=== Signatures ===
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST)

[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST)

[[User:Branan|Branan]] 21:08, 2 February 2012 (MST)

[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST)

Cyan Content Licensing Proposals

2012-02-03T12:27:25Z

Christian Walther: /* Preface */ missing word