Remove all Player Info routines from lib.

   Finish changing the last few string handling routines to memory copies to speed up the routines.

   Rewrite Send_Reliable_Message(), Send_Unreliable_Message(), and Send_Easy_Message().

   Allow more UDP variables to be changed through Set_Comms_Variable()

   The string (in a newtype) which holds the reliable message sent, has to be changed to a buffer.

   I need to convert the routines to C, and then create an Amiga shared lib, and example programs in C (including a small game).

   Then port the lib to other OSes- in order QNX, MorphOS, Windows, Linux and Amiga OS4.0 (if it eventuates), and create example programs for each OS. I could look at Mac later maybe.

   Maybe at the same time, I'll port it to Blitz Basic on Windows and PureBasic (Amiga, Windows, Linux).

   Add some more `Easy To Use' routines similar to others in Blitz (DirectPlay (tm)) and PureBasic, and maybe put them in a separate lib, so advanced programmers can use less memory if they don't need them.

   Data from the player at your machine, will be put into the incoming data buffer and will be delt with the same as the other player's (ie: the single-player data will be handled the same as the multi-player). This way we can put an artificial lag into the player's movements when using Peer-To-Peer, to prevent there being too much of a discrepancy in a player's position on different machines if you have higher lags.

   Each player needs to send out a `heartbeat' if they haven't sent a packet for 5 seconds, so other players know they're still online.

   Maybe it should check through all the unacknowledged packets for one that's overtime, rather than just the oldest one, as it does at the moment.

   I need to improve the code to test wether the game is running in NTSC or PAL. Also, some of the time-sync code could be made more robust by checking the standard deviation of the lags.

   I'll have to put in a new protocol with reliable messages, you will be able to make sure the packets are received in the correct order at the other machine- any lost/slow packets are waited for first (buffered) before the later packets are passed to your game. This is handy for copying files, like maps from the Server.

   I have to get it to check wether any incoming packets have been dropped, and ask for a resend, rather than just the sender checking- this will speed up some resends.

   Allow for non game critical data like `Taunts' (samples to be triggered by another player) etc, to be transfered after login by trickle feed (so as not to take up too much bandwidth).

   I have to change the `player honesty' system (if a player loses connection with another player when the rest haven't), as it could be got around with packet filtering- I would just send the messages with the Client-Server protocol instead between those two players.

   For Client-Server routines I'll make a `packet gathering' option for the Server, so it'll gather packets on one frame and send them all out together in one packet on the next frame, so at 50 fps, the Clients would never receive more than 2 packets per frame, no matter how many players there were in the game (assuming the data wasn't more than than the size of the MTU) .

   Also, later I'll make game connection routines using IRC programs, and messaging, so you could find other people on IRC, click on a person's name who's acting as a game Server, and click on an appropriate game button to log into the game.