list of ideas and problems for mmapper3:

1. The GUI code is hard to maintain and extend. The main reason for this is that we are still using raw opengl for everything. What I would like to have is a library which would allow me to handle objects and their properties in 3d space without caring about the low level drawing stuff. We should either build such a library ourselves using the existing GUI code or we should find an existing implementation of that.

2. The path machine doesn't perform well in certain areas. I have plenty of ideas on how to improve that situation, but all of them require a rather high level of interaction between the path machine and other components. Among the ideas are:

a, use dynamic descriptions as additional hints. A tree won't change it's position and if we have two identical rooms one with a tree in it and one without, we can easily distinguish it. Of course there's a high error ratio in this approach because there are plenty of mobs which do move around. Info about dynamic descriptions should thus decay quickly and count little.

b, let the user give manual hints. The paths and their associated probabilities should be displayed in the map and deletion of paths should only occure when processing the next event or on user input. The user can then press some keyboard shortcut to hint the mapper to a certain path. 

c, Additionally we could remember how much influence which mapping parameter had on the probability of each path. If a user hints the mapper to one path, then the parameters which would have increased this paths probability are increased and the ones which did increase the probability of other paths which were better than the hinted one are decreased. Like that the mapper could dynamically adapt to certain terrain features like randomness and repetitivity.

d, more detailed penalty values for "long jumps". Each distance should get their own value by which the probability decreases or increases when the path takes a jump. Also there should be different values for jumps only in 2d space and jumps over z-Coordinates. Possibly we even want to take very detailed measures by single coordinates. For example, when looking at the map, jumps over two coordinates in the same direction, like e-e, seem to be quite frequent, while jumps over two coordinates in different directions are somewhat less frequent. This, in conjunction with c, could significantly improve the quality of the autogenerated map in certain places.

e, undo/redo for paths. When the user finds out that the path has gone a wrong way, they should be able to undo the mapping, rolling back the path to the place where things went wrong, then hinting the mapper to the right way and roll forward the path again. Like that "continuous" errors like those that frequently happen in random places, where the mapper does one wrong step and then maps a whole new area into deep space, could be avoided. Also "emergencies", where the player has to quickly run away due to in-game reasons are less fatal.

3. Searching in the room database. The feature I currently miss most is a keyword search in room descriptions. It happens quite often that you are wondering "where did I see that herb" or "Where is the room with title x" something similar. At the moment you have to click around to eventually find it, but a simple word to room index could help you there. A thing like that is rather easy to implement and I already sketched it out. But thinking further about that, the time required to build the index on every start and other requirements leads to a new idea about storage:

4. We might want to store all the data in a relational database instead of a file. Like that data about paths, hints, indexes, mapping parameters and similar stuff can be easily kept and extended without fiddling around with the file format. We just have to make sure we get the principal design right and keep it extendable. If the database is too slow to use it directly, we could build a cache layer around it.

5. Scripting. As we have already seen, there is a need for client scripting to access the room database. As long as the mapper is communicating with the client over a telnet connection and unfortunately the same one the player uses for the game, this is hard to do. We would need to sneak some sort of RPC into the protocol without ever blocking the connection, but but that would be dirty and unreliable. The best way of dealing with this problem is a tighter coupling of client and mapper. Perhaps we could build a client right into the mapper and make some popular scripting language available for it. 

6. Thinking further about Scripting an even better idea has come to my mind. All of the functions the mapper offers should be scriptable from the client side, adding and removing rooms, sending parse events, altering mapping parameters, even defining new user commands and modifying the parser. This could give us a very generic "base" mapper and powerful user- and mud-specific extensions.

7. Visual filtering of mud output. I'd like to have different widgets for communication (perhaps even separated by character, with nice icons for each) and room descriptions. Others might have different preferences, so this should be configurable. Also it might be cool to have the mapper remember where certain mobs or players have been seen the last time. This information could be displayed on the map and slowly fade out with time (as we don't assume people stay in the same place forever).

8. Sub-Areas. Having all of the map in one giant coordinate system is impractical. There are many places where multiple rooms form a sub-area which is embedded into a single room in the big picture but forms its own map in the detailed view. Towns and caves are the most prominent examples. We should respect that and visualize sub-areas appropriately.