moved branches/jahara to trunk

git-svn-id: svn://svn.code.sf.net/p/mmapper/code/trunk/mmapper@141 14c008a5-6e10-0410-bf79-c100e0f1932b

AUTHORS

@@ -1,10 +1,11 @@
 ************************************************************************
 **
 ** Authors:   Ulf Hermann <ulfonk_mennhar@gmx.de> (Alve), 
-**            Marek Krejza <krejza@gmail.com> (Caligor)
+**            Marek Krejza <krejza@gmail.com> (Caligor),
+**            Nils Schimmelmann <nschimme@gmail.com> (Jahara)
 **
 ** This file is part of the MMapper2 project. 
-** Maintained by Marek Krejza <krejza@gmail.com>
+** Maintained by Nils Schimmelmann <nschimme@gmail.com>
 **
 ** Copyright: See COPYING file that comes with this distribution
 **

ChangeLog

@@ -0,0 +1,184 @@
+2008-10-20 16:37  jahara
+	* src/preferences/generalpage.cpp: fixed draw door names checked bug
+	* src/mainwindow/mainwindow.cpp: fixed resize/reposition bug
+
+2008-08-23 23:30  jahara
+
+	* src/configuration/configuration.cpp, .h: added beta draw door names
+	functionality similar to Pandora (feature request by Timodeus)
+	* src/display/mapcanvas.cpp, .h: ""
+	* src/preferences/generalpage.*: ""
+	* src/groupmanagerpage.ui: renamed setting
+	* src/proxy/proxy.cpp: fixed typo
+
+2008-08-20 13:00  jahara
+
+	* src/mainwindow/findroomsdlg.h: fixed minor header file typo
+
+2008-08-20 12:49  jahara
+
+	* src/parser/abstractparser.cpp: fixed _doorhelp internal alias
+	* src/pandoragroup/CGroup.cpp: changed default room to 0
+	* src/pandoragroup/CGroupCommunicator.cpp: removed printfs
+	* src/mainwindow/findroomsdlg.cpp, .h: added latin1 removal, still
+	needs rewrite
+
+2008-07-24 19:07  jahara
+
+	* src/configuration/configuration.cpp: fixed typos
+	* src/pandoragroup/CGroupClient.cpp: added a socket timeout to the
+	client
+
+2008-07-24 12:01  jahara
+
+	* src/configuration/configuration.cpp: registry cleanup
+	* src/mainwindow/mainwindow.cpp: saving alwaysOnTop setting
+	* NOTE: Build using Qt4.3 to prevent lag on Windows. Qt4.4 is bugged.
+
+2008-07-24 04:10  kalev
+
+	* src/mmapper2.pro: fixed sed
+	* src/expandora/coordinate.cpp: added stdlib.h for gcc 4.3
+
+2008-07-24 02:42  jahara
+
+	* src/display/mapcanvas.cpp: removed unnecessary gltranslate from
+	alphapixmaps trails
+	* src/abstractparser.cpp, mumexmlparser.cpp: fixed console commands
+	and ansi colored scores parsing
+	* src/preferences/groupmanager.*: fixed various input problems that
+	would invariable affect the stability of the groupmanager server
+
+2008-07-23 19:10  jahara
+
+	* src/pandoragroup/CGroup.cpp: prompt fix for grouptell
+	* src/parser/abstractparser.cpp: console command fix for _grouphelp
+
+2008-07-23 18:32  jahara
+
+	* src/mainwindow/findroomsdlg.cpp: fixed label not being cleared bug
+	* src/mainwindow/mainwindow.cpp: updated about() dialog box
+	* src/groupmanagerpage.cpp, ui: added more text from MUME rules
+
+2008-07-23 17:08  jahara
+
+	* src/mainwindow/mainwindow.cpp, .h: added support for several dock
+	windows
+	* src/pandoragroup/CGroup.c, .h: switched from a QDialog to a
+	QTreeWidget for better integration.
+	* src/pandoragroup/CGroupCommunicator.cpp: removed old qDebug message
+	* src/pandoragroup/CGroupChar.c, .h: added support for colored text
+	* src/preferences/configdialog.cpp, groupamangerpage.cpp: added
+	new icon, some extra logic to prevent crashes
+
+2008-07-23 02:30  jahara
+
+	* src/configuration/configuration.*: added a warning dialog for the
+	group manager
+	* src/mapcanvas/mapcanvas.cpp: allowed the user to use the color
+	selected for his box instead of yellow
+	* src/mainwindow/mainwindow.cpp, .h: cleaned up groupmanager code
+	* src/mainwindow/findroomsdlg.cpp, .h: added closedevent
+	* src/pandoragroup/CGroup.*, CGroupChar.*, CGroupCommunicator.cpp:
+	cleaned up the display window, added a warning dialog box, fixed
+	a reconnect bug
+	* src/pandoragroup/CGroupSettingsDialog.*: replaced by a preferences
+	page and therefore the files were removed
+	* src/parser/abstractparser.cpp, mumexmlparser.cpp: minor bug fix
+	for the groupmanager
+	* src/pathmachine/pathmachine.cpp: minor bug fix for the group
+	manager
+	* src/preferences/configdialog.*: added a hook to the groupmanager
+	* src/preferences/groupmanagerpage.*: preferences page for the
+	groupmanager
+
+
+2008-07-21 21:04  jahara
+
+	* src/configuration/configuration.cpp: finalized saving of
+	GroupManager window boundaries
+	* src/display/mapcanvas.cpp, .h: code cleanup
+	* src/mainwindow/mainwindow.cpp, .h: code cleanup
+	* src/mapdata/mapdata.cpp, .h: added support for sane roomflags
+	altering for the console commands
+	* src/pandoragroup/*: major code cleanup, polish
+	* src/parser/abstractparser.cpp, .h: added more console commands,
+	see _help for more details
+	* src/proxy/proxy.cpp, .h: code cleanup
+
+2008-07-20 21:44  jahara
+
+	* src/display/mapcanvas.cpp, .h, mapwindow.cpp, .h: added hooks for
+	drawing GroupManager characters
+	* src/mainwindow/mainwindow.cpp, .h: added hooks for GroupManager,
+	FindRooms, connects between various parts
+	* src/pandoragroup/*: This is the GroupManager that I ported from
+	Pandora, use it with caution! It is NOT STABLE
+	* src/parser/abstractparser.cpp, .h, mumexmlparser.cpp, .h: added
+	more connects and functions for the GroupManager
+	* src/pathmachine/pathmachine.cpp, .h: hooks for grabbing the
+	character's position for the GroupManager
+	* src/proxy/connectionlistening.cpp, .h, proxy.cpp, proxy.h: added
+	hooks for grouptells in the GroupManager.
+
+2008-07-19 08:00 jahara
+
+	* resources/mmapper2.qrc, resources/pixmaps/trail*.png: added images
+	for trail support. Also added a new image for FindRooms.
+	* src/display/mapcanvas.cpp, .h: added hooks for trails/centering
+	* src/mainwindow/findroomdlg.cpp, .h, .ui: ported the FindRooms
+	function from Pandora
+	* src/mainwindow/mainwindow.cpp, .h: fixed SaveAs bug
+	* src/parser/abstractparser.cpp, .h: fixed briefmode+examine bug,
+	added more console commands, ported latin2ascii function from
+	pandora
+	* src/mapdata/mapdata.cpp, .h: added hooks for searching for names,
+	exits, descriptions and toggling flags.
+
+2006-09-16 21:21  alve
+
+	* src/mapdata/roomfactory.cpp: trigger update if different amounts
+	  of whitespace are found when comparing rooms
+
+2006-09-16 15:55  alve
+
+	* src/parser/abstractparser.h, src/parser/parser.cpp,
+	  src/parser/parser.h: fixed scout problem in non-XML mode
+
+2006-09-16 13:33  alve
+
+	* src/parser/parser.cpp: ported new scout handling to none-xml
+	  parser
+
+2006-09-16 13:18  alve
+
+	* src/mapstorage/mapstorage.cpp, src/parser/abstractparser.cpp,
+	  src/parser/mumexmlparser.cpp, src/parser/mumexmlparser.h: fixed
+	  scout and river bugs in parser, removed warning about unused
+	  variable in mapstorage
+
+2006-08-23 13:24  caligor
+
+	* map/basemap.mm2, src/global/defs.h,
+	  src/mainwindow/mainwindow.cpp: updated version string
+
+2006-08-22 18:49  caligor
+
+	* src/proxy/telnetfilter.cpp: removed prompt all command
+
+2006-08-22 18:39  caligor
+
+	* src/parser/parser.cpp: bugfix: maping in normal mode - Exits line
+	  is appended to dynamic description
+
+2006-08-21 20:28  alve
+
+	* src/parser/mumexmlparser.cpp, src/parser/parser.cpp,
+	  src/proxy/telnetfilter.cpp: remove forcing the user to non-brief
+	  mode
+
+2006-08-21 08:24  alve
+
+	* src/mmapper2.pro: removed duplicate entry for mapaction.h
+
+

INSTALL

@@ -1,6 +1,6 @@
                  INSTALLING MMapper2 Version 2.0
 
-1.  You can get latest version of MMapper2 on http://mmapper.czechian.net web page.
+1.  You can get latest version of MMapper2 on http://sourceforge.net/projects/mmapper web page.
 
 2.  Uncompress the archive you downloaded into any directory,
     e.g. C:\mmapper2\ or ~/mmapper2
@@ -29,4 +29,7 @@
     MMapper2 exacutable will be built in mmapper2/bin/[debug|release] directory.]. 
     You dont need any other files to run programm.
 
+5.  Set up your client according to the wiki instructions at:
+    http://mume.org/wiki/index.php/Guide_to_install_mmapper2_on_Windows
+
 We hope you will enjoy using MMapper2. Good luck!

doc/design-principle

@@ -0,0 +1,65 @@
+The design principle for mmapper2
+
+When designing mmapper2 we tried to strictly build it around a component 
+architecture. Each functional component should have a strictly defined
+external interface and components should be exchangeable. Like this we
+thought we'd be able to exchange parts of the mapper when we'd see fit
+later on. For example we were quite sure that the parser component wasn't
+the best implementation of a parser already early in the implementation,
+but we kept it around "for now". 
+
+The interfaces between components were defined using QT signals and slots.
+Each component should have its "main" class, where those are defined. The
+main advantage of this approach is that external interfaces can be easily 
+recognized and that components can be reconfigured (reconnected) at runtime.
+Another advantage is that signals can be sent across thread boundaries. So
+the parser running in one thread can effortlessly send signals to the path
+machine running in a different thread - there is no need for explicit 
+synchronization. This especially proved to be very practical during the
+implementation. Unfortunately this approach also has a major drawback: 
+Signals and slots are "one-way", nothing can be returned, and they are 
+slower than functions. In reaction to that we introduced functional objects.
+Functional objects belong to one component, but are passed on to another
+via a slot in order to receive a number of function calls. For example the
+states of the path machine (Approved, Experimenting, Syncing) are 
+RoomRecipients, which means they are given to the mapdata component which
+feeds rooms into them via function calls. A similar construction is the 
+DrawStream, which handles the rendering (although it is formally part of
+mapdata, and doesn't get passed across component boundaries). In the end
+a lot of strange hacks have been introduced to circumvent the limitations
+of the signal/slot and component design, but the general principle is still
+recognizable.
+
+Most of the subdirectories of src constitute a components. Some components 
+are derived by inheritence. For example mmapper2pathmachine is a specialization 
+of pathmachine for mmapper2. The global, expandoracommon, configuration
+and resources directories aren't components.
+
+In order to avoid concurrent modification of rooms by various components a
+locking mechanism was introduced in the mapdata/mapfrontend component 
+(mapdata is a specialization of the more general mapfrontend for mmapper).
+Rooms are generally not writable for any component but the mapdata itself.
+They can be read though. When any of the lookingForRooms methods is called
+the mapdata remembers who called this method and "locks" the room for that
+component, so that it can't be modified. The lock is removed as soon as
+releaseRoom or keepRoom is called. releaseRoom means "I don't need the room
+anymore and I don't care about it being deleted", keepRoom means "I don't 
+need the room anymore right now, but it mustn't be deleted". Modifications
+of rooms are implemented via "MapAction". A component may schedule a 
+MapAction via scheduleAction and the mapdata will execute it as soon as
+there are no conflicting read locks on the respective rooms anymore. As a
+second alternative the execute methods can be used which will either 
+execute the action immediately or never and return the result (this is 
+obviously a breach of the signal/slot principle, you get the idea ...).
+
+Rooms are basically arrays of QVariant, so that they are easily extended
+or ported as needed. The specialization for mmapper2 isn't done via 
+inheritance here (that proved to be cumbersome) but via various 
+getXYZ(Room *) helper functions. That means their constructor is mostly
+useless and have to be constructed via a RoomFactory, especially the 
+Mmapper2RoomFactory.
+
+This should give you a general idea on how mmapper2 works. If you have
+further questions, please mail me: ulfonk_mennhar@gmx.de.
+
+alve

doc/ideas

@@ -0,0 +1,27 @@
+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.