This is a squashed down commit containing several commits with
messages - this is the edited combination of all the messages:
As well as being able to use any grapheme it is possible to use a
short word as well as anything printable from any of the Unicode
Multiple Planes; although the former will become smaller to fit within
both the square and round room shapes on the 2D mapper.
Adds controls to the profile preference to set the (preferred) font to
use to set the room symbols from and a checkbox to only use that font.
Additionally a sub-dialog can be brought up which lists the details of all
the different symbols on the map - showing the Unicode codepoint(s) for
each and showing how they would be rendered if only the selected font is
used and if any font is permitted, along with a count of the usages and
the rooms that use each one... A status icon is also displayed showing
whether the symbol can be rendered entirely with the selected font (green
tick), only by using glyphs from other fonts (yellow ! warning) or not with
the current fonts on the system (red/white cross). This allows a user to
make a sensible selection of a font to use or whether they will have a
problem (and a replacement by the replacement character '�') for any
symbols.
Updates Lua setRoomChar and getRoomChar to handle the wider
range of things that can be used. getRoomChar NOW allows for an
existing character to be cleared with an empty string or a space as
the char attribute.
The map format version has been incremented to allow the data needed to be
saved directly into the binary file format but failback code is in place
that means that this feature can be carried in map and room user data
instead for map format versions down to 17 - the current default is 18 and
there is limited support to fail gracefully down to the 16 that Mudlet 2.1
uses (all the room letter markings that are not supported will become '?',
and the font data will be lost, but the correct room character data will
still be in the room user data.)
Following review:
* I replaced some colour specifications (white and transparent) with
Qt constants.
* Use the same inline function flushSymbolPixmapCache() to clear
the map symbol pixmap cache in all places where it might be useful.
* Simplify a couple of places where an if(...) {...} else {...} can be
replaced with the (...) ? (...) : (...) operator.
* Limit the number of room numbers displayed for each symbol in the
new widget - to avoid complications where there are huge numbers
of rooms using a symbol.
* Replace a use of QTableWidget::clearContents() with
QTableWidgets::setRowCount(0) as I was getting some odd, deep
in the Qt internal library issues {Fatal Seg. Faults!} with the former,
which I suspect, but could not prove, might have been a
re-entrancy issue caused by the method containing it being called
indirectly by an asynchronous SIGNAL/SLOT originating in the
value change from the map symbol font selection QFontComboBox...
Revised to NOT do scaling when drawing room symbols from cache:
the previous QPainter::drawPixmap(...) performed a scaling operation to
make the symbol pixmap fit the specified rectangle. This is the cause
behind the poor rendering of text characters as the scaling undoes the
benefits of anti-aliasing and takes time to do. This should be faster now
because the pixmaps are generated at the size/resolution they are needed
(though they do have to be thrown away and regenerated if the zoom
or other sizing factors change) - they do however look better to me!
Also:
* merged (int) TRoom::xzoom and TRoom::yzoom into TRoom::xyzoom.
* added the symbol scaling "fudge-factor" to the "Special Options" tab of
the "Profile preferences" dialog - it may be helpful to artificially
over-size (> 1.00) or under-size (< 1.00) the symbols in some situations.
* uses the word symbol rather than just glyph/grapheme in some texts.
Also modified 2D mapper "Symbol" tooltip to observe that more than one
letter/symbol can be used (although they will be drawn smaller so that they
still fit).
Add tool-tips to profile preferences dialog for font controls (except for
"fudge factor" control (with range x0.50 to x2.00 for scaling of symbol
to test rectangle used to fit it into the room shape)...
I have consistently mispelled chosen as choosen but I have fixed that
now...!
Also added tooltips to map glyph usage table/widget.
WorkAround: try to force a specific US mirror for zziplib on AppVeyor CI
AppVeyor is based in Vancouver, Canada so the nearest SF Mirror is in the
US so this commit forces the use of that mirror for that library for the CI
build process as an attempt to get around the repeated, intermittent
failures to get that library from SourceForge (it is now the only item that
needs to be downloaded from there for such builds)...
Also adds another CI file that was not mentioned before in the qmake
project file and thus did not show up in the Qt IDE.
Following extensive discussions it has been made clear that introducing
replacements for the lua [gs]etRoomChar(...) is not going to happen.
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Using a static method means that we can centralise the generation of
strings used to access parts of the file system used to hold Mudlet user
data - which may be useful if we change them for - say running from a
thumb-drive or just to use an OS specific location for them. {Using a
".config/mudlet" sub-directory on Windows is not quite how that OS expects
things to be done...!}
This also reduces the number of raw strings that will have to be wrapped
in QStringLiteral(...) and the like for forthcoming I18n work.
Also:
* The use of "mudlet-data" as a windows symlink sub-directory to
".config/mudlet" in the user home directory may not work because the Qt
Documentation suggests that a ".lnk" extension is required - this commit
adds that FOR THAT OS ONLY.
* Previous code placed (only some - for an unexplained reason not all the
files were being copied) the DejaVu fonts that we include in the
resources directly into the main mudlet user data folder - but the
included documentation including the COPYRIGHT.TXT and other files ONLY
relate to those font files and NOT to Mudlet as a whole. I have taken
the liberty of moving and loading them from a ./fonts/ subdirectory which
makes more sense. I have noted that, at least, the Debian Linux
packager actually removes the font files from their configuration because
they already include a shared system wide copy of the same fonts and in
a much newer (2.37 at present) version compared to the 1.10 that we
bundle - perhaps our code needs to check for the existence/availability
of the fonts before we try to load ours into the Mudlet application at
run-time!
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
A code structure error in a prior fix meant that instead of sorting the
missing areas if there was more than one such area BEFORE creating them
ALL, the corner case of a single missing area was not being created as
required.
Also move two separate QString::arg() usages into a single instance as
per new coding guidelines - as the first is a number it is necessary to
force it to a QString to avoid a compile failure (in later Qt versions ?)
that have a twin argument overload that expects a first number argument to
be followed by a second numeric value being a width specifier.
Also re-layout a few related console messages to avoid hitting a default
re-wrapping width at 80 characters.
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
* Replace chained .args with multi-arg
Saves on memory allocations and it's especially useful in some performance-critical functions like the mapper paint event.
* Updated default map format to 18
This means that maps will now be saved in map format 18 by default and will require Mudlet 3.0.0 at minimum to load.
Ensure all system generated events have event names that are NOT subjected
to translation. However as I have recently learned that QLatin1String is
a better choice in most circumstances as opposed to QStringLiteral I have
changed to use them instead.
As it is concerned with using QLatin1String wrappers around things
involving TEvent instances I have extended the re-coding to the qDebug()
code provided in TEvent.h to produce a formatted and useful dump of a
TEvent instance should it be passed to the Qt Debug system methods.
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
clang-format has an option to sort header #include lines in source code
files - however the `#include "pre_guard.h"` and `#include "post_guard.h"`
includes are position sensitive - they must wrap around Qt's own classes'
includes in our files and they must not be tidied-up/rearranged.
This commit adds the necessary comments that commands clang tools to not
touch these lines.
We had previously done this on the XMLimport class as a test case but
during recent major branch merging operations one of these comments was
lost from the XMLimport.cpp file!
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
* Fix memory leak when copying maps - room made for stats and not deleted
Changed it to use a stack instead as it's just one object using the heap for this isn't entirely necessary, plus stack is faster.
Fixes CID 1415058.
* Fix memory leak when copying maps to another profile
Use stack instead of heap as the room data is discarded anyway - needs to be read in order to advance the stream.
Fixes CID 1415071
Fixes up some `TEvent` related conflicts, choosing ones generated locally
within a function - AC fix was in:
commit-4548001faca2e33d97f29ee11ae18931249f325f
which made the relevant function `Host::raiseEvent(TEvent &)` which thus
needs to be supplied with an actual `TEvent` instance rather than a pointer
to a `new TEvent` instance.
Also resolves un-TEvent related conflicts in dlgTriggerEditor.h, TMap.cpp
TLuaInterpreter.h to clear those particular files of remaining issues.
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
This is The Merge to merge what is essentially a fork in release_30 back into development branch. As both branches have diverged and been actively worked on, neither is automatically right in a merge conflict - use git blame and commit timestamps, plus some reasoning as to which change is better, to figure out which conflict needs to be resolved and how.
It says the origin is SlySven/release_30 - just happened to pick one of the many remotes I had, SlySven/release_30 is the latest 3.0 release.
Strategy:
* create a development_merge_30 branch based on development
* force-merge release_30 to development_merge_30 and push with conflicts still included
* send in PRs to development_merge_30 to resolve merge conflicts as we get through them
* once all conflicts are gone, merge development_merge_30 into development
# Conflicts:
# .travis.yml
# CI/travis.linux.before_install.sh
# CI/travis.linux.install.sh
# CMakeLists.txt
# src/ActionUnit.h
# src/CMakeLists.txt
# src/EAction.h
# src/Host.cpp
# src/Host.h
# src/T2DMap.cpp
# src/T2DMap.h
# src/TAlias.cpp
# src/TAlias.h
# src/TAstar.h
# src/TBuffer.cpp
# src/TBuffer.h
# src/TConsole.cpp
# src/TConsole.h
# src/TEasyButtonBar.cpp
# src/TEvent.h
# src/TFlipButton.h
# src/TLuaInterpreter.cpp
# src/TLuaInterpreter.h
# src/TMap.cpp
# src/TMap.h
# src/TRoom.cpp
# src/TRoom.h
# src/TRoomDB.cpp
# src/TTextEdit.cpp
# src/TTextEdit.h
# src/TTimer.cpp
# src/TTimer.h
# src/TTrigger.cpp
# src/Tree.h
# src/XMLexport.cpp
# src/XMLimport.cpp
# src/XMLimport.h
# src/ctelnet.cpp
# src/ctelnet.h
# src/dlgConnectionProfiles.cpp
# src/dlgMapper.h
# src/dlgProfilePreferences.cpp
# src/dlgTriggerEditor.cpp
# src/dlgTriggerEditor.h
# src/glwidget.h
# src/mudlet-lua/genDoc.sh
# src/mudlet-lua/lua/GUIUtils.lua
# src/mudlet-lua/tests/GUIUtils.lua
# src/mudlet.cpp
# src/mudlet.h
# src/src.pro
# src/ui/main_window.ui
# src/ui/profile_preferences.ui
We're not lab scientists here working with very detailed timing data, just people wanting to play a game - nine decimal level precision is unwarranted. In fact even reporting the time is unimportant, the only thing that matters is that it happens fast and when it's not fast, the user knows when it'll finish.
The I.R.E. MUD Midkemia-online was shutdown on 2016/09/07 and it is not
helpful to continue to offer it as a predefined MUD in the connection
dialog.
This commit removes it from that list and adds a favourite of
mine "WoTMUD" to replace it. The logo is a temporary one that I will
replace with a similar one that I need to get clearance to use (and release
with a GPL2.1+ licence) from the Wheel of Time MUD sysop with whom I am in
contact {Vivienne needs to get approval from the creator Flash who is away
for a few days...!}
The dlgConnectionProfiles.cpp file has quite a few ASCII strings, as
appropriate for a file that will in the future be subject to I18n work I
took the opportunity to put QStringLiteral(...) wrappers around the
QStrings that are used for non-GUI tasks and tr(...) ones that are. I
expect it isn't complete but it goes someway towards dealing with THIS
particular file - and it should improve very slightly the generation of
QStrings that need to be constructed because it means as much of possible
of them is done at compile rather than run-time...!
In relation to the above there are points in the code where QStrings are
compared to "" to see if they do not have any contents - the isEmpty()
method is a better way to do the same (it does not involve a string
expression)
In (void)dlgConnectionProfiles::slot_update_name( const QString ) there are
a couple of variables that use a double underscore prefix - that is NOT A
Good Idea: such a prefix is RESERVED in both C and C++. For example see:
[what-are-the-rules-about-using-an-underscore-in-a-c-identifier](http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier)
also a single prefix might be a bit of a problem with libraries...
I have renames the offending things there - but I may have used the single
underscore prefix myself in the past. *blush*
There are some help messages in this class that use an apostrophe in a word
contraction - as a matter of readability this is not considered best
practice IMHO so I have converted them to the full words.
Following experiences in my previous Pull Request I also took a look at
the initialisation and use of some member variables; it became clear that:
* (QString) dlgConnectionProfiles::mOrigin
* (bool) dlgConnectionProfiles::mEditOK
were not used and could be simply deleted and that:
* (QString) dlgConnectionProfiles::mUnsavedProfileName
* (QString) dlgConnectionProfiles::mCurrentProfileEditName
did not need to be member variables and could be local to the method that
used them, so in (void)dlgConnectionProfiles::slot_save_name():
* (QString) dlgConnectionProfiles::mCurrentProfileEditName becomes
local: (QString) currentProfileEditName
and in (void) dlgConnectionProfiles::slot_addProfile():
* (QString) dlgConnectionProfiles::mUnsavedProfileName becomes
local: (QString) newName
also added initialisers for:
* (QStringList) dlgConnectionProfiles::mProfileList
* (QPushButton *) dlgConnectionProfiles::connect_button
* (QLineEditQPushButton *) dlgConnectionProfiles::delete_profile_lineedit
* (QPushButton *) dlgConnectionProfiles::delete_button
Whilst looking at the dlgProfilePreferences c'tor I saw that immediately
adjacent to where I was editing was some dead code relating to setting a
QPalette for the buttons used to edit various aspects of the profile's
colours for the consoles and the map - by re-factoring the code I was able
to clean it up to use quite a few less lines.
The above also led me to check some other methods in the same class and I
spotted that there was code in most of the set{color}() ones that was
trying to set a palette AND a stylesheet for the SAME things (those
previously mentioned buttons). The Qt Docs say of QtWidget::setPalette :
"Warning: Do not use this function in conjunction with Qt Style Sheets.
When using style sheets, the palette of a widget can be customized using
the "color", "background-color", "selection-color",
"selection-background-color" and "alternate-background-color"."
Observing that this warning was not being heeded I cleaned up those methods
with the effect that they became significantly simpler - and on testing
worked the same, at least on my Linux platform...
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
* Update: remove Midkemia (and add WoTMUD) to list of predefined MUDs
The I.R.E. MUD Midkemia-online was shutdown on 2016/09/07 and it is not
helpful to continue to offer it as a predefined MUD in the connection
dialog.
This commit removes it from that list and adds a favourite of
mine "WoTMUD" to replace it. The logo is a temporary one that I will
replace with a similar one that I need to get clearance to use (and release
with a GPL2.1+ licence) from the Wheel of Time MUD sysop with whom I am in
contact {Vivienne needs to get approval from the creator Flash who is away
for a few days...!}
The dlgConnectionProfiles.cpp file has quite a few ASCII strings, as
appropriate for a file that will in the future be subject to I18n work I
took the opportunity to put QStringLiteral(...) wrappers around the
QStrings that are used for non-GUI tasks and tr(...) ones that are. I
expect it isn't complete but it goes someway towards dealing with THIS
particular file - and it should improve very slightly the generation of
QStrings that need to be constructed because it means as much of possible
of them is done at compile rather than run-time...!
In relation to the above there are points in the code where QStrings are
compared to "" to see if they do not have any contents - the isEmpty()
method is a better way to do the same (it does not involve a string
expression)
In (void)dlgConnectionProfiles::slot_update_name( const QString ) there are
a couple of variables that use a double underscore prefix - that is NOT A
Good Idea: such a prefix is RESERVED in both C and C++. For example see:
[what-are-the-rules-about-using-an-underscore-in-a-c-identifier](http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier)
also a single prefix might be a bit of a problem with libraries...
I have renames the offending things there - but I may have used the single
underscore prefix myself in the past. *blush*
There are some help messages in this class that use an apostrophe in a word
contraction - as a matter of readability this is not considered best
practice IMHO so I have converted them to the full words.
Following experiences in my previous Pull Request I also took a look at
the initialisation and use of some member variables; it became clear that:
* (QString) dlgConnectionProfiles::mOrigin
* (bool) dlgConnectionProfiles::mEditOK
were not used and could be simply deleted and that:
* (QString) dlgConnectionProfiles::mUnsavedProfileName
* (QString) dlgConnectionProfiles::mCurrentProfileEditName
did not need to be member variables and could be local to the method that
used them, so in (void)dlgConnectionProfiles::slot_save_name():
* (QString) dlgConnectionProfiles::mCurrentProfileEditName becomes
local: (QString) currentProfileEditName
and in (void) dlgConnectionProfiles::slot_addProfile():
* (QString) dlgConnectionProfiles::mUnsavedProfileName becomes
local: (QString) newName
also added initialisers for:
* (QStringList) dlgConnectionProfiles::mProfileList
* (QPushButton *) dlgConnectionProfiles::connect_button
* (QLineEditQPushButton *) dlgConnectionProfiles::delete_profile_lineedit
* (QPushButton *) dlgConnectionProfiles::delete_button
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
* More: two items missed from prior commit
In the previous commit I forgot to take out:
* a check for Midkemia in the dlgProfilePreferences class constructor that
enabled the download map options;
* a similar check in (bool)TMap::restore(QString) that asked if the user
wanted to download a map if there was not one found.
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
* Tweak: Insert MUD supplied Logo/Icon
Received an icon as a .jpg that the MUD operators can allow us to licence
as GPL2.1+ which I have converted to a .png file.
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
* Enhance: fix map downloading code, add manual XML map importing
A recent move by I.R.E. to using SSL for their public MUD map URLs broke
the ability for Mudlet to download those XML format files. This commit
addresses this issue (as mentioned in, but not the original problem
referred to in https://bugs.launchpad.net/mudlet/+bug/1427364) the revision
to the code does now use "https://www.<MUD URL>/maps/map.xml" as a default
name for the I.R.E. MUDS - however the method that initiates the download
which was moved to TMap class from the dlgMapper one (see below) is now:
(bool) TMap::downloadMap( const QString * remoteUrl = Q_NULLPTR,
const QString * localFileName = Q_NULLPTR )
which if not supplied with any arguments behaves as before. However the
remoteUrl argument may be given as a full QString including the scheme (the
bit of the URL at the beginning before the ':') to override that and a
second argument may be used to provide a different name to use for the
local file name which if is a RELATIVE pathFileName will be resolved in
relation to the profile directory. At present no use is made of this
additional functionality but it may be useful for use with other MUDs if
they should choose to provide XML map files with other remote locations
and scripts using a different local filename.
As a long-standing thing that needed doing I have finally provided a means
to import a map XML file that - for instance - has already been download.
It had been noted that there was no way to read those I.R.E. map files even
if they had been obtained from a web browser able to correctly handle
https: URLs - now both the TLuaInterpreter::loadMap() and the
dlgProfilePreference "loadMap" button {NOT the IRE only "map download" one}
will both handle files ending in ".xml" (not case sensitive so it'll work
MacOS platforms as well!} For the loadMap case it will be necessary to
change the filetype filter on the File Selection dialog to select "xml"
files.
During testing it became clear to me that it was possible to try and read
one or more XML files via several mechanisms simultaneously with
"unhelpful" consequences. As well as hitting the dlgProfilePreferences
IRE "map download" multiple times, the TLuaInterpreter::loadMap() does NOT
block until the map has been loaded and as the import time {running of
XMLinport::readPackage(...)} is of significant duration for a large map (a
debug, without optimisation, build on my 1.8GHz Quad-core took over two
minutes to process the current Achaea map file) it is very possible to
get conditions where the same profile will try to run
XMLinport::readPackage(...) asynchronously - given that a profile only
supports ONE map at a time it was necessary to fit a QMutex to prevent
the part of the XMLinport class relating to XML Map files being called from
different places in the map related code. This means that if a map
download is started further downloads and any local map imports will fail
until that first download has completed or aborted. Similarly a local
import will prevent a download being started. As a side effect this cures:
https://bugs.launchpad.net/mudlet/+bug/852861 - "Map download button starts
another download thread if one is already going"
The previous XML import code was not adding the rooms that it parsed to the
relevant TArea::rooms member - although this would be picked-up and fixed
by TMap::audit() later on, this would be accompanied by an error message
about every single room. The code now builds up this information while
parsing the rooms' details and inserts it so that this does not cause
report-able problems during the TMap::audit() execution - the data gathered
also allows missing areas to be spotted so that if a room claimed to belong
to an area that was not included in the preceding areas' data an unnamed
area is created for it.
As a consequence of the long time to actually parse an XML map file I have
enhanced the progress dialog that was originally used to track the map file
download. It is now retained until the file is completely imported and
shows more information about the process - importantly it shows during the
XMLimport::readRoom(...) the room id being processed - and THAT method is
the time/cpu hog so seeing something happening during the time that Mudlet
otherwise appears to hang is useful feedback even if it adds a few seconds
to the overall duration (may be more than a minute). This dialog is now
also used during the other routes that involve reading an XML file and
there is now a bit of consistence with the on-screen messages.
Whilst inspecting XMLimport class I found there was some uncertain
initialisation which I have tidied up.
In summary:
Added:
* (bool) TConsole::importMap(const QString & location)
* (void) TRoomDB::setAreaRooms(const int areaId, const QSet<int> & roomIds)
* image file mudlet_map_download.png used as icon for download/import
progress dialog
* (bool) TMap::importMap(QFile & file)
* (bool) TMap::readXmlMapFile(QFile & file)
* (void) TMap::slot_downloadError(QNetworkReply::NetworkError error)
* (void) TMap::reportStringToProgressDialog(const QString text)
* (void) TMap::reportProgressToProgressDialog(const int current,
const int maximum)
Revised:
* (int)TLuaInterpreter::loadMap( lua_State * )
* Moved XML map download code from dlgMapper class to the TMap one:
+ (void) dlgMapper::downloadMap() ==>
(bool) TMap::downloadMap(const QString * remoteUrl,
const QString * localFileName)
+ (void) dlgMapper::setDownloadProgress(qint64, qint64) ==>
(void) TMap::slot_setDownloadProgress(qint64,qint64)
+ (void) dlgMapper::cancel() ==> (void) TMap::slot_downloadCancel()
+ (void) dlgMapper::replyFinished(QNetworkReply *) ==>
(void) TMap::slot_replyFinished(QNetworkReply *)
* Enhanced download progress indication to also include parsing which can
take even more time than download!
* Provide means to import local XML map file
* Prevent trying to import/download more than one map at a time
Renamed:
* (void) XMLimport::readAreaNames() ==> XMLimport::readArea() - for
consistency with related functions
Commented out unused:
* (void) XMLimport::readUnknownRoomElement()
Note the movement of the map file download code to the TMap class does
require making the latter a class with the Q_OBJECT macro (which removes
the need for Q_DECLARE_TR_FUNCTIONS as a side-effect!) - though as
another side-effect the TMap header needed a boost name specifier added to
one identifier as that identifier ("property") exists in both boost and
QObject classes!!! YOU MAY NEED TO RUN QMAKE ON THE PROJECT IF THE
BUILD SYSTEM DOES NOT PICK UP THE ADDITION OF "Q_OBJECT" TO TMAP CLASS.
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
* BugFix: Include missing #include, remove unused return value
The absence of this was causing build errors on the Travis C.I. platform!
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
* BugFix: move TMap.h to mudlet_MOC_HDRS to fix CMake build issue
As we have made TMap inherit from QOject - to have signal/slot
functionality that class needs to be run through Qt's MOC - and to do that
with the CMake project/build system it needs to be included in the files
included in the projects *_MOC_HDRS {and removed from the *_HDRS} variable.
Also spotted a trivial error in that specifying a const return value from
method is ineffective and pointless - so removed it from:
TMap::retrieveMapFileStats(QString,QString *,int *,int *,int *,int *)
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
* Tweak: clean up TMap initialisation/clearing actions
Now restores the customEnvColors set up on initialisation but that was
cleared when the map replaced with another one that is loaded {which
subsequently replaces that element anyway} or imported {which merely
writes over it, replacing any matching keys}. Initialises elements that
when inspected on the entry to the constructor proper previously were not
being set to a consistent value {booleans/ints/floats}.
NOTE: This will now clear the map user data member when the map is cleared
if the date is required to be saved when one map is loaded OR IMPORTED over
an existing one then the data will need to be saved outside of the map - as
is already need for areas and rooms user data!
Also comment out or remove unused members/methods:
* (void) TMap::getConnectedNodesGreaterThanX(int, int)
* (void) TMap::getConnectedNodesSmallerThanX(int, int)
* (void) TMap::getConnectedNodesGreaterThanY(int, int)
* (void) TMap::getConnectedNodesSmallerThanY(int, int)
* (void) TMap::astBreitenAnpassung(int, int)
* (void) TMap::astHoehenAnpassung(int, int)
* (void) TMap::exportMapToDatabase()
* (void) TMap::importMapFromDatabase()
* (QVector3D) TMap::span
* (int) TMap::mViewArea
* (QMap<QString, int>) TMap::pixNameTable
* (QMap<int, QPixmap>) TMap::pixTable
* (bool) TMap::isToDisplayAuditErrorsToConsole
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
* ImplimentationFixes: activate a valid optimisation & remove redundant code
Adding a true as a non-default 3rd argument to TRoomDB::addRoom(...) call
in XMLimport::readRoom(...) enables a significant optimisation (skips a
computationally expensive step when ADDING a room to new map) which
dramatically reduces the time to parse an XML map file. It also pointed
to the fact that the TRoomDB::entranceMap was already correctly being
handled and didn't need to be regenerated in XMLimport::readRoom(...) so
the code that was added in a previous commit was redundant and could be
removed.
A code error in TMap::slot_setDownloadProgress(...) that caused an issue
that a reviewer found on test has been fixed - the total download filesize
that was being sent by the Qt system signal that is connected to this slot
was a -1 value (as IS DOCUMENTED) when the Qt system does NOT know the
size of a QNetworkReply in advance of reaching the end of the download was
incorrectly handled in a previous commit in this change set.
Also found during testing that there is no need for an error message for
the QNetworkReply::OperationCanceledError case in
TMap::slot_replayFinished(...) as it is already handled in the
TMap::slot_downloadCancel() slot.
Changed the text put up onto the progress widget during the XML room
parsing to be a room count - which is likely more useful and to only do it
for every hundredth room - which reduces any delay "wasted" in writing to
the display - combined, the effects seem satisfactory IMHO.
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
* Tweak: provide error messages for TLuaInterpreter::loadMap(...)
Errors for the XML map file importing process as initiated from the Lua
command should be returned to that command rather than plastered onto the
main profile console - this commit attempts to perform that effect.
In testing found that there was no error handling for failure to find or
open the nominated file so messages for that have been added as well.
Due to the previous program logic the action of creating a mapper widget
using the main toolbar button automatically loaded the "default" (the
newest Mudlet Map file format file from the currently active profile's map
sub-directory). Under some previous situations it looked as though a map
might be loaded twice as mudlet::slot_mapper() was called both directly and
via signal/slot action. These were resolved by turning that slot into a
wrapper that now calls the body of code formerly within to a new method
mudlet::createMapper( bool isToLoadDefaultMapFile = true ) with a
the default value as an argument. This allows other usages of the body of
code to be called directly with a suitable argument, which for the
TConsole::loadMap() & TConsole::importMap() and the
dlgProfilePreferences::downloadMap() cases is false as they are all do not
want the "default" map!
Also:
* spotted a word "area" missing from an advisory text in
TRoom::auditRooms(...).
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
* Tweak: fix minor bug, correct a spelling, undo a few capitalisations
Under certain, unanticipated (error with no error message) conditions
TLuaInterpreter::loadMap(...) would push both a nil and then a false value
onto the stack for return {wrong} but only indicate one value {correct}.
The textual matters were found during peer review.
off-by: Stephen Lyons <slysven@virginmedia.com>
A recent move by I.R.E. to using SSL for their public MUD map URLs broke
the ability for Mudlet to download those XML format files. This commit
addresses this issue (as mentioned in, but not the original problem
referred to in https://bugs.launchpad.net/mudlet/+bug/1427364) the revision
to the code does now use "https://www.<MUD URL>/maps/map.xml" as a default
name for the I.R.E. MUDS - however the method that initiates the download
which was moved to TMap class from the dlgMapper one (see below) is now:
(bool) TMap::downloadMap( const QString * remoteUrl = Q_NULLPTR,
const QString * localFileName = Q_NULLPTR )
which if not supplied with any arguments behaves as before. However the
remoteUrl argument may be given as a full QString including the scheme (the
bit of the URL at the beginning before the ':') to override that and a
second argument may be used to provide a different name to use for the
local file name which if is a RELATIVE pathFileName will be resolved in
relation to the profile directory. At present no use is made of this
additional functionality but it may be useful for use with other MUDs if
they should choose to provide XML map files with other remote locations
and scripts using a different local filename.
As a long-standing thing that needed doing I have finally provided a means
to import a map XML file that - for instance - has already been download.
It had been noted that there was no way to read those I.R.E. map files even
if they had been obtained from a web browser able to correctly handle
https: URLs - now both the TLuaInterpreter::loadMap() and the
dlgProfilePreference "loadMap" button {NOT the IRE only "map download" one}
will both handle files ending in ".xml" (not case sensitive so it'll work
MacOS platforms as well!} For the loadMap case it will be necessary to
change the filetype filter on the File Selection dialog to select "xml"
files.
During testing it became clear to me that it was possible to try and read
one or more XML files via several mechanisms simultaneously with
"unhelpful" consequences. As well as hitting the dlgProfilePreferences
IRE "map download" multiple times, the TLuaInterpreter::loadMap() does NOT
block until the map has been loaded and as the import time {running of
XMLinport::readPackage(...)} is of significant duration for a large map (a
debug, without optimisation, build on my 1.8GHz Quad-core took over two
minutes to process the current Achaea map file) it is very possible to
get conditions where the same profile will try to run
XMLinport::readPackage(...) asynchronously - given that a profile only
supports ONE map at a time it was necessary to fit a QMutex to prevent
the part of the XMLinport class relating to XML Map files being called from
different places in the map related code. This means that if a map
download is started further downloads and any local map imports will fail
until that first download has completed or aborted. Similarly a local
import will prevent a download being started. As a side effect this cures:
https://bugs.launchpad.net/mudlet/+bug/852861 - "Map download button starts
another download thread if one is already going"
The previous XML import code was not adding the rooms that it parsed to the
relevant TArea::rooms member - although this would be picked-up and fixed
by TMap::audit() later on, this would be accompanied by an error message
about every single room. The code now builds up this information while
parsing the rooms' details and inserts it so that this does not cause
report-able problems during the TMap::audit() execution - the data gathered
also allows missing areas to be spotted so that if a room claimed to belong
to an area that was not included in the preceding areas' data an unnamed
area is created for it.
As a consequence of time to actually parse an XML map file I have enhanced the
progress dialog that was originally used to track the map file download.
It is now retained until the file is completely imported and shows more
information about the process - importantly it shows during the
XMLimport::readRoom(...) a count of 100's of rooms processed. This dialog is now
also used during the other routes that involve reading an XML file and there
is now a bit of consistence with the on-screen messages. However errors for
the XML map file importing process as initiated from the Lua command are
generally returned to that command rather than plastered onto the main profile
console.
Adding a true as a non-default 3rd argument to TRoomDB::addRoom(...) call
in XMLimport::readRoom(...) enables a significant optimisation (skips a
computationally expensive step when ADDING a room to new map) which
dramatically reduces the time to parse an XML map file.
Whilst inspecting XMLimport class I found there was some uncertain
initialisation which I have tidied up.
Note the movement of the map file download code to the TMap class does
require making the latter a class with the Q_OBJECT macro (which removes
the need for Q_DECLARE_TR_FUNCTIONS as a side-effect!) - though as
another side-effect the TMap header needed a boost name specifier added to
one identifier as that identifier ("property") exists in both boost and
QObject classes!!! YOU MAY NEED TO RUN QMAKE ON THE PROJECT IF THE
BUILD SYSTEM DOES NOT PICK UP THE ADDITION OF "Q_OBJECT" TO TMAP CLASS.
Also spotted a trivial error in that specifying a const return value from
method is ineffective and pointless - so removed it from:
TMap::retrieveMapFileStats(QString,QString *,int *,int *,int *,int *)
Now restores the customEnvColors set up on initialisation but that was
cleared when the map replaced with another one that is loaded {which
subsequently replaces that element anyway} or imported {which merely
writes over it, replacing any matching keys}. Initialises elements that
when inspected on the entry to the constructor proper previously were not
being set to a consistent value {booleans/ints/floats}.
NOTE: This will now clear the map user data member when the map is cleared
if the date is required to be saved when one map is loaded OR IMPORTED over
an existing one then the data will need to be saved outside of the map - as
is already need for areas and rooms user data!
Due to the previous program logic the action of creating a mapper widget
using the main toolbar button automatically loaded the "default" (the
newest Mudlet Map file format file from the currently active profile's map
sub-directory). Under some previous situations it looked as though a map
might be loaded twice as mudlet::slot_mapper() was called both directly and
via signal/slot action. These were resolved by turning that slot into a
wrapper that now calls the body of code formerly within to a new method
mudlet::createMapper( bool isToLoadDefaultMapFile = true ) with a
the default value as an argument. This allows other usages of the body of
code to be called directly with a suitable argument, which for the
TConsole::loadMap() & TConsole::importMap() and the
dlgProfilePreferences::downloadMap() cases is false as they are all do not
want the "default" map!
Also:
* spotted a word "area" missing from an advisory text in
TRoom::auditRooms(...).
In summary:
Added:
* (bool) TConsole::importMap(const QString & location)
* (void) TRoomDB::setAreaRooms(const int areaId, const QSet<int> & roomIds)
* image file mudlet_map_download.png used as icon for download/import
progress dialog
* (bool) TMap::importMap(QFile & file)
* (bool) TMap::readXmlMapFile(QFile & file)
* (void) TMap::slot_downloadError(QNetworkReply::NetworkError error)
* (void) TMap::reportStringToProgressDialog(const QString text)
* (void) TMap::reportProgressToProgressDialog(const int current,
const int maximum)
Revised:
* (int)TLuaInterpreter::loadMap( lua_State * )
* Moved XML map download code from dlgMapper class to the TMap one:
+ (void) dlgMapper::downloadMap() ==>
(bool) TMap::downloadMap(const QString * remoteUrl,
const QString * localFileName)
+ (void) dlgMapper::setDownloadProgress(qint64, qint64) ==>
(void) TMap::slot_setDownloadProgress(qint64,qint64)
+ (void) dlgMapper::cancel() ==> (void) TMap::slot_downloadCancel()
+ (void) dlgMapper::replyFinished(QNetworkReply *) ==>
(void) TMap::slot_replyFinished(QNetworkReply *)
Renamed:
* (void) XMLimport::readAreaNames() ==> XMLimport::readArea() - for
consistency with related functions
Commented out unused:
* (void) XMLimport::readUnknownRoomElement()
* (void) TMap::getConnectedNodesGreaterThanX(int, int)
* (void) TMap::getConnectedNodesSmallerThanX(int, int)
* (void) TMap::getConnectedNodesGreaterThanY(int, int)
* (void) TMap::getConnectedNodesSmallerThanY(int, int)
* (void) TMap::astBreitenAnpassung(int, int)
* (void) TMap::astHoehenAnpassung(int, int)
* (void) TMap::exportMapToDatabase()
* (void) TMap::importMapFromDatabase()
* (QVector3D) TMap::span
* (int) TMap::mViewArea
* (QMap<QString, int>) TMap::pixNameTable
* (QMap<int, QPixmap>) TMap::pixTable
* (bool) TMap::isToDisplayAuditErrorsToConsole
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Enhancement: move TArea::rooms to QSet (updated)
In the absence of @vadi2 I will take the step of merging this in - with the belief that I have addressed the main issue raise in his "OK, need to think on this then..." last comment.
As the amount of messages produced by the new/improve map auditing/clean-up
code can be large for old map files this commit causes them to be sent to
a profile specific file that is already opened by the Host class but has
not been used for some time. An option (a check-box) on the "map" tab of
the "profile preferences" dialog controls whether the equivalent
information is also shown on the profile's main console as in the past.
If the option (a global one) which is saved between sessions/runs is NOT
enabled then an advisory is sent to the console advising the user to review
the file contents if a "significant" issue was detected. If it is enabled
a similar message advising that the information has also been saved. In
either case, as the file is appended to, and not rewritten each time, the
message includes details of the first line of the report so that it can
be located in the file. One difference between the on-screen and the file
versions of the information is that the former puts up the issues as they
are detected whereas the latter groups the information by subject, first
the general overall issues, then the area ones, in order of the areas' id
numbers and then the room ones, in room order.
Following earlier discussions in these Pull Request I have attempted to
edit all uses of the word "Id" in user visible places to be "id" instead.
This threw up some other messages with issues in several files that I have
tweaked here as well!
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
As the amount of messages produced by the new/improve map auditing/clean-up
code can be large for old map files this commit causes them to be sent to
a profile specific file that is already opened by the Host class but has
not been used for some time. An option (a check-box) on the "map" tab of
the "profile preferences" dialog controls whether the equivalent
information is also shown on the profile's main console as in the past.
If the option (a global one) which is saved between sessions/runs is NOT
enabled then an advisory is sent to the console advising the user to review
the file contents if a "significant" issue was detected. If it is enabled
a similar message advising that the information has also been saved. In
either case, as the file is appended to, and not rewritten each time, the
message includes details of the first line of the report so that it can
be located in the file. One difference between the on-screen and the file
versions of the information is that the former puts up the issues as they
are detected whereas the latter groups the information by subject, first
the general overall issues, then the area ones, in order of the areas' id
numbers and then the room ones, in room order.
Following earlier discussions in these Pull Request I have attempted to
edit all uses of the word "Id" in user visible places to be "id" instead.
This threw up some other messages with issues in several files that I have
tweaked here as well!
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>
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>
Although we have the provision of a default area (with Id -1) we have not
previously actually made sure it exists after loading (or clearing) prior
to loading in a map - which causes all sorts of error messages when a map
WITHOUT that area is loaded.
This will possible need checking with a planned revision to code to allow
user loading of XML map files in the near future.
Also:
* moved all instance in TMap class of mpHost->postMessage( QString ) to own
postMessage( QString ) implimentation
* removed unused QDataStream reference argument in:
* (void) TRoomDB::restoreSingleArea( QDataStream &, int, TArea * )
* (void) TRoomDB::restoreSingleRoom( QDataStream &, int, TRoom * )
* removed unused Globals in XMLimport.cpp:
* int maxAreas
* QMap<int,int> areaMap
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Although we have the provision of a default area (with Id -1) we have not
previously actually made sure it exists after loading (or clearing) prior
to loading in a map - which causes all sorts of error messages when a map
WITHOUT that area is loaded.
This will possible need checking with a planned revision to code to allow
user loading of XML map files in the near future.
Also:
* moved all instance in TMap class of mpHost->postMessage( QString ) to own
postMessage( QString ) implimentation
* removed unused QDataStream reference argument in:
* (void) TRoomDB::restoreSingleArea( QDataStream &, int, TArea * )
* (void) TRoomDB::restoreSingleRoom( QDataStream &, int, TRoom * )
* removed unused Globals in XMLimport.cpp:
* int maxAreas
* QMap<int,int> areaMap
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>
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>
In situations when we check whether a room in an area both for internal
purposes and when rooms on a mapper is selected, using QSet instead of a
QList is faster in performance for large numbers of entries in set.
As it reworks the mapper code it also fixes issue where the multi-room
selection widget overwrites map info display - the latter is re-sized and
re-positioned (and regains a semi-transparent background which helped to
show this working during debugging!) The former is now: dynamically
resized to only take up enough vertical space to show the selected rooms;
also displays the associate room names if there are any, expanding the
widget as required; sorts the display either by room name or number and in
either direction.
The mouse wheel handler is modified so that using the scroll wheel ONLY
scrolls the list within the widget - previously (by default) once the end
in either direction was hit the related events would be passed up the
widget chain where it would otherwise invoke the 2D mapper's zoom in/out
code.
In modifying the zoom in/out code I have replaced the (obsoleted in Qt5.x)
QWheelEvent::delta() method to use the QWheelEvent::angleDelta() method,
using only the Y-component the latter provides. If the Control modifier is
active the zoom value is modified by an extra x10 factor which is useful
when working with large maps as otherwise the zooming rate is "slow" at
high values - ideally the control should be logarithmic or exponential or
some other "non-linear" algorithm to work more uniformly over the range of
practical use cases.
The code to paint the map info text has been revised also to use the
mMapInfoRect which was being defined but NOT used.
The info text now reports whether the room name is for the player room
{set via the Lua command centerview(roomId)} or is one that is selected
by mouse dragging - and if more than one room is selected by that indicates
the count of rooms in the selection. In the case of multiple rooms being
selected the room that single room context menu operations will act upon
is highlighted by the same style of yellow target used to show the custom
exit line destination but is drawn in a different point in the code so that
it is drawn over the rooms.
Because of the change to the way that multiple rooms are selected routines
that use that information had to be revised - in doing so it was possible
to improve the usability/operation of:
T2DMap::slot_movePosition()
T2DMap::slot_setCharacter()
T2DMap::slot_spread()
T2DMap::slot_shrink()
T2DMap::slot_lockRoom():
T2DMap::slot_unlockRoom():
This method, also resurrected here to the 2D mapper context menu, as it is
also affected by the changes:
T2DMap::slot_setPlayerLocation()
There was a slot_setPlayerLocation code that set a global lua variable
mRoomSet and moved the player to that room Id (introduced in
commit-c25faf4e 2012-05-04 07:44:36 by Heiko) but the corresponding 2D
Mapper context menu item that called it was commented out and thus removed
from the menu in commit-93f65962 2012-12-29 01:16:28 also by Heiko without
any explaination. Since that has not been used since then I have replaced
it with a new Event: sysManualLocationSetEvent with a single numeric value
which is the new (valid) room Id number - user scripts can capture this
event if they want to know that the user has manually re-positioned the
current player room in the 2D mapper.
In passing:
* Fixed Text font changing between docked and un-docked forms of the
built-in map widget (when not incorporated into a console) - as it was
not previously explicitly set it assumed the Application one whilst
docked but the Qt System one when a free floating widget - and the two
do not have to be the same. This fixes:
https://bugs.launchpad.net/mudlet/+bug/1432841 .
* Starts to fix https://bugs.launchpad.net/mudlet/+bug/1376511 by changing
from use of obsolete QWheelEvent::delta() to QWheelEvent::angleDelta() in
T2DMap::wheelEvent(...); will need duplicating in
TTextEdit::wheelEvent(...) and GLWidget::wheelEvent(...) .
* Adds the profile name to the Mapper dockable widget so that it's
parentage can be determined when multiple profiles are active.
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
About to start a real session of MUD playing I noted that there is no quick
way to assign ranges of room numbers when mapping out areas - it is useful
to some map-makers to group ranges of numbers to areas. Since we do not
provide an implicit ways to renumber rooms (have to create new instance and
copy data across in a script) I think some would find it useful to be able
to supply a starting room number to the Lua command createRoomID and for
that to return the next available number past that.
{This will be familiar to a TinTin++ MUD Client user which behaves in the
same manner as I propose here - IIRC!}
The Lua createRoomID() has been updated (to current code/message
guidelines) - it will return a nil AND an error message instead of a
number if the optionally supplied first argument is less than 1. Otherwise
it behaves as before - new scripts written to take advantage of this
functionality may wish to check the returned number IS greater than the
specified value if they need to guarantee the result and provide fall-back
functionality with prior versions of the application {start iterating
through room Ids with getRoom( roomId ) to find first non-existent room} -
as in that case the supplied argument will be ignored and just the lowest
free positive number will be returned as for previous versions.
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
About to start a real session of MUD playing I noted that there is no quick
way to assign ranges of room numbers when mapping out areas - it is useful
to some map-makers to group ranges of numbers to areas. Since we do not
provide an implicit ways to renumber rooms (have to create new instance and
copy data across in a script) I think some would find it useful to be able
to supply a starting room number to the Lua command createRoomID and for
that to return the next available number past that.
{This will be familiar to a TinTin++ MUD Client user which behaves in the
same manner as I propose here - IIRC!}
The Lua createRoomID() has been updated (to current code/message
guidelines) - it will return a nil AND an error message instead of a
number if the optionally supplied first argument is less than 1. Otherwise
it behaves as before - new scripts written to take advantage of this
functionality may wish to check the returned number IS greater than the
specified value if they need to guarantee the result and provide fall-back
functionality with prior versions of the application {start iterating
through room Ids with getRoom( roomId ) to find first non-existent room} -
as in that case the supplied argument will be ignored and just the lowest
free positive number will be returned as for previous versions.
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>
