– OS Windows 2003
– Java version 1.6.0_06
– VASSAL version 3.1.0-beta1
– VASSAL instance 1391351269
– Combat Commander version 1.90
[1391351269]
java.io.IOException: 'images/ ’ not found in C:Documents and SettingsAdministratorVASSALCombat CommanderCombat Commander 1-90.vmod
at VASSAL.tools.DataArchive.getFileStream(DataArchive.java:380)
at VASSAL.tools.ArchiveWriter.getFileStream(ArchiveWriter.java:210)
at VASSAL.tools.DataArchive.getImageInputStream(DataArchive.java:175)
at VASSAL.tools.DataArchive.getImageSize(DataArchive.java:135)
at VASSAL.tools.imageop.SourceOpBitmapImpl.fixSize(SourceOpBitmapImpl.java:83)
at VASSAL.tools.imageop.AbstractOpImpl.getWidth(AbstractOpImpl.java:578)
at VASSAL.tools.imageop.OpIcon.getIconWidth(OpIcon.java:119)
at VASSAL.counters.ImagePicker.setImageName(ImagePicker.java:98)
at VASSAL.counters.MultiImagePicker.setImageList(MultiImagePicker.java:145)
at VASSAL.counters.Embellishment$Ed.reset(Embellishment.java:1221)
at VASSAL.counters.Embellishment$Ed.(Embellishment.java:978)
at VASSAL.counters.Embellishment.getEditor(Embellishment.java:735)
at VASSAL.counters.PieceDefiner.edit(PieceDefiner.java:526)
at VASSAL.counters.PieceDefiner$7.mouseReleased(PieceDefiner.java:366)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Basic Pieces which are entirely comprised of layers, so basicpiece trait is empty
Layers with multiple levels that follow properties where certain values require that the layer be blank/not visible - certain levels may be empty
Its easily solved by adding a transparent marker in each of them but doesn’t mean everyone is going to do that if they are lazy like me
Should add it is only in the editor this occurs, but doesn’t affect module at run time so its really more an annoyance to designer which they can choose to ignore by checking the error box for now, no player is going to notice this
This isn’t a null image—it’s an image where the filename is a space.
Believe it or not, that’s a valid filename, and so the user should
be warned that it doesn’t exist in the module. (So long as we permit
filenames which are just whitespace, that is.)
Does this happen for you when the filename really is null?
Interesting then, because there really isn’t a file there
As you can see in the picture attached Image 1 one of the layer has no file associated with it, and this is what I used to generate the log – so something is telling it there is a file there (albeit nonexistent it looks to me) with a space in it? Ive never created a file named “ “ before
I see now—it’s probably the case that the filename isn’t being trimmed
of leading and trailing whitespace somewhere, of something of that sort.
I’ll look into this.
Could someone suggest to me a module where this happens other than Combat
Commander? Presently all of the auto-module and auto-extension stuff isn’t
working, but I’d like to work on this problem first.
Also: Tim, could you explain for me why CC is packaged the way it is?
I’m trying to figure out now why the --auto and --auto-extensions flags
aren’t working, but I don’t understand what they’re for, which makes
the task harder.
I should add that it was packaged that way to prevent image extraction / editing of module.
However my current new unreleased build of the module which is using the Vassal beta and not packaged also has the same issue so dont know if that helps out any
Could I get that from you? I know there’s a problem with loading modules
which use auto-extensions right now, probably because I didn’t understand
how they’re supposed to work when I was refactoring the startup code. But
if you’re having a problem loading the module unpackage, there’s there’s
likely some other problem also.
Think I got 2 issues crossed here! I was referring to the null image issue from the thread title.
The JVM issue only happened few times for me, but It did disappear and clear itself up. Only thing I know of that was different was I had a standalone JRE which I uninstalled and was using JRE that was part of JDK package instead - not that this should matter I would have thought.
But that messed up my Eclipse also from running so I had to put the standalone JRE back and the JVM problem also went away
Now that all this stuff is working again, because I used default directories on the Java installs, the JVM problem was probably some sort of path issue I guess.
Whoever was having same problem might want to clear cache and reinstall mod to see if that helps fix path links
I made some progress tonight against the problem with loading the auto
module. That works now with what’s in the trunk. Loading auto-extensions
might also work now, but I have nothing to test that with other than
the CC module—which brings me to another problem:
I still can’t get the auto module to load with the CC jars—the buildFile
isn’t XML, so the XML parser chokes on it. Somewhere in 3.0, magic is
occuring so that this buildFile becomes readable, but I haven’t been able
to locate that and why it’s not being run now.
Possibly this is a security issue, so if you’d like to take this to private
email, please do so.
The --auto flag indicates that the module data is included as a resource in the Java classpath. It means you should use a JarArchive subclass of DataArchive. The -autoExtensions flag lists module extensions that are also included as classpath resources, each represented by their own JarArchive instance. Auto-Extension resources live within a named folder in the classpath, (e.g. myExtension/buildFile) and the --autoExtensions argument lists the folder names.
I was referring to the null image issue from the thread title.