Roadmap

This is a list of features I hope or plan to add to Odin.

At my current rate of progress, I may have at least a private (maybe even public) beta in January.

• Similar to scripts in OmniBot and other bot programs, but more feature-packed and self-contained.
• Plugins can be comprised of multiple PHP script files.
• Plugins will have their own directory structure for things like PHP scripts, configuration files, and language set definition files.

• Methods will exist to check for and/or require the installation of other plugins.
• If one plugin depends on another, it could “require” the other one. If the other plugin is not installed, Odin will prompt the user to install it and then shut down.
• If one plugin has functionality that makes use of or extends another plugin, it could check for the other plugin. If the other plugin is not installed, the application continues normally and the first plugin does not attempt to interact with the other plugin.

• Plugins will be able to define “metadata” on initialization. All metadata will be accessible to all plugins. This is useful for making details of a plugin's configuration public to any dependent or add-on plugins.

Done. Just needs more thorough testing.

• Each bot can connect to a universe, login, and enter a world, but it doesn't have to do all or any of these things.
• Each bot will probably have its own API methods to perform functions of the AW API. For example, there may be say, whisper, consoleMessage, urlSend, and serverWorldList methods.

Done except for v4 data types.

• Type-less wrapper for aw_int, aw_int_set, aw_string, etc.
• Automatically determines attribute data type on getting and setting operations.
  • Will make dynamic attribute settings easier. For example, in the SDK, world attributes cannot be easily modified at runtime, because the type of each must be known to the programmer. In Odin, this will not be necessary.
  • Example usage: When working with world attributes, code does not have to be updated to handle new world features. All attributes are handled dynamically, obviating the need to add type-sensitive code (like aw_int or aw_string) to handle it.
• Read-only attributes will be “virtual”. They can be set, and the bot will hold its own virtual value. When the AW SDK updates the actual attribute value, the virtual one will be discarded.
  • Will enable simulated events and callbacks (which in OmniBot did not work properly because custom values could not be defined for read-only attributes).

Mostly done. Only missing removeHandler, setSynchronous, and stopHandling methods.

• Management of multiple handlers (or observers) for AW events and callbacks with variable priority levels.
• Ability to simulate “virtual” events
  • Example usage: Handling and parsing console messages from bots and simulating chat events (so a bot can use chat commands by console messages).
• Method to switch between blocking and asynchronous operation.
• Instantiable custom event and callback handling interfaces.
  • Will allow plugin developers to easily build their own API and define custom events and callbacks.

Done, except for persistence support.

• Methods to add and remove “timeouts” (like JavaScript timeouts) and scheduled tasks (raw code or functions to be called at a specified time).
• Timers will have optional “persistence”, so that if Odin is stopped or restarted before the timer is reached, the action can be rescheduled when Odin restarts.

Done! After only about a week and a half of brainstorming and two nights of programming.

• Instantiable in-world coordinate management interface.
• Supports relative coordinates (like +0 +0 +1a) and easy modification of individual coordinates (like $coords→x += 10;).
• Supports custom coordinate parameters.
  • Includes two built-in parameter styles: AW and Odin. The Odin style adds a “pitch” parameter and works with the AW browser just like the standard AW style.
    • AW style:
      • Absolute: [world] z x [y] [yaw]
      • Relative: z x [y] [yaw]
    • Odin style (default):
      • Absolute: [world] z x [y] [yaw] [pitch]
      • Relative: z x [y] [yaw] [pitch]
• Intelligently dispatches a callback on coordinate changes such that individual changes are grouped together. For example, even though two changes are made (X and Z), the following code will only dispatch one coordinate change callback:

<?php 
$coords->x = 1000; 
$coords->z = 1000; 
?>

Will be left to the plugin architecture.

• Methods to parse and build object actions triggers and commands.

• Methods to read, write, and check for configuration files and the entries within them.
• Odin will have its own configuration file manager, and each plugin will be able to manage its own set of configuration files.

• Will have support for citizen privileges by number or name, citizen number ranges, tourist names, bot names or privileges by citizen number or name, and Odin user groups.
• Ranges or the wildcard character (*) can be used before citizen number or name negations. This behavior is similar to that of world rights.
• Name resolutions will use native AW API methods in synchronous mode and results will be cached to prevent multiple cross-server API calls from slowing down the application.
• May also support IP-address-based permissions with wildcards.
  • This would be useful in network environments, where all users within a network should have certain permissions.
  • Can also be used to deny permissions to a user with a dynamic IP address.

Will be left to the plugin architecture.

• Methods to retrieve citizen information by name or number.
• Will use synchronous AW API calls to return information immediately.
• Will probably cache results to reduce cross-server AW API calls. Results older than one hour or so will probably either be updated in the background or discarded.
• Handling of nearby users?

• Each bot will have its own userlist. Odin will probably also have a global userlist.
• Userlists can be queried to access information for nearby users.
• The userlist API will support user quieries like those of Hermes and Eclipse Evolution. Citizen numbers, Citizen and tourist names, and bot names and privileges can be used in a query. Partial names may also be given by prepending the ? character to them.
  • This will allow developers quick direct access to the userlist from in-world bot commands without the need to write user query mechanisms.

