ADC2 to VASSAL Coversion

When an ADC2 module that uses the same symbol name for two (or more) separate counters is converted to VASSAL, VASSAL only converts one symbol (image) for all counters. VASSAL does convert the separate counters, but uses the same image for all of them. So for example, the British unit ends up with the same colors as the German unit. This can be corrected in the ADC2 module, but I cannot figure out how to correct or change counters in VASSAL module.

It would be best if VASSAL can convert the images actually used for each ADC2 Class, rather than Symbol name, so that the images are correct.

I’m having trouble understanding this.

Why would a module use the same symbol name for totally different counters? What is going on in ADC2?

Can you send me a link to the module you’re referring to?

• M.

2009/12/23 Charles McLellan <messages@forums.vassalengine.org (messages@forums.vassalengine.org)>

Post generated using Mail2Forum (mail2forum.com)

Fourth try! – file stated as too big. Will post on sendspace. URL is sendspace.com/file/jh2r7f

Third try!

I hate it when I type a whole thing out and then lose it when I had to sign in again. This is the second try.

There are three names used in ADC2: Symbol Name, Class Name, and Piece Name. There is no prohibition against using the same name in all cases, but it could create confusion if there were a lot of units with the same name or a high counter density. In this specific case, “Sup (0-0-10)” was the Symbol Name used for both the British and German supply units. This did not cause any confusion because both were of different colors and there were only two images for supply units. “Supply” was used for the Class Name for both. Again little confusion in this case because the “Player” was different for each. Piece Names were also the same: “1,” “2,” etc.

When I imported the ADC2 module into VASSAL, the VASSAL module Inventory List contained the two separate supply units (German and British), but used the same image for both. Unzipping and checking the “.mod,” I saw only one image “Sup (0-0-10)” was there. The VASSAL program apparently considered that two images with the same Symbol Name were duplicates and only imported one or overlaid the first image with the second. As the VASSAL Inventory List does contain two supply units – one for the British and one for the German – apparently, the Class Names were imported correctly and there was only a problem with image imports from the ADC2 Symbol List.

(In the module, there is also a “Sup (0-0-10)a” which is an alternate colored supply unit used for a flip side. The same situation occurred with this counter. The German alternate side supply was used for British as well as the German.)

I did not detect the problem initially when I viewed the converted VASSAL module because the British supply unit was covered by another British unit.

I tried various things to correct the counter in the VASSAL module, but knowing nothing about VASSAL my attempts came to nothing. Ultimately, I just changed the ADC2 module giving separate names for both Symbol and Class and imported again. That seemed to do the trick, but as I had already corrected the converted VASSAL map, I sought a method to update the new map without going through the lengthy process of numbering each hex grid again. I only mentioned the counter problem in passing.

I have the original Imported VASSAL module. I did however, add a new unit “Sup2 (0-0-10)” to trick the VASSAL system into showing a second image for supply units. VASSAL was not fooled. I am going to try to attach this file if I can figure out how to do it. If not, I will post it on “sendspace.” I tried posting an image on “sendspace” and while it worked in the preview, it did not show in the forum. I posted its URL in a previous message. Sending the ADC2 file would not help because I changed both the Symbol and Class Names before making a corrected import.

Any solution to this 2009 problem yet?

Hello! Is anybody reading these things? Does anyone have a further question about what I am asking or a method to fix this problem?

Can a map be imported from one module to another?

Can units in a module be corrected?

Can new units be added to an existing module?

Any solution to these question could solve the problem.

Thanks, cgm

On Sep 30, 2010, at 12:17 AM, cgmclellan wrote:

Hello! Is anybody reading these things? Does anyone have a further
question about what I am asking or a method to fix this problem?

Can a map be imported from one module to another?

Well, not directly.

But if you extract the map image from one module, you could add that
image as a new map in another module using the module editor.

Can units in a module be corrected?

I would think so, again by using the module editor.

Can new units be added to an existing module?

Yes. Open it with the module editor and create the new units.

Or have you tried these things and run into trouble?

Thanks,

