Hi Joel Can you tell if this is the same issue that is causing memory leaks with the module and saved game I sent you about a month ago (Empire). The heap errors do seem to occur after extensive movement and rotation (as a Control, we have another battle type where pieces never rotate, and this has never caused Heap errors).
If so, is there an interim solution, or should I continue to wait for a solution? For now I have been forced to abandon Vassal. Cheers Ben --- In [email protected], "Brent Easton" <[EMAIL PROTECTED]> wrote: > > Hi Joel, > > Footprint = old name for Movement trail. > > From memory, the large bounding box was needed to ensure redraw of the entire movement trail when the screen was being repainted. In reality, there are two bounding boxes for a piece: > > 1. The bounds of the actual piece that can be grabbed to move the piece > 2. The bounds of the display of the piece. Significant for Movement trail, Area of Effect, ? > > Cheers, > Brent. > > > *********** REPLY SEPARATOR *********** > > On 11/11/2007 at 11:45 PM Joel Uckelman wrote: > Thus spake "Brent Easton": > > Hi Joel, > > > > Check the location of the Footprint trait as per an earlier email. From memor > > y, Footprint creates a bounding box to include the entire movement history an > > d should be specified outside of any rotation trait, > > It was the Movement Trail trait instead, but for the reason you give. > Thanks. > > For the Glory III module, an interim solution is to make sure that all > of the Counter prototypes (or prototypes which contain them) appear > before the "Trail USA" or "Trail CSA" prototypes. > > For a long-term solution, I'm going to have a look at how we use and > report bounding boxes. Movement paths arguably should not be reported > as being within pieces' bounding boxes. > > -- > J. > > > ____________________________________________________________ > Brent Easton > Analyst/Programmer > University of Western Sydney > Email: [EMAIL PROTECTED] > > > > [Non-text portions of this message have been removed] >
