crashtest2 build encounters the crash error; no error notice other than the crash itself.
Re that MP3; there is something about the Medieval (and Ancients) module regarding sound. For some reason, the modules allow “unit marching” sounds to be turned off with an on screen button but the other type of sound(s) - dice rolling & card drawing - can only be turned off by substituting a silent sound. So I think there is more than one MP3 embedded in the module. The developer suggested substituting silent MP3s as the way to disable all sounds but I never got round to doing that on my Mac. If there is a silent sound, I am not sure where it is used, perhaps it is just there as a convenience that can be swapped in for other sound files to disable them but not used in the standard configuration, or perhaps it gets triggered when the “unit sound off” button is pressed.
I suspect that this will be a “well-known” bug but anyway, I add that failed “undo” of moves is a common problem, so much so that the C&C online tournament gamers that I know are very wary of using undo (because it corrupts the log file). Another, perhaps related, symptom is when units lose their ability to leave a movement trail (I’ve seen this in C&C modules and 2nd Fleet).
I also acknowledge this is seen in v3.2.17 and might be out of scope of v.3.3.0 work.
Incidentally, a detail is that if you add “Does Not Stack” (aka Immobilized) to the piece, the bug does NOT reproduce. I’m pretty sure somewhere in the logic for adding/removing “stacks” to the board, a detail of the movement is either not getting recorded, or (actually equally likely I suspect) being refused when processed.
Re that MP3; there is something about the Medieval (and Ancients) module
regarding sound. For some reason, the modules allow “unit marching”
sounds to be turned off with an on screen button but the other type of
sound(s) - dice rolling & card drawing - can only be turned off by
substituting a silent sound. So I think there is more than one MP3
embedded in the module. The developer suggested substituting silent
MP3s as the way to disable all sounds but I never got round to doing
that on my Mac. If there is a silent sound, I am not sure where it is
used, perhaps it is just there as a convenience that can be swapped in
for other sound files to disable them but not used in the standard
configuration, or perhaps it gets triggered when the “unit sound off”
button is pressed.
The ability to play sounds should not have been added (way back in 2.8)
without a switch for turning sounds off in the Preferences. I’m not
inclined to accept patches for new features, but if someone were to submit
a patch for that, I’d consider it.
I checked the contents of the CCMedievalV1_4.vmod and found only one MP3
there, silence.mp3.
Try 3.3.0-svn9355. I fixed a threading problem with the stream from which
MP3s are read. I suspect this will solve the problem.
Yes, seems to have worked. I am using C&CM for PBEM once or twice a day at the moment, so I can continue to monitor but vlogs that were reproducing the crash are no longer doing so, so it looks fixed.
Also, the C&CM module quit cleanly in all three tests that I did.
Try 3.3.0-svn9355. I fixed a threading problem with the stream from
which
MP3s are read. I suspect this will solve the problem.
Yes, seems to have worked. I am using C&CM for PBEM once or twice a day
at the moment, so I can continue to monitor but vlogs that were
reproducing the crash are no longer doing so, so it looks fixed.
Also, the C&CM module quit cleanly in all three tests that I did.
Hello Joel,
The “Mouse over Stack Viewer” property is failing again when DPI scaling is <> 100%, in another module. I am using 9355 to test this.
The module is The Greatest Day Sword/Juno and Gold beaches module v 1.8.9 (vassalengine.org/mediawiki/i … _v189.vmod)
Not sure what is different here that makes it fail whereas it works well in Tunisia II
Main differences I see in the Mouse Over Stack Viewer are: that in GTS the pieces are drawn at 1.0 scale factor, Tunisia uses 0.9
Will try playing with that parameter and let you know. Bye Claudio
Regarding the “Mouse Over Stack Viewer” I copied all settings from TuII onto the GTS game, but the issue persists.
The “Mouse Over Stack Viewer” trait probably depends on other properties of the game itself.
Kr
Claudio
The problem is that my GTS modules make extensive use of custom Java code modules, including a custom mouse-over stack viewer. I had been putting off applying the HiDpi fixes as I am unable to reproduce the issues on a Windows system without a HiDpi screen. [If anyone knows how to do this, please let me know.
If you are willing to be my Test Pilot, I will start work on the update. As well as the mouse over stack viewer, I expect there will be problems with the Attack Wizard LOS thread, Info display and the Out-of-command display.
Aha,
Problems didn’t appear (except for blurry counter images) until I ran 3.3.0. Now I have the images appearing out of position issues. I have some thing to work with now, but will need assistance with testing on real HiDPI displays.
Brent.
Brent
Ok, sign me up as your Test Pilot. I will also install the vassal project on Eclipse shortly.
you can contact me directly at claudio.ciardelli@gmail.com
Bye
I’ve uploaded 3.3.0-svn9359, which reverts svn9250, the commit we determined was causing the problem with the C&C Napoleonics Vimiero scenario.
Unfortunately, the undo issue I found with the Vimiero scenario also happens in 3.2.17, and isn’t affected by svn9250 at all. 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’m not sure what undo problem is in Vimiero, but in case you didn’t see here is a minimal example module that will reproduce AN undo problem that is definitely in 3.2.17 and it will definitely reproduce it for you: vassalengine.org/wiki/File:UndoBug.vmod
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.
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.
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.