Connor's changelog converted to MD

CURRENT REVISION: UNRELEASED
==========

IF CURRENT REVISION is UNRELEASED, it means that the program has yet to be released to the general public, and therefore
does not need a revision number. Changes are made too often before release to maintain a CURRENT REVISION before release--
I'd be changing it every update I made, and that's a lot of updates. Only a select number of people WILL see the CURRENT
REVISION being set on UNRELEASED, so if you are one of those people, consider yourself...priviliged. :)

###TODO List (Goes by importance):
	1. Reconstruct the thread model for the engine
	2. Finish GUI plans
	3. Complete the login pipeline so login works
	4. Decide on the player and NPC model and how 

###Current Error(s)/Glitch(es):
	None!

###Changes:
	v0.1.0B: Event management system completed, including both worker threads and full Event & EventManager implementation
	v0.2.0B: ServerBootstrap implementation added for network port listening
	v0.2.1B: SimpleChannelUpstreamHandler implementation started for incoming channel request handling
	v0.2.2B: SimpleChannelUpstreamHandler#messageReceived() impl started, which means client-handling is the next step in
			development
	v0.2.3B: Full Netty networking impl added (full credits to `Discardedx2 from Rune-Server, see README.txt for details) WITH
			proper basic support for the RuneScape #508 client
			UPDATE: Starting revision changed from #508 to #562 
	v0.2.4B: Commandline logging impl added for advanced and organized event logging
	v0.2.5B: Simple GUI starter created...no features yet (no features planned yet, either)
	v0.2.7B: Eventhandling system redone; significant simplicity change! EventManager is now much smaller. Instead of using
			a really advanced custom class for handling all the events, we used java.util.concurrent.PriorityBlockingQueue
			to handle all the dirty queue work. Testing is now underway. Both worker threads were retained
			UPDATE: Eventhandling system passes concurrency check for one event on each worker
			UPDATE: Eventhandling system passes concurrency check for a large amount of events on each worker
			UPDATE: Test eventhandling log created; includes a log of what happened with two tests. Both tests passed 100%:
				PriorityBlockingQueue instantiated.
				Thread A started.
				Thread B started.
				Event added to queue (normal)
				Thread A looks for events and finds none.
				Thread B looks for events, finds the new event, runs it, removes it from the queue, then lets go of the 
					lock on the queue.
				------------
				Event added to queue (high)
				Event added to queue (high)
				Event added to queue (normal)
				Thread A executes the first high priority event, removes it, then looks again and finds the second and 
				runs it and removes it.
				Thread B executes the only normal event, removes it, and all is back to waiting on the queue.
			UPDATE: The current eventhandling system is expected to handle most game events perfectly well, but game events
			are a definite step up from just printing a message in the console, so we'll see later on in the development
	v0.2.8B: Benchmarking added to events to track how long each event takes to run
	v0.2.9B: Pretend update server added
	v0.3.0B: Login protocol procedure started
	v0.3.1B: Login decoder finished
	v0.3.2B: Entity and sub-class Player classes added: game world started.
	v0.3.3B: Anonymous-level logging removed; method structure in com.rsemulator.log.Logger changed so that all external
			 users have to pass into them to print a message is the raw class type. The getSimpleName() is done inside
			 the Logger. Much cleaner usage of the class, now
	v0.3.5B: Login encoder completed
	v0.3.6B: Simple world server basis completed
	v0.3.7B: Logging system removed; it was causing more problems than it was worth.
	v0.3.8B: Player saving completed