Once 3.1 settles down, how do you want to handle 3.2 development? Will the trunk stay at 3.1 with an official 3.2 branch? Or Branch off 3.1.x development and merge changes into a 3.2 trunk?
I’d prefer to have a patch branch for 3.1 and keep the trunk current,
though ultimately there’s not much difference between the two
suggestions—they’re isomorphic up to renaming.
What I would like is to have much less time elapse between 3.1 and 3.2
than between 3.0 and 3.1.
Do you mean that you have a ton of stuff that you’ll have ready by, say,
June? Or do you mean that you want the 3.2 release date to wait for that
ton of stuff? Or something else?
A lot of my plans are actually TODO comments in ADC2Module.java (things I wish I could have done and that would be pretty neat).
I think I’m committed to helping out with the OpenGL rendering as I was very interested in board rotation.
Another thing I want to work on is the CyberBoard and perhaps ZunTsu importers.
Brent, I’m very interested in your terrain work. I had been thinking about this as well, but I’m waiting to see what you’ve come up with. I had some good ideas for elevation that would go well with the OpenGL rendering.
That’s a big slate of jobs – might have to prioritise.
Have a look at the ‘A Victory Lost’ module. Go into the main map, open the Hex grid and click on Edit Grid. This is version 1, I have done more work since, adding ‘Tags’. Tags are additional attributes that can be hung off hexes, or off terrain types.
Exposing the terrain information has always been tricky and one of things that has been holding me back.
In AVL, the only thing directly available is that terrain of the current hex is available to units as the property $currentTerrain$. Apart from this, I access the map terrain directly with a custom component that generates an Area of Effect that is modified by the terrain.
In the newer version, the value of any tags attached to the hex will also be accessible by $<tag_name>$.
Even though I allow Hex Edge terrain to be defined, I am having trouble working out how to make this available to game components in a meaningful way. In AVL, I access it only by the custom component.
One though I had is to modify the PieceMover so that whenever a piece is moved one hex only, set the variable $lastEdgeTerrain$ to the name of the Edge Terrain passed over.
Good. We’ll get going on this as soon as 3.1.0 is done.
A ZunTzu importer could be done in an afternoon. There are maybe 10
kinds of XML elements it uses, and there’s a simple mapping from all
of their parts to ours.
Could you number the edges 0-5, so that 01.01.3 refers to a particular
hex side (from within a particular hex, since hex-side effects can be
can be asymmetric, e.g. things like steep slopes)?
You’re trying to kill me aren’t you. I take it that it’s just pieces and a board?
Technically the ADC2 importer is still not complete. I just finished hidden units on the weekend. However, I discovered what alliances do in ADC2 and they’re used more often than I thought. And then cards…
Pretty much (w/r/t the components, not trying to kill you). There are
dice, and a few things for cards. It’s completely trivial in terms of
the programming. It’s just writing the hooks for A SAX parser. I’ve
even started it, I could send you the code.
I found something quite handy on the GUI cleanup front this evening
while waiting to hear back about the Mac toolbar. The single biggest
problem thing we could do to improve the appearance of our GUI is to
use standard padding and inter-component spacing, and to get component
alignment and sizing right. As it happens, there’s a layout which
makes all of those things trivial: GroupLayout. It’s new to Java 1.6,
but there’s a Java 1.5 backport (like for SwingWorker), so we don’t
need to wait to use it.
It’s a bit hard to grasp at first, but without too much trouble I
was able to convert my username-and-password dialog to use it:
This is all of the layout code, and it produces the correct inter-component
spacing for the look-and-feel in use, the control buttons are the same size
and right-justified, the dialog has a border of the right width, and
everyting stretches exactly right. The only thing which is still wrong is
the alignment between the text fields and labels, but that’s because they’re
already wrapped in another component when I get them from the configurers.
The idea is that you do the layout vertical and horizontal layouts
independently. If you’re doing vertical layout, sequential group
contains items which you hit going from top to bottom, while a parallel
group sits in a slot in a sequential group and holds items which lie
along a horizontal line (and hence are met “in parallel” as you travel
from top to bottom). Same deal for the horizontal layout.
I’m looking foward to getting Configurers to return GroupLayout.Groups
so we can finally have proper component spacing and alignment. Most
Configurers are just a label and a field, so vertically are just a two-
item parallel group, and horizontally are a two-item sequential group.
I think it should be possible to merge these groups into a GroupLayout
held by the dialog which will display the configure controls.
If its useful perhaps we could also get this added in, with some sort of user option (?) when Vassal starts up asking the user if they wish to use comms or not in their game session or perhaps a preference setting maybe…