Ok, noted. We're going to have to find some way to get remote crash reporting working under this circumstance, because we can't seem to replicate the problem ourselves (I've spent some hours trying), and we have no idea why this is happening.

It's really not consistent, happens a lot for a few mins then stops altogether. It's odd.

There is another development, that is new. Lag spikes when tridents and goliaths jump in. I have no damn clue why.

There is another development, that is new. Lag spikes when tridents and goliaths jump in.

If you haven't loaded the Trident or Goliath textures in the most recent run-time of your game client (ie, seen a Trident or Goliath, or in that Livery), then that always happens.

It isn't related to this crash, which is something we've managed to reproduce a few times and we have some idea of what's going on.. but it's difficult to track down. It's probably a type of "race condition", where two pieces of code are "racing" to access the same data at the same time, but the crash only happens when the timing is perfectly (badly) aligned. Architectural challenges that sometimes arise when you're doing a lot of threading for multi-core scalability.

So the crash might be negated with turning off multi-threaded renderig? Ill turn it off during recordings then.

Yeah, no. One of the first things I disabled when this stated to happen was the multithreaded rendering. DX9 seems like the only real fix for now for those of us affected.

Actually, it's probably related to shadows. So if you turn off dynamic lighting, that will probably help. Or if you explicitly disable shadows.

On the other hand, we actually need more crash reports. So if everyone disables stuff and we don't get reports, the bug is more likely to persist.

This should now be fixed in the latest update.

It seems to be fixed for me, at least at present. Thanks