Menu

#4 NWNUpdater: Optional Human readable log file

NWNAutoUpdater
open
None
5
2004-03-06
2004-01-04
Rick Shafer
No

It seems that the update/installation process is fragile,
probably as much by design choices of Bioware, rather than
something inherent to the NWNUpdater design.

As an *option*, it would be nice if the user could create a
log file detailing what the updater is doing (or not doing),
including issues of:
Identifying what update/expansion resources are in the
appropriate locations.
Which resources are being unpacked and where they are
being put.

For example there is this message in the BW forums
http://nwn.bioware.com/forums/viewtopic.html?
topic=281853&forum=71&sp=74
which I think is a diolog.tlk problem. It would be nice to
diagnose that the updater was actually moving a dialog.tlk
from the HotU installation CD (or thought it was) and then to
move on from there.

Basicly, the information that flashes by in the bottom of the
window should be *optionally* echoed to that log file.

Discussion

  • Josephan

    Josephan - 2004-03-02

    Logged In: YES
    user_id=988529

    I would like to add my vote for the inclusion of this feature!

     
  • Sumpfork

    Sumpfork - 2004-03-06
    • milestone: --> NWNAutoUpdater
    • assigned_to: nobody --> quatermain
     
  • Jim Dovey

    Jim Dovey - 2004-03-08

    Logged In: YES
    user_id=824124

    This can be done - it does, in fact, produce a plist-based manifest of all
    installed files, which is used for rollback support in the 1.0 codebase. I
    could do one of two things here:

    1) After installation, write out (or display w/save button) a lst of all files
    installed.

    2) Have a running 'log window' like the Installer application. Shouldn't be
    too hard, either (easy enough to create an outline view based around
    text strings, after all).

    The first option would be the easiest - as mentioned above, an installed
    file list (and a more detailed 'action list' - move, delete, install) are
    automatically generated inside each Unpacker object, and the rollback
    mechanism uses the installed file list to store a list of all files to remove
    before rolling back.

    The second option would require some manner of getting the Unpackers
    (or maybe the update/install operations) to post information to some
    central object, which would collate & display the logfile accordingly. This
    would require more rewriting, but would probably be the best approach.

    As for the HoU install - as the dialog.tlk thing should be remedied now.
    The 1.0 version of the updater has a bit more knowledge of the
    heirarchies of individual files - for instance, that the dialog.tlk from hotu
    supercedes all others, etc. So if you install an expansion pack whilst
    already having a more recent expansion pack installed, it will just skip
    over installing certain files (such as dialog.tlk).

    Thoughts, comments?

    -Q

     

Log in to post a comment.