00:00 timer crash and unstable ingame timekeeping

[Aetius2]

Hi Steve,

I found out that the close combat battle timer isn't very stable in timekeeping.

as an example i've played the Dither map 3 times in a row and timed it with a stopwatch:

1st 15 min battle: 16:01:45
2nd 15 min battle: 15:57:18
3rd 15 min battle: 16:36:92

On the 3rd battle my processor was stressed more by running other applications, the ingame timekeeping is probably dependant on the processor, PC system and how stressed it is.

This got me thinking about the frequently reported "00:00 timer crash" issue when in H2H games the timer runs out and the game crashes.
What if the host's timer runs out before the other player's timer or vice versa?

Can ingame timekeeping be made more stable so synching players ingame timers doesn't fail and the 00:00 timer crash is resolved?

[SteveMcClaire]

The timer is showing simulated time, not real time. Whether this is faster or slower than real time or not depends on your game speed setting in the game options, the CPU on the computer, and what is happening in the game.

In multiplayer the host handles updating the simulation time, so the host and client are never out of sync. The client may be running a little behind since it has to receive updates from the host over the network, but the client does not keep its own separate timer.

[Aetius2]

What could explain the 00:00 timer crash?
It has to be caused with synch between host and client being lost somehow?
Maybe when host timer runs out a delay needs to be set where the host waits for synch with client to confirm the battle can be ended on both sides without a crash.
And if a delay is already implemented it should maybe be increased.

It's rather annoying if a after an intense H2H battle the timer runs out, game crashes and you'll have to start over.
The opponent may already know what battleplan you are going to play.

[SteveMcClaire]

What sort of crash are you refering to with "the 00:00 timer crash?" I doubt it has anything to do with the battle timer as the battle is over once you see '0' for the timer. At that point the host is generating the post-battle results and then sending them to the client. What could be causing it depends largely on where the crash is happening -- is the host crashing or the client?

[Aetius2]

I was talking about the 00:00 timer crash that's been reported in all cc versions, you've probably investigated this before:

-----------------------------------------------------------------------------------------------------------------------------------------------
https://www.matrixgames.com/forums/view ... r#p3511704

The way the old CC engine is designed, there is a LOT of code that executes at the end of every battle. All the post-battle clean-up and tallying, all the 'prep for next battle/turn/day' campaign and operation code, all this information is exchanged between host and client, and then the debrief screen is executed. 'End of battle' crashes can be anywhere in this, and are likely different causes for any given version of the game.
------------------------------------------------------------------------------------------------------------------------------------------------

I recently became aware that ingame timekeeping isn't the same for client and host, that's why i got the idea this might be the reason for the occasional 00:00 timer crash.

If the 2 H2H players agree a truce, the same process as described by you above needs to be executed and it never crashes on a truce!
Maybe there's a difference in post battle processes between "truce" and "timer end"?

[SteveMcClaire]

People have reported '0 timer crashes' in several versions of the engine, and generally they have been fixed. So there are multiple issues involved.

There is a lot going on under the hood in the post-battle resolution and it all happens on the host. So if the crash you're seeing happens on the host, that is a fairly good indicator that it may be somwhere in there. If it happens on the client, then it is something with the information exchanged coming from the host.

Most of the same post-battle steps are taken regardless of how a battle ends. There is very little difference between a truce and a time-over. The final map control may be different -- you might want to have the host and client players confirm they have identical map files in case that is the issue.

[Aetius2]

