I was hoping for some advise on this. I have never made a module before and now I am making one where a single upgrade effects all tokens in play and future tokens that come into play. I need a method that will reflect this upgrade.
I would like to use dynamic properties but I don’t know how to assign values to tokens on start. Markers are static, so using them for individual stats that may change due to the upgrade I don’t think will work.
That leaves me with with multiple layers (and I mean multiple!) with 5 stats that all can individually be upgraded leaves me with way too many layers per piece. Any suggestions?
You can attach a Property Sheet to a piece and include a line for each stat you want. Once the Property Sheet is in place, you can right click the piece image while editing the piece, select the Property Sheet and enter a value. This will remain as the piece’s starting value in the game.
Dynamic Properties have a min / max starting value so you can use that as well. You may also wish to use Global Properties …especially is you wish to carry over those values to other areas beyond just the piece itself. For example, if you had a score board of some kind, you’d want to create Global Properties for your stats so you could display those stats on the score board.
You can use Labels to reflect the values on the piece. It’s simple text so it isn’t very exciting to look at but it works.
I suspect you are looking at a combination of a dynamic property for each piece to hold the current value for that piece, plus a global property for each player/side to hold the current “start value”. Then where you set the DP initial value enter the name of the GP instead of a fixed value? I have not tried that and am not sure it would work but it would be the first thing I would try if I wanted to do what you seem to be talking about.
The GP is “dynamic” so can be changed during play, but is accessible by all pieces on the map (or, more correctly, in the game). The DP, unless there is a way to hack around this, is really just a separate “local dynamic variable” for each piece that has that particular DP.
Then you can display the DP value with a text label. As suggested that is much simpler than using layers, although you are limited in font selection - and I can say from experience that you need also to be prepared for differences between the same font on marginally different operating systems or versions of java or even individual character sets.
Are you sure it is really too many?
You really need one “layer” trait per stat, so only 5. Then each of those 5 layers needs to have as many images as the stat can have values, with the layer image set to track the DP value.
Then you can wrap the whole thing up as prototype and have a single definition that you can apply to all the pieces (or at least all the pieces on each side). So you have only one trait list to build and maintain.
For instance… I have a module with a layer trait with something like 32 possible images tracking a DP value.
I chose to go an easier route and made three upgrades and used a global key command that would upgrade every piece on the board with the new upgraded piece. Less choices but easier to manage i guess.
And holy moly wallace… I would shoot myself as opposed to making a piece with 32 layer levels!
From: Michael Kiefte mkiefte@dal.ca To: VASSAL Engine Forums Mailing List messages@forums.vassalengine.org Sent: Saturday, December 20, 2008 5:00:15 PM Subject: Re: [Module Design]Re: Best way to upgrade stats on all tokens/player side?
Funny. That’s what I made it for too. I figured there was no way it was going to be above 39, however. I did include a -1, so I guess I had 40 levels. -1 was unlikely, but theoretically possible.
I did a lot of editing of the buildfile in emacs, so I kind of cheated.
I would actually be very interested in how to edit modules from a text editor where you can use all the refactoring and formatting tools, rather than using the module editor GUI. There are some thing that are just plain painful to do graphically that a good code editor can whiz right through. (and vice versa of course)
Well, not right away, too many other things going on, but at some point it would be a good tool to have.
I had to look very closely at the buildfile format when I wrote the ADC2 import code, so I had a bit of an advantage.
If you absolutely felt a dire need to do this, I would recommend that you save a backup, make a change in the editor to see how the buildfile changes, and do something analogous in the editor. If you’re skilled at regular expressions in something like emacs or vi, you can do some very creative things. I definitely would not create pieces or traits in this way as there are some invisible things going on when you create these in the editor. I’ve used it to create image definitions, which is completely harmless. Also assinging images to a bazillion (e.g., 40) layer levels in this way is also harmless.
I’ll also dig out emacs if I have to change the same thing in every piece, but it’s not appropriate to assign a prototype definition and editing all pieces in a group would completely mess things up (replace with other is a good example). I don’t really fault the editor for this as I can’t imagine a way to do that conceptually.
(By the way, if you’re wondering why I use replace with other instead of layers, it’s because flipped units can then behave completely differently without resorting to complicated triggers).
But I definitely do not recommend doing this. Sometimes, to be really sure, it really is better to just click on each element one at a time, so that you know you haven’t botched it in some subtle way.