One possibility of getting more people to test the betas would be to lure them with new features and more bug fixes. Have more regular beta releases, and include all the latest commits in them. Or even nightly releases.
Mmmmmmmm, tasty features! Don’t encourage me…
Also, and this is a common thing, I have encountered this in many enterprise projects, the lack of testing and testing resources has an impact on development, if it takes too long for bugfixes and new features to get released it’s quite discouraging for developers. Like that undo bug fix that I wrote I think 2 months ago, it’s quite an important fix and impacts many or even most users, including myself, and it’s still not in any release. And if at the same time some 1.5% minority of users reports something and it gets fixed right away and a test build is made for them…
Well to be fair we did have test builds for Undo & found they worked, etc. But 3.3.2 needed to be released first because an entire platform (Macs) was failing. Seems like we’re on a glide slope to a nice yummy 3.3.3.
(But I’ll admit that the prospect of a 3.3 line that included some new features is what got me excited enough to get me off my lazy ancient butt and start contributing code & fixes and stuff)
Thus spake Flint1b:
Also, and this is a common thing, I have encountered this in many
enterprise projects, the lack of testing and testing resources has an
impact on development, if it takes too long for bugfixes and new
features to get released it’s quite discouraging for developers. Like
that undo bug fix that I wrote I think 2 months ago, it’s quite an
important fix and impacts many or even most users, including myself, and
it’s still not in any release. And if at the same time some 1.5%
minority of users reports something and it gets fixed right away and a
test build is made for them…
Crashes > new bugs > old bugs > features.
When you have a user who can reproduce a bug, you may miss your chance to
fix it if you don’t take advantage of the fact that you have their
attention. It also generates goodwill, which is a hard thing to achieve
other ways.
We’ve had some major changes in the build setup which haven’t settled down
yet over the period you’re speaking of. And 3.3.2 was released only one
week ago today. We’re not far off from a beta. There’s no reason to be
discouraged by the current pace.
–
J.
Yeah honestly I’ve found it quite encouraging.
You guys are awesome. Reading this was a lot more fun than attending a standup at work. 
I admit that I am an infrequent VASSAL user. Generally about once a year I get the itch to play a game online, check to see if a module is created for it, try out the module, tweak it for my own use, then play for a while.
And speaking of beta testing, I think the last time I did any testing here was for something called VASL when it was literally just a bunch of GIFs on a screen you could drag and drop, Rodney’s very first VASL concept, circa 1997 maybe?
Thanks guys. I’ll take a look later today and see if adding that parameter fixes my problem. Seems like it will.
Unfortunately, it is somewhat difficult to add that parameter to the call when starting the Player. Adding it to VASSAL.sh when starting the Module Manager won’t have any effect.
You’ll need to run the command to play the module directly in stand-alone module.
Something like this should work (from my Windows machine) in the same folder as VASSAL.sh. Just change the windows module path to a suitable linux path to your module:
java -Dsun.java2d.xrender=false -cp lib\Vengine.jar VASSAL.launch.Player --standalone --load -- "J:\Data\Vassal\Modules\Stamford\Stamford Test Bed.vmod"Do you still have that module?
I suspect that they changed from using the in-built shaders to using a custom image shader.
The in-built shaders work by creating an image on the fly to do the shading. The custom shaders just load the user supplied image to use. Both end up using the required image to build a TexturePaint to apply the shading.
I just confirmed that. By changing all of the custom image shaders in the module to use the inbuilt shaders, the problem goes away. When I did this, the Shader definitions already had colours defined, which indicates they where probably set up this way before, but the module designer decided to provide his own ‘nicer’ shading images.
The internal shaders use ImageUtils.createCompatibleTranslucentImage() to create a suitable image, then just draw lines into it. If we can work out what the incompatible part of the custom image is, we may be able to tweak it before use.
I’m on it.
Brent - use history links for this. You can find the oldest file we have this way
Thus spake Brent Easton:
I’ve used an older version of the EoTS module specifically for
testing map shaders before, didn’t trigger this problem, and wasn’t
using that flag. It makes me wonder what’s changed.Do you still have that module?
Well, technically I have all the modules. 
I have three sitting here locally with names EOTS.mod, EOTS_4.03.vmod,
EOTS_4.04a.vmod. I’ll check what they do here shortly.
I suspect that they changed from using the in-built shaders to using a
custom image shader.The in-built shaders work by creating an image on the fly to do the
shading. The custom shaders just load the user supplied image to use.
Both end up using the required image to build a TexturePaint to apply
the shading.I just confirmed that. By changing all of the custom image shaders in
the module to use the inbuilt shaders, the problem goes away. When I did
this, the Shader definitions already had colours defined, which
indicates they where probably set up this way before, but the module
designer decided to provide his own ‘nicer’ shading images.The internal shaders use ImageUtils.createCompatibleTranslucentImage()
to create a suitable image, then just draw lines into it. If we can work
out what the incompatible part of the custom image is, we may be able to
tweak it before use.
Ah. This is one of those arcane things I ginned up because painting images
with alpha on some systems is excruciatingly slow if you don’t provide the
type which can be blitted to the screen unmodified. I remember this being
a huge pain at the time.
Probably the right thing to do is convert the image for a custom shader
to a “compatible” image.
–
J.
I got it working with the stand alone command.
Good luck getting this fixed in the bigger scheme of things.
I’m getting close to having a fix for this issue that doesn’t require the Xrender pipeline to be disabled.
There are actually 2 problems causing the same Exception.
The first is that if all shaders are turned off, MapShader still tries to paint the empty area. The Xrender pipeline chokes on this. This one is easy to fix with an if (area.isEmpty()) check at the top of MapShader.draw().
The second issue will have to wait for another day, but it only fails when the custom shade image has to be zoomed. It works fine if the map zoom level is 1, or I comment out the code that uses Op.scale() to scale the shade image.
Thus spake Brent Easton:
I’m getting close to having a fix for this issue that doesn’t require
the Xrender pipeline to be disabled.There are actually 2 problems causing the same Exception.
The first is that if all shaders are turned off, MapShader still tries
to paint the empty area. The Xrender pipeline chokes on this. This one
is easy to fix with an if (area.isEmpty()) check at the top of
MapShader.draw().The second issue will have to wait for another day, but it only fails
when the custom shade image has to be zoomed. It works fine if the map
zoom level is 1, or I comment out the code that uses Op.scale() to scale
the shade image.
Good debugging work.
I read through what you said and stared at the code for a while and it
dawned on me what the problem is: The BufferedImage returned by
getShadePattern() needs to be a type that has transparency. I have a (bad)
working fix now, and I’ll make a proper one in the morning.
–
J.
Great, I’ll leave it you. I was able to resolve it by copying the getShadePattern() image into a ImageUtils.createCompatibleTrnaslucentImage(), but hadn’t quite worked out why.
Try VASSAL-3.3.3-SNAPSHOT-bug13199-2ba8d002:
vassalengine.org/~uckelman/tmp/
The solution is apparently (a) ensuring that the BufferedImage for the TexturePaint is a compatible translucent type, and (b) that the TexturePaint is handed its own BufferedImage. I was able to reproduce the bug every time, and these changes fixed it for me.