Heres one from the version 16. I'm attacking the city of Moscow with a stack, if I kill the first defender with any of my attackers I don't then go to attack the next defender, it sets everyone waiting till the next turn and picks someone else.
Thanks for the save game, and thanks Thoric for spotting the key issue (which I would never have found as I never use that option). With this combination I am easily able to reproduce the issue, and BOY is it weird!!
Based on the code my first reaction to hearing this happened only with quick offensive combat was 'No way!', but it certainly does happen. As far as I can tell this is a bug in the main game engine, and the DLL was doing everything correctly. Basically there are two code paths involved:
The first is the response to your initial attack order. If quick moves are on, this evaluates the combat and completes it immediately, telling the game to deselect just the attacking unit. If quick moves are not on, it sets up a multiple sub-battle sequence and extends the number of combat rounds needed to complete the attack (it has resolved the result, but the sub-rounds it sets up will be what plays out the animations and so on). It then tells the game engine how many extra combat rounds are needed to 'play it out' and returns without completing.
The second is a timer update callback that plays out a sub-round (as set up by the first call). This does nothing at all except count down the sub-round count. On the call that it reaches 0, it completes the combat using EXACTLY the same call sequence the first path does in the quick-combat case. There is NO differecne at all in the actions taken, just in the timing.
So it seems like the main game engine misintreprets a combat completion on the first call as the stack being done with (even though the DLL code only tells it to deselect a single unit). This seems like a bug in the main game engine to me.
What I have done is workaround the issue by never completing combat on the first call, and instead setting up a 1-sub-round (with no animations or focus changes) completion. This causes the completion to occur on the first timer callback, so the net effect is quick-as-possible-but-not-theoretically-ulimately-quick combat and the stack focus behaves like it does without quick combat. The delay of 1 sub-round is not, in practise, noticeable, so this technique is at least perceptually a fix.
I'll be uploading the 'fixed' DLL to the patches thread later today, or possibly tomorrow (I am still testing some other changes I have in my current DLL before I release it, but I'm done apart from an hour or so play-testing as my final test round, so hopefully today)
