Move huge comment from the beginning of main.cpp to doc/ancient_main_comment.txt

2 files changed, 345 insertions, 342 deletions

diff --git a/doc/ancient_main_comment.txt b/doc/ancient_main_comment.txt
new file mode 100644
index 000000000..d7b0e307f
--- /dev/null
+++ b/doc/ancient_main_comment.txt
@@ -0,0 +1,345 @@
+------------------------------------------------------------------
+The ancient comment from the beginning of main.cpp is stored here.
+------------------------------------------------------------------
+
+/*
+=============================== NOTES ==============================
+NOTE: Things starting with TODO are sometimes only suggestions.
+
+NOTE: iostream.imbue(std::locale("C")) is very slow
+NOTE: Global locale is now set at initialization
+
+NOTE: If VBO (EHM_STATIC) is used, remember to explicitly free the
+      hardware buffer (it is not freed automatically)
+
+NOTE: A random to-do list saved here as documentation:
+A list of "active blocks" in which stuff happens. (+=done)
+	+ Add a never-resetted game timer to the server
+	+ Add a timestamp value to blocks
+	+ The simple rule: All blocks near some player are "active"
+	- Do stuff in real time in active blocks
+		+ Handle objects
+		- Grow grass, delete leaves without a tree
+		- Spawn some mobs based on some rules
+		- Transform cobble to mossy cobble near water
+		- Run a custom script
+		- ...And all kinds of other dynamic stuff
+	+ Keep track of when a block becomes active and becomes inactive
+	+ When a block goes inactive:
+		+ Store objects statically to block
+		+ Store timer value as the timestamp
+	+ When a block goes active:
+		+ Create active objects out of static objects
+		- Simulate the results of what would have happened if it would have
+		  been active for all the time
+		  	- Grow a lot of grass and so on
+	+ Initially it is fine to send information about every active object
+	  to every player. Eventually it should be modified to only send info
+	  about the nearest ones.
+	  	+ This was left to be done by the old system and it sends only the
+		  nearest ones.
+
+NOTE: Seeds in 1260:6c77e7dbfd29:
+5721858502589302589:
+	Spawns you on a small sand island with a surface dungeon
+2983455799928051958:
+	Enormous jungle + a surface dungeon at ~(250,0,0)
+
+Old, wild and random suggestions that probably won't be done:
+-------------------------------------------------------------
+
+SUGG: If player is on ground, mainly fetch ground-level blocks
+
+SUGG: Expose Connection's seqnums and ACKs to server and client.
+      - This enables saving many packets and making a faster connection
+	  - This also enables server to check if client has received the
+	    most recent block sent, for example.
+SUGG: Add a sane bandwidth throttling system to Connection
+
+SUGG: More fine-grained control of client's dumping of blocks from
+      memory
+	  - ...What does this mean in the first place?
+
+SUGG: A map editing mode (similar to dedicated server mode)
+
+SUGG: Transfer more blocks in a single packet
+SUGG: A blockdata combiner class, to which blocks are added and at
+      destruction it sends all the stuff in as few packets as possible.
+SUGG: Make a PACKET_COMBINED which contains many subpackets. Utilize
+      it by sending more stuff in a single packet.
+	  - Add a packet queue to RemoteClient, from which packets will be
+	    combined with object data packets
+		- This is not exactly trivial: the object data packets are
+		  sometimes very big by themselves
+	  - This might not give much network performance gain though.
+
+SUGG: Precalculate lighting translation table at runtime (at startup)
+      - This is not doable because it is currently hand-made and not
+	    based on some mathematical function.
+		- Note: This has been changing lately
+
+SUGG: A version number to blocks, which increments when the block is
+      modified (node add/remove, water update, lighting update)
+	  - This can then be used to make sure the most recent version of
+	    a block has been sent to client, for example
+
+SUGG: Make the amount of blocks sending to client and the total
+	  amount of blocks dynamically limited. Transferring blocks is the
+	  main network eater of this system, so it is the one that has
+	  to be throttled so that RTTs stay low.
+
+SUGG: Meshes of blocks could be split into 6 meshes facing into
+      different directions and then only those drawn that need to be
+
+SUGG: Background music based on cellular automata?
+      http://www.earslap.com/projectslab/otomata
+
+SUGG: Simple light color information to air
+
+SUGG: Server-side objects could be moved based on nodes to enable very
+      lightweight operation and simple AI
+	- Not practical; client would still need to show smooth movement.
+
+SUGG: Make a system for pregenerating quick information for mapblocks, so
+	  that the client can show them as cubes before they are actually sent
+	  or even generated.
+
+SUGG: Erosion simulation at map generation time
+    - This might be plausible if larger areas of map were pregenerated
+	  without lighting (which is slow)
+	- Simulate water flows, which would carve out dirt fast and
+	  then turn stone into gravel and sand and relocate it.
+	- How about relocating minerals, too? Coal and gold in
+	  downstream sand and gravel would be kind of cool
+	  - This would need a better way of handling minerals, mainly
+		to have mineral content as a separate field. the first
+		parameter field is free for this.
+	- Simulate rock falling from cliffs when water has removed
+	  enough solid rock from the bottom
+
+SUGG: For non-mapgen FarMesh: Add a per-sector database to store surface
+      stuff as simple flags/values
+      - Light?
+	  - A building?
+	  And at some point make the server send this data to the client too,
+	  instead of referring to the noise functions
+	  - Ground height
+	  - Surface ground type
+	  - Trees?
+
+Gaming ideas:
+-------------
+
+- Aim for something like controlling a single dwarf in Dwarf Fortress
+- The player could go faster by a crafting a boat, or riding an animal
+- Random NPC traders. what else?
+
+Game content:
+-------------
+
+- When furnace is destroyed, move items to player's inventory
+- Add lots of stuff
+- Glass blocks
+- Growing grass, decaying leaves
+	- This can be done in the active blocks I guess.
+	- Lots of stuff can be done in the active blocks.
+	- Uh, is there an active block list somewhere? I think not. Add it.
+- Breaking weak structures
+	- This can probably be accomplished in the same way as grass
+- Player health points
+	- When player dies, throw items on map (needs better item-on-map
+	  implementation)
+- Cobble to get mossy if near water
+- More slots in furnace source list, so that multiple ingredients
+  are possible.
+- Keys to chests?
+
+- The Treasure Guard; a big monster with a hammer
+	- The hammer does great damage, shakes the ground and removes a block
+	- You can drop on top of it, and have some time to attack there
+	  before he shakes you off
+
+- Maybe the difficulty could come from monsters getting tougher in
+  far-away places, and the player starting to need something from
+  there when time goes by.
+  - The player would have some of that stuff at the beginning, and
+    would need new supplies of it when it runs out
+
+- A bomb
+- A spread-items-on-map routine for the bomb, and for dying players
+
+- Fighting:
+  - Proper sword swing simulation
+  - Player should get damage from colliding to a wall at high speed
+
+Documentation:
+--------------
+
+Build system / running:
+-----------------------
+
+Networking and serialization:
+-----------------------------
+
+SUGG: Fix address to be ipv6 compatible
+
+User Interface:
+---------------
+
+Graphics:
+---------
+
+SUGG: Combine MapBlock's face caches to so big pieces that VBO
+      can be used
+      - That is >500 vertices
+	  - This is not easy; all the MapBlocks close to the player would
+	    still need to be drawn separately and combining the blocks
+		would have to happen in a background thread
+
+SUGG: Make fetching sector's blocks more efficient when rendering
+      sectors that have very large amounts of blocks (on client)
+	  - Is this necessary at all?
+
+SUGG: Draw cubes in inventory directly with 3D drawing commands, so that
+      animating them is easier.
+
+SUGG: Option for enabling proper alpha channel for textures
+
+TODO: Flowing water animation
+
+TODO: A setting for enabling bilinear filtering for textures
+
+TODO: Better control of draw_control.wanted_max_blocks
+
+TODO: Further investigate the use of GPU lighting in addition to the
+      current one
+
+TODO: Artificial (night) light could be more yellow colored than sunlight.
+      - This is technically doable.
+	  - Also the actual colors of the textures could be made less colorful
+	    in the dark but it's a bit more difficult.
+
+SUGG: Somehow make the night less colorful
+
+TODO: Occlusion culling
+      - At the same time, move some of the renderMap() block choosing code
+        to the same place as where the new culling happens.
+      - Shoot some rays per frame and when ready, make a new list of
+	    blocks for usage of renderMap and give it a new pointer to it.
+
+Configuration:
+--------------
+
+Client:
+-------
+
+TODO: Untie client network operations from framerate
+      - Needs some input queues or something
+	  - This won't give much performance boost because calculating block
+	    meshes takes so long
+
+SUGG: Make morning and evening transition more smooth and maybe shorter
+
+TODO: Don't update all meshes always on single node changes, but
+      check which ones should be updated
+	  - implement Map::updateNodeMeshes() and the usage of it
+	  - It will give almost always a 4x boost in mesh update performance.
+
+- A weapon engine
+
+- Tool/weapon visualization
+
+FIXME: When disconnected to the menu, memory is not freed properly
+
+TODO: Investigate how much the mesh generator thread gets used when
+      transferring map data
+
+Server:
+-------
+
+SUGG: Make an option to the server to disable building and digging near
+      the starting position
+
+FIXME: Server sometimes goes into some infinite PeerNotFoundException loop
+
+* Fix the problem with the server constantly saving one or a few
+  blocks? List the first saved block, maybe it explains.
+  - It is probably caused by oscillating water
+  - TODO: Investigate if this still happens (this is a very old one)
+* Make a small history check to transformLiquids to detect and log
+  continuous oscillations, in such detail that they can be fixed.
+
+FIXME: The new optimized map sending doesn't sometimes send enough blocks
+       from big caves and such
+FIXME: Block send distance configuration does not take effect for some reason
+
+Environment:
+------------
+
+TODO: Add proper hooks to when adding and removing active blocks
+
+TODO: Finish the ActiveBlockModifier stuff and use it for something
+
+Objects:
+--------
+
+TODO: Get rid of MapBlockObjects and use only ActiveObjects
+	- Skipping the MapBlockObject data is nasty - there is no "total
+	  length" stored; have to make a SkipMBOs function which contains
+	  enough of the current code to skip them properly.
+
+SUGG: MovingObject::move and Player::move are basically the same.
+      combine them.
+	- NOTE: This is a bit tricky because player has the sneaking ability
+	- NOTE: Player::move is more up-to-date.
+	- NOTE: There is a simple move implementation now in collision.{h,cpp}
+	- NOTE: MovingObject will be deleted (MapBlockObject)
+
+TODO: Add a long step function to objects that is called with the time
+      difference when block activates
+
+Map:
+----
+
+TODO: Flowing water to actually contain flow direction information
+      - There is a space for this - it just has to be implemented.
+
+TODO: Consider smoothening cave floors after generating them
+
+TODO: Fix make_tree, make_* to use seed-position-consistent pseudorandom
+	  - delta also
+
+Misc. stuff:
+------------
+TODO: Make sure server handles removing grass when a block is placed (etc)
+      - The client should not do it by itself
+	  - NOTE: I think nobody does it currently...
+TODO: Block cube placement around player's head
+TODO: Protocol version field
+TODO: Think about using same bits for material for fences and doors, for
+	  example
+
+SUGG: Restart irrlicht completely when coming back to main menu from game.
+	- This gets rid of everything that is stored in irrlicht's caches.
+	- This might be needed for texture pack selection in menu
+
+TODO: Merge bahamada's audio stuff (clean patch available)
+
+Making it more portable:
+------------------------
+ 
+Stuff to do before release:
+---------------------------
+
+Fixes to the current release:
+-----------------------------
+
+Stuff to do after release:
+---------------------------
+
+Doing currently:
+----------------
+
+======================================================================
+
+*/
diff --git a/src/main.cpp b/src/main.cpp
index 81905109d..0c936ab63 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -17,348 +17,6 @@ with this program; if not, write to the Free Software Foundation, Inc.,
 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 */
 
