$OldMap$ not initialized

Technical Support & Bugs
1

Vassal 3.5.3

Unit is created in at start stack in a map window to hold variants
A global key command triggers the variant

Unit includes following traits:
Delete (on variant setting)
Report (on variant setting) - Format uses $OldMap$ (example desired report) “Variant-Alpha deletes UNIT A from Force Pool”

$OldMap$ returns nothing…

However, IF I manually move the unit within the map (exploring why this is happening) and THEN trigger the global key command
THEN $OldMap$ returns a value

2

Yes, old(Something) on a piece that is fresh off the pallet is null (e.g. a unit created in a start stack).

Is there a reason why you are trying to report the deletion on “OldMap” rather than “CurrentMap” ?

3

After deletion, $CurrentMap$ is null.

4

After a piece deletes itself, no further traits will be processed from that piece.

I think your report trait is executing before the delete, which is what I would suggest anyway; then you can use CurrentMap.

Does that help ?

5

Given the need to report information on a unit that may never have been moved, the lack of initializing some of these parameters if problematic.

Thus, IMHO some of the key “Old” parameters should be initialized.

6

I was reporting AFTER the delete action. I tested using both $CurrentMap$ and $OldMap$ before I posted my initial report - neither worked.

There appears to be no way of using system parameters to report information on a piece that has never moved prior to deletion.

While I could change the order of the report to report prior to deletion (as a workaround), having an engineering background, I really don’t want to report an activity prior it actually occurring. I’ve seen that approach lead to problems in the real world. (Example, you report something happens, but it’s possible the activity you are reporting on fails (for whatever reason)).

A classic debugging technique (for instance) is to report both PRIOR to and AFTER an event of interest…

7

I am surprised to learn that CurrentMap may be null in any circumstances except when a piece is on the palette; I do tend to deal with pre-set scenarios where pieces may well have been moved on the board already. Even so, a surprise and I haven’t been able to replicate it myself yet.

I appreciate your engineering discipline. That said, I stand by my statement that DELETE removes the piece and stops further processing by that piece. It is not possible for the piece itself to report after it has deleted itself. For a report after delete, it would have to be some other reporting mechanism (GKC on another piece, comes to mind).

If I’ve understood your description correctly, your piece is defined with a Delete trait followed by a Report trait, both listening for the same Key Command. In this case, you see a report because Non-trigger traits execute first, in bottom to top order, followed by trigger traits in top to bottom order. In your case: Report, followed by Delete, no trigger traits.

Mark

8

I think the solution to this issue is to treat the Delete trait as a Movement trait (which it essentially is) and have it set the Old properties prior to it executing.

This will ensure that oldMap is set to the Map of the board where the piece is being deleted from, even for newly created pieces that have not had oldMap set yet.

9

Thanks Brent, that would be great! I look forward to seeing that fix…

10

Sorry about my incorrect “advice” - until now I had failed to understand that the Report trait is special and always fires after Delete and all other traits.

11

Mark - no worries, I appreciate your offering advice.

12

I’ve uploaded 3.5.4-SNAPSHOT-35470aa2e as a test build: vassalengine.org/~uckelman/tmp/

13

Tested -

It appears that both $oldMap$ and $oldLocation$ are still null

14

VASSAL 3.5.4-SNAPSHOT-bug14152-d22186aba

As of this version, the functionality is working
$OldMap$ is set
$oldLocation$ is set

BUT…

My original post got the case of “old” wrong…
Per the designers guide, it should be $oldMap$ not $OldMap$

15

Except there appears to be inconsistencies in the Designers Guide…
The below uses “Old…” with capital…

…ReferenceManual/BasicPiece.html#top

16

So the capitalized ones (e.g. OldLocationName, etc) are set in the properties of a Game Piece whenever it is moved.

The non-capitalized ones (e.g. $oldMap$, $oldLocation$, etc) are ONLY available during execution of a “Report State” trait.

This is legacy behavior, but functional legacy behavior, and the docs are AFAIK correct.

Brian

17

Brian - thanks for the clarification. Would be good to add this snippet to the designers guide as it’s easy for module developers to trip over…

1 Like