Is your big map in SVG format?

By James Lowry (Rindis) on Wednesday, December 17, 2014 - 06:29 pm: Edit

No, it could be done that way (the original is a CorelDraw file), but I've had trouble getting SVG to work right, so it's a PNG.

But it and the 'small' map are just different size exports of the same vector file.

By Paul Edwards (Pablomatic) on Wednesday, February 25, 2015 - 07:15 pm: Edit

Much, much love for you James. I prefer Vassal, and a large map plus changes you describe will be a great upgrade. I appreciate your efforts.
I had the thought that it would be neat to have "configurable" tug counters (like the JPG-G, etc.). This would reduce stacking (no pod counters). To keep it all straight, we could still use the pod/pallet counters on the charts when they are not in use. Not a big deal, but a thought if it interests you. Cheers.

By James Lowry (Rindis) on Thursday, February 26, 2015 - 01:20 am: Edit

I have contemplated that.

That way madness lies.

That doesn't mean I won't do it. It would certainly help out some of the stat tracking that I'm trying to make 2.0 better at.

By Paul Edwards (Pablomatic) on Sunday, March 01, 2015 - 11:09 am: Edit

Understood about the madness. We would all promise not to call you a madman, regardless.

By John de Michele (Jdemichele) on Friday, March 06, 2015 - 03:46 pm: Edit

We all go a little mad sometimes

By Mike Curtis (Nashvillen) on Friday, March 06, 2015 - 03:51 pm: Edit

James, waiting on a new computer to continue with your tests. The one I have currently has been acting flaky with Vassal. Pretty sure it is the AT&T issue that is going around with Vassal and my opponents, but I want to make sure my 6 year old computer is not the issue first.

By James Lowry (Rindis) on Saturday, March 07, 2015 - 12:57 am: Edit

Okay Paul, you've volunteered to be part of the 2.0 test crew. :D

I've just sent out Test 5 to everyone on the current list.

I also talked about it a little here:
F&E Vassal 2.0 Test 5

By Paul Edwards (Pablomatic) on Saturday, March 07, 2015 - 08:56 am: Edit

I looked at the pages on BGG. No link to the module, if that is what you intended. Do you need my email?

By James Lowry (Rindis) on Saturday, March 07, 2015 - 11:38 am: Edit

I used the email you have in your profile here. You should have gotten a file from me last night.

By Paul Edwards (Pablomatic) on Saturday, March 07, 2015 - 04:56 pm: Edit

Got it.

By James Lowry (Rindis) on Sunday, June 07, 2015 - 08:01 pm: Edit

Just a quick progress update: I sent out Beta 1 of the new module today.

By Peter Bakija (Bakija) on Friday, July 03, 2015 - 01:26 pm: Edit

James!

So here is a question that came up on the facebooks, and you might have an answer:

In VASSAL preferences, there are options for JVM initial heap and JVM maximum heap. The assumption is that this is how much memory VASSAL allocates for use? What is the maximum memory you can allot? It starts at 256 (initial) and 512 (maximum).

By Byron Sinor (Bsinor) on Friday, July 03, 2015 - 01:39 pm: Edit

If it is a 32-bit engine, the maximum addressable memory should be 2GB or 2048MB. If its 64-bit, the sky is the limit, but JVM performance suffers if the heap is too large because of extended garbage collection times. Depends on the efficiency of the application where the sweet spot is. I'd suggest bumping it up until satisfactory, but generally not past 2GB.

By James Lowry (Rindis) on Friday, July 03, 2015 - 06:17 pm: Edit

Byron seems to know better than I. ~_^ Your initial assumptions are correct. I had to bump the max up to 1024 for Driving Winds (the ISC scenario) to work.

I'll also mention that once memory is allocated to a module, it doesn't get released until the module is closed. So opening and closing games can have quite an effect on the system until you actually exit the module itself.

By Byron Sinor (Bsinor) on Friday, July 03, 2015 - 09:53 pm: Edit

