Impromptu Games

It was definitely clear that the French had just promoted some new corps commanders as we entirely failed to account for their size. Outside of that I think it went pretty well. It's hard to really judge balance on the scenario from only one battle, and that battle didn't even use all of the included forces. With players on both sides there's option to have the objectives be a bit more complex too, as both sides can understand more convoluted rules. Though perhaps we should keep it simple in the early days.

I can appreciate the difficulty inherent when too many divisions get sent to the same spot more or less at the same time to fight a battle ... I think I can recall doing that somehow, somewhere. If memory served, it caused much angst in several division commanders. Much blame was passed around. One or two people were shot I think.

On the west side of the map my corps waited for the hammer blow that never came as you all shifted east. Interesting listening to Ehey’s stream that in your initial conversations you indeed were planning to come in my direction. But changed your mind.

At the start of the game, I had to ride almost 2 miles from where my commander started (south of map) to first place a division In a spot where It could flank you as you came south. As I rode north a couple miles from there I could first start to hear the sounds of battle. Then I had to actually locate the 2 small divisions that were positioned to harass you. So it wasn’t until 30 mins into the game where I actually had an idea what happened. I saw a ton of French cavalry and I managed to pull one division back to a nice hill still north of the river while shifting the other small division to defend the main crossing south of it. Both more or less in supporting distance. But no followup attack came. After a bit, I scouted east thru the woods and with an infantry brigade behind me just to see if I could find some French. So it wasn’t until well past halfway thru the game it was clear that no French were coming south on the west side of the map.

And where I didn’t have a problem sending out fake courier messages to get intercepted, to ensure real messages got thru I would have to ride 2 miles south and a mile ortwo west to get a safer direct line to Vince. That was hard to do so we really didn’t exchange much in comms outside of the most basic of status.

So I really had no idea until very late where the French were, and not until the replay did I grasp the extent of the French shift.

Miko & Ehey: Great observations on structure and design. Will heed next time.

I can play today at the usual time, 14:00 EST, 19:00 BST.

Meanwhile, I didn't get scout reports as a corps commander. It is a bit complicated to handle that many troops with no information except what you have in sight. Is there a way to go around this ?

I had player/corps commander receiving the report in SP only.  I've added it to MP if the division commander is not a human but the corps commander is.

The same regarding division commanders, they never sent me any messages regarding the forces they engaged (with number of batallions and guns).

Good idea, I'll add this later.

Hi, I'm new to the forum but not to KS style gaming... So I was wondering if it could be possible to participate in today's battle.

Welcome to the Forum. Yes, by all means join us. Try to come onto the Discord channel a few minutes early. There are a few update files you will need to download. Once that is done, we'll run a quick test to make sure you have everything installed properly.

Thank you, I'll be there

I'm halfway through watching yesterday's stream.
Quite troubled game due to bad frames and crashes so far, I see...
That's too bad.
The game setup really looked shiny.
Congrats to Vince and all participant players anyway. New and old.

Next time grab the exe crash offsets and MP/packet logs, please, if possible, Kevin.
I believe we shall at least try looking where they come from once and for all and stop speculating.
They might really break momentum and lenghten the game duration too.
Newcomers being picked as natural targets or just to see themselves feeling guilty for these unfortunate events, is equally an hateful situation.

Newcomers being picked as natural targets or just to see themselves feeling guilty for these unfortunate events, is equally an hateful situation.

We try to blame Grog when we can.


It was a good game. For once we fought on a frontage that was appropriate for our numbers. They held us until the very end, I wasn't sure we were going to make it. Next time Pat is on we can have him be CinC and tell him to pick different options.

Next time grab the exe crash offsets and MP/packet logs, please, if possible, Kevin.
I believe we shall at least try looking where they come from once and for all and stop speculating.

We are pretty sure what the problem was, the first bad frame issue was fixed when we rolled back the ai modules .dll so that was probably caused by the code Kevin added that pushes scouting reports up from division commander to corps commander level. The subsequent bad frames were due to player-sent messengers being in transit after a save file. We've known about that one for a long time. I think it was particularly bad in this game because our couriers sometimes had a long way to ride.

Thanks for sharing your understanding of the problem, Martin.
In your experience, once a BADFRAME related to courier messages occurs, do any other player get notified some kind of waiting log warning right before that?

