#71 Clean up unit movement and other properties at EndTurn instead of non-combat Move

[David Landry]

Right now, you must call the MoveDelegate twice in each turn because certain things only happen during the "non-combat" version which runs the second time (clearing unit movement, etc.). To add support for 1914, it must be possible to have a single move phase in each turn.

(see patch #70 for a dependent change)

Move the unit and transport clean-up from the MoveDelegate to the EndTurnDelegate. These functions really make more sense here anyway, since unit movement restrictions, transport load restrictions, etc. are for the duration of the turn.

I don't believe there's anything in the PlaceDelegate that would depend on these having been cleared, but I may be wrong.

Rather than calling DelegateFinder to find the MoveDelegate and then use its TransportTracker instance, I thought it made more sense to make endOfRoundClearStateChange static, since it doesn't actually use any class members.

[David Landry]

After discussion with Veqryn, moving this to EndTurn is too risky. So here's a new patch. I've moved the code to a new Util. By default, this is called at non-combat move (as it is now) but I've added a new game property to call it at End of Turn.

[David Landry]

Here's a new patch. Instead of a game property to control whether unit movement is reset, it's a stepProperty that is checked for at end of turn. This can be used by adding this to your xml:

                    <step name="austrianEndTurn" delegate="endTurn" player="Austrians">
                        <stepProperty name="resetMovement" value="true"/>
                    </step>

[Chris Duncan]

your patch was pretty good, but i thought for this sort of thing we could be a little more ambitious and systematic

i went and looked up how we tell combat move from noncombat move, and then searched for all references inside and out, and then all their references, etc, until I had a list of everywhere and everything affected by this difference

i then created step properties for each of those differences

i suspect at some point in the future, we should move all the step property stuff into a single static class, but i didn't have time for it this go around.

please have a look at this attached patch and review for possible bugs. i will be committing it, but am open to changes on it.