Same experience here, and for quite a few people at our event yesterday (we were switching cars every few races, so it probably occurred for us more than usual use). Nothing resolves it except restarting LFS, someone said they had to restart more than once.

It seemed to be occasional last week, but this week it seems more frequent. I have all the replays of the event if they're any help.

The results are in!

https://piranmoto.co.uk/events/18

Congratulations to RD2 on returning to the top step of the podium, winning comfortably over a field of 23 by claiming an incredible 181 points of a possible 210! RaceGreen's RedBot claims 2nd place for the second week running, also with comfortable margin. 3rd place was earned by Uber, his first time on the PiranMOTO DD podium.

Join us next week for more!

PLEASE NOTE, this week is the week of timezone shenanigans in PiranMOTO's home country - Events from now until spring will be held at 20:00 UTC

**snip for bandwidth**

Last edited by Racon, Mon 11 Jan 2021, 15:39. Reason : **snip for bandwidth**

yes/66/racon

**snip for bandwidth**

Last edited by Racon, Mon 11 Jan 2021, 16:22. Reason : **snip for bandwidth**

The results are in!

https://piranmoto.co.uk/events/17

Congratulations to PiranMOTO's own Vitas on victory of enormous margin over a field of 24! RaceGreen's RedBot claims 2nd place - one place higher than last week, whilst PiranMOTO's Jon swiped 3rd by a single point.

Join us next week for more!

**snip for bandwidth**

Last edited by Racon, Mon 11 Jan 2021, 16:23. Reason : **snip for bandwidth**

Quote from Degats :

AFAICT, when a new packet turns up, it just corrects the initial conditions for the next physics loop.

More pps should mean that the prediction error wouldn't get so large, but I don't see how it would cause more physics processing.

You client has been processing the car's physics all the while the packet is being sent, then when the packet it received, it goes back to the time point where the packet was sent and reprocesses the data from that point up to 'now'. There's overlap - some of the frames have been processed with stale data, then reprocessed with fresh data after the packet.

Essentially, for each second each car requires 1 second's worth of physics processing, plus half* as much as the total pings of all packets received for that car in that second. Ie, a ping of 50ms and 4 packets/sec will require an extra 100ms of 'overlap' processing per second, so 1.1 seconds of processing per second for that car. 40 packets/sec as mentioned above would be 200% - quite an increase.

*I'm assuming ping is including the return journey, hence halving here for average of one direction.

**snip for bandwidth**

Last edited by Racon, Mon 11 Jan 2021, 16:24. Reason : **snip for bandwidth**

Quote from cpn72 :

You have to be very naive to believe that a team of 3 people was able to make an outstanding model of tire physics, which cannot be done by large teams of developers of other race simulators.

Or you could try them?

If I understand it correctly, more packets would also mean more physics processing, as each packet causes some recalculations to account for ping.

#66

**snip for bandwidth**

############################################

Open DD Event #16 Results are in!

Congratulations to event winner RD2!

From a field of 20, first-time winner RD2 beats last week's winner [TC-R] Pete by the slimmest of margins, followed by newcomer Geoff in third.

Full race results are available at https://piranmoto.co.uk/events/16

Last edited by Racon, Thu 30 Mar 2023, 21:55. Reason : timezone shenanigans

yes/66/racon

You only need to do port forwarding on the computer that is running the server, not all of you.

I don't know if it's the cause of your issue or not, but my router will choke if I put ranges in to the port-forwarding - I have to list every port in its own rule separately to the others.

Spoilers!

Quote from lucaf :

As a reminder, my layouts are running on Racon's server "PiranMoto BL Industrial" and there is also lapper system (use !top), would be nice to see more name in statistics

Feel free to use the layouts in your server, events, whatever as long as you share them free Download link here

Ooops, outdated info that I neglected to update! I recently rejiggered my servers and have done away with PiranMOTOBLIndustrial. All tracks that were available there, including all of Luca's BL Industrial series, are now available on PiranMOTOStreetRacing instead

I don't care what tech is used to simulate tyres, I care whether it feels right or not. Immersion > everything else. IMHFBO, of course.

PiranMOTO Discord: https://discord.gg/Yj3B5TS

(...and website: https://piranmoto.co.uk/)

Quote from False hope :

You know what could really shake things up? Once the tire model is out and all these keyboard warriors who kept on defending how great the physics are, will be brought to a stage where the cars feel either like in Assetto Corsa or iRacing, will now suddenly, out of nowhere, praise HOW GOOD THIS UPDATE IS OMG...Yes, that will happen, I guarantee

You are incapable of imagining a good thing getting better? And it's all these other people who don't hide behind pseudonyms who are the keyboard warriors?

Also, if you download a setup file, you can run it (double-click it) in windows, and LFS will copy it into the correct directory for you.

That sounds like a good approach, but it would require the RES packet being expanded I think - there's only two spare bytes in there which is not enough to store the raw value (and they're also not consecutive).

Maybe it could be quantized to something that fits and was granular enough for this purpose, though.

66/racon/Jamie Tresidder/United Kingdom/RB4/PiranMOTO

JokerLap will enforce drivers taking a joker lap in a race. You can set a minimum number of laps required (default 1), and a maximum number of laps allowed (default 1).

You can set the type of penalty given for not meeting the joker lap requirements (default stop-go*).

You can optionally issue a warning to drivers if they must take the joker on their current lap. (This will warn every required lap in the case of multiple required laps).

The layout requires 3 InSim circles placed in such a way as to cover the whole width of the track in the following places (see reference image):

• Index 1, to be placed at the start of the joker lap
  
• Index 0, to be placed at the end of the joker lap
  
• Index 2, to be placed after the rejoin, but before the finish line
  

You may also optionally place a warning circle:

• Index 3, to be placed before the joker lap (with enough track left for them to react safely!)
  

Added in version 0.3:

- multiple joker laps can be required, both minimum and maximum can be set
- penalty type is now configurable
- optional warning at last joker opportunity
- text commands to hot-set configuration
- killswitch

** 0.3 is compatible with 0.2 - you may replace the .exe without replacing the .cfg, default values will apply to the new settings **

(This program requires Visual C++Redistributable 2015 - if you don't have it installed, it is available here: https://www.microsoft.com/en-u ... oad/details.aspx?id=48145)

InSim circle reference:

Last edited by Racon, Wed 17 Mar 2021, 18:44. Reason : version 0.3

Just a quick note to share what I've learned about JRR - you can move people about on the grid before the green lights without triggering the false-start system. Handy if you need gaps on the grid, as the REO packet doesn't allow them.

You do need to buffer the cars somewhere else first with an additional JRR though, as the JRR will allow them to spawn in an identical position as you work through the cars, and any slight movement will trigger a monster lag-hit type collision. I just use the co-ords of the pit start positions - move them all there to clear the grid, then all back to the grid in their correct positions.