Unless the Jabber server implementation we use (I’ve been testing with OpenFire) has a leak of its own, this should solve the problem.
rk
Post generated using Mail2Forum (mail2forum.com)
It is difficult for the MM to implement Chat because it does not have a GameModule.
Also, the MM can’t load SVG’s or use ImageOp’s because they are dependent on having a GameModule with DataArchive, even though the images needed are loaded from the Vengine.jar.
Both problems might be easier to solve if the ModuleManager subclasses or creates a custom GameModule or BasicModule?
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Brent Easton”:
Why don’t we decouple the chat stuff from GameModule, then?
That’s going to change during the 3.2 development cycle.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Yes, that’s the idea.
The only performance improvement is in zooming and rotating which is offloaded onto the GPU. Actually drawing the map and pieces will either be slower or the same. Hopefully this won’t be noticeable in any case. Regardless, the player should have the option to choose.
- M.
Post generated using Mail2Forum (mail2forum.com)
About 50% of the bugs coming through are being caused by problems with custom code that have now been fixed in updated versions of the modules, but there are still many copies of the old broken modules out there that people keep running and submitting bug reports from without checking if there is an updated version of the module.
Not sure how we should approach it, but some way of checking if there is an updated version on a module by module basis is becoming important for my sanity 
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
With the module manager, we have the auto updater in there that checks (every 10 days or so?) for new versions of vassal. Would it be possible to port this to drill down further (i.e at module level) so that when the module is run it checks the module version also in a similar fashion?
From: Brent Easton b.easton@exemail.com.au
To: VASSAL Engine Forums Mailing List messages@forums.vassalengine.org
Sent: Thursday, March 5, 2009 2:56:41 PM
Subject: Re: [Developers]Vassal 3.2 Discussion
About 50% of the bugs coming through are being caused by problems with custom code that have now been fixed in updated versions of the modules, but there are still many copies of the old broken modules out there that people keep running and submitting bug reports from without checking if there is an updated version of the module.
Not sure how we should approach it, but some way of checking if there is an updated version on a module by module basis is becoming important for my sanity
B.
Messages mailing list
Messages@forums.vassalengine.org (Messages@forums.vassalengine.org)
http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Brent Easton”:
I value your sanity, so here’s a proposal:
The way around this is for us to keep a list of current module versions
(possibly generated automatically from the new web site’s module library
once per day) and have VASSAL check periodically for updates for running
modules, just as it does for VASSAL itself.
In order for this to work, however, we have to force module designers to
use some kind of machine-readable versioning system. Otherwise there’s just
no way to tell whether “1.60-foo-3” is older or newer than “bar-32-baz”.
My suggestion woudl be to use dotted decimals plus an optional tag
(‘x.y.z-tag’), because it’s simple, explainable to anyone, and conveniently
we already have a parser for version numbers in that format.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
I see three main points where we would want to check the version:
a) After the Module Manager starts up and finishes building the module list, it should start a new thread that runs through the users module library and marks any modules that are out of date.
b) The Bug Dialog screen should attempt to check for a new version and not allow a bug to be submitted in an out of date module. If there is some problem with the current version, then it is up to the the users and developers to sort that out.
c) A Help menu option ‘Check for updated module’.
The new module pages will need to allow the module designer to specify which file available for download is the current version.
There will still be modules that are hosted off-site for a variety of reasons, but will have a module page on the Vassal site with no files. We should allow the module designer to enter a version number to be used for version checking. (Or enter the URL of a resource that contains the current version number).
Yes, I am all for enforcing a standard version number scheme. I have seen some bizarre things in the version number field of some modules.
We could auto convert existing version numbers to a conforming scheme. In the worst case, module version ‘bar-32-baz’ would become ‘1.0.0-bar-32-baz’.
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
We did discuss a use for hexsides in preliminary fashion at vassalengine.org/forums/view … rrain#2337
posts #8+
it could be kept simple like that for now ignoring special conditions from other components or things like modifiers.
As for lines they could be used, same way as CurrentTerrain to define roads/rivers etc… that do not follow hexsides (could probably do the same thing with tags though) and expose them with a property called CurrentTerrainLine.
The designer interface is simple enough, drag n drop in editor, just like terrain hexes (mine works wonky - always hilights another hex, old version) but strikes me as intuitive enough for designer. I dont feel it needs any special interface or instructions.
Working at this depth means your already going to understand properties, and how to use them, which is the first step in setting terrain up in the module and getting any use out of it anyways.
Another 3.2 thing -
Is it intended to revamp the caching of the property value or property provider like we discussed?
Thus spake “Tim M”:
Hmm, yes. That’s a major efficiency problem. We should fix that for 3.2
if we can.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
One more thing which should be looked at for 3.2: the drawing of grids over
maps.
I don’t know how anyone can stand to use grids which are painted over the
map the way they are now. This needs to be made more efficient than it is
now. I’ll try to tackle this at some point.
Funny you should mention that as I was just reading a blog going on about it
and the difficulty the designer is having with grids
vlnb.blogspot.com/
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Tim McCarron”:
I’m not really sure what to suggest to the guy. This is a completely
different problem from the one I was talking about. His problem could be
caused by three things:
- He doesn’t have the grid quite the right size.
- The hexes we draw aren’t quite true.
- The hexes on the map scan aren’t quite true.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
And the correct door is door number 1. 2 is never true 3. is somethimes true, but never to the extent evident on the published screen shot.
I have published the following on his blog:
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Updated 3.2 Plan:
- I18n of Module Editor (Tim, Brent)
- Tango Icon support (Not a full set of Tango Icons as such, just support for them) (Brent)
- Named KeyStrokes (Brent)
- Counter autoloader (Brent)
- Improved Game updater (Brent)
- Map Terrain Properties (Stage 1 - Full Hex terrain and Hex attributes) (Brent)
- Calculated Properties and in-line Java expressions (Stage 1 Beanshell) (Brent)
- Tabs/Docking interface (Joel)
- Further JOGL investigation (Michael)
- Logging Improvements (Joel)
- Jabber Server interface (Rodney)
- Review/Revise Drawing Grids on Maps (Joel)
- Checking for availability of new versions of modules (Joel?)
- Property Value caching/efficiency (?)
- Room auto-synching (Ben)
- Chat in Module Manager (Ben, Rodney)
- Various other RFE’s as time permits (All)
New feature cut-off: 30 June 2009
Beta 1 released: Early July 2009
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
An ongoing development I would like to see is expansion of the Module metadata.
Having just finished fighting with the ‘1914: Twilight in the East’ module, I think the first cab off the rank should be ‘Recommended Maximum Heap Size’!
I’m also wondering about the minimum Heap size. Do we really need it? What really is the disadvantage to setting it to 256Mb for all modules?
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Brent Easton”:
I think this is a good idea. But, if we do this:
-
We absolutely have to be able to check how much RAM the machine has, so as
to head off the situation where the recommended max heap is greater than the
amount of RAM. -
We should have a recommended max heap with memory-mapped images and another
without, as they’ll be quite different.
It occurs to me now that it might be possible to analyze a module and guess
a good max heap setting. If you looked at the dimensions of the main map,
you could figure out how much memory that would use, and that would give you
a lower bound for the max heap. I’ll bet that there’s some constant multiple
of that number which would work pretty well across modules.
I haven’t experimented with this much to see how much difference it makes
in practice, but in principle allocating too little heap to start with will
make module loading slower than it needs to be.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
I would see it as a recommendation only that is checked when the module starts. You would get a warning dialog and an option to increase it. It definitely should not change the heap size automatically.
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Brent Easton”:
What about the first time you run the module? Shouldn’t the recommended
size be used then?
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Yes, subject to machine RAM limitations.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)