mudlet-makers team mailing list archive

[Vadim Peretokin <vperetokin@xxxxxxxxx>]

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