OpenUru - User contributions [en]

Avatar Oneshot Animations

2019-03-27T05:54:48Z

Deledrius: Fix broken link to GoW Wiki.

One Shot Avatar Animations are those animations that we see our Avatar perform when we either enter a special region, or click on something, such as a button, or a lever, etc.

Normally these one shot animations will be tied in to something else in your Age that you are setting up. On rare occasions you could set up a trigger region and place an avatar animation in to be performed simply because the avatar walked to or entered that spot.

To put an avatar one shot animation into your Age in Max, you will need to create a "Seek Point". This is the place that the avatar will be told to move to so that it may perform it's animation. Placement of this Seek Point is VERY important, as you can have all sorts of things happen if you don't. Anything from the Avatar just looking funny reaching for a lever that's too far away, to the avatar trying to walk through a wall.......and not stopping, but instead walking against the wall.

It's also VERY important to put the device (button, lever, switch, etc) that the avatar is going to interact with in the correct place.

You will also need to know things about the avatar animation, such as it's name, and also something that we call "Call Backs".
Call Backs are important, as many times when we have the avatar performing these animations, we are also expecting a sound (and even an event). Like when the Avatar pulls on a lever, you hear it DURING the animation, not before or after.

For all this information, I HIGHLY recommend using the info located over at the GoW Wiki. While it was originally written with Blender in mind, it works perfectly for 3DS Max too. The units of measurements that you see in the Wiki are Blender units. One Blender Unit is equal to one foot. This is fine as one Max unit is also one foot (if you set your units up right!).

Here is the link for the GoW Wiki with all the information specifications on Avatar Animation. When you've found what you wanted, write it down and come back here.

[https://www.guildofwriters.org/wiki/Avatar_Animations_List GoW Wiki Avatar Animations List]

Now that you have your information, it's time to put it to use in Max.

----

===Putting in a Seek Point===

First you need to build the stuff that your avatar is going to interact with, and get it placed correctly. I have a simple button here, and placed it's center exactly 3.8 Max units above the ground that the avatar is going to stand on.

Once you have your interactive object in you will need to put in your "Seek Point"

There are two ways to do this:

1) Use one of the Max Helpers called "Dummies" or
2) Create a small cube.

I like to use the first way myself. To do this go up to your menu in Max and click on: Create > Helpers > Dummy and then draw it on to your 3D scene. You can make it any size you desire. I try to keep my small.

The one problem about using "Dummies" is that they like to hide behind your objects in your 3D scene in Max, and this can get annoying.
The upside is that Plasma automatically does NOT draw them.

Doing it the 2nd way, simply make a small cube. You will have to use the Ignore component in the Plasma Component Manager however, or it will be seen in the game.

http://assets.openuru.org/wiki/andy/MaxTutPics1/clickMultResp10.jpg

You can see my "Dummy" in the pic above. It's circled in Blue.

Now call up your Component Manager and click on New > Avatar > (ex)One Shot

http://assets.openuru.org/wiki/andy/MaxTutPics1/avieanimmax1.jpg

Then go over to your Utils Tab (the little hammer) and click on the Component Utils button. select the One Shot component:

http://assets.openuru.org/wiki/andy/MaxTutPics1/avieanimmax2.jpg

As you can see from the picture, you can simply put in the name of the animation that you need. The other options that are here are discussed in the GoW Wiki in the link above if you desire to use them, you can put the check marks in here.

Once you have done this, you are done putting in this Avatar Seek Point and are set to use it for your other function (what ever it was you were going to have the player do!)

{{ALTutorials}}

Cyan Worlds Sources And Tools

2013-06-06T06:55:34Z

Deledrius: /* Installation */ Fix link to use correct domain and point to the intended page.

{{UruDocProj}}
{{design-stub}}

== CyanWorlds.com Engine - Client & Plugin ==
=== Source ===
<div style="float: right; padding: 10px;">http://assets.openuru.org/logos/gpl/gplv3-127x51.png</div>
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.

==== Download ====
The original sources are made available here from OpenUru.org:

