Hi - I'm a long time user of WoL. Love the site but I've always been very annoyed by a missing feature in the client. It's very good about splitting and zipping and archiving logs, but it really needs a feature to read a zipped log file back in. Please please please add a feature to open a zip file and parse the log file within. I know the library support exists in Java, this should be a very easy feature to implement..
Added this to our feature requests; it does make sense to implement. Can't promise anything on a timeline, however, as we're fairly busy right now. Especially so with the recent patch.
Still really really wanting this feature..
These days the client often runs out of memory and gets "stuck" parsing more than a couple nights of raid, so often end up having to split before uploading. Really want the client to read those post-split archives directly rather than forcing me to manually unzip them again.
I've just looked at this, but sadly it's not that easy to implement. With how the client is written, we need the combat log to be an actual file, not a ZIP entry. This means we'd need to extract it before parsing. I could allocate a temp file, extract to it, then parse, but due to how we handle error states I can't guarantee that these temp files are deleted when the client crashes. Will think on the issue a bit more.
Hi and thanks for looking into this possible feature upgrade. As noted in my previous posts this is something I've desperately wanted for a long time.
I obviously know nothing about the internal architecture of your client. However based on my knowledge of Java, shouldn't it just be as easy as instantiating java.util.zip.ZipInputStream, casting it to a java.io.FilterInputStream, and then passing it to the code that reads file data? (ie allowing the "unzipping" to happen transparently and on-the-fly inside the abstraction) If necessary you could even wrap that in a PushbackInputStream or BufferedInputStream as required. The only reason I can think of this approach might fail is if your file reading code uses java.nio or something freakier.
I guess if somehow that approach won't work, then using a temporary file created using java.io.File.createTempFile() would be almost as good - slightly less efficient that on-the-fly decompression, but still MUCH faster and better than forcing the user to do this process manually. I think the JRE does a pretty good job of cleaning up those temp files even if your app crashes with a fatal exception, and at worst it's easy to reap the temp next time the user cleans his temp directory. In any case the temp file is far more likely to be automatically reclaimed by Java than when I have to unzip manually and then forget to go manually delete the manually-created temp files when I'm done.
It would be that easy if we exclusively used the stream-based I/O APIs. However, the client uses java.nio internally in the current implementation.
I had looked into File.createTempFile(), but this doesn't get removed when the VM exits abnormally, e.g. when an exception is thrown. I'm thinking of using a temp file in a static location that gets removed any time the client starts (in case it hasn't been removed after it was last created).
Maihem wrote: It would be that easy if we exclusively used the stream-based I/O APIs. However, the client uses java.nio internally in the current implementation.
Maihem wrote: I had looked into File.createTempFile(), but this doesn't get removed when the VM exits abnormally, e.g. when an exception is thrown. I'm thinking of using a temp file in a static location that gets removed any time the client starts (in case it hasn't been removed after it was last created).
Either option would be a vast improvement over the current behavior. And of course users are still free to continue managing their own decompression manually if they're really worried about the small chance of a leaked temp file.
I know this is an old post, but I'd love to see this option! Couldn't the program just always extract to the same temp file name so that is was always overwritten? Or set a flag so the program knows its uploading from a zip and ask if user wants to delete temp file upon upload as per the asking if it wants to split and zip?