I support Java based application servers for a living, specifically IBM WebSphere, have some experience with Tomcat, etc... I'm not a coder, but a Systems Admin, so I actually make the darn things work.

By Peter Bakija (Bakija) on Saturday, July 04, 2015 - 11:29 am: Edit

Oh, cool. So I should, in theory be able to bump up to 2048, close out, reopen, and I might be gold.

By Jason Langdon (Jaspar) on Tuesday, July 07, 2015 - 01:03 am: Edit

Hi James, could you please confirm whether Vassal can handle the full ISC War scenario?

If yes, are you able to confirm from which version? I have a few games running and would like to try out ISC War but dont want to interfere with my other games.

Thanks !

By James Lowry (Rindis) on Wednesday, July 08, 2015 - 02:36 pm: Edit

The current version of the module (1.3.1) can handle it. You'll need to boost the JVM Max Heap up to 1024, and the cordon borders are not shown. Also, make sure to load the ISC extension.

The new module in testing should do it better (the cordon borders are given), but no set ups for what is a complex scenario are done yet.

By Jason Langdon (Jaspar) on Wednesday, July 08, 2015 - 08:20 pm: Edit

To load the ISC extension you just take it out of the inactive folder and stick it in the main F&E folder?

By James Lowry (Rindis) on Thursday, July 09, 2015 - 10:15 pm: Edit

Right. You don't have to do that manually. If you expand the Federation & Empire entry in the module manager, you'll get the full list of available extensions, with the inactive ones in grey. Right-click on it there, and choose 'Activate'. Then start the module.

By James Lowry (Rindis) on Wednesday, October 28, 2015 - 11:15 am: Edit

Progress report: For those not getting the test materials, I am currently working on Beta 5 of the 2.0 Vassal module. I anticipate work can begin on getting all the setup files done once I've finished work on 2.0b5.

The feature I'm just finishing up is a complete re-do of the Admirals, which allows me hide away all the randomization of Variable Admirals.

This also means that I no longer need the decks on the empire charts, and could put something else in that space:

1) A pool for unused free PFs.

2) Storage for unused FOGs, HOGs, etc. Currently, I assume those are tracked outside the module, but I could do tokens easily enough.

Several empires don't really have spare space, so this is an either/or idea. The Romulans do have spare space, so I'd possibly put in spare module storage with the HDW tokens on #2.

Any thoughts on what would actually get used?

By James Lowry (Rindis) on Wednesday, November 11, 2015 - 06:00 pm: Edit

Factor tracking question:

Right now, the Stack Viewer, and a few other places in the Vassal module report on the number of fighters available in the format '10V8H6', Federation F-111s have been lumped together with all the other heavy fighters, they just happen to be nine-factor squadrons like F-14s happen to be eight-factor squadrons.

FO is making the split between F-111s and F-101s more apparent by making F-101s be 'Y' factors.

For tracking purposes, I'll keep putting them in the 'H bucket' because they're exactly like everyone else's H-factors. But, should I break the F-111's in the reporting? (Probably, yes.) And how should I mark them?

One thought is to do what the physical game can't and re-do the F-111 carriers with a new letter and keep the F-101s as "H". ("Y" is a possibility, but reversing what the physical game is doing could be very confusing.)

Possibly, use 'Z' and hope there's never a new function that uses it. F-101 squadrons would be 9Z and the module's reporting would look like '10V9Z8H6'.

Any thoughts? I'm not happy with listing out four different fighter factors in the reporting (especially since only the Feds use two of them), but that's where we are.

By Stewart Frazier (Frazikar2) on Wednesday, November 11, 2015 - 08:39 pm: Edit

If you're talking about an overview, then lumping the 'H' (V/H/Y) factors together should work.

If it's a more detailed listing, then the factors should be listed separately.

By Ryan Opel (Ryan) on Wednesday, November 11, 2015 - 10:22 pm: Edit

I agree with Stew.

Until you start talking about replacements they don't matter from one to the other.