Test builds for 3.3.0

I don’t seem to be able to view bugs via the “Tracker” (Bugzilla) function. Is it possible to gain read-access or am I not looking in the right place?

Thus spake marktb1961:

“uckelman” wrote:

I would still like to fix Bug 12538 for the 3.3.0 release, which
svn9250 was intended to fix, but as I can’t reproduce the problem it
then causes I’m not well-positioned to do that.

Would someone who can reproduce the Vimiero problem be willing to
create a minimal example module that demonstrates the problem?

I don’t seem to be able to view bugs via the “Tracker” (Bugzilla)
function. Is it possible to gain read-access or am I not looking in the
right place?

That particular bug was marked as “to be moderated” for no reason I can
see, so wasn’t public. I’ve unset that. Try now.


J.

I had a look. That’s definitely not right—but as it already happened in 3.2.17 I’m not going to sink time into fixing it. If someone else wants to, I’m happy to review patches.

Okay thanks for looking. I dug around for probably 3 hours trying to find it, but at least so far am not able to track where it is misbehaving. The CLUES I can offer anyone who is willing to have a look is:
(1) If you add “does not stack”/Immobilized to the piece, the problem goes away. So something to do with stacks and reversing their moves.
(2) The problem occurs specifically when a piece (or stack) is moved, and somewhere during the processing of the trigger caused by the move the piece (or stack) gets moved a second time.
(3) It is ONLY when a piece/stack is dragged somewhere as the initial part of the movement. A sequence initiated by send-to-location does not manifest the problem.

I think it is quite likely that the movement is being correctly wrapped up in the Command (else the initial move wouldn’t be working right in logfile/multiplayer play, but it IS working right), and that therefore the error is somehow in the execution of the UNDO – possibly some part of it is being refused/ignored as a duplicate-to-the-same-location or something like that. But alas I have not found it so far.

I do agree with what Mark says, above, that this is probably at the root of what generates the occasional bug reports of “my undo didn’t work”.

I will keep looking but while I’ve looked at buckets of multiplayer synch code in my time, I’m still pretty new to the idiosyncrasies of Vassal’s “stack” functionality.

Thanks again for having a peek.

Brian

I’ve uploaded 3.3.0-svn9360. This makes a few small adjustments to how we’re building the packages. There should be no changes to the Windows and Mac packages between this and svn9359. The Linux package now has Java bundled with it.

Please give these a try. What I’m hoping to verify with this build is that I’ve not broken installation etc. for the packages, i.e., that they still run as before. There are no code changes in svn9360.

Installed last night. Using it ok on my Mac.

By the way, I was looking at C&C Ancients module content recently. The other sounds are provided via .wav files. I expect it is the same for Medieval.

Re-visiting this with 3.3.0-svn9360, I find a difference with the image produced, compared to v3.2.17 which I missed when I tested previously. Though the image is captured in full, it is somehow scaled wrong in the output compared with v3.2.17.

v3.2.17 - dropbox.com/s/tziu1vo69u927 … 7.png?dl=0

v3.3.0-svn9360 - dropbox.com/s/r00aprdk36gnj … 0.png?dl=0

Thus spake marktb1961:

“marktb1961” wrote:

3.3.0-svn9354 on MacBook Pro (with Retina) MacOS Catalina 10.15.4

Updated:-

  • zoom bug when using the “saved map as PNG file” - confirming, fixed.

Re-visiting this with 3.3.0-svn9360, I find a difference with the image
produced, compared to v3.2.17 which I missed when I tested previously.
Though the image is captured in full, it is somehow scaled wrong in the
output compared with v3.2.17.

v3.2.17 - dropbox.com/s/tziu1vo69u927 … 7.png?dl=0[1]

v3.3.0-svn9360 - dropbox.com/s/r00aprdk36gnj
0.png?dl=0[2]

Thanks for spotting this. Try 3.3.0-svn9361.


J.

I ask this fully aware the answer may be “no” –

Is there any chance that for 3.3 you’d be willing to add the following line to each of the three MouseWheelEvent listeners (last three methods) in ScrollPane.java:

if (e.isControlDown() || e.isAltDown()) return;

Reason – I’m dying to add some MouseWheel functionality in custom java classes, but alas the MouseWheel stuff is attached deep in the bowels of Map.java (no easy way to “override”), and it presently sucks up all the MouseWheel oxygen.

