mudlet-makers team mailing list archive

[Stephen Lyons <slysven@xxxxxxxxxxxxxxx>]

Ah, by tweaking the map file format, by converting int TMap::mRoomId to
a QMap<QString, int> TMap::mRoomIdMap and writing a method to scan a
different profile's (the destination profile for a cross-profile sync)
data I have got prototype code that reads and stores in the source
profile's copy the (possibly updated) destination profile's mRoomIdMap
entry as well as it's own which means that - provided the room hasn't
been deleted all profiles can keep their user in the room they were in
BEFORE the map was copied over...

I have just had a thought - that I need to review/document the code's
behaviour if a copy is to go to more than ONE other profile... the
current interface won't work for triple or higher multi-playing without
possible issues without further work.

-- 
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:
  In Progress

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