Found during testing with humongous map files that the "Loading" & "Saving"
messages did not show up - turns out a qApp->processingEvents() call is
needed...  Whilst fixing that in relevant places on that the Profile
Preferences dialog also applied QStringLiteral(...)/ tr(...) wrappers as
needed.

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

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

…asis

It is possible to copy a saved map from one profile to another - even if
that other profile is in use.  However this will lose the details of where
the (other) player is located in THAT profile.  This commit aims to correct
that by sneaking a look at where the other player is and storing that
in the file that is both copied for this profile before it is copied and to
the file that is copied over.

This data was stored in (int) TMap::mRoomId which has now become a:
(QHash<QString, int>) TMap::mRoomIdHash with the profile name as the key
and the Value being the equivalent of mRoomId in the new code.  This has
required an increment in the Map file format version from 17 to 18.  The
default - that will be used unless the developer or tester changes it in
the Profile Preferences dialog remains at 16.

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

As well as fixing the Area ownership of rooms (which has been an issue that
crops up from past buggy TArea code) this also clears out custom exit line
junk - including details for lines where the key was an empty string, those
arose during previous buggy code that allow exit lines to be drawn without
specifying which exit they were for.

The checks also removes any stub exits that are present on rooms that have
an actual exit in the same (normal exit) direction.  The current code
prevents the creation of such things but it did not in the past (I have
encountered it - especially when the real exit is a "circular" one that
goes to the SAME room as it leaves from!)  BTW Such a exit type, although
initially seeming to be pointless is a feature of some MUDs and the normal
exit drawing code for the 2D map does not currently show them (future
thing to cover?) though a custom exit line can be drawn that shows the
"circular-ness" of the exit!

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

Refactor the code that identifies where player is in other profiles, saves
it in current profile's map, copies it to other profiles and tells them
to load it in.

The code to copy to another map as was only permitted one other profile to
be done at a time - this makes it difficult to ensure that all the profiles
get the same data for all the other affected maps. The profile selection
part of "Profile Preferences" "Mapper" has been changed to be something
that allows all the destination targets (other profiles) to be selected,
excluding the current profile (as that ALWAYS gets the new map - it is
intrinsic to the copying process).  Only when one (or more) other profiles
are selected does the "Copy" button become enabled and then all active
profiles are checked to see if they are included, their player room is
noted as before and all the details are written to the current profile's
new map.  After copying (with some checks for success) the map to ALL
profiles a signal is sent to all active profiles (with a list of profiles
to respond) that causes the listed ones to reload a new map from their
home map directory.  (Extensive, formatted!) tooltips have been added to
the two controls concerned in the profile preferences.

Slots and signals are used (via the singleton class mudlet) to try and
accommodate future situations when Mudlet becomes properly multi-threaded
and each profile runs in a different thread - getting the current room
from each profile may become more tricky THEN.

Also a bug where the currently selected (in the same dialog) map save file
format was not being used when the current profile's map has been changed
has been fixed in this commit.

===========================================================================
To support the inclusion of other profile player location data in the map
file  MAP FILE FORMAT 18 (or greater) MUST BE CHOOSEN BEFORE THE MAP IS
COPIED.
===========================================================================

