Package VASSAL.build.module

Class BasicCommandEncoder

java.lang.Object
VASSAL.build.module.BasicCommandEncoder
All Implemented Interfaces:
Buildable, CommandEncoder
Direct Known Subclasses:
BshCommandEncoder
public class BasicCommandEncoder extends Object implements CommandEncoder, Buildable
Although it is the CommandEncoder which handles the basic commands: AddPiece, RemovePiece, ChangePiece, MovePiece, this class is most commonly needed by module designers who want to make custom "Traits" for game pieces because it contains createDecorator(java.lang.String, VASSAL.counters.GamePiece), the BasicCommandEncoder.DecoratorFactory for Traits, which are usually internally referred to as Decorators because they are implemented using the Decorator Pattern. If a module is to add its own custom game pieces, it will need to override the createDecorator(java.lang.String, VASSAL.counters.GamePiece) method, and use this pattern to create any custom Traits: 
   package MyCustomClasses; // Your package name here
   public class MyCustomCommandEncoder extends BasicCommandEncoder {
     public Decorator createDecorator(String type, GamePiece inner) {
       if (type.startsWith(MyCustomClass.ID)) {
         return new MyCustomClass(type, inner);
       }
       //... more custom traits, possibly

       // Now allow BasicCommandEncoder to run so that "normal" Traits process
       return super.createDecorator(type, inner);
     }
   }
Then in the buildFile (XML) for the module, the VASSAL.build.module.BasicCommandEncoder entry is replaced with an entry for (in the example above): MyCustomClasses.MyCustomCommandEncoder The class files are placed in a MyCustomClasses (package name) folder in the Zip structure of the VMOD file, and At that point the new trait can be imported into a piece as MyCustomClasses.MyCustomClass (package name followed by class name). Less often, the createBasic(java.lang.String) or createPiece(java.lang.String) methods could be overridden to allow instantiation of custom GamePiece classes.