User Guide

240 APPENDIX D
JavaScript Interpreter Information
Atmosphere includes its own JavaScript interpreter, which is fully ECMA Standards compliant. This interpreter is now
compliant to Level 5, and is used by numerous Adobe applications. All scripts attached to Adobe Atmosphere worlds
are processed by this interpreter, which has been extended with the JavaScript API that appears in these documents.
Scope
As you browse worlds using the Adobe Atmosphere Player, a separate instance of the interpreter is created for each
world that you visit. Additionally, any loaded scene groups or avatars that have JavaScripts attached to them will also
have their own separate interpreter. This is done in order to prevent name collisions between sets of world scripts and
those scripts running on loaded scene groups.
All scripts present in an Atmosphere world will share the same JavaScript interpreter. For example, a world which
contains entries into the “JavaScript URL” fi eld on the Inspector Palette for both a solid object and a scene object
will both share the share the same interpreter. Global variables declared in either of these scripts will be available
to both scripts. Stated another way, if two scripts both defi ne a global variable named “distance”, the last value set
for “distance” will be used by both scripts. If not intentional, this will likely produce unpredictable results during
processing. However, global variable sharing may also be exploited to allow the sharing of state between scripts in a
convenient fashion.
To prevent unwanted name collisions, avoid global variables, and instead use variables attached to the “this” variable,
such as in this.mass = 1.0;. Such an approach will limit the scope of the variables to the script object itself.
Object Loading and Script Execution Order
Understanding the execution sequence of scripts is an important consideration when designing worlds that contain
multiple objects. When you visit a virtual world using the Atmosphere Player, the following load sequence is
performed:
1 Load the world solid objects and corresponding light map information and surface objects immediately.
2 Initiate loading for any Viewpoint objects.
3 Start loading world textures asynchronously, meaning they will be displayed as they arrive. Also note that only
those textures which are visible in the current view will be loaded initially. This approach is intended to minimize
download time and shorten load delay. As the visitor browses the world and new textures are required, they are
loaded asynchronously as well.
4 If present, load and run any JavaScripts present in the World. These JavaScripts may also load other scene groups
asynchronously. (Note that the script attached to the World will always be run fi rst, so that is a good place to
initialize any global variables.)
5 For any primitive or Viewpoint object that fi nishes loading, run its JavaScript if one is present.
6 A script for a loaded object may load other scene groups asynchronously, and so on.