Eek Bug Report - Failure to Load in 3.5.8

I have turned in a bug report. And I have sent you a link within it so you can download the module involved.

What I was removing the module I had just build from my vassal program and re-installing it. I do this to make sure that even though I can get it to load while I was building it, that maybe it will not load from a fresh start. So I removed it and reloaded it. It refused to re-load and generated the Bug report, which I have sent to you. I then cleared my cache and attempted once more to load the module. It still refuses. I then stored the module on DropBox and downloaded it from there to another computer (one with a larger Hard Drive and a Larger Ram - Win7). I built this using 3.5.8.

On both computers (the original build computer is a Win7 Laptop) it fails to start.

I am perplexed. It ran during build. Now it will not load nor will it run and I get multiple error messages about missing files (counters, maps, etc.).

I was just about ready to send this to the customer for him to review the work before he sends it back to me to build the scenario files. HELP!

Custoza PRIME3.jpg is 20580x16172. That is a very, very large image. There’s about 1.24GB of image data in that. The likely reason for tiles failing to be found is that the tiler exited before tiling everything, possibly due to running out of
memory.

Clear the tile cache and try loading the module again.

If that doesn’t work, your options are:

  • Reduce the size of that image.
  • Split the image into several smaller ones, and reassemble them into the full map as Boards. (I’d probably do a 5x4 grid.)
  • Wait for me to rewrite part of the image tiler to accommodate images that large.

I understand the map is very large, but that doesn’t explain why it has run for so long, about 6 weeks without problems until last night. With the exception of building the Predefined Scenarios the module was Done and Working! At least it was working until I uninstalled it and re-installed it. I can’t resize the map because I’d have to resize all the counters as well as a secondary chart upon which the counters also maneuver, and is similarly large.

I’ve cleared the cashe several times and attempted to reload … at least half a dozen times. Did that before posting. Didn’t help.

I’ve never had any luck with cutting maps into several pieces and installing them in the way you describe. I haven’t once got that to work, so I don’t even do modules that have geomorphic boards. Another problem has been the inaccuracy of cutting a board up. They never seem to match up properly once that’s done.

Perhaps if someone could give me a hand with this, it would work.

Wait for a rewrite … that also isn’t a good thing for obvious reasons, you’ve got so much to do as it is, this is something that might take months before you find time.

Then you are doing it wrong. Sorry for being blunt. I and many other people have created hundreds of modules and don’t have a problem with this.

I am happy to look at your module and I am sure I could split the boards and get it set up correctly in an hour or so.

HOWEVER, having left the splitting of the board so late, then any assets such as Zones, Decks and At-start stacks will possibly now be in the wrong place and need adjusting. Depending on the number of these, there may potentially be work to do to get those re-positioned.

I would STRONGLY advise that you split the map, especially as you have developed this on a commercial basis and presumably would like more work in the future.

Regards.

The only commercial interest in this is a free game.

I can re-set the zones and at start stacks easily enough I think. I don’t know how a split board like that operates when it comes to numbered hex grids though. Maybe I can figure that out.

I appreciate your help. I did get the map split, though perhaps not exactly accurate. If you’d be so kind as to drop me an e-mail, I’ll send you a DropBox link with the map file and the module. I’ll combine them into a WinRar file to make it easier.

Thanks Much,
Tom
tdchistorian @ gmail.com

Yup, that’s my usual fee as well.

b.easton at exemail.com.au

For the hex grids, you need to create a separate hex grid for each (newly cut) board. You can usually just copy the existing grid from original map to each board, if the artist was accurate, that should still be the right size and you just slide it around to match.

Then you need to adjust the start numbers for the vertical/horizontal grid numbers to match the starting hex on each board. It’s confusing, because the grid numbering calculates itself based on the whole map, not the board and depending on the reverse options, you may need to enter quite large positive or negative numbers as the start numbers to get it to work. Keep playing until you get the reported grid numbers to match the printed grid numbers. You need to do this on each board.

The usual problem people have is that they try and cut the map through the hex centers. This nearly always ends badly.

Assuming the flat side of hex is horizontal, make the horizontal cut halfway between the hex centre and the hex edge. Make the vertical cut at the left (or right) end of the horizontal hex edge. This keeps the hex centers away from the split between boards and keeps the snapping and stacking working cleanly. The new map pieces do not need to be the same size. but obviously have to make up the complete map.

Apart from that, any good quality image processing program should allow you to drag out some visual guides, and then cut and paste each map section into a new image. With a map this large, it can be difficult to this cleanly by manual click and drag unless you are very careful and zoom in afterwards to check that your selection actually matches the guides. In the GIMP, you can zoom and manually adjust the selection after the drag select.

Alternatively, use the Canvas Size or equivalent dialog to cut out pieces of the correct size from the original map.

I usually use an individual part-map size of around 5000 x 3000, but that’s just by chance due to the hex size I use and the size of the individual maps in the project I was working on. For you, I would start with 4 maps 10Kx8K (ish) and see how that loads before doing any grid work. You might get away with that, but that is still on the large size. The more cuts, the more grid fiddling you have to do. Next step for me would be 8 maps 5K x 8K which I would expect to be fine.

