Interesting. I built the module in 3.2-beta, so 3.1.20 refuses to try to load that module on my machine. (‘Module too new’)
Thus spake Rindis:
“uckelman” wrote:
But, I see the same thing with your module and 3.1.20-svn8251, which
makes me think this is either an old problem, or is a problem with the
module.Interesting. I built the module in 3.2-beta, so 3.1.20 refuses to try to
load that module on my machine. (‘Module too new’)
This is not something you can normally do. I hand-edited the VASSAL
version listed in the buildFile and module metadata to get around it.
–
J.
I just did a couple quick-and-dirty recreations of the module with the map and grid (twice, once in 3.1.19 and once in 3.2-8249), and they both have the same off-centeredness. So it seems to be the code, not the module itself.
I didn’t think 3.1.20 was forward compatible with 3.2.0
Fooled me once thinking the 3.1.20 was a 3.2.0 release update 
Yep, that’s it. Any commands executed by another client while the post-synchronization load up is completing will be queued up and executed in order as expected.
I feel bad I didn’t think of this sooner, but I is it too late to hash the user passwords for 3.2? 3.2 is not backward compatible with 3.1.x anyway and the PLAYER entry already changed format, so it would be a great opportunity to change from cleartext to a simple hash like SHA1. Not that that can’t be broken but it makes it a little more difficult to find the user password than cleartext. Since you compare one with the other, comparing cleartext to cleartext is no different from comparing hashed to hashed. Only thing that would have to change is writing a hashed password to the prefs instead of clear when changing prefs for a module.
Thus spake bdgza:
I feel bad I didn’t think of this sooner, but I is it too late to hash
the user passwords for 3.2? 3.2 is not backward compatible with 3.1.x
anyway
This is not the case. Most everything which worked with 3.1 should still
work with 3.2, with only a few exceptions. This is exactly why we can’t
change the password mechanism in 3.2, it it would break that.
We will rectify the situation with passwords in V4.
–
J.
The password format stored in 3.2 is already different from 3.1 since it adds an extra fields with a “;”, so it’s easy to detect if it’d be a classic password-only-in-cleartext or a multi-password-field-in-hashed. So ok, my statement that only 1 place needs to be changed is not true, it would be slightly more work and would only be doable depending on in how many places you read the password (which should be one). But it would still be compatible with loading 3.1 files, just not loading 3.2-beta1 files.
Thus spake Rindis:
“uckelman” wrote:
Yes, something isn’t quite right here. When I turn on hex grid
drawing,
the centers look dead-on, so it’s not the hex grid that’s misalligned.But, I see the same thing with your module and 3.1.20-svn8251, which
makes me think this is either an old problem, or is a problem with the
module.–
J.I just did a couple quick-and-dirty recreations of the module with the
map and grid (twice, once in 3.1.19 and once in 3.2-8249), and they both
have the same off-centeredness. So it seems to be the code, not the
module itself.
Does this still happen with 3.2.0-beta4? If so, please file a bug report
with instructions for reproducing the problem.
J.