https://wiki.openuru.org/api.php?action=feedcontributions&user=JWPlatt&feedformat=atomOpenUru - User contributions [en]2024-03-28T09:18:10ZUser contributionsMediaWiki 1.35.1https://wiki.openuru.org/index.php?title=CyanWorlds.com_Engine&diff=3010CyanWorlds.com Engine2018-01-15T17:53:32Z<p>JWPlatt: Add Discord social links</p>
<hr />
<div><div style="float: right; padding: 10px;">http://assets.openuru.org/logos/gpl/gplv3-127x51.png</div><br />
== CyanWorlds.Com Engine (CWE) Open Source Project ==<br />
<br />
The wait is over!<br />
<br />
<br />
=== Introduction ===<br />
Cyan Worlds, Inc. and OpenUru.org jointly announce open source delivery of the CyanWorlds.com Engine client and 3ds Max plugin, aka Plasma, the engine used to power Myst Online: Uru Live.<br />
<br />
<br />
==== Cyan Worlds Announcement ====<br />
The following message was posted on the MystOnline.com forums on April 6th, 2011:<br />
<blockquote class="bluebox">An Open Letter on Open Source <big>☺</big><br />
<hr><br><br />
<br />
The progress on our open source roadmap has been slow but has never stopped. And now what will look like a large step is really the result of numerous people, both inside and outside of Cyan Worlds, slowly cutting the rock into shape... <br />
<br><br><br />
<br />
Today we are announcing that the sources for the MOULA client engine and development tools (CyanWorlds.com Engine) will be made available as open source. At the same time, MOSS which is a MOULA server replacement (written by a'moaca' and cjkelly) will also be released. Both open source projects will be hosted on OpenUru.org. <br />
<br><br><br />
<br />
The goal of the open source CyanWorlds.com Engine and the MOSS server is to provide a "playground" where new writers can learn their craft, and new maintainers can inspect it, and new cartographers can map it. The Cyan Worlds MOULA servers will continue to provide a (relatively) safe environment for the D'ni faithful to mingle and share. <br />
<br><br><br />
<br />
The path forward from here seems fairly obvious and very exciting - with amazing parallels to the D'ni universe itself. As new writers arise with new books, the books are tested and documented - and books that are approved by some new kind of maintainers guild will (hopefully) find their way to the MOULA server where the public can enjoy new worlds once again. <br />
<br><br><br />
<br />
These are exciting times, but not without risk. The tools and skills are new and need to be sharpened. There will be disagreements and strongly expressed opinions. And there will be decisions and mistakes. But keep in mind that the big picture is a lot like rebuilding a long dead civilization - and the forest of common goals far outnumber the few trees of differences. Let's keep it civil. <big>☺</big><br />
<br><br><br />
<br />
There have been numerous people cutting on the rock, and they've kept this project alive. We sincerely thank all of them for the wonderful help. Specifically there are a few people who went above and beyond - JWPlatt, a'moaca', Mac_Fife, cjkelly, rarified and Chogon. <br />
<br><br><br />
<br />
Thanks again for the continued support! <br />
<br><br><br />
<br />
Shorah,<br> <br />
Rand</blockquote><br />
<br />
==== OpenUru.org Announcement ====<br />
OpenUru.org introduces the CyanWorlds.Com Engine, Cyan Worlds' Plasma game engine used to power Myst Online: Uru Live. The OpenUru.org team is thrilled that the CyanWorlds.com Engine has been released by Cyan Worlds as open source. We are honored that Cyan Worlds has given OpenUru.org the opportunity to prepare and release it to the Uru community and the world. The initial release of the CyanWorlds.Com Engine includes Cyan Worlds' client and 3ds Max plugin.<br />
<br />
<br />
OpenUru.org is especially pleased to simultaneously announce a'moaca' and cjkelly1's Myst Online Server Software (MOSS), a Myst Online: Uru Live Again (MOULa) server replacement. MOSS was largely derived from a'moaca's work on her client protocol Wireshark plugin, a project also hosted on OpenUru.org. Cyan Worlds cannot release their server code until more is done to clear it for open source, so a'moaca' and cjkelly1's completion of their open source server couldn't have been more perfectly timed.<br />
<br />
<br />
OpenUru.org is prepared with tools to support new development of the CyanWorlds.com Engine with MOSS. We welcome all developers, issue reporters and users to contribute to the effort. Contributors can use our Foundry with Atlassian tools such as JIRA, Fisheye and Crucible to manage development projects and Jenkins (previously known as Hudson) for Continuous Integration to produce automated builds.<br />
<br />
<br />
The OpenUru.org Foundry is initially providing executable builds with the sources for both the MOSS server and MOULa client, thanks to the stellar development and preparatory work by a'moaca' and cjkelly1, and Foundry development from rarified.<br />
<br />
<br />
What is included in this source release from Cyan Worlds:<br />
<br />
* MOULa client engine source<br />
* MOULa 3ds Max plugin source<br />
* MOULa supporting Python and SDL files<br />
<br />
What is not in this source release from Cyan Worlds:<br />
<br />
* MOULa server code<br />
* Certain parts of the internal client that deal with customer service support<br />
<br />
<br />
Further details can be found at http://wiki.OpenUru.org/index.php?title=CyanWorlds.com_Engine.<br />
<br />
<br />
Open Uru is an inclusive concept of a community of creative talent and hard work coming together to make new worlds, new stories, and new content - now able to openly use and develop the CyanWorlds.com Engine to empower it. The OpenUru.org team presently consists of JWPlatt, Mac_Fife, rarified, a'moaca' and cjkelly1 and Chogon. It is hoped that others will join to lead these efforts in the infinite possibilities of Open Uru.<br />
<br />
<br />
Resources:<br />
<br />
* Website: http://OpenUru.org<br />
* Wiki: http://wiki.OpenUru.org<br />
* Foundry: http://foundry.OpenUru.org<br />
* Forums: http://forums.OpenUru.org<br />
<br />
<br />
Social:<br />
<br />
* Facebook: http://www.facebook.com/OpenUru.org<br />
* Twitter: http://twitter.com/openuru_org<br />
* Discord hood - idle talk: https://discord.gg/tVknpHQ<br />
* Discord dev - developers: https://discord.gg/jyp23GF<br />
* Discord play - gameplay discussion: https://discord.gg/vZW5rZQ<br />
* Discord support - general help: https://discord.gg/SgX22BR<br />
<br />
=== What It Is ===<br />
CyanWorlds.Com Engine is the client, server and tools used to develop and operate the Myst Online: Uru Live MMO. The server code needs more work before Cyan Worlds can clear it for open source. However, the client and 3ds Max plugin are now available in open source.<br />
<br />
<br />
=== How To Get It ===<br />
CyanWorlds.Com Engine is available on OpenUru.org's Foundry, hosted on a Mercurial code repository. There was much discussion on the Myst Online forums about the strengths of various repositories after Cyan Worlds' initial open source announcement in 2008. We listened. Mercurial was selected due to the needs of a distributed developer community.<br />
<br />
<br />
Any developer requiring "commit" access to our repositories needs to [[Foundry_Accounts|register an account]] on the Foundry at https://Foundry.OpenUru.org/jira. The Foundry is secured via <abbr title="Secure Sockets Layer">SSL</abbr> throughout the site. A browser security certificate is needed. Instructions are available on the [[Foundry Certificate Installation|certificate installation page]]. Guest access to pull from the repository does not require an account.<br />
<br />
<br />
Developers with an account will be given access to pull the CyanWorlds.Com Engine repository as quickly as possible. Once the developer traffic has subsided, the repository will be opened to the public and the curious.<br />
<br />
<br />
'''Steps'''<br />
<br />
# [[Foundry_Accounts|Register]] for a Foundry account at https://Foundry.OpenUru.org/jira (only necessary if you expect to need "commit" access to the repository).<br />
<br />
# Install the Foundry SSL Certificate using the instructions on the [[Foundry Certificate Installation|certificate installation page]].<br />
<br />
# Pull the <abbr title="CyanWorlds.com Engine">CWE-ou</abbr> repository from the address given below.<br />
<br />
<br />
'''View account queue:''' http://forums.OpenUru.org/viewtopic.php?f=91&t=507 (Note: The account queue is longer required)<br />
<br />
'''Repository address:''' https://Foundry.OpenUru.org/hg/CWE-ou<br />
<br />
As mentioned in step 1, you only need to register for an account if you wish to obtain commit access. To just pull the source, anonymous access works, or use a username of ''guest'', and a password of ''guest''.<br />
<br />
<br />
=== Development ===<br />
Some developers will be invited to join the team in management and development positions for the CyanWorlds.Com Engine project. But generally, anyone who demonstrates the skills and becomes a positive force in the project may contribute to development.<br />
<br />
<br />
CyanWorlds.Com Engine "version 1.0" will consist only of a buildable client. The plugin sources will need further work to make it buildable for 3ds Max 7. The initial release from the repositories has had just enough work done to substitute proprietary and third party libraries to allow it to build successfully. There is further work required to fully integrate the new libraries and to replace functionality that was removed in preparing the sources for release. We envisage a road map of essentially three phases: Phase 1 would aim to duplicate the functionality of the current MOUL binaries, Phase 2 would start to introduce fixes for known issues or, for example, upgrade the plugin for the current release of 3ds Max. After that, the fun begins with new features and full steam ahead to keep on chugging down that open source track. While we would ''prefer'' that change submissions follow this roadmap, nothing is set in stone, and changes with clear merit will always be welcome.<br />
<br />
<br />
Once things get rolling, we'll be looking for people to fill or help with the following positions:<br />
<br />
* Project lead (integration of job flow, patches, release schedules)<br />
* Documentation lead (create and integrate cross-platform documentation for JIRA, web, Wiki, PDF, IDE)<br />
* Technology lead (site integration, resource integration, security, builds) <br />
* Development lead (prioritization of issues, issue assignments, tools, set up code review)<br />
* Web community lead (development of web presence and content to introduce, educate and deliver open source projects<br />
<br />
<br />
=== Documentation ===<br />
What documentation? The code documents itself! Right? Actually, there was an apparent early effort to maintain directives used for automated Doxygen documentation from code. Their use fell off as time went on. Introduction of integrated documentation is considered crucial to the successful development of the CyanWorlds.Com Engine. Therefore, Doxygen directives will be accepted into the main trunk from the start. We want to build integrated documentation originating from the source code for use beginning with Fisheye (our repo browser), HTML, PDF, and the Visual Studio IDE.<br />
<br />
<br />
=== Everyone ===<br />
Everyone will be able to download and watch progress of the CyanWorlds.Com Engine project and enjoy the benefits of exploring new worlds.<br />
<br />
<br />
=== The Team ===<br />
The CyanWorlds.com Engine Project was brought to you by Cyan Worlds' Rand Miller, Tony Fryman, Mark DeForest and the collective talents of everyone at Cyan Worlds who ever worked on Uru Live over many years. The original release team at OpenUru.org who are helping to make the open source CyanWorlds.com Engine project possible are JWPlatt, Mac_Fife, rarified, a'moaca', and cjkelly1.<br />
<br />
<br />
=== Building The Client ===<br />
In the article "[[Build the client with MSVC 2003]]", cjkelly1 describes how to build a working client from the <abbr title="CyanWorlds.com Engine">CWE</abbr> sources. Note that this build uses sources and makefiles that have been modified to substitute some of the libraries that could not be distributed with the original sources.<br />
<br />
<br />
=== Building The Tools ===<br />
For compiling the plPythonPack and plFileSecure projects, there is a tutorial by Mystler in the article "[[Building the plPythonPack and plFileSecure projects]]". It is based on cjkelly1's tutorial "[[Build the client with MSVC 2003]]".<br />
<br />
<br />
== See Also ==<br />
<br />
{{:CWE/See Also}}<br />
<br />
<br />
[[Category:Cyan_Worlds]]</div>JWPlatthttps://wiki.openuru.org/index.php?title=OpenUru:Community&diff=2949OpenUru:Community2016-10-03T22:16:18Z<p>JWPlatt: Fine tune text</p>
<hr />
<div>{{protected}}<br />
{{draft}}<br />
__NOTOC__<br />
<!--INC--><br />
<script type="text/javascript" src="/sitenav/javabits/fx.js"></script><br />
<script type="text/javascript" src="/sitenav/javabits/mini001.js"></script><br />
<div id="MiniBox"><br />
<span id="Mini"><br />
<img src="/sitenav/javabits/images/Mini_Blink_3.gif"><br />
</span><br />
</div><br />
<script type="text/javascript">window.onload = showMini(30);</script><br />
<span style="color:#4682B4; text-align:left; font-size:2.0em;">Community</span><br />
<table><br />
<tr><br />
<th style="text-align:left; width: 33%;"><br />
== Links ==<br />
</th><br />
<th style="width: 20px;">&nbsp;</th><br />
<th style="text-align:left;"><br />
== About... ==<br />
</th><br />
</tr><br />
<br />
<tr><br />
<td style="vertical-align:text-top;"><br />
<ul><br />
<li><span class="plainlinks" style="font-weight: 600;">[http://forums.openuru.org OpenUru Forums]</span> - Central forums for Myst and Uru project development, discussion and ideas exchange.<br>&nbsp;</li><br />
<li><span class="plainlinks" style="font-weight: 600;">[http://wiki.openuru.org OpenUru Wiki]</span> - Myst and Uru community contributions and project documentation.<br>&nbsp;</li><br />
<li><span class="plainlinks" style="font-weight: 600;">[http://Blogs.openuru.org OpenUru Blogs]</span> - Myst and Uru project blogs for <span onMouseOver="showMini(30)";>development</span> journals and news.<br>&nbsp;</li><br />
<li><span class="plainlinks" style="font-weight: 600;">[http://rel.to/IRC/openuruchat.php OpenUru Chat]</span> - Chat channel for realtime discussions.<br>&nbsp;</li><br />
<li><span style="font-weight: 600;">[[OpenURU:Community_Portal|Community Portal]]</span> - OpenUru Wiki Community Portal.<br>&nbsp;</li><br />
<li><span class="plainlinks" style="font-weight: 600;">[http://Foundry.OpenUru.org OpenUru Foundry]</span> - Minkata Shard signup; build & development tools.<br>&nbsp;</li><br />
<li><span class="plainlinks" style="font-weight: 600;">[http://Support.OpenUru.org OpenUru Support]</span> - OpenUru.org and Foundry's Minkata Test Shard support ticket system.<br></li><br />
</ul><br />
</td><br />
<td><br />
</td><br />
<br />
<td style="vertical-align:text-top; line-height: 125%;"><br />
=== Forum Membership And Posting ===<br />
Forum group membership is an important part of being able to post and participate in some projects. The OpenUru.org forums and wiki use group membership to help prevent spamming.<br />
<br /><br /><br />
<u>'''Forum Registration'''</u><br /><br />
You are asked during the registration process for an Invitation Code to prevent automated registration by spambots. The code is currently "Shorah". If it does not work for you, please email Webmaster@OpenUru.org.<br />
<br /><br /><br />
<u>'''Forum Membership'''</u><br /><br />
After you register and your account is validated, you are automatically a member of the "Registered Users" usergroup. Registered Users can see forums, but cannot post replies, create new topics, or edit the wiki. '''Follow the instructions at the link below''' to join the Members usergroup and begin posting new threads and editing the wiki. The "Members" usergroup is an open usergroup and does not need Group Leader approval. Some Project Groups may have their own Usergroup to allow posting to their specific forums.<br />
<br /><br /><br />
[http://http://forums.openuru.org/viewtopic.php?f=112&t=6 Detailed Forum & Wiki Membership Instructions]<br />
<br /><br /><br />
To find and join more Project Groups, go the the User Control Panel's Usergroups and join selected Usergroups. Some Project Groups require a request to be approved by a Group Leader. Others might be closed from view and require invitations.<br />
<br /><br /><br />
Have fun. Make a difference.<br />
<br />
=== The Wiki ===<br />
To minimize spam vandalism, only members who: <br><br />
1) have registered on the forums, <br><br />
2) have joined the forum Members user group, and <br><br />
3) have validated their wiki email address are able to edit the wiki. Use your forum user name and password to log in.<br />
<br />
=== Blogs ===<br />
Blogs are available to OpenUru.org projects. If you would like to start a project, please see forum topic [http://forums.openuru.org/viewtopic.php?f=5&t=164 How to request a new project] <br />
</td><br />
</tr><br />
</table><br />
<!--/INC--><br />
<!-- Do not edit --><br />
[[Category:OpenUru.org]]<br />
[[Category:WikiCMS]]</div>JWPlatthttps://wiki.openuru.org/index.php?title=OpenUru:Community&diff=2948OpenUru:Community2016-10-03T22:14:17Z<p>JWPlatt: Added overdue listing of support site.</p>
<hr />
<div>{{protected}}<br />
{{draft}}<br />
__NOTOC__<br />
<!--INC--><br />
<script type="text/javascript" src="/sitenav/javabits/fx.js"></script><br />
<script type="text/javascript" src="/sitenav/javabits/mini001.js"></script><br />
<div id="MiniBox"><br />
<span id="Mini"><br />
<img src="/sitenav/javabits/images/Mini_Blink_3.gif"><br />
</span><br />
</div><br />
<script type="text/javascript">window.onload = showMini(30);</script><br />
<span style="color:#4682B4; text-align:left; font-size:2.0em;">Community</span><br />
<table><br />
<tr><br />
<th style="text-align:left; width: 33%;"><br />
== Links ==<br />
</th><br />
<th style="width: 20px;">&nbsp;</th><br />
<th style="text-align:left;"><br />
== About... ==<br />
</th><br />
</tr><br />
<br />
<tr><br />
<td style="vertical-align:text-top;"><br />
<ul><br />
<li><span class="plainlinks" style="font-weight: 600;">[http://forums.openuru.org OpenUru Forums]</span> - Central forums for Myst and Uru project development, discussion and ideas exchange.<br>&nbsp;</li><br />
<li><span class="plainlinks" style="font-weight: 600;">[http://wiki.openuru.org OpenUru Wiki]</span> - Myst and Uru community contributions and project documentation.<br>&nbsp;</li><br />
<li><span class="plainlinks" style="font-weight: 600;">[http://Blogs.openuru.org OpenUru Blogs]</span> - Myst and Uru project blogs for <span onMouseOver="showMini(30)";>development</span> journals and news.<br>&nbsp;</li><br />
<li><span class="plainlinks" style="font-weight: 600;">[http://rel.to/IRC/openuruchat.php OpenUru Chat]</span> - Chat channel for realtime discussions.<br>&nbsp;</li><br />
<li><span style="font-weight: 600;">[[OpenURU:Community_Portal|Community Portal]]</span> - OpenUru Wiki Community Portal.<br>&nbsp;</li><br />
<li><span class="plainlinks" style="font-weight: 600;">[http://Foundry.OpenUru.org OpenUru Foundry]</span> - Minkata Shard signup; build & development tools.<br>&nbsp;</li><br />
<li><span class="plainlinks" style="font-weight: 600;">[http://Support.OpenUru.org OpenUru Support]</span> - OpenUru.org and Minkata Shard support ticket system.<br></li><br />
</ul><br />
</td><br />
<td><br />
</td><br />
<br />
<td style="vertical-align:text-top; line-height: 125%;"><br />
=== Forum Membership And Posting ===<br />
Forum group membership is an important part of being able to post and participate in some projects. The OpenUru.org forums and wiki use group membership to help prevent spamming.<br />
<br /><br /><br />
<u>'''Forum Registration'''</u><br /><br />
You are asked during the registration process for an Invitation Code to prevent automated registration by spambots. The code is currently "Shorah". If it does not work for you, please email Webmaster@OpenUru.org.<br />
<br /><br /><br />
<u>'''Forum Membership'''</u><br /><br />
After you register and your account is validated, you are automatically a member of the "Registered Users" usergroup. Registered Users can see forums, but cannot post replies, create new topics, or edit the wiki. '''Follow the instructions at the link below''' to join the Members usergroup and begin posting new threads and editing the wiki. The "Members" usergroup is an open usergroup and does not need Group Leader approval. Some Project Groups may have their own Usergroup to allow posting to their specific forums.<br />
<br /><br /><br />
[http://http://forums.openuru.org/viewtopic.php?f=112&t=6 Detailed Forum & Wiki Membership Instructions]<br />
<br /><br /><br />
To find and join more Project Groups, go the the User Control Panel's Usergroups and join selected Usergroups. Some Project Groups require a request to be approved by a Group Leader. Others might be closed from view and require invitations.<br />
<br /><br /><br />
Have fun. Make a difference.<br />
<br />
=== The Wiki ===<br />
To minimize spam vandalism, only members who: <br><br />
1) have registered on the forums, <br><br />
2) have joined the forum Members user group, and <br><br />
3) have validated their wiki email address are able to edit the wiki. Use your forum user name and password to log in.<br />
<br />
=== Blogs ===<br />
Blogs are available to OpenUru.org projects. If you would like to start a project, please see forum topic [http://forums.openuru.org/viewtopic.php?f=5&t=164 How to request a new project] <br />
</td><br />
</tr><br />
</table><br />
<!--/INC--><br />
<!-- Do not edit --><br />
[[Category:OpenUru.org]]<br />
[[Category:WikiCMS]]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Cyan_Worlds_Sources_And_Tools&diff=2939Cyan Worlds Sources And Tools2016-05-13T21:17:23Z<p>JWPlatt: /* Binaries */ Added Chogon's new plugin binary release.</p>
<hr />
<div>{{UruDocProj}}<br />
{{design-stub}}<br />
<br />
<br />
== CyanWorlds.com Engine - Client & Plugin ==<br />
=== Source ===<br />
<div style="float: right; padding: 10px;">http://assets.openuru.org/logos/gpl/gplv3-127x51.png</div><br />
This is a zip file of the raw client/3ds Max plugin source files as originally released by Cyan Worlds to OpenUru.org. To work with the active development repository, please see the [[CyanWorlds.com_Engine|'''full announcement''']] for details.<br />
<br />
<br />
==== Download ====<br />
The original sources are made available here from OpenUru.org:<br />
<br />
{{Pad}}From [http://assets.OpenUru.org/cyan/MOULOpenSourceClientPlugin.zip OpenUru.org]<br />
<br />
<br />
=== 3ds Max Plugin (Binary & Documentation) ===<br />
<br />
This plug-in is for [http://en.wikipedia.org/wiki/Autodesk_3ds_Max Autodesk 3ds Max]<ref name="3ds">[http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=13567410 Autodesk 3ds Max - 3D Modeling, Animation, and Rendering Software]</ref> version 7 and is built from sources contemporary with MOULagain client build 1.871. This plug-in is reported to work with 3ds Max version 8, but <u>not</u> with any later versions.<br />
<br />
==== Download ====<br />
The binaries and documentation for the plug-in are made available here from Cyan and OpenUru.org:<br />
<br />
===== Binaries =====<br />
{{Pad}}871 From [http://assets.OpenUru.org/cyan/MOULaPlugins871.zip OpenUru.org]<br />
<br />
{{Pad}}871 From [http://cho.cyan.com/bahrowings/MOULaPlugins871.zip Cyan Worlds]<br />
<br />
{{Pad}}917/918 From [http://assets.OpenUru.org/cyan/MOULaPlugins917.zip OpenUru.org]<br />
<br />
{{Pad}}917/918 From [http://cho.cyan.com/bahrowings/MOULaPlugins917.zip Cyan Worlds]<br />
<br />
===== Documentation =====<br />
{{Pad}}From [http://assets.OpenUru.org/cyan/PlasmaPlugins.doc OpenUru.org]<br />
<br />
{{Pad}}From [http://cho.cyan.com/bahrowings/PlasmaPlugins.doc Cyan Worlds]<br />
<br />
==== Installation ====<br />
{{draft}}<br />
{{tba}}<br />
OpenUru.org documentation to follow.<br />
There are installation instructions currently on the [http://www.guildofwriters.org/wiki/Max:Installation Guild of Writers website].<br />
<br />
==== Usage ====<br />
Andy Legate has prepared a series of [[3DS Max Plugin Tutorials|illustrated tutorials on this wiki]] on using the 3ds Max plugin: These are also available on the [http://dusty.homeunix.net/wiki/Andy%27s_Max_Tutorials UAM wiki] and on the [http://www.guildofmaintainers.org/Forum/viewforum.php?f=154 Guild of Maintainers forum].<br />
<br />
== CyanWorlds.com Engine - Game and Auth Files ==<br />
These are the "Game" and "Auth" files that are necessary to complete a working server installation.<br />
<br />
=== Downloads ===<br />
<br />
==== Binaries ====<br />
<br />
Game files:<br />
<br />
{{Pad}} (902) From [http://assets.OpenUru.org/cyan/GameFiles902.zip OpenUru.org]<br />
<br />
{{Pad}} (893) From [http://assets.OpenUru.org/cyan/GameFiles.zip OpenUru.org]<br />
<br />
Auth files:<br />
<br />
{{Pad}} (902) From [http://assets.OpenUru.org/cyan/AuthFiles902.zip OpenUru.org]<br />
<br />
{{Pad}} (893) From [http://assets.OpenUru.org/cyan/AuthFiles.zip OpenUru.org]<br />
<br />
==== Source ====<br />
<div style="float: right; padding: 10px;">http://assets.openuru.org/logos/gpl/gplv3-127x51.png</div><br />
Age, Fni, Python and SDL sources:<br />
<br />
{{Pad}} (902) From [http://assets.OpenUru.org/cyan/Scripts902.zip OpenUru.org]<br />
<br />
{{Pad}} (893) From [http://assets.OpenUru.org/cyan/Scripts893.zip OpenUru.org]<br />
<br />
<br />
== KI Source ==<br />
<br />
This is the KI python and 3ds Max source files.<br />
<br />
=== Download ===<br />
The sources are made available here from Cyan and OpenUru.org:<br />
<br />
{{Pad}}From [http://assets.OpenUru.org/cyan/KI-887.zip OpenUru.org]<br />
<br />
{{Pad}}From [http://cho.cyan.com/bahrowings/KI-887.zip Cyan Worlds]<br />
<br />
<br />
== Wave Emote ==<br />
<br />
This is the 3ds Max file source for the Wave emote.<br />
<br />
=== Download ===<br />
The sources are made available here from Cyan and OpenUru.org:<br />
<br />
{{Pad}}From [http://assets.OpenUru.org/cyan/WaveEmote.zip OpenUru.org]<br />
<br />
{{Pad}}From [http://cho.cyan.com/bahrowings/WaveEmote.zip Cyan Worlds]<br />
<br />
<br />
== Avatar Assets ==<br />
<br />
These are all the Cyan avatar clothing meshes, bone structures, smoothing and texture assets used in MOUL; File type: '''.max'''. Non Cyan-logoed material is not available.<br />
<br />
=== Download ===<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/Avatar_Male01.zip Male Avatar 1]<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/Avatar_Male02.zip Male Avatar 2]<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/Avatar_Male03.zip Male Avatar 3]<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/Avatar_Male04.zip Male Avatar 4]<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.male.SmoothBase.zip Male Avatar Smoothing]<br />
<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.female.01.zip Female Avatar 1]<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.female.02.zip Female Avatar 2]<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.female.zip Female Avatar 3]<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.female.04.zip Female Avatar 4]<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.female.SmoothBase.zip Female Avatar Smoothing]<br />
<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/AvatarTextures.zip Avatar Textures (94 MB)]<br />
<br />
<br />
== See also ==<br />
<br />
{{:CWE/See Also}}<br />
<br />
<br />
'''References and citations:'''<br />
<references/><br />
<br />
[[Category:Cyan_Worlds]]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Cyan_Worlds_Sources_And_Tools&diff=2008Cyan Worlds Sources And Tools2012-12-04T18:31:13Z<p>JWPlatt: Corrected link to Scripts902.zip</p>
<hr />
<div>{{UruDocProj}}<br />
{{design-stub}}<br />
<br />
<br />
== CyanWorlds.com Engine - Client & Plugin ==<br />
=== Source ===<br />
<div style="float: right; padding: 10px;">http://assets.openuru.org/logos/gpl/gplv3-127x51.png</div><br />
This is a zip file of the raw client/3ds Max plugin source files as originally released by Cyan Worlds to OpenUru.org. To work with the active development repository, please see the [[CyanWorlds.com_Engine|'''full announcement''']] for details.<br />
<br />
<br />
==== Download ====<br />
The original sources are made available here from OpenUru.org:<br />
<br />
{{Pad}}From [http://assets.OpenUru.org/cyan/MOULOpenSourceClientPlugin.zip OpenUru.org]<br />
<br />
<br />
=== 3ds Max Plugin (Binary & Documentation) ===<br />
<br />
This plug-in is for [http://en.wikipedia.org/wiki/Autodesk_3ds_Max Autodesk 3ds Max]<ref name="3ds">[http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=13567410 Autodesk 3ds Max - 3D Modeling, Animation, and Rendering Software]</ref> version 7 and is built from sources contemporary with MOULagain client build 1.871. This plug-in is reported to work with 3ds Max version 8, but <u>not</u> with any later versions.<br />
<br />
==== Download ====<br />
The binaries and documentation for the plug-in are made available here from Cyan and OpenUru.org:<br />
<br />
===== Binaries =====<br />
{{Pad}}From [http://assets.OpenUru.org/cyan/MOULaPlugins871.zip OpenUru.org]<br />
<br />
{{Pad}}From [http://cho.cyan.com/bahrowings/MOULaPlugins871.zip Cyan Worlds]<br />
<br />
===== Documentation =====<br />
{{Pad}}From [http://assets.OpenUru.org/cyan/PlasmaPlugins.doc OpenUru.org]<br />
<br />
{{Pad}}From [http://cho.cyan.com/bahrowings/PlasmaPlugins.doc Cyan Worlds]<br />
<br />
==== Installation ====<br />
{{draft}}<br />
{{tba}}<br />
OpenUru.org documentation to follow.<br />
There are installation instructions currently on the [http://www.guildofwriters.com Guild of Writers website].<br />
<br />
<br />
==== Usage ====<br />
Andy Legate has prepared a series of [[3DS Max Plugin Tutorials|illustrated tutorials on this wiki]] on using the 3ds Max plugin: These are also available on the [http://dusty.homeunix.net/wiki/Andy%27s_Max_Tutorials UAM wiki] and on the [http://www.guildofmaintainers.org/Forum/viewforum.php?f=154 Guild of Maintainers forum].<br />
<br />
== CyanWorlds.com Engine - Game and Auth Files ==<br />
These are the "Game" and "Auth" files that are necessary to complete a working server installation.<br />
<br />
=== Downloads ===<br />
<br />
==== Binaries ====<br />
<br />
Game files:<br />
<br />
{{Pad}} (902) From [http://assets.OpenUru.org/cyan/GameFiles902.zip OpenUru.org]<br />
<br />
{{Pad}} (893) From [http://assets.OpenUru.org/cyan/GameFiles.zip OpenUru.org]<br />
<br />
Auth files:<br />
<br />
{{Pad}} (902) From [http://assets.OpenUru.org/cyan/AuthFiles902.zip OpenUru.org]<br />
<br />
{{Pad}} (893) From [http://assets.OpenUru.org/cyan/AuthFiles.zip OpenUru.org]<br />
<br />
==== Source ====<br />
<div style="float: right; padding: 10px;">http://assets.openuru.org/logos/gpl/gplv3-127x51.png</div><br />
Age, Fni, Python and SDL sources:<br />
<br />
{{Pad}} (902) From [http://assets.OpenUru.org/cyan/Scripts902.zip OpenUru.org]<br />
<br />
{{Pad}} (893) From [http://assets.OpenUru.org/cyan/Scripts893.zip OpenUru.org]<br />
<br />
<br />
== KI Source ==<br />
<br />
This is the KI python and 3ds Max source files.<br />
<br />
=== Download ===<br />
The sources are made available here from Cyan and OpenUru.org:<br />
<br />
{{Pad}}From [http://assets.OpenUru.org/cyan/KI-887.zip OpenUru.org]<br />
<br />
{{Pad}}From [http://cho.cyan.com/bahrowings/KI-887.zip Cyan Worlds]<br />
<br />
<br />
== Wave Emote ==<br />
<br />
This is the 3ds Max file source for the Wave emote.<br />
<br />
=== Download ===<br />
The sources are made available here from Cyan and OpenUru.org:<br />
<br />
{{Pad}}From [http://assets.OpenUru.org/cyan/WaveEmote.zip OpenUru.org]<br />
<br />
{{Pad}}From [http://cho.cyan.com/bahrowings/WaveEmote.zip Cyan Worlds]<br />
<br />
<br />
== Avatar Assets ==<br />
<br />
These are all the Cyan avatar clothing meshes, bone structures, smoothing and texture assets used in MOUL; File type: '''.max'''. Non Cyan-logoed material is not available.<br />
<br />
=== Download ===<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/Avatar_Male01.zip Male Avatar 1]<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/Avatar_Male02.zip Male Avatar 2]<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/Avatar_Male03.zip Male Avatar 3]<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/Avatar_Male04.zip Male Avatar 4]<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.male.SmoothBase.zip Male Avatar Smoothing]<br />
<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.female.01.zip Female Avatar 1]<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.female.02.zip Female Avatar 2]<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.female.zip Female Avatar 3]<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.female.04.zip Female Avatar 4]<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.female.SmoothBase.zip Female Avatar Smoothing]<br />
<br />
<br />
{{Pad}}[http://assets.OpenUru.org/cyan/avatar/AvatarTextures.zip Avatar Textures (94 MB)]<br />
<br />
<br />
== See also ==<br />
<br />
{{:CWE/See Also}}<br />
<br />
<br />
'''References and citations:'''<br />
<references/><br />
<br />
[[Category:Cyan_Worlds]]</div>JWPlatthttps://wiki.openuru.org/index.php?title=PhysX_Update_Testing_(Minkata.65)&diff=1952PhysX Update Testing (Minkata.65)2012-10-18T18:25:45Z<p>JWPlatt: Forum report: http://forums.openuru.org/viewtopic.php?p=7167#p7167</p>
<hr />
<div>The following table records results and observations from testing of the updated physics in the Minkata.65 client build. If you have any additional observations or test points please feel free to add them: If you're uncomfortable with editing the wiki page directly, post your comments on the [http://forums.openuru.org/viewtopic.php?f=108&t=826 forums] and someone will copy your notes to here.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Age !! Category !! Action !! Designated Tester !! Results<br />
|-<br />
| Ahnonay || Vehicles || Chair Ride (Sphere 4) || ||<br />
|-<br />
| Ahnonay || Jump || From island to rock to rock to water (Sphere 1) || ||<br />
|-<br />
| Ahnonay || Avatar || Swimming (Sphere 1) || ||<br />
|-<br />
| Ahnonay || Environmental || Linking to Final Cloth in Hut || D'Lanor || avatar fell through and panic linked to Relto<br />
|-<br />
| Ahnonay Cathedral || N/A || N/A || N/A ||<br />
|-<br />
| Cleft || Jump || Hole in Hanging Bridge || ||<br />
|-<br />
| D'ni (City Island) || Kickables || Cones (if enabled) || N/A ||<br />
|-<br />
| D'ni (City Island) || Jump || Up on crates on Rooftop || ||<br />
|-<br />
| Dereno || N/A || N/A || N/A ||<br />
|-<br />
| Descent || Environmental || Walk spiral walkway up & down shaft || Tai'lahr || walking is fine, but on jump, camera shakes just before panic link out<br />
|-<br />
| Eder Delin || N/A || N/A || N/A ||<br />
|-<br />
| Eder Gira || Environmental || Fumerole to Journey Cloth || Tai'lahr || works fine<br />
|-<br />
| Eder Gira || Environmental || Fumerole over Rock Pile || Tai'lahr || works fine<br />
|-<br />
| Eder Gira || Jump || From journey cloth on ledge down to fumerole in lava || Tai'lahr || easy<br />
|-<br />
| Eder Gira || Jump || From fumerole above lava to ledge under bridge || tai'lahr || easy<br />
|-<br />
| Eder Gira || Jump || Should not be able to easily climb over Rock Pile (compare to Gehn Shard) || D'Lanor || confirmed unable to climb over rock pile<br />
|-<br />
| Eder Gira || Jump || (Optional) to pipe over bridge from small rock pedestal || Tai'lahr || easy<br />
|-<br />
| Eder Gira || Kickables || Fishing Baskets. Should include crossing them with fireflies... || Tai'lahr || baskets move well<br />
|-<br />
| Eder Gira || || Should not be able to cross 2nd water w fireflies w/o baskets || Treehugger || found that avatar can walk along edge of rock & not lose fireflies<br />
|-<br />
| || || || D'Lanor || did not find this possible<br />
|-<br />
| Eder Kemo || Jump || Up to ledge with journey cloth || D'Lanor || jump works fine<br />
|-<br />
| Eder Kemo || Jump || In puffer garden, from wall to rock & then to ledge with Relto page || D'Lanor || jump works fine<br />
|-<br />
| Eder Tsogal || Avatar || Effects when running through water? || ||<br />
|-<br />
| Er'cana || Vehicles || Harvester || Treehugger || works well<br />
|-<br />
| Er'cana || Vehicles || Elevator in Baking Room || ||<br />
|-<br />
| Er'cana || Environmental || Entering Shell Portal || Treehugger || avatar "juddered back & forth before disappearing"<br />
|-<br />
| Er'cana City Silo || N/A || N/A || ||<br />
|-<br />
| Everywhere || Avatar || Using KI while sitting || ||<br />
|-<br />
| Everywhere || Avatar || Using KI while dancing || ||<br />
|-<br />
| Everywhere || Avatar || Walking on surfaces should be normal || || HenryMikhel found some surfaces in Er'cana are "sticky" and avatar walks very slowly on them<br />
|-<br />
| Everywhere || Avatar || Using KI while run-jumping || Ehren || Run-Jump with F2/Max KI causes Avatar to WiggleFly (ascend) until KI closed - panic link<br />
|-<br />
| Gahreesen || Vehicles || Elevators up and down in 1st building || Treehugger || seem fine<br />
|-<br />
| Gahreesen || Jump || Cross gap on 1st floor || Tai'lahr || not a problem<br />
|-<br />
| Gahreesen || Jump || Up broken wall || Tai'lahr || not a problem<br />
|-<br />
| Gahreesen || Jump || To and From spinning platforms and rock in the middle outdoors || ||<br />
|-<br />
| Gahreesen || Jump || In and out of rotating wall || Treehugger || more difficult to get into the cog; kept throwing the avatar out<br />
|-<br />
| || || || Mac Fife || noted that it included a change in camera view<br />
|-<br />
| || || || Tai'lahr || tested just standing at the cog not moving; when the opening came around, it turned the avatar around and change camera view<br />
|-<br />
| Gahreesen || Jump || From rock to Bahro Cave Door || ||<br />
|-<br />
| Gahreesen || Kickables || Bones in prison room with relto page || ||<br />
|-<br />
| Great Tree Pub || N/A || N/A || N/A ||<br />
|-<br />
| Great Zero || N/A || N/A || ||<br />
|-<br />
| Guild Pubs || N/A || N/A || N/A ||<br />
|-<br />
| Jalak Dador || Vehicles || Columns Up and Down || ||<br />
|-<br />
| Jalak Dador || Kickables || Glowing blocks || ||<br />
|-<br />
| K'veer || N/A || N/A || N/A ||<br />
|-<br />
| Kadish Tolesa || Vehicles || Elevator after Moon Room || Tai'lahr || works fine<br />
|-<br />
| Kadish Tolesa || Jump || To ledge for pine tree Relto page and back || Tai'lahr || easy jumps<br />
|-<br />
| Kadish Tolesa || Jump || Up on crates in vault to journey cloth || Tai'lahr || relatively easy; seems to have more boundaries<br />
|-<br />
| Kadish Tolesa || Jump || Shortcut to journey cloth to avoid walking all around the gazebo with the gallery book & 1st scope || Tai'lahr || easy jump<br />
|-<br />
| Kadish Tolesa || Kickables || Leaves || D'Lanor || working great<br />
|-<br />
| || || || Tai'lahr || If you kick the leaves while running, they'll fly into the air. ; )<br />
|-<br />
| Minkata || Kickables || Soccer Ball || ||<br />
|-<br />
| Minkata || Environmental || Entering Portal || Treehugger || avatar "juddered back & forth before disappearing"<br />
|-<br />
| Myst || N/A || N/A || N/A ||<br />
|-<br />
| Negilahn || N/A || N/A || N/A ||<br />
|-<br />
| Neighborhood || Jump || To ledge in light garden for Relto page || Tai'lahr || easy<br />
|-<br />
| Neighborhood || Kickables || Cones || ||<br />
|-<br />
| Neighborhood || Kickables || Firemarbles || ||<br />
|-<br />
| Neighborhood || Kickables || Beach Ball || ||<br />
|-<br />
| Nexus || N/A || N/A || N/A ||<br />
|-<br />
| Payiferen || N/A || N/A || N/A ||<br />
|-<br />
| Phil's Relto || N/A || N/A || N/A ||<br />
|-<br />
| Relto || Kickables || Stones || Treehugger || works well<br />
|-<br />
| Relto || Kickables || Logs || Treehugger || works well<br />
|-<br />
| Relto || Kickables || Firemarbles || Treehugger || works well<br />
|-<br />
| Teledahn || Vehicles || Elevator (Hut / Control Room / Douglas' Room) || ||<br />
|-<br />
| Teledahn || Vehicles || Bucket Ride || Treehugger || works well<br />
|-<br />
| Teledahn || Jump || To lower raised bridge on bamboo walkway || Tai'lahr || easy<br />
|-<br />
| Teledahn || Jump || On metal walkway to make it drop down to mushroom || Tai'lahr || easy<br />
|-<br />
| Teledahn || Jump || (Optional) jumping on Sharper’s bed || Treehugger || seems fine<br />
|-<br />
| Teledahn || Kickables || Bones, stones, fish baskets in slave cave || Treehugger || works well<br />
|-<br />
| Teledahn || Environmental || Door dropping in slave cave || Tai'lahr || works fine<br />
|-<br />
| Teledahn || Avatar || Effects when running through water? || Treehugger || works well<br />
|-<br />
| Tetsonot || N/A || N/A || N/A ||<br />
|}</div>JWPlatthttps://wiki.openuru.org/index.php?title=Open_Source_Shard_List&diff=1945Open Source Shard List2012-09-26T00:43:42Z<p>JWPlatt: Added Types: Down, Canceled</p>
<hr />
<div>This page lists known Open Source shards, with a basic description and contact details. To have your shard listed, please add details to this forum thread: http://forums.openuru.org/viewtopic.php?f=91&t=554<br />
<br />
Please note that this list is for shards running Open Source server software only and run in accordance with Cyan's content licensing rules.<br />
<br />
; Shard Name : The preferred name of the shard, i.e. the name by which its owner(s) would like it to be known.<br />
; Server S/W : The server software used by the shard, e.g. MOSS, Dirtsand, Cyan.<br />
; Type : The access type of the shard, Public, Invitation or Private. Down or Canceled for temporarily or permanently offline, respectively.<br />
; Test Use : Whether this shard is available for test use or not: Yes, No.<br />
; Description : Brief description of the shard, any key features.<br />
; Shard Site URL : Website associated with the shard, e.g. location for client download.<br />
; Contact : Contact detail for shard admin. Preferably a link to a forum profile.<br />
<br />
<br />
The table below is sortable.<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Shard Name !! Server S/W !! Type !! Test Use !! Description !! Shard Site URL !! Contact<br />
|-<br />
| Minkata || MOSS || Public || Yes || OpenUru.org shard: Testing of fan submitted code changes (Testing of Fan Ages in the future) - Cyan content (not served, as per license restrictions). || http://Foundry.OpenUru.org || [http://Support.OpenUru.org Support]<br />
|-<br />
| Lost City Of Atlantis || MOSS || Public || Yes || Testing of Fan Ages, (Client, Or Python only a few can do this) - Cyan content (not served, as per license restrictions) || http://atlantis.servegame.org/forums/index.php || [http://forums.openuru.org/memberlist.php?mode=viewprofile&u=1022 MercAngel]<br />
|-<br />
| Windring || MOSS || Public || No || Planned shard - Cyan content (not served, as per license restrictions) and fan content vetted by GoMa || Not advised || [http://forums.openuru.org/memberlist.php?mode=viewprofile&u=1015 rplawrence]<br />
|-<br />
| Destiny || MOSS || Private || Yes || Private testing || Not advised || [http://forums.openuru.org/memberlist.php?mode=viewprofile&u=1002 Mystler]<br />
|-<br />
| The Open Cave || MOSS || Public || No || Cyan content (not served, as per license restrictions) and fan additions || http://the-open-cave.net || Filtik/[http://forums.openuru.org/memberlist.php?mode=viewprofile&u=1002 Mystler]<br />
|-<br />
| Gehn Shard || DIRTSAND || Public || Yes || Guild of Writers' shard for testing bleeding-edge fixes and enhancements - Cyan content (not served, as per license restrictions). || [http://forum.guildofwriters.org/viewtopic.php?f=117&t=5540 Gehn Shard Installation Instructions] || [http://forum.guildofwriters.org/viewforum.php?f=117 Gehn Shard Forum]<br />
|-<br />
| Lyros || DIRTSAND || Invitation || Yes || Cyan content (not served, as per license restrictions) and eventually minor changes (not to Cyan content). || http://uru.lyros.net/shard/ || [http://forums.openuru.org/memberlist.php?mode=viewprofile&u=1173 Lyrositor]<br />
|}<br />
<br />
[[Category:MOSS]]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Talk:Open_Source_Shard_List&diff=1944Talk:Open Source Shard List2012-09-26T00:40:13Z<p>JWPlatt: How To List Inactive Shards</p>
<hr />
<div>If a shard is taken down permanently, it would be great of we can retain the history of the shard's existence by listing the "Type" as "Canceled" or something final-sounding like that. "Down" could mean something more temporary. [[User:JWPlatt|JWPlatt]] 18:40, 25 September 2012 (MDT)</div>JWPlatthttps://wiki.openuru.org/index.php?title=User_talk:Trekluver/sandbox&diff=1942User talk:Trekluver/sandbox2012-09-11T16:42:32Z<p>JWPlatt: /* Premise of basing license on SFX files */</p>
<hr />
<div>== Sub-section numbering ==<br />
Some sub-section numbering has gone wonky (mixed alpha and numerical numbering) as a result of pasting the original HTML formatted text into the wiki markup and not taking out some of the imported "bullets". --[[User:Mac Fife|Mac Fife]] 15:01, 19 July 2012 (MDT)<br />
:Yea, I was aware of it but haven't had the chance to go through and fix it. I figured that since it's my sandbox page, it's not that big of a deal until I have the time. :) --[[User:Trekluver|Trekluver]] 13:29, 25 July 2012 (MDT)<br />
<br />
== Premise of basing license on SFX files ==<br />
This offers no help to e.g. the Uru Localization folks who want to change/extend the text! Also, I think you're missing the point about PRPs: While a license to distribute the PRPs (and the SFX files) is necessary for a shard to be self-sufficient (i.e. not dependant on copy data from a MOULa install) you need to remember that the PRPs are a compiled product and '''not''' the source files (which are 3ds Max files by and large). So, a license to distribute the existing game content on shard is actually covering a different set of files compared to license that allows modification of the sources, although the former can be produced from the latter. Textures are probably the most valuable things to age creators aiming for a consistent D'ni look in their work (and they're probably the most jealously guarded of Cyan's assets). --[[User:Mac Fife|Mac Fife]] 15:01, 19 July 2012 (MDT)<br />
:While that was just a mockup (I'm far from done with the draft. ;) ) I'm not entirely sure what you're referring to. The file names, or the license terms? As far as the SFX file names go, we can't change those because it would require far to many exception changes for shard operators and become unnecessarily complicated. And as far as the license terms go, when it's done it will basically be a revokable version of a CC license that someone has to sign up for from Cyan (At least where this version is concerned. We'll talk more about the specifics in our meeting.). <br />
<br />
:As far as the PRP's go, maybe my wording was off. I realize everything you mentioned, which is exactly why it needs to be two separate licenses. Otherwise, what you create is the potential for Cyan to say they own any and all derivatives, rather than just the files that belong to them. The raw data files and textures will be the most difficult thing to convince Cyan to license. We need to discuss how to do this better during the meeting and, when we start to license, really get the input of Branan and Hoikas. (Their knowledge in this field will be highly valuable.). --[[User:Trekluver|Trekluver]] 13:29, 25 July 2012 (MDT)<br />
<br />
:: I'm not suggesting anything at all about changing files names: What I was trying to get at was that your draft is written to specifically address the sfx files at the exclusion of others file types, and you go so far as to propose naming the files covered by the license. My point was that there has been a lot of work done to translate the textual content in Uru (e.g. the journals, etc.) and that needs to go into some of the other (existing) files in the dat folder, aside from any issues of people wanting to devlop new ages, etc. So focussing on sfx files is just too limiting. Also naming the files is potentially a "bad thing" - Let's say Cyan initially licenses a small sub-set of file to "see how things go" and later opts to release a larger (or different) set, then if the files are named within the license you'll effectively be in the position of re-licensing and that can get messy, depending upon circumstances.<br />
<br />
::: Just FYI: My biggest problem with any newly- or custom-authored license is that it would have to be read and analysed by Cyan Legal and then cycled an unknown number of times until everyone is satisfied, possibly delaying completion forever and ever. It is my opinion that any license must already be publicly established, well-known, understood, accepted and respected. And that license should not be modified in its original content, but have exceptions and additions attached as an addendum or "codicil." Only in this way can anyone understand its terms at a glance and minimize reasonable time to completion. [[User:JWPlatt|JWPlatt]] 10:42, 11 September 2012 (MDT)</div>JWPlatthttps://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals&diff=1881Cyan Content Licensing Proposals2012-02-21T16:29:14Z<p>JWPlatt: /* Summary */ Sigh. Add space. Used preview - still missed it.</p>
<hr />
<div>== Content Licensing Request ==<br />
=== Introduction ===<br />
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.<br />
<br />
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.<br />
<br />
=== Examples ===<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
=== Community Needs ===<br />
<br />
There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
=== Questions ===<br />
<br />
* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?<br />
<br />
<br />
* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?<br />
<br />
<br />
* Are there specific limitations that fans should place on their hopes for content licensing?<br />
<br />
<br />
* Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?<br />
<br />
<br />
=== Summary ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
This document's history on the wiki (includes additional detail and examples):<br />
<br />
http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals<br />
<br />
<br />
Full discussion on the OpenUru.org forums:<br />
<br />
http://forums.openuru.org/viewtopic.php?f=91&t=635<br />
<br />
=== Signatures, Open Source Uru Community ===<br />
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST), Lewis Johnston, GULP, (Address TBI)<br />
<br />
[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST), Adam Johnson, GuildOfWriters.org, H'uru, (Address TBI)<br />
<br />
[[User:Branan|Branan]] 21:08, 2 February 2012 (MST), Branan Purvine-Riley, H'uru, (Address TBI)<br />
<br />
[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST), Christian Walther, independent developer, (Address TBI)<br />
<br />
[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST), (Name TBI), GuildOfMessengers.com<br />
<br />
[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST), Ian M. McIntosh, OpenUru.org, (Address TBI)<br />
<br />
[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST), (Name TBI), H'uru<br />
<br />
[[User:Malfhok|Malfhok]] 05:14, 4 February 2012 (MST), (Name TBI), an explorer, (Address TBI)<br />
<br />
[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST), Joseph Davies, H'uru, (Address TBI)<br />
<br />
[[User:Marten|Marten]] 09:44, 5 February 2012 (MST), John Johns, The Great Tree, Guild of Messengers, Washougal, WA<br />
<br />
[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET), (Name TBI)<br />
<br />
[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST), Chloe Rhodes, TheDeepCity.com, (Address TBI)<br />
<br />
[[User:JWPlatt|JWPlatt]] 10:51, 15 February 2012 (EST), Jonathan W. Platt, OpenUru.org, (Address TBI)<br />
<br />
[[User:rarified|rarified]] 14:30, 15 February 2012 (MST), Paul Richards, OpenUru.org, (Address TBI)<br />
<br />
== Additional Information ==<br />
<br />
=== Technical Information on the Localization Example ===<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Additional Examples ===<br />
==== Collider Fixes for PhysX 2.6.4 ====<br />
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:<br />
<br />
[https://github.com/H-uru/Plasma/commit/529ff7982c53410616c62ffb98320e2dd2fd93f4 H-uru/Plasma@529ff79 on GitHub]<br />
<blockquote>'''Band-aid for poorly modelled stairs'''<br><br />
Looks like the Cyan modellers didn't extend the stair ramps all the way<br />
down in some places. To compensate, we can now take higher steps but can't<br />
walk on slopes quite as steep as before. I think this should balance out<br />
nicely.</blockquote><br />
<br />
''More details by Adam Johnson (Hoikas):''<br />
<br />
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.''<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/stairs.jpg http://assets.openuru.org/wiki/general/stairs_tn.jpg]</span><br />
<br />
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.<br />
<br />
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.<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/rocks.jpg http://assets.openuru.org/wiki/general/rocks_tn.jpg]</span><br />
<br />
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).<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/cones.jpg http://assets.openuru.org/wiki/general/cones_tn.jpg]</span><br />
<br />
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.<br />
<br />
''TL;DR: Collision meshes are broken, we must fix them!''<br />
<br />
==== KI Coordinates in Great Zero Courtyard are Backward ====<br />
Issue brought up recently on the MOUL forum that should be easy to fix given a content license:<br />
http://mystonline.com/forums/viewtopic.php?t=25431<br />
<br />
=== License Suggestions ===<br />
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.<br />
<br />
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.</div>JWPlatthttps://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals&diff=1880Cyan Content Licensing Proposals2012-02-21T16:27:47Z<p>JWPlatt: /* Summary */ Try to match format again (always use preview before save)</p>
<hr />
<div>== Content Licensing Request ==<br />
=== Introduction ===<br />
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.<br />
<br />
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.<br />
<br />
=== Examples ===<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
=== Community Needs ===<br />
<br />
There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
=== Questions ===<br />
<br />
* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?<br />
<br />
<br />
* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?<br />
<br />
<br />
* Are there specific limitations that fans should place on their hopes for content licensing?<br />
<br />
<br />
* Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?<br />
<br />
<br />
=== Summary ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
This document's history on the wiki(includes additional detail and examples):<br />
<br />
http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals<br />
<br />
Full discussion on the OpenUru.org forums:<br />
<br />
http://forums.openuru.org/viewtopic.php?f=91&t=635<br />
<br />
=== Signatures, Open Source Uru Community ===<br />
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST), Lewis Johnston, GULP, (Address TBI)<br />
<br />
[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST), Adam Johnson, GuildOfWriters.org, H'uru, (Address TBI)<br />
<br />
[[User:Branan|Branan]] 21:08, 2 February 2012 (MST), Branan Purvine-Riley, H'uru, (Address TBI)<br />
<br />
[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST), Christian Walther, independent developer, (Address TBI)<br />
<br />
[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST), (Name TBI), GuildOfMessengers.com<br />
<br />
[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST), Ian M. McIntosh, OpenUru.org, (Address TBI)<br />
<br />
[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST), (Name TBI), H'uru<br />
<br />
[[User:Malfhok|Malfhok]] 05:14, 4 February 2012 (MST), (Name TBI), an explorer, (Address TBI)<br />
<br />
[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST), Joseph Davies, H'uru, (Address TBI)<br />
<br />
[[User:Marten|Marten]] 09:44, 5 February 2012 (MST), John Johns, The Great Tree, Guild of Messengers, Washougal, WA<br />
<br />
[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET), (Name TBI)<br />
<br />
[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST), Chloe Rhodes, TheDeepCity.com, (Address TBI)<br />
<br />
[[User:JWPlatt|JWPlatt]] 10:51, 15 February 2012 (EST), Jonathan W. Platt, OpenUru.org, (Address TBI)<br />
<br />
[[User:rarified|rarified]] 14:30, 15 February 2012 (MST), Paul Richards, OpenUru.org, (Address TBI)<br />
<br />
== Additional Information ==<br />
<br />
=== Technical Information on the Localization Example ===<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Additional Examples ===<br />
==== Collider Fixes for PhysX 2.6.4 ====<br />
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:<br />
<br />
[https://github.com/H-uru/Plasma/commit/529ff7982c53410616c62ffb98320e2dd2fd93f4 H-uru/Plasma@529ff79 on GitHub]<br />
<blockquote>'''Band-aid for poorly modelled stairs'''<br><br />
Looks like the Cyan modellers didn't extend the stair ramps all the way<br />
down in some places. To compensate, we can now take higher steps but can't<br />
walk on slopes quite as steep as before. I think this should balance out<br />
nicely.</blockquote><br />
<br />
''More details by Adam Johnson (Hoikas):''<br />
<br />
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.''<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/stairs.jpg http://assets.openuru.org/wiki/general/stairs_tn.jpg]</span><br />
<br />
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.<br />
<br />
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.<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/rocks.jpg http://assets.openuru.org/wiki/general/rocks_tn.jpg]</span><br />
<br />
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).<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/cones.jpg http://assets.openuru.org/wiki/general/cones_tn.jpg]</span><br />
<br />
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.<br />
<br />
''TL;DR: Collision meshes are broken, we must fix them!''<br />
<br />
==== KI Coordinates in Great Zero Courtyard are Backward ====<br />
Issue brought up recently on the MOUL forum that should be easy to fix given a content license:<br />
http://mystonline.com/forums/viewtopic.php?t=25431<br />
<br />
=== License Suggestions ===<br />
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.<br />
<br />
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.</div>JWPlatthttps://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals&diff=1879Cyan Content Licensing Proposals2012-02-21T16:26:48Z<p>JWPlatt: /* Summary */ Match draft format and added parenthetical</p>
<hr />
<div>== Content Licensing Request ==<br />
=== Introduction ===<br />
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.<br />
<br />
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.<br />
<br />
=== Examples ===<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
=== Community Needs ===<br />
<br />
There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
=== Questions ===<br />
<br />
* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?<br />
<br />
<br />
* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?<br />
<br />
<br />
* Are there specific limitations that fans should place on their hopes for content licensing?<br />
<br />
<br />
* Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?<br />
<br />
<br />
=== Summary ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
This document's history on the wiki(includes additional detail and examples):<br />
http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals<br />
<br />
Full discussion on the OpenUru.org forums:<br />
http://forums.openuru.org/viewtopic.php?f=91&t=635<br />
<br />
=== Signatures, Open Source Uru Community ===<br />
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST), Lewis Johnston, GULP, (Address TBI)<br />
<br />
[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST), Adam Johnson, GuildOfWriters.org, H'uru, (Address TBI)<br />
<br />
[[User:Branan|Branan]] 21:08, 2 February 2012 (MST), Branan Purvine-Riley, H'uru, (Address TBI)<br />
<br />
[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST), Christian Walther, independent developer, (Address TBI)<br />
<br />
[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST), (Name TBI), GuildOfMessengers.com<br />
<br />
[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST), Ian M. McIntosh, OpenUru.org, (Address TBI)<br />
<br />
[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST), (Name TBI), H'uru<br />
<br />
[[User:Malfhok|Malfhok]] 05:14, 4 February 2012 (MST), (Name TBI), an explorer, (Address TBI)<br />
<br />
[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST), Joseph Davies, H'uru, (Address TBI)<br />
<br />
[[User:Marten|Marten]] 09:44, 5 February 2012 (MST), John Johns, The Great Tree, Guild of Messengers, Washougal, WA<br />
<br />
[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET), (Name TBI)<br />
<br />
[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST), Chloe Rhodes, TheDeepCity.com, (Address TBI)<br />
<br />
[[User:JWPlatt|JWPlatt]] 10:51, 15 February 2012 (EST), Jonathan W. Platt, OpenUru.org, (Address TBI)<br />
<br />
[[User:rarified|rarified]] 14:30, 15 February 2012 (MST), Paul Richards, OpenUru.org, (Address TBI)<br />
<br />
== Additional Information ==<br />
<br />
=== Technical Information on the Localization Example ===<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Additional Examples ===<br />
==== Collider Fixes for PhysX 2.6.4 ====<br />
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:<br />
<br />
[https://github.com/H-uru/Plasma/commit/529ff7982c53410616c62ffb98320e2dd2fd93f4 H-uru/Plasma@529ff79 on GitHub]<br />
<blockquote>'''Band-aid for poorly modelled stairs'''<br><br />
Looks like the Cyan modellers didn't extend the stair ramps all the way<br />
down in some places. To compensate, we can now take higher steps but can't<br />
walk on slopes quite as steep as before. I think this should balance out<br />
nicely.</blockquote><br />
<br />
''More details by Adam Johnson (Hoikas):''<br />
<br />
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.''<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/stairs.jpg http://assets.openuru.org/wiki/general/stairs_tn.jpg]</span><br />
<br />
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.<br />
<br />
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.<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/rocks.jpg http://assets.openuru.org/wiki/general/rocks_tn.jpg]</span><br />
<br />
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).<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/cones.jpg http://assets.openuru.org/wiki/general/cones_tn.jpg]</span><br />
<br />
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.<br />
<br />
''TL;DR: Collision meshes are broken, we must fix them!''<br />
<br />
==== KI Coordinates in Great Zero Courtyard are Backward ====<br />
Issue brought up recently on the MOUL forum that should be easy to fix given a content license:<br />
http://mystonline.com/forums/viewtopic.php?t=25431<br />
<br />
=== License Suggestions ===<br />
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.<br />
<br />
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.</div>JWPlatthttps://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals&diff=1878Cyan Content Licensing Proposals2012-02-21T15:18:36Z<p>JWPlatt: /* Examples */ Added link to GULP in first bullet point</p>
<hr />
<div>== Content Licensing Request ==<br />
=== Introduction ===<br />
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.<br />
<br />
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.<br />
<br />
=== Examples ===<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
=== Community Needs ===<br />
<br />
There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
=== Questions ===<br />
<br />
* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?<br />
<br />
<br />
* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?<br />
<br />
<br />
* Are there specific limitations that fans should place on their hopes for content licensing?<br />
<br />
<br />
* Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?<br />
<br />
<br />
=== Summary ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
This document's history on the wiki: http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals<br />
<br />
Full discussion on the OpenUru.org forums: http://forums.openuru.org/viewtopic.php?f=91&t=635<br />
<br />
<br />
=== Signatures, Open Source Uru Community ===<br />
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST), Lewis Johnston, GULP, (Address TBI)<br />
<br />
[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST), Adam Johnson, GuildOfWriters.org, H'uru, (Address TBI)<br />
<br />
[[User:Branan|Branan]] 21:08, 2 February 2012 (MST), Branan Purvine-Riley, H'uru, (Address TBI)<br />
<br />
[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST), Christian Walther, independent developer, (Address TBI)<br />
<br />
[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST), (Name TBI), GuildOfMessengers.com<br />
<br />
[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST), Ian M. McIntosh, OpenUru.org, (Address TBI)<br />
<br />
[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST), (Name TBI), H'uru<br />
<br />
[[User:Malfhok|Malfhok]] 05:14, 4 February 2012 (MST), (Name TBI), an explorer, (Address TBI)<br />
<br />
[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST), Joseph Davies, H'uru, (Address TBI)<br />
<br />
[[User:Marten|Marten]] 09:44, 5 February 2012 (MST), John Johns, The Great Tree, Guild of Messengers, Washougal, WA<br />
<br />
[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET), (Name TBI)<br />
<br />
[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST), Chloe Rhodes, TheDeepCity.com, (Address TBI)<br />
<br />
[[User:JWPlatt|JWPlatt]] 10:51, 15 February 2012 (EST), Jonathan W. Platt, OpenUru.org, (Address TBI)<br />
<br />
[[User:rarified|rarified]] 14:30, 15 February 2012 (MST), Paul Richards, OpenUru.org, (Address TBI)<br />
<br />
== Additional Information ==<br />
<br />
=== Technical Information on the Localization Example ===<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Additional Examples ===<br />
==== Collider Fixes for PhysX 2.6.4 ====<br />
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:<br />
<br />
[https://github.com/H-uru/Plasma/commit/529ff7982c53410616c62ffb98320e2dd2fd93f4 H-uru/Plasma@529ff79 on GitHub]<br />
<blockquote>'''Band-aid for poorly modelled stairs'''<br><br />
Looks like the Cyan modellers didn't extend the stair ramps all the way<br />
down in some places. To compensate, we can now take higher steps but can't<br />
walk on slopes quite as steep as before. I think this should balance out<br />
nicely.</blockquote><br />
<br />
''More details by Adam Johnson (Hoikas):''<br />
<br />
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.''<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/stairs.jpg http://assets.openuru.org/wiki/general/stairs_tn.jpg]</span><br />
<br />
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.<br />
<br />
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.<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/rocks.jpg http://assets.openuru.org/wiki/general/rocks_tn.jpg]</span><br />
<br />
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).<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/cones.jpg http://assets.openuru.org/wiki/general/cones_tn.jpg]</span><br />
<br />
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.<br />
<br />
''TL;DR: Collision meshes are broken, we must fix them!''<br />
<br />
==== KI Coordinates in Great Zero Courtyard are Backward ====<br />
Issue brought up recently on the MOUL forum that should be easy to fix given a content license:<br />
http://mystonline.com/forums/viewtopic.php?t=25431<br />
<br />
=== License Suggestions ===<br />
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.<br />
<br />
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.</div>JWPlatthttps://wiki.openuru.org/index.php?title=MOSS&diff=1850MOSS2012-02-21T06:25:27Z<p>JWPlatt: /* Why Use MOSS? */ Add back original intent of language to stress the systems perspective.</p>
<hr />
<div>'''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.<br />
<br />
<div style="float: right; padding: 10px;">http://assets.openuru.org/logos/gpl/gplv3-127x51.png</div><br />
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.<br />
<br />
== Why Use MOSS? ==<br />
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.<br />
<br />
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, but let's fix it if development resumes.)<br />
<br />
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.<br />
<br />
== How to Get It ==<br />
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.<br />
<br />
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<br />
page]].<br />
<br />
'''Repository address:''' https://foundry.openuru.org/hg/MOSS<br />
<br />
'''Snapshot location:''' ''TBD''<br />
<br />
'''Binary package:''' ''TBD''<br />
{{tba}}<br />
<br />
== How to Set Up a Server ==<br />
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]].<br />
<br />
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].<br />
<br />
There is some Q&A and other notes of possible interest to someone running a server at [[MOSS-Notes]].<br />
<br />
== How to Contribute ==<br />
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.<br />
<br />
Almost any code contribution is welcome. What is unwelcome? <br />
* Protocol/behavior changes without corresponding client support (obviously). <br />
* Changes that remove security without the option of keeping it. <br />
* Changes that introduce security holes, either in the server itself or the vault. <br />
* Changes that break big-endian support (call it a pet peeve if you like, it's still unwelcome). <br />
* Changes that break the build (accidents do happen, but don't break it on purpose). <br />
Hopefully it is not difficult to see why these things are unwelcome.<br />
<br />
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].<br />
<br />
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.<br />
<br />
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.<br />
<br />
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<br />
[https://foundry.openuru.org/hg/MOSS central repository].<br />
<br />
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<br />
people will get write access soon enough!<br />
<br />
Code reviewers might be needed. If you are willing to be a reviewer, say so! It is a very valuable contribution.<br />
<br />
== See Also ==<br />
* [[MOSS-Notes]]<br />
* [[MOSS-Setup]]<br />
* [[MOSS-Distribution Specific Instructions]]<br />
* [[MOSS-Developer Notes]]<br />
* [[CyanWorlds.com Engine]]<br />
* [[Building the plPythonPack and plFileSecure projects]]<br />
<br />
[[Category:MOSS]]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals&diff=1844Cyan Content Licensing Proposals2012-02-19T20:01:36Z<p>JWPlatt: /* Signatures, Open Source Uru Community */ Added Marten's info with permission</p>
<hr />
<div>== Content Licensing Request ==<br />
=== Introduction ===<br />
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.<br />
<br />
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.<br />
<br />
=== Examples ===<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
=== Community Needs ===<br />
<br />
There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
=== Questions ===<br />
<br />
* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?<br />
<br />
<br />
* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?<br />
<br />
<br />
* Are there specific limitations that fans should place on their hopes for content licensing?<br />
<br />
<br />
* Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?<br />
<br />
<br />
=== Summary ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
This document's history on the wiki: http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals<br />
<br />
Full discussion on the OpenUru.org forums: http://forums.openuru.org/viewtopic.php?f=91&t=635<br />
<br />
<br />
=== Signatures, Open Source Uru Community ===<br />
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST), Lewis Johnston, GULP, (Address TBI)<br />
<br />
[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST), Adam Johnson, GuildOfWriters.org, H'uru, (Address TBI)<br />
<br />
[[User:Branan|Branan]] 21:08, 2 February 2012 (MST), Branan Purvine-Riley, H'uru, (Address TBI)<br />
<br />
[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST), Christian Walther, independent developer, (Address TBI)<br />
<br />
[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST), (Name TBI), GuildOfMessengers.com<br />
<br />
[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST), Ian M. McIntosh, OpenUru.org, (Address TBI)<br />
<br />
[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST), (Name TBI), H'uru<br />
<br />
[[User:Malfhok|Malfhok]] 05:14, 4 February 2012 (MST), (Name TBI), an explorer, (Address TBI)<br />
<br />
[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST), Joseph Davies, H'uru, (Address TBI)<br />
<br />
[[User:Marten|Marten]] 09:44, 5 February 2012 (MST), John Johns, The Great Tree, Guild of Messengers, Washougal, WA<br />
<br />
[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET), (Name TBI)<br />
<br />
[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST), Chloe Rhodes, TheDeepCity.com, (Address TBI)<br />
<br />
[[User:JWPlatt|JWPlatt]] 10:51, 15 February 2012 (EST), Jonathan W. Platt, OpenUru.org, (Address TBI)<br />
<br />
[[User:rarified|rarified]] 14:30, 15 February 2012 (MST), Paul Richards, OpenUru.org, (Address TBI)<br />
<br />
== Additional Information ==<br />
<br />
=== Technical Information on the Localization Example ===<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Additional Examples ===<br />
==== Collider Fixes for PhysX 2.6.4 ====<br />
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:<br />
<br />
[https://github.com/H-uru/Plasma/commit/529ff7982c53410616c62ffb98320e2dd2fd93f4 H-uru/Plasma@529ff79 on GitHub]<br />
<blockquote>'''Band-aid for poorly modelled stairs'''<br><br />
Looks like the Cyan modellers didn't extend the stair ramps all the way<br />
down in some places. To compensate, we can now take higher steps but can't<br />
walk on slopes quite as steep as before. I think this should balance out<br />
nicely.</blockquote><br />
<br />
''More details by Adam Johnson (Hoikas):''<br />
<br />
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.''<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/stairs.jpg http://assets.openuru.org/wiki/general/stairs_tn.jpg]</span><br />
<br />
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.<br />
<br />
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.<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/rocks.jpg http://assets.openuru.org/wiki/general/rocks_tn.jpg]</span><br />
<br />
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).<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/cones.jpg http://assets.openuru.org/wiki/general/cones_tn.jpg]</span><br />
<br />
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.<br />
<br />
''TL;DR: Collision meshes are broken, we must fix them!''<br />
<br />
==== KI Coordinates in Great Zero Courtyard are Backward ====<br />
Issue brought up recently on the MOUL forum that should be easy to fix given a content license:<br />
http://mystonline.com/forums/viewtopic.php?t=25431<br />
<br />
=== License Suggestions ===<br />
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.<br />
<br />
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.</div>JWPlatthttps://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals&diff=1842Cyan Content Licensing Proposals2012-02-19T18:54:33Z<p>JWPlatt: /* Signatures, Open Source Uru Community */ Added Hoikas, Nadnerb signature info</p>
<hr />
<div>== Content Licensing Request ==<br />
=== Introduction ===<br />
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.<br />
<br />
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.<br />
<br />
=== Examples ===<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
=== Community Needs ===<br />
<br />
There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
=== Questions ===<br />
<br />
* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?<br />
<br />
<br />
* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?<br />
<br />
<br />
* Are there specific limitations that fans should place on their hopes for content licensing?<br />
<br />
<br />
* Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?<br />
<br />
<br />
=== Summary ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
This document's history on the wiki: http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals<br />
<br />
Full discussion on the OpenUru.org forums: http://forums.openuru.org/viewtopic.php?f=91&t=635<br />
<br />
<br />
=== Signatures, Open Source Uru Community ===<br />
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST), Lewis Johnston, GULP, (Address TBI)<br />
<br />
[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST), Adam Johnson, GuildOfWriters.org, H'uru, (Address TBI)<br />
<br />
[[User:Branan|Branan]] 21:08, 2 February 2012 (MST), Branan Purvine-Riley, H'uru, (Address TBI)<br />
<br />
[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST), Christian Walther, independent developer, (Address TBI)<br />
<br />
[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST), (Name TBI), GuildOfMessengers.com<br />
<br />
[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST), Ian M. McIntosh, OpenUru.org, (Address TBI)<br />
<br />
[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST), (Name TBI), H'uru<br />
<br />
[[User:Malfhok|Malfhok]] 05:14, 4 February 2012 (MST), (Name TBI), an explorer, (Address TBI)<br />
<br />
[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST)<br />
<br />
[[User:Marten|Marten]] 09:44, 5 February 2012 (MST)<br />
<br />
[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET), (Name TBI)<br />
<br />
[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST), Chloe Rhodes, TheDeepCity.com, (Address TBI)<br />
<br />
[[User:JWPlatt|JWPlatt]] 10:51, 15 February 2012 (EST), Jonathan W. Platt, OpenUru.org, (Address TBI)<br />
<br />
[[User:rarified|rarified]] 14:30, 15 February 2012 (MST), Paul Richards, OpenUru.org, (Address TBI)<br />
<br />
== Additional Information ==<br />
<br />
=== Technical Information on the Localization Example ===<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Additional Examples ===<br />
==== Collider Fixes for PhysX 2.6.4 ====<br />
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:<br />
<br />
[https://github.com/H-uru/Plasma/commit/529ff7982c53410616c62ffb98320e2dd2fd93f4 H-uru/Plasma@529ff79 on GitHub]<br />
<blockquote>'''Band-aid for poorly modelled stairs'''<br><br />
Looks like the Cyan modellers didn't extend the stair ramps all the way<br />
down in some places. To compensate, we can now take higher steps but can't<br />
walk on slopes quite as steep as before. I think this should balance out<br />
nicely.</blockquote><br />
<br />
''More details by Adam Johnson (Hoikas):''<br />
<br />
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.''<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/stairs.jpg http://assets.openuru.org/wiki/general/stairs_tn.jpg]</span><br />
<br />
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.<br />
<br />
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.<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/rocks.jpg http://assets.openuru.org/wiki/general/rocks_tn.jpg]</span><br />
<br />
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).<br />
<br />
<span class="plainlinks">[http://assets.openuru.org/wiki/general/cones.jpg http://assets.openuru.org/wiki/general/cones_tn.jpg]</span><br />
<br />
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.<br />
<br />
''TL;DR: Collision meshes are broken, we must fix them!''<br />
<br />
==== KI Coordinates in Great Zero Courtyard are Backward ====<br />
Issue brought up recently on the MOUL forum that should be easy to fix given a content license:<br />
http://mystonline.com/forums/viewtopic.php?t=25431<br />
<br />
=== License Suggestions ===<br />
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.<br />
<br />
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.</div>JWPlatthttps://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals&diff=1829Cyan Content Licensing Proposals2012-02-18T15:41:09Z<p>JWPlatt: /* Signatures, Open Source Uru Community */ Added D'Lanor name TBI</p>
<hr />
<div>== Content Licensing Request ==<br />
=== Introduction ===<br />
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.<br />
<br />
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.<br />
<br />
=== Examples ===<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
=== Community Needs ===<br />
<br />
There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
=== Questions ===<br />
<br />
* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?<br />
<br />
<br />
* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?<br />
<br />
<br />
* Are there specific limitations that fans should place on their hopes for content licensing?<br />
<br />
<br />
* Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?<br />
<br />
<br />
=== Summary ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
This document's history on the wiki: http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals<br />
<br />
Full discussion on the OpenUru.org forums: http://forums.openuru.org/viewtopic.php?f=91&t=635<br />
<br />
<br />
=== Signatures, Open Source Uru Community ===<br />
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST), Lewis Johnston, GULP, (Address TBI)<br />
<br />
[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST)<br />
<br />
[[User:Branan|Branan]] 21:08, 2 February 2012 (MST)<br />
<br />
[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST), Christian Walther, independent developer, (Address TBI)<br />
<br />
[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST), (Name TBI), GuildOfMessengers.com<br />
<br />
[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST), Ian M. McIntosh, OpenUru.org, (Address TBI)<br />
<br />
[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST)<br />
<br />
[[User:Malfhok|Malfhok]] 05:14, 4 February 2012 (MST), (Name TBI), an explorer, (Address TBI)<br />
<br />
[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST)<br />
<br />
[[User:Marten|Marten]] 09:44, 5 February 2012 (MST)<br />
<br />
[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET), (Name TBI)<br />
<br />
[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST), Chloe Rhodes, TheDeepCity.com, (Address TBI)<br />
<br />
[[User:JWPlatt|JWPlatt]] 10:51, 15 February 2012 (EST), Jonathan W. Platt, OpenUru.org, (Address TBI)<br />
<br />
[[User:rarified|rarified]] 14:30, 15 February 2012 (MST), Paul Richards, OpenUru.org, (Address TBI)<br />
<br />
<hr><br />
<br />
Following is additional technical information.<br />
<br />
=== Technical Information ===<br />
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.<br />
<br />
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.<br />
<br />
An extra note about the alternative suggestion in (2) 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, I anticipate minor bugs such as text flow and sizing in the UI when displaying languages other than the one for which they were 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.<br />
<br />
=== License Suggestions ===<br />
I was going to wrap up by suggesting licenses in order to simplify the burden 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 request, 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.<br />
<br />
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.<br />
<br />
=== Links ===<br />
Forum link: [http://forums.openuru.org/viewtopic.php?f=91&t=635 Content Licensing]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals&diff=1807Cyan Content Licensing Proposals2012-02-16T15:18:44Z<p>JWPlatt: /* Signatures */ Added name of collective for assimilation - resistance is futile</p>
<hr />
<div>== Content Licensing Request ==<br />
=== Introduction ===<br />
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.<br />
<br />
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.<br />
<br />
=== Examples ===<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
=== Community Needs ===<br />
<br />
There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
=== Questions ===<br />
<br />
* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?<br />
<br />
<br />
* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?<br />
<br />
<br />
* Are there specific limitations that fans should place on their hopes for content licensing?<br />
<br />
<br />
* Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?<br />
<br />
<br />
=== Summary ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
This document's history on the wiki: http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals<br />
<br />
Full discussion on the OpenUru.org forums: http://forums.openuru.org/viewtopic.php?f=91&t=635<br />
<br />
<br />
=== Signatures, Open Source Uru Community ===<br />
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST), Lewis Johnston, GULP, (Address TBI)<br />
<br />
[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST)<br />
<br />
[[User:Branan|Branan]] 21:08, 2 February 2012 (MST)<br />
<br />
[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST)<br />
<br />
[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST), (Name TBI), GuildOfMessengers.com<br />
<br />
[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST), Ian M. McIntosh, OpenUru.org, (Address TBI)<br />
<br />
[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST)<br />
<br />
[[User:Malfhok|Malfhok]] 05:14, 4 February 2012 (MST), (Name TBI), an explorer, (Address TBI)<br />
<br />
[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST)<br />
<br />
[[User:Marten|Marten]] 09:44, 5 February 2012 (MST)<br />
<br />
[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET)<br />
<br />
[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST)<br />
<br />
[[User:JWPlatt|JWPlatt]] 10:51, 15 February 2012 (EST), Jonathan W. Platt, OpenUru.org, (Address TBI)<br />
<br />
[[User:rarified|rarified]] 14:30, 15 February 2012 (MST), Paul Richards, OpenUru.org, (Address TBI)<br />
<br />
<hr><br />
<br />
Following is additional technical information.<br />
<br />
=== Technical Information ===<br />
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.<br />
<br />
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.<br />
<br />
An extra note about the alternative suggestion in (2) 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, I anticipate minor bugs such as text flow and sizing in the UI when displaying languages other than the one for which they were 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.<br />
<br />
=== License Suggestions ===<br />
I was going to wrap up by suggesting licenses in order to simplify the burden 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 request, 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.<br />
<br />
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.<br />
<br />
=== Links ===<br />
Forum link: [http://forums.openuru.org/viewtopic.php?f=91&t=635 Content Licensing]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals&diff=1806Cyan Content Licensing Proposals2012-02-16T15:09:20Z<p>JWPlatt: /* Signatures */ Updated To Be Inserted (TBI) info and CamelCase on GoMe</p>
<hr />
<div>== Content Licensing Request ==<br />
=== Introduction ===<br />
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.<br />
<br />
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.<br />
<br />
=== Examples ===<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
=== Community Needs ===<br />
<br />
There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
=== Questions ===<br />
<br />
* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?<br />
<br />
<br />
* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?<br />
<br />
<br />
* Are there specific limitations that fans should place on their hopes for content licensing?<br />
<br />
<br />
* Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?<br />
<br />
<br />
=== Summary ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
This document's history on the wiki: http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals<br />
<br />
Full discussion on the OpenUru.org forums: http://forums.openuru.org/viewtopic.php?f=91&t=635<br />
<br />
<br />
=== Signatures ===<br />
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST), Lewis Johnston, GULP, (Address TBI)<br />
<br />
[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST)<br />
<br />
[[User:Branan|Branan]] 21:08, 2 February 2012 (MST)<br />
<br />
[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST)<br />
<br />
[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST), (Name TBI), GuildOfMessengers.com<br />
<br />
[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST), Ian M. McIntosh, OpenUru.org, (Address TBI)<br />
<br />
[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST)<br />
<br />
[[User:Malfhok|Malfhok]] 05:14, 4 February 2012 (MST), (Name TBI), an explorer, (Address TBI)<br />
<br />
[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST)<br />
<br />
[[User:Marten|Marten]] 09:44, 5 February 2012 (MST)<br />
<br />
[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET)<br />
<br />
[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST)<br />
<br />
[[User:JWPlatt|JWPlatt]] 10:51, 15 February 2012 (EST), Jonathan W. Platt, OpenUru.org, (Address TBI)<br />
<br />
[[User:rarified|rarified]] 14:30, 15 February 2012 (MST), Paul Richards, OpenUru.org, (Address TBI)<br />
<br />
<hr><br />
<br />
Following is additional technical information.<br />
<br />
=== Technical Information ===<br />
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.<br />
<br />
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.<br />
<br />
An extra note about the alternative suggestion in (2) 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, I anticipate minor bugs such as text flow and sizing in the UI when displaying languages other than the one for which they were 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.<br />
<br />
=== License Suggestions ===<br />
I was going to wrap up by suggesting licenses in order to simplify the burden 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 request, 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.<br />
<br />
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.<br />
<br />
=== Links ===<br />
Forum link: [http://forums.openuru.org/viewtopic.php?f=91&t=635 Content Licensing]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Talk:MOSS/Distribution_Specific_Instructions&diff=1798Talk:MOSS/Distribution Specific Instructions2012-02-16T05:13:48Z<p>JWPlatt: /* Notice */</p>
<hr />
<div>== Restructuration ==<br />
<br />
__NOTOC__I suggest changing the structure of this document. Since its title is "Distribution Specific Instructions", I propose that we provide instructions with sections no longer pertaining to the appropriate step, but to the appropriate distribution, e.g.:<br />
== Linux - CentOS ==<br />
== Linux - Ubuntu ==<br />
== MacOS X ==<br />
== NetBSD ==<br />
And so on. I will begin this restructuration tonight, but if anybody feels strongly against it, I will cease. <br />
--[[User:Lyrositor|Lyrositor]] 15:28, 15 February 2012 (MST)<br />
<br />
== Notice ==<br />
<br />
You may have to give folks more time or notify prior authors via PM to give them a chance to respond. They may not watch this page or know to look. Though it makes sense to me.<br />
<br />
----<br />
<br />
This is exceptional, since I see no reason not to do this rework. This is just a notification more than a question or a warning. I was also impatient to start work on this one.<br />
<br />
--[[User:Lyrositor|Lyrositor]] 18:32, 15 February 2012 (MST)<br />
----<br />
If you're going to ask "if anybody feels strongly against it, I will cease," then "anybody" should be given the time and notice, impatience or not. Otherwise, it is insincere. It is a wiki, so anyone is free to edit just as you're doing, but if you are going to ask it should mean something. I like your energy. Make sure your impatience does not impair quality. I do like this organization better.</div>JWPlatthttps://wiki.openuru.org/index.php?title=Talk:MOSS/Distribution_Specific_Instructions&diff=1797Talk:MOSS/Distribution Specific Instructions2012-02-16T04:56:39Z<p>JWPlatt: /* Notice */</p>
<hr />
<div>== Restructuration ==<br />
<br />
__NOTOC__I suggest changing the structure of this document. Since its title is "Distribution Specific Instructions", I propose that we provide instructions with sections no longer pertaining to the appropriate step, but to the appropriate distribution, e.g.:<br />
== Linux - CentOS ==<br />
== Linux - Ubuntu ==<br />
== MacOS X ==<br />
== NetBSD ==<br />
And so on. I will begin this restructuration tonight, but if anybody feels strongly against it, I will cease. <br />
--[[User:Lyrositor|Lyrositor]] 15:28, 15 February 2012 (MST)<br />
<br />
== Notice ==<br />
<br />
You may have to give folks more time or notify prior authors via PM to give them a chance to respond. They may not watch this page or know to look. Though it makes sense to me.<br />
<br />
----<br />
<br />
This is exceptional, since I see no reason not to do this rework. This is just a notification more than a question or a warning. I was also impatient to start work on this one.<br />
<br />
--[[User:Lyrositor|Lyrositor]] 18:32, 15 February 2012 (MST)<br />
----<br />
If you're going to ask "if anybody feels strongly against it, I will cease," then "anybody" should be given the time and notice, impatience or not. Otherwise, it is insincere. It is a wiki, so anyone is free to edit just as you're doing, but if you are going to ask it should mean something. I like your energy. Make sure your impatience does not impair quality.</div>JWPlatthttps://wiki.openuru.org/index.php?title=Talk:MOSS/Distribution_Specific_Instructions&diff=1790Talk:MOSS/Distribution Specific Instructions2012-02-16T00:57:26Z<p>JWPlatt: /* Notice */</p>
<hr />
<div>== Restructuration ==<br />
<br />
__NOTOC__I suggest changing the structure of this document. Since its title is "Distribution Specific Instructions", I propose that we provide instructions with sections no longer pertaining to the appropriate step, but to the appropriate distribution, e.g.:<br />
== Linux - CentOS ==<br />
== Linux - Ubuntu ==<br />
== MacOS X ==<br />
== NetBSD ==<br />
And so on. I will begin this restructuration tonight, but if anybody feels strongly against it, I will cease. <br />
--[[User:Lyrositor|Lyrositor]] 15:28, 15 February 2012 (MST)<br />
<br />
== Notice ==<br />
<br />
You may have to give folks more time or notify prior authors via PM to give them a chance to respond. They may not watch this page or know to look. Though it makes sense to me.</div>JWPlatthttps://wiki.openuru.org/index.php?title=Talk:MOSS/Distribution_Specific_Instructions&diff=1789Talk:MOSS/Distribution Specific Instructions2012-02-16T00:56:32Z<p>JWPlatt: /* Notice */ new section</p>
<hr />
<div>== Restructuration ==<br />
<br />
__NOTOC__I suggest changing the structure of this document. Since its title is "Distribution Specific Instructions", I propose that we provide instructions with sections no longer pertaining to the appropriate step, but to the appropriate distribution, e.g.:<br />
== Linux - CentOS ==<br />
== Linux - Ubuntu ==<br />
== MacOS X ==<br />
== NetBSD ==<br />
And so on. I will begin this restructuration tonight, but if anybody feels strongly against it, I will cease. <br />
--[[User:Lyrositor|Lyrositor]] 15:28, 15 February 2012 (MST)<br />
<br />
== Notice ==<br />
<br />
You may have to give folks more time or notify prior authors via PM to give them a chance to respond. They may not watch this page or know to look.</div>JWPlatthttps://wiki.openuru.org/index.php?title=User:JWPlatt&diff=1782User:JWPlatt2012-02-15T16:35:04Z<p>JWPlatt: /* Legacy */ Stupid typos, irrelevant stuff</p>
<hr />
<div>===Legacy ===<br />
<br />
* Rode in on thesis of "Manufactured Divisions" at DRCSite.org during Until Uru<br />
* Participated on Cyan Worlds' D'mala shard leading into GameTap MOUL<br />
* Attended MOUL's "A Beginner's Bevin" nightly, mostly to abuse the ResEngs with snarky humor<br />
* Suggested Ladies Night for ResEng Lambert when he said women scared him - all part of the snarky humor: http://www.facebook.com/video/video.php?v=14151359007<br />
* Founded Pellet Points Hood, got agreement from Mr. Laxman to get and report daily pellet points from Dr. Watson<br />
* Helped bring MagiQuest Online development to Cyan Worlds for Creative Kingdoms - credited for Database Integration, but it had to be short; did lots more<br />
* Co-founded OpenUru.org for the purpose of reviving MOUL and bringing open source to the Myst Online: Uru Live community<br />
* Trekkie, frisbee, nature, hiking, camping, t-shirts, cut my own hair, prep school and college graduate, software developer, pain in the butt</div>JWPlatthttps://wiki.openuru.org/index.php?title=User:JWPlatt&diff=1781User:JWPlatt2012-02-15T16:24:00Z<p>JWPlatt: </p>
<hr />
<div>===Legacy ===<br />
<br />
* Rode in on thesis of "Manufactured Divisions" at DRCSite.org during Until Uru<br />
* Participated on Cyan Worlds' D'mala shard leading into GameTap MOUL<br />
* Attended MOUL's "A Beginner's Bevin" nightly, mostly to abuse the ResEngs with snarky humor<br />
* Suggested Ladies Night for ResEng Lambert when he said women scared him - all part of the snarky humor: http://www.facebook.com/video/video.php?v=14151359007<br />
* Founded Pellet Points Hood, got agreement frmo Mr. Laxman to get and report daily pellet points from Dr. Watson<br />
* Helped bring MagiQuest Online development to Cyan Worlds for Creative Kingdoms - credited for Database Integration, but it had to be short; did lots more<br />
* Co-founded OpenUru.org for the purpose of reviving MOUL and bringing open source to the Myst Online: Uru Live community</div>JWPlatthttps://wiki.openuru.org/index.php?title=User:JWPlatt&diff=1780User:JWPlatt2012-02-15T16:06:50Z<p>JWPlatt: /* Legacy */</p>
<hr />
<div>===Legacy ===<br />
<br />
* Rode in on thesis of "Manufactured Divisions" at DRCSite.org <br />
* Attended "A Beginner's Bevin" nightly, mostly to abuse the ResEngs<br />
* Founded Pellet Points Hood, got agreement frmo Mr. Laxman to get and report daily pellet points from Dr. Watson<br />
* Helped bring MagiQuest Online development to Cyan Worlds for Creative Kingdoms - credited for Database Integration, but it had to be short; did lots more<br />
* Co-founded OpenUru.org for the purpose of reviving MOUL and bringing open source to the Myst Online: Uru Live community</div>JWPlatthttps://wiki.openuru.org/index.php?title=User:JWPlatt&diff=1779User:JWPlatt2012-02-15T16:05:40Z<p>JWPlatt: Eh, I wanted my username in blue instead of red</p>
<hr />
<div>===Legacy ===<br />
<br />
* Rode in on thesis of "Manufactured Divisions" at DRCSite.org <br />
* Attended "A Beginner's Bevin" nightly, mostly to abuse the ResEngs<br />
* Founded Pellet Points Hood, got agreement frmo Mr. Laxman to get and report daily pellet points from Dr. Watson<br />
* Helped bring MagiQuest Online development to Cyan Worlds for Creative Kingdoms - credited for Database Integration, but it had to be short; did lots more<br />
* Co-founded OpenUru.org</div>JWPlatthttps://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals&diff=1777Cyan Content Licensing Proposals2012-02-15T15:55:14Z<p>JWPlatt: /* Signatures */ Name, TimeStamp, Affiliation, Address</p>
<hr />
<div>== Content Licensing Request ==<br />
=== Introduction ===<br />
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.<br />
<br />
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.<br />
<br />
<br />
=== Examples ===<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
=== Community Needs ===<br />
<br />
There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
=== Questions ===<br />
<br />
* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?<br />
<br />
<br />
* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?<br />
<br />
<br />
* Are there specific limitations that fans should place on their hopes for content licensing?<br />
<br />
<br />
* Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?<br />
<br />
<br />
=== Summary ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
This document's history on the wiki: http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals<br />
<br />
Full discussion on the OpenUru.org forums: http://forums.openuru.org/viewtopic.php?f=91&t=635<br />
<br />
<br />
=== Signatures ===<br />
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST)<br />
<br />
[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST)<br />
<br />
[[User:Branan|Branan]] 21:08, 2 February 2012 (MST)<br />
<br />
[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST)<br />
<br />
[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST)<br />
<br />
[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST)<br />
<br />
[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST)<br />
<br />
[[User:Malfhok|Malfhok]], an explorer 05:14, 4 February 2012 (MST)<br />
<br />
[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST)<br />
<br />
[[User:Marten|Marten]] 09:44, 5 February 2012 (MST)<br />
<br />
[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET)<br />
<br />
[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST)<br />
<br />
[[User:JWPlatt|JWPlatt]] 10:51, 15 February 2012 (EST), Jonathan W. Platt, OpenUru.org, (Address TBI)<br />
<hr><br />
<br />
Following is additional technical information.<br />
<br />
=== Technical Information ===<br />
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.<br />
<br />
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.<br />
<br />
An extra note about the alternative suggestion in (2) 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, I anticipate minor bugs such as text flow and sizing in the UI when displaying languages other than the one for which they were 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.<br />
<br />
=== License Suggestions ===<br />
I was going to wrap up by suggesting licenses in order to simplify the burden 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 request, 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.<br />
<br />
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.<br />
<br />
=== Links ===<br />
Forum link: [http://forums.openuru.org/viewtopic.php?f=91&t=635 Content Licensing]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals&diff=1776Cyan Content Licensing Proposals2012-02-15T15:54:08Z<p>JWPlatt: /* Signatures */</p>
<hr />
<div>== Content Licensing Request ==<br />
=== Introduction ===<br />
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.<br />
<br />
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.<br />
<br />
<br />
=== Examples ===<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
=== Community Needs ===<br />
<br />
There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
=== Questions ===<br />
<br />
* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?<br />
<br />
<br />
* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?<br />
<br />
<br />
* Are there specific limitations that fans should place on their hopes for content licensing?<br />
<br />
<br />
* Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?<br />
<br />
<br />
=== Summary ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
This document's history on the wiki: http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals<br />
<br />
Full discussion on the OpenUru.org forums: http://forums.openuru.org/viewtopic.php?f=91&t=635<br />
<br />
<br />
=== Signatures ===<br />
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST)<br />
<br />
[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST)<br />
<br />
[[User:Branan|Branan]] 21:08, 2 February 2012 (MST)<br />
<br />
[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST)<br />
<br />
[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST)<br />
<br />
[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST)<br />
<br />
[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST)<br />
<br />
[[User:Malfhok|Malfhok]], an explorer 05:14, 4 February 2012 (MST)<br />
<br />
[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST)<br />
<br />
[[User:Marten|Marten]] 09:44, 5 February 2012 (MST)<br />
<br />
[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET)<br />
<br />
[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST)<br />
<br />
[[User:JWPlatt|JWPlatt]] 10:51, 15 February 2012 (EST), Jonathan Platt, OpenUru.org, (Address TBI)<br />
<hr><br />
<br />
Following is additional technical information.<br />
<br />
=== Technical Information ===<br />
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.<br />
<br />
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.<br />
<br />
An extra note about the alternative suggestion in (2) 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, I anticipate minor bugs such as text flow and sizing in the UI when displaying languages other than the one for which they were 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.<br />
<br />
=== License Suggestions ===<br />
I was going to wrap up by suggesting licenses in order to simplify the burden 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 request, 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.<br />
<br />
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.<br />
<br />
=== Links ===<br />
Forum link: [http://forums.openuru.org/viewtopic.php?f=91&t=635 Content Licensing]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals&diff=1775Cyan Content Licensing Proposals2012-02-15T15:39:55Z<p>JWPlatt: Add new body text to intro, examples, questions and summary</p>
<hr />
<div>== Content Licensing Request ==<br />
=== Introduction ===<br />
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.<br />
<br />
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.<br />
<br />
<br />
=== Examples ===<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
=== Community Needs ===<br />
<br />
There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
=== Questions ===<br />
<br />
* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?<br />
<br />
<br />
* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?<br />
<br />
<br />
* Are there specific limitations that fans should place on their hopes for content licensing?<br />
<br />
<br />
* Can Cyan Worlds indicate if unreleasable content will become available in the future or under other circumstances?<br />
<br />
<br />
=== Summary ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
This document's history on the wiki: http://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals<br />
<br />
Full discussion on the OpenUru.org forums: http://forums.openuru.org/viewtopic.php?f=91&t=635<br />
<br />
<br />
=== Signatures ===<br />
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST)<br />
<br />
[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST)<br />
<br />
[[User:Branan|Branan]] 21:08, 2 February 2012 (MST)<br />
<br />
[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST)<br />
<br />
[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST)<br />
<br />
[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST)<br />
<br />
[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST)<br />
<br />
[[User:Malfhok|Malfhok]], an explorer 05:14, 4 February 2012 (MST)<br />
<br />
[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST)<br />
<br />
[[User:Marten|Marten]] 09:44, 5 February 2012 (MST)<br />
<br />
[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET)<br />
<br />
[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST)<br />
<hr><br />
<br />
Following is additional technical information.<br />
<br />
=== Technical Information ===<br />
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.<br />
<br />
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.<br />
<br />
An extra note about the alternative suggestion in (2) 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, I anticipate minor bugs such as text flow and sizing in the UI when displaying languages other than the one for which they were 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.<br />
<br />
=== License Suggestions ===<br />
I was going to wrap up by suggesting licenses in order to simplify the burden 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 request, 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.<br />
<br />
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.<br />
<br />
=== Links ===<br />
Forum link: [http://forums.openuru.org/viewtopic.php?f=91&t=635 Content Licensing]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Cyan_Content_Licensing_Proposals&diff=1773Cyan Content Licensing Proposals2012-02-15T15:30:32Z<p>JWPlatt: /* Localization Licensing Request */ Format and language edits to existing letter body content</p>
<hr />
<div>== Content Licensing Request ==<br />
=== Introduction ===<br />
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.<br />
<br />
<br />
=== Examples ===<br />
<br />
* 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 and has done Unicode development to allow non-US keyboards.<br />
<br />
<br />
=== Community Needs ===<br />
<br />
There are two primary allowances we need from Cyan Worlds to continue efforts to expand MOULa's accessibility:<br />
<br />
* 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.<br />
<br />
<br />
* 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.<br />
<br />
<br />
=== Questions ===<br />
<br />
* Is Cyan Worlds able to indicate what difficulties there are in licensing MOULa content?<br />
<br />
<br />
* Are there any particular aspects to content release issues where Cyan Worlds is open to suggestions?<br />
<br />
<br />
* Are there specific limitations that fans should place on their hopes for content licensing?<br />
<br />
<br />
=== Summary ===<br />
<br />
We are not asking for a final solution for this specific case yet, but we are presenting a specific case in the hope that it will be helpful as a first step on the collaborative path to a general solution.<br />
<br />
Thank you for reading and considering this request.<br />
<br />
==== Signatures ====<br />
[[User:OHB|OHB]] 19:24, 2 February 2012 (MST)<br />
<br />
[[User:Hoikas|Hoikas]] 19:31, 2 February 2012 (MST)<br />
<br />
[[User:Branan|Branan]] 21:08, 2 February 2012 (MST)<br />
<br />
[[User:Christian Walther|Christian Walther]] 05:28, 3 February 2012 (MST)<br />
<br />
[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST)<br />
<br />
[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST)<br />
<br />
[[User:Nadnerb|Nadnerb]] 14:36, 3 February 2012 (MST)<br />
<br />
[[User:Malfhok|Malfhok]], an explorer 05:14, 4 February 2012 (MST)<br />
<br />
[[User:Deledrius|Deledrius]] 08:57, 4 February 2012 (MST)<br />
<br />
[[User:Marten|Marten]] 09:44, 5 February 2012 (MST)<br />
<br />
[[User:D'Lanor|D'Lanor]] 00:00, 8 February 2012 (CET)<br />
<br />
[[User:GPNMilano|GPNMilano]] 23:36, 8 February 2012 (MST)<br />
<hr><br />
<br />
Following is additional technical information.<br />
<br />
=== Technical Information ===<br />
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.<br />
<br />
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.<br />
<br />
An extra note about the alternative suggestion in (2) 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, I anticipate minor bugs such as text flow and sizing in the UI when displaying languages other than the one for which they were 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.<br />
<br />
=== License Suggestions ===<br />
I was going to wrap up by suggesting licenses in order to simplify the burden 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 request, 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.<br />
<br />
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.<br />
<br />
=== Links ===<br />
Forum link: [http://forums.openuru.org/viewtopic.php?f=91&t=635 Content Licensing]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Install_Repository&diff=571Install Repository2010-04-15T06:39:11Z<p>JWPlatt: /* Blue Host 64-bit shared servers */</p>
<hr />
<div>This page intentionally orphaned for now.<br />
<br />
{{tech-stub}}<br />
<br />
== Install Repository ==<br />
<br />
Here's how if you want to grow your own repository.<br />
<br />
== Repositories ==<br />
<br />
=== Subversion ===<br />
<br />
==== Install ====<br />
<br />
===== Blue Host 64-bit shared servers =====<br />
<br />
Looks like a really good start-to-finish tutorial here:<br />
http://www.tabruyn.com/site/index.php?option=com_content&view=article&id=55:tortoisesvn-subversion-and-bluehost&catid=36:digital&Itemid=58<br />
<br />
This is the procedure that actually worked:<br />
http://netsperience.org/content/installing-subversion-151-a-shared-host-ssh-commands<br />
<br />
These instructions were originally found at:<br />
http://www.bluehostforum.com/showpost.php?p=51455&postcount=19<br />
<br />
They are based upon a more general article at:<br />
http://joemaller.com/2008/01/29/how-to-install-subversion-on-a-shared-host/<br />
<br />
Unconfirmed alternative:<br />
http://www.bluehostforum.com/showthread.php?t=12099&page=3 (last post)<br />
<br />
If Blue Host does an update that clobbers the install:<br />
http://liwen.name/2009/06/save-subversion-server-on-bluehost/<br />
<br />
<br />
Connect to your account with ssh<br />
<br />
Replace zzzzz with your username in these commands:<br />
<br />
mkdir _src<br />
cd _src<br />
wget http://subversion.tigris.org/downloads/subversion-1.4.6.tar.gz<br />
wget http://subversion.tigris.org/downloads/subversion-deps-1.4.6.tar.gz<br />
tar -xzvf subversion-1.4.6.tar.gz<br />
tar -xzvf subversion-deps-1.4.6.tar.gz<br />
cd subversion-1.4.6<br />
cd apr<br />
./configure --enable-shared --prefix=$HOME<br />
make && make install<br />
cd ../apr-util<br />
./configure --enable-shared --prefix=$HOME \<br />
--with-expat=builtin --with-apr=$HOME \<br />
--without-berlekey-db<br />
make && make install<br />
cd ../neon<br />
EXTRA_CFLAGS="-L/usr/lib64 -fPIC"<br />
CFLAGS="-L/usr/lib64 -fPIC"<br />
./configure --prefix=/home/zzzzz/system --enable-shared<br />
make && make install<br />
cd ..<br />
./configure --prefix=/home/zzzzz/system --with-expat=builtin<br />
make && make install<br />
<br />
<br />
Then you need to edit .bash_profile to add /system/bin to your path. From your home folder:<br />
<br />
nano -w .bash_profile<br />
<br />
Replace:<br />
PATH=$PATH:$HOME/bin<br />
<br />
With:<br />
PATH=$PATH:$HOME/bin:$HOME/system/bin<br />
<br />
You will need to logout of your session, and then log in again. Subversion should now be working.</div>JWPlatthttps://wiki.openuru.org/index.php?title=Cyan_Worlds_Sources_And_Tools&diff=570Cyan Worlds Sources And Tools2010-04-07T01:44:57Z<p>JWPlatt: /* Download */</p>
<hr />
<div>{{UruDocProj}}<br />
{{design-stub}}<br />
This plug-in is for [http://en.wikipedia.org/wiki/Autodesk_3ds_Max Autodesk 3ds Max]<ref name="3ds">[http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=13567410 Autodesk 3ds Max - 3D Modeling, Animation, and Rendering Software]</ref> version 7 and is compatible with MOULagain client build 1.871. This plug-in is reported to work with 3ds Max version 8, but <u>not</u> with any later versions.<br />
<br />
== Download ==<br />
The binaries and documentation for the plug-in are currently available from two authorized sources:<br />
<br />
<u>Binaries</u><br />
<br />
{{Pad}}From [http://assets.OpenURU.org/cyan/MOULaPlugins871.zip OpenURU.org]<br />
<br />
{{Pad}}From [http://cho.cyan.com/bahrowings/MOULaPlugins871.zip Cyan Worlds]<br />
<br />
<u>Documentation</u><br />
<br />
{{Pad}}From [http://assets.OpenURU.org/cyan/PlasmaPlugins.doc OpenURU.org]<br />
<br />
{{Pad}}From [http://cho.cyan.com/bahrowings/PlasmaPlugins.doc Cyan Worlds]<br />
<br />
== Installation ==<br />
{{draft}}<br />
{{tba}}<br />
OpenUru.org documentation to follow.<br />
There are installation instructions currently on the [http://www.guildofwriters.com Guild of Writers website].<br />
<br />
== Usage ==<br />
{{tba}}<br />
OpenUru.org documentation to follow.<br />
There are usage instructions currently on the [http://www.guildofwriters.com Guild of Writers website].<br />
A series of illustrated tutorials is being developed on the [http://www.guildofmaintainers.org/Forum/viewforum.php?f=154 Guild of Maintainers forum].<br />
<br />
'''References and citations:'''<br />
<references/></div>JWPlatthttps://wiki.openuru.org/index.php?title=Install_Repository&diff=567Install Repository2010-04-01T04:08:12Z<p>JWPlatt: /* Blue Host 64-bit shared servers */</p>
<hr />
<div>This page intentionally orphaned for now.<br />
<br />
= Install Repository =<br />
<br />
Here's how if you want to grow your own repository.<br />
<br />
== Repositories ==<br />
<br />
=== Subversion ===<br />
<br />
==== Install ====<br />
<br />
===== Blue Host 64-bit shared servers =====<br />
<br />
Looks like a really good start-to-finish tutorial here:<br />
http://www.tabruyn.com/site/index.php?option=com_content&view=article&id=55:tortoisesvn-subversion-and-bluehost&catid=36:digital&Itemid=58<br />
<br />
These instructions were originally found at:<br />
http://www.bluehostforum.com/showpost.php?p=51455&postcount=19<br />
<br />
They are based upon a more general article at:<br />
http://joemaller.com/2008/01/29/how-to-install-subversion-on-a-shared-host/<br />
<br />
Unconfirmed alternative:<br />
http://www.bluehostforum.com/showthread.php?t=12099&page=3 (last post)<br />
<br />
If Blue Host does an update that clobbers the install:<br />
http://liwen.name/2009/06/save-subversion-server-on-bluehost/<br />
<br />
<br />
Connect to your account with ssh<br />
<br />
Replace zzzzz with your username in these commands:<br />
<br />
mkdir _src<br />
cd _src<br />
wget http://subversion.tigris.org/downloads/subversion-1.4.6.tar.gz<br />
wget http://subversion.tigris.org/downloads/subversion-deps-1.4.6.tar.gz<br />
tar -xzvf subversion-1.4.6.tar.gz<br />
tar -xzvf subversion-deps-1.4.6.tar.gz<br />
cd subversion-1.4.6<br />
cd apr<br />
./configure --enable-shared --prefix=$HOME<br />
make && make install<br />
cd ../apr-util<br />
./configure --enable-shared --prefix=$HOME \<br />
--with-expat=builtin --with-apr=$HOME \<br />
--without-berlekey-db<br />
make && make install<br />
cd ../neon<br />
EXTRA_CFLAGS="-L/usr/lib64 -fPIC"<br />
CFLAGS="-L/usr/lib64 -fPIC"<br />
./configure --prefix=/home/zzzzz/system --enable-shared<br />
make && make install<br />
cd ..<br />
./configure --prefix=/home/zzzzz/system --with-expat=builtin<br />
make && make install<br />
<br />
<br />
Then you need to edit .bash_profile to add /system/bin to your path. From your home folder:<br />
<br />
nano -w .bash_profile<br />
<br />
Replace:<br />
PATH=$PATH:$HOME/bin<br />
<br />
With:<br />
PATH=$PATH:$HOME/bin:$HOME/system/bin<br />
<br />
You will need to logout of your session, and then log in again. Subversion should now be working.</div>JWPlatthttps://wiki.openuru.org/index.php?title=Install_Repository&diff=566Install Repository2010-04-01T04:01:49Z<p>JWPlatt: /* Blue Host 64-bit shared servers */</p>
<hr />
<div>This page intentionally orphaned for now.<br />
<br />
= Install Repository =<br />
<br />
Here's how if you want to grow your own repository.<br />
<br />
== Repositories ==<br />
<br />
=== Subversion ===<br />
<br />
==== Install ====<br />
<br />
===== Blue Host 64-bit shared servers =====<br />
<br />
These instructions were originally found at:<br />
http://www.bluehostforum.com/showpost.php?p=51455&postcount=19<br />
<br />
They are based upon a more general article at:<br />
http://joemaller.com/2008/01/29/how-to-install-subversion-on-a-shared-host/<br />
<br />
Unconfirmed alternative:<br />
http://www.bluehostforum.com/showthread.php?t=12099&page=3 (last post)<br />
<br />
If Blue Host does an update that clobbers the install:<br />
http://liwen.name/2009/06/save-subversion-server-on-bluehost/<br />
<br />
<br />
Connect to your account with ssh<br />
<br />
Replace zzzzz with your username in these commands:<br />
<br />
mkdir _src<br />
cd _src<br />
wget http://subversion.tigris.org/downloads/subversion-1.4.6.tar.gz<br />
wget http://subversion.tigris.org/downloads/subversion-deps-1.4.6.tar.gz<br />
tar -xzvf subversion-1.4.6.tar.gz<br />
tar -xzvf subversion-deps-1.4.6.tar.gz<br />
cd subversion-1.4.6<br />
cd apr<br />
./configure --enable-shared --prefix=$HOME<br />
make && make install<br />
cd ../apr-util<br />
./configure --enable-shared --prefix=$HOME \<br />
--with-expat=builtin --with-apr=$HOME \<br />
--without-berlekey-db<br />
make && make install<br />
cd ../neon<br />
EXTRA_CFLAGS="-L/usr/lib64 -fPIC"<br />
CFLAGS="-L/usr/lib64 -fPIC"<br />
./configure --prefix=/home/zzzzz/system --enable-shared<br />
make && make install<br />
cd ..<br />
./configure --prefix=/home/zzzzz/system --with-expat=builtin<br />
make && make install<br />
<br />
<br />
Then you need to edit .bash_profile to add /system/bin to your path. From your home folder:<br />
<br />
nano -w .bash_profile<br />
<br />
Replace:<br />
PATH=$PATH:$HOME/bin<br />
<br />
With:<br />
PATH=$PATH:$HOME/bin:$HOME/system/bin<br />
<br />
You will need to logout of your session, and then log in again. Subversion should now be working.</div>JWPlatthttps://wiki.openuru.org/index.php?title=Install_Repository&diff=565Install Repository2010-04-01T03:59:46Z<p>JWPlatt: </p>
<hr />
<div>This page intentionally orphaned for now.<br />
<br />
= Install Repository =<br />
<br />
Here's how if you want to grow your own repository.<br />
<br />
== Repositories ==<br />
<br />
=== Subversion ===<br />
<br />
==== Install ====<br />
<br />
===== Blue Host 64-bit shared servers =====<br />
<br />
These instructions were originally found at:<br />
http://www.bluehostforum.com/showpost.php?p=51455&postcount=19<br />
<br />
They are based upon a more general article at:<br />
http://joemaller.com/2008/01/29/how-to-install-subversion-on-a-shared-host/<br />
<br />
Unconfirmed alternative:<br />
http://www.bluehostforum.com/showthread.php?t=12099&page=3 (last post)<br />
<br />
<br />
Connect to your account with ssh<br />
<br />
Replace zzzzz with your username in these commands:<br />
<br />
mkdir _src<br />
cd _src<br />
wget http://subversion.tigris.org/downloads/subversion-1.4.6.tar.gz<br />
wget http://subversion.tigris.org/downloads/subversion-deps-1.4.6.tar.gz<br />
tar -xzvf subversion-1.4.6.tar.gz<br />
tar -xzvf subversion-deps-1.4.6.tar.gz<br />
cd subversion-1.4.6<br />
cd apr<br />
./configure --enable-shared --prefix=$HOME<br />
make && make install<br />
cd ../apr-util<br />
./configure --enable-shared --prefix=$HOME \<br />
--with-expat=builtin --with-apr=$HOME \<br />
--without-berlekey-db<br />
make && make install<br />
cd ../neon<br />
EXTRA_CFLAGS="-L/usr/lib64 -fPIC"<br />
CFLAGS="-L/usr/lib64 -fPIC"<br />
./configure --prefix=/home/zzzzz/system --enable-shared<br />
make && make install<br />
cd ..<br />
./configure --prefix=/home/zzzzz/system --with-expat=builtin<br />
make && make install<br />
<br />
<br />
Then you need to edit .bash_profile to add /system/bin to your path. From your home folder:<br />
<br />
nano -w .bash_profile<br />
<br />
Replace:<br />
PATH=$PATH:$HOME/bin<br />
<br />
With:<br />
PATH=$PATH:$HOME/bin:$HOME/system/bin<br />
<br />
You will need to logout of your session, and then log in again. Subversion should now be working.</div>JWPlatthttps://wiki.openuru.org/index.php?title=Install_Repository&diff=564Install Repository2010-04-01T03:30:58Z<p>JWPlatt: Install a repository</p>
<hr />
<div>This page intentionally orphaned for now.<br />
<br />
= Install Repository =<br />
<br />
Here's how if you want to grow your own repository.<br />
<br />
== Repositories ==<br />
<br />
=== Subversion ===<br />
<br />
==== Install ====<br />
<br />
===== Blue Host 64-bit shared servers =====<br />
<br />
These instructions were originally found at:<br />
http://www.bluehostforum.com/showpost.php?p=51455&postcount=19<br />
<br />
They are based upon a more general article at:<br />
http://joemaller.com/2008/01/29/how-to-install-subversion-on-a-shared-host/<br />
<br />
<br />
Connect to your account with ssh<br />
<br />
Replace zzzzz with your username in these commands:<br />
<br />
mkdir _src<br />
cd _src<br />
wget http://subversion.tigris.org/downloads/subversion-1.4.6.tar.gz<br />
wget http://subversion.tigris.org/downloads/subversion-deps-1.4.6.tar.gz<br />
tar -xzvf subversion-1.4.6.tar.gz<br />
tar -xzvf subversion-deps-1.4.6.tar.gz<br />
cd subversion-1.4.6<br />
cd apr<br />
./configure --enable-shared --prefix=$HOME<br />
make && make install<br />
cd ../apr-util<br />
./configure --enable-shared --prefix=$HOME \<br />
--with-expat=builtin --with-apr=$HOME \<br />
--without-berlekey-db<br />
make && make install<br />
cd ../neon<br />
EXTRA_CFLAGS="-L/usr/lib64 -fPIC"<br />
CFLAGS="-L/usr/lib64 -fPIC"<br />
./configure --prefix=/home/zzzzz/system --enable-shared<br />
make && make install<br />
cd ..<br />
./configure --prefix=/home/zzzzz/system --with-expat=builtin<br />
make && make install<br />
<br />
<br />
Then you need to edit .bash_profile to add /system/bin to your path. From your home folder:<br />
<br />
nano -w .bash_profile<br />
<br />
Replace:<br />
PATH=$PATH:$HOME/bin<br />
<br />
With:<br />
PATH=$PATH:$HOME/bin:$HOME/system/bin<br />
<br />
You will need to logout of your session, and then log in again. Subversion should now be working.</div>JWPlatthttps://wiki.openuru.org/index.php?title=Projects_and_Resources&diff=465Projects and Resources2010-02-01T01:01:36Z<p>JWPlatt: </p>
<hr />
<div>{{draft}}<br />
Sample of an index to articles on Projects and Resources on the OpenURU.org site (and elsewhere?)<br />
<br />
<!-- Keep thing simple here! Avoid unnecessary wiki markup between the INC tags. --><br />
<!--INC-->== Info & HowTo On OpenURU.org ==<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewtopic.php?f=5&t=164 How to request a new project]<!--/INC--><br />
<br />
<br />
<!--INC-->== Projects On OpenURU.org ==<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=17 System Concepts]<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=20 Building & Testing]<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=20 Building & Testing]<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=47 Myst/Uru-Style Hypergrid & Open Simulators]<!--/INC--><br />
* <!--INC-->[[David's Journey]]<!--/INC--><br />
* <!--INC-->[[SD&D_Overview|Standards For Discussion & Debate]]<!--/INC--><br />
* <!--inc-->Just some text<!--/inc--> <!-- A bit without a link, and with lower case tags --><br />
<br />
<br />
An example of <!--inc-->'''''some bold italic text taken out of context'''''<!--/inc--> just to show that it can work.<br />
<br />
<!-- Do not edit --><br />
[[Category:OpenUru.org]]<br />
[[Category:Documentation]]<br />
[[Category:Age Projects]]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Projects_and_Resources&diff=458Projects and Resources2010-01-25T18:45:14Z<p>JWPlatt: </p>
<hr />
<div>{{draft}}<br />
Sample of an index to articles on Projects and Resources on the OpenURU.org site (and elsewhere?)<br />
<br />
<!-- Keep thing simple here! Avoid unnecessary wiki markup between the INC tags. --><br />
<!--INC-->== Info & HowTo On OpenURU.org ==<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewtopic.php?f=5&t=164 How to request a new project]<!--/INC--><br />
<br />
<br />
<!--INC-->== Projects On OpenURU.org ==<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=17 System Concepts]<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=20 Building & Testing]<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=34 Writers Club]<!--/INC--><br />
* <!--INC-->[[David's Journey]]<!--/INC--><br />
* <!--INC-->[[SD&D_Overview|Standards For Discussion & Debate]]<!--/INC--><br />
* <!--inc-->Just some text<!--/inc--> <!-- A bit without a link, and with lower case tags --><br />
<br />
<br />
An example of <!--inc-->'''''some bold italic text taken out of context'''''<!--/inc--> just to show that it can work.<br />
<br />
<!-- Do not edit --><br />
[[Category:OpenUru.org]]<br />
[[Category:Documentation]]<br />
[[Category:Age Projects]]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Projects_and_Resources&diff=457Projects and Resources2010-01-25T18:37:20Z<p>JWPlatt: </p>
<hr />
<div>{{draft}}<br />
Sample of an index to articles on Projects and Resources on the OpenURU.org site (and elsewhere?)<br />
<br />
<!-- Keep thing simple here! Avoid unnecessary wiki markup between the INC tags. --><br />
<!--INC-->== Info & HowTo On OpenURU.org ==<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewtopic.php?f=5&t=164 How to request a new project]<!--/INC--><br />
<br />
<br />
<!--INC-->== Projects On OpenURU.org ==<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=17 System Concepts]<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=20 Building & Testing]<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=34 Writers Club]<!--/INC--><br />
* <!--INC-->[[David's Journey]]<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=46 Standards For Discussion & Debate]<!--/INC--><br />
* <!--inc-->Just some text<!--/inc--> <!-- A bit without a link, and with lower case tags --><br />
<br />
<br />
An example of <!--inc-->'''''some bold italic text taken out of context'''''<!--/inc--> just to show that it can work.<br />
<br />
<!-- Do not edit --><br />
[[Category:OpenUru.org]]<br />
[[Category:Documentation]]<br />
[[Category:Age Projects]]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Projects_and_Resources&diff=456Projects and Resources2010-01-25T18:35:03Z<p>JWPlatt: </p>
<hr />
<div>{{draft}}<br />
Sample of an index to articles on Projects and Resources on the OpenURU.org site (and elsewhere?)<br />
<br />
<!-- Keep thing simple here! Avoid unnecessary wiki markup between the INC tags. --><br />
<!--INC-->== Info & HowTo On OpenURU.org ==<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewtopic.php?f=5&t=164 How to request a new project]<!--/INC--><br />
<br />
<br />
<!--INC-->== Projects On OpenURU.org ==<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=17 System Concepts]<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=20 Building & Testing]<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=34 Writers Club]<!--/INC--><br />
* <!--INC-->[[David's Journey]]<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=46 Standards For Discussion & Debate]<!--/INC--><br />
* <!--inc-->Just some text<!--/inc--> <!-- A bit without a link, and with lower case tags --><br />
An example of <!--inc-->'''''some bold italic text taken out of context'''''<!--/inc--> just to show that it can work.<br />
<br />
<!-- Do not edit --><br />
[[Category:OpenUru.org]]<br />
[[Category:Documentation]]<br />
[[Category:Age Projects]]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Projects_and_Resources&diff=455Projects and Resources2010-01-25T18:33:57Z<p>JWPlatt: </p>
<hr />
<div>{{draft}}<br />
Sample of an index to articles on Projects and Resources on the OpenURU.org site (and elsewhere?)<br />
<br />
<!-- Keep thing simple here! Avoid unnecessary wiki markup between the INC tags. --><br />
<!--INC-->== Info & HowTo On OpenURU.org ==<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewtopic.php?f=5&t=164 How to request a new project]<!--/INC--><br />
<!--INC-->== Projects On OpenURU.org ==<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewtopic.php?f=5&t=164 How to request a new project]<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=17 System Concepts]<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=20 Building & Testing]<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=34 Writers Club]<!--/INC--><br />
* <!--INC-->[[David's Journey]]<!--/INC--><br />
* <!--INC-->[http://forums.openuru.org/viewforum.php?f=46 Standards For Discussion & Debate]<!--/INC--><br />
* <!--inc-->Just some text<!--/inc--> <!-- A bit without a link, and with lower case tags --><br />
An example of <!--inc-->'''''some bold italic text taken out of context'''''<!--/inc--> just to show that it can work.<br />
<br />
<!-- Do not edit --><br />
[[Category:OpenUru.org]]<br />
[[Category:Documentation]]<br />
[[Category:Age Projects]]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Instancing_-_Scope_Inheritance&diff=217Instancing - Scope Inheritance2009-02-20T17:10:53Z<p>JWPlatt: </p>
<hr />
<div>{{draft}}<br />
<br />
== Instancing Overhaul: Private, Hood, Public Scope and Instance Inheritance ==<br />
<br />
Cyan is implementing city instancing in the same way as other things with private, hood and public scopes. I happen to like the idea as long as it is possible for us to easily meet people in the scope of our choice. Unfortunately, some of the instance inheritance, or scope, of books within their contexts of Relto, Nexus and hood is are not entirely consistent - to put it kindly. City instancing is even worse with a byzantine organization which is probably in flux until Cyan figures it out completely for themselves. They have deployed the DRC to solicit our help in mapping the instancing, so it appears to be a work in progress.<br />
<br />
Rather than respond to poor instancing rules of scope, and the DRC call to help them map it, I'd like to suggest how it should work. It should be simple, having as few rules as possible, and be entirely consistent so we can understand it without complex maps for the underlying structure of the game itself. The complexity should be in the puzzles, story and visual architecture - not in the interface or infrastructure. Instance complexity gets very much in the way of immersion and playing the game. I will politely point out that unnecessary complexity to an interface is poor design. DRC mapping of this complexity is a poor solution.<br />
<br />
<br />
This is how we best understand things as a root point of origin or scope:<br />
<br />
Relto --> Hood, Nexus, and private instances.<br />
Hood --> Hood instances.<br />
Nexus --> Public and hood instances.<br />
<br />
Relto is the private n-way root which provides the two special branches for hood (hood book) and public (Nexus) scopes plus any number of additional private branches (Cleft, Gahreesen, Teledahn, Kadish, and Eders so far).<br />
<br />
I implore Cyan to just stick to the rules of inheritance within these scopes to make things entirely predictable and intuitive without scope conflict:<br />
<br />
Private: Relto --> Private Ages --> Stones/Books --> Private Ages<br />
Hood: Hood --> Hood Ages --> Stones/Books --> Hood Ages<br />
Public: Nexus --> Public/Hood Ages --> Stones/Books --> Public/Hood Ages<br />
<br />
Book/stone sharing is only necessary with the Relto book and, possibly, hood books/stones. No repetitive book sharing should be required after the first sharing until you leave the scope via your Relto or a Nexus book.<br />
<br />
<br />
<u>Examples and discussion:</u><br />
<br />
Touching the Baron's office link book in Teledahn should do one of these things:<br />
<br />
Relto branch: Link to the age owner's private instance of the Baron's office and Ae'gura generally.<br />
Hood branch: Link to the hood's private instance of the Baron's office and Ae'gura generally.<br />
Nexus branch: Link to the public instance of the Baron's office and Ae'gura generally.<br />
<br />
This would be no different for a guest within another's (private or hood) age. No book sharing should be required.<br />
<br />
<br />
Touching a linking book in a hood should do these things:<br />
Members: Continue within the hood scope.<br />
Non-members: 1) Nothing or 2) continue within your private scope.<br />
Non-members of a hood require a share from a member to continue within that hood's scope.<br />
<br />
I prefer that linking books be inactive for non-members unless shared by a member. It would break the simple rules of scope and membership to either 1) allow a non-member to use a hood's book, or 2) send the non-member to his private instance. For this reason, it might be more consistent to require Relto books be actively shared. It would eliminate the need for locks, but I really like the convenience of the locks and being able to send someone to my Relto to use a book without having to be there myself. But allowing someone other than the owner to directly use a book on Relto's bookshelf would be inconsistent with the rules I've stated. After all, there is precedent because we cannot turn pages in others' Relto books. But I am willing to bend the rules slightly on Relto for this major convenience.<br />
<br />
<br />
Private hoods should not be any different, regarding instancing and scope, than a public hood. Private only means it's not listed in the Nexus. A private hood still gets its own scope separate and distinct from its owner's Relto's private scope.<br />
<br />
<br />
With the Kadish Gallery doors on Ae'gura opened, we now have a way to enter a hood or private instance of Ae'gura proper.<br />
<br />
<br />
'''Relto's "city book" is flawed''' because the results of all branches (e.g. touch a stone) are saved into a single place (the city book), making it impossible to have a persistent way to reach any specific scope or instance you have visited. Instead, the links are overwritten or irretrievable. It's like saving the results of multiple equations into a single variable. It should be that any page collected by visiting areas like the balconies should add a page to the respective books for Relto, Hood, and Nexus, depending on the scope in which you collected that page.<br />
<br />
Touching the Bahro stone in Eder Gira for Takotah Rooftop should do one of these things:<br />
Relto branch: Add rooftop page to the Relto book.<br />
Hood branch: Add rooftop page to Relto's hood book.<br />
Nexus branch: Add rooftop page to Relto's Nexus book.<br />
<br />
Does this mean we have to visit Eder Gira three times to get our rooftop link for all three scopes? Yes. Can Cyan make an exception to make a single visit to any scope add this page to all three books? Yes! In either case, we now have a way to get ourselves to any instance and they are persistent links which will not be overwritten by the latest link. If the scope has not been instanciated yet, Cyan can either check for that and add the page when it is, or make it part of the game to prefer the efficiency of page collection after visiting your three possible scopes of any age.<br />
<br />
Notice your Relto book now has pages to allow bypassing a useless trip into Relto and a link out if you are on a marker hunt. You can directly visit any place in your private scope for which you already touched a Bahro stone without going through Relto first. As it happens, skipping the repetitive trips to Relto just to link out again also improves the load on Cyan's servers.<br />
<br />
I'm not entirely certain as of this writing, but this consistent foundation for scopes of instance inheritance should eliminate all need for book and stone sharing except for the Relto book and, possibly, books and stones within a hood. I haven't looked at it deeply enough to figure out a way to get rid of book sharing in a hood and allow easy access to invitations into the hood scope. Touching any book or stone within a scope keeps you within that scope, whether it's private, hood, or public. The Nexus can take us to any public hood. From there we can enter that hood's scope merely by touching or sharing one of it's linking books. Private hoods and ages can be reached by invitation or sharing of the Relto book. Sharing of any linking page in your Relto book could make a visit by you and your guest to Relto unnecessary. We don't need invitations to hoods because they are listed in the Nexus. It seems reasonable that all invitations could just be to the private scopes. Or the KI and Nexus listings, like the three Relto books, could be expanded to allow private, hood, and public invitations, but that could be more work than Cyan is willing to consider.<br />
<br />
There might be some aspects of sharing and invitations I've missed.<br />
<br />
<br />
<div style="background-color: #eeffff; border: solid 1px #999999; text-align: left; margin-right: 25px; margin-left: 25px; padding: 10px"><br />
<u>A slight, and worthy, alternative from sambase for Ae'gura instances:</u><br />
<br />
Relto scope: brown book on relto bookshelf<br />
Hood scope: New brown book in Nexus room in a hood (or anywhere in a hood)<br />
Nexus scope: new registerable pedestals in all "brown book" areas to enable linking to the nexus instance<br />
by using the nexus (just like linking to the library or palace after registering that link through the pedestal)<br />
</div><br />
<br />
<br />
To summarize: <br />
<br />
1. The (non-sharable) Nexus book, regardless of what age you find it in, takes you to the Nexus which provides links to the public city (Ae'gura) instance, listed hood (Hood) instances, and your private ages. You can also select your own hood instance, listed or not, at the top of the panel. <br />
<br />
2. The hood book takes you to your hood or hood-instanced ages for the hood of which you are a member. Hood-instanced pages from Ae'gura are also contained within. Any linking from books in a hood, except Nexus books, continue within that hood's scope. <br />
<br />
3. The Relto book takes you to your Relto or private-instanced ages. Private-instanced pages from Ae'gura are also contained within. Any linking, except Nexus books, continues within the private scope. <br />
<br />
4. The city book is vestigial and for sentimental value only. I think it would be okay to eliminate it, but if it has to be kept, make it represent your private instances. These are now redundant pages found in your Relto book.<br />
<br />
==Links==<br />
(DRC) Instancing Overhaul: Scope Inheritance[http://forums.drcsite.org/viewtopic.php?t=1494]<br />
(MOUL) Instancing Overhaul: Private, Hood, Public Scope Inheritance[http://mystonline.com/forums/viewtopic.php?t=4617]<br />
<br />
<!-- Categories --><br />
[[Category:Improvements]]<br />
[[Category:Instancing]]</div>JWPlatthttps://wiki.openuru.org/index.php?title=Instancing_-_Scope_Inheritance&diff=212Instancing - Scope Inheritance2009-02-20T05:00:37Z<p>JWPlatt: New page: {{draft}} == Instancing Overhaul: Private, Hood, Public Scope and Instance Inheritance == Cyan is implementing city instancing in the same way as other things with private, hood and pub...</p>
<hr />
<div>{{draft}}<br />
<br />
== Instancing Overhaul: Private, Hood, Public Scope and Instance Inheritance ==<br />
<br />
Cyan is implementing city instancing in the same way as other things with private, hood and public scopes. I happen to like the idea as long as it is possible for us to easily meet people in the scope of our choice. Unfortunately, some of the instance inheritance, or scope, of books within their contexts of Relto, Nexus and hood is are not entirely consistent - to put it kindly. City instancing is even worse with a byzantine organization which is probably in flux until Cyan figures it out completely for themselves. They have deployed the DRC to solicit our help in mapping the instancing, so it appears to be a work in progress.<br />
<br />
Rather than respond to poor instancing rules of scope, and the DRC call to help them map it, I'd like to suggest how it should work. It should be simple, having as few rules as possible, and be entirely consistent so we can understand it without complex maps for the underlying structure of the game itself. The complexity should be in the puzzles, story and visual architecture - not in the interface or infrastructure. Instance complexity gets very much in the way of immersion and playing the game. I will politely point out that unnecessary complexity to an interface is poor design. DRC mapping of this complexity is a poor solution.<br />
<br />
<br />
This is how we best understand things as a root point of origin or scope:<br />
<br />
Relto --> Hood, Nexus, and private instances.<br />
Hood --> Hood instances.<br />
Nexus --> Public and hood instances.<br />
<br />
Relto is the private n-way root which provides the two special branches for hood (hood book) and public (Nexus) scopes plus any number of additional private branches (Cleft, Gahreesen, Teledahn, Kadish, and Eders so far).<br />
<br />
I implore Cyan to just stick to the rules of inheritance within these scopes to make things entirely predictable and intuitive without scope conflict:<br />
<br />
Private: Relto --> Private Ages --> Stones/Books --> Private Ages<br />
Hood: Hood --> Hood Ages --> Stones/Books --> Hood Ages<br />
Public: Nexus --> Public/Hood Ages --> Stones/Books --> Public/Hood Ages<br />
<br />
Book/stone sharing is only necessary with the Relto book and, possibly, hood books/stones. No repetitive book sharing should be required after the first sharing until you leave the scope via your Relto or a Nexus book.<br />
<br />
<br />
<u>Examples and discussion:</u><br />
<br />
Touching the Baron's office link book in Teledahn should do one of these things:<br />
<br />
Relto branch: Link to the age owner's private instance of the Baron's office and Ae'gura generally.<br />
Hood branch: Link to the hood's private instance of the Baron's office and Ae'gura generally.<br />
Nexus branch: Link to the public instance of the Baron's office and Ae'gura generally.<br />
<br />
This would be no different for a guest within another's (private or hood) age. No book sharing should be required.<br />
<br />
<br />
Touching a linking book in a hood should do these things:<br />
Members: Continue within the hood scope.<br />
Non-members: 1) Nothing or 2) continue within your private scope.<br />
Non-members of a hood require a share from a member to continue within that hood's scope.<br />
<br />
I prefer that linking books be inactive for non-members unless shared by a member. It would break the simple rules of scope and membership to either 1) allow a non-member to use a hood's book, or 2) send the non-member to his private instance. For this reason, it might be more consistent to require Relto books be actively shared. It would eliminate the need for locks, but I really like the convenience of the locks and being able to send someone to my Relto to use a book without having to be there myself. But allowing someone other than the owner to directly use a book on Relto's bookshelf would be inconsistent with the rules I've stated. After all, there is precedent because we cannot turn pages in others' Relto books. But I am willing to bend the rules slightly on Relto for this major convenience.<br />
<br />
<br />
Private hoods should not be any different, regarding instancing and scope, than a public hood. Private only means it's not listed in the Nexus. A private hood still gets its own scope separate and distinct from its owner's Relto's private scope.<br />
<br />
<br />
With the Kadish Gallery doors on Ae'gura opened, we now have a way to enter a hood or private instance of Ae'gura proper.<br />
<br />
<br />
'''Relto's "city book" is flawed''' because the results of all branches (e.g. touch a stone) are saved into a single place (the city book), making it impossible to have a persistent way to reach any specific scope or instance you have visited. Instead, the links are overwritten or irretrievable. It's like saving the results of multiple equations into a single variable. It should be that any page collected by visiting areas like the balconies should add a page to the respective books for Relto, Hood, and Nexus, depending on the scope in which you collected that page.<br />
<br />
Touching the Bahro stone in Eder Gira for Takotah Rooftop should do one of these things:<br />
Relto branch: Add rooftop page to the Relto book.<br />
Hood branch: Add rooftop page to Relto's hood book.<br />
Nexus branch: Add rooftop page to Relto's Nexus book.<br />
<br />
Does this mean we have to visit Eder Gira three times to get our rooftop link for all three scopes? Yes. Can Cyan make an exception to make a single visit to any scope add this page to all three books? Yes! In either case, we now have a way to get ourselves to any instance and they are persistent links which will not be overwritten by the latest link. If the scope has not been instanciated yet, Cyan can either check for that and add the page when it is, or make it part of the game to prefer the efficiency of page collection after visiting your three possible scopes of any age.<br />
<br />
Notice your Relto book now has pages to allow bypassing a useless trip into Relto and a link out if you are on a marker hunt. You can directly visit any place in your private scope for which you already touched a Bahro stone without going through Relto first. As it happens, skipping the repetitive trips to Relto just to link out again also improves the load on Cyan's servers.<br />
<br />
I'm not entirely certain as of this writing, but this consistent foundation for scopes of instance inheritance should eliminate all need for book and stone sharing except for the Relto book and, possibly, books and stones within a hood. I haven't looked at it deeply enough to figure out a way to get rid of book sharing in a hood and allow easy access to invitations into the hood scope. Touching any book or stone within a scope keeps you within that scope, whether it's private, hood, or public. The Nexus can take us to any public hood. From there we can enter that hood's scope merely by touching or sharing one of it's linking books. Private hoods and ages can be reached by invitation or sharing of the Relto book. Sharing of any linking page in your Relto book could make a visit by you and your guest to Relto unnecessary. We don't need invitations to hoods because they are listed in the Nexus. It seems reasonable that all invitations could just be to the private scopes. Or the KI and Nexus listings, like the three Relto books, could be expanded to allow private, hood, and public invitations, but that could be more work than Cyan is willing to consider.<br />
<br />
There might be some aspects of sharing and invitations I've missed.<br />
<br />
<br />
<div style="background-color: #eeffff; border: solid 1px #999999; text-align: left; margin-right: 25px; margin-left: 25px; padding: 10px"><br />
<u>A slight, and worthy, alternative from sambase for Ae'gura instances:</u><br />
<br />
Relto scope: brown book on relto bookshelf<br />
Hood scope: New brown book in Nexus room in a hood (or anywhere in a hood)<br />
Nexus scope: new registerable pedestals in all "brown book" areas to enable linking to the nexus instance by using the nexus (just like linking to the library or palace after registering that link through the pedestal)<br />
</div><br />
<br />
<br />
To summarize: <br />
<br />
1. The (non-sharable) Nexus book, regardless of what age you find it in, takes you to the Nexus which provides links to the public city (Ae'gura) instance, listed hood (Hood) instances, and your private ages. You can also select your own hood instance, listed or not, at the top of the panel. <br />
<br />
2. The hood book takes you to your hood or hood-instanced ages for the hood of which you are a member. Hood-instanced pages from Ae'gura are also contained within. Any linking from books in a hood, except Nexus books, continue within that hood's scope. <br />
<br />
3. The Relto book takes you to your Relto or private-instanced ages. Private-instanced pages from Ae'gura are also contained within. Any linking, except Nexus books, continues within the private scope. <br />
<br />
4. The city book is vestigial and for sentimental value only. I think it would be okay to eliminate it, but if it has to be kept, make it represent your private instances. These are now redundant pages found in your Relto book.<br />
<br />
==Links==<br />
(DRC) Instancing Overhaul: Scope Inheritance[http://forums.drcsite.org/viewtopic.php?t=1494]<br />
(MOUL) Instancing Overhaul: Private, Hood, Public Scope Inheritance[http://mystonline.com/forums/viewtopic.php?t=4617]<br />
<br />
<!-- Categories --><br />
[[Category:Improvements]]<br />
[[Category:Instancing]]</div>JWPlatt