What exactly do you mean by not changing the ‘meaning’ of the trait?
We have already changed the ‘meaning’ of the ‘Does Not Stack’ trait several times. It is already the ‘Does Not Stack plus set the Movement and Selection Policy and optionally ignore grid’ trait. Adding an option to control the stacking policy is completely in line with it’s current action. The current name ‘Does Not Stack’ is fairly misleading.
If we are going to add a new trait, It would make more sense to add a new ‘Stacking, Movement & Selection’ trait that does everything ‘Does Not Stack’ does, plus allow control of stacking, (plus other things?). Then just leave the current ‘Does Not Stack’ as legacy.
I agree. Getting this right now will save us pain in the future.
Is there a good reason for piling all of these attributes in to one trait?
Why not have “Does Not Stack” block stacking, and “Immovable” block movement?
That way, you can get any of the four combinations you want, and the names
are meaningful.
Historical (explains a multitude of sins). The ‘Does Not Stack’ trait has become the repository for several related options that do not affect the visual look of the counter and do not matter where they are in the trait order. It is really an ‘Options’ trait.
Don’t forget the ‘Restrict Selection’ trait plus the ‘Ignore Grid’ trait. So we replace one trait with four, plus have the original legacy trait?
I have no real problem with splitting DNS out into seperate traits - it does make sense.
But it raises concerns about the number of traits, and the order of them in the Piece Definer. It’s getting real hard to find what you want in there.
I would ‘Deprecate’ the Does Not Stack’ trait by removing it from the Piece Definer left hand box so you would not be able to add it to new modules, but it would otherwise work unchanged.
Actually, the more I think about splitting out ‘Does Not Stack’ into seperate traits, the more I like it. My thought would be to create three traits:
Movement Options
Selection Options
Stacking Options
The Movement Options would include both the Movement Restrictions (Never, Selection, Normal) and the Ignore Grid option.
Having seperate traits will make it easy to include some of the RFE’s on the books such as as making Non-movable changable by players/automation (i.e via a Property Expression).
Are we concerned about creating ‘too many’ traits?
My vote goes for three separate traits. Easier to find a name for such trait that deals with one aspect than for a monster trait that does many different things…
It also makes the traits easier to test (we should be witing tests for
our code) and easier to debug, since the classes which embody them will
be smaller.
And another reason: You can’t see a list of options for a particular trait
from the list of traits, so having traits which do more than one thing makes
it more difficult to discover which trait does what you want.
I think the GUI for this needs to be redesigned somewhat. I would not say
that we have too many traits. Some are poorly named right now. It might
also help if they were categorized or sorted some way.
You can’t really, because the Immovable trait can allow the piece to move (depending on selection option, and later on property expression) and the Nonselectable trait can allow pieces to be selected (depending on control keys). It’s the same argument as why you don’t want the ‘Does Not Stack’ trait to have an ‘Allow Stacking?’ option.
Those things should be separate traits. The traits I was referring to should
do nothing beyond preventing movement, preventing selection, and preventing
stacking.
I agree. This is a very old piece of code and the names of the traits have historically never changed, even when they have significantly changed or enhanced in functionality.
I think originally, traits where just added to the bottom of the list as they where created. Then for a while, an effort was made to put commonly used traits at the top of the list. Then later, an effort wss made to group similiar traits. The overall result is a non-alphabetised, unordered mess.
Once I can get clear of my dissertation (I’m writing chapters now), I’ll
suddenly have a lot more time for a few months. One of the things I plan
to do (maybe for 3.3?) is to go through every single dialog checking for
problems like this (and fixing layout problems).
Alphabetic would be a major improvement over the way it is now. What I’d
really like is a tree list, if we can come up with a useful categorization.
I do have one idea that might be useful for this, whatever way it is decided
to be ordered - it would also be good that the left side piece definer
imitates (within reason of the order), the way these traits should stack if
they were added to a piece
You will end up with 6 new traits just to do what ‘Does Not Stack’ does now (8 including RFE’s). There would be at least three different traits needed to control different levels of Immobility (Property Expression control is a RFE):-
Completely Immovable
Mostly Immovable (depending on Selection status)
Sometimes Immovable (Property Expression Controlled)
NonSelectable
Mostly NonSelectable (Control key controlled)
Sometimes NonSelectable (Property Expression Controlled)
Ignore Grid
NonStacking
I would perhaps prefer positive rather than negative trait names and use
Movable, Selectable, Stacking
and just set the default values for new pieces to have the traits
included/activated.
But that strikes me as somewhat counter to the general method of
creating pieces by adding traits, so this preference may not really
work with the standard piece creation workflow and model.
That’s the danger. As programmers, it makes perfect sense to make a trait for each binary attribute a piece can have, but users will be confused because some combinations are very counter-intuitive.
For example: Immobile+stacking. Users will get this most commonly, if they’re looking for a trait to make a terrain marker. Then we’ll start get module bug reports saying “Why does my bridge come un-stuck when an army moves over it?” It’s fine to have this capability (it’s what started this thread) but it should be chosen by the user on purpose, and not be the default that users then have to figure out how to disable.
Here’s another example: non-stacking+non-selectable. Technically, it’s mobile but there’s actually no way to move it!
I think Brent’s idea is best: make a new trait that controls all of these aspects at once. That way the properties dialog for the trait can guide the user to make intuitive choices. Then the current Does Not Stack trait becomes redundant and we deprecate it.
I’m not sure this one is a problem. A ‘Never Moves’ but ‘Stackable’ piece just means that other pieces moved onto that hex will stack on top of it, but the ‘Never Moves’ piece can never ‘un-stick’ and be moved out of that hex.
True, but it’s not such a great problem. You can select that combination already in the current Does Not Stack trait (Selection = never, Movement = Normal).
Why not just beef up the ‘Does Not Trait’ and rename it on the Piece Definer? I can see one reason - the way the Type is stored in the current Does Not Stack trait is somewhat cryptic and not particularly amenable to enhancements.
I’m not sure I was pushing for just the one super trait. I was more tending towards breaking it into three :- Movement restrictions, Selection restrictions, Stacking restrictions.
What would we call such a beastie?
Movement, Selection and Stacking options.
Currently, Ignore Grid is only available on a Does Not Stack Piece, what would be the implications of allowing Stacking pieces to ignore the grid? Hopefully Module designers would use that wisely.
