We know already that Vassal 3.2 modules will be incompatible with the Vassal 3.1 Module Editor.
In the case of Named Hot Keys, editing a 3.2 module with Vassal 3.1 will silently erase all of the Named Hot Key information and destroy the module.
It is likely that by release, there will be at least 1 new component that will cause Vassal 3.1 to fail to build the module and generate an unnecessary Bug Report.
What do you think about adding a block to Vassal 3.1.3 to prevent it from editing or playing modules created with Vassal 3.2 or later? This will a) reduce out of date bug reports and b) help protect developers from themselves.
At the moment, the version warning message only appears after an attempt has been made to load the module.
As an alternative to blocking all access to 3.2+ modules, there should be a much stiffer warning PRIOR to loading the module, and all Bug Report generation should be disabled while editing or playing the module.
Yes, I agree. People tend to just ignore warning dialogs. Since the module can be corrupted without any error messages displaying, a developer might think ‘they got away with it’. I can see it now - endless forum messages ‘All of my Named Key Commands dissapeared’
The module structure is reasonably compatible between 3.0 and 3.1, so there was no danger from allowing this. During the beta testing stage for 3.1 I, and I have no doubt numbers of other developers, used 3.0 and 3.1 interchangeably on modules, a bad habit to have gotten into.
If someone can actually come up with a legitimate reason to edit a 3.2 module with 3.1, you will still be able to do this with command line arguments.
Having looked closely at the structure of the buildfile, I can’t
imagine what we could do that would cause the module to fail due to a
backward imcompatibility. Features are always tacked on at the end of
structures and are silently ignored.
That being said, I think it’s a good idea in general for an older
version to refuse to even look at a newer module. I understand that
the buiildFile structure was meant to be robust, but I don’t think I
want the module editor to silent destroy information either.
–
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
The problem is not Backward compatibility, which we guarantee, but forward compatibility, which we absolutely do not guarantee.
However, Vassal 3.0 is, by chance, (mostly) forward compatible with Vassal 3.1, so you can edit a 3.1 module with the 3.0 editor and not do any substantive damage. I am sure some developers have become used to this and might assume that it will also apply to editing 3.2 modules with 3.1.
That’s the big problem. It’s not so bad if the whole thing just crashes in a heap (except for unwanted bug submissions).
