			QuakeBot C/S

                        V.70  beta

                        Jim Rorie
			jfrorie@uncc.edu

                        John Simmerman
                        jksimmer@uncc.edu


QuakeBot C/S is a Client/Server Bot core for creating functional 
deathmatch bots. It does NOT provide AI.  That's your department.  
We handle everything else.

My idea behind the name is to separate this QuakeBot from QuakeC
Bots.  It works by a Client/Server link, thus the C/S.  It does not
implement a server currently, but InterBot communications will be 
implemented shortly giving full meaning to the name.


Compiling:

MSC V4.X:

The program uses winsock calls under MS Visual C++ v4.X.  It should compile
under most PC compilers. I made it as portable as I could.  

To get MS VC++ V4.X to compile this properly, do the following:

A) create a console application project.
B) In the project, go to Build->Settings.  Click the C/C++ Tab.
	Change "category" to "code generation".  The options will change.
	Change "use runtime library:" to "Debug Multithreaded"
C) Go to Build->Link
D) Add wsock32.lib to Object/Library Modules

UNIX:

It may or may not compile under UNIX.  Currently, your byte ordering needs
to the same as a PC (little endian, I think).  This version has added a
thread to the code which is implemented differently under different
UNICES.  Linux may support lightweight process and would be a good
canidate.

I have added some conditionals supplied by a couple of gurus. They should
make your life a little easier.  But there are no guarantees.  If you
get it working under your OS, fire your changes back to me and I will
incorporate them, and give due credit.

Other:

Other compilers.....Your on your own.  If you get it to compile under 
Borland or something else, mail me so I can document the procedure.

	
What it does:

This module will log you into a quake server and perform everything necessary
in the game initialization.  Runtime packets are decoded and the data stored
in the server and player objects.  You give commands to the Bot via the
RuntimeThread() function. The supplied runtime function will pursue a player
and fire if he is in a defined range.  The bot will also respawn after death.  It is
It's pretty damn stupid.  Objects will trip it up if they are in its path.

There is a say commands that will allow you to kick the bot.  If a player says
"no bots" (case insensitive), the bot will immediately exit.  It is a little
feature to prevent you from driving players crazy while testing your AI.
Don't worry, most players like competeing against it, and most want to know
more about it.  If it gives you a problem, disable it.


Limitations:

My suggestion for future compatibility is to create your own AI and navigation
objects so that they can be easily incorporated in newer releases.  This
core is still pretty crude and will see much more changes.  If you see a need
to modify my code to correct a bug, MAIL ME!!!  I will incorporate the changes
in the next release.

It only works under TCP/IP and MS winsock.  Haven't tested it with trumpet,
but it should work. You must supply an IP address.  Address names don't work,
currently.

The handshake is pretty clean now, and I don't expect any problems.  It 
has been tested on several servers with many different patches.
Unfortunately, there are about a billion different combinations.  If you
have a problem with a particular server, send me the name and the patch
it is running, if possible. I will look into it.  

My technique for determining player death hasn't been tested fully, so it 
may have problems.  Currently, I check to see if the player's model frame
is within a certain range.  If it is, I assume the player is dead. I really,
really would like suggestions in this area. I know I can parse the console
say strings, but there must be something a little slicker to solve this
problem.


Runtime Console:

New with this release is a runtime console that allows you to bring up
certain information by command.  The following commands are implemented:

Say - Broadcast message to server.  All console says are differentiated from
        bot says by prepending "(Console)" to all messages.
Net - Network Statistics.
Game - Games Stats.
Player - Player Info.
Model # - The name of model # entry in the Precache.
Entity # - Entity information.
Quit - Quit Client.

The input is scattered by incoming messages and other printouts since the
console runs in a separate process.  I will clean this up later.  For now,
deal with it.


What I want:

FEEDBACK!!!!  I need some people to play with this thing and tell me what is
needed. I am not a Quake specialist, more of a hack. I don't know how Quake
deals with identification of cetain objects, like how can I tell what an
entity is?  I know some ways of doing it, but they are rather kludgey and
I'd rather not.

Also, if you use this code for building your own bot, I require that you
either leave the "QuakeBot C/S(c)" broadcast message or modify it to show that
it is based on the core.  i.e. "Based on QuakeBot C/S(c) core", etc.  Other
than that, hack away.


Future Mods:

My next task is to tackle navigation. I intend to implement a simple
waypoint navigation system.  It will work by using objects in the level
as waypoints and creating vector connections between them. The limitation
is that need to be an object nearby to reference.  Fortunately, as the
game progresses, these are provided in the form of corpses.
By itself, it will be somewhat crude but workable. But this, combined
with a BSP tree parser, will be deadly.

I want to clean up the code a little further. The AI and nav object should
have their own threads and communicate to the server object via member
functions.  Maybe add a semi-graphical popup to display something of what
is going on the in the game.

The current version of QuakeBot C/S can always be found at:
http://www.coe.uncc.edu/~jfrorie


						Have Fun,
						Jim
  

Known Bugs:

Still some handshaking problems with certain servers.  They occur on modified
play server such as capture the flag, teamplay, MOTD or other heavily modified
systems.  Use another server for now.

The timestamp is WRONG!!  I don't know what it references to, therefore I can't
fix it yet. Ping times of 8,000,000 or more are normal.  These aren't the actual ping
times, just the calculations based on the (wrong) number I am sending.  


Fixes:

Level change MAY have been fixed.  Let me know.

Fixed massive memory leaks.

Entities are fully tracked.

Respawn problem taken care of.

Some conditionals to support unix compilation.  Little endian only, currently.

Full tracking of all entities. Finally!!!

The player objects now have their inventory, stats, etc. updated.

Corrected a bug that was sending duplicate packets.

Corrected the ACK sequences.  Previous version would desync if the server
missed an ACK and would no longer receive reliable messages.

Cleaned up the display, A LOT.

