…rrect

Rename:
(void)TArea::fast_ausgaengeBestimmen(int)
                                     ==> TArea::determineAreaExitsOfRoom
(void)TArea::ausgaengeBestimmen(int) ==> TArea::determineAreaExits
(const)(QList<int>)TArea::getAreaExits() const
                                     ==> TArea::getAreaExitRoomIds()

Add new method to return area exit data in new, wanted format:
(const)(QMultiMap<int, QPair<QString, int> >) getAreaExitRoomData() const

In preparation to revising internal storage representation of area exit
data moved the: (QMultiMap<int, QPair<int, int> >)(TArea *)->exits member
from public to private area of class.  To permit save and load the
following have had to be made friends of the TArea class:
(bool)TMap::serialize( QDataStream & ) and  (bool)TMap::restore( QString )

Revise (void)TMap::init(Host *) to run (TArea *)->determineAreaExits() on
current and all previous map file format versions, will not be needed on
future version as the code to manage the areaExits data is now functional.
Previous code would have done this only for versions prior to 14 files
(current is 16) or if the lua function auditAreas() was manually run.  In
passing also modified code that "fixed-up" "old style" map labels so that
it is no longer run on current version files and pushes any messages that
that creates into the main profile console instead of using standard C++
cout calls which we deprecate now.

All code blocks that have been touched by this series of commits have been
re-formatted to current styles.

Update copyrights on all files touched that have not already been marked as
having been edited by myself.

Revised TLuaInterpreter::getAreaExits(...) to take a second optional
Boolean that if present and true cause it to return data about the area
exit directions and the destination rooms, if false or omitted, returns
only the rooms in the area that have exits out of it, reproducing the
previous implementation.  In either case the result is a table if there
are area exits (or a nil for an isolate area without exits); two additional
values are returned an informative, translatable, text message and an
integer status code that reflects the same information.

When moving a series of rooms to a different area via the 2D mapper's GUI
the recalculations for the area extremes {by TArea::calcSpan()} and the
out of area exits {by TArea::determineAreaExits()} can now be deferred
until the last room has been moved by passing a third true (boolean)
argument to TMap::setRoomArea(...) which defaults to false for other single
room at a time usages.  Though that method keeps a local copy of the areas
that have been modified and thus need updating, should the last room NOT
be processed (null TRooo pointer for room Id) a publicly accessible
"mIsDirty" flag is also used so that recovery code can identify and clean
up those affected areas otherwise.  It is possible that this flag may be
useful in other situations, such as when moving or adding multiple rooms
WITHIN an area.

*** This commit has been rebased so it's history might not be the same as
someone else's copy of it ***

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

…andard

Due to unawareness of standards I have deviated from them in producing
multiple return values upon success as well as failure.  Whilst I feel that
a second return value being a translatable status string and a third being
an integer encoding of the same might have some merit, particularly in a
fully internationalised and localised version of Mudlet in the future; no
decision has been made over precisely how I18n and L10n will be handled so
using them is a little premature and only confuses things for the moment.

The current methodology is:
* For bad argument TYPE situations: to throw a lua_error and provide a
error message using a fairly uniform construction, I provide these via
Qt's translation system to permit that part of the Lua API to be
translated with the C++ parts of the application's framework.

* For bad argument VALUE situations best practice is for a lua function to
provide a primary nil return value but to also provide a secondary value as
a string message describing the (first) argument value error.  A lua error
is NOT thrown but unless the user catches the error message by providing a
second variable to contain the second return value they may not find out
what is wrong.  Again I choose to provide a translatable message for this.

* For good arguments case that are satisfactory but produce no data, an
empty table, an empty string or a signal number value is an appropriate
primary return value. For example for either type of table that the lua
getAreaExits((int) areaId, <(bool) provide Full data> ) function now
returns, an empty table will be returned for an area which is isolated and
has no exits.  A secondary return value is NOT expected in this situation
as far as I can tell, though I believe one could be useful...

* For good arguments values for functions that provide data then the data
is returned as the primary and only return value.

* For good arguments values for functions that do not return data then
success should be indicated by a single true Boolean return value.

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>