NON_MOVABLE

So,

what was our consensus on the Does Not Stack/Movable issue? Or is this one of those things we never resolve, so it never gets fixed :smiling_imp:

There seems to be two ways to go:

Option 1:
Add ‘Allow Stacking’ to the current ‘Does Not Stack’ trait and rename it something meaningful such as ‘Stacking, Movement and Selection Options’. Improved name required!

This option is simple, but just continues to cramp up an already very busy trait, making longer term enhancement more difficult.

Option 2:
Deprecate the current ‘Does Not Stack’ trait and replace it with multiple traits.

  • Stacking Options
  • Movement Options
  • Selection Options

This would allow more flexibility and open up the way for future enhancements such as Movement and Selection controlled by Property Match Strings.

B.

The third option - never resolve :slight_smile:

Seriously the second seems the right thing to do. With all this property
stuff being able to populate all over the place more and more, you can see a
sort of coalescing of traits becoming more fluid with each other through
property usage while adding a lot of diverse possibilities at the same time

  • a pro, albeit it is raising complexity - a con, but unlikely to be
    exploited by many designers.
    So the change would be minimal in impact for most where that is concerned
    and when used in basic form “as is” very straightforward and understandable
    in their design intent

Post generated using Mail2Forum (mail2forum.com)

No consensus yet, but of course the person who leaps in and does the work gets the most votes. To me the question comes down to whether module designers are most like to use a single one of these behaviors, or whether the most common case is to use more than one. If it’s most common to use a combination of these behaviors, then it will be less confusing to put them into a single trait. If it’s most common to only use one (e.g. don’t move but stack normally, or don’t stack but move normally) then splitting into separate traits removes clutter.

rk

Post generated using Mail2Forum (mail2forum.com)

Hello,

Since I am interested in the DoesNotStack trait, having reported some weird behavior lately, I wanted to had my 2 cents there :slight_smile:

  • Traits numbers/organisation - time loss/confusion
    True, it could be confusing to designer that were used to the DNS trait as it was and as it is now to have 3 new traits for selection, movement and stacking options. But here we are discussing about designer, people that are ready to dedicate a big chunk of their freetime to design modules… And I think that having three modular traits instead of 1 jack-of-all-trade misnamed trait is not per se a big trouble and a bit loss of time figuring out how they interact with each other. As many already noted it will make prototypes more “readable” by others as one can then at the first glance determine what specific behavior are affected by a given list of traits.

  • Deprecating old traits

Now comes the slightly off topic remark :wink:
Some of you wrote about deprecating old traits… Now I ask, why don’t we have a built-in features in the editor that warns the user, while parsing the build file that the module is using deprecated traits, giving the list of the deprecated traits used (easier then to look for them in the prototypes & pieces definitions).

Having a tool to list in a log file all deprecated traits and where they are used would be great but that just a “nice to have” where as the warning about using deprecated traits and the list of them is a “should have”.

If we had such a feature built in the editor, then module designer will get a warning when they use the new version of the editor and can then choose to either “upgrade” their module manually by using the new traits or keeping their module in a compatible mode using the deprecated traits.

Now we could also have a options in the module editor to either show or hide deprecated traits in the list of available traits one can use for units. I would hide them by default (the deprecated traits would then only be displayed in the list of traits attached to a given prototype/unit). Trouble is… how are we then supposed to get help on this deprecated trait since the help button show the help page of the trait selected in the left hand list of available trait… duh! :confused:

There should also be a list/file/anything built in vassal to indicate which trait became deprecated in which version/build. Such an information could be provided to the user when he gets the warning about using deprecated traits.

Example

"[color=darkblue]WARNING, this module is using deprecated traits:

  • DoesNotStack: deprecated since version 3.1.x (build xyz and above). It has been replaced by the MovementOptions, StackingOptions, SelectionOptions traits.
  • MyOldTrait: deprecated since version 3.2 (build xyz and above). It has been merged with JackOfAllTrade trait.
  • MyOlderTrait: deprecated since version 3.1 (build xyz and above). It has been merged with JackOfAllTrade trait.
  • MyEvenOlderTrait: deprecated since version 3.0 (build xyz and above). It has been merged with JackOfAllTrade trait.

Use the Tools/Deprecated traits/Used in the module menu to view the list of prototypes and game pieces affected."