As promised yesterday, I’m starting this thread to discuss planning for 3.2
and beyond. At this point I’m listing only projects which I’m participating
myself. I know Brent is working on some things too, but I can’t list them
from memory or say how far along he is, what dependencies he has, etc., so
I’ll leave that to him to describe when he returns home.
I. Coding
Properties: The creation of some utility classes to encapsulate type-safe
properties which can be held by objects, querried by name, and watched for
changes. (95% complete. Could use some tests.)
Preferences: Our current preferences structures have a lot of problems.
This project aims to replace existing preference structures with a container
using Properties, replace Configurers and the Preferences dialog with with
better-looking GUI elements, and to store prefs as human-readable XML.
(50% complete. Depends on Properties.)
Conversion of Buildables to Use Properties: This project addresses a
performance issue, namely that currently retrieval of property values
is linear (and demonstrably too slow in some modules), while it could be
logarithmic if we used Properties and getter/setter functors stored in
Maps. (0% complete. Depends on Properties.)
NIO2 File Systems: This project replaces DataArchive and ArchiveWriter
(which lack various features needed by the Tile Cache) with a backport of
the JSR 203 file systems classes which we’ll someday see in Java 7.
(30% complete. In rapid development with Calsir right now.)
Tile Cache: Addresses the long-standing performance problem with very large
map images, by slicing them up the first time they’re loaded and caching the
tiles to disk. (100% complete, image code. 0% complete, disk cache
management code. Disk cache management code depends on NIO2 File Systems.)
Docking: Add a docking framework so that VASSAL components may be freely
rearranged and resized by the user. The docking framework I’d like to use
is GPL, which would mean that we’d have to switch to GPL ourselves. I’m in
favor of that anyway; however, it would mean that custom module code would
also need to be GPL, and in order to round up the authors to relicense it,
it would help to have the module library on the new web site up and running
already. Another option would be to use the docking code I started before
I found something better. I’m not keen on that, as it’s going to be a ton
of work to finish, and then we’ll have to maintain it. (10% complete.
Possibly depends on Web Site Update.)
Logging Improvements: Various improvements to game logging. Tim McCarron
and I hashed this out about a year ago. This would amount to some VCR
controls and an annotatable list of moves. (5% complete. Depends on Docking,
as there’s no place to put the GUI otherwise.)
Wizard Replacement: We have quite some bugs related to the setup and welcome
wizards, and moreover they are aesthetically awful. The wizards will still
be ugly after fixing the bugs, so I want junk them rather than spend time
figuring out how exactly they’re broken. This project involves writing a
simple wizard framework and reimplementing our wizards in it. (40% complete)
ZunTzu Converter: Converts ZunTzu modules in to VASSAL modules. (70%
complete)
Model-View Separation: Our GUI code is interspersed with our data handling
code. This makes it hard to test our data handling code. This makes it hard
to ensure that all Swing calls are done on the Event Dispatch Thread. This
makes it hard to move as much other processing off the EDT as possible in
order to improve GUI responsiveness. This makes it hard to implement other
views of the same data (see the JOGL project). The idea here is to separate
existing classes into a model class (containing the data) and view classes
which hold the GUI components, listen to the model class for changes, and
pass on changes from the GUI to the model. (0% complete, depends on
Properties. Can be done concurrently with Conversion of Buildables to Use
Properties.)
JOGL Implementation: We could use JOGL (Java bindings for OpenGL) to have
continuous scaling and rotation of map views. Michael has a working demo
of this. (10% complete. Depends on Model-View Separation, in my opinion,
though Michael wasn’t sure last time we spoke about it.)
General Aesthetics: We have a lot of badly laid-out GUI elements, dialogs,
etc. They’re embarassing. These need to be cleaned up, preferably converted
to use MigLayout. (??% complete)
II. Other
Web Site Migration: The new web site will have a newer version of phpBB, a
better wiki (MediaWiki), and a better bug tracker (Bugzilla), all with a
unified login. (75% complete)
Web Site Update: Once we’ve migrated to the new site, we’ll need people
to help clean up the wiki, clean up the module pages, etc. This is a job
which can involve many, many people working in parallel so long as someone
is organizing it properly. (0% complete)
Module Editor Docs: Ed, our documentation guy, is working on new docs for
the module editor, to go with our spiffy new Users’ Guide. (?% complete)
I think that sums up everything I’m sufficiently aware of so that I can
describe it. The ones I that I don’t want to release 3.2 without are
Properties, Preferences, NIO2 File Systems, and Tile Cache. I also want
to finish Web Site Migration as soon as is feasible (both because I hate
working on it, and because I’ve been promising it for what must be getting
close to 9 months now).
Some of these are pretty small projects (e.g., the ZunTzu converter) which it
would be most efficient for me to finish myself. Others are big jobs (e.g.,
Bugs, Conversion of Buildables to Use Properties, Web Site Update) which
would benefit from many hands.
It’s basically just parsing XML, and the file format is even documented.
I don’t have the code committed right now. I can do that tonight if you
want to mess with it or finish off the last 30%.
Eh, that depends. It might help to start both of them together, because
knowing what JOGL needs could inform our design of the view interfaces.
I’ve committed the existing code to the zuntzu-converter branch. What’s
there right now is a SAX parser which understands (mostly) the ZunTzu
gamebox format. There are a lot of FIXMES, and I haven’t done anything
yet to connect it to VASSAL—the locations for creating the VASSAL
components are there, but not the code for doing it.
BeanShell - Calculated Properties, In-line Expressions [1565025 Calculated Property and General Mathematical Expressions] Calculated Properties are properties whose value is a Java expression, referencing other properties and in-built functions. Inline Expressions are Java expressions that can be used in fields that currently allow $xxxx$ expressions. 80% complete. Working, but needs improvement in GUI. No dependencies
Named Key Strokes [1604269 Specify keystrokes by name] Wherever a Hotkey can be entered, optionally allow entry of a Name instead. A Name consists of 2 or more alpha characters and does not appear on the right-clock menu. Each unique Name is internally replaced by a unique hotkey that is guaranteed to only match other VASSAL Hotkey fields using the same name. This allows you to make up meaningful names for hotkeys used internally in triggers etc., instead of having to invent series of unusual combinations to prevent overlap. 100% complete.
Jabber Client improvements. Add Room locking, invitations, kicking to the Jabber Client, tied in to the facilities provided by the Jabber server. 75% complete. No dependencies.
Counter autoloader [2132985 Facility to generate many counters from a folder of images] Point VASSAL at a folder of images, enter a Piece definition, preview the counters that will be generated, allow user to rename them, skip some, preview images, then create all of the counters in one go. 100% complete.
Improved Game Updater [1199542 Scenario Counter Refresher ]. 80% complete, no dependencies. Working, but looking at ways of automatically determining counters are out of date and auto-updating.
Tango Icon support. 50% complete. Awaiting full support for pathnames in DataArchive.
Minor projects, all completed:
2842811 ‘Ignore Grid’ changes
Add ‘Snap to Grid?’ option to HexGrid and SquareGrid
2828808 Restrict Access: Restrict movement option
Allow Restrict Access trait to restrict access to traits, but not affect movement.
2813702 Add looping to Trigger Action and Action button
Option to cause the list of actions in a Trigger or Action Button to repeat a number of times. Completely configurable, allowing implementation of any kind of For, While or Until loop. Number of loops based on a static number or on a property value.
2803311 Movement like traits to update same properties as DnD moves
Have traits that move a counter (Send To Location, Return to Deck, Move Fixed Distance, Pivot) update the same Oldxxxxxx properties that are updated by a Drag 'n Drop move.
2799291 Add DeckPosition property to pieces
Add new property DeckPosition which returns the position of a piece within a Deck, or 0 if it is not in a Deck.
2799261 Add Reverse Hot-key to Deck
Add missing option for Hotkey for Deck Reverse command
2717634 Display Log File Comments in Chat Window
Display the recorded Log File Comments when opening a log file.
2456733 Option to make a Map Global Key Command global
Map GKC’s are currently only sent to counters on the map they are defined in. Add option to allow them to be sent to all counters
2005474 Allow Dynamic Property Select Value list to be dynamic
When setting the value of a DP from list, allow the list to include property references.
2005463 Add Description field to Multi-Action button
Add missing description field to Multi-Action button.
1913850 mp3 support
Support for mp3 sound files in Play Sound trait and Do Action Button.
1637018 display coordinates without grid lines
Option to display just grid co-ords, no grid lines.
1604275 Move Level up/down within Layer
Buttons to move images higher or lower on the list in a Layer trait.
1406133 Decks - Restrict contents
Restrict the addition of counters to a Deck via Drag 'n Drop to those that match a property expression.
Brent, do you have this in sourceforge somewhere? I discovered the the save game updater is broken pretty badly in 3.1.13 but this project sounds like it’s already addressing it.
This is currently in the swampwallaby-updater branch, which is an older branch of the trunk. I have not merged the refresher into the trunk yet. It is one of the many, many jobs I need to get back to urgently!
I have added many new features to 3.2 (Look for all priority 6 and over sourceforge enhancements assigned to swampwallaby) and I desperately need assistance reviewing and testing these, and perhaps refining and polishing them given the viewpoint of a different set of eyes.
If you are interested these or any of the other enhancements, it would help me a lot if you could try them out possibly adopt a couple?
Also, I have a go at running the current trunk and see how it goes for you. Most things should work on an existing module, but there are problems trying to load in new images.
I went ahead and tested my bug against your branch and it seems to fix the problem after all. However, I did see one problem in that the pieces were displayed as all black on the mapboard while the stack display that pops up when you mouse over displayed the units correctly.
Ah, yes. That particular branch could be broken in any number of ways as it is quite old and Joel has fixed a few of the major problems since then to make it more usable.
I didn’t touch the old SavedGameUpdater, I have created a completely new online game refresher that works on the currently loaded game, refreshing all counters with the latest version defined in the editor. I will try and get it merged into the trunk asap.
I dug into this some more, and it appears that if the gpid is not in the saved game for a unit, you are VERY conservative in matching up units. I’d suggest matching commonName and imageName from the basicPiece and going with that as a secondary (or tertiary) match. Otherwise, no units will match if any changes have been made to the piece at all.
Yes, you are right, the fallback check is very conservative. gpid’s where introduced with v3.1.0, even though they are only being used now, so it is only saved games from 3.0.x or earlier that not have gpids included.
There are a number of problems trying to find an alternate match that I have seen in various modules:
Modules have multiple counters with the same commonName.
Modules with no image defined in the BasicPiece, all images defined in Embellishments.
Modules where the commonName has been updated.
Is is possible that multiple, or none counters may be found that appear to match a current counter. Perhaps we need some sort of interactive tool that suggests possible matches and asks the user to select the correct one, or to select any other counter.
As you can see, it starts to become far more complicated than the simple gpid approach and is only usefule for saved games created prior to March 2009 when 3.1.0 was released.
I will try and get the current version of the updater merged into the trunk tonight.