I’ve uploaded 3.1.0-svn5062 now, and I believe all we’re waiting for now is translation of the key added after the translators gave us the current translations. I checked each one to arrive at the following count of untranslated keys:
Note also that the translation dialog is started by giving VASSAL the ‘–translate’ command-line option now. If any of our translators don’t know how to do that, please let me know and I’ll provide instructions.
Open a terminal window. (Select “Run” from the Start menu, and type ‘cmd’.)
cd X:\path\to\VASSAL.exe (The path will probably be
Open a terminal.
cd to wherever you installed VASSAL.
Mac OS X:
I can’t provide instructions for Mac OS X, because I don’t know how to open
a terminal there. Otherwise, it’s the same: Open a terminal, cd to where
the app bundle is, the run it with the --translate option.
Actually, it isn’t quite so easy, because the App bundle itself isn’t
something you can invoke directly on the command line and pass
arguments to. It is not an executable, so you can’t just invoke the
*.app bundle from the command line. You can start applications from
the command line by using the “open” command, but that doesn’t pass
along any arguments from the command line.
Instead it launches using an application launcher and takes any
command line arguments from the appropriate key in the Info.plist file.
For the Mac, the easiest thing to do from the user perspective along
these lines would to create a copy of the Vassal.app application and
just modify the Info.plist file to include the correct command line
argument. The appropriate Java key for that is “Arguments”.
I would think that the simplest solution would be to create a
*.command script for each Vassal version XYZ, called Translate-Vassal-
XYZ.command that you put in the native Applications folder. It will
then just assume that it is in the right place and have the following
-------- Begin file contents ---------
java -classpath Vassal-XY.app/Contents/Resources/Java/Vengine.jar
-------- End file contents ---------
This could use the standard Java startup and pass the command line
argument instead of invoking the specific class instead.
But as to the original question:
To launch a command line terminal on Mac OS X:
Go to Applications/Utilities.
From the Finder this is directly accessible from the
“Go > Utilities” menu item, but that will have a
different name in different languages.
swampwallaby-work@5067 contains the rest of the fix for
Bug  Detect Infinite Loops
This detects and reports Global Key Command loops - Direct and indirect.
I extracted the loop detection we built into DoActionButton and generalized it. I am just using one global counter to detect infinite loops of all kinds. The recursion limit is set to 50, so after 50 nested calls to Loopable components, the Error Dialog will display.
I though about having a seperate recursion limit for each type of component (i.e. count DoAction button recursion seperately from Global Key Command recursion), but decided it just wasn’t warranted. If you have 50 levels of GKC and DoAction recursion combined, your module is in deep trouble.
The only loop remaining on my list is the infinite Place Marker loop. I’ll look at this one now, but I think I can use the new InfiniteLoopDetection class for this too.
No ETA yet. I pinged him again, but Torsten provided the first draft of his translation a long time ago and indicated then that he didn’t have much time, so we may have to look wider for a German translator.
There are a large number of places in the code where unprotected
int = Integer.parseInt(String)
is done. Often, the data to be parsed is sourced directly from an IntConfigurer, so there is no change of getting a non-integer
However, for many of them, the data is sourced from either the buildFile or a Saved Game that may have been hand modified or corrupted. We seem to be getting about 1 a month where this has happened. These will all need to be protected with a try/catch block and Bad Data reports of some sort generated and a reasonable default used.
Do you want me to work on this for 3.1? This is our bug fix version, so I am guessing the answer is yes!
It should be done eventually, if for no other reason than to stop the bug
reports. Since we haven’t seen this problem in great quantities in the betas,
I think we shouldn’t hold up 3.1.0 for it, but I would be shocked if we
released no 3.1.1 which this could go into.