# Oblique Hex-grid Numbering uploaded **URL:** \ **Category:** Development\ **Created:** [December 15, 2010, 9:04am UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498 "2010-12-15T09:04:00Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![pgeerkens](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/pgeerkens/32/117_2.png) [@pgeerkens](https://forum.vassalengine.org/u/pgeerkens)\ **Post date:** [December 15, 2010, 9:04am UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/1 "2010-12-15T09:04:00Z")
## If I had known how much work it would turn out to be, Imight have chosen another first projecty. However it is done now, and it was a great learning experience for Java and VASSAL. I have checked it in under the branch pgeerkens, down in …/mapgrid. HexGridNumberingX is ready for prime-time, as an extension of HexGridNumbering that: 1. Implements Oblique hex-grid numbering for all cases; and 2. Eliminates the earlier design choice to implement the pick-window for hexes as a cleverly-crafted rectangle. Each hex now has a pick-window that exactly matches its interior. HexGridNumberingX can also be added to a VASSAL module as a custom class, without any need to edit the build file. This took some work, as the implementation of HexGridNumbering was having its Configurer(), and hence its forceDraw(), method invoked before the private variable grid had been defined by addToParent(). The work-around was to override Configurer(), invoking super.Configurer() only if getGrid() returns non-null. This seems to work fine. Part of why this was such a bugger is that there are unchecked references to ex.getMessage() that were causing a Null Pointer Exception, erasing memory of the Null Pointer Exception that had caused the Exception call. I will be looking for, and writing if I don’t find it, a function as follows: String ifNull (String msg) { return (msg == null) ? “” : msg; } to simplify writing of robust Exception Handling (in my own code at least). ---
**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:** [December 15, 2010, 10:17am UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/2 "2010-12-15T10:17:46Z")
Thus spake pgeerkens: > If I had known how much work it would turn out to be, Imight have chosen > another first projecty. However it is done now, and it was a great > learning experience for Java and VASSAL. I have checked it in under the > branch **pgeerkens** , down in …/mapgrid. You didn’t commit what you intended to commit. 7570 doesn’t have any code in it. – J. ---
**Author:** ![pgeerkens](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/pgeerkens/32/117_2.png) [@pgeerkens](https://forum.vassalengine.org/u/pgeerkens)\ **Post date:** [December 15, 2010, 11:12am UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/3 "2010-12-15T11:12:37Z")
I will track it down - I am new to Subversion. Thank you. ---
**Author:** ![pgeerkens](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/pgeerkens/32/117_2.png) [@pgeerkens](https://forum.vassalengine.org/u/pgeerkens)\ **Post date:** [December 15, 2010, 11:18am UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/4 "2010-12-15T11:18:26Z")
OK That should have resolved it. The little black star beside my folders has disappeared now. ![;-)]( "Wink") Also, there is a comprehensive test bed included in the module for the use of anyone who wants to try it out. The old AH games all need oblique numbering. Pieter ---
**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:** [December 15, 2010, 11:20am UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/5 "2010-12-15T11:20:41Z")
Thus spake pgeerkens: > I will track it down - I am new to Subversion. Thank you. No problem. (Don’t get too comfortable—I was thinking of suggesting that we switch to git for version control sometime in the near future…) – J. ---
**Author:** ![pgeerkens](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/pgeerkens/32/117_2.png) [@pgeerkens](https://forum.vassalengine.org/u/pgeerkens)\ **Post date:** [December 15, 2010, 11:28am UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/6 "2010-12-15T11:28:10Z")
Don’t do that ![;-)]( "Wink") I remember when RCS was an improvement to SCCS. The one thing definitely worse than the second best version/configuration solution, is a solution that no-one is comfortable with. Pieter ---
**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 15, 2010, 11:54am UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/7 "2010-12-15T11:54:45Z")
> The one thing definitely worse than the second best > version/configuration solution, is a solution that no-one is comfortable > with. I suggest GoogleDocs. - M. ---
**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:** [December 15, 2010, 12:45pm UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/8 "2010-12-15T12:45:26Z")
Thus spake pgeerkens: > OK That should have resolved it. The little black star beside my folders > has disappeared now. 😉 Some initial comments on your code: 1. Don’t use “” + foo to convert foo to a String. Use String.valueOf(), it’s more efficient. 1. Don’t use ‘new Boolean()’, ever. There are only two possible Boolean values, and instances of them already exist; creating more only makes more work for the garbage collector. If you want to get a Boolean from a String, use Boolean.valueOf(). 2. Use prefix ++ and – unless you actually need the values returned first. 3. Any variable which you’re not going to reassign should be final. I’ll try to make a more thorough review soon. > Also, there is a comprehensive test bed included in the module for the > use of anyone who wants to try it out. The old AH games all need oblique > numbering. Tests belong under the test/ hierarchy. (Note that this is not yet observed everywhere—there are still some tests floating around under src/, which still need to be moved.) – 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:** [December 15, 2010, 12:48pm UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/9 "2010-12-15T12:48:00Z")
Thus spake Michael Kiefte: > > The one thing definitely worse than the second best > > version/configuration solution, is a solution that no-one is comfortable > > with. > > I suggest GoogleDocs. You’re funny, Michael. – J. ---
**Author:** ![pgeerkens](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/pgeerkens/32/117_2.png) [@pgeerkens](https://forum.vassalengine.org/u/pgeerkens)\ **Post date:** [December 15, 2010, 1:44pm UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/10 "2010-12-15T13:44:17Z")
Thank you for the quick feedback. I have made the changes you requested, but need a little time to get my test bed working again - the test hierarchy needs to be tweaked a bit. I will upload again soon. #3 may take a little getting used to, as I have a 20 year habit of writing i++ except when I absolutely require --i. ---
**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 15, 2010, 1:49pm UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/11 "2010-12-15T13:49:28Z")
Joel, I agree with everything you’ve said here and much of it carries over from C. But it makes me wonder, does the Java compiler optimise all this anyway? - M On 15 December 2010 11:25, Joel Uckelman [uckelman@nomic.net](mailto:uckelman@nomic.net) wrote: > Thus spake pgeerkens: > > > OK That should have resolved it. The little black star beside my folders > > has disappeared now. 😉 > > Some initial comments on your code: > > 1. Don’t use > > “” + foo > > to convert foo to a String. Use String.valueOf(), it’s more efficient. > > 1. Don’t use ‘new Boolean()’, ever. There are only two possible Boolean > values, and instances of them already exist; creating more only makes > more work for the garbage collector. If you want to get a Boolean from > a String, use Boolean.valueOf(). > > 2. Use prefix ++ and – unless you actually need the values returned > first. > > 3. Any variable which you’re not going to reassign should be final. > > I’ll try to make a more thorough review soon. > > > Also, there is a comprehensive test bed included in the module for the > > use of anyone who wants to try it out. The old AH games all need oblique > > numbering. > > Tests belong under the test/ hierarchy. (Note that this is not yet observed > everywhere—there are still some tests floating around under src/, which > still need to be moved.) > > – > 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:** [December 15, 2010, 2:01pm UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/12 "2010-12-15T14:01:27Z")
Thus spake Michael Kiefte: > Joel, > > I agree with everything you’ve said here and much of it carries over from C. > > But it makes me wonder, does the Java compiler optimise all this anyway? ‘new Boolean’ it definitely doesn’t optimize away. (The fact that there’s even a public ctor for Boolean is a bug, in my opinion.) I believe String conversion using “” + ends up happening via a StringBuilder, while something more efficient can happen if you use String.valueOf(). – J. ---
**Author:** ![pgeerkens](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/pgeerkens/32/117_2.png) [@pgeerkens](https://forum.vassalengine.org/u/pgeerkens)\ **Post date:** [December 15, 2010, 3:11pm UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/13 "2010-12-15T15:11:57Z")
Yes, the extent of optimizations is limited by the fact that only partial compilation is occurring, and run-time binding must be allowed for. Also, the more completely the programmer describes and constrains the solution, the less likely it is that erros occur later. ---
**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:** [December 15, 2010, 4:54pm UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/14 "2010-12-15T16:54:39Z")
> [@pgeerkens](#): > > ## If I had known how much work it would turn out to be, Imight have chosen another first projecty. However it is done now, and it was a great learning experience for Java and VASSAL. I have checked it in under the branch pgeerkens, down in …/mapgrid. > > HexGridNumberingX is ready for prime-time, as an extension of HexGridNumbering that: > > 1. Implements Oblique hex-grid numbering for all cases; and > 2. Eliminates the earlier design choice to implement the pick-window for hexes as > a cleverly-crafted rectangle. Each hex now has a pick-window that exactly matches its interior. > > HexGridNumberingX can also be added to a VASSAL module as a custom class, without > any need to edit the build file. This took some work, as the implementation of HexGridNumbering > was having its Configurer(), and hence its forceDraw(), method invoked before the private variable > grid had been defined by addToParent(). The work-around was to override Configurer(), invoking > super.Configurer() only if getGrid() returns non-null. This seems to work fine. > > Part of why this was such a bugger is that there are unchecked references to ex.getMessage() that > were causing a Null Pointer Exception, erasing memory of the Null Pointer Exception that had > caused the Exception call. I will be looking for, and writing if I don’t find it, a function as > follows: > > String ifNull (String msg) { > return (msg == null) ? “” : msg; > } > > to simplify writing of robust Exception Handling (in my own code at least). It might be worth knowing that the classes for Oblique Hex grid numbering had already been written as custom class imports, they just had not been included with standard Vassal for whatever reason… An interesting exercise might be to compare these already written classes with what you’ve come up with for fun and giggles. The two classes, HexGridNumbering.java and ObliqueHexGridNumbering.java can be found in the VQSL-src/trunk/afk directory in the repository ---
**Author:** ![pgeerkens](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/pgeerkens/32/117_2.png) [@pgeerkens](https://forum.vassalengine.org/u/pgeerkens)\ **Post date:** [December 15, 2010, 5:15pm UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/15 "2010-12-15T17:15:38Z")
Yes, I actually started from Brent’s implementation of ObliqueHexGridNumbering in the Afrika Korps module. However his approach was the more practical one of tackling the multiple scenarios singly, as needed for each game, and Waterloo needed settings not available in the Afrika Korps implementation. Then I discovered some subtle bugs and short-cuts in the HexGridNumbering, followed by the inability to auto-load from the Editor, and with the goal of learning quickly more about both Java and VASSAL I accepted the challenge of producing a single class that implements every hex-grid numbering known to man (any Vulcans out there?). While I do not claim to have fully succeeded, the work is good and I know a lot more Java and VASSAL now. Pieter ---
**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:** [December 15, 2010, 8:39pm UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/16 "2010-12-15T20:39:55Z")
I’ve run out of time this evening to finish reviewing your patch, unfortunately. Your code looks ok, on the whole, but what this has reminded me of is what an awful mess the existing grid code is generally. We had a discussion about this a few months ago: [https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/1](https://forum.vassalengine.org/t/adc2-to-vassal-coversion/2635/1) Adding more grid code without refactoring sends us further down the rabbit hole. I think a large part of the difficulties you had in extending HexGridNumbering stem from it’s kitchen-sink design. This is one of those places where it would be relatively easy to disentangle all of the parts so that everything is coded to an interface and each class does one thing, and also write unit tests for them. Would you be interested in doing this if I helped you get started? ---
**Author:** ![pgeerkens](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/pgeerkens/32/117_2.png) [@pgeerkens](https://forum.vassalengine.org/u/pgeerkens)\ **Post date:** [December 15, 2010, 8:56pm UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/17 "2010-12-15T20:56:38Z")
When you flatter me like that, how can I say no. ![;-)]( "Wink") Yes, I believe you are correct, and I could spend some time to at least get it properly started. Pieter ---
**Author:** ![pgeerkens](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/pgeerkens/32/117_2.png) [@pgeerkens](https://forum.vassalengine.org/u/pgeerkens)\ **Post date:** [December 16, 2010, 7:02am UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/18 "2010-12-16T07:02:31Z")
For Hex-Grid-Numbering, one issue is the staggering number of scenarios to be be verified on every code change. The independent switches are these: 1. Oblique/Standard 2. H-Descending 3. V-Descending 4. Sideways 5. Reversed 6. Stagger (if Standard) or NW\_SE (if oblique) 7. MaxRows odd/even 8. Mox Columns odd/even 9. MaxObliques odd/even (if oblique) Then for each test case you need to check a minimum of 4 points, to have odd & even rows and columns checked. By my count this makes for (128 + 64) \* 4 = 768 opportunites on evey code change to break an existing module. ---
**Author:** ![pgeerkens](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/pgeerkens/32/117_2.png) [@pgeerkens](https://forum.vassalengine.org/u/pgeerkens)\ **Post date:** [December 16, 2010, 7:16am UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/19 "2010-12-16T07:16:04Z")
Okay, maybe Reversed can be left out of this chain, but that is still 384 cases to be checked on. To be practical one would need an automated regression suite: a) probably 6 different grids, to capture these: \_\_\_\_7) MaxRows odd/even \_\_\_\_8) Mox Columns odd/even \_\_\_\_9) MaxObliques odd/even (if oblique) b) some means of efficiently selecting points to ensure coverage of this: \_\_\_\_minimum of 4 points, to have odd & even rows and columns checked c) a test engine to run through these 64 cases for each grid, for the entire point set selected. \_\_\_\_1) Oblique/Standard \_\_\_\_2) H-Descending \_\_\_\_3) V-Descending \_\_\_\_4) Sideways \_\_\_\_5) Reversed \_\_\_\_6) Stagger (if Standard) or NW\_SE (if oblique) Then one outputs the entire set as a suite of reports, that can be text-differenced to the standard and manually checked set. By checking in each small, self-contained, change independently, and running the test suite on each build, one can get an email each morning announcing whicn code changes broke which test-cases. Before one even has time to forget why one made the change. Some work to set up, but it is a real charmer once set-up. I had the privilege of creating this for the report engine that I built in the '90’s. Pieter ---
**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:** [December 16, 2010, 7:58am UTC](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498/20 "2010-12-16T07:58:13Z")
Thus spake pgeerkens: > By checking in each small, self-contained, change independently, and > running the test suite on each build, one can get an email each morning > announcing whicn code changes broke which test-cases. Before one even > has time to forget why one made the change. > > Some work to set up, but it is a real charmer once set-up. I had the > privilege of creating this for the report engine that I built in the > '90’s. It isn’t necessary to build a system like this from scratch. It already exists. We have a testing framework (JUnit). If you’re using the Makefile for building, you can run all of the tests using ‘make test’. There’s some way to do that from Eclipse, as well, in case you’re using that. You don’t need to wait for an automated system to notify you—you can run the tests immediately. There’s also Hudson, which is a continuous integration framework. It will email you when tests fail. Right now, we’re using a Hudson instance that Ken set up, but sometime in the new year we’ll have our own at [vassalengine.org](http://vassalengine.org). – J. [Next page](https://forum.vassalengine.org/t/oblique-hex-grid-numbering-uploaded/3498.md?page=2)