As you guys certainly know much better than me, in MP games, eComMultiCourMsg (along the msg identifier and player index only) goes down to other peers through the frame data's list of queued commands. This is packet type eActUpdate.
But the core data of the message is sent through an entirely different channel (eActCourMsg).
They also have different Raknet's priorities and channels configuration at the time of sending.

The thing is when the received/buffered frame data (along the attached commands) of all other peers is unrolled by the game loop, if a eComMultiCourMsg command is found but the corresponding courier message data has not arrived yet (through eActCourMsg), the given player enters in a sort of waiting state (*).

I'm under the impression this situation ends up screwing somehow the ring/circular buffer where all the future(max 20 tics ahead)/waiting for playback incoming frame data from other players is stacked. Perhaps when the waiting state terminates and we can finally pull the data out the feezer, at that point timestamps don't match local player's tics and a BADFRAME happens.

I might be off the path, but this is the first thing I guessed after looking at the game mp code.

* His commands are not executed locally, other people most likely can't advance the next frame because the stucked player is not dispatching its eActUpdate, but maybe they send him their next frame's eActUpdate in the meantime and these goes written in the wrong circular buffer place? Just an idea.

Every player gets the bad frame error at the same time as far as we can tell, or very nearly so, within a few milliseconds it would seem. Some players don't see it because they may not have the [debug] dbglvl=2 flag switched on in sowwl.ini

One thing we would like to be able to keep is a log of all player messages sent in the game - these are just historically interesting and can be amusing too. Is there a way to write these to a file?

Yes...
I can drop Kevin's the code to write the local player's messages to a txt file once his AI module gets unloaded, if he wants to try that.
It's just a read-only operation on the items of a CWarMP's std::map container. So certainly it's safe on Steam as well.

Forgot to say that the local (sent&received) messages can be easily extracted from savegames, in any case.
Just search for WARSTR.

Mr. Digby wrote:
Every player gets the bad frame error at the same time as far as we can tell, or very nearly so, within a few milliseconds it would seem. Some players don't see it because they may not have the [debug] dbglvl=2 flag switched on in sowwl.ini

Do you remember if these players normally get consistent log's content about BADFRAME?
I mean especially the player's name (3rd column), troubled data's timestamp and the local player's current comm ticks (latest 2 fields).

DebugMPLog("%d,BADFRAME,%s,%d,%d,%u,%u\n", theApp.m_timeInTicks, playerData[i].name_00.c_str(), var_10, fd.randSample_0004, fd.timestamp_1714, mp->networkTicks_0020 + 1);

That would suggest it's the "incriminated" player sending bad timestamps, somehow...
Probably desyncing its current ticks count at some points, compared to other peers.
But if one player receives frame data's timestamped from the past, it'd likely desync later I'd say, but in the short term it'd be only discarded and wouldn't fire any BADFRAME.
Too much ahead he can't run either, as failing HAVEEVERYONE should prevent that.
Now I'm even more seriously believing timestamps just screw out of logics by some unpredicted overwrite/overflow event.

Please share the logs whenever possible. The more the better.

We have definitely tracked it down to couriers in transit. We are 100% on that. Desynching players just cause the game to pause or run slowly.

Anyone around today for a quick game? I am at a loose end!

Pom and I are planning to play Austrian scenario 58 for a practice game, and you'd be welcome to join us, Diggers. We're not looking for a big game. As you know, we normally play GB, so are trying to get used to Waterloo in a low-key environment.

We need to start promptly at 19.30 UK time however, as poor old Pom needs to be up early for work tomorrow .

Martin J

That sounds good.

There is an update for the Kelheim map which I have, plus updated modules and some other updates. Do you and Pom have these, Martin? The scenario looks to be okay and uses the old style skirmishers.

We do have v1.32 of the KS Nappy Mod, but I'm pretty sure we won't have the stuff you mention. Can you email it all to both of us please in advance of the game?

Martin J

Its all in the Discord downloads channel.

Right. I see it/them. Just checking......... we need to download the complete Nappy and map mods? Yes?

No, just the files. Get on Discord with me and I'll talk you thru it.

Ok. I'll phone Pom, and see if he can come on now too.

m