mirror of
				https://github.com/luanti-org/luanti.git
				synced 2025-11-04 09:15:29 +01:00 
			
		
		
		
	
		
			
				
	
	
		
			346 lines
		
	
	
		
			12 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			346 lines
		
	
	
		
			12 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
------------------------------------------------------------------
 | 
						|
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:
 | 
						|
----------------
 | 
						|
 | 
						|
======================================================================
 | 
						|
 | 
						|
*/
 |