**snip for bandwidth**
Last edited by Racon, .
Reason : **snip for bandwidth**
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, .
Reason : **snip for bandwidth**
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
PiranMOTO Open DD Events - Every Friday 19:00 UTC
**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
############################################
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, .
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.
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!
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.
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.
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
PiranMOTO_JokerLap - Enforce a joker lap on a server
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):
- 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:
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
- Index 3, to be placed before the joker lap (with enough track left for them to react safely!)
- 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, .
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.
The plan is to turn the editor they've got into something that is releasable to the public, *after* they're happy with LFS. They're currently doing lighting/tracks and tyre physics - the lighting is coming first, the physics will come with it if it's ready in time.
It's not set in stone though, just a general idea of what they would like to be able to do and when.
It's not set in stone though, just a general idea of what they would like to be able to do and when.
I am! I'll recompile the first version soon (I think that's the one you've got) so it runs better, then I've got an idea to solve the problem of the second
Last edited by Racon, .
Reason : holy disappearing-question-post-making-you-look-like-you're-talking-to-yourself batman!
I've recompiled this now with my new compiler - v2.0 is no longer a resource-hog.
Celtic Crossover - up to 16 crossings per lap!
You like figure 8? Great fun, but with a little practice it's easy enough to avoid collisions as they all come from one place that you have enough time to watch... this track solves that 'problem' by increasing the number of crossings and making them much, much harder to track 
Figure-8 tracks have 2 crossings per lap (diagram 1), the Celtic Crossover has 8 when driving conservatively (diagram 2), or 16 if you're brave enough to drive the faster wide line (diagram 3), all from both directions.
The start grid faces a huge track map to give a hint to newcomers, each corner has a large number sign, and there's a speedbump diamond in the centre to aid navigation, but, it's still pretty easy to get lost... especially if you've been spun
Alas, you do need quite a few drivers to get the full chaos effect (a smaller version suitable for fewer drivers is planned - no timescale as of yet).
Layout free to use, modify, steal bits from, etc, as always.
Layout is available to drive on PiranMOTODestructionDerby (!vote to select if not currently loaded), track stats available at https://piranmoto.co.uk/tracks/274
Figure-8 tracks have 2 crossings per lap (diagram 1), the Celtic Crossover has 8 when driving conservatively (diagram 2), or 16 if you're brave enough to drive the faster wide line (diagram 3), all from both directions.
The start grid faces a huge track map to give a hint to newcomers, each corner has a large number sign, and there's a speedbump diamond in the centre to aid navigation, but, it's still pretty easy to get lost... especially if you've been spun
Alas, you do need quite a few drivers to get the full chaos effect (a smaller version suitable for fewer drivers is planned - no timescale as of yet).
Layout free to use, modify, steal bits from, etc, as always.
Layout is available to drive on PiranMOTODestructionDerby (!vote to select if not currently loaded), track stats available at https://piranmoto.co.uk/tracks/274
Last edited by Racon, .
PiranMOTO Grass10 - Multiple configurations
My latest Grass adventure - Multiple configurations of a test-style grass track, with a common start/finish and pitlane.
Layouts and track maps attached - free to use/modify/share/steal-bits-of/etc.
All configurations are available on PiranMOTOGrass (changeable by vote); Track stats available on PiranMOTO.co.uk.
Every track starts with a blind crest immediately after the finish line, and all (bar one) end with an uphill, adverse-cambered, tightening turn into the straight. Lumps, bumps and gradients are an integral part of each course, with plenty of high furniture and sighting posts around for orientation.
Start-line crest:
Final turn: uphill, adverse camber:
In action:
Furniture:
Open config:
**EDIT** Added Sprint 4 and 5
Layouts and track maps attached - free to use/modify/share/steal-bits-of/etc.
All configurations are available on PiranMOTOGrass (changeable by vote); Track stats available on PiranMOTO.co.uk.
Every track starts with a blind crest immediately after the finish line, and all (bar one) end with an uphill, adverse-cambered, tightening turn into the straight. Lumps, bumps and gradients are an integral part of each course, with plenty of high furniture and sighting posts around for orientation.
Start-line crest:
Final turn: uphill, adverse camber:
In action:
Furniture:
Open config:
**EDIT** Added Sprint 4 and 5
Last edited by Racon, .
It's always going to be a balance - but we shouldn't be addressing these things with hardcoding because people's setups and circumstances vary wildy, let alone requirements for different types of racing.
If there are to be bans on specific setup things in races, they should be enforced by server rules and/or insim so that you can set your server to your own preference, like the FCV option. When we hard-code this kind of thing, we get side-effects.
For example, I'd like to run MRT and FBM on hillclimbs/autocross. Those are perfectly valid cars for a hillclimb (I've seen similar on telly), and a hillclimb is a perfectly valid use of a handbrake in a single seater (they had handbrakes, and they used them for hairpins). But I can't do that if there's a hairpin, because other servers don't want handbrake abuse in their races. We could have had both if single-seat handbrake-ban was an option like FCV, or if we checked ourselves in insim with a handbrake flag added to the MCI packet or something along those lines.
TL,DR: Your right to swing a handbrake-ban should end at my server. Hardcoding means it doesn't, so let's not do that if we can avoid it
PS: I know you said that point was controversial, but the auto-clutch discussion ends before it even starts when real-life paddle-shifters are auto-clutch, doesn't it?
If there are to be bans on specific setup things in races, they should be enforced by server rules and/or insim so that you can set your server to your own preference, like the FCV option. When we hard-code this kind of thing, we get side-effects.
For example, I'd like to run MRT and FBM on hillclimbs/autocross. Those are perfectly valid cars for a hillclimb (I've seen similar on telly), and a hillclimb is a perfectly valid use of a handbrake in a single seater (they had handbrakes, and they used them for hairpins). But I can't do that if there's a hairpin, because other servers don't want handbrake abuse in their races. We could have had both if single-seat handbrake-ban was an option like FCV, or if we checked ourselves in insim with a handbrake flag added to the MCI packet or something along those lines.
TL,DR: Your right to swing a handbrake-ban should end at my server. Hardcoding means it doesn't, so let's not do that if we can avoid it
PS: I know you said that point was controversial, but the auto-clutch discussion ends before it even starts when real-life paddle-shifters are auto-clutch, doesn't it?
FGED GREDG RDFGDR GSFDG