Okay, this is odd, and I don’t have a full picture of what is going on. (yet)
But, I did a log for a continuing game in 3.2.0-svn8078. My opponent was then unable to flip a counter when he played through in 3.1.18. Checking it, I cannot either (in 3.1.18). Or at least not that one. Some, I could. I believe if it was a counter I pulled out (and presumably ‘own’) I can flip it in 3.1.18, but if it is not one I pulled, I can’t flip it. However, he couldn’t flip his own counter, so it’s not just that. It seems to function again when going back to 3.1.18.
My guess (untested) is that if you pull a counter out in 3.1.18 (and save it), and then someone else records/saves it in 3.2.0, that counter will no longer flip correctly in 3.1.18, no matter who does it. If someone wants to test this theory for me, I recommend the F&E module linked above. Pull out an ordinary ship counter and use Ctrl-F to flip it (the module will generate messages with the action, which still fire even when the command doesn’t work).
Last night I was playing Pandemic with my wife - she on 3.1.18 and I on svn 8054 - and when I pulled a card face-up from a face-down deck, it would display as masked for her (and restrict her access to the flip command) no matter how many times I flipped it. I imagined that the Mask command encoding changed, and that 3.1.18 and 3.2 are not intended to be compatible in this way. Anyways, are they supposed to be?
Okay, did a new test with a fresh file. At the moment, I’m not needing to do any profile juggling to cause this, so I don’t know why some seem to work in the ongoing game.
I’ve attached a log (for use with the F&E module), where I pull a counter while in 3.2.0, switch to 3.1.18, and then back to 3.2.0. While in 3.1.18, the counter pulled in 3.2.0 does not flip properly, but works again in 3.2.0. A counter pulled in 3.1.18 continues to work in 3.2.0. (But probably won’t if you go back to 3.1.18.)
Since I don’t think 3.2.0 is supposed to break any compatibility this way, I think it’d be best to fix this. Especially since it might be hiding something deeper that I haven’t chanced upon yet.
EDIT: And I just realized this is probably the same thing as Irishwulf’s bug.
Guys,
This is not a bug. You will inevitably come to a sticky end if you try and send log files from a later version of Vassal to an earlier. We do not support this. While the fix you propose might prop up the playing of your particular module, eventually, some other new feature present in 3.2 will not be handled properly by 3.1.18 and things will fall apart for you in a different way.
Compatibility is one-way only. We guarantee that any log file created by an earlier verion of Vassal can be read and played correctly on a later version Vassal. There is no guarantee whatsoever going in the opposite direction. In certain circumstance, it may be possible to get around this restriction:
Where the two versions are bug fix versions only (e.g. 3.1.15 to 3.1.18). This will nearly always work.
Where the module is created in the earlier version and ALL counters are pulled using the earlier version. This MAY work if you are lucky.
But, here’s a problem going from 3.1.18 to 3.2.0-svn8080:
Stacking is having issues. In this case, I’ve moved a ship onto a pre-existing stack and it is not stacking correctly. The map uses layers, and everything is still on the right layer (as evidenced by the fact that the button to toggle that layer’s stack works).
Here’s the log from my continuing game. Again, it goes with the module I linked earlier. It has the movement of the counter to the stack where it has the problem. http://www.rindis.com/BvR - The Wind - 7A-P6.vlog
So, you would expect to be able to create a game in vassal 3.2.0 and send it to someone who is still on 3.0.1 and it should work? 2.9? 1.0? Don’t be fooled by the closeness of the numbers. Version 3.2.0 is a MAJOR upgrade from 3.1.x.
No, as long as you can go through the code, determine why the change was made, and what impact reverting it will have on future play and any existing modules that have been created with 3.2.0.
I’m, sorry, but I have very little time to look into this right now, but I am hoping to get a bit more active on Vassal development in a few weeks.
No, but I would like to be able to play a game that was created in Vassal 3.1 online with people that are using 3.1 clients.
This is what I have done in the bug report.
The change was made to support encoding ObscurableOptions, which would allow you to specify additional sides which can see/peek at masked pieces. These have apparently been scrapped - they are not supported in either the Mask piece editor, nor in the function which checks if a player can see a masked piece.
I do not believe there would be any effect on 3.2 behavior - the second call to nextToken(“”) on the sequence decoder would still return an empty string if the second token were removed, as I am proposing.
No, but I would like to be able to play a game that was created in
Vassal 3.1 online with people that are using 3.1 clients.
Hasn’t this entire discussion been about something that breaks when you send a log file from a 3.2 client to a 3.1 client, but works when you send it from a 3.1 client to a 3.2 client?
This is what I have done in the bug report.
The change was made to support encoding ObscurableOptions, which would
allow you to specify additional sides which can see/peek at masked
pieces. These have apparently been scrapped - they are not supported in
either the Mask piece editor, nor in the function which checks if a
player can see a masked piece.
I do not believe there would be any effect on 3.2 behavior - the second
call to nextToken(“”) on the sequence decoder would still return an
empty string if the second token were removed, as I am proposing.
I think you have mistaken the purpose of storing the ObscurableOptions into the counter. It’s to close a security loophole, not add extra functionality. The ObscuredOptions are only recorded in the 3.2 counter’s state when it is actually obscured, in an unobscured state, obscuredOptions will be null.
While your suggestion would seem work in this pariticular situation, it is asking for trouble:
If Obscured is ever changed again to add additional data to the State, then this change would have to be unwound anyway, otherwise it will cause bugs in 3.2.
If the Obscuring player where to change from a 3.2 to a 3.1 client, he would not be able to unmask his own pieces, so the fix will not always work.
So, this fix is just to allow a 3.1 client access to a tiny subset of the 3.2 functionality. Since a 3.1 client is going to fail trying to access so much other 3.2 functionality, I don’t see that it is warranted. Especially since the fix will not fix the problem in all cases.
There are two ‘correct’ solutions to this ‘problem’:
Both players use the same level of client.
Call it a bug in the 3.1 client and include a bug fix in the 3.1.19 client Obscurable.mySetState that adds a SequenceDecoder to pull off the first token to use as the obscuredBy, instead of assuming there is only 1 token.
Rindis’ post was about logfiles; mine was about online play. The state encoding is the same in both cases, so my concern is that this will discourage people from upgrading to 3.2 - as, until their partners are also using 3.2, they will be unable to play online with other people.
In any case, I see that you’re not interested in investigating this further. Noted, and dropped.
Guys,
This is not a bug. You will inevitably come to a sticky end if you try
and send log files from a later version of Vassal to an earlier. We do
not support this. While the fix you propose might prop up the playing
of your particular module, eventually, some other new feature present
in 3.2 will not be handled properly by 3.1.18 and things will fall
apart for you in a different way.
Compatibility is one-way only. We guarantee that any log file created
by an earlier verion of Vassal can be read and played correctly on a
later version Vassal. There is no guarantee whatsoever going in the
opposite direction. In certain circumstance, it may be possible to get
around this restriction:
Where the two versions are bug fix versions only (e.g. 3.1.15 to
3.1.18). This will nearly always work.
Where the module is created in the earlier version and ALL counters
are pulled using the earlier version. This MAY work if you are lucky.
Rgds,
Brent.
Fair enough, but is there a reason not to change the one line of code in
Obscurable.myGetState() which would allow this compatibility for Mask?
I’m with Brent on this. If we start making changes to ensure
interoperability between 3.1.x and 3.2.0, we will never be able to tell
if we’re done. The current file format and codebase simply does not
support versioning well enough to handle these kinds of things. I would
like this to be different in V4 onward, but there we’ll be able to plan
for it from the beginning.
We had similar issues going from 2.9.9 to 3.0.0 and from 3.0.x to 3.1.0.
In both cases, adoption of the new version was rapid, so it didn’t cause
much of a problem.
I filed 3 bugs for 3.2.0 and I would like to know if that’s all I have to do or should I report them in this part of the forum along with details about those bugs? (One of them is a bug that has been there for a long time and persists in 3.2.0: I already filed a but report in the old system on SourceForge under the “aradiel” nickname)
I finally managed to setup eclipse/subclipe and checked out the latest trunk code and actually run Vassal from Eclipse
That being said, I started having a look at the code to see if I could pinpoint where the problem is regarding the 3 “bugs” I reported.
About #4322 (text label justification & position):
As I guessed, text label position had to be cached somewhere and was not computed each time the label had to be drawn. That’s why the text label position was wrong if the string to displayed changed length if the property used to define the text label changed.
After looking around for a while I found the private Point getLabelPosition() method in Labeler.java and I commented out the portion of code returning “position” if position was not null, forcing I guess position computing each and everytime the label has to be drawn
/**
Return the relative position of the upper-left corner of the label,
for a piece at position (0,0). Cache the position of the label once the label
image has been generated. /
private Point getLabelPosition() {
/ if (position != null) {
return position;
}*/
int x = horizontalOffset;
int y = verticalOffset;
and TADA! label is properly aligned even if base property used to create label changes.
Is it possible to have change this incorporated into VASSAL code? If you want, by design, to have label position cached once and for all, is it possible to have in the TextLavel trait a check box to deactivate caching?
Kinda
“Prevent label position caching: |_| (Check this box to force VASSAL to recalculate label position each time gamepiece is redrawn. Usefull for label using global properties with changing values)”
Here is such a piece displaying a property in a text label (the bold “0”) that is supposed to have a horizontal center justification:
Without the change I propose, here is what happens when the property changes:
If the code returning cached position is commented out, here is how it looks like:
David,
The best place for this information is the bug tracker. It’s unlikely that any of the 3 bugs will be addressed until the 3.2 beta is released, but posting an analysis and proposed solution in the tracker will almost certainly expedite the fix.
Hmmm, isn’t the little icons with the small numbers on the right also part of the gamepiece (via layers or some such)? In which case the text label when updated and changed to “-45” re-positions the label with the “4” being in the center of the entire piece which is what it looks like is happening - that is what you should expect and therefore it wouldn’t be a bug, unless I am interpreting your images incorrectly?
I haven’t looked at Aradiel’s module specifically, but I have noted the behavior he describes in my own modules, and I’ve seen reports of this behavior from other players. It is true that text labels only reposition if specifically ‘set’ with a dialog prompt, and do not reposition when following a property.
Yeah - I’ve heard of the reported behavior too - I’m just confused by the images though and what they are showing - it’s not clear how this label is being changed or what is the actual gamepiece. If the entire posted image is of the actual gamepiece it would seem to contradict the report if the label is being ‘set’ as it were
