Print_String{} Takes a string and prints it out in the main window, and scrolls the text up if necessary.

Window_Events{} This checks for any input from the user and acts accordingly, it also returns true if the program should exit- ie: if the user clicks on the close gadget while offine.
   It instigates many actions, like connecting to the Server, setting up the program as Server, disconnecting the program from the game (or shuts down the game if it's the Server), sends a string message to other players and closes program down if close gadget pressed. It also deals with other GUI functions like changing the message sending protocol and delays etc.

Result_Reply{} is a cludge to get Arexx working in Blitz.

Get_Rexx_Message{} Checks for Arexx commands received and acts on them - note: that using Arexx commands in Blitz causes an enforcer hit, so this call is commented out in General_Housekeeping{}.

Process_Comms_Information{} Is used by General_Housekeeping{} to print out or deal with information provided by Get_Comms_System_Information{} - note: that this function could easily be localised for different languages.

General_Housekeeping{} This does general housekeeping chores for UDP Chat like check for incoming Arexx commands (note: that using Arexx commands in Blitz causes an enforcer hit, so this call is commented out), constantly updates players' ping times on screen.

   UDP chat has an Object-Orientated structure- by that I mean that it has no loops that it sits in, waiting for something. It has a Main loop that it goes through once per frame, which then waits for WaitTOF_{}, which provides some CPU time for other programs if it's doing lots of work, or puts it into sleep mode until the top of the frame, if it's idling.
   It sets events into motion (usually by GUI events in Window_Events{}), which are then checked once per frame to see if any changes need to be made, wether new event(s) need to be started in response to a condition of an event, or wether an event needs to be shut down. These are done in Comms_Work{}, which calls the UDP Lib function Get_Comms_Data{} to get any Game Data sent to the Server/Client, and the UDP Lib function Comms_Housekeeping{}, which keeps track of UDP Lib events.
   General_Housekeeping{} keeps track of UDP Chat events- it also calls Process_Comms_Information{} which responds to UDP Lib system notifications. Usually, Process_Comms_Information{} just prints out messages to the UDP Chat window, for user information or debugging, but it also handles some events too.

   You can have up to 7 other players online (you can set the total number of players with the `max_number_players' variable). If you're offline you can change the `max_number_players' with the Max_Number_Players{} function.

   You have to change the constant #NO_CONNECTION at the top of the code if you're running your programs locally: 1 if you haven't been online, or 0 if you have been/are online. `Localhost' seems to work differently in each case- (I think it's because `Localhost' is your LAN address rather than your Internet address). If you're testing programs online it needs to be set to 0. Also you have to set the #COMMS_DEBUG constant to 1, which allows you to have multiple copies on one machine (otherwise, if it finds that there is already a UDP_Chat Arexx port it will exit). It's also for outputting all debug data onscreen.

   Once logged into Server, UDP Chat goes through it's own game initialisation routines. The Server starts by synching the Client's time with it's own (really only of use for Peer-To-Peer communication), using the Time_Sync_Start{} function. Note: this is for example only- the developer is free to do what ever they like after the Client is logged in (see Case #CONNECTION_ACCEPTED in Process_Comms_Information{}).

The process starts with online_state=#OFFLINE, when game is Offline.

For Server:
In Case53 (Server button) in Window_Events{}, if Initialise_Server{} returns True, then online_state=#ONLINE.

In Case #WE_ARE_DISCONNECTED_FROM_THE_GAME in Process_Comms_Information{}, then online_state becomes #OFFLINE.

For Client:
In Case51 (return is hit in the "Send To:" gadget) in Window_Events{}, online_state becomes #CONNECTION_ATTEMPT.

Then with Case #CONNECTION_ACCEPTED notification in Process_Comms_Information{}, online_state is changed to #SYNCHING_TIME, as the Server starts the synching with the Client.

When Case #SYSTEM_TIME_IS is received (ie: the time synching has been completed) in Process_Comms_Information{}, then online_state becomes #ONLINE.

In Case #WE_ARE_DISCONNECTED_FROM_THE_GAME in Process_Comms_Information{}, then online_state becomes #OFFLINE.