I’ve been spending the day porting a ZunTsu module to Vassal and have made a fair bit of progress.
I’ve got a few scripts that will extract and massage the ZT module, but I need to populate the VASSAL buildFile with counter data. (I’ll put my ZT extraction stuff up once I’ve got it all prettied up and working properly - this is just an experiment at this stage.)
Does anyone here have scripts that do this?
Thus spake “BobJames”:
I’ve already written 2/3 of a ZT converter. It will be in VASSAL 3.2.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
2009/3/24 BobJames <messages@forums.vassalengine.org (messages@forums.vassalengine.org)>
Believe it or not, I think the easiest thing to do would be to write it in Java as all the code for building the buildFile is already there. The downside of this, is you have to work through how the code is organised.
If you do it totally externally, there’s going to be a lot of problems with respect to how the buildFile is written out. Although it looks like you could do it externally, there are a lot of nested structures which are actually multiply quoted strings that would be really nasty to work out by hand.
Post generated using Mail2Forum (mail2forum.com)
*********** REPLY SEPARATOR ***********
On 24/03/2009 at 4:45 AM BobJames wrote:
The next working build of 3.2 will include a ‘MassPieceLoader’. Any component that has ‘Add Single Piece’ or ‘Add Card’ now also has ‘Add Multiple Pieces’ or ‘Add Multiple Cards’. Point it at a directory of appropriately named counter images, specify a counter template (looks just like a piece definition), tell any Layer traits how to recognize piece names that need to be placed into levels, click OK and Vassal will automagically load the images and create all of the counters for you.
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
mkiefte: “Believe it or not, I think the easiest thing to do would be to write it in Java …”
I’m not being that adventurous, I want to get this done in a day or two and it’s only for one module so I don’t have to be all singing/dancing. Also I don’t want to be here full time for the next few weeks with Java so I’m using shell and perl scripts, and I can do minor bits of fiddly stuff by hand.
I got the images out in a few hours this afternoon, all I need is something that shoves piece definitions into the build file that reference a few prototypes that I’ve pre-defined by hand - nothing fancy.
I’m also trying to avoid sitting here doing point-n-click for the next few months with counter definitions.
Brent: “MassPieceLoader”
Now that sounds good, I’ll look forward to that.
I’m currently trying to figure out how counter ID’s get defined in ZT because they are used in scenarios but seem to be defined arbitrarily. However, that can’t be true because of the way ZT appears to handle counter images (at least on the basis of how I think the data is working).
Thus spake “BobJames”:
You don’t need to do any of this if you can wait for the ZT converter I’m
working on. I estimate that it will take only another 4-6 hours of work
before it’s usable.
My guess is that they start at 1, counting upwards from the upper left corner
of the first counter block on the first sheet. If you could determine
conclusively for me how this works, that would save me some time.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
They start at 0, count left to right, top to bottom on the countersheet.
Countersheets are ordered as they appear in the game-box.xml file (and I suspect that counters are similarly ordered within countersheet-regions)
There seem to be a few xml attributes (like rot=x) that determine some placement issues but I can’t work out what “Back” means - it seems to imply flipping the counter in some way but that wouldn’t accord with the basic scheme that seems to apply a different ID to the back image.
(btw - cards are treated in the same way as counters)
All that said, ZT seems awfully primitive as there are massive amounts of semantics (hexes, LOS, etc, etc) supported by Vassal that it doesn’t even bother to capture.
And I have worked out how to manipulate the buildFile. Can I make an observation?
The properties strings - as generated/decoded by SequenceEncoder seem to be causing a bit of trouble as witnessed by the comments in the ‘inheritance’ thread. This is fair enough 'cos if you start with one implementation you can find it hard to get out if it’s a nuisance later.
But perhaps the real problem is the Decorator pattern. Just off the top of my head (I’m not across the code base yet), wouldn’t Chain-of-Responsibility simplify things a bit?
It might allow processing of traits and prototypes to be merged - ie. process traits at runtime in the order declared from the end to the start of the list specified for the piece and then move up the tree through the prototypes - sort of like a reverse of depth first search. It might get rid of the parent-redefined-the-trait-order-so-my-child-definition-is-stuffed problem (If I haven’t understood the issue in that thread, please excuse me)
Thus spake “BobJames”:
Thanks.
Have you seen this?
zuntzu.com/gamebox-grammar.htm
I don’t spot a ‘rot’ attribute there. Is that in a saved game or a module
XML file?
Well, in the long term I intend to make the buildFile human-readable. That
might eliminate some of the trouble.
My understanding of the problem is this: We completely instantiate prototypes
whenever a piece is created. The reason for that is so saved games aren’t
ruined when prototypes change. If we didn’t concretize prototypes that way,
we’d have to do something else to ensure that saved games are still loadable
(e.g., recursively store all prototypes used by a saved game in the saved
game) after a module change.
However, I’m not an expert on this part of the codebase. Brent is really
the person who is best qualified to comment on this.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Sorry, but I have no idea what ‘problem’ is being discussed. The only problem I am aware of is tinkerers poking around ‘under the hood’ and not being happy with what they see 
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
"I don’t spot a ‘rot’ attribute there. "
No, the train track diagram describes only the game-box.xml file. ‘rot’ appears to be an attribute on the [counter/] element in the scenario files and seems to have values in 60 degree increments. Sorry, my mistake, I was conflating the two file formats.
Brent: “…I am aware of is tinkerers poking around …”
Lighten up will ya? I conceded that history determines how we got here. I’m not being a purist, I’m just trying to make a suggestion (that I concede is not completely informed)
What I was talking about was the early part of the property string which appears to reproduce the hierarchy of the pane/tab/list structure in which the piece is to be placed.
I’m probably be wrong, but it appeared to me that
a.) this was redundant when destreaming from XML because the enclosing structure tells you where to put the piece.
b.) it appeared to be an artifact of the effect referred to by Joel where instantiation of the prototype is required
I’m probably jumping the gun, but it also seems to me that b.) is a side effect of the Decorator pattern - if you want to instantiate a decorator you also have to know how to instantiate the decorated object, so you end up embedding construction details of the decorated object in the decorator stream - ie. leading to the complex-relationships-in-the-buildFile that Joel referred to earlier in this thread. ie. parts of the property string refer to enclosing XML elements and vice versa.
My question was then:- if this structure is a side effect of the Decorator pattern (which I suspect it is) wouldn’t something more decoupled be appropriate? Something like:
use an XML specification for the PieceSlot instantiation and use only the enclosing XML to specify where it needs to go
use only a pointer to the separate (?) prototype chain parent for navigating traits
For the second, Chain of Responsibility is kinda close (although the dispatch would have to terminate at the first point in the chain where a handler was found). CoR doesn’t require any inheritance relationship between the types and their methods (aka traits) so it seems to me to obviate the need for instantiation.
Going on, the problem of old prototypes in files might then go away as (so far as I understand it) the old version of the prototype is also defined in the same file.
It’s just a suggestion. I noticed you guys discussing this issue and I encountered the problem of complex relationships between property strings and other parts of the buildFile when trying to manually rewrite the buildFile.
Thus spake “BobJames”:
I think this comes across as harsher than Brent intended. (Note the smiley
at the end.) We’re all a bit frazzled right now. Doing nothing but fixing
bugs for six months is enough to drive one to drink.*
Once the bugfixes for 3.1 settle down, I’m going to give what you’ve said
here some careful thought—architectural things take a bit more attention
than I have right at the moment.
BTW, you seem to be pretty knowledgeable w/r/t design—have you ever thought
about joining us? We could always use more programmers.
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Bob,
Humour was intended, however, I was trying to point out to Joel the danger of spending large amounts of valuable and extremely limited programming resources to ‘fix’ issues that are not actually problems and will only benefit a very small number of users.
I have grave concerns about any project to make the buildfile ‘more readable’
I believe (I may be wrong) it will require a large re-engineering task, with major architecural changes to every Decorator and the potential for the introduction of many bugs. The programming resources required would be better spent on other projects.
Very few people currently edit the buildfile manually, I don’t see that such a change is warranted.
Making the buildfile more readable will encourage many more people to attempt to manually change the buildfile, with a subsequent large increase in waste of user and developer time trying to track down bugs caused by people making errors in changing the buildfile. The Vassal Editor imposes controls on the contents of the buildfile.
Before starting on such a project, I think we need to ask some more questions:-
Why do people feel they need to manually edit the buildfile?
What are the deficiencies of the current editor that require manually editing?
Can we overcome these deficiencies through additional features in the Editor (e.g. Mass Piece Loader, Cut and paste of multiple adjacent items at the same level, etc.) that will remove the need for manual editing.
I am not sure which bit you are talking about here. Can you post a concrete example please? I have a good understanding of the struction of a PieceSlot entry, but I can’t reply to the rest of your post because I have no idea what we are talking about exactly I’ve checked a few modules and can’t see any such structures that match your description.
Cheers,
Brent.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Brent Easton”:
I’m only going to comment on this one right now, since I’m trying to clear
away some other junk at the moment:
I think this is due mainly to the fact that it’s so hard to edit the
buildFile manually right now; I wouldn’t take it as indicative of lack of
demand.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
But I think that is a good thing, not a bad thing!
If it is easy to edit the buildfile, then lots of people will, and there will be lots of broken buildfiles causing lots of really weird bug submissions.
I’ve had a couple of bug reports come through, that after a lot of wasted time, I have eventually decided that someone must have edited the buildfile. This will become an every day occurence.
It comes back to why do people need to edit the buildfile? Is there a better way to meet their needs that imposes the same level of control and error checking that the Vassal Editor imposes when editing?
I know one big reason was to add multiple similiar counters easily - That need should be satisfied by the Mass Piece Loader.
What are the other needs?
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Brent Easton”:
Right now it’s easy to screw up a buildFile by editing it because it’s
a ton of gibberish. If you do something wrong, it’s highly nontrivial to
spot.
If everything in the buildFile were structured XML, then
editing it would be much less error-prone, and
we could validate it against a schema at load-time, so as to catch
bad edits and prevent them from creating bug reports.
Right now, I want to be able to do scripting where I create all of the
pieces and piece images from within the script. In the future, it could
be something else—maybe I want to use XSLT for tranforming the buildFile
XML, e.g. My main interest here is having the buildFile in a format which
is easy to generate from a script and and easy to transform arbitrarily.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Meaning far less skilled users than now will feel confident to attempt hand editing.
Surely this just doubles the amount of work for developers? If I add or modify a component, I am now going to have to go and maintain this XML schema to duplicate all of the error checking that is within the Vassal component.
Is the XML schema going to 100% reproduce all of the error checking currently done by Vassal? If so, how much extra work is required in maintaining it? If not, then the bugs it lets through will be even more difficult to track down.
But your need is currently met isn’t it?
So there is currently no need for it, it might by nice in the future? Are there other ways to achieve this possible future need? Perhaps a utility to import/export XML?
We may have to agree to disagree on this one.
You will never convince me that making it simple and attractive for day 1 newbies to go in and start playing around directly with the buildfile is a good thing
B.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Brent Easton”:
No. The point of having a schema is to ensure the well-formedness of the
buildFile. It would be a total waste of effort to duplicate those same
checks in VASSAL. A big plus of validation is that you don’t need such
code at all.
I wrote an XML schema for ZunTzu module definition files. Once I get to
the point of incorporating that stuff for 3.2, I’ll point you to it so that
you can have a look.
No, it was quite hard to do the little bit that I did; I would have done
more if I’d been able to figure out the syntax.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
But that won’t find any real errors at all. I could write well-formed XML that contains rubbish in some of the fields. It will be validated against the schema, but will crash Vassal.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Thus spake “Brent Easton”:
There are a lot of restrictions you can impose with a schema—element
nesting, element ordering, number of repititions of elements, whether
attributes are optional or mandatory, what types of values they can assume.
I’m not saying that it will be possible to replace all checks with
validation against an XML schema. Expecing that valid XML won’t be able
to crash VASSAL is a much higher standard than we’re holding buildFiles
to presently. I’m certain I could write a buildFile which would crash
VASSAL.
–
J.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)
Joel,
You seem to have made my case quite nicely - you are confirming that the schema will need to be quite complex, duplicating the error checking in VASSAL, requiring much maintenance, and will not pick up all errors that will crash VASSAL that the Editor would not allow to be created in the first place.
Therefore, making the buildfile easily readable (i.e. XML) will require much initial work, much on-going maintenance of the schema, will make it attractive for less knowledgeable users to attempt it and will generate additional spurious VASSAL bug reports.
Thanks
Perhaps we should leave this here and let us both get some work done, and take it up again in the future once you start looking more closely at the issues and have done some more detailed analysis.
Cheers,
Brent.
Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org
Post generated using Mail2Forum (mail2forum.com)