mudlet-makers team mailing list archive

[Stephen Lyons <slysven@xxxxxxxxxxxxxxx>]

This issue has been address in commit-
94dd41bfb7ab203565c9397717d04eb22dc9810c (in Development branch) and
commit-1e60d82063019ae6243d75855375cd6f6bf139c4 (in release-30 branch)
these do require Mudlet Map Format 18 to be used to save the Map data in
(default for release 2.1 is 16) and it gathers the player room from all
profiles for which the map is to be copied - either by parsing the last
saved map for the given profile or, if currently active, by inter-
profile means - the same file is then saved and sent to all the profiles
concerned and a request is sent to the "other" active ones that
initiates a reload of the new map file.  The UI has been revised to
allow all the profiles to receive/share the exact same map with which
will address the issues of sharing it locally for the same user with
multiple profiles for the same MUD....

** Changed in: mudlet
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Mudlet
Makers, which is subscribed to Mudlet.
https://bugs.launchpad.net/bugs/1523645

Title:
  "Copy map to another profile" does not respect player room in
  destination

Status in Mudlet:
  Fix Committed

Bug description:
  The code in place for this function in the "profile preference"
  dialogue saves the map in the currently "active" profile before making
  a verbatim copy of that file to the specified target profile.
  Unfortunately this will obviously replace the saved "player-location"
  normally held in TMap::mRoomId in the destination profile with that of
  the source, which may confuse things the next time the destination
  profile is used.  I have not researched what the effects will be (if
  any) if the other profile is actually active (e.g. in a "multi-
  playing" set-up).

  There is not a fool-proof fix for this - in an, admittedly extreme,
  corner case the source map could theoretically have deleted the
  player-room for the destination - a work around to read the map but
  replace that one data item in the destination copy with the old value
  from the replaced map assumes that they are the same in the room where
  the character in the destination profile is - which need not be the
  case.

  I think this is a "Won't fix" bug - simply because there is no
  universal fix.  However I think it needs to be noted in the
  "Documentation" somehow - and for (I guess the small subset of) people
  who do "multi-play" they will need to be advised to always re-
  establish the character location in the destination copy immediately
  after "cloning" the map from one profile to a another.  In principle,
  in the absence of a lua command to duplicate the "Copy map to another
  profile" button,  I suppose they would have a "master"
  profile/character that they would use to edit their map when map-
  making and have lua scripts to "save" that map, then copy it across
  and then reset the "slave" profile/character.  On further
  investigation that will be harder than it needs be because the lua
  savemap() command does not return the actual filename used - which,
  when supplied with an empty string argument to cause a (date-stamp
  named) map save in the default profile location - must be awkward for
  users...!

  Possible ToDos :
  * provide a lua script equivalent to "Copy map to another profile" button on profile preferences
  * revise lua saveMap() to report the filename actually used

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1523645/+subscriptions