Object Paths

Overview

The Object Path (OP) is the base web address where all of the art files for CUni's worlds are stored. Each time the CUni browser needs a file, it appends a subfolder and filename to the Object Path address and downloads the file from the resulting address.

For a simple example, the default AlphaWorld object path, hosted by Active Worlds is

http://objects.activeworlds.com/aw/

When it needs a model with filename sign3.rwx, the browser will append the folder name models and zipped filename sign3.zip, making the full address

http://objects.activeworlds.com/aw/models/sign3.zip

For a more realistic example in CUni, the object path in Welcome world is

host.scicentr.org/worlds/general.cgi?welcome?

The warp bubbles use model filename warp1.rwx. To get this file, the browser will append the folder name models and zipped filename warp1.zip, making the full address

host.scicentr.org/worlds/general.cgi?welcome?/models/warp1.zip

The OP used in a given world is set in the World Features dialog. The address is visible only to the world's Caretakers.

Contents

An Object Path contains the following subfolders and files:

• avatars\ folder:
  • Contains a zipped model (.rwx) file for each avatar available. These .rwx files usually reference textures, which must be found in the textures folder.
  • Contains a zipped avatar list (avatars.dat), which lists the names of all avatars that users should be able to choose, and their implicit and explicit gesture files. These gesture files must be found in the seqs folder.
  • Contains "special" avatars, which are only available to public speakers and have default filenames (and default .seq filename dependencies).
• models\ folder: contains all of the 3D models (objects) that can be used in a world. These are zipped .rwx files. These models usually reference textures, which must be found in the textures folder.
• seqs\ folder: contains all of the avatar implicit gestures (walk, fly, wait, etc) and explicit gestures (waving, dancing, etc, for which users click a toolbar button) available to the avatars in a world. These are zipped .seq files.
• sounds\ folder: contains all of the sound files that are available; .wav and .mid files should are zipped, and .mp3 files are not.
• textures\ folder: contains all the textures and masks available in the world. Textures are .jpg files, and masks are zipped .bmp files. These are referenced from files in the models and avatars folders, as well as texture and picture commands.
• registry.txt file: the object registry, which gives the dimensions of each model in the Object Path. Providing this file causes encroachment rules to be enforced, and it is generally not used in CUni.

CUni Object Path locations

Base URL for all CUni OPs:

http://host.scicentr.org/worlds/

Base file location for all CUni OPs (type it in the Start->Run box or an explorer address line):

\\scicentr2\inetpub\wwwroot\worlds\

Normal SciFair OP URL:

host.scicentr.org/worlds/sfYY.cgi?SCHOOLNAME? The ?'s are part of the URL and this is explained below.

Normal SciFair OP location (for custom files):

\\scicentr2\inetpub\wwwroot\worlds\SciFairYYYY\SCHOOLNAME\

Different Object Sets

There are many publically available object sets. We use and make available both the AlphaWorld and MegaPath sets, and could add others upon request. Others we don't currently host include Mars and ColonyAlpha. We also host a variety of files made in-house, and we are set up for individual projects and programs to include their own files.

Multipath Script Explanation

CUni only supports using one Object Path in a given world, and the available sets are huge, so we use a trick to make all the files and customization available without keeping a separate copy for each world. This trick is called a MultiPath script. The URL of the MultiPath script is used for the OP location, and CUni ends up sending the desired file as a parameter. The script searches several locations and sends back the file if found.

The scripts are found in the folder \\scicentr2\inetpub\wwwroot\worlds\, and they all have a .cgi extension. The script for SciFair world OPs searches the following folders for a given file, and sends the first match found:

1. CTCAvatars - Custom avatars made in-house. Looking here first prevents clobbering avatars' textures.
2. SciFairYYYY\SCHOOLNAME - Custom world-specific folder. This is where you put your custom files.
3. SciFairYYYY\All - Files shared by all SciFair programs. This includes a default avatar list for SciFair worlds.
4. CTCPath - Custom models, etc, made in-house that are useful in multiple worlds. Also includes a default avatar list for CUni worlds (this avatar list is overridden in SciFair worlds).
5. AlphaWorld - Default object set whose contents are listed in the User Guide and the Building World Object Yard.
6. MegaPath - Another publically available object set with additional themed sets.

The MultiPath scripts are generally set up to take two parameters - (1) the custom folder to look in, and (2) the subfolder and file to look for. CGI scripts expect parameters to be included in the URL after question marks (?), so the OP URLs have the path to the .cgi file, followed by a question mark, followed by the custom folder name, and finally another question mark. When the requested filename is appended by CUni, the script sees this as the second parameter.

Lists of Available Models, Textures, etc

Unfortunately, there is no simple way to list the art files that are available in your world. Know that almost anything in the AlphaWorld (Building world Object Yard / User Guide list) and MegaPath (there is an Object Yard in AWEDU) should work. Things you see in other CUni worlds could probably be copied with some sleuthing, or are already available.

The best way to come up with a list of filenames is to look through each of the folders searched by the MultiPath script. You can also just try a filename and see if it works (though this approach is error-prone).

Using Existing Objects from Other OPs

If a file already exists in another OP that isn't currently accessible from your world, you'll need to copy (NOT MOVE) the files into your world's custom folder:

