Michael, this is one of yours, but I was checking a duplicate and had a quick look and realised what the problem was. It’s part of some new code that went in, but it did not take into account that it is possible to have single counters on a board that do not belong to a Stack and do not have a parent.
–
Michael Kiefte, Ph.D.
Associate Professor
School of Human Communication Disorders
Dalhousie University
Halifax, Nova Scotia, Canada
tel: +1 902 494 5150
fax: +1 902 494 5151
RFE [2193791] Pieces in palette to show correct dynamic property values
It turned out to be a fairly easy fix and should not affect performance. PieceSlot now returns a fully expanded piece when asked one instead of an unexpanded one. This fixes teh display DP values in the palette where the DP is defined in a prototype. It also fixes ‘Bad Data in Module’ errors when you first open the piece palette.
Tim, I solved this while playing with Combat Commander and also looked at the ‘Bad Data’ errors for ‘$Allied Orders$’ you get when you first start a new game. This turned out to be problem at your end. The Setup Stacks Allies OR and Axis OR have pieces that defined a numeric Dynamic Property with an initial value of $Allied Orders$ or $Axis Orders$. These need to be numbers.
Joel, Michael, Rodney, I did a test implementation of some of the PropertyProvider caching we discussed offline, but it had little measurable effect on my testbed (Combat Commander). I implemented it for SELECTED, SNAPSHOT and PIECE_ID. Since it had so little effect, I hesitate to add it to beta 5 as there may be unintended consequences. I think someone needs to review this whole area in more detail for 3.2. There are a whole bunch of gotcha’s just waiting to jump out.
The fixes already in solve the 2 major issues that was affecting the Stategos module.
Bug [2175571] NoSuchElementException in ColorConfigurer.stringToColor()
Colorconfigurer does not cope with corrupted input at all. There was FIXME there as to whether it should actually throw an error. I don’t think ColorConfigurer.stringToColor() should, but should return a valid color with the offending components set to 0 (ie black if it is total junk).
This bug looks to be due to a corrupted preference. If there is still a problem in the saving of the preference (which I can’t see), then users will report some Color preference not ‘sticking’.
I know, but we can’t do anything about it. Beta3 reports directly to SF,
and has no update notifier. That won’t happen with beta4, since we can
shut off bug reporting and it will pester people who are using it once
beta5 is released.
Tim, I solved this while playing with Combat Commander and also looked at
the ‘Bad Data’ errors for ‘$Allied Orders$’ you get when you first start a
new game. This turned out to be problem at your end. The Setup Stacks Allies
OR and Axis OR have pieces that defined a numeric Dynamic Property with an
initial value of $Allied Orders$ or $Axis Orders$. These need to be numbers.
Ahh! Found it! Don’t know how it changed though
Still getting the Bad Data error but it is not telling me where anymore.
I have narrowed it to two areas - The forementioned Palette Piece / DP
discussion upon opening palette in game or the use of CP’s as it always
seems to pop up when I edit protos that are reliant on DP’s / CP’s in editor
Bug [2176550] NumberFormatException in PositionOption.setValue()
It is a rare bug that can result from a naming conflict. I have changed the bug reporting to detect the naming conflict and report a BadDataReport with a suitable message, instead of a bug report.
I’ll get that now. I got tied up in following the election yesterday, in
addition to having had an awful cold almost the whole time since I returned
Australia. I feel like I’m flipped to my reduced side right now.