The reference manual for V3 doesn’t seem to have much discussion on property (variable) types (numeric, character, boolean, etc.), and as I understand, V3 tries, to some extent, to interpret property types without requiring the module developer to explicitly type them, other than the Is numeric check box for the Dynamic Property and the Global Property but not for Markers. Also, Vassal has several handy built-in properties, but their types don’t seemed to be explicitly stated. I get the impression that Vassal tries to avoid confusing potential module developers with the concept of data types (it may be the underlying Java that induces this “semi-typed” environment). My intent is not to criticize past decisions, but to suggest what I see as a better path forward. I heartily applaud the Vassal team’s efforts to keep the entry bar low for potential module authors.
I believe any processor would need to be told the type of the data it is asked to process. So the burden of providing that information would either fall on some interpretive routine or the authors of V4 and its modules. I think it would be much more efficient to present V4 as a “typed” system and state the data types for the built-in properties in the documentation and require module authors to explicitly “declare” (or choose) a type for each property they add to a module.
I don’t think the concept of data types to be all that difficult to grasp. After all when conceiving of what data and how to use it in a module the author would have to clearly distinguish between the very basic types of numeric versus character data.
I also recognize this approach would require use of a type conversion function or method to use numeric characters defined as character data as a number, or to add and keep leading zeros to a number.
As for which data types, I think the basic types of character (strings), numeric (integers) and boolean (true/false) would be appropriate for providing a great balance between simplicity and flexibility. The module editor could provide a somewhat disguised interface for more advanced types, which I believe is currently being done in V3.
I’d like to see the concept of boolean property types as an option for Dynamic and Global Properties so that they could be used in selection criteria fields rather than comparative expressions.
A couple of recent threads dealing with the topic are: How to keep leading zeros in expression and Special Grid Numbering Not Working with 3.6.7 (Solved!) - #23 by pawnpusher .
Both of these threads stemmed from an area of Vassal with what appears to me as a lot of vagueness as to property typing, Grid Numbering.