Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


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

Unstable (example)
Chris Duncan
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.

2 Attachments


  • David Landry
    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.

    Last edit: David Landry 2013-07-26
  • David Landry
    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"/>
  • Chris Duncan
    Chris Duncan

    • status: open --> closed-fixed
    • assigned_to: Chris Duncan
  • Chris Duncan
    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.