Will be left to the plugin architecture.

• Each bot will have a HUD manager (like the bot management class Bots).
• The HUD manager will maintain all the available HUD objects for the bot.
• Each HUD element will be an object with public fields corresponding to AW_HUD_ELEMENT_* attributes.
• Each HUD object will have its own developer-defined callback to handle HUD clicks.
• HUD objects will be referenced by string IDs.
• The AW SDK HUD IDs (AW_HUD_ELEMENT_ID attribute) will be managed by the HUD manager to ensure uniqueness, even in an environment where multiple plugins are creating HUD elements.
• To change a HUD element's text on bot 0 and send it to all sessions, a developer would probably do something like this:

Bots::get(0)->huds->get("demo_hud")->text = "Click Me!";  // Sets AW_HUD_ELEMENT_TEXT 
Bots::get(0)->huds->get("demo_hud")->send(0);             // Sends HUD element to all sessions (sets AW_HUD_ELEMENT_SESSION to 0 and calls aw_hud_create)

Will be left to the plugin architecture.

• Language set definition files (or language files) would be built like conf files, with key = value entries and optional [section] blocks.
• Each plugin would have its own language manager, but the bot would manage the default and per-user languages.
• Language file names would be of the form languagecode.conf. The language code could be either an ISO 639-1 “Alpha-1” code or an ISO 639-2 “Alpha-2” code (see http://en.wikipedia.org/wiki/ISO_639 for more information). If one format is specified but a corresponding file is not found, the system would check for a file with a name conforming to the other format.
• If no language file is found for a particular language, the bot's default language (likely en or eng) will be used. If no file is found for that language, no output is possible.
• This could be used to internationalize chat messages, HUD text, and object descriptions or command arguments.

• Like OmniBot's remoteReader, this will attempt three different methods of remote file retrieval to improve the chances of success in all environments.
• Will likely have blocking and asynchronous modes.
• Will send a User-agent header to identify the Odin application and its version and build numbers.

• Like OmniBot's update functionality, but improved.
• Will check for and optionally download updates before initializing the Odin application.
• If multiple builds newer than the currently running build have been released, Odin will download the updates all at once instead of individually. This was possible in OmniBot, but the system was never fully developed and used.
• Because Odin will check for and install updates before the actual initialization, it will be able to download and install updates without having to restart the application. OmniBot shut down and required a manual restart after the installation of updates.
  • Even the application's main PHP script could be updated and run without a restart.
• Could also check for updates for installed plugins.
  • Would happen after application update check and initialization.
  • Odin would send a list of installed plugins to the update server, which would return a list of updated plugins and the files that Odin should download (hosted on the Odin update webserver or a plugin developer's server).

Will be left to the plugin architecture.

• May write a plugin or built-in module to communicate with local and remote client interface programs.
• Would put an optional GUI on the application that can be closed at any time.
• The user could restrict access to the local machine or a list of remote hosts.
• Plugins could make use of the interface plugin by defining remote command callbacks to be triggered when a command is sent from a connected client.
• Input would be in the form of plugin_name command arg1 arg2 ….
• Output would be in the form of responses and events.
  • Responses: plugin_name command response_code response_attribute1 response_attribute2 ….
  • Events: plugin_name event event_attribute1 event_attribute2 ….
• It is up to the plugin developer to define and use argument and attribute syntax.
• Uses:
  • A plugin could be written to make Odin a chat bot application. The user (or users via a public web interface) could send chat to one or more worlds.
  • A world map of objects or avatars could be viewed by the local user or by remote users.
  • AJAX-based chat.
    • Messages from the end-user would be commands sent through a server-side PHP script to a plugin running in Odin.
    • A response would be sent from the plugin in Odin to the PHP script, which would exit and return to the end-user.
    • Messages from the in-world users would be events from the plugin running in Odin to an instance of the server-side PHP script that is waiting for events from Odin.
    • It would work like any other AJAX-based chat system, like that of Facebook for example.

• Good for those who may have several instances of Odin running (for example, bot hosts).
• A single server application would run and handle connections and packets for multiple instances of Odin.
• Several instances of Odin could be reached through a single port.

• (Odin Client-side Application Framework JavaScript library)
• I may write an application framework in JavaScript to build Odin server commands and send them through AJAX calls to a PHP script.
• It would load plugin client scripts to build GUIs and communicate with Odin and its plugins.

• (Odin Client Platform)
• I may write a PHP client platform to provide a client-side HTML interface for plugins.

• Odin will be downloadable in pacakages with binaries of PHP and php_aw, for both Windows and Linux. Batch files (Odin.bat and Odin-background.bat) for Windows will be included to easily run Odin. This will make it easy for less knowledgable users to install and run Odin.
• Also, Odin's update manager could check for and download updates to PHP and php_aw.