-/*
-=============================== NOTES ==============================
-NOTE: Things starting with TODO are sometimes only suggestions.
-
-NOTE: iostream.imbue(std::locale("C")) is very slow
-NOTE: Global locale is now set at initialization
-
-NOTE: If VBO (EHM_STATIC) is used, remember to explicitly free the
-      hardware buffer (it is not freed automatically)
-
-NOTE: A random to-do list saved here as documentation:
-A list of "active blocks" in which stuff happens. (+=done)
-	+ Add a never-resetted game timer to the server
-	+ Add a timestamp value to blocks
-	+ The simple rule: All blocks near some player are "active"
-	- Do stuff in real time in active blocks
-		+ Handle objects
-		- Grow grass, delete leaves without a tree
-		- Spawn some mobs based on some rules
-		- Transform cobble to mossy cobble near water
-		- Run a custom script
-		- ...And all kinds of other dynamic stuff
-	+ Keep track of when a block becomes active and becomes inactive
-	+ When a block goes inactive:
-		+ Store objects statically to block
-		+ Store timer value as the timestamp
-	+ When a block goes active:
-		+ Create active objects out of static objects
-		- Simulate the results of what would have happened if it would have
-		  been active for all the time
-		  	- Grow a lot of grass and so on
-	+ Initially it is fine to send information about every active object
-	  to every player. Eventually it should be modified to only send info
-	  about the nearest ones.
-	  	+ This was left to be done by the old system and it sends only the
-		  nearest ones.
-
-NOTE: Seeds in 1260:6c77e7dbfd29:
-5721858502589302589:
-	Spawns you on a small sand island with a surface dungeon
-2983455799928051958:
-	Enormous jungle + a surface dungeon at ~(250,0,0)
-
-Old, wild and random suggestions that probably won't be done:
--------------------------------------------------------------
-
-SUGG: If player is on ground, mainly fetch ground-level blocks
-
-SUGG: Expose Connection's seqnums and ACKs to server and client.
-      - This enables saving many packets and making a faster connection
-	  - This also enables server to check if client has received the
-	    most recent block sent, for example.
-SUGG: Add a sane bandwidth throttling system to Connection
-
-SUGG: More fine-grained control of client's dumping of blocks from
-      memory
-	  - ...What does this mean in the first place?
-
-SUGG: A map editing mode (similar to dedicated server mode)
-
-SUGG: Transfer more blocks in a single packet
-SUGG: A blockdata combiner class, to which blocks are added and at
-      destruction it sends all the stuff in as few packets as possible.
-SUGG: Make a PACKET_COMBINED which contains many subpackets. Utilize
-      it by sending more stuff in a single packet.
-	  - Add a packet queue to RemoteClient, from which packets will be
-	    combined with object data packets
-		- This is not exactly trivial: the object data packets are
-		  sometimes very big by themselves
-	  - This might not give much network performance gain though.
-
-SUGG: Precalculate lighting translation table at runtime (at startup)
-      - This is not doable because it is currently hand-made and not
-	    based on some mathematical function.
-		- Note: This has been changing lately
-
-SUGG: A version number to blocks, which increments when the block is
-      modified (node add/remove, water update, lighting update)
-	  - This can then be used to make sure the most recent version of
-	    a block has been sent to client, for example
-
-SUGG: Make the amount of blocks sending to client and the total
-	  amount of blocks dynamically limited. Transferring blocks is the
-	  main network eater of this system, so it is the one that has
-	  to be throttled so that RTTs stay low.
-
-SUGG: Meshes of blocks could be split into 6 meshes facing into
-      different directions and then only those drawn that need to be
-
-SUGG: Background music based on cellular automata?
-      http://www.earslap.com/projectslab/otomata
-
-SUGG: Simple light color information to air
-
-SUGG: Server-side objects could be moved based on nodes to enable very
-      lightweight operation and simple AI
-	- Not practical; client would still need to show smooth movement.
-
-SUGG: Make a system for pregenerating quick information for mapblocks, so
-	  that the client can show them as cubes before they are actually sent
-	  or even generated.
-
-SUGG: Erosion simulation at map generation time
-    - This might be plausible if larger areas of map were pregenerated
-	  without lighting (which is slow)
-	- Simulate water flows, which would carve out dirt fast and
-	  then turn stone into gravel and sand and relocate it.
-	- How about relocating minerals, too? Coal and gold in
-	  downstream sand and gravel would be kind of cool
-	  - This would need a better way of handling minerals, mainly
-		to have mineral content as a separate field. the first
-		parameter field is free for this.
-	- Simulate rock falling from cliffs when water has removed
-	  enough solid rock from the bottom
-
-SUGG: For non-mapgen FarMesh: Add a per-sector database to store surface
-      stuff as simple flags/values
-      - Light?
-	  - A building?
-	  And at some point make the server send this data to the client too,
-	  instead of referring to the noise functions
-	  - Ground height
-	  - Surface ground type
-	  - Trees?
-
-Gaming ideas:
--------------
-
-- Aim for something like controlling a single dwarf in Dwarf Fortress
-- The player could go faster by a crafting a boat, or riding an animal
-- Random NPC traders. what else?
-
-Game content:
--------------
-
-- When furnace is destroyed, move items to player's inventory
-- Add lots of stuff
-- Glass blocks
-- Growing grass, decaying leaves
-	- This can be done in the active blocks I guess.
-	- Lots of stuff can be done in the active blocks.
-	- Uh, is there an active block list somewhere? I think not. Add it.
-- Breaking weak structures
-	- This can probably be accomplished in the same way as grass
-- Player health points
-	- When player dies, throw items on map (needs better item-on-map
-	  implementation)
-- Cobble to get mossy if near water
-- More slots in furnace source list, so that multiple ingredients
-  are possible.
-- Keys to chests?
-
-- The Treasure Guard; a big monster with a hammer
-	- The hammer does great damage, shakes the ground and removes a block
-	- You can drop on top of it, and have some time to attack there
-	  before he shakes you off
-
-- Maybe the difficulty could come from monsters getting tougher in
-  far-away places, and the player starting to need something from
-  there when time goes by.
-  - The player would have some of that stuff at the beginning, and
-    would need new supplies of it when it runs out
-
-- A bomb
-- A spread-items-on-map routine for the bomb, and for dying players
-
-- Fighting:
-  - Proper sword swing simulation
-  - Player should get damage from colliding to a wall at high speed
-
-Documentation:
---------------
-
-Build system / running:
------------------------
-
-Networking and serialization:
------------------------------
-
-SUGG: Fix address to be ipv6 compatible
-
-User Interface:
----------------
-
-Graphics:
----------
-
-SUGG: Combine MapBlock's face caches to so big pieces that VBO
-      can be used
-      - That is >500 vertices
-	  - This is not easy; all the MapBlocks close to the player would
-	    still need to be drawn separately and combining the blocks
-		would have to happen in a background thread
-
-SUGG: Make fetching sector's blocks more efficient when rendering
-      sectors that have very large amounts of blocks (on client)
-	  - Is this necessary at all?
-
-SUGG: Draw cubes in inventory directly with 3D drawing commands, so that
-      animating them is easier.
-
-SUGG: Option for enabling proper alpha channel for textures
-
-TODO: Flowing water animation
-
-TODO: A setting for enabling bilinear filtering for textures
-
-TODO: Better control of draw_control.wanted_max_blocks
-
-TODO: Further investigate the use of GPU lighting in addition to the
-      current one
-
-TODO: Artificial (night) light could be more yellow colored than sunlight.
-      - This is technically doable.
-	  - Also the actual colors of the textures could be made less colorful
-	    in the dark but it's a bit more difficult.
-
-SUGG: Somehow make the night less colorful
-
-TODO: Occlusion culling
-      - At the same time, move some of the renderMap() block choosing code
-        to the same place as where the new culling happens.
-      - Shoot some rays per frame and when ready, make a new list of
-	    blocks for usage of renderMap and give it a new pointer to it.
-
-Configuration:
---------------
-
-Client:
--------
-
-TODO: Untie client network operations from framerate
-      - Needs some input queues or something
-	  - This won't give much performance boost because calculating block
-	    meshes takes so long
-
-SUGG: Make morning and evening transition more smooth and maybe shorter
-
-TODO: Don't update all meshes always on single node changes, but
-      check which ones should be updated
-	  - implement Map::updateNodeMeshes() and the usage of it
-	  - It will give almost always a 4x boost in mesh update performance.
-
-- A weapon engine
-
-- Tool/weapon visualization
-
-FIXME: When disconnected to the menu, memory is not freed properly
-
-TODO: Investigate how much the mesh generator thread gets used when
-      transferring map data
-
-Server:
--------
-
-SUGG: Make an option to the server to disable building and digging near
-      the starting position
-
-FIXME: Server sometimes goes into some infinite PeerNotFoundException loop
-
-* Fix the problem with the server constantly saving one or a few
-  blocks? List the first saved block, maybe it explains.
-  - It is probably caused by oscillating water
-  - TODO: Investigate if this still happens (this is a very old one)
-* Make a small history check to transformLiquids to detect and log
-  continuous oscillations, in such detail that they can be fixed.
-
-FIXME: The new optimized map sending doesn't sometimes send enough blocks
-       from big caves and such
-FIXME: Block send distance configuration does not take effect for some reason
-
-Environment:
-------------
-
-TODO: Add proper hooks to when adding and removing active blocks
-
-TODO: Finish the ActiveBlockModifier stuff and use it for something
-
-Objects:
---------
-
-TODO: Get rid of MapBlockObjects and use only ActiveObjects
-	- Skipping the MapBlockObject data is nasty - there is no "total
-	  length" stored; have to make a SkipMBOs function which contains
-	  enough of the current code to skip them properly.
-
-SUGG: MovingObject::move and Player::move are basically the same.
-      combine them.
-	- NOTE: This is a bit tricky because player has the sneaking ability
-	- NOTE: Player::move is more up-to-date.
-	- NOTE: There is a simple move implementation now in collision.{h,cpp}
-	- NOTE: MovingObject will be deleted (MapBlockObject)
-
-TODO: Add a long step function to objects that is called with the time
-      difference when block activates
-
-Map:
-----
-
-TODO: Flowing water to actually contain flow direction information
-      - There is a space for this - it just has to be implemented.
-
-TODO: Consider smoothening cave floors after generating them
-
-TODO: Fix make_tree, make_* to use seed-position-consistent pseudorandom
-	  - delta also
-
-Misc. stuff:
-------------
-TODO: Make sure server handles removing grass when a block is placed (etc)
-      - The client should not do it by itself
-	  - NOTE: I think nobody does it currently...
-TODO: Block cube placement around player's head
-TODO: Protocol version field
-TODO: Think about using same bits for material for fences and doors, for
-	  example
-
-SUGG: Restart irrlicht completely when coming back to main menu from game.
-	- This gets rid of everything that is stored in irrlicht's caches.
-	- This might be needed for texture pack selection in menu
-
-TODO: Merge bahamada's audio stuff (clean patch available)
-
-Making it more portable:
-------------------------
- 
-Stuff to do before release:
----------------------------
-
-Fixes to the current release:
------------------------------
-
-Stuff to do after release:
----------------------------
-
-Doing currently:
-----------------
-
-======================================================================
-
-*/
-
 #ifdef NDEBUG
 	/*#ifdef _WIN32
 		#pragma message ("Disabling unit tests")