version comparisons in ConditionalCommand

Can someone tell me what the version numbers are versioning in
ConditionalCommand.Lt.isSatisfied() and ConditionalCommand.Gt.isSatisfied()?
Are they VASSAL versions? module versions? something else?

Joel,

The only reference in the entire module to ConditionalCommand is in GameState.checkVersionCommand() which seems to be using Lt to check both Vassal and Module versions.

Brent.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

Thanks.

Hmm. Module version numbers could be, well, anything, so there’s no
guarantee that we’ll be able to compare them sensibly. (E.g., I have
at least one module that has a sentence appended to its version
number, presumably because the module developer wanted that to appear
in the chat window whenever the module was loaded.)

I wonder if we should require that module version numbers are input
as dotted integers only, to ensure that we can succesfully comapre them
from now on?


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

That’s not a bad idea. Maybe even break it right up, something like:

Major Revision: 4 Minor Revision: 12 Point Revision: beta-1

Where Major and Minor revision numbers are forced to be numeric?

B.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

We could constrain the module version format, but I don’t see it as critical. The implicit assumption behind the version checks in VASSAL is that everything it backward-compatible (i.e. a new module version will be able to load games saved with the old version) Of course, a module designer is free to make his upgrades non-backward-compatible, in which case the version check is useless anyway. So there’s an argument for letting version numbers be arbitrary so that module designers can set the version number to be something crazy like “4.0 – not compatible with 3.0 and earlier. Please contact joe@vassal-modules-r-us.com (joe@vassal-modules-r-us.com) for questions”

rk

Post generated using Mail2Forum (mail2forum.com)

Thus spake “Brent Easton”:

If we separate the revision numbers components into fields we’ve hard-
coded in, then we’re mandating how long the version numbers should be.
If somebody wants to have 1.2.3.4.5.6.7.8.9, we can already interpret
that properly, so maybe we shouldn’t stop them? We’re also capable
right now of interpreting dotted integer version numbers up to the
point at which they stop conforming to that pattern. E.g., we can
decide that 1.1.3-foo < 1.1.4-bar because the decisive initial
substring occurs before we hit something which isn’t a dotted integer.

The reason I’m asking about this is that I spotted the problem while
making a small change to the version parser last week, and it got me
thinking about how to compare these things sensibly.

Another thing we could do (and something I think we should do more
generally) is validating input as it’s typed. A lot of programs do
this, and I think JTextFields have support for it. What it ammounts
to is categorizing the input after each keystroke as to whether it’s
valid, invalid but extendable into something valid, or invalid with
no valid extensions, and then setting the state of some UI component
to reflect that (a common choice is to disable the Ok button except
when the input it valid). For example, if you type “1.2.3x” you’d get
something like this:

“” → possibly valid
“1” → valid
“1.” → possibly valid
“1.2” → valid
“1.2.” → possibly valid
“1.2.3” → valid
“1.2.3x” → invalid

I’m not suggesting that we do this right now, but it’s something I
think we should consider for the future.


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

On Jul 25, 2008, at 5:08 AM, Joel Uckelman wrote:

You might want to consider looking at the JGoodies validation
framework for that. It looks like it has some nice support for it,
and the license is unrestrictive (BSD open source).

jgoodies.com/freeware/valida … index.html
jgoodies.com/downloads/libraries.html


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

Thus spake Thomas Russ:

Thanks for the tip. JXLayer from SwingLabs is also something I’d
considered for this. (It has the advantage that we’re already
using is somewhere else.)


J.


Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)