Remaining 3.2 issues

I’ve uploaded a build of trunk@8023, which is the current HEAD. Any remaining issues should be reported in the bug tracker and marked with the 3.2.0 milestone.

vassalengine.org/~uckelman/builds/

I will check the issue I reported this evening (Eastern US time).
-Mark R.

The problem I reported for build VASSAL-3.2.0-svn8015 ( https://forum.vassalengine.org/t/3-2-roundup/4393/27 ) persists in build VASSAL-3.2.0-svn8023. I see another build (8054) has been posted. I’ll try to check that one tonight.

The problem remains in 5054 as well. The last known working build is 7890. I am using the windows builds. The module I am using is VERY large. I will try to reduce it’s size and narrow in on the cause.

-Mark R.

Thus spake mroyer:

“mroyer” wrote:

The problem I reported for build VASSAL-3.2.0-svn8015 (
viewtopic.php?f=5&t=4580&p=27135#p27135[1] ) persists in build
VASSAL-3.2.0-svn8023. I see another build (8054) has been posted.
I’ll try to check that one tonight.

The problem remains in 5054 as well. The last known working build is
7890. I am using the windows builds. The module I am using is VERY
large. I will try to reduce it’s size and narrow in on the cause.

Can you point out for me which bug in the tracker corepsonds to the
problem you’re seeing?


J.

I can’t because I don’t know how to use the bug tracker, and I’m not even sure if it was ever logged that way.
Someone else here acknowledged seeing the problem on their module too - perhaps they can help?

-Mark R.

I’m still using svn8023. Haven’t tested svn5054 yet.

I’m starting to run into graphics offset problems that I haven’t experienced before. I thought is was a Java issue but I went back to a previous revision of TBK and it works fine and all I did was change a few key commands which have nothing to do with the offsetting graphics. However, my module has also gotten quite large as well. How large is your build file?

Mine just exceeded 2 megs and I started having these problems. Is there a limitation to the size of the build file? Is there a limitation to the number of keywords that can be used?

Also see:

https://forum.vassalengine.org/t/video-offset-problems-with-new-java-updates/4636/1

I take back everything I said.

I upgraded my Java back to Update 30. I then loaded the last known good version of TBK and made exactly the same changes I made to the version that was having the graphics problems. Lo and behold, the module works fine. So, I really don’t know what happen. The only thing I can think of is that maybe there was some sort of corruption to the module when I first implemented the changes. Or, if it is a limitation thing, I may be just short of it. I’ll let you know if the problem re-occurs.

Thus spake mroyer:

Can you point out for me which bug in the tracker corepsonds to the
problem you’re seeing?

I can’t because I don’t know how to use the bug tracker, and I’m not
even sure if it was ever logged that way.

When you have an uncaught exception, the bug report dialog comes up. You
can add bug reports to the tracker that way. If the problem is
reproducible, you can get the bug report into the tracker that way. Or,
at least post the errorLog here, so we can match it with a bug report.


J.

Thus spake DrNostromo:

Mine just exceeded 2 megs and I started having these problems. Is there
a limitation to the size of the build file? Is there a limitation to the
number of keywords that can be used?

At some point, parts of the buildFile will be held as Strings. Last I
checked, the maximum String length was 2^31-1, so you’re three orders
of magnitude shy of that with your buildFile.

Most containers in Java will have a 2^31-1 size limit, because array
indices are signed (blech!) 32-bit values; we haven’t built in any lower
limits that I’m aware of.


J.

I’ve uploaded 3.2.0-svn8071, which contains fixes for:

  • 4184: Numeric fields truncated when committing dialogs
  • 3075: NegativeArraySizeException in ImageSaver.SnapshotTask.doInBackground()

vassalengine.org/~uckelman/builds/

I installed VASSAL-3.2.0-svn8071-windows.exe and got the eek! bug and reported it.

-Mark R.

Just downloaded and looked at 3.2.0-svn8071.

I thought the visual differences were caused by going to the Windows L&F, and that it had been switched back?

Because all the visual changes/shortcomings I pointed out a while ago are still there. Most especially, the lack of outlines on the buttons is making the F&E module look positively awful (and I don’t even know how I’d put in borders short of making each button a pure graphic). I’m also worried that the smaller font is going to reduce readability.

And on a completely trivial note, when you select a module in the module manager, all the highlighted text is white except the module name, which stays black.

Ooh. Just found something:

I have a marker that can range from -10 to +10. It uses the normal layers trait to cycle through, and it has the ‘Reset’ command defined to return it to a value of 0. In 3.2.0-svn8071, the Reset command does not appear in the context menu. (The actual Control-R command does work however.) And it does show up in 3.1.18.

To see this, go to:
rindis.com/F&E 1.3.vmod

Start a new game, open up ‘Markers’, find ‘+/-’ pull it out, and play with it.

Thus spake mroyer:

I installed VASSAL-3.2.0-svn8071-windows.exe and got the eek! bug and
reported it.

Found it, it’s Bug 4268. George, could you have a look at this one?
It appears to involve your attributes code.


J.

Thus spake Joel Uckelman:

Thus spake mroyer:

I installed VASSAL-3.2.0-svn8071-windows.exe and got the eek! bug and
reported it.

Found it, it’s Bug 4268. George, could you have a look at this one?
It appears to involve your attributes code.

Ack, I mean Pieter, not George. :slight_smile:


J.

Thus spake Rindis:

Just downloaded and looked at 3.2.0-svn8071.

I thought the visual differences were caused by going to the Windows
L&F, and that it had been switched back?

Because all the visual changes/shortcomings I pointed out a while ago
are still there. Most especially, the lack of outlines on the buttons is
making the F&E module look positively awful (and I don’t even know how
I’d put in borders short of making each button a pure graphic). I’m also
worried that the smaller font is going to reduce readability.

And on a completely trivial note, when you select a module in the module
manager, all the highlighted text is white except the module name,
which stays black.

I’m giving up on the Windows LookAndFeel. It’s too broken to be usable
as-is, and I don’t want to sink any more dev time into trying to fix it.

Try svn8079.


J.

Thus spake Rindis:

Ooh. Just found something:

I have a marker that can range from -10 to +10. It uses the normal
layers trait to cycle through, and it has the ‘Reset’ command defined to
return it to a value of 0. In 3.2.0-svn8071, the Reset command does not
appear in the context menu. (The actual Control-R command does work
however.) And it does show up in 3.1.18.

This was due to what looks like a copy-paste mistake in trunk@5908,
which dates to August 2009! We had this:

if (resetKey != null && (! rndKey.isNull()) && resetCommand.length() > 0 && !followProperty) {

instead of this:

if (resetKey != null && (! resetKey.isNull()) && resetCommand.length() > 0 && !followProperty) {

It’s fixed in trunk@8080. Good catch. I’ve uploaded a new build.


J.

Awesome! Sorry I couldn’t be more help in tracking it down.

-Mark R.

I had expected it to already be switched back, which is why I was confused.

Anyway, svn8080 looks good. L&F is back to what it was. Reset command is back.

I’ve got a report that there might be another problem, but I’m still trying to find out if it’s real and what it is.