[Rccparser-commits] CVS: rcclient NEWS,1.3,1.4 README,1.3,1.4

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Update of /cvsroot/rccparser/rcclient
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv17459

Modified Files:
	NEWS README 
Log Message:
2003-01-10	Tom Howard	<tom...@us...>

	* ./configure.ac
	Released rcclient-0.0.1

Index: NEWS
===================================================================
RCS file: /cvsroot/rccparser/rcclient/NEWS,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** NEWS	10 Jan 2003 18:56:47 -0000	1.3
--- NEWS	8 Jul 2004 02:52:33 -0000	1.4
***************
*** 1,2 ****
--- 1,8 ----
+ [0.1.0]
+   * RCClient interface has been completely rebuilt and it now used the
+   RCCSerializer libraries to provide serialization functions.  Please see the
+   README files for details on how to use the CLient libraries and rcctest for
+   and example.
+ 
  [0.0.1]
    * RCClient supports compressed communications with the server, through
***************
*** 25,29 ****

    What's more, you CANNOT send any data after your request to change to
!   the compression level until the server has responded of you give up
    the request as lost.  Sound nasty?  Well it is.  Unfortunately there is
    no nice solution because the server uses plain UDP, which does not
--- 31,35 ----

    What's more, you CANNOT send any data after your request to change to
!   the compression level until the server has responded or you give up
    the request as lost.  Sound nasty?  Well it is.  Unfortunately there is
    no nice solution because the server uses plain UDP, which does not
***************
*** 31,35 ****
    we can get.

!   The rcctest example now uses compression, so demostrate how it's done. 

  [0.0.0]
--- 37,41 ----
    we can get.

!   The rcctest example now uses compression, to demostrate how it's done. 

  [0.0.0]

Index: README
===================================================================
RCS file: /cvsroot/rccparser/rcclient/README,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** README	10 Jan 2003 18:56:47 -0000	1.3
--- README	8 Jul 2004 02:52:33 -0000	1.4
***************
*** 4,10 ****
  (http://sserver.sf.net). The library is designed for use with the
  RCCParser library and provides complete network send and receive
! functionality for version 7 and 8 players (including goalies).  Send
! support for other clients (coaches) will be added soon (recv
! functionality is already implemented).

  =========== CONFIGURING ===========
--- 4,9 ----
  (http://sserver.sf.net). The library is designed for use with the
  RCCParser library and provides complete network send and receive
! functionality for version 7, 8 and 9 players (including goalies and
! coaches).

  =========== CONFIGURING ===========
***************
*** 89,125 ****
  ================ USING THE LIBRARY ================

! The parser can be interfaced with your code by adding

! #include <rcclient/rcclient.h>

! in one of you source files.  You can then create an instance of a
! rcc::Client by passing it an instance of a rcc::Parser, the port you
! wish to connect on and the host name of the machine running the
! server.  For instance

! rcc::Client your_client( your_parser, server_port, server_host );

! You would then send an init message to the server by calling
! init(). E.G.

! your_client.init( your_teamname, protocol_version, goalie_flag );

! Apon receiving your init message, the server will start to send data
! to your client. You can start parsing the data by either calling the
! operator() or by passing your client to a thread and have it call the
! operator().  The operator() is used to provide direct compatibility
! with rcss::thread::Thread.

! The operator() does not return until some error in parsing has
! occurred, so if you chose not to use a threaded approach (which is a
! perfectly valid thing to do) you will only be able to call send
! functions (such as dash and turn) from within the rcc::Parser virtual
! functions.

! Also note, if you choose to use a single threaded approach you will
! also have to make sure that you return promptly from any of the
! rcc::Parser virtual functions.  Failure to do so may result in a
! backup of data and potential data loss if the network buffer
! overflows.

  RCClient supports compressed communications with the server, through
--- 88,132 ----
  ================ USING THE LIBRARY ================

! To use the library you must subclass from rcc::Player, rcc::OnlineCoach or
! rcc::OfflineCoach, which will allow you to override the parser fuctions and
! provide you with access to the serialization functions. rcc::Player,
! rcc::OnlineCoach and rcc::OfflineCoach subclass rcc::Parser and either
! rcc::PlayerSerializer, rcc::OnlineCoachSerializer or
! rcc::OfflineCoachSerializer respectively.

! The following is an example of how to create a Player Client.

! #include <rcclient/rccplayer.hpp>

! class EGPlayer
!     : public rcc::Player
! {
! private:
!     virtual
!     void
!     doBuildInit( int unum ) 
!     {
!         std::cout << "Got init\n";
! 	move( -10, -10 );
!     }
! };

! In this example the client will move to position (-10, -10), whenever an init
!  message is recieved.

! rcc::Player, rcc::OnlineCoach and rcc::OfflineCoach use iostreams for
! communication with the server.  Convienience decorator classes are provided
! that create a UDP iostream and set them in your player.  For instance

! EGPlayer player;
! rcc::UDPPlayer udpplayer( player, addr );

! will connect your player to the address specified by addr.

! To start your client you then use the overloaded () operator.  This will call
! onStart() and then proceed to parse data until there is no more left or an
! error occurs.  Since the server will not send you any data until your client
! has sent and init message, you must call the init() serialisation function
! within onStart().

  RCClient supports compressed communications with the server, through
***************
*** 127,131 ****
  change the current compression level (default is none), you first need
  to send the request to the simulator, which is done with the
! compression() function.  The server will then reply with either

  (ok compression LEVEL)
--- 134,138 ----
  change the current compression level (default is none), you first need
  to send the request to the simulator, which is done with the
! compression() serialisation function.  The server will then reply with either

  (ok compression LEVEL)
***************
*** 148,152 ****

  What's more, you CANNOT send any data after your request to change to
! the compression level until the server has responded of you give up
  the request as lost.  Sound nasty?  Well it is.  Unfortunately there is
  no nice solution because the server uses plain UDP, which does not
--- 155,159 ----

  What's more, you CANNOT send any data after your request to change to
! the compression level until the server has responded or you give up
  the request as lost.  Sound nasty?  Well it is.  Unfortunately there is
  no nice solution because the server uses plain UDP, which does not