I have a couple of issues with the current reporting of missing images in modules.
Currently, in Player mode, a missing image is reported as in the Chat window as:
Bad data found in module or saved game: offboard_boxes-t.png
This is meaningless. Surely something like
Missing Image: offboard_boxes-t.png
is better. Also, a full FileNotFoundException is dumped to the Errorlog which is pointless and clutters up the errorLog, it is already writing a an ‘Image not found: imagename’ message which is sufficient.
In Editor mode, if you start a game that has missing images, you get one Dialog that must be dismissed for each missing image. This is just plain painful, given that if you have to use an old save game that references missing images, you can’t easily ‘fix’ this problem. I would much prefer to see this handled the same as Player mode with just a message in the Chat Window.
Also, why are we still getting Missing Image Bug reports when they should all be reported to the user only either in the Chat Window, or as a Dialog?
What would be even better is if we could somehow identify which component is referencing the missing image.
Was that this one:
java.util.concurrent.ExecutionException: java.util.concurrent.ExecutionException: java.io.FileNotFoundException: ‘images/std-baku-overlay.png’ not found in J:\Vassal\Modules\RsR\RsR_v37.vmod
Alternately, if the missing items could just be collected when opening
in the Editor, they could be presented in a single dialog that reports
the problems opening the file. That would serve as notice of
problems, but not involve the painful plethora of pop-up boxes.
Having a List somewhere to collect these would be one way
of providing the information.
If only we could have components report what images they use, then we
could discover all of these in one go, when the module is loaded. As
it is, we don’t know whether images are missing until we attempt to
On Oct 21, 2008, at 10:17 AM, Joel Uckelman wrote:
Oh. So this happens then during play, instead of just when the module
If it happens during the loading process, it should be possible to
collect them instead of raising the dialog each time, right? In place
of the dialog call, they are just added to a global or passed parameter.
I am completely with you here. This is exactly what I would like to do,
but it isn’t logically possible to determine what images are missing
if you can’t ask build nodes to report what images the subtrees they root
are using, and be sure that the report you get is exhaustive.
Unfortunately, the only way we can get this information is to add methods
to the Buildable interface, which would probably break every single module
which uses custom code. I do see a solution to this problem on the horizion:
Once we have the new site up and the modules better organized, we’ll have an
almost complete listing of what modules use custom code, and then in the
worst case I’m willing to go fix them all myself, if that’s what it takes
to get Rodney to agree to let us change the Buildable interface.
One obstacle is that the components in the Palette are built lazily. Building the entire palette recursively significantly slows down startup time for a module like VASL.
Another obstacle is that savefiles from older module versions might reference images that don’t exist, even if the current module version doesn’t use any missing images, so you’ll always have the possibility of encountering missing images at logfile-execution time.
is that why the palette shows pieces with empty labels for DP’s (in b4, in b3 backwards I think it used to show the DP prop name) instead of their starting values, until you move them onto the map?
just a curious onlooker.