Technical questions

[Flint1b]

Hello Vassal Engine developers,

On my machine the ModuleManager starts with -Xmx2G by default, then starts a new JVM for the Player with -Xmx512M. This is surely a big overhead, many if not most classes get loaded by both JVMs, the 2G heap of the first JVM should be way too much for just the ModuleManager and should have enough heap space left to load the Player with the map and its contents. The internal runtime optimizations of the JVMs also don't work that well if each JVM has to do its own optimization. And debugging the application is also more difficult, the breakpoints in the Player don't work when the ModuleManager starts the Player in a separate JVM.

Other Java desktop applications all run inside a single JVM, be it Eclipse, Netbeans or IntelliJ, and these applications are more complex and resource-intensive compared to Vassal.

I have dirty-hacked a quick POC where the Player is started in the same JVM, and it seems to work perfectly fine, I can see the map and move all the counters as usual, can load and save savegames, so this idea with running several JVMs seems to not be a technical problem.

So what is the advantage of having the Player or the Editor in their own JVMs?

My other questions are concerning Vassal 4, I have seen some vague plans for a Vassal 4 here on the forum and in the wiki, one that will be rewritten from scratch in C++, some of these plans are already several years old, and there is still not a single line of code written. Forgive me for being a pragmatist, but are these plans still actual? What is the estimated time, when will development start, how many developers will work on it, when can a first release be expected, which GUI framework or engine will Vassal 4 use, what will happen to Vassal 3's Java code in the meanwhile, what will happen with all the modules that already exist and the modules that will be developed for Vassal 3 in the upcoming months/years, and what will happen with Vassal 3 once Vassal 4 is out?

[Brent Easton]

My other questions are concerning Vassal 4, I have seen some vague plans for a Vassal 4 here on the forum and in the wiki, one that will be rewritten from scratch in C++, some of these plans are already several years old, and there is still not a single line of code written.

Actually, quite a lot of code has been written in various prototypes and test harnesses.

Forgive me for being a pragmatist, but are these plans still actual?

Yes, they are definitely still actual plans The need for Vassal 4 (or Vassal NG) was first discussed 9 years ago. Life intervened and the primary developer has since moved continents, rebuilt a house and started a family. Myself, I have had other things on my plate, but have continued with analysis and design work.

What is the estimated time, when will development start, how many developers will work on it, when can a first release be expected

We are hoping to get things rolling when Vassal 3.3 is bedded down. I couldn't tell you how many developers will work on it. Plenty of people have put up their hand but we will see when the time comes. I would not hazard a guess at a release schedule.

which GUI framework or engine will Vassal 4 use,

That is a really good question and any input you have would be appreciated. Opensource QT is probably the front-runner due to it's range of platform support.

what will happen to Vassal 3's Java code in the meanwhile,

Vassal 3 is an open-source project and anyone with sufficient skills is welcome to take over support, or even fork it and go in a different direction. It is very difficult to make any significant changes to Vassal 3 without breaking compatibility with existing modules. However, I am considering a round of changes 'consistency' changes to try and smooth out some of the inconsistencies that exist.

what will happen with all the modules that already exist and the modules that will be developed for Vassal 3 in the upcoming months/years, and what will happen with Vassal 3 once Vassal 4 is out?

Nothing. I expect Vassal 3 will continue to exist for years. Vassal 4/NG will be a separate but related project. Module Developers and players will be free to use and develop Vassal 3 modules or to migrate their modules to Vassal 4, which will require an as yet unknown amount of work.

[Brent Easton]

And debugging the application is also more difficult, the breakpoints in the Player don't work when the ModuleManager starts the Player in a separate JVM.

Start the Player or Editor directly using the --standalone option:

Main Class: VASSAL.launch.Editor
Params: --edit "C:\Users\beast\Documents\Vassal\A Magnificent Defeat\a_magnificent_defeat.vmod" --standalone

Main Class: VASSAL.launch.Player
Params: "C:\Users\beast\Documents\Vassal\A Magnificent Defeat\a_magnificent_defeat.vmod" --standalone

[Flint1b]

Thank you for the very detailed answer.

Myself being a Java developer and specializing in backend code, I would not dare recommend a GUI framework for a C++ desktop application.

That being said, I hear QT is decent. Maybe Unity engine could be considered, it seems to be quite popular for desktop games in the recent years.

