[messages] [Developers] Re: How to become a Vassal developper

viewofheaven viewport2heaven at yahoo.com
Wed Nov 2 21:36:02 MST 2011

"Brent Easton" wrote:
> I don't understand how this will help. The entire point of the
> Recusion Limiter is to catch cyclic loops as well as self-recursion.
> Controlling Stack depth is a common technique that provides a
> reasonable compromise.

If RecursionLimiter is to "limit recursion", it will do just that, and
nothing more. Say FunctionA calls itself, that would involve a recursion
depth. Say FunctionA calls FunctionB, that would be call depth alone,
not recursion. (Call depth or recursion depth all employ a "call stack"
to keep track of scope. Hence my mention of call stack depth. I
understand that using a counter like RecursionLimiter does is a cheap
and efficient compromise between true cyclic loop catcher and fast
cyclic loop preventer).

In short, recursion depth involves call depth (since FunctionA is
calling FunctionA itself). But call depth, in general, does not
necessarily equate to recursion depth. That is, recursion depth is a
special form of call depth.

RecursionLimiter currently limits call depth, not just recursion depth.

My proposal for animation requires that TriggerAction be runnable in a
separate thread. The meat of the proposal was written here[1], though
there are some minor errors in that proposal.

If each TriggerAction can run in a separate thread, and can also loop at
a timed interval (proposal termed this as "Repetition Interval"), that
would mean this: Each TriggerAction effectively represents a single
animation loop.

Now, why would that implicate RecursionLimiter? If there are more than
50 animation loops (via 50 TriggerAction(s)), RecursionLimiter will
balk. Even without my proposal for "TriggerAction as Animation Thread",
RecursionLimiter still should be corrected to do what its name implies.

"Brent Easton" wrote:
> The speed of the animation would be non-deterministic.

With timed intervals, animation speed will be deterministic.

"Brent Easton" wrote:
> What sort of animations are you thinking of?

Anything from animating a movement (thus possibly removing the need for
movement trail), to animating a counter endlessly to show status (eg,
rotating clockwise means something, and counter-clockwise means
something else).

"Brent Easton" wrote:
> Any sort of operations running in a separate thread that change the
> game state are going to cause serious problems.

Hence, this part of my proposal:

Add a new checkbox to TriggerAction: "Non-blocking".
When user ticks this checkbox:

  * Advise end-users:
        * Race conditions might occur
        * Proper thread programming is required
        * Please limit execution time of thread (for performance

[1] http://www.vassalengine.org/forum/viewtopic.php?f=4&t=4558

Read this topic online here:

More information about the messages mailing list