NOTE: If VBO (EHM_STATIC) is used, remember to explicitly free the\r
hardware buffer (it is not freed automatically)\r
\r
-Random suggeestions (AKA very old suggestions that haven't been done):\r
-----------------------------------------------------------------------\r
-\r
-SUGG: Fix address to be ipv6 compatible\r
+Old, wild and random suggestions that probably won't be done:\r
+-------------------------------------------------------------\r
\r
SUGG: If player is on ground, mainly fetch ground-level blocks\r
\r
\r
SUGG: Simple light color information to air\r
\r
+SUGG: Server-side objects could be moved based on nodes to enable very\r
+ lightweight operation and simple AI\r
+ - Not practical; client would still need to show smooth movement.\r
+\r
+SUGG: 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
+\r
Gaming ideas:\r
-------------\r
\r
Networking and serialization:\r
-----------------------------\r
\r
+SUGG: Fix address to be ipv6 compatible\r
+\r
User Interface:\r
---------------\r
\r
FIXME: The new optimized map sending doesn't sometimes send enough blocks\r
from big caves and such\r
\r
+Environment:\r
+------------\r
+\r
+TODO: A list of "active blocks" in which stuff happens.\r
+ + Add a never-resetted game timer to the server\r
+ + Add a timestamp value to blocks\r
+ + The simple rule: All blocks near some player are "active"\r
+ - Do stuff in real time in active blocks\r
+ + Handle objects\r
+ TODO: Make proper hooks in here\r
+ - Grow grass, delete leaves without a tree\r
+ - Spawn some mobs based on some rules\r
+ - Transform cobble to mossy cobble near water\r
+ - Run a custom script\r
+ - ...And all kinds of other dynamic stuff\r
+ + Keep track of when a block becomes active and becomes inactive\r
+ + When a block goes inactive:\r
+ + Store objects statically to block\r
+ + Store timer value as the timestamp\r
+ + When a block goes active:\r
+ + Create active objects out of static objects\r
+ TODO: Make proper hooks in here\r
+ - Simulate the results of what would have happened if it would have\r
+ been active for all the time\r
+ - Grow a lot of grass and so on\r
+ + Initially it is fine to send information about every active object\r
+ to every player. Eventually it should be modified to only send info\r
+ about the nearest ones.\r
+ + This was left to be done by the old system and it sends only the\r
+ nearest ones.\r
+\r
Objects:\r
--------\r
\r
-TODO: Get rid of MapBlockObjects and use ActiveObjects\r
+TODO: Get rid of MapBlockObjects and use only ActiveObjects\r
+ - Skipping the MapBlockObject data is nasty - there is no "total\r
+ length" stored; have to make a SkipMBOs function which contains\r
+ enough of the current code to skip them properly.\r
\r
SUGG: MovingObject::move and Player::move are basically the same.\r
combine them.\r
- - NOTE: Player::move is more up-to-date.\r
- - NOTE: There is a simple move implementation now in collision.{h,cpp}\r
-\r
-SUGG: Server-side objects could be moved based on nodes to enable very\r
- lightweight operation and simple AI\r
+ - NOTE: Player::move is more up-to-date.\r
+ - NOTE: There is a simple move implementation now in collision.{h,cpp}\r
+ - NOTE: MovingObject will be deleted (MapBlockObject)\r
\r
Map:\r
----\r
\r
Misc. stuff:\r
------------\r
-* Make an "environment metafile" to store at least time of day\r
-* Move digging property stuff from material.{h,cpp} to mapnode.cpp...\r
- - Or maybe move content_features to material.{h,cpp}?\r
-* Maybe:\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
+* Move digging property stuff from material.{h,cpp} to mapnode.cpp\r
+ - ...Or maybe move content_features to material.{h,cpp}?\r
\r
Making it more portable:\r
------------------------\r
-* Some MSVC: std::sto* are defined without a namespace and collide\r
- with the ones in utility.h\r
+ \r
+Stuff to do before release:\r
+---------------------------\r
+- Player default privileges and default password\r
+- Chat privilege\r
+- Some simple block-based dynamic stuff in the world (finish the\r
+ ActiveBlockModifier stuff)\r
+- Protocol version field\r
+- Consider getting some textures from cisoun's texture pack\r
+- Add a long step function to objects that is called with the time\r
+ difference when block activates\r
\r
======================================================================\r
\r
#include "materials.h"\r
#include "game.h"\r
#include "keycode.h"\r
-#include "sha1.h"\r
-#include "base64.h"\r
\r
// This makes textures\r
ITextureSource *g_texturesource = NULL;\r
\r
playername = wide_to_narrow(menudata.name);\r
\r
- // Get an sha-1 hash of the player's name combined with\r
- // the password entered. That's what the server uses as\r
- // their password. (Exception : if the password field is\r
- // blank, we send a blank password - this is for backwards\r
- // compatibility with password-less players).\r
- if(menudata.password.length() > 0)\r
- {\r
- std::string slt=playername + wide_to_narrow(menudata.password);\r
- SHA1 *sha1 = new SHA1();\r
- sha1->addBytes(slt.c_str(), slt.length());\r
- unsigned char *digest = sha1->getDigest();\r
- password = base64_encode(digest, 20);\r
- free(digest);\r
- }\r
- else\r
- {\r
- password = "";\r
- }\r
+ password = translatePassword(playername, menudata.password);\r
\r
address = wide_to_narrow(menudata.address);\r
int newport = stoi(wide_to_narrow(menudata.port));\r
projects / dragonfireclient.git / blobdiff