AutoKickStart = 60000
; WAS 45 SECONDS, NOW 60 SECONDS

; How high a loss rate to tolerate
AutoKickLoss = 75
; WAS 65%, NOW 75%

AutoKickTime = 45000
; WAS 30 SECONDS, NOW 45 SECONDS

MaxBandwidth = 32000
REDUCED FROM 72000 - BEEN SOME MAJOR PROBLEMS AND I'M TRYING SOMETHING OUT

UseCompression = 1
I DON'T THINK THIS ACTUALLY DOES ANYTHING? LOL

; The number of bytes we increase the bandwidth usage if we are below the max ping value
; JUSTIFICATION: DOUBLED because of how high the max bandwidth is (72000 now, 16000 stock)
UpCount = 100

; The number of bytes we decrease the bandwidth usage if we are above the max ping value
; JUSTIFICATION: DOUBLED because of how high the max bandwidth is (72000 now, 16000 stock)
DownCount = 50

; How long after join to start checking a player for lag
; JUSTIFICATION: should be more permissive at game start even if 45s seems like a lot ...
AutoKickStart = 45000

; How high a ping time to tolerate
; JUSTIFICATION: HALVED because it was 1500 for Driveline and I don't think that's a good thing for a tournament
AutoKickPing = 750

; How high a loss rate to tolerate
; JUSTIFICATION: REDUCED BY 10 such that the player will be "lagged" at 70%+, having it 80%+ was largely for Driveline as well
AutoKickLoss = 65

Forgot to write this up at the time but most changes can be inferred from the change notes of the versions that precede and follow this one:

autokickping = 1500

Changed values:
MaxBandwidth = 72000 (was 40000)
AutoKickLoss = 75 (was 65)



The bandwidth usage is saturating too easily in some MPI - hopefully this doesn't cause other problems!

Was updating this item and I managed to misclick when selecting the preview image and gave it a text file ... which it accepted.

Increased bandwidth limit to 40000
was previously 32000

Maximum bandwidth reduced from 72000 to 32000, which is twice the default. Issues will arise if a player's connection can't hack it. Anyone reading this, please report any consistent increase in warping and/or choppy movement of ships in your games.

Same as previous version except it's no longer 100% broken and is now considered MP-safe again
Maximum bandwidth set to 72000 (bytes) from 60000 (16000 is stock value) mainly for testing as I have definitely seen the set-point become pinned at 60000
I also believe I've seen actual usage exceed 60000 and bad things happen after that occurs

I had been missing a parameter DownCount which is the complement of UpCount and adding it is good as it allows me to make sure that the two values are at least similar
With DownCount never set to anything other than default and UpCount set far higher, the set-point would rise rapidly and have difficulty coming back down
No longer!
I also turned compression off as the stock net.ini file has it off

Made major changes to file as I found, among bzr assets, the stock file it uses
!@#$ed up when I decided to rename the previous net.ini file and save it with the extension .old .............
The mod became MP-unsafe due to the file extension and ceased to work
Yep... it became a mod that's only relevant to MPl that was also flagged as not being MP-safe!

Fixed in following version by deleting that file.