I've been talking to experienced H2H players and they've told me that crashes also happen when asking for truce just before timer runs out (and mostly happen when there's a lot of combat going on).

So like you sayd, probably something happens during post-battle resolution.

One thing thats 100% sure is crash only can happen at end of H2H games (truce or timer end), never in SP Vs AI.

Maybe an option is to make a special exe that saves detailed logging during battles and at battle endings that can be read to pinpoint the problem?

[SteveMcClaire]

Does the crash happen on the host or the client?

Does anyone get an error message like "An unhandled exception has occurred at adress xxxxx?" If so, the adress could potentially be useful in tracking down where it is happening. If they do not get a message box (i.e. the game just closes) then they can check the Windows 'Event Viewer' to see if it has a log of the crash info.

[Aetius2]

No error messages:
At 00:00 host gets the "Loading..." screen and crashes to desktop.
At 00:00 client game "freezes"before being returned to the multiplayer screen.

2 H2H players playing the Radzymin mod simultaneously captured a stream of a 00:00 timer crash using twitch, one from host perspective and other from client perspective, i'll PM you both links.

Unfortunately no error messages appear, i'll ask if they can look into the windows event viewer for more info.

Thanks to Strike and KG_Loki for capturing the 00:00 timer crash on twitch.

[SteveMcClaire]

Thanks. Unfortunately there doesn't seem to be any clue in the game play they captured, though it does confirm a crash on the host side. Please let me know if the host has any information in the Windows event log.

[Aetius2]

Hi Steve,

Argilas had a 00:00 timer crash while hosting on 5.11.2022 at 20:12.

He has sent me the saved "windows event viewer" logging of the crash, i've sent you PM with the zipped files.
I hope you can extract valuable info from the logging.

Huge thanks to Argilas for providing the files.

[Aetius2]

I'll try to collect more "windows event viewer" loggings of crashes for analysis.
If there's anything more we can do to collect crash data, don't hesitate to ask.

[SteveMcClaire]

Thanks! If you can get saved games from the host player that might provide some insight into the crash as well.

[Aetius2]

I've got 2 saved games from the host player (Kami), first GC (Kami_Road_to_Warsaw) saved before a H2H battle that ended in 00:00 timer crash and the second file is the same GC (Kami_Road_to_Warsaw) opened after the 00:00 timer crash and saved under a different name (Test_Crash_GC), both are zipped and PM'ed to you.
Thanks again for looking into this.

[Aetius2]

Hi Steve,

I've PM'ed you data gathered from another 00:00 timer crashed H2H game RD_Steiner Vs Strike Radzymin mod:
-windows event viewer logging of crash
-Saved games before and after crash

Hope this helps you to pinpoint the source of the crash.

Thanks to RD_Steiner (as host) for collecting the data.

[Tejszd]

Thank you Aetius2 for putting in the effort to get this information to Steve!

It would be great if this bug could be found and fixed....

[Aetius2]

Thank you Aetius2 for putting in the effort to get this information to Steve!

It would be great if this bug could be found and fixed....

Second that, i've asked the H2H community to collect as much 00:00 timer crash data as possible.

Another 00:00 timer crash happened in H2H game Argilas(host) vs strike at 14-1-2023 2:27:36
crash reports have been PM'ed to Steve.

Thanks to Argilas for collecting data

[Aetius2]

I've asked H2H players to pause the game before the timer end is reached (about 10 seconds) and then let the timer run out, until now there where no 00:00 timer end crashes, but we'll never know for certain if a timer crash was avoided by pausing the game.

Thats why i want to run this "pause theory" by you Steve, to see if it makes sense:

You've stated:
------------------------------------------------------------------------------------------------------------------------------------------
In multiplayer the host handles updating the simulation time, so the host and client are never out of sync. The client may be running a little behind since it has to receive updates from the host over the network.
------------------------------------------------------------------------------------------------------------------------------------------

When an intense game is played a lot of data has to be exchanged between host and client, what if a combination of high data volume and a slow to average connection is the cause of the game crashing at 00:00 timer end.
My theory is that when the game is paused before the timer ends the host and the client who are still synched can "catch up" their data transfer and have less data volume to deal with when the game is continued and the timer end is reached.

Does this make sense to you Steve?

[SteveMcClaire]

Pausing with a few seconds to go will not hurt anything, so there's no harm in trying it. Let me know if you do see a crash after the players have done this.

I will investigate the theory when I get a chance. But even if there is a backlog of messages on the client, the client should still receive and respond to the host's messages in the order they arrived, so unless something odd is going on with the client player's networking layer I wouldn't expect this to be the problem.

[SteveMcClaire]

I have added some multi-player safety checksc as part of the latest update (6.00.05) for Last Stand Arnhem. It's possible these could resolve the issue people have been seeing with multi-player crashes but it's a bit of a guess on my part as I haven't been able to reproduce the crash myself. Please let me know if people are continuing to see the crash after updating to 6.00.05. Thanks!