Bug #141

Problem saving/loading characters

Added by Francisco Del Roio 7 months ago. Updated 7 months ago.

% Done:


Contact person:
Additional contact persons:



There is a problem in the Safe class that raises errors when loading a world with characters, prevempting the client to be started.

I found that the problem initially is with the passphrase file, but when I solved this I found some problems regarding encrypting and decrypting with unexpected results.

Currently I am investigating the pyaes library to solve this myself.

Anyway, can you give me directions on this?


Associated revisions

Revision 659cf1e0 (diff) View on GitHub
Added by Francisco Del Roio 7 months ago

Fixed some issues with `Safe` class when storing/retrieving data.

This fixes the bug #141 and character creating/loading issues.


#1 Updated by Francisco Del Roio 7 months ago

  • Checklist item deleted (Add a tet for the Safe class.)
  • Checklist item Add a test for the 'Safe' class. added
  • Tracker changed from Feature to Bug

#2 Updated by Vincent Le Goff 7 months ago

It's strange, I don't have this issue and I have several characters that are already created. Does it happen when new characters are added though?

The Safe class is meant to be a simple wrapper around something rather complex: encryption. We used other libraries before, but some of these libraries haven't updated to Python 3 yet, so I decided to find something else. pyaes is the new find. As far as I can tell, it works perfectly well with characters created before this version: I can open a word, select this character, and the username, password and other commands are read from the encrypted file with no problem. It's unfortunately possible I didn't test creating new characters with encryption, though I believe I did.

Likely culprits in this case: the str/unicode issue is one we have most problems with in this version, handling Python 2 to Python 3 support. So I would first check for the proper str types to be used: in Python 3, the rule is pretty straightforward: everything should be a str, except if it's in early input or late output (as it is, when writing to a file). The Safe class can manage raw bytes, it writes into files after all.

Another option is the fact that old characters work fine, but perhaps new ones don't: perhaps this issue regards a particular method which is called only for new characters?

BTW, a unittest on the Safe class is a very good idea. We don't have enough unittests as is and we could use many, many more, even if testing the UI itself is a bit difficult.

#3 Updated by Francisco Del Roio 7 months ago

I've found that the problem is on retrieve function when checking if the decrypted value is an str, and that condition never occurs because all strings returned at this moment are always bytes arrays or anithing other.

The way around I've tested is to save a tuple with a "str" value as the first item and the value as the second ones and it worked well.

#4 Updated by Francisco Del Roio 7 months ago

  • Checklist item Add a test for the 'Safe' class. set to Done

I think that it is solved.

#5 Updated by Vincent Le Goff 7 months ago

I will test it in a few minutes. The tricky part, of course, is that it has to keep on working with older versions, so that information of characters created before the change aren't lost. But I have a few to test, we'll see how it works. Thanks for debugging and for the PR!

#6 Updated by Vincent Le Goff 7 months ago

  • Sprint/Milestone set to 16

I brought a fix in commit 58dd663a6c5a289acda6b3431bca82527ffd74b9. Storing as a tuple was a valid idea, unfortunately it broke compatibility with older versions. The old str/unicode code was obviously not working in Python 3, so I had to adjust a little the `Safe.retriev` and `` methods. I will let you close this after testing with your characters: note, however, that the characters you have created with your fix will not work, you will have to create new ones. It seems to work just fine with old and new characters.

I also placed this issue in the sprint 16 (which is the version for CocoMUD 49). This should be released around Christmas I believe, so that most issues we close now end up in it, to keep track of what was done during this version.

#7 Updated by Francisco Del Roio 7 months ago

I tested this and works fine.


#8 Updated by Vincent Le Goff 7 months ago

  • Status changed from Open to Closed

Great! Let's close this then. Thanks!

Please register to edit this issue

Also available in: Atom PDF Tracking page