Can a Map Zone have different properties than the Map it is on?

Module Design
10

Hi Frank,

Are you moving away from ZunTzu and into VASSAL? Great. Perhaps you want to check out How to convert to a module from other tools to VASSAL to get going with converting ZunTzu modules to VASSAL.

How about something like this:

  • On your map, set the Key Command to apply to all units ending movement on this map to a named command - say updateOnEnd
  • Define your zones
    • Add a property - say MovementTrailsEnabled to the zones
      • For zones where movement trails should be enabled, set this property to true
      • For zones where movement trails should be disabled, set this property to false (or simply do not define it)
      • Important: Neither the map or board where the zones reside, nor the module should define the property, if you leave the property undefined for some zone - otherwise, the pieces will pick up the value from higher up the hierarchy.
  • In your pieces - or preferably in a Prototype
    • Add the MovementTrailTrait
      • Set the TURN ON key command and TURN OFF key command to some named commands - say turnOnTrail and turnOffTrail
    • Define two TriggerTraits
      • In both traits, make sure that Menu Command is not set
      • In both traits, set Key command to the end-movement command defined above - e.g., updateOnEnd
      • In the first TriggerTrait:
        • set Perform these Key Commands to the command to turn on the movement trail - e.g., turnOnTrail
        • set Trigger when properties match to match when the zone property is true - e.g., {MovementTrailsEnabled==true}
      • In the second TriggerTrait:
        • set Perform these Key Commands to the command to turn off the movement trail - e.g., turnOffTrail
        • set Trigger when properties match to match when the zone property is not true - e.g., {MovementTrailsEnabled!=true}

You can of course flip the logic and define the property MovementTrailsDisabled on the zones where you do not want movement trails, and then adjust the trigger’s logic too.

I haven’t tried out the above approach, but I think the logic is sound.

Internally, the TriggerTrait is called a macro trait. That’s because it provides classic flow control capabilities such as

  • if ... then ... (the else ... part must be implemented in a second TriggerTrait as above)
  • for i in ... do ...
  • while ... do ... (or do ... while ...)

Yours,
Christian