Update from Stephen: In passing I have had some joy in improving package installation as mentioned in bug 1413069 - it seems that not all archive production programs follow the step of including a zip archive entry (of zero file size) with a name ending in '/' to indicate a (sub)directory in the archive - I have successfully overcome that problem by scanning through all the entries looking both for those entries and for filenames containing '/' in places other than the first or last character. After creating any destination paths needed for those sub-directories I have then been able to extract all the contents required on a second pass. I only found out about this happening when I had put error messages (using Host::mTelnet.postMessage) up on the main console, so I do have a fix for this but it needs further work to put in error handling all the way through the file handling stuff in all of Host's methods and other relevant classes....
-- You received this bug notification because you are a member of Mudlet Makers, which is subscribed to Mudlet. https://bugs.launchpad.net/bugs/1413069 Title: unpacking mpackages stalls Status in Mudlet the MUD client: Confirmed Bug description: In Mudlet 3.0 preview D, adding a mpackage on windows stalls. It just sits there saying 'unpacking...' The easiest way to test is to just try to connect to GodWars 2 from the main GUI. It'll download a package and then just sit there. However, I also ran into the problem when downloading a .mpackage from the forum, it just doesn't seem to unpack anything at all. There's no error messages in the debug console. To manage notifications about this bug go to: https://bugs.launchpad.net/mudlet/+bug/1413069/+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
