When skipping forward in a replay by clicking the timeline slider at the bottom of the screen, any connected InSims that receive MCI packets will lose connection.

Tiny jumps are unaffected, but even 5 seconds with 19 cars on track and an update interval of 100ms will trigger the disconnection. (~100 MCI packets?)

I'm guessing it's an outgoing InSim buffer overflowing, but I can't see an option to increase it in the client or cfg.txt.

I have tried to work around this by monitoring RIP and STA, but RIP does not fire when using the timeline slider thingy, and disconnect happens before the STA showing the change of ISS_PAUSED.

Attached image is my running the same basic program (print any STA/RIP) twice, both connected to the same client which is paused at the start of the replay. The left window is MCI off, the right is with MCI set to 100ms interval.

The first STA (from startup) you see in both windows, then the slider is clicked: the left window shows ISS_PAUSED is removed from Flags while the replay moves and is re-added afterwards, but the right window loses the connection before receiving the new STA.

--

Side note: This has also happened to me when joining a busy server with lots of new mods to be downloaded by the client - there is a time when the environment is loaded and showing, but players are still loading. You can see them on the minimap, but not in the environment, and there is often a sound loop at the same time. After a while it all catches up, but MCI-based InSims will have lost connection while non-MCI InSims won't.

I know this is my join causing me an effective pit-out for all players at once, and that the newer version has much better pit-out performance - I'm just mentioning this one in case it helps shed light on the other, it looks like it could be the same cause.

Thanks for the report.

I've had a quick look so far and thought I should ask what behaviour we really want from this, in those two situations.

For example one option would be to disable NLP and MCI when fast forwarding. Is there a reason to receive NLP / MCI packets when fast forwarding a replay?

And when joining a host, I guess it could be disabled until LFS has caught up with real time.


Or a different type of solution, I think it might also be possible for a send buffer (held by LFS internally) to expand massively if the input is so much faster than the output but it seems there should be some kind of limit to this.


I'd be interested to hear your thoughts on that. One thing you might try for a quick solution is using UDP packets for MCI / NLP. But of course I don't know how easy it is to change your program to receive UDP packets instead, or if they are suitable for your purposes.

I've seen some league admins using some insim tools to achive some detailed race results, MCI based, but currently they cannot utilize the no_gpu_rendering feature bcuz of this fast forwarding bug, so they stuck the replay at 4x speed and let it wait for hour. Ofc. since they've been doing this bypass for soo looong, it might not be a big concern for them, but still it's a big waste of gpu power for no reason, let alone time.

The solution I'd opt-in for would be to aside from slight buffer increase when buffer runs out: just pause the game and let the buffer drain, but ofc. both only in effect when any insim is connected. Maybe even when it's connected and opted to use MCI packets. Than just quick note on chat like ,,Slowed down the replay forwarding to let the MCI catch-up to InSim" to inform the users the replay would forward faster if they'd had all InSims disconnected.

An less optimal solution would be to replicate the behaviour above only when activated by sending some special flag / packet, but than we run into those abondoned, never updated InSims loosing out on utilizing this feature.

I've discovered this too, but rly wasn't sure if it isn't something wrong on my side. Glad someone more exp have reported it instead.

Quote from Scawen :

For example one option would be to disable NLP and MCI when fast forwarding. Is there a reason to receive NLP / MCI packets when fast forwarding a replay?

When you say fast forwarding, I'm assuming you mean clicking the slider control rather than just speeding up the replay?

I can't see any reason to have NLP/MCI being sent when using the slider control to change position.

But, as well as the workarounds Craaach mentioned for other things, I do use faster replay speeds and longer update intervals for various things with replays. (Drawing heatmaps of location, flying a camera around following a car for timelapse-type footage).

Quote from Scawen :

And when joining a host, I guess it could be disabled until LFS has caught up with real time.

Yes, that should do it, and I can't see any need for NLP/MCI in that case.

Quote from Scawen :

Or a different type of solution, I think it might also be possible for a send buffer (held by LFS internally) to expand massively if the input is so much faster than the output but it seems there should be some kind of limit to this.

I'd be interested to hear your thoughts on that.

That could be useful if the user wants all the data at a set precision as fast as possible, but I've used InSim apps before which buffer the whole lot needlessly and then play it back to you for 5 minutes before they catch up. (Though that's more the fault of the app)

Ideally I think MCI/NLP should be sent during replays at any speed, but paused when clicking on the slider or joining a server.

I think that way people can use the replay speed and interval to get all the data as fast as possible in the resolution they want, but they can skip it if they want to.

Another thought is a warning packet and a tiny delay before the start? Like, clicking the bar causes a RIP with a flag that we could watch for - if we see it, we send a SMALL to disable MCI/NLP ourselves quicker than the delay time. (And another RIP when it lands, for us to know it's safe to turn it on again).

Quote from Scawen :

One thing you might try for a quick solution is using UDP packets for MCI / NLP. But of course I don't know how easy it is to change your program to receive UDP packets instead, or if they are suitable for your purposes.

I had a falling out with my previous compiler about UDP back in the day, and haven't talked to it since

If it's of any use to you to know if it helps then I'll try it on the new compiler over the weekend, otherwise I might leave it on the list a little bit longer.

Thanks for the replies. Yes, by fast forwarding I meant when clicking on the slider. I think this is what CRAAACH means by the "no_gpu_rendering" feature?

Interestingly I think you are both suggesting equally valid but completely different options.

CRAAACH: do send MCI/NLP on clicking slider (or maybe only when sending IS_RIP?) but slow down LFS sufficiently not to flood the buffer.

Racon: avoid sending MCI/NLP on clicking slider.

Although I haven't studied in detail yet, Racon's solution seems easier to implement, is a very good option to have and doesn't really lose anything at this point. So then CRAAACH's solution could be done as a separate option at some point, maybe as a RIPOPT option.

OK, I've done a fix for the replay slider + MCI disconnect issue in Test Patch E8.

Now, when clicking on replay slider or using IS_RIP to do the same thing, NLP/MCI packets will not be sent. I hope this works because I haven't actually tested it, but it was just a line of code.

In the case when using IS_RIP with option RIPOPT_FULL_PHYS the NLP/MCI packets are still sent. My hope is that because it is taking the time to do the physics, the rate of MCI output may be manageable. But I haven't tested this at all so I can't really confirm.


About the similar issue when joining a server, I couldn't think of a quick way to safely avoid sending the packets until LFS catches up with the server. I want to consider this a bit longer.

I've tested and confirm that MCI packets stop during the skip forward from a click. I skipped a 30 minute race of 20 cars in one go with no loss of connection (Rony's RandomCar).

I haven't tried RIP yet, but I will.

I did manage to get a disconnection from a 30-car replay of the "Just A Ride" server, but it takes a jump of about an hour. Just from a quick look it seems that UCO and CSC packets can also be fast enough - they have a lot of checkpoints and circles there.

It's easily manageable now though, without the MCIs.