It has been already stated here that using a Property for and Attachment Name is not possible, and i can figure why.
BUT
maybe could it be done with a property that can’t change during the game?
the BasicPiece property never changes, it is already defined while “creating” the piece (so, while expanding prototypes, etc) so (in my imagination) it should already be accessible when creating the Attachment trait.
This could make some thing much more easier (or less repetitive) if a Prototype could contains an Attachment like that.
My final question is: could it be possible to have a checkbox saying “use the BasicPiece name for Attachment Name” in the Attachment Trait?
Note that $BasicName$ is the name of the final piece that the prototype is included into. This, if the Attachement trait is in prototype P (with Attachment Name set to $BasicName$) and pieces A and B include prototype P, then the attachment names will be A and B, respectively, not P.
Often, you exactly want pieces to share an attachment name, which is why you would include the prototype. If you have a use case for piece specific attachment names, I think you might be doing something a little funny.
Suppose you want pieces C and D to be able to attach to both A and B. Then, if you want to use the Auto-attach feature, you need to define attachments A and B in both pieces C and D. That problem is at least O(n), and quickly become hard to maintain.
In short, I’m not sure I see the use case, but perhaps you can say a bit more?
Suppose you have about 40 miniatures, each of them has his own Card to be put on the table (you’ll never have all of them in a play, but you still have to define all of them in the module).
All the miniatures shares a lof of common traits, and so does the Cards, so the prototyping is a heavy part of building the module. The single pieces then will have just some different values for the same Properties (like LifePoint, Attack, etc), and a different image for each. And the Cards also.
A miniature and his Card will needs to be mutually attached, and shouldn’t attach to other minis/cards.
So, right now, my attachment trait, in a Prototype which is shared by both the pieces, looks like this:
(The card and the mini have the same Basic Piece name)
I cannot use the “auto-attach” feature, so I still need to find a way to generate a command when a piece (card or mini) is created in order to automatically attach it to the (already existing) relative other piece, … or to remember to manually click on the Menu Command while setting up the game.
With the “$BasicPiece$” option, i’ll just enable it, enable the “auto-attach” feature, and i’ll be done.
Well, I just noticed that the same behaviour i’d like could be obtained if the “auto-attach” option will obey to the “additional matching expression” instead of being “unconditioned”… and perhaps with a bit more flexibility and a wider use case.
Am I right?
Given that the expert here is you, and that in principle I agree (I’m a C/C++ programmer, after all ), I don’t see where the troubles may come from in my particular case.
But right now the auto-attach feature hides everything below it, so I can’t use it in this way.
I think that both the hypothetical options (auto-name, and contitional auto-attach) could have some value in flexibility and helping in keeping things easy.
If you at any point want to reference a piece or card by name, then there’d be an ambiguity. Also, if you at some point need to use the Refresh counters tool, it works best if the BasicName property of the pieces and cards are different.
You could define another property - say UnitName which is common between the card and the piece and select on
{UnitName==$UnitName$}
It is just that BasicName is rather fundamental to how Vassal works sometimes.
you are, of course, right - those options are not available when the auto attach option is selected.
I think one would need to consider the use cases.
In your case, if I understand it right, you - the module designer - is very much in control of when attachments occur. As I understand it, a user - or scenario designer - will “play” a card, and then the corresponding piece should appear and automatically be attached to the card so that users may track resources and the like on the card.
That is essentially what happens in Littoral Commander: Indo-Pacific. In that module, the cards are “played” by a scenario designer most often, by selecting a card from a deck and placing it into a user’s hand. The corresponding piece is then placed on the tracker card - and associated with the tracker card - so that a user can deploy the piece on the main board.
If that’s the use case, then you decide when to do the attachement, and you do not really need the auto-attach feature since you are in control.
(Don’t get me wrong, i’m not arguing, just explaining my thoughts).
You’re right, but this is either a new Marker to add in ~40 x 2 pieces or, if I’m being lazy, a Calculated Property in the prototype that will impact the module performances.
My general approach is this: when i’ll finish this big update/improvement of this module, i’ll forgot everything about it in about 6 months. At that point i’ll be like any new module user, which may want to setup a new scenario while having no idea of what the “Attach this card to his miniature” menu command will do, admitted that he cares to right-click and look at all the Menu Commands available in the “scenario edit mode” (which is when the round counter is < 1 and allows all the kind of “changes” that when the game starts you can’t do anymore).
So, while i don’t want to automate a lot the gameplay other than some annoying stuff like collecting back all the tokens scattered around in a turn, i would like to heavily automate the game setup, 'cause there’s a lot of things to do that are just “vassal related” and doesn’t mimic something you’re doing with the phisical game box.
(i hope you can understand me, i’m stretching my poor English to the max)
Consider how often the Calculated trait will be evaluated - according to the below - not very often - so no harm.
Yeah, that sounds very much like what I do with Littoral Commander: Indo-Pacific. The attachment of units to trackers is done when making scenarios. And the attachments happens automatically so I and others do not need to remember to do it (because we will forget ). I think you can perhaps get something out of looking at that module - shameless sefl-plug
), I don’t see where the troubles may come from in my particular case.
