I’m working in a module with pieces that will move through an irregular terrain and have some difficulties.
First of all i created a dynamic property called Move to restrict the movement of the units once its value is 0. For that, i used a trigger action with the filter Move > 0 .
My problem comes when i want to introduce different types of terrain that require more Move points to be crossed. I created a multizone grid and designated those difficult terrain areas, so once the pieces reach that position the dynamic property Move is reduced by one. However, this no reflects that correctly, because the reduction is done after the movement is done.
Example: I have one unit with 1 Move point left, so it pass the filter Move>0 and it can go into terrain that will cost an additional Move point.
Do you know any way to fix this?. Maybe changing the filter condition in a sentence that would check the future value of the Move property could work?.
Another issue related, is any way to make one position in the grid not accessible for certain units?. Lets say, in case i wanna differentiate between units with and without flying capability.
I don’t know anything about movement on terrain because I don’t use free movements in my module.
There might be a better way to do what you want but otherwise off the top of my head I can come with the following dirty trick:
Store the location of a unit before it moves in memory (but I think this is probably already stored in something like $oldLocation$, check the manual)
Let people move freely where the want but have a trigger fire after the move and send them back automatically (Send to Location trait) to oldLocation if they didn’t have enough move points to go there
Some sound or text label or just report trait could warn the player his move was illegal
I already tried the “Send to Location” trait, but i still have the same problem.
The question is that i created a trigger action with filter ( newlocation = difficult ) that decreases the “Move” dynamic property if you have that piece in that special terrain, but it won’t be activated unless i have the unit placed in the terrain already. It requires a keystroke that i used before being in that location.
In general, Vassal is designed to automate actions but not to enforce game
rules. So you would generally rely on players to keep track of the movement
costs, especially given that one is not constrained to move point-to-point,
but can drag a counter to its final location. So it is handled the same way
as in a face-to-face game with a physical board.
In particular, there isn’t really any support for specifying terrain
characteristics or costs.
This is something that comes up every so often, but the design work to
support it has not yet been undertaken.
In what you are doing, also be sure to provide some mechanism for undoing
the moves as well.
I tried to do this, but i had a problem with the command $Location$. Even when i just try to use it for reporting a movement, it doesnt appear. It only responds to $oldLocation$. This could be a bug?.
Another question related with your reply, how can i differentiate a calculation before or after movement?.
$Location$ is not a valid system property, correct. $LocationName$ should do what you want. The very best source for information on the available system properties is mycenae’s Module Designer’s Guide, available in the ‘Docs’ section of the website. A more concise listing is also available in the Module Design FAQ: vassalengine.org/wiki/Faq_mo … ounters.3F
To force a calculation to occur before or after movement, make the keystroke order explicit with a Trigger Action trait; for example, to do the calculation before moving have your Trigger Action do the following in ‘Perform the following keystrokes’:
<calculate_movement_keystroke>
<send_to_location_keystroke>
To have it perform the calculation after movement, reverse the order in the Trigger Action list.
Well, you can’t do it before movement. At least, I can’t think of a way that it will be functional.
I attached a test module that includes a movement check that does what you want. I have used three properties: Move, oldMove and ReturnMovement.
The first holds the number of available movement points a counter has before it moves.
The second copies the value of Move so it can be used if the unit moves in an “expensive” location. This property must be set as a Global Property or it won’t copy it’s value back to Move (due to Trait order in counters).
The third is just a way to, temporarily, disable the movement check. When we trigger Send to location to return the counter to the previous location, the movement check will be activated again and will mess the value of Move property. So we have to disable movement check before we trigger Send to location and re-enable it after the return to the previous location is complete.
This is just what i needed, and it works great now.
But i still have a problem with the Send to Location trait. When using the “Region on selected Map” it appears an error indicating that “OldLocationName”, or whatever name i put to the previous position, is not found.
If this is the complete error, meaning that after the = there is nothing else, then it means that “OldLocationName” value is null (empty). This happens when you place a game piece from the Game Piece Palette to the map. The old location was outside the map (no regions exist in the Game Piece Pallete) so it was set to null by default.
So, you try to place a game piece (probably UnitX in your example) in a region of a map. The game piece has less movement points than the region requires to let the piece stay. Send to Location is triggered and, because the value of “OldLocationName” is null, the piece stays in the new location and you get an error message.
What you can do to avoid this is to add a check before Send to Location is triggered. You should check if “OldLocationName=” and, if it is empty, you should Delete the game piece. A report saying that “the piece deleted cause it didn’t have enough MP’s” should be good too.
