Cyan Content Licensing Proposals

Content Licensing Request

Introduction

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

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

Examples

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

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

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

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

Community Needs

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

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

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

Questions

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

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

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

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

Summary

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

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

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

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

Full discussion on the OpenUru.org forums:

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

Signatures, Open Source Uru Community

OHB 19:24, 2 February 2012 (MST), Lewis Johnston, GULP, (Address TBI)

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

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

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

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

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

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

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

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

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

D'Lanor 00:00, 8 February 2012 (CET), (Name TBI)

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

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

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

Additional Information

Technical Information on the Localization Example

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

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

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

Additional Examples

Bink Video Replacement

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

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

Collider Fixes for PhysX 2.6.4

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

H-uru/Plasma@529ff79 on GitHub

Band-aid for poorly modelled stairs

Looks like the Cyan modellers didn't extend the stair ramps all the way down in some places. To compensate, we can now take higher steps but can't walk on slopes quite as steep as before. I think this should balance out

nicely.

More details by Adam Johnson (Hoikas):

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

http://assets.openuru.org/wiki/general/stairs_tn.jpg

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

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

http://assets.openuru.org/wiki/general/rocks_tn.jpg

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

http://assets.openuru.org/wiki/general/cones_tn.jpg

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

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

KI Coordinates in Great Zero Courtyard are Backward

Issue brought up recently on the MOUL forum that should be easy to fix given a content license: http://mystonline.com/forums/viewtopic.php?t=25431

License Suggestions

We tried to come up with suggestions for licenses in order to simplify the burden on Cyan, but as the OU Content Licensing thread proves there are many viable options and they all address different needs. Unfortunately, in order to find where that spot of compromise is we will need feedback from Cyan on this point. We ask that Cyan, should they wish to consider this request, respond with their concerns and needs first. At that point tangible suggestions can be made regarding the specifics and the proposal can move forward should they be agreeable.

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