MOULa Update, Feb 13, 2012

[PeterC]

ok, I have this problem as well. Win XP. I updated MOULa, copied the filed from dat to minkata, fired it up and same error. Any ideas?

[Mac_Fife]

@PeterC: When did you update MOULa and copy the files? If you did that recently (since May 29) then the /dat files you've copied are actually newer than the ones that the Minkata client is currently expecting: I think rarified has yet to update the download manifests to match the current MOULa /dat files.

I'd think that this "misalignment" will be resolved in a day or two.

[Christian Walther]

And thanks for bumping this thread to our attention again – we should try to get a'moaca's proposed fix from three posts back tested and integrated. Any takers? I’d rather not volunteer myself as long as I still have a backlog of other stuff to do.

[D'Lanor]

This applies only to Cyan's build process, doesn't it? How would anyone else be able to test it?

[rarified]

This applies only to Cyan's build process, doesn't it? How would anyone else be able to test it?

We are building the plFileEncrypt utility as part of the normal CWE build. I could encrypt the same file multiple times and confirm the results are identical after, and different before the fix.

As a side note, plSecureStream.cpp has the same code in it (it is essentially identical to plEncryptedStream.cpp). It affects the plFileSecure utility which is used to encrypt the packed python.pak scripts file. Do you think we should go so far as to remove the randomization there as well?

_R

[JWPlatt]

To find out, perhaps it is pertinent to first answer the question of why the randomization is there.

[Hoikas]

That is not a solution for this problem. ES and SS are only used on small files with negligible impact on the update. You need to look for issues that would invalidate the PRP files--not text files. I would start by looking for uninitialized data in any KeyedObject-derived classes.

[JWPlatt]

Is it possible the build system uses them during building of the prps?

[Hoikas]

Is it possible the build system uses them during building of the prps?

PRP files aren't encrypted.

[Paradox]

The plEncryptedStream random padding data does cause differences, and should be fixed. I believe the fix proposed by a'moaca' should fix half the problem.

The other problem is inside the PRP files, as an example I took a binary diff of AhnonayCathedral_District_LinkRoom.prp: