Adventure "Motherly Love" is EXTREMELY bugged - what you see is NOT what you get
As this title says, the adventure "Motherly Love" is not functioning properly. As in seriously game-breakingly WTF-is-going-on bugged.
For players, the TL;DR of it is: Either stay away from "Motherly Love" or do so at your own risk. You may lose more units than you want and you may lose them to a bug rather than to actual camps.
For the developers, the TL;DR of it is there are serious issues with conflicts between client and server, and please actually read this post.
Now, here's what happened.
I came in and cleared the first camp on the left (100 gunmen, 100 mates) with no problems: battle reports matched what I sent and everything was hunky dory.
Next I sent out a general to clear out the first (leftmost) wolf camp, which also worked fine.
Next, I wanted to clear another wolf camp, since it looked like it would intercept if I tried to attack the leader. So I made a general with 50 recruits and 150 soldiers and sent them out.
Now here is where things got buggy. What I saw happen on my screen and what really happened on the game's backend (database) diverge.
What I SAW
I saw my unit walk over to the 200 wolves and clear them. This had me kind of confused since I was expecting the caltrops camp to intercept. My general walked home, and I de-assigned the units (150S and like 30-something recruits) and allocated 200 cavalry to that general. I tried to send it to the leader, but it started walking towards the caltrops camp so I retreated it (twice, since it didn't seem to take the first time). At this point, the second bandit camp mysteriously disappeared on my screen, and I reloaded the game because something was clearly wrong.
What the BACKEND did
According to my battle reports, my 150S_50R general went on the warpath: he was intercepted twice before going to the target camp. First, he was intercepted by the 200 wolf camp... which is what he was targeted on, making little sense already. But that was easy, so he only lost 14R. The 150S_36R general was then intercepted by the second bandit camp of 100 mates 100 caltrops. There I lost most of the units, leaving only 56S. Those 56S then proceded on to "attack" the 100 caltrops camp which they cleared. That general then apparently returned home with naught but 47 soldiers left.
After reloading the game, the general that on my vision I had assigned 200 cavalry to now had just 47 soldiers. Those 200 cavalry have seemingly disappeared into the aether. But that's not all: the 150S and 30-something recruits that I had unassigned on my screen before the reload were added back, meaning I had 200 soldiers not assigned after the reload in addition to the 47 soldiers still assigned.
Net Result: I *lost* 200 cavalry but had an actual net GAIN of 47 soldiers, plus several camps were cleared.
What needs to be learned from this: detailed analysis
Clearly the game is mixing things up between client-side and the backend (server-side). The most serious issue is that units are disappearing into nowhere and coming back from the grave. From what I can tell, the reason for this seems to be that the server is trusting the client on what you have in some circumstances and not in others. In this case, what was going on at the server was not what was going on in the client, resulting in a significant disparity of units and some very odd errors in the end.
On the one hand, the client had 150 soliders and some recruits come back safe, and I unassigned them. The server accepted that, despite the fact it should have known that, according to it, most of them had been lost during intercepts battling camps. On the other hand, it accepted 200 cavalry as allocated to a camp, despite also knowing that according to it that camp had 47 soliders and nothing else on it. Those cavalry thus disappeared into nowhere: the server deducted it from one place but didn't ever add them back to the camp.
What this means is that the client and server are capable of getting out of sync on adventures in a very bad way. The database/server should always be the last word, and anytime the client gets out of sync and asks the server for something that is not correct there should be an error and the adventure should automatically be re-sync'd to what the server is saying happened.
For that matter, any time any significant event occurs and the server is updated (a camp is attacked and cleared for example) the client should be resync'd with the server.
As it is now, one can never be quite sure if a general will be intercepted on a give route and if so by what camp. You have to watch the general and if he heads to a different camp you have to retreat him before he attacks -- and maybe it'll work, if you're in sync with the server. If not,
he'll attack anyway.
Reworking attacking: a proposal
Instead of this method of watching and hoping, what I would like to see is attacking split into two phases. First phase would be to "plan" the attack: you pick the camp you want to attack, and the game plots the path the general would actually take, including any and all intercepts that would occur along the way. Once planned, you would then be able to actually send the attack or cancel and plan another. When the attack is executed the general would march to the camp and then you would have a pre-defined and server-synced 10 second window at the camp in which you can retreat; you would also be able to retreat at any time while the general is actually moving, like you can now.
This would have the benefit of making it abundantly clear where your general is going to go each time and since it checks with the server, there's no potential for getting out of sync. The 10 second time to retreat gives players enough time to decide and since its synced with the server makes sure that you actually can retreat.
The downside would be some loss of effectiveness of hidden camps ("forrest" camps of wolves, etc.). Since most people that do adventures (especially any harder adventures) look up where the camps are and know where these "forrest: camps are, I think that loss is extremely minor. Furthermore, there's ways that it could be mitigated: you could, for example, make several more forrest camps and randomize the # of wolves in them and then hide that number. In this example, the camp could hold anything from 1 wolf (effectively a decoy camp) to the normal amount and the player would not be able to tell how many wolves were there.
Now this is just the ideas I had that could improve the combat system and help prevent issues like that. There are many ways of doing it, but the ultimate point is that something needs to be done to ensure things do not get out of sync. The player should never see one thing happening while the server is doing something completely different.