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

viewofheaven viewport2heaven at yahoo.com
Thu Nov 3 01:25:22 MST 2011

"Brent Easton" wrote:
> > RecursionLimiter currently limits call depth, not just recursion
> > depth.
> If it helps, we can rename RecursionLimiter to CallDepthLimiter :)

Hmm. But why would we want a call depth limiter? The point of having
call depth at all is to allow us to structure our programs. That is,
organize our code into functions (and functions into classes, into
packages, and so on).

A very layered code will mean several well-insulated abstractions,
comprising of several distinct functions calling one another. The point
of "abstractions" in software is to allow us to "plug in any technology
below any abstraction". Anyway, a quick search for database abstraction
should explain my point here much better and more quickly.

I know that programming a Vassal game module isn't programming Java. But
the ability to build "layers" for better code organization is still
needed nonetheless. Some game modules are so big, they're even harder
for me to wrap my head around than Vassal Engine is!

"Brent Easton" wrote:
> > My proposal for animation requires that TriggerAction be runnable in
> > a separate thread. 
> There is no way this will ever happen. It will cause a nightmare of
> problems since Trigger Actions can trigger any actions at all. 
> If you really feel the need for Animation, then write a new Trait that
> does Animation specifically.  It would know about the image sequence
> and the timings and can start a thread to display them using a proper
> Animator timer. That would be a much better solution.

Very true. The only reason I didn't propose a new trait was because I
didn't want to "add more mess" to the Trait engine. Users are already
familiar with TriggerAction. And TriggerAction's design and motivation
exactly fits this "non-blocking" implementation.

But I totally agree with you about making an Animation trait! As long as
this new trait doesn't have too much overlap with TriggerAction, then we
won't be adding too much new code (and new bugs). And now that you
mention it, there really aren't much duplication of code between
Animation and TriggerAction!

The Animation trait can also have very tight code that controls how
animation threads run exactly. Also, it will be better suited to
specialize in handling images, organizing image sequences.

But, back to the "nightmare of problems", wouldn't all those problems
not exist if users simply ___not___ tick the "Non-Blocking" option for
TriggerAction? Only advanced users need to tick that option.

A non-blocking TriggerAction will still be good for programming a
real-time kinda game, such as some "Global Infection Count" rising every

Read this topic online here:

More information about the messages mailing list