OpenUru - User contributions [en]

Making Clickables

2013-07-17T04:37:21Z

GPNMilano:

I'm going to introduce you to "Clickables" in this tutorial. A "Clickable" is the object that the player clicks on in the game, because their cursor is hot (no longer a open circle, but looks like a target).

Clickables have a multitude of uses: A lever that you can pull, a button to push, a linking book to touch, the list goes on and on.

In most cases, you will want to have your Avatar animate when something is clicked. There are exceptions to this, like what we call GUI Dialogs. A GUI Dialog is when we click on something and it "pops up" for a closer view. Examples of this are:

Journals, the various notes on the desk in the Baron's City Office, the notes and drawings on Sharper's desk in Teledahn.

Those are all good examples of simple GUI Dialogs. You have interactive GUI Dialogs too, in which there is no avatar animation, but you may have object animation.

Many of these things get very complex and rather involved, and I'm not going to cover here for now. But I will introduce you to the most important aspect of all of these: Making something "Clickable"

----
===Let's Get Started.....===

Okay, the example I'm using in this tutorial is a clickable that when the player clicks on it, he or she links out to another Age. So you will need to make something that the avatar can click on. I just threw together a large brick box, and a flat plate that is kind of like the Bahro Stones:

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

Now, if we were going to animate the avatar for touching the plate, the positions of these things would be very important. For now I'm not too worried about it. I made the box 3 feet high and placed my metal plate on next to one edge.

Once you've made your stuff and textured them, do not forget to add them to your PageInfo (if you don't know how to do that, you need to go back to one of my first tutorials on getting started on building Ages in Max).

Now I'll be using a region for this clickable. You do not have to use a region to have a clickable work. However you can use them to ensure the player can not click on something from far away, or needs to be close to a seek point of your avatar is going to animate.

You'll want your Avatar completely in the box, so make sure you make it big enough to encompass the Avatar (no smaller than 3 x 3 x 6 feet). I made mine 5 feet x 5 feet wide and deep and 7 feet wide. Even though the avatar is 6 feet high, you'll want to dip the region just below the floor that the avatar is standing on:

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

Now, if you're wondering how I got my region box to be nice and see through like that, here's a Max tip: When you first create your objects in Max, they'll be solid. If you need them to be see through, simply select what you've made, and right click with your mouse. You'll have a box show up like this:

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

Left click where it says "Properties". A new box will pop up showing you the objects properties in Max:

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

Notice where I circled. I put a check mark in See Through, and now my box looks that way. If you want it to looks like a box with just lines (regardless of the amount of mesh facings) click where it says "Display As Box" instead.
Making your regions look either See Through or Display As Box is a very good idea, as you know it's not something that will be rendered by Plasma.

Okay, now that we have our Object we are going to click on, and our Region, make sure you've named them something Useful. Leaving them as Box01, Box02, Box03, will get confusing in a hurry. I've named my clickable object "LinkPlate" and the region has been named LinkClkRegion.

Now go and select your object that is your clickable. In my case it is the LinkPlate I made. Now call up the Component Manager. Click on New > Detector > Clickable

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

And attach it to your clickable object. AND rename it to something useful.

While still in the Component Manager, click on New > Logic > Responder

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

Attach it to your clickable object, and rename it something useful.

Now go back over to the Utils Tab (little hammer) and you Component Utils.

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

As you can see from my picture, I've renamed my components to something that helps me ID them. "LinkClick" is my "Clickable" component, and "RespLink" is my Responder component. Select your Clickable component.
I my picture, where my arrow is pointing, your button will say "none", click on this button, and then click on your Click Region you made in your 3D Scene. Your button's name should change to the name of your region.

That's all we're going to do here. We've told our Clickable component that the avatar MUST be inside our region in order for the object to become a clickable.

If you decided to not use a region, simply leave the button that says "none" alone and put a check mark where it says "Ignore"

Now things are going to start getting a bit more interesting. Select your Responder Component in the Component Utils. It will look like this:

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