{{Pad}}From [http://assets.OpenUru.org/cyan/MOULOpenSourceClientPlugin.zip OpenUru.org]

=== 3ds Max Plugin (Binary & Documentation) ===

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.

==== Download ====
The binaries and documentation for the plug-in are made available here from Cyan and OpenUru.org:

===== Binaries =====
{{Pad}}From [http://assets.OpenUru.org/cyan/MOULaPlugins871.zip OpenUru.org]

{{Pad}}From [http://cho.cyan.com/bahrowings/MOULaPlugins871.zip Cyan Worlds]

===== Documentation =====
{{Pad}}From [http://assets.OpenUru.org/cyan/PlasmaPlugins.doc OpenUru.org]

{{Pad}}From [http://cho.cyan.com/bahrowings/PlasmaPlugins.doc Cyan Worlds]

==== Installation ====
{{draft}}
{{tba}}
OpenUru.org documentation to follow.
There are installation instructions currently on the [http://www.guildofwriters.org/wiki/Max:Installation Guild of Writers website].

==== Usage ====
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].

== CyanWorlds.com Engine - Game and Auth Files ==
These are the "Game" and "Auth" files that are necessary to complete a working server installation.

=== Downloads ===

==== Binaries ====

Game files:

{{Pad}} (902) From [http://assets.OpenUru.org/cyan/GameFiles902.zip OpenUru.org]

{{Pad}} (893) From [http://assets.OpenUru.org/cyan/GameFiles.zip OpenUru.org]

Auth files:

{{Pad}} (902) From [http://assets.OpenUru.org/cyan/AuthFiles902.zip OpenUru.org]

{{Pad}} (893) From [http://assets.OpenUru.org/cyan/AuthFiles.zip OpenUru.org]

==== Source ====
<div style="float: right; padding: 10px;">http://assets.openuru.org/logos/gpl/gplv3-127x51.png</div>
Age, Fni, Python and SDL sources:

{{Pad}} (902) From [http://assets.OpenUru.org/cyan/Scripts902.zip OpenUru.org]

{{Pad}} (893) From [http://assets.OpenUru.org/cyan/Scripts893.zip OpenUru.org]

== KI Source ==

This is the KI python and 3ds Max source files.

=== Download ===
The sources are made available here from Cyan and OpenUru.org:

{{Pad}}From [http://assets.OpenUru.org/cyan/KI-887.zip OpenUru.org]

{{Pad}}From [http://cho.cyan.com/bahrowings/KI-887.zip Cyan Worlds]

== Wave Emote ==

This is the 3ds Max file source for the Wave emote.

=== Download ===
The sources are made available here from Cyan and OpenUru.org:

{{Pad}}From [http://assets.OpenUru.org/cyan/WaveEmote.zip OpenUru.org]

{{Pad}}From [http://cho.cyan.com/bahrowings/WaveEmote.zip Cyan Worlds]

== Avatar Assets ==

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.

=== Download ===

{{Pad}}[http://assets.OpenUru.org/cyan/avatar/Avatar_Male01.zip Male Avatar 1]

{{Pad}}[http://assets.OpenUru.org/cyan/avatar/Avatar_Male02.zip Male Avatar 2]

{{Pad}}[http://assets.OpenUru.org/cyan/avatar/Avatar_Male03.zip Male Avatar 3]

{{Pad}}[http://assets.OpenUru.org/cyan/avatar/Avatar_Male04.zip Male Avatar 4]

{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.male.SmoothBase.zip Male Avatar Smoothing]

{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.female.01.zip Female Avatar 1]

{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.female.02.zip Female Avatar 2]

{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.female.zip Female Avatar 3]

{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.female.04.zip Female Avatar 4]

{{Pad}}[http://assets.OpenUru.org/cyan/avatar/bas.avatar.female.SmoothBase.zip Female Avatar Smoothing]

{{Pad}}[http://assets.OpenUru.org/cyan/avatar/AvatarTextures.zip Avatar Textures (94 MB)]

== See also ==

{{:CWE/See Also}}

'''References and citations:'''
<references/>

[[Category:Cyan_Worlds]]

Cyan Content Licensing Proposals

2012-02-19T19:41:01Z

Deledrius: /* Signatures, Open Source Uru Community */ -- Add name and affiliation

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

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

=== Examples ===

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

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

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

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

=== Community Needs ===

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

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

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

=== Questions ===

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

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

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

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

=== Summary ===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Additional Information ==

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

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

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

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

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

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

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

<span class="plainlinks">[http://assets.openuru.org/wiki/general/stairs.jpg http://assets.openuru.org/wiki/general/stairs_tn.jpg]</span>

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.

<span class="plainlinks">[http://assets.openuru.org/wiki/general/rocks.jpg http://assets.openuru.org/wiki/general/rocks_tn.jpg]</span>

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).

<span class="plainlinks">[http://assets.openuru.org/wiki/general/cones.jpg http://assets.openuru.org/wiki/general/cones_tn.jpg]</span>

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

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

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

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

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

Greifers 101: Answers and Solutions to Harassment in MOULa

2012-02-19T13:51:52Z

Deledrius: moved Greifers 101: Answers and Solutions to Harassment in MOULa to Griefers 101: Answers and Solutions to Harassment in MOULa: Fix spelling error.

#REDIRECT [[Griefers 101: Answers and Solutions to Harassment in MOULa]]

Griefers 101: Answers and Solutions to Harassment in MOULa

2012-02-19T13:51:52Z

Deledrius: moved Greifers 101: Answers and Solutions to Harassment in MOULa to Griefers 101: Answers and Solutions to Harassment in MOULa: Fix spelling error.

{{NewGreeters}}
The New Greeters take harassment very seriously in regards to our efforts of helping players have a pleasant experience playing Uru. However, it is widely known, that at times, so called "Griefers" will wreak havoc with players. This is usually done through the following methods: text chat, voice chat, and public avatar harassment.

==Solution to Text Chat Harassment==
The solution to text chat harassment in probably the most straight forward of the bunch. To hide or block a player's text chat please do the following:

# Click on problem avatar's name.
# Type /ignore into the chat line.
# Success! The problem avatar's text chat will now be blocked on your chat feed.

==Solution to Voice Chat Harassment==

Due to the nature of voice chat in MOULa, you will have to take a more "direct" approach in censoring your problem griefers.

# Open your options menu by hovering the mouse over the bottom of the screen and clicking the wrench icon.
# Click Audio Options.
# Uncheck the Voice Chat box.
# Now you will no longer hear the voice chat of your troublesome adversary, nor will you hear the voice chat of anyone else.

==Solution to Public Avatar Harassment==

This proves to be a greater problem than any technical solution can control. If you are offended by another avatar walking through you or jumping around mindlessly as a form of harassment, please email Cyan World's Technical Support at [http://support.cyanworlds.com/ http://support.cyanworlds.com/.] Someone there will be glad to assist you in either: A: Banning the problem player; or B: Finding a solution that fits your unique situation.

==Further Questions and Support==

As always, the New Greeters are glad to help out players experiencing problems. We publicly recommend moving to a different age or location if you are being harassed constantly. Cyan is always the first line of support, but if you ever need in game assistance please feel free to contact one of our members if they are online and we will be glad to help you out or help get you further assistance.

==Links==

[http://newgreeters.openuru.org/membership/members/ New Greeters Membership and Contact Information]

{{NGCopyright}}

Griefers 101: Answers and Solutions to Harassment in MOULa

2012-02-19T12:35:52Z

Deledrius: Spelling fixes. (Page title needs fixing as well)

Open Source Shard List

2012-02-11T19:40:44Z

Deledrius: Add Gehn Shard.

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

Please note that this list is for shards running Open Source server software only and run in accordance with Cyan's content licensing rules.

; Shard Name : The preferred name of the shard, i.e. the name by which its owner(s) would like it to be known.
; Server S/W : The server software used by the shard, e.g. MOSS, Dirtsand, Cyan.
; Type : The access type of the shard, Public, Invitation or Private.
; Test Use : Whether this shard is available for test use or not: Yes, No.
; Description : Brief description of the shard, any key features.
; Shard Site URL : Website associated with the shard, e.g. location for client download.
; Contact : Contact detail for shard admin. Preferably a link to a forum profile.

The table below is sortable.

{| class="wikitable sortable"
|-
! Shard Name !! Server S/W !! Type !! Test Use !! Description !! Shard Site URL !! Contact
|-
| 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]
|-
| 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]
|-
| 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]
|-
| Destiny || MOSS || Private || Yes || Private testing || Not advised || [http://forums.openuru.org/memberlist.php?mode=viewprofile&u=1002 Mystler]
|-
| 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]
|-
| 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]
|}

[[Category:MOSS]]

Cyan Content Licensing Proposals

2012-02-04T15:57:56Z

Deledrius: Added signature.

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

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

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

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

At this time, we would ask: is Cyan able to indicate what difficulties they perceive over the licensing of content, are there particular aspects where Cyan is open to suggestions, and are there specific limitations which the fans should place on their aspirations for content licensing? 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.

Thank you for reading and considering this request.

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

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

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

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

[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST)

[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST)

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

[[User:Malfhok|Malfhok]] 05:14, 4 February 2012 (MST)

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

<hr>

Following is additional technical information.

=== Technical Information ===
The .loc files are XML files containing translations for all textual items in Uru. GULP (http://rel.to/gulp) already has an extensive library of translations and a system to export that database to Uru-ready .loc files. Not all of Uru uses these however, 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 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 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.

=== License Suggestions ===
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.

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

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

Cyan Content Licensing Proposals

2012-02-04T15:57:08Z

Deledrius: Grammar streamlining.

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

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

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

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

At this time, we would ask: is Cyan able to indicate what difficulties they perceive over the licensing of content, are there particular aspects where Cyan is open to suggestions, and are there specific limitations which the fans should place on their aspirations for content licensing? 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.

Thank you for reading and considering this request.

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

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

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

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

[[User:Leonardo|Leonardo]] 06:16, 3 February 2012 (MST)

[[User:Mac Fife|Mac Fife]] 12:12, 3 February 2012 (MST)

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

[[User:Malfhok|Malfhok]] 05:14, 4 February 2012 (MST)

<hr>

Following is additional technical information.

=== Technical Information ===
The .loc files are XML files containing translations for all textual items in Uru. GULP (http://rel.to/gulp) already has an extensive library of translations and a system to export that database to Uru-ready .loc files. Not all of Uru uses these however, 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 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 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.

=== License Suggestions ===
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.

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

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