1. Open the model file and find make a list of the textures it uses; these will appear on any TEXTURE lines in the file. Assume a .jpg extension for textures; if you see a MASK referenced too, assume a .zip extension (the .zip should contain a .bmp).
2. Make sure a model file of the same name is not already in your Object Path (for example by trying to build with it or making the correct URL and entering it in a web browser). Similarly check the texture files from your list.
3. If you're sure you won't be clobbering existing files, copy the model file into your models folder and the texture files into your textures folder.

Sounds and independent textures can be copied more trivially, though you still need to make sure you don't override existing files unintentionally.

Avatars can also be copied in a similar way, but the avatar list needs to be updated to reflect changes and depended sequence files listed in the avatars.dat file would also need to be copied.

If the files seem generally useful to other SciFair worlds, consider having them put in the "All" folder, and if generally useful beyond SciFair, consider having them go in the CTCPath folder.

Adding Custom Objects and other Files

To add your own custom files simply check for filename collisions as above and copy the files to the appropriate folders. Again, be sure to include all dependent files (like textures).

Avatar Lists

The simplest way to alter the avatar list for your world is to copy an existing avatar list (such as the one from SciFairYYYY\All or CTCPath) into your world's avatar folder and edit as needed. It should be straightforward to copy entries from another avatar list, or to delete ones from your list. Adding new gestures or completely new avatars is a bit trickier.

The avatars.dat file starts with a line containing the text version 3, followed by a series of avatar entries. Each entry is of the form:

avatar
  name=AVATARNAME
  geometry=AVATARFILE.RWX
  autowalk
  beginimp
    walk=WALKSEQFILE
    wait=WAITSEQFILE
  endimp
  beginexp
    wave=WAVESEQFILE
    dance=DANCESEQFILE
  endexp
endavatar

avatar/endavatar lines

These denote the start and end of an entry in the list; these lines are required.

name

Display name for the avatar list

geometry

Avatar model filename. The browser will try to download the .zip version of this filename from the avatars\ folder.

autowalk

Makes the browser automate the timing of the walk sequence. This is nice for humanoid avatars that walk normally, but doesn't work well for unusual avatars. Disable it by leaving off that line.

beginimp/endimp section

This contains the implicit gestures, the animations to be shown automatically when the user moves in different ways, for example. Each entry points to a .seq file in the seqs\ folder. Any of these can be included: walk, run, wait, warp, idle, fly, hover, swim, float, jump and fall.

beginexp/endexp section

This contains the explicit gestures. These can be anything; they are triggered by the user clicking a toolbar button. The button will have the name provided in the list.

"Special" avatars are not listed in the avatars.dat file; they are assumed to have filenames special#.rwx and sequences sp#walk.seq, sp#wait.seq, sp#act1.seq through sp#act3.seq, etc, where # is a number between 1 and 5. They appear in public speakers' avatar lists only, with generic names.

Troubleshooting and Development Tips

There are a few features that are very useful for testing and troubleshooting purposes.

Print object errors in chat window

This feature will give you an error message in the chat window any time a file fails to load. You can tell from the error what address it tried to download from, as well as the type of error. "File not found" means the filename is wrong or the file is in the wrong place. "Reason 1502" is generally a one-time server timeout, and will probably work if you try again. Other messages can indicate problems within individual files. This is also helpful in tracking down the causes of black triangles. Enable this feature in the "Advanced" tab of the browser settings (choose "Settings" from the "Options" menu)

Local Path

The Local Path feature allows you to test files locally before putting them in the world server (don't forget to put them on the server eventually, or nobody else will see them). When enabled, the browser will look in a folder on the local computer before downloading the file from the Object Path. This is good for development of new files, or testing ones you've found elsewhere. You set the base location in the "Advanced" tab of the browser settings (choose "Settings" from the "Options" menu). It is explained in the ActiveWorlds Help but it's a bit tricky to set up. Here's an example: if you set the local path to c:\CUni\localpath, and your world's object path is set to

host.scicentr.org/worlds/sf07.cgi?SCHOOLNAME?,

then you would put your test models in the folder

c:\CUni\localpath\host.scicentr.org\worlds\sf07.cgi-SCHOOLNAME-\models\,

and textures in

c:\CUni\localpath\host.scicentr.org\worlds\sf07.cgi-SCHOOLNAME-\textures\

Refreshing Files

Unfortunately, there's no automatic way to refresh files in CUni after you update the Object Path. One thing you can do is lower the Object Refresh limit in the World Features; this makes files expire sooner, forcing users to download them again (NOTE: this also makes users have to download files more often).

One useful thing to do when you're making changes to the OP is to clear your cache to make sure everything is still intact afterwards. Simply close CUni and delete the folder c:\CUni\cache and its contents. In some cases it might be helpful to clear your Internet Explorer cache as well. Then run CUni again. Note that users probably won't do this, so they might end up with combinations of old and new files for a while (this is a notorious problem with avatar lists).

Test Versions

It might take you several tries to get a new model file working properly, and the browser will generally cache your older attempts. An alternative to refreshing files as described above between tries is simply using a different filename for each one. For example if you're working on a file you will call object.rwx, you can make you first try object1.rwx, your second try object2.rwx, and so on. Once it is working how you want it, rename it to object.rwx and delete all the numbered copies.