NOTE: iostream.imbue(std::locale("C")) is very slow\r
NOTE: Global locale is now set at initialization\r
\r
-Random suggeestions:\r
---------------------\r
+Random suggeestions (AKA very old suggestions that haven't been done):\r
+----------------------------------------------------------------------\r
\r
SUGG: Fix address to be ipv6 compatible\r
\r
using for UnlimitedHeightmap? (getting all neighbors\r
when generating)\r
\r
-SUGG: Transfer more blocks in a single packet\r
-SUGG: A blockdata combiner class, to which blocks are added and at\r
- destruction it sends all the stuff in as few packets as possible.\r
-\r
SUGG: If player is on ground, mainly fetch ground-level blocks\r
-SUGG: Fetch stuff mainly from the viewing direction\r
\r
SUGG: Expose Connection's seqnums and ACKs to server and client.\r
- This enables saving many packets and making a faster connection\r
\r
SUGG: A map editing mode (similar to dedicated server mode)\r
\r
-SUGG: Add a time value to the param of footstepped grass and check it\r
- against a global timer when a block is accessed, to make old\r
- steps fade away.\r
-\r
-SUGG: Make a copy of close-range environment on client for showing\r
- on screen, with minimal mutexes to slow down the main loop\r
-\r
+SUGG: Transfer more blocks in a single packet\r
+SUGG: A blockdata combiner class, to which blocks are added and at\r
+ destruction it sends all the stuff in as few packets as possible.\r
SUGG: Make a PACKET_COMBINED which contains many subpackets. Utilize\r
it by sending more stuff in a single packet.\r
- Add a packet queue to RemoteClient, from which packets will be\r
combined with object data packets\r
- This is not exactly trivial: the object data packets are\r
sometimes very big by themselves\r
+ - This might not give much network performance gain though.\r
\r
SUGG: Split MapBlockObject serialization to to-client and to-disk\r
- This will allow saving ages of rats on disk but not sending\r
them to clients\r
+ - Not applicable. MapBlockObjects will be removed in the future.\r
\r
SUGG: MovingObject::move and Player::move are basically the same.\r
combine them.\r
SUGG: A version number to blocks, which increments when the block is\r
modified (node add/remove, water update, lighting update)\r
- This can then be used to make sure the most recent version of\r
- a block has been sent to client\r
+ a block has been sent to client, for example\r
\r
SUGG: Make the amount of blocks sending to client and the total\r
amount of blocks dynamically limited. Transferring blocks is the\r
\r
Game content:\r
-------------\r
+- When furnace is destroyed, move items to player's inventory\r
+- Add lots of stuff, no matter if they have really no real purpose.\r
- Glass blocks\r
-- WHen furnace is destroyed, move items to player's inventory\r
- Growing grass, decaying leaves\r
- This can be done in the active blocks I guess.\r
- Lots of stuff can be done in the active blocks.\r
- Uh, is there an active block list somewhere?\r
+- Player health points\r
+ - When player dies, throw items on map\r
\r
Documentation:\r
--------------\r
GUI:\r
----\r
\r
-TODO: Add gui option to remove map\r
-\r
TODO: Configuration menu, at least for keys\r
\r
Graphics:\r
---------\r
\r
-TODO: Optimize day/night mesh updating somehow\r
- - create copies of all textures for all lighting values and only\r
- change texture for material?\r
- - Umm... the collecting of the faces is the slow part\r
- -> what about just changing the color values of the existing\r
- meshbuffers? It should go quite fast.\r
- - This is not easy; There'd need to be a buffer somewhere\r
- that would contain the night and day lighting values.\r
- - Actually if FastFaces would be stored, they could\r
- hold both values\r
-\r
-FEATURE: Combine MapBlock's face caches to so big pieces that VBO\r
+SUGG: Combine MapBlock's face caches to so big pieces that VBO\r
gets used\r
- That is >500 vertices\r
- This is not easy; all the MapBlocks close to the player would\r
still need to be drawn separately and combining the blocks\r
would have to happen in a background thread\r
\r
-TODO: Make fetching sector's blocks more efficient when rendering\r
+SUGG: Make fetching sector's blocks more efficient when rendering\r
sectors that have very large amounts of blocks (on client)\r
- Is this necessary at all?\r
\r
Client:\r
-------\r
\r
+TODO: Remove IrrlichtWrapper\r
+\r
TODO: Untie client network operations from framerate\r
- Needs some input queues or something\r
+ - This won't give much performance boost because calculating block\r
+ meshes takes so long\r
\r
SUGG: Make morning and evening transition more smooth and maybe shorter\r
\r
-SUGG: Don't update all meshes always on single node changes, but\r
+TODO: Don't update all meshes always on single node changes, but\r
check which ones should be updated\r
- - implement Map::updateNodeMeshes()\r
-\r
-TODO: Remove IrrlichtWrapper\r
-\r
-SUGG: Add a "description" field to InventoryList and show it in\r
- GUIInventoryMenu\r
- - If separate menus are made for everything, this is not needed\r
-\r
-TODO: See what is the main slowdown when a node is added or removed\r
- and make it asynchronous at least for other players\r
- - It probably is updateMeshes. How 'bout making it asynchronous?\r
+ - implement Map::updateNodeMeshes() and the usage of it\r
+ - It will give almost always a 4x boost in mesh update performance.\r
\r
Server:\r
-------\r
SUGG: Make an option to the server to disable building and digging near\r
the starting position\r
\r
-TODO: Copy the text of the last picked sign to inventory in creative\r
- mode\r
-\r
-TODO: Check what goes wrong with caching map to disk (Kray)\r
- - Nothing?\r
-\r
FIXME: Server sometimes goes into some infinite PeerNotFoundException loop\r
\r
* Fix the problem with the server constantly saving one or a few\r
* Make a small history check to transformLiquids to detect and log\r
continuous oscillations, in such detail that they can be fixed.\r
\r
-TODO: Player health points\r
- - When player dies, throw items on map\r
-\r
FIXME: If something is removed from craftresult with a right click,\r
it is only possible to get one item from it should give 4\r
\r
\r
TODO: Flowing water to actually contain flow direction information\r
\r
-FEATURE: Create a system that allows a huge amount of different "map\r
- generator modules/filters"\r
-\r
-FEATURE: Erosion simulation at map generation time\r
- - Simulate water flows, which would carve out dirt fast and\r
- then turn stone into gravel and sand and relocate it.\r
- - How about relocating minerals, too? Coal and gold in\r
- downstream sand and gravel would be kind of cool\r
- - This would need a better way of handling minerals, mainly\r
- to have mineral content as a separate field. the first\r
- parameter field is free for this.\r
- - Simulate rock falling from cliffs when water has removed\r
- enough solid rock from the bottom\r
+SUGG: Erosion simulation at map generation time\r
+ - Simulate water flows, which would carve out dirt fast and\r
+ then turn stone into gravel and sand and relocate it.\r
+ - How about relocating minerals, too? Coal and gold in\r
+ downstream sand and gravel would be kind of cool\r
+ - This would need a better way of handling minerals, mainly\r
+ to have mineral content as a separate field. the first\r
+ parameter field is free for this.\r
+ - Simulate rock falling from cliffs when water has removed\r
+ enough solid rock from the bottom\r
\r
Mapgen v2:\r
* only_from_disk might not work anymore - check and fix it.\r
* Make the generator to run in background and not blocking block\r
placement and transfer\r
* Possibly add some kind of erosion and other stuff\r
-* Make client to fetch stuff asynchronously\r
- - Needs method SyncProcessData\r
* Better water generation (spread it to underwater caverns but don't\r
fill dungeons that don't touch big water masses)\r
* When generating a chunk and the neighboring chunk doesn't have mud\r
Make a system for pregenerating quick information for mapblocks, so\r
that the client can show them as cubes before they are actually sent\r
or even generated.\r
-* Optimize VoxelManipulator lighting implementation by using indices\r
- in place of coordinates?\r
\r
Making it more portable:\r
------------------------\r