What is you standard hex size out of interest? I use a 110 pixel flat to flat size with 75 pixel counters. Any bigger than that and I would consider scaling your artwork smaller.

Anyway, send the link and I am happy to have a look.

Regards,
Brent.

Try the most recent “retry_tiling” build, available here: vassalengine.org/builds/

The change you should see is that if the tiler runs out of memory, it will double its max heap and retry tiling up to two times. Please let me know how this works for you.

I concentrated upon completing the Custoza build without a hex grid. Just couldn’t get the thing to file with the full map, nor could I get the hex grid to work on the separate partial maps (I cut the main map into 8 pieces).

That said, I began building the next game. I began small by loading only the main map and a Chart Window Map. Saved it and opened it to tile the two images. There were only Two files requiring to be tiled. Wanted to do it this way so I could open Preferences and increase the heap size. Of course it not only didn’t tile, but it showed MULTIPLE tile failures. How this could be (there being over a dozen) when I installed only TWO files.

So, I downloaded your tiling update. It too failed to tile the two files.

What were the error messages? Where can I get the input that produced them?

(These will be the two questions I ask every single time.)

What was the result of loading the original Custoza module (the one you gave me via Dropbox) with the retry_tiling build?

The errors resulted in Eek Bug Reports, of which I assume you get reports. Of course I didn’t see exactly what the errors were because the Bug Report doesn’t tell us users what they are, not that we’d understand programmer-ese even if it did tell us.

Where can you get the input that produced them? Are you asking for copies of the module? I can load it to DropBox, but it’s got only two files in it.

The original Custoza file was not effected by the retry_tiling. Nor was the new La Belle Epoque module I’m building (the one with only two files loaded just to see if there would be problems … and there were). I did eventually get Epoque to load by removing the map, installing it with only the smaller Chart Window Map. Opening it with that loaded and changing the preferences to 2048. THEN I loaded the map and all was fine … so far.

We don’t collect error reports from test builds. The error dialog for test builds says that no report is being sent. Which version were you using when these errors occurred?

Also the bug report dialog does tell users what the exception was: Click “Display details” to expand the details display. That will show you the stack trace from the exception.

Yes, that’s exactly what I’m asking for. The best way to reduce the cycle time for this kind of troubleshooting is to provide the input when reporting the problem.

The retry_tiling build worked with the Custoza module you gave me when I tried it. I’d like to see an errorLog from a run of yours with a retry_tiling build where it failed with the original Custoza module. (This is essential for further progress.)

May I have a copy of the LBE module for which tiling failed?

It’s not surprising that you would have multiple missing tile errors if tiling an image fails, because the entire purpose of tiling is to slice large images into multiple small tiles.

BTW, I recommend not using JPEGs for game art if you can avoid it. The easiest place to see the effect of having converted to JPEG is the ringing around the hex coordinates in the lake in the upper left of the Custoza map. If you have a choice, use PNG for raster art and don’t convert to JPEG.

You will see the difference between the two modules. Epoque uses png because I received png files. Custoza I received jpg and couldn’t switch to png because it would have inflated the overall size of the module which was going to be very large as it was. To begin with the Custoza map file I received actually represents Two maps in the game box. So the actual maps are Two 24x32 maps, but the file I received contained both the east and west maps as One file. So everything sent me was jpg. I did my best to keep size down by maintaining the jpg “system” overall because the entire module size was going to be so big it wasn’t going to run well. I did the best I could given the tools I was provided. I even had to fight the rgb vs cmyk problem with these files. Custoza has been a real struggle.

I have both of them in my DropBox. Now the La Belle Epoque module is still in its beginning stages as I work on cutting counter tiles out of whole sheets, trying to understand a game system that is foreign to me (it’s a European style game, which I just do not play and do not understand). And am having to create artwork from whole cloth for things like Card Draw Maps to stick in Chart Windows because the game simply has you "pile money, cards, and “cubes” next to you on the table. There’s no place for them on the map. So I have to create those graphics. So, I’m barely into this module.

To whom do you wish me to send these dropbox links?

As I said, converting JPEGs to PNGs wouldn’t fix the problem—the damage would be carried over from the JPEG to the PNG. Since you were given JPEGs, there’s nothing straightforward you can do to clean up the artifacts.

Module size is only loosely related to performance. What in particular did you think wouldn’t run well?

To me, as before.

Regardless, there’s no additional progress I can make without an errorLog from a run of the retry_tiling build in which tiling failed. When you can get that to me, I’ll return to investigating the problem.

without an errorLog

Sorry, I didn’t keep them as I was able to work around the problems. I assumed they attached to the “eek bug reports”. Guess they don’t. Will have to wait for the next errors to appear.

Thanks Much,
Tom

They do, for released versions of VASASL. The retry_tiling build is a test build. Those do not generate bug reports for upload.

You needn’t wait. You could clear the tile cache and open the original Custoza module with the retry_tiling build. Based on what you’ve told me, that’s likely to produce the problem immediately. Please do this as soon as you can.

See vassalengine.org/wiki/Error_Logs for where to find the error log produced. Paste or attach it here.

I agree. You’ve made a valiant effort. Maybe when version 3.6 is provided for general use, I will revisit the Custoza module with the full scale single map file along with a numbered hex grid.

Thanks for your effort,
Tom