108 | | ==== Running it all ==== |
| 108 | Note: The following may vary depending on QuagentEntity type, but the steps necessary are invariant and will only differ syntactically. |
| 109 | |
| 110 | The first step in creating a Quagent is construction. This is accomplished by calling the constructor with a parameter of the Quagents3 server IP address, in string form. That is: |
| 111 | |
| 112 | {{{ |
| 113 | Client quagent = new Client("127.0.0.1"); |
| 114 | }}} |
| 115 | |
| 116 | |
| 117 | Next, we have the initialization phase. The quagent does not spawn on construction. Instead, we have a buffered connection to the server in which we may modify certain initial attributes. Among these are in-game name, spawn location, and team. When these attributes are set (for information on syntax, see javadoc) the developer may call the ''ready'' function. This finalizes all initial attributes and spawns the Quagent in-game. Trivially, it is implemented as: |
| 118 | |
| 119 | {{{ |
| 120 | quagent.ready(); |
| 121 | }}} |
| 122 | |
| 123 | The quagent has now entered the live phase of the game, during which most commands are unlocked for use. While many of these exist, the usage is constant throughout. Generally, the user must create an object for the Command they are about to execute. Then, the developer must execute it ''through a quagent''. There are two options for this, the ''execute'' function which blocks until the command is returned from the server, or the ''start'' function which is non-blocking. For instance, |
| 124 | |
| 125 | {{{ |
| 126 | Rotate r = new Rotate(180); |
| 127 | quagent.execute(r); |
| 128 | }}} |
| 129 | |
| 130 | or |
| 131 | |
| 132 | {{{ |
| 133 | Rotate r = new Rotate(180); |
| 134 | quagent.start(r); |
| 135 | }}} |
| 136 | |
| 137 | are both valid. Additionally, the Client class provides many convenience functions, which allow execution directly through the quagent, of the form: |
| 138 | |
| 139 | {{{ |
| 140 | quagent.rotate(180); |
| 141 | }}} |
| 142 | |
| 143 | Data and exit codes returned by these functions may be accessed through member getter functions. Note that these do not block, so usage of the Command or Quagent ''waitForTerminate'' (which blocks for return) function will ensure updated data. |
| 144 | |
| 145 | It is also possible to enable client-based periodic functions. These execute every specified period. In order to enable this execution, simply append the desired period (in milliseconds) to the end of the constructor or function. For example, |
| 146 | |
| 147 | {{{ |
| 148 | Facing facing = new Facing(100); |
| 149 | }}} |
| 150 | |
| 151 | will execute a Facing command every 100ms. This functionality is useful for sensor simulator or obtaining periodic data on the scenario execution. |