Played for over four hours with three players and not a single issue to be had; and that’s a first - so our issues were clearly related to oversizing the Heap. Thanks!
Thus spake chrono280:
“uckelman” wrote:
Thus spake chrono280:
I haven’t had any major issues. I do get the “moved.gif” not found
error message pretty often but I think that is my fault.Can you show me a module where that happens for you?
–
J.At first I figured it was just my in-progress module for Space Empires
Close Encounters, but it happens in the older, 3.1.19 version of Space
Empires that I released a few months back and in Band of Brothers, a
module I did not make.So maybe it’s not just me.
[1]
[2][3]
In the second image the MOVED icon still appears on the piece when it is
moved as normal, despite the error.The error seems to occur when either I open a piece property window from
the editor or if I select a piece from the palette in either the editor
or in game mode.
The problem here is that VASSAL originally tacked “.gif” onto
extensionless image names, which was a poor design decision and one
which I’ve been trying to correct for several versions now. Apparently
I haven’t yet succeeded. I’ll try to track down tomorrow the reason my
last fix isn’t catching this case.
–
J.
Great, thanks I was actually about to bring it back up again. It doesn’t appear to be a show stopper in any way but it is an error message that might confuse some players.
Thus spake chrono280:
I haven’t had any major issues. I do get the “moved.gif” not found
error message pretty often but I think that is my fault.
Try 3.2.0-svn8213. Is this better?
–
J.
Yes it does not seem to occur in 8123. I’ll be editing for the next couple hours, I’ll let you know if I see it. Seems to have been fixed!
I was also getting the moved.gif error message in a new module and I can confirm it disappeared with this latest build.
I’m seeing a problem with counters not centering properly. (I seem to recall this cropped up some time ago, and was generally resolved.) Exists on beta-1 and on svn8230.
Everything’s fine in the various existing modules I’ve seen, but I started a new one, put in a map, defined the hex grid… and the counters are snapping to a position that’s a bit high and off to the left.
You can check out the module here. Just start a new game, pick the first map choice, and fiddle with the counters from the Ships menu.
Joel, a few things I noticed that you might want to have fixed before 3.2.0 official release (this was using build 8255, possibly #1 already in 3.1.x):
-
Trying to start a game in online mode will abort with a unknown type bug when the server is unreachable (no Internet)
-
Starting a game by mistake in the game lobby (as opposed to opening a dedicated room first) now correctly gives a warning that it is not the right place to do it, but the game still starts (at least on the local computer)
-
When a second player enter the room synchronization starts automatically (nice) but it immediately says “Synchronization complete”, whereas
…a) on the “host” computer “sending data to …” appears somewhat later
…b) but the host never receives a “finished sending data to …” type of message
…c) some more time (minutes in MH case) need to go by before the actual “choose side” prompt finally appears for the remote computer
Therefore, I wonder: what if the host starts moving pieces around before the sending data actually finishes? Or does synchronization really take nanoseconds and the slownes mentioned above is just the normal game starting slowness for bulky modules (like MH)? Will it automatically resynchronize on the remote computer even if he still has to go through the side selection prompt?
Regarding 3 a long known issue see
vassalengine.org/tracker/sho … gi?id=1964
a semi related enhancement you may like also see
vassalengine.org/tracker/sho … gi?id=1947
-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of barbanera
Sent: Tuesday, July 31, 2012 11:44 AM
To: messages@vassalengine.org
Subject: Re: [messages] [Developers] Release candidate for 3.2.0-beta1
Joel, a few things I noticed that you might want to have fixed before
3.2.0 official release (this was using build 8255, possibly #1 already in
3.1.x):
-
Trying to start a game in online mode will abort with a unknown type bug
when the server is unreachable (no Internet) -
Starting a game by mistake in the game lobby (as opposed to opening a
dedicated room first) now correctly gives a warning that it is not the right
place to do it, but the game still starts (at least on the local
computer) -
When a second player enter the room synchronization starts automatically
(nice) but it immediately says “Synchronization complete”, whereas
…a) on the “host” computer “sending data to …” appears somewhat later
…b) but the host never receives a “finished sending data to …” type of
message
…c) some more time (minutes in MH case) need to go by before the actual
“choose side” prompt finally appears for the remote computer
Therefore, I wonder: what if the host starts moving pieces around before the
sending data actually finishes? Or does synchronization really take
nanoseconds and the slownes mentioned above is just the normal game starting
slowness for bulky modules (like MH)? Will it automatically resynchronize on
the remote computer even if he still has to go through the side selection
prompt?
Read this topic online here:
https://forum.vassalengine.org/t/release-candidate-for-3-2-0-beta1/4947/38
Thus spake Rindis:
I’m seeing a problem with counters not centering properly. (I seem to
recall this cropped up some time ago, and was generally resolved.)
Exists on beta-1 and on svn8230.Everything’s fine in the various existing modules I’ve seen, but I
started a new one, put in a map, defined the hex grid… and the
counters are snapping to a position that’s a bit high and off to the
left.You can check out the module here[1]. Just start a new game, pick the
first map choice, and fiddle with the counters from the Ships menu.
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.
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.