With that line, Ctrl+MouseWheel and Alt+MouseWheel would become available for custom-classing, without altering behavior for present modules.

Full code w/ proposed patch below.

Fingers crossed,

Brian

    viewport.addMouseWheelListener(new MouseWheelListener() {
      public void mouseWheelMoved(MouseWheelEvent e) {
        if (e.getScrollAmount() == 0) return;
        if (e.isControlDown() || e.isAltDown()) return; //BR//

        if (e.getScrollType() == MouseWheelEvent.WHEEL_UNIT_SCROLL) {
          final JScrollBar bar = e.isShiftDown() ?
            horizontalScrollBar : verticalScrollBar;
          if (bar == null || !bar.isVisible()) return;

          bar.setValue(
            bar.getValue() +
            e.getUnitsToScroll() *
            bar.getUnitIncrement()
          );
        }
      }
    });

    verticalScrollBar.addMouseWheelListener(new MouseWheelListener() {
      public void mouseWheelMoved(MouseWheelEvent e) {
        if (e.getScrollAmount() == 0) return;
        if (e.isControlDown() || e.isAltDown()) return; //BR//

        if (e.getScrollType() == MouseWheelEvent.WHEEL_UNIT_SCROLL) {
          verticalScrollBar.setValue(
            verticalScrollBar.getValue() +
            e.getUnitsToScroll() *
            verticalScrollBar.getUnitIncrement()
          );
        }
      }
    });

    horizontalScrollBar.addMouseWheelListener(new MouseWheelListener() {
      public void mouseWheelMoved(MouseWheelEvent e) {
        if (e.getScrollAmount() == 0) return;
        if (e.isControlDown() || e.isAltDown()) return; //BR//

        if (e.getScrollType() == MouseWheelEvent.WHEEL_UNIT_SCROLL) {
          horizontalScrollBar.setValue(
            horizontalScrollBar.getValue() +
            e.getUnitsToScroll() *
            horizontalScrollBar.getUnitIncrement()
          );
        }
      }
    });

Yes, that worked in my test.

3.3.0-beta1 is released: https://forum.vassalengine.org/t/vassal-3-3-0-beta1-released/10479/1

Thanks everyone for all of your hard work getting us to this point.

Thanks TO YOU for the hard work. I might speak only for myself, but we were only supporting you.

Hey all, I’ve been working on a module, almost finished, but I have been using v3.3.0 betas while doing so. I’ve belatedly decided I want users who are on v3.2 to be able to open my module, is even that possible now?

If I change the VassalVersion in the buildFile to 3.2.17, will that allow my module to be opened with that version of vassal? Thanks!

I’m no expert but I would expect so. Is anything stopping you from installIng 3.2.17 and tryIng it?

Thus spake alanesh:

Hey all, I’ve been working on a module, almost finished, but I have been
using v3.3.0 betas while doing so. I’ve belatedly decided I want users
who are on v3.2 to be able to open my module, is even that possible now?

If I change the VassalVersion in the buildFile to 3.2.17, will that
allow my module to be opened with that version of vassal? Thanks!

Yes, in this particular case, that should work, because there aren’t
any component or file format changes in 3.3.0. (You should also update
the VassalVersion element in the moduleData file.)

It’s not something you should rely on working in general, however. (There
are modules for which this would not have worked between 3.1 and 3.2,
for example.)


J.

Super, thank you for the details.

New test build 3.3.0-svn9380: vassalengine.org/~uckelman/tmp/

This moves the Java bundled with the Windows and Mac builds from Java 13 (which is now EOL) to Java 14.

I already see an svn0383. Is that the current test target?

Thus spake slimy:

“uckelman” wrote:

New test build 3.3.0-svn9380:
vassalengine.org/~uckelman/tmp/[1]

This moves the Java bundled with the Windows and Mac builds from Java
13 (which is now EOL) to Java 14.

I already see an svn0383. Is that the current test target?

Yes.

9381 has some code cleanup, 9382 (probably) fixes a problem with playing
WAV files on some systems (Bug 12731), 9383 has a font rendering
improvement (Bug 12732).

All three of those contain the Java 14 change from 9380.


J.