# Ways to trigger an effect after a piece is deleted, from a command initiated on the piece being deleted

**URL:** <https://forum.vassalengine.org/t/ways-to-trigger-an-effect-after-a-piece-is-deleted-from-a-command-initiated-on-the-piece-being-deleted/90591>\
**Category:** Module Design\
**Created:** [October 16, 2026, 1:13am UTC](https://forum.vassalengine.org/t/ways-to-trigger-an-effect-after-a-piece-is-deleted-from-a-command-initiated-on-the-piece-being-deleted/90591 "2026-10-16T01:13:08Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![Benkyo](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/benkyo/32/3289_2.png) [@Benkyo](https://forum.vassalengine.org/u/Benkyo)\
**Post date:** [October 16, 2026, 1:13am UTC](https://forum.vassalengine.org/t/ways-to-trigger-an-effect-after-a-piece-is-deleted-from-a-command-initiated-on-the-piece-being-deleted/90591/1 "2026-10-16T01:13:08Z")

</div>

I have a piece on a mat, and I want a command initiated from the piece that results in the piece being deleted to also cause the mat to recount its cargo and execute another effect (details irrelevant), _after_ the piece is deleted. Is this possible?

I suppose a workaround is to have the piece move itself off to an offboard holding area to resolve the new count before deletion. If there’s a cleaner solution, or one more generically applicable, please let me know.

---

<div class="post-metadata">

**Author:** ![clanmacrae](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@clanmacrae](https://forum.vassalengine.org/u/clanmacrae)\
**Post date:** [October 16, 2026, 2:46am UTC](https://forum.vassalengine.org/t/ways-to-trigger-an-effect-after-a-piece-is-deleted-from-a-command-initiated-on-the-piece-being-deleted/90591/2 "2026-10-16T02:46:21Z")

</div>

I would think you just reverse the trigger processes to do the recount and the other executable effect first, then delete, in that order.

---

<div class="post-metadata">

**Author:** ![Benkyo](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/benkyo/32/3289_2.png) [@Benkyo](https://forum.vassalengine.org/u/Benkyo)\
**Post date:** [October 16, 2026, 2:48am UTC](https://forum.vassalengine.org/t/ways-to-trigger-an-effect-after-a-piece-is-deleted-from-a-command-initiated-on-the-piece-being-deleted/90591/3 "2026-10-16T02:48:14Z")

</div>

(The recount doesn’t work when the piece is still present, unless I implement the intermediate step I outlined above.)

---

<div class="post-metadata">

**Author:** ![clanmacrae](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/c/e8c25b/32.png) [@clanmacrae](https://forum.vassalengine.org/u/clanmacrae)\
**Post date:** [October 16, 2026, 3:48am UTC](https://forum.vassalengine.org/t/ways-to-trigger-an-effect-after-a-piece-is-deleted-from-a-command-initiated-on-the-piece-being-deleted/90591/4 "2026-10-16T03:48:05Z")

</div>

Tricky, that.

---

<div class="post-metadata">

**Author:** ![jrwatts](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/jrwatts/32/6972_2.png) [@jrwatts](https://forum.vassalengine.org/u/jrwatts)\
**Post date:** [October 16, 2026, 4:33am UTC](https://forum.vassalengine.org/t/ways-to-trigger-an-effect-after-a-piece-is-deleted-from-a-command-initiated-on-the-piece-being-deleted/90591/5 "2026-10-16T04:33:59Z")

</div>

I would think you could just put a `Trigger Action` on the mat that uses a `Global Key Command` (unless there’s a mat-specific way to trigger a command on a cargo; I don’t know the details of mats and cargo) to call the `Delete` command on the piece and then the recount command on the mat.

---

<div class="post-metadata">

**Author:** ![Benkyo](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/benkyo/32/3289_2.png) [@Benkyo](https://forum.vassalengine.org/u/Benkyo)\
**Post date:** [October 16, 2026, 4:42am UTC](https://forum.vassalengine.org/t/ways-to-trigger-an-effect-after-a-piece-is-deleted-from-a-command-initiated-on-the-piece-being-deleted/90591/6 "2026-10-16T04:42:22Z")

</div>

Ah, bouncing a GKC off a control piece to finish the sequence, yeah, that should work using a flag or attachment to specify the piece being deleted, thanks.

---

<div class="post-metadata">

**Author:** ![Benkyo](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/benkyo/32/3289_2.png) [@Benkyo](https://forum.vassalengine.org/u/Benkyo)\
**Post date:** [October 16, 2026, 2:07pm UTC](https://forum.vassalengine.org/t/ways-to-trigger-an-effect-after-a-piece-is-deleted-from-a-command-initiated-on-the-piece-being-deleted/90591/7 "2026-10-16T14:07:51Z")

</div>

In the end I went with temporarily moving the piece off the mat - just much easier to implement with all the traits already present.

---

<div class="post-metadata">

**Author:** ![akulkis00](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/akulkis00/32/11366_2.png) [@akulkis00](https://forum.vassalengine.org/u/akulkis00)\
**Post date:** [October 17, 2026, 5:18am UTC](https://forum.vassalengine.org/t/ways-to-trigger-an-effect-after-a-piece-is-deleted-from-a-command-initiated-on-the-piece-being-deleted/90591/8 "2026-10-17T05:18:18Z")

</div>

that makes sense.

the deletion doesn’t actually finish until the deletion code exits.

so to get the mat to recount properly, the deleted unit has to be gone off the matt, but not deleted from the records, because the code to trigger the mat recount has to be done within the deletion algorithm.

Even with some sort of spawn(function\_name, arg1, arg2, … ), your way is probably much more efficient (changing the unit’s location to a mortuary location before finishing the deleition is going to be much more efficient than spawning the recount function as a separate process that must absolutely wait before the delete function returns before the it (the recount function) can begin execution.

In other words, your kludge is actuallly a superior hack compared to the CS-school “correct” method of making the last line before returning be

(spawn(recount))

and the first line of recount being a

wait() of somesort to prevent execution before its caller completes.

(I don’t know the java libraries like I know the system call libraries in C, so I’m writing in general terms, not specifics. Think of spawn() being some java function that does something eqiuvalent to the Unix fork() system call.

---

<div class="post-metadata">

**Author:** ![akulkis00](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/akulkis00/32/11366_2.png) [@akulkis00](https://forum.vassalengine.org/u/akulkis00)\
**Post date:** [October 17, 2026, 5:21am UTC](https://forum.vassalengine.org/t/ways-to-trigger-an-effect-after-a-piece-is-deleted-from-a-command-initiated-on-the-piece-being-deleted/90591/9 "2026-10-17T05:21:00Z")

</div>

The only problem with a trigger action is that it could lead to a race condition (that is, the recount() function can randomly count the piece as still being on the mat before the delete() function finishes deleting the piece from the mat. It’s really implementation dependant, and unless the vassal documentation says that a trigger executed as the last line of function is GUARANTEED to not run until after the calling function exits, I would NOT count on that behavior being true all the time, every time.

Race conditions generally create intermittent bugs that are difficult to track down.

---

<div class="post-metadata">

**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\
**Post date:** [October 17, 2026, 11:11am UTC](https://forum.vassalengine.org/t/ways-to-trigger-an-effect-after-a-piece-is-deleted-from-a-command-initiated-on-the-piece-being-deleted/90591/10 "2026-10-17T11:11:29Z")

</div>

> [@akulkis00](#):
>
> Even with some sort of spawn(function\_name, arg1, arg2, … ), your way is probably much more efficient

You can’t know this without consulting the code and profiling.

> [@akulkis00](#):
>
> The only problem with a trigger action is that it could lead to a race condition

There are no race conditions for command execution in V3, due to the fact that command execution is single-threaded. There cannot be data races on a single thread.