Under the Detect box, click on the Add button (where I have my purple arrow drawn). We're going to tell the Responder what it must detect in order to respond.
When you click on the "Add" button, a new box will pop up:

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

Now you can see why it's important to start naming your Plasma Components and not just the Objects and Materials in your Age. Our Responder is asking us to pick what it is suppose to detect: When the avatar is in the region? Or When the player clicks on something?
Select your Clickable component here. We want the Responder to detect when the player clicks on our object.

Now you should have your Clickable component in the Detect box. Go down now to the State box. We're going to tell the Responder what it is we want to happen when the player clicks on this object:

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

This is where things will start getting VERY complex for you, if you are going to have more than one thing happen. A good example of that would be the avatar pulling on a lever. We would have to tell the responder to animate the avatar, animate the lever, and make a sound....THEN have whatever is going to happen after that (a door opening, a platform rising, whatever).

I'm going easy on you here, normally we'd have the avatar animate and reach out to the linking plate, but instead, I'm just going to have the link out sequence happen immediately.

Click on the Add button where my purple arrow is pointing in the pic above. You'll have a small box pop up:

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

As you can see, LOTS of goodies to pick from here. Go down and click on Link. When you do, you'll have more added to the responder component:

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

Now we're going to tell the game, WHERE your avatar is going to link to. But before we do you need to do something first. You need to have an Age that the Avatar is going to link to. Specifically, you need to make a copy of the .age file of that Age, and place it in your Max Output folder you specified in the PlasmaMAX2.ini file. Mine is "C:\PlasmaTest\dat"
I've got another test Age I'm using here in this tutorial, but you can copy and past any Uru age you want here. When you do, it's important to remember the name of the file (IE: The Maintainer Age of Gahreesen's file name is actually "Garrison", the garden Age of Eder Kemo is actually called "Garden", etc).

Once you have a copy of the .age file pasted, go back to your responder component. In the top box about Linking Rule, leave it set to the default for now.
Instead, go down to the drop box for Age Filename and select the Age you want to link too. (if nothing is showing up, it's because you didn't put the .age file in the right place).

The next 4 boxes, you can leave alone. Unless you know what the names of different spawn points are in an Age, it won't do you any good to change this. Right now they are set up to link the Player into the Age at it's Star Point (In Teledahn it's in the hut, in Gahreesen it's in the atrium of the small building, you get the idea).

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

In that last box is the animation the Avatar will do once it has linked in to the other Age. You can leave it where it's set for now.

In the last box, simply select the name of your Age in the drop down box:

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

And that's IT! You're done!

You can export, drizzle the Age, link in and walk over to your object. Your cursor should go hot, when you click, you should immediately link out, and link into the Age you specified.

So a summery here:

For an object to be clickable, you must have; The Object and a Region near or around the object.

The Region must be set up to simply detect the Avatar.
The Object MUST have the following components: Clickable and Responder

Now, I can tell you from other things I've been working on, that your clickable will not work right if other things are not set right. You may end up with the cursor simply never going hot, or you'll have the cursor go hot, but nothing happens.

The key to troubleshooting your clickable, is to know where to look. If the cursor is not going hot, chances are you have something wrong with the clickable or region. If your cursor is going hot, but when you click nothing happens, chances are you have something wrong either with the Responder on the clickable, or the actions have a problem (IE the animation, the linking, the GUI Dialog, etc, what ever it is that is suppose to happen when you click).

{{ALTutorials}}

Cyan Content Licensing Proposals

2012-02-17T03:49:54Z

GPNMilano: /* Signatures, Open Source Uru Community */

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

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

=== Examples ===

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

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

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

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

=== Community Needs ===

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

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

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

=== Questions ===

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

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

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

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

=== Summary ===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<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-09T06:36:23Z

GPNMilano: /* Signatures */

== 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 to re-enable 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)

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

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

[[User:GPNMilano|GPNMilano]] 23:36, 8 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]