I created a tutorial for my game using a vlog. Is it possible to edit the comments (blue color) ?
No, not possible in the way you want.
What I would do. Open a new file in a text editor.
Start running the vlog.
Select a line of blue text. Copy and paste to the text file.
Continue doing this for the entire vlog.
Edit my text file to my choosing.
Run module. Create a new vlog. Copy lines from the text file to the vlog when appropriate.
I hate to sound like a broken record, but it is possible - albeit not for the faint of heart. Again, this depends on using my Python package pywargame.
First, a little info - a VLOG is just a ZIP archive with some data files in it. Specifically
moduledata- an XML file which is more or less a copy of the same file in the module
savedata- another XML with meta data on the save (date, VASSAL version, description)
savedGame- an encrypted text file which actually contains the save (or log).
Suppose now you have the tutorial in
Tutorial.vlog. Then you could do
from vassal import SaveIO key, lines = SaveIO.readSave('Tutorial.vlog')
key will contain the “secret” key used to encrypt the file, and
lines every line of
Tutorial.vlog. You can print the content of the file with
for l in lines: print(l)
Of course, you could output the entire file to disk in human readable form with
with open('Tutorial.txt','w') as output: output.writelines([l+'\n' for l in lines])
Then, you could edit the file in your favorite text editor. Chat messages written by you will be lines starting with
Other lines a various events written in the log (moving pieces, changing state of pieces, and so on).
To recreate the log file, you would then first read in the original module and save meta data
from zipfile import ZipFile, ZIP_DEFLATED with ZipFile('Tutorial.vlog','r') as orig: moduledata = orig.read('moduledata') savedata = orig.read('savedata')
With this in place, we turn to read back in your modified
with open('Tutorial.txt','r') as mod: lines = [l.strip('\n') for l in mod.readlines()]
Now lines contains your modified
savedGame. We can write all this data to a new log file, say
from vassal import SaveIO key = 123 # In the range 0 to 255 - 2 bytes. SaveIO.writeSave('Tutorial.new',key,lines.savedata,moduledata)
key is the new “secret” key of the VLOG.
Now, this technique could be used to tamper with VLOGs exchanged as a part of a PBEM game, but one is really only cheating one self of a challenge and good time if one cheats in a game.
Rest mainly for the curious and possibly interested parties:
Of course, it also points out the relatively low security of VLOG files. An alternative would be that
when Player A sends VLOG 1 to Player B, then when Player B receives VLOG 1, Player B calculates the check sum on VLOG 1,
Player B> md5sum 1.vlog > 1.md5sum
and sends it back to player A to verify that the right VLOG has been received
Player A> md5sum -c 1.md5sum
Then player B starts a new VLOG (2) from the end of VLOG 1 (i.e., does not append to VLOG 1), and when player B is done, sends VLOG 2 to player A, which responds with the check sum of the received VLOG 2,
Player A> md5sum 2.vlog > 2.md5sum
ships the checksum back to player B for verification
Player B> md5sum -c 2.md5sum
and so on. Then, both parties can ensure that
all VLOGs are the same by comparing check sums
First concatenate check sum files
Player A> cat *.md5sum > md5sums
md5sumsto player B, which then checks that all VLOG files are the same
Player B> md5sum -c md5sums
Thus of Player A has a VLOG - say
10.vlogwhich is different then what player B has, it will be immediately obvious to player B, since check of player A’s
10.vlogdoes not match the checksum of player B’s
since all VLOGs are differences to the previous VLOG, it will be obvious when loading a VLOG if the starting conditions were tampered with.
The point is that encryption doesn’t really help in this case. Proper encryption is done via public/private key pairs (VLOGs embed the private key directly in the data to be transmitted).
- Player A shared its public key with Player B.
- Player B encodes a VLOG with the public key of Player A.
- Now only player A can open the encrypted VLOG.
To utilise this kind of encryption, what would need to happen would be a bit convoluted.
- Player A encodes a VLOG with Player A’s public key and sends that to Player B.
- Player B cannot decrypt the file as Player B does not have Player A’s private key.
- So Player A would have to open the VLOG for Player B, which essentially means transferring Player A’s private key to Player B, thus compromising Player A’s private key.
Encryption works to send information to someone so that a third party can not intervene. It does not ensure that your recipient cannot change the information send.
The way DRM systems try to manage this is typically by embedding the private key into the software- sometimes hardware - in a way that is not (immediately) readable by the end user - but that in principle (qnd practise) exposes the private key to the recipient (though it may take some cracking to find it).
I think the point here is not to try to prevent players from tampering VLOGs, but rather create a transparent audit trail - as would be the case with check sums - so that players may go back and find out exactly where things started to diverge.
Any case, my 2 ¢ - and I may well have overlooked something.