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 _______________________________________________ Mailing list: https://launchpad.net/~mudlet-makers Post to : [email protected] Unsubscribe : https://launchpad.net/~mudlet-makers More help : https://help.launchpad.net/ListHelp
