You use the character “” (unicode 0x27A1 or ➡) in some places in your Report Action traits. Perhaps that could be the culprit? You could consider to replace it with the more regular HTML entity → which gives “→”.
Also, perhaps you can get your opponent to also post the relevant parts of the errorLog to the thread. There should be something in there, that says more about why, Vassal believes the file not to be valid .vlog file.
I also tried a selection of the above posted log files and saw no problems (I’m on Debian GNU/Linux “sid” with Java 27-ea).
There have been so many problems various users have had with modules and associated files that ended up stemming from usage of services like OneDrive that actively sync files between a user’s local machine and the cloud that I immediately react to seeing its mention in an errorlog.
Could it be that the logfile he intends to load is being locked by OneDrive as part of its sync activities and rendered unable to load correctly by the module (which itself is synced to OneDrive)?
I would be interested to see this user attempt to store both this module and all associated logfiles in a location on his system that is not being touched by OneDrive.
In that case, I think the next step is for you to make available the file that you can’t open. (The reason I emphasize you here is that I suspect it is not identical to the one we received from @paveuf1.)
Perhaps not only the .vlog you cannot open, but also the .vmod so that everything may be compared. Also, please put errorLog file content pastes between two ``` so that they are easier to read.
BTW, it seems like you moved the files to the E: drive - is that a removable drive? When you moved the logs, did you move them from the OneDrive location to E:?
Also try, perhaps, to double-click the .vlog file directly in the File Browser, and see if the errorLog gives more information in that case.
Also, check if you OneDrive isn’t almost at capacity - so that the troublesome .vlog may not have been written in full. Perhaps take the logs posted by @paveuf1 (via @uckelman) above and see if you can load those?
The two version of pave v bb invin 1.7 17.vlog differ in size:
> du -b pave\ v\ bb\ invin\ v1.7\ 17.vlog*
316367 pave v bb invin v1.7 17.vlog
304394 pave v bb invin v1.7 17.vlog.panzer1963
(du -b shows the size in bytes).
Above, the top file is what @paveuf1 uploaded to dropbox, and the bottom file is what @Panzer1963 made available. As you can see, the file from @Panzer1963 is 11973 bytes - or almost 12kb - smaller than what @paveuf1 provided.
When I try to load pave v bb invin v1.7 17.vlog.panzer1963, then I also see the error that it is not a valid file.
It seems plausible to me that OneDrive - possibly because your quota is almost spent - has cut off part of the file.
Try to take the same file as provided by @paveuf1 and load that. As far as I can tell, that should work. If it does, then that resolves the issue. Please remember to close the issue.
If you want to avoid this kind of error in the future, then you could exchange checksums of the log files you exchange:
Yeah. Since logfiles and saved games (just like modules) are merely renamed ZIP archives, I tried unzipping the file and got:
Archive: pave v bb invin v1.7 17.vlog error [pave v bb invin v1.7 17.vlog]: missing 11973 bytes in zipfile (attempting to process anyway) error [pave v bb invin v1.7 17.vlog]: attempt to seek before beginning of zipfile (please check that you have transferred or created the zipfile in the appropriate BINARY mode and that you have compiled UnZip properly) (attempting to re-compensate) inflating: savedGame bad CRC 58a02c3e (should be 4ccaa095) file #2: bad zipfile offset (lseek): 311296 file #3: bad zipfile offset (EOF): 315885
You guys are good. If you should ever find yourself near Reidsville, NC 1st round is on me. I’ll likely remember this should it recur with another opponent. M A H A L O
Sounds good - don’t think that’s gonna happen anytime soon though - but take one for me.
I take it that you consider the issue solved? If so, please consider to mark is as resolved by flagging the appropriate post. That helps others find the solution to their problems.
BTW, if you are using Windows, then the command sha256sum isn’t necessarily available to you. In that case you can use certutil to generate a checksum
Open a command prompt (Windows key + R and type cmd)
Navigate to the file you want to make the checksum for - e.g.,
$ cd C:\Users\Username\Documents\Vassal\LogFiles
Generate the checksum - e.g.,
$ certutil -hashfile "My latest log.vlog" SHA256
This will print out the checksum. Copy that from the terminal into the email you send your opponent with the log file (or URL to it, or whatever).
Make sure you do the above on a local file - not one stored on OneDrive or similar - no way of knowing if OneDrive f**ks things up.
Your opponent then does the same thing and compares the checksum you provided with the checksum reported in step 3 above, as done on the opponents computer. If the checksums are the same, then all should be good. If they are not, then something went wrong during the transfer of the log file.
I thought about that too, but as the case in point illustrates, it would not be sufficient in all cases. As @JoelCFC25 illustrated above, the ZIP archive it self was corrupted, and you couldn’t even extract the savedata file from the archive.
If the checksum of saveData was stored in the savedata file, one would be able to check that the saveData was written correctly to the archive. However, the Java ZIP library already does that, so in that sense, the check would be moot.
Also, if the corruption happens during the transfer from A to B, then it is likely that the ZIP archive would be corrupted (and which member of the archive that hurts is non necessarily known). Thus, it makes sense to be able to verify the ZIP archive itself, rather than the individual elements of the archive (which are already checked by the Java ZIP library).
What could be stored would be the checksum of the module. In that way, VASSAL could check if the save file actually is used with the right module.
Thanks a bunch y’all. Just had another player come back with same error on a game we had put on hiatus for several months. Awaiting his feedback as to whether one drive may be involved. I’ll put this topic to rest as I think we’ve found the smoking gun. Mahalo. pave
” (unicode 
- but take one for me.