Changes between Version 13 and Version 14 of Java Quagents Client


Ignore:
Timestamp:
Sep 1, 2011 4:42:24 PM (13 years ago)
Author:
jherwitz
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Java Quagents Client

    v13 v14  
    3636==== Client (Entity) ====
    3737
    38 The Client entity is an implementation of a QuagentEntity, which is a derived form the aforementioned Entity. It represents a Quagent in the Quake world. The Client is notable because it provides a multitude of convenience methods for executing Commands. We realize that the , so this provides a more functional paradigm for users.
     38The Client entity is an implementation of a QuagentEntity, which is a derived form the aforementioned Entity. It represents a Quagent in the Quake world. The Client is notable because it provides a multitude of convenience methods for executing Commands. We realize that the usage of the original Command execution may unintuitive for some users, so this provides a more functional paradigm.
    3939
    4040=== Commands ===
    4141
    42 The Java client is built on Command objects. These objects each represent one or more commands. Each command must first be instantiated, which sets all relevant parameters and generates necessary structures for use in data retrieval. At this point, the Command is independent of a command "executor". Once the command is constructed, it must then be attached to an executor. This may most easily be accomplished by using the Entity 
     42The Java client is built on Command objects. These objects each represent one or more commands. ProtocolZero commands have a one-to-one correspondance with the commands detailed in [[ProtocolOZero]]. They do not instrument or interpret function, and may be thought of as simply wrapping the protocol commands. ProtocolOne commands, on the other hand, may have an arbitrary level of complexity, or may even not deal with quake at all! These commands may call one or more [[ProtocolZero]] commands, and adjust or interpret data to developer desire. An example may be found in CartesianSensor2D.java. Each command must first be instantiated, which sets all relevant parameters and generates necessary structures for use in data retrieval. At this point, the Command is independent of a command "executor". Once the command is constructed, it must then be attached to an executor. This may most easily be accomplished by using the Entity ''execute()'' or ''start()'' functions, the difference being that ''execute()'' blocks until the command is completed while ''start()'' does not. Once the command has completed execution, the user may access data by calling Command-specific functions. It is important to note that these functions do not block for return, so it is recommended that users use caution when executing non-periodic commands.
     43
     44==== Periodic Commands ====
     45
     46Each Command also has an associated periodic functionality. If desired, the user may add an additional argument to the end of any constructor (or Client entity function), and the Command will execute automatically (in a separate thread) at a period of that many milliseconds. This is very useful for sensors or other queries that the user might want to be updated frequently or automatically.
    4347
    4448=== ReaderThread ===
     
    4751
    4852=== Listeners ===
     53
     54Multiple types of swing-like action listeners have been implemented. The user may choose to use these to achieve a reactive paradigm code style, or mix them with aforementioned styles to create a custom code style.
     55
     56==== Event ====
     57
     58==== Command Termination ====
    4959
    5060== External (User-Level) Structure ==