Basically, you’ve said that it can be done, but not how it can be done.

Can you give a few hints as to where I can find out how to do any of this in English? I do not understand computer things.

If you open up the VMOD file just like a ZIP file, you’ll see that it has a
directory structure. Inside there, you’ll see an “images” directory. The
map is one of the files in there.

If you’re using Windows, you’ll have to tell your computer that you wish to
open the file just like a ZIP file. Pull the map image out and use that in
another module.

If you want to combine scenarios from the same game, one thing that will
very likely work is to open each scenario as a separate module, save the
game once it’s started (as an observer) and use those saved games as
predifined saved games in the module editor.

That’s going to work 90% of the time. It won’t work when the scenarios use
very different maps. At that point, there’s no real advantage in combining
them.

• M.

On 3 October 2010 15:02, cgmclellan cgmclellan2000@knology.net wrote:

Thanks,
Basically, you’ve said that it can be done, but not how it can be
done.

Can you give a few hints as to where I can find out how to do any of
this in English? I do not understand computer things.

If you open up the VMOD file just like a ZIP file, you’ll see that it has a directory structure.� Inside there, you’ll see an “images” directory.� The map is one of the files in there.

If you’re using Windows, you’ll have to tell your computer that you wish to open the file just like a ZIP file.� Pull the map image out and use that in another module.


If you want to combine scenarios from the same game, one thing that will very likely work is to open each scenario as a separate module, save the game once it’s started (as an observer) and use those saved games as predifined saved games in the module editor.


That’s going to work 90% of the time.� It won’t work when the scenarios use very different maps.� At that point, there’s no real advantage in combining them.

- M.

I am going to need to explain myself better in regards to the map.

It is not the “image” of a map that I want to use in another module, it is the grid coordinates. The map images are the same in both modules.

As I reported once before, the supply units in an Afrika Korps module imported from ADC2 were not imported correctly. Both the German and the Allied supply units used the same image – the German one. I did not discover this until after I had gone over the whole Afrika Korp map – all 2500+ hexes – establishing the grid coordinates as irregular grid. This is an exhaustive, manual task requiring many strokes to change a single coordinate – well over 50,000 clicks. I changed the Symbol Names in the ADC2 module and imported the module again. Now the units are correct, but this map does not have the grid coordinates that I laboriously established on the former AK map.

I do not want to go through the process of doing all those coordinates again.

Is there any way to transfer the map with the grid coordinates (or just the coordinates) from one map to the other?

On Oct 4, 2010, at 2:34 PM, cgmclellan wrote:

I am going to need to explain myself better in regards to the map.

It is not the “image” of a map that I want to use in another module,
it
is the grid coordinates. The map images are the same in both modules.

As I reported once before, the supply units in an Afrika Korps module
imported from ADC2 were not imported correctly.

Just out of curiosity, why did you decide to import this from ADC2
instead of just using the native Vassal module?

Both the German and the
Allied supply units used the same image – the German one. I did not
discover this until after I had gone over the whole Afrika Korp map –
all 2500+ hexes – establishing the grid coordinates as irregular
grid.
This is an exhaustive, manual task requiring many strokes to change a
single coordinate – well over 50,000 clicks. I changed the Symbol
Names
in the ADC2 module and imported the module again. Now the units are
correct, but this map does not have the grid coordinates that I
laboriously established on the former AK map.
I do not want to go through the process of doing all those coordinates
again.

I can understand that.

It looks like the native Vassal module includes custom code for
handling the oblique hex grid numbering system. [Is that planned to
migrate into the main Vassal trunk, or are there too few classic
Avalon Hill games to make it worthwhile?]

Is there any way to transfer the map with the grid coordinates (or
just
the coordinates) from one map to the other?

My guess is that the simplest way to do this would involve manually
editing the build file. There are some brief instructions at

vassalengine.org/wiki/Creati … edit_it.3F

Make sure you do the editing on a COPY of the module, since making a
mistake in the manual editing can make the module unloadable and maybe
unrecoverable.

