# ADC2 to VASSAL Coversion **URL:** \ **Category:** Feature Requests\ **Created:** [December 23, 2009, 10:50pm UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635 "2009-12-23T22:50:28Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![Charles\_McLellan](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/c/65b543/32.png) [@Charles\_McLellan](https://forum.vassalengine.org/u/Charles_McLellan)\ **Post date:** [December 23, 2009, 10:50pm UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/1 "2009-12-23T22:50:28Z")
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. ---
**Author:** ![mkiefte](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/mkiefte/32/25_2.png) [@mkiefte](https://forum.vassalengine.org/u/mkiefte)\ **Post date:** [December 24, 2009, 3:54pm UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/2 "2009-12-24T15:54:56Z")
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](mailto:messages@forums.vassalengine.org) ([messages@forums.vassalengine.org](mailto:messages@forums.vassalengine.org))\> > [@](#): > > 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. Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![Charles\_McLellan](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/c/65b543/32.png) [@Charles\_McLellan](https://forum.vassalengine.org/u/Charles_McLellan)\ **Post date:** [December 25, 2009, 1:04am UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/3 "2009-12-25T01:04:20Z")
Fourth try! – file stated as too big. Will post on sendspace. URL is [sendspace.com/file/jh2r7f](http://www.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. > [@](#): > > I’m having trouble understanding this. 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. ---
**Author:** ![Charles\_McLellan](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/c/65b543/32.png) [@Charles\_McLellan](https://forum.vassalengine.org/u/Charles_McLellan)\ **Post date:** [August 11, 2010, 9:14pm UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/4 "2010-08-11T21:14:51Z")
Any solution to this 2009 problem yet? ---
**Author:** ![Charles\_McLellan](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/c/65b543/32.png) [@Charles\_McLellan](https://forum.vassalengine.org/u/Charles_McLellan)\ **Post date:** [September 30, 2010, 7:17am UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/5 "2010-09-30T07:17:33Z")
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 ---
**Author:** ![tar](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/tar/32/21_2.png) [@tar](https://forum.vassalengine.org/u/tar)\ **Post date:** [September 30, 2010, 9:44pm UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/6 "2010-09-30T21:44:32Z")
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? ---
**Author:** ![Charles\_McLellan](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/c/65b543/32.png) [@Charles\_McLellan](https://forum.vassalengine.org/u/Charles_McLellan)\ **Post date:** [October 3, 2010, 6:02pm UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/7 "2010-10-03T18:02:14Z")
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. ---
**Author:** ![mkiefte](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/mkiefte/32/25_2.png) [@mkiefte](https://forum.vassalengine.org/u/mkiefte)\ **Post date:** [October 3, 2010, 8:24pm UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/8 "2010-10-03T20:24:36Z")
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](mailto: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. On 3 October 2010 15:02, cgmclellan \<[cgmclellan2000@knology.net](mailto: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. ---
**Author:** ![Charles\_McLellan](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/c/65b543/32.png) [@Charles\_McLellan](https://forum.vassalengine.org/u/Charles_McLellan)\ **Post date:** [October 4, 2010, 9:34pm UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/9 "2010-10-04T21:34:42Z")
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? ---
**Author:** ![tar](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/tar/32/21_2.png) [@tar](https://forum.vassalengine.org/u/tar)\ **Post date:** [October 4, 2010, 10:28pm UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/10 "2010-10-04T22:28:08Z")
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](http://www.vassalengine.org/wiki/Creating_Modules#What_is_the_buildfile_and_how_do_I_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. ---
**Author:** ![Charles\_McLellan](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/c/65b543/32.png) [@Charles\_McLellan](https://forum.vassalengine.org/u/Charles_McLellan)\ **Post date:** [October 4, 2010, 11:30pm UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/11 "2010-10-04T23:30:39Z")
> [@](#): > > Just out of curiosity, why did you decide to import this from ADC2 > instead of just using the native Vassal module? 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. ---
**Author:** ![Tim\_M](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/tim_m/32/2_2.png) [@Tim\_M](https://forum.vassalengine.org/u/Tim_M)\ **Post date:** [October 5, 2010, 3:20am UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/12 "2010-10-05T03:20:47Z")
> [@cgmclellan](#): > > 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? 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 ---
**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\ **Post date:** [October 5, 2010, 11:49am UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/13 "2010-10-05T11:49:42Z")
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. ---
**Author:** ![mkiefte](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/mkiefte/32/25_2.png) [@mkiefte](https://forum.vassalengine.org/u/mkiefte)\ **Post date:** [October 5, 2010, 12:04pm UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/14 "2010-10-05T12:04:00Z")
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](mailto: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. On 5 October 2010 08:49, Joel Uckelman \<[uckelman@nomic.net](mailto: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. ---
**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\ **Post date:** [October 5, 2010, 12:25pm UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/15 "2010-10-05T12:25:00Z")
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. ---
**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\ **Post date:** [October 5, 2010, 5:33pm UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/16 "2010-10-05T17:33:53Z")
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. ---
**Author:** ![tar](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/tar/32/21_2.png) [@tar](https://forum.vassalengine.org/u/tar)\ **Post date:** [October 5, 2010, 6:03pm UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/17 "2010-10-05T18:03:10Z")
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? ---
**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\ **Post date:** [October 5, 2010, 6:14pm UTC](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/18 "2010-10-05T18:14:01Z")
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.