When there is no gameModule (which can happen in a test-bed, use the defined defaultSpeed instead of looking up module preferences.
Thus spake pgeerkens:
When there is no gameModule (which can happen in a test-bed, use the
defined defaultSpeed instead of looking up module preferences.
Is this something which happens much? If so, I’ll queue it up for
3.1.17. If not, I’ll save it for 3.2.0.
–
J.
This humbugged me for a while, when I tried to re-jig the test bed for HexGridNumbering to run the Configurers. If you don’t put it into 3.1.17 then it might humbug other developers working on M-V-C, probalby at the worst possible time. SInce it is a dead-simple fix the risk on it is quite low. (I speak from experience that not all ‘dead-simple’ fixes truly are, but this one really is. 
)
It looks like the original developer intended to code this in, but just forgot along the way, as the default value was already defined but unused.
I have spent yesterday and half today working on an implementation of Attributes and Attribute to eliminate much of the boiler-plate code in sub-classes of AbstractConfigurable. The intent is that classes extend AbstractConfigurableAttributed (instead of AbstractConfigurable, and replace all the code to handle attributes with nice simple calls like this:
attributes.addAttribute(“key1”, “attribute 1”, Double.class);
attributes.addAttribute(“key2”, “attribute 2”, Boolean.class);
attributes.addAttribute(“akey3”,“attribute 3”, Byte.class);
attributes.addAttribute(“akey4”,“attribute 4”, String.class);
attributes.addAttribute(“Akey5”,“attribute 5”, String.class);
attributes.addAttribute(“Zkey6”,“attribute 6”, Long.class);
attributes.addAttribute(“Akey7”,“attribute 7”, Integer.class);
attributes.addAttribute(“Akey8”,“attribute 8”, Color.class);
with client code continuing to look thus:
attributes.get(“key1”).setValueString("-48.635D");
attributes.setAttributeValue(“key2”, Boolean.FALSE);
attributes.setAttributeValue(“akey3”, 0x7F);
attributes.setAttributeValue(“akey4”, “Fred & George Weasley”);
attributes.setAttributeValue(“Akey5”, “are twins”);
attributes.setAttributeValue(“Zkey6”, “45678”);
attributes.setAttributeValue(“Akey7”, 0x80000000);
attributes.setAttributeValue(“Akey8”, Color.CYAN);
Using reflection and generics I have a nice elegant implementation of all the above, but have tripped over the StringEnum class. The missing piece is a common method name for the converions of a stirng to the attribute base-type; numerics all use valueOf and Color uses decode, but StringEnum doesn’t even sem to have an equivalent.
As this is work that might be useful to roll into M-V-C, let me know if yo want to look at it, or have thoughts on how best to work past the current road-block.
Edit:
#7774 in VASSAL-src/branches/pgeerkens/src/VASSAL/configure/Attribute*.java
Thus spake pgeerkens:
This humbugged me for a while, when I tried to re-jig the test bed for
HexGridNumbering to run the Configurers. If you don’t put it into 3.1.17
then it might humbug other developers working on M-V-C, probalby at the
worst possible time. SInce it is a dead-simple fix the risk on it is
quite low. (I speak from experience that not all ‘dead-simple’ fixes
truly are, but this one really is.)
It looks like the original developer intended to code this in, but just
forgot along the way, as the default value was already defined but
unused.
Thanks. I’ve picked this up as 3.1@7812.
–
J.