Yes, but many people aren't in power to fix that, and those that are will
probably be on the lookout for such detail.

On Sun, Oct 16, 2016 at 8:30 AM Stephen Lyons <>

> Well, is it possible that Mudlet modifying the map file to change
> existing area names so that they are not blank or repeated; or adding a
> new area that involves an area id we have warned users not to mess with
> (IIRC) might not influence packages that they have in use?
> If such things operate by area id, then no that is not likely to be a
> problem - but if by area name, maybe, though duplicate names will cause
> scripts issues if they key lua tables off those...!
> ** Changed in: mudlet
>        Status: New => Confirmed
> --
> You received this bug notification because you are a member of Mudlet
> Makers, which is subscribed to Mudlet.
> Title:
>   Map issues still reported to screen with 'report map issues to screen'
>   turned off
> Status in Mudlet:
>   Confirmed
> Bug description:
>   Even though the I have the 'report map issues to screen' checkbox
>   turned off when selecting and loading in a map, 20+ lines related to
>   map issues are still printed to the screen:
>   [ INFO ]  - Reading map (format version:16) file:
>               "/home/vadi/Dropbox/MMC/mapping/Sidd Map 1-25-15.dat",
>               please wait...
>   [ ALERT ] - Empty and duplicate area names detected in Map file!
>   [ INFO ]  - Due to some situations not being checked in the past,
> Mudlet had
>               allowed the map to have more than one area with the same or
> no name.
>               These make some things confusing and are now disallowed.
>                 To resolve these cases, an area without a name here (or
> created in
>               the future) will automatically be assigned the name "Unnamed
> Area".
>                 Duplicated area names will cause all but the first
> encountered one
>               to gain a "_###" style suffix where each "###" is an
> increasing
>               number; you may wish to change these, perhaps by replacing
> them with
>               a "(sub-area name)" but it is entirely up to you how you do
> this,
>               other then you will not be able to set one area's name to
> that of
>               another that exists at the time.
>                 If there were more than one area without a name then all
> but the
>               first will also gain a suffix in this manner.
>   [  OK  ]  - The changes made are:
>               (ID) "old name" ==> "new name"
>               (0) "<nothing>" ==> "Unnamed Area"
>   [ INFO ]  - Default (reset) area name (for rooms that have not been
> assigned to an
>               area) not found, adding "Default Area" against the reserved
> -1 id.
>   I think none of this should show, it should just go into the
>   errors.txt unless you have that checkbox enabled (and the checkbox to
>   fully do what it claims to say!).
> To manage notifications about this bug go to:
> _______________________________________________
> Mailing list:
> Post to     :
> Unsubscribe :
> More help   :
Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to