< Back

Active Worlds

Object Properties Dialog Box Prototype

Note: This form could be tighter but buttons and other GUI controls (text input fields, checkboxes, pull-down menus, etc) are displayed differently (width/size, spacing, etc) in various web browsers/OSes. Also, because HTML forms don't allow dynamic addition/deletion of form elements (yea, I could use layers and Javascript, but it's more work I care to put into this), this example isn't fully representative of the below options. Some form elements should remain hidden (denoted by the cell having a darker background color) until their parent command is selected so as to not clutter up this dialog any more than it needs to be, while remaining simple and easy-to-use. So, for example, if the "create" trigger and "name" command are selected from the pull-down menus, only the "Object:" and "Name:" rows should show.

Also, the "Description" and "Action" fields (table rows) should not be shown if an object does not have anything for them. In these cases, "Description >" and "Action >" buttons can be present so that when pressed, the appropriate subfields appear (then disappear if pressed again--but now as "< Description" and "< Action", yet still remembering their field contents, if any).

Object Properties detach
  1. dockable, resizable, optionally semi-transparent (Windows 2000/XP+ only)
  2. pull-down menus: Edit > Undo, Redo, Cut, Copy, Paste (plus global object properties cut/copy/paste), Undo/Redo (which should use standard Windows ctrl+z and ctrl+y commands instead of non-standard--and non-working--"backspace", which is useless in a field anyway), Move, Rotate, etc
  3. toolbar buttons: configurable so as not to unnecessarily widen the dialog any more than it has to be; wrapable
  4. object pull-down menu: with the current object's name selected and names of all objects (RWXes in ZIP files) in the object server's "models" directory listed. Hopefully this list wouldn't have to be updated each time an object was selected.
  5. trigger pull-down menu: "create", "activate", and "bump"
  6. command pull-down menu: "animate", "sign", "URL", "picture", "sound", "noise", "visible", "warp", "teleport", "solid", and "name"; when one is selected:
    1. "animate": Pull-down menu with the name of all textures (JPG files) in the object server's "textures" directory could appear. Hopefully this also wouldn't have to be updated each time an object was selected. Otherwise, a text entry field (edit box) where the texture name would be entered. Because this command is rather complex, a text-entry field would probably be the best option. However, a better design would be to use branching ([+]/[-])commands or even some kind of integrated flowcharting.
    2. "sign": Edit box where the sign text would be entered could appear. Then 2 buttons with a "color" label above: "background" and "foreground", where, clicking either, would bring, say, the color selection dialog that appears in the menu: Options | World... | Features > Backdrop Color > "Change..." button option.
    3. "URL"/"picture": Edit box could appear (with "http://" in front, but not IN the typing portion, since the "http://" is not needed, but assumed) where the URL is entered. Additionally, with "picture", an "update" checkbox with a small edit box for the # of seconds could appear.
    4. "sound"/"noise": Pull-down menu with the name of sounds (WAVs/MIDs as ZIP files, or MP3s) in the object server's "sounds" directory could appear for relative paths. Otherwise, an edit box where the file could be entered could appear for absolute paths.
    5. "visible": Pull-down menu with "me" (or "self" or "current") and "other" (or include other in-range named objects). Or if "other" is selected, (optional) if other objects are named in the area (cell/sector?), a pull-down menu with their names; otherwise an edit box where the name of the other object's name could be entered. Also, a pull-down menu would appear with "on" and "off" or just a checkbox.
    6. "warp"/teleport "teleport": Edit boxes for north-south and east-west coordinates (with appropriate pull-down menus for north-south and east-west); altitude and direction edit boxes. Similar to this: _# edit box_ <"N"/"S" pull-down menu> _# edit box_ <"E"/"W" pull-down menu> "altitude": _# edit box_ "facing": _# edit box_
    7. "solid": "on"/"off" (or "yes"/"no") pull-down menu or just a checkbox.
    8. "name": Edit box where the name would be entered.

  7. Unassociated command options should be hidden (preferably) and/or disabled (greyed out).
  8. Multiple, linked actions (currently separated by a semi-colon) could be done with a "More >" button, bringing up additional trigger and command pull-down menus, with the argument edit boxes or pull-down menus to follow, as needed; or just another object properties box, though these methods would clutter up the screen quicker. A "< Less" button could remove extra commands. And since only relevant information would be shown, even with multiple actions the dialog shouldn't be that cluttered. For "old-timers" and die-hard programmers, the traditional all-text commands could still be used.
  9. The action triggers/commands/options could be abbreviated to however AW could interpret them, with as few bytes (preferably binary instead of ASCII--at least for pull-down menus and checkboxes) used as possible so as to reduce cell byte data use, but the GUI presentation of doing object properties would remain more detailed.
  10. "States" of all the options could be saved and loaded so multiple-object property application would be easier. But with enhanced multiple object manipulation this shouldn't be that big a deal.

< Back