How have we done in addressing things which received a lot of votes? Here
are the top 20, with my annotations for what I think the current state is:
[3.1] make VASSAL faster, more responsive
[+] update VASSAL documentation
[?] A Moving stack should not pick up other counters from stacks
[0%] LOS determined by terrain
[0%] Victory Point Tracker
[0%] reveal hidden pieces based on LOS or range
[3.2] VCR buttons for log history navigation
[0%] Show different Map orientations to different players
[0%] LOS Enhancements - Reporting/Visibility/Snapping
[0%] Chess Clock
[0%] hot seat mode
[0%] Movement Step Counter
[3.1] Zoomingto larger than 100%
[0%] Drag mouse to scroll in Map Window
[0%] Mouse over showing properties
[0%] show die faces as images in log pane
[20%] Whiteboard component
[70%] secure external dice roller plugin
[?] cut and paste traits
[?] module and logfile management tools
[0%] allow player to join more than one side
What I’ve marked “3.1” is already done. What I’ve marked “3.2” is something
I know is scheduled for 3.2. Other things are marked with how far along I
think they are or “?” because I don’t know.
The number of these which we’ve completed is better than it looks, I think,
as some of the very difficult RFEs clustered toward the top (LOS stuff, e.g.)
and we’ve also knocked off many, many RFEs lower down the list.
[3.0] A Moving stack should not pick up other counters from stacks
[25%] LOS determined by terrain
[50%] Victory Point Tracker
[3.0] LOS Enhancements - Reporting/Visibility/Snapping
[3.0] cut and paste traits
I was interested in tackling the per-player orientation feature.
That’s a biggie for me. I was also interested in the mouse-over
terrain properties feature, but that seems like a big job.
Why does anyone want greater than 100% zoom? It’s all raster
graphics. Am I missing something?
Mouse-over terrain properties would require a way of setting terrain
properties per-hex. Someday I’d like to add this feature to mkhexgrid
and then get VASSAL to read mkhexgrid output. That would give you
something a lot like what you can produce with the Cyberboard map editor,
but in SVG.
With per-player orientation, I assume that what’s wanted is a top-bottom
flip. All you’d need to do (visually) for that is have a switch which
would add 180 degrees to the map rotation and 180 degrees to piece rotation
about their respective centers. I don’t know what this would screw up
w/r/t anything else. This could be easy or hard, I don’t know.
It’s not all raster graphics. VASSAL handles SVG since 3.0. Some
modules have bitmaps with tiny, but relevant, features. Some people
have bad eyes. The pixels on my laptop LCD panel are smaller the the
pixels on my desktop monitor, so occasionally I’ve had the desire
to soom in a bit more when using my laptop. Anyway, you get zooming
in more than 1:1 for free due to the zooming work I did for 3.1.
Also, keep in mind that I only listed the top 20 vote getters because
I was tired of typing—the curve of results is pretty smooth, so there
are lots of other much-desired RFEs which fall only a little below the
top 20 in terms of votes received. I’m not suggesting that we focus
on these exclusively for 3.2.
I have done a lot of the work to support this in Vassal already. It is all installed as custom code in the A Victory Lost module.
If you download AVL and edit the hexgrid, you will find it has a Terrain editor which allows you to define different Terrain types and paint them over the Board. It currently supports Full-Hex Terrain and Edge Terrain. My plans are to include Line Terrain (e.g. roads) and Attributed Point errain (e.g. attach named properties to specific hexes). Internally, it uses raw row/column addressing and stores the terrain data in a Text file in the module. It would be trivial to import terrain data from other formats.
In AVL I use the data in a custom Java component to generate Command Range Ares of Effect that are moderated by terrain, and them moderate a Global Key Command. This allows HQ units to activate dependent units within their terrain affected command radius.
I have not done a lot with this, mainly because of the difficulty of exposing the terrain data to other components in an easily accessible way.
I was wondering if that was possible myself. I think it would do a great deal to the over-all experience to be able to see the board from your point of view. Now I’m not a programmer so I can’t say if it’s hard to do, but it’s a feature I’d love to see.
There are a number of issues involved with this – not just drawing the map. It has to be put back to 3.2 though as I’m not willing to do this before 3.1beta1, but it is definitely high priority for me. I may also have to coordinate this with Joel if he’s got some graphics related changes in mind. We should probably make a rotation branch.
What I had in mind was actually 90, -90, 180 degree rotations as some games I’m interested in are definitely side-to-side and many people play them that way. There are some additional features that are going to be needed above and beyond this as well if people actually plan to use this. In the next couple of weeks, depending on some external factors, I’m hoping to start tackling this. In the mean time, there are still bugs to be fixed.
I think it would be a waste of time to start working on this before I
try out JOGL, since how this would be done with JOGL is completely
different for how it woudl be done without it.
There’s 2 ways to look at this: Implementing rotation is going to be a
lot easier than redoing the graphics in VOGL. That being said, I can
certainly help either way as I have some experience with OpenGL.
One thing I had in mind was implementing elevation as a bumpmap which
would work exceptionally well with VOGL.
–
Michael Kiefte, Ph.D.
Associate Professor
School of Human Communication Disorders
Dalhousie University
Halifax, Nova Scotia, Canada
tel: +1 902 494 5150
fax: +1 902 494 5151
–
Michael Kiefte, Ph.D.
Associate Professor
School of Human Communication Disorders
Dalhousie University
Halifax, Nova Scotia, Canada
tel: +1 902 494 5150
fax: +1 902 494 5151
As a start, a preference for whether to maintain piece orientation w/r/t
the viewer or to the map would make this work for any game where facing
doesn’t matter.
I’m just jumping into the discussion since I didn’t find anything about that aspect on the forum. The client is already great and I’d be more than happy even if there were no improvements. Great job guys!