If by native you are meaning the existing VASSAL module, yes. I thin that the one that I made in ADC2 is better and offers more than the “native” one.

So as not to have to redo the map again, or have to do a build edit (would not recommend for vassal novices), instead take your 2nd created version with the corrected units, unzip it and grab the correct images you need and replace them as needed in your original module creation by using the module editor.

Just go to the piece with the incorrect image, double click the image/basic piece/layer/whatever and replace with the correct one.

That would probably be a lot less work unless we are talking 50+ messed up counters, less than 30 or so though this would be a lot quicker and easiest solution

Thus spake Thomas Russ:

It looks like the native Vassal module includes custom code for
handling the oblique hex grid numbering system. [Is that planned to
migrate into the main Vassal trunk, or are there too few classic
Avalon Hill games to make it worthwhile?]

It’s something which people ask for enough that it should become a standard
part of VASSAL eventually.

A good time to do that would be when the hex grid code is next reworked.
It’s an awful mess presently—it contains a lot of cut-and-paste code
and dodgy math—but it’s also rather self-contained, so wouldn’t be that
big of a job for somebody who wanted to do it.

The code needs to be sepearated into more parts:

• An interface for hex grid numberings
• Concrete implementations of hex grid numberings
• An interface for classes which draw hex grid numberings
• A class for hex grids
• An interface for classes which draw hex grids
• Concrete implementations of classes which draw hex grids

Essentially what I’m envisioning is that you’d implement the HexGridNumbering
interface for each different numbering scheme you wanted, and then a HexGrid
would have a HexGridNumbering as a member. A good start would be to do just
this part. I don’t have time for it right now myself, but this would be a
great small project for someone who would like to contribute.

–
J.

I understand where you’re coming from Joel. However, the current code works
and there’s nothing really wrong with it other than it’s unpleasant to look
at. Might it not be easier just to hack something in?

I know that sounds bad, but, really, this issue has been hanging over us for
years(?). Didn’t Tim or someone have a partial implementation already?

• M.

On 5 October 2010 08:49, Joel Uckelman uckelman@nomic.net wrote:

Thus spake Thomas Russ:

It looks like the native Vassal module includes custom code for
handling the oblique hex grid numbering system. [Is that planned to
migrate into the main Vassal trunk, or are there too few classic
Avalon Hill games to make it worthwhile?]

It’s something which people ask for enough that it should become a standard
part of VASSAL eventually.

A good time to do that would be when the hex grid code is next reworked.
It’s an awful mess presently—it contains a lot of cut-and-paste code
and dodgy math—but it’s also rather self-contained, so wouldn’t be that
big of a job for somebody who wanted to do it.

The code needs to be sepearated into more parts:

• An interface for hex grid numberings
• Concrete implementations of hex grid numberings
• An interface for classes which draw hex grid numberings
• A class for hex grids
• An interface for classes which draw hex grids
• Concrete implementations of classes which draw hex grids

Essentially what I’m envisioning is that you’d implement the
HexGridNumbering
interface for each different numbering scheme you wanted, and then a
HexGrid
would have a HexGridNumbering as a member. A good start would be to do just
this part. I don’t have time for it right now myself, but this would be a
great small project for someone who would like to contribute.

I understand where you’re coming from Joel.� However, the current code works and there’s nothing really wrong with it other than it’s unpleasant to look at.� Might it not be easier just to hack something in?�


I know that sounds bad, but, really, this issue has been hanging over us for years(?).� Didn’t Tim or someone have a partial implementation already?

- M.

Thus spake Michael Kiefte:

I understand where you’re coming from Joel. However, the current code works
and there’s nothing really wrong with it other than it’s unpleasant to look
at. Might it not be easier just to hack something in?

I’ll bet that it wouldn’t be hard to find a whole slew of corner cases
in the current code which don’t work. If I were going to do this myself,
I wouldn’t be able to add a new grid numbering without disentangling all
the parts first, because without doing that I wouldn’t be able to test
that the new code worked or that I hadn’t broken the old code.

This must be disentangled when we do the model/view separation anyway,
so if somebody is going to work on it, this will make the code more
future-proof.