If this is not done then the map will not contain the data and then the
other profiles' player will be reset to the location of the player in the
currently active profile - as would happen for the old code (prior to
commit entitled "Enhance: store current player location in map file on a
per profile basis").  One bonus of this code is that only one copy of the
map to be copied over is made in the current profile's directory and all
the copies will have the same date-time stamp name between the profiles,
instead of a sequence of differently timed files as the file is copied one
profile at a time that code prior to this series of commits will produce!

Some items in the profile_preferences.ui have been renamed to clarify their
type or purpose or change thereof:

QGroupBox:
* groupBox_3               ==> groupBox_mapFiles

QLabel:
* label_9                  ==> label_saveMap
* label_10                 ==> label_loadMap
* label_12                 ==> label_copyMap
* map_file_action          ==> label_mapFileActionResult

QPushButtons:
* copy_map_profile         ==> pushButton_copyMap
* load_map_button          ==> pushButton_loadMap
* save_map_button          ==> pushButton_saveMap

Changes:
* (QComboBox) mapper_profiles_combobox
                           ==> (QPushButton) pushButton_chooseProfiles

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

Recent code changes uses longer messages in the "label_mapFileActionResult"
in the "Mapper" tab of the "Profile Preferences" dialog, it was however
only occupying one of the three columns in the QGridLayout in the part of
the dialogue where it was place - so that when a long message is displayed
it caused all the surrounding widgets in the other columns in the same
layout to be pushed out of the way.  This tweak makes it occupy ALL three
columns so this no longer occurs!

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

I had got the logic wrong in identifying whether an exit was a normal or
a special exit - so the validation did not work correctly as to whether a
door could be allowed to be set/reset in a room.

Also: added a call to refresh the 2D mapper display if a change WAS
successfully made to the doors for a room...

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

The recently introduced code that "improved" the saving/sharing of a map
to other profiles had a superfluous signal/slot usage:
signal:
(void) dlgProfilePrerence::signal_otherProfilesToReloadMaps( QList<QString> )
connected to slot:
(void) mudlet::slot_requestProfilesToReloadMaps( QList<QString> );

When it is possible to call the replacement NON-slot:
(void) mudlet::requestProfilesToReloadMaps( QList<QString> ) directly from
the dlgProfilePreferences::copyMap() method without too much risk of
problems as Mudlet is current constructed. I spotted this whilst
investigating another, subsequently redirected coding task (in following
commit).

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

As per this message in the Forum:
http://forums.mudlet.org/viewtopic.php?f=13&t=4857&start=20#p24479
now that a recent commit correctly ensures that a TArea for the default
area Id of -1 IS instantiated - they have noticed that it shows up in the
area control widget (a non-editable QComboBox) whereas it had not in the
past. However the original poster has a need to HIDE that area from casual
inspection by the user of their package.  As the "fix" of that recent
commit does affect the application behaviour this commit provides both
script-able and GUI means to select whether to show the Default area in
that widget.

The setting DOES not persist between settings (it would not be easy to save
in a profile specific way without introducing a new setting to the game
save format - which is NOT currently versioned {unlike the Map file format}
and it is not really a map setting).

Also, it cannot be applied until a map display (mapper) is created - so the
option is hidden on the "Profile Preferences" => "Special Options" tab and
the lua command "setDefaultAreaVisible(bool)" will return false until there
is one; after that the checkbox control is shown on the dialog and will
return true from the lua command.  On profile loading/mapper creation the
Default Area WILL be shown in the widget - corresponding to a true value
to the lua command.  Using the lua command will immediately refresh the
list of Areas in that widget if the setting is changed.

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

As discussed in http://forums.mudlet.org/viewtopic.php?f=13&t=4818#p24498
this commit improves the way the centre of the view is selected when the
area selection widget is used to (temporarily) show a view of a different
area:
* A) if the selected area has the same z-coordinate as the current view
in the (2D) mapper then the mean coordinate of all the rooms on THAT level
is calculated and then the room nearest to that is chosen to be at the
centre of the view in the selected area.
* B) if the selected area does not have any rooms on the same level then
the level with the MOST rooms (and the lowest z coordinate if there are
ties) is chosen and the room closest to the mean again selected.
* C) if there are NOT rooms in the area then the view is centred on the
origin.
* D) if (after using the control more than once OR even if NOT) the
original area is selected then the view snaps back to the current player
room (this can be used to recenter on that if the scroll buttons have been
used to offset the view!)

The center of view position is made from code within the 2D mapper - but
there is no need to do the same for the 3D one - instead the area ID and
position is passed up to the TMap class instance which forwards the details
to the 3D mapper.

The bottom line is that (unless it is an empty area) a reasonable choice
of room is ALWAYS displayed in the centre of the map when the area is
changed manually (and the 2 and 3D maps will be centred on the same room).

Code associated with loading maps has been refactored in an attempt to
ensure that the area selection widget is set to the correct value before
the first use by the user - there was four places where the map file
was being loaded (although the one in the Host class constructor seems
unnecessary - and problematic to handle as the Host class is instantiated
before the mapper widget is created!) I *think* I have got it straight now
but some testing in the map down load from server case may need a check to
see that I have not broken anything.

Also:
* have tweaked the map information display to change the text format
to emphasise when it reflects details of a selection (the text turns a bit
orange and is written BOLD) or if the player room (which is what is
referred to if NO rooms are selected) is in this area (the data is written
in BOLD) or is not in the current area shown (the data is written in
ITALICS and not bold).

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

This detail was missing and was confusing when centerview(roomId) was used.

Also, handle the case when the displayed map IS the default area (through
using centerview(...) when the room is in that area AND the area widget has
been set to hide that area name OR it has just been told not to!

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