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
This behavior/bug (choose the one you prefer) has been there for a long time.
The 3 screen captures I uploaded are only partial captures of the full piece. Here after is a screencapture with both the complete piece as seen in Editor and in the background as seen within the game:
Dumb question of the day: If the 3 bugs I reported previously in this thread also affect 3.1.8 and 3.1.9, do I have to open other bug report for those versions as well? Because I think that having them reported on 3.2.0 will not get them processed anytime soon.
Actually, if they exist prior to 3.2, the developers prefer that you change the ‘Version’ field in the tracker to 3.1.18, to expedite the release of 3.2 - and therefore the resolution of your bugs.
I shall do so this evening (GMT+1). I still have old versions of my modules I can test using 3.1.8 and 3.1.9.
I will edit the bugs and select the lowest version affected by those bugs.
Dumb question of the day: If the 3 bugs I reported previously in this
thread also affect 3.1.8 and 3.1.9, do I have to open other bug report
for those versions as well? Because I think that having them reported on
3.2.0 will not get them processed anytime soon.
I suppse you mean 3.1.18? In that case, you should set the versoin in
the bug report to 3.1.18.
I did load 3.1.18 and used a test module. I update the 4322 bug (see latest comment) and uploaded the test module on my web site. Link included in the bug report.
Bug report also updated for 4324 bug (select unit border offset)
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)
Please don’t file bugs on SourceForge. No one will ever see them there.
By “[…] I already filed a but report in the old system on SourceForge […]” I meant that when Sourceforge was still our bug tracking tool, I filed a bug report for the selected piece border problem.
Now that we use a new system and since the problem persists in 3.1.18/3.1.19/3.2.0, I filed a new report in our new system
Bug 4268 (and it looks like 4122 might be the same bug) is a show stopper for me. Because of it I’ve been stuck at build 7890, the last build I’m aware of that didn’t have the bug. Is anyone looking at this?
By “[…] I already filed a but report in the old system on SourceForge
[…]” I meant that when Sourceforge was still our bug tracking tool, I
filed a bug report for the selected piece border problem.
Now that we use a new system and since the problem persists in
3.1.18/3.1.19/3.2.0, I filed a new report in our new system
Ah, I see. When we switched over, all the old bugs were migrated. This
is ok. I didn’t want to leave you thinking that putting new bugs into
SF was the way to do it.
Bug 4268 (and it looks like 4122 might be the same bug) is a show
stopper for me. Because of it I’ve been stuck at build 7890, the last
build I’m aware of that didn’t have the bug. Is anyone looking at this?
I’ve poked Pieter about fixing this, as it’s apparently due to changes
he made to how hex grids are handled.
