Yeah, well dragging them into the larger community is hard. (Consider that most of them play just F&E and maybe SFB.) And with the existing Cyberboard version, pickup has been slow. It’s relatively recently that I’ve gotten the feature set up to the point where the ‘old-timers’ are starting to notice (the user support I have is mostly newer arrivals). I should have pushed on it more. But then, when I got to where it really was my top priority, another user tried one of the test builds and reported on the performance gain. So I waited for a beta to test.
Comments from the forum so far:
Ken Watanabe (Watank) on Tuesday, May 13, 2008 - 06:51 pm:
Holy cow… it’s like night and day on my 2.4 GHz ModBook running 10.5 - GW start file loaded in <10 secs (Vassal itself loaded in a flash)… The Mac version is an application bundle on a disk image, so a simple drag-n -drop install.
Definitely going to play with it on the commute home
Jason E. Schaff (Jschaff297061) on Tuesday, May 13, 2008 - 07:12 pm:
Mother of pearl!
Someone on the Vassal team deserves major kudos. Not quite as fast here as you guys are reporting, but still only took about 1:45 to go from cold start to finishing the load of the GW scenario. (PowerMac G5, dual 2 GHZ, OS 10.4). Firewall settings may have slowed things down a little.
I don’t believe anyone has had a chance to look at it yet. Two of
us four developers are travelling at the moment and we’re receiving
a lot of bug reports right now. We will look at yours, but it might
be several days before that happens.
This is fixed in trunk@3642. As a side-effect, the launch process for
Players and Editors is somewhat less tangly than before, since I needed
to do some refactoring in order to fix the bug.
The error dialog needs to be replaced with something more presentable,
but you won’t get any exceptions now if you try to load a non-module.
I was looking at your F&E module just now—what are you doing with those
inventories so that they take so long to load? Either you’re doing something
wrong, or Inventory needs some serious optimization attention.
Yeah. ‘<’ and ‘>’ are also evil and need to be replaced with their
entities, and double and single quotes should be replaced within
when they need to appear within an already double- or single-quoted
attribute.
I think I have something unprintable to say about putting unprintable
characters into strings.
Argh. That’s really nasty. Doing this kind of checking is going to be
slow, so putting it into ArchiveWriter would make all saving slow,
when it’s only needed for doing imports.
What’s actually the right thing to do here? Are these characters junk?
How’d the y get there?
I think you could just do something like this, if it’s ok to chuck
those characters, and if you won’t see any Unicode characters:
final Pattern p = Pattern.compile(“[^\x32-\x7E]”);
String fixed = p.matcher(bad).replaceAll(“”);
(You want to hang on to the Pattern, and reuse it to create your Matchers.)
Ok. In the long-term, we should probably plan to sanitize all input from
importers, but this is probably ok for now. (Does it matter that the other
strings you’re reading in aren’t null-terminated? How are they
terminated? Do you have byte-lengths appearing before them?
I have several more as well—but I’m at a point where all of them
depend on input from other people first, so I’m going to go have a
beer soon.