In Java the trend goes towards a XML/HTML/*ML/CSS approach even for desktop applications, for Vassal Java my recommendation would be to first refactor the code into a clean MVC-style pattern, then migrate from Swing to JavaFX.

My last question (for now) is, and forgive me if it's a stupid question, if it was possible to remove this "JVM-fork" and have the whole application run in a single JVM, without breaking the public API and existing modules, would such a change be viable, or are there reasons for running in separate JVMs that I am simply not aware about?

[Brent Easton]

first refactor the code into a clean MVC-style pattern,

The extreme difficulty, if not impossibility, of achieving this is one of the driving factors towards a full re-write.

Joel will need to weigh in on the JVM business. I think this was from before he built the Map tiling functionality, when each map at each zoom was held completely in memory.

[uckelman]

Thus spake Flint1b:
>
> In Java the trend goes towards a XML/HTML/*ML/CSS approach even for
> desktop applications, for Vassal Java my recommendation would be to
> first refactor the code into a clean MVC-style pattern, then migrate
> from Swing to JavaFX.

I have zero interest in sinking time into further development with Java
after we release 3.3. Years of wrestling with the current codebase has
convinced me that it is not efficiently refactorable. Major refactoring
requires a functioning battery of tests. We don't have that, and we can't
create it because there are so many things where how they're supposed to
behave is unclear or where people have become reliant on a bug that we
now can't eliminate. Refactoring also supposes that you're going to keep
things working as you go, and the effort required for creating all the
intermediate bridge code to keep things working in this particular case
is in my esimation larger than the effort of starting over.

> My last question (for now) is, and forgive me if it's a stupid question,
> if it was possible to remove this "JVM-fork" and have the whole
> application run in a single JVM, without breaking the public API and
> existing modules, would such a change be viable, or are there reasons
> for running in separate JVMs that I am simply not aware about?

You could combine the Player with the Module Manager, but then you'd
have back the problems that making them separate was designed to address.

Historically, we've had to jump through quite some hoops because Java,
alone among all languages in common use in the last 25 years, expects
programs to declare the maximum amount of memory they will use at the
point when they start. This is aggravating for several reasons. Modules
are of all different sizes, as are the images therein. You can't reliably
deduce how much memory an image will require to load from the file size of
the image. Furthermore, even if _we_ could estimate how much memory a
module needs, good luck conveying that information to the average user,
and it's ridiculous that Java dumps this issue into the user's lap.
Imagine if your word processor or web browser required you to guess how
much memory it might need at the time when you start it up. This state of
affairs is so absurd that it's embarassing to have to tell people that
VASSAL is like this... But, it was never our decision---Java forces this
on us, and I will be so glad to be shut of it.

Brent might remember this better than I do, but the Module Manager was
introduced in 3.1.0, and as a separate process precisely because (a) we
didn't want to steal memory from the Player for it, (b) because we
wanted it to be possible to have more than one Player open at a time,
and (c) because it was way simpler to make the Module Manager be a
process of its own than to integrate it. In 2009, people had a _lot_
less RAM than they do now, so getting your max heap adjusted right was
harder then; having the Module manager take up some of the heap you've
allocated for your module could easily have prevented you from loading
all the images.

In 3.2.0, we tried to ease heap issues by tiling large images and
keeping tiles in a memory-sensitive tile cache. This reduced the heap
sizing complaints we got considerably---for a while---but that, and
increasing RAM in machines over time also encouraged module designers to
make larger maps...

So, the short answer is: Were you to combine the Module Manager and the
Player, what you would get for your trouble is endless user complaints
about running out of memory.

--
J.

[Flint1b]

Thank you for the detailed answer, I now understand the motives, though I don't agree with the implementation.

It is not the job of the user to tell the JVM how much heap it has, but rather it's the job of the developer to give the user a start script that sets a good -Xmx value. It is also the job of the developer to use the given memory wisely, like you did with the tiling of the images and only loading the portions into memory that are needed right now.

Splitting the application over several JVMs uses up more memory, not less, as many if not most classes of the application get loaded several times into memory, all the static blocks and statically initialized variables get loaded once per JVM, not to mention the overhead of the JVM itself.

And I did not know that there can be multiple instances of the Player running at the same time, but again, doing this in separate JVMs is less memory efficient, not more, loading all the classes and instantiating mostly the same objects multiple times in several JVMs can not use less memory than loading them once in a single JVM.

The Player currently starts with -Xmx512m, the Module Manager starts with a default of 2G but surely doesn't need more than 128-256M, so theoretically, say if a user wanted to start 4 Players for some reason, he would need 4*512 plus 256M for the ModuleManager, 2.25 GB RAM would be needed in the worst case, assuming the whole 512MB are used up by each Player instance and the ModuleManager goes crazy and needs 256 for some reason. This is easily doable in a single JVM, and will help the JVM to optimize runtime and memory much better as it could reuse most of the classes and objects. All the internal Strings, the GUI Actions, could all be reused, also it's highly likely that if a user starts several Players, he won't start several modules but one and the same module in several instances, and with the correct implementation most module images could be reused.

It appears to me that the problem is not the way how Java handles memory but rather C++ developers misunderstanding and being afraid of Java and finding things impossible. The codebase has completely deteriorated and looks like Java from 20 years ago, the idioms used in the code are C/C++ idioms, methods that are several hundred lines long, variables named this_is_my_name, class fields declared public and used like C-structs, and an overall design that is not object oriented at all but rather static C-style code thrown into Java classes. I understand why you want to run away to a rewrite in C++, but I doubt this will solve the problems and become a viable replacement, at least in the next 10-15 years, assuming that as much work will be done for that as was done for Vassal 3 over the last 10-15 years. And even if after this time the given problems will become solved, they will be replaced by new problems.

Anyways I am a Java developer and have no interest in C++, it is a terrible language, most C++ developers are terrible and know nothing about clean code, maintainability, refactoring, and object oriented design, my prophecy is that the new Vassal 4's C++ code will deteriorate exactly like Vassal 3's code deteriorated or even worse thanks to the existence of the glorious language features named malloc() and the even more glorious free(). I will try to help with the current Vassal's Java code now and then and would be glad if my pull requests get accepted, I will try to make the changes as small and as easy to understand as possible, I understand a little bit about handling legacy code with no tests underneath, this is the default situation I'm dealing with professionally in big corporates.

[Brent Easton]

it's the job of the developer to give the user a start script that sets a good -Xmx value.

As Joel explained, that is just not possible. With Vassal, the 'correct' value for -Xmx is impossible to predict or determine accurately in advance of loading the module and seeing what happens.

The 2G requirement for the Module Manager seems excessive, I'm not sure why that is, unless the Module Manager is doing the tiling, I'm not sure how that works.

Honestly, with the amount of memory on modern machines, it really isn't worth the effort to optimise this. Any memory used by the Module Manager will go quiescent and be paged out before very long. We are talking about single user machines, not multiprocessors

The codebase has completely deteriorated and looks like Java from 20 years ago

.

The code has always been that way and yes, the core of Vassal was written 20+ years ago as an experiment and most of the important design decisions where made before Joel or I even started working on the project.

assuming that as much work will be done for that as was done for Vassal 3 over the last 10-15 years.

Very little work has been done over the last 10 years and most of that has been remedial. The bulk of the work before that was trying to fit features in that should have been designed in from the start but weren't. Most of development time that has gone into Vassal over the last 15 years has been wasted dealing with crap. I can't tell you how many months of my life I lost trying to retrofit Internationalisation into modules.

most C++ developers are terrible and know nothing about clean code, maintainability, refactoring, and object oriented design

The reality is that most developers in any language are terrible and know nothing about clean code, maintainability, refactoring, and object oriented design, there's nothing special about C++ programmers in that respect.

my prophecy is that the new Vassal 4's C++ code will deteriorate exactly like Vassal 3's code deteriorated or even worse thanks to the existence of the glorious language features named malloc() and the even more glorious free()

Joel is a professional C++ developer and I expect will maintain a strong guiding hand on the project.

Aw c'mon, malloc() and free() are fairy tales use by grannies to scare the grandkids. No one uses them anymore since smart pointers settled in.

[uckelman]

Thus spake Flint1b:
> Thank you for the detailed answer, I now understand the motives, though
> I don't agree with the implementation.
>
> It is not the job of the user to tell the JVM how much heap it has, but
> rather it's the job of the developer to give the user a start script
> that sets a good -Xmx value. It is also the job of the developer to use
> the given memory wisely, like you did with the tiling of the images and
> only loading the portions into memory that are needed right now.
>
> Splitting the application over several JVMs uses up more memory, not
> less, as many if not most classes of the application get loaded several
> times into memory, all the static blocks and statically initialized
> variables get loaded once per JVM, not to mention the overhead of the
> JVM itself.

Indeed. But I did not say that we're trying to conserve memory full
stop. We're trying to conserve memory _within_ the limit set for the
max heap for a particular VM.

> The Player currently starts with -Xmx512m, the Module Manager starts
> with a default of 2G but surely doesn't need more than 128-256M, so
> theoretically, say if a user wanted to start 4 Players for some reason,
> he would need 4*512 plus 256M for the ModuleManager, 2.25 GB RAM would
> be needed in the worst case, assuming the whole 512MB are used up by
> each Player instance and the ModuleManager goes crazy and needs 256 for
> some reason.

The max heap for the Module Manager is basically irrelevant; it's unlikely
ever to expand its heap from the initial value. But that amount would still
be counted within the heap in a combined application.

Also significant is that Java's heap has to be contiguous. You might be
surprised to know that even in 2020, there are many users whose machines
cannot allocate a contiguous 2GB region of RAM. There are also some
modules which need a heap of around 1GB to be opened _once_.

> This is easily doable in a single JVM, and will help the
> JVM to optimize runtime and memory much better as it could reuse most of
> the classes and objects. All the internal Strings, the GUI Actions,
> could all be reused, also it's highly likely that if a user starts
> several Players, he won't start several modules but one and the same
> module in several instances, and with the correct implementation most
> module images could be reused.

The amount of memory used by classes and Strings which would actually be
duplicates between two Players is negligible. Almost all the memory used
by a Player is for mutable objects and image data. If you had two copies
of the same module open, you might share image data, but you're still not
going to share other objects. The ability to have n Players open in one
VM would make it even harder to advise anyone as to what they should set
their max heap.

> It appears to me that the problem is not the way how Java handles memory
> but rather C++ developers misunderstanding and being afraid of Java and
> finding things impossible.

If, after reading my explanations, you still think I've misunderstood the
capabilities of Java, please do me the favor of pointing out where.

> The codebase has completely deteriorated and
> looks like Java from 20 years ago,

You're right on one count here---the codebase looks like Java from 20
years ago because most of it _is_ Java from 20 years ago. You would not
be telling us that the codebase has deterioriated if you had seen the
state of it in 2006.

> the idioms used in the code are C/C++
> idioms, methods that are several hundred lines long, variables named
> this_is_my_name, class fields declared public and used like C-structs,
> and an overall design that is not object oriented at all but rather
> static C-style code thrown into Java classes.

This is largely code we inherited.

> I understand why you want
> to run away to a rewrite in C++, but I doubt this will solve the
> problems and become a viable replacement, at least in the next 10-15
> years, assuming that as much work will be done for that as was done for
> Vassal 3 over the last 10-15 years. And even if after this time the
> given problems will become solved, they will be replaced by new
> problems.

Thanks for the vote of confidence.

I did a significant chunk of the work on VASSAL 3 over the past 16 years.
Far, far too much of that work was remedial---so much effort was lost to
fixing problems due to inapproriate design, buggy code, bugs and
limitations of Java, and lack of tests. Those are all problems we can
avoid.

> Anyways I am a Java developer and have no interest in C++, it is a
> terrible language, most C++ developers are terrible and know nothing
> about clean code, maintainability, refactoring, and object oriented
> design, my prophecy is that the new Vassal 4's C++ code will deteriorate
> exactly like Vassal 3's code deteriorated or even worse thanks to the
> existence of the glorious language features named malloc() and the even
> more glorious free().

Most developers _in any language_ are terrible and know nothing about
clean code, maintainability, refactoring, or object oriented design. It's
nothing to do with the language (except for the case of PHP, which is
special).

I suggest you look into what modern C++ is like. No one who has any clue
uses malloc() or free() in C++ (save perhaps for some very unusual
circumstances where one is interfacing with a C API), and if you're then
going to say you meant new and delete, I can tell you that those get
scant use as well these days. C++11 is dramatically different from C++03
and before, and the bad practices you see with C++03 and before are the
very same bad practices you see across much work from that period.

> I will try to help with the current Vassal's Java
> code now and then and would be glad if my pull requests get accepted, I
> will try to make the changes as small and as easy to understand as
> possible, I understand a little bit about handling legacy code with no
> tests underneath, this is the default situation I'm dealing with
> professionally in big corporates.

I'm happy to review patches so long as I can see what gain there is in
them.

--
J.

[uckelman]

Thus spake Brent Easton:
>
> The 2G requirement for the Module Manager seems excessive, I'm not sure
> why that is, unless the Module Manager is doing the tiling, I'm not sure
> how that works.

I believe it's that some server-class VMs default to 2GB. (There are also
some which default to a fixed percentage of the total RAM...) If we let a
VM do that, we'd be innundated with user complaints. I know from fielding
heap sizing questions that today there are still many users (mainly on
Windows) who don't have 2GB _contiguous_ free RAM.

> Honestly, with the amount of memory on modern machines, it really isn't
> worth the effort to optimise this. Any memory used by the Module Manager
> will go quiescent and be paged out before very long. We are talking
> about single user machines, not multiprocessors

Yes, this, exactly.

> Very little work has been done over the last 10 years and most of that
> has been remedial. The bulk of the work before that was trying to fit
> features in that should have been designed in from the start but
> weren't. Most of development time that has gone into Vassal over the
> last 15 years has been wasted dealing with crap. I can't tell you how
> many months of my life I lost trying to retrofit Internationalisation
> into modules.

Oh god, I'd forgotten about how horrible that was. Thanks for reminding
me!

It's more like little work in the last 6 years. There's a lot in the
change log through the end of 2014. If you said that the last 6 years
have felt like 10, I wouldn't disagree, though.

> The reality is that most developers in any language are terrible and
> know nothing about clean code, maintainability, refactoring, and object
> oriented design, there's nothing special about C++ programmers in that
> respect.

It made me laugh that we wrote nearly the same reply simultaneously.

> > my prophecy is that the new Vassal 4's C++ code will deteriorate
> > exactly like Vassal 3's code deteriorated or even worse thanks to the
> > existence of the glorious language features named malloc() and the
> > even more glorious free()
>
>
> Joel is a professional C++ developer and I expect will maintain a strong
> guiding hand on the project.

There will be tests, and I'd like to try to do code reviews. :)

> Aw c'mon, malloc() and free() are fairy tales use by grannies to scare
> the grandkids. No one uses them anymore since smart pointers settled in.

No one uses them in C++ in regular code, full stop. If you've ever been
using malloc() or free() in C++ (save for a few unusual cases) you were
likely doing something wrong.

--
J.

[Flint1b]

Well I have to agree that the majority of most developers are terrible, not just the C++ ones, I have simply seen too many developers coming from C++ do terrible things, which the language allowed without complaining.

The Java heap, just like its stack, does not need to be contiguous, this is defined in the JVM spec, e.g. here https://docs.oracle.com/javase/specs/jv ... vms-2.html.

The 2gb for the ModuleManager on my machine is simply the default value for -Xmx of my JVM, it's a regular Java 14 VM, I believe all the JVMs are "server" JVMs nowadays, running with an implicit -server parameter, there are no more desktop JVMs.

And I still believe that in a modern JVM it should be possible to run several instances of the Player and still conserve memory compared to the JVM-fork approach, if you are able to run one Player inside 512mb then it should be well possible to run two of them and the ModuleManager in a 1gb heap, which modern day machines should be expected to have. And for those power users that want to run 3-4 Players at the same time (what is the use case for this?), it should be possible to tell them they need 2gb for this.

I will keep proposing small refactorings, going in small but steady steps towards a clean and decoupled code, and at some point I might even propose a change that gets rid of the JVM fork, of course only after proper testing and carefully looking at the memory usage. I hope a Vassal 3.3.1+ is not out of the question just because you want to get started with the C++ stuff.

Oh btw, I am the guy with those huge PRs on github that change several hundred files and thousands of lines at a time, with no tests and without changing any functionality

[uckelman]

Thus spake Flint1b:
> Well I have to agree that the majority of most developers are terrible,
> not just the C++ ones, I have simply seen too many developers coming
> from C++ do terrible things, which the language allowed without
> complaining.
>
> The Java heap, just like its stack, does not need to be contiguous, this
> is defined in the JVM spec, e.g. here
> https://docs.oracle.com/javase/specs/jv ... vms-2.html[1].

That's a change how it once was, if memory serves.

That also doesn't speak to what actual JVMs do. It's been common for
us to get reports of users being unable to start a JVM when they've
set a large initial heap but one for which they clearly have sufficient
free RAM.

> And I still believe that in a modern JVM it should be possible to run
> several instances of the Player and still conserve memory compared to
> the JVM-fork approach, if you are able to run one Player inside 512mb
> then it should be well possible to run two of them and the ModuleManager
> in a 1gb heap, which modern day machines should be expected to have. And
> for those power users that want to run 3-4 Players at the same time
> (what is the use case for this?), it should be possible to tell them
> they need 2gb for this.

This misses the point. We frequently see reports of users who can start
a JVM with a heap of x but not a heap of 2x. It's of no help to them
that the actual value is a bit less than 2x because some of the memory
for class files can be shared if they still can't start a JVM near 2x.

It's not the users who are typing to you from machines with 32GB RAM
like I am that have this problem. It's the user who started playing
wargames in the 1970s who isn't very tech savy and isn't terribly
inclined to buy a newer computer right now who is having this problem.

I have fielded probably thousands of heap sizing questions from users
over the years. We have it down to a trickle now. If we make a change
which causes users a new heap sizing problem, who's going to be
answering user questions about it? Very likely me. If I'm going to be
on the hook for explaining the change, I need to be convinced of what
problem it solves and that solving that problem is worth the ongoing
support effort it will cause. I'm convinced of neither right now.

> I will keep proposing small refactorings, going in small but steady
> steps towards a clean and decoupled code, and at some point I might even
> propose a change that gets rid of the JVM fork, of course only after
> proper testing and carefully looking at the memory usage. I hope a
> Vassal 3.3.1+ is not out of the question just because you want to get
> started with the C++ stuff.

I've just remembered another reason for having individual Module Manager
and the individual Player processes: There are a lot of static variables
in the Player and the expectation that there will be only one Player. (It
was already this way before the Module Manager existed, possibly all the
way back to the start.) Dealing with that will be an almightly snag in any
attempt to have more than one Player in the same process.

I expect there will be a 3.3.1 as bug fixes accumulate. I'm not keen on
adding new features to 3.3. I will happily review bug fixes, however.
In the next few days, I'd like to put together a list of significant bugs
to which I can point people interested in helping. Fixing bugs is the
single biggest contribution anyone could make at this point.

(If anyone wants to pitch in with that, please do. Start a thread where
we can identify high-priority bugs and start marking them in the
tracker.)

--
J.

[uckelman]

Thus spake Flint1b:
>
> Oh btw, I am the guy with those huge PRs on github that change several
> hundred files and thousands of lines at a time, with no tests and
> without changing any functionality :D
>

Yes, I had guessed that. Thanks for those PRs.

--
J.

[Flint1b]

Thanks again for the detailed answer, I understand the underlying problems much better now.

A list of current and significant bugs would be good, I have browsed through the current bug tracker and the bugs were either several years old, or had to do with Swing which I don't know that much about, or were talking about concepts which I don't know due to me being new to both Vassal and wargaming.

The contiguous memory issue, yes the spec does not say anything about actual JVM implementations, it merely says the developer should make no assumption about the heap or stack being contiguous. A quick research showed that there are at least some JVMs that do require a contiguous space, which surprised me as I have never heard of any issues in that area, but I also have the disadvantage of having mostly worked with backend code in server-side (web-)applications. Is it possible that this is a problem of older VMs, and modern ones like from Java 8-9 onwards can be expected to start up if there is enough free RAM for the max heap size? I know from experience on an old machine with 2gb RAM that a JVM keeps working even if the RAM is all used up and the linux kernel starts swapping to the hard disk.

Is there some way I can reproduce this memory issue so I can see for myself?

[Cattlesquat]

Well I'll nominate 12554 as one that would probably help a decent number of users (based on marktb's saying "it is known" in the community that Undo screws up a lot), but HOOOO BOY it's a bear. I put some research posts into the bug entry. I *hypothesize* that if we made every PieceMover-type method that currently generates MovePiece sequences for Stacked units do a RemovePiece-then-MovePiece-then-AddPiece for every single move, that the problem would be fixed... but sheesh.