Changeset 1781

Timestamp:

08/20/07 13:28:48 (3 years ago)

Author:

dugwyler

Message:

Re-enabled player position tracking by default due to the discovery of its very low overhead (setup.cfg can be used to turn on or off all tracking by default, and at what rate);
updated Player to reset bounty to 0 in appropriate places, and then wait until next position packet to confirm actual bounty, as well as JavaDoc updates;
updated Arena with more accurate information about the problem with playerIDs;
renamed PlayerDeath's getScore() method to more accurately reflect its actual purpose. (Another revision will follow to conform to this update.)

Location:

trunk/twcore/src/twcore/core

Files:

• BotAction.java (modified) (4 diffs)
• events/PlayerDeath.java (modified) (1 diff)
• game/Arena.java (modified) (4 diffs)
• game/Player.java (modified) (26 diffs)

trunk/twcore/src/twcore/core/BotAction.java

@@ -91 +91 @@
         m_positionTask = null;
         DefaultSpectateTime = getCoreData().getGeneralSettings().getInt( "DefaultSpectateTime" );
+        setPlayerPositionUpdating(DefaultSpectateTime);
     }
 
@@ -2259 +2260 @@
     /**
      * Turns automatic player position updating on and off.  By default it is ON,
-     * and set to change between the players it spectates for packets every 5000ms.
-     * The lower the number, the more reliable any position information stored in
+     * and set to change between the players it spectates for packets at the rate
+     * specified in setup.cfg under the DefaultSpectateTime field (in ms).  Clearly
+     * the lower the number, the more reliable any position information stored in
      * Player will be, and the more frequently and reliably will the bot receive
-     * PlayerPosition events.  It is strongly advised that if you do not use
-     * position packets that you set the time to 0 (completely off).
+     * PlayerPosition events.  The network load is almost inconsequential,
+     * particularly with DefaultSpectateTime at values >1000 -- it requires only 3
+     * bytes sent each specified tick -- but it is recommended to turn this feature
+     * off by using a 0 value if you will not need reliable information in Player
+     * classes.  (Name, playerID, ship type, wins and losses do not rely on this.)  
      * <p>Note that because TWCore is a client emulator (does not operate on the
      * server side but logs in as a bot) it only receives position packets from
      * the server about players within radar range.  This is why it must switch
-     * who is being spectated in order to get as many packets as possible.  This
-     * process may be CPU-intensive when done rapidly.
+     * who is being spectated in order to get as many packets as possible.  Fortunately
+     * this process requires only minimal load.
      * <p>If the arena the bot operates in is small, you may want to manually
-     * adjust its position using the move() methods for efficiency.
+     * adjust its position using the move() methods to most effectively receive packets.
      * @param milliseconds - specified time to update player positions at
      * 0     : turns tracking off and has the bot spectate its current area (change with move())
@@ -2302 +2307 @@
 
     /**
-     * Starts the automatic player position updating system with the most reliable
-     * positioning TWCore offers (switching between players every 200ms).  This
-     * will cause the bot to switch which players it is spectating once every 5
-     * seconds.  On slower systems and older network connections this may be
-     * quite taxing.
-     * <p>If you wish to switch faster than every 200ms, you must manually edit
-     * Arena.java and hardcore a new value.
+     * Starts the automatic player position updating system at the default
+     * rate in setup.cfg.  The load on the network is a fairly trivial 3 bytes sent
+     * at each change of player that the bot is spectating.
+     * <p>Note that 200ms is the default floor value.  If you wish to switch faster
+     * than every 200ms, you must edit the setPlayerPositionUpdating method manually.
      */
     public void startReliablePositionUpdating() {
@@ -2318 +2321 @@
      * stop spectating the player it is currently spectating on, and cease
      * switching between players to update position packets.  Use this if your
-     * bot will not be receiving position packets.
+     * bot will not be receiving any position packets.
      */
     public void stopReliablePositionUpdating() {

trunk/twcore/src/twcore/core/events/PlayerDeath.java

@@ -73 +73 @@
 
     /**
-     * Gets the score resulting from the kill. NOTE: this currently
-     * just returns the bounty and not the entire score.
-     * @return the points gotten from the kill
+     * Gets the bounty of the player who was killed.  This is not the amount of bounty
+     * added to the player who made the kill, or the amount of points to add.
+     * @return Bounty of the player who was killed.
      */
-    public short getScore(){
+    public short getKilledPlayerBounty(){
         return m_score;
     }

trunk/twcore/src/twcore/core/game/Arena.java

@@ -36 +36 @@
  * "Player ID" refers to the internal packet ID used by the SS protocol rather than
  * the player's UserID found in ?userid.  IDs are assigned sequentially arena-wide
- * rather than zone-wide.  In almost all cases, an ID is sent as 2 bytes; however,
- * short position packets, used to update frequent info on a player, send ID as 1 byte.
- * This doesn't become a problem until we have >255 people in an arena, after which a
- * client with a movement prediction algorithm has no real trouble distinguishing between
- * two players with the same 1-byte ID, but a bot core does.  Fair warning!  -qan
+ * rather than zone-wide.  Large position packets send 2 bytes for ID, and small
+ * position packets send only 1; on the offchance that more than 256 players are in
+ * the arena at the same time, the server will begin sending only large position
+ * packets to alleviate potential problems with the same lower byte in two IDs.<br>
+ * However, if a player leaves the arena, their ID is freed up to be used by another
+ * player.  This can cause confusion in bots attempting to remember players primarily
+ * by their ID -- and for the reason that only 19 of a possible 23 characters of a
+ * player's name is accessible (aside from using *info) name is also not reliable.
+ * A combination of the two may be used, or just fairly meticulous planning.<br>
+ * A last word: using Arena's getPlayer(ID) method is more reliable than getPlayer(name),
+ * for the reasons described above.  If you need to get a Player object, try to do
+ * so by player ID rather than name.  For utmost security also compare the name in
+ * the Player object with the expected one.  
  */
 public class Arena {
@@ -353 +361 @@
         return list.size();
     }
+    
+    // *** EVENT PROCESSING ***
 
     /**
@@ -678 +688 @@
     }
 
+    // *** PLAYER OBJECT UPDATING ***
+    
     /**
      * Adds a playing player into the tracker queue to be spectated by the bot
@@ -735 +747 @@
     }
 
+    /**
+     * Turns on or off the system of changing the bot's spectating target.  Each time a
+     * change is made in who is being spectated, 3 bytes are sent -- plan accordingly.
+     * @param enable
+     */
     public void setEnableSpectating(boolean enable) {
         synchronized(m_tracker) {

trunk/twcore/src/twcore/core/game/Player.java

@@ -18 +18 @@
  * relevant or useful being stored here.
  * <p>
- * A VERY IMPORTANT consideration is that a player's X & Y location, X & Y velocities & rotation
- * amount may not be accurate / updated.  Use BotAction's setPlayerPositionUpdating() to make
- * this information more reliable.
+ * A <b>VERY IMPORTANT<b> consideration is that a player's X & Y location, X & Y velocities, rotation
+ * amount, weapons and accessories data (XRadar, shields, etc) may not be accurate / updated.
+ * Use BotAction's setPlayerPositionUpdating() to make this information more reliable.
+ * <p>
+ * Also note that <b>using the player's name is not a reliable method of identification</b>.
+ * Only 19 of a possible 23 characters are stored; two players whose first 19 characters
+ * of the name are identical can not be separated by the bot except by their player ID.
+ * This brings the <i>additional<i> problem of player ID being represented in a single byte,
+ * or 256 possible values, with ID re-use being possible -- this means that ID is also not
+ * a reliable method of identification; it is useless if the player is not in the arena, and
+ * it is not static in any sense.    
  */
 public class Player {
@@ -52 +60 @@
     private LinkedList<Integer> m_turrets;       // List of player IDs (Integer) that are attached
 
+
+    // The following data is generally considered so unreliably tracked as to be almost meaningless --
+    // even moreso than standard position data found in a short position packet.  It is supplied for the
+    // sake of completeness only, and it's not recommended anyone attempt to use it.  Coder beware.
+    
     private boolean m_stealthOn;        // Status of Stealth
     private boolean m_cloakOn;          // Status of Cloaking
@@ -204 +217 @@
         if( message.getKillerID() == m_playerID ){
             m_wins++;
-            m_score += message.getScore();
+            // This particular operation (adding bounty of the killed to score) is questionable;
+            // we should be using settings to properly adjust the score.  We should also update
+            // bounty as appropriate.
+            // TODO: When arena settings storage class is implemented, use to properly update score & bounty.
+            m_score += message.getKilledPlayerBounty();
         } else if( message.getKilleeID() == m_playerID ){
             m_losses++;
+            m_bounty = 0;       // As a precaution; we will retrieve bounty at next position packet
         }
     }
@@ -260 +278 @@
 
         m_frequency = message.getFrequency();
+        m_bounty = 0;       // As a precaution; we will retrieve bounty at next position packet
     }
 
@@ -270 +289 @@
         m_frequency = message.getFrequency();
         m_shipType = message.getShipType();
+        m_bounty = 0;       // As a precaution; we will retrieve bounty at next position packet
     }
 
@@ -402 +422 @@
 
     /**
-     * @return Name of the player
+     * Gets a String of the first 19 out of a possible 23 characters of this player's name.
+     * Note that <b>using the player's name is not a reliable method of identification</b>.
+     * Only 19 of a possible 23 characters are stored; two players whose first 19 characters
+     * of the name are identical can not be separated by the bot except by their player ID.
+     * @return First 19 out of 23 possible characters of the name of the player
      */
     public String getPlayerName(){
@@ -574 +598 @@
 
     /**
-     * @return Player's last recorded amount of energy left
+     * @return Player's last recorded amount of energy left.  Not reliable
      */
     public short getEnergy(){
@@ -645 +669 @@
 
     /**
+     * Returns the score as tracked by TWCore.  TWCore does <b>NOT</b> currently track
+     * score properly -- this is provided as a working approximation only. 
      * @return Overall point score of the player
      */
@@ -653 +679 @@
 
     /**
-     * @return True if player has shields
+     * @return True if player has shields (UNRELIABLE; DO NOT USE)
      */
     public boolean hasShields(){
@@ -660 +686 @@
 
     /**
-     * @return True if player has super
+     * @return True if player has super (UNRELIABLE; DO NOT USE)
      */
     public boolean hasSuper(){
@@ -667 +693 @@
 
     /**
-     * @return Total number of bursts player currently possesses
+     * @return Total number of bursts player currently possesses (UNRELIABLE; DO NOT USE)
      */
     public int getBurstCount(){
@@ -674 +700 @@
 
     /**
-     * @return Total number of bursts player currently possesses
+     * @return Total number of bursts player currently possesses (UNRELIABLE; DO NOT USE)
      */
     public int getRepelCount(){
@@ -681 +707 @@
 
     /**
-     * @return Total number of bursts player currently possesses
+     * @return Total number of bursts player currently possesses (UNRELIABLE; DO NOT USE)
      */
     public int getThorCount(){
@@ -688 +714 @@
 
     /**
-     * @return Total number of bricks player currently possesses
+     * @return Total number of bricks player currently possesses (UNRELIABLE; DO NOT USE)
      * @deprecated "Walls" is not a clear term.  Made this a wrapper for getBrickCount
      */
@@ -697 +723 @@
 
     /**
-     * @return Total number of bricks player currently posesses
+     * @return Total number of bricks player currently posesses (UNRELIABLE; DO NOT USE)
      */
     public int getBrickCount(){
@@ -704 +730 @@
 
     /**
-     * @return Total number of decoys player currently possesses
+     * @return Total number of decoys player currently possesses (UNRELIABLE; DO NOT USE)
      */
     public int getDecoyCount(){
@@ -711 +737 @@
 
     /**
-     * @return Total number of rockets player currently possesses
+     * @return Total number of rockets player currently possesses (UNRELIABLE; DO NOT USE)
      */
     public int getRocketCount(){
@@ -718 +744 @@
 
     /**
-     * @return Total number of portals player currently possesses
+     * @return Total number of portals player currently possesses (UNRELIABLE; DO NOT USE)
      */
     public int getPortalCount(){
@@ -725 +751 @@
 
     /**
-     * @return True if ship has Stealth on
+     * @return True if ship has Stealth on (UNRELIABLE; DO NOT USE)
      */
     public boolean isStealthed(){
@@ -732 +758 @@
 
     /**
-     * @return True if ship has Cloaking on
+     * @return True if ship has Cloaking on (UNRELIABLE; DO NOT USE)
      */
     public boolean isCloaked(){
@@ -739 +765 @@
 
     /**
-     * @return True if ship has X-Radar on
+     * @return True if ship has X-Radar on (UNRELIABLE; DO NOT USE)
      */
     public boolean hasXRadarOn(){
@@ -746 +772 @@
 
     /**
-     * @return True if ship has Antiwarp on
+     * @return True if ship has Antiwarp on (UNRELIABLE; DO NOT USE)
      */
     public boolean hasAntiwarpOn(){
@@ -753 +779 @@
 
     /**
-     * @return True if ship is warping in/cloaking/uncloaking (display flash on client)
+     * @return True if ship is warping in/cloaking/uncloaking (display flash on client) (UNRELIABLE; DO NOT USE)
      */
     public boolean isWarpingIn(){
@@ -760 +786 @@
 
     /**
-     * @return True if ship is currently in safe
+     * @return True if ship is currently in safe (UNRELIABLE; DO NOT USE)
      */
     public boolean isInSafe(){
@@ -767 +793 @@
 
     /**
-     * @return True if ship has UFO on
+     * @return True if ship has UFO on (UNRELIABLE; DO NOT USE)
      */
     public boolean isUFO(){
@@ -788 +814 @@
 
         /**
-         * Gets a String representation (name) of this player
+         * Gets a String of the first 19 out of a possible 23 characters of this player's name.
+     * Note that <b>using the player's name is not a reliable method of identification</b>.
+     * Only 19 of a possible 23 characters are stored; two players whose first 19 characters
+     * of the name are identical can not be separated by the bot except by their player ID.
          * @return the player's name
          */