[Request] Support reparsing of MPF-processed outputs #831

New Issue

claunia · 2026-01-29T16:22:58Z

claunia commented

2026-01-29 16:22:58 +00:00

Originally created by @mnadareski on GitHub (May 5, 2025).

Originally assigned to: @mnadareski, @Deterous on GitHub.

There are some cases where MPF-processed outputs need to be reparsed. Instead of relying on uncompressed outputs in those cases, support the case where a log archive is there instead. Created from discussion on https://github.com/SabreTools/MPF/issues/816

Two possible paths to handling this:

If the log archive exists, decompress it to a temporary path and use that temporary path along with the existing path to get the information. Alternatively, decompress to the same folder and pretend that it was all that way to begin with. This approach has the advantage of minimal amounts of changes to the existing code, including reading all required logs. It has a disadvantage of potentially overwriting existing files in the folder in some edge cases.
Retool the existing code to support reading from streams instead of file paths. This has the advantage of being more flexible across the board so that any stream can be used to get information from. The major downside is the sheer amount of work required to ensure that all of the required methods can use a stream instead.

Originally created by @mnadareski on GitHub (May 5, 2025). Originally assigned to: @mnadareski, @Deterous on GitHub. There are some cases where MPF-processed outputs need to be reparsed. Instead of relying on uncompressed outputs in those cases, support the case where a log archive is there instead. Created from discussion on https://github.com/SabreTools/MPF/issues/816 Two possible paths to handling this: - If the log archive exists, decompress it to a temporary path and use that temporary path along with the existing path to get the information. Alternatively, decompress to the same folder and pretend that it was all that way to begin with. This approach has the advantage of minimal amounts of changes to the existing code, including reading all required logs. It has a disadvantage of potentially overwriting existing files in the folder in some edge cases. - Retool the existing code to support reading from streams instead of file paths. This has the advantage of being more flexible across the board so that any stream can be used to get information from. The major downside is the sheer amount of work required to ensure that all of the required methods can use a stream instead.

claunia added the enhancement label 2026-01-29 16:22:58 +00:00

claunia closed this issue

2026-01-29 16:22:58 +00:00

claunia commented

2026-01-29 16:22:59 +00:00

@Deterous commented on GitHub (Oct 8, 2025):

Since b238616685 the zip does not get overwritten. By extracting all files that match GetOutputFiles from a found log zip, this should just work, leaving the original one untouched and having a new and complete 2nd log zip.

@Deterous commented on GitHub (Oct 8, 2025): Since b238616685cd0663b4981e07168f74626005460e the zip does not get overwritten. By extracting all files that match GetOutputFiles from a found log zip, this should *just work*, leaving the original one untouched and having a new and complete 2nd log zip.

claunia referenced this issue

2026-01-29 16:25:54 +00:00

[PR #835] Update redumper to build 549 #1185

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: SabreTools/MPF#831