Haziness. As you can see in the pic, two features that I have introduced as layers – red attack arrows popping out above the units, and red numbers appearing on their left side to mark step losses – in some cases make the unit image hazy, and sometimes they don’t. For example, the cavalry brigade in the center of the display is hazy whereas the larger stack in the bottom is not. Haziness disappears immediately if I remove the arrow or the numbers. Is there anything I can do about this, apart from looking for an exorcist?
In the module, Vassal marks units that are hidden with a ‘H’. Since in this game units are almost always hidden, I would like to mark units that are NOT hidden and leave those hidden unmarked. How can it be done?
First off, I would say your unit images are relatively small 41x41 pixels. I would make them at least 64x64.
Secondly, you seem to have defined them all as Cards rather than Piece. Technically, that is OK, but conceptually a little odd. It means you define the MaskTrait in each and every piece rather than in a prototype where it may be easier to manage.
Thirdly, you put the pieces in a Deck, which I’m not so sure make sense. A Deck is a special container from which you are meant to “draw” a card. However, for the game in question, I think what is more likely, is that there are specific units enabled at specific locations at specific times (Order of Battle). One way to handle that, is to make PredefinedSetups (.vsav files) and put them in the module. Of course, if reinforcements arrive at certain points, then those could be placed on a track, or the like, by the PredefinedSetup. Another way is to make full-blown OOB charts.
Finally, I suspect that because your hit-point and attack arrow images have an embedded colour profile, and not a standard sRGB profile like your unit pictures, that that can cause some problems for the Java Graphics2D engine. Perhaps try to normalise all your images to use a standard sRGB colour profile.
Oh, and perhaps also consider to change all file names, etc. to English - that will make it easier for non-Italians to follow your logic etc.
The H you see is what you specify in the Display Style=Use Image of the MaskTrait of all units (this traits should be confined to a prototype so you do not need to change it in every single piece). If you do not want that image shown, then do not add it. If you want the owning faction to have an indication that the piece is not hidden, then one way would be to add another LayerTrait with an image to indicate when the piece is not hidden. In that LayerTrait set Follow to true, and set the expression to be something like
and leave the first layer image empty, and set the second layer image to the indicator image to show to the owning faction. Note, you will need a prototype per faction:
German Empire prototype
MaskTrait …
MarkTrait: name = ‘Faction’, value = ‘German Empire’
Also, I see you have a PieceWindow while you also have a Map (Tray) with your Decks of pieces. This seems redundant. As you’ve probably noticed, you cannot expand a Deck, which makes it hard to select specific pieces. Aide de Champ very much used trays for pieces and such, but that’s not how VASSAL would typically do it. Rather, your PieceWindow works as a factory from which you can generate any piece you like. PieceWindows can have sub-, sub-sub-, sub-sub-sub- etc. containers, so you can easily represent a piece hierarchy.
thanks for your comprehensive response. As you probably know, most of the issues you point out stem from the fact that this is a conversion of my and Dori’s old ADC2 module.
I tried to switch to hand-drawn arrows and numbers in the hope that they fulfill the standard sRGB profile you mentioned, but Vassal mulishly keeps displaying hazy counters. I’ll carry on my quest for an exorcist and in the meantime I’ll strive to coexist with cloudiness.
Finally, I appreciate your instructions to add another layer trait with an image to indicate when the piece is not hidden, but programming is inexplicable to me. Perhaps you or somebody else wouldn’t mind translating your instructions in terms of Vassal interface…?
You can use the images you have now, just re-code them with a sRGB colour profile. You can do that, for example, with Gimp (see also Tools for module developers): When you open the image, it will ask you if you want to convert the colour profile. Say yes, and save to PNG again. Then replace the image in the .vmod archive.
The problem with blurry pieces is not related to the colour encoding.
Then I though it had something to do with the pieces being Cards rather than Pieces, and while it may have an effect, it is not the whole story.
Rather, now I believe it is because the images are very small (41×41 pixels).
The issue with marking pieces that have been unmasked (rather than those that are masked), was solved more or less along the lines I suggested earlier. However, I had to make dummy image to show as the ownerImage when masked. Fairly simple - a 1×1 pixel completely transparent image.
I also digged a bit deeper into some other issues in your module
You defined pieces as Cards and they start in Decks. As mentioned earlier, that doesn’t make much sense, though it may work conceptually.
Many of your pieces had recurring traits which should really be put into prototypes
You generally have a pattern of using a LayerTrait to show information, and
an activate key to show the information
and some some keys to manipulate the information
while not unreasonable, it does mean that your LayerTrait encodes the states in a not so straight-forward way, and also that the piece constantly changes size, making them “jump”.
I’ve editted (or rather patched) your module. You can find the result here. There, you will also find the Python script I used to do this with.
In this patched module, I
Replaced all the Cards with Pieces
The Tray board now has a RegionGrid with Regions for each slot.
The Return to tray command is a simple SendtoTrait
It is easier to pick out individual pieces
A marker is show for pieces that have been revealed - rather than those that are hidden.
I removed the set-ups, because they are not compatible with the change from Cards to Pieces.
Oh, and all pieces starts masked by their owning faction. This is actually not possible to do through the regular Editor - one has to hack the rather obscure trait encoding - or use my pywargame Python module
I would strongly encourage that you make higher resolution graphics - in particular the pieces.
Generally, I like the saying
“Give a man a fish, and he will be fed for a day. Teach a man how to fish, and he will be fed for a lifetime”.
In this one case, I made an exception because the challenge was daunting - but do not expect it to set a precedence
you are quite the expert, a veritable rocket scientist of the Vassal engine
Your remake of my humble efforts is a paragon of conceptual lucidity and operative cogency; To the extent, in fact, that my poor self understands almost nothing of it any longer. You have raised the mystery of the Vassal Fair to Lovercraftian proportions.
Anyway, I thank you for your overwhelming contribution and I will see if and what I am able to do with it.
I did another update - this one exports the old save files to the new setup and adds them as predefined set-ups to the module. Should save you some hassle.
Lorenzo:
You asked about fuzzy images. Something that may be lost in all the words is it may be that your images simply may have too few dots in them. If it were me, I’d set up my scanner for a higher density, rescan for more dots, and save as a png, not gif or jpg. Of course, if you got your images from somewhere else, you probably will have to live with it.
Christian:
I did not open this guy’s vmod, but I did read your messages with mild interest. Two items made me pause, and I’d thought I’d ask to perhaps learn something.
You did not like how this guy uses a deck. What did he do with a deck that you objected to?
You make a hard distinction between a piece and a card. Setting aside a card’s complimentary mask, what makes them different for you? What characteristic does one have that the other doesn’t?
I think you are right. It seems to be a problem that the images are very small (42 × 42 pixels). In my modified version, the haziness doesn’t really show up with the layers, but do manifest itself when the pieces are rotated. I guess the Java Renderer has to do interpolations when drawing a rotated image, and since there are so few pixels to interpolate between, the result is a blurred image. I would say the images should be at least 64 × 64 pixels.
Oh, and I don’t think Lorenzo did a scan of a counter sheet, but rather used existing images.
Try opening the module. I think you will get some of the answers to your questions.
Lorenzo made all pieces cards, and made the piece tray contain decks. Since you can not visually select cards from a deck, it makes it a bit cumbersome to select pieces and place them on the board.
What Lorenzo ended up doing, was to, at run-time, replace cards with pieces, which means that there’s a duplication of information. That can easily be avoided by using pieces rather than cards.
By way of example, I suggest you take Lorenzo’s original module and my modified version, and open them up. Take a look at the piece tray and see how that behaves differently in the two versions. Then open the modules in the editor and look at the differences. I believe my version is simpler and more maintainable.
Technically, you are right that the main difference between a card and a piece is that a card has a MaskTrait. But that trait is per piece. In many cases, it is much more desirable to make the MaskTrait part of a prototype, and then include that prototype into your piece. That means, if you want to change some aspect of the MaskTrait, or associated traits in the prototype, you only need to do it in one place.
Conceptually, a unit, in this type of game, is not a card that you draw or select from a deck. Units are rather pieces that are available - often in a fixed fashion.
and I will see if and what I am able to do with it.