I don't know about DD wheels specifically, but I know WD40 can really mess with some electronics. In the radio-control circles I was in (way, way back), it was always referred to as "servo killer" rather than by name, even by the model shops selling it. (It didn't kill them dead, but it made them twitchy and nothing would fix it).

Stats at https://piranmoto.uk/events/198

Last edited by Racon, Wed 27 Mar 2024, 17:24.

Stats at https://piranmoto.uk/events/197

Last edited by Racon, Wed 20 Mar 2024, 23:03.

Stats at https://piranmoto.uk/events/196

Last edited by Racon, Wed 13 Mar 2024, 11:55.

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.

12 seconds should be enough, and a text option to increase it would be great.

I was looking for some examples of the short timing for you but so far I've only found a few and they are indeed all 8 seconds when timed properly. (A lot of times they're on grass - they get the car reset and give it the gas, but they're spinning wheels and still not moving when they get specced a couple of seconds later).

(I wonder if maybe your cutoff speed for speccing people is different to mine for allowing JRR - that could eat into the 8 seconds and make it seem shorter when it isn't. I did increase mine to 5mph recently to see if it would help, but I haven't done any checking other than people's complaints about it happening seem to have gone down a little)

Edit: something with 'dnf' in it for the wording I think would be clearest, /specdnf maybe.

Last edited by Racon, Wed 6 Mar 2024, 17:31.

You're absolutely correct.

3 out of the 4 things mentioned are likely better defined as 'basically done' than 'finished'.

So, it wasn't a 75% arse-gravy of a statement after all... more in the region of 70, you reckon? 74? 65?

Scawen detailed every hour of his life for a month straight when he was doing multithreading, but I guess he undid it all afterwards for lolz.

Nevermind though, me and 11,000 other people will just have to make do with our shared delusion of day/night timelapse videos being on youtube.

The real question is: how much progress is it costing our space exploration program to have you guys all moonlighting from NASA at the same time?

PS: If you can't manage searching by yourselves, I should probably point out that tongue-in-cheek doesn't come through text well... I love y'all really

It's all in the progress reports, timelapse videos of the night/day cycle included.

Quote from NumberTwo :

then its onto day/night, new tyre ohysics, multithreading, new lightning system etc.

3 of those 4 things are done, keep up

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.

Stats at https://piranmoto.uk/events/196

Last edited by Racon, Thu 7 Mar 2024, 12:08.

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.

Quote from gu3st :

Should also be noted that if a website does need to authenticate that you are who your LFS Username is, LFS does offer itself as an OAuth 2 provider to authenticate with and should integrate with that rather than asking for your direct credentials.

If you're not a fan of OAuth you can have people specify their LFS username when they sign up on the site, give them a token, and then have an insim command to use the token to activate the account if the username matches.

Great idea, I look forward to tinkering with it

Sorry, I have so many LFS things to do and very little LFS time at the moment... this one got lost in the shuffle. I will bump it back up the list, but no promises as to when I'll get to it.

Quick answer to all those questions is: Download it and put it anywhere you like, it doesn't need to be in a certain place. The image should be PNG format, in the same place. It's a commandline app, so it needs to be run from a DOS window (see usage above), and it saves the layout in the same directory too.

Stats at https://piranmoto.uk/events/194

Last edited by Racon, Thu 29 Feb 2024, 16:59.

Thank you, the server restart fixed it.

In combating/logging this, have you changed anything to do with users timing out from a server?

I'm always connected and have to rejoin after a lost connection every now and then, but today the server doesn't seem to notice that I've timed out.

I've had 'User name is already online' for at least half-an-hour now, usually it takes under a minute for the server to notice I've gone and let me back in again.

(It's not a hack - I'm showing as spectating on the same server, as I was when the connection was lost)

Edit: It's on my server, so I could kick myself from the control panel I think. I don't need to be logged in just yet, so I'll leave that until later in case there's some value in you looking at a live example of a stuck player

Last edited by Racon, Mon 19 Feb 2024, 12:17.

Stats at https://piranmoto.uk/events/193

Last edited by Racon, Wed 21 Feb 2024, 16:01.