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.
I would think you just reverse the trigger processes to do the recount and the other executable effect first, then delete, in that order.
(The recount doesn’t work when the piece is still present, unless I implement the intermediate step I outlined above.)
Tricky, that.
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.
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.
In the end I went with temporarily moving the piece off the mat - just much easier to implement with all the traits already present.
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.
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.
You can’t know this without consulting the code and profiling.
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.