Issue with the new beta: by mistake, initially, I opened a module last edited in Vassal 3.5.8. Opening a log file I was greeted with this ominous dialogue.
The link to the Java replacement resource (javadoc) bounced with a 403 Forbidden code, so that was no help. In the details of the dialog is a (thankfully) short list of items within the module that seem to be running afoul of the new code.
Any suggestions on how to fix the module once 3.6 becomes the Vassal standard?
Try the javadoc link now.
OK, the link to the web page works. But I’ll be damned if I can find anything like a “solution” to the problem. I can use the search function to get here:
DataArchive (vassal-app 3.6.0-beta2 API)
[
declaration: package: VASSAL.tools, class: DataArchive
](DataArchive (vassal-app 3.6.0-beta2 API))
But once there… now the language turns into g(r)eek…
What do I do now, to track down the problem and/or solution??
Allen / Stiglr
Since you’re looking for a method which was removed in 3.6.0-beta1, you won’t find it in the 3.6.0-beta2 javadoc. You need to look in the javadoc of a version where the function still existed, such as 3.5.8.
Here’s the method you’re looking for.
You’d be replacing this method call with something that produces an ImageOp, possibly one of the static methods from Op. My guess is that you’d need Op.load(), but it’s hard to tell without seeing the code you have.
Once we get into code, I’m totally at sea. I have no idea what I’m even looking at. No idea what to do.
Are you the module’s maintainer?
I literally do not have the code to look at, so it’s hard to make any suggestions beyond the one above.
Um… I guess I am, because I’m the one who made some small edits to the current 3.5 version. The previous version, I’m not in contact with that maintainer.
Do you have the source code?
I have the MODULE (.vmod), and that’s it.
Is the source code in the module file? You’re looking for files which end with .java.
No idea. Like I said, this is alien landscape to me…
The module file is a ZIP archive. Try taking a look inside with something like 7zip.
I can find one folder in the archive that has .class files in it. Nothing with .java or anything similar. The entire .vsav is only 2.62MB. Would it be better to send it to you via FB or some other delivery device…?
I sent the module via Facebook. Thanks for any efforts expended on my behalf, as always!!! 
Here’s the procedure if you need to update custom classes but lack the source code:
Unzip the module.
Decompile the class file to source code:
java -jar cfr-0.150.jar FlatTop/FlatTopPlayerRoster.class >FlatTop/FlatTopPlayerRoster.java
Sometimes cfr has trouble with anonymous classes. I’ve also had luck with procyon. (I needed it for FlatTopPropertySheets.class, for which see below.)
procyon-decompiler FlatTop/FlatTopPropertySheet.class >FlatTop/FlatTopPropertySheet.java
- this.retireButton.setIcon(new ImageIcon(GameModule.getGameModule().getDataArchive().getCachedImage(iconFileName)));
+ this.retireButton.setIcon(new ImageIcon(new OpMultiResolutionImage(Op.load(iconFileName))));
javac -classpath Vengine.jar -source 11 -target 11 FlatTop/FlatTopPlayerRoster.java
After I replaced the method call which was removed, the Deprecation & Removal reporter found a deprecated method call, which I also replaced:
FlatTop.FlatTopPropertySheet => VASSAL.build.module.Map.componentCoordinates(java.awt.Point), 2021-08-05
This second replacement was a bit fraught; neither cfr nor procyon were able to decompile completely. In this instance, procyon figured out a case that cfr did not which I couldn’t see how to repair, while the bits that procyon didn’t get I did see how to repair, so I worked from what procyon produced instead.
I’ve sent you back the module. I have not tested it beyond that it loads. You’ll want to check that FlatTopPlayerRoster and FlatTopPropertySheet still behave as expected.