I know that sounds bad, but, really, this issue has been hanging over us for
years(?). Didn’t Tim or someone have a partial implementation already?

Well, that doesn’t make it not an issue.

–
J.

Thus spake Joel Uckelman:

Thus spake Thomas Russ:

It looks like the native Vassal module includes custom code for
handling the oblique hex grid numbering system. [Is that planned to
migrate into the main Vassal trunk, or are there too few classic
Avalon Hill games to make it worthwhile?]

It’s something which people ask for enough that it should become a standard
part of VASSAL eventually.

A good time to do that would be when the hex grid code is next reworked.
It’s an awful mess presently—it contains a lot of cut-and-paste code
and dodgy math—but it’s also rather self-contained, so wouldn’t be that
big of a job for somebody who wanted to do it.

The code needs to be sepearated into more parts:

• An interface for hex grid numberings
• Concrete implementations of hex grid numberings
• An interface for classes which draw hex grid numberings
• A class for hex grids
• An interface for classes which draw hex grids
• Concrete implementations of classes which draw hex grids

Essentially what I’m envisioning is that you’d implement the HexGridNumbering
interface for each different numbering scheme you wanted, and then a HexGrid
would have a HexGridNumbering as a member. A good start would be to do just
this part. I don’t have time for it right now myself, but this would be a
great small project for someone who would like to contribute.

Thinking about this a bit more:

CoordinateSystem should have something like the following methods:

Coordinate toCoordinate(Point p)

Point toPoint(Coordinate c)

where the first translates a point in the plane to numeric hex
coordinates, and the second translates numeric hex coordinates to
the center point of that hex. I’m unsure what Cooordinate should be
like, since we might want to support a 3-axis coordinate system.

–
J.

On Oct 5, 2010, at 10:33 AM, Joel Uckelman wrote:

Thus spake Joel Uckelman:

Thus spake Thomas Russ:

It looks like the native Vassal module includes custom code for
handling the oblique hex grid numbering system. [Is that planned to
migrate into the main Vassal trunk, or are there too few classic
Avalon Hill games to make it worthwhile?]

It’s something which people ask for enough that it should become a
standard
part of VASSAL eventually.

A good time to do that would be when the hex grid code is next
reworked.
It’s an awful mess presently—it contains a lot of cut-and-paste
code
and dodgy math—but it’s also rather self-contained, so wouldn’t
be that
big of a job for somebody who wanted to do it.

The code needs to be sepearated into more parts:

• An interface for hex grid numberings
• Concrete implementations of hex grid numberings
• An interface for classes which draw hex grid numberings
• A class for hex grids
• An interface for classes which draw hex grids
• Concrete implementations of classes which draw hex grids

Essentially what I’m envisioning is that you’d implement the
HexGridNumbering
interface for each different numbering scheme you wanted, and then
a HexGrid
would have a HexGridNumbering as a member. A good start would be to
do just
this part. I don’t have time for it right now myself, but this
would be a
great small project for someone who would like to contribute.

Thinking about this a bit more:

CoordinateSystem should have something like the following methods:

Coordinate toCoordinate(Point p)

Point toPoint(Coordinate c)

where the first translates a point in the plane to numeric hex
coordinates, and the second translates numeric hex coordinates to
the center point of that hex. I’m unsure what Cooordinate should be
like, since we might want to support a 3-axis coordinate system.

And how does this all interact with the named regions or irregular
grid items? Is there some unification possible for that?

Thus spake Thomas Russ:

CoordinateSystem should have something like the following methods:

Coordinate toCoordinate(Point p)

Point toPoint(Coordinate c)

where the first translates a point in the plane to numeric hex
coordinates, and the second translates numeric hex coordinates to
the center point of that hex. I’m unsure what Cooordinate should be
like, since we might want to support a 3-axis coordinate system.

And how does this all interact with the named regions or irregular
grid items? Is there some unification possible for that?

I don’t see any reason why it wouldn’t be possible to use a similar
(or maybe the same) interface for those.

–
J.